Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository

[Patrick Schoenfeld]

Hi Goswin,

On Mon, Jun 23, 2008 at 01:07:38AM +0200, Goswin von Brederlow wrote:
> For example: Each repository puts its keyring into Release.keyring
> (next to Release and Release.gpg). The Release.keyring could be listed
> with checksum in Release so frontends know it is there and when it
> changes.

personally I'm not sure if it is good at all to store the key on the
server whose integrity is to be checked. In my opinion it would be
neccessary to get the key from some trusted instance, because if I'm not
well-integrated into the web of trust myself I cannot rely on the key
beeing checkable by my own trust-net.

> I'm not proposing that just any key should be silently accepted. Just
> that it should be automatically fetched and independent of debs. I
> already did run into a case where I could not update the keyring
> package because the Release signature required the new keyring
> package.

I now understood. Its an interesting idea, I just think that some factors
need to be worked out, because there should be a chance for the *average*
user to understand if a key could possibly be trusted or not. (Not every user
understands those web of trust thing and this is something that can't
really be asked for).

Best Regards,
Patrick


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

Re: RFC: Idea for improved diversions and alternatives handling

[Steve Langasek]

On Mon, Jun 23, 2008 at 12:49:08AM +0200, Goswin von Brederlow wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:

> >> FIXME: what if a line changes? Only allow certain changes?

> > ... that's a rather large FIXME.  Without fixing this, such an
> > implementation of declarative diversions would be pointless churn.

> > You should perhaps discuss this with Ian Jackson, there have already been
> > rumblings from him about implementing declarative diversions.

> The problem is that changes in --rename will be insane.

> For example package A 1.0 has diverted /usr/bin/foo from package B
> with --rename and ships /usr/bin/foo itself.

> Now imagine package A 2.0 drops the --rename option.

> A 1.0 postrm expects /usr/bin/foo to be from A 1.0. On the other hand
> A 2.0 expects /usr/bin/foo to come from B in preinst while the actual
> file is from A 1.0. So you have to move /usr/bin/foo to
> /usr/bin/foo.dpkg-$RANDOM (to be able to abort-install), rename
> /usr/bin/foo.B back to /usr/bin/foo and then run preinst. And in
> case of errors you have to revert it all back.

> Would anyone have a problem if dpkgs diversion handling would always
> use --rename? Because if we eliminate that from being an option the
> changes become easy.

Er, I've for the life of me never understood why --rename is even an
*option* to dpkg-divert.  What does dpkg-divert do without it, and how is
that useful?

I don't think that the meaning of dpkg-divert (without --rename) should be
changed, but I think that for declarative diversions, it makes sense to only
support "rename".

-- 
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: Arch-dependent Depends

[Stefano Zacchiroli]

On Thu, Jun 19, 2008 at 04:28:28PM -0400, Adam C Powell IV wrote:
> I maintain a set of packages which depend openmpi which is missing on
> certain architectures.  To get around the latter problem, I use

I've frequently a similar issues: OCaml programs compiled in bytecode
depends on C stubs to interface with C libraries, while programs
compiled in native code relies on the usual shlibs mechanism. The
dependencies on stubs should be there only on archs where the native
code OCaml compiler is not available.

My usual solution are substvars, which work nicely.

The annoying part of that solution is that I know have 2 different files
in which taking care of dependencies: control and rules (where I pass
the appropriate -V to dpkg-gencontrol).

Since apparently there are quite cases like that, what is the reason for
forbidding arch-specific dependencies in control? Can we reconsider
that? I imagine the rationale was that (arch:any) binary package stanza
are supposed to be for a single arch, but the arch-specificity of deps
can be resolved later on, for example ad build-time, preserving this
assumption.  Practically it won't be much different than substvar, but
the dependency syntax would become more consistent and handy for
maintainers.

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7
[EMAIL PROTECTED],pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
I'm still an SGML person,this newfangled /\ All one has to do is hit the
XML stuff is so ... simplistic  -- Manoj \/ right keys at the right time


signature.asc
Description: Digital signature

Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository

[Robert Millan]

On Mon, Jun 23, 2008 at 11:39:36AM +1000, Brian May wrote:
> Luk Claes wrote:
> >apt-get install debian-backports-keyring
> >
> >or
> >
> >gpg --keyserver hkp://subkeys.pgp.net --recv-keys 16BA136C
> >gpg --export | apt-key add -
> >  
> This involves 3 separate commands, and modifies files under 
> /root/.gnupg/ at the same time. Seems overly complicated, especially for 
> non-technical people. Would it be possible to simplify this?

The problem is not simplifiing the process, but finding one that is not flawed
and actually provides security.

This ITP is not about making it simpler.

-- 
Robert Millan

 I know my rights; I want my phone call!
 What good is a phone call… if you are unable to speak?
(as seen on /.)


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

Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository

[Goswin von Brederlow]

Patrick Schoenfeld <[EMAIL PROTECTED]> writes:

> Hi Goswin,
>
> On Mon, Jun 23, 2008 at 01:07:38AM +0200, Goswin von Brederlow wrote:
>> For example: Each repository puts its keyring into Release.keyring
>> (next to Release and Release.gpg). The Release.keyring could be listed
>> with checksum in Release so frontends know it is there and when it
>> changes.
>
> personally I'm not sure if it is good at all to store the key on the
> server whose integrity is to be checked. In my opinion it would be
> neccessary to get the key from some trusted instance, because if I'm not
> well-integrated into the web of trust myself I cannot rely on the key
> beeing checkable by my own trust-net.

The beauty of signatures is that you do not have to trust the source
of the key, only the signatures. It truely doesn't matter wher you get
the key from.

As for the signature there is no difference between trusting apts key
to safeguard the Release file or a new key. So normal key updates will
not change its trust level with this.

Further, on first install, you probably will have to trust a signature
from the debian keyring for closely debian related repositories. I'm
assuming there will always be some maintainers there to sign the
archive key. But every debian user has the debian keyring from a
trusted source. While you might not be integrated into that web of
trust you already do have to trust it. Those keys do sign every
package upload after all.

Only for 3rd party repositories you would be completly dependent on
the web of trust. But those wouldn't get their keyring into debian
either. So no change in trust there.


Overall having the key on the archive server looses you nothing but
gains you flexibility and transparency. Now if only someone would
write a proof-of-concept implementation...

>> I'm not proposing that just any key should be silently accepted. Just
>> that it should be automatically fetched and independent of debs. I
>> already did run into a case where I could not update the keyring
>> package because the Release signature required the new keyring
>> package.
>
> I now understood. Its an interesting idea, I just think that some factors
> need to be worked out, because there should be a chance for the *average*
> user to understand if a key could possibly be trusted or not. (Not every user
> understands those web of trust thing and this is something that can't
> really be asked for).

I think you are wrong there. I think it is something that must be
asked. You can't have security without understanding. Just think how
many users blindly accept ssl ceritificates and then think https is
save because it is encrypted. It is just a false sense of security.

> Best Regards,
> Patrick

MfG
Goswin


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

Re: Arch-dependent Depends

[Ove Kaaven]

Stefano Zacchiroli skrev:

Since apparently there are quite cases like that, what is the reason for
forbidding arch-specific dependencies in control? Can we reconsider
that?


What is the problem with arch-specific dependencies in control? I've 
used them just fine (in wine, see libwine-dev) for a while, no apparent 
problems. I think they do only work for arch:any packages, though, as 
they seem to be parsed at build-time by dpkg-gencontrol or something.



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

Re: RFC: Idea for improved diversions and alternatives handling

[Goswin von Brederlow]

Steve Langasek <[EMAIL PROTECTED]> writes:

> Er, I've for the life of me never understood why --rename is even an
> *option* to dpkg-divert.  What does dpkg-divert do without it, and how is
> that useful?

Only thing I can think of is something like this:

dpkg-divert --package my-libc6-wrapper --add /lib/libc-2.7.so
cp /lib/libc-2.7.so /lib/libc-2.7.so.my-libc6-wrapper

and

mv /lib/libc-2.7.so.my-libc6-wrapper /lib/libc-2.7.so
dpkg-divert --package my-libc6-wrapper --remove /lib/libc-2.7.so

A case where an intervall without the file is unacceptable.

> I don't think that the meaning of dpkg-divert (without --rename) should be
> changed, but I think that for declarative diversions, it makes sense to only
> support "rename".

MfG
Goswin


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

Re: Arch-dependent Depends

[Goswin von Brederlow]

Stefano Zacchiroli <[EMAIL PROTECTED]> writes:

> On Thu, Jun 19, 2008 at 04:28:28PM -0400, Adam C Powell IV wrote:
>> I maintain a set of packages which depend openmpi which is missing on
>> certain architectures.  To get around the latter problem, I use
>
> I've frequently a similar issues: OCaml programs compiled in bytecode
> depends on C stubs to interface with C libraries, while programs
> compiled in native code relies on the usual shlibs mechanism. The
> dependencies on stubs should be there only on archs where the native
> code OCaml compiler is not available.

Different situation. The ocaml debs have the same depends on every
architecture for the individual deb. They might differ between debs
but not between archs for one arch:all deb.

The problem was an arch dependent depends in the binary deb, not
debian/control. So, while I a nice idea, it is a different problem.

MfG
Goswin


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

Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository

[Patrick Schoenfeld]

Hi,

On Mon, Jun 23, 2008 at 11:20:33AM +0200, Goswin von Brederlow wrote:
> The beauty of signatures is that you do not have to trust the source
> of the key, only the signatures. It truely doesn't matter wher you get
> the key from.

yes, you are right (given that you mean signatures on the key from
"third parties", e.g. someone I trust).

> As for the signature there is no difference between trusting apts key
> to safeguard the Release file or a new key. So normal key updates will
> not change its trust level with this.

Thats true, as long as the key does have signatures from people I trust
or I'm willing to trust without knowing it well.

