Re: Multi-Arch .udeb ?

[Steve Langasek]

On Mon, Jun 27, 2011 at 04:31:50PM -0700, Keith Packard wrote:
> On Tue, 28 Jun 2011 00:04:23 +0100, Steve Langasek  wrote:

> > The convention I've adopted so far for udeb-building packages has been to
> > install libraries in /usr/lib instead of to /usr/lib/$arch.

> Ok, that makes sense to me. Of course, it's also harder for me to manage
> in the package as I'm installing the same library in the .udeb as I do
> in the library .deb file. I'll manage.

> > BTW, if the package you're asking after happens to be fontconfig, I have a
> > patch here that I'll be sending on shortly. :-)

> Oddly, it is (the only package I have with a .udeb). I'm running a
> multi-arch version of that on this machine and it appears to work
> correctly. You can see this at:

> git://git.debian.org/git/pkg-freedesktop/fontconfig-debian

Yep, looks almost identical to my patch here, with only one difference: the
runtime support packages need to be marked Multi-Arch: foreign in order to
satisfy the dependencies of the multiarch libraries.  Attached.  (This is
also bug #614208.)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
From ab0b231256f358485b0e950d0e3d4bfb75e331c3 Mon Sep 17 00:00:00 2001
From: Steve Langasek 
Date: Tue, 28 Jun 2011 08:12:16 +0100
Subject: [PATCH] mark fontconfig, fontconfig-config Multi-Arch: foreign

the support packages providing arch-independent interfaces need to be
marked Multi-Arch: foreign, to satisfy the dependencies of the multiarch
libraries.
---
 debian/control |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/debian/control b/debian/control
index d9b2595..64e5b71 100644
--- a/debian/control
+++ b/debian/control
@@ -12,6 +12,7 @@ Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}, fontconfig-config
 Replaces: fontconfig-config (<< 2.5.93-1)
 Suggests: defoma (>= 0.7.0)
+Multi-Arch: foreign
 Description: generic font configuration library - support binaries
  Fontconfig is a font configuration and customization library, which
  does not depend on the X Window System. It is designed to locate
@@ -35,6 +36,7 @@ Architecture: all
 Depends: ${misc:Depends}, ucf (>= 0.29), ttf-dejavu-core | ttf-bitstream-vera | ttf-freefont | gsfonts-x11
 Replaces: fontconfig (<< 2.3.2-2)
 Conflicts: fontconfig (<< 2.3.2-2)
+Multi-Arch: foreign
 Description: generic font configuration library - configuration
  Fontconfig is a font configuration and customization library, which
  does not depend on the X Window System. It is designed to locate
-- 
1.7.5.4



signature.asc
Description: Digital signature

Re: Multi-Arch .udeb ?

[Keith Packard]

On Tue, 28 Jun 2011 08:14:07 +0100, Steve Langasek  wrote:

> Yep, looks almost identical to my patch here, with only one difference: the
> runtime support packages need to be marked Multi-Arch: foreign in order to
> satisfy the dependencies of the multiarch libraries.  Attached.  (This is
> also bug #614208.)

Then I guess I should mark that as closed then. I've pushed updated
packaging bits; I wouldn't mind if you'd check and make sure they look
right before I upload the resulting package.

-- 
keith.pack...@intel.com


pgplAxFDL1YQG.pgp
Description: PGP signature

Re: Multiarch in Debian unstable

[Joachim Breitner]

Hi,

Am Montag, den 27.06.2011, 11:54 +0100 schrieb Steve Langasek:
> Next steps for maintainers
> ==
> 
> If you are a maintainer of a shared library package, you can convert it to
> multiarch today following the instructions in the Debian wiki:
> 
>   http://wiki.debian.org/Multiarch/Implementation
> 
> If you have any questions about the multiarchification of libraries, please
> don't hesitate to ask on debian-devel@lists.debian.org.

I think I have successfully converted libnss-gw-name.¹ But it depends on
libnl, which has not been converted, which would result in this:

$ ldd debian/libnss-gw-name/./usr/lib/x86_64-linux-gnu/libnss_gw_name.so.2
linux-vdso.so.1 =>  (0x7fffcf558000)
libnl.so.1 => /usr/lib/libnl.so.1 (0x7f6fce913000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f6fce59)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f6fce30d000)
/lib64/ld-linux-x86-64.so.2 (0x7f6fced8c000)

Does this mean that I should wait and add a Depends on the new libnl
version once it comes out? Or will my package just not be
foreign-installable until libnl upgrades, in which case everything works
smoothly without changes or uploads from my side?

Thanks,
Joachim

¹ 
http://git.nomeata.de/?p=libnss-gw-name.git;a=commitdiff;h=7fd7f466f737b5d44f977d90c405bc142503a854
-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: Multiarch in Debian unstable

[Steve Langasek]

