Xenialpup64 CE 7.5 / 25 Nov 2017

[rek769]

Now that XP64 is working well for me and is setup the way I want it, I have decided to boot the system from CD rather than the dd-ed flash drive I had been using.

When booting from CD, I keep my savefile inside a directory on my hard drive (1 level deep). This method has worked well for me since the Lucid days. However, I've found that when booting from the CD with XP64 that my savefile is not automatically discovered.

In order to force it to find my save file I had to add this to the isolinux.cfg file, remaster, and then re-burn the CD: psubdir=xenial_64
(where xenial_64 is the name of the subdirectory on my hard drive that contains my savefile.)

I've never had to take this step before and wanted to let it be known that this may be an issue.

Thanks

[Lassar]

I have found that kodi will update okay on xenialpup 32 bit.

But on xenialpup 64 bit, it will fail.

Now in order to see this error, install creation.org, then update from local cache.

Then upate from the creation.org repository.

Now all updates will fail.

I took a look at DISTRO_PKGS_SPECS-ubuntu-xenial, but am not familiar enough with the differences between xenial 64 & xenial 32 bit, to be able to guess, at what causes this error.

Xenial 32 has pwsget & xenial64 doesn't, but I really doubt that causes the error.

.

[rcrsn51]

I've never had to take this step before and wanted to let it be known that this may be an issue.

This sounds familiar. There may have been a deliberate change to the init system that limits how deeply Puppy will look for its savefile.

[Lassar]

For kodipup lite, I had been looking for stuff to cut out.

A prime candidate is libLLVM-3.8.so.1, coming in at 42 megabytes.

From what I read, this library is for compiler related stuff.

Why does a normal puppy even need this?

Should this not go into devx_xenialpup64_7.0.8.5.sfs, instead?

If parts of this library is needed, I bet it could be edited, and recompiled, and made into a pet.

Come on, 42 megabytes for a library!

[peebee]

For kodipup lite, I had been looking for stuff to cut out.

A prime candidate is libLLVM-3.8.so.1, coming in at 42 megabytes.

From what I read, this library is for compiler related stuff.

Why does a normal puppy even need this?

Should this not go into devx_xenialpup64_7.0.8.5.sfs, instead?

If parts of this library is needed, I bet it could be edited, and recompiled, and made into a pet.

Come on, 42 megabytes for a library!

It's needed for video drivers....
It is cut down in 2createpackages by it's package-template llvm-cut - but its entry in DISTRO_PKGS_SPECS-slackware-** must be called llvm-cut....

[Lassar]

It is cut down in 2createpackages by it's package-template llvm-cut - but its entry in DISTRO_PKGS_SPECS-slackware-** must be called llvm-cut....

Could you expand on this in a little more detail?

[Sailor Enceladus]

@Lassar: Try deleting the file(s) /usr/lib/libLLVM*, then running this in the terminal:

checkdeps /

A few minutes later, you should get something like what I got in Slacko 6.9.9.9:

Code: Select all

/usr/lib/d3d/d3dadapter9.so.1.0.0
	libLLVM-3.8.so => not found

/usr/lib/dri/gallium_drv_video.so
	libLLVM-3.8.so => not found

/usr/lib/libLTO.so
	libLLVM-3.8.so => not found

/usr/lib/libXvMCnouveau.so.1.0.0
	libLLVM-3.8.so => not found

/usr/lib/libXvMCr600.so.1.0.0
	libLLVM-3.8.so => not found

/usr/lib/libxatracker.so.2.3.0
	libLLVM-3.8.so => not found

/usr/lib/vdpau/libvdpau_nouveau.so.1.0.0
	libLLVM-3.8.so => not found

/usr/lib/vdpau/libvdpau_r300.so.1.0.0
	libLLVM-3.8.so => not found

/usr/lib/vdpau/libvdpau_r600.so.1.0.0
	libLLVM-3.8.so => not found

/usr/lib/vdpau/libvdpau_radeonsi.so.1.0.0
	libLLVM-3.8.so => not found

