Re: i686 require SSE4.1-capable processor?

[Andrey Rakhmatullin]

On Tue, Jul 16, 2024 at 12:46:01PM +0100, Phil Wyett wrote:
> > > > Packages built for the i386 arch need to conform to the i386 baseline,
> > > > which is currently i686. If a package contains a newer instruction it's 
> > > > a
> > > > bug in that package and gcc is not the cause of it, the package is.
> > > > https://buildd.debian.org/status/fetch.php?pkg=filezilla=i386=3.63.0-1%2Bdeb12u3=1704758683=0
> > > > indeed contains at least one compile command with -msse4.1.
> > [...]
> > > Yeah, I have discovered that it is indeed a cause of the d/rules in the
> > > filezilla package. I blame having taken over it recently, and still
> > > haven't learned the ins and outs of it.
> > 
> > It'd also be good to document reasons for such workarounds next time. 
> > Both the changelog and the surrounding comments don't really tell you 
> > what to watch out for in a new gcc version. There's no bug reference 
> > (GCC or Debian bug) or example error message or a pointer to possible 
> > miscompilation.
> > 
> > Kind regards
> > Philipp Kern
> > 
> 
> Hi all,
> 
> The addition to 'debian/rules' was in response to the below.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053804

That bug report looks like the outcome of the "addition", not the reason
for it. Did you mean
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034195 ?

The interactions in both bugs look very weird to me, especially when the
same person proposes compiling software with SSE4.1 and then complains
that it fails on older hardware, and the reason for closing the newer bug
also looks weird to me. I think it should be reopened and bumped to RC.



-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: i686 require SSE4.1-capable processor?

[Andrey Rakhmatullin]

On Mon, Jul 15, 2024 at 01:42:50PM +0200, Andreas Ronnquist wrote:
> I'm maintaining a package (filezilla) which just got a bug report that
> it simply crashes on program start - It gets a SIGILL - "Illegal
> instruction". (#1076312 report [1]). 
> 
> After the reporter debugged it, it seems like it crashes on the
> assembler instruction "pinsrd", which looks like it was added in
> SSE4.1, while the reporter runs this on a 
> 
> Intel(R) Celeron(R) M CPU 420  @ 1.60GHz
> 
> which only supports SSE2. (Full cpuinfo available in the report) - So, my
> question is - is this a cpu that is too old for Debian to support, or
> should we support it, and Debian gcc generates invalid code requiring SSE4.1
> while it still should support SSE2? (Or is the problem something else
> completely?)

Neither.
Packages built for the i386 arch need to conform to the i386 baseline,
which is currently i686. If a package contains a newer instruction it's a
bug in that package and gcc is not the cause of it, the package is.
https://buildd.debian.org/status/fetch.php?pkg=filezilla=i386=3.63.0-1%2Bdeb12u3=1704758683=0
indeed contains at least one compile command with -msse4.1.

(there is also a "workaround", adding a dep on some isa-support
subpackage, but it's unlikely to be the correct course of action here and
I still don't know why is it even allowed in general)

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: what about Netplan?

[Andrey Rakhmatullin]

On Sat, Jul 13, 2024 at 09:44:03PM +0200, Lukas Märdian wrote:
> > However, I do not think it should be the default. First of all, only
> > Ubuntu uses it, nobody else - as Simon says, we don't want the
> > defaults to be super-special things that nobody else uses. And then
> 
> Actually, I think this is an agrument FOR Netplan, not against it. Netplan is 
> being used
> by millions of users for 7+ years. Plenty of usecases have been tried and 
> documented. It's
> clearly not a "super-special thing that nodbody uses".
> 
> Whereas I'm not aware of a major Linux distro using systemd-networkd 
> directly, Debian would be
> singeling out itself. I see some of networkd's strengths with advanced users 
> who want to dig deep
> and have full control at minimal resource usage (e.g. Arch Linux). Also with 
> lightweight container
> usecases, where network config only needs minimal manipulation after 
> deployment (if at all).
> 
> The RedHat ecosystem is all-in on NetworkManager. Debian and Ubuntu have 
> (natually) been very close
> to each other (e.g. package management) and together with its derivatives 
> create the Debian ecosystem.

Then it looks like a chance for netplan to go the way of upstart?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Ready stage for DD review/sponsoring - Too many DDs may spoil the broth. :-)

[Andrey Rakhmatullin]

On Fri, Jul 12, 2024 at 07:01:41AM +0100, Phil Wyett wrote:
> > > As we embark on a new process where packages submitted to mentors are 
> > > reviewed
> > > and brought to a "Ready" stage for then busy DDs who are gracious enough 
> > > to give
> > > their time to review and possibly sponsor into Debian. We have a unique 
> > > problem
> > > (one which is now a nice one to have to be honest :-)) where more than 
> > > one DD
> > > may input on the same package review.
> > > 
> > > Could submitters to mentors and DDs please ensure that only one DD is 
> > > working on
> > > a package. This is to avoid conflicting info and also not waste valuable 
> > > DD
> > > time. If a package is taken, please find another to work on, as there are 
> > > many
> > > at the "Ready" stage.
> > 
> > Do you also suggest to not review packages one isn't going to sponsor? Or
> > how should this work?
> > 
> 
> Morning Andrey,
> 
> Anyone can review packages, that has been part of mentors forever really. But
> whoever does review a package, I would hope they see it through its journey.
> 
> * For non DDs. Hopefully take it to that ready stage where a DD can then take
> over and finish a packages journey.
> 
> * For DDs. Hopefully take a package on prior to or at the ready stage and take
> it through its full journey.
> 
> Is this reasonable?

Yeah, it's reasonable, I won't do drive-by reviews in the future.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Ready stage for DD review/sponsoring - Too many DDs may spoil the broth. :-)

[Andrey Rakhmatullin]

On Fri, Jul 12, 2024 at 05:54:59AM +0100, Phil Wyett wrote:
> Morning all,
> 
> As we embark on a new process where packages submitted to mentors are reviewed
> and brought to a "Ready" stage for then busy DDs who are gracious enough to 
> give
> their time to review and possibly sponsor into Debian. We have a unique 
> problem
> (one which is now a nice one to have to be honest :-)) where more than one DD
> may input on the same package review.
> 
> Could submitters to mentors and DDs please ensure that only one DD is working 
> on
> a package. This is to avoid conflicting info and also not waste valuable DD
> time. If a package is taken, please find another to work on, as there are many
> at the "Ready" stage.

Do you also suggest to not review packages one isn't going to sponsor? Or
how should this work?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Bug#1075905: ITP: python-fraction -- Fraction carries out all the fraction operations including addition, subtraction, multiplication, division, reciprocation

[Andrey Rakhmatullin]

On Sun, Jul 07, 2024 at 01:54:59PM -0400, Yogeswaran Umasankar wrote:
> Yes, can use the standard library. This dependency chain starts with
> moarchiving, which itself is a dependency for cma, and so on. I can
> create a patch specifically for moarchiving.

As reported elsewhere, moarchiving declares a dep on it but doesn't
actually import it.
This needs to be fixed upstream to.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Bug#1075905: ITP: python-fraction -- Fraction carries out all the fraction operations including addition, subtraction, multiplication, division, reciprocation

[Andrey Rakhmatullin]

On Sun, Jul 07, 2024 at 07:00:57PM +0200, Daniele Nicolodi wrote:
> On 07/07/24 17:43, Yogeswaran Umasankar wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Yogeswaran Umasankar 
> > X-Debbugs-Cc: debian-devel@lists.debian.org, y...@debian.org
> > 
> > * Package name: python-fraction
> 
> How is this different from the fractions module in the Python standard
> library?  I was not able to find anything that this library does that the
> standard library equivalent does not do.
Yeah, it looks like a school project.
Is it a revdep of something? If so, that's probably a mistake?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: DD's, Debian Mentors needs you!

[Andrey Rakhmatullin]

On Sun, Jul 07, 2024 at 10:10:55AM -0400, Jeremy Bícha wrote:
> On Sat, Jul 6, 2024 at 9:46 AM Phil Wyett  wrote:
> > Debian Mentors[1] always struggles to find available Debian Developers for 
> > final reviewing and
> > sponsoring of packages submitted too our part of the project.
> 
> One thing that has disrupted my use of https://mentors.debian.net/ for
> sponsoring is that I am unable to log in. I don't get any of the "sign
> up" or "reset password" emails.

Sponsors don't need an account there though, (optionally) looking at the
package page and downloading the .dsc should be enough.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: DD's, Debian Mentors needs you!

[Andrey Rakhmatullin]

On Sun, Jul 07, 2024 at 07:54:25AM +0200, Andreas Tille wrote:
> Hi Phil,
> 
> thanks for advertising Debian Mentors.
> 
> Am Sat, Jul 06, 2024 at 02:45:33PM +0100 schrieb Phil Wyett:
> > Hi all DD's
> > 
> > Debian Mentors[1] always struggles to find available Debian Developers for 
> > final reviewing and
> > sponsoring of packages submitted too our part of the project.
> 
> One thing I'm missing on mentors.d.n is that I it does not advertise
> existing teams.  It happened from time to time that there was some
> sponsoring request of Debian Science, Debian Med or Debian Python Team
> related packages (surely others I did not notices).  Asking on the
> relevant lists very easily helps getting the package in question
> sponsored.  I have a personal sponsoring policy that I only sponsor from
> a Git repository in a team I'm working in.  This has the advantage I can
> easily help by pushing some commit with extensive comment to teach the
> sponsee in some direct way.  Making a sponsee aware how to work together
> with a team inside Debian is IMHO very important.
> 
> Thus I would welcome if there could be some explicit hint to mentees
> to relevant teams.

Note that "Offer your package directly to relevant teams and individual
developers." is sugested on https://mentors.debian.net/intro-maintainers/
and https://mentors.debian.net/sponsors/

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: DD's, Debian Mentors needs you!

[Andrey Rakhmatullin]

On Sun, Jul 07, 2024 at 07:41:25AM +0800, xiao sheng wen(肖盛文) wrote:
> Hi,
> 
>  Support this become a weekly thing or a monthly thing.
> 
> Can mentors.debian.net sent package list to  debian-devel automatically?

The list of open RFSes is always available at
https://bugs.debian.org/sponsorship-requests



-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Q: Ubuntu PPA induced version ordering mess.

[Andrey Rakhmatullin]

On Wed, Jul 03, 2024 at 09:27:03AM +0200, Philip Hands wrote:
> IOhannes m zmölnig (Debian GNU|Linux)  writes:
> 
> > anyhow here's my 2¢:
> > according to you¹, upstream have simply botched their package 
> > versioning, which i would consider *a bug*.
> > bugs cause pain.
> 
> AIUI the botching was done by whoever put the PPA together.
> 
> If that's the same as upstream, fair enough, but it seemed to me (having
> glanced at the repo) that upstream has been using sane versions
> throughout.

<83d8755d-5f57-47e1-bda3-5536b7563...@gmail.com> said it's the upstream.



-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Q: Ubuntu PPA induced version ordering mess.

[Andrey Rakhmatullin]

(sorry, I replied thinking I've read the entire thread, I didn't notice
that there is a second thread broken off of this one)


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Q: Ubuntu PPA induced version ordering mess.

[Andrey Rakhmatullin]

On Mon, Jul 01, 2024 at 11:59:00PM +0200, Alec Leamas wrote:
> > > After some thought, I tend to think that adding an epoch is the right 
> > > thing
> > > here.
> > > 
> > > The Policy [1] says:
> > > ---
> > > Epochs can help when the upstream version numbering scheme changes, but 
> > > they
> > > must be used with care. You should not change the epoch, even in
> > > experimental, without getting consensus on debian-devel first.
> > > ---
> > > 
> > > With all this said: Is this a case where using a epoch is justified? If 
> > > not,
> > > why?
> > 
> > Adding epochs to work around 3rd-party repo version problems sounds quite 
> > wrong.
> > We don't even add epochs that Ubuntu itself adds.
> > 
> 
> But this is not about third parties, it's about upstream which publishes PPA
> packages. 

I don't think it matters that they are published by the upstream.
Similarly to the versions issue you are not required to guarantee smooth
upgrades from 3rd-party packages and other such things.

