Re: openssl 3.1.5-1.1 effect on reverse dependencies

[Andrey Rahmatullin]

On Wed, Mar 06, 2024 at 08:50:59PM +0100, Micha Lenk wrote:
> >> You recently uploaded openssl 3.1.5-1.1.
> >> 
> >> Are you tracking the effect it had on reverse dependencies?
> >That's just a part of the time64 transition and it's definitely tracked by
> >people.
> 
> 
> Yet I wonder how I as a maintainer of a (transitive) reverse dependency
> can assist in any meaningful way. Are we supposed to do something about
> the current situation? Or is some central piece already being worked on
> and no parallel, shared maintenance possible?
If the only thing your package need is a binNMU or even nothing then you
don't need to do anything.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: 64-bit time_t transition in progress in unstable

[Andrey Rahmatullin]

On Wed, Mar 06, 2024 at 12:33:08PM -0800, Steve Langasek wrote:
> > > Are there instructions on how to progress an unstable system through
> > > this, or is the repo currently in a known inconsistent state?  I have
> > > tried upgrading various packages to work through deps but I am unable
> > > to do a dist-upgrade for a while.
> > Being unable to do a dist-upgrade is expected and some packages can't be
> > installed or can't be upgraded, but in general on amd64 you should be able
> > to upgrade a majority of them with `apt upgrade` and then manual
> > installing/upgrading, if you wish so (as in theory most libfoo0t64 are
> > drop-in replacements for libfoo0, but in practice some packages have
> > additional abi deps for their plugins etc., plus the usual amd64-i386
> > skews, plus some unique problems in some packages).
> > Also debootstrapping sid is broken, or may be broken from time to time.
> > Install testing instead if that's good enough.
> 
> Aside from the libuuid1t64 revert, for which binNMUs have been scheduled, I
> actually would expect unstable to be dist-upgradeable on non-32-bit archs:
> either the existing non-t64 library will be kept installed because nothing
> yet needs the t64 version, or something does want the t64 version and apt
> will accept it as a replacement for the non-t64 version because it Provides:
> the non-t64 name.
> 
> So once the libuuidt64 revert is done (later today?), if apt dist-upgrade is
> NOT working, I think we should want to see some apt output showing what's
> not working.
On my system there is currently only one problem not related to libuuid:
vlc-plugin-pipewire is not rebuilt for vlc-plugin-abi-3-0-0ft64. As for
uuid, I have several i386 libraries installed that depend on it.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: 64-bit time_t transition in progress in unstable

[Andrey Rahmatullin]

On Wed, Mar 06, 2024 at 12:26:17PM -0700, Kevin Bowling wrote:
> Are there instructions on how to progress an unstable system through
> this, or is the repo currently in a known inconsistent state?  I have
> tried upgrading various packages to work through deps but I am unable
> to do a dist-upgrade for a while.
Being unable to do a dist-upgrade is expected and some packages can't be
installed or can't be upgraded, but in general on amd64 you should be able
to upgrade a majority of them with `apt upgrade` and then manual
installing/upgrading, if you wish so (as in theory most libfoo0t64 are
drop-in replacements for libfoo0, but in practice some packages have
additional abi deps for their plugins etc., plus the usual amd64-i386
skews, plus some unique problems in some packages).
Also debootstrapping sid is broken, or may be broken from time to time.
Install testing instead if that's good enough.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: openssl 3.1.5-1.1 effect on reverse dependencies

[Andrey Rahmatullin]

On Wed, Mar 06, 2024 at 07:47:57AM -0800, Otto Kekäläinen wrote:
> Hi Benjamin!
> 
> You recently uploaded openssl 3.1.5-1.1.
> 
> Are you tracking the effect it had on reverse dependencies?
That's just a part of the time64 transition and it's definitely tracked by
people.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: hardinfo rebooted as hardinfo2 - community edition - RELEASE 2.0.12

[Andrey Rahmatullin]

On Sun, Mar 03, 2024 at 09:25:41PM +0100, hwspeedy wrote:
> Hi Simon Quiqley, (CC: debian-devel)
> 
> I'm trying to figure out how to get the hardinfo2 - release 2.0.12 into
> debian repository.
> hardinfo2 is a community fork of hardinfo and should continue as hardinfo
> package, currently maintained in debian by Simon Quiqley.
Then the logical way forward is to ask Simon to switch the package to
hardinfo2 and continue maintaining it (if they are still interested, as
the last maintainer upload was in 2018).

> Salvo Tomaselli suggested to do ITP
Only if you want to package and maintain it yourself, and only if it should
be a new package separate from the existing hardinfo one.

> - But the pro's on "#debian-mentors on oftc" are so out of my league. - I am
> missing the overview - eg. how to test the debian build system with packages
If you want to make and maintain the package yourself you should start at
https://mentors.debian.net/intro-maintainers

> do I need a salsa git?
No, it's just encouraged.

> - Is this for project maintainers also?
No, anyone can have a salsa account.

> Why does CPack not work with debian build system
I don't know if it can even generate source packages (generating a source
package, let alone a proper Policy-compliant one, is likely out of scope
for it), but even if it does, you still need to make it correct,
Policy-compliant and uptodate. Making trivial source package is the
easiest part of maintainership anyway.

> - could a small script fix it
> like:
> https://github.com/hardinfo2/hardinfo2/blob/master/tools/create_debian_source.sh
It doesn't really make sense to make a script that creates the initial
source package as you only need to do that once.
And no, you cannot just ship debmake results that you didn't even try to
build.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: time_t transition and bugs

[Andrey Rahmatullin]

On Sat, Mar 02, 2024 at 06:34:43AM -0700, Antonio Russo wrote:
> There's a similar issue with versioned dependencies by un-transitioned
> packages have on non-t64 libraries (e.g., libqt5sql5).
It's not similar, it's caused by some t64 libraries having wrong Provides.
I've filed bugs about this on poppler, qt5 and curl, there may be more.

> 1. Is the time_t transition team aware of these issues?
I would assume that they are aware about the issues directly blocking the
transition progression and many other issues are not relevant yet.

> 2. Where should these kinds of bugs be reported?  I feel like reporting to
> individual packages might get lost, and also these may represent less 
> package-specific
> issues.
When in doubt I would ask on #debian-devel, where the real-time
coordination seems to happen.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Any way to install packages+run autopkgtests on porterbox machines?

[Andrey Rahmatullin]

On Fri, Mar 01, 2024 at 07:15:16PM +0530, Nilesh Patra wrote:
> > You can use local sbuild chroots for foreign architectures, both for
> > building and, I assume, running autopkgtests.
> 
> I know but that is not something I want. This invaidates the whole point of 
> using
> porter machines.
I though the whole point of using porter machines is being able to run at
least something on architectures you don't have otherwise. Local chroots
are superior to that, not inferior, when they are also available..


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Any way to install packages+run autopkgtests on porterbox machines?

[Andrey Rahmatullin]

On Fri, Mar 01, 2024 at 06:28:50PM +0530, Nilesh Patra wrote:
> Hi,
> 
> When I want to fix autopkgtests for a package on a particular architecture, I 
> currently
> see no way to run autopkgtests before I dput since porter boxes do not 
> provide root
> access which autopkgtest needs.
> 
> Currently I am manually hacking around the test scripts and running the 
> autopkgtests but
> this does not emulate the autopkgtest environment well enough. It also does 
> not work
> well for daemon-like packages for instance.
> 
> Additionally, say, I have a package which FTBFS due to something broken in a 
> build dependency
> on a particular architecture.
> If I fixup the problem in the build-dependency, there is no way I could test 
> if the target
> package really works on that arch since I do not see a way to install the 
> fixed builddep without
> uploading it to the archive.
> 
> Have you found any way around these?
You can use local sbuild chroots for foreign architectures, both for
building and, I assume, running autopkgtests.



-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: On merging bin and sbin

[Andrey Rahmatullin]

On Wed, Feb 28, 2024 at 08:47:48AM -0600, r...@neoquasar.org wrote:
> Are any of these (like arping) literally duplicates of the same binary for 
> some reason? Or are they true conflicts (different binaries with the same 
> name)?
arping is definitely not a duplicate, iputils-arping and arping are
different implementations.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Migration bug ?

[Andrey Rahmatullin]

On Mon, Dec 12, 2022 at 07:28:27AM +0100, Yadd wrote:
> Hi,
> 
> I pushed 2 versions of node-rollup since December 09, but migration process
> never started (at least looking at tracker.d.o). Is there something broken ?
> 
> Cheers,
> Yadd
> 
> https://tracker.debian.org/pkg/node-rollup
Note that the unstable version is claimed to be 3.4.0-1 in multiple places
on that page, even though 3.7.2-1 is available via apt. That may be
related.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: my package uploads silently rejected

[Andrey Rahmatullin]

On Wed, Nov 30, 2022 at 03:03:14PM +0100, Jonas Smedegaard wrote:
> I have tried ssh into the host ssh.upload.debian.org and (after fumbling
> around) found the file /srv/upload.debian.org/queued/run/log where I see
> only succesful notices about rust-criterion, no indication of rejection.
The second log to check is /srv/ftp-master.debian.org/log/current on
coccia (mirror.ftp-master.debian.org). 

20221129000459|process-upload|dak|rust-criterion_0.3.6-2_source.changes|Error 
while loading changes file rust-criterion_0.3.6-2_source.changes: No valid 
signature found. (GPG exited with status code 0)
gpg: Signature made Mon Nov 28 14:29:33 2022 UTC
gpg:using RSA key 9FE3E9C36691A69FF53CC6842C7C3146C1A00121
gpg: Good signature from "Jonas Smedegaard " [expired]
gpg: aka "Jonas Smedegaard " [expired]
gpg: WARNING: Using untrusted key!




-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: transition to usrmerge to start around 2022-09-15 (next Thursday)

[Andrey Rahmatullin]

On Sun, Sep 18, 2022 at 11:16:22AM +0200, Bjørn Mork wrote:
> I find it quite disappointing to read https://bugs.debian.org/848622 . I
> don't know if it is arrogance or ignorance, but this bug is undoubtedly
> caused by usrmerge:
> 
>  frtest2:~# ls -l /usr/bin/bash 
>  -rwxr-xr-x 1 root root 1283864 Aug 25 16:03 /usr/bin/bash
>  frtest2:~# dpkg -S /usr/bin/bash 
>  dpkg-query: no path found matching pattern /usr/bin/bash
`dpkg -S` not knowing about files installed by packages is nothing new.
This was always how it worked and it was never reliable to answer "which
package installed this file/which package is responsible for this file",
usrmerge just added one more case where it fails.
#134758, linked in the bug you linked, indeed covers a part of this
general problem.

> Pointing at other maintainers/packages to fix your bugs is anti-social.
"your bugs"

> Don't force Debian decide whether the usrmerge bugs should be accepted
> in the next release.  Just fix them.  The alternative is ugly. And I'm
> not thinking about the actual bugs, but about the discussion...
"usrmerge bugs"

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Automatic trimming of changelogs in binary packages

[Andrey Rahmatullin]

