DpupBuster CE 64 and 32 bit

[josejp2424]

Inkscape 1.0 beta2-x86-64



Download Inkscape-1.0

MD5
# 697bd35daf8ef77bbfe306be5518cedf

[linux28]

frozen-bubble
Installation was unsuccessful

get_flash_videos

get_flash_videos
Can't locate parent.pm in @INC (you may need to install the parent module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.28.1 /usr/local/share/perl/5.28.1 /usr/lib/x86_64-linux-gnu/perl5/5.28 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.28 /usr/share/perl/5.28 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/lib/x86_64-linux-gnu/perl/5.28/Encode.pm line 305.
BEGIN failed--compilation aborted at /usr/lib/x86_64-linux-gnu/perl/5.28/Encode.pm line 305.
Compilation failed in require at /usr/bin/get_flash_videos line 26.
BEGIN failed--compilation aborted at /usr/bin/get_flash_videos line 26.

[josejp2424]

For Test HandBrake-20191221-x86_64




Download HandBrake 64 bits

MD5
# 8907996ee839e85906969d4f2c38f248

[mouldy]

here's a 32bit compatibility.sfs made from radky's busterpup32.
all i tested was steam, which worked fine.
https://mega.nz/#!oF8yTQ7Y!8pP3dVmfKnw4 ... zOoXsz2re8

edit: re-uploaded fixing udev link reported by watchdog

Is this the official link for this file?
I tried downloading and after waiting and refusing offers to create an account and some mystery proprietary downloader software, it starts downloading or says its downloading???

Nothing is showing in my browser downloads, nor does a file search find any trace of this file its supposedly downloading to my computer.

Could somebody please explain?

[josejp2424]

here's a 32bit compatibility.sfs made from radky's busterpup32.
all i tested was steam, which worked fine.
https://mega.nz/#!oF8yTQ7Y!8pP3dVmfKnw4 ... zOoXsz2re8

edit: re-uploaded fixing udev link reported by watchdog

Is this the official link for this file?
I tried downloading and after waiting and refusing offers to create an account and some mystery proprietary downloader software, it starts downloading or says its downloading???

Nothing is showing in my browser downloads, nor does a file search find any trace of this file its supposedly downloading to my computer.

Could somebody please explain?

https://sourceforge.net/projects/dpup/files/64bit/
there is the buster repo

[mouldy]

here's a 32bit compatibility.sfs made from radky's busterpup32.
all i tested was steam, which worked fine.
https://mega.nz/#!oF8yTQ7Y!8pP3dVmfKnw4 ... zOoXsz2re8

edit: re-uploaded fixing udev link reported by watchdog

Is this the official link for this file?
I tried downloading and after waiting and refusing offers to create an account and some mystery proprietary downloader software, it starts downloading or says its downloading???

Nothing is showing in my browser downloads, nor does a file search find any trace of this file its supposedly downloading to my computer.

Could somebody please explain?

https://sourceforge.net/projects/dpup/files/64bit/
there is the buster repo

Thanks, this download works.

[josejp2424]

new ISO , DpupBuster CE 64 RC 2


changelog

recompiled kernel 4.19.23.
+ firmware
updated PKG scottman package
blueman bluetooth manager was added
python3
jwm Auto Hide's second panel



Download dpupbuster64-8.0.0-uefi-RC-2-28122019.iso

MD5
# 3454d70dfe42da2eaf58a14a7b4b0736

[watchdog]

I did a new frugal install. I have used a portable abiword 3.0 with the 32 bit compatibility sfs. For cups to work I need again to fix it with:

http://www.murga-linux.com/puppy/viewto ... 15#1035915

[petihar]

Hey, josejp,

Thank you so much for everything you're doing. I just tested your DpupBuster CE 64 RC 2 and I particularly appreciate the addition of blueman bluetooth manager. When you know how difficult it is to make bluetooth work with a pupppy, I take my hat off to you !

Yours sincerely, petihar.

[josejp2424]

I did a new frugal install. I have used a portable abiword 3.0 with the 32 bit compatibility sfs. For cups to work I need again to fix it with:

http://www.murga-linux.com/puppy/viewto ... 15#1035915

hi watchdog.
I see that it does not work on all brother printers

Hey, josejp,

Thank you so much for everything you're doing. I just tested your DpupBuster CE 64 RC 2 and I particularly appreciate the addition of blueman bluetooth manager. When you know how difficult it is to make bluetooth work with a pupppy, I take my hat off to you !

