Bug Squashing in Sydney, November 27th to 28th

[Anand Kumria]

Folks, we can't let the Debian developers in Germany have all the fun
and glory.  If you are in or around Sydney, let's beat them to the
punch and close out as many bugs as we can.

Objectives:
---

Close as many RC bugs before the Frankfurt BSP and help get sarge out
the door.

Much of the Sydney-based Debian cabal will be in attendence. Perfect
opportunity to become a Debian maintainer. Or get you key signed.

Attendance:
---

In addition to the local Debian crowd, we invite other Debian people
in the area to join in either in person or virtually.  Please let us
know if you want to attend the meeting, so we can plan ahead a bit.
Please contact Matt Hope <[EMAIL PROTECTED]> or myself or just reply to
the debian-au list.

Location:
-

University of New South Wales
Computer Science and Engineering (CSE) Building 
Sydney, NSW, Australia

http://www.slug.org.au/events/cse.html>

Equipment:
--

Network connectivity should be okay, there should also be wireless too.
Remember to bring your own tin cans, string and ethernet cable. A power
board may make you a god among geeks. There is a full ftp.debian.org 
mirror onsite. There is also a beach nearby.

Thanks:
---

Thanks to Craige for doing the organising and Dave and Matt for
assistance with UNSW. If I've forgotten to mention anyone the
only way to make me remember who you are is to come along.

Cheers,
Anand

-- 
linux.conf.au 2005   -  http://lca2005.linux.org.au/  -  Birthplace of Tux
April 18th to 23rd   -  http://lca2005.linux.org.au/  -   LINUX
Canberra, Australia  -  http://lca2005.linux.org.au/  -Get bitten!


signature.asc
Description: Digital signature

Re: Introducing pmount in Debian / New plugdev group

[Anand Kumria]

On Tue, 09 Nov 2004 19:32:38 +0100, Marco d'Itri wrote:

> On Nov 09, Martin Pitt <[EMAIL PROTECTED]> wrote:
> 
>> We solved (4) by introducing a new group called 'plugdev'. Every user
>> who is a member of this group can access hotpluggable devices (digital
>> cameras, USB drives etc.). pmount can only be executed by members of
>> this group (it is root:plugdev 750), hal runs in this group to be able
>> to detect file systems (but it does not run in 'disk'), and udev assigns
>> the 'plugdev' group to removable devices (static drives remain in group
>> 'disk').
> I'm not sure about what I should do as the udev maintainer. The default
> udev configuration does not really know for sure if a given device is
> removable.

Initially I was going to suggest you'd know because of the bus-type but I
suspect that even that may not be enough (SATA IDE devices: removable or
not; PCI-X cards: removable or not)

I'd assume that all storage can come and go 'at whim'.

Anand
-- 
linux.conf.au 2005   -  http://lca2005.linux.org.au/  -  Birthplace of Tux
April 18th to 23rd   -  http://lca2005.linux.org.au/  -   LINUX
Canberra, Australia  -  http://lca2005.linux.org.au/  -Get bitten!

Re: I am still on the keyring. With my old key.

[Anand Kumria]

Hi Henning,

On Mon, Nov 21, 2005 at 02:18:02AM +0100, Henning Makholm wrote:
> Scripsit Martijn van Oosterhout <[EMAIL PROTECTED]>
> 
> > "push aside"? There's no rule that says there can be only one. Yes,
> > replacing someone could become ugly, but providing additional hands
> > can't be considered bad, can it?
> 
> It can be considered bad from a technical viewpoint - as far as I
> understand the master copy of the keyring is currently on a medium
> that is under the keyring maintainer's direct physical control.
>
> The "obvious" way of switching to team maintenance of the keyring
> would entail keeping the master copy in a central machine - for
> example on a debian.org box somewhere in a colo. Doing that in a way
> that does not leave the keyring more vulnerable to surreptitious
> compromise than some reasonable persons might prefer, requires
> software support that does not currently exist.
> 
> If somebody designs and implements (after a suitable architectural
> review) some software to support distributed keyring maintenance in a
> secure, auditable way, it is likely that calls for adding more people
> to the task would be considered more seriously.

This is an interesting technical position but one that I think is
incorrect.

The [EMAIL PROTECTED] is to add, update and remove keys in the
keyring.  Generally both the add and remove functions should be done 
after being directed to -- either via a GR or from the Debian Account
Maintainers (DAM)s, or in the case of removal once a developer has
resigned -- not on their own accord.

This leaves the update function, which has a number of components:
- update the signature set of existing keys (simple)

Poll the various public keyservers to for each key existing
on the keyring.

- migrate a developer from current to emeritus and vice versa (medium)

I would assume that this also occurs upon the
instructions of some other entity, either QA, the
developer themself, via GR, etc.

- replace an existing (compromised, lost) key with a new one
  (hard)

This seem to be the problematic function.

This is hard because the solution it isn't just technical 
(like the first), nor social (like the second) but a 
combination of them both.

One solution might be:
- require the developer to generate a new key
- require the developer to have _at least_ N
  number of other, existing developers sign
  their key
- once the developer submits their new key,
  the keyring-maint can select M of the N
  signatures from existing developers and ask
  them to further assure keyring-maint that the
  developer in question is who they say they
  are.
- once that check passes, update the keyring.

I would suggest that M be 2 and N be 3.

> > Anyway, ISTM that removing keys from a keyring is much more important
> > than adding new ones, right?
> 
> It is also more difficult to implement in a secure distributed way.
> Anybody can think up a scheme for using gpg signatures to prevent keys
> from being added without authorisation in the first place. Making sure
> that a removed key stays removed is a more complex question -
> particularly if emergency powers-to-remove just get kludged onto the
> existing system as an afterthought.

As I have indicated above, I do not believe the role of keyring-maint is
to make *any* decision but to act upon the instructions of other parts
of Debian (QA, DAM, tech-ctte, DPL(s), DDs via GR).

Ideally the role of keyring-maint can be useful performed by a script
but since the set of entities who could instruct the keyring-maint is
large it would probably make sense to have a number of humans fronting
that script.

Cheers,
Anand

