New branches 'legacy' and 'rationalise'

[01micko]

For more information, I will refer readers to this blog post.

I have created 2 new branches legacy and rationalisation.

Important

As @mrfricks and myself are in development please keep changes to testing as bugfix only or minor updates unless there is a pressing need for change. After release of xenialpup and slacko-63x (bugfix) it is intended that rationalise branch will be merged with testing and deleted. Hopefully this will only be a matter of weeks. Of course all xenialpup changes before and at release should land in testing so that we can merge that with master.

'legacy'

legacy branch is purely in place to preserve old code. Read the README before making changes to that branch - changes are discouraged.

'rationalise'

rationalise branch is for sweeping new changes including but not limited to:

• deletion of un-maintained distros (arch, mageia etc) and older unsupported versions of distros (ubuntu - jaunty, karmic, lucid; debian - squeeze; slackware - 13.1)
• rationalisation of code in the woof build system
• changes in the way fdrv is dealt with. See #785
• corresponding changes to kernel-kit and rationalisation of code
• initrd_progs
• other stuff which may need enhancing. Suggestions welcome.

  Notes

I expect that @zigbert will keep updating his progs in testing. Therefore, before anyone makes a commit or PR to rationalise be sure that you have merged the changes in testing. This will make for minimal conflicts when rationalise is merged back into testing.

Of course any minor bugfixes and enhancements should land in testing first. So if you have a change to make, carefully consider if it is major or minor before committing.

As usual, have fun! :octocat:

[peabee]

/bin/vercmp - needed by /usr/sbin/filemnt has gone missing from rootfs-skeleton.....

On 20/06/16 18:08, wdlkmpx wrote:

Reopened #789 https://github.com/puppylinux-woof-CE/woof-CE/issues/789.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/puppylinux-woof-CE/woof-CE/issues/789#event-697933225, or mute the thread https://github.com/notifications/unsubscribe/AFpv0c1F-gRIoQi9PCAVKVOtOAtblDpjks5qNskcgaJpZM4IuPH7.

[wdlkmpx]

Ok peebee, it's time for a new build.. you can delete the old iso (when building from rationalise always delete the old iso as soon as you build a new one).

The fdrv issue should be solved (somewhat), filemnt has been heavily updated, there are other experimental changes, you might want to add vercmp manually.. then we shall see what other bugs appear.

One thing I noticed is that when booting another 'evdev' word appears on each boot.. i will look into this, i don't have much time to test...

[wdlkmpx]

I fixed the vercmp issue in https://github.com/puppylinux-woof-CE/woof-CE/commit/e08b7ad9ae3a0a1f9cc25df5b359cdcf736a34d5

[wdlkmpx]

I see the way rootfs-packages is handled is not the best. Some packages such as mscw and load_sfs should overwrite/override the choices in DISTRO_PKGS_SPECS, but it's the other way round.

I guess that's why mrfricks thinks he is using the woofce MSCW when he is not... Definitely some rootfs packages are more important than others, in the case of load_sfs.. it's importance is pivotal.

[peabee]

Get LxPupSc-16.06.203-R from:

https://sourceforge.net/projects/lxpup/files/Other/test/woof-ce-rationalise

deltas from both 16.06.2 and 16.06.103-R

md5 of generated iso is: d93695e2a0943a6a170d1e0c54b6baa9

BUILD_FROM_WOOF='rationalise;1125e2f;2016-06-21 17:25:29 +0000'

DISTRO_PKGS_SPECS-slackware-current changed to get sfs_load from rootfs-packages

fdrv now AOK

On 21/06/16 22:48, wdlkmpx wrote:

Ok peebee, it's time for a new build.. The fdrv issue should be solved (somewhat), filemnt has been heavily updated, there are other experimental changes,

One thing I noticed is that when booting another 'evdev' word appears on each boot.. i will look into this, i don't have much time to test...

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/puppylinux-woof-CE/woof-CE/issues/789#issuecomment-227583024, or mute the thread https://github.com/notifications/unsubscribe/AFpv0TrbC-stN0A4b49uUK6VZWD9oNJHks5qOFw8gaJpZM4IuPH7.

