Probable multiarch related problem in finding header file posix_types_32.h

Hi, it seems that multiarch issues do not gather attention on debian-mentors and thus please forgive me to bring this topic here on debian-devel list. In the announcement http://lists.debian.org/debian-devel-announce/2011/06/msg2.html it was stated: "Multiarch handling of header files

Re: Probable multiarch related problem in finding header file posix_types_32.h

Andreas Tille writes: > Because neither Luis Ibanez nor me (as his mentor in the MoM project[1]) > can make some sense out of this hint we would like to ask for more > precise advise what to do or what to read to get a clue about this. > I'm quoting a short extract from Luis's mail to debian-men

Bug#659863: ITP: vegan -- Community Ecology Package for R

Package: wnpp Severity: wishlist Owner: Charles Plessy Package name: vegan Version : 2.0-2 Upstream Author : Jari Oksanen, F. Guillaume Blanchet, Roeland Kindt, Pierre Legendre, Peter R. Minchin, R. B. O'Hara, Gavin L. Simpson, Peter Solymos, M. Henry H. Stevens, Helene Wagner

Re: Multiarch file overlap summary and proposal

On 2012-02-14 07:43, Russ Allbery wrote: > 4. Lintian overrides. I believe these should be qualified with the >architecture on any multiarch: same package so that the overrides can >vary by architecture, since this is a semi-frequent use case for >Lintian. > * Lintian should recogniz

Re: Multiarch file overlap summary and proposal

On 2012-02-14 07:43, Russ Allbery wrote: > [...] > > * Lintian should recognize arch-qualified override files, and multiarch: > same packages must arch-qualify their override files. debhelper > assistance is desired for this. > > [...] I have no problem with Lintian accepting arch-qualified

Re: Multi-arch all-architecture plugins

* Peter Samuelson [120214 06:32]: > Package: libpam-fprint > Multi-Arch: same-as libpam0g > > Package: gimp-texturize > Multi-Arch: same-as libgimp2.0 > > Package: libsasl2-modules > Multi-Arch: same-as libsasl2-2 Would this also work with nss plugins? That might be a bit more complicated as it w

Re: [DEP9] call for testing of reconf-inetd (update-inetd replacement)

Serafeim Zanikolas writes ("Re: [DEP9] call for testing of reconf-inetd (update-inetd replacement)"): > Any local sysadmin changes must be done in inetd.conf, as always. > > The choice of /usr/share/ follows from two of the requirements I > have set from the beginning for DEP9 [0]: > > - the sta

Re: severity for bugs in ignoring TMP/TMPDIR?

Ben Hutchings writes ("Re: severity for bugs in ignoring TMP/TMPDIR?"): > A similar change has been implemented > > and will probably be included in wheezy. Interesting. That approach protects the buggy programs, b

Re: Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)

On Tue, 14 Feb 2012, Philipp Kern wrote: > On 2012-02-14, Raphael Hertzog wrote: > > Somehow my suggestion is then to extend dpkg-parsechangelog to provide > > the required logic to split the changelog in its bin-nmu part and its > > usual content. > > > > dpkg-parsechangelog --split-binnmu > >

Re: Summary: dpkg shared / reference counted files and version match

On Sat, 2012-02-11 at 03:28:33 +0200, Riku Voipio wrote: > * Because shared files packaging simpler for maintainers. > > Package profiliation and duplication of arch-independent data are merely > effecty that happen when packagers workaround the lack of shared identical > files. That way of thin

Re: Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)

On Mon, 2012-02-13 at 22:43:04 -0800, Russ Allbery wrote: > If this is comprehensive, then I propose the following path forward, which > is a mix of the various solutions that have been discussed: > * dpkg re-adds the refcounting implementation for multiarch, but along > with a Policy requiremen

Re: Call for projects and mentors for Google Summer of Code 2012

Hello Ana, Can you drop me from the soc-coordination list admin/moderator list? I cannot find the list admin password anymore. I've been rather passive the last years with respect to GSoC. Mostly helping a bit with voting and reviewing the applications. I'll probably help with that again, but since

