Re: linhdd concerns

[Cyril Brulebois]

On 29/11/2007, cobaco (aka Bart Cornelis) wrote:
> override files allow comments which means giving a justification is
> already possible. So it seems this just needs to be documented as best
> practice?

Yes.

-- 
Cyril Brulebois


pgpwk92xgu5mY.pgp
Description: PGP signature

Re: linhdd concerns

[Pierre Habouzit]

On Thu, Nov 29, 2007 at 11:08:33AM +, cobaco (aka Bart Cornelis) wrote:
> On Thursday 29 November 2007, Kalle Kivimaa wrote:
> > Pierre Habouzit <[EMAIL PROTECTED]> writes:
> > >   I know, but maybe (but that's sad if we need to do that) we should
> > > have overrides validated by the QA people … *sigh*.
> >
> > Should the override file have a justification field for each (error)
> > override? That would help generic DD's going through all override
> > files.
> 
> override files allow comments which means giving a justification is already 
> possible. So it seems this just needs to be documented as best practice?

  We definitely should have a lintian check for that !!! *cough*


-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgprYKWIyuaGs.pgp
Description: PGP signature

Re: linhdd concerns

[cobaco (aka Bart Cornelis)]

On Thursday 29 November 2007, Kalle Kivimaa wrote:
> Pierre Habouzit <[EMAIL PROTECTED]> writes:
> >   I know, but maybe (but that's sad if we need to do that) we should
> > have overrides validated by the QA people … *sigh*.
>
> Should the override file have a justification field for each (error)
> override? That would help generic DD's going through all override
> files.

override files allow comments which means giving a justification is already 
possible. So it seems this just needs to be documented as best practice?
-- 
Cheers, cobaco (aka Bart Cornelis)



signature.asc
Description: This is a digitally signed message part.

Re: linhdd concerns

[Kalle Kivimaa]

Pierre Habouzit <[EMAIL PROTECTED]> writes:
>   I know, but maybe (but that's sad if we need to do that) we should
> have overrides validated by the QA people … *sigh*.

Should the override file have a justification field for each (error)
override? That would help generic DD's going through all override
files.

-- 
* Sufficiently advanced magic is indistinguishable from technology (T.P)  *
*   PGP public key available @ http://www.iki.fi/killer   *

Re: linhdd concerns

[Pierre Habouzit]

On Thu, Nov 29, 2007 at 06:49:37AM +, Mike Hommey wrote:
> On Wed, Nov 28, 2007 at 02:19:21PM -0800, Russ Allbery wrote:
> > Pierre Habouzit <[EMAIL PROTECTED]> writes:
> > 
> > >   or we could disallow the override of >= E: errors in lintian, and make
> > > lintian reboot your computer, fill your gpg with /dev/random bits, and
> > > install windows over your Debian if you override such errors.
> > 
> > I'd love it if lintian were at a point where it would make sense to do
> > that, but as a lintian maintainer, I'm afraid that it's not.  Not all
> > errors are created equal, and some of them should legitimately be
> > overridable.
> > 
> > We've talked for quite a while about having finer-grained control over
> > lintian messages than the current three-tier system, in part to allow
> > something like this (automatic dak rejection on certain lintian errors,
> > for instance), but I'm way short on time.  :/
> > 
> > For example, to take the lintian error that started this thread, there are
> > some arch: all packages in the archive with architecture-specific objects
> > that at least on a cursory glance I couldn't declare wrong.  They're
> > development packages for cross-compilation and the arch-specific objects
> > are libraries for the target.  That seems like a legitimate case for a
> > lintian override to me.
> 
> Also, BIOSes for emulators are candidates for such an override.

  I know, but maybe (but that's sad if we need to do that) we should
have overrides validated by the QA people … *sigh*.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpLqejl3yhBB.pgp
Description: PGP signature

Re: linhdd concerns

[Mike Hommey]

On Wed, Nov 28, 2007 at 02:19:21PM -0800, Russ Allbery wrote:
> Pierre Habouzit <[EMAIL PROTECTED]> writes:
> 
> >   or we could disallow the override of >= E: errors in lintian, and make
> > lintian reboot your computer, fill your gpg with /dev/random bits, and
> > install windows over your Debian if you override such errors.
> 
> I'd love it if lintian were at a point where it would make sense to do
> that, but as a lintian maintainer, I'm afraid that it's not.  Not all
> errors are created equal, and some of them should legitimately be
> overridable.
> 
> We've talked for quite a while about having finer-grained control over
> lintian messages than the current three-tier system, in part to allow
> something like this (automatic dak rejection on certain lintian errors,
> for instance), but I'm way short on time.  :/
> 
> For example, to take the lintian error that started this thread, there are
> some arch: all packages in the archive with architecture-specific objects
> that at least on a cursory glance I couldn't declare wrong.  They're
> development packages for cross-compilation and the arch-specific objects
> are libraries for the target.  That seems like a legitimate case for a
> lintian override to me.

Also, BIOSes for emulators are candidates for such an override.

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: linhdd concerns

[Russ Allbery]

Pierre Habouzit <[EMAIL PROTECTED]> writes:

>   or we could disallow the override of >= E: errors in lintian, and make
> lintian reboot your computer, fill your gpg with /dev/random bits, and
> install windows over your Debian if you override such errors.

I'd love it if lintian were at a point where it would make sense to do
that, but as a lintian maintainer, I'm afraid that it's not.  Not all
errors are created equal, and some of them should legitimately be
overridable.

We've talked for quite a while about having finer-grained control over
lintian messages than the current three-tier system, in part to allow
something like this (automatic dak rejection on certain lintian errors,
for instance), but I'm way short on time.  :/

For example, to take the lintian error that started this thread, there are
some arch: all packages in the archive with architecture-specific objects
that at least on a cursory glance I couldn't declare wrong.  They're
development packages for cross-compilation and the arch-specific objects
are libraries for the target.  That seems like a legitimate case for a
lintian override to me.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: linhdd concerns

[Russ Allbery]

Michael Banck <[EMAIL PROTECTED]> writes:

> One thing we could do is have a seperate report on
> http://lintian.debian.org which lists all the lintian overrides (maybe
> only those for errors, not for warnings), so they can be peer reviewed
> by interested people. 

I've been wanting to add overrides and info tags to the lintian.d.o pages
for some time and just haven't had the time to work on the scripts.
Patches are definitely welcome.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)

[Sune Vuorela]

On 2007-11-28, Bas Wijnen <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 28, 2007 at 02:49:38PM +0100, Pierre Habouzit wrote:
>> On Wed, Nov 28, 2007 at 12:23:30PM +, Michael Banck wrote:
>> > Another thing we could do is alert sponsors about checking for lintian
>> > overrides when they review a package.
>>=20
>>   or we could disallow the override of >=3D E: errors in lintian, and make
>> lintian reboot your computer, fill your gpg with /dev/random bits, and
>> install windows over your Debian if you override such errors.
>
> Interesting idea.  I'd prefer to use a bit softer approach, if only
> because I wouldn't want to push our developers (DD or not) to non-free
> software, even if they misbehave. ;-)
>
> How about letting lintian report all messages always, with an extra note
> for overrides?  Like this[0]:

A too verbose lintian makes people overlook the real issues.

Some time ago, lintian was too strict about .desktop files and made the
kdegraphics source package spew more than 700 lines of lintian warnings
and errors.  (lintian has now gotten more accurate)

Those 700 lines of  made lintian effectively unusable for those
packages.

Overrides are meant to make stuff not be shown. Please let it be that
way and instead educate sponsors to look at installed overrides. 

Lintian even has a switch to ignore overrides and output everything -
sponsors should use that.

/Sune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)

