Puppy Linux Discussion Forum

Glug-glug-glug!? No... Woof-woof!
So what am I talking about? Oh, yeah
Version 9.8 (I know someone wants to use 10 in the future, so I modestly keep the bar lower ).

PPM 2.5, which I don't like, but which shows the difference between the installed and found program. I have removed JWMdesk altogether so far, it is better for user to install a fresh one manually. So far, I've been listening to music in mpv, until I decided which player to choose by default, but I like qmmp. It may be worth replacing Diodon with ClipIt, since the first one eats more memory, but the second one fits the theme of the design (I don't care, but I'm thinking about people). Compilation works, at least netmon_wce has compiled The kernel of the 5.4.x series. Phil stopped at this series for the last time in imppup, so let's start with this according to the precepts of our ancestors Then it will be possible to stuff the sixth one.

I checked mainly in Qemu, but it seems to work fine on a live machine. Drivers for Nvidia and all sorts of programs may be available later (if they are needed at all).
jammypup64-9.8.iso
devx_jammypup64_9.8.sfs

Hello.

I am glad that you have restarted the development of jammypup64. It is one of the two puppies on which we can use IME with Chrome. (The other is fossapup64)

However, with the kernel included in the iso, it was impossible to boot the OS installed on an ntfs partition of the internal HDD. Such failures were happening with puppies developed a while ago. I replaced vmlinuz and the zdrv sfs with those offered by ozsouth (5.15.70), and the OS booted successfully.

thinkpadfreak wrote: Wed Nov 02, 2022 8:53 am

the development of jammypup64

I'm just stalling until Phil comes back and does everything
Kernels are not a problem, we have tons and wagons of them. I haven't watched how the sixth series behaves yet, but I'm going to.
I have not checked ntfs, since I have not used Windows for several years and use only ext4
You can also throw out a quarter of the libraries and squeeze everything into xz, but there is no small-size goal.

I also did not include pa-applet in the composition. The sound is easiest and most convenient to adjust by hovering the cursor over the pasystray icon and rotating the mouse wheel & there are more functions in it.
And in general, it is better to try to produce more functions using the mouse wheel

An interesting observation. The "animation" of attributes inside the terminal works in urxvt in Fossapup, but does not work "out of the box" in LXTerminal in Jammypup.
I wanted to make a jellyfish like this :

I noticed that i965_dri.so and i965_drv_video.so were missing, and added them. The two files are included in fossapup64, and probably in other puppies.

Though intel video chips can be driven by the universal "modesetting" driver, I would like to use the "intel" driver.

thanks! long awaited new stuff to toy with

i notice that on my lenovo ideapad gaming 3 jammypup 9.8 doesnt find my wireless wifi? it does on Jammypup version 9.7b and

imppup - https://forum.puppylinux.com/viewtopic. ... 185#p38185

if i use my usb wireless adapter it works....?

it seems maybe there is missing a driver?

kindly Gnimmelf

Gnimmelf wrote: Thu Nov 03, 2022 4:13 pm

it does on Jammypup version 9.7b

If I choose the time to wipe the laptop from dust and turn it on, then I'll see what's going on with the wireless networks. But most likely the fact is that in 9.7b the kernel and firmware seem fresher, ironically It is necessary, perhaps, to keep up with the times and produce a kernel of the sixth series.

Right up front, as a newcomer, I want to emphasize that I greatly appreciate all the effort expended by developers.
Accordingly, everything I write should be treated as constructive ... without the slightest tinge of complaint.

- - -

I recently downloaded the jammypup64-9.8.iso version of jammypup64 at

https://archive.org/download/jammypup64 ... jammypup64

and have been checking it out.

I have noted a very considerable number of jammypup64 shortcomings;
but those must all wait until later ...
because jammypup64 seems to suffer from what seems to be a serious problem ... viz:
when starting up, it seems unable to retrieve any save-file which is on an NTFS partition.
jammypup64 can happily =create= a save-file on an NTFS partition when shutting down ...
but it seems unable to retrieve same when restarting.

