Puppy Linux Discussion Forum

https://sourceforge.net/projects/zestyp ... %2B/alpha/

Problem - solved:
viewtopic.php?p=112279

Looks to me like Ubuntu 24.04 is going usrmerge.........either partially or fully
bash and udev have already changed which has caused recent problems
so the question is should NoblePup32 go usrmerge?

it would make all .sfs which contain bin or sbin or lib unusable.........
and would make all old non-usrmerge kernels unusable.....
and would make NoblePup32 significantly different to JammyPup32

Using core Linux files and programs from another Linux OS, should not require you to make it work the exact way, the other Linux OS does!

Only get what is needed to keep specific core files and programs updated, if that is really needed.

But keep in Puppy the core files and programs to allow it to operate the Puppy way.

Nothing says you must constantly update every file or program.

Change to using something new, should only be done, if it really does add some needed operational improvement and it must be done!

What makes Puppy different, it does not operate the same way, all the other mainstream Linux OS's do!

peebee wrote: Sat Feb 24, 2024 11:55 am

Looks to me like Ubuntu 24.04 is going usrmerge.........

It already is. But Ubuntu inherits most packages from Debian, where usrmerge was default but not mandatory until recently, so thing worked although they shouldn't: if Debian (after 12) is usrmerge-only like most distros, forcing Ubuntu packages to run in a file system layout nobody uses can only cause compatibility issues with packages that assume identical contents of /bin and /usr/bin. Among other problems, you'll hit problems when you try build stuff from source.

Is it possible to use the symlinks /bin -> /usr/bin, /sbin -> /usr/sbin, /lib -> /usr/lib, /lib32 -> /usr/lib32, /lib64 -> /usr/lib64 like Void Linux does to possibly retain enough compatibility to be able to load and run the older style file system arrangements in SFS packages created with out usermerge?

Would this be a way to increase the lifespan of these pre-usermerge SFS packages in Noble32 Puppy Linux variants?

peebee wrote: Sat Feb 24, 2024 11:55 am

Looks to me like Ubuntu 24.04 is going usrmerge.........either partially or fully
bash and udev have already changed which has caused recent problems
so the question is should NoblePup32 go usrmerge?

it would make all .sfs which contain bin or sbin or lib unusable.........
and would make all old non-usrmerge kernels unusable.....
and would make NoblePup32 significantly different to JammyPup32

I wrote a fairly simple script to convert non-usrmerge kernels some time ago. When placed in a frugal folder and the older zdrv is dragged to it, it extracts the zdrv, rearranges it and repackages it with the name of the resident zdrv. I have tested it extensively with good results.
I'm sure it could be easily modified to make any sfs compatible. My coding and GUI building skills are minimal so hopefully someone else will take this on.

#!/bin/sh
#open in terminal
tty -s; if [ $? -ne 0 ]; then xterm -hold -e "'$0' '$1'"; exit; fi

Adjust_SFS_Directories () {
   mkdir ${WKDIR}/usr > /dev/null 2>&1  #Make sure /usr is present for directory transfer
   if [ -d ${WKDIR}/bin ] ; then cp -fr ${WKDIR}/bin  ${WKDIR}/usr; rm -fr ${WKDIR}/bin; fi
   if [ -d ${WKDIR}/lib ] ; then cp -fr ${WKDIR}/lib  ${WKDIR}/usr; rm -fr ${WKDIR}/lib; fi
   if [ -d ${WKDIR}/lib32 ] ; then cp -fr ${WKDIR}/lib32  ${WKDIR}/usr; rm -fr ${WKDIR}/lib32; fi
   if [ -d ${WKDIR}/lib64 ] ; then cp -fr ${WKDIR}/lib64  ${WKDIR}/usr; rm -fr ${WKDIR}/lib64; fi
   if [ -d ${WKDIR}/sbin ] ; then cp -fr ${WKDIR}/sbin ${WKDIR}/usr; rm -fr ${WKDIR}/sbin; fi
}

DST=`dirname $0`
echo $DST
cd $DST

for i in `ls zdrv*.old`; do BS=`basename $i .old`; mv -f $i $BS; done

ND=`ls *.sfs | grep "puppy" | cut -d "_" -f 2-` 
echo $ND
PLC=`pwd`
echo $PLC
echo $PLC/zdrv_$ND
mv $DST/vmlinuz $DST/vmlinuz.old
mv $DST/zdrv_$ND $DST/zdrv_$ND.old
TR=`dirname $1`
echo $TR
cp $TR/vmlinuz $PLC

BSNM=`basename $1 .sfs`
echo $BSNM
mkdir -p /tmp/SFS/wkdir > /dev/null 2>&1  

