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
Regard
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, mrgingh
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
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
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 po
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
> > >enabl
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
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 supp
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
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.
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
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 t
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
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
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
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
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 switch
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 offici
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
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.
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
> >
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),
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
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
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 bigge
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)?
>
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)?
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 her
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 fo
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
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
Programmin
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 h
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
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) f
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.
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
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
37 matches
Mail list logo
