Re: Debian choice of upstream tarballs for packaging

[Simon Richter]

Hi,

On 8/25/21 1:21 AM, Sean Whitton wrote:


 From my point of view, signing git tags is no less well established a
best practice than signing tarballs -- in fact, to me, it seems *more*
well established.


That is ecosystem dependent.

FWIW, I'd love to see git bundles as a source archive format -- this 
would allow shipping a (signed) tag, its commit, and the tree and blob 
objects for that commit as a single file that can be built in a 
reproducible way and allows changes on top to be easily tracked, 
including the branch point.


In the absence of an "official" upstream release tarball, using this 
format also makes it clear that this is a git snapshot, so no 
explanation is needed how that archive was created.


   Simon



OpenPGP_signature
Description: OpenPGP digital signature

Re: BTS not archiving Bcc: mails? [was: Re: inconsistent mailgraph settings]G

[Vincent Lefevre]

On 2021-08-23 07:43:07 +0100, Tim Woodall wrote:
> On Mon, 23 Aug 2021, Holger Wansing wrote:
> > Am 23. August 2021 07:19:26 MESZ schrieb Tomas Pospisek 
> > :
> > > 
> > > The thing is, if you close a bug report via `Bcc:
> > > -cl...@bugs.debian.org` then the mail that arrives at the
> > > BTS does *not* have the -cl...@bugs.debian.org address in
> > > the email header but only in the mail envelope - that is, when
> > > connecting the sending MTA will tell the BTS MTA "RCPT TO:
> > > -cl...@bugs.debian.org"
> > > and that's it. This will close the bug, but the address
> > > -cl...@bugs.debian.org will not be visible in the email
> > > that's archived...
> > 
> > Funny, just some minutes before your mail I have filed
> > bug #992755 as a place to test and document this
> > behaviour.
> > 
> > It's indeed as you stated.
> > 
> > Thus, I will reopen and rename that bug accordingly.
> 
> When I toggle "show useless messages" I think I do see the closure. And
> I see the one for 989734 too.

Yes, but only the notification (and one needs to see the full message).
But what if the close message is sent when an empty From or with
a From containing the -cl...@bugs.debian.org address
of the bug[*] (such messages could come from spammers)?

[*] That could yield a loop, and this may depend on how it is broken.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: src:developers-reference - pt_BR translation initiative

[Thiago Pezzo (tico)]

Hi, Sean,

> Please consider Debian Policy too! We've got po4a infra set up.
That would be great too. Today we'll have our team's BoF at DebConf, I'll talk 
about translating the Debian Policy.

Thanks!
Thiago Pezzo (Tico)

August 24, 2021 8:24 PM, "Sean Whitton"  wrote:

> Hello,
> 
> On Wed 18 Aug 2021 at 05:52PM GMT, Thiago Pezzo (tico) wrote:
> 
>> Hi, there,
>> 
>> I have been thinking about opening a new translation front to our team, when
>> I saw Holger’s talk about the developer's reference handbook [1]. It would be
>> another great opportunity to our (small) team to contribute to the Debian
>> community.
> 
> Please consider Debian Policy too! We've got po4a infra set up.
> 
> --
> Sean Whitton

Re: src:developers-reference - pt_BR translation initiative

[Mattia Rizzolo]

On Wed, Aug 25, 2021 at 12:11:17PM +, Thiago Pezzo (tico) wrote:
> Hi, Sean,
> 
> > Please consider Debian Policy too! We've got po4a infra set up.
> That would be great too. Today we'll have our team's BoF at DebConf, I'll 
> talk about translating the Debian Policy.

That's all nice and dandy, however please make sure to keep up with
those translations...

/me - who is kind of not amused at how the German (and clearly also the
newly added Portuguese) are not keeping up at all with devscripts
-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#992946: ITP: python-autopage -- library to provide automatic paging for console output

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: python-autopage
  Version : 0.4.0
  Upstream Author : Zane Bitter 
* URL : https://github.com/zaneb/autopage
* License : Apache-2.0
  Programming Lang: Python
  Description : library to provide automatic paging for console output

 Autopage is a library to automatically display terminal output from a program
 in a pager (like less) whenever you need it, and never when you don't. And it
 only takes one line of code.

Note: This is a new dependency of python-cliff, which is at the heart of
displaying openstack CLI output.

Bug#992952: ITP: python-baron -- Full Syntax Tree for python for refactoring code

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-devel@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-baron
  Version : 0.9
  Upstream Author : Tin Tvrtković 
* URL : https://github.com/PyCQA/baron
* License : Apache-2.0
  Programming Lang: Python
  Description : Full Syntax Tree for python for refactoring code

 Baron is a Full Syntax Tree (FST) library for Python.
 Unlike an Abstract Syntax Tree (AST)
 which drops some syntax information in the process of its creation
 (like empty lines, comments, formatting),
 an FST keeps everything and guarantees functionally identical output.

This package is needed by recent releases of matrix-mirage.
It will be maintained in the collaborative Debian "team" -
if someone wants to adopt it then they are most welcome!

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmEmPSkACgkQLHwxRsGg
ASE3+A//VaBI2+RF6Lz86jnU9lhtO4/cHPaObpUAua77xGPw03pC9Mt4/dNARQoA
O27eIVw1mNLhZRBDTLl64Q9e7P7OWLxeiYwRafu9+nCL+f/xLvworLRUSvApQy8R
jgqjYTlLUi578KC9FTM04tyQAefke6auU+lU163dTYmQJtrPN+DC48tjc+7bhejx
SXYLlStPbDxs1TuSUan0pd/LeA0yCeMxqxzeICVaFR3nSmJ/vod29hArxy19GQhc
AZy2dlXwmxZlhQyWFVXFUwtj+5QVMBx/+0/NPvLeSIVr8/GuSiTe6MlHn+BqlsdI
xGKr7VUiyJ5b100toYPXl12h57IM4SlqQ/j/2qobVNSFNVlsE5yAq5JSx2xi3mGc
PYA/V2KunR1XeM9n4wVExFWkkzPihl4LhCyoAs1umTxseK0259XNbnXO+g4ZtMAP
6zWWawV8DPolU+gHCgSJtH87HCVN1tDsyAS6dcdTtINnGbV49Jo0wD6auYA4cXgc
oV4uRl+S5qXtHRr4aUCeTmGC/6kiJPvLAkch7ZU671IKaNhxNu1fnbGYb3GhYSf9
9b50g3yz/5rfdP2HcfPEUWRq783sRzGIiOVz/1vc4dx0izxYhAURC2bhmaTGhM+l
8LO+GRLeRbRDSiv5/Q8rwLBwAz5z19xXGxne9Ry05/c3/14zPt0=
=2ymV
-END PGP SIGNATURE-

Bug#992954: ITP: python-redbaron -- abstraction on top of the baron FST for python

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-devel@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-redbaron
  Version : 0.9.2
  Upstream Author : Tin Tvrtković 
* URL : https://github.com/PyCQA/redbaron
* License : Apache-2.0
  Programming Lang: Python
  Description : abstraction on top of the baron FST for python

 RedBaron is a python library and tool
 powerful enough to be used in IPython
 solely with the intent
 of making the process of **writing code that modify source code**
 as easy and as simple as possible.
 That includes writing custom refactoring, generic refactoring, tools,
 IDE or directly modifying you source code in IPython
 with a higher and more powerful abstraction
 than the advanced texts modification tools that you find
 in advanced text editors and IDE.