Yours sincerely, petihar.

thanks petihar.
I also had bad times with the bluetooth

[marcelo4768]

no detecta el mouse, touchpad del notebok.

[josejp2424]

no detecta el mouse, touchpad del notebok.

problemas de drivers? . no detecta.

[s243a]

The following "Synergy Package" (i.e. synergy-1.7.6-x86_64-1_SBo.tgz) was built for fatdog64 but works on dpup buster:

Here are some random packages:

mono-4.8.0.495-x86_64…Bo.tgz
avahi-0.6.31-x86_64-1_SBo.tgz
libgdiplus-4.2-x86_64-1…Bo.tgz
dulwich-0.9.0-x86_64-1…Bo.tgz
spawn-fcgi-1.6.4-x86_6…Bo.tgz
synergy-1.7.6-x86_64-1_SBo.tgz

I built these a while ago in fatdog710 beta. The extension looks right. Let me know if there any problems and I'll remove and or rebuild the file.

I didn't compile avachi with all it's options. The options I used are as follows

Code: Select all

./configure \
  --prefix=/usr \
  --libdir=/usr/lib${LIBDIRSUFFIX} \
  --sysconfdir=/etc \
  --localstatedir=/var \
  --mandir=/usr/man \
  --docdir=/usr/doc/$PRGNAM-$VERSION \
  --enable-tests \
  --disable-static \
  --disable-monodoc \
  --disable-autoipd \
  --enable-python-dbus \
  --enable-pygtk\
  --enable-glib \
  --enable-dbus \
  --enable-python \
  --enable-gtk \
  --enable-gtk3 \
  --enable-qt4 \
  --disable-qt3 \
  --enable-core-docs \
  --enable-compat-howl \
  --enable-compat-libdns_sd \
  --with-dbus-sys=/etc/dbus-1/system.d \
  --with-avahi-user=avahi \
  --with-avahi-group=avahi \
  --with-avahi-priv-access-group=netdev \
  --with-distro=slackware \
  --program-prefix= \
  --program-suffix= \
  --build=$ARCH-slackware-linux \
  $MONO

Slackbuild file attached.

http://www.murga-linux.com/puppy/viewto ... 313#956313

To install download synergy, than:

Code: Select all

pkg --get libqt4-network
pkg --get libqtgui4
pkg -i synergy-1.7.6-x86_64-1_SBo.tgz #In the download directory

Mono might also be required...but probably not.

I may eventually try compiling these packages on buster. I tested this using synergy between dpup buster64 and the lastest fatdog64 (i.e. "Fatdog64-810 Beta (9 Dec 2019) ")

[Smithy]

Hi Joseph,
Any reason why the 32 bit version is 420mb? The 64 bit version is also 420mb.
I would have thought it might be nearer 210mb or so.
I tested the 64 bit version. (Latest version).
1. Changing cursors broken.
2.Theme changes. JWM broken in various places.
3. Frisbee persistent even when trying to change to SNS on taskbar.

Nice distro and pulse audio with pasytray implementation interesting!

[nilsonmorales]

Marcelo4768 escribió

no detecta el mouse, touchpad del notebok.

Adjunto archivo e instrucciones
https://my.pcloud.com/publink/show?code ... 9CBV8VKTty
1- Descomprimir el archivo fixtapflsynclient.tar
2- borrar los archivos ocultos /root/.flsynclient y /root/.flsynclient-tap-to-click
si lo hubiera
3- colocar el archivo .flsynclient-tap-to-click descomprimido en /root
4- Reemplazar el archivo flsynclient en /usr/bin
5- Reiniciar X ( cltrl+alt+backspace te lleva al prompt y escribes xwin para reiniciar X, servidor grafico, escritorio como se llame )
6- Abrir la terminal y escribir flsynclient
7- Ir a la pestaña tapping y configurar left finger one button

Ahora ya podras hacer click dando 1 toque al touchpad para configurar doble click creo que debes hacerlo desde las opciones de Rox.

[marcelo4768]

como todo eso sin mouse ?

[josejp2424]

[quote="marcelo4768"]como todo eso sin mouse ?[/quote

Es raro. No te habrá cargado el zdvr.
]

[s243a]

sandbox.sh doesn't work for me:

Code: Select all

[root@dpupbuster64 ~] $ sandbox.sh

