Re: Misc development news (#6)

[Andreas Tille]

On Tue, 15 Apr 2008, Raphael Hertzog wrote:


"Someday someone should do this..."
---

Sometimes I stumble on interesting or useful ideas on mailingslists,
which should be done, but the person having that in mind, doesn't have
time to do those. So I came up with idea of a wiki page, where those
tasks could be collected, so that people willing to do some useful work
(for example because they are in NM and need to prove their skills) can
maybe find some.

I've started collecting some on http://wiki.debian.org/NMTasks and would
be happy if you'd also use this page, to collect such ideas (in a form
other people are able to understand) or to pick those ideas and implement
them.

 -- Holger Levsen


Good idea.  I just added screenshots.debian.org idea that came up on
some discussion at Chemnitzer LinuxTage in March.  It would be nice if
somebody would grab this up - at least the idea will not just vanish
now it is stored somewhere ...

Kind regards

  Andreas.

--
http://fam-tille.de


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

Bug#476346: ITP: libmatio -- A library to read and write Matlab MAT files

[Sylvestre Ledru]

Package: wnpp
Severity: wishlist
Owner: Sylvestre Ledru <[EMAIL PROTECTED]>


* Package name: libmatio
  Version : 1.3.2
  Upstream Author : Christopher Hulbert <[EMAIL PROTECTED]>
* URL : http://sourceforge.net/projects/mati
* License : LGPL
  Programming Lang: C
  Description : A library to read and write Matlab MAT files

 matio is an ISO C library (with a limited Fortran 90 interface) for
 reading and writing Matlab MAT files.

-- System Information:
Debian Release: lenny/sid
  APT prefers gutsy
  APT policy: (500, 'gutsy'), (500, 'unstable'), (500, 'testing'), (500, 
'stable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores)
Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash



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

Re: RFH: Multiarch capable toolchain as release goal

[Marc Haber]

On Wed, 16 Apr 2008 06:24:09 +0200, Goswin von Brederlow
<[EMAIL PROTECTED]> wrote:
>Ove Kaaven <[EMAIL PROTECTED]> writes:
>> The way I understand it, they HAVE been pushing... and pushing... for
>> a long time... against a nonresponsive binutils maintainer. This
>> thread is just their latest, last-ditch effort since nothing else
>> worked so far. But I could be wrong, I guess.
>
>You are right. The patch has been around for years and requests for any
>response to the patch have just been ignored.

Why did I guess the name of binutils' maintainer correctly _before_
looking into the PTS?

I bet that multiarch gets included into Ubuntu about two weeks after
we released lenny without multiarch.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Should -dev packages providing .pc files depend on pkg-config?

[Goswin von Brederlow]

Tollef Fog Heen <[EMAIL PROTECTED]> writes:

> * Hendrik Sattler 
>
> | Am Samstag 05 April 2008 schrieb Tollef Fog Heen:
> | > Whoever develops software based on libbar will have to have a call to
> | > pkg-config somewhere in their build process so they should depend on
> | > pkg-config.
> | 
> | _If_ they do. Please consider the possibility that an application
> | developer links to libbar without using pkg-config. pkg-config is
> | _not_ part of an API, it is only a tool that _can_ be used, not
> | must.
>
> That depends on the library you are linking against.  I, as an library
> author is free to say «the only supported way to use my gargleblaster
> library is through the I_CAN_HAS_GARGELBLASTER autoconf macro» (which
> then proceeds to set GARGLEBLASTER_CFLAGS and GARGLEBLASTER_LIBS by
> using pkg-config).  If I do that, pkg-config is effectively part of
> the API.

I would go one step further. Imho libraries with *.pc files should say
"the only supported way to use this lib is by using pkg-config". And
as such the *-dev package should depend on pkg-config as that is the
only proper way to use the package. What I'm saying is that the
library should make it a requirement and therefore depends which is
not the same as saying it has to be. It just should imho.

> | Putting pkg-config on Recommends of Suggests of every -dev packages
> | that has a .pc file, you could as well put it into built-essential
> | dependency.

How would a Recommends or Suggests even help? Sure, users would get
the pkg-config installed. But buildds don't, right? So sources would
still FTBFS and would have to Build-Depend on pkg-config even if they
only call some autoconf macro from the *-dev package.

MfG
Goswin


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

Re: RFH: Multiarch capable toolchain as release goal

[Goswin von Brederlow]

Luk Claes <[EMAIL PROTECTED]> writes:

> Goswin von Brederlow wrote:
>> Ove Kaaven <[EMAIL PROTECTED]> writes:
>>> The way I understand it, they HAVE been pushing... and pushing... for
>>> a long time... against a nonresponsive binutils maintainer. This
>>> thread is just their latest, last-ditch effort since nothing else
>>> worked so far. But I could be wrong, I guess.
>> 
>> You are right. The patch has been around for years and requests for any
>> response to the patch have just been ignored.
>
> According to the bug log the patch was not ready when the maintainer
> wanted to apply it and nobody bothered to start an NMU process...
>
> Cheers
>
> Luk

What bug are you reading?

Sat, 27 May 2006 10:16:36 +0200: initial report with patch
Wed, 21 Jun 2006 00:48:26 +0200: NMU attempt gets vetoed
Wed, 28 Jun 2006 11:01:53 +0200: 2. maintainer misunderstands the patch
Thu, 29 Jun 2006 22:44:30 +0200: some discussion about the misunderstanding
Mon, 11 Sep 2006 15:58:28 +0200: patch update for the i386->i486 ABI change
Sun, 29 Apr 2007 00:12:48 +0200: prodding the maintainer for an reaction
Thu, 28 Jun 2007 03:43:16 +0100: first real reply by maintainer
Mon, 02 Jul 2007 19:14:35 +0200: patch fix for issues raise by maintainer
Thu, 26 Jul 2007 15:56:45 +0200: patch split into the ABI and multiarch parts

An NMU was tried and it and all future NMU where vetoed by the maintainer.

In summary:

- 13 month from initial report to raising a minor issue that has no
  negative effects on the functionality
- 4 days to fix the issue
- 9 month without reaction and counting

In that time (packages.qa.d.o only goes back to 2007-04-06) there have
been over 20 uploads of binutils. And all we get is ONE test of the
patch with no followup on the fix we send?

MfG
Goswin


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

Re: a small program for Fritz!Box owner

[Simon Richter]

Hi,

> I wrote a small program for Fritz!Box owners and I was wondering if
> anyone would like to maintain it. It is a small tray program that shows
> a notificatin on outgoing or incoming phonecalls. It has been written
> for GNOME, but also works with KDE. The tool currently runs in English
> or in German.

I might be interested. Just Debian maintenance or helping with upstream
tasks as well?

   Simon


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

Re: Should -dev packages providing .pc files depend on pkg-config?

[Neil Williams]

On Wed, 2008-04-16 at 09:33 +0200, Goswin von Brederlow wrote:
> Tollef Fog Heen <[EMAIL PROTECTED]> writes:
> >
> > That depends on the library you are linking against.  I, as an library
> > author is free to say «the only supported way to use my gargleblaster
> > library is through the I_CAN_HAS_GARGELBLASTER autoconf macro» (which
> > then proceeds to set GARGLEBLASTER_CFLAGS and GARGLEBLASTER_LIBS by
> > using pkg-config).  If I do that, pkg-config is effectively part of
> > the API.
> 
> I would go one step further. Imho libraries with *.pc files should say
> "the only supported way to use this lib is by using pkg-config".

No - because not all libraries restrict support to only pkg-config and
there is no good reason to force an option to become a requirement. Just
because a .pc file exists, does not mean it is the only supported method
- it can be, but it does not have to be. *IF* .pc is the only supported
method, then pkg-config is part of the API as above and the -dev
dependency is justifiable.

However, IMHO, the onus is on the source package to ensure
that /usr/bin/pkg-config is available if the source package upstream
requires it.

>  And
> as such the *-dev package should depend on pkg-config as that is the
> only proper way to use the package. What I'm saying is that the
> library should make it a requirement and therefore depends which is
> not the same as saying it has to be. It just should imho.

Why? The presence of a .pc file is *not* an indicator that pkg-config is
essential for that library or -dev, it can be optional. Some libraries
may only support pkg-config, others have the option to package a .pc
file for those who want it but let other users handle the relevant data
directly. Indeed, handling the data separately can be a useful way of
removing unwanted dependencies in the final application.

The package that *must* depend on pkg-config (build-depend) is the
package that runs a ./configure script expecting /usr/bin/pkg-config to
exist and without any fallback code if it does not exist.

> > | Putting pkg-config on Recommends of Suggests of every -dev packages
> > | that has a .pc file, you could as well put it into built-essential
> > | dependency.
> 
> How would a Recommends or Suggests even help? Sure, users would get
> the pkg-config installed. But buildds don't, right? So sources would
> still FTBFS and would have to Build-Depend on pkg-config even if they
> only call some autoconf macro from the *-dev package.

What about these clauses as a Policy amendment?

1. If a library *only supports the retrieval of FOO_LIBS and / or
FOO_CFLAGS by the use of pkg-config*, pkg-config becomes part of the API
of that library and the -dev package of that library must depend on
pkg-config. The mere presence of a .pc file in the -dev package of the
library does *not* mean that only pkg-config is supported. e.g. where a
library requires the use of an m4 macro that involves calling
pkg-config, this would require the -dev package to depend on pkg-config
but if a library provides a .pc file but also supports alternative
method(s), the -dev package does not need to depend on pkg-config.

2. If a source package uses libraries that package a .pc but where all
the libraries also support other methods of obtaining the relevant data,
and the source package requires the use of pkg-config despite those
other methods being available, then that choice by the source package
upstream must result in a Build-Depends on pkg-config in the source
package.

Is that suitable as a Policy clause? (probably needs a few tweaks for
clarity and examples in clause 1). It may well cause a few packages to
depend or build-depend on pkg-config even though another dependency also
requires it but duplication of dependencies is not a problem.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




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

Re: RFH: Multiarch capable toolchain as release goal

[Bernhard R. Link]

* Lennart Sorensen <[EMAIL PROTECTED]> [080415 21:57]:
> Now I suppose sparc and others might still like it if they have
> performance advantages of 32bit code over 64bit code, in which case
> keeping 64bit for only those programs where the extra address space is
> worth it would be great.

I guess most long-year sparc users are by now against any multiarch
stuff by bad experience. Having 64 bit libraries installed on sparc
was always the best way to get a broken system. Every other year
some directory changes to a symlink, or a symlink to a directory,
changes it name from ultra to sparc64 or there is some other reason
breaking your upgrades. So at least I try as good as I can to avoid
anything with the threathening "64" in its name.

Hochachtungsvoll,
Bernhard R. Link


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

Re: Misc development news (#6)

[Simon Richter]

Hi,

>  Since dpkg 1.14.17, dpkg-buildpackage will define the environment
>  variables CFLAGS, CXXFLAGS, CPPFLAGS, LDFLAGS and FFLAGS. The goal is to
>  be able to easily recompile packages with supplementary compilation flags
>  and to simplify the debian/rules files since CFLAGS has the right default
>  value (no need to special case for DEB_BUILD_OPTIONS=noopt).

This sounds like a bad idea to me, as it communicates instructions
(CFLAGS) along with intent (DEB_BUILD_OPTIONS). How is a package
supposed to behave if these differ, or even detect that it is asked to
do something that is wonky?

   Simon


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

Re: Misc development news (#6)

[Sune Vuorela]

On 2008-04-16, Thomas Weber <[EMAIL PROTECTED]> wrote:
> This isn't helpful for several reasons:
> a) Burying this information in a wiki where people may or may not read
> it in time (I just reverted a change already done in SVN).

I got the idea of pushing it out when Hertzog was talking about sending
it developer news out - so it was buried in the wiki for like 1-2 hours.


> b) What is the current/next revision of qt4-x11 at the time of writing
> (ie, is this still valid or already obsoleted)?

current is 4.4~rc1-3. Next is 4.4~rc1-4 which is just hit incoming for
amd64 arch.

/Sune


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

Re: Misc development news (#6)

[Thomas Weber]

Am Dienstag, den 15.04.2008, 22:58 +0200 schrieb Raphael Hertzog:
> FTFBS on packages build-depending on libqt4-dev
> ---
> 
>  If your package is build-depending on libqt4-dev and is currently failing
>  to build from sources, please wait for the next qt4-x11 package revision
>  before adding a gazillion of build-deps to your package.
> 
>   -- Sune Vuorela

This isn't helpful for several reasons:
a) Burying this information in a wiki where people may or may not read
it in time (I just reverted a change already done in SVN).
b) What is the current/next revision of qt4-x11 at the time of writing
(ie, is this still valid or already obsoleted)?

Thomas



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

uploading new binary packages from a DM approved source package

[Ondrej Certik]

Hi,

if I want to packge a new upstream version of DM-Upload-Allowed
library (for example [1]), it changes the name of the binary package
and thus goes to NEW.

Last time I asked it wasn't possible for me, as a DM, to upload it and
I had to search for a sponsor.

Is there some policital reason for that, or is it just because noone
has yet implemented it in the scripts? If the latter case, how can I
help?

Ondrej

[1] http://packages.debian.org/source/sid/libmesh


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

Re: uploading new binary packages from a DM approved source package

[Bas Wijnen]

Hi,

On Wed, Apr 16, 2008 at 01:08:05PM +0200, Ondrej Certik wrote:
> if I want to packge a new upstream version of DM-Upload-Allowed
> library (for example [1]), it changes the name of the binary package
> and thus goes to NEW.
> 
> Last time I asked it wasn't possible for me, as a DM, to upload it and
> I had to search for a sponsor.
> 
> Is there some policital reason for that,

Yes.  DMs are not as thoroughly checked as DDs, and thus have less
rights to change things in the archive.  The idea is that they should be
allowed to upload packages they already maintain, but not add new ones.
This is true both for new source, and new binary packages.

A library soname transition is a binary package name change for
technical reasons.  IMO there isn't really a good reason to send them
through NEW at all, but that's how the scripts work.  And it's not that
bad, it makes sure there's an extra check on each soname bump, which can
be useful.  It does also mean that DMs need a sponsor for the upload,
but that should be acceptable as well.

> or is it just because noone has yet implemented it in the scripts? If
> the latter case, how can I help?

