Re: STFU please (Re: Bits from DPL)

On Thu, Mar 06, 2025 at 02:54:32PM +0530, Pirate Praveen wrote: > On 3/6/25 2:09 PM, Holger Levsen wrote: > > so if the/a team says they cannot handle new members right now and thus > > there should be no big announcement asking for new members, I very much > > think this should be respected and no

Re: please do not use text/markdown

Hi Jonas, * Jonas Smedegaard [2025-03-10 12:20]: It should work, but perhaps what you are experiencing is that by default pandoc expects a blank line between changes of blockquote level: https://pandoc.org/MANUAL.html#extension-blank_before_blockquote Maybe this works: pandoc -f markdown-blan

Re: please do not use text/markdown

is is the way I’d summarise people’s preferences (if anyone sees > >that > I’ve mis-characterised their view, I promise it was not > >intentional, so > please forgive me and correct my mistake) > > > >Hi Philip and everybody, > > > >to be clear: I am supporting the pro

please do not use text/markdown

erised their view, I promise it was not intentional, so > please forgive me and correct my mistake) Hi Philip and everybody, to be clear: I am supporting the proposition to remove the requrement to wrap lines. I would like to add that I think that we should not organise GRs on that kind of questi

Re: STFU please (Re: Bits from DPL)

On Thursday, March 6, 2025 1:53:27 AM MST Marc Haber wrote: > On Thu, Mar 06, 2025 at 08:39:13AM +, Holger Levsen wrote: > >On Thu, Mar 06, 2025 at 08:58:48AM +0100, Marc Haber wrote: > >> Marc. I'll take my Popcorn with salt please. > > > >yeah, it's

Re: STFU please (Re: Bits from DPL)

On 3/6/25 2:09 PM, Holger Levsen wrote: so if the/a team says they cannot handle new members right now and thus there should be no big announcement asking for new members, I very much think this should be respected and not be ignored and spread on our most visible mailing list, where there pain

Re: STFU please (Re: Bits from DPL)

On 06.03.25 09:53, Marc Haber wrote: I apologize for trying to bring a smile into a heated discussion Thank you. -- -- regards -- -- Matthias Urlichs OpenPGP_signature.asc Description: OpenPGP digital signature

Re: STFU please (Re: Bits from DPL)

On Thu, Mar 06, 2025 at 08:39:13AM +, Holger Levsen wrote: On Thu, Mar 06, 2025 at 08:58:48AM +0100, Marc Haber wrote: Marc. I'll take my Popcorn with salt please. yeah, it's pretty funny to see a team burn out and have the same silly & salty discussion about this again

STFU please (Re: Bits from DPL)

On Thu, Mar 06, 2025 at 08:58:48AM +0100, Marc Haber wrote: > Marc. I'll take my Popcorn with salt please. yeah, it's pretty funny to see a team burn out and have the same silly & salty discussion about this again and again. or maybe not. also talking about how NEW is a b

Re: Bug#397761: Bug reports for Uploaders (was: Re #397761: bugs.debian.org: please forward bug reports to Uploaders also)

On Mon, 03 Mar 2025, Blair Noctis wrote:n > Dan Armstrong (don) wontfix'd it after stating that, quote: > > If the maintainer is not given as a mailing list, then the uploaders > > should all subscribe to the PTS for a given package. > > and > > > The problem is that if I start sending mails to U

