Re: unreproducable bugs

[Antti-Juhani Kaijanaho]

On 20050716T195244-0700, Thomas Bushnell BSG wrote:
> That's a far cry different from someone wanting to enforce a
> requirement.

Who, in this thread, is this hypothetical someone?

As far as I can tell, this thread started with a simple question: is
there a policy for a certain thing?  There were a couple of honest
responses,  Then we have a lot of whining about how the younglings
cannot think for themselves from people who should know better, and a
mini-flamewar based on those thoughts, but I haven't seen anyone talking
about enforcing anything, until now.

Where did the old-fashioned practice of reading comprehension and
assuming good intentions (instead of stupidity or malice) go [1]?  (No, this
isn't directed solely, or even mainly, at you:)

[1] Yes, there are situations where you should assume malice, but
debian-devel discussions aren't one of them - and there is no situation
where assuming stupidity is better than assuming good intentions.
-- 
Antti-Juhani Kaijanaho, Debian developer 

http://kaijanaho.info/antti-juhani/blog/en/debian


signature.asc
Description: Digital signature

Re: unreproducable bugs

[Manoj Srivastava]

On Sun, 17 Jul 2005 10:11:34 +0300, Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> 
said: 

> On 20050716T195244-0700, Thomas Bushnell BSG wrote:
>> That's a far cry different from someone wanting to enforce a
>> requirement.

> Who, in this thread, is this hypothetical someone?

> As far as I can tell, this thread started with a simple question: is
> there a policy for a certain thing?  There were a couple of honest
> responses, Then we have a lot of whining about how the younglings
> cannot think for themselves from people who should know better, and
> a mini-flamewar based on those thoughts, but I haven't seen anyone
> talking about enforcing anything, until now.

> Where did the old-fashioned practice of reading comprehension and
> assuming good intentions (instead of stupidity or malice) go [1]?
> (No, this isn't directed solely, or even mainly, at you:)

A little reading comprehension on your part would help a bit
 here. Hint: dict policy would help.

The discussion started wuth a wuestion of _policy_. Once you
 comprehend what that word means, you'll see what Thomas meant.

manoj
-- 
What a COINCIDENCE!  I'm an authorized "SNOOTS OF THE STARS" dealer!!
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

is it a bug to not depend on a library package needed for some binary?

[Karl Chen]

Suppose package P contains files /usr/bin/B1 and /usr/bin/B2.  B1
is the important program, and B2 is not as important.  Is it OK
for the declared package dependencies to not satisfy all the
run-time shared library dependencies of B2?  What if they are
listed in Suggests?

I have found many such packages.

-- 
Karl 2005-07-17 01:09


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

Re: unreproducable bugs

[Antti-Juhani Kaijanaho]

On 20050717T025707-0500, Manoj Srivastava wrote:
> A little reading comprehension on your part would help a bit
>  here. Hint: dict policy would help.
> 
> The discussion started wuth a wuestion of _policy_. Once you
>  comprehend what that word means, you'll see what Thomas meant.

I distinctly remember you arguing that Policy is not a stick to
beat people with.  How then, in your opinion, could the mere mention of
the word "policy" imply wanting to enforce anything?

Assume the best possible motivations, please.  In this case, it could go
a long way if people would read "policy" as "the DDR" when such a
reading makes a question make perfect sense (and, if they must, politely
correct the error).  Some people actually did that.
-- 
Antti-Juhani Kaijanaho, Debian developer 

http://kaijanaho.info/antti-juhani/blog/en/debian


signature.asc
Description: Digital signature

Gutenprint entering unstable

[Roger Leigh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi folks,

Gutenprint (the new name for Gimp-Print 5.0) will enter unstable
today, and a number of changes come with it.

I have made a great deal of effort to ensure smooth upgrades, and it
was uploaded to experimental two weeks ago for further testing, but
there may be rough edges.  Please report any problems during or after
the upgrade to debian-printing, or file bugs against the appropriate
packages.

* CUPS (cupsys-driver-gimpprint) users should upgrade without problems
  (there's a dummy transitional package).  They might need to tweak
  the printer settings by hand afterwards.  If the colour balance is
  way out, you might want to replace the PPD with a new one (the
  settings are preserved from the old PPD, but these may no longer be
  optimal).

* ijsgimpprint users will be transitioned to ijsgutenprint with a
  dummy transition package.  However, any ijsgimpprint-using scripts
  or programs *will break*, due to the binary being renamed to
  ijsgutenprint.5.0.  These will need fixing.

* LPRng users may have problems, depending on their filter setup.
  Users of the gs 'stp' filter should switch to 'ijs' with the
  'ijsgutenprint.5.0' IJS server.  Users of the ijsgimpprint driver
  should switch to ijsgutenprint.5.0.

* Foomatic users should install the new Foomatic data
  (foomatic-db-gutenprint).  This does not yet conflict or replace the
  old foomatic-db-gimp-print, but may do so in the future if there is
  a need.

* gs-gpl and gs-esp *must* remove the STP patch.  If they don't, they
  will shortly FTBFS after libgimpprint1-dev is removed.

  There also appears to be an issue with the IJS driver: it won't
  allow the use of a symlink to a binary as the IJS server name.  The
  Gutenprint IJS server is installed as /usr/bin/ijsgutenprint.5.0.,
  but a symlink is provided as /usr/bin/ijsgutenprint for convenience
  (packagers should always use the versioned name).

* apsfilter must remove the STP option (currently marked deprecated),
  and the ijsgimpprint option must be renamed to ijsgutenprint.

The maintainer of the ijs and gutenprint source packages has been
changed to "Debian Printing Group <[EMAIL PROTECTED]>".
I am currently the only Uploader, but I would like to get them group
maintained, so any printing maintainers who are interested in either
should get in touch.

I would also highly recommend any maintainers of printing or
printing-related packages to subscribe to debian-printing.


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 

iD8DBQFC2iEoVcFcaSW/uEgRApDhAKCkcyVDqZMsqzTcAQ/WrCi6BYmCSACdFRpY
wPNrAxet12EOqGt4Z9kOLSA=
=r/d8
-END PGP SIGNATURE-


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

Re: FTBFS problems caused by texi2html changes

[Clint Adams]

> texi2html's behavior changed recently: if it is invoked with
> -split=chapter, old versions place the HTML files in the same
> directory as the documentation source, whereas new versions place the
> generated files in a subdirectory.

To get the old behavior, one can use

 --output . --split=chapter


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

Re: is it a bug to not depend on a library package needed for some binary?

[Goswin von Brederlow]

Karl Chen <[EMAIL PROTECTED]> writes:

> Suppose package P contains files /usr/bin/B1 and /usr/bin/B2.  B1
> is the important program, and B2 is not as important.  Is it OK
> for the declared package dependencies to not satisfy all the
> run-time shared library dependencies of B2?  What if they are
> listed in Suggests?
>
> I have found many such packages.

Any examples?

>From my gut I would say thats a serious policy violation and if P
can't depend on all libs it should be split into B1 and B2 packages
and B1 suggest B2.

If your examples are like B1 is a console program and B2 an X program
and P doesn't want to pull in X for console users then splitting is
the right thing to do. isdnutils would be example of having split due
to this in the past.

MfG
Goswin


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

Alioth upgrade

[Santiago Vila]

PLEASE, if you have something important to say to most developers,
use debian-devel-announce, not a message from "[EMAIL PROTECTED]"
with no special headers. That's dangerously near to being spam.

Yes, I know this rant is not new (I remember a similar one from Branden)
but apparently past rants about this have not been enough.

Thanks.


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

Reformatted Ubuntu Patches Repository

[Joachim Breitner]

Hi,

brought to you by the Utnubu team (that is me, still waiting for more
members, hint hint :-)), is the a newly formatted repository of Ubuntu
patches.

On http://utnubu.alioth.debian.org/scottish/by_maint/ you will find a
directory for each maintainer with modified packages, inside directories
for the kind of change (changelog_only, control_only, large), and then a
directory for the change. This data is pulled from 
http://people.ubuntu.com/~scott/patches/ but not yet automatically (I
will automate this, but not sure if I will have time for that here).

This is meant as a more convenient way for Debian maintainers to look
for possible useful patches from Ubuntu.

Greetings,
Joachim Breitner
-- 
Joachim "nomeata" Breitner
Debian Developer
  [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: [EMAIL PROTECTED] | http://people.debian.org/~nomeata



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

libcurl3-dev: A development package linked again gnutls needed

[Elimar Riesebieter]

Hi,

I am currently maintaining moc, a _m_usic _o_n _c_onsole player:

http://moc.daper.net
apt-cache show moc

The new version 2.3.0 needs libcurl-dev, 'cause streaming is
possible now. Start using libcurl, which depends on libssl, and
since GPL is incompatible with OpenSSL license, the package was
rejected upstream.  Checking the source of curl-package it is
possible to build curl --without-ssl and --with-gnutls=/usr. Should
we have a libcurl3-dev and a libcurl3-ssl-dev package or ist it more
comfortable to build curl against gnutls in general? Any hints?

BTW, I filed #318590 with no response 'til yet :(

Elimar

-- 
  Numeric stability is probably not all that 
  important when you're guessing;-)


pgpOh2BC5vlD8.pgp
Description: PGP signature

Re: Dependency problems with Xorg

[Harald Dunkel]

Goswin von Brederlow wrote:
> Harald Dunkel <[EMAIL PROTECTED]> writes:
> 
>>
>>But I can follow your argument. Dpkg should allow installing
>>different C++ abis on the same machine. Only within each
>>dependency chain the abi version number must be unique, so
>>it should become some kind of package attribute. This would
>>allow dpkg to verify the abi version.
> 
> 
> And that is what the c102 / c2 is about. :)
> 

I know, but as written before, IMHO the abi version number should
not be encoded in the package name. Usually you just get a new
abi, but no new functionality, so why introduce a new name? Just
to work around the limitations of dpkg? It is my suggestion to
extend dpkg instead.

Some packages don't follow this naming convention, anyway (e.g.
libglu1-xorg, libstdc++-4.0, others?).

> Say every package provides libfoobar-c++abi2 that would mean you would
> double the depends of every c++ package. Vou need versioned depends on
> libs and provides can't be versioned. So you need to depend on both
> the lib and the abi. Doesn't appending c2 sound better?
> 

No. Of course it is more difficult for dpkg to verify both package
dependencies and package attributes. But there are some differences
between the package dependency list and the package attributes:
The attributes must match exactly, and there is no recursion. It
is still a string compare, as with the package name.

> 
>>I just want to avoid that somebody else breaks the dependencies
>>of my package by dropping the old name and introducing a new one
>>for the same library, just because we changed a low level
>>interface that usually should be transparent to everybody.
> 
> 
> The break you get anyway. If the library provides a different c++ abi
> dpkg must not allow it to be used for your old package, no matter how
> you implement this.
> 

If the abi version gets a package attribute, then chances are high
that I just have to rebuild my package to support a new abi. If the
abi version gets encoded in the package name, then everybody with a
C++ package has to

- introduce a renamed package for the new abi
- change the dependencies of his package to catch the other
  new package names
- build the new package
- make the old package obsolete sometimes

Seems to be a lot of effort for something that should be hidden deep
inside.

> Hey, lets hope this is the last C++ transition ever. At least until
> g++ 4.1 :)
> 

