Acknowledgement sent
to Helmut Grohne <[email protected]>:
New Bug report received and forwarded. Copy sent to piuparts developers team <[email protected]>.
(Tue, 04 Aug 2015 15:18:05 GMT) (full text, mbox, link).
Package: piuparts
Version: 0.64
Severity: wishlist
Tags: patch
User: [email protected]
Usertags: rebootstrap
During a partial archive cross rebuild, I discovered that many packages
failed to install. Being faced with many package installation failures
seems strange in the presence of piuparts, but then it occurred to me
that piuparts only tests native installation.
So I tried to test a foreign arch installation of libc6 with piuparts
and noticed that it succeeds despite failing to install the foreign arch
libc6. The initial dpkg --unpack fails, because the architecture is not
added to dpkg, but piuparts swallows that failure. I argue that in this
situation, piuparts should either actually perform the test or fail.
Being interested in actually testing stuff, I looked into extending
piuparts for this use case and I came up with the attached patch. It
makes both
piuparts --arch amd64 libc6_2.19-19_i386.deb
and
piuparts --arch amd64 -a libc6:i386
work in a meaningful way. I am not sure whether the new functionality
breaks aspects of piuparts that I did not test. It also is not clear
whether such liberal acceptance of packages and package names is desired
or whether piuparts would want to enforce explicit activation of foreign
arch testing via a new command line flag.
Still I hope that my patch can be a basis for adding this feature.
Helmut
Acknowledgement sent
to Holger Levsen <[email protected]>:
Extra info received and forwarded to list. Copy sent to piuparts developers team <[email protected]>.
(Tue, 04 Aug 2015 17:51:07 GMT) (full text, mbox, link).
control: tags -1 patch
control: block -1 by 687900
Hi Helmut,
piuparts is a policy checker. Multi-arch still ain't defined in policy. And
quite frankly I'm annoyed by all the multi-arch proponents and users who don't
care about documenting this properly, yet demand other people also work on
this.
So I don't think I'll be happy to support this until #687900 is fixed.
And then I don't like your implementation, thus removing the tag patch, as I
don't consider this patch ready for the reasons stated on irc. (Also you said
you're not sure what it breaks...)
< helmut> | h01ger: I have a patch now that makes that piuparts and "piuparts
--arch amd64 -a libc6:i386" work. not sure what it breaks. I'll submit it to
the bts anyway.
< h01ger> | at least "piuparts --arch amd64 -a libc6:i386" makes more sense
than "piuparts --arch=amd64 libc6_2.19-4_i386.deb"
< helmut> both work
< h01ger> | how should piuparts in the latter case know that you intend to use
a multi-arch setup (as opposed to assuming you want to install the wrong debs
for that arch)
< helmut> | h01ger: in both cases it simply assumes that you really want to
install the packages mentioned.
< h01ger> | thats your assumption but i dont think its a good one
< h01ger> | the latter should really just produce failure
< h01ger> | and the former probably should also not work, unless you also
provide an "--extra-multi-arch i386" switch too
I miss this --extra-multi-arch switch in the patch.
cheers,
Holger
Acknowledgement sent
to Andreas Beckmann <[email protected]>:
Extra info received and forwarded to list. Copy sent to piuparts developers team <[email protected]>.
(Tue, 04 Aug 2015 18:48:06 GMT) (full text, mbox, link).
Subject: Re: Bug#794575: support testing foreign arch installation
Date: Tue, 04 Aug 2015 20:44:34 +0200
Control: tags -1 - patch
On 2015-08-04 17:15, Helmut Grohne wrote:> Package: piuparts
> So I tried to test a foreign arch installation of libc6 with piuparts
> and noticed that it succeeds despite failing to install the foreign arch
> libc6. The initial dpkg --unpack fails, because the architecture is not
> added to dpkg, but piuparts swallows that failure. I argue that in this
> situation, piuparts should either actually perform the test or fail.
It should fail. So what command did you use to test it?
On 2015-08-04 19:47, Holger Levsen wrote:
> I miss this --extra-multi-arch switch in the patch.
I'd suggest explicit
--foreign-arch <arch>
(which may be given multiple times)
But I'm against automatic guessing for enabling it.
(We currently have it hardcoded for a few packages, mainly for testing
the ia32-libs switchover ... and for testing some crossbuild packages.)
Guessing from the dependencies won't work if the foreign dependency is
further down the dependency chain.
Andreas
Acknowledgement sent
to Helmut Grohne <[email protected]>:
Extra info received and forwarded to list. Copy sent to piuparts developers team <[email protected]>.
(Tue, 04 Aug 2015 21:48:08 GMT) (full text, mbox, link).
Control: tags -1 + patch
Control: severity -1 normal
On Tue, Aug 04, 2015 at 08:44:34PM +0200, Andreas Beckmann wrote:
> On 2015-08-04 17:15, Helmut Grohne wrote:> Package: piuparts
> > So I tried to test a foreign arch installation of libc6 with piuparts
> > and noticed that it succeeds despite failing to install the foreign arch
> > libc6. The initial dpkg --unpack fails, because the architecture is not
> > added to dpkg, but piuparts swallows that failure. I argue that in this
> > situation, piuparts should either actually perform the test or fail.
>
> It should fail. So what command did you use to test it?
On a amd64 system with an amd64 pbuilder base.tgz, the following command
succeeds (as in "PASS: All tests." and exit status 0) despite never
unpacking the given package.
piuparts -p /var/cache/apt/archives/libc6_2.19-19_i386.deb
As you say this behaviour is buggy, I am raising the severity
accordingly.
> I'd suggest explicit
> --foreign-arch <arch>
> (which may be given multiple times)
Implemented in the attached patch. It actually gets simpler that way.
> Guessing from the dependencies won't work if the foreign dependency is
> further down the dependency chain.
This remark is correct. My previous patch would not handle e.g.
crossbuild-essential-ppc64el. It can now be tested, but correctly
determines that crossbuild-essential-ppc64el is currently not
installable.
Helmut
Acknowledgement sent
to Holger Levsen <[email protected]>:
Extra info received and forwarded to list. Copy sent to piuparts developers team <[email protected]>.
(Tue, 04 Aug 2015 22:57:04 GMT) (full text, mbox, link).
control: severity -1 wishlist
control: tags -1 - patch
Hi,
On Dienstag, 4. August 2015, Helmut Grohne wrote:
> As you say this behaviour is buggy, I am raising the severity
> accordingly.
supporting multi-arch is still wishlist…
> Implemented in the attached patch. It actually gets simpler that way.
sigh, also please don't tag piuparts with "patch" until we think it's ready.
it's at least missing a patch for the piuparts manpage…
cheers,
Holger
Acknowledgement sent
to Andreas Beckmann <[email protected]>:
Extra info received and forwarded to list. Copy sent to piuparts developers team <[email protected]>.
(Tue, 04 Aug 2015 23:12:04 GMT) (full text, mbox, link).
Subject: Re: Bug#794575: support testing foreign arch installation
Date: Wed, 05 Aug 2015 01:10:48 +0200
On 2015-08-05 00:52, Holger Levsen wrote:
> On Dienstag, 4. August 2015, Helmut Grohne wrote:
>> As you say this behaviour is buggy, I am raising the severity
>> accordingly.
>
> supporting multi-arch is still wishlist…
there are two bugs here ...
* normal/important: installation fails but test passes for multiarch
argument libfoo:foreign
* wishlist: --foreign-architecture
that should be handled separately
(since adding the new flag does not fix the unexpected pass, it just
allows to do the intended thing in a more controlled manner)
Andreas
Acknowledgement sent
to Holger Levsen <[email protected]>:
Extra info received and forwarded to list. Copy sent to piuparts developers team <[email protected]>.
(Wed, 05 Aug 2015 07:12:03 GMT) (full text, mbox, link).
clone 794575 -1
severity -1 minor
retitle -1 piuparts should fail on multi-arch not pass
thanks
On Mittwoch, 5. August 2015, Andreas Beckmann wrote:
> > supporting multi-arch is still wishlist…
>
> there are two bugs here ...
agreed
> * normal/important: installation fails but test passes for multiarch
> argument libfoo:foreign
so that's bug -1 and is about the false positive when it should fail... I
still consider this a minor bug, as a.) it's undocumented, unsupported
behavior for piuparts and b.) multi-arch aint documented in policy. It would
be nice to fail properly...
> * wishlist: --foreign-architecture
and that's clearly a new feature, tracked as 794575.
cheers,
Holger
Acknowledgement sent
to Holger Levsen <[email protected]>:
Extra info received and forwarded to list. Copy sent to piuparts developers team <[email protected]>.
(Sat, 01 Sep 2018 11:51:05 GMT) (full text, mbox, link).
hi Helmut,
repeating what I said on irc so it doesnt get forgotten:
a.) please update your patch, it doesnt apply cleanly anymore:
$ patch -p1 --dry-run < bugreport.cgi\?att\=1\;bug\=794575\;filename\=piuparts_0.64%2Bnmu1.debdiff\;msg\=5
checking file debian/changelog
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED
checking file piuparts.py
Hunk #1 succeeded at 768 with fuzz 1 (offset 62 lines).
Hunk #2 FAILED at 728.
Hunk #3 succeeded at 995 (offset 103 lines).
Hunk #4 succeeded at 2137 (offset -26 lines).
Hunk #5 FAILED at 2527.
Hunk #6 succeeded at 2555 (offset -8 lines).
Hunk #7 succeeded at 3137 with fuzz 2 (offset 57 lines).
2 out of 7 hunks FAILED
b.) please include documentation, so at least for the piuparts manpage,
maybe also README.txt
Thanks.
--
cheers,
Holger
-------------------------------------------------------------------------------
holger@(debian|reproducible-builds|layer-acht).org
PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.