This package is needed by recent releases of matrix-mirage.
It will be maintained in the collaborative Debian "team" -
if someone wants to adopt it then they are most welcome!

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmEmQT0ACgkQLHwxRsGg
ASFsTBAAl2v9LR8ad1ymu7X/sh2Hbx9/m/Mp5nCmtNRwtOUuK+J7+HHkE54cZm/2
ajBsO+Ter+F3k/2LwpDZAF5ANcWF/5/5BEKyo23FioYK8RVbQrgSK4RHPvV5JAfN
5tv29uOAXCsv06DPKL0ED+BhUEBBDs8MpqkJoIqOdrOcnxAXpCuGIrSC7CC1k7bO
KqPd1AJBMxMoXL4CoFf38WzPNj6mZM7WNM7jkMBUjyQ19r0jbB1Z6aFFT5zimUs4
dEYbzxk5Xlvob86M6UczYGLp7z5QetIcxxn1O/7+RZYKwsj2aQVX6hSAd6sW3Ue7
WMRFo2QptrvA8Bmrk2AGPcGmrihhqayye2WuBRSVmSMjctSed5AEmmx/fOzBXtux
qen7dr4owBFRw/0XUpyqvusPfeImag6nf7G4jGedrpXm8l02T9VHKj3GMNM7HMbb
4rcQQh4NiPxuYnVhvrMg05V39BRuEnEc6CKcz0nLf8duYhY8e4En4JpIVbHzGiwK
/LJzPPAulUi5JYme1HZf82x7F5Saxs7rAXS6MA0k9u+SKdeLYjsABle72ysrE0sm
zSqHPMoCrWg7/lso+3XXfa6fQ0C40vRPsw89es8Ma/ys1+52xWcWwlAhKma8cUZG
xYEkXjILKjOhu2KzNSbWczn5K09nd9S7YZmg38YdEeAWcKm3jmI=
=KXL7
-END PGP SIGNATURE-

Package name misspelled in binNMU changelogs

[The Wanderer]

I'm not sure if this is worth giving any attention to, but it's the sort
of thing that's going to keep bothering me at a mild level if nothing is
done about it, so I figure I might as well at least ask.


Over the period since the release, I've seen quite a few packages show
up in testing with an automated-looking changelog entry along the lines of:

  * Binary-only non-maintainer upload for [arch]; no source changes.
  * Rebuild to drop dependency on libgdk-puxbif2.0-0

This has the vowel-transposition spelling error of "puxbif" instead of
"pixbuf".

There are currently 70 changelog entries of that form on my computer;
how many other packages might be affected I don't know.


If this were a simple spelling error in the changelog wording, I'd
probably just ignore it. Since it's referencing the name of another
package, however, that doesn't seem quite right; at the very least, it's
going to make looking for changes which reference that other package harder.

If I saw a spelling error like this in the changelog for just one single
package, I'd probably file a wishlist bug report against that package to
request that the shipped changelog be retroactively updated to correct
the error, and leave it at that.

Since the number of affected packages (and, I suspect, source packages)
is so sizable, however, that doesn't seem entirely reasonable; not only
would that be a lot of tiny wishlist bugs, even identifying the set of
affected packages isn't something I'm in a position to do without what
to me is a noticeable degree of effort.


Is there any reasonable way to get this spelling error corrected in the
changelogs across all these packages?

Or is this too minor to be worth bothering with, and something that
should be just left to lie as it stands?

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Package name misspelled in binNMU changelogs

[Andrey Rahmatullin]

On Wed, Aug 25, 2021 at 09:19:34AM -0400, The Wanderer wrote:
> Is there any reasonable way to get this spelling error corrected in the
> changelogs across all these packages?
As those are specifically binNMU changelogs, I don't think so.

> Or is this too minor to be worth bothering with, and something that
> should be just left to lie as it stands?
Definitely yes and yes.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Q: Use https for {deb,security}.debian.org by default

[Julien Cristau]

On Sat, Aug 21, 2021 at 10:28:04AM +0200, Wouter Verhelst wrote:
> On Thu, Aug 19, 2021 at 10:11:33PM +, Jeremy Stanley wrote:
> > On 2021-08-19 16:37:13 -0400 (-0400), Kyle Edwards wrote:
> > > On 8/19/21 3:46 PM, Simon Richter wrote:
> > > > For the most part, users would configure https if they are behind a
> > > > corporate firewall that disallows http, or modifies data in-flight so
> > > > signature verification fails, everyone else is better off using plain
> > > > http.
> > > 
> > > Or they might configure https on the sheer principle of not wanting to 
> > > have
> > > their traffic hoovered up by their ISP or anyone else who might be
> > > listening.
> > 
> > While this does complicate it, a snooping party can still know the
> > site they're connecting to via SNI happening unencrypted,
> 
> SNI is not unencrypted if you do TLS1.3...
> 
It is, though...  ECH (née ESNI)
https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ is still WIP.

Cheers,
Julien

Re: Package name misspelled in binNMU changelogs

[Tomas Pospisek]

On 25.08.21 15:23, Andrey Rahmatullin wrote:
> On Wed, Aug 25, 2021 at 09:19:34AM -0400, The Wanderer wrote:
>> Is there any reasonable way to get this spelling error corrected in the
>> changelogs across all these packages?
> As those are specifically binNMU changelogs, I don't think so.

You still can do a NMU or send a patch to the maintainer...

>> Or is this too minor to be worth bothering with, and something that
>> should be just left to lie as it stands?
> Definitely yes and yes.
That's in the eye of the beholder I'd say. I'd rather have package 
spellings cleaned up.


*t

Re: Debian choice of upstream tarballs for packaging

[Thomas Goirand]

On 8/16/21 3:18 AM, Paul Wise wrote:
> Hi all,
> 
> I noticed that sometimes Debian's choice of upstream source for
> packaging can be suboptimal. This is especially apparent for the
> different per-language upstream packaging ecosystems[1], where the
> upstream packaging differs from the upstream VCS in some significant
> ways, including missing files, prebuilt files, embedded copies etc.
> 
> While the upstream VCS also sometimes has these issues, it is often
> much less problematic than the upstream packaging ecosystems.
> 
> I'd like to suggest that we standardise on the upstream VCS for our
> orig.tar.gz files and phase out use of upstream packaging ecosystems.
> 
> For packages where the upstream packaging uses a tarball and it is
> accompanied by an OpenPGP signature, and the differences between the
> upstream VCS and the tarball aren't too problematic, we could use the
> tarball in preference to the VCS due to having a signature.
> 
> While discussing PyPI with the Python team, it was pointed out that
> sometimes the tarball contains things that cannot be regenerated from
> just the VCS snapshot, such as information stored in the VCS history,
> so perhaps the recommendation should be to prefer the VCS but always
> compare the VCS with upstream tarballs and packaging ecosystem tarballs
> using diffoscope in order to discover differences important to Debian.
> 
> I'd also like to see upstream tarball export systems switch to plain
> VCS exports plus additional tarballs for files like autotools cruft.
> 
> If there is rough consensus we could add lintian complaints when Debian
> watch files or copyright source locations refer to these ecosystems.
> 
> 1. the ecosystems I'm talking about include cargo, npm, browser
> extensions, rubygems, pypi, CPAN etc.

+1 to deprecate PyPi links.

It's been *years* since I encounter a PyPi package that doesn't have a
Git repo as its homepage (and unfortunately, 99% on Github).

I wrote this many times, but I don't see why we should use any "upstream
tarball" when the Git repository itself contains the tarball with:

git archive --prefix=$(DEBPKGNAME)-$(VERSION)/ $(GIT_TAG) \
| xz >../$(DEBPKGNAME)_$(VERSION).orig.tar.xz

(which leads to a .xz, which is nicer)

Not only then, only only has to merge the upstream tag in the Debian
branch to get the new release, but on top, no need to "gbp import" or
"pristine-tar commit", and a single packaging branch becomes enough.

I very much wish this packaging workflow gained more traction, and the
pristine-tar abomination dies...

Cheers,

Thomas Goirand (zigo)

Re: Package name misspelled in binNMU changelogs

[Sebastian Ramacher]

On 2021-08-25 16:07:02, Tomas Pospisek wrote:
> On 25.08.21 15:23, Andrey Rahmatullin wrote:
> > On Wed, Aug 25, 2021 at 09:19:34AM -0400, The Wanderer wrote:
> >> Is there any reasonable way to get this spelling error corrected in the
> >> changelogs across all these packages?
> > As those are specifically binNMU changelogs, I don't think so.
> 
> You still can do a NMU or send a patch to the maintainer...

Any future upload or binNMU will get rid of my typo without any
additional action.

Cheers

> 
> >> Or is this too minor to be worth bothering with, and something that
> >> should be just left to lie as it stands?
> > Definitely yes and yes.
> That's in the eye of the beholder I'd say. I'd rather have package spellings
> cleaned up.
> 
> *t
> 

-- 
Sebastian Ramacher

