Re: possible freetype transition; improved library handling needed for all C/C++ packages

[Daniel Schepler]

Le Vendredi 25 Novembre 2005 02:38, Steve Langasek a écrit :
> > Try debian/patches/common/07_disable_no_undefined.diff from any of the
> > core KDE packages.
>
> Er... that doesn't sound like a good thing, why would you want to allow
> undefined references?

If I recall correctly, the -no-undefined flag was being used along with 
--allow-undefined as an attempt to make all templates used by a library be 
instantiated.  Unfortunately, that _depended_ on libtool's broken behavior; 
without a full list of libraries, the link spews loads of undefined symbol 
warnings.  (Back when I wrote the patch, the link would actually succeed 
eventually despite all the warnings, but that might have changed since then.)

With the patch, KDE falls back to its old behavior of resolving this by 
linking a fake object file against the library object files before linking 
the libraries.
-- 
Daniel Schepler

Re: dpkg-sig support wanted?

[Anthony Towns]

On Sat, Nov 26, 2005 at 11:10:27PM -0600, Peter Samuelson wrote:
>   sha256sum () {
> (Implementation of -c left as an exercise, etc.)

Hrm, if we're writing our own thing, maybe we should do it properly:
have a single program that can do multiple hash algorithms, have the
default hash be secure, and update it in future, and so on.

gnupg comes close to being this, except for two things: it's got too
many dependencies, and it's command line arguments are overly complex. A
"gpgh" variant (like gpgv but for hashing) might work, though. It
doesn't support --check, and "gpg --print-md md5 /etc/motd" has a
different format to "md5sum /etc/motd" though.

Of course, if we're doing it "right", we probably want to have some way
of telling what hash was used, so we don't have to wonder whether a
given 160bit hash is sha1 or ripemd160 or something else that gets
cooked up in future. OpenBSD's cksum apparently does this, by having its
output be:

  MD5 (filename) = hash

That strikes me as pretty inconvenient, but cksum does do most of what we
want.

OTOH, it would be far more convenient for *us* if it supported the
.changes style we use, ie:

  MD5Sum:
hash size filename

Then there are the encoding questions; both the one above (do we switch
from hexadeximal to something more compact for longer hashes?) and also
the question of what happens if there's a ")" or a "\n" in the filename
-- is it worth doing some sort of http-style % encoding that apt uses
in that case?

Something like this might work well:

  $ dsum -a sha1 foo; sha1sum foo
  f572d396fae9206628714fb2ce00f72e94f2258f  foo
  f572d396fae9206628714fb2ce00f72e94f2258f  foo

  $ dsum -d foo
  SHA1Sum:
   f572d396fae9206628714fb2ce00f72e94f2258f 6 foo

  $ dsum -b foo
  SHA1 (foo) = f572d396fae9206628714fb2ce00f72e94f2258f

  $ dsum -d foo | dsum --check; echo $?
  0

  $ dsum -b foo | dsum --check; echo $?
  0

Though what "dsum foo" should do is a trickier question (particularly
whether it's better to be compatible with current md5sum/sha1sum
output, or if "dsumA foo > foo.sum" and "dsumB --check < foo.sum" will
work if dsumA's default cypher is sha1 and dsumB's is ripemd160).

(Note that "dsum" would probably need to become Priority:required,
and possibly Essential:yes, with the complications that entails)

Cheers,
aj



signature.asc
Description: Digital signature

Re: texlive-basic_2005-1_i386.changes REJECTED

[Norbert Preining]

Hi Jörg, hi ftpmasters!


On Mon, 28 Nov 2005, Norbert Preining wrote:
> > binary. Better merge them into one texlive-source and build the
> > different binary packages out of that one. You are left with 47 sources..
> > 
> > Similar things can be said for the language packs, merge the *27* to one
> > and built the binaries out of that. Down to 21 sources. :)
> 
> Ok, this is no problem. The .orig.tar.gz will be bigger, but I can merge
> the source packages without any problem.

What do you thing about this scheme:
(source package with size of the .orig.tar.gz, plus included binary
packages)
Would this be an acceptable solution for you?

texlive-binaries-source 96M
texlive-basicbin
texlive-binextra
texlive-fontbin
texlive-htmlxml
texlive-metapost
texlive-omega
texlive-pdfetex
texlive-psutils
texlive-ttfutils
texlive-music
texlive-langindic
texlive-graphicstools
texlive-langcjk

texlive-documentation-source57M
texlive-documentation-base  
texlive-documentation-bulgarian
texlive-documentation-czechslovak
texlive-documentation-dutch
texlive-documentation-english
texlive-documentation-finnish
texlive-documentation-french
texlive-documentation-german
texlive-documentation-greek
texlive-documentation-italian
texlive-documentation-japanese
texlive-documentation-korean
texlive-documentation-mongolian
texlive-documentation-polish
texlive-documentation-portuguese
texlive-documentation-russian
texlive-documentation-spanish
texlive-documentation-thai
texlive-documentation-ukrainian

texlive-languages-source37M
texlive-langafrican
texlive-langarab
texlive-langarmenian
texlive-langcroatian
texlive-langcyrillic
texlive-langczechslovak
texlive-langdanish
texlive-langdutch
texlive-langfinnish
texlive-langfrench
texlive-langgerman
texlive-langgreek
texlive-langhebrew
texlive-langhungarian
texlive-langitalian
texlive-langlatin
texlive-langmanju
texlive-langmongolian
texlive-langnorwegian
texlive-langother
texlive-langpolish
texlive-langportuguese
texlive-langspanish
texlive-langswedish
texlive-langtibetan
texlive-langukenglish
texlive-langvietnamese

texlive-base-source 78M
texlive-basic
texlive-context
texlive-genericrecommended
texlive-latex
texlive-latexrecommended
texlive-fontsrecommended
texlive-pictures

texlive-extra-source172M
texlive-bibtexextra
texlive-formatsextra
texlive-genericextra
texlive-mathextra
texlive-plainextra
texlive-latexextra
texlive-latex3
texlive-fontsextra
texlive-chemistry
texlive-games
texlive-pstricks
texlive-publishers

Best wishes

Norbert

---
Dr. Norbert Preining  Università di Siena
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
MEATH (adj.)
Warm and very slightly clammy. Descriptive of the texture of your
hands after the automatic drying machine has turned itself off, just
damp enough to make it embarrassing if you have to shake hands with
someone immediately afterwards.
--- Douglas Adams, The Meaning of Liff


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

Re: texlive-basic_2005-1_i386.changes REJECTED

[Miles Bader]

BTW I think you need a few more hyphens in your package names -- stuff
like "texlive-langtibetan" and "texlive-fontsrecommended" read much
nicely as "texlive-lang-tibetan" and "texlive-fonts-recommended".