> I also hesitate to add an epoch, after all they are basically considered
> evil. But if we should not use them when upstream has a broken versioning we
> are about to replace, when should we use it?

When upstream had a broken versioning *that we used in Debian*.

> I have good relations with upstream, and they are willing to abandon the
> current broken versioning in favor of something sane. But the legacy is
> there, and we need to handle it.

Again, it's just questionable to me if we *need* to handle upgrades from
non-Debian packages.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Q: Ubuntu PPA induced version ordering mess.

[Andrey Rakhmatullin]

On Mon, Jul 01, 2024 at 09:46:11PM +0200, Alec Leamas wrote:
> On 01/07/2024 20:48, Alec Leamas wrote:
> > Dear list,
> > 
> > Still working with the opencpn package. Now trying to normalize the
> > Ubuntu PPA builds so they can are based on the same debian/ directory
> > and tools as the existing Debian opencpn package.
> > 
> > opencpn is currently in a beta phase targeting a 5.10.1 release. The
> > beta versions are like "5.9.2-beta2+dfsg-1ubuntu1~bpo2204.1". The
> > upstream policy is to use 5.9.2-beta2, 5.9.3-beta3 so this ordering is,
> > although a bit strange, still ok.
> > 
> > However, a quite large user base have PPA packages installed. These have
> > versions like 8767+b2cbf5a3f~ubuntu24.04.1. The prefix is a build
> > number, so they are ordered. but all these versions are higher than
> > anything like 5.9.x.
> > 
> 
> After some thought, I tend to think that adding an epoch is the right thing
> here.
> 
> The Policy [1] says:
> ---
> Epochs can help when the upstream version numbering scheme changes, but they
> must be used with care. You should not change the epoch, even in
> experimental, without getting consensus on debian-devel first.
> ---
> 
> With all this said: Is this a case where using a epoch is justified? If not,
> why?

Adding epochs to work around 3rd-party repo version problems sounds quite wrong.
We don't even add epochs that Ubuntu itself adds.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Urgent help with upload of netatalk to prevent being autoremoval from testing

[Andrey Rakhmatullin]

On Sat, Jun 29, 2024 at 02:13:04PM +, Daniel Markstedt wrote:
> Netatalk got dropped from Bookworm because there was a changing of the guards 
> of upstream maintainers during the freeze time.
> So I'm just naturally anxious about missing the boat again for Trixie.

Just make sure it's in testing before the appropriate freeze stage.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: How does lintian use groff to validate man pages?

[Andrey Rakhmatullin]

On Fri, Jun 28, 2024 at 11:38:50AM +, c.bu...@posteo.jp wrote:
> > lintian-explain-tags can provide you with extensive information
> > ...
> > N:   LC_ALL=C.UTF-8 MANROFFSEQ='' MANWIDTH=80 \
> > N:   man --warnings -E UTF-8 -l -Tutf8 -Z  >/dev/null
> 
> Do I do something wrong? It is not working in my case (running on Debian
> 12):
> 
> groff LC_ALL=C.UTF-8 MANROFFSEQ='' MANWIDTH=80 man --warnings -E UTF-8 -l
> -Tutf8 -Z ./backintime.1 >/dev/null
> groff: unrecognized option '--warnings'

You prepended "groff" to the command.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: BIMI verified email logo for @debian.org addresses

[Andrey Rakhmatullin]

On Thu, Jun 27, 2024 at 07:29:45PM +0800, Blair Noctis wrote:
> Hi,
> 
> [BIMI], or Brand Indicators for Message Identification, is a specification to
> let supporting email clients show a brand's logo next to verified email 
> domains.
> It would be great to have the Debian logo shown next to @debian.org addresses.
> 
> An email service provider implements it by implementing DMARC with a 
> quarantine
> or reject policy, as well as adding a TXT record pointing to the logo.
> 
> For a quick intro, please see 
> https://postmarkapp.com/blog/what-the-heck-is-bimi
> 
> BIMI: https://bimigroup.org/