[gyrog]

Not sure if this is the right place to mention this but woof-CE/initrd-progs/0initrd/sbin/wait4usb_classic is never used with a huge_kernel. And woof-CE/initrd-progs/0initrd/sbin/wait4usb seems to be rather dated. I don't see any of the dmesg messages it looks for, and the only waiting seems to be rather fixed.

[wdlkmpx]

Do you think it's ok to delete both or only wait4usb_classic?

[gyrog]

wait4usb_classic can be deleted. wait4usb is still used, but needs to be updated. 1) The "mount" fails, I think it's obsolete 2) the "dmesg" messages don't exist 3) I always get 1 black "." and 2 yellow "."s, which seems to really be a fixed length pause. So, I'm not actually getting a result as soon as usb is available. 4) Would be handy to be able to turn off "."s when not debuging.

[wdlkmpx]

I deleted wait4usb_classic in https://github.com/puppylinux-woof-CE/woof-CE/commit/7ac866721b1da420b2fd5da90246ad253d064aeb . When booting from usb, there should no lengthy pause, i think most people boot from usb to use stuff in the same usb or the hard drives. That is probably not the case when booting from CD..

I see now you should be able to push updates to init, just make sure you use 'git pull' before editing and commiting changes.

Also this is the new proxy-setup for those who want to test, i already did, and all combinations lead to the same results: https://github.com/puppylinux-woof-CE/woof-CE/commit/60306163ad7f0dd2e5943910e9a98be6aa9c57e3

[gyrog]

@wdlkmpx, The current "init" doesn't use wait4usb_classic because there are no modules, it always uses wait4usb. ( see "init" lines 941-945 ) So, deleting wait4usb_classic does not change what "init" does when a huge-kernel is used. Booting from usb still has the long pause and the 3 dots from wait4usb.

[wdlkmpx]

Yeah I was just pointing that out... I see that it takes at least 4-5 seconds to pass that step (when booting from usb).

On a side note, I see the biggest change in a new version is not the kernel, but Xorg. Puppies basically behave the same with kernel 3.2 and kernel 4.6 (at least with the changes I pushed to rationalise), however Xorg does make a difference.. but only in the oldest hardware, so I guess it doesn't matter anyway. It's good to have different puppies, because some puppies can freeze in some old hardware, however others even more updated do work, so I guess it's a matter of patches, ubuntu seems to have a very particular xorg.

[wdlkmpx]

I need to ask some questions about a number of things, try to coordinate and synchronize pups, this can happen via pm and this thread created by bigpup

http://murga-linux.com/puppy/viewtopic.php?t=106853

So I suggest we all have a random talk there..

[dimkr]

My account in the forums is locked or something (for several months or so). I tried to reset its password several times already, but it didn't work. I'm too lazy to fix this and I find it nicer to have conversations in GitHub, closer to the code.

[wdlkmpx]

Another major blow to xorgwizard-cli in https://github.com/puppylinux-woof-CE/woof-CE/commit/5813359153dbacaab4db2480caf7bb541cb66bcc

iguleder, how about adding your apps to woofce.. starting from syslog. the steps are as follows: compile it for the woofce arches, and edit 00sys_logger and that should be it... I compiled it using another initrd-progs static "pkg", but i guess the binaries are not as small as they should be..

[gyrog]

I now plan t build a new "init" and then port the new stuff back into the current "init". Is it ok if I clobber the "init" in the initrd_progs repository with my new "init"? When the new "init" is working, I would then push patches containing ports of the new stuff to the woof-ce rationalise branch. The final question would be to choose which "init" to keep.

[01micko]

I now plan t build a new "init" and then port the new stuff back into the current "init". Is it ok if I clobber the "init" in the initrd_progs repository with my new "init"?

