Re: controle du contenu d'un paquet source
Quoting Frédéric BOITEUX ([EMAIL PROTECTED]): j'aimerais savoir comment faire pour ne pas les y retrouver. Comme le paquet est maintenu avec CVS, j'imagine qu'un « export » serait bien, mais je ne sais pas où mettre cette commande ? Ceci dans ~/.devscripts devrait aider: DEBUILD_DPKG_BUILDPACKAGE_OPTS=-i'(?:^|/).*~$|(?:^|/)\..*\.swp|DEADJOE|(?:/CVS|/RCS|/\.svn|/\.deps|\.\#.*)(?:$|/)' -ICVS -I.svn -uc -us (les -us et -uc permettent de ne pas avoir de demande de signature des .changes et .dsc, donc rien à voir avec le problème) PS : la ligne ci-dessus m'a elle-même été donnée par Petter Reinholdtsen. Je suis totalement incapable de faire des regexp aussi ampoulées et qui marchent...:-)
Re: controle du contenu d'un paquet source
Bonjour, Le Thu, 9 Dec 2004 06:59:05 +0100, Christian Perrier [EMAIL PROTECTED] a écrit : Ceci dans ~/.devscripts devrait aider: DEBUILD_DPKG_BUILDPACKAGE_OPTS=-i'(?:^|/).*~$|(?:^|/)\..*\.swp|DEADJOE|(?:/C VS|/RCS|/\.svn|/\.deps|\.\#.*)(?:$|/)' -ICVS -I.svn -uc -us (les -us et -uc permettent de ne pas avoir de demande de signature des .changes et .dsc, donc rien à voir avec le problème) Ok, j'avais qqchose de beaucoup plus simple qui ignorait simplement les CVS et .cvsignore, mais j'aurais voulu savoir s'il était possible de dire à « dpkg-source » d'utiliser le résultat d'un « cvs export » plutôt que le répertoire courant, mais bon j'ai l'impression que l'appel de dpkg-source dans dpkg-buildpackage ou debuild est verrouillé... Merci pour l'expression régulière (amusant de rechercher à quoi cela correspond...) Je me demande quel outil crée ce fameux 'DEADJOE' que l'on voit de temps en temps dans les outils Debian ? Fred.
Re: controle du contenu d'un paquet source
Le Thursday 09 December 2004 à 08:54:27, Frédéric BOITEUX a écrit: Ok, j'avais qqchose de beaucoup plus simple qui ignorait simplement les CVS et .cvsignore, mais j'aurais voulu savoir s'il était possible de dire à « dpkg-source » d'utiliser le résultat d'un « cvs export » plutôt que le répertoire courant, mais bon j'ai l'impression que l'appel de dpkg-source dans dpkg-buildpackage ou debuild est verrouillé... J'utilise cvs-buildpackage(1) « build Debian packages from a CVS repository » qui fait un export dans /usr/local/src/Packages/ pour construire le paquet. C'est quelque fois contraignant de devoir commiter une modification avant de pouvoir construire le paquet. Mais il suffit de patcher les fichiers exportés dans /usr/local/src/Packages/non_du_paquet/ et travailler sur la version de ce répertoire jusqu'à obtenir un paquet satisfaisant puis d'appliquer les modifications à la version contrôlée par CVS. Voir aussi le point 7 de [1]. À+ [1] http://www.debian.org/devel/cvs_packages -- Dr. Ludovic Rousseau[EMAIL PROTECTED] -- Normaliser Unix c'est comme pasteuriser le camembert, L.R. --
Re: SVG icons
On Wed, Dec 08, 2004 at 09:16:06PM -0600, Ron Johnson [EMAIL PROTECTED] wrote: Note that's a may and a should, not a must. IIRC they only trigger lintian warnings, not errors. If I tell my son, You may not go play in the rain., he knows that he can't go play in the rain. OT If you tell your som, You must not go play in the rain, it's the best way to be sure he'll be doing it ;) /OT Thus, may in this context is ambiguous. Should is only slightly less so. See RFC 2119. I think usages of may, should, must and stuff should follow these explanations. Mike
Re: SVG icons
On Thu, 2004-12-09 at 15:49 +0900, Mike Hommey wrote: On Wed, Dec 08, 2004 at 09:16:06PM -0600, Ron Johnson [EMAIL PROTECTED] wrote: Note that's a may and a should, not a must. IIRC they only trigger lintian warnings, not errors. If I tell my son, You may not go play in the rain., he knows that he can't go play in the rain. OT If you tell your som, You must not go play in the rain, it's the best way to be sure he'll be doing it ;) /OT The best way to be sure he'll *want* to do it. He knows the consequences of disobeying a direct order can be unpleasant. Thus, may in this context is ambiguous. Should is only slightly less so. See RFC 2119. I think usages of may, should, must and stuff should follow these explanations. There's an RFC for words??? -- - Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B I prefer encrypted mail. Clueless tech journalists drive geeks crazy signature.asc Description: This is a digitally signed message part
Re: Linux Core Consortium
On Wed, 2004-12-08 at 14:59 -0800, Bruce Perens wrote: The main technical effect that I see would be that the names of some dynamic libraries would change. And compatibility with the old names could be maintained indefinitely if necessary. ?!??!?!?!?!?!?!PO!(*!$*_(!$*($*!(*$_*!*$( That is all. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: SVG icons
On Thu, Dec 09, 2004 at 12:56:23AM -0600, Ron Johnson [EMAIL PROTECTED] wrote: See RFC 2119. I think usages of may, should, must and stuff should follow these explanations. There's an RFC for words??? Yes, there is one, to make sure everybody use the words for the same thing, especially when people in a project doesn't share the same mother tongue. For instance, mine is french, and distinction between may and should is sometimes awkward to me. Mike
Re: dpkg-reversion: how about debedit?
also sprach Mike Hommey [EMAIL PROTECTED] [2004.12.09.0359 +0100]: Sounds good. Could it be used for dh_striping the content of a package ? It is an unpacked DEB file, not a Debian source package, so I am not sure how much use the debhelper suite will be. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: dpkg-reversion: how about debedit?
On Thu, Dec 09, 2004 at 09:29:57AM +0100, martin f krafft [EMAIL PROTECTED] wrote: also sprach Mike Hommey [EMAIL PROTECTED] [2004.12.09.0359 +0100]: Sounds good. Could it be used for dh_striping the content of a package ? It is an unpacked DEB file, not a Debian source package, so I am not sure how much use the debhelper suite will be. Well, let's say strip, then, wrapped in a little script. If i understood correctly what your tool aims at, it would be possible to do that. Mike
Re: Backups in maintainer scripts
Diogo Kollross [EMAIL PROTECTED] schrieb: I'm replacing files in the maintainer script of a package, but I would like to maintain backups of these files. Is there any good practice about that (eg: like renaming the old file to filename~ or filename.old)? filename~ looks like an Emacs backup file, and I routinely delete them when I find some. I would suggest to use an extension that clearly indicates Whodunit - I use .postinst-bak (or .preinst-bak etc.). I would also like to know if dpkg makes any backups when installing packages, and if I can rely on them being present when removing a package. It takes care that no files are lost in the unpacking phase - if unpacking fails for some reason, dpkg stops and you end up with only the old files installed. But after that, all memory of older versions are removed, except that files that were conffiles in the old version and are nonexistant in the new one are kept. The .dpkg-old and .dpkg-new files come from conffile handling, see 10.7 in the Policy. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: dpkg-reversion: how about debedit?
also sprach Mike Hommey [EMAIL PROTECTED] [2004.12.09.0951 +0100]: Well, let's say strip, then, wrapped in a little script. If i understood correctly what your tool aims at, it would be possible to do that. Absolutely, yes. You are basically free to change anything within control.tar.gz and data.tar.gz, and these two are already properly unpacked to ./DEBIAN and . respectively. Just try it out: dpkg-reversion -k sh some_file.deb This will execute a shell and allow you to modify to your heart's content. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: SVG icons
On Thu, Dec 09, 2004 at 11:55:41AM +0900, Mike Hommey wrote: On Wed, Dec 08, 2004 at 11:49:49PM +0100, Bill Allombert [EMAIL PROTECTED] wrote: The authoritative document is the menu _manual_: (/usr/share/doc/menu/menu.txt.gz), section 3.7 An extract from that section: Debian package maintainers should ensure that any icons they include for use in the Debian menus conform to the following points: 1. The icons should be in xpm format. 2. The icons may not be larger than 32x32 pixels, although smaller sizes are ok. Note that's a may and a should, not a must. IIRC they only trigger lintian warnings, not errors. Should I *really* upload a new menu manual with s/should/must ? Debian policy convention are that violating a should is a normal bug, violating a must is a serious bug: In the normative part of this manual, the words _must_, _should_ and _may_, and the adjectives _required_, _recommended_ and _optional_, are used to distinguish the significance of the various guidelines in this policy document. Packages that do not conform to the guidelines denoted by _must_ (or _required_) will generally not be considered acceptable for the Debian distribution. Non-conformance with guidelines denoted by _should_ (or _recommended_) will generally be considered a bug, but will not necessarily render a package unsuitable for distribution. Guidelines denoted by _may_ (or _optional_) are truly optional and adherence is left to the maintainer's discretion. These classifications are roughly equivalent to the bug severities _serious_ (for _must_ or _required_ directive violations), _minor_, _normal_ or _important_ (for _should_ or _recommended_ directive violations) and _wishlist_ (for _optional_ items). [2] Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here.
Re: Still no 3D acceleration in Sarge..
At 10:32 2004-12-09, you wrote: On Thu, Dec 09, 2004 at 09:24:37AM +0100, Björn Johansson wrote: At 16:48 2004-12-08, you wrote: On Wed, Dec 08, 2004 at 04:00:48PM +0100, Björn Johansson wrote: At 15:46 2004-12-08, you wrote: On Wed, Dec 08, 2004 at 02:40:34PM +0100, Björn Johansson wrote: Hello! I still have problems getting 3D acceleration in Sarge. I've attached the log file. Anybody who has any suggestions? Computer: Apple Powerbook G3 Lombard Graphics: ATi Rage 16MB X-server: Xfree86 4.3 I think I need unofficial drivers or something, I don't know. Try configuring correctly your X server, the below log says that your configuration file is broken, and not much more. Please provide it also. Friendly, Sven Luther Ok, now it's working, again, but with no 3d acceleration. I've attached the log file. You are missing the kernel mach64 drm module it seems. I think this module is not available in the current kernel : CONFIG_AGP=m CONFIG_AGP_UNINORTH=m CONFIG_DRM=y CONFIG_DRM_TDFX=m # CONFIG_DRM_GAMMA is not set CONFIG_DRM_R128=m CONFIG_DRM_RADEON=m CONFIG_DRM_MGA=m CONFIG_DRM_SIS=m I would consider asking this question on the dri-devel mailing list (on sourceforge i think), and fill a bug report against the debian kernels When I used Debian on my Amiga4000 I had to enable glint to get 2D acceleration. Is 2D acceleration default nowadays? :-/ Sure. 3D acceleration is not available on glint though. Friendly, Sven Luther What do you guys know about this? Björn Johansson
ITP: g-wrap -- Scripting interface generator for C
Package: wnpp
Severity: wishlist
Subject: ITP: g-wrap -- Scripting interface generator for C
Package: wnpp
Severity: wishlist
* Package name: g-wrap
Version : 1.9.3
Upstream Author : Andreas Rottmann [EMAIL PROTECTED]
Rob Browning [EMAIL PROTECTED]
Christopher Lee [EMAIL PROTECTED]
* URL : http://www.nongnu.org/g-wrap
* License : LGPL
Description : Scripting interface generator for C
A tool (and Guile library) for generating function wrappers for
inter-language calls. It currently only supports generating Guile
wrappers for C functions.
G-Wrap takes a set of interface declarations (written in Scheme) and
wraps the described interface for Guile.
/long-description
This is the sucessor of G-Wrap 1.3.4 (packaged as libgwrapguile-dev and
libgwrapguile). It is packaged as a new source package since G-Wrap 1.3.4
is still needed to build GnuCash, although GnuCash CVS has received patches
to allow building with G-Wrap 1.9.x, so the old G-Wrap packages can be
faded out sometime after the release of GnuCash 1.8.10.
The source package g-wrap will procduce the following binary packages:
Package: g-wrap
Architecture: any
Depends: guile-1.6, guile-1.6-slib, guile-library (= 0.1.1),
libgwrap-runtime0-dev (= ${Source-Version})
Conflicts: gwrapguile-dev
Description: Scripting interface generator for C
A tool (and Guile library) for generating function wrappers for
inter-language calls. It currently only supports generating Guile
wrappers for C functions.
.
G-Wrap takes a set of interface declarations (written in Scheme) and
wraps the described interface for Guile.
Package: libgwrap-runtime0-dev
Section: libs
Architecture: any
Depends: libgwrap-runtime0 (= ${Source-Version}), libffi3-dev, libc6-dev
Description: Scripting interface generator for C - runtime
A tool (and Guile library) for generating function wrappers for
inter-language calls. It currently only supports generating Guile
wrappers for C functions.
.
This package contains the development files for the runtime shared
libraries.
Package: libgwrap-runtime0
Section: libs
Architecture: any
Depends: ${shlibs:Depends}
Description: Scripting interface generator for C - runtime
A tool (and Guile library) for generating function wrappers for
inter-language calls. It currently only supports generating Guile
wrappers for C functions.
.
This package contains the runtime shared library.
Package: guile-g-wrap
Architecture: any
Depends: ${shlibs:Depends}
Description: Scripting interface generator for C - Guile runtime
A tool (and Guile library) for generating function wrappers for
inter-language calls. It currently only supports generating Guile
wrappers for C functions.
.
This package contains the Guile standard wrapset, needed by Guile
bindings generated by G-Wrap.
Re: Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On Wed, Dec 08, 2004 at 01:34:58PM -0800, Scott Robinson wrote: As long as Debian is a distribution - a precomposed packaging of as much software as possible - then there will be conflicts like this. Perhaps that's the crux of the problem - an emphasis on quantity rather than quality. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Bug#284642: ITP: dpkg-reversion -- change the version of a DEB file
* martin f krafft | also sprach Scott James Remnant [EMAIL PROTECTED] [2004.12.08.0909 +0100]: | Generally the dpkg-* namespace is reserved for features that are | intended for integration into dpkg at some point. | | well, by all means then. If dpkg-repack and dpkg-www are intended | for integration into dpkg, then reversion should be too. Three wrongs does not make a right (or one and a half right or anything.) | I really think reversion should be available. I think it's useless, but if you're going to upload it anyhow, please don't use the dpkg-* namespace. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: binary NMUs and version numbers
Anthony Towns aj at azure.humbug.org.au writes: Goswin von Brederlow wrote: [...] Another case that should be considered is the existing use of + for revisions of a cvs snapshot (e.g. mutt uses a + but always does so): 1.2-20041208 1.2-20041208+2 1.2-20041208+b1 Hrm, why isn't this 1.2+20041208-1 ? Isn't the date describing the upstream version? Or 1.2-20041208-1, or 1.2+cvs20041208-1 or whatever. -rw-rw-r-- 16 katiedebadmin 2908273 May 2 2004 pool/main/m/mutt/mutt_1.5.6.orig.tar.gz -rw-rw-r-- 16 katiedebadmin 412082 Nov 17 10:17 pool/main/m/mutt/mutt_1.5.6-20040907+2.diff.gz It seems to result in rather large diffs, and I can't really see the benefit? [...] It is a payoff, larger diff for less frequent orig.tar.gz uploads. Instead of uploading a 3MB mutt_1.5.6-20040915.orig.tar.gz the mutt maintainers can upload a 400KB mutt_1.5.6-20040915+1.diff.gz when updating to CVS 20040915. cu andreas
Re: Bug#284642: ITP: dpkg-reversion -- change the version of a DEB file
also sprach Tollef Fog Heen [EMAIL PROTECTED] [2004.12.09.1351 +0100]: | I really think reversion should be available. I think it's useless, it's not. I will probably rename it to debedit. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: binary NMUs and version numbers
On Thu, Dec 09, 2004 at 01:13:09PM +, Andreas Metzler wrote: Anthony Towns aj at azure.humbug.org.au writes: Hrm, why isn't this 1.2+20041208-1 ? Isn't the date describing the upstream version? Or 1.2-20041208-1, or 1.2+cvs20041208-1 or whatever. It seems to result in rather large diffs, and I can't really see the benefit? It is a payoff, larger diff for less frequent orig.tar.gz uploads. Instead of uploading a 3MB mutt_1.5.6-20040915.orig.tar.gz the mutt maintainers can upload a 400KB mutt_1.5.6-20040915+1.diff.gz when updating to CVS 20040915. This bandwith consideration is nice, but IMHO in no way is anywhere near as important as the property that you can find Debian-specific changes in the .diff.gz, and upstream sources in the .orig.tar.gz. It's quite difficult to find out what was changed in Debian and what's directly from upstream CVS this way. .orig.tar.gz size only matters (marginally) for mirrors and developers downloading mutt's sources. As bandwith diskspace is cheap compared to developer time, I think it's much more important to keep the upstream/Debian specific separation that is intended with .orig.tar.gz/.diff.gz. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Bug#284909: ITP: vbetool -- run real-mode video BIOS code to alter hardware state
Package: wnpp Severity: wishlist * Package name: vbetool Version : 0.1 Upstream Author : Matthew Garrett [EMAIL PROTECTED] * URL : http://www.srcf.ucam.org/~mjg59/laptops/ * License : GPL Description : run real-mode video BIOS code to alter hardware state vbetool uses lrmi in order to run code from the video BIOS. Currently, it is able to alter DPMS states, save/restore video card state and attempt to initialize the video card from scratch. vbetool is primarily useful for attempting to recover from ACPI S3, since most hardware leaves the video card in an undefined state. Since it uses vm86, it will currently only work on x86 hardware - in the long run, I'd hope to move it over to Scitech's x86emu and give it more portability. It's also currently in the form of three separate tools, but I'll merge those in the near future. Currently, the combination of: switch away from X vbetool savestate foo vbetool dpms off (suspend) vbetool post vbetool restorestate foo vbetool dpms on switch back to X seems to work on a fairly wide range of hardware. Of course, this all interacts badly with framebuffers - there's an argument for getting the kernel to try to get userspace to do this before it attempts to resume framebuffer devices. But we'll cross that bridge when we come to it. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.9-1-386 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Re: binary NMUs and version numbers
Andreas Metzler wrote: Anthony Towns aj at azure.humbug.org.au writes: Hrm, why isn't this 1.2+20041208-1 ? Isn't the date describing the upstream version? Or 1.2-20041208-1, or 1.2+cvs20041208-1 or whatever. -rw-rw-r-- 16 katiedebadmin 2908273 May 2 2004 pool/main/m/mutt/mutt_1.5.6.orig.tar.gz -rw-rw-r-- 16 katiedebadmin 412082 Nov 17 10:17 pool/main/m/mutt/mutt_1.5.6-20040907+2.diff.gz It seems to result in rather large diffs, and I can't really see the benefit? It is a payoff, larger diff for less frequent orig.tar.gz uploads. Instead ^^ (trade off) of uploading a 3MB mutt_1.5.6-20040915.orig.tar.gz the mutt maintainers can upload a 400KB mutt_1.5.6-20040915+1.diff.gz when updating to CVS 20040915. Hrm, there seem to have been nine versions since the 1.5.6 orig was uploaded in May. The total sizes of the version (source, and all debs for all architectures), and the size of the .diff.gz's seem to be: 1.5.6-1: 17109678 59577 1.5.6-20040523+1: 1382297 102196 +3M - 40k 1.5.6-20040523+2: 15671819 102236 - 40k 1.5.6-20040722+1: 14633689 154874 +3M - 100k 1.5.6-20040722+2: 11890401 155978 - 100k 1.5.6-20040803+1: 14647304 301927 +3M - 250k 1.5.6-20040818+1: 14940217 313439 +3M - 250k 1.5.6-20040907+1: 15118784 409724 +3M - 350k 1.5.6-20040907+2: 15131102 412082 - 350k Uploading a new 3M .orig.tgz for each CVS update would introduce 3M uploads every now and then, but reduce the .diff down to 60k (or less?), so doing it that way would cost 15MB in orig.tgz uploads, and save something like 1.5MB in diffs. So 13.5MB extra from a total of 120MB, so that's about an extra 11%. Dunno that that's really worth it. Pity we don't support more than two files to build up the source we want in a more fine grained way. Cheers, aj
Re: binary NMUs and version numbers
On Thu, Dec 09, 2004 at 02:24:33PM +0100, Jeroen van Wolffelaar wrote: On Thu, Dec 09, 2004 at 01:13:09PM +, Andreas Metzler wrote: It is a payoff, larger diff for less frequent orig.tar.gz uploads. Instead of uploading a 3MB mutt_1.5.6-20040915.orig.tar.gz the mutt maintainers can upload a 400KB mutt_1.5.6-20040915+1.diff.gz when updating to CVS 20040915. This bandwith consideration is nice, but IMHO in no way is anywhere near as important as the property that you can find Debian-specific changes in the .diff.gz, and upstream sources in the .orig.tar.gz. It's quite difficult to find out what was changed in Debian and what's directly from upstream CVS this way. .orig.tar.gz size only matters (marginally) for mirrors and developers downloading mutt's sources. As bandwith diskspace is cheap compared to developer time, I think it's much more important to keep the upstream/Debian specific separation that is intended with .orig.tar.gz/.diff.gz. I tend to agree for vanilla diff.gz files. A lot of packages are using patch systems these days, however, that provide alternative means to distinguish the origins of patches. The mutt package, for instance, separates them in upstream/patches, debian/patches etc. For my own packages, I usually add a CVS suffix to the patch name and a note to the comment section. Which should be clear enough for anyone looking at the package source, and keeps the orig.tar.gz always at a released upstream version. Regards, Daniel.
Re: SVG icons
Ron Johnson wrote: See RFC 2119. I think usages of may, should, must and stuff should follow these explanations. Note that RFC 2119 does not mention the phrase may not. In American english it clearly means is not permitted. For clarity in policy documents must not should be used when the intent is to state that something is not permitted. If the intent is to say that one has the choice of doing or not doing something structure the sentence so as to use may or optional. Don't use may not to mean you can leave this out if you want to. It might be best to not use it at all as it seems to engender some confusion. Note also that the RFC says the the imperatives it defines should be used sparingly. -- John Hasler
Why is package X not in testing yet - where's the page
Hello, I used to check testing migration with the link http://bjorn.haxx.se/debian/testing.pl but the host is no longer found. Does anybody know whether this is just a temporary problem? Or is there an alternative site? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: ITP: g-wrap -- Scripting interface generator for C
Please, check the following bugs, rename or close them, however you prefer. 1) #242467: ITA: gwrapguile -- Tool for exporting C libraries into Scheme int 2) #263127: O: gwrapguile -- g-wrap: Tool for exporting C libraries into Sche Thanks, Thadeu Cascardo signature.asc Description: Digital signature
Re: Why is package X not in testing yet - where's the page
* Frank Küster ([EMAIL PROTECTED]) [041209 17:25]: I used to check testing migration with the link http://bjorn.haxx.se/debian/testing.pl but the host is no longer found. Does anybody know whether this is just a temporary problem? Or is there an alternative site? Both nameservers (which are just one ip-adresses next to each other) are not found currently. If the author wants, I'd offer secondary DNS servers. Also, we might perhaps consider to integrate these scripts into pts or on release.d.o. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Why is package X not in testing yet - where's the page
Frank Kster frank at debian.org writes: I used to check testing migration with the link http://bjorn.haxx.se/debian/testing.pl but the host is no longer found. Does anybody know whether this is just a temporary problem? Or is there an alternative site? Hello, It worked yesterday, and I've no idea what the status of the /site/ actually is because the nameservers for haxx.se seem to be down. cu andreas
Re: Linux Core Consortium
Hi everyone, Let me first say unequivocally that the LCC is very interested in getting Debian involved. The question has always been: How do we do that? It's one thing for a bunch of companies that can push down decisions from the top and that already have a great deal in common (Red Hat lineage, RPM-based package management, etc.) to join forces to address a common problem; it's quite another for a decentralized community project that evolved very differently over the years. Still, I contend Debian shares those common problems (most notably, lack of support from ISVs and IHVs), and furthermore, that the common cause is much more achievable with Debian's support than without it. I've been thinking about the obstacles for a long time, and I'm convinced they're not as large as they might appear at first glance. The end goal of the LCC is actually very simple: to create a single set of binaries that constitute an implementation of the LSB standard; to use that single set of binaries as a common core for as many Linux distributions as possible; and to develop the common core in an open and collaborative fashion, so the end result is owned by the community, not by one or two commercial players. There's only one preconceived notion: that we need a single set of binaries, because that's what ISVs and IHVs require for the result to be viable. The LCC doesn't mandate the use of RPM (only to the extent the LSB does, which Debian can already address). The LCC doesn't mandate what compatibility means as regards package naming or library versioning or anything else--it only says we need to agree on *something*, because agreeing on something buys us a lot, whereas continuing to differ on such minor things doesn't serve any purpose other than to divide us and set the stage for one or two companies to run away with commercial Linux via ISV/IHV certification lock-in. If you're having trouble picturing how Debian might engage the LCC, here's my ideal scenario: the source packages at the core of Debian are maintained in collaboration with the other LCC members, and the resulting binaries built from those source packages are made available in both RPM and .deb format. Care would have to be taken to ensure that the resulting RPM- and Debian-based versions of the common core are compatible. The two main problems I anticipate here are package namespace and file system differences--the RPM-based distros might call the package that contains /lib/libacl.so.1.1.0 acl, whereas the Debian-based distros might call it libacl1, both for reasons of historical compatibility; and differences in such things as network configuration (Debian's /etc/network vs. RH's /etc/sysconfig/network) would need to be addressed as well. Furthermore, both sets of binary packages would need to understand what the other expects for compatibility between the two sets--e.g., the Debian packages would need to understand that acl == libacl1, and the RPM packages would need to be able to deal with programs that want to configure the network via /etc/network/interfaces. I see many of these issues as being addressed in a compatibility layer of sorts. Note that this last set of issues is not unique to the RPM vs. Debian question--it also exists within the RPM world as well. The RPM distros have evolved in different directions as well, albeit for a shorter period of time--Conectiva does things differently than Mandrakesoft, and Mandrakesoft does things differently than Turbolinux, etc. etc.. Of course, my ideal scenario is a huge step, and it can't be taken all at once. As Bruce points out, though, it doesn't *have* to be taken all at once. The LCC is in the early stages, and many of the decisions that will affect the ultimate ability to reach the ideal scenario are being made now; furthermore, the vast majority (if not all) of these decisions will happen at the compatibility layer level. Finally, because the LCC is a collaborative effort, the groups involved will ultimately determine the direction of the effort as a whole. With more Debian voices at the table, who knows what that direction might be... Technical details aside, it all comes down to the question: Is getting involved worthwhile? As I said at the outset, the LCC has a lot to offer Debian, and likewise, Debian has a lot to offer the LCC as well. How does Debian benefit from LCC? It's a route to the ISV and IHV certifications that Debian has always lacked, and it is the lack of these certifications that's preventing Debian from standing alongside Red Hat and Novell/SuSE in the commercial space despite comparable (and arguably greater) popularly. The industry simply doesn't know how to engage us, and LCC provides them with a vehicle for doing that. I can imagine many of you are thinking, What difference does it make if Debian has the support of proprietary software vendors? Ok. If attracting ISV and IHV support to Debian isn't a worthwhile goal in itself, how about helping ensure that Linux remains
Re: Linux Core Consortium
On Thu, Dec 09, 2004 at 12:40:29PM -0500, Ian Murdock wrote: There's only one preconceived notion: that we need a single set of binaries, because that's what ISVs and IHVs require for the result to be viable. The LCC doesn't mandate the use of RPM (only to the extent the What makes you think you'll be any more successful than when the Unix Consortium tried to do the same thing for Unix?
Re: Linux Core Consortium
On Thu, 2004-12-09 at 09:07 +0100, Scott James Remnant wrote: On Wed, 2004-12-08 at 14:59 -0800, Bruce Perens wrote: The main technical effect that I see would be that the names of some dynamic libraries would change. And compatibility with the old names could be maintained indefinitely if necessary. ?!??!?!?!?!?!?!PO!(*!$*_(!$*($*!(*$_*!*$( That is all. Well, that's certainly constructive. Can someone provide an example of where the name of a dynamic library itself (i.e., the one in the file system, after the package is unpacked) would change? I'd be surprised if this was a big issue. The LSB/FHS should take care of file system level incompatibilities already (though Debian may put some things in /lib that RPM-based distros put in /usr/lib due to more strict policy about such things), so I'd think the main issue wouldn't so much be about the names of the dynamic libraries themselves, but the names of the packages they come in (acl vs. libacl1, as per my last message). The bottom line is that the differences between the distributions are much smaller than you might think. Remember, we all share the same upstream sources for our software. And, after an initial rough comparison of Conectiva, Mandrakesoft, Turbolinux, and Debian sarge, we're surprisingly close to not only using the same upstream sources, but also the same versions of those upstream sources too. So, increasing compatibility is mostly about using the same versions of stuff, and making sure we have the glue in place to deal with any differences in file system layout and package namespace in the binary packages built from them. I expect configuration issues to be more significant than namespace issues such as this (mostly /etc stuff). -- Ian Murdock 317-578-8882 (office) http://www.progeny.com/ http://ianmurdock.com/ All men dream: but not equally. Those who dream by night in the dusty recesses of their minds wake in the day to find that it was vanity: but the dreamers of the day are dangerous men, for they may act their dreams with open eyes, to make it possible. -T.E. Lawrence
Re: Linux Core Consortium
William Ballard wrote: What makes you think you'll be any more successful than when the Unix Consortium tried to do the same thing for Unix? The members considered that they had proprietary value at the level at which they were collaborating. We conclusively do not, because of the Open Source nature of the software. About the worst occurrance in the entire saga was the day that the X Consortium got together and decided that there would be no canonical X widget set, so that they could all differentiate from each other at that level. So, everyone had to turn to Microsoft to provide a canonical widget set on top of other manufacturer's hardware, and MS ate the X consortium's lunch. Thanks Bruce smime.p7s Description: S/MIME Cryptographic Signature
Re: Linux Core Consortium
Bruce, The history there is much more complex that that; you are oversimplifying. In fact, with my perspective, the failure occurred before that, but (un)intended consequences of the Consortium agreement, which disenfranchised the flourishing community we had built. Pay for say, and centralized development teams funded by such payers, are a major trap. Equally important, however, was that UNIX went to the high end, where there was profit to be made in the short term (but no volume), and M$ went to the low end, where there was volume, and eventual major profit. That being said, certainly UNIX's disunity was a major aid to Microsoft. Repeating that history would not be good. - Jim On Thu, 2004-12-09 at 10:53 -0800, Bruce Perens wrote: William Ballard wrote: What makes you think you'll be any more successful than when the Unix Consortium tried to do the same thing for Unix? The members considered that they had proprietary value at the level at which they were collaborating. We conclusively do not, because of the Open Source nature of the software. About the worst occurrance in the entire saga was the day that the X Consortium got together and decided that there would be no canonical X widget set, so that they could all differentiate from each other at that level. So, everyone had to turn to Microsoft to provide a canonical widget set on top of other manufacturer's hardware, and MS ate the X consortium's lunch. Thanks Bruce
Re: Linux Core Consortium
Jim Gettys wrote: Pay for say, and centralized development teams funded by such payers, are a major trap. Let's make sure to keep giving OSDL that message. Thanks Bruce smime.p7s Description: S/MIME Cryptographic Signature
Re: Linux Core Consortium
Name changes are a superficial design flaw that obscures the fundamental design flaw in this proposal -- sharing binaries between Linux distributions is a bad idea to begin with. Fixing ABI forks, and articulating best known practices about managing ABI evolution going forward, that's a good idea. Building an open source test kit that exercises the shared ABIs, validating that the test kit builds substantially the same on each distro, and helping ISVs resolve issues that the test kit missed (and add them as new test cases), that's even better. But if two competent packagers, working on different distros, can't get the same ABI out of the same source code, then upstream's build procedures are badly broken -- and I don't want that papered over by passing binaries around! From the point of view of a user of commercial software, I want to do business with ISVs that take responsibility for the proper functioning of their software on a system that is reasonably compatible with their anticipated target environment. Exposed ABIs, as verified by a test kit, are an appropriate standard of reasonably compatible. It's in everyone's interest for that test kit to be correct and thorough, which is a good thing, because it's a lot of work to build and maintain it. I prefer open source platforms for a number of reasons. One is that it's the source code, not any particular binary, that is authoritative about how things should work. In principle, one can bug-fix and rebuild any components in any order without breaking the system. My experience has been that the more faithful a distro is to this principle, and the more work is put into abiding by it, the more likely it is that I will be able to use its binaries unaltered! That's one reason why I choose Debian when I have the option. ISVs and IHVs who think that binaries shared among distros will help them manage tech support costs and quality issues aren't thinking along these lines, perhaps because testimonials like mine tend to be anecdotal. Maybe they could be persuaded by quantitative evidence. I'm not in a great position to gather that evidence; perhaps someone else is? Cheers, - Michael
Re: dselect survey
On Wed, Dec 08, 2004 at 08:30:50PM -0800, Blunt Jackson wrote: Having enter exit the selection process (rather than simply selecting the entry) is perennially surprising, And the need to use upper-Q in conflict resolution to keep the selections one has made manually is also pretty confusing. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://www.eckes.org/ o--o 1024D/E383CD7E [EMAIL PROTECTED] v:+497211603874 f:+497211606754 (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: Linux Core Consortium
Michael K. Edwards wrote: Fixing ABI forks, and articulating best known practices about managing ABI evolution going forward, that's a good idea. Building an open source test kit that exercises the shared ABIs, validating that the test kit builds substantially the same on each distro, and helping ISVs resolve issues that the test kit missed (and add them as new test cases), that's even better. But if two competent packagers, working on different distros, can't get the same ABI out of the same source code, then upstream's build procedures are badly broken -- and I don't want that papered over by passing binaries around! If we could all share the same source packages and a tool set with the same calling conventions, we'd be very far in the direction of what LCC wishes to achieve. The fact is that Debian would have to stop there for most of its architectures, simply because most of our architectures are not in common with the rest of LCC. I think it would be great to get this far. At that point we could decide if there is any purpose in using the same compile as other folks. Thanks Bruce smime.p7s Description: S/MIME Cryptographic Signature
Re: Bug#284642: ITP: dpkg-reversion -- change the version of a DEB file
On Wed, 8 Dec 2004, martin f krafft wrote: also sprach Scott James Remnant [EMAIL PROTECTED] [2004.12.08.0909 +0100]: Generally the dpkg-* namespace is reserved for features that are intended for integration into dpkg at some point. well, by all means then. If dpkg-repack and dpkg-www are intended for integration into dpkg, then reversion should be too. Probably yes on dpkg-repack. Definately not for dpkg-www. Which is a sucky name, btw.
Re: Linux Core Consortium
On Thu, Dec 09, 2004 at 12:40:29PM -0500, Ian Murdock wrote: I've been thinking about the obstacles for a long time, and I'm convinced they're not as large as they might appear at first glance. The end goal of the LCC is actually very simple: to create a single set of binaries that constitute an implementation of the LSB standard; to use that single set of binaries as a common core for as many Linux distributions as possible; and to develop the common core in an open and collaborative fashion, so the end result is owned by the community, not by one or two commercial players. There's only one preconceived notion: that we need a single set of binaries, because that's what ISVs and IHVs require for the result to be viable. The LCC doesn't mandate the use of RPM (only to the extent the LSB does, which Debian can already address). The LCC doesn't mandate what compatibility means as regards package naming or library versioning or anything else--it only says we need to agree on *something*, because agreeing on something buys us a lot, whereas continuing to differ on such minor things doesn't serve any purpose other than to divide us and set the stage for one or two companies to run away with commercial Linux via ISV/IHV certification lock-in. Disclaimer: I have not gone looking for any information about the Linux Core Consortium outside of this thread. It would have been nice to include a link: http://www.mandrakesoft.com/lcc Of course, there's not much there. Oh, here's some more: http://componentizedlinux.org/lsb As one of the maintainers involved in Debian's toolchain, I think this is a terrible idea. Our needs are different than other distributions, we already know that from experience. The core needs are conceptually the same - everyone needs working libraries and tools - but the details we consider worth fixing are not. Common binaries are only useful with fixed releases and versioning of the common binaries, because otherwise you have a dozen different sets of your common binaries running around. So during the sarge release cycle, when we need to make updates to fix an RC bug in glibc that doesn't affect any platform shipped by any other member of the LCC, which has moved on to new development according to some other member's release schedule, what would we do? We'd have to rebuild them anyway. There goes our common binaries advantage. From the web site, I see that LCC has a limited set of architectures targeted anyway. Debian will continue to use common source for all architectures. That will make working with the LCC difficult. Using binaries from LCC would also run against the Debian principle of always building Debian packages from their source before uploading them. That's a big deal. I'm sure other members of the LCC have similar concerns - or will. What are they doing about them? Are the other companies listed as supporting the Linux Core Consortium interested in this common binaries plan? Their support quotes only explicitly support the Linux Standard Base. I see primarily scheduling, maintenance, coordination, and change control problems. Technical details aside, it all comes down to the question: Is getting involved worthwhile? As I said at the outset, the LCC has a lot to offer Debian, and likewise, Debian has a lot to offer the LCC as well. How does Debian benefit from LCC? It's a route to the ISV and IHV certifications that Debian has always lacked, and it is the lack of these certifications that's preventing Debian from standing alongside Red Hat and Novell/SuSE in the commercial space despite comparable (and arguably greater) popularly. The industry simply doesn't know how to engage us, and LCC provides them with a vehicle for doing that. We would never have a common kernel with these vendors anyway - they don't even have a common kernel with each other. My experience tells me that would be a big barrier to certification of any kind. There's plenty more than certification keeping Debian from standing along side enterprise distributions in the commercial space. If there is merit to the common binaries, I think we would get more mileage from it by supporting them as we do the LSB: with separate packages on top of the Debian base system. -- Daniel Jacobowitz
Re: Status of this ITP?
On Wed, 2004-12-08 at 19:36 -0800, Brian Nelson wrote: On Wed, Dec 08, 2004 at 09:26:00PM -0600, Ron Johnson wrote: On Wed, 2004-12-08 at 11:30 -0600, Steve Greenland wrote: On 08-Dec-04, 11:15 (CST), Luis R. Rodriguez [EMAIL PROTECTED] wrote: [snip] Get off your ass. Ah. I see. Courtesy is not your strong point. His parents must not have taught him manners. Or he knows that he can't get beat up by people who don't see him face-to-face. Here, go find him: http://www.acs.rutgers.edu/directory/ Why thank you. LUIS R. RODRIGUEZ (STUDENT) IID: LRR32 EMAIL ADDRESS: Student: [EMAIL PROTECTED] POSTAL ADDRESS: Student: 34739 RPO WAY STUDENT INFORMATION: School: Rutgers College Academic Major(s): English Academic Minor(s): P Rican Hisp Carib Study Cinema Studies Year of Graduation: 05 -- greg, [EMAIL PROTECTED] The technology that is Stronger, better, faster: Linux signature.asc Description: This is a digitally signed message part
Re: Linux Core Consortium
On Dec 09, Ian Murdock [EMAIL PROTECTED] wrote: Let me first say unequivocally that the LCC is very interested in getting Debian involved. The question has always been: How do we do that? As usual: by sending patches. How does Debian benefit from LCC? It's a route to the ISV and IHV certifications that Debian has always lacked, and it is the lack of And which I doubt we will get with LCC, since the kernel is the most important piece which needs to be certificated. -- ciao, | Marco | [9673 deUYnWbve8slc] signature.asc Description: Digital signature
Re: Linux Core Consortium
On Thu, 2004-12-09 at 11:23 -0800, Michael K. Edwards wrote: Name changes are a superficial design flaw that obscures the fundamental design flaw in this proposal -- sharing binaries between Linux distributions is a bad idea to begin with. Fixing ABI forks, and articulating best known practices about managing ABI evolution going forward, that's a good idea. Building an open source test kit that exercises the shared ABIs, validating that the test kit builds substantially the same on each distro, and helping ISVs resolve issues that the test kit missed (and add them as new test cases), that's even better. But if two competent packagers, working on different distros, can't get the same ABI out of the same source code, then upstream's build procedures are badly broken -- and I don't want that papered over by passing binaries around! You've just described the way the LSB has done it for years, which thus far, hasn't worked--while there are numerous LSB-certified distros, there are exactly zero LSB-certified applications. The reason for this is that substantially the same isn't good enough--ISVs want *exactly the same*, and there's a good reason for that, as evidenced by the fact that while Debian is technically (very nearly) LSB compliant, there are still a lot of edge cases like file system and package namespace differences that fall outside the LSB that vastly complicate the certify to an ABI, then support all distros that implement the ABI as defined by whether or not it passes a test kit model. I'm not knocking the LSB--by definition, the LSB codifies existing standards, i.e., things everyone already agree with. The things we're talking about here (package naming differences, network configuration differences, all that) are clearly points of disagreement between distributions (perhaps backed more by inertia than by anything else). The LCC aims to complement the LSB by agreeing on a single set of solutions for these edge cases, then by putting the necessary glue in place to make sure whatever inertia or otherwise has propagated the differences for so long doesn't remain an insurmountable obstacle. And with enough mass, the edge cases become stuff we agree on. -- Ian Murdock 317-578-8882 (office) http://www.progeny.com/ http://ianmurdock.com/ All men dream: but not equally. Those who dream by night in the dusty recesses of their minds wake in the day to find that it was vanity: but the dreamers of the day are dangerous men, for they may act their dreams with open eyes, to make it possible. -T.E. Lawrence
Re: Linux Core Consortium
Daniel Jacobowitz writes: Using binaries from LCC would also run against the Debian principle of always building Debian packages from their source before uploading them. That's a big deal. Big enough that I think common binaries should be completely out of the question for that reason alone. I also haven't seen a convincing argument that they are beneficial. Why don't standard ABIs suffice? -- John Hasler
Re: Linux Core Consortium
On Thu, 2004-12-09 at 21:17 +0100, Marco d'Itri wrote: On Dec 09, Ian Murdock [EMAIL PROTECTED] wrote: Let me first say unequivocally that the LCC is very interested in getting Debian involved. The question has always been: How do we do that? As usual: by sending patches. So, the flow can only be unidirectional? How does Debian benefit from LCC? It's a route to the ISV and IHV certifications that Debian has always lacked, and it is the lack of And which I doubt we will get with LCC, since the kernel is the most important piece which needs to be certificated. The common core will include a common kernel. See the FAQ at http://componentizedlinux.org/lsb/: Importantly, the LCC platform will include a common kernel, eliminating one of the largest sources of incompatibilities between Linux distributions as each vendor incorporates its own potentially incompatible patch sets. -- Ian Murdock 317-578-8882 (office) http://www.progeny.com/ http://ianmurdock.com/ All men dream: but not equally. Those who dream by night in the dusty recesses of their minds wake in the day to find that it was vanity: but the dreamers of the day are dangerous men, for they may act their dreams with open eyes, to make it possible. -T.E. Lawrence
Re: Linux Core Consortium
If ISVs want exactly the same, they are free to install a chroot environment containing the binaries they certify against and to supply a kernel that they expect their customers to use. That's the approach I've had to take when bundling third-party binaries built by people who were under the illusion that exactly the same was a reasonable thing to ask for. Once I got things working in my chroot, and automated the construction of the chroot, I switched back to the kernel I wanted to use; the ISV and I haven't troubled one another since. If the LSB only attempts to certify things that haven't forked, then it's a no-op. Well, that's not quite fair; I have found it useful to bootstrap a porting effort using lsb-rpm. But for it to be a software operating environment and not just a software porting environment, it needs to have a non-trivial scope, which means an investment by both ISVs and distros. As a strategy for defining and extending the scope of consensus preparatory to a release of a test suite, sharing binaries is fine. But as a strategy for making ISVs and their customers happy, I think it's a chimera. Cheers, - Michael
Bug#284964: ITP: autoconf-doc -- automatic configure script builder documentation
Package: wnpp Severity: wishlist * Package name: autoconf-doc Version : 2.59 Upstream Author : FSF * URL : http://www.gnu.org/software/autoconf/ * License : GPL+GFDL Description : automatic configure script builder documentation This is the non-free GFDL documentation for the autoconf package -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.28-rc1-debian5+skas+lmsensors+3c59xvlan+lmlbt4x Locale: LANG=pt_BR, LC_CTYPE=pt_BR (charmap=ISO-8859-1) -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: Linux Core Consortium
|| On Thu, 09 Dec 2004 15:51:15 -0500 || Ian Murdock [EMAIL PROTECTED] wrote: And which I doubt we will get with LCC, since the kernel is the most important piece which needs to be certificated. im The common core will include a common kernel. See the FAQ at im http://componentizedlinux.org/lsb/: Importantly, the LCC platform im will include a common kernel, eliminating one of the largest sources im of incompatibilities between Linux distributions as im each vendor incorporates its own potentially incompatible patch sets. Ok but how will be deal with unsupported hardware? Will be applied patches to add support on it? -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house.
Re: ITP: g-wrap -- Scripting interface generator for C
[CC'ed Thomas Bushnell, since he has filed an ITA on gwrapguile] [EMAIL PROTECTED] writes: Please, check the following bugs, rename or close them, however you prefer. 1) #242467: ITA: gwrapguile -- Tool for exporting C libraries into... 2) #263127: O: gwrapguile -- g-wrap: Tool for exporting C... I prefer to have them open until GnuCash is built against G-Wrap 1.9.3 and the gwrapguile source package can be removed. A note to Thomas: You can already try building GnuCash 1.8.9 (1.8.10 will have the patch applied, as it is already in CVS, both in HEAD and the 1.8 branch) when you apply the attached patch. Note that I have not yet done extensive testing with the G-Wrap 1.9.3-built GnuCash, so there *might* be problems, so I'm not sure if we want this to be a pre-Sarge change (although probably any problems would show up quick enough to fix them before Sarge). You can download G-Wrap 1.9.3 .debs by adding this to your /etc/apt/sources.list: deb http://people.debian.org/~rotty/debian/ unstable/ deb-src http://people.debian.org/~rotty/debian/ unstable/ ? app-file/gnome-glib.log ? app-utils/gnome-glib.log ? business/business-core/gnome-glib.log ? business/business-gnome/gnome-glib.log ? business/dialog-tax-table/gnome-glib.log ? engine/gnome-glib.log ? gnome/gnome-glib.log ? gnome-search/gnome-glib.log ? gnome-utils/gnome-glib.log ? report/report-gnome/gnome-glib.log Index: engine/gw-engine-spec.scm === RCS file: /home/cvs/cvsroot/gnucash/src/engine/gw-engine-spec.scm,v retrieving revision 1.73 diff -u -p -r1.73 gw-engine-spec.scm --- engine/gw-engine-spec.scm 13 Jun 2004 20:01:29 - 1.73 +++ engine/gw-engine-spec.scm 8 Oct 2004 16:03:28 - @@ -97,8 +97,6 @@ (gw:wrap-as-wct ws 'gnc:id-type QofIdType QofIdTypeConst) (gw:wrap-as-wct ws 'gnc:Account* Account* const Account*) (gw:wrap-as-wct ws 'gnc:Account** Account** const Account**) -(gw:wrap-as-wct ws 'gnc:InvAcct* InvAcct* const InvAcct*) -(gw:wrap-as-wct ws 'gnc:AccInfo* AccInfo* const AccInfo*) (gw:wrap-as-wct ws 'gnc:AccountGroup* AccountGroup* const AccountGroup*) (gw:wrap-as-wct ws 'gnc:Book* QofBook* const QofBook*) (gw:wrap-as-wct ws 'gnc:Lot* GNCLot* const GNCLot*) Index: gnome-search/dialog-search.h === RCS file: /home/cvs/cvsroot/gnucash/src/gnome-search/dialog-search.h,v retrieving revision 1.11 diff -u -p -r1.11 dialog-search.h --- gnome-search/dialog-search.h 23 Oct 2003 04:32:57 - 1.11 +++ gnome-search/dialog-search.h 8 Oct 2004 16:03:28 - @@ -24,6 +24,8 @@ #ifndef _GNC_DIALOG_SEARCH_H #define _GNC_DIALOG_SEARCH_H +#include gtk/gtk.h + #include GNCId.h #include QueryNew.h Index: report/report-gnome/dialog-column-view.h === RCS file: /home/cvs/cvsroot/gnucash/src/report/report-gnome/dialog-column-view.h,v retrieving revision 1.2 diff -u -p -r1.2 dialog-column-view.h --- report/report-gnome/dialog-column-view.h 22 Feb 2003 08:13:23 - 1.2 +++ report/report-gnome/dialog-column-view.h 8 Oct 2004 16:03:28 - @@ -20,8 +20,14 @@ * Boston, MA 02111-1307, USA [EMAIL PROTECTED] * / +#ifndef GNC_DIALOG_COLUMN_VIEW_H +#define GNC_DIALOG_COLUMN_VIEW_H + #include libguile.h +#include gtk/gtk.h typedef struct gncp_column_view_edit gnc_column_view_edit; GtkWidget * gnc_column_view_edit_options(SCM options, SCM view); + +#endif Regards, Rotty -- Andreas Rottmann | [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 Software Patents: Where do you want to stifle inovation today?
Re: Linux Core Consortium
On Thu, 2004-12-09 at 15:10 -0500, Daniel Jacobowitz wrote: As one of the maintainers involved in Debian's toolchain, I think this is a terrible idea. Our needs are different than other distributions, we already know that from experience. The core needs are conceptually the same - everyone needs working libraries and tools - but the details we consider worth fixing are not. Can you provide examples? I'm not trying to be dense--I'm simply trying to understand what, if anything, is so irreconcilable, as some of you seem to be suggesting is the case here. So during the sarge release cycle, when we need to make updates to fix an RC bug in glibc that doesn't affect any platform shipped by any other member of the LCC, which has moved on to new development according to some other member's release schedule, what would we do? We'd have to rebuild them anyway. There goes our common binaries advantage. From the web site, I see that LCC has a limited set of architectures targeted anyway. Debian will continue to use common source for all architectures. That will make working with the LCC difficult. First, because the four founding members are commercial entities, we're mainly interested in the architectures that are predominant in commercial environments. That's all about aligning resources with relative priorities and certainly isn't a statement that we will never support anything else. If resources and priorities change, the set of supported architectures could change as well. Second, the common core will have a release schedule corresponding to the release schedule of the LSB standard (roughly every 12-18 months), and the members' release schedules will be synchronized to match that. Using binaries from LCC would also run against the Debian principle of always building Debian packages from their source before uploading them. That's a big deal. I'm not sure I follow--we all have to build packages from source, and the LCC will be no different, so where's the problem exactly? I'm sure other members of the LCC have similar concerns - or will. What are they doing about them? Well, for one, we're trying to open a dialog with the Debian community. :-) Are the other companies listed as supporting the Linux Core Consortium interested in this common binaries plan? Their support quotes only explicitly support the Linux Standard Base. Yes. (And you'd better re-read the quotes--all but one, IIRC, explicitly mentions the LCC too.) We would never have a common kernel with these vendors anyway - they don't even have a common kernel with each other. My experience tells me that would be a big barrier to certification of any kind. The LCC core will include a common kernel. If there is merit to the common binaries, I think we would get more mileage from it by supporting them as we do the LSB: with separate packages on top of the Debian base system. That's certainly an option I've thought a lot about--the main question is, is this good enough to get the ISV support? It probably isn't to get the tier 1 ISVs (Oracle etc.), but it might be to get some of the smaller ISVs, and that's better than nothing at all. -- Ian Murdock 317-578-8882 (office) http://www.progeny.com/ http://ianmurdock.com/ All men dream: but not equally. Those who dream by night in the dusty recesses of their minds wake in the day to find that it was vanity: but the dreamers of the day are dangerous men, for they may act their dreams with open eyes, to make it possible. -T.E. Lawrence
Re: Linux Core Consortium
The most high and most honorable Ian Murdock wrote: Hi everyone, Hi Back at you. Let me first say unequivocally that the LCC is very interested in getting Debian involved. The question has always been: How do we do that? It's one thing for a bunch of companies that can push down decisions from the top and that already have a great deal in common (Red Hat lineage, RPM-based package management, etc.) to join forces to address a common problem; it's quite another for a decentralized community project that evolved very differently over the years. Still, I contend Debian shares those common problems (most notably, lack of support from ISVs and IHVs), and furthermore, that the common cause is much more achievable with Debian's support than without it. ISVs and IHVs want Binary, mainly that is because Microsoft and Apple have been dealing binary for decades. Binary is not what Debian is all about. For myself I will strongly oppose any shared binaries. I don;t want any RPM shoved down my throat. I would like to use see a shared usage of the same Source Core, built on the apropos systems for those supported archs. Debian Might be okay with that. But to demand Binary? Pfeh! I've been thinking about the obstacles for a long time, and I'm convinced they're not as large as they might appear at first glance. The end goal of the LCC is actually very simple: to create a single set of binaries that constitute an implementation of the LSB standard; to use that single set of binaries as a common core for as many Linux distributions as possible; and to develop the common core in an open and collaborative fashion, so the end result is owned by the community, not by one or two commercial players. Let us change this somewhat and see what you may think. The end goal of the LCC is actually very simple: to create a single set of source-packages that constitute an implementation of the LSB standard(with or without RPM) and strict policies; to use that single set of source-packages as a common core for as many Linux distributions as possible, again with a strict set of policies; to produce a implementation test kit to verify these common cores; and to develop the common core in an open and collaborative fashion, so the end result is owned by the community, not by any commercial players. There's only one preconceived notion: that we need a single set of binaries, because that's what ISVs and IHVs require for the result to be viable. PUT THE BRAKES ON. Single set of Binaries, right there I'll be 110% opposed to this. As I am sure many in the Gentoo crowd and perhaps even some others (Linux From Scratch is another) will be against this. Repeat after me: Binary is not the way. Binary is not the way. The LCC doesn't mandate the use of RPM (only to the extent the LSB does, which Debian can already address). Which is exactly why Debian is not REALLY considered an LSB Distro. RPM and the big players policies are so inadequate thereby removing RPM as a viable alternative to package management for the LCC. My gosh tar.gz or tar.bz2 binaryballs would be immensely better than RPM in that regard. But let me keep saying Binary is not the way. Source for the core-packages, with an ABI/API/OTHER Test Kit to test compliance, should be what happens. The LCC doesn't mandate what compatibility means as regards package naming or library versioning or anything else--it only says we need to agree on *something*, because agreeing on something buys us a lot, whereas continuing to differ on such minor things doesn't serve any purpose other than to divide us and set the stage for one or two companies to run away with commercial Linux via ISV/IHV certification lock-in. ISV/IHV don't quite understand what it really means to use these standards, they THINK they want these standards... but in reality they want thing mandated into the systems. That in and of itself hampers what really Debian, for that matter Linux is all about. It stifles revolutionary disruptive evolution. Debian is all about Stifling on Stable, but not elsewhere. Where you are leading Microsoft has already gone down that path. Look at how much of a NIGHTMARE it is to deal with different versions of the same Libraries with the same interfaces... but reacting differently and breaking many things. If you're having trouble picturing how Debian might engage the LCC, here's my ideal scenario: the source packages at the core of Debian are maintained in collaboration with the other LCC members, and the resulting binaries built from those source packages are made available in both RPM and .deb format. Care would have to be taken to ensure that the resulting RPM- and Debian-based versions of the common core are compatible. Okay, he we are as Debian, with strict policies about packaging. If we could get the RPM based Distros to get that we could get along much much
Re: Linux Core Consortium
Ian Murdock [EMAIL PROTECTED] writes: On Thu, 2004-12-09 at 09:07 +0100, Scott James Remnant wrote: On Wed, 2004-12-08 at 14:59 -0800, Bruce Perens wrote: The main technical effect that I see would be that the names of some dynamic libraries would change. And compatibility with the old names could be maintained indefinitely if necessary. ?!??!?!?!?!?!?!PO!(*!$*_(!$*($*!(*$_*!*$( That is all. Well, that's certainly constructive. Can someone provide an example of where the name of a dynamic library itself (i.e., the one in the file system, after the package is unpacked) would change? I'd be surprised if this was a big issue. The LSB/FHS should take care of file system level incompatibilities already (though Debian may put some things in /lib that RPM-based distros put in /usr/lib due to more strict policy about such things), so I'd think the main issue wouldn't so much be about the names of the dynamic libraries themselves, but the names of the packages they come in (acl vs. libacl1, as per my last message). When multiarch hits all (core) libs will move around drastically: /lib/* - /lib/`gcc -dumpmachine`/ /usr/lib/* - /usr/lib/`gcc -dumpmachine`/ /usr/X11R6/lib/* - /usr/X11R6/lib/`gcc -dumpmachine`/ If you aim at having the same path to libs (which only broken rpath needs) then this will be your nightmare. MfG Goswin PS: The above lib dirs are the best and only practical solution we have for multiarch.
Re: Linux Core Consortium
On Thu, Dec 09, 2004 at 04:42:29PM -0500, Ian Murdock wrote: Second, the common core will have a release schedule corresponding to the release schedule of the LSB standard (roughly every 12-18 months), and the members' release schedules will be synchronized to match that. So given that Debian's release schedule once again slips past 18 months, do we have to wait another 18 months to get etch out? /* Steinar */ -- Homepage: http://www.sesse.net/
Re: dselect survey
Bernd Eckenfels [EMAIL PROTECTED] wrote: On Wed, Dec 08, 2004 at 08:30:50PM -0800, Blunt Jackson wrote: Having enter exit the selection process (rather than simply selecting the entry) is perennially surprising, And the need to use upper-Q in conflict resolution to keep the selections one has made manually is also pretty confusing. Er, these are shortcuts. *shrug* Uppercase is often used, relatively consistently, for things that you really don't want to do inadvertently. I learnt the most useful shortcuts, I know them, and I don't find them particularly confusing. Very few are needed to do basic package management (I would say, 10 or so). If in doubt, you can always invoke the online help, which is bound to the question mark, so again, I don't see a problem (oh, wait, some industry standard says it should be F1. Well, frankly, I don't care.). For people who are allergic to keyboard shortcuts, I would suggest some point-and-click frontend; that is simply not dselects's target audience, AFAICT. I've always thought that people who say they hate dselect (or, worse, that dselect is crap) fall into one of the following cases: (a) allergic to text-mode interfaces (b) type or click without thinking (c) haven't used it for more than 5 years (I don't know how dselect was before slink) (d) didn't bother to read the dselect for beginners tutorial or any similar introductory document (e) have had problems with packages that didn't install, upgrade or configure correctly and wrongly blamed dselect for these problems. [ Quizz of the day: which cases do you think are the most common? ] Once you understand the basics, I find dselect to be a very useful and efficient program. -- Florent
Re: Linux Core Consortium
Ian Murdock [EMAIL PROTECTED] writes: On Thu, 2004-12-09 at 21:17 +0100, Marco d'Itri wrote: On Dec 09, Ian Murdock [EMAIL PROTECTED] wrote: How does Debian benefit from LCC? It's a route to the ISV and IHV certifications that Debian has always lacked, and it is the lack of And which I doubt we will get with LCC, since the kernel is the most important piece which needs to be certificated. The common core will include a common kernel. See the FAQ at http://componentizedlinux.org/lsb/: Importantly, the LCC platform will include a common kernel, eliminating one of the largest sources of incompatibilities between Linux distributions as each vendor incorporates its own potentially incompatible patch sets. And how will you get the other members to support architectures they do not support? A common kernel sounds good but we haven't even managed to common-ify the kernel inside of debian. And that is without mentioning the non-free ness and license issues coming up after sarge. The firmware blobs and the like. Don't get me wrong, I think a common kernel would be great. I just don't think Debians standards will go well with the commercial distributions. MfG Goswin
Re: Linux Core Consortium
Greg Folkert wrote: I will strongly oppose any shared binaries. I don't want any RPM shoved down my throat. One is not equal to the other. It's entirely possible to have a single package source that builds into both RPM and DEB. I would like to use see a shared usage of the same Source Core Yes, let's work on that for now. Perhaps we will all find that we should stop at that. Okay, he we are as Debian, with strict policies about packaging. If we could get the RPM based Distros to get that we could get along much much better as well. Smaller more numerous packages (Like for Samba: samba-common, smbclient, smbfs, swat, winbind, samba, samba-doc, libsmbclient, libsmbclient-dev... etc), not just samba and samba-devel. This does not sound unreasonable, but they won't do it if we're not there asking for it to be done. If we are so sure we want interoperability, why not Invite the BSDs as well. I know I'd like to see that. Some of the BSDs already provide much of the compatibility right now. Well, why not invite the AIX, Solaris, and HP-UX folks too :-) Let's bite off a managable piece for now. I'd be glad to help on any front to get more applications from Commercial Entities for Linux and BSD, even down to the negotiations about how this. I for one use Linux 99.95% of the time. I'd like to see that at 100%. If this LCC would be something that even RedHat and Novell would Follow as well as the packaging and policy (even for just the Core pieces) and as long as source for these and a test kit is made available and improved by a technical committee/task-force, I'd like to see more of this. I can tell you for sure that if we don't build a strong community for LCC, the only thing that business people will ever care about is RH certification and Novell certification. We need to take this to the point that RH and Novell customers and the hardware vendors will insist that RH and Novell adopt it. Debian has Policy and packaging constraints, if more Linux Distros at least experienced those and really, how easy it is to just do it... I think Debian could help tremendously. Yes, I don't believe any other distro has done such an excellent job on policy. Those Certifications would be given to the CORE, right? If a given Distro proves, through the Testing Kit, that it complies, Certification is inherited? Thats what they are planning. Thanks Bruce
Re: Linux Core Consortium
Steinar H. Gunderson wrote: So given that Debian's release schedule once again slips past 18 months, do we have to wait another 18 months to get etch out? I don't see why, we don't do that for X or GNOME or anything else. But some of us don't want to see Debian's release schedule slip again. I am hoping that once Sarge releases, we can continue to have weekly reports on RC bugs, continue bug-squashing parties, and in general do the most we can to keep the distribution on a ready-to-release footing on a continual basis. Thanks Bruce
Re: ITP: g-wrap -- Scripting interface generator for C
Andreas Rottmann [EMAIL PROTECTED] writes: A note to Thomas: You can already try building GnuCash 1.8.9 (1.8.10 will have the patch applied, as it is already in CVS, both in HEAD and the 1.8 branch) when you apply the attached patch. Just so you know, it's really my intention not to have *any* pre-Sarge changes.
Re: Linux Core Consortium
Patrz w ekran, a to Goswin von Brederlow pisze do mnie: Don't get me wrong, I think a common kernel would be great. I just don't think Debians standards will go well with the commercial distributions. Not necessary. If the common kernel would not suit best for the debian it would always be possible to have the kernel-xyz-lcc packages (with the warning in the others that they do not fit LCC standard). So it will be up to the user to decide what he wants. And I will always build my very custom kernel anyway ;) Cheers Maciek -- M.Sc. Maciej Dems [EMAIL PROTECTED] - C o m p u t e r P h y s i c s L a b o r a t o r y Institute of Physics,Technical University of Lodz ul. Wolczanska 219, 93-005 Lodz, Poland, +48426313649
Re: dselect survey
On Thu, Dec 09, 2004 at 11:08:53PM +0100, Florent Rougon wrote: I've always thought that people who say they hate dselect (or, worse, that dselect is crap) fall into one of the following cases: (a) allergic to text-mode interfaces (b) type or click without thinking (c) haven't used it for more than 5 years (I don't know how dselect was before slink) (d) didn't bother to read the dselect for beginners tutorial or any similar introductory document (e) have had problems with packages that didn't install, upgrade or configure correctly and wrongly blamed dselect for these problems. [ Quizz of the day: which cases do you think are the most common? ] Once you understand the basics, I find dselect to be a very useful and efficient program. Amen! Well said. Regards, David -- * Customer: My palmtop won't turn on. * Tech Support: Did the battery run out, maybe? * Customer: No, it doesn't use batteries. It's Windows powered. -- http://www.rinkworks.com/stupid/cs_power.shtml
LCC and blobs
Goswin von Brederlow wrote: And how will you get the other members to support architectures they do not support? They would have to support merging in of source-code changes for all architectures that any member builds. They would not be called upon to compile those architectures. And that is without mentioning the non-free ness and license issues coming up after sarge. The firmware blobs and the like. The whole system has to be DFSG-free. Debian won't compromise on that. I have been thinking about the blob problem for a while. I propose to remove blobs from the driver, and store them as files in initramfs (the kernel-internal filesystem created by the stuff in /usr/src/linux*/usr) or initrd.img. At boot time, the drivers would look for the blobs and load them if they are present, and fail gracefully or fall back if they are not. This gets around some GPL issues, because rather than be treated as code, the blobs become external files that are just sent to the device by the driver. Doing the above doesn't necessarily solve the problem for Debian, because we would still not want to distribute the blobs. but it allows the kernel to be GPL-compliant, which I don't feel it is while the blobs live in drivers. An alternative is to make blobs their own loadable modules, but then we are treating them as code rather than as just a file that the kernel sends to some device, and we get GPL issues. Thanks Bruce
Re: dselect survey
Miles Bader [EMAIL PROTECTED] wrote: The current aptitude, by contrast, seems both powerful and elegant: it rarely gets in my way, deals well with problem situations, and offers powerful features should I want them (aptitude of years past could also be kinda cranky though). The last time I used aptitude (about six months ago, from Testing), I found it difficult to specify how I wanted dependencies (including recommends and suggests) to be satisfied. I like that fact that when I select a package in dselect which has several ways of satisfying its dependencies, dselect lets me choose what gets installed. Just because a package depends on a web server doesn't mean I want apache installed. While aptitude does tell you what it's going to install, and gives you an opportunity to change it, I couldn't get it to give me a list of acceptable alternatives. I am willing to accept that this might just be down to my own stupidity though. Roger (Sorry if I've broken the thread; I'm reading the web archive.)
Re: Linux Core Consortium
On Thu, Dec 09, 2004 at 02:25:28PM -0800, Bruce Perens wrote: So given that Debian's release schedule once again slips past 18 months, do we have to wait another 18 months to get etch out? I don't see why, we don't do that for X or GNOME or anything else. Then I don't see what you mean by synchronization. But some of us don't want to see Debian's release schedule slip again. I doubt anybody wants to see Debian's release schedule slip, but it still happens. :-) /* Steinar */ -- Homepage: http://www.sesse.net/
Re: Linux Core Consortium
Steinar H. Gunderson wrote: Then I don't see what you mean by synchronization. You use the LCC version available to you at the time you release, whatever that is. It may make sense for you to schedule your release to come some months after the LCC's, but I can't see that you have to do everything modulo 18 months. Thanks Bruce
Bug#284978: general: libgmp segfaults on generating 48402688-bit random number
Package: general
Version: 20041209
Severity: normal
The program
#include stdio.h
#include stdlib.h
#include math.h
#include gmp.h
int main(int argc, char** argv)
{
mpz_t A,B,C;
gmp_randstate_t state;
gmp_randinit_default(state);
gmp_randseed_ui(state, 3);
mpz_urandomb(A, state, 48402688);
mpz_urandomb(B, state, 845*32);
mpz_gcd(C,A,B);
}
compiled with gcc = gcc-2.95.4, gmp = gmp-4.0.1
segfaults in the mpz_urandomb() function
with a back-trace
#0 0x4003d051 in __gmpn_copyi () from /usr/lib/libgmp.so.3
#1 0x40023012 in __gmp_randinit_lc_2exp () from /usr/lib/libgmp.so.3
#2 0x4002310d in __gmp_rand () from /usr/lib/libgmp.so.3
#3 0x400331f8 in __gmpz_urandomb () from /usr/lib/libgmp.so.3
#4 0x0804861b in main (argc=1, argv=0xbca4) at use-gcds-BUG.c:14
-- System Information
Debian Release: 3.0
Kernel Version: Linux chiark 2.4.28 #2 SMP Mon Nov 22 15:56:31 GMT 2004 i686
unknown
Re: Linux Core Consortium
On Thu, 2004-12-09 at 14:33 -0600, John Hasler wrote: Daniel Jacobowitz writes: Using binaries from LCC would also run against the Debian principle of always building Debian packages from their source before uploading them
Re: dselect survey
On Thu, Dec 09, 2004 at 11:08:53PM +0100, Florent Rougon wrote: And the need to use upper-Q in conflict resolution to keep the selections one has made manually is also pretty confusing. Er, these are shortcuts. *shrug* Uh, so there is a non-shortcut method of operating? management (I would say, 10 or so). If in doubt, you can always invoke the online help, which is bound to the question mark And which is left with enter, just like you need to do to install (unless you really want to ignore the conflict, which means you have to use Q to install, then :) Gruss Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://www.eckes.org/ o--o 1024D/E383CD7E [EMAIL PROTECTED] v:+497211603874 f:+497211606754 (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: dselect survey
On Thu, Dec 09, 2004 at 10:27:50PM +, Roger Lynn wrote: The last time I used aptitude (about six months ago, from Testing), I found it difficult to specify how I wanted dependencies You just use g and resolve the dependencies? (Kind of same as in dselect) Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://www.eckes.org/ o--o 1024D/E383CD7E [EMAIL PROTECTED] v:+497211603874 f:+497211606754 (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: Linux Core Consortium
On Thu, Dec 09, 2004 at 12:40:29PM -0500, Ian Murdock wrote: I can imagine many of you are thinking, What difference does it make if Debian has the support of proprietary software vendors? Ok. If attracting ISV and IHV support to Debian isn't a worthwhile goal in itself, how about helping ensure that Linux remains open and free in the face of increased commercialization (this was, after all, Debian's founding goal)? I've long argued that, as the Linux world's leading non-commercial, community-driven free software distributor, Debian can and should lead the way against the elements of our community that seek to own Linux all to themselves. In fact I'm using Debian exactly because it doesn't try to apeal ISVs, IHVs, OEMs and other business-driven three-letter acronyms. As soon as you ty to please them quality of implementation goes down. Besides that the LCC sounds like an extraordinarily bad idea, passing around binaries only makes sense if you can't easily reproduce them from the source (which I defined very broadly to include all build scripts and depencies), and that case is the worst possible thing a distribution can get into.
Re: Linux Core Consortium
On Thu, Dec 09, 2004 at 03:10:52PM -0500, Daniel Jacobowitz wrote: We would never have a common kernel with these vendors anyway - they No does Debian with itself :P
Re: Linux Core Consortium
On Thu, Dec 09, 2004 at 02:33:30PM -0600, John Hasler wrote: Why don't standard ABIs suffice? Not that I'm necessarily arguing in favour of a set of common packages, but defining an ABI is not a sufficient condition to ensure compatibility. Consider a function int s(int, int) -- you can have two ABI-compatible versions of this, one that adds it's arguments and one that multiplies them. ABI compatible, but different results. I'm not expecting that there'll be anything different to that degree in the LCC-defined packages, but pretty much any change in a library would have the effect of changing the way that library operates in some fashion -- and who's to say that some program isn't relying on the former (buggy) operation of the library? - Matt signature.asc Description: Digital signature
Re: Linux Core Consortium
On Thu, Dec 09, 2004 at 03:51:15PM -0500, Ian Murdock wrote: The common core will include a common kernel. See the FAQ at http://componentizedlinux.org/lsb/: Importantly, the LCC platform will include a common kernel, eliminating one of the largest sources of incompatibilities between Linux distributions as each vendor incorporates its own potentially incompatible patch sets. Which already shows that either they're going to play the UL-like rebrand a single distro game or they are totally disconnected from reality.
Re: Linux Core Consortium
Matthew Palmer writes: Consider a function int s(int, int) -- you can have two ABI-compatible versions of this, one that adds it's arguments and one that multiplies them. ABI compatible, but different results. And different APIs. Is that really a serious risk? ...who's to say that some program isn't relying on the former (buggy) operation of the library? How could the program do that without being buggy itself? -- John Hasler
Bug#284978: general: libgmp segfaults on generating 48402688-bit random number
Thomas Womack [EMAIL PROTECTED] writes:
Package: general
Version: 20041209
Severity: normal
The program
#include stdio.h
#include stdlib.h
#include math.h
#include gmp.h
Do you have libgmp2-dev or libgmp3-dev installed?
int main(int argc, char** argv)
{
mpz_t A,B,C;
gmp_randstate_t state;
gmp_randinit_default(state);
gmp_randseed_ui(state, 3);
mpz_urandomb(A, state, 48402688);
mpz_urandomb(B, state, 845*32);
mpz_gcd(C,A,B);
}
compiled with gcc = gcc-2.95.4, gmp = gmp-4.0.1
With gcc-3.3 and libgmp3-dev_4.1.4-5_amd64.deb
[EMAIL PROTECTED]:~% gcc -g -O2 -W -Wall -o foo foo.c -lgmp
foo.c: In function `main':
foo.c:6: warning: unused parameter `argc'
foo.c:6: warning: unused parameter `argv'
[EMAIL PROTECTED]:~% ./foo
zsh: segmentation fault ./foo
Program received signal SIGSEGV, Segmentation fault.
0x002a95673f00 in __gmp_rand () from /usr/lib/libgmp.so.3
(gdb) bt
#0 0x002a95673f00 in __gmp_rand () from /usr/lib/libgmp.so.3
#1 0x002a95673eba in __gmp_rand () from /usr/lib/libgmp.so.3
#2 0x002a95687164 in __gmpz_urandomb () from /usr/lib/libgmp.so.3
#3 0x00400782 in main (argc=4196299, argv=0x9e) at foo.c:14
Same with gcc-3.4.
segfaults in the mpz_urandomb() function
with a back-trace
#0 0x4003d051 in __gmpn_copyi () from /usr/lib/libgmp.so.3
#1 0x40023012 in __gmp_randinit_lc_2exp () from /usr/lib/libgmp.so.3
#2 0x4002310d in __gmp_rand () from /usr/lib/libgmp.so.3
#3 0x400331f8 in __gmpz_urandomb () from /usr/lib/libgmp.so.3
#4 0x0804861b in main (argc=1, argv=0xbca4) at use-gcds-BUG.c:14
-- System Information
Debian Release: 3.0
Kernel Version: Linux chiark 2.4.28 #2 SMP Mon Nov 22 15:56:31 GMT 2004 i686
unknown
Kernel Version: Linux frosties 2.6.8-frosties-1 #2 Sun Oct 3 22:06:03 CEST 2004
x86_64 GNU/Linux
MfG
Goswin
Re: LCC and blobs
Bruce Perens [EMAIL PROTECTED] writes:
Goswin von Brederlow wrote:
And that is without mentioning the non-free ness and license issues coming up
after sarge. The firmware blobs and the like.
The whole system has to be DFSG-free. Debian won't compromise on that.
I have been thinking about the blob problem for a while. I propose to
remove blobs from the driver, and store them as files in initramfs
(the kernel-internal filesystem created by the stuff in
/usr/src/linux*/usr) or initrd.img. At boot time, the drivers would
look for the blobs and load them if they are present, and fail
gracefully or fall back if they are not. This gets around some GPL
issues, because rather than be treated as code, the blobs become
external files that are just sent to the device by the driver.
Doing the above doesn't necessarily solve the problem for Debian,
because we would still not want to distribute the blobs. but it allows
the kernel to be GPL-compliant, which I don't feel it is while the
blobs live in drivers.
An alternative is to make blobs their own loadable modules, but then
we are treating them as code rather than as just a file that the
kernel sends to some device, and we get GPL issues.
Thanks
Bruce
Blobs can be made binary files and stored in the initrd. Since no
linking is involved and the kernel-image without the blobs is still
fully functional (except for a very very few hardware constelations)
that should get the GPL issue settled.
As for distributing the blobs itself they can be relicensed under BSD
license or similar (if their aren't already) that doesn't have such a
problem with a char data[] = { 0x17, ... } source file, something
without the prefered source form clause. Even putting some in non-free
works fine.
But presonaly I think even distributing such blobs as GPL is fine as
they are the source as recieved from upstream. Only an author could
sue us for obfuscating the source but the author released the source
as is. No obfuscating is done on our part.
Where I see problems is firmware and sources that were not explicitly
released as GPL by the authors but somehow sneaked their way into the
kernel just the same. Many of the problem cases fall under this.
But enough said. It's all put off till sarge is out.
MfG
Goswin
PS: Having the firmware as GPL would allow reverse engeneering to get
a more readable source format.
Re: Linux Core Consortium
On Thu, 09 Dec 2004 17:20:00 -0600, Ron Johnson [EMAIL PROTECTED] wrote: libfoo 1.7 fixes a non-security bug in v1.6. bar segfaults when running libfoo 1.6. But libfoo 1.6 is in Sarge, and the bug won't be fixed because it's not a security bug. Having a formal GNU/Linux Distro Test Kit would help organize this process. Suppose that sarge validates against DTK 1.0, the vendor of bar contributes a new test case which is accepted into DTK 1.0.1, and DTK 1.0.1 runs against sarge + libfoo 1.7. Then we'd be in no worse a position than Other-Distro 14.7 which also included libfoo 1.6 and validated against DTK 1.0 -- except insofar as commercial distros are more likely to silently roll DTK 1.0.1 and libfoo 1.7 into 14.7-updates, which isn't the way Debian handles stable. This could be handled with overlay repositories that handle bug fixes within a DTK minor version. In the case described, bar depends on validated-with-dtk (= 1.0.1, 1.1), validated-with-dtk 1.0.1-1 depends on libfoo (=1.7-1), and you need to have packages from the validated-with-dtk 1.0.1 repository in order to install bar. A security fix to libfoo 1.6 (in stable) would need re-validating against DTK 1.0, and might also need to be done on libfoo 1.7, resulting in validated-with-dtk 1.0.1-2 (built to depend on libfoo 1.7-2). I actually think trying to handle this with a validated-with-dtk package is a kludge, but it doesn't require any new development (except, of course, the DTK, and perhaps automation of propagation into the overlay repositories). One of these days I will get around to doing a more competent job of proposing Signed Package Integrity Tokens (my last effort wasn't worth SPIT :-) as a way for ISVs to self-service (or delegate self-servicing) at the level of functional test and validation. Either approach partitions the problem of security/bug-fix management so that ISVs and their customers can contribute to things that matter to them. The DTK needs to be re-run, and the validated-with-dtk dependencies updated or the PITs re-signed, any time there is a security update to the relevant packages. Security updates themselves multiply because they may hit the versions in the overlay repositories as well. But at least it's possible to estimate the resource cost of maintaining the various overlays, and it's clear what the criterion for adding an overlay package is -- a DTK update that fails without the overlay. Note that many of the core packages we are talking about already have extensive test suites, so the DTK could get off the ground by adapting them into tests of the package in its installed state instead of build-time tests. This would make it pretty easy for an ISV to prototype a test within the DTK, send it to upstream (the same test runs in the build-time test framework), and get the bug fixed (or feature added). Obviously there aren't any new ideas in this (DejaGNU, anyone?) and it's not a panacea. The LCC's proposal is just a special case of this -- a DTK that verifies the checksums of the common binaries :-). But I prefer an approach in which I can verify when and why the contract between distro and ISV changed, so that I can make reasonable decisions about whether and how to replace distro binaries with builds that meet my own needs better. Cheers, - Michael
Re: LCC and blobs
On Fri, 10 Dec 2004, Goswin von Brederlow wrote:
As for distributing the blobs itself they can be relicensed under
BSD license or similar (if their aren't already) that doesn't have
such a problem with a char data[] = { 0x17, ... } source file,
something without the prefered source form clause. Even putting some
in non-free works fine.
They'd pretty much have to go into non-free, as I'd imagine most of
them wouldn't be able to satisfy DFSG 2 if they were unable to satisfy
the GPL's source code requirement.
Don Armstrong
--
When I was a kid I used to pray every night for a new bicycle. Then I
realised that the Lord doesn't work that way so I stole one and asked
Him to forgive me.
-- Emo Philips.
http://www.donarmstrong.com http://rzlab.ucr.edu
Re: dselect survey
Florent Rougon [EMAIL PROTECTED] writes: I've always thought that people who say they hate dselect (or, worse, that dselect is crap) fall into one of the following cases: (a) allergic to text-mode interfaces (b) type or click without thinking (c) haven't used it for more than 5 years (I don't know how dselect was before slink) (d) didn't bother to read the dselect for beginners tutorial or any similar introductory document (e) have had problems with packages that didn't install, upgrade or configure correctly and wrongly blamed dselect for these problems. Completely and utterly wrong in my case. I'm exactly the sort of person that you apparently think should like dselect, but I think aptitude is _far_ superior, for both experts and newbies. The competition isn't even close. -Miles -- Most attacks seem to take place at night, during a rainstorm, uphill, where four map sheets join. -- Anon. British Officer in WW I
Re: dselect survey
On Thursday 09 December 2004 06:35 pm, Bernd Eckenfels wrote: On Thu, Dec 09, 2004 at 10:27:50PM +, Roger Lynn wrote: The last time I used aptitude (about six months ago, from Testing), I found it difficult to specify how I wanted dependencies You just use g and resolve the dependencies? (Kind of same as in dselect) If you want to find alternatives for a virtual package, you can use 'd' and 'r' to navigate the dependency lists. It's not as convenient as dselect, but it works. Daniel -- /--- Daniel Burrows [EMAIL PROTECTED] --\ | Do you know why the prisoner in the| |tower watches the flight of birds?| | -- Terry Pratchett, _Reaper_Man_ | \-- (if (not (understand-this)) (go-to http://www.schemers.org)) ---/ pgptaUbdTIxuT.pgp Description: PGP signature
Re: Linux Core Consortium
Bruce Perens [EMAIL PROTECTED] writes: You use the LCC version available to you at the time you release, whatever that is. It may make sense for you to schedule your release to come some months after the LCC's, but I can't see that you have to do everything modulo 18 months. I think this is a hideously bad idea, and I say this as a representative of an institutional user of Debian that has been hurt by the lack of ISV support. Having Oracle support Debian would be great, but not if it comes at the cost of Debian's ability to make its own fixes and releases of core libraries and toolchain components. One of the reasons why we chose Debian in the first place is that the packages that come out of the Debian project are simply higher quality, in large part because they themselves are maintained in an open-source fashion rather than as proprietary packages maintained by single vendors controlled by commercial and economic restraints. If I wanted Red Hat's broken libc maintenance process, I know where to find it. We explicitly chose Debian because it's *better* than Red Hat in the core system maintenance that we care about. I think that tying core Debian packages to the Red Hat boat anchor is a horrible, horrible idea. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Linux Core Consortium
On Thu, Dec 09, 2004 at 07:08:48PM -0800, Russ Allbery wrote: Bruce Perens [EMAIL PROTECTED] writes: I think that tying core Debian packages to the Red Hat boat anchor is a horrible, horrible idea. I tend to agree with sentiments like this, but didn't Bruce mention that we could participate in this organization even if we didn't take their packages? That is, perhaps we could influence the direction to a more useful one? If that is the case, it seems zero risk to me. -- John
Re: dselect survey
Miles Bader dijo [Fri, Dec 10, 2004 at 11:52:05AM +0900]: Completely and utterly wrong in my case. I'm exactly the sort of person that you apparently think should like dselect, but I think aptitude is _far_ superior, for both experts and newbies. The competition isn't even close. AOLME TOO!/AOL I liked dselect very much, and would have no problems using it... Only that I found aptitude was standard the first time I installed using d-i, decided to give it a spin, didn't really love it the first time... But by the third use, it really stuck, and now I am an aptitude convert. Far more usable, friendly, navigable user type=normalhas more colors, lets me play minesweeper/user. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: Linux Core Consortium
On Thu, Dec 09, 2004 at 04:42:29PM -0500, Ian Murdock wrote: On Thu, 2004-12-09 at 15:10 -0500, Daniel Jacobowitz wrote: As one of the maintainers involved in Debian's toolchain, I think this is a terrible idea. Our needs are different than other distributions, we already know that from experience. The core needs are conceptually the same - everyone needs working libraries and tools - but the details we consider worth fixing are not. Can you provide examples? I'm not trying to be dense--I'm simply trying to understand what, if anything, is so irreconcilable, as some of you seem to be suggesting is the case here. I'll try. My first concern is the architectures issue. Bruce made a comment along the lines of LCC would have to accept patches for architectures it didn't care about, but would not be required to build them. But it's not that simple; there are always tradeoffs. Some of the issues are rate of change (esp. w.r.t. release schedules), modifications to common code, and increased pressure on patch review/approval. Debian has a different set of use cases than most Linux distributions. The first example that comes to mind is in-place upgrading, and some packages have horrible hacks in them to support this. Other LCC members might reasonably object to the baggage. So during the sarge release cycle, when we need to make updates to fix an RC bug in glibc that doesn't affect any platform shipped by any other member of the LCC, which has moved on to new development according to some other member's release schedule, what would we do? We'd have to rebuild them anyway. There goes our common binaries advantage. From the web site, I see that LCC has a limited set of architectures targeted anyway. Debian will continue to use common source for all architectures. That will make working with the LCC difficult. First, because the four founding members are commercial entities, we're mainly interested in the architectures that are predominant in commercial environments. That's all about aligning resources with relative priorities and certainly isn't a statement that we will never support anything else. If resources and priorities change, the set of supported architectures could change as well. Of course. I understand the point of supporting commercially viable architectures; Debian is the alternate extreme. Second, the common core will have a release schedule corresponding to the release schedule of the LSB standard (roughly every 12-18 months), and the members' release schedules will be synchronized to match that. Precisely. You've signed Debian up for externally (quotes, because we would be participants, but there will be strong external pressures) managed schedules for dozens of core packages. And some external pressure on overall release schedule, because of the sharp dropoff in staleness. For example, suppose GNOME is part of this managed set. The other members, primarily commercial distributions with greater control over their schedules than Debian has, want to wait off on upgrading to GNOME 3.4 until their next release cycle. Debian is going to be releasing in three months and two dozen active GNOME developers are heartbroken by the idea. It's not an idle example - that happened for this release cycle. Heroic effort on the part of both GNOME maintainers and release managers got it in under the wire, and it will make an IMHO big difference to the out-of-the-box usability of sarge. Right now, if you have a brilliant idea that you want to implement and integrate all through Debian, there's a clear set of the relevant maintainers to convince. Expanding that set to include lots more people, and people with sharply different needs and pressures, is not something I consider good for the future of Debian. The reason I am a Debian developer is because Debian is responsive to my needs; it's (relatively speaking) easily swayed onto a better course when one presents itself. As long as there's someone willing to do the work, the work can be done. Also, the multiple-architectures issue is a big one for the imposed schedules. Architectures that only Debian, out of all the LCC members, cares about will be only lightly tested by the time any given LCC release is made. I estimate a dozen or more substantial changes to any released packages before Debian could use them, taking many months to come together. Using binaries from LCC would also run against the Debian principle of always building Debian packages from their source before uploading them. That's a big deal. I'm not sure I follow--we all have to build packages from source, and the LCC will be no different, so where's the problem exactly? Autobuilders. Security updates. Build testing in Debian environments. None of this is new... We would never have a common kernel with these vendors anyway - they don't even have a common kernel with each other. My experience tells me
Re: Linux Core Consortium
John Goerzen dijo [Thu, Dec 09, 2004 at 09:40:51PM -0600]: I think that tying core Debian packages to the Red Hat boat anchor is a horrible, horrible idea. I tend to agree with sentiments like this, but didn't Bruce mention that we could participate in this organization even if we didn't take their packages? That is, perhaps we could influence the direction to a more useful one? If that is the case, it seems zero risk to me. Then we would be non-participants, we would be just bitchers, telling everybody how fucked-up their process and QA are. We would gain nothing, and we would lose as everybody would say that Debian refuses to play together with the guys after giving an initial 'yes'. And no, no ISV would certify Debian just because Debian sits and bitches. I don't have a real position on whether we should join LCC or not - But if we do, we should _really_ join LCC, not just sit at the LCC table and watch them play. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: Linux Core Consortium
Ian Murdock dijo [Thu, Dec 09, 2004 at 04:42:29PM -0500]: We would never have a common kernel with these vendors anyway - they don't even have a common kernel with each other. My experience tells me that would be a big barrier to certification of any kind. The LCC core will include a common kernel. Ummm... Wait a second on this one. Do you think that Mandrake (I wanted to make the example with RedHat or SuSE, but it seems they also have not commited, and without them mostly any attempt to do something this big will probably fail) would want to have a kernel with less, slower or less complete hardware support? Because I know Debian does not want a kernel with propietary firmware in it. If there is merit to the common binaries, I think we would get more mileage from it by supporting them as we do the LSB: with separate packages on top of the Debian base system. That's certainly an option I've thought a lot about--the main question is, is this good enough to get the ISV support? It probably isn't to get the tier 1 ISVs (Oracle etc.), but it might be to get some of the smaller ISVs, and that's better than nothing at all. Ok, so here is where exactly companies like yours come into play. I don't think the LCC (as a commercial entity, with commercial interest as you said) would be benefitted at all by supporting m68k or mips (they would be more hindered than pushed by it - It does not surprise me at all most Linux distributions pulled the plug on older or less common architectures one by one). Progeny provides a Debian-based distribution meant to be closer to the commercial world than Debian. Why shouldn't Progeny provide for this set of needs? Of course, if you are in the right mood, you can push your packages into Debian as well, although they would not be base packages. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: Linux Core Consortium
Greg Folkert wrote: Many reasons people come to Debian... Distributed Binaries is not one of them. If you think this isn't a reason to use Debian, I, as a long-time user, will tell you that you're dead wrong. I use Debian because there exist packages for most every popular piece of free software out there, and I will never have to use an untrusted binary package to install it conveniently. Even when it comes to installing software that's not in the Archive, I can safely install it from source, with the assurance that none of its files will be mixed in with any files installed by the package management system (not the case with most 3rd-party RPMS). I am doing some sysadmin work involving RedHat Enterprise Linux 3 systems, and I will tell you that they do a terrible job of maintaining a binary distribution. Standing by themself, let alone compared to Debian, they do no integration testing of the packages they release and distribute. For example, this past summer, after a new server installation, we had to build and install a local copy of Perl, because the version they distributed was completely incompatible with both mailscanner and amavisd-new due to module bugs. This sort of brown-paper-bag error in a release is unthinkable in Debian, precisely because of the QA that our exact distributed binaries go through (and this particular issue was actually caught in testing, as it should have been). Philip Miller
Call for papers embedded track Fosdem 2005 (26-27 feb, Brussels)
Hello all, At the start of next year FOSDEM, the most important Belgian Free Software event will be back again. As on the previous occasions there will also be an embedded track, for which we are looking for speakers. All the necessary info can be found in the following call for papers. Feel free to distribute, and tell other people about it. 3th EMBEDDED SYSTEMS and OPERATING SYSTEMS track at FOSDEM 2005 === 26 - 27 February 2005, Brussels Call for papers The 2005 edition of FOSDEM (Free and Open Source Developers' European Meeting; http://www.fosdem.org) will take place in Brussels, Belgium on 26 and 27 February 2005. For the third time, a track on Embedded Systems and Operating Systems will be organized. The second edition was quite succesful and attracted up to 150 attendants for certain topics. For last year's program see: http://www.embedded-kernel-track.org/2004/papers.html The use of Free Software in the infrastructure of embedded systems is booming, e.g. by the use of Linux, uClinux, eCos, RedBoot, RTEMS and many other Free Software components. More companies are supporting embedded Free Software each day because of the reliability and cheap licensing. Operating system development has always been a very important topic in Free Software. As embedded and real-time systems typically have special OS requirements, we organise this Free Embedded and OS development track at FOSDEM. This track provides a remarkable opportunity to present and discuss the ongoing work in these areas, and we invite developers to present their current projects. Technical topics of the conference include but are not limited to : * OS Development : kernel architecture and implementation, libraries (e.g. Linux, BSD, uClinux, uClibc, newlib, ...) * Practical experiences in implementing Free Software in embedded systems (e.g. reverse engineering, porting too (and adapting of) commercial devices (IPAQ, Linksys WRT54G,...), ...) * Toolchain and build environment (e.g. crosstool, emdebian, openembedded, PTX dist, packaging, scratchbox, Eclipse, Valgrind,...) * GUIs for embedded systems (Gtk, Qt-(embedded), GPE, Qtopia, UI design with touchscreen, ...) * Multimedia applications for embedded systems (e.g. integer-only decoders, Opieplayer, ... ) * Real-time extensions, nanokernels and hardware virtualization software (e.g. RTAI, Adeos, KURT, L4, Qemu, User Mode Linux, ...) * Hard real-time OS's (eCos, RTEMS, ...) * Open hardware and softcores (e.g opencores.org, OpenRISC, LEON SPARC, FPGA's, specific design restrictions for free systems...) * Safety and security certifications applied to Free software (e.g. security measures in Embedded systems, SSL libraries, ...) * Free software licenses and embedded systems Authors are requested to submit their abstracts online to [EMAIL PROTECTED] before 3/1/2005. Notification of receipt will be sent within 48 hours. Authors wishing to submit a full paper (between 6 and 12 A4 pages), can do so in PS or PDF format. The program committee will evaluate the abstracts and consists of: * Herman Bruyninckx, Professor at K.U.Leuven, Belgium * Geert Uytterhoeven, Sony NSCE, Belgium * Karim Yaghmour, Opersys, Canada * Peter De Schrijver (P2), Mind, Belgium * Russell King (RMK), ARM Linux Kernel Engineer, Deep Blue Solutions Ltd See you at Fosdem, Philippe -- | Philippe De Swert | | Stag developer http://stag.mind.be/ | Emdebian developer: http://www.emdebian.org | | Please do not send me documents in a closed format.(*.doc,*.xls,*.ppt) | Use the open alternatives. (*.pdf,*.ps,*.html,*.txt) | Why? http://pallieter.is-a-geek.org:7832/~johan/word/english/ signature.asc Description: This is a digitally signed message part
Re: Call for papers embedded track Fosdem 2005 (26-27 feb, Brussels)
On Thu, Dec 09, 2004 at 10:04:53PM +0100, Philippe De Swert wrote: Hello all, Hi, My eye just caught a few small items. For the rest, this is plain good work, Peter (e.g. reverse engineering, porting too (and adapting of) commercial ^^^ to devices (IPAQ, Linksys WRT54G,...), ...) (Gtk, Qt-(embedded), GPE, Qtopia, UI design with touchscreen, ...) kdrive ? * Real-time extensions, nanokernels and hardware virtualization software (e.g. RTAI, Adeos, KURT, L4, Qemu, User Mode Linux, ...) Xen ? * Open hardware and softcores (e.g opencores.org, OpenRISC, LEON SPARC, FPGA's, specific design restrictions for free systems...) IIRC, the prefered public name for the Leon core is Leon and not Leon Sparc. Authors are requested to submit their abstracts online to [EMAIL PROTECTED] before 3/1/2005. Notification of receipt 3 January 2005 will be sent within 48 hours. Authors wishing to submit a full paper (between 6 and 12 A4 pages), can do so in PS or PDF format. The program committee will evaluate the abstracts and consists of: * Herman Bruyninckx, Professor at K.U.Leuven, Belgium * Geert Uytterhoeven, Sony NSCE, Belgium * Karim Yaghmour, Opersys, Canada * Peter De Schrijver (P2), Mind, Belgium ^^ p2 (?) * Russell King (RMK), ARM Linux Kernel Engineer, Deep Blue Solutions Ltd
Accepted evolution-data-server 1.0.3-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 9 Dec 2004 15:32:33 +0900 Source: evolution-data-server Binary: evolution-data-server libegroupwise-dev libedata-cal-dev libedata-book1 libedataserver3 libedata-cal5 libebook-dev libebook8 evolution-data-server-dev libegroupwise6 libecal6 libedataserver-dev libedata-book-dev libecal-dev Architecture: source i386 Version: 1.0.3-1 Distribution: unstable Urgency: low Maintainer: Takuo KITAME [EMAIL PROTECTED] Changed-By: Takuo KITAME [EMAIL PROTECTED] Description: evolution-data-server - evolution database backend server evolution-data-server-dev - Development files for evolution-data-server (meta package) libebook-dev - Client library for evolution address books (development files) libebook8 - Client library for evolution address books libecal-dev - Client library for evolution calendars (development files) libecal6 - Client library for evolution calendars libedata-book-dev - Backend library for evolution address books (development files) libedata-book1 - Backend library for evolution address books libedata-cal-dev - Backend library for evolution calendars (development files) libedata-cal5 - Backend library for evolution calendars libedataserver-dev - Utility library for evolution data servers (development files) libedataserver3 - Utily library for evolution data servers libegroupwise-dev - Development files for libegroupwise libegroupwise6 - Client library for accessing groupwise POA through SOAP interface Changes: evolution-data-server (1.0.3-1) unstable; urgency=low . * New upstream release Files: b5af4fbf508998c5fcd52dab04d2f560 970 gnome optional evolution-data-server_1.0.3-1.dsc 859f4407f73cd88eafc6d18ac1017b78 6486384 gnome optional evolution-data-server_1.0.3.orig.tar.gz a399396dca3509e491adffcd9ea7f1f4 40176 gnome optional evolution-data-server_1.0.3-1.diff.gz b8fb69cd0f0b4110825622827fbead80 354658 gnome optional evolution-data-server_1.0.3-1_i386.deb ba597008cd2999104b1b7b1df1071eba 15426 devel optional evolution-data-server-dev_1.0.3-1_i386.deb fac52f8e310c9ae4fb86aed49a363be5 70614 libs optional libedataserver3_1.0.3-1_i386.deb c6ac258b6b5941e14d3cf25e6b9452d2 26288 libdevel optional libedataserver-dev_1.0.3-1_i386.deb d62dff3e64963bce3b61975842b48f95 78732 libs optional libebook8_1.0.3-1_i386.deb c019cb1487537c0bede2ca0db7261010 35868 libdevel optional libebook-dev_1.0.3-1_i386.deb 56ab8b1be7cb6b077c5a0d79a5828680 50158 libs optional libedata-book1_1.0.3-1_i386.deb da58410c624189f9151d1ee59f1480f0 29874 libdevel optional libedata-book-dev_1.0.3-1_i386.deb c647ada01ed1f9d6b55b12db9649766e 244142 libs optional libecal6_1.0.3-1_i386.deb 49829b2eb2a1b6bc5d0f1d31d6d3e40c 81438 libdevel optional libecal-dev_1.0.3-1_i386.deb 389127420ab3f3b16ed770e1dd47 63610 libs optional libedata-cal5_1.0.3-1_i386.deb 2133108271d49345827069dfea17885d 35972 libdevel optional libedata-cal-dev_1.0.3-1_i386.deb 65a105c751dbb39e439c0c1a11783ccb 43990 libs optional libegroupwise6_1.0.3-1_i386.deb dad1a70f58d64f0b0eff2250cbc1e682 20546 libdevel optional libegroupwise-dev_1.0.3-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBuAZUU+WZW1FVMwoRAhIwAJ9asdKFviMppXga7vZEnquJ6VxmogCeKzjH 3lZ51kR4gHM/Chxq7qP1t5k= =FmHW -END PGP SIGNATURE- Accepted: evolution-data-server-dev_1.0.3-1_i386.deb to pool/main/e/evolution-data-server/evolution-data-server-dev_1.0.3-1_i386.deb evolution-data-server_1.0.3-1.diff.gz to pool/main/e/evolution-data-server/evolution-data-server_1.0.3-1.diff.gz evolution-data-server_1.0.3-1.dsc to pool/main/e/evolution-data-server/evolution-data-server_1.0.3-1.dsc evolution-data-server_1.0.3-1_i386.deb to pool/main/e/evolution-data-server/evolution-data-server_1.0.3-1_i386.deb evolution-data-server_1.0.3.orig.tar.gz to pool/main/e/evolution-data-server/evolution-data-server_1.0.3.orig.tar.gz libebook-dev_1.0.3-1_i386.deb to pool/main/e/evolution-data-server/libebook-dev_1.0.3-1_i386.deb libebook8_1.0.3-1_i386.deb to pool/main/e/evolution-data-server/libebook8_1.0.3-1_i386.deb libecal-dev_1.0.3-1_i386.deb to pool/main/e/evolution-data-server/libecal-dev_1.0.3-1_i386.deb libecal6_1.0.3-1_i386.deb to pool/main/e/evolution-data-server/libecal6_1.0.3-1_i386.deb libedata-book-dev_1.0.3-1_i386.deb to pool/main/e/evolution-data-server/libedata-book-dev_1.0.3-1_i386.deb libedata-book1_1.0.3-1_i386.deb to pool/main/e/evolution-data-server/libedata-book1_1.0.3-1_i386.deb libedata-cal-dev_1.0.3-1_i386.deb to pool/main/e/evolution-data-server/libedata-cal-dev_1.0.3-1_i386.deb libedata-cal5_1.0.3-1_i386.deb to pool/main/e/evolution-data-server/libedata-cal5_1.0.3-1_i386.deb libedataserver-dev_1.0.3-1_i386.deb to pool/main/e/evolution-data-server/libedataserver-dev_1.0.3-1_i386.deb libedataserver3_1.0.3-1_i386.deb to pool/main/e/evolution-data-server/libedataserver3_1.0.3-1_i386.deb
Accepted libsdl1.2 1.2.7+1.2.8cvs20041007-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 08 Dec 2004 23:27:25 -0500 Source: libsdl1.2 Binary: libsdl1.2debian-oss libsdl1.2debian-alsa libsdl1.2debian-arts libsdl1.2debian libsdl1.2-dev libsdl1.2debian-nas libsdl1.2debian-esd libsdl1.2debian-all Architecture: source i386 Version: 1.2.7+1.2.8cvs20041007-2 Distribution: unstable Urgency: medium Maintainer: Debian SDL maintainers [EMAIL PROTECTED] Changed-By: Matthew Danish [EMAIL PROTECTED] Description: libsdl1.2-dev - Simple DirectMedia Layer development files libsdl1.2debian - Simple DirectMedia Layer libsdl1.2debian-all - Simple DirectMedia Layer (with all available options) libsdl1.2debian-alsa - Simple DirectMedia Layer (with X11 and ALSA options) libsdl1.2debian-arts - Simple DirectMedia Layer (with X11 and aRts options) libsdl1.2debian-esd - Simple DirectMedia Layer (with X11 and esound options) libsdl1.2debian-nas - Simple DirectMedia Layer (with X11 and NAS options) libsdl1.2debian-oss - Simple DirectMedia Layer (with X11 and OSS options) Closes: 284172 Changes: libsdl1.2 (1.2.7+1.2.8cvs20041007-2) unstable; urgency=medium . * Thanks go to Lawrence Williams ( [EMAIL PROTECTED] ) for this release. * Fixed libsdl.la invalid libdir bug (Closes: 284172) Files: 0263df556ae04dbe1a5bba59d7351cb1 1180 libs optional libsdl1.2_1.2.7+1.2.8cvs20041007-2.dsc c5d5b9eaaec6d002d24ec8a6bf7e1b87 18016 libs optional libsdl1.2_1.2.7+1.2.8cvs20041007-2.diff.gz 82f8dea0659ea6f07f8bcece86dfb780 15214 libs optional libsdl1.2debian_1.2.7+1.2.8cvs20041007-2_i386.deb 04feb3cd82881c22f9fad44a74cf561b 198854 libs optional libsdl1.2debian-all_1.2.7+1.2.8cvs20041007-2_i386.deb 9d73e3643549859efe76da3a2081467f 186962 libs extra libsdl1.2debian-alsa_1.2.7+1.2.8cvs20041007-2_i386.deb 41af8bae17332a52a86ae201af2e26f6 188168 libs extra libsdl1.2debian-oss_1.2.7+1.2.8cvs20041007-2_i386.deb 706f9c2a8f340b35bdc62874f4528f09 186492 libs extra libsdl1.2debian-esd_1.2.7+1.2.8cvs20041007-2_i386.deb d48f246e61eb4935959ec18fc23a1ff8 186536 libs extra libsdl1.2debian-arts_1.2.7+1.2.8cvs20041007-2_i386.deb 2a21395408e00ccfaa18cb42bea25fc5 186730 libs extra libsdl1.2debian-nas_1.2.7+1.2.8cvs20041007-2_i386.deb 87ac304d4f902fee24eb0d917438ab2e 911890 libdevel optional libsdl1.2-dev_1.2.7+1.2.8cvs20041007-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBt+28zxUyMsJLYBARAh38AJ9VtslUkjEgcstMI+hP6bTml0RlaACdFZ7x 7+BZLCxLTquFJmT6zpQn+gQ= =WYhj -END PGP SIGNATURE- Accepted: libsdl1.2-dev_1.2.7+1.2.8cvs20041007-2_i386.deb to pool/main/libs/libsdl1.2/libsdl1.2-dev_1.2.7+1.2.8cvs20041007-2_i386.deb libsdl1.2_1.2.7+1.2.8cvs20041007-2.diff.gz to pool/main/libs/libsdl1.2/libsdl1.2_1.2.7+1.2.8cvs20041007-2.diff.gz libsdl1.2_1.2.7+1.2.8cvs20041007-2.dsc to pool/main/libs/libsdl1.2/libsdl1.2_1.2.7+1.2.8cvs20041007-2.dsc libsdl1.2debian-all_1.2.7+1.2.8cvs20041007-2_i386.deb to pool/main/libs/libsdl1.2/libsdl1.2debian-all_1.2.7+1.2.8cvs20041007-2_i386.deb libsdl1.2debian-alsa_1.2.7+1.2.8cvs20041007-2_i386.deb to pool/main/libs/libsdl1.2/libsdl1.2debian-alsa_1.2.7+1.2.8cvs20041007-2_i386.deb libsdl1.2debian-arts_1.2.7+1.2.8cvs20041007-2_i386.deb to pool/main/libs/libsdl1.2/libsdl1.2debian-arts_1.2.7+1.2.8cvs20041007-2_i386.deb libsdl1.2debian-esd_1.2.7+1.2.8cvs20041007-2_i386.deb to pool/main/libs/libsdl1.2/libsdl1.2debian-esd_1.2.7+1.2.8cvs20041007-2_i386.deb libsdl1.2debian-nas_1.2.7+1.2.8cvs20041007-2_i386.deb to pool/main/libs/libsdl1.2/libsdl1.2debian-nas_1.2.7+1.2.8cvs20041007-2_i386.deb libsdl1.2debian-oss_1.2.7+1.2.8cvs20041007-2_i386.deb to pool/main/libs/libsdl1.2/libsdl1.2debian-oss_1.2.7+1.2.8cvs20041007-2_i386.deb libsdl1.2debian_1.2.7+1.2.8cvs20041007-2_i386.deb to pool/main/libs/libsdl1.2/libsdl1.2debian_1.2.7+1.2.8cvs20041007-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libosip2 2.0.9-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 9 Dec 2004 18:09:09 +0900 Source: libosip2 Binary: libosip2 libosip2-dev Architecture: source i386 Version: 2.0.9-1 Distribution: unstable Urgency: low Maintainer: Anand Kumria [EMAIL PROTECTED] Changed-By: ARAKI Yasuhiro [EMAIL PROTECTED] Description: libosip2 - Session Initiation Protocol (SIP) library libosip2-dev - development files for the SIP library Changes: libosip2 (2.0.9-1) unstable; urgency=low . * New upstream release Files: a4cfa571718668d8b54dcd6cda6c9086 673 comm optional libosip2_2.0.9-1.dsc dba6d47332f4842f70694792939fec2d 606839 comm optional libosip2_2.0.9.orig.tar.gz a6acf4342ee1f4bbdd53a86c032f1b6a 5438 comm optional libosip2_2.0.9-1.diff.gz c6bca55cd4023acef2dc7e6b66413969 127016 libdevel optional libosip2-dev_2.0.9-1_i386.deb 2ce826c4eb7ba21d078fd7b4cec479c6 78190 libs optional libosip2_2.0.9-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBuBgQNOYipi+po4wRAsrQAJoC4HlEo491r6KQhoe0fkIWaFAoBQCbB7SY P6aQOAHodmh8wCEGLJPdltA= =RrPZ -END PGP SIGNATURE- Accepted: libosip2-dev_2.0.9-1_i386.deb to pool/main/libo/libosip2/libosip2-dev_2.0.9-1_i386.deb libosip2_2.0.9-1.diff.gz to pool/main/libo/libosip2/libosip2_2.0.9-1.diff.gz libosip2_2.0.9-1.dsc to pool/main/libo/libosip2/libosip2_2.0.9-1.dsc libosip2_2.0.9-1_i386.deb to pool/main/libo/libosip2/libosip2_2.0.9-1_i386.deb libosip2_2.0.9.orig.tar.gz to pool/main/libo/libosip2/libosip2_2.0.9.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted python-kde3 3.11.3-3 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 9 Dec 2004 09:36:34 + Source: python-kde3 Binary: python-kde3-doc python-kde3 python2.3-kde3 Architecture: source all i386 Version: 3.11.3-3 Distribution: unstable Urgency: low Maintainer: Ricardo Javier Cardenes Medina [EMAIL PROTECTED] Changed-By: Ricardo Javier Cardenes Medina [EMAIL PROTECTED] Description: python-kde3 - KDE3 bindings for Python python-kde3-doc - Documentation and examples for PyKDE python2.3-kde3 - KDE3 bindings for Python 2.3 Changes: python-kde3 (3.11.3-3) unstable; urgency=low . * Changed depend on PyQt = 3.13-2 to = 3.13 (I don't know what I was thinking on) Files: d65a4c3ebab5bf12935b1cffefd523e3 900 python optional python-kde3_3.11.3-3.dsc 66b4670a08d676d07b84b8ca3bf0f891 32909 python optional python-kde3_3.11.3-3.diff.gz 5577ccc8153cb4ff16304ad055ae6ff7 6292416 python optional python2.3-kde3_3.11.3-3_i386.deb f7d685cf0d92911547c488347f674375 2518 python optional python-kde3_3.11.3-3_all.deb 9ec03cc2dfdf4c12d2950e5236cf3cfc 698486 doc optional python-kde3-doc_3.11.3-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBuCVxHkQIZYcutOURArnTAJ9mg0i7doFVfDWElXHk0FKeIRf5NgCeNzzB ux0uIZ1Ek75QfmsgUif9214= =kekU -END PGP SIGNATURE- Accepted: python-kde3-doc_3.11.3-3_all.deb to pool/main/p/python-kde3/python-kde3-doc_3.11.3-3_all.deb python-kde3_3.11.3-3.diff.gz to pool/main/p/python-kde3/python-kde3_3.11.3-3.diff.gz python-kde3_3.11.3-3.dsc to pool/main/p/python-kde3/python-kde3_3.11.3-3.dsc python-kde3_3.11.3-3_all.deb to pool/main/p/python-kde3/python-kde3_3.11.3-3_all.deb python2.3-kde3_3.11.3-3_i386.deb to pool/main/p/python-kde3/python2.3-kde3_3.11.3-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted nessus-plugins 2.2.0-4 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Format: 1.7 Date: Thu, 9 Dec 2004 11:32:44 +0100 Source: nessus-plugins Binary: nessus-plugins Architecture: source i386 Version: 2.2.0-4 Distribution: unstable Urgency: low Maintainer: Josip Rodin [EMAIL PROTECTED] Changed-By: Javier Fernandez-Sanguino Pen~a [EMAIL PROTECTED] Description: nessus-plugins - Nessus plugins Changes: nessus-plugins (2.2.0-4) unstable; urgency=low . * Fix postrm since the /var/lib/nessus/plugins was not properly removed on purge if the directory contained downloaded plugin. Kept the check for /usr/lib/nessus/plugins just in case. Files: 057001f47b1b93235b906c4d035bc75b 868 admin optional nessus-plugins_2.2.0-4.dsc ed182703fda6b484dd8ac629336d880e 324124 admin optional nessus-plugins_2.2.0-4.diff.gz a8e7328b667d409e2401f6b8bd4eac03 2554608 admin optional nessus-plugins_2.2.0-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iQCVAwUBQbgrY/tEPvakNq0lAQHEQQP/YSx03UwWCSnWchbXKypLYfl89N57dkMk DZc71a5asoQB8CkFQrOjAPkuyB0QYquaksHUt1JgJeZJ6ECgZiYubf8IlMnqa589 02TU3lEC5IPJ3CfWLMtE0T/Jy0vJyjb7tsnPvioCwqVUW6yknPRt3qZF8m8YwBL2 EGgjqkGJKFA= =Fo42 -END PGP SIGNATURE- Accepted: nessus-plugins_2.2.0-4.diff.gz to pool/main/n/nessus-plugins/nessus-plugins_2.2.0-4.diff.gz nessus-plugins_2.2.0-4.dsc to pool/main/n/nessus-plugins/nessus-plugins_2.2.0-4.dsc nessus-plugins_2.2.0-4_i386.deb to pool/main/n/nessus-plugins/nessus-plugins_2.2.0-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted inkscape 0.40-2 (powerpc source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 8 Dec 2004 18:54:45 +0100 Source: inkscape Binary: inkscape Architecture: source powerpc Version: 0.40-2 Distribution: unstable Urgency: high Maintainer: Wolfram Quester [EMAIL PROTECTED] Changed-By: Wolfram Quester [EMAIL PROTECTED] Description: inkscape - Vector based drawing program Closes: 283476 Changes: inkscape (0.40-2) unstable; urgency=high . * High-urgency upload for sarge targetted RC bugfix. * Build inkscape with -Wa,-xgot on mips, mipsel so that the linker can handle the symbol tables correctly. Closes: #283476. This patch is from Steve Langasek. Many thanks to him. * upload sponsored by Guido Guenther [EMAIL PROTECTED] * GG: really set urgency to high Files: c916e6cdfb03c7887648309a60af652c 841 graphics optional inkscape_0.40-2.dsc 53b0f7bd7e94e8667097a713d1c4a4d5 6331 graphics optional inkscape_0.40-2.diff.gz 194281b324140f6d84157164b9d0834e 4892706 graphics optional inkscape_0.40-2_powerpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBuC5un88szT8+ZCYRAlasAJ9yd7H2XQCgJH2Nb4XdO2NOE6+TawCfYJTK 3dSIQDnj3RgLTeut7hmNya8= =dium -END PGP SIGNATURE- Accepted: inkscape_0.40-2.diff.gz to pool/main/i/inkscape/inkscape_0.40-2.diff.gz inkscape_0.40-2.dsc to pool/main/i/inkscape/inkscape_0.40-2.dsc inkscape_0.40-2_powerpc.deb to pool/main/i/inkscape/inkscape_0.40-2_powerpc.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted apt-spy 3.1-13 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 9 Dec 2004 12:45:08 + Source: apt-spy Binary: apt-spy Architecture: source i386 Version: 3.1-13 Distribution: unstable Urgency: low Maintainer: Stephen Stafford [EMAIL PROTECTED] Changed-By: Stephen Stafford [EMAIL PROTECTED] Description: apt-spy- writes a sources.list file based on bandwidth tests Closes: 279472 281897 Changes: apt-spy (3.1-13) unstable; urgency=low . * Transition to libcurl3 (Closes: #279472) * fix manpage (Closes: #281897) Files: 72786135f1954c028ae9f4e80eb0f82c 626 admin optional apt-spy_3.1-13.dsc 59759e6fafd9c5e32f4b1db943d7402b 16916 admin optional apt-spy_3.1-13.diff.gz 3bf8baf88453fd48e9896e9c26c21dc6 27684 admin optional apt-spy_3.1-13_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAkG4StAACgkQFwmY7Xa4pD1okQCfW0MGJia3g3zzOCiDi8YsTfKa E3UAnj8lboWIr3wrUbal4dJ/J+L2JN1z =gUtk -END PGP SIGNATURE- Accepted: apt-spy_3.1-13.diff.gz to pool/main/a/apt-spy/apt-spy_3.1-13.diff.gz apt-spy_3.1-13.dsc to pool/main/a/apt-spy/apt-spy_3.1-13.dsc apt-spy_3.1-13_i386.deb to pool/main/a/apt-spy/apt-spy_3.1-13_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted getmail4 4.2.5-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 9 Dec 2004 14:47:44 +0100 Source: getmail4 Binary: getmail4 Architecture: source all Version: 4.2.5-1 Distribution: unstable Urgency: low Maintainer: Fredrik Steen [EMAIL PROTECTED] Changed-By: Fredrik Steen [EMAIL PROTECTED] Description: getmail4 - mail retriever with support for POP3, IMAP4 and SDPS Changes: getmail4 (4.2.5-1) unstable; urgency=low . * New upstream release Files: b22240d7f102215cc02c5514c9619cf2 588 mail optional getmail4_4.2.5-1.dsc 30f1528598db4e507aed4565c3f76d30 123810 mail optional getmail4_4.2.5.orig.tar.gz c63cbf7f98399e6877edfcbc1d272870 2882 mail optional getmail4_4.2.5-1.diff.gz 4719ca526179565e56839f02e9f71543 132938 mail optional getmail4_4.2.5-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBuFg32pHue6WOFk8RAo+XAJ9EqeardWdHUDHFka5DcJEJYyAbuwCghG0K T/4va4d8r8h/LUPIZ5aKyrc= =bF+8 -END PGP SIGNATURE- Accepted: getmail4_4.2.5-1.diff.gz to pool/main/g/getmail4/getmail4_4.2.5-1.diff.gz getmail4_4.2.5-1.dsc to pool/main/g/getmail4/getmail4_4.2.5-1.dsc getmail4_4.2.5-1_all.deb to pool/main/g/getmail4/getmail4_4.2.5-1_all.deb getmail4_4.2.5.orig.tar.gz to pool/main/g/getmail4/getmail4_4.2.5.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted openalpp-cvs 20041206-2 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 9 Dec 2004 14:04:58 +0100 Source: openalpp-cvs Binary: openalpp-cvs-doc libopenalpp-cvs-dev libopenalpp-cvs Architecture: source all i386 Version: 20041206-2 Distribution: unstable Urgency: low Maintainer: Loic Dachary (OuoU) [EMAIL PROTECTED] Changed-By: Loic Dachary (OuoU) [EMAIL PROTECTED] Description: libopenalpp-cvs - Object Oriented version of OpenAL libopenalpp-cvs-dev - Object Oriented version of OpenAL openalpp-cvs-doc - Object Oriented version of OpenAL Changes: openalpp-cvs (20041206-2) unstable; urgency=low . * gcc 3.4 patches . * versionned osg depend Files: 1e9e403bad753b444c7a8b67cc33dbc2 740 libs optional openalpp-cvs_20041206-2.dsc f478ec349c7b48d99b0f5817cecb0347 6894 libs optional openalpp-cvs_20041206-2.diff.gz d271d28d8d3dde0b33a54e1f97695344 111524 libdevel optional openalpp-cvs-doc_20041206-2_all.deb bd7b7a7e6c804d0ffc9b121eabc4dc2e 19334 libdevel optional libopenalpp-cvs-dev_20041206-2_i386.deb 506975e9323bdb7acef5015946ba18d0 59512 libs optional libopenalpp-cvs_20041206-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBuFF48dLMyEl6F20RAnP7AKCBAWQwAqPATbjsb1BfUsvfXsSNVACgtVNu fr/FNbJSxQSSWklPfhAALJc= =M3p0 -END PGP SIGNATURE- Accepted: libopenalpp-cvs-dev_20041206-2_i386.deb to pool/main/o/openalpp-cvs/libopenalpp-cvs-dev_20041206-2_i386.deb libopenalpp-cvs_20041206-2_i386.deb to pool/main/o/openalpp-cvs/libopenalpp-cvs_20041206-2_i386.deb openalpp-cvs-doc_20041206-2_all.deb to pool/main/o/openalpp-cvs/openalpp-cvs-doc_20041206-2_all.deb openalpp-cvs_20041206-2.diff.gz to pool/main/o/openalpp-cvs/openalpp-cvs_20041206-2.diff.gz openalpp-cvs_20041206-2.dsc to pool/main/o/openalpp-cvs/openalpp-cvs_20041206-2.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libaal 1.0.3-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 9 Dec 2004 14:53:10 +0100 Source: libaal Binary: libaal-dev Architecture: source i386 Version: 1.0.3-1 Distribution: unstable Urgency: low Maintainer: Ed Boraas [EMAIL PROTECTED] Changed-By: Domenico Andreoli [EMAIL PROTECTED] Description: libaal-dev - The Reiser4's application abstraction library Changes: libaal (1.0.3-1) unstable; urgency=low . * New upstream release. Files: 2da7d8001c119b0985ddc4fc57b56046 602 libs optional libaal_1.0.3-1.dsc 78b06fcea858031c776f99628c4f7376 328535 libs optional libaal_1.0.3.orig.tar.gz 43daf98a256e2cc4c4173b942e333fc1 76012 libs optional libaal_1.0.3-1.diff.gz c1f20553ac2cb09459b6f4a859581662 26064 libdevel extra libaal-dev_1.0.3-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBuF2cBneQM6IOvFARAvO5AKDq/JZSbf494yZ3xD1ifm5a7Pw4pwCfR66q bEE0jwsOE/O0veJR6eAaDw0= =dIuC -END PGP SIGNATURE- Accepted: libaal-dev_1.0.3-1_i386.deb to pool/main/liba/libaal/libaal-dev_1.0.3-1_i386.deb libaal_1.0.3-1.diff.gz to pool/main/liba/libaal/libaal_1.0.3-1.diff.gz libaal_1.0.3-1.dsc to pool/main/liba/libaal/libaal_1.0.3-1.dsc libaal_1.0.3.orig.tar.gz to pool/main/liba/libaal/libaal_1.0.3.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted osgal-cvs 20041121-3 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 9 Dec 2004 14:02:06 +0100 Source: osgal-cvs Binary: libosgal-cvs-dev osgal-cvs-doc libosgal-cvs Architecture: source all i386 Version: 20041121-3 Distribution: unstable Urgency: low Maintainer: Loic Dachary (OuoU) [EMAIL PROTECTED] Changed-By: Loic Dachary (OuoU) [EMAIL PROTECTED] Description: libosgal-cvs - OpenSceneGraph adapter for OpenAL libosgal-cvs-dev - OpenSceneGraph adapter for OpenAL osgal-cvs-doc - OpenSceneGraph adapter for OpenAL Changes: osgal-cvs (20041121-3) unstable; urgency=low . * versionned depend on osg . * gcc 3.4 fixes Files: e083af938f05c90e444e43604418ba3f 760 libs optional osgal-cvs_20041121-3.dsc f7454080e59aef8f6ae6dd97044bfa03 9148 libs optional osgal-cvs_20041121-3.diff.gz 0f739e4b168de5164f9439096d452d45 32010 libdevel optional osgal-cvs-doc_20041121-3_all.deb 548e7471a23658802d9de27403989567 13522 libdevel optional libosgal-cvs-dev_20041121-3_i386.deb 0190dd165c07702e069814ec5dc29576 49756 libs optional libosgal-cvs_20041121-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBuF0l8dLMyEl6F20RAjqBAKCvcrIGbQKzzMh+uaJG1n/3xWK0qQCdF6Pj jyP6JKIdT37RGUUcvoJ2/yc= =BbIA -END PGP SIGNATURE- Accepted: libosgal-cvs-dev_20041121-3_i386.deb to pool/main/o/osgal-cvs/libosgal-cvs-dev_20041121-3_i386.deb libosgal-cvs_20041121-3_i386.deb to pool/main/o/osgal-cvs/libosgal-cvs_20041121-3_i386.deb osgal-cvs-doc_20041121-3_all.deb to pool/main/o/osgal-cvs/osgal-cvs-doc_20041121-3_all.deb osgal-cvs_20041121-3.diff.gz to pool/main/o/osgal-cvs/osgal-cvs_20041121-3.diff.gz osgal-cvs_20041121-3.dsc to pool/main/o/osgal-cvs/osgal-cvs_20041121-3.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libwww-curl-perl 2.0-8 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 9 Dec 2004 15:27:33 +0100 Source: libwww-curl-perl Binary: libwww-curl-perl Architecture: source i386 Version: 2.0-8 Distribution: unstable Urgency: low Maintainer: Debian Perl Group [EMAIL PROTECTED] Changed-By: Joachim Breitner [EMAIL PROTECTED] Description: libwww-curl-perl - Perl bindings to libcurl Closes: 279459 Changes: libwww-curl-perl (2.0-8) unstable; urgency=low . * Closes: #279459: please rebuild with libcurl3-dev as build dependency Files: a65565622ca6e95eec15303672595032 741 perl optional libwww-curl-perl_2.0-8.dsc 352eebcbf83e590d1bc37805cdac1efc 16151 perl optional libwww-curl-perl_2.0-8.diff.gz c80ceba2ee075871a724d95bfe1ab15a 54602 perl optional libwww-curl-perl_2.0-8_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.3.90 (GNU/Linux) iD8DBQFBuGN99ijrk0dDIGwRAtsgAKCe9HI/i/jdXP4vdJcsLbLcyE6COwCdFDba yPHzj+zEy0/V4OxxTpOnGBA= =Z+Ow -END PGP SIGNATURE- Accepted: libwww-curl-perl_2.0-8.diff.gz to pool/main/libw/libwww-curl-perl/libwww-curl-perl_2.0-8.diff.gz libwww-curl-perl_2.0-8.dsc to pool/main/libw/libwww-curl-perl/libwww-curl-perl_2.0-8.dsc libwww-curl-perl_2.0-8_i386.deb to pool/main/libw/libwww-curl-perl/libwww-curl-perl_2.0-8_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sane-frontends 1.0.13-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 9 Dec 2004 15:38:41 +0100 Source: sane-frontends Binary: sane Architecture: source i386 Version: 1.0.13-2 Distribution: unstable Urgency: medium Maintainer: Julien BLACHE [EMAIL PROTECTED] Changed-By: Julien BLACHE [EMAIL PROTECTED] Description: sane - scanner graphical frontends Closes: 284320 Changes: sane-frontends (1.0.13-2) unstable; urgency=medium . * debian/patches/01_sanei_update.dpatch: + Added; update sanei from sane-backends 1.0.15 to fix a deadlock when scanning over the network (both saned and xscanimage attempt to read at the same time) (closes: #284320). Files: e4abeead30579ed3df72437928f9cbeb 723 graphics optional sane-frontends_1.0.13-2.dsc 00565c64adb3e0486a1ecdf5e934a3d7 20134 graphics optional sane-frontends_1.0.13-2.diff.gz bda969c428983a028ab5ca31321853db 104446 graphics optional sane_1.0.13-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBuGW9zWFP1/XWUWkRArVoAJ4sxbGoI1JcFCjIdIvERzP0dAVsswCbBtQw Uam5FkeR1LprbkCUNegXtHM= =4Gjx -END PGP SIGNATURE- Accepted: sane-frontends_1.0.13-2.diff.gz to pool/main/s/sane-frontends/sane-frontends_1.0.13-2.diff.gz sane-frontends_1.0.13-2.dsc to pool/main/s/sane-frontends/sane-frontends_1.0.13-2.dsc sane_1.0.13-2_i386.deb to pool/main/s/sane-frontends/sane_1.0.13-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ocamlnet 0.98-3 (powerpc source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 9 Dec 2004 15:52:33 +0100 Source: ocamlnet Binary: libocamlnet-ocaml libocamlnet-ocaml-dev Architecture: source powerpc Version: 0.98-3 Distribution: unstable Urgency: low Maintainer: Stefano Zacchiroli [EMAIL PROTECTED] Changed-By: Stefano Zacchiroli [EMAIL PROTECTED] Description: libocamlnet-ocaml - OCaml application-level Internet protocols and conventions librar libocamlnet-ocaml-dev - OCaml application-level Internet protocols and conventions librar Changes: ocamlnet (0.98-3) unstable; urgency=low . * rebuilt against ocaml 3.08.2 Files: f33864af3d0279ad71b399da2f3f00ad 690 devel optional ocamlnet_0.98-3.dsc 52d0eb4bd48384fbdf5bea8011ff87bd 5020 devel optional ocamlnet_0.98-3.diff.gz fa032acbab3baa7baccb17724b7c033b 1578432 libdevel optional libocamlnet-ocaml-dev_0.98-3_powerpc.deb 8486bd3c317c8f33097a53d297245566 12004 libs optional libocamlnet-ocaml_0.98-3_powerpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBuGeN1cqbBPLEI7wRAtbXAJ9jp39vI/zxSjQwOfF60QGVaQ4QbwCeKZde 5cb/Zb5pPa/WeebhSIGsTN8= =2XZS -END PGP SIGNATURE- Accepted: libocamlnet-ocaml-dev_0.98-3_powerpc.deb to pool/main/o/ocamlnet/libocamlnet-ocaml-dev_0.98-3_powerpc.deb libocamlnet-ocaml_0.98-3_powerpc.deb to pool/main/o/ocamlnet/libocamlnet-ocaml_0.98-3_powerpc.deb ocamlnet_0.98-3.diff.gz to pool/main/o/ocamlnet/ocamlnet_0.98-3.diff.gz ocamlnet_0.98-3.dsc to pool/main/o/ocamlnet/ocamlnet_0.98-3.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
