Re: key packages RC bugs of the month April

Hi On 05-04-2025 14:06, Santiago Vila wrote: El 5/4/25 a las 8:44, Paul Gevers escribió: Remember, if you really think a bug shouldn't be RC (particularly if you are the maintainer), downgrade it with an explanation. Does this include the case where a Release Manager previously raised the s

Re: key packages RC bugs of the month April

El 5/4/25 a las 8:44, Paul Gevers escribió: Remember, if you really think a bug shouldn't be RC (particularly if you are the maintainer), downgrade it with an explanation. Does this include the case where a Release Manager previously raised the severity from important to serious? Thanks.

Re: key packages RC bugs of the month April

* Paul Gevers , 2025-04-05 08:44: #1071316 infinipath-psm FTBFS: ips_proto_dump.c:142:15: error: static declaration of ‘strlcat’ follows non-static declaration https://bugs.debian.org/1069553 Wrong URL, should be: https://bugs.debian.org/1071316 -- Jakub Wilk

key packages RC bugs of the month April

Dear all, During the preparation phase of bookworm, I was running an awareness campagne on RC bugs [1] in package in the key package set [2]. As those packages are exempted from being auto-removed, their RC bugs are ironically less exposed. Ideally we should get the number of RC bugs in

Re: Heimdal Bugs re update-alternatives

Gabor Gombas writes: > This one is nothing special - some commands behaving differently based > on argv[0] is a traditional Unix thing. "(exec -a klist klist.heimdal)" > should work. Sorry, not 100% sure what you are trying to say here. Are you suggesting that https://bugs.debian.org/cgi-bin/bu

Re: Heimdal Bugs re update-alternatives

