[PATCH] resolvconf - Add option PREFER_IPV6

[Pali Rohár]

Forwarding email to debian-devel

-- 
Pali Rohár
pali.ro...@gmail.com
--- Begin Message ---
Hello,

I created small patch which adding new env option PREFER_IPV6.
When is set to YES then libc resolvconf updater will add ipv6
nameservers before ipv4 in /etc/resolv.conf. This is usefull if
you want to prefer using nameservers via ipv6 protocol.

Patch was generated against ubuntu resolvconf version 1.67ubuntu2.

--- etc/resolvconf/update.d/libc.orig   2013-04-02 15:27:34.017686814 +0200
+++ etc/resolvconf/update.d/libc2013-04-02 15:37:55.121668638 +0200
@@ -87,6 +87,21 @@ uniquify()
done
 }
 
+ipv6_nameserver_list()
+{
+   while [ "$1" ] ; do
+   case "$1" in (*:*) : ;; (*) shift ; continue ;; esac
+   for E in $NMSRVRS ; do
+   [ "$1" = "$E" ] && { shift ; continue 2 ; }
+   done
+   NMSRVRS="${NMSRVRS:+$NMSRVRS }$1"
+   case "$TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS" in 
(y|Y|yes|YES|Yes) case "$1" in (127.*|::1) return 0 ;; 
esac ;; esac
+   N=$(($N + 1))
+   [ "$N" = 3 ] && return 0
+   shift
+   done
+}
+
 # Args are candidate items not containing spaces
 # Returns NSMSRVS -- space-separate list of no more than 3 items,
 #without duplicates,
