Re: Proposed MBF: packages that FTBFS with make --shuffle

[Cyril Brulebois]

Soren Stoutner  (2025-05-05):
> Filing these bug reports sounds like a good idea to me.  I don’t see
> any reason to wait as these will be severity:minor, so they won’t
> interfere with the trixie release.

Filing now can trigger uploads to fix those minor bugs, meaning packages
that absolutely do not meet requirements for freeze exceptions end up in
unstable. Depending on circumstances, they might make migrations of other
packages more complicated than they need to be.

(I'll refrain from naming a particular example, but I'm aware of one of
those without even searching for it, it just happened to show up on one of
my specific “important for the release” radars…)


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Upcoming d-i release vs. hard freeze

[Cyril Brulebois]

Hi,

Cyril Brulebois  (2025-05-12):
> I do realize it might make some maintainers nervous as the next few days
> are the last ones before the hard freeze (scheduled 2025-05-15), and I
> do apologize for creating this awkward situation.

The very few packages that were out of sync between testing and unstable
got very special attention (a little more than usual).

Most maintainers were contacted, and responded very positively either to
the proposed earlier migration or to the proposed “let's wait a little”
approach.

The other ones weren't contacted because their packages were either too
young (so they were too late regarding the hard freeze anyway) or almost
ready (so they insta-migrated as soon as I lifted the “udeb freeze”) —
cryptsetup, libpng1.6, lvm2, during the 16:00Z britney run this Friday.

> That being said, the release team has agreed (should it be needed) to
> have at least one britney run between my unfreezing udeb-producing
> packages, and implementing the hard freeze.

I'm not aware of any other packages that might have been caught up in that
last-minute “udeb freeze”, but feel free to reach out to me if you think
I've caused any problems.

[ FTR: Tue May 13 21:04:17 2025 + → Fri May 16 15:21:27 2025 +]

> Thanks for your understanding and your patience.

Thanks to the maintainers I contacted and answered quickly and nicely,
thanks to those who might have been affected and decided to wait it out,
and to the release team for the leeway they were willing to give.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Proposed MBF: packages that FTBFS with make --shuffle

[Cyril Brulebois]

Santiago Vila  (2025-05-17):
> El 17/5/25 a las 1:13, Cyril Brulebois escribió:
> > Soren Stoutner  (2025-05-05):
> > > Filing these bug reports sounds like a good idea to me.  I don’t see
> > > any reason to wait as these will be severity:minor, so they won’t
> > > interfere with the trixie release.
> > 
> > Filing now can trigger uploads to fix those minor bugs, meaning packages
> > that absolutely do not meet requirements for freeze exceptions end up in
> > unstable. Depending on circumstances, they might make migrations of other
> > packages more complicated than they need to be.
> > 
> > (I'll refrain from naming a particular example, but I'm aware of one of
> > those without even searching for it, it just happened to show up on one of
> > my specific “important for the release” radars…)
> 
> Hi. Discussing about the right time to report those bugs does not make
> much sense anymore, because Lucas already reported them :-)

Given I mentioned spotting a resulting upload, it should be pretty clear
that I do know that has happened.

It seemed important to me to reply to the “I don't see any reason to
wait” part (which I quoted, and kept above just in case), so that people
might take that in consideration next time they want to MBF that late in
the freeze.

> Now we can only expect maintainers to act responsibly, and as you
> point out, be particularly careful about not affecting other packages.

The example I was alluding to builds a udeb, and is therefore very much
not something like a leaf package one can easily pretend doesn't exist.

> I think the idea of reporting them now was more about letting the bugs
> to be known "soon", more than starting to fix them "soon". Now we can
> forward the bugs upstream and some of the fixes will be present in the
> new upstream releases that we will start to upload after the release.

I didn't challenge any reasons *for* filing. I'm giving a reason *not
to*, in reply to someone who said wasn't seeing any.

Also, as a random maintainer, despite the “Severity: minor”, seeing
piles of FTBFS bug reports pop up all of a sudden in my maildir right
before entering hard freeze does not bring any kind of warm, cozy
feeling. Distraction and worry isn't quite something I enjoy. YMMV.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Proposed MBF: packages that FTBFS with make --shuffle

[Santiago Vila]

El 17/5/25 a las 1:13, Cyril Brulebois escribió:

Soren Stoutner  (2025-05-05):

Filing these bug reports sounds like a good idea to me.  I don’t see
any reason to wait as these will be severity:minor, so they won’t
interfere with the trixie release.


