Re: curl 7.14.0-5: OpenSSL vs GnuTLS is still a problem

[Olaf van der Spek]

On 9/12/05, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
> If they have compatible APIs.
> 
> So: if they are compatible, then yes, they should cover the same
> namespace, and then each should Provide the same package name.
> 
> Or, if they are not, they should provide different symbol names.
> 
> Or, as a second-best, they could be in different file names, with
> colliding symbol name spaces.
> 
> Or, as the absolutely worst, they could be the same file name and the
> packages could conflict.
> 
> Unfortunately, the last "solution" has been chosen.

Just wondering, why?
Is it that hard to enable 'different' symbols?

Build problem with Courier (#327162), need help

[Stefan Hornburg]

Hello,

I'm not able to build Courier packages for unstable which are intended
to fix security problems due to a curious FTBFS bug (#327162):

find /tmp/courier-0.47/debian/tmp -perm +u+x -type f | xargs chmod u+rwx,go+rx
chmod: too few arguments
Try `chmod --help' for more information.
make: *** [install] Error 123

There _are_ files with this permission and building the package within sarge
works and issuing the above command from outside of the sid chroot works as
well.

What is going wrong here ?

Bye
Racke

-- 
Debian maintainer of Courier, Pure-FTPd, Interchange, Sympa

LinuXia Systems => http://www.linuxia.de/
Expert Interchange Consulting and System Administration


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

Re: curl situation is intolerable

[Steve Langasek]

On Sun, Sep 11, 2005 at 09:46:26PM -0700, Thomas Bushnell BSG wrote:
> I don't care about the callback.  The package maintainers have the job
> of deciding whether the packages implement the same ABI or not.
> DECIDE.

> If the answer is "yes", then they should both be drop-in replacements,
> and Provide the same virtual package.

That isn't really an option so long as we have the GPL/OpenSSL license
issue to deal with, regardless of whether the ABI matches.

-- 
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: Build problem with Courier (#327162), need help

[Olaf van der Spek]

On 9/12/05, Stefan Hornburg <[EMAIL PROTECTED]> wrote:
> Hello,
> 
> I'm not able to build Courier packages for unstable which are intended
> to fix security problems due to a curious FTBFS bug (#327162):
> 
> find /tmp/courier-0.47/debian/tmp -perm +u+x -type f | xargs chmod u+rwx,go+rx
> chmod: too few arguments
> Try `chmod --help' for more information.
> make: *** [install] Error 123

Wouldn't something like echo provide a clue about what's happening?
find /tmp/courier-0.47/debian/tmp -perm +u+x -type f
find /tmp/courier-0.47/debian/tmp -perm +u+x -type f | xargs echo u+rwx,go+rx

Re: curl situation is intolerable

[Olaf van der Spek]

On 9/12/05, Steve Langasek <[EMAIL PROTECTED]> wrote:
> On Sun, Sep 11, 2005 at 09:46:26PM -0700, Thomas Bushnell BSG wrote:
> > I don't care about the callback.  The package maintainers have the job
> > of deciding whether the packages implement the same ABI or not.
> > DECIDE.
> 
> > If the answer is "yes", then they should both be drop-in replacements,
> > and Provide the same virtual package.
> 
> That isn't really an option so long as we have the GPL/OpenSSL license
> issue to deal with, regardless of whether the ABI matches.

Really?
I thought that if the interface matches the user can link whatever he
wants, because he doesn't (re)distribute the results.

Re: curl situation is intolerable

[Domenico Andreoli]

On Sun, Sep 11, 2005 at 09:46:26PM -0700, Thomas Bushnell BSG wrote:
> Paul TBBle Hampson <[EMAIL PROTECTED]> writes:
> 
> > Mind you, the license/OpenSSLCallback conflict neccessarily
> > segregates the packages into two camps, those which are GPL, and
> > those which need the callback only supplied by the OpenSSL-linked
> > libcurl.
> 
> You misunderstand my complaint.
> 
> I do not care that a given package cannot link to SSL and also be
> GPLd.  That's a hassle, but it's endurable.
> 
> What I complain is that, once the packages have been so segregated, it
> is now *impossible* to even install both kinds on the same Debian
> system at the same time.  *That* is intolerable.
>
> I don't care about the callback.  The package maintainers have the job
> of deciding whether the packages implement the same ABI or not.
> DECIDE.
> 
> If the answer is "yes", then they should both be drop-in replacements,
> and Provide the same virtual package.
> 
> If the answer is "no", then they should install different files in the
> Debian namespace and should not Conflict with each other.
> 
> DECIDE, and then do whichever.  But the current "solution" is utterly
> unacceptible.  

Thomas, i'm aware of the poor (non-)solution currently realized.

yesterday i was rolling a new upload with a modified name for
libcurl3-gnutls to allow both the packages to be installed at the same
time when i finally understood why i probably need versioned symbols.

then i looked for some kind soul (Matthias Urlichs) who introduced me
to the world of versioned symbols.

so my next favourite solution is:

curl   openssl
libcurl3   openssl, versioned symbols
libcurl3-dev   openssl
libcurl3-gnutlsgnutls, versioned symbols
libcurl3-gnutls-devgnutls
libcurl3-dbg   openssl


will libcurl3 with versioned symbols break existing packages linked
to it?

cheers
domenico

-[ 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: curl situation is intolerable

[Richard Atterer]

Folks, *please* consider to help with the implementation of the real
solution for libcurl4, i.e. several SSL backends to just one libcurl.so
"front-end", without installation conflicts, modular and compatible with
all licenses. See the second half of
.

I am rather swamped with lots of other things. Daniel (curl upstream)
sounds like he will accept a patch to implement this, but he will probably
not do any work on this himself.

Also see , a first, very
incomplete patch by me.

Cheers,
 
  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯


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

Re: curl situation is intolerable

[Steve Langasek]

On Mon, Sep 12, 2005 at 11:34:22AM +0200, Domenico Andreoli wrote:
> will libcurl3 with versioned symbols break existing packages linked
> to it?

It will not.

It would be best to coordinate with upstream to get symbol versioning
added there as well, so that binaries built against the symbol-versioned
Debian lib can also be run on other systems.

-- 
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: Bug#318590: curl situation is intolerable

[Domenico Andreoli]

On Mon, Sep 12, 2005 at 03:03:02AM -0700, Steve Langasek wrote:
> On Mon, Sep 12, 2005 at 11:34:22AM +0200, Domenico Andreoli wrote:
> > will libcurl3 with versioned symbols break existing packages linked
> > to it?
> 
> It will not.

good

> It would be best to coordinate with upstream to get symbol versioning
> added there as well, so that binaries built against the symbol-versioned
> Debian lib can also be run on other systems.

i already contacted him

cheers
domenico

-[ 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: Build problem with Courier (#327162), need help

[Willi Mann]

I'm not able to build Courier packages for unstable which are intended
to fix security problems due to a curious FTBFS bug (#327162):

find /tmp/courier-0.47/debian/tmp -perm +u+x -type f | xargs chmod u+rwx,go+rx
chmod: too few arguments
Try `chmod --help' for more information.
make: *** [install] Error 123

There _are_ files with this permission and building the package within sarge
works and issuing the above command from outside of the sid chroot works as
well.


The reason is that findutils 4.2.2{4,5}-1 behave differently. (I don't 
know why exactly). If you change the -perm argument to

-perm -u+x
it works.

Willi


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

Re: curl situation is intolerable

[Henning Makholm]

Scripsit Domenico Andreoli <[EMAIL PROTECTED]>

> yesterday i was rolling a new upload with a modified name for
> libcurl3-gnutls to allow both the packages to be installed at the same
> time when i finally understood why i probably need versioned symbols.

However unacceptable the current situation is, wouldn't fixing it now
introduce a library transition? And wouldn't it be a good idea to
postpone that until the current large transitions are done with?

-- 
Henning Makholm   "The great secret, known to internists and
 learned early in marriage by internists' wives, but
   still hidden from the general public, is that most things get
 better by themselves. Most things, in fact, are better by morning."


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

Re: Build problem with Courier (#327162), need help

[Stefan Hornburg]

On Mon, 12 Sep 2005 11:08:05 +0200
Olaf van der Spek <[EMAIL PROTECTED]> wrote:

> On 9/12/05, Stefan Hornburg <[EMAIL PROTECTED]> wrote:
> > Hello,
> > 
> > I'm not able to build Courier packages for unstable which are intended
> > to fix security problems due to a curious FTBFS bug (#327162):
> > 
> > find /tmp/courier-0.47/debian/tmp -perm +u+x -type f | xargs chmod 
> > u+rwx,go+rx
> > chmod: too few arguments
> > Try `chmod --help' for more information.
> > make: *** [install] Error 123
> 
> Wouldn't something like echo provide a clue about what's happening?
> find /tmp/courier-0.47/debian/tmp -perm +u+x -type f
> find /tmp/courier-0.47/debian/tmp -perm +u+x -type f | xargs echo u+rwx,go+rx
> 

No, because find is supposed to find files and it doesn't. 

But another post seems to have the solution :-).

Bye
Racke

-- 
Debian maintainer of Courier, Pure-FTPd, Interchange, Sympa

LinuXia Systems => http://www.linuxia.de/
Expert Interchange Consulting and System Administration


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

Re: Build problem with Courier (#327162), need help

[Stefan Hornburg]

On Mon, 12 Sep 2005 12:52:45 +0200
Willi Mann <[EMAIL PROTECTED]> wrote:

> 
> > I'm not able to build Courier packages for unstable which are intended
> > to fix security problems due to a curious FTBFS bug (#327162):
> > 
> > find /tmp/courier-0.47/debian/tmp -perm +u+x -type f | xargs chmod 
> > u+rwx,go+rx
> > chmod: too few arguments
> > Try `chmod --help' for more information.
> > make: *** [install] Error 123
> > 
> > There _are_ files with this permission and building the package within sarge
> > works and issuing the above command from outside of the sid chroot works as
> > well.
> 
> The reason is that findutils 4.2.2{4,5}-1 behave differently. (I don't 
> know why exactly). If you change the -perm argument to
> -perm -u+x
> it works.

Grmpf. Ok, I'll try this. 

Thank you very much !

Racke
 


-- 
Debian maintainer of Courier, Pure-FTPd, Interchange, Sympa

LinuXia Systems => http://www.linuxia.de/
Expert Interchange Consulting and System Administration


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

Re: curl situation is intolerable

[Marco d'Itri]

On Sep 12, Richard Atterer <[EMAIL PROTECTED]> wrote:

> Folks, *please* consider to help with the implementation of the real
> solution for libcurl4, i.e. several SSL backends to just one libcurl.so
> "front-end", without installation conflicts, modular and compatible with
> all licenses. See the second half of
> .
I do not believe that it's worth the effort, there are no really good
reasons to use OpenSSL in the long time.
Development effort should be focused on fixing any eventual gnutls bugs
(either in the library itself or in the libcurl glue).

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: curl situation is intolerable

[Steve Langasek]

On Mon, Sep 12, 2005 at 11:09:31AM +0200, Olaf van der Spek wrote:
> On 9/12/05, Steve Langasek <[EMAIL PROTECTED]> wrote:
> > On Sun, Sep 11, 2005 at 09:46:26PM -0700, Thomas Bushnell BSG wrote:
> > > I don't care about the callback.  The package maintainers have the job
> > > of deciding whether the packages implement the same ABI or not.
> > > DECIDE.

> > > If the answer is "yes", then they should both be drop-in replacements,
> > > and Provide the same virtual package.

> > That isn't really an option so long as we have the GPL/OpenSSL license
> > issue to deal with, regardless of whether the ABI matches.

> Really?
> I thought that if the interface matches the user can link whatever he
> wants, because he doesn't (re)distribute the results.

There isn't universal agreement on this point, and it's never actually
been tested in court.  Debian generally plays it safe, though, there
doesn't seem to be much reason to be a test case for this given that at
least some copyright holders of GPL works don't want their code used
with OpenSSL.

-- 
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: curl situation is intolerable

[Richard Atterer]

On Mon, Sep 12, 2005 at 02:05:23PM +0200, Marco d'Itri wrote:
> On Sep 12, Richard Atterer <[EMAIL PROTECTED]> wrote:
> > Folks, *please* consider to help with the implementation of the real
> > solution for libcurl4, i.e. several SSL backends to just one libcurl.so
> > "front-end", without installation conflicts, modular and compatible with
> > all licenses. See the second half of
> > .
> I do not believe that it's worth the effort, there are no really good
> reasons to use OpenSSL in the long time.
> Development effort should be focused on fixing any eventual gnutls bugs
> (either in the library itself or in the libcurl glue).

Well, how much is "in the long run"? It could be years. Furthermore,
OpenSSL is simply much more popular, plus it will stay the "primary" SSL
implementation for curl upstream for the foreseeable future.

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯


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

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

[Ken Bloom]

Anthony Towns wrote:
> Hello world,
> 
> There's been a bunch of changes to the BTS over the past couple of
> months, pretty much leading up to, during, and following debconf [0].
> These are the next two. :)
> 
> [0] Blocking bugs, min/maxdays, bug subscriptions, version tracking,
> prettier bug report pages, prettier package report pages, ability
> to change options from the package report pages rather than just by
> editing urls or going back to the main page, internal changes to how
> mail works that fixes some long standing bugs, some internal support
> to make cookies plausible, a couple of new members to the BTS team,
> maybe some other stuff I've forgotten...

The only new stuff that seems to be documented in the help files for BTS
is the version tracking stuff. Everything else (bug subscriptions, user
tags) hasn't hit the documentation yet.

--Ken Bloom

-- 
I usually have a GPG digital signature included as an attachment.
See http://www.gnupg.org/ for info about these digital signatures.


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

Bug#327854: ITP: imview-doc -- The manual for Imview

[Teemu Ikonen]

Package: wnpp
Severity: wishlist
Owner: Teemu Ikonen <[EMAIL PROTECTED]>


* Package name: imview-doc
  Version : 1.0.1
  Upstream Author : Hugues Talbot <[EMAIL PROTECTED]>
* URL : http://www.cmis.csiro.au/Hugues.Talbot/imview/
* License : GFDL
  Description : The manual for Imview

 This is the complete user manual for Imview, an image viewing and analysis
 application found in the Debian package imview.
  

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (600, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.11-1-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)


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

Re: Bug#323227: new list: debian-planet to distribute planet.debian.org postings; archive to enable searching

[Martin Schulze]

Tollef Fog Heen wrote:
> | I'd like to have a debian-planet list that would receive blog postings
> | from planet.debian.org.
> | 
> | The main reason is that after postings expire on the planet website,
> | it's very hard to find old postings if you cannot remember who wrote
> | it. Think of "there was some nice sh script snippet" or "someone
> | pointed to that great package". Now you have to manually browse all
> | feeds or hope for google. Having a regular list archive on
> | lists.debian.org would solve this.
> 
> I would like this not to happen.  Having your feed syndicated on
> planet.debian does not mean you want all your postings to end up in a
> public mail archive somewhere.

Isn't this a bit bogus since even if your web log does not support displaying
items that are older than say two months, the chance that they're found by
the internet archive is quite high, except that you've explicitely disallowed
this, and as well for planet.debian.org?

Maybe, if you don't want your output to be found on the Internet, you
should not make it available on the Internet?

Regards,

Joey

-- 
Whenever you meet yourself you're in a time loop or in front of a mirror.

Please always Cc to me when replying to me on the lists.


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

Re: Bug#323227: new list: debian-planet to distribute planet.debian.org postings; archive to enable searching

[Martin Schulze]

Benj. Mako Hill wrote:
> 
> > I'd like to have a debian-planet list that would receive blog
> > postings from planet.debian.org.
> > 
> > The main reason is that after postings expire on the planet website,
> > it's very hard to find old postings if you cannot remember who wrote
> > it. Think of "there was some nice sh script snippet" or "someone
> > pointed to that great package". Now you have to manually browse all
> > feeds or hope for google. Having a regular list archive on
> > lists.debian.org would solve this.
> > 
> > Joey has already set up a list for that privately, but it is not
> > archived publically. Providing that service from lists.debian.org
> > would recognize the importance of planet.debian.org to Debian
> > culture.
> 
> Is this private list available for other people to subscribe to? At
> the very least, can we document this?
> 
> It sounds like a number of people would be happier with with this both
> as an unofficial service and a non-public archived list. If Joey is
> not happy with running this, I'm happy to set up the rss2email program
> on a list at my own site. 

Feel free to document this.  The list is
[EMAIL PROTECTED] and is run by
smartlist/majorsmart similar to lists.debian.org.

I started it to be able to follow Planet Debian on my own but got
requests from some friends to read the feed as well.

I seconds Myon's proposal to have an official list for the Planet
Debian aggregation.

Regards,

Joey

-- 
Whenever you meet yourself you're in a time loop or in front of a mirror.

Please always Cc to me when replying to me on the lists.


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

Bug#327860: ITP: libpam-encfs -- PAM module to automatically mount encfs filesystems on login

[Ruben Porras]

Package: wnpp
Severity: wishlist
Owner: Ruben Porras <[EMAIL PROTECTED]>

* Package name: libpam-encfs
  Version : 0.1.2
  Upstream Author : Anders Aagaard <[EMAIL PROTECTED]>
* URL : http://hollowtube.mine.nu/wiki/index.php/PAM/PamEncfs
* License : GPLv2 or later
  Description : PAM module to automatically mount encfs filesystems on login

This PAM module integrates encfs [0] and PAM, so home directories are
automatically mounted on login. EncFS provides an encrypted filesystem in
user-space, this PAM module easily allow each user to have an encrypted home,
and mount it using its login password as encfs password automatically.

[0] http://arg0.net/wiki/encfs
http://packages.debian.org/unstable/utils/encfs

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1-686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8)


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

architecture alias and disto rebuild

[Bill Allombert]

Hello Debian developers,

Some distributions/people rebuild a lot of Debian packages from Debian
source while making no change to the source. While this is technically
a binNMU they seldom bother to bump the version, which lead to two debs
files with different content (if they are built with a different version
of gcc, e.g) which somehow break the package version idea and make very
hard to see it is not the one compiled by Debian.

This is understandable since bumping the version can cause unforeseen
bugs  (though I would like very much a list of package that cannot be
binNMUed). So I propose a alternate solution:

If the distro foobar rebuild packages on i386, they could use
i386foobar as architecture name instead of i386, this way every
package they rebuild will be clearly marked as such. 

Of course, if foobar want to allow regular Debian package to be installed,
they can just patch dpkg so that it accept both kind of package.

The morale of the story is: since we have now comprehensive plateform
handling with CPU-SYSTEM, why not go a little farther and add a BUILDER
field with the suitable logic in dpkg so that it allow to install
packages from any builder by default ?

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

Imagine a large red swirl here. 


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

Re: Build problem with Courier (#327162), need help

[Daniel Jacobowitz]

On Mon, Sep 12, 2005 at 12:52:45PM +0200, Willi Mann wrote:
> 
> >I'm not able to build Courier packages for unstable which are intended
> >to fix security problems due to a curious FTBFS bug (#327162):
> >
> >find /tmp/courier-0.47/debian/tmp -perm +u+x -type f | xargs chmod 
> >u+rwx,go+rx
> >chmod: too few arguments
> >Try `chmod --help' for more information.
> >make: *** [install] Error 123
> >
> >There _are_ files with this permission and building the package within 
> >sarge
> >works and issuing the above command from outside of the sid chroot works as
> >well.
> 
> The reason is that findutils 4.2.2{4,5}-1 behave differently. (I don't 
> know why exactly). If you change the -perm argument to
> -perm -u+x
> it works.

That means something different.  There's still an example using +g+w on
the find man page; if it's broken, isn't it a bug in find?

-- 
Daniel Jacobowitz
CodeSourcery, LLC


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

Re: Distro Development Talk

[Martin Schulze]

Jason Chu wrote:
> (I'm not a member of the list, so please CC me on any responses you want me
> to see)
> 
> I'm a developer for a neighbour distro, Arch Linux, and I'm starting up a
> site to discuss distro development issues.
> 
> The goal is to have a site that describes solutions to common distro
> problems and shares information between distros more.

It may be worth noting the [EMAIL PROTECTED] list that was
started to discuss such issues.

Regards,

Joey

-- 
Whenever you meet yourself you're in a time loop or in front of a mirror.

Please always Cc to me when replying to me on the lists.


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

Re: curl situation is intolerable

[Thomas Bushnell BSG]

Steve Langasek <[EMAIL PROTECTED]> writes:

> On Sun, Sep 11, 2005 at 09:46:26PM -0700, Thomas Bushnell BSG wrote:
>> I don't care about the callback.  The package maintainers have the job
>> of deciding whether the packages implement the same ABI or not.
>> DECIDE.
>
>> If the answer is "yes", then they should both be drop-in replacements,
>> and Provide the same virtual package.
>
> That isn't really an option so long as we have the GPL/OpenSSL license
> issue to deal with, regardless of whether the ABI matches.

I'm not sure I see what that is, but regardless, if it is so, then
they must be separate libraries with nonconflicting packages.

All this dithering about which way to go is the problem, not the
solution.  


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

Re: curl situation is intolerable

[Thomas Bushnell BSG]

Richard Atterer <[EMAIL PROTECTED]> writes:

> Folks, *please* consider to help with the implementation of the real
> solution for libcurl4, i.e. several SSL backends to just one libcurl.so
> "front-end", without installation conflicts, modular and compatible with
> all licenses. See the second half of
> .

Fine, and when that's done, we can do that.

UNTIL that is done, the two libcurls *must not conflict*.


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

Re: curl situation is intolerable

[Marco d'Itri]

On Sep 12, Richard Atterer <[EMAIL PROTECTED]> wrote:

> > I do not believe that it's worth the effort, there are no really good
> > reasons to use OpenSSL in the long time.
> > Development effort should be focused on fixing any eventual gnutls bugs
> > (either in the library itself or in the libcurl glue).
> Well, how much is "in the long run"? It could be years. Furthermore,
One year at most, considering that so far I have not seen reports of
major problems with libcurl+libgnutls.

> OpenSSL is simply much more popular, plus it will stay the "primary" SSL
So what?

> implementation for curl upstream for the foreseeable future.
Again, who cares?
If Debian will use gnutls by default it will get more than enough
testing.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Bug#327081: ITP: rpmstrap -- bootstrap a basic RPM-based system

[Sam Hart]

On Sun, 2005-09-11 at 20:56 +1000, Anthony Towns wrote:
> On Wed, Sep 07, 2005 at 02:08:04PM +0200, Piotr Roszatycki wrote:
> > * Package name: rpmstrap
> >   Version : 0.5
> > * URL : http://hackers.progeny.com/~sam/rpmstrap/
> > * License : GPL
> >   Description : bootstrap a basic RPM-based system
> > 
> >  rpmstrap is a tool for bootstrapping a basic RPM-based system. It is 
> > inspired
> >  by debootstrap, and allows you to build chroots and basic systems from RPM
> >  sources.
> 
> Looking at the source it seems more "based on" than "inspired by",
> particular to "rpmstrap" itself, though the "functions" and "scripts/*"
> files sure seem more derivative than just coincidently similar. If
> so, it's in violation of debootstrap's license (by not including
> debootstrap's copyright text), and it seems fairly rude to relicense it
> from debootstrap's BSD-ish license to GPLv2+, not to mention expunging
> my name and copyright notice from the source, and for that matter all
> references to debootstrap.
> 
> Removing the copyright's a license violation, and presumably renders the
> program undistributable and unpackagable, afaics.
> 
> At least Bastian Blank's cdebootstrap was written from scratch to justify
> its different license and lack of recognition. Colour me unimpressed.

To be completely honest with you, I've not looked much at the
debootstrap code before now. I have tried to mimic debootstrap's
interface without a doubt, but have only done so by *using* debootstrap
rather than snooping in its code. I am astounded that I have been
accused of stealing code or "expunging" any name or copyright
information.

For what it's worth, rpmstrap as it is today is actually based on a tool
developed in house at Progeny. This tool could only bootstrap Fedora
Core 2 at a specific revision. Looking at that code now and comparing it
to what I see inside of debootstrap, the only real similarities I see
are that they both have functions common to /many/ other shell scripts
(usage(), die(), warn(), trace()).

I will have to check the legacy on this tool used internally at Progeny
to ensure nothing came from debootstrap, but to the best of my knowledge
it did not. In fact, looking at this internal tool now, it is only 314
lines of code, 153 of which are lists of FC2 packages, so it doesn't
seem likely to share any common ancestry with debootstrap.

Starting with this internal tool, I aimed to build something that could
bootstrap any other RPM-based systems. Part of my goal was to mimic
debootstrap's functionality as it was a tool I had a lot of respect for.
However, I only mimicked it based upon my usage of debootstrap. Thus, in
my design of rpmstrap I did recreate the following from the design of
debootstrap:

1) Identical command-line options:
I wanted rpmstrap to take the same command line options
as debootstrap. This was more out of convenience because
I already knew the debootstrap options and I didn't want
to have to keep track of two different usages. This was
also because I wanted rpmstrap to be something that
someone could just drop into a tool that already used
debootstrap and it would work without any major
tweaking.

2) Placing of suite scripts inside of a "scripts/*" directory:
I wanted to split out the RPM-suites into their own
suite scripts. Originally, I thought of placing these in
either a directory called "suites/*" or one called
"scripts/*". I'll admit freely that I did a "dpkg-query
-L debootstrap" so I could mimic the directory structure
(remember, I wanted this to be a drop-in replacement).
However, that is not looking at the code, merely the
directory layout. I am reasonably certain that directory
layout is not copyrightable.

3) Making common functions available to suite scripts:
I wanted several functions written to be available to
the suite scripts. I originally place these into a file
called "functions", and was pleased to see that
debootstrap had taken similar logic when I did the
"dpkg-query -L debootstrap" above.

So, in conclusion, I did not copy any code from debootstrap, and to the
best of my knowledge, neither did any other contributors. The goal of
rpmstrap has always been to mimic what debootstrap does, except for
RPM-based systems.

rpmstrap and debootstrap both have similar design goals (and rpmstrap
was designed to have the same interface as debootstrap) so there will
undoubtedly be similarities.

Anthony, I value and respect your input, could you show me examples of
code that you believe was stolen? There is a very remote possibility
that code from contributo

Re: apt with index diff support

[Andreas Metzler]

On 2005-09-11 Michael Vogt <[EMAIL PROTECTED]> wrote:
> On Sat, Sep 10, 2005 at 04:46:09PM +0200, Andreas Metzler wrote:
[...]
>> Having to specify this at the commandline is messy, is there a way to put
>> this in /etc/apt.conf.d/?

> Please add (in e.g. /etc/apt/apt.conf.d/50remap):
> APT::URL-Remap::"http://merkel.debian.org/~aba/debian/"; 
> "http://ftp.de.debian.org/debian/";; 
[...]

Thank you, this work nicely.

| Get:8 2005-09-11-2032.14.pdiff [8309B]
| Fetched 20.5MB in 7s (2619kB/s)
  cu and- 80K downstream -reas


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

Re: Build problem with Courier (#327162), need help

[Andreas Metzler]

Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 12, 2005 at 12:52:45PM +0200, Willi Mann wrote:
[...] 
>>> find /tmp/courier-0.47/debian/tmp -perm +u+x -type f | xargs chmod 
>>> u+rwx,go+rx
[...]
>> The reason is that findutils 4.2.2{4,5}-1 behave differently. (I don't 
>> know why exactly). If you change the -perm argument to
>> -perm -u+x
>> it works.

The whole thing is caused by

| The GNU extension "find ... -perm +MODE" has been withdrawn because it
| is incompatible with POSIX in obscure cases like "find ... -perm ++r".
| Use the new syntax "find ... -perm /MODE" instead.  Old usages will
| still continue to work, so long as they don't conflict with POSIX.

however, today I am too stupid to properly parse the way -perm works
today.

> That means something different. There's still an example using +g+w on
> the find man page; if it's broken, isn't it a bug in find?

It is indeed a bug that the manpage has not caught up - the info docs
are up-to-date. I'll get this fixed.
   cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"


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

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

[Andreas Metzler]

Ken Bloom <[EMAIL PROTECTED]> wrote:
> Anthony Towns wrote:
>> There's been a bunch of changes to the BTS over the past couple of
>> months, pretty much leading up to, during, and following debconf [0].
>> These are the next two. :)
[...]
> The only new stuff that seems to be documented in the help files for BTS
> is the version tracking stuff. Everything else (bug subscriptions, user
> tags) hasn't hit the documentation yet.

http://www.debian.org/Bugs/Developer#subscribe

  cu and- not trying to deny your pont, just pointing out a badly
  chosen example reas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"


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

Re: Bug#327081: ITP: rpmstrap -- bootstrap a basic RPM-based system

[Sam Hart]

On Mon, 2005-09-12 at 12:12 -0500, Sam Hart wrote:
> For what it's worth, rpmstrap as it is today is actually based on a tool
> developed in house at Progeny. This tool could only bootstrap Fedora
> Core 2 at a specific revision. Looking at that code now and comparing it
> to what I see inside of debootstrap, the only real similarities I see
> are that they both have functions common to /many/ other shell scripts
> (usage(), die(), warn(), trace()).
> 
> I will have to check the legacy on this tool used internally at Progeny
> to ensure nothing came from debootstrap, but to the best of my knowledge
> it did not. In fact, looking at this internal tool now, it is only 314
> lines of code, 153 of which are lists of FC2 packages, so it doesn't
> seem likely to share any common ancestry with debootstrap.

I have just been given permission to post the original internal tool
used at Progeny which rpmstrap is based upon, in case anyone would care
to check the legacy for debootstrap code.

This original tool was also called "rpmstrap" and was written from
scratch by Branden Robinson. It does not contain any code borrowed from
debootstrap.

The first appearance of rpmstrap in the internal Progeny svn is the
following code:
http://hackers.progeny.com/~sam/rpmstrap/legacy/rpmstrap-original

The most current revision of rpmstrap in the same svn is:
http://hackers.progeny.com/~sam/rpmstrap/legacy/rpmstrap

This is the actual base for what is now rpmstrap as I maintain. It is
also why the current rpmstrap is GPLv2.

The one thing I have just realized is that the current rpmstrap script
does not actually have Branden's name in it as an author (although his
name does exist in some of the suite scripts). I will rectify this
shortly and apologize for the oversight.

-- 
'
.O. Sam Hart, [EMAIL PROTECTED]
..OProgeny Linux Systems, Inc
OOO 


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

Re: Bug#327081: ITP: rpmstrap -- bootstrap a basic RPM-based system

[Anthony Towns]

On Mon, Sep 12, 2005 at 12:12:31PM -0500, Sam Hart wrote:
> To be completely honest with you, I've not looked much at the
> debootstrap code before now. I have tried to mimic debootstrap's
> interface without a doubt, but have only done so by *using* debootstrap
> rather than snooping in its code. 

It's not "snooping" to look at the code of a free software project.

> For what it's worth, rpmstrap as it is today is actually based on a tool
> developed in house at Progeny. This tool could only bootstrap Fedora
> Core 2 at a specific revision. Looking at that code now and comparing it
> to what I see inside of debootstrap, the only real similarities I see
> are that they both have functions common to /many/ other shell scripts
> (usage(), die(), warn(), trace()).

Looking at rpmstrap-0.1, we see the following code for handling options:

] if [ $# != 0 ] ; then
] while true ; do
] case "$1" in
] --help)
] usage
] exit 0
] ;;
] ...
] esac
] done
] else
] usage_error "You must specify a suite and a target."
] fi

