Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition

> "Matthew" == Matthew Garrett writes: Matthew> I agree with the conclusions drawn here, but feel that it's Matthew> possibly worth making a stronger general statement that Matthew> policy should never prevent the implementation of a Matthew> well-considered simple solution.

Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition

Are there solutions in the space of having glib2.0-0 continue to exist as a package depended on by glib2.0-0t64 or depending on the new library allowing you to replace the postrm? That might create a space in time where glib2.0-0.so does not exist, but we probably have more flexibility there

Bug#1060700: Requesting advice regarding the impact of problems caused by aliasing on declared Conflicts

> "Matthew" == Matthew Vernon writes: Matthew> This continues to make me worry we are not on the path of Matthew> robust engineering. But I appreciate I'm in a very small Matthew> minority in that regard. I want to second the above. I do still believe that the way forward is

Bug#1060700: Requesting advice regarding the impact of problems caused by aliasing on declared Conflicts

> "Helmut" == Helmut Grohne writes: Helmut> Package: tech-ctte Given our discussion at the last CTTE Helmut> meeting, I am turning my request for advice into a formal Helmut> one. Helmut> Most of the /usr-move that is happening via DEP17 seems to Helmut> be working out,

Bug#1050001: Unwinding directory aliasing [and 3 more messages]

TL;DR: I think I understand one of Ian's points. I explain, but do not believe it is compelling as an argument to switch direction. > "Helmut" == Helmut Grohne writes: >> I think "package management" is the wrong term here. It's not >> just our tools and packages that are

Bug#1050001: Unwinding directory aliasing