Filing now can trigger uploads to fix those minor bugs, meaning packages
that absolutely do not meet requirements for freeze exceptions end up in
unstable. Depending on circumstances, they might make migrations of other
packages more complicated than they need to be.

(I'll refrain from naming a particular example, but I'm aware of one of
those without even searching for it, it just happened to show up on one of
my specific “important for the release” radars…)


Hi. Discussing about the right time to report those bugs does
not make much sense anymore, because Lucas already reported them :-)

They are here usertagged:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=lu...@debian.org;tag=ftbfs-shuffle

Now we can only expect maintainers to act responsibly, and as you
point out, be particularly careful about not affecting other packages.

I think the idea of reporting them now was more about letting the bugs
to be known "soon", more than starting to fix them "soon". Now we can
forward the bugs upstream and some of the fixes will be present in
the new upstream releases that we will start to upload after the
release.

Thanks.

Re: Question about splitting a source package with an epoch

[Nicholas D Steeves]

Hi Soren,

Soren Stoutner  writes:

> On Thursday, May 15, 2025 3:56:50 PM Mountain Standard Time Nicholas D 
> Steeves 
> wrote:
>> "adjusting" the epoch also requires discussion, and consensus, on -devel
>
> As far as I know, nobody is proposing adding or adjusting any epochs.  All of 
> these binary packages are going to end up with the same epochs they already 
> have.

Do you disagree with the following?: You're creating two new source
packages that have to pass the NEW queue, you're adding epochs to them,
and your rationale appears to be thus: Because the old multiple-upstream
source package has an epoch, therefore both NEW source packages should
have an epoch.

There's nothing in dsdt-policy about source package naming.

Yes, the NEW binary packages need to provide a greater version than the
old ones, because otherwise upgrades won't occur; No one is saying they
don't need to.

>> We have
>> an obligation to avoid epochs whenever possible, and the way that we do
>> this is by deductively eliminating alternatives such as Breaks,
>> Replaces, and Provides.  Maybe I missed part of this thread?  If so,
>> where can I read that this was demonstrated?
>
> I completely agree.  I detest epochs and do everything I can to avoid using 
> them.

I'm happy to hear that, and I hope that you'll be happy to see that
there's a cool solution!

> The background (partially explained in the first email) is that this is a 
> package I recently salvaged.  It has never had a working debian/watch file 
> and 
> cannot have one in its current state because the original maintainer combined 
> sources from multiple upstream sources with potentially distinct release 
> schedules.

Thank you, and I gathered this much :)

> As part of bringing the package up to Debian standards, I need to split it 
> into two source packages that match the upstream repositories.  At some point 
> in the past, an epoch was added to this package.  I am unaware of the history 
> of why this was done.  I also don’t know why one of the binary packages has 
> an 
> epoch of 2 (something I learned in this email chain), while the other three 
> have an epoch of 1.

Are you going to preserve the git and imported SVN history?  Is the
rationale for the epochs somewhere in that metadata?  Obviously there's
no need to check if your plan is to eliminate the epochs.

> As much as I would like to get rid of the epochs, I don’t see any way to do 
> so.

Here's how: Use accurate upstream versions in two NEW source packages.
Their binary packages gain versioned Provides [and Breaks and Replaces,
if appropriate].  In two Debian releases (forky+1), you can you drop the
Breaks, Replaces, and Provides.  Thus, packages without epochs replace
the packages with epochs, and a pox on the archive is removed.

You can test this by putting the new binary packages generated from the
NEW source packages into a local apt repository.  Their "actual
versions" are inferior to the bin packages currently on your system, but
the versioned Provides will take precedence and sort higher, and apt
will install the seemingly lower-versioned replacements.  Don't forget
to increment the Debian revision on the versioned Provides ;)

> I have never split a source package before, and certainly not one with an 
> epoch.  I assumed that the new source package needed to start out with a new 
> debian/changelog, and creating one with a single entry with an epoch seemed 
> wrong to me.  However, it was pointed out that when splitting a source 
> package, it is appropriate to maintain the debian/changelog history,

There are multiple solutions to the changelog and package history
problems; do what you feel is best.

> in which case I can simply explain in the changelog that the binary
> package was moved to a new source package and the previous
> debian/changelog history will make it obvious why the epoch was
> maintained.

This is not the case, and it will not make the rationale for the epoch
obvious, because earlier you wrote

> At some point in the past, an epoch was added to this package.  I am
> unaware of the history of why this was done.  I also don’t know why
> one of the binary packages has an epoch of 2 (something I learned in
> this email chain), while the other three have an epoch of 1.

