Re: Package version numbers

2013-01-16 Thread Raphael Hertzog 
On Wed, 16 Jan 2013, Christian PERRIER wrote:
> Quoting Jakub Wilk (jw...@debian.org):
> > I would paint the bikeshed the following color:
> > 0.8.51+dfsg1-0.1
> 
> Isn't that missing the fact that this is a t-p-u upload, which is
> indeed the start of a "wheezy" branch?
> 
> So something we were naming "+wheezy" in the past and which we
> now name "+deb70u1".

It's not really relevant because sid has already diverged and has a higher
(upstream) version.

So 0.8.51+dfsg1-0.1 is acceptable IMO.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130116084941.gd18...@x230-buxy.home.ouaza.com

Re: Bootstrappable Debian - proposal of needed changes

2013-01-16 Thread Ansgar Burchardt 

On 01/16/2013 08:56, Neil Williams wrote:

On Wed, 16 Jan 2013 00:26:53 +0100
Jakub Wilk  wrote:

Not only dpkg, but also wanna-build, sbuild, lintian, dak, and who knows
what else...


It's about which ones need to change. lintian response rates are not
likely to be a problem - once this gets approved. dak doesn't
necessarily need to do anything - most bootstrapping happens outside
the main archive to prepare the ground for a move into debian-ports.
Beyond that point, none of the bootstrapping support is required.


If you want to use new Build-Depends features for packages in the main 
archive, dak needs patches too: "dak rm -R" will warn if Build-Depends 
are broken by a package removal. So it needs to be able to understand 
the field.


python-apt would need to support the field for the same reason. And we 
would need the support in stable (or backports) for dak to use it.



sbuild can use a specified bootstrapping dependency resolver, e.g. the
one used to test the proposal itself. (As could pbuilder.)


And the official buildd network would need to use these before any 
package using build profiles in Build-Depends could be uploaded to the 
main archive.


Ansgar


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50f67199.5080...@debian.org

Re: Continue discussion about uscan enhancement (Was: Uscan enhancements revitalised)

2013-01-16 Thread Andreas Tille 
Hi,

On Fri, Jan 11, 2013 at 08:06:43PM +0100, Jonas Smedegaard wrote:
> > On Fri, Jan 11, 2013 at 08:39:41PM +0900, Charles Plessy wrote:
> > > > Not any more (hopefully) since I droped the `find -name` approach 
> > > > which turned out as insufficient (even if very attractive in the 
> > > > first place).
> 
> > > In that case, the field in mothur's copyright file (and perhaps 
> > > others) is not valid, as it uses [] wildcards, which are not 
> > > recognized in Files fields.
> > 
> > Uhmmm, I was not aware of this.  Hmmm, this needs to be discussed.  
> > Any specific reason not to support [] wildcards?  Without having dived 
> > deeply into this I'd consider this as an unneeded restriction.
> 
> Needed or not, it is how the format looks now.
> 
> Please avoid derailing into _development_ of the format.

OK.  So Fields-Excluded is currently not part of DEP5 anyway and so I
revert my former answer that it fits the Files format because it may
contain [] wildcards (and I do not see any problem because of this).  I
agree with Jonas that discussing the format might be delayed until after
Wheezy release.

Kind regards

  Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130116094504.gj17...@an3as.eu

Re: Continue discussion about uscan enhancement (Was: Uscan enhancements revitalised)

2013-01-16 Thread Charles Plessy 
Le Wed, Jan 16, 2013 at 10:45:04AM +0100, Andreas Tille a écrit :
> 
> OK.  So Fields-Excluded is currently not part of DEP5 anyway and so I
> revert my former answer that it fits the Files format because it may
> contain [] wildcards (and I do not see any problem because of this).  I
> agree with Jonas that discussing the format might be delayed until after
> Wheezy release.

Hi Andreas,

http://bugs.debian.org/685506 is there to receive your proposal when you feel
it is the right time.

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130116095700.gd2...@falafel.plessy.net

Re: Bug#698256: ITP: lz4 -- Extremely Fast Compression algorithm library

2013-01-16 Thread Jakub Wilk 

* Nobuhiro Iwamatsu , 2013-01-16, 09:51:

* URL : http://code.google.com/p/lz4/
* License : BSD 2-Clause License
 Programming Lang: C
 Description : Extremely Fast Compression algorithm library

LZ4 is a very fast lossless compression algorithm.
This uses Dictionary compression, and only supports compression and 
decompression unit blocks.


This looks very promising, but also immature. The upstream makefile 
doesn't build a shared library, not even a static library, but only an 
executable ("lz4demo"). Are there any plans to change that?


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130116100258.ga3...@jwilk.net

Re: Packages with incomplete .md5sum files

2013-01-16 Thread Agustin Martin 
2013/1/15 Andreas Beckmann :
> On 2013-01-15 10:29, Julien Cristau wrote:
>> There's no requirement for md5sums files in the first place AFAIK.  How
>> are incomplete md5sums worse than no md5sums?  If anything this stuff
>> should be minor IMO.
>
> If a package is shipping no .md5sum at all, it will be created by dpkg
> at installation time.
>
> A partial .md5sum however will not be "completed". This hides some
> shipped files from debsums, defeating its purpose.
>
> I'm pretty sure modifying *any* shipped files in the maintainer scripts
> should be forbidden, although I didn't find a policy reference for this
> (this is made explicit for conffiles, what about "normal" files?).
> Packages violating this and hiding the fact by excluding the modified
> files from .md5sums ... should be fixed.

There are some cases where debsums should IMHO consider things
differently. In particular I mean those corresponding to files shipped
under "/var" with "d41d8cd98f00b204e9800998ecf8427e" md5sum (empty
files created with touch). These are clearly placeholders, being dpkg
used to remove/reset them instead of doing things from maintainer
scripts. Whether that makes sense or not depends on the package.

-- 
Agustin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cahmxk7jujr7qhuavqcqdylfsuyzext-vu6dtu1ndlzsq20y...@mail.gmail.com

Re: Continue discussion about uscan enhancement (Was: Uscan enhancements revitalised)

2013-01-16 Thread Jonas Smedegaard 
Quoting Andreas Tille (2013-01-16 10:45:04)
> Hi,
> 
> On Fri, Jan 11, 2013 at 08:06:43PM +0100, Jonas Smedegaard wrote:
> > > On Fri, Jan 11, 2013 at 08:39:41PM +0900, Charles Plessy wrote:
> > > > > Not any more (hopefully) since I droped the `find -name` 
> > > > > approach which turned out as insufficient (even if very 
> > > > > attractive in the first place).
> > 
> > > > In that case, the field in mothur's copyright file (and perhaps 
> > > > others) is not valid, as it uses [] wildcards, which are not 
> > > > recognized in Files fields.
> > > 
> > > Uhmmm, I was not aware of this.  Hmmm, this needs to be discussed.  
> > > Any specific reason not to support [] wildcards?  Without having 
> > > dived deeply into this I'd consider this as an unneeded 
> > > restriction.
> > 
> > Needed or not, it is how the format looks now.
> > 
> > Please avoid derailing into _development_ of the format.
> 
> OK.  So Fields-Excluded is currently not part of DEP5 anyway and so I 
> revert my former answer that it fits the Files format because it may 
> contain [] wildcards (and I do not see any problem because of this).  
> I agree with Jonas that discussing the format might be delayed until 
> after Wheezy release.

Copyright ile format 1.0 permits unofficial fields, so I disagree with 
your reasoning to avoid Files-Excluded:.

Makes sense to me to a) introduce a new field that can later be adopted 
in a later revision of the format, but b) reuse existing defined 
*format* for that new field.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Bootstrappable Debian - proposal of needed changes

2013-01-16 Thread Neil Williams 
On Wed, 16 Jan 2013 10:23:37 +0100
Ansgar Burchardt  wrote:

> On 01/16/2013 08:56, Neil Williams wrote:
> > On Wed, 16 Jan 2013 00:26:53 +0100
> > Jakub Wilk  wrote:
> >> Not only dpkg, but also wanna-build, sbuild, lintian, dak, and who knows
> >> what else...
> >
> > It's about which ones need to change. lintian response rates are not
> > likely to be a problem - once this gets approved. dak doesn't
> > necessarily need to do anything - most bootstrapping happens outside
> > the main archive to prepare the ground for a move into debian-ports.
> > Beyond that point, none of the bootstrapping support is required.
> 
> If you want to use new Build-Depends features for packages in the main 
> archive, dak needs patches too: "dak rm -R" will warn if Build-Depends 
> are broken by a package removal. So it needs to be able to understand 
> the field.

That depends whether bootstrapping  fields need to cover the
*inclusion* of extra Build-Depends only for bootstrapping which would
not normally be installed as a default Debian build. Otherwise, dak can
have a simpler patch to just allow but ignore  content in
Build-Depends.

The main archive only needs to "carry" this extra information without
needing to act upon it. If dak needs patches to allow-and-ignore the
new information, that can be done. Most bootstrapping changes are to
turn off features by not build-depending on packages which can be
turned off in debian/rules.

I'm not sure if we are going to find this situation:

Source: foo
Build-Depends: bar , baz <+embedded>

(especially where bar does not depend on baz and therefore standard
Debian builds would not normally install it. If bar depends on baz
then this isn't a problem and dak can ignore all the <> content
without any effects.)

We may be able to implement dak support to allow-and-ignore and then
deal with the above corner-case later.

Wookey, Johannes: has anything come up so far which would trigger this
corner case?

> python-apt would need to support the field for the same reason. And we 
> would need the support in stable (or backports) for dak to use it.

backports would be manageable.
 
> > sbuild can use a specified bootstrapping dependency resolver, e.g. the
> > one used to test the proposal itself. (As could pbuilder.)
> 
> And the official buildd network would need to use these before any 
> package using build profiles in Build-Depends could be uploaded to the 
> main archive.

Isn't that also a case of allow-but-ignore or
allow-with-hardcoded-default ?

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgp21cUFnY3kQ.pgp
Description: PGP signature

Bug#698293: ITP: nafe -- toolset for editing psf format consolefonts

2013-01-16 Thread Gerfried Fuchs 
Package: wnpp
Severity: wishlist
Owner: Gerfried Fuchs 

* Package name: nafe
  Version : 0.1-1
  Upstream Author : Eric Price 
* URL : http://nafe.sourceforge.net/
* License : GPLv2
  Programming Lang: C
  Description : toolset for editing psf format consolefonts

 The package contains two tools: psf2txt and txt2psf.  With the help of these
 tools it is possible to change consolefonts in psf format.  To not lose the 
 embedded unicode character table you need the psf table tools from the 
 console-tools package, too.

 Enjoy,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130116130631.ga27...@anguilla.debian.or.at

