Bug#1021230: ITP: golang-github-abiosoft-ishell -- Library for creating interactive cli applications

[Ben Westover]

Package: wnpp
Severity: wishlist
Owner: Ben Westover 
X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-abiosoft-ishell
  Version : 2.0.2-1
  Upstream Author : Abiola Ibrahim
* URL : https://github.com/abiosoft/ishell
* License : Expat
  Programming Lang: Go
  Description : Library for creating interactive cli applications

 ishell is an interactive shell library for creating interactive cli
 applications.

I am packaging this library because it's a dependency of proton-bridge.

--
Ben Westover


OpenPGP_signature
Description: PGP signature

Bug#1021228: ITP: golang-github-flynn-archive-go-shlex -- Fork of go-shlex from Google Code

[Ben Westover]

Package: wnpp
Severity: wishlist
Owner: Ben Westover 
X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-flynn-archive-go-shlex
  Version : 0.0~git20150515.3f9db97-1
  Upstream Author : Google Inc.
* URL : https://github.com/flynn-archive/go-shlex
* License : Apache-2.0
  Programming Lang: Go
  Description : Fork of go-shlex from Google Code

 go-shlex is a simple lexer for go that supports shell-style quoting,
 commenting, and escaping.

I am packaging this library because it's a dependency of proton-bridge.

--
Ben Westover


OpenPGP_signature
Description: PGP signature

Re: FTBS bugs -- MBF?

[Adam Borowski]

On Sun, Oct 02, 2022 at 01:06:31PM +0200, Mattia Rizzolo wrote:
> 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).

I've filed a few of those, let's see if there's any pushback or comments.

https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=debian-qa%40lists.debian.org&tag=ftbs


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.

Bug#1021226: ITP: golang-github-chzyer-test -- test

[Ben Westover]

Package: wnpp
Severity: wishlist
Owner: Ben Westover 
X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-chzyer-test
  Version : 1.0.0-1
  Upstream Author : ChenYe
* URL : https://github.com/chzyer/test
* License : Expat
  Programming Lang: Go
  Description : test

 test

I am packaging this library because it's a dependency of proton-bridge.

--
Ben Westover


OpenPGP_signature
Description: PGP signature

Bug#1021225: ITP: golang-github-chzyer-logex -- Golang log library that supports tracking and level

[Ben Westover]

Package: wnpp
Severity: wishlist
Owner: Ben Westover 
X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-chzyer-logex
  Version : 1.2.1-1
  Upstream Author : ChenYe
* URL : https://github.com/chzyer/logex
* License : Expat
  Programming Lang: Go
  Description : Golang log library, supporting tracking and level

 Logex is a Golang log library that supports tracing and level, wrapped
 by the standard log library.

I am packaging this library because it's a dependency of proton-bridge.

--
Ben Westover


OpenPGP_signature
Description: PGP signature

Bug#1021224: ITP: golang-github-abiosoft-readline -- Pure Go implementation for GNU-Readline kind library

[Ben Westover]

Package: wnpp
Severity: wishlist
Owner: Ben Westover 
X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-abiosoft-readline
  Version : 0.0~git20180607.155bce2-1
  Upstream Author : Abiola Ibrahim
* URL : https://github.com/abiosoft/readline
* License : Expat
  Programming Lang: Go
  Description : Pure Go implementation of GNU-Readline kind library

 This is powerful readline Go library for Linux, macOS, Windows,
 Solaris, and more.

I am packaging this library because it's a dependency of proton-bridge.

--
Ben Westover


OpenPGP_signature
Description: PGP signature

Bug#1021212: ITP: biometryd -- biometryd mediates/multiplexes to biometric devices

[Mike Gabriel]

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

* Package name: biometryd
  Version : 0.0.2
  Upstream Author : UBports Foundation 