debootstrap uses the exact same code, except to say "usage_err
1 NEEDSUITETARGET" instead of "usage_error" and with two-space
indentation. The usual way to parse arguments is with a `for a in "$@"'
loop, or using getopt -- the above parsing algorithm has the bug that
options can only appear at the beginning of the command line, eg.

rpmstrap-0.1 uses the variable "$JUST_PRINT_RPMS" to track whether to dump
the list of rpms to stdout or not; debootstrap uses "$JUST_PRINT_DEBS".

Compare the usage() functions:

] usage()
] {
] echo "Usage: $PROGNAME [OPTION]...   []"
] echo "Bootstrap RPM-based systems."
] echo
] cat <  [ [

Re: Bug#327081: ITP: rpmstrap -- bootstrap a basic RPM-based system

[Branden Robinson]

Anthony Towns wrote:
> > > Looking at the source it seems more "based on" than "inspired by",
> > > particular to "rpmstrap" itself, though the "functions" and "scripts/*"
> > > files sure seem more derivative than just coincidently similar. If
> > > so, it's in violation of debootstrap's license (by not including
> > > debootstrap's copyright text), and it seems fairly rude to relicense it
> > > from debootstrap's BSD-ish license to GPLv2+, not to mention expunging
> > > my name and copyright notice from the source, and for that matter all
> > > references to debootstrap.
> > > 
> > > Removing the copyright's a license violation, and presumably renders the
> > > program undistributable and unpackagable, afaics.
> > > 
> > > At least Bastian Blank's cdebootstrap was written from scratch to
> > > justify its different license and lack of recognition. Colour me
> > > unimpressed.

Sam Hart wrote:
> > For what it's worth, rpmstrap as it is today is actually based on a tool
> > developed in house at Progeny. This tool could only bootstrap Fedora
> > Core 2 at a specific revision. Looking at that code now and comparing it
> > to what I see inside of debootstrap, the only real similarities I see
> > are that they both have functions common to /many/ other shell scripts
> > (usage(), die(), warn(), trace()).

Anthony, I've been using shell functions with these names (and the
expected corresponding behaviors) in shell scripts I write for years
now, so you're probably going to need to accuse me of copyright
infringement in shell-lib.sh[1] in the XFree86 and X.Org packages as well.

> > I will have to check the legacy on this tool used internally at Progeny
> > to ensure nothing came from debootstrap, but to the best of my knowledge
> > it did not. In fact, looking at this internal tool now, it is only 314
> > lines of code, 153 of which are lists of FC2 packages, so it doesn't
> > seem likely to share any common ancestry with debootstrap.
> 
> I have just been given permission to post the original internal tool
> used at Progeny which rpmstrap is based upon, in case anyone would care
> to check the legacy for debootstrap code.
> 
> This original tool was also called "rpmstrap" and was written from
> scratch by Branden Robinson. It does not contain any code borrowed from
> debootstrap.

I assert this to be the case.  I'm easily capable of writing the trivial
shell script that constitutes the original "rpmstrap", and the
modifications I made to it subsequently.

For your edification, I'm attaching the SVN commit log for "rpmstrap" up
to and including my last change to it.  None of this is rocket science.

Oh, what the hell, how about I attach the diff of each commit as well,
making it all the easier to identify the exact spots where I absconded
with debootstrap code, mustache twitching!

> The first appearance of rpmstrap in the internal Progeny svn is the
> following code:
> http://hackers.progeny.com/~sam/rpmstrap/legacy/rpmstrap-original
> 
> The most current revision of rpmstrap in the same svn is:
> http://hackers.progeny.com/~sam/rpmstrap/legacy/rpmstrap
> 
> This is the actual base for what is now rpmstrap as I maintain. It is
> also why the current rpmstrap is GPLv2.
> 
> The one thing I have just realized is that the current rpmstrap script
> does not actually have Branden's name in it as an author (although his
> name does exist in some of the suite scripts). I will rectify this
> shortly and apologize for the oversight.

Well, only if there's any of my original nasty kludge *left*.  I kind of
hope it isn't.  :)  (Okay, you can keep usage()/trace()/warn()/die(),
but as for the rest... :) )

The original rpmstrap I wrote was done in haste, but it was not
plagiarized.  The accusation would be amusing if it weren't so
insulting.

[1] http://necrotic.deadbeast.net/svn/xorg-x11/trunk/debian/shell-lib.sh

(There, trace() is not present, but a similar function, observe(),
is.  Neither function is an example of anything more than highly
trivial and idiomatic shell usage.)

-- 
Branden Robinson  | GPG signed/encrypted mail welcome
[EMAIL PROTECTED]   | 1024D/9C0BCBFB
Progeny Linux Systems | D5F6 D4C9 E25B 3D37 068C
  | 72E8 0F42 191A 9C0B CBFB

r16721 | branden | 2005-02-15 12:06:40 -0500 (Tue, 15 Feb 2005) | 2 lines

Install i386, not i686, version of openssl on x86_64 systems.


r15950 | branden | 2004-10-01 12:22:58 -0500 (Fri, 01 Oct 2004) | 3 lines

Fix erroneous architecture string in x86 glibc package for
x86_64.


r15943 | branden | 2004-09-29 15:35:44 -0500 (Wed, 29 Sep 2004) | 13 lines

Add command-line options -h | --help, -l | --list, and -v |
--verbose.

The new -l | --list feature simply prints the list of required
RPMs and exits.

Stop ha

Re: Bug#327081: ITP: rpmstrap -- bootstrap a basic RPM-based system

[Anthony Towns]

On Tue, Sep 13, 2005 at 04:41:26AM +1000, Anthony Towns wrote:
> Looking at rpmstrap-0.1, we see the following code for handling options:

Also copied was debootstrap's --arch and --include handling; even
duplicating the bug where you have to say "--arch i386" (with a space)
and "--include=foo,bar" (with an =). There even seems to have been a bug
introduced during the copying; debootstrap has:

]   --include*)
] additional="$(echo $1 | cut -f2 -d"="|tr , " ")"
] shift 1
] ;;
]   --exclude*)
] exclude="$(echo $1 | cut -f2 -d"="|tr , " ")"
] shift 1
] ;;

Someone involved in rpmstrap-0.1 evidently decided using lowercase
variables in some places was unacceptably inconsistent and changed
that to:

]   --include*)
]   ADDITIONAL="$(echo $1 | cut -f2 -d"="|tr , " ")"
]   shift 1
]   ;;
]   --exclude*)
]   ADDITIONAL="$(echo $1 | cut -f2 -d"="|tr , " ")"
]   shift 1
]   ;;

making --exclude work the same as --include, up until rpmstrap-0.4,
where they were changed to INCLUDES and EXCLUDES instead.

rpmstrap-0.1 set an UNPACK_TARBALL variable based on an --unpack-tarball
using the same code as debootstrap; but UNPACK_TARBALL is never actually
used; support for it is only implemented in rpmstrap-0.2.

Cheers,
aj


signature.asc
Description: Digital signature

Re: Bug#327081: ITP: rpmstrap -- bootstrap a basic RPM-based system

[Sam Hart]

On Tue, 2005-09-13 at 04:41 +1000, Anthony Towns wrote:
> Looking at rpmstrap-0.1, we see the following code for handling options:

> debootstrap uses the exact same code, except to say "usage_err
> 1 NEEDSUITETARGET" instead of "usage_error" and with two-space
> indentation. The usual way to parse arguments is with a `for a in "$@"'
> loop, or using getopt -- the above parsing algorithm has the bug that
> options can only appear at the beginning of the command line, eg.