I checked out various older puppy_linux editions to find out at what stage the problem crept in.

https://distro.ibiblio.org/puppylinux/p ... 64-9.5.iso ... seems to have no such problem.
https://archive.org/download/Puppy_Linu ... p/Imppup64 9.6.1.iso ... seems to have no such problem.
https://archive.org/download/jammypup64 ... 4-9.7a.iso - ahhh, there's the problem.
https://archive.org/download/jammypup64 ... 4-9.7b.iso - again, the problem.
https://archive.org/download/jammypup64 ... 64-9.8.iso - again, the problem.

So it looks like the step from imppup64 to jammypup64 which introduces the problem.

Intriguingly, though, the corresponding step from peabee's imppup32 to jammypup32 [and even beyond!] seems clean.

https://sourceforge.net/projects/zestyp ... o/download ... seems to have no such problem.
https://sourceforge.net/projects/zestyp ... o/download ... seems to have no such problem.
https://sourceforge.net/projects/zestyp ... o/download ... seems to have no such problem.

As to the problem itself:
my tracing indicates that an ntfs-3g return code of 21 is received by jammypup64's init script,
twice per call to /sbin/mountpartition,
when the latter [/sbin/mountpartition] makes the following two calls to ntfs-3g:
line 43: ntfs-3g $MNT_DEV $MNT_DIR -o umask=0,no_def_opts,noatime,rw,silent
line 47 [retrying with force option]: ntfs-3g $MNT_DEV $MNT_DIR -o umask=0,no_def_opts,noatime,rw,force,silent

