Re: [Debconf-discuss] GPG keysigning?

[martin f krafft]

also sprach Manoj Srivastava  [2009.06.23.0325 +0200]:
> Now, Madduck wants us to say that there is no need for this
> broader identity verification mechanism, that oe should just trust
> him, and there shall be a means of smiting evil doers just the
> same -- but after debconf 6 --- his track record for trust on
> identification schemes runs pretty low.

This is an accusation for which you have no data. Do you know which
keys I signed since then, and on what basis?

I also never said that you should trust me.

Anyway, no interest to continue this discussion on a personal level.

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
a c programmer asked whether computers have buddha's nature.
as the answer, the master did "rm -rf" on the programmer's home
directory. and then the c programmer became enlightened...


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [Debconf-discuss] GPG keysigning?

[martin f krafft]

also sprach Russ Allbery  [2009.06.23.0158 +0200]:
> > However, if you want to tie that key owner to a real person, to
> > somehow (my speculation) bring down the wrath on the community
> > on someone who does something nasty or  subverts the DMUP or
> > causes the FSM to weep, well, you need the meet and greet and
> > key signing stuff. Smiting evil dooers seems to be the major
> > cause that justifies this exerciser, since otherwise the person
> > can just dump their key, change their email, and get away scot
> > free. Hard to smite them then.
> 
> I think this is the key point, plus just a general sort of raising
> the effort required for someone to subvert the system as Manoj
> also mentions.

Right, but where's the borderline? Having gone through the process
of getting an ID from the Transnational Republic, I would have no
trouble imagining that somewhere else on this earth there's a lot
less scrutiny involved when a government ID is issued.

While I still maintain that a community-signed GPG key of a meanie
is not going to allow for a better indictment in court, I see the
argument about the proxy. However, given the broad spectrum of
governments and their standards, I think the cut-off point is
convenient, but not really useful.

Obviously we cannot pick an elite group of countries and deny
signing to citizens whose governments don't have the resources for
rigorous processes or fancy documents, or who are simply corrupt, so
we just accept them all, as long as it's a government.

It might be asking a bit much to expect people to know whether
a given country actually exists, too. I remember people asking me
where the Transnational Republic was.

> Meeting in person and exchanging government ID or something that
> looks good enough to fool people is a compromise position, but
> I do think there's a general feeling that it's close to a sweet
> spot in that tradeoff for what we want out of our web of trust.

Alright, I agree that it's not as useless as I sometimes portray it.
But it's still woefully arbitrary.