Re: Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)

Russ Allbery writes ("Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)"): > There's been a lot of discussion of this, but it seems to have been fairly > inconclusive. We need to decide what we're doing, if anything, for wheezy > f

Re: Multi-arch all-architecture plugins

Aron Xu : > On Tue, Feb 14, 2012 at 00:09, Ian Jackson > wrote: > > Goswin von Brederlow writes ("Re: Multi-arch all-architecture plugins"): > >> As you said these are usualy plugins that nothing depends on. So this > >> wouldn't help much. Also if there is a dependency than the rules for > >> m-a

Re: Multi-arch all-architecture plugins

Peter Samuelson writes ("Re: Multi-arch all-architecture plugins"): > [Ian Jackson] > > Where should this fact be declared ? Is it a property of a package > > that it makes sense to install it only on all configured architectures > > or none ? Or is it a property of the dependency from the depend

Re: Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)

Le lundi 13 février 2012 à 22:43 -0800, Russ Allbery a écrit : > There's been a lot of discussion of this, but it seems to have been fairly > inconclusive. We need to decide what we're doing, if anything, for wheezy > fairly soon, so I think we need to try to drive this discussion to some > concr

Re: Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)

* Raphael Hertzog , 2012-02-14, 14:17: dpkg-buildpackage --binary-version --binary-changelog 'foo' could create debian/changelog.build with the given changelog version and changelog entry. dpkg-parsechangelog could be taught to read debian/changelog.build before debian/changelog so that dpkg

Re: Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)

Guillem Jover writes ("Re: Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)"): > On Mon, 2012-02-13 at 22:43:04 -0800, Russ Allbery wrote: > > * The binNMU process is changed to add the binNMU changelog entry to an > > arch-quali

Re: Multi-arch all-architecture plugins

On Tue, Feb 14, 2012 at 22:10, Ian Jackson wrote: > Aron Xu : >> On Tue, Feb 14, 2012 at 00:09, Ian Jackson >> wrote: >> > Goswin von Brederlow writes ("Re: Multi-arch all-architecture plugins"): >> >> As you said these are usualy plugins that nothing depends on. So this >> >> wouldn't help much.

Re: Multiarch file overlap summary and proposal

On 2012-02-14 15:28 +0100, Ian Jackson wrote: > Guillem Jover writes: > >> This still does not solve the other issues I listed, namely binNMUs >> have to be performed in lock-step, more complicated transitions / >> upgrades. > > I don't think I see where this is coming from. Are you talking about

Re: Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)

Hi, On Tue, 14 Feb 2012, Guillem Jover wrote: > > * All packages that want to be multiarch: same have to move all generated > > documentation into a separate package unless the maintainer has very > > carefully checked that the generated documentation will be byte-for-byte > > identical even

Re: Multiarch file overlap summary and proposal

Hi, On Tue, 14 Feb 2012, Sven Joachim wrote: > > Guillem Jover writes: > > > >> This still does not solve the other issues I listed, namely binNMUs > >> have to be performed in lock-step, more complicated transitions / > >> upgrades. > > > > I don't think I see where this is coming from. Are you

Re: Multiarch file overlap summary and proposal

* Russ Allbery [120214 01:48]: > If this is comprehensive, then I propose the following path forward, which > is a mix of the various solutions that have been discussed: I thought Goswin's suggestion in [1] of having dpkg use implicit diversions has merit and deserves further scrutiny. It essent

Re: Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)

On Tue, 14 Feb 2012, Jakub Wilk wrote: > Are we sure than no existing package uses debian/changelog.build for > their own purposes? No, but with debian/changelog.dpkg-build we should be safe. > Are we sure that all existing packages (and helpers) that parse > debian/changelog use dpkg-parsechange

Re: Multiarch file overlap summary and proposal

On Tue, 14 Feb 2012, Marvin Renich wrote: > I thought Goswin's suggestion in [1] of having dpkg use implicit > diversions has merit and deserves further scrutiny. I don't. diversions support 2 packages, the "diverted" one and the "diverting" one. Multi-Arch: same must support co-installation of an

