[Spacewalk-list] Switching from rhn-clone-errata to eva-direct-errata-sync
Pierre Casenove
pcasenove at gmail.com
Thu Feb 14 14:59:24 UTC 2013
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20130214/a6e6607b/attachment.htm>
More information about the Spacewalk-list
mailing list