Bug#903158: Multi-Arch: foreign and -dbgsym: too weak dependency
Hi,
I have BCC'ed debian-devel on this email to ask for input on this bug
(#903158) and ask parties that are interested to follow up there. I am
considering to remove the dependencies for -dbgsym packages on the
grounds that:
1) They are too weak when M-A: foreign is involved and they are not
always help (see the partial email quote from the bug below)
2) We now have a debuginfod service, so you do not even have to install
dbgsym packages anymore (if you configure gdb to use it). For the
cases where you do install the dbgsym, you still have to manage
inter-source dbgsym dependencies manually.
As a debhelper maintainer, I willing to either keep the status quo and
close the bug as wontfix or close the bug by removing the dependencies.
If you hoping for another outcome, I expect you to be ready to put the
effort and patches required to reach the outcome.
Thanks,
~Niels
On Sat, 4 Aug 2018 21:04:59 +0200 Helmut Grohne wrote:
Hi Niels,
On Sat, Aug 04, 2018 at 08:38:00AM +, Niels Thykier wrote:
> On Sat, 7 Jul 2018 11:40:54 +0300 "Yuriy M. Kaminskiy"
> wrote:
> > I think (at least, 'Multi-arch: foreign' *and* 'Architecture' != all)
> > packages should have explicit parent package arch dependency
> >Depend: foo:${Arch} (=${binary:Version})
> > instead of
> >Depend: foo (=${binary:Version})
> > Untested patch against debhelper 11.3.5 attached (please review
> > carefully, I'm neither M-A nor debhelper expert).
Yes, this makes somewhat sense.
Personally, I disagree with the Depends though. I've often been in the
situation of wanting to debug a foreign core file or remotely attaching
to a process on a different system. These dependencies were not helpful
at all in these situations. Personally, I'm in favour of making -dbgsym
packages dependency-less. I acknowledge that others see things
different.
In any case, we agree that if we want the dependency, then it is
presently too weak.
[...]
Bug#1021433: ITP: libequihash -- memory-hard Proof-of-Work with fast verification
Package: wnpp Owner: Joost van Baal-Ilić Severity: wishlist * Package name: libequihash Upstream Author : Dmitry Khovratovich and Stefan Marsiske * URL : https://github.com/stef/equihash * License : CC0-1.0 Programming Lang: C++ Description : memory-hard Proof-of-Work with fast verification Equihash implements the algorith as described in "Equihash: Asymmetric Proof-of-Work Based on the Generalized Birthday Problem" by Alex Biryukov and Dmitry Khovratovich, 2016, DOI:10.14722/ndss.2016.23108. This code, by Stefan Marsiske, is a fork of an earlier implementation by Khovratovich at https://github.com/khovratovich/equihash/ ; it provides a library, a C API and Python bindings. The cryptographic password storage SPHINX (pwdsphinx and libsphinx) depend upon equihash. Upstream started packaging work at https://github.com/stef/equihash/tree/master/debian . I'll work from that first packaging code, probably using a repository at salsa.debian.org . See https://www.ctrlc.hu/~stef/blog/posts/sphinx.html and https://nlnet.nl/project/OpaqueSphinxServer/ for more background information. See e.g. https://core.ac.uk/download/pdf/31227294.pdf for a copy of the original article. The SPHINX project was funded through the NGI0 PET Fund, a fund established by NLnet with financial support from the European Commission's Next Generation Internet programme, under the aegis of DG Communications Networks, Content and Technology under grant agreement No 825310. Bye, Joost
Bug#1021437: ITP: lomiri-terminal-app -- Terminal App for Lomiri Operating Environment
Package: wnpp Severity: wishlist Owner: Mike Gabriel X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: lomiri-terminal-app Version : 1.0.3 Upstream Author : UBports Developers * URL : https://gitlab.com/ubports/development/apps/lomiri-terminal-app * License : GPL-3(+), GPL-2(+), LGPL-2+, LGPL-3 Programming Lang: C++/QML Description : Terminal App for Lomiri Operating Environment This app is a core app for Ubuntu Touch's shell Lomiri. Ubuntu Touch is a mobile OS developed by the UBports Foundation. Lomiri is its operating environment optimized for touch based human-machine interaction, but also supports convergence (i.e. switching between tablet/phone and desktop mode). . This package provides Lomiri's Terminal App. . This package will be maintained by Debian's UBports Packaging Team.
Re: Bug#903158: Multi-Arch: foreign and -dbgsym: too weak dependency
On Sat, 08 Oct 2022 at 11:00:30 +0200, Niels Thykier wrote:
> > > On Sat, 7 Jul 2018 11:40:54 +0300 "Yuriy M. Kaminskiy"
> > > wrote:
> > > > I think (at least, 'Multi-arch: foreign' *and* 'Architecture' != all)
> > > > packages should have explicit parent package arch dependency
> > > >Depend: foo:${Arch} (=${binary:Version})
> > > > instead of
> > > >Depend: foo (=${binary:Version})
So as a concrete example, for sed:amd64 (which is Multi-Arch: foreign),
sed-dbgsym:amd64 currently depends on sed (= 4.8-1) which can be satisfied
by sed:i386, and the request is for it to explicitly depend on
sed:amd64 (= 4.8-1) instead?
I was under the impression that the Debian archive does not allow
dependencies with an explicit architecture like this, only the :any
qualifier for M-A: allowed packages (like python3:any). Am I basing this
on outdated information?
Policy §7 doesn't currently document multiarch qualifiers at all.
deb-control(5) documents foo:any and foo:amd64.
smcv
Re: Bug#903158: Multi-Arch: foreign and -dbgsym: too weak dependency
Simon McVittie:
On Sat, 08 Oct 2022 at 11:00:30 +0200, Niels Thykier wrote:
On Sat, 7 Jul 2018 11:40:54 +0300 "Yuriy M. Kaminskiy"
wrote:
I think (at least, 'Multi-arch: foreign' *and* 'Architecture' != all)
packages should have explicit parent package arch dependency
Depend: foo:${Arch} (=${binary:Version})
instead of
Depend: foo (=${binary:Version})
So as a concrete example, for sed:amd64 (which is Multi-Arch: foreign),
sed-dbgsym:amd64 currently depends on sed (= 4.8-1) which can be satisfied
by sed:i386, and the request is for it to explicitly depend on
sed:amd64 (= 4.8-1) instead?
In essence, yes.
Though, I think it is better to read OP's email as a "functional
requirement" rather than the exact way to implement it.
I was under the impression that the Debian archive does not allow
dependencies with an explicit architecture like this, only the :any
qualifier for M-A: allowed packages (like python3:any). Am I basing this
on outdated information?
Policy §7 doesn't currently document multiarch qualifiers at all.
deb-control(5) documents foo:any and foo:amd64.
smcv
It is not clear to me that the archive supports it (or that apt, dak and
dpkg are all aligned on what "foo:amd64" means). However, as noted in
my debian-devel mail, I am not willing to spend time figuring out
whether "foo:amd64" works and much less provide patches if it does not.
Accordingly, I am not planning to do any research in that area.
Thanks,
~Niels
Re: Bits from the DAMs
Regarding the following, written by "Joerg Jaspert" on 2022-10-08 at 16:12 Uhr +0200: 3. Thresholds for DAM action In various recent discussions we have noticed people mention that they "cannot say this, or DAM may expel them". This is not backed by facts (we've only had to go through with 8 expulsions since 2006) and it originates from wrong assumptions. DAM action is the last step in a long process, with others involved first. This is not an accurate representation. There have been cases where DAM have threatened to expel (though the expulsion didn't happen, so didn't count in the statistics), and there was *no* long process with others involved first. In my case, you didn't even tell me details about the allegations (just the threat), nor heard my side of the story before wielding the big hammer. Not interested in relitigating the past. But I cannot let you get away with claiming that DAM has always been impartial. Good if this has since changed, and you guys have put in place protocols to ensure your own accountability. -- .''`. martin f. krafft @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems "i sometimes think that god in creating man somewhat overestimated his ability." -- oscar wilde digital_signature_gpg.asc Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Re: Bug#903158: Multi-Arch: foreign and -dbgsym: too weak dependency
On Sat, 2022-10-08 at 11:00 +0200, Niels Thykier wrote: > 2) We now have a debuginfod service, so you do not even have to install > dbgsym packages anymore (if you configure gdb to use it). For the > cases where you do install the dbgsym, you still have to manage > inter-source dbgsym dependencies manually. The debuginfod service is not protected by the archive keys and it isn't available offline, so I currently prefer to use debian-goodies' `find-dbgsym-packages --install` command. Since I don't have any foreign architectures enabled, I can't be affected by the issue with not strict enough dependencies though. Removing all dependencies would mean that removing an obsolete library package would no longer also remove the dbgsym package and a lot of obsolete library packages would accumulate without manual action and it could be time consuming to track down no longer used dbgsym packages. Keeping the dependencies does also block some use-cases, some of that can be worked around using debuginfod, with the usual downsides. I have often wanted a different kind of relationship between packages and their dbgsym packages than mere Depends. Currently when a dbgsym is installed it keeps the library package installed even after it is no longer used and both should be auto-removed. So I believe the optimal thing to do would be stricter depends for now and later if apt adds some kind of special handling for dbgsym, then all of the Depends could be dropped to enable more use-cases. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1021475: ITP: libgeo-coordinates-transform-perl -- Transform latitude/longitude between coordinate functions
Package: wnpp Severity: wishlist Owner: Bas Couwenberg X-Debbugs-Cc: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libgeo-coordinates-transform-perl Version : 0.10 Upstream Author : Steve Troxel * URL : https://metacpan.org/release/Geo-Coordinates-Transform * License : Artistic or GPL-1+ Programming Lang: Perl Description : Transform latitude/longitude between coordinate functions There are several formats used to present geographic coordinates. For example: * DMS Degrees:Minutes:Seconds (48 30 30, -117 30' 30") * DM Degrees:Decimal-Minutes (48 30.5, -117 30.5'), * DD Decimal-Degrees (48.508, -17.508) Geo::Coordinates::Transform converts a list of provided latitude and longitude coordinates in any of the three formats above (mixed input is ok) and converts to the desired format. The package will be maintained under the umbrella of the Debian Perl Group. This package is required for libgeo-gpx-perl (>= 1.00).
Bug#1021476: ITP: libgeo-calc-perl -- Simple geo calculator for points and distances
Package: wnpp Severity: wishlist Owner: Bas Couwenberg X-Debbugs-Cc: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libgeo-calc-perl Version : 0.12 Upstream Author : Sorin Alexandru Pop * URL : https://metacpan.org/release/Geo-Calc * License : Artistic or GPL-1+ Programming Lang: Perl Description : Simple geo calculator for points and distances Geo::Calc implements a variety of calculations for latitude/longitude points All these formulare are for calculations on the basis of a spherical earth (ignoring ellipsoidal effects) which is accurate enough* for most purposes. [ In fact, the earth is very slightly ellipsoidal; using a spherical model gives errors typically up to 0.3% ]. The package will be maintained under the umbrella of the Debian Perl Group. This package is required for libgeo-gpx-perl (>= 1.00).
Bug#1021477: ITP: libmath-units-perl -- Perl module for measurement unit conversion
Package: wnpp Severity: wishlist Owner: Bas Couwenberg X-Debbugs-Cc: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libmath-units-perl Version : 1.3 Upstream Author : Daniel Muey * URL : https://metacpan.org/release/Math-Units * License : Artistic or GPL-1+ Programming Lang: Perl Description : Perl module for measurement unit conversion The Math::Units module converts a numeric value in one unit of measurement to some other unit. The units must be compatible, i.e. length can not be converted to volume. If a conversion can not be made an exception is thrown. A combination chaining and reduction algorithm is used to perform the most direct unit conversion possible. Units may be written in several different styles. An abbreviation table is used to convert from common long-form unit names to the (more or less) standard abbreviations that the units module uses internally. All multiplicative unit conversions are cached so that future conversions can be performed very quickly. The package will be maintained under the umbrella of the Debian Perl Group. This package is required for libgeo-calc-perl (#1021476) which in turn is required for libgeo-gpx-perl (>= 1.00).