[Gunnar Wolf]

Bas Wijnen dijo [Wed, Nov 28, 2007 at 04:51:30PM +0100]:
> >   or we could disallow the override of >= E: errors in lintian, and make
> > lintian reboot your computer, fill your gpg with /dev/random bits, and
> > install windows over your Debian if you override such errors.
> 
> Interesting idea.  I'd prefer to use a bit softer approach, if only
> because I wouldn't want to push our developers (DD or not) to non-free
> software, even if they misbehave. ;-)

Besides, I somehow doubt this would be legal or enforceable on all
jurisdiction. Just as an example, I doubt it would be legal and
enforceable for Lintian to install Windows on my PPC machines.

> How about letting lintian report all messages always, with an extra note
> for overrides?  Like this[0]:
> 
> I: Override installed for the following message:
> I: W: pioneers binary: binary-without-manpage usr/games/pioneers-editor
> 
> With -i, the first line should expand to something like:
> 
> I: Override installed for the following message:
> I: The maintainer installed an override for the following error.  This
> I: means that lintian is wrong about this, and there is nothing wrong
> I: with the package.
> 
> Or perhaps a little less maintainer-friendly, suggesting that the
> override could be incorrect. :-)

+1 to this. Overriden Lintian messages should be infrequent, as you
say, and the overrides should just demote the message to the point it
does not bother the person building anymore, but automated tools (and
fellow humans building the package, i.e. to sponsor, NMU or adopt it)
should nonetheless know there is _something_ Lintian does not like.

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


pgpPM1acy66Tf.pgp
Description: PGP signature

Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)

[Pierre Habouzit]

On Wed, Nov 28, 2007 at 02:54:39PM +, Michael Banck wrote:
> On Wed, Nov 28, 2007 at 02:49:38PM +0100, Pierre Habouzit wrote:
> >   or we could disallow the override of >= E: errors in lintian, and make
> > lintian reboot your computer, fill your gpg with /dev/random bits, and
> > install windows over your Debian if you override such errors.
> 
> Are you routinely overriding valid lintian errors or why are you
> apparently so deeply horrified by peer review of lintian overrides?
> 
> Pierre, bugs are nothing to be ashamed of.

  You must have misunderstood me. I believe that allowing anyone to
override some kinds of lintian warnings should just be disallowed,
because there's no way such a thing is correct. Or so seldomly that
packagers for whom it's the case can live with a warning.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpvfWXmvbzWN.pgp
Description: PGP signature

Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)

[Ramakrishnan Muthukrishnan]

Michael Banck <[EMAIL PROTECTED]> writes:

> On Tue, Nov 27, 2007 at 06:55:10PM +1000, Anthony Towns wrote:
>> aj, who'd just like to see some failure analysis / air crash investigation
>> type conclusions out of this, rather than just "foo sucks and
>> shouldn't upload"
>  
> One thing we could do is have a seperate report on
> http://lintian.debian.org which lists all the lintian overrides (maybe
> only those for errors, not for warnings), so they can be peer reviewed
> by interested people. 
>
> Another thing we could do is alert sponsors about checking for lintian
> overrides when they review a package.

I would also suggest adding afew lines in the developer reference
under section 7.5.2 with those suggestions that evolved out of this
thread. I will file a wishlist bug against developers-reference.

-- 
Ramakrishnan


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)

[Brett Parker]

On Wed, Nov 28, 2007 at 02:49:38PM +0100, Pierre Habouzit wrote:
> On Wed, Nov 28, 2007 at 12:23:30PM +, Michael Banck wrote:
> > On Tue, Nov 27, 2007 at 06:55:10PM +1000, Anthony Towns wrote:
> > > aj, who'd just like to see some failure analysis / air crash investigation
> > > type conclusions out of this, rather than just "foo sucks and
> > > shouldn't upload"
> >  
> > One thing we could do is have a seperate report on
> > http://lintian.debian.org which lists all the lintian overrides (maybe
> > only those for errors, not for warnings), so they can be peer reviewed
> > by interested people. 
> > 
> > Another thing we could do is alert sponsors about checking for lintian
> > overrides when they review a package.
> 
>   or we could disallow the override of >= E: errors in lintian, and make
> lintian reboot your computer, fill your gpg with /dev/random bits, and
> install windows over your Debian if you override such errors.

