Bug#994388: dpkg currently warning about merged-usr systems

2022-04-08 Thread Felix Lechner

On Fri, Apr 8, 2022 at 1:48 AM Wouter Verhelst  wrote:
> The nuclear option here is obviously to take maintenance of dpkg away
> from the dpkg maintainer unless and until he decides to follow the
> rules.

This song is for Guillem:


Kind regards,
Felix Lechner

Bug#1007717: Native source package format with non-native version

2022-03-17 Thread Felix Lechner

On Thu, Mar 17, 2022 at 11:57 AM Russ Allbery  wrote:
> source package format

While everyone is receptive to new labels, I prefer "upload format" or
"archive format". Either one helps us to distinguish the intermediate
product from any workflow objects a maintainer may have.

> single tarball as a source package format

It is also not necessary to "define" unpatched sources in the archive
by how many tarballs they have, or any tarballs at all.

In fact, I wrote a manifest utility that could one day replace tarball
signatures with per-file hashes. The latter remain useful even when
sources are repackaged, because manifests can be cryptographically
daisy-chained in a "chain of custody." Of course, they would be more
often used for patched upload formats.

Kind regards
Felix Lechner

Bug#1007717: Native source package format with non-native version

2022-03-16 Thread Felix Lechner

On Tue, Mar 15, 2022 at 9:33 PM Russ Allbery  wrote:
> We should define native and non-native
> packages in terms of version numbers, and allow both native and non-native
> packages to use single-tarball source package formats.

I co-maintaintain several Debian-internal tools, and that description
is backwards. "Native" sources are characterized by their lack of
Debian patches.

On that note, the term "native" is also not great. The words "patched"
and "unpatched" describe the relationship between sources in the
archive and their respective upstreams more accurately.

As for version strings, we need no additional restrictions. The use of
patches is declared in source format 3.0. Some folks even use Debian
revisions for unpatched sources. [1]

Most significantly, Lintian's parser is unable to deduce "nativeness"
from the version number. The native status is a required input! [2]

Please do not "define" a source's patch status via the version string.
It's what got us here in the first place. Debian version numbers are
complicated enough already. Thank you!

Kind regards,
Felix Lechner

[1] for example, https://tracker.debian.org/pkg/python3-defaults

Bug#1007717: Native source package format with non-native version

2022-03-15 Thread Felix Lechner
Hi Ian,

On Tue, Mar 15, 2022 at 11:54 AM Ian Jackson
> I do remember this coming up
> before, but I don't seem to be able to find a record of it now.

Perhaps you were thinking about this discussion in a bug against Lintian?