-miles
-- 
`There are more things in heaven and earth, Horatio,
 Than are dreamt of in your philosophy.'


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

Re: texlive-basic_2005-1_i386.changes REJECTED

[Frank Küster]

Norbert Preining <[EMAIL PROTECTED]> wrote:

> What do you thing about this scheme:
> (source package with size of the .orig.tar.gz, plus included binary
> packages)
> Would this be an acceptable solution for you?
>
[...]
> texlive-documentation-source  57M
>   texlive-documentation-base  
> texlive-documentation-bulgarian
[...]
> texlive-languages-source  37M
[...]
>
> texlive-base-source   78M
> texlive-basic
[...]
>
> texlive-extra-source  172M
> texlive-bibtexextra

Whether this is a good idea depends on a decision that, IIRC, we have
not yet talked about:  Will you only provide packages of the released
version, or also of (usable) development versions?  In the latter case,
I think it would be a good idea to keep documentation sources and TeX
input file sources together.  Otherwise you'd have to rebuilt all
packages from texlive-documentation-source and texlive-languages-source
just because one language package was updated on CTAN and mirrored in
TeXLive. 

And generally I wonder:  Don't you generate most of the documentation
from dtx files, and many input files from the same dtx files?  Then why
not build most documentation packages from the same source as the TeX
input files?  Or are the input files already included in the TeXlive
repository in their extract version?

Regards, Frank

-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: texlive-basic_2005-1_i386.changes REJECTED

[Rogério Brito]

On Nov 28 2005, Norbert Preining wrote:
> Hi Jörg, hi ftpmasters!

Hi, Norbert, Jörg and others.

Here is the opinion of a long time Debian luser (and DD wannabe), based
on the naming that I am already used to with other packages.

> texlive-binaries-source   96M
>   texlive-basicbin
What about texlive-bin-base?

>   texlive-binextra
texlive-bin-extra?

>   texlive-fontbin
texlive-bin-font?

>   texlive-langindic
texlive-lang-indic?

>   texlive-langcjk
texlive-lang-cjk?

> texlive-documentation-source  57M
>   texlive-documentation-base  
texlive-base-doc?

> texlive-documentation-bulgarian
texlive-bulgarian-doc?

> texlive-documentation-czechslovak
texlive-czechslovak-doc?
(...)

And similarly for all the others:

texlive--doc? Or, perhaps:
texlive-lang--doc (see this to avoid confusion with the
packages below).

> texlive-languages-source  37M
> texlive-langafrican
(...)
> texlive-langvietnamese

What about:
texlive-lang-african?
(...)
texlive-lang-vietnamese?

With this scheme, the user would have two packages, possibly:
texlive-lang- and
texlive-lang--doc
and this would make it more or less obvious what the packages are
about. What do you think?

> texlive-base-source   78M
> texlive-genericrecommended
texlive-generic-recommended?

> texlive-latexrecommended
texlive-latex-recommended?

> texlive-fontsrecommended
texlive-fonts-recommended?

> texlive-extra-source  172M
> texlive-bibtexextra
texlive-bibtex-extra?

> texlive-formatsextra
texlive-formats-extra?

> texlive-genericextra
texlive-generic-extra?

> texlive-mathextra
texlive-math-extra?

> texlive-plainextra
texlive-plain-extra?

> texlive-latexextra
texlive-latex-extra?

> texlive-fontsextra
texlive-fonts-extra?

(...)
> texlive-chemistry
> texlive-games
> texlive-pstricks
> texlive-publishers

Since there and others are generated by texlive-extra-source, it would
perhaps be a possibility to append -extra to their names, so that the
users already used to the Debian naming would automatically know that
they are extra packages.

Please sorry if I am talking nonsense here, but I'm sleep deprived. :-(


Thanks for all your work, Rogério Brito.

-- 
Rogério Brito : [EMAIL PROTECTED] : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat:  http://freshmeat.net/projects/algorithms/


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

Re: texlive-basic_2005-1_i386.changes REJECTED

[Frank Küster]

Norbert Preining <[EMAIL PROTECTED]> wrote:

> On Son, 27 Nov 2005, Joerg Jaspert wrote:
>> Looking at the texlive packages in NEW I have some comments for you,

I can only support was Norbert has said here, no need to repeat it.

Maybe two more things:  

The process of preparing Debian for having two TeX systems has very much
improved the Policy Draft that we are currently writing (available in
the tex-common package), and the packaging of teTeX (and texlive).  I am
sure that this is not a once-and-for-all-times process, but will
continue to help us with critically rethinking our packages - and thus
improve the quality of TeX in Debian.

Second, Norbert is a TeXlive developer and a Debian user.  He has become
a Debian maintainer (and applied for DD) because he and other TeXlive
developers and users wanted a simple way to install texlive in Debian,
replacing teTeX while keeping dependencies in order.  One should not
assume that he will put only half as much effort into making "teTeX more
modular", as you have suggested, as he has put into the creation of the
texlive Debian package.  Instead, he and his users would be better
served if he used the tex-common infrastructure that we have developed
together to provide apt-get'able texlive packages from the texlive
server.  And I am sure that this situation would be much harder to
handle, also for the teTeX maintainers and especially for maintainers of
TeX-add-on packages or fonts, than if texlive was in Debian.

>> allrunes   dfsg
>> 
>> Please: Tell me its not true that the DFSG is used as a license there.
>
> As stated in the License file, this list was generated from the TeX
> Catalogue, which *can be wrong*! If you check the actual allrunes files,
> you see that it is LPPL.

Please also note that, although TeXLive's copyright file might still be
problematic, it is better than what teTeX has - see the bug #218105.
And I fear that only the combined effort of Debian people caring for
teTeX and for TeXLive will finally enable us to resolve this bug.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: texlive-basic_2005-1_i386.changes REJECTED

[Norbert Preining]

Hi all!

On Mon, 28 Nov 2005, Miles Bader wrote:
> nicely as "texlive-lang-tibetan" and "texlive-fonts-recommended".

On Mon, 28 Nov 2005, Rogério Brito wrote:
> > texlive-binaries-source 96M
> > texlive-basicbin
> What about texlive-bin-base?


As I said, it is true that I can arbitrary hyphens, but there was a
decisison behind these names: Keeping the collections of TeX live (this
is what users see when they use the installer) and the debian packages
namewise in sync.

I have no problem introducing different names, but only if I see good
reasons other than "I like it" or "it is usual like this". To me, the
argument on name-sync collection-debiannames is strong enough to keep
the current names.

Best wishes

Norbert

---
Dr. Norbert Preining  Università di Siena
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
IBSTOCK (n.)
Anything used to make a noise on a corrugated iron wall or
clinker-built fence by dragging it along the surface while walking
past it. 'Mr Bennett thoughtfully selected a stout ibstock and left
the house.' - Jane Austen, Pride and Prejudice, II.
--- Douglas Adams, The Meaning of Liff


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

Re: texlive-basic_2005-1_i386.changes REJECTED

[Norbert Preining]

Hi Frank!

On Mon, 28 Nov 2005, Frank Küster wrote:
> > texlive-languages-source37M
> > texlive-base-source 78M
> > texlive-extra-source172M
> 
> Whether this is a good idea depends on a decision that, IIRC, we have
> not yet talked about:  Will you only provide packages of the released
> version, or also of (usable) development versions?  In the latter case,

Irrelevant.

> I think it would be a good idea to keep documentation sources and TeX
> input file sources together.  Otherwise you'd have to rebuilt all
> packages from texlive-documentation-source and texlive-languages-source
> just because one language package was updated on CTAN and mirrored in
> TeXLive. 

No, because a tpm is treated as unit, thus the documentation and
source/input files are always in sync.

the documentation-foobar packages provide documentation in the
respective language if available.

> And generally I wonder:  Don't you generate most of the documentation
> from dtx files, and many input files from the same dtx files?  Then why

No, I use what is in the depot of perforce texlive.

Best wishes

Norbert

---
Dr. Norbert Preining  Università di Siena
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
You're bound to be unhappy if you optimize everything.
--- Donald E. Knuth


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

Re: texlive-basic_2005-1_i386.changes REJECTED

[Thiemo Seufer]

Norbert Preining wrote:
> Hi all!
> 
> On Mon, 28 Nov 2005, Miles Bader wrote:
> > nicely as "texlive-lang-tibetan" and "texlive-fonts-recommended".
> 
> On Mon, 28 Nov 2005, Rogério Brito wrote:
> > > texlive-binaries-source   96M
> > >   texlive-basicbin
> > What about texlive-bin-base?
> 
> 
> As I said, it is true that I can arbitrary hyphens, but there was a
> decisison behind these names: Keeping the collections of TeX live (this
> is what users see when they use the installer) and the debian packages
> namewise in sync.
> 
> I have no problem introducing different names, but only if I see good
> reasons other than "I like it" or "it is usual like this". To me, the
> argument on name-sync collection-debiannames is strong enough to keep
> the current names.

FWIW, Debian package names prefer e.g. foo-en-uk-doc over
foo-documentation-ukenglish. This allows to filter documentation
packages by name (doc-* or *-doc), and following the standardized
ISO abbreviations also seems to be better than using yet another
scheme.


Thiemo


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

Re: texlive-basic_2005-1_i386.changes REJECTED

[Thomas Viehmann]

[I've dropped some CCs...]

Norbert Preining wrote:
>>What about texlive-bin-base?

> As I said, it is true that I can arbitrary hyphens, but there was a
> decisison behind these names: Keeping the collections of TeX live (this
> is what users see when they use the installer) and the debian packages
> namewise in sync.

> I have no problem introducing different names, but only if I see good
> reasons other than "I like it" or "it is usual like this". To me, the
> argument on name-sync collection-debiannames is strong enough to keep
> the current names.

Well, Debian as a project has effectively standardized (by practice) on
the hyphenation that has been suggested all over the place in this
thread. Debian users will and should be able to expect a Debian-style
package naming.
Dismissing comments favoring this hyphenation - in unison - as
expressions of personal taste doesn't really reflect the fact that
consistency is a quality Debian users look for in packages.

If you provide the TeX live names in the long description, people will
be able to find stuff by the usual package search functions.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


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

Bug#341102: RFA: trophy -- A 2D car racing action game

[Guus Sliepen]

Package: wnpp
Severity: normal

I request an adopter for the trophy package.

The package description is:
 Trophy is a single-player racing game for Linux. Even though the goal is
 basically to finish the laps as the first, Trophy is an action game which
 offers much more than just a race. Lots of extras enable "unusual" features
 for races such as shooting, putting mines and many others.

Trophy is a nice but limited game. Upstream is not working on this game
anymore, and there are a number of open bugs, mostly about memory leaks
and segmentation faults. These problems are becoming more and more
evident, I guess it is bit rot taking place. This package needs a
developer with C++ knowledge that wants to find the bugs in the source
code and keep the package in shape, despite the inactive upstream. If
noone wants to adopt this package, I will request for its removal from
Debian.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14.3
Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8)


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

Re: texlive-basic_2005-1_i386.changes REJECTED

[Frank Küster]

Rogério Brito <[EMAIL PROTECTED]> wrote:

> On Nov 28 2005, Norbert Preining wrote:
>> Hi Jörg, hi ftpmasters!
>
> Hi, Norbert, Jörg and others.
>
> Here is the opinion of a long time Debian luser (and DD wannabe), based
> on the naming that I am already used to with other packages.
>
>> texlive-binaries-source  96M
>>  texlive-basicbin
> What about texlive-bin-base?
[...]
> And similarly for all the others:

I think that keeping the package names the same as the texlive
collection names would be a great benefit for the users.  

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: texlive-basic_2005-1_i386.changes REJECTED

[Frank Küster]

Norbert Preining <[EMAIL PROTECTED]> wrote:

>> And generally I wonder:  Don't you generate most of the documentation
>> from dtx files, and many input files from the same dtx files?  Then why
>
> No, I use what is in the depot of perforce texlive.

Right answer to my wrongly phrased question.  The right question would
have been: "Do you keep ready-made documentation in the repository, or
are the documentation files created at build-time from the dtx files?".

Obviously, the answer is they are not created at build time.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: texlive-basic_2005-1_i386.changes REJECTED

[Frank Küster]

Thiemo Seufer <[EMAIL PROTECTED]> wrote:

>> I have no problem introducing different names, but only if I see good
>> reasons other than "I like it" or "it is usual like this". To me, the
>> argument on name-sync collection-debiannames is strong enough to keep
>> the current names.
>
> FWIW, Debian package names prefer e.g. foo-en-uk-doc over
> foo-documentation-ukenglish. This allows to filter documentation
> packages by name (doc-* or *-doc), and following the standardized
> ISO abbreviations also seems to be better than using yet another
> scheme.

I agree with you; however this particular point should not be a reason
for rejecting a package.  It is clearly something that has to be
synchronized with upstream, and it not of such severity that the package
couldn't be accepted without such an upstream change.  Especially if one
notices that there won't be a new upstream release until autumn 2006.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: texlive-basic_2005-1_i386.changes REJECTED

[Miles Bader]

Thomas Viehmann <[EMAIL PROTECTED]> writes:
> Well, Debian as a project has effectively standardized (by practice) on
> the hyphenation that has been suggested all over the place in this
> thread. Debian users will and should be able to expect a Debian-style
> package naming.
> Dismissing comments favoring this hyphenation - in unison - as
> expressions of personal taste doesn't really reflect the fact that
> consistency is a quality Debian users look for in packages.
>
> If you provide the TeX live names in the long description, people will
> be able to find stuff by the usual package search functions.

I'm not sure why the goal of exact correspondence with texlive names is
important in the first place (if it's just because it's aesthetically
pleasing, then obviously the same argument can be made from a Debian
point of view as well).

I assume that people seeing/using texlive-in-debian are more likely to
be long-term Debian users rather than veteran texlive users, and will
benefit both from more readable package names, and (as you say) from
consistency with other debian packages.  Note that there is a definite
benefit to this sort of consistency -- I often do operations in aptitude
by matching on package prefixes/suffix, e.g. everything matching "-doc"
(or whatever).

For programs, some sort of correspondence with texlive names might be
useful, but that could be easily provide via other means (e.g. a mapping
file, or perhaps virtual packages like "texlive-collection-FOO").

-miles
-- 
/\ /\
(^.^)
(")")
*This is the cute kitty virus, please copy this into your sig so it can spread.


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

Re: texlive-basic_2005-1_i386.changes REJECTED

[Miles Bader]

Frank K.AN|ster <[EMAIL PROTECTED]> writes:
> I think that keeping the package names the same as the texlive
> collection names would be a great benefit for the users.  

Can you explain why it's important to keep the names _exactly_ the same?

Renaming them to completely random names might put off or confuse some
texlive users, but I think the changes suggested are not like that.

-Miles
-- 
$B<+$i$r6u$K$7$F!"?4$r3+$/;~!"F;$O3+$+$l$k(B


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

Re: texlive-basic_2005-1_i386.changes REJECTED

[Frank Küster]

Miles Bader <[EMAIL PROTECTED]> wrote:

> For programs, some sort of correspondence with texlive names might be
> useful, but that could be easily provide via other means (e.g. a mapping
> file, or perhaps virtual packages like "texlive-collection-FOO").

We already have a lot of real packages; no need to bloat the package
list even further by providing lots of virtual ones.  But on the other
hand, you are all probably right, and it might actually be best to
divert from upstream's names.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: texlive-basic_2005-1_i386.changes REJECTED

[Andrew Vaughan]

On Mon, 28 Nov 2005 22:28, Thiemo Seufer wrote:
>
> FWIW, Debian package names prefer e.g. foo-en-uk-doc over
> foo-documentation-ukenglish. This allows to filter documentation
> packages by name (doc-* or *-doc), and following the standardized
> ISO abbreviations also seems to be better than using yet another
> scheme.
>
As a user, I much prefer 
foo   
 + libfoo 
 + foo-doc-en
 + foo-doc-fr
rather than   
foo   
 + libfoo 
 + foo-en-doc
 + foo-fr-doc

To me the hierarchy tree 
--
is much more natural than 
--

Cheers
Andrew V.


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

Re: texlive-basic_2005-1_i386.changes REJECTED

[Rogério Brito]

On Nov 28 2005, Frank Küster wrote:
> Rogério Brito <[EMAIL PROTECTED]> wrote:
> 
> > On Nov 28 2005, Norbert Preining wrote:
> > > texlive-binaries-source   96M
> > >   texlive-basicbin
> > What about texlive-bin-base?
> 
> I think that keeping the package names the same as the texlive
> collection names would be a great benefit for the users.

For which users exactly? Debian users? I would expect the fact of
packaging a given piece of software to adapt it to the Debian system as
a whole.

For instance, many programs put their configuration files in places that
are not acceptable for a Debian system (for instance, qmail comes to
mind: it keeps is configuration files on /var/qmail/control), but the
task of a Debian Developer is to adapt the package requirements to what
a Debian system would look like (e.g., make all configuration of the
package must be accessible via /etc).

I understand that keeping the names in sync with what upstream provides
is nice and here we have to make a choice between two "standards". Which
one to choose? I sincerely don't know.

Oh, and even though some things aren't mandated, they are of course the
basis for future policy if the practice is considered to be good enough
(i.e., if it is a best current practice).

BTW, I do agree with the fact that the naming alone (except for some
disasterous things) is not a strong reason to reject an upload.


Regards, Rogério Brito.

P.S.: If, indeed, the package names for language things are changed, the
proposal of having them use the ISO abbrevs would be quite nice.
-- 
Rogério Brito : [EMAIL PROTECTED] : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat:  http://freshmeat.net/projects/algorithms/


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

Re: texlive-basic_2005-1_i386.changes REJECTED

[Rogério Brito]

On Nov 28 2005, Thomas Viehmann wrote:
> Dismissing comments favoring this hyphenation - in unison - as
> expressions of personal taste doesn't really reflect the fact that
> consistency is a quality Debian users look for in packages.

Agreed. Debian users look for consistency in the same way that
development packages are called foo-dev, documentation packages are
called foo-doc and some packages share content via foo-common packages,
just to name a few things.

> If you provide the TeX live names in the long description, people will
> be able to find stuff by the usual package search functions.

I think that this would be a nice suggestion for Norbert. If I were
maintaining the packages, this would be something that I would actually
adopt, to conform to the practices of both worlds. A good compromise,
IMVHO.

Of course, the packages are his and he decides how to name what.


Regards, Rogério Brito.

-- 
Rogério Brito : [EMAIL PROTECTED] : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat:  http://freshmeat.net/projects/algorithms/


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

Re: texlive-basic_2005-1_i386.changes REJECTED

[Thiemo Seufer]

Andrew Vaughan wrote:
> On Mon, 28 Nov 2005 22:28, Thiemo Seufer wrote:
> >
> > FWIW, Debian package names prefer e.g. foo-en-uk-doc over
> > foo-documentation-ukenglish. This allows to filter documentation
> > packages by name (doc-* or *-doc), and following the standardized
> > ISO abbreviations also seems to be better than using yet another
> > scheme.
> >
> As a user, I much prefer 
> foo   
>  + libfoo 
>  + foo-doc-en
>  + foo-doc-fr
> rather than   
> foo   
>  + libfoo 
>  + foo-en-doc
>  + foo-fr-doc
> 
> To me the hierarchy tree 
> --
> is much more natural than 
> --

It may look more natural, but it makes pattern matching harder
(e.g. python-docutils is a false positive for the naive approach).


Thiemo


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

Re: texlive-basic_2005-1_i386.changes REJECTED

[Norbert Preining]

Hi all!

(Taking out all the private email adr plus the other lists of the Cc and
continuing only on debian-devel)

On Mon, 28 Nov 2005, Miles Bader wrote:
> I assume that people seeing/using texlive-in-debian are more likely to
> be long-term Debian users rather than veteran texlive users, and will
> benefit both from more readable package names, and (as you say) from
> consistency with other debian packages.  Note that there is a definite
> benefit to this sort of consistency -- I often do operations in aptitude
> by matching on package prefixes/suffix, e.g. everything matching "-doc"
> (or whatever).

Ok, accepted. Let's go on and try to settle this:

How would the layout go for documentation packages. Ok, for a
documentation in language  I take the XX code and generate
old:texlive-documentation-x
new:texlive-XX-doc
But what to do with the texlive-documentation-base, should it become
old:texlive-documenatation-base
new:texlive-base-doc
?

For the language stuff: Here is a problem as some languages packages are
not *one* single language, but several (arabic, cjk, other). So would it
be the best solution to have
old:texlive-langX
new:texlive--lang
?

Finally a question concerning the package build from binaries-source:
texlive-binaries-source 96M
texlive-basicbin texlive-binextra texlive-fontbin texlive-htmlxml
texlive-metapost texlive-omega texlive-pdfetex texlive-psutils
texlive-ttfutils texlive-music texlive-langindic texlive-graphicstools
texlive-langcjk
Renaming some of them in the `obvious' way is in fact misleading: Take
eg 
old:texlive-binextra
and rename it to
new:texlive-extra-bin
Then most Debian users would expect a package "texlive-extra" and this
one would provide only the binaries.