> "Ansgar" == Ansgar writes: Ansgar> And the more important question: how often do we want to Ansgar> rehash the usrmerge discussion? At some point we should Ansgar> stick with a decision and not endlessly restart discussions Ansgar> (unless something really significant

Re: Bug#1050001: Unwinding directory aliasing

> "Adam" == Adam Borowski writes: Adam>all Adam> files from /lib /bin (that are not required interface, such as Adam> /bin/sh -- which can be symlinked) are moved within a week Adam> from the first upload. Rather than taking two+ Debian Adam> releases! This is an area where

Re: Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?

> "Luca" == Luca Boccassi writes: >> I suspect the reason you want to make this MBF is that you >> believe it Luca> will somehow make the transition easier if there are fewer Luca> files in /bin or /usr/bin. Luca> IE, you immediately escalated it with aggressiveness

Re: Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?

;> "Luca" == Luca Boccassi writes: Luca> So what you are worried is the combination of a testing Luca> installation from~one year ago, that is otherwise never Luca> touched for say another year, and also that has one of those Luca> 23 packages installed in the old version, and

Re: Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?

>>>>> "Luca" == Luca Boccassi writes: Luca> On Mon, 22 May 2023 at 20:22, Sam Hartman wrote: >> >> >>>>> "Luca" == Luca Boccassi writes: >> Luca> Hello Release Team, If we were to do a MBF again

Re: Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?

> "Luca" == Luca Boccassi writes: Luca> Hello Release Team, If we were to do a MBF against packages Luca> that in _Bookworm_ have introduced new files in /bin, /sbin or Luca> /lib*, would you accept the consequent mass unblock request? Luca> I am asking beforehand as there's

Bug#1035904: What does merged /usr bring us

>>>>> "Sam" == Sam Hartman writes: Sam> Hi. Off list, I wanted to try to explain what I think merged My apology for sending a mail intended to be private to the bug. It was not my intent to clutter an already cluttered discussion. I was really just

Bug#1035904: What does merged /usr bring us

Hi. Off list, I wanted to try to explain what I think merged /usr has brought us that is positive. I want to stress that I'm not a huge fan of merged /usr, and I know you've encouraged me not to argue from a devil's advocate position in the past. All the things I cite here are things I actually

Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

> "Matthew" == Matthew Vernon writes: Matthew> On 15/05/2023 16:54, Bdale Garbee wrote: >> I could. >> >> Can you provide an example of actual value delivered to Debian >> from merged-/usr? Matthew> With respect, I don't think this line of argument is going

Re: DEP17 feedback

> "Helmut" == Helmut Grohne writes: Helmut> another, we probably need to clarify whether the file move Helmut> moratorium extends to trixie. I think Matthew Garrett Helmut> already looked into it and wanted to followup but never did Helmut> and I'd also appreciate Simon

Bug#1020923: tech-ctte: please clarify if atomic updates are required

> "Sean" == Sean Whitton writes: >> >> * Who is expected to drive further discussion: the maintainer or >> the bug submitter I guess I don't really see how the above is broad. But let me try and narrow it. Is the maintainer expected to find a forum and try to build consensus on

Bug#1020923: tech-ctte: please clarify if atomic updates are required

> "Russ" == Russ Allbery writes: Russ> Unfortunately, with this current set of bugs, it seems Russ> unlikely that we're going to manage to make everyone happy in Russ> the short term, which means there's going to be a tense period Russ> where some folks feel strongly that

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

> "Sean" == Sean Whitton writes: Sean> - you might be lacking the full context of TC-involving Sean> discussions over the past few months, but so far as I can see, Sean> you are asking for us to undo a decision that we only just Sean> made, which doesn't make sense. Sean, as

Re: Is a different opinion about a license a case for the ctte?

[I accidentally sent this as a private reply earlier this morning before Phil's message.] TL;DR: you don't have any recourse that is appropriate for this situation. All the hammers are bigger than your nail. > "Andreas" == Andreas Tille writes: Andreas> Hi folks, before I

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

> "Josh" == Josh Triplett writes: Josh> Over the years, I've seen a few proposals floated to consider Josh> dropping /etc/shells; this would just require dropping Josh> pam_shells.so from /etc/pam.d/chsh. That would also have the Josh> side effect of solving this problem, and

Re: tech-ctte: more on merged-/usr

> "Matthew" == Matthew Vernon writes: Matthew> While it's understandable, I am saddened and a bit worried Matthew> by the "it's too much hassle to fix dpkg's usr-merge Matthew> support, let's not bother" message I seem to be getting Matthew> from these threads. I agree with

Bug#1007717: Updated draft resolution

> "Helmut" == Helmut Grohne writes: Helmut> Indeed, and I do agree that 4c is such a clear statement. I Helmut> would like to see a stronger statement here, but Sam et Helmut> al. tried to gain consensus on that and there wasn't. So the Helmut> CTTE advice probably shouldn't

Bug#1007717: attempt to summarize current state of this bug

> "Matthew" == Matthew Vernon writes: Matthew> Hi, I thought it might be useful to try and summarize where Matthew> we are with this bug, which hasn't see much recent activity Matthew> (not least as there's a TC meeting later...). I read your summary and agree it is accurate.

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

> "Russ" == Russ Allbery writes: Russ> Switching terminology to completely leave behind the terms Russ> with ambiguous meanings isn't a bad idea, but if so we really Russ> need a term that captures "is a packaging of an upstream Russ> software package with a separate

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

> "Helmut" == Helmut Grohne writes: Helmut> Hi Russ, Helmut> 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. >>

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

Dear TC, I cannot speak for what Ian wants, but I would also like to formally ask the TC to rule on this issue. My hope is that what Ian and I are asking for is similar enough that the TC can consider the issues together. Specifically, I'd like to ask the TC to come up with policy on native

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

> "Ian" == Ian Jackson writes: Ian> 3. Consequently, declare that the recent MBF on this topic Ian> ought not to have been filed against packages where simply Ian> changing the source format does not currently work. That would Ian> include at least 1.0 native packages with

Re: New semi-formal ctte role: TC facilitators

> "Sean" == Sean Whitton writes: Sean> As with any TC related activity, assigned facilitators may Sean> find themselves in conflict of interest in a given Sean> disagreement. We trust members of the TC to recognize such Sean> problems and, if it becomes necessary, recuse

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

>On merged-/usr systems, there is a possible failure mode involving files >being moved between packages (with Replaces) during the same release >cycle that their logical location is changed from the root filesystem >to the corresponding aliased directory in /usr, which can result in >the

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

> "Simon" == Simon McVittie writes: Simon> Package: tech-ctte Severity: normal Simon> As discussed in our last meeting, I think we should issue Simon> more specific advice about merged-/usr, and in particular Simon> about what #978636 means for maintainers right now. I

Bug#976462: tech-ctte: Should dbgsym files be compressed via objcopy --compress-debug-section or not?

Hi. Thanks for your reply. The links to bugs you included add much needed detail to this discussion. > "Matthias" == Matthias Klose writes: Matthias> as pre-processing. So we know since about three years Matthias> that dwz doesn't support compressed debug symbols. Your

Bug#976462: tech-ctte: Should dbgsym files be compressed via objcopy --compress-debug-section or not?

> "Matthias" == Matthias Klose writes: Matthias> Maybe you should be more specific about "those who can't Matthias> use" uncompressed debug info in the first place. So, you've argued that the disk savings are not significant inside a package, because packages are themselves

Bug#976462: Bug#631985: Compress debug

> "Sean" == Sean Whitton writes: Sean> Hello, Sean> So, just to confirm, you're saying that you think that you or Sean> people you know would end up doing the latter pretty regularly Sean> if we were to decide to turn off compression? I know for larger packages I'd be likely

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

General arguments about how the TC should conduct its business do not belong on this bug. I'd appreciate it if replies to this message are directed to a different place than this bug. We've established that the TC is operating consistently both with its historical process and with currently

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

> "Russ" == Russ Allbery writes: >> I have not come to the TC to ask them to overrule the maintainer >> frivolously nor before exploring as many other options as I >> could. Russ> I understand (oh, boy, do I ever) how strained relationships Russ> are after the

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

> "Russ" == Russ Allbery writes: Russ> We do drop features all the time between stable releases, Russ> though, and generally that too is at the maintainer's Russ> discretion. The package maintainer's normal obligation in Russ> Debian isn't to keep everything working that

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

> "Russ" == Russ Allbery writes: Russ> I think this clearly and unambiguously says that maintainers Russ> can depend on unit support and drop init scripts from their Russ> packages if they so choose, and that this choice only requires Russ> as much justification as rejecting

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

>>>>> "Wouter" == Wouter Verhelst writes: Wouter> On Wed, Dec 16, 2020 at 10:28:55AM -0500, Sam Hartman wrote: >> I think that we should either decide that >> >> 1) NetworkManager should support elogind >> >> or

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

