Re: [Spacewalk-list] Packages associated with wrong channel
On 04/06/2011 04:54 AM, Sander Grendelman wrote: On Mon, Apr 04, 2011 at 02:18:42PM -0600, Jason M. Nielsen wrote: After a long time of poking around I noticed a pattern and it appears to be related to errata that were submitted into spacewalk. The script I use is not capable of supplying a channel name so it is submitted to all channels. I presumed that even with the errata in all channels it would still only be the errata and only apply if the rpm existed in the channel. Actually it would seem by pushing the errata to all channels it results in those rpms becoming associated with the channel with one exception. Architecture is held correctly. That is, Im not seeing x8664 rpms associated with i386 channels. I realize that if this is what caused the problem then its the b0rked script but what Im wondering is does Spacewalk automatically associate an rpm with a channel just because errata for the rpm has been submitted to that channel? It seems to me that packages should only be associated to a channel by an explicit push of some sort (in my case rhnpush) and no other reason. It could be the script itself did this as one section looks like it very well might be pushing packages and not just errata. Im completely unfamiliar with the api though. I've also run into this problem, it seems that publishing an erratum to multiple channels can cause associated packages to be pushed to some of those channels too. This can also cause centos5-packages to appear in centos4 channels :(. A workaround is to publish the erratum without associated packages and associating packages afterwards. In my opinion this is a bug, I don't know if there is already a bugzilla report for this one? I tried disassociating the errata with the channels but the rpm still shows up in the package list. Its looking like the only method to reliably clean this up will be start from scratch. Maybe I can just wipe the rhel4 channels. If it was not the script and related to the errata then Im baffled as to what caused this. It is very probable that this was caused by the script, deleting the packages should also work. You can probably search for packages with "el5" in their name through the api and delete the resulting packages from your rhel4 channels. This is the script I used (get_errata.pl): http://sourceforge.net/projects/rhn2spacewalk/files/ I don't see an errata-publishing step in this script but I do see that errata are created with their relevant packages attached. What works for me when publishing an erratum through the api is: 1) Create erratum _without packages_. 2) Publish erratum to the relevant channels. 3) Add packages to the erratum. This way no packages are pushed to the wrong channel. An extra benefit is that publishing the erratum without packages is a lot quicker. ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list So I modified the script and submitted the thought on the sourceforge open discussion board but in case anyone is interested take a look at: https://sourceforge.net/projects/rhn2spacewalk/forums/forum/1266739/topic/4482538 It only submits errata to the channels that have the associated package. Not pretty but its worked thus far. begin:vcard fn:Jason Nielsen n:Nielsen;Jason org:Myriad Genetics, Inc.;IT email;internet:jniel...@myriad.com title:Unix Administrator tel;work:801-505-5123 tel;cell:801-782-7141 version:2.1 end:vcard ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Packages associated with wrong channel
On 04/06/2011 04:54 AM, Sander Grendelman wrote: On Mon, Apr 04, 2011 at 02:18:42PM -0600, Jason M. Nielsen wrote: After a long time of poking around I noticed a pattern and it appears to be related to errata that were submitted into spacewalk. The script I use is not capable of supplying a channel name so it is submitted to all channels. I presumed that even with the errata in all channels it would still only be the errata and only apply if the rpm existed in the channel. Actually it would seem by pushing the errata to all channels it results in those rpms becoming associated with the channel with one exception. Architecture is held correctly. That is, Im not seeing x8664 rpms associated with i386 channels. I realize that if this is what caused the problem then its the b0rked script but what Im wondering is does Spacewalk automatically associate an rpm with a channel just because errata for the rpm has been submitted to that channel? It seems to me that packages should only be associated to a channel by an explicit push of some sort (in my case rhnpush) and no other reason. It could be the script itself did this as one section looks like it very well might be pushing packages and not just errata. Im completely unfamiliar with the api though. I've also run into this problem, it seems that publishing an erratum to multiple channels can cause associated packages to be pushed to some of those channels too. This can also cause centos5-packages to appear in centos4 channels :(. A workaround is to publish the erratum without associated packages and associating packages afterwards. In my opinion this is a bug, I don't know if there is already a bugzilla report for this one? I tried disassociating the errata with the channels but the rpm still shows up in the package list. Its looking like the only method to reliably clean this up will be start from scratch. Maybe I can just wipe the rhel4 channels. If it was not the script and related to the errata then Im baffled as to what caused this. It is very probable that this was caused by the script, deleting the packages should also work. You can probably search for packages with "el5" in their name through the api and delete the resulting packages from your rhel4 channels. This is the script I used (get_errata.pl): http://sourceforge.net/projects/rhn2spacewalk/files/ I don't see an errata-publishing step in this script but I do see that errata are created with their relevant packages attached. What works for me when publishing an erratum through the api is: 1) Create erratum _without packages_. 2) Publish erratum to the relevant channels. 3) Add packages to the erratum. This way no packages are pushed to the wrong channel. An extra benefit is that publishing the erratum without packages is a lot quicker. ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list The biggest problem with the manual association is when you are talking 1000s of errata its pretty well just not going to happen. Think Im going to try my hand at the api and my own scripts. If there is no way to automatically associate it all then errata be damned. Its not worth the grief. This is definitely a bug if the script did not push the package to the other channels. So after closer inspection I have packages posted across all channels which basically means reconstruction of over 2 packages and 16 channels. Ouch. Guess I just should not have trusted the script and knew more about it before running. Unfortunately when I tested it I only had a small number of packages and channels. There was probably no cross over for whatever reason. What really sucks is I thought maybe I could just delete all packages across the board and at least keep my channel setup and activation keys. It would appear nothing is being removed from the satellite base directory and it just continues to grow in size so I very well might be stuck with a full blown wipe of all of spacewalk. Perhaps Ill just stick with a plain flat file http repo and yum. lol begin:vcard fn:Jason Nielsen n:Nielsen;Jason org:Myriad Genetics, Inc.;IT email;internet:jniel...@myriad.com title:Unix Administrator tel;work:801-505-5123 tel;cell:801-782-7141 version:2.1 end:vcard ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Packages associated with wrong channel
On Mon, Apr 04, 2011 at 02:18:42PM -0600, Jason M. Nielsen wrote: > > After a long time of poking around I noticed a pattern and it appears to > be related to errata that were submitted into spacewalk. The script I > use is not capable of supplying a channel name so it is submitted to all > channels. I presumed that even with the errata in all channels it would > still only be the errata and only apply if the rpm existed in the > channel. Actually it would seem by pushing the errata to all channels it > results in those rpms becoming associated with the channel with one > exception. Architecture is held correctly. That is, Im not seeing x8664 > rpms associated with i386 channels. > > I realize that if this is what caused the problem then its the b0rked > script but what Im wondering is does Spacewalk automatically associate > an rpm with a channel just because errata for the rpm has been submitted > to that channel? > > It seems to me that packages should only be associated to a channel by > an explicit push of some sort (in my case rhnpush) and no other reason. > It could be the script itself did this as one section looks like it very > well might be pushing packages and not just errata. Im completely > unfamiliar with the api though. I've also run into this problem, it seems that publishing an erratum to multiple channels can cause associated packages to be pushed to some of those channels too. This can also cause centos5-packages to appear in centos4 channels :(. A workaround is to publish the erratum without associated packages and associating packages afterwards. In my opinion this is a bug, I don't know if there is already a bugzilla report for this one? > > I tried disassociating the errata with the channels but the rpm still > shows up in the package list. Its looking like the only method to > reliably clean this up will be start from scratch. Maybe I can just wipe > the rhel4 channels. > > If it was not the script and related to the errata then Im baffled as to > what caused this. It is very probable that this was caused by the script, deleting the packages should also work. You can probably search for packages with "el5" in their name through the api and delete the resulting packages from your rhel4 channels. > > This is the script I used (get_errata.pl): > http://sourceforge.net/projects/rhn2spacewalk/files/ I don't see an errata-publishing step in this script but I do see that errata are created with their relevant packages attached. What works for me when publishing an erratum through the api is: 1) Create erratum _without packages_. 2) Publish erratum to the relevant channels. 3) Add packages to the erratum. This way no packages are pushed to the wrong channel. An extra benefit is that publishing the erratum without packages is a lot quicker. ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
[Spacewalk-list] Packages associated with wrong channel
I have 4 base channels, rhel5 has children, basically: RHEL 4 Base - i386 RHEL 4 Base - x8664 RHEL 5 Base - i386 - RHEL 5 Updates - i386 RHEL 5 Base - x8664 - RHEL 5 Updates - x8664 ... firefox-3.6.13-2.el5.i386 was submitted in December of 2010. This is based off the actual dates from the /var/satellite directories and file. This rpm was only rhnpushed to RHEL 5 Updates - i386. RHEL 4 Base - i386 channel was created 03-30-2011. Well after the above rpm was pushed. I was checking up2date on a RHEL4 system and noticed there was an update for firefox and the associated rpm was you guessed it. The one above which is clearly not a RHEL4 rpm. Nor was it ever pushed to that channel(I still had my rhnpush command on the screen so I know it wasnt that plus if it was Id have all packages showing up not just some.). So I go browse the packages for RHEL 4 Base - i386 and there is the rpm firefox-3.6.13-2.el5.i386 in the list. After a long time of poking around I noticed a pattern and it appears to be related to errata that were submitted into spacewalk. The script I use is not capable of supplying a channel name so it is submitted to all channels. I presumed that even with the errata in all channels it would still only be the errata and only apply if the rpm existed in the channel. Actually it would seem by pushing the errata to all channels it results in those rpms becoming associated with the channel with one exception. Architecture is held correctly. That is, Im not seeing x8664 rpms associated with i386 channels. I realize that if this is what caused the problem then its the b0rked script but what Im wondering is does Spacewalk automatically associate an rpm with a channel just because errata for the rpm has been submitted to that channel? It seems to me that packages should only be associated to a channel by an explicit push of some sort (in my case rhnpush) and no other reason. It could be the script itself did this as one section looks like it very well might be pushing packages and not just errata. Im completely unfamiliar with the api though. I tried disassociating the errata with the channels but the rpm still shows up in the package list. Its looking like the only method to reliably clean this up will be start from scratch. Maybe I can just wipe the rhel4 channels. If it was not the script and related to the errata then Im baffled as to what caused this. This is the script I used (get_errata.pl): http://sourceforge.net/projects/rhn2spacewalk/files/ Thanks. begin:vcard fn:Jason Nielsen n:Nielsen;Jason org:Myriad Genetics, Inc.;IT email;internet:jniel...@myriad.com title:Unix Administrator tel;work:801-505-5123 tel;cell:801-782-7141 version:2.1 end:vcard ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
