Re: dehs will stop

[Steve Langasek]

On Mon, Feb 28, 2005 at 12:54:46AM -0300, Lucas Wall wrote:

> The core idea of dehs (as I understand it) is to keep track of 
> differences between the current upstream and Debian package versions. In 
> the long run dehs is intended to gather and present more information 
> than just the numerical version difference. Upstream changelog 
> fragments, bug reports or NEWS, can be easily inspected (in one place) 
> to check what upstream has done and is not yet available in a Debian 
> package.

This is a rather blue sky goal, given how much of a mixed bag upstream
changelogs are...  Doesn't seem to justify making a fuss over getting watch
files into all packages, when there are so many real, reported,
user-affecting bugs outstanding?

> The system can also be used spot MIA developers,

No, it can't: neither package out-of-dateness nor infrequency of upload is a
criterion for being considered MIA, nor should they be.  This is simply not
a good indicator of whether the package is being well-maintained.

> long forgotten package, etc.

Can't you tell that much more easily by looking at the datestamp of the most
recent upload, instead of trying to get maintainers who may already be MIA
to add files to their packages before you can get any statistics?

> Should people care about this? Well... People should care if the 
> packages lag behind upstream.

Why?

> Good maintainers will care and will build a new package when upstream
> releases or will have a good reason not to do so (and there are a couple
> of good reasons for this).

Good maintainers understand that QA is more than just getting the latest and
greatest version of the package into the archive...

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: dehs will stop

[Lucas Wall]

On 02/28/2005 02:02 AM, Andrew Suffield wrote:
On Mon, Feb 28, 2005 at 01:35:40AM -0300, Lucas Wall wrote:
Now that you have this information, do you think dehs could be useful? 
Do others think something like dehs could be useful?

As a general tool? Maybe, but how is it better than uscan, which it
duplicates?
Probably dehs would not be a replacement to uscan. People don't even 
need to use uscan to track upstream. What dehs could offer is a 
consolidated source of information and a big picture. It can also be a 
source for information you don't directly handle or would be dispersed 
and hard to harvest around the net.

As a website? No, not really. It's slow and doesn't present any views
on the information that are particularly useful and it's completely
immune to shell scripting. A web interface would appear to be the
wrong way to do this.
Agreed. Maybe dehs could provide information in a more shell friendly 
way. The web pages could just be a pretty view, used for occasional 
checks or big pictures viewing.

K.
--
Lucas Wall <[EMAIL PROTECTED]>  .''`.
Buenos Aires, Argentina: :ø :   Debian GNU/Linux
http://www.kadath.com.ar   `. `'  http://www.debian.org
PGP: 1024D/84FB46D6  `-
 5D25 528A 83AB 489B 356Ahttp://people.debian.org/~lwall
 4087 BC9B 4733 84FB 46D6mailto:[EMAIL PROTECTED]


signature.asc
Description: OpenPGP digital signature

Re: dehs will stop

[Andrew Suffield]

On Mon, Feb 28, 2005 at 01:35:40AM -0300, Lucas Wall wrote:
> Now that you have this information, do you think dehs could be useful? 
> Do others think something like dehs could be useful?

As a general tool? Maybe, but how is it better than uscan, which it
duplicates?

As a website? No, not really. It's slow and doesn't present any views
on the information that are particularly useful and it's completely
immune to shell scripting. A web interface would appear to be the
wrong way to do this.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: dehs will stop

[Lucas Wall]

On 02/28/2005 01:08 AM, Henning Makholm wrote:
Scripsit Lucas Wall <[EMAIL PROTECTED]>
On 02/27/2005 11:15 PM, Henning Makholm wrote:

Now you have a third reply: Explain why people should care, and
someone might actually start caring.

The core idea of dehs (as I understand it) is to keep track of

[snip explanation]
But why did I have to ask to get that information? Why wasn't it
included in the intial gripe about people not writing watch files, or
at least linked to? Why is it not available on the Dehs website itself?
I do not think it is justified to complain "it annoys me that people
do not do X" without at least referencing a place where people can
learn why they should do X.
I can't answer this. I don't know why this explanation is not included 
in the dehs web page, or why it wasn't mentioned with the original post.

Now that you have this information, do you think dehs could be useful? 
Do others think something like dehs could be useful?

K.
--
Lucas Wall <[EMAIL PROTECTED]>  .''`.
Buenos Aires, Argentina: :ø :   Debian GNU/Linux
http://www.kadath.com.ar   `. `'  http://www.debian.org
PGP: 1024D/84FB46D6  `-
 5D25 528A 83AB 489B 356Ahttp://people.debian.org/~lwall
 4087 BC9B 4733 84FB 46D6mailto:[EMAIL PROTECTED]


signature.asc
Description: OpenPGP digital signature

Re: dehs will stop

[Henning Makholm]

Scripsit Lucas Wall <[EMAIL PROTECTED]>
> On 02/27/2005 11:15 PM, Henning Makholm wrote:

>> Now you have a third reply: Explain why people should care, and
>> someone might actually start caring.

> The core idea of dehs (as I understand it) is to keep track of

[snip explanation]

But why did I have to ask to get that information? Why wasn't it
included in the intial gripe about people not writing watch files, or
at least linked to? Why is it not available on the Dehs website itself?

I do not think it is justified to complain "it annoys me that people
do not do X" without at least referencing a place where people can
learn why they should do X.

-- 
Henning Makholm "Nemo enim fere saltat sobrius, nisi forte insanit."


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

Re: [OT] maildir

[Henning Makholm]

Scripsit Bernd Eckenfels <[EMAIL PROTECTED]>
> In article <[EMAIL PROTECTED]> you wrote:

>> It means that the message is not marked 'new'. Many MUA's keep track
>> of message flags by inserting this header into the message.