>>>>> "Matthew" == Matthew Vernon writes: Matthew> On 15/12/2020 22:07, Sam Hartman wrote: >>> However, Debian remains an environment where developers and >>> users can explore and develop alternate init systems and >>&

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

I had a great discussion with Mark Hindley about this issue a few months ago. I'd like to summarize what I said in that discussion as input to the TC. But I'd also like to start out by reminding us all what we said in the GR text that we agreed to. As one of the contributors to that text, you

Re: Proposal: Make it Easier to Refine TC Process

> "David" == David Bremner writes: David> For what it's worth, I'm not keen on further centralization David> of powers in the DPL. I understand that others (e.g. Sam) David> might see this a reasonable tradeoff for the ability to more David> easily update the role and powers

Proposal: Make it Easier to Refine TC Process

I think the summary of problems facing the TC is really good and a great starting point for discussion. In another message I proposed one additional problem, but regardless of whether the TC agrees with that, you've given a good starting point. My biggest take away from the set of problems and

Problem: Ineffective at Choosing a Maintainer

Dear Technical Committee: I'd like to ask you to consider an additional problem with the current TC structure that I don't think was called out clearly enough in your mail to debian-devel-announce. Currently, the TC is the only body that can change who is the maintainer of a package.

Considering Presenting a Talk on Alternate Structures for the TC--How to Do So Constructively