Re: Continue discussion about uscan enhancement (Was: Uscan enhancements revitalised)

2013-01-16 Thread Andreas Tille 
On Wed, Jan 16, 2013 at 12:35:27PM +0100, Jonas Smedegaard wrote:
> > OK.  So Fields-Excluded is currently not part of DEP5 anyway and so I 
> > revert my former answer that it fits the Files format because it may 
> > contain [] wildcards (and I do not see any problem because of this).  
> > I agree with Jonas that discussing the format might be delayed until 
> > after Wheezy release.
> 
> Copyright ile format 1.0 permits unofficial fields, so I disagree with 
> your reasoning to avoid Files-Excluded:.

I do *not* want to avoid 'Files-Excluded'!  I was just asked:

  "By the way, are there differences with the syntax of the Files field ?"[1]

and my answer was[2]

  "Not any more (hopefully) ..."

Now Charles has proven my hopes wrong in[3].
 
> Makes sense to me to a) introduce a new field that can later be adopted 
> in a later revision of the format, but b) reuse existing defined 
> *format* for that new field.

The Files field seems to be a specific form of the "Whitespace-separated
lists"[4] format (at least the restriction about [] is made only in the
Files field definition[5].)  It is certainly my fault that I did not
joined DEP5 discussion to question this definition which puts a
restriction into effect that I do not understand.  But I agree that it
does not make any sense to reopen a DEP5 debatte now.

On the other hand I do not see why I should put any restriction onto a
new field if I can use the defined "Whitespace-separated lists"[4]
format.  And yes, for sure, I perfectly agree that it is a pretty
reasonable goal to use the same format for Files and Files-Excluded and
if you want to be safe you might refrain from adding [] wildcards into
your copyright files.  But for the moment I see no reason to remove this
from files living in VCS (exclusively, not released files) that are
perfectly working with tools adapted to this (also in VCS not released)
just to follow a potential outcome to a non-existing decision.

Kind regards

   Andreas.

[1] https://lists.debian.org/debian-devel/2013/01/msg00189.html
[2] https://lists.debian.org/debian-devel/2013/01/msg00202.html
[3] https://lists.debian.org/debian-devel/2013/01/msg00242.html
[4] 
http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#white-space-lists
[5] 
http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#files-field

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130116131955.ge5...@an3as.eu

Re: Continue discussion about uscan enhancement (Was: Uscan enhancements revitalised)

2013-01-16 Thread Jonas Smedegaard 
Quoting Andreas Tille (2013-01-16 14:19:55)
> On Wed, Jan 16, 2013 at 12:35:27PM +0100, Jonas Smedegaard wrote:
> > > OK.  So Fields-Excluded is currently not part of DEP5 anyway and so I 
> > > revert my former answer that it fits the Files format because it may 
> > > contain [] wildcards (and I do not see any problem because of this).  
> > > I agree with Jonas that discussing the format might be delayed until 
> > > after Wheezy release.
> > 
> > Copyright ile format 1.0 permits unofficial fields, so I disagree with 
> > your reasoning to avoid Files-Excluded:.
> 
> I do *not* want to avoid 'Files-Excluded'!

Ok.  I misunderstood.


> > Makes sense to me to a) introduce a new field that can later be 
> > adopted in a later revision of the format, but b) reuse existing 
> > defined *format* for that new field.
> 
> The Files field seems to be a specific form of the "Whitespace-separated
> lists"[4] format (at least the restriction about [] is made only in the
> Files field definition[5].)  It is certainly my fault that I did not
> joined DEP5 discussion to question this definition which puts a
> restriction into effect that I do not understand.  But I agree that it
> does not make any sense to reopen a DEP5 debatte now.
> 
> On the other hand I do not see why I should put any restriction onto a 
> new field if I can use the defined "Whitespace-separated lists"[4] 
> format.  And yes, for sure, I perfectly agree that it is a pretty 
> reasonable goal to use the same format for Files and Files-Excluded 
> and if you want to be safe you might refrain from adding [] wildcards 
> into your copyright files.  But for the moment I see no reason to 
> remove this from files living in VCS (exclusively, not released files) 
> that are perfectly working with tools adapted to this (also in VCS not 
> released) just to follow a potential outcome to a non-existing 
> decision.

Sorry if I am dense...

You agree that Files and Files-Excluded should ideally use same format, 
but you find it more important that Files-Excluded be flexible - even 
if Files as currently defined is not.

Did I get that correct?

In case it was unclear: I find it more important for Files and 
Files-Excluded to use _same_ format than for Files-Excluded to use an 
ideal format _now_.

I find it better to discuss (later!) relaxing that Files format, which 
would then affect both Files and Files-Excluded, than to now try 
second-guess what Files format might be relaxed to allow in the future.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Bootstrappable Debian - proposal of needed changes

2013-01-16 Thread Ian Jackson 
Johannes Schauer writes ("Bootstrappable Debian - proposal of needed changes"):
> the following is an email written by Wookey and myself.

Firstly, I want to say thank you!  This seems like excellent work to
me.

> 5. Cross-Builds field
> =
> 
> For even further automation and also for quality assurance, we propose
> another new field for source packages which indicates whether or not
> this source package is supposed to be cross compilable.

Is it possible that packages might only cross build for certain
targets ?  Or only for certain hosts ?

> 6. Conclusion
> =
...
> The question remains of how many source packages would have to have the
> proposed new fields added to them to make a full bootstrap from zero
> possible. If the Gentoo USE flags were not too far off and assuming or
> tools do the correct thing so far, then:
> 
>  - the number of source packages that has to be modified with the new
>fields is at maximum 83 (there might be a smaller set).

That sounds very manageable.

> The main questions to this list are:
> 
>  - should Debian be bootstrappable in a fully automated fashion? We
>created the algorithms that can allow this to happen, we just need
>more meta data and a way to encode it

Yes, please.

>  - do the proposals for the needed fields sound convincing? Can they be
>improved? Do they have fundamental flaws?

I haven't spotted anything hideously wrong.  I have three suggestions
for changes:

 * Packages should explicitly declare which profiles they support.
   This should be done with a Profile field in the source stanza
   of debian/control.

 * It should be made explicit in the spec that building occurs with
   zero or one profile, not several.

 * The concrete syntax in build-depends should not use < > but rather
   reuse the architecture qualification syntax.

In more detail:

I worry about this:
  Build-Depends: huge (>= 1.0) [i386 arm] , tiny

This takes the < > metacharacters and reserves them for build
profiles.  Metacharacters are very scarce and should only be used when
necessary.

And indeed the profiles work very much like architectures, just in a
different namespace and with different rules for defining whether a
profile applies to a particular build.

So I think it would be better to make using of this commonality, save
a metacharacter, and have a more regular syntax.  For example:

(a)
  Build-Depends: huge (>= 1.0) [i386 arm] [!profile:embedded !profile:stage1]

Another possibility is this:
(b)
  Build-Depends: huge (>= 1.0) [i386 arm] [profile: !embedded !stage1]

Or this:
(c)
  Build-Depends: huge (>= 1.0) [i386 arm] [!embedded !stage1]
(Since unknown arches and unknown profiles can be safely ignored as
"no match", the parser doesn't need to know which of the keywords are
profiles and which are architectures.)

All of these are a bit longer because they use an identifier rather
than a metacharacter to indicate that the qualifier is talking about
profiles.  I think this is the right tradeoff.  The arrangement could
be extended later by adding new keywords alongside "profile:", if we
wanted different qualifiers (whose application to a particular build
is specified in a different way to arches and profiles).

Of these I prefer (a) or (b).  (c) doesn't have a satisfactory answer
to the namespace registry.  (b) has a more irregular syntax but its
fields are slightly more readable and shorter than (a).

The semantics I would propose for my unified qualifier syntax are as
follows:

  * Multiple qualifiers (each with the syntax [...]) may occur in one
build-dependency.  The dependency applies iff _all_ the
qualifiers match.

  * A qualifier must contain either only positive labels
(in which case it matches iff any label is true), or
only negated ones (ie prefixed with !) (in which case it
matches iff no label is true).

  * A label not known to the software processing the field
is taken not to match.

  * (a) Labels are ":", or "".
Labels in a single qualifier must be in the same scope
(but this need not be enforced by parsers).
There is a registry of scopes, which defines the
registry of labels within each scope.
or
(b) Qualifiers start with ":" iff the scope isn't
architecture.  Label names are meaningful within scopes.
There is a registry of scopes, which defines the
registry of labels within each scope.
or
(c) Labels may be names of build profiles, architectures,
or anything else.
option (i) There is a registry of labels.
option (ii) There is no registry of labels and the
label namespace is a free-for-all.

 * We initially define one scope "profile", for build profiles.

   A build profile is an optional variation that can be applied
   to a particular package, for the purpose of reducing the
   build dependencies and/or avoiding the building of unneeded
   binary packages.

   The builder of a p

Re: Bootstrappable Debian - proposal of needed changes

2013-01-16 Thread Matthias Klose 
Am 16.01.2013 13:05, schrieb Neil Williams:
> The main archive only needs to "carry" this extra information without 
> needing to act upon it. If dak needs patches to allow-and-ignore the new
> information, that can be done. Most bootstrapping changes are to turn off
> features by not build-depending on packages which can be turned off in
> debian/rules.
> 
> I'm not sure if we are going to find this situation:
> 
> Source: foo Build-Depends: bar , baz <+embedded>
> 
> (especially where bar does not depend on baz and therefore standard Debian
> builds would not normally install it. If bar depends on baz then this isn't
> a problem and dak can ignore all the <> content without any effects.)
> 
> We may be able to implement dak support to allow-and-ignore and then deal
> with the above corner-case later.
> 
> Wookey, Johannes: has anything come up so far which would trigger this 
> corner case?

cross building the gcc-4.x packages requires additional build dependencies on
{gobjc++,gccgo,gfortran}- packages.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50f6b2e2.9000...@debian.org

Re: Continue discussion about uscan enhancement (Was: Uscan enhancements revitalised)

2013-01-16 Thread Andreas Tille 
On Wed, Jan 16, 2013 at 02:43:54PM +0100, Jonas Smedegaard wrote:
> 
> Sorry if I am dense...

I like you because I know you are dense. ;-)
 
