Re: [Spacewalk-devel] Errata api problem
Now that there is enough information i looked and found an exiting bug ticket for this https://bugzilla.redhat.com/show_bug.cgi?id=834569 On Thu, Nov 22, 2012 at 12:58 PM, Paul Robert Marino wrote: > well here was an intresting and succesfull experiment > I manually added the packages to the errata via sql > " > spaceschema=# select id from rhnErrata where advisory_name like > 'SLBA-2012:1302'; > id > --- > 29954 > (1 row) > > spaceschema=# select * from rhnerratapackage where errata_id = '29954'; > errata_id | package_id |created| modified > ---++---+--- > 29954 | 107482 | 2012-11-21 18:12:48.351349-05 | 2012-11-21 > 18:12:48.351349-05 > 29954 | 107483 | 2012-11-21 18:12:48.351349-05 | 2012-11-21 > 18:12:48.351349-05 > (2 rows) > > spaceschema=# insert into rhnerratapackage > (errata_id,package_id,created,modified) > VALUES(29954,107890,'2012-11-21 18:12:48.351349-05','2012-11-21 > 18:12:48.351349-05'); > INSERT 0 1 > spaceschema=# insert into rhnerratapackage > (errata_id,package_id,created,modified) > VALUES(29954,107889,'2012-11-21 18:12:48.351349-05','2012-11-21 > 18:12:48.351349-05') > ; > INSERT 0 1 > spaceschema=# > > " > > then I refreshed the page listing the packages in the errata > and I got this > " > CentOS 6 FastTrack (x86_64) > sha256:e85a76b7a959db0566c656b82fb4ad69ddec2ab448e111086716c63e18945c33 > cvs-1.11.23-15.el6-x86_64 > sha256:455178ca3ab78b5f0403da16f4512ac9f5d2481e191329f5b7f02ef7b05b2423 > cvs-inetd-1.11.23-15.el6-noarch > > Scientific Linux 6 Updates FastBug (x86_64) > sha256:b2c4eeb020973c966747ccbd2711ae8f25f1f35f2be12211e21ba4118fef4e2f > cvs-1.11.23-15.el6-x86_64 > sha256:d09f12ee26dada51aafa210846c120dff2fab3a8ff17ec1fb6d510677cfb6784 > cvs-inetd-1.11.23-15.el6-noarch > " > It works so I'm now leaning in the direction that this is an API bug > because clearly its possible > > I think we now have enough to put together a bug report > I just have one more test i want to do to complete it but it seems > like this may be fixable. > > > On Wed, Nov 21, 2012 at 5:33 PM, Paul Robert Marino > wrote: >> Well I understand your point about mixing distros but more often than >> not often they are the same and with Scientific Linux they are always >> the same as RHEL's. >> also there is a bigger concern mixing architectures and releases in a >> single errata is common place even in RHN. >> Ive seen instances where a 32bit library or app on x86_64 requires a >> 64bit dependance on the x86_64 version of the distro this happens for >> various reasons. Ive also seen instances where onarch packages weren't >> actually architecture independent this often happens with Perl modules >> where a new version added XS code and the package maintainer didn't >> catch it. In these cases it would represent a significant problem. >> >> >> >> >> >> On Wed, Nov 21, 2012 at 3:20 PM, Franky Van Liedekerke >> wrote: >>> On Tue, 20 Nov 2012 22:28:07 -0500 >>> Paul Robert Marino wrote: >>> I'm not sure if I should classify this as bug or an rfe but either way ill put in a ticket tommorow. I ran into an intresting problem. There is a common case where you have for example centos channels and scientific linux channels where you may have different packages with the same name in different base channels. It would be nice to be able to publish a single errata with multiple base channels from different distros that could cover them all but what I've found in testing is there seems to be no way to do that safely. When you try to do that the package from one channel gets published into the other resulting in a duplicate package in the other channels the first one being the original package for that distro the second being the package from the first channel. This is actually a common problem and complaint for most of the errata sync scripts. The resultt is it breaks yum and by extention anacondas ability to use the channel. After a bit of investigation I found it was a limitation of the api, I haven't dug into the database yet but. This is something that needs investigation because it would eleviate a lot of the dificulties users have with the errata sync scripts. >>> >>> Why try to "combine" errata's from different distro's? It seems like >>> a very bad idea: one should know for which distro/base channel the >>> errata is. And a CentOS errata might totally not be related to a redhat >>> errata, even if it has the same name (the packages might be different). >>> The way I coded it up: get a list of packages per channel and then >>> compare these with the ones mentioned in the errata. Easy and >>> simple ... of course I only do one-on-one channel errata sync, but it >>> never failed me yet. >>> For those interested (shameless adv): one errata script for both redhat >>> and/or centos er
Re: [Spacewalk-devel] Errata api problem
well here was an intresting and succesfull experiment I manually added the packages to the errata via sql " spaceschema=# select id from rhnErrata where advisory_name like 'SLBA-2012:1302'; id --- 29954 (1 row) spaceschema=# select * from rhnerratapackage where errata_id = '29954'; errata_id | package_id |created| modified ---++---+--- 29954 | 107482 | 2012-11-21 18:12:48.351349-05 | 2012-11-21 18:12:48.351349-05 29954 | 107483 | 2012-11-21 18:12:48.351349-05 | 2012-11-21 18:12:48.351349-05 (2 rows) spaceschema=# insert into rhnerratapackage (errata_id,package_id,created,modified) VALUES(29954,107890,'2012-11-21 18:12:48.351349-05','2012-11-21 18:12:48.351349-05'); INSERT 0 1 spaceschema=# insert into rhnerratapackage (errata_id,package_id,created,modified) VALUES(29954,107889,'2012-11-21 18:12:48.351349-05','2012-11-21 18:12:48.351349-05') ; INSERT 0 1 spaceschema=# " then I refreshed the page listing the packages in the errata and I got this " CentOS 6 FastTrack (x86_64) sha256:e85a76b7a959db0566c656b82fb4ad69ddec2ab448e111086716c63e18945c33 cvs-1.11.23-15.el6-x86_64 sha256:455178ca3ab78b5f0403da16f4512ac9f5d2481e191329f5b7f02ef7b05b2423 cvs-inetd-1.11.23-15.el6-noarch Scientific Linux 6 Updates FastBug (x86_64) sha256:b2c4eeb020973c966747ccbd2711ae8f25f1f35f2be12211e21ba4118fef4e2f cvs-1.11.23-15.el6-x86_64 sha256:d09f12ee26dada51aafa210846c120dff2fab3a8ff17ec1fb6d510677cfb6784 cvs-inetd-1.11.23-15.el6-noarch " It works so I'm now leaning in the direction that this is an API bug because clearly its possible I think we now have enough to put together a bug report I just have one more test i want to do to complete it but it seems like this may be fixable. On Wed, Nov 21, 2012 at 5:33 PM, Paul Robert Marino wrote: > Well I understand your point about mixing distros but more often than > not often they are the same and with Scientific Linux they are always > the same as RHEL's. > also there is a bigger concern mixing architectures and releases in a > single errata is common place even in RHN. > Ive seen instances where a 32bit library or app on x86_64 requires a > 64bit dependance on the x86_64 version of the distro this happens for > various reasons. Ive also seen instances where onarch packages weren't > actually architecture independent this often happens with Perl modules > where a new version added XS code and the package maintainer didn't > catch it. In these cases it would represent a significant problem. > > > > > > On Wed, Nov 21, 2012 at 3:20 PM, Franky Van Liedekerke > wrote: >> On Tue, 20 Nov 2012 22:28:07 -0500 >> Paul Robert Marino wrote: >> >>> I'm not sure if I should classify this as bug or an rfe but either >>> way ill put in a ticket tommorow. I ran into an intresting problem. >>> There is a common case where you have for example centos channels and >>> scientific linux channels where you may have different packages with >>> the same name in different base channels. >>> It would be nice to be able to publish a single errata with multiple >>> base channels from different distros that could cover them all but >>> what I've found in testing is there seems to be no way to do that >>> safely. When you try to do that the package from one channel gets >>> published into the other resulting in a duplicate package in the >>> other channels the first one being the original package for that >>> distro the second being the package from the first channel. >>> This is actually a common problem and complaint for most of the >>> errata sync scripts. The resultt is it breaks yum and by extention >>> anacondas ability to use the channel. >>> After a bit of investigation I found it was a limitation of the api, I >>> haven't dug into the database yet but. This is something that needs >>> investigation because it would eleviate a lot of the dificulties >>> users have with the errata sync scripts. >> >> Why try to "combine" errata's from different distro's? It seems like >> a very bad idea: one should know for which distro/base channel the >> errata is. And a CentOS errata might totally not be related to a redhat >> errata, even if it has the same name (the packages might be different). >> The way I coded it up: get a list of packages per channel and then >> compare these with the ones mentioned in the errata. Easy and >> simple ... of course I only do one-on-one channel errata sync, but it >> never failed me yet. >> For those interested (shameless adv): one errata script for both redhat >> and/or centos errata sync's, without cross contamination issues and >> with proxy support (but only one channel at the time): >> https://github.com/liedekef/spacewalk_scripts >> >> Franky >> >> ___ >> Spacewalk-devel mailing list >> Spacewalk-devel@redhat.com >> https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] List of installable packages: API vs. Web UI
On 11/08/2012 12:18 PM, Johannes Renner wrote: > On 11/05/2012 12:03 PM, Tomas Lestach wrote: >> ... >> If there's a bug in the API call, we of course fix it. >> But we try to keep the current API interface as is. Spacewalk users have >> their >> scripts using our API calls and we do not want to break the scripts by >> renaming/deleting existing API calls. (Introducing of new sensefull APIs is >> always good. :) >> >> So, it is important that the API behaves according to its name. It the name >> and behavior do not match, we fix the behavior according to the name and can >> introduce a new API in case the behavior of the original API was helpfull. >> >> However, internal naming has lower priority, because the users do not come >> into contact with it, so it cannot be confusing for them. (But we of course >> try to keep the naming sensefull as well.) > > Ok, I might come up with a patch these days, fixing the existing API call so > it behaves like its name is suggesting + maybe add a new call to provide the > previous behavior in addition to that. > > Thanks for the explanations, > Johannes Ok, here we go: The first patch should fix the query for the existing API call so that actually only the very latest versions of packages will be returned, as the name of the function suggests. (Note that the query might have been working for you correctly before, but only in case all of packages and updates are provided through one single channel, I guess). Further, the query is internally renamed like this (in Package_queries.xml): "system_latest_all_available_packages" -> "system_latest_available_packages" The second patch adds a new API call to list all versions and releases of packages that can be installed to a given system: system.list_all_installable_packages(key, sid) Unfortunately the previous query could not be reused, since it didn't actually return all of the versions and releases of a package (as noted above). It rather returned only the max EVR version of each package in every channel the system is subscribed to. This might have lead to correct behavior for list_latest, but only in case all packages are provided through _one_ single channel. So the second patch also contains a new query to handle the list_all_... case. Regards, Johannes -- SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer >From 84295bbb50bf32bfbec425d3aca516eeb8276d85 Mon Sep 17 00:00:00 2001 From: Johannes Renner Date: Wed, 21 Nov 2012 18:21:20 +0100 Subject: [PATCH] Fix query for API call system.listLatestInstallablePackages --- .../common/db/datasource/xml/Package_queries.xml | 33 +++- .../redhat/rhn/manager/system/SystemManager.java |2 +- 2 files changed, 20 insertions(+), 15 deletions(-) diff --git a/java/code/src/com/redhat/rhn/common/db/datasource/xml/Package_queries.xml b/java/code/src/com/redhat/rhn/common/db/datasource/xml/Package_queries.xml index 44bc39d..38e7f4b 100644 --- a/java/code/src/com/redhat/rhn/common/db/datasource/xml/Package_queries.xml +++ b/java/code/src/com/redhat/rhn/common/db/datasource/xml/Package_queries.xml @@ -6,20 +6,19 @@ - + SELECT pn.name AS name, -full_list.id AS id, +pkg.id AS id, NVL((full_list.evr).version, ' ') AS version, NVL((full_list.evr).release, ' ') AS release, NVL((full_list.evr).epoch, ' ') AS epoch, NVL(full_list.arch_label, ' ') AS arch_label FROM ( SELECT p.name_id name_id, - p.id, - p.evr_id, max(pe.evr) evr, + pa.id as arch_id, pa.label as arch_label FROM rhnPackageArch PA, rhnPackageEVR PE, rhnPackage P, rhnChannelNewestPackage CNP, rhnServerChannel SC @@ -28,17 +27,23 @@ SELECT AND cnp.package_id = p.id AND p.evr_id = pe.id AND p.package_arch_id = pa.id - GROUP BY p.name_id, p.id, p.evr_id, pa.label + GROUP BY p.name_id, pa.label, pa.id ) full_list, - rhnPackageName pn - WHERE full_list.name_id = pn.id - AND NOT EXISTS (SELECT 1 - FROM rhnServerPackage SP, rhnPackageEVR PE2 - WHERE SP.server_id = :sid - AND SP.name_id = full_list.name_id - AND SP.evr_id = PE2.id - AND PE2.evr >= full_list.evr) -ORDER BY UPPER(pn.name), full_list.evr + rhnPackage pkg + join rhnPackageName pn on pkg.name_id = pn.id + join rhnPackageEVR pevr on pkg.evr_id = pevr.id + join rhnChannelPackage CP on CP.package_id = pkg.id + join rhnServerChannel SC on SC.channel_id = CP.channel_id + WHERE full_list.name_id = pkg.name_id + AND full_list.evr = pevr.evr + AND full_list.arch_id = pkg.package_arch_id + AND SC.server_id = :sid + AND NOT EXISTS (SELECT 1 + FROM rhnServerPackage