* URL : https://gitlab.com/ubports/development/core/biometryd/
* License : LGPL-3.0
  Programming Lang: C++
  Description : biometryd mediates/multiplexes to biometric devices

 biometryd mediates and multiplexes access to biometric devices present
 on the system, enabling applications and system components to leverage
 them for identification and verification of users.
 .
 This package is part of the Lomiri operating environment and will be
 maintained by the UBports Packaging Team.

Bug#1021210: ITP: woof -- continuation of the Doom source port MBF targeted at modern systems

[Fabian Greffrath]

Package: wnpp
Severity: wishlist
Owner: Fabian Greffrath 
X-Debbugs-Cc: debian-devel@lists.debian.org, Debian Games Team 


* Package name: woof
  Version : 10.3.0
  Upstream Author : Fabian Greffrath 
* URL : Debian Games Team
* License : GPL-2.0+ and others
  Programming Lang: C (with CMake build system)
  Description : continuation of the Doom source port MBF targeted at modern 
systems

Woof! is a continuation of Lee Killough's Doom source port MBF
targeted at modern systems.
.
MBF stands for "Marine's Best Friend" and is widely regarded as the
successor of the Boom source port by TeamTNT. It serves as the code
base for popular Doom source ports such as PrBoom+/DSDA-Doom or The
Eternity Engine. As the original engine was limited to run only under
MS-DOS, it has been ported to Windows by Team Eternity under the name
WinMBF in 2004. Woof! is developed based on the WinMBF code with the
aim to make MBF more widely available and convenient to use on modern
systems.
.
To achieve this goal, this source port is less strict regarding its
faithfulness to the original MBF. It is focused on quality-of-life
enhancements, bug fixes and compatibility improvements. However, all
changes have been introduced in good faith that they are in line with
the original author's intentions and even for the trained eye, this
source port should still look very familiar to the original MBF.
.
In summary, this project's goal is to forward-port MBF.EXE from DOS to
21st century and remove all the stumbling blocks on the way.
Furthermore, just as MBF was ahead of its time, this project dedicates
itself to early adoption of new modding features such as
DEHEXTRA+DSDHacked, UMAPINFO and MBF21.

I am the project's upstream developer and would like to maintain this
package under the umbrella of the Debian Games Team. It is a Doom
source port somewhere between Crispy Doom and PrBoom+ in terms of
complexity and may be considered as PrBoom+'s successor for casual
play whereas DSDA-Doom (the other source port I am going to package
next) is focussed more on demo recording and speed running.

Re: packages expected to fail on some archs

[Adam Borowski]

On Tue, Sep 27, 2022 at 12:23:57AM +0300, Adrian Bunk wrote:
> If we limit the problem to avoiding build failures in cases that 
> upstream does not support, there would be the trivial solution of
> having a package ship Provides like:
> - architecture-is-64bit
> - architecture-is-32bit
> - architecture-is-little-endian
> - architecture-is-big-endian
> - architecture-has-64bit-timet

>   Build-Depends: architecture-is-64bit, architecture-is-little-endian,...
> would be a package that only supports 64bit little endian architectures, 
> and that would never be attempted to build on 32bit or big endian
> architectures.
> 
> The buildd page would then show for i386:
>   mypackage build-depends on missing:
>   - architecture-is-64bit

Alas, this scheme won't work for cross-building or multi-arch :(


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.

Bug#1021203: ITP: node-postcss-modules -- PostCSS plugin to use CSS Modules everywhere

[Yadd]

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

* Package name: node-postcss-modules
  Version : 5.0.0
  Upstream Author : Alexander Madyankin 
* URL : https://github.com/madyankin/postcss-modules
* License : Expat
  Programming Lang: JavaScript
  Description : PostCSS plugin to use CSS Modules everywhere

node-postcss-modules will provide a PostCSS plugin to use CSS Modules
everywhere. Not only at the browser side.

This package is needed at least to update vue.js (libjs-vue and
node-vue) to version 4.x

It will be maintained under JS Team umbrella

Re: transitional packages? (was: Firmware GR result - what happens next?)

[Shengjing Zhu]