which indicates that the changelog is insufficient to explain to the
current maintainer why there is an epoch anywhere in the old package.
If it's not obvious to the maintainer, would it be obvious to anyone
else?

Cheers,
Nicholas


signature.asc
Description: PGP signature

Re: Question about splitting a source package with an epoch

[Soren Stoutner]

On Friday, May 16, 2025 1:51:49 PM Mountain Standard Time Nicholas D Steeves 
wrote:
> Hi Soren,
> 
> Soren Stoutner  writes:
> > On Thursday, May 15, 2025 3:56:50 PM Mountain Standard Time Nicholas D
> > Steeves> 
> > wrote:
> >> "adjusting" the epoch also requires discussion, and consensus, on -devel
> > 
> > As far as I know, nobody is proposing adding or adjusting any epochs.  All
> > of
> > these binary packages are going to end up with the same epochs they 
already
> > have.
> 
> Do you disagree with the following?: You're creating two new source
> packages that have to pass the NEW queue, you're adding epochs to them,
> and your rationale appears to be thus: Because the old multiple-upstream
> source package has an epoch, therefore both NEW source packages should
> have an epoch.

Actually, my plan is to create one new source package and to refactor the 
other existing source package.

> There's nothing in dsdt-policy about source package naming.

No, but there is about binary package naming.  Quoting from the policy.

"Language-specific ispell dictionary packages and wordlists *must be named* 
the classical way, like "ifrench", "wfrench", "iswedish", etc. Use of non-
English language names is discouraged; for example "ingerman" should not be 
named "indeutsch". (This is based on existing practice, and is for consistency 
and the convenience of Debian administrators in all languages.)”

"myspell dictionary packages *must be called* myspell- and hunspell 
dictionary packages *must be called* hunspell- ( being the 
two-digit isocode of the language). Use the myspell prefix for myspell 
dictionaries and the hunspell prefix for hunspell only dictionaries that use 
hunspell features."

I agree that if it were possible to modify the binary package names for one 
release cycle it would be possible to remove the epochs.  And, if this were a 
different type of package that did not have a naming policy, I would do so 
(because I really dislike epochs).

But in this case, doing so would be both against policy and not in the best 
interest of users, because when searching for dictionary packages there is an 
expectation they are able to find them using the canonical names.

-- 
Soren Stoutner
so...@debian.org

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

Re: git branches vs debian specific git tools (Re: RFC for changes regarding NMU in developers reference

[Marco d'Itri]

On May 14, PICCA Frederic-Emmanuel 
 wrote:

Despite this, it is good practice to 
not push any upstream branch to the packaging repository so as to not 
confuse anyone about the purpose of the Git repository.
This kind of personal opinions proposed as if they were the consensus 
are the reason why many people do not take DEP-14 seriously.


--
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1105868: ITP: oniux -- Kernel-level Tor isolation for any Linux app

[Yifei Zhan]

Package: wnpp
Severity: wishlist
Owner: Yifei Zhan 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian@zhan.science

* Package name: oniux
  Version : 0.4.0
* URL : https://gitlab.torproject.org/tpo/core/oniux
* License : MIT OR Apache-2.0
  Programming Lang: Rust
  Description : Kernel-level Tor isolation for any Linux app

oniux is a small command-line utility providing Tor network isolation for
third-party applications using Linux namespaces. It isolates any Linux program
into its own network namespace to route it through Tor and strips away the
potential for data leaks.

See this post for more info:
https://blog.torproject.org/introducing-oniux-tor-isolation-using-linux-
namespaces/

This can be considered as an upcoming, more robust replacement for torsocks.
Interestingly, it uses the relatively new Arti as its Tor engine, which would
benefit from more testing. At the moment this is still experimental software in
a sense that it's new, but it's already functional and I'd like to get more
users to test it. I'd like to maintain it within the Debian Rust team.

Re: git branches vs debian specific git tools (Re: RFC for changes regarding NMU in developers reference

[Julien Plissonneau Duquène]

Le 2025-05-12 15:04, Lucas Nussbaum a écrit :


Regarding "I don't want a gbp.conf", I think that we should aim for 
DRY,

and that adding a gbp.conf in every package doesn't sound too great for
teams that maintain hundreds or thousands of packages...


Could having a way to manage "team defaults" for gbp provide some relief 
here? These could maybe be distributed with the gbp package, or a 
separate distribution-wide package, or by separate packages managed by 
each team. The idea would be to add some logic to gbp to apply different 
defaults depending on the declared maintainer of the package. Such 
defaults could still be overriden by gbp.conf the same way as current 
gbp built-in defaults can be.


Cheers,

--
Julien Plissonneau Duquène