Page 55 of 68
Posted: Sun 31 Jul 2011, 23:12
by playdayz
pemasu and don570, You have made me a believe in the
right-click convenience. I am already starting to rely on it
I think it will be a big hit among users. Thanks for all the work.
Posted: Sun 31 Jul 2011, 23:15
by Béèm
playdayz wrote:@ playdayz
In talking to Bert, he taught me that the version of mplayer gnome was not the same between 266 and 526.
266 => 1.0.4 gnome mplayer
526rc => 1.0.3 gnome mplayer
What is the reason for this change in version?
The pursuit of the elusive vdpau message was the basic reason. It seemed that 1.0.3 did not generate that message, but 1.0.4 did, so I reverted. I have learned more and the version I am currently building has 1.0.4 again.
mplayer isn't the only application which generates this series of VDPAU messages. As I said already SeaMonkey does it also.
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.
Just my 2¢.
Posted: Sun 31 Jul 2011, 23:30
by bigpup
rerwin 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.
Posted: Mon 01 Aug 2011, 00:16
by rerwin
playdayz,
I have discovered a surprising situation. It appears that the udev rules in the relatively new /lib/udev/rules.d directory are not being processed. I have been frustrated by my inability to solve dalderton's issue of the modeswitch rules being ignored. As a test, I moved a working test rules file from /etc/udev/rules.d to /lib/udev/rules.d. It no longer works!
This implies that not only are the modeswitch rules being ignored, but also the rest of the rules files in /lib/udev/rules.d. Maybe we should pause a little longer to resolve that.
Richard
Here is evidence that the udev version (124-2) in lupu does not know about the "default" rules directory. That must have come in later.
Content of RPM udev-core-124-2.i586.rpm :
/etc/modprobe.d/udev_blacklist.conf
/etc/scsi_id.config
/etc/udev
/etc/udev/links.conf
/etc/udev/rules.d
/etc/udev/rules.d/05-udev-early.rules
/etc/udev/rules.d/10-udev-example.rules
/etc/udev/rules.d/40-alsa.rules
/etc/udev/rules.d/50-udev-default.rules
/etc/udev/rules.d/51-modprobe.rules
/etc/udev/rules.d/55-hotplug_map.rules
/etc/udev/rules.d/60-cdrom_id.rules
/etc/udev/rules.d/60-persistent-input.rules
/etc/udev/rules.d/60-persistent-storage-tape.rules
/etc/udev/rules.d/60-persistent-storage.rules
/etc/udev/rules.d/61-persistent-storage-edd.rules
/etc/udev/rules.d/64-device-mapper.rules
/etc/udev/rules.d/80-drivers.rules
/etc/udev/rules.d/95-udev-late.rules
/etc/udev/udev.conf
/lib/udev
/lib/udev/ata_id
/lib/udev/cdrom_id
/lib/udev/create_floppy_devices
/lib/udev/devices
/lib/udev/edd_id
/lib/udev/firmware.sh
/lib/udev/net_helper
/lib/udev/path_id
/lib/udev/scsi_id
/lib/udev/usb_id
/lib/udev/vol_id
. . .
It appears that lucid lynx uses udev 151-12. I cannot find similar evidence, but the ubuntu pages such as
http://www.ubuntuupdates.org/packages/show/248972 mention both directories.
We have two alternatives:
1. "Right" way: Upgrade lupu to use the Lucid Lynx udev version (or similar, as in wary).
2. Expedient way: Move all of the rules files into /etc/udev/rules.d.
Now I can get a good night's sleep, having solved dalderton's mystery.
Richard
Right clicks and Puppy Help 101
Posted: Mon 01 Aug 2011, 00:18
by Snail
Smokey01 Playdayz
I would be happy to write the HowTo. How urgent is it? I have never used Notecase, is there much of a learning curve? I don't see any picture in 101 at the moment, are they possible or do I have to get that sort of detail over by being clever with links?
Playdayz I am very, very pleased that you now see the use of right-clicks. If it helps you, just think how good it is for the casual user. If I write the HowTo, it would be my preference to assume that you have binned the "Customise" menu options, for the reasons that I have given above. Would this be acceptable to you? It's your distro after all.
I had a mad idea about right clicks. The .desktop files already hold info about icons and executable files and are a Linux standard, unlike RoxApps. Wouldn't it be nice if you could use the .desktop instead of duplicating the same info in the form of a Roxapp? So I tried adding the "$1" parameter to the Exec= line in a .desktop and then symlinking the .desktop to the Open-with subdirectory. Alas it doesn't work, nor does "$@". Pity.
Posted: Mon 01 Aug 2011, 00:27
by Béèm
Snail,
Notecase is very easy and intuitive.
It is based on creating nodes and eventually nodes on nodes.
Just make up your mind about a structure and hierarchy you want to set up.
Right click howto
Posted: Mon 01 Aug 2011, 00:59
by Snail
Thanks for the reassurance Béèm.
I have thought a bit more about the subject, should have done it before my last post
I know how to set up a right click, provided that the filetype is one already assigned a mime-type. For the case of an entirely new file-type that doesn't have an existing mime-type, I will have to do some research. If we drop the "Customise" options in the menus, the user also needs to check if his particular file-type is already known to Rox or not. Anyone got any pointers?
Puppy Help 101
Posted: Mon 01 Aug 2011, 01:50
by Snail
Smokey01
Quick question. Is there a reason that PH101-001.ncd is in /usr/share/doc and not /usr/share/doc/help? Shouldn't it be PH101-002.ncd?
Posted: Mon 01 Aug 2011, 06:07
by bigpup
Got the idea from here
http://murga-linux.com/puppy/viewtopic.php?t=39505
Product key for your computer
Posted: Mon 01 Aug 2011, 06:19
by bigpup
Got idea from here:
http://murga-linux.com/puppy/viewtopic.php?t=39505
Sticker for the front of computer
Posted: Mon 01 Aug 2011, 07:10
by Sage
rerwin:
Your question is something every upgrader needs to know.
- care to advise on precautions relating to FULL installation upgrades, please?
Re: Puppy Help 101
Posted: Mon 01 Aug 2011, 08:09
by smokey01
Snail wrote:Smokey01
Quick question. Is there a reason that PH101-001.ncd is in /usr/share/doc and not /usr/share/doc/help? Shouldn't it be PH101-002.ncd?
Snail, no reason really.
I have already started on PH101-002 in fact playdayz already has a copy of it. You don't need to do any fancy programming just PM me a text file.
Answer to your question above. Yes you can add graphics but the file would become very large and would not make it into Lucid.
smbc printer error
Posted: Mon 01 Aug 2011, 10:00
by peebee
Hi playdayz
I did my usual setup of a remote smbc printer to my XP box.
Got the attached error when I tried to print.....
Cheers
peebeee
Re: smbc printer error
Posted: Mon 01 Aug 2011, 12:28
by rcrsn51
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.
Posted: Mon 01 Aug 2011, 12:57
by pemasu
Playdayz and rerwin. About udev 151-12. I remember when Playdayz tested it and got some bad experience about it. I just cant remember what went wrong.
But....I had to change to the udev 151-12 when I started to use kernel 2.6.35.7. I couldnt get audio working otherwise. I have used udev 151-12 since then with 2.6.38.2, 2.6.38.4 and now with 2.6.39.3 kernels. Audio has worked. I havent noticed any problems with using it.
Now...People have woofed using ez woof 525 and they have used my kernels 2.6.38.4 and maybe 2.6.39.3 and they have had a lot problems with audio. Maybe older udev is one reason of the audio problems with ez woof 525
If....you are going to create ez woof 527 and there is plan to test newer kernels with it....updating the udev to 151-12 is again current.
Posted: Mon 01 Aug 2011, 13:00
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
Re: smbc printer error
Posted: Mon 01 Aug 2011, 13:14
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
Partial simulation of udev upgrade to activate rules
Posted: Mon 01 Aug 2011, 15:52
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
Posted: Mon 01 Aug 2011, 15:58
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.
.
Posted: Mon 01 Aug 2011, 16:15
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.