Re: Firmware GR result - what happens next?

[David Prévot]

Hi,

Le 03/10/2022 à 01:00, Lennart Sorensen a écrit :
[…]

I can't think of ever having had to add anything, only
change the release name.


You’ll change your mind when you’ll upgrade to stable.

https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information#security-archive

Regards

David

Bug#1021158: ITP: mrbuild -- Simple build system

[Dima Kogan]

Package: wnpp
Owner: Dima Kogan 
Severity: wishlist

* Package name: mrbuild
  Version : 1.0
  Upstream Author : Dima Kogan 
* URL or Web page : https://github.com/dkogan/mrbuild
* License : MIT
  Description : Simple build system

This is the build system for mrcal, mrgingham and others

Re: Firmware GR result - what happens next?

[Charles Plessy]

Le Mon, Oct 03, 2022 at 12:33:20AM +0200, Mattia Rizzolo a écrit :
> 
> I can live with an APT hook warning me if I have non-free but not
> non-free-firmware, but I would prefer to even do without that.

In addition, how about distributing the firmware in both 'non-free' and
'non-free-firmware' at the same time for a release or two ?

Cheers,

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Re: Firmware GR result - what happens next?

[Lennart Sorensen]

On Sun, Oct 02, 2022 at 08:21:31PM +0100, Steve McIntyre wrote:
> Two things:
> 
>  1. I'm worried what bugs we might expose by having packages be in two
> components at once.
>  2. I really don't like the idea of leaving two different
> configurations in the wild; it'll confuse people and is more
> likely to cause issues in the future IMHO.
> 
> Plus, as Shengjing Zhu points out: we already expect people to manage
> the sources.list anyway on upgrades.

People that just have 'stable' in their sources.list haven't had to
do anything.  I can't think of ever having had to add anything, only
change the release name.

This will get missed and it will get missed a lot.

-- 
Len Sorensen

Re: Firmware GR result - what happens next?

[Mattia Rizzolo]

On Mon, Oct 03, 2022 at 01:18:55AM +0300, Dmitry Baryshkov wrote:
> вс, 2 окт. 2022 г. в 22:36, Steve Langasek :
> > > So this is the one bit that I don't think we currently have a good
> > > answer for. We've never had a specific script to run on upgrades (like
> > > Ubuntu do), so this kind of potentially breaking change doesn't really
> > > have an obvious place to be fixed.
> >
> > > Obviously we'll need to mention this in the release notes for
> > > bookworm. Should we maybe talk about adding an upgrade helper tool?
> >
> > I heartily endorse ubuntu-release-upgrader, it has been useful in addressing
> > uncounted upgrade issues over the years and I think something like this
> > would be a nice addition to Debian as well.  Two caveats:
> 
> I'd kindly ask against additional upgrade scripts. It is too easy to
> miss them, especially if one has been using Debian for ages with bare
> apt-get update && apt-get dist-upgrade.
> Moreover such a script will not help people that are already using testing.
> 
> For the past few decades, updating the setup was always a job of the
> package scripts.

This is getting OT in this thread, but I agree with the many that are
against such upgrading script.

I consider even the need for such thing a bug, as each package should
take care of its own quirks.

Besides, if something wants to mess with my system configuration, that's
an even greater bug for me (something that IME ubuntu has been doing
more and more over the last years).


I can live with an APT hook warning me if I have non-free but not
non-free-firmware, but I would prefer to even do without that.

For stable→stable updates there are the release notes for this tiny
change.
For testing/unstable users, they should really read d-d-a, and this
change be announced there (if it hasn't already).

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Firmware GR result - what happens next?

[Dmitry Baryshkov]

Hello,

вс, 2 окт. 2022 г. в 22:36, Steve Langasek :
>
> On Sun, Oct 02, 2022 at 03:53:00PM +0100, Steve McIntyre wrote:
> > >What's the plan for upgraded systems with an existing 
> > >/etc/apt/sources.list.
> > >Will the new n-f-f section added on upgrades automatically(if non-free was
> > >enabled before)?
>
> > So this is the one bit that I don't think we currently have a good
> > answer for. We've never had a specific script to run on upgrades (like
> > Ubuntu do), so this kind of potentially breaking change doesn't really
> > have an obvious place to be fixed.
>
> > Obviously we'll need to mention this in the release notes for
> > bookworm. Should we maybe talk about adding an upgrade helper tool?
>
> I heartily endorse ubuntu-release-upgrader, it has been useful in addressing
> uncounted upgrade issues over the years and I think something like this
> would be a nice addition to Debian as well.  Two caveats:

I'd kindly ask against additional upgrade scripts. It is too easy to
miss them, especially if one has been using Debian for ages with bare
apt-get update && apt-get dist-upgrade.
Moreover such a script will not help people that are already using testing.

For the past few decades, updating the setup was always a job of the
package scripts. Thus we potentially can have an addon in the apt's
postinstall script that will check if the user is running bookworm,
the non-free repo is enabled and non-free-firmware is not. In such
case postinst can present user with a choice of ignoring n-f-f,
attempting automatic '/bookworm/s/non-free/non-free
non-free-firmware/' or letting user to fix setup. This way the user
will be present with such choice whichever path he uses to update to
bookworm.


-- 
With best wishes
Dmitry

Re: Firmware GR result - what happens next?

[Thomas Goirand]

Hi Steve,

On 10/2/22 21:26, Steve Langasek wrote:

I heartily endorse ubuntu-release-upgrader, it has been useful in addressing
uncounted upgrade issues over the years and I think something like this
would be a nice addition to Debian as well.  Two caveats:

  - Despite this being the sanctioned upgrade path in Ubuntu for over a
decade, every single cycle we get bug reports from users who have run
into issues because they have bypassed it and done the manual sed
/etc/apt/sources.list && apt dist-upgrade.  So in Debian where this has
been the norm for /two/ decades, I would not expect this to substantially
reduce the error rate in the first release where such a mechanism is
introduced.  (After all, whether telling users to use a new upgrader tool
or telling them to manually add a component to sources.list, they will
have to read the release notes to know about it!)

  - There are always some users that end up with buggy systems after upgrade
despite using the supported interface because they upgrade to the devel
release, and the release-upgrader is still under development up until
release so they miss out on quirks being applied - and there is no
interface for users to replay the quirks that they missed out on.  Don't
repeat the same design mistake.


I very much dislike the Ubuntu approach, but not only because of the 
above. Also because this approach forgets the fact that we also maintain 
2 rolling-updates distro (testing and unstable).



In the absence of a release-upgrader, the only way I see to automate this on
upgrade would be to handle it in the maintainer scripts of either base-files
(which I don't think the base-files maintainer would like) or apt.


If the base-files maintainer (ie: Santiago Vila) doesn't like doing 
things like this in "his" package, maybe we could have base-file >> 12.2 
depend on another package (called non-free-upgrade?) that would do the 
work instead. We could even have only base-file to depend on that 
package for a single release (ie: only for the lifetime of bookworm, and 
we get rid of the package after the release).


I think that's an even better approach than having this done in 
base-files itself.


Your thoughts?

Cheers,

Thomas Goirand (zigo)

Re: Firmware GR result - what happens next?

[Thomas Goirand]

On 10/2/22 22:02, Russ Allbery wrote:

Michael Biebl  writes:


The main difference is, that the renaming caused an error message by
apt, so you knew something needed to be fixed.


One could argue that having non-free but not non-free-firmware is
sufficiently strange that it would be worth a suppressable apt warning
(that you could turn off in apt.conf).  I have no idea how easy that would
be to implement, though.


Hi!

I would very much prefer having this implemented in the base_files 
package. This is *the* package that follows releases, so that's IMO the 
best location.


I would hate having to use an upgrade program like in Ubuntu. :/

An easy check could be:
1/ are we upgrading from base-files << 12.3 (we're currently at 12.2 in Sid)
AND
2/ is there the non-free repo installed in the default sources.list
AND
3/ non-free-firmware repo isn't installed

THEN

warn user with debconf.

Checking the configuration of a non-free and non-free-firmware is kind 
of hard, because just reading/parsing source.list and source.list.d that 
could be filled with non-debian repos can be quite hard. Though we could 
imagine tricks, like where both repo would include a special package 
present only for that test, and we just see if it is available with 
apt-cache policy for example (this is just an idea... not sure if 
there's better options).


Eventually, and propose automatically adding the n-f-f repo, if some of 
you really want to, but I'd prefer if at least this could be the 
non-default debconf answer (because on non-interactive setup, without 
access to internet (only to a local mirror), this could really mess 
things up).


Your thoughts everyone?
Cheers,

Thomas Goirand (zigo)

P.S: I'm unfortunately *not* volunteering for implementing the above as 
I wont have enough time to do it properly, though I just hope my above 
suggestion helps...

Re: FTBS bugs -- MBF?

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Lucas Nussbaum (2022-10-02 21:51:52)
> On 02/10/22 at 04:23 +0200, Adam Borowski wrote:
> > Nǐmen hǎo!
> > I did another _source_ rebuild of the archive -- checking if every package
> > is capable of repacking its source.  Ie, if you can unpack it, (possibly
> > modify), and pack again.
> > 
> > Putting aside packages that are broken in other ways as well (B-Depends
> > non-installable, FTBFS or a RC bug), there seems to be no new fancy types
> > of breakage that haven't been fixed in 2020.
> > 
> > This leaves one big set: packages that fail the clean step due to
> > undeclared B-Depends.  According to the Policy:
> > 
> > # "clean"
> > #Only the "Build-Depends" and "Build-Conflicts" fields must be
> > #satisfied when this target is invoked.
> > 
> > ... which makes sense as you might be interested in only an arch:all or
> > arch:any build, and we have no clean-indep/clean-arch targets.
> > 
> > For sbuild, the incantation is:
> > alias sbuild-source='sbuild -s --source-only-changes --no-arch-all 
> > --no-arch-any --no-run-autopkgtest'
> > 
> > As 291 packages fail this requirement, I'm posting here before (instead?)
> > filing bugs.  There's also a question of severity.
> > 
> > Raw list and dd-list attached.
> 
> All those source packages are Architecture: all.
> 
> To make this easier to detect (and avoid regressions in the long term),
> I wonder if sbuild should have an option that would make it do, for a
> source+all build:

please do not abuse sbuild to produce source packages. Source packages are the
input to sbuild and not its output. Sbuild has some convenience features that
let it create the source package for you from an unpacked directory so that you
do not have to do that step manually but that doesn't change the fact that to
operate it still needs to create a dsc first.

Instead of trying to use the -s or --source option, use the
--source-only-changes option instead which will not re-create the source
package but gives you a .changes file ready to a source-only upload anyways in
addition to the arch-all or arch-any .changes file.

> - install B-D
> - run clean
> - install B-D-I
> - build the binary packages

This will be tricky to implement because sbuild doesn't run the clean target.
Instead it runs dpkg-buildpackage which then runs the clean target. But feel
free to try and implement it and file a merge request on salsa. Maybe it's not
as bad as I fear.

Changing salsa-ci.yml to test for this would not be easy either, because
"apt-get build-dep" only exposes the --arch-only and --indep-only options. So
there is no way to tell apt "only the dependencies for the clean target,
please".

Thanks!

cheers, josch

signature.asc
Description: signature

Re: FTBS bugs -- MBF?

[Adam Borowski]

On Sun, Oct 02, 2022 at 09:51:52PM +0200, Lucas Nussbaum wrote:
> On 02/10/22 at 04:23 +0200, Adam Borowski wrote:
> > I did another _source_ rebuild of the archive -- checking if every package
> > is capable of repacking its source.  Ie, if you can unpack it, (possibly
> > modify), and pack again.

> All those source packages are Architecture: all.
> 
> To make this easier to detect (and avoid regressions in the long term),
> I wonder if sbuild should have an option that would make it do, for a
> source+all build:
> - install B-D
> - run clean
> - install B-D-I
> - build the binary packages

There is nothing that stops B-D-A being necessary for clean for an arch:any
package.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Genetics say, virgin birth may not possibly produce male offspring.
⣾⠁⢠⠒⠀⣿⡁ Thus, either Jesus was fathered by (Abdes?) Pantera, or she was trans.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄ In neither case Joseph is involved, making Jesus a bastard.

Re: FTBS bugs -- MBF?

[Lucas Nussbaum]

On 02/10/22 at 04:23 +0200, Adam Borowski wrote:
> Nǐmen hǎo!
> I did another _source_ rebuild of the archive -- checking if every package
> is capable of repacking its source.  Ie, if you can unpack it, (possibly
> modify), and pack again.
> 
> Putting aside packages that are broken in other ways as well (B-Depends
> non-installable, FTBFS or a RC bug), there seems to be no new fancy types
> of breakage that haven't been fixed in 2020.
> 
> This leaves one big set: packages that fail the clean step due to
> undeclared B-Depends.  According to the Policy:
> 
> # "clean"
> #Only the "Build-Depends" and "Build-Conflicts" fields must be
> #satisfied when this target is invoked.
> 
> ... which makes sense as you might be interested in only an arch:all or
> arch:any build, and we have no clean-indep/clean-arch targets.
> 
> For sbuild, the incantation is:
> alias sbuild-source='sbuild -s --source-only-changes --no-arch-all 
> --no-arch-any --no-run-autopkgtest'
> 
> As 291 packages fail this requirement, I'm posting here before (instead?)
> filing bugs.  There's also a question of severity.
> 
> Raw list and dd-list attached.

All those source packages are Architecture: all.

To make this easier to detect (and avoid regressions in the long term),
I wonder if sbuild should have an option that would make it do, for a
source+all build:
- install B-D
- run clean
- install B-D-I
- build the binary packages

Lucas

Re: Firmware GR result - what happens next?

[Russ Allbery]

Michael Biebl  writes:

> The main difference is, that the renaming caused an error message by
> apt, so you knew something needed to be fixed.

One could argue that having non-free but not non-free-firmware is
sufficiently strange that it would be worth a suppressable apt warning
(that you could turn off in apt.conf).  I have no idea how easy that would
be to implement, though.

-- 
Russ Allbery (r...@debian.org)  

Bug#1021151: ITP: setuptools-rust -- Plugin for setuptools to build Rust Python extensions

[Edward Betts]

Package: wnpp
Severity: wishlist
Owner: Edward Betts 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: setuptools-rust
  Version : 1.5.2
  Upstream Author : Nikolay Kim 
* URL : https://github.com/PyO3/setuptools-rust
* License : MIT
  Programming Lang: Python
  Description : Plugin for setuptools to build Rust Python extensions

  Compile and distribute Python extensions written in Rust as easily as if
  they were written in C.
 
  Extensions can be implemented with PyO3 or rust-cpython.
 
I plan to maintain this package as part of the Python team.

Re: Firmware GR result - what happens next?

[Steve Langasek]

On Sun, Oct 02, 2022 at 03:53:00PM +0100, Steve McIntyre wrote:
> >What's the plan for upgraded systems with an existing /etc/apt/sources.list.
> >Will the new n-f-f section added on upgrades automatically(if non-free was
> >enabled before)?

> So this is the one bit that I don't think we currently have a good
> answer for. We've never had a specific script to run on upgrades (like
> Ubuntu do), so this kind of potentially breaking change doesn't really
> have an obvious place to be fixed.

> Obviously we'll need to mention this in the release notes for
> bookworm. Should we maybe talk about adding an upgrade helper tool?

I heartily endorse ubuntu-release-upgrader, it has been useful in addressing
uncounted upgrade issues over the years and I think something like this
would be a nice addition to Debian as well.  Two caveats:

 - Despite this being the sanctioned upgrade path in Ubuntu for over a
   decade, every single cycle we get bug reports from users who have run
   into issues because they have bypassed it and done the manual sed
   /etc/apt/sources.list && apt dist-upgrade.  So in Debian where this has
   been the norm for /two/ decades, I would not expect this to substantially
   reduce the error rate in the first release where such a mechanism is
   introduced.  (After all, whether telling users to use a new upgrader tool
   or telling them to manually add a component to sources.list, they will
   have to read the release notes to know about it!)

 - There are always some users that end up with buggy systems after upgrade
   despite using the supported interface because they upgrade to the devel
   release, and the release-upgrader is still under development up until
   release so they miss out on quirks being applied - and there is no
   interface for users to replay the quirks that they missed out on.  Don't
   repeat the same design mistake.

In the absence of a release-upgrader, the only way I see to automate this on
upgrade would be to handle it in the maintainer scripts of either base-files
(which I don't think the base-files maintainer would like) or apt.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: Firmware GR result - what happens next?

[Steve McIntyre]

On Sun, Oct 02, 2022 at 11:08:47AM -0400, Michael Stone wrote:
>On Sun, Oct 02, 2022 at 03:53:00PM +0100, Steve McIntyre wrote:
>> On Sun, Oct 02, 2022 at 04:43:47PM +0200, Michael Biebl wrote:
>> > What's the plan for upgraded systems with an existing 
>> > /etc/apt/sources.list.
>> > Will the new n-f-f section added on upgrades automatically(if non-free was
>> > enabled before)?
>> 
>> So this is the one bit that I don't think we currently have a good
>> answer for. We've never had a specific script to run on upgrades (like
>> Ubuntu do), so this kind of potentially breaking change doesn't really
>> have an obvious place to be fixed.
>
>Is there a reason to not continue to make the packages available in non-free?
>I don't see a reason to force any change on existing systems.

Two things:

 1. I'm worried what bugs we might expose by having packages be in two
components at once.
 2. I really don't like the idea of leaving two different
configurations in the wild; it'll confuse people and is more
likely to cause issues in the future IMHO.

Plus, as Shengjing Zhu points out: we already expect people to manage
the sources.list anyway on upgrades.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You raise the blade, you make the change... You re-arrange me 'til I'm sane...

Re: Firmware GR result - what happens next?

[Steve McIntyre]

On Sun, Oct 02, 2022 at 05:31:16PM +0200, Cyril Brulebois wrote:
>Steve McIntyre  (2022-10-02):
>> * Extra d-i code to inform users about what firmware blobs have been
>>   loaded and the matching non-free-firmware packages. Plus information
>>   about the hardware involved. Maybe a new d-i module / udeb for this?
>>   Exact details here still TBD. Probably the biggest individual piece
>>   of work here.
>
>Not just blobs that were loaded, but also those which might get loaded
>in the installed system (since we don't have all modules around), see
>hw-detect.post-base-installer.d/50install-firmware in hw-detect (udevadm
>vs. modalias stuff).

ACK.

>> * Tweaks to add the non-free-firmware section in the apt-setup module
>>   if desired/needed.
>> 
>> * An extra boot option (a debconf variable) to disable loading extra
>>   firmware automatically, then exposed as an extra option through the
>>   isolinux and GRUB menus. d-i "expert mode" can also be used to tweak
>>   this behaviour later, except (obviously) for things like audio
>>   firmware that *must* be loaded early if they're going to be useful
>>   at all.
>
>The option/variable looks easy enough (once we decide what to call it)…
>Not sure what would be best to expose it to users: bootloader menus
>already have many options (text vs.  graphical, normal vs. rescue,
>accessibility settings, etc.), and don't get internationalization
>support anyway. On the flip side, having to go through a full expert
>installation is very nice.
>
>Maybe start by documenting the option (probably installation guide plus
>release notes), and of course implementing it; then see if/how we expose
>it?

Yup. Very much in that order... :-)

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You lock the door
And throw away the key
There's someone in my head but it's not me 

Re: Q: uscan with GitHub

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Paul Wise (2022-09-20 02:38:30)
> On Mon, 2022-09-19 at 20:50 +0900, Hideki Yamane wrote:
> > Recent changes in GitHub releases pages, I cannot check upstream
> > version with uscan. How do you deal with it?
> 
> If you are using the automatically generated tarballs, then
> just switching to the uscan git mode seems like the way to go.

the only reason I'm not using git mode for all my upstream projects that use
git is this paragraph from the uscan man page:

If the upstream publishes the released tarball via its web
interface, please use it instead of using this mode. This mode is
the last resort method.

This sounds like I should rather use other methods like rewriting my d/watch
files to use api.github.com before using this "last resort" method.

Is this paragraph still accurate?

Thanks!

cheers, josch

signature.asc
Description: signature

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Jonathan McDowell]

On Sun, Oct 02, 2022 at 07:29:31PM +0100, Jonathan McDowell wrote:
> On Thu, Sep 08, 2022 at 05:58:25PM +0200, Dylan Aïssi wrote:
> > Hi,
> > 
> > I have been asked several times regarding when Debian will switch its 
> > default
> > sound server from PulseAudio to PipeWire without having an official answer.
> > Thus, I suppose it's the right time to start a discussion about that.
> 
> Perhaps, now this has actually got as far as testing, someone will be so
> kind as to at least comment on #996750, which I opened almost a year
> ago. It's had no follow-ups and I'm now seeing the same behaviour on a
> system that only has an external screen - it doesn't actually go into
> power save mode. I suspect there's something going on with pipewire and
> HDMI audio, but it's a regression from a pulseaudio setup.

After a bit more patience, and some experimentation, I'm going to have
to recant. It might be taking a _little_ longer to actually hit power
save, but it is now happening and it does seem to recover ok.

Apologies for the noise, I'll follow up to the bug.

J.

-- 
   101 things you can't have too   |  .''`.  Debian GNU/Linux Developer
   much of : 33 - Jokes.   | : :' :  Happy to accept PGP signed
   | `. `'   or encrypted mail - RSA
   |   `-key on the keyservers.

Re: Firmware GR result - what happens next?

[Michael Biebl]

Am 02.10.22 um 20:14 schrieb Luca Boccassi:

On Sun, 2022-10-02 at 10:52 -0700, Russ Allbery wrote:



will
be very obvious.  But if you currently have non-free configured but
don't
add the new firmware section, everything will appear to work but you
won't
get new firmware, so the problem may go unnoticed.


In Bullseye we changed the name/syntax for the security repository, and
for that a mention in the release notes was enough, no? Isn't this a
very similar situation?


The main difference is, that the renaming caused an error message by 
apt, so you knew something needed to be fixed.


For this particular change, there will be no error. So yes, I have the 
same fear as Russ that this particular change might go unnoticed.



Regards,
Michael


OpenPGP_signature
Description: OpenPGP digital signature

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Jonathan McDowell]

On Thu, Sep 08, 2022 at 05:58:25PM +0200, Dylan Aïssi wrote:
> Hi,
> 
> I have been asked several times regarding when Debian will switch its default
> sound server from PulseAudio to PipeWire without having an official answer.
> Thus, I suppose it's the right time to start a discussion about that.

Perhaps, now this has actually got as far as testing, someone will be so
kind as to at least comment on #996750, which I opened almost a year
ago. It's had no follow-ups and I'm now seeing the same behaviour on a
system that only has an external screen - it doesn't actually go into
power save mode. I suspect there's something going on with pipewire and
HDMI audio, but it's a regression from a pulseaudio setup.

J.

-- 
If we sleep together, will you like me better?

Re: Firmware GR result - what happens next?

[Luca Boccassi]

On Sun, 2022-10-02 at 10:52 -0700, Russ Allbery wrote:
> Shengjing Zhu  writes:
> > On Sun, Oct 2, 2022 at 10:53 PM Steve McIntyre 
> > wrote:
> 
> > > So this is the one bit that I don't think we currently have a
> > > good
> > > answer for. We've never had a specific script to run on upgrades
> > > (like
> > > Ubuntu do), so this kind of potentially breaking change doesn't
> > > really
> > > have an obvious place to be fixed.
> 
> > > Obviously we'll need to mention this in the release notes for
> > > bookworm. Should we maybe talk about adding an upgrade helper
> > > tool?
> 
> > For upgrading, people already need to edit their source list to
> > change
> > the suite name, why would it hurt to add one more manual step to
> > change
> > the section name?
> 
> I think the difference is that if you don't update your sources.list
> to
> point to the new suite, your system won't upgrade and so the problem
> will
> be very obvious.  But if you currently have non-free configured but
> don't
> add the new firmware section, everything will appear to work but you
> won't
> get new firmware, so the problem may go unnoticed.

In Bullseye we changed the name/syntax for the security repository, and
for that a mention in the release notes was enough, no? Isn't this a
very similar situation? Is it truly necessary to do more than mention
this in the release notes?

-- 
Kind regards,
Luca Boccassi


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

Re: Firmware GR result - what happens next?

[The Wanderer]

On 2022-10-02 at 13:52, Russ Allbery wrote:

> Shengjing Zhu  writes:
> 
>> On Sun, Oct 2, 2022 at 10:53 PM Steve McIntyre 
>> wrote:
> 
>>> So this is the one bit that I don't think we currently have a
>>> good answer for. We've never had a specific script to run on
>>> upgrades (like Ubuntu do), so this kind of potentially breaking
>>> change doesn't really have an obvious place to be fixed.
> 
>>> Obviously we'll need to mention this in the release notes for 
>>> bookworm. Should we maybe talk about adding an upgrade helper
>>> tool?
> 
>> For upgrading, people already need to edit their source list to
>> change the suite name, why would it hurt to add one more manual
>> step to change the section name?
> 
> I think the difference is that if you don't update your sources.list
> to point to the new suite, your system won't upgrade and so the
> problem will be very obvious.  But if you currently have non-free
> configured but don't add the new firmware section, everything will
> appear to work but you won't get new firmware, so the problem may go
> unnoticed.

There's also the issue of people who track stable or testing by that
name, rather than by the release-specific codename, and so *don't* need
to edit sources.list to start getting the packages from the new release.

I don't know how many of us there are, but I know there's at least me
(for the testing case), and I'd greatly prefer to be able to run an
upgrade and have things Just Work rather than need to make sure I catch
whatever notification comes along and make that change at the right
time to coordinate with when the 'upstream' change is made.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Firmware GR result - what happens next?

[Russ Allbery]

Shengjing Zhu  writes:
> On Sun, Oct 2, 2022 at 10:53 PM Steve McIntyre  wrote:

>> So this is the one bit that I don't think we currently have a good
>> answer for. We've never had a specific script to run on upgrades (like
>> Ubuntu do), so this kind of potentially breaking change doesn't really
>> have an obvious place to be fixed.

>> Obviously we'll need to mention this in the release notes for
>> bookworm. Should we maybe talk about adding an upgrade helper tool?

> For upgrading, people already need to edit their source list to change
> the suite name, why would it hurt to add one more manual step to change
> the section name?

I think the difference is that if you don't update your sources.list to
point to the new suite, your system won't upgrade and so the problem will
be very obvious.  But if you currently have non-free configured but don't
add the new firmware section, everything will appear to work but you won't
get new firmware, so the problem may go unnoticed.

-- 
Russ Allbery (r...@debian.org)  

Re: Firmware GR result - what happens next?

[Shengjing Zhu]

On Sun, Oct 2, 2022 at 10:53 PM Steve McIntyre  wrote:
>
> On Sun, Oct 02, 2022 at 04:43:47PM +0200, Michael Biebl wrote:
> >
> >Hi Steve,
> >
> >thanks for the update!
> >
> >Am 02.10.22 um 16:27 schrieb Steve McIntyre:
> >
> >> * Tweaks to add the non-free-firmware section in the apt-setup module
> >>if desired/needed.
> >
> >...
> >
> >> If you think I've missed anything here, please let me and Cyril know -
> >> the best place would be the mailing list
> >> (debian-b...@lists.debian.org).
> >
> >What's the plan for upgraded systems with an existing /etc/apt/sources.list.
> >Will the new n-f-f section added on upgrades automatically(if non-free was
> >enabled before)?
>
> So this is the one bit that I don't think we currently have a good
> answer for. We've never had a specific script to run on upgrades (like
> Ubuntu do), so this kind of potentially breaking change doesn't really
> have an obvious place to be fixed.
>
> Obviously we'll need to mention this in the release notes for
> bookworm. Should we maybe talk about adding an upgrade helper tool?

For upgrading, people already need to edit their source list to change
the suite name, why would it hurt to add one more manual step to
change the section name?

-- 
Shengjing Zhu

Re: Firmware GR result - what happens next?

[Cyril Brulebois]

Steve McIntyre  (2022-10-02):
> * Extra d-i code to inform users about what firmware blobs have been
>   loaded and the matching non-free-firmware packages. Plus information
>   about the hardware involved. Maybe a new d-i module / udeb for this?
>   Exact details here still TBD. Probably the biggest individual piece
>   of work here.

Not just blobs that were loaded, but also those which might get loaded
in the installed system (since we don't have all modules around), see
hw-detect.post-base-installer.d/50install-firmware in hw-detect (udevadm
vs. modalias stuff).

> * Tweaks to add the non-free-firmware section in the apt-setup module
>   if desired/needed.
> 
> * An extra boot option (a debconf variable) to disable loading extra
>   firmware automatically, then exposed as an extra option through the
>   isolinux and GRUB menus. d-i "expert mode" can also be used to tweak
>   this behaviour later, except (obviously) for things like audio
>   firmware that *must* be loaded early if they're going to be useful
>   at all.

The option/variable looks easy enough (once we decide what to call it)…
Not sure what would be best to expose it to users: bootloader menus
already have many options (text vs.  graphical, normal vs. rescue,
accessibility settings, etc.), and don't get internationalization
support anyway. On the flip side, having to go through a full expert
installation is very nice.

Maybe start by documenting the option (probably installation guide plus
release notes), and of course implementing it; then see if/how we expose
it?


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


signature.asc
Description: PGP signature

Re: Firmware GR result - what happens next?

[Jeremy Bicha]

On Sun, Oct 2, 2022 at 10:53 AM Steve McIntyre  wrote:
> On Sun, Oct 02, 2022 at 04:43:47PM +0200, Michael Biebl wrote:
> >What's the plan for upgraded systems with an existing /etc/apt/sources.list.
> >Will the new n-f-f section added on upgrades automatically(if non-free was
> >enabled before)?
>
> So this is the one bit that I don't think we currently have a good
> answer for. We've never had a specific script to run on upgrades (like
> Ubuntu do), so this kind of potentially breaking change doesn't really
> have an obvious place to be fixed.

There is /etc/apt/sources.list.d/ . One idea is that you could have a
package install a non-free-firmware apt source line there without
needing to touch anyone's primary /etc/apt/sources.list

I'm guessing things that change apt sources for mirrors would need to
be able to handle that file, but maybe they needed to handle
sources.list.d/ anyway.

Thank you,
Jeremy Bicha

Re: Firmware GR result - what happens next?

[Michael Stone]

On Sun, Oct 02, 2022 at 03:53:00PM +0100, Steve McIntyre wrote:

On Sun, Oct 02, 2022 at 04:43:47PM +0200, Michael Biebl wrote:

What's the plan for upgraded systems with an existing /etc/apt/sources.list.
Will the new n-f-f section added on upgrades automatically(if non-free was
enabled before)?


So this is the one bit that I don't think we currently have a good
answer for. We've never had a specific script to run on upgrades (like
Ubuntu do), so this kind of potentially breaking change doesn't really
have an obvious place to be fixed.


Is there a reason to not continue to make the packages available in 
non-free? I don't see a reason to force any change on existing systems.

Re: Firmware GR result - what happens next?

[Steve McIntyre]

On Sun, Oct 02, 2022 at 04:43:47PM +0200, Michael Biebl wrote:
>
>Hi Steve,
>
>thanks for the update!
>
>Am 02.10.22 um 16:27 schrieb Steve McIntyre:
>
>> * Tweaks to add the non-free-firmware section in the apt-setup module
>>if desired/needed.
>
>...
>
>> If you think I've missed anything here, please let me and Cyril know -
>> the best place would be the mailing list
>> (debian-b...@lists.debian.org).
>
>What's the plan for upgraded systems with an existing /etc/apt/sources.list.
>Will the new n-f-f section added on upgrades automatically(if non-free was
>enabled before)?

So this is the one bit that I don't think we currently have a good
answer for. We've never had a specific script to run on upgrades (like
Ubuntu do), so this kind of potentially breaking change doesn't really
have an obvious place to be fixed.

Obviously we'll need to mention this in the release notes for
bookworm. Should we maybe talk about adding an upgrade helper tool?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Into the distance, a ribbon of black
Stretched to the point of no turning back

Firmware GR result - what happens next?

[Steve McIntyre]

Hi all!

[ I've also blogged about this - see
  https://blog.einval.com/2022/10/02#firmware-vote-result ]

I'm assuming that there will be no surprises and Kurt will shortly
confirm the result that devotee reported already [1]. :-)

We have quite a few things to do now, ideally before the freeze for
Debian 12 (bookworm), due January 2023 [2]. This list of work items is
almost definitely not complete, and Cyril and I are aiming to get
together this week and do more detailed planning for the d-i
pieces. Off the top of my head I can think of the following:

* Update the SC with the new text, update the website.

* Check/add support for the non-free-firmware section in various
  places:
  + d-i build
  + debian-cd
  + debmirror (?)
  + ftpsync (?)
  + Any others?

* Uploads of firmware packages targeting non-free-firmware.

* Extra d-i code to inform users about what firmware blobs have been
  loaded and the matching non-free-firmware packages. Plus information
  about the hardware involved. Maybe a new d-i module / udeb for this?
  Exact details here still TBD. Probably the biggest individual piece
  of work here.

* Tweaks to add the non-free-firmware section in the apt-setup module
  if desired/needed.

* An extra boot option (a debconf variable) to disable loading extra
  firmware automatically, then exposed as an extra option through the
  isolinux and GRUB menus. d-i "expert mode" can also be used to tweak
  this behaviour later, except (obviously) for things like audio
  firmware that *must* be loaded early if they're going to be useful
  at all.

* Update the image build scripts to include the n-f-f packages, only
  build one type of image. I'll do my best to keep config and support
  around too for images without n-f-f included, to make it easier to
  still build those for people who still want them.

* Matching updates to docs, website, wiki etc.

* ...

If you think I've missed anything here, please let me and Cyril know -
the best place would be the mailing list
(debian-b...@lists.debian.org). If you'd like to help implement any of
these changes, that would be lovely too!

[1] https://lists.debian.org/debian-vote/2022/10/msg0.html
[2] https://lists.debian.org/debian-devel/2022/03/msg00251.html

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
There's no sensation to compare with this
Suspended animation, A state of bliss

Bug#1021118: ITP: golang-github-dennwc-btrfs -- btrfs library for Go

[Daniel Swarbrick]

Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: golang-github-dennwc-btrfs
  Version : 0.0~git20220403.b3db0b2
  Upstream Author : Denys Smirnov 
* URL : https://github.com/dennwc/btrfs
* License : Apache-2.0
  Programming Lang: Go
  Description : btrfs library for Go

btrfs library for Go, providing access to low-level management functions
of btrfs filesystems.

This package is a new build-dep for the btrfs collector in Prometheus
node_exporter >= v1.4.0. I will co-maintain this package as part of the
Debian Go packaging team.

Bug#1021116: ITP: golang-github-dennwc-ioctl -- ioctl library for Go

[Daniel Swarbrick]

Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: golang-github-dennwc-ioctl
  Version : 1.0.0
  Upstream Author : Denys Smirnov 
* URL : https://github.com/dennwc/ioctl
* License : MIT
  Programming Lang: Go
  Description : ioctl library for Go

Lightweight ioctl library for Go, providing functions for performing
read/write ioctl operations.

This package is dependency of github.com/dennwc/btrfs, and thus an
indirect dependency of Prometheus node_exporter 1.4.0+. It appears
fairly inactive, as it is functionally complete and mature. I don't
expect it to require much maintenance going forward, however I will
co-maintain it as part of the Debian Go packaging team.

Re: FTBS bugs -- MBF?

[Mattia Rizzolo]

On Sun, Oct 02, 2022 at 10:57:11AM +0100, Simon McVittie wrote:
> > Packages that only build Architecture: all binary packages tend to use
> > Build-Depends-Indep.
> 
> Policy is quite clear about that being a bug. I think a better rule of
> thumb for maintainers in a hurry would be: if you don't have time to think
> about which dependency list is the right one, and preferably test the
> result (with a source-only build like Adam has been doing, a --build=all
> build, and a --build=any build), then the safe option is to put everything
> in B-D.


I totally agree, and I consider that a RC bug in my mind.

I would support filing all the bugs as sev:important, and bump them
right after the bookworm release (so we don't add all these RC bugs so
near the freeze, even if they are trivial to fix).

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: FTBS bugs -- MBF?

[Simon McVittie]

On Sun, 02 Oct 2022 at 10:16:00 +0200, Sebastiaan Couwenberg wrote:
> On 10/2/22 04:23, Adam Borowski quoted Policy:
> > # "clean"
> > #Only the "Build-Depends" and "Build-Conflicts" fields must be
> > #satisfied when this target is invoked.
> 
> Shouldn't Build-Depends-Indep be considered as part of Build-Depends?

I think that would defeat the purpose of splitting B-D, B-D-I and B-D-A.
A common reason to use B-D-I is that building documentation needs a
relatively "heavy" tool like doxygen, gtk-doc or TeX, which is time-
and space-consuming to install and harder to satisfy during architecture
bootstrapping.

If we required B-D-I to be satisfied for clean, then that would mean
the documentation tool would be required when running dpkg-buildpackage -B,
which expands to somethng similar to

debian/rules clean
debian/rules build-arch
debian/rules binary-arch

That would have the same practical result as moving everything from
B-D-I to B-D.

> Packages that only build Architecture: all binary packages tend to use
> Build-Depends-Indep.

Policy is quite clear about that being a bug. I think a better rule of
thumb for maintainers in a hurry would be: if you don't have time to think
about which dependency list is the right one, and preferably test the
result (with a source-only build like Adam has been doing, a --build=all
build, and a --build=any build), then the safe option is to put everything
in B-D.

smcv

Re: FTBS bugs -- MBF?

[Shengjing Zhu]

Package: dh-golang
Severity: wishlist
Control: retitle -1 dh-golang unnecessary call for go command in clean target

> Apparently there's not a single package that needs B-D-Arch.  I've just
> looked in case if sbuild installs those by default, but it's not the case.
> A sample package (acmetool) for example says:
>
> dh clean --buildsystem=golang --with=golang,apache2
>dh_auto_clean -O--buildsystem=golang
> Can't exec "go": No such file or directory at 
> /usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 443.
> Use of uninitialized value in pattern match (m//) at 
> /usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 443.
> Can't exec "go": No such file or directory at 
> /usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 449.
> Use of uninitialized value in pattern match (m//) at 
> /usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 449.
> Use of uninitialized value $_gcc_major in multiplication (*) at 
> /usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 450.
>dh_autoreconf_clean -O--buildsystem=golang
>dh_clean -O--buildsystem=golang
>  dpkg-source -b .

Looks like a bug in dh-golang, it shouldn't need to use the compiler to clean.

-- 
Shengjing Zhu

Re: FTBS bugs -- MBF?

[Adam Borowski]

On Sun, Oct 02, 2022 at 08:40:04AM +0200, Lucas Nussbaum wrote:
> On 02/10/22 at 04:23 +0200, Adam Borowski wrote:
> > I did another _source_ rebuild of the archive -- checking if every package
> > is capable of repacking its source.  Ie, if you can unpack it, (possibly
> > modify), and pack again.
[...]
> > This leaves one big set: packages that fail the clean step due to
> > undeclared B-Depends.
[...]
> > ... which makes sense as you might be interested in only an arch:all or
> > arch:any build, and we have no clean-indep/clean-arch targets.
[...]
> > As 291 packages fail this requirement, I'm posting here before (instead?)
> > filing bugs.  There's also a question of severity.

> Are you saying that those 291 packages fail when only
> Build-Depends/Build-Conflicts are satisfied, but do not fail when
> Build-Depends-Indep is also satisfied?

Yes, exactly.

> FWIW, when I do archive rebuilds, I rebuild the source, but that's with
> Build-Depends-Indep installed.

Apparently there's not a single package that needs B-D-Arch.  I've just
looked in case if sbuild installs those by default, but it's not the case.
A sample package (acmetool) for example says:

dh clean --buildsystem=golang --with=golang,apache2
   dh_auto_clean -O--buildsystem=golang
Can't exec "go": No such file or directory at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 443.
Use of uninitialized value in pattern match (m//) at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 443.
Can't exec "go": No such file or directory at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 449.
Use of uninitialized value in pattern match (m//) at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 449.
Use of uninitialized value $_gcc_major in multiplication (*) at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 450.
   dh_autoreconf_clean -O--buildsystem=golang
   dh_clean -O--buildsystem=golang
 dpkg-source -b .

but succeeds.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Genetics say, virgin birth may not possibly produce male offspring.
⣾⠁⢠⠒⠀⣿⡁ Thus, either Jesus was fathered by (Abdes?) Pantera, or she was trans.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄ In neither case Joseph is involved, making Jesus a bastard.

Re: FTBS bugs -- MBF?

[Sebastiaan Couwenberg]

On 10/2/22 04:23, Adam Borowski wrote:

This leaves one big set: packages that fail the clean step due to
undeclared B-Depends.  According to the Policy:

# "clean"
#Only the "Build-Depends" and "Build-Conflicts" fields must be
#satisfied when this target is invoked.

... which makes sense as you might be interested in only an arch:all or
arch:any build, and we have no clean-indep/clean-arch targets.


Shouldn't Build-Depends-Indep be considered as part of Build-Depends?

Packages that only build Architecture: all binary packages tend to use 
Build-Depends-Indep.


Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: FTBS bugs -- MBF?

[Lucas Nussbaum]

On 02/10/22 at 04:23 +0200, Adam Borowski wrote:
> Nǐmen hǎo!
> I did another _source_ rebuild of the archive -- checking if every package
> is capable of repacking its source.  Ie, if you can unpack it, (possibly
> modify), and pack again.
> 
> Putting aside packages that are broken in other ways as well (B-Depends
> non-installable, FTBFS or a RC bug), there seems to be no new fancy types
> of breakage that haven't been fixed in 2020.
> 
> This leaves one big set: packages that fail the clean step due to
> undeclared B-Depends.  According to the Policy:
> 
> # "clean"
> #Only the "Build-Depends" and "Build-Conflicts" fields must be
> #satisfied when this target is invoked.
> 
> ... which makes sense as you might be interested in only an arch:all or
> arch:any build, and we have no clean-indep/clean-arch targets.
> 
> For sbuild, the incantation is:
> alias sbuild-source='sbuild -s --source-only-changes --no-arch-all 
> --no-arch-any --no-run-autopkgtest'
> 
> As 291 packages fail this requirement, I'm posting here before (instead?)
> filing bugs.  There's also a question of severity.

Hi,

Are you saying that those 291 packages fail when only
Build-Depends/Build-Conflicts are satisfied, but do not fail when
Build-Depends-Indep is also satisfied?

FWIW, when I do archive rebuilds, I rebuild the source, but that's with
Build-Depends-Indep installed.

Lucas