Raspberry Pi build broken

[01micko]

I just did a sanity check, doing a No-X build, crashes at 3builddistro stage

[01micko]

Rolling back 3builddistro to one from late 2012 seems to have fixed it. I'll do a diff and find the problem.

[01micko]

Found the problem. Barry changed it so that the .img is mounted. This is an vfat/ext4 image, Busybox mount failed with the vfat and the script closes. Changing to full mount fixed that but mounting the ext4 no journal partition failed. It may be a problem with the image so I'll try another.

[woodenshoe-wi]

I think I found the other problem with the second partition. The offset was being calculated with the value from the first partition. $P1STARTSECTORS instead of $P2STARTSECTORS

Sent pull request #455
EDIT: That one was against master, #456 is against testing.

[mavrothal]

Where do we stand on this one?

[01micko]

out to pasture?

[mavrothal]

Lovely place to be :D

[woodenshoe-wi]

Well... This spring I couldn't resist and I got a Pi2 and over the summer I did succeed in hacking the woof build scripts enough to make a bootable image that would work with either the 512MB model B or the new Pi2. The Pi2 is a quad core and uses a different kernel, so I modified the scripts to load two kernels into the image. I had success treating the kernels and firmware like any other package and loading them from raspbian.org with the rest of the packages, but there was a puppy specific program used by the fixmenus script, and the ARM version is an old version ( I think jwm-xdgmenu, but that's just from memory ) that can't parse the config file as it currently is in woof. I have the modified woof script files somewhere, but haven't gotten around to making the changes into git commits yet, and am kind of busy getting ready for winter outside.

Short answer:
Probably still broken, at least for Pi2, but I know it can be fixed.
(but it may take me a while to get around to it.)

[woodenshoe-wi]

I found back some of my notes...
...
xdg_puppy-0.7.6-15-binaries_only-armv6.pet
is too old to handle the "MENHEIGHT" option in
/usr/sbin/fixmenus
...

[01micko]

You can compile the newer version. It is at http://distro.ibiblio.org/puppylinux/sources/x

[woodenshoe-wi]

I may be missing something, but the only version I could find was
xdg_puppy-0.7.6-9.tar.bz2
Is this newer than 0.7.6-15?

[woodenshoe-wi]

I tried it and it worked!?
I don't understand the version numbering.

[woodenshoe-wi]

Assuming you wanted the pet, I uploaded it to Drop Box.
https://www.dropbox.com/s/hmk012wqld98w8f/xdg_puppy_jwm-0.7.6-16-armv6.pet?dl=0
I'm guessing at the version number, but I figured that if it worked it must be newer than 0.7.6-15.

I also used petbuilds to compile JWM.
https://www.dropbox.com/s/l34rhvxmw8ogevu/jwm-2.3.2-armv6l_hf.pet?dl=0

Both of these were compiled in a test woof build based on Raspbian wheezy on my model B Pi.
I think they would go in Packages-puppy-wheezy-official?

I haven't finished making all the changes into commits, but I did finish a few and pushed them up to my git-hub account. They have only been tested with builds for raspberry pi, would it be OK to issue pull requests or do they need to be tested on an x86 build first?

[mavrothal]

The one commit I found in your repo at ( a4808b3 ) appears safe, but is always a good idea to run a test build for x86.

Regarding the pets, why not in Packages-puppy-armv6-official. Is there any compile option that would break them in other flavours (that support hard float of course)?
Or maybe open a Packages-puppy-armv6hf repo?
Not that makes a huge difference but if there are more to come is better to get them together I think.

[woodenshoe-wi]

I didn't use any special compile options, but I'm assuming they're dynamically linked against system libs from Raspbian. Some pets from Packages-puppy-armv6-official didn't run right in my Raspbian based builds so I assumed my pets wouldn't run right in other flavors either. If it is a problem to compile new pets for each flavor I could try compiling them statically soft float, then they could run on any armv6, but as they are now they may or may not work depending on what library versions the other flavors use.

I'm still tracking down dependencies so I haven't made my changes to DISTRO_PKGS_SPECS-raspbian-wheezy into a commit yet, but I didn't know if you wanted me to dump all my changes on you at once, or as I finished testing them. a4808b3 735b39f 412006c

[mavrothal]

Pulls with many commits have the risk to get rejected because of some little issue in one of the commits, but makes more sense to get them in one pull if they are related as in this case.
Re-issuing a pull with one commit or many does not make a lot of difference really so I would rather say go with one, but it depends on how comfortable you are with git and pull requests.

[woodenshoe-wi]

The three commits I finished should allow a build that will boot to the command line, but JWM won't start and jwm-xdgmemu can't parse the menu properly. I'm still tracking down dependencies of dependencies, and if I have to do a x86 test build I would rather wait until I am all the way done.

The two issues that I can't solve myself are JWM and xdg_puppy.
One option is to use the dynamically linked pets in Drop Box,
the other option is to try to compile xdg_puppy statically against uclibc
and take the files from petbuilds and make a template to use JWM from Raspbian.

Until this is figured out, my "working" builds won't be reproducible by others.

[woodenshoe-wi]

I did a test build last night with just the commits in
https://github.com/woodenshoe-wi/woof-CE/tree/fix-pi-build
and the problems with JWM and xdgmenu somehow went away by themselves.

I still need to do a x86 test build, but I think I am close to being finished.

[mavrothal]

👍

[woodenshoe-wi]

Well, I've been running into snags with my x86 build. First I tried the slacko 14.1 build running woof-CE in precise but ran into problems in 2createpackages, so I installed the latest slacko on my parent's computer and then 2createpackages worked but when I tried to run 3builddistro it said I had to run 3builddistro-Z instead which is not the script I edited so that won't work for a test.

