[Spacewalk-list] Switching from rhn-clone-errata to eva-direct-errata-sync

Pierre Casenove pcasenove at gmail.com
Mon Jan 14 17:47:05 UTC 2013


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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20130114/8ab4831e/attachment.htm>


More information about the Spacewalk-list mailing list