But in binextra there are not the binaries for some extra package, there
are just extra binaries including the necessary support files, so
complete packages.

To stress this fact: texlive-fontbin, texlive-binextra should be renamed
to have decent names, but they are in some sense self contained packages
containing binaries and the necessary support files, they are not of the
usual -bin type packages in Debian, ie splitting out binaries from one
package to have only small arch dep packages and one big arch indep
package.

If this changes anything in your idea on how the packages should be
named, tell me, I am open to this.

Otherwise, according to your comments, I would suggest
texlive-base-bin
texlive-extra-bin
texlive-font-bin
texlive-htmlxml
texlive-metapost
texlive-omega
texlive-pdfetex
texlive-psutils
texlive-ttfutils
texlive-music
texlive-indic-lang
texlive-graphicstools
texlive-cjk-lang

Would this be an acceptable naming scheme for all present? Also
ftpmasters?

Best wishes

Norbert

---
Dr. Norbert Preining  Università di Siena
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
LOUTH (n.)
The sort of man who wears loud check jackets, has a personalised
tankard behind the bar and always gets served before you do.
--- Douglas Adams, The Meaning of Liff


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

ITP: open.tool -- User guide for GNUMail

[Gürkan Sengün]

Package: wnpp
Severity: wishlist

* Package name: open.tool
  Version : 0.1cvs20051128
  Upstream Author : Jeff Teunissen <[EMAIL PROTECTED]>
* URL : http://www.nongnu.org/backbone/download.html
* License : GNU GPL
  Description : GNUstep open tool
 Tool to open files and applications and what not. 


 Users that have worked with open on OPENSTEP or Mac OS X,
 will be familiar with this tool. 

 . 



 Homepage: http://www.nongnu.org/backbone/apps.html


-- System Information:
Debian Release: testing/unstable
Architecture: powerpc
Kernel: Linux ibook 2.4.23-ben1 #7 Sat Dec 27 11:20:38 CET 2003 ppc
Locale: LANG=POSIX, LC_CTYPE=POSIX


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

Re: ITP: open.tool -- User guide for GNUMail

[Steinar H. Gunderson]

On Mon, Nov 28, 2005 at 03:25:25PM +0100, Gürkan Sengün wrote:
>   Description : GNUstep open tool
>  Tool to open files and applications and what not. 
> 
>  Users that have worked with open on OPENSTEP or Mac OS X,
>  will be familiar with this tool. 

You might want to be a lot more descriptive. It “opens applications”? What?
And “what not”? Please explain what this tool actually does.

/* Steinar */
-- 
Homepage: http://www.sesse.net/


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

Re: texlive-basic_2005-1_i386.changes REJECTED

[Thiemo Seufer]

Norbert Preining wrote:
[snip]
> For the language stuff: Here is a problem as some languages packages are
> not *one* single language, but several (arabic, cjk, other). So would it
> be the best solution to have
>   old:texlive-langX
>   new:texlive--lang
> ?

Arabic is "ar", IIRC. For groups of languages like cjk or indic it might
make sense to split the packages further, or, if that's not feasible,
use e.g. texlive-cjk-lang (but make sure the abbreviation is not ISO-style
two-character).

> Finally a question concerning the package build from binaries-source:
> texlive-binaries-source 96M
> texlive-basicbin texlive-binextra texlive-fontbin texlive-htmlxml
> texlive-metapost texlive-omega texlive-pdfetex texlive-psutils
> texlive-ttfutils texlive-music texlive-langindic texlive-graphicstools
> texlive-langcjk
> Renaming some of them in the `obvious' way is in fact misleading: Take
> eg 
>   old:texlive-binextra
> and rename it to
>   new:texlive-extra-bin
> Then most Debian users would expect a package "texlive-extra" and this
> one would provide only the binaries.
> 
> But in binextra there are not the binaries for some extra package, there
> are just extra binaries including the necessary support files, so
> complete packages.

Probably texlive-extra and texlive-fontutils then? In any case, there's
not much need to search for executables only packages.


Thiemo


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

Re: ITP: open.tool -- User guide for GNUMail

[Wouter van Heyst]

On Mon, Nov 28, 2005 at 03:48:50PM +0100, Steinar H. Gunderson wrote:
> On Mon, Nov 28, 2005 at 03:25:25PM +0100, Gürkan Sengün wrote:
> >   Description : GNUstep open tool
> >  Tool to open files and applications and what not. 
> > 
> >  Users that have worked with open on OPENSTEP or Mac OS X,
> >  will be familiar with this tool. 
> 
> You might want to be a lot more descriptive. It “opens applications”? What?
> And “what not”? Please explain what this tool actually does.

Well, it is what it does I guess, ala 'start' on Windows. I agree the
description needs to be improved, good luck coming up with something
descriptive though.

Wouter van Heyst

Re: texlive-basic_2005-1_i386.changes REJECTED

[W. Borgert]

Quoting Thiemo Seufer <[EMAIL PROTECTED]>:
> Arabic is "ar", IIRC. For groups of languages like cjk or indic it might
> make sense to split the packages further, or, if that's not feasible,
> use e.g. texlive-cjk-lang (but make sure the abbreviation is not ISO-style
> two-character).

ISO-style can be two-character (ISO 639-1) or three-letter (ISO 639-2).
The latter is IMHO more useful for TeX, as more languages have a code.
Arabic is either "ar" or "ara", Aramaic is "arc", Apache is "apa"...
"cjk" is currently not an ISO code, but it could be in the future.
However, cjk is well-known, so ISO would be very stupid to use this
code for anything else than zho-jpn-kor. Indic already has an ISO
language code: "inc".

Cheers, WB


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

Re: Bug#340428: octave2.9 - lists mailing list as uploader in changelog

[Ian Jackson]

Thiemo Seufer writes ("Re: Bug#340428: octave2.9 - lists mailing list as 
uploader in changelog"):
> Policy violations are RC by definition.

This is pernicious nonsense.

Asking whether a bug is release critical is the same as asking whether
it would be better to release with the bug, or to discard the package
and/or delay the release.  There are plenty of situations where a
violation of a stricture in the policy manual is not a good reason for
ditching the package or delaying the release.

Furthermore, lest you say `but the policy manual says ...': whether a
bug is release critical is determined by the release team (usually via
their release policy), not by the policy manual.

