Re: migrating wiki content from twiki (w.d.net) to moinmoin (w.d.org)

[Andreas Fester]

I thought that the wiki was to be moved to mediawiki?

http://wiki.debian.net/?HelpMoveDebianWikiToMediaWiki

Will w.d.org be a replacement for w.d.net? With the latter
leading to the same page once the migration is done?

Best Regards,

Andreas

Andreas Schuldei wrote:

The wiki markup languages of twiki and moin-moin are not
compatible. Still it would be nice to have some content moved
from the old .net wiki to the new .org one. (the debconf team for
one is interested in using the features of moin-moin for easier
cooperation and to keep the existing pages.)

[...]

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


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

Re: Do we still need libc5?

[Bastian Blank]

On Sat, Sep 03, 2005 at 04:33:13AM +0200, Jeroen van Wolffelaar wrote:
> Debian unstable & testing still carry around libc5, and some associated
> packages like altgcc, libdb1, ld.so and a few others.

Hmm, i386 only?

Bastian

-- 
No one may kill a man.  Not for any purpose.  It cannot be condoned.
-- Kirk, "Spock's Brain", stardate 5431.6


signature.asc
Description: Digital signature

Re: migrating wiki content from twiki (w.d.net) to moinmoin (w.d.org)

[Joerg Jaspert]

On 10401 March 1977, Andreas Fester wrote:

> Will w.d.org be a replacement for w.d.net?

Thats the intention of it.

> With the latter leading to the same page once the migration is done?

That depends on the one who has it right now, but would be the best, yes.

-- 
bye Joerg
 [Clint]: I'm convinced zsh users could deal with a keyboard that has 
5 random letters, tab and enter.
 3 random letters :)
 you need anything but tab and perhaps space?
 yes, enter - sometimes you want the completed thing to happen


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

Re: Do we still need libc5?

[Mark Brown]

On Sat, Sep 03, 2005 at 10:52:34AM +0200, Bastian Blank wrote:
> On Sat, Sep 03, 2005 at 04:33:13AM +0200, Jeroen van Wolffelaar wrote:

> > Debian unstable & testing still carry around libc5, and some associated
> > packages like altgcc, libdb1, ld.so and a few others.

> Hmm, i386 only?

Yes, the versions for other arches have gradually been removed due to
lack of interest in maintaining them.  One of the major reasons for
keeping libc5 around has been old commercial software and there wasn't
much of that for other arches.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


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

Re: migrating wiki content from twiki (w.d.net) to moinmoin (w.d.org)

[Javier Fernández-Sanguino Peña]

On Sat, Sep 03, 2005 at 01:34:29AM +0200, Andreas Schuldei wrote:
> I did not find migration scripts between the two wikis.  Do they
> exist?  Is someone who is familiar with both wikis interested in
> writing one?

Based on the text on the w.d.o frontpage it seems that Michael Ivey
has provided the tar.gz with all the w.d.n contents.

Javier


signature.asc
Description: Digital signature

Re: migrating wiki content from twiki (w.d.net) to moinmoin (w.d.org)

[martin f krafft]

also sprach Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> [2005.09.03.1308 
+0200]:
> Based on the text on the w.d.o frontpage it seems that Michael
> Ivey has provided the tar.gz with all the w.d.n contents.

... at which point it would make sense to discourage any further
edits to the old wiki. In any case, the tarball can be used to
create a migration path, but for the final migration, it should
probably be refetched and the old wiki subsequently closed and the
DNS name redirected to the new one.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
"arthur slapped his arms about himself to try and get his
 circulation a little more enthusiastic about its job."
 -- hitchhiker's guide to the galaxy


signature.asc
Description: Digital signature (GPG/PGP)

Re: libcurl and moc

[Steve Langasek]

On Sat, Sep 03, 2005 at 08:16:48AM +1000, Paul TBBle Hampson wrote:
> As far as packaging goes, this means you get the following packages:

> libcurl3, providing libcurl3-openssl (linked against OpenSSL to avoid breaking
>   sarge packages that use this functionality)
> libcurl3-gnutls (linked against gnuTLS, doesn't support SSL_CTX_FUNCTION)
> libcurl3-dev (Do we need a second -dev? Static linking maybe requires it? If
>   this becomes a testable feature, then a second -dev is definately 
> needed.)

> Packages which don't use SSL_CTX_FUNCTION can Depend on either libcurl3 |
> libcurl3-gnutls, or if they're GPL'd can depend on libcurl3-gnutls only.

> Packages which need SSL_CTX_FUNCTION can depend on libcurl3-openssl

> grepping the source of libcurl3's direct rdepends should tell you which
> packages in Debian need SSL_CTX_FUNCTION.

> GPL'd packages which need SSL_CTX_FUNCTION are out of luck. And have always
> been so.

> Before etch ships, no package should depend on libcurl3, they should depend on
> libcurl3-openssl or libcurl3 | libcurl3-gnutls or libcurl3-gnutls.

> After etch ships, upload:
> libcurl3, providing libcurl3-gnutls (linked against gnuTLS)
> libcurl3-openssl, providing libcurl3 (linked against openSSL)
> libcurl3-dev

> At this point, packages who don't like having libcurl3-gnutls is their
> Depends line can do a versioned depends on libcurl3, which won't match
> the libcurl3 virtual dependancy provide by libcurl3-openssl, and will
> also prevent them accidentally linking against an openSSL version of
> libcurl3. (At least, I _think_ that's how versioned dependancies on
> virtual packages work. Possibly they'll _always_ match, in which case a
> Conflicts is in order instead.)

Do libcurl3 and libcurl3-gnutls provide different sonames to allow
co-installability of the packages, or does libcurl3 use diversions to
override the libcurl.so.3 that lacks SSL_CTX_FUNCTION support (if any)
when installing?  (We know that directly conflicting between the two
packages is not really an option, unless we're doing this like the C++
ABI transition and we either don't believe there are any packages in
Debian which will need to retain SSL_CTX_FUNCTION support or we assume
they're packages that we don't care about co-installability of -- which
seems far-fetched to me.)

The latter may require excessive amounts of license patrolling, because
one could have a package which depends on libcurl3-gnutls but also has
dependencies which force libcurl3 to be pulled in.

The former would make it rather impractical to migrate the libcurl3
association from -openssl to -gnutls in etch+1.

> The _problem_ with this setup is you can't parallel-install a GPL'd
> libcurl3-using application and an application that uses SSL_CTX_FUNCTION
> (as libcurl3 and libcurl3-gnutls must conflict as they provide shared libs
> with the same soname/sover. As you'd expect as they're ABI-compatible,
> albeit functionaly different.) The impact of this should be taken into
> account, and balanced against the fact that right now, we can't have
> a GPL'd libcurl3-using application installed at all. ^_^

Ah, so you were aiming for conflicts between the packages after all...
:/  The worry I have with balancing it against not having GPLed
libcurl3-using applications is that we do currently seem to be doing ok
without libcurl support in those packages right now, but there may be
many packages with optional libcurl support that'll get enabled, leaving
the packages that need the OpenSSL support *virtually* uninstallable.

> There are possibly some optimisations that could be made above with Conflicts.
> Maybe both -openssl and -gnutls should provide libcurl3, all users depend on
> libcurl3, and GPL packages conflict with libcurl3-openssl and SSL_CTX_FUNCTION
> users conflict with libcurl3-gnutls. I'm not sure if this is an improvement...

It isn't; it doesn't ensure a smooth upgrade path for apps in sarge.

It may be worthwhile to simply survey all the curl-using packages in
sarge, though, and find out if there is a non-zero number of them that
need SSL_CTX_FUNCTION.  If *not*, then I don't think there's much sense
in going through a multi-stage transition: just switch libcurl3 directly
to gnutls, and add libcurl3-openssl which provides libcurl-openssl.so.3?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: To Linux or not to Linux

[Yavor Doganov]

On Sat, 03 Sep 2005 08:29:03 +1000, Paul TBBle Hampson wrote:

> Coming directly after "wrong list" possibly helped that, although
> I didn't read it as such.

My mistake, Wouter has explained and I'm more than happy now ;-)

> Of course, now I'm posting... I disagree with Yavor that we should use
> GNU/Linux so that people will go to gnu.org [...]
[...]
> I believe we should use GNU/Linux because we're using GNU libc

That's ok, so even from technical point of view people should call it
GNU/Linux.  I am more concerned about the moral issues, though. 

> So GNU/FreeBSD for the kfreebsd port

Thanks to the people involved in development of this port one day I'll be
able to install on my old Alpha not only a GNU system, but the system I am
familiar with -- Debian.  The Linux kernel will never boot on it as the
kernel team has declared several times that people having TurboChannel Bus
Alphas are not important (which is in fact, true).

> The name of the distribution should reflect the contents of that
> distribution, rather than the politics it may or may not endorse.

I agree, it is a GNU system, hence the name -- GNU/Linux (with a piece of
deserved credit to Linus).  Calling it only "Debian" is fine as well.

-- 
Yavor Doganov   JID: [EMAIL PROTECTED]
Free Software Association - Bulgaria   http://fsa-bg.org
GNOME in Bulgarian! http://gnome.cult.bg


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

Re: migrating wiki content from twiki (w.d.net) to moinmoin (w.d.org)

[Jeroen van Wolffelaar]

On Sat, Sep 03, 2005 at 01:08:00PM +0200, Javier Fernández-Sanguino Peña wrote:
> On Sat, Sep 03, 2005 at 01:34:29AM +0200, Andreas Schuldei wrote:
> > I did not find migration scripts between the two wikis.  Do they
> > exist?  Is someone who is familiar with both wikis interested in
> > writing one?
> 
> Based on the text on the w.d.o frontpage it seems that Michael Ivey
> has provided the tar.gz with all the w.d.n contents.

Which 404's at the moment. But anyway, what's needed is someone who uses some
perl (or whatever) magic on that tarball, to get moin-compatible data/pages
files that can be unpacked in the wiki.debian.org installation by a DSA
member. I wonder whether with moin moin, there needs to happen anything else
too, for example (index files rebuild or something?). Unfortunately I'm
familiar with kwiki nor moin moin.

And someone needs to come up with a way to deal with conflicts, though the
best way would be to simply prevent them from happening -- i.e., do not create
pages that already exist on wiki.debian.net.

Note: I wasn't and still am not involved in any way with wiki.debian.org/
wiki.debian.net, but I simply would really like to see this transition happen
smoothly, because the longer it takes, the harder it will get.

--Jeroen

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


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

Re: migrating wiki content from twiki (w.d.net) to moinmoin (w.d.org)

[Bastian Blank]

On Sat, Sep 03, 2005 at 02:10:57PM +0200, Jeroen van Wolffelaar wrote:
> I wonder whether with moin moin, there needs to happen anything else
> too, for example (index files rebuild or something?).

No, there are only cache files which are rebuilt if needed.

Bastian

-- 
Conquest is easy. Control is not.
-- Kirk, "Mirror, Mirror", stardate unknown


signature.asc
Description: Digital signature

Re: migrating wiki content from twiki (w.d.net) to moinmoin (w.d.org)

[martin f krafft]

also sprach Jeroen van Wolffelaar <[EMAIL PROTECTED]> [2005.09.03.1410 +0200]:
> member. I wonder whether with moin moin, there needs to happen anything else
> too, for example (index files rebuild or something?). Unfortunately I'm

From my experience, there are no indices.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
"alle vorurteile kommen aus den eingeweiden."
 - friedrich nietzsche


signature.asc
Description: Digital signature (GPG/PGP)

Re: migrating wiki content from twiki (w.d.net) to moinmoin (w.d.org)

[Michael D. Ivey]

On Sep 3, 2005, at 6:13 AM, martin f krafft wrote:


at which point it would make sense to discourage any further
edits to the old wiki


I have made it read-only, and am happy to use mod_rewrite to send  
wiki.d.n requests to wiki.d.o ... or to change the CNAME to point  
directly to wiki.d.o, as soon as the content has been migrated.


PGP.sig
Description: This is a digitally signed message part

Re: making developer location from ldap public?

[Bruno Barrera C.]

On Fri, 2005-08-26 at 14:34 +0200, W. Borgert wrote:
> And I wouldn't want that.
> 
> I do not understand this discussion.  Why on earth is someone
> so interested in the public availability of DDs location?  This
> would only make sense when cross-connecting with other things,
> like belief, gender, sexual preferences and phantasies etc.
> Are those fields of db.debian.org already public or not?

While I don't agree to publish the coordinates and all that stuff of the
Debian Developers, I think if you want to know (non-DDs) the information
about some DD searching using their login name for example, it would not
hurt anyone to know the Country where he lives. Otherwise he will become
crazy searching in all the countries to find him.

Then, he can think "Oh well, he is from $country. I will drop him an
email to see if we can meet us".
-- 
Bruno Barrera C.
"The most dangerous moment comes with victory."


signature.asc
Description: This is a digitally signed message part

Need help with SDL 1.2.9 packages

[Lawrence Williams]

Hi everyone,

I am working on packages for SDL 1.2.9, as I would like to get the buggy, 
unstable version out of testing/unstable. I previously packaged SDL since 
1.2.7, with Matthew Danish sponsoring the uploads. However, we have been both 
busy recently and haven't had adequate time to address the issues in SDL 
packaging.

Now while I do have free time, Mr. Danish is still busy. I would like to not 
further burdening him with SDL work, so I would like if some DD's would be 
willing to test my packages when they're finished and/or (hopefully) upload 
them :)