> Further, on first install, you probably will have to trust a signature
> from the debian keyring for closely debian related repositories. I'm
> assuming there will always be some maintainers there to sign the
> archive key. But every debian user has the debian keyring from a
> trusted source. While you might not be integrated into that web of
> trust you already do have to trust it. Those keys do sign every
> package upload after all.

Exactly. I know that I must trust a key that I cannot verify now. For
example the Debian keyring. Obvious I can only see if it was signed by
some people, but as I probably don't have any of these signatures in my
trusted keyring I cannot me sure that this isn't a compromised
signature. In this case I (as any other user) give a trust bonus. Thats
okay as long as I don't have to give a trust bonus to other external
repositories, like backports.org, without at least a signature from
someone whose signature I partly trust.

But as far as I understand your proposal you do have this, so everything
is right. Good idea, needing a reference implementation.

> Overall having the key on the archive server looses you nothing but
> gains you flexibility and transparency. Now if only someone would
> write a proof-of-concept implementation...

Yep it losses me nothing if it is signed by a third party (that I know
or at least is reasonable trusted). Right. If it isn't then not.

> > I now understood. Its an interesting idea, I just think that some factors
> > need to be worked out, because there should be a chance for the *average*
> > user to understand if a key could possibly be trusted or not. (Not every 
> > user
> > understands those web of trust thing and this is something that can't
> > really be asked for).
> 
> I think you are wrong there. I think it is something that must be
> asked. You can't have security without understanding. Just think how
> many users blindly accept ssl ceritificates and then think https is
> save because it is encrypted. It is just a false sense of security.

Although it might have sounded so, but it isn't what I tried to say.
What I meant is that security has to be as easy as possible for them.
Because you have to consider the reason *why* they click "ok" if they
see SSL warnings. It is because they are overwhelmed with the
decision. Because its to complex for them to understand. You can't ask
them to understand everything you understand. Some people are not able
to understand that, but they have a right on security, as well.

Regards,
Patrick


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

Re: Arch-dependent Depends

[Julian Andres Klode]

Ove Kaaven wrote:
> Stefano Zacchiroli skrev:
>> Since apparently there are quite cases like that, what is the reason for
>> forbidding arch-specific dependencies in control? Can we reconsider
>> that?
> 
> What is the problem with arch-specific dependencies in control? I've
> used them just fine (in wine, see libwine-dev) for a while, no apparent
> problems. I think they do only work for arch:any packages, though, as
> they seem to be parsed at build-time by dpkg-gencontrol or something.
> 
> 
This is Bug#436733 [0].



[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=436733

-- 
Julian Andres Klode, Fellow of the Free Software Foundation Europe
 Debian Maintainer | Developer | Ubuntu Member

try Debian: http://www.debian.org/ | my site: http://jak-linux.org/
jabber: [EMAIL PROTECTED] | IRC: juliank (FreeNode, OFTC)
languages: German  | English



signature.asc
Description: OpenPGP digital signature

Re: Arch-dependent Depends

[Stefano Zacchiroli]

On Mon, Jun 23, 2008 at 11:26:21AM +0200, Ove Kaaven wrote:
> What is the problem with arch-specific dependencies in control? I've  
> used them just fine (in wine, see libwine-dev) for a while, no apparent  
> problems. I think they do only work for arch:any packages, though, as  
> they seem to be parsed at build-time by dpkg-gencontrol or something.

Interesting.

The problem with them is that policy does not allow them :-) Well, to be
precise, policy mentions that build-time relationships in debian/control
can be restricted to a certain set of architectures; it does not state
anything similar for run-time relationships. Hence I, as I guess most of
us, concluded that they are not allowed for run-time relationships.

Here is a quote from Policy 7.1:

  All fields that specify build-time relationships (`Build-Depends',
  `Build-Depends-Indep', `Build-Conflicts' and `Build-Conflicts-Indep')
  may be restricted to a certain set of architectures.  This is
  indicated in brackets after each individual package name and the
  optional version specification.  The brackets enclose a list of ...
  

I've found no similar text for run-time relationships.

Should the policy be updated on this?

-- 
Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7
[EMAIL PROTECTED],pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
I'm still an SGML person,this newfangled /\ All one has to do is hit the
XML stuff is so ... simplistic  -- Manoj \/ right keys at the right time


signature.asc
Description: Digital signature

Re: Arch-dependent Depends

[Stefano Zacchiroli]

On Mon, Jun 23, 2008 at 11:34:35AM +0200, Goswin von Brederlow wrote:
> Different situation. The ocaml debs have the same depends on every
> architecture for the individual deb. They might differ between debs
> but not between archs for one arch:all deb.

Nope. I was talking about OCaml programs shipped as arch:any packages
and built as native code executables on some archs and as bytecode
executables on some other [1]. In such cases you have arch:any packages
which have different dependencies on different architectures.

For one the bytecode architectures will have a dependency on the OCaml
interpreter, dependency which won't be there on native code
architectures.

Cheers.

[1] yes, in such cases there is a small waste of archive space given
that on all bytecode architectures you are using the same,
theoretically arch:all, executable. But in some cases we happen to
choose this bad, over the bad of having to split a separate -byte
package which would pollute Packages files

-- 
Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7
[EMAIL PROTECTED],pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
I'm still an SGML person,this newfangled /\ All one has to do is hit the
XML stuff is so ... simplistic  -- Manoj \/ right keys at the right time


signature.asc
Description: Digital signature

Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository

[Joerg Jaspert]

On 11424 March 1977, Francesco Poli wrote:

> Important disclaimers: IANAL, TINLA, IANADD, TINASOTODP.

Those are *totally* and absolutely unimportant and a waste to write.
Could people please stop always writing them, its fairly clear by itself
that debian-legal does NOT do any lawyers work (and whatever else people
put into that crap). Its also absolutely unimportant if someone is a DD
or not, it doesnt matter at all, as people are writing their own opinion
about $stuff on the list, not that of Debian.

-- 
bye, Joerg
 SCSI benötigt drei Terminierungen, eine am einen Ende, eine
am anderen Ende, und das Leben einer Ziege über einer schwarzen Kerze


pgpyFgLdC1DkB.pgp
Description: PGP signature

Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository

[Robert Millan]

On Sun, Jun 22, 2008 at 01:08:30PM -0500, Adam Majer wrote:
> 
> Certainly, the backports.org keyring is useful to some people, *but* it is,
> 
>   1. not free software

I don't think there's a legal basis to claim copyright on a blob of random
bytes generated by a program.  Who's the copyright holder?  gpg?  The authors
of gpg?  The person who typed gpg in command-line?  The entropy source?

-- 
Robert Millan

 I know my rights; I want my phone call!
 What good is a phone call… if you are unable to speak?
(as seen on /.)


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

Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository

[brian m. carlson]

On Mon, Jun 23, 2008 at 06:05:28PM +0200, Robert Millan wrote:

On Sun, Jun 22, 2008 at 01:08:30PM -0500, Adam Majer wrote:


Certainly, the backports.org keyring is useful to some people, *but* it is,

  1. not free software


I don't think there's a legal basis to claim copyright on a blob of random
bytes generated by a program.  Who's the copyright holder?  gpg?  The authors
of gpg?  The person who typed gpg in command-line?  The entropy source?


Copyright (in the United States) requires an original creation.
Generating several prime numbers for a purely functional purpose is not
at all original and hence not copyrightable.

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

Re: Arch-dependent Depends

[Russ Allbery]

Stefano Zacchiroli <[EMAIL PROTECTED]> writes:

> Interesting.
>
> The problem with them is that policy does not allow them :-) Well, to be
> precise, policy mentions that build-time relationships in debian/control
> can be restricted to a certain set of architectures; it does not state
> anything similar for run-time relationships. Hence I, as I guess most of
> us, concluded that they are not allowed for run-time relationships.
>
> Here is a quote from Policy 7.1:
>
>   All fields that specify build-time relationships (`Build-Depends',
>   `Build-Depends-Indep', `Build-Conflicts' and `Build-Conflicts-Indep')
>   may be restricted to a certain set of architectures.  This is
>   indicated in brackets after each individual package name and the
>   optional version specification.  The brackets enclose a list of ...
>   
>
> I've found no similar text for run-time relationships.
>
> Should the policy be updated on this?

It probably should if all of the software or at least most (plus all of
the package installation software) supports them properly.  Does it?
(dpkg, apt, aptitude, debcheck, dak if applicable, britney)

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository

[Ken Arromdee]

On Sun, 22 Jun 2008, Francesco Poli wrote:
> OK, that said, if you wanted to modify a public key (in order to obtain
> something else), what form would you use for making modifications?
> I think the preferred form would be the one in which the GPG public key
> is distributed by keyservers or some other equivalent form (which may
> be losslessly obtained from the distribution form).

Wouldn't the preferred form for modification be the number that's used to
generate both the private and public key?


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

bashism question

[Michael Meskes]

With our move to dash as sh we have to remove all bashisms from scripts
run by /bin/sh. However, checkbashism seems to moan about clauses that
work in dash as well. I don't know in which shells a trap with a signal number
is guaranteed to work, but it seems to work well in dash. 

I just ran a short test, so if the devil's in the detail I might have
missed something, but nevertheless I wonder if this feature can safely
be used.

Michael
-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!


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

Re: Re: Arch-dependent Depends

[Adam C Powell IV]

Terrific, I will give that a try, thanks very much!

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/


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

Re: Arch-dependent Depends

[Goswin von Brederlow]

Stefano Zacchiroli <[EMAIL PROTECTED]> writes:

> On Mon, Jun 23, 2008 at 11:34:35AM +0200, Goswin von Brederlow wrote:
>> Different situation. The ocaml debs have the same depends on every
>> architecture for the individual deb. They might differ between debs
>> but not between archs for one arch:all deb.
>
> Nope. I was talking about OCaml programs shipped as arch:any packages
> and built as native code executables on some archs and as bytecode
> executables on some other [1]. In such cases you have arch:any packages
> which have different dependencies on different architectures.

Different debs. Each architecture has its own foo_1.2-3_arch.deb with
their own depends. As such the depends can be generated at compile
time.