I've slightly regretted not using getopt, honestly, however the bug you
point out is in many different shell scripts. This really seems a very
common way for people to parse command line options.

As for the name of the usage error function, yes they are similarly
named, but that was really coincidental I assure you.

> rpmstrap-0.1 uses the variable "$JUST_PRINT_RPMS" to track whether to dump
> the list of rpms to stdout or not; debootstrap uses "$JUST_PRINT_DEBS".

Ah, you're right on that one. The use of that variable was suggested to
me by someone who had used debootstrap for some VPS setups. He
maintained custom debootstrap scripts and desired the ability to do some
similar RPM-based VPS scripts. I'd have to check my mail archives to be
certain I am remembering this correctly, but I believe that was part of
a very early patch when rpmstrap was still living as a small set of
scripts.

> Compare the usage() functions:

> The code that handles the "You must specify a suite and a target." error
> messages looks pretty familiar too, but I've changed it a few times and
> I didn't find an exact match at first glance.

The usage() functions and error messages really should come as no
surprise. I was modeling the output based upon what I was getting from
debootstrap. Like I said, the intention was to reproduce debootstrap's
interface so rpmstrap would be familiar to people who have used
debootstrap before. I would guess that all of the error messages common
to the two of them would have similar wording.

> > I will have to check the legacy on this tool used internally at Progeny
> > to ensure nothing came from debootstrap,
> 
> As opposed to use a license that means it could potentially be incorporated
> into debootstrap or give credit where it seems like it's due, considering