I have sent this to -devel and -mentors to get the widest possible audience.

Any help would be greatly appreciated!

Lawrence


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

Reciprocal Link Request

[Checks HQ]

Hi

I checked your site out, thought it was great and would love
to trade links you!

You've got some great content related to the checks
resource I've just created.

In fact, I liked your site so much, I went ahead and added
you here:

http://www.checks-hq.com under http://www.checks-hq.com/checkpending


I hope you'll be pleased to have the link to your site -
i'm sure you know how essential links are for both direct
traffic and better search engine ranking.

I'd be very grateful if you would return the favor and link
back to me. Perhaps we even look at doing more cross
linking/promotion in the future and help each other out even
more.

Although the site has only just been completed, we are
aggressively building links and expect our page rank to rise
dramatically.

Thanks... and do drop me an email if you'd like to chat more
about this.

Best regards,

Steve

[EMAIL PROTECTED]

PS. I've created a list of all the sites I've visited but
if you have received this email in error then please let me
know and I will remove you from my list and apologies for
any inconvenience this has caused.//

Re: Bug#318590: Bug#325643: libcurl and moc

[Domenico Andreoli]

On Fri, Sep 02, 2005 at 04:04:27AM -0700, Steve Langasek wrote:
> On Fri, Sep 02, 2005 at 12:24:18PM +0200, Domenico Andreoli wrote:
> > > >  - libcurl3  (GnuTLS, soname: libcurl.so.3)
> 
> > >   So the libcurl3 in sarge and etch will have ABI incompatibilities?
> 
> > at the release time of etch this problem will regard only
> > external software. this kind of installations will be able to use
> > libcurl3-openssl-dev package or switch to GnuTLS.
> 
> > is this reasonable enough?
> 
> No, definitely not.  You cannot change the ABI of an existing library
> package, especially not one that's been in a stable release; you need
> to rename it instead.

