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

Quoting Timo Röhling (2025-03-10 11:19:01) > Hi Charles, > > * Charles Plessy [2025-03-10 09:32]: > >Le Sun, Mar 09, 2025 at 10:13:51PM +0100, Philip Hands a écrit : > > > >Having skimmed through the 106 mails I currently see in this thread, > > >this is the way I’d summarise people’s preferences

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

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

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

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! Thanks, jik

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

Thank you for bringing this up @Georges ! I would like to add, that generally it is a bit confusing that you don't restrict merge requests against master on https://salsa.debian.org/ to maintainers, since the preferred way for contributors seems to be a patch/diff on top of a already patched r

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, please help fi

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

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 packages that were until > recently part of the essential set, and since deb

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. > > >... > > > > Please provide a pointer wh

Re: Please, minimize your build chroots

On 2023-01-28 21:56:23 +0100, Santiago Vila wrote: > 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

Re: Please, minimize your build chroots

> "Santiago" == Santiago Vila writes: Santiago> 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

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 ha

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

Re: Please, minimize your build chroots

On Sat, Jan 28, 2023 at 07:34:48PM +0100, Guillem Jover wrote: > On Sat, 2023-01-28 at 16:32:17 +0100, Adam Borowski wrote: > > On Sat, Jan 28, 2023 at 01:59:40PM +0100, Santiago Vila wrote: > > > Unsupported by whom? What is supported or unsupported is explained in > > > policy. > > > Policy says

Re: Please, minimize your build chroots

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 has said so > explicitly in recent years. >

Re: Please, minimize your build chroots

On Sat, 2023-01-28 at 16:32:17 +0100, Adam Borowski wrote: > On Sat, Jan 28, 2023 at 01:59:40PM +0100, Santiago Vila wrote: > > Unsupported by whom? What is supported or unsupported is explained in > > policy. > > Policy says it must work. Therefore it should be supported (by fixing the > > bugs)

Re: Please, minimize your build chroots

On Sat, Jan 28, 2023 at 03:11:39PM +0100, Johannes Schauer Marin Rodrigues wrote: > And I asked in my mail to please "decouple the policy and bug severity > question > from the question of what a buildd chroot should contain" for a reason. yes, I know. my point was that too many people won't be

Re: Please, minimize your build chroots

On Sat, Jan 28, 2023 at 03:28:58PM +0100, Johannes Schauer Marin Rodrigues wrote: >... > My proposal is to fix debootstrap #837060 (patch is in the bug report) so that > it only installs Essential:yes, build-essential and apt and discuss if it > makes > sense to have packages like tzdata or e2fsp

Re: Please, minimize your build chroots

Johannes Schauer Marin Rodrigues wrote: > Do you agree that the software in our archive should agree on which > packages are needed to build a source package? Currently, they do > not. dose3 requires only Essential:yes and build-essential being > installed. Who is buggy? Well, the /informational/

Re: Please, minimize your build chroots

On Sat, Jan 28, 2023 at 01:59:40PM +0100, Santiago Vila wrote: > El 28/1/23 a las 12:50, Andreas Henriksson escribió: > > > Claiming there's no point to free software when the problem is simply > > that you are using an *unsupported* setup?!?! > > Unsupported by whom? What is supported or unsuppo

Re: Please, minimize your build chroots

Quoting Ansgar (2023-01-28 14:41:31) > 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

Re: Please, minimize your build chroots

Quoting Holger Levsen (2023-01-28 14:53:37) > On Sat, Jan 28, 2023 at 02:28:30PM +0100, Johannes Schauer Marin Rodrigues > wrote: > > could we decouple the policy and bug severity question from the question of > > what a buildd chroot should contain, please? > [...] > > Why do people call just acc

Re: Please, minimize your build chroots

On Sat, Jan 28, 2023 at 02:28:30PM +0100, Johannes Schauer Marin Rodrigues wrote: >... > Why do people call just accepting that Priority:required packages have to be > part of the buildd chroot the easier solution? We just need to fix debootstrap > bug #837060 and we are done, no? This is mostly

Re: Please, minimize your build chroots

On Sat, Jan 28, 2023 at 02:28:30PM +0100, Johannes Schauer Marin Rodrigues wrote: > could we decouple the policy and bug severity question from the question of > what a buildd chroot should contain, please? [...] > Why do people call just accepting that Priority:required packages have to be > part

Re: Please, minimize your build chroots

On Sat, Jan 28, 2023 at 9:29 PM Johannes Schauer Marin Rodrigues wrote: > To me it seems that we nearly are already at (2). The debootstrap bug #837060 > has a working patch and mmdebstrap exists that can do what is needed today. > Santiago did an archive rebuild to make sure our source package co

Re: Please, minimize your build chroots

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 think is) a bug > in > debootstrap:

Re: Please, minimize your build chroots

Quoting Timo Röhling (2023-01-28 13:30:42) > 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/12/msg00023.html > Your

Re: Please, minimize your build chroots

On 2023-01-28 13:59, Adrian Bunk wrote: I am not saying that trying to force maintainers to spend time on such issues by making them release critical is better, but you are also creating extra work and frustration for the people who are doing QA work in Debian. It also pushes some maintainers t

Re: Please, minimize your build chroots

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 has said so explicitly in recent years. In my experience they are usually saying that FTBFS that do not

Re: Please, minimize your build chroots

On Sat, Jan 28, 2023 at 12:20:16AM +0100, Santiago Vila wrote: > El 27/1/23 a las 22:37, Adrian Bunk escribió: > > On Fri, Dec 16, 2022 at 02:15:13AM +0100, Santiago Vila wrote: ... > > I am right now looking at #1027382, and the first question is how I can > > make apt remove e2fsprogs so that I c

Re: Please, minimize your build chroots

El 28/1/23 a las 13:59, Adrian Bunk escribió: Policy 4.2 also says Source packages should specify which binary packages they require to be installed or not to be installed in order to build correctly. We are not following the "not to be installed" part, which is the can of worms you would

Re: Please, minimize your build chroots

El 28/1/23 a las 12:50, Andreas Henriksson escribió: Policy is not a religion. Policy has many bugs. Policy is very outdated. buildd is not a religion. buildd has bugs, etc. Claiming there's no point to free software when the problem is simply that you are using an *unsupported* setup?!?! U

Re: Please, minimize your build chroots

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/12/msg00023.html Your argument cuts both ways. Right now, Policy says that the bug

Re: Please, minimize your build chroots

Hello, I've previously discussed this topic with Santiago Vila on a bug report but sharing my opinion here for the wider audience. On Sat, Jan 28, 2023 at 12:20:16AM +0100, Santiago Vila wrote: > El 27/1/23 a las 22:37, Adrian Bunk escribió: [...] > This is not the right time to change policy. T

Re: Please, minimize your build chroots

El 28/1/23 a las 10:11, Vincent Bernat escribió: On 2023-01-28 00:20, Santiago Vila wrote: Release Policy exists as a canonical list of what should be RC and > what not, and it's intended to avoid stupid discussions like this one. Extending build-essential is easier than asking many people to

Re: Please, minimize your build chroots

On 2023-01-28 00:20, Santiago Vila wrote: Release Policy exists as a canonical list of what should be RC and > what not, and it's intended to avoid stupid discussions like this one. Extending build-essential is easier than asking many people to do pointless work to satisfy a set of non-existi

Re: Please, minimize your build chroots

El 27/1/23 a las 22:37, Adrian Bunk escribió: On Fri, Dec 16, 2022 at 02:15:13AM +0100, Santiago Vila wrote: Greetings. I'm doing archive-wide rebuilds again. I've just filed 21 bugs with subject "Missing build-depends on tzdata" in bookworm (as tzdata is not build-essential). This is of cour

Re: Please, minimize your build chroots

On Fri, Dec 16, 2022 at 02:15:13AM +0100, Santiago Vila wrote: > Greetings. > > I'm doing archive-wide rebuilds again. > > I've just filed 21 bugs with subject "Missing build-depends on tzdata" > in bookworm (as tzdata is not build-essential). > > This is of course not fun for the maintainers, b

Re: Please, minimize your build chroots

On Sun, Dec 18, 2022 at 06:08:57PM +0100, Johannes Schauer Marin Rodrigues wrote: > Quoting David Kalnischkies (2022-12-18 17:18:28) > > On Fri, Dec 16, 2022 at 03:38:17PM +0100, Santiago Vila wrote: > > > Then there is "e2fsprogs", which apt seems to treat as if it were > > > an essential package

Re: Please, minimize your build chroots

Hi, Quoting David Kalnischkies (2022-12-18 17:18:28) > On Fri, Dec 16, 2022 at 03:38:17PM +0100, Santiago Vila wrote: > > Then there is "e2fsprogs", which apt seems to treat as if it were > > an essential package: > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826587 > > As Julian exp

Re: Please, minimize your build chroots

On Fri, Dec 16, 2022 at 03:38:17PM +0100, Santiago Vila wrote: > Then there is "e2fsprogs", which apt seems to treat as if it were > an essential package: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826587 As Julian explained, it is considered "essential" because the maintainer said so.

Re: Please, minimize your build chroots

El 16/12/22 a las 18:55, Andreas Metzler escribió: I am wondering if there is point to this or whether policy should be changed? Is there some value in investing work in having packages buildable without Prioriry required packages? I'd like to apologize to Andreas for my previous answer, as I b