If you can build consensus on the fact that soname bumps shouldn't go
through NEW, then you could implement that technically.  But I don't
think you will be able to.  In fact, most people might well think that
soname bumps should indeed go through NEW, and that that is not a bug.

Personally I didn't really think about it.  I've never considered it a
problem, but wouldn't consider it a problem if they don't go through NEW
either.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: uploading new binary packages from a DM approved source package

[Ondrej Certik]

On Wed, Apr 16, 2008 at 1:34 PM, Bas Wijnen <[EMAIL PROTECTED]> wrote:
> Hi,
>
>
>  On Wed, Apr 16, 2008 at 01:08:05PM +0200, Ondrej Certik wrote:
>  > if I want to packge a new upstream version of DM-Upload-Allowed
>  > library (for example [1]), it changes the name of the binary package
>  > and thus goes to NEW.
>  >
>  > Last time I asked it wasn't possible for me, as a DM, to upload it and
>  > I had to search for a sponsor.
>  >
>  > Is there some policital reason for that,
>
>  Yes.  DMs are not as thoroughly checked as DDs, and thus have less
>  rights to change things in the archive.  The idea is that they should be
>  allowed to upload packages they already maintain, but not add new ones.
>  This is true both for new source, and new binary packages.

I completely agree they shouldn't be able to add new packages.

>
>  A library soname transition is a binary package name change for
>  technical reasons.

Exactly, that's why I think it could be resolved somehow, see for
example my suggestion below.

> IMO there isn't really a good reason to send them
>  through NEW at all, but that's how the scripts work.  And it's not that
>  bad, it makes sure there's an extra check on each soname bump, which can
>  be useful.  It does also mean that DMs need a sponsor for the upload,
>  but that should be acceptable as well.
>
>
>  > or is it just because noone has yet implemented it in the scripts? If
>  > the latter case, how can I help?
>
>  If you can build consensus on the fact that soname bumps shouldn't go
>  through NEW, then you could implement that technically.  But I don't
>  think you will be able to.  In fact, most people might well think that
>  soname bumps should indeed go through NEW, and that that is not a bug.
>
>  Personally I didn't really think about it.  I've never considered it a
>  problem, but wouldn't consider it a problem if they don't go through NEW
>  either.

Right. Well, how about changing the DM scripts to allow DMs to upload
new sonames to NEW? (And only new sonames). I.e. not accepting
completely new binary package (and of course not accepting a new
source package).

That way it will still be checked and yet the DM will not have to
search for a sponsor.

Ondrej


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

How to manage security issues when the maintainer is not the developer

[Andrea De Iacovo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all.

How do you think a maintainer should manage security issues when he is
not the package developer? Should he/she either work alone to make
patches or wait for the upstream patches/relases that solve the bug?

Andrea De Iacovo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIBejnMXahCK22/rwRAhl3AJ9/rP8FFSVqvz1+8bQu1PZHCLGjGQCfZQJ7
zCofl8Z64XpvIRBQklhQ3gQ=
=WToO
-END PGP SIGNATURE-


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

Re: How to manage security issues when the maintainer is not the developer

[Mark Brown]

On Wed, Apr 16, 2008 at 01:55:51PM +0200, Andrea De Iacovo wrote:

> How do you think a maintainer should manage security issues when he is
> not the package developer? Should he/she either work alone to make
> patches or wait for the upstream patches/relases that solve the bug?

As ever, the best thing tends to be to work with upstream.  If the issue
is an upstream one then upstream really needs to be involved in getting
the fix released.

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


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

Re: How to manage security issues when the maintainer is not the developer

[Neil Williams]

On Wed, 2008-04-16 at 13:55 +0200, Andrea De Iacovo wrote:
> Hi all.
> 
> How do you think a maintainer should manage security issues when he is
> not the package developer? Should he/she either work alone to make
> patches or wait for the upstream patches/relases that solve the bug?

Notify upstream, work on the patch and stay in communication with
upstream as you work.

If you get a response from upstream, work together to come up with a
complete solution but don't let that process cause undue delay to fixing
the problem (especially close to a release, as now).

If upstream are busy with other things, solve the problem yourself and
make the upload - ask the security team for help with that side if you
are unsure.

Solve the problem - if upstream come back to you with a different fix
later, you can always migrate to that fix.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




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

Bright Paul wants to chat

[Bright Paul]

---

Bright Paul wants to stay in better touch using some of Google's coolest new
products.

If you already have Gmail or Google Talk, visit:
http://mail.google.com/mail/b-adfe2d3c11-5bc346a7b5-261400fbee2be624
You'll need to click this link to be able to chat with Bright Paul.

To get Gmail - a free email account from Google with over 2,800 megabytes of
storage - and chat with Bright Paul, visit:
http://mail.google.com/mail/a-adfe2d3c11-5bc346a7b5-0f37bd0f91

Gmail offers:
- Instant messaging right inside Gmail
- Powerful spam protection
- Built-in search for finding your messages and a helpful way of organizing
  emails into "conversations"
- No pop-up ads or untargeted banners - just text ads and related information
  that are relevant to the content of your messages

All this, and its yours for free. But wait, there's more! By opening a Gmail
account, you also get access to Google Talk, Google's instant messaging
service:

http://www.google.com/talk/

Google Talk offers:
- Web-based chat that you can use anywhere, without a download
- A contact list that's synchronized with your Gmail account
- Free, high quality PC-to-PC voice calls when you download the Google Talk
  client

Gmail and Google Talk are still in beta. We're working hard to add new features
and make improvements, so we might also ask for your comments and suggestions
periodically. We appreciate your help in making our products even better!

Thanks,
The Google Team

To learn more about Gmail and Google Talk, visit:
http://mail.google.com/mail/help/about.html
http://www.google.com/talk/about.html

(If clicking the URLs in this message does not work, copy and paste them into
the address bar of your browser).


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

Re: Bug#476340: ITP: datapacker -- Tool to pack files into minimum number of CDs/DVDs/etc

[brian m. carlson]

On Tue, Apr 15, 2008 at 10:50:23PM -0500, John Goerzen wrote:

Package: wnpp
Severity: wishlist
Owner: John Goerzen <[EMAIL PROTECTED]>

* Package name: datapacker
 Version : 1.0.0
 Upstream Author : John Goerzen <[EMAIL PROTECTED]>
* URL : http://software.complete.org/datapacker
* License : GPL
 Programming Lang: Haskell
 Description : Tool to pack files into minimum number of CDs/DVDs/etc
datapacker is a tool to group files by size. It is
designed to group files such that they fill fixed-size containers
(called "bins") using the minimum number of containers.


This sounds suspiciously like the knapsack problem, which is in NP.  Is 
it guaranteed to use the minimum number, or are there cases when it 
would not?  If the former, I'm sure Merkle and Hellman would like to 
hear from you. ;-)


--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Should SONAME bumps always go through NEW

[Neil Williams]

On Wed, 2008-04-16 at 13:34 +0200, Bas Wijnen wrote:
> On Wed, Apr 16, 2008 at 01:08:05PM +0200, Ondrej Certik wrote:
> > if I want to packge a new upstream version of DM-Upload-Allowed
> > library (for example [1]), it changes the name of the binary package
> > and thus goes to NEW.
> > 
> > Last time I asked it wasn't possible for me, as a DM, to upload it and
> > I had to search for a sponsor.

(and that is just as it should be).

> > Is there some policital reason for that,
> 
> Yes.  DMs are not as thoroughly checked as DDs, and thus have less
> rights to change things in the archive.  The idea is that they should be
> allowed to upload packages they already maintain, but not add new ones.
> This is true both for new source, and new binary packages.

What kind of new binary package can be more disruptive than a SONAME
bump??? The restrictions exist for good technical reasons. SONAME bumps
need careful management across a number of different packages.

> A library soname transition is a binary package name change for
> technical reasons.  IMO there isn't really a good reason to send them
> through NEW at all, but that's how the scripts work. 

It does give others watching NEW a chance to see a pending transition -
bumping a SONAME should not be done lightly (especially now). I think
that is a good reason.

> If you can build consensus on the fact that soname bumps shouldn't go
> through NEW, then you could implement that technically. 

Personally, I think that SONAME bumps in NEW get "fast-tracked" through
the queue anyway and I think it is a worthwhile safeguard that should be
retained. If SONAME bumps are not to go through NEW in the future, I
think it should be mandatory that SONAME bumps go through some other
"holding" phase instead - there should be technical restrictions on
library transitions and that DM's should still not be allowed to make
uploads that involve a SONAME bump. Such a "holding" phase would just be
another name for NEW anyway, hence I think it should stay as-is.

Dropping this merely for the convenience of DM's when the real problem
is delays in NM is trying to fix the wrong problem in the wrong place,
IMHO.

>  But I don't
> think you will be able to.  In fact, most people might well think that
> soname bumps should indeed go through NEW, and that that is not a bug.

:-) Most definitely not a bug, IMHO.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




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

Re: How to manage security issues when the maintainer is not the developer

[Lars Wirzenius]

On ke, 2008-04-16 at 13:55 +0200, Andrea De Iacovo wrote:
> How do you think a maintainer should manage security issues when he is
> not the package developer? Should he/she either work alone to make
> patches or wait for the upstream patches/relases that solve the bug?

If the package maintainer in Debian can do something to make a security
problem be fixed faster, they should do that. If they can provide the
patch themselves, good. If they can't do that, perhaps they can help or
encourage or recruit someone else to do that, also good. If nobody can
do anything, bad.

The point is to get the problem fixed, not to worry about whose
responsibility it is or who gets the credit or what makes someone look
bad.



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

GnuPG: Maintainer inactive?

[Kai Wasserbäch]

Hello,
on the 1st of April I wrote an e-mail to James Troup offering my help in hunting
down open bugs which are no longer present an thus enabling him to concentrate
on packaging GnuPG 1.4.9. But his last action regarding this package is well
over an year old and the only updates I can see in the PTS were made by the
Security Team. And before I forget to write it: I didn't receive an answer.
So my question is: Is James known to be inactive? Are there others currently on
the task to get a new version (upstream has 1.4.9) into Debian? Is there
anything I can help (I'm certainly not suitable as a maintainer for that package
myself, because it's too essential to be entrusted to someone who is unknown to
(nearly) all people on this list) with, e.g. by triaging bugs?

Should this question already have been discussed somewhere, please point me to 
it.

Thank you in advance for your reply(s).

Kind regards,
Kai Wasserbäch



-- 

Kai Wasserbäch (Kai Wasserbaech)