It actually was not my decision to GPLv2 it. I honestly didn't care what
license it was released under. GPLv2 was just what the original base as
written by Branden Robinson was copyrighted under.

> > 1) Identical command-line options:
> > 2) Placing of suite scripts inside of a "scripts/*" directory:
> > 3) Making common functions available to suite scripts:
> 
> that you did seem to copy quite a bit from debootstrap anyway.

No, I did not. Maintaining an identical interface and file layout is not
copying code. Aside from the $JUST_PRINT_RPMs patch (which I will track
down to see what else it may have contained) doing similar things in
command-line option handling and usage() functions which have been done
many times before in other shell scripts does not show copying code.

> Even if you hadn't copied any code whatsoever, isn't a little
> acknowledgement appropriate? It's not as though debootstrap's license
> is particularly onerous.

I maintain that I did not copy any code. If you look at the problem
logically, building an RPM-based bootstrap is quite a bit different from
building a DEB-based bootstrap. In the RPM-world I have to keep track of
a lot of information that you wouldn't need to in the DEB-world because
with DEB you get a more rich set of tools. As an example, in an
RPM-based distribution you have to keep track of installation order and
grouping.

However, I do want to make sure that you and debootstrap get appropriate
acknowledgment. I honestly thought I had given sufficient acknowledgment
by linking from the website and mentioning it in the documentation.

