Re: curl reverts to openssl (but the story does not ends here)

[Steve Langasek]

On Sat, Aug 06, 2005 at 02:10:29AM +0200, Domenico Andreoli wrote:
> 
> BTW what about gssapi support? kerberos or heimdal?

> hmmm... there is smell of combinatorial explosion. debian is about
> choice, not explosions, isn't it? how much it is for choice and how
> much is for explosions?
> 

Mmm, FWIW, there are no license issues with MIT/Heimdal Kerberos that would
necessitate having two builds.  I'm not sure if there are other reasons
currently to prefer one over the other except in talking with particular
servers, but one certainly shouldn't try to do dual builds of packages
unless such use cases manifest.

> i continue to think that having only a curl+gnutls package is the
> long term solution but i'll be glad to hear also your opinion and
> suggestions. [1]

Agreed, but of course the source has to be in a state to allow that.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Change of contact info

[Stephen Ronan]

Hi
I am no longer on CTCNet staff and do not receive email directed to this
address. I can now be reached at [EMAIL PROTECTED]

For any CTCNet-related business, please contact CTCNet's Executive
Director, Kavita Singh, at [EMAIL PROTECTED]

Thanks,
Steve Ronan


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

packaging for multiple JDKs

[Charles Fry]

Hi,

I am currently working on bug #234048 to package Bouncy Castle Crypto, a
Java implementation of various cryptographic algorithms, for Debian. My
previous post about issues I have encountered went unanswered:

   http://lists.debian.org/debian-java/2005/07/msg3.html

My primary dilema is this:

Bouncy Castle has a binary release for every JDK from 1.0 to 1.5, and
J2ME. I had been planning to create a separate binary package for each
JDK, but was unable to find any precedent for doing something like this
in Java. It seems that most Java packages outright depend on a specific
JDK, and make no effort to be backwards compatible.

This issue is further complicated by the fact that increasing JDK
requirements are also associated with a decreasing ability on my part to
build the Debian packages using free Java tools. For example, with no
extra work on my part, I was able to build all releases from JDK 1.0 up
to 1.2, but I have not yet managed to succesfully build versions 1.3 to
1.5 using free tools.

Have other packages had to deal with similar issues? How would you
recommend that I approach this dilema?

thanks,
Charles

-- 
Salesmen, tourists
Camper-outers
All you other
Whisker-sprouters
Don't forget your
Burma-Shave
http://burma-shave.org/jingles/1937/salesmen_tourists


signature.asc
Description: Digital signature

curl reverts to openssl (but the story does not ends here)

[Domenico Andreoli]

reopen 318590
thanks

hi dear developers,

  it looks like i completely underestimated the transition of curl to
gnutls [0]. so i have just made a new upload which settles the things
back to openssl.

i don't want to start any transition right now, also because upstream
developer made me note that the gnutls support is still young.

these are bad news for those gpl packages waiting for libcurl with no
openssl. they will have to wait a little more. i'm sorry for this.


in talking about the solution IMHO things get hotter.

probably the next simpler solution is to add libcurl3-gnutls and,
if required, libcurl3-gnutls-dev packages. but somebody could prefer
a -nossl version (like that still in woody, the one i should have
never removed).


BTW what about gssapi support? kerberos or heimdal?

hmmm... there is smell of combinatorial explosion. debian is about
choice, not explosions, isn't it? how much it is for choice and how
much is for explosions?


i continue to think that having only a curl+gnutls package is the
long term solution but i'll be glad to hear also your opinion and
suggestions. [1]


thank you
domenico


[0] probably because i never wanted to start such transition. my hope
was to (ingenuously) hide the change within the curl build process.

[1] yes, recently a thread talked right about curl and openssl vs. gnutls,
but evidently i didn't see what i call a general consensus.

