Bug#631784: O: mediatomb -- UPnP MediaServer

[Reinhard Tartler]

Package: wnpp
Version: 0.12.1-2

On Fri, Jun 24, 2011 at 10:29:03 (CEST), Reinhard Tartler wrote:

[...]

> I know that I did the last upload of the package, but since I don't
> really use it, getting the package in shape is not really my
> priority. For the team, I ask you what to do about it. Do we have
> volunteers to get it in shape or shall we rather orphan/remove it from
> Debian?

Summary of this thread: Noone seems to have the time or interest to care
for mediatomb in Debian. I'm therefore orphaning the package with this
bug for now in the hope that someone finds the time to at least fix the
open RC bugs and change the ownership of the package to the Debian QA team.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4



-- 
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/87boxj207x@faui43f.informatik.uni-erlangen.de

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

[Geert Uytterhoeven]

On Mon, Jun 27, 2011 at 07:35, Mike Hommey  wrote:
> On Sun, Jun 26, 2011 at 10:35:08PM +0100, Ben Hutchings wrote:
>> On Sun, 2011-06-26 at 08:04 -0400, Durandal Dokucheyav wrote:
>> > 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.
>
> There actually *is* a separate port:
> http://wiki.debian.org/PowerPCSPEPort

That's unrelated.

It's a pity (and cause of confusion) of having SPE mean both "Signal Processing
Extension" (for FreeScale parts) and "Synergistic Processing Element" (for Cell
parts), both in a PowerPC context.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


--
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/BANLkTi=rkbhkjq9bdzkgv9z88zddlar...@mail.gmail.com

Re: Bug#631743: O: gdb -- The GNU Debugger

[Hector Oron]

Hi,

2011/6/26 Daniel Jacobowitz :

> I intend to orphan the gdb package.  I will continue to intermittently
> follow upstream development, and upstream is pretty active; not a lot
> of Debian-local work is needed.  There's a couple of local patches
> (bad Dan!) which could be submitted.  Or possibly dropped with the
> latest upstream.

  I am planning to adopt gdb and I am looking for interested parties to setup
a team for gdb maintainance. If you are interested, please let me know.

  Dan, thanks for all the fish.

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/banlktin2r50z1t_zme+6nr9gnv_a3en...@mail.gmail.com

Re: Bug#631743: O: gdb -- The GNU Debugger

[Luca Bruno]

Hector Oron scrisse:

> I am planning to adopt gdb and I am looking for interested parties
> to setup a team for gdb maintainance. If you are interested, please
> let me know.

Having a bunch of packages that strictly depend on it, I could help
with occasional contributions (mostly from time to time).
Please let me know once you have settled maintenance details with all
interested parties. 

Ciao, Luca