Re: Package name misspelled in binNMU changelogs

[The Wanderer]

On 2021-08-25 at 10:22, Sebastian Ramacher wrote:

> On 2021-08-25 16:07:02, Tomas Pospisek wrote:

>> You still can do a NMU or send a patch to the maintainer...
> 
> Any future upload or binNMU will get rid of my typo without any 
> additional action.

So no action is needed, this will resolve eventually in any case, as
long as there's ever another update to the affected package?

In that case, that entirely addresses my concern, and I apologize for
the noise.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Debian choice of upstream tarballs for packaging

[Simon Richter]

Hi,


I wrote this many times, but I don't see why we should use any "upstream
tarball" when the Git repository itself contains the tarball with:



git archive --prefix=$(DEBPKGNAME)-$(VERSION)/ $(GIT_TAG) \
| xz >../$(DEBPKGNAME)_$(VERSION).orig.tar.xz



(which leads to a .xz, which is nicer)


"git archive" is reproducible, for simplicity I wouldn't use a prefix 
though. xz has some issues with reproducibility, AFAIK "-T2" makes it 
disable some internal heuristics that are based on the machine it is 
running on, and generates consistent output.


   Simon



OpenPGP_signature
Description: OpenPGP digital signature

Re: Package name misspelled in binNMU changelogs

[Andrey Rahmatullin]

On Wed, Aug 25, 2021 at 04:07:02PM +0200, Tomas Pospisek wrote:
> >> Is there any reasonable way to get this spelling error corrected in the
> >> changelogs across all these packages?
> > As those are specifically binNMU changelogs, I don't think so.
> 
> You still can do a NMU or send a patch to the maintainer...
You cannot do a NMU, or send a patch, for a binNMU changelog.

> >> Or is this too minor to be worth bothering with, and something that
> >> should be just left to lie as it stands?
> > Definitely yes and yes.
> That's in the eye of the beholder I'd say. I'd rather have package spellings
> cleaned up.
In that case you should make changeless sourceful uploads for the affected
packages.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Debian choice of upstream tarballs for packaging

[Jeremy Stanley]

On 2021-08-25 16:11:37 +0200 (+0200), Thomas Goirand wrote:
[...]
> I wrote this many times, but I don't see why we should use any "upstream
> tarball" when the Git repository itself contains the tarball with:
> 
> git archive --prefix=$(DEBPKGNAME)-$(VERSION)/ $(GIT_TAG) \
>   | xz >../$(DEBPKGNAME)_$(VERSION).orig.tar.xz
> 
> (which leads to a .xz, which is nicer)

This is a very absolutist statement. As pointed out in prior
discussions, not everything which makes it into an upstream's
release tarball is necessarily tracked in revision control. And for
things which are tracked in revision control, they may sometimes
need to be extracted from the revision control metadata rather than
kept within the worktree, so would not be included by naive git
archive output. You could perform the necessary steps to
extract/assemble this data at package build time, but may need a
copy of the actual upstream Git repository on hand in order to do
so. Some of these extracted files may even be referenced in
copyrights (e.g. an AUTHORS file), with reliance on the worktree
contents alone leading to a legally undistributable downstream copy.

> Not only then, only only has to merge the upstream tag in the Debian
> branch to get the new release, but on top, no need to "gbp import" or
> "pristine-tar commit", and a single packaging branch becomes enough.
[...]

Yes, if you have the upstream Git repository, things like revision
history can be accessed when generating the source package. However,
if upstream already supplies signed source release tarballs with
this extracted for you, and guarantees through testing that they
don't omit files from the worktree in their official tarballs,
redoing all that at source package build time does seem marginally
obsessive (though I suppose that's fine so long as you actually
remember to do it).
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

Re: Debian choice of upstream tarballs for packaging

