Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)
Quoting Raphael Hertzog (hert...@debian.org): > Christian and Cyril, what are your thoughts on this? Do you think that if > we come up with a patch implementing the above, we could get it in > stretch? What would be the last delay to come up with such a patch? From my own POV, I'm too far from core D-I development (except l10n) nowadays to get a usefuul advice. When it comes at tasksel, I work in low maintenance mode. When obvious things pop up, and if I notice them, I usually apply fixes. The same stands when an upload is needed. However, when it comes at design issues, I consider that my own advice would be quite pointless and maybe even confusing. Sorry for not being very helpful here. signature.asc Description: PGP signature
Bug#750135: [CTTE #750135] Aptitude Project Maintainer
Quoting Axel Beckert (a...@debian.org): Hi, Don Armstrong wrote: 2. During the discussion of this issue, Christian Perrier proposed that he and Axel Beckert could watch the social aspects of Aptitude development and restore Manuel Fernandez Montecelo's commit access. Christian still has administrative rights and believes he has the technical power to implement his proposal, but requested the advice of the technical committee before doing so. Using the power of the technical committee to provide advice (ยง6.1.5): 1. The Technical Committee agrees that Christian has the power to implement his proposal and encourages him to do so. I've allowed myself to restore Manuel's commit access on behalf of Christian. Great, thanks Axel. I was waiting for the official announcement to do the same but that's of course absolutely not a problme. Thanks for your action. And thanks to the CTTE careful work. Even though the issue would seem quite obvious and was not only a technical issue, I think it's important to have it endorsed by an official Debian governing body. signature.asc Description: Digital signature
Bug#750135: Status of #750135 (Maintainer of aptitude package)
Quoting Tollef Fog Heen (tfh...@err.no): It can't indeed be worse than the current situation anyway. I see where the proposal is coming from, but I'd like to ask you to hold off on it a little bit. I've mailed Daniel and asked him to comment on the bug, so hopefully we can have his input soon and get this resolved. No problem. I was indeed waiting to see comments to my proposal without doing anything, anyway. I'll follow the issue as well to see where it goes and help where I can. signature.asc Description: Digital signature
Bug#750135: Status of #750135 (Maintainer of aptitude package)
Quoting Axel Beckert (a...@debian.org): In the long run I'd like to see even more people working on Aptitude. But for that, a possessive lead developer or power games are quite hindering. IMHO one of the reasons Aptitude's development stalled again are those power games we've seen. So I'd prefer a solution where people who want to do stuff are also able to do it -- without getting harassed by other people involved. So do I. And I still have admin rights on aptitude on Alioth. Even though I'm not that much active in aptitude's development. Here's my proposal: - restore Manuel's commit rights - have both me and Axel watch the aptitude-devel mailing list, not to judge the technical validity of changes, but more following the social aspects - and see what happens... It can't indeed be worse than the current situation anyway. It can be done without blessing of the CTTE : after all, I'm admin of the project, this was indeed granted to me by Daniel Burrows, the original aptitude developerprecisely because he feared that him becomign MIA would be an issue. And *I* am the one who granted Daniel Hartwig admin rights *because* he was doing a very useful work to keep aptitude development going on. So, indeed, I think I'm legitimate enough to decide what is best. Still, an advice from the CTTE wouldn't hurt. signature.asc Description: Digital signature
Spam fighting in -ctte mailing list....
For the record, debian-ctte can have the same spam cleaning operation than any Debian list. Anyone can report any mail in Debian mailing lists as spam. For instance, the following: https://lists.debian.org/debian-ctte/2014/03/msg1.html has a Report as spam button on the upper right corner. Once enough people reported a given mail as spam, it is handled to a team of volunteer DD who process reported spam candidates and either tag them as ham or spam. If a said mail reaches a predefined treshold, it is then definitely removed from the mailing list archives. It is quite likely that I resume my activity in that field in the upcoming weeks, particularly focusing on -ctte, -project, -devel and -user mailing lists. Just as a coincidence, of course. And, of course, I would love to see more volunteers joining this effort. -- signature.asc Description: Digital signature
Bug#727708: Call for votes on init system resolution
Quoting Cyril Brulebois (k...@debian.org): If you have any question for -boot@, please send a mail there. If you want some input from either Christian or me, please cc us to ensure we don't miss that mail. And, FWIW, though I *am* in some way following the -ctte list (including the giant #727708 story to some extent), I do not consider myself qualified to have any *technical* advice or valid *technical* input about the decision that has to be taken. signature.asc Description: Digital signature
Re: Draft GR for permitting private discussion
Quoting Michael Gilbert (mgilb...@debian.org): We went back and forth on this in IRC a little bit. The difficulty is that unless you're going to delegate to some other entity the ability to decide when the TC can hold private discussions (which I don't think would be very practical), the TC itself ends up deciding when it's appropriate. I think that's appropriate. Self-policing seems fine. The importance ^^ Definitely, it's fine. If Project Members don't have any kind of trust in the wisdom of the TC members, including their wisdomwhen it comes at non-technical things, then we have a problem. So, making the wording over-complicated to just avoid theoretical situations that can not happen if the TC members are trustworthy people, just seems like haircutting to me (definitely a typical geek activity, but often the best way to go nowhere). signature.asc Description: Digital signature
Re: draft ballot: please rule on how to implement debian/rules build-arch
Quoting Bdale Garbee (bd...@gag.com): On Sun, 24 Jul 2011 20:36:14 +0100, Ian Jackson ijack...@chiark.greenend.org.uk wrote: - Lintian doesn't warn about missing build-* targets yet, so many maintainers are not aware that their package are affected by this issue. Is this still true ? No. Lintian has been warning me about the missing targets .. I'm not sure when that changed, but I believe it's doing the right things now. And, as a Stupid And Clueless Maintainer, I have to say that, up to now, I just blindly adopted what lintian suggested to meassuming that Those Who Know know what they're doing and that adding these target is What Should Be Done...:-) Or, even more simpler, I try to use dh7-style minimal rules files and let debhelper handle all the magic..:-) Still, nearly each package of mine I worked on recently had the issue of not having build-arch and build-any, so I suspect this is the case for many pkgs in the archive. signature.asc Description: Digital signature
Re: Always ask for root passowrd twice, even on critical priority installs?
Quoting Raul Miller ([EMAIL PROTECTED]): On 6/9/05, Christian Perrier [EMAIL PROTECTED] wrote: Some people have argued this does against all established practices in such matter. Others have argued that the way to install a system is a very specific way and that, after all, the password confirmation is not *mandatory* to have the process continuing. As the arguments seems quite solid both ways, I take the hard way and hereby ask about Your Wise Advice. The discussion inside the D-I team did not yield to a very strong advice, too, as far as I have analysed. I must admit that I don't understand the argument for asking only once. Could someone spell out those reasons for me? This is a strict implementation of what's explained in debconf-devel(7) about debconf questions priorities: lowVery trivial questions that have defaults that will work in the vast majority of cases. medium Normal questions that have reasonable defaults. high Questions that don't have a reasonable default. critical Questions that you really, really need to see (or else). Strictly speaking, the first password question pertains to the critical priority, because it does not have any reasonable default. The confirmation question has a reasonable default or, to say this another way, is not strictyly necessary to be able to continue and not break anything. About the keyboard problem detection, I indeed fail to see how asking the password twide would help detecting it. If the keymap is wrong, then the password will be entered wrongly both times Again, the strongest argument to have the confirmation asked at high priority is that critical is really meant to be a *non default* priority as it uses as few questions as possible. This is highly arguable, of courseand this is precisely for that reason that I have chosen to gather advices..:-) (and not in -devel, at least for the first round) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Always ask for root passowrd twice, even on critical priority installs?
(and not in -devel, at least for the first round) Now that's kind of bizarre. You're planning to go to -devel *after* having gone to the technical committee? I guess you're not actually expecting the technical committee to make a ruling on it, or you're just going to ignore it if it's one you don't like? Hmmm, sorry for not having been clear. No, I don't want to go to -devel if -ctte comittee advice is not the one I'm expecting. Honestly, I'm having hard times to make my own mind and I need help and wise advice on that issue. I personnally tend to favor the current choice of only one prompt, but this is definitely not a strong position. Up to now, advices I have collected all go in the same direction, especially from -ctte people. So, if nothing comes to go against this, I think that I will follow these advices and reinstate the confirmation to critical priority. Asking -devel would have happened *only* if the Technical Committe had been unable to take a strong position on this issue, for instance if advices had been shared inside the TC itself. Hope this makes it clearer:-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Always ask for root passowrd twice, even on critical priority installs?
(2nd try as I ignored that posting to the -ctte list is restricted to subscribers) Dear Technical Commitee, The shadow package maintenance team is left with an issue which seems quite controversial (even inside the team...:-)). See http://bugs.debian.org/304350 for details. In short, shadow debconf templates are currently used by base-config during the initial system install to prompt about the root user password. In default installs, the user is prompted for the password, then the password confirmation. However, when the debconf priority is set to critical in D-I (which is not the recommended way to install a system and is aimed at minimizing the number of questions seen by users to the very strict minimum), then the root password is only prompted ONCE. Some people have argued this does against all established practices in such matter. Others have argued that the way to install a system is a very specific way and that, after all, the password confirmation is not *mandatory* to have the process continuing. As the arguments seems quite solid both ways, I take the hard way and hereby ask about Your Wise Advice. The discussion inside the D-I team did not yield to a very strong advice, too, as far as I have analysed. Please keep #304350 CC'ed to the thread and answers. I will then try to make my mind from your answers. -- - End forwarded message - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