-- 
 .''`.  ** Debian GNU/Linux **  | Luca Bruno (kaeso)
: :'  :   The Universal O.S.| lucab (AT) debian.org
`. `'`  | GPG Key ID: 3BFB9FB3
  `- http://www.debian.org  | Debian GNU/Linux Developer


signature.asc
Description: PGP signature

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

[Neil Williams]

On Mon, 27 Jun 2011 10:43:38 +0200
Geert Uytterhoeven  wrote:

> On Mon, Jun 27, 2011 at 07:35, Mike Hommey  wrote:
> > On Sun, Jun 26, 2011 at 10:35:08PM +0100, Ben Hutchings wrote:
> >> On Sun, 2011-06-26 at 08:04 -0400, Durandal Dokucheyav wrote:
> >> > 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.
> >
> > There actually *is* a separate port:
> > http://wiki.debian.org/PowerPCSPEPort
> 
> That's unrelated.
> 
> It's a pity (and cause of confusion) of having SPE mean both "Signal 
> Processing
> Extension" (for FreeScale parts) and "Synergistic Processing Element" (for 
> Cell
> parts), both in a PowerPC context.

Disambiguation section added to the wiki page:
http://wiki.debian.org/PowerPCSPEPort#Signal_Processing_Extension

-- 


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



pgp9KIduM24UO.pgp
Description: PGP signature

Re: Multiarch in Debian unstable

[Török Edwin]

On 06/27/2011 01:54 PM, Steve Langasek wrote:
> currently the only authoritative way to get the multiarch path for a system
> is by calling dpkg-architecture, so many of these patches are not yet
> upstreamable; with the result that some upstream projects now have a hard
> time building on Debian without the addition of Debian patches.
> 
> Work is ongoing to formulate a proper, distribution-neutral interface for
> querying the correct multiarch path for a system.  In the meantime, if you
> are an upstream affected by this issue, or a maintainer of a package whose
> upstream is affected, you are welcome to join us in discussing these matters
> on debian-devel as well.

I think gcc already provides a way to find out the multiarch directory, so it 
should be only a matter of patching gcc.
Upstream would then just use gcc -print-multi-os-directory to find out the path 
(when building with gcc).

For example I currently get this:
On Linux:
$ gcc -print-multi-os-directory
.
$ gcc -print-multi-os-directory -m32
../../lib32

And on Solaris:
$ gcc -print-multi-os-directory
.
$ gcc -print-multi-os-directory -m64
sparcv9

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

(or whatever -m32 will use)

For example of packages that have been using gcc's -print-multi-os-directory 
since quite some time are:
- ltdl (libtool.m4): to find the runtime search path of the linker
- ClamAV: to automatically install to /usr/lib32 when you compile with -m32

For example here is an GPLv2 m4 macro to "guess" the multilib directory:
http://git.clamav.net/gitweb?p=clamav-devel.git;a=blob;f=m4/acinclude.m4#l844

If gcc was patched to output the correct multiarch directory then no upstream 
changes would be required for these packages.

Best regards,
--Edwin


-- 
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/4e087232.4080...@gmail.com

Re: Multiarch in Debian unstable

[Hector Oron]

Hello,

2011/6/27 Török Edwin :
> I think gcc already provides a way to find out the multiarch directory, so it 
> should be only a matter of patching gcc.

Please try not to confuse multiarch with multilibs.
There is also multiarch designation for sparc machines so they use
STT_GNU_IFUNC functions for relocations, nothing to do with what is
proposed here.

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/BANLkTik_=B=z0c_kk89nuy5acaf9uq-...@mail.gmail.com

sachin gautam has invited you to open a Google mail account

[sachin gautam]

I've been using Gmail and thought you might like to try it out. Here's an
invitation to create an account.


  You're Invited to Gmail!

sachin gautam has invited you to open a Gmail account.

Gmail is Google's free email service, built on the idea that email can be
intuitive, efficient, and fun. Gmail has:

 *Less spam*
Keep unwanted messages out of your inbox with Google's innovative
technology.

*Lots of space*
Enough storage so that you'll never have to delete another message.

*Built-in chat*
Text or video chat with sachin gautam and other friends in real time.

*Mobile access*
Get your email anywhere with Gmail on your mobile phone.

You can even import your contacts and email from Yahoo!, Hotmail, AOL, or
any other web mail or POP accounts.

Once you create your account, sachin gautam will be notified of your new
Gmail address so you can stay in touch. Learn
moreor get
started
!
Sign 
up

Google Inc. | 1600 Ampitheatre Parkway | Mountain View, California 94043

Re: Multiarch in Debian unstable

[Vincent Lefevre]

Hi,

On 2011-06-27 11:54:53 +0100, Steve Langasek wrote:
> Work is ongoing to formulate a proper, distribution-neutral interface for
> querying the correct multiarch path for a system.  In the meantime, if you
> are an upstream affected by this issue, or a maintainer of a package whose
> upstream is affected, you are welcome to join us in discussing these matters
> on debian-devel as well.
> 
> A summary of currently known upstream compatibility issues, and the status
> of prospective patches for them, can also be found in the Debian wiki here:
> 
>   http://wiki.debian.org/Multiarch/TheCaseForMultiarch#Impact

Just a comment...

How libraries are searched is not clear, but depending on how this
is done, there may be compatibility issues when the user installs
software in his home directory, in case he or some tool installs
libraries in $prefix/lib instead of $prefix/lib/.

For instance, if all the default .../lib/ directories have
the precedence over the .../lib directories listed in the user's
$LIBRARY_PATH, bad things can happen. This is the choice followed
by upstream GCC (lib64 directories have the precedence over the
user's lib directories), with the following consequence:

  http://gcc.gnu.org/ml/gcc-help/2010-11/msg00341.html

Related to that, will Linux support fat binaries[*] one day?
If this is possible, where should they be installed, and how
libraries would be searched in a consistent way to support
various kinds of libraries?

[*] containing different architectures, not just sub-architectures.

-- 
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/20110627133124.ga16...@prunille.vinc17.org

Re: Multiarch in Debian unstable

[Adam Borowski]

On Mon, Jun 27, 2011 at 12:16:41PM +, Hector Oron wrote:
> 2011/6/27 Török Edwin :
> > I think gcc already provides a way to find out the multiarch directory,
> > so it should be only a matter of patching gcc.
> 
> Please try not to confuse multiarch with multilibs.

What multilib does is allowing use of incompatible modes of the CPU: 32 bit
vs 64 bit, hard float vs soft float, etc.  In Debian non-biarch world, this
is done as separate architectures.

I wonder, is there any reason to not reuse -print-multi-os-directory for
multiarch?  Doing that has the benefit of being compatible with all but most
ancient versions of gcc.

Using this option for multiarch wouldn't even break its old use:

(amd64)$ gcc -print-multi-os-directory
.
(amd64)$ gcc -print-multi-os-directory -m32
../../lib32

Before the conversion of amd64 -m32 to i386, and sparc -m64 to sparc64, it
could keep using biarch paths for the time being but provide the correct
multiarch one when no -m is specified.

Otherwise, it produces oh so useful:
(amd64)$ arm-linux-gnueabi-gcc -print-multi-os-directory
.


-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


-- 
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/20110627131953.ga5...@angband.pl

Re: Multiarch in Debian unstable

[Steve Langasek]

On Mon, Jun 27, 2011 at 03:06:10PM +0300, Török Edwin wrote:
> On 06/27/2011 01:54 PM, Steve Langasek wrote:
> > currently the only authoritative way to get the multiarch path for a system
> > is by calling dpkg-architecture, so many of these patches are not yet
> > upstreamable; with the result that some upstream projects now have a hard
> > time building on Debian without the addition of Debian patches.

> > Work is ongoing to formulate a proper, distribution-neutral interface for
> > querying the correct multiarch path for a system.  In the meantime, if you
> > are an upstream affected by this issue, or a maintainer of a package whose
> > upstream is affected, you are welcome to join us in discussing these matters
> > on debian-devel as well.

> I think gcc already provides a way to find out the multiarch directory, so
> it should be only a matter of patching gcc.  Upstream would then just use
> gcc -print-multi-os-directory to find out the path (when building with
> gcc).

> For example I currently get this:
> On Linux:
> $ gcc -print-multi-os-directory
> .
> $ gcc -print-multi-os-directory -m32
> ../../lib32

> And on Solaris:
> $ gcc -print-multi-os-directory
> .
> $ gcc -print-multi-os-directory -m64
> sparcv9

There are certain implementation difficulties with this proposal.  The
multi-os-directory printed by gcc is always a *relative* path with respect
to the "base" lib directory; and in a multiarch directory, this base lib
directory *is* the multiarch directory (for the primary toolchain target). 
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!

It could be done instead with absolute paths, but that's still a semantic
change for gcc and consumers of this may not be expecting the change.

> For example of packages that have been using gcc's -print-multi-os-directory 
> since quite some time are:
> - ltdl (libtool.m4): to find the runtime search path of the linker

Heh, that's not at all a correct method of querying the runtime search path
of the linker.

> If gcc was patched to output the correct multiarch directory then no
> upstream changes would be required for these packages.

A number of upstream changes would still be required in order for these
packages to *use* the gcc -print-multi-os-directory output.

-- 
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/20110627142023.ge31...@virgil.dodds.net

Re: Multiarch in Debian unstable

[Steve Langasek]

On Mon, Jun 27, 2011 at 03:31:24PM +0200, Vincent Lefevre wrote:
> On 2011-06-27 11:54:53 +0100, Steve Langasek wrote:
> > Work is ongoing to formulate a proper, distribution-neutral interface for
> > querying the correct multiarch path for a system.  In the meantime, if you
> > are an upstream affected by this issue, or a maintainer of a package whose
> > upstream is affected, you are welcome to join us in discussing these matters
> > on debian-devel as well.

> > A summary of currently known upstream compatibility issues, and the status
> > of prospective patches for them, can also be found in the Debian wiki here:

> >   http://wiki.debian.org/Multiarch/TheCaseForMultiarch#Impact

> Just a comment...

> How libraries are searched is not clear, but depending on how this
> is done, there may be compatibility issues when the user installs
> software in his home directory, in case he or some tool installs
> libraries in $prefix/lib instead of $prefix/lib/.

> For instance, if all the default .../lib/ directories have
> the precedence over the .../lib directories listed in the user's
> $LIBRARY_PATH, bad things can happen. This is the choice followed
> by upstream GCC (lib64 directories have the precedence over the
> user's lib directories), with the following consequence:

>   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.  A user
could do this locally, but there's no good reason to ever do so.

As a practical matter, the runtime path will list all of the multiarch paths
before all of the non-multiarch paths.  (It does this already today.)  If
nothing else, we do need to list out these directories in /etc/ld.so.conf.d
(because other things parse these files), and it's impractical to have a
different config file for each of the multiarch paths for each architecture.

> Related to that, will Linux support fat binaries[*] one day?

I don't agree that this is related. :)

-- 
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/20110627144246.gf31...@virgil.dodds.net

Re: Multiarch in Debian unstable

[Simon McVittie]

On Mon, 27 Jun 2011 at 15:31:24 +0200, Vincent Lefevre wrote:
> Related to that, will Linux support fat binaries[*] one day?

I doubt it; but multiarch doesn't make them any more problematic.

> If this is possible, where should they be installed, and how
> libraries would be searched in a consistent way to support
> various kinds of libraries?

If by "fat binaries" you mean executables, they'd go in ${prefix}/bin just
like normal executables do (under multi-arch or not), and the runtime
linker would have to search the appropriate linker path for whichever
architecture's part of the binary was actually being executed.

(Concrete example: I install an i386/x86-64/armel fat binary on my x86-64.
My kernel can natively execute i386 and x86-64, and it chooses to execute
the x86-64 version. The runtime linker should look in
/usr/local/lib/x86_64-linux-gnu, /usr/local/lib, and so on, in some order,
ignoring any non-x86-64 libraries it finds - but the runtime linker already
knows how to ignore unsuitable libraries, so that's easy.)

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). But there's no real advantage in doing that, you could
just as easily install several "thin" libraries.

S


-- 
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/20110627145927.ga25...@reptile.pseudorandom.co.uk

Re: pam_listfile / pam_supair

[Stanisław Findeisen]

On 2011-06-01 20:24, Steve Langasek wrote:
> On Wed, Jun 01, 2011 at 12:43:46PM +0200, Stanisław Findeisen wrote:
> 
>> It looks that pam_listfile only allows to restrict *source* user set and
>> *not* *target* user set.
> 
> That's not true at all.  item=user *is* the target user set.  (Source user
> set would be the seldom-used item=ruser.)
> 
>> Here's the debian-user discussion:
>> http://lists.debian.org/debian-user/2011/05/msg02054.html
> 
>> Is there any way to do what I want?
> 
> As already suggested, sudo does seem to be a better fit for what you're
> trying to achieve.
> 
> pam_listfile isn't going to give you any reasonable mapping for applicant /
> target user *pairs*; you only get "this list of users are allowed access to
> this other list of users".
> 
>> If I write a patch for pam_listfile, will you accept it to Debian?
> 
> No.  It would have to go upstream first; but I'll say that such a patch is
> unlikely to be accepted.
> 
>> Where is the source code?
> 
> I think that's more of a question for debian-user anyway, but:
> 
> $ dpkg -S /lib/security/pam_listfile.so
> libpam-modules: /lib/security/pam_listfile.so
> $ debcheckout libpam-modules
> declared bzr repository at 
> nosmart+http://bzr.debian.org/bzr/pkg-pam/debian/sid/
> bzr branch nosmart+http://bzr.debian.org/bzr/pkg-pam/debian/sid/ 
> libpam-modules ...
> [...]
> 
>> Or maybe that should be a new PAM module?
> 
> It could be.  But I'm skeptical that such a module would be of widespread
> interest.

In case anyone has free time, could you please have a look at my module,
spot bugs or issue any valuable comments? :-)

Here's how to use it:

In /etc/pam.d/su :

auth   sufficient   pam_supair.so sf,u2,u3:root,sf2 sf2:u2

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.

Your comments are very welcome.

MD5:
a9f363539105e5cf7424dd1f68a18880  pam_supair.tgz

SHA-512:
8cd49f56567d490e7cedaa847d05d4e2e72dfc34740ff61c324e409a4487f35013440568079e3fda340fbae2dd85a964fae7924bdc7e5338e528677f65d85615
 pam_supair.tgz

-- 
Eisenbits - proven software solutions: http://www.eisenbits.com/
OpenPGP: E3D9 C030 88F5 D254 434C  6683 17DD 22A0 8A3B 5CC0


pam_supair.tgz
Description: application/compressed-tar


signature.asc
Description: OpenPGP digital signature

Re: Multiarch in Debian unstable

[Bernhard R. Link]

* Steve Langasek  [110627 13:00]:
>   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.

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?

> Multiarch is a significant departure from the historical directory layout,

It is not really new, it was common in commercial unices. A pity one can
no longer make fun of them.

> A number of upstream build
> systems rely on being able to locate libraries and headers on the filesystem
> at build time, not just using the system compiler's built-in search path.

Please feel free to relay them my "I told you so". Thinking your build
system would know where the files are and that duplicating the code the
preprocessor and linker already have, has been a bad idea in the past
and is still a bad idea now.

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

Re: Multiarch in Debian unstable

[Ben Hutchings]

On Mon, Jun 27, 2011 at 03:19:53PM +0200, Adam Borowski wrote:
[...]
> Before the conversion of amd64 -m32 to i386, and sparc -m64 to sparc64, it
> could keep using biarch paths for the time being but provide the correct
> multiarch one when no -m is specified.
> 
> Otherwise, it produces oh so useful:
> (amd64)$ arm-linux-gnueabi-gcc -print-multi-os-directory

Indeed, I saw a complaint from David Miller that building gcc from
upstream source fails at present (on sparc, I assume).

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
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/20110627163703.gz29...@decadent.org.uk

Re: pam_listfile / pam_supair

[Bastian Blank]

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

-- 
A Vulcan can no sooner be disloyal than he can exist without breathing.
-- Kirk, "The Menagerie", stardate 3012.4


-- 
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/20110627164227.gb23...@wavehammer.waldi.eu.org

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

[Geoff Levand]

Hi,

On 06/26/2011 02:35 PM, Ben Hutchings wrote:
> 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.

>From what I understand of otherOS++, a kernel update to the PS3 code for
hot plug memory and initrd is needed.  Existing powerpc binaries won't
work.

I think the changes needed are just a generalization of the existing
code.  Is so, they should be sent to the Linuxppc-dev mailing list.

-Geoff


-- 
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/4e08b7c8.4080...@am.sony.com

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

[Ben Hutchings]

On Mon, Jun 27, 2011 at 10:03:04AM -0700, Geoff Levand wrote:
> Hi,
> 
> On 06/26/2011 02:35 PM, Ben Hutchings wrote:
> > 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.
> 
> From what I understand of otherOS++, a kernel update to the PS3 code for
> hot plug memory and initrd is needed.  Existing powerpc binaries won't
> work.

The existing *userland* binaries will work, won't they?

If a special kernel configuration is needed, we would add that as a
'flavour' of the kernel, not a separate architecture.

> I think the changes needed are just a generalization of the existing
> code.  Is so, they should be sent to the Linuxppc-dev mailing list.
 
Right.  The Debian kernel team generally does not like to carry
patches forward indefinitely.  They should normally be accepted
upstream before we apply them.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
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/20110627180433.ga29...@decadent.org.uk

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

[Geoff Levand]

Hi Ben,

On 06/27/2011 11:04 AM, Ben Hutchings wrote:
> On Mon, Jun 27, 2011 at 10:03:04AM -0700, Geoff Levand wrote:
> 
>> From what I understand of otherOS++, a kernel update to the PS3 code for
>> hot plug memory and initrd is needed.  Existing powerpc binaries won't
>> work.
> 
> The existing *userland* binaries will work, won't they?

Yes, userland binaries will work.  I meant the existing
powerpc kernel binaries that work on old PS3 firmware
won't work for this gitbrew otherOS++ thing.

-Geoff


-- 
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/4e08cd09.9040...@am.sony.com

Multi-Arch .udeb ?

[Keith Packard]

On Mon, 27 Jun 2011 11:54:53 +0100, Steve Langasek  wrote:
Non-text part: multipart/signed

> It is with excitement and trepidation that I write to you today about the
> status of multiarch support in Debian.

Thanks for the update. I'm afraid I haven't been paying close attention,
but a cursory search didn't uncover any description of what I'm supposed
to do with a .udeb that includes a shared library in our glorious
Multi-Arch world of the future.

I'm assuming that any files destined for /usr/lib should land in the
architecture-specific sub-directory, right?

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


pgpOMljwYtiXe.pgp
Description: PGP signature

Link Exchance Request-Travel-3way

[vincent]

Hi,
 
As an ongoing process to increase the link popularity of TRAVEL Website , we 
are looking for some good quality Websites to exchange links  with our website. 
I recently came across your Website through Google Search and found it 
beneficial and informative for our site's visitors. 
 
For our mutual benefit, I would like to do a 3-WAY Link(s) Exchange with your 
website, in return I will post your link at same value page without any delay.

If you find the whole concept interesting, then I request you to send your site 
details to be added with the exact page where you propose to place my link and 
I will give you a link of equal pagerank ASAP. 
 
If you'd like to discuss this further, please feel free to contact us at: 
vinc...@pays-basque-consultants.com
 
Expecting an earlier Reply!
 
Kind Regards,
Links Manager

Bug#631855:

[Fabrizio Regalli]

Package: wnpp
Owner: Fabrizio Regalli 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libinternals-perl
  Version : 1.1
  Upstream Author : Steffen Beyer 
* URL : http://search.cpan.org/dist/Internals/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl module for write-protect variables, manipulate
refcounts

Internals allows you to write-protect and write-enable your Perl
variables,
objects and data structures.

Moreover, the reference count of any Perl variable can be read and set.

You can never pass the object directly on which to perform the desired
action, you always have to pass a reference to the variable or data
structure
in question.

This comes in handy for objects and anonymous data structures, where you
only
have a reference anyway!



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

Bug#631861: ITP: summain -- create file manifests with checksums

[Lars Wirzenius]

Package: wnpp
Severity: wishlist
Owner: Lars Wirzenius 

* Package name: summain
  Version : 0.8
  Upstream Author : Lars Wirzenius 
* URL : http://liw.fi/summain/
http://liw.fi/summain/README/
http://liw.fi/summain/NEWS/
http://liw.fi/summain/summain.1.txt
* License : GPL
  Programming Lang: Python
  Description : create file manifests with checksums

Summain generates file manifests, which contain metadata about the files,
and a checksum of their content for regular files. The manifest can be
generated for a directory tree at different points in time and compared
(with diff) to see if something has changed.



-- 
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/20110627211225.5260.34143.report...@havelock.liw.fi

Bug#631862: ITP: seivot -- benchmark program for backup software

[Lars Wirzenius]

Package: wnpp
Severity: wishlist
Owner: Lars Wirzenius 

* Package name: seivot
  Version : 1.9
  Upstream Author : Lars Wirzenius 
* URL : http://liw.fi/seivot/
* License : GPL
  Programming Lang: Python
  Description : benchmark program for backup software

seivot generates synthetic test data and backs it up using the
desired backup tool. It then modifies the test data, and makes
further backups. It also does restores, verifications, and 
forgets backup generations. It measures the runtime and memory
usage of each run of the backu program.
.
Originally written for Obnam, seivot aims to be useful for 
benchmarking many backup programs.



-- 
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/20110627211927.5353.32610.report...@havelock.liw.fi

Bug#631864: ITP: python-larch -- B-tree library for Python

[Lars Wirzenius]

Package: wnpp
Severity: wishlist
Owner: Lars Wirzenius 

* Package name: python-larch
  Version : 0.19
  Upstream Author : Lars Wirzenius 
* URL : http://liw.fi/larch/
* License : GPL
  Programming Lang: Python
  Description : B-tree library for Python

An implementation of a particular kind of B-tree, based on research
by Ohad Rodeh. This is the same data structure that btrfs uses, but
in a new, pure-Python implementation.
.
The distinctive feature of this B-tree is that a node is never (conceptually)
modified. Instead, all updates are done by copy-on-write. This makes it
easy to clone a tree, and modify only the clone, while other processes
access the original tree.
.
The implementation is generic and flexible, so that you may use it in
a variety of situations. For example, the tree itself does not decide
where its nodes are stored: you provide a class that does that for it.
The library contains two implementations, one for in-memory and one
for on-disk storage.



-- 
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/20110627212650.5504.50781.report...@havelock.liw.fi

Re: Multiarch in Debian unstable

[Steve Langasek]

On Mon, Jun 27, 2011 at 06:31:19PM +0200, Bernhard R. Link wrote:
> * Steve Langasek  [110627 13:00]:
> >   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.

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

-- 
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: Multi-Arch .udeb ?

[Steve Langasek]

Hi Keith,

On Mon, Jun 27, 2011 at 01:02:13PM -0700, Keith Packard wrote:
> On Mon, 27 Jun 2011 11:54:53 +0100, Steve Langasek  wrote:
> Non-text part: multipart/signed

> > It is with excitement and trepidation that I write to you today about the
> > status of multiarch support in Debian.

> Thanks for the update. I'm afraid I haven't been paying close attention,
> but a cursory search didn't uncover any description of what I'm supposed
> to do with a .udeb that includes a shared library in our glorious
> Multi-Arch world of the future.

> I'm assuming that any files destined for /usr/lib should land in the
> architecture-specific sub-directory, right?

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.  While
/usr/lib/$arch is perfectly findable by ld.so in the installer environment,
and while any plugins still need to be installed to the multiarch path if
you're doing a single build of the source for both .deb and .udeb, I think
it just adds unneeded complexity to use /usr/lib/$arch for shared libraries
in udebs.

Since this is the third time this question has come up, I guess that makes
it a FAQ; added now at
. :)

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

-- 
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: Multi-Arch .udeb ?

[Keith Packard]

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

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


pgpXtEWsTI3sy.pgp
Description: PGP signature

Re: Multiarch in Debian unstable

[Adam Borowski]

On Mon, Jun 27, 2011 at 11:54:53AM +0100, Steve Langasek wrote:
> Multiarch handling of header files (/usr/include) will require
> more per-package attention, because architecture-dependent and
> architecture-independent header files are currently mixed together in a
> single directory and we probably don't want to move these all to
> /usr/include/$arch.

If a library does install different headers on different architectures,
wouldn't it be better to put everything for the library in /usr/include/$arch?
This way, packaging is much simpler, there is less place for error, headers
for different architectures are co-installable, and there is less confusion.

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.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


-- 
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/20110627234436.ga15...@angband.pl

Re: Multiarch in Debian unstable

[Vincent Lefevre]

On 2011-06-27 15:42:47 +0100, Steve Langasek wrote:
> On Mon, Jun 27, 2011 at 03:31:24PM +0200, Vincent Lefevre wrote:
> > How libraries are searched is not clear, but depending on how this
> > is done, there may be compatibility issues when the user installs
> > software in his home directory, in case he or some tool installs
> > libraries in $prefix/lib instead of $prefix/lib/.
> 
> > For instance, if all the default .../lib/ directories have
> > the precedence over the .../lib directories listed in the user's
> > $LIBRARY_PATH, bad things can happen. This is the choice followed
> > by upstream GCC (lib64 directories have the precedence over the
> > user's lib directories), with the following consequence:
> 
> >   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).

> 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

and if there's a library installed in /usr/lib/ (by the system)
and a more recent version in $HOME/lib (by some tool that doesn't
support multiarch or... [see below]), then that's the system version
that will be taken instead of the version installed by the user. So,
directories specified by $LIBRARY_PATH no longer necessarily have the
precedence over the default system directories. And the header will be
taken from $HOME/include; thus it will not correspond to the library.

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

> > Related to that, will Linux support fat binaries[*] one day?
> 
> I don't agree that this is related. :)

Installing fat binaries in prefix/lib/ would be meaningless.
So, I'd think they would be installed in prefix/lib, with the problem
mentioned above.

-- 
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/20110628000505.ga17...@prunille.vinc17.org

Bug#631877: ITP: python-numpydoc -- Numpy's Sphinx extensions

[Luis Pedro Coelho]

Package: wnpp
Severity: wishlist
Owner: Luis Pedro Coelho 


* Package name: python-numpydoc
  Version : 0.4
  Upstream Author : Pauli Virtanen and others 
* URL : http://pypi.python.org/pypi/numpydoc/
* License : BSD
  Programming Lang: (Python)
  Description : Numpy's Sphinx extensions

This is necessary to build the documentation of other packages. For an example,
see the discussion at http://comments.gmane.org/gmane.comp.bug-tracking.bugs-
everywhere.devel/685



-- 
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/20110628000911.27206.44389.reportbug@localhost6.localdomain6

Re: Multiarch in Debian unstable

[Vincent Lefevre]

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

-- 
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/20110628003051.gb17...@prunille.vinc17.org

Re: pam_listfile / pam_supair

[Stanisław Findeisen]

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 -' . :-)

-- 
Eisenbits - proven software solutions: http://www.eisenbits.com/
OpenPGP: E3D9 C030 88F5 D254 434C  6683 17DD 22A0 8A3B 5CC0


-- 
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/4e095de4.2020...@eisenbits.com

Re: Multiarch in Debian unstable

[Hendrik Sattler]

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?

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

HS


-- 
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/201106280740.03845.p...@hendrik-sattler.de

Re: Multiarch in Debian unstable

[Steve Langasek]

On Tue, Jun 28, 2011 at 01:44:36AM +0200, Adam Borowski wrote:
> On Mon, Jun 27, 2011 at 11:54:53AM +0100, Steve Langasek wrote:
> > Multiarch handling of header files (/usr/include) will require
> > more per-package attention, because architecture-dependent and
> > architecture-independent header files are currently mixed together in a
> > single directory and we probably don't want to move these all to
> > /usr/include/$arch.

> If a library does install different headers on different architectures,
> wouldn't it be better to put everything for the library in /usr/include/$arch?
> This way, packaging is much simpler, there is less place for error, headers
> for different architectures are co-installable, and there is less confusion.

That is one option, for sure; but even determining that a library's headers
*are* architecture-dependent is a fairly manual process, so this is going to
be much less of an automated process than library handling itself has been.

Also, libc6-dev is affected by this, and I'm not sure we really want to move
~400 libc headers to /usr/include/ when only about 20 of them are
arch-dependent.

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

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