Puppy Linux Discussion Forum

Read all about it here:

https://bkhome.org/news/202104/easyos-d ... eased.html

I have given it limited testing, but it is looking good!

I used the update icon to update from version 2.7 to 2.7.1 - It went well.
The old easy-2.7-amd64.img.gz file was offered in the working directory for the update.

One point to mention: if you boot via 'grldr' you need to save your old menu.lst and menu-advanced.lst some were for later use.

My Samsung SCX-3405 printer works fine with this version of Dunfell; all I had to add was the SCX-3400_series.ppd and rastertospl filter.
williwaw's Samsung ML-2010 printer should work too, using the foomatic-rip filter.

Bought two 32GB USB sticks to run Linux on them. - How did it go? -
Well, as soon as you add a Linux partition to them the sticks becomes slow, very very slow.
I'm patient, but I was ready to throw them in the bin!

No, I am not appose to Taiwan, but those sticks are no good.
'Innostor Technology Corporation Disk 3.0 USB'
They come with type: c win95 (lba) format
As long as you don't touch this format they are fine!

Hi!
No problem for the update to 2.7.1 (French version). Only a small problem with the icons that I had changed and which returned to the original ones. Everything was settled quickly via the JWM manager. Thanks Barry for the great job!

Bye!

FeodorF wrote: Tue Apr 20, 2021 6:25 pm

My Samsung SCX-3405 printer works fine with this version of Dunfell; all I had to add was the SCX-3400_series.ppd and rastertospl filter.

2.7.1 already has /usr/bin/rastertospl

What I am keen to know, does the foomatic db have the ppd for your printer, and secondly, will it work without /usr/lib/libscmssc.so?

And that SCX-3400_series.ppd, does that require that library?

Hi Barry,

started from scratch with a new frugal install. With the foomatic driver, and my Samsung ML-2010 installs without complaint in cups.

I then deleted my printer in cups and deleted /usr/lib/ibscmssc.so

reinstalled my printer with my user supplied ppd, and needed to also resupply rastertospl before I got to a "filter failure'
restored /usr/lib/ibscmssc.so, reprinted the job and I now have two ways to make this samsung work. only need one I suppose....

One reason I started from scratch with a new frugal install by downloading instead of updating, is that updating seldom works for me. I am pretty sure its something to do with my connection, as almost all my downloading from ibiblio seems to grind to a halt before failing. Multiple tries are needed with the download manager in seamonkey usually. The download manager in seamonkey at least lets me monitor the process, or the lack of it.
Should you find an occasion to revisit your update script, would it be feasible to direct the progress of rsync to the terminal? When I use rsync for backups, it can be quite verbose and informative.

Trying to use dunfell 2.7 to create a new dunfell frugal install is not possible for me if I wish to mount easy-2.7.1-amd64.img by clicking on the icon prior to copying the contents to my new directory. The previous gunzip step seems to run without issue, but the decompressed .img is as shown below, and unlike the icon seen in buster. What arguments to mount are called with the clicking of an .img?

FeodorF wrote: Tue Apr 20, 2021 6:25 pm

No, I am not appose to Taiwan, but those sticks are no good.
'Innostor Technology Corporation Disk 3.0 USB'
They come with type: c win95 (lba) format
As long as you don't touch this format they are fine!

I have found SanDisk Ultra to be very reliable and fast.
Or the much faster SanDisk Extreme.

I have 3 of those Innostor brand. Originally 4, but one failed. They have been OK for me, and reasonably fast. USB3.
Purchased them a few years ago -- just checked my blog, they were purchased in 2017.
Can't recall what they were originally formatted as.

Did get an email from someone who said they are very unreliable, but my remaining 3 have been ok.

But I only buy the SanDisk sticks now.

williwaw wrote: Wed Apr 21, 2021 12:12 am

reinstalled my printer with my user supplied ppd, and needed to also resupply rastertospl before I got to a "filter failure'
restored /usr/lib/ibscmssc.so, reprinted the job and I now have two ways to make this samsung work. only need one I suppose....

Thanks for testing. That's interesting. Running ldd:

# ldd /usr/bin/rastertospl
	linux-vdso.so.1 (0x00007fff76bec000)
	libdl.so.2 => /lib/libdl.so.2 (0x00007f188c7bb000)
	libcups.so.2 => /usr/lib/libcups.so.2 (0x00007f188c725000)
	libcupsimage.so.2 => /usr/lib/libcupsimage.so.2 (0x00007f188c720000)
	libc.so.6 => /lib/libc.so.6 (0x00007f188c571000)
	/lib64/ld-linux-x86-64.so.2 => /lib/ld-linux-x86-64.so.2 (0x00007f188c7db000)
	libgnutls.so.30 => /usr/lib/libgnutls.so.30 (0x00007f188c3ac000)
	libz.so.1 => /lib/libz.so.1 (0x00007f188c393000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x00007f188c371000)
	libm.so.6 => /lib/libm.so.6 (0x00007f188c235000)
	libidn2.so.0 => /usr/lib/libidn2.so.0 (0x00007f188c212000)
	libunistring.so.2 => /usr/lib/libunistring.so.2 (0x00007f188c08b000)
	libnettle.so.7 => /usr/lib/libnettle.so.7 (0x00007f188c051000)
	libhogweed.so.5 => /usr/lib/libhogweed.so.5 (0x00007f188c018000)
	libgmp.so.10 => /usr/lib/libgmp.so.10 (0x00007f188bf9d000)

It doesn't need libscmssc.so.
But perhaps it loads that library after it is running. There are some utilities that do that, so the library doesn't show up when run ldd.

Barry,
just rebooted, deleted /usr/lib/ibscmssc.so, and printer works fine without it using foomatic. To clarify my post above, the foomatic bd includes the driver for the ML-2010, but when using my own driver, I also had to add rastertospl to /usr/libexec/cups/filter in spite of it being present in /usr/bin.

williwaw wrote: Wed Apr 21, 2021 12:37 am

Barry,
just rebooted, deleted /usr/lib/ibscmssc.so, and printer works fine without it using foomatic. To clarify my post above, the foomatic bd includes the driver for the ML-2010, but when using my own driver, I also had to add rastertospl to /usr/libexec/cups/filter in spite of it being present in /usr/bin.

Thanks for that, very interesting information!

It looks like I can save space by just including /usr/bin/rastertodpl, leave out /usr/lib/libscmssc.so.

Putting rastertospl into /usr/libexec/cups/filter, now that is curious!

Just using foomatic, without your driver, does it still work if rastertospl is moved to /usr/libexec/cups/filter? That is, removed from /usr/bin

Found out here:

https://askubuntu.com/questions/512046/ ... ups-filter

Yes, it should be at /usr/lib/cups/filter (which is a symlink to /usr/libexec/cups/filter). I put it in the wrong place. OK, I shall fix the 'printer-samsung-driver' PET.

williwaw wrote: Wed Apr 21, 2021 12:12 am

One reason I started from scratch with a new frugal install by downloading instead of updating, is that updating seldom works for me. I am pretty sure its something to do with my connection, as almost all my downloading from ibiblio seems to grind to a halt before failing. Multiple tries are needed with the download manager in seamonkey usually. The download manager in seamonkey at least lets me monitor the process, or the lack of it.
Should you find an occasion to revisit your update script, would it be feasible to direct the progress of rsync to the terminal? When I use rsync for backups, it can be quite verbose and informative.

update worked for me today. Something going on with ibiblio, or possibly between my connection and ibiblio?

as a test, I tried to download an easy.img.gz from ibiblio. Multiple tries failed in seamonkey. Ok bad connection or service you might think? except when downloading the same easy.img.gz concurrently from both ibiblio.org and nluug.nl, the nluug downloaded up to 10 times faster, and did not fail.

Hi williwaw,

have you tried drag and drop instead of the download manager?

FeodorF,

dragging the link to rox, and having rox use wget works quite nice. As you can see from the pic below, today, on my system, nluug is slower than ibiblio. My issue is that connections get dropped while downloading. I realize that the problems are mine and not the fault of Easy. Never the less, without some feedback from rsync, when the connection fails, it is hard to tell if the update script fails or what is happening. Not really a big issue, I only posted as a follow up to my previous post.