so we need both libcurl3-openssl and libcurl3-gnutls until libcurl4? i
am not seeing this as a problem.

dom

-[ 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]

Re: migrating wiki content from twiki (w.d.net) to moinmoin (w.d.org)

[martin f krafft]

also sprach Michael D. Ivey <[EMAIL PROTECTED]> [2005.09.03.1550 +0200]:
> I have made it read-only, and am happy to use mod_rewrite to send

This is a good idea, but only if the migration can be completed
soon. Otherwise I suggest making it writable again until a migration
path exists, and then to take another snapshot after turning it
read-only again.

> wiki.d.n requests to wiki.d.o ... or to change the CNAME to point
> directly to wiki.d.o, as soon as the content has been migrated.

Superb.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
apt-get source --compile gentoo


signature.asc
Description: Digital signature (GPG/PGP)

Re: Do we still need libc5?

[Florian Weimer]

* Jeroen van Wolffelaar:

> Fact is though that libc6 has been in Debian stable for over 7
> years, since hamm was releaed mid-1998,

This suggests that we should give it three more years or something
like that.

However, if the packages aren't covered by security support anyway, it
probably doesn't make a difference to our users if we stop shipping
them.

> and I think Debian is like the only living Linux distribution out
> there still shipping libc5.

Are you sure?  I would be very surprised if the "enterprise"
distributions didn't ship it as well.


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

Re: Spam on the BTS

[Florian Weimer]

* Blars Blarson:

> Would it be acceptable to reject or drop more non-spam?  (We could
> reject on CBL, getting rid of about half the spam and rejecting about
> one non-spam per day.  CBL is easy to get off of.) 

CBL has the advantage that you can make a local copy of the list
(which reduces name server load and avoids the name lookup latency),
but its license is somewhat non-free.  Is this a problem for Debian?

What's causing most of the load right now?  I think some of the effort
should probably concentrate on getting legitimate mail through faster.


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

Re: Bug#326404: hdf5-tools: missing h4toh5 and h5toh4 programs

[Josselin Mouette]

Le samedi 03 septembre 2005 à 19:47 +0200, Josselin Mouette a écrit :
> * Package name: h4h5tools
>   Version : 1.2
>   Upstream Author : Jay Bonci <[EMAIL PROTECTED]>

Em, no. It is developed by the NCSA and other contributors.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: This is a digitally signed message part

Re: Do we still need libc5?