(everything I know about BIMI I've learned from
https://16years.secvuln.info/ )


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Reviving schroot as used by sbuild

[Andrey Rakhmatullin]

On Tue, Jun 25, 2024 at 10:24:12AM -0700, Russ Allbery wrote:
> Guillem Jover  writes:
> 
> > I manage my chroots with schroot (but not via sbuild, for dog fooding
> > purposes :), and use type=directory and union-type=overlay so that I get
> > a fast and persistent base, independent of the underlying filesystem,
> > with fresh instances per session. (You can access the base via the
> > source: names.) I never liked the type=file stuff, as it's slow to
> > setup and maintain.
> 
> Ah, thank you, I didn't realize that existed.  That sounds like a nice
> generalization of the file system snapshot approach.

(Unless I'm missing something it's the default setup for e.g.
sbuild-createchroot(8))

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Reviving schroot as used by sbuild

[Andrey Rakhmatullin]

On Tue, Jun 25, 2024 at 02:02:11PM +0100, Simon McVittie wrote:
> > In this work, limitations with --chroot-mode=unshare became apparent and
> > that lead to Johannes, Jochen and me sitting down in Berlin pondering
> > ideas on how to improve the situation. That is a longer story, but
> > eventually Timo Röhling asked the innocuous question of why we cannot
> > just use schroot and make it work with namespaces.
> 
> I have to ask:
> 
> Could we use a container framework that is also used outside the Debian
> bubble, rather than writing our own from first principles every time, and
> ending up with a single-maintainer project being load-bearing for Debian
> *again*? I had hoped that after sbuild's history with schroot becoming
> unmaintained, and then being revived by a maintainer-of-last-resort who
> is one of the same few people who are critical-path for various other
> important things, we would recognise that as an anti-pattern that we
> should avoid if we can.

100%


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Mini-DebConf in Cambridge, UK - October 10-13 2024

[Andrey Rakhmatullin]

On Tue, Jun 25, 2024 at 06:14:54AM -0400, Roberto C. Sánchez wrote:
> > The style of writing mail - everything in one line, CCing several lists is
> > similar to how Luna writes it too. Freaky.
> > 
> AI can already generate audio and video that convincingly imitate real
> people. Why not the same with email? Though, the implications are rather
> serious.

That "style" doesn't seem to be hard to imitate manually...

> Perhaps our policies need to evolve to expect (or require?)
> cryptographic signatures from DDs in mailing list discussion.

Not all people here are DDs anyway.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: dh_auto_clean, autoconf, and building packages twice (was: Potential MBF: packages failing to build twice in a row)

[Andrey Rakhmatullin]

On Sun, Jun 23, 2024 at 02:06:04PM +0200, Magnus Holmgren wrote:
> I'm very late to the party, but after reading the entire thread, I'd like to 
> discuss a more specific, but perhaps not uncommon, situation with regard to 
> cleaning and building again:
> 
> We have a [still fairly] typical upstream package using Autotools. The 
> tarball 
> includes some built files (e.g. documentation), i.e. make dist builds them 
> (as 
> long as the right tools are installed) and make distclean deletes them. 
> dh_auto_clean by default runs make distclean if such a target exists. But 
> that's not the case until ./configure has been run, because until then, there 
> are no makefiles. So The first time you run debian/rules build, the shipped 
> version of the files will be untouched and used in the final package, but 
> when 
> you then clean and build again, they will be deleted and rebuilt (or the 
> second build fails because of missing build dependencies).
> 
> Besides building a package twice potentially failing, this can lead to the 
> second build being different from the first. So I'm thinking:
> 
> 1. Do we generally want dh_auto_build to run make distclean, deleting files 
> that we otherwise wouldn't need to build? 

My autotools knowledge is rusty so I don't know what else except docs is
included here, but docs is a perfect example of a thing that we normally
*want* to rebuild.



-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: WolfSSL and Netatalk

[Andrey Rakhmatullin]

On Sun, Jun 23, 2024 at 05:58:54AM +, Daniel Markstedt wrote:
> > wolfssl is packaged in Debian, did you try to build netatalk with the
> > packaged version?
> > 
> > Debian doesn't like code copies in sources, so if it builds fine with
> > the packaged version, removing it from the source that ends up in
> > Debian will fix all issues.
> > 
> 
> This is a reasonable request. I did try to build with Debian's WolfSSL 
> libraries last year.
> At the time (September 2023) I concluded that the DES compatibility headers 
> (des.h etc.) were missing altogether from Debian's WolfSSL package, and 
> therefore could not be used for this purpose with Netatalk.

libwolfssl-dev: /usr/include/wolfssl/openssl/des.h

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Re: About i386 support

[Andrey Rakhmatullin]

On Fri, Jun 14, 2024 at 05:53:42AM -0500, r...@neoquasar.org wrote:
> A bug that can't be reproduced, effectively doesn't exist. 
Wow.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Seeking consensus on file conflict between python3-proto-plus and nanopb

[Andrey Rakhmatullin]

On Mon, Jun 10, 2024 at 06:40:02PM -0400, Yogeswaran Umasankar wrote:
> There is a file conflict between python3-proto-plus and nanopb. The
> conflict arises due to both packages has a file at
> /usr/lib/python3/dist-packages/proto/__init__.py [0]. I am maintaining
> python3-proto-plus, and I am seeking guidance.
> 
> The module name "proto" is an integral part of the python3-proto-plus
> package. Renaming the "proto" module in python3-proto-plus would
> significantly impact future dependent packages.
> 
> It appears that nanopb's use of the module name "proto" does not align
> with the conventional identification of a Python module. 

What do you mean? It does look like a Python module to me. It's very
likely that it should be a private one though, but I see you already asked
the maintainer about that.

> I have attempted to reach out to the nanopb maintainer to discuss this
> issue, but I have not yet received a response. In case the maintainer is
> MIA, should I proceed with renaming the "proto" module in nanopb to
> "nanopb-proto"? 

No, it will make it useless.
I don't see a good way forward that doesn't involve NMUing nanopb.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Suggestions about i386 support

[Andrey Rakhmatullin]

On Mon, Jun 10, 2024 at 04:02:54PM +0100, Simon McVittie wrote:
> On Mon, 10 Jun 2024 at 12:43:27 +, Stefano Rivera wrote:
> > The point here is that the Debian project is not intending to support
> > new hardware on the i386 architecture. The architecture is being kept
> > around primarily to support running old i386 binaries.
> 
> ... and the most appropriate answers to some technical questions are not
> going to be the same for "i386 to run legacy 32-bit binaries on 64-bit
> CPUs" and "i386 to run on 32-bit CPUs", so we cannot simply support
> both equally.

Yeah, it should be made clear that if some people want to bring back
proper support for i386 hardware, they will need to make a new port.
Which is of course more complicated than fixing an existing one (but at
least bootstrapping it should be easier than bootstrapping some non-x86
port).

> If people want a distribution to run on 32-bit x86 CPUs badly enough,
> one possible route would be to start a new port (perhaps called ia32,
> i386t64 or something similar) for that use-case; it would have a baseline
> that is as low as its maintainers want it to be (i586?), and a 64-bit
> time_t for post-2038 future-proofing.
> 
> As far as I'm aware, nobody is yet putting effort into doing this. Also,
> several important upstreams no longer consider i386 to be useful (and
> especially i386-without-SSE2), so so the burden of supporting 32-bit
> CPUs in modern software will fall on the downstream developers who have
> chosen that their aim is to support 32-bit CPUs.

I assume such software already has this status on Debian i386 (and so is
either not built there or supported only by the maintainer, or maybe built
with a raised baseline) so there should be no regression here, though
additional packages will get the same status in the future.
Similarly, we already don't build a noticeable number of packages on armel
(and some of them also on armhf) when we build them on arm64.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Enabling some -Werror=format* by default?

[Andrey Rakhmatullin]

On Mon, Jun 10, 2024 at 04:24:54PM +0200, Guillem Jover wrote:
> > Do you think it makes sense to add this a flag that enables -Werror=format
> > to dpkg-buildflags(1), before, or after a test rebuild, before, or after
> > the MBF if we do one?
> 
> If by adding you mean adding a new feature flag that is disabled by
> default, then depending on the feature area, that might unfortunately
> be equivalent to enable it by default (due to the «all» keyword).

Another related question: if not via dpkg-buildflags, how do we do
rebuilds with changed default flags?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Enabling some -Werror=format* by default?

[Andrey Rakhmatullin]

On Mon, Jun 10, 2024 at 04:24:54PM +0200, Guillem Jover wrote:
> > > > We recently increased the time_t size on certain architectures and some
> > > > packages started failing to build because they were using a format
> > > > specifier too narrow for the wider time_t, e.g. #1067829.
> > > > But the only reason those package FTBFS is they enable either -Werror or
> > > > some more specific non-default switch like -Werror=format=2, so I 
> > > > suspect
> > > > much more packages contain similar code but gained only a warning. Isn't
> > > > this a bad thing? Should we enable at least some combination of 
> > > > -Wformat*
> > > > switches by default? Should we at least add a new flag to 
> > > > dpkg-buildflags
> > > > and do some test rebuilds with it enabled?
> > > 
> > > It wasn't quite clear to me what -Werror=format=2 actually means.
> > > According to the gcc documentation[1], -Wformat=2 currently means:
> > > 
> > > -Wformat -Wformat-nonliteral -Wformat-security -Wformat-y2k.
> 
> Those are in addition to the ones enabled by -Wformat=1, which are:

(note that -Wformat is already included in that list)

>   -Wnonnull -Wno-format-contains-nul -Wno-format-extra-args
>   -Wno-format-zero-length

(note that -Wformat is not equal to these flags, it just implies -Wnonnull
and those three -Wno-* can be used to turn off some parts of it)


> In general I think it's good (in principle) to enable -Werror flags
> that detect actual bugs in code, the problem is always going to be
> the amount of fallout and work that creates, and whether there's
> consensus about that work commitment being acceptable to maintainers
> in Debian, or whether that can interfere with transitions going on,
> etc.

Yeah.

> > > It also is unclear how this impacts the archive and yes, I'd recommend a
> > > rebuild. Note though that we likely need this rebuild both on a 64bit
> > > architecture and a 32bit architecture that is not i386 (due to how t64
> > > works). A partial archive rebuild may work to gauge the size of the
> > > problem.
> > > 
> > > I note that this kind of change affects cross builds, so performing
> > > cross builds for armhf on amd64 will likely show many of these failures
> > > (in addition to all the regular cross build failures).
> > > 
> > > I recommend doing more research before moving forward with this. In
> > > particular a MBF about introduced problems would be prudent before doing
> > > the switch and even if we don't switch, such a MBF bears value on its
> > > own.
> 
> > Do you think it makes sense to add this a flag that enables -Werror=format
> > to dpkg-buildflags(1), before, or after a test rebuild, before, or after
> > the MBF if we do one?
> 
> If by adding you mean adding a new feature flag that is disabled by
> default, then depending on the feature area, that might unfortunately
> be equivalent to enable it by default (due to the «all» keyword).

That's a good point, though hopefully people who use "all" understand the
implication...

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Enabling some -Werror=format* by default?

[Andrey Rakhmatullin]

On Mon, Jun 10, 2024 at 07:48:59AM +0200, Helmut Grohne wrote:
> > We recently increased the time_t size on certain architectures and some
> > packages started failing to build because they were using a format
> > specifier too narrow for the wider time_t, e.g. #1067829.
> > But the only reason those package FTBFS is they enable either -Werror or
> > some more specific non-default switch like -Werror=format=2, so I suspect
> > much more packages contain similar code but gained only a warning. Isn't
> > this a bad thing? Should we enable at least some combination of -Wformat*
> > switches by default? Should we at least add a new flag to dpkg-buildflags
> > and do some test rebuilds with it enabled?
> 
> It wasn't quite clear to me what -Werror=format=2 actually means.
> According to the gcc documentation[1], -Wformat=2 currently means:
> 
> -Wformat -Wformat-nonliteral -Wformat-security -Wformat-y2k.
> 
> Of these, we already enable -Werror=format-security, but not the other
> ones. It is not clear to me, which of these actually catches the the
> type mismatches. Would you do more research here?

#include 

void foo()
{
printf("%d", 0L);
}

This produces a warning with just -Wformat ("format ‘%d’ expects argument
of type ‘int’, but argument 2 has type ‘long int’ [-Wformat=]"). It
doesn't look like any more narrow options for this exist (-Wno-* ones
listed in the -Wformat description don't silence this one, and they don't
look like they should anyway).

But I don't know if even -Werror=format is too much to enable by default
globally (I assume it's a good thing to enable it, though).

> It also is unclear how this impacts the archive and yes, I'd recommend a
> rebuild. Note though that we likely need this rebuild both on a 64bit
> architecture and a 32bit architecture that is not i386 (due to how t64
> works). A partial archive rebuild may work to gauge the size of the
> problem.
> 
> I note that this kind of change affects cross builds, so performing
> cross builds for armhf on amd64 will likely show many of these failures
> (in addition to all the regular cross build failures).
> 
> I recommend doing more research before moving forward with this. In
> particular a MBF about introduced problems would be prudent before doing
> the switch and even if we don't switch, such a MBF bears value on its
> own.
Do you think it makes sense to add this a flag that enables -Werror=format
to dpkg-buildflags(1), before, or after a test rebuild, before, or after
the MBF if we do one?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Suggestions about i386 support

[Andrey Rakhmatullin]

On Sun, Jun 09, 2024 at 08:39:27PM -0500, r...@neoquasar.org wrote:
> >> It's not just a matter of "buy something better." That's easy.  
> 
> >Indeed, that is easier and cheaper.
> 
> Of course, continuing to use a system I already have is cheaper still.
> 
> > What's not easy is that a) that adds another machine to the waste 
> > stream, instead of continuing to get use from it, and b) someone has 
> > to take the time to set up the new machine, test things, migrate 
> > services, etc. to functionally replace the old one. That takes time 
> > and effort, too, multiplied by the number of such systems out there.  
> 
> > (a) is false as newer hardware can already be taken from electronic waste, 
> > so it does not add new waste.
> 
> That is a gross overstatement. Electronics are NOT 100% recyclable. A fair 
> amount of material still goes to waste, and there are all kinds of costs 
> associated with those processes. 
> 
> Reuse is better than recycle for complex things like electronics. 
You were suggested to resuse an old amd64 machine.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Illegal Instruction Using sudo in Bookworm on i686

[Andrey Rakhmatullin]

On Sun, Jun 09, 2024 at 06:56:00AM -0500, rhys wrote:
> The question right now is:  Is this processor supported at all?
No.

> So given that these no longer fit the "old and busted" description, is Debian 
> going to stick with the decision to not support them?
I'm sure we will, yes, though I'm not in a position to decide that.

> Or is Debian going to continue to support this processor, since it is still 
> apparently a viable product, enough that new systems are using it?
Considering the plans for i386 I don't think it makes sense to even ask
this question?

> Only after that issue is addressed does anyone need to worry about sudo.  
> Depending on the answer, that is.
Yes, this indeed looks like one of those "why you don't support my CPU"
threads not specific to any software.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Enabling some -Werror=format* by default?

[Andrey Rakhmatullin]

We recently increased the time_t size on certain architectures and some
packages started failing to build because they were using a format
specifier too narrow for the wider time_t, e.g. #1067829.
But the only reason those package FTBFS is they enable either -Werror or
some more specific non-default switch like -Werror=format=2, so I suspect
much more packages contain similar code but gained only a warning. Isn't
this a bad thing? Should we enable at least some combination of -Wformat*
switches by default? Should we at least add a new flag to dpkg-buildflags
and do some test rebuilds with it enabled?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Mandatory LC_ALL=C.UTF-8 during package building

[Andrey Rakhmatullin]

On Thu, Jun 06, 2024 at 12:08:17PM +0200, Johannes Schauer Marin Rodrigues 
wrote:
> Or whether we should switch the default and require that d/rules is run in an
> environment (for example as set-up by dpkg-buildpackage) where these variables
> are set?
(a previous discussion on this:
https://lists.debian.org/debian-devel/2017/10/msg00317.html)



-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: changing existing entries in debian/changelog

[Andrey Rakhmatullin]

On Fri, May 24, 2024 at 09:30:44AM +0200, Bastian Venthur wrote:
> I'm having troubles finding the relevant parts in the developers reference.
> I've uploaded a version to experimental and later found out that this
> version fixes several bugs.
> 
> Can I rewrite existing changelog entries for already uploaded versions with
> the next upload, i.e. by adding the relevant "closes" line to the previsions
> version?
You can if you want but it won't close the bugs, you'll still need to
close them properly with manual action. SO it may be easier to just not
edit them.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: finally end single-person maintainership

[Andrey Rakhmatullin]

On Wed, May 22, 2024 at 09:11:16PM +0200, Bernd Zeimetz wrote:
> > > You can run autopkgtests locally, you do not need Salsa for that.
> > 
> > Also, Debian runs autopkgtests on all packages that provide them, and
> > makes passing them on all supported architectures a requirement for 
> > testing migration.
> 
> Uploading to check autopkgtests is an absolute waste of ressources. I
> really hope nobody uploads a package without running the tests
> somewhere else.
> 
> > 
> > It could be argued that testing migration is a CI process.
> > 
> 
> Its a CI process at a way too late stage.
> Also, uploading to test a merge request is not the right thing to do.
If the archive is a VCS then uploading an untested package to experimental
to run tools is pushing a commit to run CI.
*shrug*

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: finally end single-person maintainership

[Andrey Rakhmatullin]

On Wed, May 22, 2024 at 12:32:32AM +0200, Salvo Tomaselli wrote:
> And what's the advantage? When an nmu happens the person doing it normally 
> doesn't bother to push to salsa anyway. 
Yes, because it's unfortunately too expensive to:
- make sure the repo exists and is uptodate
- somehow find out what workflow does the repo imply
- if it's an unfamiliar one then somehow learn it
- check if there are no commits on top of the previous upload and if there
  are any then how to merge them with the NMU changes
- check that your commit builds correctly
at least when doing more than one NMU per week or whatever.
The nmudiff(1) interface is standardized, one command does everything, you
are still required to use it, and you need to remember that MRs don't give
notifications so you have an additional reason to use it, and importing a
nmudiff should be easy for the maintainer.

> At most I get a patch in the 
> bugreport, or I have to diff the packages and import the diff.
Sending the nmudiff to the bugreport is mandatory per the devref NMU
procedure (though of course that procedure itself is not a policy and not
everyone follows it).

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

[Andrey Rakhmatullin]

On Tue, May 21, 2024 at 08:45:50PM +0900, Simon Richter wrote:
> Hi,
> 
> On 5/21/24 15:54, Andrey Rakhmatullin wrote:
> 
> > > The Debian archive itself is a VCS, so git-maintained packaging is also a
> > > duplication, and keeping the official VCS and git synchronized is causing
> > > additional work for developers, which is why people are opposed to having 
> > > it
> > > mandated.
> 
> > The Debian archive itself is a *bad* and *poor* VCS. It should be obvious
> > in which areas it's poor, and it's bad e.g. because force pushes are
> > enabled, the history is periodically truncated (though there is no easy
> > way to get it anyway) etc.
> 
> All of these things are *also* explicit features. We need a way to unpublish
> things, and mirrors only want to keep a shallow subset.
We don't have a way to unpublish things, and force pushes I meant are
uploading things without including all previous changes, like all those
NMUs silently not included in the next maintainer uploads.
But, sure, some of the problems we have are explicitly features.

> Representing the Debian archive in git would probably look like a massive
> amount of submodules, because that's the only way to represent state across
> multiple projects without extending it 
Sorry? I don't understand what you would use submodules for. Unless you
meant literally mapping archive-as-VCS to a single literal VCS repo?


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: finally end single-person maintainership

[Andrey Rakhmatullin]

On Tue, May 21, 2024 at 12:05:59PM +0200, Philip Hands wrote:
> >> > All these things should make it much more easy for other people or
> >> > automated tools to send merge requests or keep maintaining a
> >> > package in
> >> > case the original maintainer becomes MIA.
> >> 
> >> 
> >> Mandating a specific git layout is a big jump from not requiring a
> >> VCS at all. 
> >
> > yes, its a big jump, but we are in 2024 and a modern workflow should be
> > expected from a modern distribution.
> 
> Attempts at top-down imposition of new methods on Debian strike me as
> being unlikely to induce joy in anyone involved.
> 
> After all, We're a self-selecting group of people who are prone to
> repeatedly walking the road less travelled.
> 
> Do we even have a consensus on which layout is "best"?
Definitely no.
Also all of them are bad in some way, which is expected when you wrap
incompatible workflows.

> For anyone with an opinion, I'd suggest that you should try to make sure
> that DEP-14 reflects your opinion, and then work on getting people to
> adopt the use of DEP-14 and/or get DEP-14 accepted.
How do you envision this for people who are against storing upstream
sources in the repo? Having two mutually exclusive options in DEP-14?


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

[Andrey Rakhmatullin]

On Mon, May 20, 2024 at 04:11:02AM +0900, Simon Richter wrote:
> > My concern about Gitlab is not its *additions* to existing services, but
> > its *duplications* of core services already in Debian.
> 
> I agree, that's the key problem.
> 
> The Debian archive itself is a VCS, so git-maintained packaging is also a
> duplication, and keeping the official VCS and git synchronized is causing
> additional work for developers, which is why people are opposed to having it
> mandated.
The Debian archive itself is a *bad* and *poor* VCS. It should be obvious
in which areas it's poor, and it's bad e.g. because force pushes are
enabled, the history is periodically truncated (though there is no easy
way to get it anyway) etc.
It makes sense that some people want to replace it with a good VCS, but I
agree that adding a good VCS only gives us two VCSes because replacing
will never happen.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: finally end single-person maintainership

[Andrey Rakhmatullin]

On Tue, May 21, 2024 at 12:32:52AM +0200, Bernd Zeimetz wrote:
> > > All these things should make it much more easy for other people or
> > > automated tools to send merge requests or keep maintaining a
> > > package in
> > > case the original maintainer becomes MIA.
> > 
> > 
> > Mandating a specific git layout is a big jump from not requiring a
> > VCS at all. 
> 
> yes, its a big jump, but we are in 2024 and a modern workflow should be
> expected from a modern distribution.
People will resign.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: About i386 support

[Andrey Rakhmatullin]

On Mon, May 20, 2024 at 07:16:54PM -0300, Leandro Cunha wrote:
> > > > which is good news. The end of support for 32 bits will not
> > > > affect the lives of almost anyone who has machines purchased after
> > > > 2011 and who bought them after that
> > >
> > > Does this also mean he support for armhf will be dropped ?
> > There is no "end of support for 32 bits" yet so no.
> When you refer to 32 bits you are referring to i386 (see the subject),
No, please don't, this confuses people.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: About i386 support

[Andrey Rakhmatullin]

On Mon, May 20, 2024 at 10:57:58PM +0200, William Bonnet wrote:
> > which is good news. The end of support for 32 bits will not
> > affect the lives of almost anyone who has machines purchased after
> > 2011 and who bought them after that
> 
> Does this also mean he support for armhf will be dropped ?
There is no "end of support for 32 bits" yet so no.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Any volunteers for lintian co-maintenance?

[Andrey Rakhmatullin]

On Sun, May 19, 2024 at 12:49:29PM +0200, Andreas Tille wrote:
> > It also fails as an archive QA tool in my view since the FTP masters have
> > been unwilling to upgrade to any recent version of lintian.
> 
> Perhaps a ftpmaster could explain this in detail. As far as I understand,
> it's also a DSA issue. All packages are obtained from stable.
Per e.g. the discussion on #debian-devel on 2024-04-01, this specific
package is older than even that. Per the same discussion, we don't have
(or at least couldn't find) an *official* reason for that, only
speculation.
But, sure, running lintian from stable on packages for unstable can also
cause problems up to autorejects.

> > As a consequence,
> > people now get auto-rejects when uploading because lintian on the FTP master
> > server does not produce the same output as current lintian in stable or
> > newer.
> 
> I think its a bit unfair to blame lintian about the fact that its old
> versions do not do a proper job when it comes to checking newer packages.
Yes.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Re: Suggestions about i386 support

[Andrey Rakhmatullin]

On Sun, May 19, 2024 at 09:09:10AM +, defrag mentation wrote:
> > What will this solve?
> 
> > I don't think this is "needed"? Unless you think all i386 packages will be
> 
> removed from Debian, which is not the plan?
> 
> Case 1: Debian removed i386 DVDs/BDs, and someone jigdo backed the full amd64 
> DVDs/BDs set will be surprised that it do not contain wine32.
This isn't specific to wine.

> > Debian wine is not the only thing we want i386 libraries for.
> 
> What are they?
Non-Debian Wine (e.g. Proton), legacy native apps, probably other non-Wine
wrappers.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Suggestions about i386 support

[Andrey Rakhmatullin]

On Sun, May 19, 2024 at 07:26:28AM +, defrag mentation wrote:
> I think some of the i386 support policies needs to be reconsidered.
> 
> Here are some suggestions:
> 
> 1. ​Move Wine-32 to amd64, and Wine-32 may be compiled to 64-bit time_t.
What will this solve?

> Wine-32 is now in currently dropped i386 DVDs/BDs, not in amd64 DVDs/BDs as 
> it is multiarch-only now, so at least I think moving it to amd64 is needed.
I don't think this is "needed"? Unless you think all i386 packages will be
removed from Debian, which is not the plan?

> 3. For future i386 support:
> 
> If there are not enough human resources, i386 can be dropped completely as 
> Wine-32 is moved to amd64 
Debian wine is not the only thing we want i386 libraries for.

> If someone wants to continue maintaining pure 32-bit device bootable i386, I 
> think recompiling it to be Y2038-safe is still meaningless 
And nobody proposed it.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Any volunteers for lintian co-maintenance?

[Andrey Rakhmatullin]

My 1.83 RUB:

lintian is one of those things that are very important and useful when you
know how to use them, which quirks to apply and which parts to ignore, and
without that knowledge are maybe useful, maybe useless, maybe harmful, and
nobody will tell you that knowledge unless you ask directly. It's also a
mandatory part of the infra and workflows, yet it's mostly unmaintained,
somewhat bitrotten and in part a victim of unfortunate decisions of
previous maintainers. This is a very weird and paradoxical state which
also in a large part relects the state of Debian as a whole (luckily, only
in a part, not completely). 

Random examples:
- The most paradoxical thing is the recently "discovered" combination of
  "old lintian falsely reports a problem in certain packages", "lintian
  runs as a part of the package acceptance process and some problems are
  autorejects", "people are supposed to run lintian from sid for packages
  in sid", "specifically *old* lintian runs as a part of the package
  acceptance process" and "that lintian can't be upgraded because new one
  is too slow". 
- To get full lintian output you need to run it against binary .changes,
  not against a .deb, a .dsc or a source .changes. And you should run it
  with a bunch of args enabling lower-severity tags, because some of
  those are useful. Newer people don't know that even if they know about
  lintian. Those that don't know will see lintian output when they upload
  their package to mentors, and which subset they will see depends on
  which .changes they upload.
- lintian tags have descriptions (it's still unclear to me how obvious is
  that). The most straightforward ways to read them are googling them if
  you run lintian locally and clicking links if you look at e.g. mentors. 
  But lintian.debian.org is dead. There are also lintian -i and
  lintian-explain-tags but it's unclear how to learn about them, at least
  without reading all of lintian(1).
- It's impossible to know beforehand which tags you need to address now,
  which you should address now or some time in the future, which are
  irrelevant and which must not be followed because they are wrong (in
  general or are false positives). Severity is also often not correlated
  with this. My go-to advice for sponsored uploads is "fix whatever your
  sponsor asks you to fix" and I won't publish my advice for direct
  uploads which I follow myself.

As a bottom line, it's clearly not good enough for the role it currently
plays and is becoming worse instead of becoming better, but we don't have
a replacement and it needs a lot of man-hours to go back on track. 

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Andrey Rakhmatullin]

On Tue, May 07, 2024 at 09:49:17PM +0200, Johannes Schauer Marin Rodrigues 
wrote:
> Quoting Andrey Rakhmatullin (2024-05-06 19:14:40)
> > On Mon, May 06, 2024 at 04:50:50PM +0100, Barak A. Pearlmutter wrote:
> > > > tmpfiles.d snippets can be defined to cleanup on a timer _anything_,
> > > 
> > > It's a question of what the *default* behaviour should be.
> > > 
> > > For whatever reason, a lot of people who process large data use
> > > /var/tmp/FOO/ as a place to store information that should not be
> > > backed up, but also should not just disappear.
> > To be honest I'm greatly surprised by this idea, and by the suggestion
> > that a lot of people do this, to me this is very similar by that half-joke
> > about people storing useful files in the Recycle Bin.
> 
> I'm doing exactly that. I use paper I already printed stuff on but which were
> misprints or which are no longer useful to me and are just destined for the
> recycling bin to write stuff on that is important to me. After I'm done with 
> my
> work on this scrap paper I decide what I want to keep and copy to permanent
> storage and what I want to really throw away.
I actually meant the Windows feature :)


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: how to upgrade testing

[Andrey Rakhmatullin]

On Tue, May 07, 2024 at 08:54:39PM +0200, Jérémy Lal wrote:
> could we have a hint when it's "safe" to upgrade testing ?
It was always safe...

> Currently I get for a full-upgrade:
> 2338 mis à jour, 362 nouvellement installés, 715 à enlever et 41 non mis à
> jour.
alias e='LC_ALL=C'
e apt full-upgrade

But also if apt wants to remove some things you need then you may need to
upgrade some packages manually or install some *t64 libs manually, just
like in sid in March.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Andrey Rakhmatullin]