Then tag as wontfix when someone reports the bug on lintian? Or just
claim that it's a feature, not a bug?

-- 
Brett Parker


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)

[Bas Wijnen]

On Wed, Nov 28, 2007 at 02:49:38PM +0100, Pierre Habouzit wrote:
> On Wed, Nov 28, 2007 at 12:23:30PM +, Michael Banck wrote:
> > Another thing we could do is alert sponsors about checking for lintian
> > overrides when they review a package.
> 
>   or we could disallow the override of >= E: errors in lintian, and make
> lintian reboot your computer, fill your gpg with /dev/random bits, and
> install windows over your Debian if you override such errors.

Interesting idea.  I'd prefer to use a bit softer approach, if only
because I wouldn't want to push our developers (DD or not) to non-free
software, even if they misbehave. ;-)

How about letting lintian report all messages always, with an extra note
for overrides?  Like this[0]:

I: Override installed for the following message:
I: W: pioneers binary: binary-without-manpage usr/games/pioneers-editor

With -i, the first line should expand to something like:

I: Override installed for the following message:
I: The maintainer installed an override for the following error.  This
I: means that lintian is wrong about this, and there is nothing wrong
I: with the package.

Or perhaps a little less maintainer-friendly, suggesting that the
override could be incorrect. :-)

AFAIK there are three solutions for handling a lintian message:
- If the package is indeed broken, fix it.  The most usual.
- If lintian is broken, report a bug and/or fix it and submit a patch.
  In the mean time, ignore the message.  Not so usual.
- If lintian is not right, but this is such a weird cornercase that it
  is not reasonable to expect that, install an override.  Very unusual.

This means that lintian overrides should be very rare.  And it is no
problem to get messages like above for them.

Thanks,
Bas

[0] Ok, this is not something that should be overridden, but I wanted to
use my own package, and I don't think I have any overrides installed
anywhere.

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)

[Steve McIntyre]

On Wed, Nov 28, 2007 at 01:23:30PM +0100, Michael Banck wrote:
>On Tue, Nov 27, 2007 at 06:55:10PM +1000, Anthony Towns wrote:
>> aj, who'd just like to see some failure analysis / air crash investigation
>> type conclusions out of this, rather than just "foo sucks and
>> shouldn't upload"
> 
>One thing we could do is have a seperate report on
>http://lintian.debian.org which lists all the lintian overrides (maybe
>only those for errors, not for warnings), so they can be peer reviewed
>by interested people. 
>
>Another thing we could do is alert sponsors about checking for lintian
>overrides when they review a package.

#452804

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
"Since phone messaging became popular, the young generation has lost the
 ability to read or write anything that is longer than one hundred and sixty
 characters."  -- Ignatios Souvatzis


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)

[Michael Banck]

On Wed, Nov 28, 2007 at 02:49:38PM +0100, Pierre Habouzit wrote:
>   or we could disallow the override of >= E: errors in lintian, and make
> lintian reboot your computer, fill your gpg with /dev/random bits, and
> install windows over your Debian if you override such errors.

Are you routinely overriding valid lintian errors or why are you
apparently so deeply horrified by peer review of lintian overrides?

Pierre, bugs are nothing to be ashamed of.


Michael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)

[Pierre Habouzit]

On Wed, Nov 28, 2007 at 12:23:30PM +, Michael Banck wrote:
> On Tue, Nov 27, 2007 at 06:55:10PM +1000, Anthony Towns wrote:
> > aj, who'd just like to see some failure analysis / air crash investigation
> > type conclusions out of this, rather than just "foo sucks and
> > shouldn't upload"
>  
> One thing we could do is have a seperate report on
> http://lintian.debian.org which lists all the lintian overrides (maybe
> only those for errors, not for warnings), so they can be peer reviewed
> by interested people. 
> 
> Another thing we could do is alert sponsors about checking for lintian
> overrides when they review a package.

  or we could disallow the override of >= E: errors in lintian, and make
lintian reboot your computer, fill your gpg with /dev/random bits, and
install windows over your Debian if you override such errors.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgptwTatMy2Tb.pgp
Description: PGP signature

Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)

[Michael Banck]

On Tue, Nov 27, 2007 at 06:55:10PM +1000, Anthony Towns wrote:
> aj, who'd just like to see some failure analysis / air crash investigation
> type conclusions out of this, rather than just "foo sucks and
> shouldn't upload"
 
One thing we could do is have a seperate report on
http://lintian.debian.org which lists all the lintian overrides (maybe
only those for errors, not for warnings), so they can be peer reviewed
by interested people. 

Another thing we could do is alert sponsors about checking for lintian
overrides when they review a package.


Michael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: linhdd concerns

[Daniel Baumann]

[ late, but for the records. ]

Kartik Mistry wrote:
> linhdd introduce binary abs_fdisk which was modified copy of fdisk
> from new version 0.4. It was arch:all before that too, and previous
> maintainer set it to arch:all saying 'it will save achieve space'.

hu?? the previous maintainer, me, did set arch all because the package
*was* arch all only, it did not contain any architecture depended data
at all- it is just a script (up to 0.3-3; no clue what you/upstream did
afterwards).

> As suggested to me, I did removal of linhdd. To fix this bug, we have
> to build util-linux and I think its too much and probably wrong to
> have fdisk stay in /usr/bin.

why not just having uploaded the last sane version with an epoche? then,
you could have took your time to fix the 0.4 version properly.. it's bad
to see 'my' package go just because of that..