On Tue, Jun 28, 2011 at 02:05:05AM +0200, Vincent Lefevre wrote:
> > >   http://gcc.gnu.org/ml/gcc-help/2010-11/msg00341.html

> > This particular issue will not occur with multiarch, because /usr/lib/
> > will never be a symlink to /usr/lib in the canonical implementation.

> There will be the same issue if libraries are installed directly
> in /usr/lib/ (see below).

No, it's not the *same* issue.  The issue you referenced is /usr/lib taking
precedence over /usr/local/lib because of /usr/lib64 being a symlink.  In
multiarch, /usr/local/lib still takes precedence over /usr/lib. 
*/usr/lib/$arch* might take precedence over /usr/local/lib, and that's not
desirable, but it's not the same issue.

> > As a practical matter, the runtime path will list all of the multiarch paths
> > before all of the non-multiarch paths.

> Like what upstream GCC does. So, this means that if I have LIBRARY_PATH
> (and LD_LIBRARY_PATH) containing $HOME/lib, the library search path
> would be something like:

>   $HOME/lib/
>   /usr/local/lib/
>   /lib/
>   /usr/lib/
>   $HOME/lib
>   /usr/local/lib
>   /lib
>   /usr/lib


Huh?  Certainly not.  Why would you expect gcc to look in $HOME/lib/
if you haven't put $HOME/lib/ in your LIBRARY_PATH?  gcc isn't going
to magically append the architecture to all directories in the search path.

with LIBRARY_PATH=$HOME/lib, the build-time order would (currently) be:

   $HOME/lib
   /usr/x86_64-linux-gnu/lib
   /usr/lib/x86_64-linux-gnu
   /lib
   /usr/lib

(via:
 gcc -print-search-dirs | sed -n -e's/^libraries: =//p' | sed -e's/:/\n/g' |
 xargs -n1 readlink -f)

So at build time, there doesn't appear to be an issue.

> > (It does this already today.)

> No, it doesn't. Well, it may depend on the tool, but for instance,
> with the dynamic linker, the search order is:

>   prefix1/lib/
>   prefix1/lib
>   prefix2/lib/
>   prefix2/lib
>   prefix3/lib/
>   prefix3/lib

> instead of:

>   prefix1/lib/
>   prefix2/lib/
>   prefix3/lib/
>   prefix1/lib
>   prefix2/lib
>   prefix3/lib

> (according to strace). I think this is the right solution to avoid
> the problem mentioned above.

Ok - I didn't think we had this right, but it's great to know that we do.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Multiarch in Debian unstable

[Bernhard R. Link]

* Steve Langasek  [110628 08:42]:
> > On the downside, files which are the same would be duplicated, but since a
> > vast majority of libraries use #ifdefs instead of modifying the files, the
> > waste would be infinitessimally low.
>
> I don't know what this "vast majority of libraries" is.  Most of the
> libraries I work on have at least one header that's autogenerated from
> configure at build time.

Comparing all lib[abc]*-dev packages being found both in amd64
(little-endian,64bit) and sparc (big endian,32bit, quite some solaris
compatibility crap) in unstable that contain a /usr/include:

328 packages
295 no differences

That means 90% of the packages in this sample have the same
/usr/include in this two cases. Even assuming that for some high
percentage of those packages comparing two vastly different architectures
like amd64 and sparc is not enough, that would still be quite a
majority.

And taking a cursory look at the packages that differ, I think for most
getting rid of those changes would actually improve the code quality of
them. (Though for some packages that might mean acknowledging it is no
longer 1998).

Bernhard R. Link


-- 
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/20110628092533.ga2...@pcpool00.mathematik.uni-freiburg.de

Re: Multiarch in Debian unstable

[Steve Langasek]

On Tue, Jun 28, 2011 at 07:40:03AM +0200, Hendrik Sattler wrote:
> Am Montag, 27. Juni 2011, 16:20:23 schrieb Steve Langasek:
> > So this:
> > > So it should be a matter of changing that to print this instead on Debian
> > > multiarch: $ gcc -print-multi-os-directory
> > > x86_64-linux-gnu
> > > $ gcc -print-multi-os-directory -m32
> > > i486-linux-gnu

> > would definitely be wrong, because neither
> > /usr/lib/x86_64-linux-gnu/x86_64-linux-gnu nor
> > /usr/lib/x86_64-linux-gnu/i486-linux-gnu will exist.  Correct would be '.'
> > and '../i486-linux-gnu', but that's of little help if one doesn't know what
> > it's relative to in the first place!

> Then make it "../x86_64-linux-gnu" instead of "."
> That will always work for all subdirectories of /usr/lib, no?

That doesn't tell the consumer of this information what it's relative *to*.
How does the consumer know that it's relative to "some subdirectory of
/usr/lib", rather than relative to /usr/lib itself?  (Answer: it can't.)

> One question, though:
> How are build tools like CMake converted to use Multiarch directories for
> the installation rule?