[Roger Leigh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Florian Weimer <[EMAIL PROTECTED]> writes:

> * Jeroen van Wolffelaar:
>
>> Fact is though that libc6 has been in Debian stable for over 7
>> years, since hamm was releaed mid-1998,
>
> This suggests that we should give it three more years or something
> like that.

I don't agree.  We have supported it for quite a long time already,
longer than any other distribution, and it hasn't built with a
contemporary toolchain for years.  Who knows what sort of state it's
really in?  Is it even properly compatible with current (> 2.0.x)
kernels, or are there subtle incompatibilities there? (IIRC, there
were some [mmap-related??] last time this was brought up.)

I appreciate that some folks do want to run obsolete proprietary code,
but if they are in that sort of situation, do they really need a
current distribution, or should a suitably-firewalled old system be
sufficient?  Being tied to the past is just one of the prices you pay
when you use proprietary software...

> However, if the packages aren't covered by security support anyway, it
> probably doesn't make a difference to our users if we stop shipping
> them.

We can't provide proper security support, and by now, libc5 is likely
full of holes, so IMO it's best if we drop it.  It's not like there's
any active maintenance or we can do any serious work on it: it's dead
code.

If users need it, they can always grab a sarge (or older) CD and
install from that.  At least then the user is using them at their own
risk--we are not making any claim that it is supported, and since it's
been unsupported for a good 7 years anyway, that's probably for the
best, since we really can't support it as it stands.

>> and I think Debian is like the only living Linux distribution out
>> there still shipping libc5.
>
> Are you sure?  I would be very surprised if the "enterprise"
> distributions didn't ship it as well.

ftp://ftp.redhat.com/pub/contrib/libc5/i386/
libc5 hasn't been updated since 1998, and dependent packages mostly
not since 97-98, with some in 99 and 2 in 00.

ftp://ftp.redhat.com/pub/redhat/linux/enterprise/4/en/os/i386/SRPMS/
No trace.

ftp://ftp.suse.com/pub/suse/i386/current/suse/i586/
No trace.

- From what I can see, we are the sole distributors of libc5, and IMO
dropping it (and its toolchain) would be a wise move.


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.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iD8DBQFDGe42VcFcaSW/uEgRAjDuAJ9tjWKw7CXReyV0Sw29tffaeENu5wCgnKcn
564tv8xXmMky5hH0MiikeP4=
=baLM
-END PGP SIGNATURE-


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

Re: Debian package and OpenSSL stuff

[Josselin Mouette]

Le vendredi 02 septembre 2005 à 13:45 -0400, Roberto C. Sanchez a
écrit :
> On Fri, Sep 02, 2005 at 07:07:02PM +0200, Jean-Philippe Garcia Ballester 
> wrote:
> >   Hi,
> >   I heard OpenSSL's license is incompatible with GPL. Does this apply to
> > binary package only or both binary and source package?
> >   The thing is, the library I'm packaging can use both libcrypto (from
> > OpenSSL) and libgcrypt, using ifdef. The binary package is built with
> > libgcrypt support only.
> >   Should I remove OpenSSL support in the source, or is it okay to leave
> > it?
> 
> free, I simply ignore it.  I believe that the same would apply to your
> package.  If you are only linking to ligcrypt (regardless of the code's
> ability to link to alternate implementations), it is main and so you are
> OK.

True. You can even have OpenSSL support in the binary if, for example,
the application can use either libgcrypt or libcrypto depending on a
command-line switch, dlopen()ing either of the libraries. This way, it
wouldn't really require OpenSSL to run.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: This is a digitally signed message part

Re: Bug#326404: hdf5-tools: missing h4toh5 and h5toh4 programs

[Josselin Mouette]

reassign 326404 wnpp
severity 326404 wishlist
retitle 326404 RFP: h4h5tools -- Conversion tools between HDF4 and HDF5 formats
thanks

Le samedi 03 septembre 2005 à 12:46 -0400, [EMAIL PROTECTED] a
écrit :
> > I've just uploaded h5utils 1.10, which now contains h4fromh5 and
> > h5fromh4. Is this enough for you? I don't really want to end up with
> > another HDF5-related package to maintain...
> 
> The h5utils programs are sufficient for my immediate needs, but they
> shouldn't be considered a complete replacement for NCSA's programs.  The
> h5utils programs only convert a single scientific dataset in a file,
> whereas the NCSA utilities attempt to convert all information in the file
> (groups, annotations, etcetera).
> 
> Perhaps this bug should be converted into an RFP?

Yes, I think so. Here it is.

* Package name: h4h5tools
  Version : 1.2
  Upstream Author : Jay Bonci <[EMAIL PROTECTED]>
* URL : http://hdf.ncsa.uiuc.edu/h4toh5/
* License : similar to the old 4-clause BSD
  Description : Conversion tools between HDF4 and HDF5 formats

HDF (hierarchical data format) is a file format for scientific data.
Version 5 is believed to be a much superior format, however it is
incompatible with the old tools. This package provides complete and
accurate conversion tools between the two formats. The h5utils package
already contains some conversion tools, but they are much less complete.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: This is a digitally signed message part

It is 23:53, do you know whether your package (un)installs cleanly?

[Lars Wirzenius]

I wrote piuparts, a package installation, upgrading, and removal
testing tool, in June, and have been running it over etch since.
Most packages succeed, and many that fail do so because something
they depend on fails. (If piuparts notices a file left behind on the
filesystem that dpkg did not know about, it cannot know which
package was the cause. Or at least I've been too lazy to implement
such logic.)