-- 
 `When any government, or any church for that matter, undertakes to say to
  its subjects, "This you may not read, this you must not see, this you are
  forbidden to know," the end result is tyranny and oppression no matter how
  holy the motives' -- Robert A Heinlein, "If this goes on --"


signature.asc
Description: Digital signature

Re: gtk-gnutella

[Anand Kumria]

On Sun, Dec 04, 2005 at 06:34:18PM +0100, Andreas Barth wrote:
> * Anand Kumria ([EMAIL PROTECTED]) [051124 04:40]:
> > <http://www.progsoc.org/~wildfire/debian/gtk-gnutella/gtk-gnutella-0.95to0.96b.diff>
> > 
> > It's 18MiB of unified diff goodness.
> > 
> > Far larger than 2.5MiB gtk-gnutella 0.96b the updated source release is.
> 
> You don't really expect that we can accpet such massive changes in
> volatile? 

Yes, I do, otherwise I wouldn't have spent any time discussing it.

> Besides, BTW, the changelog is *really* broken (and also the
> general packaging - I probably should as QA member do a package review
> soon ...).

Great, I look forward to your bugreports.  But this is a side-issue
completely unrelated to whether or not gtk-gnutella should be in
backports.

> Basically, if you want to do a normal backport, speak with the
> backport.org-people. 

This isn't a backport.  Here is a hypothetical situation:
- you provide a web browser which does http 0.9
- all existing web servers and web browser in the meantime are
  upgraded to only speak http/1.1
- the web browser you provide now does http 1.1
- the protocol (for both servers and clients) changes more
  frequently than a Debian release

This is the situation I find myself in with gtk-gnutella.  Generally,
the program will release with a version of the client code that
interoperates with the rest of the network.

Over time, the rest of the network changes and decides that gtk-gnutella
(in Debian 3.1) is hostile -- in this case 0.95 is performing a DoS against 
other clients.

> Perhaps it is possible to send out a mail to the
> volatile-announce-list that gtk-gnutella doesn't really work anymore and
> people should look for backports (and also name one or more locations),
> but there is no way to accept the package as it is currently in
> volatile.

From your email the only reasons you've given are:
- it's a massive change
- you don't like the changelog

Is that a fair summary?

Anand

-- 
 `When any government, or any church for that matter, undertakes to say to
  its subjects, "This you may not read, this you must not see, this you are
  forbidden to know," the end result is tyranny and oppression no matter how
  holy the motives' -- Robert A Heinlein, "If this goes on --"


signature.asc
Description: Digital signature

congratulations to our ftp-master team

[Anand Kumria]

I'd like to congratulate our ftp-master team on their ability to timely
process packages progressing through the NEW queue.

 [1]

I think you are an excellent example of people who are too busy for Debian.

I must say that I am particularly impressed that you've managed to
frustrate our users for over 1 year with the package 'xvidcap'.

Truly the works of Gods among both Debian users _and_ Debian developers.

If only more of the infrastructure teams displayed your attitude and
dedication to volunteering for the benefit of all Debian users and
developers.

Oh.



As this post indicates, it isn't just the ftp-master team failing Debian.



From the current issues list, most infrastructure teams seems incapable
of acting in any kind of reasonable timeframe.

Either that or the high concentration of particularly reticient
individuals is the problem. Something like that.

Perhaps we should just recall the DPL, change the structure of Debian so
it is an appointed board and appoint those already acting in a
dictatorial manner to it.  It'd be better to outline what current reality
is rathing than continuing with our current charade.

Thanks,
Anand

[1]: As I write this 79 NEW packages, 85 total.



signature.asc
Description: Digital signature

Re: congratulations to our ftp-master team

[Anand Kumria]

On Wed, Dec 14, 2005 at 09:30:15AM +, David Pashley wrote:
> On Dec 14, 2005 at 00:25, Anand Kumria praised the llamas by saying:
> > I'd like to congratulate our ftp-master team on their ability to timely
> > process packages progressing through the NEW queue.
> > 
> > <http://ftp-master.debian.org/new.html> [1]
> > 
> > I think you are an excellent example of people who are too busy for Debian.
> > 
> > I must say that I am particularly impressed that you've managed to
> > frustrate our users for over 1 year with the package 'xvidcap'.
> > 
> > Truly the works of Gods among both Debian users _and_ Debian developers.
> > 
> > If only more of the infrastructure teams displayed your attitude and
> > dedication to volunteering for the benefit of all Debian users and
> > developers.
> > 
> 2875   + Dec 13 18:17   Debian Installer  (   0) irssi_0.8.10-1_multi.changes 
> is NEW
> 2876   + Dec 13 23:48   Debian Installer  (   0) irssi_0.8.10-1_multi.changes 
> ACCEPTED
> 
> 5.5 hours for a package to make it through NEW. I think you owe some people 
> an apology.
> 

-> 8126   T Oct 25 Debian Installe (  46) xmovie_1.9.13-0_i386.changes is NEW
   10552   T Dec 14 Joerg Jaspert   (  23) xmovie_1.9.13-0_i386.changes REJECTED

How many hours is that, David?

Anand

-- 
 `When any government, or any church for that matter, undertakes to say to
  its subjects, "This you may not read, this you must not see, this you are
  forbidden to know," the end result is tyranny and oppression no matter how
  holy the motives' -- Robert A Heinlein, "If this goes on --"


signature.asc
Description: Digital signature

Re: congratulations to our ftp-master team

[Anand Kumria]

On Fri, Dec 16, 2005 at 03:56:30PM +0100, Goswin von Brederlow wrote:
> Anand Kumria <[EMAIL PROTECTED]> writes:
> 
> > I'd like to congratulate our ftp-master team on their ability to timely
> > process packages progressing through the NEW queue.
> >
> > <http://ftp-master.debian.org/new.html> [1]
> >
> > I think you are an excellent example of people who are too busy for Debian.
> >
> > I must say that I am particularly impressed that you've managed to
> > frustrate our users for over 1 year with the package 'xvidcap'.
> 
> Guessing by the name alone I would say this is a patent issue like
> mplayer and therefore a problem package that is not likely to get
> resolved anytime soon.
> 
> But that is just a guess.

And it is an incorrect guess. xvidcap itself uses libraries already in
Debian. But thanks for playing "guess the mind of the ftp-masters".

Was it fun?

> For non problem cases the NEW queue was never as fast as now so
> congratulation of improving the NEW queue so much already. Giving your
> past month performance I'm sure the few remaining issues can be
> resolved in time as well. Ignoring anything 2 weeks or newer I count
> only 7 packages. This is great.

Maybe you are a fan of being left in limbo, or like the perverbial
Schrödinger's cat, but even a bad process can benefit from assurances.

A simple assurance that your package will be rejected from the NEW queue
if no ftp-master approves it within 2 weeks would actually be a benefit.

Anand

-- 
 `When any government, or any church for that matter, undertakes to say to
  its subjects, "This you may not read, this you must not see, this you are
  forbidden to know," the end result is tyranny and oppression no matter how
  holy the motives' -- Robert A Heinlein, "If this goes on --"


signature.asc
Description: Digital signature

Re: congratulations to our ftp-master team

[Anand Kumria]

