Well, since the default rhn_check interval is 4 hours, you would have to
wait that long. Even after a manual rhn_check, the change isn’t
instantaneous because it takes a few minutes before the queued taskomatic
task executes. But if you wait overnight, all your servers should update.
On Sat, Dec
Bonjour Paul-André,
I did try your procedure and ...amazing !
Before applying the SP, I had to change the OWNER as it is rhnuser in my
case :
ALTER FUNCTION rpm.rpmstrcmp(string1 character varying, string2 character
varying) OWNER TO *rhnuser*;
To apply the SP :
# su - postgres
Last login:
Bonjour Phillipe,
Robert can vouch that this issue's actually been bugging me since SW 2.8
came out, when I found out that this was still a problem despite PR500's
improvements. I just haven't had enough time until this month to look at it
and dig through all the layers to figure out the root
Indeed, really appreciated Paul-Andre, I did not expect somebody to work so
fast to solve this issue !!
Not sure that I will be able to implement your new PostgreSQL SP in our
current Spacewalk platform, I need to understand before the full
implication of such modification and the harmless way to
Am 21. Dezember 2018 00:44:02 MEZ schrieb Paul-Andre Panon
:
>I created Bugzilla Bug 1661347 regarding this issue
Great job, Paul-Andre. Thanks.
Robert
>
>On Thursday, December 20, 2018 1:24 PM, I wrote:
>
>>The updated SP corrected the erroneous false positives, and also
>caught
>some
I created Bugzilla Bug 1661347 regarding this issue
On Thursday, December 20, 2018 1:24 PM, I wrote:
>The updated SP corrected the erroneous false positives, and also caught
some >packages which needed to be updated but weren't listed. Can somebody
put >this in a PR?
>Thanks,
>Paul-Andre
On Tuesday, December 18, 2018 2:59 PM, I wrote that I thought I had a
solution to the phantom packages with Ubuntu that I hadn't tested yet.
OK, there were a few typos and syntax errors, but this corrected stored
proc appears to work well.
SET search_path = rpm, pg_catalog;
create or
On Tuesday, December 11, 2018 4:34 PM, I wrote:
that I had tracked down the false positive "newer" Ubuntu packages to the
rhnServerNeededCache and that it was getting repopulated by the rhn_check.
>After clearing the unwanted entries in the rhnServerNeededCache table, I
verified that the
After clearing the unwanted entries in the rhnServerNeededCache table, I
verified that the incorrect packages had been cleared from the package
list for the servers. I then ran rhn_check on one of the clients that had
been cleared and after some delay (due to queuing a taskomatic task to
update
Am 11. Dezember 2018 01:51:11 MEZ schrieb Paul-Andre Panon
:
>Earlier today I wrote about the changes in PR500. That parsing actually
>seems to be OK after all because the EVR entries in the database are
>OK.
>
>That said, it looks like the query that generates the list of
>upgradeable
>packages
It looks like there aren't too many things that insert into the
rhnServerNeededCache.
./java/code/src/com/redhat/rhn/manager/errata/cache/ErrataCacheManager.jav
a calls some queries directly to insert into the table, and the
update_needed_cache stored procedure could also be a cause.
I've cleared
Earlier today I wrote about the changes in PR500. That parsing actually
seems to be OK after all because the EVR entries in the database are OK.
That said, it looks like the query that generates the list of upgradeable
packages in the Spacewalk GUI is system_upgradable_package_list in
On Thu, 6 Dec 2018 13:25:54 +0100, philippe bidault
wrote:
>Hi Robert,
>
>Thanks for the script, really appreciated. Already implemented in my
>Spacewalk and for the moment, working like a charm.
>In fact it even solved an issue I had with the "netplan.io" package
always
>flagged as upgradable
p(new_package)
> new_package.write("\n")
> new_package.close()
> sys.exit(0)
>
> Cheers,
> Robert
>
> *Gesendet:* Mittwoch, 05. Dezember 2018 um 21:10 Uhr
> *Von:* "philippe bidault"
> *An:* robert.pasche...@web.de
> *Cc:* spacewalk-list@redhat.
p(new_package)
new_package.write("\n")
new_package.close()
sys.exit(0)
Cheers,
Robert
Gesendet: Mittwoch, 05. Dezember 2018 um 21:10 Uhr
Von: "philippe bidault"
An: robert.pasche...@web.de
Cc: spacewalk-list@redhat.com
Betreff: Re: [Spacewalk-list] Ubuntu 18.
Hi Robert,
Good to know, thanks !!
Regarding the version comparison logic issue for .deb packages, is there a
solution that could be implemented ?
Regards,
Philippe.
On Wed, 5 Dec 2018 at 20:18, Robert Paschedag
wrote:
> Am 5. Dezember 2018 00:44:25 MEZ schrieb philippe bidault <
>
Am 5. Dezember 2018 00:44:25 MEZ schrieb philippe bidault
:
>Hi all,
>
>I am trying to make our Spacewalk 2.8 working with Ubuntu 18.04, but as
>well described here :
>https://github.com/spacewalkproject/spacewalk/wiki/DebianUbuntuSupportIn27
>
>... there are 3 main issues :
>
>"1- The current
Hi all,
I am trying to make our Spacewalk 2.8 working with Ubuntu 18.04, but as
well described here :
https://github.com/spacewalkproject/spacewalk/wiki/DebianUbuntuSupportIn27
... there are 3 main issues :
"1- The current version comparison logic does not distinct a dot from an
hyphen, a tilde
18 matches
Mail list logo