On Mon, Oct 3, 2022 at 11:32 PM Santiago Ruano Rincón
 wrote:
> > Can we have different versions in each section?
> >
> > + non-free/pkgA version~1
> > + non-free-firmware/pkgA version~2
>
> that wouldn't comply with the current policy:
> https://www.debian.org/doc/debian-policy/ch-binary.html#the-package-name
>

I don't think it's related to name policy. It's whether dak will
remove old versions in different sections.

-- 
Shengjing Zhu

Re: transitional packages? (was: Firmware GR result - what happens next?)

[Santiago Ruano Rincón]

El 03/10/22 a las 19:40, Shengjing Zhu escribió:
> On Mon, Oct 3, 2022 at 7:31 PM Didier 'OdyX' Raboud  wrote:
> >
> > 3 octobre 2022 11:11 "Santiago Ruano Rincón"  a 
> > écrit:
> > > El 02/10/22 a las 20:42, Michael Biebl escribió:
> > >> Am 02.10.22 um 20:14 schrieb Luca Boccassi:
> > >> On Sun, 2022-10-02 at 10:52 -0700, Russ Allbery wrote:
> > >> 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.
> > >
> > > Couldn't we handle this via transitional firware* non-free packages,
> > > that depend on bookworm non-free-firmware packages?
> >
> > That would only work if we renamed all concerned binary packages, or if apt 
> > grew a "section/packagename" syntax (which would be bizarre).
> >
> 
> Can we have different versions in each section?
> 
> + non-free/pkgA version~1
> + non-free-firmware/pkgA version~2

that wouldn't comply with the current policy:
https://www.debian.org/doc/debian-policy/ch-binary.html#the-package-name

> 
> And let non-free/pkgA version~1 just fail during upgrade and produce a
> migration guide.
> 
> -- 
> Shengjing Zhu
> 


signature.asc
Description: PGP signature

Re: Firmware GR result - what happens next?

[Thomas Goirand]

On 10/3/22 02:23, Charles Plessy wrote:

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 ?


How about being smarter than this? :)

Cheers,

Thomas Goirand (zigo)

Re: Firmware GR result - what happens next?

[Michael Stone]

On Sun, Oct 02, 2022 at 08:21:31PM +0100, Steve McIntyre wrote:

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


We also try to avoid silent install problems that might or might not 
result in a system that doesn't boot properly.

Re: Firmware GR result - what happens next?

[Julian Andres Klode]

On Sun, Oct 02, 2022 at 12:26:29PM -0700, Steve Langasek wrote:
> 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?

We have already talked about apt release-upgrade for a couple of times,
but no time to implement it yet and the design needs to be talked
through how the target release can hook into apt to provide quirks.

We want apt release-upgrade too

1. rewrite sources for you if you want to
2. upgrade the system in three steps equivalent to

apt safe-upgrade --without-new-pkgs
apt safe-upgrade --with-new-pkg
apt full-upgrade

3. Hooks to customize the dependency solving (adding/removing packages),
   and potentially arbitrary quirks.

Where things get awkard is that (1) we'd like declarative hooks where
possible, a deb822 file of hooks, but (2) we also need to perhaps add
new logic.

So there was an idea to build a binary package that ships a module that
can be loaded at runtime by apt. So apt would install that package first
before it can upgrade. Or you can make it be a shell script and have
hooks of Type: Shell. Or just add Depends to release file that requires
users to install a newer version of apt before they can use the
repository and then ship that in (old)stable-updates with the additional
types of hooks.


> 
> 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.

That makes sense. So the idea for apt release-upgrade is to have a list
of quirks and each quirk can then have a test to see if it ran already.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en


signature.asc
Description: PGP signature

Re: Firmware GR result - what happens next?

[Lennart Sorensen]

On Mon, Oct 03, 2022 at 02:47:33PM +0200, Pascal Hambourg wrote:
> Not even replace "stable/updates" with "stable-security" during the upgrade
> from buster to bullseye ?