Maybe of more concern to Barry, is the loss of being able to mount my .img in dunfell once it is gunzipped by left clicking in rox. Not sure if rox is broken for just me, or in dunfell.

other wise, I found this https://oldforum.puppylinux.com/viewtop ... 41#p233641 which seems to indicate I need to use losetup in addition to the mount command..... or perhaps it is easier to boot into easy buster to create a frugal install

@BarryK,
Somewhere between 2.6.1 and 2.7.1 I seem to have lost sound via my dell desktops headset connections while the speaker connections at the rear are perfectly ok still. These dell optiplex use separate interfaces for each set and while 2.6.1 works happily still, the new 2.7.1 gives nothing via the front headset interface. Any sugestions where to start looking?

williwaw wrote: Thu Apr 22, 2021 7:39 pm

Maybe of more concern to Barry, is the loss of being able to mount my .img in dunfell once it is gunzipped by left clicking in rox. Not sure if rox is broken for just me, or in dunfell.

Oh dear, you are right, it is broken.

Dunfell is using a later shared-mime-info package, and easy-2.7.1-amd64.img is showing as mime type application/x-raw-disk-image.

shared-mime-info is supposed to detect that it is a special EasyOS image file, and set mime type to application/easy-disk-image

Hmmm, the entry that causes this special behaviour is /usr/share/mime/packages/puppy.xml:

  <mime-type type="application/easy-disk-image">
    <comment>Easy Linux disk image</comment>
    <glob pattern="easy-*.img"/>
  </mime-type>

...which is supposed to override the default for .img files.

I am wondering if the later version of shared-mime-info has changed its behaviour and won't allow the override. looks like that's the case. Will investigate further...

BarryK wrote: Fri Apr 23, 2021 10:36 am

williwaw wrote: Thu Apr 22, 2021 7:39 pm

Maybe of more concern to Barry, is the loss of being able to mount my .img in dunfell once it is gunzipped by left clicking in rox. Not sure if rox is broken for just me, or in dunfell.

Oh dear, you are right, it is broken.

Dunfell is using a later shared-mime-info package, and easy-2.7.1-amd64.img is showing as mime type application/x-raw-disk-image.

shared-mime-info is supposed to detect that it is a special EasyOS image file, and set mime type to application/easy-disk-image

Hmmm, the entry that causes this special behaviour is /usr/share/mime/packages/puppy.xml:

Code: Select all

  <mime-type type="application/easy-disk-image">
    <comment>Easy Linux disk image</comment>
    <glob pattern="easy-*.img"/>
  </mime-type>

...which is supposed to override the default for .img files.

I am wondering if the later version of shared-mime-info has changed its behaviour and won't allow the override. looks like that's the case. Will investigate further...

Until I fix it, you can open it up from the commandline:

# filemnt easy-2.7.1-amd64.img

...but clicking on it again doesn't unmount it, you have to do that manually also

Run this to confirm which loop device is being used:

# mount

If it is loop2:

# sync
# umount /dev/loop2

A bit of "progress"...

/usr/share/mime/packages is where you can place custom mime definitions.

/usr/share/mime/globs gives a hint what is going wrong. Ah...

# grep 'disk-image' *
freedesktop.org.xml:  <mime-type type="application/x-raw-disk-image">
freedesktop.org.xml:    <glob pattern="*.raw-disk-image"/>
freedesktop.org.xml:  <mime-type type="application/x-raw-floppy-disk-image">
freedesktop.org.xml:    <sub-class-of type="application/x-raw-disk-image"/>
freedesktop.org.xml:  <mime-type type="application/x-raw-disk-image-xz-compressed">
freedesktop.org.xml:    <glob pattern="*.raw-disk-image.xz"/>
freedesktop.org.xml:    <sub-class-of type="application/x-raw-disk-image"/>
puppy.xml:  <mime-type type="application/easy-disk-image">
# 

/usr/share/mime/packages/freedesktop.org.xml is the culprit.
I might substitute for the freedesktop.org.xml in Easy Buster, which doesn't have that conflict.