What will happen if the abi changes just for one platform, lets
say for the Arm cpu? Does everybody have to rename his packages
again?


Regards

Harri


signature.asc
Description: OpenPGP digital signature

Re: Reformatted Ubuntu Patches Repository

[Javier Candeira]

Joachim, for the record:

YOU ROCK!!!

-- javier

Joachim Breitner wrote:
> Hi,
> 
> brought to you by the Utnubu team (that is me, still waiting for more
> members, hint hint :-)), is the a newly formatted repository of Ubuntu
> patches.
> 
> On http://utnubu.alioth.debian.org/scottish/by_maint/ you will find a
> directory for each maintainer with modified packages, inside directories
> for the kind of change (changelog_only, control_only, large), and then a
> directory for the change. This data is pulled from 
> http://people.ubuntu.com/~scott/patches/ but not yet automatically (I
> will automate this, but not sure if I will have time for that here).
> 
> This is meant as a more convenient way for Debian maintainers to look
> for possible useful patches from Ubuntu.
> 
> Greetings,
> Joachim Breitner


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

Re: Dependency problems with Xorg

[Goswin von Brederlow]

Harald Dunkel <[EMAIL PROTECTED]> writes:

> Goswin von Brederlow wrote:
>> Harald Dunkel <[EMAIL PROTECTED]> writes:
>> 
>>>
>>>But I can follow your argument. Dpkg should allow installing
>>>different C++ abis on the same machine. Only within each
>>>dependency chain the abi version number must be unique, so
>>>it should become some kind of package attribute. This would
>>>allow dpkg to verify the abi version.
>> 
>> 
>> And that is what the c102 / c2 is about. :)
>> 
>
> I know, but as written before, IMHO the abi version number should
> not be encoded in the package name. Usually you just get a new
> abi, but no new functionality, so why introduce a new name? Just
> to work around the limitations of dpkg? It is my suggestion to
> extend dpkg instead.