My approach has been to analyze failures, figure out what the root
cause is, report a bug, and then add suitable --ignore or
--ignore-regex options to simulate a fix.

I still have about a thousand failed logs to process, and this is
going to take a while. There are, however, some patterns emerging
and I thought it might be useful to report on them now rather than
at some distant future date when I can run piuparts on the entire
etch without unignored errors.

* Unconditional use of non-essential packages in postrm when a
  package is purged (policy, 7.2, description of Depends). One
  of the most common reasons is because the package uses ucf.

* Files created in postinst, but not removed when package is
  purged. For example, log files (policy, 10.8), or
  configuration files made from a template of some sort.

* Temporary files created, but not removed by maintainer
  scripts.

* Complicated alternatives setups, where some are not un-done
  when package is removed.

* Running programs in postinst that automatically create a dot
  file in the user's home directory. This puts files into
  /root, which is potentially troublesome in other ways than
  just leaving cruft on the filesystem.

* Various scripting errors, such as using "set -e" and then
  "foo && bar" instead of "if foo; then bar; fi".

* Some packages still don't use debconf for prompting, and
  instead do silly stuff that assumed it is OK to read and
  write /dev/tty.

Most of the errors I find are pretty trivial, just minor oversights,
and mostly harmless cruft. Happily, this also means they are easy to
fix.

Reading piuparts logs en masse is tedious and I would be extremely
happy if all developers did it for their own packages. Go ahead,
please prevent me from becoming a top ten bug reporter. :)


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

Re: It is 23:53, do you know whether your package (un)installs cleanly?

[Andrew Suffield]

On Sat, Sep 03, 2005 at 11:53:35PM +0300, Lars Wirzenius wrote:
> * Unconditional use of non-essential packages in postrm when a
>   package is purged (policy, 7.2, description of Depends). One
>   of the most common reasons is because the package uses ucf.

Which is because the example postrm given in ucf is wrong, so if
you're using ucf, beware. See #326085

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


signature.asc
Description: Digital signature

Re: mesag3 <-> xlibmesa-gl / libgl1-mesa-dri <-> xlibmesa-dri / libglu1-mesa <-> libglu1-xorg

[Michel Dänzer]

On Wed, 2005-08-31 at 21:55 -0600, Marcelo E. Magallon wrote:
> On Wed, Aug 31, 2005 at 10:35:55PM -0400, Michel Dänzer wrote:
> 
>  > >  2) Someone with the proper hardware should test the several
>  > > (there's at least 8 of them IIRC) drivers that ship inside the
>  > > -dri package with the current (6.8) and future (6.9, 7.0) x.org
>  > > server.
>  > 
>  > I'll gladly test the r200 driver once it's built on powerpc and the
>  > libgl1 issue mentioned above is solved.
> 
>  Can you just try the drivers?  I mean "dpkg -x" or something like that.

I tried building from SVN:

[...]
mkdir -p debian/stamp/ && touch debian/stamp/target-gl-debian-debug
dh_testdir
chmod +x debian/shadowtree
rm -f -rf build/gl-debian-debug-i386
debian/shadowtree build/gl-debian-debug-i386
ln -sf debian-debug-i386 build/gl-debian-debug-i386/configs/current
if test gl != gl ; then mkdir -p build/gl-debian-debug-i386/lib/ ; ln
-sf ../../gl-debian-debug-i386/lib/libGL.so
build/gl-debian-debug-i386/lib/ ; fi
make -C build/gl-debian-debug-i386/src SRC_DIRS=mesa
make[1]: Entering directory
`/home/michdaen/debian/mesa-svn/trunk/build/gl-debian-debug-i386/src'
Making sources for debian-debug-i386
mkdir ../lib
make[2]: Entering directory
`/home/michdaen/debian/mesa-svn/trunk/build/gl-debian-debug-i386/src/mesa'
make[3]: Entering directory
`/home/michdaen/debian/mesa-svn/trunk/build/gl-debian-debug-i386/src/mesa'
make[4]: Entering directory
`/home/michdaen/debian/mesa-svn/trunk/build/gl-debian-debug-i386/src/mesa/x86'
cc -I../../../include/GL -I../../../include -I.. -I../main -I../math
-I../glapi -I../tnl -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L
-D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DUSE_XSHM -DPTHREADS
-I/usr/X11R6/include -DDEBUG -DMESA_DEBUG -ansi -pedantic -Wall -fPIC
-std=c99 -mcpu=i686 -msse -mfpmath=sse -DUSE_X86_ASM -DUSE_MMX_ASM
-DUSE_3DNOW_ASM -DUSE_SSE_ASM gen_matypes.c -o gen_matypes
cc1: error: invalid option ‘sse’
cc1: error: invalid option ‘fpmath=sse’
gen_matypes.c:1: error: bad value (i686) for -mcpu= switch
[...]

(Keep in mind this is on powerpc)

I took a look at debian/rules, but it isn't obvious to me what the best
way to fix this is.

>  I just need to know if they work fine with the current X server in
>  unstable or if I need to wait for the 6.9 X server.

FWIW, we generally try to preserve backwards compatibility, so they
*should* work with the X server in sid. The r200 driver from Mesa CVS
certainly works here, although I'm not using the DDX driver from
xserver-xorg either. :)