Would adding something like the following to the header of the scripts
(under the authors line) be sufficient?
 * Inspired by and modeled after Anthony Towns' debootstrap (URL).

In all seriousness, I never wanted to /not/ let people know what
rpmstrap was intended to be like debootstrap but for RPM-based
distributions.

-- 
'
.O. Sam Hart, [EMAIL PROTECTED]
..OProgeny Linux Systems, Inc
OOO 


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

Bug#327890: ITP: libhtml-prototype-perl -- Generate HTML and Javascript for the Prototype library

[Krzysztof Krzyzaniak (eloy)]

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


* Package name: libhtml-prototype-perl
  Version : 1.33
  Upstream Author : Sebastian Riedel, <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/~mramberg/HTML-Prototype-1.33/
* License : Perl: GPL, Artistic
  Description : Generate HTML and Javascript for the Prototype library

 The module contains some code generators for Prototype, the famous
 JavaScript OO library and the script.aculous extensions.
 
 The Prototype library (http://prototype.conio.net/) is designed to make
 AJAX easy. Catalyst::Plugin::Prototype makes it easy to connect to the
 Prototype library.
 
 This is mostly a port of the Ruby on Rails helper tags for JavaScript
 for use in Catalyst.
 

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.8-11-amd64-k8
Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2) (ignored: LC_ALL set to 
pl_PL)


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