Ian.


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

Re: texlive-basic_2005-1_i386.changes REJECTED

[Frank Küster]

Norbert Preining <[EMAIL PROTECTED]> wrote:

> How would the layout go for documentation packages. Ok, for a
> documentation in language  I take the XX code and generate
>   old:texlive-documentation-x
>   new:texlive-XX-doc
> But what to do with the texlive-documentation-base, should it become
>   old:texlive-documenatation-base
>   new:texlive-base-doc
> ?

I would say, yes, texlive-base-doc, because it is the doc package for
texlive-base (or probably for the arch: all and arch: any packages with
base in their name).  It is not so much the basis of all texlive
documentation. 

> For the language stuff: Here is a problem as some languages packages are
> not *one* single language, but several (arabic, cjk, other). So would it
> be the best solution to have
>   old:texlive-langX
>   new:texlive--lang
> ?

Here, I would take descriptive names - you wouldn't want to change the
package name if cjk starts supporting an additional language.  But as
for arabic, isn't that *one* language?  I'm not familiar with language
vs. country codes, but I found a list of ISO 639 2- and 3-letter
lanugage codes, where 'AR' or 'ara' stands for arabic.  And the
two-letter list is missing some languages with TeX support, e.g. Sorbian
(wen). 

> Otherwise, according to your comments, I would suggest
>   texlive-base-bin
>   texlive-extra-bin
>   texlive-font-bin

Why not texlive-bin-* in this case, if it fits better to the content? 

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

package name changes in atlas-cpp (was Re: library renaming due to changed libstdc++ configuration)

[Ming Hua]

On Tue, Nov 15, 2005 at 06:28:05AM +0100, Matthias Klose wrote:
> 
>  * Rename and rebuild the libraries listed below. The new suffix for
>these packages should be in any case "c2a" (instead of "c2"). No
>new suffix is needed when the soname changes in a new upstream
>upload.

I noticed that atlas-cpp with renamed library packages has been
uploaded, and it renames the binary packages as follows:
libatlas-cpp-0.6-0 => libatlas-cpp-0.6-0c2
libatlas-cpp-0.6-0-dbg => libatlas-cpp-0.6-0c2-dbg

I have two questions for this:

1. Should -dbg packages be renamed or not?
2. Shouldn't the suffix be c2a in this case?

