[Spacewalk-list] Switching from rhn-clone-errata to eva-direct-errata-sync
Pierre Casenove
pcasenove at gmail.com
Tue Jan 15 07:18:45 UTC 2013
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?
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?
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...
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20130115/df69b834/attachment.htm>
More information about the Spacewalk-list
mailing list