A dpkg extension is rather difficult to add and needs to be added to
stable before it can be used in unstable at all. If you can realy
think of something simpler than mangling the name add it now and
etch+1 can use it at the earliest.

> Some packages don't follow this naming convention, anyway (e.g.
> libglu1-xorg, libstdc++-4.0, others?).

libglu1 has a C abi while internaly it uses c++. It doesn't need a
transition. It actualy did do a transition (in the Provides) but that
will be reversed again.

libstdc++ doesn't follow the simple 'add c2' rule as it changes it
soversion at the same time: libstdc++-4, libstdc++-5, libstdc++-6. It
also needs to be installed in parallel with prior versions for
different g++ versions to work. So, since the library has a new name
anyway there is no point in also adding c102 or c2 on top of that.
It's all in the transition rules.

>> Say every package provides libfoobar-c++abi2 that would mean you would
>> double the depends of every c++ package. Vou need versioned depends on
>> libs and provides can't be versioned. So you need to depend on both
>> the lib and the abi. Doesn't appending c2 sound better?
>> 
>
> No. Of course it is more difficult for dpkg to verify both package
> dependencies and package attributes. But there are some differences
> between the package dependency list and the package attributes:
> The attributes must match exactly, and there is no recursion. It
> is still a string compare, as with the package name.
>
>> 
>>>I just want to avoid that somebody else breaks the dependencies
>>>of my package by dropping the old name and introducing a new one
>>>for the same library, just because we changed a low level
>>>interface that usually should be transparent to everybody.
>> 
>> 
>> The break you get anyway. If the library provides a different c++ abi
>> dpkg must not allow it to be used for your old package, no matter how
>> you implement this.
>> 
>
> If the abi version gets a package attribute, then chances are high
> that I just have to rebuild my package to support a new abi. If the
> abi version gets encoded in the package name, then everybody with a
> C++ package has to
>
> - introduce a renamed package for the new abi

You have to change some ABI field somewhere and update the shlibs file
to state the new ABI. That is basicaly the same work.

> - change the dependencies of his package to catch the other
>   new package names

Dependencies are done by shlibs. No change there.

You do have to change the Build-Depends to the -dev packages though,
increase the version to the first transitioned one.

Unless you find some magic to make dpkg and sbuild check the ABI of
the libs the -dev package is for you still have to change
Build-Depends.

And what ABI should it check for? What if I want to build for an older
ABI for oldlibs?

So would every source have to Build-Depend on the ABI it wants to
build for? Changing that is as difficult as changing the package name
and a lot less obvious. Note that the buildd system can Dep-Wait on
the new name but wouldn't have a clue about the ABI field.

Or would all the -dev packages Provide an ABI and conflict with all
other ABIs? Then you have to adjust those for every package again.

> - build the new package

Needs to be done anyway.

> - make the old package obsolete sometimes

??? The package becomes obsolete on it's own.

> Seems to be a lot of effort for something that should be hidden deep
> inside.

Let's put it this way: Renaming is proven to work well and is simple.
Anything else seems to need a lot of changes and extra thought to get
implemented the first time.

>> Hey, lets hope this is the last C++ transition ever. At least until
>> g++ 4.1 :)
>> 
>
> What will happen if the abi changes just for one platform, lets
> say for the Arm cpu? Does everybody have to rename his packages
> again?

Yes and no. Depends.

E.g. parts of the C ABI have changed for m68k and hppa but the porters
will have to deal with that transition on their own without a global
renaming scheme.

> Regards
>
> Harri

MfG
Goswin


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

Re: Dependency problems with Xorg

[Daniel Stone]

On Sun, Jul 17, 2005 at 04:28:56PM +0200, Harald Dunkel wrote:
> I know, but as written before, IMHO the abi version number should
> not be encoded in the package name. Usually you just get a new
> abi, but no new functionality, so why introduce a new name? Just
> to work around the limitations of dpkg? It is my suggestion to
> extend dpkg instead.

Look, nice theory, but we're dealing with the realities of Debian today.


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

linuxsampler/libgig: intent to hijack

[Paul Brossier]

Hi,

linuxsampler has been FTBFS since its first upload, is now
uninstallable, and requires a rebuild against the latest g++.

Matt, are you still interested in maintaining this package? and libgig?
if not, i would be interested to adopt them.

cheers, piem 


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

Re: libcurl3-dev: A development package linked again gnutls needed