On Sun, Sep 11, 2022 at 03:09:07PM +0300, Hakan Bayındır wrote:
>  Stuffing them behind a command, possibly making them online only in the
>  process will arguably make system troubleshooting and administration 
>  harder,
>  esp. if the system has connectivity issues.
>  
>  If something critical breaks, I can boot to recovery and look at the logs
>  and changelogs of recently updated packages. Having recent-ish 
>  changelogs on
>  the disk arguably accelerates the fixing process.
> >>> I don't think removing recent-ish changelogs from the disk is proposed
> >>> here.
> >> 
> >> Again, I may have misread, then. Because what I understood is
> >> 
> >> Trim changelogs:
> >> 1. Convert them to metadata
> >> 2. Ship untrimmed part in package DB
> >> 3. Get remaining part from network
> >> 
> >> Effectively eliminating /usr/share/doc/*changelog* files.
> > Even this isn't "making them online only".
> 
> Yes, you’re right. However, my reservation is whether dpkg is more prone to 
> breaking in disaster recovery scenarios. Reading a gzipped file is always 
> simpler than querying a DB via more abstraction.
I assume that cases when your dpkg database is broken and cases when you
need to read changelogs of updated packages shouldn't intersect.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Automatic trimming of changelogs in binary packages

[Andrey Rahmatullin]

On Sun, Sep 11, 2022 at 02:41:24PM +0300, Hakan Bayındır wrote:
> > On Tue, Sep 06, 2022 at 12:11:38PM +0300, Hakan Bayındır wrote:
> >> While all looks good and feels sound from many aspects, I have some
> >> reservations against treating changelogs as metadata.
> >> 
> >> Current changelogs as files have a well known place, can be used by 
> >> anything
> >> and everything, and they are local.
> > Assuming you are talking about making changelogs available at a dpkg
> > command, as in the RPM world, it's actually making the way to get a
> > package changelog more well-known, not less.
> 
> If this created the opposite effect in RPM world w.r.t. my theory, then I 
> stand corrected.
It didn't create anything because that was how it worked from the
beginning.
But yes, it's easier to run -q --changelog than write a full file path.

> >> Stuffing them behind a command, possibly making them online only in the
> >> process will arguably make system troubleshooting and administration 
> >> harder,
> >> esp. if the system has connectivity issues.
> >> 
> >> If something critical breaks, I can boot to recovery and look at the logs
> >> and changelogs of recently updated packages. Having recent-ish changelogs 
> >> on
> >> the disk arguably accelerates the fixing process.
> > I don't think removing recent-ish changelogs from the disk is proposed
> > here.
> 
> Again, I may have misread, then. Because what I understood is
> 
> Trim changelogs:
> 1. Convert them to metadata
> 2. Ship untrimmed part in package DB
> 3. Get remaining part from network
> 
> Effectively eliminating /usr/share/doc/*changelog* files.
Even this isn't "making them online only".

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Intel CET Support?

[Andrey Rahmatullin]

On Mon, Sep 05, 2022 at 10:44:52PM +0200, Felix Potthast wrote:
> i just stumbled upon the fact that debian doesn't yet make use of the
> Intel CET security feature, while many other distributions
> (Ubuntu, Fedora, Suse, Arch Linux) do.
> 
> The idea is to insert endbr instructions,
> (which are just NOPs on older CPUs) at the beginning
> of functions to identify valid call targets to mitigate
> ROP attacks.
> 
> You can do a quick test with
> 
> objdump -d /usr/bin/mv | grep endbr | wc -l
> 
> which outputs a nonzero number if the feature is used.
It's indeed nonzero on my testing and sid machines, with coreutils 8.32-4.1.
In which version is it zero?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Automatic trimming of changelogs in binary packages

[Andrey Rahmatullin]

On Tue, Sep 06, 2022 at 12:11:38PM +0300, Hakan Bayındır wrote:
> While all looks good and feels sound from many aspects, I have some
> reservations against treating changelogs as metadata.
> 
> Current changelogs as files have a well known place, can be used by anything
> and everything, and they are local.
Assuming you are talking about making changelogs available at a dpkg
command, as in the RPM world, it's actually making the way to get a
package changelog more well-known, not less.

> Stuffing them behind a command, possibly making them online only in the
> process will arguably make system troubleshooting and administration harder,
> esp. if the system has connectivity issues.
> 
> If something critical breaks, I can boot to recovery and look at the logs
> and changelogs of recently updated packages. Having recent-ish changelogs on
> the disk arguably accelerates the fixing process.
I don't think removing recent-ish changelogs from the disk is proposed
here.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Half the world being removed

[Andrey Rahmatullin]

On Thu, Sep 01, 2022 at 11:04:38PM -0500, Steven Robbins wrote:
> Suddenly half the packages are marked AUTOREMOVE; many due to gcc-12 and 
> zlib.  
> The related two bugs are months-old.  
> 
> Why are things suddenly being removed??
Both are key packages per
https://udd.debian.org/cgi-bin/key_packages.yaml.cgi so it must be some
recent problem that causes the things to ignore that.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Re: Need a buildd build after trip through NEW -- best practice?

[Andrey Rahmatullin]

On Thu, Sep 01, 2022 at 08:45:06AM -0500, Steven Robbins wrote:
> > > Specficially: in the case of a NEW binary upload, could a manual request
> > > be
> > > implemented (pick a different name if "give back" is not suitable) such
> > > that it is thrown away and replaced by a buildd build?
> > 
> > If you are suggesting the ability for dak to replace binaries already
> > in the archive with different content without a new source version,
> > then I don't think that should be implemented for Debian at least,
> > since our archive is meant to only contain immutable package files.
> 
> OK, so let's call it "bin nmu", then.  And add the "+bN" version suffix.
Have you seen 
and ?
(and )

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Bug#1018759: ITP: sd - intuitive find and replace CLI

[Andrey Rahmatullin]

On Tue, Aug 30, 2022 at 06:44:36PM +0800, Blair Noctis wrote:
> An RFP is at #1016929 [1].
> 
> 1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016929
> 
You should have retitled and owned the RFP instead of creating a separate
ITP. You should do that now, as described on
https://www.debian.org/devel/wnpp/#l3 , and merge this bug into that one.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Need a buildd build after trip through NEW -- best practice?

[Andrey Rahmatullin]

On Sun, Aug 28, 2022 at 05:54:36PM -0500, Steven Robbins wrote:
> I understand that the current state is that one can only "give back" a failed 
> build.  I'm asking whether this must necessarily be the case.  
Yes, by definition.

> Specficially: in the case of a NEW binary upload, could a manual request be 
> implemented (pick a different name if "give back" is not suitable) such that 
> it 
> is thrown away and replaced by a buildd build?
That's called a binNMU and it was already explained in this thread that it
already happens and that it cannot work for packages building arch:all.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation

[Andrey Rahmatullin]

On Fri, Aug 26, 2022 at 04:13:43PM -0400, M. Zhou wrote:
> If one's enthusiasm on working on some package is eventually
> worn out after a break, then try to think of the following question:
> 
>   Is it really necessary to introduce XXX to Debian?
>   Must I do this to have fun?
> 
> Strong motivations such as "I use this package, seriously" are not
> likely to wear out very easily through time. Packages maintained
> with a strong motivation are better cared among all packages in our
> archive.
(note that using a package doesn't require uploading it and, indeed,
sometimes packaging things for local use is much, much easier than
packaging them for the archive)

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Automatic trimming of changelogs in binary packages

[Andrey Rahmatullin]

On Fri, Aug 19, 2022 at 11:44:03AM +, Bastien Roucariès wrote:
> Le jeudi 18 août 2022, 19:18:35 UTC Gioele Barabucci a écrit :
> > Hello,
> > 
> > in 2020 there was a brief discussion on debian-devel@ about trimming
> > changelogs [1,2].
> > 
> > Now there is a working implementation of said functionality in
> > `dh_installchangelogs` [3].
> Could you stress on the mapage that some license ask to document the change 
> done by downstream in binary distribution and that in this case this tool 
> should be disable
Like GPLv2's "You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change"? We already
don't do this.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Unsolicited GNU bc patch

[Andrey Rahmatullin]

On Sat, Aug 06, 2022 at 05:12:13AM +, Thomas DiModica wrote:
> Yes, I keep spamming this trying to find an appropriate mailing list. I don't
> remember how or why I initially stumbled across this bug report
> (https://bugs.launchpad.net/ubuntu/+source/bc/+bug/1775776), but, given that
> I have some familiarity with GNU bc, I decided to fix some of the issues.
> Turns out, this also seems to fix the crashes reported here
> (https://www.openwall.com/lists/oss-security/2018/11/28/1). I think it would
> be a lot more useful to share this, as there isn't a lot to review. There are
> three bug fixes and some self-defensive checks in the runtime for malformed
> bytecode. Address Sanitizer tells me that these previously invalid memory
> references now just leak memory. I don't appear to have broken anything in the
> process, either. I'm not a member of any Debian mailing list, but I will try
> to watch for responses.
Please send such patches upstream.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: debhelper-compat should allow >= relations

[Andrey Rahmatullin]

On Sat, Jul 30, 2022 at 10:21:06PM -0700, Dima Kogan wrote:
> > it's completely identical to putting 13 into debian/compat
> 
> Oh. So it is. I vaguely remember that using debian/compat and
> "Build-Depends: debhelper" generated some lintian complaints.
Using debian/compat and "Build-Depends: debhelper-compat" generates them,
because the latter replaces the former.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: debhelper-compat should allow >= relations

[Andrey Rahmatullin]

On Sat, Jul 30, 2022 at 11:15:30AM -0700, Dima Kogan wrote:
> Hi. This probably has been covered before
It wasn't, but it's completely identical to putting 13 into debian/compat,
which never supported >= either.

> This works fine if you're building for Debian/sid in 2022. It does not
> work in any other context. I have a very common use case: at work I'm
> maintaining several APT repos for the packages we use for several
> distros (the last few releases of Debian and Ubuntu). The latest Debian
> already has the packages in it, so the Build-Depends line is exactly as
> above. But this means that building the package for any of the older
> releases fails. And if I say something reasonable like
> 
>   Build-Depends: debhelper-compat (>= 11)
And the recommendation was always "put 11 into debian/compat if you want
to build on older distros".

> It isn't helpful. Most packages (including mine) are very vanilla, and
> there isn't any difference between debhelper 11 or 12 or 13.
(there can be important changes even in very vanilla packages)

> I'm having to patch debian/control every time I do a build
You presumably also have to patch debian/changelog, and building a single
unchanged (apart from debian/changelog) package for multiple distros is
not going to always work either (even for very vanilla packages, e.g.
because of different versions for versioned B-D in Debian and Ubuntu).

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: how about telegram channel

[Andrey Rahmatullin]

On Wed, Jul 20, 2022 at 11:09:57AM +0200, Pierre-Elliott Bécue wrote:
> I'd try to stay closer to FOSS decentralized solution like Mattermost or
> Rocket Chat (not sure how and if it evolved to the point of being
> usable).
Shouldn't this have gone to -curiosa instead?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: how about telegram channel

[Andrey Rahmatullin]

On Wed, Jul 20, 2022 at 12:37:25PM +0200, Rand Pritelrohm wrote:
> You can also keep a session open if you have a small SOC/board around
> (screen tmux are her for that) without BNC/ZNC honeypot things.
Seriously.

> No need for those fancy, bloated, full of javascript modern things
> blinking like a Christmas tree.
> 
> Let's keep all the thing FOSS, KISS, lightweight and solid as a rock.
The irony in this email thread is so good.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Bug#1014908: ITP: gender-guesser -- Guess the gender from first name

[Andrey Rahmatullin]

On Thu, Jul 14, 2022 at 08:45:24AM -0400, Roberto C. Sánchez wrote:
> > > > And I see you uploaded ~immediately - why even bother with an ITP?
> > > 
> > > Is it proper procedure to upload without an ITP?
> > > 
> > 
> > No ; I have to admit a large percentage of the new packages I upload
> > get their ITP minutes before the package is ready.
> > 
> > Basically: I wait for the bug number before pushing to salsa & NEW.
> > 
> It's been a while since I've packaged something entirely new, but this
> is also how I have approached it.  Especially during periods when it
> might take months to make it through NEW, waiting an additional week or
> two for discussion around an ITP (especially when the vast majority of
> ITPs actually never elecit any sort of response from anyone), seems
> rather pointless.
> 
> Filing the ITP then immediately uploading seems really sensible,
More sensible than not filing it?
This defeats both purposes of an ITP: getting it discussed and working as
a mutex for people who are thinking about packaging the same software. Are
there other purposes?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: is rust-failure a heisen-package?

[Andrey Rahmatullin]

On Thu, Jun 30, 2022 at 02:35:45PM +0200, Jonas Smedegaard wrote:
> Hi,
> 
> This looks odd to me: https://tracker.debian.org/pkg/rust-failure
> 
> Latest news from 7 months ago was *removal* of the package, yet it is
> seemingly still around.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973298 should answer
this (e.g. #45)



-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Bug#1013132: ITP: BabaSSL -- BabaSSL is a base library for modern cryptography and communication security protocols.

[Andrey Rahmatullin]

On Wed, Jun 29, 2022 at 01:43:25PM +, Lance Lin wrote:
> Hello everyone,
> 
> Thank you for your input and guidance. I've only been in Debian for a year so 
> 
> I still have many things to learn. I assumed there would be issues with 
> library
> name conflicts and wanted to get the group's opinion.
> 
> >> Or if the goal is rather to experiment and expose BabaSSL to the many archs
> >> we have in Debian, then keep it in unstable only by filing a bug to block
> >> it from testing.
> 
> > Or better: experimental, to avoid packages starting to (build-)depend on it.
> 
> It sounds like it would be suitable for the community if I continue the 
> packaging 
> work but restrict the package to experimental? 
As a drop-in OpenSSL replacement or with different file names and SONAMEs?


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Lintian breaks existing lintian-overrides due to added []

[Andrey Rahmatullin]

On Wed, Jun 29, 2022 at 02:49:35PM +0200, Andreas Tille wrote:
> Hi,
> 
> I realised that lintian (at least) starting with version 2.115.1 (may be
> earlier) wraps file names into [] which breaks existing
> lintian-overrides.  Random example:
> 
>   
> https://salsa.debian.org/med-team/biomaj3-user/-/blob/master/debian/lintian-overrides
> 
> now becomes invalid by lintian claiming
> 
>   W: python3-biomaj3-user: mismatched-override script-with-language-extension 
> usr/bin/biomaj-users.py [usr/share/lintian/overrides/python3-biomaj3-user:2]
>   W: python3-biomaj3-user: script-with-language-extension 
> [usr/bin/biomaj-users.py]
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007002

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Package uploads silently discarded: how to investigate?

[Andrey Rahmatullin]

On Mon, Jun 27, 2022 at 09:02:30AM +1000, Ben Finney wrote:
> In this thread I want to discover: How can I find out what's happening
> and why the Debian archive is no longer sending me any email messages
> about my package uploads?
You should check usper.debian.org:/srv/upload.debian.org/queued/run/log

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Bug#1013132: ITP: BabaSSL -- BabaSSL is a base library for modern cryptography and communication security protocols.

[Andrey Rahmatullin]

On Wed, Jun 22, 2022 at 02:21:43PM +, Lance Lin wrote:
> > AFAIK this library is forked from OpenSSL with some extensive
> > modifications to support new crypto technologies, do you think we need
> > to involve the Security Team to review whether this package can be
> > supported during the next stable release cycle?
> > Also this project has a planned rename, and I'm a bit concerned this
> > could cause some maintenance burden if the rename is not well
> > coordinated at the time we accept it into Debian.
> 
> I think any reviews and oversight are a good thing. In making this ITP,
> I figured it would cause discussion as it's a "drop-in" replacement for
> OpenSSL and the libraries have the same name. I wasn't sure if this was
> directly permitted so the ITP is a good place to have the discussion.
Have you already designed how will this be packaged to work as a drop-in
replacement for libssl3? I see quite a lot of problems with that,
both Policy ones and technical ones.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Python installation paths

[Andrey Rahmatullin]

On Thu, Jun 02, 2022 at 09:15:40PM +0200, Alec Leamas wrote:
> > > I try handle a package which installs a partly compiled,
> > > architecture-dependent python module. Until now  this has been done in
> > > /usr/lib/triplet/python3.10/site-packages. This scheme has basically 
> > > worked
> > > fine.
> > > 
> > > However, here is an Ubuntu bug [1] where a user runs into problems because
> > > this installation path is not in sys.path by default.
> > > 
> > > I have been trying to look in the python policy docs, but cannot find the
> > > exact way to install code like this, in the policy [2]
> > > parlance an "extension module".
> > Not sure where is this documented but you can easily check on your system.
> > It should be /usr/lib/python3/dist-packages/*.cpython-3*-x86_64-linux-gnu.so
> 
> 
> Hm...this is not what I have. Did I get get the term "Extension module"
> wrong?
Well, we don't know what do you have.
Extension modules are ones you import.

> That aside, what I have is some python3 scripts and a compiled .so library
> invoked form the python code. The whole thing designed to be in the same
> directory. And the question is how this should be installed...
Invoked how?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Python installation paths

[Andrey Rahmatullin]

On Thu, Jun 02, 2022 at 07:19:56PM +0200, Alec Leamas wrote:
> Dear list,
> 
> I try handle a package which installs a partly compiled,
> architecture-dependent python module. Until now  this has been done in
> /usr/lib/triplet/python3.10/site-packages. This scheme has basically worked
> fine.
> 
> However, here is an Ubuntu bug [1] where a user runs into problems because
> this installation path is not in sys.path by default.
> 
> I have been trying to look in the python policy docs, but cannot find the
> exact way to install code like this, in the policy [2]
> parlance an "extension module".
Not sure where is this documented but you can easily check on your system.
It should be /usr/lib/python3/dist-packages/*.cpython-3*-x86_64-linux-gnu.so


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: use of Recommends by vlc to force users to use pipewire

[Andrey Rahmatullin]

On Tue, May 31, 2022 at 11:43:06AM +0200, Vincent Lefevre wrote:
> > > > >  a) pipewire package enables pipewire service by default
> > > > 
> > > > Indeed, but pipewire service doesn't take control of audio over
> > > > pulseaudio. Only pipewire-pulse does that.
> > > 
> > > This is incorrect. The pipewire-pulse package was not installed
> > > at all (pipewire-pulse had been installed automatically in
> > > October 2021 due to dependencies, but the change was reverted,
> > > and the package got removed on my machine 3 days later).
> 
> Sorry. Actually it got removed because I downgraded the pipewire
> packages back to the previous version (it's clearer with the
> /var/log/apt/term.log* log files).
> 
> > > I don't know whether this could cause the issue, but
> > > pipewire-media-session was installed, because pipewire-bin
> > > recommends it. There were already issues with it in the past:
> > What issues?
> 
> The ones mentioned below ("Closes: ...").
They are about pipewire-media-session vs wireplumber and/or affect people
installing pipewire-pulse as far as I can see.

> > > https://tracker.debian.org/news/1271014/accepted-pipewire-0339-3-source-into-unstable/
> > > which says:
> > > 
> > >* Remove pipewire-media-session from Recommends.
> > >(Closes: #995116, #996994, #997859)
> > The context of this was "replace pipewire-media-session with wireplumber"
> 
> Indeed, this is what happened with pipewire 0.3.39-1, as I can see
> in my dpkg logs and the changelog:
> 
>   * Change priority order between pipewire-media-session and wireplumber,
>   WirePlumber is now the recommended session manager.
> 
> and this is what led to the pipewire-pulse installation.
So "pipewire-media-session was installed" is indeed irrelevant.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: use of Recommends by vlc to force users to use pipewire

[Andrey Rahmatullin]

On Tue, May 31, 2022 at 10:55:55AM +0200, Vincent Lefevre wrote:
> > >  a) pipewire package enables pipewire service by default
> > 
> > Indeed, but pipewire service doesn't take control of audio over
> > pulseaudio. Only pipewire-pulse does that.
> 
> This is incorrect. The pipewire-pulse package was not installed
> at all (pipewire-pulse had been installed automatically in
> October 2021 due to dependencies, but the change was reverted,
> and the package got removed on my machine 3 days later).
> 
> I don't know whether this could cause the issue, but
> pipewire-media-session was installed, because pipewire-bin
> recommends it. There were already issues with it in the past:
What issues?

> https://tracker.debian.org/news/1271014/accepted-pipewire-0339-3-source-into-unstable/
> which says:
> 
>* Remove pipewire-media-session from Recommends.
>(Closes: #995116, #996994, #997859)
The context of this was "replace pipewire-media-session with wireplumber"
and it was rolled back in the next upload as you can see in d/changelog.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Firmware - what are we going to do about it?

[Andrey Rahmatullin]

On Sun, May 29, 2022 at 05:33:21PM -0400, Bobby wrote:
> There are definitely people who use forks because it's easier to
> install non-free firmware. What's the problem with that? Let them use
> forks. A distro can't be all things to all people. 
This would mean almost officially dropping support for user computers and,
as I've heard, many of the servers. It's certainly possible but I'm afraid
this will lead to even fewer new contributors to Debian.

> Debian is unique in this area, and it would be a shame to sacrifice that
> and make it just like all the rest. And it's unclear what benefit there
> is to attracting a larger and larger userbase as a bottom-line. It is
> not a commercial project, so they will not be paying customers. The
> best-case scenario is that people are attracted to making contributions
> or becoming more interested in free software, which I thought was the
> main goal. So if that isn't prioritized, what's the point?
I'm afraid that not providing hardware support is not the same as
prioritizing free software, or even free hardware. 

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Project Improvements

[Andrey Rahmatullin]

On Thu, May 26, 2022 at 06:47:19PM +0200, David Kalnischkies wrote:
> > > > > I support many people with Debian, what I often see is that they 
> > > > > remove a
> > > > > package, and then also the meta-package is removed. And later all
> > > > > dependencies of the meta-package are removed by accident.
> > > > Not to rain on your parade, but those people should consider upgrading
> > > > their Debian installations as since at least apt version 1.1 shipped
> > > > before current old-old-stable (that is, they run at best Debian 8 jessie
> > > > which is covered only by Extended LTS) apt actually marks dependencies
> > > > of packages in section metapackages as manually installed if the
>  
> > > > metapackage is removed due to the removal of one of its dependencies
> > > > – but doesn't if you decide to remove the metapackage explicitly.
> > > Then I guess there are some other reasons for this to happen not
> > > explainable by "these peoiple just run jessie".
> > OK, this was really easy.
> […]
> > # apt update && apt install task-kde-desktop && apt remove konqueror
> 
> task-kde-desktop has Section: tasks (as does all the other task- packages
> as they are built from the same source package).
Sure, it just means upgrading from jessie won't help actual users.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: 1011146: nvidia-graphics-drivers-tesla-470 is a dependency of libb2

[Andrey Rahmatullin]

No, see https://bugs.debian.org/1011268 (already linked in the bug report
you replied to).

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: cups-pdf is marked for autoremoval from testing

[Andrey Rahmatullin]

On Thu, May 26, 2022 at 02:33:20PM +0300, Martin-Éric Racine wrote:
> Someone apparently made a commit to the autoremoval hinter that makes
> it mark packages unrelated to an RC-bug package getting marked for
> autoremoval.
That's not what has happened.

> Could someone please look into this?
The bug report you replied to already has the bug report for this linked:
https://bugs.debian.org/1011268.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: maildir-utils is marked for autoremoval from testing

[Andrey Rahmatullin]

On Thu, May 26, 2022 at 04:54:25PM +0200, Hector Oron wrote:
> > > maildir-utils 1.6.10-1 is marked for autoremoval from testing on
> > 2022-06-30
> > >
> > > It (build-)depends on packages with these RC bugs:
> > > 1011146: nvidia-graphics-drivers-tesla-470: CVE-2022-28181,
> > CVE-2022-28183, CVE-2022-28184, CVE-2022-28185, CVE-2022-28191,
> > CVE-2022-28192
> > >  https://bugs.debian.org/1011146
> >
> > This is now the nth email I get about a completely irrelevant
> > dependency.
> >
> 
> I have gotten the same email for several packages, I assume this was
> unexpected. I tried to check for an email giving some explanation, but I
> have not found it yet.
https://bugs.debian.org/1011268

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Project Improvements

[Andrey Rahmatullin]

On Thu, May 26, 2022 at 03:28:21PM +0500, Andrey Rahmatullin wrote:
> > > I support many people with Debian, what I often see is that they remove a
> > > package, and then also the meta-package is removed. And later all
> > > dependencies of the meta-package are removed by accident.
> > Not to rain on your parade, but those people should consider upgrading
> > their Debian installations as since at least apt version 1.1 shipped
> > before current old-old-stable (that is, they run at best Debian 8 jessie
> > which is covered only by Extended LTS) apt actually marks dependencies
> > of packages in section metapackages as manually installed if the
> > metapackage is removed due to the removal of one of its dependencies
> > – but doesn't if you decide to remove the metapackage explicitly.
> Then I guess there are some other reasons for this to happen not
> explainable by "these peoiple just run jessie".
OK, this was really easy.

In a sid chroot:

# apt update && apt install task-kde-desktop && apt remove konqueror
[...]
The following packages were automatically installed and are no longer required:
  apper apper-data coinor-libcbc3 coinor-libcgl1 coinor-libclp1 
coinor-libcoinmp1v5 coinor-libcoinutils3v5 coinor-libosi1v5 cups-pk-helper 
espeak-ng-data fonts-opensymbol fonts-symbola gir1.2-atk-1.0 gir1.2-atspi-2.0
  gir1.2-freedesktop gir1.2-gdkpixbuf-2.0 gir1.2-gstreamer-1.0 gir1.2-gtk-3.0 
gir1.2-harfbuzz-0.0 gir1.2-notify-0.7 gir1.2-pango-1.0 gir1.2-secret-1 
gir1.2-wnck-3.0 gstreamer1.0-libav gstreamer1.0-plugins-ugly hyphen-en-us iw
  kdeaccessibility kmag kmousetool kmouth kontrast laptop-detect libabw-0.1-1 
libatk-adaptor libboost-filesystem1.74.0 libboost-iostreams1.74.0 
libboost-locale1.74.0 libbox2d2 libbrlapi0.8 libcdr-0.1-1 libclucene-contribs1v5
  libclucene-core1v5 libdotconf0 libe-book-0.1-1 libeot0 libepubgen-0.1-1 
libespeak-ng1 libetonyek-0.1-1 libexttextcat-2.0-0 libexttextcat-data 
libfreehand-0.1-1 libglu1-mesa libharfbuzz-icu0 libkf5konq6 liblangtag-common 
liblangtag1
  libmhash2 libmspub-0.1-1 libmwaw-0.3-3 libmythes-1.2-0 libnumbertext-1.0-0 
libnumbertext-data libodfgen-0.1-1 libopencore-amrnb0 libopencore-amrwb0 
liborcus-0.17-0 liborcus-parser-0.17-0 libpagemaker-0.0-0 libpangoxft-1.0-0
  libpcaudio0 libqaccessibilityclient-qt5-0 libqt5opengl5 libqt5xmlpatterns5 
libqxp-0.0-0 libraptor2-0 librasqal3 librdf0 libreoffice-base-core 
libreoffice-calc libreoffice-common libreoffice-core libreoffice-draw
  libreoffice-help-common libreoffice-help-en-us libreoffice-impress 
libreoffice-kf5 libreoffice-math libreoffice-plasma libreoffice-qt5 
libreoffice-style-breeze libreoffice-style-colibre libreoffice-writer 
librevenge-0.0-0
  libsidplay1v5 libsonic0 libstaroffice-0.0-0 libstartup-notification0 
libuno-cppu3 libuno-cppuhelpergcc3-3 libuno-purpenvhelpergcc3-3 libuno-sal3 
libuno-salhelpergcc3-3 libvisio-0.1-1 libwnck-3-0 libwnck-3-common 
libwpd-0.10-10
  libwpg-0.3-3 libwps-0.4-4 libxmlsec1-nss libyajl2 libzmf-0.0-0 lp-solve 
mythes-en-us node-normalize.css orca perl-tk print-manager python3-brlapi 
python3-cairo python3-certifi python3-chardet python3-charset-normalizer 
python3-cups
  python3-cupshelpers python3-idna python3-louis python3-pkg-resources 
python3-pyatspi python3-requests python3-six python3-smbc python3-speechd 
python3-uno python3-urllib3 python3-xdg qtgstreamer-plugins-qt5 sound-icons
  speech-dispatcher speech-dispatcher-audio-plugins speech-dispatcher-espeak-ng 
system-config-printer-common system-config-printer-udev task-desktop tasksel 
tasksel-data uno-libs-private ure x11-apps x11-session-utils xbrlapi xinit
  xkbset xorg
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
  kde-baseapps kde-plasma-desktop kde-standard konq-plugins konqueror 
task-kde-desktop
0 upgraded, 0 newly installed, 6 to remove and 37 not upgraded.



-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Project Improvements

[Andrey Rahmatullin]

On Wed, May 25, 2022 at 08:21:03PM +0200, David Kalnischkies wrote:
> > I support many people with Debian, what I often see is that they remove a
> > package, and then also the meta-package is removed. And later all
> > dependencies of the meta-package are removed by accident.
> 
> Not to rain on your parade, but those people should consider upgrading
> their Debian installations as since at least apt version 1.1 shipped
> before current old-old-stable (that is, they run at best Debian 8 jessie
> which is covered only by Extended LTS) apt actually marks dependencies
> of packages in section metapackages as manually installed if the
> metapackage is removed due to the removal of one of its dependencies
> – but doesn't if you decide to remove the metapackage explicitly.
Then I guess there are some other reasons for this to happen not
explainable by "these peoiple just run jessie".


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Concerns about Security of packages in Debain OS and the Operating system itself.

[Andrey Rahmatullin]

On Mon, May 23, 2022 at 07:22:40PM +0100, lkcl wrote:
> > > i believe the answer is in the question. debian is based on distributed 
> > > trust.  i did the analysis (took 3 weeks): it is literally the only 
> > > distro in the world with an inviolate chain of trust from a large keyring 
> > > dating back 20 years that is itself GPG-signed as a package, with a 
> > > package distribution chain from source where all components within the 
> > > chain up to release are unbroken and inviolate.
> >
> > This is not an answer to the question though, OP was asking how we prevent 
> > abuse of that trust.
> 
> reputation, and potentially criminal and civil proceedings.
> 
> all identities are known, and inviolate-known [through the
> above-described chain].
(there is no mechanism to tie a GPG key to an actual person or to find who
actually did the signing)

> anyone stupid enough to abuse their position may only do so once, at which
> point their GPG key is revoked.
(only after the abuse is found)

> given that GPG key-signing parties require people's real-world identities
> to be known,
(depends on your definition of "people's real-world identities")

> it is easy to track down who signed whose key (it's right
> there in the keyring-archive], and request that the signer provide assistance
> to the relevant authorities in proving that real-world identity.
(doubtful, considering how GPG key-signing parties actually work)

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Correct version and revision of upstream packaged Debian package

[Andrey Rahmatullin]

On Fri, May 20, 2022 at 10:52:08AM +0200, Jonas Smedegaard wrote:
> > It only makes sense to use '+maria~deb11' if you are going to
> > also release '+maria' that needs to sort after all of those, or if you are
> > using/going to use some '+maria+foo' scheme(s) that, again, need to sort
> > after all of '+maria~foo'.
> 
> Not true: It *is* helpful that you include a "distro label" as part of
> your version suffix - as documented here:
> https://wiki.debian.org/Derivatives/Guidelines#Packages
For the avoidance of doubt, I meant using ~ as a separator.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Correct version and revision of upstream packaged Debian package

[Andrey Rahmatullin]

On Fri, May 20, 2022 at 10:22:55AM +0300, Tuukka Pasanen wrote:
> After reading couple times Debian Policy documentation packaging conventions
> and especially'5.6.12.2. Special version conventions' chapter. I'm bit
> confused about revision system. As MariaDB Foundation wants to provide
> upstream packages and currently naming scheme conflicts when upgrading from
> Buster to Bullseye something should be done to solve situation.
> 
> Currently revision is for example: '10.6.7+maria~buster' which upgrades
> '10.6.7+maria~bullseye' which is lexical orderly lower than first one.To
> understand this bug report can be found here:
> https://jira.mariadb.org/browse/MDEV-28628 which contain more info about how
> apt works with current situation.
You indeed shouldn't put codenames into versions as codenames don't sort
correctly. You should put release version numbers, like official stable
updates and backports do (e.g. "[...]deb11[...]).

> Thing that like to ask should revision it be more like '+maria~deb11' or
> +mariadeb11. I understood that char '~' means it's build from upstream
> version control not from official release tag. 
No, the only thing ~ means is "a tilde sorts before anything, even the end
of a part". It only makes sense to use '+maria~deb11' if you are going to
also release '+maria' that needs to sort after all of those, or if you are
using/going to use some '+maria+foo' scheme(s) that, again, need to sort
after all of '+maria~foo'.

> So I like to know is there any common or tasked knowledge about how this can
> be done correctlywhich I'm no aware of? If someone can point out that I'm
> more than pleased to correct this thing.
There are no policies governing version structures for unofficial
packages, you should use whatever works for you.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: rules-needs-root: yes (Was: popularity-contest: support for XB-Popcon-Reports: no)

[Andrey Rahmatullin]

On Thu, May 05, 2022 at 11:31:37AM +0200, Andreas Tille wrote:
> > If there's a growing list of boolean control fields, isn't it the
> > indication that some sort of tagging system might make more sense?
> > 
> > Instead of three lines:
> > 
> > XB-Popcon-Reports: no
> > Rules-Requires-Root: yes
> > Pants-Need-Washing: yes
> > 
> > The same package could use a single line:
> > 
> > Tags: no-popcon-reports, rules-needs-root, pants-need-washing
> 
> ACK.
>  
> > (aside: by default rules doesn't need root... that would make one not-
> > very-useful line less in so many packages!)
> 
> I'd like to stress this!  If "rules-needs-root: no" would be default
> the majority of packages could be build.  So why not making this the
> default and just specify
>rules-needs-root: yes
> if needed?
First, strictly speaking it's not boolean, at least until #975637 is
implemented.
Second, changing the default is a breaking change. Is there any statistics
how many of the packages not already having a Rules-Requires-Root field
(which are a half of them according to trends.d.n) are working fine with
Rules-Requires-Root: no? 
Also note that "yes" doesn't exist, the correct value for the current
default is "binary-targets".

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Firmware - what are we going to do about it?

[Andrey Rahmatullin]

On Tue, Apr 26, 2022 at 11:59:20AM +0300, Hakan Bayındır wrote:
> > No, they do not. Most popular devices won't work at all without non-
> > free firmware, including boring things such as mass storage (SD cards,
> > SSD, HDD, ..., and controllers), input devices (keyboards, mice, ...).
> 
> Yeah, you’re right. Since the firmware images always there and doesn’t
> need to be hot-loaded by the driver itself 99% of the time (for these
> classes of devices), I tend to forget about them.
Note that this fact was mentioned many times in this thread.

> I wonder whether these “proper” firmware can be considered as part of the 
> hardware,
FSF and/or some FSF proponents certainly think like this. Others just
conveniently ignore it completely.

> since it’s bundled with the hardware, but not with the driver itself. 
In the Linux world loadable firmware is rarely "bundled with the driver".
This includes the use case discussed in this thread.

> This makes matters more complicated, of course, but starting somewhere
> may create the same wedging effect as in the drivers, over time.
Such arguments seem to ignore that
1) it's not about "starting somewhere" because we aren't discussing
something we will need to decide before some point in the future: the
situation exists for many years, we are discussing whether we should
change how to handle it, not how to start handling it;
2) the often mentioned expected effect on hardware manufacturers should be
already felt in some form as the status quo of not providing any non-free
firmware on the official image is many years old;
3) so far the usability of systems with the official image becomes worse,
not better, over time.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Firmware - what are we going to do about it?

[Andrey Rahmatullin]

On Mon, Apr 25, 2022 at 05:53:03PM +0200, Paul van der Vlis wrote:
> > > > > I have an idea for an extra option:
> > > > > 
> > > > > 6. Put the closed source firmware somewhere in the Debian images, but 
> > > > > never
> > > > > install closed source firmware by default. "No" should be the default.
> > > > That's the option 3 more or less.
> > > 
> > > Option 3 says to publish two sets of images.
> > > 
> > > 
> > > 3. We could stop pretending that the non-free images are unofficial, and
> > > maybe move them alongside the normal free images so they're published
> > > together. This would make them easier to find for people that need them, 
> > > but
> > > is likely to cause users to question why we still make any images without
> > > firmware if they're otherwise identical.
> > > 
> > If you want to drop the non-firmware image then it's the option 4 more or
> > less.
> 
> I see it more like option 5, with the difference that no closed source
> firmware or repository will be installed by default. With the non-free ISO
> this is the case.
> 
> For people who don't like closed source firmware, it gives the option not to
> install some firmware. E.g.: do I need that bluetooth adapter?
As I said, this is about d-i questions and defaults more than it's about
ISO choices and content.

> And we stay a possibility for FSF-people.
FSF people condemned Debian long ago:
https://www.gnu.org/distros/common-distros.html#Debian

> Most SSD devices also have firmware, do you update that firmware?
Sure.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Firmware - what are we going to do about it?

[Andrey Rahmatullin]

On Sun, Apr 24, 2022 at 05:03:29AM +0200, Simon Richter wrote:
> > Making Debian hard to use is a very short-sighted view of how to promote
> > free software - it works in the very short term only.
> 
> The same applies in the other direction -- making no real distinction
> between free and non-free software is a short term solution to the usability
> problem, but does not incentivize hardware vendors to open up designs in the
> slightest.
Does the status quo incentivize them?

> With drivers, user awareness is there at least.
(only for people who can actually differentiate drivers and firmware)

> People know that the nV drivers are essentially unsupported and if it
> breaks, they get to keep the pieces. 
As opposed to "nouveau usually doesn't work and if it indeed doesn't, just
install the non-free driver".

> The same isn't true for firmware, users just expect that stuff will work
> and if it doesn't, it's Debian's fault. We can either validate that
> expectation, or push back on it, saying "this hardware is supported on a
> best-effort basis, but we can't help you because it's closed source."
This, again, should be equally applied to loadable firmware and firmware
on the board.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Firmware - what are we going to do about it?

[Andrey Rahmatullin]

On Sat, Apr 23, 2022 at 10:48:03PM +0200, Paul van der Vlis wrote:
> > > I have an idea for an extra option:
> > > 
> > > 6. Put the closed source firmware somewhere in the Debian images, but 
> > > never
> > > install closed source firmware by default. "No" should be the default.
> > That's the option 3 more or less.
> 
> Option 3 says to publish two sets of images.
> 
> 
> 3. We could stop pretending that the non-free images are unofficial, and
> maybe move them alongside the normal free images so they're published
> together. This would make them easier to find for people that need them, but
> is likely to cause users to question why we still make any images without
> firmware if they're otherwise identical.
> 
If you want to drop the non-firmware image then it's the option 4 more or
less.

> And it says nothing about defaults.
d-i defaults are mostly unrelated to the ISO set and the archive setup
questions. You seem to want to add a yet another "free vs usable, with
free as the default" question, which is not too bad, just yet another
thing for most people to change.

> > > to put "non-free" into sources.list should also be an non-default choice,
> > > even when you install closed source firmware.
> > No, that's a bad idea, which is one of the main reasons for the option 5.
> 
> The idea is not to promote closed source firmware in any way. Have it
> available, but only for the people who really want it.
*shrug* that's just "have it available for most people" with extra
complexity. And you seem to miss the problem with installing firmware
packages but not enabling updates for them.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Firmware - what are we going to do about it?

[Andrey Rahmatullin]

On Sat, Apr 23, 2022 at 03:13:29PM +0200, Paul van der Vlis wrote:
> > I see several possible options that the images team can choose from here.
> > However, several of these options could undermine the principles of Debian. 
> > We
> > don't want to make fundamental changes like that without the clear backing 
> > of
> > the wider project. That's why I'm writing this...
> 
> I have an idea for an extra option:
> 
> 6. Put the closed source firmware somewhere in the Debian images, but never
> install closed source firmware by default. "No" should be the default.
That's the option 3 more or less.

> to put "non-free" into sources.list should also be an non-default choice,
> even when you install closed source firmware.
No, that's a bad idea, which is one of the main reasons for the option 5.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Firmware - what are we going to do about it?

[Andrey Rahmatullin]

On Thu, Apr 21, 2022 at 01:39:39PM +0300, Hakan Bayındır wrote:
> > > > > As everybody knows, Debian is also releasing the said firmware as 
> > > > > compressed
> > > > > archives and these are visible in the download page [0], however 
> > > > > usage and
> > > > > documentation is neither clearly documented, nor easy for the 
> > > > > beginners or
> > > > > casual users.
> > > > (it's documented at https://www.debian.org/releases/stable/amd64/ch06s04
> > > > for a separate drive, there may be some documentation about putting the
> > > > files to the installation drive but at that point the user should just
> > > > burn the firmware ISO)
> > > 
> > > I know it's documented, but it's buried deep down.
> > It's linked in the same yellow block on the page you linked as the archive
> > itself.
> > I mean, I agree it's not good but most of places on debian.org that are
> > related to downloading are not good. At least
> > https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/
> > is now just two clicks away from the main page.
> 
> Again, I think two clicks is too deep. A newcomer doesn't have to know the
> difference between all the files there. We're having this discussion because
> I see that the current amount of friction is seen as detrimental, and I
> agree.
Yes, my position was always "the only ISO link on the main page should be
the firmware netinst" but I understand that it's a minority one.

> > > In my ideal world (for newcomers), the link should produce the file
> > > directly, not the directory, or they get the tool, insert a USB drive, and
> > > viola.
> > They should just get the firmware ISO and burn it instead of fiddling with
> > all of that.
> 
> "The user shall do X" is not a very correct standpoint either. Even if we
> decide to add the firmware somehow into the "Official" ISOs, I still believe
> having a simple tool to do all of that is beneficial for new starters.
Providing a free ISO and a set of stuff to make it usable is strictly
worse (from the usability perspective) than providing a usable ISO right
away, and we even build the usable ISO already, we just hide it and
surround it with obsolete/hypocritical/outright false words, such as "For
convenience for some users, this unofficial alternative build includes
non-free firmware for extra support for some awkward hardware."

> If we want to have more new users or entice people who're starting to
> use/try Linux, initial barrier should be lowered.
I agree and I don't see why this should be done with a set of additional
tools instead of a directly usable ISO.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Firmware - what are we going to do about it?

[Andrey Rahmatullin]

On Thu, Apr 21, 2022 at 10:57:47AM +0300, Hakan Bayındır wrote:
> > > As everybody knows, Debian is also releasing the said firmware as 
> > > compressed
> > > archives and these are visible in the download page [0], however usage and
> > > documentation is neither clearly documented, nor easy for the beginners or
> > > casual users.
> > (it's documented at https://www.debian.org/releases/stable/amd64/ch06s04
> > for a separate drive, there may be some documentation about putting the
> > files to the installation drive but at that point the user should just
> > burn the firmware ISO)
> 
> I know it's documented, but it's buried deep down. 
It's linked in the same yellow block on the page you linked as the archive
itself.
I mean, I agree it's not good but most of places on debian.org that are
related to downloading are not good. At least
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/
is now just two clicks away from the main page.

> In my ideal world (for newcomers), the link should produce the file
> directly, not the directory, or they get the tool, insert a USB drive, and
> viola.
They should just get the firmware ISO and burn it instead of fiddling with
all of that.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Firmware - what are we going to do about it?

[Andrey Rahmatullin]

On Thu, Apr 21, 2022 at 09:57:36AM +0300, Hakan Bayındır wrote:
> As everybody knows, Debian is also releasing the said firmware as compressed
> archives and these are visible in the download page [0], however usage and
> documentation is neither clearly documented, nor easy for the beginners or
> casual users.
(it's documented at https://www.debian.org/releases/stable/amd64/ch06s04
for a separate drive, there may be some documentation about putting the
files to the installation drive but at that point the user should just
burn the firmware ISO)

> The whole process can be simplified with a simple GUI/CLI tool akin to
> GRML2USB which accepts the ISO file and burns (sic) it to a USB drive, and
> simplifying the whole process a lot. The tool can accept the ZIP file, or
> can have checkbox saying "Integrate firmware" if one decides to make such
> tool auto-downloading resources.
Only as long as it's usable on Windows.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Firmware - what are we going to do about it?

[Andrey Rahmatullin]

On Wed, Apr 20, 2022 at 12:53:46PM -0500, Devin Prater wrote:
> But back on topic, would the nonfree DVD ISO's have more firmware on them
> than the CD version? Or is that just for offline installs?
As far as I understand it there is just one set of non-free firmware for
including in the ISOs and separate drives, which consists of all non-free
firmware found in the archive.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Firmware - what are we going to do about it?

[Andrey Rahmatullin]

On Wed, Apr 20, 2022 at 05:04:13AM -0500, Devin Prater wrote:
> So then, I found the Non-free section and got the CD version? I guess
> that's what I should have gotten? The DVD one is the live environment
> right? See how confusion this can be? 
Yes, the variety of our ISOs and the poor way they are presented to the
user is already a significant problem even before considering official and
non-free ones.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Keep both images but stop pretending no-free is unofficial

[Andrey Rahmatullin]

On Wed, Apr 20, 2022 at 08:28:25AM -0400, Polyna-Maude Racicot-Summerside wrote:
> I think you lack pretty much of seeing more than you own self and use case.
No, everything I write in these threads I write for our potential users
who don't have enough knowledge to find things they need or to dismiss
propaganda. It's much easier for me to handle my own use cases.

> I've used plenty of laptop without making a mess, sometime by using a
> external Wifi card or simply choosing wisely.
> 
> Now, regarding your complain on the microcode. I think it's useless to
> have a conversation regarding this subject with you because having a
> global view seems out of bound for your mind.
> 
> Yes microcode are copyrighted blob. So run your computer without using
> microcode update and do a change of CPU every time a potential bug is
> found in a CPU.
> 
> You know what microcode does ? If so explain to me how it could be
> possible to have a CPU with microcode in the open-source without having
> more risk than benefits ? Now we'd see hacking done on the CPU
> micro-code itself because anyone could sign it. Dumb bell.
> 
> You've now got your solution. What are you asking for ? We provide a OS,
> we don't change the world to make it suit your need.
So you've lost the context.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Keep both images but stop pretending no-free is unofficial

[Andrey Rahmatullin]

On Wed, Apr 20, 2022 at 01:25:31PM +0530, Pirate Praveen wrote:
> >> >> Similarly, I think it would be reasonable for someone to want to provide
> >> >> entirely free Debian media along with a libre laptop.
> >> >
> >> >Does this exist in the real world?  Which hardware would such a system
> >> >contain?
> >> 
> >> liberated.computer it is refurbished and some components like wifi cards 
> >> replaced so it works with 100% free software.
> >
> >Intel Core i5-3320M CPU (dual-core, four threads, 3rd Gen)
> >
> >So no.
> >
> 
> What is no here? This project don't exist or they don't want to provide a 
> libre image?
Intel CPUs contain non-free microcode. Using them even implies enabling
the Debian non-free repo to get security fixes for it.
Intel GPUs reportedly don't work good enough, or at all, without non-free
firmware, according to the surveys done during the bullseye freeze.

> Debian's free image works on these laptops and if we make only non-free 
> images they won't be able to provide a fully free image. 
Eh, Debian's free image works on a lot of hardware, especially when you
don't need to download anything during the install (e.g. because you use a
DVD image or don't install a GUI), the installed system, on the other
hand...

But I agree that technically it's fine "to provide entirely free Debian
media along with a libre laptop" in this case.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Keep both images but stop pretending no-free is unofficial

[Andrey Rahmatullin]

On Wed, Apr 20, 2022 at 12:55:44PM +0530, Pirate Praveen wrote:
> >> Similarly, I think it would be reasonable for someone to want to provide
> >> entirely free Debian media along with a libre laptop.
> >
> >Does this exist in the real world?  Which hardware would such a system
> >contain?
> 
> liberated.computer it is refurbished and some components like wifi cards 
> replaced so it works with 100% free software.

Intel Core i5-3320M CPU (dual-core, four threads, 3rd Gen)

So no.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Firmware - what are we going to do about it?

[Andrey Rahmatullin]

On Tue, Apr 19, 2022 at 11:00:23PM +0200, Jonas Smedegaard wrote:
> > > > > > > When I install systems, I consider non-free blobs more risky 
> > > > > > > than other code.
> > > > > > Do you consider loadable non-free blobs more risky than their 
> > > > > > older versions soldered onto the hardware?
> > > > > > 
> > > > > Definitely "more risky" possibly not "less secure"
> > > > > 
> > > > > One of my biggest frustrations is that it's impossible to 
> > > > > selectively apply "security patches" and companies are wont to 
> > > > > "smuggle" in feature changes along with security fixes.
> > > > [...]
> > > > > No, but I do see a benefit in them not being applied 
> > > > > automatically as part of a standard update. And for something 
> > > > > like a firmware upgrade for a network card, I might only want to 
> > > > > install it if there was a security issue that might actually 
> > > > > impact me or I was having a problem. Otherwise it's hard to 
> > > > > imagine a scenario where a firmware upgrade can make things 
> > > > > better but it's easy to imagine it making things much worse.
> > > > Then what about hardware that doesn't have soldered firmware, only 
> > > > loadable one? Would you not use it at all?
> > > 
> > > I notice that you shift the conversation topic from *upgrading* 
> > > firmware to *introducing* firmware.
> > You partially narrowed the topic to upgrading firmware in 
> > <165037188392.1708.14819384411900940...@auryn.jones.dk>, so yes, I'm 
> > asking about both sides of the question. I will even say that the 
> > situation where some perfectly usable firmware is already available on 
> > the device, and Debian just offers an update to it, is much less 
> > important (but still very important for e.g. intel-microcode) than the 
> > situation where the device is not usable without firmware loaded by 
> > Debian, which is the main usability problem with the status quo.
> 
> Ah, so your view is that newer blob might...
I thought I shifted the conversation topic from *upgrading* firmware to
*introducing* firmware?
I even called this situation "much less important" than the other one.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Firmware - what are we going to do about it?

[Andrey Rahmatullin]

On Tue, Apr 19, 2022 at 06:51:16PM +0200, Jonas Smedegaard wrote:
> > > > > When I install systems, I consider non-free blobs more risky 
> > > > > than other code.
> > > > Do you consider loadable non-free blobs more risky than their 
> > > > older versions soldered onto the hardware?
> > > > 
> > > Definitely "more risky" possibly not "less secure"
> > > 
> > > One of my biggest frustrations is that it's impossible to 
> > > selectively apply "security patches" and companies are wont to 
> > > "smuggle" in feature changes along with security fixes.
> > [...]
> > > No, but I do see a benefit in them not being applied automatically 
> > > as part of a standard update. And for something like a firmware 
> > > upgrade for a network card, I might only want to install it if there 
> > > was a security issue that might actually impact me or I was having a 
> > > problem. Otherwise it's hard to imagine a scenario where a firmware 
> > > upgrade can make things better but it's easy to imagine it making 
> > > things much worse.
> > Then what about hardware that doesn't have soldered firmware, only 
> > loadable one? Would you not use it at all?
> 
> I notice that you shift the conversation topic from *upgrading* firmware 
> to *introducing* firmware.
You partially narrowed the topic to upgrading firmware in
<165037188392.1708.14819384411900940...@auryn.jones.dk>, so yes, I'm
asking about both sides of the question. I will even say that the
situation where some perfectly usable firmware is already available on the
device, and Debian just offers an update to it, is much less important
(but still very important for e.g. intel-microcode) than the situation
where the device is not usable without firmware loaded by Debian, which is
the main usability problem with the status quo.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Firmware - what are we going to do about it?

[Andrey Rahmatullin]

On Tue, Apr 19, 2022 at 04:30:44PM +0100, Tim Woodall wrote:
> > On Tue, Apr 19, 2022 at 02:38:03PM +0200, Jonas Smedegaard wrote:
> > > When I install systems, I consider non-free blobs more risky than other
> > > code.
> > Do you consider loadable non-free blobs more risky than their older
> > versions soldered onto the hardware?
> > 
> Definitely "more risky" possibly not "less secure"
> 
> One of my biggest frustrations is that it's impossible to selectively
> apply "security patches" and companies are wont to "smuggle" in feature
> changes along with security fixes.
[...]
> No, but I do see a benefit in them not being applied automatically as
> part of a standard update. And for something like a firmware upgrade for
> a network card, I might only want to install it if there was a security
> issue that might actually impact me or I was having a problem. Otherwise
> it's hard to imagine a scenario where a firmware upgrade can make things
> better but it's easy to imagine it making things much worse.
Then what about hardware that doesn't have soldered firmware, only
loadable one? Would you not use it at all?

> apt-get upgrade will tell you that linux-image-amd64 has a newer version
> but it then takes apt-get dist-upgrade to commit to that update.
(this is not really relevant, not exactly true and not really a feature)

> (kernels are a bit of a funny case because some kernel updates happen
> under apt-get upgrade)
(most package updates happen under apt-get upgrade)

> I'd like to see something similar for (non-free) firmeware where users
> can choose to default upgrade with their regular updates or can hold
> back updates.
Considering what I wrote above, this isn't really something we usually do.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Firmware - what are we going to do about it?

[Andrey Rahmatullin]

On Tue, Apr 19, 2022 at 02:38:03PM +0200, Jonas Smedegaard wrote:
> When I install systems, I consider non-free blobs more risky than other 
> code. 
Do you consider loadable non-free blobs more risky than their older
versions soldered onto the hardware?

> When I (sometimes, but not always¹) choose to "infect" my systems with 
> non-free packages, I therefore consider each non-free package to try 
> minimize the amount of risky blobs on my systems.  As an example, I may 
> choose to not apply realtek firmware updates when I can verify that my 
> ethernet device works adequately without it.
Do you see some inherent value in not applying a firmware update then?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Firmware - what are we going to do about it?

[Andrey Rahmatullin]

On Tue, Apr 19, 2022 at 11:33:30AM +0200, Christian Kastner wrote:
> Hi Steve,
> 
> thank you for bringing this up.
> 
> On 2022-04-19 02:27, Steve McIntyre wrote:
> >  1. Keep the existing setup. It's horrible, but maybe it's the best we can 
> > do?
> > (I hope not!)>
> >  2. We could just stop providing the non-free unofficial images altogether.
> > That's not really a promising route to follow - we'd be making it even
> > harder for users to install our software. While ideologically pure, it's
> > not going to advance the cause of Free Software.
> 
> Here's a somewhat radical idea: I propose that we make option (1) and
> (2) conditional on all Debian infra switching to hardware entirely free
> of binary firmware/microcode blobs.
But people promoting these two options only care about loadable firmware,
not all of it...


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Firmware - what are we going to do about it?

[Andrey Rahmatullin]

On Tue, Apr 19, 2022 at 10:22:15AM +0200, parodper wrote:
> >   5. We could split out the non-free firmware packages into a new
> >  non-free-firmware component in the archive, and allow a specific 
> > exception
> >  only to allow inclusion of those packages on our official media. We 
> > would
> >  then generate only one set of official media, including those non-free 
> > >  firmware packages.
> 
> Aren't drivers already part of the non-free/kernel section? Maybe also query
> for the use::driver tag.
Sections and tags don't mean anything useful in the context of the
discussed topic.
Also, drivers and firmware are different things.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: ITP: trbot -- Powerful software for playing games through text, supporting remote collaborative play

[Andrey Rahmatullin]

On Fri, Apr 15, 2022 at 09:21:20PM +, kimim...@posteo.net wrote:
> Package: trbot
> Version: 2.5.1
> Severity: wishlist
Looks like you intended to submit this as a bug report but sent it to
debian-devel@ instead.
Also, if you are not going to package and maintain this software in Debian
but just want someone else to do that, it should be RFP, not ITP (and note
that RFPs usually don't cause the software to be actually packaged).

> * dotnet-sdk-5.0
> * dotnet-runtime-5.0
> * netstandard-targeting-pack-2.1
> * aspnetcore-runtime-5.0
> * dotnet-targeting-pack-5.0
> * aspnetcore-targeting-pack-5.0
> * dotent-apphost-pack-5.0
(so somebody would need to package these first)

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: rebuild of rpcbind (and other packages?) due to old debhelper bug 993316

[Andrey Rahmatullin]

On Fri, Apr 08, 2022 at 05:25:11PM +0200, Vincent Lefevre wrote:
> > > Bug 993316 was fixed on 23 September 2021. Any reason why rpcbind
> > > hasn't been rebuilt yet?
> > Was anything done for that to happen? Because otherwise the answer is
> > "nobody did that".
> 
> I would have assumed that this would be done when bug 993316 was closed.
There is no mechanism to automatically rebuild affected packages when a
bug in debhelper was fixed, or in any similar cases.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: rebuild of rpcbind (and other packages?) due to old debhelper bug 993316

[Andrey Rahmatullin]

On Fri, Apr 08, 2022 at 03:22:07PM +0200, Vincent Lefevre wrote:
> Due to the old bug 993316 in debhelper[*], rpcbind is still buggy as
> it hasn't been rebuilt yet: rpcbind_1.2.6-2_amd64.deb contains
> 
> -rw-r--r-- root/root   626 2021-08-17 17:31:36 
> ./usr/lib/systemd/system/rpcbind.service
> -rw-r--r-- root/root   325 2021-08-17 17:31:36 
> ./usr/lib/systemd/system/rpcbind.socket
> lrwxrwxrwx root/root 0 2021-08-17 17:31:36 
> ./lib/systemd/system/portmap.service -> rpcbind.service
> 
> thus with a dangling symlink, while this should be
> 
> /lib/systemd/system/rpcbind.service
> /lib/systemd/system/rpcbind.socket
> /lib/systemd/system/portmap.service -> rpcbind.service
> 
> i.e. without the "/usr".
> 
> Bug 993316 was fixed on 23 September 2021. Any reason why rpcbind
> hasn't been rebuilt yet?
Was anything done for that to happen? Because otherwise the answer is
"nobody did that".

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: What to do with merged /usr and dpkg-fsys-usrunmess

[Andrey Rahmatullin]

On Wed, Apr 06, 2022 at 04:02:23PM +0200, Bjørn Mork wrote:
> > Sorry, blame the dpkg maintainer.
> 
> Is that how we discuss technical issues around here?
This is not a technical issue.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: isa-support -- exit strategy?

[Andrey Rahmatullin]

On Fri, Mar 25, 2022 at 11:34:17PM +0100, Adam Borowski wrote:
> While packages are allowed to not support entire architectures
> outright, there's a problem when some code requires a feature that is
> not present in the arch's baseline.  Effectively, this punishes an arch
> for keeping compatibility.  The package's maintainers are then required
> to conform to the baseline even when this requires a significant work
> and/or is a pointless exercise (eg.  scientific number-crunching code
> makes no sense to run on a 2002 box).
A partial arch (whatever that is, yeah) with the x86-64-v3 baseline, and
optionally raise the main amd64 baseline to x86-64-v2?
Assuming we don't want to mass-modify software to support code separation
into hwcaps etc. or runtime detection.

> With that in mind, in 2017 I added "isa-support" which implements
> install-time checks via a dependency.  Alas, this doesn't work as well
> as it should:
(that was expected tbh)

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: proposed MBF: packages still using source format 1.0

[Andrey Rahmatullin]

On Tue, Mar 15, 2022 at 10:49:17AM +, Matthew Vernon wrote:
> >> It's probably unfashionable, but I think debian/patches is not a great
> >> way to manage changes, particularly if you're using a VCS for
> >> maintaining your packages. As others have pointed out in this thread,
> >> doing this means you end up essentially trying to version-control your
> >> patches twice - once in the source package, and once in the VCS.
> > That's just a consequence of using two different storage formats for your
> > packages: a Debian source package and a VCS. As long as both of them are 
> > widely
> > used and incompatible, problems will exist in some form when using both.
> > By e.g. merging all patches in the Debian source package into one big diff
> > you are just breaking one of these two storage formats for that package,
> > essentially mandating the usage of the other one (the VCS) for most of the
> > developer operations with it.
> 
> I'm not sure that's entirely true; 
Which of my statements?

> but even if it were, is that an entirely unreasonable position for a
> package maintainer (or team thereof) to take?
Probably not? Just yet another case where you need to learn a specific
workflow to modify or study a certain package, cannot use established
documentation for that, and are required to use specific non-default tools
for that.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: proposed MBF: packages still using source format 1.0

[Andrey Rahmatullin]

On Tue, Mar 15, 2022 at 08:54:50AM +, Matthew Vernon wrote:
> It's probably unfashionable, but I think debian/patches is not a great
> way to manage changes, particularly if you're using a VCS for
> maintaining your packages. As others have pointed out in this thread,
> doing this means you end up essentially trying to version-control your
> patches twice - once in the source package, and once in the VCS.
That's just a consequence of using two different storage formats for your
packages: a Debian source package and a VCS. As long as both of them are widely
used and incompatible, problems will exist in some form when using both.
By e.g. merging all patches in the Debian source package into one big diff
you are just breaking one of these two storage formats for that package,
essentially mandating the usage of the other one (the VCS) for most of the
developer operations with it.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Bits from the Release Team: bookworm freeze dates (preliminary)

[Andrey Rahmatullin]

On Mon, Mar 14, 2022 at 09:43:15PM +0100, Jérémy Lal wrote:
> > We are currently considering the following dates as our freeze
> > dates. If you are aware of major clashes of these dates with anything
> > we depend on please let us know. We also like to stress again that we
> > really would like to have a short Hard and Full Freeze (counting in
> > weeks, rather than months), so please plan accordingly. If serious
> > delays turn up during any of the Freeze steps, we rather (partially or
> > completely) thaw bookworm again than staying frozen for a long time.
> >
> > 2022-01-12  - Milestone 1 - Transition and toolchain freeze
> > 2022-02-12  - Milestone 2 - Soft Freeze
> > 2022-03-12  - Milestone 3 - Hard Freeze - for key packages and
> > packages without autopkgtests
> > To be announced - Milestone 4 - Full Freeze
> Is it possible to adopt ISO8601 dates like -MM-DD please (to avoid
> heart attacks) ?
Do you think these phases are so short that they are 1 day each? :)

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Why? "Marked for autoremoval on 24 March due to xdelta3: #965883"

[Andrey Rahmatullin]

On Thu, Feb 24, 2022 at 10:09:23PM +0900, Osamu Aoki wrote:
> Hi,
> 
> I favor moving away from pre-dh7 packages and I support people pushing for 
> it.  But I
> am in intriguing situation with this effort.  Can someone help me.
> 
> At: https://udd.debian.org/cgi-bin/autoremovals.cgi
> 
> I see:
> 
> Osamu Aoki 
>debian-history: buggy deps xdelta3, flagged for removal in 28.4 days
>debian-reference: buggy deps xdelta3, flagged for removal in 28.4 days
>maint-guide: buggy deps xdelta3, flagged for removal in 28.4 days
These say "buggy deps". It means they are not affected themselves but they
(maybe indirectly) depend on an affected package.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: LESS copyright, not more!

[Andrey Rahmatullin]

On Thu, Feb 10, 2022 at 12:14:40PM +0100, dude wrote:
> Linus: the (GPL 2.0) intented social contract is: “i give you sourcecode,
> give me back your changes”
> 
> https://dwaves.de/2022/01/31/why-is-it-gnu-linux-and-not-just-linux-linus-talking-about-gpl-v3-vs-gpl-v2-the-better-one-the-social-gpl-contract-is-i-give-you-sourcecode-give-me-back-your-changes-non-free-binary/
> 
> if the developer does not want-need changes back GPL 3.0 is also "okayish"
> 
> the kernel licensing is also rather... complicated... (with the many
> different versions of GPL and LGPL) maybe a user can do a 30min entertaining
> sum up video explanation of this ...
This isn't related to this thread.

> PS: yes iterating over this stuff takes time, anyone ever read the whole GPL
> 2.0?
Yes.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: What are the most important projects that Debian ought to work on?

[Andrey Rahmatullin]

On Thu, Feb 10, 2022 at 12:07:24PM +0100, dude wrote:
> provide build in easy feedback-communications to digest, collect, analyze
> user's needs and progress from there
> 
> (more security, stability and faster boot is laways better X-D (in that
> order))
> 
> aka: what is REALLY needed (comes per installed per default) and what is
> optional/can be installed by user later
> 
> imho the minimalistic approach is my favorite: have as little software
> installed/running as possible
> 
> and then gradually add stuff as needed
> 
> to gradually improof the OS in a user-centric way
> 
> right now pretty happy with Debian 10 and 11 + MATE 2 Desktop (not as
> minimalistic as xfce but not as bloated as Ubuntu Desktop X-D)
> 
> and usually without a lot of tinkering it works out of the box on most
> hardware
This isn't related to this thread.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: What are the most important projects that Debian ought to work on?

[Andrey Rahmatullin]

On Wed, Feb 09, 2022 at 06:53:49PM +0100, Enrico Zini wrote:
> > > I've added "We should have a default standard packaging workflow":
> > > https://salsa.debian.org/debian/grow-your-ideas/-/issues/24
> > This should include ideas what to do with resignations that will follow.
> 
> Why would one decide to resign based on a standard for a default that
> nobody is required to follow?
> 
> I'm talking about suggesting a widely accepted default for people who
> would love to have a widely accepted default suggested instead of
> needing to figuring out a workflow from lots of conflicting tutorials.
> 
> I'm not talking about mandating the way everyone has to do their work in
> Debian.
Eh, if it's just for new people who don't know which workflow to use then
fine, it's a good idea, but the scope of that is quite narrow and doesn't
even help the second point in "This impacts" ("every package I need to
change is set up in a different way!").


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: What are the most important projects that Debian ought to work on?

[Andrey Rahmatullin]

On Wed, Feb 09, 2022 at 03:23:38PM +0100, Enrico Zini wrote:
> > That's where you come into play: it would be nice if you could share
> > what are — according to you — the most important projects/improvements
> > that Debian ought to make. You can share your ideas here by replying to
> > this email, but it would be interesting to file them as new issues in
> > the "grow-your-ideas" project and then reply here pointing to your new
> > issue:
> > 
> >   https://salsa.debian.org/debian/grow-your-ideas/-/issues
> 
> I've added "We should have a default standard packaging workflow":
> https://salsa.debian.org/debian/grow-your-ideas/-/issues/24
This should include ideas what to do with resignations that will follow.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Legal advice regarding the NEW queue

[Andrey Rahmatullin]

On Wed, Feb 02, 2022 at 12:12:30PM -0500, Michael Stone wrote:
> On Wed, Feb 02, 2022 at 11:39:11AM -0500, The Wanderer wrote:
> > Doesn't that, then, lead to the suggestion that any package entering
> > unstable without having undergone NEW review (which, in the revised
> > model, might be every new package) should automatically have a bug filed
> > against it requesting suitable review, and that bug should be treated as
> > a blocker for entering testing?
> 
> Not really, since anyone in the world could close said bug (including the
> uploader).
This applies to any RC bug.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Legal advice regarding the NEW queue

[Andrey Rahmatullin]

On Wed, Feb 02, 2022 at 11:39:11AM -0500, The Wanderer wrote:
> >>> I would hate to entirely lose the quality review that we get via
> >>> NEW, but I wonder if we could regain many those benefits by
> >>> setting up some sort of peer review system for new packages that
> >>> is less formal and less bottlenecked on a single team than the
> >>> current NEW processing setup.
> >> 
> >> This is a fantastic idea.
> >> 
> >> In fact, it wouldn't have to bottleneck packages at all.  I mean,
> >> if a quality issue is found in NEW, wouldn't the same be an RC bug
> >> preventing a transition to testing?
> > 
> > I'm not sure "nobody ever looked at this" is a suitable criteria for
> > inclusion in a stable release. We sort of have that problem now in
> > crusty corners of the archive if someone uploads a bad change, but at
> > least there's been one review at some point in the package's
> > lifetime.
> 
> Doesn't that, then, lead to the suggestion that any package entering
> unstable without having undergone NEW review (which, in the revised
> model, might be every new package) should automatically have a bug filed
> against it requesting suitable review, and that bug should be treated as
> a blocker for entering testing?
> 
> That wouldn't help the "someone uploads a bad change" problem for
> already-accepted packages, but it would seem to avoid the "nobody ever
> looked at this" situation.
> 
> It would also increase the number of automatically-filed bugs by quite a
> lot, I suspect, which would itself be some degree of downside...
This will also decrease the number of new packages in testing, which can
be considered an upside too...


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Legal advice regarding the NEW queue

[Andrey Rahmatullin]

On Tue, Feb 01, 2022 at 09:18:07AM -0800, Russ Allbery wrote:
> I would hate to entirely lose the quality review that we get via NEW, but
> I wonder if we could regain many those benefits by setting up some sort of
> peer review system for new packages that is less formal and less
> bottlenecked on a single team than the current NEW processing setup.
What do you think, would it be more or less staffed than the current RFS
review process?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Unplanned freeze?

[Andrey Rahmatullin]

On Fri, Jan 28, 2022 at 07:53:02AM +0100, Ole Streicher wrote:
> I just observed that many of my packages that are currently in unstable
> are not migrating because of
> 
> | Not touching package due to block request by elbrus (Follow the freeze
> | policy when applying for an unblock)
> 
> where the "freeze policy" is linked to the bookworm Freeze Timeline (?).
> 
> f.e. https://tracker.debian.org/pkg/photutils
> 
> However, I couldn't find an announcement of a freeze in d.d.a. What is
> the cause of this?
http://bugs.debian.org/1004272
I agree that it should have been announced somewhere in addition to the
#debian-devel topic.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: generic viewer for md files

[Andrey Rahmatullin]

On Mon, Jan 24, 2022 at 12:46:40PM +0100, Jerome BENOIT wrote:
> I am asking because a software that I am currently packaging has its documents
> in MarDown (GitHub flavour, I guess).
You can likely read those with `less`.
Alternatively, software is likely to ship a build script for e.g. HTML in
which case you should use it (see
https://www.debian.org/doc/debian-policy/ch-docs.html#preferred-documentation-formats).

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: generic viewer for md files

[Andrey Rahmatullin]

On Mon, Jan 24, 2022 at 10:36:50AM +0100, Jerome BENOIT wrote:
> is there a virtual package for viewing MD documents
Do you mean Markdown? Are there specialized viewers for it at all?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: How to contribute ?

[Andrey Rahmatullin]

On Sun, Jan 02, 2022 at 11:07:10AM -0600, Zebediah Figura wrote:
> > > > > vkd3d 1.2-6 in Experimental is not usable in Sid because it needs
> > > > > mesa-vulkan-driver << 21.
> > > > > 
> > > > > Michael did that because vkd3d tests fails during building. I don't 
> > > > > know
> > > > > why because it fails with mesa 20 too.
> > > > > 
> > > > > I opened a bug report upstream and wine/vkd3d developer told me that 
> > > > > there
> > > > > is this issue because of nobody has the same GPU (someone can have the
> > > > > error and someone else not)
> > > > The tests shouldn't access the GPU though so it shouldn't depend on 
> > > > actual
> > > > hardware.
> > > 
> > > Sorry, can you please clarify? libvkd3d is essentially a GPU driver (well,
> > > translation layer), so its tests need to access the GPU or they're
> > > meaningless.
> > OK, if the tests need access to actual hardware then they must be turned
> > off during the package build process.
> > (though of course tests for code that needs hardware don't necessarily
> > need hardware too)
> > 
> 
> Is there a codified set of guidelines for what a test can and can't do?
A build time test can do only what a package build process can do, which,
while I don't think this part is codified, certainly cannot rely on even
presence of specific hardware.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: DD(s) to help DM land some long-overdue package updates?

[Andrey Rahmatullin]

On Sat, Jan 01, 2022 at 07:06:09PM +, Reuben Thomas wrote:
> Here's a summary of the packages I'm trying to update. If any DD can help me
> get these uploaded, I'd be most grateful
The packages you listed are not orphaned and the changes you listed don't
warrant NMUs so your only options are either sending your updated packages
to their current maintainers, or
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging

> I really just need a sponsor for uploads 
Well, that's not how it works for non-orphaned packages.
Otherwise, see https://mentors.debian.net/sponsors/

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: How to contribute ?

[Andrey Rahmatullin]

On Fri, Dec 31, 2021 at 02:47:22PM -0600, Zebediah Figura wrote:
> > > vkd3d 1.2-6 in Experimental is not usable in Sid because it needs
> > > mesa-vulkan-driver << 21.
> > > 
> > > Michael did that because vkd3d tests fails during building. I don't know
> > > why because it fails with mesa 20 too.
> > > 
> > > I opened a bug report upstream and wine/vkd3d developer told me that there
> > > is this issue because of nobody has the same GPU (someone can have the
> > > error and someone else not)
> > The tests shouldn't access the GPU though so it shouldn't depend on actual
> > hardware.
> 
> Sorry, can you please clarify? libvkd3d is essentially a GPU driver (well,
> translation layer), so its tests need to access the GPU or they're
> meaningless.
OK, if the tests need access to actual hardware then they must be turned
off during the package build process.
(though of course tests for code that needs hardware don't necessarily
need hardware too)

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: How to contribute ?

[Andrey Rahmatullin]

On Fri, Dec 31, 2021 at 03:37:05PM +0100, Maxime Lombard wrote:
> vkd3d 1.2-6 in Experimental is not usable in Sid because it needs
> mesa-vulkan-driver << 21.
> 
> Michael did that because vkd3d tests fails during building. I don't know
> why because it fails with mesa 20 too.
> 
> I opened a bug report upstream and wine/vkd3d developer told me that there
> is this issue because of nobody has the same GPU (someone can have the
> error and someone else not)
The tests shouldn't access the GPU though so it shouldn't depend on actual
hardware.

> The question is :
> It is possible to don't make the test to package the app ?
> --> it's possible to pass "--disable-tests" as argument for configure.
You should disable only the tests that are flaky, not all of them.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: How to contribute ?

[Andrey Rahmatullin]

On Tue, Dec 21, 2021 at 07:47:47PM +0100, Maxime Lombard wrote:
> Hello,
> 
> I'm an user of Debian since 10 years ago and it's only now that i decide to
> help to packaging.
> I send this email about wine and wine-development package which are not
> updated since a very long time.
Normally you should contact the maintainers if you want to help
maintaining some packages.

> Nowadays, the last package of wine-development was uploaded ~6 months ago.
> More bugs report opened the last months have no answer from Maintainer
> (999753, 995580), same thing with vkd3d bug (994186, 993570)
Unless all maintainers are MIA you can't really do anything except making
NMUs for things that are allowed in NMUs, or sending your work to the
maintainers hoping they will use it.
There is also
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
but I wouldn't recommend it when packages are complex and you don't have
enough experience with packaging and contributing yet. You may be able to
find other would-be-maintainers though.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Reopen RFP Skia - Google's 2D graphic suite

[Andrey Rahmatullin]

On Mon, Dec 13, 2021 at 02:51:55PM +0100, maxzor wrote:
> TL;DR Please consider reopening the following request for packaging :
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818180
You could that yourself. On the other hand, having an RFP doesn't mean
anything so reopening it is not useful. If someone wants to package it
they could do that with or without the RFP existing.

> I believe that the effort of decoupling Skia from the upstream packages
> can be worth it. It could to allow more people to hear about the existence
> of
> the library in the first place, to study its algorithms,
> and maybe build upon them. 
Somebody still needs to do that, and then maintain the package in Debian.

> I do not have the rights on the request mail server to unarchive the RFP.
I don't think the concept of such rights exists.

>  Hello again, do you know why skia is not packaged?
>  maxzor: assuming it meets the DSFG, it is often lack of someone
> volunteering to do the work
This is correct.

>  maxzor: Didn't you just ask this in #ubuntu?
>  I did jkc, I was received... strangely
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818180 -- hmm
> unsure why that bug was marked as done and archived, but there was an RFP
> bug for it a while ago. MAybe they close old RFP bugs if no one steps up
> since projects can die and not be needed. Also could be a library not needed
> by other things in debian.
It was indeed closed due to inactivity, as can be seen in the close email.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: How to do 32-bit build in AMD64 chroot -- problem with SSE instructions?

[Andrey Rahmatullin]

On Sat, Dec 11, 2021 at 05:12:50PM -0600, Steven Robbins wrote:
> I've built the ITK package on my AMD64 machine without trouble, but the 
> 32-bit 
> build is failing with the error below. 
It's failing on buildds with the same problem so you are running the build
itself correctly.

> The errors seem to point to using SSE instructions.  Is there a recommended 
> set of flags to use when building for x86?
Normally you don't need to do anything, no. And when you do, it depends on
the upstream.
For example, in this case it's not about compilation flags because the
relevant code uses SSE2 explictly when USE_SSE2_32IMPL is set. I haven't
checked how is it set but the configure step output suggests it checks the
hardware support on the build machine, which must not be done in Debian
packages. So the first step would be finding how to disable this. There
may be other steps needed.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Consequences of the NEW queue's length [Was: Remove packages from NEW queue?]

[Andrey Rahmatullin]

On Thu, Nov 18, 2021 at 04:08:23PM +0100, Stephan Lachnit wrote:
> > > I don't know if that has been proposed before, but how about waiving
> > > the NEW queue requirement for experimental packages as a start?
> > > [...] Since packages in experimental will never land in any
> > > official release, I think dropping the NEW queue requirement has no
> > > negative impact.
> > This makes no sense as NEW is mostly about checking licenses.
> 
> I think this is exactly why it makes sense. I think we can trust the
> DDs to not make any large mistakes (e.g. putting steam in main).
The existence of NEW means we currently don't, for completely new
packages.

> Since packages in experimental aren't supposed to be used by anyone else
> but the DDs themselves, the "damage" of a potentially missing / wrong
> license is minimal, considering that DDs are aware of the fact that the
> packages aren't "official".
The "damage" that's usually being discussed is Debian distributing
something we can't, not users e.g. getting non-free software thinking it's
free. Packages in NEW aren't even publicly accessible because of this,
and discussions of switching to git-based source packages end with "we
can't publish git history of random repos as we don't want to review
and rewrite it".

> However I find that view a bit weird. Any update can change the license
> or add new files with different licenses, nothing is ever checked by the
> ftp-masters (that would be insanity).
Sure.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Consequences of the NEW queue's length [Was: Remove packages from NEW queue?]

[Andrey Rahmatullin]

On Thu, Nov 18, 2021 at 02:52:56PM +0100, Stephan Lachnit wrote:
> I don't know if that has been proposed before, but how about waiving
> the NEW queue requirement for experimental packages as a start?
> [...] Since packages in experimental will never land in any
> official release, I think dropping the NEW queue requirement has no
> negative impact.
This makes no sense as NEW is mostly about checking licenses.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Mapping Reproducibility Bug Reports to Commits

[Andrey Rahmatullin]

On Sun, Nov 14, 2021 at 05:53:24PM +, Muhammad Hassan wrote:
> Hi all,
> 
> I am a researcher at the University of Waterloo, conducting a project to 
> study reproducibility issues in Debian packages.
> 
> The first step for me is to link each Reproducibility-related bug at this 
> link: 
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?usertag=reproducible-bui...@lists.alioth.debian.org
>  to the corresponding commit that fixed the bug.
This task implies that packaging for all Debian packages is stored in some
VCS, those repos are public, specific commits are marked as fixing
specific bugs and probably, depending on the specifics of the task, that
commits are granular. None of this is true. The best you can do is find
which uploads closed those bugs, using their "fixed in version" data.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Crypto Libs: Linking to OpenSSL, GnuTLS, NSS, ..?

[Andrey Rahmatullin]

On Fri, Nov 12, 2021 at 12:03:53PM +, Stephan Verbücheln wrote:
> Then I also think that OpenSSL 0.9.x/1.x and the new OpenSSL 3.x have
> to be treated like two completely different libraries. They have
> different licenses and intentionally broke APIs to end the mess that
> OpenSSL was. 
When you say "intentionally broke APIs to end the mess that OpenSSL was"
you shouldn't say "0.9.x/1.x":
https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes

> It is a situation like Python 2 and 3, we will have both around for a
> long time, because upstream code has to be ported to new APIs.
Just like for 1.1? Or do you think it will be longer this time?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Short description disapearing from package tracker

[Andrey Rahmatullin]

On Thu, Nov 11, 2021 at 07:16:50PM +0100, Ben Tris wrote:
> Maybe I did make a mistake. Is the description of the first binary visible at 
> the source package?
No, otherwise all pages would have some description.
The description of the binary with the same name as the source package is
displayed.

> Why is there not a seperate description for a source package
There is a very recent policy bug about adding this:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998165

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Crypto Libs: Linking to OpenSSL, GnuTLS, NSS, ..?

[Andrey Rahmatullin]

On Thu, Nov 11, 2021 at 08:01:54AM -0800, Russ Allbery wrote:
> (Didn't Red Hat attempt to standardize on NSS a while back?  I feel like
> that didn't work and they stopped that effort, but some quick searching
> didn't uncover any support for that belief.)
https://fedoraproject.org/wiki/Fedora_Crypto_Consolidation
https://fedoraproject.org/wiki/FedoraCryptoConsolidationBackup

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: pan blend lists game powder should be removed (relative: debichem science medical)

[Andrey Rahmatullin]

On Thu, Nov 11, 2021 at 07:47:20AM +0100, Andreas Tille wrote:
> For some reason git blamed me for injecting this into the mx task and
> so I removed it[1].  I'm pretty sure that I never edited the pan tasks
> despite git blames me about this.  No idea what's wrong here and it
> would be great if some of the pan team would check these tasks for
> some unclear edits.
If you haven't found it yourself from the blame output,
https://salsa.debian.org/blends-team/pan/-/commit/d053f45a61d9d648885fbc64fb41e94465a54c4b
Well, and
https://salsa.debian.org/blends-team/pan/-/commit/8c7efc8befca7cd5a668c20ccd8a8c544c9d23d9

-- 
WBR, wRAR


signature.asc
Description: PGP signature