-- 
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:  [EMAIL PROTECTED]
Internet:   http://people.panthera-systems.net/~daniel-baumann/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: linhdd concerns

[Bas Wijnen]

On Mon, Nov 26, 2007 at 11:38:06PM -0800, Steve Langasek wrote:
> On Mon, Nov 26, 2007 at 09:51:35PM +0100, Leo costela Antunes wrote:
> > What information does linhdd need from fdisk?
> > Fdisk seems to run just fine as a normal user on Debian. The issues
> > seems to be that /dev/{s,h}d* are directly readable only by members of
> > the group 'disk'.
> > Perhaps instead of packaging this 'abs_fdisk', which AFAICT is just a
> > "read-only non-root" fdisk, you could just create a setuid wrapper to
> > the normal fdisk and use it from linhdd?
> 
> No, that would be a security hole.  Even making it setgid disk would be a
> security hole, since the disk group has write access to all disk devices.

The idea of the wrapper would of course be that it would only allow read
access, so the write access is not a problem.

If I understand the case correctly, abs_fdisk is a modified read-only
setuid root version of fdisk, which is used by linhdd to get some info
which is also available to everyone under /proc.  Providing this info is
obviously not a security problem (as long as abs_fdisk is not buggy).
However, "a read-only version of fdisk" can likely get much more info
than just what is available in /proc.  The fact that linhdd doesn't use
that doesn't make it unavailable.  It seems to me that this approach
introduces security issues (allowing read access that shouldn't be
allowed, plus an extra setuid root (or setgid disk) binary which must
not be buggy) that should better be avoided.

Would it be very hard to write a script which does the same as abs_fdisk
(and can be used as a drop-in replacement), but gets its info from
/proc, and doesn't need elevated permissions?

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: linhdd concerns

[Leo "costela" Antunes]

Steve Langasek wrote:
> No, that would be a security hole.  Even making it setgid disk would be a
> security hole, since the disk group has write access to all disk devices.

I didn't mean a simple wrapper around the binary, I meant a wrapper
around the binary with a specific set of arguments, locking the used to
a single read-only operation (which seems to be what the front end needs).

Now that you mention it, my original thought would still pose a security
threat in case the fdisk could somehow be exploited through the wrapper,
but then again this is precisely the same level of security any other
setuid binary in the system has.

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)

[Anthony Towns]

On Mon, Nov 26, 2007 at 09:44:50PM +0530, Ramakrishnan Muthukrishnan wrote:
> As people have already explained, this is not the first mistake people
> have commited.  And at the same time, I agree that it was a grave
> mistake on my part and I publicly apologize for this mistake. If you
> care to rectify this by removing my account, by all means do so.

Right, and it won't be the last either -- but it seems to me the best 
approach is to prevent similar bugs from happening again.

Unless there's some hidden mass of problems in packages you sponsor (and
I imagine it would've become apparent by now if there were), removing your
account or upload rights or ability to sponsor wouldn't actually be an
improvement.

But there has to be *something* that could reasonably have been done
to avoid this mistake, that you and other sponsors could just make part
of your routine in future so *this* mistake doesn't happen again. I've
suggested some ways that might work, but your thoughts on the matter
would seem much more useful, both since this was your mistake, and
because you're much more actively involved in sponsoring than I am.

Cheers,
aj, who'd just like to see some failure analysis / air crash investigation
type conclusions out of this, rather than just "foo sucks and
shouldn't upload"



signature.asc
Description: Digital signature

Re: linhdd concerns

[Steve Langasek]

On Mon, Nov 26, 2007 at 09:51:35PM +0100, Leo costela Antunes wrote:
> Anthony Towns wrote:
> > Given the description of abs_fdisk on the linhdd site:

> > ] 0.4 release now includes a customized version of fdisk (called
> > ] abs_fdisk). Why? Well, daealing with SATA (scsi) in /proc was a bear --
> > ] and the ease with which fdisk gave me the needed drive info made me wish
> > ] I could use fdisk. Just that on Slackware and Absolute, which I use,
> > ] you can only run fdisk as root. So -- I downloaded util-linux and
> > ] changed the source code for fdisk so that it would not srite anythig
> > ] to drives, just return the drive info. Renamed it abs_fdisk (because I
> > ] wrote it sort of specifically for Absolute Linux, and Eureka!, Use fdisk
> > ] as non-root user safely.

> > makes it sound to me like you should be packaging abs_fdisk separately and
> > having linhdd Depend: on it; or, ideally, getting util-linux patched so
> > its fdisk can support the same features as abs_fdisk.

> What information does linhdd need from fdisk?
> Fdisk seems to run just fine as a normal user on Debian. The issues
> seems to be that /dev/{s,h}d* are directly readable only by members of
> the group 'disk'.
> Perhaps instead of packaging this 'abs_fdisk', which AFAICT is just a
> "read-only non-root" fdisk, you could just create a setuid wrapper to
> the normal fdisk and use it from linhdd?

No, that would be a security hole.  Even making it setgid disk would be a
security hole, since the disk group has write access to all disk devices.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: linhdd concerns

[Leo "costela" Antunes]

Anthony Towns wrote:
> Given the description of abs_fdisk on the linhdd site:
> 
> ] 0.4 release now includes a customized version of fdisk (called
> ] abs_fdisk). Why? Well, daealing with SATA (scsi) in /proc was a bear --
> ] and the ease with which fdisk gave me the needed drive info made me wish
> ] I could use fdisk. Just that on Slackware and Absolute, which I use,
> ] you can only run fdisk as root. So -- I downloaded util-linux and
> ] changed the source code for fdisk so that it would not srite anythig
> ] to drives, just return the drive info. Renamed it abs_fdisk (because I
> ] wrote it sort of specifically for Absolute Linux, and Eureka!, Use fdisk
> ] as non-root user safely.
> 
> makes it sound to me like you should be packaging abs_fdisk separately and
> having linhdd Depend: on it; or, ideally, getting util-linux patched so
> its fdisk can support the same features as abs_fdisk.