[Theodore Ts'o]

On Wed, Aug 25, 2021 at 04:11:37PM +0200, Thomas Goirand wrote:
> 
> It's been *years* since I encounter a PyPi package that doesn't have a
> Git repo as its homepage (and unfortunately, 99% on Github).
> 
> I wrote this many times, but I don't see why we should use any "upstream
> tarball" when the Git repository itself contains the tarball with:
> 
> git archive --prefix=$(DEBPKGNAME)-$(VERSION)/ $(GIT_TAG) \
>   | xz >../$(DEBPKGNAME)_$(VERSION).orig.tar.xz
> 
> (which leads to a .xz, which is nicer)

Well, if we don't use an "upstream tarball", we do need to keep our
own private archive the Git repository.  After all, there is no
guaranteee that the upstream git repo might disappear in the future.

Simon's proposal that use use a tarball of the bare git repo
containing all of the git objects needed leading up to the signed tag
works, but isn't necessarily the most efficient over time, since we
would be keeping multiple copies of redundant git repos in
snapshots.debian.org, or across multiple Debian versions in our ftp
archives.  But it at least guarantees if we will continue to have
access to the source even if the upstream git repo goes *poof*.

> Not only then, only only has to merge the upstream tag in the Debian
> branch to get the new release, but on top, no need to "gbp import" or
> "pristine-tar commit", and a single packaging branch becomes enough.
> 
> I very much wish this packaging workflow gained more traction, and the
> pristine-tar abomination dies...

Sure, but it implies that the git repos on salsa and/or dgit have to
become our official source of record for the purposes of GPL
compliance.  Which means we need to be a lot more careful about ever
allowing those git trees from being deleted or rewritten, even if the
goal is to remove files that might be found to be problematic
copyright licensing perspective.

- Ted

Re: Looking for Estonian DD-s

[Wouter Verhelst]

On Mon, Aug 23, 2021 at 04:12:43AM +, Paul Wise wrote:
> On Sun, Aug 22, 2021 at 2:31 PM Aivar Annamaa wrote:
> 
> > Is here someone, who can meet me in Tartu, Estonia or is willing to
> > arrange this over the internet? Perhaps I could sign a statement about
> > my identity with Estonian ID card?
> 
> I checked the list of lists of Debian locations and there are no
> Debian members that list their location as Estonia. It generally isn't
> accepted to sign keys over the internet or other electronic means.

Disagree. Why would that be the case?

By signing an OpenPGP key you certify that you are sufficiently
convinced that the key's holder is who they say they are, and that they
control their key. The easiest way to do that is to meet someone in
person, but that doesn't mean it's the *only* possible way.

Am I missing something?

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: Looking for Estonian DD-s

[Samuel Thibault]

Wouter Verhelst, le mer. 25 août 2021 17:06:39 +0200, a ecrit:
> On Mon, Aug 23, 2021 at 04:12:43AM +, Paul Wise wrote:
> > On Sun, Aug 22, 2021 at 2:31 PM Aivar Annamaa wrote:
> > 
> > > Is here someone, who can meet me in Tartu, Estonia or is willing to
> > > arrange this over the internet? Perhaps I could sign a statement about
> > > my identity with Estonian ID card?
> > 
> > I checked the list of lists of Debian locations and there are no
> > Debian members that list their location as Estonia. It generally isn't
> > accepted to sign keys over the internet or other electronic means.
> 
> Disagree. Why would that be the case?
> 
> By signing an OpenPGP key you certify that you are sufficiently
> convinced that the key's holder is who they say they are, and that they
> control their key. The easiest way to do that is to meet someone in
> person, but that doesn't mean it's the *only* possible way.
> 
> Am I missing something?

You need to make sure to avoid man-in-the-middle concerns.

Samuel

Re: Looking for Estonian DD-s

[Nilesh Patra]

Hi Wouter,

On 8/25/21 8:36 PM, Wouter Verhelst wrote:
> On Mon, Aug 23, 2021 at 04:12:43AM +, Paul Wise wrote:
>> On Sun, Aug 22, 2021 at 2:31 PM Aivar Annamaa wrote:
>>
>>> Is here someone, who can meet me in Tartu, Estonia or is willing to
>>> arrange this over the internet? Perhaps I could sign a statement about
>>> my identity with Estonian ID card?
>>
>> I checked the list of lists of Debian locations and there are no
>> Debian members that list their location as Estonia. It generally isn't
>> accepted to sign keys over the internet or other electronic means.
> 
> Disagree. Why would that be the case?
> 
> By signing an OpenPGP key you certify that you are sufficiently
> convinced that the key's holder is who they say they are, and that they
> control their key. The easiest way to do that is to meet someone in
> person, but that doesn't mean it's the *only* possible way.

That is correct, but it varies from Developer to deveoper. Some folks would 
agree here,
while others would not want to sign keys w/o meeting in-person - this is on 
coherence with the long-ish
discussion on -project discussion, which you can find here[1] regarding 
keysigning in times of COVID.
 
That said,
Key Endorsements solve this situation to a large extent[2] if not completely.

[1]: https://lists.debian.org/debian-project/2020/08/msg0.html
[2]: https://lists.debian.org/debian-devel-announce/2020/11/msg3.html



OpenPGP_signature
Description: OpenPGP digital signature

Re: merged /usr vs. symlink farms

[Wouter Verhelst]

On Mon, Aug 23, 2021 at 08:23:50AM -0700, Russ Allbery wrote:
> Luca Boccassi  writes:
> 
> > Thank you - it has been brought up in this thread as an example of a
> > valid setup, so if it is not, I think it could be good to be extra clear
> > in the policy? How about the following:
> 
> If we tried to document every random bit of buggy packaging behavior
> anyone thought of in Policy, Policy would become unwieldy, so I want to
> verify here that someone really thought having one package containing a
> file in /bin and another package containing the same file in /usr/bin was
> was a reasonable thing to do (as opposed to accidental).  Are there
> packages in the archive like this?  Or could you point me at the message
> in the thread that said this was non-buggy?  I think I missed it.

The problem here is also that if there are two packages like that, on an
usrmerge system, we would not know this is happening.

Let's say there's a package "foo" which installs /usr/bin/foo, and an
package "binfoo" which installs "/bin/foo". In the current situation,
dpkg would not know that the two files are equivalent, and would happily
overwrite /usr/bin/foo with /bin/foo if "binfoo" was installed after
"foo".

Then when the user notices the "foo" program is not doing what they
believe it should be doing and runs "reportbug /usr/bin/foo", reportbug
will file the bug against the package "foo" rather than the package
"binfoo" which is the actual package whose binary they are trying to
use.

In contrast, if foo and binfoo both install "/bin/foo" (or both install
"/usr/bin/foo", either way works), then dpkg will complain at
installation time that one of the two packages tries to overwrite a file
from the other and refuse to continue.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: Debian choice of upstream tarballs for packaging

[Phil Morrell]

On Wed, Aug 25, 2021 at 04:35:51PM +0200, Simon Richter wrote:
> > I wrote this many times, but I don't see why we should use any "upstream
> > tarball" when the Git repository itself contains the tarball with:
> 
> > git archive --prefix=$(DEBPKGNAME)-$(VERSION)/ $(GIT_TAG) \
> > | xz >../$(DEBPKGNAME)_$(VERSION).orig.tar.xz
> 
> "git archive" is reproducible, for simplicity I wouldn't use a prefix
> though.

For simplicity I *would* use a prefix, purely because that's what
github/gitlab uses, so upstream can still choose to additionally sign
the distributed tarball if they wish.

name=CorsixTH-0.61-beta1 # don't ask me why there's no v, it's just what 
GitHub does
git archive --prefix=$name/ -o ../$name.tar.gz v0.61-beta1
gpg --armor --detach-sign ../$name.tar.gz

https://github.com/CorsixTH/CorsixTH/issues/1271#issuecomment-344882419


signature.asc
Description: PGP signature

Re: merged /usr vs. symlink farms

[Russ Allbery]

Wouter Verhelst  writes:
> On Mon, Aug 23, 2021 at 08:23:50AM -0700, Russ Allbery wrote:

>> If we tried to document every random bit of buggy packaging behavior
>> anyone thought of in Policy, Policy would become unwieldy, so I want to
>> verify here that someone really thought having one package containing a
>> file in /bin and another package containing the same file in /usr/bin
>> was was a reasonable thing to do (as opposed to accidental).  Are there
>> packages in the archive like this?  Or could you point me at the
>> message in the thread that said this was non-buggy?  I think I missed
>> it.

> The problem here is also that if there are two packages like that, on an
> usrmerge system, we would not know this is happening.

I agree, of course, but I don't see a way in which Policy can help with
that problem unless this packaging decision was intentional and the person
who made that decision would have chosen otherwise if Policy had said to
not do it.

This seems more like an appropriate check for an archive-wide QA tool
looking for cross-package problems.

(That said, the molly-guard example does seem to indicate that at least
one packager in the past did not realize this would be a problem.)

-- 
Russ Allbery (r...@debian.org)  

Re: Debian choice of upstream tarballs for packaging

[Thomas Goirand]

On 8/25/21 5:01 PM, Theodore Ts'o wrote:
> On Wed, Aug 25, 2021 at 04:11:37PM +0200, Thomas Goirand wrote:
>>
>> It's been *years* since I encounter a PyPi package that doesn't have a
>> Git repo as its homepage (and unfortunately, 99% on Github).
>>
>> I wrote this many times, but I don't see why we should use any "upstream
>> tarball" when the Git repository itself contains the tarball with:
>>
>> git archive --prefix=$(DEBPKGNAME)-$(VERSION)/ $(GIT_TAG) \
>>  | xz >../$(DEBPKGNAME)_$(VERSION).orig.tar.xz
>>
>> (which leads to a .xz, which is nicer)
> 
> Well, if we don't use an "upstream tarball", we do need to keep our
> own private archive the Git repository.  After all, there is no
> guaranteee that the upstream git repo might disappear in the future.

What I was saying is that you don't need to use the Github generated
tarballs, because likely they are also generated with git-archive, so
doing it yourself achieves the same thing. You do not need to even keep
the upstream branch, the only thing you need is to push the Git tags
from upstream (which by itself contains the whole thing...).

> Simon's proposal that use use a tarball of the bare git repo
> containing all of the git objects needed leading up to the signed tag
> works, but isn't necessarily the most efficient over time, since we
> would be keeping multiple copies of redundant git repos in
> snapshots.debian.org, or across multiple Debian versions in our ftp
> archives.  But it at least guarantees if we will continue to have
> access to the source even if the upstream git repo goes *poof*.

If pushing the upstream git tags to Salsa, you're safe, and the way we
do in the OpenStack team, we still generate and upload tarballs to the
Debian archive matching each tags.

>> Not only then, only only has to merge the upstream tag in the Debian
>> branch to get the new release, but on top, no need to "gbp import" or
>> "pristine-tar commit", and a single packaging branch becomes enough.
>>
>> I very much wish this packaging workflow gained more traction, and the
>> pristine-tar abomination dies...
> 
> Sure, but it implies that the git repos on salsa and/or dgit have to
> become our official source of record for the purposes of GPL
> compliance.  Which means we need to be a lot more careful about ever
> allowing those git trees from being deleted or rewritten, even if the
> goal is to remove files that might be found to be problematic
> copyright licensing perspective.
> 
>   - Ted

That's the thing with git: anyone working on the repository will hold a
local copy, which can act as a backup... :)

Thomas Goirand (zigo)

Bug#992965: ITP: gn -- meta-build system that generates build files for Ninja

[Romain Porte]

Package: wnpp
Severity: wishlist
Owner: Romain Porte 
X-Debbugs-Cc: debian-devel@lists.debian.org, deb...@microjoe.org, Debian 
Chromium Team 

* Package name: gn
  Version : 0+git20210811
  Upstream Author : Google
* URL : https://gn.googlesource.com/gn/
* License : BSD-3-Clause
  Programming Lang: Python
  Description : meta-build system that generates build files for Ninja

This package is introduced as a dependency for some Google software
related to Chromium. It can also replace the `gn` copy currently
embedded in the Chromium source package.

I intent to publish this package under the umbrella of the Debian
Chromium team.

Bug#992965: ITP: gn -- meta-build system that generates build files for Ninja

[Boyuan Yang]

X-Debbugs-Cc: debian-devel@lists.debian.org chrom...@packages.debian.org

