Lucid Puppy 5.2.7 RC2

A home for all kinds of Puppy related projects
Message
Author
backi
Posts: 1922
Joined: Sun 27 Feb 2011, 22:00
Location: GERMANY

#1096 Post by backi »

I´ m not quite shure where to post this information. So I do it here.

Today I have seen in DISTROWATCH some comments about economic crisis and if this maybe will give Linux in future some advantage over MS Windows.
Please read for your own.

There was a comment from a guy " Linux in Africa (by Atle on 2011-08-01 10:37:23 GMT from France)" which I like to cite here.

3 • Linux in Africa (by Atle on 2011-08-01 10:37:23 GMT from France)

"Dear readers. After spending more than 2 years in various African countries, I can for sure tell you why it does not succeed. Its as simple or stupid as this:

There is no money to collect. Nothing to be stolen. No government kickbacks, no 10% percent commission to the government people. So the public sector, as well as the private, will only deal with MS, that has off course specialized into offering the 10 or 20 percent commission on all sales. Microsoft main sales partner in Tanzania was awarded something like “Partner of the Year

User avatar
peebee
Posts: 4370
Joined: Sun 21 Sep 2008, 12:31
Location: Worcestershire, UK
Contact:

Re: smbc printer error

#1097 Post by peebee »

rcrsn51 wrote:
peebee wrote:I did my usual setup of a remote smbc printer to my XP box.Got the attached error when I tried to print....
The solution is to make the following symlink

Code: Select all

ln -s /lib/libreadline.so.6.1 /usr/lib/libreadline.so.5
But I have no idea why 526 requires this but 525 does not.
Thanks rcrsn51

Confirmed - that fixes it.

Cheers
peebee
ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

User avatar
rerwin
Posts: 2017
Joined: Wed 24 Aug 2005, 22:50
Location: Maine, USA

Partial simulation of udev upgrade to activate rules

#1098 Post by rerwin »

playdayz,
Although this may make it easier to avoid upgrading udev to the lucid lynx level, I provide here a possible workaround for people to try. It activates udev rules that have never before been in effect in Lucid Puppy, so might cause concern for their possible impacts. Instead of moving the rules to the /etc/udev/rules.d directory (where they will be processed as expected), the package provides absolute links to each of the rules files in /lib/udev/rules.d (which are ignored by the current udev version). The package also has the 526RC versions of the two rc.update scripts that should remain as they are in 526RC.

I encourage anyone with a USB dialup modem, Wacom tablet PC (if anyone is going that route), USB SmartCard Reader (SCM), libgphoto2 devices, or SDP4430 sound card to try this workaround.

The newly activated rules files are:
  • /lib/udev/rules.d/40-gnupg.rules
    /lib/udev/rules.d/40-libgphoto2-2.rules [needs udev 136]
    /lib/udev/rules.d/40-libpisock9.rules
    /lib/udev/rules.d/40-usb_modeswitch.rules
    /lib/udev/rules.d/40-xserver-xorg-video-intel.rules
    /lib/udev/rules.d/64-xorg-xkb.rules [needs missing file: /etc/default/console-setup]
    /lib/udev/rules.d/66-xorg-synaptics.rules
    /lib/udev/rules.d/66-xorg-tslib.rules
    /lib/udev/rules.d/69-xorg-vmmouse.rules
    /lib/udev/rules.d/69-xserver-xorg-input-wacom.rules [needs missing file: check_driver]
    /lib/udev/rules.d/90-alsa-restore.rules
    /lib/udev/rules.d/90-alsa-ucm.rules
While the usb_modeswitch file is definitely required, some of the others may not be, but probably would cause no trouble. To assist with evaluating the rules files, I attach a listing of their content (except for modeswitch). If any of the rules files should not be active, their link in /etc/udev/rules.d can be removed, to deactivate them.

I consider this a partial workaround because it does not provide the full support that udev 151-12 would. At least one of the rules files needs a udev version later than the current one.
Richard
Attachments
old-udev_workaround-1.pet
adds processable links to udev rules, as partial alternative to upgrading udev.
(8.76 KiB) Downloaded 246 times
lib_udev_rules.txt.gz
udev rules to be activated
(8.22 KiB) Downloaded 237 times

User avatar
playdayz
Posts: 3799
Joined: Fri 25 Apr 2008, 18:57

#1099 Post by playdayz »

But I have news.
I installed the 526 on the dreaded Medion 8818.
It has an nvidia graphics card.
After booting and only using SeaMonkey, xerrs.log stays at some 57 lines.
No VDPAU messages.
It's logic, as nvidia is VDPAU ready. Others not.