On Tue, May 07, 2024 at 04:24:06PM +0300, Hakan Bayındır wrote:
> On the other hand, if we need to change the configuration 99% of the time,
[citation needed]




-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Andrey Rakhmatullin]

On Mon, May 06, 2024 at 04:50:50PM +0100, Barak A. Pearlmutter wrote:
> > tmpfiles.d snippets can be defined to cleanup on a timer _anything_,
> 
> It's a question of what the *default* behaviour should be.
> 
> For whatever reason, a lot of people who process large data use
> /var/tmp/FOO/ as a place to store information that should not be
> backed up, but also should not just disappear.
To be honest I'm greatly surprised by this idea, and by the suggestion
that a lot of people do this, to me this is very similar by that half-joke
about people storing useful files in the Recycle Bin.
But I also thought that "/tmp is on tmpfs, /var/tmp isn't, and that's
their main difference" are our defaults for years, when they apparently
aren't (now I understand why people sometimes suggest using /dev/shm or
/run for this or that to increase performance).

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Andrey Rakhmatullin]

On Mon, May 06, 2024 at 07:42:11AM -0700, Russ Allbery wrote:
> >> I'm not sure if we have software on long running servers which place
> >> files in /tmp and /var/tmp and expect files to not be deleted during
> >> runtime, even if not accessed for a long time. This is certainly an
> >> issue to be aware of and keep an eye on.
> 
> > Note that FHS mandates it for /var/tmp: "Files and directories located
> > in /var/tmp must not be deleted when the system is booted. Although data
> > stored in /var/tmp is typically deleted in a site-specific manner, it is
> > recommended that deletions occur at a less frequent interval than /tmp."
> 
> It mandates that it not be cleaned on *boot*.  Not that it never be
> cleaned during runtime.  
Ah, I've read that as "while the system is booted".


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Andrey Rakhmatullin]

On Mon, May 06, 2024 at 10:40:00AM +0200, Michael Biebl wrote:
> I'm not sure if we have software on long running servers which place files
> in /tmp and /var/tmp and expect files to not be deleted during runtime, even
> if not accessed for a long time. This is certainly an issue to be aware of
> and keep an eye on.
Note that FHS mandates it for /var/tmp: "Files and directories located in
/var/tmp must not be deleted when the system is booted. Although data
stored in /var/tmp is typically deleted in a site-specific manner, it is
recommended that deletions occur at a less frequent interval than /tmp."




-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Status of the t64 transition

[Andrey Rakhmatullin]

On Sun, Apr 28, 2024 at 02:28:30PM +0200, Paul Gevers wrote:
> > Can you please look at libproxy<->glib-networking? libproxy excuses show
> > glib-networking tests failing, but they are working in sid.
> 
> And that's not missing a versioned Depends and/or Breaks? I.e. this is a
> test only failure?
I'm not a maintainer of either of them and I couldn't understand from the
test failure what's the reason of it. 
Jeremy, can you please look at it and help it migrate?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Status of the t64 transition