Re: apt with index diff support

[Florian Weimer]

* Michael Vogt:

> Andreas Barth implemented the server side of the index diffs
> generation and has a test-repository (with only the index-files) at
> [3].

By the way, the secure-testing project on alioth contains a
moderately-tested pure-Python implementation of the client side
(without ed/red depedencies).  It's not a speed daemon, but it
significantly cuts down network traffic.

Thanks a lot for providing the necessary infrastructure.


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

Re: apt with index diff support

[Michael Vogt]

On Mon, Sep 12, 2005 at 10:11:34PM +0200, Florian Weimer wrote:
> * Michael Vogt:
> > Andreas Barth implemented the server side of the index diffs
> > generation and has a test-repository (with only the index-files) at
> > [3].
> 
> By the way, the secure-testing project on alioth contains a
> moderately-tested pure-Python implementation of the client side
> (without ed/red depedencies).  It's not a speed daemon, but it
> significantly cuts down network traffic.

Just to avoid confusion (and because it wasn't mentioned in the
original mail), the apt implementation has it's own rred-method (in
methods/rred.cc) and does not need a external ed/red.

Cheers,
 Michael
-- 
Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo


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

wnpp situation

[Nico Golde]

Hi,
If you go through the list of wnpp bugs you will see alot of 
open bugs which are very very old.
Especially the RFPs. What about closing an RFP bug 
automatically after the third semi automatic notice mail 
which is sent to the BTS entry?
Regards Nico