On Wed, Dec 21, 2005 at 03:21:07PM +0100, Goswin von Brederlow wrote:
> Anand Kumria <[EMAIL PROTECTED]> writes:
> 
> > On Fri, Dec 16, 2005 at 03:56:30PM +0100, Goswin von Brederlow wrote:
> >> Anand Kumria <[EMAIL PROTECTED]> writes:
> >> 
> >> > I'd like to congratulate our ftp-master team on their ability to timely
> >> > process packages progressing through the NEW queue.
> >> >
> >> > <http://ftp-master.debian.org/new.html> [1]
> >> >
> >> > I think you are an excellent example of people who are too busy for 
> >> > Debian.
> >> >
> >> > I must say that I am particularly impressed that you've managed to
> >> > frustrate our users for over 1 year with the package 'xvidcap'.
> >> 
> >> Guessing by the name alone I would say this is a patent issue like
> >> mplayer and therefore a problem package that is not likely to get
> >> resolved anytime soon.
> >> 
> >> But that is just a guess.
> >
> > And it is an incorrect guess. xvidcap itself uses libraries already in
> > Debian. But thanks for playing "guess the mind of the ftp-masters".
> >
> > Was it fun?
> 
> Yes and I guessed right it seems.

I think you've been smoking too much.

> The ffmpeg library in debian is a problem case and probably should not
> be in there. That issue hasn't been decided yet and till then anything
> using it stays stuck.

Really? Excellent then. I would expect that gstreamer0.10-ffmpeg, 
recently uploaded, to be stuck in NEW for a year (at least) then.

If it isn't then your theory is wrong.

What you are saying that is that a sceanario such as:
- a company (e.g. Unisys) asserting a patent on 
- a file format (e.g. GIF) which has 
- a library (e.g. libgif) which is used by
- an application (e.g. gimp)

should result in further uploads of the gimp being held indefinately in
the NEW queue until such time as any perceived library patent problem is
resolved.

I'd argue that either:
- the library, and all dependant program be removed from the
  archive
- that applications merely linked to the library be allowed in
  but that the library maintainer be asked to remove the
  offending code

In the spirit of Anthony's blog entry [1], I've CC'd him for an informal
opinion about that.

> >> For non problem cases the NEW queue was never as fast as now so
> >> congratulation of improving the NEW queue so much already. Giving your
> >> past month performance I'm sure the few remaining issues can be
> >> resolved in time as well. Ignoring anything 2 weeks or newer I count
> >> only 7 packages. This is great.
> >
> > Maybe you are a fan of being left in limbo, or like the perverbial
> > Schrödinger's cat, but even a bad process can benefit from assurances.
> >
> > A simple assurance that your package will be rejected from the NEW queue
> > if no ftp-master approves it within 2 weeks would actually be a benefit.
> 
> And would result in mplayer being uploaded again and again everytime
> someone forgets it was there before.
> 
> Beter to have it stuck but documented why.

Surely it be better to document that in the REJECT FAQ that a package:
- with a particular name 
- or linked to a particular library
- isn't likely to be looked at prior to autoREJECT occuring

Then it wouldn't even be stuck.

Anand

[1]: http://azure.humbug.org.au/~aj/blog/2005/12/11

-- 
 `When any government, or any church for that matter, undertakes to say to
  its subjects, "This you may not read, this you must not see, this you are
  forbidden to know," the end result is tyranny and oppression no matter how
  holy the motives' -- Robert A Heinlein, "If this goes on --"


signature.asc
Description: Digital signature

spohr.debian.org not sending email

[Anand Kumria]

Hi,

There seems to be a problem, localised to spohr, with the sending of
emails. I've uploaded some packages recently and have neither received
the acceptance nor rejection emails (as expected) however some packages
have been accepted since they are currently auto-building.

I've tested various others Debian infrastructure machines and no other
appears to have an issue.  I've not seen anything mentioning this issue
(hence the CC to debian-devel in case anyone else is experiencing the
problem).

Please take a look at see what is happening for the domains:
progsoc.uts.edu.au and progsoc.org

Thanks,
Anand

-- 
 `When any government, or any church for that matter, undertakes to say to
  its subjects, "This you may not read, this you must not see, this you are
  forbidden to know," the end result is tyranny and oppression no matter how
  holy the motives' -- Robert A Heinlein, "If this goes on --"


signature.asc
Description: Digital signature

Re: timezone data packaged separately and in volatile?

[Anand Kumria]