mount-FULL: /mnt/sb/fakeroot: wrong fs type, bad option, bad superblock on aufs, missing codepage or helper program, or other error.
Unable to mount aufs br:/mnt/sb/sandbox=rw:Error:=ro:Expected=ro:at=ro:least=ro:6=ro:tokens=ro:for=ro:--checklist,=ro:have=ro:4.=ro:Use=ro:--help=ro:to=ro:list=ro:options.=ro
[root@dpupbuster64 ~] $ 

It was supposedly fixed:

fix sandbox.sh

testing (#2)
@wdlkmpx
wdlkmpx committed on Mar 25, 2018 1 parent a31da76 commit e29f4217baea1c394a59ab0957678d2876f5fa5d

I want to learn about sandbox.sh to run a puppy in a chroot so I probably will need to modify it but first I wanted to see if it worked.

Here's some info on it:
http://distro.ibiblio.org/fatdog/web/faqs/sandbox.html

Edit: This seems to be a woof-CE problem, so I created a new issue:
"sandbox.sh -- items='' #1737"

[jamesbond]

sandbox.sh
...
This seems to be a woof-CE problem, so I created a new issue:
"sandbox.sh -- items='' #1737"

sandbox.sh used to work. I made the original commit and I made sure that it worked. It only did not work when running off the LiveCD without savefile, because /tmp was a symlink and not a real mounted filesystem, and that could easily be "fixed". When booting with a savefile/savedir, it worked. I had a few posts on this forum (can't find it now) that used sandbox.sh for testing.

Over the years changes to woof-CE apparently made it stops working, and a "fix" was committed in Jan 2018. Sadly the "fix" doesn't work, because it does not address the problem.

The root cause of this particular all the problem is because certain aufs mountpoints cannot be found in /proc/mounts.

See this for yourself. In terminal, type "cat /sys/fs/aufs/si_*/br0". You will see the mountpoint for the topmost layer (either pupsave or tmpfs).
Now "cat /proc/mounts" and see if that mountpoint is listed in there.
Experiment with pfix=ram and with savefile/savedir loaded, and you will see the same result.

This was __certainly__ not the case in the past, and something has been changed in puppy's initrd's init, probably in initrd-skeleton.

Now, demanding rollback to changes to puppy's initrd's init to accomodate one lowly app like sandbox is probably too much, so we just have to live with whatever it is and make sandbox.sh to work again.

The fix is NOT by doing this:

Code: Select all

items="$(echo "$items" | grep squashfs)" #only need SFS's

But it should by doing

Code: Select all

items="$(echo "$items" | grep -E "XXXX|YYYY")" 

where XXXX and YYYY represents the top-layer mountpoints when puppy runs with savefile and without savefile (on upup bionic, this would be /initrd/mnt/dev_save and /initrd/mnt/tmpfs/pup_rw).

So my suggestion is to revert that particular "fix" commit and then work out the proper fix.

Until this is done, sandbox functionality should be considered BROKEN and sandbox.sh should be renamed to sandbox-BROKEN.sh until it is fixed.

(NOTE: Though, I would argue, "proper fix" is to make sure that all branches of aufs layers are visible in the /proc/mounts; because with the fix I suggested above, the sandbox will lose its ability to use existing customisations done in the topmost layer (because the topmost layer is now inaccessible) - which reduces it functionality by much).

[s243a]

sandbox.sh
...
This seems to be a woof-CE problem, so I created a new issue:
"sandbox.sh -- items='' #1737"

sandbox.sh used to work. I made the original commit and I made sure that it worked. It only did not work when running off the LiveCD without savefile, because /tmp was a symlink and not a real mounted filesystem, and that could easily be "fixed". When booting with a savefile/savedir, it worked. I had a few posts on this forum (can't find it now) that used sandbox.sh for testing.

Over the years changes to woof-CE apparently made it stops working, and a "fix" was committed in Jan 2018.

Was the original code committed before puppy started using save folders?

Code: Select all

items=$(
{ echo ==mount==; cat /proc/mounts; 
  echo ==losetup==; losetup-FULL -a; 
  echo ==branches==; ls -v /sys/fs/aufs/$AUFS_ROOT_ID/br[0-9]* | xargs sed 's/=.*//';
  echo "==finised so print=="; } | \

https://github.com/puppylinux-woof-CE/w ... -550190880

Sadly the "fix" doesn't work, because it does not address the problem.

The root cause of this particular all the problem is because certain aufs mountpoints cannot be found in /proc/mounts.

by "cannot be found", I presume that you mean, the script can't find them but they are there. Perhaps though, once upon a time the save folder was directly mounted but I don't think that is the case now. Instead, I think only the partition where the savefolder resides is mounted.

See this for yourself. In terminal, type "cat /sys/fs/aufs/si_*/br0". You will see the mountpoint for the topmost layer (either pupsave or tmpfs).

With my partial fixes:

Code: Select all

[root@dpupbuster64 ~] $ cat /sys/fs/aufs/si_*/br0
/initrd/mnt/dev_save/dpup_buster/1-07092019/dpupbuster64save=rw
/mnt/sb/sandbox=rw

Now "cat /proc/mounts" and see if that mountpoint is listed in there.

The top layer is sort of there. It shows up for me as:

Code: Select all

/dev/sda2 /initrd/mnt/dev_save ext4 rw,noatime 0 0

except that it's missing the path to the save folder, "/dpup_buster/1-07092019/dpupbuster64save" which I don't think is really a mount point (even though it is the top layer).

Experiment with pfix=ram and with savefile/savedir loaded, and you will see the same result.

Maybe later.

This was __certainly__ not the case in the past, and something has been changed in puppy's initrd's init, probably in initrd-skeleton.

You can get the topy layer via "cat /proc/mounts" by appending to dev_save the path found in "/etc/rc.d" to the save location. From /etc/rc.d/PUPSTATE

Code: Select all

PUPSAVE='sda2,ext4,/dpup_buster/1-07092019//dpupbuster64save'

Now, demanding rollback to changes to puppy's initrd's init to accomodate one lowly app like sandbox is probably too much, so we just have to live with whatever it is and make sandbox.sh to work again.

Agreed.

The fix is NOT by doing this:

Code: Select all

items="$(echo "$items" | grep squashfs)" #only need SFS's

It's a partial fix but wdlkmpx, didn't really do this correctly anyway, because when we loop through the loop devices, the mount type of "squashfs" gets replaced with the name of the squash file. That's why my improvment to wdlkmpx partial fix was to use the following grep statement:

Code: Select all

items="$(echo "$items" | grep "\(squashfs\|\.sfs\)")" #only need SFS's

but you're correct that we might also want to mount the save layer, so if we fix the awk code then we can get rid of this grep statement that was added by wdlkmpx.

But it should by doing

Code: Select all

items="$(echo "$items" | grep -E "XXXX|YYYY")" 

where XXXX and YYYY represents the top-layer mountpoints when puppy runs with savefile and without savefile (on upup bionic, this would be /initrd/mnt/dev_save and /initrd/mnt/tmpfs/pup_rw).

These are symlinks which would be a different way to get the top layer and after much head scratching, I see the issue. The issue is that the path to the save layer is different than the mount point but the mountpoint is used as the key when looking up the mounttype in the following statment:

Code: Select all

print $0, mounttypes[$0], "on"

/rootfs-skeleton/usr/bin/sandbox-rw.sh#L112

So when we try to lookup the mounttype using the path to the save file, then it returns nothing, which breaks the gui, because the gui expects three values but it only got two values. wdlkmpx's code changes suggest the viewpoint, that for a sandbox, we don't want the save location anyway. Otherwise it isn't really a sandbox. However, this isn't true if we mount the save-layer as readonly. That way it is still a sandbox. To fix the code we first check that mounttypes[$0] returns a value with a length greater than zero, otherwise maybe print some other value to indicate that it is not a mount point.

BTW, the comparison expression is wrong "else if (mode=4)" but it doesn't seem to matter (I think that this always returns true). For equality comparison it should be mode == 4.

]So my suggestion is to revert that particular "fix" commit and then work out the proper fix.

Until this is done, sandbox functionality should be considered BROKEN and sandbox.sh should be renamed to sandbox-BROKEN.sh until it is fixed.

I don't think the fix is that hard so no need to revert the previous so called fix or call it broken.

(NOTE: Though, I would argue, "proper fix" is to make sure that all branches of aufs layers are visible in the /proc/mounts; because with the fix I suggested above, the sandbox will lose its ability to use existing customisations done in the topmost layer (because the topmost layer is now inaccessible) - which reduces it functionality by much).

I don't think that this is actually a mount point if it is a save folder. I suppose we could separately mount the save folder but that would be redundant and might cause other issues (e.g. slowdown unmounting during shotwown.).