This also has the consequence of having different binary package names
than Ubuntu (Ubuntu only renamed libatlas-cpp-0.6-0 to
libatlas-cpp-0.6-0c2a, didn't rename -dbg package), Ubuntu MOTU cc:ed.

(Please cc: the reply to me, I'm not subscribed to debian-devel, thanks.)

Ming
2005.11.28


signature.asc
Description: Digital signature

Bug#341127: ITP: libformvalidator-simple-perl -- validation with simple chains of constraints

[Krzysztof Krzyzaniak (eloy)]

Package: wnpp
Severity: wishlist
Owner: "Krzysztof Krzyzaniak (eloy)" <[EMAIL PROTECTED]>

* Package name: libformvalidator-simple-perl
  Version : 0.11
  Upstream Author : Lyo Kato <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/~lyokato/FormValidator-Simple-0.10/
* License : Perl: GPL/Artistic
  Description : validation with simple chains of constraints

 This module provides you a sweet way of form data validation with
 simple constraints chains. You can write constraints on single line
 for each input data.
 .
 This idea is based on Sledge::Plugin::Validator, and most of
 validation code is borrowed from this plugin.
  
-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-1-686
Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2)


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

Re: texlive-basic_2005-1_i386.changes REJECTED

[Norbert Preining]

Dear all!

I have reworked the whole packaging naming and would like all of you
again for comments:

I collect here the binary packages by source package, and list first the
old name, then the new name.

For doc and lang I give some reasoning.

Please comment, not only on the package naming, but also on the
bin-to-source mapping.


texlive-binaries-source 96M
---
texlive-basicbintexlive-base-bin
texlive-binextratexlive-extrautils
texlive-fontbin texlive-fontutils
texlive-htmlxml texlive-htmlxml
texlive-metaposttexlive-metapost
texlive-omega   texlive-omega
texlive-pdfetex texlive-pdfetex
texlive-psutils texlive-psutils
texlive-ttfutilstexlive-ttfutils
texlive-music   texlive-music
texlive-langindic   texlive-lang-indic
texlive-graphicstools   texlive-graphicstools
texlive-langcjk texlive-lang-cjk

texlive-documentation-source57M

Reasoning: The documenatation is actually in a specific language, so we use
the respective language code.
texlive-documentation-base  texlive-base-doc
texlive-documentation-bulgarian texlive-bg-doc
texlive-documentation-czechslovak texlive-cs-doc
texlive-documentation-dutch texlive-nl-doc
texlive-documentation-english   texlive-en-doc
texlive-documentation-finnish   texlive-fi-doc
texlive-documentation-frenchtexlive-fr-doc
texlive-documentation-germantexlive-de-doc
texlive-documentation-greek texlive-el-doc
texlive-documentation-italian   texlive-it-doc
texlive-documentation-japanese  texlive-ja-doc
texlive-documentation-koreantexlive-ko-doc
texlive-documentation-mongolian texlive-mn-doc
texlive-documentation-polishtexlive-pl-doc
texlive-documentation-portuguese texlive-pt-doc
texlive-documentation-russian   texlive-ru-doc
texlive-documentation-spanish   texlive-es-doc
texlive-documentation-thai  texlive-th-doc
texlive-documentation-ukrainian texlive-uk-doc

texlive-languages-source37M

Reasoning: We use names instead of codes as several of these packages include
support for different languages/variants (greek: various versions of greek 
with different iso codes, ...). 
texlive-langafrican texlive-lang-african
texlive-langarabtexlive-lang-arab
texlive-langarmeniantexlive-lang-armenian
texlive-langcroatiantexlive-lang-croatian
texlive-langcyrillictexlive-lang-cyrillic
texlive-langczechslovak texlive-lang-czechslovak
texlive-langdanish  texlive-lang-danish
texlive-langdutch   texlive-lang-dutch
texlive-langfinnish texlive-lang-finnish
texlive-langfrench  texlive-lang-french
texlive-langgerman  texlive-lang-german
texlive-langgreek   texlive-lang-greek
texlive-langhebrew  texlive-lang-hebrew
texlive-langhungarian   texlive-lang-hungarian
texlive-langitalian texlive-lang-italian
texlive-langlatin   texlive-lang-latin
texlive-langmanju   texlive-lang-manju
texlive-langmongolian   texlive-lang-mongolian
texlive-langnorwegian   texlive-lang-norwegian
texlive-langother   texlive-lang-other
texlive-langpolish  texlive-lang-polish
texlive-langportuguese  texlive-lang-portuguese
texlive-langspanish texlive-lang-spanish
texlive-langswedish texlive-lang-swedish
texlive-langtibetan texlive-lang-tibetan
texlive-langukenglish   texlive-lang-ukenglish
texlive-langvietnamese  texlive-lang-vietnamese

texlive-base-source 78M

texlive-basic   texlive-base
texlive-context texlive-context
texlive-genericrecommended  texlive-generic-recommended
texlive-latex   texlive-latex-base
texlive-latexrecommendedtexlive-latex-recommended
texlive-fontsrecommendedtexlive-fonts-recommended
texlive-pictures

texlive-extra-source172M

texlive-bibtexextra texlive-bibtex-extra
texlive-formatsextratexlive-formats-extra
texlive-genericextratexlive-generic-extra
texlive-mathextra   texlive-math-extra
texlive-plainextra  texlive-plain-extra
texlive-latexextra  texlive-latex-extra
texlive-latex3  texlive-latex3
texlive-fontsextra  texlive-fonts-extra
texlive-chemistry   texlive-chemistry
texlive-games   texlive-games
texlive-pstrickstexlive-pstricks
texlive-publishers  texlive-publishers


Best wishes

Norbert

---
Dr. Norbert Preining  Uni

Re: Bug#340631: ITP: culmus-fancy -- Type1 Fancy Hebrew Fonts for X11

[Ben Armstrong]

On Sat, 2005-11-26 at 21:38 -0600, Peter Samuelson wrote:
> [Lior Kaplan]
> > * Package name: culmus-fancy
> >   Description : Type1 Fancy Hebrew Fonts for X11
> 
> I understand that the 'culmus' package already exists, and other
> packages like 'lmodern' don't follow any particular name convention
> either, but could you consider naming this thing t1-culmus-fancy or
> something?  We don't really have a package name convention for fonts,
> but xfonts-*, t1-* and ttf-* are the closest thing we have.

Besides which, doesn't 'culmus' already contain Ktav Yad?

Ben


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

InterWiki names

[Arnaud Vandyck]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I'm moving http://java.debian.net to http://wiki.debian.org/Java

I'd like to add three InterWiki links but I don't know how to do that. I
edited http://wiki.debian.org/InterWiki but I'm sure it's not the way to
do it.

These are the links to add:
* DebianBug http://bugs.debian.org/
* DebianPts http://packages.qa.debian.org/
* AliothCVS
http://cvs.alioth.debian.org/cgi-bin/cvsweb.cgi/?cvsroot=pkg-java/

Thanks for any help,

- --
  .''`.
 : :' :rnaud
 `. `'
   `-
Java Trap: http://www.gnu.org/philosophy/java-trap.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDizaX4vzFZu62tMIRAultAJ90luwJ/4t6QF9KUKm9ILHc1zYB1gCgmcdh
K7G2TASKHYR3Rm/0wJVVxc0=
=ZISO
-END PGP SIGNATURE-


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

Re: texlive-basic_2005-1_i386.changes REJECTED

[Marvin Renich]

* Norbert Preining <[EMAIL PROTECTED]> [051128 11:20]:
> Dear all!
> 
> Please comment, not only on the package naming, but also on the
> bin-to-source mapping.
> 
> 
> texlive-documentation-source  57M
> 
> Reasoning: The documenatation is actually in a specific language, so we use
> the respective language code.
> texlive-documentation-basetexlive-base-doc
> texlive-documentation-bulgarian texlive-bg-doc
> texlive-documentation-czechslovak texlive-cs-doc
> texlive-documentation-dutch   texlive-nl-doc
> texlive-documentation-english texlive-en-doc
> 
> 
> Best wishes
> 
> Norbert
> 

In [1], Thiemo Seufer asserts that "FWIW, Debian package names prefer
e.g. foo-en-uk-doc over foo-documentation-ukenglish."  I completely
disagree.

There is already precedent for using foo-doc-fr ordering of -doc-LANG:
aptitude-doc-XX, udo-doc-XX, mdnkit-doc-XX, otrs-doc-XX,
speechd-el-doc-cs (the -el- is emacs lisp, -cs is Czech),
speech-dispatcher-doc-cs, lifelines-doc-sv, samba-doc-ja.

I saw no examples of -XX-doc with XX a language.

The most notable exceptions to PKG-doc-XX were doc-linux-XX and
doc-debian-XX, but in these cases, you can consider 'doc-linux' and
'doc-debian' to be the package names, rather than "documentation for the
linux or debian package."  And, the -XX still came after.

I think -doc-XX is more natural, and I don't see why in [2] Thiemo said
that it made pattern matching harder.  In fact, I think it is easier to
find documentation for the foo package with foo-doc; then you can easily
see what languages are available.  Suppose you speak German and are
looking for documentation for package foo.  You search for foo-doc; it
lists several, but not foo-doc-de.  However, it lists foo-doc-fr, and
you speak French as a second language.  Weeding out foo-docutils with
the -doc-XX ordering is at least as easy as finding doc packages in all
languages with Thiemo's ordering.

I am not currently a texlive user, but as a Debian user, I would much
prefer the current precedent rather than your proposed -XX-doc.

...Marvin

[1] http://lists.debian.org/debian-devel/2005/11/msg01661.html
[2] http://lists.debian.org/debian-devel/2005/11/msg01673.html


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

Common Light Events Coming Up

[ElizaKeiser]

    

November 26, 2005
 
Dear Friends of Common 
Light,
 
    
As Anais Nin has eloquently stated, “Life shrinks or expands in 
proportion to one’s courage.”  
November has brought a good beginning to Common Light Meetingplace’s 
second year, “Dialogues on Courage,” and we now want to alert you to what will 
be happening in December and January.  
For those who live in the area, we hope that you will be drawn to join us 
at one or more of these events--all intended to deepen our reservoirs of courage 
and therefore expand our lives. To all of you, we send warm greetings at the 
year’s turning, hoping that 2006 will find our species renewed in  the courage needed to act in accord with 
the dignity and compassion which define our humanity. 

 
    
NEXT SATURDAY, DECEMBER 3, we look forward to a retreat designed as a DAY 
OF MINDFULNESS in the Thich Nhat Hanh tradition led by LARRY WARD and PEGGY ROWE 
from the Lotus Institute in Asheville.  They will 
have just returned from leading a week-long workshop at Pendle Hill.  Here in 
Black 
Mountain you have an opportunity—at considerably less cost—to have 
something of that Pendle Hill experience with two outstanding Buddhist leaders 
without traveling to Philadelphia.  It’s 
December 3, 9:00am to 4:00pm—notice that it ends one hour earlier than stated on our 
flier.  The suggested donation is 
$25; as always, scholarships are available.  Bring something to share at a vegetarian 
potluck lunch.  No experience with 
Buddhism is needed, and you are welcome to meditate in the position(s) you find 
most fitting. We cannot recommend this retreat experience highly enough as we 
embark on the darkest month of the year.  

 
 The following week, on WEDNESDAY DECEMBER 
7, the video documenting the problematic aspects of contemporary merchandising 
epitomized by WALMART will be shown at 7 pm, with a discussion afterwards led by MICHAEL GALOVIC.    

 
You are welcome 
to join the final of BARBARA NERENZ-KELLEY’s six sessions of Meditative Circle 
Dancing for autumn on THURSDAY THIS WEEK, DECEMBER 1, 11 am-1 pm ($10).  This 
series, like all of Barbara’s classes, resonates with the sacred energy that 
manifests through the changing seasons.   To celebrate the darkest day and 
the great turning towards light it announces, mark your calendar to participate 
in DEEP DANCING FOR WINTER SOLSTICE which Barbara has scheduled for THURSDAY 
EVENING, DECEMBER 22, 6:00-8:00pm 
($12).  No dance or meditation 
skills are needed to enter fully into this wonderful ritual experience.  .  
    

 
 GAETANA FRIEDMAN’S “Intuitive Painting: 
Exploring the Artist Within” is also just concluding with ten inspired persons 
painting from the source.  On 
FRIDAY, JANUARY 27, 7 to 8:30 pm, in the context of a video, she will lead a 
discussion on “active imagination,” C.G. Jung’s term for a process of active 
engagement with one’s unconscious.  
In “Appointment with the Wise Old Dog: Dream Images in a Time of Crisis,” 
conductor/cellist David Blum recorded his own medical and spiritual journey, and 
how he found ways to bring his dreams into his life through music and pastel 
drawings.  Yo-Yo Mah introduces the 
30-minute film.  

    

A 
reading/discussion group will meet THREE TIMES IN JANUARY to consider the 
relevance of Albert Camus’ novel THE PLAGUE to an ethic of nonviolence.  This will be led by TONY BING, whose 
Charles Lectures on Camus at Earlham 
College are at www.earlham.edu/~tonyb/bing_charles1.html 
.   The first two meetings are 
on JANUARY 8 and 15, SUNDAY afternoons from 3:30 to 5:30 pm, 
following tea and coffee, and the final meeting will follow a potluck supper on 
FRIDAY evening, JANUARY 20, 5:30 to 
8.  

 
The fourteen people who 
shared the first weekend, “Women Claiming Courage,” led by MariJo Moore and 
Laura Donaldson, found new meanings and energy for their own courageous 
living.  This workshop became a 
transformative event as we interacted wholeheartedly with stories, poems, 
history, and each other’s improvisational creative writing. For pictures, see 
our website at www.commonlight.org.
 
Yours in the 
common light,
Beth and Mel 
Keiser
 

Re: dpkg-sig support wanted?

[Peter Samuelson]

[Anthony Towns]
> gnupg comes close to being this, except for two things: it's got too
> many dependencies, and it's command line arguments are overly
> complex.  A "gpgh" variant (like gpgv but for hashing) might work,
> though. It doesn't support --check, and "gpg --print-md md5
> /etc/motd" has a different format to "md5sum /etc/motd" though.

I think it's important to support md5sum/sha1sum format, in cases where
md5 or sha1 are used, so people can conveniently use --check with their
existing binaries.  That might be just me, though.

> Of course, if we're doing it "right", we probably want to have some
> way of telling what hash was used, so we don't have to wonder whether
> a given 160bit hash is sha1 or ripemd160 or something else that gets
> cooked up in future.

For large files, getting a cryptographic checksum is more about reading
blocks off the disk than about CPU time.  So it wouldn't be completely
ridiculous to allow sha-1 to remain ambiguous with competing 160-bit
hashes, and have --check check for all of them (reading the file only
once).

I still think two-byte prefixes for non-md5-non-sha1 hashes makes some
sense, like s- for sha-256.  Avoids the filename encoding issue you
mentioned later (unless we want to encode newlines).

> OTOH, it would be far more convenient for *us* if it supported the
> .changes style we use, ie:
> 
>   MD5Sum:
> hash size filename

This might be generally reasonable, but we do want our dsum tool to
work with arbitrary MD5SUMS style files.  And if such files require a
hash-type header, dsum will have to produce one, at least optionally.
I really like the default behavior of our existing md5sum outputting
just a single line per file, and nothing more.

>   $ dsum -a sha1 foo; sha1sum foo
>   f572d396fae9206628714fb2ce00f72e94f2258f  foo
>   f572d396fae9206628714fb2ce00f72e94f2258f  foo
> 
>   $ dsum -d foo
>   SHA1Sum:
>f572d396fae9206628714fb2ce00f72e94f2258f 6 foo
> 
>   $ dsum -b foo
>   SHA1 (foo) = f572d396fae9206628714fb2ce00f72e94f2258f

What's the " 6 " above?  Surely not a hollerith-like string.  Other
than that, I like your proposed command line quite a lot.

> (Note that "dsum" would probably need to become Priority:required,
> and possibly Essential:yes, with the complications that entails)

Hmmm, promoting libgcrypt11 + libgpg-error0 to Required adds 516 kB on
i386, plus a trivial amount for dsum itself.  I wonder if it'd be
better to just copy / paste the algorithm code into dsum.


signature.asc
Description: Digital signature

Re: texlive-basic_2005-1_i386.changes REJECTED

[Thiemo Seufer]

Marvin Renich wrote:
> * Norbert Preining <[EMAIL PROTECTED]> [051128 11:20]:
> > Dear all!
> > 
> > Please comment, not only on the package naming, but also on the
> > bin-to-source mapping.
> > 
> > 
> > texlive-documentation-source57M
> > 
> > Reasoning: The documenatation is actually in a specific language, so we use
> > the respective language code.
> > texlive-documentation-base  texlive-base-doc
> > texlive-documentation-bulgarian texlive-bg-doc
> > texlive-documentation-czechslovak texlive-cs-doc
> > texlive-documentation-dutch texlive-nl-doc
> > texlive-documentation-english   texlive-en-doc
> > 
> > 
> > Best wishes
> > 
> > Norbert
> > 
> 
> In [1], Thiemo Seufer asserts that "FWIW, Debian package names prefer
> e.g. foo-en-uk-doc over foo-documentation-ukenglish."  I completely
> disagree.

The point was about "documentation" and "ukenglish".

> There is already precedent for using foo-doc-fr ordering of -doc-LANG:
> aptitude-doc-XX, udo-doc-XX, mdnkit-doc-XX, otrs-doc-XX,
> speechd-el-doc-cs (the -el- is emacs lisp, -cs is Czech),
> speech-dispatcher-doc-cs, lifelines-doc-sv, samba-doc-ja.
> 
> I saw no examples of -XX-doc with XX a language.

apt-cache pkgnames |egrep '(^doc-|-doc-|-doc$|-docs$)'
should catch most documentation packages, it shows the -doc suffix as
the most popular one.

> The most notable exceptions to PKG-doc-XX were doc-linux-XX and
> doc-debian-XX, but in these cases, you can consider 'doc-linux' and
> 'doc-debian' to be the package names, rather than "documentation for the
> linux or debian package."  And, the -XX still came after.
> 
> I think -doc-XX is more natural, and I don't see why in [2] Thiemo said
> that it made pattern matching harder.  In fact, I think it is easier to
> find documentation for the foo package with foo-doc; then you can easily
> see what languages are available.

If you know you are intersted in "foo", then it is easy anyway
(apt-cache pkgnames instead of search for the purpose of this
discussion):

apt-cache pkgnames | grep '^foo.*-doc$'

If the idea is to remove some documentation from a space-constrained
system, a -doc suffix would be easier.


Thiemo


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

Re: texlive-basic_2005-1_i386.changes REJECTED

[Frans Pop]

On Monday 28 November 2005 19:36, Thiemo Seufer wrote:
> If you know you are intersted in "foo", then it is easy anyway
> (apt-cache pkgnames instead of search for the purpose of this
> discussion):
>
> apt-cache pkgnames | grep '^foo.*-doc$'
>
> If the idea is to remove some documentation from a space-constrained
> system, a -doc suffix would be easier.

I disagree. Most regular users use frontends like aptitude for package 
management that sort on package name. For those having related packages 
together and sorted on language makes most sense.
Thus: foo-doc-

For removing you can still egrep on '^foo-doc(-.*)?$'.
For me, this is a specialized use case. Using a package management 
frontend is the normal use-case and should be an important factor in 
package naming.


pgpitoKQFdKsg.pgp
Description: PGP signature

Re: texlive-basic_2005-1_i386.changes REJECTED

[Andrew Vaughan]

On Tue, 29 Nov 2005 00:40, Thiemo Seufer wrote:
> Andrew Vaughan wrote:
> > On Mon, 28 Nov 2005 22:28, Thiemo Seufer wrote:
> > > FWIW, Debian package names prefer e.g. foo-en-uk-doc over
> > > foo-documentation-ukenglish. 
Can you provide a reference/stats to back this up. 

(on sarge) 
$ apt-cache search doc |grep -e'-doc-[a-z][a-z] ' |wc -l
12
$ apt-cache search doc |grep -e'-[a-z][a-z]-doc ' |wc -l
5

Examination of the first set shows 1 false positive:
gmt-doc-ps - PostScript docs for the Generic Mapping Tools
The other 11 translated docs
 
Examination of the second set shows:
adduser-ng-doc - Documentation for AddUser-NG users
gnome-db-doc - frontend to the GDA architecture for GNOME -- documentation 
gri-ps-doc - PostScript manual for gri, a language for scientific graphics.
libinti-gl-doc - GtkGLExt bindings for Inti - shared libraries
proj-ps-doc - PostScript docs for cartographic projection filters and library

Also look at the output to apt-cache search firefox |grep locale

> > > This allows to filter documentation 
> > > packages by name (doc-* or *-doc), and following the standardized
> > > ISO abbreviations also seems to be better than using yet another
> > > scheme.
> >

> >
> > To me the hierarchy tree
> > --
> > is much more natural than
> > --
>
> It may look more natural, but it makes pattern matching harder
> (e.g. python-docutils is a false positive for the naive approach).

Probably any approach will yield false positives with naive search strings.  

However a few false positives don't matter in the typical use case of an 
interactive user searching for a package.
>
>
> Thiemo

Package naming should be about what makes most sense to the users.  For me, 
that means increasing specialisation (of package) means tacking additional 
suffixes on the end of the packagename.

package foo.

add a doc package 
foo, foo-doc

add translated docs
foo, foo-doc-en, foo-doc-jp, foo-doc-fr etc.

(Regardless of which way is considered better, this sort of thing should be 
standardised and defined in policy IMO).

Why do you need to filter for *-doc packages anyway?  If you are looking for 
say Japanese doc packages, filtering on say *-doc-jp is as easy as *-jp-doc 
isn't it?  

If you want all doc packages, regardless of language/formatting/encoding, then 
filtering for doc-* and *-doc is not enough anyway.  In order to find 
*-doc-html, *-doc-ps you need you need to add *-doc-* anyway.
  (i) You are going to miss packages which don't contain doc in the name. 
  (eg ada-reference-manual, apt-dpkg-ref, docbook-defguide).
  (ii) In order to find *-doc-html, *-doc-ps etc packages you need to add
   *-doc-* anyway.  (eg exim4-doc-html, exim4-doc-info, r-doc-html,
   r-doc-pdf etc.  Note that renaming these to say exim4-info-doc suggests
   naive users that this is the documentation for the exim4-info package.)
  (iii) So you need to search for doc-* *-doc and *-doc-* anyway.
 eg. apt-cache search doc | grep -e'^doc-\|-doc-\|-doc '
or apt-cache search doc | grep -e'^doc-\|-doc\b'

Cheers
Andrew V.


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

Re: petsc_2.3.0-1_i386.changes REJECTED

[Adam C Powell IV]

On Sun, 2005-11-20 at 17:50 -0800, Steve Langasek wrote:
> On Sun, Nov 20, 2005 at 06:57:36PM -0500, Adam C Powell IV wrote:
> > > Well, I think the factor there is that we "usually" want users to upgrade 
> > > to
> > > the latest kernel automatically, whereas users of petsc usually can't
> > > auto-upgrade to the new API.
> 
> > Okay, then what about octave, another empty package which forced an
> > incompatible auto-upgrade from octave2.0 to octave2.1, and now to 2.9?
> 
> Probably depends on how incompatible the upgrades are.

I've only worked with octave a bit, but such upgrades have bit me on all
of the .m files I've written.  I'd say roughly similar backward
compatibility to PETSc-linked source.  There's a larger user community
for octave, but that's why I don't put multiple PETSc versions in Debian
simultaneously.

> BTW, the other big reason for linux-image-2.6-$flavor metapackages is that
> they provide a hook for debian-installer, so the installer doesn't have to
> be futzed with in 5 places every time there's a kernel update.

Okay, fair enough.

> > And come to think of it, the python-dev python version consistency
> > argument doesn't really apply to anyone running a single distribution,
> > because the "python" version in that distribution is automatically
> > identical to the "python-dev" version.  The only way this "guarantee" of
> > the same pythonx.y-dev and python -> pythonx.y actually does anything is
> > if an admin somehow attempts to shoehorn the woody python with the sarge
> > python-dev onto the same system, and how likely is that?
> 
> So you're suggesting that people who package python tools should be ok with
> having to update their build-dependencies as part of every python
> transition, even when nothing else in their package needs to change?  (This
> also has implications for backports and cross-ports, mind you...)

No, I'm merely saying that the versioning in the python dep is
irrelevant because python-dev and python will automatically have the
same version in every Debian release.

As for what should be OK, two scenarios: (1) empty upgrade packages are
good, so people build-dep on python-dev, which depends on python; (2)
empty upgrade packages are bad, so people build-dep on "python2.3-dev |
python-dev", the latter of which is a virtual package provided by
python*-dev.  No need to change the python-dependent package.

> > Again, the point is that these are all over Debian, and it's
> > inconsistent to accept all but one.
> 
> I don't think anyone has been proposing an inconsistent guideline, here.
> I'll grant you that these guidelines probably haven't been *applied*
> consistently in the past, but that's not the same thing.

Makes sense.  Can someone please write the guideline somewhere,
preferably in policy, so we can apply it?

Thanks,
-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


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

Checksumming tool

[Lars Wirzenius]

ma, 2005-11-28 kello 19:07 +1000, Anthony Towns kirjoitti:
> Hrm, if we're writing our own thing, maybe we should do it properly:
> have a single program that can do multiple hash algorithms, have the
> default hash be secure, and update it in future, and so on.

As it happens, I've been wanting a really nice checksum program for a
couple of years now. When I burn a CD or DVD with files, I put a
checksum file ("md5sum.txt" usually) at the root, so that I can easily
check that the disk is still working years later. It would be nice to
not have a zillion different, incompatible checksum tools.

The md5sum program isn't very user friendly and my main motivation has
been for more usability (feedback of how long the check will still take,
and stuff like that). I have, however, also thought about other checksum
algorithms than MD5, and about a format that is extensible enough that
it won't need to be changed every time the algorithm changes. A few
thoughts:

1. Definitely use URL encoding for filenames. It's cheap, well
known, and usually not needed (% being a nicely rare character),
and sometimes it really is important to be able to deal with
pathnames with weird characters.

2. A little bit of verbosity doesn't add very much to the file
size, and will make dealing with the files much easier.

3. Who knows what else one might want in the file later.

4. md5sum and sha1sum compatibility is pretty much required for
the new tool. It makes the transition tolerable. I don't feel
new files need to be backwards compatible by default, however.

The best I've come up with so far is a pseudo rfc822 syntax:

File: foo%20bar/hellurei.txt
Size: 12345
MD5: 012345667
SHA-256: 0a0a0a0a0a0a0a0a0a0a0a0a
Mode: 0644

Empty lines separate blocks of "headers" for different files. This
should all be very simple to use and immediately logical and familiar to
anyone who'se seen e-mail headers.

It would be cool for file(1) or GNOME's and KDE's MIME type heuristics
to easily recognize the format, so that (eventually) a GUI tool can be
written to deal with such files.

I put an old draft of the manual page for my work-in-progress tool at
http://liw.iki.fi/liw/temp/summain.txt and the bzr (a.k.a. bazaar-ng)
repository at http://liw.iki.fi/liw/bzr/ in case anyone is interested. I
don't have all that much code (this being a project I hack on whenever I
don't have anything useful to do, like reading Debian mailing lists). It
tends to get rewritten every now and then (happiness is going NIH on
your own code). It shouldn't take that much effort to write the tool, so
most of my efforts have gone into thinking about the exactly correct
command line user interface features, and about the prettiest
implementation design. 

I also write it in Python, and a pure C version would probably be
preferable for Debian's purposes. The file format is more important at
this point, though, and any sensible file format should be quite simple
to support in any language.

-- 
The most difficult thing in programming is to be simple and
straightforward.


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

NOW !! Al haramain Sermons Makkah & Madina

[eng]

Assalam alaikum Brothers and Sisters,
  
 I am pleased to inform you that you can continue viewing Sermons from the Two 
Holy Mosques of Makkah and Madinah via the site
  
 http://www.alharamainsermons.org/eng
  
 Which is the only site currently offering these.
  
 Wasalam alaikum wa rahmatullah
  
  
 Sincerely,
  
 Site Developers



---
To be unsubscribed from the  mailing list simply click on the link below 
http://www.alharamainsermons.org/cgi-bin/subscribe/s.pl?r=1&l=1&[EMAIL 
PROTECTED]





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