在 2021-08-25星期三的 19:12 +0200，Romain Porte写道：
> Package: wnpp
> Severity: wishlist
> Owner: Romain Porte 
> X-Debbugs-Cc: debian-devel@lists.debian.org, deb...@microjoe.org, Debian
> Chromium Team 
> 
> * Package name    : gn
>   Version : 0+git20210811
>   Upstream Author : Google
> * URL : https://gn.googlesource.com/gn/
> * License : BSD-3-Clause
>   Programming Lang: Python
>   Description : meta-build system that generates build files for Ninja
> 
> This package is introduced as a dependency for some Google software
> related to Chromium. It can also replace the `gn` copy currently
> embedded in the Chromium source package.
> 
> I intent to publish this package under the umbrella of the Debian
> Chromium team.

https://tracker.debian.org/pkg/generate-ninja

Thanks,
Boyuan Yang


signature.asc
Description: This is a digitally signed message part

Re: merged /usr vs. symlink farms

[Guillem Jover]

On Wed, 2021-08-25 at 09:57:09 -0700, Russ Allbery wrote:
> Wouter Verhelst  writes:
> > The problem here is also that if there are two packages like that, on an
> > usrmerge system, we would not know this is happening.

Also this does not need to come from "buggy" packaging practices.

> I agree, of course, but I don't see a way in which Policy can help with
> that problem unless this packaging decision was intentional and the person
> who made that decision would have chosen otherwise if Policy had said to
> not do it.

> This seems more like an appropriate check for an archive-wide QA tool
> looking for cross-package problems.

I've said this many times over the months (years!?), that while this
can easily affect stuff from the archive, which we do control, where
policy applies and where we could try to poorly reimplement the checks
that dpkg does to detect them in some QA checker, even though the
following problems would still apply:

  - the checks cannot be performed (only) over static snapshots of
the archive, as this would affect partial upgrades too,
  - the checks would need to take into account packages we have
stopped shipping way in the past as those can linger around
installed,
  - the checks would have a hard time with the non-declarative side
of the packaging stack,

is that something else I expect to have a non-zero chance to bite users
are all those common practices that people give for granted and that we
have supposedly supported in the past, as guaranteed by our packaging
system, such as:

  - keeping installed packages that have stopped shipping in Debian,
  - installation of packages from third-parties, or from local
overlays or similar, or even rebuilt forks of packages from Debian,
  - installation or holding of Debian packages from older releases,
  - local diversions or alternatives,

which are out of our QA reach.


The fact that the supporters of a *filesystem layout* have been happy
to dismiss and ignore this and have been pushing for what I think can
be easily described as the worst ever "transition" done in Debian, very
sadly, for me this whole topic marks a before and after in Debian, and
has put my trust in the technical side of the project into question.

Of course some of those supporters are now agreeing these problems can
be insidious, progress I guess. And at the same time others are claiming
that acknowledging those problems would hold back the entire distribution,
while others are now saying we should stop doing packaging changes because,
well, these problems perhaps are potentially problematic, the irony.

And then we get people raving over what's the worst and most atrocious
hacks to pile on into dpkg to try to workaround the actual root cause
(turtles^Wnasty hacks and kludges all the way down I guess). Which I
obviously expect to eventually be coerced into merging into dpkg at
some point or another via our esteemed Authority.

From where I'm sitting Debian is the project that lost its way…

Sadly,
Guillem

Re: Debhelper and /lib/systemd vs /usr/lib/systemd

[Niels Thykier]

Sam Hartman:
> 
> TL;DR: Should we hold off on moving stuff from / to /usr in packages
> until we develop our plan?
> If so, how do we communicate that to people?
> 
>> "Russ" == Russ Allbery  writes:
> 
> Russ> Simon Richter  writes:
> >> It is less nonsensical because usrmerge exists, since we
> >> presumably don't want to keep the /bin paths in the packages, so
> >> at some point we need to move /bin/foo to /usr/bin/foo inside a
> >> package.  That is safe with current dpkg, as dpkg will not delete
> >> /bin/foo if it has the same inode as a just-unpacked file.
> 
> Russ> [...]
> 
> Russ> I think this implies that writing something in Policy about
> Russ> this would be premature.  The issues you raise are related to
> Russ> something new that is being discussed and would be part of a
> Russ> migration plan to a merged /usr world.
> 
> Russ, I agree with you that it's premature to document this in policy.
> 
> However, Simon has raised what I think is a credible argument that it
> is harmful to perform both / -> /usr transitions and to move files
> between packages in the same release.
> My take away from that is that it may be harmful to move a bunch of
> stuff from / -> /usr until we have a plan, and that maintainers should
> actively be discouraged from doing so.
> 
> I think we should get people to hold off at least until we have a
> consensus on that point.
> 
> And this is by no means theoretical.
> 
> As was discussed here, recent debhelper (has or at least had) changed
> from installing systemd units in /lib/systemd/system to
> /usr/lib/systemd/system.
> 
> That is totally fine interms of  usermerged stuff, but sets up a
> potential problem .
> 
> Suppose we have a program foo that ships a daemon and also a systemd
> unit to run it.
> 
> Later we discover that foo is kind of useful in desktop situations and
> other situations where it wants to be started as needed  and possibly
> not even by systemd.
> So, we want to split out the foo package into foo containing the daemon
> binary and foo-system (recommended by foo) containing the systemd unit.
> 
> The maintainer may not even be thinking about how debhelper moved around
> the unit file.
> 
> foo-system  replaces/breaks the old version of foo.
> 
> I think the following series of operations would result in the unit file
> disappearing on a usermerged system:
> 
> * user has  old foo with /lib/systemd/system/foo.service
> 

As I understand it, the issue does not depend on whether "usrmerge" is
run before or after installing the "/lib" version of "foo".  On that
assumption, running "usrmerge" as a part of the upgrade and "cleaning
up" in bookworm+1 is liable to exactly the same risk as before.

Which means that we are likely "just" debating on when we want to risk
to occur. The difference for me being that people would forgot about
this issue in bookworm+1 and assume that migration is over with no risk
left.

On that front, I prefer to take my chances with breaking bookworm while
it is fresh in our minds rather than breaking bookworm+1 when every body
forgot about it.

That said ...

> * user attempts to upgrade and installs foo-system as part of upgrade
> 
> * foo is deconfigured because of the breaks on foo-system
> 
> * foo-system is unpacked, including
>   /usr/lib/systemd/system/foo.service.  On the usrmerged system, that
>   overwrites the existing foo.service since dpkg doesn't know about the
>   aliasing
> 
> * foo is upgraded.  From dpkg's standpoint it looks like
>   /lib/systemd/system/foo.service disappeared, but since the file still
>   exists it is removed.
> 
> So the user ends up with no unit.
> 
> I think this is particular insidious because the maintainer might not
> even know that they had moved files from / to /usr, or if they knew they
> might have not been paying enough attention to provide special care.
> 
> Do people agree that we want to hold off on this sort of thing until we
> get a plan?
> 

This strongly depends on:

 * Who volunteered to be the "we" that provide this plan?
 * When is "until" we have a defined plan?

For concrete values of those definitions, I can be convinced to stop
further changes and rollback the systemd / -> /usr change.  However, as
long as these definitions are variations of "somebody" or "everyone" or
"the project" and "eventually" or "when it is ready", then I am not
convinced that waiting is the right option.

For now, I will hold on further "/ -> /usr" changes in debhelper, but I
am not convinced that I should actively rollback the changes already made.

Thanks,
~Niels

PS: Guesstimates suggests that there 16.5 months until the transition
freeze assuming the release team keeps the current cadence.

Re: Debian choice of upstream tarballs for packaging

[Simon Richter]

Hi,

On 25.08.21 18:42, Phil Morrell wrote:


"git archive" is reproducible, for simplicity I wouldn't use a prefix
though.



For simplicity I *would* use a prefix, purely because that's what
github/gitlab uses, so upstream can still choose to additionally sign
the distributed tarball if they wish.



 name=CorsixTH-0.61-beta1 # don't ask me why there's no v, it's just what 
GitHub does


This comment is precisely what I mean with "simplicity."

   Simon



OpenPGP_signature
Description: OpenPGP digital signature

Re: merged /usr vs. symlink farms

[Aurelien Jarno]