With an arch: all deb the depends change at install time depending on
the architecture in use.

MfG
Goswin


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

Re: bashism question

[Adam D. Barratt]

Michael Meskes wrote, 2008-06-23, 10:07:27 +0200:

With our move to dash as sh we have to remove all bashisms from
scripts  run by /bin/sh. However, checkbashism seems to moan
about clauses that work in dash as well.
I don't know in which shells a trap with a signal number is
guaranteed to work, but it seems to work well in
dash.


It's not guaranteed to work in any shell implementing POSIX without 
extensions, which is what Policy says you're allowed to rely on (well, plus 
a few extensions, but not including trap and kill with signal numbers).


In general the definition of bashism used by checkbashisms and lintian in 
this case is "not portable to a shell implementing SUSv3 2004 without 
extensions", with the potential exception of those explicitly allowed by 
Policy.



I just ran a short test, so if the devil's in the detail I might have
missed something, but nevertheless I wonder if this feature can safely
be used.


It's safe for use with dash, but using it is technically a violation of 
Policy (albeit a widespread one). There is a Policy bug open requesting that 
the XSI extensions for trap and kill be permitted (#477240).


Regards,

Adam 



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

copyright nonsense (was Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository)

[Joey Hess]

brian m. carlson wrote:
>> I don't think there's a legal basis to claim copyright on a blob of random
>> bytes generated by a program.  Who's the copyright holder?  gpg?  The authors
>> of gpg?  The person who typed gpg in command-line?  The entropy source?
>
> Copyright (in the United States) requires an original creation.
> Generating several prime numbers for a purely functional purpose is not
> at all original and hence not copyrightable.

On the other hand, the numbers we're using for keys are long enough to
encode a nice litte copyrightable short story or song. Major media
organisations have recently been threatening to sue over distribution of
fragements of text much smaller than 128 letters[1]. Making up a large
number of such copyrightable fragments and then tracking down and
threatening to sue[2] people distributing public keys that happen to
encode to the same bit string might be a nice business model for anyone
who is tired of spamming.

-- 
see shy jo

[1] http://www.eff.org/deeplinks/2008/06/biting-hand-feeds-traffic-them
[2] Who knows, some judges might even fall for it.


signature.asc
Description: Digital signature

Re: bashism question

[James Vega]

On Mon, Jun 23, 2008 at 10:07:27AM +0200, Michael Meskes wrote:
> With our move to dash as sh we have to remove all bashisms from scripts
> run by /bin/sh. However, checkbashism seems to moan about clauses that
> work in dash as well. I don't know in which shells a trap with a signal number
> is guaranteed to work, but it seems to work well in dash. 

Policy currently doesn't allow use of XSI extensions which is what
"trap -SIGNAL_NAME" is.  Therefore, checkbashisms is flagging such use
until policy is clarified about this behavior[0].

[0] - http://bugs.debian.org/477240
-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Generating debian package using cmake (take 2)

[Mathieu Malaterre]

Hi there,

  Because of the recent feedback I got in building debian package
using cmake, I decided to rewrite the current -broken- support.

  As far as I understand :
1. dpkg-buildpackage *has* to be the entry point (nothing else, not
even 'cmake')

2. dpkg-buildpackage requires a 'debian' subdirectory to be present in
the source directory directly (it cannot be outside of the project
first level subdirectory).

3. I was suggested libopensync for cmake/debian package start.
3.1 where is the internal name 'libopensync1exp3' coming from ? what
does the '1exp3' stand for ?
3.2 In opensync/debian/control file, where does the 'Build-Depends'
comes from ? Is this computed by some tool or is this purely
human-based ?

4. Let say my package is named 'foo',
4.1 the 'libfoo' package is assumed to provide the runtime libraries
4.2 the 'libfoo-dev' package is assumed to provide the shared lib
symlinks + headers file
4.3 I could not find any naming convention consistant for 'utils' or
'tools', basically applications (main function) based on 'libfoo'.

I am sure there will be tiny differences that will prevent cmake from
generating complete 'control' files (for instance, Conflicts section
cannot be generated by a machine), I am targetting at getting 95% of
the job done and hopefully 100% for simple project. Which will means
that installation will be (automatically) consistant in between a
Linux-debian/MacOSX-darwin/Win32-windows machine.

For references:

* http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack
and
* http://gdcm.svn.sourceforge.net/viewvc/gdcm/branches/gdcm-2-0/debian/

Regards,
-- 
Mathieu


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

Re: Generating debian package using cmake (take 2)

[Michael Banck]

On Mon, Jun 23, 2008 at 07:04:09PM +0200, Mathieu Malaterre wrote:
> 3. I was suggested libopensync for cmake/debian package start.

I suggested it as a package which builds for different python versions.
By that time, I didn't realize you were doing something like
deb-creation support in cmake.

In sofar, I don't think libopensync might be the best example to learn
basic Debian packaging.

> 3.1 where is the internal name 'libopensync1exp3' coming from ? 

It's set in opensync/CMakeLists.txt (in the Debian source package, not
in the upstream code).

> what does the '1exp3' stand for ?

It's the library version.

> 3.2 In opensync/debian/control file, where does the 'Build-Depends'
> comes from ? Is this computed by some tool or is this purely
> human-based ?

This is human based.


Michael


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

Re: Arch-dependent Depends

[Michael Banck]

On Sun, Jun 22, 2008 at 09:33:14PM +0200, Goswin von Brederlow wrote:
> On a hunch I checked the Packages.gz files on my system and found the
> following example:
> 
> Package: libgnomevfs2-dev
> Architecture: amd64
> Source: gnome-vfs
> Version: 1:2.22.0-4
> Depends: libgnomevfs2-0 (= 1:2.22.0-4), libgconf2-dev (>= 2.8.0-1), 
> libgnutls-dev, libxml2-dev, libavahi-client-dev (>= 0.6) | hurd, 
> libavahi-glib-dev (>= 0.6) | hurd, libdbus-1-dev | hurd, libselinux1-dev | 
> not+linux-gnu
> 
> So there actually is a provision for that and here is the magic:
> 
> Package: type-handling
> Architecture: amd64
> Version: 0.2.23
> Provides: amd64, linux, linux-gnu, not+alpha, not+arm, not+armeb, 
> not+bsd-darwin, not+bsd-freebsd, not+bsd-netbsd, not+bsd-openbsd, not+darwin, 
> not+freebsd, not+gnu, not+gnu-hurd, not+gnu-kfreebsd, not+gnu-knetbsd, 
> not+gnu-linux, not+gnueabi-linux, not+gnulp-linux, not+hppa, not+i386, 
> not+i486, not+ia64, not+kfreebsd-gnu, not+knetbsd-gnu, not+linux-gnueabi, 
> not+linux-gnulp, not+m32r, not+m68k, not+mips, not+mipsel, not+netbsd, 
> not+openbsd, not+powerpc, not+powerpc64, not+ppc64, not+s390, not+s390x, 
> not+sh3, not+sh3eb, not+sh4, not+sh4eb, not+solaris, not+sparc, 
> not+sysv-solaris, x86-64-linux-gnu
> 
> So you just add
> 
> Depends: libopenmpi-dev | not+linux, lam4-dev | linux
> 
> or whatever set you need.

Well, that's the good-old type-handling, something we hoped we wouldn't
need in 2008 anymore.  


Michael


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

Re: bashism question

[Michael Meskes]

On Mon, Jun 23, 2008 at 05:39:07PM +0100, Adam D. Barratt wrote:
> It's not guaranteed to work in any shell implementing POSIX without  
> extensions, which is what Policy says you're allowed to rely on (well, 
> plus a few extensions, but not including trap and kill with signal 
> numbers).

Right. But what does this mean in terms of our Lenny release goal "dash as
sh" which essantially was what I meant to ask.

