Vanilla Dpup 9.x (x86 and x86_64) (old thread)

[dimkr]

shutdown hangs with stray filesystem message and requires hard power-off

Should be fixed by https://github.com/puppylinux-woof-CE/woof-CE/pull/2756.

No matter how I answer, yes or no, the result is the same - the saves are discarded, Puppy boots like the first time

I'll try to reproduce this issue.

[williwaw]

Hi Dimkr

after dd'ing a 2 Gb .img to disk it would be useful to be able to utilize any additional space. Do you have a utility or script in the build? Or perhaps a recommendation?
thanks

[dimkr]

after dd'ing a 2 Gb .img to disk it would be useful to be able to utilize any additional space. Do you have a utility or script in the build? Or perhaps a recommendation?
thanks

You can resize the partitions (using gparted?) or use the included installer (but you'll need to boot from another flash drive first).

[retiredt00]

Just to point out that updating, saving, shutting down, etc with the i386 version installed in the internal HD went really smoothly.

However, PPM cannot find any packages even after updating the repo.
PPM2.5 is really terrible!
Please roll back to the xenial/bionic version (2.0/2.1) that was very usable

[dimkr]

However, PPM cannot find any packages even after updating the repo.

Will be fixed in 9.0.23, see https://github.com/puppylinux-woof-CE/woof-CE/pull/2752.

[Keef]

I also had selected update savefile, but it it was ignored.

Also, is it possible to remap mouse buttons? I have a left handed ergonomic mouse, but can't swap the left and right buttons over. In the absence of a utility to do this, I can achieve this under Xorg by creating .Xmodmap with the line "pointer = 3 2 1". This has no effect on Vanilla Dpup (didn't think it would, but no harm in trying). I've searched for solutions under Wayland, but couldn't find anything I could make sense of.

[dimkr]

Also, is it possible to remap mouse buttons?

Right now - no. I'll add support for left-handed mode, hopefully in time for 9.0.23.

EDIT: testing https://github.com/puppylinux-woof-CE/woof-CE/pull/2758

[dimkr]

I also had selected update savefile, but it it was ignored.

Saving and even loading after upgrade work just fine here:

I also tested multiple save folders, and selection of which one to use - everything works just fine.

Did you type "yes"?

No matter how I answer, yes or no, the result is the same - the saves are discarded, Puppy boots like the first time

I'll try to reproduce this issue.

Did you replace *.sfs from within Vanilla Dpup, or while booting from a different drive?

[retiredt00]

However, PPM cannot find any packages even after updating the repo.

Will be fixed in 9.0.23, see https://github.com/puppylinux-woof-CE/woof-CE/pull/2752.

Yeap, this fixes the issue

Though hardly improves my views on PPM2.5
For example tried to install TAS which requires ffmpeg which pulled 27 dependencies for a total of a 27MB download, and I was not even informed or given the chance to consider
BTW screeny and its 2 small dependencies might worth including OOTB to facilitate "visual" problem reports.

[TerryH]