@@ -95,6 +110,7 @@ uniquify_nameserver_list()
 {
NMSRVRS=""
N=0
+   case "$PREFER_IPV6" in (y|Y|yes|YES|Yes) ipv6_nameserver_list "$@" ;; 
esac
while [ "$1" ] ; do
for E in $NMSRVRS ; do
[ "$1" = "$E" ] && { shift ; continue 2 ; }


-- 
Pali Rohár
pali.ro...@gmail.com


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


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

Bug#705537: ITP: metastudent -- predictor of Gene Ontology terms from protein sequence

[Laszlo Kajan]

Package: wnpp
Severity: wishlist
Owner: Laszlo Kajan 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: metastudent
  Version : 1.0.7
  Upstream Author : Tobias Hamp 
* URL : https://rostlab.org/owiki/index.php/Metastudent
* License : GPL-2+
  Programming Lang: Perl, Python, Java
  Description : predictor of Gene Ontology terms from protein sequence

 Often, only the sequence of a protein is known, but 
 not its functions. Metastudent will try to predict 
 missing functional annotations through homology searches (BLAST).
 .
 All predicted functions correspond to Gene Ontology (GO) 
 terms from the Molecular Function Ontology (MFO) and the Biological Process
 Ontology (BPO) and are associated with a reliability score.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJRbS5vAAoJEJvS1kCaDFL6koQP/13ADRhPTdJcqzBqIAb/sxks
JuhwNADTLTcdv/hBeEDJJTei8psFIb+RjJykwV9tWJ8FoBVClQIwxyeTiMahuUfU
XnazexpOZEZtaYNNBUm4fZKUVCCYr8nAcaQztfy36UksM4Bjj+NregI4o8GuR/nE
27D0D6ZKXdZaR5r9//J0ZFKp/cqqGIXxc6PeSgDLOtt/DNmRD24+o/hXllnzH+hv
6R3o0atf4s6WDa7VdGV9XrZBgyyNYEvJYp8xn5rt3JtUgyTuq0tZxjuCAvjeWnnJ
LHsV+Qj5ItxS3p5y5rOomfTM0Y2WskFsdrdCwbTw75UjhboyKSUQMGSd5Hg5ecee
0hc3Qpg7GmX3zvZ7Ha1DrMxWtRCE4q0D/Ma6HOPdWlcxA/IcUHHj5MmUKmk0B0v/
oc7ADpP+WCXxuWEDmiiaajXWrdv/J3msUdUGMZJg7FvNLiHOUv6Rhec6cIZkINoW
a8zcTCr92j5IPJ8dgglLgeYn/njQpkQ65j4so+T55qidjLlL+iNr51GPni30jPmu
Qm9WrzEyvkghKFpylXWS2nMvvr8jxRe5VWJ5beYwwL/UeGsQ4iBKjTF2gA47d0RL
kq9pbAn3OahmCuPHyBf/+NQUrkfEoBtXoe7PZOf2sNBxfzXVWf9v4iewZ6hI21sk
UUXjuyw0y7tRvhZeJmeG
=3RgD
-END PGP SIGNATURE-


-- 
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/20130416105652.3386.7449.reportbug@debian-unstable.rostclust

Add multiarch library paths to DEFAULT_LIBRARY_PATH in Dpkg::Shlibs?

[Игорь Пашев]

Hi, all.

Now, /usr/share/perl5/Dpkg/Shlibs.pm defines default library search path as:
use constant DEFAULT_LIBRARY_PATH =>
qw(/lib /usr/lib /lib32 /usr/lib32 /lib64 /usr/lib64
   /emul/ia32-linux/lib /emul/ia32-linux/usr/lib);

and adds multiarch dirs only for crosscompiling:

if ($crossprefix) {
push @crosslibrarypaths, "/lib/$multiarch", "/usr/lib/$multiarch",
"/$crossprefix/lib", "/usr/$crossprefix/lib",
"/$crossprefix/lib32", "/usr/$crossprefix/lib32",
"/$crossprefix/lib64", "/usr/$crossprefix/lib64";
}

Multiarch dirs are added below by parsing /etc/ld.so.conf:
parse_ldso_conf("/etc/ld.so.conf") if -e "/etc/ld.so.conf";

I think it would be better to add multiarch dirs to DEFAULT_LIBRARY_PATH,
and put them in first positions.


-- 
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/call-q8wzrdbs2xuajbn+zh8_bwmpmtfqe+tgzo1muicpxr0...@mail.gmail.com

Re: Add multiarch library paths to DEFAULT_LIBRARY_PATH in Dpkg::Shlibs?

[Paul Wise]

On Tue, Apr 16, 2013 at 7:34 PM, Игорь Пашев wrote:

> Now, /usr/share/perl5/Dpkg/Shlibs.pm defines default library search path as:

Sounds like a topic for the debian-dpkg list?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Add multiarch library paths to DEFAULT_LIBRARY_PATH in Dpkg::Shlibs?

[Игорь Пашев]

2013/4/16 Paul Wise :
> On Tue, Apr 16, 2013 at 7:34 PM, Игорь Пашев wrote:
>
>> Now, /usr/share/perl5/Dpkg/Shlibs.pm defines default library search path as:
>
> Sounds like a topic for the debian-dpkg list?

No.


--
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/CALL-Q8xjWfE7_F0O�QEess_f-opFBEupW+zSR=ptekurk...@mail.gmail.com

Re: Add multiarch library paths to DEFAULT_LIBRARY_PATH in Dpkg::Shlibs?

[Neil Williams]

On Tue, 16 Apr 2013 15:34:40 +0400
Игорь Пашев  wrote:

> Now, /usr/share/perl5/Dpkg/Shlibs.pm defines default library search path as:
> use constant DEFAULT_LIBRARY_PATH =>
> qw(/lib /usr/lib /lib32 /usr/lib32 /lib64 /usr/lib64
>/emul/ia32-linux/lib /emul/ia32-linux/usr/lib);
> 
> and adds multiarch dirs only for crosscompiling:
> 
> if ($crossprefix) {
> push @crosslibrarypaths, "/lib/$multiarch", "/usr/lib/$multiarch",
> "/$crossprefix/lib", "/usr/$crossprefix/lib",
> "/$crossprefix/lib32", "/usr/$crossprefix/lib32",
> "/$crossprefix/lib64", "/usr/$crossprefix/lib64";
> }

i.e. when cross-compiling, the foreign architecture object files need
to be linked against the shared libraries of the same architecture.
Dpkg::Shlibs is used in package building, not at runtime.

The value of $multiarch depends on the architecture being built.
($crossprefix is the old dpkg-cross style path)

> I think it would be better to add multiarch dirs to DEFAULT_LIBRARY_PATH,
> and put them in first positions.

Why?

AFAICT, the only time ordering is going to matter is if libfoo1 is not
multiarch and libfoo2 is multiarch, both are installed for the current
dpkg build architecture and you are building something which compiles
against both versions. That's a false premise because, currently, the
-dev side of MultiArch isn't complete and even if foo builds
libfoo2-dev and libfoo1-dev still exists, libfoo1-dev and libfoo2-dev
will not be co-installable. So the actual .so symlink will be for
whichever one gets installed. The mere fact that one version is
multiarch and one is not is incidental to this "problem".

When calculating the shlibs of a package during the build, the libfoo
part of the dependency is not relevant, it is the libfoo?-dev package
which determines which .so symlink gets used and therefore which libfoo
gets linked.

This is a topic for the debian-dpkg list, please follow up there.

-- 


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



pgpznvBf8u8Yj.pgp
Description: PGP signature

Re: Add multiarch library paths to DEFAULT_LIBRARY_PATH in Dpkg::Shlibs?

[Raphael Hertzog]

On Tue, 16 Apr 2013, Игорь Пашев wrote:
> I think it would be better to add multiarch dirs to DEFAULT_LIBRARY_PATH,
> and put them in first positions.

Why?

This modules tries to mimick ld.so's logic to find libraries as closely
as possible.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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


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

Re: Add multiarch library paths to DEFAULT_LIBRARY_PATH in Dpkg::Shlibs?

[Игорь Пашев]

2013/4/16 Raphael Hertzog :
> On Tue, 16 Apr 2013, Игорь Пашев wrote:
>> I think it would be better to add multiarch dirs to DEFAULT_LIBRARY_PATH,
>> and put them in first positions.
>
> Why?
>
> This modules tries to mimick ld.so's logic to find libraries as closely
> as possible.

/lib:/usr/lib was the default path, now it is
/lib/:/usr/lib/, isn't it?


--
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/call-q8zaupp+sgpramfyg7+ak7jmmu-1h2kf-udo2nx0jy0...@mail.gmail.com

Re: Add multiarch library paths to DEFAULT_LIBRARY_PATH in Dpkg::Shlibs?

[Neil Williams]

On Tue, 16 Apr 2013 16:11:24 +0400
Игорь Пашев  wrote:

> 2013/4/16 Raphael Hertzog :
> > On Tue, 16 Apr 2013, Игорь Пашев wrote:
> >> I think it would be better to add multiarch dirs to DEFAULT_LIBRARY_PATH,
> >> and put them in first positions.
> >
> > Why?
> >
> > This modules tries to mimick ld.so's logic to find libraries as closely
> > as possible.
> 
> /lib:/usr/lib was the default path, now it is
> /lib/:/usr/lib/, isn't it?

No - there's confusion here between the runtime link path and the
build time link path. Dpkg::Shlibs at the point quoted is concerned
with the build time paths. Where to find the stuff which has been
linked against the built binaries for the current architecture of the
current build.

The shared library libfoo.so.1.2.3 lives in /usr/lib/$triplet for
runtime usage but the -dev package which provides the .so symlink which
is used to find the actual .so.N.N.N file is not necessarily in a
MultiArch path. The implementation of MultiArch for -dev packages is
not complete and most -dev packages are not co-installable with a
foreign architecture of the same -dev package. (Any one package build is
only building for a single architecture at any one time, discounting
the issues with CC_FOR_BUILD which needs to be handled differently.
Therefore, building bar for i386 and then armhf means removing some
of the i386 build-deps and installing the armhf build-deps instead.
This typically includes removing libfoo-dev:i386 and installing
libfoo2:armhf & libfoo-dev:armhf. libfoo2:armhf can, of course, stay
installed for later.)

MultiArch in Debian is principally concerned with runtime paths, the
build-time paths and consequent cross-compilation support still has a
few wrinkles to resolve. (or dpkg-cross could have been removed from
Wheezy.)

-- 


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



pgpsZ6izuBA6F.pgp
Description: PGP signature

Re: alternative debian/rules

[Goswin von Brederlow]

On Fri, Apr 05, 2013 at 10:47:39AM -0700, Russ Allbery wrote:
> ?? ??  writes:
> 
> > Indeed.
> 
> > So, in any case one can use its own tool just like dh:
> 
> > %:
> > debian/megatool $@
> 
> Yes, from a Policy perspective.  Although please consider using dh and its
> framework instead to make life easier for everyone else in the project who
> may have to help out with maintaining the package, such as the security
> team.  It has a nice plugin module system that lets you add custom
> infrastructure for particular types of projects without changing the basic
> framework.
> 
> -- 
> Russ Allbery (r...@debian.org)   

% ls -lh debian/rules
lrwxrwxrwx 1 mrvn users  1 Apr 16 12:27 debian/rules -> /usr/bin/dh

MfG
Goswin


-- 
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/20130416122818.GA21076@frosties

Re: Add multiarch library paths to DEFAULT_LIBRARY_PATH in Dpkg::Shlibs?

[Игорь Пашев]

2013/4/16 Neil Williams :
> On Tue, 16 Apr 2013 16:11:24 +0400
>
> No - there's confusion here between the runtime link path and the
> build time link path. Dpkg::Shlibs at the point quoted is concerned
> with the build time paths. Where to find the stuff which has been
> linked against the built binaries for the current architecture of the
> current build.
>
> The shared library libfoo.so.1.2.3 lives in /usr/lib/$triplet for
> runtime usage but the -dev package which provides the .so symlink which
> is used to find the actual .so.N.N.N file is not necessarily in a
> MultiArch path. The implementation of MultiArch for -dev packages is
> not complete and most -dev packages are not co-installable with a
> foreign architecture of the same -dev package. (Any one package build is
> only building for a single architecture at any one time, discounting
> the issues with CC_FOR_BUILD which needs to be handled differently.
> Therefore, building bar for i386 and then armhf means removing some
> of the i386 build-deps and installing the armhf build-deps instead.
> This typically includes removing libfoo-dev:i386 and installing
> libfoo2:armhf & libfoo-dev:armhf. libfoo2:armhf can, of course, stay
> installed for later.)
>
> MultiArch in Debian is principally concerned with runtime paths, the
> build-time paths and consequent cross-compilation support still has a
> few wrinkles to resolve. (or dpkg-cross could have been removed from
> Wheezy.)
>

So, is it important, that multiarch dirs go after crossdirs:
our @librarypaths = (DEFAULT_LIBRARY_PATH, @crosslibrarypaths);
?


-- 
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/CALL-Q8zz=a5bwt1w6rsnrbs7c1munfxsxjazrpghrr+k1y7...@mail.gmail.com

Re: Add multiarch library paths to DEFAULT_LIBRARY_PATH in Dpkg::Shlibs?

[Dmitrijs Ledkovs]

On 16 April 2013 13:29, Neil Williams  wrote:
> On Tue, 16 Apr 2013 16:11:24 +0400
> Игорь Пашев  wrote:
>
>> 2013/4/16 Raphael Hertzog :
>> > On Tue, 16 Apr 2013, Игорь Пашев wrote:
>> >> I think it would be better to add multiarch dirs to DEFAULT_LIBRARY_PATH,
>> >> and put them in first positions.
>> >
>> > Why?
>> >
>> > This modules tries to mimick ld.so's logic to find libraries as closely
>> > as possible.
>>
>> /lib:/usr/lib was the default path, now it is
>> /lib/:/usr/lib/, isn't it?
>
>
> MultiArch in Debian is principally concerned with runtime paths, the
> build-time paths and consequent cross-compilation support still has a
> few wrinkles to resolve. (or dpkg-cross could have been removed from
> Wheezy.)
>

Well, despite policy not settled people started to multi-arch enable
-dev packages in a quite aggressively.
Because well, it's convenient.

I found 140+ dev packages on my system that do so.

http://paste.ubuntu.com/5713071/

And well, since these are multi-arch same and presumably
co-installable, that mean that .so symlink is not in /usr/lib/ any
more for all of them.
So we better figure out the Multi-arch-dev story sooner than later =)