I also was working on getting rpi-update to work and I think I have to add one more line to fstab for /boot which is done in 3builddistro I think.

I want to try to finish the fix for rpi-update before I try another x86 build, but I can't recommend actually running rpi-update because I think it breaks the arrow keys on my keyboard.

I guess I'm not as close to being finished as I hoped :-(

[mavrothal]

I guess I'm not as close to being finished as I hoped :-(

You are closer than anybody else 👍

[01micko]

I ordered the new 'el cheapo' pi. Still set me back AUD$32.50 😱 but it does come with hdmi adapter and USB adapter. We should be able to make use of FatDogARM repo by @jamesbond3142 😉

[dimkr]

It's ARMv6 like Raspberry Pi 1 😴

[01micko]

Doesn't matter.. we can build up a repo.. 👍 petbuilds should help.

Even better really. We can revisit GTK 1 and Dillo and all the good old small stuff.. run it all in RAM and show those other distros that Pi can Fly. 😁

[mavrothal]

But let's have something that builds first 😉
(have to do something about it...)

[01micko]

TBH I don't like the idea of downloading an image. It should be created on the fly with builder's choice of ext2, or ext3,4 (no journal)., with builder's choice of size.

Actually, if you make the small FAT partition, then swap, then the Linux partition it becomes trivial to resize the thing, so a default of fitting on a 2 GB media is easy to resize (with gparted or tool of choice).

[woodenshoe-wi]

For those of you that have a Pi or are buying one, I have my work uploaded to git-hub and you can start playing with it now if you would like.
https://github.com/woodenshoe-wi/woof-CE.git
If you are running anything older than Slacko 6.3.0 you will need to update debdb2pupdb or you will have errors finding the raspberrypi-bootloader-nokernel package.
See https://github.com/woodenshoe-wi/woof-CE#raspbian-build

On the subject of fixing the the Pi build in woof-CE, I tried a slacko 14.0 build and when I tried to boot the CD on my laptop I got this

[woodenshoe-wi]

I started working on a build based on Raspbian stretch, #940 I think I have compiling working now.

@wdlkmpx do you know where I can find a petbuild or at least the configure flags for eudev? And is there a specific version I should use?

I was able to compile the latest version on my pi3 and after adding the mail group make check passes. I would like to recompile it on my pi1 the same way the pet in your Debian stretch build was compiled.

[wdlkmpx]

I used an edited PKGBUILD (Arch), i have the file somewhere. i'll post it later. it's for eudev 3.2.1,

The network interfaces have weird names (enp2s1). Apparently i'm missing these files https://github.com/gentoo/eudev/tree/master/rule_generator also here http://anduin.linuxfromscratch.org/LFS/udev-lfs-20140408.tar.bz2

[wdlkmpx]

This is the updated script i use to produce a complete eudev pet pkg: http://pastebin.com/raw/JnWd3LVK

run this way:
./eudev

when it's a finished you'll see a pet pkg ready to go in the pet repos.

a new feature in 2createpackages is that you can "fake" the installation of problematic apps by specifying exe>null,dev>null,doc>null,nls>null

see commit: 8705f6b

from now on you might want to work in testing as both branches are even..

[wdlkmpx]

oops i think i have to redo the last commits i pushed to rationalise. apparently they got lost

[wdlkmpx]

hmm no. the commits are there. they're just hidden somewhere in the log. strange, as the commit date is 2017-01-11

[woodenshoe-wi]

Success! 😁
I compiled the eudev pet on my pi1, did a test build with with the eudev pet and a fake install of systemd-udev, and now my wifi works properly again. No more strange interface names...

Pet compiled in Raspbian stretch based puppy (raspup-7.0.1)
https://www.dropbox.com/sh/rgrfxxevokj8994/AACE-xx5zBbeIEQQ8OlbysxZa?dl=0
I think it should go in arm/pet_packages-stretch/ with an entry in Packages-puppy-stretch-official

[peabee]

I think it should go in arm/pet_packages-stretch/ with an entry in Packages-puppy-stretch-official

These new items created.....

[woodenshoe-wi]

I have another pet for arm/pet_packages-stretch / Packages-puppy-stretch-official

I have been trying woof builds on my pi3 connected to a computer over Ethernet with the files on the computer's hard drive. I discovered the old disktype would segfault when reading the empty SD image file so I compiled the latest version from http://distro.ibiblio.org/puppylinux/sources/

The original disktype was compiled statically, but I compiled the new one on my pi1 as a regular dynamically linked program. I don't know where it would be used other than during woof builds. If it needs to be compiled statically maybe it could be added to initrd-progs? Otherwise if it is OK to use the dynamically linked version, @peabee if you wouldn't mind, could you upload please?
https://www.dropbox.com/sh/rgrfxxevokj8994/AACE-xx5zBbeIEQQ8OlbysxZa?dl=0

[peabee]

Done.

[01micko]

Ok, since I created this issue all those years ago can we close it? Of course comments are still supported whether it is closed or not.

[woodenshoe-wi]

It probably is still broken in master, but that can't be helped because the base distro is always changing and the updated DISTRO_PKGS_SPECS will be merged into testing because that is the branch that I do my builds from.

I think the stretch build in testing should work, although I haven't done a jessie build recently.

I would say since testing is the default branch, if having a working build in testing is good enough for you, go ahead and close it. 👍

[01micko]

Ok thanks @woodenshoe-wi

NB: testing will eventually be merged to master

[woodenshoe-wi]

Maybe this is a newbie question, but I'll ask it anyway.

It's just theoretical right now, but if Raspbian stretch is not stable by the time testing is merged to master would it be ok to fix DISTRO_PKGS_SPECS directly in master, or should changes only be made in testing?