Bug#480718: buildd.emdebian.org: Unable to update gnome-vfs, new version fails to cross build - Debian

This is a discussion on Bug#480718: buildd.emdebian.org: Unable to update gnome-vfs, new version fails to cross build - Debian ; Package: general Severity: normal User: codehelp@debian.org In preparation for a pseudo-package, buildd.emdebian.org, I'm filing status bugs about packages that fail to crossbuild successfully, despite building successfully in the past. i.e. where an existing package in Emdebian cannot be updated because ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Bug#480718: buildd.emdebian.org: Unable to update gnome-vfs, new version fails to cross build

  1. Bug#480718: buildd.emdebian.org: Unable to update gnome-vfs, new version fails to cross build

    Package: general
    Severity: normal
    User: codehelp@debian.org

    In preparation for a pseudo-package, buildd.emdebian.org, I'm filing
    status bugs about packages that fail to crossbuild successfully, despite
    building successfully in the past. i.e. where an existing package in
    Emdebian cannot be updated because the new version fails in a new and
    different way.
    :-(

    $ emsource --status gnome-vfs
    Checking the apt-cross cache is up to date for arm.
    Checking status of gnome-vfs in /opt/emdebian/trunk/g/gnome-vfs/trunk/
    5 emdebian patch files
    0 debian patch files

    Checking emdebuild status in /opt/emdebian/trunk/g/gnome-vfs/trunk/
    gnome-vfs may be out of date.
    Checking for error logs in /opt/emdebian/trunk/g/gnome-vfs/trunk/
    Checking bug status
    No open cross-building bugs for gnome-vfs
    gnome-vfs FAILED to build.

    $ tail
    /opt/emdebian/trunk/g/gnome-vfs/trunk/gnome-vfs_1:2.22.0-2em1_arm.build
    checking for Solaris ACL... no
    checking for POSIX ACL... yes
    checking for acl_extended_file... no
    checking pwd.h usability... yes
    checking pwd.h presence... yes
    checking for pwd.h... yes
    checking for posix getpwuid_r... configure: error: cannot run test
    program while cross compiling
    See `config.log' for more details.
    make: *** [config.status] Error 1
    dpkg-buildpackage: failure: debian/rules build gave error exit status 2



    -- System Information:
    Debian Release: lenny/sid
    APT prefers unstable
    APT policy: (500, 'unstable')
    Architecture: amd64 (x86_64)

    Kernel: Linux 2.6.22-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



    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  2. Re: Bug#480718: buildd.emdebian.org: Unable to update gnome-vfs, new version fails to cross build

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)
    Comment: Joerg Jaspert -- Debian Developer

    iD8DBQFIJ1fHcV7WoH57iskRApcpAJ0QTF7RM8ly4sGLjunSjA 5jSRl1IgCfXaoV
    gjIdEnbgaDYkGrLiHPhK2r8=
    =8zV+
    -----END PGP SIGNATURE-----

  3. Re: Bug#480718: buildd.emdebian.org: Unable to update gnome-vfs, new version fails to cross build

    On Sun, 2008-05-11 at 22:31 +0200, Joerg Jaspert wrote:
    > On 11382 March 1977, Neil Williams wrote:
    >
    > > Package: general
    > > Severity: normal
    > > User: codehelp@debian.org
    > > In preparation for a pseudo-package, buildd.emdebian.org, I'm filing

    >
    > Yes, as flooding -devel with lots of useless stuff (for -devel) is *THE*
    > way to get those responsible for pseudo packages to add it.
    >
    > *NOT*



    OK, I'm using quiet now so there should be no more CC'd reports to
    -devel with the next batch of reports. Sorry for the noise.

    --


    Neil Williams
    =============
    http://www.data-freedom.org/
    http://www.nosoftwarepatents.com/
    http://www.linux.codehelp.co.uk/



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

    iD8DBQBIKCYLiAEJSii8s+MRApULAJ98tFPfh8Ik/Z6gMb50SJ1BnmxRjgCeKPY2
    7UL5IUVqXogWrDLniyo62mY=
    =VKFe
    -----END PGP SIGNATURE-----


  4. Re: Bug#480718: buildd.emdebian.org: Unable to update gnome-vfs, new version fails to cross build

    On Mon, 12 May 2008, Neil Williams wrote:
    > On Sun, 2008-05-11 at 22:31 +0200, Joerg Jaspert wrote:
    > > On 11382 March 1977, Neil Williams wrote:
    > >
    > > > Package: general
    > > > Severity: normal
    > > > User: codehelp@debian.org
    > > > In preparation for a pseudo-package, buildd.emdebian.org, I'm filing

    > >
    > > Yes, as flooding -devel with lots of useless stuff (for -devel) is *THE*
    > > way to get those responsible for pseudo packages to add it.
    > >
    > > *NOT*

    >
    > OK, I'm using quiet now so there should be no more CC'd reports to
    > -devel with the next batch of reports. Sorry for the noise.


    Why are you filing those against "general" and not the respective
    packages?

    As a maintainer, I would have no problem receiving such reports
    if they are filed with a severity minor. Then you use some usertags to get
    a global view of all the open issues distribution-wise.

    In fact, I think that it makes more sense than using a pseudo-package.

    Cheers,
    --
    Raphaël Hertzog

    Le best-seller français mis à jour pour Debian Etch :
    http://www.ouaza.com/livre/admin-debian/


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  5. Re: buildd.emdebian.org pseudo-package and Emdebian bugs

    On Mon, 2008-05-12 at 13:47 +0200, Raphael Hertzog wrote:
    > On Mon, 12 May 2008, Neil Williams wrote:
    > >
    > > OK, I'm using quiet now so there should be no more CC'd reports to
    > > -devel with the next batch of reports. Sorry for the noise.

    >
    > Why are you filing those against "general" and not the respective
    > packages?


    I hope I covered that earlier:

    http://lists.debian.org/debian-devel.../msg00176.html

    1. When a package, foo, has been crossbuilt successfully but cannot be
    uploaded because a dependency, bar, is failing to cross build, file a
    bug against buildd.emdebian.org showing foo as Blocked by #number in
    bar. The bug report against bar would be a normal BTS report against
    that package, tagged "crossbuilt". (I need easily available data on
    which packages are causing the most trouble.)
    e.g.:
    #465248 bar: mass bug filing for cross building support.
    Tags: crossbuilt.
    ....
    # 465mumble : buildd.emdebian.org [foo] {arm} : new version available.
    Blocked by #465248

    Emdebian has custom scripts to detect these situations (using
    edos-debcheck) because the normal method of relying on a pbuilder /
    chroot build cannot pick up these cross-building dependency issues. This
    bug type would not normally occur in Debian - the package would simply
    FTBFS due to a missing dependency but still be installable.

    2. When a package has had a crossbuilding fix applied but still needs
    nodocs support or nochecks support implemented via debhelper etc., file
    a bug against the pseudo-package, again, blocked by the debhelper or
    cdbs bug. If the package installs docs with direct calls to 'install' or
    'cp', file a bug against the Debian package instead. It's not the fault
    of the foo maintainer using dh_installman that debhelper doesn't use the
    DEB_BUILD_OPTIONS="nodocs" variable but Emdebian still needs to track
    which packages are waiting for which bugs.

    3. When a package has been crossbuilt and uploaded but the installed
    package does not behave as the Debian package would behave - i.e. where
    crossbuilding might have introduced a new bug by changing dependencies
    or removing a file that should be included. Emdebian has changed the
    build environment created by the Debian maintainer to meet our own
    requirements (which may well conflict with Debian requirements), it's
    not the fault of the maintainer that the change causes a breakage, nor
    is it really up to that maintainer to fix the breakage.

    4. When a package has unwanted dependencies in Emdebian - typically
    because the Emdebian package needs to be built with --disable-foo
    instead of --enable-foo. (Note that {4} may cause {3} - in which case a
    functional package split or a new generated package may be needed to
    have both build options available as separate packages).

    5. One pseudo-package for all Emdebian architectures, just use the
    [package]-{$ARCH} prefix in bug titles - including
    [package]-{i386-linux-uclibc} where appropriate. I'll be starting on
    prebuilt packages for armel and i386 soon and experimental uClibc
    support is already available in emdebian-tools (>= 1.0.0).

    6. The majority of these bug reports against buildd.emdebian.org would
    be automatically generated. The existing embug script in emdebian-tools
    already uses SOAP to get information on existing bugs, it can migrate to
    storing bug information in the BTS under this pseudo-package instead of
    only being able to create a local log file.

    7. Where a crossbuilt package now fails the lintian test for cross-built
    packages (lintian -ioC em) e.g. when the lintian check script provided
    by emdebian-tools is updated. (Packages are not uploaded if the build
    fails the cross-building lintian test.)

    I have been tracking these with just local files but that isn't any use
    for others who want to use Emdebian and need to find out why a package
    isn't up to date.

    The basic premise of using buildd.emdebian.org as a usertag and
    eventually pseudo-package is that the problem does not necessarily lie
    within the Debian package. The bug report is filed to indicate the
    reason why a package cannot be uploaded - i.e. buildd.emdebian.org is
    insta-buggy as soon as one of the ~220 source packages in the Emdebian
    target repository are updated in Debian Sid. Once a cross-building
    buildd is available, buildd.emdebian.org can try to update the package
    itself before the bug is filed - in effect, becoming like an unofficial
    Debian port for emdebian-arm, emdebian-armel and emdebian-i386 (which
    isn't actually cross built, just uses Emdebian patches to reduce package
    size and dependencies). Not all bugs against buildd.emdebian.org are
    related to crossbuilding, some are down to differences between Debian
    Policy and Emdebian Policy. Due to the difficulties of debugging
    cross-built packages, Emdebian requires that every package complies with
    Emdebian Policy before upload, so lintian errors from the Emdebian
    checks are fatal build errors - a big difference to normal Debian
    methods.

    http://wiki.debian.org/EmdebianPolicy

    Where Debian Policy conflicts with Emdebian Policy (e.g. manpages and
    changelogs), I file bugs against the relevant build tools (like
    debhelper #448615 or CDBS #450483) in Debian so that DEB_BUILD_OPTIONS
    can be used to allow one package to build for both policies, tracking
    the packages waiting for the bug fix via buildd.emdebian.org bugs.

    > As a maintainer, I would have no problem receiving such reports
    > if they are filed with a severity minor. Then you use some usertags to get
    > a global view of all the open issues distribution-wise.


    I do that too - although I generally wait until I have at least some
    idea of how to fix the bug and then attach a patch to a wishlist bug.
    Cross-building can still be awkward in Debian and I find that it is hard
    enough getting cross-building patches applied without expecting
    maintainers to set up an Emdebian toolchain, install the tools, obtain
    the patches and use customised build scripts to prepare a test build -
    all of which are unfamiliar to most maintainers. I'm getting closer to a
    situation where this would not be so much work but right now, I'm not
    sure that many maintainers would have the motivation to fix and test the
    cross-building bugs themselves. The fixes in dpkg have been a
    significant benefit and some packages do crossbuild without any changes
    but more work is needed to get the rest to work in the same manner.

    Other bugs, like support for DEB_BUILD_OPTIONS="nodocs" (and "nocheck"),
    I will file against the relevant Debian packages because those fixes are
    generally obvious to the maintainer and easy to test with standard
    Debian build tools. I'll probably use a usertag of "emdebian-policy" for
    such reports.

    I use the "crossbuilt" usertag (which I have requested to be converted
    into the "crossbuilding" BTS tag in #480511) for failures in the
    crossbuild itself.

    There are also other issues like the whole question of cache files that
    need to be thought through before I can expect packages to cross-build
    without any changes whatsoever. (cache files have a high chance of going
    stale without breaking the build but changing all those m4 macros to not
    fail if cross-compiling is going to take time.)

    Current packages needing cache files:
    apt, avahi, coreutils, dbus-glib, dbus, devmapper, dpkg, glib2.0, gnupg,
    krb5, libidl, libopenobex, mktemp, ntp, orbit2, psmisc, shadow, sqlite,
    startup-notification, tar, tslib, usbutils, util-linux, xorg-server,
    xserver-xorg-input-mouse

    (there are 26 in total - you can find the cache file values at
    http://buildd.emdebian.org/svn/brows.../target/trunk/ under
    initial letter/, source package
    name/trunk/emdebian-arm-linux-gnu.cache.patch, e.g.
    http://buildd.emdebian.org/svn/brows...tch?format=txt

    (Yes, those need to be more accessible too.)

    (dpkg cache file is just dpkg_cv_va_copy=yes - see around line 11728
    of ./configure in the dpkg source.)

    One way around such small cache files would be for the ./configure
    script to support a --enable-foo or --with-foo option that can be
    enabled with another DEB_BUILD_OPTION - fine for variables that are
    actually just GNU|non-GNU tests but other variables are likely to be
    change between architectures so that could get messy. Adding the cache
    values to /etc/dpkg-cross/cross-config.arm is just as likely to result
    in stale values as keeping the value in an Emdebian patch. The real fix
    is for the relevant ./configure snippet to not fail if
    cross_compiling=yes and come up with another way of determining the
    value without trying to run a compiled executable during ./configure.
    Most current cache files are less than 6 lines, most values are also
    unique to each package, AFAICT none are common to more than two or three
    different packages.

    > In fact, I think that it makes more sense than using a pseudo-package.


    Maybe what I need is a list of maintainers who would be willing to spend
    the time preparing a cross building environment (emdebian-tools supports
    pbuilder-type builds) and who are willing to have bug reports without
    patches. Even with those, I would still need to track updated versions
    and Emdebian Policy issues in a buildd.emdebian.org pseudo-package.

    I still have a very small number of packages, overall, but it is more
    than enough work for one person (what with continuing the development of
    the tools at the same time). I'm hoping to use buildd.emdebian.org as a
    tracker for Emdebian - probably with quite a high turnover of bugs.

    I am also hoping that the activity in the BTS will help others start on
    Emdebian development by clearly documenting what is working, where the
    problems lie and what still needs to be done. Currently, most of the
    knowledge on how to fix certain cross-building issues is buried in the
    Emdebian patches - hopefully by putting more detail into the BTS, I can
    assist others who want to learn how to cross-build their own packages -
    especially with regard to Maemo, Qt and other environments that I simply
    won't have time to build or debug.

    --


    Neil Williams
    =============
    http://www.data-freedom.org/
    http://www.nosoftwarepatents.com/
    http://www.linux.codehelp.co.uk/



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

    iD8DBQBIKEsLiAEJSii8s+MRAtjdAKCMAJOvf5igTOGnBzA72V IXQGTJ/QCeJtlD
    XfDYlwFQjlWDMBqPyJqdg5E=
    =lKzb
    -----END PGP SIGNATURE-----


  6. Re: Bug#480718: buildd.emdebian.org: Unable to update gnome-vfs, new version fails to cross build

    On Mon, 2008-05-12 at 13:47 +0200, Raphael Hertzog wrote:
    > As a maintainer, I would have no problem receiving such reports
    > if they are filed with a severity minor. Then you use some usertags to get
    > a global view of all the open issues distribution-wise.
    >
    > In fact, I think that it makes more sense than using a pseudo-package.


    Agreed. Then use usertags to track overall progress, which seems to be
    the reason a pseudo-package is wanted.

    See you, =)

    --
    Gustavo Noronha Silva
    Debian Project

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

    iQEVAwUASCg7ztIA6zCg+12mAQLEUQgAs9dRG4NMRUC6pvoKTg Sc/GBQUR0ue+6E
    C4QjMAO03lP1i8NaFhl5oQFsqKKbMRVYVGJ8sMlDBaEs3SKhAw dmdprLop7GWw7m
    5tB+CD/V33GJo5R3cK78ONISyEVayjV0kneVYTr6xbV5b61TCH6xcL4zR kDDcKLc
    fk7dH4WY3QCVXq2hvGqmnz8+HShRXCcUnhIGOm9sqaG0h9iuU9 3YFWvLTikqjfVu
    gB513+1k98XUoid9WXOoLg0jThogEBQvSDKNmEfT7TYtwtt2WY TA59/iwpmM0XEF
    L/SIcA+7gCeXWgPx0kT3sPX7t0SMqhWue0nWW7NsRappx7yPTb3G Bg==
    =z9H/
    -----END PGP SIGNATURE-----


+ Reply to Thread