-- 
 .''`.   martin f. krafft 
: :'  :  DebConf orga team; press officer
`. `'`
  `-  DebConf9: 24-30 Jul 2009, Extremadura, ES: http://debconf9.debconf.org
 
it is ok to let your mind go blank, but please turn off the sound.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

CDBS - how to source a shell fragement before running ./configure?

[Carsten Aulbert]

Hi,

as suggested on debian-user I repost my question here (sorry for the
cross post, but I think it's better than send to individual emails to
both lists, feel free to remove the other list)

I'm currently packaging some "internal" software named gds with the
great CDBS package. However, I have a problem. One of the build
dependencies installs things into a non-standard system location (read
/opt) and I need to source one file to let the configure script know
where to look for certain software.

Right now my debian/rules file looks like:
#!/usr/bin/make -f

MAJOR_VER := 2.13
DEB_TAR_SRCDIR:=gds-2.13.1
INSTALL_PREFIX:=/opt/lscsoft/gds

include /usr/share/cdbs/1/rules/tarball.mk
include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/autotools.mk

DEB_CONFIGURE_NORMAL_ARGS := --prefix=$(INSTALL_PREFIX)
--libdir=$(INSTALL_PREFIX)/lib --enable-online --enable-dtt
CFLAGS += -D_POSIX_C_SOURCE=199309 -fPIC

--8><8><

This one works provided I source /opt/foo/bar.sh before running
dpkg-buildpackage. Obviously, I would like to get this included into the
rules file, however, my current attempts failed since it seems that the
"source" only happens in a subshell and the remaining (inlcuded makefile
snippets odn't know about this)

I'm adding this to the debian/rules file:

makebuilddir/gds::
source /opt/foo/bar.sh

which subsequently leads the configure script to fail when detecting
software available under /opt

Any idea how to solve this? If possible I'd like to stay with CDBS :)

Is there a way to "import" the additions the source'd file makes to the
environment into the makefile?

I've read a lot of pages returned by google, however, they did not
really help me.

TIA

Carsten

PS: Please CC me


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [Debconf-discuss] GPG keysigning?

[Russ Allbery]

Manoj Srivastava  writes:
> On Mon, Jun 22 2009, Russ Allbery wrote:

>> Going back to the previous discussion in debian-devel about signing a
>> key for which the only IDs are pseudonyms, I personally would do
>> that, but only if I knew the person personally and knew they were the
>> person who used that pseudonym.  Which means that in the event of
>> smiting being necessary, I would personally be able to trace that key
>> to a person.

> The key signing then works for you to keep a marker that you
>  know the person behind the key, but it does not help the Debian project
>  at large, since you know where to deliver the smite, the current or
>  future officers of the project may not (especially if you have lost
>  interest and moved on to better things, as happen to people).

For me, there are different levels of reproducibility required in
signing a PGP key and in welcoming that person as a Debian Developer.
I'm comfortable signing a key for a pseudonym under some circumstances,
but I would be a lot more leery of accepting a Debian Developer only
known to the project under a pseudonym, even if I knew who the person
was personally.  I could see it, but the circumstances would have to be
fairly exceptional.

> The thing is, your identification scheme fails the
>  reproducibility test; there is no way that the person with the pseudo
>  (i.e. lie [0]) name can't reproduce the identification challenge
>  with, say, me, or any wider test authority that does not belong to
>  the small subset of the people who know the person behind the key
>  well enough to make the smiting a viable deterrent,

Right, this is something that I don't think is necessary for signing a
key but which I would be more concerned with in adding someone as a
Debian Developer.

I sign role keys as well, which to me is a similar situation, but I
wouldn't want someone to be able to upload to the repository using a
role key.

> The set of people familiar with the travel documents is likely
>  to be larger, and there are back channels to the authoritative
>  distributors which can be used to deliver the smite to, independent of
>  personal shared history with the aforementioned individual.

For many Debian developers, I have no idea what country they're even
from, and some names are quite common and not particularly useful as
unique identifiers.  I'm unlikely to remember the details of the
government-issued ID that I saw when signing their key.

I'm much more likely to be able to track down someone who would meet my
standard for signing a key under a pseudonym than someone who I met at a
key-signing party and checked via government ID.

It is, however, a lot harder to write simple and straightforward rules
around how one would do that sort of verification than it is to write
the rules for a key-signing party using government ID.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [Debconf-discuss] GPG keysigning?

[Manoj Srivastava]

On Mon, Jun 22 2009, Russ Allbery wrote:

> Manoj Srivastava  writes:

>> So while signing keys is not about governments, as Russ said, it
>>  is about establishing identity, and government issued identity
>>  documents are better proxies for establishing that than I can be
>>  bothered to do myself.
>
> Particularly given that if one does need to smite, the process of
> smiting is likely to be done via a goverment, presumably the one that
> issued the identity papers in the first place.  So there is a reasonable
> connection.
>
> Security is always a tradeoff -- it's just about where you want to put
> the tradeoff between verification work and convenience.  There are a lot
> of things that we could do that other organizations do, like hire
> private investigators to do background checks (which seems to be coming
> routine for employment in the US, at least in a cursory way).  Or we
> could sign keys based on e-mail interactions.
>
> Meeting in person and exchanging government ID or something that looks
> good enough to fool people is a compromise position, but I do think
> there's a general feeling that it's close to a sweet spot in that
> tradeoff for what we want out of our web of trust.

> Going back to the previous discussion in debian-devel about signing a
> key for which the only IDs are pseudonyms, I personally would do that,
> but only if I knew the person personally and knew they were the person
> who used that pseudonym.  Which means that in the event of smiting being
> necessary, I would personally be able to trace that key to a person.

The key signing then works for you to keep a marker that you
 know the person behind the key, but it does not help the Debian project
 at large, since you know where to deliver the smite, the current or
 future officers of the project may not (especially if you have lost
 interest and moved on to better things, as happen to people).

The thing is, your identification scheme fails the
 reproducibility test; there is no way that the person with the  pseudo
 (i.e. lie [0]) name can't reproduce the identification challenge with,
 say, me, or any wider test authority that does not belong to the small
 subset of the people who know the person behind the key well enough to
 make the smiting a viable deterrent,

The set of people familiar with the travel documents is likely
 to be larger, and there are back channels to the authoritative
 distributors which can be used to deliver the smite to, independent of
 personal shared history with the aforementioned individual.

Now, Madduck wants us to say that there is no need for this
 broader identity verification mechanism, that oe should just trust him,
 and there shall be a means of smiting evil doers just the same -- but
 after debconf 6 --- his track record for trust on identification
 schemes runs pretty low.  Me, I would like there to be a well
 established identification process that does not merely rely on a
 shared history.  The travel document things raises the bar higher -- by
 either collusion, or by the ability to spoof the signer (unfortunately,
 that bar is rather low at mass key signings).

manoj

[o]
  Pseudo- \Pseu"do-\ [Gr. pseydh`s lying, false, akin to psey`dein
 to belie; cf. psydro`s lying, psy`qos a lie.]
 A combining form or prefix signifying false, counterfeit,
 pretended, spurious; as, pseudo-apostle, a false apostle;
 pseudo-clergy, false or spurious clergy; pseudo-episcopacy,
 pseudo-form, pseudo-martyr, pseudo-philosopher. Also used
 adjectively.
 [1913 Webster]

-- 
Be wary of strong drink.  It can make you shoot at tax collectors and
miss. Lazarus Long, "Time Enough for Love"
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [Debconf-discuss] GPG keysigning?

[Manoj Srivastava]

On Mon, Jun 22 2009, martin f krafft wrote:

> Does it matter whether I have a passport that carries my name, or
> whether the name on my key, with which I consistently identify
> myself in Debian, is actually my own name? Why would anyone care?

This is getting silly enough that we probably want to back off a
 bit and examine what we really want to do here.

So, I see a reason for having a gpg sig signed by other people
 is accountability: we want to tie a online persona to a real person in
 some way (if not, there is no point in signing keys; you just make
 every contributor sign with whatever keys they want, and just let that
 key owner build up a trust in their competence/integrity/homage to the
 holy penguin pee/whatever.

You can send in your own signed message saying you have known
 the work signed by key foo for years, and you trust the owner of that
 key to turn in goodly work, and you think the owner of that key has the
 technical chops to belong to Debian, whatever. The key owner, of they
 change their key, will lose a lot of that trust the old key built,
 unless they can prove the new key owner is the same as the old key
 owner -- which means that we need to tie the keys together somehow. Of
 course, an interesting means of doing so is to somehow tie the key to a
 real person (heh).

This is all that is really needed for the integrity/trust of the
 work produced by a keys owner.

However, if you want to tie that key owner to a real person, to
 somehow (my speculation) bring down the wrath on the community on
 someone who does something nasty or  subverts the DMUP or causes the FSM
 to weep, well, you need the meet and greet and key signing
 stuff. Smiting evil dooers seems to be the major cause that justifies
 this exerciser, since otherwise the person can just dump their key,
 change their email, and get away scot free. Hard to smite them then.

Now really, we want to tie the key to a person -- even if they
 resleeve (a. la. Altered Carbon, [0]). Thankfully, releeving is not
 (yet) possible, so we don't have to deal with that. All we have to do
 is to tie a key to a real live person, and do it in a fashion that is
 reproducible and testable.

Traditionally, you establish identity for a person by one or
 more of:
   A) Something they (and only they) have. This is previously issued
  tokens of some kind (passports, id cards, secure tokens,
  etc). There are three things needed to make this even the least bit
  reliable: 
  1) You need to trust the process of deploying the thing they have;
 someone must establish in some manner who the person is, before
 the token is given out
  2) The token should not be easily duplicated, stolen, and
 reused. This requires some care on the part of the token holder
  3) You can actually verify that the token is genuine and decipher
 who the token was issued to without being spoofed.
   B) Something that the person is. Biometrics, etc. Again, the caveats
  apply about spoofing, and trusting you know what it is that the
  person is supposed to be (is it really Mr X's retina scan I am
  trying to match?)
   C) Something they know. Shared  secrets, passwords, knowledge of
  events past you and the person knows, and no one else could.

Madduck seems to put a whole lot of unjustified confidence in C)
 above.  You might think you know the person pretending to be Mr X, but
 really, most of us at debconf have done little to verify C to any
 degree of reliability. If all you can say is that person owns that
 email address, why are you even bothering to have a signing party? You
 don't need it to ascertain that a key owner controls an email address
 by some other persons signature; just send a encrypted message to that
 email address and ask for a reply. Done.

So, A. Now, most countries where people are allowed to come to
 my country from have to demonstrate a process by which they issue
 travel documents to their citizens, and I have established for myself
 that if  it meets the State departments needs, then !.1 is satisfied
 for me.

A.2 is somewhat harder, but  being careless about your travel
 documents has real world consequences, and most countries whose
 citizens can travel to mine have made travel docs hard to
 duplicate. Not impossible, but hard.
 
A.3 seems to be the part which receives most criticism; I can
 surely be spoofed by a well forged travel document. But it does raise
 the bar for someone who needs my signature, and I think it meets my
 threshold of return on effort to sign the key, and put a modicum of
 trust in the assertion that we have nailed that key to a real human
 being.

So while signing keys is not about governments, as Russ said, it
 is about establishing identity, and government issued identity
 documents are better proxies for establishing that than I can be
 bothered to do 

Re: [Debconf-discuss] GPG keysigning?

[Russ Allbery]

Manoj Srivastava  writes:

> However, if you want to tie that key owner to a real person, to
>  somehow (my speculation) bring down the wrath on the community on
>  someone who does something nasty or  subverts the DMUP or causes the FSM
>  to weep, well, you need the meet and greet and key signing
>  stuff. Smiting evil dooers seems to be the major cause that justifies
>  this exerciser, since otherwise the person can just dump their key,
>  change their email, and get away scot free. Hard to smite them then.

I think this is the key point, plus just a general sort of raising the
effort required for someone to subvert the system as Manoj also
mentions.

> So while signing keys is not about governments, as Russ said, it
>  is about establishing identity, and government issued identity
>  documents are better proxies for establishing that than I can be
>  bothered to do myself.

Particularly given that if one does need to smite, the process of
smiting is likely to be done via a goverment, presumably the one that
issued the identity papers in the first place.  So there is a reasonable
connection.

Security is always a tradeoff -- it's just about where you want to put
the tradeoff between verification work and convenience.  There are a lot
of things that we could do that other organizations do, like hire
private investigators to do background checks (which seems to be coming
routine for employment in the US, at least in a cursory way).  Or we
could sign keys based on e-mail interactions.

Meeting in person and exchanging government ID or something that looks
good enough to fool people is a compromise position, but I do think
there's a general feeling that it's close to a sweet spot in that
tradeoff for what we want out of our web of trust.

Going back to the previous discussion in debian-devel about signing a
key for which the only IDs are pseudonyms, I personally would do that,
but only if I knew the person personally and knew they were the person
who used that pseudonym.  Which means that in the event of smiting being
necessary, I would personally be able to trace that key to a person.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#519941: Remove Policy permission for packages to modify ld.so.conf

[Russ Allbery]

Darren Salt  writes:

> Perhaps this?
>
> * Install the binaries in /usr/lib/root.
> * Provide wrappers such as the following in /usr/bin:
>
>   #! /bin/sh -e
>   export LD_LIBRARY_PATH=/usr/lib/root"${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH}"
>   exec /usr/lib/root/"$(basename "$0")" "$@"

It's generally better to just set RPATH when building the binaries for
that case.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#519941: Remove Policy permission for packages to modify ld.so.conf

[Darren Salt]

I demand that Bill Allombert may or may not have written...

> On Sun, Jun 21, 2009 at 09:43:16PM +0200, Christian Holm Christensen wrote:
>> On Fri, 2009-06-19 at 21:25 -0700, Russ Allbery wrote:
[snip]
>> ROOT has libraries named like libMatrix, libPostscript, libPhysics,
>> libMath, and so on - i.e., very general names.   For that reason I moved
>> all the packages into the subdirectory /usr/lib/root to not cause
>> possible conflicts.   To make this work seamlessly for both the
>> root-system binaries and user code linked against the libraries, I dump a
>> file in /etc/ld.so.conf.d/.

> I understand this issue, but putting libMatrix in /usr/lib/root avoid file
> conflict with other package, do not address the problem of library name
> conflict at run-time.

Perhaps this?

* Install the binaries in /usr/lib/root.
* Provide wrappers such as the following in /usr/bin:

  #! /bin/sh -e
  export LD_LIBRARY_PATH=/usr/lib/root"${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH}"
  exec /usr/lib/root/"$(basename "$0")" "$@"

[snip]
-- 
| Darren Salt  | linux at youmustbejoking | nr. Ashington, | Doon
| Debian GNU/Linux | or ds,demon,co,uk| Northumberland | Army
| + RIPA NOTICE: NO CONSENT GIVEN FOR INTERCEPTION OF MESSAGE TRANSMISSION

The only way to make something foolproof is to keep it away from fools.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#534242: ITP: antihex -- Converts hex to decimal

[Harry Rickards]

Package: wnpp
Severity: wishlist
Owner: Harry Rickards 

* Package name: antihex
  Version : 0.02-1
  Upstream Author : Zhaolei 
  Maintainer  : Harry Rickards 
* URL : https://sourceforge.net/projects/antihex/
* License : GPL, version 3
  Section : math

AntiHex is a pipe to convert hex values into decimal. Ex: # cat
/proc/iomem -0009fbff : System RAM 0009fc00-0009 : reserved
 # cat /proc/iomem | ah -639K-1 : System RAM 639K -640K-1 :
reserved ...



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: dupload fatal error: Can't upload libgdcm-cil_2.0.10-5_amd64.deb

[Cyril Brulebois]

Mathieu Malaterre  (22/06/2009):
> Sorry this might be dumb, but I cannot get the *.commands to be signed
> as expected:

Use dcut.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: dupload fatal error: Can't upload libgdcm-cil_2.0.10-5_amd64.deb

[brian m. carlson]

On Mon, Jun 22, 2009 at 09:34:06PM +0200, Mathieu Malaterre wrote:
> $ gpg  --sign --armor gdcm.commands
> 
> It creates a separate .gpg file instead of appending the signature to
> the actual *.commands file...

Uh, I don't think you want --armor.  That signs the text and then
ascii-armors the entire thing, including the signed data.  You want
--clearsign.

HTH.

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


signature.asc
Description: Digital signature

Re: dupload fatal error: Can't upload libgdcm-cil_2.0.10-5_amd64.deb

[Mathieu Malaterre]

On Mon, Jun 22, 2009 at 9:22 PM, Joerg Jaspert wrote:
> On 11789 March 1977, Mathieu Malaterre wrote:
>
>>   I had a network issue and had to re-run dupload a second time. Now a
>> partially *.changes files was updated, and I cannot do anything
>> anymore:
>
> Either wait for the files to time out - or read the README in the
> directory you try to upload to, look for command files.

Sorry this might be dumb, but I cannot get the *.commands to be signed
as expected:


$ cat gdcm.commands
Uploader: Mathieu Malaterre 
Commands:
 rm gdcm_2.0.10-5.tar.gz
 rm libgdcm2-dev_2.0.10-5_amd64.deb
 rm libgdcm-cil_2.0.10-5_amd64.deb
 rm libgdcm2.0-dbg_2.0.10-5_amd64.deb
 rm libvtkgdcm2-dev_2.0.10-5_amd64.deb
 rm libvtkgdcm2.0_2.0.10-5_amd64.deb

$ gpg  --sign --armor gdcm.commands

It creates a separate .gpg file instead of appending the signature to
the actual *.commands file...

Thanks for help !
-- 
Mathieu


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: dupload fatal error: Can't upload libgdcm-cil_2.0.10-5_amd64.deb

[Joerg Jaspert]

On 11789 March 1977, Mathieu Malaterre wrote:

>   I had a network issue and had to re-run dupload a second time. Now a
> partially *.changes files was updated, and I cannot do anything
> anymore:

Either wait for the files to time out - or read the README in the
directory you try to upload to, look for command files.

-- 
bye, Joerg


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

dupload fatal error: Can't upload libgdcm-cil_2.0.10-5_amd64.deb

[Mathieu Malaterre]

Hello,

  I had a network issue and had to re-run dupload a second time. Now a
partially *.changes files was updated, and I cannot do anything
anymore:


$ dupload --force gdcm_2.0.10-5_amd64.changes
dupload note: no announcement will be sent.
Checking signatures before upload..signatures are ok
Uploading (ftp) to ftp.upload.debian.org:/pub/UploadQueue/
[ job gdcm_2.0.10-5_amd64 from gdcm_2.0.10-5_amd64.changes
 libgdcm-cil_2.0.10-5_amd64.deb, size ok, md5sum ok, sha1sum ok, sha256sum ok
 gdcm_2.0.10-5.tar.gz, size ok, md5sum ok, sha1sum ok, sha256sum ok
 libvtkgdcm2-dev_2.0.10-5_amd64.deb, size ok, md5sum ok, sha1sum ok,
sha256sum ok
 libvtkgdcm2.0_2.0.10-5_amd64.deb, size ok, md5sum ok, sha1sum ok, sha256sum ok
 libgdcm2-dev_2.0.10-5_amd64.deb, size ok, md5sum ok, sha1sum ok, sha256sum ok
 libgdcm2.0-dbg_2.0.10-5_amd64.deb, size ok, md5sum ok, sha1sum ok, sha256sum ok
 libvtkgdcm-tools_2.0.10-5_amd64.deb, size ok, md5sum ok, sha1sum ok,
sha256sum ok
 libgdcm-tools_2.0.10-5_amd64.deb, size ok, md5sum ok, sha1sum ok, sha256sum ok
 libgdcm2.0_2.0.10-5_amd64.deb, size ok, md5sum ok, sha1sum ok, sha256sum ok
 python-gdcm_2.0.10-5_amd64.deb, size ok, md5sum ok, sha1sum ok, sha256sum ok
 python-vtkgdcm_2.0.10-5_amd64.deb, size ok, md5sum ok, sha1sum ok, sha256sum ok
 gdcm_2.0.10-5.dsc, size ok, md5sum ok, sha1sum ok, sha256sum ok
 gdcm_2.0.10-5_amd64.changes ok ]
Uploading (ftp) to anonymous-ftp-master (ftp.upload.debian.org)
[ Uploading job gdcm_2.0.10-5_amd64
 libgdcm-cil_2.0.10-5_amd64.deb 193.1 kBdupload fatal error: Can't
upload libgdcm-cil_2.0.10-5_amd64.deb: Could not create file.
 at /usr/bin/dupload line 558


Thanks for suggestion,
-- 
Mathieu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [Popcon-developers] popcon.d.o? (was: gluck.debian.org (aka oldpeople.d.o) about to be shut down)

[Bill Allombert]

On Mon, Jun 22, 2009 at 07:27:17PM +0200, martin f krafft wrote:
> also sprach Martin Zobel-Helas  [2009.06.20.0127 +0200]:
> > If you care about any data you might have there please get it while you
> > can.
> > 
> > Current plan is to shut down current gluck by end of June (so in about
> > 10 days).
> 
> Where is popcon being run now? DNS says bellini, but gluck still
> seems to accumulate data. Since I am snapshotting popcon data for my
> research, I would appreciate to know when I have to change to
> bellini.

As I wrote in <20090621204523.ga28...@yellowpig>, it is moved to bellini
since yesterday evening.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

popcon.d.o? (was: gluck.debian.org (aka oldpeople.d.o) about to be shut down)

[martin f krafft]

also sprach Martin Zobel-Helas  [2009.06.20.0127 +0200]:
> If you care about any data you might have there please get it while you
> can.
> 
> Current plan is to shut down current gluck by end of June (so in about
> 10 days).

Where is popcon being run now? DNS says bellini, but gluck still
seems to accumulate data. Since I am snapshotting popcon data for my
research, I would appreciate to know when I have to change to
bellini.

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"they redundantly repeated themselves over and over,
 incessantly without end and ad infinitum"
 -- ibid


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: RFS: kernelcheck

[Ben Pfaff]

Jan Hauke Rahm  writes:

> Practically, I do see problems in the US, too: do you think a US court
> would grant you copyright if the only statement in a file were "(C)
> 2009, cate"?

The copyright office has a webpage that explains some of these
issues at http://www.copyright.gov/fls/fl101.html:

A pseudonym or pen name may be used by an author of a
copyrighted work. A work is pseudonymous if the author is
identified on copies or phonorecords of that work by a
fictitious name. Nicknames or other diminutive forms of one’s
legal name are not considered fictitious. As is the case with
other names, the pseudonym itself is not protected by
copyright.

If you are writing under a pseudonym but wish to be
identified by your legal name in the records of the Copyright
Office, you should give your legal name and your pseudonym
when filling out your application. Check the box labeled
“Pseudonymous” if the author is identified on copies of the
work only under a fictitious name and if the work is not made
for hire. Give the pseudonym on the associated line.

If you are writing under a pseudonym but do not wish to have
your identity revealed in the records of the Copyright
Office, you should give your pseudonym and identify it as
such. You may leave blank the space for the name of the
author. If the author’s name is given, it will be made part
of the online public records produced by the Copyright Office
and will be accessible via the Internet. This information
cannot be removed later from those public records. You must,
however, identify the citizenship or domicile of the author.

In no case should you omit the name of the copyright
claimant. You may use a pseudonym in completing the claimant
space, but you should also be aware that if a copyright is
held under a fictitious name, business dealings involving
that property may raise questions of ownership of the
copyright property. You should consult an attorney for legal
advice on these matters.

If the author is identified in the records of the Copyright
Office, the term of the copyright is the author’s life plus
70 years. If the author is not identified in the records of
the Copyright Office, the term of copyright is 95 years from
publication of the work or 120 years from its creation,
whichever term expires first. If the author’s identity is
later revealed in the records of the Copyright Office, the
copyright term then becomes the author’s life plus 70 years.
-- 
"Let others praise ancient times; I am glad I was born in these."
--Ovid (43 BC-18 AD)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFS: kernelcheck

[Jan Hauke Rahm]

On Mon, Jun 22, 2009 at 09:22:17AM -0700, Russ Allbery wrote:
> Jan Hauke Rahm  writes:
> > Practically, I do see problems in the US, too: do you think a US court
> > would grant you copyright if the only statement in a file were "(C)
> > 2009, cate"?
> 
> Explicit copyright notice is not required in any country that's a
> signatory to Berne.  The only difference the copyright notice makes in
> the US is in what statutory damages you can claim.
> 
> So yes, this wouldn't pose any challenge to copyright in the US.  You
> would, of course, have to prove that you're the copyright holder, but
> you'd have to do that no matter what the copyright statement said.

Okay, I stand corrected. A real name in a copyright statement is
required if you actually care about your copyright. By using your real
name as known to the government it's pretty easy to prove being the same
person while a nick name isn't.

Hauke


signature.asc
Description: Digital signature

Re: RFS: kernelcheck

[Russ Allbery]

Jan Hauke Rahm  writes:

> Speaking for germany (as I already did in this thread), you have to
> disclose your identity in court to make use of your civil rights. IOW
> you cannot lay claim to your copyright if you are not identified as
> the copyright holder. A pseudonym is then only helping (AFAIK again)
> if this pseudonym is accepted by government which means official
> registering.
>
> Practically, I do see problems in the US, too: do you think a US court
> would grant you copyright if the only statement in a file were "(C)
> 2009, cate"?

Explicit copyright notice is not required in any country that's a
signatory to Berne.  The only difference the copyright notice makes in
the US is in what statutory damages you can claim.

So yes, this wouldn't pose any challenge to copyright in the US.  You
would, of course, have to prove that you're the copyright holder, but
you'd have to do that no matter what the copyright statement said.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Should umountnfs.sh allow for NFS shares being bind mounted?

[Frans Pop]

On Monday 22 June 2009, Frans Pop wrote:
> On Monday 22 June 2009, Frans Pop wrote:
> > I think it's worth getting some thoughts on this before filing a bug
> > about it (or not).
>
> Just see it's already been discussed to some extend in
> http://bugs.debian.org/254311.

And after looking a bit closer at that BR and reading the mount manpage, I 
solved the issue by adding the '_netdev' option in /etc/fstab.
Learn something every day and sorry for the noise.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFS: kernelcheck

[Jan Hauke Rahm]

On Mon, Jun 22, 2009 at 09:02:59AM -0700, Russ Allbery wrote:
> "Giacomo A. Catenazzi"  writes:
> 
> > but I don't think is is usable in open source.  Editors/publishers are
> > required to know the real name,
> 
> Why are editors/publishers required to know the real name?
> 
> Maybe this is a jurisdiction-dependent issue?  I don't know of any such
> constraint in the US, but I can't speak for other countries.

Speaking for germany (as I already did in this thread), you have to
disclose your identity in court to make use of your civil rights. IOW
you cannot lay claim to your copyright if you are not identified as the
copyright holder. A pseudonym is then only helping (AFAIK again) if this
pseudonym is accepted by government which means official registering.

Practically, I do see problems in the US, too: do you think a US court
would grant you copyright if the only statement in a file were "(C)
2009, cate"?

Hauke


signature.asc
Description: Digital signature

Re: Configurable debian/control & debian/rules

[Samuel Thibault]

Mathieu Malaterre, le Mon 22 Jun 2009 17:36:31 +0200, a écrit :
> On Mon, Jun 22, 2009 at 4:51 PM, Samuel Thibault wrote:
> > Mathieu Malaterre, le Mon 22 Jun 2009 16:13:58 +0200, a écrit :
> >>   My question is simply: how do express that only one Binary package
> >> requires a particular Build-Depends package, but the other remaining
> >> Binary package should be fine ?
> >
> > Mmm, I guess that's more a question for debian-mentors?  dh_shlibdeps
> > will precisely do this automatically for you.
> 
> No, dh_shlibdeps operates on Depends, not on Build-Depends.

Ok, but a Binary package doesn't require a particular build-depends
by itself. The whole build of a source package does. If some arch
doesn't produce a Binary package and for instance that one was the
only one that needs some build-dep to get built (e.g. libasound
for an ALSA plugin), then just add the same arch condition. In the
ALSA plugin case, the build-dep should be libasound [!hurd-i386
!kfreebsd-i386 !kfreebsd-amd64].  There is no need for any other kind of
configurability.

Now, the user may want to rebuild the package for himself with some
features disabled.  To my knowledge that's not something that Debian
handles, however.

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFS: kernelcheck

[Russ Allbery]

"Giacomo A. Catenazzi"  writes:

> but I don't think is is usable in open source.  Editors/publishers are
> required to know the real name,

Why are editors/publishers required to know the real name?

Maybe this is a jurisdiction-dependent issue?  I don't know of any such
constraint in the US, but I can't speak for other countries.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Lintian magic-arch-in-arch-list

[Russ Allbery]

Philipp Kern  writes:
> On 2009-06-22, Russ Allbery  wrote:
>> Philipp Kern  writes:

>>> As explained lintian was wrong after I dropped the bit that
>>> collapsed "amd64 i386 all" to "any" in dpkg-source.  The problem is
>>> that we lost information about what needs to be built where.  "any"
>>> if there is one i386 and one all binary package is just plain wrong,
>>> IMHO.

>> Both Lintian and Policy, in fact.  Policy will be fixed in the next
>> release.

> I was pretty sure to have it looked up before submitting the patch,
> but rereading it carefully I can see "can include the following sets
> of values".  So this means that each set is to be considered
> independent.  Bummer.

Not a problem.  The whole section was rather confusingly worded, so it
was a good opportunity for a rewrite.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Lintian magic-arch-in-arch-list

[Philipp Kern]

On 2009-06-22, Russ Allbery  wrote:
> Philipp Kern  writes:
>> As explained lintian was wrong after I dropped the bit that collapsed
>> "amd64 i386 all" to "any" in dpkg-source.  The problem is that we lost
>> information about what needs to be built where.  "any" if there is one
>> i386 and one all binary package is just plain wrong, IMHO.
> Both Lintian and Policy, in fact.  Policy will be fixed in the next
> release.

I was pretty sure to have it looked up before submitting the patch, but
rereading it carefully I can see "can include the following sets of values".
So this means that each set is to be considered independent.  Bummer.

Sorry,
Philipp Kern


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Configurable debian/control & debian/rules

[Mathieu Malaterre]

On Mon, Jun 22, 2009 at 5:43 PM, Russ Allbery wrote:
> Mathieu Malaterre  writes:
>
>> Let's consider one source package 'foo' which can be build using a
>> --enable-super-duper-3rd-party-lib. My control file is then:
>>
>> 
>> Source: foo
>> Build-Depends: super-duper-3rd-party-lib
>> ...
>>
>> Package: libfoo
>> ...
>>
>> Package: libfoo-super-duper-3rd-party-lib
>> ...
>> 
>>
>> Clearly only 'libfoo-super-duper-3rd-party-lib' 'Build-Depends' on
>> package 'libfoo-super-duper-3rd-party-lib', which make libfoo only
>> available on the limited subset of Arch for
>> libfoo-super-duper-3rd-party-lib...
>>
>> Clearly this is an issue with availability on Arch, but I do not see
>> how to express: "Use libfoo-super-duper-3rd-party-lib only if
>> available" (I would then need to tweak debian/rules but this should be
>> easier).
>
> You want an arch-specific build-dependency, like:
>
>    super-duper-3rd-party-lib [i386 amd64]

Indeed that was simple. And I guess I need to reflect that into the
'Package: libfoo-super-duper-3rd-party-lib'/Architecture: section

Thanks,
-- 
Mathieu


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Should umountnfs.sh allow for NFS shares being bind mounted?

[Frans Pop]

On Monday 22 June 2009, Frans Pop wrote:
> I think it's worth getting some thoughts on this before filing a bug
> about it (or not).

Just see it's already been discussed to some extend in
http://bugs.debian.org/254311.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Configurable debian/control & debian/rules

[Russ Allbery]

Mathieu Malaterre  writes:

> Let's consider one source package 'foo' which can be build using a
> --enable-super-duper-3rd-party-lib. My control file is then:
>
> 
> Source: foo
> Build-Depends: super-duper-3rd-party-lib
> ...
>
> Package: libfoo
> ...
>
> Package: libfoo-super-duper-3rd-party-lib
> ...
> 
>
> Clearly only 'libfoo-super-duper-3rd-party-lib' 'Build-Depends' on
> package 'libfoo-super-duper-3rd-party-lib', which make libfoo only
> available on the limited subset of Arch for
> libfoo-super-duper-3rd-party-lib...
>
> Clearly this is an issue with availability on Arch, but I do not see
> how to express: "Use libfoo-super-duper-3rd-party-lib only if
> available" (I would then need to tweak debian/rules but this should be
> easier).

You want an arch-specific build-dependency, like:

super-duper-3rd-party-lib [i386 amd64]

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Lintian magic-arch-in-arch-list

[Russ Allbery]

Philipp Kern  writes:

> As explained lintian was wrong after I dropped the bit that collapsed
> "amd64 i386 all" to "any" in dpkg-source.  The problem is that we lost
> information about what needs to be built where.  "any" if there is one
> i386 and one all binary package is just plain wrong, IMHO.

Both Lintian and Policy, in fact.  Policy will be fixed in the next
release.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFS: kernelcheck

[Giacomo A. Catenazzi]

Lars Wirzenius wrote:

la, 2009-06-20 kello 08:56 +0200, David Paleino kirjoitti:

Is material copyrightable under a nickname, instead of a realname?


Yes, in all jurisdictions I am aware of. It's called a pseudonym and
tends to be explicitly recognized by copyright laws.


but I don't think is is usable in open source.
Editors/publishers are required to know the real name, which is
impossible on copyleft (per definition anybody could become publisher,
and the program must still be distributable)

ciao
cate



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Configurable debian/control & debian/rules

[Julien Cristau]

On Mon, Jun 22, 2009 at 16:13:58 +0200, Mathieu Malaterre wrote:

>   My question is simply: how do express that only one Binary package
> requires a particular Build-Depends package, but the other remaining
> Binary package should be fine ?
> 
You don't.

Cheers,
Julien


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Configurable debian/control & debian/rules

[Mathieu Malaterre]

On Mon, Jun 22, 2009 at 4:51 PM, Samuel Thibault wrote:
> Mathieu Malaterre, le Mon 22 Jun 2009 16:13:58 +0200, a écrit :
>>   My question is simply: how do express that only one Binary package
>> requires a particular Build-Depends package, but the other remaining
>> Binary package should be fine ?
>
> Mmm, I guess that's more a question for debian-mentors?  dh_shlibdeps
> will precisely do this automatically for you.

No, dh_shlibdeps operates on Depends, not on Build-Depends.


Thanks anyway,
-- 
Mathieu


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#519941: Remove Policy permission for packages to modify ld.so.conf

[Russ Allbery]

Christian Holm Christensen  writes:

> This could be very bad for the root-system package set.   ROOT has
> libraries named like libMatrix, libPostscript, libPhysics, libMath, and
> so on - i.e., very general names.   For that reason I moved all the
> packages into the subdirectory /usr/lib/root to not cause possible
> conflicts.   To make this work seamlessly for both the root-system
> binaries and user code linked against the libraries, I dump a file
> in /etc/ld.so.conf.d/.  
>
> For the root-system binaries, there is of course the option to link with
> RPATH set.   However, I believe that the Policy actually forbids this.  
>
> That leaves maintainers no choice but to put libraries in a directory in
> the general search path - i.e., /usr/lib.

Which is what you already did by adding the directory to ld.so.conf, no?

> Furthermore, it will be up to the maintainers to make sure that he/she
> figures out if other packages use the same library names and make then
> `Conflict' against those packages.  This could turn out to be quite
> some work.