Gabor Gombas writes: > Exactly - that's why making the KDC package Conflicts: with the other > implementation would be a quick fix. There aren't many KDC > implementations, and I think Shishi does not use kadmin (I'm not sure, I > never used it), so maintaining such Conflicts: does not sound like

Re: Heimdal Bugs re update-alternatives

On Mon, Feb 10, 2025 at 09:59:26AM -0800, Russ Allbery wrote: > As someone who used to have to regularly deal with multi-implementation > Kerberos setups, I can confirm that there is a real need to be able to > install the Heimdal clients and the MIT clients (including kadmin) at the > same time.

Re: Heimdal Bugs re update-alternatives

Le 10/02/2025 à 18:59, Russ Allbery a écrit : It's unfortunate that the commands have the same names in both Kerberos distributions, although it's understandable from a user UI perspective. I don't have a good solution. Either using alternatives or not using alternatives runs some risk of breaki

Re: Heimdal Bugs re update-alternatives

Gabor Gombas writes: > On Mon, Feb 10, 2025 at 08:59:47AM +1100, Brian May wrote: >> Is it appropriate to use update-alternatives for kadmin that is supplied >> with {Heimdal,MIT} Kerberos? > ... in the real world, KDCs tend to be heavily locked down machines with > not much else installed, due

Re: Heimdal Bugs re update-alternatives

Hi, On Mon, Feb 10, 2025 at 08:59:47AM +1100, Brian May wrote: > Can I please have some thoughts on #1070031? > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070031 Hmm, how is that possible? At a quick glance, heimdal-kdc Depends: on heimdal-clients, and krb5-user Conflicts: with heimda

Heimdal Bugs re update-alternatives

Hello, Can I please have some thoughts on #1070031? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070031 Is it appropriate to use update-alternatives for kadmin that is supplied with {Heimdal,MIT} Kerberos? I am thinking they do very different things but maybe not. i.e. one updates files f

Re: file-roller old bugs

On Wed, Oct 16, 2024 at 11:43:59PM +0300, Mina wrote: > hi > i noticed that there is a lot of very old( > 13 years old) > outstanding bugs in file-roller bugs page and some of then i confirmed > that it's n longer reproducible most probably fix > is it ok to close it and arc

file-roller old bugs

hi i noticed that there is a lot of very old( > 13 years old) outstanding bugs in file-roller bugs page and some of then i confirmed that it's n longer reproducible most probably fix is it ok to close it and archive it or what is your suggestion on that -- Best Regards Mina

Re: Open "NMU diff for 64-bit time_t transition" bugs

Hi On 2024-05-10 08:29:28 +0300, Andrius Merkys wrote: > I care for tree packages which still have open "NMU diff for 64-bit time_t > transition" bugs: libccp4, macromoleculebuilder and rdkit. All of them have > NMU diffs applied in experimental, but not in unstable yet. What

Re: [sylpheed:37255] Re: Debian 12 released with two RC bugs in Sylpheed

On Sun, 7 Apr 2024 15:18:57 +0200 José Luis González wrote: > I found the report now. It's #1036799. Yes, it looks like a temporary server issue. And you're sending via gmail now. But again, what do you expect a package maintainer to do? It's upstream where bugs get fixed

Re: Debian 12 released with two RC bugs in Sylpheed

On Sun, 7 Apr 2024 13:26:49 +0200 José Luis González wrote: > The maintainer accumulates a lot of bugs for the package, doesn't take > care about almost all, and when I filed a RC bug because the package > became unusable to me he downgraded severity to important claiming it >

Re: Debian 12 released with two RC bugs in Sylpheed

In days of yore (Sun, 07 Apr 2024), José Luis González thus quoth: > Hi, > > Debian 12 was released with two Release Critical bugs I filed on May > 20th 2023 (#1036424 and #1036388) on Sylpheed about issues that I > found on stable, and remain, with Debian 12 released later on J

Re: Debian 12 released with two RC bugs in Sylpheed

On Apr 07, José Luis González wrote: > I want to know why Debian 12 was released with those two Sylpheed RC > bags, report the incident to you all, know what to do with the > maintainer and kindly request that someone better at the job takes over > Sylpheed maintainance, or otherwise I will becom

Re: [sylpheed:37253] Debian 12 released with two RC bugs in Sylpheed

On Sun, 7 Apr 2024 13:26:49 +0200 José Luis González wrote: > Debian 12 was released with two Release Critical bugs I filed on May > 20th 2023 (#1036424 and #1036388) on Sylpheed about issues that I > found on stable, and remain, with Debian 12 released later on June 10th > 2023. T

Debian 12 released with two RC bugs in Sylpheed

Hi, Debian 12 was released with two Release Critical bugs I filed on May 20th 2023 (#1036424 and #1036388) on Sylpheed about issues that I found on stable, and remain, with Debian 12 released later on June 10th 2023. The maintainer accumulates a lot of bugs for the package, doesn't take

Re: time_t transition and bugs

Thanks Steve for uploading a fixed curl on Saturday. Just checking did you notice amel/armhf are still not building due to secondary issues and n dependencies? https://buildd.debian.org/status/package.php?p=curl

Re: time_t transition and bugs

7;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. As mentioned on IRC, I isolated the bug in the script that caused this, which allowed working out the full list of affected packages.

Re: time_t transition and bugs

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'v

time_t transition and bugs

7;re using kde/qt5 (I am holding packages in older versions in aptitude right now). My questions are: 1. Is the time_t transition team aware of these issues? 2. Where should these kinds of bugs be reported? I feel like reporting to individual packages might get lost, and also these may repr

Re: Proposal for how to deal with Go/Rust/etc security bugs

On 2024-01-25 17:10, Russ Allbery wrote: Rebuilding a bunch of software after a security fix is not a completely intractable problem that we have no idea how to even approach. It's just CPU cycles and good metadata plus ensuring that our software can be rebuilt, something that we already promi

Re: Proposal for how to deal with Go/Rust/etc security bugs (was: Re: Limited security support for Go/Rust? Re ssh3)

On Wed, Jan 24, 2024 at 09:37:27AM +0100, Simon Josefsson wrote: > Simon Josefsson writes: > > >> > My naive approach on how to fix a security problem in package X > >> > which is > >> > statically embedded into other packages A, B, C, ... would be to > >> > rebuild > >> > the transitive closure

Re: Understanding what's missing for Rust dynamic linking (was: Proposal for how to deal with Go/Rust/etc security bugs)

On Thu, Jan 25, 2024 at 07:03:05PM +, Luca Boccassi wrote: > On Thu, 25 Jan 2024 at 18:22, Gard Spreemann wrote: > > > > Hello. > > > > Paul Wise writes: > > > > > On Thu, 2024-01-25 at 00:24 +, Wookey wrote: > > > > > >> People keep telling us (@ARM) how marvellous Rust is, and we keep >

Re: Understanding what's missing for Rust dynamic linking (was: Proposal for how to deal with Go/Rust/etc security bugs)

On Thu, 25 Jan 2024 at 18:22, Gard Spreemann wrote: > > Hello. > > Paul Wise writes: > > > On Thu, 2024-01-25 at 00:24 +, Wookey wrote: > > > >> People keep telling us (@ARM) how marvellous Rust is, and we keep > >> telling them that it's useless in the real world until it sorts out > >> the

Re: Proposal for how to deal with Go/Rust/etc security bugs

On Thu, 25 Jan 2024 at 16:11, Russ Allbery wrote: > > Simon Josefsson writes: > > > I want to explore if there is a possibility to change status quo, and > > what would be required to do so. > > > Given how often gnulib is vendored for C code in Debian, and other > > similar examples, I don't thi

Re: Proposal for how to deal with Go/Rust/etc security bugs

Simon Josefsson writes: > I want to explore if there is a possibility to change status quo, and > what would be required to do so. > Given how often gnulib is vendored for C code in Debian, and other > similar examples, I don't think of this problem as purely a Go/Rust > problem. The parallel a

Understanding what's missing for Rust dynamic linking (was: Proposal for how to deal with Go/Rust/etc security bugs)

Hello. Paul Wise writes: > On Thu, 2024-01-25 at 00:24 +, Wookey wrote: > >> People keep telling us (@ARM) how marvellous Rust is, and we keep >> telling them that it's useless in the real world until it sorts out >> the stable ABI/dynamic linking problem. > > IIRC that has been worked on fo

Re: Proposal for how to deal with Go/Rust/etc security bugs

On Jan 25, Wookey wrote: > Luca is quite right here. Ultimately this can only be fixed by these > ecosystems understanding that software in these languages cannot be > sensibly used in distributions until they support modularity and > stability. The rust people make the excuse that they are 'too

Re: Proposal for how to deal with Go/Rust/etc security bugs

On Thu, 2024-01-25 at 00:24 +, Wookey wrote: > People keep telling us (@ARM) how marvellous Rust is, and we keep > telling them that it's useless in the real world until it sorts out > the stable ABI/dynamic linking problem. IIRC that has been worked on for some years now, and IIRC the static

Re: Proposal for how to deal with Go/Rust/etc security bugs

On 2024-01-24 13:29 +0100, Simon Josefsson wrote: > Luca Boccassi writes: > > > There's always option B: recognize that the Rust/Go ecosystems are not > > designed to be compatible with the Linux distributions model Luca is quite right here. Ultimately this can only be fixed by these ecosystems

Re: Proposal for how to deal with Go/Rust/etc security bugs (was: Re: Limited security support for Go/Rust? Re ssh3)

On Jan 24, Peter Pentchev wrote: > This might be a minority, optimistic, rose-tinted-glasses kind of > opinion, but I believe that the state of the Rust ecosystem today > (I have no experience with the Go one) is quite similar to what Perl and > Python modules were 25, 20, bah, even 15 years ago.

static linking, modularity, and community (was: Proposal for how to deal with Go/Rust/etc security bugs)

[follow-ups should probably go to -project, but I'm not setting my headers to try to force that] At 2024-01-24T16:57:06+0100, Simon Josefsson wrote: > One could equally well make the argument that distributors should care > about the Go/Rust ecosystems, and make whatever changes needed in > order

Re: Proposal for how to deal with Go/Rust/etc security bugs (was: Re: Limited security support for Go/Rust? Re ssh3)

On Wed, Jan 24, 2024 at 01:01:34PM +, Luca Boccassi wrote: > On Wed, 24 Jan 2024 at 12:26, Johannes Schauer Marin Rodrigues > wrote: > > > > Hi, > > > > Quoting Luca Boccassi (2024-01-24 12:59:38) > > > There's always option B: recognize that the Rust/Go ecosystems are not > > > designed to be

Re: Proposal for how to deal with Go/Rust/etc security bugs

Luca Boccassi writes: > On Wed, 24 Jan 2024 at 13:34, Simon Josefsson wrote: >> >> Luca Boccassi writes: >> >> >> Having reflected a bit, and learned through my own experience and >> >> others' insights [1] that Go Build-Depends are not transitive, I'd like >> >> to update my proposal on how to

Re: Proposal for how to deal with Go/Rust/etc security bugs

On Wed, 24 Jan 2024 at 13:34, Simon Josefsson wrote: > > Luca Boccassi writes: > > >> Having reflected a bit, and learned through my own experience and > >> others' insights [1] that Go Build-Depends are not transitive, I'd like > >> to update my proposal on how to handle a security bug in any Go

Re: Proposal for how to deal with Go/Rust/etc security bugs (was: Re: Limited security support for Go/Rust? Re ssh3)

On 2024-01-24 13:26:49 +0100 (+0100), Johannes Schauer Marin Rodrigues wrote: [...] > how does that work for those applications that require rust, go > and friends? Are you proposing that everything that needs them > should be be distributed by a flatpak or similar mechanism > instead? > > Just a

Re: Proposal for how to deal with Go/Rust/etc security bugs

On 24/01/24 14:01, Luca Boccassi wrote: how does that work for those applications that require rust, go and friends? Are you proposing that everything that needs them should be be distributed by a flatpak or similar mechanism instead? Those applications are not shipped in the distribution. If s

Re: Proposal for how to deal with Go/Rust/etc security bugs (was: Re: Limited security support for Go/Rust? Re ssh3)

On Wed, 24 Jan 2024 at 12:26, Johannes Schauer Marin Rodrigues wrote: > > Hi, > > Quoting Luca Boccassi (2024-01-24 12:59:38) > > There's always option B: recognize that the Rust/Go ecosystems are not > > designed to be compatible with the Linux distributions model, and are > > instead > > design

Re: Proposal for how to deal with Go/Rust/etc security bugs

On 24/01/24 5:59 pm, Simon Josefsson wrote: Does anyone know of a shared library in a Debian package written in Go? I've only encountered the vendored approach to ship Go libraries. libgovarnam1 is shipped as a shared library https://packages.debian.org/sid/amd64/libgovarnam1/filelist Open

Re: Proposal for how to deal with Go/Rust/etc security bugs

Luca Boccassi writes: >> Having reflected a bit, and learned through my own experience and >> others' insights [1] that Go Build-Depends are not transitive, I'd like >> to update my proposal on how to handle a security bug in any Go/Rust/etc >> package and the resulting package rebuilds: > > Ther

Re: Proposal for how to deal with Go/Rust/etc security bugs (was: Re: Limited security support for Go/Rust? Re ssh3)

Hi, Quoting Luca Boccassi (2024-01-24 12:59:38) > There's always option B: recognize that the Rust/Go ecosystems are not > designed to be compatible with the Linux distributions model, and are instead > designed to be as convenient as possible for a _single_ application developer > and its users -

Re: Proposal for how to deal with Go/Rust/etc security bugs (was: Re: Limited security support for Go/Rust? Re ssh3)

On Wed, 24 Jan 2024 at 11:42, Simon Josefsson wrote: > > Simon Josefsson writes: > > >> > My naive approach on how to fix a security problem in package X > >> > which is > >> > statically embedded into other packages A, B, C, ... would be to > >> > rebuild > >> > the transitive closure of all pac

Re: Proposal for how to deal with Go/Rust/etc security bugs

On 24/01/24 2:07 pm, Simon Josefsson wrote: Yes, for a low-level Go package (e.g., golang-golang-x-net-dev), this will mean rebuilding almost all of the Go packages in Debian and publish them in a security advisory. This algorithm can be optimized (i.e., reduce the number of packages to publis

Proposal for how to deal with Go/Rust/etc security bugs (was: Re: Limited security support for Go/Rust? Re ssh3)

Simon Josefsson writes: >> > My naive approach on how to fix a security problem in package X >> > which is >> > statically embedded into other packages A, B, C, ... would be to >> > rebuild >> > the transitive closure of all packages that Build-Depends on X and >> > publish a security update for

Re: Consensus on closing old bugs

often useful > for me to see the amount/age/contents of bugs in a package as an > indication in what state it is. Yes, I completely agree with this. When adopting an old, unloved package, closing a bunch of old bugs (by fixing them, usually) is one of the most satisfying and enjoyable parts of t

Re: Consensus on closing old bugs

the bug reporter than leaving > it open and creating the illusion that you might fix it some day. A maintainer closing a bug based on its contents is quite different from "close bugs simply because they are old". There is a certain stupidity if a (human or nonhuman) bot blindly asks the

Re: Consensus on closing old bugs

e! true in some circumstances!), and separately has defined bug triage as closing old bugs (sort of! true if they no longer apply!). Neither of these are entirely unreasonable, or put another way both of these are true in specific situations. But they interact very poorly: people who don't know the proj

Re: Consensus on closing old bugs

On Mon, Feb 13, 2023 at 10:33:51AM +, Holger Levsen wrote: > On Sat, Feb 11, 2023 at 10:45:16PM +0200, Adrian Bunk wrote: > > On Mon, Feb 06, 2023 at 10:07:59AM -0700, Sam Hartman wrote: > > > Most of us do not prefer to close bugs simply because they are old. > > It cr

Re: Consensus on closing old bugs

On Sat, Feb 11, 2023 at 10:45:16PM +0200, Adrian Bunk wrote: > On Mon, Feb 06, 2023 at 10:07:59AM -0700, Sam Hartman wrote: > > Most of us do not prefer to close bugs simply because they are old. > It creates angry users and no real benefits. this is undoubtingly true for some bu

Re: Consensus on closing old bugs

On Mon, Feb 06, 2023 at 10:07:59AM -0700, Sam Hartman wrote: >... > Most of us do not prefer to close bugs simply because they are old. It creates angry users and no real benefits. > But closing bugs with a moreinfo tag when information has not been > provided in six months to a ye

Re: Consensus on closing old bugs

asily reproducible and replied documenting that it was and a more exact procedure for that. Perhaps the maintainer didn't have time for that individual bug or for the aggregate of bugs they were triaging though. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: Thi

Re: Consensus on closing old bugs

>>>>> "Tomas" == Tomas Pospisek writes: Tomas> All that said, I have never received negative feedback to Tomas> these bug triages that I am occassionaly doing and am under Tomas> the impression that the maintainers *do* appreciate someone Tom

Re: Consensus on closing old bugs

Let the maintainers handle their bugs. Old bugs should not be closed just because they are "old". For example, I have an open bug which is 26 years old: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=5898 and I don't see any reason to close it. However I'd like to put San

Re: Consensus on closing old bugs

On Mon, 2023-02-06 at 11:51 +0100, Santiago Vila wrote: > Let the maintainers handle their bugs. > Old bugs should not be closed just because they are "old". > > For example, I have an open bug which is 26 years old: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?b

Re: Consensus on closing old bugs

El 6/2/23 a las 11:26, Brian Thompson escribió: I understand that the usual way to close out bug reports is having the original author do it themselves. What's the policy on closing bug reports that haven't had activity in over 6 months? Let the maintainers handle their bugs. Old b

Consensus on closing old bugs

I understand that the usual way to close out bug reports is having the original author do it themselves. What's the policy on closing bug reports that haven't had activity in over 6 months? Specifically I am talking about the following: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007922

key packages RC bugs of the month February

Dear all, While I skipped one month, we're now in the mid of the first freeze, so here's another plea [1,2,3,4, 5] to fix RC bugs in key packages [6]. Currently we have 168 RC bugs in key packages affecting bookworm [7] of which 109 are unresolved in unstable or experimental, aren

key packages RC bugs of the month December

Dear all, With only 1 month to go until the first freeze, another plea [1,2,3,4] to fix RC bugs in key packages [5]. Currently we have 234 RC bugs in key packages affecting bookworm [6] of which 160 are unresolved in unstable or experimental, aren't pending and don't have a patch

key packages RC bugs of the month November

Dear all, With about 2 months to go until the first freeze, a fresh plea [1,2,3] to fix RC bugs in key packages [4]. Currently we have 255 RC bugs in key packages affecting bookworm [5] of which 184 are unresolved in unstable or experimental, aren't pending and don't have a patch

Re: FTBS bugs -- MBF?

d=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 w

Re: FTBS bugs -- MBF?

uild, 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

Re: FTBS bugs -- MBF?

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

Re: FTBS bugs -- MBF?

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.

Re: FTBS bugs -- MBF?

lean-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 bug

Re: FTBS bugs -- MBF?

ly 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 Rizzo

Re: FTBS bugs -- MBF?

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

Re: FTBS bugs -- MBF?

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

Re: FTBS bugs -- MBF?

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

Re: FTBS bugs -- MBF?

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

Re: FTBS bugs -- MBF?

lean-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?) > filin

FTBS bugs -- MBF?

o-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. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ A tit a day keeps the vet away. ⠈⠳⣄ adduser arandr aspe

key packages RC bugs of the month October

Dear all, A new month, a fresh plea [1,2] to fix RC bugs in key packages. So, here are again 5 RC bugs in key packages in the hope to draw some attention to this class of bugs. Remember, fixing these bugs is a collective effort. #913916 grub-efi-amd64 UEFI boot option removed after update to

Re: Fixing CI bugs for a package on the REJECT list

Hi Jeff, On 26-09-2022 12:53, Jeff wrote: Short of closing #1012250, how do I get CI pipeline to pick up gscan2pdf again to debug the flaky tests? I'd appreciate any pointers. The bug has a user specified for the usertag and explicitly mentions: """ Don't hesitate to reach out if you need he

Fixing CI bugs for a package on the REJECT list

Hallo all, A few of the tests for gscan2pdf seem to be flaky (although I can't reproduce this locally): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012250 When I wrote the reply on the above bug, I evidently waited too long for help, as now the log files cited have been purged, as hav

Re: key packages RC bugs of the month September

Hi, Am 01.09.22 um 22:18 schrieb Paul Gevers: On 01-09-2022 21:10, Rene Engelhard wrote: This either should be ignored (like for bullseye) or downgrade, imho, but I didn't do it myself. I don't think there's anything actionable here... [...] If I read these correctly, this is exactly the kind

Re: key packages RC bugs of the month September

ly. If I read these correctly, this is exactly the kind of action that a maintainer can take to make the release process smoother. If *you* as a maintainer think the bug shouldn't be RC, by all means downgrade it (ideally with an explanation just in case it's disputed later on). The Rel

Re: key packages RC bugs of the month September

Hi Am 01.09.22 um 13:53 schrieb Paul Gevers: #935182 libreoffice-core Concurrent file open on the same host results file deletion https://bugs.debian.org/935182 This one has been open so long, is forwarded upstream. Has to do with samba *and* two persons on the same host doing it at the same t

Re: key packages RC bugs of the month September

On Thu, 01 Sep 2022 at 13:53:41 +0200, Paul Gevers wrote: > #919914 gnome-settings-daemon > gnome-tweaks now equates "don't suspend on lid close" with "don't lock on > lid close" (security issue) > https://bugs.debian.org/919914 Honestly, I don't think this one is really RC. The bug reporter

Re: fontconfig RC bugs (was: Re: key packages RC bugs of the month September)

On Thu, Sep 01, 2022 at 04:08:20PM +0200, Johannes Schauer Marin Rodrigues wrote: > > #960679 src:fontconfig > > strict dependency of arch:any libfontconfig1 on arch:all > > fontconfig-config going wrong > > https://bugs.debian.org/960679 > > fontconfig also has a second RC bug: #909750 > > The

fontconfig RC bugs (was: Re: key packages RC bugs of the month September)

Hi Paul, Quoting Paul Gevers (2022-09-01 13:53:41) > I am asking for help with investigating RC bug reports, judging > severity, reproducing the issue, clarifying the problem, i.e. bug > triaging of all RC bugs that haven't seen activity for a while and that > are still affec

key packages RC bugs of the month September

Dear all, In the same theme as my earlier message [0], I like to ask you to please spend some time triaging (and ideally solving) old RC bugs. Some packages you may care about were removed from testing because the maintainer didn't triage or fix the bug. And then there's key packag

Re: Idea: autopkgtest on big-endian for 'Architecture: all' packages to catch endian bugs

kilobyte dixit: >Funny thing: there's not a single release architecture that's both >bad-endian and supports X (they do build X related packages because the >dependency graph is quite dense, but there are no users). So this Meh. Remote X, X forwarding over SSH, VNC and RDP servers exist. So do d

Re: Idea: autopkgtest on big-endian for 'Architecture: all' packages to catch endian bugs

Le lun. 29 août 2022 à 03:30, Adam Borowski a écrit : > On Sun, Aug 28, 2022 at 04:56:26PM +, Thorsten Glaser wrote: > > Didier 'OdyX' Raboud dixit: > > >If these tests are run at build-time, errors halt the build and that > provides > > > > That may not be enough, though; there are cases whe

Re: Idea: autopkgtest on big-endian for 'Architecture: all' packages to catch endian bugs

On Sun, Aug 28, 2022 at 04:56:26PM +, Thorsten Glaser wrote: > Didier 'OdyX' Raboud dixit: > >If these tests are run at build-time, errors halt the build and that provides > > That may not be enough, though; there are cases where the build > architecture determines artefact endianness (e.g. wi

Re: Idea: autopkgtest on big-endian for 'Architecture: all' packages to catch endian bugs

Didier 'OdyX' Raboud dixit: >If these tests are run at build-time, errors halt the build and that provides That may not be enough, though; there are cases where the build architecture determines artefact endianness (e.g. with PCF bitmap fonts), and that may even be enough (X servers can load PCFs

Re: Idea: autopkgtest on big-endian for 'Architecture: all' packages to catch endian bugs

Hi Edward, On 02-08-2022 18:00, Edward Betts wrote: I wonder if it would be possible to routinely run the autopkgtests on s390x, or another big-endian architecture, for 'Architecture: all' packages and make the results available. We run all autopkgtests on all architectures we have available.

Re: Idea: autopkgtest on big-endian for 'Architecture: all' packages to catch endian bugs

Hi, Le 02/08/2022 à 18:00, Edward Betts a écrit : […] I wonder if it would be possible to routinely run the autopkgtests on s390x, or another big-endian architecture, for 'Architecture: all' packages and make the results available. AFAICT, they already are. E.g.

Re: Idea: autopkgtest on big-endian for 'Architecture: all' packages to catch endian bugs

Le mardi, 2 août 2022, 18.00:40 h CEST Edward Betts a écrit : > I recently packaged a Python module called sqlite-fts4 written by Simon > Willison. The package is pure Python, so is 'Architecture: all', but it > fails on big-endian architectures. The test suite catches this failure. > > The bug wa

Please fix or triage RC bugs

Dear all, Please help keeping the upcoming bookworm freeze short by fixing or triaging RC bugs in key packages [1] before the freeze starts on 12 January 2023 [2]. As you are very likely aware, Debian releases when it's ready. One of the most important criteria is the number of RC bugs. To

Re: writing REJECTED messages publicly on the ITP bugs (was: secnet_0.6.2_multi.changes REJECTED)

ould file RC issues against the "NEW" package, which would get closed by new revisions of the package uploaded to NEW pabs: if the BTS knew about NEW packages that would be great. I have to make notes to file bugs the next day etc. * pabs asked about feasibility in #debbugs #debbugs:

Re: writing REJECTED messages publicly on the ITP bugs (was: secnet_0.6.2_multi.changes REJECTED)

On 4/11/22 19:04, Jonas Smedegaard wrote: Quoting Ian Jackson (2022-04-11 18:51:35) For transparency, I am CCing this reply to debian-devel, and quoting the whole of the REJECTED mail. There does not seem to be anything in here that ought to be private. Please let me know if there is somewhere

Re: [External] Re: Touchpad driver on Lenovo X13 Yoga has major use-stopping bugs

touchpad while typing, touchpad is not >> disable while typing. >> >> these problems prevent any work from getting done cause typing results >> in the cursor moving position on its own resulting in my typing into a >> place above or below where I'm actually typing, among o

Re: Touchpad driver on Lenovo X13 Yoga has major use-stopping bugs

below where I'm actually typing, among other problems. Can anything be done to fix this situation? Or is my only fix to move to a different distro? The main reason I chose Debian is to not have to deal with crippling use bugs like this one. Are the devs doing anything to fix this bug ASAP?

Touchpad driver on Lenovo X13 Yoga has major use-stopping bugs

r problems. Can anything be done to fix this situation? Or is my only fix to move to a different distro? The main reason I chose Debian is to not have to deal with crippling use bugs like this one. Are the devs doing anything to fix this bug ASAP? Can you offer any help? I am running Debian

Re: Reconsider sending ITP bugs to debian-devel: a new list?

Hi Bart, On Thu, Jul 01, 2021 at 02:04:14PM +0200, Bart Martens wrote: > > I agree that the ITP->RFP script was helpful to change the status of the > > bug and it would be good to check if this keeps on working. > > My script doesn't do that anymore. That is intentional. For many ITPs without > p

Re: Reconsider sending ITP bugs to debian-devel: a new list?

Hi, sorry for the late reply. On Fri, Jun 11, 2021 at 09:36:58PM +0500, Andrey Rahmatullin wrote: > On Fri, Jun 11, 2021 at 11:05:02AM -0500, Gunnar Wolf wrote: > > But WNPP is problematic on its own: Right now, we have 1586 normal > > priority open bugs, 4613 wishlist open bugs

  1   2   3   4   5   6   7   8   9   10   >