Thanks pemasu, I decided that was a bad idea I had As long as it has been installing correctly, that is alI I as worried about. I am about to build with the version 6 you posted. Thanks.Well. almost everything inside it matters.
Lucid Puppy 5.2.7 RC2
- ASRI éducation
- Posts: 3197
- Joined: Sat 09 May 2009, 12:10
- Location: France
- Contact:
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.@ 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?
pemasu, I have it installed and it is looking good. Thanks for putting up with me.Don570 created pinstall.sh script has been done properly with woof building in mind.
----------------------------------------------------------------------
Maybe the last question, wouldn't that be great? Does anyone know why there are two instances of pfbpanel running and one of fbpanel? I am not saying it is an error or even that it needs fixing, just curious. It has not presented any problem I am aware of. Thanks.
Because the way we do it, there is already a lupu-526 on the loose--hopefully only among us testers. But for safety the next will be 5.2.7. We allowed for that, just in casesomeone asked why the enxt version will be 5.2.7 instead of 5.2.6 rc2.
As I say, I have seen no problems. Should pfbpanel exit when done, or does it need to stay running? Sometimes also, the taskmanagers will show two instances, but it is really only one, two threads or something.Certainly, one of those instances of pfbpanel will be left over from the fixmenus script run from the startup folder.
Pfbpanel only sets up the configuration initially and then does nothing further, so it can be killed until required again.playdayz wrote:As I say, I have seen no problems. Should pfbpanel exit when done, or does it need to stay running? Sometimes also, the taskmanagers will show two instances, but it is really only one, two threads or something.Certainly, one of those instances of pfbpanel will be left over from the fixmenus script run from the startup folder.
Spup Frugal HD and USB
Root forever!
Root forever!
Yes you should be able to upgrade a frugal save file from version 5.2 to 5.2.6rc and then to 5.2.6 final.Hogweed wrote:Wondering whether to try a frugal upgrade of my 5.2 config. Can someone tell me what exactly a frugal upgrade of the personal save file does? Does it just change a version number or does it attempt to detect if newer versions are installed by the upgrades than I might have in my personal files (or older versions installed over my savefile updates)?
A quick search suggests there might be problems but I'm not clear if these are unusual exceptions or the norm.
Also can I then just upgrade from 5.2.6RC to the final release?
Or am I better just to do a fresh installation and reinstall/migrate what I need. Sorry for these simple questions but I've never upgraded before and am just wondering what to expect.
Frugal save file upgrades can only be done to Puppy in same series.
Puppy5 to Puppy 5.2, but not Puppy 4.1 to Puppy 5.0
Because 5.2.6rc is a test of the final version and some things broken have been found. I would not upgrade your working 5.2 with it.
The final version of 5.2.6 will be out soon. Wait for that before upgrading.
What happens when you upgrade a frugal install save file?
This is what should happen. The key word is should.
The save file data is upgraded to work with the newer version of Puppy and any newer program versions that come with the newer version of Puppy.
If a program is in the new version, but was not in the old version. The save file would not contain any data to update or configuration data for that new program. That program would be a fresh run the first time.
Any programs in the save file that are not part of the newer version of Puppy will stay as they are.
There is always the chance that a newer version, of a Puppy series, will have changes in it, that will conflict with a program you have added to Puppy.
For the most part it works fine to upgrade the save file with a newer version of Puppy. Just not 100% you will not have little issues caused by the upgrade.
So far with 5.2.6rc
You get two console icons on desktop after the upgrade. Just have to delete the one you do not want or keep them both.
Desktop icons may go back to default, if you made custom changes.
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
Playdayz,
On bootup, seems I notice on first seeing desktop, the taskbar is at the bottom, and a few seconds later, it like resets.
Could this be why?
Also between the two pfbpanels the freememapplet_tray starts up.
pfbpanel - is variables created at bootup by 'init' in initramfs...Does anyone know why there are two instances of pfbpanel running and one of fbpanel?
On bootup, seems I notice on first seeing desktop, the taskbar is at the bottom, and a few seconds later, it like resets.
Could this be why?
Also between the two pfbpanels the freememapplet_tray starts up.
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
That is because pfbpanel re-writes the default profile when fixmenus runs from the entry in the startup folder. Fixmenus 'calls' pfbpanel. Hope that is the right term.....bigpup wrote:Playdayz,pfbpanel - is variables created at bootup by 'init' in initramfs...Does anyone know why there are two instances of pfbpanel running and one of fbpanel?
On bootup, seems I notice on first seeing desktop, the taskbar is at the bottom, and a few seconds later, it like resets.
Could this be why?
Also between the two pfbpanels the freememapplet_tray starts up.
Spup Frugal HD and USB
Root forever!
Root forever!
It could be. There is a script in startup that runs fixmenus. The reason is that if a pet has been installed and then the user exits X *before* fixmenus has finished running to update things for the pet menu entry etc, then the fbpanel menu will be messed up. This is not just theoretical---I saw it happen several times which is why I did the Startup script. Not the most elegant solution I am sure, but it works.On bootup, seems I notice on first seeing desktop, the taskbar is at the bottom, and a few seconds later, it like resets.
Could this be why?
Sometimes you just have to go with what worksplaydayz wrote:It could be. There is a script in startup that runs fixmenus. The reason is that if a pet has been installed and then the user exits X *before* fixmenus has finished running to update things for the pet menu entry etc, then the fbpanel menu will be messed up. This is not just theoretical---I saw it happen several times which is why I did the Startup script. Not the most elegant solution I am sure, but it works.On bootup, seems I notice on first seeing desktop, the taskbar is at the bottom, and a few seconds later, it like resets.
Could this be why?
Spup Frugal HD and USB
Root forever!
Root forever!
Your question is something every upgrader needs to know. Thank you for bringing it up.Hogweed wrote:Been using Lupu 5.2 (with update 1) since it came out and have tested 5.26RC on multiseesion DVD - seems fine.
Wondering whether to try a frugal upgrade of my 5.2 config. Can someone tell me what exactly a frugal upgrade of the personal save file does? Does it just change a version number or does it attempt to detect if newer versions are installed by the upgrades than I might have in my personal files (or older versions installed over my savefile updates)?
A quick search suggests there might be problems but I'm not clear if these are unusual exceptions or the norm.
Obviously I would back up my 1G save file first but I'm just wondering what to expect from a frugal upgrade from 5.2 to 5.2.6
Also can I then just upgrade from 5.2.6RC to the final release?
Or am I better just to do a fresh installation and reinstall/migrate what I need. Sorry for these simple questions but I've never upgraded before and am just wondering what to expect.
As the person who has most recently maintained the update function, I do not believe that the newer versions of programs you have installed will replace your version. It simply keeps what you have in the pupsave, but ensures that the new versions of puppy components are substituted for any in the pupsave file.
Essentially, the updater will not delete your old app versions, which should override the newer versions. I don't think that is what you want to have happen. Therefore, I recommend making a copy of the old pupsave in the old puppy, then work with one of them for the upgrade. It might get tedious, but I suggest determining which of your installed apps have newer versions in the new puppy, and uninstalling them from the old pupsave. However, any data they may have saved may remain -- that could be good or bad.
In summary, an upgrade keeps everything you have in your "personal storage" except for puppy itself. It does not examine your installed packages to determine what new packages might replace old ones, nor does it have any way of knowing that.
That would be safer.Or am I better just to do a fresh installation and reinstall/migrate what I need.
Richard
Right clicks
Both the "Customise" option in the top-level Rox right-click menu and the "Customise" in the "open-with" submenu work in exactly the same way. The "helpful" pop-up message panel for the submenu is a bit longer, but not much more informative, apart from that there is no difference in how they work. How can one possibly be said to be easier than the other?
Rox "SentTo" was presumably renamed to "Open-with" to make ex-Windows users feel at home. Most of us will have had a few year's experience in Windows, so it is important that any Puppy "Open-with" behaves reasonably like the Windows one if the new user is not to be confused and irritated. Windows' "Open-with" is mime-type specific. Therefore putting items in the base ...."Open-with" directory is not merely daft but, because it is un-Windows-like, it is also misleading. For that reason alone, the lower-level "Customise" needs booting. For the very few occasions where using the base directory is indicated,
Right-click -> "Customise -> UP-arrow
isn't exactly hard to do.
Both "Customise" options "help" pop-ups and the Rox manual are seriously defective in that they don't tell the full story. It is not sufficient to drag in just any application file. This will only work where the application expects the first parameter to be the filename. Many do not work that way, including pfind and gdmap and most linux utilities. These must be wrapped, and the best solution is to stick to the way the right-clicks pet has done it, for consistency and debug-ability. This is not trivial for the new user. Both "Customise" options suck new users into thinking that things are easy and set them up for possible failure. Not nice user interfacing.
Now that right-clicks has been properly implemented (Thanks Pemasu and Don570), there is very little need it any for customistaion by noobs. It needs better than noob skills to do. Therefore, for the rare cases where it is needed, I think that it would be better to put a good "Howto' into Puppy Help 101 and dispense with both snare-and-delusion "Customise" options altogether.
"Open-with" acts like it does in Windows if the sub-menus are properly populated, which they will be in 526. However, it merely repeats the info in the top-level right-click, then adds any nonsense left behind in the base directory. Since its "Customise" option is misleading and not necessary and needs an extra click what is its point, apart from to mislead and confuse? (Requiring Shift-click for basic functionality is not good GUI)
Proper right-click behaviour will be part of Puppy 526's basic infra-structure. Hopefully this major advance in usability will be carried forward into 5.3 and beyond. It is most desirable that pets and sfs files in the repository don't break it. Hence, in addition to setting up menus, the right clicks should be set up automatically by the each pet or sfs, when this is appropriate.
Rox "SentTo" was presumably renamed to "Open-with" to make ex-Windows users feel at home. Most of us will have had a few year's experience in Windows, so it is important that any Puppy "Open-with" behaves reasonably like the Windows one if the new user is not to be confused and irritated. Windows' "Open-with" is mime-type specific. Therefore putting items in the base ...."Open-with" directory is not merely daft but, because it is un-Windows-like, it is also misleading. For that reason alone, the lower-level "Customise" needs booting. For the very few occasions where using the base directory is indicated,
Right-click -> "Customise -> UP-arrow
isn't exactly hard to do.
Both "Customise" options "help" pop-ups and the Rox manual are seriously defective in that they don't tell the full story. It is not sufficient to drag in just any application file. This will only work where the application expects the first parameter to be the filename. Many do not work that way, including pfind and gdmap and most linux utilities. These must be wrapped, and the best solution is to stick to the way the right-clicks pet has done it, for consistency and debug-ability. This is not trivial for the new user. Both "Customise" options suck new users into thinking that things are easy and set them up for possible failure. Not nice user interfacing.
Now that right-clicks has been properly implemented (Thanks Pemasu and Don570), there is very little need it any for customistaion by noobs. It needs better than noob skills to do. Therefore, for the rare cases where it is needed, I think that it would be better to put a good "Howto' into Puppy Help 101 and dispense with both snare-and-delusion "Customise" options altogether.
"Open-with" acts like it does in Windows if the sub-menus are properly populated, which they will be in 526. However, it merely repeats the info in the top-level right-click, then adds any nonsense left behind in the base directory. Since its "Customise" option is misleading and not necessary and needs an extra click what is its point, apart from to mislead and confuse? (Requiring Shift-click for basic functionality is not good GUI)
Proper right-click behaviour will be part of Puppy 526's basic infra-structure. Hopefully this major advance in usability will be carried forward into 5.3 and beyond. It is most desirable that pets and sfs files in the repository don't break it. Hence, in addition to setting up menus, the right clicks should be set up automatically by the each pet or sfs, when this is appropriate.
Re: Right clicks
Snail if you write the help I will include it in the next version.Snail wrote:I think that it would be better to put a good "Howto' into Puppy Help 101 and dispense with both snare-and-delusion "Customise" options altogether.
- Béèm
- Posts: 11763
- Joined: Wed 22 Nov 2006, 00:47
- Location: Brussels IBM Thinkpad R40, 256MB, 20GB, WiFi ipw2100. Frugal Lin'N'Win
mplayer isn't the only application which generates this series of VDPAU messages. As I said already SeaMonkey does it also.playdayz wrote: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.@ 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?
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¢.
Last edited by Béèm on Mon 01 Aug 2011, 00:08, edited 1 time in total.
Time savers:
Find packages in a snap and install using Puppy Package Manager (Menu).
[url=http://puppylinux.org/wikka/HomePage]Consult Wikka[/url]
Use peppyy's [url=http://wellminded.com/puppy/pupsearch.html]puppysearch[/url]
Find packages in a snap and install using Puppy Package Manager (Menu).
[url=http://puppylinux.org/wikka/HomePage]Consult Wikka[/url]
Use peppyy's [url=http://wellminded.com/puppy/pupsearch.html]puppysearch[/url]
If I am understanding this.rerwin wrote:Essentially, the updater will not delete your old app versions, which should override the newer versions.
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.
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
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.
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
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.
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.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
. . .
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
Last edited by rerwin on Mon 01 Aug 2011, 01:30, edited 2 times in total.
Right clicks and Puppy Help 101
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.
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.