www.rich-dad.com.ar
Please see this site in Subject
www.juniorguide.com
Please see this site in Subject
Re: Debian-AI
[...] I am requesting comment on this approach, review of my project, and looking for guidance. Though I have tried for 7 years, I have not been able to make the breakthrough into the community (most likely owing to a lack of social skills). I tried to discuss this project on the Debian channels, where they suggested I post to the Debian-devel mailing list. Would there be any interest in a Debian-AI sub-project? Hmmm, I kind of fail to see the exact point: Are you really proposing a sub-project related to AI software (like Debian-Med is for medical tools), or are you rather proposing an AI approach to selecting and packaging any software? Judging from the beginning of your post I was tempted to think of the latter, but suggesting an AI sub-project seems something pretty different from that. Further, your repository mainly contains AI-related tools, but also some unrelated software. Could you/somebody else clarify this a little? Best, Michael pgpt0Y0h3ZzLt.pgp Description: PGP signature
Re: Debian-AI
On Tue, 1 Jan 2008, Andrew Dougherty wrote: As a result of this, it has been my goal to assemble a comprehensive software ontology of existing systems and package as many of them as possible, ordered in such a way that the new packages can improve the automatic creation of packages. I startet building Debian packages about 10 years ago and in no single case I had the impression that this process could be done automatically. You might be lucky if you try to package some kind of standardized archives like CTAN or CPAN, but I doubt that this is possible if you are picking random FOSS from the net. Would there be any interest in a Debian-AI sub-project? It sounds like you should think about joining the Custom Debian Distribution effort: http://wiki.debian.org/CustomDebian http://people.debian.org/~tille/cdd/ If you are using the CDD tools you could gain some profit for your users by technically grouping set of packages to takss. We have also automatic tools to document what we just have inside official Debian and what is on our todo list like for instance http://debian-med.alioth.debian.org/tasks/bio.php (Please note that the later URL is just a preview of the web tools that are currently developed and once they are bug free there will be an official announcement. It's just to give you an idea of the profit you might have if you are building an official CDD.) Kind regards and good luck for your project Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian-AI
On Wednesday 02 January 2008, Andrew Dougherty wrote: There is a lot of great libre software related to the field of Artificial Intelligence either directly or indirectly that has not been packaged yet for Debian. As a result of this, it has been my goal to assemble a comprehensive software ontology of existing systems and package as many of them as possible. If your goal is to provide a comprehensive repository of AI software, I think you have forgotten some rather important AI projects on your list. You might want to have a look at the following two lists: http://ml-site.grantingersoll.com/index.php?title=Existing_Learning_Tools http://mloss.org/software/ Isabel -- BOFH excuse #188:..disk or the processor is on fire. |\ _,,,---,,_ Web: http://www.isabel-drost.de /,`.-'`'-. ;-;;,_ |,4- ) )-,_..;\ ( `'-' '---''(_/--' `-'\_) (fL) IM: xmpp://[EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part.
Re: Faster shutdown and the ubuntu multiuser update-rc.d extention
On Wed, 2008-01-02 at 00:29 +, Colin Watson wrote: On Wed, Jan 02, 2008 at 12:13:13AM +0100, Petter Reinholdtsen wrote: What about changing the default values for dh_installinit for a future debhelper compatibility layer, to use 'start 20 2 3 4 5 . stop 80 1 .' instead of 'default' when calling update-rc.d? Some packages actually do need to shut down cleanly; in the case of a database, for example, such a change could cause data loss. Surely no more than a hard power failure(*), which databases (even such lightweight ones as sqlite) are designed to handle. (*) To any component :) -Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
some packges are waiting for i386 build
Hi list, I'm waiting sylpheed 2.4.8-1 package (i386) from 25th December, all architectures except i386 are built completed. sylpheed is still in build queue for one week. http://unstable.buildd.net/buildd/i386_Needs-Build_queueorder.html build percentage for i386 has decreased. http://buildd.debian.org/stats/graph-week-big.png Is there any trouble for i386 build? -- Regards, Hideki Yamane -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: -Wl,--as-needed considered possibly harmful
On Tue, 1 Jan 2008 23:17:50 -0800 Steve Langasek [EMAIL PROTECTED] wrote: On Wed, Dec 26, 2007 at 01:11:40PM +, Neil Williams wrote: I think I'm doing this already - if libfoo1 implements and exports types from libbar2 and libbar2 moves to libbar3, I would expect to have to port libfoo to libbar3 and this would usually cause a SONAME bump in libfoo. Have I got these possible scenarios correct: 1. libfoo depends on libbar2 without exporting libbar symbols. libfoo can migrate to libbar3 with internal code changes and if these do not require changing any libfoo interfaces, libfoo needs no SONAME bump. No, exporting libbar symbols is not the right line to draw. The right line is the one I already identified, namely, libfoo uses some of libbar's types in its own exported ABI. That makes more sense, thank you. Does libfoo need to use versioned symbols to cope with this No, libbar does, as the library which has other libraries for reverse-dependencies. (codehelp has a light bulb moment of clarity). :-) 2. libfoo depends on libbar2 and exports some libbar symbols in libfoo-dev. libfoo can migrate to libbar3 with only internal code changes because it only exports a portion of the libbar API that has not actually been changed in the libbar2-libbar3 transition. libfoo needs to export libbar in the libfoo --libs data. Is a SONAME bump needed in libfoo even though *none* of the libfoo interfaces have changed? As upstream for libfoo, I would not normally make a SONAME bump in this situation. If libfoo's exported ABI hasn't changed, then any package name or soname change is gratuitous and should be avoided. Agreed. 3. libfoo depends on libbar2 and needs to make changes to its own interfaces to cope with the libbar transition or needs to export symbols from the new libbar API and therefore makes a SONAME bump. No problem here except ensuring that applications transition to both API's at the same time. Can be enforced by making libbar-dev conflict with the old libfoo-dev or making the new libfoo-dev depend on the new libbar-dev version. Requires disruptive name changes to libbar-dev which affect all packages that build-depend on it, and is therefore again inferior to implementing symbol versions up front. OK. Because *all* libraries which have other libs as reverse-dependencies should implement symbol versioning, precisely as the shortest path for reliably and permanently addressing the various issues we're discussing. It *is* libbaz's fault for having an ABI-breaking change. And based on history, it is only reasonable to assume all such libraries are guilty, and demand that they use symbol versioning in anticipation of such future ABI changes. OK, I'm doing this upstream for one of my packages - following threads from: http://lists.debian.org/debian-mentors/2007/05/msg00387.html http://www.gnu.org/software/binutils/manual/ld-2.9.1/html_node/ld_25.html That gave me a basic versioning addition to the library, a diff of objdump -p shows: +Version definitions: +1 0x01 0x06077991 libqof.so.1 +2 0x00 0x0f307023 LIBQOF_0.7.3 + (I'm not putting the history of the symbols into the file at this stage - no new symbols are added in the new version so the libqof.ver file is simply marking all as global. I could add historical data - is there any benefit in that?) That's upstream covered, it appears I also need debian/libqof1.symbols from http://qa.debian.org/cgi-bin/mole/seedsymbols ? If I had done symbol versioning correctly upstream, shouldn't dpkg-shlibdeps be able to create the necessary data itself? I don't provide a .shlib file of my own at this stage. (A SONAME bump is due in this library fairly soon so I want to get symbol versioning into libqof1 prior to the ABI change.) No. You seem to agree that each soname change of a library near the bottom of the stack should not propagate its way up the stack to affect other libraries that themselves are not affected by the ABI change, but you again overlook (or disdain) the impact that this has on partial upgrades if we don't require those base libraries to use symbol versioning. It was an oversight. Sorry. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpCd2KIOnk2h.pgp Description: PGP signature
Re: Faster shutdown and the ubuntu multiuser update-rc.d extention
On Wed, Jan 02, 2008 at 09:47:20PM +1100, Robert Collins wrote: On Wed, 2008-01-02 at 00:29 +, Colin Watson wrote: Some packages actually do need to shut down cleanly; in the case of a database, for example, such a change could cause data loss. Surely no more than a hard power failure(*), which databases (even such lightweight ones as sqlite) are designed to handle. Databases guarantee consistency in case of a power failure, they cannot prevent data loss. -- Met vriendelijke groet / with kind regards, Guus Sliepen [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Parallel build results
On 01/01/08 at 18:23 -0800, Russ Allbery wrote: Aurelien Jarno [EMAIL PROTECTED] writes: On the other hand, DEB_BUILD_OPTIONS=parallel=n was ignored by packages that have not been validated by the maintainers, and used by packages that have been tested by the maintainer. Also it was possible to use only on some parts of the build. For example the make install part is sometimes problematic, and mainly depends on I/O throughput of the machine, and not CPU. This make some problems difficult to detect, as they happen only in rare case on some machines. Unfortunately dpkg-buildpackage now looks for DEB_BUILD_OPTIONS and call debian/rules with -j and the value it founds in this environment variable. That makes DEB_BUILD_OPTIONS=parallel=n useless, as it has the same effect as dpkg-buildpackage -j. I personally think that supporting DEB_BUILD_OPTIONS=parallel=n on some packages is a first goal to achieve. Supporting this option in the 100 packages which take the longest to build would probably be a huge improvement in build time of the whole archive, while being easier than fixing all the packages in the archive. I agree with this analysis. I think the MAKEFLAGS setting in dpkg-buildpackage should be removed and instead calling dpkg-buildpackage with the -j option should just set the parallel=n flag in DEB_BUILD_OPTIONS. From there, we can leave it to package maintainers to decide how to implement this. I filed bug #458589 against dpkg-dev about this. I think that both following solutions are fine: - dpkg-buildpackage must not consider DEB_BUILD_OPTIONS=parallel=n as the same thing as calling dpkg-buildpackage -j n. - dpkg-buildpackage -j must not set MAKEFLAGS. But if this is choosen, dpkg-buildpackage -j will simply become another way of doing 'export DEB_BUILD_OPTIONS=parallel=n'. Is it really worth keeping in this case? If someone *really* wants to try forcing make to do a parallel build, they can always set MAKEFLAGS themselves directly. True ; maybe dpkg-buildpackage -j is completely useless, actually. -- | 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]
Re: some packges are waiting for i386 build
Hideki Yamane a écrit : Hi list, I'm waiting sylpheed 2.4.8-1 package (i386) from 25th December, all architectures except i386 are built completed. sylpheed is still in build queue for one week. http://unstable.buildd.net/buildd/i386_Needs-Build_queueorder.html build percentage for i386 has decreased. http://buildd.debian.org/stats/graph-week-big.png Is there any trouble for i386 build? It seems the build daemon is down. However according to [1] it should not be a problem, you should build and upload the packages manually: | Waiver (for redundancy, since there isn't any): Most developers upload | for i386; buildd downtime can be made up for with manual uploads for | the few other packages And according to [1] you are supposed to have an i386 machine to do that: | Waiver: everyone has an i386 of their own, developer machines are | unnecessary. Cheers, Aurelien [1] http://wiki.debian.org/i386EtchReleaseRecertification -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: some packges are waiting for i386 build
On Wednesday 2 January 2008 14:27, Aurelien Jarno wrote: It seems the build daemon is down. However according to [1] it should not be a problem, you should build and upload the packages manually: | Waiver (for redundancy, since there isn't any): Most developers upload | for i386; buildd downtime can be made up for with manual uploads for | the few other packages Although this used to be sensible, it is getting outdated fast with the growth of amd64. Within the security team we're already experiencing the trouble with the i386 buildd being down from time to time, and a second one (perhaps with an extra buildd admin) would in my opinion be very desirable. Of course i386 machines are commonly available, but the suggested procedure of making uploads by hand is undesirable (especially for stable): a) it increases chances of dirty/broken build environments; b) it costs time; c) some packages require nontrivial resources (time, disk) to build. Several DSA's have been stalled the past months because of missing i386 builds. It would be great if we can reduce that. Thijs pgprhlg37rd1V.pgp Description: PGP signature
Re: some packges are waiting for i386 build
Hi, On Wed, 02 Jan 2008 14:27:42 +0100 Aurelien Jarno [EMAIL PROTECTED] wrote: It seems the build daemon is down. However according to [1] it should not be a problem, you should build and upload the packages manually: But I'm not a DD and not sylpheed package maintainer... ;-) Umm, if build daemon is down, it is a problem, I think. As i386 it is not a serious, but it is just a problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: some packges are waiting for i386 build
Quoting Thijs Kinkhorst ([EMAIL PROTECTED]): Of course i386 machines are commonly available, but the suggested procedure of making uploads by hand is undesirable (especially for stable): a) it increases chances of dirty/broken build environments; b) it costs time; c) some packages require nontrivial resources (time, disk) to build. Several DSA's have been stalled the past months because of missing i386 builds. It would be great if we can reduce that. Seconded (easy to say for me as I'm definitely not in position to do much to have another i386 buildd). I just noticed that missing i386 buildd today because I was surprised of KDE being non installable currently on i386 because many packages need to be built as they were apparently manually built on an amd64 machine. signature.asc Description: Digital signature
Re: Associating suffixes, programs and icons with MIME.
Le dimanche 30 décembre 2007 à 00:50 +0900, Charles Plessy a écrit : For the association between an icon and a file type, I did not manage. I found a document that tells how to give a name to the icons, and one that tells where third party applications should store them: http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html I found the program dh_icons that appeared in the debhelper suite at version 5.0.51. However, it seems quite GNOME-specific as it is not fully compliant with the FreeDesktop standard. http://bugs.debian.org/448094 The purpose of dh_icons is to update the caches, and it isn’t GNOME-specific. The bug you are pointing at is not annoying for most packages, as they use PNG or SVG, not XPM icons. Is there a Debian way to associate icons, file types and suffixes in FreeDesktop-compliant environments ? I don’t think there is a generic way to do that. The GNOME way is to provide an icon named mimetypes/gnome-mime-application-x-foobar, and it will automatically be selected for the application/x-foobar MIME type. For instance, the /usr/share/icons/hicolor directory (the default one) supports many different resolutions. Should a package support all of them ? The desktop will automatically select the most appropriate resolution among the ones that are provided, but it is preferable to have at least a scalable version and a 24x24 one. Should .icon files be written for all icons ? The .icon files are for parameters really specific to a given icon, like attach points for emblems or the area definition for embedded text. Most icons don’t need them. If they are identical, is it better to use symlinks ? Sure. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Associating suffixes, programs and icons with MIME.
Le mercredi 02 janvier 2008 à 16:46 +0100, Josselin Mouette a écrit : Is there a Debian way to associate icons, file types and suffixes in FreeDesktop-compliant environments ? I don’t think there is a generic way to do that. The GNOME way is to provide an icon named mimetypes/gnome-mime-application-x-foobar, and it will automatically be selected for the application/x-foobar MIME type. I forgot to add that although this works, you should almost never do that. This breaks icon themes in a very ugly way, and this is the reason why the countless MIME type icons in earlier releases were replaced by a much smaller set of generic icons. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: some packges are waiting for i386 build
Hideki Yamane [EMAIL PROTECTED] wrote: Umm, if build daemon is down, it is a problem, I think. As i386 it is not a serious, but it is just a problem. It is a problem, and it is serious. It's stalling the testing transition already due to missing builds. i386 is no longer a special case among our supported architectures. JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Parallel build results
On Tuesday 01 January 2008 07:36:34 pm Aurelien Jarno wrote: Did you compare the contents of the package with and without -j? I am almost sure some of the successfully built packages are actually not correctly built and some files are missing. For example I remember having seen some python packages building one flavour after the other in different targets. I imagine this could result in one of the flavour being overwritten by the other, and thus not present in the resulting .deb file. I compared the control files and file lists from the packages and marked the build broken if it found significant differences. So that would have caught the case above. But not a case where, for example, the compiler runs were started before patches were completely applied, probably resulting in a mix of patched and non-patched code. However, due to the issues raised in the previous thread about 100% bit-by-bit reproducibility of package builds, I don't see any good way to detect that case automatically. -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Parallel build results
On Monday 31 December 2007 04:07:15 pm Robert Millan wrote: On Sat, Dec 01, 2007 at 09:21:33PM -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 . Why -j3 ? It's already quite an effort to aim for -j2. Shouldn't we try to fix those first? That's just my habit, the idea being to increase the probability that both CPUs have work to do while I/O is going on. And besides, I don't see that much of a qualitative difference between -j2 and -j3, for reasons already pointed out by others in the thread. -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#199653: Say good bye to ED_dysfunction!
regards Nothing c'n B better than our pharmas! http://dobongworld.com And all night long they sailed away; -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Faster shutdown and the ubuntu multiuser update-rc.d extention
Robert Collins [EMAIL PROTECTED] writes: On Wed, 2008-01-02 at 00:29 +, Colin Watson wrote: Some packages actually do need to shut down cleanly; in the case of a database, for example, such a change could cause data loss. Surely no more than a hard power failure(*), which databases (even such lightweight ones as sqlite) are designed to handle. You can still lose data transactions that weren't complete, and you may have to go through an extended consistency check when the system comes back up. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#81118: Discounted RX, Customers are our #1 priority. We guarantee the quality of our drugs u7eizn2tti
ntact [EMAIL PROTECTED]
Re: Faster shutdown and the ubuntu multiuser update-rc.d extention
Robert Collins [EMAIL PROTECTED] writes: On Wed, 2008-01-02 at 00:29 +, Colin Watson wrote: Some packages actually do need to shut down cleanly; in the case of a database, for example, such a change could cause data loss. Surely no more than a hard power failure(*), which databases (even such lightweight ones as sqlite) are designed to handle. You can still lose data transactions that weren't complete, and you may have to go through an extended consistency check when the system comes back up. Definitely. And databases are likely to store some critical data, just consider LDAP as yet another database (which, for performance reasons, won't write changes to disk all the time). Once we are at it: If we don't do clean shutdowns of the services anymore, why don't you just turn off power instead of taking the pain to kill the processes? I guess I missed the point. Best, Michael pgpXIhMdRYBBM.pgp Description: PGP signature
Re: Faster shutdown and the ubuntu multiuser update-rc.d extention
On Wed, Jan 02, 2008 at 07:11:01PM +0100, Michael Tautschnig wrote: Once we are at it: If we don't do clean shutdowns of the services anymore, why don't you just turn off power instead of taking the pain to kill the processes? I guess I missed the point. Well, not sure whether I'm playing devil's advocate here, but: init sends a TERM signal to the processes, and only 5(?) seconds later the KILL signal. So databases or other services can catch the TERM signal and have five seconds to properly shutdown, which might or might not be enough. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458767: ITP: ccfits -- C++ library for I/O with FITS format data files
Package: wnpp Severity: wishlist Owner: Aurelien Jarno [EMAIL PROTECTED] * Package name: ccfits Version : 1.8 Upstream Author : HEASARC at the NASA Goddard Space Flight Center * URL : http://heasarc.gsfc.nasa.gov/fitsio/CCfits/ * License : BSD like Programming Lang: C++ Description : C++ library for I/O with FITS format data files CCfits is an object oriented interface to the cfitsio library. It is designed to make the capabilities of cfitsio available to programmers working in C++. It is written in ANSI C++ and implemented using the C++ Standard Library with namespaces, exception handling, and member template functions. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.23-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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]
List of packages which should probably be Architecture: all
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello all, I've written a script which tries to detect packages which should be architecture all based on the fact that they don't contain a Depends field. This is usually bug either because of a missing Depends or because the package should be Architecture: all. I'm not going to attempt to do a MBF for these because the results may contain many false positives so I encourage people to take a look at this list, review and fix or fill bug reports accordingly. The attachment is the list of packages including uploaders (output of dd-list -u). As usually any kind of feedback is very welcomed. Cheers, Raphael Geissert Anibal Avelar (Fixxxer) [EMAIL PROTECTED] centerim Loic Dachary (OuoU) [EMAIL PROTECTED] unittest++ (U) Peter De Schrijver (p2) [EMAIL PROTECTED] openwince-include Johan Euphrosine (proppy) [EMAIL PROTECTED] unittest++ Clint Adams [EMAIL PROTECTED] db (U) zsh Martin Albisetti [EMAIL PROTECTED] 2vcard Russ Allbery [EMAIL PROTECTED] gss (U) shishi (U) Stuart R. Anderson [EMAIL PROTECTED] lsb-build-base2 lsb-build-base3 Domenico Andreoli [EMAIL PROTECTED] curl Kumar Appaiah [EMAIL PROTECTED] vala (U) maximilian attems [EMAIL PROTECTED] klibc linux-2.6 (U) Jeff Bailey [EMAIL PROTECTED] klibc (U) Michael Banck [EMAIL PROTECTED] libopensync-plugin-palm Andreas Barth [EMAIL PROTECTED] iproute (U) Douglas Bates [EMAIL PROTECTED] r-base (U) Bradley Bell [EMAIL PROTECTED] bakery2.3 Christoph Berg [EMAIL PROTECTED] dds CJ van den Berg [EMAIL PROTECTED] pulseaudio Michael Biebl [EMAIL PROTECTED] tracker Bastian Blank [EMAIL PROTECTED] busybox (U) linux-2.6 (U) Eduard Bloch [EMAIL PROTECTED] icewm W. Borgert [EMAIL PROTECTED] omnievents Fathi Boudra [EMAIL PROTECTED] icecc (U) Joachim Breitner [EMAIL PROTECTED] xaralx Ludovic Brenta [EMAIL PROTECTED] gnat-4.1 (U) gnat-4.2 (U) Marc 'HE' Brockschmidt [EMAIL PROTECTED] libgnomecanvas (U) Rob Browning [EMAIL PROTECTED] guile-1.6 Cyril Brulebois [EMAIL PROTECTED] etl (U) Ross Burton [EMAIL PROTECTED] xnee Petr Cech [EMAIL PROTECTED] lde Hubert Chathi [EMAIL PROTECTED] gnustep-make (U) Kanru Chen [EMAIL PROTECTED] libchewing Patryk Cisek [EMAIL PROTECTED] kadu Robert Collins [EMAIL PROTECTED] libopensync-plugin-palm (U) Arnaud Cornet [EMAIL PROTECTED] ratbox-services Nigel Croxon [EMAIL PROTECTED] gnu-efi Marco d'Itri [EMAIL PROTECTED] inn2 Joost Yervante Damad [EMAIL PROTECTED] flake (U) Terry Dawson [EMAIL PROTECTED] hamlib (U) Debian Berkeley DB Maintainers [EMAIL PROTECTED] db Debian EMBOSS Packaging Team [EMAIL PROTECTED] emboss Debian GCC Maintainers [EMAIL PROTECTED] gcc-3.3 gcc-3.4 gcc-4.1 gcc-4.2 gcc-defaults gcj-4.1 gcj-4.2 gnat-4.1 gnat-4.2 Debian GNOME Maintainers [EMAIL PROTECTED] libgnomecanvas (U) system-tools-backends (U) Debian GNUstep maintainers [EMAIL PROTECTED] gnustep-make Debian Install System Team [EMAIL PROTECTED] busybox debian-installer discover1 os-prober Debian Java Maintainers [EMAIL PROTECTED] antlr Debian JED Group [EMAIL PROTECTED] tess Debian KDE Extras Team [EMAIL PROTECTED] icecc Debian Kernel Team [EMAIL PROTECTED] linux-2.6 Debian multimedia packages maintainers [EMAIL PROTECTED] libdts libdvb liblivemedia Debian Multimedia Team [EMAIL PROTECTED] flake Debian OpenOffice Team [EMAIL PROTECTED] openoffice.org Debian Qt/KDE Maintainers [EMAIL PROTECTED] qt-x11-free Debian Ruby Extras Maintainers [EMAIL PROTECTED] libdaemons-ruby (U) Debian Scientific Computing Team [EMAIL PROTECTED] netgen Debian Synfig Maintainers [EMAIL PROTECTED] etl Debian TeX Maintainers [EMAIL PROTECTED] texlive-bin Debian VDR Team [EMAIL PROTECTED] libmdsp Debian VoIP Team [EMAIL PROTECTED] srtp Debian Xfce Maintainers [EMAIL PROTECTED] xfce4-dev-tools XCB Developers [EMAIL PROTECTED] libpthread-stubs Scott M. Dier [EMAIL PROTECTED] bitcollider Yann Dirson [EMAIL PROTECTED] memtest86 memtest86+ Sebastian Dröge [EMAIL PROTECTED] avahi (U) libgnomecanvas (U) vala (U) Paul Dwerryhouse [EMAIL PROTECTED] kannel Dirk Eddelbuettel [EMAIL PROTECTED] r-base tclap Free Ekanayaka [EMAIL PROTECTED] flake (U) Rene Engelhard [EMAIL PROTECTED] lp-solve (U) openoffice.org (U) Exim4 Maintainers [EMAIL PROTECTED] exim4 Fabian Fagerholm [EMAIL PROTECTED] etl (U) Andreas Fester [EMAIL PROTECTED] qcad Andreas Franzen [EMAIL PROTECTED] pgapack Bdale Garbee [EMAIL PROTECTED] gnu-efi (U) Hector Garcia [EMAIL PROTECTED] mindi-busybox (U) Rudy Godoy [EMAIL PROTECTED] xfce4-dev-tools (U) Stephen Gran [EMAIL PROTECTED] dvdbackup freeradius Fabian Greffrath [EMAIL PROTECTED] invaders Tobias Grimm [EMAIL PROTECTED] libmdsp (U) Debian QA Group [EMAIL
Re: Debian-AI
From: Michael Tautschnig [EMAIL PROTECTED] Subject: Re: Debian-AI Date: Wed, 2 Jan 2008 09:38:34 +0100 [...] I am requesting comment on this approach, review of my project, and looking for guidance. Though I have tried for 7 years, I have not been able to make the breakthrough into the community (most likely owing to a lack of social skills). I tried to discuss this project on the Debian channels, where they suggested I post to the Debian-devel mailing list. Would there be any interest in a Debian-AI sub-project? Hmmm, I kind of fail to see the exact point: Are you really proposing a sub-project related to AI software (like Debian-Med is for medical tools), or are you rather proposing an AI approach to selecting and packaging any software? Judging from the beginning of your post I was tempted to think of the latter, but suggesting an AI sub-project seems something pretty different from that. Further, your repository mainly contains AI-related tools, but also some unrelated software. Could you/somebody else clarify this a little? Best, Michael No I'm not really proposing a sub-project related to AI, I should have titled the subject the FRDCSA project, not Debian-AI to avoid confusion. One would not start a sub-project without lots of interest. Andreas Tille points out that joining the Custom Debian Distribution effort might make more sense than a sub-project. As far as proposing an AI approach to selecting and packaging any software, yes I am proposing that. I propose to work with people on tools that: Create a Comprehensive Software Ontology (CSO) in Semantic Web's OWL format of existing software, including license information, project capabilities, all sorts of information about the projects, and make tools that use this information. A large number of projects can be queued from the FLOSSMole data. Create a webspider that can automatically index metasites like the ones Isabel Drost called to attention (http://ml-site.grantingersoll.com/index.php?title=Existing_Learning_Tools, http://mloss.org/software/), (detecting duplicates using alias detection and the same software they use to differentiate people), and begin adding those repositories to the CSO. Develop additional tools that enhance the coverage of automated, scripted and data-driven methods of transforming from upstream sources to source packages (a.k.a. packaging the software). The CSO must manage software licensing information and determine which software is appropriately licensed for packaging into different archives, whether it is free, non-free or simply a package that generates an installer. For software which is not licensed compliant to DFSG, systematically petition the authors to rerelease the software under a compatible license. Create a separate package archive for rough quality automated packages that users may use at their own risk, as well as begin manually tweaking these packages for inclusion to the main Debian repository. Regarding the difference between AI-related tools and unrelated software, IMHO any software or dataset may be considered as a component to a weak-AI because of the correspondance between proof-systems and programs (Curry Howard Isomorphism). While this may be an erroneous viewpoint, the main point is that we should package software relevant to increasing the capabilities of the system. Right now one great provider of improved capabilities are the unused AI systems, but there are many other sources as well. I hope this has gone some way towards clarifying exactly what I propose. Thank you for taking the time to consider my proposal. Sincerely, Andrew Dougherty -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
On 02/01/2008, Raphael Geissert wrote: Hello all, Maw. I've written a script which tries to detect packages which should be architecture all based on the fact that they don't contain a Depends field. This is usually bug either because of a missing Depends or because the package should be Architecture: all. Hm, what about checking their *content*? What about listing *binary* packages? Cheers, -- Cyril Brulebois pgpLZXls1co1w.pgp Description: PGP signature
Re: Faster shutdown and the ubuntu multiuser update-rc.d extention
On Wed, 2008-01-02 at 09:50 -0800, Russ Allbery wrote: Robert Collins [EMAIL PROTECTED] writes: On Wed, 2008-01-02 at 00:29 +, Colin Watson wrote: Some packages actually do need to shut down cleanly; in the case of a database, for example, such a change could cause data loss. Surely no more than a hard power failure(*), which databases (even such lightweight ones as sqlite) are designed to handle. You can still lose data transactions that weren't complete, and you may have to go through an extended consistency check when the system comes back up. Meh, two answers to my point that equate 'data loss' with 'incomplete transactions are not committed'. Incomplete transactions are *just that* - incomplete. Its why database clients use transactions and understand that errors (such as the db going away) mean their changes are not committed. If a database is asked to shutdown and a client has a 10 minute update running, you still end up with 'incomplete transaction not being completed' - unless of course you want to block indefinitely on each service. Your note about an extended consistency check is valid when a power loss has occurred but doesn't apply to the proposed fast shutdown as a signal is in fact sent to the database. (And BTW, if your database needs a huge consistency check on startup after a hard-down situation - consider changing database engine!). -Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: List of packages which should probably be Architecture: all
On Wed, Jan 02, 2008 at 01:17:24PM -0600, Raphael Geissert wrote: Hello all, I've written a script which tries to detect packages which should be architecture all based on the fact that they don't contain a Depends field. Your list seems to contain alot of packages that do have a Depends field. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
Hello Kurt, Kurt Roeckx wrote: On Wed, Jan 02, 2008 at 01:17:24PM -0600, Raphael Geissert wrote: Hello all, I've written a script which tries to detect packages which should be architecture all based on the fact that they don't contain a Depends field. Your list seems to contain alot of packages that do have a Depends field. Like which one? I used a lot of grepping so maybe something was left in. Kurt Cheers, -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
On Wed, Jan 02, 2008 at 01:17:24PM -0600, Raphael Geissert wrote: Clint Adams [EMAIL PROTECTED] db (U) zsh My first suggestion is to list binary packages instead of source. Then I could say that db4.6-doc is already arch:all and that zsh-static is a false positive. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
On 02/01/2008, Raphael Geissert wrote: Your list seems to contain alot of packages that do have a Depends field. Like which one? I used a lot of grepping so maybe something was left in. Take any random package, let's say icecc: $ apt-cache show icecc|grep ^Depends: Depends: libc6 (= 2.6-1), libgcc1 (= 1:4.2-20070516), libstdc++6 (= 4.2-20070516), debconf (= 0.5) | debconf-2.0, adduser, lsb-base A quick look at its content should also convince you that having binary objects under /usr/bin, /usr/lib, /usr/sbin isn't really a reason to ask for making it become an Architecture: all package… -- Cyril Brulebois pgp9FgKHmhFLe.pgp Description: PGP signature
Re: List of packages which should probably be Architecture: all
My first suggestion is to list binary packages instead of source. What about listing *binary* packages? That would be the doing of dd-list alone, it seems. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Joaquín Sabina - ¿Quién es Abel, quién es Caín? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
Hello Cyril, Cyril Brulebois wrote: Hm, what about checking their *content*? What about listing *binary* packages? Forgot to mention that, based on the binary-amd64 Packages file of the main, contrib and non-free sections. I didn't check the content of the packages because that's something linda/lintian should do, this is just a simple/quick list of packages and as I said it may contain some false positives (although there's usually a reason/bug causing the package to be listed). Cheers, Cheers, -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
On Wed, Jan 02, 2008 at 07:17:24PM +, Raphael Geissert wrote: maximilian attems [EMAIL PROTECTED] klibc linux-2.6 (U) OMG, I wish we knew about this before, we clearly would have saved a _lot_ of buildd time. Seriously, did you even _read_ the list you just submitted ? at least 66% of it is obviously wrong. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpyd0O2NwTxk.pgp Description: PGP signature
Re: List of packages which should probably be Architecture: all
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just to clarify to everybody, the list was screwed up by dd-list (my bad, didn't see the '-b' option part). Thanks to Adeodato for pointing that out. So, here's the list of binary packages (attachment is dd-list -u again). Anibal Avelar (Fixxxer) [EMAIL PROTECTED] centerim-common Loic Dachary (OuoU) [EMAIL PROTECTED] libunittest++0 (U) Peter De Schrijver (p2) [EMAIL PROTECTED] openwince-include Johan Euphrosine (proppy) [EMAIL PROTECTED] libunittest++0 Clint Adams [EMAIL PROTECTED] libdb4.6-dbg (U) zsh-dev Martin Albisetti [EMAIL PROTECTED] 2vcard Russ Allbery [EMAIL PROTECTED] libgss-dbg (U) shishi-dbg (U) Stuart R. Anderson [EMAIL PROTECTED] lsb-build-base2 lsb-build-base3 Domenico Andreoli [EMAIL PROTECTED] libcurl3-dbg Kumar Appaiah [EMAIL PROTECTED] vala-doc (U) maximilian attems [EMAIL PROTECTED] libklibc linux-headers-2.6.23-1-common (U) linux-libc-dev (U) Jeff Bailey [EMAIL PROTECTED] libklibc (U) Michael Banck [EMAIL PROTECTED] opensync-plugin-palm-dev Andreas Barth [EMAIL PROTECTED] iproute-dev (U) iproute-doc (U) Douglas Bates [EMAIL PROTECTED] r-mathlib (U) Bradley Bell [EMAIL PROTECTED] libbakery-2.3-common Christoph Berg [EMAIL PROTECTED] libdds-dev CJ van den Berg [EMAIL PROTECTED] libpulse-browse0-dbg Michael Biebl [EMAIL PROTECTED] tracker-dbg Bastian Blank [EMAIL PROTECTED] busybox-static (U) linux-headers-2.6.23-1-common (U) linux-libc-dev (U) Eduard Bloch [EMAIL PROTECTED] icewm-common W. Borgert [EMAIL PROTECTED] libomnievents-dev Fathi Boudra [EMAIL PROTECTED] libicecc-dev (U) Joachim Breitner [EMAIL PROTECTED] xaralx-examples Ludovic Brenta [EMAIL PROTECTED] gnat-4.1-base (U) gnat-4.2-base (U) Marc 'HE' Brockschmidt [EMAIL PROTECTED] libgnomecanvas2-0 (U) Rob Browning [EMAIL PROTECTED] libqthreads-12 Cyril Brulebois [EMAIL PROTECTED] etl-dev (U) Ross Burton [EMAIL PROTECTED] libxnee-dev Petr Cech [EMAIL PROTECTED] lde Hubert Chathi [EMAIL PROTECTED] gnustep-common (U) gnustep-make-ogo (U) Kanru Chen [EMAIL PROTECTED] libchewing3-data Patryk Cisek [EMAIL PROTECTED] kadu-dev Robert Collins [EMAIL PROTECTED] opensync-plugin-palm-dev (U) Arnaud Cornet [EMAIL PROTECTED] ratbox-services-common Nigel Croxon [EMAIL PROTECTED] gnu-efi Marco d'Itri [EMAIL PROTECTED] inn2-dev Joost Yervante Damad [EMAIL PROTECTED] libflake-dev (U) Terry Dawson [EMAIL PROTECTED] libhamlib-doc (U) Debian Berkeley DB Maintainers [EMAIL PROTECTED] libdb4.6-dbg Debian EMBOSS Packaging Team [EMAIL PROTECTED] libajax5-dev libnucleus5-dev Debian GCC Maintainers [EMAIL PROTECTED] gcc-3.3-base gcc-3.4-base gcc-4.1-base gcc-4.2-base gcj-4.1-base gcj-4.2-base gnat-4.1-base gnat-4.2-base libgcj-common Debian GNOME Maintainers [EMAIL PROTECTED] libgnomecanvas2-0 (U) system-tools-backends-dev (U) Debian GNUstep maintainers [EMAIL PROTECTED] gnustep-common gnustep-make-ogo Debian Install System Team [EMAIL PROTECTED] busybox-static debian-installer libdiscover1-pic os-prober Debian Java Maintainers [EMAIL PROTECTED] libantlr-dev Debian JED Group [EMAIL PROTECTED] slang-tess Debian KDE Extras Team [EMAIL PROTECTED] libicecc-dev Debian Kernel Team [EMAIL PROTECTED] linux-headers-2.6.23-1-common linux-libc-dev Debian multimedia packages maintainers [EMAIL PROTECTED] libdts-dev libdvb-dev liblivemedia-dev Debian Multimedia Team [EMAIL PROTECTED] libflake-dev Debian OpenOffice Team [EMAIL PROTECTED] libmythes-dev openoffice.org-dbg Debian Qt/KDE Maintainers [EMAIL PROTECTED] libqt3-headers Debian Ruby Extras Maintainers [EMAIL PROTECTED] libdaemons-ruby1.8 (U) Debian Scientific Computing Team [EMAIL PROTECTED] libnetgen-dev Debian Synfig Maintainers [EMAIL PROTECTED] etl-dev Debian TeX Maintainers [EMAIL PROTECTED] texlive-base-bin-doc texlive-metapost-doc Debian VDR Team [EMAIL PROTECTED] libmdsp-dev Debian VoIP Team [EMAIL PROTECTED] libsrtp1-dev Debian Xfce Maintainers [EMAIL PROTECTED] xfce4-dev-tools XCB Developers [EMAIL PROTECTED] libpthread-stubs0 Scott M. Dier [EMAIL PROTECTED] libbitcollider-dev Yann Dirson [EMAIL PROTECTED] memtest86 memtest86+ Sebastian Dröge [EMAIL PROTECTED] libavahi-common-data (U) libgnomecanvas2-0 (U) vala-doc (U) Paul Dwerryhouse [EMAIL PROTECTED] kannel-dev Dirk Eddelbuettel [EMAIL PROTECTED] libtclap-dev r-mathlib Free Ekanayaka [EMAIL PROTECTED] libflake-dev (U) Rene Engelhard [EMAIL PROTECTED] liblpsolve55-dev (U) libmythes-dev (U) openoffice.org-dbg (U) Exim4 Maintainers [EMAIL PROTECTED] exim4-dev Fabian Fagerholm [EMAIL PROTECTED] etl-dev (U) Andreas Fester [EMAIL PROTECTED] libqcad0-dev Andreas Franzen [EMAIL PROTECTED] pgapack Bdale Garbee [EMAIL
Re: List of packages which should probably be Architecture: all
On Wed, Jan 02, 2008 at 01:38:32PM -0600, Raphael Geissert wrote: Hello Kurt, Kurt Roeckx wrote: On Wed, Jan 02, 2008 at 01:17:24PM -0600, Raphael Geissert wrote: Hello all, I've written a script which tries to detect packages which should be architecture all based on the fact that they don't contain a Depends field. Your list seems to contain alot of packages that do have a Depends field. Like which one? I used a lot of grepping so maybe something was left in. As already pointed out by some others, you should list the binary packages instead of the source packages. It's rather confusing like this. Anibal Avelar (Fixxxer) [EMAIL PROTECTED] centerim That should be centerim-common Loic Dachary (OuoU) [EMAIL PROTECTED] unittest++ (U) libunittest++0 Johan Euphrosine (proppy) [EMAIL PROTECTED] unittest++ libunittest++0 Russ Allbery [EMAIL PROTECTED] gss (U) libgss-dbg, false positive shishi (U) shishi-dbg, false positive Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
Interesting idea, though so few packages lack dependencies that it won't catch much. Perhaps grepping for package that don't depend on any shared libraries would catch more? Raphael Geissert wrote: maximilian attems [EMAIL PROTECTED] klibc linux-2.6 (U) heh Andreas Barth [EMAIL PROTECTED] iproute (U) Has dependencies. busybox depends on libc6 debian-installer Arch all so that d-i boot images will autobuild. discover1 depends on libc6 os-prober Contains architecture-dependent shell scripts, like many other d-i udebs. -- see shy jo
Re: List of packages which should probably be Architecture: all
On 02/01/2008, Raphael Geissert wrote: Forgot to mention that, based on the binary-amd64 Packages file of the main, contrib and non-free sections. I didn't check the content of the packages because that's something linda/lintian should do Wondering why, I asked what they were supposed to catch: 20:51:10 [ KiBi] Atomo64: What are linda/lintian supposed to catch? 20:51:49 [ KiBi] That an Architecture: any package rightfully contains architecture-dependent data? 20:51:57 [ Atomo64] KiBi: !arch: all packages not containing any arch-dependent file You might have missed the point, trying again: your list contains plenty of “Architecture: any” packages that are *rightfully* “any” because they *do* contain architecture-dependant stuff (see e.g. icecc as already pointed out). this is just a simple/quick list of packages and as I said it may contain some false positives (although there's usually a reason/bug causing the package to be listed). Maybe there's rather a bug in your process. Instead of speaking of “plenty of greps”, you might want to expose the code / algorithm you used. -- Cyril Brulebois pgpHsdTBsCCaC.pgp Description: PGP signature
Re: List of packages which should probably be Architecture: all
On Wed, Jan 02, 2008 at 07:58:24PM +, Raphael Geissert wrote: Russ Allbery [EMAIL PROTECTED] libgss-dbg (U) shishi-dbg (U) rrght... -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpicoMtNRbk4.pgp Description: PGP signature
Re: List of packages which should probably be Architecture: all
On Wed, 02 Jan 2008 13:17:24 -0600, Raphael Geissert [EMAIL PROTECTED] said: Hello all, I've written a script which tries to detect packages which should be architecture all based on the fact that they don't contain a Depends field. This is usually bug either because of a missing Depends or because the package should be Architecture: all. Maybe you want to make this into a lintian test? [...] Hubert Chathi [EMAIL PROTECTED] gnustep-make (U) This package only contains data files (makefile snippets, shell scripts, etc.), but the contents of the data files vary depending on what architecture it was built on, since it needs to control building for the right environment. -- Hubert Chathi [EMAIL PROTECTED] -- Jabber: [EMAIL PROTECTED] PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
Hello Joey, Joey Hess wrote: Interesting idea, though so few packages lack dependencies that it won't catch much. Perhaps grepping for package that don't depend on any shared libraries would catch more? Nice idea, though I'll first wait for everybody to read my last message (Message-ID: [EMAIL PROTECTED]) which contains the 'good' list (I wonder why dd-list goes the source packages way when the ones provided in the input are nothing but binary packages). Cheers, -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
On Wed, Jan 02, 2008 at 08:04:44PM +, Pierre Habouzit wrote: On Wed, Jan 02, 2008 at 07:58:24PM +, Raphael Geissert wrote: Russ Allbery [EMAIL PROTECTED] libgss-dbg (U) shishi-dbg (U) rrght... Though after a second thought, -dbg should probably not have empty Depends line. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpS3HNNobS5m.pgp Description: PGP signature
Re: List of packages which should probably be Architecture: all
On Wed, Jan 02, 2008 at 01:58:24PM -0600, Raphael Geissert wrote: Just to clarify to everybody, the list was screwed up by dd-list (my bad, didn't see the '-b' option part). Thanks to Adeodato for pointing that out. So, here's the list of binary packages (attachment is dd-list -u again). This list looks alot better, but still seems to contains atleast 1 that have a Depends field: Marc 'HE' Brockschmidt [EMAIL PROTECTED] libgnomecanvas2-0 (U) Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
On 02/01/2008, Pierre Habouzit wrote: Though after a second thought, -dbg should probably not have empty Depends line. After a third thought, I still fail to see what that has to do with being Architecture: all or any. -- Cyril Brulebois pgp8jGHoiH4cw.pgp Description: PGP signature
Re: some packges are waiting for i386 build
On Wed, Jan 02, 2008 at 05:18:58PM +, Julien BLACHE wrote: Hideki Yamane [EMAIL PROTECTED] wrote: Umm, if build daemon is down, it is a problem, I think. As i386 it is not a serious, but it is just a problem. It is a problem, and it is serious. It's stalling the testing transition already due to missing builds. i386 is no longer a special case among our supported architectures. Agreed. OTOH couldn't the amd64 buildd's also act as i386 buildd's ? I think that _most_ of the packages are built either on x86 or amd64, and it's fair to share the buildd infrastructure on the same hosts based on this. That should solve the issue of needing a w-b access since it's host-based I guess. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpgLhsPyNpwN.pgp Description: PGP signature
Re: List of packages which should probably be Architecture: all
On Wed, Jan 02, 2008 at 08:16:21PM +, Cyril Brulebois wrote: On 02/01/2008, Pierre Habouzit wrote: Though after a second thought, -dbg should probably not have empty Depends line. After a third thought, I still fail to see what that has to do with being Architecture: all or any. I agree. My point is, listing packages with an empty Depends: line isn't meaningless. The total lack of data-massaging _is_ a mistake though. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgprD3GzFg5dK.pgp Description: PGP signature
Re: List of packages which should probably be Architecture: all
On Wed, Jan 02, 2008 at 09:11:40PM +0100, Pierre Habouzit wrote: On Wed, Jan 02, 2008 at 08:04:44PM +, Pierre Habouzit wrote: On Wed, Jan 02, 2008 at 07:58:24PM +, Raphael Geissert wrote: Russ Allbery [EMAIL PROTECTED] libgss-dbg (U) shishi-dbg (U) rrght... Though after a second thought, -dbg should probably not have empty Depends line. It should even have a = dependency on the binary package that contains the binaries. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'll consider your message as sent (won't verify timestamps) before I clarified the situation both by mail and on IRC. Cyril Brulebois wrote: Maybe there's rather a bug in your process. Instead of speaking of “plenty of greps”, you might want to expose the code / algorithm you used. Parts of it are pretty ugly (and the Packages-fetching part isn't there), but I'm attaching it anyway. Cheers, - -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHe/FJYy49rUbZzloRAnsOAJ9vsqqQ3tVJW6mant4W4vNOn0R/IACePp+z gd3VgRJ0FeUZEqDPbZl2ohI= =va4z -END PGP SIGNATURE- should-be-arch-all.sh Description: application/shellscript
Re: some packges are waiting for i386 build
Thijs Kinkhorst wrote: Several DSA's have been stalled the past months because of missing i386 builds. It would be great if we can reduce that. i386 d-i is also broken due to missing i386 builds now. (partman-* version skew) -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: some packges are waiting for i386 build
Pierre Habouzit a écrit : On Wed, Jan 02, 2008 at 05:18:58PM +, Julien BLACHE wrote: Hideki Yamane [EMAIL PROTECTED] wrote: Umm, if build daemon is down, it is a problem, I think. As i386 it is not a serious, but it is just a problem. It is a problem, and it is serious. It's stalling the testing transition already due to missing builds. i386 is no longer a special case among our supported architectures. Agreed. OTOH couldn't the amd64 buildd's also act as i386 buildd's ? I think that _most_ of the packages are built either on x86 or amd64, and it's fair to share the buildd infrastructure on the same hosts based on this. That should solve the issue of needing a w-b access since it's host-based I guess. wanna-build access is handled via an ssh-key so that's not a problem. The main problem I see is that sbuild uses apt from the host installation, which means the host and the chroot should have the same architecture. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
Cyril Brulebois wrote: On 02/01/2008, Pierre Habouzit wrote: Though after a second thought, -dbg should probably not have empty Depends line. After a third thought, I still fail to see what that has to do with being Architecture: all or any. Quoting my self (first message): This is usually bug either because of a missing Depends or because the package should be Architecture: all. Cheers, -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Faster shutdown and the ubuntu multiuser update-rc.d extention
On Wed, Jan 02, 2008 at 07:11:01PM +0100, Michael Tautschnig wrote: Once we are at it: If we don't do clean shutdowns of the services anymore, why don't you just turn off power instead of taking the pain to kill the processes? I guess I missed the point. The point is that, if all you're going to do by way of a clean shutdown is send SIGTERM to the process and not wait for it to complete (which is the case for quite a number of init scripts; Scott did a survey of those that were part of a stock Ubuntu desktop installation at http://wiki.ubuntu.com/Teardown), then you might as well just let sendsigs do that since it's going to do so anyway. This isn't not doing clean shutdowns - it's just rationalising away multiple init scripts called on shutdown that are duplicating work done by a core script. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
Raphael Geissert a écrit : Cyril Brulebois wrote: On 02/01/2008, Pierre Habouzit wrote: Though after a second thought, -dbg should probably not have empty Depends line. After a third thought, I still fail to see what that has to do with being Architecture: all or any. Quoting my self (first message): This is usually bug either because of a missing Depends or because the package should be Architecture: all. I fail to see why. Imagine for example a -dev package providing only .h files, but depending on the architecture. It has to be Architecture: any and does not need to Depends on a package. You really have to look at the contents of the package and verify it does not change between architecture. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
Pierre Habouzit [EMAIL PROTECTED] writes: On Wed, Jan 02, 2008 at 08:04:44PM +, Pierre Habouzit wrote: On Wed, Jan 02, 2008 at 07:58:24PM +, Raphael Geissert wrote: Russ Allbery [EMAIL PROTECTED] libgss-dbg (U) shishi-dbg (U) rrght... Though after a second thought, -dbg should probably not have empty Depends line. Indeed. Fixed in CVS, and I'll file a wishlist lintian bug to remind me or someone to write a check at some point. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Faster shutdown and the ubuntu multiuser update-rc.d extention
On Thu, Jan 03, 2008 at 06:29:09AM +1100, Robert Collins wrote: On Wed, 2008-01-02 at 09:50 -0800, Russ Allbery wrote: Robert Collins [EMAIL PROTECTED] writes: On Wed, 2008-01-02 at 00:29 +, Colin Watson wrote: Some packages actually do need to shut down cleanly; in the case of a database, for example, such a change could cause data loss. Surely no more than a hard power failure(*), which databases (even such lightweight ones as sqlite) are designed to handle. You can still lose data transactions that weren't complete, and you may have to go through an extended consistency check when the system comes back up. Meh, two answers to my point that equate 'data loss' with 'incomplete transactions are not committed'. This is true, but it's still a change in the behaviour of the system that may or may not be desirable. The purpose of the change Petter is proposing (at least the purpose of the same change when it was done in Ubuntu) is a trivial transformation of init scripts that does not produce any meaningful change in behaviour. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
Pierre Habouzit wrote: On Wed, Jan 02, 2008 at 07:58:24PM +, Raphael Geissert wrote: Russ Allbery [EMAIL PROTECTED] libgss-dbg (U) shishi-dbg (U) rrght... -dbg package without a Depends? that sounds like a bug (please read my first message). Depends: sishi Depends: libgss0 ? -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
Hubert Chathi [EMAIL PROTECTED] writes: Maybe you want to make this into a lintian test? The reason not to do a general lintian test is exactly... This package only contains data files (makefile snippets, shell scripts, etc.), but the contents of the data files vary depending on what architecture it was built on, since it needs to control building for the right environment. ...that. It's very hard for lintian to rule out false positives here. Other examples include header files with architecture-specific defines or data types. lintian does already have a few checks in this area for specific types of packages. Another check that would generally be valid would be to flag any package that only installs files in /usr/share but is arch: any. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Faster shutdown and the ubuntu multiuser update-rc.d extention
Colin Watson [EMAIL PROTECTED] writes: The point is that, if all you're going to do by way of a clean shutdown is send SIGTERM to the process and not wait for it to complete (which is the case for quite a number of init scripts; Scott did a survey of those that were part of a stock Ubuntu desktop installation at http://wiki.ubuntu.com/Teardown), then you might as well just let sendsigs do that since it's going to do so anyway. This isn't not doing clean shutdowns - it's just rationalising away multiple init scripts called on shutdown that are duplicating work done by a core script. Right. The only case where a shutdown script makes sense to me is if it's doing something other than sending signals or if it's waiting (intelligently, not just blindly for five seconds) for the process to shut down cleanly. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
On Wed, Jan 02, 2008 at 03:06:21PM -0500, Hubert Chathi wrote: On Wed, 02 Jan 2008 13:17:24 -0600, Raphael Geissert [EMAIL PROTECTED] said: Hello all, I've written a script which tries to detect packages which should be architecture all based on the fact that they don't contain a Depends field. This is usually bug either because of a missing Depends or because the package should be Architecture: all. Maybe you want to make this into a lintian test? One thing I feel is worth mentioning is that it is more harmful for a package to be mistakenly Architecture: all than mistakenly Architecture: any. The former merely wastes some disk space, while the latter will cause actual broken packages. While the breakage would be obvious in the case of packages containing ELF binaries, in the case of packages like os-prober that include different scripts depending on the build architecture, the breakage would be more subtle and time-consuming: it will simply fail to detect things that should have been detected. In light of this, and that there's no straightforward way I can think of for Lintian to detect this situation given a binary package, I feel that a Lintian test risks prompting inexperienced maintainers to err on the side of incaution and set an incorrect Architecture field. I appreciate the zeal involved in cleaning up those packages which are any when they should be all, but is a Lintian test for this worth the potential breakage? Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: some packges are waiting for i386 build
On Wed, Jan 02, 2008 at 09:35:08PM +0100, Aurelien Jarno wrote: The main problem I see is that sbuild uses apt from the host installation, which means the host and the chroot should have the same architecture. Two solutions present themselves: * -o APT::Architecture=i386 (if that works) * an i386 chroot within which you run sbuild, with the actual buildd chroots nested inside that -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
Aurelien Jarno wrote: I fail to see why. Imagine for example a -dev package providing only .h files, but depending on the architecture. It has to be Architecture: any and does not need to Depends on a package. I know I'm hidding behind my 'the results may contain many false positives' statement but I'm really aware there are some exceptions (like the one you mentioned or others like kdepim-dbg, as stated by Sune Vuorela, which contain the symbols of several binaries which are distributed in several binary packages). You really have to look at the contents of the package and verify it does not change between architecture. I'll try to do it when I have time and after the archive wide lintian check (on amd64 binary packages only) I talked about in #-qa Cheers, Raphael Geissert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
On 02/01/2008, Colin Watson wrote: While the breakage would be obvious in the case of packages containing ELF binaries, […] Not necessarily, one could remember of RC bugs opened for some months due to arch: all packages containing shared objects, and its maintainer wondering what was happening on 64-bit architectures, where 32-bit shared objects were (unsuccessfully) tried to be used. -- Cyril Brulebois pgpmyYrhdOIhc.pgp Description: PGP signature
Re: List of packages which should probably be Architecture: all
On Wed, Jan 02, 2008 at 09:39:17PM +0100, Aurelien Jarno wrote: Raphael Geissert a écrit : Cyril Brulebois wrote: On 02/01/2008, Pierre Habouzit wrote: Though after a second thought, -dbg should probably not have empty Depends line. After a third thought, I still fail to see what that has to do with being Architecture: all or any. Quoting my self (first message): This is usually bug either because of a missing Depends or because the package should be Architecture: all. I fail to see why. Imagine for example a -dev package providing only .h files, but depending on the architecture. It has to be Architecture: any and does not need to Depends on a package. Most -dev package do not fall in this category because they have a symlink to the shared library and thus have a Depends. This is probably why it says ussually. Reasons why a -dev package can be arch any: - It contains a static library. - It contains headers that change depending on the arch. Reasons why a -dev can have Depends: - symlink to shared library - The headers file in it use header files from an other library. - The libtool .la or pkg-config .pc files mention other such files. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: some packges are waiting for i386 build
Aurelien Jarno [EMAIL PROTECTED] writes: Pierre Habouzit a écrit : On Wed, Jan 02, 2008 at 05:18:58PM +, Julien BLACHE wrote: Hideki Yamane [EMAIL PROTECTED] wrote: Agreed. OTOH couldn't the amd64 buildd's also act as i386 buildd's ? I think that _most_ of the packages are built either on x86 or amd64, and it's fair to share the buildd infrastructure on the same hosts based on this. That should solve the issue of needing a w-b access since it's host-based I guess. wanna-build access is handled via an ssh-key so that's not a problem. The main problem I see is that sbuild uses apt from the host installation, which means the host and the chroot should have the same architecture. This is only a problem with the old version of sbuild in use on the buildds. The version in unstable has used the apt inside the chroot for well over two years. The patches to enable it do exist in the GIT repo, and could be trivially ported to the sbuild in use on the buildds. In fact, the unstable sbuild even has an --arch option to specify the build architecture, and will select the appropriate chroot accordingly. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. pgpHADudESoa0.pgp Description: PGP signature
Re: List of packages which should probably be Architecture: all
On Wed, Jan 02, 2008 at 02:17:08PM -0600, Raphael Geissert wrote: Parts of it are pretty ugly (and the Packages-fetching part isn't there), but I'm attaching it anyway. Tying together grep-dctrl and dd-list would probably be a cleaner approach. I haven't done a thorough comparison to your list but the results seem to be pretty similar. $ grep-dctrl ! -FDepends -e '.' -a ! -FPre-Depends -e '.' \ -a ! -FArchitecture all -n -sPackage binary-i386_Packages | dd-list -i -u -b Anibal Avelar (Fixxxer) [EMAIL PROTECTED] centerim-common Loic Dachary (OuoU) [EMAIL PROTECTED] libunittest++0 (U) Peter De Schrijver (p2) [EMAIL PROTECTED] openwince-include Johan Euphrosine (proppy) [EMAIL PROTECTED] libunittest++0 Clint Adams [EMAIL PROTECTED] libdb4.6-dbg (U) zsh-dev Martin Albisetti [EMAIL PROTECTED] 2vcard Russ Allbery [EMAIL PROTECTED] libgss-dbg (U) shishi-dbg (U) Stuart R. Anderson [EMAIL PROTECTED] lsb-build-base2 lsb-build-base3 Domenico Andreoli [EMAIL PROTECTED] libcurl3-dbg Kumar Appaiah [EMAIL PROTECTED] vala-doc (U) maximilian attems [EMAIL PROTECTED] libklibc linux-headers-2.6.23-1-common (U) linux-headers-2.6.23-1-common-xen (U) linux-libc-dev (U) Jeff Bailey [EMAIL PROTECTED] gnumach (U) gnumach-dev (U) libklibc (U) Jeff Bailey [EMAIL PROTECTED] oskit (U) Michael Banck [EMAIL PROTECTED] opensync-plugin-palm-dev Andreas Barth [EMAIL PROTECTED] iproute-dev (U) iproute-doc (U) Douglas Bates [EMAIL PROTECTED] r-mathlib (U) Daniel Baumann [EMAIL PROTECTED] lightning Bradley Bell [EMAIL PROTECTED] libbakery-2.3-common Christoph Berg [EMAIL PROTECTED] libdds-dev CJ van den Berg [EMAIL PROTECTED] libpulse-browse0-dbg Michael Biebl [EMAIL PROTECTED] tracker-dbg Bastian Blank [EMAIL PROTECTED] busybox-static (U) linux-headers-2.6.23-1-common (U) linux-headers-2.6.23-1-common-xen (U) linux-libc-dev (U) Eduard Bloch [EMAIL PROTECTED] icewm-common Ed Boraas [EMAIL PROTECTED] oskit W. Borgert [EMAIL PROTECTED] libomnievents-dev Fathi Boudra [EMAIL PROTECTED] libicecc-dev (U) Ludovic Brenta [EMAIL PROTECTED] gnat-4.1-base (U) gnat-4.2-base (U) Marcus Brinkmann [EMAIL PROTECTED] gnumach (U) gnumach-dev (U) Paul Brossier [EMAIL PROTECTED] supercollider-dev Cyril Brulebois [EMAIL PROTECTED] etl-dev (U) Ross Burton [EMAIL PROTECTED] libxnee-dev Petr Cech [EMAIL PROTECTED] lde Hubert Chathi [EMAIL PROTECTED] gnustep-common (U) gnustep-make-ogo (U) Kanru Chen [EMAIL PROTECTED] libchewing3-data Patryk Cisek [EMAIL PROTECTED] kadu-dev Robert Collins [EMAIL PROTECTED] opensync-plugin-palm-dev (U) Arnaud Cornet [EMAIL PROTECTED] ratbox-services-common Nigel Croxon [EMAIL PROTECTED] gnu-efi Marco d'Itri [EMAIL PROTECTED] inn2-dev Joost Yervante Damad [EMAIL PROTECTED] libflake-dev (U) Terry Dawson [EMAIL PROTECTED] libhamlib-doc (U) Debian Berkeley DB Maintainers [EMAIL PROTECTED] libdb4.6-dbg Debian EMBOSS Packaging Team [EMAIL PROTECTED] libajax5-dev libnucleus5-dev Debian GCC Maintainers [EMAIL PROTECTED] gcc-3.3-base gcc-3.4-base gcc-4.1-base gcc-4.2-base gcj-4.1-base gcj-4.2-base gnat-4.1-base gnat-4.2-base libgcj-common Debian GNOME Maintainers [EMAIL PROTECTED] system-tools-backends-dev (U) Debian GNUstep maintainers [EMAIL PROTECTED] gnustep-common gnustep-make-ogo Debian Install System Team [EMAIL PROTECTED] busybox-static debian-installer libdiscover1-pic os-prober Debian Java Maintainers [EMAIL PROTECTED] libantlr-dev Debian JED Group [EMAIL PROTECTED] slang-tess Debian KDE Extras Team [EMAIL PROTECTED] libicecc-dev Debian Kernel Team [EMAIL PROTECTED] linux-headers-2.6.23-1-common linux-headers-2.6.23-1-common-xen linux-libc-dev Debian multimedia packages maintainers [EMAIL PROTECTED] libdts-dev libdvb-dev liblivemedia-dev Debian Multimedia Team [EMAIL PROTECTED] libflake-dev Debian OpenOffice Team [EMAIL PROTECTED] libmythes-dev openoffice.org-dbg Debian Qt/KDE Maintainers [EMAIL PROTECTED] libqt3-headers Debian Ruby Extras Maintainers [EMAIL PROTECTED] libdaemons-ruby1.8 (U) Debian Scientific Computing Team [EMAIL PROTECTED] libnetgen-dev Debian Synfig Maintainers [EMAIL PROTECTED] etl-dev Debian TeX Maintainers [EMAIL PROTECTED] texlive-base-bin-doc texlive-metapost-doc Debian VDR Team [EMAIL PROTECTED] libmdsp-dev Debian VoIP Team [EMAIL PROTECTED] libsrtp1-dev Debian Xfce Maintainers [EMAIL PROTECTED] xfce4-dev-tools XCB Developers [EMAIL PROTECTED] libpthread-stubs0 Scott M. Dier [EMAIL PROTECTED] libbitcollider-dev Yann Dirson [EMAIL PROTECTED] memtest86 memtest86+ Sebastian Dröge [EMAIL PROTECTED] libavahi-common-data (U) vala-doc (U) Paul Dwerryhouse [EMAIL PROTECTED] kannel-dev Dirk Eddelbuettel [EMAIL PROTECTED] libtclap-dev
Re: List of packages which should probably be Architecture: all
Raphael Geissert schrieb: Just to clarify to everybody, the list was screwed up by dd-list (my bad, didn't see the '-b' option part). Thanks to Adeodato for pointing that out. So, here's the list of binary packages (attachment is dd-list -u again). Michael Biebl [EMAIL PROTECTED] tracker-dbg Currently tracker-dbg holds the debugging symbols for the binary packages: tracker, tracker-search-tool, libtrackerclient0 and libtracker-gtk0. I didn't want to bloat the archive unnecessarily and add a separate -dbg package for each binary package. Now, adding a Depends on all those 4 binary packages in tracker-dbg seems wrong to me. I don't want to force people to install tracker-search-tool if they only want to debug tracker. I guess this is a quite common problem. So, what's the proper solution to that? Cluttering the archive with a load of -dbg packages or leave it as is? Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Re: List of packages which should probably be Architecture: all
On 02/01/2008, Michael Biebl wrote: Now, adding a Depends on all those 4 binary packages in tracker-dbg seems wrong to me. I don't want to force people to install tracker-search-tool if they only want to debug tracker. What about being a bit more subtle and play around with Recommends: (or maybe even Suggests:)? By using e.g. Recommends: you ensure every package is installed in the normal/default/whatever_you_call_it case, but still leave the possibility to the user to only install what s/he really needs. Cheers, -- Cyril Brulebois pgpizM98FJIqT.pgp Description: PGP signature
Re: List of packages which should probably be Architecture: all
On Wed, Jan 02, 2008 at 10:18:46PM +0100, Michael Biebl wrote: So, what's the proper solution to that? Cluttering the archive with a load of -dbg packages or leave it as is? The solution I took for the Vim packages was to have ORed Depends on all of the binary packages that the -dbg package contains debugging symbols for. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Debian-AI
I startet building Debian packages about 10 years ago and in no single case I had the impression that this process could be done automatically. You might be lucky if you try to package some kind of standardized archives like CTAN or CPAN, but I doubt that this is possible if you are picking random FOSS from the net. Though it would be nice, I do not pretend to be able to automatically package software to the Debian archive quality standards. However, I do have tools that expedite the semi-automatic creation of rough quality packages (see Packager [0]), and believe that certain tasks in the package creation process can be completely automated to a high success rate (especially when more AI systems are integrated part of the available tool chain, and the large archive of source packages and their upstream sources is used as a training and testing data source). I am using debaux to completely automatically package Perl modules, and for every package in CPAN would like to attempt to create a rough quality package. [0] http://frdcsa.onshore.net/frdcsa/internal/packager/ Would there be any interest in a Debian-AI sub-project? It sounds like you should think about joining the Custom Debian Distribution effort: http://wiki.debian.org/CustomDebian http://people.debian.org/~tille/cdd/ If you are using the CDD tools you could gain some profit for your users by technically grouping set of packages to takss. We have also automatic tools to document what we just have inside official Debian and what is on our todo list like for instance http://debian-med.alioth.debian.org/tasks/bio.php (Please note that the later URL is just a preview of the web tools that are currently developed and once they are bug free there will be an official announcement. It's just to give you an idea of the profit you might have if you are building an official CDD.) I am definitely interested in the CDDs, and think the Comprehensive Software Ontology (CSO) (which should have formal representation of software capabilities), along with a tool I am working on for generating custom distributions based on required capabilities, would help with that effort. Kind regards and good luck for your project Andreas. -- http://fam-tille.de Slainte, Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
On Wednesday 02 January 2008 22:18, Michael Biebl wrote:
Raphael Geissert schrieb:
Michael Biebl [EMAIL PROTECTED]
tracker-dbg
Currently tracker-dbg holds the debugging symbols for the binary
packages: tracker, tracker-search-tool, libtrackerclient0 and
libtracker-gtk0.
I didn't want to bloat the archive unnecessarily and add a separate -dbg
package for each binary package.
Now, adding a Depends on all those 4 binary packages in tracker-dbg
seems wrong to me. I don't want to force people to install
tracker-search-tool if they only want to debug tracker.
I guess this is a quite common problem.
So, what's the proper solution to that? Cluttering the archive with a
load of -dbg packages or leave it as is?
How about using alternative dependencies:
Package: tracker-dbg
Depends: tracker (= ${binary:Version}) |
tracker-search-tool (= ${binary:Version}) |
libtrackerclient0 (= ${binary:Version}) |
libtracker-gtk0 (= ${binary:Version})
Cheers,
--
Frank S. Thomas [EMAIL PROTECTED] PGP public key ID: 0xDC426429
Debian Developerfinger fst/[EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part.
Re: Faster shutdown and the ubuntu multiuser update-rc.d extention
Petter Reinholdtsen wrote: Did you ever curse that Debian took so long to shut down, waiting for all the shutdown scripts to complete before the machine was ready to move? Here is a simple recipe to help making sure your package do not slow down the shutdown. Most of the init.d scripts are simple scripts that during shutdown kill the process they started during boot. But the default halt (0) and reboot (6) shutdown sequences will kill all processes on their own (in the sendsigs script), so there is normally no need for individual packages and init.d scripts to run at shutdown if all they need to do is to kill a daemon. There might be exceptions, for example if the daemons need to stop in a given order, but that do not seem to be the case for most packages. Are the five seconds that sendsigs waits between TERM and KILL enough to cleanly shutdown *all* running services at the same time? -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Faster shutdown and the ubuntu multiuser update-rc.d extention
Felipe Sateler [EMAIL PROTECTED] writes: Petter Reinholdtsen wrote: Did you ever curse that Debian took so long to shut down, waiting for all the shutdown scripts to complete before the machine was ready to move? Here is a simple recipe to help making sure your package do not slow down the shutdown. Most of the init.d scripts are simple scripts that during shutdown kill the process they started during boot. But the default halt (0) and reboot (6) shutdown sequences will kill all processes on their own (in the sendsigs script), so there is normally no need for individual packages and init.d scripts to run at shutdown if all they need to do is to kill a daemon. There might be exceptions, for example if the daemons need to stop in a given order, but that do not seem to be the case for most packages. Are the five seconds that sendsigs waits between TERM and KILL enough to cleanly shutdown *all* running services at the same time? On a heavily loaded or slow system, I suspect it would be highly likely some would get SIGKILL before they could shut down properly. I can't say I'm a big fan of the proposal for this reason. With a better init, like upstart, or a dependency-based init, there's no reason why scripts can't be run in parallel. But, simply sending everything a TERM and KILL doesn't seem do be very clean in my understanding. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. pgpitrNKlMwSF.pgp Description: PGP signature
Re: some packges are waiting for i386 build
On Wed, Jan 02, 2008 at 09:09:51PM +, Roger Leigh wrote: This is only a problem with the old version of sbuild in use on the buildds. The version in unstable has used the apt inside the chroot for well over two years. The patches to enable it do exist in the GIT repo, and could be trivially ported to the sbuild in use on the buildds. In fact, the unstable sbuild even has an --arch option to specify the build architecture, and will select the appropriate chroot accordingly. It's not a bug, it's a feature. The official buildds use the stable apt by design. See e.g. #452858, which would've hit the buildds hard. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
Hi, On Wed, 2008-01-02 at 16:32:48 -0500, James Vega wrote: On Wed, Jan 02, 2008 at 02:17:08PM -0600, Raphael Geissert wrote: Parts of it are pretty ugly (and the Packages-fetching part isn't there), but I'm attaching it anyway. Tying together grep-dctrl and dd-list would probably be a cleaner approach. I haven't done a thorough comparison to your list but the results seem to be pretty similar. $ grep-dctrl ! -FDepends -e '.' -a ! -FPre-Depends -e '.' \ -a ! -FArchitecture all -n -sPackage binary-i386_Packages | dd-list -i -u -b Guillem Jover [EMAIL PROTECTED] gnumach (U) A kernel image (false positive). gnumach-dev (U) Arch specific header files (false positive). libaio1 Syscall stubs, does not use glibc (false positive, has already a shared-lib-without-dependency-information lintian override). regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458811: ITP: mgltools -- preparation of proteins and ligands to analyse their binding
Package: wnpp Severity: wishlist Owner: Steffen Moeller [EMAIL PROTECTED] * Package name: mgltools Version : 1.5.0 * URL : http://mgltools.scripps.edu * License : various custom non-free, mostly academia-only Programming Lang: Python Description : preparation of proteins and ligands to investigate their binding The package comprises AutoDockTools, Python Molecular Viewer, Vision and many helping smaller python libraries which shall all become available as Debian packages ... if their license permits. The essential mslib library for instance comes with binaries which should not go into Debian. The analysis itself is performed with AutoDock, which was recently made available under the GPL. Upstream is very supportive but their binary-only libraries are of a third party. This set of tools is well known across biochemistry and computational/structural biology. This ITP should be out and then we will see how to compromise for something that might fit into Debian. The current state of the packaging effort can be inspected in the Debian-Med svn repository at http://svn.debian.org/wsvn/debian-med/trunk/packages/mgltools/?rev=0sc=0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
Raphael == Raphael Geissert [EMAIL PROTECTED] writes: Raphael Brian May [EMAIL PROTECTED] Raphael dar-static Raphael Theodore Y. Ts'o [EMAIL PROTECTED] Raphael e2fsck-static Both of these (and maybe others) are false positives. -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Faster shutdown and the ubuntu multiuser update-rc.d extention
On Wed, Jan 02, 2008 at 12:47:12PM -0800, Russ Allbery wrote: Right. The only case where a shutdown script makes sense to me is if it's doing something other than sending signals or if it's waiting (intelligently, not just blindly for five seconds) for the process to shut down cleanly. So the only question is how many scripts _should_ wait but currently get away without waiting because the shutdown sequence takes so long. IMHO if a daemon does not write anything to disk except maybe log messages then it should be fine without a shutdown script, but everything else should have one. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Faster shutdown and the ubuntu multiuser update-rc.d extention
On Wed, Jan 02, 2008 at 10:31:33PM +, Roger Leigh wrote: Felipe Sateler [EMAIL PROTECTED] writes: Are the five seconds that sendsigs waits between TERM and KILL enough to cleanly shutdown *all* running services at the same time? On a heavily loaded or slow system, I suspect it would be highly likely some would get SIGKILL before they could shut down properly. I can't say I'm a big fan of the proposal for this reason. If this is a real problem for a given service, surely its init script should actually wait for the process to shut down cleanly? If so, it wouldn't be a candidate for this refactoring. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458819: ITP: nettee -- a network tee program
Package: wnpp Severity: wishlist Owner: Joel Franco [EMAIL PROTECTED] * Package name: nettee Version : 0.1.8 Upstream Author : David Mathog [EMAIL PROTECTED] * URL : http://saf.bio.caltech.edu/nettee.html * License : GPL Programming Lang: C Description : a network tee program It can typically transfer data between N nodes at (nearly) the full bandwidth provided by the switch which connects them. It is handy for cloning nodes or moving large database files. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.23.11 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to pt_BR.UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Opinions needed: reporting lintian overrides
After a recent problem with a package with a fairly egregious error that was overridden, hurting the ability of the sponsor to notice it, I added a line of output to the default lintian output saying if any package overrides error or warning tags. As I sort of suspected at the time, someone else has now objected to having this output by default on the grounds that the point of the override was to shut lintian up and it's easier to verify that lintian produces no output. I'd really like to not have to make this decision myself. I'd like to get opinions and see if a consensus emerges. I personally always run lintian with -iI --show-overrides, so I'm clearly not the target audience for this feature one way or the other. Here are the options: * Show the N: line with a count of overrides per package by default and provide an option to suppress this output if someone wants. * Don't show the N: line by default and provide an option to turn it on. Which should we do? Separately, I'm working on adding lintian overrides to the lintian.d.o pages to make it easier to see how people are using overrides across the whole archive. It looks like people sometimes just add an override when lintian makes a mistake rather than filing a bug, so this gives us a fighting chance of finding those bugs and fixing them. It also uncovers some fascinating overrides currently in the archive. Oh, and there are 1759 unused overrides in the archive in 369 packages. lintian -i will tell you about unused overrides. We do fix false-positive bugs! -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Opinions needed: reporting lintian overrides
Russ Allbery [EMAIL PROTECTED] writes: Oh, and there are 1759 unused overrides in the archive in 369 packages. lintian -i will tell you about unused overrides. We do fix false-positive bugs! lintian -I, rather. (Display info tags.) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Opinions needed: reporting lintian overrides
Hi Russ Russ Allbery wrote: I'd really like to not have to make this decision myself. I'd like to get opinions and see if a consensus emerges. I personally always run lintian with -iI --show-overrides, so I'm clearly not the target audience for this feature one way or the other. Here are the options: * Show the N: line with a count of overrides per package by default and provide an option to suppress this output if someone wants. * Don't show the N: line by default and provide an option to turn it on. Which should we do? We should show the N: line by default and have an option to suppress the output. Separately, I'm working on adding lintian overrides to the lintian.d.o pages to make it easier to see how people are using overrides across the whole archive. It looks like people sometimes just add an override when lintian makes a mistake rather than filing a bug, so this gives us a fighting chance of finding those bugs and fixing them. It also uncovers some fascinating overrides currently in the archive. Great! Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Opinions needed: reporting lintian overrides
On Wed, 2008-01-02 at 22:30 -0800, Russ Allbery wrote: After a recent problem with a package with a fairly egregious error that was overridden, hurting the ability of the sponsor to notice it, I added a line of output to the default lintian output saying if any package overrides error or warning tags. As I sort of suspected at the time, someone else has now objected to having this output by default on the grounds that the point of the override was to shut lintian up and it's easier to verify that lintian produces no output. I'd really like to not have to make this decision myself. I'd like to get opinions and see if a consensus emerges. I prefer that lintian messages are silently overridden. I personally always run lintian with -iI --show-overrides, so I'm clearly not the target audience for this feature one way or the other. Here are the options: * Show the N: line with a count of overrides per package by default and provide an option to suppress this output if someone wants. * Don't show the N: line by default and provide an option to turn it on. Which should we do? I prefer the second option. Regards, Bart Martens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Opinions needed: reporting lintian overrides
On Thu, 03 Jan 2008, Luk Claes wrote: * Show the N: line with a count of overrides per package by default and provide an option to suppress this output if someone wants. * Don't show the N: line by default and provide an option to turn it on. Which should we do? We should show the N: line by default and have an option to suppress the output. I agree. Although I think that it would be better if there could be a single line indicating overrides on everything that got scanned by lintian. Currently on dpkg I have 4 N: lines: one per deb + one for the .dsc. That clutters the output a bit too much to my taste. And ideally it should be at the end of the output (or at the beginning) but not spread in the output. 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: Opinions needed: reporting lintian overrides
Raphael Hertzog [EMAIL PROTECTED] writes: I agree. Although I think that it would be better if there could be a single line indicating overrides on everything that got scanned by lintian. Hm, that's another option. That's kind of hard to do with the current lintian architecture, I think, since I think we may reset all the tag counts between packages, but I may be wrong. Currently on dpkg I have 4 N: lines: one per deb + one for the .dsc. That clutters the output a bit too much to my taste. And ideally it should be at the end of the output (or at the beginning) but not spread in the output. I was going to ask: why does dpkg have (and override lintian warnings for) Bugs and Origin fields? It's the only package in the archive with those fields set to their default values. redundant-bugs-field (0 packages, 0 tags, plus 3 overrides) redundant-origin-field (0 packages, 0 tags, plus 4 overrides) windlord:~ lintian-info -t redundant-bugs-field redundant-origin-field N: redundant-bugs-field N: N: You use the Bugs field though the field value is the default N: (debbugs://bugs.debian.org/). In this case the field is redundant and N: should be removed. N: N: redundant-origin-field N: N: You use the Origin field though the field value is the default N: (Debian). In this case the field is redundant and should be removed. N: -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Parallel build results
Hi, On Wed, 2008-01-02 at 14:23:01 +0100, Lucas Nussbaum wrote: On 01/01/08 at 18:23 -0800, Russ Allbery wrote: Aurelien Jarno [EMAIL PROTECTED] writes: On the other hand, DEB_BUILD_OPTIONS=parallel=n was ignored by packages that have not been validated by the maintainers, and used by packages that have been tested by the maintainer. Also it was possible to use only on some parts of the build. For example the make install part is sometimes problematic, and mainly depends on I/O throughput of the machine, and not CPU. This make some problems difficult to detect, as they happen only in rare case on some machines. Well on my part I think I've made all my packages to properly build in parallel but didn't add the explicit parsing on the rules file. Unfortunately dpkg-buildpackage now looks for DEB_BUILD_OPTIONS and call debian/rules with -j and the value it founds in this environment variable. That makes DEB_BUILD_OPTIONS=parallel=n useless, as it has the same effect as dpkg-buildpackage -j. No, there's build systems out there that are not make based, those would still need to parse DEB_BUILD_OPTIONS and activate parallelism if supported by those systems. I personally think that supporting DEB_BUILD_OPTIONS=parallel=n on some packages is a first goal to achieve. Supporting this option in the 100 packages which take the longest to build would probably be a huge improvement in build time of the whole archive, while being easier than fixing all the packages in the archive. I agree with this analysis. I think the MAKEFLAGS setting in dpkg-buildpackage should be removed and instead calling dpkg-buildpackage with the -j option should just set the parallel=n flag in DEB_BUILD_OPTIONS. From there, we can leave it to package maintainers to decide how to implement this. I filed bug #458589 against dpkg-dev about this. I think that both following solutions are fine: - dpkg-buildpackage must not consider DEB_BUILD_OPTIONS=parallel=n as the same thing as calling dpkg-buildpackage -j n. Ok, I've just commited a change for dpkg-buildpackage not to automatically behave as if -j had been passed as argument if DEB_BUILD_OPTIONS contains parallel=n. - dpkg-buildpackage -j must not set MAKEFLAGS. But if this is choosen, dpkg-buildpackage -j will simply become another way of doing 'export DEB_BUILD_OPTIONS=parallel=n'. Is it really worth keeping in this case? If someone *really* wants to try forcing make to do a parallel build, they can always set MAKEFLAGS themselves directly. True ; maybe dpkg-buildpackage -j is completely useless, actually. It's as useless as dpkg-buildpackage itself, you can also directly call debian/rules ... regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Opinions needed: reporting lintian overrides
On Wed, 02 Jan 2008 22:30:09 -0800 Russ Allbery [EMAIL PROTECTED] wrote: After a recent problem with a package with a fairly egregious error that was overridden, hurting the ability of the sponsor to notice it, I added a line of output to the default lintian output saying if any package overrides error or warning tags. I'd really like to not have to make this decision myself. I'd like to get opinions and see if a consensus emerges. I personally always run lintian with -iI --show-overrides, so I'm clearly not the target audience for this feature one way or the other. As a sponsor, I'd rather have lintian silent on overrides by default and use an alias to show overrides in my shell. That allows me to have silent output in pbuilder builds and obvious override notices in other builds. Here are the options: * Show the N: line with a count of overrides per package by default and provide an option to suppress this output if someone wants. * Don't show the N: line by default and provide an option to turn it on. Second option would be my choice. Separately, I'm working on adding lintian overrides to the lintian.d.o pages to make it easier to see how people are using overrides across the whole archive. It looks like people sometimes just add an override when lintian makes a mistake rather than filing a bug, so this gives us a fighting chance of finding those bugs and fixing them. It also uncovers some fascinating overrides currently in the archive. That would be extremely useful - thank you. Oh, and there are 1759 unused overrides in the archive in 369 packages. lintian -i will tell you about unused overrides. We do fix false-positive bugs! Having an alias to show overrides would make it easier to spot those too. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpT2RKMd4AzJ.pgp Description: PGP signature
Re: Opinions needed: reporting lintian overrides
On Wed, 02 Jan 2008, Russ Allbery wrote: Currently on dpkg I have 4 N: lines: one per deb + one for the .dsc. That clutters the output a bit too much to my taste. And ideally it should be at the end of the output (or at the beginning) but not spread in the output. I was going to ask: why does dpkg have (and override lintian warnings for) Bugs and Origin fields? It's the only package in the archive with those fields set to their default values. redundant-bugs-field (0 packages, 0 tags, plus 3 overrides) redundant-origin-field (0 packages, 0 tags, plus 4 overrides) Hum... I don't know. It looks like it got added by Wichert Akkerman in 2000: * Add Origin and Bugs fields to the control file And the lintian overrides got added by Guillem last year. 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: Opinions needed: reporting lintian overrides
On Wed, 2 Jan 2008, Russ Allbery wrote: After a recent problem with a package with a fairly egregious error that was overridden, hurting the ability of the sponsor to notice it, I added a line of output to the default lintian output saying if any package overrides error or warning tags. What about a summary line: lintian detected: x_e errors, x_w warnings, o_e errors and o_w warnings were overridden (in case o_e and o_w are different from 0). Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted geda-gschem 1:1.2.1-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 02 Jan 2008 18:38:29 +1100 Source: geda-gschem Binary: geda-gschem Architecture: source amd64 Version: 1:1.2.1-1 Distribution: unstable Urgency: low Maintainer: Debian Electronics Team [EMAIL PROTECTED] Changed-By: Hamish Moffatt [EMAIL PROTECTED] Description: geda-gschem - GPL EDA -- Electronics design software -- schematic editor Changes: geda-gschem (1:1.2.1-1) unstable; urgency=low . * New upstream release Files: 595c5baccfc4647df799dcaa7344f104 811 electronics optional geda-gschem_1.2.1-1.dsc d5f126617e9de11b8164e823d1e7f126 1120291 electronics optional geda-gschem_1.2.1.orig.tar.gz 9e8b62fff86921a7e9a7b45f378d6872 3463 electronics optional geda-gschem_1.2.1-1.diff.gz ff74b12a6c09f1eb4e026ed70d7d73e9 359748 electronics optional geda-gschem_1.2.1-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHez/M30WoBV0H6VwRAgpDAJ9w8dWlkj1m36DAcyaZyXc8GhKE1wCgganb wYOH/ie6f8COK+1veS1zbME= =xReZ -END PGP SIGNATURE- Accepted: geda-gschem_1.2.1-1.diff.gz to pool/main/g/geda-gschem/geda-gschem_1.2.1-1.diff.gz geda-gschem_1.2.1-1.dsc to pool/main/g/geda-gschem/geda-gschem_1.2.1-1.dsc geda-gschem_1.2.1-1_amd64.deb to pool/main/g/geda-gschem/geda-gschem_1.2.1-1_amd64.deb geda-gschem_1.2.1.orig.tar.gz to pool/main/g/geda-gschem/geda-gschem_1.2.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted geda-symbols 1:1.2.1-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 01 Jan 2008 16:21:10 +1100 Source: geda-symbols Binary: geda-symbols Architecture: source all Version: 1:1.2.1-1 Distribution: unstable Urgency: low Maintainer: Debian Electronics Team [EMAIL PROTECTED] Changed-By: Hamish Moffatt [EMAIL PROTECTED] Description: geda-symbols - Symbols for GPL EDA -- Electronics design software Changes: geda-symbols (1:1.2.1-1) unstable; urgency=low . * New upstream release Files: ccfa319242566b68560f14a852c8cbb0 763 electronics optional geda-symbols_1.2.1-1.dsc 5da85fcbe1f0b83eaf6120a5307b9b67 829621 electronics optional geda-symbols_1.2.1.orig.tar.gz 283ce8ebc30f9ad5213cde635c8e1805 2486 electronics optional geda-symbols_1.2.1-1.diff.gz 80fde648815ae9e768cec3a9adb7e2e2 515142 electronics optional geda-symbols_1.2.1-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHec5F30WoBV0H6VwRAr6JAJ9vW3RZ5lHJcyDrM+CjPg/gHq5FrgCdGLH1 vTjEzSSoPrbC8Cutq4r5/j0= =WRcw -END PGP SIGNATURE- Accepted: geda-symbols_1.2.1-1.diff.gz to pool/main/g/geda-symbols/geda-symbols_1.2.1-1.diff.gz geda-symbols_1.2.1-1.dsc to pool/main/g/geda-symbols/geda-symbols_1.2.1-1.dsc geda-symbols_1.2.1-1_all.deb to pool/main/g/geda-symbols/geda-symbols_1.2.1-1_all.deb geda-symbols_1.2.1.orig.tar.gz to pool/main/g/geda-symbols/geda-symbols_1.2.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted geda-gsymcheck 1:1.2.1-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 02 Jan 2008 18:44:56 +1100 Source: geda-gsymcheck Binary: geda-gsymcheck Architecture: source amd64 Version: 1:1.2.1-1 Distribution: unstable Urgency: low Maintainer: Debian Electronics Team [EMAIL PROTECTED] Changed-By: Hamish Moffatt [EMAIL PROTECTED] Description: geda-gsymcheck - GPL EDA -- Electronics design software -- symbol checker Changes: geda-gsymcheck (1:1.2.1-1) unstable; urgency=low . * New upstream release Files: 6e69b2dc2134a0760749dae242c4000e 791 electronics optional geda-gsymcheck_1.2.1-1.dsc b25ef3580fb5dd649cb1316ca82d3557 163810 electronics optional geda-gsymcheck_1.2.1.orig.tar.gz 43996b2941519578c0fe9e8b517c0def 2737 electronics optional geda-gsymcheck_1.2.1-1.diff.gz 2925b38fdd9538fd01ffa8d1116a46c1 22886 electronics optional geda-gsymcheck_1.2.1-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHe0Ef30WoBV0H6VwRAgtUAJwPWEQBdgRz/nHQLIBzVBN7zfjVTACfXPWz 9xDqcFfl4YqtWdrCyw1ceRM= =ab72 -END PGP SIGNATURE- Accepted: geda-gsymcheck_1.2.1-1.diff.gz to pool/main/g/geda-gsymcheck/geda-gsymcheck_1.2.1-1.diff.gz geda-gsymcheck_1.2.1-1.dsc to pool/main/g/geda-gsymcheck/geda-gsymcheck_1.2.1-1.dsc geda-gsymcheck_1.2.1-1_amd64.deb to pool/main/g/geda-gsymcheck/geda-gsymcheck_1.2.1-1_amd64.deb geda-gsymcheck_1.2.1.orig.tar.gz to pool/main/g/geda-gsymcheck/geda-gsymcheck_1.2.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted geda-gnetlist 1:1.2.1-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 02 Jan 2008 18:43:57 +1100 Source: geda-gnetlist Binary: geda-gnetlist Architecture: source amd64 Version: 1:1.2.1-1 Distribution: unstable Urgency: low Maintainer: Debian Electronics Team [EMAIL PROTECTED] Changed-By: Hamish Moffatt [EMAIL PROTECTED] Description: geda-gnetlist - GPL EDA -- Electronics design software -- netlister Changes: geda-gnetlist (1:1.2.1-1) unstable; urgency=low . * New upstream release Files: c35a7f2560550eaaea64024261ad88ca 787 electronics optional geda-gnetlist_1.2.1-1.dsc 7052134d8977d87277c83fd57390fb5e 398180 electronics optional geda-gnetlist_1.2.1.orig.tar.gz 8e00a5935e0c1d13f447cb24d4d87a74 3208 electronics optional geda-gnetlist_1.2.1-1.diff.gz 47431813e617bfbd019a8f42e5cd4164 171314 electronics optional geda-gnetlist_1.2.1-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHe0Dy30WoBV0H6VwRAtSZAKCJVACVw6dECgJgU3rSKvNgJCXP6ACg0qUb 458cFO3ohe8e4smkyKMLJho= =L//T -END PGP SIGNATURE- Accepted: geda-gnetlist_1.2.1-1.diff.gz to pool/main/g/geda-gnetlist/geda-gnetlist_1.2.1-1.diff.gz geda-gnetlist_1.2.1-1.dsc to pool/main/g/geda-gnetlist/geda-gnetlist_1.2.1-1.dsc geda-gnetlist_1.2.1-1_amd64.deb to pool/main/g/geda-gnetlist/geda-gnetlist_1.2.1-1_amd64.deb geda-gnetlist_1.2.1.orig.tar.gz to pool/main/g/geda-gnetlist/geda-gnetlist_1.2.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted geda-utils 1:1.2.1-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 02 Jan 2008 18:46:12 +1100 Source: geda-utils Binary: geda-utils Architecture: source amd64 Version: 1:1.2.1-1 Distribution: unstable Urgency: low Maintainer: Debian Electronics Team [EMAIL PROTECTED] Changed-By: Hamish Moffatt [EMAIL PROTECTED] Description: geda-utils - GPL EDA -- Electronics design software -- utilities Changes: geda-utils (1:1.2.1-1) unstable; urgency=low . * New upstream release Files: ef0543723793038fd1a24cfb4b660f07 784 electronics optional geda-utils_1.2.1-1.dsc d51953d8091a8b2fdfefa3df1a8a5cb9 319966 electronics optional geda-utils_1.2.1.orig.tar.gz 651ba497be2ad8609857381648ead8ba 2788 electronics optional geda-utils_1.2.1-1.diff.gz c9d7c2e41de4f070380d60f07d1aec86 119718 electronics optional geda-utils_1.2.1-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHe0Fz30WoBV0H6VwRAhF/AKCAr/A1tkepicgrn8ReAFUKASs/OgCgqTYE ncKFX/vNKgd3fXTYbZZavy8= =bRc9 -END PGP SIGNATURE- Accepted: geda-utils_1.2.1-1.diff.gz to pool/main/g/geda-utils/geda-utils_1.2.1-1.diff.gz geda-utils_1.2.1-1.dsc to pool/main/g/geda-utils/geda-utils_1.2.1-1.dsc geda-utils_1.2.1-1_amd64.deb to pool/main/g/geda-utils/geda-utils_1.2.1-1_amd64.deb geda-utils_1.2.1.orig.tar.gz to pool/main/g/geda-utils/geda-utils_1.2.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted geda-examples 1:1.2.1-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 02 Jan 2008 18:41:34 +1100 Source: geda-examples Binary: geda-examples Architecture: source all Version: 1:1.2.1-1 Distribution: unstable Urgency: low Maintainer: Debian Electronics Team [EMAIL PROTECTED] Changed-By: Hamish Moffatt [EMAIL PROTECTED] Description: geda-examples - GPL EDA -- Electronics design software -- example designs Changes: geda-examples (1:1.2.1-1) unstable; urgency=low . * New upstream release Files: 9f8fc23f81c8e2c3ab7ea19438a1a34e 739 electronics optional geda-examples_1.2.1-1.dsc b830216c15a1c53253768876f45bbbce 255794 electronics optional geda-examples_1.2.1.orig.tar.gz 0b5308732c592552e9486fb5aeee54e9 1891 electronics optional geda-examples_1.2.1-1.diff.gz 8ed3f12f703659cd3e5fb756b08a 185522 electronics optional geda-examples_1.2.1-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHe0BG30WoBV0H6VwRAhIKAJ9daFe9yZykUh3qsCniR2IHC0iu+ACePvFK I5WsMyfWyP2bApxwGSRb6RA= =AMHs -END PGP SIGNATURE- Accepted: geda-examples_1.2.1-1.diff.gz to pool/main/g/geda-examples/geda-examples_1.2.1-1.diff.gz geda-examples_1.2.1-1.dsc to pool/main/g/geda-examples/geda-examples_1.2.1-1.dsc geda-examples_1.2.1-1_all.deb to pool/main/g/geda-examples/geda-examples_1.2.1-1_all.deb geda-examples_1.2.1.orig.tar.gz to pool/main/g/geda-examples/geda-examples_1.2.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libgeda 1:1.2.1-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 02 Jan 2008 18:33:42 +1100 Source: libgeda Binary: libgeda-common libgeda31 libgeda-dev Architecture: source amd64 all Version: 1:1.2.1-1 Distribution: unstable Urgency: low Maintainer: Debian Electronics Team [EMAIL PROTECTED] Changed-By: Hamish Moffatt [EMAIL PROTECTED] Description: libgeda-common - GPL EDA -- Electronics design software -- data files libgeda-dev - GPL EDA -- Electronics design software -- development files libgeda31 - GPL EDA -- Electronics design software -- library files Changes: libgeda (1:1.2.1-1) unstable; urgency=low . * New upstream release Files: 26c15a2f7103a30623e84d6d8b06c16d 773 electronics optional libgeda_1.2.1-1.dsc 154d219540de33694e1db67e3525b8b6 675896 electronics optional libgeda_1.2.1.orig.tar.gz 60ce7c28b3e14a76aea300521239b19c 5206 electronics optional libgeda_1.2.1-1.diff.gz 471c4705399601e0d6146eacb4b05f15 23138 electronics optional libgeda-common_1.2.1-1_all.deb 93e8bddc587be7d02f4f4717ba053521 162472 electronics optional libgeda31_1.2.1-1_amd64.deb 9a408df59a5b48bbee3926e3f0b01d4d 22864 libdevel optional libgeda-dev_1.2.1-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHez7330WoBV0H6VwRAlfoAKCc009DPsMLslrGgVMEFY0QqmEHawCcDNVs QOCZkzmYcCq56sT6ZwUHMew= =YEZj -END PGP SIGNATURE- Accepted: libgeda-common_1.2.1-1_all.deb to pool/main/libg/libgeda/libgeda-common_1.2.1-1_all.deb libgeda-dev_1.2.1-1_amd64.deb to pool/main/libg/libgeda/libgeda-dev_1.2.1-1_amd64.deb libgeda31_1.2.1-1_amd64.deb to pool/main/libg/libgeda/libgeda31_1.2.1-1_amd64.deb libgeda_1.2.1-1.diff.gz to pool/main/libg/libgeda/libgeda_1.2.1-1.diff.gz libgeda_1.2.1-1.dsc to pool/main/libg/libgeda/libgeda_1.2.1-1.dsc libgeda_1.2.1.orig.tar.gz to pool/main/libg/libgeda/libgeda_1.2.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted geda-doc 1:1.2.1-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 02 Jan 2008 18:35:48 +1100 Source: geda-doc Binary: geda-doc Architecture: source all Version: 1:1.2.1-1 Distribution: unstable Urgency: low Maintainer: Debian Electronics Team [EMAIL PROTECTED] Changed-By: Hamish Moffatt [EMAIL PROTECTED] Description: geda-doc - Documentation for GPL EDA -- Electronics design software Changes: geda-doc (1:1.2.1-1) unstable; urgency=low . * New upstream release Files: bd52add8c088eae8423eab7325681ea5 720 doc optional geda-doc_1.2.1-1.dsc b49eb081bb47be8f6f2aee393e1786da 1815441 doc optional geda-doc_1.2.1.orig.tar.gz b4abc7cec400aae366bbc17a1fe3f335 2171 doc optional geda-doc_1.2.1-1.diff.gz e7b16dd4396e46720eae3bad57d02ea0 1716488 doc optional geda-doc_1.2.1-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHez7530WoBV0H6VwRAsUoAJ9h/Uh0X6Gu0zLYWCZ7f3ylvs/McQCg6oFB Ui/EyVZgtgjMGpkmyqMJUYc= =KyLU -END PGP SIGNATURE- Accepted: geda-doc_1.2.1-1.diff.gz to pool/main/g/geda-doc/geda-doc_1.2.1-1.diff.gz geda-doc_1.2.1-1.dsc to pool/main/g/geda-doc/geda-doc_1.2.1-1.dsc geda-doc_1.2.1-1_all.deb to pool/main/g/geda-doc/geda-doc_1.2.1-1_all.deb geda-doc_1.2.1.orig.tar.gz to pool/main/g/geda-doc/geda-doc_1.2.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted geda-gattrib 1:1.2.1-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 02 Jan 2008 18:43:22 +1100 Source: geda-gattrib Binary: geda-gattrib Architecture: source amd64 Version: 1:1.2.1-1 Distribution: unstable Urgency: low Maintainer: Debian Electronics Team [EMAIL PROTECTED] Changed-By: Hamish Moffatt [EMAIL PROTECTED] Description: geda-gattrib - GPL EDA -- Electronics design software -- attribute editor Changes: geda-gattrib (1:1.2.1-1) unstable; urgency=low . * New upstream release Files: efa528f42c2921dce17f83957702cf24 791 electronics optional geda-gattrib_1.2.1-1.dsc e75efbe2e788ae09fd3a7c1c470e5fbe 290400 electronics optional geda-gattrib_1.2.1.orig.tar.gz 8b39a7a9d98ed5b79f8276b285d9e232 2405 electronics optional geda-gattrib_1.2.1-1.diff.gz 78fe438c32baefd9718b7aaec1aae38c 107180 electronics optional geda-gattrib_1.2.1-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHe0DM30WoBV0H6VwRAj3kAKCuqACITBNM43RPU9XEIkRwoqP3lQCeIMYV sEwFubxHMtPnXxGwLMRQuFs= =WhSR -END PGP SIGNATURE- Accepted: geda-gattrib_1.2.1-1.diff.gz to pool/main/g/geda-gattrib/geda-gattrib_1.2.1-1.diff.gz geda-gattrib_1.2.1-1.dsc to pool/main/g/geda-gattrib/geda-gattrib_1.2.1-1.dsc geda-gattrib_1.2.1-1_amd64.deb to pool/main/g/geda-gattrib/geda-gattrib_1.2.1-1_amd64.deb geda-gattrib_1.2.1.orig.tar.gz to pool/main/g/geda-gattrib/geda-gattrib_1.2.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