> You agree that Files and Files-Excluded should ideally use same format, 
> but you find it more important that Files-Excluded be flexible - even 
> if Files as currently defined is not.
> 
> Did I get that correct?
> 
> In case it was unclear: I find it more important for Files and 
> Files-Excluded to use _same_ format than for Files-Excluded to use an 
> ideal format _now_.
> 
> I find it better to discuss (later!) relaxing that Files format, which 
> would then affect both Files and Files-Excluded, than to now try 
> second-guess what Files format might be relaxed to allow in the future.

Let me put it like this:  My *current* implementation of uscan is
accepting [] wildcards.  I would need to squeeze my mind to reduce the
functionality of find to implement the Files format definition.  If
somebody volunteers to send me a patch I would consider applying it.
For the moment I see no need for action before a discussion has started.

I have documented the difference between the `Files` and `Files-Excluded`
formats in the Wiki[2] to make sure we will not forget.  Feel free to add
a hint to advise users to refrain from using [] wildcards.

Kind regards

   Andreas.

[1] 
http://anonscm.debian.org/gitweb/?p=users/tille/devscripts.git;a=blob;f=scripts/uscan.pl
[2] https://wiki.debian.org/UscanEnhancements


-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130116141122.gh5...@an3as.eu

Re: Bootstrappable Debian - proposal of needed changes

2013-01-16 Thread Matthias Klose 
Am 15.01.2013 19:18, schrieb Johannes Schauer:
> This mechanism also covers cross-compiler bootstraping. The eglibc, gcc,
> and kernel packages already have the neceassary staged-build info, but
> the build profiles (1.) part is also needed to specifiy the reduced
> build-deps. The cross-toolchain bootstrap ceases to be a special case if
> treated this way and just becomes packages to be built in stages using
> the profiles mechansim, like many others in the base system (but for
> build arch taregtting host, arch, rather than built for host-arch). See
> the wiki article at [11].
> 
> [11] http://wiki.debian.org/MultiarchCrossToolchains

Please stop calling this "MultiarchCrossToolchains". It was already wrong when
used in the Emdebian context, and on some GSOC pages. What you are apparently
aiming for is a cross compiler re-using the target libraries built (natively).
However this is not yet done, requires dependencies on "foreign" architectures
and only is a very special case, not helping for targets where these are not yet
available (like for the arm64 bootstrap). Having a cross-toolchain just built on
the host architecture (targeting the target architecture), should still be an
option.

Binutils, GCC, clang, and probably more packages in Debian are currently aware
about the multiarch locations, including native and cross compilers. So please
don't hijack this term for your very specific view on a cross compiler.

The so called "cross-toolchain bootstrap" is overly complex and probably should
not be handled by staged builds, but by building from a combined source tree.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50f6bb1f.7060...@debian.org

Re: Bootstrappable Debian - proposal of needed changes

2013-01-16 Thread Matthias Klose 
Am 16.01.2013 14:50, schrieb Ian Jackson:
>  * We initially define one scope "profile", for build profiles.
> 
>A build profile is an optional variation that can be applied
>to a particular package, for the purpose of reducing the
>build dependencies and/or avoiding the building of unneeded
>binary packages.
> 
>The builder of a package may apply one single build profile.
> 
>Build profile names are a controlled namespace and are allocated by
>the Debian project.  The following are defined:
> 
>   profile:stage1
>   profile:stage2
> For multi-stage bootstrap.  A package may only
> declare support for stage2 if it supports stage1 as well.
> These are not a global ordering across the distribution.
> Rather, stage1 is the most limited build of this
> particular package.  stage2 is an intermediate bootstrap
> build, support for which is provided only if it is
> necessary to build this particular package three times.

this only takes care about packages with a reduced package set built, or
packages with reduced functionality. There are same cases missing:

 - extra build dependencies for cross builds, like for gcc-4.7:
   {gobjc++,gccgo,gfortran}-
   profile:cross?

 - build dependencies for running the check target. Usually these
   dependencies can be ignored when cross-building packages, or when
   building a package natively with DEB_BUILD_OPTIONS=nocheck.
   profile:check? There are not few packages which can be easier
   cross-built when identifying and dropping these build dependencies.

So it does make sense to build with two profiles like stage1 & check.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50f6c07f.5050...@debian.org

Re: Bootstrappable Debian - proposal of needed changes

2013-01-16 Thread Neil Williams 
On Wed, 16 Jan 2013 13:50:17 +
Ian Jackson  wrote:

> > For even further automation and also for quality assurance, we propose
> > another new field for source packages which indicates whether or not
> > this source package is supposed to be cross compilable.
> 
> Is it possible that packages might only cross build for certain
> targets ?  Or only for certain hosts ?

For certain host architectures: yes, definitely. Any source package
which includes assembly (there are more than most people expect) and any
package which then has a build dependency on a binary package
built from the source package(s) containing assembly and so on.
(This is a separate discussion, please don't hijack this
thread for the pros and cons of assembly in packages.)

Also, cross-building of kernels other than Linux and the packages
which build-depend on the headers for such kernels is often not
supported by cross-building toolchains.

These failures are recursive and it can be very hard to identify why
package A wouldn't cross-build until the bootstrapping process shows
that it absolutely requires a package N levels down the dependency
chain which fails to cross build.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpPaMTOwMXem.pgp
Description: PGP signature

Re: Continue discussion about uscan enhancement (Was: Uscan enhancements revitalised)

2013-01-16 Thread Jonas Smedegaard 
Quoting Andreas Tille (2013-01-16 15:11:22)
> On Wed, Jan 16, 2013 at 02:43:54PM +0100, Jonas Smedegaard wrote:
> > 
> > Sorry if I am dense...
> 
> I like you because I know you are dense. ;-)
>  
> > You agree that Files and Files-Excluded should ideally use same 
> > format, but you find it more important that Files-Excluded be 
> > flexible - even if Files as currently defined is not.
> > 
> > Did I get that correct?
> > 
> > In case it was unclear: I find it more important for Files and 
> > Files-Excluded to use _same_ format than for Files-Excluded to use 
> > an ideal format _now_.
> > 
> > I find it better to discuss (later!) relaxing that Files format, 
> > which would then affect both Files and Files-Excluded, than to now 
> > try second-guess what Files format might be relaxed to allow in the 
> > future.
> 
> Let me put it like this: My *current* implementation of uscan is 
> accepting [] wildcards.  I would need to squeeze my mind to reduce the 
> functionality of find to implement the Files format definition.  If 
> somebody volunteers to send me a patch I would consider applying it. 
> For the moment I see no need for action before a discussion has 
> started.
> 
> I have documented the difference between the `Files` and 
> `Files-Excluded` formats in the Wiki[2] to make sure we will not 
> forget.  Feel free to add a hint to advise users to refrain from using 
> [] wildcards.

Fine with me that uscan can do more than needed.

Fine with me if uscan Files-Excluded feature is promoted (e.g. in its 
manpage) to support same format as Files field.

Problematic in my opinion if uscan *documented* format is a custom 
format. 

Fine with me if uscan *documented* format is the current Files field 
format, leaving that additional functionality as an undocumented 
(mis)feature.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Bootstrappable Debian - proposal of needed changes

2013-01-16 Thread Johannes Schauer 
Hi,

On Wed, Jan 16, 2013 at 01:50:17PM +, Ian Jackson wrote:
> > 5. Cross-Builds field
> > =
> > 
> > For even further automation and also for quality assurance, we propose
> > another new field for source packages which indicates whether or not
> > this source package is supposed to be cross compilable.
> 
> Is it possible that packages might only cross build for certain
> targets ?  Or only for certain hosts ?

Yes. But for the intended purpose of this field, it does not make much
sense to encode the information on which architecture and for which
architecture a source package cross compiles.

If a source package would not compile on some architectures or for some
architectures, then it would be Cross-Builds:No.

If the Cross-Builds field is being introduced, then only a few base
source packages *must* carry this field. For all other source packages,
this field would be optional.

The tools we developed can always be used to calculate which source
packages are necessary to cross compile a minimal build system.
Therefor, this field would only be:

 - a more obvious way for the maintainer of a source package to know
   that his/her package is one of those that must be cross compilable
   for any upcoming architecture.

 - a more obvious way for a bootstrapper to see which native build
   dependency cycles could easily be solved by cross compiling some
   source packages

The field is therefor rather low priority compared to the other ideas.

> I haven't spotted anything hideously wrong.  I have three suggestions
> for changes:
> 
>  * Packages should explicitly declare which profiles they support.
>This should be done with a Profile field in the source stanza
>of debian/control.

Good idea - this would make it even more analogous to the "Architecture"
field and its meaning in source and binary stanzas in ./debian/control.

>  * It should be made explicit in the spec that building occurs with
>  zero or one profile, not several.

As far as I understood (but I'm not the one who actually cross-compiles
things in real life), different dependencies might be needed during
cross compilation of some source packages. If that source package must
be cross compiled for a minimal base system and if it also must be built
with reduced build dependencies, then two build profiles at the same
time are necessary. In this case a "cross" and "stage1" profile.

>  * The concrete syntax in build-depends should not use < > but rather
>  reuse the architecture qualification syntax.

You basically propose to extend the architecture qualification syntax
from a single disjunction into a conjunctive normal form expression. If
any number of disjunctions is allowed, your proposal will also support
more than one profile at the same time.

What would an example of a different namespace than "profile:" be?

>From the perspective of dependency analysis, your proposal seems to be
able to carry all information that is needed for it. I leave it up to
you guys to decide on which you like better.

Thanks for your input!

cheers, josch


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130116160543.GA30841@hoothoot

Re: Bootstrappable Debian - proposal of needed changes

2013-01-16 Thread Johannes Schauer 
Hi,

On Wed, Jan 16, 2013 at 04:00:15PM +0100, Matthias Klose wrote:
> this only takes care about packages with a reduced package set built,
> or packages with reduced functionality. There are same cases missing:
> 
>  - extra build dependencies for cross builds, like for gcc-4.7:
>{gobjc++,gccgo,gfortran}-
>profile:cross?
> 
>  - build dependencies for running the check target. Usually these
>dependencies can be ignored when cross-building packages, or when
>building a package natively with DEB_BUILD_OPTIONS=nocheck.
>profile:check? There are not few packages which can be easier
>cross-built when identifying and dropping these build dependencies.
> 
> So it does make sense to build with two profiles like stage1 & check.

You probably mean a "nocheck" profile?

Your first example indeed demonstrates why multiple profiles are useful
to be enabled at once.

The second example can be accomplished with only one profile by marking
all dependencies that are not being needed by a "nocheck" profile as not
being needed by the "stage1" profile as well.