>  SVN is svn://svn.debian.org/svn/pkg-mesa/mesa/trunk and patches are
>  most welcomed (BTS is easier, but my @d.o address should be fine).

The attached patch adds the IMO appropriate Conflicts:, Replaces: and
Provides: for libgl1-mesa-dri{,-dev}.


>  And since I've got your attention Michel, if you figure there's an
>  optimization for PowerPC that actually has some visible impact, I'll be
>  glad to include that, too.  Please read debian/README.build.

Thanks for the pointer, but unfortunately, I can't think of anything
offhand.

>  I really wish I had a PowerPC where I could port the optimized T&L
>  functions, PowerPC asm is *really* nice :-)

Yeah, that'd be very cool. :)


>  And co-maintaining is always welcomed.

Okay, do you intend to use the pkg-mesa-devel list?


-- 
Earthling Michel Dänzer  | Debian (powerpc), X and DRI developer
Libre software enthusiast|   http://svcs.affero.net/rm.php?r=daenzer
Index: debian/control
===
--- debian/control	(revision 26)
+++ debian/control	(working copy)
@@ -52,6 +52,9 @@
 Section: libs
 Architecture: any
 Depends: ${shlibs:Depends}, libglu1-mesa | libglu1
+Conflicts: libgl1
+Replaces: libgl1
+Provides: libgl1
 Description: A free implementation of the OpenGL API -- DRI runtime
  This version of Mesa provides hardware accelerated rendering
  capabilities via the Direct Rendering Interface (DRI) infraestructure.
@@ -62,6 +65,9 @@
 Section: libs
 Architecture: any
 Depends: ${shlibs:Depends}, libc6-dev, mesa-common-dev (= ${Source-Version}), libgl1-mesa-dri (=${Source-Version})
+Conflicts: libgl-dev
+Replaces: libgl-dev
+Provides: libgl-dev
 Description: A free implementation of the OpenGL API -- DRI development support files
  This version of Mesa provides hardware accelerated rendering
  capabilities via the Direct Rendering Interface (DRI) infraestructure.

Re: Do we still need libc5?

[Florian Weimer]

* Roger Leigh:

> We can't provide proper security support, and by now, libc5 is likely
> full of holes, so IMO it's best if we drop it.  It's not like there's
> any active maintenance or we can do any serious work on it: it's dead
> code.
>
> If users need it, they can always grab a sarge (or older) CD and
> install from that.

I agree.  Security support would have made the difference, but the
rest you can get from a CD.


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

Section 6.3 should reference 3.10.1 (was: It is 23:53, do you know whether your package (un)installs cleanly?)

[Marc 'HE' Brockschmidt]

Lars Wirzenius <[EMAIL PROTECTED]> writes:
> * Some packages still don't use debconf for prompting, and
>   instead do silly stuff that assumed it is OK to read and
>   write /dev/tty.

Actually, the policy explicitly allows this:

| The maintainer scripts are guaranteed to run with a controlling terminal
| and can interact with the user. If they need to prompt for passwords, do
| full-screen interaction or something similar you should do these things
| to and from /dev/tty, [...]
[Debian Policy 3.6.2.1, section 6.3]


This should probably changed a bit to reference 3.10.1, which says that
all means to prompt the user besides debconf are deprecated.

I'm not yet sure that this my view is right, so I only CCed -policy (and
have not filed a bug yet).

Marc
-- 
Fachbegriffe der Informatik - Einfach erklärt
255: City
   Die Gegend mit der höchsten Kneipendichte und den wenigsten
   Parkplätzen. (Juergen Nieveler)


pgphWmAanbYWT.pgp
Description: PGP signature

Bug#326526: ITP: php4-clamavlib -- PHP ClamAV Lib - ClamAV Interface

[Jonas Genannt]

Package: wnpp
Severity: wishlist
Owner: Jonas Genannt <[EMAIL PROTECTED]>


* Package name: php4-clamavlib
  Version : 0.11
  Upstream Author : Geffrey Velasquez <[EMAIL PROTECTED]>