I don't have a generic recipe for converting cmake to install to the
multiarch directory.  If someone has one, please add it to
.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@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/20110628093414.gg23...@virgil.dodds.net

Re: Multiarch in Debian unstable

[Steve Langasek]

On Tue, Jun 28, 2011 at 10:58:47AM +0200, Joachim Breitner wrote:
> Am Montag, den 27.06.2011, 11:54 +0100 schrieb Steve Langasek:
> > Next steps for maintainers
> > ==
> > 
> > If you are a maintainer of a shared library package, you can convert it to
> > multiarch today following the instructions in the Debian wiki:
> > 
> >   http://wiki.debian.org/Multiarch/Implementation
> > 
> > If you have any questions about the multiarchification of libraries, please
> > don't hesitate to ask on debian-devel@lists.debian.org.

> I think I have successfully converted libnss-gw-name.¹ But it depends on
> libnl, which has not been converted, which would result in this:

> $ ldd debian/libnss-gw-name/./usr/lib/x86_64-linux-gnu/libnss_gw_name.so.2
>   linux-vdso.so.1 =>  (0x7fffcf558000)
>   libnl.so.1 => /usr/lib/libnl.so.1 (0x7f6fce913000)
>   libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f6fce59)
>   libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f6fce30d000)
>   /lib64/ld-linux-x86-64.so.2 (0x7f6fced8c000)

> Does this mean that I should wait and add a Depends on the new libnl
> version once it comes out? Or will my package just not be
> foreign-installable until libnl upgrades, in which case everything works
> smoothly without changes or uploads from my side?

The latter - it's fine to convert these in parallel, with each individual
package only becoming foreign-installable once the dependencies are
converted.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@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/20110628094144.gh23...@virgil.dodds.net

Re: Multi-Arch .udeb ?

[Steve Langasek]

On Tue, Jun 28, 2011 at 01:40:41AM -0700, Keith Packard wrote:
> On Tue, 28 Jun 2011 08:14:07 +0100, Steve Langasek  wrote:

> > Yep, looks almost identical to my patch here, with only one difference: the
> > runtime support packages need to be marked Multi-Arch: foreign in order to
> > satisfy the dependencies of the multiarch libraries.  Attached.  (This is
> > also bug #614208.)

> Then I guess I should mark that as closed then. I've pushed updated
> packaging bits; I wouldn't mind if you'd check and make sure they look
> right before I upload the resulting package.

Looks perfect, thanks!

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@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/20110628095840.gi23...@virgil.dodds.net

Re: pam_listfile / pam_supair

[Wouter Verhelst]

On Tue, Jun 28, 2011 at 06:51:48AM +0200, Stanisław Findeisen wrote:
> On 2011-06-27 18:42, Bastian Blank wrote:
> > On Mon, Jun 27, 2011 at 05:49:34PM +0200, Stanisław Findeisen wrote:
> >> This specifies that users sf, u2 and u3 can each do passwordless su to
> >> users root and sf2. User sf2 can do passwordless su to user u2. You can
> >> also use "debug" (anywhere on the command line) for additional debug
> >> information in auth.log.
> > 
> > Could you please explain what makes this superior to sudo?
> > 
> > Bastian
> 
> I don't know what sudo is. I always use 'su -' . :-)

Then you should learn. Urgently :-)

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
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/20110628092542.gp3...@carillon.nixsys.be

Re: Multiarch in Debian unstable

[Wouter Verhelst]

On Tue, Jun 28, 2011 at 02:30:51AM +0200, Vincent Lefevre wrote:
> On 2011-06-27 15:59:27 +0100, Simon McVittie wrote:
> > If by "fat binaries" you mean executables,
> 
> No, I meant libraries (the term "fat binary" is used by the GMP library,
> but is here restricted to x86 subarchs).
> 
> > If by "fat binaries" you mean shared libraries, they could either go in
> > /usr/lib, or go in /usr/lib/TUPLE for every appropriate tuple (using hard
> > links or something).
> 
> See my other message concerning a possible problem with the search
> directory order.
> 
> > But there's no real advantage in doing that, you could
> > just as easily install several "thin" libraries.
> 
> Perhaps multiarch partly makes fat libraries more or less obsolete
> (unless some data could be shared, such as debugging symbols).

That's impossible. Debugging symbols have data on which parts of which
code segments point to which source lines, and by definition, that kind
of data would be different for every architecture.

The random data that a library might store in .text segments (string
initializers and such) could be shared depending on the implementation
of the linker producing fat binaries, but that kind of data is going to
be fairly small compared to the number of code segments in the library
anyway.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
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/20110628072816.go3...@carillon.nixsys.be

Bug#631927: ITP: libhttp-server-simple-authen-perl -- Authentication plugin for HTTP::Server::Simple

[Gonéri Le Bouder]

Package: wnpp
Severity: wishlist
Owner: "Gonéri Le Bouder" 


* Package name: libhttp-server-simple-authen-perl
  Version : 0.0.4 
  Upstream Author : Tatsuhiko Miyagawa 
