Re: [Spacewalk-list] Problems with Debian Stretch on SW 2.7. Can reinstall packages over and over again

[Paul-Andre Panon]

On Monday, October 16, 2017 2:08 PM, Robert Paschedag 
[mailto:robert.pasche...@web.de] wrote:
>On 10/16/17 21:25, Paul-Andre Panon wrote:
>> On Saturday, October 14, 2017 12:02 AM, Robert Paschedag 
>> [mailto:robert.pasche...@web.de] wrote:
>>> Am 14. Oktober 2017 01:38:59 MESZ schrieb Paul-Andre Panon 
>>> :
>>> Hi Paul-Andre,
>>>
>>> the big problem is... "allowed" is not the only value for Multi-Arch. In 
>>> Debian stretch "main" repo, there are 8979 Packages with "Multi-Arch" 
>>> header. No way to do that by hand.
>> Agreed, but so far I have only had problems with packages where the missing 
>> Multi-Arch value is "allowed". Maybe I've just been lucky though. The 
>> annoying thing is that, even with the ~couple dozen cases of "Multi-Arch: 
>> allowed" in the Ubuntu main and universe repos (mostly from python and the 
>> gcc toolchain), every sync wipes out your last set of manual fixes.  When I 
>> ran into the problem, I found the clue to a workaround in matus' Jan 30th 
>> 2015 comment at 
>> http://www.devops-blog.net/spacewalk/registering-ubuntu-and-debian-servers-with-spacewalk,
>>  so this isn't a new issue. I'm not happy with his kludgy "fix" though since 
>> it also winds up adding that property to many packages where it doesn't 
>> apply.
>Yeah. I'm also using that workaround from the bugzilla report about the 
>missing Multi-Arch headers and in jessie, this really works quite good.
>Now, with "stretch", this is just a nightmare. I was so happy, that now in 
>SW2.7, the debian version string parsing has been improved and now debian has 
>"improved" "apt". But that improvement somehow throws a big stick between your 
>legs while you're running at max speed, causing you to crash and break with 
>your face on the ground :-P
>
>>> Thanks
>>> Robert
>> Paul-Andre Panon
>> Senior systems administrator
>>
>> Office: 604.629.5182 ext 2341 Mobile: 604.679.1617
>
>I found the "error". It is really because of the "missing" "Release" 
>file. If this is found, and there is an "Architectures:" header, the new "apt" 
>will download the Packages for this architecture. If the "Release" is missing, 
>"apt" will download the Packages for the clients configured "architectures" + 
>"all".
>
>This is a new behaviour.
Ah, that explains why I haven't been seeing the same problems then then. I've 
been building Release files using another of Philip's blog postings (and 
customized it to build InRelease files as well). 
http://www.devops-blog.net/spacewalk/gpg-signing-apt-repository-in-spacewalk

>
>But I think, that this is not my main error. Because I'm still using Steve 
>Meier's "debian sync" tool to download and import the debian packages, I 
>modified that to create a "temporary" file with the "package" name and 
>possible "multi-arch" header, which I can insert, after SW has created his own 
>"Packages" file.
>
>But this does not yet work 100%, because there are sometimes more than one 
>package with exact same name. I have to improve that and keep trying.
>
>Really the best thing would be, if the "Multi-Arch" header would be added to 
>the database. If I'm right, this header is already "present", while the .deb 
>files gets parsed but it just gets ignored. And I don't know, how much work 
>and modification is needed to fully implement this header to every .deb 
>package.

It appears to be in the .deb package so if that's what is being used as a 
metadata source (and not the Package file from the mirror site) then it would 
still be valid.
 
~$ dpkg-deb -I 
/var/cache/apt/archives/python2.7-minimal_2.7.12-1ubuntu0~16.04.1_amd64.deb
 new debian package, version 2.0.
 size 1295108 bytes: control archive=2355 bytes.
 826 bytes,21 lines  control
 338 bytes, 5 lines  md5sums
2365 bytes,78 lines   *  postinst #!/bin/sh
 416 bytes,21 lines   *  postrm   #!/bin/sh
 900 bytes,39 lines   *  preinst  #!/bin/sh
 813 bytes,36 lines   *  prerm#!/bin/sh
 Package: python2.7-minimal
 Source: python2.7
 Version: 2.7.12-1ubuntu0~16.04.1
 Architecture: amd64
 Maintainer: Ubuntu Core Developers 
 Installed-Size: 3584
 Pre-Depends: libc6 (>= 2.15)
 Depends: libpython2.7-minimal (= 2.7.12-1ubuntu0~16.04.1), zlib1g (>= 1:1.2.0)
 Recommends: python2.7
 Suggests: binfmt-support
 Conflicts: binfmt-support (<< 1.1.2)
 Replaces: python2.7 (<< 2.7.8-7~)
 Section: python
 Priority: standard
 Multi-Arch: allowed
 Description: Minimal subset of the Python language (version 2.7)
  This package contains the interpreter and some essential modules.  It can
  be used in the boot process for some basic tasks.
  See /usr/share/doc/python2.7-minimal/README.Debian for a list of the modules
  contained in this package.
 Original-Maintainer: Matthias Klose 