[Though hardly improves my views on PPM2.5
For example tried to install TAS which requires ffmpeg which pulled 27 dependencies for a total of a 27MB download, and I was not even informed or given the chance to consider

You should change the Auto Install to use Step by step installation (classic mode) or just download packages. Using Package NG will also pull in the same dependencies. As Vanilla DPup appears, very bare bones, installing packages, will require many dependencies to be installed also.

As for screen capture, in my install, screenshots default to mtPaint, which functions well.

Edit: Unable to post image, only blank rectangle appears.

[Keef]

Did you type "yes"?

It did work when I actually typed 'yes' - I'm pretty sure I just hit 'y' before.

[OscarTalks]

Now testing Vanilla Dpup 9.0.22 x86_64
Appimage of Linphone requires libfuse2
I see that Debian Bullseye offers both libfuse3 and libfuse2
Don't know if you would want to include it in the package recipe
Easy to just install via PPM, not sure if other appimages depend on this and they are small libs.
Just thought I would mention it anyway.

Also when doing a bit of compiling I have found that some of the DEV lib packages are not in the devx even though the corresponding runtime shared libraries are in the main Puppy
Again it is not a huge problem to add them via PPM if I can identify them during the compiling process, but I wondered if you might want to consider this.

[dimkr]

Again it is not a huge problem to add them via PPM if I can identify them during the compiling process, but I wondered if you might want to consider this.

I'm trying keep Vanilla Dpup lean. It does include some extra libraries: for example, extra codecs and GPU-based video decoding, because this reduces the CPU% and power consumption of browsers. Most Puppies don't have them, and unsurprisingly, this makes them much smaller, but also slow and power hungry. Most users use a browser, so this "cost" is justified. But I'm against adding dependencies of applications, only to make the installation of these applications easier or faster.

With all that said, if many/most users end up installing these libraries, I'll consider adding them, so they get auto-updated like any other preinstalled package.

[retiredt00]

[Though hardly improves my views on PPM2.5
For example tried to install TAS which requires ffmpeg which pulled 27 dependencies for a total of a 27MB download, and I was not even informed or given the chance to consider

You should change the Auto Install to use Step by step installation (classic mode) or just download packages. Using Package NG will also pull in the same dependencies. As Vanilla DPup appears, very bare bones, installing packages, will require many dependencies to be installed also.

As for screen capture, in my install, screenshots default to mtPaint, which functions well.

Edit: Unable to post image, only blank rectangle appears.

I’m aware of all these things and I can use this pup fine with all its (I think) shortcomings.

I guess what is not clear to me what/whom these builds are for.
If it is just for seasoned users to test new features (wayland/Gtk3 etc) and identify bugs, then I’m good.
But if this puppy as it matures, aspires to be an “official” build, I think user experience should be considered.
It is clearly up to the developer doing the work to “scratch their own itch” as they see best, but we can always suggest and hope.

[dimkr]

I’m aware of all these things and I can use this pup fine with all its (I think) shortcomings.

Just press the PrtSc key on your keyboard, and you'll see it works. The image corruption thingy is not related to Vanilla Dpup and it's a bug in the forum software, as far as I know.

What other shortcomings do you see?

I think user experience should be considered.

Take a look at the long list of fixes in the last 4 releases:

https://github.com/puppylinux-woof-CE/w ... 3?closed=1
https://github.com/puppylinux-woof-CE/w ... 2?closed=1
https://github.com/puppylinux-woof-CE/w ... 0?closed=1
https://github.com/puppylinux-woof-CE/w ... 9?closed=1

Most of these are bug fixes, fixes for security issues, and usability improvements. Users asked for a network wizard easier updates, a left-handed mouse mode and some bug fixes, among other things, and I worked hard to fulfill their wishes.

Contributions (especially bug fixes and testing, not just bug reports) and constructive feedback are always welcome, but if you don't describe issues in a way that allows me to fix them or come up with unrealistic proposals like "let's roll back months or years of changes in PPM and face the consequences", I can't help.

[retiredt00]

Contributions (especially bug fixes and testing, not just bug reports) and constructive feedback are always welcome, but if you don't describe issues in a way that allows me to fix them or come up with unrealistic proposals like "let's roll back months or years of changes in PPM and face the consequences", I can't help.

OK, I’ll bite.

PPM can not install multiple packages at once
Does not give any feedback what to install before it installs it or any progress to know how far you are in the process. (Unless you go to “clasic” mod and keep clicking for ever for each package)
Does not check for available space. Booting from a smallish USB drive space is again a concern and must be checked.
When updating the DBs restarts with blank package fields, you have to change repo to process DBs and then takes for ever on an older machine (literally 140 sec in a pentium machine)

Besides package management, which is important since as you said users will install whatever they need,
The 32 and 64 bit versions are indistinguishable so you can “update” one with the other (I did that! can not tell you which versions though) and end up in a mess.

Is missing OOTB support for NTFS which limits its use in a windows machine (a common scenario I would think)

Is missing OOTB support for older Intel wifi cards, (which makes package installation impossible). A spartan build must have internet connectivity and feedback at all cost.
(A small annoyance on this, when a wireless module is installed the netmon applet shows connection although the internet connection is not established.
To test in a fresh instal of the 32bit version without wired connection and without credentials for WiFi, rmmod the wifi module if loaded and then modprobe it an see the wifi indicator.)

Is missing utilities that can can help you identify the the problem with your hardware (.jwmrc has 297 lines, while in other pups ~400, most of the differences are in the Desktop/system/setup/utility sections ~50 vs ~100)
In an era that everybody has a phone that “has an app for this”, asking for key combinations and terminal commands is “very boomer” (as they tell me…)
As a general exercise, I would suggest to pick a machine from someone, do a fresh install, delete terminal (and do not drop to console) and see how far you can go.

Please do not get me wrong, I think that vanilladpup is a VERY GOOD puppy with major steps forward and I think a clear direction.
Might be a good tho idea to test with people that do not care about computers and OS versions/flavours and just want to use them.
Unfortunately (for this aspect) the forum is becoming an aspiring developer forum rather that a user one. Currently it supports 20+ OS versions with 2-5 users/testers reporting in each (several “testing” many OS versions), so I can understand that is not easy to find “normal users” around here.

Anyway, hopefully I provided some actionable info and apologies for preaching.

[dimkr]

The 32 and 64 bit versions are indistinguishable so you can “update” one with the other (I did that! can not tell you which versions though) and end up in a mess.

This is false! For example, the 32-bit variant doesn't have anything Wayland-related and has SNS instead of ConnMan.

And the updater included in the ext4 images will never update a 64-bit installation to a 32-bit one, or the other way around. Yes, you can make that mistake if you update manually, so ... don't.

Is missing OOTB support for NTFS which limits its use in a windows machine (a common scenario I would think)

The kernel NTFS driver is present. Have you tried it?

Is missing OOTB support for older Intel wifi cards,

Please give me a specific model. Support for Intel cards is included, and I tested multiple laptops for connectivity: some 10+ years old, some ~5 years old and very recent ones, all with Intel cards.

[retiredt00]

@dimkr
Regarding cross version updates, as I mentioned I have installed in a hard drive from the ISO and manual update is the only possible update “mechanism” that I could find.
Now given that the x86_64 version is the only one shown all different files in the download page, picking this should not be very surprising.
The point is that the update mechanism does not have any $ARCH checking safeties. This may not be necessary in other pups since every puppy has a distinct naming scheme, but vanilladpup offers two versions with identical naming in the ISOs, IMGs and SFSs!
I may be wrong but I thing this is a first among Linux distros.
I guess the common name is dictated by some automated building facilitation but adding $ARCH in the naming scheme should not be too difficult.

Regarding windows drives access, the kernel driver is there but ntfs-3g and its dependencies are not. After installing them is fine but till then you keep wondering why the drive visible on your desktop is not mounting when you click on it (without providing any feedback).

Regarding wifi card support as I said is a rather old card and lspci reports: Intel Corporation PRO/Wireless 2200BG”

Thank you for your efforts

[dimkr]

Now given that the x86_64 version is the only one shown all different files in the download page

Have you tried to scroll down, or search?

https://github.com/vanilla-dpup/releases/releases?q=x86
https://github.com/vanilla-dpup/release ... s?q=x86_64

Is https://vanilla-dpup.github.io/ clear enough to avoid this confusion?

[Maybe]

Hey!

VanillaPup 9.0.22 from PPM Install VLC or MPV video player but no success. The installation is interrupted, then the message "Unfortunately, these packages are not available". Below is a list of libraries and .deb files

[dimkr]

The installation is interrupted, then the message "Unfortunately, these packages are not available".

Should be fixed by https://github.com/puppylinux-woof-CE/woof-CE/pull/2752, this fix will be included in 9.0.23.

[dimkr]

9.0.23 is out! The full changelog is at https://github.com/puppylinux-woof-CE/w ... 3?closed=1.

Some highlights -

The annoying and misleading popup after changing the lanugage is gone (only when using one of the ext4 images, where nlsx is included and loaded by default):

Now there's an easy way to enable left-handed mouse mode (only when using Xwayland):

(Users who upgrade from earlier versions: add LIBINPUT_DEFAULT_LEFT_HANDED=1 to ~/.Xwaylandrc)

PPM is now able to install packages that have security updates (for example, mpv and qemu-system-gui) and auto-selects the right mirror for each package:

The "connect" button in the first run wizard is back, and now runs connman-gtk (only on x86_64, x86 still uses SNS):

The sound wizard and network wizard buttons in Puppy Setup are back, and now they run connman-gtk (only on x86_64, x86 still uses SNS) and pavucontrol, respectively:

I hope to get https://github.com/joewing/jwm/issues/540 fixed in time for 9.0.24.

[dimkr]

Stay tuned, apt will soon be part of Vanilla Dpup! https://github.com/puppylinux-woof-CE/woof-CE/pull/2779

I wonder how many users actually use PPM and pkg - should I remove them?

[williwaw]

Stay tuned, apt will soon be part of Vanilla Dpup! https://github.com/puppylinux-woof-CE/woof-CE/pull/2779

I wonder how many users actually use PPM and pkg - should I remove them?

apt is nice. will it be able to access and install a.pet, or should pkg remain for that task?

[dimkr]

apt is nice. will it be able to access and install a.pet, or should pkg remain for that task?

On the one hand, I want it to be possible to install individual .pet packages, by downloading the and clicking them via a file manager.

On the other hand, I think PPM is horrible and I'd like to remove it, but the primary way of removing .pet packages is via PPM and there must be some way to uninstall a .pet package.

pkg never worked for me, so right now, my best idea (which isn't perfect) is to keep PPM but disable everything except package removal functionality.

[amethyst]

there must be some way to uninstall a .pet package.

Well you should be able to manually do so if there are user installed packages file entries or if you know what the contents of the pet files are. Also - It may be possible to modify the "remove builtin packages" script to remove installed user packages instead (again one will in this case have to have a list of installed files). OR make a script for extracting the pet package (maybe using something like pet2dir for the extract), creating a list of the contents and copy the list somewhere, and installing the files by copying it to the system from the extracted folder. This way you don't need PPM at all.

[wiak]

This experimental addon provides dpkg_apt_multiuserPAM facilities for FossaPup64 systems (i.e. official Debian/Ubuntu package manager).

Since tradition Pup initrd didn't provide drive space to fit the sfs addon lower than main sfs, below gave instructions to rename/re-use adrv for that purpose since otherwise adding special-purpose 'bdrv' was up to a Puppy dev, not me, but you know that...

Thanks for the credit by the way. That's the kind of developer you are.

By the way, that original dpkg/apt sfs addon project for Puppy, which you have chosen to fork rather than contribute to, was actually created using specially modified WeeDogLinux build_firstrib_rootfs script - original version as an Ubuntu Focal build (via Ubuntu/Debian debootstrap utility) to produce WDLGO_UbuntuFocal64 little iso I published at below WeeDog link almost exactly one year ago (the modified WDLGO build_firstrib_rootfs can however also directly build a Debian or Devuan dpkg/apt addon sfs versions for Puppy - but most developers generally credit and acknowledge original projects even if forking rather than contributing - however, we know your 'pretend' approach already...):

https://weedoglinux.rockedge.org/viewto ... p=332#p332

As I said at the time (being almost exactly one year ago):

It is possible to use the 01firstrib_rootfs.sfs part of this distro as an addon for FossaPup64, but should be slimmed down first to not overwrite some existing crucial FossaPup64 config files. I will later upload a modified 01firstrib_rootfs.sfs purely for that purpose, whose contents could alternatively be permananently merged into a FossaPup64 for the same funtionality.

However, it wasn't big anyway - around 20MiB if provided in xz compressed sfs addon form. Avoiding full/proper multiuser-PAM would make it a little bit smaller but not a lot... but a MB or two maybe, and what a shame it would be to continue to restrict Puppy multi-user 'abilities' unnecessarily for the sake of 'tradition'.

As we all know, all details of that dpkg/apt sfs addon creation for Puppy have been described and explained in detail on Puppy forum already and rockedge has been using it extensively in Fossapup for a long time now and already posted some Puppy-related fixes for the likes of dpkg/apt trying to overwrite existing Puppy files:
viewtopic.php?p=17574#p17574
viewtopic.php?p=17654#p17654

The original Puppy dpkg/addon sfs, for loading at layer lower than puppyXXX.sfs is likely still available via:
viewtopic.php?p=16601#p16601
https://weedoglinux.rockedge.org/viewto ... p=336#p336

Certainly, for more stable use in Puppy I identified some extra work that I indicated at the time would be appreciated from any interested-'others' (and I particularly suggested/invited any interested Puppy devs to look into that since I needed to focus on my own WDLGO project and not woof-CE integration of the scheme), but 'forking' (and per usual without acknowledgement) other's ideas (such as changing layer algorithm to pseudo numeric 1.sfs, 2.sfs, 3.sfs for in a loop sfs search to allow for that missing 'bdrv') instead of appropriately contributing to long existing WDL-contributed-for-Puppy dpkg/apt project provided, after lots of work from WeeDog Linux development efforts as a contribution for Puppy's possible future, is something you probably preferred to be blind towards in terms of crediting the source of that original work. Nothing new here.

@rockedge isn't just a WeeDog Linux enthusiast/user, by the way, he is an official WDL developer with full WeeDogLinux gitlab dev rights, so he knows the history of dpkg/apt sfs addon project and how it operates perfectly well for that whole year now.

They do say that (in your case, apparently constant) "imitation is the sincerest form of flattery", so thanks again.

[dimkr]

Thanks for the credit by the way. That's the kind of developer you are.

which you have chosen to fork rather than contribute to

we know your 'pretend' approach already.

Do I need to credit you for code I wrote?
Did I fork anything here without knowing?
Did I pretend to write this code?
Did you have a patent on union file systems?

Please look at https://github.com/puppylinux-woof-CE/w ... 2779/files. This is not a fork of any prior work, and nothing here is copied from code written by you or @rockedge.

This entire PR adds only 168 lines - I bet you can't find a single line I copied from your work.

(And this solution is 19 MB, smaller than 20 MB, and that's with zstd's lower compression ratio compared to xz. The implementation is different, the result is different, so good luck trying to prove I copied anything from you.).

thanks again.

You're welcome. Please return to your throne in your forum, and stop trolling here.

[Maybe]

Dear @dimkr, please tell me which version of WINE should I use in Vanilla PUP64?
a) From PPM Vanilla PUP?
b) one of the WINE_v_xx.pet packages created for puppies by user @version2013?
c) portable WINE?
d) WINE official package for Debian downloaded from https://wiki.winehq.org/Download?