Now, a return code of 21 from ntfs-3g is documented as "meaning" [hey, I use that term extremely loosely]
Unclassified FUSE error
[see https://www.systutorials.com/docs/linux ... -3g.probe/]
Not really very helpful.

The call stack as these return codes of 21 are received is as follows:

init line 1086: #ensure that save partition is mounted
init line 1089: [ "$SAVEPART" ] && ensure_save_mounted
>>>
init line 293: ensure_save_mounted() {
init line 295: ensure_mounted "$SAVEPART" "$SAVE_MP"
>>>
init line 250: ensure_mounted() {
init line 263: /sbin/mountpartition /dev/${1} $ONE_MP $ONE_FS
init line 266 [again after 3-sec sleep in case usb optical drive]: /sbin/mountpartition /dev/${1} $ONE_MP $ONE_FS

However: once jammypup64 initialization is complete,
it is then not a problem to have the "troublesome" NTFS partition mounted on request --
the return code from ntfs-3g is then 0, and the partition can be accessed completely normally
[though of course it is far too late by then for it to be set as the save-file partition].
The "return code of 21 from ntfs-3g" thing is only during the jammypup64 initialization phase
[which explains how jammypup64 can happily create a save-file on an NTFS partition when shutting down].

With that ... over to you!
[I have quite a lot of other information available, if need be -- but that's the heart of it.

jrl wrote: Wed Dec 14, 2022 5:28 pm

such problem.

Thank you for your vigilance. The problem is different. I just don't have any NTFS hard drives left to experiment with - all with ext4. In addition, I am currently collecting a collection of games and screenshots for RetroArch (already 400+ gigabytes ) and just "doesn't matter" for everything else

Working through some similar problems with NTFS partitions and save file images with KLV-Airedale.

Our issue is some of the kernels we are testing are missing the ntfs3 module and seem to hang for long periods of time during boot. Though eventually booting successfully so on a usb stick this hang time can be up to 5 minutes.

File system image files on NTFS partitions do work well when the right initrd.gz - kernel modules, firmware and vmlinuz are present.
Kernel panic, not being able to find the save file or long boot hang times are a result of when the initrd.gz and the kernel components are not configured correctly for use in an overlayfs mechanism applied to NTFS partitions.

This PUP was on my system for quite some time, but, I hadn't tested its operation for some reason (I cant remember).

Today I am happy to report that it appears this distro boots and run faster overall vs it use on bare-metal. Oh it is fast, actually very fast. But on QEMU its BLAZING FAST in the VM! My stanza

qemu-system-x86_64 -enable-kvm -vga std -m 2G -smp 2 -device ac97 -name 'JammyPUP64 on QEMU' -cdrom jammypup64-9.8.iso

So far, everything works. Nothing seems to be buggy/broken and this essentially is a FossaPUP64 upgrade. Further it carries ALL the markings of the standard WoofCE PUPs from the past. Please note the terminal in the picture, below.

Ubuntu has issued a point-release of Jammy since this was published.

@Grey is there any change you can rerun your WoofCE recipe publishing a point release to this PUP? This PUP has everything built-in and MATCHES the contents of FossaPUP64 with the Ubuntu subsystem upgrades, of course.

This is great piece of work flying under the PUP forum radar.

Clarity wrote: Sun Apr 09, 2023 1:31 am

is there any change you can rerun

It's spring now, there's some housework. In addition, a difficult period ("spring exacerbation") for romantics and psychos, always pulls somewhere.

I found the time and drew ANSI graphics for the terminal of one of the Russian distros (but all the work is done in Fossapup ).
And even in this case, some said that the character has a trident in his hand (the symbol of the state with which my state is in conflict ).
I had to explain that the usb-staff is not a trident, but a support for a wanderer and a wizard and is not a gladiator's weapon (after all, he is a penguin, bearded and elderly).

On the left it looks like this in Fossapup, on the right with a different font and theme in target distro (a slightly later version, the right hand is slightly modified):

Clarity, "This is great piece of work flying under the PUP forum radar."

Ditto. Thanks, Grey, for publishing and Clarity for bringing it to my attention.

Some thoughts.

Well, as we know, there are 3 intermediate ones between LTS releases that come out in April of every even-numbered year. October of the same year as the LTS and the April and October releases of the odd year.

Since the release of Jammy, 2 of the three intermediate ones have already appeared. Only the October one remains this year.

It seems to make less and less sense to engage in Jammy. And yes, it seems next time I need to make a system first, and then desktop wallpapers and ANSI graphics

By the way. As @peebee mentioned somewhere on the forum, the next version (October) will be called Mantic Minotaur. It seems that real animals are running out and mythical and legendary ones will be used
P.S. Ah, there was already some werewolf, I finished reading the article on peebee's link

Reading this thread again I first found Clarity's post that "This PUP has everything built-in and MATCHES the contents of FossaPUP64 with the Ubuntu subsystem upgrades, of course. This is great piece of work flying under the PUP forum radar."

I was going to post "Ditto", then saw I already did that.

I returned to this Puppy with larceny in mind. I'm contemplating another build of Bionicpup64-revival (removing LibreOffice as a builtin but offering an independently downloadable SFS; and maybe someother size-reducing changes but) primarily --following amethyst's lead-- to offer a gdrv.sfs which will contain updated glibc libraries, openssl and other web-related applications. [If I can get them to work: failed with my attempt to do that with Tahrpup64; but maybe I'm wiser now ]

I like jrb's Jammy. But gnewpet, https://www.forum.puppylinux.com/viewto ... 211#p73211 which might be useful stealing applications from it doesn't work. Suspecting that that may be a result of Another-Jammy's employment of Overlays rather than AUFS, or some basic change in structure [now that I think of it maybe the storing of records in /var rather than /root/.packages] I booted into Jammypup 9.8 to see if gnewpet functions under it. It does.

But I like this Puppy for the reason I don't like the newer breed of Puppys: (a) AUFS rather than Overlays, so SFS-Load/unload is fully functional; (b) the older wifi technology which is better for my weak connection: when it is lost It can be restarted without an reboot.

Think I'll play with jammypup 9.8 awhile for its own-sake.

And Grey, although working with Ubuntu's interim releases enables one to keep up with the changes they test, and generally keep 'your hand in the game', only Ubuntu's Long-term-releases fit in well with Puppy's general approach to operating systems: "If it ain't broke, don't fix it."

Hello.

I have created a Japanized iso of Jammypup64 9.8.
https://sakurapup.com/forum1/viewtopic.php?f=24&t=3638

It includes kernel 5.15.70 offered by ozsouth in order that it can boot from the ntfs partition.
The adrv sfs is added which contains files related to Japanese.
The main sfs is compressed with the block size 512KB to reduce the size of the iso.
The dri modules are added which are missing in the original iso. The modules are contained in the adrv sfs. The main sfs is not changed except that it is compressed in the way mentioned above.

Hi thinkpadfreak,

For future reference, you may want to designate your 'alphabet' SFSes as ydrv rather than adrv. They work identically, but an adrv has priority: its files will overwrite ydrv's conflicting ones in RAM so are better employed for things which will often change, such as web-browsers. nicOS-Utility-Suite, viewtopic.php?p=12983#p12983 can manage both. As you already have an adrv, you can simply rename it ydrv.

You may like this desktop.

If you want, I can upload the wallpaper, or just it's base without the labradore puppy. I used the 2.6.0 version of pwidgets, and JWDesk 3.6 to create the theme. The icons are Stark042. Let me know your screen resolution. Having discovered that the one for my desktop's monitor was distorted on my laptop's smaller screen (or vice-versa) I have two.

mikeslr wrote: Sun Jun 25, 2023 4:37 pm

you may want to designate your 'alphabet' SFSes as ydrv rather than adrv.

A senior member of the Japanese forum used to use an adrv sfs to japanize puppies. I am not sure whether the settings in the adrv sfs will conflict with settings in other alphabet SFSes, but I would like the settings related to Japanese to be prioritized.

I have another option. It is possible to Japanize puppies with .pet packages.

mikeslr wrote: Sun Jun 25, 2023 4:37 pm

Let me know your screen resolution.

I have two ThinkPads available. Both screens are 1366 x 768.

I keep a cat, but I also like Puppy Linux (and puppies) very much.

You were right, Thinkpadfreak. A grey cat is more fitting for a desktop on grey's OS. See revised screenshot.

The priority order doesn't usually matter. It is only when two files having the same name try to locate the same location in RAM that a potential conflict exist and the priority rule is implemented. As far as I can tell, files relating to language have their own, unique, locations. The other exception may be synaptic. But dimkr is better able to explain why that is.

mikeslr wrote: Sat Jun 24, 2023 7:41 pm

and generally keep 'your hand in the game',

I'm still alive. And even almost healthy

Last Friday I decided to go to the regional center (Rostov-on-Don) for some shopping. As a result, I saw strange events. I do not know what it was. But impressions and memories are like from a surrealist painting.

Well, or as in this clip:

Grey wrote: Tue Jun 27, 2023 6:17 pm

Last Friday I decided to go to the regional center (Rostov-on-Don) for some shopping.

But there are also positive aspects.
I bought a good adapter in Rostov, with which you can connect SATA and old IDE disks via USB. As a result, I found the Linux version of the AnimeStudioPro 5.6 (yes, Moho ) program on the old IDE disk. This is the only version for Linux, 2008, but still excellent (yes, a pirated version with a key ). Unexpectedly, the program started working in Fossapup !
Anime Studio still rocks:

mikeslr wrote: Mon Jun 26, 2023 6:51 pm

The priority order doesn't usually matter. It is only when two files having the same name try to locate the same location in RAM that a potential conflict exist and the priority rule is implemented. As far as I can tell, files relating to language have their own, unique, locations.

I agree. I don't think that files related to Japanese exist in other alphabet SFSes.
But I will leave the iso which I have created as it is for the time being. The users can rename the adrv sfs if they want to.

Grey wrote: Tue Jun 27, 2023 6:17 pm

I'm still alive. And even almost healthy

You got me worried there love, I thought you ran away with another man.