> You mark a message as new by moving it to the "new" directory,

That's for a maildir. It won't help you for mbox folders. Which kind
of was the point, as I understand it.

-- 
Henning Makholm   "Der er ingen der sigter på slottet. D'herrer konger agter
 at triumfere fra balkonen når de har slået hinanden ihjel."

Bug#297235: ITP: duhdraw -- A ANSI Editor for Linux similar to TheDraw.

[Nelson A. de Oliveira]

Package: wnpp
Severity: wishlist
Owner: "Nelson A. de Oliveira" <[EMAIL PROTECTED]>


* Package name: duhdraw
  Version : 2.7.7
  Upstream Author : Walt Stoneburner <[EMAIL PROTECTED]>
* URL : http://www.cs.helsinki.fi/u/penberg/duhdraw/
* License : GNU Copyleft
  Description : A ANSI Editor for Linux similar to TheDraw.

DuhDraw is a program which almost perfectly simulates TheDraw for DOS.
Back in the good old BBSing days, TheDraw was a program used by a SysOp
in order to draw ANSI screens, the only graphics available on BBSes for
quite a while. However, for a long time, nobody considered Linux, as
Linux BBSes were uncommon. Other applications of the software include
login screens, and mud screens.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.10-mm3-biolinux1
Locale: LANG=pt_BR, LC_CTYPE=pt_BR (charmap=ISO-8859-1) (ignored: LC_ALL set to 
pt_BR)


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

Re: [OT] maildir

[Henning Makholm]

Scripsit Ron Johnson <[EMAIL PROTECTED]>

> Doing a "select all, and mark as read" on a multi-GB mbox file
> sounds painful.

Indeed. Or just "mark the first (or any) message as read".

