Package: tech-ctte
Control: tags 737634 patch
Control: block 737634 by -1

Hi.

I would like the Technical Committee to explicitly use its power in Constitution 6.1 (1) "Decide on any matter of technical policy"
to decide that:

dpkg-source should be able to build "3.0 (native)" source packages
with a non-native version number.

Note that this does not require a supermajority - a simple majority
will do, since this is "the behaviour of non-experimental package
building tools".

A 10-year-old patch is available to implement the change.

I would also ideally like the TC to explicitly give advice that they
think this change is appropriate for trixie.


Scope
-----

We are talking here precisely about the behaviour of dpkg-source
when the version number has a hyphen, and the source format is
"3,0 (native)".

Currently dpkg-source -b it fails with an error.

Note ethat we are not debating (any longer) whether "3.0 (native)"
packages with a non-native version number are incorrect. That was
settled in 2022 by TC decison: the answer is "yes, they are fine".

The remaining problem is simply that dpkg-source still rejects them.


History
-------

In 2014 dpkg-source was changed to reject these source packages at
build time.

Quickly, a bug was filed,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737634

In that bug several people request the previous behaviour be restored
and give practical explanations why they want to do things that way.
There are a variety of use cases presented.

In 2022, the matter was discussed (along with many other things) by
the Technical Committee. The TC ruling can be found here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737634#107

The full discussion (which includes other matters too) is here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007717

The TC decided to agree with us on the substance. But the wording in
the resolution is unfortuante. The TC say that there is nothing wrong
with this situation, that dpkg-source rejects. But they then say only
"We suggest that the wontfix tag on #737634 be reconsidered".

The maintainer did not respond to this TC decision. Nor did they
respond to a followup message in January 2024.


Current situation
-----------------

The Technical Committee has declared what Debian's technical policy is
in this area. However, the dpkg-srouce maintainer has failed to
align the software with Debian policy.


As I understand from

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737634#112

Ubuntu have patched their version of dpkg-source to relax this
restriction. One consequence is that Ubuntu now contains source
packages that cannot be edited and then rebuild with upstream Debian
tooling.


There is this patch from Adam Conrad:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737634#102

I haven't tried applying it, but I expect that if it doesn't work, the
fix will be about as simple.

This issue means that I have many packages that are still using 1.0
source format, despite its several important behavioural flaws, when
they could be using 3.0. It also greatly complicates recommending
good packaging workflows.

So I would like to see this resolved.


I appreciate that the relationship between the dpkg maintainer and the
TC is poor. But, the TC is the appropriate venue for this decision.
The maintainer has clearly indicated by their non-responses in 2022
and again in 2024 that they don't intend to reconsider this question.

Given that all the technical matters were already discussed
exhaustively in #1007717, I'm hoping that the TC can make a decision
fairly quickly.


Thanks,
Ian.

--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.

Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"Ian" == Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

Ian> I would like the Technical Committee to explicitly use its
Ian> power in Constitution 6.1 (1) "Decide on any matter of
Ian> technical policy" to decide that:

Ian, thanks so much for pushing this forward.
I support Ian's request, his reasoning about procedures, his summary of
the history, and his description of the harm that is caused.

For me this issue is very personal.
If the TC does not agree with Ian, I ask the TC to tell me how we can
get reasonable closure on this issue.
For myself, if there is not a way to actually solve issues like this, I
would find Debian to be an unhealthy environment to invest emotional
energy.
It really really sucks to bring up legitimate concerns and not have
their heard.
I don't have to be right, but if you want me to be part of your
community, you need to show me that I am being listened to, and my words considered.
My motivation in Debian has been decreasing because I've been feeling
like getting this issue addressed is hopeless ever since the dpkg
maintainer declined to respond to my concerns in 2014.
Please prove my hopelessness wrong.

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQSj2jRwbAdKzGY/4uAsbEw8qDeGdAUCaDJadQAKCRAsbEw8qDeG dIktAP0S9ddrhdLZXdqXdtGdOLjKE2Y0MXyhEf+hOYlbyugpdgD/UZ9qiS2/qiWm IHdAHApUmNjoFVcmDk84yYLbQgiDeww=
=Ll7t
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

For reference, the resolution in #1007717 was:

"""
Therefore, using its powers
under constitution 6.1.5, the Technical Committee issues the following
advice:

1. It is not a bug of any severity for a package with a non-native
version number to use a native source package format.

2. Thus, we think that dpkg shouldn't issue warnings, or otherwise
complain, when a non-native version number is used w/ 3.0 (native).

3. We suggest that the wontfix tag on #737634 be reconsidered.

4. We believe that there are indeed circumstances in which
1.0-with-diff is the best choice for a particular source package,
including, but not limited to, git-first packaging workflows.
However, we recommend discontinuing use of 1.0-with-diff in other
circumstances, to simplify the contents of the archive.

This is because there is currently no other source format which is
such that avoid both (i) uploading the whole source, including
upstream, for every upload; and (ii) having to maintain
debian/patches/ inside the package tree.

5. We decline to comment on the recent source package format MBF.
"""

As Ian points out, dpkg-source was changed to reject 3.0 quilt with
native version and 3.0 native with non-native version in dpkg (in
response to #700177) on the basis that it was considered to be a mistake
to have either of those combinations. In discussion on the resulting
#737634 Guillem said that he thought it was a failing in dpkg that 1.0
packages were sloppy in enforcing native vs non-native version numbers;
he later added that he thought that such use of version numbers was
contrary to policy[0].

The TC was not asked to consider over-ruling the dpkg maintainer in its consideration of #1007717; the question of whether 3.0 native should
allow non-native version numbers arose during discussion.

I think Ian is right that we could declare as he wishes under 6.1.1 that:

dpkg-source should be able to build "3.0 (native)" source packages
with a non-native version number.

...although if the dpkg maintainers continue to decline to allow a fix
of #737634 to implement such a policy I'm not quite sure where it would
leave us constitutionally.

I incline to the view that we should probably make such a declaration,
and suggest to the release team that such a fix should be allowed into
trixie (though obviously it's up to them).

Disclaimer: I've known Ian for years. I think there is plenty of
evidence that this doesn't stop me disagreeing with them ;-)

Regards,

Matthew

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737634#77

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-05-27 19:44:52 +0100, Matthew Vernon wrote:

Hi,

For reference, the resolution in #1007717 was:

"""
Therefore, using its powers
under constitution 6.1.5, the Technical Committee issues the following advice:

1. It is not a bug of any severity for a package with a non-native
version number to use a native source package format.

2. Thus, we think that dpkg shouldn't issue warnings, or otherwise
complain, when a non-native version number is used w/ 3.0 (native).

3. We suggest that the wontfix tag on #737634 be reconsidered.

4. We believe that there are indeed circumstances in which
1.0-with-diff is the best choice for a particular source package,
including, but not limited to, git-first packaging workflows.
However, we recommend discontinuing use of 1.0-with-diff in other
circumstances, to simplify the contents of the archive.

This is because there is currently no other source format which is
such that avoid both (i) uploading the whole source, including
upstream, for every upload; and (ii) having to maintain
debian/patches/ inside the package tree.

5. We decline to comment on the recent source package format MBF.
"""

As Ian points out, dpkg-source was changed to reject 3.0 quilt with native version and 3.0 native with non-native version in dpkg (in response to #700177) on the basis that it was considered to be a mistake to have either of those combinations. In discussion on the resulting #737634 Guillem said that he thought it was a failing in dpkg that 1.0 packages were sloppy in enforcing native vs non-native version numbers; he later added that he thought that such use of version numbers was contrary to policy[0].

The TC was not asked to consider over-ruling the dpkg maintainer in its consideration of #1007717; the question of whether 3.0 native should allow non-native version numbers arose during discussion.

I think Ian is right that we could declare as he wishes under 6.1.1 that:

dpkg-source should be able to build "3.0 (native)" source packages
with a non-native version number.

...although if the dpkg maintainers continue to decline to allow a fix of #737634 to implement such a policy I'm not quite sure where it would leave
us constitutionally.

I incline to the view that we should probably make such a declaration, and suggest to the release team that such a fix should be allowed into trixie (though obviously it's up to them).

NACK, it's way too late into the freeze. Toolchain freeze (which dpkg
belongs to) started on 2025-03-15.

Cheers

Disclaimer: I've known Ian for years. I think there is plenty of evidence that this doesn't stop me disagreeing with them ;-)

Regards,

Matthew

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737634#77

--
Sebastian Ramacher

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Sebastian Ramacher writes ("Re: Bug#1106402: dpkg-source, native source package format with non-native version"):

NACK, it's way too late into the freeze. Toolchain freeze (which dpkg
belongs to) started on 2025-03-15.

Of course the final decision is with the Release Team, but looking at
the freeze policy I see that "small, targeted fixes" are acceptable
and also that changes to toolchain packages require pre-approval.

So one thing I am asking for is precisely that pre-approval.
I'm hoping that TC will agree, and join me in asking for that
pre-approval. Obviously there will be no upload to sid, during the
freeze, without it.

I think the required patch is the first hunk[2] from Adam Conrad's
message in 2014 [1]:
- return (0, _g('native package version may not have a revision'))
+ warning (_g('native package version may not have a revision'))
so it seems to me that it is clearly a "small, targeted fix".

So, again, I am not asking for any kind of bypass to the freeze
policy. I think this falls clearly within the policy.

I think it would be preferable if the Release Team avoided making a
definitive decision on this until after the TC has delibrated, but of
course you must do what you think best.

Ian.

[1] Before actually preparing any upload we would want to check what
the Ubuntu version of the patch is. We might well prefer that.

[2] I think the 2nd hunk is out of scope because it's trying to
support native version with "3.0 (quilt)" which is not the subjet of
this request and which I think probably can't function.

--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.

Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Matthew Vernon writes ("Re: Bug#1106402: dpkg-source, native source package format with non-native version"):

I think Ian is right that we could declare as he wishes under 6.1.1 that:

dpkg-source should be able to build "3.0 (native)" source packages
with a non-native version number.

...although if the dpkg maintainers continue to decline to allow a fix
of #737634 to implement such a policy I'm not quite sure where it would
leave us constitutionally.

I think that would constitute authorising an NMU. In other words,
authorising an NMU is what I am asking you to do.

Apparently that wasn't clear from my original request. Since the
effect of a decision should be unambiguous, it would be a good idea
for the TC to explicitly say that you are authorising an NMU. [1]

It seems clear to me that 6.1(1) empowers the TC to authorise an NMU
to dpkg, because dpkg is a "non-experimental package building tool" so
you do not need to use 6.1(4). [2]

I incline to the view that we should probably make such a declaration,
and suggest to the release team that such a fix should be allowed into
trixie (though obviously it's up to them).

Thanks for your supportive opinion.

Ian.

[1] I imagine the actual upload could be done by the TC chair, perhaps
as a sponsored upload prepared by one of the supplicants here. I
think that's a usual process for implementing a TC decision?

[2] In 6.1(1) "behaviour" is explicitly listed, separately from
"contents of technical policy manuals", so 6.1(1) definitely doesn't
just cover documentation.

The Constitution doesn't talk directly about NMUs, only about
decisions. Indeed it generally doesn't talk about how decisoins are implementated. Rather, it assumes that they will be.

Another way to look at this is to consider, what if an implementation
of the decision were to be uploaded to DELAYED? I think Constitution
2.1(1) would bar a dcut or revert.

If anyone doubts that the TC can authorise an NMU to dpkg under
6.1(1), I guess we should ask for a ruling from the Secretary.

--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.

Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-05-27 20:48:30 +0100, Ian Jackson wrote:

Sebastian Ramacher writes ("Re: Bug#1106402: dpkg-source, native source package format with non-native version"):

NACK, it's way too late into the freeze. Toolchain freeze (which dpkg belongs to) started on 2025-03-15.

Of course the final decision is with the Release Team, but looking at
the freeze policy I see that "small, targeted fixes" are acceptable
and also that changes to toolchain packages require pre-approval.

You might consider it small and targeted, but for me overriding the dpkg maintainer does not fall into this category. It also puts additional
workload on us to check that no other upload of dpkg for trixie reverts
this change afterwards.

And we are talking about a bug that enough time to be fixed during the
trixie release cycle (and many more release cycles since *2014*). This
change can wait for forky.

Please fix RC bugs, review unblock requests, test the installer, or, ... instead so that we can release trixie and lift the freeze.

Cheers
--
Sebastian Ramacher

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Control: owner -1 !
Control: tags -1 + confirmed

Hi,

as per https://salsa.debian.org/debian/tech-ctte/-/blob/master/procedures/moderation.md
I am assuming the moderator role for this TC bug.

I'm going to summarize the state of this bug and the original bug
against dpkg as I have read up on it:


Ian submitted the TC bug as a follow-up to a previous TC ruling that it
is not considered a bug to have a non-native version in a native source package. He asks that dpkg-source no longer unconditionally rejects such versions for source packages with format "3.0 (native)".

Guillem argues in the original bug that the versioning scheme is an
important part of the distinction between native and non-native packages
and explicitly encoded as such in Debian Policy. As dpkg-source will
only refuse to *build* non-complying packages, and builds are presumed
to come with package changes and a version bump, it is a small ask of maintainers to fix their affected packages.

Dimitri argues that the native package format is useful even for
non-native packages and mentions the linux-signed source package, which
is technically native but needs to match the version number of the corresponding non-native linux image. (Ian also mentions in the TC bug
that Ubuntu has patched dpkg to enable this use-case). Besides, Debian
tooling is not exclusively used for Debian development and therefore
should not unconditionally enforce Debian Policy either. Sam and a few
others support this viewpoint with use-cases outside Debian, which would benefit from dpkg-source being more lenient.

As a secondary motion, Ian wishes for dpkg-source to be changed in time
for the trixie release. The Release Team, however, has signaled that
they consider this change to come far too late in the release cycle, especially considering that the bug in questions has been open for more
than 10 years at this point.


If I have mispresented or omitted important facts, please do not
hesitate to correct me.

Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀ ╭────────────────────────────────────────────────────╮
⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │
⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmg8xIwACgkQzIxr3RQD 9MorOxAAnO2EQk6+q8F8/fVchkNOLr6WAvBksNs1Uul1RFvZYDqfe6Pt/Vccvt0/ ejiqJS4I3CioCxKut+5Jotex5xFGyth8BQgpiF2EYrf6nRI+LZBvlV/glcg2YDW9 5KI2LDRF3tuEIBQor7VmsUc+BWWSFWMuW3aAJKxgPHu6XnlIDA1piAD5yqajsKYK LeVCUNMcNEp62QZX2IzgEhRw6FLXXfZRuhRcyUqoHZTtag0bDcabbiHknLoX4MuI 4DM3qequAbhHiLJrfqAgdKGwZTkULMzwNCytXZIayO+0cj+9uvTYKmQZ5xH1Y5z5 hKXz2ANtSSTveBz26gmKXQBhTLzQ2YFficsnkJooSsf

Hi, thanks.

Timo R�hling writes ("Re: dpkg-source, native source package format with non-native version"):

Dimitri argues that the native package format is useful even for
non-native packages

...

If I have mispresented or omitted important facts, please do not
hesitate to correct me.

I think this would benefit from stronger emphasis on the relevant
discussions in #1007717, which are much more comprehensive, and many
of which bear directly on the underlying technical policy question.

In #1007717 several use cases were presented there for "3.0 (native)"
source packages with a native version, including by me and Sam and
others. In particular many reasonable git-first workflows find this convenient. The downsides of "3.0 (quilt)" as an alternative are
discussed in #1007717 too.

At the very least your summary ought to mention that this restriction
is blocking me from changing several of my packages from 1.0 source
format.

Also I think your summary doesn't really do justice to the ruling in
#1007717. for example, in your summary you write

Guillem argues in the original bug that the versioning scheme is an important part of the distinction between native and non-native packages

This is an argument in support of of the supposed bugginess of "3.0
(native)" with a non-native version. It was considered by the TC in
#1007717 - and rejected.

Obviously as someone whose views (on this point) were upheld by the TC
in #1007717, I have an interest in the TC not re-litigating the
underlying technical decision. So my intent with my request was to
ask the TC to permut an NMU, to align dpkg with the TC decision last
year.

Your summary probably ought to mention that I see this as a procedural
request to permit an NMU, not a request for a substantive decision.

So I think the summary ought to acknowledge that there is a process
question to answer, before we go back into all the arguments presented
in #1007717.

Obviously the TC should feel free to re-open previous decisions,
especially in the light of new information and experience. But I
don't think there has been any new information here, other than
that Ubuntu has relaxed this restriction without any problems for
them.

Thanks,
Ian.

--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.

Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"Timo" == Timo Röhling <roehling@debian.org> writes:

Timo> Guillem argues in the original bug that the versioning scheme
Timo> is an important part of the distinction between native and
Timo> non-native packages and explicitly encoded as such in Debian
Timo> Policy.

Several of us argued both back in 2014 and with the TCthat Guillem's
interpretation of policy was wrong.
Back in 2014, Russ (one of the policy editors)agreed with my
reading of policy that allowed for native packages with a non-native
version number.

My reading of the TC's decision is that the TC supported the claim that
a native package with a non-native version number was not a bug--thus
not a policy violation.

Like Ian, I do not wish to see the underlying technical issue
relitigated.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Sam and Ian,

thank you for your replies!

* Sam Hartman <hartmans@debian.org> [2025-06-02 11:44]:

My reading of the TC's decision is that the TC supported the claim that
a native package with a non-native version number was not a bug--thus
not a policy violation.

Like Ian, I do not wish to see the underlying technical issue
relitigated.

In my initial email, I tried to give a neutral representation of the
view points of the involved parties. Clearly I overshot in my attempt to
be fair to all sides; as you both pointed out, this could be
misconstrued as intention to overturn the previous ruling. I apologize
for the confusion; there is no such intention.


Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀ ╭────────────────────────────────────────────────────╮
⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │
⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmg97FgACgkQzIxr3RQD 9Mp8+BAAnxkurXItSWoh/N/x4SVvfEm72vpXU3TX1/SuqZYraZJoR66Y5D9MwauM 8u25jvh9mk/Mdi2IeH92+vHCkJJI0r477vIlKSRP4zFV2io75KHKBRvqMH26JIOB 4MZv2Lxoodf63jt9wjm5Uw8v66RqKCx0ZpcJWm7yzzNg+c3OnKvMo4Z48MfJ7+eW Sq7YqGTwebd52JcDAfxNYEonMq5cSCsY8Hpw7lVvCfZXTgQYZyvq3kjGMjab5aYJ EwQcnXeanr/RIqVcIZUxPN95KK11/4krUgoHk2nGTBjpzLd6owWsn8NTqR7GKV3N sVAxEPPGixM+8V4cEQQH2YrlvXIs3tetNvhdjmr4z9p

Hi everyone.

Please see:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737634#117

It appears that dpkg is now going to be fixed, albeit with a bunch of unpleasantness in the documentation, and only for forky.

Meanwhile, the dpkg maintainer filed a bug against policy, #1107137.
That report was well-founded (albeit unpleasantly worded), since
policy has the same conflation that the TC rejected in 2024. I have
proposed patches to policy in that bug. I think that conversation can
continue there.

I still think it would have been good to have this fixed in trixie.
The original one-line revert would have been very low risk from a
purely technical point of view.

However, I doubt the TC will want to try to clear a path through the nontechnical obstacles between this improvement and trixie. So, to be
clear, I'm withdrawing my request for the TC to authorise an NMU,
or to express any opinion to the Release Team.

I still get the feeling that any exercise of governance or oversight
is Debian is widely regarded as cataclysmic. I have been criticised
here and in #1107137, as if my requests were unreasonable or obviously
beyond the pale. This is very uncomfortable for me, and this kind of
thing is hardly going to encourage others to try to resolve
longstanding problems using our official processes.

So I would appreciate at the very least some explicit recognition that
my requests to to the TC, in this bug, were appropriate.

Thanks,
Ian.

--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.

Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
9that is a private address which bypasses my fierce spamfilter.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Jun 03, 2025 at 04:36:28PM +0100, Ian Jackson wrote:

However, I doubt the TC will want to try to clear a path through the nontechnical obstacles between this improvement and trixie. So, to be
clear, I'm withdrawing my request for the TC to authorise an NMU,
or to express any opinion to the Release Team.

I'd like to take over this request then. We have also the policy
proposal of #1049406 open, which will make secure boot package building impossible in Debian.

So we need to fix one of the problems.

Bastian

--
Murder is contrary to the laws of man and God.
-- M-5 Computer, "The Ultimate Computer", stardate 4731.3

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bastian Blank writes ("Re: Bug#1106402: dpkg-source, native source package format with non-native version"):

I'd like to take over this request then. We have also the policy
proposal of #1049406 open, which will make secure boot package building impossible in Debian.

OK. My reading of #1049406 is that it's asking a question.

I think you'll probably agree with my answer in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1049406#15
?

Ian.

FTR I'm going to be mostly AFK for a week or so, so unless something
urgent comes up I'll look at this after that.

--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.

Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello Ian,

* Ian Jackson <ijackson@chiark.greenend.org.uk> [2025-06-03 16:36]:

I still get the feeling that any exercise of governance or oversight
is Debian is widely regarded as cataclysmic. I have been criticised
here and in #1107137, as if my requests were unreasonable or obviously
beyond the pale. This is very uncomfortable for me, and this kind of
thing is hardly going to encourage others to try to resolve
longstanding problems using our official processes.

So I would appreciate at the very least some explicit recognition that
my requests to to the TC, in this bug, were appropriate.

Speaking with my TC hat on: Yes, I believe they were absolutely
appropriate, and I find it unacceptable to insinuate anything else. This
does not mean that everyone has to agree with you, of course, but the TC
is the place to settle technical disagreements such as this one.

Speaking personally, I know people sometimes perceive technical
criticism as personal attack, and sometimes people unjustly vent their frustration over a bug to the maintainer. This can be very discouraging,
but neither should not be a reason to keep quiet about technical issues;
it means that we should always strive to be kind to one another.

And again, I find no fault in your behavior. I've seen you become
frustrated on occasion, and express this frustration, but as far as I
can remember you never crossed the line.

If there is any blame at all to assign here, one might wonder if the TC
should have followed up on #1007717 earlier. I think this is something
we need to discuss internally.


Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀ ╭────────────────────────────────────────────────────╮
⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │
⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmhBfTsACgkQzIxr3RQD 9Mqq6RAAhtNk8pvTpQZ8tLyJ8vjbb9WWpIeaC6w8KYXJ2Z11mYJWcmDR1sXavF38 MnJKeNHtdASDSIUHskQbuXgMqG+x/OIc01vQUyFqUDC03TFZtWJPR5vNBpWBsgyf lcOxWp7ICtiJac2HIUBTS6RMS7inDS3jqmYozg1+1iRy1pwcuJr3/ECb+FJtINMx IWbMKKux2HiATKJPWhRueX8GsJuSSkUAcsdeee15uLWo+kzAAcSaL43VeCQtnwU9 KJkXuT1jZLODyMeRPDkgp89nz86J9QAjb7MrWS3gAExrmmEfLZVZCmaplD3BlaHh IrRTfFbqxdIFIUJGE5l/Vaj3jPdnMVCICpypvdA3iZy

XPost: linux.debian.devel.release

* Ian Jackson <ijackson@chiark.greenend.org.uk> [2025-06-03 16:36]:

It appears that dpkg is now going to be fixed, albeit with a bunch of >unpleasantness in the documentation, and only for forky.
[...]
I still think it would have been good to have this fixed in trixie.
The original one-line revert would have been very low risk from a
purely technical point of view.

Release Team, would you be willing to reconsider your position on a
trixie fix, given that Guillem agreed to implement the change? I concur
with Ian's risk assessment, and I believe your main objection was the nonconsensual nature of the upload.

Guillem, would you be willing to backport the change to trixie or
consent to an NMU?


Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀ ╭────────────────────────────────────────────────────╮
⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │
⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmhBf8wACgkQzIxr3RQD 9Mr7aw//e9NG0GTQx08uClHFyZ/SmMwcyg3xhCedD8eIWVPzMaqzrHWBm3+AWEtx IAjoX3YZCQ+SVVOAa9xFApgL5HYZ16WWDyFVGq7WB1I8ZOkOE9IPki/FiEEx6CiC R3fqYO2OlNGGuk1i+TFicSnT8l80FhHjX2G/NLlDGMjisG77+tZ6FmjnvtsT0NyQ KtB7+IqVASsOatoUqVkFRXvsDcSl78yZYM958MzlS8lC/YSxMGmJsm9+Vfjk4UMe 7MIQMxdk36qktKRv6q0AojCxzEVOgl6DRXTWTrEoPeHBFXZVP5I1Zu5VoO+sUGOA svWMFVNJvGPLtprxMMxFd0Ch9XUhR/9R7RdpXaNlEnZ

XPost: linux.debian.devel.release

On Thu, 2025-06-05 at 13:30:21 +0200, Timo Röhling wrote:

Guillem, would you be willing to backport the change to trixie or
consent to an NMU?

No. The required changes are too intrusive, add new strings to
translate, add new interfaces, and deprecate others with warnings.

Guillem

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.release

On 2025-06-05 13:30:21 +0200, Timo Röhling wrote:

* Ian Jackson <ijackson@chiark.greenend.org.uk> [2025-06-03 16:36]:

It appears that dpkg is now going to be fixed, albeit with a bunch of unpleasantness in the documentation, and only for forky.
[...]
I still think it would have been good to have this fixed in trixie.
The original one-line revert would have been very low risk from a
purely technical point of view.

Release Team, would you be willing to reconsider your position on a trixie fix, given that Guillem agreed to implement the change? I concur with Ian's risk assessment, and I believe your main objection was the nonconsensual nature of the upload.

No, we are trying to get trixie released. Wishlist bug fixes for
toolchain issues are still not appropriate at this stage of the freeze.

Cheers

Guillem, would you be willing to backport the change to trixie or consent to an NMU?

Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀ ╭────────────────────────────────────────────────────╮
⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │
⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯

--
Sebastian Ramacher

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)