Bug#727708: tech-ctte: Decide which init system to default to in Debian.

2013-10-29 Thread Helmut Grohne
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

Bug#727708: tech-ctte: Decide which init system to default to in Debian.

2013-10-30 Thread Helmut Grohne
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

Bug#727708: systemd socket activation protocol rationale

2013-12-15 Thread Helmut Grohne
. 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

Bug#744246: ftp.debian.org: update python-apt to support build-profiles

2014-07-17 Thread Helmut Grohne
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

Re: Bug#766708: breaks multiarch cross building

2014-10-26 Thread Helmut Grohne
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 +++

Bug#766708: Processed: Re: Bug#766708: breaks multiarch cross building

2014-10-27 Thread Helmut Grohne
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

Bug#766708: Processed: Re: Bug#766708: breaks multiarch cross building

2014-10-28 Thread Helmut Grohne
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

Bug#766708: Request to override gcc maintainer changes breaking unsupported way of cross-building

2014-10-29 Thread Helmut Grohne
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

Bug#766708: Request to override gcc maintainer changes breaking unsupported way of cross-building

2014-10-30 Thread Helmut Grohne
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

Bug#766708: Processed: Re: Bug#766708: breaks multiarch cross building

2014-11-01 Thread Helmut Grohne
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

Bug#766708: Processed: Re: Bug#766708: breaks multiarch cross building

2014-11-19 Thread Helmut Grohne
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

Bug#766708: Processed: Re: Bug#766708: breaks multiarch cross building

2014-11-24 Thread Helmut Grohne
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

Bug#766708: supported GCC based cross compilers in Debian

2014-11-26 Thread Helmut Grohne
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

Bug#766708: experience report on the default method

2014-12-04 Thread Helmut Grohne
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

Bug#766708: status of cross gcc/jessie?

2014-12-04 Thread Helmut Grohne
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

Bug#766708: experience report on the default method

2014-12-05 Thread Helmut Grohne
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

Bug#766708: Coordinating a plan and requirements for cross toolchain packages in Debian

2014-12-16 Thread Helmut Grohne
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

Bug#766708: Coordinating a plan and requirements for cross toolchain packages in Debian

2014-12-17 Thread Helmut Grohne
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

Bug#766708: Coordinating a plan and requirements for cross toolchain packages in Debian

2014-12-17 Thread Helmut Grohne
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

Bug#830978: Browserified javascript and DFSG 2

2016-07-19 Thread Helmut Grohne
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

Bug#994275: Reverting breaking changes in debianutils

2021-09-15 Thread Helmut Grohne
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

Bug#994275: Reverting breaking changes in debianutils

2021-09-15 Thread Helmut Grohne
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

Bug#1007717: Native source package format with non-native version

2022-03-17 Thread Helmut Grohne
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.

Bug#1007717: Native source package format with non-native version

2022-03-15 Thread Helmut Grohne
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.

Bug#994388: dpkg currently warning about merged-usr systems

2022-03-25 Thread Helmut Grohne
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

Bug#994388: dpkg currently warning about merged-usr systems

2022-03-24 Thread Helmut Grohne
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

Bug#994388: dpkg currently warning about merged-usr systems

2022-03-24 Thread Helmut Grohne
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

Bug#994388: dpkg currently warning about merged-usr systems

2022-04-03 Thread Helmut Grohne
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

Bug#1003653: Revision of removal of rename.ul from package util-linux

2022-03-28 Thread Helmut Grohne
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

Bug#994388: dpkg currently warning about merged-usr systems

2022-03-29 Thread Helmut Grohne
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

Bug#1003653: Revision of removal of rename.ul from package util-linux

2022-01-31 Thread Helmut Grohne
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

Bug#1003653: Revision of removal of rename.ul from package util-linux

2022-01-31 Thread Helmut Grohne
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

Bug#1004611: Resignation & call for votes to elect the Chair

2022-02-01 Thread Helmut Grohne
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

Bug#1003653: Revision of removal of rename.ul from package util-linux

2022-02-08 Thread Helmut Grohne
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

Bug#994388: dpkg currently warning about merged-usr systems

2022-04-08 Thread Helmut Grohne
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

Bug#1003653: Revision of removal of rename.ul from package util-linux

2022-04-09 Thread Helmut Grohne
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;

Bug#1003653: Revision of removal of rename.ul from package util-linux

2022-04-16 Thread Helmut Grohne
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

Bug#1003653: Revision of removal of rename.ul from package util-linux

2022-04-20 Thread Helmut Grohne
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

Bug#1003653: Revision of removal of rename.ul from package util-linux

2022-04-10 Thread Helmut Grohne
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

Bug#1003653: Revision of removal of rename.ul from package util-linux

2022-04-10 Thread Helmut Grohne
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'

Bug#1007717: Ballot and call for votes

2022-06-23 Thread Helmut Grohne
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

Bug#1007717: Draft resolution for "Native source package format with non-native version"

2022-06-08 Thread Helmut Grohne
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

Bug#1007717: Draft resolution for "Native source package format with non-native version"

2022-06-06 Thread Helmut Grohne
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

Bug#1007717: Updated draft resolution

2022-06-16 Thread Helmut Grohne
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

Bug#1007717: Updated draft resolution

2022-06-14 Thread Helmut Grohne
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

Bug#1007717: Draft resolution for "Native source package format with non-native version"

2022-06-07 Thread Helmut Grohne
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

Re: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

2022-07-18 Thread Helmut Grohne
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

Re: Bug#993161: pam: some remaining changes for DPKG_ROOT

2022-08-18 Thread Helmut Grohne
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

Re: Bug#993161: pam: some remaining changes for DPKG_ROOT

2022-09-08 Thread Helmut Grohne
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

Bug#1019409: Bug#993161: pam: some remaining changes for DPKG_ROOT

2022-09-18 Thread Helmut Grohne
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

Re: Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed

2022-09-28 Thread Helmut Grohne
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

Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed

2022-09-28 Thread Helmut Grohne
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