Mime handler for .tar.xz

No comments
Binary packages created in OE are in .tar.xz format. Currently, when you click on such a file in ROX-Filer, it opens in Xarchive (an archive manager).

Contrast that with say, a .pet package. Click on that, and 'petget' runs, with an offer to install it.

I have created a new script, /usr/local/bin/pkghandler, that is launched when someone clicks on a file of mime-type application/x-xz (a *.tar.xz file), and analyses whether it is a binary package or source code.

If a binary package, a window pops up asking if want to install or open in Xarchive. If not a binary package, opens immediately in Xarchive.

This is very nice. Now, if you have downloaded a .tar.xz binary package, just by clicking on it, you get to choose whether to install, or view the contents with Xarchive.


SNS buglets fixed

No comments
SNS is my Simple Network Setup.

Thanks to Philh who posted about showing wifi networks in order of field strength:
http://murga-linux.com/puppy/viewtopic.php?p=955250#955250

I implemented that. But, I do have a list of old buglets, decided to tackle those. Stuff like:

1. Right-click on tray icon, chose "Disconnect from network", but it doesn't. Not always anyway.
2. Click on a button to delete a network connection profile, sometimes not deleting.

I fixed those also. The modified scripts are /usr/local/simple_network_setup/rc.network and sns.
The woof-CE guys would probably be interested in these fixes, except that they have probably diverged the scripts from mine somewhat by now.

Anyway, my fixed scripts will be in the next release of Quirky or Easy, if they want to examine them.

I noticed a recent post, someone wanting SNS to do static address setup, not using dhcpcd. Yeah, that has been on my to-list for a very long time.


More xorg drivers for Pyro64

1 Comment
Quirky Pyro64 0.2 was uploaded yesterday. It only has the intel, vesa and modesetting xorg drivers, so apart from some acceleration provided by the kernel gpu drivers, only intel has hardware acceleration for xorg.

I have now compiled:
xf86-video-nouveau
xf86-video-ati
xf86-video-amdgpu


That is going to cover a lot more video cards out there.

When running Xine media player, launched from a terminal (run "xinewrapper"), it complains that libvdpau-va-gl.so cannot be found so disabling vdpau support.

Now, I recall several months ago, in Quirky Xerus64, putting in that library, and vdpau did not work at all.

Anyway, giving it another go. Have compiled:
libvdpau-va-gl

This will all be in the next Pyro64 (and Easy) linux.

It will probably be necessary to make up a pet package with firmware for amd gpu's. Though, that can bulk up the build very quickly. LFS has firmware here:
http://anduin.linuxfromscratch.org/BLFS/linux-firmware/


wget, aaaargh!

No comments
I was fixing a couple of bugs in the package manager, PPM.

I compiled 'vim' in OE, and added it to the online package repository in ibiblio.org. Then I used the PPM to download and install it, to test all that is working ...which it isn't.

For a start, the "Update database" button was broken. Fixed that.

Then chose 'vim', but it failed to download.

I discovered the reason. The latest release of wget, 1.19.1, no longer logs to stderr, instead to ~/wget-log*

A quick google, this chap has hit the same problem:
https://www.makemkv.com/forum2/viewtopic.php?f=3&t=15885

I have at least two scripts, probably more, that are now broken. For example "wget .... 2>&1 | .... " or "wget .... 2> logfile" no longer work.

In the latter case, you have to use the "-o" to direct output to a particular logfile. I don't know what to do in the first case, where want to pipe it.

wget has been around since the beginning of time, why make such a fundamental change now? I sent a very polite email to the wget-bugs mail list, asking why.

In the OE build, I have rolled back to wget 1.17.1. This is the same version used in Ubuntu 16.04. In OE, it was easy-peasy to rollabck, I just grabbed the recipe from the "krogoth" release.

In OE:
# bitbake -c clean wget
...then put in the new recipe, in my 'meta-quirky' layer, then...
# bitbake wget

Then, over in woofQ:
# ./0pre-oe-add

...which detects the changed versions in OE, and deletes the old one, imports the 1.17.1 binary tarball.

Oh yeah, vim. It started out early this morning, I compiled vim in OE and imported it to woofQ. Then got distracted by this wget stuff. Now it is 11am.
I want vim as it can convert syntax-highlighted code to HTML output, great for putting code into web pages.

if you want vim for the new Quirky Pyro64, it is here (6MB):
http://distro.ibiblio.org/quirky/quirky6/amd64/packages/oe/pyro/vim-8.0.0427-r0-core2-64.tar.xz

If you download and click on it in Pyro64, Xarchive will open. The mime handler does not (yet) recognise *.tar.xz as possible being a package to install.
Instead, open a terminal where you downloaded it, and run:
# petget `pwd`/vim-8.0.0427-r0-core2-64.tar.xz


Easy Linux returning

No comments
I designed Easy Linux early in 2017, a radical rethink of how Linux works, a new paradigm even.

Version 0.2 pre-alpha was released on the 17th of March 2017, see blog announcement:
http://barryk.org/news/?viewDetailed=00515

...there is a link to a web page that outlines the architecture.

There was some great feedback on the Puppy Forum, however, I got diverted, worked on compiling everything in OpenEmbedded. That has reached a milestone, have compiled almost ever package needed by Quirky/Easy, and wrote a script to import the binary packages into woofQ.

Have just built Easy 0.2.1 with the packages from OE, using it now. Works great.

Now I am back on developing Easy. The first thing that I plan to do is simplify the loading of sfs files. This was an area of difficulty reported in the forum.
I know what to do to make that super-easy. Will do so and build a new version for release.


Pages: [1] [2] [3] [4] [5] ...