> It's safe for use with dash, but using it is technically a violation of  
> Policy (albeit a widespread one). There is a Policy bug open requesting 
> that the XSI extensions for trap and kill be permitted (#477240).

>From this I'd say for Lenny using trap with a signal number is fine. 

Also they same question comes up with the "local" keyword. Dash seems to
support this, while it is not POSIX.

Michael
-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!


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

Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository

[Francesco Poli]

On Mon, 23 Jun 2008 17:16:28 +0200 Joerg Jaspert wrote:

> On 11424 March 1977, Francesco Poli wrote:
> 
> > Important disclaimers: IANAL, TINLA, IANADD, TINASOTODP.
> 
> Those are *totally* and absolutely unimportant and a waste to write.
> Could people please stop always writing them, its fairly clear by itself
> that debian-legal does NOT do any lawyers work (and whatever else people
> put into that crap). Its also absolutely unimportant if someone is a DD
> or not, it doesnt matter at all, as people are writing their own opinion
> about $stuff on the list, not that of Debian.

I *used* to think that those disclaimers are implicit in most cases.

But then, I was harshly accused of not making it clear enough that
I am neither a lawyer, nor a Debian developer, that I'm not providing
legal advice, and that I don't speak on behalf of the Debian Project.
Other people were similarly attacked for the same reason.

http://lists.debian.org/debian-legal/2006/10/msg00133.html
http://lists.debian.org/debian-legal/2007/06/msg00014.html
http://lists.debian.org/debian-legal/2007/06/msg00038.html
http://lists.debian.org/debian-legal/2007/06/msg00092.html
http://lists.debian.org/debian-legal/2007/06/msg00106.html
http://lists.debian.org/debian-legal/2007/06/msg00222.html
http://lists.debian.org/debian-legal/2007/06/msg00278.html
http://lists.debian.org/debian-legal/2007/07/msg00062.html
http://lists.debian.org/debian-legal/2007/07/msg00215.html

As a consequence I began adding the disclaimers to my messages, in
order to explicitly remind readers about the above facts.

Now, you say that those disclaimers are a waste of time...

I'm really puzzled.


-- 
 http://frx.netsons.org/doc/index.html#nanodocs
 The nano-document series is here!
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgp9sxzgrYHrn.pgp
Description: PGP signature

Re: bashism question

[James Vega]

On Mon, Jun 23, 2008 at 07:28:36PM +0200, Michael Meskes wrote:
> On Mon, Jun 23, 2008 at 05:39:07PM +0100, Adam D. Barratt wrote:
> > It's safe for use with dash, but using it is technically a violation of  
> > Policy (albeit a widespread one). There is a Policy bug open requesting 
> > that the XSI extensions for trap and kill be permitted (#477240).
> 
> >From this I'd say for Lenny using trap with a signal number is fine. 
> 
> Also they same question comes up with the "local" keyword. Dash seems to
> support this, while it is not POSIX.

The "local" keyword is an explicitly supported extension.  These are
discussed in Section 10.4 of policy.

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


signature.asc
Description: Digital signature

Re: Arch-dependent Depends

[Raphael Hertzog]

On Mon, 23 Jun 2008, Russ Allbery wrote:
> > I've found no similar text for run-time relationships.
> >
> > Should the policy be updated on this?
> 
> It probably should if all of the software or at least most (plus all of
> the package installation software) supports them properly.  Does it?

No. The only support that dpkg has is that those arch-limitations are used
by dpkg-gencontrol to keep/drop the dependency while generating the
DEBIAN/control. This means that it can only be used on Arch: any package
and it means that such dependency that appears in a real .deb will not be
parsed correctly by dpkg itself.

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: bashism question

[Adam D. Barratt]

On Mon, 2008-06-23 at 19:28 +0200, Michael Meskes wrote:
> On Mon, Jun 23, 2008 at 05:39:07PM +0100, Adam D. Barratt wrote:
> > It's not guaranteed to work in any shell implementing POSIX without  
> > extensions, which is what Policy says you're allowed to rely on (well, 
> > plus a few extensions, but not including trap and kill with signal 
> > numbers).
> 
> Right. But what does this mean in terms of our Lenny release goal "dash as
> sh" which essantially was what I meant to ask.

I'd assume it doesn't make any difference in terms of that release goal
as (as you noted) dash supports the syntax.

> > It's safe for use with dash, but using it is technically a violation of  
> > Policy (albeit a widespread one). There is a Policy bug open requesting 
> > that the XSI extensions for trap and kill be permitted (#477240).
> 
>From this I'd say for Lenny using trap with a signal number is fine. 

As fine as it was for etch :-)

> Also they same question comes up with the "local" keyword. Dash seems to
> support this, while it is not POSIX.

Policy contains an explicit exemption for "local", although it places
several restrictions on exactly how the keyword may be used. Again, if
dash supports the syntax then the "dash as sh" release goal is
achievable without changing the code; whether that code is Policy
compliant is another matter.

Adam


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

Re: bashism question

[Michael Meskes]

On Mon, Jun 23, 2008 at 01:33:21PM -0400, James Vega wrote:
> > >From this I'd say for Lenny using trap with a signal number is fine. 
> > 
> > Also they same question comes up with the "local" keyword. Dash seems to
> > support this, while it is not POSIX.
> 
> The "local" keyword is an explicitly supported extension.  These are
> discussed in Section 10.4 of policy.

Thanks to James and Adam for the explanations. Maybe I could ping the
devscripts maintainers to add a not-xsi-but-supported-by-policy flag.
:-)

Michael

-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!


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

Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository

[William Pitcock]

Hi,

On Mon, 2008-06-23 at 19:34 +0200, Francesco Poli wrote:
> I *used* to think that those disclaimers are implicit in most cases.
> 
> But then, I was harshly accused of not making it clear enough that
> I am neither a lawyer, nor a Debian developer, that I'm not providing
> legal advice, and that I don't speak on behalf of the Debian Project.
> Other people were similarly attacked for the same reason.
> 
> http://lists.debian.org/debian-legal/2006/10/msg00133.html
> http://lists.debian.org/debian-legal/2007/06/msg00014.html
> http://lists.debian.org/debian-legal/2007/06/msg00038.html
> http://lists.debian.org/debian-legal/2007/06/msg00092.html
> http://lists.debian.org/debian-legal/2007/06/msg00106.html
> http://lists.debian.org/debian-legal/2007/06/msg00222.html
> http://lists.debian.org/debian-legal/2007/06/msg00278.html
> http://lists.debian.org/debian-legal/2007/07/msg00062.html
> http://lists.debian.org/debian-legal/2007/07/msg00215.html
> 
> As a consequence I began adding the disclaimers to my messages, in
> order to explicitly remind readers about the above facts.
> 
> Now, you say that those disclaimers are a waste of time...
> 
> I'm really puzzled.
> 

Have you ever heard the fable concerning a father, a son and a donkey?
In a nutshell, first, nobody rides down the road on the donkey, and
instead lead him with a rope. People criticized them for doing so, e.g.
"why not let the kid ride on top of the donkey?"

So, the father told the kid to ride the donkey. Then people criticized
them again, for not letting the father ride the donkey instead. So, they
switched again. Then people criticized that too, so they wound up
carrying the donkey. Eventually, they reached a stream and fell in the
water because there was too much weight in once place on the bridge they
were crossing.

The moral of the story is that no matter what you do or say, somebody
will complain about it. So, the best path to take is the one which you
think is correct.

Judging by the point that you used to believe that the disclaimers were
implicit, it seems like going back to assuming that might be a good
idea. But, that's just my opinion, obviously.

William


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

Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository

[Ben Hutchings]

On Mon, 2008-06-23 at 09:00 -0700, Ken Arromdee wrote:
> On Sun, 22 Jun 2008, Francesco Poli wrote:
> > OK, that said, if you wanted to modify a public key (in order to obtain
> > something else), what form would you use for making modifications?
> > I think the preferred form would be the one in which the GPG public key
> > is distributed by keyservers or some other equivalent form (which may
> > be losslessly obtained from the distribution form).
> 
> Wouldn't the preferred form for modification be the number that's used to
> generate both the private and public key?

You never want to "modify" those numbers - if there's something wrong
with them you generate new ones at random.

It seems to me that the only things you might want to modify about the
keys are the identities on a public key and the signatures on those, and
the preferred form for doing that would presumably be the one that's
published.

Ben.

-- 
Ben Hutchings
It is impossible to make anything foolproof because fools are so ingenious.


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

Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository

[Francesco Poli]

On Mon, 23 Jun 2008 18:15:16 +0200 Arnoud Engelfriet wrote:

> Ken Arromdee wrote:
> > On Sun, 22 Jun 2008, Francesco Poli wrote:
> > > OK, that said, if you wanted to modify a public key (in order to obtain
> > > something else), what form would you use for making modifications?
> > > I think the preferred form would be the one in which the GPG public key
> > > is distributed by keyservers or some other equivalent form (which may
> > > be losslessly obtained from the distribution form).
> > 
> > Wouldn't the preferred form for modification be the number that's used to
> > generate both the private and public key?

No, that would be the preferred form for compromising the key!  ;-)

Seriously, if I want to alter the public key, I don't think I need the
corresponding secret key.
A public key consists of some numbers, and so does the secret key.
Those two sets of numbers are somewhat correlated, but I don't need one
set in order to alter some numbers in the other set...

> 
> I don't think that "modifying" has any reasonable meaning when talking
> about cryptographic keys.

Why not?

Original public key:

  -BEGIN PGP PUBLIC KEY BLOCK-
  Version: GnuPG v1.4.6 (GNU/Linux)
  
  mQGiBWDHQR[...]9U/rG7P6VAgfYkUYnkueiQ==
  =AGXn
  -END PGP PUBLIC KEY BLOCK-

Modified work:

  -BEGIN PGP PUBLIC KEY BLOCK-
  Version: GnuPG v1.4.6 (GNU/Linux)
  
  XQGiBWDHQm[...]9U/rG7P6VAgfYkUYnkueiQ==
  =AGXn
  -END PGP PUBLIC KEY BLOCK-

Please note that I changed two characters.
Maybe it's no longer a public key, but who cares?
It was a public key, it has been modified...

> A key is a number, or a set of numbers in
> the case of public-key cryptography. How do you modify a number?

By performing operations on it.
5454 may be modified into 5457 by adding 3.
Or into 2727 by dividing by 2.

As an aside, this is just what computers do all the time: they process
numbers in order to compute other numbers, and so on...



P.S.: now what should I do?
"to add disclaimers or not to add disclaimers? this is the question!"
;-)

-- 
 http://frx.netsons.org/doc/index.html#nanodocs
 The nano-document series is here!
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgp6OM0ePMjFx.pgp
Description: PGP signature

Re: subversion 1.5.0 in experimental

[Daniel Widenfalk]

Peter Samuelson wrote:

A few days ago upstream released Subversion 1.5.0, a fairly major
improvement over 1.4.x.  Last night I finally fixed enough build and
testsuite bugs to be able to upload it to experimental.

For those of you who _haven't_ been caught up in the git craze yet, and
are still using this old and boring technology, I would appreciate
aggressive testing.  I know it's almost, if not already, too late for
the lenny library freeze, but I'd _really_ like to try to get 1.5.0
into lenny anyway.  It finally has merge tracking with cherry picking,
WebDAV caching proxy support, sparse checkouts, hashed repository files
(still 1 file per global revision, but now not all in the same dir) and
a lot of small UI improvements.

The main reason it's in experimental and not sid is that I disabled
libsvn-java for now, which is broken because upstream doesn't have much
desire to use anything but Sun Java.  It's not because I think the rest
of the package is necessarily buggy.


An important thing to note:

If you update your svn client to 1.5.x it will automatically
upgrade your working copies (I guess on first use) so that
they become incompatible with earlier clients!

For merge info to be fully supported you'll need to update
your repositories manually using svnadmin or some other
method, e.g. dumping and reloading the repository.

Regards
/Daniel Widenfalk


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

Re: bashism question

[Adam D. Barratt]