A few words of thanks! Dear @dimkr, I noticed Vanilla PUP after @BarryK saying that this project, in his opinion, is very promising! Indeed, it's nice to see how quickly you react to the found errors and fix them already in your next release! At the moment, everything I need in Puppy Linux works great in your puppy version! The only thing I haven't done yet is install and configure WINE. But I'm sure it's only a matter of time. Thank you so much for your great work!

[wiak]

This is not a fork of any prior work, and nothing here is copied from code written by you or @rockedge.

Oh... 'technically' not a fork - not a fork of code per se - but a copy of existing intellectual idea with actually almost identical underlying implementation (had to be - the sfs needs loaded below main pup sfs, you need a rearranged layering system - you already copied that idea with your frugalify 1.sfs, 2.sfs, 3.sfs loop creation per WeeDog addlayers algorithm (slightly modified and very simplistic version per you need to re-write in C - very inflexible overall of course since hiding in C limits what you can get it to do without crazy efforts - oh yes, we know, C is faster than shell script, which is no big deal here in practical use).

As for the code you use to put together your dpkg/apt sfs variant, you are simply talking about the code you use to push it into woof-CE, which is of no concern to me (there is little or no difference between Ubuntu/Debian/Devuan creations of the same).

and as for the 19MB instead of 20MB because of zstd compression instead of xz, well that is just a ridiculous comment.

In fact the underlying implementation of the addon sfs can not be very different at all since that is determined by dpkg/apt dependencies.

Stop continually stealing credit and instead reference previous works that are published here (as any proper professional developer/researcher would do anyway) that you read prior to your self-crediting 'inventions' and of course I will not bother commenting.