Hmm I don't recall but I suppose it just wasn't very memorable to do it.
At least it would have given an error fetching the list if you didn't
do it.  Not adding a new entry on the other hand will not.

-- 
Len Sorensen

Bug#1021188: ITP: ovn-bgp-agent -- OpenStack virtual network service - OVN BGP agent

[Thomas Goirand]

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

* Package name: ovn-bgp-agent
  Version : 0.2.0
  Upstream Author : OpenStack Foundation 
* URL : https://opendev.org/x/ovn-bgp-agent
* License : Apache-2.0
  Programming Lang: Python
  Description : OpenStack virtual network service - OVN BGP agent

 Neutron provides an API to dynamically request and configure virtual networks.
 These networks connect "interfaces" from other OpenStack services (such as
 vNICs from Nova VMs). The Neutron API supports extensions to provide advanced
 network capabilities, including QoS, ACLs, and network monitoring.
 .
 This package provides the OVN BGP agent.

Re: Firmware GR result - what happens next?

[Pascal Hambourg]

On 03/10/2022 at 01:00, Lennart Sorensen wrote:

On Sun, Oct 02, 2022 at 08:21:31PM +0100, Steve McIntyre wrote:


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.


Not even replace "stable/updates" with "stable-security" during the 
upgrade from buster to bullseye ?

Re: transitional packages? (was: Firmware GR result - what happens next?)

[Santiago Ruano Rincón]

El 03/10/22 a las 11:31, Didier 'OdyX' Raboud escribió:
> 3 octobre 2022 11:11 "Santiago Ruano Rincón"  a écrit:
> > El 02/10/22 a las 20:42, Michael Biebl escribió:
> >> Am 02.10.22 um 20:14 schrieb Luca Boccassi:
> >> On Sun, 2022-10-02 at 10:52 -0700, Russ Allbery wrote:
> >> 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.
> > 
> > Couldn't we handle this via transitional firware* non-free packages,
> > that depend on bookworm non-free-firmware packages?
> 
> That would only work if we renamed all concerned binary packages, 

Indeed. Something like:

bullseye:
firmware-linux-nonfree (non-free)
bookworm:
firmware-linux-nonfree (non-free) - empty, that
Depends on: firmware-linux-nonfree-bookworm (non-free-firmware) -
find a better name/suffix
trixie:
firmware-linux-nonfree-bookworm (non-free-firmware) - empty
Depends on: firmware-linux-nonfree (non-free-firmware)
trixie+1:
firmware-linux-nonfree (non-free-firmware)
and so on.

It is (also) bizarre, but this would help users make sure they include
the non-free-firmware section when required. I suppose apt would
complain if it cannot satisfy the dependency due to a missing section.

> or if apt grew a "section/packagename" syntax (which would be bizarre).

Beyond being bizarre, users and other tools would have to learn that
syntax.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Re: Firmware GR result - what happens next?

[Cyril Brulebois]

Steve McIntyre  (2022-10-02):
>   + ftpsync (?)

I don't think that's needed. Using buster's and more recently bullseye's
version, I have this locally:

drwxr-xr-x 4 mirror mirror 4096 Jul 19 04:16 
/srv/mirrors/debian/dists/bookworm/non-free-firmware/by-hash/

which matches when dak's config got updated with that extra component.

The git tree has a bin/archive_release that lists components explicitly
but it doesn't end up in any binary packages (there's a single ftpsync,
and it's not shipped there). Furthermore the 'non-free' string doesn't
appear in any of the files below debian/ftpsync/ after a build, so the
package doesn't look like it needs an update for that (even though a lot
of work happened in master since the last tag/release).


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?

[Cyril Brulebois]

Colin Watson  (2022-10-03):
> Done in debmirror 1:2.37.  I guess we need to cherry-pick this to
> bullseye too?  I know bullseye doesn't have non-free-firmware (which
> is fine, the new debmirror doesn't object), but most people running
> mirrors probably run stable rather than testing.