Re: Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)

On Tue, 2012-02-14 at 14:28:58 +, Ian Jackson wrote: > Guillem Jover writes ("Re: Multiarch file overlap summary and proposal (was: > Summary: dpkg shared / reference counted files and version match)"): > > On Mon, 2012-02-13 at 22:43:04 -0800, Russ Allbery wrote: > > > * The binNMU process is

Bug#659902: ITP: django-floppyforms -- better control of form rendering in Django

Package: wnpp Severity: wishlist Owner: Michael Fladischer -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: django-floppyforms Version : 0.4.7 Upstream Author : Bruno Renié * URL : https://github.com/brutasse/django-floppyforms * License : BSD

Re: Probable multiarch related problem in finding header file posix_types_32.h

On Tue, Feb 14, 2012 at 12:34:41AM -0800, Russ Allbery wrote: > > and goes on an on, repeating the error about posix_types_32.h. > > --- > > It would help if you could confirm that this is actually an issue caused > > by multiarch mi

Re: Probable multiarch related problem in finding header file posix_types_32.h

On Tue, Feb 14, 2012 at 09:29:30AM -0800, Steve Langasek wrote: > On Tue, Feb 14, 2012 at 12:34:41AM -0800, Russ Allbery wrote: > > > and goes on an on, repeating the error about posix_types_32.h. > > > --- > > > > It would help if y

Re: -fPIE and stuff

On Mon, Feb 13, 2012 at 10:29:23PM +, Uoti Urpala wrote: > Kurt Roeckx roeckx.be> writes: > > So my understanding is that you want to build libraries with -fPIE > > instead of -fPIC, and that that creates a different ABI? > > What affects the ABI is compiling the library in a way that does no

Re: Multiarch file overlap summary and proposal

Niels Thykier writes: > On 2012-02-14 07:43, Russ Allbery wrote: >> [...] >> >> * Lintian should recognize arch-qualified override files, and multiarch: >> same packages must arch-qualify their override files. debhelper >> assistance is desired for this. >> >> [...] > I have no problem wit

Re: Bug#659863: ITP: vegan -- Community Ecology Package for R

On Tue, 14 Feb 2012, Charles Plessy wrote: > Package name: vegan New R packages shouldn't be added with a source name that does not match the single binary package that they produce. Please consider using r-cran-vegan for both the source and binary package names. Don Armstrong -- N: Why

Bug#659908: ITP: jenkins-parametrized-trigger-plugin -- Triggers new Jenkins builds when a build has completed

Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: jenkins-parametrized-trigger-plugin Version: 2.13 Upstream Author: Kohsuke Kawaguchi and others License: MIT Description: Triggers new Jenki

Re: -fPIE and stuff

Kurt Roeckx roeckx.be> writes: > > What affects the ABI is compiling the library in a way that does not support > > copy relocations. This can be done with visibility attributes or linker > It was always my understanding that protected wasn't useful, > because it's even more expensive. Sounds li

Re: Probable multiarch related problem in finding header file posix_types_32.h

Hi Ben, On Tue, Feb 14, 2012 at 06:19:40PM +, Ben Hutchings wrote: > > Where we've run across similar problems with posix_types.h in the recent > > past, it has indeed been due to the use of "gcc -I-". > Wow, that is a really insane option. However it is documented as > deprecated. Right.

Re: Multi-arch all-architecture plugins

[Ian Jackson] > If you install on i386 your 2 binaries and libc6, you /do/ need the > i386 libfakeroot. Otherwise if you say "fakeroot " it > won't work, no matter that /usr/bin/fakeroot is amd64. libfakeroot is something of a special case, indeed. As a hack to my proposal, perhaps it can be 'M

Re: Probable multiarch related problem in finding header file posix_types_32.h

On Tue, Feb 14, 2012 at 12:32:16PM -0800, Steve Langasek wrote: > Hi Ben, > > On Tue, Feb 14, 2012 at 06:19:40PM +, Ben Hutchings wrote: > > > > Where we've run across similar problems with posix_types.h in the recent > > > past, it has indeed been due to the use of "gcc -I-". > > > Wow, tha