[Marco d'Itri]

On Jul 17, Elimar Riesebieter <[EMAIL PROTECTED]> wrote:

> comfortable to build curl against gnutls in general? Any hints?
Upstream developers should get a clue and either properly license their
software, stop using libcurl or adding gnutls support to it.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

lsb-base

[Marco d'Itri]

I am considering switching the init scripts of my packages to lsb-base
(which means that it will have to be promoted to important priority, at
least).
If anybody has objections please voice them now.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: unreproducable bugs

[Manoj Srivastava]

On Sun, 17 Jul 2005 11:35:14 +0300, Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> 
said: 

> On 20050717T025707-0500, Manoj Srivastava wrote:
>> A little reading comprehension on your part would help a bit
>> here. Hint: dict policy would help.
>> 
>> The discussion started wuth a wuestion of _policy_. Once you
>> comprehend what that word means, you'll see what Thomas meant.

> I distinctly remember you arguing that Policy is not a stick to beat
> people with.  How then, in your opinion, could the mere mention of
> the word "policy" imply wanting to enforce anything?

I can see what you mean about reading comprehension. I say
 that when people want to put things into policy to beat people in the
 head with. You see, then something is in policy, you are supposed to
 pay attention to it, since otherwise there is no point in having
 a policy at all.


Secondly, not all policy in the world, or even in Debian, is
 in the Debian technical policy document; indeed, the unadorned word
 policy still has meaning, commonly accepted as in the wider world.

> Assume the best possible motivations, please.  In this case, it
> could go a long way if people would read "policy" as "the DDR" when
> such a reading makes a question make perfect sense (and, if they
> must, politely correct the error).  Some people actually did that.

Yeah, it could also go away if people read "policy" to mean
 the movie I saw yesterday.  However, if you want to communicate,
 people need to have a common understanding of what a word
 means. Unless, like Clinton, your sentences depends on what the
 meaning of the word "is" is.


As to good intentions, the road to hell is paved with  good
 intentions; and the good intent is no reason to suspend critical
 thinking. 

manoj
-- 
It will be advantageous to cross the great stream ... the Dragon is on
the wing in the Sky ... the Great Man rouses himself to his Work.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: aspell dictionary packages fail to build

[Brian Nelson]

On Thu, Jul 14, 2005 at 04:34:05PM -0700, Matt Kraai wrote:
> Howdy,
> 
> The aspell dictionary packages build-depend on aspell-bin (>> 0.60).
> aspell-bin is now a virtual package provided by aspell, but virtual
> packages cannot be versioned, so these build-dependency cannot be
> satisfied.
> 
> There are fifteen such packages:

Actually, it's worse than that.  Almost every aspell dictionary package
is broken right now.

[...]
> Should I file bugs against each of these packages?  Should I contact
> the maintainers directly via email?  Should I email d-d-a?

Normally, I would have contacted the maintainers beforehand about the
breakage.  However, Agustin and I are currently finalizing support for
building the dictionary hashes at install time.  Once that's ready, the
plan is to transition all of the dictionary packages to use the hash
building sytem.

You may start filing bugs against each of aspell dictionaries (minus
aspell-en, aspell-es, and possibly a couple others) if you'd like, but I
suggest that the maintainers wait to fix the bugs until Agustin and I
have written a dictionary transition document.

-- 
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: linuxsampler/libgig: intent to hijack

[Matt Flax]

Hi Paul,

I am currently deep in the tail end of my PhD at the moment. I would 
really appreciate co-developer ownership, where I can return to duty 
with you on these packages once I have a little more time. Probably 
about next year some time.

I still have a few others to maintain as well as these, which happen to 
be a bit less active and alot more managable.

I have left some shell packaing scripts in the 'README.debian' file... I 
don't know but perhaps they will help ? I was building straight from CVS 
by the way.

I will put up a request for adoption on wnpp if that is necessary.

thanks
Matt

On Sun, Jul 17, 2005 at 04:56:09PM +0100, Paul Brossier wrote:
> Hi,
> 
> linuxsampler has been FTBFS since its first upload, is now
> uninstallable, and requires a rebuild against the latest g++.
> 
> Matt, are you still interested in maintaining this package? and libgig?
> if not, i would be interested to adopt them.
> 
> cheers, piem 

-- 
http://www.flatmax.org

Public Projects :
http://sourceforge.net/search/?type_of_search=soft&words=mffm


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

Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)

[Elimar Riesebieter]

On Sun, 17 Jul 2005 the mental interface of
Marco d'Itri told:

> On Jul 17, Elimar Riesebieter <[EMAIL PROTECTED]> wrote:
> 
> > comfortable to build curl against gnutls in general? Any hints?
> Upstream developers should get a clue and either properly license their
> software, stop using libcurl or adding gnutls support to it.
I don't see a gpl'd alternative to curl for internet streaming. I am
thinking about to build moc --without-curl then :(

What about the fbi-package, raptor-utils-package and others who are using
libcurl3 as well?

Elimar


-- 
  Learned men are the cisterns of knowledge, 
  not the fountainheads ;-)


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

Re: is it a bug to not depend on a library package needed for some binary?

[Martijn van Oosterhout]

2005/7/17, Goswin von Brederlow <[EMAIL PROTECTED]>:
> Karl Chen <[EMAIL PROTECTED]> writes:
> 
> > Suppose package P contains files /usr/bin/B1 and /usr/bin/B2.  B1
> > is the important program, and B2 is not as important.  Is it OK
> > for the declared package dependencies to not satisfy all the
> > run-time shared library dependencies of B2?  What if they are
> > listed in Suggests?
> >
> > I have found many such packages.
> 
> Any examples?
> 
> From my gut I would say thats a serious policy violation and if P
> can't depend on all libs it should be split into B1 and B2 packages
> and B1 suggest B2.
> 
> If your examples are like B1 is a console program and B2 an X program
> and P doesn't want to pull in X for console users then splitting is
> the right thing to do. isdnutils would be example of having split due
> to this in the past.

Let say, hypothetically, the maintainer made a script called
/usr/bin/B2 which would check for the dependancies. If they're not
present error out with a message "please install program Y". If they
are present, exec the original.

Would this still be a policy violation?

Re: lsb-base

[Petter Reinholdtsen]

[Marco d'Itri]
> I am considering switching the init scripts of my packages to
> lsb-base (which means that it will have to be promoted to important
> priority, at least).
> If anybody has objections please voice them now.

I already did this for discover1, but did this in a way to make it use
lsb-base only if it is installed.

I used this code to make lsb-base optional, and used the lsb functions
for output:

  if [ -f /lib/lsb/init-functions ]; then
. /lib/lsb/init-functions
  else
log_begin_msg()   { echo "$@"; }
log_success_msg() { echo "$@"; }
log_warning_msg() { echo "$@"; }
  fi

Perhaps an idea for you too?


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

Re: is it a bug to not depend on a library package needed for some binary?

[Goswin von Brederlow]

Martijn van Oosterhout <[EMAIL PROTECTED]> writes:

> 2005/7/17, Goswin von Brederlow <[EMAIL PROTECTED]>:
>> Karl Chen <[EMAIL PROTECTED]> writes:
>> 
>> > Suppose package P contains files /usr/bin/B1 and /usr/bin/B2.  B1
>> > is the important program, and B2 is not as important.  Is it OK
>> > for the declared package dependencies to not satisfy all the
>> > run-time shared library dependencies of B2?  What if they are
>> > listed in Suggests?
>> >
>> > I have found many such packages.
>> 
>> Any examples?
>> 
>> From my gut I would say thats a serious policy violation and if P
>> can't depend on all libs it should be split into B1 and B2 packages
>> and B1 suggest B2.
>> 
>> If your examples are like B1 is a console program and B2 an X program
>> and P doesn't want to pull in X for console users then splitting is
>> the right thing to do. isdnutils would be example of having split due
>> to this in the past.
>
> Let say, hypothetically, the maintainer made a script called
> /usr/bin/B2 which would check for the dependancies. If they're not
> present error out with a message "please install program Y". If they
> are present, exec the original.
>
> Would this still be a policy violation?

Probably not. But damn anoying. If it is a binary that just fails with
a linker error then I would definetly report a bug.

For a few K script on top of a say 1MB package splitting out that one
script wouldn't be sensible.

On the other hand if Y is a say 10K package itself depending on it as
well doesn't hurt anyone, does it?

It's all relative. If you can see a good reason to violate policy then
even that can be allowed.

MfG
Goswin


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

Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)

[sean finney]

On Sun, Jul 17, 2005 at 08:21:00PM +0200, Elimar Riesebieter wrote:
> I don't see a gpl'd alternative to curl for internet streaming. I am
> thinking about to build moc --without-curl then :(

or you could always contact the author and inform them of their
self-inflicted license violation.  in my experience, many authors
don't realize the licensing problem and are more than willing to
relicense/dual license/add exceptions for stuff like openssl.

> What about the fbi-package, raptor-utils-package and others who are using
> libcurl3 as well?

if they are strict gpl and use libcurl, you should report bugs against them.


sean

-- 


signature.asc
Description: Digital signature

Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)

[Elimar Riesebieter]

On Sun, 17 Jul 2005 the mental interface of
sean finney told:

> On Sun, Jul 17, 2005 at 08:21:00PM +0200, Elimar Riesebieter wrote:
> > I don't see a gpl'd alternative to curl for internet streaming. I am
> > thinking about to build moc --without-curl then :(
> 
> or you could always contact the author and inform them of their
> self-inflicted license violation.  in my experience, many authors
> don't realize the licensing problem and are more than willing to
> relicense/dual license/add exceptions for stuff like openssl.
> 
> > What about the fbi-package, raptor-utils-package and others who are using
> > libcurl3 as well?
> 
> if they are strict gpl and use libcurl, you should report bugs against them.

Damian can't. I asked him.

Why not building curl --without-sssl and --with-gnutls=/usr? Maybe a
NMU?

Elimar


-- 
  "Talking much about oneself can also 
   be a means to conceal oneself."
 -Friedrich Nietzsche


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

Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)

[sean finney]

On Sun, Jul 17, 2005 at 09:04:57PM +0200, Elimar Riesebieter wrote:
> Why not building curl --without-sssl and --with-gnutls=/usr? Maybe a
> NMU?

this is definitely NOT a reason to NMU libcurl.  remember that it is
your package that is "broken".  of course you could still file a
wishlist bug against libcurl asking to compile against gnutls
instead, but it's up to the maintainer in question to decide.

sean

-- 


signature.asc
Description: Digital signature

Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)