So instead of:

  Build-Depends: foo , bar 

and then needing two profiles at the same time, one could have:

  Build-Depends: foo , bar 

Though I agree that the first option looks more maintainable.

There is also the idea of a "nodocs" profile which would work like
DEB_BUILD_OPTIONS=nodocs.

Whether or not "nocheck" and "nodocs" can/should become build profiles
is of course still to be debated.

An argument for them becoming build profiles is, that the analysis
algorithm would then be able to just choose the less dangerous "nodocs"
or "nocheck" profile instead of a "stage1" profile if they break a
dependency cycle. How safe/dangerous choosing a profile is, could be
evaluated by the number of binary packages which are not built with a
given profile but which are needed as build dependencies by other source
packages. While a "stage1" profile is likely to not build binary
packages which are needed somewhere else, the "nodocs" and "nocheck"
profiles will likely not lead to needed binary packages not being
compiled.

So "nocheck" and "nodocs" profiles could allow "safer" reduced builds.

An argument against "nodocs" might be, that since (most?) *-doc packages
are Architecture:all, the build dependencies that are needed by them to
be built are already/should be included in Build-Depends-Indep anyways.
The current algorithms discard the Build-Depends-Indep field as
Architecture:all binary packages do naturally not need to be built
during the bootstrapping process.

cheers, josch


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130116162652.GB30841@hoothoot

Pure-mulitarch Cross Toolchains

2013-01-16 Thread Wookey 
+++ Matthias Klose [2013-01-16 15:37 +0100]:
> Am 15.01.2013 19:18, schrieb Johannes Schauer:
> > This mechanism also covers cross-compiler bootstraping. The eglibc, gcc,
> > and kernel packages already have the neceassary staged-build info, but
> > the build profiles (1.) part is also needed to specifiy the reduced
> > build-deps. The cross-toolchain bootstrap ceases to be a special case if
> > treated this way and just becomes packages to be built in stages using
> > the profiles mechansim, like many others in the base system (but for
> > build arch taregtting host, arch, rather than built for host-arch). See
> > the wiki article at [11].
> > 
> > [11] http://wiki.debian.org/MultiarchCrossToolchains
> 
> Please stop calling this "MultiarchCrossToolchains". It was already wrong when
> used in the Emdebian context, and on some GSOC pages. What you are apparently
> aiming for is a cross compiler re-using the target libraries built (natively).

The target libraries can be built natively or cross-built. Clearly
cross-building is necessary when the target architecture does not yet
exist (e.g. arm64). The point is that the library dependencies use the
multiarch file locations and mechanisms, rather than extra copies in
different locations.

I agree this is separate from multiarch path support in the
cross-toolchain for finding libraries and headers for non-toolchain
libs. What term would you like me to use for this cross-toolchain
arangement? multiarch-libraryCrossToolchains? 
PureMultiarchCrossToolchains? FullyMultiarchedCrossToolchains?

Yes it's a bit confusing, because multiarch affects various aspects
of the toolchain. I'm happy to use a different name to avoid
confusion, this just seems to me to be the logical conclusion of
'mulitarching the cross toolchains' (see discussion below), so it
seemed a reasonable name. 

> However this is not yet done, 

It was done in Thibg's GSOC project for 4.7.2-4. Yes it needs more
work to properly integrate, test, and make bootstrappable, but we have a
working implementation (modulo keeping up with your amazing rate of
new uploads :-). (For which kudos, even if it does make it hard to
keep up!)

> requires dependencies on "foreign" architectures

It does.

> and only is a very special case, 

This is where we seem to disagree. I think it should be the standard
case (for binary distro cross-toolchains).

> not helping for targets where these are not yet
> available (like for the arm64 bootstrap). Having a cross-toolchain just built 
> on
> the host architecture (targeting the target architecture), should still be an
> option.

This is still an option - you just cross-build the target libraries as
part of the bootstrap. The wiki page gives the runes.

I am not convinced of the benefit in also maintaining toolchains with
these libraries installed twice in different locations, now that we
have multiarch to make this unnecessary. But I would
like to see much wider discussion of this issue so we can reach
conclusions as a project on what the default cross-toochain setup
should be, and what non-default methods are also worth maintaining in the
packaging.

The main disadvantage of making use of the multiarch libraries is the
need to keep libgcc, libstdc++ etc in version lockstep across
architectures. But this applies to multiarch in general for all
libraries, and is something we manage in Debian as part of being a
distro. It is something to carefully consider. Is the reduced
independence of the cross-toolchain library versions a fatal flaw?

The main advantage is that the code you build against is actually the
code the toolchain was built against, not some other code that happens
to be installed in the expected location. Also build-dependencies work
automatically without having to have 'equivs' packages for libgcc1,
libstc++6-dev etc until the real native ones are built. And having one
copy of libgcc1:, libstdc++: on the system
instead of two seems like good practice to me. 

Another advantage is that for normal cross-toolchain builds you don't
need to do a 3-stage bootstrap build, because you already have the
target-arch libc, libgcc1, libstc++ etc available so you just need to
rebuild gcc without staging. Much quicker and simpler. This is
(fundamentally) how the emdebian toolchain builds worked for many
years. 

Using multiarch libraries also greatly simplifies the gcc packaging
(if we are able to drop multilib equivalents as a result). Again we
disagree on this point.

I think we should be encouaging people to install arm-linux-gnueabi
and arm-linux-gnueabihf cross-compilers if they want to target both
those arches, not install one or the other, each of which is
multilibbed to output code for both, with a corresponding collection
of libgcc's. I realise that upstream is not yet convinced of the
benefits of this view of the world, but I think we should be using it
and demonstrating its effectiveness (assuming we believe that
multiarch is actually the right way to be dealing wit

Re: Bootstrappable Debian - proposal of needed changes

2013-01-16 Thread Colin Watson 
On Tue, Jan 15, 2013 at 07:18:40PM +0100, Johannes Schauer wrote:
> Besides bootstrapping, these build profiles could also be used for
> embedded builds, and to allow for changed buil-deps when cross-building.

On a related point, see:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695287

I've been thinking, and talking to Wookey, about how to do this sanely.
The best idea I have is for those packages for which we have -triplet
versions (gcc-x.y et al, pkg-config, and so on) to have an extra control
field called something like "Cross-Tool-Available: yes".  sbuild and
dpkg-checkbuilddeps could then use the presence of this field to know
that they need to translate "Build-Depends: gcc-4.6" into
"Build-Depends: gcc-4.6:native, gcc-4.6-arm-linux-gnueabihf" when
cross-compiling to armhf, say.  Given my recent sbuild patches, it's
very easy for sbuild to do this once we have agreement on how it should
detect when to do so.

This is cleaner than any of the other options I've come up with: it
doesn't require hardcoding a list of "toolchain packages" that have
special cross versions; it would allow us to stop having to shove
pkg-config-HOST into cross-build chroots; and it wouldn't require
dpkg-checkbuilddeps to violate layers by looking in the apt cache, at
least as long as the available file is up to date.  Does it seem sane to
people?

> While this field is meant to make sure not to allow any profile built
> binary package to be uploaded to the archive, it can also be abused to
> only allow "some" build profiles to be uploaded. For example ubuntu
> might generally forbid profile built binary packages to be uploaded
> except for packages built with the "ubuntu" profile only.

I'm not sure we (Ubuntu) would actually want to do this, FWIW.  It
wouldn't buy us much since all our binaries are required to be built on
our own buildds anyway.  That said, the ability to have conditional
build-dependencies for Ubuntu and its descendant dpkg-vendors would be
valuable; but I'm wary of feature creep.

> 5. Cross-Builds field
> =
> 
> For even further automation and also for quality assurance, we propose
> another new field for source packages which indicates whether or not
> this source package is supposed to be cross compilable.

I don't think we should do this.  Instead, we should have a cross-buildd
that regularly tests whether packages are cross-buildable, and over time
we should expect packages considerably beyond just the base system to be
cross-buildable.  I want to be able to take any package that I might
find on (for the sake of argument ...) an Ubuntu phone and expect that I
can cross-build it cleanly; I don't want cross-building to be this
strange thing that only works for a few exceptional packages, and I
think that having this field sets that expectation.  The more packages
that just work, the easier it will be to do anything related to
cross-building.

This shouldn't be unrealistic, although it's certainly ambitious.
http://people.canonical.com/~cjwatson/cross/armhf/raring/ shows about
35% of Ubuntu main cross-building cleanly right now, and there are lots
of cross-build and multiarch patches sitting in the Debian BTS (I've
forwarded and/or uploaded everything I've done) which would improve the
state of a similar core-ish set of Debian source packages to something
similar.  There are really only a handful of underlying causes
representing many of the remaining failures - and yes, I know these are
fairly hard (perl, python, gobject-introspection, ...) but they aren't
intractable.

> If Debian wants to incorporate the ability to being bootstrappable in its
> policy, then there *must* be some packages which are cross compiled for
> a minimal build system. Adding this header to those source packages
> would make it a bug if they do not actually cross compile. Without this
> header, cross compilation would be wishlist as usual.

This would be better done by way of an external list of the packages
that need to cross-build cleanly.

> Furthermore, cross compilation is one of the methods a porter can use to
> break build dependency cycles. If some packages carry this new field
> then not only could a porter decide quicker whether or not a source
> package is cross compilable, an algorithm could also incorporate this
> information to automatically break build dependency cycles for cross
> compilation.

While this is true, having stared at similar things myself in the past,
I've come to believe that it's a better use of time to just make
everything in sight cross-buildable than to spend lots of effort trying
to algorithmically decide what might work or not.

> If more automated bootstrapping of Debian is desired, then at least build
> profiles (1.) should be introduced.

I am strongly in favour of something occupying the general position of
build profiles; there are several otherwise-intractable cross-building
problems that will require something like them.  I don't have much
interest in the spe

Re: Bootstrappable Debian - proposal of needed changes

2013-01-16 Thread Colin Watson 
On Wed, Jan 16, 2013 at 12:26:53AM +0100, Jakub Wilk wrote:
> 2) Support for the :any qualifiers in Build-Depends was added to apt
> in February 2010, and to dpkg in March 2012; AFAIK it's still not
> supported by wanna-build.

I'm working on the buildd/wanna-build side of things at the moment (late
last week).  Now that I know where to find the branches that need to be
changed it would be easy for me to add support for profiles as well once
they're agreed elsewhere, and I'm motivated to do so.

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130116174249.gb3...@riva.dynamic.greenend.org.uk