/usr/lib/xorg/modules/dri/kms_swrast_dri.so
	libLLVM-3.8.so => not found

/usr/lib/xorg/modules/dri/nouveau_dri.so
	libLLVM-3.8.so => not found

/usr/lib/xorg/modules/dri/r300_dri.so
	libLLVM-3.8.so => not found

/usr/lib/xorg/modules/dri/r600_dri.so
	libLLVM-3.8.so => not found

/usr/lib/xorg/modules/dri/radeonsi_dri.so
	libLLVM-3.8.so => not found

/usr/lib/xorg/modules/dri/swrast_dri.so
	libLLVM-3.8.so => not found

/usr/lib/xorg/modules/dri/vmwgfx_dri.so
	libLLVM-3.8.so => not found

/usr/lib/xorg/modules/drivers/vmware_drv.so
	libLLVM-3.8.so => not found
	libLLVM-3.8.so => not found

I think if you delete libLLVM-3.8.so, you can also delete all these drivers since they won't work properly any more (I could be wrong though). I didn't seem to need libLLVM-3.8 or any of those drivers on the 3 older computers I tried, so a pet might work.

[peebee]

It is cut down in 2createpackages by it's package-template llvm-cut - but its entry in DISTRO_PKGS_SPECS-slackware-** must be called llvm-cut....

Could you expand on this in a little more detail?

Look in:
woof-out_***/packages-templates/llvm-cut

or on github:
https://github.com/puppylinux-woof-CE/w ... s/llvm-cut

entry in DISTRO_PKGS_SPECS should be:
yes|llvm-cut|llvm|exe,dev>null,doc,nls

[slenkar]

how does one install opera on xenial64?

Doesnt seem to be in repo.
.deb from the website doesnt seem to do anything.

[riedzig]

If you mean the new Opera 46, download the .rpm file from opera.com, extract it and just run /usr/bin/opera

[bigpup]

how does one install opera on xenial64?

Doesn't seem to be in repo.
.deb from the website doesn't seem to do anything.

If you downloaded the .deb and left clicked on it to install.
It may not have made any menu entries.
Open a console/terminal.
Type:

Code: Select all

opera

If it does not run.
What do you get for errors?

[slenkar]

I installed opera-stable_46_amd64.deb

when typing opera into the terminal it says it doesnt exist,
also cant find it in usr/bin or with a file search

do you want me to try the .rpm file?

[mikeslr]

Hi slenkar,

deb, rpm - same difference. Both these packages are designed for an operating system which is truly multi-architecture. Puppies built from Ubuntu binaries aren't. When you install or unpack debs or rpms, you'll find that they locate some lib files in /usr/lib/x86_64-linux-gnu and/or /usr/local/lib/x86_64-linux-gnu. Puppies can't find those libs. The workaround is to unpack the deb or rpm and move those libs to /usr/lib or usr/local lib, respectively.

I run opera from /mnt/home where I unpacked, I think, the package ending in tar.gz or tgz. To run it, I installed a "handmade" pet. . But you can skip the pet creation part and simply include its 3 files. One is just an opera icon (png) which I placed in /usr/share/pixmaps. The second was a desktop file placed in /usr/share/applications --this creates a menu listing. Mine, named opera.desktop, reads:

[Desktop Entry]
Encoding=UTF-8
Name=Opera64 web browser
Icon=/usr/share/pixmaps/opera.png
Comment=Opera from /mnt/home/Pup-Apps
Exec=/root/my-applications/bin/opera64
Terminal=false
Type=Application
Categories=X-Internet
GenericName=Opera web browser

Note the Exec argument. Puppy expects executables/binaries to be "on the Path" -- which means within any "bin" or "sbin" folder. The one in /root/my-applications/ was especially constructed for, and is peculiar to, Puppies. A more common location in Linux would be /usr/local/bin.