On Thu, Feb 02, 2006 at 11:42:31PM +0100, Lionel Elie Mamane wrote:
> Hi,
> 
> I just realised that the timezone data in glibc is taken from an
> upstream database (namely ftp://elsie.nci.nih.gov/pub/). This data
> sometimes changes, more rapidly than our release cycle (and than any
> release cycle we can reasonable have).

But that doesn't mean that we can issue an update to a stable package.

Currently they are mainly done for security purposes -- but stable updates 
should not be confined to only that.  They should be done to keep the
system functional.

I also think volatile is precisely the wrong place to put this kind of 
data -- it isn't part of the default apt.sources for one thing; and it 
places an extra burden on the maintainer(s) (who know have to track
three different upgrade paths, etc.).

It would be good to hear from the glibc maintainers if there are any
issues addressing bugs such as: 345479, 351049 with an update for
stable.

Thanks,
Anand

-- 
 `When any government, or any church for that matter, undertakes to say to
  its subjects, "This you may not read, this you must not see, this you are
  forbidden to know," the end result is tyranny and oppression no matter how
  holy the motives' -- Robert A Heinlein, "If this goes on --"


signature.asc
Description: Digital signature

Re: timezone data packaged separately and in volatile?

[Anand Kumria]

On Tue, Feb 07, 2006 at 09:13:07AM +0100, Andreas Barth wrote:
> * Anand Kumria ([EMAIL PROTECTED]) [060207 04:34]:
> > I also think volatile is precisely the wrong place to put this kind of 
> > data -- it isn't part of the default apt.sources for one thing; and it 
> > places an extra burden on the maintainer(s) (who know have to track
> > three different upgrade paths, etc.).
> 
> Only because you have a prejudice against volatile doesn't mean its the
> wrong place. Volatile is rather the exactly right place for this kind of
> update.

It is precisely the wrong place because volatile isn't in
apt.sources by default. If it were, it'd be a different story.

As it is, volatile is a great solution in search of a problem.  It is 
unfortunate that you, and others, seem to latch onto things like as a 
reason to make volatile useful.

The underlying technical issue that volatile is working around is that the 
stable release manager isn't interested in ensuring that a stable release is
both functional and secure (btw: has anyone asked him to confirm this?;
I'm just working on the 'general assumptions' here).

These goals are not inherently opposed to each other.  I'd rather work
through the existing stable release process first, then resort to a
work-around.

Anand

-- 
 `When any government, or any church for that matter, undertakes to say to
  its subjects, "This you may not read, this you must not see, this you are
  forbidden to know," the end result is tyranny and oppression no matter how
  holy the motives' -- Robert A Heinlein, "If this goes on --"


signature.asc
Description: Digital signature

Re: timezone data packaged separately and in volatile?

[Anand Kumria]

[ debian-volatile dropped ]

Hi Daniel,

On Mon, Feb 06, 2006 at 11:41:26PM -0500, Daniel Jacobowitz wrote:
> On Tue, Feb 07, 2006 at 02:30:01PM +1100, Anand Kumria wrote:
> > But that doesn't mean that we can issue an update to a stable package.
> > 
> > Currently they are mainly done for security purposes -- but stable updates 
> > should not be confined to only that.  They should be done to keep the
> > system functional.
> > 
> > I also think volatile is precisely the wrong place to put this kind of 
> > data -- it isn't part of the default apt.sources for one thing; and it 
> > places an extra burden on the maintainer(s) (who know have to track
> > three different upgrade paths, etc.).
> > 
> > It would be good to hear from the glibc maintainers if there are any
> > issues addressing bugs such as: 345479, 351049 with an update for
> > stable.
> 
> It's not us, but the stable maintainer, that you'd have to talk to;
> he has traditionally not been interested in these sorts of updates to
> stable as far as I know.

Well, perhaps a first start is creating the package for stable-updates;
would it be easier for you if I created a diff or would you rather do it
yourself?

Once a package is available we can start talking to the stable release
manager to see what his position is.

Anand

-- 
 `When any government, or any church for that matter, undertakes to say to
  its subjects, "This you may not read, this you must not see, this you are
  forbidden to know," the end result is tyranny and oppression no matter how
  holy the motives' -- Robert A Heinlein, "If this goes on --"


signature.asc
Description: Digital signature

Re: timezone data packaged separately and in volatile?

[Anand Kumria]

On Tue, Feb 07, 2006 at 09:57:54AM +0100, Andreas Barth wrote:
> * Anand Kumria ([EMAIL PROTECTED]) [060207 09:52]:
> > On Tue, Feb 07, 2006 at 09:13:07AM +0100, Andreas Barth wrote:
> > > * Anand Kumria ([EMAIL PROTECTED]) [060207 04:34]:
> > > > I also think volatile is precisely the wrong place to put this kind of 
> > > > data -- it isn't part of the default apt.sources for one thing; and it 
> > > > places an extra burden on the maintainer(s) (who know have to track
> > > > three different upgrade paths, etc.).
> > > 
> > > Only because you have a prejudice against volatile doesn't mean its the
> > > wrong place. Volatile is rather the exactly right place for this kind of
> > > update.
> > 
> > It is precisely the wrong place because volatile isn't in
> > apt.sources by default. If it were, it'd be a different story.
> 
> You mean, we better don't do anything than to accept packages into a
> repository that is actually in apt.sources on a lot of machines, even on
> the debian.org-machines?

I don't understand your English, perhaps you could rephrase or clarify?

> > As it is, volatile is a great solution in search of a problem.  It is 
> > unfortunate that you, and others, seem to latch onto things like as a 
> > reason to make volatile useful.
> 
> You mean, like accepting a new locale package into volatile? Ah, that's
> you who don't like it.

Again, those statements don't make any sense to me.  Either by
themselves or in the context my what you've quoted. Could you rephrase
or clarify.

Thanks,
Anand

-- 
 `When any government, or any church for that matter, undertakes to say to
  its subjects, "This you may not read, this you must not see, this you are
  forbidden to know," the end result is tyranny and oppression no matter how
  holy the motives' -- Robert A Heinlein, "If this goes on --"


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

Re: Problems found by piuparts

[Anand Kumria]

Hi Lars,

On Mon, Feb 20, 2006 at 08:24:53AM +0200, Lars Wirzenius wrote:
> 
> * Creating /usr/local/lib/foo in postinst, but not removing it
> in postrm.

I don't think that is a problem at all; the administrator ought to feel
free to be able to put things in (say) /usr/local/lib/firmware and not
have to worry that a full purge / install of the package which happened
to create that directory will wipe out things there.

Anand

-- 
 `When any government, or any church for that matter, undertakes to say to
  its subjects, "This you may not read, this you must not see, this you are
  forbidden to know," the end result is tyranny and oppression no matter how
  holy the motives' -- Robert A Heinlein, "If this goes on --"


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

Re: More polls and social pressure

[Anand Kumria]

On Wed, Feb 22, 2006 at 09:43:23AM +0100, Raphael Hertzog wrote:
> [ Reply-to debian-project ]

reply-to, ignored since I feel this is important enough that both lists
should see this reponse.

> 
> Hi everybody,
> 
> In the light of recent events, those polls could be used to give a physical
> reality to the social peer pressure that should exist on our mailing lists
> (and maybe avoid going straight to extreme solutions):

[...]

> The result of the polls could eventually be used by the listmasters to
> take action if needed. 

There is a better way.

As some of you may be aware, the listmasters use feedback to gauge the
desirability / utility of new lists.  Likewise while the listmasters
monitor the general 'health' of the lists (ebb/flow, posting frequency,
etc.), that doesn't necessarily mean they have read everything (although
Pascal certainly tries).

So, if you feel a particular post was inappropriate / out-of-line bring
it to the attention of [EMAIL PROTECTED]

> This is a civilized way to define what *must change* and what is ok. 

It is certainly *a* way but I'd hesitate to call it civilised; public
non-secret ballots are frequently used in mafia-like organisations.  
And also within governments too.

> The current limitation is that we probably ought to open the votes to a
> larger group than the DD but we might start with DD only and check out the
> results.

If people who have a problem, let [EMAIL PROTECTED] know, they 
don't even need to be in the new-maintainer queue to be heard.  Even
your pet dog can complain![1]

Anand

[1]: On the Internet, no one knows that you're a dog
 

-- 
 `When any government, or any church for that matter, undertakes to say to
  its subjects, "This you may not read, this you must not see, this you are
  forbidden to know," the end result is tyranny and oppression no matter how
  holy the motives' -- Robert A Heinlein, "If this goes on --"


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

Re: http mirror (was Re: New APT Version)

[Anand Kumria]

On Tue, 7 Apr 1998, Steve Hsieh wrote:

> On 5 Apr 1998, Jason Gunthorpe wrote:
> 
> > > Oh I'm all for switching to HTTP. Can we convince all our mirrors to
> > > switch?
> >
> > I'm going through the mirror list and building a sources.list of all the
> > possible sources. I have 8 sites already
> 
> 
> I have enabled http transfers on our mirror as well...
>http://linux.eecs.umich.edu/pub/linux/debian
> 

As have I ...

http://ftp.progsoc.uts.edu.au/pub/Linux/debian-non-US/

Anand.


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

Re: Coming to closure on ae...

[Anand Kumria]

On Sat, 2 May 1998, Dale Scheetz wrote:

> There doesn't seem to be a "reliable" method for determining whether or
> not you are in an xterm. Any method so far suggested has "natural" 
> configuration situations that break the method.

  How about just checking for the existance of the DISPLAY variable?

Anand.


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

Re: Coming to closure on ae...

[Anand Kumria]

On Wed, 6 May 1998, Anand Kumria wrote:

[snip]

I guess I should learn to read faster since it has already been mentioned
many times.

Anand


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

newbie comments

[Anand Kumria]

I just recently had the chance to install, and help a few Linux newbie's 
install Debian. My comments pertain to 0.93R6 available on FTP sites. 
Overall we liked it, better than Yggdrasil, and slightly better than 
Slackware (though I put that down to familiarity). 

The new users I help install Debian found the interface change between 
the main install script and the timezone and partition sections a bit 
disorienting. Perhaps they can be dressed up like Slackware?

Also, we found the copy of curses, or ncurses, "ruined" dselect's screen, 
until we rebooted. Perhaps that can be automated.

We were also wondering in what package which/where are in? Since I (and
thus them) mainly use bash and it isn't part of the installed base. On
that topic, perhaps there could be an interface via the WWW so you could
type in the name of a program (say unzip), and see what package you need
to download to install it. 

Lastly, I had been reading the FSSTND and was wondering how the members of
the Debian team were interpreting it. Are you/will you be making available
packages that reside in /usr/local/ ? Although the FSSTND says that no
distribution should put anything there initially, it does not specify what
can/should happen post installation. I, personally, would like things in
/usr/local/ so I could NFS export/mount that particular tree to
numerous machines. 

Cheers,

Anand.

--
 `When any government, or any church for that matter, undertakes to say to
  its subjects, "This you may not read, this you must not see, this you are
  forbidden to know," the end result is tyranny and oppression no matter how
  holy the motives' -- Robert A Heinlein, "If this goes on --"

Re: Fwd: Re: unable to execute

[Anand Kumria]

On Fri, 24 Mar 2000, Dushara Jayasinghe wrote:

> 
> 
> --  Forwarded Message  --
> Subject: Re: unable to execute
> Date: Thu, 23 Mar 2000 21:12:12 -0800
> From: Tristan Savatier <[EMAIL PROTECTED]>
> 
> 
> Dushara Jayasinghe wrote:
> > 
> > I downloaded mpegtv 1.1.0.20-3 (.deb version) from linuxberg and installed 
> > it
> > in Corel Linux -which seems to be the same as debian.
> > 
> > However, when I tried to execute mtv I get the error 'Segmentation fault'
> > 
> > What could cuase this problem?
> 
> We don't know yet.  looks like a problem with the Debian
> distribution (mtv works fine with all other Linux distributions).

It works fine for me on Debian 2.2 apart from cutting out the sounds
after a few minutes of playing VCDs.

> It would help if you could forward this message to the Debian support
> team, since the problem is on their side.

I don't think so. Have you asked this person to send the strace output
to you?

Anand

Re: Fwd: Re: unable to execute

[Anand Kumria]

On Mon, 27 Mar 2000, Tristan Savatier wrote:

> Yes, but I have not received it.
> 
> We have received several email of people reporting that mtv/mtvp
> does not work at all on some recent distributions of Corel linux.
> Is Corel Linux based on Debian ?

yes it is.

> In all cases, 'mtvp -h' seg faults immediately.  
> normally 'mtvp -h' should just print a help  message
> and exit.

I just checked on my Corel box. You have two version of mtv
available: one for glibc2.0 and the for glibc2.1

It works (well runs, I have no VCDs to test with at work) and display
help (mtvp -h). Even the graphical intreface works too. That .deb was
mtv_1.1.0.20-2_i386.deb

When I install the glibc2.1 version (mtv_1.1.0.20-3_i386.deb) it
promptly fails. You don't seem to have any dependancy information in
your .deb's which is probably a bad thing.

Debian 2.1 ships with libc6-2.0.7.19981211-6; Corel has the same
version. Debian 2.2 has libc6-2.1.3-7 (currently). Perhaps depending
on the right version of the libc6 would be good. Also for the glibc2.0
version you provide an SDL deb, yet it isn't depended upon.

>  usually when this type of thing happens, it is something
> broken with the libraries.  mtvp is one of the few multithreaded
> applications, and anything broken in the thread support would be fatal
> for mtvp.

They've installed the wrong version; perhaps updating your ver web
site with information for Corel would be useful too.

Anand

Re: Bug#70269: automatic build fails for potato

[Anand Kumria]

On Tue, Aug 29, 2000 at 11:57:32AM -0500, Manoj Srivastava wrote:
> >>"Hamish" == Hamish Moffatt <[EMAIL PROTECTED]> writes:
> 
>  Hamish> The package could be redone not to use debhelper. At the same time,
>  Hamish> the package could be rewritten not to use the C compiler.
> 
>  Hamish> Lazy programmers who require a C compiler, what is the world
>  Hamish> coming to? :-) 
> 
>   Yes indeed, there appears to be a modicum of common sense in
>  play here, Even though anything can be coded in assembly, or for a
>  turing machine, the principle here takes into account the effort
>  involved. It also tries to take into account the number of packages
>  that would need to write in an dependency if it was not a build
>  essential. 
> 
>   For a program written in C, a total  rewrite may be required
>  if one needs to remove the3 dependency on the compiler; however,
>  helper packages are not deemed to be that hared to replace. (You do
>  know what your helper package is doing, don't you?)

I did care at one point but don't any longer. It requires less effort
to figure it out anew each time a problem crops up.

Computers -> More Time.
  ^^
That transition point is software/tools which give me that. For the
vast majority of developers tools like debhelper do that.

For the other vast majority of people, C Compilers do the same thing. 
(You do know what your C compiler is doing, don't you?). The same can
apply to any large package (the kernel, X). (In howmuch detail do
you know what they are doing?).

One of nice things that devolves from having "interested" people look
after packages is that they can see to the details, which are important,
but not to everyone.

Now if only there was a distribution where people looked after packages
they had an interest in. Hey! Isn't that Debian?

>   However, given the number of people who seem to automatically
>  assume helper packages, is it time to revisit this issue?

I think so.

>   manoj
>  i'll fight tooth and nail any effort to make helper packages mandatory

Currently 87% of all packages [0] use some build scripts (not even counting
dbs -- doogie's build system -- of which some large packages; e.g. X use).

Not having the helper packages included in the autobuild system appears to
benefit, at most, around ~470 packages. 

Regards,
Anand

[0] Raw taken from Joey Hess's debhelper charts which can be found at
http://www.kitenet.net/programs/debhelper/stats/data>

Re: (Beware helix packages) Re: [CrackMonkey] The right to bare legs

[Anand Kumria]

On Tue, Aug 29, 2000 at 10:02:04PM -0500, Branden Robinson wrote:
> > No, there is no difference between our apps and the upstream in most
> > cases. We do brand gnome-core and gdm, but those are the only packages
> > I can think of offhand. Those are only graphics changes, substituting
> > some of our images in place of the defaults.
> 
> Okay, fine.  Name the Helixified packages under the following scheme:
> 
> Package: helix-gnome-core
> Conflicts: gnome-core
> Provides: gnome-core
> 
> Package: helix-gdm
> Conflicts: gdm
> Provides: gdm
> 
> (The Provides: gdm isn't necessary if nothing depends on it, and off the
> top of my head I can't think of anything that would depend on a display
> manager.)
> 
> You can then version helix-gnome-core and helix-gdm however you see fit.
> I'm not in any position to guarantee this, but I think Debian can agree to
> cede this part of our packaging namespace to you.  You may then, on these
> packages, violate our version numbering conventions to your heart's
> content.

That is one mechanism of creating a private namespace, isn't another 
Setting the origin to something other than Debian?

I'm not familiar with the gritty details of creating Package(.gz) files.

Anand

Re: Bug#70269: automatic build fails for potato

[Anand Kumria]

On Wed, Aug 30, 2000 at 10:10:27PM +0200, Wichert Akkerman wrote:
> Previously Richard Braakman wrote:
> > I don't know how the decision ended up being made, but the argument
> > I presented at the time is that a dependency on debhelper is far more
> > likely to be versioned than the others are.  A package that makes use
> > of a new feature of debhelper is going to have to declare its own
> > build-depends anyway.

Likewise a package that makes use of a particular feature of dpkg-dev.

But it is listed in the dependancy line of build-essential. What you are
saying is that rather than file bug reports on the (I assume) small set
of packages whic require a particular feature/verion of debhelper it
makes more sense to force everyone who uses it to declare a build-dependancy
upon it.

> Very much agreed, excellent point
> 
> Wichert (who has grown very tired of debhelper changes making building
> security fixes a painful job at times)

Presumably you also get just as tired when dpkg-dev changes happen but
the maintainer has not declared a version dependancy, yes?

Anand


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

Re: Bug#70269: automatic build fails for potato

[Anand Kumria]

On Thu, Aug 31, 2000 at 04:49:31PM +0200, Wichert Akkerman wrote:
> Previously Manoj Srivastava wrote:
> > I think that since every package using a helper package seems
> >  to need a versioned dependency, addign debhelper to build essential
> >  shall not remove the burden from the packages. And auto build daemons
> >  can also augment the build environment beyond build essential, as
> >  they already do. 
> 
> Right. In fact it makes things worse since people will just assume that
> their helper is already essential and they don't need to bother to
> to check if they need to specify a versioned dependency for it as well.

So file a bug. They can do exactly the same thing with dpkg-dev.

Anand


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

Re: Problems with mail system? [Fwd: Returned mail: User unknown]

[Anand Kumria]

On Thu, Sep 07, 2000 at 05:16:23PM -0500, Joseph Carter wrote:
> On Thu, Sep 07, 2000 at 05:37:25PM -0400, Adam McKenna wrote:
> > > My reverse DNS does not match my forward DNS.  I have @home.  Only
> > 
> > They don't need to "match".  Your IP just needs to resolve to something, and
> > that something needs to resolve back to your IP.  This has no effect on what
> > From: addresses and envelope senders you can use.
> 
> Miquel van Smoorenburg and others seem to think that they do need to
> match.  if you connect to my IP, you will see that neither 24.22.127.210
> nor cc659474-a.indnpls1.in.home.com appear in the greeting.

Maybe it is because they've read over RFC1912 Section 2.1:

  " Many services available
   on the Internet will not talk to you if you aren't correctly
   registered in the DNS.

   Make sure your PTR and A records match.  For every IP address, there
   should be a matching PTR record in the in-addr.arpa domain. "

If you feel that the way you use DNS is broad enough, why not write up
an RFC?

Anand


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

[ADMIN] Unsubscription problems

[Anand Kumria]

Hi there,

A number of people have reported problems with unsubscribing from
various lists, principally debian-user and debian-devel.

We, the listmaster team, believe we have fixed the underlying
problem and you should merrily be able to [un]subscribe as needed.

Please inform us if you aren't but keep in mind that you may 
not get a response with 24 hours. Three to four days is the
norm.

Thanks,
Anand

-- 
Linux.Conf.Au   --  http://linux.conf.au/
17th - 20th January,--  Alan Cox, David Miller,
Sydney, Australia   --  Tridge, maddog and you?

Re: Bug#80343: general: Lack of policy on which files should be owned by which user

[Anand Kumria]

On Tue, Dec 26, 2000 at 11:48:35AM +1100, Hamish Moffatt wrote:
> On Tue, Dec 26, 2000 at 11:13:13AM +1100, Brian May wrote:
> > However, the idea of one UID per daemon is (IMHO) a really horrible
> > solution, too, as you end up having more UIDs for daemons then
> > users. 
> 
> Why is that a problem? There are 65536 available UIDs.
> 

And 2^32 when 32-bit UIDs become more widespread.

Anand

-- 
Linux.Conf.Au   --  http://linux.conf.au/
17th - 20th January,--  Alan Cox, David Miller,
Sydney, Australia   --  Tridge, maddog and you?

Re: Misclassification of packages; "libs" and "doc" sections

[Anand Kumria]

On Tue, Dec 26, 2000 at 04:29:22AM +0200, Eray Ozkural (exa) wrote:
> Hi Thomas,
> 

[snip - lengthy email]

All of which is fine and dandy. None of which belonged on a public
mailing list though. Your email is tangentially related to Debians'
effort to determine new categories. 

In future please send those kinds of emails privately.

Anand

-- 
Linux.Conf.Au   --  http://linux.conf.au/
17th - 20th January,--  Alan Cox, David Miller,
Sydney, Australia   --  Tridge, maddog and you?

Debian 10th birthday gear

[Anand Kumria]

Hi all,

[ forward as required ]

I'm planning on doing some 10th birthday gear. I'm intending to get some
t-shirts made up but if people would like something else instead/as well
then let me know. Naturally you'll probably find it simpler to get your
own made up if you don't live in Sydney, Australia.

I'm only planning on doing a limited run, so perhaps people who are
doing something similiar locally can email [EMAIL PROTECTED] and let
others know. Naturally if I don't hear from you, nothing will be made.

I've also been toying around with a slogan (or two) with the help of
Anthony. The general one can always be done later (or used on posters).
I've, obviously, taken some artistic liberties with the numbers but the
intent is the alliteration.

Birthday

 Debian 
10 years
   100 countries
  1000 maintainers
 1 packages

General
Debian
1 project
   10 architectures
  100 countries
 1000 maintainers
1 packages
   10 bug fixed
  100 million users
 1000 installations
1 lines of code

I'd welcome any feedback / improvements.

Regards,
Anand

-- 
 `` We are shaped by our thoughts, we become what we think.
 When the mind is pure, joy follows like a shadow that never
 leaves. '' -- Buddha, The Dhammapada


pgp7aghpMNK0E.pgp
Description: PGP signature

Re: Debian 10th birthday gear

[Anand Kumria]

On Tue, Jul 08, 2003 at 12:58:01PM -0500, Adam Heath wrote:
> On Tue, 8 Jul 2003, Anand Kumria wrote:
> 
> > Hi all,
> >
> > [ forward as required ]
> >
> > I'm planning on doing some 10th birthday gear. I'm intending to get some
> > t-shirts made up but if people would like something else instead/as well
> > then let me know. Naturally you'll probably find it simpler to get your
> > own made up if you don't live in Sydney, Australia.
> 
> Hat?
> 
> Is there a debian patch that can be applied to hats, shirts, backpacks?
> 

Actually I was thinking about a red fedora - but that has been done
already. It turns out I'll be probably be doing some bags with a
embroided Debian logo on the front and the birthday text (10 Projects
... 1 packages) on the back.

I've got about 25 people interested in the first kind (b235) and only
5 in the second kind (b247). Minimum order is typically 50.

http://www.progsoc.org/~wildfire/debian/bags/deb-b235.png>
http://www.progsoc.org/~wildfire/debian/bags/deb-b247a.png>

The likely price would be AUD$30 for b235 and AUD$25 for b247. A
shipment will be headed to HP via Bdale; so overseas orders aren't out
of the question.

I've also been thinking about getting some glassware made up. Pint
glasses (left) or Schooners (right) for AUD$9 and AUD$16 respectively 
with a Debian logo, the words 'Debian' and '10 Years' on them. I've had 
about 15 people interested in the Pint (minimum number is 72) and none 
in the Schooners.

http://www.progsoc.org/~wildfire/debian/mugs.png>

If you, or anyone else, is interested shipping those overseas could be
arranged (with the caveat that glass might break in transit). I need to
know by this Friday to get them in time for Aug 16th so if you'd like
any of this stuff, let me know. 

Regards,
Anand

-- 
 `` We are shaped by our thoughts, we become what we think.
 When the mind is pure, joy follows like a shadow that never
 leaves. '' -- Buddha, The Dhammapada

Re: Debian 10th birthday gear

[Anand Kumria]

Hi Steve,

On Wed, Jul 30, 2003 at 08:02:44AM -0500, Steve Langasek wrote:
> On Wed, Jul 30, 2003 at 05:40:26PM +1000, Anand Kumria wrote:
> 
> > If you, or anyone else, is interested shipping those overseas could be
> > arranged (with the caveat that glass might break in transit). I need to
> > know by this Friday to get them in time for Aug 16th so if you'd like
> > any of this stuff, let me know. 
> 
> What kind of shipping costs would be tacked on for overseas orders?

It would really depend on how many you wanted, The steins are about
0.5kg and the bags about 250g but apparently the minimum shipping cost
is AUD$18 (for 20kg) overseas. Which is actually more than the Steins 
(AUD$12) are, Bags are AUD$30. 

Photos are available at http://www.progsoc.org/~wildfire/debian/> 
in the appropriate directory (the .jpg's). There wasn't that much
interest so there are only a limited number (50 bags, 72 steins).

If you are still interested, let me know.

Cheers,
Anand

-- 
 `` We are shaped by our thoughts, we become what we think.
 When the mind is pure, joy follows like a shadow that never
 leaves. '' -- Buddha, The Dhammapada

interacting with the press

[Anand Kumria]

Hi Martin,

I just read this article[1] in the SMH.  I think there are a few points that 
you should keep when talking to the press in future:

- don't "slag" them off / don't complain aobut the press

- Just talk about Debian, unless explicitly asked for comments
on other things (i.e. Ubuntu). 

In particular, it is obvious to me that you have not taken into account
the size or audience of the paper. It is (probably) the most widely read
paper in Australia and most of your comments have just given people a
negative impression of Debian.

Perhaps, with the funds being held for us by SPI, it would be useful to
arrange for you to have a 'refresher' course in dealing with the media.

Or, should you find the demands on your time too pressing, why not use
this opportunity to step-aside as the Debian press contact.

Thanks,
Anand

[1]: http://smh.com.au/news/breaking/debian-debates-support-for-ports/2005/07/12/1120934228145.html>

-- 
 `When any government, or any church for that matter, undertakes to say to
  its subjects, "This you may not read, this you must not see, this you are
  forbidden to know," the end result is tyranny and oppression no matter how
  holy the motives' -- Robert A Heinlein, "If this goes on --"


signature.asc
Description: Digital signature

no time for all debian tasks was: interacting with the press

[Anand Kumria]

Hi Torsten,

Thanks for your comments -- however I don't think anyone should be able
afraid to point out when a debian developer is obviously not able to
satisfy all the Debian-related demands on their time; let alone their
committments.

>From http://www.debian.org/intro/organization> you can various
people listed more than once; in Martin Schulze case 6 times.  I've
already said I do not believe that Martin is being an effective press
contact -- good intentions are great, but I'd like tto htink we also
deserve good execution.

Thanks,
Anand

-- 
 `When any government, or any church for that matter, undertakes to say to
  its subjects, "This you may not read, this you must not see, this you are
  forbidden to know," the end result is tyranny and oppression no matter how
  holy the motives' -- Robert A Heinlein, "If this goes on --"


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

Unidentified subject!

[Anand Kumria]

Hi Steve,

Thanks for your email.  I'd like to say touche but I basically believe
you are wrong.  Unfortunately I found from past-personal experience that
email to busy people is generally ignored unless brought to their
attention.

Additionally personal personality conflicts between myself and press
contact would practically guarantee that.  At any rate, I had hoped that
my email was being constructive (or that it could spaark a constructive
discussion) but that doesn't appear to have been the case.

I had hoped that others would have noted:

- the most recent PR does not have any indication of embargoed
  status.  Is it for immediate release?  Should it be held
  briefly?

  Most organisation use embargoed press releases so that when
  important events happen (e.g. a Debian release) everything can
  be prepared in advance and happen simultaneously.

- no 'about Debian' section

 Even smaller projects like Gnome has a section detailing, who
 they are, a brief outline of their goals, etc.  We place great
 value on things like the Social Contract and the DFSG and we
 should have a similiar section which mentions them -
 particularly for journalists who are not familiar with Debian
 this may be a great 'teaser' in an article about us.

 A good example one is
 http://gnome.org/press/releases/guadec2006-location.html>

 - nothing about debconf

 The Gnome release, above, highlights where the next GUADEC will
 be; how many Press Release have their been highlighting the
 current debcamp/debconf?  

There are other additional issues, all of which are technical -- since
press release are essentially 'cookie-cutter' things.  The last issue is
related to timelyness and my belief that quite a number of developers
have taken on too many roles within the project -- to the detriment of
the project.

Once again, thanks for your email, I personally didn't like the tone but
I do take your point. I just happen to diagree with it.

Regards,
Anand

-- 
 `When any government, or any church for that matter, undertakes to say to
  its subjects, "This you may not read, this you must not see, this you are
  forbidden to know," the end result is tyranny and oppression no matter how
  holy the motives' -- Robert A Heinlein, "If this goes on --"


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

Re: Wanted BTS feature: subscription to individual bug reports

[Anand Kumria]

On Tue, 12 Oct 2004 13:37:37 +0400, Nikita V. Youshchenko wrote:

> Hello.
> 
> I can't find a way to track more-or-less easilly all bugs in BTS that I am 
> somewhat involved into.
> 

If by 'involved' you mean submitted, then this might be useful:

http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED]>

