Re: Multiarch hinter on package tracker: Shall i obey ?
Hi, Rebecca N. Palmer wrote: > xul-ext-noscript I will check this out. Have a nice day :) Thomas
Javascript Re: Multiarch hinter on package tracker: Shall i obey ?
Without Javascript the web becomes a much more unexcited place. Regrettably Iceweasel seems not to offer finely granulated enabling. A whitelist would be nice. That's available in xul-ext-noscript
Re: Multiarch hinter on package tracker: Shall i obey ?
Hi, Quoting Thomas Schmitt (2016-09-18 09:09:09) > Johannes Schauer wrote: > > [the need for Javascript] should be reported as a bug against the tracker. > > Submitted as > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838178 > and subscribed to it. thanks! > > imagine an Architecture:all package doing this: > > #!/bin/sh > > gcc "$@" > > Certainly, what this architecture independent shell script does is > > architecture dependent and thus the package containing it cannot be > > marked as Multi-Arch:foreign. > > How can this script be "Architecture:all" if it does not work as expected > on some architectures ? > https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Architecture > says: > "all, which indicates an architecture-independent package." > > So is there a difference between "being architecture independent" and > "acting architecture independent" ? > (Hopefully i will never have to decide which of both is in effect.) When we say "an Architecture:all package is architecture independent" then we actually mean to say "an Architecture:all package contains content (files) which are the same across all architectures". In fact, we could easily live without Architecture:all packages. It would just mean that mirrors would then carry many identical binary packages for different architectures. So in the debian/control of src:libisofs you could mark libisofs-doc as Architecture:any and then you would get a libisofs-doc package on each architecture which would be completely identical (because src:libisofs seems to build reproducibly [1]). This would totally work as far as dependency relationships are concerned. It would just "waste" a little bit of mirror space because now you have to store X identical copies of a binary package, where X is the number of architectures in Debian. So the only thing that marking a package as Architecture:all tells you is, that its *content* is equal across all architectures and that it is thus not necessary to build and ship an individual copy of that binary package for each architecture. Thanks! cheers, josch [1] https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libisofs.html signature.asc Description: signature
Re: Multiarch hinter on package tracker: Shall i obey ?
Hi, Johannes Schauer wrote: > [the need for Javascript] should be reported as a bug against the tracker. Submitted as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838178 and subscribed to it. i wrote: > > Doesn't "Architecture: all" imply "Multi-arch: foreign" ? > No. Multi-arch:foreign means that a package of architecture foo is able to > satisfy the dependencies of a package with architecture bar. > [...] > imagine an Architecture:all package doing this: > #!/bin/sh > gcc "$@" > Certainly, what this architecture independent shell script does is > architecture dependent and thus the package containing it cannot be > marked as Multi-Arch:foreign. How can this script be "Architecture:all" if it does not work as expected on some architectures ? https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Architecture says: "all, which indicates an architecture-independent package." So is there a difference between "being architecture independent" and "acting architecture independent" ? (Hopefully i will never have to decide which of both is in effect.) Have a nice day :) Thomas
Re: Multiarch hinter on package tracker: Shall i obey ?
Hi, Quoting Thomas Schmitt (2016-09-17 17:51:16) > I saw the mouseover text "Toggle details", but the click only brought me to > https://tracker.debian.org/pkg/libisofs# > because i have Javascript disabled. that should be reported as a bug against the tracker. Without Javascript, the default should be to see the expanded view or otherwise the data will be invisible for users without Javascript. It should be simple to make it such that users with javascript see the collapsed view by default and have to click to expand it. Though since I also didn't see the drop-down "button" myself at first maybe this UI element of the tracker needs some rethinking anyways. > Is there a diagram or table which relates Architecture: and Multi-arch: ? I don't see how this should be done. The fields are not related except that they both have the character sequence "arch" in them. The Architecture field tells you whether the binary package is architecture specific or not and if it is architecture specific to which architecture it belongs. Architecture:all means that the data inside the package doesn't differ between different architectures. Hence, Architecture:all packages are only built once by buildds and can then be used on any other architecture where their dependencies are satisfied, even before there was multiarch. For all other values of the Architecture field, the binary package is architecture specific and before there was multiarch you only were able to install a package that was of Architecture:foo on a system with native architecture foo. You can find out your system's native architecture via $(dpkg --print-architecture). With multiarch it is now also potentially possible to install a package of architecture bar on a system with native architecture foo. A short summary: If a package is Multi-Arch:same then it is potentially possible to install a package with same name and version but different architecture at the same time. If a package is Multi-Arch:foreign, then a package of architecture foo is potentially able to satisfy a dependency of a package with architecture bar. > Coming back to the diagram question: Doesn't "Architecture: all" imply > "Multi-arch: foreign" ? No. Multi-arch:foreign means that a package of architecture foo is able to satisfy the dependencies of a package with architecture bar. This means that the functionality and interface that your Architecture:all package provides must be independent of the native architecture (Architecture:all packages are currently treated as if they were of the native architecture). While this is certainly the case for many Architecture:all packages, there also exist many for which it is not the case. Here an example: Imagine your Architecture:all package was just a shell script which provided the functionality of printing "hello world" on standard output: #!/bin/sh echo "hello world" The package that just contains this script could probably be marked as Multi-Arch:foreign as the functionality it provides is architecture independent. No matter the architecture of the package depending on it, they would get the requested functionality: the string "hello world". But now imagine an Architecture:all package doing this: #!/bin/sh gcc "$@" Certainly, what this architecture independent shell script does is architecture dependent and thus the package containing it cannot be marked as Multi-Arch:foreign. I hope this helps. Thanks! cheers, josch signature.asc Description: signature
Re: Multiarch hinter on package tracker: Shall i obey ?
Hi, Johannes Schauer wrote: > Thus, marking it as Multi-Arch:foreign should be correct. Helmut Grohne wrote: > Add "Multi-Arch: foreign" to the binary package section of libisofs-doc. Ok, i will add the line in libisofs, libburn, and libisoburn control files. --- Some more feedback about noob versus documentation: Johannes Schauer wrote: > You have to click at the small downward arrow at the left of the "Multiarch > hinter" text. I saw the mouseover text "Toggle details", but the click only brought me to https://tracker.debian.org/pkg/libisofs# because i have Javascript disabled. Helmut Grohne wrote: > This is a generic tracker.d.o UI aspect and not specific > to the multiarch hinter. Without Javascript the web becomes a much more unexcited place. Regrettably Iceweasel seems not to offer finely granulated enabling. A whitelist would be nice. Johannes Schauer wrote: > The package libisofs-doc is Architecture: all, does not contain any > maintainer scripts and does not have any dependencies on > architecture-dependent packages. Is there a diagram or table which relates Architecture: and Multi-arch: ? > "foreign" is no architecture Architecture: appeared to be nearest to undocumented Multi-arch:. So i had a look there in the hope to find another link. > https://wiki.ubuntu.com/MultiarchSpec Oh. At least the part "Binary package control fields" should be in Debian manuals, too. (Now that i know about it i see the link in the Multiarch/HOWTO. But that is not connected to https://www.debian.org/doc/debian-policy/ and the link is not overly prominent.) Coming back to the diagram question: Doesn't "Architecture: all" imply "Multi-arch: foreign" ? Thanks to Ubuntu, i now know the answer why one year ago i did not mark libisofs-doc by "Multi-arch: same" as the other packages stemming from libisofs. (Possibly lintian kept me from doing it.) Thank you for the explanations. Have a nice day :) Thomas
Re: Multiarch hinter on package tracker: Shall i obey ?
On Sat, Sep 17, 2016 at 04:00:28PM +0200, Thomas Schmitt wrote:
> i am preparing the Debian package for a new upstream release of libisofs
> and see on its tracker page
> https://tracker.debian.org/pkg/libisofs
> a new "action needed":
>
> "Multiarch hinter reports 1 issue(s)"
Thank you for looking into that.
> The link points to
> https://wiki.debian.org/MultiArch/Hints
>
> But where to see the actual complaint ?
tracker.d.o initially displays a compressed form for action items. On
the left of the item there is a little arrow. Clicking that reveals the
actual issues. This is a generic tracker.d.o UI aspect and not specific
to the multiarch hinter.
> The MultiArch/Hints wiki page says
> "marking it Multi-Arch: foreign usually is safe."
> but does not clearly state what it means by "usually".
There are a few obscure exceptions to that rule. For instance, if you
want a package that is only installable for the native architecture, you
can have it depend on an Architecture: all + Multi-Arch: no package.
Also triggers are ignored by the hinter and post-installation actions of
triggers could turn the hint invalid. For the Multi-Arch: foreign hints,
I am not aware of any real-world exceptional use cases.
I'm still looking for ways to improve the explanation text, but it turns
out that multiarch is hard to explain in general.
> There is no mentioning of "Multi-arch" in
> https://www.debian.org/doc/debian-policy/ch-controlfields.html
There are like 6 bugs for adding multiarch to policy. Progress is slow.
> More Google brings me to
> https://wiki.debian.org/Multiarch/HOWTO
> with the statement:
> "If a package is marked 'Multi-Arch: foreign', then it can satisfy
>dependencies of a package of a different architecture."
That's one of the better ones. Also consider
https://wiki.ubuntu.com/MultiarchSpec if you need a specification-like
document.
> I am about as confused as a year ago:
> "Multi-arch and debian/control"
> https://lists.debian.org/debian-mentors/2015/09/msg00403.html
> All packages got "Multi-arch: same" then, except libisofs-doc which
> got no Multi-arch header at all. I cannot find or remember the reason
> for that.
The reason here is that libisofs-doc is Architecture: all. The spec says
that Multi-Arch: same is not applicable to Architecture: all packages at
all. Thus marking it that way would be invalid.
Also things have changed a little since 2015. The whole business around
adding Pre-Depends on multiarch-support is gone. You can still add
${misc:Pre-Depends} to Pre-Depends to ease backporting, but in general
that transition is over and we don't need that Pre-Depends anymore.
> Could somebody please look into
> https://tracker.debian.org/media/packages/libi/libisofs/control-1.4.4-1
> and tell me what to do ?
Add "Multi-Arch: foreign" to the binary package section of libisofs-doc.
The practical effect is that if you install libisofs-dev for a foreign
architecture, its suggestion of libisofs-doc will become resolvable.
> (And was i really expected to google for a link to the 1.9 MB yaml file ?)
No. You were supposed to click the little arrow. Is there any way to
make that more clear?
Helmut
Re: Multiarch hinter on package tracker: Shall i obey ?
Hi, Quoting Thomas Schmitt (2016-09-17 16:00:28) > i am preparing the Debian package for a new upstream release of libisofs > and see on its tracker page > https://tracker.debian.org/pkg/libisofs > a new "action needed": > > "Multiarch hinter reports 1 issue(s)" > > The link points to > https://wiki.debian.org/MultiArch/Hints > > But where to see the actual complaint ? I was confused by this as well when I first saw the hints appear in the tracker. You have to click at the small downward arrow at the left of the "Multiarch hinter" text. Then you can see: There are issues with the multiarch metadata for this package. libisofs-doc could be marked Multi-Arch: foreign > Google "multiarch hinter" brings me to > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833623 > where i find in the patch a URL: > https://dedup.debian.net/static/multiarch-hints.yaml > which says: > - binary: libisofs-doc > description: 'libisofs-doc could be marked Multi-Arch: foreign' > link: https://wiki.debian.org/MultiArch/Hints#ma-foreign > severity: low > source: libisofs > The MultiArch/Hints wiki page says > "marking it Multi-Arch: foreign usually is safe." > but does not clearly state what it means by "usually". The package libisofs-doc is Architecture: all, does not contain any maintainer scripts and does not have any dependencies on architecture-dependent packages. Thus, marking it as Multi-Arch:foreign should be correct. It says "usually" because this analysis is wrong if any of the metadata the analysis is based on is wrong. > There is no mentioning of "Multi-arch" in > https://www.debian.org/doc/debian-policy/ch-controlfields.html Multiarch is not in policy yet but it has been in Debian since Wheezy. The four year old policy bug can be found here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687900 > nor is there an explanation of "foreign" in > > https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Architecture "foreign" is no architecture but one of the possible values of the Multi-arch field. > More Google brings me to > https://wiki.debian.org/Multiarch/HOWTO > with the statement: > "If a package is marked 'Multi-Arch: foreign', then it can satisfy >dependencies of a package of a different architecture." > > Duh ! > I am about as confused as a year ago: A better (and the probably still most complete) explanation is here: https://wiki.ubuntu.com/MultiarchSpec > "Multi-arch and debian/control" > https://lists.debian.org/debian-mentors/2015/09/msg00403.html > All packages got "Multi-arch: same" then, except libisofs-doc which > got no Multi-arch header at all. I cannot find or remember the reason > for that. Some packages are just neither Multi-arch same, foreign nor allowed. In the case of libisofs-doc, it is very likely that it can be correctly marked as "foreign". > Could somebody please look into > https://tracker.debian.org/media/packages/libi/libisofs/control-1.4.4-1 and > tell me what to do ? You could just mark libisofs-doc as Multi-Arch:foreign. > (And was i really expected to google for a link to the 1.9 MB yaml file ?) Nope and I agree that the current way to find the actual problem in the tracker is suboptimal. Thanks! cheers, josch signature.asc Description: signature
Multiarch hinter on package tracker: Shall i obey ?
Hi, i am preparing the Debian package for a new upstream release of libisofs and see on its tracker page https://tracker.debian.org/pkg/libisofs a new "action needed": "Multiarch hinter reports 1 issue(s)" The link points to https://wiki.debian.org/MultiArch/Hints But where to see the actual complaint ? Google "multiarch hinter" brings me to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833623 where i find in the patch a URL: https://dedup.debian.net/static/multiarch-hints.yaml which says: - binary: libisofs-doc description: 'libisofs-doc could be marked Multi-Arch: foreign' link: https://wiki.debian.org/MultiArch/Hints#ma-foreign severity: low source: libisofs The MultiArch/Hints wiki page says "marking it Multi-Arch: foreign usually is safe." but does not clearly state what it means by "usually". There is no mentioning of "Multi-arch" in https://www.debian.org/doc/debian-policy/ch-controlfields.html nor is there an explanation of "foreign" in https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Architecture More Google brings me to https://wiki.debian.org/Multiarch/HOWTO with the statement: "If a package is marked 'Multi-Arch: foreign', then it can satisfy dependencies of a package of a different architecture." Duh ! I am about as confused as a year ago: "Multi-arch and debian/control" https://lists.debian.org/debian-mentors/2015/09/msg00403.html All packages got "Multi-arch: same" then, except libisofs-doc which got no Multi-arch header at all. I cannot find or remember the reason for that. Could somebody please look into https://tracker.debian.org/media/packages/libi/libisofs/control-1.4.4-1 and tell me what to do ? (And was i really expected to google for a link to the 1.9 MB yaml file ?) Have a nice day :) Thomas