On 2021-08-20 23:15, Simon Richter wrote:
> I think that one of the release goals should be that any freshly installed
> or upgraded system should have a dpkg database that is consistent with
> reality, and I'd prioritize that higher than actually finishing the
> transition, because as long as we can have files vanish from under us, we
> can't expect that the transition will be reliable for bullseye->bookworm
> updates.
> 
> Basically, we've been lucky so far.

I am not sure we have been so lucky. Problems have been found during the
release cycles, some of them got fixed (#953562), some other are still
there (#926699).

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Re: merged /usr vs. symlink farms

[Wouter Verhelst]

On Wed, Aug 25, 2021 at 09:57:09AM -0700, Russ Allbery wrote:
> Wouter Verhelst  writes:
> > On Mon, Aug 23, 2021 at 08:23:50AM -0700, Russ Allbery wrote:
> 
> >> If we tried to document every random bit of buggy packaging behavior
> >> anyone thought of in Policy, Policy would become unwieldy, so I want to
> >> verify here that someone really thought having one package containing a
> >> file in /bin and another package containing the same file in /usr/bin
> >> was was a reasonable thing to do (as opposed to accidental).  Are there
> >> packages in the archive like this?  Or could you point me at the
> >> message in the thread that said this was non-buggy?  I think I missed
> >> it.
> 
> > The problem here is also that if there are two packages like that, on an
> > usrmerge system, we would not know this is happening.
> 
> I agree, of course, but I don't see a way in which Policy can help with
> that problem unless this packaging decision was intentional and the person
> who made that decision would have chosen otherwise if Policy had said to
> not do it.
>
> This seems more like an appropriate check for an archive-wide QA tool
> looking for cross-package problems.

Indeed, and that was the point I was trying to make: it's not something
Policy can help with, unless it is intentional (and it is my belief that
this is not likely to be the case).

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: merged /usr vs. symlink farms

[Simon Richter]

Hi,

On 25.08.21 18:57, Russ Allbery wrote:


The problem here is also that if there are two packages like that, on an
usrmerge system, we would not know this is happening.



I agree, of course, but I don't see a way in which Policy can help with
that problem unless this packaging decision was intentional and the person
who made that decision would have chosen otherwise if Policy had said to
not do it.


I'd expand the definition of Conflicts/Replaces though: packages that 
use names that conflict because of usrmerge would need to declare it, 
because as soon as we teach dpkg to recognize these conflicts, the 
packages would fail to install on stable.



This seems more like an appropriate check for an archive-wide QA tool
looking for cross-package problems.


We have a tool that looks for missing Conflicts/Replaces, and that tool 
needs to be extended as well.


   Simon

Re: Debhelper and /lib/systemd vs /usr/lib/systemd

[Sam Hartman]

> "Niels" == Niels Thykier  writes:

Niels> As I understand it, the issue does not depend on whether
Niels> "usrmerge" is run before or after installing the "/lib"
Niels> version of "foo".  On that assumption, running "usrmerge" as
Niels> a part of the upgrade and "cleaning up" in bookworm+1 is
Niels> liable to exactly the same risk as before.

I don't think so.
My assumption is that we will eventually  produce a dpkg that handles
this situation better.
I think that every time we move files from / to /usr inside a package
before that new dpkg is introduced,
we increase our risk.
So my hope is that debhelper and maintainers refrain from moving files
from / to /usr prior to  being able to depend on an as yet unwritten
 dpkg.

I think that if debhelper moves systemd units and later a maintainer
moves units between packages, we can run into trouble with today's
dpkg.  So we could potentially run into trouble as soon as someone
installs such a package from testing onto a bullseye system.

If debhelper were to hold off until after a fixed dpkg exists and we can
guarantee it is available,
I think that we avoid the risk of files disappearing.
So, based on my understanding, I think the risk is worse today than it
would be if we rolled back the debhelper change.


Put another way.
You can choose any two of:

1) alias things outside of dpkg I.E. usrmerge moves files and creates
symlinks

2) Move files inside a package within the knowledge of dpkg

3) move files between packages.

If you choose all 3, files may disappear depending on upgrade ordering.
We've already chosen 1 with the buster debootstrap change.
We often choose 3 as part of regular package reorganization.
I think we should not choose 2.


It's possible I'm missing something .
If so, I'd appreciate help understanding what it is.

 This strongly depends on:

>  * Who volunteered to be the
> "we" that provide this plan?
>  * When is "until" we have a
> defined plan?

So, I think that the discussions here have been converging on things
that  would work.
I'm happy to volunteer to assist in trying to find what consensus there
is if that helps.

The discussion here has convinced me at least that actually
canonicalizing paths (making the path inside the package match reality)
is not a safe thing to do until dpkg is changed.
I do think we could force usrmerge (or something similar) to be
installed without changing dpkg.

The dpkg maintainer hasn't been happy with the discussions here, and I
think facilitating to a level where Guillem is part of the consensus is
beyond my skill.

So I don't actually know how to get to something actionable.  I do
believe the chance of breakage if we move around paths inside packages
is high enough that we should block path canonicalization on a dpkg that
can handle that, even if that takes a long time.


signature.asc
Description: PGP signature

Re: merged /usr vs. symlink farms

[Russ Allbery]

Simon Richter  writes:

> I'd expand the definition of Conflicts/Replaces though: packages that
> use names that conflict because of usrmerge would need to declare it,
> because as soon as we teach dpkg to recognize these conflicts, the
> packages would fail to install on stable.

Yes, that's probably the most appropriate place to make a change to Policy
to clarify this.

-- 
Russ Allbery (r...@debian.org)  

Re: merged /usr vs. symlink farms

[Russ Allbery]

Guillem Jover  writes:

> The fact that the supporters of a *filesystem layout* have been happy to
> dismiss and ignore this and have been pushing for what I think can be
> easily described as the worst ever "transition" done in Debian, very
> sadly, for me this whole topic marks a before and after in Debian, and
> has put my trust in the technical side of the project into question.

I agree that you've been pointing out potential problems for years and
that your warnings have been at least partly vindicated by the problems we
are indeed seeing.

My understanding (which may be entirely incorrect, in which case please
let me know what your preferred solution actually is!) is that your
preferred solution was to migrate individual packages.  What I'm hearing
from the frequent threads in debian-devel is that a sufficient number of
Debian contributors have rejected that approach (for various reasons) as
to make that solution not viable.  In other words, my reading of the
consensus is that this option has effectively been vetoed by the rest of
the project (noting that this veto was certainly not unanimous).

Please note that I'm not taking a position on the merits of that decision,
simply noting that, based on my reading of debian-devel, this is has what
has happened, and I do not believe it will be possible at this point to
convince the project as a whole to unwind usrmerge and go back to doing
individual package migrations.

Given that as a design constraint (we will not be doing this transition
via one-by-one changes to each package), what would you support as a good
architectural solution to this transition?  Even ruling out that approach,
the design space seems large and flexible; surely there must be some
coherent way of doing this transition that does not require individual
action for each affected package and preserves some of the "be done with
it" design goals of the current usrmerge approach while avoiding the
problems you have pointed out.

I think it's obvious that any such design will require support from dpkg.

You're very understandably upset that people are insisting on a solution
that you feel is clearly incorrect, but I think that's also how the people
who are disagreeing with you are feeling, and as long as that's true on
both sides it's hard to see how we're going to arrive at a solution that
isn't going to make you even more unhappy.  In order to break this
deadlock, I think we have to have a design discussion in the shared space
of mutually agreeable solutions and not (on all sides) retreat back to a
single preferred architectural decision and only point out the problems
with any other approach.

-- 
Russ Allbery (r...@debian.org)  

Re: Debhelper and /lib/systemd vs /usr/lib/systemd

[Simon Richter]

Hi,

On 25.08.21 21:45, Sam Hartman wrote:


The dpkg maintainer hasn't been happy with the discussions here, and
I think facilitating to a level where Guillem is part of the
consensus is beyond my skill.


The discussion so far has been around the question whether there is
actually a problem and whether it is actually required for the dpkg
database to be consistent with the file system. It is unsurprising that
the dpkg maintainer has an opinion about that.

So I don't actually know how to get to something actionable.  I do 
believe the chance of breakage if we move around paths inside

packages is high enough that we should block path canonicalization on
a dpkg that can handle that, even if that takes a long time.


We have a few half-baked solution proposals.