Re: Bootstrappable Debian - proposal of needed changes

2013-01-16 Thread Colin Watson 
On Wed, Jan 16, 2013 at 11:52:42AM +0800, Paul Wise wrote:
> That sounds useful, so yes. arm64 is on the way, it would be a nice
> test case but I guess wookey/Sledge are onto that. The SH-5 CPU
> architecture apparently exists but has no port. There are also the
> architectures with open-source CPU designs OpenRISC and LatticeMico32
> (LM32, used in the Milkymist SoC).

Also potentially x32.

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130116174457.gc3...@riva.dynamic.greenend.org.uk

Re: Bootstrappable Debian - proposal of needed changes

2013-01-16 Thread Colin Watson 
On Wed, Jan 16, 2013 at 03:40:52PM +, Neil Williams wrote:
> On Wed, 16 Jan 2013 13:50:17 +
> Ian Jackson  wrote:
> > Is it possible that packages might only cross build for certain
> > targets ?  Or only for certain hosts ?

In my reply I'm going to use autoconf terminology, so host =>
architecture built for, and target => only relevant when talking about
cross-tools themselves.  (Not everyone likes this terminology, but it is
widespread and autoconf tends to do a better job than virtually any
other build system at supporting cross-building so I tend to end up
preferring its terms.)

> For certain host architectures: yes, definitely. Any source package
> which includes assembly (there are more than most people expect) and any
> package which then has a build dependency on a binary package
> built from the source package(s) containing assembly and so on.

Such packages would typically fail to build natively for the
architecture in question too.  I think it's more interesting to consider
cases where, of the set of architectures on which a package can be built
natively, it can cross-build to some of those host architectures but not
others.

However, I can't think of any such packages right now, although no doubt
anything is possible; at least, it seems to me to be rare enough not to
be worth inventing metadata for.  I suspect that most such instances
will be where packages only cross-build to "similar enough"
architectures, e.g. where you happen to have a multilib toolchain
available, so amd64 to i386, or perhaps architectures with the same bit
length and/or endianness.  In other words, such bugs would be a function
of the combination of build and host architectures, rather than just of
the host architecture.  (I haven't run into many of these, since I
cross-build from amd64 to armhf and they're fairly different.)

Neil, can you think of any packages that meet this stricter criterion?

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130116175500.gd3...@riva.dynamic.greenend.org.uk

Re: Bootstrappable Debian - proposal of needed changes

2013-01-16 Thread Neil Williams 
On Wed, 16 Jan 2013 17:55:00 +
Colin Watson  wrote:

> On Wed, Jan 16, 2013 at 03:40:52PM +, Neil Williams wrote:
> > On Wed, 16 Jan 2013 13:50:17 +
> > Ian Jackson  wrote:
> In my reply I'm going to use autoconf terminology, so host =>
> architecture built for, and target => only relevant when talking about
> cross-tools themselves.  (Not everyone likes this terminology, but it is
> widespread and autoconf tends to do a better job than virtually any
> other build system at supporting cross-building so I tend to end up
> preferring its terms.)

I remember the same convention using builD == desktop Host == handheld.
Not perfect, but it may help others as it's helped me. (You can also
think of Build == Big.)

> > For certain host architectures: yes, definitely. Any source package
> > which includes assembly (there are more than most people expect) and any
> > package which then has a build dependency on a binary package
> > built from the source package(s) containing assembly and so on.
> 
> Such packages would typically fail to build natively for the
> architecture in question too.

Oh absolutely.

>  I think it's more interesting to consider
> cases where, of the set of architectures on which a package can be built
> natively, it can cross-build to some of those host architectures but not
> others.
> 
> However, I can't think of any such packages right now, although no doubt
> anything is possible; at least, it seems to me to be rare enough not to
> be worth inventing metadata for.  I suspect that most such instances
> will be where packages only cross-build to "similar enough"
> architectures, e.g. where you happen to have a multilib toolchain
> available, so amd64 to i386, or perhaps architectures with the same bit
> length and/or endianness.  In other words, such bugs would be a function
> of the combination of build and host architectures, rather than just of
> the host architecture.  (I haven't run into many of these, since I
> cross-build from amd64 to armhf and they're fairly different.)
> 
> Neil, can you think of any packages that meet this stricter criterion?

Not from memory, no. The list could have changed from when I last
looked into it.

A different - similarly strict - criterion would catch out glib2, gtk
and others- introspection / marshalling code. This can cause a build
failure but can also cause more difficult bugs which only show at
runtime. Skipping the execution causes missing functionality, copying
data from the build architecture is likely to cause other kinds of
misbehaviour or crashes.

I had this problem with Emdebian Crush - none of the icons would
display because all of the cache data was to have been generated in the
build but had to be omitted during the cross build.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgp_pq_1lDARI.pgp
Description: PGP signature

Re: Bootstrappable Debian - proposal of needed changes

2013-01-16 Thread Johannes Schauer 
On Wed, Jan 16, 2013 at 05:41:31PM +, Colin Watson wrote:
> > If Debian wants to incorporate the ability to being bootstrappable
> > in its policy, then there *must* be some packages which are cross
> > compiled for a minimal build system. Adding this header to those
> > source packages would make it a bug if they do not actually cross
> > compile. Without this header, cross compilation would be wishlist as
> > usual.
> 
> This would be better done by way of an external list of the packages
> that need to cross-build cleanly.

It will be possible for every developer to generate this "external list"
by using the tools that were developed during my GSoC.

Note, that a consistent list cannot be generated at this point, as some
source packages have conflicts in their multiarch cross build
dependencies. So (as pointed out in my initial email) the algorithms
exist but package meta data must still be fixed.

What we have right now is:

- the *minimum* list of source packages that must be cross compiled
- the *maximum* list of source packages that must be cross compiled

The actual list of source packages that must be cross compiled is
somewhere in between, closer to the minimum list of source packages and
depends on how multiarch cross dependencies will be resolved in
practice.

> > Furthermore, cross compilation is one of the methods a porter can use to
> > break build dependency cycles. If some packages carry this new field
> > then not only could a porter decide quicker whether or not a source
> > package is cross compilable, an algorithm could also incorporate this
> > information to automatically break build dependency cycles for cross
> > compilation.
> 
> While this is true, having stared at similar things myself in the past,
> I've come to believe that it's a better use of time to just make
> everything in sight cross-buildable than to spend lots of effort trying
> to algorithmically decide what might work or not.

The only way to "algorithmically decide" this, is to actually attempt to
cross build the package in question. For example by using a buildd which
constantly tests source packages for cross buildability as you already
mentioned in your last email.

>From what I was told by wookey and others, cross building should only be
the very last option and therefor the current version of the tools
tries to select as few source packages as possible for cross
compilation. Cross building is also currently regarded as only the last
resort for breaking native build dependency cycles.

>From the perspective of the dependency analysis algorithms, deciding
that cross compilation is suddenly an easy thing which can and should be
done for most source packages, is just switching the dependency
resolution from native to cross. So the developed algorithms would still
all be valid if building things cross were suddenly preferred.

> > The question remains of how many source packages would have to have the
> > proposed new fields added to them to make a full bootstrap from zero
> > possible. If the Gentoo USE flags were not too far off and assuming or
> > tools do the correct thing so far, then:
> > 
> >  - the number of source packages that has to be modified with the new
> >fields is at maximum 83 (there might be a smaller set).
> 
> https://wiki.ubuntu.com/CrossBuilding/BuilddChroot (thanks, Matthias)
> suggests that we are not that far from being able to at least get to a
> sensible minimal chroot with a modicum of hacking.

Not sure whether you meant to reply to my paragraph above yours, but you
linked to a different selection of packages than I meant. The 83 source
packages I mentioned were not the minimal build system but those which
need to have build profile information added to break dependency cycles.

The ~300 source packages out of which the 83 are selected can be found
here:
http://wiki.debian.org/DebianBootstrap/TODO#Break_dependency_cycles_using_staged_builds

The list is of Debian Sid from (IIRC) August last year and consists of
the main build dependency problem. All those ~300 source packages depend
upon each other through their build dependencies.  Maximum 83 of them
must be modified to break this strongly connected component into a
directed acyclic graph.

cheers, josch


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130116195100.GA12783@hoothoot

Re: Package version numbers

2013-01-16 Thread Christian PERRIER 
Quoting Raphael Hertzog (hert...@debian.org):
> On Wed, 16 Jan 2013, Christian PERRIER wrote:
> > Quoting Jakub Wilk (jw...@debian.org):
> > > I would paint the bikeshed the following color:
> > > 0.8.51+dfsg1-0.1
> > 
> > Isn't that missing the fact that this is a t-p-u upload, which is
> > indeed the start of a "wheezy" branch?
> > 
> > So something we were naming "+wheezy" in the past and which we
> > now name "+deb70u1".
> 
> It's not really relevant because sid has already diverged and has a higher
> (upstream) version.
> 
> So 0.8.51+dfsg1-0.1 is acceptable IMO.


Indeed.

And the theoretical question of "what if sid hadn't diverged wrt
upstream" is silly as this is a native package.

Steve, problem solved, then..:). We were bikeshedding a bit too much.

Merci, Raphaël.



signature.asc
Description: Digital signature

Re: Bootstrappable Debian - proposal of needed changes

2013-01-16 Thread Matthias Klose 
Am 16.01.2013 17:26, schrieb Johannes Schauer:
> Hi,
> 
> On Wed, Jan 16, 2013 at 04:00:15PM +0100, Matthias Klose wrote:
>> this only takes care about packages with a reduced package set built,
>> or packages with reduced functionality. There are same cases missing:
>>
>>  - extra build dependencies for cross builds, like for gcc-4.7:
>>{gobjc++,gccgo,gfortran}-
>>profile:cross?
>>
>>  - build dependencies for running the check target. Usually these
>>dependencies can be ignored when cross-building packages, or when
>>building a package natively with DEB_BUILD_OPTIONS=nocheck.
>>profile:check? There are not few packages which can be easier
>>cross-built when identifying and dropping these build dependencies.
>>
>> So it does make sense to build with two profiles like stage1 & check.
> 
> You probably mean a "nocheck" profile?
> 
> Your first example indeed demonstrates why multiple profiles are useful
> to be enabled at once.
> 
> The second example can be accomplished with only one profile by marking
> all dependencies that are not being needed by a "nocheck" profile as not
> being needed by the "stage1" profile as well.
> 
> So instead of:
> 
>   Build-Depends: foo , bar 
> 
> and then needing two profiles at the same time, one could have:
> 
>   Build-Depends: foo , bar 
> 
> Though I agree that the first option looks more maintainable.