Re: Bug reports for Uploaders (was: Re #397761: bugs.debian.org: please forward bug reports to Uploaders also)

On Sun, Mar 2, 2025 at 12:07 PM Blair Noctis wrote: > (I'm also confused by the fact that follow-ups to bug reports aren't > forwarded to submitters by default, but the submitter must X-Debbugs-Cc > themselves, but then which is basically the default behavior of reportbug(1) > now IIRC, but tha

Re: Bug reports for Uploaders (was: Re #397761: bugs.debian.org: please forward bug reports to Uploaders also)

On 2025-03-02 Blair Noctis wrote: [...] > 2. Let PTS automatically subscribe maintainers to packages they are Uploaders > of > In the current version of the PTS, subscribing to a package means either a. > after logging in, clicking the Subscribe button on > tracker.debian.org/pkg/foo, and opti

Re: Bug reports for Uploaders (was: Re #397761: bugs.debian.org: please forward bug reports to Uploaders also)

On Mon, 2025-03-03 at 01:06 +0800, Blair Noctis wrote: > In the current version of the PTS, subscribing to a package means > either a. after logging in, clicking the Subscribe button on > tracker.debian.org/pkg/foo, and optionally changing topics > ("keywords"); b. with devscripts installed, runnin

Re: Bug reports for Uploaders (was: Re #397761: bugs.debian.org: please forward bug reports to Uploaders also)

Hi all, I am in strong favor of 1., letting BTS forward to Uploaders. I'm Uploader for a few tens of (team-maintained) packages, most of which I don't particularly care about since I only introduced them as dependencies, and I'm not going to subscribe to all of them. Still, I do feel responsi

Re: Bug reports for Uploaders (was: Re #397761: bugs.debian.org: please forward bug reports to Uploaders also)

I will just note that I have been a Debian Developer for almost 30 years, and a few months after I started maintaining varnish and other related packages I am still not sure if I did everything needed to receive one and only one copy of new bug reports. So I would welcome some rationalization in

Re: Bug reports for Uploaders (was: Re #397761: bugs.debian.org: please forward bug reports to Uploaders also)

Quoting Blair Noctis (2025-03-02 18:06:49) [...] > Dan Armstrong (don) wontfix'd it after stating that, quote: > > > If the maintainer is not given as a mailing list, then the uploaders > > should all subscribe to the PTS for a given package. [...] > I added that a. team maintenance means hundreds

Bug reports for Uploaders (was: Re #397761: bugs.debian.org: please forward bug reports to Uploaders also)

Dear -devel, Way back in 2006 (19 years ago), #397761 was submitted to request for BTS to forward bug reports also to the Uploaders. Dan Armstrong (don) wontfix'd it after stating that, quote: If the maintainer is not given as a mailing list, then the uploaders should all subscribe to the PTS

Please Test Pam 1.7.0 from experimental

Please test pam from experimental. Upstream made some significant changes including completely rewriting the build system from autotools to meson. I've also made some significant changes around pam_limits and when we override limits set by systemd (now, we normally do not). I'd love

938 open Merge Requests at in main Debian group on Salsa - Please help with reviews!

Hi, If you have some spare time for Debian today, please consider collaborating with another maintainer by providing them review/feedback on an open Merge Request. There are currently 938 open merge requests in the main Debian group on Salsa: https://salsa.debian.org/groups/debian

Please test adduser from experimental

Hi, I just uploaded a major update for adduser to experimantal (done during #RIPE89 in Prague). adduser and deluser now run with perl -T, which meant a lot of input sanitizing. I am sure I didn't do everything right, so it needs some testing before going to unstable. The test suite runs alright,

Bug#1084914: task-telugu-desktop: Please migrate away from fcitx4

the fallback. If there are any better places for such discussion, please let me know.) Hi all, As shown on https://packages.debian.org/unstable/task-telugu-desktop , tasksel tries to install the fcitx(4) input method to provide Telugu input support. However, (with my Debian Input Method Team

Re: Please help me fix the build pipeline for apt-listchanges on Salsa, which is failing

Quoting Jonathan Kamens (2024-09-02 17:52:42) > On 9/2/24 11:47 AM, Colin Watson wrote: > > On Mon, Sep 02, 2024 at 11:15:50AM -0400, Jonathan Kamens wrote: > >> I was suggesting that perhaps the root cause of /why/ the .deb files are > >> not > >> identical is because if there's no timestamp in t

Re: Please help me fix the build pipeline for apt-listchanges on Salsa, which is failing

On 9/2/24 11:47 AM, Colin Watson wrote: On Mon, Sep 02, 2024 at 11:15:50AM -0400, Jonathan Kamens wrote: I was suggesting that perhaps the root cause of /why/ the .deb files are not identical is because if there's no timestamp in the trailer line of the top changelog entry, that impacts the cont

Re: Please help me fix the build pipeline for apt-listchanges on Salsa, which is failing

On Mon, Sep 02, 2024 at 11:15:50AM -0400, Jonathan Kamens wrote: > I was suggesting that perhaps the root cause of /why/ the .deb files are not > identical is because if there's no timestamp in the trailer line of the top > changelog entry, that impacts the contents of the .deb. IMO your debian/ch

Re: Please help me fix the build pipeline for apt-listchanges on Salsa, which is failing

On Mon, Sep 02, 2024 at 11:15:50AM -0400, Jonathan Kamens wrote: > P.S. Wow, diffoscope has a /lot/ of dependencies. I understand why, but > still... wow. (Note that those are Recommends and that there is diffoscope-minimal) -- WBR, wRAR signature.asc Description: PGP signature

Re: Please help me fix the build pipeline for apt-listchanges on Salsa, which is failing

On 9/2/24 4:09 AM, IOhannes m zmölnig (Debian GNU|Linux) wrote: On 9/2/24 03:19, Jonathan Kamens wrote: However, the pipeline is still failing, now in reprotest. For example . Perhaps this is because I haven't yet finalized t

Re: Please help me fix the build pipeline for apt-listchanges on Salsa, which is failing

IOhannes m zmölnig (Debian GNU|Linux) writes: > [[PGP Signed Part:Undecided]] > On 9/2/24 03:19, Jonathan Kamens wrote: >> However, the pipeline is still failing, now in reprotest. For >> example >> . >> Perhaps >> this is bec

Re: Please help me fix the build pipeline for apt-listchanges on Salsa, which is failing

On 9/2/24 03:19, Jonathan Kamens wrote: However, the pipeline is still failing, now in reprotest. For example . Perhaps this is because I haven't yet finalized the changelog for the upcoming release so the trailer line is bad

Re: Please help me fix the build pipeline for apt-listchanges on Salsa, which is failing

On 9/1/24 6:22 AM, Philip Hands wrote: If you look at the repo on Salsa, and find: Settings > CI/CD > General Pipelines > CI/CD configuration file you'll see it's set to: recipes/debian.yml@salsa-ci-team/pipeline which is how the pipeline gets it's configuration. The documentation is h

Re: Please help me fix the build pipeline for apt-listchanges on Salsa, which is failing

On Sat, Aug 31, 2024 at 07:06:30PM -0400, Jonathan Kamens wrote: >|dh clean --with python3 --buildsystem=pybuild dh_auto_clean >-O--buildsystem=pybuild I: pybuild base:311: python3.12 setup.py >clean /usr/lib/python3/dist-packages/setuptools/__init__.py:88: >_DeprecatedInstaller: se

Re: Please help me fix the build pipeline for apt-listchanges on Salsa, which is failing

On Sat, Aug 31, 2024 at 07:06:30PM -0400, Jonathan Kamens wrote: > Hey folks, > > I had to step away from working on apt-listchanges > for quite a while (nearly > a year), and upon stepping back into it today and pushing some changes to > Salsa, I

Re: Please help me fix the build pipeline for apt-listchanges on Salsa, which is failing

Jonathan Kamens writes: > Hey folks, > > I had to step away from working on apt-listchanges > for quite a while > (nearly a year), and upon stepping back into it today and pushing some > changes to Salsa, I discovered that the build pipeline—w

Re: Please help me fix the build pipeline for apt-listchanges on Salsa, which is failing

Hi Jonathan, On Sun Sep 1, 2024 at 1:06 AM CEST, Jonathan Kamens wrote: I had to step away from working on apt-listchanges for quite a while (nearly a year), and upon stepping back into it today and pushing some changes to Salsa, I discovered

Please help me fix the build pipeline for apt-listchanges on Salsa, which is failing

Hey folks, I had to step away from working on apt-listchanges for quite a while (nearly a year), and upon stepping back into it today and pushing some changes to Salsa, I discovered that the build pipeline—which is configured outside my Salsa

Re: Please block glj....@gmail.com from Debian lists [Re: UOC and Britsh Council lawsuit]

On 22/4/24 21:29, Steve Langasek wrote: On Mon, Apr 22, 2024 at 05:11:39PM +0200, José Luis González González wrote: I sent 5 minutes ago an email to "Plaza de Castilla *courts*" setting                    ^^^ BS. It just doesn't work like this.  A regular citizen can't communicate

Please block glj....@gmail.com from Debian lists [Re: UOC and Britsh Council lawsuit]

On Mon, Apr 22, 2024 at 05:11:39PM +0200, José Luis González González wrote: > I sent 5 minutes ago an email to "Plaza de Castilla *courts*" setting > it crystal clear that it was a long time ago the lawsuit to Universitat > Oberta de Catalunya and British Council had to be solved. > > "Kinda or

Re: Please help test the PAM in experimental

Hi, you don't seem to address: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029097 why? On Fri, 2024-01-19 at 11:40 -0700, Sam Hartman wrote: > > There are a number of changes, and I'd just like a bit more > confidence > that it works as expected before uploading to unstable in about a > w

Re: Please help test the PAM in experimental

On Fri, 19 Jan 2024 at 18:41, Sam Hartman wrote: > > > There are a number of changes, and I'd just like a bit more confidence > that it works as expected before uploading to unstable in about a week. > > Changes include: > > * Running pam_umask with usergroups support by default. > > * libpam-modu

Please help test the PAM in experimental

There are a number of changes, and I'd just like a bit more confidence that it works as expected before uploading to unstable in about a week. Changes include: * Running pam_umask with usergroups support by default. * libpam-modules now depends on libsystemd0 because utmp is not y2038-clean a

Bug#1057290: bpftool: please build from https://github.com/libbpf/bpftool

bpf-next Linux source tree. The Maintainers have said "Please use this Github repository for building and packaging bpftool" at [2] The announcement was at [3]. imho, packaging it from the github instead of the kernel source will fix three issues: 1. bpftool will use libbpf available

New apt-listchanges in experimental, please test

Version 4.4 of apt-listchanges is now available for testing in experimental (N.B., we released 4.3 and 4.4 a day apart because something came up last-minute, so make sure to `apt update` before installing so you get 4.4). It has both functional changes and bug fixes in it. Most notably, we've

apt-listchanges testers: new version (4.2) is available, please note these changes

Version 4.2 of apt-listchanges is now available in experimental. Please test. Three important notes: 1) There was a bug in 4.1 that caused corruption in the database of previously seen changelog entries (sorry!). The bug has been fixed, but the corruption was too complex to be recoverable

Re: Please test apt-listchanges 4.0 in experimental

Le mer. 11 oct. 2023 à 14:54, Jonathan Kamens a écrit : > Can you confirm that this occurred with 4.0 rather than 4.1? I'm a bit messy & forgetful these times. But you have #1053812 against 4.1 already. > > Can annotations/mypy testing be considered now "best practices" for > > Debian native pack

Re: Please test apt-listchanges 4.0 in experimental

On 10/11/23 03:37, Alexandre Detiste wrote: Le dim. 8 oct. 2023 à 17:27, Jonathan Kamens a écrit : I'd appreciate some testing from folks here before it gets promoted to unstable. I got important NEWS from libx11 from 2006 (?) so far so good for the rest. Can you confirm that this occurre

Re: Please test apt-listchanges 4.0 in experimental

Le dim. 8 oct. 2023 à 17:27, Jonathan Kamens a écrit : > I'd appreciate some testing from folks here before it gets promoted to > unstable. I got important NEWS from libx11 from 2006 (?) so far so good for the rest. > the database needs to be populated with data for existing packages durin

Re: Please test apt-listchanges 4.0 in experimental

N.B. apt-listchanges has been upgraded to 4.1 in experimental with some significant fixes, so if you're testing 4.0, please upgrade to 4.1, and if you're not testing yet, what are you waiting for? ;-) Thanks to everyone who has tested and helped identify the issues fixed in 4.1

MR against patched package (Was: Please give a test to cron package, in experimental)

On 10/10/23 10:15, Alex wrote: So I wonder why you don't just provide an additional branch "master-patched" against which merge requests can be opened without the risk of causing conflicts with existing patches. This can be easily done with git-buildpackage's `pq` (patch queue) subcommand. An

Re: Please give a test to cron package, in experimental

e now included in Git's log, which preserves authorship information. If you have some free time, please can you give a try, or just share your thoughts about this change ? I intend to push version 4.0 to debian/sid shortly if we can agree. Best regards, Georges. OpenPGP_signature Description: OpenPGP digital signature

Please test apt-listchanges 4.0 in experimental

k for that advice). Also, I'm still waiting on some translations, so you may notice some English strings in foreign locales. There is no need to report this to me, I'm aware. Please file bugs, reply in this thread, or email me privately with any feedback as you deem appropriate. I

Bug#1050994: xutils-dev: Please add support for loong64

Source: xutils-dev Version: 1:7.7+6.1 Severity: normal User: debian-devel@lists.debian.org Usertags: loong64 X-Debbugs-Cc: debian-devel@lists.debian.org,zhangjial...@loongson.cn,zhangdan...@loongson.cn Hi! Multiple X packages currently fail to build from source on loong64 due to missing architec

Bug#1050893: gcc-13: Please disable Ada, D, Go and M2 as well as GDB support on loong64

Source: gcc-13 Version: 13.2.0-2 Severity: normal Tags: patch User: debian-devel@lists.debian.org Usertags: loong64 X-Debbugs-Cc: debian-devel@lists.debian.org Hello! In order to ease the bootstrap of the new loong64 port, please reduce the build dependencies and number of enabled languages

Re: another problem class from /usr-merge [Re: Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/]

Hi, I fear we are not done with empty directory loss yet. This is a technical update for future reference. On Wed, May 31, 2023 at 11:59:58AM +0200, Helmut Grohne wrote: > On Tue, May 30, 2023 at 11:53:00AM +0200, Helmut Grohne wrote: > > In effect, this bug report is an instance of a bug class.

Re: Bug#1040032: rkdeveloptool: please switch to newer Pine64 fork

wice on > the same > day, given that there hasn't been much movement since 2021 ;-). I will be > careful to > make sure I consider this in future. A version number is for aligning releases on a timeline. A git hash serves a different purpose. Please do not bloat version strings by

Re: Bug#1040032: rkdeveloptool: please switch to newer Pine64 fork

onto it, > > > but have found the code in Debian to be inferior for that use. > > > > > > Please consider switching to the (slightly) newer fork done by Pine64, > > > which fixes some bugs and improves the user interface, while seemingly > > > fully pr

Re: Bug#1040032: rkdeveloptool: please switch to newer Pine64 fork

Hi Cristopher, Quoting Christopher Obbard (2023-07-04 16:01:19) > On Sat, 2023-07-01 at 11:07 +0200, Jonas Smedegaard wrote: > > I own a PineNote, and use rkdeveloptool for flashing software onto it, > > but have found the code in Debian to be inferior for that use. > >

Re: Bug#1040032: rkdeveloptool: please switch to newer Pine64 fork

Debian to be inferior for that use. > > Please consider switching to the (slightly) newer fork done by Pine64, > which fixes some bugs and improves the user interface, while seemingly > fully preserving backwards compatibility: > https://gitlab.com/pine64-org/quartz-bsp/rkdevelopt

Bug#1035883: Close out this report, please

I have looked at my other debian computers and the TMOUT setting works on them. I'm not sure why TMOUT does not work on my one computer, but it is not worth the effort to try to debug this issue for one system. Please consider this issue closed. Jim A.

Re: another problem class from /usr-merge [Re: Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/]

On Wed, 31 May 2023 at 11:18, Helmut Grohne wrote: > > Hi, > > On Tue, May 30, 2023 at 11:53:00AM +0200, Helmut Grohne wrote: > > In effect, this bug report is an instance of a bug class. I am in the > > process of quantifying its effects, but I do not have useful numbers at > > this time. As an i

Re: another problem class from /usr-merge [Re: Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/]

Hi, On Tue, May 30, 2023 at 11:53:00AM +0200, Helmut Grohne wrote: > In effect, this bug report is an instance of a bug class. I am in the > process of quantifying its effects, but I do not have useful numbers at > this time. As an initial gauge, I think it is about 2000 binary packages > that shi

Re: another problem class from /usr-merge [Re: Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/]

On Tue, 30 May 2023 at 14:09, Helmut Grohne wrote: > > Hi Luca, > > On Tue, May 30, 2023 at 11:23:07AM +0100, Luca Boccassi wrote: > > > > - unmerged-usr paths are no longer supported > > > > > > Then you argue that this bug would affect only unmerged systems, while > > > it actually is in reverse

Re: another problem class from /usr-merge [Re: Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/]

Hi Luca, On Tue, May 30, 2023 at 11:23:07AM +0100, Luca Boccassi wrote: > > > - unmerged-usr paths are no longer supported > > > > Then you argue that this bug would affect only unmerged systems, while > > it actually is in reverse. Unmerged systems are unaffected by this bug > > class. The deleti

Re: another problem class from /usr-merge [Re: Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/]

On Tue, 30 May 2023 at 10:53, Helmut Grohne wrote: > > Context for d-devel: > > Andreas Beckmann noticed that systemd ships an empty directory > /usr/lib/modules-load.d. When removing a package that ships a file in > /lib/modules-load.d (such as multipath-tools), dpkg may in some > circumstanced d

Re: another problem class from /usr-merge [Re: Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/]

On Tue, May 30, 2023 at 11:53:01AM +0200, Helmut Grohne wrote: > Are there other kinds of resources in dpkg that can be shared like > directories? Thinking... Yes, regular files. How can files be shared? > Via Multi-Arch: same. Can that happen for real? Yes. I've attached an > artificial reproduce

another problem class from /usr-merge [Re: Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/]

t be real. We shouldn't be scared, but "it probably works" may not be the best approach either. And then Andreas got me thinking. Before delving into that, I'd like to again express thanks to Andreas. When we see a bug from Andreas, can we please start with thanking him? Even if

Re: Bug#932957: Please migrate Release Notes to reStructuredText

Hi, Stéphane Blondon wrote (Sun, 28 May 2023 13:16:24 +0200): > > > Richard Lewis wrote (Fri, 19 May > > 2023 00:58:26 +0100): > > > > > - are the red hyphens in eg the 'deb...' line near the top of > > > > > > https://people.debian.org/~holgerw/release-notes_sphinx/en/html/issues.html > > > >

Re: Bug#932957: Please migrate Release Notes to reStructuredText

> > Richard Lewis wrote (Fri, 19 May > 2023 00:58:26 +0100): > > > - are the red hyphens in eg the 'deb...' line near the top of > > > > https://people.debian.org/~holgerw/release-notes_sphinx/en/html/issues.html > > > meant to be red? (maybe it is a syntax error?) > > Sphinx uses Pygments to h

Re: #932957 Please migrate Release Notes to reStructuredText

[ Sending this to #932957 as well, as it contains valueable info on that topic ] Jeremy Stanley wrote (Wed, 24 May 2023 18:22:09 +): > On 2023-05-24 19:40:56 +0200 (+0200), Agathe Porte wrote: > [...] > > Maybe the idea was to introduce %OLD_RELEASE_NAME% and to call sed to > > replace this

Re: #932957 Please migrate Release Notes to reStructuredText

On 2023-05-24 19:40:56 +0200 (+0200), Agathe Porte wrote: [...] > Maybe the idea was to introduce %OLD_RELEASE_NAME% and to call sed to > replace this kind of strings in a build step, and not rely on sphinx > substitution at all. > > I know that I have done this a few times and it works fine as a

Re: #932957 Please migrate Release Notes to reStructuredText

is still lacking some > > > functionality, > > > which is heavily used in the release-notes. > > > That is the use of substitutions within URLs. > > > In docbook speach these were entities, and you could use them in URLs > > > like this: > >

Bug#1036077: please reassign to xserver

Since this seems to be a xserver problem, could you please reassign the ticket to the correct xserver package? *t

Re: Bug#932957: Please migrate Release Notes to reStructuredText

[[ Replying to two mails in one ]] Hi, Holger Wansing wrote (Sat, 20 May 2023 23:26:47 +0200): > James Addison wrote (Fri, 19 May 2023 23:28:55 +0100): > > > Please note the &oldreleasename; in the URL! > > > I could not get this working with sphinx (if som

Re: #932957 Please migrate Release Notes to reStructuredText

the release-notes. > > That is the use of substitutions within URLs. > > In docbook speach these were entities, and you could use them in URLs like > > this: > > > > Please follow the instructions in the > > > url="https://www.debian.org/

Re: #932957 Please migrate Release Notes to reStructuredText

each these were entities, and you could use them in URLs like > this: > > Please follow the instructions in the > url="https://www.debian.org/releases/&oldreleasename;/releasenotes";>Release > Notes for &debian; &oldrelease; to upgrade to &

Re: #932957 Please migrate Release Notes to reStructuredText

these were entities, and you could use them in URLs like this: Please follow the instructions in the https://www.debian.org/releases/&oldreleasename;/releasenotes";>Release Notes for &debian; &oldrelease; to upgrade to &debian; &oldrelease; first if needed. Ple

Re: ssh-audit: Please update the debian package

Quoting Robert Ernst (2023-05-05 08:24:00) > I already sent a MR a week ago. But the maintainer  ChangZhuo Chen (陳昌倬) > replied with cryptic messages via E-Mail, never > accepted the Merge Request and then stopped replying to mails. I also > would be interested to have progress h

Re: Bug#1035528: ssh-audit: Please update the debian package

cryptic messages via E-Mail, never accepted > the Merge Request and then stopped replying to mails. I also would be > interested to have progress here. Sorry, I did not submit review result into salsa. Please check https://salsa.debian.org/debian/ssh-audit/-/merge_requests/4 again. --

ssh-audit: Please update the debian package

Hello Martin, thank you for creating Bug report #1035528 The missing update might be due to a broken watchfile. I already sent a MR a week ago. But the maintainer  ChangZhuo Chen (陳昌倬) replied with cryptic messages via E-Mail, never accepted the Merge Request and then stopped replying to mail

Bug#1021292: dpkg-buildflags: Please add support for pointer authentication on arm64

Package: dpkg-dev Followup-For: Bug #1021292 X-Debbugs-Cc: woo...@wookware.org, debian-devel@lists.debian.org > We decided that the best thing to do was create a new hardening flags > feature called 'branch' to add to the existing set. This enables > -mbranch-protection=standard on arm64, and > -f

Bug#1032440: www.d.o: please link to single html page version of developers-reference

package: www.debian.org severity: wishlist x-debbugs-cc: debian-devel@lists.debian.org hi, On Mon, Mar 06, 2023 at 07:46:43PM +, Holger Levsen wrote: > [...], there's a single page HTML version available again, eg on > https://www.debian.org/doc/manuals/developers-reference/developers-referen

Re: Please, minimize your build chroots

El 30/1/23 a las 14:05, Guillem Jover escribió: Given the number of packages that currently declare a dependency on tzdata (34~), the ones that seem to have the most potential to pull it for others are language bindings such as python3-dateutil, python3-tz ruby-tzinfo, etc, which handle timezone

Re: Please, minimize your build chroots

On Sun, 2023-01-29 at 12:28:37 +0200, Adrian Bunk wrote: > On Sun, Jan 29, 2023 at 05:00:56AM +0100, Guillem Jover wrote: > > On Sat, 2023-01-28 at 21:35:01 +0200, Adrian Bunk wrote: > > > Removing tzdata from the essential set made sense, and I do see your > > > point that tzdata does not fit the

Re: Please, minimize your build chroots

El 30/1/23 a las 13:41, Santiago Vila escribió: Note: I've downgraded the bugs in dispute to important, so they are not RC anymore, per request of Sebastian Ramacher. I mean: Sebastian started to downgrade them, and I've downgraded the remaining open bugs which were not downgraded by him, to co

Re: Please, minimize your build chroots

El 27/1/23 a las 22:37, Adrian Bunk escribió: Speaking as someone who is doing a lot of QA work, [...] Note: I've downgraded the bugs in dispute to important, so they are not RC anymore, per request of Sebastian Ramacher. I just wanted to point out that the "it's more work for me" argument goe

Re: Please, minimize your build chroots

* Wouter Verhelst [2023-01-30 12:07]: What is "RC" is defined by the release team, not by policy. The release team has clarified that these bugs are not RC. My mistake, I conflated policy violation and RC. Other than that, my original point stands: if you think Policy is wrong, p

Re: Please, minimize your build chroots

On Sat, Jan 28, 2023 at 01:30:42PM +0100, Timo Röhling wrote: > Hi Andreas, > > * Andreas Henriksson [2023-01-28 12:50]: > > Policy is not a religion. Policy has many bugs. Policy is very outdated. > > [...] > > Here's an example you could follow: > > https://lists.debian.org/debian-policy/2022/1

Re: Please, minimize your build chroots

El 29/1/23 a las 9:56, Sebastian Ramacher escribió: On 2023-01-28 15:55:05 -0800, Russ Allbery wrote: Historically, we have not treated FTBFS bugs as falling into the category of mass bug filing or requiring this pre-discussion. Various folks have been mass-filing FTBFS bugs near the release fr

Re: Please, minimize your build chroots

On Sun, 2023-01-29 at 13:43 +0100, Santiago Vila wrote: > What you call current practice is only current debootstrap behaviour. Current practice is to use Build-Depends to specify build dependencies in a way that the buildd network will successfully build packages. The data might also be of (limit

Re: Please, minimize your build chroots

El 28/1/23 a las 14:41, Ansgar escribió: Johannes Schauer Marin Rodrigues writes: I think the much more interesting question is in what environment we want to build our packages in. Currently, on buildds, we build them in a chroot that has Priority:required and build-essential because of (what I

Re: Please, minimize your build chroots

On Sun, Jan 29, 2023 at 05:00:56AM +0100, Guillem Jover wrote: > On Sat, 2023-01-28 at 21:35:01 +0200, Adrian Bunk wrote: > > I don't think such arguments are bringing us forward, > > we should rather resolve the problem that these differ. > > > > All/Most(?) packages where they do differ are pack

Re: Please, minimize your build chroots

On 2023-01-28 15:55:05 -0800, Russ Allbery wrote: > Sebastian Ramacher writes: > > > As with all mass bug filings, discuss the issue first on debian-devel. > > See developer's reference 7.1.1. This discussion could have both > > answered the questions whther RC severity is appropriate for this ty

Re: Please, minimize your build chroots

e importantly of clean definition of a specification (which seems rather more important than the other concerns). The work to spot these problems has already been done, and the changes required are trivial and minimal (disregarding any severity consideration here). > Everyone can feel free

Re: Please, minimize your build chroots

Sebastian Ramacher writes: > As with all mass bug filings, discuss the issue first on debian-devel. > See developer's reference 7.1.1. This discussion could have both > answered the questions whther RC severity is appropriate for this type > of bug and whether it's a bug at all. Historically, we

Re: Please, minimize your build chroots

On Sat, Jan 28, 2023 at 10:23:19PM +0100, Santiago Vila wrote: > El 28/1/23 a las 22:18, Adrian Bunk escribió: > > On Sat, Jan 28, 2023 at 09:45:14PM +0100, Santiago Vila wrote: > > > ... > > > The other one: There are a bunch of packages whose unit tests rely on > > > tzdata. The tzdata > > > pac

Re: Please, minimize your build chroots

On Sat, Jan 28, 2023 at 09:45:14PM +0100, Santiago Vila wrote: >... > The other one: There are a bunch of packages whose unit tests rely on tzdata. > The tzdata > package changes often during the lifetime of stable, and as a result, some > package might > stop building from source. If we wanted t

Re: Please, minimize your build chroots

El 28/1/23 a las 22:18, Adrian Bunk escribió: On Sat, Jan 28, 2023 at 09:45:14PM +0100, Santiago Vila wrote: ... The other one: There are a bunch of packages whose unit tests rely on tzdata. The tzdata package changes often during the lifetime of stable, and as a result, some package might sto

Re: Please, minimize your build chroots

On 2023-01-28 20:44:50 +0100, Sebastian Ramacher wrote: > On 2023-01-28 15:03:04 +0200, Adrian Bunk wrote: > > On Sat, Jan 28, 2023 at 12:24:47PM +0100, Santiago Vila wrote: > > >... > > > * Those bugs are RC by definition and have been for a long time. > > >.

Re: Please, minimize your build chroots

se bugs are RC by definition and have been for a long time. > > > > ... > > > > > > Please provide a pointer where a release team member has said so > > > explicitly in recent years. > > > > > > In my experience they are usually sa

Re: Please, minimize your build chroots

gt;> ... * Those bugs are RC by definition and have been for a long >>>> time. ... >>> >>> Please provide a pointer where a release team member has said so >>> explicitly in recent years. >>> >>> In my experience t

Re: Please, minimize your build chroots

El 28/1/23 a las 20:44, Sebastian Ramacher escribió: On 2023-01-28 15:03:04 +0200, Adrian Bunk wrote: On Sat, Jan 28, 2023 at 12:24:47PM +0100, Santiago Vila wrote: ... * Those bugs are RC by definition and have been for a long time. ... Please provide a pointer where a release team member

Re: Please, minimize your build chroots

El 28/1/23 a las 20:35, Adrian Bunk escribió: I have so far not seen any technical arguments why removing tzdata from the build essential set would be better for Debian than keeping it there. Removing tzdata reduces the size of a chroot that has the build dependencies for the hello package instal

  1   2   3   4   5   6   7   8   9   10   >