* URL : http://search.cpan.org/dist/HTTP-Server-Simple-Authen/ 
* License : Artistic / GPL
  Programming Lang: Perl
  Description : Authentication plugin for HTTP::Server::Simple

 HTTP::Server::Simple::Authen is an HTTP::Server::Simple plugin to allow HTTP
 authentication. Authentication scheme is pluggable and you can use whatever
 Authentication protocol that Authen::Simple supports.



--
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/20110628105804.28425.76744.report...@tosh-r630.rulezlan.org

Bug#631928: ITP: emacs-calfw -- A calendar framework for Emacs

[KURASHIKI Satoru]

Package: wnpp
Severity: wishlist
Owner: KURASHIKI Satoru 


* Package name: emacs-calfw
  Version : 0.2.1
  Upstream Author : SAKURAI, Masashi 
* URL : https://gist.github.com/kiwanami/emacs-calfw/
* License : GPL3
  Programming Lang: Emacs Lisp
  Description : A calendar framework for Emacs

This program displays a pretty cool calendar view in the Emacs buffer,
which also work with org-agenda, google calendar, and ical.



-- 
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/20110628110236.31740.60043.reportbug@localhost

Re: Multiarch in Debian unstable

[Hendrik Sattler]

Zitat von Steve Langasek :

One question, though:
How are build tools like CMake converted to use Multiarch directories for
the installation rule?


I don't have a generic recipe for converting cmake to install to the
multiarch directory.  If someone has one, please add it to
.


Maybe a patch to
http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/GNUInstallDirs.cmake
can be provided?

Then, projects that use CMake and include this module automatically  
get support for multiarch. Those that don't probably need  
Debian-specific patches(*) or the debian/rules script handles it  
somehow itself.


HS

(*) Question: are other distributions going to follow the Debian  
multiarch scheme?




--
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/20110628124704.9692660f6iqgc...@mail.hendrik-sattler.de

Bug#631929: ITP: gnomad2 -- music manager for Creative Labs NOMAD and Zen devices

[Alessio Treglia]

Package: wnpp
Severity: wishlist
Owner: Alessio Treglia 

* Package name: gnomad2
  Version : 2.9.5
  Upstream Author : Linus Walleij 
* URL : http://gnomad2.sourceforge.net/
* License : GPL
  Programming Lang: C
  Description : music manager for Creative Labs NOMAD and Zen devices

 Gnomad2 is a GUI built on top of GTK/GNOME 2, id3lib and libnjb that makes
 it possible to transfer tracks and files from/to Creative NOMAD and Zen
 devices. It is designed much like an ordinary graphical FTP program.

I'm trying to reintroduce this as it seems upstream has finally woken up.



-- 
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/20110628110720.26917.46346.reportbug@alessio-laptop

Re: relationships with GNU as an upstream - call for feedback

[Josselin Mouette]

Le mardi 21 juin 2011 à 17:26 +0200, Stefano Zacchiroli a écrit : 
> I'll be glad to talk about that. But I would also like to take the
> chance to present how we feel about GNU as an upstream, in case we have
> anything more to say about GNU than what we have to say about other
> upstreams (see for example initiatives like [1,2,3]).

I’m not a GNU package maintainer (unless you still consider GNOME a GNU
project), so I’m not saying anything about GNU as upstream developers,
but if you want to discuss frankly our issues with them, I hope you can
talk about RMS and the handful of holier-than-thou followers who always
find something that is “not free enough”. 
There’s the topic of non-free firmwares of course (which suddenly become
free when they are shipped as EPROMs), and there’s the insanity that is
said every other day about Mono and anything loosely related to
Microsoft.

These people still represent the voice of the community in the minds of
journalists. They should consider it a great responsibility on their
shoulders, and I think they are abusing it; instead of promoting the
actual voice of the community, they are scaring people away by extremist
views based on incorrect claims.

I’d also join the crowd on the topic of non-free documentation which is
still extremely cumbersome for us, and forces people to add non-free APT
lines to install documentation for their free software.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


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

Re: Multiarch in Debian unstable

[Bernhard R. Link]

* Steve Langasek  [110628 00:36]:
> > Is there anything for nss plugins yet? As plugins for libc one needs to
> > make sure that if it is installed, it is installed for all installed libcs.
> > With bi-arch/multilib one can get there by just having it compiled for all
> > possible variants. Is there any way to not break nss modules with
> > multiarch?
>
> If you care about the nss module being available for all of the
> architectures you're running, you simply go through the same process to
> convert the nss package to multiarch and install the package for each
> architecture.

Please note that this "if" does not make sense. NSS modules used are a
global setting and every libc using program needs them or name services
will not be available.

> No special handling has been proposed for nss modules beyond
> that - though this is already a substantial improvement over the status quo,
> where about half our nss modules have biarch versions available and the
> other half don't.

