Closed 01micko closed 5 years ago
I compiled this in slacko 140.. and tested it in dpup stretch. It works
It will be the only supported pngoverlay both in woof and in the running system.
There will also be a generic.petbuild just in case.
I have to build a slacko 140*64 + a raspup to compile pngoverlay.
I can do 64 and armhf if needed. I did do armhf but the USBHDD died on me... was building a devuan based raspi version .. all is not lost tho because I saved the config files.
I certainly have an ulterior motive for pngoverlay-cairo (which I don't care what it is named, so long as it is consistent) and that is that devuan armhf netpbm
package is severely restricted so the script pngoverlay.sh
failed for me. I really needed it to work in chroot too (using zwn
) which woof should do to install packages anyway. It does however make cross building difficult.
Here is a sneak-peek at what I have, and it is certainly at alpha stage too because dpkg
, apt
and friends are working as well as the devx
. If I hadn't have had the crappy hardware failure I'd be releasing this week, but alas...
I was not able to compile (a generic arm) pngoverlay-cairo in my raspi 1.. it would not boot, the board seems to be dead.
zwn uses a woof-arch tarball, which has not been updated
Apparently there is a local store that sells raspis
raspi zero $22 raspi zero w $32 raspi zero - mini hdmi + mini usb adapters $12 raspi 1a+ $45 - hahaha rapis 2b $50 - another joke raspi 3b+ $67
I guess i can buy a raspi zero + raspi 3b+ ($100), i'm just so disappointed that my raspi 1 no longer works. Something happened and i wasn't there see it. I want to sell my barely used Hyperx Fury 8GB DDR3 RAM, my 2GB nvidia graphics card, my bluray burner, bluray player, also my 200+ old useless coins, my cheap electric/acoustic guitars, What else, everything else. Nothing makes sense since i sold my digitech death metal effect
This was compiled in raspup, which is based on Raspbian, not Debian. https://www.dropbox.com/s/v0t2lb9kyivf84v/pngoverlay-cairo?dl=1
It was working when I tested it on my raspi, hopefully it didn’t get corrupted on its way into Dropbox.
I have the opposite problem than 01micko, my raspis are fine but it is the hard drive in my PC that I think is failing.
@wdlkmpx if you are getting a constant red light on your pi without any blinking maybe something is wrong with the SD card. Once my pi wouldn’t boot after changing the SD card and after taking it out, wiping the contacts and putting it back in it booted. If you are not getting any lights then something could be wrong with the power adapter, power cable or USB power connector on the pi itself.
What else, everything else. Nothing makes sense since i sold my digitech death metal effect
Don't sell your guitars. Just get a cheapo champ or something (tube/valve) and plug in a pedal. My little vox 12ax7/el84 5 watt sounds great with a tube screamer. Remember,tone comes from the fingers.
BTW; the first line of the Makefile needs editing,
Should be CC=gcc
, ommitting the ?
, because for some reason gcc-6 armhf spat the dummy.
@woodenshoe-wi BTW, thanks for your efforts on RPI, without which my RPI3 would be collecting dust.
@wdlkmpx Get a website and a donation button.
The minimum version for the raspis is debian/raspbian stretch / devuan ascii.
Stuff was compiled in raspbian stretch, and i think woodendshoe-wi said that it needs to be compiled in a raspi 1 for a package to be compatible with all raspis.. some gcc stuff is activated or something.
I think that my raspi is indeed dead, i used different sd cards, OSes, hdmi cables, etc. There is no ACT (ivity) lights just a red light (power). It might be my fault, it was in several places, and perhaps someone or some little devil (cat) dropped it to the floor. I'll be 5 times more careful from now on. I'll be a different person.
But i read the raspis do indeed suddenly die [often].
I do like buying adapters and stuff as long it's cheap, i can find everything quite cheap, but the raspis are way overpriced here.
Reading https://www.raspberrypi.org/forums/viewtopic.php?f=91&t=34061 i see the hdmi stuff does not always work, specially with big screens or something... requires tweaks in some cases
These lines might be worth adding to config.txt
hdmi_force_hotplug=1
hdmi_drive=1
config_hdmi_boost=9
pngoverlay-cairo
armhf I committed was compiled on my pi3 running a woofed version (I built over a year ago) of @woodenshoe-wi 's work on raspup so it might be good on pi1. I scavenged it out of the save dir on the micro sd after the USBHDD died. My pi1 died an age ago. Was the original 256MB version so pretty much useless with a modern pup running in RAM.
Yesterday i changed the logic to copy sfs's to ram (a bit). You might want to comment in the respective commit.
It's possible to create a cli-only raspup, maybe by duplicating the current raspian/stretch -> stretch-cli, only changing the pkgs_specs, which could be really small and fast for the old pi's, maybe for a small server or something. Such tiny boards.
But overall all apps/libs that are used are cached in ram or something and are unloaded after some time, i noticed this a long time ago. So even when the sfs's are not copied to ram, stuff is as fast as always, but there's more ram available.
As long as no write operations occur, the sd card should not suffer... is this statement true?
Seeing a flash drive with activity lights, there is not much activity, it mostly happen when a program is being opened (and being cached)..
Logic probably needs to be revised again.
I compile stuff on a raspi 1 to make sure it is compatible, but most of the time it should work fine compiling on newer ARM chips as long as the default settings of the Raspbian gcc are used. I don’t think 01micko’s Makefile is trying to automatically detect what CPU it is running on and optimize itself for that 😄. I wasn’t sure if the version I compiled would be compatible with 01micko’s build if it was based on devuan, because if devuan is following the Debian ARM builds, it would be for pi2 and higher chips.
I’m sure I’ve read that the official Rasbian builds are done on more powerful ARM chips and they scan the binaries for illegal instructions to see if the configuration needs to be tweaked to force compatibility.
As long as no write operations occur, the sd card should not suffer... is this statement true?
As far as I know this is true, and if the card could be kept mounted ro most of the time it probably wouldn’t get corrupted by improper shutdowns either.
I remember reading that when using slow media you actually get better performance with light compression like gzip than uncompressed. It also will boot faster without having to wait while copying to RAM.
The only reasons that I can think of that someone would need to be running totally in RAM would be if they want to remove the SD card after booting (I have not tried this, but if you are working on a project that involved using lots of Pis it could save on SD card costs), or network booting (I have not tried this either, but it is supposed to work after a fashion on a Pi3 and better on the newer models).
I now have a pi 0 and woofed up the latest raspup. pngoverlay-cairo
works fine.
The only anomaly is that a 'save' icon appears after saving even though I am using a save folder on ext4. (EDIT: I see since 8358e777a18a283283414c7599f452aced834a71 this is expected)
I knocked up a quick respin of pngoverlay if anyone is interested. Save the code to
pngoverlay-cairo.c
and the Makefile
It doesn't check the file extension or anything really but cairo itself does check if a valid PNG is sourced and will close the program accordingly and all resources should then be freed. It doesn't check icon size either. The prog is hardwired to 48x48 so any other size will produce rubbish.
garbage > prog > more garbage
What it does do is work outside of X, and in place, so no silly copying of the file to the location of the png's. The exec is mucho smallero too. (~11k stripped 64).
There are some other handy snippets too,
icon_switcher
snippet (mid way thrufunc_switch()
)and the matching
pngoverlay.sh