Absolutely. The init script in that repo was just a convenience at the time so I would think that initrd_progs repo is as good a test bed as any for init script changes.

[dimkr]

iguleder, how about adding your apps to woofce.. starting from syslog. the steps are as follows: compile it for the woofce arches, and edit 00sys_logger and that should be it... I compiled it using another initrd-progs static "pkg", but i guess the binaries are not as small as they should be..

I have a branch that deals with that: integrate-sdaemons. However, initNEW and probably some other files need to be patched. Also, I don't know what exactly takes care of copying init from the initramfs to the main SFS during builds.

[wdlkmpx]

I have static binaries in /bin.. daemon, fakelogin, syslog and 'zinit'.. i can just copy the files from the integrate-sdaemon branch and test... but need to make sure that it will reach the desktop.. what files need patching?

Regarding the static petbuild.. i'd suggest you create a release tarball and use that url. The binaries can go in woof arch i suppose.

peebe has built a recent iso, so you can edit the files and test: https://sourceforge.net/projects/lxpup/files/Other/test/woof-ce-rationalise

On a side note, there's a thread on the forum about xload http://murga-linux.com/puppy/viewtopic.php?t=28483

In my experience that is not a lightweight app, in fact in slow hardware getting rid of it is a must.. if you want to free resoruces to watch videos for example

[dimkr]

what files need patching?

At least rootfs-skeleton/sbin/initNEW - 3builddistro replaces init with this script, which runs the real init.

[wdlkmpx]

iguleder, something is not working.. it looks like it doesn't continue after running 'zinit' (from /sbin/init) and just reboots..

gyro i updated the initrd_progs repo, you can continue from there, it will start to diverge but the changes done to woofce initrd-progs will be ported to the init in initrd_progs..

[wdlkmpx]

If there is interest.. I can add an alternative grub4dos menu for the iso (which includes the same help)...6 options, normal boot, boot no ram, boot with debug, boot to stop at X step (1,2,3), force boot with xorg vesa driver (this is easy to implement). I'm using g4dos 4.6.a 2015-06-18. It can use jpg images.. in fact the same image that greets me on boot (grub4dos menu).. is the desktop background.. https://s33.postimg.org/5it4g6htb/capture29126.jpg

[gyrog]

wdlkmpx, initrd-progs is no use to me if it's init is being changed from woof-ce. I want to store my new init somewhere and then cherry pick which bits of it get ported back to woof-ce. The only changes to my new init should be folk directly fixing it's code. The end of the process is to finish porting all the useful bits back to woof-ce and then discard the new init, or replace the woof-ce init with the new init.

[wdlkmpx]

Actually that is plan... when the new init is declared stable.. it will overwrite the woofce init.. Something that is to be added asap is the code to stop init before it crashes...

[wdlkmpx]

This https://github.com/puppylinux-woof-CE/woof-CE/commit/7a374b380d5e28cf9f9a5664982737ebe6c66e15 is a replacement for pngoverlay.bac... can anybody confirm it's ok to delete pngoverlay.bac ?

[01micko]

# gcc -Wall -o pngoverlay pngoverlay.c -ldl
pngoverlay.c: In function ‘main’:
pngoverlay.c:59:16: warning: variable ‘wid_img1’ set but not used [-Wunused-but-set-variable]
  int hei_img1, wid_img1, hei_img2, wid_img2, dest_x;

[wdlkmpx]

Yeah, but it compiles, actually most of the stuff in pngoverlay.bac is not used (I was only replacing code, not writing from scratch).. i decided to keep that variable. I wonder if pngoverlay.bac actually produces a usable binary? Following its rules leads to at least 1 fatal error, but if I change the order in some of the final lines, then it works in C.

In commit i simplified it even more: https://github.com/puppylinux-woof-CE/woof-CE/commit/cdadd862d96229a16286708b66dcb8b49fdef499 .. works. The binary is 5.5kb here.

[01micko]

# stat -c %s pngoverlay
7096

