Inkscape 1.0 beta2
Posted: Sat 07 Dec 2019, 17:30
READ-ONLY Archive
https://oldforum.puppylinux.com/
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.
Is this the official link for this file?666philb wrote: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
https://sourceforge.net/projects/dpup/files/64bit/mouldy wrote:Is this the official link for this file?666philb wrote: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
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?
Thanks, this download works.josejp2424 wrote:https://sourceforge.net/projects/dpup/files/64bit/mouldy wrote:Is this the official link for this file?666philb wrote: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
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?
there is the buster repo
hi watchdog.watchdog wrote: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
thanks petihar.petihar wrote: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.
problemas de drivers? . no detecta.marcelo4768 wrote:no detecta el mouse, touchpad del notebok.
http://www.murga-linux.com/puppy/viewto ... 313#956313s243a wrote: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
Slackbuild file attached.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
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
Adjunto archivo e instruccionesno detecta el mouse, touchpad del notebok.
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 ~] $
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.fix sandbox.sh
testing (#2)
@wdlkmpx
wdlkmpx committed on Mar 25, 2018 1 parent a31da76 commit e29f4217baea1c394a59ab0957678d2876f5fa5d
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.s243a wrote:sandbox.sh
...
This seems to be a woof-CE problem, so I created a new issue:
"sandbox.sh -- items='' #1737"
Code: Select all
items="$(echo "$items" | grep squashfs)" #only need SFS's
Code: Select all
items="$(echo "$items" | grep -E "XXXX|YYYY")"
Was the original code committed before puppy started using save folders?jamesbond wrote: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.s243a wrote:sandbox.sh
...
This seems to be a woof-CE problem, so I created a new issue:
"sandbox.sh -- items='' #1737"
Over the years changes to woof-CE apparently made it stops working, and a "fix" was committed in Jan 2018.
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=="; } | \
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.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.
With my partial fixes: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).
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
The top layer is sort of there. It shows up for me as:Now "cat /proc/mounts" and see if that mountpoint is listed in there.
Code: Select all
/dev/sda2 /initrd/mnt/dev_save ext4 rw,noatime 0 0
Maybe later.Experiment with pfix=ram and with savefile/savedir loaded, and you will see the same result.
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/PUPSTATEThis was __certainly__ not the case in the past, and something has been changed in puppy's initrd's init, probably in initrd-skeleton.
Code: Select all
PUPSAVE='sda2,ext4,/dpup_buster/1-07092019//dpupbuster64save'
Agreed.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.
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:The fix is NOT by doing this:Code: Select all
items="$(echo "$items" | grep squashfs)" #only need SFS's
Code: Select all
items="$(echo "$items" | grep "\(squashfs\|\.sfs\)")" #only need SFS's
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:But it should by doingwhere 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).Code: Select all
items="$(echo "$items" | grep -E "XXXX|YYYY")"
Code: Select all
print $0, mounttypes[$0], "on"
I don't think the fix is that hard so no need to revert the previous so called fix or call it broken.]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 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.).(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).