Thanks for patching and verifying the extra component's presence on a
per-suite basis isn't an issue, that was on my to-do list.

And yes, it looks like bullseye-proposed-updates material to me; esp.
given that tiny diff…


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?

[Colin Watson]

On Sun, Oct 02, 2022 at 03:27:36PM +0100, Steve McIntyre wrote:
> * Check/add support for the non-free-firmware section in various
>   places:
>   + debmirror (?)

Done in debmirror 1:2.37.  I guess we need to cherry-pick this to
bullseye too?  I know bullseye doesn't have non-free-firmware (which is
fine, the new debmirror doesn't object), but most people running mirrors
probably run stable rather than testing.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Re: transitional packages? (was: Firmware GR result - what happens next?)

[Shengjing Zhu]

On Mon, Oct 3, 2022 at 7:31 PM Didier 'OdyX' Raboud  wrote:
>
> 3 octobre 2022 11:11 "Santiago Ruano Rincón"  a écrit:
> > El 02/10/22 a las 20:42, Michael Biebl escribió:
> >> Am 02.10.22 um 20:14 schrieb Luca Boccassi:
> >> On Sun, 2022-10-02 at 10:52 -0700, Russ Allbery wrote:
> >> 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.
> >
> > Couldn't we handle this via transitional firware* non-free packages,
> > that depend on bookworm non-free-firmware packages?
>
> That would only work if we renamed all concerned binary packages, or if apt 
> grew a "section/packagename" syntax (which would be bizarre).
>

Can we have different versions in each section?

+ non-free/pkgA version~1
+ non-free-firmware/pkgA version~2

And let non-free/pkgA version~1 just fail during upgrade and produce a
migration guide.

-- 
Shengjing Zhu

Re: transitional packages? (was: Firmware GR result - what happens next?)

[Didier 'OdyX' Raboud]

3 octobre 2022 11:11 "Santiago Ruano Rincón"  a écrit:
> El 02/10/22 a las 20:42, Michael Biebl escribió:
>> Am 02.10.22 um 20:14 schrieb Luca Boccassi:
>> On Sun, 2022-10-02 at 10:52 -0700, Russ Allbery wrote:
>> 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.
> 
> Couldn't we handle this via transitional firware* non-free packages,
> that depend on bookworm non-free-firmware packages?

That would only work if we renamed all concerned binary packages, or if apt 
grew a "section/packagename" syntax (which would be bizarre).

Re: FTBS bugs -- MBF?

[Lucas Nussbaum]

On 02/10/22 at 22:21 +0200, Johannes Schauer Marin Rodrigues wrote:
> 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.

My point is: if the issue raised by Adam is something we want to fix, it
would be great if we could come up with a way to detect this issue on a
regular basis, rather than with one-off QA checks.  One way to achieve
that would be to extend sbuild so that it is able to check for that
while also checking for rebuildability of binary packages. (and then I
would integrate that into my regular archive rebuilds)

> > - 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".

... but I see your point.

Lucas

Re: Firmware GR result - what happens next?

[Julian Andres Klode]

On Sun, Oct 02, 2022 at 11:47:42PM +0200, Thomas Goirand wrote:
> 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).

Really all you need is

if [ -n "$(apt-get indextargets 'Component: non-free' 'Origin: Debian')" ] &&
   [ -z "$(apt-get indextargets 'Component: non-free-firmware' 'Origin: 
Debian')" ]; then
   debconf prompt
fi

I mean you could filter on codenames too but meh.

(CC me if you want me to get a reply in my INBOX, I may not see it
otherwise, I'm not subscribed, just receiving via NNTP gateway :D)
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

transitional packages? (was: Firmware GR result - what happens next?)

[Santiago Ruano Rincón]

El 02/10/22 a las 20:42, Michael Biebl escribió:
> 
> 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.
> 

Couldn't we handle this via transitional firware* non-free packages,
that depend on bookworm non-free-firmware packages?

Cheers,

 -- Santiago


signature.asc
Description: PGP signature