Ideally I would like dpkg-source to permit source format
`3.0 (native)' packages to have a non-native version number. [1]

Kind regards,
Felix Lechner

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953554#30

Bug#994275: Reverting breaking changes in debianutils

2021-10-17 Thread Felix Lechner

On Mon, Oct 11, 2021 at 1:45 AM Sebastian Ramacher  wrote:
> the lintian tag
> possibly-insecure-handling-of-tmp-files-in-maintainer-script still
> recommend "tempfile or mktemp".

Lintian's last remaining reference to 'tempfile' was dropped. [1] The
updated tag description is now live on our website. [2]

Kind regards
Felix Lechner


Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-27 Thread Felix Lechner

On Tue, Jan 26, 2021 at 5:48 PM Sandro Tosi  wrote:
> the ability to talk privately with the committee is something CTTE has
> allowed for a long time

Debian has many great traditions, but the Magna Carta is much older. I
found a great article about it ([1], p. 5):

"the simple human need for fairness, reflected in western
jurisprudence since at least 1215 when it was pronounced in the Magna
Carta, underlies the legal concerns about ex parte communications
during administrative decisionmaking processes. Fairness certainly
requires an impartial decisionmaker, and often the appearance of
impartiality can become as important a factor in the legal review of
fairness as actual impartiality."

The State of Hawai'i publishes a simpler guidance prohibiting private
communications with a judge. [2]

Kind regards
Felix Lechner

[2] https://www.courts.state.hi.us/self-help/exparte/ex_parte_contact

Bug#978636: move to merged-usr-only?

2021-01-26 Thread Felix Lechner

On Tue, Jan 26, 2021 at 3:45 AM Wouter Verhelst  wrote:
> You can start writing a lintian check today

Here is a Lintian check that follows Ansgar's specification in the
second d-d thead. Of course, it will not be merged until the project
works out a suitable consensus on this controversial topic:


Thank you!

Kind regards
Felix Lechner

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-20 Thread Felix Lechner

Sorry to comment so late. A meeting about this bug may already be in progress.

On Sat, Jan 16, 2021 at 4:15 AM Matthew Vernon  wrote:
> The maintainer won't talk to me, nor will they engage with me (or anyone
> else) on this thread, though they will it seems talk to the TC in private.

In most places, a failure to respond would result in a default
judgment for the aggrieved party—in this case Matthew.

Here, the situation here is more complicated. There was a private
communication with the committee, but such side conversations are
unfair: How can Matthew ever feel that justice was served? I would
personally not feel closure unless I saw all such communications and
had an opportunity to respond.

Secrecy, if it is really needed, should instead be implemented by
requiring all parties involved to keep sealed records confidential.

I urge the committee to please reconsider its willingness to engage
with one party without the other present. The dignity of the Technical
Committee—Debian's highest and most hallowed body—could suffer.

Thank you!

Kind regards
Felix Lechner

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-19 Thread Felix Lechner

On Wed, Nov 18, 2020 at 11:33 PM Josh Triplett  wrote:
> I do not believe it falls within the scope of the technical committee
> to override a decision already decided by a project-wide GR

In the State of California we follow such a strict interpretation of
ballot measures. While consistent with direct democracy, it is also
widely blamed for a dysfunctional state government. [1] But even here,
courts enjoy some leeway.

Please consider Proposition 8. Widely publicized in 2008, it was a
successful ballot initiative that banned same-sex marriage by amending
the state constitution (yes, California can be conservative). A
Federal District Court later ordered the State to ignore the people.
While the appeals failed on narrow grounds, the original opinion that
ended up standing was described as ruling that "the amendment was
unconstitutional under both the Due Process and Equal Protection
Clauses of the Fourteenth Amendment, since it removed rights from a
disfavored class with no rational basis." [2]

In Debian, users of 'sysvinit' strike me as such a "disfavored class".
Personally, I find it outdated and would never use it again, yet based
on how often the topic reappears, there are clearly people who think
differently. Now similarly to Proposition 8, I believe the GR should
bind the DPL and all delegates—but not the Technical Committee. It is
our supreme court.

Like Josh's message, I make a point of procedure. The Technical
Committee should be free to rule. They could also decline, for example
by citing the GR.

As an aside, the Debian Constitution lacks any elevating language that
by itself would make such daring projections of universal justice
possible. In fact, our constitution mentions no "rights" whatsoever
(except for a copyright notice at the bottom). That is why I had to
resort to an outside precedent to make my point. The constitution's
text also leads me to renew my call: Let's rewrite Debian's
foundational documents together to promulgate inspiring ideals we can
hold up in the sky.

[1] https://openlibrary.org/works/OL16420003W/California_crackup
[2] https://guides.ll.georgetown.edu/c.php?g=592919=4182204
[3] https://lists.debian.org/debian-devel/2014/11/msg00174.html

Kind regards,
Felix Lechner

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-18 Thread Felix Lechner

On Wed, Nov 18, 2020 at 10:21 AM Matthew Vernon  wrote:
> I invite the technical committee to rule that:

What a great read! This message must be among the best prepared, and
most polite, to come before the committee.

Kind regards,
Felix Lechner

Re: Bug#971515: kubernetes: excessive vendoring (private libraries)

2020-10-21 Thread Felix Lechner
Hi Dmitry,

On Wed, Oct 21, 2020 at 12:50 AM Dmitry Smirnov  wrote:
> Yes, at first there will
> be a significant effort but then it will become easier.

I know you put a lot of effort in (as did Michael Stapelberg, with
whom I spent some time before he left), but I don't think our current
approach makes anything easy. It is also why the world is moving in
another direction.

> You are advocating for disruptive
> changes therefore your proposed theoretical solutions have to be available as
> a proof of concept for review.

Did you catch the part about different versions being co-installable?
It would be similar to the freedom we grant to major numbers of shared
object libraries. My point is theoretical only because we do not
presently have it.

> Personally I'm not satisfied with either of those inferior proposals.

How is the second one inferior, please? I think it includes a crucial
missing feature (co-installable versions).

> Look how many packages we already have:
> https://qa.debian.org/developer.php?login=pkg-go-maintainers%40lists.alioth.debian.org+team%2Bpkg-go%40tracker.debian.org

It's an impressive list; thank you for forwarding it. I am proud to be
on the Golang team. :)

> In the meantime you could follow the established practice that is
> demonstrated to be working on several packaged heavy Golang applications.

Not sure about heavy Golang applications, but our established practice
does work well for the relatively lightweight 'gocryptfs', which I
maintain. That source moves very fast. I often have problems finding
the proper go-fuse or xattr prerequisite required for a new version.
Sometimes they are incompatible with the needs of other packages in
the archive.

As a side note, several "library" packages that gocryptfs relies on
should really be marked "Architecture: any" to exercise their test
suites properly. It is another example of the impedance mismatch in
our current approach. We are confusing sources and libraries, and our
method of shoehorning one into the other ought to be rethought.

> Besides un-vendoring libraries can prevent some CVE issues as well.

Packages could declare vendored sources (or Lintian could scan for
them) for an effective match with their security status.

> If we tolerate full vendoring now, because "there is no better way" yet, then
> there will be no better way for sure.

Please do not despair. I offered full vendoring only in the interest
of compromise, which I believe is a worthwhile goal just like the
consensus we are working on. As a project, we are looking for a better
endpoint together.

Kind regards
Felix Lechner

Re: Bug#971515: kubernetes: excessive vendoring (private libraries)

2020-10-20 Thread Felix Lechner
Hi Dmitry,

On Tue, Oct 20, 2020 at 5:24 PM Dmitry Smirnov  wrote:
> Let's not attempt to fabricate perception of consensus please.

Consensus is a worthy goal and perhaps even possible, per below.

> We favour technical elegance
> often in expense of maintainers' comfort.

Is our approach really either one of those? I think our response to
the vendoring explosion is at odds with the trends in many languages.

It's time to retool. At the two ends of the solution spectrum, I see

1. Fully vendored source packages; or
2. A packaging system that allows different vendor versions to co-exist.

Either one allows dependent sources to consume whichever versions they
require, but in my view solution (2) is otherwise superior---provided
that the packaging process is automated. (A language's build system
also has to distinguish the installed versions.) For each language so
affected, could we make (2) our goal, and allow (1) until then?

Kind regards
Felix Lechner

Re: Dispute resolution in Debian

2020-07-29 Thread Felix Lechner
Hi Sean,

On Wed, Jul 29, 2020 at 1:10 PM Sean Whitton  wrote:
> So what you are proposing would correspond to the last of our
> proposals -- try to remove the meditation role the TC presently has?

I am sorry you read my proposal as curtailing TC's "territory". I
merely meant to write that mediating between people and making good
long-term technical decisions for the project are probably two
different things.

Your original email stated as much when you wrote that "[often] the
conflict is not at the technical side."

Kind regards
Felix Lechner

Re: Dispute resolution in Debian

2020-07-29 Thread Felix Lechner
Hi Sean,

I hoped respected members like Sam would send additional ideas first,
but then did not wish to keep you waiting.

On Mon, Jul 27, 2020 at 7:01 PM Sean Whitton  wrote:
> Do you think it shouldn't have those other roles, maybe?  That would
> correspond to the last of our proposals, I think.

As a computer project, Debian's highest decision making body should
probably be a Technical Committee. Current committee members who like
to adjudicate more along human lines, under my proposal, may wish to
join the Community Team.

> I think we think of the community team as mostly about the CoC

Please keep an open mind. The Community Team would quickly shed its
image of a pronoun-wielding social reformer and become a universally
respected arbiter of justice—especially when elected. They have the
human touch.

Debian needs more empathy. People are not logical like machines. They
are burdened by ideas and have fears and hopes. Plus, some do not
lightheartedly express how they feel. Solving conflicts in a unified
system brings all that out in one place, and makes peace.

Kind regards
Felix Lechner

Dispute resolution in Debian

2020-07-26 Thread Felix Lechner
Dear Technical Committee,

In deviation from community standards, I top-post. I hope it provides
a simple and coherent narrative that is also compelling. You should be
familiar with the issues raised in Sean's email.

I would model access to conflict resolution on the US courts. There
should be two levels of jurisprudence: One is quick and easily like
small claims, the other is for appeals. Both can issue rulings that
bind everyone, including delegates and the DPL.

Private side conversations should remain off-limits. They create an
incurable attack surface that lowers credibility. Decision makers who
expressed an opinion outside the official process must recuse
themselves. To seek their opinion, please file a case.

As Sean wrote, many problems at Debian are social in nature, I would
make the Community Team the first legal instance before a party can
appeal to the Technical Committee. Cases at Community Team level
should be heard before a single member unless someone requests a
hearing en banc. That effectively makes the Technical Committee
Debian's Supreme Court (which hears all cases). In some way, this
resembles Sean's Proposal 2.

Like any court, the Community Team and Technical Committee should be
able provide independent solutions of their own design. Ideally, the
judges at the lower level, i.e. the Community Team, would be elected.

Thank you for your hard work on the Technical Committee!

Kind regards
Felix Lechner

-- Forwarded message -
From: Sean Whitton 
Date: Sun, Jul 26, 2020 at 1:37 PM
Subject: CTTE requesting questions for DebConf20 BoF

Hello everyone,


The technical committee has served the project for many years, acting as
a conflict resolution body of last resort.  The TC is established in the
Debian Constitution,[2] which means that it's a highly regulated body
and it's hard to change it. The current setup of the TC has several
problems that need to be addressed.

This document is split between first a description of the current
situation and the problems identified, followed by a bunch of different
proposals that we could implement to try to solve said problems.



Because everything is mandated to be public, discussions must take place
in a public forum where anybody can jump in and add wood to the
fire. This can be very taxing, so there are community members that just
check out and refuse to participate in the discussion even when their
input would be valuable. And even those who participate can feel that
their voice is being drowned by whoever sends the most emails. The
committee strives to hear all opinions equally regardless of how many
emails were sent, but the participants of the discussion can still end
up with a bitter taste because of how it devolved.

Going to the TC is seen as a nuclear option, as a stick to beat others
with.  This is partly because of how the Constitution establishes that
the role of the committee if to be a last resort decision maker. But
also because of historical reasons that are very hard to change, even
when the committee members have all changed by now.

People don't like being on the "losing" side of a decision, but even if
they are on the "winning" side of it, lots of people don't want the
level of flamewar and attention that an issue raised to the TC
brings. Some people would rather orphan a package than participate in a
discussion with the TC.

Social vs Technical

Most of the problems that reach the TC are not purely technical. There's
a lot of "human stuff" going on. People with different goals or
interests that fail to agree on how to move forward, but the conflict is
not at the technical side. For discussions around social issues,
discussing in the open is like being on public trial. It's very
stressful and very hard to find a good resolution.

On top of this, because this is the *Technical* committee, we're forced
to focus on the technical side of a problem. In various occasions this
means that there's really no solution we can offer. We're not explicit
mediators, we don't have the authority to be mediators and we're
definitely not set up in a way that leads to good mediation outcomes.


In many occasions in the past, the committee took too long to make a
decision.  There's many reasons for this. Perhaps we wanted to be
thorough in looking at the problem from all angles. Perhaps we wanted to
explore different alternatives to solve the issue. Perhaps we were busy
with other priorities and the discussion just moved slowly. Whatever the
case, the long time to resolution also devalues the role that the
committee has in solving issues (technical or not technical).

If the TC is going to be of value to the project it needs to act quickly
when dealing with urgent matters (for example, right before a freeze).

It's important to note that the questions brought to the TC typically
have no easy and quick solution, that's w