-[ Domenico Andreoli, aka cavok
 --[ http://people.debian.org/~cavok/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50


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

not starting daemons at boot: ln -s disabled

[Dan Jacobson]

One way of having some daemons not start at boot (e.g., if we only use
our printer once a year) is to remove certain /etc/rc?.d/ links.

But the downsize is later, unless one keeps records, one isn't quite
sure of just what tampering one has done in /etc/rc?.d/

So in /etc/default/* we can set NO_START_AT_BOOT=1 etc., at least we
can see and comment what we did.

However there still is a way to know what we tampered with in
/etc/rc?.d/: instead of telling the user to just remove some links,
have them instead ln -s to /dev/null or better: /etc/init.d/disabled perhaps,
an empty file mode 555.

And those link manager programs could do the same.

So then one could see clearly that S20cwdaemon -> ../init.d/disabled
etc.  Or use DISABLED for extra clarity.

Not as efficient as removing the link, but at least one can see what
one did later.


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

Re: net-tools maintenance status

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> Didn't I (also) send you a much later version?

Hmm.. I cant find that, but yes I thin u did. Can you dig that up?

Bernd


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

Re: net-tools maintenance status

[Olaf van der Spek]

On 8/5/05, Bernd Eckenfels <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> >> I have attached it to the bug.
> > Thanks. But: It's not ready yet, but what do you think of it?
> 
> It is not ready yet :)

Didn't I (also) send you a much later version?
 
> No seriously I think the idea with having the column width in *_width is
> fine. I would add a calculation of it based on COLUMS if and only if COLUMNS
> is > 80 and --wide is given. I am not sure how to react if output is not a
> tty. One option is to always asume a very wide line, the other is to stick
> with columns. For beeing compatible with parsing scripts I think the output
> without wide option should not change (however I think everybody who is
> arsing netstat output is insane)

The later version auto-sets the wide option if there's a tty and
detects the width of the tty.

Re: net-tools maintenance status

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
>> I have attached it to the bug.
> Thanks. But: It's not ready yet, but what do you think of it?

It is not ready yet :)

No seriously I think the idea with having the column width in *_width is
fine. I would add a calculation of it based on COLUMS if and only if COLUMNS
is > 80 and --wide is given. I am not sure how to react if output is not a
tty. One option is to always asume a very wide line, the other is to stick
with columns. For beeing compatible with parsing scripts I think the output
without wide option should not change (however I think everybody who is
arsing netstat output is insane)

Bernd

PS: please use unified diffs -u, better readable.


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

Re: possible ICU transition

[Steve Langasek]

On Fri, Aug 05, 2005 at 12:05:59PM -0400, Jay Berkenbilt wrote:

> The version of icu in debian is very old.  I have recently taken over
> maintainership of the package.  I had originally intended to wait
> until after the g++ transition had completed to do the ICU transition,
> but I'm now strongly considering building new ICU packages to upload
> to unstable before the g++ transition is finished.  The main reason
> for this is that icu 2.1 fails to build on ARM, but icu 3.4 beta
> succeeds.  The only direct reverse dependencies of the icu package are
> the xerces packages which I also maintain.  There are only three or
> four reverse dependencies of the xerces packages.  Right at this
> moment, libxml-xerces-perl has succeeded on arm even though xerces25
> has failed, which probably means that it is not in a stable state with
> respect to the g++ transition.  Also, I'm about to move, go on
> vacation, and change jobs, so my available time will drop for a short
> time (from late August through mid September), and it might be good to
> have this done before then.  There is also an icu28 package in debian,
> but it is not necessary to convert its reverse dependencies to use the
> new icu package at the same time -- that can wait until after the g++
> transition.

> If I start this transition as early as this weekend, it should not
> hold up the g++ transition, and I will be able to monitor it closely
> for two or three weeks before I start being much less available.
> Given all this, can anyone think of any reason why I should not start
> an ICU transition this weekend?

If the only packages that need to be rebuilt for this change are xerces25
and xerces26, and those packages don't also need to have name changes in the
process, then I see no reason not to proceed with the change.  You'll have
to upload icu one way or another to fix the FTBFS, so you might as well go
with the lib transition while you're at it since the set of affected
packages is so small.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: valknut and libdc0 - gcc 4.0 transition

[Steve Langasek]

On Fri, Aug 05, 2005 at 01:42:06PM +0200, Ondrej Sury wrote:
> On Fri, 2005-08-05 at 12:46 +0200, Ondrej Sury wrote:
> > I was just looking at valknut and libdc0 packages which didn't undergo
> > gcc 4.x ABI transition and how one question:

> > If valknut is only package which is using C++ libdc0 package, is there
> > real technical reason to rename libdc0 to libdc0c2 instead of just
> > adding:

> > Conflicts: valknut (<< gcc-4.x.version), dcgui-qt (<< gcc-4.0version)

> > to libdc0

This is less robust in the face of third-party valknut debs that may have
transitioned to gcc-4.0 at a different point in their version history.
There's also no reason to conflict with dcgui-qt here, btw; and in any case,
<< conflicts are known to be problematic for upgrades, so this will cause
awkward upgrade paths any time apt picks up the new version of libdc0 as an
upgrade candidate before it sees the new version of valknut: apt may choose
to remove valknut instead of upgrading it.

If you rename the library package, then valknut is the upgrade candidate,
and libdc0c2 is pulled in automatically and libdc0 is removed automatically.

> Err, maybe shlibs update is more appropriate :-)

I don't understand what you mean there.

> > and
> > 
> > Depends: libdc0 (>= gcc-4.x.version)

> > I am pretty sure, that there is no other (even proprietary) package
> > which uses libdc0.

I still think it would be bad form to rely on this, although I hope the
above arguments have already persuaded you to rename according to the
transition plan.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: net-tools maintenance status

[Olaf van der Spek]

On 8/5/05, Bernd Eckenfels <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > Yes, it's about that bug.
> 
> I have attached it to the bug.

Thanks. But: It's not ready yet, but what do you think of it?

Re: possible ICU transition

[Shachar Shemesh]

Steinar H. Gunderson wrote:


On Fri, Aug 05, 2005 at 09:04:34PM +0200, Andreas Fester wrote:
 


being involved in an i18n project currently, I also learned about
ICU recently. I was a littlebit disappointed to find only a very old
version in the Debian archive, so its very good to see that the package
is still maintained and that you are working on the current 3.4 version
:-)
   



While we're at all the i18n (is there a more proper list for this, BTW?)
business: Is there a good way for a given locale of getting ordinal numbers?
Ie. func(1) = “1st”, func(2) = “2nd”, func(3) = “3rd” etc. for LANG=en_US,
func(1) = “1ère”, func(2) = “2ème”, func(3) = “3ème” etc. for LANG=fr_FR and
so on...

/* Steinar */
 

Actually, ICU can do that. Search for the word "ordinal" at 
http://icu.sourceforge.net/apiref/icu4c/classRuleBasedNumberFormat.html 
for a lead.


I would recommend against, however, for two reasons:
1. ICU's link requirements are horrible. If you link with a particular 
version of ICU, the version number gets mangled into the function name, 
so that replacing the shared object at a later point is just a big 
no-no. In addition to that, if your project is not C++, you are creating 
a dependency on the C++ runtime library, which is often a problem. I 
introduced ICU dependency into Wine to put in BiDi support, and the code 
is rotting away there, because it is basically unmaintainable.


2. The actual concept is flawed. ICU is trying to give the impression 
that you can just type in a number and get it translated into textual 
representation without knowing in advance anything about the language 
(http://www-950.ibm.com/software/globalization/icu/demo/locales). The 
problem is that the people doing the designing are usually western 
people. This means that it works great for Latin based languages, but 
the further away you travel, the less well it works.


Example: In English: 1st (or "first"). In French, 1ère. In Hebrew? Well, 
it depends. If you are counting male object (and in Hebrew, nouns have a 
gender), that would be "ראשון", otherwise it would be "ראשונה". The 
description is dependent on the noun.


About a year ago, ICU simply did not have an answer to that problem. I 
just looked again to find out the answer for your original question, and 
they do appear to have a muscular vs. feminine forms. Give them 10/10 
for effort. I fail to see how that can solve the problem, though. Even 
if you were somehow made aware that some languages have this distinction 
(a great advancement already), you have no clue what the object's gender 
should be. Please bear in mind that Hebrew is not the only language to 
have gendered nouns. Also bear in mind that while "Table" is male in 
Hebrew, it may well be female in another language.


In short, please think carefully before using an automatic solution for 
generating your numbers. Things may not be as simple as you think.


   Shachar

--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/


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

Re: net-tools maintenance status

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> Yes, it's about that bug.

I have attached it to the bug.

Greetings
Bernd


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

Re: mass bug filing on packages that are blocking use of cdebconf

[Mattia Dongili]

On Tue, Aug 02, 2005 at 06:46:20PM -0400, Joey Hess wrote:
[...]
> Mattia Dongili <[EMAIL PROTECTED]>
>cpufreqd

fixed and uploaded.

-- 
mattia
:wq!


signature.asc
Description: Digital signature

Re: possible ICU transition

[Andreas Fester]

Steinar H. Gunderson wrote:

While we're at all the i18n (is there a more proper list for this, BTW?)
business: Is there a good way for a given locale of getting ordinal numbers?
Ie. func(1) = “1st”, func(2) = “2nd”, func(3) = “3rd” etc. for LANG=en_US,
func(1) = “1ère”, func(2) = “2ème”, func(3) = “3ème” etc. for LANG=fr_FR and
so on...


I think if I had to implement such a function, I would use a kind of
property file, i.e. an approach similar to other language specific text
strings and translate the text strings which are needed; becomes
difficult of course if there is an open end of numbers you have to
support...

Regards,
Andreas

--
Andreas Fester
mailto:[EMAIL PROTECTED]
WWW: http://littletux.homelinux.org
ICQ: 326674288


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

Virus intercepted

[debian-devel]

A message you sent to
<[EMAIL PROTECTED]>
contained Worm.SomeFool.P and has not been delivered.


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

Bug#321475: ITP: libcommons-io-java -- Common useful IO related classes

[Trygve Laugstøl]

Package: wnpp
Severity: wishlist
Owner: "Trygve Laugstøl" <[EMAIL PROTECTED]>


* Package name: libcommons-io-java
  Version : 1.0
  Upstream Authors: Scott Sanders <[EMAIL PROTECTED]>,
dIon Gillard <[EMAIL PROTECTED]>,
Nicola Ken Barozzi <[EMAIL PROTECTED]>,
Henri Yandell <[EMAIL PROTECTED]>,
Stephen Colebourne,
Jeremias Maerki <[EMAIL PROTECTED]>,
Matthew Hawthorne <[EMAIL PROTECTED]>, 
Martin Cooper 
* URL : http://jakarta.apache.org/commons/io/
* License : ASL
  Description : Common useful IO related classes

Commons-IO contains utility classes, stream implementations, file filters and
endian classes.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.6-1-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Bug#321476: ITP: ognl -- Java expression language

[Trygve Laugstøl]

Package: wnpp
Severity: wishlist
Owner: "Trygve Laugstøl" <[EMAIL PROTECTED]>


* Package name: ognl
  Version : 2.5.1
  Upstream Authors: Drew Davidson <[EMAIL PROTECTED]>
Luke Blanshard
* URL : http://www.example.org/
* License : Modern BSD licensing
  Description : Java expression language

OGNL stands for Object-Graph Navigation Language; it is an expression
language for getting and setting properties of Java objects. You use the
same expression for both getting and setting the value of a property.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.6-1-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Re: Maintainer/List for ALSA Audio

[Steinar H. Gunderson]

On Fri, Aug 05, 2005 at 11:40:45AM -0700, Allyn, MarkX A wrote:
> Is there a maintainer for the ALSA Audio drivers/lib/utils? 
> Is there a separate email list?
> 
> I have some questions about ALSA on both the production and testing
> releases.

trofast:~# apt-cache show alsa-base | grep Maintainer
Maintainer: Debian ALSA Maintainers <[EMAIL PROTECTED]>

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


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

Re: possible ICU transition

[Steinar H. Gunderson]

On Fri, Aug 05, 2005 at 09:04:34PM +0200, Andreas Fester wrote:
> being involved in an i18n project currently, I also learned about
> ICU recently. I was a littlebit disappointed to find only a very old
> version in the Debian archive, so its very good to see that the package
> is still maintained and that you are working on the current 3.4 version
> :-)

While we're at all the i18n (is there a more proper list for this, BTW?)
business: Is there a good way for a given locale of getting ordinal numbers?
Ie. func(1) = “1st”, func(2) = “2nd”, func(3) = “3rd” etc. for LANG=en_US,
func(1) = “1ère”, func(2) = “2ème”, func(3) = “3ème” etc. for LANG=fr_FR and
so on...

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


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

Re: possible ICU transition

[Andreas Fester]

Jay,

being involved in an i18n project currently, I also learned about
ICU recently. I was a littlebit disappointed to find only a very old
version in the Debian archive, so its very good to see that the package
is still maintained and that you are working on the current 3.4 version
:-)

> Given all this, can anyone think of any reason why I should not start
> an ICU transition this weekend?

I dont think that I have enough insight to speak for or against your
plan to start the transition this weekend, but it would be great to have
the current version available in the archive, and if you need any help
like beta testing the package or the like, I am available some time this
weekend.

Best Regards,

Andreas

Jay Berkenbilt wrote:

The version of icu in debian is very old.  I have recently taken over
maintainership of the package.  I had originally intended to wait

[...]

--
Andreas Fester
mailto:[EMAIL PROTECTED]
WWW: http://littletux.homelinux.org
ICQ: 326674288


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

Re: Updating tags on svn

[Enrico Zini]

On Fri, Aug 05, 2005 at 08:42:53PM +0200, Enrico Zini wrote:

> I'm checking the new tag updates from the packagebrowser.

Am I nuts today?  I wrote twice debian-devel instead of debtags-devel :(

Good thing are, debian-devel gets some peek at what's happening in
debtags-devel, and there are some issues raised in the mail on which I
wouldn't mind getting opinions also from this list :)


Ciao,

Enrico

--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Updating tags on svn

[Enrico Zini]

Hello,

I'm checking the new tag updates from the packagebrowser.

Weird thing: someone went on and removed works-with::image:raster from
pretty much everything.  I have no idea why, maybe it wasn't on purpose
and there's been a problem somewhere.

Besides the raster images, there's been lots of new tags, and generally
with high quality.  Great!

Some issues I stumbled on:

 - Are X terminals: role::sw:application, role::sw:utility or something
   else?
 - Are games role::sw:application, or should I create role::sw:game?
 - Are shells use::login?

Here are my personal overrides to the data coming from the
packagebrowser:

album: +works-with::image:raster
autotrace: +role::sw:application, +works-with::image:raster, 
+works-with::image:vector
babygimp: +works-with::image:raster
bins: +works-with::image:raster
caca-utils: +works-with::image:raster
came: +works-with::image:raster
camediaplay: +works-with::image:raster
catdoc: +works-with::textdocument, -works-with::dtp
cl-png: +works-with::image:raster
clara: +role::sw:application, +works-with::image:raster
compface: +works-with::image:raster
coriander: +works-with::image:raster
cthumb: +works-with::image:raster
curator: +works-with::image:raster
dailystrips: +works-with::image:raster
deroff: +works-with::textdocument
digikam: +works-with::image:raster, +works-with::rasterimage, 
-special::invalid-tag
djview: +works-with::image:raster
djvulibre-bin: +works-with::image:raster
djvulibre-plugin: +works-with::image:raster
docbook-dsssl: +works-with::text:formatted, +works-with::textdocument
docbook2x: +works-with::textdocument
doclifter: +works-with::textdocument
dosage: +works-with::image:raster
driftnet: +works-with::image:raster
ean13: +works-with::image:raster
enscribe: +works-with::image:raster
eog: +works-with::image:raster
exif: +works-with::image:raster
exiftags: +works-with::image:raster
exiftran: +works-with::image:raster
exrtools: +works-with::image:raster
fbgrab: +works-with::image:raster
fbi: +works-with::image:raster
fblogo: +works-with::image:raster
feh: +works-with::image:raster
fftw-dev: +works-with::image:raster
fftw2: +works-with::image:raster
fftw3: +works-with::image:raster
findimagedupes: +works-with::image:raster
fractxtra: +works-with::image:raster
gallery: +works-with::image:raster
galrey: +works-with::image:raster
gandalf-dev: +works-with::image:raster
gandalf-doc: +works-with::image:raster
gandalf1: +works-with::image:raster
gatos: +works-with::image:raster
gdk-imlib1: +works-with::image:raster
giblib-dev: +works-with::image:raster
giblib1: +works-with::image:raster
gif2png: +works-with::image:raster
giflib-bin: +role::sw:application
giflib3g: +works-with::image:raster
gimageview: +works-with::image:raster
gimp: +works-with::image:raster
gimp-cbmplugs: +works-with::image:raster
gimp-data: +works-with::image:raster
gimp-data-extras: +works-with::image:raster
gimp-dcraw: +role::sw:application, +works-with::image:raster
gimp-gap: +works-with::image:raster
gimp-python: +works-with::image:raster
gimp-texturize: +works-with::image:raster
gimp-ufraw: +role::sw:application, +works-with::image:raster
gimp2.0-quiteinsane: +works-with::image:raster
gkrellkam: +works-with::image:raster
gkrellshoot: +works-with::image:raster
gliv: +works-with::image:raster
gnome-iconedit: +works-with::image:raster
gnome-terminal: +use::login
gnuift: +works-with::image:raster
gnuift-doc: +works-with::image:raster
gnuift-perl: +works-with::image:raster
gocr: +role::sw:application, +works-with::image:raster
gocr-doc: +role::sw:application, +works-with::image:raster
gocr-gtk: +role::sw:application, +works-with::image:raster
gocr-tk: +role::sw:application, +works-with::image:raster
gozer: +works-with::image:raster
gpaint: +works-with::image:raster
gphoto2: +works-with::image:raster
gphotocoll: +works-with::image:raster
gqcam: +works-with::image:raster
gqview: +works-with::image:raster
graphviz: +works-with::image:raster, +works-with::image:vector
grip: +role::sw:application
grokking-the-gimp: +works-with::image:raster
grunch: +works-with::image:raster
gsfonts-x11: +role::content:font
gsumi: +works-with::image:raster
gthumb: +works-with::image:raster
gtkam-gimp: +works-with::image:raster
gtkmorph: +works-with::image:raster
gtksee: +works-with::image:raster
gwenview: +works-with::image:raster
helix-player: +works-with::image:raster
hermes1: +works-with::image:raster
hermes1-dev: +works-with::image:raster
html2text: +works-with::text:formatted, +works-with::textdocument
htmldoc: +works-with::text:document, +works-with::textdocument
ida: +works-with::image:raster
igal: +works-with::image:raster
imagemagick: +role::sw:application, +works-with::image:raster
imageviewer: +works-with::image:raster
imaptool: +works-with::image:raster
imgseek: +works-with::image:raster
imgsizer: +works-with::image:raster
imgvtopgm: -hardware::embedded
imlib-base: +works-with::image:raster
imlib-progs: +works-with::image:raster
imlib1: +works-with::image:raster
imlib11: +works-with::image:raster
irc

Maintainer/List for ALSA Audio

[Allyn, MarkX A]

Hello:

Is there a maintainer for the ALSA Audio drivers/lib/utils? 
Is there a separate email list?

I have some questions about ALSA on both the production and testing
releases.

Thank you

Mark Allyn

Re: mass bug filing on packages that are blocking use of cdebconf

[Thorsten Sauter]

Hi,

* Joey Hess <[EMAIL PROTECTED]> [2005-08-03 00:46]:
|libphp-adodb

fixed and uploaded.


Regards,
Thorsten

-- 
Thorsten Sauter
<[EMAIL PROTECTED]>

(Is there life after /sbin/halt -p?)


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

Re: svn merge -r 1046:1095 debtags-bigmerge/debtags debtags

[Benjamin Mesing]

> HAYAYYY!!!
> 
> $ svn st|grep ^C
> C  debian/control
> C  README
> C  configure.ac
> 
> Small things easy to resolve.  Wow!  It's done!
This should have gone to debtags-devel I suppose :-)

-- 
Please do not sent any email to the [EMAIL PROTECTED] - all email not
originating from the mailing list will be deleted automatically. Use the
reply to address instead.


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

Re: mass bug filing on packages that are blocking use of cdebconf

[Adrian von Bidder]

On Wednesday 03 August 2005 00.46, Joey Hess wrote:
[debconf dance]

> Adrian von Bidder <[EMAIL PROTECTED]>
>    postgrey

tags +pending (fixed in svn)

I hear a new upstream version is in the works, so I'll wait a week or two 
before uploading.

cheers
-- vbi

-- 
featured product: SpamAssassin - http://spamassassin.org


pgpNqPg2Ppqrz.pgp
Description: PGP signature

svn merge -r 1046:1095 debtags-bigmerge/debtags debtags

[Enrico Zini]

HAYAYYY!!!

$ svn st|grep ^C
C  debian/control
C  README
C  configure.ac

Small things easy to resolve.  Wow!  It's done!


Ciao,

Enrico and the emotion of finally doing a real merge :)