Combining the parts from Ted Ts'o (for usrmerged systems) and mine (for
not-yet usrmerged systems) would be the complex and generic approach.

I think I've also seen some ideas along the lines of "have the usrmerge
package patch the dpkg database", which would be simpler.

Would it make sense to start a wiki page?

   Simon

Re: Debhelper and /lib/systemd vs /usr/lib/systemd

[Niels Thykier]

Sam Hartman:
>> "Niels" == Niels Thykier  writes:
> 
> Niels> As I understand it, the issue does not depend on whether
> Niels> "usrmerge" is run before or after installing the "/lib"
> Niels> version of "foo".  On that assumption, running "usrmerge" as
> Niels> a part of the upgrade and "cleaning up" in bookworm+1 is
> Niels> liable to exactly the same risk as before.
> 
> I don't think so.
> My assumption is that we will eventually  produce a dpkg that handles
> this situation better.

I can appreciate the allure of assuming that "a fixed dpkg" appears and
solves the entire problem.  It would certainly make all the problem go
away *if* it appears.

I am not ready to believe in that dpkg as a solution to the bookworm
release because the dpkg development flow has never been "fast" due to a
strong focus on "a generic solution that gets it right in every case" -
and I expect it to be even slower than usually given how demotivated
Guillem feels and the complexity involved in such a change to dpkg.

And until the "fixed" dpkg materializes, every package shipping
something has to keep files in /lib - even if that is a decade after the
bookworm release - or risk breaking if they later need to split the
package in the same release cycle.
  To me, that sounds like we will drag the transition on "until the
fixed dpkg comes along" no matter how long it takes.  Finishing the
transition is a key element for me in the transition.

> [...]
> So my hope is that debhelper and maintainers refrain from moving files
> from / to /usr prior to  being able to depend on an as yet unwritten
>  dpkg.
> 

For me, this reads as "until = eventually", which I stated I would find
unconvincing.

For the record, I did not immediately expect a better answer which is
also why I am waiting with moving forward in case a better answer
materializes "soon".

> I think that if debhelper moves systemd units and later a maintainer
> moves units between packages, we can run into trouble with today's
> dpkg.  So we could potentially run into trouble as soon as someone
> installs such a package from testing onto a bullseye system.
> 
> If debhelper were to hold off until after a fixed dpkg exists and we can
> guarantee it is available,
> I think that we avoid the risk of files disappearing.
> So, based on my understanding, I think the risk is worse today than it
> would be if we rolled back the debhelper change.
> 
> 
> [...]
> 
> 
> It's possible I'm missing something .
> If so, I'd appreciate help understanding what it is.
> 

On the assumption that a "fixed" dpkg will appear in bookworm, I would
agree with you.  However, I do not believe in that assumption/timeline -
to explain why I believe we fundamentally disagree on the priority/solution.


>  This strongly depends on:
> 
>>  * Who volunteered to be the
>> "we" that provide this plan?
>>  * When is "until" we have a
>> defined plan?
> 
> So, I think that the discussions here have been converging on things
> that  would work.
> I'm happy to volunteer to assist in trying to find what consensus there
> is if that helps.
> 

I appreciate you volunteering to a part of it.  My interest in a
detailed transition plan with a fixed end date where we are *done* with
the "clean up" no later than bookworm+1.  I do not see that directly in
these discussions - but certainly, a consensus is probably the first
step there.  Maybe the consensus will motivate someone to volunteer to
create the plan.

(Side-note my desired timeline implies that a "fixed" dpkg lands in
bookworm.)

> [...]
> 
> So I don't actually know how to get to something actionable.  I do
> believe the chance of breakage if we move around paths inside packages
> is high enough that we should block path canonicalization on a dpkg that
> can handle that, even if that takes a long time.
> 

I would strongly prefer a timely actionable transition plan that does
not involve assuming a "fixed" dpkg will show up and magically fix
everything when the volunteer working dpkg is strongly demotivated by
this transition.  In the absence of such a transition plan ...

If the project consensus of this discussion is aligned with the belief
that we should block decentralized volunteer work on the transition, I
will respect the decision.

~Niels

Re: Debhelper and /lib/systemd vs /usr/lib/systemd

[Niels Thykier]

Simon Richter:
> Hi,
> 
> On 25.08.21 21:45, Sam Hartman wrote:
> 
>> The dpkg maintainer hasn't been happy with the discussions here, and
>> I think facilitating to a level where Guillem is part of the
>> consensus is beyond my skill.
> 
> The discussion so far has been around the question whether there is
> actually a problem and whether it is actually required for the dpkg
> database to be consistent with the file system. It is unsurprising that
> the dpkg maintainer has an opinion about that.
> 
>> So I don't actually know how to get to something actionable.  I do
>> believe the chance of breakage if we move around paths inside
>> packages is high enough that we should block path canonicalization on
>> a dpkg that can handle that, even if that takes a long time.
> 
> We have a few half-baked solution proposals.
> 
> Combining the parts from Ted Ts'o (for usrmerged systems) and mine (for
> not-yet usrmerged systems) would be the complex and generic approach.
> 
> I think I've also seen some ideas along the lines of "have the usrmerge
> package patch the dpkg database", which would be simpler.
> 
> Would it make sense to start a wiki page?
> 
>    Simon
> 

As I understand it, the "have usrmerge package patch the dpkg database"
approach will only work if we ensure that each and every package stop
using / in bookworm+1.  Else we are back to the same problem that Sam
listed with package splits (just with the paths inverted).

That is, a solution based on that plan should also involve a plan for
getting each and every package affected by the usrmerge updated in
bookworm+1.

Thanks,
~Niels

Bug#992967: ITP: erlang-poolboy -- Erlang worker pool factory

[James Valleroy]

Package: wnpp
Severity: wishlist
Owner: James Valleroy 
X-Debbugs-Cc: debian-devel@lists.debian.org, jvalle...@mailbox.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: erlang-poolboy
  Version : 1.5.2
  Upstream Author : Devin Torres 
* URL : https://github.com/devinus/poolboy
* License : Unlicense or ISC
  Programming Lang: Erlang
  Description : Erlang worker pool factory

A lightweight, generic pooling library for Erlang with a focus on
simplicity, performance, and rock-solid disaster recovery.