-- 
Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org 
VIM has two modes - the one in which it beeps 
and the one in which it doesn't -- encrypted mail preferred


pgpN7sbxoNBGj.pgp
Description: PGP signature

Re: wnpp situation

[Andrew Pollock]

On Tue, Sep 13, 2005 at 12:47:33AM +0200, Nico Golde wrote:
> Hi,
> If you go through the list of wnpp bugs you will see alot of 
> open bugs which are very very old.
> Especially the RFPs. What about closing an RFP bug 
> automatically after the third semi automatic notice mail 
> which is sent to the BTS entry?

Or have a cron job that automatically closes them after a period of
inactivity? With or without three automatic nags?

regards

Andrew


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

Re: wnpp situation

[Nico Golde]

Hi,
* Andrew Pollock <[EMAIL PROTECTED]> [2005-09-13 01:07]:
> On Tue, Sep 13, 2005 at 12:47:33AM +0200, Nico Golde wrote:
> > Hi,
> > If you go through the list of wnpp bugs you will see alot of 
> > open bugs which are very very old.
> > Especially the RFPs. What about closing an RFP bug 
> > automatically after the third semi automatic notice mail 
> > which is sent to the BTS entry?
> 
> Or have a cron job that automatically closes them after a period of
> inactivity? With or without three automatic nags?

Yes that another possibility. I think the only way to handle 
RFPs which makes sense is to give a period of time (a year 
or so) and if the bug has not been retilted to ITP in this 
time delete the RFP. In a year many things (licenses too :) 
can change in software development so if someone is 
interrested in a piece of software he can write a wnpp 
again. If nothing changes in this period of time upstream is 
inacive and the software shouldn't be packaged.
Regards Nico
-- 
Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org 
VIM has two modes - the one in which it beeps 
and the one in which it doesn't -- encrypted mail preferred


pgpsJnZAo1eeg.pgp
Description: PGP signature

GPL 2 Revision 3

[Joe Smith]

Have we updated the GPL in debian with the FSF new address?

As the address is for informational purposes the change is legally a no-op, 
and should be performed for convince. (Unless of course somebody objects to 
effectively changing a non-normative part of their license.) 




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

Re: wnpp situation

[Alexander Schmehl]

* Nico Golde <[EMAIL PROTECTED]> [050913 00:47]:

> Especially the RFPs. What about closing an RFP bug 
> automatically after the third semi automatic notice mail 
> which is sent to the BTS entry?

What is the purpose of this mail?  Either there is someone interested in
packaging it, or you won't find someone sooner with "Please someone do
something or we will close the bug" mails.  And if we have a definite
"RFPs are closed after n month inactivity" policy, everyone can easily
calculate, when such a bug is closed.

Close RFP after ... uhm... let's say 1 year inactivity and send the
submitter an apology, that we couldn't find a volunteer for the
requested package, should to very well.


Yours sincerely,
  Alexander

-- 
http://learn.to/quote/
http://www.catb.org/~esr/faqs/smart-questions.html


signature.asc
Description: Digital signature

Re: wnpp situation

[Lars Wirzenius]

ti, 2005-09-13 kello 01:45 +0200, Alexander Schmehl kirjoitti:
> Close RFP after ... uhm... let's say 1 year inactivity and send the
> submitter an apology, that we couldn't find a volunteer for the
> requested package, should to very well.

There was a discussion about closing old RFPs on -project in the middle
of July (around the 13th, I think). I really should get acting on the
consensus of that thread and close the old RFPs.


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

Re: GPL 2 Revision 3

[Christoph Berg]

Re: Joe Smith in <[EMAIL PROTECTED]>
> Have we updated the GPL in debian with the FSF new address?

Yes.

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


signature.asc
Description: Digital signature

Re: Bug#327081: ITP: rpmstrap -- bootstrap a basic RPM-based system

[Steve Langasek]

On Mon, Sep 12, 2005 at 02:19:09PM -0500, Sam Hart wrote:
> It actually was not my decision to GPLv2 it. I honestly didn't care what
> license it was released under. GPLv2 was just what the original base as
> written by Branden Robinson was copyrighted under.

> > > 1) Identical command-line options:
> > > 2) Placing of suite scripts inside of a "scripts/*" directory:
> > > 3) Making common functions available to suite scripts:

> > that you did seem to copy quite a bit from debootstrap anyway.

> No, I did not. Maintaining an identical interface and file layout is not
> copying code.

