XenialDog (Ubuntu 16.04 'Xenial Xerus' LTS, 32-bit)

[mikeslr]

Hi ruffwoof & All,

Foxitreader, discussed here, http://murga-linux.com/puppy/viewtopic. ... 5ea#936553 worked OOTB under XenialDog64. I would expect similar results in other "Dogs".

Mine is in an external folder /mnt/home/pup-apps/foxitreader. So to start it under XenialDog64 I browsed to that folder and clicked the wrapper named FoxitReader.sh.

Under Puppies, I start it via menu having built a pet which creates such menu entry. I do this with all applications I frequently run from "external" folders. These pets consists only of a bash script on the path pointing to the executable; an icon in /usr/share/pixmaps and a desktop file in /usr/share/applications. I wonder if there is an easy way to convert those Puppy Pets to create menu entries under Dogs. Alternatively, to build debs for that purpose.

An older version of Master PDF Editor than rufwoof linked to wouldn't run under XenialDog64. I think it has Qt 4x as a dependency. I noticed that, from the link rufwoof provided, the 64 bit versions names included a reference to QT5 while the 32 Bit versions did not. In the former, is Qt5 included in the 64bit version?, In the 32 bit versions, is a separate install of Qt still required? and if so, which version?

mikesLr

[rufwoof]

Sorry Mike I can't help. I just downloaded and installed the .deb and then ran fix dependencies and Debian took care of it all. I seem to recall it saying that libqtprint or something like that was needed after installing the .deb before it would run, but can't recall the exact detail.

[fredx181]

Hi Max2017,

I am trying to use an encrypted savefile, but I can't get it to load on reboot.
....
....

Welcome and congratulations!! Your first post and you found a real bug!!
There's a fix if you have a frugal install and using porteus-boot :

Added to Changes and fixes list

Bugfix for when using encrypted savefile:
If XenialDog is frugally installed and using "porteus-boot":
https://github.com/DebianDog/xenialdog/ ... rteus-boot
Replace initrd1.xz in the "casper" folder with the one from Here and encrypted savefile should work.

And thanks for reporting.

Fred

[Max2017]

Hi Fred,
I'm more than impressed by your quick response. If me finding bugs helps not just me but also you and others, I'm glad to help.

I just tested your bug fix. It works like a charm on the 32bit-version. Actually, I'm typing this from my frugal installation with porteus-boot.

Just two more questions:
1. Could you also provide a fix for the 64bit-version?
2. Your bug fix (naturally) doesn't survive a kernel upgrade. Any workaround for that? I don't mind getting my hands dirty myself if pointed into the right direction.

From what I see so far, I'm already a fan. I'll have this doggy running the next weeks. If feedback is welcome, I won't hold back.

Cheers, Max

[mcewanw]

Hi ruffwoof & All,

Foxitreader, discussed here, http://murga-linux.com/puppy/viewtopic. ... 5ea#936553 worked OOTB under XenialDog64. I would expect similar results in other "Dogs".

I also sometimes use Masterpdfeditor, but that's when I need a pdf editor on my system - it does indeed need qt. I am also a longtime user of Foxit Reader. However, my question would be: what is the advantage of Foxit reader (or any other "pdf reador" over using Firefox/Mozilla provide PDF.js, which in my tests works very well indeed (is opensource and continually being developed)? Different if you want or need a pdf editor, but that would not surely be expected in base iso. Since base iso comes with Firefox, it thus comes with inbuilt pdf reader, which I suspect many people don't realise can be used with locally-stored pdfs too (just needs activated and, optionally, filebrowser associations set as I described).

Main app most people use is probably their browser (so it is usually already running) - might as well benefit from the additional html5 js support/bloat in them - it's already there so no disadvantage to use anyway.

William

Sorry, wasn't long out of my bed so kept making typing errors and having to fix/repost!!!

EDIT: PDF.js is inbuilt into FIrefox, which works fine/out-of-the-box in default XenialDog32, but if you were using Palemoon it seems you need to add plugin:

https://addons.palemoon.org/addon/moon-pdf-viewer/

Personally, I've always had trouble with Palemoon (after using it for a while). I can't remember the details (maybe fixed?) but it used to start using a lot of RAM over time I think. Nobody else seemed to have the problem or at least didn't notice or didn't report it. I prefer Firefox original.

