dpkg-source --commit fails to find local changes
I'm unable to get dpkg-source to see that I have changed files in a python source package format 3.0 (quilt): dpkg-source: info: there are no local changes to record No matter what I seem to do inside the json-schema-validator package, dpkg refuses to spot the change, even renaming the package in setup.py or changing the .py files. I get no warning on building and I have to create the patch manually. Is this a regression or is there something different about the json-schema-validator and versiontools packages? This happened with 1.17.11 and 1.17.12. -- Neil Williams = http://www.linux.codehelp.co.uk/ signature.asc Description: PGP signature
Re: dpkg-query --print-avail: how to get long descriptions?
On Thu, 24 Apr 2014 23:04:35 +0200
Marcel Partap mpar...@gmx.net wrote:
Dear DPKG developers,
for all my packages installed (via aptitude), long descriptions are
written (by? aptitude? dpkg?) to /var/lib/dpkg/{status,available} ..
How to get them for uninstalled packages as well? The
/var/lib/dpkg/available generated by dselect update does only contain
the short description.. apt-cache also doesn't show them.
apt-cache show package
does include the long description, along with all of the other fields.
The full list of long descriptions for all packages, as well as all the
other information, will be in /var/lib/apt/lists/ - one large file per
apt source, combining installed and uninstalled packages.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
signature.asc
Description: PGP signature
Bug#737634: dpkg-dev: please reject native/non-native version when building native/non-native source packages
On Mon, 10 Feb 2014 22:13:45 +0100 Wouter Verhelst wou...@debian.org wrote: Sigh. On Wed, Feb 05, 2014 at 12:59:23PM +, Neil Williams wrote: Using packages to support upstream development is a common problem /common problem/common source of problems/ and this is exactly where things get awkward. No, it is not a *problem*; it is a *method* of doing things. ... one which I've used consistently for more years than I've been a DD and had frequent problems with various assumptions in various tools and in more distributions than just Debian and its derivatives. Hopefully the clarification will show that I'm not questioning the methods of anyone (other than possibly my own). It is not your place (nor mine) to question another person's methods of doing things; especially not if said methods are done outside of Debian, as is here the case. ... and in my ongoing work. If using distribution tools for upstream development was easy, we might not have had people developing tools like pypi, ruby gems, CPAN or a whole range of other non-distribution distributive tools. This isn't just a Debian problem. (Indeed fixing it in Debian isn't going to fix the problems because upstreams will rarely fixate on a single distribution across the entire team - for entirely sane reasons.) It is right for upstream to want to deploy to FHS compliant paths and use dependencies from the main distribution system etc. None of the distribution tools for any of the distributions actually make it easy to then develop within those paths without either rebuilding unreleased upstream packages or copying files into privileged paths. Both of these routes need sudo access which just makes things harder again. Why must every developer have sudo access on the development box? That is exactly why pypi and buildout have got so much traction. It annoys me that I have to use such methods for upstream work because dpkg-dev is too constrained by rules which *only* relate to official builds. Doing a quick native build of a non-native package for use and distribution within a known team is a *common requirement* for upstream teams. (e.g. it means that developers can push to a branch, get a quick native package built, uploaded locally, installed via an inotify and available to test without the unnecessary step of building an .orig.tar.gz in the middle.) It's not quite as clean or DRY as restarting a daemon directly from a user-privilege git clone but it is workable. Why should that require two branches of the packaging files? Developing using Debian is not just about development of Debian. Upstream teams use dpkg-dev too. Constraints which are entirely warranted for developing packages destined for ftp-master are directly harmful for developing packages destined for a repository on 192.168. Yes this could work with overrides but those overrides need to be build specific (not package specific or version specific). This is exactly why a ~/.gbp.conf is the right approach. Not true. There are options to use debuild or pdebuild or dpkg-buildpackage in-place. e.g. I use: [DEFAULT] #builder = git-pbuilder builder = debuild cleaner = fakeroot debian/rules clean pristine-tar = True [git-buildpackage] export-dir = ../build-area/ tarball-dir = ../tarballs/ Even if so, this increases the complexity of the system, and requires people to learn yet another tool to Just Do what was previously possible with no extra fluff. It's okay for a tool (like dpkg) to warn if something doesn't look right. It's not okay for a tool (like dpkg) to pretend to be smarter than the person operating said tool. True - however, there will always be a need for tools like git-bp and it is common to use aliases and JDTRT scripts to provide a consistent interface no matter what changes beneath. Thankfully, none of those hacks make it into Debian but that does mean that people within Debian don't get to see how the tools are actually used. Switching a non-native package to native arbitrarily is a necessary use of dpkg and it needs to be supported cleanly and in a way which is easy to override using a per-build configuration option. -- Neil Williams = http://www.linux.codehelp.co.uk/ signature.asc Description: PGP signature
Bug#737634: dpkg-dev: please reject native/non-native version when building native/non-native source packages
On Wed, 5 Feb 2014 12:21:30 + Sam Hartman hartm...@debian.org wrote: Andreas == Andreas Beckmann a...@debian.org writes: Andreas On 2014-02-05 10:57, Sam Hartman wrote: tarballs useful; anyone who is likely to want to build this from source probably has a copy of git and can checkout a tag. Andreas Such a tag corresponds to an upstrema version? yes. I'm happy to entertain other options rather than 3.0(native) but my requirements are: * support for upstream version * support for debian revision * No need to have upstream sources available to dpkg-buildpackage prior to running it * No need to maintain .orig.tar.gz artifacts produced by dpkg-source and keep the checksums of these artifacts consistent between packages with the same upstream versions. Andreas All this sounds like it can be done with git-buildpackage Andreas --git-pristine-tar --git-pristine-tar-commit. Can be set Andreas in debian/gbp.conf. And maybe dpkg-source Andreas --single-debian-patch. no, that means I have to maintain the artifact (namely the .orig.tar.gz). The archive software (both reprepro and dak were I to use that) require that the .orig.tar.gz not change checksums. Using packages to support upstream development is a common problem and this is exactly where things get awkward. For my own role within an upstream team, I'm considering using unofficial or developer upstream tarball releases. We'll probably use a date based tag 2014.02 etc for the main monthly release. Developer builds will have a shortened git hash appended (this happens to match our existing deployment method) like 2014.02.234fdga2 and incremental upstream releases will use tag.01 etc. so 2014.02.01 This has advantages that developers self-verify that the tarballs work which finds problems due to new files not being included in the tarball. It also retains the upstream packaging behaviour. I don't want my build machines to be able to push back to my master repository. Nor do I want to have to release upstream versions if I lose state on my build machines. So this violates my requirements because I have to maintain an artifact of dpkg-source (the .orig.tar.gz) and makesure its checksum never changes. Also, using git-buildpackage is difficult. The build is done by sbuild, which does not call git-buildpackage. Not true. There are options to use debuild or pdebuild or dpkg-buildpackage in-place. e.g. I use: [DEFAULT] #builder = git-pbuilder builder = debuild cleaner = fakeroot debian/rules clean pristine-tar = True [git-buildpackage] export-dir = ../build-area/ tarball-dir = ../tarballs/ -- Neil Williams = http://www.linux.codehelp.co.uk/ signature.asc Description: PGP signature
Re: Add multiarch library paths to DEFAULT_LIBRARY_PATH in Dpkg::Shlibs?
On Tue, 16 Apr 2013 15:34:40 +0400
Игорь Пашев pashev.i...@gmail.com 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/
pgpa45NBs1Zd_.pgp
Description: PGP signature
Re: Add multiarch library paths to DEFAULT_LIBRARY_PATH in Dpkg::Shlibs?
On Tue, 16 Apr 2013 16:11:24 +0400 Игорь Пашев pashev.i...@gmail.com wrote: 2013/4/16 Raphael Hertzog hert...@debian.org: 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/multiarch:/usr/lib/multiarch, 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/ pgpydxnZopYnS.pgp Description: PGP signature
Re: Bug#180128: state of integration of dpkg-cross into dpkg
On Sun, 22 Jul 2012 18:01:05 +0100 Wookey woo...@wookware.org wrote: +++ Neil Williams [2012-07-22 17:05 +0100]: One unresolved issue is the cache values and architecture support: where to put the cross- config settings currently implemented in /etc/dpkg-cross/cross* which pass the architecture-specific values to autotools projects. CC'ing debian-embedded for more input on that. It was sugested at the multiarch-cross BOF at debconf this year that we create a 'crossbuild-support' package to take over these various glue functions from dpkg-cross. That could just stay named 'dpkg-cross' for simplicity but if we are going to drop all the cross-conversion functionality and add a load of other stuff, a name change makes sense. OK. I don't mind what the package name is, as long as it Breaks: xapt. If it's not dpkg-cross, it will also need to Conflict: dpkg-cross The cross-conversion functionality can only be dropped once the critical mass of -dev packages are implemented. Therefore, I think this bug will need to remain open, unless dpkg maintainers do not wish to integrate the cross architecture-specific metadata at all. (This data does not change until a new port is accepted by dpkg or an old port removed, at which point it is just a single file addition/removal containing data provided by the porters.) I don't think that dpkg is the right place for this data. The architecture-specific data? Is that really subject to change? True the package-specific stuff is going to change and is not useful in dpkg, but once a port has been accepted, the chances of the size of a long long being changed are slim (and a serious problem). We want to be able to update it easily without having to mess with important things like dpkg. True - for the package-specific stuff. Equally, the package-specific stuff could actually be patched into the relevant packages which is a better place for it - eventually. The core cross functionality is now in dpkg and apt. with the sole exception of the size of a long long for DEB_HOST_ARCH etc. We should discuss where remaining stuff like autoconf cache variables, triplet-prefixed commands like triplet-pkg-config and triplet-config scripts, cross-build-essential package lists and the like should live, but I don't currently see good arguments to put any more of it into dpkg. The package-specific stuff does not need to be lumped in with the truly architecture-specific variables. Most of the package-specific cache variables are not also architecture-specific, separating those out means less files need updates and if we do get the package-specific cache values into the packages, the whole cache problem becomes more manageable. This is a long-term goal, it will take until Wheezy+1 to even get that critical mass of -dev MultiArch packages. If we are agreed on that then this bug is indeed closed. So is it worth separating out the architecture-specific cache values? It's not easy to do until other changes are in place but I think it should be done. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpg709runOyv.pgp Description: PGP signature
Re: Bug#180128: state of integration of dpkg-cross into dpkg
On Sun, 22 Jul 2012 19:23:44 +0200 Guillem Jover guil...@debian.org wrote: On Sun, 2012-07-22 at 18:01:05 +0100, Wookey wrote: It was sugested at the multiarch-cross BOF at debconf this year that we create a 'crossbuild-support' package to take over these various glue functions from dpkg-cross. That could just stay named 'dpkg-cross' for simplicity but if we are going to drop all the cross-conversion functionality and add a load of other stuff, a name change makes sense. Such package sounds like a good idea indeed, but I'd really like if any glue required there would end up being mere environment variable settings (like appropriate CC for cross-building for example), symlinks for cross tools, the cache files or at most a tiny wrapper for dpkg-buildpackage passing correct options. Anything else should be integrated back in the lower layers IMO (if it makes sense and the solutions are “generic enough”). OK. e.g. for armel: ac_cv_c_bigendian=no ac_cv_c_char_unsigned=yes ac_cv_sizeof_long_long=8 ac_cv_sizeof_unsigned_long_long=8 ac_cv_sizeof_long=4 Something that has crossed my mind in the recent past is that cputable has most of this data, but not all, and it could make sense to add more information so that the architecture ABI is crystal clear from the tables alone. That sounds like a very useful goal. Thanks. dpkg-cross or crossbuild-support or whatever could then generate an autoconf cache file at build time from the dpkg tables for example. Because I'd assume there's other cached values that will end up there and those would certainly not be appropriate for dpkg. OK. I don't think that dpkg is the right place for this data. We want to be able to update it easily without having to mess with important things like dpkg. The core cross functionality is now in dpkg and apt. We should discuss where remaining stuff like autoconf cache variables, triplet-prefixed commands like triplet-pkg-config and triplet-config scripts, cross-build-essential package lists and the like should live, but I don't currently see good arguments to put any more of it into dpkg. Except for my comments above, I tend to agree with this. I'd be happy if this bug is closed with an upload of dpkg which extends the cputable data to complete the ABI declarations with the architecture-specific values from which dpkg-cross / replacement can derive the cache values. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpgpoy3ZoYdp.pgp Description: PGP signature
Bug#180128: state of integration of dpkg-cross into dpkg
On Wed, 18 Jul 2012 19:11:38 +0200 Guillem Jover guil...@debian.org wrote: The bulk of the patch is now out of date but rather than spend time updating the patch, work is ongoing to merge the existing dpkg-cross package (which includes all the cache values and architecture support) into dpkg itself, sometime after Lenny. Far better, in my view, to remove the 'patch' tag from this report, keep it open as wishlist and I'll merge it with the eventual bug report that implements an updated patch (arranged with Guillem) that fully merges dpkg-cross into dpkg and then remove dpkg-cross (and apt-cross) from unstable. So, was checking this (and also the dpkg roadmap) and was wondering what else is still missing to be merged from dpkg-cross? If the only problem is the listed below, then it'd seem this bug has been resolved and it can be closed. One unresolved issue is the cache values and architecture support: where to put the cross- config settings currently implemented in /etc/dpkg-cross/cross* which pass the architecture-specific values to autotools projects. CC'ing debian-embedded for more input on that. e.g. /usr/share/perl5/Dpkg/Shlibs.pm contains numerous references to dpkg-cross-style paths which pick up these files as well as allow dpkg-cross'd libraries to be usable whilst MultiArch is still being rolled out. This parallel support needs to be retained until some critical mass of libraries and -dev packages are completely MultiArch compliant. At that point (and not before) dpkg-cross would change into a transitional package which is merely a configuration shell with no command-line interface (and no perl module) but which just provides the existing /etc/dpkg-cross/cross* data. At that point, xapt would have to be removed from Debian. My proposal would be that this transition is marked as dpkg-cross 3.0.0 and xapt gains a Depends: dpkg-cross (= 3) immediately Wheezy is released. dpkg-cross 3.0.0 would then have a Breaks: xapt and xapt would be removed once dpkg-cross 3.0.0 arrived in unstable, possibly not until after Wheezy +1, depending on the resolution of -dev MultiArch package issues. To allow final removal of the transitional dpkg-cross 3.0.0 and closure of this bug, dpkg-dev would adopt the arch-specific metadata in dpkg-cross 3.0.0. Packages which currently rely on package-specific metadata in /etc/dpkg-cross/cross* will have to be patched to continue any cross-building support before dpkg-cross can finally be removed. The rest of this problem comes down to individual packages: 0: packages using custom config scripts instead of pkg-config 1: packages which have m4 macros which don't handle cross-building cleanly, e.g. AC_TRY_RUN without fallbacks. I think having dpkg-cross 3.0.0 is a useful interim stage which allows the problems with -dev MultiArch packages to be resolved after Wheezy, allows packages to migrate whilst retaining what cross-build support we already have and provides a somewhat smooth path to eventual removal of dpkg-cross. Therefore, I think this bug will need to remain open, unless dpkg maintainers do not wish to integrate the cross architecture-specific metadata at all. (This data does not change until a new port is accepted by dpkg or an old port removed, at which point it is just a single file addition/removal containing data provided by the porters.) e.g. for armel: ac_cv_c_bigendian=no ac_cv_c_char_unsigned=yes ac_cv_sizeof_long_long=8 ac_cv_sizeof_unsigned_long_long=8 ac_cv_sizeof_long=4 The main issue unresolved in this bug report is the mapping of /usr/lib/foo.so to /usr/arm-linux-gnu/lib/foo.so for packages that do not use pkg-config (e.g. I'm having upstream problems trying to configure a package that build-depends on Postgres and ODBC using pg_config and iodbc-config respectively). This should be solved by making those packages multi-arch ready. Yes, this part of it is resolved as far as dpkg is concerned and the work is now with package maintainers to implement MultiArch support but there remains the issues around MultiArch and -dev packages which may yet require some dpkg support - and thereby block this bug. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpk3mGsbK5UH.pgp Description: PGP signature
Re: BinNMU changelog handling for Multi-Arch: same packages
On Wed, 11 Jul 2012 17:01:24 -0700 Russ Allbery r...@debian.org wrote: Raphael Hertzog hert...@debian.org writes: The right *temporary* solution then. Remember that this was meant as an intermediary solution until the full changelog (with the bin-nmu entry) is just integrated in the package medata (control.tar). Please don't put that into the files used to prepare content for dpkg -s and apt-cache - that output is large enough as it is. A single step like this could seriously compromise package handling on low resource machines and push apt passed it's memory mapping limits again even on more powerful machines. Oh, yes, absolutely agreed. Sorry for not making that clear. Putting the changelog in the package metadata makes a ton of sense. In fact, if we could also do that with the copyright file, that would eliminate nearly all of our issues with linked doc directories and would simplify a whole currently-contentious area of Policy, replacing it with a much simpler debate about the right interface to view those files for installed packages. ... and that would be even worse if not isolated from the status and cache information at the point where it is unpacked. Wherever the data lives inside the .deb is not the problem. Where the data gets cached, copied, listed and parsed is likely to be a major problem. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpRuL0mtyRmz.pgp Description: PGP signature
Re: dpkg-query --show, invalid output when package is not found, and executed within a bash script.
On Fri, 15 Jun 2012 16:16:22 +0800 eugene qin picocrea...@gmail.com wrote: The following shows an unexpected behaviour of the query output directly to the console screen, as oppose to what was intended in the bash script. The following 2 bash script examples, will probably explain the bug better. $ dpkg-query --show theseAintTheDroidsYourLookingFor 21 No packages found matching theseAintTheDroidsYourLookingFor. $ dpkg-query --show theseAintTheDroidsYourLookingFor 2/dev/null $ dpkg-query --show theseAintTheDroidsYourLookingFor file 21 $ cat file No packages found matching theseAintTheDroidsYourLookingFor. The behaviour is correct - requested output goes to STDOUT, error messages go to STDERR. In the second case, the variable is returned a blank The variable is reading STDOUT. , while the No package found output goes directly to console screen. ... because you aren't capturing STDERR PS: Im sending this email, as I am unable to find the bug tracker for the package directly =x http://bugs.debian.org/dpkg -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpZbkfHtvvXo.pgp Description: PGP signature
Re: Bug #340306: Specification draft for signed debs
On Mon, 11 Jun 2012 11:26:19 +0200 (CEST) ni...@thykier.net (Niels Thykier) wrote: * Role (required, simple). Defines the signers relation to the package. It must be one of the following values: - builder: The signer built the package. At most one signature file can use this role. - reviewer: The signer reviewed the package. This role can be used in any number of signature files. - vendor: The signer is a vendor (re-)distributing the package. The name of the vendor will be in the Vendor field. This role can be used in any number of signature files (assuming the vendors import the deb as-is and simply resign it). * Vendor (special, simple). Contains the name of the Vendor - Field is mandatory if Role has the value vendor, otherwise it should be absent. - Example value: Debian * Vendor-URI (optional, simple). URI to the vendor's website or documentation. - Should be omitted if Vendor is not present. - Example value: http://debian.org Open question: should we allow implementation specific fields with the usual X-field notation (or something similar)? That would be useful for Emdebian and other derivatives who need to preserve the original builder information and then sign as itself as a builder (effectively a rebuilder) because we modify the data.tar.gz and control.tar.gz without changing the md5sums of the compiled files within the data.tar.gz. (We simply remove files compress debian/copyright). Preserving the original builder metadata helps demonstrate binary compatibility with the original Debian package as the signature file for that builder would have to be removed - it's now a broken sig. If there is to be only one builder role, the additional fields can used to store the details of the original builder role, effectively transferring the builder role to Emdebian and storing the old value as another field. Reviewer doesn't really fit. X-DebianBuilder: the Signer details from the original Debian package X-DebianDate: the date the Debian package was signed. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgplB6NS2U8xt.pgp Description: PGP signature
Re: Temporary Files in Packages
On Mon, 20 Feb 2012 10:38:05 -0500 Brandon Phelps bphe...@gls.com wrote: I'm not sure if this is the best list for this question so please correct me if not. Probably not the right list, IMHO. I am putting together some packages for our internal servers and have an SQL file that I need to run on the database during the package install. I realize I could put the .sql file in /tmp and simply remove it after I've successfully imported it into the mysql database like this: service mysqld stop mysqld --bootstrap /tmp/dbscript.sql service mysqld start rm /tmp/dbscript.sql But I am wondering if there is a better place for this? Yes. From previous experience of exactly these startup situations, there will *always* be situations where the local admin is going to need to redo this SQL injection for whatever reason and it is a lot easier, therefore, if the SQL file is kept in the package, maintained by the package and used from that location by the package. Myself, I'd put the .sql file in /var/lib/ or /usr/share/ and let your postinst read it from there. What is generating the content of the SQL file? If the rest of the postinst generates the SQL itself, then maybe /tmp might be OK but you should allow admins to rescue systems which may get into a state where the first part of the generation process takes an amount of time / hit a bug elsewhere and just having the .sql somewhere outside /tmp and not hidden away in an unusual location would make things easier. Perhaps generate the SQL in the package build and then include it directly in the postinst? (No need to remove it either, for above reasons.) Make life easier for the local admins to see what was done to cover situations where it just doesn't work as expected. Don't hide (or erase) useful stuff...someday, you'll regret that 'rm' when someone files a bug... -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpLtrniMjq5I.pgp Description: PGP signature
Re: Please test gzip -9n - related to dpkg with multiarch support
On Tue, 07 Feb 2012 19:11:16 +0100 Michael Biebl bi...@debian.org wrote: On 07.02.2012 18:07, Joey Hess wrote: Neil Williams wrote: I'd like to ask for some help with a bug which is tripping up my tests with the multiarch-aware dpkg from experimental - #647522 - non-deterministic behaviour of gzip -9n. pristine-tar hat tricks[1] aside, none of gzip, bzip2, xz are required to always produce the same compressed file for a given input file, and I can tell you from experience that there is a wide amount of variation. If multiarch requires this, then its design is at worst broken, and at best, there will be a lot of coordination pain every time there is a new/different version of any of these that happens to compress slightly differently. Exactly. I'm not convinced that this is fixable at the gzip level, nor is it likely to be fixable by the trauma of changing from gzip to something else. That would be pointless. What matters, to me, is that package installations do not fail somewhere down the dependency chain in ways which are difficult to fix. Compression is used to save space, not to provide unique identification of file contents. As it is now clear that the compression is getting in the way of dealing with files which are (in terms of their actual *usable* content) identical, then the compression needs to be taken out of the comparison operation. Where the checksum matches that's all well and good (problems with md5sum collisions aside), where it does not match then dpkg cannot deem that the files conflict without creating a checksum based on the decompressed content of the two files. A checksum failure of a compressed file is clearly unreliable and will generate dozens of unreproducible bugs. MultiArch has many benefits but saving space is not why MultiArch exists and systems which will use MultiArch in anger will not be likely to be short of either RAM or swap space. Yes, the machines which are *targeted* by the builds which occur as a result of having MultiArch available for Emdebian will definitely be aimed at low resource devices but those devices do NOT need to actually use MultiArch themselves. In the parlance of --build, --host and autotools, MultiArch is a build tool, not a host mechanism. If you've got the resources to cross-build something, you have the resources to checksum the decompressed content of some files. As far as having MultiArch to install non-free i386 on amd64, it is less of a problem simply because the number of packages installed as MultiArch packages is likely to be a lot less. Even so, although the likelihood drops, the effect of one of these collisions getting through is the same. This seems to be a rather common problem as evindenced by e.g. https://bugs.launchpad.net/ubuntu/+source/clutter-1.0/+bug/901522 https://bugs.launchpad.net/ubuntu/+source/libtasn1-3/+bug/889303 https://bugs.launchpad.net/ubuntu/oneiric/+source/pam/+bug/871083 See the number of .gz files in this list: http://people.debian.org/~jwilk/multi-arch/same-md5sums.txt In Ubuntu they started to work-around that by excluding random files from being compressed. So far I refused to add those hacks to the Debian package as this needs to be addressed properly. Maybe the way to solve this properly is to remove compression from the uniqueness check - compare the contents of the file in memory after decompression. Yes, it will take longer but it is only needed when the md5sum (which already exists) doesn't match. The core problem is that the times when the md5sum of the compressed file won't match are unpredictable. No workaround is going to be reliable because there is no apparent logic to the files which become affected and any file which was affected at libfoo0_1.2.3 could well be completely blameless in libfoo0_1.2.3+b1. (binNMU's aren't the answer either because that could just as easily transfer the bug from libfoo0 to libfoo-dev and so on.) There appears to be plenty of evidence that checksums of compressed files are only useful until the checksums fail to match, at which point I think dpkg will just have to fall back to decompressing the contents in RAM / swap and doing a fresh checksum on the contents of each contentious compressed file. If the checksums of the contents match, the compressed file on the filesystem wins. Anything else and Debian loses all the reproducibility which is so important to developers and users. When I need to make a cross-building chroot from unstable (or write a tool for others to create such chroots), it can't randomly fail today, work tomorrow and fail with some other package the day after. If others agree, I think that bug #647522, currently open against gzip, could be reassigned to dpkg and retitled to not rely on checksums for compressed files when determining MultiArch file collisions. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgptj0LtSC5J0.pgp Description: PGP signature
Changes in unpacking in dpkg 1.16
What has changed in the actions of dpkg --unpack recently which has altered the detection of which packages remain to be configured? A chroot created with multistrap now fails to configure because dpkg --configure -a not only does not identify any packages as needing configuration but also changes the status from install ok unpacked to install ok installed for every package without doing any work. (dpkg --unpack cannot be used directly because multistrap is not operating natively and cannot execute anything within the chroot.) I can't see any differences currently in the files in /chroot/var/lib/dpkg/ between using dpkg --unpack (native architecture) and the multistrap method (native or foreign). Can we look again at a way of unpacking a .deb which is architecture-neutral but still allows the package to be configured once the fs is accessed under the appropriate arch? -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpPFrl67HkXs.pgp Description: PGP signature
Re: dpkg 1.16.1 configure
On Wed, 28 Sep 2011 08:40:06 +0200 Gabor Z. Papp g...@papp.hu wrote: * Guillem Jover wrote: | without installed dpkg the new 1.16.1 tarball can't be | configured/compiled due the above error. | W/o more context I can only guess, but did configure fail to find the | perl binary for any reason? Maybe you don't have it installed or you | do but in a non-standard path? I have installed, but in a non-standard path, but even it could be found, I don't have dpkg installed, so dpkg-architecture.pl will fail. Gabor: dpkg does try to avoid depending on itself, so there is no need for dpkg-architecture to exist in $PATH. The configure script is actually looking for dpkg-architecture.pl in the scripts/ directory of the unpacked source. So it should be entirely possible to build dpkg without having dpkg installed (it would make it impossible to bootstrap new architectures otherwise). See lines 10671, 10693 10715 of the configure script - it also sets the PERL5LIB to look at the unpacked sources so that the Dpkg modules can be found without having to have them installed. What dpkg does need is a working perl installation to be able to run the perl scripts directly from the unpacked sources. So as long as perl can be found, whether you have dpkg installed or not, dpkg-architecture.pl will work from the scripts/ directory. (Once the package is built, the actual script becomes dpkg-architecture - losing the .pl suffix, so this is one way to work out which script is being called.) Therefore, as Guillem has already mentioned, this is more likely to be down to your perl installation - if you set the correct path to perl does dpkg then build? What path do you need to specify to run any perl script which is not already in your $PATH? -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpmZbJ323RyV.pgp Description: PGP signature
Re: Bug#616111: Bootstrapping a foreign architecture with multiarch
On Sat, 2 Apr 2011 05:47:47 +0200 Guillem Jover guil...@debian.org wrote: Adding linaro people and debian-embedded to CC: Hi! On Fri, 2011-04-01 at 22:31:07 +0100, Neil Williams wrote: dpkg cannot be executed inside the chroot because it has not necessarily been unpacked at this stage, it certainly has not been configured. (dpkg is running from outside the chroot). (An Essential package does not need to be configured to be functional.) (It's quite possibly the wrong architecture inside the chroot, so this doesn't apply.) Yet dpkg-query won't work with --admindir to operate from outside: I'm checking on this - it could be an artefact of how the chroot was initially created. Anyways: Multi-Arch: same packages will use /var/lib/dpkg/info/package:arch.something For Multistrap, every file in /var/lib/dpkg/ has to be created by multistrap, based on the data obtained from dpkg -e (basically the DEBIAN/ content). This data needs only to be sufficient that dpkg can correctly configure the packages once dpkg itself is able to be executed inside the new filesystem. It's sufficient, you just need to know the value of the Multi-Arch field. True. I've got a change now which uses dpkg -f to check the Multi-Arch field of the actual downloaded .deb (independent of arch) and use that to detect Multi-Arch: same, then lookup Architecture in the same way, add that to the filename of the created maintainer script etc. for /path/to/chroot/var/lib/dpkg/info/* If you are not going to install multiple instances of “Multi-Arch: same” packages, then just keep writting the files as you are currently doing, the next dpkg native run on that chroot image will automatically upgrade the db layout. Which seems to be the less onerous way to handle this. Otherwise you'll have to duplicate the db layout handling, including format file, etc, and at that point I'd say you are on your own. Multistrap will need to be able to create chroots containing multiple instances of Multi-Arch: same packages because it needs to be able to build cross-building chroots with libc6-dev of the build and host architectures, as well as other common dependencies like libglib2.0-0 (needed as build arch by pkg-config and as host arch by everything else). Multistrap, like debootstrap and other similar scripts, is commonly used in two roles - to create a chroot of the build architecture for building stuff in a contained environment and creating a chroot of a foreign architecture to act as a root filesystem. As with debootstrap, I see no reason to implement two different methods to creating these chroots inside a single tool, so when creating a build arch chroot multistrap uses the same processing as when creating a foreign arch chroot. That processing has to avoid a design flaw in dpkg where the normal --unpack method would attempt to run the preinst scripts. On Fri, 2011-04-01 at 22:43:35 +0100, Neil Williams wrote: Further to this, --control-path doesn't include 'list' but $pkg:$arch.list files are created. This was done on purpose, .list and .conffiles are internal files, the correct interfaces to access the information is dpkg-query. Internal files maybe, but multistrap still needs to create them to handle packages of a foreign architecture. Even once Multi-Arch is fully deployed, this will continue because the assumption with Multi-Arch is that the foreign architecture packages are being installed alongside the build architecture. When preparing a root filesystem for a foreign architecture (e.g. an embedded device), multistrap cannot put the amd64 binaries into the chroot and then add the armel, it needs to be able to unpack armel binaries into an armel chroot without running the preinst scripts or using the armel dpkg binary inside the chroot. The preinst scripts can't run on the build arch (amd64) because that would expose the chroot to the external configuration. i.e. it needs to be possible to create an armel chroot of Ubuntu natty from an i386 machine running Debian Wheezy and similarly from Ubuntu natty i386 to create a Debian Wheezy armel chroot. Currently, dpkg --unpack cannot cope with this and the existing Multi-Arch changes in dpkg do not address this problem. This has been covered before in this bug and elsewhere without resolution, but please reconsider how dpkg - even in a Multi-Arch world - needs to support unpacking foreign architecture binaries into a foreign architecture chroot and that this mandates that dpkg *must not* attempt to execute the preinst scripts inside the foreign chroot. It can *only* do so if the packages are to be unpacked into the main, external, system. When using --admindir and --instdir options to --unpack, dpkg *must* allow for the specified directories to actually be a foreign architecture chroot and act accordingly. Maybe this requires the addition of an --arch option to --unpack but it *does* need to be addressed
Re: Bootstrapping a foreign architecture with multiarch
On Thu, 3 Mar 2011 08:31:51 +0100 Raphael Hertzog hert...@debian.org wrote: 3/ Any program that assumes the current layout of control files (/var/lib/dpkg/info/package.something) will be broken (at least for some packages) since the layout will change to support Multi-Arch: same packages that can be co-installed. You should use dpkg-query --control-path package something to retrieve the path of the file. This has been introduced in dpkg 1.15.4 and is thus in squeeze already. dpkg cannot be executed inside the chroot because it has not necessarily been unpacked at this stage, it certainly has not been configured. (dpkg is running from outside the chroot). Yet dpkg-query won't work with --admindir to operate from outside: $ dpkg-query --admindir /home/neil/code/chroots/natty-amd64/var/lib/dpkg --control-path libc6 postinst $ Inside: /home/test# dpkg-query --control-path libc6 postinst /var/lib/dpkg/info/libc6:amd64.postinst /home/test# dpkg-query --admindir /var/lib/dpkg --control-path libc6 control /var/lib/dpkg/info/libc6:amd64.control $ ls -l /home/neil/code/chroots/natty-amd64/var/lib/dpkg/status -rw-r--r-- 1 root root 261652 Apr 1 21:46 /home/neil/code/chroots/natty-amd64/var/lib/dpkg/status dpkg outside the chroot is 1.15.8.10 Do you want a bug report for that one? Anyways: Multi-Arch: same packages will use /var/lib/dpkg/info/package:arch.something For Multistrap, every file in /var/lib/dpkg/ has to be created by multistrap, based on the data obtained from dpkg -e (basically the DEBIAN/ content). This data needs only to be sufficient that dpkg can correctly configure the packages once dpkg itself is able to be executed inside the new filesystem. It's sufficient, you just need to know the value of the Multi-Arch field. True. I've got a change now which uses dpkg -f to check the Multi-Arch field of the actual downloaded .deb (independent of arch) and use that to detect Multi-Arch: same, then lookup Architecture in the same way, add that to the filename of the created maintainer script etc. for /path/to/chroot/var/lib/dpkg/info/* -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp27291eH5tY.pgp Description: PGP signature
Re: Bootstrapping a foreign architecture with multiarch
On Fri, 1 Apr 2011 22:31:07 +0100 Neil Williams codeh...@debian.org wrote: Inside: /home/test# dpkg-query --control-path libc6 postinst /var/lib/dpkg/info/libc6:amd64.postinst /home/test# dpkg-query --admindir /var/lib/dpkg --control-path libc6 control /var/lib/dpkg/info/libc6:amd64.control $ ls -l /home/neil/code/chroots/natty-amd64/var/lib/dpkg/status -rw-r--r-- 1 root root 261652 Apr 1 21:46 /home/neil/code/chroots/natty-amd64/var/lib/dpkg/status dpkg outside the chroot is 1.15.8.10 Do you want a bug report for that one? Further to this, --control-path doesn't include 'list' but $pkg:$arch.list files are created. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpNGuXETpW7D.pgp Description: PGP signature
Re: [PATCH] Dpkg/Shlibs.pm: multiarch search paths
On Mon, 21 Mar 2011 09:55:26 +0100 Raphael Hertzog hert...@debian.org wrote: (Trimming the CC: feel free to drop patches@l.o if linaro-dev@l.l.o is more useful. Please keep debian-embedded in CC to reach me.) Not knowing much about cross-compilation I had started with a sligthly different approach than you, mimicking exactly what was done for cross-compilation support. 09:48 codehelp buxy: vorlon: my original query related to not so much building a cross-compiler but building gcc-* to install and run on cross, i.e. reverse-cross where build=amd64,host=armel,target=armel 09:48 codehelp cross-compiler build=amd64,host=amd64,target=armel 09:48 codehelp doesn't give you a libgcc1 which can be used to satisfy dependencies of packages cross-built using the cross-compiler Cross-building an entire distro, like Emdebian Crush, involved a long winded process: 0: Build gcc-4.* as an arm cross-compiler (not armel in those days but that's not important to the method) 1: Build build-dependencies of gcc using the cross-compiler 2: Build gcc-4.* as a normal package using the cross-compiler The people who are most likely to be doing this now are Linaro. Emdebian Crush stalled after Lenny (and used ARM not armel), so the version of gcc-4.2 in Lenny should still build with the typical dpkg-buildpackage -aarm. Later versions of gcc probably have other fixes which would cause the reverse cross build to fail, not due to the failure of the original patches but due to changes in gcc itself. To create a fully bootstrap-able system, gcc does need to support the reverse cross and this will need testing in Multi-arch world. Typically, gcc-4.* *should* be expected to build correctly just using: $ dpkg-buildpackage -a$arch No special target specification (except internally in debian/rules etc.), no expectation of building a cross-compiler, just building it as if it is any other package which needs to be cross-built. Of course, if libgcc1 can be made available in any other way than having to pretend that we actually want a native compiler on these systems (99% of the time we really don't), then everyone wins. Neil (or anyone else knowledgable on the topic), can you review the patches and tell us what's really needed and most logical according to you? Steve's patch: - adds the multi-arch path at the start of the search paths - adds them only for stantard cross-compilation (host != build) but not for the special cases used to detect a cross-compiler build Intuitively this does sound the correct way to do it, especially as what I wanted from the original patch was a standard cross-build, not the special case of building a cross-compiler, but: My patch: - adds the multi-arch path before the cross-arch patch but after the standard search path - add them in all cases where the cross-compilation paths are used Putting the multi-arch paths after the default path should not matter as dpkg-shlibdeps skips libraries of non-matching architecture. This is more in line with how it actually works out when trying to cross-build gcc itself. I'm not sure of the benefit of putting the multiarch lib location in front of the default lib location. I'm not sure if having some i386 libraries in a multi-arch path and the main system amd64 libraries in a non-multi-arch path would actually matter (after all, the same libraries *should* get updated together). That's a traditional Multi-Arch question, so I'd defer to Steve on that one. For cross-building, it's simply sufficient that the new multi-arch-cross paths precede the old dpkg-cross paths and both patches achieve this. For the case of building a cross-compiler, Steve's experience tends to prove that adding the multi-arch path is not needed... but I don't see why it should be treated differently than the cross-arch paths. Can you enlighten us? For building a cross-compiler, Steve is correct - it doesn't matter. For using that cross-compiler to cross-compile gcc itself, it will matter. Multi-Arch paths will be necessary to build a version of libgcc1 which can be installed on the target. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpnyLu6Y9VK5.pgp Description: PGP signature
Re: [PATCH] Dpkg/Shlibs.pm: multiarch search paths
On Mon, 21 Mar 2011 14:03:37 +0100 Matthias Klose d...@ubuntu.com wrote: On 21.03.2011 11:25, Neil Williams wrote: The people who are most likely to be doing this now are Linaro. Emdebian Crush stalled after Lenny (and used ARM not armel), so the version of gcc-4.2 in Lenny should still build with the typical dpkg-buildpackage -aarm. Later versions of gcc probably have other fixes which would cause the reverse cross build to fail, not due to the failure of the original patches but due to changes in gcc itself. the gcc-4.4 packaging is able to build a reverse cross. I didn't check gcc-4.5 and gcc-4.6. Matthias Oops, sorry Matthias - that was meant to be later versions of gcc *might* have other (internal) changes which could cause... I didn't mean to infer that I'd tried and failed a reverse cross with newer versions, I haven't had time to do that test. Thanks for the info on gcc-4.4. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpN9YV74jLFL.pgp Description: PGP signature
Re: Bootstrapping a foreign architecture with multiarch
that will be affected by the above problems? Please file a bug and usertag it with this command: $ bts user debian-dpkg@lists.debian.org . usertag $bug + multiarch Done. #616111 Bug CC'd. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpEOZfL6En7b.pgp Description: PGP signature
Bug#591522: Original patch for dpkg-dev avoiding DEFAULT_LIBRARY_PATH
http://lists.debian.org/debian-dpkg/2007/08/msg00027.html http://lists.debian.org/debian-dpkg/2007/09/msg00032.html Bug: #439979 -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgprvE8XYLx40.pgp Description: PGP signature
Re: Adding chroot support to the dpkg functional testsuite (was Bug#580984...)
On Thu, 13 May 2010 07:21:26 +0200 Guillem Jover guil...@debian.org wrote: [ Moving this to the debian-dpkg where it is relevant, CCing debian-embedded for the cross-installation bit. ] On Mon, 2010-05-10 at 18:55:13 +0200, Raphael Hertzog wrote: [ Bug in “dpkg --root” support. ] dpkg --root isn't used in the current Emdebian or cross-installation methods - TBH it doesn't appear useful from the dpkg manpage: --root=dir Changing root changes instdir to dir and admindir to dir/var/lib/dpkg. (--root appears to be a shortcut to combine --admindir and --instdir into one option) The only options where this would be used, AFAICT, is --install but that means running the maintainer scripts which is impossible when building a cross-chroot. Unless the new Multiarch code uses this method, it doesn't appear to be something debian-embedded needs to rely upon. Much more useful would be a way of 'installing' *without* allowing any maintainer scripts (or any command within the chroot) to be executed. dpkg in this mode would need to do everything it usually does to maintain the status files (in another directory) and put the maintainer scripts in a nominated directory, without executing any of them. If --root did that, it would be useful. Currently, Emdebian has to replicate this behaviour externally (e.g. in the multistrap package which we use to replace debootstrap and cdebootstrap) - it works very well but it would still be better if dpkg understood that maintainer scripts *cannot* hope to run inside a foreign chroot, ever. No amount of prefixes or hackery or magic will make it work - dpkg must simply accept that there are some situations where the maintainer scripts must not be allowed to execute, no exceptions, no complaints. I think this feature deserves a non-regression test given how seldom it's used in daily usages by the developers. That would imply adding the infrastructure to create a chroot, which might be nice to have anyway to test dpkg w/o affecting the installed system, but still, I'm not prepared to do this right now. What I had in mind was for example to add a new --test option which would make dpkg pass a new environment variable (say DPKG_ROOT_DIR) to the maintainer scripts denoting the root directory and just avoid doing the chroot() call. Care would need to be taken to use the correct built backends, though. This option (if properly renamed) might also be useful for cross-installations, perhaps. Although package maintainer scripts would need to be accomodated (if possible at all) to make called programs operate on the different root path, which might uglify them quite a bit. No. Cross-installation means that the package maintainer scripts are to be ignored under all circumstances and that there must never be any opportunity for any of the foreign package maintainer scripts to be executed, let alone discover where they are. Package maintainer scripts *cannot* be accommodated by a cross-installation but dpkg should still be able to create and maintain the relevant status files and put the maintainer scripts inside the chroot without calling them. dpkg should treat the package content as if was all just data and had no executable content whatsoever. It is not sane to run the scripts outside the chroot (amd64) and expect the configuration to be appropriate for armel or mips. This is the reason why Emdebian cannot use dpkg --unpack and has to have a separate method involving dpkg -x and dpkg -e. 'dpkg --unpack and dpkg --root foo --install' insist on trying to run the prerm/preinst which is just wrong. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpU5hMBdq2hH.pgp Description: PGP signature
Bug#560391: dpkg-dev: dpkg-source --print-format fails to recognise 3.0 (quilt)
On Fri, 11 Dec 2009 08:21:05 +0100 Raphael Hertzog hert...@debian.org wrote: On Thu, 10 Dec 2009, Neil Williams wrote: $ cd gpe-calendar-0.92/ gpe-calendar-0.92$ dpkg-source --print-format . 1.0 Try building with dpkg-source -b . and you'll see that it fails to select 3.0 (quilt). You need to call it in the same conditions than dpkg-source -b, that means from somewhere where the .orig tarball is available in the current directory. I might need to make this more explicit in the documentation. But then it also insists on finding ./debian/changelog in that same directory. That makes some very large assumptions about directory layout for something as simple as querying/verifying a source format string. e.g. this was to be used in svn-buildpackage in which case we have: ./foo/tarballs/foo_1.2.3.orig.tar.bz2 ./foo/trunk/debian/changelog ./foo/trunk/debian/source/format (trunk cannot be assumed here, it could be absent in a branch.) Why does --print-format need to locate the .orig.tar.gz|bz2 anyway? BTW the bash completion for --print-format is also broken, it does not allow a directory to be specified after the option when a directory is mandatory.) -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpVuiB7BOX5o.pgp Description: PGP signature
Bug#560391: dpkg-dev: dpkg-source --print-format fails to recognise 3.0 (quilt)
On Fri, 11 Dec 2009 11:10:48 +0100 Raphael Hertzog hert...@debian.org wrote: On Fri, 11 Dec 2009, Neil Williams wrote: That makes some very large assumptions about directory layout for something as simple as querying/verifying a source format string. Well, it's the same code than -b except we stop right after having selected the target format. So the docs should describe it as: When using --print-format, dpkg-source needs to be run in the same directory as any .orig.tar.gz|bz2 and also given the top level source directory (where it can find ./debian/changelog). e.g. after unpacking with 'dpkg-source -x foo_1.2.3-1.dsc', the command would be 'dpkg-source --print-format foo-1.2.3/', without changing the current working directory. This gets over the point that dpkg-source --print-format actually requires the user to think about two directories - the current one which dpkg-source uses to find the orig tarball and the one specified which dpkg-source uses to find debian/changelog. In most programs, specifying a directory leads the user to think that all operations would use that directory and that the current working directory shouldn't matter. e.g. $ ls /path/ doesn't care about `pwd` unless pwd doesn't exist, equally dpkg -x /path/foo /tmp/ doesn't care about pwd at all. IMHO it would be better if --print-format understood the existence of the foo-1.2.3/ directory that the -x option to dpkg-source may well have created and handled it transparently. That way, --print-format could be given a directory in which to find the source (as unpacked by apt-get source) and work out the rest itself. Why does --print-format need to locate the .orig.tar.gz|bz2 anyway? Because currently, if you don't have a .orig.tar file it will fallback to creating a native package in 1.0 format. IMHO dpkg-source --print-format should explain this fallback by putting a message on STDERR that the orig tarball has not been found, maybe dpkg-source was run from the wrong directory, especially if debian/source/format exists and contains something matching /3\.0.*/ (or anything other than 1.0). -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpBKYIWJNMNp.pgp Description: PGP signature
Bug#560391: dpkg-dev: dpkg-source --print-format fails to recognise 3.0 (quilt)
Package: dpkg-dev Version: 1.15.5.4 Severity: normal I'm testing format 3.0 (quilt) with a branch of gpe-calendar in collab-maint and also trying to get svn-buildpackage to understand source format 3.0 but dpkg-source --print-format is failing: $ dpkg-source -x gpe-calendar_0.92-4.dsc dpkg-source: info: extracting gpe-calendar in gpe-calendar-0.92 dpkg-source: info: unpacking gpe-calendar_0.92.orig.tar.gz dpkg-source: info: unpacking gpe-calendar_0.92-4.debian.tar.gz dpkg-source: info: applying dependency-renaming dpkg-source: info: applying desktop-validity dpkg-source: info: applying add-lgthread-linkage dpkg-source: info: applying migrate-to-soup_2.4 $ cd gpe-calendar-0.92/ gpe-calendar-0.92$ dpkg-source --print-format . 1.0 gpe-calendar-0.92$ cat debian/source/format 3.0 (quilt) $ head gpe-calendar_0.92-4.dsc Hash: SHA1 Format: 3.0 (quilt) Source: gpe-calendar Binary: gpe-calendar Architecture: any Version: 0.92-4 The branch can be found at: http://svn.debian.org/viewsvn/pkg-gpe/trunk/gpe-calendar/branches/trunk/ The relevant tarball is already in Debian or can be retrieved using 'uscan --force-download' Although only debian/ is in svn, I'm also testing in a complete (unpacked) source directory, as shown above. I can make the updated source package available if requested. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dpkg-dev depends on: ii base-files5.0.0 Debian base system miscellaneous f ii binutils 2.20-4 The GNU assembler, linker and bina ii bzip2 1.0.5-3high-quality block-sorting file co ii dpkg 1.15.5.4 Debian package management system ii libtimedate-perl 1.1900-1 Time and date functions for Perl ii lzma 4.43-14Compression method of 7z format in ii make 3.81-7 An utility for Directing compilati ii patch 2.6-2 Apply a diff file to an original ii perl [perl5] 5.10.1-8 Larry Wall's Practical Extraction ii perl-modules 5.10.1-8 Core Perl modules ii xz-utils 4.999.9beta+20091116-1 XZ-format compression utilities Versions of packages dpkg-dev recommends: ii build-essential 11.4 Informational list of build-essent ii fakeroot 1.14.4-1 Gives a fake root environment ii gcc [c-compiler] 4:4.4.2-2 The GNU C compiler ii gcc-4.3 [c-compiler] 4.3.4-6The GNU C compiler ii gcc-4.4 [c-compiler] 4.4.2-3The GNU C compiler ii gnupg 1.4.10-2 GNU privacy guard - a free PGP rep ii gpgv 1.4.10-2 GNU privacy guard - signature veri Versions of packages dpkg-dev suggests: ii debian-keyring [debian-mainta 2009.11.04 GnuPG (and obsolete PGP) keys of D -- no debconf information -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551118: dpkg-dev: PKG_CONFIG_LIBDIR override makes it difficult to compile build-architecture binaries when necessary
is that $host-pkg-config will indeed be automatically used for anyone who's using the PKG_CHECK_MODULES Autoconf macro (which I suspect is the majority, but certainly won't be everyone), but not for anyone who's just calling pkg-config directly. A wrapper that knows about dpkg-architecture should be able to handle that. Should we just say that if they're doing that then they need to compare build and host architectures directly, the way they're probably already doing for gcc and friends? Would this be a serious regression for Emdebian that would need to be tackled in advance? Emdebian Crush (the cross-built distribution) is already in a serious regression but this provides an opportunity for major changes whilst everything is up for grabs. Fixing this will not cause any regression in Emdebian that is not already present - the implementation of multiarch is the ideal time to do TheRightThing. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpzll42Auv1z.pgp Description: PGP signature
Bug#550252: dpkg-divert: should ignore missing files
Package: dpkg Version: 1.15.4 Severity: normal This occurs in Emdebian Grip but could also occur whenever a file that is diverted has been deleted. When the diversion comes to be updated, dpkg-divert tries to 'mv' the old diverted file without checking that it exists, 'mv' then fails and dpkg-divert errors out causing the postinst to fail. The particular problem was with dash: Setting up dash (0.5.5.1-2em1) ... mv: cannot stat `/usr/share/man/man1/sh.distrib.1.gz': No such file or directory dpkg: error processing dash (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: dash E: Sub-process /usr/bin/dpkg returned an error code (1) # touch /usr/share/man/man1/sh.distrib.1.gz Setting up dash (0.5.5.1-2em1) ... Removing `diversion of /usr/share/man/man1/sh.1.gz to /usr/share/man/man1/sh.distrib.1.gz by dash' dpkg-divert could simply ignore the missing file. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dpkg depends on: ii coreutils 7.5-6 GNU core utilities ii libc6 2.9-27 GNU C Library: Shared libraries ii lzma 4.43-14Compression method of 7z format in dpkg recommends no packages. Versions of packages dpkg suggests: ii apt 0.7.24 Advanced front-end for dpkg -- no debconf information -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Howto automate etch-lenny dist-upgrade via preseed?
On Mon, 13 Jul 2009 18:03:56 -0700 Chris Hiestand chiest...@salk.edu wrote: I have tried stfw, reading debian documentation, man pages, the debian- users mailing list, irc.debian.org #debian - all to no avail. Help would be greatly appreciated - even just an answer explaining that what I want was ill conceived or impossible. Wrong list - this isn't a dpkg issue, it is a pre-seeding issue which would mean debian-b...@lists.debian.org; dpkg has no understanding of pre-seeding. My goal is to automate the etch-lenny upgrade such that no manual interaction is needed for generic (non-special) systems. I have gotten this 95% of the way using debconf-get-selections and debconf-set- selections. But there are 2 categories of questions that I have been unable to pressed. Pre-seeding relates to first-time installations and the debconf settings need to be understood by the installer. In your case, you already have an installed system and pre-seeding is unlikely to be useful. If it does work, it is likely to be unreliable and could break on future releases because the point of pre-seeding is to support first-time installations, not upgrades. The only real option for upgrades is to set debconf to be non-interactive and require that every package sets it's own default. You can learn about that from the debconf documentation. Ask on debian-mentors for more questions on debconf. Category 1. Which services to restart after a library (eg libc6) is upgraded. There are debconf questions for this, they are just ignored when I try to set them. Because pre-seeding is bound to the installer, not dpkg. Is there anyway to preseed install_new or keep_current in relation to these files? Maybe I need to use the python or perl interfaces instead of debconf-set-selections? Pre-seeding these values is likely to break things, probably better to set debconf to just do the default, always, just as it does in the preparation of build chroots etc. See the pbuilder source code or information at Emdebian about debconf settings: http://www.emdebian.org/release/grip/a1106.html http://www.emdebian.org/svn/browser/current/host/trunk/emdebian-rootfs/trunk/emdebian.crossd#L77 DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true export DEBIAN_FRONTEND DEBCONF_NONINTERACTIVE_SEEN -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpxHcVP07PIV.pgp Description: PGP signature
Bug#532222: dpkg-dev: dpkg-vendor not listening to DEB_VENDOR correctly
Package: dpkg-dev Version: 1.15.2 Severity: normal With this vendor file: $ cat /etc/dpkg/origins/emdebian-crush Vendor: Emdebian Crush Vendor-URL: http://www.emdebian.org/crush/ Bugs: debbugs://bugs.debian.org Bugs-Package: buildd.emdebian.org Cross-Compiling: yes Grip-Build-Option: usecrush Blacklist: coreutils perl python ldap adduser Parent: Debian I get confusing results from dpkg-vendor: $ dpkg-vendor --vendor emdebian-crush --query Cross-Compiling yes (correct) $ dpkg-vendor --query Cross-Compiling; echo $? 1 (correct) $ DEB_VENDOR=emdebian-crush dpkg-vendor --query Cross-Compiling; echo $? dpkg-vendor: error: vendor Emdebian Crush doesn't exist in /etc/dpkg/origins/ 2 Huh? Emdebian Crush is a different vendor to Emdebian Grip (Crush is cross-built, Grip is not). Is there some hidden assumption that the filename must match the Vendor because the existing default file does not follow that convention, at least as far as case-sensitivity is concerned. (debian vs Debian). -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dpkg-dev depends on: ii binutils 2.19.1-1 The GNU assembler, linker and bina ii bzip2 1.0.5-1high-quality block-sorting file co ii dpkg 1.15.2 Debian package management system ii libtimedate-perl 1.1600-9 Time and date functions for Perl ii lzma 4.43-14Compression method of 7z format in ii make 3.81-5 The GNU version of the make util ii patch 2.5.9-5Apply a diff file to an original ii perl [perl5] 5.10.0-22 Larry Wall's Practical Extraction ii perl-modules 5.10.0-22 Core Perl modules Versions of packages dpkg-dev recommends: ii build-essential 11.4 Informational list of build-essent ii gcc [c-compiler] 4:4.3.3-8 The GNU C compiler ii gcc-4.3 [c-compiler] 4.3.3-10 The GNU C compiler ii gcc-4.4 [c-compiler] 4.4.0-5The GNU C compiler ii gnupg 1.4.9-4GNU privacy guard - a free PGP rep ii gpgv 1.4.9-4GNU privacy guard - signature veri Versions of packages dpkg-dev suggests: ii debian-keyring2009.05.28 GnuPG (and obsolete PGP) keys of D pn debian-maintainersnone (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532222: dpkg-dev: dpkg-vendor not listening to DEB_VENDOR correctly
On Sun, 7 Jun 2009 18:45:53 +0200 Raphael Hertzog hert...@debian.org wrote: On Sun, 07 Jun 2009, Neil Williams wrote: Is there some hidden assumption that the filename must match the Vendor because the existing default file does not follow that convention, at least as far as case-sensitivity is concerned. (debian vs Debian). Yes. Case-sensitivity is taken care of (we try files named $vendor, lc($vendor), ucfirst($vendor)), but that's the only difference allowed between the name of the vendor and the filename. That isn't true because --vendor accepts the file, DEB_VENDOR fails. There's no documentation of the origins files for now and I'm not sure what you want me to do to resolve this bug. The behaviour with DEB_VENDOR should match the behaviour with --vendor and there should be some way of handling vendor names that include spaces without needing to use quote marks when using the environment variables or --vendor options. It is inconsistent that the command line option works one way and the environment variable works another way. It would be better to look only for the matching filename and then use the value for the field from that file. If the supplied argument matches the filename, why bother cross-checking that with the Vendor: field inside the file? I would have thought that the field can be the longer, descriptive title and the filename can be a shortened version. Currently, if the file specified originally has the Vendor changed from the correct title Emdebian Crush to the corrupted form Emdebian-Crush, then dpkg-vendor works in the same way with both forms. This change should not be necessary. What is the reason for the duplicate check? -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Next upload 2009-05-18 (dpkg 1.15.1)
On Sun, 17 May 2009 16:20:41 +0200 Raphael Hertzog hert...@debian.org wrote: * Build flags env settings. Raphaël mentioned on IRC that we could wait a bit for this, but I think we rather stop exporting them now so that no more maintainers start relying on them. We can always reenable them later on if we end up deciding this is the way to go. I would rather wait a final decision on this instead of knowingly breaking packages once more. Not sure how to reach a decision, the discussion is rather slowly paced. Maybe asking a recommendation to the technical committee ? Also why should we keep the dpkg-architecture environment variables if we decide that using environment variables in not a good idea ? Because use of dpkg-architecture - by definition - is not the default and therefore that it is one way of setting the environment variables necessary for non-standard builds, i.e. cross-builds. Environment variables are core to how any package cross-builds in Debian - what needs to happen is that the standard native builds don't interfere with the cross-building environment (see #450483). The discussion centred on defaults like CFLAGS and those need to be overridden for cross-building anyway, sometimes via setting the PKG_CONFIG environment variables as a result of environment variables set by dpkg-architecture -a. How is dpkg-buildpackage -a meant to work without dpkg-architecture -a setting environment variables? The only problem that results from dpkg-architecture usage (AFAICT) is that some maintainers have got the autotools-dev advice wrong and are always setting --host as well as --build instead of just --build - that can't be fixed in dpkg anyway. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpg57hX2RIgd.pgp Description: PGP signature
Re: [RFC] [Cross Toolchain] Multiarch and sysrooted toolchain
macros to find installed software). Simon That can't work either. If the core Debian packaging tools are going to change in our favour at all, they are going to change to support multiarch - that much has been made clear repeatedly. If cross-building doesn't get up to speed then the packaging tools could change in a way that breaks all cross-builds, not just the harder corner cases. Multiarch isn't perfect for Emdebian but it is the best we are going to get, it is immeasurably better than what we have (principally because it can support future development needs) and we need to work with it and modify it to our needs. The current layout is simply not an option. It has gone as far as it can go, it simply cannot cope with forthcoming changes within dpkg or likely future changes. There is no way to make any progress with cross-building larger parts of Debian without an unsustainable mess of multiple layers of package patches, specialised tools and horrible hacks to what should be standard tools. Perpetuating the current system will only add back layer upon layer of new hacks, to replace the ones I've been working to remove, as our methods once again fall behind core Debian methods and get left to bitrot. If that happens, there will be no way to expand Emdebian Crush. A lot of progress has been made in removing old hacks from the current tools but there is nowhere left to go. The next step is to get support into dpkg - only then can any of the bugs in apt-cross and the more complex bugs in Emdebian Crush actually get fixed. That much has been inevitable from the start. I think that it is highly unlikely that Emdebian Crush will ever be able to support more than ARM or armel (i.e. one architecture at a time) *unless* the current cross-building methods are dropped - the workload is simply too high. I do not think that is acceptable. There are problems with using multiarch, yes, but the prize is infinitely more important than the difficulties. If some things need to be adapted to work with unchanged core tools then so be it - if some things still need specialised wrappers, so be it. The aim is and has always been to get the core cross-building support into the core Debian packaging tools and that means dpkg and no dpkg-cross, it means apt and no apt-cross and it means that cross-building needs to adopt and modify multiarch to the point where we can all use it, albeit with wrappers and support tools where necessary. Then, we can work on absorbing those wrappers into the new dpkg when the time comes. Multiarch is the only deal on the table and we need to make it work, even if certain features/artefacts of the current system are lost. Please don't argue the points any further, we may lose all that we have gained so far. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpHVDnRQdfoh.pgp Description: PGP signature
Re: [RFC] [Cross Toolchain] Multiarch and sysrooted toolchain
On Thu, 12 Mar 2009 10:31:03 +0100 Goswin von Brederlow goswin-...@web.de wrote: I thought mulitarch wanted: (this is making a lot more sense now.) So, updating: /usr/ |-- include/ | `-- $arch-linux-gnu/ | `-- foo.h `-- lib/ `-- $arch-linux-gnu/ `-- libfoo.so The problem, as I see it, with /usr/include/$arch-linux-gnu/foo.h is that it makes it impossible to export one entire tree of all cross-build stuff. i.e. make /usr/$arch-linux-gnu/ available and everything is in a single place. Instead, three paths need to be exported. In the end, it's two paths. One reason against /usr/$arch-linux-gnu/ was that it pollutes the/usr namespace. In my opinion that is a pretty weak argument. The directories would only be there as needed and never many. Agreed - it's also a tradition of long-standing with lots of existing tools to support it, inside and outside Debian. However, cross-dependencies need to use the multiarch methods to be included into normal Debian which makes the specialised tools either redundant or standard. I think that is a price worth paying. The objective all along has been to have Debian supporting cross-building and toolchains without specialised support. So which layout do we need for LHS? /usr/ `-- $arch-linux-gnu/ |-- include/ | `-- foo.h `-- lib/ `-- libfoo.so i.e. a complete hierarchy beneath /usr/arm-linux-gnu/ with files that are normally in /bin/ in /usr/$arch-linux-gnu/bin and files that are normally in /usr/bin/ in /usr/$arch-linux-gnu/usr/bin, similarly for lib. That will not work. You can not for example but /bin/sh into s/but/boot/ I don't think anyone wants to boot into that location, they want to be able to export it complete to another system that has also booted normally. It is only the 32bit/64bit multiarch usage where booting becomes an issue. Is there any information arround, maybe LHS, on how to setup DIR layout? Nowadays we are using non multiarch structure as: usr/$arch-linux-gnu |-- include `-- lib But what it should look like in future? /usr/include/$arch-linux-gnu? Would it be reasonable to be using a new layout like: usr/include/$arch-linux-gnu usr/ |-- include | `-- $arch-linux-gnu `-- lib `-- $arch-linux-gnu That is already standard on i386/amd64 at least. Many /usr/include/* files just include the right usr/include/$arch-linux-gnu file depending on wether __i386__ or __x86_64__ is set. gcc also looks into those dirs on its own. So yes, do use those. Is that /usr/include/$arch-linux-gnu/usr/include/foo.h ? No, just /usr/include/$arch-linux-gnu/foo.h. and /usr/lib/$arch-linux-gnu/libfoo.so ? Special case as some of binutils behave differently depending on the arch they support. That is not something that is needed distribution wide. True. Also isn't there an /usr/bin/arm-linux-gnu-objdump? Maybe just a link to /usr/arm-linux-gnu/bin/objdump? -rwxr-xr-x 2 root root 882128 2008-07-01 16:41 /usr/arm-linux-gnu/bin/objdump -rwxr-xr-x 2 root root 882128 2008-07-01 16:41 /usr/bin/arm-linux-gnu-objdump Not a symlink, but it is there. Hmm, so dpkg-cross would need to change the path to include/ for headers but not change the path for libraries? dpkg-cross does not need to change anything. First gcc needs to change. Then packages. And last dpkg/apt/aptitude. And then dpkg-cross is obsolete. This is the plan, yes. Once dpkg supports multiarch in /usr/include/$arch-linux-gnu and /usr/lib/$arch-linux-gnu/ then dpkg-cross becomes not only obsolete but counter-productive. That version of dpkg will conflict with dpkg-cross, leading to the inevitable removal of dpkg-cross from unstable. We'd have: /usr/arm-linux-gnu/lib/libfoo.so /usr/include/arm-linux-gnu/include/foo.h or /usr/arm-linux-gnu/usr/lib/libfoo.so /usr/include/arm-linux-gnu/usr/include/foo.h So current dpkg-cross behaviour: /usr/arm-linux-gnu/lib/libfoo.so /usr/arm-linux-gnu/include/foo.h Multiarch behaviour that doesn't need dpkg-cross: /usr/lib/arm-linux-gnu/libfoo.so /usr/include/arm-linux-gnu/foo.h as a conversion of /usr/lib/libfoo.so The question is /arm-linux-gnu/lib/libfoo.so l /usr/arm-linux-gnu/[usr/]lib/libbla.so /usr/arm-linux-gnu/[usr/]include/foo.h or /lib/arm-linux-gnu/libfoo.so /usr/lib/arm-linux-gnu/libbla.so /usr/include/arm-linux-gnu/foo.h It has always been a question of where to put the tripplet, not whether or not to have an extra subdir below that. Although I'm against the subdirs. No need to duplicate that this is usr. I'd agree - [usr] below $arch-linux-gnu appears redundant to me. The only difference between /lib and /usr/lib/ relates to the libraries required to boot before /usr is mounted. That reasoning doesn't apply to toolchain issues. -- Neil Williams
Re: Transition from dpkg to GNU install-info
On Thu, 12 Mar 2009 16:00:26 +0200 Guillem Jover guil...@debian.org wrote: On Wed, 2009-03-11 at 12:13:47 +, Neil Williams wrote: What I really need, in order to test properly, is a package that can trigger install-info. I admit, I'm a bit unfamiliar with triggers still - what do I need to change in a package (say coreutils) that currently contains an info document and maintainer script changes, in order to test it with a trigger created by a patch to the experimental texinfo sources above? Is it a case of: 1. create debian/install-info.triggers in the tex source above 2. create a modified coreutils (for testing in a chroot) where the info document is part of the package, not mentioned in the maintainer scripts 3. and? Neil, please hold your horses! Once dpkg provides the dummy install-info, then this is solved for you, and you don't have to do anything. Please check the transition plan on the wiki. :-) I was just experimenting. Also: * As long as the new install-info packages is not installed on your system, then it won't be triggered. * Ideally we should not need any .install-info file, if we get the remaning incomplete Info files properly fixed. Thanks, Guillem, that will be a good solution. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpGgyTS1lwnN.pgp Description: PGP signature
Re: Transition from dpkg to GNU install-info
On Wed, 11 Mar 2009 09:40:46 +0100 Norbert Preining prein...@logic.at wrote: Here immediately some questions: I can start preparing a separate install-info bin package for experimental, but - should we install GNU install-info into /usr/bin where there is ginstall-info ATM, or into /usr/sbin, where there is dpkg ii? I would suggest /usr/bin. Ok, here is a package, crude, nothing tested, but it is there: deb http://people.debian.org/~preining/TeX/ i-i/ deb-src http://people.debian.org/~preining/TeX/ i-i/ or dget http://people.debian.org/~preining/TeX/i-i/texinfo_4.13a.dfsg.1-2~exp01.dsc It does: - split install-info package off - make info depend on install-info - still ship ginstall-info - ship install-info shell script from Nicolas So all this now does is echo the command that should be used instead: texinfo-4.13a.dfsg.1$ ./debian/install-info/usr/bin/install-info /usr/share/info/coreutils.info ; echo $? /usr/bin/ginstall-info --quiet /usr/share/info/coreutils.info 0 (even if the actual info page does not exist) Is it meant to only echo the command out? In an Emdebian Grip chroot (with the current workaround replacement install-info script renamed): # dpkg --unpack /var/cache/apt/archives/coreutils_6.10-6em1_amd64.deb ; echo $? (Reading database ... 5726 files and directories currently installed.) Preparing to replace coreutils 6.10-6em1 (using .../coreutils_6.10-6em1_amd64.deb) ... /usr/bin/ginstall-info --quiet --remove /usr/share/info/coreutils.info Unpacking replacement coreutils ... 0 # dpkg --configure coreutils ; echo $? Setting up coreutils (6.10-6em1) ... /usr/bin/ginstall-info --quiet /usr/share/info/coreutils.info 0 My only concern is this: # /usr/bin/ginstall-info --quiet /usr/share/info/coreutils.info ; echo $? install-info: No dir file specified; try --help for more information. 1 and this: # /usr/bin/ginstall-info --info-dir=/usr/share/info --quiet /usr/share/info/coreutils.info ; echo $? install-info: No such file or directory for /usr/share/info/coreutils.info 1 (The reason I'm CC'd in all of this is because of #518737 dpkg: install-info should still exit zero if info document is not found) I can adapt the Emdebian Grip processes to remove the trigger file from packages like coreutils when the info document is removed, so if the intention is that the postinst will become a no-op - merely echoing the command - then this seems OK for what I need. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpDmlZoArq1r.pgp Description: PGP signature
Re: Transition from dpkg to GNU install-info
On Wed, 11 Mar 2009 10:30:12 +0100 Norbert Preining prein...@logic.at wrote: On Mi, 11 Mär 2009, Neil Williams wrote: Is it meant to only echo the command out? Uups, forgot the comment out the part in the install-info.sh. please can you do so and retry. The very first lines ;-) Change packages are on the server, version 4.13a.dfsg.1-2~exp02 Then it will fail and the Emdebian install will still break. :-( # dpkg --unpack /var/cache/apt/archives/coreutils_6.10-6em1_amd64.deb ; echo $? (Reading database ... 5726 files and directories currently installed.) Preparing to replace coreutils 6.10-6em1 (using .../coreutils_6.10-6em1_amd64.deb) ... Unpacking replacement coreutils ... 0 # dpkg --configure coreutils ; echo $? Setting up coreutils (6.10-6em1) ... install-info: No dir file specified; try --help for more information. dpkg: error processing coreutils (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: coreutils 1 and with the -dir specified, it will still break: # dpkg --configure coreutils ; echo $? Setting up coreutils (6.10-6em1) ... install-info: /usr/share/info: empty file dpkg: error processing coreutils (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: coreutils 1 This is expressly what I need to avoid happening. Now, what we could do is have the /usr/bin/install-info wrapper ignore such errors because, after all, packages should be migrating to trigger support with .install-info files and make no mention of install-info in the maintainer scripts. I can then file bugs against those packages that retain maintainer scripts listing install-info. (lintian tests would be good too.) That way, Grip can remove the info document and the trigger file together, ensuring smooth package installations for those that complete the transition. The patch would be: diff -u texinfo-4.13a.dfsg.1/debian/install-info.sh texinfo-4.13a.dfsg.1/debian/install-info.sh --- texinfo-4.13a.dfsg.1/debian/install-info.sh +++ texinfo-4.13a.dfsg.1/debian/install-info.sh @@ -51 +51 @@ -/bin/sh -c $INSTALL_INFO $options +/bin/sh -c $INSTALL_INFO --dir /usr/share/info $options || true Rendering: dpkg --configure coreutils ; echo $? Setting up coreutils (6.10-6em1) ... install-info: /usr/share/info: empty file 0 It depends how quickly we can transition all the packages listed in the existing bug report #518737 to *not* have any mention of install-info in their maintainer scripts. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518737#27 -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgp73oN7Q5uc0.pgp Description: PGP signature
Re: Transition from dpkg to GNU install-info
On Wed, 11 Mar 2009 09:40:46 +0100 Norbert Preining prein...@logic.at wrote: Ok, here is a package, crude, nothing tested, but it is there: deb http://people.debian.org/~preining/TeX/ i-i/ deb-src http://people.debian.org/~preining/TeX/ i-i/ What I really need, in order to test properly, is a package that can trigger install-info. I admit, I'm a bit unfamiliar with triggers still - what do I need to change in a package (say coreutils) that currently contains an info document and maintainer script changes, in order to test it with a trigger created by a patch to the experimental texinfo sources above? Is it a case of: 1. create debian/install-info.triggers in the tex source above 2. create a modified coreutils (for testing in a chroot) where the info document is part of the package, not mentioned in the maintainer scripts 3. and? -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpT75VoIxGc9.pgp Description: PGP signature
Re: [RFC] [Cross Toolchain] Multiarch and sysrooted toolchain
On Wed, 11 Mar 2009 14:50:19 +0100
Goswin von Brederlow goswin-...@web.de wrote:
[*]
I have been looking lately into making some cross toolchain
improvements, one of them will be to change to a sysrooted cross
toolchain, but the current layout we are using by dpkg-cross installs
relevant bits under:
DIR/{include,bin,lib,lib64}
Mainstream code expects a different layout more LHS compliant,
DIR/{usr/include,bin,lib,lib64}
dpkg-cross currently does:
/usr/
`-- $arch-linux-gnu/
|-- include/
| `-- foo.h
`-- lib/
`-- libfoo.so
$ ls /usr/arm-linux-gnu/
bin include lib
Very flat but quite simple.
I thought mulitarch wanted:
/usr/
|-- bin/
| `-- $arch-linux-gnu/
|-- include/
| `-- $arch-linux-gnu/
| `-- foo.h
|-- lib64/
| `-- $arch-linux-gnu/
`-- lib/
`-- $arch-linux-gnu/
`-- libfoo.so
?
The problem, as I see it, with /usr/include/$arch-linux-gnu/foo.h is
that it makes it impossible to export one entire tree of all
cross-build stuff. i.e. make /usr/$arch-linux-gnu/ available and
everything is in a single place. Instead, three paths need to be
exported.
So which layout do we need for LHS?
/usr/
`-- $arch-linux-gnu/
|-- bin/
|-- lib64/
!-- lib/
|-- usr/
`-- |-- bin/
|-- include/
| `-- foo.h
`-- lib/
`-- libfoo.so
$ ls /usr/arm-linux-gnu/
bin lib64 lib usr
$ ls /usr/arm-linux-gnu/usr
bin include lib
(with or without a symlink of /usr/arm-linux-gnu/usr/lib64
to /usr/arm-linux-gnu/usr/lib) ?
i.e. a complete hierarchy beneath /usr/arm-linux-gnu/ with files that
are normally in /bin/ in /usr/$arch-linux-gnu/bin and files that are
normally in /usr/bin/ in /usr/$arch-linux-gnu/usr/bin, similarly for
lib.
Is there any information arround, maybe LHS, on how to setup DIR
layout?
Nowadays we are using non multiarch structure as:
usr/$arch-linux-gnu
|-- bin
|-- include
|-- lib
`-- lib64
But what it should look like in future? /usr/include/$arch-linux-gnu?
Would it be reasonable to be using a new layout like:
usr/include/$arch-linux-gnu
That is already standard on i386/amd64 at least. Many /usr/include/*
files just include the right usr/include/$arch-linux-gnu file
depending on wether __i386__ or __x86_64__ is set. gcc also looks into
those dirs on its own. So yes, do use those.
Is that /usr/include/$arch-linux-gnu/usr/include/foo.h ?
|-- bin
All binaries are assumed to do the same thing no matter what
architecture they are compiled for. As such there is no need to have
the same binary compiled for different archs at the same time. Also
any change here would play havock with shebang lines.
binutils-multiarch puts stuff in /usr/$arch-linux-gnu/bin/
$ ls /usr/arm-linux-gnu/bin/
ar as ld nm objcopy objdump ranlib strip
I am missing some papers on multiarch, are there any kind of
information out there.
You are missing the actual multiarch or cross-compile library dirs:
/usr/$arch-linux-gnu/lib (cross-compile)
/usr/lib/$arch-linux-gnu (multiarch)
I still haven't heart a good reason why multiarch can't use the
cross-compile dirs as the libraries for each are ment to be
interchangable (and in fact dpkg-cross demonstrates that already).
Hmm, so dpkg-cross would need to change the path to include/ for
headers but not change the path for libraries?
We'd have:
/usr/arm-linux-gnu/lib/libfoo.so
/usr/include/arm-linux-gnu/include/foo.h
or
/usr/arm-linux-gnu/usr/lib/libfoo.so
/usr/include/arm-linux-gnu/usr/include/foo.h
?
I thought the question was whether we would have:
/usr/lib/arm-linux-gnu/lib/libfoo.so
or
/usr/lib/arm-linux-gnu/usr/lib/libfoo.so
or
/usr/arm-linux-gnu/usr/lib/libfoo.so
or the current
/usr/arm-linux-gnu/lib/libfoo.so
as a conversion of /usr/lib/libfoo.so
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgp9tgMdTd7tZ.pgp
Description: PGP signature
Bug#518719: dpkg needs unpack support that does not run any maintainer scripts
Package: dpkg
Version: 1.14.25
Severity: normal
dpkg --unpack needs to be able to work without executing any maintainer
scripts, just
extracting the data.tar.gz, decompressing the control.tar.gz, moving maintainer
scripts
to the var/lib/dpkg/info/ directory, handling var/lib/dpkg/status and
var/lib/dpkg/available
and leaving the status of the package as Status: install ok unpacked
This mode is particularly important for debootstrap usage when the archives are
for a
different architecture to the host system. I've had to implement two versions
of this
support, one in shell and one in perl, for Emdebian. The main objective is to
achieve
a debootstrap that leaves an almost complete filesystem with every file in
place and
only needing 'dpkg --configure -a' to be run on the actual machine.
Emdebian Grip has a particular need for this support, so that the debootstrap'd
directory
can be packed into a .tar.gz *without* needing to carry large numbers of .deb
packages in
var/cache/apt/archives/. It seems utterly pointless that 24Mb of .debs are
needed merely so
that the maintainer scripts can be created and executed before removing all the
.debs on
a machine where file I/O can be slow and space for the extra 24Mb is not
necessarily
available. It gets worse when such machines need to have more than a basic
debootstrap
in the installation image, e.g. when the user needs to make a complete
installation image
that includes a full XFCE GUI without any .debs in the tarball.
If the new mode could simply detect that the architecture of the .deb does not
match the
architecture of the host system (i.e. the system outside the chroot), it could
conceivably
do everything except executing any code/scripts installed by the package. This
would also
require that the unpack mode would be closer to the extract support that is
able to write
files to a nominated directory - i.e. running dpkg from outside the chroot and
writing to
files in $PREFIX/var/lib/dpkg etc.
Requiring that a directory '$PREFIX' is specified and that the $PREFIX cannot
be '/' should
minimise problems of this mode being used in a normal filesystem. As such,
maybe an option
to dpkg -e would be more appropriate than a change to dpkg --unpack.
This is the test code (perl version) that adds to the functionality available
with dpkg -e:
(I don't consider it fully debugged, it is merely here to show the steps that
Emdebian
currently needs due to the lack of this functionality within dpkg itself. The
final code
will be executed from the top level of what will become the chroot, but never
from '/'
and will repeat over each archive in no particular order.)
#!/usr/bin/perl
# $dir will eventually hold a prefix that cannot be /
$dir=;
$cachedir=var/cache/apt/;
$libdir = var/lib/apt/; # lists
$etcdir = etc/apt/; # sources
$dpkgdir = var/lib/dpkg/; # state
force_unpack;
exit 0;
sub force_unpack
{
my %unpack=();
$deb = wget_1.11.4-2_armel.deb;
{
print I: Extracting $deb...\n;
system (ar -p \./${cachedir}archives/$deb\ data.tar.gz |
zcat | tar -xf -);
my $ver=`dpkg -f ./${cachedir}archives/$deb Version`;
my $pkg=`dpkg -f ./${cachedir}archives/$deb Package`;
chomp ($ver);
chomp ($pkg);
print - Unpacking control data...\n;
mkdir (tmp/listing);
system (ar -p \./${cachedir}archives/$deb\ data.tar.gz
tmp/listing/data.tar.gz);
my $datatar = `tar -tzf tmp/listing/data.tar.gz`;
my @lines = split(\n, $datatar);
open (LIST, ${dpkgdir}info/${pkg}.list);
foreach my $l (@lines)
{
chomp ($l);
$l =~ s:^\.::;
$l =~ s:^/$:/\.:;
$l =~ s:/$::;
print LIST $l\n;
}
close (LIST);
# this needs to use mktemp -d and only remove that dir.
system (rm -rf tmp/*);
system (dpkg -e ./${cachedir}archives/$deb tmp/);
opendir (MAINT, tmp);
my @maint=grep(!m:\.\.?:, readdir (MAINT));
closedir (MAINT);
open (AVAIL, ${dpkgdir}available);
open (STATUS, ${dpkgdir}status);
foreach my $mscript (@maint)
{
rename tmp/$mscript, ${dpkgdir}info/$pkg.$mscript;
if ( $mscript eq control )
{
open (MSCRIPT, ${dpkgdir}info/$pkg.$mscript);
my @scr=MSCRIPT;
close (MSCRIPT);
my @avail = grep(!/^$/, @scr);
print AVAIL @avail;
print STATUS @avail;
Bug#518737: dpkg: install-info should still exit zero if info document is not found
Package: dpkg Version: 1.14.25 Severity: normal Various GNU packages handle info documents in maintainer scripts via install-info but Emdebian Grip removes those info documents, just as it removes manpages and other documentation, to save space. The files are removed from the packages and the reduced packages made available via http://www.emdebian.org/grip to handle bandwidth and temporary space issues on the devices running Grip. Currently, Grip needs to replace install-info from dpkg with an empty script because install-info halts the entire installation if a single info document is missing. The packages themselves have the Emdebian version string (em[0-9]) suffix but have no changes to the maintainer scripts (to maintain compatibility with Debian). To simplify Grip installations, install-info needs to not halt the installation of a package merely because the info document has been removed from the package. A warning or message is not needed either - users of Emdebian Grip know that info documents and manpages are not going to exist in the Grip packages. Retaining binary compatibility with Debian does mean that individual packages can be installed from Debian where the user wants to have the extra files and apt-pinning can do the rest. update-alternatives has now gained this support and it would be much appreciated if install-info could be quiet about missing info documents whilst still supporting those Debian packages that the user may still wish to install. This would make info management as simple as manpage management where man-db really doesn't care if a package used to contain a manpage but does not contain one anymore, it just does the right thing and carries on without halting the installation. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dpkg depends on: ii coreutils 7.1-2 The GNU core utilities ii libc6 2.9-4 GNU C Library: Shared libraries ii lzma 4.43-14Compression method of 7z format in dpkg recommends no packages. Versions of packages dpkg suggests: ii apt 0.7.20.2 Advanced front-end for dpkg -- no debconf information -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518719: dpkg needs unpack support that does not run any maintainer scripts
On Sun, 8 Mar 2009 16:29:29 +0100 Raphael Hertzog hert...@debian.org wrote: On Sun, 08 Mar 2009, Neil Williams wrote: dpkg --unpack needs to be able to work without executing any maintainer scripts, just extracting the data.tar.gz, decompressing the control.tar.gz, moving maintainer scripts to the var/lib/dpkg/info/ directory, handling var/lib/dpkg/status and var/lib/dpkg/available and leaving the status of the package as Status: install ok unpacked You're asking us to support crude hacks… --unpack is not --unpack if it doesn't call the preinst/prerm. --unpack cannot operate if the architecture of the .deb does not match the architecture of the system. It is a fundamental requirement of any cross-architecture, even multi-architecture, system that no binaries are executed. It isn't a crude hack, it is a middle-stage between --unpack and --extract || --control and it underpins all operations in Debian that involve multiple architectures. It is still up to dpkg to sort out everything else via 'dpkg --configure -a' run on the target machine. This is an area of intense interest and activity around Debian, it would be a shame for dpkg to assume that native is the only supported system, particularly around installation support. While I understand your need, I'm not convinced that dpkg has to be modified to support this use case. After all policy compliant packages have the right to expect in their postinst that the prerm/preinst have been run. That will still happen, however, not until the binaries have been copied onto a system capable of executing them. The new mode would merely add a delay between tar -xzf and running the preinst sufficient to allow the files to be copied to a suitable system within that delay. All of these situations are based on debootstrap type environments where --force-depends --force-configure-any, --force-conflicts, --force-overwrite and --ignore-depends are likely to be in use. I don't mind if this new mode becomes a --force-foo *and* is only operative if the system architecture does not match the .deb architecture, i.e. needs to be used from outside what will become a chroot. I fail to see why we would want to allow that. Hacks are okay to get something done, but I wouldn't want to officialize hacks by integrating them in dpkg itself. True, however there is more to dpkg than native-only. I would suggest you to look into using virtualisation or other similar solution instead. On an iPAQ?? Making cross-installation require Xen is a bizarre idea. That's just my opinion. Maybe Guillem has some nicer approach to suggest, we'll see. OK. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpxWQjZEai7Z.pgp Description: PGP signature
Bug#518737: dpkg: install-info should still exit zero if info document is not found
On Sun, 8 Mar 2009 16:46:53 +0100 Raphael Hertzog hert...@debian.org wrote: On Sun, 08 Mar 2009, Neil Williams wrote: The packages themselves have the Emdebian version string (em[0-9]) suffix but have no changes to the maintainer scripts (to maintain compatibility with Debian). To simplify Grip installations, install-info needs to not halt the installation of a package merely because the info document has been removed from the package. A warning or message is not needed either - users of Emdebian Grip know that info documents and manpages are not going to exist in the Grip packages. Retaining binary compatibility with Debian does mean that individual packages can be installed from Debian where the user wants to have the extra files and apt-pinning can do the rest. update-alternatives has now gained this support and it would be much appreciated if install-info could be quiet about missing info documents whilst still supporting those Debian packages that the user may still wish to install. The plan is always to get rid of install-info inside dpkg, so asking us for this change is not the right long-term solution. (And contrary to update-alternatives, I don't think such a change make sense) Any timescales? Will the package containing install-info become Priority: required or will all packages using info documents need to be changed to check for install-info in their postinsts? I would really suggest that you design a solution that doesn't require the postinst snippet at all. A simple solution could be: - have a package install-info register a file trigger on /usr/share/install-info/ - have other packages provide a .install-info file in that directory that tells how install-info should be called - add a dh_installinfo helper to automatize the installation of this file - have info readers depend on the new install-info package Opinions ? One thing I cannot do is modify the relevant debian/rules of the packages concerned because Grip does not rebuild any packages, in order to retain binary compatibility with Debian. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgp9PN1ImoUnP.pgp Description: PGP signature
Bug#518719: dpkg needs unpack support that does not run any maintainer scripts
On Sun, 8 Mar 2009 17:30:02 +0100 Raphael Hertzog hert...@debian.org wrote: On Sun, 08 Mar 2009, Neil Williams wrote: I would suggest you to look into using virtualisation or other similar solution instead. On an iPAQ?? Making cross-installation require Xen is a bizarre idea. As I understand, you want to create a root filesystem with dpkg not on the target device but on your devel machine. Yes, because unpacking .debs onto the target machine takes huge amounts of time compared to merely running 'dpkg --configure -a' after copying the filesystem across. Also, requiring that the .debs exist in the tarball containing the filesystem makes things even more difficult by making the install into a two-stage process. (Unpack the base system on the device, remove all the .debs then download/copy/obtain the rest of the system and unpack it all over again.) If debootstrap took 3 hours per install, would you not prefer a system that turns that into a 15 minute process? All for the sake of delaying the execution of maintainer scripts? So maybe running dpkg in a qemu host emulating the architecture of the iPAQ would be a solution. We rejected qemu (or any emulator) long ago - the system needs to be built from source without emulators. Why should dpkg require that cross-installs require emulators or Xen? It's just unpacking .debs, why should that require an emulator? -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpFI1Dda9fco.pgp Description: PGP signature
Re: Merging dpkg-cross into the dpkg source
On Mon, 23 Feb 2009 22:46:24 +1030 Ron r...@debian.org wrote: On Sun, Feb 22, 2009 at 12:23:22PM +, Neil Williams wrote: The rationale is, things like arm and uclibc have many possible variants, and we cannot possibly provide them all by default. archtable.d/ was meant for this support - although the name does tend to indicate only one side of the table but that can be changed. Ok, I'm probably a bit confused still about where everything is planning to move to, I had thought dpkg-cross was going to mostly disappear, but if it fits better there, I'm not really fussy about what it's called. The dpkg-cross executable will disappear - the issue is where to place the configuration support files and the mechanisms to support variants, as you and others require. As for planning, umm, what planning? :-) This is being discussed in order to make a plan but the main hindrance is just how multiarch will actually work. Without the detail of the multiarch implementation, we can't really make a detailed plan for dpkg-cross itself. However, I feel that the cross-config.$arch and associated archtable.d/ support is orthogonal to what actually happens to dpkg-cross and multiarch. The two issues both need to be resolved but the detailed implementation of dpkg-cross within a multiarch capable dpkg will need to work with a realistic multiarch implementation *and* a working implementation of the cross-config and archtable.d/ support. So, in some ways, we can discuss and plan elements of such support in advance of a detailed plan for multiarch itself. 1. Do you need to alter ostable, archtable and tripletable or can we arrange a method to host all three in one file/directory? Combining the tables requires an element of rigour to the definitions and should prevent overlaps or omissions. I need to alter ostable and triplettable for the arm-uclibc builds. I also don't really mind how that is done, but it makes sense to me that whatever mechanism we choose should be basically similar to what dpkg currently uses. ie. I should be able to create 'unofficial' archs of my own on demand, but those same definitions should also be able to be moved to dpkg later should this become an 'official' arch, without any visible difference to the tools using it. OK. I think we worked out a basic form for how the triplets should be composed previously that would work 'universally'. We'd definitely want to shake that down again and provide it as a guidance for people customising this. A Wiki page would be suitable, linked from http://wiki.debian.org/dpkg and http://wiki.debian.org/Embedded_Debian. 2. Do you need dpkg to support this directly or will support via other tools be sufficient? (i.e. as now with archtable and dpkg-cross). If so, which tools? (bearing in mind that dpkg-cross itself will disappear). Basically, I need `dpkg-architecture -a $myarch` and dpkg-buildpackage -a to work as if $myarch were a 'real' arch in the os/triplet tables. That's the crux of the problem. The current method relies on you querying the architecture values via a wrapper like dpkg-cross or a script using libdebian-dpkgcross-perl. To handle this inside dpkg-architecture will need the .d/ directory to be supported by dpkg directly. We may want to set up some sort of 'registrar', where people can publish names that are in use, to avoid accidental conflicts, but that could be as simple as a wiki page that people can update with the names they are using. I don't expect that will be a huge problem in the near future, but as more people do this there may be value in something like that. (in the same sense that wnpp helps people avoid conflicting package names for works in progress) Agreed. A Wiki page is probably a good start - scripts to parse the various values can be written later. While we may provide one or more of them for general use, specialised devices are each going to want to enable or disable different (sometimes incompatible) features. To do so, you may well need to also modify the cross-config.cache values as these provide the results of macros run by autoconf based on a standard Debian system. If uClibc or any other variant changes the behaviour of functions compared to standard glibc and standard Debian, the variant would also need to take account of these changes. Yes, that's something that people defining a 'new arch' would also need to take care of. So far the things I need don't depend too heavily on that, but you couldn't build all of the packages in the distro without it. Unless I'm missing something this should work without changes though, since you have a unique triplet for each new arch. It's just a part of the cross environment you need to bootstrap when kicking off a new arch variant. Yes, although care will be needed to prevent unnecessary duplication if the cross-config.cache file needs modification for particular architecture
Re: Merging dpkg-cross into the dpkg source
On Fri, 20 Feb 2009 16:08:45 +1030 Ron r...@debian.org wrote: On Thu, Feb 19, 2009 at 10:24:34AM +, Neil Williams wrote: On Thu, 19 Feb 2009 08:47:47 +0200 Guillem Jover guil...@debian.org wrote: 3. Any renaming issues or other changes required in the current package? There's the arch name divergences, from the IRC logs, I think most should just be removed and the ones from dpkg-architecture used instead. If those need fixing then we should check for each specific case. The only remaining values are: armeb: armeb-linux-gnueabi hurd-i386: i386-gnu#XXX This differs from dpkg-architecture s390x: 's390-linux-gnu' #XXX This differs from dpkg-architecture openbsd-i386: 'i386-openbsd' #XXX This differs from dpkg-architecture freebsd-i386: 'i386-freebsd' #XXX This differs from dpkg-architecture darwin-i386: 'i386-darwin', #XXX This differs from dpkg-architecture win32-i386: 'i386-cygwin' Compare in each case with the output of: $ dpkg-architecture -a$key -qDEB_HOST_GNU_TYPE 2/dev/null The main effect is to allow i386 in the GNU type where dpkg insists on changing it to i486. The mechanism itself was intended to support uClibc architectures - Simon? The other issue related to this was some mechanism to permit local definitions to be maintained in ostable and triplettable. /etc/dpkg-cross/archtable.d/ could be extended for that purpose - it's a much better idea than the legacy method of hardcoding such variants into dpkg-cross itself. It was originally designed for this situation, so if it isn't suitable, it needs to be fixed. See #447427 The rationale is, things like arm and uclibc have many possible variants, and we cannot possibly provide them all by default. archtable.d/ was meant for this support - although the name does tend to indicate only one side of the table but that can be changed. The questions are: 1. Do you need to alter ostable, archtable and tripletable or can we arrange a method to host all three in one file/directory? Combining the tables requires an element of rigour to the definitions and should prevent overlaps or omissions. 2. Do you need dpkg to support this directly or will support via other tools be sufficient? (i.e. as now with archtable and dpkg-cross). If so, which tools? (bearing in mind that dpkg-cross itself will disappear). Maybe what we shall end up doing is migrating the package conversion routines from /usr/bin/dpkg-cross into dpkg|dpkg-dev using multi-arch support and implementing the architecture-support configuration of dpkg-cross as a configuration package that handles the static data like cross-config. $arch, archtable.d/ and the rest in /etc/. The only issue for me is about the status of multi-arch in Debian - where are we at? While we may provide one or more of them for general use, specialised devices are each going to want to enable or disable different (sometimes incompatible) features. To do so, you may well need to also modify the cross-config.cache values as these provide the results of macros run by autoconf based on a standard Debian system. If uClibc or any other variant changes the behaviour of functions compared to standard glibc and standard Debian, the variant would also need to take account of these changes. Since the majority of the 2000 arm machine types now registered with the linux kernel are in some way or another specialised, this is very desirable from the point of view of manufacturers trying to get the best performance from their devices using an OS built from Debian sources, and cross tools on a Debian host workstation to build it all. Then what we need is a test suite for these systems whereby we get the results of the ./configure tests performed by each package currently supported by /etc/dpkg-cross/cross-config.cache or putting files into /etc/dpkg-cross/cross-config.d/ in a native build and then reporting back on any changes in the cached values. There is a prototype script to do that kind of thing in emdebian-tools already, emcache. Patches to modify it for such a test suite would be welcome. ;-) Delineating them by triplets works well as the toolchains and autoconf all support this cleanly without any extra hackery required. I've been using a specialised arm/uclibc toolchain like this with our products since about the middle of 2007 and it's been working really nicely. The only thing I need to keep tweaking is to add: ostable: uclibc-linux linux-uclibclinux[^-]*-uclibc triplettable: uclibc-linux-cpuuclibc-cpu ... every time I update dpkg and they get overwritten again. OK, so which executables and which routines need to call these values - would support inside dpkg-cross be sufficient or are you seeking for dpkg to support /etc/dpkg/arch.d/ instead? Most of the support you need does exist but it sounds like it needs to be optimised. There is no need to alter /usr/share/dpkg/ostable or /usr/share
Re: Please test master branch and update-alternatives in particular
On Sun, 22 Feb 2009 23:24:15 +0100 Raphael Hertzog hert...@debian.org wrote: Hello, as some might have noticed I largely rewrote update-alternatives, corrected bugs and implemented most features requested in the BTS. Hmm, maybe I left it too late to put my own request into the BTS for update-alternatives. :-( With any change of this importance, and despite the (relatively extensive) test-suite which covers most important actions, I expect that we'll find small problems, in particular in the user interface or in messages displayed. Please compile and run the dpkg in the master branch and report any problem you might have with update-alternatives. TIA. Something that may not have come up before, I'm looking for a way for update-alternatives to fail gracefully if things like man pages simply don't exist on the filesystem. (Emdebian doesn't have manpages but the Grip flavour does have other targets of alternatives - Crush drops alternatives completely.) Currently, I'm using a config package to replace the current update-alternatives with a minor change that brute forces things to make update-alternatives exit with zero instead of 2 in the quit subfunction. Yes, I know, it's a hack but I needed to get it fixed to get Grip working and planned on getting a sane implementation in a few weeks time and bringing it to dpkg at that time. Just from the bare outline, is there a good way of implementing a fix for this? I can create a file in /etc/ that update-alternatives notices in order to change behaviour, that seemed like the best initial approach. (Doesn't have to be in /etc/ actually.) Does update-alternatives need to fail noisily / die if the target of an alternative does not exist? (thereby breaking the install). Has this been looked at before? -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpNdiHAvdKNV.pgp Description: PGP signature
Re: Merging dpkg-cross into the dpkg source
On Thu, 19 Feb 2009 08:47:47 +0200 Guillem Jover guil...@debian.org wrote: 3. Any renaming issues or other changes required in the current package? There's the arch name divergences, from the IRC logs, I think most should just be removed and the ones from dpkg-architecture used instead. If those need fixing then we should check for each specific case. The only remaining values are: armeb: armeb-linux-gnueabi hurd-i386: i386-gnu#XXX This differs from dpkg-architecture s390x: 's390-linux-gnu' #XXX This differs from dpkg-architecture openbsd-i386: 'i386-openbsd' #XXX This differs from dpkg-architecture freebsd-i386: 'i386-freebsd' #XXX This differs from dpkg-architecture darwin-i386: 'i386-darwin', #XXX This differs from dpkg-architecture win32-i386: 'i386-cygwin' Compare in each case with the output of: $ dpkg-architecture -a$key -qDEB_HOST_GNU_TYPE 2/dev/null The main effect is to allow i386 in the GNU type where dpkg insists on changing it to i486. The mechanism itself was intended to support uClibc architectures - Simon? There's also the ELF table, but detect_arch does not seem to be used anywhere in the pkg. If it's not really needed then just drop it. It used to be used in emdebian-tools but a lintian check script proved to be a better method. I'll drop detect_arch and the ELF table in the next version of dpkg-cross - along with other legacy code. 4. Which package should take on the hierarchy of cross-configuration conffiles in /etc/dpkg-cross/ ? The autoconf config.cache files are not really specific to dpkg, so it might make more sense to provide them somewhere else. They could be used to speed up a bit normal builds as well. It would also make sense to rename them to contain the gnu-triplet instead of the Debian arch name. That can be done - I'll do some testing. For this to work with native packages, something (probably dpkg-buildpackage) has to set the CONFIG_SITE environment variable that points to the relevant file (all of which are actually shell scripts). There is also the /etc/dpkg-cross/cross-config.d/ directory which is intended to be used by packages to drop in their own files, e.g. orbit2. The directory could have package-specific files to replace the values in cross-config.cache. I haven't made that known to the packages involved yet as there are a few issues with ensuring that values remain package-specific. I'll continue working on those. One of the problems I mentioned was that if not explicitly specified configure by default tries to load them from the default prefix, which tends to be /usr/local or from the prefix specified on the command line, which might not be always the same place for all builds. Which makes me think that dpkg-buildpackage needs to set an explicit location in CONFIG_SITE if these are going to be used for native builds. Currently, emdebuild sets it for cross-builds. Where do we start? gcc is still lacking some patches to properly support building using the multiarch dirs, Aurélien Jarno said he would be preparing some patches for which Matthias Klose agreed to include (at least agreed with the idea behind the patches). Once we have a working toolchain we can start drafting the details for the implementation in the packaging level, and we'll be able to test stuff easily. Although, there's already some previous implementation work from at least Hugo Mills and Tollef Fog Heen that I'm aware of. OK. Thanks Guillem. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpIaCd6s1F7T.pgp Description: PGP signature
Merging dpkg-cross into the dpkg source
dpkg-cross 2.4.0 is now in unstable and has had a lot of outdated cruft removed during the Lenny freeze. I'd like to start the process of removing dpkg-cross itself and providing all functionality via dpkg/dpkg-dev. Questions: 1. Should dpkg-cross remain as a discrete executable or as functionality of another executable in dpkg or dpkg-dev? 2. How to retain the *very* useful default cross-building architecture and associated debconf support, depending on the answer to Q1. 3. Any renaming issues or other changes required in the current package? 4. Which package should take on the hierarchy of cross-configuration conffiles in /etc/dpkg-cross/ ? 5. What needs to happen to the perl module (currently Debian::DpkgCross) - apart from the pending removal of all legacy code (already marked as such in the module). I'd like to make as many of these changes as I can during the 2.4.x series, leaving one final upload of dpkg-cross 2.5.0 in a state that can be easily merged into dpkg. Once there is a clear path for dpkg-cross, I'll be moving on to seeking the migration of apt-cross into apt which is a (theoretically) harder task as I need to convert that from perl to C++. If there is a desire for dpkg-cross functionality to be C rather than perl, I can cope with that - depends what we want to achieve. Where do we start? -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpoqF0xMiOtn.pgp Description: PGP signature
Re: Fixing info in Debian
On Sun, 21 Dec 2008 17:56:23 + Sam Morris s...@robots.org.uk wrote: A while ago, Nicolas François announced plans to fix the dpkg and info packages so that they would work together and user commands such as 'info pr' (as documented in various manpages throughout Debian) would work again. But #139569 has not seen any updates since then, and the info command still doesn't work. I'm wondering if anyone is still working on this bug? The same problem exists now as when the bug report was last discussed, except it is now a different release - Lenny. If this had been raised a year ago . . . Try again in 6 months time? -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpsG6hSq08mv.pgp Description: PGP signature
Bug#139569: Fixing info in Debian
On Sun, 21 Dec 2008 17:56:23 + Sam Morris s...@robots.org.uk wrote: A while ago, Nicolas François announced plans to fix the dpkg and info packages so that they would work together and user commands such as 'info pr' (as documented in various manpages throughout Debian) would work again. But #139569 has not seen any updates since then, and the info command still doesn't work. I'm wondering if anyone is still working on this bug? The same problem exists now as when the bug report was last discussed, except it is now a different release - Lenny. If this had been raised a year ago . . . Try again in 6 months time? -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpj6dU5SujoB.pgp Description: PGP signature
Re: help to make a .deb package needed till monday
On Fri, 12 Dec 2008 21:16:01 +0100 M. Peterson petersonm...@googlemail.com wrote: we need help to make a .deb package out of a source for linux binary http://sourceforge.net/project/showfiles.php?group_id=233927package_id=299091 Wrong list. Ask on debian-ment...@lists.debian.org but note that there cannot be any expectation that any help would be available within a specific deadline. Everyone is a volunteer, no-one can say whether anyone will be able to help you. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpHR9byoNDoD.pgp Description: PGP signature
Re: Thoughts about tdebs
On Wed, 3 Dec 2008 09:12:46 +0100 Raphael Hertzog [EMAIL PROTECTED] wrote: BTW, it was Eddy Petrisor, not Eric - typo. Sorry Eddy. (Thanks, Christian.) On Tue, 02 Dec 2008, Neil Williams wrote: It is a very sizable special case, though, and growing thanks to the tireless translation efforts within and beyond Debian. This is why the consensus at the meeting seemed to be to get this right even if it means having to implement some special casing. Raphael - I think you've missed some of the purpose behind TDebs and if that is a fault of the current draft TDeb spec, then I would value your comments on how to fix it. I hear the size problem that Emdebian is facing but Tdeb is not the right solution for this either IMO. We should rather aim at having some DEB_BUILD_OPTIONS or something similar to instruct the build process to create the minimalist package that you need instead of dropping the translation entirely from the original .deb. We already have DEB_BUILD_OPTIONS to instruct the build process to create the minimalist package but those don't meet the need for TDebs. It isn't the translation it is dozens of translations per package - a single package can contain 30 or 40 .mo files, between 7k and 30kb each. An embedded device does not need all the translations, it needs one, two, maybe four or five at most, carefully matched against the locales supported on that one specific device. The rest are a complete waste of storage because storage space is not cheap. Emdebian users need control over which translations are installed - absolute control - without bloating the download sizes of the packages themselves. Therefore, Emdebian Crush splits out each .mo file into a dedicated .tdeb package and provides tools to match the package against the supported locales and the installed package list. No other component of a Debian package needs as much specialised code - manpages, other docs, all those can be dumped out of the package without any other considerations. Package names can be changed to reflect changes in --enable-foo to --disable-foo using DEB_BUILD_OPTIONS to attain reductions in the sizes of the actual binaries and (more importantly) the dependency chain of those binaries, other DEB_BUILD_OPTIONS can drop README and TODO etc., but translations are special. The current TDeb specification also allows for Debian users to have a similar level of control over what actually gets installed - albeit without the ability to reduce the size of the total download. That's OK because Debian doesn't need to care about the size of the download via apt-get etc. - Emdebian does. TDebs are a specialised solution to one side of the need for smaller packages but Emdebian has other ways of reducing the size of the rest of the package. I don't want to handle translations as just another component of a package, I want a solution that works as a translator. I have a host of other methods for reducing the package size, that is only part of the goal for tdebs. You can always continue to use Tdebs to distribute the translation that you need while installing the minimalistic .deb. That is precisely what we already provide. Minimalised .debs (rebuilt using cross-build support or repackaged using dpkg support) with TDebs in a separate repository and tools that allow users to manage the actual translations that get installed. TDebs are a solution for translations, not for the creation of the minimalistic .deb - however, once you have a set of TDebs for a package, it makes no sense to retain any .mo files in the .deb. Actually making the remainder of the .deb smaller then comes down to use of DEB_BUILD_OPTIONS. If the idea becomes separated from translations, automated creation of TDebs by translation review teams would be compromised, difficulties in re-assembling the source to ensure that subsequent uploads retain the intervening translation updates become even more complex and the drive to deliver TDebs starts to wane. (Personally, I am also not at all convinced that ftp-master would consider partial debs as a viable option.) I'm sorry but the technical choice has little to do with the ability of translation teams to create .tdeb. Then what is the point? TDebs are all about the translation teams creating .tdeb - without that the whole thing is pointless. The technical choice must rely on the needs of the translation teams. A significant reason for adopting TDebs in Debian is to make it easier and less intrusive for translations to be updated in a release freeze - to allow Christian a better method than doing source NMU's on every package using debconf when everything else is meant to be frozen. It isn't a good idea to keep rebuilding binaries just to update the templates file - TDebs solve that problem. It is a specialised problem and TDebs are a specialised solution. If the technical choice does not consider the needs of the translation teams in deciding how to allow
Re: Thoughts about tdebs
On Wed, 3 Dec 2008 14:28:58 + Mark Brown [EMAIL PROTECTED] wrote: From what I understand of your idea, you seem to think about translations mainly as updates. While it is one of the goals to enable translation-only updates, it is not quite obvious to me what your proposal has to offer in terms of splitting translations out of the debs, which is an explicit goal. Also, the proposal specifically aims at limiting the amount of data that the archive and apt have to handle. Surely translations can be modeled as updates to translationless .deb files (ie, you have a .deb with no translations and then patch that package to add the translations)? Why patch the package? Why not simply put a TDeb alongside the translationless Debian package? The internal layout of the TDeb is important to the overall usefulness of TDebs in general. Updates to the TDeb then simply replace the previous TDeb, leaving the .dsc and the rest of the (signed) Debian files completely unchanged. AFAICT it is not possible to patch a binary debian package - you lose all the benefit of signing the .dsc in the first place. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpxlqSVXll3i.pgp Description: PGP signature
Re: Thoughts about tdebs
translations. http://www.emdebian.org/emdebian/flavours.html Whatever experiment you might have done within Emdebian, I will not trust any design decision that lacks a (serious) rationale and explanations of why the alternatives are not viable. I can understand that, but I offer a challenge in response - I will not be charitable to changes in design that lack the testing and documentation even currently available for TDebs. Ideas are fine but this is already a working implementation with a long history - and existing approval from various teams in Debian who would need to be considered in any design changes. Show me some code that works to meet all the criteria required for TDebs and I'll consider it more carefully. Show me code that meets with the requirements of ftp-master and i18n and I'll be more interested. What's good for one is good for the other. http://www.emdebian.org/emdebian/langupdate.html http://www.emdebian.org/locale/search.php (That said, it's only my opinion and I'm not the one that maintains the C part of dpkg) There will need to be minor changes in dpkg-dev too - dpkg-gencontrol.pl only needs a minor tweak (see http://git.debian.org/?p=users/codehelp/dpkg.git;a=commit;h=f7e88a887f4a7e3a9d6b8cbfbfef561a3533a5c6 and http://people.debian.org/~codehelp/tdeb/ch4.html) Other changes are needed in devscripts and a few other packages. The biggest changes are in the archive, hence ftp-master was approached and the design altered substantially in discussion with ftp-master and i18n teams during DebConf8 - this much was inevitable as all parties accept that Emdebian TDebs cannot be implemented in Debian without changes to the numbers of packages generated. Those changes are now in place. The changes for dpkg, by comparison, are small. In many ways, the scope of the changes within dpkg are dwarfed by the scale of changes required in the archive and elsewhere and those changes, as I said above, are already agreed with the relevant teams. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgp4SHTwP126A.pgp Description: PGP signature
Re: Thoughts about tdebs
is translation, building from the embedded implementation. As I see it, partial debs are not useful within Debian but for deployments of Debian - e.g. I've been asked before about kiosk type implementations where there is a need to only update those parts of the package that have actually changed in the latest release - many Debian revisions change only a single file and many of those have absolutely no effect on the compiled binaries or actual functionality of the package. This has little benefit for Emdebian - what we need are smaller packages in smaller repositories containing everything necessary and no bloat. Actually, from my perspective, your idea is far from simple and seems to be a lot more complex than anything so far agreed with ftp-master. I think this would be better handled within what we have by deployment of dpkg classes to allow arbitrary selection of package components. That is not the same as the locale root components within a TDeb, your suggestion is far more general and needs a different solution. TDebs can use dpkg class support once available but the tdeb is a special case (just as a udeb is a special case). In essence, it is the old problem of enabling a query interface (which file do you want from this package?) and always getting a different answer depending on which user you ask. Maybe partial debs would be useful to other users as a layer on top of dpkg classes but partial debs would not be suitable for what we need from TDebs. From what I understand of your idea, you seem to think about translations mainly as updates. While it is one of the goals to enable translation-only updates, it is not quite obvious to me what your proposal has to offer in terms of splitting translations out of the debs, which is an explicit goal. Also, the proposal specifically aims at limiting the amount of data that the archive and apt have to handle. I'm not quite sure how useful the notes about design considerations are, but you could always ask Neil whether they are in a shape to publish them for further discussion. It seems that at Casar de Cáceres we found quite a few corner-cases that had not been previously considered. I've tried to include all the notes about design into the specification but there has been little work on comparing this with the original TDeb proposals put forward by Eric Petrisor. (AFAIAM, Eric is happy with the new model). If there is anything in the specification that is unclear, please let me know. In particular, if there is a need for more detail relating to the background, purpose and motivation behind TDebs. You might also be interested in the slides for the presentation I made at FOSDEM last year on TDebs: http://buildd.emdebian.org/svn/browser/current/emdebian/trunk/docs/fosdem2008/debian With some distance, it might well be that we could generalize (at least parts of) the tdeb-implementation to class support (with different members of the ar archive per class[1]). We would still want to separate them out, but that might be a good way to arrive at a better mechanism. In summary, yes, there might be room for generalization, but taking your suggestions as an indication, maybe part of your dissatisfaction with the direction that the tdeb proposal takes stems from a disparity in the goals that each is concerned with. Within Emdebian, we want to use dpkg class alongside DEB_VENDOR to provide more flexibility in how Debian packages are assembled. I certainly want to have class support within tdebs (to make it easier to remove translated manpages that are useless in Emdebian). Right now, I'm concentrating on what changes are necessary within debhelper and dpkg to implement TDebs based on the agreement with ftp-master for what is actually achievable and with i18n for what is actually usable - whilst still retaining the functionality that is necessary for TDebs in Emdebian. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpzybuUk7Cgc.pgp Description: PGP signature
Re: Bug#489771: New Build-Options field and build-arch option, please review
On Thu, 2008-09-11 at 08:46 +0200, Raphael Hertzog wrote: On Wed, 10 Sep 2008, Bill Allombert wrote: People have noticed that and already requested that we can call arbitrary targets of debian/rules with all the proper initialization done precisely for test purpose during packaging work (see #477916). I must say, I really do not like this direction. debhelper and cdbs and similar sytsems are the places to provide this help where people want to use it, in my opinion. The actual support will be implemented in debhelper - all that is needed is a consistent manner to pass the same options to debhelper across a range of packages. Packages then add extra support if necessary, e.g. if a package installs docs manually instead of using dh_installdocs, then those sections of debian/rules need to be either conditionally excluded: ifeq (,$(findstring nodocs,$(DEB_BUILD_OPTIONS))) install foo.1 debian/foo/usr/share/man/man1/ ... endif or redone for debhelper support via foo.install files, etc. After Lenny, I will be filing bugs for this support - at least for the packages used in Emdebian. We have a lot of past experience with that and we have the compatibility level to handle smoothing transitions. (And to provide a way for people to never transition, I admit, and I see where that's the problem that you're solving, but I prefer that problem to the problems introduced by the instability of having the package build infrastructure change the input to the builds without coordination with the package.) There has to be coordination with the package - the package needs to support the build option, either explicitly or via debhelper. All CDBS or any other layer needs to do is pass down the option to make it accessible to debhelper (usually via DEB_BUILD_OPTIONS). I like to say I concurr with Russ. There are some much difference between packages that distributions wide default does not make sense. On the contrary, there are clear divisions where distribution-wide build options do make sense. Raphael correctly identifies nodocs and nocheck as the current Emdebian distribution-wide build options. nodocs itself needs to be refined to allow for graded levels of documentation exclusion and other build options may change the build process itself - all under the control of the particular package. If the package does not understand the option, nothing happens. e.g. Emdebian needs nodocs (or something as broad) that drops everything, from README and TODO to changelog.gz and manpages during the build, rather than after downloading. Preferably, nodocs would also lead to the mandatory compression of copyright to save more space. It is not new for DEB_BUILD_OPTIONS to break Debian Policy - supporting a distribution-wide superset of options allows the use of the set to conform to Emdebian Policy etc. Other uses of options could use graduations so that examples are dropped but not the rest, or just manpages or just HTML docs etc. Dpkg Classes will help with graduations, as long as the distro can afford to remove the files *after* the package has been downloaded. But more and more people want to be able to change distribution wide default: Emdebian wants to enable nodocs and nocheck by default, other want to be able to enable hardening options by default and I agree with them that official support for such a facility is desirable. See also #498355 and #498380 for such requests from Emdebian. Note also that Ubuntu are interested in supporting distribution-wide build options. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: Bug#489771: New Build-Options field and build-arch option, please review
On Thu, 2008-09-11 at 10:53 -0700, Russ Allbery wrote: Raphael Hertzog [EMAIL PROTECTED] writes: On Wed, 10 Sep 2008, Bill Allombert wrote: I like to say I concurr with Russ. There are some much difference between packages that distributions wide default does not make sense. Such change would rather lead me to hardcode values of DEBIAN_BUILD_OPTIONS in debian/rules if they are used blidly. But more and more people want to be able to change distribution wide default: Emdebian wants to enable nodocs and nocheck by default, other want to be able to enable hardening options by default and I agree with them that official support for such a facility is desirable. So they should set DEB_BUILD_OPTIONS in the environment. That's what it's for. I don't have any objections to that, or even to doing it via dpkg-buildpackage. That is what DEB_VENDOR seeks to achieve - set it once and it sets the same options across all builds, in the environment. This is getting to be a long list of CC: - isn't it worth sending to debian-devel instead? Goswin von Brederlow and Simon Richter did a lot of work on this at Extremadura and they aren't on the current CC:. I'm losing track of all the bugs in the CC: and why they are listed. My objection is specifically to having dpkg-buildpackage set a variety of environment variables *by default*, and then telling package maintainers that they should rely on those environment variables being set in the default case. If by default you mean Debian, then NO. DEB_BUILD_OPTIONS is empty for Debian and will continue so. That breaks the debian/rules interface and requires that all package builds go through dpkg-buildpackage. Having dpkg-buildpackage set environment variables in the non-default case like Emdebian is not a problem, since for Emdebian builds (for example) Emdebian can decide that using dpkg-buildpackage or setting the environment variables manually is required. There is no existing precedent, and they can make that rule from scratch. Exactly. My concern is for the default build where there *is* an existing precedent that debian/rules build should work sanely, not for support for special cases like that where the existing debian/rules interface already doesn't do the right thing without additional help. If you are going to go down this path of having dpkg-buildpackage set up an environment that package maintainers should rely on, you or someone else on the dpkg team needs to make a debian-devel-announce post making it clear that debian/rules build is no longer a supported interface for building packages and using dpkg-buildpackage is required for consistent behavior. Right now, I don't think most Debian Developers have any idea what the implications of these changes are. That's fine. DEB_BUILD_OPTIONS would be empty if DEB_VENDOR is not set or is set to Debian. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Bug#229357: Bug#489771: New Build-Options field and build-arch option, please review
On Thu, 2008-09-11 at 08:46 +0200, Raphael Hertzog wrote: On Wed, 10 Sep 2008, Bill Allombert wrote: People have noticed that and already requested that we can call arbitrary targets of debian/rules with all the proper initialization done precisely for test purpose during packaging work (see #477916). I must say, I really do not like this direction. debhelper and cdbs and similar sytsems are the places to provide this help where people want to use it, in my opinion. The actual support will be implemented in debhelper - all that is needed is a consistent manner to pass the same options to debhelper across a range of packages. Packages then add extra support if necessary, e.g. if a package installs docs manually instead of using dh_installdocs, then those sections of debian/rules need to be either conditionally excluded: ifeq (,$(findstring nodocs,$(DEB_BUILD_OPTIONS))) install foo.1 debian/foo/usr/share/man/man1/ ... endif or redone for debhelper support via foo.install files, etc. After Lenny, I will be filing bugs for this support - at least for the packages used in Emdebian. We have a lot of past experience with that and we have the compatibility level to handle smoothing transitions. (And to provide a way for people to never transition, I admit, and I see where that's the problem that you're solving, but I prefer that problem to the problems introduced by the instability of having the package build infrastructure change the input to the builds without coordination with the package.) There has to be coordination with the package - the package needs to support the build option, either explicitly or via debhelper. All CDBS or any other layer needs to do is pass down the option to make it accessible to debhelper (usually via DEB_BUILD_OPTIONS). I like to say I concurr with Russ. There are some much difference between packages that distributions wide default does not make sense. On the contrary, there are clear divisions where distribution-wide build options do make sense. Raphael correctly identifies nodocs and nocheck as the current Emdebian distribution-wide build options. nodocs itself needs to be refined to allow for graded levels of documentation exclusion and other build options may change the build process itself - all under the control of the particular package. If the package does not understand the option, nothing happens. e.g. Emdebian needs nodocs (or something as broad) that drops everything, from README and TODO to changelog.gz and manpages during the build, rather than after downloading. Preferably, nodocs would also lead to the mandatory compression of copyright to save more space. It is not new for DEB_BUILD_OPTIONS to break Debian Policy - supporting a distribution-wide superset of options allows the use of the set to conform to Emdebian Policy etc. Other uses of options could use graduations so that examples are dropped but not the rest, or just manpages or just HTML docs etc. Dpkg Classes will help with graduations, as long as the distro can afford to remove the files *after* the package has been downloaded. But more and more people want to be able to change distribution wide default: Emdebian wants to enable nodocs and nocheck by default, other want to be able to enable hardening options by default and I agree with them that official support for such a facility is desirable. See also #498355 and #498380 for such requests from Emdebian. Note also that Ubuntu are interested in supporting distribution-wide build options. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Bug#229357: Bug#489771: New Build-Options field and build-arch option, please review
On Thu, 2008-09-11 at 10:53 -0700, Russ Allbery wrote: Raphael Hertzog [EMAIL PROTECTED] writes: On Wed, 10 Sep 2008, Bill Allombert wrote: I like to say I concurr with Russ. There are some much difference between packages that distributions wide default does not make sense. Such change would rather lead me to hardcode values of DEBIAN_BUILD_OPTIONS in debian/rules if they are used blidly. But more and more people want to be able to change distribution wide default: Emdebian wants to enable nodocs and nocheck by default, other want to be able to enable hardening options by default and I agree with them that official support for such a facility is desirable. So they should set DEB_BUILD_OPTIONS in the environment. That's what it's for. I don't have any objections to that, or even to doing it via dpkg-buildpackage. That is what DEB_VENDOR seeks to achieve - set it once and it sets the same options across all builds, in the environment. This is getting to be a long list of CC: - isn't it worth sending to debian-devel instead? Goswin von Brederlow and Simon Richter did a lot of work on this at Extremadura and they aren't on the current CC:. I'm losing track of all the bugs in the CC: and why they are listed. My objection is specifically to having dpkg-buildpackage set a variety of environment variables *by default*, and then telling package maintainers that they should rely on those environment variables being set in the default case. If by default you mean Debian, then NO. DEB_BUILD_OPTIONS is empty for Debian and will continue so. That breaks the debian/rules interface and requires that all package builds go through dpkg-buildpackage. Having dpkg-buildpackage set environment variables in the non-default case like Emdebian is not a problem, since for Emdebian builds (for example) Emdebian can decide that using dpkg-buildpackage or setting the environment variables manually is required. There is no existing precedent, and they can make that rule from scratch. Exactly. My concern is for the default build where there *is* an existing precedent that debian/rules build should work sanely, not for support for special cases like that where the existing debian/rules interface already doesn't do the right thing without additional help. If you are going to go down this path of having dpkg-buildpackage set up an environment that package maintainers should rely on, you or someone else on the dpkg team needs to make a debian-devel-announce post making it clear that debian/rules build is no longer a supported interface for building packages and using dpkg-buildpackage is required for consistent behavior. Right now, I don't think most Debian Developers have any idea what the implications of these changes are. That's fine. DEB_BUILD_OPTIONS would be empty if DEB_VENDOR is not set or is set to Debian. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: RFC: Idea for improved diversions and alternatives handling
Goswin von Brederlow wrote: working on dpkg reminded me that I wanted to propose a better diversion and alternatives handling for debian packages. Currently they have to be manually added and removed in the maintainer scripts. This method is prone to errors and can easily leave diversions or alternatives behind. Instead I suggest creating two new control files detailing the diversions and alternatives a package should have. Can symlinks be supported in the declarative control file stanzas? One problem within Emdebian is replacing coreutils etc. with busybox - currently we are having to use a rigid replacement where the options enabled in busybox must be removed from the package set (or added as Conflicts: in busybox) and then the symlinks for each applet are listed in the dpkg file list. This requires a particular level of coordination and makes it harder to customise Emdebian for a different scenario. If both /bin/foo and /bin/bar are called during the boot/init process, the issue is allowing for this scenario: Install package foo, includes symlink /bin/bar - /bin/foo Also includes a variety of others (about 30 in total). At a later date, the installation needs to be customised to allow the full version of /bin/bar from package bar to be installed for extra functionality. If Replaces: is used, bar cannot be removed because the box would not be bootable anymore - the previous symlink has gone forever. How to divert a symlink such that it can be restored later? Alternatives isn't a good solution because it means reimplementing the alternatives support code to avoid the use of Perl - and alternatives (IIRC) does not support symlinks as alternatives. What I need to avoid is having to make dozens of changes to postinst scripts to enable diversions in a long list of packages. Busybox 1.10.3 (not yet in Debian) does support discrete binaries linked to a shared library version of busybox but the library is bigger than the current busybox binary and each discrete binary is just over 4Kb so that is an appreciable increase in total size. (Seeing as this is busybox, size increases must be avoided.) It would allow the use of alternatives (subject to replacement non-perl code) but that method also needs changes in other packages (currently). So that costs an extra 2Mb or so and involves rewriting the code supporting alternatives - not my favourite option when the entire OS has to fit into 32Mb (or 64Mb for a full GUI using glibc). -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: Multiarch and idea for improved diversions and alternatives handling
On Fri, 2008-07-04 at 08:33 +0200, Tollef Fog Heen wrote: * Neil Williams | Just a thought - why use /usr/lib/$ARCH and /usr/include/$ARCH at all | when it would (IMHO) be simpler to use /usr/$TRIPLET/ and put the entire | package under that, as we do with dpkg-cross currently: How would you then handle libraries that go in /lib? (Apart from the fact that I think just using a subdirectory of /usr/lib is much neater than random subdirectories in /usr. /lib/ /arm-linux-gnu/lib/ (did I miss that bit?) A single subdirectory of /usr is, IMHO, neater than a subdirectory of /usr/include and /usr/lib/. It would also mean less changes for those who are currently using multiple architectures on one system for the purposes of cross building. I wouldn't want to go the whole hog though and have /arm-linux-gnu/usr/lib /arm-linux-gnu/lib because that would be ugly, at least to me. | /usr/include/ | /usr/arm-linux-gnu/include/ Please note that the initial goal of multiarch at least has been just running of packages from foreign architectures. Not building them. True but the current usage of these mechanisms is in cross-building so sometimes the results of having to do something without major changes elsewhere can be helpful in designing the subsequent mechanism. | multiarch could even add: | /usr/share/ | /usr/arm-linux-gnu/share Pardon my language, but this is crack. The point of /usr/share is you can share it between systems. If you go down this route, just use a chroot and some wrapper scripts to bounce between them instead. It was only a suggestion for /usr/share - it was an alternative to renaming the package to get a different directory in /usr/share/ as the current tools do. Until all suitable packages have things like translations separated out into TDebs and other things like images in a -data or -common package instead of being packaged along with the architecture-dependent binaries, conflicts will occur if /usr/share is used as intended. Personally, I think it is better to avoid the need for complicated changes to diversions, alternatives or Replaces: if a simpler change in the packaging can achieve a smoother effect overall - albeit that the change in packaging would affect a lot more packages. Multiarch isn't needed for every possible package - not even every lib package or every binary package, changes can be made in the relevant package when people find a need to use that package as a multiarch package. [...] | BTW I think it is a mistake to want to use /usr/lib/i386/ when it is | entirely possible that multiarch users will actually need the full | triplet - think about hurd or kfreebsd as multiarch packages. I don't believe anybody has suggested using just /usr/lib/i386, but rather /usr/lib/i486-linux-gnu? OK - as I said, my connection has been flaky and I might have missed that bit. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: Multiarch and idea for improved diversions and alternatives handling
On Tue, 2008-07-01 at 18:44 +0200, Goswin von Brederlow wrote: James Vega [EMAIL PROTECTED] writes: On Sat, Jun 28, 2008 at 02:03:05AM -0700, Steve Langasek wrote: So if we allow multiple packages to be installed at the same time which divert the same file, then I think we have another case for wanting to continue supporting an optional diversion target - or at least for not using .diverted by default, since we wouldn't want diversions from multiple packages to collide. Maybe .diverted-$package, then? (My internet connection has been very flaky since this thread started and I have only been able to post intermittently so apologies if this appears to be late or out-of-sync with other posts.) Just a thought - why use /usr/lib/$ARCH and /usr/include/$ARCH at all when it would (IMHO) be simpler to use /usr/$TRIPLET/ and put the entire package under that, as we do with dpkg-cross currently: /usr/lib/ /usr/arm-linux-gnu/lib/ /usr/include/ /usr/arm-linux-gnu/include/ multiarch could even add: /usr/share/ /usr/arm-linux-gnu/share This adds only one new directory, it keeps the main contents of the package in a single location (making it easier to manage and parse things like dpkg -L) and it means less changes for existing packages that use these paths already. It also means no need for extra diversions at all, no need for Replaces: and no headaches when removing the multiarch vs removing the primary package etc. BTW I think it is a mistake to want to use /usr/lib/i386/ when it is entirely possible that multiarch users will actually need the full triplet - think about hurd or kfreebsd as multiarch packages. There are two use cases to consider regarding multiple packages and diversions. 1) Multiple packages installing a file that has been diverted. Currently, there is only one divert to filename so you'll end up losing data once the second diverted file is installed. This could be alleviated by instead basing the divert to filename on the package which contains the file being diverted (as you suggest above). There's still the problem of what to do when the package providing the diversion is uninstalled as now you have conflicting packages. Actually, you already had conflicting packages that just weren't affected yet because of the diversion, which leads to 2). If the multiarch package can be installed alongside the primary without any conflicts by using /usr/$triplet instead, then the need for the diversion and consequent hacks goes away entirely. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: Another multiarch decision
On Thu, 2008-06-26 at 14:56 +0200, Goswin von Brederlow wrote: Raphael Hertzog [EMAIL PROTECTED] writes: On Thu, 26 Jun 2008, Goswin von Brederlow wrote: So I think for Multi-Arch: abi packages the /usr/share/doc/package in its entirety should be renamed and now there is a choice to make: I like none of your suggestions. I'd like to suggest to rely on the work done by Tollef that lets dpkg skip some files in packages. The first purpose was to strip doc and locale data in some embedded usage but it could be improved with new rules that exclude such common name spaces for package which are for another architecture than the current one. Cheers, So when I install iceweasel 32bit on amd64 (for stupid plugins) I will have no copyright, changelog nor license? I doubt that would be legal. Even for libaries there is no garanty that the native flavour of a library will be present when another architectures flavour is installed. Your use case is a touch unusual (from my perspective anyway) - current behaviour (via dpkg-cross) is focused on only providing the binaries of a particular package for purposes of linking during cross builds, in which case dropping everything not related to linkage is the obvious solution, hence dpkg filtering and dpkg-cross. Similarly, many multiarch dpkg runs will take place in a temporary chroot during a cross-build - there isn't a need for any copyright or changelog files in that situation. (Currently, these -cross packages are generated on-the-fly from the Debian mirrors for the requested architecture, obtained using apt-cross). Actually running foreign binaries involves a different set of problems (and dependencies). iceweasel 32bit on amd64 isn't what I would think of as the typical use of dpkg multiarch support. If we are to continue migrating dpkg-cross into dpkg, the multiarch support will need to support installing ARM packages on amd64 and i386 - not for the purposes of running them via qemu or anything else, purely for the purposes of linking against them during builds. If a user wants to skip them that is their problem but Debian shipping a dpkg that skips them allways or by default would be problematic. (Although common in a variety of embedded installations so by no means a deal-breaker.) Besides, dpkg-cross has been in Debian for a decade with the default action doing precisely this kind of stripping: $ dpkg -L libqof1-arm-cross /. /usr /usr/arm-linux-gnu /usr/arm-linux-gnu/lib /usr/arm-linux-gnu/lib/libqof.so.1.0.10 /usr/share /usr/share/doc /usr/share/doc/libqof1-arm-cross /usr/share/doc/libqof1-arm-cross/README /usr/arm-linux-gnu/lib/libqof.so.1 Can you give me an url for Tollefs work? Maybe that can be used to rename by default. See this thread in the dpkg list archives: http://lists.debian.org/debian-dpkg/2008/01/msg1.html And some other links for background: http://www.linux.codehelp.co.uk/serendipity/index.php?/archives/25-dpkg-filtering.html http://www.emdebian.org/docs/howto-4.html -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: Another multiarch decision
On Thu, 2008-06-26 at 14:56 +0200, Goswin von Brederlow wrote: Can you give me an url for Tollefs work? Maybe that can be used to rename by default. See this thread in the dpkg list archives: Try this one instead: http://lists.debian.org/debian-dpkg/2008/01/msg00011.html -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: Another multiarch decision
On Thu, 2008-06-26 at 10:45 -0400, Felipe Sateler wrote: Goswin von Brederlow wrote: Raphael Hertzog [EMAIL PROTECTED] writes: On Thu, 26 Jun 2008, Goswin von Brederlow wrote: So I think for Multi-Arch: abi packages the /usr/share/doc/package in its entirety should be renamed and now there is a choice to make: I like none of your suggestions. I'd like to suggest to rely on the work done by Tollef that lets dpkg skip some files in packages. The first purpose was to strip doc and locale data in some embedded usage but it could be improved with new rules that exclude such common name spaces for package which are for another architecture than the current one. Cheers, So when I install iceweasel 32bit on amd64 (for stupid plugins) I will have no copyright, changelog nor license? I doubt that would be legal. Even for libaries there is no garanty that the native flavour of a library will be present when another architectures flavour is installed. If a user wants to skip them that is their problem but Debian shipping a dpkg that skips them allways or by default would be problematic. Maybe install the first one and skip the next? ie, if I install iceweasel 32 bits first, then /u/s/d/iceweasel gets installed. When I install the amd64 version, /u/s/d/iceweasel gets skipped. Another option would be for dpkg to automatically assume that each arch Replaces: the same package for other archs, and so it will just overwrite said files. If we are to have automated Replaces:, wouldn't it make sense to assert that the primary arch replaces all other architectures? i.e. in the same manner as the buildd allows Architecture: all uploads for the first upload but requires -B builds for the ports. Whichever is the primary system architecture (according to dpkg-architecture when passed no arguments) has first call on all files installed for that architecture - everything else is deemed to be replaced by the primary. In the case of conflict or Replaces: the files stay under the ownership of the primary architecture. The problem with arbitrary or sequential decisions on Replaces: is that whichever package finally gets the flag ends up with ownership so if the user removes the multiarch but leaves the primary, the files are not put back because Replaces: is already in effect. If users install a multiarch version without the primary version, is that something dpkg even needs to worry about? The default (to me) should be to preserve the primary architecture and ensure that if the multiarch package is purged, the primary architecture package is still in a pristine state. Allowing the multiarch to Replace: the primary will only ensure that the primary arch package is always incomplete if the multiarch is ever removed. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Bug#180128: state of integration of dpkg-cross into dpkg
tag 180128 - patch thanks The bulk of the patch is now out of date but rather than spend time updating the patch, work is ongoing to merge the existing dpkg-cross package (which includes all the cache values and architecture support) into dpkg itself, sometime after Lenny. dpkg-buildpackage -a is working due to other bug fixes in dpkg (= 1.14.17) and the use of dpkg-cross. The idea behind this bug is still open but the patch itself is too out of date to be useful (not the fault of the submitter), other methods are being followed to achieve the long term goal and a working solution does already exist. Far better, in my view, to remove the 'patch' tag from this report, keep it open as wishlist and I'll merge it with the eventual bug report that implements an updated patch (arranged with Guillem) that fully merges dpkg-cross into dpkg and then remove dpkg-cross (and apt-cross) from unstable. The main issue unresolved in this bug report is the mapping of /usr/lib/foo.so to /usr/arm-linux-gnu/lib/foo.so for packages that do not use pkg-config (e.g. I'm having upstream problems trying to configure a package that build-depends on Postgres and ODBC using pg_config and iodbc-config respectively). dpkg-cross implements a workaround solution (gccross) but the real fix is getting exec-prefix support in such config scripts and in other situations where a package build mistakenly looks in /usr/lib/ during a cross-build due to some problem with FOO_LIBS settings. A variation of that bug is internal libraries within packages (either where the package builds a library and a binary or builds more than one library and one library depends on at least one of the others). gccross assists in this situation too but, again, upstream support will be needed for some of these packages. Support for removing dpkg-cross entirely is therefore far from complete (even without considering the other use of dpkg-cross in making the -cross packages available in /usr/arm-linux-gnu/lib in the first place) and the patch in this bug report is certainly insufficient (and was when originally posted IMHO). More information on dpkg-cross, apt-cross, cross-building in general and issues relating to how Debian can be made easier to cross-build, see http://www.emdebian.org/ Just in the last few weeks, it has become possible to track the cross-builds of packages in Emdebian - 230 source packages are currently supported with manual builds, maybe 60% will cross-build without intervention and this proportion will increase over time. (The main purpose of the autobuilder so far is simply to make the build logs available and help me find the packages that need fixes.) http://www.emdebian.org/buildd/ -- Neil Williams [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Generated changes and patch systems
On Sun, 2008-05-25 at 08:40 -0700, Russ Allbery wrote: Neil Williams [EMAIL PROTECTED] writes: On Sun, 2008-05-25 at 13:19 +0100, Mark Brown wrote: If you run autotools at build time you should also ensure that the changes which autotools makes are reverted in the clean target. This means that your diff doesn't get cluttered with automatically generated things and ensures that repeated builds of the package produce the same diff.gz. I haven't seen any other packages doing that - is there an example involving aclocal.m4 somewhere? Lots of other packages do this -- one of mine off the top of my head is xml-security-c. Nope. No mention of aclocal.m4 in debian/rules for that package, just /usr/share/misc/config.guess and config.sub. I need to patch configure and configure.ac in this package, that means that aclocal.m4 is constantly being changed and reverted. It shouldn't matter - it really should not. I see no purpose in lintian (or dpkg come to that) testing for changes in aclocal.m4 - IMHO it should simply be exempt from this check. No distro can risk patching aclocal.m4 - by it's nature it is transient and volatile and subject to large changes entirely at the mercy of external factors. Any build system that tries is simply going to break constantly, AFAICT. No matter how I wrap the cp foo foo.safe mv foo.safe foo in debian/rules, the first build can be OK but all subsequent builds end up with aclocal.m4 in the .diff.gz. Besides, replacing aclocal.m4 after it has just been updated by ./configure is not a good idea to me. I really don't want to do all that for the tmpl/* files as well - I don't see the need, copying dozens of files into foo.safe or foo.upstream and then moving them back? Just delete them then. ??? That simply does not work. The problem is that running gtk-doc not only requires tmpl/*.sgml files to exist but it *then modifies them*! Even though I don't install these files into the package, I cannot delete them and I cannot move them out of the way or the documentation is not updated. Again, first build can be OK, second build generates a dozen spurious warnings (because the files are modified after the .diff.gz is created but cannot be reliably reverted before the next build). I don't see that I should provide out-dated documentation (by dropping --enable-gtk-doc) just because it suits lintian - neither can I patch the updates because the updates themselves are generated by a third party tool so I can neither control the changes made nor maintain clean patches. I suspect the issue arises because upstream happen to prepare the release tarballs on Ubuntu or Fedora where the tool version differs. The precise reason is inconsequential - the problem is that Debian should not need to care about these modifications. It's taking 'divergence' one stage too far. With these gtk-doc files, it's not so much that the tmpl/*.sgml files are generated but that a tool essential to the build modifies them in a way that cannot be patched because the results of the patches are variable according to that third party tool. The changes then affect the files that are packaged. Some of these are formatting changes - whitespace changes, extra lines, comment changes. Other changes cause sections or entire pages to migrate within the final files. The sense of the docs doesn't appear to change, just the internal structure - as determined by the differing versions of the tools used. The CDBS build doesn't do anything different - it's just that lintian doesn't produces any warnings for this check in CDBS packages, ever. The point is to not put mechanically generated changes in the diff, since it makes it much harder to review what the maintainer has actually done. I don't see how it can be prevented. Take a look at the current .diff.gz for libgpewidget 0.115-5 in the archive. I think most people take the approach of just deleting such files in the clean target, which will exclude their changes from the diff. Sorry, it is not as simple as that - the package simply won't build if tmpl/*.sgml are removed, no rule to make tmpl/*.sgml. The tmpl/*.sgml files cannot be cleaned and removing aclocal.m4 is simply pointless (and creates an even larger .diff.gz). I still don't see what problem this test is trying to solve - AFAICT the problem didn't exist in the first place and all this extra work appears pointless. I still think patch-system-but-direct-changes-in-diff should be downgraded to info only, if kept at all. I fail to see what I'm doing wrong - or even why it matters to lintian. We risk swapping a minor problem that only occurs when the maintainer upgrades from one version to another (and which could be fixed by dpkg-source ignoring changes to generated files in the .diff.gz or not applying generated changes that do exist in the .diff.gz) for a major FTBFS error every time some random third party package is updated by erroneously patching files that contain generated
Re: Transition to GNU's install-info (was: Removing cleanup-info)
On Thu, 2008-05-22 at 16:36 +0200, Sven Joachim wrote:
Agreed. Guillem wanted to remove it once the install-info issue had been
sorted. But progress has been slower than expected on this front. I'm
never quite sure if GNU's install-info has all the features now and what
the next step is... maybe you could lead that effort?
From the texinfo NEWS file and the output of the respective
`install-info --help' commands, I get the impression that all options of
dpkg's install-info are supported in texinfo's install-info as of
version 4.12 (which is not packaged for Debian yet). So, in principle
it would be possible to switch to GNU's install-info now¹ with the
following steps:
- create a separate install-info package from the texinfo source that
Replaces: dpkg ( 1.15.0)
- remove {cleanup,install}-info files from dpkg and let dpkg 1.15.x
pre-depend on install-info
But another question is: what exactly do we want from install-info?
The ability to omit it entirely if DEB_BUILD_OPTIONS specifies nodocs.
From an Emdebian perspective, I would rather that dpkg did not
pre-depend on install-info - rather dpkg should be able to operate
without install-info ever existing. Not every usage of dpkg wants info
documents as well.
Currently, despite removing info documents from the rebuilt packages and
install-info calls from maintainer scripts, I still need to have a
useless /usr/bin/install-info containing #!/bin/sh - it would be nice to
not require such a hack, merely to dump documentation.
Another feature that would be very desirable is triggers support. In
the long run, install-info should probably not be Priority: Required, as
it's only useful if a package providing info-browser is installed.
Agreed.
--
Neil Williams [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dpkg + Architecture limitations
On Wed, 2008-05-07 at 10:13 +0300, dani wrote: Good Morning, I have compiled a uclibc based system I think you should probably be asking this on the debian-embedded list. http://lists.debian.org/debian-embedded/ uClibc is not in Debian at this time and dpkg does not have explicit support for it yet. dpkg-cross is probably where you would start with uClibc requirements. Debian-embedded looks after dpkg-cross and I'm currently doing most of the work on the source code for it. and I want to use dpkg as the package manager. My config.site is; host=$(uname -m)-anchor-linux-uclibc Why put 'anchor' in there? To what does anchor refer? A uClibc architecture string is not specific to one particular machine. It should specify the CPU (i486 because i686 is not a distinct architecture from i486 which in turn is not distinct from i386), the kernel and the OS suffix. build=$host target=$host ac_cv_host=$host ac_cv_build=$build ac_cv_target=$target That doesn't look right to me. Where did you find this snippet? dpkg-cross does not use system-level config.site files of that type anymore. The i386 config.site data is: # # i386 specific configure variables # # If you have additions to this file, please tell [EMAIL PROTECTED] # so they can be included in the package. # ac_cv_c_bigendian=no ac_cv_c_char_unsigned=no ac_cv_sizeof_long_long=8 ac_cv_sizeof_unsigned_long_long=8 ac_cv_sizeof_long=4 ac_cv_sizeof_unsigned_long=4 ac_cv_sizeof_int=4 ac_cv_sizeof_unsigned_int=4 ac_cv_sizeof_short=2 ac_cv_sizeof_unsigned_short=2 ac_cv_sizeof_short=2 ac_cv_sizeof_unsigned_short=2 ac_cv_sizeof_float=4 ac_cv_sizeof_double=8 ac_cv_sizeof_long_double=12 Nothing in that file is any different on i486, i686 or uClibc. My machine architecture is i686 (output of uname -m). I think you may be confusing things - to build uClibc packages on an i686 machine that will run on i386 machine, you don't need config.site. The experimental uClibc support in emdebian-tools uses an existing toolchain (cross building toolchain if necessary) and simply bolts-on uClibc support to that toolchain. This snippet gives you your proper architecture string: $ perl -e '$u=i486-linux-gnu; $u =~ s/([[:alnum:]]*)-([[:alnum:]]*)-gnu(.*)/$1-$2-uclibc$3/; print $u\n;' i486-linux-uclibc The value to pass to $u is the value from: $ dpkg-architecture -ai386 -qDEB_HOST_GNU_TYPE Take a look at the source code for emchain in current SVN for emdebian-tools: http://buildd.emdebian.org/svn/browser/current/host/trunk/emdebian-tools/trunk/emchain#L698 My problem is; when I run the configure script (dpkg-1.14.15), I get the following warnings; configure: loading site script /usr/share/config.site checking build system type... (cached) i686-anchor-linux-uclibc checking host system type... (cached) i686-anchor-linux-uclibc checking target system type... (cached) i686-anchor-linux-uclibc That is plain wrong, sorry. Call ./configure with: --build=i486-linux-gnu --host=i486-linux-uclibc (Just don't use config.site to do it.) With a correctly setup uClibc environment using emchain to munge the gcc specs files, that would be all you need. No config.site. What should I add to the ostable, triplettable, and cputable files to get rid of the above warnings? Nothing. The warnings, AFAICT are correct, your original approach seems wrong. -- Neil Williams [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#476530: control field to tell that cross-building is not possible
\ --disable-debugging --sysconfdir=/var/lib/ntp \ The remaining problem is how to cope with these cache-files for ./configure data that would normally be determined by running a binary compiled during the ./configure operation. Cache files are a bit of a hack really and risk going stale in some circumstances. I'm investigating any other methods if anyone has ideas -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Bug#476530: control field to tell that cross-building is not possible
On Thu, 2008-04-17 at 13:14 +0200, Peter Eisentraut wrote: Package: dpkg-dev Version: 1.14.16.6 Severity: wishlist I've just noticed that despite the matter being a problem in ntp, this bug was filed against dpkg-dev and at 1.14.6.6 when 1.14.18 contains changes that directly improve the cross-build support for packages like ntp. *ALL* the remaining issues in crossbuilding ntp lie solely within the ntp package - namely debian/rules. I think this bug should be closed forthwith. dpkg-dev has already done everything necessary to support cross-building on Lenny in 1.14.18. As outlined already, I'm more than happy to supply a patch for ntp. Sorry that the patch went to this report instead of #315935. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Bug#456332: support for an option to drop lzma during rebuilds?
Just my 2p, from an embedded angle, it would be very useful if all the lzma options can be turned off (cleanly and reproducibly) when rebuilding / crossbuilding the package because if lzma is used too widely it could easily overwhelm embedded devices with limited memory. Pre-Depends isn't an issue for Emdebian, what worries me is a previously working Emdebian package set suddenly needing a four fold increase in memory requirements just to upgrade a handful (or even single) package. We can't just add more RAM to embedded devices! ;-o Ideally, something in DEB_BUILD_OPTIONS would be very helpful, which means allowing debian/rules complete control over whether lzma is used or not and all consequent changes. Then a simple check for 'nolzma' in DEB_BUILD_OPTIONS can turn off all the lzma features and revert to gzip. The Ubuntu page also talks about using lzma for the Packages file in repositories to save download time - the risk of making it impossible for low memory devices to actually then unpack the Packages file worries me a lot so a duplicate file is probably best for that (but is off-topic for this bug). It would be a shame to fix important cross-building bugs in one release and then undermine using dpkg on devices that require crossbuilt packages in the next. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Bug#439979: extra setting for Architecture:all pkgconfig data
On Fri, 2008-03-28 at 14:43 +0100, Raphael Hertzog wrote:
On Tue, 01 Jan 2008, Neil Williams wrote:
The full setting for PKG_CONFIG_LIBDIR is:
$ENV{PKG_CONFIG_LIBDIR}=/usr/$(DEB_HOST_GNU_TYPE)/lib/pkgconfig/:/usr/share/pkgconfig/;
Adding /usr/share/ allows the few Architecture: all packages that
contain pkgconfig data to be located during cross builds. (e.g.
gnome-mime-data).
Please review the attached patch. I hope it does what you want.
If it works for you, then I'll integrate it for the next dpkg.
It works perfectly, thanks Raphael.
I've been testing it on a variety of existing Emdebian packages and it
works exactly as requested.
Having the opinion of Frank and Guillem would be nice too.
I believe it's worthwhile to try to get those changes for lenny.
Closing this and #453267 would provide sane cross-building support
native to dpkg in Lenny and that is fantastic news. It may not sound
like a big event to the rest of Debian, but IMHO this warrants being
listed as one of the major improvements between Etch and Lenny for
anyone interested in embedded development.
I have no definitive opinion on this particular patch, but it's important
to have a sane cross-compilation toolchain and if that helps Neil, then
I'm ok for it.
I may be the one filing the bugs but there are lots of other people who
want to use Debian as their platform-of-choice when developing embedded
software.
Thanks for committing this improvement to dpkg!
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
signature.asc
Description: This is a digitally signed message part
Bug#453267: dpkg-shlibdeps and cross-building
On Thu, 2008-03-27 at 22:54 +0100, Raphael Hertzog wrote: Hi, On Tue, 04 Dec 2007, Neil Williams wrote: It does apply against dpkg 1.14.12 (albeit with offsets), it was developed against 1.14.11. I have merged a variant of this patch this evening: http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=626dda6f55bb7fb025be6a7c276651df884ac8a1 Can you check that it works as you want? I have been testing this with a variety of packages, including reverse_cross builds and cross-compiler builds of gcc-4.2 (there are upstream problems with gcc-4.3 right now) and a mix of other Emdebian packages and it works perfectly. Thanks for committing this fix, it will help Emdebian enormously. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: debconf: Bad file descriptor
On Wed, 2008-01-09 at 12:28 +, Alex Gonzalez wrote: Hi, Please redirect me to the correct list if this happens to be off-topic here. A post installation script on a private debian package performs the following: mount /dev/hda2 /mnt/hda mount -t proc none /mnt/hda/proc chroot /mnt/hda /bin/bash -c 'apt-get install portmap' chroot /mnt/hda apt-get install portmap You shouldn't need the extra shell. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: Review of file exclusion branch requested
On Sat, 2008-01-05 at 09:48 -0200, Otavio Salvador wrote: Tollef Fog Heen [EMAIL PROTECTED] writes: Hi, I've finally gotten around to fixing up my support for excluding bits of packages as they are unpacked. It can be gotten from git://git.err.no/dpkg in the master branch (sorry about that, it should probably have gone in a separate branch). What would be the usage scenario for it? Embedded devices? Yes, it was originally something that I set out to do at DebConf7 but Tollef came up with a better implementation of my patch. Once dpkg filtering is supported upon installation, I'll be looking at extending Tollef's work into filtering upon build so that I can further reduce the number of patches required to strip out unwanted components of Debian packages for Emdebian, in conjunction with support for noudeb, nodocs etc. dpkg-filtering upon installation isn't a complete solution for embedded devices because the device still has to download the entire package and unpack it - it is better to combine installation filtering with rebuilding the package upstream so that the device actually has room to unpack the .deb before starting filtering. Nevertheless, filtering is a powerful addition to embedded support in dpkg and Debian, especially for packages that contain lots of small files to be filtered out and where patches to remove those files are unnecessarily intrusive. (I'm thinking here of package files that Debian must include, due to Policy, but which Emdebian and others can actually do without.) However, for more powerful embedded devices, dpkg filtering may be all they need to be able to run normal Debian packages. Other uses include easier support for testing package changes such as splits and moving files between packages or replacing the static Essential list with a volatile list of packages selected during the installation. e.g. Emdebian already disregards Essential in order to reduce the size of the root filesystem - however the idea of Essential is still useful so Emdebian is considering how to implement a device-specific Essential list that is much smaller than the current Debian default. After all, apt doesn't care whether a package is Essential to your machine when running on my machine - it only cares about what is Essential to the current device. I can envisage testing for package splits by filtering out certain package components during install, seeing which applications actually need those components and thereby devising a new package split that operates on a *functional* basis instead of an archive basis. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Bug#439979: extra setting for Architecture:all pkgconfig data
The full setting for PKG_CONFIG_LIBDIR is:
$ENV{PKG_CONFIG_LIBDIR}=/usr/$(DEB_HOST_GNU_TYPE)/lib/pkgconfig/:/usr/share/pkgconfig/;
Adding /usr/share/ allows the few Architecture: all packages that
contain pkgconfig data to be located during cross builds. (e.g.
gnome-mime-data).
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgpY6CEFJ1uNo.pgp
Description: PGP signature
Re: Why does dpkg invoke find instead of doing own searches?
On Wed, 12 Dec 2007 10:11:37 + Phil Lello [EMAIL PROTECTED] wrote: Hi all, Can someone clarify for me why dpkg invokes 'find' to search for files, instead of having it's own code? Why have two versions of the same code? Is there a library that would do the same job? (Would it be sensible to use it if there was? I guess it would be OK if the library was built from the 'find' source.) Is there a problem with invoking find? busybox provides find if you don't want to install findutils (as in Emdebian). It would be a very strange GNU/Linux box that did away with some kind of find functionality. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpCHCC6KTtZ4.pgp Description: PGP signature
Bug#453267: tested patch
Raphael Hertzog wrote:
On Sun, 09 Dec 2007, Neil Williams wrote:
Emdebian cannot build, patch or test every permutation of toolchain that
people need so this isn't about us patching locally, it is about
lowering the barrier to cross building on Debian by not forcing every
user to patch locally. This is why we are at the current impasse - too
many permutations.
Emdebian provides ready to use cross compiler. You can also provides
ready-to-use source packages for building other cross-compilers that are
not yet provided.
? You make it sound as trivial as providing a web page.
Emdebian provides a small selection of binary toolchains containing
selected cross compilers. Extending that range is a truly massive
undertaking that nobody has the time to do. There are no usable
toolchain-source packages anymore - unmaintainable - we can provide
simple scripts that can assist in building a variant toolchain but we do
not provide ready-to-use source packages for building cross compilers.
The major reason why this is so much work is because the necessary
changes have not been incorporated into dpkg and we end up having to
patch a patch of a diversion of a patch.
Emdebian has quite a good relationship with the gcc maintainers and our
patches are generally welcome but that does not diminish the amount of
time involved in making a tested patch in the first place. Emdebian only
has enough developer time to derive patches for the latest versions of
gcc and even then it can be difficult to keep up with gcc releases. We
look forward to the stability of the pre-Lenny freeze because we know
that we can catch up and get a stable set of toolchains for unstable and
testing, all thoroughly tested and fixed. Then as soon as Lenny comes
out, we'll be swamped by gcc changes again. (We, in this case, equals
Hector Oron, myself and Wookey - gcc has a much larger team just for
itself.)
Why propose changing every version of gcc (a process that could take
extreme amounts of time to test, implement and get into testing) and
then make it impossible to build cross compilers in Etch? Are we looking
at backports as well?? Who is going to do all that work? (Not me, before
anyone asks.)
ARCH is a very generic environment variable that might be set for some
other reasons (I use it for example in debian-cd) and I don't like to
change the behaviour of dpkg-shlibdeps just because it's set. IMO,
there should be a single check to activate cross-building support
cross building != building a cross compiler, as I've said many times.
A single check for cross building is already in place -
DEB_BUILD_GNU_TYPE != DEB_HOST_GNU_TYPE
I created a patch for that in gcc for reverse cross support, it is
included in gcc-4.2.
A mass bug filing is already under way to implement this single check
for cross building support across Debian. The patch to dpkg-shlibdeps
contains a part of that support.
Cross building gcc is NOT the problem. gcc now cross builds just like
any other package in Debian. If reverse cross support in Debian goes
wrong, I'll fix it. I've no problem with that.
Building a cross compiler is a completely separate task and one that has
only become a problem *after* changes in dpkg made the dpkg-cross
diversions impractical.
and gcc's crossbuild should provide the right variables.
It does, thanks to the reverse cross support in gcc-4.2. Thankfully, we
don't need reverse cross support in 4.1 or earlier. (Well, it would be
nice if it could happen but then nobody has the time to do it so ...)
I'm ok with a
supplementary specific check for building of a cross-compiler, but not
with a generic check like testing the ARCH environment variable.
OK, I have a solution for that - replace $ARCH with $GCC_TARGET.
I've tested with this change to the patch for scripts/Dpkg/Shlibs.pm
# GCC_TARGET for cross compiler builds
my $crossprefix = Dpkg::Arch::debarch_to_gnutriplet($ENV{GCC_TARGET}) if
($ENV{GCC_TARGET});
...
I went for ARCH before because, in the context of building a cross
compiler, ARCH is only set at certain times. GCC_TARGET is set at the
beginning and is present throughout the build. This means that the
patched dpkg-shlibdeps behaves much more like the original diversion
from dpkg-cross - it effectively extends the list of directories
searched by dpkg-shlibdeps to include the ${crossprefix} ones for every
call throughout the entire build. It may slow things down a little bit
but building a cross compiler isn't exactly quick anyway. It is far more
important that the build completes than shaving a few more seconds off
the build time.
Furthermore, all the cross-building support in gcc has been contributed
by various Emdebian people (according to doko), so it looks like Emdebian
is also able to fix gcc in that regard if needed.
Those fixes (or hacks) were implemented piecemeal over many years and
the cross building support in Emdebian has recently been rewritten so
some of those hacks (i.e. the dpkg-cross
Bug#453267: tested patch
Raphael Hertzog wrote:
On Sun, 09 Dec 2007, Neil Williams wrote:
I'm ok with a
supplementary specific check for building of a cross-compiler, but not
with a generic check like testing the ARCH environment variable.
OK, I have a solution for that - replace $ARCH with $GCC_TARGET.
I've tested with this change to the patch for scripts/Dpkg/Shlibs.pm
# GCC_TARGET for cross compiler builds
my $crossprefix = Dpkg::Arch::debarch_to_gnutriplet($ENV{GCC_TARGET}) if
($ENV{GCC_TARGET});
...
I went for ARCH before because, in the context of building a cross
compiler, ARCH is only set at certain times. GCC_TARGET is set at the
beginning and is present throughout the build.
If I understand you correctly, we can check for GCC_TARGET only and we
don't need to check DEB_TARGET_GNU_TYPE != DEB_BUILD_GNU_TYPE.
What's the obsession with cutting components out of the patch?? I'm
confused.
dpkg-shlibdeps should at least *support* the right way of doing
things, even if the packages currently do not use that. At least it
supports a migration route away from GCC_TARGET for future releases of
gcc. GCC_TARGET is a hack, yes, but we need it around for older
compilers that simply aren't going to get fixed. It would be nice to
provide a migration path to do it TheRightWay(TM) eventually because
that only means changing the latest version of gcc (probably 4.3) and we
can do that in the Lenny freeze when everything else gets easier too. I
don't want to have to go through all this again. GCC_TARGET is likely to
be around until gcc-4.3 gets into oldstable but that's a small price to
pay, IMHO. (It's been around for as long as dpkg-cross which is a decade
so a bit longer isn't going to hurt.)
Is that correct and does that work ?
I don't believe it is correct but it happens to work - for now.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
signature.asc
Description: OpenPGP digital signature
Bug#453267: tested patch
Raphael Hertzog wrote: On Wed, 05 Dec 2007, Neil Williams wrote: My first patch did exactly that - and failed on building a cross compiler. gcc needs dpkg-shlibdeps to take notice of $ARCH in the preparation of libgcc1-$arch-cross and other libraries used in the complete toolchain. It needs (and sets) DEB_TARGET_GNU_TYPE != DEB_BUILD_GNU_TYPE at other stages of the build. If that's the case, I'd like to know if this is deliberate and really required... can't the gcc package be consistent and always have both DEB_TARGET_GNU_TYPE and DEB_BUILD_GNU_TYPE properly set ? Even if gcc changes that behaviour in 4.2 (or 4.3), lots of people still need to be able to build cross compilers from older versions of gcc, especially 4.1 and some even need 3.3 or 3.4. Emdebian still hosts 4.1 and 3.4 toolchains: http://www.emdebian.org/toolchains/search.php?package=gcc-3.4-arm-linux-gnu It's not sensible to say that these cannot be built in the future without writing a whole new diversion for dpkg-shlibdeps. Emdebian and lots of other people doing cross building need backwards compatibility here. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: OpenPGP digital signature
Bug#453267: tested patch
Hector and I have tested this patch with normal builds, cross builds
and cross compiler builds.
It does apply against dpkg 1.14.12 (albeit with offsets), it was
developed against 1.14.11.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
--- dpkg.old/scripts/Dpkg/Shlibs.pm 2007-11-23 02:42:51.0 +
+++ dpkg-1.14.11/scripts/Dpkg/Shlibs.pm 2007-11-28 22:06:15.0 +
@@ -25,11 +25,28 @@
use Dpkg::Gettext;
use Dpkg::ErrorHandling qw(syserr);
use Dpkg::Shlibs::Objdump;
+use Dpkg::Arch;
use constant DEFAULT_LIBRARY_PATH =
qw(/lib /usr/lib /lib32 /usr/lib32 /lib64 /usr/lib64
/emul/ia32-linux/lib /emul/ia32-linux/usr/lib);
-our @librarypaths = (DEFAULT_LIBRARY_PATH);
+my @shlibdeps=();
+# ARCH for some awkward builds
+my $crossprefix = Dpkg::Arch::debarch_to_gnutriplet($ENV{ARCH}) if ($ENV{ARCH});
+# host for normal cross builds.
+$crossprefix = $ENV{DEB_HOST_GNU_TYPE}
+if (($ENV{DEB_HOST_GNU_TYPE}) and ($ENV{DEB_HOST_GNU_TYPE} ne $ENV{DEB_BUILD_GNU_TYPE}));
+# target when building a cross compiler
+$crossprefix = $ENV{DEB_TARGET_GNU_TYPE}
+if (($ENV{DEB_TARGET_GNU_TYPE}) and ($ENV{DEB_TARGET_GNU_TYPE} ne $ENV{DEB_BUILD_GNU_TYPE}));
+if ($crossprefix)
+{
+@shlibdeps = ( ${crossprefix}/lib, /usr/${crossprefix}/lib,
+/${crossprefix}/lib32, /usr/${crossprefix}/lib32,
+/${crossprefix}/lib64, /usr/${crossprefix}/lib64,
+/emul/ia32-linux/lib, /emul/ia32-linux/usr/lib );
+}
+our @librarypaths = ((DEFAULT_LIBRARY_PATH), @shlibdeps);
# Update library paths with LD_LIBRARY_PATH
if ($ENV{LD_LIBRARY_PATH}) {
pgpRmMrVgW4AO.pgp
Description: PGP signature
Bug#453267: tested patch
Frank Lichtenheld wrote:
On Tue, Dec 04, 2007 at 10:27:35AM +, Neil Williams wrote:
use constant DEFAULT_LIBRARY_PATH =
qw(/lib /usr/lib /lib32 /usr/lib32 /lib64 /usr/lib64
/emul/ia32-linux/lib /emul/ia32-linux/usr/lib);
[...]
+if ($crossprefix)
+{
+@shlibdeps = ( ${crossprefix}/lib, /usr/${crossprefix}/lib,
+/${crossprefix}/lib32, /usr/${crossprefix}/lib32,
+/${crossprefix}/lib64, /usr/${crossprefix}/lib64,
+/emul/ia32-linux/lib, /emul/ia32-linux/usr/lib );
+}
Why do you add /emul/ia32-linux/lib, /emul/ia32-linux/usr/lib again?
Gruesse,
Oops.
Do you want a new patch with that final line amended?
Sorry about the typo - there is no need for the repeated /emul/, it is a
hangover from when the cross paths overwrote the standard paths instead
of appending to them.
It should be:
+if ($crossprefix)
+{
+@shlibdeps = ( ${crossprefix}/lib, /usr/${crossprefix}/lib,
+/${crossprefix}/lib32, /usr/${crossprefix}/lib32,
+/${crossprefix}/lib64, /usr/${crossprefix}/lib64);
+}
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
signature.asc
Description: OpenPGP digital signature
Bug#453267: tested patch
On Wed, 5 Dec 2007 00:01:22 +0100
Raphael Hertzog [EMAIL PROTECTED] wrote:
On Tue, 04 Dec 2007, Neil Williams wrote:
+my @shlibdeps=();
+# ARCH for some awkward builds
+my $crossprefix = Dpkg::Arch::debarch_to_gnutriplet($ENV{ARCH}) if
($ENV{ARCH});
What's the role of $ARCH ? And why shall we consider that we're
crossbuilding only because this variable is set ?
Not cross building - building a cross compiler.
gcc relies on $ARCH when preparing libgcc1-$arch-cross and other
toolchain libraries.
The actual call in gcc is:
ARCH=arm MAKEFLAGS=CC=something dh_shlibdeps -plibgcc1-arm-cross
e.g.
cd /opt/emdebian/emchain/gcc-4.2-4.2.2
GCC_TARGET=arm DEB_CROSS=yes debian/rules control
GCC_TARGET=arm DEB_CROSS=yes dpkg-buildpackage -b -uc -us -rfakeroot
build completes as normal with the patch
Testing from gcc-4.2-4.2.2 directory:
ARCH=arm MAKEFLAGS=CC=something dh_shlibdeps -plibgcc1-arm-cross
no errors.
Without the patch, I get:
dpkg-shlibdeps: failure: couldn't find library libc.so.6 needed by
debian/libgcc1-arm-cross/usr/arm-linux-gnu/lib/libgcc_s.so.1 (its RPATH
is '').
Note: libraries are not searched in other binary packages that do not
have any shlibs file.
To help dpkg-shlibdeps find private libraries, you might need to set
LD_LIBRARY_PATH.
dh_shlibdeps: command returned error code 512
...
+# host for normal cross builds.
+$crossprefix = $ENV{DEB_HOST_GNU_TYPE}
+if (($ENV{DEB_HOST_GNU_TYPE}) and ($ENV{DEB_HOST_GNU_TYPE} ne
$ENV{DEB_BUILD_GNU_TYPE}));
I think you should use the functions contained in Dpkg::Arch instead of
relying only the environment variables here...
Those variables are only defined in a cross build, not when building a
cross compiler or a toolchain.
We cannot use 'dpkg-architecture -a..' when building a cross compiler,
therefore we only have the environment variables.
use Dpkg::Arch qw(get_host_arch get_build_arch debarch_to_gnutriplet);
[...]
if (get_host_arch() ne get_build_arch()) {
$crossprefix = debarch_to_gnutriplet(get_host_arch());
}
+# target when building a cross compiler
+$crossprefix = $ENV{DEB_TARGET_GNU_TYPE}
+if (($ENV{DEB_TARGET_GNU_TYPE}) and ($ENV{DEB_TARGET_GNU_TYPE} ne
$ENV{DEB_BUILD_GNU_TYPE}));
Why would we need a special treatment of libs when creating a
cross-compiler? The cross-compiler runs on the build arch but is not linked
against any lib of the target arch so it doesn't need to scan the
directories of the target arch.
The cross compiler needs to build cross libraries that *are* called
when preparing the cross compiler itself.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgp6NZvDnv5Nk.pgp
Description: PGP signature
Re: Bug#439979: dpkg-dev: Please support removal of dpkg-cross diversions
Raphael Hertzog wrote:
On Tue, 28 Aug 2007, Neil Williams wrote:
As outlined on the debian-dpkg lists, I've been testing the removal of
the dpkg-cross diversions of dpkg-buildpackage and dpkg-shlibdeps during
the rewrite of dpkg-cross and I now have two patches (slightly modified
from the last ones posted to the list) that I would like to see in
dpkg-dev as a beginning to a process to merge dpkg-cross back into dpkg.
Okay, to make it easier to not loose track of this I properly reassigned
this to dpkg-dev and split it in two issues: one for dpkg-buildpackage and
one for dpkg-shlibdeps.
Contrary to what Hector forwarded from you on -devel, the changes for
dpkg-shlibdeps are relatively independant from the rest and since I've
been doing the work on dpkg-shlibdeps I can review and merge a good patch
of you.
I thought Guillem wanted to review the use of /usr/arm-linux-gnu/lib and
/usr/arm-linux-gnu/include ? I do have perl code that solves the problem
(used it to cross build GPE for Emdebian) involving adding search
directories to LD_LIBRARY_PATH but I wasn't sure if Guillem was looking
at a different implementation for those directories.
CC'ing debian-dpkg to find out.
Guillem: what are your plans for the diversion replacements?
Are you planning on changing the current usage of /usr/$arch/include
etc. or just changing the way that the diversion used to use a temporary
directory of symlinks or something else? Should Raphael and I work on a
solution for dpkg-shlibdeps using LD_LIBRARY_PATH using the example below?
If you don't provide the patch, it'll take some more time but I'll get
around to it sometime.
This is the core of what would be the patch:
my $crossprefix = check_arch($arch);
#(check_arch takes a user-specified string and checks that
#dpkg-architecture supports it, then returns the triplet so for 'arm',
# e.g. $crossprefix=arm-linux-gnu;
my @librarypaths = qw( /lib /usr/lib /lib32 /usr/lib32 /lib64 /usr/lib64
/emul/ia32-linux/lib /emul/ia32-linux/usr/lib );
my @shlibdeps = ( ${crossprefix}/lib, /usr/${crossprefix}/lib,
/${crossprefix}/lib32, /usr/${crossprefix}/lib32,
/${crossprefix}/lib64, /usr/${crossprefix}/lib64,
/emul/ia32-linux/lib, /emul/ia32-linux/usr/lib );
my $libpath = join (:, @librarypaths) . join (:, @shlibdeps);
$ENV{LD_LIBRARY_PATH}.=$libpath;
That is what I'm using with the current dpkg-shlibdeps from 1.14.11 and
AFAICT it is fine (providing that the cross paths are added to the
standard paths and not replace them or perl gets confused).
If this method is ok, I'll prepare the patch against 1.14.11.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
signature.asc
Description: OpenPGP digital signature
Bug#453267: Bug#439979: dpkg-dev: Please support removal of dpkg-cross diversions
Raphael Hertzog wrote:
On Tue, 28 Aug 2007, Neil Williams wrote:
As outlined on the debian-dpkg lists, I've been testing the removal of
the dpkg-cross diversions of dpkg-buildpackage and dpkg-shlibdeps during
the rewrite of dpkg-cross and I now have two patches (slightly modified
from the last ones posted to the list) that I would like to see in
dpkg-dev as a beginning to a process to merge dpkg-cross back into dpkg.
Okay, to make it easier to not loose track of this I properly reassigned
this to dpkg-dev and split it in two issues: one for dpkg-buildpackage and
one for dpkg-shlibdeps.
Contrary to what Hector forwarded from you on -devel, the changes for
dpkg-shlibdeps are relatively independant from the rest and since I've
been doing the work on dpkg-shlibdeps I can review and merge a good patch
of you.
I thought Guillem wanted to review the use of /usr/arm-linux-gnu/lib and
/usr/arm-linux-gnu/include ? I do have perl code that solves the problem
(used it to cross build GPE for Emdebian) involving adding search
directories to LD_LIBRARY_PATH but I wasn't sure if Guillem was looking
at a different implementation for those directories.
CC'ing debian-dpkg to find out.
Guillem: what are your plans for the diversion replacements?
Are you planning on changing the current usage of /usr/$arch/include
etc. or just changing the way that the diversion used to use a temporary
directory of symlinks or something else? Should Raphael and I work on a
solution for dpkg-shlibdeps using LD_LIBRARY_PATH using the example below?
If you don't provide the patch, it'll take some more time but I'll get
around to it sometime.
This is the core of what would be the patch:
my $crossprefix = check_arch($arch);
#(check_arch takes a user-specified string and checks that
#dpkg-architecture supports it, then returns the triplet so for 'arm',
# e.g. $crossprefix=arm-linux-gnu;
my @librarypaths = qw( /lib /usr/lib /lib32 /usr/lib32 /lib64 /usr/lib64
/emul/ia32-linux/lib /emul/ia32-linux/usr/lib );
my @shlibdeps = ( ${crossprefix}/lib, /usr/${crossprefix}/lib,
/${crossprefix}/lib32, /usr/${crossprefix}/lib32,
/${crossprefix}/lib64, /usr/${crossprefix}/lib64,
/emul/ia32-linux/lib, /emul/ia32-linux/usr/lib );
my $libpath = join (:, @librarypaths) . join (:, @shlibdeps);
$ENV{LD_LIBRARY_PATH}.=$libpath;
That is what I'm using with the current dpkg-shlibdeps from 1.14.11 and
AFAICT it is fine (providing that the cross paths are added to the
standard paths and not replace them or perl gets confused).
If this method is ok, I'll prepare the patch against 1.14.11.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
signature.asc
Description: OpenPGP digital signature
dpkg-deb breaks ALL cross building
dpkg 1.14.9
dpkg-dev 1.14.9
Try with a simple, really quick package that has just been patched to
cross-build successfully with emdebian-tools :
$ apt-get source hostname
$ cd hostname-2.94/
# comment out dh_shlibdeps to allow the build to complete
# (awaiting fix for 439979)
$ dpkg-buildpackage -aarm
dpkg-buildpackage: source package hostname
dpkg-buildpackage: source version 2.94em1
dpkg-buildpackage: source changed by Neil Williams [EMAIL PROTECTED]
dpkg-architecture: warning: Specified GNU system type arm-linux-gnu does
not match gcc system type x86_64-linux-gnu.
dpkg-buildpackage: host architecture arm
fakeroot debian/rules clean
dh_testdir
dh_testroot
rm -f build-stamp
# Cleaning package
/usr/bin/make clean
make[1]: Entering directory
`/opt/emdebian/trunk/h/hostname/trunk/hostname-2.94'
rm -f hostname.o hostname dnsdomainname
make[1]: Leaving directory
`/opt/emdebian/trunk/h/hostname/trunk/hostname-2.94'
dh_clean
dpkg-source -b hostname-2.94
dpkg-source: warning: source directory './hostname-2.94' is not
sourcepackage-upstreamversion 'hostname-2.94em1'
dpkg-source: building hostname in hostname_2.94em1.tar.gz
dpkg-source: building hostname in hostname_2.94em1.dsc
debian/rules build
dh_testdir
# Building package
CFLAGS=-Wall -g -O2 /usr/bin/make CC=arm-linux-gnu-gcc
make[1]: Entering directory
`/opt/emdebian/trunk/h/hostname/trunk/hostname-2.94'
arm-linux-gnu-gcc -O2 -Wall -c -o hostname.o hostname.c
arm-linux-gnu-gcc -O2 -Wall -o hostname hostname.o
ln -fs hostname dnsdomainname
make[1]: Leaving directory
`/opt/emdebian/trunk/h/hostname/trunk/hostname-2.94'
touch build-stamp
fakeroot debian/rules binary
dh_testdir
dh_testroot
dh_clean -k
dh_installdirs
# Installing package
/usr/bin/make install
BASEDIR=/opt/emdebian/trunk/h/hostname/trunk/hostname-2.94/debian/hostname
CC=arm-linux-gnu-gcc
make[1]: Entering directory
`/opt/emdebian/trunk/h/hostname/trunk/hostname-2.94'
install -d
/opt/emdebian/trunk/h/hostname/trunk/hostname-2.94/debian/hostname/usr/share/man/man1
install -o root -g root -m 0644 hostname.1
/opt/emdebian/trunk/h/hostname/trunk/hostname-2.94/debian/hostname/usr/share/man/man1
ln -fs hostname.1
/opt/emdebian/trunk/h/hostname/trunk/hostname-2.94/debian/hostname/usr/share/man/man1/dnsdomainname.1
install -d
/opt/emdebian/trunk/h/hostname/trunk/hostname-2.94/debian/hostname/bin
install -o root -g root -m 0755 hostname
/opt/emdebian/trunk/h/hostname/trunk/hostname-2.94/debian/hostname/bin
ln -f hostname
/opt/emdebian/trunk/h/hostname/trunk/hostname-2.94/debian/hostname/bin/dnsdomainname
make[1]: Leaving directory
`/opt/emdebian/trunk/h/hostname/trunk/hostname-2.94'
dh_testdir
dh_testroot
rm -f -r debian/hostname/usr/share/man/
dh_install
dh_link
dh_strip
dh_compress
dh_fixperms
dh_installdeb
dh_gencontrol
dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
dh_md5sums
dh_builddeb
dpkg-deb: building package `hostname' in `../hostname_2.94em1_amd64.deb'.
signfile hostname_2.94em1.dsc
gpg: skipped Neil Williams [EMAIL PROTECTED]: secret key not available
gpg: [stdin]: clearsign failed: secret key not available
dpkg-genchanges ../hostname_2.94em1_arm.changes
dpkg-genchanges: including full source code in upload
dpkg-buildpackage: full upload; Debian-native package (full source is
included)
Note:
dpkg-deb: building package `hostname' in `../hostname_2.94em1_amd64.deb'.
dpkg-genchanges ../hostname_2.94em1_arm.changes
What is going on?
The build clearly uses arm-linux-gnu-gcc, it builds an arm package
containing arm binaries (checked with 'file'), it creates an arm
.changes file but dpkg-deb gives me an amd64 suffix!!!
HELP! Can we have a 1.14.10 fix, like real, real soon?
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
signature.asc
Description: OpenPGP digital signature
Re: UNable to configure my package
On Wed, 26 Sep 2007 00:22:16 -0700 (PDT) varun_shrivastava [EMAIL PROTECTED] wrote: hi i have made a package which is a simple gtk application. it depends on gtk-directfb-2.0.so.0 , i included this library in the depends field in control file. That should be the -dev version of that package. libgtk-directfb-2.0-dev after creating the package when i try to install it using dpkg -i it displays following error dpkg: dependency problems prevent configuration of clock: clock depends on libgtk-directfb-2.0 (= 2.2); however: Package libgtk-directfb-2.0 is not installed. $ sudo apt-get install libgtk-directfb-2.0-0 the package is installed at /usr/local/lib but i did a make install You should not mix packaging systems - you still need to install the libgtk-directfb-2.0-dev binary package (which will bring in the libgtk-directfb-2.0-0 package as a dependency) using dpkg (via apt or aptitude). You must also ensure that your package builds against this version so that it will build on other Debian systems, including the autobuilders. dpkg cannot be expected to work with software that is installed directly from upstream source instead of from a Debian binary. for this library, i haven't installed it from a gtk-directfb package. Why not? You need to install the package in order to install any packages that use it. Also i found that as i have manually installed it, there is no gtk.shlibs file at /var/lib/dpkg/info/, so i manually wrote a shlibs.local file in debian/ directory for my package. but still i get this error Stop working around the lack of the Debian binary - install the binary from the Debian mirrors and if your package doesn't build against it, fix your package so that it does. If there is a bug in the Debian package that prevents your package from working, rebuild libgtk-directfb-2.0-0 from source, create a patch to fix that bug and report it to the Debian bug tracking system. You cannot expect to be able to install your package via dpkg if you have not also installed *all* the dependencies of that package via dpkg. Either you use: Debian -- libgtk-directfb-2.0-0 (/usr/local/) -- clock (/usr/local) or Debian == libgtk-directfb-2.0-0 (Debian) == clock (dpkg install) You cannot expect it to work as: Debian -- libgtk-directfb-2.0-0 (/usr/local/) == clock (dpkg install) (where -- represents building the upstream source directly and == represents installing a Debian package.) -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpZFowrPnrww.pgp Description: PGP signature
Re: UNable to configure my package
On Wed, 26 Sep 2007 02:30:36 -0700 (PDT) varun_shrivastava [EMAIL PROTECTED] wrote: thanks for the reply i want to add some information that i m using a cross compilation tool scratchbox Then you should look at Emdebian which has updated tools for cross-building using Debian sources. http://www.emdebian.org/ (Next time, please mention that you are cross-building as the very first thing you say because 99.999% of Debian people will try and answer from a *native* build perspective - even those who regularly cross-build a variety of packages, like me.) All the source code i have installed in scratchbox is using make install (not from the deb packages) So why are you trying to install your program using dpkg? dpkg: dependency problems prevent configuration of clock: clock depends on libgtk-directfb-2.0 (= 2.2); however: Package libgtk-directfb-2.0 is not installed. If you want to use dpkg to install clock, you must install libgtk-directfb-2.0-0 using dpkg too, irrespective of whether you are using scratchbox or emdebian-tools. So if i want to convert an application to deb package, first i need to convert all other source code (becoz i have made changes to them according to my requirement) that i have installed using make install, otherwise i wouldn't be able to make a deb package. But you cannot install that deb package without also installing the dependency as a deb as well. If you install a dependency of a package with 'sudo make install' then you must install the package with 'sudo make install' as well - you cannot revert to dpkg without also installing all dependencies via dpkg. I'm an Emdebian developer as well as a DD so I am used to cross-building Debian packages. However, I don't use scratchbox because (unless you are using scratchbox2) there are known bugs and it's quite out of date. If you want to work with upstream source, use OpenEmbedded. If you want to work with Debian packages, use Emdebian. If you want help on using scratchbox2, ask on the debian-embedded mailing list (where you'll find the scratchbox2 maintainer, me and various other cross-building types). Whatever you want, this problem is *not* in dpkg and there isn't any point continuing this thread here. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpyZhclwYCBV.pgp Description: PGP signature
Re: Bug#439979: reversed patches
On Sun, 23 Sep 2007 13:56:24 +0200
Frank Lichtenheld [EMAIL PROTECTED] wrote:
On Tue, Aug 28, 2007 at 09:39:40PM +0100, Neil Williams wrote:
The /usr/share/dpkg-cross/buildcross file is part of dpkg-cross 1.99
+2.0.0pre2 which is due to be uploaded to experimental just after pre1
leaves NEW.
[...]
--- dpkg.old/scripts/dpkg-buildpackage.sh 2007-08-27 23:23:28.0
+0100
+++ dpkg-1.14.5/scripts/dpkg-buildpackage.sh2007-08-28
20:06:39.0 +0100
@@ -84,6 +84,18 @@
passopts=''
admindir=''
+DPKGCROSSENABLE=0
+if [ -f /usr/share/dpkg-cross/buildcross ]; then
+ . /usr/share/dpkg-cross/buildcross
+ DPKGCROSSENABLE=1
+fi
+
+function enhance_cross {
+ if [ $DPKGCROSSENABLE -gt 0 ]; then
+ setup_cross
+ fi
+}
+
Just to make your life harder ;) I've now decided to convert
dpkg-buildpackage to a Perl script (see head of master branch
in git). Therefor this part of the patch doesn't apply anymore.
It isn't a problem - this is a workaround patch. Guillem doesn't want
the external lookup involved in the workaround, he wants an internal
solution. The perl version simply needs to implement the functionality
of setup_cross which, in turn, needs to setup and use a directory of
symlinks that are only in the PATH when cross-compiling and which allow
the command line paths passed to the cross-compiler to be manipulated
in real time to set the actual location of the cross header and -dev
package contents.
$args =~ s,/usr/include/,/usr/$arch_type/include/;
where $arch_type is arm-linux-gnu, for example, retrieved from
dpkg-architecture (which in turn is set by the -a switch).
That functionality is available as gccross in the dpkg-cross source at
the moment and could be implemented that way in dpkg -
dpkg-buildpackage just needs to setup the PATH to put the directory
containing gccross first.
http://alioth.debian.org/plugins/scmcvs/cvsweb.php/dpkg-cross/buildcross?rev=1.1;content-type=text%2Fplain;cvsroot=dpkg-cross
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgppt6qynGcrY.pgp
Description: PGP signature
Re: [RFC] dpkg-buildpackage: Convert from Shell to Perl
On Sun, 23 Sep 2007 19:28:16 + (UTC) Oleg Verych [EMAIL PROTECTED] wrote: 21-09-2007, Guillem Jover: Yes, such a rewrite has crossed my mind few times, I'd say go ahead! What's the problem in keepeing both? Maintenance time - think about why Emdebian wants the dpkg-cross diversions to be removed. 1. We've been maintaining the diverted code for a decade [0] and it's a PITA. Honest, there is NO WAY I want those diversions to make it into Lenny. What is the point of creating ANOTHER instance of the same problem? 2. During all that time, dpkg developers have been busy, emdebian developers have been busy but not with dpkg. Result? Pretty obvious really, the code in the diverted scripts are almost a decade out of date. Why on earth would Debian want two versions of the same thing when it is absolutely guaranteed that one or other version will be continuously out of date. [0] http://packages.debian.org/changelogs/pool/main/d/dpkg-cross/current/changelog I like shell (not bash) and i can not read perl. ? Why does your personal preference determine the choice of language of a script that you don't maintain ? As long as perl is not necessary to run the basic dpkg functions of install, remove and update, there isn't a problem. Embedded systems don't need perl (or bash) but embedded systems also won't be running dpkg-buildpackage. Anything capable of doing anything useful with dpkg-buildpackage won't have a problem running perl. I can do most of the packaging stuff with shell and sed. I can do *all* of the packaging stuff with Perl and CPAN. Last time I checked, neither you nor I are dpkg maintainers / uploaders so let's just work with those who have accepted the task of maintaining the code. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpd63TCbpIOi.pgp Description: PGP signature
Bug#439979: reversed patches
On Sun, 23 Sep 2007 13:56:24 +0200
Frank Lichtenheld [EMAIL PROTECTED] wrote:
On Tue, Aug 28, 2007 at 09:39:40PM +0100, Neil Williams wrote:
The /usr/share/dpkg-cross/buildcross file is part of dpkg-cross 1.99
+2.0.0pre2 which is due to be uploaded to experimental just after pre1
leaves NEW.
[...]
--- dpkg.old/scripts/dpkg-buildpackage.sh 2007-08-27 23:23:28.0
+0100
+++ dpkg-1.14.5/scripts/dpkg-buildpackage.sh2007-08-28
20:06:39.0 +0100
@@ -84,6 +84,18 @@
passopts=''
admindir=''
+DPKGCROSSENABLE=0
+if [ -f /usr/share/dpkg-cross/buildcross ]; then
+ . /usr/share/dpkg-cross/buildcross
+ DPKGCROSSENABLE=1
+fi
+
+function enhance_cross {
+ if [ $DPKGCROSSENABLE -gt 0 ]; then
+ setup_cross
+ fi
+}
+
Just to make your life harder ;) I've now decided to convert
dpkg-buildpackage to a Perl script (see head of master branch
in git). Therefor this part of the patch doesn't apply anymore.
It isn't a problem - this is a workaround patch. Guillem doesn't want
the external lookup involved in the workaround, he wants an internal
solution. The perl version simply needs to implement the functionality
of setup_cross which, in turn, needs to setup and use a directory of
symlinks that are only in the PATH when cross-compiling and which allow
the command line paths passed to the cross-compiler to be manipulated
in real time to set the actual location of the cross header and -dev
package contents.
$args =~ s,/usr/include/,/usr/$arch_type/include/;
where $arch_type is arm-linux-gnu, for example, retrieved from
dpkg-architecture (which in turn is set by the -a switch).
That functionality is available as gccross in the dpkg-cross source at
the moment and could be implemented that way in dpkg -
dpkg-buildpackage just needs to setup the PATH to put the directory
containing gccross first.
http://alioth.debian.org/plugins/scmcvs/cvsweb.php/dpkg-cross/buildcross?rev=1.1;content-type=text%2Fplain;cvsroot=dpkg-cross
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgpAerT0CQV0Q.pgp
Description: PGP signature
Bug#439979: dpkg-dev: Please support removal of dpkg-cross diversions
Package: dpkg
Version: 1.14.5
Severity: normal
Tags: patch
As outlined on the debian-dpkg lists, I've been testing the removal of
the dpkg-cross diversions of dpkg-buildpackage and dpkg-shlibdeps during
the rewrite of dpkg-cross and I now have two patches (slightly modified
from the last ones posted to the list) that I would like to see in
dpkg-dev as a beginning to a process to merge dpkg-cross back into dpkg.
The first part is to remove the diversions and requires PATH and
environment changes within 'dpkg-buildpackage -a' via a small set of
shell functions provided by dpkg-cross. Cross support for dpkg-shlibdeps
needs a few more PATH changes and a dependency on binutils-multiarch.
Once these patches are included, maybe the shell functions and the
existing cross-config.$arch files can also be merged into dpkg-dev,
leaving dpkg-cross with the original task of preparing foreign shared
objects as Architecture:all packages that can be installed into
/usr/$arch-triplet/lib etc. to make the libraries and headers accessible
to the cross-compiler.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.21-2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages dpkg depends on:
ii coreutils 5.97-5.4 The GNU core utilities
ii libc6 2.6.1-1GNU C Library: Shared libraries
dpkg recommends no packages.
-- no debconf information
--- dpkg-1.14.5/scripts/dpkg-buildpackage.sh2007-08-28 20:06:39.0
+0100
+++ dpkg.old/scripts/dpkg-buildpackage.sh 2007-08-27 23:23:28.0
+0100
@@ -84,18 +84,6 @@
passopts=''
admindir=''
-DPKGCROSSENABLE=0
-if [ -f /usr/share/dpkg-cross/buildcross ]; then
- . /usr/share/dpkg-cross/buildcross
- DPKGCROSSENABLE=1
-fi
-
-function enhance_cross {
- if [ $DPKGCROSSENABLE -gt 0 ]; then
- setup_cross
- fi
-}
-
while [ $# != 0 ]
do
value=`echo x\$1\ | sed -e 's/x--.*=//;s/^x-.//'`
@@ -116,7 +104,7 @@
-us)signsource=: ;;
-uc)signchanges=: ;;
-ap)usepause=true;;
- -a*)targetarch=$value; checkbuilddep=false; enhance_cross ;;
+ -a*)targetarch=$value; checkbuilddep=false ;;
-si)sourcestyle=-si ;;
-sa)sourcestyle=-sa ;;
-sd)sourcestyle=-sd ;;
--- dpkg-1.14.5/scripts/dpkg-shlibdeps.pl 2007-08-28 00:02:16.0
+0100
+++ dpkg.old/scripts/dpkg-shlibdeps.pl 2007-08-27 23:23:48.0 +0100
@@ -75,16 +75,6 @@
), $progname, join(/,@depfields);
}
-# detect cross-compilation
-my $result = `dpkg-architecture -qDEB_HOST_ARCH`;
-chomp($result);
-my $host_arch = $result;
-$result = `dpkg-architecture -qDEB_BUILD_ARCH`;
-chomp($result);
-my $target_arch = $result;
-my $use_cross = 0;
-$use_cross = 1 if ($host_arch ne $target_arch);
-
my ($stdout, @exec, @execfield);
foreach (@ARGV) {
if (m/^-T/) {
@@ -144,21 +134,8 @@
}
}
-my @librarypaths=();
-if ($use_cross)
-{
-my $crossprefix = `dpkg-architecture -qDEB_HOST_GNU_TYPE`;
-chomp($crossprefix);
-@librarypaths = ( ${crossprefix}/lib, /usr/${crossprefix}/lib,
-/${crossprefix}/lib32, /usr/${crossprefix}/lib32,
-/${crossprefix}/lib64, /usr/${crossprefix}/lib64,
-/emul/ia32-linux/lib, /emul/ia32-linux/usr/lib );
-}
-else
-{
-@librarypaths = qw( /lib /usr/lib /lib32 /usr/lib32 /lib64 /usr/lib64
- /emul/ia32-linux/lib /emul/ia32-linux/usr/lib );
-}
+my @librarypaths = qw( /lib /usr/lib /lib32 /usr/lib32 /lib64 /usr/lib64
+ /emul/ia32-linux/lib /emul/ia32-linux/usr/lib );
my %librarypaths = map { $_ = 'default' } @librarypaths;
if ($ENV{LD_LIBRARY_PATH}) {
Bug#439979: reversed patches
Bah!
Patches were the wrong way around. Try these.
The /usr/share/dpkg-cross/buildcross file is part of dpkg-cross 1.99
+2.0.0pre2 which is due to be uploaded to experimental just after pre1
leaves NEW.
dpkg-cross will need to depend on the version of dpkg-dev that includes
these patches before migrating into unstable.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
--- dpkg.old/scripts/dpkg-buildpackage.sh 2007-08-27 23:23:28.0 +0100
+++ dpkg-1.14.5/scripts/dpkg-buildpackage.sh 2007-08-28 20:06:39.0 +0100
@@ -84,6 +84,18 @@
passopts=''
admindir=''
+DPKGCROSSENABLE=0
+if [ -f /usr/share/dpkg-cross/buildcross ]; then
+ . /usr/share/dpkg-cross/buildcross
+ DPKGCROSSENABLE=1
+fi
+
+function enhance_cross {
+ if [ $DPKGCROSSENABLE -gt 0 ]; then
+ setup_cross
+ fi
+}
+
while [ $# != 0 ]
do
value=`echo x\$1\ | sed -e 's/x--.*=//;s/^x-.//'`
@@ -104,7 +116,7 @@
-us) signsource=: ;;
-uc) signchanges=: ;;
-ap) usepause=true;;
- -a*)targetarch=$value; checkbuilddep=false ;;
+ -a*)targetarch=$value; checkbuilddep=false; enhance_cross ;;
-si) sourcestyle=-si ;;
-sa) sourcestyle=-sa ;;
-sd) sourcestyle=-sd ;;
--- dpkg.old/scripts/dpkg-shlibdeps.pl 2007-08-27 23:23:48.0 +0100
+++ dpkg-1.14.5/scripts/dpkg-shlibdeps.pl 2007-08-28 00:02:16.0 +0100
@@ -75,6 +75,16 @@
), $progname, join(/,@depfields);
}
+# detect cross-compilation
+my $result = `dpkg-architecture -qDEB_HOST_ARCH`;
+chomp($result);
+my $host_arch = $result;
+$result = `dpkg-architecture -qDEB_BUILD_ARCH`;
+chomp($result);
+my $target_arch = $result;
+my $use_cross = 0;
+$use_cross = 1 if ($host_arch ne $target_arch);
+
my ($stdout, @exec, @execfield);
foreach (@ARGV) {
if (m/^-T/) {
@@ -134,8 +144,21 @@
}
}
-my @librarypaths = qw( /lib /usr/lib /lib32 /usr/lib32 /lib64 /usr/lib64
- /emul/ia32-linux/lib /emul/ia32-linux/usr/lib );
+my @librarypaths=();
+if ($use_cross)
+{
+my $crossprefix = `dpkg-architecture -qDEB_HOST_GNU_TYPE`;
+chomp($crossprefix);
+@librarypaths = ( ${crossprefix}/lib, /usr/${crossprefix}/lib,
+/${crossprefix}/lib32, /usr/${crossprefix}/lib32,
+/${crossprefix}/lib64, /usr/${crossprefix}/lib64,
+/emul/ia32-linux/lib, /emul/ia32-linux/usr/lib );
+}
+else
+{
+@librarypaths = qw( /lib /usr/lib /lib32 /usr/lib32 /lib64 /usr/lib64
+ /emul/ia32-linux/lib /emul/ia32-linux/usr/lib );
+}
my %librarypaths = map { $_ = 'default' } @librarypaths;
if ($ENV{LD_LIBRARY_PATH}) {
pgpsoQs66dx5H.pgp
Description: PGP signature
Preliminary patches to remove dpkg-cross diversions
OK, I now have two patches (and a dummy changelog patch that just acts
to separate these changes from the existing dpkg packages) attached. I
also have maintainer script changes that remove any previous dpkg-cross
diversions upon installation of / upgrade to the new code.
dpkg-cross pre2 now depends on binutils-multiarch and this makes the
patches to dpkg-buildpackage and dpkg-shlibdeps in dpkg almost trivial.
Most of the detailed work in the enhanced 'dpkg-buildpackage -a' is done
by scripts provided by dpkg-cross but the patch to dpkg-shlibdeps
completely replaces the previous dpkg-cross code, courtesy of
binutils-multiarch, by checking the values returned by
dpkg-architecture.
I'm continuing to test the dpkg-cross code so the patches are submitted
here for review really. Once testing is complete I can submit a bug
report with the patches if that is preferable.
dpkg-cross will need to depend on the version of dpkg-dev that contains
the final versions of these patches *before* it leaves experimental.
For now, the old versions of the dpkg-cross scripts will be retained
in /usr/share/dpkg-cross/ to support bespoke configurations, corner
cases and other situations where the rewrite still needs work.
The changes in dpkg-dev are almost trivial (and, I hope,
self-explanatory after my previous posts).
Finally, this means that bug reports filed against dpkg for native
builds cannot be confused by having dpkg-cross also installed. The
dpkg-cross code is only called during a cross-build - i.e. only when
the -a option is supplied to dpkg-buildpackage.
With dpkg-cross pre2, the diversions are gone for good.
;-)
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
--- dpkg-1.14.5/scripts/dpkg-buildpackage.sh 2007-08-27 13:14:12.0 +0100
+++ dpkg.new/scripts/dpkg-buildpackage.sh 2007-08-27 13:14:49.0 +0100
@@ -84,6 +84,18 @@
passopts=''
admindir=''
+DPKGCROSSENABLE=0
+if [ -f /usr/share/dpkg-cross/buildcross ]; then
+ . /usr/share/dpkg-cross/buildcross
+ DPKGCROSSENABLE=1
+fi
+
+function enhance_cross {
+ if [ $DPKGCROSSENABLE -gt 0 ]; then
+ setup_cross
+ fi
+}
+
while [ $# != 0 ]
do
value=`echo x\$1\ | sed -e 's/x--.*=//;s/^x-.//'`
@@ -104,7 +116,7 @@
-us) signsource=: ;;
-uc) signchanges=: ;;
-ap) usepause=true;;
- -a*)targetarch=$value; checkbuilddep=false ;;
+ -a*)targetarch=$value; checkbuilddep=false; enhance_cross ;;
-si) sourcestyle=-si ;;
-sa) sourcestyle=-sa ;;
-sd) sourcestyle=-sd ;;
@@ -181,7 +193,7 @@
if test $signinterface = gpg ; then
(cat ../$1 ; echo ) | \
$signcommand --local-user ${signkey:-$maintainer} --clearsign --armor \
- --textmode ../$1.asc
+ --textmode ../$1.asc
else
$signcommand -u ${signkey:-$maintainer} +clearsig=on -fast ../$1 \
../$1.asc
@@ -226,7 +238,7 @@
cd ..; withecho dpkg-source $passopts $diffignore $tarignore -b $dirn; cd $dirn
fi
if [ x$sourceonly = x ]; then
- withecho debian/rules build
+ withecho debian/rules build
withecho $rootcommand debian/rules $binarytarget
fi
if [ $usepause = true ] \
@@ -251,7 +263,7 @@
fir=$?
set -e
return $fir
-}
+}
if fileomitted '\.deb'; then
--- dpkg.new/debian/changelog 2007-08-27 13:04:42.0 +0100
+++ dpkg-1.14.5/debian/changelog 2007-08-27 13:24:56.0 +0100
@@ -1,3 +1,11 @@
+dpkg (1.14.5.1) unstable; urgency=low
+
+ * Dummy entry to test the patches.
+ * Include patches to support removal of dpkg-cross diversions
+ for dpkg-buildpackage and dpkg-shlibdeps
+
+ -- Neil Williams [EMAIL PROTECTED] Mon, 27 Aug 2007 12:58:20 +0100
+
dpkg (1.14.5) unstable; urgency=low
[ Guillem Jover ]
--- dpkg-1.14.5/scripts/dpkg-shlibdeps.pl 2007-08-27 13:14:06.0 +0100
+++ dpkg.new/scripts/dpkg-shlibdeps.pl 2007-08-27 13:16:46.0 +0100
@@ -75,6 +75,16 @@
), $progname, join(/,@depfields);
}
+# detect cross-compilation
+my $result = `dpkg-architecture -qDEB_HOST_ARCH`;
+chomp($result);
+my $host_arch = $result;
+$result = `dpkg-architecture -qDEB_BUILD_ARCH`;
+chomp($result);
+my $target_arch = $result;
+my $use_cross = 0;
+$use_cross = 1 if ($host_arch ne $target_arch);
+
my ($stdout, @exec, @execfield);
foreach (@ARGV) {
if (m/^-T/) {
@@ -134,8 +144,16 @@
}
}
-my @librarypaths = qw( /lib /usr/lib /lib32 /usr/lib32 /lib64 /usr/lib64
- /emul/ia32-linux/lib /emul/ia32-linux/usr/lib );
+my $crossprefix = '/';
+if ($use_cross)
+{
+ $crossprefix = `dpkg-architecture -qDEB_HOST_GNU_TYPE`;
+ chomp($crossprefix);
+ $crossprefix = $crossprefix/;
+}
+my @librarypaths = ( ${crossprefix}lib, /usr/${crossprefix}lib, ${crossprefix}lib32,
+ /usr/${crossprefix}lib32, ${crossprefix}lib64, /usr/${crossprefix}lib64,
+ /emul/ia32-linux/lib, /emul/ia32-linux/usr/lib );
my %librarypaths = map { $_ = 'default' } @librarypaths;
if ($ENV{LD_LIBRARY_PATH}) {
pgppnf0ZpvY26.pgp
Description: PGP signature
Re: Preliminary patches to remove dpkg-cross diversions
On Mon, 27 Aug 2007 14:26:07 +0100 Neil Williams [EMAIL PROTECTED] wrote: OK, I now have two patches (and a dummy changelog patch that just acts to separate these changes from the existing dpkg packages) attached. I also have maintainer script changes that remove any previous dpkg-cross diversions upon installation of / upgrade to the new code. Bah! There are a few whitespace changes in the previously attached patches. I thought I'd cleared those. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgp55vMMfRu0k.pgp Description: PGP signature
Removing the dpkg-buildpackage diversion in dpkg-cross
I now have a replacement shell library (it's only 60 lines) that
replicates the functions of the dpkg-buildpackage diversion script from
dpkg-cross (which was perl) and with a few more tests I will be able to
submit this as a patch to the dpkg-buildpackage script in dpkg-dev. With
other changes to dpkg-shlibdeps to merge that into dpkg-dev, I
anticipate this construction:
1. dpkg-dev does not need to depend on dpkg-cross
2. dpkg-cross Enhances: dpkg-dev, Depends: dpkg-dev (= 1.15)
3. This code (or something quite like it) in dpkg-buildpackage from
dpkg-dev (somewhere around line 87-ish):
DPKGCROSSENABLE=0
if [ -f /usr/share/dpkg-cross/buildcross ]; then
. /usr/share/dpkg-cross/buildcross
DPKGCROSSENABLE=1
fi
function enhance_cross {
if [ $DPKGCROSSENABLE -gt 0 ]; then
setup_cross
fi
}
The '-a' switch to dpkg-buildpackage then calls a new function, patched
into dpkg-dev:
...
-a*)targetarch=$value; checkbuilddep=false; enhance_cross ;;
...
setup_cross comes from the new dpkg-cross file and basically implements
the path and environment changes within the dpkg-dev version of
dpkg-buildpackage to access /usr/share/dpkg-cross/bin/gccross and
cross-config.$arch files. gccross rewrites the @ARGV during the build
to ensure that the cross-compiler locates the correct headers and
shared object files. cross-config.$arch provides common cached values
for ./configure on the requested arch.
This way, the patch to dpkg-dev is trivial and debian-embedded can
update all the relevant files as often as needed without affecting
dpkg. (We don't need to bug you for future updates!) It's so trivial,
it could almost go in as-is - I just need to finish the dpkg-shlibdeps
code.
The remaining changes are in gccross and porting the dpkg-cross
dpkg-shlibdeps diversion code into the dpkg-dev version (both are perl)
to use the binutils-mulitarch versions of objdump and strip.
dpkg-cross can then remove the dpkg-buildpackage and dpkg-shlibdeps
diversions and relocate the scripts into /usr/share/dpkg-cross
alongside the old versions of objcopy, objdump and strip for
reference / trouble-shooting. The final dpkg-cross 2.0.0 release will
remove the files completely. Only dpkg-cross goes into /usr/bin/. I'm
thinking that we could have a /usr/share/dpkg-cross/bin/gccross so that
there is no chance of the old scripts being called accidentally. It
seems strange to have a bin/ below share/ but I'm not sure what else to
call it at the moment. The only file on my system in a similar location
is /usr/share/openoffice/bin/openoffice-xlate-lang which is also a perl
script.
This will be in dpkg-cross 1.99+2.0.0pre2 (experimental) - although
pre1 is yet to leave NEW. :-(
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgpLM4jAfTngE.pgp
Description: PGP signature
Re: migrating dpkg-cross diversions into dpkg-dev (was Dependencies on shared libs)
On Fri, 24 Aug 2007 14:44:01 +0200
Raphael Hertzog [EMAIL PROTECTED] wrote:
The second stage is to replace the dpkg-shlibdeps diversion too. It has
to identify the shared dependencies of a foreign binary, then look up
the packages that provide those. It needs updating because it is
currently somewhere around dpkg-dev 1.10. The standard dpkg method has
to be adapted for cross-building because you can't read the binaries
normally.
If dpkg-cross can depend on binutils-multiarch, then dpkg-shlibdeps needs
no modification to be able to read binaries.
I'll look into that. I know there's been a lot of discussion around
multiarch in the past. I'll have to check on the current status.
Furthermore it's already smart enough to ignore libraries which are
incompatible (another type reported by objdump -a).
Alternatively, dpkg-shlibdeps could do the complete job and check the
alternative dpkg data itself when in cross-compiling mode.
We could detect that cross-compiling mode simply because the analyzed
binaries do not match the host binaries.
Is it possible to use a more routine method of checking the values
returned by dpkg-architecture?
(e.g. in makefile syntax)
DEB_HOST_GNU_TYPE=$(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
DEB_BUILD_GNU_TYPE=$(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
(On the basis of the line of least surprise for existing
cross-builders?)
How is $crossroot supposed to be defined ?
Currently, it is read in from a dpkg-cross configuration file. Any
other method could be arranged. $crossroot isn't that common, yet,
because Emdebian has been working primarily with the rootfs and there
has been only limited opportunity for splitting packages or using
optional dependencies. It is part of why I need to do after these
dpkg-cross changes in order to build an Emdebian distribution based on
GPE and Gtk.
Although I wish to remove the diversions, there is clearly still going
to be a need for dpkg-cross when actually cross-building packages. Even
when building a toolchain or rootfs, libraries need to be processed by
dpkg-cross to make the foreign binary available to the build process
in /usr/${archtriplet}/lib and include/.
There is also a need for the cross-config.$arch files that are
currently part of dpkg-cross. These are cache values read in for
autotools builds that describe the common differences between the build
and host architectures so that ./configure gets sensible values that
actually work on the host, despite what would have been generated
normally on the build arch. These config values are read in
by ./configure using the CONFIG_SITE variable.
How can we map the elf type to the archtriplet ?
dpkg-cross already has a working perl table to do this. It is
incomplete but has sufficient coverage for the current cross-building
requirements. (%archdetecttable in Debian::DpkgCross. See also %
crossprefixtable).
Debian::DpkgCross is still a work-in-migration so the documentation is
quite poor, even if I say so myself. I can't really improve that until
the codebase within the module has had a chance to settle, which in
turn means deciding issues like $crossroot, %archtable etc.
%archtable has recently been remapped to use dpkg-architecture wherever
possible but it does still map some architectures that
dpkg-architecture either does not define or defines differently:
%archtable = (
'armeb' = 'armeb-linux-gnueabi', #XXX This differs from
dpkg-architecture
'hurd-i386' = 'i386-gnu',#XXX This differs from
dpkg-architecture
's390x' = 's390-linux-gnu', #XXX This differs from
dpkg-architecture
'openbsd-i386' = 'i386-openbsd', #XXX This differs from
dpkg-architecture
'freebsd-i386' = 'i386-freebsd', #XXX This differs from
dpkg-architecture
'darwin-i386' = 'i386-darwin', #XXX This differs from
dpkg-architecture
'win32-i386' = 'i386-cygwin'
);
dpkg-architecture values:
armeb = armeb-linux-gnu
hurd-i386 = i486-gnu
s390x = s390x-linux-gnu
openbsd-i386 = i486-openbsd
freebas-i386 = i486-freebsd
darwinbsd-i386 is unknown to dpkg-architecture
win32-i386 is unknown to dpkg-architecture
These remaining issues need to be discussed on debian-embedded. (My
internet connection has become quite brittle in the last few days so
discussion on IRC is difficult. I'll raise these remaining
discrepancies on the mailing list.)
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgpX3p31AX0zJ.pgp
Description: PGP signature