The nss modules without support currently mostly do so because they pull
in some other libraries (which usually also opens another can of worms
anyway).

For those modules that have support right now, multiarch will mean every
single user has to remember that every time something will pull in a new
architecture they also have to install the nss module for that
architecture. That is quite a regression to the current status quo.

Bernhard R. Link


-- 
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/20110628131927.ga24...@pcpool00.mathematik.uni-freiburg.de

Re: Multiarch in Debian unstable

[Vincent Lefevre]

On 2011-06-28 09:54:34 +0100, Steve Langasek wrote:
> On Tue, Jun 28, 2011 at 02:05:05AM +0200, Vincent Lefevre wrote:
> > > >   http://gcc.gnu.org/ml/gcc-help/2010-11/msg00341.html
> 
> > > This particular issue will not occur with multiarch, because
> > > /usr/lib/ will never be a symlink to /usr/lib in the
> > > canonical implementation.
> 
> > There will be the same issue if libraries are installed directly
> > in /usr/lib/ (see below).
> 
> No, it's not the *same* issue.  The issue you referenced is /usr/lib taking
> precedence over /usr/local/lib because of /usr/lib64 being a symlink.

No, the real problem is that /usr/lib64 takes the precedence over
/usr/local/lib (with upstream's GCC). Note that if /usr/lib64 were
a real directory, the library should have been installed directly
in /usr/lib64 and the problem would be the same.

> In multiarch, /usr/local/lib still takes precedence over /usr/lib.

OK.

> */usr/lib/$arch* might take precedence over /usr/local/lib, and
> that's not desirable, but it's not the same issue.

If /usr/lib/$arch takes precedence over /usr/local/lib, that's the
same class of problem: an arch-specific directory takes precedence
over all the conventional lib directories specified in the path.

> > > As a practical matter, the runtime path will list all of the
> > > multiarch paths before all of the non-multiarch paths.
> 
> > Like what upstream GCC does. So, this means that if I have LIBRARY_PATH
> > (and LD_LIBRARY_PATH) containing $HOME/lib, the library search path
> > would be something like:
> 
> >   $HOME/lib/
> >   /usr/local/lib/
> >   /lib/
> >   /usr/lib/
> >   $HOME/lib
> >   /usr/local/lib
> >   /lib
> >   /usr/lib
> 
> Huh?  Certainly not.  Why would you expect gcc to look in $HOME/lib/
> if you haven't put $HOME/lib/ in your LIBRARY_PATH?  gcc isn't going
> to magically append the architecture to all directories in the search path.

Well, upstream GCC does search prefix/lib64 even if $LIBRARY_PATH
contains only prefix/lib.

The specifications should be very clear about:
  * in the (ordered) list of directories in which the libraries will
be searched (by static and dynamic linkers), depending on the
value of LIBRARY_PATH and LD_LIBRARY_PATH;
  * the directory in which the libraries should be installed by
development tools.

> with LIBRARY_PATH=$HOME/lib, the build-time order would (currently) be:
> 
>$HOME/lib
>/usr/x86_64-linux-gnu/lib
>/usr/lib/x86_64-linux-gnu
>/lib
>/usr/lib
> 
> (via:
>  gcc -print-search-dirs | sed -n -e's/^libraries: =//p' | sed -e's/:/\n/g' |
>  xargs -n1 readlink -f)
> 
> So at build time, there doesn't appear to be an issue.

That's with Debian's GCC.

The upstream version behaves differently: it first includes all the
lib64 variants (which is bad, IMHO). For instance, with

  LIBRARY_PATH=/home/vlefevre/gmp/athlon64/lib:/home/vlefevre/x86_64/lib

I got:

  /home/vlefevre/gmp/athlon64/lib/x86_64-unknown-linux-gnu/4.3.1/
  /home/vlefevre/gmp/athlon64/lib/../lib64/
  /home/vlefevre/x86_64/lib/x86_64-unknown-linux-gnu/4.3.1/
  /home/vlefevre/x86_64/lib/../lib64/
  /usr/local/stow/gcc-4.3.1/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/
  /usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/
  
/usr/local/stow/gcc-4.3.1/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../../x86_64-unknown-linux-gnu/lib/x86_64-unknown-linux-gnu/4.3.1/
  
/usr/local/stow/gcc-4.3.1/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../../x86_64-unknown-linux-gnu/lib/../lib64/
  
/usr/local/stow/gcc-4.3.1/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../x86_64-unknown-linux-gnu/4.3.1/
  
/usr/local/stow/gcc-4.3.1/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../../lib64/
  /lib/x86_64-unknown-linux-gnu/4.3.1/
  /lib/../lib64/
  /usr/lib/x86_64-unknown-linux-gnu/4.3.1/
  /usr/lib/../lib64/
  /home/vlefevre/gmp/athlon64/lib/
  /home/vlefevre/x86_64/lib/
  
/usr/local/stow/gcc-4.3.1/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../../x86_64-unknown-linux-gnu/lib/
  /usr/local/stow/gcc-4.3.1/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../
  /lib/
  /usr/lib/

BTW, that's a completely different problem, but I wonder why GCC
(Debian's and upstream) no longer includes /usr/local/lib, while
cpp has /usr/local/include in its search path. This doesn't seem
to be consistent.

> > > (It does this already today.)
> 
> > No, it doesn't. Well, it may depend on the tool, but for instance,
> > with the dynamic linker, the search order is:
> 
> >   prefix1/lib/
> >   prefix1/lib
> >   prefix2/lib/
> >   prefix2/lib
> >   prefix3/lib/
> >   prefix3/lib
> 
> > instead of:
> 
> >   prefix1/lib/
> >   prefix2/lib/
> >   prefix3/lib/
> >   prefix1/lib
> >   prefix2/lib
> >   prefix3/lib
> 
> > (according to strace). I think this is the right solution to avoid
> > the problem mentioned above.
> 
> Ok - I didn't think we had this right, but it's great to know that we do.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 

Re: Multiarch in Debian unstable

[Vincent Lefevre]

On 2011-06-28 10:34:14 +0100, Steve Langasek wrote:
> On Tue, Jun 28, 2011 at 07:40:03AM +0200, Hendrik Sattler wrote:
> > Am Montag, 27. Juni 2011, 16:20:23 schrieb Steve Langasek:
> > > So this:
> > > > So it should be a matter of changing that to print this instead on 
> > > > Debian
> > > > multiarch: $ gcc -print-multi-os-directory
> > > > x86_64-linux-gnu
> > > > $ gcc -print-multi-os-directory -m32
> > > > i486-linux-gnu
> 
> > > would definitely be wrong, because neither
> > > /usr/lib/x86_64-linux-gnu/x86_64-linux-gnu nor
> > > /usr/lib/x86_64-linux-gnu/i486-linux-gnu will exist.  Correct would be '.'
> > > and '../i486-linux-gnu', but that's of little help if one doesn't know 
> > > what
> > > it's relative to in the first place!
> 
> > Then make it "../x86_64-linux-gnu" instead of "."
> > That will always work for all subdirectories of /usr/lib, no?
> 
> That doesn't tell the consumer of this information what it's relative *to*.
> How does the consumer know that it's relative to "some subdirectory of
> /usr/lib", rather than relative to /usr/lib itself?  (Answer: it can't.)

By reading the documentation?

-print-multi-os-directory
Print the path to OS libraries for the selected multilib, relative
to some lib subdirectory. If OS libraries are present in the lib
subdirectory and no multilibs are used, this is usually just ., if
OS libraries are present in lib sibling directories this
prints e.g. ../lib64, ../lib or ../lib32, or if OS libraries are
present in lib/ subdirectories it prints e.g. amd64, sparcv9
or ev6.

(though I don't know why it says "lib subdirectory" instead of
"lib directory" here).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


-- 
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/20110628135558.gd17...@prunille.vinc17.org

Re: Multiarch in Debian unstable

[Steve Langasek]

On Tue, Jun 28, 2011 at 03:19:27PM +0200, Bernhard R. Link wrote:
> * Steve Langasek  [110628 00:36]:
> > > Is there anything for nss plugins yet? As plugins for libc one needs to
> > > make sure that if it is installed, it is installed for all installed 
> > > libcs.
> > > With bi-arch/multilib one can get there by just having it compiled for all
> > > possible variants. Is there any way to not break nss modules with
> > > multiarch?

> > If you care about the nss module being available for all of the
> > architectures you're running, you simply go through the same process to
> > convert the nss package to multiarch and install the package for each
> > architecture.

> Please note that this "if" does not make sense. NSS modules used are a
> global setting and every libc using program needs them or name services
> will not be available.

There are plenty of programs for which NSS is not interesting.  Most apps
only need the hosts database, and that's only if they're networked apps.

> > No special handling has been proposed for nss modules beyond
> > that - though this is already a substantial improvement over the status quo,
> > where about half our nss modules have biarch versions available and the
> > other half don't.

> The nss modules without support currently mostly do so because they pull
> in some other libraries (which usually also opens another can of worms
> anyway).

The following NSS modules are not available in a biarch configuration today:

libnss_lwres.so.2
libnss_mysql.so.2
libnss_pgsql.so.2
libnss_sss.so.2
libnss_winbind.so.2
libnss_wins.so.2
libnss_db-2.2.3.so
libnss_db.so.2
libnss_gw_name.so.2
libnss_rainbow.so.2

The only nss modules outside of eglibc that *are* available in biarch today
are nss_ldap, nss_mdns*, nss_myhostname, and nss_extrausers.

> For those modules that have support right now, multiarch will mean every
> single user has to remember that every time something will pull in a new
> architecture they also have to install the nss module for that
> architecture. That is quite a regression to the current status quo.

libnss-myhostname and libnss-extrausers ship the biarch versions of the
module in the same package.  libnss_mdns builds a separate lib32nss-mdns
biarch package, and biarch libnss_ldap is only available in ia32-libs.  So
this is FUD.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#631959: ITP: stapler -- Stapler HTTP request handling engine

[James Page]

Package: wnpp
Severity: wishlist
Owner: James Page 


* Package name: stapler
  Version : 1.167
* URL : http://stapler.java.net
* License : BSD
  Programming Lang: Java
  Description : Stapler HTTP request handling engine

 Stapler is a library that "staples" your application objects to URLs,
 making it easier to write web applications. The core idea of Stapler
 is to automatically assign URLs for your objects, creating an intuitive
 URL hierarchy.
 .
 Stapler provides bindings for:
  * Commons Jelly
  * Groovy
  * JRuby
  * Java Server Pages



-- 
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/20110628171225.18172.80325.reportbug@hendrix.shouse.local

Bug#631960: ITP: stapler-adjunct-timeline -- Timeline visualisation library for use with stapler

[James Page]

Package: wnpp
Severity: wishlist
Owner: James Page 


* Package name: stapler-adjunct-timeline
  Version : 1.3
* URL : http://stapler.java.net
* License : BSD
  Programming Lang: Java, JavaScript
  Description : Timeline visualisation library for use with stapler

 This library provides a JavaScript based timeline visualisation
 component for embedding in web applications using the stapler
 HTTP request handling engine.



-- 
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/20110628171514.18293.83122.reportbug@hendrix.shouse.local

Bug#631961: ITP: maven-stapler-plugin -- Maven plugin for developing stapler applications

[James Page]

Package: wnpp
Severity: wishlist
Owner: James Page 


* Package name: maven-stapler-plugin
  Version : 1.15
* URL : http://stapler.java.net/
* License : Apache-2.0
  Programming Lang: Java
  Description : Maven plugin for developing stapler applications

 Maven2 plugin for developing web applications using the 
 Stapler HTTP request engine.



-- 
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/20110628171805.18393.94955.reportbug@hendrix.shouse.local

Re: Multiarch in Debian unstable

[Joachim Breitner]

Hi,

Am Dienstag, den 28.06.2011, 15:32 +0100 schrieb Steve Langasek:
> > > No special handling has been proposed for nss modules beyond
> > > that - though this is already a substantial improvement over the status 
> > > quo,
> > > where about half our nss modules have biarch versions available and the
> > > other half don't.
> 
> > The nss modules without support currently mostly do so because they pull
> > in some other libraries (which usually also opens another can of worms
> > anyway).
> 
> The following NSS modules are not available in a biarch configuration today:
> 
> [..]
> libnss_gw_name.so.2
> libnss_rainbow.so.2
> 
> The only nss modules outside of eglibc that *are* available in biarch today
> are nss_ldap, nss_mdns*, nss_myhostname, and nss_extrausers.

nss_gw_name would be if the depedency libnl had multilibs support.

> > For those modules that have support right now, multiarch will mean every
> > single user has to remember that every time something will pull in a new
> > architecture they also have to install the nss module for that
> > architecture. That is quite a regression to the current status quo.
> 
> libnss-myhostname and libnss-extrausers ship the biarch versions of the
> module in the same package.  libnss_mdns builds a separate lib32nss-mdns
> biarch package, and biarch libnss_ldap is only available in ia32-libs.  So
> this is FUD.

Earlier today I had converted libnss-myhostname to multi-arch, so the
package will only ship one module per package.

I tend to agree with Bernhard that it would be nice if it were made easy
for the user (e.g. a user on amd64 who runs some application in wine and
is surprised that the foo.local addresses stop working). But what can we
do? I don’t see any “easy” solution that would work right away. Maybe
add a new field or new value to the Multi-Arch field indicating that
this package should be installed for each foreign architecture set in
dpkg.conf, if possible? (Does not sound good to me, but maybe its a
discussion starter.)

Greetings,
Joachim



-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: Multiarch in Debian unstable

[Steve Langasek]

On Tue, Jun 28, 2011 at 07:56:42PM +0200, Joachim Breitner wrote:

> > libnss-myhostname and libnss-extrausers ship the biarch versions of the
> > module in the same package.  libnss_mdns builds a separate lib32nss-mdns
> > biarch package, and biarch libnss_ldap is only available in ia32-libs.  So
> > this is FUD.

> Earlier today I had converted libnss-myhostname to multi-arch, so the
> package will only ship one module per package.

> I tend to agree with Bernhard that it would be nice if it were made easy
> for the user (e.g. a user on amd64 who runs some application in wine and
> is surprised that the foo.local addresses stop working). But what can we
> do? I don’t see any “easy” solution that would work right away. Maybe
> add a new field or new value to the Multi-Arch field indicating that
> this package should be installed for each foreign architecture set in
> dpkg.conf, if possible? (Does not sound good to me, but maybe its a
> discussion starter.)

I agree it would be nice, but this seems to map to the (long unsolved)
problem of conditional depends - where you want A to pull in B only if C is
also installed.  If you solve that, you've got the NSS module question
solved as well.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Multiarch in Debian unstable

[Michael Biebl]

Hi,

Am 28.06.2011 19:56, schrieb Joachim Breitner:
>> The only nss modules outside of eglibc that *are* available in biarch today
>> are nss_ldap, nss_mdns*, nss_myhostname, and nss_extrausers.
> 
> nss_gw_name would be if the depedency libnl had multilibs support.

I'll be happy to take patches for libnl which make it multiarch ready.
Otherwise I'll update it as soon as I find some time to read up on multiarch, as
I haven't converted a package yet.

Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: debian-ppc port for ps3-otheros++

[Matthias Klose]

On 06/26/2011 11:35 PM, Ben Hutchings wrote:
> On Sun, 2011-06-26 at 08:04 -0400, Durandal Dokucheyav wrote:
>> Hello,
>>
>> I am contacting you guys on behalf of http://gitbrew.org.  We have
>> recently released the otherOS++ firmware for the Sony Playstation 3,
>> allowing the install of third-party OSes on the PS3 once again.  We
>> currently have Debian-PPC running on otherOS++ with full access to
>> RSX/SPE's, and would like to know if you would like to collaborate
>> with us on an official Debian port.
> 
> We wouldn't consider this as a distinct port, as the PS3 will run the
> same powerpc binaries as we already provide.  But I assume there is some
> specific hardware support (particularly for the SPEs) that is currently
> lacking from our powerpc port, and help on that would surely be welcome.

maybe check before communicating wrong things?  Both Debian and Ubuntu do ship a
toolchain targeting the SPUs. If something is wrong with it, just file bug 
reports.

  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/4e0a62df.1000...@debian.org

Re: throw away debs and source only uploads

[Hector Oron]

Hi,

  Chipping in late... sorry for that.

2011/6/7 Don Armstrong :
> On Tue, 07 Jun 2011, Andreas Barth wrote:

>> > Non-buildd binaries should still be allowed, but they should be
>> > followed immediately by a binNMU. [Are there any cases where we
>> > wouldn't want to rebuild the package after it was bootstrapped?]

>> There are cases where porters need to upload, because of "funny"
>> issues. Or hand-builds within sane buildd chroots where the buildd
>> software refuses. Or similar. (I think I did less than 10 such
>> uploads recently.)

> Ok. Am I correct that these odd cases are bugs which should be fixed?
>
> If so, it seems reasonable to queue a binNMU, and then file bugs
> appropriately if it failed.

FWIW, there are corner cases, besides cyclic build dependencies were a
bootstrap is needed. Some emulators might need some ROM code compiled
on one architecture to be run on another architecture. I have also
attended some requests where people was wanting to access porter boxes
to hand-build packages, IIRC, mlton compiler was one of such cases.
Having said that I believe our build daemon infrastructure is quite
good, but still there are several corner cases where manual uploads
are needed and there is nothing bad about it, even policy is not
against that. If ever consider source-only uploads, please make an
exception to the rule to allow corner cases like the ones discussed,
some to be followed by binNMU, some others not to be followed by
binNMU.

Best regards,
-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.


-- Would you like to make a donation for Debian Conference?
   ** http://debconf11.debconf.org/payments.xhtml **



--
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/BANLkTikafaw-Br0B4M=_n+t7vevjtrk...@mail.gmail.com

Bug#632002: ITP: pvclust -- Hierarchical Clustering with P-Values via Multiscale Bootstrap

[Charles Plessy]

Package: wnpp
Severity: wishlist
Owner: Charles Plessy 

  Package name: pvclust
  Version : 1.2-2
  Upstream Author : Ryota Suzuki , Hidetoshi Shimodaira 

  URL : http://www.is.titech.ac.jp/~shimo/prog/pvclust/
  License : GPL-2+
  Programming Lang: R
  Description : Hierarchical Clustering with P-Values via Multiscale 
Bootstrap

Maintainer: Debian Med Packaging Team 

Uploaders: Charles Plessy 
DM-Upload-Allowed: yes
Homepage: http://www.is.titech.ac.jp/~shimo/prog/pvclust/
Vcs-Git: git://git.debian.org/debian-med/pvclust.git
Vcs-Browser: http://git.debian.org/?p=debian-med/pvclust.git

Package: r-cran-pvclust
Architecture: all
Description: Hierarchical Clustering with P-Values via Multiscale Bootstrap
 pvclust is a package for assessing the uncertainty in
 hierarchical cluster analysis. It provides AU (approximately
 unbiased) p-values as well as BP (boostrap probability) values
 computed via multiscale bootstrap resampling.



-- 
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/20110629040143.7328.77954.reportbug@localhost.localdomain