Re: Bug #298195: ITP: tinywm -- Ridiculously tiny window manager

[Nick Welch]

> This is why random Joe off the street should not be writing licences.

>From what I can gather, the license was developed through discussion on
OSI's mailing list, and in the end it was OSI who approved it.  Quite
different from "random Joe off the street" whipping up some homebrew
license and slapping it on some code.

I will be making another TinyWM release real soon now, and it will be
put into the public domain.  I'm tired of license drama -- that's partly
why I started using this license.  I guess the joke's on me. ;)

As far as it not being worth packaging for debian, I won't really get
involved in that debate except basically to say that it is certainly
worthy of debate.  It would be useful to have it apt-gettable, but then
again.. it's 60 lines of code! :)

-- 
Nick Welch aka mackstann | mack @ incise.org | http://incise.org


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

Re: Shouldn't kernel-image-2.6.x-y-z depend on alsa-base ?

[Joey Hess]

Josselin Mouette wrote:
> When you install an alsa-modules package for the 2.4 kernel, you get
> alsa-base per the dependencies. However, when you install sarge with a
> 2.6 kernel, alsa-base doesn't end up being installed. The result is that
> for most sound cards, both OSS and ALSA modules end up installed,
> resulting in various and random problems. To avoid that, shouldn't the
> kernel-image packages for 2.6 depend on alsa-base?

No, because the kernel does not depend on alsa to function.

Also, the problem you describe has nothing to do with the kernel's
dependency on alsa-base and everything to do with the mismash of several
hardware detection systems that randomly choose to load one or the other
module for a given pci id.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Bug#298195: ITP: tinywm -- Ridiculously tiny window manager

[Hamish Moffatt]

On Sun, Mar 06, 2005 at 12:05:52AM +, Andrew Suffield wrote:
> On Sun, Mar 06, 2005 at 01:17:50AM +0900, Nobuhiro Iwamatsu wrote:
> > * Package name: tinywm
> >   Version : 1.2.0
> >   Upstream Author : Nick Welch <[EMAIL PROTECTED]>
> > * URL : http://incise.org/
> > * License : fair license 
> 
[...]
> Usual example of why random people should not be writing licenses.

Do upstream developers find our arrogance endearing?

(Specifically yours.)


How embarassing.

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


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

Re: dehs will stop

[Martin Quinson]

[Why to cc on policy? Cut]

On Mon, Feb 28, 2005 at 03:32:30AM +0100, Bluefuture wrote:

> >If people don't care as much about this as you think they should,
> >perhaps it would be a good idea to try explaining why they *should*
> >care, instead of just lamenting their lack of a telepathic
> >understanding of your intentions?
> 
> This is not true. Had u tried to do a search about dehs/watch on
> debian-devel about 2004/2005? 

I didn't. Just change the content of this mail into one of the pages of your
site, and you're set.

> I'm not a debian developer, so i could not post on dda mailing list. I
> had opened many thread over this months on debian-qa debian-devel about
> dehs issues. The only reply are:
> 
> 1) Dehs is useless.
> 2) Submitting 6229 wishlist bug is not possible/is not the solution
> (without proposing alternatives method)
> 
> I had try to randomly submit wishlist bugs for 6 packages to bts with
> the tag "patch" pointing to the dehs site or attaching the watch file to
> the bug.
> Almost all of this bug was closed and the watch file was check (in some
> cases fixed) and inserted in the package on the next upload. 

So, you got the way to go. Please go ahead and submit those 6229 bugs.
Providing a patch *is* an alternative method. We did the same sort of
wishlish bug mass filling with the transition from raw debconf to
po-debconf. We had less packages to bug, though.

It represents an insane amount of work, but it's the way to go, I guess.
What's useless is to fill the bug without the patches, but if you write the
watch file for the people, nobody should complain.

Good luck, Mt.


signature.asc
Description: Digital signature

Re: Bug #298195: ITP: tinywm -- Ridiculously tiny window manager

[Matthew Palmer]

On Sun, Mar 06, 2005 at 02:38:35AM -0600, Nick Welch wrote:
> > This is why random Joe off the street should not be writing licences.
> 
> >From what I can gather, the license was developed through discussion on
> OSI's mailing list, and in the end it was OSI who approved it.  Quite
> different from "random Joe off the street" whipping up some homebrew
> license and slapping it on some code.

The links you gave earlier don't appear to show much useful debate or input
from anyone with the first clue about licence authoring.

> I will be making another TinyWM release real soon now, and it will be
> put into the public domain.  I'm tired of license drama -- that's partly
> why I started using this license.  I guess the joke's on me. ;)

