ere build-conflicts can't be used
> anyway) and cross the same.
I don't understand what you are trying to say here. c-t-b only builds
Arch:all packages, so the terms native and cross appear to not apply.
Then again we also don't know what "further problems" are. I hope
Matthias can shed
Hi,
In this mail, I'll try to summarize my state of knowledge on this
matter while noting that I don't see the full picture.
On Fri, Mar 29, 2024 at 11:17:55AM +0100, Bastian Blank wrote:
> On Thu, Mar 21, 2024 at 08:48:01PM +0100, Helmut Grohne wrote:
> > I was recently working on g
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
>
> 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's
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
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
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 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
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
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
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
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
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
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
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
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
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
corresponding 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
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
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
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 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
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
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 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
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
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 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.
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.
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
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
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
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
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 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
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
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 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
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
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
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
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 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 change
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
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,
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
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
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
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
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
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
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
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'
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 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;
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
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
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
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
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
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
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 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.
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.
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
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 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 t
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
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
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
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
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
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 the
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 resolved
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:x32. It seems
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
do have problems.
In the meantime there is some progress from Adam Conrad, Dimitri
Ledkov and my side on the cross-toolchain-base package. Both Wookey
and Helmut Grohne were CCed on these efforts but they choose to stay
quiet.
My reasons for not participating in the cross-toolchain-base package
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
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 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
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
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 flag, gcc emits
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 to
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, but
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
+++
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.
The only message from anyone
.
Helmut Grohne has done some work in that direction², speaking to the
relevant people at DebConf 13 in person. I am not entirely sure about
the current status of these efforts, maybe Helmut can comment
See http://bugs.debian.org/732179. (Afaik you cannot create a new bug
and CC another
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
consideration
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
Helmut Grohne (Cced) did most of the work on analyzing those possibilities
89 matches
Mail list logo