Except that moving them to a different directory doesn't really avoid
this if you have a fully conflicting library with the same version.  If
you installed both root-system and another library with the same name at
the same time now, you'd get one or the other depending on the
ld.so.conf order, leading to unpredictable results, segfaults, and so
forth.  dpkg refusing to install both at the same time is actually
cleaner, I think.

It also shouldn't be that much work to use apt-file to watch for
conflicting packages.  You should be able to set up a script that uses
apt-file and runs once a month or so to look for new conflicts.

> This is, of course, a good point, and the only proper solution to this
> is of course to make sure that every single library out there has a
> globally unique name (or some other kind of Magic identifier).   
>
> However, in the face of `difficult' packages like ROOT or legacy stuff
> it might be good to allow for using specific sub-directories.   Given
> that it is only a few packages that does this, it may not be so bad
> after all.   Also, since ld.so looks for the so-name which _must_
> (according to Policy) contain an interface number it seems unlikely (but
> not impossible) that two libraries with the same basename but in two
> different directories, has the same so-name. 

The same thing applies to libraries installed in the same directory,
such as both installed in /usr/lib, although the dev packages would
have to conflict.  Heimdal and libkrb5-3 both install a /usr/lib/libkrb5
shared library, for instance, but with different SONAMEs, so just the
development packages have to conflict.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#534216: ITP: mbuffer -- tool for buffering data streams

[Peter Pentchev]

Package: wnpp
Severity: wishlist
Owner: Peter Pentchev 

* Package name: mbuffer
  Version : 20090215
  Upstream Author : Thomas Maier-Komor 
* URL : http://www.maier-komor.de/mbuffer.html
* License : GPL-3
  Programming Lang: C
  Description : tool for buffering data streams

The mbuffer tool is used to buffer data streams and show the I/O rate and
summary to the user.  It is especially useful for writing backups to
fast tape drives or streaming them over the network.  If used correctly,
it can prevent buffer underruns and speed up the whole backup or
transfer process.

I'll contact upstream for clarifications about the OpenSSL exception,
since mbuffer links against libcrypto.  Alternatively, I'll see if it
can use gnutls for those routines.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.netr...@space.bgr...@freebsd.org
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
Thit sentence is not self-referential because "thit" is not a word.


pgpwZugB4ERq4.pgp
Description: PGP signature

Should umountnfs.sh allow for NFS shares being bind mounted?

[Frans Pop]

I think it's worth getting some thoughts on this before filing a bug about 
it (or not).

Here's the use case:
$ mount | tail -n2
nfs-server:/project on /srv/project type nfs4 (rw,[...])
/srv/project/kernel on /home/fjp/projects/kernel type none (rw,bind)

So, an NFS share is mounted and a subdir from that is bind mounted 
elsewhere.

During shutdown this results in:
Stopping portmap daemon
not deconfiguring network interfaces: network file systems still mounted. 
(warning).
Cleaning up ifupdown
Deactivating swap...done.
Unmounting local filesystems...  <-- long delay here!!
rpcbind: server localhost not responding, timed out
RPC: failed to contact local rpcbind server (errno 5).
done.
Will now restart.

What seems to happen is that the umountnfs.sh init script *does* unmount
/srv/project, but the actual NFS mount is still preserved because of the 
bind mount.
I discovered this by running umountnfs.sh manually; after that mount no 
longer showed the first line, but in the bind mounted dir all files on 
the NFS server were still fully accessible.

Should we attempt to cover this in the init scripts by also automatically 
unmounting any bind mounts on remote file systems?

Cheers,
FJP


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

Re: Configurable debian/control & debian/rules

[Mathieu Malaterre]

On Mon, Jun 22, 2009 at 5:02 PM, Alexander
Reichle-Schmehl wrote:
> Hi!
>
> Mathieu Malaterre schrieb:
>
>>   My question is simply: how do express that only one Binary package
>> requires a particular Build-Depends package, but the other remaining
>> Binary package should be fine ?
>
> You can't. You specify build-depends for _source_ packages, which in turn
> build the binary packages.  And since you can't specify to build a specific
>  binary package anywayą:  Why would you need to specify that a build
> depends is only needed for a single binary package?

Let's consider one source package 'foo' which can be build using a
--enable-super-duper-3rd-party-lib. My control file is then:


Source: foo
Build-Depends: super-duper-3rd-party-lib
...

Package: libfoo
...

Package: libfoo-super-duper-3rd-party-lib
...


Clearly only 'libfoo-super-duper-3rd-party-lib' 'Build-Depends' on
package 'libfoo-super-duper-3rd-party-lib', which make libfoo only
available on the limited subset of Arch for
libfoo-super-duper-3rd-party-lib...

Clearly this is an issue with availability on Arch, but I do not see
how to express: "Use libfoo-super-duper-3rd-party-lib only if
available" (I would then need to tweak debian/rules but this should be
easier).

Thanks,
-- 
Mathieu


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Configurable debian/control & debian/rules

[Samuel Thibault]

Mathieu Malaterre, le Mon 22 Jun 2009 16:13:58 +0200, a écrit :
>   My question is simply: how do express that only one Binary package
> requires a particular Build-Depends package, but the other remaining
> Binary package should be fine ?

Mmm, I guess that's more a question for debian-mentors?  dh_shlibdeps
will precisely do this automatically for you.

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Configurable debian/control & debian/rules

[Alexander Reichle-Schmehl]

Hi!

Mathieu Malaterre schrieb:

>   My question is simply: how do express that only one Binary package
> requires a particular Build-Depends package, but the other remaining
> Binary package should be fine ?

You can't. You specify build-depends for _source_ packages, which in turn
build the binary packages.  And since you can't specify to build a specific
 binary package anyway¹:  Why would you need to specify that a build
depends is only needed for a single binary package?

Best regards,
  Alexander

1: Well, there is the special case where one source package builds one
arch:all package one architecture specific one.  In that case you can
simply use build-depends and Build-Depends-Indep.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Configurable debian/control & debian/rules

[Mathieu Malaterre]

hi,

  I am reposting a previous post under a different Subject line,
hoping to get more (read: any) feedback.
  I am currently maintaining the gdcm package:

http://packages.qa.debian.org/g/gdcm.html

  Is is written in -somewhat- portable C++ and should build with any
decent C++ compiler. However because a Binary package of gdcm required
vtk (apt-get install libvtk5-dev), I had to list this dependency in
the Source/Build-Depends section.

  My question is simply: how do express that only one Binary package
requires a particular Build-Depends package, but the other remaining
Binary package should be fine ?

  I was thinking that maybe there was a way to configure
debian/control and debian rules files...

Thanks for help,
-- 
Mathieu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#519941: Remove Policy permission for packages to modify ld.so.conf

[Bill Allombert]

On Sun, Jun 21, 2009 at 09:43:16PM +0200, Christian Holm Christensen wrote:
> Hi all,
> 
> On Fri, 2009-06-19 at 21:25 -0700, Russ Allbery wrote:
> > In Policy Bug#519941, it was proposed to remove the Policy permission
> > for packages to modify ld.so.conf in exceptional circumstances.  The
> > implication would be that all packages which do this will need to either
> > move their libraries into a standard library directory like /usr/lib if
> > they're really intended to be public or compile with an RPATH setting.
> > Permission for packages to modify the global library search order to
> > include a non-standard directory would be removed.
> > 
> > The rationale as stated by Steve Langasek:
> > 
> > | This recommendation needs to be elminated entirely.  It is *not* ok
> > | for packages that provide libraries to stick extra linker paths in the
> > | global configuration, whether by modifying ld.so.conf or by adding to
> > | /etc/ld.so.conf.d.  Either the libraries provided by the packages are
> > | meant to be public, in which case they should be installed to the
> > | standard library path instead of needlessly adding another directory
> > | that's going to be globally visible anyway; or they should not, and
> > | the cooperating packages should use rpath instead.
> > | 
> > | Use of rpath should still be discouraged, but if someone is bound and
> > | determined to violate the FHS with their library paths in order to
> > | have private libraries, they should make them really private with
> > | rpath instead of using this "compromise" solution that takes the worst
> > | of each approach.
> 
> This could be very bad for the root-system package set.   ROOT has
> libraries named like libMatrix, libPostscript, libPhysics, libMath, and
> so on - i.e., very general names.   For that reason I moved all the
> packages into the subdirectory /usr/lib/root to not cause possible
> conflicts.   To make this work seamlessly for both the root-system
> binaries and user code linked against the libraries, I dump a file
> in /etc/ld.so.conf.d/.  

I understand this issue, but putting libMatrix in /usr/lib/root avoid file
conflict with other package, do not address the problem of library name
conflict at run-time.

> That leaves maintainers no choice but to put libraries in a directory in
> the general search path - i.e., /usr/lib.   Furthermore, it will be up
> to the maintainers to make sure that he/she figures out if other
> packages use the same library names and make then `Conflict' against
> those packages.  This could turn out to be quite some work. 

