I would like to refer bugs #164591 and #164889 (these are merged, and
I'm the submitter of the latter) to the committee. Below you'll find
my summary of the issue. (In the summary, `you' refers to the package
maintainer.)
I sent Adam (via the BTS) this summary on the 25th of October, and
asked A
Ian Jackson writes ("Bug#164889: md5sum I would like to refer bugs #164591 and #164889 (these are merged, and
> I'm the submitter of the latter) to the committee. Below you'll find
> my summary of the issue. (In the summary, `you' refers to the package
> mainta
Ian Jackson writes ("Committee members please check you got my test"):
> I've just sent a test message to debian-ctte-private. To avoid any
> problems with the call for applications that I'm going to send out,
> please let me know within the next few days if you di
I've just had a conversation with Josip Rodin on IRC, and it seems
that -ctte-private is actually being archived to a file which is
readable to all developers. This isn't really what we want if we're
going to have a sensitive conversation about who'd make a good tech
ctte member.
Also, it seems t
Clint Adams writes ("Re: Bug#164889: md5sum Rather than Debian shipping its own md5sum, why not just rely on the GNU
> textutils md5sum(1) in coreutils or one of the not-yet-packaged md5(1)
> utilities from *BSD, depending on whether or not one wants the '-' in
> output?
Please read my summary of
Jason Gunthorpe writes ("Re: Committee members please check you got my test"):
> murphy{jgg}/var/list/debian-ctte-private#cat dist
> (Only addresses below this line can be automatically removed)
> [EMAIL PROTECTED]
> murphy{jgg}/var/list/debian-ctte-private#
>
> So, I don't think anyone but you is
Everyone: please do not CC debian-ctte on this discussion.
Anthony Towns writes ("Re: Bug#97671: xutils: why is rstart.real a conffile?"):
> reassign 97671 tech-ctte
> thanks
The Technical Committee has already referred this question to the
Bug System Administrators and the Project Leadership. Q
Raul Miller writes ("Re: Bug#164889: md5sum There are essentially two approaches to this class of problem.
I think you're approaching this the wrong way. To look at it only as
a compatibility problem is to avoid the question of which behaviour is
more useful.
The behaviour that GNU md5sum now p
Jason Gunthorpe writes ("Re: Committee members please check you got my test"):
> Yes, I probably can, if you tell me where the archive you are having
> problems is located.
I had a conversation on IRC with Josip Rodin, who asserted that there
was an archive readable to all developers, as a result
Ian Jackson writes ("Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for
console"):
> I think all that's going to be said has been said. So I hereby
> propose the following resolution and immediately call for a vote.
Thanks everyone for your contributions, and thanks to
Herbert Xu writes ("Re: Processed: 161931 etc. reassign"):
> This will be fixed in the next release.
Thanks.
Regards,
Ian.
john lee writes ("aboot"):
> Hi I am a student trying to install debian on a dec alpha and I cant get
> the aboot to load is thre any help that u could provide thx
Thank you for your message to the Debian Technical Committee.
The Committee's purpose is to resolve technical disputes for the
Debi
John Obenauer writes ("Debian on tablet PCs?"):
> Do you know whether Debian can be installed on the new tablet PCs, and
> if it could accept input from the new screens? If not, do you know
> whether anyone has started a project like this, such as making a Linux
> device driver to read screen i
Please make [EMAIL PROTECTED] undeliverable. The
Committee is using [EMAIL PROTECTED], a simple alias, and
the presence of two addresses is confusing. Also, there is some doubt
about the protection status of any archives of
[EMAIL PROTECTED], meaning that some information which should
be private
Anand Kumria writes ("Re: [EMAIL PROTECTED] - shut it down"):
> On Sat, Jan 04, 2003 at 02:05:41PM +, Ian Jackson wrote:
> > Please make [EMAIL PROTECTED] undeliverable.
>
> Done.
Thanks.
> > The Committee is using [EMAIL PROTECTED], a simple alias, and
Bdale Garbee writes ("request for status report"):
> Hello. You are receiving this email either because I've delegated some task
> to you explicitly as Debian Project Leader in the past year, or because your
> name is listed at
> http://www.debian.org/intro/organization
Sorry for the delay
Rob Bradford writes ("Re: Help"):
> This list is not relevant for this topic. A revelant list would be
> [EMAIL PROTECTED]
Can I offer my form letter which I use for cases like this ?
Thank you for your message to the Debian Technical Committee.
The Committee's purpose is to resolve technical d
Anand Kumria writes ("Re: new moderation system"):
> On Wed, Feb 12, 2003 at 05:11:57PM +, Ian Jackson wrote:
> > But, debian-ctte should not be moderated.
> > Could you please unmoderate it, but make it member posting only ?
>
> Do you mean restricted to
Raul Miller writes ("Re: Social Contract GR's Affect on sarge"):
> [1] We need to make sure we know who is active. Maybe we should have a
> "show of hands" on who on the committee is actively reading this thread?
Thanks to your prod in my other mailbox, Raul. I'd fallen off the
committee list (a
Manoj Srivastava writes ("Re: Social Contract GR's Affect on sarge"):
> On Mon, 3 May 2004 17:28:43 +0100, Ian Jackson <[EMAIL PROTECTED]> said:
> > * Our Secretary seems to be under the impression [...]
>
> Rubbish. In the case of the last GR, the spon
Manoj Srivastava writes ("Re: Social Contract GR's Affect on sarge"):
> > * Since we are in something of a hurry, [...]
>
> I think we should not interfere in whatever solution the
> developers come up with, since we are not actually involved as a
> group in the solution process.
We've b
Getting myself back on the ctte list has reminded me of the two other
things we have had on our plate for a little while: bug #164591
(md5sum output format) and the call for new members.
The md5sum output format thing is my bug report, so I'll write up a
summary soon.
Re the call for new members:
This bug has been sitting on our todo list for some time, mainly
because I've been too slack. My apologies. As promised, I'm now
picking it up again.
I've gone and reread the bug reports #164591 and #164889, of which I'm
the submitter of the latter, and I've written a summary of my
position, bel
Raul Miller writes ("Re: md5sum It's probably not unreasonable, however, for programs designed to work
> with specifically this md5sum interface to expect the interface to remain
> the same.
When it has already changed more than once (Debian has changed from
old behaviour to new and back and now
Scott James Remnant writes ("Re: md5sum [I am not subscribed to debian-ctte, please Cc: me if you feel your
> reply deserves my attention.]
...
> My personal feeling is that is what should change; /usr/bin/md5sum
> should be provided by the GNU coreutils package with dpkg either using
> that or i
Scott James Remnant writes ("Re: md5sum Just stepping the bug aside for a moment; I'm unsure whether it as
> appropriate for the chairman of the tech-ctte to make a recommendation
> about a bug they themselves filed. It seems to give you a power to
> pronounce judgement from on-high on any bug yo
Pascal Hakim writes ("Posting on the list [EMAIL PROTECTED]: Re: md5sumBack in Feb 2003, this list was turned into a subscribers-only
> list. This means that unless those people are subscribed, they won't be
> able to post.
This is to try to reduce the amount of spam.
> Based on som
As far as the committee goes, we've heard from Guy, Raul, and me. Are
the rest of you reading ? What are your views ? Guy, do you have a
reply to Raul's last point ?
I've written a draft resolution as a trial balloon. Let me know what
you think.
Thanks,
Ian.
1. The Technical Committe has co
Raul Miller writes ("Re: md5sum I do wish we has a better way of saying "request (or require [if we have
> sufficient supermajority])".
Perhaps we should just write `require' in draft resolutions, with the
understanding that if they pass but not with the necessary
supermajority the word `require'
Well, now there are four of us who've replied so it seems we're not
going to be lacking in participants, and no-one has criticised my
draft, so I hereby formally propose the resolution below. If I don't
hear any objections I'll call for a vote in a few days.
1. The Technical Committe has conside
In the original constitution, which can be seen here:
http://www.debian.org/devel/constitution.1.0
in order to overrule a maintainer we need a 3:1 supermajority
including the chairman (because it counts as a tie). I think the need
for the chairman to agree in this case is a mistake.
In the `tidy
:A,
even though this produces an outcome that is worse overall (the TC is
unable ever to decide). Any member who votes A:B:FD effectively hands
the vote over to the other side, because now B (which they dislike)
strictly defeats FD even though their own option A (which their
B:FD:A-voting opponents di
Raul Miller writes ("Re: Our supermajority requirement has changed !"):
> On Wed, May 26, 2004 at 12:53:41AM +0100, Ian Jackson wrote:
> > IME people nearly always put FD ahead of the options they disagree
> > with.
>
> However, it's possible for people to thi
Ian Jackson writes ("Re: Our supermajority requirement has changed !"):
> amended a ballot A:B:FD count against A in A-vs-B due to the the
^can
Ian.
Raul Miller writes ("Re: Our supermajority requirement has changed !"):
> If you approve of two options but like one better than another, you're
> not being penalized if the "liked, but not liked as much" option wins
> over your favorite. Instead, you're being rewarded -- there weren't
> enough vo
Raul Miller writes ("Re: Our supermajority requirement has changed !"):
> I don't see that removing the word "strictly" has this effect at all.
>
> The quorum for committee votes is 2, which means that each option must
> receive 2 votes preferring it over the default option or it is ignored.
Yes,
Raul Miller writes ("Re: Our supermajority requirement has changed !"):
> If X wants to minimize potential losses (and X has certain knowledge that
> no other votes will be cast), X should cooperate.
Oh, I forgot to say:
`Minimise potential losses' (ie, aim for the least bad worst case) is
one
Ian Jackson writes ("Proposed resolution Re: md5sum Well, now there are four of us who've replied so it seems we're not
> going to be lacking in participants, and no-one has criticised my
> draft, so I hereby formally propose the resolution below. If I don't
> hear a
Jason Gunthorpe writes ("Re: Proposed resolution Re: md5sum I do not object to your draft, if it comes to a vote I will support it.
Thanks.
> However, I fail to see the point of all this. As far as I can tell making
> this decision, or not, will have no substantive effect on Debian at all.
Well
Anthony Towns writes ("Re: Our supermajority requirement has changed !"):
> On Wed, May 26, 2004 at 11:49:55PM +0100, Ian Jackson wrote:
> > While I'm looking at this, A.6(3)(3) is very oddly phrased and might
> > turn out to be buggy in the future: if a
Raul Miller writes ("Re: Proposed resolution Re: md5sum Maybe we should do a bit more on Anthony Towns' release policy issue,
> first.
Perhaps so.
Several weeks ago I wrote:
> Anthony, do you still want a formal statement of this from the whole
> committee or is informal opinions from some of us
Manoj Srivastava writes ("Re: Social Contract GR's Affect on sarge"):
> On Mon, 3 May 2004 17:28:43 +0100, Ian Jackson <[EMAIL PROTECTED]> said:
> > * Since we are in something of a hurry, and there will be time to
> >clarify the situation at mo
It seems that my previous mail, while having a comment addressed to
Anthony in it, wasn't sent to him :-(. Oh well. Anthony, do I take
it that you still want the TC to make some kind of formal decision
here ?
Is there a bug report for this issue ? Anthony, if you would still
like a formal prono
I hereby propose the following resolution:
WE THE DEBIAN TECHNICAL COMMITTEE NOTE THAT
1. The Technical Committee is not merely a mailing list, but a
formal institution in the Debian Project, established by the
Constitution.
2. People sometimes mail [EMAIL PROTECTED] (d.o = debian
Ian Jackson writes ("[EMAIL PROTECTED]' etc. blackhole"):
> I hereby propose the following resolution:
Oh, two of my test messages were delayed, and I have discovered that
some of my assertions in my previous draft were false:
> 4. Messages to [EMAIL PROTECTED], [EMA
Martin Michlmayr - Debian Project Leader writes ("Re: Posting on the list
[EMAIL PROTECTED]: Re: md5sum * Ian Jackson <[EMAIL PROTECTED]> [2004-05-20 19:49]:
> > > Back in Feb 2003, this list was turned into a subscribers-only
> > > list. This means that unles
Stephen Frost writes ("(forw) [EMAIL PROTECTED]: Re: Posting on the list [EMAIL
PROTECTED]: Re: md5sum * Ian Jackson ([EMAIL PROTECTED]) wrote:
> > If the alternatives are a moderated list or one that has completely
> > open posting then we will have to go back to a moderate
Stephen Frost writes ("Re: (forw) [EMAIL PROTECTED]: Re: Posting on the list
[EMAIL PROTECTED]: Re: md5sum The TC isn't the only committee in Debian. [...]
FSVO `committee', this is true. But the TC is the only one that's
formally established and can't really be worked round if it breaks.
It's
Ian Jackson writes ("[EMAIL PROTECTED]' etc. blackhole"):
> I hereby propose the following resolution: [snipped]
I would like to apologise. James Troup sent me a sensible mail
pointing out that this approach is rude and unhelpful. My private
reply to James at the time was
Pascal Hakim writes ("Re: (forw) [EMAIL PROTECTED]: Re: Posting on the list
[EMAIL PROTECTED]: Re: md5sum Luckily for you, murphy leaves in the headers both the old
> envelope-sender, and the host it received the email from.
This is true, but not helpful in this particular case. But I don't
thi
Raul Miller writes ("Re: (forw) [EMAIL PROTECTED]: Re: Posting on the list
[EMAIL PROTECTED]: Re: md5sum I can probably live with things the way they are now, as far as spam
> filtering.
You mean that you think the current level of spamfiltering would be
adequate even without the `member posting
Manoj Srivastava writes ("Re: Our supermajority requirement has changed !"):
> [stuff about voting methods]
I think I've lost the plot now. I can't remember what the original
point of this subthread was. I think I was trying to convince you
that allowing options equal the default option to pass
Ian Jackson writes ("Re: Proposed resolution Re: md5sum No-one has objected, so I hereby call for a vote on my resolution,
> which I proposed earlier. I vote yes, obviously. Here's the
> resolution again, for reference.
Votes so far:
Ian, Raul, Manoj: yes
Guy, Bdale, Jaso
Jason Gunthorpe writes ("Re: [EMAIL PROTECTED]' etc. blackhole"):
> On Tue, 1 Jun 2004, Ian Jackson wrote:
> > 6. We insist that [EMAIL PROTECTED] should be an alias for
> > [EMAIL PROTECTED]
>
> Ok, I just did that.
thanks.
> > 7. We insist t
Ian Jackson writes ("Re: Social Contract GR's Affect on sarge"):
> It seems that my previous mail, while having a comment addressed to
> Anthony in it, wasn't sent to him :-(. Oh well. Anthony, do I take
> it that you still want the TC to make some kind of formal d
Apologies for sending this mail to the whole list (if it works). Note
that the published contact address for the committee, and for
discussion of the committee's activities, is still
[EMAIL PROTECTED] This extra alias is merely there to prevent
accidents.
Thanks,
Ian.
Thanks to everyone for your contributions, and to the voting committee
members for your votes. The Technical Committee has passed the
following resolution:
1. The Technical Committe has considered the questions raised in
Bug#164591 and Bug#164889, concerning the output format from
md5sum
I've just posted a message to the debian-vote list about a bug I think
I've found in the Condorcet/Cloneproof-SSD GR's amendments to the vote
counting arrangements.
I didn't include you all in the CC list of my posting because you
probably don't want to get flooded with mail discussions about it.
Jason Gunthorpe writes ("Re: [EMAIL PROTECTED]' etc. blackhole"):
> Well, I have made an error in this it seems. The rational for not having
> this sort of forward is pretty good. What I wanted to fix is the
> _blackhole_ around [EMAIL PROTECTED] that is used by the remote list
> auto-backuper, so
Chris Cheney writes ("Why doesn't debian-ctte accept emails forwarded from
bts?"):
> Why doesn't the debian-ctte list accept emails forwarded from bts. I
> just had to bounce my messages sent to the bug #254598. It is pretty
> dumb that it only accepts emails from bts if the person sending the
> e
Raul Miller writes ("debian-ctte mailing list and spam"):
> As near as I can tell, the only outstanding committee mailing list admin
> issue is that the list is closed to non-subscribers.
I think this is true.
> The advantage of this policy is that it does reduce the amount of spam
> the list get
Stephen Frost writes ("Re: debian-ctte mailing list and spam"):
> Generally I think the spam filtering done for all the other lists is
> pretty decent and takes case of most of it. I've got my own filtering
> in case something gets through (and for non-debian lists that don't have
> much filtering
Raul Miller ([EMAIL PROTECTED]) wrote:
> Your fundamental point seems to be that we should have no filtering
> till after the list has distributed it (or, at least, no more than what
> the other lists have). That any additional filtering should be on a
> per-user basis.
Oh, and I should have come
(Note that this mail isn't CC'd to the bug report. I will send a note
there saying that the discussion will be / should be taken to the
debian-ctte list.)
I agree that it is the porting team's primary responsibility to choose
the name. I don't think that this is the dpkg maintainers' decision,
a
I'm posting my substantive reply to the debian-ctte list (only) -
please find it, and follow up, there.
Ian.
Pascal Hakim writes ("Re: debian-ctte mailing list and spam"):
> Speaking with my listmaster hat on, that's certainly possible, but I
> don't believe it will help non-subscribers or subscribers posting with a
> different address all that much. I guess every little bit helps however.
Is it straight
Manoj Srivastava writes ("Re: debian-ctte mailing list and spam"):
> I deal with spam on about a dozen debian mailing lists, and I
> see this list as little different. I heartily recommend crm114 to
> people who want to eliminate spam from their inboxes.
Presumably crm114 is a spamfilter o
Pascal Hakim writes ("Re: debian-ctte mailing list and spam"):
> I still fail to see why this list needs different rules than all the
> others.
To put it most bluntly: the other lists have a bad situation too.
Speaking for myself, though, I don't have to follow all of those other
lists and read th
Pascal Hakim writes ("Re: debian-ctte mailing list and spam"):
> I take back what I said actually. The signature checker is very brittle,
> and it already stops a number of valid messages from people who want to
> post on the gpg-restricted lists such as debian-devel-annouce or
> debian-security-an
Wichert Akkerman writes ("Re: debian-ctte mailing list and spam"):
> It runs from procmail, so basically:
> * receive the post on stdin
> * return accept/bounce flag via returncode
Blars Blarson writes ("Re: debian-ctte mailing list and spam"):
> * the system being used is heavily overloaded, so f
Ian Jackson writes ("Re: [Fwd: Re: Bug#254598: Name of the Debian x86-64/AMD64
port]"):
> Pretty much all of these lead me to conclude that we should resolve
> along the following lines:
I was slightly unclear about whether that was a formal proposal, and
in any case didn't
Adam Heath writes ("Re: md5sum Please don't do anything to resolve this bug, until I have had time
> to write a proper reply.
How soon can we expect that to be ?
Adam Heath writes ("Re: md5sum There are issues not discussed with the decision.
If they're relevant, it's a shame that you didn't r
Wichert Akkerman writes ("Re: debian-ctte mailing list and spam"):
> Do you want to store the original message on the server? That might grow
> to become a large database. It could be pruned daily of course.
Indeed. The original message wouldn't have to be kept very long.
> Perhaps we should sup
Stephen Stafford writes ("Re: debian-ctte mailing list and spam"):
> This looks like a fairly good plan, however it will mean that
> virtually all the spam (which the point is to try to minimise) gets
> bounced back to the (probably) forged return-path, thereby sending
> spam to some poor unfortuna
Bdale wrote to me after I announced the results of the md5sum vote to
say that he voted in favour. I emailed him back to say that I didn't
receive his message and asking for details so I could trace it. Bdale
didn't reply, and a followup I sent recently has had no reply that I
can see either, des
Reading debian-vote, I think it would be helpful if we stated our
opinion formally. There still seems to be some dispute.
I therefore hereby propose the following resolution and call for a
vote. I'm hoping we can get enough of the TC to vote in favour to get
an official resolution well before th
Ian Jackson writes ("Re: Social Contract GR's Affect on sarge"):
> Reading debian-vote, I think it would be helpful if we stated our
> opinion formally. There still seems to be some dispute.
>
> I therefore hereby propose the following resolution and call for a
>
Raul Miller writes ("Re: Social Contract GR's Affect on sarge"):
> I've been trying to decide what I think about that resolution.
If it's difficult to decide then perhaps I should draft a simpler
version that makes it easier :-).
Ian.
[EMAIL PROTECTED] writes ("Re: Social Contract GR's Affect on sarge"):
> I don't think the ctte should be recommending how to vote. [...]
Manoj Srivastava writes ("Re: Social Contract GR's Affect on sarge"):
> I agree with the first part of this. [...]
> I strongly feel we should not b
On Mon, Jun 28, 2004 at 03:36:08PM -0500, david nicol wrote:
> We could demand SPF listing or c/r, until junk all has SPF.
I'm strongly opposed to SPF, mainly because the technical details
are insane. See for example what I said in RISKS:
http://catless.ncl.ac.uk/Risks/23.18.html#subj10
Ian.
Raul Miller writes ("[EMAIL PROTECTED]: vote graph for GR2004-004]"):
> http://seehuhn.de/comp/GR2004-004.html
>
> Seems to indicate that option B is likely to win.
Right. (Good.)
> Given that the old release policy was implicitly based
> on an ambiguous interpretation of the social contrac
Raul Miller writes ("releasing sarge"):
> Given option B as the winner for the most
> recent election, and given current release policy
> (http://people.debian.org/~ajt/sarge_release_policy.txt) I think we need
> to issue a statement along the lines of
>
> We ratify the current release policy wit
Raul Miller writes ("release policy"):
> Attached, below, is AJ's release critical policy, in the context of
> sarge.
>
> I'm thinking we should ratify it, as is. As soon as possible.
Gads, do we really need to ratify the entire text of this document ?
> I'm thinking we should ratify a changed
Thanks to Raul, Bdale and Steinar for comments and suggestions. At
Bdale's request I have deleted the old paragraph 17 (which
contemplated the rpvm maintainer closing their bug). So ...
I hereby propose the following resolution and call for an immediate vote:
It appears that everyone agrees on
Steinar H. Gunderson writes ("[EMAIL PROTECTED]: ]"):
> Dirk requested that somebody forwarded this to the list, so here goes. :-)
Thanks.
Dirk Eddelbuettel <[EMAIL PROTECTED]> writes:
> [stuff]
Dirk, I'm not sure I understand the thrust of your argument. The main
thing you seem to be disagreei
Bdale Garbee writes ("Re: Bug#266837: rpvm_0.6.2-1_hppa: FTBFS: relocation
R_PARISC_DPREL21L can not be used when making a shared object; recompile with
-fPIC"):
> [EMAIL PROTECTED] (Ian Jackson) writes:
> > 16. If the rpvm maintainer is of the opinion that there is no cha
(I accidentally failed to send my last message to the committee list.
My apologies! Here is a slightly edited version, taking into account
a correction from Steinar.)
It looks like informal discussions aren't doing the job here. I
hereby propose the resolution below. If anyone disagrees with an
der,
[EMAIL PROTECTED].
Membership
The current members of the committee are:
Wichert Akkerman
Bdale Garbee
Jason Gunthorpe
Ian Jackson (chairman)
Guy Maor
Raul Miller
Dale Scheetz
Manoj Srivastava
Archives and status
The
http://lists.debian.org/debian-ctte/";>committee mailing list is
arch
Josip Rodin writes ("Re: Technical Committee web page"):
> Done, thanks. It'll appear at http://www.debian.org/devel/tech-ctte shortly.
Thanks. Could you make some links to it, somewhere, possibly ? For
example, http://www.debian.org/intro/organization could do with
`Technical Committee' being m
Thanks to everyone for your contributions, and to the voting committee
members for your votes. The Technical Committee has passed the
following resolution:
The Technical Committee have considered the question of the name of
the Debian x86-64/AMD64 port. We resolve that:
* In our opinion the
Sam Hartman writes ("Formal request for review: [Sam Hartman <[EMAIL
PROTECTED]>] Referring what kernel-images to build to the technical
committee?"):
> Hi. I posted the following message to debian-devel last night and
> have received agreement with the summary and apparently (it was not
> expli
Work are sending me to Asiacrypt, which is in Queenstown from the 1st
to the 5th of December. I'm also going to be taking some time in NZ
for sightseeing etc.
So firstly, I'm going to be away from my email for quite a bit. I may
have some access from NZ, but hotel connectivity is strange and my
Well, there's certainly a lot of hot air. And the situation is rather
unfortunate.
It seems to me that:
* The social contract as amended is unambiguous, and prevents the
release of sarge as-is.
Therefore:
* The Developers must decide whether to waive or amend the social
contract. If n
Raul Miller writes ("testing committee email (and minor essay)"):
> I'm sending this message as a test message, because my MDA has been
> changed, and I want to make sure I still get committee email.
:-).
> Despite this (or perhaps because of this) there has been a singular lack
> of people sayin
I thought I should let you know, so that you hear it from me: I have
accepted a job with Canonical, working on Ubuntu.
This shouldn't significantly affect my Debian packages or my
participation on the Technical Committee (although the last week or so
has been quite hectic and I have neglected to
A little birdie tells me that we can now permit posting to debian-ctte
based on GPG signatures as well as subscription to debian-ctte. This
would be very good, and I'm sure that the rest of the committee agree
with me that this should be done straight away.
For now accepting any valid signature s
> reassign 341901 tech-ctte
> reassign 341901 devmapper
I'm afraid I don't understand why you have reassigned these bugs to
tech-ctte and then back to devmapper.
>From the discussion in 329409 it seems clear that the TC has been
asked to take up this issue. And it does seem that this is a
situat
Manoj Srivastava writes ("Removing long inactive members from the technical
committee"):
> I am formally proposing a resolution to remove the following
> members from the technical committee:
> o) Wichert Akkerman, since he has indicated that he is no longer
> actively involved wit
Raul Miller writes ("Bug#342455: tech-ctte: Ownership and permissions of device
mapper block devices"):
> I've been looking at these bugs, and I can see no good reason for the 600
> permissions, nor the reason to avoid using the disk group.
I basically agree, but I'm going to try to play devil's
Just in case the notifications from the BTS, and CC's so far, haven't
made this clear:
I would like to draw your attention to the fact that the Technical
Committee is considering complaints about the default permissions of
device nodes made by devmapper and lvm2. See bug #316883 and the bugs
merg
101 - 200 of 1203 matches
Mail list logo