Cheers,
Anand

-- 
linux.conf.au 2005   -  http://lca2005.linux.org.au/  -  Birthplace of Tux
April 18th to 23rd   -  http://lca2005.linux.org.au/  -   LINUX
Canberra, Australia  -  http://lca2005.linux.org.au/  -Get bitten!

Re: discover or alsa?

[Anand Kumria]

On Wed, 13 Oct 2004 13:43:01 +0200, Wouter Verhelst wrote:

> On Wed, Oct 13, 2004 at 10:51:46AM +0200, Marco d'Itri wrote:
>> On Oct 13, Thomas Hood <[EMAIL PROTECTED]> wrote:
>> > Lots of users are reporting that ALSA sound doesn't "just" work when
>> > they install it.  The cause of the problem is the fact that discover
>> > loads OSS modules even when ALSA modules are available.  This bug cannot
>> > be worked around consistently with policy because discover offers no
>> > mechanism for blacklisting modules other than editing a conffile.  The
>> > bug report against discover1 (#220616) has been tagged "wontfix" so I am
>> > not expecting the discover maintainers to solve the problem.
>> Discover should not try to load drivers for PCI devices AT ALL, we have
>> hotplug for this.
> 
> The reverse could be (and has been, on multiple occasions) said about
> hotplug.

[snip]
 
> The issue is that there are multiple auto-detection schemes in the
> This multitude of packages doing stuff with modules is bound to break
> eachother. Perhaps it's time to create a scheme which will allow
> packages to load modules without stepping on eachother's toes? Such a
> scheme would
> 
> * Require init scripts to ask the central module handling system
>   permission to load a module, with a description of what purpose the
>   module serves.
> * Not do anything if the central handling system forbids it.
> * Optionally keep track of what modules are loaded by what package, for
>   debugging purposes.
> * Allow packages to register themselves as the 'preferred' handler of
>   the module at postinst time (similar to the alternatives system; this
>   would solve the current issue ALSA has).
> * Give the local admin the ability to override such decisions, or to
>   disable the loading of certain modules.
> 
> Comments?

I think this is a situation where should push a particular implementation
to standard. Just as we promote 'sysvinit' and have interoperability
scripts for things like file-rc; if people want to use it.

Once we've picked a standard one, I'm partial to hotplug myself since it
seems to work well on both 2.4 and 2.6 kernels and I've found discover
doesn't. The optional detection mechanism(s) can then come up with a
programmatic interface similar to sysv-rc.

Cheers,
Anand

-- 
linux.conf.au 2005   -  http://lca2005.linux.org.au/  -  Birthplace of Tux
April 18th to 23rd   -  http://lca2005.linux.org.au/  -   LINUX
Canberra, Australia  -  http://lca2005.linux.org.au/  -Get bitten!

Testing Large File Support (LFS)

[Anand Kumria]

Hi,

I'm just wondering if there is an automated way that we can test programs
and/or packages to determine if they have working large file support?

I've stumbled onto problems in this area, in the past, with Apache and
Apache2 (fixed upstream but won't be making sarge) and with things like
wget (no idea about status).

Today I was hit but uw-imapd not working with >2G mailboxes.

I'm hoping there is some automated tool we can use rather than having to
find and then report bugs as we go.

Thanks,
Anand

-- 
linux.conf.au 2005   -  http://lca2005.linux.org.au/  -  Birthplace of Tux
April 18th to 23rd   -  http://lca2005.linux.org.au/  -   LINUX
Canberra, Australia  -  http://lca2005.linux.org.au/  -Get bitten!

Re: Proper Virtual Package Selection for Althea

[Anand Kumria]

On Wed, Apr 25, 2001 at 09:48:24PM +0200, Bas Zoetekouw wrote:
> Hi Jimmy!
> 
> 
> > but I don't have the time right now to remember how to write a procmail 
> > recipe
> > to filter out the list into a separate folder to prevent my inbox from 
> > getting
> > too large. (Any help on this would be appreciated as well.)

No doubt this will spark a large rash of emails helping. I may as well
get in while I can.

> This will put all mail from debian-devel into a mailbox "Debian" (in the
> default maildir):
> 
> :0
> * ^x-loop:[EMAIL PROTECTED]
> debian
> 

A slight more generic one is:


:0 
* ^((List-Id|X-(Mailing-)?List):(.*[<]\/[^>]*))
{
LISTID=$MATCH

# all Debian things ...
:0: 
* LISTID ?? debian-\/[EMAIL PROTECTED]
where/to/store/Debian/$MATCH
}

Which you can then make use of if you happen to subscribe to other mailing
lists which contain list-id (most) or x-mailing-list (a few).

Regards,
Anand