If one's MUA is the version of mutt shipped with woody one gets twice
the pain because it will *first* write the updated folder to /tmp and
*then* try to move it to the final destination, usually in a home
directory on another partition. :-(  (I haven't checked whether this
happens in sarge's mutt too).

-- 
Henning Makholm   "Det er trolddom og terror
 og jeg får en værre
   ballade når jeg kommer hjem!"

Re: Let's remove mips, mipsel, s390 ... [or have strict arch: control? ]

[Goswin von Brederlow]

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:

> Rudy Godoy <[EMAIL PROTECTED]> writes:
>
>> Regarding this issue I was thinking about it since I've faced in a
>> situation where a package[0] I maintain does have "high" hardware
>> requirements, which led me to think if it is really wise to have it
>> with "arch: any" since probably in some arches it would not ever be
>> installed/used, or even if case it will run really slow or even crash
>> and the user will not enjoy the software as was intended by upstream,
>> so maybe it doesn't make sense to have this software sent to
>> autobuilders and waste their resources/time for this, probably there
>> are more software with the same kind of hw reqs. in Debian.
>
> I think it's up to the buildd folks to decide a question like this.
> They can add it to the buildd exceptions table and not build it or
> request that you take an arch out of the arch list.

Which also avoids that packages will be unavailable on every new
architecture debian introduces because the maintainer has to adjust
the Architecture: line.

The best course is to have "Architecture: any" in control and let the
arch exclude the package if it overly burdens the buildds.

Also note that each buildd has a list of package that it will only
build if idle and one for packages they won't build. The slower
buildds (not archs) can thus list long compiling packages in the
former and buildds with to little disk space can list large packages
in the later.

That means some packages will only be compiled on fast or big buildds
where they will finish in a timely manner (or at all).

MfG
Goswin


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

Re: dehs will stop

[Lucas Wall]

On 02/27/2005 11:15 PM, Henning Makholm wrote:
Now you have a third reply: Explain why people should care, and
someone might actually start caring.
The core idea of dehs (as I understand it) is to keep track of 
differences between the current upstream and Debian package versions. In 
the long run dehs is intended to gather and present more information 
than just the numerical version difference. Upstream changelog 
fragments, bug reports or NEWS, can be easily inspected (in one place) 
to check what upstream has done and is not yet available in a Debian 
package. The system can also be used spot MIA developers, long forgotten 
package, etc.

The watch file (which is a configuration file for a personal developer 
tool) is useful to start gathering this information. To a small group it 
would be a big effort to define the gathering sources for dehs for all 
packages, for a maintainer its almost trivial to write a watch file for 
his own packages.

Should people care about this? Well... People should care if the 
packages lag behind upstream. Good maintainers will care and will build 
a new package when upstream releases or will have a good reason not to 
do so (and there are a couple of good reasons for this).

Should Debian care about a system like dehs? Considering the effort 
maintainers have to do (adding a watch file) I think its worth it. 
Debian has a high commitment to QA and having a big picture of the state 
of upstream/package versions could be useful.

K.
--
Lucas Wall <[EMAIL PROTECTED]>  .''`.
Buenos Aires, Argentina: :ø :   Debian GNU/Linux
http://www.kadath.com.ar   `. `'  http://www.debian.org
PGP: 1024D/84FB46D6  `-
 5D25 528A 83AB 489B 356Ahttp://people.debian.org/~lwall
 4087 BC9B 4733 84FB 46D6mailto:[EMAIL PROTECTED]


signature.asc
Description: OpenPGP digital signature

Re: [OT] maildir

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> It means that the message is not marked 'new'. Many MUA's keep track
> of message flags by inserting this header into the message.

You mark a message as new by moving it to the "new" directory, and mark it
as seen with the "cur" directory. Flags are normally added to the file name
(by mutt for example). However some MUA-Servers need more info, which is
then stored in extra files (imap is a pathological example for excessiv
additional state)

Greetings
Bernd


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

Bug#297233: ITP: wmansied -- An ANSI/ASCII editor.

[Nelson A. de Oliveira]

Package: wnpp
Severity: wishlist
Owner: "Nelson A. de Oliveira" <[EMAIL PROTECTED]>


* Package name: wmansied
  Version : 0.4
  Upstream Author : Walter Schreppers <[EMAIL PROTECTED]>
* URL : http://www.win.ua.ac.be/~wschrep/ansied/
* License : GNU General Public Licence version 2
  Description : An ANSI/ASCII editor.

WMAnsiEd is an ANSI editor with functions like line drawing, ellipse,
box, etc., written in Qt. All IBM ANSI and ASCII characters are
included. Saved ANSI files can be shown in standard text Linux
terminals, konsole, or gnome-terminal with VGA as the font setting.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.10-mm3-biolinux1
Locale: LANG=pt_BR, LC_CTYPE=pt_BR (charmap=ISO-8859-1) (ignored: LC_ALL set to 
pt_BR)


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

Re: [OT] maildir (was Re: procmail and Large File Support)

[Ron Johnson]

On Sun, 2005-02-27 at 22:26 -0500, sean finney wrote:
> On Sun, Feb 27, 2005 at 06:51:32PM -0600, Ron Johnson wrote:
> > That seems awfully huge.  In my (Maildir) archive of d-u, the
> > average size is 4,959 bytes.  Of course, there are no html mails.
> > Though, even in my Evolution list archive, where there are many 
> > more html-mails, the average size is only 6,097.
> 
> i came up with the number by totalling the mailbox sizes of a 3000 user
> mail system, and then dividing by the total number of messages in these
> mailboxes.  this generated a number around 13k average message size.
> i had to do this as part of assessing the feasability of migrating
> to maildir without reformatting the filesystem.

Wow.  Lot's of html and lots of attachments.

It might also be useful to calculate the mode and standard deviation.
Why?  Really big attachments *might* be skewing the average.

> > > recent versions of kernel/ext2/ext3 have built-in dirent hashing, which
> > > cuts heavily on the many-files penalty.  another benefit of maildir
> > > is that when you modify a single message, you only need to modify the
> > 
> > I thought it was "illegal" to modify a message.
> 
> marking a message as read is one example.  moving a message from one
> mailbox to another is another example.  although it's not modifying the
> message itself, it's moving its location, which with a crappy imap
> server can mean re-writing the contents of two mailboxes.

*cough* wu- *cough* ;)

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA
PGP Key ID 8834C06B I prefer encrypted mail.

"Lead the people with governmental measures and regulate them by
law and punishments, and they will avoid wrongdoing, but will
have no sense of honor and shame. Lead them by virtue and
regulate them by the rules of propriety and they will have a
sense of shame and, moreover, set themselves right."
Confucius


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

Re: [OT] maildir (was Re: procmail and Large File Support)

[sean finney]

On Sun, Feb 27, 2005 at 06:51:32PM -0600, Ron Johnson wrote:
> That seems awfully huge.  In my (Maildir) archive of d-u, the
> average size is 4,959 bytes.  Of course, there are no html mails.
> Though, even in my Evolution list archive, where there are many 
> more html-mails, the average size is only 6,097.

i came up with the number by totalling the mailbox sizes of a 3000 user
mail system, and then dividing by the total number of messages in these
mailboxes.  this generated a number around 13k average message size.
i had to do this as part of assessing the feasability of migrating
to maildir without reformatting the filesystem.

> > recent versions of kernel/ext2/ext3 have built-in dirent hashing, which
> > cuts heavily on the many-files penalty.  another benefit of maildir
> > is that when you modify a single message, you only need to modify the
> 
> I thought it was "illegal" to modify a message.

marking a message as read is one example.  moving a message from one
mailbox to another is another example.  although it's not modifying the
message itself, it's moving its location, which with a crappy imap
server can mean re-writing the contents of two mailboxes.


sean

-- 


signature.asc
Description: Digital signature

Re: [OT] maildir

[Ron Johnson]

On Mon, 2005-02-28 at 02:05 +, Henning Makholm wrote:
> Scripsit Ron Johnson <[EMAIL PROTECTED]>
> > On Mon, 2005-02-28 at 11:54 +1100, Paul Hampson wrote:
> 
> >> > I thought it was "illegal" to modify a message.
> 
> >> "Status: O"?
> 
> > I don't know what that means.
> 
> It means that the message is not marked 'new'. Many MUA's keep track
> of message flags by inserting this header into the message.

Ah.  Maildir distinguishes "new" and "already read" by whether
an email is in the new/ or cur/ folder.

Doing a "select all, and mark as read" on a multi-GB mbox file
sounds painful.

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA
PGP Key ID 8834C06B I prefer encrypted mail.

If 1/2 of all US marriages end in divorce, and there are a good
number of 3rd, 4th, etc marriages, then more than 1/2 of all 1st
marriages will be permanent.


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

Re: dehs will stop

[Henning Makholm]

Scripsit Bluefuture <[EMAIL PROTECTED]>

>>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.

You are entitled to believe that the idea is not good. In that case,
I wish you the best of luck.

> I'm not a debian developer, so i could not post on dda mailing list.

How does not being a DD stop you from giving explanations elsewhere?

Your postings give me the impression that you have control of the
contents of dehs.alioth.d.o. Why do you not make that page link to an
introduction and explanation before you complain that people cannot
guess what would be there if you had bothered to write it?

> The only reply are:
>
> 1) Dehs is useless.
> 2) Submitting 6229 wishlist bug is not possible/is not the solution
> (without proposing alternatives method)

Now you have a third reply: Explain why people should care, and
someone might actually start caring.

-- 
Henning Makholm   "Det nytter ikke at flygte
   der er henna overalt"


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