E-Mail: [EMAIL PROTECTED]
Jabber (debianforum.de): Drizzt
URL: http://wiki.debianforum.de/Drizzt_Do%27Urden
GnuPG: 0xE1DE59D2  0600 96CE F3C8 E733 E5B6 1587 A309 D76C E1DE 59D2
(http://pgpkeys.pca.dfn.de/pks/lookup?search=0xE1DE59D2&fingerprint=on&hash=on&op=vindex)



signature.asc
Description: OpenPGP digital signature

Re: Misc development news (#6)

[Roberto C . Sánchez]

On Wed, Apr 16, 2008 at 08:38:16AM +0200, Andreas Tille wrote:
> On Tue, 15 Apr 2008, Raphael Hertzog wrote:
> 
> >"Someday someone should do this..."
> >---
> >
> >Sometimes I stumble on interesting or useful ideas on mailingslists,
> >which should be done, but the person having that in mind, doesn't have
> >time to do those. So I came up with idea of a wiki page, where those
> >tasks could be collected, so that people willing to do some useful work
> >(for example because they are in NM and need to prove their skills) can
> >maybe find some.
> >
> >I've started collecting some on http://wiki.debian.org/NMTasks and would
> >be happy if you'd also use this page, to collect such ideas (in a form
> >other people are able to understand) or to pick those ideas and implement
> >them.
> >
> > -- Holger Levsen
> 
> Good idea.  I just added screenshots.debian.org idea that came up on
> some discussion at Chemnitzer LinuxTage in March.  It would be nice if
> somebody would grab this up - at least the idea will not just vanish
> now it is stored somewhere ...
> 
This is something that I propsed on January 3, 2007, on debian-devel.
There was a fairly lengthy thread that resulted and Thomas Viehmann even
offered to help.  Of course, he and I both became very busy and so it
sort of fell by the wayside.  However, I have my projects much better in
hand this year and I intend to resurrect the idea early this summer.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: GnuPG: Maintainer inactive?

[Michael Banck]

On Wed, Apr 16, 2008 at 02:19:12PM +0200, Kai Wasserbäch wrote:
> on the 1st of April I wrote an e-mail to James Troup offering my help in 
> hunting
> down open bugs which are no longer present an thus enabling him to concentrate
> on packaging GnuPG 1.4.9. But his last action regarding this package is well
> over an year old and the only updates I can see in the PTS were made by the
> Security Team. And before I forget to write it: I didn't receive an answer.
> So my question is: Is James known to be inactive? Are there others currently 
> on
> the task to get a new version (upstream has 1.4.9) into Debian? Is there
> anything I can help (I'm certainly not suitable as a maintainer for that 
> package
> myself, because it's too essential to be entrusted to someone who is unknown 
> to
> (nearly) all people on this list) with, e.g. by triaging bugs?
 
I guess triaging bugs (i.e. marking bugs which have been fixed upstream
in newer versions as "fixed-upstream" or mention bugs which can be
closed already cause they are fixed in the current version in the
appropriate bug (CCing the submitter, so they can possibly close it
themselves) is always welcome, regardless of any other action or
non-action by the maintainer.


Michael


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

Re: Misc development news (#6)

[Holger Levsen]

Hi Roberto,

On Wednesday 16 April 2008 15:24, Roberto C. Sánchez wrote:
> This is something that I propsed on January 3, 2007, on debian-devel.
> There was a fairly lengthy thread that resulted and Thomas Viehmann even
> offered to help.  Of course, he and I both became very busy and so it
> sort of fell by the wayside.  However, I have my projects much better in
> hand this year and I intend to resurrect the idea early this summer.

Cool.

I've changed the contact address Andreas put there into "Contact: AndreasTille 
or Roberto C. Sánchez <[EMAIL PROTECTED]> - Roberto intends to work on 
it..." - feel free to change further :-)


regards,
Holger


pgpl0InoFZ2pn.pgp
Description: PGP signature

Re: Should SONAME bumps always go through NEW

[Ondrej Certik]

On Wed, Apr 16, 2008 at 2:27 PM, Neil Williams <[EMAIL PROTECTED]> wrote:
> On Wed, 2008-04-16 at 13:34 +0200, Bas Wijnen wrote:
>  > On Wed, Apr 16, 2008 at 01:08:05PM +0200, Ondrej Certik wrote:
>  > > if I want to packge a new upstream version of DM-Upload-Allowed
>  > > library (for example [1]), it changes the name of the binary package
>  > > and thus goes to NEW.
>  > >
>  > > Last time I asked it wasn't possible for me, as a DM, to upload it and
>  > > I had to search for a sponsor.
>
>  (and that is just as it should be).
>
>  > > Is there some policital reason for that,
>  >
>  > Yes.  DMs are not as thoroughly checked as DDs, and thus have less
>  > rights to change things in the archive.  The idea is that they should be
>  > allowed to upload packages they already maintain, but not add new ones.
>  > This is true both for new source, and new binary packages.
>
>  What kind of new binary package can be more disruptive than a SONAME
>  bump??? The restrictions exist for good technical reasons. SONAME bumps
>  need careful management across a number of different packages.
>
>  > A library soname transition is a binary package name change for
>  > technical reasons.  IMO there isn't really a good reason to send them
>  > through NEW at all, but that's how the scripts work.
>
>  It does give others watching NEW a chance to see a pending transition -
>  bumping a SONAME should not be done lightly (especially now). I think
>  that is a good reason.
>
>  > If you can build consensus on the fact that soname bumps shouldn't go
>  > through NEW, then you could implement that technically.
>
>  Personally, I think that SONAME bumps in NEW get "fast-tracked" through
>  the queue anyway and I think it is a worthwhile safeguard that should be
>  retained. If SONAME bumps are not to go through NEW in the future, I
>  think it should be mandatory that SONAME bumps go through some other
>  "holding" phase instead - there should be technical restrictions on
>  library transitions and that DM's should still not be allowed to make
>  uploads that involve a SONAME bump. Such a "holding" phase would just be
>  another name for NEW anyway, hence I think it should stay as-is.
>
>  Dropping this merely for the convenience of DM's when the real problem
>  is delays in NM is trying to fix the wrong problem in the wrong place,
>  IMHO.


Thanks for the reply. As I said, I am not questioning new SONAME bumps
going into NEW.

The question is, whether the DMs should be allowed to upload SONAME
bumps to NEW by themselves or not. I agree there should be a special
attention to SONAME bumps and that's what the NEW is for (or any other
queue as you said).

It's all about how much trust you give to DMs. Imho if they are
allowed to upload new revisions and even new upstream (if the name of
all the binaries and the number of them stays the same), they can
screw up a lot of things. So giving them the right to also upload new
binary packages to NEW imho belongs to the same cathegory. Either you
trust him to maintain the package, or not. Imho.

Ondrej


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

Re: RFH: Multiarch capable toolchain as release goal

[Mikhail Gusarov]

Twas brillig at 10:01:53 16.04.2008 UTC+02 when Goswin von Brederlow did gyre 
and gimble:

 GvB> Luk Claes <[EMAIL PROTECTED]> writes:

 GvB> - 13 month from initial report to raising a minor issue that has no
 GvB>   negative effects on the functionality
 GvB> - 4 days to fix the issue
 GvB> - 9 month without reaction and counting

Seems to be a good candidate for raising the question to ctte (in first
several month).

-- 


pgpdInlcEQtce.pgp
Description: PGP signature

Re: Misc development news (#6) (DEB_BUILD_OPTIONS=noopt)

[Raphael Hertzog]

On Wed, 16 Apr 2008, Darren Salt wrote:
> I'd rather that this just got left in debian/rules, where it belongs:
> xine-lib, for example, needs more than just -O0 for disabling optimisations.

You can keep it there for special cases like this one.

But I disagree that debian/rules is necessarily the place where it belongs. 
It looks like cruft/bad design to have the same snippet of code in all
packages.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


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

Re: GnuPG: Maintainer inactive?

[Kai Wasserbäch]

Hello again,

Kai Wasserbäch wrote:
> [...] Is there anything I can help (I'm certainly not suitable as a maintainer
> for that package myself, because it's too essential to be entrusted to someone
> who is unknown to (nearly) all people on this list) with, e.g. by triaging 
> bugs?

I've just seen, that Daniel Leidert is already on it and triages the bugs. If
you (Daniel) would like me to help you, just let me know. Otherwise just: thank 
you.

Kind regards,
Kai Wasserbäch



-- 

Kai Wasserbäch (Kai Wasserbaech)

E-Mail: [EMAIL PROTECTED]
Jabber (debianforum.de): Drizzt
URL: http://wiki.debianforum.de/Drizzt_Do%27Urden
GnuPG: 0xE1DE59D2  0600 96CE F3C8 E733 E5B6 1587 A309 D76C E1DE 59D2
(http://pgpkeys.pca.dfn.de/pks/lookup?search=0xE1DE59D2&fingerprint=on&hash=on&op=vindex)



signature.asc
Description: OpenPGP digital signature

Re: Misc development news (#6) (DEB_BUILD_OPTIONS=noopt)

[Darren Salt]

I demand that Raphael Hertzog may or may not have written...

> On Wed, 16 Apr 2008, Charles Plessy wrote:
>> Le Tue, Apr 15, 2008 at 10:58:29PM +0200, Raphael Hertzog a écrit :
>>> Since dpkg 1.14.17, dpkg-buildpackage will define the environment
>>> variables CFLAGS, CXXFLAGS, CPPFLAGS, LDFLAGS and FFLAGS. The goal is to
>>> be able to easily recompile packages with supplementary compilation flags
>>> and to simplify the debian/rules files since CFLAGS has the right default
>>> value (no need to special case for DEB_BUILD_OPTIONS=noopt).

>> When do you recommend to drop the support for this option? I personally
>> like to keep debian/rules minimal. Do we need to wait for a Policy
>> update?

> I would not yet update the rules files. [...]

I'd rather that this just got left in debian/rules, where it belongs:
xine-lib, for example, needs more than just -O0 for disabling optimisations.
Then there are the times when I find it useful to run "debian/rules build" or
something similar...

-- 
| Darren Salt| linux or ds at  | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + At least 4000 million too many people. POPULATION LEVEL IS UNSUSTAINABLE.

I'd like to, but I'm going down to the bakery to watch the buns rise.

Re: Should -dev packages providing .pc files depend on pkg-config?

[Gabor Gombas]

On Wed, Apr 16, 2008 at 11:23:51AM +0100, Neil Williams wrote:

> What about these clauses as a Policy amendment?
> 
> 1. If a library *only supports the retrieval of FOO_LIBS and / or
> FOO_CFLAGS by the use of pkg-config*, pkg-config becomes part of the API
> of that library and the -dev package of that library must depend on
> pkg-config. The mere presence of a .pc file in the -dev package of the
> library does *not* mean that only pkg-config is supported. e.g. where a
> library requires the use of an m4 macro that involves calling
> pkg-config, this would require the -dev package to depend on pkg-config
> but if a library provides a .pc file but also supports alternative
> method(s), the -dev package does not need to depend on pkg-config.
> 
> 2. If a source package uses libraries that package a .pc but where all
> the libraries also support other methods of obtaining the relevant data,
> and the source package requires the use of pkg-config despite those
> other methods being available, then that choice by the source package
> upstream must result in a Build-Depends on pkg-config in the source
> package.
> 
> Is that suitable as a Policy clause? (probably needs a few tweaks for
> clarity and examples in clause 1).

Wow, that's awfully complicated. This is much more straightforward:

"If a package wants to call /usr/bin/foo during build and fails
to build properly if /usr/bin/foo is not present, then the
package MUST Build-Depend: on some other package providing
/usr/bin/foo".

And by this definition, it is the package _invoking_ pkg-config that
should Build-Depend on it, not the package that happens to ship a .pc
file.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -

Re: Should DMs be allowed to upload to NEW

[Neil Williams]

On Wed, 2008-04-16 at 15:59 +0200, Ondrej Certik wrote:
> Thanks for the reply. As I said, I am not questioning new SONAME bumps
> going into NEW.
> 
> The question is, whether the DMs should be allowed to upload SONAME
> bumps to NEW by themselves or not.

Umm, I would have to say no. Sorry.

SONAME bumps are just too disruptive IMHO.

>  I agree there should be a special
> attention to SONAME bumps and that's what the NEW is for (or any other
> queue as you said).

NEW is a step that can help with SONAME bumps but it is not sufficient
on its own. SONAME transitions MUST be coordinated amongst all the DD's
(and upstreams) involved. Such uploads can take months to arrange and
coordinate - your sponsor is best placed to deal with these issues.

More haste, less speed. DDs can make mistakes but DMs are not full DDs
and as such, the intervention of a DD is appropriate when the potential
upload could cause havoc in the rest of Debian (IMHO).

> It's all about how much trust you give to DMs. Imho if they are
> allowed to upload new revisions and even new upstream (if the name of
> all the binaries and the number of them stays the same), they can
> screw up a lot of things. 

Not as many as a SONAME transition. Any library upload can mistakenly
result in a broken API/ABI but normally that only affects one part of
the library functionality. 

A new SONAME is a completely NEW library - there is nothing that says
that libfoo1 has to have *anything* in common with libfoo2 at a binary
or source code level. It might do the same things on the surface but
during a SONAME change, the library upstream can change 100% of the API
and touch 100% of the source code. Every single header filename,
function prototype, typedef, macro, struct and variable. e.g. some
SONAME bumps have involved a complete renaming of the functions and
variables to a new namespace - FooFunc becoming foo_func etc. and with
structs going the opposite way from foo_data to FooData. Yes, the
principle of the library stays the same and it works in a similar manner
once the reverse dependencies are rebuilt but nothing else is the same.

After all, Debian is STILL carrying gtk1 - that should give you some
idea of the disruption caused by SONAME bumps. The consequences of a
single upload can take YEARS to resolve (and still involve the removal
of otherwise usable packages).

A new application can change 100% of the source code without problems -
many do change as much as 50% at each major release. Changing the
behaviour of a shared library has far wider implications. The two simply
cannot be compared.

I maintain (and co-maintain) a range of libraries, some upstream too - I
can honestly say that I would not consider any of those as suitable for
DM-Upload, even without changing a SONAME.

> So giving them the right to also upload new
> binary packages to NEW imho belongs to the same cathegory.

Not even close. IMHO, the very fact that you equate those two makes me
doubt that you properly understand shared libraries and SONAME bumps in
Debian.

An upload of a new application is nowhere near as complex as the upload
to start a library SONAME transition. Even uploading a new library never
seen in Debian before is easier than starting a SONAME transition for a
library that already exists. I'm sorry, merely by equating those two you
have lost all credibility in my eyes.

It's not just about trust, it is about coordination, planning and
ability. If you think that a SONAME transition is no more disruptive
than a new application then I have cause to worry about your ability to
maintain a library in Debian in the first place. It doesn't give me any
confidence in you or in DMs in general.


-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




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

Re: GnuPG: Maintainer inactive?

[Christian Perrier]

Quoting Kai Wasserbäch ([EMAIL PROTECTED]):
> Hello,
> on the 1st of April I wrote an e-mail to James Troup offering my help in 
> hunting

You shouldn't have done this on 1st of April as you could then have
received an answer.

> So my question is: Is James known to be inactive? Are there others currently 
> on


There are rumours about that, yes. Maybe a package hijack could be
attempted by someone who's lucky enough to have his|her key in the
keyring.




signature.asc
Description: Digital signature

Re: Should DMs be allowed to upload to NEW

[Romain Beauxis]

Le Wednesday 16 April 2008 15:44:56 Neil Williams, vous avez écrit :
> An upload of a new application is nowhere near as complex as the upload
> to start a library SONAME transition. Even uploading a new library never
> seen in Debian before is easier than starting a SONAME transition for a
> library that already exists. I'm sorry, merely by equating those two you
> have lost all credibility in my eyes.

Why should he have to gain any credibility in your eyes ? Were you about to 
help him dealing with this ?

> It's not just about trust, it is about coordination, planning and
> ability. If you think that a SONAME transition is no more disruptive
> than a new application then I have cause to worry about your ability to
> maintain a library in Debian in the first place. It doesn't give me any
> confidence in you or in DMs in general.

Well, ok SONAME is a dangerous thing, warning, warning !!

In the mean time, it's still possible for a DM to upload a different soname in 
the same binary package, which would result in an even worse mess, right ?

I don't like your tone, it's pedantic, because somehow it's legitimate to ask 
this kind of questions regarding the potential harm he already has the right 
to do with the DM upload rights. And I believe you didn't even look at his 
package (neither did I by the way...)


Romain
-- 
How can a man
Discover a land
That already populated with Indians?

Re: Should -dev packages providing .pc files depend on pkg-config?

[Tollef Fog Heen]

* Goswin von Brederlow 

| I would go one step further. Imho libraries with *.pc files should say
| "the only supported way to use this lib is by using pkg-config".

I would not recommend that, as pkg-config upstream.

| > | Putting pkg-config on Recommends of Suggests of every -dev packages
| > | that has a .pc file, you could as well put it into built-essential
| > | dependency.
| 
| How would a Recommends or Suggests even help? Sure, users would get
| the pkg-config installed. But buildds don't, right? So sources would
| still FTBFS and would have to Build-Depend on pkg-config even if they
| only call some autoconf macro from the *-dev package.

The configure script is usually not regenerated as part of the package
build process, so this would not help at all.  I think this is a
deficiency in the auto* approach.  The autoconf macro comes from when
the upstream source tarball was prepared and whatever the packager had
installed at that time.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


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

Re: Should -dev packages providing .pc files depend on pkg-config?

[Neil Williams]

On Wed, 2008-04-16 at 16:12 +0200, Gabor Gombas wrote:
> On Wed, Apr 16, 2008 at 11:23:51AM +0100, Neil Williams wrote:
> 
> > What about these clauses as a Policy amendment?
> > 
> > 1. If a library *only supports the retrieval of FOO_LIBS and / or
> > FOO_CFLAGS by the use of pkg-config*, pkg-config becomes part of the API
> > of that library and the -dev package of that library must depend on
> > pkg-config. The mere presence of a .pc file in the -dev package of the
> > library does *not* mean that only pkg-config is supported. e.g. where a
> > library requires the use of an m4 macro that involves calling
> > pkg-config, this would require the -dev package to depend on pkg-config
> > but if a library provides a .pc file but also supports alternative
> > method(s), the -dev package does not need to depend on pkg-config.
> > 
> > 2. If a source package uses libraries that package a .pc but where all
> > the libraries also support other methods of obtaining the relevant data,
> > and the source package requires the use of pkg-config despite those
> > other methods being available, then that choice by the source package
> > upstream must result in a Build-Depends on pkg-config in the source
> > package.
> > 
> > Is that suitable as a Policy clause? (probably needs a few tweaks for
> > clarity and examples in clause 1).
> 
> Wow, that's awfully complicated. 

Yes, I realise that. 

> This is much more straightforward:
> 
>   "If a package wants to call /usr/bin/foo during build and fails
>   to build properly if /usr/bin/foo is not present, then the
>   package MUST Build-Depend: on some other package providing
>   /usr/bin/foo".

It doesn't account for packages where pkg-config really is part of the
API of the library but maybe that is the way it should be.

If a library enforces the use of pkg-config, it is still the choice of
upstream to use that library or implement a different version - as such,
the choice carries a consequence of depending on pkg-config in
Build-Depends. I'm not convinced that that is such a penalty but others
on -devel wanted a different view so I tried to cover that in the
clauses.

I was merely trying to reflect other threads in this discussion - I
haven't actually got a concrete example of a library that includes
pkg-config into the API.

There may well be corner cases I don't know about but AFAICT most cases
would be met correctly by the simpler expedient of "you use it, you
depend on it" as you describe.

> And by this definition, it is the package _invoking_ pkg-config that
> should Build-Depend on it, not the package that happens to ship a .pc
> file.

I agree with that interpretation and that intention, I'm just not sure
it covers all eventualities.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




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

Re: Should -dev packages providing .pc files depend on pkg-config?

[Bas Wijnen]

First of all, I skipped a large part of this thread, so I'm sorry if
this has come up before.

On Wed, Apr 16, 2008 at 03:53:03PM +0100, Neil Williams wrote:
> > And by this definition, it is the package _invoking_ pkg-config that
> > should Build-Depend on it, not the package that happens to ship a .pc
> > file.
> 
> I agree with that interpretation and that intention, I'm just not sure
> it covers all eventualities.

What is missed, I think, is the situation where:
- the library which ships the .pc file also ships a script which calls
  pkg-config, called foo-config.
- the library provides this as an option, and lets you use other options
  (for example using pkg-config directly) as well.
- the library wants the foo-config option to be opaque, that is, it may
  stop using pkg-config in the future, and use some other method to
  provide the flags.

According to the suggested definition, if a package using this library
chooses to use foo-config, it doesn't call pkg-config directly (and it
may not call it at all, this depends on the inner workings of
foo-config).  So the package wouldn't need a Build-Depends: on
pkg-config.  However, the library doesn't need a Depends: either,
because the package can well be used without pkg-config.

While I agree that the proposed solution is probably best (the caller
needs the dependency), this situation isn't solved by it.  Then again,
this seems to be a broken dependency specification by upstream ("what do
you need to compile programs with this library?"), and I'm not sure if
this is solved by anything other than "you need to depend on everything
you directly or indirectly use", and we certainly don't want that.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Rejected: epcr_2.3.9-1.dsc: sha1 check failed

[Andreas Tille]

Hi,

it is the third time that I've got this type of rejection.  I faced
it two times with package gnumed-client and now with a different package.

Is anybody able to explain this and how can I avoid the problem.  I
just builded the package with an up to date pbuilder.

Puzzled

Andreas.

--
http://fam-tille.de

-- Forwarded message --
Date: Wed, 16 Apr 2008 13:02:03 +
From: Debian Installer <[EMAIL PROTECTED]>
To: Andreas Tille <[EMAIL PROTECTED]>,
Debian-Med Packaging Team <[EMAIL PROTECTED]>
Subject: [Debian-med-packaging] epcr_2.3.9-1_i386.changes REJECTED


Rejected: epcr_2.3.9-1.dsc: sha1 check failed.
Rejected: epcr_2.3.9-1.dsc: actual file size (1289) does not match size (1052) 
in .changes sha1
Rejected: epcr_2.3.9-1.dsc: sha256 check failed.
Rejected: epcr_2.3.9-1.dsc: actual file size (1289) does not match size (1052) 
in .changes sha256


===

If you don't understand why your files were rejected, or if the
override file requires editing, reply to this email.

___
Debian-med-packaging mailing list
[EMAIL PROTECTED]
http://lists.alioth.debian.org/mailman/listinfo/debian-med-packaging


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

Re: Misc development news (#6)

[Andreas Tille]

On Wed, 16 Apr 2008, Holger Levsen wrote:


On Wednesday 16 April 2008 15:24, Roberto C. Sánchez wrote:

This is something that I propsed on January 3, 2007, on debian-devel.


Great!! I did not noticed. :-(


There was a fairly lengthy thread that resulted and Thomas Viehmann even
offered to help.  Of course, he and I both became very busy and so it
sort of fell by the wayside.  However, I have my projects much better in
hand this year and I intend to resurrect the idea early this summer.


Cool.


Really cool.


I've changed the contact address Andreas put there into "Contact: AndreasTille
or Roberto C. Sánchez <[EMAIL PROTECTED]> - Roberto intends to work on
it..." - feel free to change further :-)


I decided to change it by removing my name to not blur the list of people
who really intent to work on this.

I would be very happy if there would be some progress on this

  Andreas.

--
http://fam-tille.de

Re: Rejected: epcr_2.3.9-1.dsc: sha1 check failed

[Matthew Johnson]

On Wed Apr 16 17:19, Andreas Tille wrote:
> Hi,
>
> it is the third time that I've got this type of rejection.  I faced
> it two times with package gnumed-client and now with a different package.
>
> Is anybody able to explain this and how can I avoid the problem.  I
> just builded the package with an up to date pbuilder.

do you have updated devscripts? debsign signs the dsc then updates the
md5 hash in the changes before signing that. It needs to update the sha
checks as well. The latest devscripts does.

Matt
-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: Should DMs be allowed to upload to NEW

[Adeodato Simó]

* Romain Beauxis [Wed, 16 Apr 2008 15:53:21 +0100]:

> In the mean time, it's still possible for a DM to upload a different soname 
> in 
> the same binary package, which would result in an even worse mess, right ?

Well, DDs have done this in the past already, so...

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
If there is a sin against life, it consists perhaps not so much in
despairing of life as in hoping for another life and in eluding the
implacable grandeur of this life.
-- Albert Camus


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

Re: Misc development news (#6) (DEB_BUILD_OPTIONS=noopt)

[Adeodato Simó]

* Raphael Hertzog [Wed, 16 Apr 2008 16:20:36 +0200]:

> On Wed, 16 Apr 2008, Darren Salt wrote:
> > I'd rather that this just got left in debian/rules, where it belongs:
> > xine-lib, for example, needs more than just -O0 for disabling optimisations.

> You can keep it there for special cases like this one.

> But I disagree that debian/rules is necessarily the place where it belongs. 
> It looks like cruft/bad design to have the same snippet of code in all
> packages.

On the other hand, the bit about running `debian/rules build` by hand
seems valid to me.

Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
He who has not a good memory should never take upon himself the trade of lying.
-- Michel de Montaigne


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

Re: Rejected: epcr_2.3.9-1.dsc: sha1 check failed

[Adam D. Barratt]

Hi,

Andreas Tille wrote:

it is the third time that I've got this type of rejection.  I faced
it two times with package gnumed-client and now with a different
package.

[...]

Rejected: epcr_2.3.9-1.dsc: sha1 check failed.
Rejected: epcr_2.3.9-1.dsc: actual file size (1289) does not match
size (1052) in .changes sha1 Rejected: epcr_2.3.9-1.dsc: sha256 check
failed. Rejected: epcr_2.3.9-1.dsc: actual file size (1289) does not match
size (1052) in .changes sha256


As Matthew said, you need to make sure you're using devscripts 2.10.25 so 
that debsign knows to update the file size in the new Checksums-* fields.


fwiw, this was mentioned in the recent Misc Development News post to d-d-a.

Regards,

Adam 



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

Re: Rejected: epcr_2.3.9-1.dsc: sha1 check failed

[Andreas Tille]

On Wed, 16 Apr 2008, Matthew Johnson wrote:


do you have updated devscripts?


Will this be updated by

sudo pbuilder update

?


debsign signs the dsc then updates the
md5 hash in the changes before signing that. It needs to update the sha
checks as well. The latest devscripts does.


I failed to upload with a debuild of gnumed-client twice but it
worked in an updated pbuilder the day before yesterday.  Now I
failed in a pbuilder updated today.

Do I have to start pdebuild out of an "unstable" system?  This
would be a nuisance because I do not want to run unstable on this
machine and regarded pbuilder as a very nice way to maintain a
proper unstable chroot.

Kind regards

  Andreas.

--
http://fam-tille.de


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

Re: Rejected: epcr_2.3.9-1.dsc: sha1 check failed

[Matthew Johnson]

On Wed Apr 16 17:47, Andreas Tille wrote:
> Do I have to start pdebuild out of an "unstable" system?  This
> would be a nuisance because I do not want to run unstable on this
> machine and regarded pbuilder as a very nice way to maintain a
> proper unstable chroot.

It depends where you run debsign. I've backported devscripts to the
machine I run debsign on, which isn't running unstable, so pbuilder
builds in a sid chroot and then I sign outside of it.

Matt
-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: Rejected: epcr_2.3.9-1.dsc: sha1 check failed

[Andreas Tille]

On Wed, 16 Apr 2008, Adam D. Barratt wrote:


fwiw, this was mentioned in the recent Misc Development News post to d-d-a.


Yes, but I expect an up to date pbuilder to contain everything I
need.  Thinking about it chances are good that the GPG key is not
copied to the building chroot and my assumption was just wrong and
the local devscripts are involved in finally preparing the package.
I never have really thought about this ...

Kind regards

Andreas.

--
http://fam-tille.de


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

Re: GnuPG: Maintainer inactive?

[Francesco P. Lovergine]

On Wed, Apr 16, 2008 at 04:49:50PM +0200, Christian Perrier wrote:
> 
> There are rumours about that, yes. Maybe a package hijack could be
> attempted by someone who's lucky enough to have his|her key in the
> keyring.
> 

... and still have it after that upload :-P

-- 
Francesco P. Lovergine


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

Bug#476416: ITP: plasma-netgraph -- A plasmoid to display network usage

[Salvatore Ansani]

Package: wnpp
Severity: wishlist
Owner: Salvatore Ansani <[EMAIL PROTECTED]>


* Package name: plasma-netgraph
  Version : 0.2
  Upstream Author : John Varouhakis <[EMAIL PROTECTED]>
* URL : 
http://www.kde-look.org/content/show.php/plasma-netgraph?content=74071
* License : GPL
  Programming Lang: C++
  Description : A plasmoid to display network usage

 Plasma-netgraph is a plasmoid, that displays
 network usage and is comprised of a configurable
 applet and a data-engine.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing-proposed-updates
  APT policy: (500, 'testing-proposed-updates'), (500, 'proposed-updates'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Re: Misc development news (#6) (DEB_BUILD_OPTIONS=noopt)

[Loïc Minier]

On Wed, Apr 16, 2008, Raphael Hertzog wrote:
> But I disagree that debian/rules is necessarily the place where it belongs. 
> It looks like cruft/bad design to have the same snippet of code in all
> packages.

 Perhaps this should be fixed in another way then?  For example a shared
 Makefile included by all debian/rules (if they are a makefile :) -- ala
 cdbs, but with a simple documented interface such as documenting that
 this will set *FLAGS based on deb_build_opts.  e.g.
 /usr/share/dpkg/flags.mk with:
CFLAGS += -Wall -g -O$(if $(findstring noopt,$(DEB_BUILD_OPTIONS)),0,2)

-- 
Loïc Minier


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

Fwd: Please All Links Builder My Request Added

[sameer webmaster]

-- Forwarded message --
From: Ashwini Prajapati <[EMAIL PROTECTED]>
Date: Apr 16, 2008 9:39 PM
Subject: Re: Please All Links Builder My Request Added
To: [EMAIL PROTECTED]

You always be happy :)

You always be smile :)

You always be happy :)

You always be smile :)

You always be happy :)

You always be smile :)

You always be happy :)

You always be smile :)

--
(¨`·.·´¨) Always
`·.¸(¨`·.·´¨) Keep
(¨`·.·´¨)¸.·´ Smiling!
`·.¸.·´

Re: Rejected: epcr_2.3.9-1.dsc: sha1 check failed

[James Vega]

On Wed, Apr 16, 2008 at 05:51:48PM +0200, Andreas Tille wrote:
> On Wed, 16 Apr 2008, Adam D. Barratt wrote:
>
>> fwiw, this was mentioned in the recent Misc Development News post to d-d-a.
>
> Yes, but I expect an up to date pbuilder to contain everything I
> need.  Thinking about it chances are good that the GPG key is not
> copied to the building chroot and my assumption was just wrong and
> the local devscripts are involved in finally preparing the package.
> I never have really thought about this ...

Signing generally isn't performed in the pbuilder chroot.  The only reason
devscripts would be installed into the chroot is if the package you're
building Build-Depends on it or you explicitly installed it into the chroot.

You're either running debsign on your own after the build is complete or
telling pbuilder to automatically sign the package.  In either case, debsign
is being invoked outside of the chroot in your native environment.  Therefore
you need to make sure you have devscripts 2.10.25 (or your own backport if you
aren't running sid) in that environment.

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: RFH: Multiarch capable toolchain as release goal

[Goswin von Brederlow]

"Bernhard R. Link" <[EMAIL PROTECTED]> writes:

> * Lennart Sorensen <[EMAIL PROTECTED]> [080415 21:57]:
>> Now I suppose sparc and others might still like it if they have
>> performance advantages of 32bit code over 64bit code, in which case
>> keeping 64bit for only those programs where the extra address space is
>> worth it would be great.
>
> I guess most long-year sparc users are by now against any multiarch
> stuff by bad experience. Having 64 bit libraries installed on sparc
> was always the best way to get a broken system. Every other year
> some directory changes to a symlink, or a symlink to a directory,
> changes it name from ultra to sparc64 or there is some other reason
> breaking your upgrades. So at least I try as good as I can to avoid
> anything with the threathening "64" in its name.
>
> Hochachtungsvoll,
>   Bernhard R. Link

Multiarch, for lack of a better unique identifier, currently uses the
gnu tripplet as directory name. If you change your abi name from ultra
to sparc64 then the tripplet would change and therefore the directory
name, right?

The problem you describe is exactly one of the reasons for the
multiarch design. Every library should have a unique location so
packages for different "architectures" will not create file conflicts
and can be installed in parallel. No moving, no linking. If you add a
new ABI you must make it end up in a new and unique location.

Also a change in the location would mean adding a new location,
changing the libs one by one and then remove the old location when it
is empty. Again no moving or linking.

To give some examples you can have

/usr/lib/i486-linux-gnu/
/usr/lib/i686-linux-gnu/
/usr/lib/i484-linux-uclibc/
/usr/lib/x86_64-linux-gnu/
/usr/lib/ppc-linux-gnu/

all on the same system.

MfG
Goswin


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

Re: Should -dev packages providing .pc files depend on pkg-config?

[Goswin von Brederlow]

Gabor Gombas <[EMAIL PROTECTED]> writes:

> On Wed, Apr 16, 2008 at 11:23:51AM +0100, Neil Williams wrote:
>
>> What about these clauses as a Policy amendment?
>> 
>> 1. If a library *only supports the retrieval of FOO_LIBS and / or
>> FOO_CFLAGS by the use of pkg-config*, pkg-config becomes part of the API
>> of that library and the -dev package of that library must depend on
>> pkg-config. The mere presence of a .pc file in the -dev package of the
>> library does *not* mean that only pkg-config is supported. e.g. where a
>> library requires the use of an m4 macro that involves calling
>> pkg-config, this would require the -dev package to depend on pkg-config
>> but if a library provides a .pc file but also supports alternative
>> method(s), the -dev package does not need to depend on pkg-config.
>> 
>> 2. If a source package uses libraries that package a .pc but where all
>> the libraries also support other methods of obtaining the relevant data,
>> and the source package requires the use of pkg-config despite those
>> other methods being available, then that choice by the source package
>> upstream must result in a Build-Depends on pkg-config in the source
>> package.
>> 
>> Is that suitable as a Policy clause? (probably needs a few tweaks for
>> clarity and examples in clause 1).
>
> Wow, that's awfully complicated. This is much more straightforward:
>
>   "If a package wants to call /usr/bin/foo during build and fails
>   to build properly if /usr/bin/foo is not present, then the
>   package MUST Build-Depend: on some other package providing
>   /usr/bin/foo".
>
> And by this definition, it is the package _invoking_ pkg-config that
> should Build-Depend on it, not the package that happens to ship a .pc
> file.
>
> Gabor

You are missing the point.

What if the library says "You must call /usr/bin/foo during build"?
The libarry does not use foo, only the user, so no depends?
Or idoes forcing users to use foo make foo part of the API and hence
the library should depend on it?

MfG
Goswin


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

Re: Misc development news (#6) (DEB_BUILD_OPTIONS=noopt)

[Darren Salt]

I demand that Loïc Minier may or may not have written...

> On Wed, Apr 16, 2008, Raphael Hertzog wrote:
>> But I disagree that debian/rules is necessarily the place where it
>> belongs. It looks like cruft/bad design to have the same snippet of code
>> in all packages.

> Perhaps this should be fixed in another way then?  For example a shared
> Makefile included by all debian/rules (if they are a makefile :) -- ala
> cdbs, but with a simple documented interface such as documenting that
> this will set *FLAGS based on deb_build_opts.  e.g.
> /usr/share/dpkg/flags.mk with:
> CFLAGS += -Wall -g -O$(if $(findstring noopt,$(DEB_BUILD_OPTIONS)),0,2)

That looks reasonable to me.

However, care should be taken to avoid ending up with cdbs-buildpackage ;-)

-- 
| Darren Salt| linux or ds at  | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
|   Kill all extremists!

I couldn't possibly fail to disagree with you less.

Re: Should -dev packages providing .pc files depend on pkg-config?

[Neil Williams]

On Wed, 2008-04-16 at 19:15 +0200, Goswin von Brederlow wrote:
> Gabor Gombas <[EMAIL PROTECTED]> writes:
> 
> > On Wed, Apr 16, 2008 at 11:23:51AM +0100, Neil Williams wrote:
> >
> >> What about these clauses as a Policy amendment?
> >> 
> >> 1. If a library *only supports the retrieval of FOO_LIBS and / or
> >> FOO_CFLAGS by the use of pkg-config*, pkg-config becomes part of the API
> >> of that library and the -dev package of that library must depend on
> >> pkg-config. The mere presence of a .pc file in the -dev package of the
> >> library does *not* mean that only pkg-config is supported. e.g. where a
> >> library requires the use of an m4 macro that involves calling
> >> pkg-config, this would require the -dev package to depend on pkg-config
> >> but if a library provides a .pc file but also supports alternative
> >> method(s), the -dev package does not need to depend on pkg-config.
> >> 
> >> 2. If a source package uses libraries that package a .pc but where all
> >> the libraries also support other methods of obtaining the relevant data,
> >> and the source package requires the use of pkg-config despite those
> >> other methods being available, then that choice by the source package
> >> upstream must result in a Build-Depends on pkg-config in the source
> >> package.
> >> 
> >> Is that suitable as a Policy clause? (probably needs a few tweaks for
> >> clarity and examples in clause 1).
> >
> > Wow, that's awfully complicated. This is much more straightforward:
> >
> > "If a package wants to call /usr/bin/foo during build and fails
> > to build properly if /usr/bin/foo is not present, then the
> > package MUST Build-Depend: on some other package providing
> > /usr/bin/foo".
> >
> > And by this definition, it is the package _invoking_ pkg-config that
> > should Build-Depend on it, not the package that happens to ship a .pc
> > file.
> >
> > Gabor
> 
> You are missing the point.
> 
> What if the library says "You must call /usr/bin/foo during build"?
> The libarry does not use foo, only the user, so no depends?

The library -dev package includes the binary - if that binary needs
other binaries to run, the package containing the binary must depend on
those packages. So if /usr/bin/foo is actually a script that calls
pkg-config, the -dev package containing /usr/bin/foo must depend on
pkg-config. However, unless the application linking against the library
does not use pkg-config for any other libraries that it needs, the
application will be running pkg-config during the ./configure script so
the application will need to Build-Depend on pkg-config as well.

> Or idoes forcing users to use foo make foo part of the API and hence
> the library should depend on it?

Exactly - it does, IMHO. That is why I suggested the more complex
wording, albeit still based on the "you run it, you depend on it"
mantra.

-- 
Neil Williams <[EMAIL PROTECTED]>


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

Re: Should -dev packages providing .pc files depend on pkg-config?

[Gabor Gombas]

On Wed, Apr 16, 2008 at 07:15:53PM +0200, Goswin von Brederlow wrote:

> You are missing the point.
> 
> What if the library says "You must call /usr/bin/foo during build"?

But the library can't say "foo must come from a Debian package". What if
I have my local replacement? Why should I be forced to install a package
that is now useless for me (and installing it would only cause confusion
as there are now two different tools with the same name present in
$PATH)?

> The libarry does not use foo, only the user, so no depends?

Of course no dependency is needed. If the library is not used by anyone
(think about an NFS server that just exports the library), then a
missing "foo" would not hurt anyone. And if someone _does_ use the
library, then that user must depend on "foo", and everything is fine.

> Or idoes forcing users to use foo make foo part of the API and hence
> the library should depend on it?

You can't _force_ anyone to use foo. At most you can say "I'm not going
to give you support if I somehow find out you didn't use foo" but that's
it. I should be able to write my own tools and use the library in
whatever way I want - or the library must go into non-free.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Please add me to your list - Thank you!

[Miranda, Marjorie (GE, Corporate, consultant)]

Re: Should -dev packages providing .pc files depend on pkg-config?

[Neil Williams]

On Wed, 2008-04-16 at 19:57 +0200, Gabor Gombas wrote:
> On Wed, Apr 16, 2008 at 07:15:53PM +0200, Goswin von Brederlow wrote:
> 
> > You are missing the point.
> > 
> > What if the library says "You must call /usr/bin/foo during build"?
> 
> But the library can't say "foo must come from a Debian package". What if
> I have my local replacement? 

/usr/local/bin/foo ?

> Why should I be forced to install a package
> that is now useless for me (and installing it would only cause confusion
> as there are now two different tools with the same name present in
> $PATH)?

That is a problem with your replacement, not with the Debian package. If
your replacement is a Debian package, you need to use Debian Policy to
handle that situation - it still doesn't mean that it is the fault of
the library or that the library must support your alternative.

> 
> > The libarry does not use foo, only the user, so no depends?
> 
> Of course no dependency is needed. 

To run /usr/bin/foo, if you need bar, the package containing foo must
depend on bar. That, in this case, means libfoo-dev depends on
pkg-config.

> If the library is not used by anyone
> (think about an NFS server that just exports the library), then a
> missing "foo" would not hurt anyone. And if someone _does_ use the
> library, then that user must depend on "foo", and everything is fine.

Or more exactly, the package containing foo which will be the -dev.

> > Or idoes forcing users to use foo make foo part of the API and hence
> > the library should depend on it?
> 
> You can't _force_ anyone to use foo. At most you can say "I'm not going
> to give you support if I somehow find out you didn't use foo" but that's
> it. I should be able to write my own tools and use the library in
> whatever way I want - or the library must go into non-free.

True, but you cannot dictate to the library that it must support your
replacement or even not conflict with it. Your replacement needs to live
with the package as-is, in accordance with Debian Policy. If Policy gets
an update that "you run it, you depend on it" along the lines of my
previous post, then the -dev would depend on pkg-config and most other
applications using the library would depend on pkg-config *if* they need
that to work with other libraries. (That's the usual case - most
applications will end up running pkg-config so most applications will
end up with a Build-Depends: pkg-config, )

-- 
Neil Williams <[EMAIL PROTECTED]>


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

Re: Should -dev packages providing .pc files depend on pkg-config?

[Neil Williams]

On Wed, 2008-04-16 at 17:23 +0200, Bas Wijnen wrote:
> First of all, I skipped a large part of this thread, so I'm sorry if
> this has come up before.
> 
> On Wed, Apr 16, 2008 at 03:53:03PM +0100, Neil Williams wrote:
> > > And by this definition, it is the package _invoking_ pkg-config that
> > > should Build-Depend on it, not the package that happens to ship a .pc
> > > file.
> > 
> > I agree with that interpretation and that intention, I'm just not sure
> > it covers all eventualities.
> 
> What is missed, I think, is the situation where:
> - the library which ships the .pc file also ships a script which calls
>   pkg-config, called foo-config.
> - the library provides this as an option, and lets you use other options
>   (for example using pkg-config directly) as well.
> - the library wants the foo-config option to be opaque, that is, it may
>   stop using pkg-config in the future, and use some other method to
>   provide the flags.

That is an example of a library including pkg-config into the library
API. Changing that behaviour (dropping the script) means a SONAME bump.

> According to the suggested definition, if a package using this library
> chooses to use foo-config, it doesn't call pkg-config directly (and it
> may not call it at all, this depends on the inner workings of
> foo-config). 

During the time that foo-config calls pkg-config, the -dev package
containing foo-config must depend on pkg-config. That follows logically
from the "you call it, you depend on it" model.

>  So the package wouldn't need a Build-Depends: on
> pkg-config.  However, the library doesn't need a Depends: either,
> because the package can well be used without pkg-config.

Which is where that complexity comes in again - if the package calls
foo-config, it must depend on the -dev. If foo-config *as a script*
requires pkg-config, the -dev must depend on pkg-config because it is
calling it.

A simple .pc file doesn't call anything so that does not lead to a
dependency on pkg-config for the -dev.

If we stick with the idea of "you call it, you depend on it", these
situations become a lot clearer.

If foo-config changes internally to not call pkg-config anymore, that
allows the -dev to drop the pkg-config dependency. What is wrong,
therefore, is for the package using foo-config to expect that the -dev
continues to provide pkg-config and to then use pkg-config itself for
other things *without* a dependency.

i.e. a duplicate dependency is the best approach here.


-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




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

Re: RFH: Multiarch capable toolchain as release goal

[Luk Claes]

Goswin von Brederlow wrote:
> Luk Claes <[EMAIL PROTECTED]> writes:
> 
>> Goswin von Brederlow wrote:
>>> Ove Kaaven <[EMAIL PROTECTED]> writes:
 The way I understand it, they HAVE been pushing... and pushing... for
 a long time... against a nonresponsive binutils maintainer. This
 thread is just their latest, last-ditch effort since nothing else
 worked so far. But I could be wrong, I guess.
>>> You are right. The patch has been around for years and requests for any
>>> response to the patch have just been ignored.
>> According to the bug log the patch was not ready when the maintainer
>> wanted to apply it and nobody bothered to start an NMU process...

> What bug are you reading?
> 
> Sat, 27 May 2006 10:16:36 +0200: initial report with patch
> Wed, 21 Jun 2006 00:48:26 +0200: NMU attempt gets vetoed

Nope, this is only a patch with a mail subject 'Patch for pending NMU of
binutils'

> Wed, 28 Jun 2006 11:01:53 +0200: 2. maintainer misunderstands the patch
> Thu, 29 Jun 2006 22:44:30 +0200: some discussion about the misunderstanding
> Mon, 11 Sep 2006 15:58:28 +0200: patch update for the i386->i486 ABI change
> Sun, 29 Apr 2007 00:12:48 +0200: prodding the maintainer for an reaction
> Thu, 28 Jun 2007 03:43:16 +0100: first real reply by maintainer

Patch was not ready...

> Mon, 02 Jul 2007 19:14:35 +0200: patch fix for issues raise by maintainer

Didn't look like the issue was settled as the mail of Aurélien on 03 Jul
was ending questioning the patch...

> Thu, 26 Jul 2007 15:56:45 +0200: patch split into the ABI and multiarch parts
> 
> An NMU was tried and it and all future NMU where vetoed by the maintainer.

I only see discussion about the misunderstanding of a patch and fixing
of the patch after the maintainer comment.

There was no mail asking if it was allright to NMU, nor a real NMU
attempt AFAICS...

> In summary:
> 
> - 13 month from initial report to raising a minor issue that has no
>   negative effects on the functionality
> - 4 days to fix the issue

Not clear from the bug log that everything was right already...

> - 9 month without reaction and counting

9 month waiting instead of trying to resolve the issue...

Btw looks like a very colored summary to me...

If I want a feature to be included in a package which the maintainer is
not really interested in, I would make sure that my patch would be ready
to apply and/or make sure I tried to actually NMU...

Cheers

Luk

PS: I would not mind having multiarch support myself...


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

Re: Bug#476340: ITP: datapacker -- Tool to pack files into minimum number of CDs/DVDs/etc

[Jon Leonard]

On Wed, Apr 16, 2008 at 12:21:51PM +, brian m. carlson wrote:
> On Tue, Apr 15, 2008 at 10:50:23PM -0500, John Goerzen wrote:
>> Package: wnpp
>> Severity: wishlist
>> Owner: John Goerzen <[EMAIL PROTECTED]>
>>
>> * Package name: datapacker
>>  Version : 1.0.0
>>  Upstream Author : John Goerzen <[EMAIL PROTECTED]>
>> * URL : http://software.complete.org/datapacker
>> * License : GPL
>>  Programming Lang: Haskell
>>  Description : Tool to pack files into minimum number of CDs/DVDs/etc
>> datapacker is a tool to group files by size. It is
>> designed to group files such that they fill fixed-size containers
>> (called "bins") using the minimum number of containers.
>
> This sounds suspiciously like the knapsack problem, which is in NP.  Is  
> it guaranteed to use the minimum number, or are there cases when it  
> would not?  If the former, I'm sure Merkle and Hellman would like to  
> hear from you. ;-)

If all the items to be packed are multiples of a common size (say, one
sector on a CD), then it is instead an instance of "integer knapsack",
which has a dynamic programming algorithm of reasonable complexity.
(That is, number of items times bin size.)

It's entirely possible that datapacker solves the problem that way.

Jon Leonard


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

missing package conflicts

[Ralf Treinen]

Hi,

The following list contains packages that fail to install at the same time
since one package tries to overwrite a file owned by the other package:

http://edos.debian.net/missing-conflicts/

In these package pairs, (at least) one of the two packages must declare 
a conflict with the other package.

I will file bugs soon (hopefully before leaving on [VAC] on 18/4). One
interesting question is: against which of the conflicting packages
should the bug be filed? The less popular one according to popcon? The
more recent one in the archive? The one with the more active
maintainer?

Here is how the clashes were detected:
1) generate from the Contents file a list of package pairs that contain 
   at least one common file.
2) use pkglab (one of the EDOS tools, debian packages are pending) to select
   from the list obtained in (1) those pairs of packages that are installable
   at the same time when looking only at dependency relationships.
3) try installing the packages obtained from (2) in a sid chroot.

Some statistics for amd64/sid:
- 2432104 files listed in the Contents file
- 867 package pairs that contain at least one common file
- 102 package pairs that contain at least one common file, and that are
  co-installable according to the EDOS criteria
- 27 package pairs that fail to install together due to attempted file
  overwrite

-Ralf.


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

Re: GnuPG: Maintainer inactive?

[Moritz Muehlenhoff]

Michael Banck wrote:
> On Wed, Apr 16, 2008 at 02:19:12PM +0200, Kai Wasserbäch wrote:
>> on the 1st of April I wrote an e-mail to James Troup offering my help in 
>> hunting
>> down open bugs which are no longer present an thus enabling him to 
>> concentrate
>> on packaging GnuPG 1.4.9. But his last action regarding this package is well
>> over an year old and the only updates I can see in the PTS were made by the
>> Security Team. And before I forget to write it: I didn't receive an answer.
>> So my question is: Is James known to be inactive? Are there others currently 
>> on
>> the task to get a new version (upstream has 1.4.9) into Debian? Is there
>> anything I can help (I'm certainly not suitable as a maintainer for that 
>> package
>> myself, because it's too essential to be entrusted to someone who is unknown 
>> to
>> (nearly) all people on this list) with, e.g. by triaging bugs?
>  
> I guess triaging bugs (i.e. marking bugs which have been fixed upstream
> in newer versions as "fixed-upstream" or mention bugs which can be
> closed already cause they are fixed in the current version in the
> appropriate bug (CCing the submitter, so they can possibly close it
> themselves) is always welcome, regardless of any other action or
> non-action by the maintainer.

gnupg is very important and unmaintained for all practical purposes. 
It should be hijacked and brought into shape for Lenny.

Cheers,
Moritz


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

Re: GnuPG: Maintainer inactive?

[Lucas Nussbaum]

On 16/04/08 at 17:08 +0200, Francesco P. Lovergine wrote:
> On Wed, Apr 16, 2008 at 04:49:50PM +0200, Christian Perrier wrote:
> > There are rumours about that, yes. Maybe a package hijack could be
> > attempted by someone who's lucky enough to have his|her key in the
> > keyring.
> 
> ... and still have it after that upload :-P

You are probably joking.

But if a member of a team with some special rights on the Debian
infrastructure (ab)used his/her rights to remove a key from the keyring,
or to prevent access to Debian resources, for no valid reason or without
a proper procedure, I'm sure that many developers would loudly protest
and wouldn't let that happen.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


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

Re: missing package conflicts

[Daniel Schepler]

On Wednesday 16 April 2008 02:58:52 pm Ralf Treinen wrote:
> Hi,
>
> The following list contains packages that fail to install at the same time
> since one package tries to overwrite a file owned by the other package:
>
> http://edos.debian.net/missing-conflicts/
>
> In these package pairs, (at least) one of the two packages must declare
> a conflict with the other package.
>
> I will file bugs soon (hopefully before leaving on [VAC] on 18/4). One
> interesting question is: against which of the conflicting packages
> should the bug be filed? The less popular one according to popcon? The
> more recent one in the archive? The one with the more active
> maintainer?
>
> Here is how the clashes were detected:
> 1) generate from the Contents file a list of package pairs that contain
>at least one common file.
> 2) use pkglab (one of the EDOS tools, debian packages are pending) to
> select from the list obtained in (1) those pairs of packages that are
> installable at the same time when looking only at dependency relationships.
> 3) try installing the packages obtained from (2) in a sid chroot.
>
> Some statistics for amd64/sid:
> - 2432104 files listed in the Contents file
> - 867 package pairs that contain at least one common file
> - 102 package pairs that contain at least one common file, and that are
>   co-installable according to the EDOS criteria
> - 27 package pairs that fail to install together due to attempted file
>   overwrite
>
> -Ralf.

I'd be interested in seeing how there can be 75 package pairs with shared file 
names which coinstall successfully.  In the case of a Replaces making that 
possible, I'd say that the package with files being replaced should usually 
have a bug report submitted to get those obsolete files removed.  On the 
other hand, if there's a diversion involved, that seems fine.
-- 
Daniel Schepler


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

Re: Misc development news (#6)

[Jörg Sommer]

Hi Simon,

Simon Richter <[EMAIL PROTECTED]> wrote:
>>  Since dpkg 1.14.17, dpkg-buildpackage will define the environment
>>  variables CFLAGS, CXXFLAGS, CPPFLAGS, LDFLAGS and FFLAGS. The goal is to
>>  be able to easily recompile packages with supplementary compilation flags
>>  and to simplify the debian/rules files since CFLAGS has the right default
>>  value (no need to special case for DEB_BUILD_OPTIONS=noopt).
>
> This sounds like a bad idea to me, as it communicates instructions
> (CFLAGS) along with intent (DEB_BUILD_OPTIONS). How is a package
> supposed to behave if these differ, or even detect that it is asked to
> do something that is wonky?

I think the same way as it currently does. What do you do, if the user
sets DEB_BUILD_OPTIONS=noopt and CFLAGS=-O2? I think that's not a new
problem.

Bye, Jörg.
-- 
Es gibt nichts schöneres als dem Schweigen eines Dummkopfes zuzuhören.
(Helmut Quatlinger)


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

Re: Misc development news (#6) (DEB_BUILD_OPTIONS=noopt)

[Matthew Woodcraft]

Adeodato wrote:
> On the other hand, the bit about running `debian/rules build` by hand
> seems valid to me.

Indeed, that's what my fingers are used to typing if I just want a
patched package for local use. I wouldn't be surprised if there were
lots of other users who are the same.

The various wrappers want to do extra stuff which doesn't seem relevant
for a package you aren't going to publish.

-M-


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

Re: GnuPG: Maintainer inactive?

[Francesco P. Lovergine]

On Wed, Apr 16, 2008 at 09:33:32PM +0200, Lucas Nussbaum wrote:
> On 16/04/08 at 17:08 +0200, Francesco P. Lovergine wrote:
> > On Wed, Apr 16, 2008 at 04:49:50PM +0200, Christian Perrier wrote:
> > > There are rumours about that, yes. Maybe a package hijack could be
> > > attempted by someone who's lucky enough to have his|her key in the
> > > keyring.
> > 
> > ... and still have it after that upload :-P
> 
> You are probably joking.
> 

Of course yes, isn't that evident?

-- 
Francesco P. Lovergine


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

Bug#476465: ITP: dose2 -- OCaml libraries for managing packages and their dependencies

[Stefano Zacchiroli]

Package: wnpp
Severity: wishlist
Owner: Stefano Zacchiroli <[EMAIL PROTECTED]>

* Package name: dose2
  Version : 1.2
  Upstream Author : Berke Durak, Jaap Boender
* URL : http://gforge.inria.fr/projects/sodiac/
* License : LGPL
  Programming Lang: OCaml
  Description : OCaml libraries for managing packages and their dependencies

   Dose 2 is a framework made of several of OCaml libraries for managing
   distribution packages and their dependencies.
   .
   Though not tied to any particular distribution, Dose 2 forms a
   background of libraries which enable injecting packages coming for
   various distribution. Companion libraries (e.g. ceve) and tools (e.g.
   pkglab) rely on Dose 2 to manage packages coming from various
   distributions, e.g. Debian and Red Hat.
   .
   Besides basic functionalities for querying and setting package
   properties, Dose 2 also implements algorithms for solving more complex
   problems (monitoring package evolutions, correct and complete
   dependency resolution, repository-wide uninstallability checks).

dose2 is the first of a chain of 3/4 package that would lead to the
packaging of pkglab, an interactive shell to "play" with package
dependencies. pkglab is a tool which has already been proved very useful
for archive wide QA and testing.

dose2 is being packaged on the git repository
git://git.debian.org/git/pkg-ocaml-maint/packages/dose2.git

Cheers.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Re: GnuPG: Maintainer inactive?

[Daniel Leidert]

Am Mittwoch, den 16.04.2008, 14:19 +0200 schrieb Kai Wasserbäch:

> on the 1st of April I wrote an e-mail to James Troup offering my help in 
> hunting
> down open bugs which are no longer present an thus enabling him to concentrate
> on packaging GnuPG 1.4.9. But his last action regarding this package is well
> over an year old and the only updates I can see in the PTS were made by the
> Security Team. And before I forget to write it: I didn't receive an answer.
> So my question is: Is James known to be inactive? Are there others currently 
> on
> the task to get a new version (upstream has 1.4.9) into Debian?

I tried to get into it after I found, that several issues were fixed.
You can find some tagging and commenting by my person at the BTS. But
for known reasons (told it on the planet), I'm currently busy and
offline.

However: We should REALLY give more love to this package. I mean, there
is a very active and helpful upstream, but an inactive maintenance which
lead to >130 open bug report. I don't think, that upstream will keep up
taking care of bug reports in the Debian BTS with this amount of
reports. We should try to track down issues and decrease the amount of
open bug reports to keep the good relationship to upstream. I hope, you
understand, what I want to say. I mean: having such an upstream is a
very fortunate situation.

> Is there
> anything I can help (I'm certainly not suitable as a maintainer for that 
> package
> myself, because it's too essential to be entrusted to someone who is unknown 
> to
> (nearly) all people on this list) with, e.g. by triaging bugs?
> 
> Should this question already have been discussed somewhere, please point me 
> to it.

Here is, what I found out yet after a short look (just a c&p):

*** Main:
452118: new upstream release

*** Fixed in 1.4.7 and newer:
201589: Removed shutdown code in util/http.c and fix http_proxy (739)
402592: Limit bytes read for an unknown alogorithm
412508,
420613: Build changes to fully evaluate paths
431828: Decrypt multiple files and not just the first

*** Maybe fixed 1.4.7 and newer:
...

*** Fixed in older releases:
 72148: will deadlock with no timeout if keyserver cannot close socket (151)
137381: http_proxy support (361)
146345: gnupg: Can't restrict access to secring.gpg (--enable-selinux-support)

*** Maybe fixed in older releases (needs to be verified):
166794,
172823: --search leads to segfault

*** Forward candidates:
 58260,
317654: remove existing lockfiles

*** Wontfix candidates (upstream rejected without final notice or candidate):
310805: gnupg: fully exportable armored homedir is completely impossible now!
162742: gnupg: Please handle "deprecated option honor-http-proxy"

*** Close candidate (upstream rejected change):
185782: `--batch --output existingfile' outputs nothing and exits 0
196681: gnupg: gpg says /dev/[EMAIL PROTECTED] isn't a valid email address

*** Maybe is addressed (patch exists somehow and somewhere):
262467: 16_min_privileges breaks gpg on kernels without capabilities

*** Maybe should be addressed:
130363: gnupg: Duplicate key is handled as error (upstream)
133923: gnupg: Reports bug on --list-keys

*** Debian package related (to fix with update):
357267: conditional libcap-dev dependency
399092: debian/gzip.1 manpage
399167: ldap -> recommends
453122: not suid-root

> Thank you in advance for your reply(s).

HTH
(will be back during mid of May and I'm willing to help)

Regards, Daniel

Re: Should -dev packages providing .pc files depend on pkg-config?

[Jakob Bohm]

On Wed, Apr 16, 2008 at 04:12:45PM +0200, Gabor Gombas wrote:
> On Wed, Apr 16, 2008 at 11:23:51AM +0100, Neil Williams wrote:
> 
> > What about these clauses as a Policy amendment?
> > 
> > 1. If a library *only supports the retrieval of FOO_LIBS and / or
> > FOO_CFLAGS by the use of pkg-config*, pkg-config becomes part of the API
> > of that library and the -dev package of that library must depend on
> > pkg-config. The mere presence of a .pc file in the -dev package of the
> > library does *not* mean that only pkg-config is supported. e.g. where a
> > library requires the use of an m4 macro that involves calling
> > pkg-config, this would require the -dev package to depend on pkg-config
> > but if a library provides a .pc file but also supports alternative
> > method(s), the -dev package does not need to depend on pkg-config.
> > 
> > 2. If a source package uses libraries that package a .pc but where all
> > the libraries also support other methods of obtaining the relevant data,
> > and the source package requires the use of pkg-config despite those
> > other methods being available, then that choice by the source package
> > upstream must result in a Build-Depends on pkg-config in the source
> > package.
> > 
> > Is that suitable as a Policy clause? (probably needs a few tweaks for
> > clarity and examples in clause 1).
> 
> Wow, that's awfully complicated. This is much more straightforward:
> 
>   "If a package wants to call /usr/bin/foo during build and fails
>   to build properly if /usr/bin/foo is not present, then the
>   package MUST Build-Depend: on some other package providing
>   /usr/bin/foo".
> 
> And by this definition, it is the package _invoking_ pkg-config that
> should Build-Depend on it, not the package that happens to ship a .pc
> file.
> 

Here is another example supporting Gabor's proposal over Neil's:

Package libfoo-dev version 1.0.4 only documents how to use libfoo via
pkg-config.  Package bar build-depends on libfoo-dev >= 1.0.4 and uses
pkg-config to locate libfoo.so.1 etc.  Under Neil's rules, libfoo-dev would
Depends: pkg-config, bar would not Build-Depends: pkg-config.  Under Gabor's
rules, bar would Build-Depend pkg-config, but libfoo-dev would only
Recommends: pkg-config.

Now libfoo-dev version 1.0.5 is uploaded.  libfoo-dev is 100% backward
compatible so there is no change in so-name.  But libfoo-dev 1.0.5 adds
documentation on how to use libfoo without using pkg-config.  Under both
rules, this means that libfoo-dev 1.0.5 now only Suggests: pkg-config. 
Under Neil's rules, the unchanged bar source package would now FTBS and it
would be bar's fault.  Under Gabor's rules, the unchanged bar source package
would continue to build and continue to be compliant and nothing would need
to be done.

However just to clarify on some other examples elsewhere in this thread,
the following rules may need to be added:

   2. If libfoo-dev contains scripts which would typically be called by
 packages that Depend, Pre-Depend or Build-Depend on libfoo-dev, then
 anything needed by those scripts should (RFC-should) be ordinary
 Depends for the libfoo-dev package.  For instance if programs building
 against libfoo would typically call /usr/bin/foo-config-get, then
 anything called by foo-config-get (such as pkg-config or perl) would
 need to be listed as Depends for libfoo-dev.  Note that this does not
 extend to anything otherwise needed by callers to take advantage of
 files in libfoo-dev.  For instance the presence of .h files in
 libfoo-dev does not imply a Depends: c-compiler, nor would .pc files
 imply a Depends: pkg-config.

   3. Similarly, the fact that libfoo Depends: libbar for its runtime needs
 has no reason to imply that libfoo-dev should Depend: libbar-dev, such
 a need would arise only if the public (not private) .h files for libfoo
 #include some files provided only by by libbar-dev etc or if libfoo.a
 is included and useless without libbar.a.  A weaker dependency
 (Recommends or Suggests) would be sufficient if only rarely used public
 .h files or rarely linked members of libfoo.a need libbar-dev.

-- 
#include 
I am subscribed to -policy but not -devel, no need to cc me on replies to
-policy.


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

Re: Misc development news (#6) (DEB_BUILD_OPTIONS=noopt)

[Manoj Srivastava]

On Wed, 16 Apr 2008 18:38:39 +0100, Darren Salt <[EMAIL PROTECTED]> said: 

> I demand that Loïc Minier may or may not have written...
>> On Wed, Apr 16, 2008, Raphael Hertzog wrote:
>>> But I disagree that debian/rules is necessarily the place where it
>>> belongs. It looks like cruft/bad design to have the same snippet of
>>> code in all packages.

>> Perhaps this should be fixed in another way then?  For example a
>> shared Makefile included by all debian/rules (if they are a makefile
>> :) -- ala cdbs, but with a simple documented interface such as
>> documenting that this will set *FLAGS based on deb_build_opts.  e.g.
>> /usr/share/dpkg/flags.mk with:
>>  CFLAGS += -Wall -g -O$(if $(findstring noopt,$(DEB_BUILD_OPTIONS)),0,2)

> That looks reasonable to me.

Hmm. Smells a lot like:
--8<---cut here---start->8---
 ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
CFLAGS += -O0
 else
CFLAGS += -O2
 endif
--8<---cut here---end--->8---

See §10.1. Binaries.

> However, care should be taken to avoid ending up with
> cdbs-buildpackage ;-)

manoj
-- 
"I'd love to go out with you, but I want to spend more time with my
blender."
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: Should -dev packages providing .pc files depend on pkg-config?

[Manoj Srivastava]

On Wed, 16 Apr 2008 19:15:53 +0200, Goswin von Brederlow
<[EMAIL PROTECTED]> said:  

> You are missing the point.

> What if the library says "You must call /usr/bin/foo during build"?

How does the library say that? Why can't I just have
 gcc -o baz baz.c -lfoo

How can the library make that not work?

> The libarry does not use foo, only the user, so no depends?  Or idoes
> forcing users to use foo make foo part of the API and hence the
> library should depend on it?

If the library can be used without calling /usr/bin/foo? I mean,
 I know it is a convenience function, but it does not, in fact, force
 anyone to use foo, or pkg-config, or anything,

__> pkg-config --cflags --libs libselinux
 -lselinux  

Which is, err, nice. But You can, you know, just use -lselinux
 in your Makefile. I don't see why libselinux-dev needs to depend on
 pkg-config. Or even recommend it.

manoj
-- 
Always look over your shoulder because everyone is watching and plotting
against you.
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: Should -dev packages providing .pc files depend on pkg-config?

[Neil Williams]

On Wed, 2008-04-16 at 22:12 +0200, Jakob Bohm wrote:
> On Wed, Apr 16, 2008 at 04:12:45PM +0200, Gabor Gombas wrote:
> > On Wed, Apr 16, 2008 at 11:23:51AM +0100, Neil Williams wrote:
> > 
> > > What about these clauses as a Policy amendment?
> > > 
> > > 1. If a library *only supports the retrieval of FOO_LIBS and / or
> > > FOO_CFLAGS by the use of pkg-config*, pkg-config becomes part of the API
> > > of that library and the -dev package of that library must depend on
> > > pkg-config. The mere presence of a .pc file in the -dev package of the
> > > library does *not* mean that only pkg-config is supported. e.g. where a
> > > library requires the use of an m4 macro that involves calling
> > > pkg-config, this would require the -dev package to depend on pkg-config
> > > but if a library provides a .pc file but also supports alternative
> > > method(s), the -dev package does not need to depend on pkg-config.
> > > 
> > > 2. If a source package uses libraries that package a .pc but where all
> > > the libraries also support other methods of obtaining the relevant data,
> > > and the source package requires the use of pkg-config despite those
> > > other methods being available, then that choice by the source package
> > > upstream must result in a Build-Depends on pkg-config in the source
> > > package.
> > > 
> > > Is that suitable as a Policy clause? (probably needs a few tweaks for
> > > clarity and examples in clause 1).
> > 
> > Wow, that's awfully complicated. This is much more straightforward:
> > 
> > "If a package wants to call /usr/bin/foo during build and fails
> > to build properly if /usr/bin/foo is not present, then the
> > package MUST Build-Depend: on some other package providing
> > /usr/bin/foo".
> > 
> > And by this definition, it is the package _invoking_ pkg-config that
> > should Build-Depend on it, not the package that happens to ship a .pc
> > file.
> > 
> 
> Here is another example supporting Gabor's proposal over Neil's:
> 
> Package libfoo-dev version 1.0.4 only documents how to use libfoo via
> pkg-config.  Package bar build-depends on libfoo-dev >= 1.0.4 and uses
> pkg-config to locate libfoo.so.1 etc.  Under Neil's rules, libfoo-dev would
> Depends: pkg-config, bar would not Build-Depends: pkg-config.  Under Gabor's
> rules, bar would Build-Depend pkg-config, but libfoo-dev would only
> Recommends: pkg-config.

No - bar would Build-Depends: pkg-config because it contains
a ./configure script that calls pkg-config - that's why some duplication
will always occur, precisely to prevent these failures. A duplicate
depends is not a problem.

Your example states: "bar uses pkg-config to locate libfoo.so.1" - bar
calls pkg-config so it must depend on it - in this case Build-Depends:.

That was the result of an over-zealous edit of the clauses. Sorry.

0 If a source package calls pkg-config directly, it must Build-Depend
on pkg-config.

> > > 2. If a source package uses libraries that package a .pc but where all
> > > the libraries also support other methods of obtaining the relevant data,
> > > and the source package requires the use of pkg-config despite those
> > > other methods being available, then that choice by the source package
> > > upstream must result in a Build-Depends on pkg-config in the source
> > > package.

From another message:

If we stick with the idea of "you call it, you depend on it", these
situations become a lot clearer.

If foo-config changes internally to not call pkg-config anymore, that
allows the -dev to drop the pkg-config dependency. What is wrong,
therefore, is for the package using foo-config to expect that the -dev
continues to provide pkg-config and to then use pkg-config itself for
other things *without* a dependency.

i.e. a duplicate dependency is the best approach here.

> However just to clarify on some other examples elsewhere in this thread,
> the following rules may need to be added:
> 
>2. If libfoo-dev contains scripts which would typically be called by
>  packages that Depend, Pre-Depend or Build-Depend on libfoo-dev, then
>  anything needed by those scripts should (RFC-should) be ordinary
>  Depends for the libfoo-dev package.  For instance if programs building
>  against libfoo would typically call /usr/bin/foo-config-get, then
>  anything called by foo-config-get (such as pkg-config or perl) would
>  need to be listed as Depends for libfoo-dev.  Note that this does not
>  extend to anything otherwise needed by callers to take advantage of
>  files in libfoo-dev.  For instance the presence of .h files in
>  libfoo-dev does not imply a Depends: c-compiler, nor would .pc files
>  imply a Depends: pkg-config.
> 
>3. Similarly, the fact that libfoo Depends: libbar for its runtime needs
>  has no reason to imply that libfoo-dev should Depend: libbar-dev, such
>  a need would arise only if the public (not private) .h files for libfoo
>  #include some files provided on

Re: Bits from the DPL: FTP-master & DAM delegations

[Hamish Moffatt]

On Thu, Apr 17, 2008 at 12:32:17AM +0200, Sam Hocevar wrote:
>Dear Developers,
> 
>Now that I have your attention, I would like to make the following
> delegations:
> 
>  1. Joerg Jaspert <[EMAIL PROTECTED]> is appointed FTP-master.
> 
>  2. Joerg Jaspert <[EMAIL PROTECTED]> is made a full Debian Account
>  Manager and is therefore empowered to create and remove developer
>  accounts according to the New Maintainer procedure.
> 
>These delegations are effective until revoked by the DPL or by a
> resolution.

Terrific!

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


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

Re: missing package conflicts

[Ben Hutchings]

On Wed, 2008-04-16 at 15:44 -0400, Daniel Schepler wrote:

> I'd be interested in seeing how there can be 75 package pairs with shared 
> file 
> names which coinstall successfully.  In the case of a Replaces making that 
> possible, I'd say that the package with files being replaced should usually 
> have a bug report submitted to get those obsolete files removed.  On the 
> other hand, if there's a diversion involved, that seems fine.

These are surely cases of diversions.  Diversions aren't visible in
package metadata, since they're carried out by the preinst script.  The
only sure way to check for them is to have dpkg run the script, which
the final figure of 27 conflicts is based on.

Ben.

-- 
Ben Hutchings
Life would be so much easier if we could look at the source code.


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

Re: missing package conflicts

[Ralf Treinen]

On Wed, Apr 16, 2008 at 11:20:21PM +0100, Ben Hutchings wrote:
> On Wed, 2008-04-16 at 15:44 -0400, Daniel Schepler wrote:
> 
> > I'd be interested in seeing how there can be 75 package pairs with shared 
> > file 
> > names which coinstall successfully.  In the case of a Replaces making that 
> > possible, I'd say that the package with files being replaced should usually 
> > have a bug report submitted to get those obsolete files removed.  On the 
> > other hand, if there's a diversion involved, that seems fine.
> 
> These are surely cases of diversions.  Diversions aren't visible in
> package metadata, since they're carried out by the preinst script.  The
> only sure way to check for them is to have dpkg run the script, which
> the final figure of 27 conflicts is based on.

The remaining 75 package pairs do not fail to install *due to file
overwriting*. Most of them succeed to install, but some fail to
install for reasons different from file overwriting.

In fact most of them use diversions, but not all of them.
Some packages are mentionend in the Contents file but do not
actually exist in the distribution. One reason is certainly that
the Contents file is about main+contrib+nonfree while I do
installation tests only from main. I will fix that for the next run.

I agree that the remaining 75 cases also deserve some investigation.

-Ralf.


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

Bug#476482: ITP: ocamlpam -- OCaml bindings for the PAM library

[Stephane Glondu]

Package: wnpp
Severity: wishlist
Owner: Stephane Glondu <[EMAIL PROTECTED]>

* Package name: ocamlpam
  Version : 1.0
  Upstream Author : Sharvil Nanavati <[EMAIL PROTECTED]>
* URL : http://sharvil.nanavati.net/projects/ocamlpam/
* License : MIT
  Programming Lang: C/OCaml
  Description : OCaml bindings for the PAM library

OCamlPAM is a wrapper for the Pluggable Authentication Modules (PAM)
library. PAM provides a flexible mechanism for authenticating users
via administrator-defined policies. PAM has modules for authenticating
via Unix passwd files, Kerberos, LDAP, etc. Additional modules for
custom authentication mechanisms can be created and deployed without
recompiling existing services based on PAM. Moreover, policies
defining the authentication requirements can be changed at runtime
without restarting running services.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Re: RFH: Multiarch capable toolchain as release goal

[Goswin von Brederlow]

Luk Claes <[EMAIL PROTECTED]> writes:

> Goswin von Brederlow wrote:
>> Wed, 21 Jun 2006 00:48:26 +0200: NMU attempt gets vetoed
>
> Nope, this is only a patch with a mail subject 'Patch for pending NMU of
> binutils'

The BTS doesn't show it but it was vetoed.

>> Wed, 28 Jun 2006 11:01:53 +0200: 2. maintainer misunderstands the patch
>> Thu, 29 Jun 2006 22:44:30 +0200: some discussion about the misunderstanding
>> Mon, 11 Sep 2006 15:58:28 +0200: patch update for the i386->i486 ABI change
>> Sun, 29 Apr 2007 00:12:48 +0200: prodding the maintainer for an reaction
>> Thu, 28 Jun 2007 03:43:16 +0100: first real reply by maintainer
>
> Patch was not ready...
>
>> Mon, 02 Jul 2007 19:14:35 +0200: patch fix for issues raise by maintainer
>
> Didn't look like the issue was settled as the mail of Aurélien on 03 Jul
> was ending questioning the patch...

He only tries to understand the problem of the i386->i486 ABI
change. That is actually a different issue and a bug that was
introduced into binutils when dpkg changed the architecture from i386
to i486. Doesn't quite belong in this bug but should be seperate.

The problem is that binutils defaults to i386-linux-gnu for the ia32
abi and debian/rules overrides that through the host/target options to
configure on i386. On amd64 though the host/target says
x86_64-linux-gnu and binutils mangles that internally to
i386-linux-gnu for the ia32 abi. There is no option to configure to
set the gnu tripplet for the alternative abis binutils builds beside
the main one.

The effect is that binutils currently has different crosscompile
directories for ia32 abi on i386 and amd64. The
140_amd64_has_i486_subtarget.dpatch patch at the end of the report
works around the issue by changing the mangling.

>> Thu, 26 Jul 2007 15:56:45 +0200: patch split into the ABI and multiarch parts
>> 
>> An NMU was tried and it and all future NMU where vetoed by the maintainer.
>
> I only see discussion about the misunderstanding of a patch and fixing
> of the patch after the maintainer comment.
>
> There was no mail asking if it was allright to NMU, nor a real NMU
> attempt AFAICS...
>
>> In summary:
>> 
>> - 13 month from initial report to raising a minor issue that has no
>>   negative effects on the functionality
>> - 4 days to fix the issue
>
> Not clear from the bug log that everything was right already...

The only issue the maintainer had with the patch was fixed. I still
think the original one was more right but the maintainer wished
otherwise and got his wish. 

>> - 9 month without reaction and counting
>
> 9 month waiting instead of trying to resolve the issue...

I did ask Mathias (doko) on irc a few times about it without responce
and James has me on ignore so there is no point asking him. But that
isn't aparent from the BTS.

As summarised: no reaction. Doesn't say no trying.

> Btw looks like a very colored summary to me...

and it is green. Or is it purple?

> If I want a feature to be included in a package which the maintainer is
> not really interested in, I would make sure that my patch would be ready
> to apply and/or make sure I tried to actually NMU...
>
> Cheers
>
> Luk
>
> PS: I would not mind having multiarch support myself...

MfG
Goswin


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

Re: Rejected: epcr_2.3.9-1.dsc: sha1 check failed

[Charles Plessy]

Le Wed, Apr 16, 2008 at 04:39:56PM +0100, Adam D. Barratt a écrit :
> Andreas Tille wrote:
> >Rejected: epcr_2.3.9-1.dsc: sha1 check failed.
> >Rejected: epcr_2.3.9-1.dsc: actual file size (1289) does not match
> >size (1052) in .changes sha1 Rejected: epcr_2.3.9-1.dsc: sha256 check
> >failed. Rejected: epcr_2.3.9-1.dsc: actual file size (1289) does not match
> >size (1052) in .changes sha256
> 
> As Matthew said, you need to make sure you're using devscripts 2.10.25 so 
> that debsign knows to update the file size in the new Checksums-* fields.

Should dpkg-dev conflict with devscripts < 2.10.25, then ? This would
not solve all problems, but at least some of them.

Have a nice day,

-- 
Charles Plessy
http://charles.plessy.org
Wakō, Saitama, Japan


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

Re: Misc development news (#6)

[Paul Wise]

On Wed, Apr 16, 2008 at 9:24 PM, Roberto C. Sánchez
<[EMAIL PROTECTED]> wrote:

>  > Good idea.  I just added screenshots.debian.org idea that came up on
>  > some discussion at Chemnitzer LinuxTage in March.  It would be nice if
>  > somebody would grab this up - at least the idea will not just vanish
>  > now it is stored somewhere ...
>
>  This is something that I propsed on January 3, 2007, on debian-devel.
>  There was a fairly lengthy thread that resulted and Thomas Viehmann even
>  offered to help.  Of course, he and I both became very busy and so it
>  sort of fell by the wayside.  However, I have my projects much better in
>  hand this year and I intend to resurrect the idea early this summer.

The games team had a short discussion about screenshots, goplay and
packages.d.o recently too:

http://lists.debian.org/debian-devel-games/2008/03/threads.html#00071

-- 
bye,
pabs

http://wiki.debian.org/PaulWise

Re: Rejected: epcr_2.3.9-1.dsc: sha1 check failed

[Roberto C . Sánchez]

On Wed, Apr 16, 2008 at 04:25:46PM +0100, Matthew Johnson wrote:
> On Wed Apr 16 17:19, Andreas Tille wrote:
> > Hi,
> >
> > it is the third time that I've got this type of rejection.  I faced
> > it two times with package gnumed-client and now with a different package.
> >
> > Is anybody able to explain this and how can I avoid the problem.  I
> > just builded the package with an up to date pbuilder.
> 
> do you have updated devscripts? debsign signs the dsc then updates the
> md5 hash in the changes before signing that. It needs to update the sha
> checks as well. The latest devscripts does.
> 
Will the devscripts in stable be updated to handle this?  If so, when?
If not, why not?

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

shrishanidev invites you to join Zorpia

[shrishanidev]

   
Hi !
Your friend shrishanidev from  , just invited you to  his/her  online photo 
albums and journals at Zorpia.com.



So what is Zorpia?
It is an online community that allows you to upload unlimited amount of photos, 
write journals and make friends. We also have a variety of skins in store for 
you so that you can customize your homepage freely.

Join now for free! Please click the following link to join Zorpia:
http://signup.zorpia.com/signup?invitation_key=20061150525e3d7e587ac678d40dd9c0&referral=shrishanidev

This message was delivered with the shrishanidev's initiation.

If you wish to discontinue receiving invitations from us, please click the 
following link:
http://signup.zorpia.com/email/optout/debian-devel@lists.debian.org

Re: Bits from the DPL: FTP-master & DAM delegations

[Andreas Tille]

On Thu, 17 Apr 2008, Hamish Moffatt wrote:


On Thu, Apr 17, 2008 at 12:32:17AM +0200, Sam Hocevar wrote:

   Dear Developers,

   Now that I have your attention, I would like to make the following
delegations:

 1. Joerg Jaspert <[EMAIL PROTECTED]> is appointed FTP-master.

 2. Joerg Jaspert <[EMAIL PROTECTED]> is made a full Debian Account
 Manager and is therefore empowered to create and remove developer
 accounts according to the New Maintainer procedure.

   These delegations are effective until revoked by the DPL or by a
resolution.


Terrific!


Congratulations to old DPL and new FTP-master / DAM.  The new DPL will
have a hard time to beat this success - good luck anyway!

It's fun to be in Debian these days

   Andreas.

--
http://fam-tille.de


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

Re: Rejected: epcr_2.3.9-1.dsc: sha1 check failed

[Luk Claes]

Charles Plessy wrote:
> Le Wed, Apr 16, 2008 at 04:39:56PM +0100, Adam D. Barratt a écrit :
>> Andreas Tille wrote:
>>> Rejected: epcr_2.3.9-1.dsc: sha1 check failed.
>>> Rejected: epcr_2.3.9-1.dsc: actual file size (1289) does not match
>>> size (1052) in .changes sha1 Rejected: epcr_2.3.9-1.dsc: sha256 check
>>> failed. Rejected: epcr_2.3.9-1.dsc: actual file size (1289) does not match
>>> size (1052) in .changes sha256
>> As Matthew said, you need to make sure you're using devscripts 2.10.25 so 
>> that debsign knows to update the file size in the new Checksums-* fields.
> 
> Should dpkg-dev conflict with devscripts < 2.10.25, then ? This would
> not solve all problems, but at least some of them.

It wouldn't solve much as dpkg-dev is used in the build environment
(unstable), while the troublesome signing is done in a
production/desktop environment (oldstable/stable/whatever).

Cheers

Luk


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

Re: Should -dev packages providing .pc files depend on pkg-config?

[Tollef Fog Heen]

* Manoj Srivastava 

| On Wed, 16 Apr 2008 19:15:53 +0200, Goswin von Brederlow
| <[EMAIL PROTECTED]> said:  
| 
| > You are missing the point.
| 
| > What if the library says "You must call /usr/bin/foo during build"?
| 
| How does the library say that? Why can't I just have
|  gcc -o baz baz.c -lfoo
| 
| How can the library make that not work?

By not shipping the libraries in /usr/lib:

> pkg-config --libs valgrind
-L/usr/lib/valgrind/amd64-linux -lcoregrind -lvex -lgcc

[...]

| __> pkg-config --cflags --libs libselinux
|  -lselinux  
| 
| Which is, err, nice. But You can, you know, just use -lselinux
|  in your Makefile. I don't see why libselinux-dev needs to depend on
|  pkg-config. Or even recommend it.

Yes, in the simple case, you can just do this.  In the more complex
case (which upstream might want to cater for), you need to use
pkg-config.  pkg-config allows you to, say, move all the headers from
each package into its own namespace, like how GTK+ and Glib does it
and you can then rename that later if you so wish, without causing
FTBFS-es.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


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

Re: Should -dev packages providing .pc files depend on pkg-config?

[Tollef Fog Heen]

* Neil Williams 

| That is an example of a library including pkg-config into the library
| API. Changing that behaviour (dropping the script) means a SONAME bump.

No, changing an API without changing the ABI does not mean a SONAME
bump.  SONAMEs are for ABIs, not APIs and one can change without the
other changing.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


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

Re: Default value for CFLAGS/LDFLAGS set by dpkg

[Steve Langasek]

On Tue, Apr 01, 2008 at 11:15:37AM +0200, Josselin Mouette wrote:
> On mar, 2008-04-01 at 01:21 -0700, Steve Langasek wrote:
> > On Mon, Mar 31, 2008 at 06:57:48PM +0200, Kurt Roeckx wrote:
> > > I also have to wonder that if we have something like this as default,
> > > why -Bsymbolic-functions would be a good default, and not -Bsymbolic.

> > I'm told the difference is that the former is safe to use as an option when
> > linking executables, and the latter is not.

> According to the documentation, both only apply to shared libraries;
> AIUI, local symbols are always used by default for programs.

> Also, do you know why it would be safe for functions and not for other
> symbols?

The difference was that -Bsymbolic causes build problems with executables,
and -Bsymbolic-functions does not.

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


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

Re: Bits from the DPL: FTP-master & DAM delegations

[Stefano Zacchiroli]

On Thu, Apr 17, 2008 at 08:35:38AM +1000, Hamish Moffatt wrote:
> >  1. Joerg Jaspert <[EMAIL PROTECTED]> is appointed FTP-master.
> > 
> >  2. Joerg Jaspert <[EMAIL PROTECTED]> is made a full Debian Account
> >  Manager and is therefore empowered to create and remove developer
> >  accounts according to the New Maintainer procedure.
> >These delegations are effective until revoked by the DPL or by a
> > resolution.
> Terrific!

\o/ go Sam go!!!

... and, of course: go Joerg go :)

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: Should -dev packages providing .pc files depend on pkg-config?

[Manoj Srivastava]

On Thu, 17 Apr 2008 07:58:44 +0200, Tollef Fog Heen <[EMAIL PROTECTED]> said: 

> * Manoj Srivastava
>> On Wed, 16 Apr 2008 19:15:53 +0200, Goswin von Brederlow
>> <[EMAIL PROTECTED]> said:
>> 
>> > You are missing the point.
>> 
>> > What if the library says "You must call /usr/bin/foo during build"?
>> 
>> How does the library say that? Why can't I just have gcc -o baz baz.c
>> -lfoo
>> 
>> How can the library make that not work?

> By not shipping the libraries in /usr/lib:

>> pkg-config --libs valgrind
> -L/usr/lib/valgrind/amd64-linux -lcoregrind -lvex -lgcc

And how exactly does this prevent me from doing:
baz: baz.c
gcc -o baz baz.c -L/usr/lib/foo/amd64-linux -lfoo



> [...]

__> pkg-config --cflags --libs libselinux
>> -lselinux
>> 
>> Which is, err, nice. But You can, you know, just use -lselinux in
>> your Makefile. I don't see why libselinux-dev needs to depend on
>> pkg-config. Or even recommend it.

> Yes, in the simple case, you can just do this.  In the more complex
> case (which upstream might want to cater for), you need to use
> pkg-config.  pkg-config allows you to, say, move all the headers from
> each package into its own namespace, like how GTK+ and Glib does it
> and you can then rename that later if you so wish, without causing
> FTBFS-es.

No, I do not need to do any such thing. I can just inspect the
 files shipped, and adjust accordingly.  It is _convenient_ to use
 pkg-config, but I am not forced to use it.  We have been linking
 libraries for _decades_ before pkg-config was invented

So, if you want to use the convenience of pkg-config; build
 depend on it.

manoj
-- 
Nirvana?  That's the place where the powers that be and their friends
hang out. Zonker Harris
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]