WKDIR=/tmp/SFS/wkdir > /dev/null 2>&1
SFSDIR=/tmp/SFS
rox ${WKDIR}
rm -frv ${WKDIR}/*
unsquashfs -f -d ${WKDIR} /$1
Adjust_SFS_Directories
mksquashfs "${WKDIR}" "$PLC/zdrv_$ND" -comp xz -Xbcj x86 -b 512K

I have no coding skills but figured something like jrb's script could be done because ITSMETRSH did something similar with PaDS 1.17 in order to handle debian/ubuntu's decision to locate 64-bit libs in three folders (/lib, /usr/lib, and /usr/local/lib)/x86_64-linux-gnu) rather than in the parent folders, themselves.

Someone with coding skills should double-check jrb's script. When satisfied, a pet should be created and posted to the Software Utilities Section.

AFAIK, a reverse-script isn't necessary: NON-usrmerge Puppys will search all '/bin' and '/lib' folders.

Well, I've tried to do a usrmerge build of NoblePup32 and all did not go well.....

I set USR_SYMLINKS=yes in _00build.conf
but the build failed....

Looking at 3builddistro:
the chroot at line 713
is attempted way before line 1096:

[ "$USR_SYMLINKS" = "yes" ] && usrmerge rootfs-complete 1

and therefore the earlier chroot fails.....

Also.... the busybox petbuild when run during a NoblePup32 build puts busybox into /usr/bin and so /support/busybox_symlinks.sh fails

@dimkr - how should a usrmerge build be done? Help appreciated!

peebee wrote: Sun Mar 03, 2024 2:00 pm

the chroot at line 713

You can remove it, I don't know why it exists in first place.

peebee wrote: Sun Mar 03, 2024 2:00 pm

Also.... the busybox petbuild when run during a NoblePup32 build puts busybox into /usr/bin and so /support/busybox_symlinks.sh fails

Fails with what error?

if /bin is a symlink to /usr/bin, creating a symlink in one also creates it in the other.

EDIT: try https://github.com/puppylinux-woof-CE/woof-CE/pull/4245 (not tested), maybe this is it

+A2 is a "usrmerge" alpha build of NoblePup32

66696fba2f39bd05c433bcc0e6a838b9 NoblePup32-24.04+A2.iso

delta from +A0

25f2b902128c8d150b9eb6af22ceeac6 NoblePup32-24.04+A3.iso

Lots of updates..........

Any possibility of a 64bit version out of your Github collection, going forward?

Or, are you anticipating a 64bit Wayland build of Noble Numbat (LTS)?

Clarity wrote: Fri Mar 29, 2024 7:21 am

Any possibility of a 64bit version out of your Github collection, going forward?

Or, are you anticipating a 64bit Wayland build of Noble Numbat (LTS)?

You keep asking - still same answer....

viewtopic.php?t=10791
https://github.com/puppylinux-woof-CE/w ... tu/noble64
https://github.com/puppylinux-woof-CE/w ... oble64.yml

BTW: I saw those links, particularly this https://github.com/puppylinux-woof-CE/w ... oble64.yml . Is that one you've scheduled?

Clarity wrote: Fri Mar 29, 2024 9:51 am

BTW: I saw those links, particularly this https://github.com/puppylinux-woof-CE/w ... oble64.yml . Is that one you've scheduled?

No
https://github.com/search?q=repo%3Apupp ... pe=commits

NoblePup32RC is built locally and transferred to SourceForge ......... latest = 240416

download page

Github distro

Github Release

Repo

@peebee I don't know if mixing Ubuntu 24.04 and Debian 12 packages is a good idea.

Debian is currently undergoing migration to 64-bit timestamps in 32-bit packages (https://wiki.debian.org/ReleaseGoals/64bit-time) but this affects only Debian testing and sid (what will eventually become Debian 13, not 12) while this change is currently propagating into Ubuntu 24.04 (https://discourse.ubuntu.com/t/whats-ha ... ries/43729, https://ubuntuforums.org/showthread.php ... p=14183945 and many others).

The mix of Ubuntu t64 packages from 2024 and Debian pre-t64 packages from 12 can cause issues. An application that uses a 32-bit timestamp can't use a library that uses 64-bit timestamps, it must be rebuilt first so it starts using 64-bit timestamps: otherwise, it truncates timestamps or uses only half of the timestamp (which is 0). If a library thinks a pointer to a timestamp points to a 64-bit wide location but the application passes a pointer to 32-bit timestamp, you probably get corruption, a crash or a security issue.

dimkr wrote: Sun Mar 31, 2024 12:43 pm

@peebee I don't know if mixing Ubuntu 24.04 and Debian 12 packages is a good idea.
.......
you probably get corruption, a crash or a security issue.

I guess we'll find out - seems to be working OK so far........... problem reports awaited

I have no idea if the recently discovered xz backdoor (posted about elsewhere on the forum viewtopic.php?p=115556#p115556) effects 32bit distro builds, but it does seem problematic in recent Ubuntu according to: https://discourse.ubuntu.com/t/whats-ha ... es/43729/7

Fedora Rawhide has the issue (but not KLF at least on installation is old release, but I guess on update it could be effected though Fedora resolving issue via their repos), Linux Mint uses older xz and thus apparently is not effected I am glad to say. One of those occasions when it is maybe better to not be too up-to-date...

dimkr wrote: Sun Mar 31, 2024 12:43 pm

Debian is currently undergoing migration to 64-bit timestamps in 32-bit packages (https://wiki.debian.org/ReleaseGoals/64bit-time) but this affects only Debian testing and sid (what will eventually become Debian 13, not 12) while this change is currently propagating into Ubuntu 24.04 (https://discourse.ubuntu.com/t/whats-ha ... ries/43729, https://ubuntuforums.org/showthread.php ... p=14183945 and many others).

The mix of Ubuntu t64 packages from 2024 and Debian pre-t64 packages from 12 can cause issues. An application that uses a 32-bit timestamp can't use a library that uses 64-bit timestamps, it must be rebuilt first so it starts using 64-bit timestamps: otherwise, it truncates timestamps or uses only half of the timestamp (which is 0). If a library thinks a pointer to a timestamp points to a 64-bit wide location but the application passes a pointer to 32-bit timestamp, you probably get corruption, a crash or a security issue.

This change is being implemented by changing the package names by appending "t64" to the name which immediately invalidates the Woof-CE build lists.......

The problem occurs for both NoblePup32 and NoblePup64.

peebee wrote: Sat Apr 06, 2024 4:00 pm

immediately invalidates the Woof-CE build lists.......

Unless they use deps:yes whenever possible, so dependencies are resolved automatically and don't need to be named specifically.

dimkr wrote: Sat Apr 06, 2024 5:27 pm

peebee wrote: Sat Apr 06, 2024 4:00 pm

immediately invalidates the Woof-CE build lists.......

Unless they use deps:yes whenever possible, so dependencies are resolved automatically and don't need to be named specifically.

It seems like it is often the main component that is being renamed rather than dependencies.....

@peebee

I know that you provide a Noblepup 32 build.

I have a 64bit cpu, so it should run.

Is the only downside to me, that I am unable to use the additional cores?

The device I am using is a laptop that has 4gb RAM therefore that should be acceptable in a 32bit build.

peebee wrote: Sat Apr 06, 2024 6:07 pm

It seems like it is often the main component that is being renamed rather than dependencies.....

But something depends on the 'main component'. For example, you can drop the glib row if the GTK+ row has deps:yes, because the latter depends on the former: put only the 'head' of each dependency chain in DISTRO_PKGS_SPECS and let dependency resolution take care of everything.

Alternatively, you can specify only the -dev package in DISTRO_PKGS_SPECS: its name doesn't change over time and it depends on the non-development package (for example, libgtk-3-dev depends on libgtk-3-0).

NoblePpup32: news

So far (!!) the "t64" issue is not causing any unsurmountable problems.

I tried to update gcc to gcc-14 and entered petbuild h3ll!!

gtkdialog would not build with gcc-14:

printing.c: In function 'pip_message_print_debug':
printing.c:53:9: error: implicit declaration of function 'g_vprintf'; did you mean 'g_print'? [-Wimplicit-function-declaration]
   53 |         g_vprintf(format, args);
      |         ^~~~~~~~~
      |         g_print
make[2]: *** [Makefile:549: printing.o] Error 1
make[2]: *** Waiting for unfinished jobs....

also tried gcc-13 but xdg-puppy-jwm would not build

so will probably be sticking with gcc-12 as all petbuilds seem to build OK with that.

No reply. Message deleted.

Hi @peebee

I'm using nobleppup32 (lunarlobster, too) with grub4dos bootloader.

Is it possible to insert boot parameters into grub4dos to set the keyboard layout and time zone?

Thank you for your help.

Best to you.

Rantanplan wrote: Thu Apr 18, 2024 9:28 am

Hi @peebee

I'm using nobleppup32 (lunarlobster, too) with grub4dos bootloader.

Is it possible to insert boot parameters into grub4dos to set the keyboard layout and time zone?

Thank you for your help.

Best to you.

Same as any other Pup.........
viewtopic.php?t=5484
https://oldforum.puppylinux.com/viewtopic.php?t=115603

The next short-term (STR) release of Ubuntu, Ubuntu 24.10 is due Oct 2024
Ubuntu 24.10 Is The "Oracular Oriole"

Current plans are that NoblePup32 will be that last UPup32 release as building 32-bit Pups from Ubuntu+Debian components is becoming increasingly difficult. There will not be an OracularPup32.