Regards,

Dmitrijs.


--
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/canbhlui9b_pylrugdstjngmunzndx53exgmjotjb4t638...@mail.gmail.com

Re: Add multiarch library paths to DEFAULT_LIBRARY_PATH in Dpkg::Shlibs?

[Wookey]

+++ Neil Williams [2013-04-16 13:29 +0100]:
> On Tue, 16 Apr 2013 16:11:24 +0400
> Игорь Пашев  wrote:

> > /lib:/usr/lib was the default path, now it is
> > /lib/:/usr/lib/, isn't it?
> 
> No - there's confusion here between the runtime link path and the
> build time link path. Dpkg::Shlibs at the point quoted is concerned
> with the build time paths. 

> The implementation of MultiArch for -dev packages is
> not complete and most -dev packages are not co-installable with a
> foreign architecture of the same -dev package.
> 
> MultiArch in Debian is principally concerned with runtime paths, the
> build-time paths and consequent cross-compilation support still has a
> few wrinkles to resolve.

Despite most -dev packages not yet using multiarch paths, some have been,
and more will be (co-installability of -dev packages of multiple
architectures is needed for some builds: libpaper was the first one I
came across, but there will be many more as we move up the stack to
packages with more complex build-deps, such as desktop stuff).

So in general it is a good idea if software checks the multiarch paths
at build time as well as at runtime. And it should check the multiarch
paths before the generic paths as that reduces the risk of getting the
wrong-arch library/file.