I cannot see how your scheme avoid such work: your packages still has to
conflict with any other that contains libMatrix to avoid a library name
conflict. Indeed it make it harder because files conflicts are easier to spot
than library name conflict.

> Now, I agree that the names chosen by upstream ROOT developers are poor.
> It would have been better to call them something like libRootMatrix,
> libRootPostscript, and so on (I can lobby for this, but I fear that it
> will have very little effect).   One could argue, that one should simply
> change the names of the library names in the Debian packages, but
> several issues makes this undesirable: 
> 
>   * ROOT sometimes autoloads libraries in response to user input.
> This mechanism is partially hard-coded into the sources, and
> changing the names in Debian packages only would necessitate a
> lot of patching. 
>   * ROOT also sports a kind of Virtual Machine for clusters and Grid
> computing.   One can simply upload a tar-ball with code and an
> automatically generated Makefile to a cluster, and the code will
> be built and run on target machine(s).   For this to work in a
> heterogeneous environment like Grid were many types of Linux's,
> Unix's, and what not machines is supposed to contribute, the
> names of the libraries must remain the same - since that is
> assumed by the generated Makefile (which may not be built on
> Debian at all). 

I suggest you try the following:

Put libRootMatrix in /usr/lib and a symlink 
/usr/lib/root/libMatrix.so -> /usr/lib/libRootMatrix.so
This way it will be possible to do
gcc -L/usr/lib/root/ -lMatrix
as it is done currently.