What information does linhdd need from fdisk?
Fdisk seems to run just fine as a normal user on Debian. The issues
seems to be that /dev/{s,h}d* are directly readable only by members of
the group 'disk'.
Perhaps instead of packaging this 'abs_fdisk', which AFAICT is just a
"read-only non-root" fdisk, you could just create a setuid wrapper to
the normal fdisk and use it from linhdd?

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)

[Torsten Werner]

On Nov 26, 2007 5:14 PM, Ramakrishnan Muthukrishnan
<[EMAIL PROTECTED]> wrote:
> If you care to rectify this by removing my account, by all means do so.

I do not like that idea and I have just sponsored an upload for Kartik
because I think he is doing a great job for Debian. I agree that he
was mistaken not asking someone else for help. But that's it.


Cheers,
Torsten

-- 
blog: http://twerner.blogspot.com/
homepage: http://www.twerner42.de/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: linhdd concerns

[Kalle Kivimaa]

Anthony Towns <[EMAIL PROTECTED]> writes:
> ] I could use fdisk. Just that on Slackware and Absolute, which I use,
> ] you can only run fdisk as root. So -- I downloaded util-linux and
>
> makes it sound to me like you should be packaging abs_fdisk separately and
> having linhdd Depend: on it; or, ideally, getting util-linux patched so
> its fdisk can support the same features as abs_fdisk.

No, all you really need to do is to have linhdd depend on util-linux
and use simply "fdisk -l /dev/sda". Works just fine, provided the user
has read rights on the device (and if the user doesn't, it doesn't
matter *which* program tries to read the data).

-- 
* Sufficiently advanced magic is indistinguishable from technology (T.P)  *
*   PGP public key available @ http://www.iki.fi/killer   *


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)

[Ramakrishnan Muthukrishnan]

On Nov 26, 2007 8:57 PM, Anthony Towns <[EMAIL PROTECTED]> wrote:
>
> In this case it's inaction, and it'd be better if you'd acknowledge the
> problem and do what you can to avoid it in future. From the above, it
> seems like when sponsoring packages you're not always:
>
> - testing to see if they work
> - reviewing the changelog with an eye for problems
> - running debdiff to see if anything looks odd
> - agreeing to sponsor packages only when you've got time to review them

aj,

As I already explained, Kartik sent me loads of packages to check for
and almost all the time after afew initial mistakes, he did a good
job, so perhaps I missed looking into this package more closely.

As people have already explained, this is not the first mistake people
have commited. And at the same time, I agree that it was a grave
mistake on my part and I publicly apologize for this mistake. If you
care to rectify this by removing my account, by all means do so.

Ramakrishnan


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)

[Anthony Towns]

On Sat, Nov 24, 2007 at 09:34:21PM +0530, Kartik Mistry wrote:
> > Kartik what possible reason did you have for overriding the lintian
> > error report, rather than changing your package to remove the error?
> linhdd introduce binary abs_fdisk which was modified copy of fdisk
> from new version 0.4. It was arch:all before that too, and previous
> maintainer set it to arch:all saying 'it will save achieve space'.

So first, you're the maintainer of that package now -- if something
the previous maintainer did no longer makes sense because of changes
since then, it's your responsibility to fix that. If you're not sure
whether the old behaviour makes sense, then talk to people about it --
the previous maintainer, your sponsor or AM, debian-mentors, or whatever
else. Better to ask a stupid question early, than upload something broken
to the archive.

Or, well, at least you _were_ the maintainer...

> Since, it was working fine with 0.3, linhdd now depends on modified
> copy of fdisk, abs_fdisk. I fixed this by adding upstream provided
> copy of it.

Right, which also had the bug that abs_fdisk wasn't being built from
source; which could have meant, eg, that the source wasn't complete and
thus couldn't actually be used to build the binary, or that the binary was
trojaned or infected by a virus. Either way it would've meant any security
bugs in the binary would have been difficult to fix because the security
team would need to change your build system as well as patch the source.

> > Did you ask anyone's advice before [introducing the lintian override]?

You haven't answered this.

The lintian error *should* have been enough to give you serious concerns
about what you were doing; if you addressed that by asking for advice,
and got bad advice (or didn't get an answer at all), that's one thing;
if you addressed it by just ignoring the hint (which is what it looks
like), that's a problem that you should be correcting.

> > Why are you asking for the
> > removal of linhdd now (Bug#452629), instead of *fixing* the package,
> > eg, by making the package architecture specific instead of arch:all and
> > either the binary built as part of debian/rules, or simply using the
> > fdisk that's already packaged as part of util-linux?
> As suggested to me, I did removal of linhdd. To fix this bug, we have
> to build util-linux and I think its too much and probably wrong to
> have fdisk stay in /usr/bin.

The social contract says "we will be guided by the needs of our users",
amongst other things. Linhdd obviously has at least one user, based on
Bug#442093 -- wouldn't the needs of the Debian users that have installed
linhdd be better served by fixing the problem, than removing the package?

Fixing the problem you have an RC bug on (452464) would've just required
an upload with Arch:all changed to Arch:i386, and the removal of the
lintian override.

Given the description of abs_fdisk on the linhdd site:

] 0.4 release now includes a customized version of fdisk (called
] abs_fdisk). Why? Well, daealing with SATA (scsi) in /proc was a bear --
] and the ease with which fdisk gave me the needed drive info made me wish
] I could use fdisk. Just that on Slackware and Absolute, which I use,
] you can only run fdisk as root. So -- I downloaded util-linux and
] changed the source code for fdisk so that it would not srite anythig
] to drives, just return the drive info. Renamed it abs_fdisk (because I
] wrote it sort of specifically for Absolute Linux, and Eureka!, Use fdisk
] as non-root user safely.