* URL : http://phpclamavlib.org
* License : GPL
  Description : PHP ClamAV Lib - ClamAV Interface

PHP ClamAV Lib is a PHP extension that allows to incorporate virus
scanning features on your PHP scripts. It uses the Clam AV API for virus
scanning.
This version are supported two functions for file scanning and buffer
scanning.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-686-smp
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

Re: Bug#318590: Bug#325643: libcurl and moc

[Steve Langasek]

On Sat, Sep 03, 2005 at 04:12:43PM +0200, Domenico Andreoli wrote:
> On Fri, Sep 02, 2005 at 04:04:27AM -0700, Steve Langasek wrote:
> > On Fri, Sep 02, 2005 at 12:24:18PM +0200, Domenico Andreoli wrote:
> > > > >  - libcurl3  (GnuTLS, soname: libcurl.so.3)

> > > >   So the libcurl3 in sarge and etch will have ABI incompatibilities?

> > > at the release time of etch this problem will regard only
> > > external software. this kind of installations will be able to use
> > > libcurl3-openssl-dev package or switch to GnuTLS.

> > > is this reasonable enough?

> > No, definitely not.  You cannot change the ABI of an existing library
> > package, especially not one that's been in a stable release; you need
> > to rename it instead.

> so we need both libcurl3-openssl and libcurl3-gnutls until libcurl4? i
> am not seeing this as a problem.

If there is really a reason to regard the SSL_CTX change as an ABI
change, then yes, that may be the best option.  I don't know if we need
to consider SSL_CTX an ABI incompatibility, though.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Sascha Einloft ist nicht im Büro.

[Sascha Einloft]

Ich werde ab  27.08.2005 nicht im Büro sein. Ich kehre zurück am
12.09.2005.

Bitte wenden Sie sich während meiner Abwesenheit an meine Kollegen von der
IT-Abteilung unter der Telefonnummer: +49 (8272) 86-555.

Ihre Mail wird nicht automatisch weitergeleitet!

Mit freundlichen Grüßen,

Sascha Einloft
IT-Abteilung
CREATON AG

Tel.: +49 (8272) 86 404
FAX: +49 (8272) 86 207404
eMail: [EMAIL PROTECTED]

Re: Spam on the BTS

[Blars Blarson]

On Sat, Sep 03, 2005 at 06:59:44PM +0200, Florian Weimer wrote:
> CBL has the advantage that you can make a local copy of the list
> (which reduces name server load and avoids the name lookup latency),
> but its license is somewhat non-free.  Is this a problem for Debian?

spohr is already running a nameserver, so it would have to run on an
alternate port.  I havn't looked into how hard it would be to convice
spamassassin to use something like this.

> What's causing most of the load right now?  I think some of the effort
> should probably concentrate on getting legitimate mail through faster.

spamscan is single-threaded, and the latency of DNSBL lookups is the
main delay.  We have less than 1 second to process each message on
average. Any good recomendations for a perl inter-process
communications library?  Once it becomes multi-threaded CPU usage
could become an issue, especially if we upgrade to spamassassin 3.

-- 
Blars Blarson   [EMAIL PROTECTED]
http://www.blars.org/blars.html
With Microsoft, failure is not an option.  It is a standard feature.


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

Re: It is 23:53, do you know whether your package (un)installs cleanly?

[Paul TBBle Hampson]

On Sat, Sep 03, 2005 at 11:53:35PM +0300, Lars Wirzenius wrote:
> Reading piuparts logs en masse is tedious and I would be extremely
> happy if all developers did it for their own packages. Go ahead,
> please prevent me from becoming a top ten bug reporter. :)

Since you've already run it, are the piuparts logs you've generated available
anywhere public?

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

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

License: http://creativecommons.org/licenses/by/2.1/au/
---


pgpMQ9bDiUHiz.pgp
Description: PGP signature

Re: bugs.d.o: usertags and user categories

[Anthony Towns]

On Sat, Sep 03, 2005 at 02:52:53AM +1000, Anthony Towns wrote:
> The second way is to use a tag to select interesting bugs -- there's not
> really much use knowing that an lsb-core bug is lsb related, but being
> able to list all the lsb-compliance bugs no matter which package, well
> that sounds more interesting. You can do that pretty much the same way:
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?
> tag=lsb;[EMAIL PROTECTED]
> That'll tell debbugs to look at all the tags debian-lsb has set, and
> prepare a report of all the bugs tagged "lsb".

An alternative that might also be useful:

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

http://bugs.debian.org/cgi-bin/pkgreport.cgi?
[EMAIL PROTECTED]:lsb

At some point

http://bugs.debian.org/usertag:debian-lsb@lists.debian.org

might work too.

Cheers,
aj


signature.asc
Description: Digital signature