I agree that adding it to the database was what I thought would be needed to do 
it right as well. 

Re: [Spacewalk-list] Problems with Debian Stretch on SW 2.7. Can reinstall packages over and over again

[Robert Paschedag]

On 10/16/17 21:25, Paul-Andre Panon wrote:

On Saturday, October 14, 2017 12:02 AM, Robert Paschedag 
[mailto:robert.pasche...@web.de] wrote:

Am 14. Oktober 2017 01:38:59 MESZ schrieb Paul-Andre Panon 
:

On Fri, 13 Oct 2017 19:17:12, Robert Paschedag

Hi Robert,

I can confirm that. I've been experiencing the same thing with Ubuntu
14 clients last month and Ubuntu 16 clients this month. The python
packages had updated and attempts to update kept on cycling through
with the same packages identified as needing updates, until I went
through and manually copied the Multi-Arch: allowed settings for the
packages that had it (looking at the Packages on the Ubuntu repos). I
was thinking of doing what you propose but I've been to busy to dig
into the code to try to add the Multi-Arch field to the copied data. I
look forward to your changes.

Paul-Andre Panon
Senior systems administrator


Hi Paul-Andre,

the big problem is... "allowed" is not the only value for Multi-Arch. In Debian stretch 
"main" repo, there are 8979 Packages with "Multi-Arch" header. No way to do that by hand.

Agreed, but so far I have only had problems with packages where the missing Multi-Arch value is 
"allowed". Maybe I've just been lucky though. The annoying thing is that, even with the ~couple 
dozen cases of "Multi-Arch: allowed" in the Ubuntu main and universe repos (mostly from python and 
the gcc toolchain), every sync wipes out your last set of manual fixes.  When I ran into the problem, I found 
the clue to a workaround in matus' Jan 30th 2015 comment at 
http://www.devops-blog.net/spacewalk/registering-ubuntu-and-debian-servers-with-spacewalk, so this isn't a 
new issue. I'm not happy with his kludgy "fix" though since it also winds up adding that property 
to many packages where it doesn't apply.
Yeah. I'm also using that workaround from the bugzilla report about the 
missing Multi-Arch headers and in jessie, this really works quite good.
Now, with "stretch", this is just a nightmare. I was so happy, that now 
in SW2.7, the debian version string parsing has been improved and now 
debian has "improved" "apt". But that improvement somehow throws a big 
stick between your legs while you're running at max speed, causing you 
to crash and break with your face on the ground :-P





Another thing. I hope you can give me a hint. Apt now tries (or even just generates) 
"binary-all" package files for all "amd64" repos, the client has subscribed.
How can I stop that? All "architecture" settings are set to "amd64". Don't know, where 
this *feature* came from but it looks like breaking my "workaround" I'm trying to implement.

I'm not sure, we've only been using the 64-bit amd64 images, not the 32-bit 
i386 images. When I look at the Packages file on the binary-amd64 Ubuntu 
directory from the closest mirror, there doesn't seem to be a package with 
something other than Architecture: amd64 . Since we've been all 64-bit it 
hasn't been an issue for us, and maybe that's why I'm not having any issues 
with other possible values of Multi-Arch as well.


Thanks
Robert

Paul-Andre Panon
Senior systems administrator

Office: 604.629.5182 ext 2341 Mobile: 604.679.1617


I found the "error". It is really because of the "missing" "Release" 
file. If this is found, and there is an "Architectures:" header, the new 
"apt" will download the Packages for this architectures. If the 
"Release" is missing, "apt" will download the Packages for the clients 
configured "architectures" + "all".


This is a new behaviour.

But I think, that this is not my main error. Because I'm still using 
Steve Meier's "debian sync" tool to download and import the debian 
packages, I modified that to create a "temporary" file with the 
"package" name and possible "multi-arch" header, which I can insert, 
after SW has created his own "Packages" file.


But this does not yet work 100%, because there are sometimes more than 
one package with exact same name. I have to improve that and keep trying.


Really the best thing would be, if the "Multi-Arch" header would be 
added to the database. If I'm right, this header is already "present", 
while the .deb files gets parsed but it just gets ignored. And I don't 
know, how much work and modification is needed to fully implement this 
header to every .deb package.


Would be cool, if the main developers of SW could look into that issue 
and I'll really try to support them with as much information as possible 
to get this fixed.


As final information. This is not an error in SW. This is "an 
improvement" in Debian 9, which most of us (and I think most of SW 
developers) just did not get but its a major problem to "manage" debian 
9 with spacewalk.


Robert


___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list