> > Note that using a separate directory and modifying ld.so.conf does not
> > usefully resolve name conflicts, since all the libraries end up on the
> > same global search path anyway and one still has to use RPATH to select
> > which of two conflictingly-named libraries one wants to load.
> 
> This is, of course, a good point, and the only proper solution to this
> is of course to make sure that every single library out there has a
> globally unique name (or some other kind of Magic identifier).   

But this makes your attempt at avoiding conflict quite futile.

> However, in the face of `difficult' packages like ROOT or legacy stuff
> it might be good to allow f

Re: What's wrong with meta-gnome2 ?

[Philipp Kern]

On 2009-06-22, Olivier Berger  wrote:
>> Following Joss's mail to -release@, the following answer came:
>> http://lists.debian.org/debian-release/2009/06/msg00216.html
> OK... so, how comes these dependencies aren't reflected in
> http://release.debian.org/migration/testing.pl?package=gnome-desktop-environment;expand=1
>  ?
> Bug ?

Sadly this bit of software is not as accurate as one would like
it to be.  Maybe we should put a prominent notice onto that page.
Patches appreciated.

Kind regards,
Philipp Kern


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Lintian magic-arch-in-arch-list

[Philipp Kern]

On 2009-06-22, Shaun Jackman  wrote:
> I have a source package with two binary packages. One binary package
> is arch i386 amd64, the other is arch all containing the
> architecture-independent data files. The resulting dsc file is
> Architecture: amd64 i386 all
> which lintan complains about:
> E: eagle source: magic-arch-in-arch-list
>
> I'm guessing that the architecture line should omit all:
> Architecture: amd64 i386

As explained lintian was wrong after I dropped the bit that collapsed
"amd64 i386 all" to "any" in dpkg-source.  The problem is that we lost
information about what needs to be built where.  "any" if there is
one i386 and one all binary package is just plain wrong, IMHO.

Kind regards,
Philipp Kern


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#519941: Remove Policy permission for packages to modify ld.so.conf

[Christian Holm Christensen]

Hi all,

On Fri, 2009-06-19 at 21:25 -0700, Russ Allbery wrote:
> In Policy Bug#519941, it was proposed to remove the Policy permission
> for packages to modify ld.so.conf in exceptional circumstances.  The
> implication would be that all packages which do this will need to either
> move their libraries into a standard library directory like /usr/lib if
> they're really intended to be public or compile with an RPATH setting.
> Permission for packages to modify the global library search order to
> include a non-standard directory would be removed.
> 
> The rationale as stated by Steve Langasek:
> 
> | This recommendation needs to be elminated entirely.  It is *not* ok
> | for packages that provide libraries to stick extra linker paths in the
> | global configuration, whether by modifying ld.so.conf or by adding to
> | /etc/ld.so.conf.d.  Either the libraries provided by the packages are
> | meant to be public, in which case they should be installed to the
> | standard library path instead of needlessly adding another directory
> | that's going to be globally visible anyway; or they should not, and
> | the cooperating packages should use rpath instead.
> | 
> | Use of rpath should still be discouraged, but if someone is bound and
> | determined to violate the FHS with their library paths in order to
> | have private libraries, they should make them really private with
> | rpath instead of using this "compromise" solution that takes the worst
> | of each approach.

This could be very bad for the root-system package set.   ROOT has
libraries named like libMatrix, libPostscript, libPhysics, libMath, and
so on - i.e., very general names.   For that reason I moved all the
packages into the subdirectory /usr/lib/root to not cause possible
conflicts.   To make this work seamlessly for both the root-system
binaries and user code linked against the libraries, I dump a file
in /etc/ld.so.conf.d/.  

For the root-system binaries, there is of course the option to link with
RPATH set.   However, I believe that the Policy actually forbids this.  

That leaves maintainers no choice but to put libraries in a directory in
the general search path - i.e., /usr/lib.   Furthermore, it will be up
to the maintainers to make sure that he/she figures out if other
packages use the same library names and make then `Conflict' against
those packages.  This could turn out to be quite some work. 