This is a dependency of pleroma (#895050). It will be maintained in
the Erlang team.

-BEGIN PGP SIGNATURE-

iQJKBAEBCgA0FiEEfWrbdQ+RCFWJSEvmd8DHXntlCAgFAmEmgIEWHGp2YWxsZXJv
eUBtYWlsYm94Lm9yZwAKCRB3wMdee2UICAHND/9D1dMaRJR2CfQaOpGDs/5YkJc4
0gOCRNlRBazA9qQaZmV8XZ1WeF8xcQInTEYJgCRq4sy1+h5rKmZxXlbN+W92KF3H
5EAqhlGb1OiF1R7G8khU6hxlMs0vzhYsk7ZXI+l8KUzuyGhlgYGKUoPA+ww6dEum
Mh+8emz5ShLGzAz9sxseKYlLtGLp1wSjf84ZoaxqfJo8dia/6skrz3mIDi63/M6C
W3tOABB9Hm4QzHWdr3bELNq2HBDuYwVGoQPUWRlcC2nXLjWXm4+MKMJljkNdfBgV
YHyyYauLsAWHrpFi0+33mIN6YFCavEWY/Dikh0dpntv4cPCjtcBg7hdxa3MXBFLg
AsA7wmS7q+UGrMjG3roBsDd1PueGbd+IDEPPEZLZztq/bXn0VbIPw4LIltLE0vYo
1tNw1MC4a8VAsZ/TqbKTTsEBH6BuRIb+8Amq3Xxu0i7xOzSK36aUlKIl3WMHevul
iU+Yw0Mnebffcke+KeFvkgwW48x0/n4ZNNb/Dwe21f/IPFFWXHfnFnj+RZ4xSt+e
eQo5HCZNNJgnfuIWvkCqI1lAQE8esnfQ/KQ8B8BAw3IMWbsdUvpj8bNqksbAJNUC
5qxQMu6EptLvMsKjA4R4oQszTQV92wXaUefKiMpvuQTw4VdT3PqbZF7h3Vph/wK6
l/WmQCXytrTbC+iasg==
=iEOn
-END PGP SIGNATURE-

Re: Debian choice of upstream tarballs for packaging

[Sam Hartman]

> "Simon" == Simon Richter  writes:

Simon> Hi,
Simon> On 8/16/21 3:18 AM, Paul Wise wrote:

>> I'd like to suggest that we standardise on the upstream VCS for
>> our orig.tar.gz files and phase out use of upstream packaging
>> ecosystems.

Simon> This is also an additional burden on package maintainers:
Simon> explaining how they arrived at that particular "upstream"
Simon> package in a reproducible way, and why what we ship as "orig"
Simon> is different from upstream, and what the copyright and
Simon> licensing situation for that derived work is.

Simon> Upstream projects have gotten a lot sloppier in how they cut
Simon> releases, that is true, and that is making packaging more
Simon> difficult as we need to disable mechanisms and embedded code
Simon> copies that were included for our "convenience."

Simon> Rather than accept defeat,

I don't think it's accepting defeat to use an upstream vcs.
I think it's just better.
IT's closer to the development workflow I'd use to work on the upstream.
AS a maintainer, it makes it easier for me to forward or back port
patches.
It makes it easier for me to contribute upstream.

I acknowledge your concern about needing to justify why I picked a
particular git tag.

By this point I kind of think source tarballs are an anti-pattern.

I do agree with you that Debian should work with upstreams to understand
our needs and to produce high quality releases.
At least for me though, that's unrelated to this issue.
In my world high quality source releases are signed git tags not
tarballs.
I'd like Debian to embrace my world:-)


signature.asc
Description: PGP signature

Bug#992992: ITP: python-spinners -- spinners library of terminal for python3

[Nobuhiro Iwamatsu]

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: python-spinners
  Version : 0.0~git20200220.a73d561
  Upstream Author : Manraj Singh 
* URL : https://github.com/manrajgrover/py-spinners
* License : Expat
  Programming Lang: Python
  Description : spinners library of terminal for python3

  More than 60 spinners libraries for terminal, this is python port of
  amazing node library cli-spinners 
(https://github.com/sindresorhus/cli-spinners).

Re: merged /usr vs. symlink farms

[Guillem Jover]

Hi!

On Sun, 2021-08-22 at 09:18:25 +0200, Andreas Metzler wrote:
> Afaict we have still no idea on how to move on.
> 
> 1 I think you agree that there is a significant number of usrmerged Debian
>   installations out there. It does not really matter whether there are 7% or
>   40%. They exist and should (keep) working.

By my definition, these have never been working correctly, but
semantics I guess. My wish would be to indeed salvage those systems,
that's why I implemented dpkg-fsys-usrunmess. But if people refuse,
then at some point I'd personally consider them lost, TBH. :/

> 2 As you have stated there are known issues with dpkg and usrmerged
>   systems. Some of them are are triggered by moving files from / to /usr.
> 
> Starting from here it is hard to see a way forward.

Well, in my mind the first and most immediate action that would be
done, is to stop the bleeding, by:

  - reverting the changes in deboostrap in sid, bullseye (and ideally
in buster too),
  - reverting the notion that split-/usr is unsupported (which includes
the extremely confusing interpretation about this applying to
sid/testing too), and update documentation such as release-notes,
etc.,
  - adding a Conflicts against usrmerge somewhere (dpkg, base-files or
similar) for extra caution,
  - (optionally) removing usrmerge from buster, bullseye and sid,

I'd be ready to prepare patches or file reports for any of these.

But then, my expectations regarding Debian have plummeted so…

> Is it a realistic option to require something like
> -
> dpkg --purge usrmerge
> dpkg-fsys-usrunmess
> -
> pre dist-upgrade to bookworm to get back all systems to a sane (from
> dpkg POV) state and start fresh?

If by requiring you mean documenting the requirement, then I don't
think that would be enough.

But I could see introducing a preinst somewhere (perhaps base-files,
to permit upgrading dpkg itself) which would check for those unsupported
systems and emit a big fat message explaining the situation and
instructions to follow to be able to proceed, then abort. Similar in vein
with how other preventions (AFAIR) have been implemented for example on
glibc or udev for environment, multi-arch or kernel requirements.

Sadly, even introducing that into bullseye would not guarantee that the
bookworm upgrade would already be in a sane state, as there's no
guarantee people do not skip point releases. But I assume it would cover
most of the installations. So the problem would be greatly minimized.
Only after the bookworm upgrade has been completed this would be
guaranteed.

> Is this robust (except for crash as stated in the manpage), or would
> you consider it beta-quality?

There's a known problematic interaction with a systemd's emergency mode
misbehavior/bug, which I've worked around, plus some other robustness
improvements I've prepared that will be included in 1.21.0, and targeted
for 1.20.10. I should probably also add a temporary policy-rc.d to
batch and defer all service actions for after the mass reconfiguration,
which I'll try to code up soonish to further improve robustness.

Otherwise I've taken great care and consideration on trying to make it
as robust as possible, but I guess out of cautiousness and given the
nature of what the script is doing (which is still a hack, although a
self-contained one at least), I'd be hard pressed to probably ever
declare it 100% safe. :/ Of course more testing is always helpful!

Thanks,
Guillem

Re: Debian choice of upstream tarballs for packaging

[Brian Thompson]

On 0825, Simon Richter wrote:
>Hi,
>
>On 8/25/21 1:21 AM, Sean Whitton wrote:
>
>> From my point of view, signing git tags is no less well established a
>>best practice than signing tarballs -- in fact, to me, it seems *more*
>>well established.
>
>That is ecosystem dependent.
>
>FWIW, I'd love to see git bundles as a source archive format -- this would
>allow shipping a (signed) tag, its commit, and the tree and blob objects for
>that commit as a single file that can be built in a reproducible way and allows
>changes on top to be easily tracked, including the branch point.
>
>In the absence of an "official" upstream release tarball, using this format
>also makes it clear that this is a git snapshot, so no explanation is needed
>how that archive was created.

Ecosystem-dependent or not, I can see being able to verify who uploaded 
the Git tag (or anything for that matter) as being increasingly valuably
in a world where there is a lot of uncaught or ignored plagiarism.
Uploaders and creators should have integrity so that their users can
rely on them and be confident to deliver quality work.

-- 
Best regards,

Brian T


signature.asc
Description: PGP signature

Re: merged /usr vs. symlink farms

[Danilo Santos]

Today's update, Debian test can't read my windows partition. I fix it
inside the bios configuration.

El mié, 25 de ago. de 2021 a la(s) 15:27, Aurelien Jarno (
aurel...@aurel32.net) escribió:

> On 2021-08-20 23:15, Simon Richter wrote:
> > I think that one of the release goals should be that any freshly
> installed
> > or upgraded system should have a dpkg database that is consistent with
> > reality, and I'd prioritize that higher than actually finishing the
> > transition, because as long as we can have files vanish from under us, we
> > can't expect that the transition will be reliable for bullseye->bookworm
> > updates.
> >
> > Basically, we've been lucky so far.
>
> I am not sure we have been so lucky. Problems have been found during the
> release cycles, some of them got fixed (#953562), some other are still
> there (#926699).
>
> --
> Aurelien Jarno  GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://www.aurel32.net
>


-- 
*Grupo Santos Frias S.R.L*
*Danilo Alejandro Santos Frias*
*Cel: (809) 708-7460*

Bug#992999: ITP: unyt -- Python package for handling numpy arrays with units.

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org, 
debian-as...@lists.debian.org, debian-scie...@lists.debian.org

* Package name: unyt
  Version : 2.8.0
  Upstream Author : Nathan Goldbaum
* URL : debian-devel@lists.debian.org
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Pyton package for handling numpy arrays with units.

Often writing code that deals with data that has units can be confusing.
A function might return an array but at least with plain NumPy arrays,
there is no way to easily tell what the units of the data are without
somehow knowing a priori.

The unyt package (pronounced like “unit”) provides a subclass of NumPy’s
ndarray class that knows about units.

It is a new build dependency of the "yt" package. I will maintain it
within the Debian Python team. Salsa dir is

https://salsa.debian.org/python-team/packages/unyt

Best regards

Ole