64 bit. An oddity, that the original bacon binary displays too, is that in the usage it says "front-png back-png output-png". Seems to be the opposite. Works though.

[wdlkmpx]

One thing that can be done for very basic retro compat is "downgrading xorg to a previous version". In arch linux i was able to downgrade xorg from 1.15 to 1.11, of course it was tricky but it worked, as the system changes dramatically and it's not usable in some older hardware. That was in 2015 using a 2014 dvd, i was not able to repeat that step with the latest arch release.

Although playing with my precise install, i upgraded almost everything but xorg, i cannot call it precise anymore, i want to do the opposite in tahrpup.

In puppy it must be easier, just wipe the new xorg-server and drivers and replace it with an old version including some needed libraries, and that whould be it. I think i can try and make a pkg for tahrpup and slacko, a change that cannot be undone, something like that..

[wdlkmpx]

I want to delete welcome1stboot... zigbert, calling zigbert, how about a new welcome1stboot. There is the Sound Wizard (alsawizard) dialog that looks good like a good template to produce a new welcome1stboot and get rid of the .bac file and binaries..

[peabee]

Just experienced a kernel panic with system built with 'rationalise;1125e2f;2016-06-21 17:25:29 +0000' - LxPupSc-16.06.3

System has both adrv and frdrv and after initial install it shut down correctly, created a savefolder and rebooted correctly.

However, I then installed the devx .sfs and on reboot the kernel panic occurred - red error messages on screen from /tmp/sysinit.log which ended in "/pup_ro5 duplicated"

[peabee]

A fresh build with 'rationalise;6810642;2016-06-29 00:46:40 +0000' - LxPup-16.06.303 seems to have cured the kernel panic on reboot when extra sfs are loaded - however I note that fdrv is showing in the sfs_load list as a normal sfs that can be unloaded.....?

[wdlkmpx]

I can confirm the issue, I have new code to push, basically to prevent a kernel panic from happening, so the user can check the log files and look around.

I can see the msg "/pup_ro5 duplicated". I'll download the deltas and the iso and test again

[zigbert]

welcome1stboot... zigbert, calling zigbert :+1:

[wdlkmpx]

There is a script called welcome1stboot after https://github.com/puppylinux-woof-CE/woof-CE/commit/3984ace996535597f3268b84ae76ad786b9e77f1 , I guess it gets overwritten by the binaries when building a pup

Perhaps you might to review or edit it...

[wdlkmpx]

peebee the last iso does not have the latest sfs_load version, don't know why but it seems commits behind woofce git

[wdlkmpx]

After installing a sfs_load pet from woofce git, i see a strange behavior. LxPupSc-16.06.303.iso is the last iso right? Before I attempt to fix issues... rebuild the iso

[zigbert]

welcome1stboot at https://github.com/puppylinux-woof-CE/woof-CE/edit/rationalise/woof-code/rootfs-skeleton/usr/sbin/welcome1stboot looks good to me

[peabee]

Sorry - 16.06.303 had build error - I've withdrawn it.

16.06.403 delta is available to test: https://sourceforge.net/projects/lxpup/files/Other/LxPupSc/interims/

[peabee]

Sorry again - adrv and fdrv in 16.06.403 iso need to be renamed....reuploaded

Kernel panic still occurs if reboot after another sfs installed.

[wdlkmpx]

i fixed the kernel panic issue, now it boots to desktop, but there is something else going on... startup apps run twice, don't know why. i'll have a closer look and try to fix it.

[wdlkmpx]

peebee time for a completely fresh build.. after commit https://github.com/puppylinux-woof-CE/woof-CE/commit/d113cceb497124eb2727bfd3ca074b8a507218db things should have improved a little.

well, snapmergepuppy uses ps, which means busybox ps, maybe that has a negative effect at shutdown in lxpup... i'm not sure, i just happened to stumble on that code

something i notice in my test machine is that from the 3rd boot onwards.. tray apps start twice, but that doesn't happen when i restart X... also that you're using the full PS instead of the puppy script (your approach is right though), and other things we may discuss in the lxpup thread, i'll subscribe to that thread...