makes it sound to me like you should be packaging abs_fdisk separately and
having linhdd Depend: on it; or, ideally, getting util-linux patched so
its fdisk can support the same features as abs_fdisk.

Just getting the package removed seems like taking the easy way out to
try to make the issue go away instead of actually fixing the problem
(which is what introducing a lintian override seemed like too)...

Cheers,
aj



signature.asc
Description: Digital signature

Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)

[Anthony Towns]

On Sat, Nov 24, 2007 at 11:22:52PM +0530, Ramakrishnan Muthukrishnan wrote:
> [I did not recieve the original email addressed to me by aj, so I am
> literally "reading between the lines" to digest the original message]

It was sent to your @d.o address, and is in the list archives at:

http://lists.debian.org/debian-project/2007/11/msg00145.html

> >> Ramakrishnan, how did your sponsorship checking miss both this error
> >> and the RC bug (442093) the previous upload introduced by the i386
> >> binary's absence?
> I have tried to catch and feed the lintian and linda errors back to
> Kartik all the time. I really don't know how I missed it. 

Well, it was overriden, so unless you'd use lintian with --show-overrides,
it wouldn't've shown up.

> If I remember right, I did an upload of this package only once. 

You sponsored both the 0.4-1 and 0.4-2 uploads according to the signatures
on the .changes files [0].

AFAICS, there were three places where, as sponsor, you could have picked
this issue up:

- in the 0.4-1 upload, you should have found that the program didn't
  work at all after being built, ie spotted Bug#442093 prior to
  uploading; working more closely with Kartik in solving that bug
  might have avoided including abs_fdisk at all

- in the 0.4-2 upload, you should've seen the changelog entry "added
  abs_fdisk binary" and wondered why a "binary" was being added to an
  arch:all package. Or why it wasn't using fdisk from util-linux.

- in the 0.4-2 upload, you might've looked at the debdiff against
  0.4-1 and noticed the addition of the debian/lintian.override file
  containing:

linhdd: arch-independent-package-contains-binary-or-object ./usr/bin/abs_fdisk

  and asked what was going on.

> Please go ahead with my upload rights removal and also removal from
> debian keyring, if you judje people by just one of their actions.

In this case it's inaction, and it'd be better if you'd acknowledge the
problem and do what you can to avoid it in future. From the above, it
seems like when sponsoring packages you're not always:

- testing to see if they work
- reviewing the changelog with an eye for problems
- running debdiff to see if anything looks odd
- agreeing to sponsor packages only when you've got time to review them

That's only my inference from the results though; maybe you are doing
some or all of the above normally, and just slipped up this time. Or
maybe you have some other technique to catch problems that makes more
sense than the above? 

Removal of your upload rights is one way of avoiding this mistake in
future, but there are lots of other sponsors who could make the same
mistake, and given you sponsor other things, it has a lot of collateral
damage...

Cheers,
aj

[0] [EMAIL PROTECTED]:/srv/ftp.debian.org/queue/done$ gpgv \
--keyring /srv/keyring.debian.org/keyrings/debian-keyring.gpg \
2007/09/06/linhdd_0.4-1_amd64.changes 
gpgv: Signature made Thu Sep  6 11:01:25 2007 MDT using DSA key ID 6A9F3C38
gpgv: Good signature from "Ramakrishnan M <[EMAIL PROTECTED]>"
...

[EMAIL PROTECTED]:/srv/ftp.debian.org/queue/done$ gpgv \
--keyring /srv/keyring.debian.org/keyrings/debian-keyring.gpg \
2007/09/19/linhdd_0.4-2_amd64.changes
gpgv: Signature made Wed Sep 19 10:19:22 2007 MDT using DSA key ID 6A9F3C38
gpgv: Good signature from "Ramakrishnan M <[EMAIL PROTECTED]>"
...



signature.asc
Description: Digital signature

Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)

[Mohammed Adnène Trojette]

On Sun, Nov 25, 2007, Anthony Towns wrote:
> Mohammed and Jaldhar, as advocates (and AM) of Kartik, do you have
> anything to add here?

What I have to add is:
1) Kartik is very reactive in correcting his packages when an error
is found
2) Kartik has not finished NM yet as I have to check (all) his packages;
my advocacy was based on the quality of the packages I've already checked
(linhdd is not one of them) or sponsored

-- 
Mohammed Adnène Trojette


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: linhdd concerns

[Marc 'HE' Brockschmidt]

Gunnar Wolf <[EMAIL PROTECTED]> writes:
> I have sponsored several of Kartik's uploads as well, regarding
> xosview (for which I am the previous maintainer). Some months ago,
> yes, Kartik needed quite a bit of hand-holding. As of now, however, I
> do agree his packaging (on what I have seen - this means, on xosview)
> _is_ of enough quality.

Yay. So he now is skilled enough, but he never remembered the ugly hack
he put in the archive with the help of a sponsor.

> So... Well, I do hope this public flaming regarding the fdisk messup
> is enough to fix the mistake (not minor by any means, but still a
> mistake) he did. Of course, as sponsors we are meant to check the
> uploaded packages do build and work correctly, and as a
> sponsoree/trainee he should be very careful when playing with
> overrides (in most cases, lintian/linda _do_ know best!)...
>
> ...But I do feel he should be given the DM privileges. And, of course,
> Kartik, please keep your eyes open! ;-)

That's a bit weird. He produces a package with a major bug, ignores
*all* hints by lintian and is now rewarded for that by getting upload
permissions? Please consider this my urgent request to remove him from
the DM keyring. Also, perhaps this event is a sign that the current
review process is not perfect yet.

Marc
-- 
BOFH #396:
Mail server hit by UniSpammer.


pgpwToZ0e3nvD.pgp
Description: PGP signature

Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)

[Steve Langasek]