Now, I agree that the names chosen by upstream ROOT developers are poor.
It would have been better to call them something like libRootMatrix,
libRootPostscript, and so on (I can lobby for this, but I fear that it
will have very little effect).   One could argue, that one should simply
change the names of the library names in the Debian packages, but
several issues makes this undesirable: 

  * ROOT sometimes autoloads libraries in response to user input.
This mechanism is partially hard-coded into the sources, and
changing the names in Debian packages only would necessitate a
lot of patching. 
  * ROOT also sports a kind of Virtual Machine for clusters and Grid
computing.   One can simply upload a tar-ball with code and an
automatically generated Makefile to a cluster, and the code will
be built and run on target machine(s).   For this to work in a
heterogeneous environment like Grid were many types of Linux's,
Unix's, and what not machines is supposed to contribute, the
names of the libraries must remain the same - since that is
assumed by the generated Makefile (which may not be built on
Debian at all). 

> Note that using a separate directory and modifying ld.so.conf does not
> usefully resolve name conflicts, since all the libraries end up on the
> same global search path anyway and one still has to use RPATH to select
> which of two conflictingly-named libraries one wants to load.

This is, of course, a good point, and the only proper solution to this
is of course to make sure that every single library out there has a
globally unique name (or some other kind of Magic identifier).   