Re: Please, minimize your build chroots

El 16/12/22 a las 18:55, Andreas Metzler escribió: I am wondering if there is point to this or whether policy should be changed? Is there some value in investing work in having packages buildable without Prioriry required packages? Please do not misrepresent what I said. I never proposed such

Re: Please, minimize your build chroots

On Fri, 2022-12-16 at 18:55:42 +0100, Andreas Metzler wrote: > or apt. > > I am wondering if there is point to this or whether policy should be > changed? Is there some value in investing work in having packages > buildable without Prioriry required packages? > > Such installations can only be fo

Re: Please, minimize your build chroots

On 2022-12-16 Santiago Vila wrote: > Greetings. > I'm doing archive-wide rebuilds again. > I've just filed 21 bugs with subject "Missing build-depends on tzdata" > in bookworm (as tzdata is not build-essential). > This is of course not fun for the maintainers, but it's also not fun > for people

Re: Please, minimize your build chroots

El 16/12/22 a las 4:39, Johannes Schauer Marin Rodrigues escribió: I think truly fixing this problem is a bit more tricky because most build tools like the sbuild schroot backend require apt being installed in the chroot. As of today, the sbuild schroot backend is unable to function with a chroot

Re: Please, minimize your build chroots

Quoting Santiago Vila (2022-12-16 02:15:13) > I've just filed 21 bugs with subject "Missing build-depends on tzdata" > in bookworm (as tzdata is not build-essential). thank you for that! > I can think of two solutions for this: > > A) Either debootstrap, when using buildd profile, installs only

Re: please coordinate using ITP bugreports

Hi Jonas, rust-rmp and rust-rmp-serde are now accepted. Please let me know if there is any problem with it. -- Regards, Blair Noctis OpenPGP_signature Description: OpenPGP digital signature

Re: please coordinate using ITP bugreports

[ Reply sent to debian-devel@l.d.o ] Quoting Blair Noctis (2022-09-24 05:27:57) > Sorry for the situation - I did the rmp (and rmp-serde) upload. That's before > I > realized I can and should check wnpp.d.net before packaging something. I now > check it regularly. Thanks for responding. I am ha

Re: Please participate in Debian Med sprint (Was: 20 years of Debian Med list :-) and suggested sprint date)

Hi Gard, Am Wed, Feb 02, 2022 at 02:29:44PM +0100 schrieb Gard Spreemann: > I don't have push access to the repo, but feel free to add that I can > probably join on the 18th and on the 20th of February, if you end up > picking 18-20. You can push now and we are happy that you intend to join

Re: Please participate in Debian Med sprint (Was: 20 years of Debian Med list :-) and suggested sprint date)

Andreas Tille writes: > Hi again, > > I've just created a preliminary Sprint page[2]. At the top I've added a > table to summarise first responses of participants about the date. > Seems we have a vague preference for the date 2022-02-18 - 2021-02-20. > > I'd be really happy if more interested

Re: please document why a package has been dropped from Testing/Bullseye

On Mon, May 10, 2021 at 06:23:34AM -0500, Michael Lustfield wrote: > On Sun, 9 May 2021 07:30:04 +0200 > Harald Dunkel wrote: > > > > https://packages.debian.org/search?keywords=rsnapshot doesn't tell, so I > > wonder > > what is the recommended way to find out why rsnapshot (or any other packag

Re: please document why a package has been dropped from Testing/Bullseye

On Sun, 9 May 2021 07:30:04 +0200 Harald Dunkel wrote: > Hi folks, > > https://packages.debian.org/search?keywords=rsnapshot doesn't tell, so I > wonder > what is the recommended way to find out why rsnapshot (or any other package) > has been dropped from Testing? I was wondering what the easi

Re: please document why a package has been dropped from Testing/Bullseye

On Sun, May 09, 2021 at 07:30:04AM +0200, Harald Dunkel wrote: > Hi folks, > > https://packages.debian.org/search?keywords=rsnapshot doesn't tell, so I > wonder > what is the recommended way to find out why rsnapshot (or any other package) > has been dropped from Testing? packages.debian.org is i

Re: please document why a package has been dropped from Testing/Bullseye

On 2021-05-09 Harald Dunkel wrote: > https://packages.debian.org/search?keywords=rsnapshot doesn't tell, so > I wonder what is the recommended way to find out why rsnapshot (or any > other package) has been dropped from Testing? > rsnapshot is still in Sid. I found #986709, of course, but this >

Re: [please not now!] call for ftpmaster's transparency

Please! Not now! I absolutely think that accountability and transparency for a couple of delegated teams --and really for delegations in general--needs to be one of the big issues for the next DPL. I think that's true whether it is me or someone else. Our delegates put a lot of time and energy i

Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)