and I would assume that it better documents the intention. It maybe could be
used for a (native) test rebuild on a slow architecture, where you wouldn't do
that otherwise. For this case I don't want to have a package built with reduced
functionality.

> There is also the idea of a "nodocs" profile which would work like
> DEB_BUILD_OPTIONS=nodocs.

This seems to be less important, because these b-d's most likely end up b-d-i.
Side question: if a package offers a --disable-docs configure option, is there a
good way to enable it for arch only builds?

> An argument for them becoming build profiles is, that the analysis
> algorithm would then be able to just choose the less dangerous "nodocs"
> or "nocheck" profile instead of a "stage1" profile if they break a
> dependency cycle. How safe/dangerous choosing a profile is, could be
> evaluated by the number of binary packages which are not built with a
> given profile but which are needed as build dependencies by other source
> packages. While a "stage1" profile is likely to not build binary
> packages which are needed somewhere else, the "nodocs" and "nocheck"
> profiles will likely not lead to needed binary packages not being
> compiled.
> 
> So "nocheck" and "nodocs" profiles could allow "safer" reduced builds.

did somebody make an analysis for what stage1 and stage2 are currently used for?
I would like to see more descriptive profiles, so I can break down these
profiles ... For packages within a buildd chroot, I see

 - nobindings -- disabling bindings for various interpreters/languages.
   (could be something for DEB_BUILD_OPTIONS too, like nobindings=python,tcl)

 - no ... gobject-introspection, building udev without gobject-introspection
   and libgirepository1.0-dev.

Even if there are a few more, I like it better to make the profiles more
granular, and then letting the people doing a bootstrap decide what to include
in a stage1 or stage2 build.

Matthias


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50f708e9.4090...@ubuntu.com

Re: Pure-mulitarch Cross Toolchains

2013-01-16 Thread Matthias Klose 
Am 16.01.2013 17:30, schrieb Wookey:
> +++ Matthias Klose [2013-01-16 15:37 +0100]:
>> Am 15.01.2013 19:18, schrieb Johannes Schauer:
>>> This mechanism also covers cross-compiler bootstraping. The eglibc, gcc,
>>> and kernel packages already have the neceassary staged-build info, but
>>> the build profiles (1.) part is also needed to specifiy the reduced
>>> build-deps. The cross-toolchain bootstrap ceases to be a special case if
>>> treated this way and just becomes packages to be built in stages using
>>> the profiles mechansim, like many others in the base system (but for
>>> build arch taregtting host, arch, rather than built for host-arch). See
>>> the wiki article at [11].
>>>
>>> [11] http://wiki.debian.org/MultiarchCrossToolchains
>>
>> Please stop calling this "MultiarchCrossToolchains". It was already wrong 
>> when
>> used in the Emdebian context, and on some GSOC pages. What you are apparently
>> aiming for is a cross compiler re-using the target libraries built 
>> (natively).
> 
> The target libraries can be built natively or cross-built. Clearly
> cross-building is necessary when the target architecture does not yet
> exist (e.g. arm64). The point is that the library dependencies use the
> multiarch file locations and mechanisms, rather than extra copies in
> different locations.
> 
> I agree this is separate from multiarch path support in the
> cross-toolchain for finding libraries and headers for non-toolchain
> libs. What term would you like me to use for this cross-toolchain
> arangement? multiarch-libraryCrossToolchains? 
> PureMultiarchCrossToolchains? FullyMultiarchedCrossToolchains?
> 
> Yes it's a bit confusing, because multiarch affects various aspects
> of the toolchain. I'm happy to use a different name to avoid
> confusion, this just seems to me to be the logical conclusion of
> 'mulitarching the cross toolchains' (see discussion below), so it
> seemed a reasonable name. 

just leave any *Multiarch* out of the name.

>> However this is not yet done, 
> 
> It was done in Thibg's GSOC project for 4.7.2-4. Yes it needs more
> work to properly integrate, test, and make bootstrappable, but we have a
> working implementation (modulo keeping up with your amazing rate of
> new uploads :-). (For which kudos, even if it does make it hard to
> keep up!)
> 
>> requires dependencies on "foreign" architectures
> 
> It does.
> 
>> and only is a very special case, 
> 
> This is where we seem to disagree. I think it should be the standard
> case (for binary distro cross-toolchains).
> 
>> not helping for targets where these are not yet
>> available (like for the arm64 bootstrap). Having a cross-toolchain just 
>> built on
>> the host architecture (targeting the target architecture), should still be an
>> option.
> 
> This is still an option - you just cross-build the target libraries as
> part of the bootstrap. The wiki page gives the runes.
> 
> I am not convinced of the benefit in also maintaining toolchains with
> these libraries installed twice in different locations, now that we
> have multiarch to make this unnecessary. But I would
> like to see much wider discussion of this issue so we can reach
> conclusions as a project on what the default cross-toochain setup
> should be, and what non-default methods are also worth maintaining in the
> packaging.
> 
> The main disadvantage of making use of the multiarch libraries is the
> need to keep libgcc, libstdc++ etc in version lockstep across
> architectures. But this applies to multiarch in general for all
> libraries, and is something we manage in Debian as part of being a
> distro. It is something to carefully consider. Is the reduced
> independence of the cross-toolchain library versions a fatal flaw?
> 
> The main advantage is that the code you build against is actually the
> code the toolchain was built against, not some other code that happens
> to be installed in the expected location. Also build-dependencies work
> automatically without having to have 'equivs' packages for libgcc1,
> libstc++6-dev etc until the real native ones are built. And having one
> copy of libgcc1:, libstdc++: on the system
> instead of two seems like good practice to me. 
> 
> Another advantage is that for normal cross-toolchain builds you don't
> need to do a 3-stage bootstrap build, because you already have the
> target-arch libc, libgcc1, libstc++ etc available so you just need to
> rebuild gcc without staging. Much quicker and simpler. This is
> (fundamentally) how the emdebian toolchain builds worked for many
> years. 

emdebian is not debian. emdebian has a rather limited subset what to target and
what to build. This may fit emdebian, but not a cross-toolchain for debian.

> Using multiarch libraries also greatly simplifies the gcc packaging
> (if we are able to drop multilib equivalents as a result). Again we
> disagree on this point.

no, your perception is wrong. there is no way that multilib'ed GCC builds will
go away. Yes, emdebian does ignore the to

Re: Bootstrappable Debian - proposal of needed changes

2013-01-16 Thread Colin Watson 
On Wed, Jan 16, 2013 at 06:47:01PM +, Neil Williams wrote:
> A different - similarly strict - criterion would catch out glib2, gtk
> and others- introspection / marshalling code. This can cause a build
> failure but can also cause more difficult bugs which only show at
> runtime. Skipping the execution causes missing functionality, copying
> data from the build architecture is likely to cause other kinds of
> misbehaviour or crashes.

Yeah, that and gtk-doc.  I do have some ideas on how to deal with
gobject-introspection; but I think it's going to require a
gobject-introspection-TRIPLET for each host architecture, which is one
reason I want to have a reasonably generalisable solution to the
build-dep substitution problem.

There's probably no general magic bullet to the problem where
cross-built packages build successfully but turn out to be inadequate in
some way, although I guess that file list comparison against
natively-built packages would catch a majority of the problems.

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130116215218.ga24...@riva.dynamic.greenend.org.uk

Wheezy testing versus Wheezy release repositories: confused on how to get source code

2013-01-16 Thread Paul Johnson 
I installed Wheezy beta 4 from CD and was surprised that compiz window
manager was removed.  Compiz is the best thing about Linux, that's a
shame. I tracked down some explanations, don't want to start a flame
war about that decision.

But, even though Debian is not including compiz, I still love it and
am going to build compiz and use it. My plan is to get the compiz
source packages from the most recent Wheezy which did include compiz.
But I'm having trouble finding that and understanding the way the
repositories fit together. The Wheezy repo that was testing during the
Squeeze time is a different thing from the Wheezy that is Wheezy
release beta 4? Right? In Wheezy beta 4, why can't I see the same
compiz files that I could see when I ran Squeeze with the wheezy repo
enabled in apt?

pj
-- 
Paul E. Johnson
Professor, Political Science  Assoc. Director
1541 Lilac Lane, Room 504  Center for Research Methods
University of Kansas University of Kansas
http://pj.freefaculty.org   http://quant.ku.edu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAErODj-nqNi_j2+3SaJLCxggm=-aa9uhtcwcfp_wtrbbec1...@mail.gmail.com

Re: Wheezy testing versus Wheezy release repositories: confused on how to get source code

2013-01-16 Thread Matthias Klumpp 
Hi!
Why don't you just use the Sid version?
=> http://packages.debian.org/sid/compiz

2013/1/16 Paul Johnson :
> [...]
> The Wheezy repo that was testing during the
> Squeeze time is a different thing from the Wheezy that is Wheezy
> release beta 4? Right?
No. Testing *is* Wheezy at time ;-)

> In Wheezy beta 4, why can't I see the same
> compiz files that I could see when I ran Squeeze with the wheezy repo
> enabled in apt?
Because the Compiz packages have now been removed from Testing7Wheezy,
I guess. But you should be fine with the Sid version.

Cheers,
   Matthias


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKNHny-7U=kww1+emb2f6v5qxtmy2xi972otbmjn3gnyazi...@mail.gmail.com

how to handle architecture dependent headers in subdirectories

2013-01-16 Thread Matthias Klose 
There are some issues when you do have an architecture dependent header file
which needs to be in the multiarch specific include directory.  If the header
file is directly located in /usr/include, then moving it to
/usr/include/ usually is not a problem (except for quoting
issues as found in the packaging for libreoffice).  The compilers (checked here
GCC and clang) do include the multiarch include path as a path for system
includes too.

However there are some issues when you do need to split the header files into
different locations. Seen that with python2.7 and python3.3 in experimental,
however I think it is a concern for packages like openssl as well.

Looking at python in experimental (having the architecture independent headers
in /usr/include and the architecture dependent headers in
/usr/include/) you have some build failures.

For the python case:

 - moving all the headers to the multiarch include path doesn't work,
   because configure tests fail which assume the include directory
   a direct subdirectory of .

 - splitting the header installation into /usr/include and
   /usr/include/ doesn't work because packages do use
   sysconfig.get_python_inc() which only returns the former directory.
   (This is the current behaviour of the python packages in experimental).

  - Everything is fine when a package uses pkg-config or python-config,
