[Spacewalk-list] Switching from rhn-clone-errata to eva-direct-errata-sync
Paul Robert Marino
prmarino1 at gmail.com
Thu Jan 17 00:32:58 UTC 2013
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
More information about the Spacewalk-list
mailing list