[Andrey Rakhmatullin]

On Wed, Apr 24, 2024 at 07:38:42PM +0200, Paul Gevers wrote:
> Hi,
> 
> On 24-04-2024 7:35 p.m., Andrey Rakhmatullin wrote:
> > What to do with autopkgtests that fail in testing because of problems with
> > packages in testing that are fixed in unstable, e.g. the autopkgtest for
> > speech-dispatcher/0.11.5-2 on
> 
> Inform the Release Team and we can either schedule the combination manually,
> add a hint or both.
Can you please look at libproxy<->glib-networking? libproxy excuses show
glib-networking tests failing, but they are working in sid. 


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Status of the t64 transition

[Andrey Rakhmatullin]

On Wed, Apr 24, 2024 at 08:51:48AM +0200, Sebastian Ramacher wrote:
> If you wonder how you are able to help with the migration, here are
> some things to do:
> * Fix FTBFS bugs
> * Check the status of autopkgtests [1] and report or fix any issues
>   related to failing tests.
> * Check if source-only uploads for Arch: all packages are missing.
What to do with autopkgtests that fail in testing because of problems with
packages in testing that are fixed in unstable, e.g. the autopkgtest for
speech-dispatcher/0.11.5-2 on
https://qa.debian.org/excuses.php?package=glib2.0?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Status of the t64 transition

[Andrey Rakhmatullin]

Lists updated to omit packages not in testing:

On Thu, Apr 18, 2024 at 09:22:02PM +0200, Sebastian Ramacher wrote:
> Let's start with the first category. Those are packages that could be
> binNMUed, but there are issues that make those rebuilds not have the
> desired effect. This list include packages that
>  * are BD-Uninstallabe,
>  * FTBFS but with out ftbfs-tagged RC bug,
>  * have hard-coded dependencies on pre-t64 libraries,
>  * have $oldlib | $newlib dependencies (those are at least wrong on
>armel/armhf and violate policy 2.2.1 once the pre-t64 libraries are
>decrufted),
>  * have been rebuilt before all dependencies were built,
>  * have broken symbols/shlibs files producing incorrect dependencies,
>  * or might just be missing the binNMU (but those should be few).

(52 packages out of 78)

arctica-greeter
cegui-mk2
condor
deepin-movie-reborn
fastnetmon
gentle
gocryptfs
gtk-chtheme
haskell-gi-dbusmenugtk3
haskell-gi-gtk
haskell-gi-gtk-hs
haskell-gi-vte
haskell-gtk-strut
hugin
jellyfish
lcmaps-plugins-basic
lcmaps-plugins-verify-proxy
lcmaps-plugins-voms
libcanberra
libosmo-netif
lightdm
lightdm-gtk-greeter
light-locker
limesuite
llvm-toolchain-17
lmms
lyskom-server
nautilus-wipe
nfs-ganesha
ppp
prelude-lml
prelude-manager
purple-xmpp-carbons
purple-xmpp-http-upload
python-escript
qt5-ukui-platformtheme
quorum
rtags
sdpa
seafile-client
slick-greeter
sonic-visualiser
spectrwm
spice-gtk
swtpm
tfortune
trantor
ukui-greeter
urfkill
vdeplug-pcap
vdeplug-slirp
xca


> Next, packages that need an upload since they build Architecture: all
> binaries depending on pre-t64 libraries:
(9 packages out of 13)

alsa-ucm-conf
jruby
mandos
python-pylibdmtx
pyzbar
rapid-photo-downloader
ruby-ethon
ruby-ffi-libarchive
sbmltoolbox


> Finally, packages that need rebuilds but currently have open FTBFS (RC +
> ftbfs tag) bugs:
(57 packages out of 221)

3dchess
acm
adns
barrier
blasr
cctools
clanlib
code-saturne
das-watchdog
deepin-log-viewer
dub
dvbstreamer
epic4
epic5
eterm
freebayes
gnome-breakout
google-compute-engine-oslogin
gtkterm
gyoto
hping3
hplip
httest
isoquery
kamailio
kdrill
kexec-tools
klatexformula
kluppe
lftp
linssid
linuxtv-dvb-apps
llvm-toolchain-16
loqui
matchbox-keyboard
matchbox-panel
mdbtools
mlpcap
moonshot-ui
ncrack
netdiag
nitrokey-app
pesign
pidgin-sipe
porg
projecteur
raku-readline
s390-tools
siridb-server
slrn
spek
tcptrack
tightvnc
tlog
veusz
wmweather+
xpra


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Status of the t64 transition

[Andrey Rakhmatullin]

All missing bugs about wrong deps are now filed.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Status of the t64 transition

[Andrey Rakhmatullin]

On Thu, Apr 18, 2024 at 09:22:02PM +0200, Sebastian Ramacher wrote:
> Let's start with the first category. Those are packages that could be
> binNMUed, but there are issues that make those rebuilds not have the
> desired effect. This list include packages that
>  * are BD-Uninstallabe,
>  * FTBFS but with out ftbfs-tagged RC bug,
>  * have hard-coded dependencies on pre-t64 libraries,
>  * have $oldlib | $newlib dependencies (those are at least wrong on
>armel/armhf and violate policy 2.2.1 once the pre-t64 libraries are
>decrufted),
>  * have been rebuilt before all dependencies were built,
>  * have broken symbols/shlibs files producing incorrect dependencies,
>  * or might just be missing the binNMU (but those should be few).
> 
> 3depict
BD-Uninstallable (mathgl FTBFS)
> arctica-greeter
fixed recently
> cegui-mk2
not sure?
> condor
not sure?
> courier
FTBFS without a bug, filed
> deepin-movie-reborn
not sure?
> fastnetmon
not sure?
> fcitx-kkc
BD-Uninstallable (libkkc FTBFS)
> gentle
not sure?
> gnome-subtitles
FTBFS without a bug, filed
> gocryptfs
FTBFS without a bug, filed
> gozer
BD-Uninstallable (giblib FTBFS)
> gtk-chtheme
fixed recently
> gvmd
not sure?
> gxneur
BD-Uninstallable (xneur FTBFS)
> haskell-gi-dbusmenugtk3
BD-Uninstallable (haskell-gi-gtk FTBFS)
> haskell-gi-gtk
FTBFS without a bug, filed
> haskell-gi-gtk-hs
BD-Uninstallable (haskell-gi-gtk FTBFS)
> haskell-gi-vte
BD-Uninstallable (haskell-gi-gtk FTBFS)
> haskell-gtk-strut
BD-Uninstallable (haskell-gi-gtk FTBFS)
> hkl
BD-Uninstallable (datatype99 FTBFS)
> hugin
not sure?
> hxtools
Dep-Wait on libhx
> ibus-kkc
BD-Uninstallable (libkkc FTBFS)
> ippsample
not sure?
> jellyfish
not sure?
> jskeus
FTBFS without a bug, filed
> lcmaps-plugins-basic
fixed recently
> lcmaps-plugins-jobrep
fixed recently
> lcmaps-plugins-verify-proxy
fixed recently
> lcmaps-plugins-voms
fixed recently
> libcanberra
not sure?
> libosmo-netif
not sure?
> lightdm
fixed recently
> lightdm-gtk-greeter
fixed recently
> light-locker
fixed recently
> limesuite
not sure?
> llvm-toolchain-17
not sure?
> lmms
FTBFS, bug in wine
> lyskom-server
BD-Uninstallable (adns FTBFS)
> massxpert2
BD-Uninstallable (libpappsomspp FTBFS)
> nautilus-wipe
not sure?
> ncl
not sure?
> nfs-ganesha
BD-Uninstallable (ceph dropped 32bit)
> obs-advanced-scene-switcher
not sure?
> openjdk-20
BD-Uninstallable (wrong BD without a bug, filed)
> perdition
not sure?
> ppp
FTBFS
> prads
not sure?
> prelude-lml
BD-Uninstallable (libprelude FTBFS)
> prelude-manager
BD-Uninstallable (libprelude FTBFS)
> purple-xmpp-carbons
not sure?
> purple-xmpp-http-upload
not sure?
> python-escript
FTBFS (pmix dropped 32bit?)
> qt5-ukui-platformtheme
not sure?
> quorum
not sure?
> renpy
BD-Uninstallable (pygame-sdl2 FTBFS)
> roger-router
BD-Uninstallable (librm bug)
> rtags
FTBFS without a tag, tagged
> sdpa
Dep-Wait (mumps FTBFS because pmix dropped 32bit?)
> seafile-client
not sure?
> slick-greeter
fixed recently
> sonic-visualiser
FTBFS without a bug, filed
> spectrwm
not sure?
> spice-gtk
not sure?
> swtpm
not sure?
> tfortune
not sure?
> thunderbird
not sure?
> trantor
fixed recently
> ui-gxmlcpp
not sure?
> ukui-greeter
fixed recently
> urfkill
not sure?
> vdeplug-pcap
not sure?
> vdeplug-slirp
not sure?
> wine-development
FTBFS without a bug, filed
> worker
Dep-Wait (avfs FTBFS)
> xbase64
not sure?
> xca
FTBFS without a tag, tagged


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: finally end single-person maintainership

[Andrey Rakhmatullin]

