Re: [Spacewalk-list] Debian package comparison failing.
Hi Paul, Yes sorry for this, false alert, the repodata for this repository was broken. Regards, Philippe. On Wed, 31 Jul 2019 at 20:53, Robert Paschedag wrote: > Hi Paul, > > Problem has been solved. All good. Your code works. It was an outdated > Packages.gz file. > > Robert > > sent from my mobile device > > > Originale Nachricht > Von: Paul-Andre Panon > Gesendet: Wed Jul 31 20:08:45 GMT+02:00 2019 > An: spacewalk-list@redhat.com > Betreff: Re: [Spacewalk-list] Debian package comparison failing. > > Well, looks like the Ubuntu apt-get is the one that's getting it wrong > here and that Spacewalk is correct (for these packages). That's what it > looked like to me on your first e-mail but I wasn't certain, however this > seems to confirm it. Now, have you tried to update with rhn_check after > approving the package updates in Spacewalk? > > It's been annoying me that Ubuntu seems to take great liberties with the > Debian package versioning standards but it appears to be a new low for > them to manage to come up with versions that seem to break their own > hacked up versioning algorithms. You could try to crank up the logging on > the rhn_check, to verify that those package versions are being recommended > by Spacewalk (or look at the event history?) but if Spacewalk is > suggesting python-ethtool-0.14-1.amd64-deb and the apt-get client is > rejecting it, then the client is wrong. If that only happens with apt-get > however, then maybe there's a bug in the apt-get=>spacewalk glue/shim in > separating and parsing the package version and breaking it down into > epoch/upstream-version/Debian-version (which would be my guess with > python-gobject-2 but unfortunately doesn't make sense with the others) > > Cheers, > > Paul-Andre > > On Tue, 30 Jul 2019 17:36:34 +0200, philippe bidault > wrote: > >Nope, no lock or nothing similar: > > > >root@debian10:~# dpkg -l | grep python-eth > >ii python-ethtool 0.12-1.1 amd64 > > Python bindings for the ethtool kernel interface > > > >Regards, > >Philippe. > > > >On Tue, 30 Jul 2019 at 15:02, Michael Mraka > >wrote: > > > >> philippe bidault: > >> > Hi Michael, > >> > > >> > Here are the installed versions: > >> > > >> > root@debian10:~# dpkg -l | grep python-go > >> > ii python-gobject 3.22.0-2 all > >> > Python 2.x bindings for GObject - transitional package > >> > ii python-gobject-22.28.6-13 amd64 > >> >deprecated static Python bindings for the GObject library > >> > root@debian10:~# dpkg -l | grep python-eth > >> > ii python-ethtool 0.12-1.1 amd64 > >> >Python bindings for the ethtool kernel interface > >> > > >> > So this is in fact matching what appears in the "Installed Package" > column > >> > in the Spacewalk web console. The Debian 10 client just does not see > >> > the 3 updates. > >> > >> Can't they be somehow excluded / version-locked / ... etc? > >> If you use dpkg to list all available python-ethtool packages can you > >> see > >> python-ethtool-0.14-1 among them? > >> > >> > Regards, > >> > Philippe. > >> ... > >> > > > Latest Package Installed Package > >> > > > python-ethtool-0.14-1.amd64-deb > python-ethtool-0.12-1.1.amd64-deb > >> > > > python-gobject-3.30.4-1.all-deb > python-gobject-3.22.0-2.all-deb > >> > > > python-gobject-2-2.28.6-13+b1.amd64-deb > python-gobject-2-2.28.6-13.amd64-deb > >> > > > > >> > > > But on the registered debian 10 server, "apt update" is telling > me that all > >> > > > the packages are already up-to-date. > >> > > > >> > > What version of python-ethtool, python-gobject and > >> > > python-gobject-2 do you have installed on the debian server? > >> > >> Regards, > >> > >> -- > >> Michael Mr?ka > >> System Management Engineering, Red Hat > >> > > > > -- > At Motorola Solutions and our subsidiaries, your privacy is important to > us. That is why we have taken appropriate measures to ensure the data you > provide to us is kept secure. To learn more about how we process your > personal information, how we comply with applicable data protection laws, >
Re: [Spacewalk-list] Debian package comparison failing.
Hi, I did directly remove the corresponding repodata directory, so in your case /var/cache/rhn/repodata/debian-9, and to trigger a regeneration, an "apt clean all && apt update" on a debian 9 registered on your spacewalk should do the trick. Philippe. On Wed, 31 Jul 2019 at 17:53, wrote: > Hi > > > > I am trying to get Spacewalk to play with Debian and I am facing the same > problem (/var/cache/rhn/repodata/debian-9/Packages.gz is empty and doesn’t > get changed even after syncing new packages). > > > > How did you regenerate the repodata? I tried with spacecmd > softwarechannel_regenerateyumcache but that didn’t work on my server. > > > > Regards, > > Javier > > > > *Von:* spacewalk-list-boun...@redhat.com < > spacewalk-list-boun...@redhat.com> *Im Auftrag von *philippe bidault > *Gesendet:* Wednesday, July 31, 2019 5:16 PM > *An:* spacewalk-list@redhat.com > *Betreff:* Re: [Spacewalk-list] Debian package comparison failing. > > > > Thanks Robert, good catch. Indeed, the Packages file was not complete, > seems that it was built during the reposync process of the repository as > lots of package was missing in the repodata. > > I did force Spacewalk to regenerate it, and all good now. > > > > Regards, > > Philippe. > > > > On Wed, 31 Jul 2019 at 13:22, Robert Paschedag > wrote: > > Please check, that you repo metadata has been correctly regenerated. Might > be, that within the channel, the new package is there, but the metadata has > not been refreshed (the Packages.gz) is still old. > > Robert > > sent from my mobile device > > > Originale Nachricht > Von: philippe bidault > Gesendet: Wed Jul 31 08:30:07 GMT+02:00 2019 > An: spacewalk-list@redhat.com > Betreff: Re: [Spacewalk-list] Debian package comparison failing. > > Hi Robert, > > No, this is so strange, absolutely no trace through apt of the new packages > proposed by Spacewalk on the Debian server. I need to troubleshoot this > deeper. > > root@debian10:~# apt-cache show python-gobject > Package: python-gobject > Status: install ok installed > Priority: extra > Section: oldlibs > Installed-Size: 323 > Maintainer: Debian GNOME Maintainers < > pkg-gnome-maintain...@lists.alioth.debian.org> > Architecture: all > Source: pygobject > Version: 3.22.0-2 > Depends: python-gi (>= 3.22.0-2), python-gobject-2 > Description: Python 2.x bindings for GObject - transitional package > This package will bring the two versions of GObject Python modules: the > deprecated gobject module, and the new gobject-introspection system. It > is here for upgrade purposes only. You can remove it safely when > nothing else depends on it. > Description-md5: 0972cedec40e0869495e1025aa320af1 > Homepage: https://wiki.gnome.org/Projects/PyGObject > > Regards, > Philippe. > > On Tue, 30 Jul 2019 at 21:53, Robert Paschedag > wrote: > > > You can also try to install one of the packages with "apt-get -o > > Debug::pkgProblemResolver install ..." > > > > Robert > > > > sent from my mobile device > > > > > > Originale Nachricht > > Von: philippe bidault > > Gesendet: Tue Jul 30 17:36:34 GMT+02:00 2019 > > An: spacewalk-list@redhat.com > > Betreff: Re: [Spacewalk-list] Debian package comparison failing. > > > > Nop, no lock or nothing similar: > > > > root@debian10:~# dpkg -l | grep python-eth > > ii python-ethtool 0.12-1.1 amd64 > >Python bindings for the ethtool kernel interface > > > > Regards, > > Philippe. > > > > On Tue, 30 Jul 2019 at 15:02, Michael Mraka > > wrote: > > > > > philippe bidault: > > > > Hi Michael, > > > > > > > > Here are the installed versions: > > > > > > > > root@debian10:~# dpkg -l | grep python-go > > > > ii python-gobject 3.22.0-2 all > > > > Python 2.x bindings for GObject - transitional package > > > > ii python-gobject-22.28.6-13 amd64 > > > >deprecated static Python bindings for the GObject library > > > > root@debian10:~# dpkg -l | grep python-eth > > > > ii python-ethtool 0.12-1.1 amd64 > > > >Python bindings for the ethtool kernel interface > > > > > > > > So this is in fact matching what appears in the "Installed Package" > > > column > > > > in the
Re: [Spacewalk-list] Debian package comparison failing.
Thanks Robert, good catch. Indeed, the Packages file was not complete, seems that it was built during the reposync process of the repository as lots of package was missing in the repodata. I did force Spacewalk to regenerate it, and all good now. Regards, Philippe. On Wed, 31 Jul 2019 at 13:22, Robert Paschedag wrote: > Please check, that you repo metadata has been correctly regenerated. Might > be, that within the channel, the new package is there, but the metadata has > not been refreshed (the Packages.gz) is still old. > > Robert > > sent from my mobile device > > > Originale Nachricht ---- > Von: philippe bidault > Gesendet: Wed Jul 31 08:30:07 GMT+02:00 2019 > An: spacewalk-list@redhat.com > Betreff: Re: [Spacewalk-list] Debian package comparison failing. > > Hi Robert, > > No, this is so strange, absolutely no trace through apt of the new packages > proposed by Spacewalk on the Debian server. I need to troubleshoot this > deeper. > > root@debian10:~# apt-cache show python-gobject > Package: python-gobject > Status: install ok installed > Priority: extra > Section: oldlibs > Installed-Size: 323 > Maintainer: Debian GNOME Maintainers < > pkg-gnome-maintain...@lists.alioth.debian.org> > Architecture: all > Source: pygobject > Version: 3.22.0-2 > Depends: python-gi (>= 3.22.0-2), python-gobject-2 > Description: Python 2.x bindings for GObject - transitional package > This package will bring the two versions of GObject Python modules: the > deprecated gobject module, and the new gobject-introspection system. It > is here for upgrade purposes only. You can remove it safely when > nothing else depends on it. > Description-md5: 0972cedec40e0869495e1025aa320af1 > Homepage: https://wiki.gnome.org/Projects/PyGObject > > Regards, > Philippe. > > On Tue, 30 Jul 2019 at 21:53, Robert Paschedag > wrote: > > > You can also try to install one of the packages with "apt-get -o > > Debug::pkgProblemResolver install ..." > > > > Robert > > > > sent from my mobile device > > > > > > Originale Nachricht > > Von: philippe bidault > > Gesendet: Tue Jul 30 17:36:34 GMT+02:00 2019 > > An: spacewalk-list@redhat.com > > Betreff: Re: [Spacewalk-list] Debian package comparison failing. > > > > Nop, no lock or nothing similar: > > > > root@debian10:~# dpkg -l | grep python-eth > > ii python-ethtool 0.12-1.1 amd64 > >Python bindings for the ethtool kernel interface > > > > Regards, > > Philippe. > > > > On Tue, 30 Jul 2019 at 15:02, Michael Mraka > > wrote: > > > > > philippe bidault: > > > > Hi Michael, > > > > > > > > Here are the installed versions: > > > > > > > > root@debian10:~# dpkg -l | grep python-go > > > > ii python-gobject 3.22.0-2 all > > > > Python 2.x bindings for GObject - transitional package > > > > ii python-gobject-22.28.6-13 amd64 > > > >deprecated static Python bindings for the GObject library > > > > root@debian10:~# dpkg -l | grep python-eth > > > > ii python-ethtool 0.12-1.1 amd64 > > > >Python bindings for the ethtool kernel interface > > > > > > > > So this is in fact matching what appears in the "Installed Package" > > > column > > > > in the Spacewalk web console. The Debian 10 client just does not see > > the > > > 3 > > > > updates. > > > > > > Can't they be somehow excluded / version-locked / ... etc? > > > If you use dpkg to list all available python-ethtool packages can you > see > > > python-ethtool-0.14-1 among them? > > > > > > > Regards, > > > > Philippe. > > > ... > > > > > > Latest Package > > > > > Installed > > > > > > Package > > > > > > python-ethtool-0.14-1.amd64-deb > > > > > > python-ethtool-0.12-1.1.amd64-deb > > > > > > python-gobject-3.30.4-1.all-deb > > > > > > python-gobject-3.22.0-2.all-deb > > > > > > python-gobject-2-2.28.6-13+b1.amd64-deb > > > > > > python-gobject-2-2.28.6-13.amd64-deb > > > > > > > > > > > > But on the registered debian 10 server, "apt update" is telling > me > > > that > > > > > all > > > > >
Re: [Spacewalk-list] Debian package comparison failing.
Hi Robert, No, this is so strange, absolutely no trace through apt of the new packages proposed by Spacewalk on the Debian server. I need to troubleshoot this deeper. root@debian10:~# apt-cache show python-gobject Package: python-gobject Status: install ok installed Priority: extra Section: oldlibs Installed-Size: 323 Maintainer: Debian GNOME Maintainers < pkg-gnome-maintain...@lists.alioth.debian.org> Architecture: all Source: pygobject Version: 3.22.0-2 Depends: python-gi (>= 3.22.0-2), python-gobject-2 Description: Python 2.x bindings for GObject - transitional package This package will bring the two versions of GObject Python modules: the deprecated gobject module, and the new gobject-introspection system. It is here for upgrade purposes only. You can remove it safely when nothing else depends on it. Description-md5: 0972cedec40e0869495e1025aa320af1 Homepage: https://wiki.gnome.org/Projects/PyGObject Regards, Philippe. On Tue, 30 Jul 2019 at 21:53, Robert Paschedag wrote: > You can also try to install one of the packages with "apt-get -o > Debug::pkgProblemResolver install ..." > > Robert > > sent from my mobile device > > > ---- Originale Nachricht > Von: philippe bidault > Gesendet: Tue Jul 30 17:36:34 GMT+02:00 2019 > An: spacewalk-list@redhat.com > Betreff: Re: [Spacewalk-list] Debian package comparison failing. > > Nop, no lock or nothing similar: > > root@debian10:~# dpkg -l | grep python-eth > ii python-ethtool 0.12-1.1 amd64 >Python bindings for the ethtool kernel interface > > Regards, > Philippe. > > On Tue, 30 Jul 2019 at 15:02, Michael Mraka > wrote: > > > philippe bidault: > > > Hi Michael, > > > > > > Here are the installed versions: > > > > > > root@debian10:~# dpkg -l | grep python-go > > > ii python-gobject 3.22.0-2 all > > > Python 2.x bindings for GObject - transitional package > > > ii python-gobject-22.28.6-13 amd64 > > >deprecated static Python bindings for the GObject library > > > root@debian10:~# dpkg -l | grep python-eth > > > ii python-ethtool 0.12-1.1 amd64 > > >Python bindings for the ethtool kernel interface > > > > > > So this is in fact matching what appears in the "Installed Package" > > column > > > in the Spacewalk web console. The Debian 10 client just does not see > the > > 3 > > > updates. > > > > Can't they be somehow excluded / version-locked / ... etc? > > If you use dpkg to list all available python-ethtool packages can you see > > python-ethtool-0.14-1 among them? > > > > > Regards, > > > Philippe. > > ... > > > > > Latest Package > > > > Installed > > > > > Package > > > > > python-ethtool-0.14-1.amd64-deb > > > > > python-ethtool-0.12-1.1.amd64-deb > > > > > python-gobject-3.30.4-1.all-deb > > > > > python-gobject-3.22.0-2.all-deb > > > > > python-gobject-2-2.28.6-13+b1.amd64-deb > > > > > python-gobject-2-2.28.6-13.amd64-deb > > > > > > > > > > But on the registered debian 10 server, "apt update" is telling me > > that > > > > all > > > > > the packages are already up-to-date. > > > > > > > > What version of python-ethtool, python-gobject and python-gobject-2 > > > > do you have installed on the debian server? > > > > Regards, > > > > -- > > Michael Mráka > > System Management Engineering, Red Hat > > > > ___ > > Spacewalk-list mailing list > > Spacewalk-list@redhat.com > > https://www.redhat.com/mailman/listinfo/spacewalk-list > > > > > ___ > Spacewalk-list mailing list > Spacewalk-list@redhat.com > https://www.redhat.com/mailman/listinfo/spacewalk-list > > ___ > Spacewalk-list mailing list > Spacewalk-list@redhat.com > https://www.redhat.com/mailman/listinfo/spacewalk-list ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Debian package comparison failing.
It seems that finally that if I am not wrong the stored procedure is not working at 100% as Spacewalk wrongly detects the "~rc1" packages to be updated on some Ubuntu 18.04 servers : Latest Package Installed Package libpython2.7-2.7.15~rc1-1ubuntu0.1.amd64-deb libpython2.7-2.7.15-4ubuntu4~18.04.amd64-deb libpython2.7-minimal-2.7.15~rc1-1ubuntu0.1.amd64-deb libpython2.7-minimal-2.7.15-4ubuntu4~18.04.amd64-deb libpython2.7-stdlib-2.7.15~rc1-1ubuntu0.1.amd64-deb libpython2.7-stdlib-2.7.15-4ubuntu4~18.04.amd64-deb python2.7-2.7.15~rc1-1ubuntu0.1.amd64-deb python2.7-2.7.15-4ubuntu4~18.04.amd64-deb python2.7-minimal-2.7.15~rc1-1ubuntu0.1.amd64-deb python2.7-minimal-2.7.15-4ubuntu4~18.04.amd64-deb Regards, Philippe. On Sat, 22 Jun 2019 at 01:01, Paul-Andre Panon < paul-andre.pa...@avigilon.com> wrote: > On Fri, 21 Jun 2019 16:28:17 , Jay McCanta wrote: > > >We are seeing a version compare failure in spacewalk with two Debian > packages: > >libtre5-0.8.0-3+deb7u1ubuntu1 and > >libtre5-0.8.0-3ubuntu1 > > >Spacewalk says the second one is newer, but apt (and dpkg) say the first > one is newer. > > >Looking at the version comparison code, which is in so many places, it > looks like there nothing that differentiates whether to use >the rpm > version algorithm or the Debian one. Is this being looked at in the next > release? It seems that the two algorithms are >incompatible for some > release versions and none of the comparisons tests take into account > whether it is deb or rpm. > > Hi Jay, > > You might want to try out the updated rpm.rpmstrcmp stored procedure in > https://bugzilla.redhat.com/show_bug.cgi?id=1661347 > > I submitted that bug and the proposed fix (for PostgreSQL DBs) a while > back, but not soon enough to make it into 2.9. Hopefully it will make it > into the next release. > > Cheers, > > Paul-Andre > > ___ > Spacewalk-list mailing list > Spacewalk-list@redhat.com > https://www.redhat.com/mailman/listinfo/spacewalk-list > ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Debian package comparison failing.
Nop, no lock or nothing similar: root@debian10:~# dpkg -l | grep python-eth ii python-ethtool 0.12-1.1 amd64 Python bindings for the ethtool kernel interface Regards, Philippe. On Tue, 30 Jul 2019 at 15:02, Michael Mraka wrote: > philippe bidault: > > Hi Michael, > > > > Here are the installed versions: > > > > root@debian10:~# dpkg -l | grep python-go > > ii python-gobject 3.22.0-2 all > > Python 2.x bindings for GObject - transitional package > > ii python-gobject-22.28.6-13 amd64 > >deprecated static Python bindings for the GObject library > > root@debian10:~# dpkg -l | grep python-eth > > ii python-ethtool 0.12-1.1 amd64 > >Python bindings for the ethtool kernel interface > > > > So this is in fact matching what appears in the "Installed Package" > column > > in the Spacewalk web console. The Debian 10 client just does not see the > 3 > > updates. > > Can't they be somehow excluded / version-locked / ... etc? > If you use dpkg to list all available python-ethtool packages can you see > python-ethtool-0.14-1 among them? > > > Regards, > > Philippe. > ... > > > > Latest Package > > > Installed > > > > Package > > > > python-ethtool-0.14-1.amd64-deb > > > > python-ethtool-0.12-1.1.amd64-deb > > > > python-gobject-3.30.4-1.all-deb > > > > python-gobject-3.22.0-2.all-deb > > > > python-gobject-2-2.28.6-13+b1.amd64-deb > > > > python-gobject-2-2.28.6-13.amd64-deb > > > > > > > > But on the registered debian 10 server, "apt update" is telling me > that > > > all > > > > the packages are already up-to-date. > > > > > > What version of python-ethtool, python-gobject and python-gobject-2 > > > do you have installed on the debian server? > > Regards, > > -- > Michael Mráka > System Management Engineering, Red Hat > > ___ > Spacewalk-list mailing list > Spacewalk-list@redhat.com > https://www.redhat.com/mailman/listinfo/spacewalk-list ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Debian package comparison failing.
Hi Michael, Here are the installed versions: root@debian10:~# dpkg -l | grep python-go ii python-gobject 3.22.0-2 all Python 2.x bindings for GObject - transitional package ii python-gobject-22.28.6-13 amd64 deprecated static Python bindings for the GObject library root@debian10:~# dpkg -l | grep python-eth ii python-ethtool 0.12-1.1 amd64 Python bindings for the ethtool kernel interface So this is in fact matching what appears in the "Installed Package" column in the Spacewalk web console. The Debian 10 client just does not see the 3 updates. Regards, Philippe. On Tue, 30 Jul 2019 at 11:46, Michael Mraka wrote: > philippe bidault: > > Hi, > > Hello Philippe, > > > Indeed, the procedure from Paul did solve the issues on package > comparison > > I had on Ubuntu 18.04 and Debian 9. > > > > I am trying now to implement Debian 10 in Spacewalk, but curiously I > have a > > mismatch between the packages number to be updated on Spacewalk and the > > server. > > > > On Spacewalk. 3 servers flagged to be updated: > > > > Latest Package > Installed > > Package > > python-ethtool-0.14-1.amd64-deb > > python-ethtool-0.12-1.1.amd64-deb > > python-gobject-3.30.4-1.all-deb > > python-gobject-3.22.0-2.all-deb > > python-gobject-2-2.28.6-13+b1.amd64-deb > > python-gobject-2-2.28.6-13.amd64-deb > > > > But on the registered debian 10 server, "apt update" is telling me that > all > > the packages are already up-to-date. > > What version of python-ethtool, python-gobject and python-gobject-2 > do you have installed on the debian server? > > > Somebody did have this same issue ? > > > > Regards, > > Philippe. > > Regards, > > -- > Michael Mráka > System Management Engineering, Red Hat > > ___ > Spacewalk-list mailing list > Spacewalk-list@redhat.com > https://www.redhat.com/mailman/listinfo/spacewalk-list ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Debian package comparison failing.
Hi, Indeed, the procedure from Paul did solve the issues on package comparison I had on Ubuntu 18.04 and Debian 9. I am trying now to implement Debian 10 in Spacewalk, but curiously I have a mismatch between the packages number to be updated on Spacewalk and the server. On Spacewalk. 3 servers flagged to be updated: Latest PackageInstalled Package python-ethtool-0.14-1.amd64-deb python-ethtool-0.12-1.1.amd64-deb python-gobject-3.30.4-1.all-deb python-gobject-3.22.0-2.all-deb python-gobject-2-2.28.6-13+b1.amd64-deb python-gobject-2-2.28.6-13.amd64-deb But on the registered debian 10 server, "apt update" is telling me that all the packages are already up-to-date. Somebody did have this same issue ? Regards, Philippe. On Sat, 22 Jun 2019 at 01:01, Paul-Andre Panon < paul-andre.pa...@avigilon.com> wrote: > On Fri, 21 Jun 2019 16:28:17 , Jay McCanta wrote: > > >We are seeing a version compare failure in spacewalk with two Debian > packages: > >libtre5-0.8.0-3+deb7u1ubuntu1 and > >libtre5-0.8.0-3ubuntu1 > > >Spacewalk says the second one is newer, but apt (and dpkg) say the first > one is newer. > > >Looking at the version comparison code, which is in so many places, it > looks like there nothing that differentiates whether to use >the rpm > version algorithm or the Debian one. Is this being looked at in the next > release? It seems that the two algorithms are >incompatible for some > release versions and none of the comparisons tests take into account > whether it is deb or rpm. > > Hi Jay, > > You might want to try out the updated rpm.rpmstrcmp stored procedure in > https://bugzilla.redhat.com/show_bug.cgi?id=1661347 > > I submitted that bug and the proposed fix (for PostgreSQL DBs) a while > back, but not soon enough to make it into 2.9. Hopefully it will make it > into the next release. > > Cheers, > > Paul-Andre > > ___ > Spacewalk-list mailing list > Spacewalk-list@redhat.com > https://www.redhat.com/mailman/listinfo/spacewalk-list > ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] RHEL 8 client support
You perhaps will have luck with the nightly clients versions : https://copr.fedorainfracloud.org/coprs/g/spacewalkproject/nightly-client/ Repo for RH8 beta present there. Philippe. On Thu, 6 Jun 2019 at 22:51, Wilkinson, Matthew < matthewwilkin...@alliantenergy.com> wrote: > Yeah I just thought that was for RHEL 8 packages. It doesn’t look like > either in the stable or nightly that there’s any RHEL 8 client repos: > > > https://copr.fedorainfracloud.org/coprs/g/spacewalkproject/spacewalk-2.9-client/ > > > > > > > > Thanks, > > > > Matthew Wilkinson > > > > *From:* spacewalk-list-boun...@redhat.com [mailto: > spacewalk-list-boun...@redhat.com] *On Behalf Of *philippe bidault > *Sent:* Thursday, June 06, 2019 15:48 > *To:* spacewalk-list@redhat.com > *Subject:* Re: [Spacewalk-list] RHEL 8 client support > > > > [This is an external email. Be cautious with links, attachments and > responses.] > -- > > Hi Matthew, > > > > Did not test it, but if I am not wrong, this is already the case with the > last Spacewalk release: > > > > https://github.com/spacewalkproject/spacewalk/wiki/ReleaseNotes29 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_spacewalkproject_spacewalk_wiki_ReleaseNotes29=DwMFaQ=GUDVeAVg1gjs_GJkmwL1m3gEzDND7NeJG5BIAX_2yRE=zxSMv3Yyn0u8GiLjBm805qsHQ-PQnlWklaJFaNwJsRdou0Rx32Ld6bt57-Tq1kdA=keimDzXl-ega0WOizy4aBkvRSfsaBo0K-_3u2CgFMX8=a1oHcrg3RP9puCcMA30TqIXshPOLk6E9m_DW4nbxe3w=> > > > > " > > · Spacewalk server is now capable of syncing and distributing of Red Hat > Enterprise Linux 8 Beta content" > > > > Regards, > > Philippe. > > > > On Thu, 6 Jun 2019 at 22:40, Wilkinson, Matthew < > matthewwilkin...@alliantenergy.com> wrote: > > Are there any plans for Spacewalk to support RHEL 8 clients? > > > > Thanks! > > > > *Matthew Wilkinson** |* *Lead Server Administrator, Unix* > > > > ___ > Spacewalk-list mailing list > Spacewalk-list@redhat.com > https://www.redhat.com/mailman/listinfo/spacewalk-list > > ___ > Spacewalk-list mailing list > Spacewalk-list@redhat.com > https://www.redhat.com/mailman/listinfo/spacewalk-list ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] RHEL 8 client support
Hi Matthew, Did not test it, but if I am not wrong, this is already the case with the last Spacewalk release: https://github.com/spacewalkproject/spacewalk/wiki/ReleaseNotes29 " - Spacewalk server is now capable of syncing and distributing of Red Hat Enterprise Linux 8 Beta content" Regards, Philippe. On Thu, 6 Jun 2019 at 22:40, Wilkinson, Matthew < matthewwilkin...@alliantenergy.com> wrote: > Are there any plans for Spacewalk to support RHEL 8 clients? > > > > Thanks! > > > > *Matthew Wilkinson** |* *Lead Server Administrator, Unix* > > > ___ > Spacewalk-list mailing list > Spacewalk-list@redhat.com > https://www.redhat.com/mailman/listinfo/spacewalk-list ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] spacewalk 2.9 && never ending issue with ubuntu/debian clients
Hi Florin, Not sure if this is your case, but I did had this same issue by installing the rhn packages from this Opensuse repository : http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/2.9:/debclients/ I did create this ticket : https://bugzilla.opensuse.org/show_bug.cgi?id=1123726 hoping that this could be checked, but no reply so far, not sure if this is because I did not create the ticket in the correct place. Anyway, I am now installing the rhn packages directly from the official debian and Ubuntu repositories, and no more issue anymore. Exemple for Debian 9: wget http://ftp.de.debian.org/debian/pool/main/r/rhnsd/rhnsd_5.0.4-3+b1_amd64.deb wget http://ftp.de.debian.org/debian/pool/main/r/rhn-client-tools/rhn-client-tools_2.3.5-1_amd64.deb wget http://ftp.de.debian.org/debian/pool/main/a/apt-spacewalk/apt-transport-spacewalk_1.0.6-4.1_all.deb Regards, Philippe. On Tue, 26 Feb 2019 at 15:06, Florin Portase wrote: > On 2019-02-22 22:30, Robert Paschedag wrote: > > On 2/22/19 7:53 PM, Robert Paschedag wrote: > > Am 22. Februar 2019 13:11:00 MEZ schrieb Florin Portase < > portase.flo...@medianetork.ro>: > > On 2019-02-13 10:56, Florin Portase wrote: > > Hello, > > I just have upgraded the spacewalk server from 2.7 => 2.9. > > I have applied also the sql patch from > > https://bugzilla.redhat.com/show_bug.cgi?id=1661347 > > > + upgraded the clients from : > > > > http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/2.9:/debclients/ > > > Just to mention spacewalk 2.7 + patches was working just fine for > > both debian & ubuntu. > > > Now, for ubuntu 16.05 I have over 100 packages marked as up-gradable( > > over and over) > > > ___ > > Spacewalk-list mailing list > Spacewalk-list@redhat.com > https://www.redhat.com/mailman/listinfo/spacewalk-list > > > So, after digging through SPW archive Dec '18 til Feb '19 finally I > come to something more acceptable: > > 1. sync script for Ubuntu channels > > 2. "spacewalk-add-debian-multiarch-header.py.NEW " took it from > " > https://www.redhat.com/archives/spacewalk-list/2018-December/msg00017.html > " > > > wget -q > > http://de.archive.ubuntu.com/ubuntu/dists/xenial/main/binary-amd64/Packages.gz > \ >-O /tmp/Packages-xenial-main.gz && gunzip -f > /tmp/Packages-xenial-main.gz > wget -q > > http://cz.archive.ubuntu.com/ubuntu/dists/xenial-updates/main/binary-amd64/Packages.gz > \ >-O /tmp/Packages-xenial-updates.gz && gunzip -f > /tmp/Packages-xenial-updates.gz > wget -q > > http://cz.archive.ubuntu.com/ubuntu/dists/xenial-security/main/binary-amd64/Packages.gz > \ >-O /tmp/Packages-xenial-security.gz && gunzip -f > /tmp/Packages-xenial-security.gz > > s=180 > trap 'echo "Ctrl-C detected."' 2 > for (( i=$s ; i>0; i--)); >do >#printf '\rFinishing sync in: %2d seconds' $i; sleep 1 >echo -ne "\rFinishing sync in: $i seconds\033[0K"; > sleep 1 >done > echo -e "\nSync completed!" > trap 2 > $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW > $_PKG_MAIN/Packages/tmp/Packages-xenial-main > $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW > $_PKG_UPD/Packages /tmp/Packages-xenial-updates > $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW > $_PKG_SEC/Packages /tmp/Packages-xenial-security > $_BIN_PATH/spacewalk-add-debian-multiarch-header.py.NEW > $_PKG_UNIV/Packages/tmp/Packages-xenial-universe > > > Below is your error > > Packages.new is the "modified" Packages which you rename and > *afterwards* use its "modified" timestamp. This is wrong. > > You have to use the "modified" timestamp of the "original" (the one > generated by Spacewalk) packages file > > So when you have the original "Packages" file (by spacewalk), do > > - run the script (which generates "Packages.new") > - gzip -c Packages.new > Packages.gz > - touch -r Packages Packages.new Packages.gz && mv Packages.new Packages > > So you have transferred the original timestamp to the new files and all > set to "secure" your repo then. > > Robert > >/bin/mv $_PKG_MAIN/Packages.new $_PKG_MAIN/Packages >/bin/mv $_PKG_SEC/Packages.new $_PKG_SEC/Packages >/bin/mv $_PKG_UPD/Packages.new $_PKG_UPD/Packages >/bin/mv $_PKG_UNIV/Packages.new $_PKG_UNIV/Packages > >gzip < $_PKG_MAIN/Packages > $_PKG_MAIN/Packages.gz >gzip < $_PKG_UPD/Packages > $_PKG_UPD/Packages.gz >gzip < $_PKG_SEC/Packages > $_PKG_SEC/Packages.gz >gzip < $_PKG_UNIV/Packages > $_PKG_UNIV/Packages.gz > > cd $_PKG_MAIN >$_BIN_PATH/secureApt.sh xenial xenial-main >touch -r Packages.gz Packages > cd $_PKG_UPD >$_BIN_PATH/secureApt.sh xenial xenial-updates >touch -r Packages.gz Packages > cd $_PKG_SEC >$_BIN_PATH/secureApt.sh
[Spacewalk-list] Taskomatic : Debian repodata generation issue
Hi all, Something strange is happening on my Spacewalk 2.9: taskomatic is regenerating my Ubuntu repodatas some times to times: INFO | jvm 1| 2019/01/24 03:34:00 | 2019-01-24 03:34:00,144 [Thread-3446] INFO com.redhat.rhn.taskomatic.task.repomd.RepositoryWriter - File Modified Date:2019-01-24 03:05:24 CET INFO | jvm 1| 2019/01/24 03:34:00 | 2019-01-24 03:34:00,144 [Thread-3446] INFO com.redhat.rhn.taskomatic.task.repomd.RepositoryWriter - Channel Modified Date:2019-01-24 03:33:49 CET INFO | jvm 1| 2019/01/24 03:34:00 | 2019-01-24 03:34:00,374 [Thread-3447] INFO com.redhat.rhn.taskomatic.task.repomd.RepositoryWriter - Generating new DEB repository for channel bionic-security INFO | jvm 1| 2019/01/24 03:34:00 | 2019-01-24 03:34:00,544 [Thread-3446] INFO com.redhat.rhn.taskomatic.task.repomd.RepositoryWriter - Generating new DEB repository for channel bionic-updates I know that this is the purpose of taskomatic, but this is really annoying as the "Packages" and "Release" files are "manually" generated, thus having taskomatic triggering their re-generation just break everything. I don't think remember having seen such behaviour in Spacewaok 2.8. Is there a way to force taskomatic to ignore the DEB repodatas ? Regards, Philippe. ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Missing Ubuntu Package properties in Spacewalk
And you are right, my mistake, I was checking a previouly generated Packages.gz. I still need to use your script to have all the headers. And yes, you are right again, the bug you did create is similar to the issue I have described. I guess that a workaroud is to replace the "Depends" header. Philippe. On Sun, 20 Jan 2019 at 21:17, Robert Paschedag wrote: > Am 20. Januar 2019 20:48:24 MEZ schrieb Robert Paschedag < > robert.pasche...@web.de>: > >Am 20. Januar 2019 14:03:03 MEZ schrieb philippe bidault > >: > >>Good news, I have upgraded to Spacewalk 2.9, and seems that the > >headers > >>issue did definively go away, no need to manually add them. > > What?? Now really all headers are added to packages.gz? I do not yet > believe this. The database schema would have been tuned a lot to support > all Debian headers. > > Can someone else confirm this? I'm currently not that often at the > customers site to test this. > > Robert > > >> > >>However, a new issue did come up. If I add for exemple this repo in > >SPW > >>: > >> > http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/2.9:/debclients/xUbuntu_18.04/ > , > >>I can notice that the "Depends" header is truncated for some packages > >>wich > >>results on a malformed Packages file. > >> > >>For exemple, original headers of package rhn-setup-gnome : > >> > >>Package: rhn-setup-gnome > >>Version: 2.9.36-1.ubuntu18.04.1 > >>Architecture: all > >>Maintainer: Spacewalk Project > >>Installed-Size: 339*Depends: rhn-client-tools (= > >>2.9.36-1.ubuntu18.04.1),python2-rhn-setup (= > >>2.9.36-1.ubuntu18.04.1),python2-rhn-setup-gnome (= > >>2.9.36-1.ubuntu18.04.1),rhn-setup (= > > >>2.9.36-1.ubuntu18.04.1),libpam0g,libpam-modules,libpam-runtime,libpam-gnome-keyring* > >> > >>"Depends" header apparearing in the Package file generated by > >>Spacewalk: > >> > >>Package: rhn-setup-gnome > >>Version: 2.9.36-1.ubuntu18.04.1 > >>Architecture: all > >>Maintainer: Spacewalk Project > >>Installed-Size: 339 > >>*Depends: rhn-client-tools (= > >>2.9.36-1.ubuntu18.04.1),python2-rhn-setup )* > >> > >>Result of this is the following error on the clients registered > >against > >>this channel : > >> > >>E: Problem parsing dependency 21 > >>E: Error occurred while processing rhn-setup-gnome (NewVersion2) > >>E: Problem with MergeList > > >>/var/lib/apt/lists/space01-fr_dists_bionic-spacewalk29-client_repodata_binary-amd64_Packages > >>E: The package lists or status file could not be parsed or opened. > >> > >>which is due to the malformed/incomplet "Depends" header. > >> > >>Will try to dig, but if somebody did have this same issue or more > >>information, please let me know. > >> > >>Regards, > >>Philippe. > > > >Sounds like this , didn't it? > >https://bugzilla.redhat.com/show_bug.cgi?id=1658772 > > > >Robert > >> > >>On Sat, 12 Jan 2019 at 02:12, Paul-Andre Panon < > >>paul-andre.pa...@avigilon.com> wrote: > >> > >>> On Thu, 10 Jan 2019 09:47:25 +0100, philippe bidault > >>> wrote: > >>> > >>> >Hi Paul-Andre, > >>> > >>> >Robert did send me some weeks ago a new script which fetch all the > >>> missing > >>> >headers. I am using it, and for the moment, seems to correctly work > >>: > >>> > >>> > >>> > https://www.redhat.com/archives/spacewalk-list/2018-December/msg00015.htm > >>> l > >>> > >>> >Regards, > >>> >Philippe. > >>> > >>> Ah, merci Phillipe and thanks Robert! That should do it going > >>forward. > >>> > >>> ___ > >>> Spacewalk-list mailing list > >>> Spacewalk-list@redhat.com > >>> https://www.redhat.com/mailman/listinfo/spacewalk-list > >>> > > > -- > sent from my mobile device > ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Missing Ubuntu Package properties in Spacewalk
Good news, I have upgraded to Spacewalk 2.9, and seems that the headers issue did definively go away, no need to manually add them. However, a new issue did come up. If I add for exemple this repo in SPW : http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/2.9:/debclients/xUbuntu_18.04/, I can notice that the "Depends" header is truncated for some packages wich results on a malformed Packages file. For exemple, original headers of package rhn-setup-gnome : Package: rhn-setup-gnome Version: 2.9.36-1.ubuntu18.04.1 Architecture: all Maintainer: Spacewalk Project Installed-Size: 339*Depends: rhn-client-tools (= 2.9.36-1.ubuntu18.04.1),python2-rhn-setup (= 2.9.36-1.ubuntu18.04.1),python2-rhn-setup-gnome (= 2.9.36-1.ubuntu18.04.1),rhn-setup (= 2.9.36-1.ubuntu18.04.1),libpam0g,libpam-modules,libpam-runtime,libpam-gnome-keyring* "Depends" header apparearing in the Package file generated by Spacewalk: Package: rhn-setup-gnome Version: 2.9.36-1.ubuntu18.04.1 Architecture: all Maintainer: Spacewalk Project Installed-Size: 339 *Depends: rhn-client-tools (= 2.9.36-1.ubuntu18.04.1),python2-rhn-setup )* Result of this is the following error on the clients registered against this channel : E: Problem parsing dependency 21 E: Error occurred while processing rhn-setup-gnome (NewVersion2) E: Problem with MergeList /var/lib/apt/lists/space01-fr_dists_bionic-spacewalk29-client_repodata_binary-amd64_Packages E: The package lists or status file could not be parsed or opened. which is due to the malformed/incomplet "Depends" header. Will try to dig, but if somebody did have this same issue or more information, please let me know. Regards, Philippe. On Sat, 12 Jan 2019 at 02:12, Paul-Andre Panon < paul-andre.pa...@avigilon.com> wrote: > On Thu, 10 Jan 2019 09:47:25 +0100, philippe bidault > wrote: > > >Hi Paul-Andre, > > >Robert did send me some weeks ago a new script which fetch all the > missing > >headers. I am using it, and for the moment, seems to correctly work : > > >https://www.redhat.com/archives/spacewalk-list/2018-December/msg00015.htm > l > > >Regards, > >Philippe. > > Ah, merci Phillipe and thanks Robert! That should do it going forward. > > ___ > Spacewalk-list mailing list > Spacewalk-list@redhat.com > https://www.redhat.com/mailman/listinfo/spacewalk-list > ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Missing Ubuntu Package properties in Spacewalk Packages/Packages.gz files
Hi Paul-André, Robert did send me some weeks ago a new script which fetch all the missing headers. I am using it, and for the moment, seems to correctly work : https://www.redhat.com/archives/spacewalk-list/2018-December/msg00015.html Regards, Philippe. On Thu, 10 Jan 2019 at 00:45, Paul-Andre Panon < paul-andre.pa...@avigilon.com> wrote: > Hi Robert, > > We had a discussion about failing upgrades a long time ago due to > Multi-Arch > property headers in the Packages file, and a follow-up where I had issues > with the python packages even though they had Multi-Arch properties set up. > I'm running into a similar upgrade problem again, but with updated > e2fsprogs > and libext2fs2 packages in Ubuntu 18.04. This time I've been able to figure > out that the problem isn't missing Multi-Arch property "headers" in the > Packages file, but the missing Pre-Depends: property info for the e2fsprogs > package. I manually copied that property from the Ubuntu repo to the > e2fsprog info in the /var/cache Packages file, and my upgrade problem went > away. I remember you had talked about modifying your Multi-Arch download > scripts to copy more headers/properties. > a) did you ever do that? > b) was Pre-Depends one of the properties you added? > c) if the answer to a and b is yes, then do you have it available somewhere > were I can get at it? > > As far as I can tell, > https://github.com/rpasche/spacewalk-debian-sync/tree/add-multiarch-header > is the version that only handles multi-arch, and your dev branch appears to > mostly be the same. > > Thanks, > > Paul-Andre Panon > > ___ > Spacewalk-list mailing list > Spacewalk-list@redhat.com > https://www.redhat.com/mailman/listinfo/spacewalk-list > ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Ubuntu 18.04 package management in Spacewalk 2.8
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: Sat Dec 22 16:20:46 CET 2018 on pts/1 -bash-4.2$ psql rhnschema -f /var/tmp/rpm.rpmstrcmp.sql SET CREATE FUNCTION ALTER FUNCTION And I did restart the satellite service. However even after waiting and finally force the "rhn_check" on a registered Ubuntu 18.04 server, nothing occured. I did have to remove and register again the Ubuntu client server to see the difference, means no more packages flagged as upgradable appaearing on the Spacewalk server. Will continue to keep an eye on this, will let you know if I notice something strange. Thanks again ! Regards, Philippe. On Sat, 22 Dec 2018 at 08:50, Paul-Andre Panon < paul-andre.pa...@avigilon.com> wrote: > 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 cause. > > If you go to the bug, https://bugzilla.redhat.com/show_bug.cgi?id=1661347 > , I had added an attachment there. You should be able to download the > attachment and > 1) stop your Spacewalk service > 2) backup your database > 3) sudo su postgres or add your spaceuser/password to psql -i > rpm.rpmstrcmp.sql > 4) exit psql if needed and restart your Spacewalk service > and then wait for servers to run the next rhn_check to update their needed > updates list. > > Cheers, > > Paul-Andre Panon > Senior Systems Administrator > > *Avigilon* > A Motorola Solutions Company > > > On Fri, 21 Dec 2018 at 04:00, philippe bidault > wrote: > >> 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 do it. >> >> Do you think that a patch, update or something will be delivered soon to >> allow an easy implementation of your work ? >> >> Regards, >> Philippe. >> >> >> >> >> On Fri, 21 Dec 2018 at 07:27, Robert Paschedag >> wrote: >> >>> Am 21. Dezember 2018 00:44:02 MEZ schrieb Paul-Andre Panon < >>> paul-andre.pa...@avigilon.com>: >>> >I created Bugzilla Bug 1661347 regarding this issue >>> >>> Great job, Paul-Andre. Thanks. >>> >>> Robert >>> >> ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Ubuntu 18.04 package management in Spacewalk 2.8
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 do it. Do you think that a patch, update or something will be delivered soon to allow an easy implementation of your work ? Regards, Philippe. On Fri, 21 Dec 2018 at 07:27, Robert Paschedag wrote: > Am 21. Dezember 2018 00:44:02 MEZ schrieb Paul-Andre Panon < > paul-andre.pa...@avigilon.com>: > >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 >packages which needed to be updated but weren't listed. Can > >somebody > >put >this in a PR? > > > >>Thanks, > > > >>Paul-Andre > > > >___ > >Spacewalk-list mailing list > >Spacewalk-list@redhat.com > >https://www.redhat.com/mailman/listinfo/spacewalk-list > > > -- > sent from my mobile device > > ___ > Spacewalk-list mailing list > Spacewalk-list@redhat.com > https://www.redhat.com/mailman/listinfo/spacewalk-list > ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Ubuntu 18.04 package management in Spacewalk 2.8
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 (I guess because of a missing header).
Regarding the fake-upgradable Debian packages appearing on Spacewalk, I
have 12 of them for the moment :
gcc-8-base-8-20180414-1ubuntu2.amd64-deb
gcc-8-base-8.2.0-1ubuntu2~18.04.amd64-deb
lib32gcc1-8-20180414-1ubuntu2:1.amd64-deb
lib32gcc1-8.2.0-1ubuntu2~18.04:1.amd64-deb
libatomic1-8-20180414-1ubuntu2.amd64-deb
libatomic1-8.2.0-1ubuntu2~18.04.amd64-deb
libcc1-0-8-20180414-1ubuntu2.amd64-deb libcc1-0-8.2.0-1ubuntu2~18.04.amd64-deb
libgcc1-8-20180414-1ubuntu2:1.amd64-deb
libgcc1-8.2.0-1ubuntu2~18.04:1.amd64-deb
libgomp1-8-20180414-1ubuntu2.amd64-deb libgomp1-8.2.0-1ubuntu2~18.04.amd64-deb
libitm1-8-20180414-1ubuntu2.amd64-deb libitm1-8.2.0-1ubuntu2~18.04.amd64-deb
liblsan0-8-20180414-1ubuntu2.amd64-deb liblsan0-8.2.0-1ubuntu2~18.04.amd64-deb
libmpx2-8-20180414-1ubuntu2.amd64-deb libmpx2-8.2.0-1ubuntu2~18.04.amd64-deb
libquadmath0-8-20180414-1ubuntu2.amd64-deb
libquadmath0-8.2.0-1ubuntu2~18.04.amd64-deb
libstdc++6-8-20180414-1ubuntu2.amd64-deb
libstdc++6-8.2.0-1ubuntu2~18.04.amd64-deb
libtsan0-8-20180414-1ubuntu2.amd64-deb
libtsan0-8.2.0-1ubuntu2~18.04.amd64-deb
Will try to dig, but indeed if the versioning motor is managed by Java and
not Python, will be hard to debug ...
Regards,
Philippe.
On Wed, 5 Dec 2018 at 22:08, Robert Paschedag
wrote:
> Hi Philippe,
>
> Welluntil now, I only have very few packages that are shown as
> upgradable for "Debian" systems. I only found some version comparision
> problem while testing Uyuni (and testing to get Debian system registered as
> Salt client). I think this could be further tuned to use the python-apt or
> python-dpkg package...but I did not have time to dig into that.
>
> Within spacewalk, I currently do not know, where the comparision takes
> place (within java or within python).
>
> The "modified" script is a "new" one. It does not depend on the - from
> myself - modified sync script. What it needs is the original Packages.gz
> file for the channel you sync.
>
> Just throwing this here so you can test yourself. Basically, it should add
> all "missing" headers for every package.
>
> import sys
> import os
> from debian.deb822 import *
> if len(sys.argv) < 3:
> print "Usage: %s
> " % sys.argv[0]
> sys.exit(1)
> spacewalk_file = sys.argv[1]
> original_file = sys.argv[2]
> if not os.path.isfile(spacewalk_file):
> print "Error: Inputfile '%s' not available." % spacewalk_file
> sys.exit(1)
> if not os.path.isfile(original_file):
> print "Error: Inputfile '%s' not available." % original_file
> sys.exit(1)
> spacewalk_packages = {}
> original_packages = {}
> with open(spacewalk_file, 'r') as pkgs:
> for pkg in Packages.iter_paragraphs(pkgs):
> spacewalk_packages[pkg['Package'] + pkg['Version'] +
> pkg['Architecture']] = pkg
> with open(original_file, 'r') as orig_file:
> for pkg in Packages.iter_paragraphs(orig_file):
> p = pkg['Package']
> v = pkg['Version']
> a = pkg['Architecture']
> if spacewalk_packages.has_key(p + v + a):
> # found package. Check for missing headers
> for header in pkg.keys():
> if not header in spacewalk_packages[p + v + a].keys():
> spacewalk_packages[p + v + a][header] = pkg[header]
> # open new file
> new_package = open(spacewalk_file + '.new', 'w')
> for pkg in spacewalk_packages.values():
> pkg.dump(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.04 package management in
> Spacewalk 2.8
> 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 <
>> philippe.bida...@gmail.com>:
>> >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
Re: [Spacewalk-list] Ubuntu 18.04 package management in Spacewalk 2.8
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 <
> philippe.bida...@gmail.com>:
> >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 or a plus character. This leads to some packages
> >wrongly
> >shown as an update for a client in spacewalk when the package is
> >actually a
> >downgrade. The client however uses a correct comparison and handles the
> >package upgrade correctly
> >
> >2- The deb importer does not import all the package header information
> >into
> >the database and the repository-writer will not write the missing
> >information to the repository metadata served by spacewalk. This will
> >lead
> >to problems on the client in case of the missing Multi-Arch header:
> >Clients
> >will try to reinstall the same package over and over again when this
> >header
> >is missing.
> >
> >3- A deb repository provided by spacewalk is not GPG signed and thus
> >will
> >not work without disabling secure-apt. Spacewalk imports and recreates
> >the
> >repository based on the imported package catalogue, this will destroy
> >the
> >GPG signing of the repository vendor."
> >
> >I did manage to solve the point 2 and 3. The point 3 thanks to this
> >method
> >:
> >
> http://www.devops-blog.net/spacewalk/gpg-signing-apt-repository-in-spacewalk
> >
> >Regarding the point 2, I did have to customize the script
> >
> https://github.com/rpasche/spacewalk-debian-sync/tree/add-multiarch-header
> >,
> >as it seems that in any case the add of the Multi-Arch header in
> >Packages.gz is not enough for Ubuntu 18.04. I did only succeed in not
> >ending in an infinite loop of packages flagged to be upgraded as the
> >result
> >of "apt upgrade" by adding more headers in Packages.gz :
> >
> >p, v, a, multi, breaks, predeps = line.rstrip().split("||")
> > if (packages.has_key(p + v + a) and (multi is not "#")) :
> > packages[p + v + a]['Multi-Arch'] = multi
> > if (packages.has_key(p + v + a) and (breaks is not "#")) :
> > packages[p + v + a]['Breaks'] = breaks
> > if (packages.has_key(p + v + a) and (predeps is not "#")) :
> > packages[p + v + a]['Pre-Depends'] = predeps
>
> I did improve the script (still testing). Basically it just adds all
> missing headers from the original file to that generated by spacewalk. The
> repo is not yet updated.
>
> Robert
> >
> >Right now, what is really causing me much more trouble, is the point 1,
> >which is making Spacewalk not really reliable for deb package
> >management ,
> >as I have a permanent list of upgradable packages in the Spacewalk
> >console,
> >whereas the installed versions are already the latest.
> >
> >Example :
> >
> >
> >Latest Package
> >Installed Package
> >gcc-8-base-8-20180414-1ubuntu2.amd64-deb
> ><
> https://space01/rhn/software/packages/Details.do?sid=110058_combo=21120|7544|145
> >
> >gcc-8-base-8.2.0-1ubuntu2~18.04.amd64-deb
> >lib32gcc1-8-20180414-1ubuntu2:1.amd64-deb
> ><
> https://space01/rhn/software/packages/Details.do?sid=110058_combo=21933|7796|145
> >
> >lib32gcc1-8.2.0-1ubuntu2~18.04:1.amd64-deb
> >
> >
> >So in resume, I have 2 questions :
> >
> >- Regarding the point 1, is there already an existing solution I could
> >use,
> >or at least some clues ?
> >- Regarding the point 2 : Did I miss something, or do we really need to
> >add
> >some extra headers (Breaks and Pre-depends) to have the Ubuntu 18.04
> >client
> >servers correctly listing packages to be upgraded ?
> >
> >Regards,
> >Philippe.
>
>
> --
> sent from my mobile device
>
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] SpaceWalk 2.8 Install Error
Hi, Not sure if this is relevant, but on the Spacewalk 2.8 installation instructions, there are references about Oracle 10g and 11g, but nothing about Oracle 12 : https://github.com/spacewalkproject/spacewalk/wiki/HowToInstall28 In order to get Spacewalk to run with Oracle database backend, you need: - Instant Client 11.2.0.4.0 installed on the Spacewalk machine - Oracle database server, either on the Spacewalk machine or on another host; versions 10g and 11g are known to work Regards, Phlilippe. On Wed, 5 Dec 2018 at 14:38, Bruce Wainer wrote: > I don’t have any specific experience with using an Oracle backend for > spacewalk (although I was an Oracle 9i certified database administrator) > but have you verified using some other program that the database can be > reached from this server? I’m just wondering if the Spacewalk setup is > giving you an error about the tablespace when in reality it might have > failed to connect, or the user you supplied does not have the proper > permissions. > > Hope this helps, > Bruce Wainer > > > On Dec 5, 2018, at 8:24 AM, Worner, Frank wrote: > > > > Hi Michael > > > > Thanks for the swift reply, but unfortunately there was an omission in > my typing ... I should have said; > > > > "We have confirmed that the tableSPACE SWALK_DATA does indeed exist" > > > > Sorry, my mistake - but the original issue still exists - any other > suggestion, anyone ?? > > > > Regards > > > > Frank > > > > -Original Message- > > From: spacewalk-list-boun...@redhat.com < > spacewalk-list-boun...@redhat.com> On Behalf Of Michael Mraka > > Sent: 05 December 2018 12:38 > > To: spacewalk-list@redhat.com > > Subject: Re: [Spacewalk-list] SpaceWalk 2.8 Install Error > > > > Worner, Frank: > >> > >> Hi All - I wonder if anyone can shed light on the following error ?? > >> > >> # spacewalk-setup --external-oracle > >> * Setting up SELinux.. > >> * Setting up Oracle environment. > >> * Setting up database. > >> ** Database: Setting up database connection for Oracle backend. > >> Global Database Name or SID (requires tnsnames.ora)? ABCD > >> Username? WXYZ > >> Password? > >> ** Database: Testing database connection. > >> Tablespace 'SWALK_DATA' does not appear to exist. > > ^^ > >> Use of uninitialized value in string ne at > /usr/share/perl5/vendor_perl/Spacewalk/Setup.pm line 1528, line 3. > >> Use of uninitialized value $_[2] in sprintf at > /usr/share/perl5/vendor_perl/Spacewalk/Setup.pm line 162, line 3. > >> Use of uninitialized value in string ne at > /usr/share/perl5/vendor_perl/Spacewalk/Setup.pm line 1528, line 3. > >> Use of uninitialized value $_[2] in sprintf at > /usr/share/perl5/vendor_perl/Spacewalk/Setup.pm line 162, line 3. > >> Use of uninitialized value in string ne at > /usr/share/perl5/vendor_perl/Spacewalk/Setup.pm line 1528, line 3. > >> Use of uninitialized value $_[2] in sprintf at > /usr/share/perl5/vendor_perl/Spacewalk/Setup.pm line 162, line 3. > >> Tablespace errors: tablespace SWALK_DATA has STATUS set to where > ONLINE is expected;tablespace SWALK_DATA has LOGGING set to where LOGGING > is expected;tablespace SWALK_DATA has CONTENTS set to where PERMANENT is > expected > >> > >> We are trying to install SpaceWalk 2.8 on a Centos7 host, connecting to > a remote host running an Oracle 12C instance. We have confirmed that the > table SWALK_DATA does indeed exist, so are unsure why we get the error > stating the table doesn't exist. We are also unsure what the subsequent > errors are complaining about too, so any help or advice would be gratefully > received !! > > > > Tablespace != table. You need to create *tablespace* SWALK_DATA (a place > > where Oracle stores tables). > > > >> Many Thanks > >> > >> Frank > > > > > > Regards, > > > > -- > > Michael Mráka > > System Management Engineering, Red Hat > > > > ___ > > Spacewalk-list mailing list > > Spacewalk-list@redhat.com > > https://www.redhat.com/mailman/listinfo/spacewalk-list > > > > ___ > > Spacewalk-list mailing list > > Spacewalk-list@redhat.com > > https://www.redhat.com/mailman/listinfo/spacewalk-list > > ___ > Spacewalk-list mailing list > Spacewalk-list@redhat.com > https://www.redhat.com/mailman/listinfo/spacewalk-list ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
[Spacewalk-list] Ubuntu 18.04 package management in Spacewalk 2.8
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 or a plus character. This leads to some packages wrongly
shown as an update for a client in spacewalk when the package is actually a
downgrade. The client however uses a correct comparison and handles the
package upgrade correctly
2- The deb importer does not import all the package header information into
the database and the repository-writer will not write the missing
information to the repository metadata served by spacewalk. This will lead
to problems on the client in case of the missing Multi-Arch header: Clients
will try to reinstall the same package over and over again when this header
is missing.
3- A deb repository provided by spacewalk is not GPG signed and thus will
not work without disabling secure-apt. Spacewalk imports and recreates the
repository based on the imported package catalogue, this will destroy the
GPG signing of the repository vendor."
I did manage to solve the point 2 and 3. The point 3 thanks to this method
:
http://www.devops-blog.net/spacewalk/gpg-signing-apt-repository-in-spacewalk
Regarding the point 2, I did have to customize the script
https://github.com/rpasche/spacewalk-debian-sync/tree/add-multiarch-header ,
as it seems that in any case the add of the Multi-Arch header in
Packages.gz is not enough for Ubuntu 18.04. I did only succeed in not
ending in an infinite loop of packages flagged to be upgraded as the result
of "apt upgrade" by adding more headers in Packages.gz :
p, v, a, multi, breaks, predeps = line.rstrip().split("||")
if (packages.has_key(p + v + a) and (multi is not "#")) :
packages[p + v + a]['Multi-Arch'] = multi
if (packages.has_key(p + v + a) and (breaks is not "#")) :
packages[p + v + a]['Breaks'] = breaks
if (packages.has_key(p + v + a) and (predeps is not "#")) :
packages[p + v + a]['Pre-Depends'] = predeps
Right now, what is really causing me much more trouble, is the point 1,
which is making Spacewalk not really reliable for deb package management ,
as I have a permanent list of upgradable packages in the Spacewalk console,
whereas the installed versions are already the latest.
Example :
Latest Package
Installed Package
gcc-8-base-8-20180414-1ubuntu2.amd64-deb
gcc-8-base-8.2.0-1ubuntu2~18.04.amd64-deb
lib32gcc1-8-20180414-1ubuntu2:1.amd64-deb
lib32gcc1-8.2.0-1ubuntu2~18.04:1.amd64-deb
So in resume, I have 2 questions :
- Regarding the point 1, is there already an existing solution I could use,
or at least some clues ?
- Regarding the point 2 : Did I miss something, or do we really need to add
some extra headers (Breaks and Pre-depends) to have the Ubuntu 18.04 client
servers correctly listing packages to be upgraded ?
Regards,
Philippe.
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list