EDIT: Yes, just read in Palemoon release notes than pdf.js code was removed in Nov 2016 from main browser (ver 27), because their pdf.js code wasn't being maintained. That isn't the case for official pdf.js from mozilla, however, it is constantly being updated/maintained - last pdf.js github entry just 3 days ago and I haven't come across a pdf yet that it can't display correctly.

Of course, I can't say if Firefox will always come with inbuilt pdf reader, but it does just now, and it works. Users can install external pdf readers any time they like...

[Pelo]

Wireless antennas not usable with xenialDog.. how to connect public wireless with my dongle ? Usual wireless just working half a day where i am living. Often i need to make active my dongle.
Often i bring my laptop in my car when weather is sunny. But Wifi is not serviceable unless a driver made available. rcrsn51 makes pets for some kernels for Puppy Linux. How can we get the same with XenialDog ?

[dancytron]

Most wireless drivers are available if you know where to look.

Do you know what chipset you have? If not, the brand name and model information on your dongle?

[fredx181]

Hi Max,

Just two more questions:
1. Could you also provide a fix for the 64bit-version?
2. Your bug fix (naturally) doesn't survive a kernel upgrade. Any workaround for that? I don't mind getting my hands dirty myself if pointed into the right direction.

From what I see so far, I'm already a fan. I'll have this doggy running the next weeks. If feedback is welcome, I won't hold back.

1. Yes, I will, today or tomorrow
2. Well, if you mean when running "upgrade-kernel", it actually should create a initrd1.xz with encryption support, the script has inside: "CRYPTSETUP=Y update-initramfs ....
The CRYPTSETUP=Y command I forgot when creating initrd1.xz for the ISO

Basically creating initrd1.xz is rather simple (see more exact info in code below).
It comes down at:
- Generate initrd.img (with encryption) using update-initramfs (will be located then in /boot)
- Copy and extract just generated initrd.img and initrd1.xz into separate folders
- Replace content of lib/modules in (extracted) initrd1.xz with the content of lib/modules from (extracted) initrd.img
- Create new initrd1.xz

Here are the commands:

Code: Select all

### Create porteus-boot initrd1.xz from generated initrd.img (in /boot) with encryption support

# Check for where initrd files are located (frugal install only)
if  [ ! -f /mnt/live/tmp/modules ]; then    # for casper-boot
# should be exact, parse from /proc/cmdline
live_dir=$(grep -o "live-media-path=.*" /proc/cmdline |sed 's: .*::' |sed 's:live-media-path=/::')
 if [[ -z "$live_dir" ]] ; then
 live_dir="casper/"
 fi

BASE="/cdrom/$live_dir"

else    # for porteus-boot
BASE="$(cat /mnt/live/etc/homedrv)"
fi

# Generate initrd.img with encryption support (in /boot) (CRYPTSETUP=Y does the trick)
CRYPTSETUP=Y update-initramfs -t -c -k $(uname -r)

# Create working directories
mkdir xencasper xenporteus

# Copy original initrd1.xz (from frugal install directory) to xenporteus folder
cp -af $BASE/initrd1.xz xenporteus/

# Copy the just generated initrd.img from /boot to xencasper/initrd.img
cp -af /boot/initrd.img-$(uname -r) xencasper/initrd.img

# Extract initrd.img...
cd xencasper/
zcat initrd.img | cpio -i -d
cd --

# Extract initrd1.xz...
cd xenporteus/
xz -dc initrd1.xz | cpio -i
rm -f initrd1.xz