On Sat, Apr 13, 2024 at 10:08:07AM +0200, Andreas Tille wrote:
> > For example, any repository that does not list debian/files and
> > debian/*.substvars in the gitignore will fail to build twice in a row,
> > because these files are created and are subsequently untracked.
> 
> Sorry, no.  We should teach people to build in a chroot which does
> not leave this stuff inside local debian/ dir.
I was afraid that's what "or we make people reliant on a magic tool to set
it up properly for them" means.
(technically, the way to not touch the workdir at all is gbp's
--export-dir, which *is* a magic mode of a magic tool in the world where
neither are parts of the default workflow but at the same time it's so
much better than not doing this)

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: finally end single-person maintainership

[Andrey Rakhmatullin]

On Tue, Apr 09, 2024 at 07:43:04PM +0200, Johannes Schauer Marin Rodrigues 
wrote:
> > And I do just prefer having two directories rather than multiple
> > version on top of each other. My simple brain finds it a lot easier to
> > keep track of a version directory to diff between, rather than finding
> > the right runes to get git to give meld faked-up directories pointing
> > at revisions or branches.
> 
> I found this paragraph really interesting because reading your other emails I
> was wondering "well but how else do you do it then??" :D Maybe this is just
> muscle memory? Your directories are just my git branches. Instead of "cd
> ../source-verX" I'd do "git switch verX". Personally, I find git branches
> superior to directories because the git commit messages in each branch allow 
> me
> to describe what this feature-branch is doing much better than a directory 
> name
> could. A stack of commits in a branch allows me to trace back what changes I
> did in what order when I worked on a feature. By pushing the branches to 
> salsa,
> I enable collaboration on my work by doing not much more than running "git 
> push
> --set-upstream origin myfeature".
And of course git can emulate the other workflow using git-worktree.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: finally end single-person maintainership

[Andrey Rakhmatullin]

On Tue, Apr 09, 2024 at 05:52:43PM +0100, Wookey wrote:
> Right - this was (one of the) main thing(s) that annoyed me enough to
> just go back to the non-git based workflow. I want to make changes and
> try them. I don't want to have to commit every damn time - it's not
> done yet - I'll commit it after I'm satisfied that it works. But I
> don't know that until I've made a whole set of changes and it builds.
> 
> So now I've got a pile of changes which should really be separate
> commits and logically separate things often affect the same files, and
> even the same lines, so really I need to commit some chunks and not
> others and tidy it all up. Yes this makes a nice set of commits but
> it's _so_ much work in comparison to just editing the damn files, and
> then effectively doing one fat 'commit' when I dupload. Often
> something ends up stalled for weeks or months or years because I've
> got some chunks in the wrong places and sorting it out is painful, so
> I go do something else and lose all my state. You all know how that
> goes...
Again, you don't need to commit anything to test it, so you can use
whatever commit style is fine, including one fat commit before dupload.
You may mean that doing this provides no benefit over not using git, which
isn't really true.

> Also what do you git people do to replace uscan? 
gbp import-orig --uscan

> git world seems to make this way more complicated. I have to set up
> two different repos - one for salsa one for upstream, then pull them,
> maybe into different branches, and fight the diff config to let me
> dirdiff two different commits. And the upstream pull will always pull
> changes, not just only do it is there is an actual release (tag).
You don't need to do that, you can't do that with upstreams that don't use
git and some (probably all?) teams forbid that.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: finally end single-person maintainership

[Andrey Rakhmatullin]

On Mon, Apr 08, 2024 at 09:44:55PM +0900, Simon Richter wrote:
> > I don't mind what other people do, but I worry that conversations like
> > this seem to take the new thing as so self-evidently better that
> > no-one can reasonably complain about them being made a
> > requirement. Well, we don't all think it's better, and I wouldn't
> > enjoy seeing 'packages must be in Salsa' made a requirement, for
> > example.
> 
> What people seem to be missing is that the Debian archive *is* a version
> control system.
We are not missing it.

> Stacking another VCS on top of it leads to a lot of annoying artifacts,
> because there is no sensible metadata mapping between them -- what is
> metadata in Debian becomes data in git, and another metadata layer is added
> on top of that, and what is data in Debian must be run through a filter to
> make it accessible to git for efficient handling, so part of it gets
> converted to metadata.
> 
> The result is... not ideal, because the resulting workflow is neither a
> Debian nor a git workflow, but a mix that requires users to be aware of the
> state of two systems at the same time.
We know, and we are sad about this, but we see the benefits it brings so
we tolerate the rough edges and data duplication and hope for a better
future when the workflows are improved.
Some of us make proposals for better workflows from time to time but this
is Debian.

> Testing a package requires me to commit everything into git first, so I
> have to remember to squash all these commits later.\
At least gbp doesn't require anything like this (unless your "testing"
requires Salsa CI which is another story).

> What would make sense would be a git based format that is designed around
> the requirements for package maintenance, and where internal consistency can
> be enforced by upload hooks -- for example by storing metadata out-of-band
> in a separate branch.
We know. It was rejected as Debian doesn't want to store random data as a
part of a repo history because of DFSG, or something like that.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: xz backdoor

[Andrey Rakhmatullin]

On Tue, Apr 02, 2024 at 11:49:50AM +0200, Francesco P. Lovergine wrote:
> Speaking about that, I'm a simple guy: how can anyone trust
> sources signed by an unsigned-gnupg-key committer (I mean both the
> actors of this tragically ridicolous drama)? In 2024. Really?
As opposed to sources not signed by any key at all?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Firmwares (was Re: Bits from the DPL)

[Andrey Rakhmatullin]

On Mon, Apr 01, 2024 at 06:27:29PM +0200, Vincent Bernat wrote:
> On 2024-04-01 18:05, Jonathan Carter wrote:
> > The included firmware contributed to Debian 12 being a huge success,
> > but it wasn't the only factor.
> 
> Unfortunately, the shipped firmwares are now almost a year old, including
> for unstable. I am following the progress since quite a few years and I have
> seen many possible contributors trying to help and fail. The current
> situation is that Debian does not work well with recent AMD-based laptops
> due to firmware being too old. Therefore, we are back at users trying to
> update the firmware by copying them from random places (as for myself, I am
> using the deb generated by upstream's Makefile).
> 
> My personal impression is that we are repeating a common scheme in Debian:
> maintainers don't have time to move forward due to the task being
> non-trivial for reasons of our own, people are proposing to help (6 people
> in [1]), but this is ignored by the maintainers as they don't have time.
> 
> [1]: https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests
Why is updating the firmware packages not trivial? Is it because of
licensing issues? I always thought it's just copying a bunch of files from
the linux-firmware repo (but I also often wondered why is the package
often not up to date).

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Command /usr/bin/mv wrong message in German

[Andrey Rakhmatullin]

On Mon, Apr 01, 2024 at 05:02:56PM +0200, Fabrice Aeschbacher wrote:
> "dpkg -S" or "apt-file" give me an incorrect or no answer, most of the
> times.
> 
> Whereas this url always returns a correct answer:
> https://www.debian.org/distrib/packages#search_contents
Have you tried either of two examples you quoted?


> Le 01/04/2024 à 09:58, Andrey Rakhmatullin a écrit :
> > On Mon, Apr 01, 2024 at 01:03:04PM +1000, Russell Stuart wrote:
> > > On 1/4/24 10:18, gregor herrmann wrote:
> > > > % dpkg -S $(which mv > coreutils: /usr/bin/mv
> > > On bookworm:
> > > 
> > >  $ dpkg -S $(which mv)
> > >  dpkg-query: no path found matching pattern /usr/bin/mv
> > > 
> > > This is caused by the /bin -> /usr/bin shift.
> > > 
> > > The reason I'm replying is after one, probably two decades this still
> > > annoys me:
> > > 
> > > $ dpkg -S /etc/profile
> > > dpkg-query: no path found matching pattern /etc/profile
> > > 
> > > It was put their by the Debian install, and I'm unlikely to change it.
> > > Its fairly important security wise.  It would be nice if "dpkg -S" told
> > > me base-files.deb installed it.  It would be nice if debsums told me if
> > > it changed.  There are lots of files like this, such as /etc/environment
> > > and /etc/hosts.  There are some directories like /etc/apt/trusted.gpg.d/
> > > which should only have files claimed by some .deb.
> > This is the reason I never expect dpkg -S to work and dpkg -L to be
> > correct. The (probably) oldest registered bug report about this is
> > #213907, from 2003.
> > RPM has %ghost since before that, of course.
> > 
> 
> 

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Validating tarballs against git repositories

[Andrey Rakhmatullin]

On Mon, Apr 01, 2024 at 04:10:55PM +0200, Alexandre Detiste wrote:
> Le lun. 1 avr. 2024 à 15:49, Colin Watson  a écrit :
> >
> > The practice of running "autoreconf -fi" or similar via dh-autoreconf
> > has worked extremely well at scale in Debian.  I'm sure there are
> > complex edge cases where it's caused problems, but it's far from being a
> > disaster area.
> 
> It's pretty uncommon, only old stuff.
> 
> That could be monitored (via lintian ?),
> anything with "--without autoreconf"
> or "overides dh_autoreconf".
Or compat < 10.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Command /usr/bin/mv wrong message in German

[Andrey Rakhmatullin]

On Mon, Apr 01, 2024 at 01:03:04PM +1000, Russell Stuart wrote:
> On 1/4/24 10:18, gregor herrmann wrote:
> > % dpkg -S $(which mv > coreutils: /usr/bin/mv
> 
> On bookworm:
> 
> $ dpkg -S $(which mv)
> dpkg-query: no path found matching pattern /usr/bin/mv
> 
> This is caused by the /bin -> /usr/bin shift.
> 
> The reason I'm replying is after one, probably two decades this still
> annoys me:
> 
>$ dpkg -S /etc/profile
>dpkg-query: no path found matching pattern /etc/profile
> 
> It was put their by the Debian install, and I'm unlikely to change it.
> Its fairly important security wise.  It would be nice if "dpkg -S" told
> me base-files.deb installed it.  It would be nice if debsums told me if
> it changed.  There are lots of files like this, such as /etc/environment
> and /etc/hosts.  There are some directories like /etc/apt/trusted.gpg.d/
> which should only have files claimed by some .deb.
This is the reason I never expect dpkg -S to work and dpkg -L to be
correct. The (probably) oldest registered bug report about this is
#213907, from 2003.
RPM has %ghost since before that, of course.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: xz backdoor

[Andrey Rakhmatullin]

On Sun, Mar 31, 2024 at 12:28:35PM -0400, Roberto C. Sánchez wrote:
> On Sun, Mar 31, 2024 at 09:53:06AM -0300, Carlos Henrique Lima Melara wrote:
> > Hi,
> > 
> > On Sun, Mar 31, 2024 at 02:31:37PM +0200, Pierre-Elliott Bécue wrote:
> > 
> > > I would also be happy if it helps my fellow DDs to try making an article
> > > about some basic crypto concepts regarding PGP, RSA et al. But not in
> > > the same piece I guess.
> > 
> > My suggestion is to create a wiki page with these concepts plus a guide
> > on best practices dor the gpg key (subkeys + hsm - yubikey and others).
> > 
> Didn't DKG start something like this some time ago? Or am I
> mis-remembering?
I also thought I remember some Debian-specific PGP-related document but I
couldn't find it.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: xz backdoor

[Andrey Rakhmatullin]

On Sun, Mar 31, 2024 at 12:13:30PM +0200, Alexandre Detiste wrote:
> Le dim. 31 mars 2024 à 10:17, Sirius  a écrit :
> > Reduction of complexity is IMHO always worthwhile as it would open the
> > door for more people being able to step up as maintainers (taking into
> > account that volunteers right this minute might not be overly welcome and
> > when they are, they should likely not be near authentication, crypto and
> > compression at least initially).
> 
> It's worse than that: to make the xz MR looks more legit;
> the fake puppet profile "Hans Jansen" also sent _maybe_ legit MR to
> random games repos:
>https://news.ycombinator.com/item?id=39868390
> 
> Here fixing our Salsa tooling could help also making real newcomers
> life more enjoyable by always disabling MR again upstream & pristine-tar tar.
Yeah, those MRs never made sense to time, it's obvious that "run gbp
import-orig and propose the result as MRs" is just not a workflow we
support with the existing tools.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Some t64 libraries already in testing; I'm confused

[Andrey Rakhmatullin]

On Sun, Mar 31, 2024 at 11:22:05AM +0200, Andreas Metzler wrote:
> hdf5 1.10.10+repack-3.3
This one has an unanswered question from the maintainer in the NMU report,
and I feel like the reason for the missing line is the package having
debian/control.in.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: xz backdoor

[Andrey Rakhmatullin]

On Sat, Mar 30, 2024 at 11:22:33PM -0300, Santiago Ruano Rincón wrote:
> > I agree that dogfooding is important for discovering quality issues, but
> > I think it's a poor argument for discovering security issues, especially
> > if it concerns a host which is used for building and signing packages.
> > 
> > As I mentioned earlier, I think containers are one good way to have
> > almost the best of both worlds. One can do anything one could do on
> > host, all while being isolated from that host, and with very little
> > overhead but also a ton of useful extra features.
> 
> I don't see the real benefit.
> 
> As others have said, the best solution is to relay on HSW for handling
> the cryptographic material.
Aren't these answers to different questions?
Not all attacks are about stealing the key or using it to sign unintended
things.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Some t64 libraries already in testing; I'm confused

[Andrey Rakhmatullin]

On Sat, Mar 30, 2024 at 10:41:55PM +, Julian Gilbey wrote:
> My very limited understanding of this major transition was that the
> t64 libraries are being held in unstable until (almost) everything is
> ready, at which point there will be a coordinated migration into
> testing.  But I've now been asked to upgrade something on my testing
> machine which pulls in a t64 library.  Has something slipped through
> the net, or is this intentional?
I assume it's not intentional, some packages just didn't get a dpkg dep
for some reason.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: xz backdoor

[Andrey Rakhmatullin]

On Sat, Mar 30, 2024 at 08:52:29PM +0100, Ansgar  wrote:
> Hi,
> 
> On Sun, 2024-03-31 at 00:40 +0500, Andrey Rakhmatullin wrote:
> > On Sat, Mar 30, 2024 at 05:00:26PM +0100, Marco d'Itri wrote:
> > 
> > > I think that the real question is whether we should really still
> > > use 
> > > code-signing keys which are not stored in (some kind of) HSM.
> > What are the options for random DDs for that?
> 
> Yubikeys, Nitrokeys, GNUK, OpenPGP smartcards and similar devices.
> Possibly also TPM modules in computers.
> 
> These can usually be used for both OpenPGP and SSH keys.
Sure (though all the discourse around USB keys in the past 10 years or so
has suggested to me that all of them are bad according to one DD or
other).

> If someone cannot afford them, I think Debian paying for them is a good
> investment; Debian buying tokens for all project members would also be
> nice, 
This was even suggested at least once in the past.

> but logistics are probably annoying...
Exactly.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Validating tarballs against git repositories

[Andrey Rakhmatullin]

On Sat, Mar 30, 2024 at 10:56:40AM +0100, Iustin Pop wrote:
> > Now it is time to take a step forward:
> > 
> > 1. new upstream release;
> > 2. the DD/DM merges the upstream release VCS into the Debian VCS;
> > 3. the buildd is notified of the new release;
> > 4. the buildd creates and uploads the non-reviewed-in-practice blobs "source
> > deb" and "binary deb" to unstable.
> > 
> > This change would have three advantages:
> 
> I think everyone fully agrees this is a good thing, no need to list the
> advantages.
> 
> The problem is that this requies functionality testing to be fully
> automated via autopkgtest, and moved off the "update changelog, build
> package, test locally, test some more, upload".
Do you mean this theoretical workflow will not have a step of the
maintainer actually looking at the package and running it locally, or
running any building or linting locally before pushing the changes?
Then yeah, looking at some questions in the past years I understand that
some people are already doing that, powered by Salsa CI (I can think of
several possible reasons for that workflow but it still frustrates me).

> Give me good Salsa support for autopkgtest + lintian + piuparts, and
> easy support (so that I just have to toggle one checkbox), and I'm
> happy. Or even better, integrate all that testing with Salsa (I don't
> know if it has "CI tests must pass before merging"), and block tagging
> on the tagged version having been successfully tested.
AFAIK the currently suggested way of enabling that is putting
"recipes/debian.yml@salsa-ci-team/pipeline" into "CI/CD configuration
file" in the salsa settings (no idea where is the page that tells that or
how to find it even knowing it exists).

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: xz backdoor

[Andrey Rakhmatullin]

On Sat, Mar 30, 2024 at 05:00:26PM +0100, Marco d'Itri wrote:
> On Mar 30, Jonathan Carter  wrote:
> 
> > Another big question for me is whether I should really still
> > package/upload/etc from an unstable machine. It seems that it may be prudent
> If we do not use unstable for development then who is going to?
Yup.

> I think that the real question is whether we should really still use 
> code-signing keys which are not stored in (some kind of) HSM.
What are the options for random DDs for that?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: xz backdoor

[Andrey Rakhmatullin]

On Sat, Mar 30, 2024 at 10:49:33AM +0200, Jonathan Carter wrote:
> Another big question for me is whether I should really still
> package/upload/etc from an unstable machine. It seems that it may be prudent
> to consider it best practice to work from stable machines where any private
> keys are involved. For me it's just been so convenient to use unstable
> because it helps track changes that affect my users by the time it hits
> stable and also find bugs early that I care about, but perhaps I just need
> to make that adjustment and find more efficient ways to track unstable
> (perhaps on additional machines / VMs / etc). Not sure how other DDs think
> about this, but I'm also curious how they will deal with this, because
> there's near to no filter between unstable and the outside world, and this
> is probably not the last time someone will try something like this.
For me it's simple: if I'm forced to run my tools not on the host but in
some kind of inconvenient VM/chroot/whatever, I'll just stop contributing.
I'm not even discussing any of that proper Debian setups with keys on
separate airgapped machines, that's just not funny.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Validating tarballs against git repositories

[Andrey Rakhmatullin]

On Sat, Mar 30, 2024 at 09:58:22AM +0100, Ingo Jürgensmann wrote:
> > Yes. In that specific case, the original xz maintainer (Lasse Collin)
> > was socially-pressed by a likely fake person (Jigar Kumar) to do the
> > "right thing" and hand over maintenance.
> > https://www.mail-archive.com/xz-devel@tukaani.org/msg00566.html
> 
> In his reply to that mail Lasse writes in 
> https://www.mail-archive.com/xz-devel@tukaani.org/msg00567.html:
> 
> > It's also good to keep in mind that this is an unpaid hobby project.
> 
> 
> This reminds me of https://xkcd.com/2347/ - and I think that’s getting a more 
> common threat vector for FLOSS: pick up some random lib that is widely used, 
> insert some malicious code and have fun. Then also imagine stuff that 
> automates builds in other ways like docker containers, Ruby, Rust, pip that 
> pull stuff from the network and installs it without further checks. 
> 
> I hope (and am confident) that Debian as a project will react accordingly to 
> prevent this happening again. 
How?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Re: time_t progress report

[Andrey Rakhmatullin]

On Sat, Mar 23, 2024 at 04:50:48PM -0500, Steven Robbins wrote:
> Wondering about the current state of this transition. 
It's still in the stage of re-bootstrapping armel and armhf.
https://buildd.debian.org/stats/armel.png
https://buildd.debian.org/stats/armhf.png
https://buildd.debian.org/stats/graph-week-big.png

> 5. Do unchanged source rebuilds (binNMUs on all architectures) of 5000-6000 
> packages which depend on those. By the magic of transitions this just works.
> 
> 
> I'm guessing that we're somewhere in the midst of Milestone 5?  
Yes.

> In looking at packages I maintain, I find things like "blocked by ${pkg}".  
> But 
> when I go to the blocker, there's often no upload for 2-3 weeks and no other 
> visible sign of progress.
Just don't look at migration data now, it's intentionally blocked by dpkg
anyway. If a package B is successfully updated it won't migarte for now
and if a package A depends/build-depends on B it will say "B is blocked by
A" but no further action is needed for either of them.


> What's holding things up?  Are we waiting for folks to identify the 5-6k
> packages that need binNMU?   
We are waiting for:

1. Dependency cycles to be broken manually (both cases when A B-D: B, B
B-D: A and cases when A B-D: A), like when a new arch is bootstrapped.
This requires developer time, local build time and in the former cases
sometimes additional effort for finding where to break the cycle.
An example of a currently existing obstacle of this kind is openjdk-17.

2. FTBFSing packages (those that block further work, anyway) to be fixed
by their maintainers or NMUed. There are many FTBFSing packages, because
of
2.1. not being ready for 64-bit time_t (like assigning those to long);
2.2. not supporting -Werror=implicit-function-declaration;
2.3. symbol file changes due to 64-bit time_t;
2.3. usual bitrot.
An example of a currently existing obstacle of this kind is snapd-glib
(mainly because it blocks pipewire).

3. Not all binNMUs being scheduled yet.

4. buildd time to rebuild packages that can be rebuilt, when there are
any (currently not applicable).

> Can we help?  I tried filing a binNmu bug for a package, but then found out 
> the 
> package was nmu'd later -- without closing my bug.  So clearly someone is 
> looking at things.  Where are we in the process?  
From my experience in the past week, you (or any DD, and for parts not
involving uploads anyone) can do these things to speed up the process:

1. Help with FTBFS bugs. The options here are the usual ones: triage; fix
and attach the patch; fix and upload a NMU; find a patch in the upstream
source/upstream tracker/trackers of other distros; suggest general ideas
for a fix or at least for the reason of the problem.
This is more helpful for non-leaf packages.
2. File FTBFS bugs if you see something FTBFS but there is no bug reported
yet.
3. Identify packages that were not binNMUed against *t64 libraries
(packages.d.o helps with this, showing deps for all architectures), at all
or on some arches (usually armel and armhf) and file binNMU bugs against
release.debian.org for those.
4. Find packages that need to be rebuilt but can't, because they FTBFS or
B-D on packages that also can't be rebuilt, while blocking many packages,
and build them locally (most likely by enabling some build profile already
specified in the package) for armel and armhf and upload those binaries. 

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: lazarus is marked for autoremoval from testing

[Andrey Rakhmatullin]

On Tue, Feb 13, 2024 at 08:06:55AM +0100, Abou Al Montacir wrote:
> > It is affected by these RC bugs:
> > 1061034: lcl-utils-3.0: lcl-utils-3.0 Missing dependencies for lazbuild
> >  https://bugs.debian.org/1061034
> I really don't understand this message.
> the bug was fixed and is marked as so in the BTS.
It's clearly *not* marked as fixed in testing in the BTS.

> What' wrong with BTS since a few days? Is there a bug, or the procedure to fix
> bugs changed?
The autoremoval is correct, assuming the bug affects the version in 
testing. Otherwise the bug report should be changed to no longer mark it
as affecting testing.

Re: Drawbacks of lack of mandated packaging workflow (Was: Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline)

[Andrey Rakhmatullin]

On Sun, Jan 07, 2024 at 02:23:32AM +0900, Simon Richter wrote:
> > Aren't all these problems just inherent in Debian's lack of a mandated
> > packaging tooling and workflow [1,2]?
> 
> We have a mandated tooling and workflow.
> 
> The tooling follows an interface that is defined in Policy. The interface is
> deliberately designed to be as flexible as possible. Most packages do not
> require this flexibility, which is why a majority use a library of helper
> functions that trades that flexibility for ease of use.
> 
> This works because it is a solution that solves 95% of cases, and does not
> impose requirements on the remaining 5%. If you wanted 100% of packages to
> use this, and turn this into the new interface, then all these corner cases
> would need to be handled as well, and the interface extended.
> 
> We also have a version control system -- the Debian archive. It, too, has a
> different focus than other version control systems, because it also includes
> a mirroring strategy.
> 
> Switching to git would, again, require replication of the missing
> functionality, and it would require a lot of work to properly define all
> these interfaces and make sure they are extensible in the future.
This is, unironically, why we can't have nice things.

Re: DebGPT: how LLM can help debian development? demo available.

[Andrey Rakhmatullin]

On Wed, Jan 03, 2024 at 11:33:06AM +0200, Andrius Merkys wrote:
> On 2024-01-03 11:12, Andrey Rakhmatullin wrote:
> > On Wed, Jan 03, 2024 at 09:58:33AM +0200, Andrius Merkys wrote:
> > > To me the most time consuming task in Debian recently is the Python
> > > transitions. I wonder whether DebGPT could help with them. Maybe there are
> > > other, non-Debian-specific GPTs for this task, but I would prefer a Debian
> > > one.
> > As "transitions" is too broad, can you list actual problems you spend time
> > on for them?
> 
> Mostly failing tests, and mostly due to API changes between subsequent
> Python 3.x versions.
So the solution is either find a patch in the upstream repo (committed or
proposed in issues/PRs) or write one yourself. Not sure what can AI help
here with.

Re: DebGPT: how LLM can help debian development? demo available.

[Andrey Rakhmatullin]

On Wed, Jan 03, 2024 at 09:58:33AM +0200, Andrius Merkys wrote:
> To me the most time consuming task in Debian recently is the Python
> transitions. I wonder whether DebGPT could help with them. Maybe there are
> other, non-Debian-specific GPTs for this task, but I would prefer a Debian
> one.
As "transitions" is too broad, can you list actual problems you spend time
on for them?

Re: [Pkg-pascal-devel] Issue with fpc_3.2.2+dfsg-24 in Sid.

[Andrey Rakhmatullin]

On Sat, Dec 30, 2023 at 10:58:58AM +0100, Abou Al Montacir wrote:
> > I see only two possibilities, either upload manually fpc_3.2.2+dfsg-25 for
> > each missing architecture, or get fpc_3.2.2+dfsg-24 removed from archive and
> > replaced by fpc_3.2.2+dfsg-23 so that fpc_3.2.2+dfsg-25 can be built.
The second option is not possible.

Re: How to build debian transitional package without source code?

[Andrey Rakhmatullin]

On Wed, Dec 27, 2023 at 04:36:01PM -0500, Kaiqi Z wrote:
> Hello Debian Community,
> 
> I need to define a transitional package like debian Renaming Packages Method
> .
> 
> Since it is transitional it should not contain any actual source code, only
> pointing to the real package(via "Depends" field).
Transitional packages are binary packages, talking about source code is
not relevant here. And all binary packages are built from source packages
even if they are mostly empty.

> The example from the official doc does not contain Source field too.
It shows the binary package definition, not a full debian/control file.

> Then I tried to rewrite debian/control file as below:
> 
> Source: source-code
> Maintainer: Authors
> Section: misc
> Priority: optional
> Standards-Version: 3.9.2
> Build-Depends: debhelper (>= 9)
> Homepage: https://cloud.google.com/
> 
> Package: real-deb-pkg
> Replaces: transitional-deb-pkg (<< 100.0.0~)
> Breaks: transitional-deb-pkg (<< 100.0.0~)
> Architecture: amd64 arm64
> Description: real package
> 
> Package: transitional-deb-pkg
> Depends: real-deb-pkg
> Architecture: all
> Description: transitional package
Do you have any problems with this?

> I am not sure if I need to add more debian files to make the build works.
Does it not work?

Re: bring a newer version of a package into stable (nsis-3.09-1 into Debian "bookworm")

[Andrey Rakhmatullin]

On Fri, Dec 22, 2023 at 01:55:59PM +0100, Thomas Gaugler wrote:
> Hi,
> 
> I thought a package in Debian "bookworm" could be updated via a "bookworm
> proposed updates request" .
> 
> It looks like I did not fully understand the process. Therefore I kindly ask
> for assistance in updating the nsis-3.08-3 package in Debian "bookworm" to
> nsis-3.09-1.
What kind of assistance are you asking for?

Re: reference Debian package of multiple binaries sharing one man page

[Andrey Rakhmatullin]

On Fri, Nov 10, 2023 at 11:44:06AM -0800, Russ Allbery wrote:
> The good news is that if you're using debhelper, you don't have to care
> about how man handles these indirections and can just use a symlink.
> Install the man page into usr/share/man/man1 under whatever name is
> canonical (possibly by using dh_installman), and then create a symlink in
> usr/share/man/man1 from the other man page name to that file.
> 
> dh_installman will then clean this all up for you and create proper .so
> links and you don't have to care about the proper syntax.
Isn't it the other way around? The whole idea of using .so is to tell
dh_installman(1) to create symlinks.

Re: What would help the most?

[Andrey Rakhmatullin]

On Mon, Oct 30, 2023 at 02:48:24PM -0500, Lukasz Szybalski wrote:
> It's not an AI guy.
> 
> This is a question of, as a debian developer @debian.org...what do you need
> right now? What would help you?
> 
> Example without giving direction..or inserting things... more cs grads
> working bugs or more debian developers or more automation or ...?
Which of these can you provide?

Re: What would help the most?

[Andrey Rakhmatullin]

On Mon, Oct 30, 2023 at 07:03:38AM +0100, deb...@hyperborg.com wrote:
> Hi,
> 
> I have the feeling, that this is some kind of semi-AI generated chat.
> I think we should stop it now.
Makes sense.

Re: What would help the most?

[Andrey Rakhmatullin]

On Fri, Oct 27, 2023 at 02:00:45PM -0500, Lukasz Szybalski wrote:
> Hello
> I wanted to understand better from people with y...@debian.org email address
> on:
> 
> Vision of Debian:
> Create a free operating system, freely available for everyone.
> 
> Goal:
> Helping customers achieve outcome.
Sorry, I don't get this part.

> What is the minimum most value thing that would help YOU accomplish your
> goals for Debian ?
What's the context for your survey?

Re: Illegal Instruction Using sudo in Bookworm on i686

[Andrey Rakhmatullin]

On Tue, Oct 17, 2023 at 02:38:40PM -0500, Justin wrote:
> Okay, so because the VIA C3 Nehemaiah chip doesn't properly implement 
> ENDBR32, it falls outside of the supported hardware, despite being otherwise 
> an "i686 class chip," correct?
Seems correct to me.

> Or put another way, in classic Cyrix style, it's "almost a 686."
> 
> As for what I was looking for, well, two things:
> 
> 1. Clarification on the "big picture" situation in the most precise terms.  
> Assuming the answer to my question above is "yes," then this part is covered.
Your GCC link, assuming it's the current code, suggests that GCC thinks
"supports CMOV means supports ENDBR32". Nehemiah does the former but not
the latter. And binaries compiled with -march=i686 require CMOV support so
they require ENDBR32 support. In other words, yes, VIA C3 Nehemiah
doesn't seem to be a supported CPU for -march=i686 (even if that worked
before).

> 2. If this was a bug, I was going to ask if there was anything else I
> could do to help fix it.  Since it looks like it's not a bug - not in
> the SOFTWARE, anyway... - is the best suggestion for hardware like this
> to use Debian LTS (and bullseye) for the foreseeable future?
Yes, assuming the pre-bookworm Debian i386 architecture fully supports it,
as I don't know what *exactly* was allowed in the "almost i686"
stretch-bullseye i386.

Re: Illegal Instruction Using sudo in Bookworm on i686

[Andrey Rakhmatullin]

On Tue, Oct 17, 2023 at 10:57:41AM -0500, Justin wrote:
> Any other information I can provide that would help track this down?
Track what down, sorry? It seems to me you already understand the reason
for this error? Or are you asking how to make sure that your CPU indeed
doesn't support this?

Re: Control header sent with done email didn't do what I expected, should it have?

[Andrey Rakhmatullin]

On Mon, Sep 25, 2023 at 01:55:22PM -0400, Jonathan Kamens wrote:
> The documentation you inked to does not specify a tag that can be used
> specifically to mark something as not actually a bug.
Yes, we just close those. The Debian BTS is not as rich as e.g. a typical
bugzilla installation in this regard. Though I guess not having a fixed
version and not having the wontfix tag usually suggests the report was
invalid.

>This bug won't be fixed. Possibly because this is a choice
>between two arbitrary ways of doing things and the maintainer
>and submitter prefer different ways of doing things, possibly
>because changing the behaviour will cause other, worse, problems
>for others, or */possibly for other reasons./*
> 
> "I don't consider this a bug" seems, to me, to fit under "other reasons."
Other reasons why *this bug won't be fixed*, which doesn't apply if this
is not a bug.

> Is there some harm that is done by marking a bug that falls into this
> category with "wontfix"?
I think there is some: it having wontfix suggests the bug is valid but
won't be fixed.
The harm is minimal though, because likely nobody will read this report if
it doesn't correspond to anything affecting other people.

Re: Control header sent with done email didn't do what I expected, should it have?

[Andrey Rakhmatullin]

On Mon, Sep 25, 2023 at 12:55:16PM -0400, Jonathan Kamens wrote:
> All that aside, in this particular case I closed the bug because it wasn't
> actually a bug, but rather a PEBKAC issue (user complaining that a program
> wasn't respecting his locale when he had LC_ALL set to "C" so he was
> essentially telling the program to ignore his locale).
wontfix is a wrong tag for such bugs according to
https://www.debian.org/Bugs/Developer#tags though.

Re: Control header sent with done email didn't do what I expected, should it have?

[Andrey Rakhmatullin]

On Mon, Sep 25, 2023 at 07:16:56AM -0400, Jonathan Kamens wrote:
> I recently tried to close a bug, explain why, and set a "wontfix" tag all at
> once by sending my explanation to ###-d...@bugs.debian.org with "Control:
> tags ### wontfix" as the first line of my message body. The bug was closed
> but the tags command wasn't processed.
It doesn't work for NNN-done@ according to
https://www.donarmstrong.com/posts/control_at_submit/

Re: Control header sent with done email didn't do what I expected, should it have?

[Andrey Rakhmatullin]

On Mon, Sep 25, 2023 at 10:04:17AM -0400, Jonathan Kamens wrote:
> I did find this here  after I emailed
> the list:
> 
>QUESTION: Can you do all the control-server actions by using fields
>in a pseudo header in an email to bugnumber@b.d.o
> or do you need to use control@b.d.o
>?
> 
>ANSWER: You need to use the explicit control@ mail copy, automatic
>parsing isn't done. From what I understood it's worked on but it
>might take a bit to make it reliable and not catch something it
>shouldn't.
This is about plain commands, not about the Control: pseudo-header.
This QA transcript is from 2010, the feature was added in 2012.

Re: Control header sent with done email didn't do what I expected, should it have?

[Andrey Rakhmatullin]

On Mon, Sep 25, 2023 at 02:44:19PM +0100, Peter B wrote:
> On 25/09/2023 14:25, Jonathan Kamens wrote:
> > 
> > So putting a Control: line in the pseudo-header of a message sent to 
> > ###-d...@bugs.debian.org doesn't work at all?
> > 
> 
> It should work if the syntax is correct. The + character was missing.
Please read https://www.debian.org/Bugs/server-control#tag

Re: Control header sent with done email didn't do what I expected, should it have?

[Andrey Rakhmatullin]

On Mon, Sep 25, 2023 at 02:06:44PM +0100, Peter B wrote:
> > I recently tried to close a bug, explain why, and set a "wontfix" tag
> > all at once by sending my explanation to ###-d...@bugs.debian.org with
> > "Control: tags ### wontfix" as the first line of my message body. The
> > bug was closed but the tags command wasn't processed.
> > 
> > Looking at the raw message file that I sent, I see that my mailer
> > encoded the text/plain MIME body part with base64 because I had pasted
> > into the body a quote from a web site that used non-ASCII quotation
> > marks (d'oh). Is that why BTS failed to process the "Control:" command?
> > 
> > If yes, then is this a known thing that's not going to change that I
> > should just live with ;-), or should I file a bug about it?
> > 
> > If no, then can anyone tell me what else I did wrong to cause the 
> > "Control:" command not to be processed?
> > 
> > Thanks,
> > 
> > jik
> > 
> 
> see
> https://www.debian.org/Bugs/server-refcard
> 
> It should be
> tags bugnumber + wontfix
> 
> sent to cont...@bugs.debian.org
Please check https://www.debian.org/Bugs/Reporting#control

Re: Bug#1052421: ITP: control -- Python Control Systems Library

[Andrey Rakhmatullin]

On Thu, Sep 21, 2023 at 08:37:53PM +, Kurva Prashanth wrote:
> It seems debian python team following certain convention when naming
> packages for python modules, libraries prefixed with "python-" and
> python3 packages are prefixed with "pyhton3-".
python3- prefixes for binary packages are mandated by
https://www.debian.org/doc/packaging-manuals/python-policy/index.html#module-package-names
There is no requirement for source packages to be prefixed with python-,
but it's often done e.g. to not pollute the source package namespace,
which makes total sense in your case.

> will use python3-control over python-control as it's a python3 package.
This goes against the current practice.

Re: Bug#1052421: ITP: control -- Python Control Systems Library

[Andrey Rakhmatullin]

On Thu, Sep 21, 2023 at 08:20:20PM +0200, Christoph Biedl wrote:
> > * Package name: control
> >   Version : 0.9.4
> >   Upstream Author :  > >
> > * URL : http://python-control.org/
> 
> While I cannot judge whether this package is a sensible addition to
> Debian - I strongly ask you to re-consider the package name as "control"
> can apply to many different areas, and is therefore not helping when
> trying to figure if that package helps in a particular situation.
> Also, as there's the debian/control file in each source package, this
> will create some confusion and possibly even to users asking you for
> help with their packaging.
> 
> Just from the above website, perhaps something like
> python-feedback-control-systems or a bit shorter variant would be more
> appropriate. I might be wrong.
python-control is fine, considering it's https://pypi.org/project/control/

Re: Potential MBF: packages failing to build twice in a row

[Andrey Rakhmatullin]

On Thu, Aug 10, 2023 at 02:22:30PM +0200, Lucas Nussbaum wrote:
> > It might be worth to consider changing your workflow a bit and work with
> > a git repository. It does not have to be a clone of the repository (if
> > any) where the package is maintained, you can start with a fresh import,
> > e.g. with "gbp import-dsc".
> > 
> > Then before building the package for the first time, commit or at least
> > stash your changes, and you can go easily back to a clean state with
> > "git reset --hard; git clean -fdqx".
> 
> While this works in practice (and I do that as well), I find it hard to
> explain to new contributors that hacking on random packages requires
> them to create a temporary git repository so that they revert the
> package' source to a clean state.
They should be able to get an official git repo and hack on it instead.
Not now or in <10 years though, unless I guess you count dgit.

Re: Potential MBF: packages failing to build twice in a row

[Andrey Rakhmatullin]

On Sat, Aug 05, 2023 at 07:20:19PM +0300, Adrian Bunk wrote:
> What packages are failing, and why?
> 
> I would expect some debhelper machinery being responsible for most of 
> these, e.g. perhaps some dh-whatever helper might be creating this 
> issue for all 1k packages in some language ecosystem.
I've checked one of my Python packages and it fails because the contents
of $name.egg-info were modified. I expect all Python packages that ship
$name.egg-info and don't remove it in clean and don't exclude it via
extend-diff-ignore (all of which is unneeded busywork even if recommended)
to behave the same.