On Sat, Nov 24, 2007 at 09:18:46PM -0600, Gunnar Wolf wrote:
> So... Well, I do hope this public flaming regarding the fdisk messup
> is enough to fix the mistake (not minor by any means, but still a
> mistake) he did.

I think this misses the point.  Giving someone DM privileges is a
declaration that, even if they aren't yet skilled enough to have unfettered
access to upload any package in the archive, they are skilled enough to
maintain their own packages without further supervision.

Not knowing that you shouldn't put compiled binaries in an Architecture: all
package IMHO shows a pretty big gap in one's understanding of policy (this
is after all an RC bug).  But on top of this, taking the further step of
*suppressing* the lintian warning when the lintian warning was right is a
significant lapse in judgement that *hides bugs from view that would
otherwise be readily visible to the project*.  That sort of overconfidence
directly affects our ability as a project to easily audit the work that
maintainers are doing, be they DDs, DMs, or NMs, by subverting our automated
bug detection processes.

I am happy for Kartik's involvement in Debian, he's an active and valuable
contributor and I would like to see him continue on the path towards DDship.
But if we ignore clear evidence of an inconsistency between one's skills and
one's *self-assessment* of those skills, then I think we're optimizing for
the wrong outcome at our peril.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)

[Gunnar Wolf]

Jaldhar H. Vyas dijo [Sat, Nov 24, 2007 at 11:13:29AM -0500]:
> >Mohammed and Jaldhar, as advocates (and AM) of Kartik, do you have
> >anything to add here?
> >
> 
> Mainly I have worked with Kartik on Debian-IN packages and there I
> have no complaints.  Lately, I have been sponsoring some of his
> other packages and on the occasions that I have spotted packaging
> problems (few, and none as bad as this.) Kartik has fixed them and
> not repeated the error.
> 
> As I suggested on IRC yesterday, maybe he should cut down on the
> amount of packages he is maintaining and drop some of the more
> complicated ones but I do think he is capable of maintaining
> packages on his own in general.

I have sponsored several of Kartik's uploads as well, regarding
xosview (for which I am the previous maintainer). Some months ago,
yes, Kartik needed quite a bit of hand-holding. As of now, however, I
do agree his packaging (on what I have seen - this means, on xosview)
_is_ of enough quality.

So... Well, I do hope this public flaming regarding the fdisk messup
is enough to fix the mistake (not minor by any means, but still a
mistake) he did. Of course, as sponsors we are meant to check the
uploaded packages do build and work correctly, and as a
sponsoree/trainee he should be very careful when playing with
overrides (in most cases, lintian/linda _do_ know best!)...

...But I do feel he should be given the DM privileges. And, of course,
Kartik, please keep your eyes open! ;-)

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


pgp4h6WTihtwL.pgp
Description: PGP signature

Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)

[David Moreno Garza]

On Sun, 2007-11-25 at 00:14 +1000, Anthony Towns wrote:
> Mohammed and Jaldhar, as advocates (and AM) of Kartik, do you have
> anything to add here? 

Out of Kartik's NM page:

Application Manager Comments
P&P1: [done] 20070417 
P&P2: [done] 20070529 
T&S1: [done] 20070812 
T&S2: [done] 20071007 
packages checking...

I don't know until what point the NM process can actually be hacked.

--
David Moreno Garza <[EMAIL PROTECTED]> | http://www.damog.net/
 Y es que me gusta tanto tu pelo.



signature.asc
Description: This is a digitally signed message part

Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)

[Ramakrishnan Muthukrishnan]

[I did not recieve the original email addressed to me by aj, so I am
literally "reading between the lines" to digest the original message]

"Kartik Mistry" <[EMAIL PROTECTED]> writes:

>> Ramakrishnan, how did your sponsorship checking miss both this error
>> and the RC bug (442093) the previous upload introduced by the i386
>> binary's absence?

I have tried to catch and feed the lintian and linda errors back to
Kartik all the time. I really don't know how I missed it. If I
remember right, I did an upload of this package only once. 

As a matter of fact, I was a bit overwhelmed by the number of requests
for package uploads from Kartik, so it may have so happened that I did
it by in haste and missed this error. I apologize for the error.  

For the last few sponsored uploads of Kartik, I have only uploaded
festival and associated packages, not linhdd.
 
>> On Fri, Nov 23, 2007 at 06:49:24PM +, Steve McIntyre wrote:
>> > >> dm:[EMAIL PROTECTED]
>> > >> Full name: Kartik Mistry
>> > >I don't know if that was such a good idea, see #452464
>> > Wow, the linhdd package is *special*. Based on initial analysis of
>> > this package, please remove:
>> >  * the DM (Kartik Mistry) from the keyring (he clearly needs to learn
>> >more before he should be allowed to upload directly)
>> >  * the upload rights of the sponsor (Ramakrishnan M
>> ><[EMAIL PROTECTED]>) who uploaded this to incoming without any
>> >suitable level of checking. This is a *much* more important problem
>> >IMHO.

Please go ahead with my upload rights removal and also removal from
debian keyring, if you judje people by just one of their actions.

Thanks
-- 
Ramakrishnan


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)

[Jaldhar H. Vyas]

On Sun, 25 Nov 2007, Anthony Towns wrote:



Mohammed and Jaldhar, as advocates (and AM) of Kartik, do you have
anything to add here?



Mainly I have worked with Kartik on Debian-IN packages and there I have no 
complaints.  Lately, I have been sponsoring some of his other packages and 
on the occasions that I have spotted packaging problems (few, and none as 
bad as this.) Kartik has fixed them and not repeated the error.


As I suggested on IRC yesterday, maybe he should cut down on the amount of 
packages he is maintaining and drop some of the more complicated ones but 
I do think he is capable of maintaining packages on his own in general.


--
Jaldhar H. Vyas <[EMAIL PROTECTED]>
La Salle Debain - http://www.braincells.com/debian/


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)