There are other things that are copyrightable besides code -- in
particular, usage/error messages (depending on their length and number)
are likely to be covered by copyright, and it's pretty implausible that
those would be the same between debootstrap and rpmstrap *without*
direct copying.

-- 
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: wnpp situation

[Brian Nelson]

Andrew Pollock <[EMAIL PROTECTED]> writes:

> On Tue, Sep 13, 2005 at 12:47:33AM +0200, Nico Golde wrote:
>> Hi,
>> If you go through the list of wnpp bugs you will see alot of 
>> open bugs which are very very old.
>> Especially the RFPs. What about closing an RFP bug 
>> automatically after the third semi automatic notice mail 
>> which is sent to the BTS entry?
>
> Or have a cron job that automatically closes them after a period of
> inactivity? With or without three automatic nags?

Or don't even open RFP bugs in the first place because they're
thoroughly useless?

-- 
Society is never going to make any progress until we all learn to
pretend to like each other.


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

Re: curl situation is intolerable

[Peter Samuelson]

  [Olaf van der Spek]
> > I thought that if the interface matches the user can link whatever
> > he wants, because he doesn't (re)distribute the results.

[Steve Langasek]
> There isn't universal agreement on this point, and it's never
> actually been tested in court.

There isn't?  I thought this has been standard GPL lore for a very long
time - if you link to an *interface* which has a GPL-compliant
implementation, it does not matter if you also are incidentally runtime-
compatible with a non-GPL-compatible implementation.

Some have argued back and forth about how useful or bug-free the
GPL-compliant implementation must be before it "counts", but that seems
not to be an issue here - both SSL backends are said to be functional,
if not 100% feature- and bug-equivalent.

From a common-sense standpoint, it's pretty hard to argue that some
software is "derived" from openssl if any user could run the same
binary with only gnutls on his system.


signature.asc
Description: Digital signature

Re: insighttoolkit2 is now available

[Guanglei Xiong]

Andreas Tille wrote:


On Mon, 12 Sep 2005, bear wrote:


dh_shlibdeps -a
dpkg-shlibdeps: warning: format of libitkzlib.so not recognized
dpkg-shlibdeps: warning: format of libitkzlib.so not recognized
dpkg-shlibdeps: warning: format of libitkjpeg8.so not recognized
dpkg-shlibdeps: warning: format of libitkzlib.so not recognized
dpkg-shlibdeps: warning: format of libitkzlib.so not recognized
dpkg-shlibdeps: warning: format of libitkjpeg8.so not recognized
dpkg-shlibdeps: warning: format of libitkjpeg12.so not recognized
dpkg-shlibdeps: warning: format of libitkjpeg16.so not recognized
...

Do you have any idea what's the problem with these libraries?



Sorry. I do now know the cause of this problem.



My guess is that something in the build process just went not the way it
should.  Moreover I suspect that cmake just does a bad job compared to
the autoconf / automake / libtool combination.  I have no idea about 
cmake

and do not know the reasons why it is prefered but I would like you to
ask on debian-devel for help in this case.


This toolkit chooses cmake mainly because it is portable to M$ Windows. 
Currently the
building process can be controlled by cmake. I will ask this problem of 
these warnings on debian-devel.




This should be no final reason not to upload the package but it just
should be solved for the future.


I move the examples to /usr/share/doc/insighttoolkit2-examples/examples



OK.

I wonder why a dev package is architecture all.  Normally it 
contains
headers *and* static libraries but obviousely there are no 
static libraries

builded at all.



Yes. There is no static libraries when choosing to build shared 
library in cmake.



Hmmm, you probably should have to separate build processes when building
the package: one which builds dynamic .so libraries for the runtime 
package

and another one for building the static *.a libraries.  Also in this case
libtool comes into mind which does this perfectly fine.

I think .a libraries are not necessary. Because .so libraries can be 
used in the development
of applications based on this toolkit. Besides, a similar package vtk in 
debian do the same thing.



libinsighttoolkit2:

I have no idea about cmake but it is really necessary to move
  /usr/lib/InsightToolkit/*.cmake
files into the binary package?



All .cmake files now is packaged in libinsighttoolkit2-dev



I guess they are used if you want to build something against the
toolkit, right?


Yes. They helps the cmake to do further configuration to ITK.



Kind regards

   Andreas.




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

Help on packaging insighttoolkit2

[Guanglei Xiong]

hi developers,

I have recently packaged insighttoolkit2 (www.itk.org) for Debian. The
packages are available on mentors.debian.net. There is a problem when
running "dh_shlibdeps -a" with warnings:

dpkg-shlibdeps: warning: format of libitkzlib.so not recognized
dpkg-shlibdeps: warning: format of libitkzlib.so not recognized
dpkg-shlibdeps: warning: format of libitkjpeg8.so not recognized
dpkg-shlibdeps: warning: format of libitkzlib.so not recognized
dpkg-shlibdeps: warning: format of libitkzlib.so not recognized
dpkg-shlibdeps: warning: format of libitkjpeg8.so not recognized
dpkg-shlibdeps: warning: format of libitkjpeg12.so not recognized
dpkg-shlibdeps: warning: format of libitkjpeg16.so not recognized

I am wondering if anyone can help me to check this package. Thanks!

Best regards,
Guanglei


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

Looking for historical package information

[Andrew Pollock]

Hi,

The debian/changelog for dhcp3 has a malformed first entry, which I'd like
to fix if possible.

I'm trying to determine the date and uploader of dhcpd (0.5.5-1) to
experimental, sometime around or before September 1996.

Is there anything useful stashed away somewhere that Google can't see?

regards

Andrew


signature.asc
Description: Digital signature

Re: insighttoolkit2 is now available

[Andreas Tille]

On Tue, 13 Sep 2005, Guanglei Xiong wrote:


Andreas Tille wrote:


On Mon, 12 Sep 2005, bear wrote:


dh_shlibdeps -a
dpkg-shlibdeps: warning: format of libitkzlib.so not recognized
dpkg-shlibdeps: warning: format of libitkzlib.so not recognized
dpkg-shlibdeps: warning: format of libitkjpeg8.so not recognized
dpkg-shlibdeps: warning: format of libitkzlib.so not recognized
dpkg-shlibdeps: warning: format of libitkzlib.so not recognized
dpkg-shlibdeps: warning: format of libitkjpeg8.so not recognized
dpkg-shlibdeps: warning: format of libitkjpeg12.so not recognized
dpkg-shlibdeps: warning: format of libitkjpeg16.so not recognized
...


This toolkit chooses cmake mainly because it is portable to M$ Windows.


Thanks for the explanation.  I was not aware that libtool is not portable.

I think .a libraries are not necessary. Because .so libraries can be used in 
the development of applications based on this toolkit.


Please see

  
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#id4747942



Besides, a similar package vtk in debian do the same thing.


Well, it does not really convince me that other examples exist.  IMHO the
static libraries are useful for debugging purpose but people her on this
list might be able to explain this in more detail.


Yes. They helps the cmake to do further configuration to ITK.


OK, this makes sense.

Kind regards

  Andreas.

--
http://fam-tille.de


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