packman automated updates
Does anyone know if there is a way or intention in the future of supporting packman where the software updater orb on the bottom right knows that an update is available from packman, like it knows that an update is available from SUSE. I have packman in YaST Sources and that works. I don't want to hear anything about switching to smart and other stuff. What has to happen and who needs encouragement to make this happen? Cheers, Bob
Apologies for the length of this post, and apologies to Rob for the additional private reply... On Thursday 14 September 2006 22:02, Robert Lewis wrote:
Does anyone know if there is a way or intention in the future of supporting packman where the software updater orb on the bottom right knows that an update is available from packman, like it knows that an update is available from SUSE. This is already possible.
I have packman in YaST Sources and that works. This is *somewhat* independent of the orb approach.
I don't want to hear anything about switching to smart and other stuff. Ditto.
What has to happen and who needs encouragement to make this happen? Here is what I just did which works for me. I got the main part of this from
<http://waxborg.servepics.com/English/Linux/SUSE.10.1/suse10.1.html> --------------------------------------------------------------------------------- (0) Turn off (or remove if you wish) the Packman source in YaST. This will get added again in (5) below. Do the following, In a shell as root type [without the quotes] (1) 'rug ping' This 'wakes up' the zmd (why it was sleeping I do not know). (2) 'rpm --import http://packman.iu-bremen.de/public-keys.asc' This imports Packman's public key for signing the packages. You may already have done this, but I do not think repeating it causes any harm (3) 'rug set-prefs security-level checksum' **You might want to think about this one. ** As far as I can tell, while the rpm packages themselves are signed, the /repodata/repomd.xml file itself from Packman isn't, so the updates using the globe/orb will fail. (I could be way off base here). This command changes the security used by the update system from signature based to checksum based. I'm in no position to comment about the security compromises this may involve. Maybe someone else on the list can addres this. I am not recommending for you to do this, I am only telling you what I have done to get this to work. Again... **You might want to think about this one.** (4) 'rug sa --type=zypp http://packman.iu-bremen.de/suse/10.1 packman' This adds Packman as a service (and calls it packman). Type 'rug sl' to check that it was added (sl = services list). (5) 'rug sub packman' This subscribes the update system to the newly added service. Type 'rug ca' to verify that it was added (ca = Catalogs). (I don't know when a service becomes a catalog or vice-versa). This procedure adds Packman as a source for YaST as well, so you will end up with two there if you already had one added. You can remove the one you turned 'off' previously. The one that is 'on' is the one you just added and if you remove it from YaST, you will remove it from the globe's vision as well. (6) 'rug refresh' This refreshes the data. After this finished, my blue globe turned orange with updates from Packman --------------------------------------------------------------------------------- As with all things Zen, some of this may take a while. But it seems to work. As a bonus, updating from the command line with 'rug update packman' actually shows a status bar with some indication of progress! -- Don
Don Raboud wrote:
Apologies for the length of this post, and apologies to Rob for the additional private reply...
On Thursday 14 September 2006 22:02, Robert Lewis wrote:
Does anyone know if there is a way or intention in the future of supporting packman where the software updater orb on the bottom right knows that an update is available from packman, like it knows that an update is available from SUSE.
This is already possible.
I have packman in YaST Sources and that works.
This is *somewhat* independent of the orb approach.
I don't want to hear anything about switching to smart and other stuff.
Ditto.
What has to happen and who needs encouragement to make this happen?
Here is what I just did which works for me. I got the main part of this from
<http://waxborg.servepics.com/English/Linux/SUSE.10.1/suse10.1.html>
---------------------------------------------------------------------------------
(0) Turn off (or remove if you wish) the Packman source in YaST. This will get added again in (5) below.
Do the following, In a shell as root type [without the quotes]
(1) 'rug ping' This 'wakes up' the zmd (why it was sleeping I do not know).
(2) 'rpm --import http://packman.iu-bremen.de/public-keys.asc' This imports Packman's public key for signing the packages. You may already have done this, but I do not think repeating it causes any harm
(3) 'rug set-prefs security-level checksum' **You might want to think about this one. **
As far as I can tell, while the rpm packages themselves are signed, the /repodata/repomd.xml file itself from Packman isn't, so the updates using the globe/orb will fail. (I could be way off base here). This command changes the security used by the update system from signature based to checksum based.
I'm in no position to comment about the security compromises this may involve. Maybe someone else on the list can addres this. I am not recommending for you to do this, I am only telling you what I have done to get this to work.
Again... **You might want to think about this one.**
(4) 'rug sa --type=zypp http://packman.iu-bremen.de/suse/10.1 packman' This adds Packman as a service (and calls it packman). Type 'rug sl' to check that it was added (sl = services list).
(5) 'rug sub packman' This subscribes the update system to the newly added service. Type 'rug ca' to verify that it was added (ca = Catalogs). (I don't know when a service becomes a catalog or vice-versa).
This procedure adds Packman as a source for YaST as well, so you will end up with two there if you already had one added. You can remove the one you turned 'off' previously. The one that is 'on' is the one you just added and if you remove it from YaST, you will remove it from the globe's vision as well.
(6) 'rug refresh' This refreshes the data. After this finished, my blue globe turned orange with updates from Packman
---------------------------------------------------------------------------------
As with all things Zen, some of this may take a while. But it seems to work. As a bonus, updating from the command line with
'rug update packman'
actually shows a status bar with some indication of progress!
Many thanks to Don for his easy to follow instructions. I learned a lot and read the man pages on rug. At first I had many failures. All related to "Dependency Resolution Failed" followed by various numbers one per line. For example 430901 was one of them. The main difference is that originally I substituted the lines above from Don from the .de Germany packman site with a more local mirror. Namely I used: http://packman.unixheads.com/suse/10.1 Another observation is that the line in Yast Installation Source that I had turned off per Don's instructions never got replaced by another line. I don't know why. I finally deleted the line in YaST and then the new one did show up. In the end I dumped the unixheads reference and started all over again following Don's procedure and using the Germany site. I found I still got dependency failures but this time I tried a reboot and then it worked. I did have two dependency issues on software I wasn't using anyway so I had to delete these two with YaST. They were openh323 and xine-ui. I extracted Don's instructions and turned it into a shell script. Here it is: rug ping rpm --import http://packman.iu-bremen.de/public-keys.asc rug set-prefs security-level checksum rug sa --type=zypp http://packman.iu-bremen.de/suse/10.1 packman rug sl rug sub packman rug ca rug refresh # rug update packman echo "For me I had to reboot before this would work without error!" echo "After the reboot click on the Orange Orb on the right." If anyone has further insight into the set-prefs security-level checksum rather than using the defaut rather than using signature that would be of interest. Maybe I should ask someone at packman to explain why signaure can't be used or what they can do to use it. Thanks again Don! Cheers, Bob
participants (2)
-
Don Raboud -
Robert Lewis