[Elimar Riesebieter]

On Sun, 17 Jul 2005 the mental interface of
sean finney told:

> On Sun, Jul 17, 2005 at 08:21:00PM +0200, Elimar Riesebieter wrote:
> > I don't see a gpl'd alternative to curl for internet streaming. I am
> > thinking about to build moc --without-curl then :(
> 
> or you could always contact the author and inform them of their
> self-inflicted license violation.  in my experience, many authors
> don't realize the licensing problem and are more than willing to
> relicense/dual license/add exceptions for stuff like openssl.
> 
> > What about the fbi-package, raptor-utils-package and others who are using
> > libcurl3 as well?
> 
> if they are strict gpl and use libcurl, you should report bugs against them.

apt-get remove --purge libssl0.9.7 gives me tons of packages. Just
an estimation: We need to repack half of all packages then?

Elimar


-- 
  Planung:
  Ersatz des Zufalls durch den Irrtum.
-unknown-


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

Re: lsb-base

[Thomas Hood]

On Sun, 17 Jul 2005 20:33:40 +0200, Petter Reinholdtsen wrote:
> I used this code to make lsb-base optional, and used the lsb functions
> for output:
> 
>   if [ -f /lib/lsb/init-functions ]; then
> . /lib/lsb/init-functions
>   else
> log_begin_msg()   { echo "$@"; }
> log_success_msg() { echo "$@"; }
> log_warning_msg() { echo "$@"; }
>   fi
> 
> Perhaps an idea for you too?


The package is only 20 kbytes installed.  Let's just start Depending on it.

-- 
Thomas Hood


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

Re: lsb-base

[Petter Reinholdtsen]

[Thomas Hood]
> The package is only 20 kbytes installed.  Let's just start Depending on it.

I agree.  We should start using the LSB, not just talk about trying to
be LSB conforming. :)

But I made the use optional for discover1 because someone complained
and said it was just a fancy way to get colors in the boot screen, and
besides lsb-base is not a commonly installed package yet.  I believe
it is a good idea to standardize the init.d message reporting, to make
it easier to redirect them to a common location, and believe using the
lsb-base functions is a step in the right direction.


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

Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)

[Don Armstrong]

On Sun, 17 Jul 2005, Elimar Riesebieter wrote:
> apt-get remove --purge libssl0.9.7 gives me tons of packages. Just
> an estimation: We need to repack half of all packages then?

NO.[1]

All that needs to happen is that GPLed packages without an OpenSSL
linking exception either need to:

  1) Get a linking exception.

  2) Stop linking with OpenSSL.

Nothing more needs to be done.


Don Armstrong

1: This has been seriously discussed in hideous detail at least 10
times already. The list archives are your friend.
-- 
Grimble left his mother in the food store and went to the launderette
and watched the clothes go round. It was a bit like colour television
only with less plot.
 -- Clement Freud _Grimble_

http://www.donarmstrong.com  http://rzlab.ucr.edu


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

Removal of transitional dummy packages

[Mohammed Adnène Trojette]

Hello Debian mainainers,

In accordance with the Etch wishlist^wTODOList[1], we need to remove
from the archive all the Woody-to-Sarge transition dummy packages.