--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: net-tools maintenance status

[Olaf van der Spek]

On 8/5/05, Adam D. Barratt <[EMAIL PROTECTED]> wrote:
> On Friday, August 05, 2005 3:42 PM, Olaf van der Spek <[EMAIL PROTECTED]>
> wrote:
> 
> > On 8/2/05, Bernd Eckenfels <[EMAIL PROTECTED]> wrote:
> >> On Tue, Aug 02, 2005 at 07:45:12PM +0200, Olaf van der Spek wrote:
> >>> What's the maintenance status of the net-tools package?
> >>
> >> It is maintained. Patches are welcome.
> >>
> >> http://packages.qa.debian.org/n/net-tools.html
> >>
> >> Which patch are you talking about?
> >
> > The one for --wide
> > Did you find it already?
> 
> Any particular reason you didn't mail it to #222324? (I'm assuming that's

No (or can't remember).
Maybe because it's quite a big change and I didn't have the final
version ready the first time I mailed it (and I didn't want to 'flood'
that bug.

> the bug you're referring to; it's the only open bug against net-tools that
> mentions --wide, and neither of the bugs you've reported contain a patch)

Yes, it's about that bug.

possible ICU transition

[Jay Berkenbilt]

The version of icu in debian is very old.  I have recently taken over
maintainership of the package.  I had originally intended to wait
until after the g++ transition had completed to do the ICU transition,
but I'm now strongly considering building new ICU packages to upload
to unstable before the g++ transition is finished.  The main reason
for this is that icu 2.1 fails to build on ARM, but icu 3.4 beta
succeeds.  The only direct reverse dependencies of the icu package are
the xerces packages which I also maintain.  There are only three or
four reverse dependencies of the xerces packages.  Right at this
moment, libxml-xerces-perl has succeeded on arm even though xerces25
has failed, which probably means that it is not in a stable state with
respect to the g++ transition.  Also, I'm about to move, go on
vacation, and change jobs, so my available time will drop for a short
time (from late August through mid September), and it might be good to
have this done before then.  There is also an icu28 package in debian,
but it is not necessary to convert its reverse dependencies to use the
new icu package at the same time -- that can wait until after the g++
transition.

If I start this transition as early as this weekend, it should not
hold up the g++ transition, and I will be able to monitor it closely
for two or three weeks before I start being much less available.
Given all this, can anyone think of any reason why I should not start
an ICU transition this weekend?

An alternative would to resolve the FTBFS on arm for icu 2.1 (which
worked before g++ 4.0) and to wait for xerces25 to rebuild and then to
do a binary NMU rebuild of libxml-xerces-perl

Thoughts?

--Jay

-- 
Jay Berkenbilt <[EMAIL PROTECTED]>


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

Re: net-tools maintenance status

[Adam D. Barratt]

On Friday, August 05, 2005 3:42 PM, Olaf van der Spek <[EMAIL PROTECTED]>
wrote:

> On 8/2/05, Bernd Eckenfels <[EMAIL PROTECTED]> wrote:
>> On Tue, Aug 02, 2005 at 07:45:12PM +0200, Olaf van der Spek wrote:
>>> What's the maintenance status of the net-tools package?
>>
>> It is maintained. Patches are welcome.
>>
>> http://packages.qa.debian.org/n/net-tools.html
>>
>> Which patch are you talking about?
>
> The one for --wide
> Did you find it already?

Any particular reason you didn't mail it to #222324? (I'm assuming that's
the bug you're referring to; it's the only open bug against net-tools that
mentions --wide, and neither of the bugs you've reported contain a patch)

Regards,

Adam


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

Possible Link Partnership with debian.org

[eSuperchips]

Hello; 

I am the webmaster for the site http://www.esuperchips.com/.  At the 
moment we are in the process of creating reciprocal link partnerships.  
Since both of our sites are automotive related exchanging links will 
increase both of our search engine rankings and we will each benefit 
from greater targeted traffic.  Currently we hold several top search 
positions on Google and Yahoo which result in more than 5,000 unique 
visitors to our site each day.  All sites who link back to us will be 
showcased in front of these visitors.
 
To make the link exchange process as easy as possible we have created a 
simple link exchange form where you can simply enter in your website 
info and category.  Once complete your link will be added to our 
website within 24 hours.  To get your site listed in our directory 
simply fill in your website info on the following page:

http://www.esuperchips.com/linkexchange.html

Please link back to our website using one of the following text links 
or if you would like we have several banners you can use on our link 
exchange page at:  http://www.esuperchips.com/linkexchange.html   

1) Superchip Alternative - Gain up to 30 horsepower with the Powerboost 
Performance System. Experience results similar to expensive aftermarket 
performance chips at a fraction of the price!

2) Superchips - Gain up to 30 horsepower on any vehicle. Visit 
eSuperchips.com today! 