The multiarch spec has indeed not been updated to reflect best
practice for -dev package multiarching, but that's not because it's
not a good idea, or will never happen, it's just a combination of
general slackness and the Debian release cycle timing, (which meant we
only targetted the essential runtime multiarch stuff to wheezy).

So in general it seems like a good idea to me for dpkg shlibs to check
multiarch paths at build time if it doesn't already, because it'll
need to soon. I am of course happy to hear of reasons why that will
break things and we should not do it yet. 

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


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

Re: detailed lists with archive contents - more than just Contents

[Goswin von Brederlow]

On Sun, Apr 14, 2013 at 04:48:20PM +0800, Paul Wise wrote:
> On Thu, Feb 21, 2013 at 9:54 PM, Paul Wise wrote:
> 
> > For duplicate file detection, there is now the Debian duplication
> > detector (still importing the archive):
> >
> > http://dedup.debian.net/
> 
> This will soon be linked to from the PTS for packages that share a
> significant amount of data. Here is an example of what to expect:
> 
> http://packages.qa.debian.org/a/a2ps.html

Will that also detect files in multiarch packages that are not identical?
Or files in foo_arch.deb that should be in foo-common_all.deb?

MfG
Goswin


-- 
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/20130416130420.GB21076@frosties

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

[Goswin von Brederlow]