On Mon, 2008-06-23 at 19:45 +0200, Michael Meskes wrote:
> On Mon, Jun 23, 2008 at 01:33:21PM -0400, James Vega wrote:
> > > >From this I'd say for Lenny using trap with a signal number is fine. 
> > > 
> > > Also they same question comes up with the "local" keyword. Dash seems to
> > > support this, while it is not POSIX.
> > 
> > The "local" keyword is an explicitly supported extension.  These are
> > discussed in Section 10.4 of policy.
> 
> Thanks to James and Adam for the explanations. Maybe I could ping the
> devscripts maintainers to add a not-xsi-but-supported-by-policy flag.
> :-)

/me coughs in the direction of devscripts' Uploaders field (I'm assuming
you'd noticed, but just in case :-)

Assuming "not-POSIX-but-supported-by-policy" checkbashisms already has a
flag to indicate whether "echo -n" should be flagged for exactly this
reason; otherwise it errs on the side of not flagging constructs that
are policy-compliant.

Supporting "local x" would be relatively simple; suggestions for a
reliable regex to catch use of -a/-o welcome... :)

Adam


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

Re: subversion 1.5.0 in experimental

[Bastian Blank]

On Mon, Jun 23, 2008 at 07:59:01PM +0200, Daniel Widenfalk wrote:
> If you update your svn client to 1.5.x it will automatically
> upgrade your working copies (I guess on first use) so that
> they become incompatible with earlier clients!

This was already the case with 1.4, so what?

> For merge info to be fully supported you'll need to update
> your repositories manually using svnadmin or some other
> method, e.g. dumping and reloading the repository.

This can't be true. I used merge tracking on a format 3 repository
(several years old). Also upstream explicitely say that you are not
required to update the repo for using this feature.

Bastian

-- 
Without followers, evil cannot spread.
-- Spock, "And The Children Shall Lead", stardate 5029.5


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

Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository

[Christian Perrier]

Quoting Joerg Jaspert ([EMAIL PROTECTED]):
> On 11424 March 1977, Francesco Poli wrote:
> 
> > Important disclaimers: IANAL, TINLA, IANADD, TINASOTODP.
> 
> Those are *totally* and absolutely unimportant and a waste to write.


I disagree.

For the very first time after too may years of electronic
communication, I understood that damn "IANAL" acronym, so that thread
had at least one benefit: it improved my overall knowledge..:-)





signature.asc
Description: Digital signature

Re: bashism question

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> work in dash as well. I don't know in which shells a trap with a signal number
> is guaranteed to work, but it seems to work well in dash. 

The signal numbers are different on various architectures. I think in the
GNU world at least mach and FreeBSD kernels have different ones. So it is
less a question of shell syntax but portability.

Gruss
Bernd


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

Re: How to build XEN dom0 and domU kernels based on 2.6.25?

[Daniel Widenfalk]

Ian Campbell wrote:

On Sun, 2008-05-11 at 11:32 +0200, Daniel Widenfalk wrote:

Ian Campbell wrote:

On Thu, 2008-05-08 at 14:16 +0200, Daniel Widenfalk wrote:


Ok, so dropping back a step. Let's assume that I build the 3.2.0 XEN
hypervisor and dom0 kernel using 2.6.18 as base. I should then be able to
build domU kernel(s) using the linux-source-2.6.25 files? How?

I can't seem to get CONFIG_XEN set in my .config file. Running "make
menuconfig" does not show any xen-specific options.

Have you enabled CONFIG_PARAVIRT? You might also need to select a 686
kernel flavour for the option to appear. I've attached my config in case
it is useful, it's PAE+XEN.

Also that that kernel only has i386 support for Xen, no 64 bit yet.

Ian.


Many thanks all,

I've decided to do the following:

Upgrade to Xen 3.2.0 using the 2.6.18 kernel (debian tree) for
my dom0 machines and build 2.6.25 kernels for my domUs. I can't
see any major howlers with this as the domUs won't rely on
anything linux/version specific in the dom0 kernel?


No that should be perfectly fine and is pretty much what I do (I use the
XenSource 2.6.18-xen tree though).


My major problem with 2.6.25 was that I was trying to build a
64-bit kernel which caused the config system to disable Xen.
Quite explainable if xen is not yet available for 64-bit in the
current linux tree...


Yes, there is a tree at
http://git.et.redhat.com/?p=xen-pvops-64.git;a=summary which is the
in-progress tree but it needs pretty specific configuration settings:
http://lists.xensource.com/archives/html/xen-devel/2008-05/msg00117.html

Ian.


Hi all,

I'd just like to come back with some good news! I've (finally)
had some success with a 64-bit 2.6.18 dom0 together with a
32-bit 2.6.25 domU.

I started on an Amd64 machine running (an old) Xen 3.0 with
custom built kernels. Here is how I did it:

0) Save all changes to the network initialization scripts used
   by xen!

1) Shut down all domU machines before updating Xen from 3.0 to
   3.2. The reason for this is that Xen 3.0 is bound to Python
   2.4 whereas Xen 3.2 is bound to Python 2.5.

   If you don't shut down your domU guests before updating Xen,
   then you won't be able to shut them down gracefully afterwards!
   (Learned that the hard way ;-) If you forget, then you have
   to go in and redirect the "python" soft link in /usr/bin to
   point at python2.4 instead, then run "xm shutdown -wa" and then
   point is back at python2.5.

2) Port your changes to the network initialization scripts!

   It seems that the default bridge name is no longer
   "xenbr0", it will be "eth0". I had some trouble with this
   as I'm running a DMZ-bridge for use by the web and email
   servers. Had to update my guest configuration files to
   refer to eth0 instead of xenbr0...

3) Reboot your machine using your old dom0 kernel. This should
   work without a hitch as long as you're got the network
   scripts fixed OK. You may run into problems if your old
   kernel had cpu frequency adaption enabled. This shouldn't
   be the case as Xen 3.0 doesn't support cpu frequence adaption
   but I had applied a patch to allow this which has caused me
   a lot of problems.

4) Download the Xen distribution and also the latest 2.6.18
   kernel from xensource. Configure and build a new dom0
   kernel using the Xen sources.

   IMPORTANT: Don't use gcc-4.3 for this! This is what tripped
   me up. The kernels I built using gcc-4.3 crashed on boot.

   > make linux-2.6-xen-config CONFIGMODE=menuconfig (or xconfig)
   > make linux-2.6-xen-build CC=gcc-4.2
   > sudo cp dist/install/boot/config* /boot
   > sudo cp dist/install/boot/System.map* /boot
   > sudo cp dist/install/vmlinuz* /boot

   Update your grub-menu with an additional entry using your
   newly built kernel.

5) Reboot your machine with your new dom0 kernel. This should,
   hopefully, work like a charm. You're now running Xen 3.2
   together with a dom0 kernel based on Xen 3.2.

6) Download the linux-tree-2.6.25 (and build dependencies, of
   course) package and build/configure your domU kernel:

   > MAKEFLAGS="CC=gcc-4.2" make-kpkg --rootcmd fakeroot \
 --revision 1 --added-patches debian --append-to-version \
 my-32-xenu --cross-compile - --arch i386 \
 --config=menuconfig kernel_image

   IMPORTANT: Note the use of gcc-4.2!

   IMPORTANT: Enable PAE and 64Gbyte memory or it won't work!

   The important point here is to remember:

 "--cross-compile - --arch i386"

   This tells make-kpkg to build a 32-bit image using the native
   amd64 gcc. You'll need to install the "gcc-multilib" package!

7) Install your newly created image

8) Create disk images using, e.g., xen-create-image. Remember to
   specify "--arch i386" or you'll get an Amd64 image and that
   won't boot!

9) Mount your root image and edit the fstab file. The virtual
   block devices are named xvda1, xvda2 etc and not sda1, sda2!

   You probably also want to make all other important changes
   in etc now

Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository

[Walter Landry]

Francesco Poli <[EMAIL PROTECTED]> wrote:
> On Mon, 23 Jun 2008 17:16:28 +0200 Joerg Jaspert wrote:
> 
> > On 11424 March 1977, Francesco Poli wrote:
> > 
> > > Important disclaimers: IANAL, TINLA, IANADD, TINASOTODP.
> > 
> > Those are *totally* and absolutely unimportant and a waste to write.
> > Could people please stop always writing them, its fairly clear by itself
> > that debian-legal does NOT do any lawyers work (and whatever else people
> > put into that crap). Its also absolutely unimportant if someone is a DD
> > or not, it doesnt matter at all, as people are writing their own opinion
> > about $stuff on the list, not that of Debian.
> 
> I *used* to think that those disclaimers are implicit in most cases.
> 
> But then, I was harshly accused of not making it clear enough that
> I am neither a lawyer, nor a Debian developer, that I'm not providing
> legal advice, and that I don't speak on behalf of the Debian Project.
> Other people were similarly attacked for the same reason.
> 
> http://lists.debian.org/debian-legal/2006/10/msg00133.html
> http://lists.debian.org/debian-legal/2007/06/msg00014.html
> http://lists.debian.org/debian-legal/2007/06/msg00038.html
> http://lists.debian.org/debian-legal/2007/06/msg00092.html
> http://lists.debian.org/debian-legal/2007/06/msg00106.html
> http://lists.debian.org/debian-legal/2007/06/msg00222.html
> http://lists.debian.org/debian-legal/2007/06/msg00278.html
> http://lists.debian.org/debian-legal/2007/07/msg00062.html
> http://lists.debian.org/debian-legal/2007/07/msg00215.html

Note that all of these complaints were made by the same person:
Anthony Towns.  Since Anthony used to hold a number of positions of
authority in Debian, including ftpmaster and DPL, I think that
Francesco's response was not irrational.  Since a current ftpmaster
has explicitly said that these notices are no longer necessary,
Francesco can probably relent.

Personally, I received similar criticisms, but I never added
disclaimers.  I just thought Anthony was being a jerk.

Cheers,
Walter Landry
[EMAIL PROTECTED]


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

Re: bashism question

[brian m. carlson]

On Mon, Jun 23, 2008 at 10:07:27AM +0200, Michael Meskes wrote:

With our move to dash as sh we have to remove all bashisms from scripts
run by /bin/sh. However, checkbashism seems to moan about clauses that
work in dash as well. I don't know in which shells a trap with a signal number
is guaranteed to work, but it seems to work well in dash. 


As far as I'm aware, there are three shells in Debian that can be used
as /bin/sh: bash, dash, and posh[0].  bash is, in general, the most
featureful of these.  Just because something works in one does not mean
that it works in all of them.  Notably, posh implements the most minimal
set of features, and last time I checked, my system failed to boot
because scripts were using features not mandated by policy.

So, if you're going to fix bugs due to bashisms, please fix them all.
They are all policy violations, and there's no reason to fix only some
bugs.

As for the signal numbers, different architectures have different signal
numbers.  See signal(7), but the most common ones *are* identical.
However, signals such as SIGUSR1 and SIGUSR2 are not, and using a number
for these will break on at least alpha, mips, mipsel, and sparc[1].  Using
names is not only more portable, it is more explicit.  Everyone knows
what SIGABRT does, but not everyone knows what signal 4 does.  Think of
using signal numbers as using magic numbers: it's a bad programming
practice.

Also, as GNU/kFreeBSD becomes more usable, it will be important to have
shell scripts work across kernels.  The FreeBSD kernel does not match
any Linux architecture in its assignment of signal numbers, so fixing
these now is a good idea.

[0] It would be nice if zsh were added to this list, but I'm not holding
my breath.
[1] Assuming, of course, that most people use i386 or amd64 as their
main platform, and program accordingly.  Judging by the number of FTBFS
bugs on sparc due to alignment problems, this is a safe assumption.

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

Re: subversion 1.5.0 in experimental

[Josselin Mouette]

Le lundi 23 juin 2008 à 20:10 +0200, Bastian Blank a écrit :
> > For merge info to be fully supported you'll need to update
> > your repositories manually using svnadmin or some other
> > method, e.g. dumping and reloading the repository.
> 
> This can't be true. I used merge tracking on a format 3 repository
> (several years old). Also upstream explicitely say that you are not
> required to update the repo for using this feature.

http://subversion.tigris.org/svn_1.5_releasenotes.html
“As described earlier, merge-tracking is not supported unless you
upgrade the repository as well as the server.”

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Generating debian package using cmake (take 2)

[Frank Küster]

"Mathieu Malaterre" <[EMAIL PROTECTED]> wrote:

> 3. I was suggested libopensync for cmake/debian package start.
> 3.1 where is the internal name 'libopensync1exp3' coming from ? what
> does the '1exp3' stand for ?

You shouldn't try to invent a new system for building packages if you
are not familiar enough with Debian Policy to know that yourself.

Sorry, but that's how it is.

Regards, Frank
-- 
Frank Küster
Debian Developer (teTeX/TeXLive)


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

Re: Generating debian package using cmake (take 2)

[Mathieu Malaterre]

On Mon, Jun 23, 2008 at 9:57 PM, Frank Küster <[EMAIL PROTECTED]> wrote:
> "Mathieu Malaterre" <[EMAIL PROTECTED]> wrote:
>
>> 3. I was suggested libopensync for cmake/debian package start.
>> 3.1 where is the internal name 'libopensync1exp3' coming from ? what
>> does the '1exp3' stand for ?
>
> You shouldn't try to invent a new system for building packages if you
> are not familiar enough with Debian Policy to know that yourself.
>
> Sorry, but that's how it is.

Hi Frank,

  That's just rude. Even if you are a super star in the debian-world
and a fantastic hacker, your comment can not possibly be coming from a
grown up adult.
  You did NOT even try to make a tiniest effort to understand what I
am doing here. I am NOT reinventing the wheel here. As I said in the
very first line of my email, I understood my previous mistake in the
early implementation of debian package. That's why I am doing it the
'right' way (as I have been suggested in the previous thread in this
very same mailing list).
  The output of cmake will be a bunch of files: control,
libfoo.install, so that you can run dpkg-buildpackage as any other
debian package.

  Why am I doing that ? Because *this is reinventing the wheel* when
you use cmake and duplicate code in *.install file instead of simply
asking cmake to generate those file for you. If you had read the wiki
page I send, all the information is in the cmakelists, just not
available as regular debian package files.
  The other goal is to also export cmake dependencies (cmake is doing
system inspection), so that one should not have to write the
'Build-Depends' line. cmake knows what is needs to compile, so indeed
this line is purely machine generated.

  As I said, I understand that some info (Conflicts typically) will be