Dear Marga: I've been refining and thinking about the comments I made to you at/after the TC BOF last year about alternate ways to think about the functions now performed by the TC. I've reached a point where I think I could put together a concrete proposal as a starting point for discussion

Re: Fwd: Bug#931965: New Debian package squashfs-tools-ng_0.4.2

It looks like the maintainer has uploaded a new version presumably with the readme corrected which is also available in new. In particular, there appears to be a version based on 0.5, which I believe has the upstream readme change included. I cannot see for sure until the package is approved by

Re: That merged-usr is mandatory is RC

> "Ivo" == Ivo De Decker writes: Ivo> Hi, Given that there is still discussion about the impact of Ivo> merged /usr at this very late point of the freeze, I think Ivo> having merged /usr by default for new installations should be Ivo> reconsidered. What discussion are you

Re: Thinking about Delegating Decisions about Policy

>>>>> "Sean" == Sean Whitton writes: Sean> Hello Sam, Sean> On Fri 10 May 2019 at 03:57PM -04, Sam Hartman wrote: >> What are people's thoughts about this? >> >> Will this approach work for the TC and policy editors?

Re: Managing Frozen text when the TC Decides Policy

>>>>> "Sean" == Sean Whitton writes: Sean> Hello Sam, Sean> On Sat 11 May 2019 at 01:24PM -04, Sam Hartman wrote: >> I agree that it would generally be unfortunate if we had policy >> text that could not be changed by the policy proce

Re: That merged-usr is mandatory is RC

> "Ian" == Ian Jackson writes: Ian> (sending this because I got the release team address wrong) Ian Ian> Jackson writes ("That merged-usr is mandatory is RC"): >> Control: severity -1 serious >> >> In #923091, Guillem (with dpkg maintainer hat on) asks for a >>

Managing Frozen text when the TC Decides Policy

I'm not really sure that the point you bring up is all that related to the question I was asking. But I think the point you bring up is important and I hope relatively easy to solve, so let's discuss it and try to solve it. > "Bill" == Bill Allombert writes: Bill> In my view it is

Thinking about Delegating Decisions about Policy

In my platform, one of the things I focused on is trying to drive the decision process forward. I imagine it won't be uncommon to get to a point where the right next step is to develop technical or non-technical policy about something. I'd like to focus in this message about what I as DPL do

Bug#904302: Whether vendor-specific patch series should be permitted in the archive [and 1 more messages]

> "Wouter" == Wouter Verhelst writes: Wouter> But in the general case, I feel that downstream packaging Wouter> changes belong downstream, not in Debian; therefore it is Wouter> best to recommend that, in the general case, packages in Wouter> Debian do not switch on

Bug#904558: What should happen when maintscripts fail to restart a service