On Sat, Apr 06, 2013 at 01:08:49PM +0900, Charles Plessy wrote:
> Le Sun, Mar 31, 2013 at 07:02:15PM -0400, Scott Kitterman a écrit :
> > 
> > Depends: r-base-core (>= 3.0.0~20130327) , r-base-core (<< 4) 
> > 
> > or you could have an API virtual package:
> > 
> > r-base-api-3.0 
> 
> Hi Dirk and everybody,
> 
> since we already have a substitution variable in most of the R packages
> (R:Depends), I think that we can use it to address the problem.
> 
> First, let's define the problem: R broke backwards compatibility a couple of
> times since it has been packaged.  Rebuilding packages is usually done 
> swiftly,
> but there remains the problem of transitions to Testing and updates on the
> users computers.  There is usually a gap of some years between breakages,
> so we do not want an over-engeneered solution.
> 
> I like the idea of an api virtual package, as it requires little work from the
> parties involved and solves most of the problem.  (The exception being that
> partial upgrades from Wheezy to Jessie will not be supported, but this is also
> the case in the current situation).

In short: That is not an exception but THE intention. It's the whole
point of having an api virtual package.

In long: The R package breaks compatibility in such a way that a
partial upgrade simply won't be functional. You either update them all
or none. Till now installing any package compiles against a newer R
API would pull in the newer r-base-core package to fullfill its
version requirement but would not force old R packages already
installed to also be updated. This leads to procken packages on
partial update. Introducing the api virtual package will enforce that
all R packages will be compiled against the same R API, against a
compatible r-base-core. Installing one package compiled against the
new R will force apt/aptitude to also update all the already installed
R packages, which is what is required.

>  - /usr/share/R/debian/r-cran.mk, which is used in most R packages and 
> produces
>the R:Depends substitution variable, would make packages depend on the 
> r-api
>virtual package instead of requiring a version equal or superior to the 
> version
>of r-base-core used at build time.

It might be enough to only depend on the api or you might need both,
the api virtual package and a versioned depends for a minimum version.
But that depends on the circumstances. Design it so that it is easy to
have both and so that you don't miss updating the minimum version when
required.
 
>  - Next time R breaks backwards compatibility, Dirk would need to modify the
>Provides: line in debian/control and voilà, the new R core package can not
>be installed on a system without removing or upgrading the R library 
> packages
>that were built with the old API.

It might make sense to have a single file "r-api-virtual-version" (or
so) in the source and generate the Provides: field and
/usr/share/R/debian/r-cran.mk from that single source.
 
> Let's discuss the details on #704805
> 
> Have a nice week-end,

MfG
Goswin


-- 
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/20130416131604.GC21076@frosties

Re: Add multiarch library paths to DEFAULT_LIBRARY_PATH in Dpkg::Shlibs?

[Wookey]

+++ Игорь Пашев [2013-04-16 16:49 +0400]:
> 2013/4/16 Neil Williams :
> > On Tue, 16 Apr 2013 16:11:24 +0400
> >
>
> 
> So, is it important, that multiarch dirs go after crossdirs:
> our @librarypaths = (DEFAULT_LIBRARY_PATH, @crosslibrarypaths);
> ?

