Re: Parallel build results
> I finally got through the test builds of all the source packages in sid for > i386 using dpkg-buildpackage -j3 on a dual core machine. The results as > before are at http://people.debian.org/~schepler/build-logs/bymaint.html . > Some statistics: > [...] BTW, Daniel, it would be nice if you provided a detailed description of the exact build environment you use, i.e., kernel version, libc version, gcc, ... Thanks, Michael pgpkghRLTogCM.pgp Description: PGP signature
Re: Parallel build results
> I finally got through the test builds of all the source packages in sid for > i386 using dpkg-buildpackage -j3 on a dual core machine. The results as > before are at http://people.debian.org/~schepler/build-logs/bymaint.html . > Some statistics: > [...] Wouldn't it have been wise to use lenny (or even etch) instead of sid? Apparently your statistics include all the failures due to "normal" bugs entirely unrelated to the parallel build process. Best, Michael pgpnf9JaJMYby.pgp Description: PGP signature
Re: Bug#416490: acpi-support: IBM Ultrabase X4 DVD/CDOM Undetected On Dock
Hi Henrique, Henrique de Moraes Holschuh wrote: On Tue, 03 Apr 2007, Raphael Hertzog wrote: Debian should be able to handle automatically detecting IDE CDROM's after docking by now, it is 2007 after all! I would like this too. Unfortunately, I have no clue on how to detect that we're plugged into a dock. And it's not even clear that acpi-support Well, since this has "thinkpad" near it, let me make it pretty clear: whatever you guys do, DO NOT hook into thinkpad-acpi/ibm-acpi bay ejection and undocking functionality as it stands on anything that will be shipped by Debian. I have deprecated it for a long time now, and it *will* be removed or completely changed (to match generic bay and dock interface) before Lenny is out. Thanks for the warning! Back to the problem at hand: there are Linux generic ACPI "dock" and "bay" drivers, they are supposed to notify userspace of any ejections and reconnections. Only, they don't do everything that is needed yet, and they don't handle many of the real ejectable devices in a laptop (e.g. ThinkPad batteries, floppies, and anything else that is not a SATA/ATA/ATAPI device). As for automated bus rescanning, sincerely, it is up to the kernel to do it. Anything else will be just an ugly hack or highly specific to a particular machine model. You really need to do ACPI/platform specific node -> kernel device -> device bus mapping to do it properly, and the kernel is the place to do it. Userspace should be getting the usual udev messages for device hot-insertion and hot-removal, and not need to care about anything else. If I understand you correctly, your advice would be to tag all of this stuff "wontfix"? is really the package that should take care of that. After all, acpi-support is only a set of hacks so that supend/resume works with as many laptops as possible. Frankly, a package should deal with anything and everything to do with ACPI support if it is going to be named "acpi-support". If it is a suspend/resume helper, it should have been named differently, IMO. Raphael's description skipped a few details. First of all, the purpose of the package is not only suspend/resume, it's basically to make as many laptop features work as possible. This includes all of the "special" buttons etc. Yes, this still means acpi-support is a misnomer, but we have an upstream, so package renaming is not a really attractive option. :-) Anyway, since acpi-support is really a collection of ugly hacks to make various laptops work, and since it is absolutely intended to be a transitional package until better solutions come along for the problems that it solves, there is something to be said for including a dirty hack for common docks as well. OTOH, if this stuff is going to be changed completely before Lenny comes out, it's probably not worth the trouble doing it now. What I do worry about is that the kernel hotplug events won't materialize in the kernel that will be shipped with Lenny. I don't want to leave these users out in the cold for yet another stable release cycle, so if this stuff isn't fixed in the kernel, I'm tempted to include a hack in acpi-support. Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Parallel build results
On 01/12/07 at 21:21 -0500, Daniel Schepler wrote: > I finally got through the test builds of all the source packages in sid for > i386 using dpkg-buildpackage -j3 on a dual core machine. The results as > before are at http://people.debian.org/~schepler/build-logs/bymaint.html . > Some statistics: > > 204 built BROKEN packages >1408 FAILED > 230 FAILED, even with regular build >8986 succeeded >1014 succeeded, but with jobserver warnings > > These are not encouraging statistics, especially considering the fact that > there are undoubtedly many false negatives, so I'll hold off on submitting > bug reports for now. According to those numbers, I don't really see how it could become a viable solution to require that packages support building using dpkg-buildpackage -j. This option is nice for maintainers, to build their own packages, but it seems better to push #209008 instead, so packages that take a long time to build have a common interface to specify that parallel builds. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#368383: keiznega
do you really want to be average all the time? or do you really want to excell? boost your manhood with this. http://www.omealy.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#78782: takuusta
Customers keep coming back for and more, why? because virility pills really do work! http://www.olodean.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#453955: ITP: virt-top -- show stats of virtualized domains
Package: wnpp Severity: wishlist Owner: Guido Guenther <[EMAIL PROTECTED]> * Package name: virt-top Version : 0.3.3.0 Upstream Author : [EMAIL PROTECTED] * URL : http://et.redhat.com/~rjones/virt-top/ * License : GPL Programming Lang: Ocaml Description : show stats of virtualized domains virt-top is modelled after the "ordinary" top utility and many keys and command line options are the same. . It uses libvirt so it capable of showing stats across a variety of different virtualization systems. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: Lenny release goal: UTF-8 debian/changelog and debian/control
Processing commands for [EMAIL PROTECTED]:
> #
> # Recording current bugs about non-utf8 debian/{control,changelog}
> #
> block #453954 by #356825
Bug#356825: elmo: unsuitable control + changelog file encoding
Bug#453954: general: Lenny release goal: UTF-8 debian/changelog and
debian/control
Was not blocked by any bugs.
Blocking bugs of 453954 added: 356825
> severity #356825 important
Bug#356825: elmo: unsuitable control + changelog file encoding
Severity set to `important' from `normal'
> block #453954 by #338837
Bug#338837: fcmp: unsuitable control file encoding
Bug#453954: general: Lenny release goal: UTF-8 debian/changelog and
debian/control
Was blocked by: 356825
Blocking bugs of 453954 added: 338837
> severity #338837 important
Bug#338837: fcmp: unsuitable control file encoding
Severity set to `important' from `normal'
> block #453954 by #338838
Bug#338838: glade-perl: unsuitable encoding in control file
Bug#453954: general: Lenny release goal: UTF-8 debian/changelog and
debian/control
Was blocked by: 338837 356825
Blocking bugs of 453954 added: 338838
> severity #338838 important
Bug#338838: glade-perl: unsuitable encoding in control file
Severity set to `important' from `normal'
> block #453954 by #242690
Bug#242690: itcl3: non-ASCII character in description field
Bug#453954: general: Lenny release goal: UTF-8 debian/changelog and
debian/control
Was blocked by: 338837 338838 356825
Blocking bugs of 453954 added: 242690
> severity #242690 important
Bug#242690: itcl3: non-ASCII character in description field
Severity set to `important' from `minor'
> block #453954 by #451080
Bug#451080: dash: Improperly encoded debian/changelog
Bug#453954: general: Lenny release goal: UTF-8 debian/changelog and
debian/control
Was blocked by: 242690 338837 338838 356825
Blocking bugs of 453954 added: 451080
> severity #451080 important
Bug#451080: dash: Improperly encoded debian/changelog
Severity set to `important' from `normal'
> block #453954 by #356825
Bug#356825: elmo: unsuitable control + changelog file encoding
Bug#453954: general: Lenny release goal: UTF-8 debian/changelog and
debian/control
Was blocked by: 242690 338837 338838 356825 451080
Blocking bugs of 453954 added: 356825
> severity #356825 important
Bug#356825: elmo: unsuitable control + changelog file encoding
Severity set to `important' from `important'
> block #453954 by #338837
Bug#338837: fcmp: unsuitable control file encoding
Bug#453954: general: Lenny release goal: UTF-8 debian/changelog and
debian/control
Was blocked by: 242690 338837 338838 356825 451080
Blocking bugs of 453954 added: 338837
> severity #338837 important
Bug#338837: fcmp: unsuitable control file encoding
Severity set to `important' from `important'
> block #453954 by #338838
Bug#338838: glade-perl: unsuitable encoding in control file
Bug#453954: general: Lenny release goal: UTF-8 debian/changelog and
debian/control
Was blocked by: 242690 338837 338838 356825 451080
Blocking bugs of 453954 added: 338838
> severity #338838 important
Bug#338838: glade-perl: unsuitable encoding in control file
Severity set to `important' from `important'
> --
Stopping processing here.
Please contact me if you need assistance.
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#453954: general: Lenny release goal: UTF-8 debian/changelog and debian/control
Package: general Severity: important This bug is to track progress on the Lenny release goal "UTF-8 debian/changelog and debian/control": * UTF-8 debian/changelog and debian/control Advocate: Russ Allbery Release-Team-Contact: ?? Description: Fix all remaining debian/changelog and debian/control files which don't use UTF-8. These are easily found by lintian via debian-changelog-file-uses-obsolete-national-encoding and debian-control-file-uses-obsolete-national-encoding. Bug-Tag: utf8-control State: confirmed (See [1]) I will file individual bugs against all packages that are affected (see [2] and [3]) and set them to block this bug. [1] http://release.debian.org/lenny-goals.txt [2] http://lintian.debian.org/reports/Tdebian-changelog-file-uses-obsolete-national-encoding.html [3] http://lintian.debian.org/reports/Tdebian-control-file-uses-obsolete-national-encoding.html -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.23.8 (SMP w/1 CPU core; PREEMPT) 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#150555: ugitteas
average dicks get average hoes. Bust out on all the babes when you increase your piece by up to 3 full inches http://oionbody.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: bug with imprperly encoded control and chnagelog
Processing commands for [EMAIL PROTECTED]:
> #
> # record bugs with improperly encoded debian/{control,changelog}
> #
> block #453954 by 453960
Bug#453960: Mass bug filing: debian/changelog must be utf8
Bug#453954: general: Lenny release goal: UTF-8 debian/changelog and
debian/control
Was blocked by: 242690 338837 338838 356825 451080
Blocking bugs of 453954 added: 453960
> block #453954 by 453962
Bug#453962: Mass bug filing: debian/changelog must be utf8
Bug#453954: general: Lenny release goal: UTF-8 debian/changelog and
debian/control
Was blocked by: 242690 338837 338838 356825 451080 453960
Blocking bugs of 453954 added: 453962
> block #453954 by 453963
Bug#453963: Mass bug filing: debian/changelog must be utf8
Bug#453954: general: Lenny release goal: UTF-8 debian/changelog and
debian/control
Was blocked by: 242690 338837 338838 356825 451080 453960 453962
Blocking bugs of 453954 added: 453963
> block #453954 by 453965
Bug#453965: Mass bug filing: debian/changelog must be utf8
Bug#453954: general: Lenny release goal: UTF-8 debian/changelog and
debian/control
Was blocked by: 242690 338837 338838 356825 451080 453960 453962 453963
Blocking bugs of 453954 added: 453965
> block #453954 by 453961
Bug#453961: Mass bug filing: debian/changelog must be utf8
Bug#453954: general: Lenny release goal: UTF-8 debian/changelog and
debian/control
Was blocked by: 242690 338837 338838 356825 451080 453960 453962 453963 453965
Blocking bugs of 453954 added: 453961
> block #453954 by 453966
Bug#453966: Mass bug filing: debian/changelog must be utf8
Bug#453954: general: Lenny release goal: UTF-8 debian/changelog and
debian/control
Was blocked by: 242690 338837 338838 356825 451080 453960 453961 453962 453963
453965
Blocking bugs of 453954 added: 453966
> block #453954 by 453967
Bug#453967: Mass bug filing: debian/changelog must be utf8
Bug#453954: general: Lenny release goal: UTF-8 debian/changelog and
debian/control
Was blocked by: 242690 338837 338838 356825 451080 453960 453961 453962 453963
453965 453966
Blocking bugs of 453954 added: 453967
> block #453954 by 453972
Bug#453972: Mass bug filing: debian/changelog must be utf8
Bug#453954: general: Lenny release goal: UTF-8 debian/changelog and
debian/control
Was blocked by: 242690 338837 338838 356825 451080 453960 453961 453962 453963
453965 453966 453967
Blocking bugs of 453954 added: 453972
> block #453954 by 453971
Bug#453971: Mass bug filing: debian/changelog must be utf8
Bug#453954: general: Lenny release goal: UTF-8 debian/changelog and
debian/control
Was blocked by: 242690 338837 338838 356825 451080 453960 453961 453962 453963
453965 453966 453967 453972
Blocking bugs of 453954 added: 453971
> block #453954 by 453974
Bug#453974: Mass bug filing: debian/changelog must be utf8
Bug#453954: general: Lenny release goal: UTF-8 debian/changelog and
debian/control
Was blocked by: 242690 338837 338838 356825 451080 453960 453961 453962 453963
453965 453966 453967 453971 453972
Blocking bugs of 453954 added: 453974
> block #453954 by 453964
Bug#453964: Mass bug filing: debian/changelog must be utf8
Bug#453954: general: Lenny release goal: UTF-8 debian/changelog and
debian/control
Was blocked by: 242690 338837 338838 356825 451080 453960 453961 453962 453963
453965 453966 453967 453971 453972 453974
Blocking bugs of 453954 added: 453964
> block #453954 by 453968
Bug#453968: Mass bug filing: debian/changelog must be utf8
Bug#453954: general: Lenny release goal: UTF-8 debian/changelog and
debian/control
Was blocked by: 242690 338837 338838 356825 451080 453960 453961 453962 453963
453964 453965 453966 453967 453971 453972 453974
Blocking bugs of 453954 added: 453968
> block #453954 by 453970
Bug#453970: Mass bug filing: debian/changelog must be utf8
Bug#453954: general: Lenny release goal: UTF-8 debian/changelog and
debian/control
Was blocked by: 242690 338837 338838 356825 451080 453960 453961 453962 453963
453964 453965 453966 453967 453968 453971 453972 453974
Blocking bugs of 453954 added: 453970
> block #453954 by 453973
Bug#453973: Mass bug filing: debian/changelog must be utf8
Bug#453954: general: Lenny release goal: UTF-8 debian/changelog and
debian/control
Was blocked by: 242690 338837 338838 356825 451080 453960 453961 453962 453963
453964 453965 453966 453967 453968 453970 453971 453972 453974
Blocking bugs of 453954 added: 453973
> block #453954 by 453969
Bug#453969: Mass bug filing: debian/changelog must be utf8
Bug#453954: general: Lenny release goal: UTF-8 debian/changelog and
debian/control
Was blocked by: 242690 338837 338838 356825 451080 453960 453961 453962 453963
453964 453965 453966 453967 453968 453970 453971 453972 453973 453974
Blocking bugs of 453954 added: 453969
> block #453954 by 453990
Bug#453990: Mass bug filing: debian/changelog must be utf8
Bug#453954: general: Lenny release goal: UTF-8 debian/changelog and
debian/control
Was blocked by: 242690 338837 338838 356825 451080 453960 453961 453962 453963
4
Bug#453954: general: Lenny release goal: UTF-8 debian/changelog and debian/control
On Sun, 02 Dec 2007 16:37:42 +0100, Bas Zoetekouw wrote: > This bug is to track progress on the Lenny release goal "UTF-8 > debian/changelog and debian/control": I'd suugest to include debian/copyright, too. Lintian is almost ready, cf. #451689 Cheers, gregor -- .''`. http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4 : :' : debian: the universal operating system - http://www.debian.org/ `. `' member of https://www.vibe.at/ | how to reply: http://got.to/quote/ `-NP: Red Hot Chili Peppers: Under The Bridge signature.asc Description: Digital signature
Processed: Re: Processed (with 1 errors): merging bugs
Processing commands for [EMAIL PROTECTED]: > block 453954 by 453962 Bug#453962: dash: debian/changelog should be utf8 Bug#453954: general: Lenny release goal: UTF-8 debian/changelog and debian/control Was blocked by: 242690 338837 338838 356825 451080 453960 453961 453962 453963 453964 453965 453966 453967 453968 453969 453970 453971 453972 453973 453974 453976 453977 453978 453979 453980 453981 453982 453983 453984 453985 453986 453987 453988 453989 453990 453991 453992 453993 453994 453995 453996 453997 453998 453999 454000 454001 454002 454003 454004 454005 454006 454007 454008 454009 454010 454011 454012 454013 454014 454015 454016 454017 454018 454019 454020 454021 454022 454023 454024 454025 454026 454027 454028 454029 454030 454031 454032 454033 454034 454035 Blocking bugs of 453954 added: 453962 > merge 451080 453962 Bug#451080: dash: Improperly encoded debian/changelog Bug#453962: dash: debian/changelog should be utf8 Merged 451080 453962. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#453955: ITP: virt-top -- show stats of virtualized domains
On 02-12-2007, Guido Guenther <[EMAIL PROTECTED]> wrote: > Package: wnpp > Severity: wishlist > Owner: Guido Guenther <[EMAIL PROTECTED]> > > * Package name: virt-top > Version : 0.3.3.0 > Upstream Author : [EMAIL PROTECTED] > * URL : http://et.redhat.com/~rjones/virt-top/ > * License : GPL > Programming Lang: Ocaml > Description : show stats of virtualized domains > > virt-top is modelled after the "ordinary" top utility and many keys and > command line options are the same. > . > It uses libvirt so it capable of showing stats across a variety of > different virtualization systems. > > > You should take contact with the pkg-ocaml-maint team to coordinate the packaging of this application. http://alioth.debian.org/projects/pkg-ocaml-maint/ #debian-ocaml on irc.debian.org [EMAIL PROTECTED] Regards, Sylvain Le Gall -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Injecting versions of build-deps in the deps
On Sun, Dec 02, 2007 at 05:11:52PM +0100, Loïc Minier wrote: > > An example would be package foobar3 build-depending on libfoo3 (>= > 2.10.2). When built against libfoo3 2.12.0-2 which provides a symbols > file, the resulting binaries need symbols from libfoo3 (>= 2.8.7) (as > the symbols file say), the new system injects a dep on libfoo3 >= > max(2.10.2, 2.8.7) == 2.10.2. >If libfoo3 only provides shlibs and no symbol file and the shlibs > claim a dep on libfoo3 (>= 2.10), the system would inject a dep on > libfoo3 >= max(2.10.2, 2.10) == 2.10.2. So you would need to build-depend on both libfoo-dev and libfoo3? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#453954: general: Lenny release goal: UTF-8 debian/changelog and debian/control
Hi gregor! You wrote: > > This bug is to track progress on the Lenny release goal "UTF-8 > > debian/changelog and debian/control": > > I'd suugest to include debian/copyright, too. > Lintian is almost ready, cf. #451689 I'd be happy to add debian/copyright, too, but as the release goal explicitly mentions chaneglog and control only, I think the release team should ok it first. (And of course the linitan test needs to be available on lintian.debian.org) Best regards, Bas. -- ++ | Bas Zoetekouw | GPG key: 0644fab7 | || Fingerprint: c1f5 f24c d514 3fec 8bf6 | | [EMAIL PROTECTED] | a2b1 2bae e41f 0644 fab7 | ++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Injecting versions of build-deps in the deps
Hi, Some packages require running with versions of libraries at least as high as the versions used during the build. I think we should offer packagers a system to generate dependencies close to this, but not as strict. This would complement our current infrastructure nicely, some of the rationale follows. In Debian, we have the shlibs system and now the "symbols" system to inject dependencies when ELF binaries depend on shared libs or symbols in shared libs. The shlibs system worked nicely and permits injecting high deps when the ABI is augmented backwards-compatibly, but this is not enough in all cases: Consider libfoo which doesn't change API/ABI, but sees a bug fix, shlibs aren't bumped as the lib is backwards-compatible. Package foobar detects the bugged version of libfoo at build time, and enables/disables a workaround. The shlibs/symbol systems will neither prevent foobar to build the workaround and run with the new libfoo, nor to disable the workaround and run with the old libfoo. The symbols system currently bypasses shlibs and will make sure that you get a version of a lib providing all ELF symbols that your binaries need, but like the shlibs system it only sees the ELF level: Consider libfoo2 which manipulates frozzles and doesn't change API/ABI at the ELF level, but gains support for a new frozzle. Package foobar2a needs the new frozzle, package foobar2b doesn't. The shlibs or symbols systems will either a) inject dependencies on the new version and hence give overly high dependencies for foobar2b or b) inject deps on the old version and hence give too loose deps (requiring the foobar2a to add a manual dependencies to get the new frozzle). In general, the shlibs and symbols systems inject dependencies which we would like as low as possible for each package [1], but the amount of information in the binaries is insufficient and encourages maintainers to bump injected dependencies at high levels. Similar problems exist outside of ELF binaries, such as across Python packages. An idea that came up is to use a per-dependent package information provided by the maintainer such as the build-deps version [2]. It would require a map from deps to build-deps and could typically be combined with the existing systems to inject a dependency >= max(shlibdeps version, bdeps version). An example would be package foobar3 build-depending on libfoo3 (>= 2.10.2). When built against libfoo3 2.12.0-2 which provides a symbols file, the resulting binaries need symbols from libfoo3 (>= 2.8.7) (as the symbols file say), the new system injects a dep on libfoo3 >= max(2.10.2, 2.8.7) == 2.10.2. If libfoo3 only provides shlibs and no symbol file and the shlibs claim a dep on libfoo3 (>= 2.10), the system would inject a dep on libfoo3 >= max(2.10.2, 2.10) == 2.10.2. What do you think of such a system? Please share your ideas and comments! Thanks to Raphaël Hertzog, Josselin Mouette, Julien Cristau, Aurélien Jarno, and Julien Blache (and the others I forget) for their arguments and comments on the topic and similar topics. [1] to help transitions to testing, or to ease installation of packages from $next-release without rebuilding, to ease upgrades [2] it could be a new field, but you would want to use it in the build-deps anyway; using b-deps is backwards-compatible and the most likely version we would want to start with -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Draft new policy document format
On Sat, Dec 01, 2007 at 12:29:28AM -0600, Manoj Srivastava wrote: > At Debconf earlier this year, I gave a talk about the benefits First of all, thanks for revamping this. I'm really looking forward for some common format for writing policies and, personally, I would be very happy to port the Vim and OCaml policies to such a format when there will be one. > Comments appreciated. As a general comment, before seeing an actual XML-like format I would like to see a list of what semantic information a document in such a format should be able to express. E.g. "a set of rules, each of which with a mandatoriness level which is one among MUST/SHOULD/... bla bla together with bla bla". Can you please summarize such information for us? In addition to that, just some tiny nitpicking below. > > Policy Rule Example > > > MUST > I find this use of inappropriate. The role is fine, but the one thing above is definitely not a paragraph, so it should not be tagged as such. Unfortunately I'm writing this email offline so I'm unable to check whether docbook has any more appropriate element for this or where else can be but a element, but something better then this should be looked for. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: Parallel build results
* Daniel Schepler <[EMAIL PROTECTED]> [071202 03:39]: > I finally got through the test builds of all the source packages in sid for > i386 using dpkg-buildpackage -j3 on a dual core machine. The results as > before are at http://people.debian.org/~schepler/build-logs/bymaint.html . |xbuffy: succeeded, but with jobserver warnings thanks for catching this, should be fixed with the upload of today. > These are not encouraging statistics, especially considering the fact that > there are undoubtedly many false negatives, so I'll hold off on submitting > bug reports for now. Glancing over some of the failed build logs, suprisingly many of them seem even be caused by broken debian/rules files. I'm suprised stuff like | build-arch: unpack-stamp patch-stamp configure build-arch-stamp | build-arch-stamp: |...some commands... actually works with -j1. (Well, it will only work when special targets are specified). I think going after such errors has much more advantages than just allowing hosts with multiple processors to build faster, such stuff should never be allowed to sneak in. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Injecting versions of build-deps in the deps
On Sun, Dec 02, 2007, Kurt Roeckx wrote: > > An example would be package foobar3 build-depending on libfoo3 (>= > > 2.10.2). When built against libfoo3 2.12.0-2 which provides a symbols > > file, the resulting binaries need symbols from libfoo3 (>= 2.8.7) (as > > the symbols file say), the new system injects a dep on libfoo3 >= > > max(2.10.2, 2.8.7) == 2.10.2. > >If libfoo3 only provides shlibs and no symbol file and the shlibs > > claim a dep on libfoo3 (>= 2.10), the system would inject a dep on > > libfoo3 >= max(2.10.2, 2.10) == 2.10.2. > > So you would need to build-depend on both libfoo-dev and libfoo3? Sorry, I meant "foobar3 build-depending on libfoo3-*dev*" (which is why I suggest we want a mapping to relate deps to build-deps); thanks for pointing out this typo. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Injecting versions of build-deps in the deps
On Sun, Dec 02, 2007 at 05:11:52PM +0100, Loïc Minier wrote: > What do you think of such a system? Please share your ideas and > comments! I think there is a problem using build dependencies for that purpose: There are dozens of reasons why you want to build-depend on libfoo-dev >= version that do NOT involve working around bugs in the library at runtime. There are so many that it would just pollute a lot of dependencies for a few interesting cases, and would sadly end up going in the opposite way we are currently heading for with the addition of dpkg-gensymbols. Now, the thing is you can pretty much already do some kind of trick to do what you want, with shlibs.local. The only problem with shlibs.local is that is forces to use the shlibs in this file and only these, so if the package's shlibs tell to depend on a newer version, it won't be taken into account. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#453954: general: Lenny release goal: UTF-8 debian/changelog and debian/control
On Sun, 02 Dec 2007 18:22:50 +0100, Bas Zoetekouw wrote: > > I'd suugest to include debian/copyright, too. > I'd be happy to add debian/copyright, too, but as the release goal > explicitly mentions chaneglog and control only, I think the release team > should ok it first. > (And of course the linitan test needs to be available on > lintian.debian.org) Agreed (on both aspects). Cheers, gregor -- .''`. http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4 : :' : debian: the universal operating system - http://www.debian.org/ `. `' member of https://www.vibe.at/ | how to reply: http://got.to/quote/ `-NP: Anouar Brahem: Le pas du chat noir signature.asc Description: Digital signature
Re: Parallel build results
Hi, On Sat, Dec 01, 2007 at 09:21:33PM -0500, Daniel Schepler wrote: > i386 using dpkg-buildpackage -j3 on a dual core machine. The results as > before are at http://people.debian.org/~schepler/build-logs/bymaint.html . I am not sure how to handle these problems with my packages. Currently there are two packages failing. detox and dnsproxy. dnsproxy should be simply (moving config.status depend to build-stamp instead of build), but with detox I don't really know what to do. Relevant parts for detox are: /usr/bin/install -c -d /tmp/buildd/detox-1.1.1/debian/tmp/etc /usr/bin/install: cannot create regular file `/tmp/buildd/detox-1.1.1/debian/tmp/etc/detoxrc.sample': No such file or directory make[1]: *** [install-sample-config] Error 1 make[1]: *** Waiting for unfinished jobs /usr/bin/install: `/tmp/buildd/detox-1.1.1/debian/tmp/etc' exists but is not a directory make[1]: *** [install-base] Error 1 make[1]: Leaving directory `/tmp/buildd/detox-1.1.1' So I assume the first install command for debian/tmp/etc was not successful? I'm not very experienced with parallel builds and I cannot reproduce this on my single-core-systems. So: Is there some documentation or hints on how to make package building be parallel-safe? Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Injecting versions of build-deps in the deps
On Sun, 02 Dec 2007, Mike Hommey wrote: > On Sun, Dec 02, 2007 at 05:11:52PM +0100, Loïc Minier wrote: > > What do you think of such a system? Please share your ideas and > > comments! > > I think there is a problem using build dependencies for that purpose: > There are dozens of reasons why you want to build-depend on libfoo-dev > >= version that do NOT involve working around bugs in the library at > runtime. There are so many that it would just pollute a lot of > dependencies for a few interesting cases, and would sadly end up going > in the opposite way we are currently heading for with the addition of > dpkg-gensymbols. > > Now, the thing is you can pretty much already do some kind of trick to > do what you want, with shlibs.local. The only problem with shlibs.local > is that is forces to use the shlibs in this file and only these, so if > the package's shlibs tell to depend on a newer version, it won't be > taken into account. I also explained that you can manually add a dependency in debian/control. dpkg-gencontrol will simplify the dependency as he want (by keeping the stricter one). However this requires a manual intervention of the maintainer while Loïc hoped that using the build-dep it would require no change by the maintainer. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Parallel build results
On Sat, 2007-12-01 at 21:21 -0500, Daniel Schepler wrote: > I finally got through the test builds of all the source packages in sid for > i386 using dpkg-buildpackage -j3 on a dual core machine. The results as > before are at http://people.debian.org/~schepler/build-logs/bymaint.html . > Some statistics: > > 204 built BROKEN packages >1408 FAILED > 230 FAILED, even with regular build >8986 succeeded >1014 succeeded, but with jobserver warnings > > These are not encouraging statistics, especially considering the fact that > there are undoubtedly many false negatives, so I'll hold off on submitting > bug reports for now. It appears that ExtUtils::MakeMaker, a standard Perl module commonly used to generate Makefiles for Perl modules, emits the rule: install :: all pure_install doc_install This appears to account for the failure of some of my Perl packages, and probably many others. This should be fixed in MakeMaker, not in the packages that use it. Ben. -- Ben Hutchings The most exhausting thing in life is being insincere. - Anne Morrow Lindberg signature.asc Description: This is a digitally signed message part
Re: Parallel build results
On Sunday 02 December 2007 02:12:40 pm Patrick Schoenfeld wrote: > Relevant parts for detox are: > /usr/bin/install -c -d /tmp/buildd/detox-1.1.1/debian/tmp/etc > /usr/bin/install: cannot create regular file > `/tmp/buildd/detox-1.1.1/debian/tmp/etc/detoxrc.sample': No such file or > directory > make[1]: *** [install-sample-config] Error 1 > make[1]: *** Waiting for unfinished jobs > /usr/bin/install: `/tmp/buildd/detox-1.1.1/debian/tmp/etc' exists but is > not a directory > make[1]: *** [install-base] Error 1 > make[1]: Leaving directory `/tmp/buildd/detox-1.1.1' Earlier, the Makefile is trying to execute /usr/bin/install -c detoxrc /tmp/buildd/detox-1.1.1/debian/tmp/etc/detoxrc.sample which failed because debian/tmp/etc was not yet created. So it appears the upstream package's Makefile is not parallel-safe, at least with regards to the install target. -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