3) Custom Automotive Superchips - Gain up to 30 horsepower with the 
Powerboost Performance System. Experience results similar to expensive 
aftermarket performance chips at a fraction of the price!

Once you have added one of the above text links to your website simply 
fill in the link exchange form on our website and your site will be 
added to our link directory.

Sincerely; 
Blair Russell - Webmaster
eSuperchips.com



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

Re: net-tools maintenance status

[Olaf van der Spek]

On 8/2/05, Bernd Eckenfels <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 02, 2005 at 07:45:12PM +0200, Olaf van der Spek wrote:
> > What's the maintenance status of the net-tools package?
> 
> It is maintained. Patches are welcome.
> 
> http://packages.qa.debian.org/n/net-tools.html
> 
> Which patch are you talking about?

The one for --wide
Did you find it already?

Re: Usability: Technical details in package descriptions?

[Manoj Srivastava]

On Thu, 04 Aug 2005 19:08:22 -0500, John Hasler <[EMAIL PROTECTED]> said: 

> Peter Samuelson writes:
>> There is no need for dumbing down descriptions for things
>> non-technical users aren't going to be selecting anyway.

> One can be a highly technical user of a package without knowing (or
> caring) squat about the language it is implemented in.  Descriptions
> should focus on the domain of application.

Why should we only cater to a subset of selection criteria
 that we deem "proper"? What is wrong with  having clear description
 of the domain of the application _and_  technical factes as well, so
 that we cater to all possible users, not just those who are deemed
 "kosher" by the powers that be?