That's actually a rather problematic question because it's an awkward
transition and we want to break as few things as possible during it. I
believe the correct answer for now is to check multiarch paths,
'crossdirs' paths (if crossbuilding), and 'plain' paths. In that
order. At some point in the future we can drop the 'crossdirs' paths
as they will no longer be used. 

So in multiarch world crossbuilding is not special. You always look in
'multiarch dirs' (for the correct architecture) for the libraries.
Until everything is multiarched you also want to look in the 'plain
dirs' for backwards compatibility.

If you know you are crossbuilding you want to look in the appropriate
dirs where cross libaries are installed. Unfortunately which those are
depends on the mechanism you used to install them. If using
dpkg/multiarch then they will be in the multiarch dirs, so the
situation is as above (the same as native building). If using older
tools (dpkg-cross, xapt, xdeb) then they will be in the 'dpkg-cross
crossdirs' and you need to look in there too. As it will be possible
(but not a good idea) to install both a foreign-arch multiarch -dev
package (into multiarch dirs) and the corresponding foreign-arch
dpkg-crossed package (into dpkg-cross crossdirs) at the same time,
there is no such things as a 'perfect' correct path search order. But
as we are moving away from the old crossdirs paths to the new
multiarch paths, it is reasonable to declare that the multiarch paths
should be treated preferntially, and thus searched first.

This is the 'wrinkles that still needed to be sorted out' for the
multiarch -dev spec. https://wiki.ubuntu.com/MultiarchCross

Updating that doc (and the main multiarch spec) has been on my todo
list for about a year.

I've been thinking that a 'crossbuilding sprint' would be a good idea
for a while, to tie down the recommendations for -dev packages,
in-archive cross-toolchains, multiarch perl and the 'arch-indepedent
dep-stack interruption' problem, and other outstanding issues such as
cross gobject-introspection. We've experimented on most of this in
Ubuntu with armhf and arm64 so (a select few of us) have a reasonable
idea of how it should work, but that knowledge now needs formalising
and documenting, and outstanding questions need some discussion.
Hopefully we can get this sorted by/at debconf. 

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


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

Re: Add multiarch library paths to DEFAULT_LIBRARY_PATH in Dpkg::Shlibs?

[Raphael Hertzog]

On Tue, 16 Apr 2013, Wookey wrote:
> So in general it seems like a good idea to me for dpkg shlibs to check
> multiarch paths at build time if it doesn't already, because it'll
> need to soon. I am of course happy to hear of reasons why that will
> break things and we should not do it yet.

All of this makes no sense to me. The Dpkg::Shlibs module is used by
dpkg-shlibdeps and dpkg-gensymbols.

The former wants to find the library (and not the .so symlink) in order
to identify the binary package and the corresponding symbols/shlibs file
to generate a dependency.

The latter uses the library paths to find potential libraries in
the built binary packages.

Both programs are run at "build-time", but they care about how dynamic
libraries are loaded at run-time in ordre to identify/find the same
libraries that ld.so would find given a NEEDED entry in an executable.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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


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

Re: bits from the DPL: March-April 2013

[Wouter Verhelst]

Hi Zack,