Re: dpkg-sig support wanted?

[Henning Makholm]

Scripsit Peter Samuelson <[EMAIL PROTECTED]>

> For large files, getting a cryptographic checksum is more about reading
> blocks off the disk than about CPU time.  So it wouldn't be completely
> ridiculous to allow sha-1 to remain ambiguous with competing 160-bit
> hashes, and have --check check for all of them (reading the file only
> once).

That sounds cryptographically unsafe. It would mean that a practical
preimage attack against _any_ of the supported hashes would break the
entire system. That's not the kind of algorithm agility we need.

> I still think two-byte prefixes for non-md5-non-sha1 hashes makes some
> sense, like s- for sha-256.

That is much better. But let's use "s." as a prefix and do a
[/+] -> [_-] substitution on the following base64 data. The dot
in the prefix will prevent the prefix from being mistaken as part of a
slightly larger non-tagged hash value.

>>   $ dsum -a sha1 foo; sha1sum foo
>>   f572d396fae9206628714fb2ce00f72e94f2258f  foo
>>   f572d396fae9206628714fb2ce00f72e94f2258f  foo

There appears to be to few characters of hash there, at least unless
it is a cosmically weird coincidence that it base64 encodes to all hex
digits. :-)

I would expect something like

$ dsum -a sha1 COPYING; sha1sum COPYING
s.w4runjyMTV1ZT_VIob4FRTAjAW1ihpMfZRLbIV7B_UI  COPYING
s.w4runjyMTV1ZT_VIob4FRTAjAW1ihpMfZRLbIV7B_UI  COPYING
$ dsum -a sha1 -a md5 COPYING
s.w4runjyMTV1ZT_VIob4FRTAjAW1ihpMfZRLbIV7B_UI  COPYING
4325afd396febcb659c36b49533135d4  COPYING
$ echo m | sha1sum -
s.-tUTs04N4IxBOtWpdoIXt1b0qgHIgNm9IC_OgYjm-mU  -