Re: -fPIE and stuff

On Tue, Feb 14, 2012 at 08:17:09PM +, Uoti Urpala wrote: > Kurt Roeckx roeckx.be> writes: > > > What affects the ABI is compiling the library in a way that does not > > > support > > > copy relocations. This can be done with visibility attributes or linker > > > It was always my understandin

Re: -fPIE and stuff

On 2012-02-14, Kurt Roeckx wrote: Hi Application Manager :) (My response here includes some questions from my upstream who I showed this mail) > It was always my understanding that protected wasn't useful, > because it's even more expensive. Can you come with a bit pointers or numbers about 'e

Re: Bug#659863: ITP: vegan -- Community Ecology Package for R

Le Tue, Feb 14, 2012 at 10:35:57AM -0800, Don Armstrong a écrit : > On Tue, 14 Feb 2012, Charles Plessy wrote: > > Package name: vegan > > New R packages shouldn't be added with a source name that does not > match the single binary package that they produce. Please consider > using r-cran-ve

Re: -fPIE and stuff

Kurt Roeckx roeckx.be> writes: > On Tue, Feb 14, 2012 at 08:17:09PM +, Uoti Urpala wrote: > > Kurt Roeckx roeckx.be> writes: > > > It was always my understanding that protected wasn't useful, > > > because it's even more expensive. > > > > Sounds like your understanding was wrong. Protected

Re: Bug#659863: ITP: vegan -- Community Ecology Package for R

On Wed, 15 Feb 2012, Charles Plessy wrote: > Le Tue, Feb 14, 2012 at 10:35:57AM -0800, Don Armstrong a écrit : > > On Tue, 14 Feb 2012, Charles Plessy wrote: > > > Package name: vegan > > > > New R packages shouldn't be added with a source name that does not > > match the single binary packa

Re: Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)

On Tue, 2012-02-14 at 14:28:58 +, Ian Jackson wrote: > I think the refcounting approach is very worthwhile because it > eliminates unnecessary work (by human maintainers) in many simple > cases. Aside from what I said on my other reply, I just wanted to note that this seems to be a recurring p

Source package names for R libraries (and Perl, Python, Java, …).

Le Tue, Feb 14, 2012 at 04:23:40PM -0800, Don Armstrong a écrit : > > http://lists.debian.org/debian-perl/2008/08/msg00055.html > http://lists.debian.org/debian-policy/2008/01/msg00019.html > #505309 > > among others. For sure there are discussions, but what we need is a summarized conclusion. (

Re: Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)

Guillem Jover wrote: > Aside from what I said on my other reply, I just wanted to note that > this seems to be a recurring point of tension in the project when it > comes to archive wide source package changes, where supposed short > term convenience (with its usually long term harmful effects) app

Re: Multiarch file overlap summary and proposal

Joey Hess writes: > Anyway, my worry about the refcounting approach (or perhaps M-A: same in > general) is not the details of the implementation in dpkg, but the added > mental complexity of dpkg now being able to have multiple distinct > packages installed under the same name. I had a brief expo

Re: How to tell users that ia32-libs will go away

Ben Hutchings writes: > On Mon, Feb 13, 2012 at 04:30:47PM +0100, Goswin von Brederlow wrote: >> Ben Hutchings writes: >> >> > On Sat, 2012-02-11 at 17:33 +0100, Goswin von Brederlow wrote: >> >> Bastian Blank writes: >> >> >> >> > On Fri, Feb 10, 2012 at 01:00:50PM +0100, Bernhard R. Link wr

Re: Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)

On Tue, 14 Feb 2012, Guillem Jover wrote: > I've never proposed to arch-qualify the filename for the stuff under > /usr/share/doc/pkgname/, I've proposed to arch-qualify the pkgname in > the path (/usr/share/doc/pkgname:arch/), but only for M-A:same packages, > which are the only ones needing the d