This is why Clément Stenac and I have tried to establish a list of the
packages to be removed[2]. This[3] page also explains how the list was
built.

If one of your packages is listed here[2], please remove it from your
control file and ask ftp-masters for its removal from the archive by
filing a bug on ftp.debian.org (of course, we might have made some
mistakes computing this list, please contact us
on  should you have any question/remark.)

In a few weeks, we'll start filing RC bugs against the remaining
packages.

Consequently, the less remain, the easier the job will be.

Thanks for your cooperation!

[1] http://wiki.debian.net/?EtchTODOList
[2] http://adn.diwi.org/wiki/index.php/DummyPackagesList
[3] http://adn.diwi.org/wiki/index.php/DummyPackagesStatus 

-- 
Clément Stenac
Mohammed Adnène Trojette


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

Re: lsb-base

[Marco d'Itri]

On Jul 17, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote:

> I already did this for discover1, but did this in a way to make it use
> lsb-base only if it is installed.
I can't see the point. The package is tiny, so if it should be used then
everybody should install it.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

debconf5 - videos of the talks and BOFs available

[Holger Levsen]

Hi,

"the mighty video team", in boring alphabetical order (but you who where there 
know who they are), Andrew McMillan, Chris Halls, Erik Johansson,  Henning 
Sprang, Herman Robak, Holger Levsen, Javier Candeira, John Lightsey,
Kalle Boess, Martin Langhoff, Noel Koethe, Peter de Schrijver, Tore S Bekkedal
is proud to announce the availability of (most of, atm) the videos of the 
officially scheduled talks and BOFs at debconf5.  

Jeroen van Wolffelaar and Tuukka Hastrup were not really part of the team, but 
still deserve special mentioning for their participation... Of course those 
videos would not have been possible without all the others (...) who made 
debconf5 the special event it was - it's not completly over as I type this, 
but almost.

Please note, that not all videos are available _now_. The ones missing will be 
released when they're ready :-) We hope this is soon, but you have take into 
consideration, that some of us worked >16h a day - so we might need some time 
to recover.

Well, 'nuff said for the moment, dudette, the videos are and will be here: 
http://dc5video.debian.net 


regards,
Holger  


pgp5n9joNViqX.pgp
Description: PGP signature

Re: Removal of transitional dummy packages

[Adeodato Simó]

* Mohammed Adnène Trojette [Sun, 17 Jul 2005 22:46:19 +0200]:

> Hello Debian mainainers,

  Hi!

> [2] http://adn.diwi.org/wiki/index.php/DummyPackagesList
> [3] http://adn.diwi.org/wiki/index.php/DummyPackagesStatus 

  This two pages are asking for authentification. I guess this is not
  intended?

  Thanks for your initiative,

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
In Italy, for 30 years under the Borgias they had warfare, terror,
murder, bloodshed, but they produced Michelangelo, Leonardo da Vinci, and
the Renaissance. In Switzerland they had brotherly love - they had 500
years of democracy and peace, and what did that produce? The cuckoo clock.
-- Harry Lime in “The Third Man”


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

Re: Removal of transitional dummy packages

[Mohammed Adnène Trojette]

On Sun, Jul 17, 2005, Adeodato Simó wrote:
>   This two pages are asking for authentification. I guess this is not
>   intended?

Oops! It should be fixed ;-)
Thanks.

PS: I read the list.

-- 
adn
Mohammed Adnène Trojette


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

Re: Removal of transitional dummy packages

[Santiago Vila]

On Sun, 17 Jul 2005, Mohammed Adnène Trojette wrote:

> Hello Debian mainainers,
> 
> In accordance with the Etch wishlist^wTODOList[1],

Do not confuse a personal wishlist with a real todo list.

> we need to remove
> from the archive all the Woody-to-Sarge transition dummy packages.

No, that's not true, we don't *need* to remove woody-to-sarge dummy
packages, as they are also woody-to-etch dummy packages.

> This is why Clément Stenac and I have tried to establish a list of the
> packages to be removed[2]. This[3] page also explains how the list was
> built.
> 
> If one of your packages is listed here[2], please remove it from your
> control file and ask ftp-masters for its removal from the archive by
> filing a bug on ftp.debian.org (of course, we might have made some
> mistakes computing this list, please contact us
> on  should you have any question/remark.)
> 
> In a few weeks, we'll start filing RC bugs against the remaining
> packages.

RC bug? What the heck are you talking about?

You can argue that we don't have a clear and defined policy about how
long "should" a dummy package be kept in the archives, but it is
definitely *not* in policy that dummy packages *have* to be removed
after one release.

Please do not make "policy" by submitting bugs.

Re: is it a bug to not depend on a library package needed for some binary?

[Matthew Woodcraft]

Karl Chen <[EMAIL PROTECTED]> wrote:
>Suppose package P contains files /usr/bin/B1 and /usr/bin/B2.  B1
>is the important program, and B2 is not as important.  Is it OK
>for the declared package dependencies to not satisfy all the
>run-time shared library dependencies of B2?  What if they are
>listed in Suggests?

There is a lot of discussion of this question in bug 119517 (where the
conclusion reached was that this is sometimes ok).

-M-


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

Re: Removal of transitional dummy packages

[Joerg Jaspert]

On 10353 March 1977, Santiago Vila wrote:

>> we need to remove
>> from the archive all the Woody-to-Sarge transition dummy packages.
> No, that's not true, we don't *need* to remove woody-to-sarge dummy
> packages, as they are also woody-to-etch dummy packages.

We do not support that. No. So yes, woody->sarge packages should be
removed, there is no reason to keep them. Upgrades from woody go via
sarge and then to etch.

>> In a few weeks, we'll start filing RC bugs against the remaining
>> packages.
> RC bug? What the heck are you talking about?

No RC Bug, normal severity. If its a dummy out of an (now) empty source
package, then ftp.debian.org Bug with CC to maintainer could be better.

> You can argue that we don't have a clear and defined policy about how
> long "should" a dummy package be kept in the archives, but it is
> definitely *not* in policy that dummy packages *have* to be removed
> after one release.

As we only support upgrades to the next release and not any other its
very clear to remove them from the archive.

-- 
bye Joerg
 Ganneff: NM-queue ist das schnellste zu uploadrechten für ein paket,
oder?
 ach aqua^Wribnitz


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

