site  contact  subhomenews

Modem -10 upgrade postponed

February 15, 2011 — BarryK
I merged rerwin's modem upgrade PETs into Woof:

pup_event_backend_modprobe_fix_to_p43x-5.9.pet
modem_fix_pack_delta-8_to_10-20110209.pet


...but then I reconsidered, and rolled back.

Merging these PETs took me a long time, as they are designed for a 431 base system. I had to study each pinstall script and examine the contents of each file in the PETs to see whether it can replace the one in Woof or in some cases I just need to edit some lines in the Woof file.

It actually took me a couple of hours to go through those two PETs. I was logging all my changes to a file, then X crashed and I lost the file as hadn't saved it for awhile. I have become complacent, as Wary is usually so stable, but the crash happened when switching s virtual desktop -- which I recall is an instability that I have encountered before.

So that cheesed me off somewhat. Then I decided that it is going to cause me some trouble as rerwin's PETs are designed for usb-modeswitch 1.1.6 whereas my zzz package has not yet been upgraded to 1.1.6. Installing my zzz PET on top of Woof with rerwin's latest updates, I saw potential problems.

Also, I want to bring out Wary 5.1RC, and this is too many changes, with potential unknown side-effects.

So, I have abandoned the work of the last two hours. Left Woof as it is.

Rerwin also has these two PETs:

usb-modeswitch-1.1.6-adapted.pet
usb-modeswitch-data-20101222.pet


The forum thread:
http://murga-linux.com/puppy/viewtopic.php?t=57290

Comments

woof stuff
Username: 01micko
Hi Barry, sorry off topic, but it is "Woof" category. Today I built a Natty version of Puppy. There are woof issues that need to be addressed with gdk_pixbuf. The libgkk_pixbuf deb package for natty is a completely different structure from anything previous. It has recently been a part of gtk+-2 but now it is separate with it's own directory with modules in /usr/lib/gdk-pixbuf-2.0/. Issue 1) The lib and dev files were not split correctly. The executable [i]gdk-pixbuf-query-loaders[/i] is now located in /usr/lib/gdk-pixbuf-2.0. It is symlinked back to /usr/bin but that symlink ended up in the dev folder. I manually moved it before I ran 3builddistro. Also gdk-pixbuf-csource executable was in the dev too, I'm not sure about that one. Issue 2) [i]gdk-pixbuf-query-loaders --update-cache[/i] needs to be run to generate a [i]loaders.cache[/i] file, /usr/lib/gdk-pixbuf-2.0/2.10/loaders.cache, (note it's not in /etc/gtk-2.0/*/) or else no images display when you boot the CD. I ran it manually, but it would need to be run near when [i]pango-querymodules[/i] is run (which incidentally was misplaced in the dev file too, I moved it manually). I guess a test would be needed for it's existence before executing. Would something like this work for execution? [i]echo "/usr/bin/gdk-pixbuf-query-loaders --update-cache" > rootfs-complete/zzzz chroot rootfs-complete /bin/ash zz rm -f rootfs-complete/zzzz[/i] Cheers (PS, posting from Natty Puppy now)

woops
Username: 01micko
"that second line should have been chroot rootfs-complete /bin/ash zzzz

re chroot
Username: BarryK
"01micko, Why can't you just do: chroot rootfs-complete /usr/bin/gdk-pixbuf-query-loaders --update-cache

chroot
Username: 01micko
"Thanks Barry BTW, that method I used did in fact work, but simpler is always better ;) Also, in woof do you think in 3builddistro we can have something like this? (at or about line 1569) [code]#110215 later versions gdk-pixbuf fix if [ -d rootfs-complete/usr/lib/gdk-pixbuf-* ];then echo "running gdk-pixbuf-query-loaders --update-cache" chroot rootfs-complete /usr/bin/gdk-pixbuf-query-loaders --update-cache fi [/code] I'll try it on the weekend. Hmm.. but I guess other distros may do things differently. Cheers

Re gdk-pixbuf-query-loaders
Username: BarryK
"Wary 503 already has that (and Woof), but in /etc/rc.d/rc.update. But, I don't have the --update-cache.

re gdk-pixbuf-query-loaders
Username: BarryK
"This is what I have: #110119 just in case something missing (like svg loader)... echo -n " pixbuf-loaders" >/dev/console gdk-pixbuf-query-loaders > /etc/gtk-2.0/gdk-pixbuf.loaders ...the path it writes to is not suitable for you.

WOOFGUI PROBLEMS
Username: scsijon
"off topic for this thread but VERY woof relevant and could not work out where else to add it. Downloaded update of woof 20110214 just went to start the woofgui and instead of getting the usual splash screen pre front woofgui screen it started running the hd at full rate. I eventually had to kill the operation to stop it and it killed my video. I reran the last version and that worked as expected. Do you have a problem? or is something been added without explanation! regards scsijon

woofgui problems part 2
Username: scsijon
"updated "bones download" tried again from wary5, same thing happened. rebooted and tried from puppy 5.2, firstrun was started this time. sorry barry but something strange happening here.

gdk-pixbuf-query-loaders: more info
Username: 01micko
"This post is mainly FYI Here's the error I got in /tmp/xerrs.log when I booted up to a grey desktop with warning symbols for every icon: [i](ROX-Filer:13462): GdkPixbuf-WARNING **: Cannot open pixbuf loader module file '/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or directory[/i] (plus many, many more lines of similar errors) There are many hits if you google just the "GdkPixbuf-WARNING **: Cannot open pixbuf loader module file '/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache'" part of the message, mostly to do with Ubuntu Lucid Lynx users updating to Maverick Meerkat via the internal Ubuntu upgrade program. Obviously either the devs didn't automate the running of [i]gdk-pixbuf-query-loaders --update-cache[/i] or they didn't put in a prominent enough message to do so manually. There is documentation that is easy to find, and it didn't take long for me to solve the issue. http://library.gnome.org/devel/gdk-pixbuf/stable/gdk-pixbuf-query-loaders.html You can read for yourself where I came up with the "--update-cache" argument :happy: Cheers


Tags: woof