(old)Puppy Linux Discussion Forum

Iguleder wrote:(...)

musher0 wrote:Works ok here.

Are you sure about that?
(...)

Yep! Squished the old db-something you worked on with the new one
in /usr/local/petget, like you said.

Then tested updating the entire trisquel db of progs. Result ok.
Then tested download/installation of speedcrunch with PPM. Result ok.
No fault, no segfault, works a breeze.

Hello all.

Re: the lm-sensors package acting funny in LibrePup.

The pic below was obtained from a script in PPrecise-5.4.3 using the lm-
sensors package provided with the CPU-temp-1.7 package assembled
by our colleague rscrn21.

What do we see? At least two of the three results come from proprietary
drivers: i2c / radeon.

With whatever package of lm-sensors, whether /etc/modules is a file or
a folder, it won't work. The problem is way upstream: the ROMS are
proprietary, and LibrePup not having any proprietary thingy... The logic
of this hits you like a slap in the face.

Shucks, I'll have to rework my pekwm script to take this into account:
something like "skip the menu line if no temperature results".

BFN.

Iguleder wrote:(...)

musher0 wrote:Works ok here.

Are you sure about that?
(...)

Hi, Iguleder.

Second take on this:
Have the other guys checked || defrag'ed their partitions recently? This
is not a WhineDose joke: defrag happens on Linux filesystems too;
more slowly, but it happens.

A partition with many scattered "extents" can provoke segfaults out of
nowhere. Defrag that /root/.packages folder, fsck that pupsave, and the
segfault error might just go away. It may not, but one should check the
possibility of disk fragmentation before starting to chop code. The PPM
process is disk-intensiive, it is more likely than other apps to divide the
files it uses in multiple "extents".

Any frequently used db presents a frag risk: a large opera bookmarks
file, for example. As well, most of the members on this thread are
developers and testers, which usually means heavy use of a partition.

My 2¢.
~~~~~~~~

While I'm on the subject, this is one thing I appreciate about LibrePup:
it does an fsck of the home partition at every boot, in addition to the
pfix=fsck option for the pupsave.

Keep in mind that even if your partition has a frag rate of 0.5%, which
means your fs is speedy and healthy, that 0.5% fragmentation may be
caused by the big db file you're using all the time. A very tough
problem, that.

BFN.

musher0

It has nothing to do with file systems. I compared the old and new debdb2pupdb side-by-side and with tmpfs, so no disk was involved

Iguleder wrote:It has nothing to do with file systems. I compared the old and new debdb2pupdb side-by-side and with tmpfs, so no disk was involved

Well, it has to store the db it downloads somewhere! But if you say so.

The database is downloaded to /tmp as well and I ran debdb2pupdb manually to ensure zero download times.

There you go: a fixed debdb2pupdb binary.

This parser runs in two modes: either via woof-CE or via PPM. I tested only the first use case, but there was a crash that happens 100% of the time when it runs via PPM. Fixed

Still working on the find_cat replacement and it's crucial to have this thing replaced. It's the only reason why PPM's database update is so slow now.

Iguleder?

Find_cat? Phone the SPCA...

I mean if you don't believe that /root/.packages and the general trisquel
or slackware or trustythar listings needed for PPM are not somehow
stored on disk, you might as well call the spca to find a cat.

On some of my pups, ROX-Filer "properties" says the size of
/root/.packages is +/- 13 Mb's. That's proof to me of disk occupation!

But who am I talking to? The brilliant updater of PPM. Very-very weird.
(Sound effect needed here: three-note science-fiction weirdness jingle.)

BFN.

musher0

Iguleder wrote:There you go: a fixed debdb2pupdb binary.

This parser runs in two modes: either via woof-CE or via PPM. I tested only the first use case, but there was a crash that happens 100% of the time when it runs via PPM. Fixed

Still working on the find_cat replacement and it's crucial to have this thing replaced. It's the only reason why PPM's database update is so slow now.

It works fine in PPM.

Talking about PPM, besides find_cat, another 2 "crawlers" is fixmenus and indexgen.sh. Would be nice if (even some of) the endless "sed'ings" and "grep'ings" could be replaced with bash builtins that are way faster, or some other scripting magic (techno?)