-- 
Henning Makholm"But I am a Sunni Muslim," the bemused Arab said.


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

Re: Bug#341127: ITP: libformvalidator-simple-perl -- validation with simple chains of constraints

[Florian Ragwitz]

On Mon, Nov 28, 2005 at 04:38:56PM +0100, Krzysztof Krzyzaniak (eloy) wrote:
> Package: wnpp
> Severity: wishlist
> Owner: "Krzysztof Krzyzaniak (eloy)" <[EMAIL PROTECTED]>
> 
> * Package name: libformvalidator-simple-perl
>   Version : 0.11
>   Upstream Author : Lyo Kato <[EMAIL PROTECTED]>
> * URL : http://search.cpan.org/~lyokato/FormValidator-Simple-0.10/
> * License : Perl: GPL/Artistic
>   Description : validation with simple chains of constraints
> 
>  This module provides you a sweet way of form data validation with
>  simple constraints chains. You can write constraints on single line
>  for each input data.
>  .
>  This idea is based on Sledge::Plugin::Validator, and most of
>  validation code is borrowed from this plugin.

What's the difference to Data::FormValidator?


-Flo

-- 
BOFH excuse #258:
That's easy to fix, but I can't be bothered.


signature.asc
Description: Digital signature

Re: texlive-basic_2005-1_i386.changes REJECTED

[Joerg Jaspert]

On 10487 March 1977, Norbert Preining wrote:

> I have reworked the whole packaging naming and would like all of you
> again for comments:

WTH, what a thread. :) And its also *not* a flamewar. Is hell freezing? :)

> Please comment, not only on the package naming, but also on the
> bin-to-source mapping.

Hey, that looks ways better than the initial upload. Good work. :)
And with 5 sources left its also much less then what I suggested.

> texlive-binaries-source   96M
> texlive-documentation-source  57M
> texlive-languages-source  37M
> texlive-base-source   78M
> texlive-extra-source  172M

Drop the -source from the source names i would say. Its clear what is
source and what not. :)

With those package sizes you should be *damn sure* that the stuff
you/your sponsor uploads *really* works and doesnt have any simple
errors. I assume you have a good testsuite for it? :)

>> allrunes   dfsg
>> Please: Tell me its not true that the DFSG is used as a license there.
>As stated in the License file, this list was generated from the TeX
>Catalogue, which *can be wrong*! If you check the actual allrunes files,
>you see that it is LPPL.

Well, yes. To be honest: I looked for the real license before I wrote
this. :)
Take this as a pointer to a.) correct the catalog and b.) correct the
header of the generated license.txt. And/Or whoever listed "dfsg" as a
license in the first place.

-- 
bye Joerg
A.D. 1492:
Christopher Columbus arrives in what he believes to be India, but
which RMS informs him is actually GNU/India.


pgpJBsKjeSP1X.pgp
Description: PGP signature

Re: Bug#341127: ITP: libformvalidator-simple-perl -- validation with simple chains of constraints

[Krzysztof Krzyzaniak]

Florian Ragwitz wrote:

On Mon, Nov 28, 2005 at 04:38:56PM +0100, Krzysztof Krzyzaniak (eloy) wrote:


Package: wnpp
Severity: wishlist
Owner: "Krzysztof Krzyzaniak (eloy)" <[EMAIL PROTECTED]>

* Package name: libformvalidator-simple-perl
 Version : 0.11
 Upstream Author : Lyo Kato <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/~lyokato/FormValidator-Simple-0.10/
* License : Perl: GPL/Artistic
 Description : validation with simple chains of constraints

This module provides you a sweet way of form data validation with
simple constraints chains. You can write constraints on single line
for each input data.
.
This idea is based on Sledge::Plugin::Validator, and most of
validation code is borrowed from this plugin.



What's the difference to Data::FormValidator?


Generally - it's simplier to use (IMHO of course), have more builded 
checkers and it's used in Catalyst::Plugin::FormValidator::Simple :-)


  eloy
--
[EMAIL PROTECTED]

   jak to dobrze, że są oceany - bez nich byłoby jeszcze smutniej


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

Re: Secret changes for binNMUs