So I wonder if there could be:
- a kernel parameter to disable VDPAU
or better
- disable automatically VDPAU in case a nvidia graphics isn't installed.
I think we have come pretty close to what you want Béèm, in the next RC release 5.2.7. I have it where gnome-mplayer and gecko-mediaplayer (in the browsers) do not generate the message. The messages in Seamonkey are from flashplayer. In 527 which I am working on, those flashplayer messages are also eliminated.

Credit where credit is due. In order to investigate the vdpau message I spent *a lot* of time in xerrs.log, and in that way I did discover a serious problem of one program going crazy and generating about 100 messages a minute. That is *very* bad. It would slow the computer down and perhaps even overload the filesystem if one didn't restart X fairly often to reset xerrs.log. I have notified the author of that program.

One helpful hint in general for everyone is that if Puppy slows down or becomes less responsive, it can help to Menu -> Shutdown -> Restart X server.
So I wonder if there could be:
- a kernel parameter to disable VDPAU
or better
- disable automatically VDPAU in case a nvidia graphics isn't installed.
The thing is, this is not really a Puppy error. It comes mainly from flashplayer and what I think is some lazy programming. pemasu has found it reported in many places on the web. it looks like flashplayer doesn't bother to check whether you are using an nvida card or not--it just tries to load it and if it fails, that doesn't really matter--flashplayer still plays the video. Then some programs pass the message on to xerrs.log, but other programs are smart enough to know if doesn't matter and to null it. As I say, I think we have what you want in 5.2.7. Thanks.
.
Last edited by playdayz on Mon 01 Aug 2011, 16:16, edited 1 time in total.

User avatar
playdayz
Posts: 3799
Joined: Fri 25 Apr 2008, 18:57

#1100 Post by playdayz »

After Lucid. I have been thinking about this so I might as well post it. Pemasu mentioning EZ-Woof gives me the opportunity.

There will be an EZ-Woof 5.2.7 and I hope people will use it. One thing is that a newer kernel should plug right in--I know it's never that easy but pemasu has already done much work in that direction--and maybe this new business of udev will help further. EZ-Woof is also reasonably easy to update individual programs as well. A 5.2.7 built from EZ-Woof and a new kernel should be a Puppy Derivative, imho, until Slack Pup is released, and for at least a month afterwards, but after that who knows.

EZ-Woof is not good for simply installing the latest Woof. That is ultimately doable I think, but that is what Slacko will be doing so maybe the ghost of lucid should do something else. Maybe Lucid should remain the "last non-zzz" Puppy--or maybe it could even do both. Anyway, I will be available and happy to answer questions from people, once 5.2.7 is released.

However, I hope some of the people who have helped with Lucid will now go on to release Puppies of their own--well I am sure some will. One thing that i might mention is the difference between a derivative and an official release. I have found that an official release is a heck of a lot of pressure--the responsibility to develop a Puppy with almost zero problems that will represent all that Barry has built, is a big responsibility--there is a lot more development time and work needed. Everyone can see that, I don't know why I am saying it.

I know iguleder has also been interested in EZ-Woof--I would love to see the hybrid 64-bit system that he has mentioned. OK, now to see what rerwin has found.

User avatar
playdayz
Posts: 3799
Joined: Fri 25 Apr 2008, 18:57

#1101 Post by playdayz »

pemasu, I assume you used the udev from Ubuntu? I notice there is a lucid 10.04 update for udev. I am going to try that. Is there anything you have discovered that might help me? Thanks.

In case anyone would like to follow, my first thoguht was to use the Ubuntu Lucid-update version of udev, but oh my, that seems to be a big mess--with a lot of files that seem to me might conflict with similar files in Lucid puppy.

Now I am looking to see what version of udev is Barry's latest.

In both or either of those cases, rerwin's changes would overwrite what was in the udev package, so that might be OK after all.

More to come.

User avatar
rerwin
Posts: 2017
Joined: Wed 24 Aug 2005, 22:50
Location: Maine, USA

#1102 Post by rerwin »

playdayz,
In both or either of those cases, rerwin's changes would overwrite what was in the udev package
I don't think my changes would replace anything in udev. However, the links would still be used, because the rules in /etc/udev/rules.d take precedence over those in /lib/udev/rules.d, but they would just run the same rules. Also, the rules are not part of the udev (151) package, so my workaround is independent of udev itself.
Richard

Sylvander
Posts: 4416
Joined: Mon 15 Dec 2008, 11:06
Location: West Lothian, Scotland, UK

#1103 Post by Sylvander »