[peabee]

Hi @wdlkmpx - tried to do a build with: BUILD_FROM_WOOF='rationalise;469e359;2016-07-01 01:43:06 +0000'

but have a problem as the DISTRO_SPECS in the initrd.gz ends up as the one from the build system not the new system being built - see screenie.

the DISTRO_SPECS in /rootfs-complete/etc is correct.

I've done a manual edit of initrd.gz to correct and done some tests and all seems AOK now on the sfs front etc.

I now realise that when I changed from procps to procps-ng for slackware-current I didn't make the new packages-template to match......this may account for some of the ps changes you've had to make? Unless @01micko tells me I should, I don't think I'll revert now?

Cheers peebee

[wdlkmpx]

Yeah my mistake... I fixed that issue. I think it's ok to have the full ps as default and fix woof and scripts instead.. i used to rant about the ps script... and losetup.. and the fake truncate...

In https://github.com/puppylinux-woof-CE/woof-CE/commit/652e453294856fe385813ff9e440844a492dad23 i introduced a new major change

[peabee]

LxPupSc-16.06.503 built with @wdlkmpx latest changes. Download iso and/or delta from 16.06.3 from: https://sourceforge.net/projects/lxpup/files/Other/test/woof-ce-rationalise/

Tried the new xorgwizard - selected Option 1 = continue without changes - result was a non-working keyboard and mouse (usb wireless Logitech)......

Cheers peebee

[wdlkmpx]

Yes that was a bug, i think it should be fixed now. I also deleted the old xorgwizard-cli code.

A 3rd option could be downgrade xorg server (1.11).. to use the accelerated drivers for some very old video hardware.. currently the SavagePro onboard video card does not work at all with xorg 1.18.3, i'll test it with my 4 prehistoric video AGP cards, i bet it will work with almost all of them at least using the vesa driver, the savage onboard chip is what really sucks..

[01micko]

@wdlkmpx there is something critically wrong with 2createpackages in rationalise branch.

I just built a slacko64 from slackware64-14.2 so it was a build from scratch. Several pets did not get processed - only the _DEV part got processed.

Here is the list:

• arp-scan
• inkscapelite
• mirdir
• notecase
• openal-soft
• p7zip
• pnscan
• retrovol
• usbutils
• wireless_tools
• x264
• xclip
• xfdiff

[wdlkmpx]

I recently added a commit to 2 createpackages, maybe i introduced a bug, i'll look into this, i'll also build a slacko64 to try to reproduce what's wrong, i'm building in a 32 bit machine

[wdlkmpx]

The problem is in findpkgs. There are incostencies in the PKGS_SPECS. For exmaple

mirdir|2.1-x86_64_s630|mirdir-2.1-x86_64_s630.pet||slackware64|14.1| mirdir_DEV|2.1-x86_64_s630|mirdir_DEV-2.1-x86_64_s630.pet|+mirdir|||

These are the rules: |slackware64|14.2| ||| |slackware64|14.1| |slackware64| |t2|8.0rc| |puppy| |

when it reaches this rule: ||| ...only mirdir_DEV will match

And once there is match, this happens: [ -s /tmp/findpkgs_tmp/FNDSPECS ] && break 2 #pkg(s) found.

---

It both packages ended in |slackware64|14.1| , then both will be selected:

mirdir|2.1-x86_64_s630|mirdir-2.1-x86_64_s630.pet||slackware64|14.1| mirdir_DEV|2.1-x86_64_s630|mirdir_DEV-2.1-x86_64_s630.pet|+mirdir|slackware64|14.1|

I'm not sure how to deal with this... this may also happen with the old findpkgs, since there were no discrepancies in the diffs for slacko 14.1 32bit. I'll test..

[wdlkmpx]

The same thing happens with the old findpkgs.. i'll fix the PKGS_SPECS.

[wdlkmpx]

I mean Packages-puppy-slacko6414.2-official