The Exec argument points to the third file. It's a bash script "on the path". You create them by right-clicking an empty space and selecting New>script, and giving it a name such as opera64. You then open it in geany/text editor

Mine reads:

#!/bin/sh
exec /mnt/home/Pup-Apps/opera64/usr/lib/x86_64-linux-gnu/opera/opera "$@"

The first line is created for you. The second you have to do yourself, being careful to accurately point to the executable --the last "opera" of the line-- by providing the entire path, properly spelled. Exec says its an executable; and my guess is that somehow "$@" got to mean "do it". After creating the script, make sure it's executable. Right-Click it, select "Properties" and make certain all the boxes in the Exec column are checked.

You can unpack the tgz/deb/rpm anywhere. A common place is /opt. That's where Chrome and its clones folders are found. But be sure that the bash script accurately point to wherever the executable will be found.

Since all other files relating to opera are within one folder --that named opera-- Puppies don't have to search far and can find all the libs.

But an easier solution is to use either the pet or sfs Mike Walsh built of Iron. You'll find them here: https://yadi.sk/d/_S5b4g7tpcyZn. Take it from a long-time opera fan. It's just a better program.

mikesLr

[slenkar]

i unpacked the deb as per your suggestion and found all those files that failed to install, then i was able to create the menu item
thanks!

[Lassar]

In my quest, to get kodi to handle addon updates, in xenialpup64, I found a bug.

What made me suspicious, is I got updates to work, after creating a new folder, and copying the guts of the .kodi folder into it.

Deleted the old .kodi folder, and rename the new folder to .kodi.

After I did this, addon updates would work.

In researching this problem, I found a web page, that says file attributes do not copy over, from the source to target.

Which explains, why the copying, from the .kodi folder to the new folder worked.

I went to the terminal and typed lsattr /root.

I got "Inappropriate ioctl for device While reading flags on ..." every file and folder as far as I can tell.

Xenialpup64 cannot handle lsattr, and I bet chattr either.

Definitely a bug.

[Sailor Enceladus]

I went to the terminal and typed lsattr /root.

I got "Inappropriate ioctl for device While reading flags on ..." every file and folder as far as I can tell.

Xenialpup64 cannot handle lsattr, and I bet chattr either.

Definitely a bug.

I guess lsattr is designed to tell you where you are on real disk drives? It works for me on /mnt/sda2 (which is ext4). Interestingly, it also worked if I navigated through sda2 into my actual save folder (rather than /).

[Mike Walsh]

Evening, all.

Well, now; I've got one here that's never happened to me before.

I've just installed Xenialpup64 7.0.8.5 this evening, and to start with everything was behaving itself beautifully. First shutdown and created the save-folder; then updated the PPM and set up the basics; rebooted again, to make certain everything had 'taken' (which it had).....and then started the long process of installing everything, and customising all to my liking.

I'd almost got Xenialpup just how I wanted it, when I noticed that all of a sudden, 'X' wasn't responding. Desktop entries would 'blink' when clicked on, but nothing was happening. Ditto for the Menu; it would come up, but upon clicking on entries, nothing would respond. Strangely, what few things I'd got in the tray were behaving themselves as normal...

For the first time ever, I had to use Ctrl+Alt+Backspace to shut down, as even the Shutdown dialog box refused to appear. Upon re-booting, I had a fairly strong suspicion what was going to happen, and, sure enough, 'X' refused to start.

Typed 'xwin'; nothing. Tried 'xwin jwm'; ditto. 'Xwin -default' met with an equal lack of success. So I ran 'xorgwizard', and reset to the default xorg.conf.....and still nothing.

I'd almost suspect that the graphics chip in this 13-yr old desktop PC had finally given up the ghost, were it not for the fact that I'm currently typing this from Tahr64 on the same machine, which is running as sweet as a nut. Every other Pup is behaving itself, too, as far as I can tell....