> "Ian" == Ian Jackson writes: Ian> * If the maintainer has no particular reason to diverge the Ian> right answer is usually to fail the postinst with init systems Ian> that do not provide service supervision; but to not fail the Ian> postinst with ones that do. (I think

Bug#904302: Whether vendor-specific patch series should be permitted in the archive [and 1 more messages]

>>>>> "Wouter" == Wouter Verhelst writes: Wouter> On Fri, Oct 05, 2018 at 08:40:03AM -0400, Sam Hartman wrote: >> That said, even there there are tradeoffs. As an example, Ubuntu >> tries to use unmodified Debian source packages wher

Bug#904558: What should happen when maintscripts fail to restart a service

> "Simon" == Simon McVittie writes: Simon> the error path is most important were packages that provide a Simon> system-level API to other packages, so their failures are Simon> likely to cause other packages to fail to configure (such as Simon> local DNS caches and

Bug#904302: Whether vendor-specific patch series should be permitted in the archive [and 1 more messages]

Actually directly switching on vendor seems fairly bad. However, to the extent that downstream changes can be encapsulated into options/deltas that someone might want, I think it may often be reasonable to carry the delta in Debian. So imagine that Ubuntu and several other downstreams care more

Resignation from the Debian Technical Committee Effective Immediately

When I joined the technical committee, I asked the TC to carefully consider whether my hopes were a good fit for the TC. I was nervous because I had a very clear vision, and I wanted to give people an opportunity to decide if they wanted a different direction. In part, I said [1]: >I'd like

Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee

> "Steve" == Steve Langasek writes: Steve> Hi Diane, Steve> On Thu, Nov 02, 2017 at 11:48:05AM -0700, Diane Trout wrote: >> I only just subscribed and only have read some of the discussion >> so this may be a bit off topic or already discussed. >> But

Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee

> "Ian" == Ian Jackson writes: Ian> Thanks for your mail. I have trimmed vigorously the parts I Ian> agreed with :-). Thanks again for your mail. I also trim parts where I think we understand each other and seem to be in general agreement. I want to

Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee

>>>>> "Ian" == Ian Jackson <ijack...@chiark.greenend.org.uk> writes: Ian> Sam Hartman writes ("Re: Let's Stop Getting Torn Apart by Ian> Disagreement: Concerns about the Technical Committee"): >> I am discussing how we handle

Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee

> "Russ" == Russ Allbery writes: Russ> Martin Steigerwald writes: >> Russ Allbery - 28.10.17, 16:13: >>> There wasn't *anything* "left out" of that discussion. >> In my opinion this is a pretty bold statement. >> If everyone has

Bug#877024: Modemmanager probing of unknown Devices

Like Ian, I honestly don't know what the rules are in this situation. Wou/ld it be reasonable for him to make an NMU to experimental, and then if there is no objection after testing to unstable? In parallel, it seems desirable to see if any of the maintainers are active. --Sam

Re: Bug#877024: Modemmanager probing of unknown Devices

[Bug dropped; I don't think this has value in that bug log] > "Ansgar" == Ansgar Burchardt writes: In reading your message, I realize there is an interesting challenge here. When I agree that it might be reasonable for the TC to take a look at something, what is going

Bug#877024: Modemmanager probing of unknown Devices

Dear Ian: I wanted to make you aware of a status update. The maintainer who has been doing most of the uploads on modemmanager stepped down after receiving my query. First, I'd like to extend my thanks to Michael for his hard work on modemmanager in the past and all the things he continues to

Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee

As a member of the technical committee, I've grown increasingly alarmed as I think about the impact of the issues that come to us. Yes, we're giving answers. However, I think we are doing a lot of harm to the members of our community in the process, and I would like to explore whether we can do

Bug#877024: Modemmanager probing of unknown Devices

Hi. In #877024, the TC was asked to rule on whether modemmanager should continue to probe USB devices that might not be modems. There's been significant involvement from upstream leading to a new optional behavior that is less aggressive about probing unknown devices. Would it help the

Bug#877024: modemmanager should ask before messing with serial ports

> "Aleksander" == Aleksander Morgado writes: >> In going forward, I think it is important to consider that >> Modemmanager's needs and Debian's needs may be different here. >> In the case of Modemmanager as an upstream project, it may be >> desirable

Bug#877024: modemmanager should ask before messing with serial ports

Hi. It looks like there hasn't been much traffic on this issue in the last couple of weeks. My analysis is that the key technical point here is whether it's acceptable to treat unknown devices as possible modems. It sounds like: 1) We don't have a good white list of modems. 2) We don't have

Re: Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium

> "Dominique" == Dominique Dumont writes: Dominique> On Thursday, 31 August 2017 13:58:23 CEST Thorsten Glaser wrote: >> > How about printing a "nice" warning explaining it would be a >> good idea to > move to /usr/bin/node ? >> >> That will break

Bug#862051: [Pkg-javascript-devel] Bug#754462: Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium

> "Julien" == Julien Puydt writes: Julien> Hi, Le 31/08/2017 à 13:52, Jérémy Lal a écrit : >> How about printing a "nice" warning explaining it would be a good >> idea to move to /usr/bin/node ? Then in next next release drop >> the nodejs symlink.

Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium

> "Didier" == Didier 'OdyX' Raboud writes: Didier> For good reasons, Debian forcibly introduced a special-case Didier> when Node.js first appeared in a stable release through only Didier> shipping it under /usr/bin/nodejs. That forced hundreds of Didier>

Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium

> "Thorsten" == Thorsten Glaser writes: Thorsten> Hi, >> * Restore /usr/bin/node following CTTE #862051 Let's try to drop >> /usr/bin/nodejs before buster. Replaces and Conflicts >> nodejs-legacy. Closes: #754462. Thorsten> please do NOT completely

Re: Agust 2017 TC meeting is at 'Wed Aug 16 19:00:00 UTC 2017'

I'm not sure if I can attend today. I'm watching my daughter and I don't know what we'll be doing at that point.

Bug#862051: Call for vote on allowing nodejs to provide /usr/bin/node

=== Resolution === The Technical Committee recognises that circumstances change in ways that make previous resolutions no longer appropriate. In 2012, it was resolved that the nodejs package should not provide /usr/bin/node due to the historical conflict with the ax25-node

Bug#836127: Call for Votes for new TC member

===BEGIN The Technical Committee recommends that Niko Tyni be appointed by the Debian Project Leader to the Technical Committee. N: Recommend to Appoint Niko Tyni F: Further Discussion ===END I vote N>F signature.asc Description: PGP signature

Bug#862051: Refer #862051 to ctte

> "David" == David Bremner writes: David> Philip Hands writes: >> I presume we'd want to continue providing /usr/bin/nodejs for >> people that have switched to using that, so that might as well >> continue to be the name of the binary,

Bug#860520: Voting for TC Chair

> > The chair of the Debian Technical Committee will be: > > A: Keith Packard > B: Didier Raboud > C: Tollef Fog Heen > D: Sam Hartman > E: Phil Hands > F: Margarita Manterola > G: David Bremner > ===END=== I vote B > F > D > C = E = A = G signature.asc Description: PGP signature

Bug#836127: Call for Votes for new CTTE Member

> ===BEGIN > > The Technical Committee recommends that David Bremner be > appointed by the Debian Project Leader to the Technical Committee. > > A: Recommend to Appoint David Bremner > B: Further Discussion > > ===END I vote B > A My vote is not a comment on any specific candidate. As

Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

Hi, first, you've made the point that you were hoping the TC would help the blends team and the d-i team work together. I think that Phil's suggestions for a technical approach are quite good, and I hope that will move forward in the buster cycle. With regard to stretch, I honestly don't think

Bug#846002: Call for votes on resolution for #846002 (blends-tasks)

I vote A -> FD for the blends-tasks vote. signature.asc Description: PGP signature

Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

> "Ole" == Ole Streicher writes: Georg commented that if we're going to delegate to D-I, we should hurry up and do so unless this turn into another TC failure. I personally think we've taken long enough this is already a TC failure and have expressed regret for my actions

Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

>>>>> "Ole" == Ole Streicher <oleb...@debian.org> writes: Ole> Hi Sam, Am 31.01.2017 um 16:26 schrieb Sam Hartman: >> If you go back one meeting further, my interpretation is that the >> consensus of the committee seems to b

Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

> "Ole" == Ole Streicher writes: Hi. If you go back one meeting further, my interpretation is that the consensus of the committee seems to be that ultimately this decision belongs to the installer team. That is, in this case, a number of members on the TC seem to believe

Bug#850887: To the right bug this time: Why do you want us to keep this open?

I posted this to the wrong bug, now reposting: Dear Matthias: Hi. As I understand our IRC conversation, you asked me to keep the TC bug regarding mips binutils open even after your upload. First, I want to confirm that understanding. Second, what are you hoping for from the TC at this point?

Bug#850967: Why did you want us to keep this open?

Dear Matthias: Hi. As I understand our IRC conversation, you asked me to keep the TC bug regarding mips binutils open even after your upload. First, I want to confirm that understanding. Second, what are you hoping for from the TC at this point? I think you've resolved the issue that came to

Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts

> "Josh" == Josh Triplett writes: Josh> As another technical alternative, which I haven't seen Josh> mentioned elsewhere in this thread or related bug reports: Josh> when I need to override a packaged binary or file temporarily Josh> for debugging

Bug#850887: [TIMELY for TC members] Interim Ballot Proposal: #850887 binutils mips

> "Ian" == Ian Jackson writes: Ian> You should explicitly state whether you want this NMU to be Ian> DELAYED. Good point. I think we don't want a delay. Updated the ballot in git.

Bug#850887: [TIMELY for TC members] Interim Ballot Proposal: #850887 binutils mips

I heard back from doko today. We can expect a reply tomorrow. We also talked briefly about the issue. Realistically, i cannot imagine the TC coming to any final decision on something like this in under three weeks. That timeline seems fairly aggressive actually. However, I think the TC could

Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts

I'll note that the practice of hard-coding paths is fairly common. One common cause for this is programs that don't want to rely on PATH for calling exec. Systemd is a particularly interesting example. ExecStart and related arguments in systemd units are required to include full paths. I am

Bug#850887: TC Involvement: MIPS and binutils

>>>>> "Lisandro" == Lisandro Damián Nicanor Pérez Meyer <perezme...@gmail.com> >>>>> writes: Lisandro> On miércoles, 11 de enero de 2017 09:39:25 ART Sam Hartman wrote: >> Hi. >> >> As you are probably aware,

Bug#850887: TC Involvement: MIPS and binutils

Hi. As you are probably aware, the question of what to do about linking on mips and stretch has been referred to the TC. There's a reasonable probability that we're going to want to move very quickly on this issue, and I wanted to reach out to you and see how we could best work with you to

Bug#850887: Decide proper solution for binutils' mips* bug

Hi. I'd really appreciate comments from debian-release on this issue. Would debian-release like us to take this up? If so, I have a proposal for how to fast-track this situation, but I am only comfortable doing that if the release team is involved.

Bug#846002: blends-tasks must not be priority:important - ballot proposal

Is our intent to override the maintainer or provide advice? I don't care what the answer is but perhaps we want to be clear. I'm fine with this ballot beyond that. Perhaps we want to override the blends-tasks maintainers to the extent that they disagree with the tasksel maintainers?

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

> "Ole" == Ole Streicher writes: Ole> We already have more that 5700 popcon-counted installations Ole> with the blends selection in the installer. This should give Ole> some base for that. Hi. Speaking with my TC hat on. I don't find quoting popcon stats

Bug#841294: Overrule maitainer of "global" to package a new upstream version

> "Colin" == Colin Watson writes: Colin> As a maintainer who has sometimes had cause to do similar Colin> things, I'm concerned at the standard being applied here. Colin> Could you perhaps review the history around groff 1.18.1.1 -> Colin> 1.20 for

Bug#841294: Overrule maitainer of "global" to package a new upstream version

> "Didier" == Didier 'OdyX' Raboud writes: Didier> That code is now in Debian (experimental), so yes, I do Didier> expect you to act in good faith and report bugs you see. You Didier> are obviously quite versed in how 'global' works, and that's Didier>

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

For what it's worth, I think the policy question here is not a significant one. Holger is right that we should either fix policy or fix both (tasksel-data and blends-tasks). I think that is a bug that should get hashed out. I don't think it is all that timely, and I don't think it matters much

Bug#841294: Global Ballot Thoughts

So, does someone want to propose a resolution so we can move this forward?

Bug#841294: Global Ballot Thoughts

> "Ian" == Ian Jackson writes: Ian> I know that you do not _set out_ reinforce Ron's position of Ian> power over his victims. That is not your goal. You are trying Ian> to come to an amicable settlement. You are trying to get Ian> everyone

Bug#841294: Global Ballot Thoughts

>>>>> "Ian" == Ian Jackson <ijack...@chiark.greenend.org.uk> writes: Ian> Sam Hartman writes ("Bug#841294: Global Ballot Thoughts"): >> Like you I want to see global6 for stretch. I'm not sure I want >> to see it bad enough

  1   2   3   >