1. Running Lupu-526, and used it to update the lupusave of Lupu-525.

2. All seems to be working well. :D 8)
Haven't noticed any faults/flaws.

User avatar
rerwin
Posts: 2017
Joined: Wed 24 Aug 2005, 22:50
Location: Maine, USA

#1104 Post by rerwin »

Sage wrote:rerwin:
Your question is something every upgrader needs to know.
- care to advise on precautions relating to FULL installation upgrades, please?
I can speak only regarding the "update" process. The same update is done for full installations as for pupsave files. That includes copying all new-puppy files into the full installation.

Since the upgrade would simply be additive (except, now, for deletion of some old puppy-modprobe and modem files), some residue of past versions of apps could be left around. I think the same precaution applies -- uninstall all apps that you know are being upgraded in the new puppy. I would expect a new app version to read an old retained-data file or to adapt to retained-data changes between versions.

To clarify the terms: "Upgrade" means the replacement of puppy into an existing pupsave or full-installation environment. "Updating" is the process of merging the new puppy files into an existing environment.
Richard
Last edited by rerwin on Mon 01 Aug 2011, 17:36, edited 2 times in total.

Jim1911
Posts: 2460
Joined: Mon 19 May 2008, 20:39
Location: Texas, USA

#1105 Post by Jim1911 »

Please provide the latest NVIDIA-Linux-280.13 driver in 5.2.7, otherwise please provide a link to the kernel source so that we can install the driver.

Thanks,
Jim

User avatar
playdayz
Posts: 3799
Joined: Fri 25 Apr 2008, 18:57

#1106 Post by playdayz »

I made a luci-268 with udev 151-12.3 from Ubuntu Lucid-upgrade and it booted. That is a good first step. Upgrading would be good for reasons pemasu mentioned *if* it can be done expeditiously and safely.

Now, I need to know how to handle the rules. The ubu udev comes with a bunch of rules in /lib/udev/rules.d. I will attach a screen shot.

Option 1. Delete them all and let the Puppy rules rule ;-) The new udev would look in both places, and that was the problem as I udnerstand it--the old udev not looking in the new place. Therefore no symlinks would be necessary. Do I have this right?

Option 2. Leave the ubu rules. There are certainly a lot more rules than Puppy has. I could arrange it so that the Puppy rules would overwrite any ubu rules. This would be much more complicated than option 1.

I am now going to pursue Option 1 and see what I get.
Attachments
ubu-rules.png
(98.48 KiB) Downloaded 284 times
Last edited by playdayz on Mon 01 Aug 2011, 17:36, edited 1 time in total.

User avatar
playdayz
Posts: 3799
Joined: Fri 25 Apr 2008, 18:57

#1107 Post by playdayz »

Essentially, the updater will not delete your old app versions, which should override the newer versions.

If I am understanding this.
What good is an update of the save file?
The whole purpose of upgrading is to get the newer version, of a program, with the bug fix.
BTW rerwin, This seems like a good question to me also? I think you may be talking about old apps that were installed with a pet???

User avatar
pemasu
Posts: 5474
Joined: Wed 08 Jul 2009, 12:26
Location: Finland

#1108 Post by pemasu »

I have used ubuntu repo udev, not the one from ubuntu updates. Eventhough I tested several builds with both repos enabled. But the problem was that many packages had duplicates and it was a mess to remove the older ones.
Also ubuntu update packages broke the X. I couldnt boot to the X.

Code: Select all

yes|udev|udev|exe,dev>null,doc,nls
>>>> udev_151-12_i386.deb
Last edited by pemasu on Mon 01 Aug 2011, 17:50, edited 2 times in total.

User avatar
rerwin
Posts: 2017
Joined: Wed 24 Aug 2005, 22:50
Location: Maine, USA

#1109 Post by rerwin »

playdayz wrote:Option 1. Delete them all and let the Puppy rules rule ;-) The new udev would look in both places, and that was the problem as I udnerstand it--the old udev not looking in the new place. Therefore no symlinks would be necessary. Do I have this right?

Option 2. Leave the ubu rules. There are certainly a lot more rules than Puppy has. I could arrange it so that the Puppy rules would overwrite any ubu rules. This would be much more complicated than option 1.
I do not believe there is a conflict in the rules files. Both puppy's and ubuntu's rules files can be retained, unless there is a reason to remove any of them. If there happens to be a match in file names between puppy's and ubuntu's, just rename the puppy file to avoid conflict. If I am missing such a conflict, please tell me.

If we go with the new udev, then please ignore my workaround package. Do not include the symlinks in lupu, but the rc.update files are there if you need them to restore the 526RC versions.
Richard