Re: [OT] maildir

[Henning Makholm]

Scripsit Ron Johnson <[EMAIL PROTECTED]>
> On Mon, 2005-02-28 at 11:54 +1100, Paul Hampson wrote:

>> > I thought it was "illegal" to modify a message.

>> "Status: O"?

> I don't know what that means.

It means that the message is not marked 'new'. Many MUA's keep track
of message flags by inserting this header into the message.

-- 
Henning Makholm "That's okay. I'm hoping to convince the
  millions of open-minded people like Hrunkner Unnerby."


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

Re: [OT] maildir (was Re: procmail and Large File Support)

[Ron Johnson]

On Sun, 2005-02-27 at 20:54 -0500, Glenn Maynard wrote:
> On Sun, Feb 27, 2005 at 06:51:32PM -0600, Ron Johnson wrote:
> > > > Of course, all of these factors depend on the file system used. I am
> > > > confident somebody could point out a file-system that eliminates many
> > 
> > Reiserfs, of course.
> 
> You meant XFS, right?
> 
> (Sorry, couldn't be helped.  :)

Sure, for those *20* GB mbox files.

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA
PGP Key ID 8834C06B I prefer encrypted mail.

"Rightly hating violence, [pacifists] do not wish to recognise
that it is integral to modern society and that their own fine
feelings and noble attitudes are all the fruit of injustice
backed up by force. They do not want to learn where their incomes
come from."
George Orwell


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

Re: [OT] maildir (was Re: procmail and Large File Support)

[Glenn Maynard]

On Sun, Feb 27, 2005 at 06:51:32PM -0600, Ron Johnson wrote:
> > > Of course, all of these factors depend on the file system used. I am
> > > confident somebody could point out a file-system that eliminates many
> 
> Reiserfs, of course.

You meant XFS, right?

(Sorry, couldn't be helped.  :)

-- 
Glenn Maynard


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

Re: dehs will stop

[Bluefuture]

>The community might start considering it less useless if an
>explanation of what it is supposed to be good for was actually
>available. In particular, why should a maintainer care about watch
>files if he uses something else than uscan to keep track of upstream
>happenings?

>From time to time, these little microthreads start on d-d where
>somebody complains that so and so many packages do not have watch
>files, but it seems always to be left entirely to the reader's
>imagination to figure out why that is apparently a bad thing.
>If I go to, say,  in search of
>information, I find not a single word of purpose or rationale.

>The only places I can see watch files mentioned in our general
>"required reading" documentation (twice in NM-guide and once in
>dev-ref), they are presented exclusively as a maintainer convenience
>tool.

>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'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. 

If the watch file is well done - preferring ftp and http download
address instead of html pages - dehs try to catch in his archive also
the UPSTREAM changelog/news as you can see here[2] clicking on the
upstream version. 
So we (all other user and developer that doesn't maintain the package)
can check features and upstream bugs fixed in the new
usptream release and the upstream bugs that we still had in debian and
features we doesn't had for packages that are not in sync with upstream
version or that ones that the maintainer had not packaged for more then
one
release. 
So we can start to check things like maintainer activity, vacation, mia,
see if the maintainer is simple too busy (we will could add in future in
dehs archive the upstream release date field and the debian package
upload date - for this task we need some collaboration from the uscan
developer). Then after this check, if we doesn't had a clear situation
about the upstream  we could email to the maintainer what is the problem
about packaging the new version (if months has passed from the upstream
release and the maintainer doesn't has prepared uploaded the package in
debian). 
We could have for reply that the new release is not in a good
and stable shape, or that he need a library not already packaged in
debian etc. etc.
I think that also monitoring upstream bugs fixed, and new feature we
could make a better distro and not only fixing bugs and put in an
harmonic shape all the packages
in debian but also getting what the upstream authors offer to debian and
to the all the linux distros with his upstream releases and development
work. 

[1] http://dehs.alioth.debian.org/no_updated.html


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

Re: dehs will stop

[Bluefuture]

>I know that I thougt dehs per se not too useful, but the watch section
>on qa.d.o has inspired me to write watch files for two of my packages.
>Not much (2 out of 7), admittedly, but I think that it's fairly useful.
>I think the experimental columns are overkill (as people packaging
>experimental stuff probably monitor upstream releases even more
>closely).
>If 25% of the packages can be watched, hey, that's a fair share.

Are we still talking around dehs as a personal  developer tool?

Is It a so hard work to add this watch file, only as an example for some
of your package i had built it in some minutes:

xml2

version=2
http://download.ofb.net/gale/xml2-([\d\.]+)\.tar\.gz 

xtermset
--
version=2
ftp://ftp2.sf.net/pub/sourceforge/c/cl/clts/xtermset-([\d\.]+)\.tar\.gz

ferm
---
version=2
http://ferm.sourceforge.net/ferm-([\d\.]+)\.tar\.gz

If we still think to fix watch file only for application that we doesn't
strictly follow this will not help dehs. You must fill every file watch
for everyone of your package that had a valid upstream and acessible
repo. We all know naturally some exceptions like only as example if
there aren't available tarball releases/snapshot but u build your
package from cvs/svn/arch.


Tanks,
Stefano


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

Re: [OT] maildir (was Re: procmail and Large File Support)

[Ron Johnson]

On Mon, 2005-02-28 at 11:54 +1100, Paul Hampson wrote:
> On Sun, Feb 27, 2005 at 06:51:32PM -0600, Ron Johnson wrote:
> > On Sun, 2005-02-27 at 18:19 -0500, sean finney wrote:
> > > recent versions of kernel/ext2/ext3 have built-in dirent hashing, which
> > > cuts heavily on the many-files penalty.  another benefit of maildir
> > > is that when you modify a single message, you only need to modify the
> 
> > I thought it was "illegal" to modify a message.
> 
> "Status: O"?

I don't know what that means.

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA
PGP Key ID 8834C06B I prefer encrypted mail.

"I take my children everywhere, but they always find their way
back home."
Robert Orben


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

Re: [OT] maildir (was Re: procmail and Large File Support)

[Paul Hampson]

On Sun, Feb 27, 2005 at 06:51:32PM -0600, Ron Johnson wrote:
> On Sun, 2005-02-27 at 18:19 -0500, sean finney wrote:
> > recent versions of kernel/ext2/ext3 have built-in dirent hashing, which
> > cuts heavily on the many-files penalty.  another benefit of maildir
> > is that when you modify a single message, you only need to modify the

> I thought it was "illegal" to modify a message.

"Status: O"?

-- 
---
Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---


signature.asc
Description: Digital signature

Re: [OT] maildir (was Re: procmail and Large File Support)

[Ron Johnson]

On Sun, 2005-02-27 at 18:19 -0500, sean finney wrote:
> can't help but chime in here :)
> 
> On Mon, Feb 28, 2005 at 09:22:30AM +1100, Brian May wrote:
[snip]
> 
> figuring the average email is about 13-15k, i believe an ext2/ext3

That seems awfully huge.  In my (Maildir) archive of d-u, the
average size is 4,959 bytes.  Of course, there are no html mails.
Though, even in my Evolution list archive, where there are many 
more html-mails, the average size is only 6,097.

> filesystem created with default options would fill up before running
> out of inodes.
> 
> > Of course, all of these factors depend on the file system used. I am
> > confident somebody could point out a file-system that eliminates many

Reiserfs, of course.

> > of these disadvantages.
> 
> recent versions of kernel/ext2/ext3 have built-in dirent hashing, which
> cuts heavily on the many-files penalty.  another benefit of maildir
> is that when you modify a single message, you only need to modify the

I thought it was "illegal" to modify a message.

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA
PGP Key ID 8834C06B I prefer encrypted mail.

"He was about as useful in a crisis as a sheep."
Dorothy Eden


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

Re: dehs will stop

[Henning Makholm]

Scripsit Bluefuture <[EMAIL PROTECTED]>

> There is no reason to put more work and effort on a community tool that
> community itself consider useless.

The community might start considering it less useless if an
explanation of what it is supposed to be good for was actually
available. In particular, why should a maintainer care about watch
files if he uses something else than uscan to keep track of upstream
happenings?

>From time to time, these little microthreads start on d-d where
somebody complains that so and so many packages do not have watch
files, but it seems always to be left entirely to the reader's
imagination to figure out why that is apparently a bad thing.
If I go to, say,  in search of
information, I find not a single word of purpose or rationale.

The only places I can see watch files mentioned in our general
"required reading" documentation (twice in NM-guide and once in
dev-ref), they are presented exclusively as a maintainer convenience
tool.

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?

-- 
Henning Makholm"Nu kommer han. Kan du ikke høre knallerten?"

Re: Bug#297218: ITP: radeontool -- utility to control ATI Radeon backlight functions on laptops

[Luigi Gangitano]

Il giorno lun, 28-02-2005 alle 00:10 +0100, Luigi Gangitano ha scritto:
> Package: wnpp
> Severity: wishlist
> Owner: Luigi Gangitano <[EMAIL PROTECTED]>
> 
> * Package name: radeontool
>   Version : 1.5
>   Upstream Author : Frederick Dean <[EMAIL PROTECTED]>
> * URL : http://fdd.com/software/radeon/
> * License : zlib license
>   Description : utility to control ATI Radeon backlight functions on 
> laptops

You can find (and review) a preliminary package at

  http://people.debian.org/~luigi/radeontool

Regards,

-- 
 Luigi Gangitano -- <[EMAIL PROTECTED]> -- <[EMAIL PROTECTED]>
 GPG: 1024D/924C0C26: 12F8 9C03 89D3 DB4A 9972  C24A F19B A618 924C 0C26


signature.asc
Description: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata

Re: dehs will stop

[Stephen Gran]

This one time, at band camp, Thomas Viehmann said:
> Hi Stefano,
> 
> Bluefuture wrote:
> >I know that there are a little bit group of people that think that the
> >"old" use of watch file could be converted in a Qa tools, but actually
> >i'm the only one that is trying to find a solution that could fix that
> >lack of watch file. 
> >But without maintainers interest, the project still lack in an usable
> >status. 
> >There is no reason to put more work and effort on a community tool that
> >community itself consider useless.
> >I hope that something could change. But i don't belive it.
> I know that I thougt dehs per se not too useful, but the watch section 
> on qa.d.o has inspired me to write watch files for two of my packages. 
> Not much (2 out of 7), admittedly, but I think that it's fairly useful. 
> I think the experimental columns are overkill (as people packaging 
> experimental stuff probably monitor upstream releases even more closely).
> If 25% of the packages can be watched, hey, that's a fair share.

Just my 2 cents, but I agree - only two of my packages have useful (and
really, alive) upstreams, so they are the only ones with watch files.
That doesn't mean it's unhelpful though - it alerted me to a new hdparm
before I would otherwise have known.

Thanks for your efforts.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


pgpgdWtIXcxQ7.pgp
Description: PGP signature

Bug#297218: ITP: radeontool -- utility to control ATI Radeon backlight functions on laptops

[Luigi Gangitano]

Package: wnpp
Severity: wishlist
Owner: Luigi Gangitano <[EMAIL PROTECTED]>

* Package name: radeontool
  Version : 1.5
  Upstream Author : Frederick Dean <[EMAIL PROTECTED]>
* URL : http://fdd.com/software/radeon/
* License : zlib license
  Description : utility to control ATI Radeon backlight functions on laptops

This small utility control backlight functions in ATI Mobile based video cards.
It can power on/off backlight and external output.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.10
Locale: LANG=it_ITeuro, LC_CTYPE=it_ITeuro (charmap=ISO-8859-15) (ignored: 
LC_ALL set to [EMAIL PROTECTED])


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

[OT] maildir (was Re: procmail and Large File Support)

[sean finney]

can't help but chime in here :)

On Mon, Feb 28, 2005 at 09:22:30AM +1100, Brian May wrote:
> Not every situation warrants using maildir, it uses a large number of
> inodes, is slow to scan (yes, mbox isn't very good either),
> inefficient at storing large number of very small files (due to block
> size limitations of file system), and more complicated to
> transfer/move/share.

it does use a large number of inodes, but i've found that even on large
filesystems with many users, there's not a real risk of starving the fs
of inodes.  ymmv.  i'm not sure about the transferring/moving/sharing though.

figuring the average email is about 13-15k, i believe an ext2/ext3
filesystem created with default options would fill up before running
out of inodes.

> Of course, all of these factors depend on the file system used. I am
> confident somebody could point out a file-system that eliminates many
> of these disadvantages.

recent versions of kernel/ext2/ext3 have built-in dirent hashing, which
cuts heavily on the many-files penalty.  another benefit of maildir
is that when you modify a single message, you only need to modify the
individual file, as opposed to the entire mailbox.  in some of the
sloppier imap servers (*cough* uw-imap *cough* *cough*), this can cause
huge, grind-your-server-to-a-halt performance hits as deleting, or
merely reading a new message necessates a huge amount of i/o.


sean


-- 


signature.asc
Description: Digital signature

Re: Let's remove mips, mipsel, s390 ... [or have strict arch: control? ]

[Thomas Bushnell BSG]

Rudy Godoy <[EMAIL PROTECTED]> writes:

> Regarding this issue I was thinking about it since I've faced in a
> situation where a package[0] I maintain does have "high" hardware
> requirements, which led me to think if it is really wise to have it
> with "arch: any" since probably in some arches it would not ever be
> installed/used, or even if case it will run really slow or even crash
> and the user will not enjoy the software as was intended by upstream,
> so maybe it doesn't make sense to have this software sent to
> autobuilders and waste their resources/time for this, probably there
> are more software with the same kind of hw reqs. in Debian.

I think it's up to the buildd folks to decide a question like this.
They can add it to the buildd exceptions table and not build it or
request that you take an arch out of the arch list.

But I would rely on them to take the initiative.  It can be the right
thing to do, but I would be annoyed if I had such a machine, and the
maintainer of the package decided it "couldn't" work on mine when I
knew it actually could.

Thomas


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

Re: procmail and Large File Support

[Brian May]

> "Colin" == Colin Watson <[EMAIL PROTECTED]> writes:

Colin> Not everyone likes maildir; I gave up on it after
Colin> experimenting with it and realising that making it harder
Colin> for myself to use standard Unix text-processing tools on my
Colin> mailboxes was just too annoying. This is true of spam-bin
Colin> folders more than other folders, if anything.

Not every situation warrants using maildir, it uses a large number of
inodes, is slow to scan (yes, mbox isn't very good either),
inefficient at storing large number of very small files (due to block
size limitations of file system), and more complicated to
transfer/move/share.

Of course, all of these factors depend on the file system used. I am
confident somebody could point out a file-system that eliminates many
of these disadvantages.

The major benefits of Maildir, IIRC, seem to be:

* No locking required for mail delivery. Not all folders require this.

* More robust separation of messages (only an issue because
  mbox. standards are so pathetic and everybody has there own ideas
  what constitutes a reliable method to detect the end of a
  message). So what appears to be to separate messages contained in
  mbox format in mutt can be interpreted as only one message by
  formail (see bug #295604 for example).
-- 
Brian May <[EMAIL PROTECTED]>


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

Re: dh_movefiles, tar vs. mv

[Adeodato Simó]

* Brian May [Mon, 28 Feb 2005 09:05:01 +1100]:

> A benefit of moving files, rather then copying, is that you get to see
> at a glance what files your package left behind and missed in
> debian/tmp (e.g. if upstream adds new files to the packages but
> doesn't document these additions).

  FWIW, there is always dh_install --no-act --list-missing.

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
He has never been known to use a word that might send a reader to the
dictionary.
-- William Faulkner (about Ernest Hemingway)


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

Re: dh_movefiles, tar vs. mv

[Brian May]

> "Christoph" == Christoph Berg <[EMAIL PROTECTED]> writes:

Christoph> As I understood it, the question was about moving stuff
Christoph> from debian/tmp to debian/package. The stuff in
Christoph> debian/tmp should get removed by the clean target
Christoph> anyway, so it doesn't hurt to move instead of copying
Christoph> it.

A benefit of moving files, rather then copying, is that you get to see
at a glance what files your package left behind and missed in
debian/tmp (e.g. if upstream adds new files to the packages but
doesn't document these additions).
-- 
Brian May <[EMAIL PROTECTED]>


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

Re: Looking for someone to adopt pdftohtml

[Frederic Peters]

Søren Boll Overgaard wrote:

> So, if anyone uses or cares about pdftohtml, please step up, otherwise I will
> work out an arrangement with the maintainer of the depending package mentioned
> above.

I use pdftohtml in a private project (actually only pdftohtml -xml for
its XML output) and will adopt pdftohtml if nobody steps up.


Frederic


signature.asc
Description: Digital signature

Looking for someone to adopt pdftohtml

[Søren Boll Overgaard]

Hello,

I am currently maintaning pdftohtml in Debian, but I would like for someone
else to take over maintenance[1].

Lately, a few security related bugs have come up. They have been fixed in
NMU's, which has apparently introduced bugs causing segfaults. I haven't had the
time to research the bugs, nor do I feel very motivated. Upstream no longer
supports pdftohtml. One package in the archive unfortunately depends on
pdftohtml, so removing it is not entirely straightforward, even though that
would probably be the best thing to do.

So, if anyone uses or cares about pdftohtml, please step up, otherwise I will
work out an arrangement with the maintainer of the depending package mentioned
above.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=293870

-- 
Søren O.   ,''`.
  : :' :
GPG key id: 0x1EB2DE66`. `'
GPG signed mail preferred.  `-


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

self-depending packages

[Nicolas Boullis]

Hi,

Trying to upgrade a woody system to sarge, I experienced problems 
upgrading libgtk2.0-0, and discovered that this packages was 
self-depending. Afetr forcing the upgrade with "dpkg -i --force-depends", 
everything went smoothly. So I filed a bug against libgtk2.0-0.
Then I discovered that I could upgrade this package from woody to sarge 
with no trouble in a clean pbuilder chroot. So the problem might me more 
complex.

However, from this bug report began a discussion with Loic Minier about 
self-dependencies and circular dependencies.

Readibg policy 7.2, I see:
"
Depends
This declares an absolute dependency. A package will not be 
configured unless all of the packages listed in its Depends field 
have been correctly configured.
"

My understanding is that a self-depending package must be configured 
before it can be configured, which makes it unconfigurable, and hence 
uninstallable. And I think the same reasoning can be applied to 
circular dependencies. But Loic disagrees.

What is the opinion of others? Shouldn't policy be more explicit about 
circular (and self) dependencies?


Moreover, I just wrote a small python script that looks for 
self-dependencies in sarge, and found those packages:
libtabe2
libtextwrap1
gnustep-back
libbonoboui2-0
libgail-common
libbonobo2
libgtk2.0-0

Should a bug be filed against those packages?


Cheers,

Nicolas


PS: please CC your replies to me, as I am currently quite unable to 
track debian-devel. (MFT set accordingly)


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

Re: dehs will stop

[Thomas Viehmann]

Hi Stefano,
Bluefuture wrote:
I know that there are a little bit group of people that think that the
"old" use of watch file could be converted in a Qa tools, but actually
i'm the only one that is trying to find a solution that could fix that
lack of watch file. 
But without maintainers interest, the project still lack in an usable
status. 
There is no reason to put more work and effort on a community tool that
community itself consider useless.
I hope that something could change. But i don't belive it.
I know that I thougt dehs per se not too useful, but the watch section 
on qa.d.o has inspired me to write watch files for two of my packages. 
Not much (2 out of 7), admittedly, but I think that it's fairly useful. 
I think the experimental columns are overkill (as people packaging 
experimental stuff probably monitor upstream releases even more closely).
If 25% of the packages can be watched, hey, that's a fair share.

Kind regards
T.
--
Thomas Viehmann, http://thomas.viehmann.net/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

dehs will stop

[Bluefuture]

After another gruelling discussion on #debian-devel about the useless of
dehs and the lack of watch file (75,60% of non native debian packages
doesn't had one), I think that dehs is start to begin only my own
personal toys, so i'm thinking to stop it and to leave alioth resources
and put my development effort on something more useful to the community.

I know that there are a little bit group of people that think that the
"old" use of watch file could be converted in a Qa tools, but actually
i'm the only one that is trying to find a solution that could fix that
lack of watch file. 
But without maintainers interest, the project still lack in an usable
status. 
There is no reason to put more work and effort on a community tool that
community itself consider useless.

I hope that something could change. But i don't belive it.

Cheers,
Stefano


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

fw: high cholesterol breakthrough discovery - pancake

[Dr. Ashley]

From: August<[EMAIL PROTECTED]> 
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> ; [EMAIL PROTECTED]
<[EMAIL PROTECTED] >; 
--

Flozar Heart Health News:

Breakthrough Natural Cholesterol Reduction System:

No Dangerous side effects such as dizziness, nausea, yellow skin & more.

http://ouw.anationpickle.com/2fl2/ 

Try Flozar for 30 days - if you AND your physicial are not amazed,
return for full refund.

worshipful  knowledgeable  helium 

- Sent to debian-devel@lists.debian.org based on previous subscrition request 
on Sun, 27 Feb 2005 18:44:38 -0300

to opt-out please click: www.wallaceentry.com/ach/  .

Sent by TripleHelath network LTD
402 Berkshire Road
Bermuda, Bermuda, L2A4H0


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

Re: Statically linked binaries from fpc

[Florian Weimer]

* Roland Stigge:

> Unfortunately, fpc in Debian produces statically linked binaries, due to
> the Pascal unit style library files. We currently don't have other
> packages in the archive that Build-Depend on fp-compiler (except fpc
> itself which indeed carries statically linked binaries) as examples.
>
> Any suggestions? Should I just upload it that way?

Yes, policy permits statically linked binaries if the development
environment does not permit dynamic linking (or the library ABI
changes too rapidly).


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

Re: Let's remove mips, mipsel, s390 ... [or have strict arch: control? ]

[Rudy Godoy]

On 22/02/2005 at 10:11 Wouter Verhelst wrote...

 
> I agree that we should not continue to provide software for outdated
> hardware platforms just for the sake of it; but as it is, there are
> still people interested in m68k (some hobbyists, some embedded
> developers, some who just use their old trusty hardware as their home
> firewall, etc) and, I'm sure, other currently less-used hardware, so as
> long as a port doesn't continually stall the release (which none
> currently does; there are occasionally problems, but that happens in
> every major undertaking), I see no reason to drop any port.
> 

Regarding this issue I was thinking about it since I've faced in a
situation where a package[0] I maintain does have "high" hardware
requirements, which led me to think if it is really wise to have it
with "arch: any" since probably in some arches it would not ever be
installed/used, or even if case it will run really slow or even crash
and the user will not enjoy the software as was intended by upstream,
so maybe it doesn't make sense to have this software sent to
autobuilders and waste their resources/time for this, probably there
are more software with the same kind of hw reqs. in Debian.

I think if each package does specify the arches where it could 
*actually* be used/installed will save time and resources, which can be used
the most urgent/important ones, so in the end this probably would help the
situation for buildds' disk space, mirrors claiming not having disk
space to add another arch, large queue on buildds and posibibly make
life easier for porters and Debian releases.

I don't know much about buildd infrastructure[1], if such thing was
proposed or commented before (didn't check archives), if there's
another way to handle this, or if such things probably could be better
handled as a policy (to enforce and be more strict on this due growing
number of packages) for maintainers double check the arch: line to
question themselves if its really worth to have "any" or just put
there only the ones which does. I'd rather be more helpful than "hey
let's do this" but imho this could be easily addressed by encouraging to
double checking "arch", unless there are better options.

regards,
Rudy

0- torcs, a 3D OpenGL game, it needs at least 550MHZ CPU, >32MB OpenGL
1.3 Video Card and so on... upstream says it works on i386 and ppc
(both confirmed by me) but have no news from other', it has built
sucessful though.

1- although this tread is very informative 

-- 
Rudy Godoy | 0x3433BD21 | http://stone-head.org   ,''`.
http://www.apesol.org  -  http://www.debian.org  : :' :
GPG FP: 0D12 8537 607E 2DF5 4EFB  35A7 550F 1A00 3433 BD21   `. `'
   `-


signature.asc
Description: Digital signature

Statically linked binaries from fpc

[Roland Stigge]

Hi,

maintaining m-tx, I would like to move from the p2c generated C sources
to the original upstream Pascal sources (better suited for patches,
development, design, etc.).

m-tx is written in a Turbo Pascal dialect that can only be compiled with
fpc (not gpc).

Unfortunately, fpc in Debian produces statically linked binaries, due to
the Pascal unit style library files. We currently don't have other
packages in the archive that Build-Depend on fp-compiler (except fpc
itself which indeed carries statically linked binaries) as examples.

Any suggestions? Should I just upload it that way?

Thanks in advance!

bye,
  Roland
-- 


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

Re: Bug#297121: ITP: wmail -- WindowMaker docklet watching your inbox

[Julien Danjou]

On Sun, Feb 27, 2005 at 12:23:02PM +0100, Peter Palfrader wrote:
> Is it still actively maintained upstream?  It doesn't look that way.
> I doubt that it's a good idea to add new software to debian when
> upstream lost interest - unless you are prepared to take that over too.

Yes, I am.

Regards,
-- 
Julien Danjou
.''`.  Debian developer
: :' : http://julien.danjou.info
`. `'  http://people.debian.org/~acid
  `-   9A0D 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD


signature.asc
Description: Digital signature

Re: Bug#297121: ITP: wmail -- WindowMaker docklet watching your inbox

[Peter Palfrader]

On Sun, 27 Feb 2005, Julien Danjou wrote:

> * Package name: wmail
>   Version : 2.0
>   Upstream Author : Sven Geisenhainer <[EMAIL PROTECTED]>
> * URL : http://dockapps.org/file.php/id/70
> * License : Seems specific, but free and probably GPL-compatible
>   Description : WindowMaker docklet watching your inbox
> 
> 
> wmail is a Window Maker docklet watching your inbox

Is it still actively maintained upstream?  It doesn't look that way.
I doubt that it's a good idea to add new software to debian when
upstream lost interest - unless you are prepared to take that over too.


-- 
 PGP signed and encrypted  |  .''`.  ** Debian GNU/Linux **
messages preferred.| : :' :  The  universal
   | `. `'  Operating System
 http://www.palfrader.org/ |   `-http://www.debian.org/


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

Re: Bug#296873: ITP: jackbeat -- a drummachine-like audio sequencer with JACK support

[Matijs van Zuijlen]

On Fri, Feb 25, 2005 at 12:02:35PM +0100, Guillaume Pellerin wrote:
>   Jackbeat is an audio sequencer with the following features :
> 
>   * drummachine-like interface for fast and easy edition

"edition" doesn't mean the same thing in English as in French. I think the
word you want here is "editing".

-- 
Matijs van Zuijlen  http://www.matijs.net/


signature.asc
Description: Digital signature

Bug#297121: ITP: wmail -- WindowMaker docklet watching your inbox

[Julien Danjou]

Package: wnpp
Severity: wishlist
Owner: Julien Danjou <[EMAIL PROTECTED]>

* Package name: wmail
  Version : 2.0
  Upstream Author : Sven Geisenhainer <[EMAIL PROTECTED]>
* URL : http://dockapps.org/file.php/id/70
* License : Seems specific, but free and probably GPL-compatible
  Description : WindowMaker docklet watching your inbox


wmail is a Window Maker docklet watching your inbox, which is either a
ordinary mbox or a directory conforming to qmails Maildir format. It
provides a nice little GUI displaying some useful pieces of information
about your inbox (as many other nice wm-apps doing nearly the same
thing...). Per default it uses the $MAIL environment-variable to locate
the inbox you are using, other mailing mechanisms like POP or IMAP are
not supported - use a tool like fetchmail to retrieve POP- or IMAP-based
mail.

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

-- 
Julien Danjou
// <[EMAIL PROTECTED]> http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD


signature.asc
Description: Digital signature