The MIT licence (http://www.opensource.org/licenses/mit-license.php) does
pretty much what you appear to want the Fair Licence to provide -- "do what
you like, just don't remove the licence".  That makes the Fair Licence
doubly pointless.

Public domain is not going to absolve you from the licence drama, either --
in many jurisdictions, there is no concept of "the public domain", so you're
in a bit of a pickle.

> As far as it not being worth packaging for debian, I won't really get
> involved in that debate except basically to say that it is certainly
> worthy of debate.  It would be useful to have it apt-gettable, but then
> again.. it's 60 lines of code! :)

A minimal WM might be of use, but I'm not sure if it's quite going to "add
value" to Debian.  But it's not as though it'd be the first package with
limited appeal to enter Debian.  I'll leave that judgement call to whoever
is willing to maintain the package.

- Matt


signature.asc
Description: Digital signature

Re: Popularity-contest http POST: call for testers

[Bill Allombert]

On Sat, Mar 05, 2005 at 09:17:22PM -0600, Jacob S wrote:
> On Sun, 6 Mar 2005 00:48:21 +0100
> Bill Allombert <[EMAIL PROTECTED]> wrote:
> 
> > Hello developers,
> > 
> > We have plans to add support in popularity-contest to send the
> > report through http POST. Both the server part an the client part have
> > been developed.  The last issue is to actually use it in the cron job
> > and see what issues 
> > 
> > For that purpose, I have made an experimental popularity-contest
> > package that use both smtp and http. Please find it here:
> > 
> > 
> > 
> > This package report to the test popcon account so we can monitor it.
> > 
> > We would really like people to review or test this package in real
> > situations, in particular when network connectivity is chaotic.
> > We would like to make sure the popcon cron job will not cause problem
> > to users with poor network.
> 
> I have not yet bothered to setup smtp on my machine to go through my
> ISP's required gateway, so I could only send reports via the HTTP
> method. Would my beta testing still be helpful, or are reports needed
> via both methods for the test?

On the contrary, it would be very useful!

Cheers,
Bill.


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

Re: Re:Bug #298195: ITP: tinywm -- Ridiculously tiny window manager

[Nick Welch]

On Sun, 6 Mar 2005 20:51:43 +1100, Matthew Palmer wrote:
> The links you gave earlier don't appear to show much useful debate or
> input from anyone with the first clue about licence authoring.

The internet appears to have swallowed the mailing list messages, but I
do remember reading through them in the past, and there was debate and
multiple revisions of the license before it became what is on the OSI
site.

> The MIT licence (http://www.opensource.org/licenses/mit-license.php)
> does pretty much what you appear to want the Fair Licence to provide
> -- "do what you like, just don't remove the licence".  That makes the
> Fair Licence doubly pointless.
>
> Public domain is not going to absolve you from the licence drama,
> either -- in many jurisdictions, there is no concept of "the public
> domain", so you're in a bit of a pickle.

In the past I used the MIT license, but the only reason I used it
instead of giving to the public domain was because I had read a paper
that, IIRC, basically said that you're less protected legally by doing
so.  But anymore I realize what the odds are and it seems silly to care.
If someone wants to sue me, hah, "bring it on."

There seem to be other issues regarding PD, such as what you mention,
but a quick look around reveals a number of non-trivial projects
released to the public domain.  PD-ksh is the most prominent in my mind,
simply because of the name.  UCLA seems to deem it safe to do so:
.  DJB also comes to mind.  And it
appears that Debian has quite a few packages which are classified as
public domain.

-- 
Nick Welch aka mackstann | mack @ incise.org | http://incise.org


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

Re: Popularity-contest http POST: call for testers

[Bill Allombert]

On Sat, Mar 05, 2005 at 09:05:49PM -0500, Daniel Burrows wrote:
> On Saturday 05 March 2005 06:48 pm, Bill Allombert wrote:
> > For that purpose, I have made an experimental popularity-contest package
> > that use both smtp and http. Please find it here:
> 
>   Have you considered uploading it to experimental?

Not yet, because it does not report to the normal popcon account so I am
afraid that look a bit sneaky to just drop it in experimental without
warning users.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here.


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

Re: Shouldn't kernel-image-2.6.x-y-z depend on alsa-base ?

[Thomas Hood]

On Sun, 06 Mar 2005 00:20:13 +0100, Paul Hampson wrote:
> Hmm. I would think that the better solution (the less surprising
> solution) would be to leave out the ALSA modules from the Debian
> kernel package, since we have a seperate package of ALSA modules
> which _does_ depend on alsa-base.


That's not a bad idea.  We already have the problem that the ALSA drivers
in the kernel-image packages are out of date relative to the ALSA
libraries in alsa-lib.  (Currently, the drivers in kernel-image-2.6.8 are
version 1.0.4 but alsa-lib in sarge is version 1.0.8.)  Omitting the ALSA
drivers from kernel-image packages would solve this problem by forcing
people to install up-to-date alsa-modules packages.


On Fri, 04 Mar 2005 20:20:10 +0100, Josselin Mouette wrote:
> As long as the linux26 installation ends up with both sound modules
> loaded, that's a bug that needs to be fixed, though. Another option
> would be to put the alsa modules in separate packages, just like pcmcia
> modules.


There already exist separate alsa modules packages.  Currently we only
build them for 2.4 kernels, though.

-- 
Thomas Hood


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

Re: Shouldn't kernel-image-2.6.x-y-z depend on alsa-base ?

[Josselin Mouette]

Le dimanche 06 mars 2005 Ã 11:53 +0100, Thomas Hood a Ãcrit :
> On Fri, 04 Mar 2005 20:20:10 +0100, Josselin Mouette wrote:
> > As long as the linux26 installation ends up with both sound modules
> > loaded, that's a bug that needs to be fixed, though. Another option
> > would be to put the alsa modules in separate packages, just like pcmcia
> > modules.
> 
> There already exist separate alsa modules packages.  Currently we only
> build them for 2.4 kernels, though.

Yes, that's why the problem doesn't show up on 2.4 installations.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=

Re: Bug #298195: ITP: tinywm -- Ridiculously tiny window manager

[Henning Makholm]

Scripsit Nick Welch <[EMAIL PROTECTED]>

> From what I can gather, the license was developed through discussion on
> OSI's mailing list, and in the end it was OSI who approved it.

That only goes to show that the OSI has finally lost every last bit of
sense they used to possess.

-- 
Henning Makholm"Jeg køber intet af Sulla, og selv om uordenen griber
planmæssigt om sig, så er vi endnu ikke nået dertil hvor
   ordentlige mennesker kan tillade sig at stjæle slaver fra
 hinanden. Så er det ligegyldigt, hvor stærke, politiske modstandere vi er."

Re: list what's in the NEW queue?

[Marcelo E. Magallon]

On Fri, Feb 04, 2005 at 12:40:02AM -0800, Steve Langasek wrote:

 > >  > It works and is available from dak.ganneff.de.  And the packages
 > >  > is used on several archives now.  Its just not out of NEW atm.
 > 
 > >  So, let's *guess* ...
 > 
 > >  * -release decided to stop processing NEW ... we still have this thing
 > >called debian-devel-announce, you know?
 > 
 > Er, as flattering as it might be to suppose that the release team can
 > unilaterally decide to stop NEW processing, it's at least as
 > insulting to presume that we wouldn't have told people about it via
 > debian-devel-announce, y'know?

 Whilst no insult was meant, it _still_ _looks like_ a silent decision.

 My apologies if insult was taken,

 Marcelo


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

Re: list what's in the NEW queue?

[Marcelo E. Magallon]

Hi,

 pardon me for the delay, I really have better things to do that getting
 involved all day long in discussions with purposely obtuse people.

On Fri, Feb 04, 2005 at 01:30:22PM +1000, Anthony Towns wrote:
 > Marcelo E. Magallon wrote:
 > >On Fri, Feb 04, 2005 at 11:21:02AM +1000, Anthony Towns wrote:
 > >
 > > > >On Thu, Feb 03, 2005 at 08:39:10PM +0100, Joerg Jaspert wrote:
 > > > > * it's not ftp-master's business to judge on _technical_ merits
 > > > >   of the pacakge (bad packaging practices, missing
 > > > >   dependencies, ignores /chapter and verse/ of policy, ...), so
 > > > >   we can safely rule that one out
 > > > Uh, wtf are you on?
 > > Anthony, please, think in context.  Use some common sense.
 > 
 > Ah, arrogance and self-righteousness with a dash of utter ignorance.
 > Fair enough.

 And there goes your typical MO on mailing lists _again_.

 Shall I remind you that *you* are the one that recently put a request
 for more civil and productive discussions down in written form in front
 of the whole project?  Please, by all means, do as you say.  I'll be
 delighted to follow suit.

 > > Or is it now your intention to burden the bunch of people who
 > > actually do some work as ftp-master with package nitpicking, too?
 > > Give me a break.
 > 
 > Dude, you have no idea what you're talking about.

 Maybe, I sit on the wrong side of ftp-master, it's been always like
 that and I have no intention whatsoever to change that because I'm not
 afraid to admit that I don't have the resources to volunteer for such a
 task.

 That doesn't make my own appreciation of the situation wrong.

 > Processing of NEW packages is done with a tool called "lisa", the use
 > of which involves two steps -- checking the package, then either
 > accepting it, rejecting it, or skipping it. Checking it invokes a
 > library called "fernanda.py" whose _sole_ purpose is finding
 > technical issues with the package; it runs both lintian and linda,
 > gives a full manifest of the changed packages, lists the contents of
 > the control file, highlighting issues that might need attention,
 > dumps the copyright file, and so on.

 Pretty tale.

 Useless, too.

 A certain truly new, not previously on the archive, package with
 *obvious* technical flaws recently sat on NEW for a period a bit shy of
 two weeks, and after this time certainly devoted to careful scrutiny it
 just made its way into unstable.  The problem here is that the flaws
 are obvious to anyone with a clue about the package, which I simply
 won't require ftp-master to have because it is not their task nor
 place.

 In the meantime, there's plenty of packages _already_ in the archive
 which were split, reorganized or simply added new components, either
 because upstream includes more stuff, a bug requires this action to be
 taken, policy requires this action or the maintainer simply realized
 that -- in three years time, or whenever sarge+1 actually releases
 unless something changes drastically in this project -- there will be a
 better upgrade path in that way.

 What you are saying reads to me as if stuff that already in the archive
 gets more attention and demands more time than stuff that's plain new.

 The situation wouldn't be this bad if all these "issues that need
 attention" would end up in the developer's mailbox and a public mailing
 list.  But since ftp-master take the actions you mention and says
 *nothing* to the involved parties (which in this case happen to be "the
 whole project").  I can't honestly image that there's no communication
 among ftp-master members: "I'm looking at that", "I don't like that",
 "that gives me the willies", ... because you have to _somehow_ avoid
 stepping on each other's toes.

 Now, *please*, shed some your wisdom and knowledge on me once again and
 do tell me where's the problem with sharing this data with the rest of
 the project.

 And just to save you some detective work: yes, there's a package of
 mine sitting in NEW, it's mesa.  It's been there for over two months.
 I'd be complaining the same if it wasn't there because this has
 happened before and it has happened in other areas of the project,
 perhaps most notably with the new maintainer queue and the keyring.

 > > Let me use a package of mine as an example: mesa 6.2.1-1 (source)
 > > produces, among others, the binary package mesag3.  This package
 > > ships libGL.so.1.  This is a violation of 8.1 ("The run-time shared
 > > library needs to be placed in a package called
 > > `' [...]").
 > 
 > *shrug* The proper thing to do when policy recommends something
 > that's wrong is to fix policy. That policy isn't particularly well
 > maintained has very little to do with whether NEW packages will have
 > their technical flaws examined or not.

 There is simply no way to bend policy to accommodate this case.  The
 name "mesag3" is historic and fooling with transitional packages to get
 it "fixed" is pointless.  A mistake was made, really really long ago,
 and that

Re: list what's in the NEW queue?

[Marcelo E. Magallon]

On Fri, Feb 04, 2005 at 03:17:51AM +0100, Wouter van Heyst wrote:
 > On Thu, Feb 03, 2005 at 06:03:04PM -0600, Marcelo E. Magallon wrote:
 > >  * it's not ftp-master's business to judge on _technical_ merits of
 > >the pacakge (bad packaging practices, missing dependencies,
 > >ignores /chapter and verse/ of policy, ...), so we can safely
 > >rule that one out
 > 
 > I had the impression this was an important part of the job.

 While it's true that there _are_ automated tests for some (important!)
 parts of policy, I really do _not_ want ftp-master installing and
 deinstalling a bunch of stuff in order to tell me that Foo needs to
 depend on Bar.  I also do not want ftp-master to waste time questioning
 why libfoo-perl does not depend on libfoo1 perl (which would be easy to
 catch and also a mistake to fix -- yes, I'm thinking about one very
 particular example of something still stuck in NEW last time I looked)

 Have ftp-master question copyrights where -legal already reached a
 (positive!) consensus if that gives them joy...  but have them say
 something!

 Again, I'm really not talking about plain silly and stupid.  I would
 have thought that was obvious.

 Marcelo


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

Re: Bug#298195: ITP: tinywm -- Ridiculously tiny window manager

[Marc Haber]

On Sun, 6 Mar 2005 20:38:06 +1100, Hamish Moffatt <[EMAIL PROTECTED]>
wrote:
>On Sun, Mar 06, 2005 at 12:05:52AM +, Andrew Suffield wrote:
>> On Sun, Mar 06, 2005 at 01:17:50AM +0900, Nobuhiro Iwamatsu wrote:
>> > * Package name: tinywm
>> >   Version : 1.2.0
>> >   Upstream Author : Nick Welch <[EMAIL PROTECTED]>
>> > * URL : http://incise.org/
>> > * License : fair license 
>> 
>[...]
>> Usual example of why random people should not be writing licenses.
>
>Do upstream developers find our arrogance endearing?
>
>(Specifically yours.)

I seldomly agree with asuffield, but having worked for a law office
for seven years has given me sufficient legal experience to know that
he is right this time. If you want to put down something legally
binding, go see a landshark.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

unsubscribe

[richard]

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

Re: list what's in the NEW queue?

[Petter Reinholdtsen]

[Marcelo E. Magallon]
> Whilst no insult was meant, it _still_ _looks like_ a silent
> decision.

Well, that is one of several explanations.  I have no idea if it is
the real one, but believe the release team would have the decency to
let us know if they made such decision and do not believe the release
team made a silent decision to stop the NEW queue processing.

But facts remain that the NEW queue process stopped completely a few
months ago, and almost only the d-i related packages have been able to
get through the "queue" since then.

At the moment, 419 source packages are waiting in the NEW queue.  The
oldest package was uploaded 2002-02-21, but it seem to be one of the
packages destined to be ignored, along with seven other packages
uploaded before 2004-11-30.  The "real" NEW queue seem to start
2004-12-20.  From that date, there is no "holes" in the dates when the
upload happened.  I find all this information on
http://qa.debian.org/~anibal/debian-NEW-summary.html>.

So, something happened around Christmas, and the NEW queue haven't
been processed as a queue (I mean as first in, first out) since.
Anyone know what happened?  I suspect the ftpmasters got too much to
do elsewhere, making the NEW queue processing drop in priority.  Is
there any truth in that, or was there something else that happened?

The fact that the NEW queue process has stopped affect the project
negatively in several ways.  I'm involved in two sub-projects having
problems making progress because of this.

The Debian GIS subproject are working on making GIS tools available in
Debian, and need both C, C++ and Java libraries and programs to make
it into the Debian archive.  The members of this subproject seem to
have given up on trying to get their packages into Debian proper, and
maintain their own APT source on alioth with the new GIS tools.
Getting the tools into Debian proper isn't give much priority, as the
package would just be uploaded into the NEW queue and nothing would
happen after that.

The Debian Java subproject is working on improving Java support in
Debian and also moving Java packages from contrib into main.  To move
Java packages into main, they need to get the dependency Java packages
accepted into main first before they can move on to the next level of
dependencies.  With no progress in the NEW queue, this work is slowing
almost to an halt.  Some Java developers have moved to Ubuntu because
of this, where the NEW queue is processed in at most 2 work days, and
lots of Java packages are already moved into main.

So the blocked NEW queue either scare people over to Ubuntu, get them
to avoid the new archive and make their own or delay the work of
improving the packages in the Debian archive.  This is really bad for
the project.

I saw one idea from Joey Hess to make it easier to share the load of
processing the NEW queue.  That might be a solution to this problem at
hand, allowing more people to vouch for the content of new packages.

While we wait, I suggest we start registering alternative locations
for the packages in the NEW queue.  Almost all the packages in the NEW
queue is also located elsewhere on the web.  If we started to register
the URL where the package in the NEW queue can be located outside the
NEW queue, more people could have a look at the packages in the NEW
queue, and start testing them earlier.  At least for Debian Java, it
might make a difference.  This will not affect the problem of the
stuck NEW queue, but it will make it easier for the project to keep
moving forward while the NEW queue is stick.

--
Petter Reinholdtsen
Without any packages in the NEW queue at the moment, luckily


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

Re: Popularity-contest http POST: call for testers

[Daniel Burrows]

On Sunday 06 March 2005 05:55 am, Bill Allombert wrote:
> Not yet, because it does not report to the normal popcon account so I am
> afraid that look a bit sneaky to just drop it in experimental without
> warning users.

  Well, the idea would be to post here AND upload it to experimental, so 
people who want it can just fetch it from there.

  Daniel

-- 
/--- Daniel Burrows <[EMAIL PROTECTED]> --\
|  "Progress just means bad things happen faster."  |
|-- Terry Pratchett, _Witches Abroad_   |
\--- Be like the kid in the movie!  Play chess! -- http://www.uschess.org --/


pgpIG6ZFVlHD1.pgp
Description: PGP signature

Re: dehs will stop

[Jeroen van Wolffelaar]

On Sun, Mar 06, 2005 at 10:49:47AM +0100, Martin Quinson wrote:
> [Why to cc on policy? Cut]
> 
> On Mon, Feb 28, 2005 at 03:32:30AM +0100, Bluefuture wrote:
> 
> > >If people don't care as much about this as you think they should,
> > >perhaps it would be a good idea to try explaining why they *should*
> > >care, instead of just lamenting their lack of a telepathic
> > >understanding of your intentions?
> > 
> > This is not true. Had u tried to do a search about dehs/watch on
> > debian-devel about 2004/2005? 
> 
> I didn't. Just change the content of this mail into one of the pages of your
> site, and you're set.
> 
> > I'm not a debian developer, so i could not post on dda mailing list. I
> > had opened many thread over this months on debian-qa debian-devel about
> > dehs issues. The only reply are:
> > 
> > 1) Dehs is useless.
> > 2) Submitting 6229 wishlist bug is not possible/is not the solution
> > (without proposing alternatives method)
> > 
> > I had try to randomly submit wishlist bugs for 6 packages to bts with
> > the tag "patch" pointing to the dehs site or attaching the watch file to
> > the bug.
> > Almost all of this bug was closed and the watch file was check (in some
> > cases fixed) and inserted in the package on the next upload. 
> 
> So, you got the way to go. Please go ahead and submit those 6229 bugs.

NO!

Do *not* file 6229 bugs about the same subject. Never.

Adding a watchfile is up to the maintainer. It's a feature offered to
maintainers, they can use it if the wish. If a watchfile for a package
makes sense (for quite some packages it doesn't) I think it's useful.
In no case should 6229 bugs be filed about these watchfiles that don't
have ANY effect on the resulting binary packages.

--Jeroen

-- 
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl

Re: dehs will stop

[Thiemo Seufer]

Jeroen van Wolffelaar wrote:
[snip]
> > > I had try to randomly submit wishlist bugs for 6 packages to bts with
> > > the tag "patch" pointing to the dehs site or attaching the watch file to
> > > the bug.
> > > Almost all of this bug was closed and the watch file was check (in some
> > > cases fixed) and inserted in the package on the next upload. 
> > 
> > So, you got the way to go. Please go ahead and submit those 6229 bugs.
> 
> NO!
> 
> Do *not* file 6229 bugs about the same subject. Never.

Why not? As wishlist bugs with patch this seems sensible to me.

> Adding a watchfile is up to the maintainer. It's a feature offered to
> maintainers, they can use it if the wish. If a watchfile for a package
> makes sense (for quite some packages it doesn't) I think it's useful.

If upstream doesn't publish tarballs, e.g. In this case there won't be
a meaningful patch for a watchfile. In any case it's up to the
maintainer to decide about its inclusion. I believe most of them will
accept such a patch.


Thiemo


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

Re: dehs will stop

[Lars Wirzenius]

su, 2005-03-06 kello 19:28 +0100, Thiemo Seufer kirjoitti:
> Jeroen van Wolffelaar wrote:
> > Do *not* file 6229 bugs about the same subject. Never.
> 
> Why not? As wishlist bugs with patch this seems sensible to me.

Denial of service attacks on the bug tracking system, on mailing lists,
mail servers, and maintainers is unappreciated. 6229 bug reports would
result in all sorts of unnecessary and unwanted load on all sorts of
systems and people. It is because of reasons like these that mass-filing
of bugs must always be discussed on debian-devel beforehand, so that the
utility of the bug reports can be weighed against the load and
disruption they cause.

In this situation, I think it is clear that filing 6229 *wishlist* bugs
is completely unwarranted.

> If upstream doesn't publish tarballs, e.g. In this case there won't be
> a meaningful patch for a watchfile. In any case it's up to the
> maintainer to decide about its inclusion. I believe most of them will
> accept such a patch.

Having the watch information in the package means the information
becomes stale: when the package is part of a Debian release the watch
information won't get updated when the upstream web site moves, or the
download URL changes, or whatever. Having a centralized database (say,
part of package.debian.org) allows that information to be updated
centrally, continuously, and also without disturbing a thousand
developers with it.


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

Re: dehs will stop

[Christoph Berg]

Re: Thiemo Seufer in <[EMAIL PROTECTED]>
> > Do *not* file 6229 bugs about the same subject. Never.
> 
> Why not? As wishlist bugs with patch this seems sensible to me.

I assume that you will hand-check the patches in those 6229 bug
reports that the watch files actually do the right thing before you
submit the reports?

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature

Re: dehs will stop

[Thiemo Seufer]

Christoph Berg wrote:
> Re: Thiemo Seufer in <[EMAIL PROTECTED]>
> > > Do *not* file 6229 bugs about the same subject. Never.
> > 
> > Why not? As wishlist bugs with patch this seems sensible to me.
> 
> I assume that you will hand-check the patches in those 6229 bug
> reports that the watch files actually do the right thing before you
> submit the reports?

How else could it be a useful patch?
Btw, I'm not volunteering for that task.


Thiemo


signature.asc
Description: Digital signature

Re: dehs will stop

[Thiemo Seufer]

Lars Wirzenius wrote:
> su, 2005-03-06 kello 19:28 +0100, Thiemo Seufer kirjoitti:
> > Jeroen van Wolffelaar wrote:
> > > Do *not* file 6229 bugs about the same subject. Never.
> > 
> > Why not? As wishlist bugs with patch this seems sensible to me.
> 
> Denial of service attacks on the bug tracking system, on mailing lists,
> mail servers, and maintainers is unappreciated. 6229 bug reports would
> result in all sorts of unnecessary and unwanted load on all sorts of
> systems and people.

Since preparation of the accompanying patches would take some time,
it is unlikely to cause "denial of service" or "disruption".

[snip]
> > If upstream doesn't publish tarballs, e.g. In this case there won't be
> > a meaningful patch for a watchfile. In any case it's up to the
> > maintainer to decide about its inclusion. I believe most of them will
> > accept such a patch.
> 
> Having the watch information in the package means the information
> becomes stale: when the package is part of a Debian release the watch
> information won't get updated when the upstream web site moves, or the
> download URL changes, or whatever.

Yes, it adds some (small) maintenance burden.

> Having a centralized database (say,
> part of package.debian.org) allows that information to be updated
> centrally, continuously, and also without disturbing a thousand
> developers with it.

Do you really expect such a centralized database would be updated
more consistently? By whom?


Thiemo


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

Re: dehs will stop

[Lars Wirzenius]

su, 2005-03-06 kello 20:11 +0100, Thiemo Seufer kirjoitti:
> Since preparation of the accompanying patches would take some time,
> it is unlikely to cause "denial of service" or "disruption".

If they are sent at a slow pace, then the disruption is less, it is
true. It is still detrimental to have thousands upon thousands of
wishlist bugs for something like this. We don't have lintian report bugs
for all the errors it finds for the same reason (well, one of the
reasons): the volume would be too much.

Increasing the number of open bugs in Debian with 10-20% just for watch
files, or any other non-critical issue, is not a good idea.

> Yes, it adds some (small) maintenance burden.

In case it was unclear: I am not talking about the burden on the package
maintainer, that is small enough to not worry about. I am talking about
information that will not be updated at all, even if the package
maintainer wants it to be updated and provides a new package with the
new information. There is no point in flooding a Debian stable release
with new package versions that merely change a watch URL.

> > Having a centralized database (say,
> > part of package.debian.org) allows that information to be updated
> > centrally, continuously, and also without disturbing a thousand
> > developers with it.
> 
> Do you really expect such a centralized database would be updated
> more consistently? By whom?

Given that the distributed version won't be updated at all, there is a
chance that a centralized database will be more up to date. Making it
easy to update by, for example, providing a simple web interface that
lets any DD log in and update any watch url should make it pretty likely
that it actually happens. If Wikipedia can do it for tens of thousands
of articles, surely we can do it for a few thousand URLs.

(Or you can lobby for a virtual package in the bug tracking system and
have people write bug reports when they notice a broken URL, and have a
team dedicated to checking the URLs and updating the database. Or have a
mail bot a la the one for db.debian.org. Or a structured wiki site.)


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

Re: dehs will stop

[Martin Quinson]

On Sun, Mar 06, 2005 at 06:44:37PM +0100, Jeroen van Wolffelaar wrote:
> On Sun, Mar 06, 2005 at 10:49:47AM +0100, Martin Quinson wrote:
> > 
> > On Mon, Feb 28, 2005 at 03:32:30AM +0100, Bluefuture wrote:
> > 
> > > I'm not a debian developer, so i could not post on dda mailing list. I
> > > had opened many thread over this months on debian-qa debian-devel about
> > > dehs issues. The only reply are:
> > > 
> > > 1) Dehs is useless.
> > > 2) Submitting 6229 wishlist bug is not possible/is not the solution
> > > (without proposing alternatives method)
> > > 
> > > I had try to randomly submit wishlist bugs for 6 packages to bts with
> > > the tag "patch" pointing to the dehs site or attaching the watch file to
> > > the bug.
> > > Almost all of this bug was closed and the watch file was check (in some
> > > cases fixed) and inserted in the package on the next upload. 
> > 
> > So, you got the way to go. Please go ahead and submit those 6229 bugs.
> 
> NO!
> 
> Do *not* file 6229 bugs about the same subject. Never.
> 
> Adding a watchfile is up to the maintainer. It's a feature offered to
> maintainers, they can use it if the wish. If a watchfile for a package
> makes sense (for quite some packages it doesn't) I think it's useful.
> In no case should 6229 bugs be filed about these watchfiles that don't
> have ANY effect on the resulting binary packages.

Erm. You did cut what I said, ie, that if someone wants to write the few
thousands missing watch files and provide them as wishlist bug, I'd say that
they should proceed. People not wanting of those watch files can always mark
the bug wontfix if it's a political opinion, or close the bug if it does not
make any sense in their case.

Of course, mass bug filling saying "please do the job I'd like to see done"
is never a solution. That's not what I proposed. That's not what we did for
the po-debconf transition.

And hoping that maintainers are perfect and will write everybit of the
needed infrastructure alone is a dream. I welcome any transversal help
offer. That's QA job, and that's good, IMHO.

Thanks, Mt.


signature.asc
Description: Digital signature

Re: Switchconf: Orphaning or removing?

[Jose Manuel dos Santos Calhariz]

On Thu, Jan 06, 2005 at 01:01:15AM -0600, Gunnar Wolf wrote:
> Hi,
> 
> Some time ago, I adopted switchconf, a very simple bash script used to
> simply switch between configurations, planned for use on mobile
> systems, but perfectly usable on the desktop as well.
> 
> Now, switchconf is too simple. It does very little, but does not do it
> very well. I originally intended to work with it to make it much more
> robust... But in the end, I didn't get around to do it.
> 
> (...)
>
> ...So this message is just to ask: Does anybody care about it, or
> should I just file the removal bug?

Yes, I care about it.  I use it on my laptop to have personalized
configurations for the places I connect to the Internet.  For example
besides interfaces, I have a sources.list optimized.

Now I have to install 60 PCs with Debian and there exist 4 different
configurations of monitor, graphical display and mouse.  I am using it
to switch XF86Config-4 and gpm.conf between the 4 kinds of
configurations.

There exist any alternative?

What can I do to get it back into the Debian?

 
> Greetings,
> 
> -- 

Jose Calhariz

PS: I am not a Debian Developer. 

-- 
Meu Deus, dai-me paciência... mas tem que ser já!


signature.asc
Description: Digital signature

Re: list what's in the NEW queue?

[Anthony Towns]

Marcelo E. Magallon wrote:
 pardon me for the delay, I really have better things to do that getting
 involved all day long in discussions with purposely obtuse people.
On Fri, Feb 04, 2005 at 01:30:22PM +1000, Anthony Towns wrote:
Yay for pulling up flamewars from over a month ago and restarting them 
on a different list.

 > Ah, arrogance and self-righteousness with a dash of utter ignorance.
 > Fair enough.
 And there goes your typical MO on mailing lists _again_.
Dude, insulting the people you're talking to is Debian's MO on mailing 
lists. Heck, reread what you just wrote: "purposely obtuse people" whom 
you've got better things to do than talk to, and who's "MO" is snarky 
comments.

 Shall I remind you that *you* are the one that recently put a request
 for more civil and productive discussions down in written form in front
 of the whole project?  Please, by all means, do as you say.  I'll be
 delighted to follow suit.
If you'd like to discuss this aspect on -vote, I'd be happy to; 
otherwise, I've already said everything I intend to in this thread, 
whether it's on -project or -devel.

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

Re: dehs will stop

[Russ Allbery]

Lars Wirzenius <[EMAIL PROTECTED]> writes:

> Denial of service attacks on the bug tracking system, on mailing lists,
> mail servers, and maintainers is unappreciated. 6229 bug reports would
> result in all sorts of unnecessary and unwanted load on all sorts of
> systems and people. It is because of reasons like these that mass-filing
> of bugs must always be discussed on debian-devel beforehand, so that the
> utility of the bug reports can be weighed against the load and
> disruption they cause.

> In this situation, I think it is clear that filing 6229 *wishlist* bugs
> is completely unwarranted.

Wouldn't it be a lot easier, if there is consensus that having a watch
file is the right thing to do, to add it as a lintian warning?  That seems
like a far lower-impact way of notifying 6,229 package maintainers.

One problem with either approach (although somewhat less so for filing
bugs if someone is carefully hand-checking each one) is that there are
packages in Debian that are based on an upstream release that's completely
dead or unsuitable for further tracking for some reason.  For such
packages, the watch file is actually counter-productive, since it implies
some ongoing relationship to the original upstream release that isn't
accurate.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

Re: dehs will stop

[Thiemo Seufer]

Lars Wirzenius wrote:
> su, 2005-03-06 kello 20:11 +0100, Thiemo Seufer kirjoitti:
> > Since preparation of the accompanying patches would take some time,
> > it is unlikely to cause "denial of service" or "disruption".
> 
> If they are sent at a slow pace, then the disruption is less, it is
> true. It is still detrimental to have thousands upon thousands of
> wishlist bugs for something like this.

Why? Could you provide a rationale for this assertion?

> We don't have lintian report bugs
> for all the errors it finds for the same reason (well, one of the
> reasons): the volume would be too much.

We don't talk about automated bug filing here. If somebody writes
patches to fix (valid) lintian problems it is IMHO clearly legitimate
to file that as a wishlist bug. Of course there are bogus Lintian
triggers, this needs to be taken into account.

(Btw, I somehow doubt the volume of such bugs will become a problem
anytime soon. Simply because there aren't that many people motivated
to fix such stuff.)

> Increasing the number of open bugs in Debian with 10-20% just for watch
> files, or any other non-critical issue, is not a good idea.
> 
> > Yes, it adds some (small) maintenance burden.
> 
> In case it was unclear: I am not talking about the burden on the package
> maintainer, that is small enough to not worry about. I am talking about
> information that will not be updated at all, even if the package
> maintainer wants it to be updated and provides a new package with the
> new information.

Why would it be impossible for the maintainer to update the watchfile
in his package?

> There is no point in flooding a Debian stable release
> with new package versions that merely change a watch URL.

Such changes aren't acceptable for a stable release anyways. It would
make as much sense as trying to update maintainer addresses in stable
source packages.

And, just to point out the obvious, watch files are supposed to help
with development of new versions of a package. There's simply no point
to care about them aside from the one in the newest package.


Thiemo


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

Re: dehs will stop

[Lars Wirzenius]

su, 2005-03-06 kello 21:09 +0100, Thiemo Seufer kirjoitti:
> We don't talk about automated bug filing here.

We're talking about filing over 6000 bugs for watch files. It may not be
automated, but it is mass-filing. It doesn't matter if it takes weeks or
months, it is still not a good idea. That is what I am primarily
objecting to, and what I understand Jeroen also to be objecting to.

Since there is no consensus, as far as I can see, that putting watch
files into packages is a good thing, mass-filing bugs is a really bad
idea.

>  If somebody writes
> patches to fix (valid) lintian problems it is IMHO clearly legitimate
> to file that as a wishlist bug. Of course there are bogus Lintian
> triggers, this needs to be taken into account.

Fixing packages one by one is not mass-filing bugs.

> Why would it be impossible for the maintainer to update the watchfile
> in his package?

Getting the updated package into stable is the point.

> And, just to point out the obvious, watch files are supposed to help
> with development of new versions of a package. There's simply no point
> to care about them aside from the one in the newest package.

Packages in stable may be missing from unstable, or have a different
name in unstable.


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

Re: debootstrap-farm (was: Automatic building of (parts of) the archive)

[Andreas Barth]

* Frank Küster ([EMAIL PROTECTED]) [050305 20:00]:
> While I only read it back then, I wanted to actually do the stuff
> described in the cheat sheet.  However, it mentions the command
> "debootstrap-farm".  I can't find anything about it.  What is changed in
> this command, compared to standard debootstrap?

Actually, I added all extra things in that to the commands listed, so
just use the normal debootstrap, and everything works.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C


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

Re: Shouldn't kernel-image-2.6.x-y-z depend on alsa-base ?

[Christoph Hellwig]

On Fri, Mar 04, 2005 at 02:41:27PM +0100, Josselin Mouette wrote:
> When you install an alsa-modules package for the 2.4 kernel, you get
> alsa-base per the dependencies. However, when you install sarge with a
> 2.6 kernel, alsa-base doesn't end up being installed.

It's not a depency in any way.  I play sound just fine with OSS drivers
without the ALSA mess getting in my way anywhere.


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

Re: announcing first release of common database infrastructure package

[Martin Langhoff]

Sean,

sounds really good. How do your scripts relate to the db management
scripts provided by wwwconfig-common, maintained by Ola Lundqvist
<[EMAIL PROTECTED]>?

I suspect your package should be either supercede wwwconfig-common or
be rolled into it.

cheers,



martin


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

Re: fftw3 non-pic k7 optimisations

[Paul Brossier]

On Wed, Mar 02, 2005 at 10:47:34PM +0100, Bill Allombert wrote:
> Hello Paul,
> 
> You need to refer to KP707106781KP707106781 through the GOT, something
> like
> pfmul [EMAIL PROTECTED](%ebx), %mm3

Ok, i gave it a try, it compiles and runs fine, but i still get
the 'objdump -p libfftw3f.so | grep TEXTREL' to show up.

> Why do you insist to have that code be position-independant ?

I could say because it is a 'must' in the debian policy, but...
Given that this error occurs only on i386, that fftw3 now works
fine on K7 and alike and that non-pic code does not seem to cause
too much problems, i could put a lintian override for now.
Upstream told me they will have that fixed in the next release.

> (Sorry to be pedantic, but 'PIC compliant' is meaningless: PIC is not
> a standard but an attribute)

you're not, i'm learning :)

cheers, piem


signature.asc
Description: Digital signature

Bug#298354: ITP: gtk2-engines-clearlooks -- An attractive gtk engine with a focus on usability.

[Marco Alfonso]

Package: wnpp
Severity: wishlist
Owner: Marco Alfonso <[EMAIL PROTECTED]>

* Package name: gtk2-engines-clearlooks
  Version : 0.4
  Upstream Author : Marco Alfonso <[EMAIL PROTECTED]>
* URL : http://maop.puntodeb.net/
* License : GPL
  Description : An attractive gtk engine with a focus on usability.

This is a GTK+ 2.x engine based on Bluecurve. It features a modern look
without sacrificing (much) speed.
.
Clearlooks will transform your GNOME desktop into an attractive looking
and usable environment.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.7-1-386
Locale: LANG=es_MX, LC_CTYPE=es_MX (charmap=ISO-8859-1)


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

unsubscribe

[richard]

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

Quality Loans made easy

[Pearlie Crowe]

Dear Homeowner,


You have been pre-approved for a $402,000 Home Loan at 3.45% Fixed Rate.

This offer is being extended to you unconditionally and your credit is in no 
way a factor.


To take Advantage of this Limited Time opportunity all

we ask is that you visit our Website and complete

the 1 minute post Approval Form.

http://www.easy-finances.net/1/index/bvk


Best Regards,

Pearlie Crowe
Regional CEO








shill rc architectural br prevalent ka chemist ta 
blanchard oc antiquarian hk steam rym hasp uf epidermis jbq voracity egj 
http://easy-finances.net/rem.php


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

Re: Bug#298354: ITP: gtk2-engines-clearlooks -- An attractive gtk engine with a focus on usability.

[Rob Weir]

On Sun, Mar 06, 2005 at 06:02:48PM -0600, Marco Alfonso said
> Package: wnpp
> Severity: wishlist
> Owner: Marco Alfonso <[EMAIL PROTECTED]>
> 
> * Package name: gtk2-engines-clearlooks
>   Version : 0.4
>   Upstream Author : Marco Alfonso <[EMAIL PROTECTED]>
> * URL : http://maop.puntodeb.net/

Hrm, I can't seem to find anything about it at this URL...perhaps
there's a more specific one?

-rob

-- 
Words of the day:   BRLO AK-47 Rule Psix Crowell Noriega MDA ISEC red noise


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

Re: Bug#298354: ITP: gtk2-engines-clearlooks -- An attractive gtk engine with a focus on usability.

[David Moreno Garza]

On Mon, 2005-03-07 at 14:11 +1100, Rob Weir wrote:
> On Sun, Mar 06, 2005 at 06:02:48PM -0600, Marco Alfonso said
> > Package: wnpp
> > Severity: wishlist
> > Owner: Marco Alfonso <[EMAIL PROTECTED]>
> > 
> > * Package name: gtk2-engines-clearlooks
> >   Version : 0.4
> >   Upstream Author : Marco Alfonso <[EMAIL PROTECTED]>
> > * URL : http://maop.puntodeb.net/
> 
> Hrm, I can't seem to find anything about it at this URL...perhaps
> there's a more specific one?

I think the correct thing here would be:

Richard Stellingwerff <[EMAIL PROTECTED]>
http://sourceforge.net/projects/clearlooks

Also, this is interesting:
http://www.gnomefiles.org/app.php?soft_id=810

Cheers,

--
David Moreno Garza <[EMAIL PROTECTED]> | http://www.damog.net/
 A poem is never finished, only abandoned. 
 GPG: C671257D - 6EF6 C284 C95D 78F6 0B78 FFD3 981C 5FD7 C671 257D


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

Bug#298381: ITP: lat -- Ldap Administration Tool

[Guido Trotter]

Package: wnpp
Severity: wishlist
Owner: Guido Trotter <[EMAIL PROTECTED]>

* Package name: lat
  Version : 0.3.1
  Upstream Author : Loren Bandiera <[EMAIL PROTECTED]>
* URL : http://people.mmgsecurity.com/~lorenb/lat/
* License : GPL
  Description : Ldap Administration Tool

LAT allows browsing LDAP directories and add/edit/delete entries
contained within. It can store profiles for quick access to different
servers. There are also different views available such as Users, Groups
and Hosts which allows to easily manage these objects without having to
deal with the intricacies of LDAP.



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

updated package development diagram w/new spanish translation

[Kevin Mark]

Hi tired and overworked folks, 
I recently got some help from a fellow in cuba(Maykel Moya) to translate
my diagram into spanish. I have added some bits about the autobuild
network but have not reconciled it with my original bits. On the far
right is the unincorperated bits.  Its now at:
http://debian.home.pipeline.com/ 
newdebian.png,newdebian.dia for english
newdebian.es.png,newdebian.es.dia for spanish 
the spanish version is currently a little less 'aligned'
see ya' in the funny pages,
Kev
-- 
counter.li.org #238656 -- goto counter.li.org and be counted!

(__)
(oo)
  /--\/
 / |||
*  /\---/\
   ~~   ~~
"Have you mooed today?"...


signature.asc
Description: Digital signature