# Now replace content of xenporteus/lib/modules with content of xencasper/lib/modules
rm -rf lib/modules/*
cp -a ../xencasper/lib/modules/* lib/modules/

# Create new initrd1.xz
find . -print | cpio -o -H newc 2>/dev/null | xz -f --extreme --check=crc32 > ../initrd1.xz

# Optional (uncomment below lines) copy (replace it) initrd1.xz to frugal install directory
# cd ..
# cp -af initrd1.xz $BASE/ 

Yes, feedback always very welcome!

Fred

[Max2017]

Hi Fred,

thank you for your explanations. I'll keep on testing and post any findings.

Looking forward to the 64bit fix.

Take care. Max

[mcewanw]

Fred,

I'm currently preparing an sce package for dCorePup (dCore-xenial) to include some of the DebianDog utilities in it.

dCore comes with dpkg-deb (in wireless sce), so I'm testing out pet2deb (from XenialDog32) at the moment

EDIT2: deleted change code suggestion - I misunderstood (see my EDIT3 below).

I'm not on XenialDog32 just now, so can't test that there. Works on dCoreDog.

EDIT3: I realise now that from command line pet2deb (or pet2deb-convert) needs full absolute pathname of the pet to be converted... I had tried it just with the filename, and things got messed-up a bit. All working fine in both dCoreDog and XenialDog32 with that full pathname proviso.

William

EDIT: Note, that dCore-xenial seems to work well in terms of its package management compatibility with Ubuntu/Debian and mimics apt-usage to quite an extent (sce-import then sce-load, instead of apt-get install, and also has sce-ppa-add, sce-remove, sce-debpurge and sce-update and more). So it could be configured pretty much like XenialDog so the DD utils could prove to be quite handy in terms of 'puppyfying' it (I might also get round to xenialdog-style configured openbox on it eventually).

[Pelo]

i Like wicd , and josejp24 too . I created a topic about wicd not to disturb development of xenialdog.

[mcewanw]

Fred,

I'm scratching my head because I can't see how the pet2deb script ends up with the .deb file in the same folder as the .pet file... It does though.

In the script, there is a cd $EXTRACT

and then every thing gets put in there

and then there is

dpkg-deb ./ ...

which would suggest to me that dpkg-deb would build the new .deb package inside that $EXTRACT directory somewhere (and not the one where the .pet is).

and after that there is a cd `dirname $FILE`, which takes system back to where the .pet is.

after which rm -fr $EXTRACT removes the whole build folder, which I feel would have included the .deb file (but doesn't seem to)? So how does the newly built .deb get into the folder where the original .pet is (which it does)?

I'd like to modify this script to not need fullpathname for the case where you are running pet2deb at the commandline from the same directory the .pet is in. Best of all (less restrictive) would be if it would work with either absolute or relative pathnames for where the dotpet is.

William

EDIT: OKay, I see it now - I was blind: It's because dpkg-deb code is:

Code: Select all

dpkg-deb -b ./ "$FILE"-convert-to.deb

and $FILE contains the fullpathname of the original .pet.

[mcewanw]

Fred,

I've sent you a modded pet2deb via PM for testing. Works with absolute or relative dotpet filenames - a bit more testing would be good, but seems fine - left most of the existing script untouched; just look for lines with mcewanw at end of them.

The mod makes pet2deb more intuitive IMO for commandline use and better for associating files with some filemanagers (fluff on tinycore, in my case, which otherwise needed a `pwd'/filename construct in making right-click file association commands, which was a bit of a pain that this mod cures).

William

[saintless]

Fred,

I've sent you a modded pet2deb via PM for testing.

Hi William.

In case you are interested pet2deb and pet2sfs are mine scripts with credits for the included code inside:
http://murga-linux.com/puppy/viewtopic. ... 7da#783785
I don't know what is the version you are using but both pet2deb and pet2sfs are GPL3. You don't need permission to modify them. Just include the GPL3 license in your mod.
Both have updated version for xz compressed debs.
https://github.com/MintPup/DebianDog-Wh ... pet2sfs.sh
https://github.com/MintPup/DebianDog-Wh ... pet2deb.sh

Toni

[mcewanw]

Thanks Toni. I'll take a look.

I have put License "GPLv3" alongside my mods to any of the existing scripts I work with.

William

EDIT: Had a quick look so far. One thing I feel we, or at least I, shoulld try to get away from using (eventually) is bash dependency. I want to move to my scripts being usable with busybox ash (and presumably dash) since bb/ash is what tinycore uses generally. Should be easy for simple scripts, but bigger programs (like my gtkdialog-apps) will often need a lot of work.

EDIT2: Personally, I have to say that, for system scripts, I prefer less restrictive licenses than GPL. License MIT (as used in scrot - despite it being quite a complex C source program), for example, is very unrestrictive and allows for forks to use more or less restrictive licenses as long as all credits are listed. Shell scripts are often quite simple really so often hard to license as original anyway in my opinion. I sometimes see two-line bash scripts with a GPL stuck on them, which becomes ridiculous. Credit where credit is due is vital though as are date marked mod details and name or source of the modifier IMO

[mcewanw]

Fred,

I've sent you a modded pet2deb via PM for testing. Works with absolute or relative dotpet filenames - a bit more testing would be good, but seems fine - left most of the existing script untouched; just look for lines with mcewanw at end of them.

The mod makes pet2deb more intuitive IMO for commandline use and better for associating files with some filemanagers (fluff on tinycore, in my case, which otherwise needed a `pwd'/filename construct in making right-click file association commands, which was a bit of a pain that this mod cures).

William

I will be running through this script again, to remove bashisms (such as [[...]] construct) and to fix, for example, some double quotes I already visually noticed still missing round variables (which gives potential problems with file/dir names with spaces in them, for example).

I might also avoid yad since don't want to force that on dCore. Like gtkdialog, I prefer yad to be optional rather than core. Xdialog is available by default in most systems, I believe, and if not, then dialog, and worst case can simply give reports to defaultterminal.

As in Toni's recent re-write of pet2deb script, it would, I'm sure, indeed be good to try and avoid gsu and also include ability to work with pets compressed with xv as well as gz.

There is a very nice program/project called ShellCheck, which can be installed with apt-get or used online, which can indicate most of the required 'fixing/improving" and also the bashism-checking. I recommend we always use this (or similar, though ShellCheck is much better than old checkbashisms program, albeit much bigger). To use it to check for bashisms, just make the Shebang at top of scripts #!/bin/sh.

http://www.shellcheck.net/

EDIT: http://net-hope.blogspot.co.nz/2016/07/ ... check.html
I haven't myself used it with geany, so don't know if extra required to get it working with that (in my XenialDog32, the Build -> Build, submenu is greyed out).

EDIT2: Yeah works well with newer geany 1.27 Build -> Lint submenu (used apt to fetch geany from ubuntu repo).

Hope that is useful information, if not already known.

William

[mcewanw]

Hi Fred,

I'm still mulling over the pet2deb situation. I note that you store all the converted binaries in /usr/local hierarchy. But I remember in earlier DebianDog /opt hierarchy was used instead, apparently to remove possibility of such files as converted dotpets clashing with Debian files of same name? Could you clarify that and explain why you prefer /usr/local hierarchy for the converted files to /opt?

Main reason I ask is that tiny core dCore actually takes the official Debian binaries and transfers them to /usr/local hierarchy - then I see a real danger of clashes if dotpets converted to debs were also put into that same area. So for pet2deb use in dCore it seems to me that /opt will be better, though I'm not sure of the DebianDog situation in terms of clashes or not.

Cheers, William

[fredx181]

I'm still mulling over the pet2deb situation. I note that you store all the converted binaries in /usr/local hierarchy. But I remember in earlier DebianDog /opt hierarchy was used instead, apparently to remove possibility of such files as converted dotpets clashing with Debian files of same name? Could you clarify that and explain why you prefer /usr/local hierarchy for the converted files to /opt?

Well, not really a big reason, I changed to /usr/local/bin (and removed /opt/bin from PATH) just to stay as close as possible to "official" (/usr/local/bin is already in PATH by default)
So that PATH change resulted in needing to modify pet2deb also.
EDIT: Also a reason was to have most custom scripts (not-official-Debian) in one place: /usr/local/bin rather than in two places

You can change the PATH of course on Dcore (and pet2deb accordingly) but that would mean that you need to modify standard system config files e.g. /etc/profile.


Not sure to understand what you mean by "clashing". Replacing files accidentally in /usr/local/bin ?
If a script with the same name would be in /opt/bin and suppose /opt/bin is the first in PATH it would "clash" also IMO.

Fred

[mcewanw]

I'm still mulling over the pet2deb situation. I note that you store all the converted binaries in /usr/local hierarchy. But I remember in earlier DebianDog /opt hierarchy was used instead, apparently to remove possibility of such files as converted dotpets clashing with Debian files of same name? Could you clarify that and explain why you prefer /usr/local hierarchy for the converted files to /opt?

Well, not really a big reason, I changed to /usr/local/bin (and removed /opt/bin from PATH) just to stay as close as possible to "official" (/usr/local/bin is already in PATH by default)
So that PATH change resulted in needing to modify pet2deb also.
EDIT: Also a reason was to have most custom scripts (not-official-Debian) in one place: /usr/local/bin rather than in two places

You can change the PATH of course on Dcore (and pet2deb accordingly) but that would mean that you need to modify standard system config files e.g. /etc/profile.


Not sure to understand what you mean by "clashing". Replacing files accidentally in /usr/local/bin ?
If a script with the same name would be in /opt/bin and suppose /opt/bin is the first in PATH it would "clash" also IMO.

Fred

Hi Fred,

You have put XenialDog together, so it is up to you, but personally I think the PATH issue needs to be revisited so this is a long answer.

Short answer, I think pet2deb would be best using /opt and that should be added to end of PATH (for lowest priority) and with /opt/local coming first in that opt-related list. Of course a relatively minor mod to pet2deb could have the directory (/usr/local or /opt) as a variable near the top for installer to modify if wanted.
---------------------------

The problem with a utility like pet2deb is that we do not know beforehand if the dotpet is self-contained (i.e. having libraries included, and not being standardised different dotpets could include different compiles of same libraries). Basically a dotpet is a tar.gz file, so on the whole would normally be installed into /opt (despite us repackaging it in a 'non-official' deb).

Certainly, official debs will store into the main hierarchy of /, /usr, /usr/lib, /usr/bin, /usr/sbin, /lib, /bin, /sbin etc., so should be okay in terms of not overwriting apps in /local, /usr/local etc hierarchy. But since these are in the PATH and /local, /usr/local hierarchy may well have higher priority (more local, nearer to the user, the more likely to be given higher priority by system designer - same with config files). /opt on the other hand is usually not in PATH by default and, according to my researches, usually added with least priority using:

Code: Select all

PATH=$PATH:~/opt/bin

i.e. at the end of PATH.

Actually, If using opt, I would add /opt hierarch (most local parts first. e.g. /opt/local/sbin:/opt/local/bin:/opt/sbin:/opt/bin) to the end of that.

Best community agreed answer I could find was here:

http://askubuntu.com/questions/34880/us ... xt-of-a-pc

/opt is for third-party applications that don't rely on any dependencies outside the scope of said package. /usr/local is for packages installed on this machine outside the scope of the distribution package manager.

An example:

An open source sip-client supplied as a .deb would install into /usr. If it was built with the Qt framework, apt would pull it in as a dependency.

The same open source sip-client built from source would reside in /usr/localso it would not be messed up by apt if you later installed a .deb package for the same application. You could either build its dependencies from source, or get them from the package manager.

A third-party application in /opt is supposed to be self-contained. For instance, a proprietary sip-client using Qt would not rely on the version from apt, but would have it bundled or statically linked in.

For more information, take a look at the Filesystem Hierarchy Standard

--------------------------


Also, the PATH for 'all users' is 'normally' put in /etc/environment but that is read by PAM system (pam_env.so), which I don't think DebianDog uses? (I'm in tinycore at the moment). Tiny Core does set PATH in /etc/profile. However, I think, if no PAM available, it would be nicer to do it from /etc/profile the way I saw on superuser.com by contributor Daniel Beck, which still reads it from /etc/environment:

https://superuser.com/questions/339617/ ... -rebooting

Code: Select all

For the current shell session, you can use for line in $( cat /etc/environment ) ; do export $line ; done, if the file format is key=value. – Daniel Beck♦ Sep 25 '11 at 11:38 

Should also take sudo into account though as described here:
http://askubuntu.com/questions/128413/s ... -root-sudo

Since sudo by itself is generally configured to give a limited higher-security PATH, you sometimes need to use sudo su - to get root user's PATH with it.


In tiny core dCore, most main (official debian-sourced) apps are stored in /, /bin, /usr/bin etc hierarchy and cat /etc/environment contains:

In tiny core (dCore) it ends up having the following in /etc/profile for Bourne-type shells:

Code: Select all

PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

and then in ~/.profile tiny core (dCore) has:

Code: Select all

# ~/.profile: Executed by Bourne-compatible login SHells.
#
# Path to personal scripts and executables (~/.local/bin).
[ -d "$HOME/.local/bin" ] || mkdir -p "$HOME/.local/bin"
export PATH=$HOME/.local/bin:$PATH

It is common to set the user's own bin directory with highest priority by means of their default-provided ~/.profile as follows (e.g. from Linux Mint .profile), which will not be read at all if .bash_profile is created:

Code: Select all

if [ -d "$HOME/bin" ] ; then
  PATH="$HOME/bin:$PATH"
fi

Cheers, William

[mcewanw]

Fred,

Note that in your pet2deb:

Code: Select all

ifpet=`echo "${FILE##*.}"`

can be more simply written as:

Code: Select all

ifpet="${FILE##*.}"

Actually, I'm too busy re-writing pet2deb for my own tinycore dCore needs to test the above...

William