However, in the face of `difficult' packages like ROOT or legacy stuff
it might be good to allow for using specific sub-directories.   Given
that it is only a few packages that does this, it may not be so bad
after all.   Also, since ld.so looks for the so-name which _must_
(according to Policy) contain an interface number it seems unlikely (but
not impossible) that two libraries with the same basename but in two
different directories, has the same so-name. 

> This has already recieved the support of six Debian Developers, which is
> more than enough to make this change in Policy.  However, due to the
> broader effects, I wanted to make sure that people were aware of this
> discussion and had a chance to review and weigh in.  

This was my 2 €¢ :-)

> I'm also copying
> the maintainers of all packages that apt-file says include files in
> /etc/ld.so.conf.d except fo

Bug#534163: ITP: gsm0710muxd -- GSM 07.10 Multiplexer

[Johannes Schauer]

Package: wnpp
Severity: wishlist
Owner: Johannes Schauer 


* Package name: gsm0710muxd
  Version : 1.13
  Upstream Author : Michael Dietrich 
* URL : http://pyneo.org
* License : GPL2+
  Programming Lang: C
  Description : GSM 07.10 Multiplexer

pyneo mobile stack: muxer as GSM 07.10 describes.
A muxer for gsm modems to allow more than one channel to be used with
the modem. Each channel can be used to issue phonecalls, watch signal
strength, receiving sms or even doing ppp (gprs) at the same time.
Access to the multiplexer is managed via D-Bus.

-

I already attempted to build a Debian package:
http://rabenfrost.net/pyneo/gsm0710muxd/gsm0710muxd_1.13-1.dsc

This ITP relates to the ITP of pyneod Bug#534160

-- System Information:
Debian Release: 5.0.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#534162: ITP: python-pyneo -- pyneo mobile stack: basis libraries

[Johannes Schauer]

Package: wnpp
Severity: wishlist
Owner: Johannes Schauer 


* Package name: python-pyneo
  Version : 1.13
  Upstream Author : Michael Dietrich 
* URL : http://pyneo.org
* License : GPL3
  Programming Lang: Python
  Description : pyneo mobile stack: basis libraries

Helper modules to support development for and with pyneo in Python. It
contains common functions, modules and constants.

--
I already attempted to build a Debian package:
http://rabenfrost.net/pyneo/python-pyneo/python-pyneo_1.13-1.dsc

This ITP is related to the ITP of pyneod Bug#534160

-- System Information:
Debian Release: 5.0.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Lintian magic-arch-in-arch-list

[Mauro Lizaur]

On Sun, 21 Jun 2009, Shaun Jackman wrote:

> I have a source package with two binary packages. One binary package
> is arch i386 amd64, the other is arch all containing the
> architecture-independent data files. The resulting dsc file is
> Architecture: amd64 i386 all
> which lintan complains about:
> E: eagle source: magic-arch-in-arch-list
> 
> I'm guessing that the architecture line should omit all:
> Architecture: amd64 i386
> 
> What's gone wrong here?
> 
> I'm using
> lintian 2.2.10

This was a lintian issue [0] fixed in the version 2.2.11, so you shouldn't 
pay much attention to *this* particular error.
When using lintian to check your packages use the sid's version, also I
recommend you to use pbuilder [1] next time, this way you can have a clean
environment to test/build your packages.

BTW, this kind of questions usually go in debian-ment...@l.d.o

[0] http://bugs.debian.org/530565
[1] http://packages.debian.org/pbuilder
http://www.netfort.gr.jp/~dancer/software/pbuilder-doc/pbuilder-doc.html

Regards,
Mauro

-- 
JID: lavaram...@jabber.org | http://lusers.com.ar/
2B82 A38D 1BA5 847A A74D 6C34 6AB7 9ED6 C8FD F9C1


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What's wrong with meta-gnome2 ?

[Olivier Berger]

Le lundi 22 juin 2009 à 03:51 +0200, Cyril Brulebois a écrit :
> Aaron M. Ucko  (21/06/2009):
> > [Copying the original poster because I'm not certain he's subscribed;
> > apologies for any resulting duplication.]
> 
> [AFAICT, he is, since he replied in some threads previously. ;)]

Sure am I (on d...@l.d.o).

> > I agree that this message is not as clear as it could be.  In
> > practice, I believe the reason for the delay is that
> > gnome-desktop-environment has recently gained a conflict against
> > gstreamer0.10-gnomevfs, which is however still a dependency of several
> > packages.  Not all of these are necessarily problematic, but one
> > certainly is: gnome-dbg (which also comes from meta-gnome2) depends on
> > gstreamer0.10-plugins-base-dbg (from gst-plugins-base0.10), which
> > historically depended on gstreamer0.10-gnomevfs.  Version 0.10.23-3
> > has downgraded that to a suggestion, but only showed up as a
> > low-priority upload on June 17, so as things stand I wouldn't expect
> > the new meta-gnome2 to hit testing until at least the 27th.
> > 
> > See also http://bugs.debian.org/532469 .
> 
> Following Joss's mail to -release@, the following answer came:
> http://lists.debian.org/debian-release/2009/06/msg00216.html
> 

OK... so, how comes these dependencies aren't reflected in
http://release.debian.org/migration/testing.pl?package=gnome-desktop-environment;expand=1
 ?

Bug ?

Thanks for your replies.

Best regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Lintian magic-arch-in-arch-list

[Cyril Brulebois]

Shaun Jackman  (21/06/2009):
> I have a source package with two binary packages. One binary package
> is arch i386 amd64, the other is arch all containing the
> architecture-independent data files. The resulting dsc file is
> Architecture: amd64 i386 all
> which lintan complains about:
> E: eagle source: magic-arch-in-arch-list

From lintian sources:
| Tag: magic-arch-in-arch-list
| Severity: serious
| Certainty: certain
| Info: The special architecture value "any" only make sense if it occurs
|  alone.  The value "all" may appear together with other architectures
|  in a *.dsc file but must occur alone if used in a binary package.
| Ref: policy 5.6.8

“lintian -i” would have said so.

> Please cc me in your reply.

Done.

Mraw,
KiBi.


signature.asc
Description: Digital signature