On 16-04-13 16:37, Stefano Zacchiroli wrote:
>   (see John's brief summary [10]) and discuss further technical
[...]
>   workshop of FSFE's European Legal Network [10]; slides are available
[...]
> [10]: http://fsfe.org/activities/ftf/ftf.en.html

You made a minor mistake here; there is no "brief summary" at [10], it
seems to only refer to that european legal network thing.

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



signature.asc
Description: OpenPGP digital signature

Re: bits from the DPL: March-April 2013

[Holger Levsen]

Dear Zack,

/me bows, thanking you for three great years! It's been a real pleasure to see 
you work, you were and are doing an amazing job.

If I wanted to give Lucas an advice here, I think it is to keep your tradition 
of keeping day-to-day activity logs and regular postings of destilled bits 
from those logs. This really made a difference (and should be rather easy to 
copy, cough, though it needs a lot of discipline to keep this going for 3 
years!), "though" it's just one of the many bits were you acted outstandingly.

Oh, well, I should rather keep this short, so:


Thanks again and keep up the fun!
Holger



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

Re: bits from the DPL: March-April 2013

[Stefano Zacchiroli]

On Tue, Apr 16, 2013 at 04:47:34PM +0200, Wouter Verhelst wrote:
> You made a minor mistake here; there is no "brief summary" at [10], it
> seems to only refer to that european legal network thing.

Sorry for the wrong like, the correct one should have been
http://lists.alioth.debian.org/pipermail/fsf-collab-discuss/2013-March/000383.html

FWIW it's fixed in the version of the report that is going to show up on
Planet.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: bits from the DPL: March-April 2013

[Peter Samuelson]

Zack,

Thank you SO MUCH for your service this past 3 years.  Your hard work,
persistence, calm voice and especially your transparency have been much
appreciated.  

Peter


signature.asc
Description: Digital signature

ITP: grub-loopback-iso -- Boot a compatible loopback ISO from GRUB 2

[Ryan Finnie]

retitle 693774 ITP: grub-loopback-iso -- Boot a compatible loopback
 ISO from GRUB 2
kthxbye

(Please excuse the perfect storm of bugs + multiple lists.)

As it turns out, grml invented a generic way of allowing it to be booted
as an ISO from GRUB 2, with a file in the ISO called
/boot/grub/loopback.cfg.  Other distros/utilities, including Super Grub2
Disk and Ubuntu have adopted this, and Finnix will as well, as of the
forthcoming 108 release.

In that light, I have rewritten grub-finnix as grub-loopback-iso, which
is an update-grub2 hook which scans a directory of ISOs an looks for
/boot/grub/loopback.cfg within them, and will build grub.cfg stanzas
which chain that file.  The method is similar to how Super Grub2 Disk
works, and will support any distro ISO which ships a
/boot/grub/loopback.cfg file.

Package: grub-loopback-iso
Architecture: i386 amd64
Depends: ${shlibs:Depends}, ${misc:Depends}, grub-pc (>= 1.99-1)
Description: Boot a compatible loopback ISO from GRUB 2
 grub-loopback-iso is a GRUB 2 configuration hook to boot compatible
 ISOs stored on the host filesystem. The stanzas built utilize GRUB
 2's loopback mount support to chain a /boot/grub/loopback.cfg file on
 an ISO.

The source archive URL has therefore (once again) been renamed to:
https://code.launchpad.net/~finnix/finnix/grub-loopback-iso-pkg

(loopback.cfg would also be a nice feature for d-i ISOs to ship, as well
as any other derivatives (or any distro at all) which supports the
findiso= or iso-scan/filename= feature.)

RF



signature.asc
Description: OpenPGP digital signature

Re: detailed lists with archive contents - more than just Contents

[Helmut Grohne]

On Tue, Apr 16, 2013 at 03:04:20PM +0200, Goswin von Brederlow wrote:
> Will that also detect files in multiarch packages that are not identical?

No, it does not do this at the moment. The main reason here is that
currently only amd64 is processed. Support for multiple architectures
would take a bit more to implement and vastly more resources on the
machine hosting dedup.d.n.

> Or files in foo_arch.deb that should be in foo-common_all.deb?

I do not yet understand what kind of algorithm you imagine here. In any
case dedup.d.n does not do such a thing at the moment. In addition a
task that operates one one binary package is likely better suited for
lintian.

Helmut


-- 
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/20130416190906.ga7...@alf.mars

Re: alternative debian/rules

[Steve Langasek]

On Tue, Apr 16, 2013 at 02:28:18PM +0200, Goswin von Brederlow wrote:
> On Fri, Apr 05, 2013 at 10:47:39AM -0700, Russ Allbery wrote:
> > ?? ??  writes:

> > > Indeed.

> > > So, in any case one can use its own tool just like dh:

> > > %:
> > > debian/megatool $@

> > Yes, from a Policy perspective.  Although please consider using dh and its
> > framework instead to make life easier for everyone else in the project who
> > may have to help out with maintaining the package, such as the security
> > team.  It has a nice plugin module system that lets you add custom
> > infrastructure for particular types of projects without changing the basic
> > framework.

> % ls -lh debian/rules
> lrwxrwxrwx 1 mrvn users  1 Apr 16 12:27 debian/rules -> /usr/bin/dh

I don't understand your point, other than to demonstrate that you're doing
something which doesn't conform to policy?

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

Plat'Home OpenBlocks discounted for Debian member and FLOSS Developer

[Nobuhiro Iwamatsu]

Hi, all.

Plat'Home is one of the Debconf 13 sponsor will sell at discount to
Debian member and FLOSS Developer for the OpenBlocks of small ARM micro server.

  https://openblocks.plathome.com/form/obs_verification/input.html

Two types of the machine will be sold.

 * OpenBlocks A6 / $250
   ARM (kirkwood) 600 MHz CPU and 512 MB onboard memory.
   http://openblocks.plathome.com/products/a6/

* OpenBlocks AX3 / $450
   Dualcore ARM (armadaXP) 1.33 GHz CPU and 1 GB onboard memory.
   http://openblocks.plathome.com/products/ax3/

If you are interested, please contact to the following URL.

  https://openblocks.plathome.com/form/obs_verification/input.html

About Plat'Home:
  We're a Linux server and services company in Tokyo, the first to bring
  the Linux operating system to Japan.
  Our key product is the OpenBlocks series, robust and flexible embedded
  Linux servers. Companies like KDDI, HitachiSoft, Yomiuri(news),
  Shimizu (construction) and many others depend on us every day. We are a
  company listed at the Tokyo Stock Exchange Mothers Market.

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


signature.asc
Description: Digital signature

Automatically satisfying Build-Depends from local control file

[Nikolaus Rath]

Hello,

When downloading a source package from somewhere else, I often find
myself in the situation that after..

$ dpkg-buildpackage -us -uc
[...]
dpkg-checkbuilddeps: Unmet build dependencies: libreadline6-dev 
libncursesw5-dev (>= 5.3) libbz2-dev liblzma-dev libgdbm-dev libdb-dev 
tk8.5-dev blt-dev (>= 2.4z) libbluetooth-dev libffi-dev (>= 3.0.5) xvfb
dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
dpkg-buildpackage: warning: (Use -d flag to override.)

...I have to manually/painfully construct the command line...

$ sudo apt-get install libreadline6-dev libncursesw5-dev libbz2-dev liblzma-dev 
libgdbm-dev libdb-dev tk8.5-dev blt-dev  libbluetooth-dev libffi-dev xvfb

...by copying every package name, but omitting the version numbers. 


Has someone already written a tool to automate this? I.e., parse
debian/control and run the appropriate apt-get command?

I think I am *not* looking for apt-get build-deps, because I'm talking
about source packages not included in an apt repository. 

Best,

   -Nikolaus

-- 
 »Time flies like an arrow, fruit flies like a Banana.«

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


--
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/87a9oxu6uo@vostro.rath.org

Re: Automatically satisfying Build-Depends from local control file

[Charles Plessy]

Le Tue, Apr 16, 2013 at 09:19:27PM -0700, Nikolaus Rath a écrit :
> 
> When downloading a source package from somewhere else, I often find
> myself in the situation that after..
> 
> $ dpkg-buildpackage -us -uc
> [...]
> dpkg-checkbuilddeps: Unmet build dependencies: libreadline6-dev 
> libncursesw5-dev (>= 5.3) libbz2-dev liblzma-dev libgdbm-dev libdb-dev 
> tk8.5-dev blt-dev (>= 2.4z) libbluetooth-dev libffi-dev (>= 3.0.5) xvfb
> dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
> dpkg-buildpackage: warning: (Use -d flag to override.)
> 
> ...I have to manually/painfully construct the command line...

Hi Nikolaus,

this is a question that is more appropriate for the debian-mentors mailing list.

The tool you are looking for is "mk-build-deps" from the package "devscripts".

Cheers,

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


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

Re: Automatically satisfying Build-Depends from local control file

[Carlos Alberto Lopez Perez]

On 17/04/13 06:19, Nikolaus Rath wrote:
> Hello,
> 
> When downloading a source package from somewhere else, I often find
> myself in the situation that after..
> 
> $ dpkg-buildpackage -us -uc
> [...]
> dpkg-checkbuilddeps: Unmet build dependencies: libreadline6-dev 
> libncursesw5-dev (>= 5.3) libbz2-dev liblzma-dev libgdbm-dev libdb-dev 
> tk8.5-dev blt-dev (>= 2.4z) libbluetooth-dev libffi-dev (>= 3.0.5) xvfb
> dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
> dpkg-buildpackage: warning: (Use -d flag to override.)
> 
> ...I have to manually/painfully construct the command line...
> 
> $ sudo apt-get install libreadline6-dev libncursesw5-dev libbz2-dev 
> liblzma-dev libgdbm-dev libdb-dev tk8.5-dev blt-dev  libbluetooth-dev 
> libffi-dev xvfb
> 
> ...by copying every package name, but omitting the version numbers. 
> 
> 
> Has someone already written a tool to automate this? I.e., parse
> debian/control and run the appropriate apt-get command?
> 
> I think I am *not* looking for apt-get build-deps, because I'm talking
> about source packages not included in an apt repository. 
> 
> Best,
> 
>-Nikolaus
> 

Please check: http://bugs.debian.org/214566




signature.asc
Description: OpenPGP digital signature