because these give the correct include paths. However not every
packaged upstream does use these.

So I'm proposing to use a header which can be installed into /usr/include and
does include the header file included in a subdirectory installed into
/usr/include/ and works around the issue. Intending to do that
for python2.7. For python3.x I do intend to get the sysconfig.get_python_inc()
deprecated.

Attaching the proposed header file, intending to include it into the gcc package
as /usr/lib/gcc/multiarch.h.in

  Matthias
#if defined(__linux__)
# if defined(__x86_64__) && defined(__LP64__)
#  include 
# elif defined(__x86_64__) && defined(__ILP32__)
#  include 
# elif defined(__i386__)
#  include 
# elif defined(__alpha__)
#  include 
# elif defined(__ARM_EABI__) && defined(__ARM_PCS_VFP)
#  include 
# elif defined(__ARM_EABI__) && !defined(__ARM_PCS_VFP)
#  include 
# elif defined(__hppa__)
#  include 
# elif defined(__ia64__)
#  include 
# elif defined(__m68k__) && !defined(__mcoldfire__)
#  include 
# elif defined(__mips_hard_float) && defined(_MIPSEL)
#  if defined(_ABIO32)
#   include 
#  elif defined(_ABIN32)
#   include 
#  elif defined(_ABI64)
#   include 
#  else
#   error unknown multiarch location for @header@
#  endif
# elif defined(__mips_hard_float)
#  if defined(_ABIO32)
#   include 
#  elif defined(_ABIN32)
#   include 
#  elif defined(_ABI64)
#   include 
#  else
#   error unknown multiarch location for @header@
#  endif
# elif defined(__powerpc__) && defined(__SPE__)
#  include 
# elif defined(__powerpc__)
#  include 
# elif defined(__powerpc64__)
#  include 
# elif defined(__s390x__)
#  include 
# elif defined(__s390__)
#  include 
# elif defined(__sh__) && defined(__LITTLE_ENDIAN__)
#  include 
# elif defined(__sparc__)
#  include 
# elif defined(__sparc64__)
#  include 
# else
#   error unknown multiarch location for @header@
# endif
#elif defined(__FreeBSD_kernel__)
# if defined(__LP64__)
#  include 
# elif defined(__i386__)
#  include 
# else
#   error unknown multiarch location for @header@
# endif
#elif defined(__gnu_hurd__)
# include 
#else
# error unknown multiarch location for @header@
#endif

Re: Bug#698256: ITP: lz4 -- Extremely Fast Compression algorithm library

2013-01-16 Thread Nobuhiro Iwamatsu 
Hi,

On Wed, Jan 16, 2013 at 7:02 PM, Jakub Wilk  wrote:
> * Nobuhiro Iwamatsu , 2013-01-16, 09:51:
>
>> * URL : http://code.google.com/p/lz4/
>> * License : BSD 2-Clause License
>>  Programming Lang: C
>>  Description : Extremely Fast Compression algorithm library
>>
>> LZ4 is a very fast lossless compression algorithm.
>> This uses Dictionary compression, and only supports compression and
>> decompression unit blocks.
>
>
> This looks very promising, but also immature. The upstream makefile doesn't
> build a shared library, not even a static library, but only an executable
> ("lz4demo"). Are there any plans to change that?
>
Yes, I am correcting the part which you pointed out.
And I will send the patch to upstream.
A static library, shared library and sample program are provided when
this is installed in Debian.

Best regards,
  Nobuhiro

-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CABMQnV+C9GAxK1SvOmPMztDT4XriWM6P5o=fzuqzcjq0f8b...@mail.gmail.com

Re: Package version numbers

2013-01-16 Thread Stephen Kitt 
On Wed, 16 Jan 2013 19:16:26 +0100, Christian PERRIER 
wrote:
> Quoting Raphael Hertzog (hert...@debian.org):
> > On Wed, 16 Jan 2013, Christian PERRIER wrote:
> > > Quoting Jakub Wilk (jw...@debian.org):
> > > > I would paint the bikeshed the following color:
> > > > 0.8.51+dfsg1-0.1
> > > 
> > > Isn't that missing the fact that this is a t-p-u upload, which is
> > > indeed the start of a "wheezy" branch?
> > > 
> > > So something we were naming "+wheezy" in the past and which we
> > > now name "+deb70u1".
> > 
> > It's not really relevant because sid has already diverged and has a higher
> > (upstream) version.
> > 
> > So 0.8.51+dfsg1-0.1 is acceptable IMO.
> 
> Indeed.
> 
> And the theoretical question of "what if sid hadn't diverged wrt
> upstream" is silly as this is a native package.
> 
> Steve, problem solved, then..:). We were bikeshedding a bit too much.

Yup, thanks! A case of “Pourquoi faire simple quand on peut faire
compliqué ?” ;-) (“Why make things simple when they can be complicated?”)

An updated package is coming up shortly...

Regards,

Stephen


signature.asc
Description: PGP signature

Re: problematic shlibs entry in substvars file

2013-01-16 Thread Charles Plessy 
Le Wed, Jan 16, 2013 at 10:44:53AM +0800, Paul Wise a écrit :
> The version difference is probably due to symbols stuff, read
> deb-symbols(5), dpkg-shlibdeps(1), dpkg-gensymbols(1) and this wiki
> page:
> 
> http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps

Hi all,

note that since version 3.9.4, this is also well covered in the Policy's
chapter 8.

http://www.debian.org/doc/debian-policy/ch-sharedlibs.html

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130116225942.ga29...@falafel.plessy.net

Re: how to handle architecture dependent headers in subdirectories

2013-01-16 Thread Adam Borowski 
On Wed, Jan 16, 2013 at 11:32:45PM +0100, Matthias Klose wrote:
> There are some issues when you do have an architecture dependent header file
> which needs to be in the multiarch specific include directory.  If the header
> file is directly located in /usr/include, then moving it to
> /usr/include/ usually is not a problem (except for quoting
> issues as found in the packaging for libreoffice).  The compilers (checked 
> here
> GCC and clang) do include the multiarch include path as a path for system
> includes too.
> 
> However there are some issues when you do need to split the header files into
> different locations.

> So I'm proposing to use a header which can be installed into /usr/include and
> does include the header file included in a subdirectory installed into
> /usr/include/ and works around the issue.

> Attaching the proposed header file, intending to include it into the gcc 
> package
> as /usr/lib/gcc/multiarch.h.in

> #if defined(__linux__)
> # if defined(__x86_64__) && defined(__LP64__)
> #  include 
> # elif defined(__x86_64__) && defined(__ILP32__)
> #  include 
> # elif defined(__i386__)
> #  include 

This looks just like the solution ultimately chosen for #682183, except for
the include being monstrous.  Let's instead add a file to libc6-dev with
the following:

#define DEB_HOST_MULTIARCH "x86_64-linux-gnu"

(for different values of "x86_64-linux-gnu").  It might be either a new file
on its own, or an addition to one of existing headers.  This is currently
/usr/include/x86_64-linux-gnu/lua5.1-deb-multiarch.h except that it'd be a
pain to do this for every single package.

Having a #define that says "amd64" could be good, too.


Doing it this way would remove a yet another place that has to be changed
when adding a new arch.  Also, having it as a string allows other uses than
a static #include.


-- 
How to squander your resources: those silly Swedes have a sauce named
"hovmästarsås", the best thing ever to put on cheese, yet they waste it
solely on mere salmon.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130116232343.ga16...@angband.pl

Re: how to handle architecture dependent headers in subdirectories

2013-01-16 Thread Russ Allbery 
Matthias Klose  writes:

> There are some issues when you do have an architecture dependent header
> file which needs to be in the multiarch specific include directory.  If
> the header file is directly located in /usr/include, then moving it to
> /usr/include/ usually is not a problem (except for
> quoting issues as found in the packaging for libreoffice).  The
> compilers (checked here GCC and clang) do include the multiarch include
> path as a path for system includes too.

> However there are some issues when you do need to split the header files
> into different locations. Seen that with python2.7 and python3.3 in
> experimental, however I think it is a concern for packages like openssl
> as well.

> Looking at python in experimental (having the architecture independent
> headers in /usr/include and the architecture dependent headers in
> /usr/include/) you have some build failures.

> For the python case:

>  - moving all the headers to the multiarch include path doesn't work,
>because configure tests fail which assume the include directory
>a direct subdirectory of .

Why not just fix this bug instead?  That's what I did for OpenAFS.  I
think it's more robust than trying to split the header files apart.

This is probably a sign of badly-written configure probes anyway, since it
implies that configure is not using the compiler to test headers and is
instead poking about on the file system.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87bocog11m@windlord.stanford.edu

Re: problematic shlibs entry in substvars file

2013-01-16 Thread Paul Wise 
On Thu, Jan 17, 2013 at 6:59 AM, Charles Plessy wrote:
> Le Wed, Jan 16, 2013 at 10:44:53AM +0800, Paul Wise a écrit :
>> The version difference is probably due to symbols stuff, read
>> deb-symbols(5), dpkg-shlibdeps(1), dpkg-gensymbols(1) and this wiki
>> page:
>>
>> http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps
>
> Hi all,
>
> note that since version 3.9.4, this is also well covered in the Policy's
> chapter 8.
>
> http://www.debian.org/doc/debian-policy/ch-sharedlibs.html

I guess that #s-sharedlibs-symbols on that page should be referenced
by deb-symbols(5), dpkg-shlibdeps(1) and dpkg-gensymbols(1), could you
file a bug/patch about that on dpkg-dev?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caktje6f45lhcerscjmpybbzeox1oe2ai0rfhva1kwgb5xjh...@mail.gmail.com

Re: how to handle architecture dependent headers in subdirectories

2013-01-16 Thread Paul Wise 
Would it be possible to use something similar to the bits/ dir in
eglibc? Or would your proposal replace that?

/usr/include/python2.7/bits -> /usr/include/x86_64-linux-gnu/python2.7/bits