human generated, but I am sure that 95% of writing control/*.install
file can be automatically generated by the build system: cmake in my
case. As far as I understand generating those debian files can be
tedious and error prone, plus it duplicate the logic in cmake anyway.
This should remove most of the boiler plate code, when a project is
using cmake.



-- 
Mathieu


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

Bug#487732: O: ispell -- International Ispell (an interactive spelling corrector)

[Bernd Zeimetz]

Hi,

I'm forwarding this orphaning bug to debian-devel as I hope this rises
the chances to find somebody who is willing to take care of ispell.
According to http://ficus-www.cs.ucla.edu/geoff/ispell.html the version
in Debian is pretty outdated, also there's a number of bugs to triage...

Best regards,

Bernd


 Original Message 
Subject: Bug#487732: O: ispell -- International Ispell (an interactive
spelling corrector)
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED], [EMAIL PROTECTED]
To: Debian Bug Tracking System <[EMAIL PROTECTED]>

Package: wnpp
Severity: normal

The current maintainer of ispell, David Coe <[EMAIL PROTECTED]>,
is apparently not active anymore.  Therefore, I orphan this package
now.  If you want to be the new maintainer, please take it -- see
http://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: ispell
Binary: iamerican, ispell, ibritish
Version: 3.1.20.0-4.4
Priority: standard
Section: text
Maintainer: David Coe <[EMAIL PROTECTED]>
Build-Depends: bison, texinfo, texi2html, debhelper (>= 4), wamerican
(>= 5-2), wbritish (>= 5-2), libncurses5-dev, textutils,
dictionaries-common-dev (>= 0.20)
Architecture: any
Standards-Version: 3.6.1
Format: 1.0
Directory: pool/main/i/ispell
Files: 1f1959139ac18c82eed5472481fcab27 713 ispell_3.1.20.0-4.4.dsc
 8376d8c63c6066fc2e4af6cb49629f60 675385 ispell_3.1.20.0.orig.tar.gz
 ade3758731178717bbe2cfa687712b9c 54441 ispell_3.1.20.0-4.4.diff.gz

Package: iamerican
Priority: standard
Section: text
Installed-Size: 1189
Maintainer: David Coe <[EMAIL PROTECTED]>
Architecture: i386
Source: ispell
Version: 3.1.20.0-4.4
Provides: ispell-dictionary
Depends: ispell, debconf | debconf-2.0, dictionaries-common (>= 0.20),
debconf (>= 0.5) | debconf-2.0
Recommends: wamerican
Conflicts: ispell (<< 3.1.18-2)
Filename: pool/main/i/ispell/iamerican_3.1.20.0-4.4_i386.deb
Size: 425774
MD5sum: d344414aadadca581c0f1503f2214e6e
SHA1: 925e2a8e159d2325054fbb7a0b446a999d567970
SHA256: f809fc3b952cd7f8703d69b988ed8e847ac7112b8e4024d9d6171a4b65d7ca9c
Description: An American English dictionary for ispell
 This is the americanmed+ dictionary, as supplied with
 the source for ispell, with additional words added from
 the more comprehensive wamerican wordlist package.
 .
 This package also recommends wamerican because ispell's
 (L)ookup command needs a wordlist.
Tag: made-of::data:dictionary, role::app-data, use::checking

Package: ibritish
Priority: standard
Section: text
Installed-Size: 1189
Maintainer: David Coe <[EMAIL PROTECTED]>
Architecture: i386
Source: ispell
Version: 3.1.20.0-4.4
Provides: ispell-dictionary
Depends: ispell, debconf | debconf-2.0, dictionaries-common (>= 0.20),
debconf (>= 0.5) | debconf-2.0
Recommends: wbritish
Conflicts: ispell (<< 3.1.18-2)
Filename: pool/main/i/ispell/ibritish_3.1.20.0-4.4_i386.deb
Size: 425386
MD5sum: c3e9f83488e71e18e3aadd2ced66d942
SHA1: 3ec5ffc995a47b32f8b5ae53c637bc417fb5b211
SHA256: c372d6345cd6cdfe264e4088683fcb4bd5085784469480abb5c3210b42f59c60
Description: A British English dictionary for ispell
 This is the britishmed+ dictionary, as supplied with
 the source for ispell, with additional words added from
 the more comprehensive wbritish wordlist package.
 .
 This package also recommends wbritish because ispell's
 (L)ookup command needs a wordlist.
Tag: made-of::data:dictionary, role::app-data, use::checking
Task: british

Package: ispell
Priority: standard
Section: text
Installed-Size: 322
Maintainer: David Coe <[EMAIL PROTECTED]>
Architecture: i386
Version: 3.1.20.0-4.4
Depends: dictionaries-common (>= 0.20), iamerican | ispell-dictionary,
libc6 (>= 2.5-5), libncurses5 (>= 5.4-5)
Recommends: wordlist
Suggests: spell
Filename: pool/main/i/ispell/ispell_3.1.20.0-4.4_i386.deb
Size: 159754
MD5sum: 25406835d42abe85fa00b3324f89d4a8
SHA1: 1ba72a618b6aa2b6b5efc227490ff99b9f1d4d17
SHA256: 815cb1d82c00524daf2d2226041627dbab8c77317deae38933c4fbfad977faf9
Description: International Ispell (an interactive spelling corrector)
 Ispell corrects spelling in plain text, LaTeX, sgml/html/xml,
 and nroff files.  [x]Emacs and jed have nice interfaces to
 ispell, and ispell works from many other tools and from the
 command line as well.
 .
 No ispell dictionaries are included in this package; you must install
 at least one of them ("iamerican" is the default dependency for no
 good reason); install the "ispell-dictionary" package(s) for the
 language(s) you and your users will want to spell-check.
 .
 It's a good idea to install "wordlist" package(s) for the same
 language(s), because they'll be used by ispell's (L)ookup command.
Tag: interface::text-mode, role::program, scope::utility,
uitoolkit::ncurses, works-with::dictionary




-- 
 Bernd Zeimetz   Debian GNU/Linux Developer
 GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a sub

Re: ITP: debian-backports-keyring -- GnuPG archive key of the?backports.org repository

[Jacobo Tarrio]

El domingo, 22 de junio de 2008 a las 12:54:09 -0600, Wesley J. Landaker 
escribía:

> Actually, how are debian-keyring and debian-archive-keyring free-software, 
> anyway? Do I get source code for the all GPG keys they contain? 
> The /usr/share/doc/debian-keyring/copyright even says "The keys in the 
> keyrings don't fall under any copyright." Ops!

 Well, the keys are not creative works, so they cannot be covered under
copyright in most jurisdictions. However, the collection of keys itself can
be covered under copyright, or something similar to it, in many of them, so
having a free licence is still relevant: you can add, remove and update keys
in the collection freely.

 Note how cunningly I avoided talking specifics about one or other
jurisdiction to avoid giving legal advice unadvertantly.

-- 
   Jacobo Tarrío | http://jacobo.tarrio.org/


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

Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository

[Arnoud Engelfriet]

Francesco Poli wrote:
> On Mon, 23 Jun 2008 18:15:16 +0200 Arnoud Engelfriet wrote:
> > I don't think that "modifying" has any reasonable meaning when talking
> > about cryptographic keys.
> 
> Why not?

Because it implies that you'd obtain something meaningful after
the modification. The intent of the right to modify is that you
can do something meaningful with the work. With any bitstream you
can change random characters at will.

I do not see any meaningful modification I can do with someone's
key block.

> 5454 may be modified into 5457 by adding 3.
> Or into 2727 by dividing by 2.

Well, if that's what you want, then the key block is source enough
for the purpose. I just don't understand the point. It gets much
more interesting if you want to modify, say, the name and e-mail 
address in an informational field in the key block. 

> P.S.: now what should I do?
> "to add disclaimers or not to add disclaimers? this is the question!"
> ;-)

Disclaimers usually aren't worth the electroncs they're reproduced with.

Arnoud

-- 
IT lawyer, blogger and patent attorney ~ Partner at ICTRecht.nl legal services
http://www.arnoud.engelfriet.net/ ~ http://www.iusmentis.com/


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

Re: Generating debian package using cmake (take 2)

[Josselin Mouette]

Le lundi 23 juin 2008 à 22:11 +0200, Mathieu Malaterre a écrit :
>   That's just rude. Even if you are a super star in the debian-world
> and a fantastic hacker, your comment can not possibly be coming from a
> grown up adult.

Rude? Come on. You are trying to reinvent the wheel in the worst
possible way, without understanding what a wheel is for and without
obviously reading the documents that explain what are wheels and how to
make them (Debian Policy and New Maintainer’s guide). Starting from
that, Frank could have been much more rude.

>   You did NOT even try to make a tiniest effort to understand what I
> am doing here. I am NOT reinventing the wheel here. As I said in the
> very first line of my email, I understood my previous mistake in the
> early implementation of debian package. That's why I am doing it the
> 'right' way (as I have been suggested in the previous thread in this
> very same mailing list).
>   The output of cmake will be a bunch of files: control,
> libfoo.install, so that you can run dpkg-buildpackage as any other
> debian package.

Stop. Don’t even try to go further. This is NOT the right way. Your
brand new wheels are going to drive you straight into a wall after way
too much effort.

>   Why am I doing that ? Because *this is reinventing the wheel* when
> you use cmake and duplicate code in *.install file instead of simply
> asking cmake to generate those file for you. If you had read the wiki
> page I send, all the information is in the cmakelists, just not
> available as regular debian package files.

The cmakelists will not tell you in which package the files have to go.
And if they all need to go in the same package, you don’t need a
*.install file.

Most of the stuff in debian/ is NOT duplicating anything. It is the
required information to build a package.

>   The other goal is to also export cmake dependencies (cmake is doing
> system inspection), so that one should not have to write the
> 'Build-Depends' line. cmake knows what is needs to compile, so indeed
> this line is purely machine generated.

There is no metadata store to map a build system’s requirements to
build-dependencies (unlike those we have for shared libraries). Some of
us have thrown some ideas to achieve that with pkg-config, but they
would be hacks. Achieving them with packages not using pkg-config (or a
similar system) does not even look possible in the current state of
affairs.

>   As I said, I understand that some info (Conflicts typically) will be
> human generated, but I am sure that 95% of writing control/*.install
> file can be automatically generated by the build system: cmake in my
> case. As far as I understand generating those debian files can be
> tedious and error prone, plus it duplicate the logic in cmake anyway.
> This should remove most of the boiler plate code, when a project is
> using cmake.

Instead of trying to make funny and stupid things that will entertain us
for months, looking at you drowning in your brain-dead system, you
should try to write patches to make cdbs and/or debhelper 7 work
transparently with cmake. This is the right way, and it requires much
less effort than building a car with square wheels.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository

[Francesco Poli]

On Mon, 23 Jun 2008 11:43:25 -0700 (PDT) Walter Landry wrote:

> Francesco Poli <[EMAIL PROTECTED]> wrote:
[...]
> > But then, I was harshly accused of not making it clear enough that
> > I am neither a lawyer, nor a Debian developer, that I'm not providing
> > legal advice, and that I don't speak on behalf of the Debian Project.
> > Other people were similarly attacked for the same reason.
> > 
> > http://lists.debian.org/debian-legal/2006/10/msg00133.html
> > http://lists.debian.org/debian-legal/2007/06/msg00014.html
> > http://lists.debian.org/debian-legal/2007/06/msg00038.html
> > http://lists.debian.org/debian-legal/2007/06/msg00092.html
> > http://lists.debian.org/debian-legal/2007/06/msg00106.html
> > http://lists.debian.org/debian-legal/2007/06/msg00222.html
> > http://lists.debian.org/debian-legal/2007/06/msg00278.html
> > http://lists.debian.org/debian-legal/2007/07/msg00062.html
> > http://lists.debian.org/debian-legal/2007/07/msg00215.html
> 
> Note that all of these complaints were made by the same person:
> Anthony Towns.

There were some other people who seemed to more or less agree with
Anthony Towns.  But he was certainly the loudest one complaining about
this.
That's why the messages I was able to found out in a hurry were his
ones: I didn't manage to dig the few from other people...

> Since Anthony used to hold a number of positions of
> authority in Debian, including ftpmaster and DPL, I think that
> Francesco's response was not irrational.  Since a current ftpmaster
> has explicitly said that these notices are no longer necessary,
> Francesco can probably relent.

I am not sure: adding those acronyms is not a big deal and they use (or
waste!) really few bits.  They seem to succeed in stopping the
complaints, so maybe they are not completely useless.


-- 
 http://frx.netsons.org/doc/index.html#nanodocs
 The nano-document series is here!
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpkGAtRvNQrr.pgp
Description: PGP signature

Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository

[Francesco Poli]

On Mon, 23 Jun 2008 22:31:02 +0200 Arnoud Engelfriet wrote:

> Francesco Poli wrote:
> > On Mon, 23 Jun 2008 18:15:16 +0200 Arnoud Engelfriet wrote:
> > > I don't think that "modifying" has any reasonable meaning when talking
> > > about cryptographic keys.
> > 
> > Why not?
> 
> Because it implies that you'd obtain something meaningful after
> the modification. The intent of the right to modify is that you
> can do something meaningful with the work.

Never underestimate the unexpected results you can obtain by giving
some permission to unknown people!   ;-)

I mean: just because you cannot think of any meaningful modifications,
it does not mean that nobody will ever come up with some.
Maybe someone will turn your public key into some sort of ASCII art!
Or who knows what?

[...]
> I do not see any meaningful modification I can do with someone's
> key block.
> 
> > 5454 may be modified into 5457 by adding 3.
> > Or into 2727 by dividing by 2.
> 
> Well, if that's what you want, then the key block is source enough
> for the purpose.

Exactly.

> I just don't understand the point. It gets much
> more interesting if you want to modify, say, the name and e-mail 
> address in an informational field in the key block.

I suppose you can do that without access to the secret key.
Of course at that point you would break the self-signature: at least I
hope so, otherwise forging a fake public key would be too easy!   ;-)


-- 
 http://frx.netsons.org/doc/index.html#nanodocs
 The nano-document series is here!
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpn1gFxXeqMD.pgp
Description: PGP signature

Re: ITP: debian-backports-keyring -- GnuPG archive key of the?backports.org repository

[Michael Banck]

Hi,

On Sun, Jun 22, 2008 at 12:54:09PM -0600, Wesley J. Landaker wrote:
> Actually, how are debian-keyring and debian-archive-keyring free-software, 
> anyway? 

Next time you have a similar question about these things, please
consider dropping -devel from the list of CCs.


thanks,

Michael


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

Re: Generating debian package using cmake (take 2)

[Mathieu Malaterre]

On Mon, Jun 23, 2008 at 11:06 PM, Josselin Mouette <[EMAIL PROTECTED]> wrote:
> Le lundi 23 juin 2008 à 22:11 +0200, Mathieu Malaterre a écrit :
>>   That's just rude. Even if you are a super star in the debian-world
>> and a fantastic hacker, your comment can not possibly be coming from a
>> grown up adult.
>
> Rude? Come on. You are trying to reinvent the wheel in the worst
> possible way, without understanding what a wheel is for and without
> obviously reading the documents that explain what are wheels and how to
> make them (Debian Policy and New Maintainer's guide). Starting from
> that, Frank could have been much more rude.

Fine.

>>   You did NOT even try to make a tiniest effort to understand what I
>> am doing here. I am NOT reinventing the wheel here. As I said in the
>> very first line of my email, I understood my previous mistake in the
>> early implementation of debian package. That's why I am doing it the
>> 'right' way (as I have been suggested in the previous thread in this
>> very same mailing list).
>>   The output of cmake will be a bunch of files: control,
>> libfoo.install, so that you can run dpkg-buildpackage as any other
>> debian package.
>
> Stop. Don't even try to go further. This is NOT the right way. Your
> brand new wheels are going to drive you straight into a wall after way
> too much effort.

Please give such real world examples of failure (if they are
documented anywhere).

>>   Why am I doing that ? Because *this is reinventing the wheel* when
>> you use cmake and duplicate code in *.install file instead of simply
>> asking cmake to generate those file for you. If you had read the wiki
>> page I send, all the information is in the cmakelists, just not
>> available as regular debian package files.
>
> The cmakelists will not tell you in which package the files have to go.

I am the maintainer of this particular package. I made sure that
'cmake-components' actually match what I call a 'typical' debian
package: runtime libraries, application and dev package. Typically
cmake will also split installation into development type installation
vs runtime installation. So yes, there is a way to specify in cmake
what executable is part of which components (package in debian
vocabulary AFAIK).


> And if they all need to go in the same package, you don't need a
> *.install file.

what do you mean all ?

In cmake you simply say:

  INSTALL(TARGETS tiffdump libtiff
RUNTIME DESTINATION bin COMPONENT Runtime
LIBRARY DESTINATION lib COMPONENT Runtime
)
  INSTALL(FILES tiff.h
DESTINATION include COMPONENT Development
)

Which mean tiffdump and libtiff are part of the 'runtime' package,
while 'tiff.h' is part of the development package.(*)

Thus if you :

cmake -DCOMPONENT=Runtime -P cmake_install.cmake

It will only install the 'Runtime' components.

> Most of the stuff in debian/ is NOT duplicating anything. It is the
> required information to build a package.

That's what I call duplicate information:
http://gdcm.svn.sourceforge.net/viewvc/gdcm/trunk/debian/gdcmutils.install?view=markup

This file could have been generated from the info contained in the
following cmakelists.txt

http://gdcm.svn.sourceforge.net/viewvc/gdcm/trunk/Applications/Cxx/CMakeLists.txt?view=markup

while this file:

http://gdcm.svn.sourceforge.net/viewvc/gdcm/trunk/debian/libgdcm20.install?view=markup

could have been generated from the info contained in the following
files (where * stand for Common, DataDict...):

http://gdcm.svn.sourceforge.net/viewvc/gdcm/trunk/Source/*/CMakeLists.txt?view=markup