[Roger Leigh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Wouter Verhelst <[EMAIL PROTECTED]> writes:

> On Thu, Nov 24, 2005 at 06:51:24PM +0100, Goswin von Brederlow wrote:

>> Last year the aim was to get the buildd sbuild and debian sbuild back
>> in sync and it pains me to see Ryan silently diferting it further and
>> further instead of aiding that goal.
>
> That's one way to look at it.
>
> The other way would be to say that Ryan has recently been actively
> working on improving the code in the wanna-build SVN, and that the
> people maintaining the sbuild package in Debian (Roger?) haven't been
> paying too much attention to their upstream, likely because they didn't
> see the link on buildd.debian.org--a link which I, admittedly, had
> missed out on at first too, because it used to point to
> cvs.linux-m68k.org. There is indeed still a wanna-build CVS repository
> over there, but it's been effectively unmaintained for as long as I can
> remember.

This is very true.  I wasn't aware of the SVN repository until it was
mentioned in this thread.  Over the weekend, I have merged almost all
the SVN changes:

http://cvs.alioth.debian.org/cgi-bin/cvsweb.cgi/sbuild/sbuild?cvsroot=buildd-tools
http://lists.alioth.debian.org/pipermail/buildd-tools-devel/2005-November/000388.html

As you mentioned, due to cvs.linux-m68k.org being unmaintained for
years, the code in the Debian package (maintained by Rick Younie, now
group maintained by Francesco Paolo Lovergine, Michael Banck and I),
and the code used by the buildds has diverged over the years.  Even
after the above merge the diff is still around 1000 lines, which I
hope we can reduce much further if we can merge the changes both ways
to reduce the differences as much as possible.  Perl being Perl, so
far all the merging has been by hand, and going through the remaining
huge diff by hand will take some time.


Regards,
Roger

- -- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ 

iD8DBQFDi48wVcFcaSW/uEgRAgf2AJ9OeKLykTblYCu9nhVatvBm2lRfeQCgsrpM
D6zpcMr6kY7X+WetUgTjo1Q=
=Rv3N
-END PGP SIGNATURE-


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

Re: Checksumming tool

[Adam Heath]

On Mon, 28 Nov 2005, Lars Wirzenius wrote:

> File: foo%20bar/hellurei.txt
> Size: 12345
> MD5: 012345667
> SHA-256: 0a0a0a0a0a0a0a0a0a0a0a0a
> Mode: 0644

Checksum:
 md5: 0123456789[B
 sha-256: 0a0a0a0a0a0a0a0a0a0a0a0a

Having the names of the checksums be the header names could lead to clashes.


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

Re: Checksumming tool

[Lars Wirzenius]

ma, 2005-11-28 kello 18:20 -0600, Adam Heath kirjoitti:
> On Mon, 28 Nov 2005, Lars Wirzenius wrote:
> 
> > File: foo%20bar/hellurei.txt
> > Size: 12345
> > MD5: 012345667
> > SHA-256: 0a0a0a0a0a0a0a0a0a0a0a0a
> > Mode: 0644
> 
> Checksum:
>  md5: 0123456789[B
>  sha-256: 0a0a0a0a0a0a0a0a0a0a0a0a
> 
> Having the names of the checksums be the header names could lead to clashes.

That's a point. I think I'd leave out the colon after the checksum name,
or possibly change it to an equals sign:

Checksum: md5=123123123123123
  sha-256=aaffaaffaaffaaffaaff

Those are pretty small details, though, I could easily live with any of
these.

-- 
sic transit discus mundi


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

Re: Chao ban ve may bay

[than Dao]

xinh chao anh chi...!     em muong ve vietnamvao thang 2 ngay 10 may cung duoc.   3 ve nguoi lo'n..va`  3 ve con nit'.      di tu'` tieu bang vermont...ve da` nang~.      xin anh chi cho biet tien ve' la` bao nhieu  xin goi.802 863 3303 =  cell---   802 310 9485    gap...tung hay minh..  thank y./
		 Yahoo! Music Unlimited - Access over 1 million songs. Try it free.

ウイルス警告 - InterScan for Lotus Notes --> Hello

[topsv03]

InterScan has detected a virus during a real-time scan of the email
traffic.


日付: 2005/11/29 10:44:00 AM
件名:  Hello
ウイルス:   WORM_MYTOB.A
ファイル:   doc.scr
From: debian-devel@lists.debian.org
To:   [EMAIL PROTECTED]
処理: 削除済み：

Scanned by ScanMail for Lotus Notes 2.6 SP1
with scanengine 7.500-1001
and pattern version 2.971.00



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

ウイルス警告 - InterScan for Lotus Notes --> Test

[topsv03]

InterScan has detected a virus during a real-time scan of the email
traffic.


日付: 2005/11/29 10:44:03 AM
件名:  Test
ウイルス:   WORM_MYTOB.A
ファイル:   doc.zip
From: debian-devel@lists.debian.org
To:   [EMAIL PROTECTED]
処理: 削除済み：

Scanned by ScanMail for Lotus Notes 2.6 SP1
with scanengine 7.500-1001
and pattern version 2.971.00



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

Re: Checksumming tool

[Anthony DeRobertis]

Lars Wirzenius wrote:
> 
> The best I've come up with so far is a pseudo rfc822 syntax:
> 
> File: foo%20bar/hellurei.txt
> Size: 12345
> MD5: 012345667
> SHA-256: 0a0a0a0a0a0a0a0a0a0a0a0a
> Mode: 0644

[EMAIL PROTECTED]:tmp$ md5sum test
04c09e317db0addf12be8d1a4e2b9e37  test

[EMAIL PROTECTED]:tmp$ sha1sum test
35a980f320a5f72b11f3616c476fab2844118879  test


That format is extremely easy to work with using basic Unix commands
like grep, cut, sort, diff, etc. The one you've come up with is not.

Please, keep the useful one record (file) per line format. Is there
something wrong with:

LINE = TAG DELIM1 HASH DELIM2 FILENAME
DELIM1 = " " | "-" | ":" | ... (pick one)
DELIM2 = " "

If you let DELIM1 be either "-" or ":" and DELIM2 be " " then you are
backwards compatible with both md5sum and sha1sum by making 32-character
untagged hashes mean MD5 and 40-character ones mean SHA-1.

sha-256:<> test

is so much easier to deal with than rfc822 stuff.


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

Re: texlive-basic_2005-1_i386.changes REJECTED

[Anthony DeRobertis]

Norbert Preining wrote:

> 
> texlive-binaries-source   96M
> ---
> texlive-basicbin  texlive-base-bin
> texlive-binextra  texlive-extrautils

I'd suggest texline-extra-utils here, because (at least to me) "extra"
and "utils" put together are hard to read. Possibly because "au"
generally (always, maybe even) goes together as one sound in English.

In general, hyphenated is far easier to read than concatenated, so I
don't see a problem with prefering it. Just-try-reading-this-sentence
vs. Justtryreadingthissentence.

> texlive-langindic texlive-lang-indic

Shouldn't this go with languages, below?

> texlive-graphicstools texlive-graphicstools

A hyphen would really be appreciated here, too. Probably because of "st"
generally being one sound in English. Not to mention "graphic stools"
has the same spelling.

> texlive-langcjk   texlive-lang-cjk

Another language.

> texlive-documentation-basetexlive-base-doc
> texlive-documentation-bulgarian texlive-bg-doc
> texlive-documentation-czechslovak texlive-cs-doc
> texlive-documentation-dutch   texlive-nl-doc

I'm going to agree with the other poster: These should all be
texlive-doc-FOO instead of texlive-FOO-doc (including the base one).
It'll make them all sort nicely in aptitude, and also makes them be
found when the user searches (in aptitude) for texlive-doc.

> texlive-languages-source  37M
> 
> Reasoning: We use names instead of codes as several of these packages include
> support for different languages/variants (greek: various versions of greek 
> with different iso codes, ...). 

This makes them oddly different than the documentation packages. Could
you maybe use ISO codes, either two or three letter, where possible? Its
fairly clear that -lang-african can't do that, but almost all of them can.


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

Re: texlive-basic_2005-1_i386.changes REJECTED

[Anthony DeRobertis]

Norbert Preining wrote:

>>allrunes   dfsg
>>
>>Please: Tell me its not true that the DFSG is used as a license there.
> 
> 
> As stated in the License file, this list was generated from the TeX
> Catalogue, which *can be wrong*! If you check the actual allrunes files,
> you see that it is LPPL.

I really hope you've done this --- for all files --- before uploading.
Also, there are several versions of the LPPL, at least one of which
might have DFSG issues.


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

Re: texlive-basic_2005-1_i386.changes REJECTED

[Miles Bader]

> How would the layout go for documentation packages. Ok, for a
> documentation in language  I take the XX code and generate
>   old:texlive-documentation-x
>   new:texlive-XX-doc

A bit of searching suggests the most common patterns are:

   PKG-doc
   PKG-doc-TYPE (TYPE is like "html", "ps", "info" etc.)
   PKG-doc-LANG (LANG is usually code like "fr")

> But what to do with the texlive-documentation-base, should it become
>   old:texlive-documenatation-base
>   new:texlive-base-doc

Not sure, but I guess either just "texlive-doc" or "texlive-doc-base".

> For the language stuff: Here is a problem as some languages packages are
> not *one* single language, but several (arabic, cjk, other). So would it
> be the best solution to have
>   old:texlive-langX
>   new:texlive--lang

Existing usage seems a bit mixed; the main common point seems to be
"-LANG" as a suffix.  Some patterns are:

   PKG-LANG
   PKG-locale-LANG  (this seems the most common)
   PKG-l10n-LANG(openoffice uses this)
   PKG-i18n-LANG(kde uses this)

I don't know if there's some technical nuance to the term "locale" which
would make it inappropriate for texlive's usage, but it's the most common
so would seem the best bet generally.

[For stuff like "cjk" and "arabic" I'd just use the same namespace -- it
seems very unlikely they'll ever conflict with a new language code.]

> Renaming some of them in the `obvious' way is in fact misleading: Take
> eg 
>   old:texlive-binextra
> and rename it to
>   new:texlive-extra-bin
> Then most Debian users would expect a package "texlive-extra" and this
> one would provide only the binaries.

I think "PKG-bin-extra" would be better.

I think debian usage mostly agrees with the original texlive names
except for the details of some common tags, e.g. "doc" instead of
"documentation" and more hyphens.

So how about as a start, just:

   sed -e 's/-documentation/-doc/'  \
   -e 's/-lang\(uages-\)*/-locale-/'\
   -e 's/bin$/-bin/'\
   -e 's/binaries/bin/' \
   -e 's/basic-bin/bin/'\
   -e 's/-basic/-base/' \
   -e 's/\(extra\|recommended\)$/-\1/'  \
   -e s/armenian/hy/ -e s/bulgarian/bg/ -e s/croatian/hr/   \
   -e s/czechslovak/cs-sk/ -e s/danish/da/ -e s/dutch/nl/   \
   -e s/ukenglish/en-gb/ -e s/english/en/ -e s/finnish/fi/  \
   -e s/french/fr/ -e s/german/de/ -e s/greek/el/   \
   -e s/hebrew/he/ -e s/hungarian/hu/ -e s/italian/it/  \
   -e s/japanese/ja/ -e s/korean/ko/ -e s/latin/la/ \
   -e s/mongolian/mn/ -e s/norwegian/no/ -e s/polish/pl/\
   -e s/portuguese/pt/ -e s/russian/ru/ -e s/spanish/es/\
   -e s/swedish/sv/ -e s/tibetan/bo/ -e s/ukrainian/uk/ \
   -e s/thai/th/ -e s/vietnamese/vi/

That gives this list:


texlive-bin-source  96M
texlive-bin
texlive-bin-extra
texlive-font-bin
texlive-htmlxml
texlive-metapost
texlive-omega
texlive-pdfetex
texlive-psutils
texlive-ttfutils
texlive-music
texlive-locale-indic
texlive-graphicstools
texlive-locale-cjk

texlive-doc-source  57M
texlive-doc-base  
texlive-doc-bg
texlive-doc-cs-sk
texlive-doc-nl
texlive-doc-en
texlive-doc-fi
texlive-doc-fr
texlive-doc-de
texlive-doc-el
texlive-doc-it
texlive-doc-ja
texlive-doc-ko
texlive-doc-mn
texlive-doc-pl
texlive-doc-pt
texlive-doc-ru
texlive-doc-es
texlive-doc-th
texlive-doc-uk

texlive-locale-source   37M
texlive-locale-african
texlive-locale-arab
texlive-locale-hy
texlive-locale-hr
texlive-locale-cyrillic
texlive-locale-cs-sk
texlive-locale-da
texlive-locale-nl
texlive-locale-fi
texlive-locale-fr
texlive-locale-de
texlive-locale-el
texlive-locale-he
texlive-locale-hu
texlive-locale-it
texlive-locale-la
texlive-locale-manju
texlive-locale-mn
texlive-locale-no
texlive-locale-other
texlive-locale-pl
texlive-locale-pt
texlive-locale-es
texlive-locale-sv
texlive-locale-bo
texlive-locale-en-gb
texlive-locale-vi

texlive-base-source 78M
texlive-base
texlive-context
texlive-generic-recommended
texlive-latex
texlive-latex-recommended
texlive-fonts-recommended
texlive-pictures

texlive-extra-source172M
texlive-bibtex-extra
texlive-formats-extra
texlive-generic-ex

Bug#341188: ITP: libwcs -- FITS world coordinate system support library

[Justin Pryzby]

Package: wnpp
Severity: wishlist

* Package name: libwcs
  Version : 4.2
  Upstream Author : Mark R. Calabretta <[EMAIL PROTECTED]>
* URL : http://www.atnf.csiro.au/people/mcalabre/WCS/
* License : GPL
  Description : FITS world coordinate system support library

Please critique my understanding of library packaging (copy me in
responses).  Upstream doesn't (yet!) build a shared library, so it
seems the burden lies on me to implement that support.  But wcslib is
used by 2 of my packages (saods9 and sextractor), and seems to provide
a highly specialized, yet readily accessible and well-documented API,
which I can easily see being useful in my own projects.

  WCSLIB is a C library, supplied with a full set of Fortran wrappers,
  that implements the "World Coordinate System" (WCS) convention in
  FITS (Flexible Image Transport System).  It also includes a
  PGPLOT-based routine, PGSBOX, for drawing general curvilinear
  coordinate graticules.

  The FITS data format is widely used within the international
  astronomical community, from the radio to gamma-ray regimes, for
  data interchange and archive, and also increasingly as an online
  format.  It is described in

"Definition of The Flexible Image Transport System (FITS)",
Hanisch, R.J., Farris, A., Greisen, E.W., et al. 2001, A&A, 376,
359

  which formalizes NOST 100-2.0, a document produced by the
  NASA/Science Office of Standards and Technology, see
  http://fits.gsfc.nasa.gov.


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

Re: dpkg-sig support wanted?

[Anthony Towns]

On Mon, Nov 28, 2005 at 10:15:34PM +0100, Henning Makholm wrote:
> I would expect something like
> $ dsum -a sha1 COPYING; sha1sum COPYING
> s.w4runjyMTV1ZT_VIob4FRTAjAW1ihpMfZRLbIV7B_UI  COPYING
 
sha1sum already exists; and isn't that long. Do you mean sha256?

Cheers,
aj



signature.asc
Description: Digital signature

Re: dpkg-sig support wanted?

[Anthony Towns]

On Mon, Nov 28, 2005 at 12:09:33PM -0600, Peter Samuelson wrote:
> I still think two-byte prefixes for non-md5-non-sha1 hashes makes some
> sense, like s- for sha-256.  Avoids the filename encoding issue you
> mentioned later (unless we want to encode newlines).

The encoding issues are only for doing base64 (or similar compression)
or filename encoding, so you can't avoid them :)

> > OTOH, it would be far more convenient for *us* if it supported the
> > .changes style we use, ie:
> >   MD5Sum:
> > hash size filename
> This might be generally reasonable, 

Doesn't matter if it's generally reasonable, it's needed by *us*. That's
the format we use in .changes, in .dscs and Sources, and in Release.
It's silly to have a useful format, then not have tools that
conveniently check it, particularly if we're writing our own.

> >   $ dsum -a sha1 foo; sha1sum foo
> >   f572d396fae9206628714fb2ce00f72e94f2258f  foo
> >   f572d396fae9206628714fb2ce00f72e94f2258f  foo
> > 
> >   $ dsum -d foo
> >   SHA1Sum:
> >f572d396fae9206628714fb2ce00f72e94f2258f 6 foo
> > 
> >   $ dsum -b foo
> >   SHA1 (foo) = f572d396fae9206628714fb2ce00f72e94f2258f
> What's the " 6 " above?  

wc -c foo. foo was "hello\n" for reference. (And it probably should've
been SHA1: not SHA1Sum: too)

> > (Note that "dsum" would probably need to become Priority:required,
> > and possibly Essential:yes, with the complications that entails)
> Hmmm, promoting libgcrypt11 + libgpg-error0 to Required adds 516 kB on
> i386, plus a trivial amount for dsum itself.  I wonder if it'd be
> better to just copy / paste the algorithm code into dsum.

libssl0.9.8 is 860kB of .deb, 2MB installed. It's possible that libssl
would be too much of a nuisance wrt transitions to use, at least
dynamically.

Cheers,
aj



signature.asc
Description: Digital signature