Puppy Linux Discussion Forum

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.

1st almost affordable consumer 64bit PCs emerged in 2nd quarter 2004. Today, people have been throwing out perfectly good, though old, 64bit PCs for free. Thus for last 2 decades, 64bit PCs are everywhere and many of castaway units.

So, like so many of the mainline distros have moved on without providing or dedicating development resources to old 32bit operating-systems, Puppy Linux family of EASY, PUPs, KLs and DOGs has the same limited resource problem.

So the decision to focus future efforts and talents on 64bit, is a very reasonable expectation and step, given how the landscape in the world has changed over the recent decades.

Edited: Minor paragraphs updates.

Clarity wrote: ↑Sat Aug 24, 2024 8:53 am

1st almost affordable consumer 64bit PCs emerged in 2nd quarter 2004. Today, people have been throwing out perfectly good, though old, 64bit PCs for free. Thus for last 2 decades, 64bit PCs are everywhere and many of castaway units.

So, like so many of the mainline distros have moved on without providing or dedicating development resources to old 32bit PCs, Puppy Linux has the same problem.

So the decision to focus future efforts and talents on 64bit, is a very reasonable expectation.

There are still viable 32-bit builds possible using Slackware, Debian and Void components for example - just no longer Ubuntu.