musher0 wrote:Iguleder?

Find_cat? Phone the SPCA...

I mean if you don't believe that /root/.packages and the general trisquel
or slackware or trustythar listings needed for PPM are not somehow
stored on disk, you might as well call the spca to find a cat.

On some of my pups, ROX-Filer "properties" says the size of
/root/.packages is +/- 13 Mb's. That's proof to me of disk occupation!

But who am I talking to? The brilliant updater of PPM. Very-very weird.
(Sound effect needed here: three-note science-fiction weirdness jingle.)

BFN.

musher0

My apologies. The above is too emotional to be useful to this thread.

BFN.

musher0

Almost ready! Takes less than a second for the entire process, while the old one takes almost a second per package (and I have 40,000+ of them).

Yes, fixmenus is horrible too. Need to get rid of it ASAP.

There was no segmentation fault with the latest debdb2pupdb, didn't seem
to be much quicker though.
The manual frugal installation to an ext4 32gb usb-2.0 of my
custom-puppy.iso is working well.

Hello all.

What is this line doing in /etc/rc.d/rc.local? Isn't it a useless repeat of what /etc/init.d/sfs_load is already doing?
Since, according to Linux theory, everything in /etc is supposed to be
executed automatically.

This is not a criticism, it is a sincere question. I wish to know why we
would apparently be loading sfs_load twice.

I have this problem with sfs's in LibrePup: it loads its devx but not the
other sfs's -- although the boot manager says they are loaded. I have a
big sfs with java JRE and apps that loads fine in other pups but not here.
Could this double activation of sfs_load be the cause?

Or is some Trisquel script barring the load of java apps because java is
not GPL2? Probably not, since Médor's sfs of abiword 3 would not load
either. I had to "pour" its content in the pupsave to get a valid abiword 3
running. Still, an answer about tolerance of java in Trisquel or Trisquel
derivatives would be appreciated.

Thanks in advance for any leads.

Best regards.

musher0

There you go: a fixed debdb2pupdb binary.

Yes it works but there are still issues to iron out. The stuff in the screeny causes the database to appear as a 'data' file, not text.

01micko wrote:Yes it works but there are still issues to iron out. The stuff in the screeny causes the database to appear as a 'data' file, not text.

Hi 01micko

What question does this reply answer?
Thanks in advance for keeping us focused.

BFN.

musher0

@musher0, yes I fixed my previous post. Thanks.

It's ready! I committed new find_cat and debdb2pupdb binaries to woof-CE. The database update in PPM should take about 10-15 seconds now, compared to 10-15 minutes.

Put them in /usr/local/petget and tell me what you think. There's a big chance that some packages previously not shown in PPM will appear there, because the category guessing code is much smarter now.

01micko wrote:Yes it works but there are still issues to iron out. The stuff in the screeny causes the database to appear as a 'data' file, not text.

Yes, this is some weird stuff I noticed while working on find_cat. Investigating!

EDIT: fixed!

Iguleder wrote:It's ready! I committed new find_cat and debdb2pupdb binaries to woof-CE. The database update in PPM should take about 10-15 seconds now, compared to 10-15 minutes.

Wow, that is fast, took about 2 seconds to update ppm.

Iguleder wrote:

01micko wrote:Yes it works but there are still issues to iron out. The stuff in the screeny causes the database to appear as a 'data' file, not text.

Yes, this is some weird stuff I noticed while working on find_cat. Investigating!

EDIT: fixed!

Hmm.. still got the dodgy chars in trisquel database. Was fast tho and does work.

@01micko - attach the relevant parts of Packages-* files, I want to see which fields are corrupt.

Besides those small issues here and there (which I'm not worried about), PPM seems to work great. I was able to install several window managers, abrowser with plugins, etc',

@mavrothal - maybe you should change PPM's default settings, to kick those urxvt windows. The UI seems to work just fine and they kinda ruin the user experience IMHO.

@01micko, @pemasu - I fixed ca-certificates using this pinstall.sh: Now, QupZilla works out-of-the-box.

The only remaining problem I wish to fix for the next release is AbiWord, which needs to be updated to the tahrpup 3.0.0 package. For some reason 1download prefers an older package, although the Librepup repository has the highest priority and the right package.