On 11/11/19 6:30 PM, Theodore Y. Ts'o wrote: > Yes, and that's why I use debian/master instead of debian/buster or > debian/bullseye. :-) > > When I do create debian/buster (once it became the stable branch), the > first thing I did after I branched off debian/buster from > debian/master was t

Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)

On 11/14/19 1:59 AM, Jeremy Bicha wrote: > Let me try to be more specific. Many packages are maintained by people > who use gbp. Many packages have pristine-tar branches but do not have > "pristine-tar = True" set. When I work on one of these packages (and I > work on many packages with many mainta

Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)

On Wed, 13 Nov 2019 at 19:59:07 -0500, Jeremy Bicha wrote: > Let me try to be more specific. Many packages are maintained by people > who use gbp. Many packages have pristine-tar branches but do not have > "pristine-tar = True" set. When I work on one of these packages (and I > work on many package

Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)

On Tue, Nov 12, 2019 at 5:23 AM Thomas Goirand wrote: > On 11/11/19 12:50 PM, Jeremy Bicha wrote: > > It is absolutely not possible to set the correct > > pristine-tar=True/False in ~/.gbp.conf to work with your packages > > (which avoid pristine-tar) and the vast majority of gbp packages in > > D

Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)

On 11/13/19 1:53 PM, Andreas Tille wrote: > Except for not agreeing with your opinion about pristine-tar I agree that > debian/gbp.conf is frequently not very helpful and flooded with unneeded > options sometimes. It really makes sense to use ~/.gbp.conf instead. This was the single and only poin

Re: please avoid writing useless/annoying stuff in debian/gbp.conf

Andreas Tille writes: > From time to time I hear this statement. I can confirm that in all > teams I'm working on pristine-tar belongs to the team policy and I never > experienced in those > 2000 packages I've touched any problem with this. > For me this makes some statistically relevant set whi

Re: please avoid writing useless/annoying stuff in debian/gbp.conf

On Mon, Nov 11, 2019 at 11:37:06AM -0800, Russ Allbery wrote: > "Theodore Y. Ts'o" writes: > > > Yes, and that's why I use debian/master instead of debian/buster or > > debian/bullseye. :-) > > > When I do create debian/buster (once it became the stable branch), the > > first thing I did after

Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)

On Tue, Nov 12, 2019 at 11:23:08AM +0100, Thomas Goirand wrote: > > If you're rebuilding a package which is already in the archive, you're > supposed to take the .orig.tar.xz from the archive, and if not, you're > supposed to generate it with git archive (or with the shortcut for that > command: .

Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)

On 11/11/19 12:50 PM, Jeremy Bicha wrote: > On Mon, Nov 11, 2019 at 2:59 AM Thomas Goirand wrote: >> On 11/11/19 1:02 AM, Theodore Y. Ts'o wrote: >>> On Sun, Nov 10, 2019 at 11:20:45PM +0100, Thomas Goirand wrote: Please, *never* do that. It's generally a very bad idea to write anyt

Re: please avoid writing useless/annoying stuff in debian/gbp.conf

"Theodore Y. Ts'o" writes: > Yes, and that's why I use debian/master instead of debian/buster or > debian/bullseye. :-) > When I do create debian/buster (once it became the stable branch), the > first thing I did after I branched off debian/buster from debian/master > was to edit debian/gbp.con

Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)

On Mon, Nov 11, 2019 at 08:58:42AM +0100, Thomas Goirand wrote: > >> Please, *never* do that. It's generally a very bad idea to write > >> anything to debian/gbp.conf. It's as if you were adding your text editor > >> preferences in the package. Instead, please prefer writing in ~/.gbp.conf. > > >

Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)

On Mon, Nov 11, 2019 at 2:59 AM Thomas Goirand wrote: > On 11/11/19 1:02 AM, Theodore Y. Ts'o wrote: > > On Sun, Nov 10, 2019 at 11:20:45PM +0100, Thomas Goirand wrote: > >> > >> Please, *never* do that. It's generally a very bad idea to write > >> anything to debian/gbp.conf. It's as if you were

Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)

On 11/11/19 1:02 AM, Theodore Y. Ts'o wrote: > On Sun, Nov 10, 2019 at 11:20:45PM +0100, Thomas Goirand wrote: >> >> Please, *never* do that. It's generally a very bad idea to write >> anything to debian/gbp.conf. It's as if you were adding your text editor >> preferences in the package. Instead, p

Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)

On Sun, Nov 10, 2019 at 11:20:45PM +0100, Thomas Goirand wrote: > > Please, *never* do that. It's generally a very bad idea to write > anything to debian/gbp.conf. It's as if you were adding your text editor > preferences in the package. Instead, please prefer writing in ~/.gbp.conf. I keep most

  1   2   3   4   5   6   7   8   9   10   >