User avatar
playdayz
Posts: 3799
Joined: Fri 25 Apr 2008, 18:57

#1110 Post by playdayz »

I do not believe there is a conflict in the rules files. Both puppy's and ubuntu's rules files can be retained, unless there is a reason to remove any of them. If there happens to be a match in file names between puppy's and ubuntu's, just rename the puppy file to avoid conflict.
Well, I went with Option 1. The result was that /etc/udev/rules.d and /lib/udev/rules.d look exactly as they do in Lupu-526. I regard that as a good thing. I will attach a screenie.

Now, the question, is it worth putting the ubu rules back in? And if so, how do I rename any conflicts? With a higher number? This is more complicated but if it would result in a better Lucid I can give it a go.

Thanks pemasu. The ubu update udev boots OK. There is also a udev_lib that I don't see in your entry, but maybe you had that in a separate entry. (I updated both udev and libudev0 (udev_lib).)
If we go with the new udev, then please ignore my workaround package. Do not include the symlinks in lupu, but the rc.update files are there if you need them to restore the 526RC versions.


I tried the update udev option first so the rc.updates should be OK. I will check of course.
Attachments
option1.png
(136.9 KiB) Downloaded 612 times
Last edited by playdayz on Mon 01 Aug 2011, 18:05, edited 3 times in total.

User avatar
rerwin
Posts: 2017
Joined: Wed 24 Aug 2005, 22:50
Location: Maine, USA

#1111 Post by rerwin »

playdayz wrote:
Essentially, the updater will not delete your old app versions, which should override the newer versions.

If I am understanding this.
What good is an update of the save file?
The whole purpose of upgrading is to get the newer version, of a program, with the bug fix.
BTW rerwin, This seems like a good question to me also? I think you may be talking about old apps that were installed with a pet???
Yes, I am referring to puppy apps that the user may have updated from a .pet. (for example, pfind).

The updater is concerned only about ensuring that the correct (new) versions of puppy components are retained. If a puppy component exists in a pupsave or full installation, it will be replaced in the pupsave/full-install by the new version. In the past, as I assessed the code, the entire set of new components got copied into the pupsave! My changes ensure that that is done only if there is already an old version there (or signs that it was deleted), so as to avoid bloating the pupsave file.

Anyway, that is my take on how upgrading works. Anyone, please correct me if I have it wrong.
Richard

User avatar
rerwin
Posts: 2017
Joined: Wed 24 Aug 2005, 22:50
Location: Maine, USA

#1112 Post by rerwin »

playdayz wrote:Now, the question, is it worth putting the ubu rules back in? And if so, how do I rename any conflicts? With a higher number? This is more complicated but if it would result in a better Lucid I can give it a go.
I am still confused about what you mean by a conflict. There is no duplication of file names nor functionality implied by the text parts of the names. The initial numbers in the file names do not have to be unique. They are there merely to affect the order they are processed by udev.

The only reason, so far, I am aware of for assigning a particular number to the name is to have the rules be processed either before or after the normal loading of modules, which is done in rule files starting with "50". The numbers would also be important to control the relative order of related rules. But the rules I have seen seem not to depend on processing sequence.
Richard

User avatar
playdayz
Posts: 3799
Joined: Fri 25 Apr 2008, 18:57

#1113 Post by playdayz »

I am still confused about what you mean by a conflict. There is no duplication of file names nor functionality implied by the text parts of the names.
Sorry. I haven't gone through them one by one to look for conflicts. Since you have gone through and found no conflicts I assume from your question that you think it would be a good thing to include the ubu rules? If so, it will be done. No problem.


Also, to confirm, the rc.update and remove_obsolete_files that we want are the ones you sent me yesterday in a pm?

Sage
Posts: 5536
Joined: Tue 04 Oct 2005, 08:34
Location: GB

#1114 Post by Sage »

Richard: many thanks for your comments and apologies for my sloppy terminology (not an IT professional by trade!).

User avatar
rerwin
Posts: 2017
Joined: Wed 24 Aug 2005, 22:50
Location: Maine, USA

#1115 Post by rerwin »

playdayz wrote:Also, to confirm, the rc.update and remove_obsolete_files that we want are the ones you sent me yesterday in a pm?
Yes, rc.update_fix-4.

That restores the 526RC version of rc.update and has the version of the file remover that deletes the now-unnecessary "40-" link to the usb_modeswitch rules file in /lib/udev/rules.d.

Thanks for verifying this, after all the chaos about it. And thanks for going with the ubuntu version of udev.
Richard

Post Reply