[Kartik Mistry]

On Nov 24, 2007 7:44 PM, Anthony Towns <[EMAIL PROTECTED]> wrote:
> Hi Ramakrishnan, Mohammed, Jaldhar, Kartik,

Hi all,

Please read me inline.

> It's been pointed out that Kartik's latest upload of linhdd has included
> an i386 binary in arch:all package, and explicitly overriden the lintian
> warning for it (see the mail quoted below). That seems pretty dodgy.

Yes. Its pretty bad. I agree. And deeply apologize.

> Kartik what possible reason did you have for overriding the lintian
> error report, rather than changing your package to remove the error?

linhdd introduce binary abs_fdisk which was modified copy of fdisk
from new version 0.4. It was arch:all before that too, and previous
maintainer set it to arch:all saying 'it will save achieve space'.

Since, it was working fine with 0.3, linhdd now depends on modified
copy of fdisk, abs_fdisk. I fixed this by adding upstream provided
copy of it.

> Did
> you ask anyone's advice before doing so? Why are you asking for the
> removal of linhdd now (Bug#452629), instead of *fixing* the package,
> eg, by making the package architecture specific instead of arch:all and
> either the binary built as part of debian/rules, or simply using the
> fdisk that's already packaged as part of util-linux?

As suggested to me, I did removal of linhdd. To fix this bug, we have
to build util-linux and I think its too much and probably wrong to
have fdisk stay in /usr/bin.

> Ramakrishnan, how did your sponsorship checking miss both this error
> and the RC bug (442093) the previous upload introduced by the i386
> binary's absence?
>
> Mohammed and Jaldhar, as advocates (and AM) of Kartik, do you have
> anything to add here?
>
> For the record, Ramakrishnan also seems to have sponsored uploads of the
> following packages for Kartik that are still present in the archive:
> of festival, festival-doc, fontypython, speech-tools, tagtool, and
> uni2ascii. His only other sponsored upload still in the archive is kpsk
> 1.0.1-3 in sarge for Sebastian Muszynski.
>
> Kartik is listed as maintainer of:
>
>  aspell-gu  | Kartik Mistry <[EMAIL PROTECTED]>
>  ayttm  | Kartik Mistry <[EMAIL PROTECTED]>
>  bake   | Kartik Mistry <[EMAIL PROTECTED]>
>  blast  | Kartik Mistry <[EMAIL PROTECTED]>
>  chmlib | Kartik Mistry <[EMAIL PROTECTED]>
>  clara  | Kartik Mistry <[EMAIL PROTECTED]>
>  dvdrtools  | Kartik Mistry <[EMAIL PROTECTED]>
>  festival   | Kartik Mistry <[EMAIL PROTECTED]>
>  festival-doc   | Kartik Mistry <[EMAIL PROTECTED]>
>  fontypython| Kartik Mistry <[EMAIL PROTECTED]>
>  freetalk   | Kartik Mistry <[EMAIL PROTECTED]>
>  gnome-specimen | Kartik Mistry <[EMAIL PROTECTED]>
>  gtkdiskfree| Kartik Mistry <[EMAIL PROTECTED]>
>  kphotobymail   | Kartik Mistry <[EMAIL PROTECTED]>
>  ldtp   | Kartik Mistry <[EMAIL PROTECTED]>
>  ldtp-doc   | Kartik Mistry <[EMAIL PROTECTED]>
>  libyahoo2  | Kartik Mistry <[EMAIL PROTECTED]>
>  linhdd | Kartik Mistry <[EMAIL PROTECTED]>
>  mpy-svn-stats  | Kartik Mistry <[EMAIL PROTECTED]>
>  pygtkmvc   | Kartik Mistry <[EMAIL PROTECTED]>
>  pyslide| Kartik Mistry <[EMAIL PROTECTED]>
>  recoll | Kartik Mistry <[EMAIL PROTECTED]>
>  scanmem| Kartik Mistry <[EMAIL PROTECTED]>
>  sitecopy   | Kartik Mistry <[EMAIL PROTECTED]>
>  speech-tools   | Kartik Mistry <[EMAIL PROTECTED]>
>  tagtool| Kartik Mistry <[EMAIL PROTECTED]>
>  tepache| Kartik Mistry <[EMAIL PROTECTED]>
>  uni2ascii  | Kartik Mistry <[EMAIL PROTECTED]>
>  xchm   | Kartik Mistry <[EMAIL PROTECTED]>
>  xmms-crossfade | Kartik Mistry <[EMAIL PROTECTED]>
>  xmountains | Kartik Mistry <[EMAIL PROTECTED]>
>  xosview| Kartik Mistry <[EMAIL PROTECTED]>
>
> On Fri, Nov 23, 2007 at 06:49:24PM +, Steve McIntyre wrote:
> > >> dm:[EMAIL PROTECTED]
> > >> Full name: Kartik Mistry
> > >I don't know if that was such a good idea, see #452464
> > Wow, the linhdd package is *special*. Based on initial analysis of
> > this package, please remove:
> >  * the DM (Kartik Mistry) from the keyring (he clearly needs to learn
> >more before he should be allowed to upload directly)
> >  * the upload rights of the sponsor (Ramakrishnan M
> ><[EMAIL PROTECTED]>) who uploaded this to incoming without any
> >suitable level of checking. This is a *much* more important problem
> >IMHO.
> >  * the package itself
> > The package contains an i386 binary (abs_fdisk)in a binary-all
> > package, directly installed from a binary that comes in the upstream
> > source packages. To accompany that, there are the following
> > highlights:
> >  * a README.Debian stating
> >   "linhdd also has binary called 'abs_fdisk' which is used for linhdd
> >working correctly. util-linux is provided for its source.
> >   "To save archive space, the package is set to Architecture:
> >all. Please do not report this as a bug on the mentioned
> >architectures.