So the question is now: are the files debian/libgdcm20.install &
debian/gdcmutils.install the right way of doing it (I was suggested
the opensync package if that matter). Else how do you automatically
generate them, so that they are always in sink with the dev team ?

>>   The other goal is to also export cmake dependencies (cmake is doing
>> system inspection), so that one should not have to write the
>> 'Build-Depends' line. cmake knows what is needs to compile, so indeed
>> this line is purely machine generated.
>
> There is no metadata store to map a build system's requirements to
> build-dependencies (unlike those we have for shared libraries). Some of
> us have thrown some ideas to achieve that with pkg-config, but they
> would be hacks. Achieving them with packages not using pkg-config (or a
> similar system) does not even look possible in the current state of
> affairs.

I do not understand this either. For instance, my cmakelists.txt
contains this particular line:

FIND_PACKAGE(ZLIB REQUIRED)

I thought I could just add an entry for the Build-Depends teling it
that zlib-dev will be required...

I understand that I may miss some (debhelper for instance), but
technically all dependencies should be listed in the cmake project.
Otherwise it's the developper's fault if they are missing a dep (and
not the packager's fault)

Please details your thought for simple cases.

>>  

Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository

[Stephen Gran]

This one time, at band camp, Francesco Poli said:
> 
> There were some other people who seemed to more or less agree with
> Anthony Towns.  But he was certainly the loudest one complaining about
> this.

I think it's quite likely I objected to you appearing to speak
authoritatively on behalf of the project.  However, that has more to do
with you saying things like "you must" or "you cannot" and less to do
with how many acronyms you can invent to stick on the end of your
emails.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: Generating debian package using cmake (take 2)

[Neil Williams]

On Tue, 2008-06-24 at 00:20 +0200, Mathieu Malaterre wrote:
> > Stop. Don't even try to go further. This is NOT the right way. Your
> > brand new wheels are going to drive you straight into a wall after way
> > too much effort.
> 
> Please give such real world examples of failure (if they are
> documented anywhere).

Cross-purposes.

Mathieu - you're coming from the viewpoint of a single package and
trying to make that apply to all packages that would use cmake.

Josselin is working from the viewpoint of all packages in Debian and
trying to make you see that the *right way* is to modify the existing
build tools to work with cmake.

I regularly have cause to review, modify, patch and mangle every build
system used in Debian (just about) and I have had to build a modified
build system around those systems that is able to support cross-building
via each one. The only way to do this is to supply modifications for
debhelper and CDBS, then make individual changes for individual packages
and get those changes filed as bugs in the BTS.

(Yes, I know many here hate CDBS but I say again, CDBS is the easiest
one for me to handle in such a way.)

Over the years, Emdebian and others have tried many other ways of doing
things, including your (doomed) attempt to scale up from a single
package. The right way is to extend debhelper to explicitly understand
cmake and use existing debhelper routines in a cmake-way.

> I am the maintainer of this particular package. 

Then I respectfully submit that this is quite obviously the WRONG
package to select for this purpose.

Forget any specific package - work within debhelper alone and create a
system that works for all cmake projects using debhelper meta-data that
is entirely within the current scope of debhelper itself. By all means
test on a particular package (preferably many packages) but do *NOT*
base the entire thesis on a specific package - that way lies lunacy,
believe me. Been there, done that.

If debhelper understands cmake, CDBS will understand cmake via debhelper
and virtually every other build system in Debian will be able to make
the adjustment.

Do *NOT* stipulate that all cmake projects in Debian are expected to
generate their debian/ files using your scheme - reverse the logic and
make your scheme support all possible permutations of files in debian/
and provide the support required to implement those for cmake.

(If for no other reason than that people like me need to be able to
patch your debian/ files to make the package cross-build and comply with
Emdebian Policy without changes being overwritten by cmake.)

cmake is the object here, not the controller.

debhelper is the controller - cmake is the servant. Help the controller
understand how the servant works and get the servant to do things the
way that the controller stipulates.

> I made sure that
> 'cmake-components' actually match what I call a 'typical' debian
> package: runtime libraries, application and dev package. Typically
> cmake will also split installation into development type installation
> vs runtime installation. So yes, there is a way to specify in cmake
> what executable is part of which components (package in debian
> vocabulary AFAIK).

In which case the chances of the system matching any other package made
by a different upstream team approach zero.

> > There is no metadata store to map a build system's requirements to
> > build-dependencies (unlike those we have for shared libraries). Some of
> > us have thrown some ideas to achieve that with pkg-config, but they
> > would be hacks. Achieving them with packages not using pkg-config (or a
> > similar system) does not even look possible in the current state of
> > affairs.
> 
> I do not understand this either. For instance, my cmakelists.txt
> contains this particular line:
> 
> FIND_PACKAGE(ZLIB REQUIRED)

Insufficient. configure.ac contains lots of lines for finding libraries
and stuff. These lines are an *AID* to collating Build-Depends but not
the complete solution. A 100% calculated build-depends algorithm has not
yet been found.

> I understand that I may miss some (debhelper for instance), but
> technically all dependencies should be listed in the cmake project.

Wrong. You would also need to map Debian package names against upstream
names - many do differ. Other problems lie ahead - honest, this path is
doomed.

> Otherwise it's the developper's fault if they are missing a dep (and
> not the packager's fault)

Tosh.

> Anyway, I have a working cmake-skeleton at least to automatically
> generate the files in gdcm/debian/*, see:
> 
>   http://gdcm.svn.sourceforge.net/viewvc/gdcm/trunk/debian/
> 
> So I'll rephrase all my previous questions, into this single one: are
> those files the right way of doing a debian package ?

A single package, maybe but it is still the wrong approach.

Get debhelper to work with cmake by making an interface between cmake
meta-data and debhelper meta-data. That is the mapping you need.

Give up generatin

Re: Generating debian package using cmake (take 2)

[Sune Vuorela]

On 2008-06-23, Josselin Mouette <[EMAIL PROTECTED]> wrote:
> for months, looking at you drowning in your brain-dead system, you
> should try to write patches to make cdbs and/or debhelper 7 work
> transparently with cmake. This is the right way, and it requires much

cdbs already works pretty well with cmake.

/Sune


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

Re: bashism question

[Russ Allbery]

"Adam D. Barratt" <[EMAIL PROTECTED]> writes:

> Supporting "local x" would be relatively simple; suggestions for a
> reliable regex to catch use of -a/-o welcome... :)

There was a fairly good one in Lintian that I took out once Policy blessed
it, or at least we didn't get a lot of false positive reports.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: bashism question

[Russ Allbery]

"brian m. carlson" <[EMAIL PROTECTED]> writes:

> As for the signal numbers, different architectures have different signal
> numbers.  See signal(7), but the most common ones *are* identical.
> However, signals such as SIGUSR1 and SIGUSR2 are not, and using a number
> for these will break on at least alpha, mips, mipsel, and sparc[1].
> Using names is not only more portable, it is more explicit.  Everyone
> knows what SIGABRT does, but not everyone knows what signal 4 does.
> Think of using signal numbers as using magic numbers: it's a bad
> programming practice.

I'm personally leaning towards modifying Policy to say that XSI extensions
are permitted for kill and trap, which not only allows a very specific set
of numeric signals but also allows kill -1 instead of kill -s 1.

The one remaining problem is that some scripts (libtool, I think) trap
SIGPIPE by number, which is not one of the XSI-allowed numeric signals.
I'm not sure if we should make an additional special exception.

Cc'd to the relevant Policy bug.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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