[Spacewalk-list] Switching from rhn-clone-errata to eva-direct-errata-sync
Paul Robert Marino
prmarino1 at gmail.com
Fri Feb 15 00:05:07 UTC 2013
I added the bug fix in commit 11bce9d9019fbfe6e11189b98a9d3c5da7eddd4c
"
Update errata-tools/eva-direct-errata-sync.pl
applied the bug fix submitted by Pierre Casenove to insert the
description properly instead of the topic in the description field.
"
On Thu, Feb 14, 2013 at 12:06 PM, Paul Robert Marino
<prmarino1 at gmail.com> wrote:
> Pierre
> Thank you for pointing that out I'll correct it in the version on github
> latter today when I get a chance.
>
>
>
> -- Sent from my HP Pre3
>
> ________________________________
> On Feb 14, 2013 10:04 AM, Pierre Casenove <pcasenove at gmail.com> wrote:
>
> Hello,
> For your information,you have a bug in the published version of the script:
> the description field is set to the same value as the topic:
>
> my $new_errata_details={
> 'synopsis'=>$errata_details->{'synopsis'},
> 'advisory_name'=>rewrite_errata_name(%{$options},$errata->{'advisory_name'}),
> 'advisory_release'=>1,
> 'advisory_type'=>$errata_details->{'type'},
> 'product'=>'Unknown',
> 'topic'=>$errata_details->{'topic'},
> 'description'=>$errata_details->{'topic'},
> 'references'=>$errata_details->{'references'},
> 'notes'=>$errata_details->{'notes'},
> 'solution'=>'UPDATE'
>
>
> I've modified the previous code to set 'description'
> =>$errata_details->{'description'} and now it's all good.
>
> pierre
>
>
> 2013/1/17 Paul Robert Marino <prmarino1 at gmail.com>
>>
>> On Tue, Jan 15, 2013 at 2:18 AM, Pierre Casenove <pcasenove at gmail.com>
>> wrote:
>> > Hello Paul,
>> > Thanks, now the script works.
>> > But, I think that there is still an issue though, sorry!
>> > First, a question about options "rewritereleasefrom" and
>> > "rewritereleaseto":
>> > centos does not publish all their packages with a modified release. Does
>> > your script searches for the regular release (1.el6 for example), and if
>> > it
>> > fails, searches for the alternate release (1.el6.centos)? Or does it
>> > searches only for the alternate release?
>>
>> It searches for matches to both and if it finds both and in the odd
>> chance it would attempt to add both as if that were different
>> packages.
>>
>> >
>> > Now, the bug I found. Take errata RHSA-2013:0144 published for firefox.
>> > It
>> > is associated with the following packages:
>> > firefox-10.0.12-1.el6_3.i686.rpm
>> > firefox-10.0.12-1.el6_3.x86_64.rpm
>> > xulrunner-10.0.12-1.el6_3.i686.rpm
>> > xulrunner-10.0.12-1.el6_3.x86_64.rpm
>> > xulrunner-devel-10.0.12-1.el6_3.i686.rpm
>> > xulrunner-devel-10.0.12-1.el6_3.x86_64.rpm
>> >
>> > Notice that the release is set to "1.el6-3".
>> >
>> > Centos have published the following packages:
>> > firefox-10.0.12-1.el6.centos.i686
>> > firefox-10.0.12-1.el6.centos.x86_64
>> > xulrunner-10.0.12-1.el6.centos.i686
>> > xulrunner-10.0.12-1.el6.centos.x86_64
>> > xulrunner-devel-10.0.12-1.el6.centos.i686
>> > xulrunner-devel-10.0.12-1.el6.centos.x86_64
>> >
>> > The release is only "1.el6.centos".
>>
>> >
>> > In the current version, your script is searching for the following
>> > release:
>> > 1.el6.centos_3... which does not exist, and so the errata is never
>> > published.
>> > I've launch your script with "rewriteerratafrom el6_3" so that the
>> > errata
>> > gets created, but it is only a workaround, as, when RHEL 6.4 will be
>> > out, I
>> > will have some packages with el6_3 release and some with el6_4!
>> >
>> > What is your point of view on this?
>> I though about this possibility of this in the original design but
>> haven't documented it yet, because i haven't hardened it yet to detect
>> possible problematic mistakes.
>> Right now in the rewritereleasefrom field in a single quotes string
>> you can use a regex there are only two restriction.
>> 1) you can not use round brackets in the regex so 'el6_*\d*' should
>> work but 'el6(_\d)*' wont.
>> 2) there is no effective way to escape a single quote inside of single
>> quotes in a shell. This shouldn't be a problem as far as I know, but
>> I've seen it trip up people who used other applications I wrote so i
>> thought it was worth mentioning.
>>
>> In the future when I write the --loadjobconfig and --writejobconfig I
>> will give you the option of writing you own more complex replace
>> regexes for this. essentially my plan is that the --writejobconfig
>> option will create a boilerplate xml config file that matches the
>> command line options and documentation comments that will allow you to
>> tweak a lot more for things in more detail that would be difficult to
>> put into a command line string. I will be writing this feature next
>> because I have an as of yet unpublished experimental proof of concept
>> branch that wont work the way I want without it. I would like to get
>> the POC branch out there because it has some really cool features that
>> the Spacewalk API is not currently capable of. There have been ticket
>> posted for the API improvements but unfortunately none of them have
>> gotten any traction as far as I can tell so the POC version is meant
>> to help that along, and really thats the point of my overall project.
>>
>>
>>
>> >
>> > Another point: in order to speed up even more the sync, why don't you
>> > remove
>> > *debuginfo* and *beta* channels from errata sync (or at least add the
>> > option
>> > to do this)? I don't think that any erratas are created on these
>> > channels...
>>
>> I do intend to write source and destination channel exclude options I
>> just haven't had time to do it yet because of three other projects
>> with looming deadlines that are quickly approaching, but I will get to
>> it fairly soon.
>>
>>
>> >
>> > Thanks,
>> >
>> > Pierre
>> >
>> >
>> > 2013/1/14 Paul Robert Marino <prmarino1 at gmail.com>
>> >>
>> >> Pierre
>> >> I was able to reproduce the error and fix it. please try the version I
>> >> just put on github it should fix both issues.
>> >>
>> >> Thank you for reporting the error I haven't used the rewrite package
>> >> release name options in a while because I don't actually need them in
>> >> my environment, which is why I wasn't seeing the error my self.
>> >>
>> >>
>> >> On Mon, Jan 14, 2013 at 12:47 PM, Pierre Casenove <pcasenove at gmail.com>
>> >> wrote:
>> >> > What I don't understand is why, the array of options is correct
>> >> > before
>> >> > calling rewrite_package_release, but then, inside this function, it
>> >> > is
>> >> > only
>> >> > a string and not the full array.
>> >> >
>> >> > The perl error say the same thing: we expect to have an array, but we
>> >> > only
>> >> > have a string.
>> >> > $VAR1 = 'bugzilla_url';
>> >> >
>> >> >
>> >> > 2013/1/14 Pierre Casenove <pcasenove at gmail.com>
>> >> >>
>> >> >> Hello,
>> >> >> Here is my script:
>> >> >> #!/bin/bash
>> >> >> # Variables pour le script
>> >> >> export ERRATASRCUSER=
>> >> >> export ERRATADSTUSER=
>> >> >> export ERRATASRCPASS=
>> >> >> export ERRATADSTPASS=
>> >> >> /usr/local/sbin/eva-direct-errata-sync.pl
>> >> >> --sourcechannel=rhel-x86_64-server-5
>> >> >> --destinationchannel=centos-5-base-x64
>> >> >> --rewritepackagereleasefrom=el5 --rewritepackagereleaseto=el5.centos
>> >> >> --rewriteerratanamefrom=RH --rewriteerratanameto=COS5X64
>> >> >> --startfromprevious=week -r -v
>> >> >>
>> >> >> I've tried to set -b option, but it fails with the same error... I
>> >> >> can't
>> >> >> find why.
>> >> >>
>> >> >> Geting details for COS5X64SA-2013:0128
>> >> >> getting RHSA-2013:0128 from the source
>> >> >> Geting details for RHSA-2013:0128
>> >> >> getting details for package ricci
>> >> >> Can't use string ("bugzilla_url") as a HASH ref while "strict refs"
>> >> >> in
>> >> >> use
>> >> >> at /usr/local/sbin/eva-direct-errata-sync.pl line 492.
>> >> >>
>> >> >>
>> >> >> Thanks in advance,
>> >> >>
>> >> >> Pierre
>> >> >>
>> >> >>
>> >> >>
>> >> >> 2013/1/14 Paul Robert Marino <prmarino1 at gmail.com>
>> >> >>>
>> >> >>> Hello Pierre
>> >> >>>
>> >> >>> huh thats odd
>> >> >>>
>> >> >>> I know the default bugzilla url worked at one point but you seem to
>> >> >>> be
>> >> >>> right Ill put a patch up latter today when I get a chance. I'm
>> >> >>> surprised because I never ran into this error. For now setting the
>> >> >>> bugzilla URL via the command line option should work around it.
>> >> >>>
>> >> >>> This is also odd for an other reason in the current version on
>> >> >>> github
>> >> >>> that lin number has nothing to do with the bugzilla url
>> >> >>>
>> >> >>> please send me the full command line options so I can try to
>> >> >>> reproduce
>> >> >>> it
>> >> >>> NOTE please do not include your username and passwords.
>> >> >>>
>> >> >>>
>> >> >>> On Mon, Jan 14, 2013 at 8:20 AM, Pierre Casenove
>> >> >>> <pcasenove at gmail.com>
>> >> >>> wrote:
>> >> >>> > Hello,
>> >> >>> > Using Data::dumper, I've tried to debug this...
>> >> >>> > I dump $options just before calling rewrite_package_release and
>> >> >>> > then
>> >> >>> > inside
>> >> >>> > this procedure:
>> >> >>> > before calling it:
>> >> >>> > $VAR1 = {
>> >> >>> > 'bugzilla_url' => undef,
>> >> >>> > 'verbose' => undef,
>> >> >>> > 'dst_passwd' => '',
>> >> >>> > 'rewrite_package_release_from' => 'el5',
>> >> >>> > 'rewrite_package_release_to' => 'el5.centos',
>> >> >>> > 'src_channel' => 'rhel-x86_64-server-5',
>> >> >>> > 'dst_host' => 'localhost',
>> >> >>> > 'batch_config' => undef,
>> >> >>> > 'help' => undef,
>> >> >>> > 'start_date' => '2013-1-07 13:11:17',
>> >> >>> > 'dryrun' => undef,
>> >> >>> > 'src_passwd' => '',
>> >> >>> > 'src_host' => 'rhn.redhat.com',
>> >> >>> > 'dst_channel' => 'centos-5-base-x64',
>> >> >>> > 'start_from_previous' => 'week',
>> >> >>> > 'recursive' => 1,
>> >> >>> > 'dst_user' => 'erratasync',
>> >> >>> > 'rewrite_errata_name_from' => 'RH',
>> >> >>> > 'end_date' => undef,
>> >> >>> > 'write_config' => undef,
>> >> >>> > 'src_user' => 'rhn-mreposync',
>> >> >>> > 'rewrite_errata_name_to' => 'COS5X64'
>> >> >>> > };
>> >> >>> > Inside the procedure:
>> >> >>> > $VAR1 = 'bugzilla_url';
>> >> >>> >
>> >> >>> > I'm not a perl expert, but it seems that the array of option is
>> >> >>> > not
>> >> >>> > correctly passed...
>> >> >>> >
>> >> >>> > By the way, in the current code, I think that there is a bug:
>> >> >>> >
>> >> >>> > unless($options->{'bugzilla_url'}){
>> >> >>> > print_verbose(%{$options},"No bugzilla url specified
>> >> >>> > setting
>> >> >>> > to
>> >> >>> > the default
>> >> >>> > \"https://bugzilla.redhat.com/\"\n");
>> >> >>> > }
>> >> >>> >
>> >> >>> > The bugzilla_url is never set to the default!
>> >> >>> >
>> >> >>> > Pierre
>> >> >>> >
>> >> >>> >
>> >> >>> >
>> >> >>> > 2013/1/14 Pierre Casenove <pcasenove at gmail.com>
>> >> >>> >>
>> >> >>> >> Hello,
>> >> >>> >> I still have one problem.
>> >> >>> >> I want to use options --rewritepackagereleasefrom=el5
>> >> >>> >> --rewritepackagereleaseto=el5.centos for centos errata sync.
>> >> >>> >> When I try to sync errata RHSA-2013:0128, I get the following
>> >> >>> >> error:
>> >> >>> >>
>> >> >>> >> checking if RHSA-2013:0128 exists on the destination host
>> >> >>> >> Geting details for COS5X64SA-2013:0128
>> >> >>> >> getting RHSA-2013:0128 from the source
>> >> >>> >> Geting details for RHSA-2013:0128
>> >> >>> >> getting details for package ricci
>> >> >>> >> Can't use string ("bugzilla_url") as a HASH ref while "strict
>> >> >>> >> refs"
>> >> >>> >> in
>> >> >>> >> use
>> >> >>> >> at /usr/local/sbin/eva-direct-errata-sync.pl line 492.
>> >> >>> >>
>> >> >>> >> Thanks in advance,
>> >> >>> >>
>> >> >>> >> Pierre
>> >> >>> >>
>> >> >>> >>
>> >> >>> >> 2013/1/10 Paul Robert Marino <prmarino1 at gmail.com>
>> >> >>> >>>
>> >> >>> >>> On Thu, Jan 10, 2013 at 1:48 AM, Pierre Casenove
>> >> >>> >>> <pcasenove at gmail.com>
>> >> >>> >>> wrote:
>> >> >>> >>> > Hello Paul.
>> >> >>> >>> > First, thanks a lot for this hint, now it works... but with a
>> >> >>> >>> > little
>> >> >>> >>> > twist:
>> >> >>> >>> > as I'm setting environment variables, I use proxy to connect
>> >> >>> >>> > to
>> >> >>> >>> > RHN
>> >> >>> >>> > AND
>> >> >>> >>> > to
>> >> >>> >>> > my local spacewalk server...
>> >> >>> >>> > How could I unset PROXY variables for Spacewalk, and not for
>> >> >>> >>> > RHN?
>> >> >>> >>> I haven't looked into it yet but I think this is a limitation
>> >> >>> >>> LWP
>> >> >>> >>> inherits from one of it many dependencies. It will take time
>> >> >>> >>> for
>> >> >>> >>> me
>> >> >>> >>> to
>> >> >>> >>> investigate it there is a workaround but your solution using
>> >> >>> >>> HTTP
>> >> >>> >>> for
>> >> >>> >>> the local connection and HTTPS to rhn may be the only practical
>> >> >>> >>> workaround right now.
>> >> >>> >>> > By the way, great script, it works like a charm (except this
>> >> >>> >>> > proxy
>> >> >>> >>> > setting!)
>> >> >>> >>> >
>> >> >>> >>> > I still have three questions:
>> >> >>> >>> > - For Centos, I have a base channel named Centos 6 Base and a
>> >> >>> >>> > child
>> >> >>> >>> > channel
>> >> >>> >>> > for the updates. Can your script find packages in both?
>> >> >>> >>> yes it can
>> >> >>> >>> > - For RHEL channels: Do i have to call the script twice to
>> >> >>> >>> > get
>> >> >>> >>> > erratas
>> >> >>> >>> > from
>> >> >>> >>> > RHEL 6 Server channels and RHEL 6 Optionnal channel, or does
>> >> >>> >>> > your
>> >> >>> >>> > script
>> >> >>> >>> > automatically find everything when calling it and specifying
>> >> >>> >>> > the
>> >> >>> >>> > rhel 6
>> >> >>> >>> > server channel?
>> >> >>> >>> No it will scan all channels on the source you have access to
>> >> >>> >>> under
>> >> >>> >>> the base channel
>> >> >>> >>>
>> >> >>> >>> > - I'm planning to call the script once a day, with the
>> >> >>> >>> > "startfromprevious"
>> >> >>> >>> > option. Imagine the following case, which happens quite
>> >> >>> >>> > frequently:
>> >> >>> >>> > RedHat
>> >> >>> >>> > publishes a RHSA with the associated packages on day 1. The
>> >> >>> >>> > next
>> >> >>> >>> > night,
>> >> >>> >>> > I'm
>> >> >>> >>> > going the download the package and create the errata for
>> >> >>> >>> > RHEL.
>> >> >>> >>> > But
>> >> >>> >>> > from
>> >> >>> >>> > centos, it happens that the packages are not yet available
>> >> >>> >>> > (they
>> >> >>> >>> > are
>> >> >>> >>> > published a few days after). Your script will skip the errata
>> >> >>> >>> > creation
>> >> >>> >>> > for
>> >> >>> >>> > centos... but even when the package will be available, the
>> >> >>> >>> > errata
>> >> >>> >>> > will
>> >> >>> >>> > never
>> >> >>> >>> > be re-created, as it starts with the last launch date. How
>> >> >>> >>> > can I
>> >> >>> >>> > address
>> >> >>> >>> > this?
>> >> >>> >>> I usually use startfromprevious with month with scientific
>> >> >>> >>> linux
>> >> >>> >>> and
>> >> >>> >>> year with Centos because it doesn't take that much longer and
>> >> >>> >>> resolves
>> >> >>> >>> this for both distros
>> >> >>> >>>
>> >> >>> >>> >
>> >> >>> >>> > Thanks in advance,
>> >> >>> >>> >
>> >> >>> >>> > Pierre
>> >> >>> >>> >
>> >> >>> >>> >
>> >> >>> >>> >
>> >> >>> >>> > 2013/1/4 Paul Robert Marino <prmarino1 at gmail.com>
>> >> >>> >>> >>
>> >> >>> >>> >> perl-Crypt-SSLeay
>> >> >>> >>> >
>> >> >>> >>> >
>> >> >>> >>> >
>> >> >>> >>> >
>> >> >>> >>> > _______________________________________________
>> >> >>> >>> > Spacewalk-list mailing list
>> >> >>> >>> > Spacewalk-list at redhat.com
>> >> >>> >>> > https://www.redhat.com/mailman/listinfo/spacewalk-list
>> >> >>> >>>
>> >> >>> >>> _______________________________________________
>> >> >>> >>> Spacewalk-list mailing list
>> >> >>> >>> Spacewalk-list at redhat.com
>> >> >>> >>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>> >> >>> >>
>> >> >>> >>
>> >> >>> >
>> >> >>> >
>> >> >>> > _______________________________________________
>> >> >>> > Spacewalk-list mailing list
>> >> >>> > Spacewalk-list at redhat.com
>> >> >>> > https://www.redhat.com/mailman/listinfo/spacewalk-list
>> >> >>>
>> >> >>> _______________________________________________
>> >> >>> Spacewalk-list mailing list
>> >> >>> Spacewalk-list at redhat.com
>> >> >>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > Spacewalk-list mailing list
>> >> > Spacewalk-list at redhat.com
>> >> > https://www.redhat.com/mailman/listinfo/spacewalk-list
>> >>
>> >> _______________________________________________
>> >> Spacewalk-list mailing list
>> >> Spacewalk-list at redhat.com
>> >> https://www.redhat.com/mailman/listinfo/spacewalk-list
>> >
>> >
>> >
>> > _______________________________________________
>> > Spacewalk-list mailing list
>> > Spacewalk-list at redhat.com
>> > https://www.redhat.com/mailman/listinfo/spacewalk-list
>>
>> _______________________________________________
>> Spacewalk-list mailing list
>> Spacewalk-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
>
More information about the Spacewalk-list
mailing list