manoj
 ps: presenting technical facets may well be done by presenting
 debtags information, but, lacking that, the description has been
 traditionally used to do so
-- 
Blessed are the young, for they shall inherit the national
debt. Herbert Hoover
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Usability: Technical details in package descriptions?

[Manoj Srivastava]

On Wed, 03 Aug 2005 09:16:23 +0200, Benjamin Mesing <[EMAIL PROTECTED]> said: 

> Especially details like "written in C++" should be left to the
> debtags system as there is no use for the end user.

I am a potential end user for the vast majority of packages in
 Debian -- as I am for the vast majority of the packages installed on
 my machines. I find lasnguage of implementation a useful selection
 criteria for selecting between completing implementations of similar
 functionality.

I may not fit into your jaundiced view of what an "end user"
 /should/ be -- but that is merely lack of imagination on your part.

I think Debian as a whole should not be discriminating against
 the segment of the user base that does tend to be somewhat technical
 -- I suspect there are a large number of us out there.

manoj
-- 
Nudists are people who wear one-button suits.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Usability: Technical details in package descriptions?

[Manoj Srivastava]

On Tue, 02 Aug 2005 22:51:11 -0700, Dustin Harriman
<[EMAIL PROTECTED]> said:  

> Wouldn't it make sense that debtags and Package Descriptions not do
> redundant work of each other?