And in /usr/include/python2.7/*

#include 

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKTje6F7eY2Wjo9W9ao=f8xjpu7oorh2e3uifwy6syvjazs...@mail.gmail.com

Re: Bootstrappable Debian - proposal of needed changes

2013-01-16 Thread Charles Plessy 
Le Wed, Jan 16, 2013 at 05:26:52PM +0100, Johannes Schauer a écrit :
> 
> Whether or not "nocheck" and "nodocs" can/should become build profiles
> is of course still to be debated.

Hi all,

for the packages I maintain, I am now replacing the regression tests that
were ran during the build process by autopkgtest test suites.

http://dep.debian.net/deps/dep8/

(see http://developer.ubuntu.com/packaging/html/auto-pkg-test.html
 while Alioth-hosted sites seem to be in trouble)
   
If this eventually becomes the norm, then we will not need "nocheck" build
option or profile anymore.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130117013503.gc29...@falafel.plessy.net

Re: Bootstrappable Debian - proposal of needed changes

2013-01-16 Thread Wookey 
+++ Matthias Klose [2013-01-16 21:09 +0100]:
> Am 16.01.2013 17:26, schrieb Johannes Schauer:
> > On Wed, Jan 16, 2013 at 04:00:15PM +0100, Matthias Klose wrote:
> >>
> >> So it does make sense to build with two profiles like stage1 & check.

Yes. I can think of situations where being able to specify more than
one profile at a time would be useful/flexible. stage1 & cross for
example. 

I'd like to enable this if it doesn't make things too complicated.

> > Your first example indeed demonstrates why multiple profiles are useful
> > to be enabled at once.
> > 
> > The second example can be accomplished with only one profile by marking
> > all dependencies that are not being needed by a "nocheck" profile as not
> > being needed by the "stage1" profile as well.
> > 
> > So instead of:
> > 
> >   Build-Depends: foo , bar 
> > 
> > and then needing two profiles at the same time, one could have:
> > 
> >   Build-Depends: foo , bar 
> > 
> > Though I agree that the first option looks more maintainable.
> 
> and I would assume that it better documents the intention. It maybe could be
> used for a (native) test rebuild on a slow architecture, where you wouldn't do
> that otherwise. For this case I don't want to have a package built with 
> reduced
> functionality.

Makes sense. 

> > There is also the idea of a "nodocs" profile which would work like
> > DEB_BUILD_OPTIONS=nodocs.
> 
> This seems to be less important, because these b-d's most likely end up b-d-i.

There is potentially some overlap between DEB_BUILD_OPTIONS and
DEB_BUILD_PROFILES. Indeed implementing them as
DEB_BUILD_OPTIONS=profile=foo was in the spec at one point but we
moved away from that.

My feeling for the best way to think about this is that
DEB_BUILD_OPTIONS are for things that don't change the dependencies
(optimisation options, parallelisation options, most checks).
DEB_BUILD_PROFILES are for things that do have dependency
implications (bootstrap builds, embedded builds, check-only
build-deps, binaries not produced).

> Side question: if a package offers a --disable-docs configure option, is 
> there a
> good way to enable it for arch only builds?

Shouldn't this be done in the rules file for binary-arch/binary-indep
targets?

> did somebody make an analysis for what stage1 and stage2 are currently used 
> for?

Not a formal analysis, and having a done a few I suspect you have as
good an idea as anyone. I've found: Removing language bindings,
removing optinal library deps (selinux for eglibc for example, ldap
for gnupg or krb5), building without gui components when some fairly low-level
package also has a gui-tool that brings in a pile more build-deps. 

> I would like to see more descriptive profiles, so I can break down these
> profiles ... For packages within a buildd chroot, I see
> 
>  - nobindings -- disabling bindings for various interpreters/languages.
>(could be something for DEB_BUILD_OPTIONS too, like nobindings=python,tcl)
> 
>  - no ... gobject-introspection, building udev without gobject-introspection
>and libgirepository1.0-dev.
> 
> Even if there are a few more, I like it better to make the profiles more
> granular, and then letting the people doing a bootstrap decide what to include
> in a stage1 or stage2 build.

I can see some logic to this, and ultimately profiles _could_ be used
for anything like this. Packagers are best-placed to know which
aspects of their software are logically optional. But this could get
out of hand with a very long list in the build-deps line, so we should
resist going too crazy. 

libdose can cope with an arbitrary set of profiles, and work out which
ones provide linearisable builds, so maybe there is no actual need for
regularised names (stage1, stage2), so long as available profiles are
discoverable (as ijw mentioned - I agree that would be wise). 

I'm not sure how this might work with generating version numbers so
profiled builds supercede each other correctly in automated uploads
to a bootstrap repo. It's easy with 'stage1, stage2'. Tools would have
to get smarter with arbitrary names. But we can probably make it work
with a bit of thought. And it will work 'manually' without this (but
it's very annoying fighting reprepro all the time). 

One thing that should come out of this work is recomendations for
packagers on what profiles are available/recommended/supported by
tools. We can use the mechansim as much/little as seems sensible. 

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130117031831.gs5...@stoneboat.aleph1.co.uk

Re: Bootstrappable Debian - proposal of needed changes

2013-01-16 Thread Wookey 
+++ Ian Jackson [2013-01-16 13:50 +]:
> Johannes Schauer writes ("Bootstrappable Debian - proposal of needed 
> changes"):
> > 6. Conclusion
> > =
> ...
> 
> >  - do the proposals for the needed fields sound convincing? Can they be
> >improved? Do they have fundamental flaws?
> 
> I haven't spotted anything hideously wrong.  I have three suggestions
> for changes:
> 
>  * Packages should explicitly declare which profiles they support.
>This should be done with a Profile field in the source stanza
>of debian/control.

I agree this is a really good idea. They could be inferred from
parsing the build-deps line, but profiles that don't actually change
the build-deps could exist and they would be undiscoverable without a
field like this. I did think about putting this in the spec mail, but
decided it was long enough to be going on with. 

>  * It should be made explicit in the spec that building occurs with
>zero or one profile, not several.

This is something to ponder. We could decree that and it would
simplify some things. But I think there are good reasons to consider
what we gain from relatively granular profiles which brings along with
it the likelihood of needing to specify more than one. 

>  * The concrete syntax in build-depends should not use < > but rather
>reuse the architecture qualification syntax.

> This takes the < > metacharacters and reserves them for build
> profiles.  Metacharacters are very scarce and should only be used when
> necessary.

This is a good point. I really don't care what the syntax is so long
as as it represents the semantics we need. The current syntax was
suggested by the dpkg people, and it has been shown to be sufficient.
If we can make it work sensibly without using a new metacharacter then
that's fine by me. 

[snip very useful attempt to try and define a spec].

We do need something explicit like this writing down, so thanks for
doing that. In fact I'll copy it over the wiki page. The details of
this need a decision on whether more than one can be specified at a
time or not, before we can finalise them. 

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130117034544.gu5...@stoneboat.aleph1.co.uk

Bug#698329: ITP: sos -- This set of tools is designed to provide information to support organizations

2013-01-16 Thread Adam Stokes 
Package: wnpp
Severity: wishlist
Owner: Adam Stokes 

* Package name: sos
  Version : 2.3.1
  Upstream Author : Adam Stokes 
* URL : https://github.com/sosreport/sosreport
* License : GPL2+
  Programming Lang: Python
  Description : This set of tools is designed to provide information to 
support organizations

This set of tools is designed to provide information to support
organizations in an extensible manner, allowing third parties, package 
maintainers,
and anyone else to provide plugins that will collect and report information
that is useful for supporting software packages.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130117042707.25687.77206.reportbug@localhost

Re: Bootstrappable Debian - proposal of needed changes

2013-01-16 Thread Wouter Verhelst 
Hi Johannes,

On Tue, Jan 15, 2013 at 07:18:40PM +0100, Johannes Schauer wrote:
[...]
> 2. Build-Profiles (extension 1)
> ===
> 
> When a source package is built with fewer build dependencies (cross,
> embedded, stage1, nodocs...), then it often happens that it does not
> build one or more of its binary packages at all (e.g. foo-gtk, foo-java,
> foo-doc). While this is a minor nuisance during a half automated
> bootstrap, a fully automated bootstrapping process needs to know which
> binary packages a source package does not build if it is compiled in one
> of its profiles. We therefore propose a new field for binary packages in
> their control file which indicates for which profiles it builds.
> 
>   Builds-With-Profile: !stage1 !embedded
> 
> Different profile names are separated by spaces similar to the
> Architecture field. A binary package with the above field would not be
> built during the profile builds "stage1" or "embedded". Binary packages
> which do not have this field would default to being built by every
> profile. This field would mean a minor change to dpkg-gencontrol.
> 
> 
> 3. Build-profiles (extension 2)
> ===
> 
> A build profile is set either using a DEB_ environment variable or a
> command-line option. DEB_STAGE has been used historically in a few
> packages with staged build support, but that is specific to the
> staged-builds purpose. For the more generic build-profiles
> DEB_BUILD_PROFILE= is proposed instead - (only 7 existing
> packages would need to be changed - patches exist for some already).
> 
> Setting the build-profile causes dpkg-checkbuilddeps to use the modified
> deps, dpkg-gencontrol to mark the built package with a new field:
> 
>   Built-With-Profile: stage1 cross
> 
> This new field is optional and just meant to mark binary packages such
> that they can not accidentally make it to the archive. Another idea is
> to encode this information in the package version by adding a ~stage1.
> Using the field is more powerful as source packages can also be built
> with multiple profiles activated at once and the field can store a list
> of profile names. In above example, the binary package was built with
> the cross profile activated for cross compilation and the stage1 profile
> activated to break a build dependency cycle.
> 
> While this field is meant to make sure not to allow any profile built
> binary package to be uploaded to the archive, it can also be abused to
> only allow "some" build profiles to be uploaded.

If wanna-build is updated to support these two fields, then I imagine it
can run the bootstrapping dependency algorithm. While you wouldn't want
to upload a package to the debian.org archive when the architecture is
as yet incomplete, the same isn't true for the debian-ports.org archive.

It would require some patches for wanna-build to understand that package
"foo" would need to be rebuilt once a particular profile is fully built
and available, but I don't think that's impossible.

However, to do that, there's one thing I'm missing in your mail: there
will be cases where packages, when built in a particular profile do not
support some functionality. That is, the package is available and does
most of what the full package does, but because some build-dependency is
missing, it doesn't support some feature or other -- for example, let's
say that a document translation package (which we'll call "foo") which
supports many input formats does not support XML as an input format when
built in the stage1 profile. The output of its stage1 build would not
change the number of binary packages built with the source package, it
would just build a binary package with reduced functionality.

Now it might be that a package build-depends on our package foo because
it needs to translate documents in that XML format into something else,
With your proposal, there's no way for the build-depending package to
declare that it needs a version of foo that was built at a richer
profile than stage1.

Is this something you've considered?

-- 
Copyshops should do vouchers. So that next time some bureaucracy requires you
to mail a form in triplicate, you can mail it just once, add a voucher, and
save on postage.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130117073357.ga1...@grep.be