Re: Alioth upgrade

[Raphael Hertzog]

Hi,

Le dimanche 17 juillet 2005 à 13:13 +0200, Santiago Vila a écrit :
> PLEASE, if you have something important to say to most developers,
> use debian-devel-announce, not a message from "[EMAIL PROTECTED]"
> with no special headers. That's dangerously near to being spam.
> 
> Yes, I know this rant is not new (I remember a similar one from Branden)
> but apparently past rants about this have not been enough.

I have also been surprised by the mail but Wichert probably used
alioth's "Mass mailing" feature. If you want to avoid that in the
future, feel free to provide a patch on gforge. :-)

Source code (with changes specific to alioth) is available in 
alioth.debian.org:~lolando/gforge+alioth/

Cheers,
-- 
Raphaël Hertzog -+- http://www.ouaza.com
Formation Linux et logiciel libre : http://www.logidee.com
Earn money with free software: http://www.geniustrader.org


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

Re: Removal of transitional dummy packages

[Santiago Vila]

On Sun, 17 Jul 2005, Joerg Jaspert wrote:

> On 10353 March 1977, Santiago Vila wrote:
>
> >> we need to remove
> >> from the archive all the Woody-to-Sarge transition dummy packages.
> > No, that's not true, we don't *need* to remove woody-to-sarge dummy
> > packages, as they are also woody-to-etch dummy packages.
>
> We do not support that.