But Debtags information is not yet integrated into the
 package selection front-ends, like the description is. I use aptitude,
 and every packages description is shown to me when I browse the new or
 un-installed package lists; the debtags information is not present.

> I propose that by a simple split in the use of the Package
> Description and debtags between the "internal world" (ie. relative
> to the computer) and "external world" (ie. relative to the end
> user's real life apart from their computer), respectively, I think
> we can make the best use of volunteer effort as they review the
> Package Descriptions and create debtags.

Firstly, this is an artificial distinction; my selection
 criteria for installing new packages does take into consideration the
 so called technical facets of the package.

> I think that the Package Description should be (re)written using
> language intended at your grandma.  This way she can intuitively
> find packages also without needing to learn about the debtags
> system.  Learning how to use the search button in Synaptic is work
> enough for her, let alone learn and play with debtags to do wild and
> crazy searching (with logical operators no less).

I strongly oppose such discrimination against techinically
 competent people. We should not not make package selection harder for
 a group of people we do not consider the "desired" target audience by
 removing information they use in there selection criteria.

I am all for clarified descriptions that make package
 selection easier for every user; but deliubrately removing
 information, based on the arrogant view point that our users are too
 dumb to understand, or presuming to decide that their selection
 criteria could not possibly be the same as us elite developers, is
 both silly and counter productive.

Integrating debtags into package selection and browsing
 front-ends may mitigate the need for duplicating the information, but
 we are not there yet.

manoj
-- 
Most people's favorite way to end a game is by winning.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Bug#321054: ITP: mls -- Mls is a linux clone of Mdir.

[Paul Brossier]

On Fri, Aug 05, 2005 at 10:38:50PM +1000, Russell Coker wrote:
> On Wednesday 03 August 2005 16:02, Ki-Heon Kim <[EMAIL PROTECTED]> wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: "Ki-Heon Kim" <[EMAIL PROTECTED]>
> 
> MLS also stands for "Multi Level Security".  It would probably avoid 
> confusion 
> if the package was named "mdir".

or whatever mls stands for in this case, like multi-level-shell or
something (i couldn't figure that out from the website).

cheers, piem


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

Re: Bruce Perens hosts party at OSCON Wednesday night

[Brendan]

On Friday 05 August 2005 08:35 am, Russell Coker wrote:
> On Friday 05 August 2005 11:14, Miles Bader <[EMAIL PROTECTED]> wrote:
> > > Because the intent is obviously to forbid any sort of spam.
> >
> > "Spam", as I understand it, generally means UBE.  Bruce's message
> > clearly wasn't spam.
>
> The traditional definition of spam is UBE or UCE (that's the way it's been
> for over 10 years).  UCE is the most commonly used definition currently,
> many newbies who have only used the net for 5 years or less think that spam
> is only UCE, so the UCE category of spam is more commonly applied than the
> UBE category.

Ok, everyone has had a chance to show how large their schlongs are. Can we 
just let this thread die and let Bruce buy dinner for some people who need 
jobs? I pray that there are no ACTUAL problems in the future. With all the 
energy put into these discussions of something that's already happened, you'd 
think you could go put some effort into some code somewhere...


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

Re: Usability: Technical details in package descriptions?

[John Hasler]

Peter Samuelson writes:
> I meant legible and searchable to ignorant people. 

Everyone is ignorant in some areas.  Many intelligent and highly skilled
people know little about programming.

> It should go without saying that all package descriptions should be
> legible and searchable for their respective target audiences.

It _should_...
-- 
John Hasler


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

Re: RFC: allow new upstream into stable when it's the only way to fix security issues.

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> I am a Debian developer. I am not interested in solutions which are
> developed outside of Debian.

Correct: We still have no solution in Debian, not even a DSA warning the
user.

Gruss
Bernd


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

Re: Bug#321054: ITP: mls -- Mls is a linux clone of Mdir.

[Russell Coker]

On Wednesday 03 August 2005 16:02, Ki-Heon Kim <[EMAIL PROTECTED]> wrote:
> Package: wnpp
> Severity: wishlist
> Owner: "Ki-Heon Kim" <[EMAIL PROTECTED]>

MLS also stands for "Multi Level Security".  It would probably avoid confusion 
if the package was named "mdir".

NB  We will have MLS in Debian in the next release.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: Bruce Perens hosts party at OSCON Wednesday night

[Russell Coker]

On Friday 05 August 2005 11:14, Miles Bader <[EMAIL PROTECTED]> wrote:
> > Because the intent is obviously to forbid any sort of spam.
>
> "Spam", as I understand it, generally means UBE.  Bruce's message
> clearly wasn't spam.

The traditional definition of spam is UBE or UCE (that's the way it's been for 
over 10 years).  UCE is the most commonly used definition currently, many 
newbies who have only used the net for 5 years or less think that spam is 
only UCE, so the UCE category of spam is more commonly applied than the UBE 
category.

> Non-UBE "commercial" email doesn't seem to be a problem on this list, so

It is a big problem.  The entire point of spamming a mailing list is that a 
single message can go to thousands or tens of thousands of people.  That 
removes the technical issues related to UBE and makes spamming easier.


We still need better anti-spam measures on the mailing lists and other Debian 
servers.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: Usability: Technical details in package descriptions?

[Peter Samuelson]

[John Hasler]
> > So I'd suggest concentrating on the 3% of packages non-technical users
> > might actually want to select manually, and making sure those have
> > legible and searchable descriptions.
> 
> Technical users don't deserve legible and searchable descriptions?

I meant legible and searchable to ignorant people.  It should go
without saying that all package descriptions should be legible and
searchable for their respective target audiences.  That's not at all
the same thing as what this subthread seems to be suggesting.


signature.asc
Description: Digital signature

Re: valknut and libdc0 - gcc 4.0 transition

[Ondrej Sury]

On Fri, 2005-08-05 at 12:46 +0200, Ondrej Sury wrote:
> Hi,
> 
> I was just looking at valknut and libdc0 packages which didn't undergo
> gcc 4.x ABI transition and how one question:
> 
> If valknut is only package which is using C++ libdc0 package, is there
> real technical reason to rename libdc0 to libdc0c2 instead of just
> adding:
> 
> Conflicts: valknut (<< gcc-4.x.version), dcgui-qt (<< gcc-4.0version)
> 
> to libdc0

Err, maybe shlibs update is more appropriate :-)

> and
> 
> Depends: libdc0 (>= gcc-4.x.version)
> 
> ?
> 
> I am pretty sure, that there is no other (even proprietary) package
> which uses libdc0.

-- 
Ondrej Sury <[EMAIL PROTECTED]>


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

Re: RFC: allow new upstream into stable when it's the only way to fix security issues.

[Marco d'Itri]

On Aug 05, Marc Haber <[EMAIL PROTECTED]> wrote:

> It will keep them from using a vulnerable version of the software, and
> will probably encourage them to get a fixed version from outside
> Debian proper (e.g. volatile).
I am a Debian developer. I am not interested in solutions which are
developed outside of Debian.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

valknut and libdc0 - gcc 4.0 transition

[Ondrej Sury]

Hi,

I was just looking at valknut and libdc0 packages which didn't undergo
gcc 4.x ABI transition and how one question:

If valknut is only package which is using C++ libdc0 package, is there
real technical reason to rename libdc0 to libdc0c2 instead of just
adding:

Conflicts: valknut (<< gcc-4.x.version), dcgui-qt (<< gcc-4.0version)

to libdc0

and

Depends: libdc0 (>= gcc-4.x.version)

?

I am pretty sure, that there is no other (even proprietary) package
which uses libdc0.

Ondrej.
-- 
Ondrej Sury <[EMAIL PROTECTED]>


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

Re: OT: Bruce Perens spamming -devel?

[Kari Laine]

Brian Nelson wrote:


Anders Breindahl <[EMAIL PROTECTED]> writes:

 


On Wednesday 03 August 2005 02:16, Steve
Langasek wrote:
   


On Tue, Aug 02, 2005 at 06:32:44PM -0500, Adam Heath wrote:
 


Unsolicited Commercial Email.  Please pay the standard $2000 fee for
advertisments on Debian mailing lists.
   


Y'know, it's fine if you think that Bruce's mail was inappropriate for
 


the list, and there's nothing wrong with saying so; but claiming that a
message that isn't selling anything is UCE, and attempting to enforce
   


against
 


a member of the community an advertising policy that daily goes
unenforced against thousands of more deserving souls, just makes you
   


sound like
 


an asshole and an idiot.

How does an asshole sound, anyway?
   



It sounds like, "Pffftthhhbbb", "Grrrhhhfff", or sometimes even,
"Fwp!"

 

Give  the nice guy little slack! I mean Bruce has done a LOT for Linux  
and Open Source. He was Debian leader few years back and worked hard for 
the project. So why to nickpick him? There seems to be severall type of 
Linux people. Ones who  do  something and ones who seems to get 
satisfaction to harrass the first group for little misteps, which are 
unavoidable  when one really do something. Grow up.


I won't post again for this list because it is not right plase  to 
discuss this. Just my 2 cents. And I sure someone  will point out that 
my english suck :-)


Best Regards
Kari Laine



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

Re: Suscripciones en lists.debian.org

[Santiago Vila]

On Fri, 5 Aug 2005, Ismael Valladolid Torres wrote:

> ¿Hay alguna forma conocida de saber a cuántas listas en lists.debian.org
> está suscrita una dirección de correo dada y cuáles son esas listas?
>
> Google no me ha servido de ayuda. Cualquier idea me resultará muy útil.

[ Please note that this is the wrong list to ask for such questions ]

Try [EMAIL PROTECTED] Behind such address there is
(well, there should be) a majordomo emulator called "majorsmart".

Suscripciones en lists.debian.org

[Ismael Valladolid Torres]

¿Hay alguna forma conocida de saber a cuántas listas en lists.debian.org 
está suscrita una dirección de correo dada y cuáles son esas listas?


Google no me ha servido de ayuda. Cualquier idea me resultará muy útil.

Un saludo, Ismael


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

Re: Bug#145878: ITP: ctn -- Central Test Node package (A DICOM implemention) for medical image handling

[Karsai Gyozo]

Helo,
 
excuse me for confusion. I'm fom Hungary, Middel-Europe. I wrote a PACS server and now I like to 
test for DICOM compliance. I seem on Internet that any address of  
DICOM Test Server. But I can't to connect to theyt
Can cou help me in this problem? That is can you 
write to me any live address of DICOM Test Server.
 
best regard of
 
Gyozo Karsai
[EMAIL PROTECTED]

Re: RFC: allow new upstream into stable when it's the only way to fix security issues.

[Alexander Sack]

On Fri, Aug 05, 2005 at 08:22:43AM +0200, Marc Haber wrote:
> On Mon, 1 Aug 2005 11:37:11 +0200, [EMAIL PROTECTED] (Marco d'Itri) wrote:
> >On Aug 01, "W. Borgert" <[EMAIL PROTECTED]> wrote:
> >> On Sun, Jul 31, 2005 at 10:07:10PM +, Roland Rosenfeld wrote:
> >> > But how do you push the users to remove the package from their
> >> > systems?  In reality they will keep the broken version installed and
> >> > so you have (1) again :-(
> >> Empty package with a higher version number?
> >And exactly, how this would help our users?
> 
> It will keep them from using a vulnerable version of the software, and
> will probably encourage them to get a fixed version from outside
> Debian proper (e.g. volatile).
> 

If there is really no chance to get something new in (or remove them), I
would suggest that those packages affected should be allowed to push a
minimal patched package to the security archive that tries to warn the users
about the potential security problems in the package and how to obtain a new
one (e.g. on the default startpage).

-- 
 GPG messages preferred.   |  .''`.  ** Debian GNU/Linux **
 Alexander Sack| : :' :  The  universal
 [EMAIL PROTECTED]   | `. `'  Operating System
 http://www.asoftsite.org  |   `-http://www.debian.org


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