Bug#355643: ITP: xsltsl -- XSLT Standard Library stylesheets
Package: wnpp Severity: wishlist Owner: Neil Williams <[EMAIL PROTECTED]> * Package name: xsltsl Version : 1.2.2 Upstream Author : Steve Ball <[EMAIL PROTECTED]> * URL : http://xsltsl.sourceforge.net/ * License : LGPL Description : XSLT Standard Library stylesheets The XSLT Standard Library, xsltsl, provides the XSLT developer with a set of XSLT templates for commonly used functions. These are implemented purely in XSLT, that is they do not use any extensions. The current version, 1.2.1, has an unclear/incomplete licence declaration and the release contains spurious CVS directories but after contacting the upstream developer, both issues should be resolved for the next release. Hence this ITP is for the next release, 1.2.2 or later. Some of these stylesheets are likely to be included in the pilot-qof package in the meantime. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.25-1-686 Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#305563: ITP: pilotqof -- query Palm PDA data using SQL syntax and write to XML
Package: wnpp
Severity: wishlist
Owner: Neil Williams <[EMAIL PROTECTED]>
* Package name: pilotqof
Version : 0.0.3
Upstream Author : Neil Williams <[EMAIL PROTECTED]>
* URL : http://sourceforge.net/projects/pilot-qof/
* License : GPL
Description : query Palm PDA data using SQL syntax and write to XML
Write Palm PDA data - addresses, calendar, tasks and expenses -
as XML to a file or the terminal. Users can run SQL-type queries on
the live data or XML file and output the results of the query as XML.
XML written by pilot-qof can be imported into other applications
that use QOF, including GnuCash. SQL commands can be passed on the
command line or from a file.
pilot-qof uses libpisock (pilot-link) and QOF - the Query Object
Framework.
Homepage: http://pilot-qof.sourceforge.net/
End long description.
Build-Depends: debhelper (>= 4.0.0), autotools-dev, libpopt-dev,
libglib1.2-dev, libqof-dev (>= 0.5.1), libpisock-dev (>= 0.12),
docbook-to-man
Depends: ${shlibs:Depends}, ${misc:Depends}, libqof-0.5.1, libpisock9
The CVS codebase is almost complete but packaging must wait until the
release of code for the two dependencies; QOF and libpisock. libpisock9
is to be released at the same time as pilot-link v0.12 and the code here
is complete. I've got some more code to finish in QOF and hope to make
a file release at the same time as pilot-link 0.12 and libpisock9.
Current pilotqof file release: v0.0.1, CVS v0.0.2
Expected Release at packaging: v0.0.3
More information:
http://code.neil.williamsleesmill.me.uk/pilot-qof/
CVS: http://cvs.sourceforge.net/viewcvs.py/pilot-qof/
Sample man page:
http://code.neil.williamsleesmill.me.uk/pilot-qof.html
Rationale: http://code.neil.williamsleesmill.me.uk/pilot-link.html
The XML format used by pilotqof is documented here:
http://code.neil.williamsleesmill.me.uk/qsf.html
and
http://code.neil.williamsleesmill.me.uk/doxygen/group__QSF.html
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.25-1-686
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#381221: ITP: dpkg-view -- View the contents of .deb packages without root access
Package: wnpp Severity: wishlist Owner: Neil Williams <[EMAIL PROTECTED]> * Package name: dpkg-view Version : 0.0.2 Upstream Author : Neil Williams <[EMAIL PROTECTED]> * URL : http://dpkg-view.alioth.debian.org * License : GPL Programming Lang: C Description : View the contents of .deb packages without root access Simple read-only viewer of .deb package files for Gnome. Accepts package locations on the command line to support the 'open' command in various file managers, one window for each package. Displays Debian control information, patch details and details of the files that would be installed (names, sizes and locations). Packages do not need to be installed to be viewed. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-powerpc Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#387426: ITP: glipper -- A clipboardmanager for GNOME and other window managers
Package: wnpp Severity: wishlist Owner: Neil Williams <[EMAIL PROTECTED]> * Package name: glipper Version : 0.89 Upstream Author : Sven Rech <[EMAIL PROTECTED]> * URL : http://glipper.sourceforge.net/ * License : LGPL Programming Lang: C Description : A clipboardmanager for GNOME and other window managers A GNOME counterpart to KDE's Klipper using GTK+2, intended for Gnome. Can also be used with any other window manager that supports tray icons. Supports configurable number and length of clipboard entries and saving clipboard history on exit. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-powerpc Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#397065: ITP: apt-cross -- retrieve, build and install cross-built packages using dpkg-cross
Package: wnpp Severity: wishlist Owner: Neil Williams <[EMAIL PROTECTED]> * Package name: apt-cross Version : 0.0.1 Upstream Author : Neil Williams <[EMAIL PROTECTED]> * URL : http://buildd.emdebian.org/repos/tools/apt-cross/ * License : GPL Programming Lang: Perl Description : retrieve, build and install cross-built packages using dpkg-cross Provides apt functionality for cross-building under dpkg-cross. . By default, apt-cross uses /etc/apt/sources.list to find the current debian package file for the architecture specified (default is arm) and in the suite specified (default is unstable). Alternatively, you can specify a different mirror. Downloaded files can be passed directly to dpkg-cross using the -b or -i commands to apt-cross. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-amd64-k8 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403802: ITP: gpe-minibrowser -- small web browser with a low memory footprint for GPE
Package: wnpp Severity: wishlist Owner: Neil Williams <[EMAIL PROTECTED]> * Package name: gpe-minibrowser Version : 0.19 Upstream Author : Philippe De Swert <[EMAIL PROTECTED]> * URL : http://gpe.linuxtogo.org/projects/gpe-mini-browser.shtml * License : GPL Programming Lang: C Description : small web browser with a low memory footprint for GPE gpe-minibrowser is designed to be used on devices with small screens and limited resources. Apart from plain HTML it supports Java Script and stylesheets. The application supports both plain GTK and the Maemo software environments. Part of a wider move to include all of GPE in Debian to support Emdebian and the wider use of Debian on machines with limited resources. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-amd64-k8 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403979: ITP: gpe-gallery -- GPE image gallery and viewer, with slideshow support
Package: wnpp Severity: wishlist Owner: Neil Williams <[EMAIL PROTECTED]> * Package name: gpe-gallery Version : 0.97 Upstream Author : Damien Tanner <[EMAIL PROTECTED]> * URL : http://gpe.linuxtogo.org/projects/gpe-gallery.shtml * License : GPL Programming Lang: C Description : GPE image gallery and viewer, with slideshow support A small application for viewing images in GPE. Intended to show small and medium sized images and is able to display a slide show and to perform several simple operations with the images. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-amd64-k8 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#403979: ITP: gpe-gallery -- GPE image gallery and viewer, with slideshow support
On Thu, 21 Dec 2006 07:22:50 +0100 (CET) Andreas Tille <[EMAIL PROTECTED]> wrote: > On Thu, 21 Dec 2006, Neil Williams wrote: > > > Description : GPE image gallery and viewer, with slideshow support > > A small application for viewing images in GPE. Intended to show > > small and medium sized images and is able to display a slide > > show and to perform several simple operations with the images. Description: GPE image gallery and viewer with slideshow support An image viewer for the GPE Palmtop Environment. Intended to show small and medium sized images as icons or as a slideshow, gpe-gallery also performs some simple operations with the images. > Sorry, what is GPE? > Yes, I'm sure Google would be my friend for this question but package > descriptions should not require other resources to be understandable > for the user. Agreed. Hope the above replacement is clearer. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpxgVOi5EVmb.pgp Description: PGP signature
Bug#404030: ITP: gpe-clock -- alarm clock tray applet for GPE
Package: wnpp Severity: wishlist Owner: Neil Williams <[EMAIL PROTECTED]> * Package name: gpe-clock Version : 0.25 Upstream Author : Philip Blundell <[EMAIL PROTECTED]> * URL : http://gpe.linuxtogo.org/projects/gpe-clock.shtml * License : GPL Programming Lang: C Description : alarm clock tray applet for GPE gpe-clock is an alarm clock dock application for the GPE Palmtop Environment. It displays the time in the system tray and manages simple alarms (single or weekly). It can be configured to display a digital or an analogue clock face. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-amd64-k8 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404042: ITP: libgpeschedule -- scheduling library for GPE
Package: wnpp Severity: wishlist Owner: Neil Williams <[EMAIL PROTECTED]> * Package name: libgpeschedule Version : 0.16 Upstream Author : Florian Boor <[EMAIL PROTECTED]> * URL : http://gpe.linuxtogo.org/projects/ * License : GPL Programming Lang: C Description : scheduling library for GPE The Debian packages have been renamed from the upstream libschedule to prevent possible conflicts and to highlight the use of the library within GPE. There exist other scheduling packages for other environments, this one is linked to libgpewidget1 and is designed for the GPE Palmtop Environment to make it small enough for embedded devices. This source package builds two binary packages: libgpeschedule0 scheduling library for GPE Scheduling library that is used by the GPE Palmtop Environment to schedule events and warn applications of their occurence. . This package contains the shared libraries. libgpeschedule-dev GPE scheduling library development files Scheduling library that is used by the GPE Palmtop Environment to schedule events and warn applications of their occurence. . This package contains the development files. . Homepage: http://www.kernelconcepts.de/~fuchs/gpe/doc/libschedule/ -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-amd64-k8 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404059: ITP: gpe-conf -- configuration toolset for GPE
Package: wnpp Severity: wishlist Owner: Neil Williams <[EMAIL PROTECTED]> * Package name: gpe-conf Version : 0.2.2 Upstream Author : Florian Boor <[EMAIL PROTECTED]> * URL : http://gpe.linuxtogo.org/projects/gpe-conf.shtml * License : GPL Programming Lang: C Description : configuration toolset for GPE GPE-Conf is a set of configuration tools for the GPE Palmtop Environment to perform the basic configuration tasks on a mobile device. It is designed to expose all necessary settings in an easy to use and unintrusive way. It is also able to set up some tasks that are the subject of more advanced use of a device such as serial port usage and multi user setups. . The GPE-Conf package contains another small tool - GPE-Info to provide information about the device and current status as well. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-amd64-k8 debian/gpe-conf.1 usr/share/man/man1/ Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404083: ITP: gpe-appmgr -- application manager for GPE desktop
Package: wnpp Severity: wishlist Owner: Neil Williams <[EMAIL PROTECTED]> * Package name: gpe-appmgr Version : 2.8 Upstream Author : Robert Mibus <[EMAIL PROTECTED]> * URL : http://gpe.linuxtogo.org/projects/GPE-appmgr.shtml * License : GPL Programming Lang: C Description : application manager for GPE desktop The application manager is the main window of an embedded device running the GPE Palmtop Environment. It allows users to start-up applications and offers a main menu. Any application that a user should be able to access should also be available through the application manager. . GPE-Appmgr uses freedesktop.org-style desktop files like known from Gnome and KDE. It is able to deal with single- and multi instance applications as well as different screen sizes. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-powerpc Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404306: ITP: libxsettings -- Xsettings protocol library for GPE
Package: wnpp Severity: wishlist Owner: Neil Williams <[EMAIL PROTECTED]> * Package name: libxsettings Version : 0.11 Upstream Author : Owen Taylor <[EMAIL PROTECTED]> * URL : http://standards.freedesktop.org/xsettings-spec/0.5/ * License : RedHat modified BSD Programming Lang: C Description : Xsettings protocol library for GPE Provides a mechanism to allow the configuration of settings such as double click timeout, drag-and-drop threshold, and default foreground and background colors for all applications running within a desktop. Used by the GPE Palmtop Environment. The package includes a -dev binary and a libxsettings0 shared library. Note that the library itself has been renamed for Debian. Upstream uses libXsettings.so and this package creates libxsettings.so There is also a libxsettings-client package that I will also be packaging. Full licence text: Permission to use, copy, modify, distribute, and sell this software and its documentation for any purpose is hereby granted without fee, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of Red Hat not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. Red Hat makes no representations about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty. RED HAT DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL RED HAT BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-amd64-k8 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404307: ITP: libxsettings-client -- utility functions for the Xsettings protocol (GPE)
Package: wnpp Severity: wishlist Owner: Neil Williams <[EMAIL PROTECTED]> * Package name: libxsettings-client Version : 0.17 Upstream Author : Owen Taylor <[EMAIL PROTECTED]> * URL : http://standards.freedesktop.org/xsettings-spec/0.5/ * License : RedHat modified BSD Programming Lang: C Description : utility functions for the Xsettings protocol (GPE) This library is used for applications making use of the Xsettings configuration setting propagation protocol. Controls setting of double click timeout, drag-and-drop threshold, and default foreground and background colors for all applications running within a desktop. . Used by the GPE Palmtop Environment. The client side of libxsettings. Full licence text: Permission to use, copy, modify, distribute, and sell this software and its documentation for any purpose is hereby granted without fee, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of Red Hat not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. Red Hat makes no representations about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty. RED HAT DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL RED HAT BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-amd64-k8 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404312: ITP: gpe-soundserver-0.4 -- start and stop the GPE sound service
Package: wnpp Severity: wishlist Owner: Neil Williams <[EMAIL PROTECTED]> * Package name: gpe-soundserver-0.4 Version : 0.4 Upstream Author : Philip Blundell <[EMAIL PROTECTED]> * URL : http://gpe.linuxtogo.org/projects/GPE-soundbite.shtml * License : GPL Programming Lang: C Description : start and stop the GPE sound service Provides as-and-when sound services by wrapping the esd daemon. gpe-soundbite starts the gpe-soundserver prior to playback or recording and stops it again at the end of playback or recording. . Used by the GPE Palmtop Environment to reduce the resource footprint on devices where sound is only used intermittently. (Investigating a fix for upstream so that the actual package can be gpe-soundserver and version 0.4 (or 0.5) upstream to make a more 'friendly' Debian version string.) -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-amd64-k8 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404381: ITP: gpe-mixer -- audio mixer frontend for GPE
Package: wnpp Severity: wishlist Owner: Neil Williams <[EMAIL PROTECTED]> * Package name: gpe-mixer Version : 0.42 Upstream Author : Nils Faerber <[EMAIL PROTECTED]> * URL : http://gpe.linuxtogo.org/download/source/ * License : GPL Programming Lang: C Description : audio mixer frontend for GPE Enables configuration of the internal audio mix on an embedded device in the GPE Palmtop Environment. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-amd64-k8 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404380: ITP: gpe-su -- root shell for GPE
Package: wnpp Severity: wishlist Owner: Neil Williams <[EMAIL PROTECTED]> * Package name: gpe-su Version : 0.19 Upstream Author : Philip Blundell <[EMAIL PROTECTED]> * URL : http://gpe.linuxtogo.org/download/source/ * License : GPL Programming Lang: C Description : root shell for GPE Executes applications with root privileges. . Used by gpe-conf to configure devices on the embedded device. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-amd64-k8 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404385: ITP: gpe-shield -- firewall configuration for GPE
Package: wnpp Severity: wishlist Owner: Neil Williams <[EMAIL PROTECTED]> * Package name: gpe-shield Version : 0.9 Upstream Author : Florian Boor <[EMAIL PROTECTED]> * URL : http://gpe.linuxtogo.org/download/source/ * License : GPL Programming Lang: C Description : firewall configuration for GPE Gpe-shield is a frontend for the iptables network packet filter for the GPE Palmtop Environment. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-amd64-k8 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404388: ITP: gpe-watch -- a watch for a small screen in GPE
Package: wnpp Severity: wishlist Owner: Neil Williams <[EMAIL PROTECTED]> * Package name: gpe-watch Version : 0.10 Upstream Author : Nils Faerber <[EMAIL PROTECTED]> * URL : http://gpe.linuxtogo.org/download/source/ * License : GPL Programming Lang: C Description : a watch for a small screen in GPE Can also display a clock if you have a bigger screen. Part of the GPE Palmtop Environment. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-amd64-k8 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404387: ITP: gpe-what -- A small applet to provide help within GPE
Package: wnpp Severity: wishlist Owner: Neil Williams <[EMAIL PROTECTED]> * Package name: gpe-what Version : 0.43 Upstream Author : Philip Blundell <[EMAIL PROTECTED]> * URL : http://gpe.linuxtogo.org/download/source/ * License : GPL Programming Lang: C Description : A small applet to provide help within GPE Indicates if context-sensitive help is available and enables tooltips in the GPE Palmtop Environment. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-amd64-k8 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404390: ITP: gpe-confd -- configuration daemon for GPE
Package: wnpp Severity: wishlist Owner: Neil Williams <[EMAIL PROTECTED]> * Package name: gpe-confd Version : 0.16 Upstream Author : Philip Blundell <[EMAIL PROTECTED]> * URL : http://gpe.linuxtogo.org/download/source/ * License : GPL Programming Lang: C Description : configuration daemon for GPE The purpose of gpe-confd is to provide a persistent storage backend for Xsettings. Most of the global user interface related settings such as theme and font sizes are made using the Xsettings mechanism. . Use by the GPE Palmtop Environment. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-powerpc Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405591: ITP: libtext-vfile-asdata-perl -- generic perl module to read and write vfile files
Package: wnpp Severity: wishlist Owner: Neil Williams <[EMAIL PROTECTED]> * Package name: libtext-vfile-asdata-perl Version : 0.0.5 Upstream Author : Jay Lawrence <[EMAIL PROTECTED]> * URL : http://search.cpan.org/dist/Text-vFile * License : GPL Programming Lang: Perl Description : generic perl module to read and write vfile files Works with such as vCard (RFC 2426) and vCalendar (RFC 2445). The result of loading this data is a collection of objects which will grant you easy access to the properties. Then the module can write your objects back to a data file. Used by libtext-vcard-perl which in turn is to be recommended by pilot-qof. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-powerpc Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405590: ITP: libtext-vcard-perl -- parse, edit and create multiple vCards
Package: wnpp Severity: wishlist Owner: Neil Williams <[EMAIL PROTECTED]> * Package name: libtext-vcard-perl Version : 2.00 Upstream Author : Leo Lapworth <[EMAIL PROTECTED]> * URL : http://search.cpan.org/dist/Text-vCard * License : GPL Programming Lang: Perl Description : parse, edit and create multiple vCards Text::vCard::Addressbook provides an API to reading / editing and creating multiple vCards. A vCard is an electronic business card. This package has been developed based on rfc2426. . Many applications (Apple Address book, MS Outlook, Evolution etc) can export and import vCards. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-powerpc Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405961: ITP: emdebian-tools -- emdebian crossbuilding tool set
Package: wnpp Severity: wishlist Owner: Neil Williams <[EMAIL PROTECTED]> * Package name: emdebian-tools Version : 0.0.2 Upstream Author : Neil Williams <[EMAIL PROTECTED]> * URL : http://buildd.emdebian.org/repos/tools/em_make/ * License : GPL Programming Lang: Perl Description : emdebian crossbuilding tool set A collection of scripts to ease cross-building Debian packages for Emdebian, reducing package size, separating translations into individual files and handling dependencies. . emsetup : Check your system for cross-build support and determine some defaults for other emdebian-tools scripts. Run this first, using the simulate option to see what changes may be needed. . emchain : Toolchain builder for cross compiling. If a pre-built toolchain is not found or not available, emchain can build a custom toolchain for your needs using the current Debian version of gcc. . em_make : Emdebianise a Debian package. Creates suitable changelog entries, omits certain debhelper scripts from debian/rules and maintains a patchset for emdebian. Removes all documentation and udeb packages from debian/control. . emlocale : Moves all translations out of the Debian package(s) and into individual locale packages, allowing the embedded user to only install the translations that are relevant to that system. First run is via em_make, subsequent runs update the list of available translation packages. . emdebuild : Emdebian version of debuild that handles cross-building the emdebianised tree. Requires a suitable cross-building toolchain to be installed for the requested architecture, e.g. gcc-4.1-arm-linux-gnu, available from the emdebian tools repository via emsetup or built for your particular configuration using emchain. . Homepage: http://www.emdebian.org/ -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-amd64-k8 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: new tar behavior and --wildcards
Thijs Kinkhorst wrote: > On Tue, 2006-06-27 at 10:02 +0200, Pierre Habouzit wrote: >> Le lun 26 juin 2006 21:53, Petr Vandrovec a écrit : >>> Maybe it could be default for tar's POSIX mode, but I have no idea >>> why GNU mode behavior should be changed in any way. >> I second that. it's now completely unpossible to do basic packaging >> work, because such a change wasn't planned. I also don't find it wise, >> if we still want to release this year, to introduce such a change >> *now*. >> >> Bdale, I *really* beg you to postpone that default change post-etch. > > Is there any idea of the number of packages actually affected by this? It's not so much packages already in the archive, it's every package that is being prepared to be uploaded. Lintian *always* fails for all packages that I build on a system with the updated tar. None of those packages failed prior to the tar update. Linda just crashes, every single time. Again, never did before. Without those two, how can new packages be uploaded safely? dpkg-buildpackage generates an error message but does continue to operate. > I've harly seen an RC bug flood arise out of this; I've only seen two, I'm not a DD (in the NM process) but couldn't that simply be because the Debian machines themselves (like p.d.o and qa.d.o) have not upgraded to this release of tar? If those machines become unable to run lintian or linda without errors, isn't that going to be a flood of a different kind? > one of which is already pending upload. Probably a few more will arise, > but the fix is trivial. You mean downgrading to the version of tar in testing? > So I wonder if it would be useful to revert the change, since we have to > change at some point and at this point the effects do not seem to be > quite dramatic. Maybe you have signs indicating otherwise? > PLEASE can tar be reverted to 1.15.1dfsg-3 in unstable? Maybe tar 1.15.91-1 should go into experimental until lintian, dpkg-buildpackage and linda can all be prepared for the new behaviour. If lintian functionality isn't restored soon, how can new packages be uploaded safely? -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: OpenPGP digital signature
Bug#329676: ITP: CashUtil -- GnuCash command line interface and shell
Package: wnpp Severity: wishlist Owner: Neil Williams <[EMAIL PROTECTED]> * Package name: CashUtil Version : 0.1.0 Upstream Author : Neil Williams <[EMAIL PROTECTED]> * URL : http://www.linux.codehelp.co.uk/cashutil/ * License : GPL Description : GnuCash command line interface and shell A command line interface for GnuCash providing access to most GnuCash features. CashUtil supports SQL-type queries using QOF and writes results to QSF XML to support external report scripts / tools. It also includes the prototype QOF interactive shell and limited undo capability. . This package provides the files needed to run CashUtil. The XML format used by cashutil exports is documented here: http://code.neil.williamsleesmill.me.uk/qsf.html and http://code.neil.williamsleesmill.me.uk/doxygen/group__QSF.html CashUtil requires libqof1 (QOF >= 0.6.0) and will share some libraries with GnuCash. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.25-1-686 Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
OT: Please vote for EU recognition of those who oppose software patents
I know it's off-topic for the list but I feel it is sufficiently important that it deserves the widest possible publication. I'm not sure if the list has already received this notification. The vote *is* open to non-EU residents. Feel free to adapt any part of it if you'd like to send it on to other user group mailing lists etc. --- Dear Supporters of NoSoftwarePatents.com, On 6 July 2005, the European Parliament rejected a proposal to legalise software patents in Europe. However, our fight continues. There is now a public Internet poll in which you can vote against software patents. Everyone can participate in the vote of the "Europeans of the Year". That is the most important award in the European Union, and Florian Mueller, the founder of the NoSoftwarePatents.com campaign, has a realistic chance to win. If Florian wins, then the big news in the media will be: "Opponent of software patents is elected as European of the Year". The importance of our cause would be clearer than ever before, to politicians, the press, and the public. Florian would also have the chance to make a speech against software patents in front of some of Europe's most powerful politicians. Please click here to read more about this opportunity to vote (on the Internet) against software patents: http://www.nosoftwarepatents.com/en/m/ev50/index.html Thank you very much in advance for your support. This is really a unique opportunity for you and your friends to show to politicians that software patents are a major problem to people all over the world. Everyone may participate in the vote, including non-Europeans, and if we win, then the victory will belong to all of us together. Best regards, The NoSoftwarePatents.com Team --- My two-cents: The vote works like this: 1. You must vote once for each of the ten categories, not just Florian. The link above at nosoftwarepatents.com links on to a page that explains who on the list of nominees did the most to support the fight against software patents. There are some categories where the vote is entirely neutral - make your own mind up on those. (I would personally recommend against voting for Tony Blair - no matter what your political persuasion - as the UK government was firmly behind the UKPO. If Lord Sainsbury was on the list, maybe I would change that but although he listens, it is still unclear how much he acts on the reports.) 2. Enter your real name and a genuine email address at the end. You will receive a confirmation email that activates your vote by providing a link. This is an attempt to block repeat voting - not sure how it works for those of us with multiple email addresses! However, do NOT deliberately attempt to skew the vote - your votes may be disqualified if abuse is found. 3. This is a real poll with real results - it's not the usual Slashdot type poll that has no effect beyond the stats. There are real awards that will get the attention of the worldwide media. 4. Florian was and is the most persistent anti-software-patent voice in Brussels, his support of FFII, his endless campaigning and unflinching support for the fight against software patents does deserve wider recognition. From the nosoftwarepatents.com site: This is a campaign for a cause, not for a person. A respected jury has nominated Florian Mueller as a figurehead of our movement, and he has made it clear that we will all be winners if he becomes elected. By voting for Florian in a public Internet poll, you and your friends - no matter where in the world you live - can send out a strong signal that politicians must act against software patents. If we succeed with this campaign, the issue of software patents will be elevated to the level of awareness that other major political topics enjoy. Our opponents try to portray it as a concern of geeks. With the power of the Internet, we can prove them wrong once again. We face strong competition from such prominent people as Bono (U2), Bob Geldof, J.K. Rowling and 46 other candidates. However, we have a realistic chance to win because a public Internet poll should be a home game for us. Imagine what it will mean if our candidate receives a highly prestigious award that Microsoft has co-sponsored, at a gala event that is moderated by a pro-patent lobbyist (Pat Cox), and if he can then make an acceptance speech in front of many EU commissioners and the heads of governments of several EU member countries. Europe's political leaders would have to listen to us like never before, and the news would go around the world. Florian has promised that he will give the prize money to the FFII if he wins. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpfoge2jNwFI.pgp Description: PGP signature
Re: Amarok build-dep failure
On Mon, 21 Jan 2008 23:53:07 +0530 Ritesh Raj Sarraf <[EMAIL PROTECTED]> wrote: > Currently, I don't see amarok having all its build dependencies satisfied. This isn't the fault of amarok - it simply means that the list of build dependencies cannot be installed on your system due to conflicts or pinned packages or problems with other dependencies. Your best bet is to try to install each of the build dependencies manually using the list in debian/control. > E: Build-dependencies for amarok could not be satisfied. > > Is this a bug ? It might be a wishlist/minor bug in apt to request a clearer error message but I don't see that it is a bug in amarok. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpzYgfd9EKtF.pgp Description: PGP signature
Re: late at night... can't think -- why is my bugs are not closed?
On Wed, 2008-01-23 at 03:03 -0500, Yaroslav Halchenko wrote: > Dear All, may I used your brains a bit > > In a fresh package (edac-utils) I have closed a bug in recent upload > (proper Closes statement and a Closes in .changes). But bug remains Done > but not closed: #456644. Looks OK now - maybe just a delay? -- 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#462306: ITP: gpe-tetris -- tetris game for small screens and embedded devices
Package: wnpp Severity: wishlist Owner: Neil Williams <[EMAIL PROTECTED]> * Package name: gpe-tetris Version : 0.6.4 Upstream Author : David Necas <[EMAIL PROTECTED]> * URL : http://gpe.linuxtogo.org/projects/ * License : GPL Programming Lang: C Description : tetris game for small screens and embedded devices Falling-block game for the G Palmtop Environment. -- System Information: Debian Release: lenny/sid APT prefers experimental APT policy: (500, 'experimental'), (500, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.6.22-3-powerpc 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: late at night... can't think -- why is my bugs are not closed?
On Thu, 2008-01-24 at 07:09 +, Adam D. Barratt wrote: > Hi, > > On Wed, 2008-01-23 at 22:39 -0500, Yaroslav Halchenko wrote: > > Well... as Neil pointed it seems not to be the case -- m68k arch is > > still -1 but now it is "resolved". > > Where are you seeing it as "resolved"? It's still listed as outstanding > on > http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=edac-utils;dist=unstable > http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=edac-utils -- 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#462791: ITP: libgtkstylus -- stylus tap support for Gtk+
Package: wnpp Severity: wishlist Owner: Neil Williams <[EMAIL PROTECTED]> * Package name: libgtkstylus Version : 0.3 Upstream Author : Philip Blundell <[EMAIL PROTECTED]> * URL : http://gpe.linuxtogo.org/download/source/ * License : LGPL Programming Lang: C Description : stylus tap support for Gtk+ Provides a module for Gtk+ to interpret touchscreen taps, used by the G Palmtop Environment. -- System Information: Debian Release: lenny/sid APT prefers experimental APT policy: (500, 'experimental'), (500, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.6.22-3-powerpc 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: Alternatives: field for debian/control
On Mon, 2008-02-04 at 14:26 -0600, William Pitcock wrote: > Hi, > > There's a lot of packages in Debian which do the same basic thing, but > slightly differently. Having an Alternatives: field would be nice for > listing alternative packages which package maintainers may find useful > to try if the user does not like how the package they are installing > behaves. Sounds more like a job for debtags and ept-cache to me. The judgement about whether two packages are "similar" enough to be "alternatives" can be subjective, as shown by the previous discussions on xmms and audacity. Such "fuzzy" relationships are best done with tags, IMHO. (Also, let's not add yet more lines to the Packages.gz file?) -- 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: package names for library modules (was: shlibs vs symbols)
On Tue, 2008-02-05 at 09:37 +0100, Raphael Hertzog wrote: > Hi, > > On Tue, 05 Feb 2008, Paul Wise wrote: > > I was reviewing a library package RFS (libthai) and I noticed that the > > shlibs pointed at version X and all the symbols in the symbols file > > pointed at an earlier version. Here I assume that the shlibs should be > > changed to point to the earlier version? > > libqof-backend-qsf0: shlibs no version, symbols all 0.7.3, changelog goes > > way back > > libqof1: shlibs no version, symbols all 0.7.2, changelog goes way back > > Strange, stable has 0.7.1... and lack of version in shlibs is probably a > bug, but one that can't be triggered except by building on etch with a > dpkg-dev that doesn't support symbols files yet. Looks like old data - 0.7.5 is current in unstable and has: libqof-backend-qsf0 shlibs:Depends: libglib2.0-0 (>= 2.6.0), libqof1 (= 0.7.5-1), libxml2 (>= 2.5.10) libqof1 shlibs:Depends=libgda3-3, libc6 (>= 2.7-1), libglib2.0-0 (>= 2.12.0) True, the symbols version differs but, TBH, libqof-backend-qsf0|sqlite0 are a bit of an anomaly at the moment. I'm waiting for the transition to libqof2 at which point the backend modules will be renamed and repackaged as private libraries. I've decided to wait until after Lenny to make the transition - the upstream code will not be ready until after the main Lenny freeze has begun. Symbols were only implemented in 0.7.3 and I saw no point going back to 0.7.1, just show that the symbols in 0.7.3 were compatible with 0.7.2. After the transition, the backend modules will no longer be shlibs so there will be no symbols for those, just libqof2 which will start at 0.8.0 (a lot of symbols are being removed in the transition). Actually, this reminds me of a question for debian-devel: Is there a convention for the package name for *library modules* ? GDA has modules that are loaded by a library and which are optional - the user can choose from one of a few backend modules. QOF has a very similar mechanism - the backends are modular (GModule) and entirely optional (as long as at least one is available). After the transition, these will be private libraries and I'm thinking of using the names: libqof2-backend-qsf libqof2-backend-sqlite This is similar to the new package names for the GDA backends: libgda3-mysql, libgda3-postgres, libgda3-odbc, libgda3-sqlite, libgda3-freetds - which were changed from the equivalent packages for libgda2. QOF also supports modular object libraries to support a variety of frontends. These are shlibs and are currently named as: libqofexpensesobjects0 libqofcashobjects0 ... (with -dev, -dbg etc. as normal) Applications then mix-and-match object libraries (and/or their own objects) at compile time and call routines in libqof1|2 to dynamically load the backend module as requested by the user. The transition is the perfect time to change the names of the other components. Comments? -- 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: Progress on the mass bug filing for cross build support.
On Mon, 2008-02-11 at 19:19 +, Neil Williams wrote: One little note on these bugs: 1. All bugs below have patches attached that have been carefully tested with your package to avoid any changes in the Debian packages. As such, the patches can be applied without you needing to worry about testing the patch within a crossbuild environment. Please verify that the patch does not change your Debian packages and let me know if I have missed something that changes the Debian build. I am conscious that time is short before certain packages go into soft freeze and I want to get the autotools-dev support into as many packages as possible because these are the patches that are the most difficult for Emdebian to maintain as "outside-tree". 2. Many patches are inter-woven with other changes and other patches elsewhere in Debian and might not be sufficient to actually implement complete cross build support for any one package at this time. This is not, IMHO, a reason to not apply the patches at this stage. I have started with the autotools-dev patches because these are the ones that will simplify my cross building workload the most. With these patches in place, I will be able to allocate time to solving the more general problems that still remain within cross building Debian. There is little point submitting patches that are full of hacks and workarounds. Leave those to me and emdebian-tools. :-) When I have fixes for the issues that require the hacks, I'll come back with the final changes. (Please let me walk before expecting me to run. ;-)) 3. The long term mass bug filing for cross build support is ongoing and this is only Phase 1. I fully expect to still be filing bug reports under this title after Lenny has become old-stable. One step at a time is the principle. 4. I have deliberately *not* included changes in these Phase 1 patches that are related to other changes in Debian that are yet to be implemented. Emdebian has working solutions for all the problems on a patch basis but better solutions are pending. I need to get this set of patches into place so that it frees up time to solve the more general issues. 5. Some patches include support for --cache-file. See my explanation of this in #465294. Other packages may still need similar support but I have decided not to seek patches for these packages, yet. If anyone has a good idea for solving the issues described in #465294, I'm listening. 6. Please apply the patches as they stand - harangue me at Fosdem if you have general questions but please, help me out and apply the patches so that I can get on with Phase 2 and actually get something working for a Fosdem demo. Thanks. ;-) (Many thanks to those developers who have already uploaded fixes for the bugs listed in the original email.) > > > This is the list of maintainers for the remaining open bugs (excluding > the pending bugs). Some of these are really v.v.old and I will look at > doing delayed NMU's for those that remain unfixed after Fosdem. > > http://www.emdebian.org/bugs.php > > Russ Allbery <[EMAIL PROTECTED]> >krb5 (U) > > Bill Allombert <[EMAIL PROTECTED]> >libjpeg6b > > Domenico Andreoli <[EMAIL PROTECTED]> >curl > > Bastian Blank <[EMAIL PROTECTED]> >busybox (U) >cdebconf (U) > > Jérémy Bobbio <[EMAIL PROTECTED]> >cdebconf (U) > > Daniel Burrows <[EMAIL PROTECTED]> >aptitude >libsigc++-2.0 > > Volker Christian <[EMAIL PROTECTED]> >libmimedir > > Randolph Chung <[EMAIL PROTECTED]> >cdebconf (U) > > Julien Cristau <[EMAIL PROTECTED]> >mesa (U) > > Julien Cristau <[EMAIL PROTECTED]> >libx11 (U) > > Marco d'Itri <[EMAIL PROTECTED]> >tcp-wrappers >udev > > Debian Install System Team <[EMAIL PROTECTED]> >busybox >cdebconf > > Debian OpenSSL Team <[EMAIL PROTECTED]> >openssl > > Debian X Strike Force <[EMAIL PROTECTED]> >libx11 >mesa > > Bernd Eckenfels <[EMAIL PROTECTED]> >net-tools > > Anthony Fok <[EMAIL PROTECTED]> >freetype (U) > > Jochen Friedrich <[EMAIL PROTECTED]> >libgsm > > Brice Goglin <[EMAIL PROTECTED]> >mesa (U) > > Steve Greenland <[EMAIL PROTECTED]> >cron (U) > > Sam Hartman <[EMAIL PROTECTED]> >krb5 >pam (U) > > Joey Hess <[EMAIL PROTECTED]> >cdebconf (U) > > Matthias Klose <[EMAIL PROTECTED]> >curl (U) >readline5 > > Matt Kraai <[EMAIL PROTECTED]> >cdebconf (U) > > Noèl Köthe <[EMAIL PROTECTED]> >wget > > Steve Langasek <[EMAIL PROTECTED]>
Progress on the mass bug filing for cross build support.
emineur James Troup <[EMAIL PROTECTED]> ed mawk Santiago Vila <[EMAIL PROTECTED]> diffutils Michael Vogt <[EMAIL PROTECTED]> libcap Colin Watson <[EMAIL PROTECTED]> cdebconf (U) The actual bug numbers: acl284167 aptitude 465076 busybox465290 cdebconf 451130 cron 465077 curl 465089 dash 450512 diffutils 451159 ed 451175 esound 465092 fontconfig 451277 freetype 465292 iputils451181 krb5 465294 libcap 283023 libgsm 465222 libjpeg6b 451222 libmimedir 465150 libopenobex465262 libsigc++-2.0 465255 libvolume-id-dev 459788 libx11 425445 mawk 285418 mesa 451648 net-tools 451281 newt 465105 openssl465248 pam 284854 popt 282913 procps 451812 psmisc 465226 readline5 465237 rxvt 465214 tcp-wrappers 451854 udev 465156 wget 451285 xdemineur 465117 -- 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: swfdec0.6 buildd failure
On Mon, 2008-03-03 at 21:52 +0100, Jiří Paleček wrote: > Hello, > > I was looking at the swfdec0.6 package and wondered why it is unavailable > on almost all architecture. It only exists in experimental - packages in experimental *might* be autobuilt but the only way to be sure is to get the package in a fit state for unstable. > So I looked at the build logs and they > (almost) fail in a quite strange way. It seems apt installed a broken set > of packages (even though a package set satisfying the build-dependencies > was -probably- available). Probably? Are you able to build it using pbuilder yourself? > Is this a bug in APT? Probably not. It looks more like a feature of experimental, most of the logs I saw include this error: libglib2.0-dev: Depends: libglib2.0-0 (= 2.14.6-1) but 2.15.5-1 is to be installed i.e. one of your dependencies is also in experimental and therefore builds of your package try to use this experimental version which then fails because experimental is not a complete distribution. -- 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
Build-Depends-Indep, gtk-doc-tools and buildds
libgda3-3 is currently FTBFS on the autobuilders but local tests check out fine - I want to be able to close the RC bug in an NMU but I can't reproduce the buildd error. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466431 http://buildd.debian.org/fetch.cgi?pkg=libgda3;ver=3.0.2-1;arch=amd64;stamp=1203274481 gtk-doc-tools is not being picked up as a build depends during port builds, despite it being located during normal debuild, pdebuild and pbuilder checks on my machines. (pbuilder ... --binary-arch works too). gtk-doc-tools is in Build-Depends-Indep: in debian/control so porting builds will (presumably) drop that depends and this setup then conflicts with the explicit --enable-gtk-doc option in debian/rules, causing the upstream GTK_DOC_CHECK m4 macro to fail. There isn't much point forcing buildds to build the docs but the quick fix would be to put gtk-doc-tools into Build-Depends instead of Build-Depends-Indep. Do buildds set DEB_BUILD_OPTIONS ? (i.e. wrapping --enable-gtk-docs in "nodocs" support would help in other areas but would it allow the buildd runs to complete?) Is there a sane solution *and* a way to replicate this on a normal Debian box without implementing sbuild? (This is also holding up my own upstream work which needs a fix in this version of libgda3-3.) -- 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: Build-Depends-Indep, gtk-doc-tools and buildds
On Tue, 2008-03-04 at 13:06 +0100, Loïc Minier wrote: > On Tue, Mar 04, 2008, Neil Williams wrote: > > gtk-doc-tools is not being picked up as a build depends during port > > builds, despite it being located during normal debuild, pdebuild and > > pbuilder checks on my machines. (pbuilder ... --binary-arch works too). > > Could it be that gtk-doc-tools was added as a dep of another package? I've sent you a partial build log off-list but pbuilder does seem to be picking up this dependency directly. -> Creating pbuilder-satisfydepends-dummy package Package: pbuilder-satisfydepends-dummy Version: 0.invalid.0 Architecture: amd64 Maintainer: Debian Pbuilder Team <[EMAIL PROTECTED]> Description: Dummy package to satisfy dependencies with aptitude - created by pbuilder This package was created automatically by pbuilder and should Depends: bison, cdbs (>= 0.4.41), debhelper (>= 5), dpkg-dev (>= 1.13.19), flex, freetds-dev (>= 0.61), gnome-pkg-tools (>= 0.11), intltool, libgdbm-dev, libglib2.0-dev (>= 2.4.1-2), libmysqlclient15-dev, libpopt-dev, libpq-dev, libreadline5-dev, libsqlite3-dev, libxml2-dev (>= 2.4.22), libxslt1-dev (>= 1.0.18), pkg-config, scrollkeeper, unixodbc-dev, zlib1g-dev, gtk-doc-tools, sgmltools-lite dpkg-deb: building package `pbuilder-satisfydepends-dummy' in `/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'. gtk-doc-tools and sgmltools-lite are Build-Depends-Indep (or where before the upload to fix libgda3-3). > pbuilder should only pick build-deps and not -indep when run with > --binary-arch, but perhaps this is borken. It would be interesting to > try looking how your pbuilder came to select gtk-doc-tools for a > --binary-arch build. The logic is in > /usr/lib/pbuilder/pbuilder-satisfydepends-* and it might be easiest to > diagnose with the aptitude backend which will create a fake .deb with > the build-deps as deps and install it. > > > There isn't much point forcing buildds to build the docs but the quick > > fix would be to put gtk-doc-tools into Build-Depends instead of > > Build-Depends-Indep. > > (This is also holding up my own upstream work which needs a fix in this > > version of libgda3-3.) > > (Done and uploaded.) Thanks! -- 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: Build-Depends-Indep, gtk-doc-tools and buildds
On Tue, 2008-03-04 at 12:28 +, Neil Williams wrote: > On Tue, 2008-03-04 at 13:06 +0100, Loïc Minier wrote: > > On Tue, Mar 04, 2008, Neil Williams wrote: > > > gtk-doc-tools is not being picked up as a build depends during port > > > builds, despite it being located during normal debuild, pdebuild and > > > pbuilder checks on my machines. (pbuilder ... --binary-arch works too). > > > > Could it be that gtk-doc-tools was added as a dep of another package? > > I've sent you a partial build log off-list but pbuilder does seem to be > picking up this dependency directly. Nah, it was my fault. Got the option in the wrong place when calling pbuilder. (Bit of a pain that pbuilder requires such precise command line parsing) I originally did: $ sudo pbuilder build ../libgda3_3.0.2-1.dsc --binary-arch and that results in --binary-arch being ignored. $ sudo pbuilder build --binary-arch ../libgda3_3.0.2-1.dsc reproduces the original problem which has now been fixed in libgda. -- 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: [PATCH] debootstrap new options to list and check suite
On Thu, 2008-03-13 at 18:18 +0100, Julien Kerihuel wrote: > Hi List, > > Please find attached a small patch which add new options to debootstrap > script and manpage: > Any reason not to file this as a wishlist bug against debootstrap in the Debian Bug Tracking System? http://www.debian.org/Bugs/Reporting This isn't the kind of thing that generally needs discussion on debian-devel. -- 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: Proposing a new source control header to link to upstream BTSs
On Mon, 2008-03-17 at 02:38 -0300, Martín Ferrari wrote: > Dear -devel: > > Following the trend to add metadata to the debian/control file that > allows for the creation of new and powerful tools, I thought about the > usefulness of a header that'd allow to automatically relate to > upstream bug trackers. Please can this 'trend' be stopped here and now? The Packages.gz file is already enormous (especially for Emdebian purposes or other low resource units) and adding yet more fields to debian/control is really not that friendly. Please use debtags wherever possible for all such metadata - maybe even migrate some existing data in debian/control to debtags. This specific request, IMHO, is probably best done via links on the Homepage URL anyway. -- 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: Proposing a new source control header to link to upstream BTSs
On Mon, 2008-03-17 at 12:16 -0300, Martín Ferrari wrote: > On Mon, Mar 17, 2008 at 5:42 AM, Neil Williams <[EMAIL PROTECTED]> wrote: > > > Please can this 'trend' be stopped here and now? > > > > The Packages.gz file is already enormous (especially for Emdebian > > purposes or other low resource units) and adding yet more fields to > > debian/control is really not that friendly. > > I appreciate the strive to make Debian work on small machines, but it > is reasonable to put their constraints on the whole project? IMHO the Packages.gz file is already too large for my standard Debian machines! Unless you have a v.recent v.fast machine, reading the dpkg available file and apt package lists can take significant amounts of time. Even on this amd64 box, it is a noticeable delay. Why make that worse? Others have already indicated that this particular addition might not be the most useful addition to debian/control - I'd say leave it at that. > > Please use debtags wherever possible for all such metadata - maybe even > > migrate some existing data in debian/control to debtags. > > If I understand correctly, debtags are faceted and not free-form, so > you won't be able to enter URLs into it. That's probably for the best, IMHO. > Other data, like the type of > bug tracker, as Russ suggested, could be put in debtags, and it felts > like the correct place for doing it. Agreed. > > This specific request, IMHO, is probably best done via links on the > > Homepage URL anyway. > > Can you explain how you'd do this? ? Ask upstream ? I thought that would be the simplest solution. I fail to see any benefit in linking Debian to the upstream BTS - automated or otherwise and your replies to the other respondents has failed to persuade me that there is any merit in this idea at all. -- 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: Simple bug left unsolved
On Sun, 23 Mar 2008 14:36:04 +0100 Kurt Petersen <[EMAIL PROTECTED]> wrote: > The "installation-reports"-package has about 1.500 bug reports. It is > A LOT... Including archived bugs, there are also nearly 2,000 resolved bugs which is also a lot. > Something should be done to have at least simple bugs resolved fast. Well, maybe you could help with d-i rather than just point out the negative? -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgp47Yva2wtZc.pgp Description: PGP signature
Re: Should -dev packages providing .pc files depend on pkg-config?
On Mon, 2008-04-07 at 22:12 -0700, Steve Langasek wrote: > Any package that wants to use .pc files during its build is going to invoke > pkg-config directly, and changing your -dev package to recommend a different > means of linking to the library won't cause this reference to disappear. > That's a build-dependency. It's also a lot of packages - does such a dependency ever become inferred by other packages? It probably shouldn't, for your reasons above, so this would appear to be a case for a lintian check. If ./configure exists and calls pkg-config or configure.in|ac calls pkg-config or uses an m4 macro that calls pkg-config, the package should build-depend on pkg-config ? (We don't seem to have many lintian checks on Build-Depends.) I think the -dev package should not depend on pkg-config - whichever packages choose to use pkg-config to retrieve the data in the .pc file needs to depend on pkg-config. The -dev package doesn't call pkg-config. IMHO, the package providing the .pc file has no need to force any dependency on packages using the -dev. It is perfectly possible to avoid pkg-config but if you are linking against several -dev packages which all provide .pc files, it is inevitable that the package will be better off with pkg-config. This, in many ways, is no different to a build-depends on debhelper or dpatch. The package is using an existing tool as a direct component of the build in situations where another method might be possible (hardcoding the --libs and --cflags output) but not usually desirable. Yes, packages do build without debhelper but it is certainly easier (and desirable for most packages to avoid repeating the same bugs) to use debhelper. Similarly with pkg-config - you can build packages without it but it does make life easier and it does solve some problems inherent in other methods. (It brings in one or two problems of its own too.) (In terms of cross-building / debian-xcontrol, Simon, it's a Build-Depends-Tool.) -- 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: Should -dev packages providing .pc files depend on pkg-config?
On Wed, 2008-04-16 at 09:33 +0200, Goswin von Brederlow wrote: > Tollef Fog Heen <[EMAIL PROTECTED]> writes: > > > > That depends on the library you are linking against. I, as an library > > author is free to say «the only supported way to use my gargleblaster > > library is through the I_CAN_HAS_GARGELBLASTER autoconf macro» (which > > then proceeds to set GARGLEBLASTER_CFLAGS and GARGLEBLASTER_LIBS by > > using pkg-config). If I do that, pkg-config is effectively part of > > the API. > > I would go one step further. Imho libraries with *.pc files should say > "the only supported way to use this lib is by using pkg-config". No - because not all libraries restrict support to only pkg-config and there is no good reason to force an option to become a requirement. Just because a .pc file exists, does not mean it is the only supported method - it can be, but it does not have to be. *IF* .pc is the only supported method, then pkg-config is part of the API as above and the -dev dependency is justifiable. However, IMHO, the onus is on the source package to ensure that /usr/bin/pkg-config is available if the source package upstream requires it. > And > as such the *-dev package should depend on pkg-config as that is the > only proper way to use the package. What I'm saying is that the > library should make it a requirement and therefore depends which is > not the same as saying it has to be. It just should imho. Why? The presence of a .pc file is *not* an indicator that pkg-config is essential for that library or -dev, it can be optional. Some libraries may only support pkg-config, others have the option to package a .pc file for those who want it but let other users handle the relevant data directly. Indeed, handling the data separately can be a useful way of removing unwanted dependencies in the final application. The package that *must* depend on pkg-config (build-depend) is the package that runs a ./configure script expecting /usr/bin/pkg-config to exist and without any fallback code if it does not exist. > > | Putting pkg-config on Recommends of Suggests of every -dev packages > > | that has a .pc file, you could as well put it into built-essential > > | dependency. > > How would a Recommends or Suggests even help? Sure, users would get > the pkg-config installed. But buildds don't, right? So sources would > still FTBFS and would have to Build-Depend on pkg-config even if they > only call some autoconf macro from the *-dev package. What about these clauses as a Policy amendment? 1. If a library *only supports the retrieval of FOO_LIBS and / or FOO_CFLAGS by the use of pkg-config*, pkg-config becomes part of the API of that library and the -dev package of that library must depend on pkg-config. The mere presence of a .pc file in the -dev package of the library does *not* mean that only pkg-config is supported. e.g. where a library requires the use of an m4 macro that involves calling pkg-config, this would require the -dev package to depend on pkg-config but if a library provides a .pc file but also supports alternative method(s), the -dev package does not need to depend on pkg-config. 2. If a source package uses libraries that package a .pc but where all the libraries also support other methods of obtaining the relevant data, and the source package requires the use of pkg-config despite those other methods being available, then that choice by the source package upstream must result in a Build-Depends on pkg-config in the source package. Is that suitable as a Policy clause? (probably needs a few tweaks for clarity and examples in clause 1). It may well cause a few packages to depend or build-depend on pkg-config even though another dependency also requires it but duplication of dependencies is not a problem. -- 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: How to manage security issues when the maintainer is not the developer
On Wed, 2008-04-16 at 13:55 +0200, Andrea De Iacovo wrote: > Hi all. > > How do you think a maintainer should manage security issues when he is > not the package developer? Should he/she either work alone to make > patches or wait for the upstream patches/relases that solve the bug? Notify upstream, work on the patch and stay in communication with upstream as you work. If you get a response from upstream, work together to come up with a complete solution but don't let that process cause undue delay to fixing the problem (especially close to a release, as now). If upstream are busy with other things, solve the problem yourself and make the upload - ask the security team for help with that side if you are unsure. Solve the problem - if upstream come back to you with a different fix later, you can always migrate to that fix. -- 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
Should SONAME bumps always go through NEW
On Wed, 2008-04-16 at 13:34 +0200, Bas Wijnen wrote: > On Wed, Apr 16, 2008 at 01:08:05PM +0200, Ondrej Certik wrote: > > if I want to packge a new upstream version of DM-Upload-Allowed > > library (for example [1]), it changes the name of the binary package > > and thus goes to NEW. > > > > Last time I asked it wasn't possible for me, as a DM, to upload it and > > I had to search for a sponsor. (and that is just as it should be). > > Is there some policital reason for that, > > Yes. DMs are not as thoroughly checked as DDs, and thus have less > rights to change things in the archive. The idea is that they should be > allowed to upload packages they already maintain, but not add new ones. > This is true both for new source, and new binary packages. What kind of new binary package can be more disruptive than a SONAME bump??? The restrictions exist for good technical reasons. SONAME bumps need careful management across a number of different packages. > A library soname transition is a binary package name change for > technical reasons. IMO there isn't really a good reason to send them > through NEW at all, but that's how the scripts work. It does give others watching NEW a chance to see a pending transition - bumping a SONAME should not be done lightly (especially now). I think that is a good reason. > If you can build consensus on the fact that soname bumps shouldn't go > through NEW, then you could implement that technically. Personally, I think that SONAME bumps in NEW get "fast-tracked" through the queue anyway and I think it is a worthwhile safeguard that should be retained. If SONAME bumps are not to go through NEW in the future, I think it should be mandatory that SONAME bumps go through some other "holding" phase instead - there should be technical restrictions on library transitions and that DM's should still not be allowed to make uploads that involve a SONAME bump. Such a "holding" phase would just be another name for NEW anyway, hence I think it should stay as-is. Dropping this merely for the convenience of DM's when the real problem is delays in NM is trying to fix the wrong problem in the wrong place, IMHO. > But I don't > think you will be able to. In fact, most people might well think that > soname bumps should indeed go through NEW, and that that is not a bug. :-) Most definitely not a bug, IMHO. -- 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: Should DMs be allowed to upload to NEW
On Wed, 2008-04-16 at 15:59 +0200, Ondrej Certik wrote: > Thanks for the reply. As I said, I am not questioning new SONAME bumps > going into NEW. > > The question is, whether the DMs should be allowed to upload SONAME > bumps to NEW by themselves or not. Umm, I would have to say no. Sorry. SONAME bumps are just too disruptive IMHO. > I agree there should be a special > attention to SONAME bumps and that's what the NEW is for (or any other > queue as you said). NEW is a step that can help with SONAME bumps but it is not sufficient on its own. SONAME transitions MUST be coordinated amongst all the DD's (and upstreams) involved. Such uploads can take months to arrange and coordinate - your sponsor is best placed to deal with these issues. More haste, less speed. DDs can make mistakes but DMs are not full DDs and as such, the intervention of a DD is appropriate when the potential upload could cause havoc in the rest of Debian (IMHO). > It's all about how much trust you give to DMs. Imho if they are > allowed to upload new revisions and even new upstream (if the name of > all the binaries and the number of them stays the same), they can > screw up a lot of things. Not as many as a SONAME transition. Any library upload can mistakenly result in a broken API/ABI but normally that only affects one part of the library functionality. A new SONAME is a completely NEW library - there is nothing that says that libfoo1 has to have *anything* in common with libfoo2 at a binary or source code level. It might do the same things on the surface but during a SONAME change, the library upstream can change 100% of the API and touch 100% of the source code. Every single header filename, function prototype, typedef, macro, struct and variable. e.g. some SONAME bumps have involved a complete renaming of the functions and variables to a new namespace - FooFunc becoming foo_func etc. and with structs going the opposite way from foo_data to FooData. Yes, the principle of the library stays the same and it works in a similar manner once the reverse dependencies are rebuilt but nothing else is the same. After all, Debian is STILL carrying gtk1 - that should give you some idea of the disruption caused by SONAME bumps. The consequences of a single upload can take YEARS to resolve (and still involve the removal of otherwise usable packages). A new application can change 100% of the source code without problems - many do change as much as 50% at each major release. Changing the behaviour of a shared library has far wider implications. The two simply cannot be compared. I maintain (and co-maintain) a range of libraries, some upstream too - I can honestly say that I would not consider any of those as suitable for DM-Upload, even without changing a SONAME. > So giving them the right to also upload new > binary packages to NEW imho belongs to the same cathegory. Not even close. IMHO, the very fact that you equate those two makes me doubt that you properly understand shared libraries and SONAME bumps in Debian. An upload of a new application is nowhere near as complex as the upload to start a library SONAME transition. Even uploading a new library never seen in Debian before is easier than starting a SONAME transition for a library that already exists. I'm sorry, merely by equating those two you have lost all credibility in my eyes. It's not just about trust, it is about coordination, planning and ability. If you think that a SONAME transition is no more disruptive than a new application then I have cause to worry about your ability to maintain a library in Debian in the first place. It doesn't give me any confidence in you or in DMs in general. -- 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: Should -dev packages providing .pc files depend on pkg-config?
On Wed, 2008-04-16 at 16:12 +0200, Gabor Gombas wrote: > On Wed, Apr 16, 2008 at 11:23:51AM +0100, Neil Williams wrote: > > > What about these clauses as a Policy amendment? > > > > 1. If a library *only supports the retrieval of FOO_LIBS and / or > > FOO_CFLAGS by the use of pkg-config*, pkg-config becomes part of the API > > of that library and the -dev package of that library must depend on > > pkg-config. The mere presence of a .pc file in the -dev package of the > > library does *not* mean that only pkg-config is supported. e.g. where a > > library requires the use of an m4 macro that involves calling > > pkg-config, this would require the -dev package to depend on pkg-config > > but if a library provides a .pc file but also supports alternative > > method(s), the -dev package does not need to depend on pkg-config. > > > > 2. If a source package uses libraries that package a .pc but where all > > the libraries also support other methods of obtaining the relevant data, > > and the source package requires the use of pkg-config despite those > > other methods being available, then that choice by the source package > > upstream must result in a Build-Depends on pkg-config in the source > > package. > > > > Is that suitable as a Policy clause? (probably needs a few tweaks for > > clarity and examples in clause 1). > > Wow, that's awfully complicated. Yes, I realise that. > This is much more straightforward: > > "If a package wants to call /usr/bin/foo during build and fails > to build properly if /usr/bin/foo is not present, then the > package MUST Build-Depend: on some other package providing > /usr/bin/foo". It doesn't account for packages where pkg-config really is part of the API of the library but maybe that is the way it should be. If a library enforces the use of pkg-config, it is still the choice of upstream to use that library or implement a different version - as such, the choice carries a consequence of depending on pkg-config in Build-Depends. I'm not convinced that that is such a penalty but others on -devel wanted a different view so I tried to cover that in the clauses. I was merely trying to reflect other threads in this discussion - I haven't actually got a concrete example of a library that includes pkg-config into the API. There may well be corner cases I don't know about but AFAICT most cases would be met correctly by the simpler expedient of "you use it, you depend on it" as you describe. > And by this definition, it is the package _invoking_ pkg-config that > should Build-Depend on it, not the package that happens to ship a .pc > file. I agree with that interpretation and that intention, I'm just not sure it covers all eventualities. -- 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: Should -dev packages providing .pc files depend on pkg-config?
On Wed, 2008-04-16 at 19:15 +0200, Goswin von Brederlow wrote: > Gabor Gombas <[EMAIL PROTECTED]> writes: > > > On Wed, Apr 16, 2008 at 11:23:51AM +0100, Neil Williams wrote: > > > >> What about these clauses as a Policy amendment? > >> > >> 1. If a library *only supports the retrieval of FOO_LIBS and / or > >> FOO_CFLAGS by the use of pkg-config*, pkg-config becomes part of the API > >> of that library and the -dev package of that library must depend on > >> pkg-config. The mere presence of a .pc file in the -dev package of the > >> library does *not* mean that only pkg-config is supported. e.g. where a > >> library requires the use of an m4 macro that involves calling > >> pkg-config, this would require the -dev package to depend on pkg-config > >> but if a library provides a .pc file but also supports alternative > >> method(s), the -dev package does not need to depend on pkg-config. > >> > >> 2. If a source package uses libraries that package a .pc but where all > >> the libraries also support other methods of obtaining the relevant data, > >> and the source package requires the use of pkg-config despite those > >> other methods being available, then that choice by the source package > >> upstream must result in a Build-Depends on pkg-config in the source > >> package. > >> > >> Is that suitable as a Policy clause? (probably needs a few tweaks for > >> clarity and examples in clause 1). > > > > Wow, that's awfully complicated. This is much more straightforward: > > > > "If a package wants to call /usr/bin/foo during build and fails > > to build properly if /usr/bin/foo is not present, then the > > package MUST Build-Depend: on some other package providing > > /usr/bin/foo". > > > > And by this definition, it is the package _invoking_ pkg-config that > > should Build-Depend on it, not the package that happens to ship a .pc > > file. > > > > Gabor > > You are missing the point. > > What if the library says "You must call /usr/bin/foo during build"? > The libarry does not use foo, only the user, so no depends? The library -dev package includes the binary - if that binary needs other binaries to run, the package containing the binary must depend on those packages. So if /usr/bin/foo is actually a script that calls pkg-config, the -dev package containing /usr/bin/foo must depend on pkg-config. However, unless the application linking against the library does not use pkg-config for any other libraries that it needs, the application will be running pkg-config during the ./configure script so the application will need to Build-Depend on pkg-config as well. > Or idoes forcing users to use foo make foo part of the API and hence > the library should depend on it? Exactly - it does, IMHO. That is why I suggested the more complex wording, albeit still based on the "you run it, you depend on it" mantra. -- Neil Williams <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Should -dev packages providing .pc files depend on pkg-config?
On Wed, 2008-04-16 at 19:57 +0200, Gabor Gombas wrote: > On Wed, Apr 16, 2008 at 07:15:53PM +0200, Goswin von Brederlow wrote: > > > You are missing the point. > > > > What if the library says "You must call /usr/bin/foo during build"? > > But the library can't say "foo must come from a Debian package". What if > I have my local replacement? /usr/local/bin/foo ? > Why should I be forced to install a package > that is now useless for me (and installing it would only cause confusion > as there are now two different tools with the same name present in > $PATH)? That is a problem with your replacement, not with the Debian package. If your replacement is a Debian package, you need to use Debian Policy to handle that situation - it still doesn't mean that it is the fault of the library or that the library must support your alternative. > > > The libarry does not use foo, only the user, so no depends? > > Of course no dependency is needed. To run /usr/bin/foo, if you need bar, the package containing foo must depend on bar. That, in this case, means libfoo-dev depends on pkg-config. > If the library is not used by anyone > (think about an NFS server that just exports the library), then a > missing "foo" would not hurt anyone. And if someone _does_ use the > library, then that user must depend on "foo", and everything is fine. Or more exactly, the package containing foo which will be the -dev. > > Or idoes forcing users to use foo make foo part of the API and hence > > the library should depend on it? > > You can't _force_ anyone to use foo. At most you can say "I'm not going > to give you support if I somehow find out you didn't use foo" but that's > it. I should be able to write my own tools and use the library in > whatever way I want - or the library must go into non-free. True, but you cannot dictate to the library that it must support your replacement or even not conflict with it. Your replacement needs to live with the package as-is, in accordance with Debian Policy. If Policy gets an update that "you run it, you depend on it" along the lines of my previous post, then the -dev would depend on pkg-config and most other applications using the library would depend on pkg-config *if* they need that to work with other libraries. (That's the usual case - most applications will end up running pkg-config so most applications will end up with a Build-Depends: pkg-config, ) -- Neil Williams <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Should -dev packages providing .pc files depend on pkg-config?
On Wed, 2008-04-16 at 17:23 +0200, Bas Wijnen wrote: > First of all, I skipped a large part of this thread, so I'm sorry if > this has come up before. > > On Wed, Apr 16, 2008 at 03:53:03PM +0100, Neil Williams wrote: > > > And by this definition, it is the package _invoking_ pkg-config that > > > should Build-Depend on it, not the package that happens to ship a .pc > > > file. > > > > I agree with that interpretation and that intention, I'm just not sure > > it covers all eventualities. > > What is missed, I think, is the situation where: > - the library which ships the .pc file also ships a script which calls > pkg-config, called foo-config. > - the library provides this as an option, and lets you use other options > (for example using pkg-config directly) as well. > - the library wants the foo-config option to be opaque, that is, it may > stop using pkg-config in the future, and use some other method to > provide the flags. That is an example of a library including pkg-config into the library API. Changing that behaviour (dropping the script) means a SONAME bump. > According to the suggested definition, if a package using this library > chooses to use foo-config, it doesn't call pkg-config directly (and it > may not call it at all, this depends on the inner workings of > foo-config). During the time that foo-config calls pkg-config, the -dev package containing foo-config must depend on pkg-config. That follows logically from the "you call it, you depend on it" model. > So the package wouldn't need a Build-Depends: on > pkg-config. However, the library doesn't need a Depends: either, > because the package can well be used without pkg-config. Which is where that complexity comes in again - if the package calls foo-config, it must depend on the -dev. If foo-config *as a script* requires pkg-config, the -dev must depend on pkg-config because it is calling it. A simple .pc file doesn't call anything so that does not lead to a dependency on pkg-config for the -dev. If we stick with the idea of "you call it, you depend on it", these situations become a lot clearer. If foo-config changes internally to not call pkg-config anymore, that allows the -dev to drop the pkg-config dependency. What is wrong, therefore, is for the package using foo-config to expect that the -dev continues to provide pkg-config and to then use pkg-config itself for other things *without* a dependency. i.e. a duplicate dependency is the best approach here. -- 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: Should -dev packages providing .pc files depend on pkg-config?
On Wed, 2008-04-16 at 22:12 +0200, Jakob Bohm wrote: > On Wed, Apr 16, 2008 at 04:12:45PM +0200, Gabor Gombas wrote: > > On Wed, Apr 16, 2008 at 11:23:51AM +0100, Neil Williams wrote: > > > > > What about these clauses as a Policy amendment? > > > > > > 1. If a library *only supports the retrieval of FOO_LIBS and / or > > > FOO_CFLAGS by the use of pkg-config*, pkg-config becomes part of the API > > > of that library and the -dev package of that library must depend on > > > pkg-config. The mere presence of a .pc file in the -dev package of the > > > library does *not* mean that only pkg-config is supported. e.g. where a > > > library requires the use of an m4 macro that involves calling > > > pkg-config, this would require the -dev package to depend on pkg-config > > > but if a library provides a .pc file but also supports alternative > > > method(s), the -dev package does not need to depend on pkg-config. > > > > > > 2. If a source package uses libraries that package a .pc but where all > > > the libraries also support other methods of obtaining the relevant data, > > > and the source package requires the use of pkg-config despite those > > > other methods being available, then that choice by the source package > > > upstream must result in a Build-Depends on pkg-config in the source > > > package. > > > > > > Is that suitable as a Policy clause? (probably needs a few tweaks for > > > clarity and examples in clause 1). > > > > Wow, that's awfully complicated. This is much more straightforward: > > > > "If a package wants to call /usr/bin/foo during build and fails > > to build properly if /usr/bin/foo is not present, then the > > package MUST Build-Depend: on some other package providing > > /usr/bin/foo". > > > > And by this definition, it is the package _invoking_ pkg-config that > > should Build-Depend on it, not the package that happens to ship a .pc > > file. > > > > Here is another example supporting Gabor's proposal over Neil's: > > Package libfoo-dev version 1.0.4 only documents how to use libfoo via > pkg-config. Package bar build-depends on libfoo-dev >= 1.0.4 and uses > pkg-config to locate libfoo.so.1 etc. Under Neil's rules, libfoo-dev would > Depends: pkg-config, bar would not Build-Depends: pkg-config. Under Gabor's > rules, bar would Build-Depend pkg-config, but libfoo-dev would only > Recommends: pkg-config. No - bar would Build-Depends: pkg-config because it contains a ./configure script that calls pkg-config - that's why some duplication will always occur, precisely to prevent these failures. A duplicate depends is not a problem. Your example states: "bar uses pkg-config to locate libfoo.so.1" - bar calls pkg-config so it must depend on it - in this case Build-Depends:. That was the result of an over-zealous edit of the clauses. Sorry. 0 If a source package calls pkg-config directly, it must Build-Depend on pkg-config. > > > 2. If a source package uses libraries that package a .pc but where all > > > the libraries also support other methods of obtaining the relevant data, > > > and the source package requires the use of pkg-config despite those > > > other methods being available, then that choice by the source package > > > upstream must result in a Build-Depends on pkg-config in the source > > > package. From another message: If we stick with the idea of "you call it, you depend on it", these situations become a lot clearer. If foo-config changes internally to not call pkg-config anymore, that allows the -dev to drop the pkg-config dependency. What is wrong, therefore, is for the package using foo-config to expect that the -dev continues to provide pkg-config and to then use pkg-config itself for other things *without* a dependency. i.e. a duplicate dependency is the best approach here. > However just to clarify on some other examples elsewhere in this thread, > the following rules may need to be added: > >2. If libfoo-dev contains scripts which would typically be called by > packages that Depend, Pre-Depend or Build-Depend on libfoo-dev, then > anything needed by those scripts should (RFC-should) be ordinary > Depends for the libfoo-dev package. For instance if programs building > against libfoo would typically call /usr/bin/foo-config-get, then > anything called by foo-config-get (such as pkg-config or perl) would > need to be listed as Depends for libfoo-dev. Note that this does not > extend to anything otherwise needed by callers to take advantage of &g
Bug#476793: ITP: soci -- C++ Database Access Library
Package: wnpp Severity: wishlist Owner: Neil Williams <[EMAIL PROTECTED]> * Package name: soci Version : 2.2.0 Upstream Author : Maciej Sobczak, Stephen Hutton, David Courtney, Pawel Aleksander Fedorynski, Rafal Bobrowski, Mateusz Loskot * URL : http://soci.sourceforge.net/ * License : Boost Programming Lang: C++ Description : C++ Database Access Library Database access library for C++ that makes the illusion of embedding SQL queries in the regular C++ code, staying entirely within standard C++. Includes backends for MySQL, Postgres, SQLite3 and Oracle (Oracle backend will not be packaged at this time). -- 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477218: ITP: estron -- data-centric development interpreter for GNOME
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: estron Version: 0.7.0 Upstream Authors: Neil Williams, Linas Vepstas URL: http://estron.alioth.debian.org/ License: LGPL Description: data-centric development interpreter for GNOME estron supports the creation of data-driven graphic interfaces based on the structure of the data, not a programming language. estron interface files are written in XML and declare an interface between the datasource and a graphic interface, currently Glade. Interfaces are designed, improved and operated at runtime. Other GUI design tools could also be supported. Estron - the new name for DWI, Data with Integration - is a fairly simple environment for quickly creating data-driven applications, that is, graphical applications that manipulate and show info from a database. This environment differs from others in that it is focused on native GTK/Gnome support through the Glade GUI designer, and thus allows you to build user interfaces as elegant as you can make them in Glade. Multiple SQL database vendors are supported through ODBC or libdbi drivers. There is a simple db-driver infrastructure so its easy to support for additional SQL API's. estron is also related to QOF and the two engines work together so that estron applications can also access QOF data sources like QSF XML, sqlite0 and libgda3 (awaiting completion in libqof2). estron can be the glue between various data sources, providing a common means of accessing user data, calculating intermediate data and exporting results in a variety of formats. estron allows users to design, improve and operate estron interfaces without recompilation. At all stages, the interface is determined by the structure of the data, not the limitations or complexity of a programming language. I've restarted upstream development with help from Linas - the use of Alioth is purely for easier upstream development, estron is not a native Debian package. Expected binary packages: estron (runtime interpreter), estron-examples, libestron0, libestron-dev, libestron-dbg and libestron-doc (libestron API). The -dev is only needed when developing applications to export estron files or interface directly with libestron0 during other operations. Applications written in estron only need the runtime interpreter. My expectation is that quicklist will be one of the current applications to gain estron export support, providing a simple GUI for creating estron files (which currently need to be created manually). A full WYSIWYG estron GUI is also possible. Some issues remain to be resolved upstream before the 0.7.0 release is made (removing some deprecated Gtk code mainly). If anyone wants to see estron available in Lenny (or help make that happen), let me know. Otherwise, I expect to release and upload estron 0.7.0 alongside libqof2 0.8.0 after Lenny. The current code is in Debian SVN (link on the alioth homepage) if anyone wants to try it. (I can prepare a version in experimental if requested.) -- 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#477699: general: No read permission for /usr/include/GL directory
On Thu, 2008-04-24 at 19:13 +0300, Heikki Orsila wrote: > Package: general > Severity: important > > Directory /usr/include/GL lacks read permissions, and thus, can not be > listed: mesa-common-dev creates /usr/include/GL with the correct permissions: drwxr-xr-x root/root 0 2008-04-11 08:30 ./usr/include/GL/ > > $ ls -la /usr/include/GL > total 640 > drwx--x--x 2 root root 4096 2008-04-24 18:49 . > drwxr-xr-x 102 root root 12288 2008-04-24 18:49 .. $ ls -la /usr/include/GL total 796 drwxr-xr-x 3 root root 4096 2008-04-12 05:23 . drwxr-xr-x 204 root root 16384 2008-04-24 04:58 .. -rw-r--r-- 1 root root 5028 2007-11-16 15:36 freeglut_ext.h This would appear to be a problem only on your own system. I would suggest that this bug should be closed, it certainly does not appear to be a "general" bug because only one package creates that directory and that package is creating it correctly AFAICT. $ umask 0022 # umask 0022 > My root user has default umask 0077. 0077 is not the default umask for a user or for root and I suspect that this is the cause of your problem. If this is the case, this bug needs to be closed and you need to reset the current umask for the root user. -- 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#427697: sbackup uses a non-existent group.
On Thu, 2008-04-24 at 22:39 +0900, Charles Plessy wrote: > I need your advice for bug #427697: Although the bug has been open a while, the severity was only increased a few days ago. It seems hasty to look for a forced solution IMHO. > As far as #427697 is concerned, there are two obvious solutions: > > 1) Use a group that exists. The problems are: > - I am too inexperienced to pick one that makes sense, > - I know nothing about python, in which sbackup is programmed, In which case, you should not even entertain ideas of hijacks. > - I am only interested in sbackup as a user, not as a DD, and I would > rather swich to an alternative if it were abandonned. > > I use sbackup at work, so I definitely would consider migrating to > something else would the bug be rotting longer. But it would not help > the other persons lured to use an unmaintained package, so I hope that > something can be done. unmaintained? On what grounds? It's been three days since the severity was bumped. Mon, 21 Apr 2008 14:57:39 +0900 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=427697#25 > The best would of course that the maintainer himself would show some > sign of activity. Maybe he has a mail configuration problem ? and maybe he's just busy, like many of us. -- 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#477699: general: No read permission for /usr/include/GL directory
On Thu, 2008-04-24 at 19:10 +0200, Julien Cristau wrote: > On Thu, Apr 24, 2008 at 18:02:28 +0100, Neil Williams wrote: > > > I would suggest that this bug should be closed, it certainly does not > > appear to be a "general" bug because only one package creates that > > directory and that package is creating it correctly AFAICT. > > > dpkg creates that directory, and dpkg ought to use the permissions from > the package, regardless of umask, IMO. I follow dpkg development only as a basis of working within Emdebian so I can't really comment on whether dpkg should ignore umask - it might be a good idea to reassign this bug to dpkg and see what the dpkg maintainers feel about this behaviour. -- 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
BTS pseudo-package: buildd.emdebian.org ?
kages.debian.org pages. Only a fraction of the packages in Debian would show up in Emdebian. Currently, we have 211 source packages, building 642 binaries. [4] (I am looking at d-i support for Emdebian but haven't had time to look at it closely since talking to Frans Pop at FOSDEM.) Comments? [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=337733#10 [1] http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED] [2] http://www.emdebian.org/bugs.php (parses the same tags) [3] http://wiki.debian.org/EmdebianPolicy [4] http://www.emdebian.org/packages/search.php -- 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#480514: general: buildd.emdebian.org : Need a crossbuilding buildd compliant with Emdebian Policy
Package: general Severity: wishlist This is filed against general in advance of a buildd.emdebian.org pseudo-package becoming available. See #480408 Emdebian has a set of prebuilt binary packages which allow an 80% reduction in the total installation size of the final Debian system, acheived through the use of TDebs, DEB_BUILD_OPTIONS and patches held in Emdebian SVN. Currently, I am maintaining just over 210 source packages (over 600 binary packages) with manual builds and patches but in order for Emdebian to support armel and i386, an autobuilder is needed. Basic script support for a cross-building buildd exists in emdebian-tools, work is still needed to get this working smoothly and then implement on a suitable machine: http://buildd.emdebian.org Emdebian also has a developing Policy that is based on Debian Policy - a wiki page indicates where the two documents differ: http://wiki.debian.org/EmdebianPolicy The autobuilder would use existing lintian support to ensure that crossbuilds are compliant with Emdebian Policy, principally that the crossbuilt binaries really are the correct architecture. Maintaining these packages via manual builds is unsustainable and causes problems with a usable testing/stable migration because certain versions might simply not exist in the repository when a migration should occur. The lack of internet-visible build logs is also a significant problem for helping other people begin developing their own packages for Emdebian. -- 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#480515: buildd.emdebian.org: gconf unable to be uploaded, libldap-2.4-2 failed to cross build
Package: general
Severity: normal
In preparation for a pseudo-package, buildd.emdebian.org, I'm filing
status bugs about packages that block the use of packages that
crossbuild successfully.
libldap-2.4.2 fails to cross build:
configure: error: crossing compiling: use
--with-yielding_select=yes|no|manual
make: *** [configure-stamp] Error 1
dpkg-buildpackage: failure: debian/rules build gave error exit status 2
In this particular case, the initial fix is probably a value in the
cache file but the dependencies of libldap also cause problems due to a
failure to cross build liborbit2.
gconf cannot be uploaded as it would result in broken dependencies:
Checking for error logs in /opt/emdebian/trunk/g/gconf/trunk/
gconf2 (= 2.22.0-1em1): FAILED
libgconf2-4 (= 2.22.0-1em1): FAILED
gconf2 (= 2.22.0-1em1) depends on libgconf2-4 (>= 2.13.5) {libgconf2-4
(= 2.22.0-1em1)}
libgconf2-4 (= 2.22.0-1em1) depends on libldap-2.4-2 (>= 2.4.7) {NOT
AVAILABLE}
libgconf2-4 (= 2.22.0-1em1) depends on libldap-2.4-2 (>= 2.4.7) {NOT
AVAILABLE}
Thu May 8 00:56:43 BST 2008
This bug is blocked by the problems in libldap but is also blocking the
use of gpe-filemanager which requires gconf.
Due to the lack of a crossbuilding buildd, the build logs are not
internet-visible at this time. Builds can be reproduced using
emdebian-tools.
-- 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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#480518: buildd.emdebian.org: libgpewidget needs DEB_BUILD_OPTIONS="nodocs" support in debhelper
Package: general Severity: normal libgpewidget includes documentation files required by Debian Policy and is unable to remove these using the DEB_BUILD_OPTIONS="nodocs" option due to a lack of support for this option in debhelper. Documentation needs to be removed when preparing Emdebian packages in order to comply with Emdebian Policy. http://wiki.debian.org/EmdebianPolicy Currently, this means that libgpewidget needs to be crossbuilt with a patch for debian/rules. This bug is being filed in preparation for a pseudo-package, buildd.emdebian.org, where these issues can be set out and fixed. The intention is to provide simple support for Emdebian packages without needing patches by filing appropriate bug reports against the packages themselves and against packages that block such actions as well as tracking bugs filed against buildd.emdebian.org so that the overall status of the Emdebian builds is visible to anyone, not just the person doing the builds (me). This is not a bug in libgpewidget because libgpewidget is doing what is required by Debian Policy - it is a bug in buildd.emdebian.org because Emdebian needs to be able to build as many packages as possible without any patches and this requirement is blocked by #448615. i.e. Where the need for a patch can be removed by fixing a package already in Debian, the bug is in buildd.emdebian.org until the bug in the relevant package is closed (in this case, debhelper). -- 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#480521: buildd.emdebian.org: gpe-clock inherits wrong configure environment
Package: general Severity: normal This bug is in preparation for a buildd.emdebian.org pseudo-package. This is not a bug in gpe-clock because gpe-clock is doing what is required by CDBS - it is a bug in buildd.emdebian.org because Emdebian needs to be able to build as many packages as possible without any patches and this requirement is blocked by #450483 i.e. Where the need for a patch can be removed by fixing a package already in Debian, the bug is in buildd.emdebian.org until the bug in the relevant package is closed (in this case, cdbs). -- 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#480709: buildd.emdebian.org: cupsys fails to cross build, cannot be updated
Package: general Severity: normal User: [EMAIL PROTECTED] In preparation for a pseudo-package, buildd.emdebian.org, I'm filing status bugs about packages that block the use of packages that crossbuild successfully or fail to cross build themselves after an update in Debian. $ emsource --status cupsys Checking the apt-cross cache is up to date for arm. Checking status of cupsys in /opt/emdebian/trunk/c/cupsys/trunk/ 7 emdebian patch files 0 debian patch files Checking emdebuild status in /opt/emdebian/trunk/c/cupsys/trunk/ build logs: /opt/emdebian/trunk/c/cupsys/trunk/cupsys_1.3.7-1em1_arm.build /opt/emdebian/trunk/c/cupsys/trunk/cupsys_1.3.7-5em1_arm.build Checking empdebuild status cupsys may be out of date. Checking for error logs in /opt/emdebian/trunk/c/cupsys/trunk/ Checking bug status No open cross-building bugs for cupsys cupsys FAILED to build. $ tail /opt/emdebian/trunk/c/cupsys/trunk/cupsys_1.3.7-5em1_arm.build from adminutil.c:37: /usr/include/pthread.h:653: warning: ‘__regparm__’ attribute directive ignored /usr/include/pthread.h:664: warning: ‘__regparm__’ attribute directive ignored /usr/include/pthread.h:708: warning: ‘__regparm__’ attribute directive ignored make[2]: *** [adminutil.o] Error 1 make[2]: Leaving directory `/opt/emdebian/trunk/c/cupsys/trunk/cupsys-1.3.7/cups' make[1]: *** [all] Error 1 make[1]: Leaving directory `/opt/emdebian/trunk/c/cupsys/trunk/cupsys-1.3.7' make: *** [debian/stamp-makefile-build] Error 2 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#480710: buildd.emdebian.org: avahi cannot be updated, new version fails to cross build
Package: general Severity: normal User: [EMAIL PROTECTED] In preparation for a pseudo-package, buildd.emdebian.org, I'm filing status bugs about packages that block the use of packages that crossbuild successfully. $ emsource --status avahi Checking the apt-cross cache is up to date for arm. Checking status of avahi in /opt/emdebian/trunk/a/avahi/trunk/ 9 emdebian patch files 0 debian patch files Checking emdebuild status in /opt/emdebian/trunk/a/avahi/trunk/ build log: avahi (0.6.22) FAILED to cross build for arm. /opt/emdebian/trunk/a/avahi/trunk/avahi_0.6.22-3em1_arm.build Checking for error logs in /opt/emdebian/trunk/a/avahi/trunk/ Checking bug status No open cross-building bugs for avahi avahi FAILED to build. In file included from /usr/arm-linux-gnu/include/gtk-2.0/gtk/gtkactiongroup.h:34, from /usr/arm-linux-gnu/include/gtk-2.0/gtk/gtk.h:38, from main.c:33: /usr/arm-linux-gnu/include/gtk-2.0/gtk/gtkitemfactory.h:50: warning: function declaration isn’t a prototype arm-linux-gnu-gcc: -lpthread: linker input file unused because linking not done make[3]: *** No rule to make target `../avahi-glib/libavahi-glib.la', needed by `avahi-discover-standalone'. Stop. make[3]: Leaving directory `/opt/emdebian/trunk/a/avahi/trunk/avahi-0.6.22/avahi-discover-standalone' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/opt/emdebian/trunk/a/avahi/trunk/avahi-0.6.22' make[1]: *** [all] Error 2 make[1]: Leaving directory `/opt/emdebian/trunk/a/avahi/trunk/avahi-0.6.22' make: *** [debian/stamp-makefile-build] Error 2 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#480706: buildd.emdebian.org: coreutils fails to cross build
Package: general Severity: normal 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 coreutils Checking the apt-cross cache is up to date for arm. Checking status of coreutils in /opt/emdebian/trunk/c/coreutils/trunk/ 6 emdebian patch files 0 debian patch files Checking emdebuild status in /opt/emdebian/trunk/c/coreutils/trunk/ build log: coreutils (6.10) FAILED to cross build for arm. /opt/emdebian/trunk/c/coreutils/trunk/coreutils_6.10-6em1_arm.build Checking empdebuild status coreutils may be out of date. Checking for error logs in /opt/emdebian/trunk/c/coreutils/trunk/ Checking bug status No open cross-building bugs for coreutils coreutils FAILED to build. $ tail /opt/emdebian/trunk/c/coreutils/trunk/coreutils_6.10-6em1_arm.build /usr/arm-linux-gnu/include/stdio.h:718: error: conflicting types for 'rpl_fseeko' ./stdio.h:277: error: previous declaration of 'rpl_fseeko' was here make[3]: *** [areadlink-with-size.o] Error 1 make[3]: Leaving directory `/opt/emdebian/trunk/c/coreutils/trunk/coreutils-6.10/build-tree/coreutils-6.10/lib' make[2]: *** [all] Error 2 make[2]: Leaving directory `/opt/emdebian/trunk/c/coreutils/trunk/coreutils-6.10/build-tree/coreutils-6.10/lib' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/opt/emdebian/trunk/c/coreutils/trunk/coreutils-6.10/build-tree/coreutils-6.10' make: *** [build-stamp] Error 2 dpkg-buildpackage: failure: debian/rules build gave error exit status 2 This is a placeholder bug until buildd.emdebian.org is available as a pseudo-package but serves to explain why coreutils is not being updated and the nature of the build failure. See #480514 regarding why the build logs are not available online yet. -- 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#480711: buildd.emdebian.org: curl cross built but unable to upload, missing dependencies
Package: general
Severity: normal
User: [EMAIL PROTECTED]
In preparation for a pseudo-package, buildd.emdebian.org, I'm filing
status bugs about packages that block the use of packages that
crossbuild successfully.
$ emsource --status curl
Checking the apt-cross cache is up to date for arm.
Checking status of curl in /opt/emdebian/trunk/c/curl/trunk/
20 emdebian patch files
0 debian patch files
Checking emdebuild status in /opt/emdebian/trunk/c/curl/trunk/
curl may be out of date.
Checking for error logs in /opt/emdebian/trunk/c/curl/trunk/
curl (= 7.18.0-1em1): FAILED
libcurl3 (= 7.18.0-1em1): FAILED
libcurl3-gnutls (= 7.18.0-1em1): FAILED
curl (= 7.18.0-1em1) depends on libcurl3 (>= 7.16.2-1) {libcurl3 (=
7.18.0-1em1)}
libcurl3 (= 7.18.0-1em1) depends on libidn11 (>= 0.5.18) {NOT
AVAILABLE}
libcurl3 (= 7.18.0-1em1) depends on libidn11 (>= 0.5.18) {NOT
AVAILABLE}
libcurl3-gnutls (= 7.18.0-1em1) depends on libgnutls26 (>= 2.2.0-0)
{NOT AVAILABLE}
Sat May 3 20:36:03 BST 2008
curl (= 7.18.0-1em1): FAILED
libcurl3 (= 7.18.0-1em1): FAILED
libcurl3-gnutls (= 7.18.0-1em1): FAILED
libcurl4-gnutls-dev (= 7.18.0-1em1): FAILED
libcurl4-openssl-dev (= 7.18.0-1em1): FAILED
curl (= 7.18.0-1em1) depends on libcurl3 (>= 7.16.2-1) {libcurl3 (=
7.18.0-1em1)}
libcurl3 (= 7.18.0-1em1) depends on libidn11 (>= 0.5.18) {NOT
AVAILABLE}
libcurl3 (= 7.18.0-1em1) depends on libidn11 (>= 0.5.18) {NOT
AVAILABLE}
libcurl3-gnutls (= 7.18.0-1em1) depends on libidn11 (>= 0.5.18) {NOT
AVAILABLE}
libcurl4-gnutls-dev (= 7.18.0-1em1) depends on libidn11-dev {NOT
AVAILABLE}
libcurl4-openssl-dev (= 7.18.0-1em1) depends on libidn11-dev {NOT
AVAILABLE}
Mon May 5 13:17:04 BST 2008
curl (= 7.18.0-1em1): FAILED
libcurl3 (= 7.18.0-1em1): FAILED
libcurl4-gnutls-dev (= 7.18.0-1em1): FAILED
libcurl4-openssl-dev (= 7.18.0-1em1): FAILED
curl (= 7.18.0-1em1) depends on libcurl3 (>= 7.16.2-1) {libcurl3 (=
7.18.0-1em1)}
libcurl3 (= 7.18.0-1em1) depends on libssh2-1 {NOT AVAILABLE}
libcurl3 (= 7.18.0-1em1) depends on libssh2-1 {NOT AVAILABLE}
libcurl4-gnutls-dev (= 7.18.0-1em1) depends on libldap2-dev {NOT
AVAILABLE}
libcurl4-openssl-dev (= 7.18.0-1em1) depends on libssh2-1-dev {NOT
AVAILABLE}
Mon May 5 13:27:14 BST 2008
If these errors have been resolved, delete the
'/opt/emdebian/trunk/c/curl/trunk/emrecent_error.log' file.
Checking bug status
No open cross-building bugs for curl
curl is waiting for a dependency - see above.
-- 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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#480712: buildd.emdebian.org: e2fsprogs fails to cross build, unable to update package
Package: general Severity: normal User: [EMAIL PROTECTED] $ emsource --status e2fsprogs Checking the apt-cross cache is up to date for arm. W: Unable to locate package libuuid1-udeb W: Unable to locate package libblkid1-udeb W: Unable to locate package e2fsprogs-udeb Checking status of e2fsprogs in /opt/emdebian/trunk/e/e2fsprogs/trunk/ 4 emdebian patch files 0 debian patch files Checking emdebuild status in /opt/emdebian/trunk/e/e2fsprogs/trunk/ build log: e2fsprogs (1.40.8) FAILED to cross build for arm. /opt/emdebian/trunk/e/e2fsprogs/trunk/e2fsprogs_1.40.8-2em1_arm.build Checking for error logs in /opt/emdebian/trunk/e/e2fsprogs/trunk/ Checking bug status No open cross-building bugs for e2fsprogs e2fsprogs FAILED to build. $ tail -20 /opt/emdebian/trunk/e/e2fsprogs/trunk/e2fsprogs_1.40.8-2em1_arm.build CC /opt/emdebian/trunk/e/e2fsprogs/trunk/e2fsprogs-1.40.8/e2fsck/profile.c CC prof_err.c LD e2fsck ../lib/libblkid.so: undefined reference to `dm_log_init' ../lib/libblkid.so: undefined reference to `dm_task_run' ../lib/libblkid.so: undefined reference to `dm_task_create' ../lib/libblkid.so: undefined reference to `dm_task_get_deps' ../lib/libblkid.so: undefined reference to `dm_task_destroy' ../lib/libblkid.so: undefined reference to `dm_task_get_names' ../lib/libblkid.so: undefined reference to `dm_task_set_name' ../lib/libblkid.so: undefined reference to `dm_task_get_info' collect2: ld returned 1 exit status make[3]: *** [e2fsck] Error 1 make[3]: Leaving directory `/opt/emdebian/trunk/e/e2fsprogs/trunk/e2fsprogs-1.40.8/debian/BUILD-STD/e2fsck' make[2]: *** [all-progs-recursive] Error 1 make[2]: Leaving directory `/opt/emdebian/trunk/e/e2fsprogs/trunk/e2fsprogs-1.40.8/debian/BUILD-STD' make[1]: *** [all] Error 2 make[1]: Leaving directory `/opt/emdebian/trunk/e/e2fsprogs/trunk/e2fsprogs-1.40.8/debian/BUILD-STD' make: *** [debian/stampdir/build-std-stamp] Error 2 dpkg-buildpackage: failure: debian/rules build gave error exit status 2 Cross build dependency information: -- $ cat /opt/emdebian/trunk/e/e2fsprogs/trunk/e2fsprogs-1.40.8/debian/xcontrol | grep Build-Depends Build-Depends: dietlibc-dev [alpha amd64 arm hppa i386 ia64 mips mipsel powerpc ppc64 s390 sparc], libsepol1-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], libdevmapper-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], libselinux1-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64] Build-Depends-Tools: texi2html (>= 1.76), gettext, texinfo, dc, pkg-config, debhelper (>= 4) $ dpkg -l dietlibc-dev-arm-cross libsepol1-dev-arm-cross libdevmapper-dev-arm-cross libselinux1-dev-arm-cross Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-=-=-== ii dietlibc-dev-arm-cross0.31-1dietlibc - a libc optimized for small size (for cross-compiling) ii libdevmapper-dev-arm-cross2:1.02.24-4 The Linux Kernel Device Mapper header files (for cross-compiling) ii libselinux1-dev-arm-cross 2.0.59-1 SELinux development headers (for cross-compiling) ii libsepol1-dev-arm-cross 2.0.25-1 Security Enhanced Linux policy library and development files (for cross-co -- 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#480715: buildd.emdebian.org: New version of 'file' fails to cross build, unable to update package.
Package: general Severity: normal $ emsource --status file Checking the apt-cross cache is up to date for arm. Checking status of file in /opt/emdebian/trunk/f/file/trunk/ 4 emdebian patch files 0 debian patch files Checking emdebuild status in /opt/emdebian/trunk/f/file/trunk/ build log: file (4.24) FAILED to cross build for arm. /opt/emdebian/trunk/f/file/trunk/file_4.24-2em1_arm.build Checking empdebuild status file may be out of date. Checking for error logs in /opt/emdebian/trunk/f/file/trunk/ Checking bug status No open cross-building bugs for file file FAILED to build. /bin/sh ../libtool --tag=CC --mode=link arm-linux-gnu-gcc -DHOWMANY=0x18000 -Wall -g -O2 -no-undefined -version-info 1:0:0 -o libmagic.la -rpath /usr/lib magic.lo apprentice.lo softmagic.lo ascmagic.lo compress.lo is_tar.lo readelf.lo print.lo fsmagic.lo funcs.lo apptype.lo -lz gcc -shared .libs/magic.o .libs/apprentice.o .libs/softmagic.o .libs/ascmagic.o .libs/compress.o .libs/is_tar.o .libs/readelf.o .libs/print.o .libs/fsmagic.o .libs/funcs.o .libs/apptype.o -lz -Wl,-soname -Wl,libmagic.so.1 -o .libs/libmagic.so.1.0.0 /usr/bin/ld: .libs/magic.o: Relocations in generic ELF (EM: 40) /usr/bin/ld: .libs/magic.o: Relocations in generic ELF (EM: 40) /usr/bin/ld: .libs/magic.o: Relocations in generic ELF (EM: 40) /usr/bin/ld: .libs/magic.o: Relocations in generic ELF (EM: 40) /usr/bin/ld: .libs/magic.o: Relocations in generic ELF (EM: 40) /usr/bin/ld: .libs/magic.o: Relocations in generic ELF (EM: 40) .libs/magic.o: could not read symbols: File in wrong format collect2: ld returned 1 exit status make[3]: *** [libmagic.la] Error 1 make[3]: Leaving directory `/opt/emdebian/trunk/f/file/trunk/file-4.24/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/opt/emdebian/trunk/f/file/trunk/file-4.24' make[1]: *** [all] Error 2 make[1]: Leaving directory `/opt/emdebian/trunk/f/file/trunk/file-4.24' make: *** [build-stamp] Error 2 dpkg-buildpackage: failure: debian/rules build gave error exit status 2 Recording that the package failed to build. This is down to the libtool handling in the package - the libtool script modified by calling ./configure is removed and replaced by a basic one that is unable to handle cross building. Allowing the upstream libtool to be updated by the configure script causes a different build error: arm-linux-gnu-ranlib .libs/libmagic.a creating libmagic.la (cd .libs && rm -f libmagic.la && ln -s ../libmagic.la libmagic.la) arm-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -DMAGIC='"/etc/magic:/usr/share/file/magic"' -DHOWMANY=0x18000 -Wall -g -O2 -MT file.o -MD -MP -MF .deps/file.Tpo -c -o file.o file.c mv -f .deps/file.Tpo .deps/file.Po /bin/sh ../libtool --tag=CC --mode=link arm-linux-gnu-gcc -DHOWMANY=0x18000 -Wall -g -O2 -o file file.o libmagic.la arm-linux-gnu-gcc -DHOWMANY=0x18000 -Wall -g -O2 -o file file.o ./.libs/libmagic.a -lz make[3]: Leaving directory `/opt/emdebian/trunk/f/file/trunk/file-4.24/src' Making all in magic make[3]: Entering directory `/opt/emdebian/trunk/f/file/trunk/file-4.24/magic' make[3]: *** No rule to make target `file', needed by `magic.mgc'. Stop. make[3]: Leaving directory `/opt/emdebian/trunk/f/file/trunk/file-4.24/magic' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/opt/emdebian/trunk/f/file/trunk/file-4.24' make[1]: *** [all] Error 2 make[1]: Leaving directory `/opt/emdebian/trunk/f/file/trunk/file-4.24' make: *** [build-stamp] Error 2 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#480716: buildd.emdebian.org: New version of findutils fails to cross build, prevents update in Emdebian
Package: general Severity: normal User: [EMAIL PROTECTED] 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. :-( A similar problem to #480706 - looks like a new cache value is needed but I haven't been able to identify it. $ emsource --status findutils Checking the apt-cross cache is up to date for arm. Checking status of findutils in /opt/emdebian/trunk/f/findutils/trunk/ 6 emdebian patch files 0 debian patch files Checking emdebuild status in /opt/emdebian/trunk/f/findutils/trunk/ build log: findutils (4.4.0) FAILED to cross build for arm. /opt/emdebian/trunk/f/findutils/trunk/findutils_4.4.0-2em1_arm.build Checking empdebuild status findutils may be out of date. Checking for error logs in /opt/emdebian/trunk/f/findutils/trunk/ Checking bug status No open cross-building bugs for findutils findutils FAILED to build. make[5]: Entering directory `/opt/emdebian/trunk/f/findutils/trunk/findutils-4.4.0/gnulib/lib' depbase=`echo areadlink-with-size.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ arm-linux-gnu-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../intl -Wall -g -O2 -MT areadlink-with-size.o -MD -MP -MF $depbase.Tpo -c -o areadlink-with-size.o areadlink-with-size.c &&\ mv -f $depbase.Tpo $depbase.Po In file included from ./stdio.h:31, from areadlink-with-size.c:25: /usr/arm-linux-gnu/include/stdio.h:718: error: expected declaration specifiers or ‘...’ before ‘(’ token /usr/arm-linux-gnu/include/stdio.h:718: error: conflicting types for ‘rpl_fseeko’ ./stdio.h:275: error: previous declaration of ‘rpl_fseeko’ was here make[5]: *** [areadlink-with-size.o] Error 1 make[5]: Leaving directory `/opt/emdebian/trunk/f/findutils/trunk/findutils-4.4.0/gnulib/lib' make[4]: *** [all] Error 2 make[4]: Leaving directory `/opt/emdebian/trunk/f/findutils/trunk/findutils-4.4.0/gnulib/lib' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/opt/emdebian/trunk/f/findutils/trunk/findutils-4.4.0/gnulib' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/opt/emdebian/trunk/f/findutils/trunk/findutils-4.4.0' make[1]: *** [all] Error 2 make[1]: Leaving directory `/opt/emdebian/trunk/f/findutils/trunk/findutils-4.4.0' make: *** [build-stamp] Error 2 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#480717: buildd.emdebian.org: [RM] {arm} (unstable) gcc-4.2 not needed in Emdebian anymore?
Package: general Severity: normal User: [EMAIL PROTECTED] 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. :-( gcc-4.2 no longer builds libgcc1 in Debian and as this package was the primary reason for building gcc at all in Emdebian and libgcc1 is finally available through a reverse cross of gcc-4.3, it may be time to remove gcc-4.2 from Emdebian. -- 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#480718: buildd.emdebian.org: Unable to update gnome-vfs, new version fails to cross build
Package: general Severity: normal User: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#480722: buildd.emdebian.org: gtk+2.0 fails to update, udeb fails to cross build
Package: general Severity: normal User: [EMAIL PROTECTED] 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. :-( This problem appears to be restricted to the gtk+2.0 udeb. $ emsource --status gtk+2.0 Checking the apt-cross cache is up to date for arm. W: Unable to locate package libgtk-directfb-2.0-0-udeb Checking status of gtk+2.0 in /opt/emdebian/trunk/g/gtk+2.0/trunk/ 28 emdebian patch files 0 debian patch files Checking emdebuild status in /opt/emdebian/trunk/g/gtk+2.0/trunk/ build log: gtk+2.0 (2.12.9) FAILED to cross build for arm. /opt/emdebian/trunk/g/gtk+2.0/trunk/gtk+2.0_2.12.9-3em1_arm.build In file included from /opt/emdebian/trunk/g/gtk+2.0/trunk/gtk+2.0-2.12.9/gdk/directfb/gdkdrawable-directfb.c:49: /usr/lib/libcairo-directfb/include/cairo/cairo-directfb.h:54:3: error: #error Cairo was not compiled with support for the directfb backend /opt/emdebian/trunk/g/gtk+2.0/trunk/gtk+2.0-2.12.9/gdk/directfb/gdkdrawable-directfb.c: In function ‘gdk_directfb_ref_cairo_surface’: /opt/emdebian/trunk/g/gtk+2.0/trunk/gtk+2.0-2.12.9/gdk/directfb/gdkdrawable-directfb.c:1044: warning: implicit declaration of function ‘cairo_directfb_surface_create’ /opt/emdebian/trunk/g/gtk+2.0/trunk/gtk+2.0-2.12.9/gdk/directfb/gdkdrawable-directfb.c:1044: warning: assignment makes pointer from integer without a cast make[5]: *** [gdkdrawable-directfb.lo] Error 1 make[5]: Leaving directory `/opt/emdebian/trunk/g/gtk+2.0/trunk/gtk+2.0-2.12.9/debian/build/directfb/gdk/directfb' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/opt/emdebian/trunk/g/gtk+2.0/trunk/gtk+2.0-2.12.9/debian/build/directfb/gdk' make[3]: *** [all] Error 2 make[3]: Leaving directory `/opt/emdebian/trunk/g/gtk+2.0/trunk/gtk+2.0-2.12.9/debian/build/directfb/gdk' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/opt/emdebian/trunk/g/gtk+2.0/trunk/gtk+2.0-2.12.9/debian/build/directfb' make[1]: *** [all] Error 2 make[1]: Leaving directory `/opt/emdebian/trunk/g/gtk+2.0/trunk/gtk+2.0-2.12.9/debian/build/directfb' make: *** [debian/stampdir/build-stamp-directfb] Error 2 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#480729: buildd.emdebian.org: ncurses cannot be updated, new version fails to cross build
Package: general Severity: normal $ emsource --status ncurses Checking the apt-cross cache is up to date for arm. W: Unable to locate package lib64ncurses5 W: Unable to locate package lib64ncurses5-dev W: Unable to locate package lib32ncurses5 W: Unable to locate package lib32ncurses5-dev W: Unable to locate package lib32ncursesw5 W: Unable to locate package lib32ncursesw5-dev Checking status of ncurses in /opt/emdebian/trunk/n/ncurses/trunk/ 3 emdebian patch files 0 debian patch files Checking emdebuild status in /opt/emdebian/trunk/n/ncurses/trunk/ build log: ncurses (5.6+20080503) FAILED to cross build for arm. /opt/emdebian/trunk/n/ncurses/trunk/ncurses_5.6+20080503-1em1_arm.build Checking for error logs in /opt/emdebian/trunk/n/ncurses/trunk/ Checking bug status No open cross-building bugs for ncurses ncurses FAILED to build. $ tail /opt/emdebian/trunk/n/ncurses/trunk/ncurses_5.6+20080503-1em1_arm.build gcc -o make_hash -DHAVE_CONFIG_H -I../ncurses -I/opt/emdebian/trunk/n/ncurses/trunk/ncurses-5.6+20080503/ncurses -I/opt/emdebian/trunk/n/ncurses/trunk/ncurses-5.6+20080503/ncurses/../include -I../include -DMAIN_PROGRAM /opt/emdebian/trunk/n/ncurses/trunk/ncurses-5.6+20080503/ncurses/tinfo/comp_hash.c In file included from /opt/emdebian/trunk/n/ncurses/trunk/ncurses-5.6+20080503/ncurses/tinfo/comp_hash.c:42: /opt/emdebian/trunk/n/ncurses/trunk/ncurses-5.6+20080503/ncurses/curses.priv.h:1406: warning: parameter names (without types) in function declaration /opt/emdebian/trunk/n/ncurses/trunk/ncurses-5.6+20080503/ncurses/curses.priv.h:1407: error: expected '=', ',', ';', 'asm' or '__attribute__' before '_nc_to_widechar' make[2]: *** [make_hash] Error 1 make[2]: Leaving directory `/opt/emdebian/trunk/n/ncurses/trunk/ncurses-5.6+20080503/obj-wide/ncurses' make[1]: *** [all] Error 2 make[1]: Leaving directory `/opt/emdebian/trunk/n/ncurses/trunk/ncurses-5.6+20080503/obj-wide' make: *** [build-wide] Error 2 dpkg-buildpackage: failure: debian/rules build gave error exit status 2 This may seem an obvious error - using gcc - but even calling arm-linux-gnu-gcc in this directory causes a failure and I've been unable to convince ncurses to use arm-linux-gnu-gcc in this directory, despite setting --host and --build as normal. Even make CC=arm-linux-gnu-gcc -C $dir is ignored. Filing the bug as a placeholder for buildd.emdebian.org so that we have an online record of why ncurses is old in Emdebian. -- 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#480730: buildd.emdebian.org: Unable to update ntp - new version fails to cross build
Package: general Severity: normal 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 ntp Checking the apt-cross cache is up to date for arm. Checking status of ntp in /opt/emdebian/trunk/n/ntp/trunk/ 11 emdebian patch files 0 debian patch files Checking emdebuild status in /opt/emdebian/trunk/n/ntp/trunk/ ntp may be out of date. Checking for error logs in /opt/emdebian/trunk/n/ntp/trunk/ Checking bug status No open cross-building bugs for ntp In file included from /usr/include/string.h:423, from /usr/include/memory.h:30, from ../include/ntp_string.h:13, from authkeys.c:15: /usr/include/bits/string2.h:972: warning: C99 inline functions are not supported; using GNU89 /usr/include/bits/string2.h:983: warning: C99 inline functions are not supported; using GNU89 /usr/include/bits/string2.h:996: warning: C99 inline functions are not supported; using GNU89 /usr/include/bits/string2.h:1048: warning: C99 inline functions are not supported; using GNU89 /usr/include/bits/string2.h:1060: warning: C99 inline functions are not supported; using GNU89 /usr/include/bits/string2.h:1072: warning: C99 inline functions are not supported; using GNU89 /usr/include/bits/string2.h:1125: warning: C99 inline functions are not supported; using GNU89 /usr/include/bits/string2.h:1137: warning: C99 inline functions are not supported; using GNU89 /usr/include/bits/string2.h:1176: warning: C99 inline functions are not supported; using GNU89 /usr/include/bits/string2.h:1226: warning: C99 inline functions are not supported; using GNU89 /usr/include/bits/string2.h:1236: warning: C99 inline functions are not supported; using GNU89 /usr/include/bits/string2.h:1264: warning: C99 inline functions are not supported; using GNU89 authkeys.c: In function ‘authencrypt’: authkeys.c:445: error: invalid 'asm': invalid operand for code 'w' authkeys.c:445: error: invalid 'asm': invalid operand for code 'w' make[3]: *** [authkeys.o] Error 1 make[3]: Leaving directory `/opt/emdebian/trunk/n/ntp/trunk/ntp-4.2.4p4+dfsg/libntp' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/opt/emdebian/trunk/n/ntp/trunk/ntp-4.2.4p4+dfsg' make[1]: *** [all] Error 2 make[1]: Leaving directory `/opt/emdebian/trunk/n/ntp/trunk/ntp-4.2.4p4+dfsg' make: *** [build-stamp] Error 2 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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: [EMAIL PROTECTED] > > 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/ signature.asc Description: This is a digitally signed message part
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/2008/05/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 buil
Re: divergence from upstream as a bug
On Sat, 2008-05-17 at 23:08 +0200, Pierre Habouzit wrote: > On Sat, May 17, 2008 at 09:01:08PM +, Joey Hess wrote: > > What if we just decide that changes made to upstream sources[1] qualify > > as a bug? > > WTF ? What's the point of free software if we invent rules for not > modifying them ? ? AFAICT the point is that we feed those changes back to upstream instead of hoarding them in the current layers of Debian changes. I think it's a good idea. > And well, we're in a bad posture then, because glibc > without patches can't work. And what is it that makes this not a bug in upstream glibc? I know it is a complex build but that only makes it more important that the Debian changes are clear and unambiguous. glibc and gcc are the most complex packages that I regularly build (ok, crossbuild) and I dread seeing the email from incoming that a new version needs to be prepared for Emdebian because it nearly always fails first time, despite working last time. > Striving for minimal differences is good, > but deciding a change is a bug ? please… I think it is right that a change is a bug - after all, Debian builds on a range of architectures that upstream often do not have available. When upstream does not build on these architectures, that is a portability bug upstream. It would catch out someone upstream if they were to try and build the package on that arch so why not post the fix to the upstream bug tracker? Call it a feature enhancement if you like but it still ends up in a bug tracker of one kind or another so might as well call it a bug IMHO. -- 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: divergence from upstream as a bug
On Sat, 2008-05-17 at 23:22 +0200, Pierre Habouzit wrote: > Okay, still I dislike the idea a lot. the BTS is unusable past 100 > bugs. ? there are ways of managing lots and lots of bugs via custom scripts and the SOAP interface or usertags or the filters at the end of each bug index page. > For some packages this will add 100 more, that will never go away. 100 patches that upstream never accept? That's revisting the "extensive patching" thread from earlier. There is no general metric for determining when a diversion has become a de facto fork but if the "relationship" with upstream is in such a state that hundreds of patches for upstream go ignored ad infinitum, it's not a healthy relationship IMHO. > And upstreams wont want to use yetanother bug tracker, they want to use > theirs (especially the ones using RT or BZ that ensure this way never to > recieve too many patches… *cough*). Did you miss the bit about CC'ing the upstream bug tracker or otherwise wrapping the call such that the upstream bug tracker is notified at the same time? The Debian bug is a means of tracking those forwarded bugs and Debian has been tagging bugs for the purposes of tracking forwarded bugs for a long time. -- 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: Tracking divergence from upstream as a bug
On Sat, 2008-05-17 at 23:01 -0400, Joey Hess wrote: > Ben Finney wrote: > > Care to discuss what tags you plan to use, so an attempt at consensus > > can be made on naming the tags for this purpose? > > I'm using a "divergence" usertag, with users [EMAIL PROTECTED] and > [EMAIL PROTECTED] (so it'll show up on my bugs page, and the > package's bug page -- not ideal). I've done aalib so far. Doing this retrospectively does make things look more than a little odd in the BTS. Unarchiving, reopening, retitling, change severity and then tagging (#97695). I can see the reasoning (keeping the patch with any original bug report) but reopening a bug 7 years after it was closed just to indicate that upstream still hasn't included the fix is more than a little strange to behold. I wonder if such divergence issues should merely start with a new bug and *reference* the old, archived, bug report. I need to implement divergence tags for GPE and soci - I can't decide whether to start new bugs or reopen ones that have already been closed by an upload. Certainly in the future I plan to treat my own bugs more like NMUs and if the fix involves a patch that I have devised myself, send the patch to the BTS prior to the upload. However, from a bug submitter point of view, I don't think I want to see the bug report kept open (tagged divergence) after it has actually been closed by a Debian-specific patch. As upstream it might make a fair bit of sense but as a user / bug submitter, it will just look odd. Also, as upstream, I might not want to trawl through hundreds of comments (possibly including references to other packages due to bugs being reassigned) to get to a patch and possibly find that the patch in the BTS at comment 112 differs from the final patch actually applied before the bug was closed in comment 234. I'm wondering, therefore, if divergence bugs should be NEW bugs that include only the final patch and a summary along with a reference to the old discussion so that the old bug can stay archived and closed and the new bug is updated via bts-link. A user reporting a bug in foo should not still be wondering why the bug is open after the fix has been applied. To me, divergence tags are a maintainer issue, not a user issue and as such, could deserve being filed by the maintainer as a separate issue. To all intents and purposes, the bug actually reported by the submitter was fixed long, long ago - I can't see that it makes a whole lot of sense (to the bug submitter) to reopen it. If I got a message saying that a grave bug that I had reported before Etch was now suddenly reopened in the release phase for Lenny, as a bug submitter I might be a little concerned. -- 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: divergence from upstream as a bug
On Sun, 2008-05-18 at 09:40 +0200, Goswin von Brederlow wrote: > Joey Hess <[EMAIL PROTECTED]> writes: > > > What if we just decide that changes made to upstream sources[1] qualify > > as a bug? A change might be a bug in upstream, or in the debianisation, > > or in Debian for requiring the change. But just call it a bug. > > Everything else follows from that quite naturally.. > > > > The bug can be tracked, with a patch, in our BTS. The bug can be > > forwarded upstream as the patch is sent upstream. A tag "divergence" can > > be used to query for all such bugs, or to sort such bugs out of the way. > > I think a frequent workflow goes like this: > > 1) user reports bug [open] > 2) patch is added[open, Tags: patch] > 3) bug gets closed [closed] > > where 2 and 3 are often just a new version being uploaded. If I > understand you right you would add the following: > > 2b) patch is send upstream [open, Tags: patch, send-upstream] > 3b) source diverges[closed, Tags: divergence, send-upstream] > 4) upstream accepts patch [closed, Tags: divergence, fixed-upstream] > 5) new upstream release[closed] s/send-upstream/upstream/ - we already have a fixed-upstream. 1 - User reports bug with a patch against upstream code [open, patch] 2 - maintainer forwards the patch upstream [confirmed, patch, upstream, forwarded] 3 - maintainer uploads divergent code with Fixed: #1234 [fixed, divergence, forwarded] 4 - bts-link tags the report as upstream work on the issue [fixed, divergence, forwarded, fixed-upstream], [fixed, divergence, forwarded, pending] etc. 5 - maintainer closes bug in the relevant upstream release [closed] ... time passes ... [archived] 'Tags: + upstream' would mean that the issue is an upstream issue but without a Debian-specific patch (or fix), yet. 'Tags: + divergence' would mean that the upstream issue has been fixed in Debian with a patch in advance of an upstream fix. Uploading a divergent package with Fixed: would mean removing the patch tag and changing 'confirmed' into 'fixed' (or adding fixed if confirmed not set). As divergence implies upstream, replace 'upstream' with 'divergence'. In effect, divergence would be a sub-case of upstream as Fixed would be a sub-case of Closed. (Native packages simply use Closed: directly, as now.) We could also specify that Fixed: cannot be used unless 'forwarded' is already set - debchange could check for that. > It would be nice if the changelog could indicate wether a bug is > closed by divergence or by upstream. A new statements should be added > for the changelog to make divergence easy to handle and document them > machine readable in the source: > > * Adding Debian patch foo (Diverges: #1234) > * Patch foo added upstream (Closes: #1234) Assuming both refer to the same bug report, I personally prefer the Fixes: #1234 approach: foo (0.1.6-1) unstable; urgency=low * New upstream release * Remove patch 'patch-file-name' included upstream (Closes: #1234) -- Neil Williams <[EMAIL PROTECTED]> Fri, 16 May 2008 21:29:20 +0100 foo (0.1.5-2) unstable; urgency=low * Add 'patch-file-name' $reason (Fixes: #1234) > Maybe divergence could mark a bug as fixed instead of closed. For > people that want to use divergence like you propose a bug isn't closed > untill it is accepted upstream. I like that idea - the bug submitter gets a notification that the upload has fixed the bug but we continue to track the issue until the patch disappears. As far as the bug submitter is concerned, Fixed == end of the problem. That may require a new column on the DDPO and a new row in the PTS so that bugs that are Fixed but not Closed are shown separately. -- 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: Should dpkg-source -x list patches (Re: How to handle Debian patches)
On Sun, 2008-05-18 at 09:51 +0200, Andreas Tille wrote: > On Fri, 16 May 2008, Raphael Hertzog wrote: > > > I totally agree that we need to make our changes more visible. In the > > openssl case, the patch in question is inside the .diff.gz and you don't > > notice it in the unpacked source package. I tend to give a look to what's > > in debian/patches/ when I rebuild a package but not to what's in .diff.gz > > only. > > If I inspect an unknown package I always do > > zgrep "^+++ " *.diff.gz | grep -v "/debian/" > > and I wonder whether I should file a bug report against "dpkg-source -x" > to do this by default. lintian already has that level of check but it does have problems with generated files, see #471263: "Files that are changed as the result of a patch to a file that is processed during the build should be ignored - e.g. patching configure.in|ac should mean that changes in ./configure must be ignored." Otherwise, as soon as autotools updates or an m4 macro gets updated in some -dev package, the "patch" for ./configure will break for no good reason and we get a FTBFS RC bug. Detecting which files are changed as a by-product of a patch isn't always particularly obvious. Incidentally, you can collapse the zgrep into lsdiff -z: $ lsdiff -z *.diff.gz | grep -v 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: Tracking divergence from upstream as a bug
On Sun, 2008-05-18 at 18:43 +1000, Ben Finney wrote: > Neil Williams <[EMAIL PROTECTED]> writes: > > > However, from a bug submitter point of view, I don't think I want to > > see the bug report kept open (tagged divergence) after it has > > actually been closed by a Debian-specific patch. As upstream it > > might make a fair bit of sense but as a user / bug submitter, it > > will just look odd. > > Would your opinion be different if the bug was "fixed" but not closed > nor archived, until the "divergence" tag is gone? I think that would be fine - as long as the bug is clearly "Fixed" and the relevant Debian www pages are updated. > > A user reporting a bug in foo should not still be wondering why the > > bug is open after the fix has been applied. > > Isn't that a matter easily resolved by presenting the bug information > appropriately in the interface? Yes - supported by the use of (Fixed: #1234) in debian/changelog, .changes etc. and a revised interface for PTS and DDPO to discriminate between Fixed and Closed bugs. -- 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: divergence from upstream as a bug
On Sun, 2008-05-18 at 15:30 +0200, Goswin von Brederlow wrote: > Neil Williams <[EMAIL PROTECTED]> writes: > > > > 1 - User reports bug with a patch against upstream code > > [open, patch] > > 2 - maintainer forwards the patch upstream > > [confirmed, patch, upstream, forwarded] > > 3 - maintainer uploads divergent code with Fixed: #1234 > > [fixed, divergence, forwarded] > > 4 - bts-link tags the report as upstream work on the issue > >  [fixed, divergence, forwarded, fixed-upstream], > > [fixed, divergence, forwarded, pending] etc. > > 5 - maintainer closes bug in the relevant upstream release > > [closed] > > ... time passes ... > > [archived] > > > > 'Tags: + upstream' would mean that the issue is an upstream issue but > > without a Debian-specific patch (or fix), yet. > > 'Tags: + divergence' would mean that the upstream issue has been fixed > > in Debian with a patch in advance of an upstream fix. > > 'fixed + upstream' would mean divergence. No need for a new tag actually. Hmm, that's interesting. Good idea. This would mean a relatively simple change to implement the entire proposal: [EMAIL PROTECTED] | (Fixes: #nnn) marks the bug as fixed by a patch added by Debian and awaiting a new release upstream to be finally closed. nnn-fixed is ignored if the upstream tag is not already set. Bugs can be fixed in the changelog of an upload using (Fixes: #1234) in a similar manner to (Closes: #1234). The principle usage of "fixed" is to denote points at which Debian diverges from upstream. Filenames of patch files must be clearly identified when using (Fixes: #1234) in the changelog. Possibly add: "Fixed bugs must also be tagged Forwarded as well as just upstream." or alternatively, "Forwarded is equivalent to upstream and one or both tags must be used for Fixed to work." Probably also add: "Fixed bugs must be tagged "patch" for Fixed to work." Also add: "The maintainer may choose not to post the patch to the BTS when using Fixes: as long as the upstream bug tracker makes all patches publicly visible without requiring passwords or authentication." Lintian could check that the specified patch actually exists and use that to output a warning if the patch was removed (due to the changes already being present in the upstream). The other checks implemented in debchange and in bugs.debian.org. The requirement for a filename in debian/patches is so that it is easier to track the point at which Fixes: needs to become Closes:. I suppose it might be possible to parse the output of lsdiff -z *.diff.gz | grep -v debian to find the filename of the files being patched and put those in the Fixes: changelog entry but I would prefer the use of debian/patches as one source file may contain more than one issue to be Fixed - e.g. a FTBFS bug in the #include lines and a seg fault in a function declaration in src/foo.c. YMMV. Is this acceptable as a possible policy proposal? > > Uploading a divergent package with Fixed: would mean removing the patch > > tag and changing 'confirmed' into 'fixed' (or adding fixed if confirmed > > not set). As divergence implies upstream, replace 'upstream' with > > 'divergence'. > > Why remove the patch tag? Well, ok, maybe it is better so you can get > a list of pending patches in your package without having already > applied patches show up. Well that was just the simplest way of doing things but if the PTS can be adapted to *ignore* patches where the bug is "fixed" (or at least split those numbers into a different section of the ToDo list in the PTS) then that would solve the problem by allowing everyone to clearly identify which BTS patches are in the package and which are not. Leaving the patch tag in place could be useful, as long as the relevant web pages and tools can discriminate between patches in open bugs and patches in Fixed bugs. > > In effect, divergence would be a sub-case of upstream as Fixed would be > > a sub-case of Closed. > > > > (Native packages simply use Closed: directly, as now.) > > > > We could also specify that Fixed: cannot be used unless 'forwarded' is > > already set - debchange could check for that. > > So what you're saying is that we only need a minimal change: > > - (Fixes: #1234) in changelog when adding a patch > - The fixed state from NMU uploads is reused for divergent sources. > [- debchange does some extra sanity checking] > > And we use "fixed + upstream" as source being
Re: Which problem are we trying to solve? (Was: divergence from upstream as a bug)
o help me track which patches that I have applied in Debian are actually diverging from upstream and which have been applied. To find that out, I need to build the package and see the failure messages from patch. Not ideal. This way, I can indicate to the bug submitter that the bug is fixed in Debian (using a divergence) by including (Fixes: #1234) in a new Debian revision. Until the bug is fixed in an upstream release, I still see that the package has bugs that are Fixed but not Closed. bts-link takes care of updating the tags on the Fixed bugs (because they are also forwarded) so that when the upstream release is made, I know which patches are included upstream. I can then remove those patches, build the new upstream release, implement any new divergences if needed and upload with (Closes: #1234). -- 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: Which problem are we trying to solve? (Was: divergence from upstream as a bug)
On Sun, 2008-05-18 at 18:22 +0200, Lucas Nussbaum wrote: > > > The problem I am interested in solving is: > > > It is currently difficult for people not involved in Debian > > > development (upstream, other distros, users) to know which patches we > > > applied, the reason for the patch, and whether they should be > > > interested in that patch or not. > > > > In that case, the fault lies in Debian for not using Forwarded properly. > > IMHO we should be going out of our way to communicate with upstream > > using the systems preferred BY upstream, not trying to devise a new one. > > > > I know it's a PITA using bugzilla and a gazillion different logins but > > that is part of the workload. > > I think that upstreams would like two different things: > - that distros forward patches to their BTS > - that distros provide an automated, simple way to see what they patched ok - so two problems, not one. > That sounds logical to have both: > - they know that distro devs are not perfect and sometimes don't forward > simple patches > - they want to know which patches are actually used (and widely tested), > because that make them better candidates for integration upstream > But maybe I'm just misunderstanding upstreams' needs? There's no accounting for the variety in upstream teams - I don't know many that want the second option but I can see that some will probably want it that way, if only because of an MIA DD. > > > I thought that the problem of tracking changes for Debian developers was > > > already solved by using a VCS and advertising it thought Vcs-*? > > > > No, it isn't because Debian developers still need to track where Debian > > patches have diverged from upstream due to delays in upstream > > development. Vcs does nothing for that, nothing whatsoever (and I > > consider it a nonsense to include the entire upstream codebase in our > > RCS). > > If we have a Formarded-upstream: field in patches.d.o (pointing to the > upstream bug for a patch), it would be easy to modify bts-link and > automatically monitor those upstream bugs. I still like the two-stage closure option because sometimes we just need to upload a fix before an upstream release can be made and the bug submitter should know that the bug has been fixed using a divergence whilst still waiting for upstream. > Yes. One problem with this discussion is that we are discussing: >What can/can't we do by using, abusing and modifying our current >infrastructure (i.e the BTS)? > Instead of discussing: >What is the real problem that we are trying to solve? What needs >to be done to fix that problem? (what features/requirements are >needed in a candidate solution?) > The discussion is polluted by technical details about BTS things, and > this hides the real issues. OK, so problem 1: Q: How to improve Debian forwarding patches to upstream using upstream bug trackers? A: Leave the burden on the DD to handle multiple logins to multiple bug trackers but make life easier in the BTS so that everyone can read the patch without needing a login. This, IMHO, is met by the Fixed|Closed two stage closure idea. Problem 2: Q: How to help upstream find out from Debian which patches are actually in use. A: provide browsable patch files organised by source package (the upstream source package name if it differs) - this sounds like the patches.d.o idea. I'll stick to Problem 1. :-) I think you're right that there are two distinct problems - although I'm still not convinced that Problem 2 is sufficiently common to require a whole new bug/patch tracker. -- 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: Which problem are we trying to solve? (Was: divergence from upstream as a bug)
from a buggy -dev package. If appropriate, feed > that info into the BTS. Message-Id: <[EMAIL PROTECTED]> > I fear that this will turn into DDs thinking that it's enough to file a > bug in the BTS to consider a bug as "forwarded upstream". While it's > obviously not the case. I'm not sure how that follows but I don't want that either. (I suggested that Fixed would only work if Forwarded was set.) > If my upstream BTS doesn't require login to read the bug, are there > other reasons (beside the "submitter want to be notified when the patch > is applied upstream" one -- see question above) for duplicating the bug > discussion into the BTS? Similar reason to why you added that CC - because when dealing with a variety of inputs, it is helpful to get an overview of the changes across all packages. I'm not sure where you see duplication: > Use tags in the BTS and custom webpages to let others know which bugs we > fixed with these patches. If the upstream tracker isn't public, file the > patches in the BTS too so that everyone can find it. and > Users can choose whichever bug tracker they prefer - the Debian BTS or > the upstream bug tracker for the project concerned. It is up to Debian > to ensure that proper use of Forwarded ensures that the same information > is available via (but not necessarily in) both. i.e. whichever entry > route is chosen, links are available to go to the relevant point where > the information is publicly available (without logins). Whether that > particular point is in the upstream bug tracker or the BTS is > inconsequential. The essential point is that it does exist and it is > linked from both entry points. I'm not sure which bug tracker I was thinking of regarding logins but upstreams that only have private email contact would qualify as not publicly available. ;-) In that case, there would be no duplication. As long as both the BTS and the upstream tracker contain links to the patch itself (no matter where that is located), that's fine with me. If the upstream bug tracker is so broken that it cannot do this, the BTS is the only place to put it. -- 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: Tracking divergence from upstream as a bug
On Sun, 2008-05-18 at 18:51 +0100, Don Armstrong wrote: > On Sun, 18 May 2008, Neil Williams wrote: > > Yes - supported by the use of (Fixed: #1234) in > > debian/changelog, .changes etc. and a revised interface for PTS and DDPO > > to discriminate between Fixed and Closed bugs. > > I could easily handle this by just not archiving bugs tagged > divergence; when it's fixed upstream, you just untag it. > > No need for complicated mucking about with the changelog parsers. Hmmm, ok. Should be straightforward to create QA pages/scripts that can check on bugs that might get missed. Untagging is also something that can be done by anyone so it has the advantage that more people can pick up such errors and fix them. I've already started talking myself into circles (see my reply to Lucas) so I think I'll quit while I'm ahead and go for that solution. :-) -- 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: Which problem are we trying to solve? (Was: divergence from upstream as a bug)
On Sun, 2008-05-18 at 21:40 +0200, Lucas Nussbaum wrote: > (you can skip to the end for a summary of what I think we agree on) > > > The only > > > thing that he would additionaly get is a notification when the change is > > > applied upstream and fixed in Debian by a new upstream version. > > > > Don echoed that sentiment by offering just to not archive bugs tagged > > with 'divergence'. I would agree that the submitter doesn't really need > > to know when Fixed: is replaced by Closes: - it is a maintainer issue > > but one that does need to be publicly visible. > > OK, but then you have to remove the divergence tag when the change is > integrated upstream -- not just close the bug. This would be still be a > manual process, right? I suppose bts-link could be utilised - after all, the bug tagged 'divergence' should also be forwarded so it can be updated from there. However, it might be just as well that it is manual. As I mentioned before, removing a tag can be done by anyone so it's not a big issue. > Users can choose whichever bug tracker they prefer, but DDs should > always report patches that should be reported upstream to the upstream > BTS. It would be nonsense if DDs started reporting patches for upstream > only to the Debian BTS. ok. > OK, I think that we generally agree. Let's summarize again to make sure: > > 1) Encourage maintainers to use patches in debian/patches. Define some > useful pseudo-headers. Definitely. > 2) Build patches.debian.org, fully automated export of Debian patches. Yes. > 3) For patches that need to be sent upstream, a pseudo header in the > patch indicates where the submission of the patch to upstream is > discussed. > -> If upstream has a BTS, the discussion happens on upstream's >BTS, and the pseudo header in the patch points there. > -> If upstream doesn't have a BTS, a bug is created/reused on the Debian >BTS, and the discussion with upstream is Cced with this bug. The >pseudo header in the patch points to that Debian BTS bug. >Additionally, this bug is tagged +divergence to indicate what it's >about. >Also, bugs tagged divergence are not archived. So even after the bug >has been closed in Debian, the bug can continue to be used to discuss >the patch with upstream. > > Sounds good? Yes, it does. It could also be possible to add some automation because as the pseudo-header is in the patch, scripts could check that the list of pseudo-headers with a bugs.d.o URL matches the list of diversion bugs obtained via SOAP. Lintian doesn't currently do SOAP queries of the BTS but a QA script should be relatively easy to create. Maybe bts-link could be drafted in to provide some leverage over pseudo-headers mapping to an upstream bug tracker. Lintian could check that the pseudo-header exists. -- Neil Williams <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Generated files and patch systems
g patches for these tmpl/ files is correct either - a change in gtk-doc-tools could easily break many such patches and I do not consider it "my fault" that those files have been changed, hence no patches. This, to me, is where the "all changes are patches" approach falls down. A patch, IMHO, is a deliberate action - similar to a GnuPG signature on an email. It should require a conscious act to solve an identifiable problem - preferably one with a bug report. Changes that result merely from differences in build environment between upstream and Debian should not even be in the .diff.gz if at all possible - such changes are, IMHO, certainly not deliberate actions by the maintainer. Changes that themselves change independently of the actions of the maintainer cannot be implemented by the maintainer as patches, imho. The "silent" build is available from my repo: dget -x http://www.linux.codehelp.co.uk/packages/pool/main/libg/libgpewidget/libgpewidget_0.116-1.dsc I won't upload to ftp-master just yet - I do need to do some more tests to ensure that other GPE packages build and function correctly so that I don't inadvertently trigger a transition in over 40 packages. ;-) -- 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: Generated files and patch systems
On Sun, 2008-05-25 at 13:19 +0100, Mark Brown wrote: > On Sun, May 25, 2008 at 01:07:56PM +0100, Neil Williams wrote: > > > So I am running the relevant autotools at build time but I still get the > > warning. > > 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? 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? > This is the same idea as patch systems reverting the changes they make > in the clean target. Unfortunately, I can't get it to work either. -- 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: What about use xml for descriptions of packages?
On Sun, 2008-05-25 at 08:46 -0400, Roberto C. Sánchez wrote: > On Sun, May 25, 2008 at 02:40:07PM +0200, Fernando Cerezal wrote: > > Hello, > > I'm thinking about advantages and disadvantages of write the > > description of the packages using XML. > > Personally, I would hate this. I've written too many ant build.xml > scripts to think that writing XML by hand is even a remotely sane thing > to do. I agree - I write a lot of XML and XSL and write various XML backends for various upstream projects. It sounds like a very bad idea to me, especially considering the extra workload required to parse the dpkg data on low resource installations. The extra bloat of the XML tags alone is sufficient reason not to do this, IMHO. I like XML but it isn't the right choice for package descriptions IMHO. Better to work with a simpler format but one that can still be parsed by gettext so that TDebs can read the translation strings from binary .mo files. -- 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: Generated files and patch systems
On Sun, 2008-05-25 at 14:01 +0100, Neil Williams wrote: > On Sun, 2008-05-25 at 13:19 +0100, Mark Brown wrote: > > On Sun, May 25, 2008 at 01:07:56PM +0100, Neil Williams wrote: > > > > > So I am running the relevant autotools at build time but I still get the > > > warning. > > > > 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? Actually, I just converted the package to CDBS and it did TheRightThing(tm) so I'll either stick with that or convert what cdbs does into the existing package. -- 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: What about use xml for descriptions of packages?
On Sun, 2008-05-25 at 15:07 +0200, Fernando Cerezal wrote: > 2008/5/25 Roberto C. Sánchez <[EMAIL PROTECTED]>: > > On Sun, May 25, 2008 at 02:40:07PM +0200, Fernando Cerezal wrote: > Yes, you are right. However, currently the translations of the Debian > website are being done by hand, so there is the same problem and it > works enough fine. What are we talking about here, www.debian.org or apt-cache show? These are two very different issues. > Are interpreted as two difference descriptions. They would be in gettext - unless marked up in such a way as to not include the extra spaces. > A description with lines Is an extra 13 characters per line, per description, per package. 13 x 10 x 20,000 = bloat. > The program foo is used for help you in your task src="http://logo_of_foo.jpg";> Now that really is out of the question - please remember that the packages descriptions go into the dpkg database which is already too big. -- 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: What about use xml for descriptions of packages?
On Sun, 2008-05-25 at 08:29 -0500, Ron Johnson wrote: > > 13 x 10 x 20,000 = bloat. > > It would probably be more like one paragraph per . Still far too much. > > Now that really is out of the question - please remember that the > > packages descriptions go into the dpkg database which is already too > > big. > > What's an extra few MB plus parsing overhead when "everyone" has > 250GB HDDs, multi-core 64-bit CPUs and 2+GB RAM? I am going to assume you are not being serious. Try 64Mb Flash, ARM5 CPU and 64Mb RAM. -- 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: 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 t
Re: Processed: tagging 480716
On Wed, 2008-05-28 at 11:39 +0200, Julien Cristau wrote: > On Tue, May 27, 2008 at 14:18:07 +0100, Neil Williams wrote: > > > If it is just that 'quiet' supports what it does because that is all it > > has needed to support so far, I'm fine with that. It just means I cannot > > prevent those messages coming to -devel. I still need to process the > > bugs. > > > The only mail -devel needs to get about those bugs now is the > 'Processed' mail from the BTS about them being closed or reassigned. > I don't think anyone will complain about that one mail. > You don't need to process them before they're assigned to the relevant > package. The relevant package is a pseudo-package that is pending so I cannot reassign as yet. Sadly, I do need to process these bugs whilst waiting for the pseudo-package to be created. If I've chosen the wrong pseudo-package whilst waiting, I'll reassign but AFAICT, general is the right one at this time. -- 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: Generated changes and patch systems
On Wed, 2008-05-28 at 11:45 +0100, Neil Williams wrote: Ignore the CC for #482716 - the CC should be for #471263 [patch-systems]: please no patch-system-but-direct-changes-in-diff for generated files -- 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: Generated changes and patch systems
On Tue, 2008-05-27 at 18:06 -0700, Russ Allbery wrote: > Neil Williams <[EMAIL PROTECTED]> writes: > > On Sun, 2008-05-25 at 08:40 -0700, Russ Allbery wrote: > > >> 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. > > Uh, it's the same problem. Surely the generalization is obvious? It's not quite the same problem because aclocal.m4 is regenerated in the clean rule itself because changing it causes ./configure --recheck to recreate the (modified) file. So instead of copying it around, it has to be deleted - merely because a patch system is in use. Seems crazy to me. > > 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. > > Right, so delete it in the clean rule. OK. It's a bit like collateral damage - need a patch to configure, patching causes configure --recheck which modifies aclocal.m4 so delete aclocal.m4. Hmmm. I don't like it but I'll do it anyway. > > 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. > > Absolutely not -- you're introducing unexpected changes to the packaging > diff file, Well my point is that the change is entirely expected (because the patch modifies a file that is involved in generating the changes) - the changes are merely a consequence of the patch. It feels wrong to have to add a clean rule for aclocal.m4 as a direct result of patching configure.ac when aclocal.m4 was not a problem before the patch. Anyway, the "problem" of the tmpl/* files is far more resistant. > >>> 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*! > > This is extremely unusual. Are you *sure* that it does an inplace edit of > the files during the build process? $ ls libgpewidget-0.115.orig/doc/tmpl/ -1 colordialog.sgml color-slider.sgml dirbrowser.sgml errorbox.sgml gpeclockface.sgml gpehelp.sgml gpeiconlistitem.sgml gpe-iconlist.sgml gpeiconlistview.sgml gpetimesel.sgml gpewindowlist.sgml gtkdatecombo.sgml gtksimplemenu.sgml infoprint.sgml init.sgml libgpewidget-unused.sgml picturebutton.sgml pixmaps.sgml popup_menu.sgml popup.sgml question.sgml smallbox.sgml spacing.sgml stylus.sgml translabel.sgml tray.sgml windows.sgml From the build log: gtkdoc-mkdb --module=libgpewidget --source-dir=.. --output-format=xml --sgml-mode --output-format=xml --tmpl-dir=tmpl Now running lintian... W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/color-slider.sgml W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/colordialog.sgml W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/colorrenderer.sgml W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/gpeclockface.sgml W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/gpedialog.sgml W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/gpehelp.sgml W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/gtkdatecombo.sgml W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/gtksimplemenu.sgml W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/libgpewidget-unused.sgml W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/link-warning.sgml W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/pixmaps.sgml W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/smallbox.sgml W: libgpewidget source: patch-system-but-direct-changes-in-diff doc/tmpl/spacing.sgml Finished running lintian. 13 out of 27 files modified by gtk-doc. Copy those files back into doc/tmpl/ from the upstream source and they are still modified at the next build. Add a rm -f doc/tmpl/*.sgml to clean:: and the build fails: No rule to make doc/tmp/*.sgml So, yes, --enable-gtkdoc is modifying files included upstream and which are essential to the build process. If I drop --enable-gtkdoc I get different contents in the libgpewidget-doc package. > This is almost never what build > systems do; instead, they generate files from other files using templating > systems. They may ship the results of that operat
