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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> >> On Tue, Jan 15, 2013 at 2:18 AM, Pierre Casenove <[email protected]> >> 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 <[email protected]> >> >> >> >> 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 <[email protected]> >> >> 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 <[email protected]> >> >> >> >> >> >> 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 <[email protected]> >> >> >>> >> >> >>> 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 >> >> >>> <[email protected]> >> >> >>> 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 <[email protected]> >> >> >>> >> >> >> >>> >> 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 <[email protected]> >> >> >>> >>> >> >> >>> >>> On Thu, Jan 10, 2013 at 1:48 AM, Pierre Casenove >> >> >>> >>> <[email protected]> >> >> >>> >>> 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 <[email protected]> >> >> >>> >>> >> >> >> >>> >>> >> perl-Crypt-SSLeay >> >> >>> >>> > >> >> >>> >>> > >> >> >>> >>> > >> >> >>> >>> > >> >> >>> >>> > _______________________________________________ >> >> >>> >>> > Spacewalk-list mailing list >> >> >>> >>> > [email protected] >> >> >>> >>> > https://www.redhat.com/mailman/listinfo/spacewalk-list >> >> >>> >>> >> >> >>> >>> _______________________________________________ >> >> >>> >>> Spacewalk-list mailing list >> >> >>> >>> [email protected] >> >> >>> >>> https://www.redhat.com/mailman/listinfo/spacewalk-list >> >> >>> >> >> >> >>> >> >> >> >>> > >> >> >>> > >> >> >>> > _______________________________________________ >> >> >>> > Spacewalk-list mailing list >> >> >>> > [email protected] >> >> >>> > https://www.redhat.com/mailman/listinfo/spacewalk-list >> >> >>> >> >> >>> _______________________________________________ >> >> >>> Spacewalk-list mailing list >> >> >>> [email protected] >> >> >>> https://www.redhat.com/mailman/listinfo/spacewalk-list >> >> >> >> >> >> >> >> > >> >> > >> >> > _______________________________________________ >> >> > Spacewalk-list mailing list >> >> > [email protected] >> >> > https://www.redhat.com/mailman/listinfo/spacewalk-list >> >> >> >> _______________________________________________ >> >> Spacewalk-list mailing list >> >> [email protected] >> >> https://www.redhat.com/mailman/listinfo/spacewalk-list >> > >> > >> > >> > _______________________________________________ >> > Spacewalk-list mailing list >> > [email protected] >> > https://www.redhat.com/mailman/listinfo/spacewalk-list >> >> _______________________________________________ >> Spacewalk-list mailing list >> [email protected] >> https://www.redhat.com/mailman/listinfo/spacewalk-list > > _______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list
