all services, using such as interpreter
> could maybe provide an easy support path for sysvinit on non-linux
> platforms for a large number of "simple" services.
>
> There's a subthread about that starting at
> https://lists.debian.org/debian-devel/2013/05/msg01309.html
>
Hi Steve,
On Tue, Oct 29, 2013 at 09:31:37AM -0700, Steve Langasek wrote:
> On Tue, Oct 29, 2013 at 10:22:54AM +0100, Helmut Grohne wrote:
> > Having read the parts of the ctte bug, it feels odd to preclude the
> > option of supporting multiple init systems from discussion or
&g
Hi Luca,
On Fri, Aug 02, 2024 at 01:43:04AM +0100, Luca Boccassi wrote:
> 1) The os-release specification must be adhered to, and it must be
> possible to tell the difference between testing vs unstable, and each
> must be correctly identified by the respective metadata
Given the state of discuss
Hi Wouter,
I am continuing the off-topic part below. Earlier, in this discussion I
noted that being able to distinguish testing and unstable is rarely the
right thing to do. I'll use your nbd example to show why. Everyone not
interested in nbd autopktests may stop reading here.
On Sun, Aug 04, 20
Hi Luca,
On Fri, Aug 02, 2024 at 04:17:43PM +0100, Luca Boccassi wrote:
> Validating is of course necessary. If the worry is around changing the
> dependencies of base-files, I would be happy to carry the dependency on
> a new os-release binary package in init-system-helpers, which is
> already Es
Hi Gioele,
On Mon, Aug 05, 2024 at 08:34:41AM +0200, Gioele Barabucci wrote:
> as the maintainer (and upstream author) of the current lsb_release
> implementation used in Debian and derivatives (src:lsb-release-minimal), I'd
> like to voice my support in favor of having enough information in
> /us
Hi Luca,
On Tue, Aug 06, 2024 at 10:42:28AM +0100, Luca Boccassi wrote:
> that matters. This is not a hard technical problem with no known
> solution that we are asking for design guidance on. This is a trivial
> technical problem with a hard social conflict at its core. What we are
That's actual
On Tue, Aug 06, 2024 at 08:33:39PM +0800, Sean Whitton wrote:
> Hello,
>
> I call for votes on the following:
>
> =
> BEGIN BALLOT
>
> The Technical Committee declines to overrule the maintainer of
> base-files, or issue any advice on issues concerning /etc/os-release.
>
> We do not think t
Hi Luca,
I kindly ask you to stop posting to this bug and mailing list for at
least 24h from now. Multiple participants have asked you to improve the
way you interact. I am not seeing such improvement and remind you of the
Debian Code of Conduct available at
https://www.debian.org/code_of_conduct.
On Sat, Aug 17, 2024 at 12:10:52PM +0800, Sean Whitton wrote:
> ===BEGIN BALLOT
>
> A: Christoph Berg
> B: Matthew Garrett
> C: Helmut Grohne
> D: Stefano Rivera
> E: Timo Röhling
> F: Craig Small
> G: Matthew Vernon
> H: Sean Whitton
>
> ===END BALLO
On Fri, Aug 23, 2024 at 04:08:28PM +0800, Yunqiang Su wrote:
> I struggled with the build system, and I know the real problem:
Thanks for chiming in!
> 1. linux-libc-dev-ARCH-cross is useful, for some case if we maintain an cross
> toolchain of a port
> that Debian is not supported yet. The exa
Added Bastian to Cc for a question below.
On Sun, Aug 25, 2024 at 01:14:27AM +0800, YunQiang Su wrote:
> Helmut Grohne 于2024年8月24日周六 19:20写道：
> > I think this is a bad example on multiple levels. For one thing,
> > limits.h is glibc and not linux. Then, it is not actually
&
Hi Ben,
Dropping leader@ and community@ from Cc as this is a technical
side-track.
On Thu, Sep 12, 2024 at 12:38:24AM +0200, Ben Hutchings wrote:
> On Mon, 2024-09-09 at 02:13 +0200, Ben Hutchings wrote:
> [...]
> > My answers below are mine alone. I have not discussed this with other
> > team m
Hi Ben,
On Thu, Sep 12, 2024 at 07:56:09PM +0200, Ben Hutchings wrote:
> It is trivial for us to add support for additional architectures once
> they are minimally supported in upstream Linux (we may also require
> that dpkg recognises their triplet; I'm not sure). There is no
> requirement that
On Sat, Dec 14, 2013 at 11:53:42PM +0100, Michael Stapelberg wrote:
> Ian Jackson writes:
> > I think it would be good, regardless of what the TC decides on the
> > init system question for Debian, for systemd and upstart to converge
> > on a single reasonable protocol.
>
On Thu, Jul 17, 2014 at 08:07:00PM +0100, Adam D. Barratt wrote:
> On Thu, 2014-07-17 at 20:46 +0200, Helmut Grohne wrote:
> > * SRM deemed our patches too invasive. Thread starts at:
> >https://lists.debian.org/debian-dpkg/2014/04/msg00034.html
>
> I'm confused.
Control: reassign -1 tech-ctte
Dear technical committee,
I ask you to overrule the gcc maintainer and rule that the following
hunks to the gcc-4.9 package must be reverted:
diff -u gcc-4.9-4.9.1/debian/rules.defs gcc-4.9-4.9.1/debian/rules.defs
--- gcc-4.9-4.9.1/debian/rules.defs
+++ gcc-4.9-4.9
Hi Don,
Thanks for taking this up.
On Sun, Oct 26, 2014 at 02:59:13PM -0700, Don Armstrong wrote:
> Matthias: is the primary concern of including this patch one of
> maintenance burden, not primarily technical?
If you want Matthias to answer your question, I think that you may want
to Cc him, bu
On Mon, Oct 27, 2014 at 09:41:59PM +, Ian Jackson wrote:
> > The most obvious bug is the one mentioned in the patch: #760770
> > It is about a bug in the implementation of with_deps_on_target_arch (the
> > contended feature).
>
> I think I may not understand what's going on here. In your mail
Matthias contended that the default method to build a gcc cross compiler
works with multiarch:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766708#73
On Sun, Oct 26, 2014 at 03:50:59PM +0100, Helmut Grohne wrote:
> Why is with_deps_on_target_arch_pkgs needed?
>
> Without this
On Wed, Oct 29, 2014 at 09:35:52AM +, Dimitri John Ledkov wrote:
> The libc*-$arch-cross packages come from rebuilds of glibc package.
The major complaint being made here is that this process relies on
out-of-archive code, whereas the unsupported alternative
with_deps_on_target_arch_pkgs does
On Sat, Nov 01, 2014 at 01:46:48AM +, Wookey wrote:
> To me that sounds like this method is actually the
> current de-facto default in Debian - it is certainly at least on a par.
I don't think that a feature being de-facto default is a good argument
to force maintaining it forever. There clea
Hi Don,
On Wed, Nov 19, 2014 at 04:41:49PM -0800, Don Armstrong wrote:
> Are people who are doing cross-building like this actually using the
> code which will be in jessie? I (perhaps naïvely) would expect them to
> be primarily using the code in unstable, and maybe at a late stage of
> bring-up
On Sat, Nov 22, 2014 at 08:37:56PM +, Dimitri John Ledkov wrote:
> gcc:
> (wheezy) http://sources.debian.net/src/gcc-4.7/4.7.2-5/debian/README.cross/
> (jessie) http://sources.debian.net/src/gcc-4.8/4.8.3-13/debian/README.cross/
>
> Fundamentally the standard way to build cross-compilers from
1/. At least it makes more
sense with that negation removed. It may be a reaction to Wookey's cross
toolchain uploads, but it has undesired effects on others (e.g. me, Ron,
Sam). I do not want to deny that these uploads do have problems.
> In the meantime there is some progress from Adam C
On Tue, Oct 28, 2014 at 12:35:50AM +0100, Matthias Klose wrote:
> cross builds supporting multiarch exists and works. claiming otherwise is just
> populistic and/or marketing.
This claim and its counterclaim has been made repeatedly throughout the
discussion. It is long overdue to fill it with fac
I am wondering what the status of this bug is. It seems to me that
currently there are no viable option to choose from, because getting the
changes resulting from a decision into jessie seems to run counter the
freeze policy. Either a decision is made and implemented within less
than half a day or
On Thu, Dec 04, 2014 at 06:14:02PM +0100, Helmut Grohne wrote:
> After covering all of the above, the glibc/gcc dance can be completed,
> but the resulting compiler is not installable. It depends on libc6-amd64
> (:amd64), which is unsatisfiable because there only is a
> libc6-amd64:x
On Tue, Dec 16, 2014 at 04:11:00PM -0800, Don Armstrong wrote:
> forcemerge 771070 766708
> retitle 771070 Coordinate plan and requirements for cross toolchain packages
> in Debian
> thanks
>
> I believe that these two bugs now need to be discussed together, as the
> time for #766708 to be resolv
On Wed, Dec 17, 2014 at 07:42:02AM -0800, Don Armstrong wrote:
> OK. So your opinion is that this issue should be handled outside of the
> CTTE?
There are two aspects of #766708 that I asked for:
1) Reinstantiate the alternative method for jessie, because it was
tested extensively and many peop
On Wed, Dec 17, 2014 at 02:39:14PM -0800, Don Armstrong wrote:
> My question was not in regards to the issue of #766708 for jessie, but
> cross compilation going forwards.
>
> Do you want the CTTE involved with that or not?
Thanks for clarifying.
My interest in cross compilation does not cover t
On Wed, Jul 13, 2016 at 05:37:11PM +0100, Ansgar Burchardt wrote:
> On Wed, 2016-07-13 at 10:43 -0500, Don Armstrong wrote:
> > Or are you asking us to potentially overrule the ftpmasters inclusion
> > of libjs-handlebars? Or potentially overrule the release managers
> > determination of whether th
On Wed, Sep 15, 2021 at 01:36:26AM +0300, Adrian Bunk wrote:
> This is a request to override the maintainer of debianutils on several
> changes that were done to the package in unstable after the release of
> bullseye.
As someone being involved with debianutils lately (via DPKG_ROOT), I
feel the n
On Wed, Sep 15, 2021 at 12:41:31PM +0300, Adrian Bunk wrote:
> Are you arguing for a transition that makes "which" non-essential,
> or are you arguing for a transition that would remove "which" from
> Debian?
Irrespective of the technical arguments for keeping or removing which, I
think that with
Hi,
On Mon, Jan 31, 2022 at 10:11:19AM +, Matthew Vernon wrote:
> The two renames have substantially different CLI syntax, making them
> unsuitable for an alternatives arrangement
I think that much of the discussion has taken this point for granted,
but it is one of the aspects that the submi
Hi Chris,
On Mon, Jan 31, 2022 at 09:39:40PM +0100, Chris Hofstaedtler wrote:
> * Helmut Grohne [220131 17:09]:
> > > #966468 & #982944 asked for rename.ul to return (though the latter rather
> > > confuses the removal vs alternatives issue)
> >
> > I thin
On Sun, Jan 30, 2022 at 02:10:08PM -0700, Sean Whitton wrote:
> ===BEGIN
>
> A: Christoph Berg
> B: Helmut Grohne
> C: Elana Hashman
> D: Simon McVittie
> E: Niko Tyni
> F: Matthew Vernon
> G: Sean Whitton
> H: Gunnar Wolf
>
> ===END
I vote
G
Hi Chris,
On Sun, Jan 23, 2022 at 10:04:34PM +0100, Chris Hofstaedtler wrote:
> I was hoping we could put util-linux' rename into the
> "bsdextrautils" binary package, which has utilities like write, col,
> etc; to avoid putting it into an Essentials: yes package, and to
> avoid a new binary packa
Hi Ian,
On Tue, Mar 15, 2022 at 04:29:17PM +, Ian Jackson wrote:
> (Sorry for the resend, this should have gone to the BTS the first
> time; have fixed a slip in the wording.)
Thank you for resubmitting your issue as a bug report.
Beyond the content of your request, I have a meta-question. D
Hi Russ,
On Tue, Mar 15, 2022 at 09:22:09PM -0700, Russ Allbery wrote:
> > Specifically, I'd like to ask the TC to come up with policy on native
> > packages and debian revisions using its power under 6.1.1.
>
> As a Policy Editor, I support this request.
As a TC member I admit disliking this. W
Hi,
On Thu, Mar 24, 2022 at 09:12:14AM +0100, Ansgar wrote:
> Maybe it should be changed into a warning that non-merged-/usr systems
> will not be supported in the future. The `dpkg-fsys-usrunmess` program
> should probably also include a warning that it will convert the system
> into a state no
Hi Sean,
On Thu, Mar 24, 2022 at 09:31:21AM -0700, Sean Whitton wrote:
> We should distinguish two senses of "supported".
>
> There is the sense of what Debian-the-project supports. That is
> specified in the TC decision. That is not subjective.
This could be a language issue on my side. As I
On Fri, Mar 25, 2022 at 10:46:01AM +, Luca Boccassi wrote:
> Let me reverse the question: this stuff has been known and going on for
> what, 3 years? Why do _you_ think it is that nobody has stepped up to
> write a patch? In the same time lapse everybody involved has written
> mountains of code
Hi Chris,
On Mon, Mar 28, 2022 at 07:58:11PM +0200, Chris Hofstaedtler wrote:
> I would like to ask a question: under which constitution point will
> the CTTE act?
Given your reply, I believe that no 6.1.1-4 decision is necessary. The
views of the submitter seem sufficiently covered in what you d
Hi Luca,
On Mon, Mar 28, 2022 at 10:24:03PM +0100, Luca Boccassi wrote:
> Also worth noting that a couple of days ago, the author wrote on
> #debian-devel that some time ago the patch was presented to the dpkg
> maintainer, who rejected it with an answer along the lines of the usual
> "usrmerge is
Hi Luca,
On Tue, Mar 29, 2022 at 12:43:23PM +0100, Luca Boccassi wrote:
> Well, of course it's incomplete - if it is as it appears to be and the
> maintainer refuses to engage in any way, how can any reasonable
> progress be made? Especially in the fact of constantly shifting goal
> posts. First a
On Fri, Apr 08, 2022 at 09:39:30AM -0700, Josh Triplett wrote:
> It sounds like at least one patch has already been rejected, not with
> comments about the patch needing work (which it absolutely does), but AIUI
> with "usrmerge is broken by design". That seems like sufficient proof that
> the p
Hi Dom and Chris,
Chris proposes to transition /usr/bin/rename from the perl API to the
util-linux API.
On Thu, Apr 07, 2022 at 01:04:54PM +0200, Chris Hofstaedtler wrote:
> I see two clear options:
[...]
> B) Finish the very old migration. Have util-linux(-extra) ship
>/usr/bin/rename; per
Hi Dom and gregor,
On Sun, Apr 10, 2022 at 03:06:56PM +0100, Dominic Hargreaves wrote:
> +1 to all of this.
Thank you for your replies. They're not unexpected, but we (or at least
I) weren't entirely sure.
> Furthermore I'm troubled that this discussion rolled on for two months
> having dropped
Hi Chris,
On Thu, Apr 07, 2022 at 01:04:54PM +0200, Chris Hofstaedtler wrote:
> I see two clear options:
>
> A) Keep the status quo ("rename is not part of Debians util-linux").
>Very clear, very simple, no work.
This option is obviously incompatible with the request to restore
util-linux' r
Hi Matthew,
On Fri, Apr 15, 2022 at 08:54:16PM +0100, Matthew Vernon wrote:
> Thanks for the feedback on my previous draft; here's a revised ballot.
Thank you for moving this forward.
> ===Rationale
>
> There are two "rename" programs - the perl rename, and the util-linux
> rename. Debian and i
On Wed, Apr 20, 2022 at 03:31:13PM +0100, Matthew Vernon wrote:
> ===Begin Resolution A
> The Technical Committee overrides the util-linux maintainer, and requires
> that util-linux's rename should be shipped as /usr/bin/rename.ul in a binary
> package built from src:util-linux. The package contain
Hallo,
On Tue, May 10, 2022 at 05:29:57PM -0700, Sean Whitton wrote:
> DRAFT
>
> Using its powers under constitution 6.1.5, the Technical Committee
> issues the following advice:
I've given this some thought and feel uneasy about one item.
> 4. We believe that there are indeed circumstances i
Hi Sean,
On Mon, Jun 06, 2022 at 11:08:48PM -0700, Sean Whitton wrote:
> I think this argument needs to be made more precise -- we should be
> clearer about why this particular un-uniformity is bad. I don't think
> the issue for new contributors is persuasive enough, as new contributors
> can mos
Hi Sean,
On Tue, Jun 07, 2022 at 04:35:24PM -0700, Sean Whitton wrote:
> I disagree with you that this is primarily about package ownership, and
> I think that we agree on more than you realise we do :)
Hmm. It's not that obvious. While it would be possible to remove the
choice of workflow from s
Hi,
On Tue, Jun 07, 2022 at 10:31:18PM -0700, Sean Whitton wrote:
> Here's an updated ballot in light of our upcoming meeting. I've left
> space to add a 4b, if, when our current discussion is concluded, someone
> would like that in addition to 4c.
After the meeting, Simon, Sean and myself furt
Hi,
On Wed, Jun 15, 2022 at 04:06:55PM +0200, Lucas Nussbaum wrote:
> If you look at Debian 'testing' only, I think that the only remaining
> way to do that is 1.0 + quilt (packages that were using dpatch have all
> been converted or removed from testing).
That's good. I wasn't able to locate a c
On Mon, Jun 20, 2022 at 05:31:16PM -0700, Sean Whitton wrote:
> BEGIN BALLOT
>
> Using its powers under constitution 6.1.5, the Technical Committee
> issues the following advice:
>
> 1. It is not a bug of any severity for a package with a non-native
> version number to use a native source
Hi Luca,
Thank you for providing such a detailed and well-rationalized plan for
moving forward. It removes quite an amount of uncertainty about where
we're heading. I've missed this kind of clarity in previous
conversations.
On Sun, Jul 17, 2022 at 12:56:14AM +0100, Luca Boccassi wrote:
> A MR is
Hi Sam and Steve,
On Sun, Jan 23, 2022 at 02:22:53PM +0100, Helmut Grohne wrote:
> In any case, as long as we are actively discussing the technical means,
> we have no intention to push for a rapid inclusion. To the contrary:
> Please wait with applying the proposed changes as lo
Control: clone -1 -2
Control: retitle -2 decide whether pam should support DPKG_ROOT
Control: tags -2 =
Control: reassign -2 tech-ctte
Hi technical comittee members,
On Thu, Aug 18, 2022 at 03:44:54PM +0200, Helmut Grohne wrote:
> Within three weeks I want Steve to reply to this bug in a
Hi,
On Sat, Sep 10, 2022 at 11:57:48PM +0200, Johannes Schauer Marin Rodrigues
wrote:
> From my side, I'd be fine with the TC pausing any action on this issue and
> waiting for our mail to d-devel first. This is assuming that if there is no
> opposition to the DPKG_ROOT idea, that Steve then also
Hi Luca,
As much as I agree with you on other matters...
On Tue, Sep 27, 2022 at 09:11:18PM +0100, Luca Boccassi wrote:
> baseless, patently false statements - I frankly find it quite upsetting
> to see claimed that "we have refused to fix any bug" as a self-evident
> fact, when even a cursory lo
Hi Zack,
On Wed, Sep 28, 2022 at 12:29:19PM -0400, Zack Weinberg wrote:
> I thought about this a bunch yesterday evening and I believe I see a
> concrete scenario that can cause problems but is not covered by the
> moratorium: Suppose there exist two packages, one of which ships
> /bin/foo, and th
Hi Steve,
On Wed, Oct 05, 2022 at 04:41:02PM -0700, Steve Langasek wrote:
> No need to wait on the TC at all; your post and the subsequent discussion on
> debian-devel (and -policy) addresses my concerns, thank you. At this point
> committing and uploading is blocked only on me having the time to
On Fri, Nov 25, 2022 at 03:39:12PM -0700, Sean Whitton wrote:
> ===BEGIN
> The Technical Committee recommends that Matthew Garrett be
> appointed by the Debian Project Leader to the Technical Committee.
>
> H: Recommend to Appoint Matthew Garrett
> F: Further Discussion
> ===END
I vote H > F.
Hi Matthew,
On Sat, Jan 07, 2023 at 05:06:50PM +, Matthew Vernon wrote:
> Sandro, would you be opposed to relaxing the Depends: to a Recommends: ? If
> you would be opposed, would you mind briefly explaining why, please?
I think this question was already posed by Simon McVittie and Sandro's
a
Hi Joachim,
On Sat, Jan 07, 2023 at 09:50:28PM +0100, Joachim Wuttke wrote:
> Would it make sense to submit an issue against dh-python?
I think that dh-python - in general - does the right thing here. It
looks at #! lines and adds the appropriate dependencies. If you want to
make a dent on python
Constitution, the vote runs until all members have voted,
> or until my resignation takes effect.
Thank you Sean!
> I would like to continue in the role, if the committee agrees.
>
> The ballot:
>
> ===BEGIN
>
> A: Christoph Berg
> B: Matthew Garrett
> C: Helmut
Hi fellow committee members,
can we put the /usr-merge back to our agenda for one of the next
meetings?
For one thing, there is DEP17 being discussed (see
https://lists.debian.org/debian-dpkg/2023/04/msg0.html). For
another, we probably need to clarify whether the file move moratorium
extends
Hi Matthew,
On Tue, Apr 25, 2023 at 02:39:02PM +0100, Matthew Vernon wrote:
> Today is our slightly delayed monthly meeting, at 18:00 UTC. The March
> meeting didn't happen, so this is our first meeting since February.
Thank you for volunteering as chair.
> I've not seen any recruitment updates,
On Tue, May 09, 2023 at 01:26:10PM -0700, Sean Whitton wrote:
> I call for votes on the following resolution.
> Voting lasts for one week or until the outcome is no longer in doubt.
> Let me take this opportunity to thank Helmut for all his recent work on
> this topic.
>
> === BEGIN
>
> OPTION A:
Hi Ansgar,
I'm speaking with a CTTE hat here, but not representing CTTE consensus.
On Wed, May 10, 2023 at 11:47:42PM +0200, Ansgar wrote:
> Dear ctte, please consider overruling the dpkg maintainer to include
> the patch from #994388[1].
I think we need to reject this request on multiple levels
On Wed, Jun 14, 2023 at 10:03:19AM +0100, Sean Whitton wrote:
> ===BEGIN
> The Technical Committee recommends that Stefano Rivera be
> appointed by the Debian Project Leader to the Technical Committee.
>
> R: Recommend to appoint Stefano Rivera
> F: Further discussion
> ===END
I vote R > F.
H
On Wed, Jun 14, 2023 at 10:04:54AM +0100, Sean Whitton wrote:
> ===BEGIN
> The Technical Committee recommends that Timo Röhling be
> appointed by the Debian Project Leader to the Technical Committee.
>
> R: Recommend to appoint Timo Röhling
> F: Further discussion
> ===END
I vote R > F.
Helmut
Hi Sean,
On Mon, Jul 03, 2023 at 05:55:12PM +0100, Sean Whitton wrote:
> I would like to continue in the role, if the committee agrees.
Thanks for your work as chair.
> The ballot:
>
> ===BEGIN
>
> A: Christoph Berg
> B: Matthew Garrett
> C: Helmut Grohne
> D: S
On Fri, Jul 07, 2023 at 11:11:08AM +0100, Sean Whitton wrote:
> - Updates on merged-/usr
> -- if, Helmut, you think this would be useful this month?
Let me summarize what has happened. The rewrite of DEP17 has seen wider
circulation and little feedback. It seems to me that we have consensus
on f
Hi Ian,
While I have a CTTE hat, this response should be considered a
Freexian/personal response rather than an official CTTE response.
On Fri, Aug 18, 2023 at 07:57:14AM +0100, Ian Jackson wrote:
> Thanks to work funded by Freexian we now have a list of many of these
> malfunctions[2] (although
Hi Ian,
On Wed, Aug 23, 2023 at 05:04:36PM +0100, Ian Jackson wrote:
> Desired end state
> =
>
> This is a very good question. I had a very constructive conversation
> with Helmut via video chat. It seems that there's a misunderstanding
> about the desired end state.
I concur.
Hi,
after bookworm, we extended the moratorium, because we saw that lifting
it would cause problems. We have a better understanding of those
problems now and are into preparations for actually moving files. I'd
like to initiate a discussion on how the moratorium is to be lifted.
DEP17 tells us ab
Hi Timo,
On Sat, Aug 26, 2023 at 01:32:25AM +0200, Timo Röhling wrote:
> Practically, lifting the moratorium means that the CTTE relinquishes
> control of the /usr-merge transition to whoever drives the
> transition, i.e., maintains that living document and thereby makes
> decisions on how to proc
Hi Ian,
On Sat, Aug 26, 2023 at 11:24:33AM +0100, Ian Jackson wrote:
> Helmut Grohne writes ("Bug#1050001: Unwinding directory aliasing"):
> > On Wed, Aug 23, 2023 at 05:04:36PM +0100, Ian Jackson wrote:
> > > And, the approach being taken very seriously privileges De
Hi Luca,
At least three DDs have asked you to stop. Why do you continue?
In all of your mails to this bug, I've seen little attempt at trying to
understand other participants. In a project as large as Debian, it is to
be expected that disagreement arises. That's not the end of the world,
but it i
Hello Jonathan,
On Fri, Sep 22, 2023 at 09:50:51AM -0400, Jonathan Kamens wrote:
> The current python3-selenium package does not include all of the
> components that the vendor expects to be included in the package, and
> as a result it does not work. This is a regression from previous
> versions
onding locations under
> /usr in the data.tar.* of packages.
>
> The transition driver, which at the time of writing is Helmut Grohne, is
> using a phased approach, in which the moratorium is rolled back for only
> certain classes of packages, and changes, at a time. In addition,
> re
Hi,
this installment serves a dual purpose. Let me first give an update of
the status quo and then pose a consensus question on how we want to deal
with a particular problem.
I Cc d-release@l.d.o as upgrades are an integral part of releases.
I Cc d-ctte@l.d.o for advisory feedback with experience
Hi Matthew,
On Thu, Dec 21, 2023 at 02:42:56PM +, Matthew Vernon wrote:
> On 21/12/2023 09:41, Helmut Grohne wrote:
>
> > Is it ok to call upgrade scenarios failures that cannot be reproduced
> > using apt unsupported until we no longer deal with aliasing?
Let me thank Da
Thanks for the feedback. Given the replies, I consider that most people
expect upgrades to be performed with apt (or some apt-using tool).
Upgrades using dpkg (directly) are at least partially unsupported. In
more detail:
On Thu, Dec 21, 2023 at 10:41:57AM +0100, Helmut Grohne wrote:
> ## Opti
On Wed, Jan 03, 2024 at 08:07:53PM +0100, Wouter Verhelst wrote:
> Presumably the reason for this requirement in policy is that without it,
> debootstrap cannot function. That is, debootstrap first unpacks all
> Essential packages, without running any preinst or postinst scripts, and
> *then* runs
Package: tech-ctte
Given our discussion at the last CTTE meeting, I am turning my request
for advice into a formal one.
Most of the /usr-move that is happening via DEP17 seems to be working
out, but the effects of Conflicts raise the question of what kinds of
interactions with a package manager a
On Fri, Jan 12, 2024 at 01:31:18PM +0100, Helmut Grohne wrote:
> The relevant situation is not entirely trivial to construct:
>
> * Package $first contains an aliased file $file and this is moved to
>package $second in an update.
>OR
>Package $first diverts alia
Hi Sam,
On Wed, Jan 17, 2024 at 09:33:25AM -0700, Sam Hartman wrote:
> I'd really like to understand why this is desired dpkg behavior.
I fear I have to defer to Guillem on this one. My rough understanding is
that we can minimize the window of time during which the files are
missing. Though given
On Mon, Feb 19, 2024 at 09:53:20AM +, Matthew Vernon wrote:
> On 12/01/2024 12:31, Helmut Grohne wrote:
>
> > For the gzip case, we have the additional question whether we tolerate
> > the temporary policy violation for the trixie upgrade or halt the
> > /usr-move a
On Mon, Feb 19, 2024 at 09:48:00AM +, Matthew Vernon wrote:
> To check I have understood correctly: one may see loss of files when doing
> dpkg -i of a package where it Conflicts: with an installed package?
Unfortunately, this is real.
apt avoids this, because it recognizes that it can remove
Hi Simon,
On Fri, Mar 01, 2024 at 11:50:22AM +, Simon McVittie wrote:
> Background
> ==
Thank you for explaining the details so clearly.
> - for giomodule.cache (per-architecture), the file is simply deleted by
> postrm remove
For this one (but not gschemas.compiled), I am wonderi
On Sun, Mar 10, 2024 at 10:06:42AM +0800, Sean Whitton wrote:
> ===BEGIN
> The Technical Committee recommends that Craig Small be
> appointed by the Debian Project Leader to the Technical Committee.
>
> C: Recommend to Appoint Craig Small
> F: Further Discussion
> ===END
I vote C > F.
Helmut
Hi Bastian and Matthias,
I was recently working on gcc builds and this disagreement currently
makes stuff unbuildable. Hence I looked into solutions and/or
workarounds.
On Tue, Mar 05, 2024 at 09:50:27AM +0100, Helmut Grohne wrote:
> > You just said that the search path used during the bu
Hi Bastian,
On Wed, Mar 06, 2024 at 07:52:09AM +0100, Bastian Blank wrote:
> On Tue, Mar 05, 2024 at 09:50:27AM +0100, Helmut Grohne wrote:
> > The problem arises in the reverse sense. If a file does not exist in
> > one, it is searched in the second and erroneously may be
> A: Christoph Berg
> B: Matthew Garrett
> C: Helmut Grohne
> D: Stefano Rivera
> E: Timo Röhling
> F: Craig Small
> G: Matthew Vernon
> H: Sean Whitton
>
> ===END
I vote:
H > ABG > CDE > F
In this case, I want to give a rationale.
While Sean&#x
On Tue, Apr 30, 2024 at 11:09:26AM +0100, Matthew Vernon wrote:
> > ===BEGIN
> >
> > A: Christoph Berg
> > B: Matthew Garrett
> > C: Helmut Grohne
> > D: Stefano Rivera
> > E: Timo Röhling
> > F: Craig Small
> > G: Matthew Vernon
>
1 - 100 of 103 matches
Mail list logo