There is no "we" here. You don't want to support them for your packages?
Fine, they are your packages, but I support them for my packages (see
Bug #312336 for example). So there is no "we".


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

Re: linuxsampler/libgig: intent to hijack

[Paul Brossier]

Hi Matt,

On Mon, Jul 18, 2005 at 03:18:52AM +1000, Matt Flax wrote:
> Hi Paul,
> 
> I am currently deep in the tail end of my PhD at the moment. I would 
> really appreciate co-developer ownership, where I can return to duty 
> with you on these packages once I have a little more time. Probably 
> about next year some time.

cool, good luck with your PhD. 

yes, co-maintainance would be nice. I'll will prepare an upload for
linuxsampler.

bye, piem.

> I still have a few others to maintain as well as these, which happen to 
> be a bit less active and alot more managable.
> 
> I have left some shell packaing scripts in the 'README.debian' file... I 
> don't know but perhaps they will help ? I was building straight from CVS 
> by the way.
> 
> I will put up a request for adoption on wnpp if that is necessary.
> 
> thanks
> Matt
> 
> On Sun, Jul 17, 2005 at 04:56:09PM +0100, Paul Brossier wrote:
> > Hi,
> > 
> > linuxsampler has been FTBFS since its first upload, is now
> > uninstallable, and requires a rebuild against the latest g++.
> > 
> > Matt, are you still interested in maintaining this package? and libgig?
> > if not, i would be interested to adopt them.
> > 
> > cheers, piem 
> 
> -- 
> http://www.flatmax.org
> 
> Public Projects :
> http://sourceforge.net/search/?type_of_search=soft&words=mffm
> 
> 


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

Re: is it a bug to not depend on a library package needed for some binary?

[Hamish Moffatt]

On Sun, Jul 17, 2005 at 12:46:03PM +0200, Goswin von Brederlow wrote:
> If your examples are like B1 is a console program and B2 an X program
> and P doesn't want to pull in X for console users then splitting is
> the right thing to do. isdnutils would be example of having split due
> to this in the past.

Policy (11.8.1) says that you should only split your package into X and
non-X parts if it is higher priority than the X libraries (which are
optional). isdnutils doesn't seem to qualify.


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


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

Re: is it a bug to not depend on a library package needed for some binary?

[Goswin von Brederlow]

Hamish Moffatt <[EMAIL PROTECTED]> writes:

> On Sun, Jul 17, 2005 at 12:46:03PM +0200, Goswin von Brederlow wrote:
>> If your examples are like B1 is a console program and B2 an X program
>> and P doesn't want to pull in X for console users then splitting is
>> the right thing to do. isdnutils would be example of having split due
>> to this in the past.
>
> Policy (11.8.1) says that you should only split your package into X and
> non-X parts if it is higher priority than the X libraries (which are
> optional). isdnutils doesn't seem to qualify.
>
>
> Hamish
> -- 
> Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

People with their small headless isdn routers didn't feel like
installing X on them just to be able to install isdn-utils at all.

Enough people wished for a split and it was done.

MfG
Goswin


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

Re: is it a bug to not depend on a library package needed for some binary?

[Hamish Moffatt]

On Mon, Jul 18, 2005 at 01:55:48AM +0200, Goswin von Brederlow wrote:
> Hamish Moffatt <[EMAIL PROTECTED]> writes:
> > On Sun, Jul 17, 2005 at 12:46:03PM +0200, Goswin von Brederlow wrote:
> >> If your examples are like B1 is a console program and B2 an X program
> >> and P doesn't want to pull in X for console users then splitting is
> >> the right thing to do. isdnutils would be example of having split due
> >> to this in the past.
> >
> > Policy (11.8.1) says that you should only split your package into X and
> > non-X parts if it is higher priority than the X libraries (which are
> > optional). isdnutils doesn't seem to qualify.
> 
> People with their small headless isdn routers didn't feel like
> installing X on them just to be able to install isdn-utils at all.
> 
> Enough people wished for a split and it was done.

The previous version of 11.8.1 was a bit less forgiving (changed in
1999). Anyway you are not obligated to install X but only some
libraries.


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


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

NMUs wanted: C++ library packages in need of uploading

[Steve Langasek]

Below is a list of libraries which appear to be blocking other packages that
need to go through the C++ transition[1] and which are themselves ready to
go through the ABI transition.  These packages should be uploaded ASAP,
either by maintainer upload or NMU; even though no bugs have been filed,
this is a release-critical issue for all of these packages, because
rebuilding the libraries (e.g., for a security NMU) with the current default
compiler will break all applications depending on the lib, so now that it's
begun, this transition should be treated with the highest of priorities.

Per Matthias' mail, it's open season for 0-day NMUs on any of these
packages.  Of course, there's no sense in working on an NMU if the
maintainer already has the matter in hand, so please make an effort to
coordinate with the maintainer and with other NMUers.  To minimize
duplication of effort, I recommend opening a bug report (severity: serious)
*and* replying to this thread stating your intention to upload any of the
packages on this list.  In addition, please verify that the library you're
uploading hasn't already been transitioned by the maintainer, by checking
both the NEW queue on ftp-master[2] and the status of any new versions in
unstable before uploading.  Remember that not all libraries will have 'c2'
in their package name after the transition!

Other rules of NMUing apply as always, including making sure you've sent the
patch to the BTS before sending the package to the upload queue.  Since the
BTS mail interface is down at the moment due to maintenance, as an
additional courtesy you may want to cc: the maintainer directly on any such
mails.

If someone else takes the library you had your eyes on, leaving you with no
other libraries to NMU, don't worry; not only will there be several more
rounds of libraries (and applications) in need of upload, there is also a
list of nearly 550 packages at[3] that have RC bugs that could use some
attention -- many of them also bugs caused by the transition to a new, more
strict version of gcc.

libccaudio
libccscript
libchipcard
libcrypto++
libgwenhywfar
libinti1.0
libktoblzcheck
libmodplug
libmusicbrainz-2.1
libparagui1.0
librudiments0
libsdl-sge
libsigcx
libtagcoll
libxbase
libxml++
maxdb-7.5.00
omniorb4
openbabel
socketapi
stlport4.6
strutilsxx
taglib
wfmath
wxwindows2.4
xplc
zipios++


Cheers,
-- 
Steve Langasek
postmodern programmer

[1] http://lists.debian.org/debian-devel-announce/2005/07/msg1.html
[2] http://ftp-master.debian.org/new.html
[3] 
http://bts.turmzimmer.net/details.php?ignore=sid&ignnew=on&pseudopackages=on&new=7&refresh=900


signature.asc
Description: Digital signature

Re: NMUs wanted: C++ library packages in need of uploading

[Steve Langasek]

On Sun, Jul 17, 2005 at 06:54:42PM -0700, Steve Langasek wrote:
> In addition, please verify that the library you're uploading hasn't
> already been transitioned by the maintainer, by checking both the NEW
> queue on ftp-master[2] and the status of any new versions in unstable
> before uploading.  Remember that not all libraries will have 'c2'
> in their package name after the transition!

Case in point, the wxwindows2.4 maintainer has already uploaded a new
version for the ABI transition.  So please don't go NMUing it. :)

This means that rapidsvn and tqslib can be added to the list of libs to be
uploaded instead.

Cheers,
-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: skills of developers

[Manoj Srivastava]

On Sat, 16 Jul 2005 16:38:20 +0200, Torsten Landschoff <[EMAIL PROTECTED]> 
said: 

> Hi *, What kind of discussion is this?

This is a discussion about project quality.

> We can't effort more bureaucrazy (typo intended) in the project. Let
> the people doing the work do the work instead of first measuring
> their ability.

This is quite possibly the silliest thing I have ever heard.
 Please, people, before taking on a task that users depend on  you to
 perform well,  _do_ assess whether you are up to the task.  There is
 no shame in acknowledging that you do not have to skills to maintain
 something (you'll not find a python package in my stable, nor
 haskel, not a slew of other languages I have no skill with).

If you do not have the skillset to perform a task, or the
 time, ***DO NOT VOLUNTEER TO TAKE IT ON***.  By doing so, someone
 better able to perform that task would not do so

Find something else to maintain. There are 10,000 or so source
 packages out there, I am sure you can find something you feel capable
 of doing.  Doing a bad job (and, as a maintainer, you can't do
 anything _but_ a bad job if you can't help debuag/develop a package)
 is not really better than doing something else.


> And critical packages are assigned anyway so why bother that much?

It is not just critical packages that deserve quality of
 implementation.  We have problems enough with ill maintained packages
 to start encouraging people to do so.

manoj
-- 
In the next world, you're on your own.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: unreproducable bugs

[Matthew Palmer]

On Fri, Jul 15, 2005 at 01:54:48PM -0400, kamaraju kusumanchi wrote:
> Manoj Srivastava wrote:
> >On Fri, 15 Jul 2005 15:42:44 +0200, Nico Golde <[EMAIL PROTECTED]> said: 
> >   What's with the recent push to get every little things written
> >down into policy, so the developer no longer is required to have an
> >ability to think, or exercise any judgement whatsoever?
>
> Dont know about others. But whenever I post some question on irc or a 
> mailing list the most frequent answer is 'it is there in the policy', 
> 'go by the policy', 'read the policy' etc., Similar answers would have 
> made other people think that "all Debian maintainers/developers should 
> go by the policy and only by the policy".

I'd suggest checking the usual suspects (Policy, DevRef, NM Guide, etc)
before asking questions.  Then, when people give you those sorts of answers,
you can confidently say "no it's not, go eat your hat".

- Matt


signature.asc
Description: Digital signature

Re: unreproducable bugs

[Thomas Bushnell BSG]

Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> writes:

> On 20050716T195244-0700, Thomas Bushnell BSG wrote:
>> That's a far cry different from someone wanting to enforce a
>> requirement.
>
> Who, in this thread, is this hypothetical someone?

Right.  Manoj asked: why should we have a requirement?  Someone said
"here's why!" and I am simply pointing out that you can get what he
wanted without a requirement.


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

Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)

[Peter Samuelson]

[Don Armstrong]
> All that needs to happen is that GPLed packages without an OpenSSL
> linking exception either need to:
> 
>   1) Get a linking exception.
>   2) Stop linking with OpenSSL.

3) For indirect dependencies: make sure you're only using the bits
   of the (for example) libcurl ABI which work whether or not it is
   compiled against openssl.  In that case it's really hard to
   argue you're "linking to openssl".


signature.asc
Description: Digital signature

Re: Removal of transitional dummy packages

[Christian Perrier]

> >> In a few weeks, we'll start filing RC bugs against the remaining
> >> packages.
> > RC bug? What the heck are you talking about?
> 
> No RC Bug, normal severity. If its a dummy out of an (now) empty source


I also agree with the severity to be normal.

Which could, btw, have been said in a more kind manner to Mohamed,
instead of the quite rude sentence above from Santiago.

After a week of Debconf friendlyness, I see that we might easily fall
again in our usual flaming style.

Debconfs should be mandatory events..:-)

As I use to say : I will no more be able to flame someone I've been
naked with in a finnish sauna



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