So, dear friends; any ideas? Is this a 'bug' in the newest version of XenialPup? I deleted Slacko64 6.3.0 to install Xenialpup64, 'cos the newest 'beta' versions of Chrome are now refusing to run in Slacko (GTK 3.0 version isn't new enough, and I can't find a newer version anywhere.....6.3.0 is based on Slackware 14.1, which is now considered 'out of date', apparently.)

I've always had success with the 'buntu-based Pups, hence trying out Xenialpup.....but this is baffling me. Any help would be very much appreciated!


Mike.

[mikeslr]

Hi Mike,

You wrote, in pertinent part:

I've just installed Xenialpup64 7.0.8.5 this evening, and to start with everything was behaving itself beautifully. First shutdown and created the save-folder; then updated the PPM and set up the basics; rebooted again, to make certain everything had 'taken' (which it had).....and then started the long process of installing everything, and customising all to my liking.
I'd almost got Xenialpup just how I wanted it, when ... nothing would respond.

First thought: something you installed spoiled your day. I'd start again from scratch. After creating a SaveFile*, kill Automatic Save. Leave customizing settings for last. After you install each application, do a manual Save. When you get to whatever it was that screwed things up, you won't be able to Save. But don't anyway. You should however be able to shutdown --even if you have to pull the plug. Reboot, skip that application and continue installing.

If all applications install OK, then customize your settings one at a time, Saving after each change.

If its one (or a couple applications) or a particular setting that's causing a problem, once it's identified, we'll figure out what to do. Once you've identified the problem application(s), or setting you can also re-build using a SaveFolder. Not sure, but I think you can create a SaveFolder if you unpack a SaveFile into a folder named xenialpupsave-xxx, maybe xenialpup64save-xxx. [I've been doing some experiments with xenialpup64, so don't have a SaveFolder at the present time].

Second thought: I have a recollection of something like that happening when I clicked the "bugfix" icon on the desktop. Do a search and see if there's a post about that; or back-track to shortly after 7.0.8.5 first appeared.

mikesLr

*I've found that on occasion things sneak into SaveFolders even with Automatic Save turned off. And unless I know it's safe, I also don't let PPM install. I set it to download to a folder on /mnt/home, then build an SFS. If its small, I'll repackage as a pet to be installed. Many apps "straight from Ubuntu" have to be restructured anyway. Xenialpup64 can't find libs which Ubuntu places in various directories named x86_64-linux-gnu.

[Mike Walsh]

Mornin', Mike.

TBH, I've got a pretty fair idea of what 'screwed things up'. I'm almost 100% certain it was 'lm-sensors' that's responsible.... (little bugger! Grrrr...) It was the very last thing I installed (pSensor uses it), and there'd been a break of at least half-an-hour prior to that while I was doing something else (at which point she was still behaving herself nicely...)

I'm going to re-do from scratch, anyway.....and I might well revert to a save-file, too; you're right, you do get more control with them, as the save-folder auto-saves whether you want it to or not. However, I'll possibly go back a couple of releases; 7.0.8.1, or 7.0.8.4. What d'you reckon?

(Y'know, despite trying out these newer, 64-bit Pups ('cos that's the direction Puppy seems to be heading!), I still find Micko's classic 570 one of the most stable Pups in my kennels. So it's 4 years old, and only 32-bit.....so what??

Tell me something, Mike; can you change 'Pup-mode' between sessions (and will the change actually stick)?


Mike.

[artsown]

@ Mike Walsh

I've been using lm-sensors and psensor on xenialpup64 7.0.8.5 for
quite some time now without problems. I monitor core temps and
hard drive temp (HDDTEMP), and have temp limits set to alarm.

Also, my wife is using xenialpup64 7.0.8.5 on a daily basis where she
gives it a good pounding on facebook. For our purposes, this pup has
been reliable. The only problem has been palemoon which is still not
good for intensive use by social media users. The latest versions of
Waterfox, Firefox with pulseaudio and a script wrapper, and ... thanks to
your SFS ... Google Chrome .... all run reliably under intensive use in our
experiences here.

Hope this helps, and thanks for your SFS

Art