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
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
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
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
* 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
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
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
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
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
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
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
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
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
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
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
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
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
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
> "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
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
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
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
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.
>
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)
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
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
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/
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
55 matches
Mail list logo
