Away from my mail
I'm away from my office until December 11. I am accessing my email but there may be some delay in your receiving a reply. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Conditionally applying an architecture-dependent patch
On Mon, Nov 27, 2006, Shaun Jackman wrote: > When using CDBS, what is the best way to conditionally apply an > architecture-dependent patch. I'm using CDBS, but not yet using a > patch system such as simple-patchsys, dpatch, or quilt, so > recommendations of a patch system are welcome. Currently I have... If you use simple-patchsys, you can prepend before any "include" line: ifeq ($(DEB_HOST_ARCH),m68k) DEB_PATCHDIRS = debian/patches debian/patches/$(DEB_HOST_ARCH) endif to add debian/patches/m68k to the list of directories with patches to apply. Obviously, this can be adapted for many use cases, and different patch orders. -- Loïc Minier <[EMAIL PROTECTED]> "You see, killbots have a preset kill limit. Knowing their weakness, I sent wave after wave of my own men at them until they reached their limit and shutdown."-- Zapp Brannigan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Call for testers: cyrus-sasl2
On Tuesday 28 November 2006 07:53, Fabian Fagerholm wrote: > This new package is a major change compared to the old version. > Therefore, we want people to test it as much as possible! Hi Fabian, can you explain short, what are the changes? Thanks and with kind regards, Jan. -- Write never mails to <[EMAIL PROTECTED]>, you have been warned! -BEGIN GEEK CODE BLOCK- Version: 3.1 GIT d-- s+: a- C+++ UL P+ L+++ E- W+++ N+++ o++ K++ w--- O M V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI- D++ G++ e++ h-- r+++ y+++ --END GEEK CODE BLOCK-- pgp1p1RujCfvv.pgp Description: PGP signature
Mirror pulses now twice a day
Hello. It seems testing and unstable change twice a day now, which is fantastic. Is it going to be announced somewhere or it is still a beta feature? [ I didn't find anything about this in debian-announce or debian-mirrors ]. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mirror pulses now twice a day
* Santiago Vila ([EMAIL PROTECTED]) [061128 11:34]: > It seems testing and unstable change twice a day now, which is fantastic. Also britney runs now twice per day, and ftp-master host has changed (now ries). Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#399284: gettext-el: loads other packages' site-files when byte-compiling for xemacs
On Mon, 20 Nov 2006, Luis Rodrigo Gallardo Cruz wrote: > On Mon, Nov 20, 2006 at 05:56:55PM +0100, Santiago Vila wrote: > > *) should there be a lintian warning for this? > > I took a look at the /u/l/e-c/p/i/* files in my sistem. There are as > many different ways to write them as there are files. Some are using a > slightly edited debhelper template, some have weird package specific > workarounds, and some look like NIH rewrites. I don't think there's much of > a chance to get lintian to do a reasonable job of this. > > Maybe we should all stop the silly GNUEmacs vs XEmacs war, at least > within Debian[1], and get them to converge at least in command line > options. > > [1] Yeah, you may say I'm a dreamer. Following Ockham's razor, I finally fixed this in gettext by using -no-site-file for all emacsen, since it is accepted by all of them. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RC class bug, dataloss grade, No 398373
Hallo, I don't intend to do any advocacy. I just wish to politely point Your attention to the bug 398373 that IMO is critical to be resolved before Etch reach stable statute (that is every day closer and many people are happy because that, including myself :-) Best regards Peter Tuharsky -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RC class bug, dataloss grade, No 398373
severity 398373 grave thanks * Mgr. Peter Tuharsky ([EMAIL PROTECTED]) [061128 12:07]: > I don't intend to do any advocacy. I just wish to politely point Your > attention to the bug 398373 that IMO is critical to be resolved before > Etch reach stable statute (that is every day closer and many people are > happy because that, including myself :-) Thank you for this information, I adjusted the bug severity so that it occurs on our list of critical bugs. Regards, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Call for testers: cyrus-sasl2
On Tue, 2006-11-28 at 11:05 +0100, Jan Wagner wrote: > On Tuesday 28 November 2006 07:53, Fabian Fagerholm wrote: > > This new package is a major change compared to the old version. > > Therefore, we want people to test it as much as possible! > can you explain short, what are the changes? Sure. Some of the most important changes since 2.1.19 (which is in sarge and etch at the moment) -- this includes both upstream and packaging changes -- are: * LDAP auxprop support -- no need to run saslauthd to authenticate against an LDAP directory. * Rewrite of Kerberos / GSSAPI plugins -- plus build against MIT Kerberos instead of Heimdal. * Separate configuration file and plugin directories -- no more "secret conf files in /usr/lib/sasl2" (this change is what broke Postfix). * Security fixes included (sarge has them backported via security updates). * Debug packages and testing tools provided. Plus, more than two years worth of bug fixes and small improvements upstream, a complete rewrite of the Debian packaging using dpatch, collaborative maintenance via Alioth, ... I guess this qualifies as "short" :) Cheers, -- Fabian Fagerholm <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: RC class bug, dataloss grade, No 398373
Le mardi 28 novembre 2006 à 12:16 +0100, Andreas Barth a écrit : > severity 398373 grave > thanks > > * Mgr. Peter Tuharsky ([EMAIL PROTECTED]) [061128 12:07]: > > I don't intend to do any advocacy. I just wish to politely point Your > > attention to the bug 398373 that IMO is critical to be resolved before > > Etch reach stable statute (that is every day closer and many people are > > happy because that, including myself :-) > > Thank you for this information, I adjusted the bug severity so that > it occurs on our list of critical bugs. FWIW, fixing this bug requires changes in the kernel. -- Josselin Mouette/\./\ "Do you have any more insane proposals for me?"
Re: RC class bug, dataloss grade, No 398373
* Josselin Mouette ([EMAIL PROTECTED]) [061128 12:29]: > Le mardi 28 novembre 2006 à 12:16 +0100, Andreas Barth a écrit : > > * Mgr. Peter Tuharsky ([EMAIL PROTECTED]) [061128 12:07]: > > > I don't intend to do any advocacy. I just wish to politely point Your > > > attention to the bug 398373 that IMO is critical to be resolved before > > > Etch reach stable statute (that is every day closer and many people are > > > happy because that, including myself :-) > > > > Thank you for this information, I adjusted the bug severity so that > > it occurs on our list of critical bugs. > > FWIW, fixing this bug requires changes in the kernel. Why that? AFAICR, umount must not return before not everything is written down. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RC class bug, dataloss grade, No 398373
Le mardi 28 novembre 2006 à 12:30 +0100, Andreas Barth a écrit : > > FWIW, fixing this bug requires changes in the kernel. > > Why that? AFAICR, umount must not return before not everything is > written down. I don't think this is always the case. Of course, if the applet is saying things are OK while umount is still running, this can be fixed in the applet, but I wonder whether this would be enough. -- Josselin Mouette/\./\ "Do you have any more insane proposals for me?"
Re: RC class bug, dataloss grade, No 398373
* Josselin Mouette ([EMAIL PROTECTED]) [061128 12:36]: > Le mardi 28 novembre 2006 à 12:30 +0100, Andreas Barth a écrit : > > > FWIW, fixing this bug requires changes in the kernel. > > > > Why that? AFAICR, umount must not return before not everything is > > written down. > > I don't think this is always the case. > > Of course, if the applet is saying things are OK while umount is still > running, this can be fixed in the applet, but I wonder whether this > would be enough. I wonder too. But the current state is definitly dangerous, but - many investigations start with not knowing enough. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Naming a 32-bit/64-bit specific Java package
Hi On Mon, Nov 27, 2006 at 10:54:11AM -0700, Shaun Jackman wrote: > Although SWT uses Java, it is not entirely platform independent. It > requires one jar for 32-bit architectures and one jar for 64-bit > architectures. I could change libswt-gtk-3.2-java to be an What do you mean here? Do you mean that it need a different jars for different architectures or that you need to create different jars for different architectures? > Architecture: any package -- it's currently an all package and does > not support 32-bit architectures -- but this seems like overkill to > me. I'm more inclined to release one Arch:all package for the 32-bit > architectures and one Arch:all package for the 64-bit architectures. A > meta-package would provide the correct dependency for a given > architecture. So, my question, what to name the 32-bit package, the > 64-bit package, and the meta-package? At the moment, I think I'm > leaning towards... > > libswt-gtk-3.2-java32 > libswt-gtk-3.2-java64 > libswt-gtk-3.2-java > > Any other suggestions, or completely different approaches? As I did not fully understand the question, I can not really answer but if it is not architecture independent (all) then it should not be marked as such, which means that it should be marked as any, or the specific architectures that it really support. Regards, // Ola > Thanks, > Shaun > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > > -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Conditionally applying an architecture-dependent patch
On Mon, Nov 27, 2006 at 07:21:53PM -0500, Daniel Jacobowitz wrote: > On Mon, Nov 27, 2006 at 04:04:41PM -0800, Steve Langasek wrote: > > I would normally recommend quilt, but I'm not sure it has a concept of > > conditional patches, which may make things awkward later if further patches > > are required. > > It doesn't. I think I've seen this done before by processing the > series file. But it's not pretty. well you also can have many series files, the basic one, and the extra one for architecture dependants files. I suppose one could hack quite esaily a makefile using quilt and debian/patches/series + debian/patches/series.$(arch) if it exists e.g. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgppiQDyMFMFD.pgp Description: PGP signature
Re: Call for testers: cyrus-sasl2
On Tue, 28 Nov 2006 08:53:23 +0200 Fabian Fagerholm <[EMAIL PROTECTED]> wrote: > Hi everyone, Hi, Fabian, > If you've been using cyrus-sasl2, please consider spending an hour or > so upgrading to version 2.1.22.dfsg1-4 (currently in unstable), > testing, and submitting bug reports indicating success or failure. > Please note that you may have to upgrade other packages as well. > Importantly, Postfix users must upgrade to the unstable version > (2.3.4-2). Ah, presumably only if they're actually using SASL? I have installed the updated libs on a box with postfix, but it's not configured to use SASL at this time. The box also has openldap installed (upgrading to 2.3.29 is what necessitated upgrading sasl), but again, not configured to use SASL. Anyway, that install went fine. I hope today to install it on my primary mail server which has postfix and cyrus-imapd-2.2, both authenticating against an LDAP db, installed; that should be more of a workout. Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Automatically collect hardware information from users?
Luca Capello <[EMAIL PROTECTED]> writes: > Hello! > > On Mon, 27 Nov 2006 13:56:53 +0100, Petter Reinholdtsen wrote: >> [Goswin von Brederlow] >>> Shouldn't that be included in popularity-contest? >> >> Well, I have had the same idea, but never found time to implement >> it. It could be added as an option to popularity-contest, but not >> as part of the normal popcon submission as it would require approval >> from each individual sysadmin with popcon installed before reporting >> hardware information. On the other hand, the hardware content in a >> machine changes very rarely, while the package list change fairly >> regularly. > > Another solution could be to add the feature to popularity-contest, > but only for the first submission and controlled by a debconf question > when the package is installed (thus the sysadmin can approve it). I don't see any difference in the hardware and software info. Both need to be approved and popcon does ask. As for implementing it I would have reportbug make up the report, generate its md5sum (or sha1). If the md5sum does match the last (any one of the last) report only the md5sum is send. Otherwise a full hardware report is added. There are hardware things that do change daily. People plug in usb device or remove them. pcmcia/cardb us cards are frequently inserted and removed. Nowadays you can even hot-plug ram and cpus. I'm not sure how popcon could gather stats for usb usage but maybe it could watch for events. The hardware report could then include "Usb storage: 10% used this week". But maybe that is too much. A simple "Usb storage: yes" would help too. The difference would be that it records that it is used and not just that is is available. >> I suspect it is a good idea to set up the collector as part of >> popcon.debian.org, but let the hardware reporting system be a >> standalone package reporting when the machine is installed or >> something like that, instead of weekly. > > Well, doesn't the debian-installer report [1] [2] already fulfill the > latter case, i.e. when the machine gets installed the first time? Can that be send in via http and does it automatically ask if it should do that? Last I checkd it didn't. Might be a good idea though. > Just my 0.02â¬... > > Thx, bye, > Gismo / Luca > > Footnotes: > [1] /var/log/debian-installer/* > [2] http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=installation-reports MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Naming a 32-bit/64-bit specific Java package
"Shaun Jackman" <[EMAIL PROTECTED]> writes: > Although SWT uses Java, it is not entirely platform independent. It > requires one jar for 32-bit architectures and one jar for 64-bit > architectures. I could change libswt-gtk-3.2-java to be an > Architecture: any package -- it's currently an all package and does > not support 32-bit architectures -- but this seems like overkill to > me. I'm more inclined to release one Arch:all package for the 32-bit > architectures and one Arch:all package for the 64-bit architectures. A > meta-package would provide the correct dependency for a given > architecture. So, my question, what to name the 32-bit package, the > 64-bit package, and the meta-package? At the moment, I think I'm > leaning towards... > > libswt-gtk-3.2-java32 > libswt-gtk-3.2-java64 > libswt-gtk-3.2-java > > Any other suggestions, or completely different approaches? > > Thanks, > Shaun Don't forget that you have 32bit and 64bit needs on amd64. So both packages should be installable. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#400739: ITP: whitedune -- Graphical VRML97 viewer, editor and animation tool
Package: wnpp Severity: wishlist Owner: Philippe Coval <[EMAIL PROTECTED]> * Package name: whitedune Version : 0.29beta483 Upstream Author : Stephen F. White (and others) * URL : http://www.csv.ica.uni-stuttgart.de/vrml/dune/ * License : GPL Programming Lang: C++ Description : Graphical VRML97 viewer, editor and animation tool White dune is a graphical VRML97 editor, simple NURBS/Superformula 3D modeller and animation tool. It has support for animation, real-time interaction, and multimedia (images, movies, and sounds). White dune can read, create and display VRML97 files and let the user change the scenegraph/fields. I have finally built a Q&D package of whitedune-0.29beta483 I will publish it soon and start looking for sponsors Stay tuned : @ http://rzr.online.fr/q/VRML Regards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Call for testers: cyrus-sasl2
On Tue, 28 Nov 2006 07:58:12 -0500 Michael Alan Dorman <[EMAIL PROTECTED]> wrote: > Anyway, that install went fine. I hope today to install it on my > primary mail server which has postfix and cyrus-imapd-2.2, both > authenticating against an LDAP db, installed; that should be more of a > workout. And, in fact, have done so, and other than having to tweak my postfix config a bit---I just started adding stuff referenced in the SASL docs for postfix and at one point it started working---it's working fine, though it's still using saslauthd. My next task, which may get delayed a bit, will be to change things to use the ldap auxprop. Regardless, nothing seems to have regressed, so please accept my congratulations on a job well done. Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Naming a 32-bit/64-bit specific Java package
Ola Lundqvist <[EMAIL PROTECTED]> writes: > Hi > > On Mon, Nov 27, 2006 at 10:54:11AM -0700, Shaun Jackman wrote: >> Although SWT uses Java, it is not entirely platform independent. It >> requires one jar for 32-bit architectures and one jar for 64-bit >> architectures. I could change libswt-gtk-3.2-java to be an > What do you mean here? Do you mean that it need a different jars for > different architectures or that you need to create different jars for > different architectures? > >> Architecture: any package -- it's currently an all package and does >> not support 32-bit architectures -- but this seems like overkill to >> me. I'm more inclined to release one Arch:all package for the 32-bit >> architectures and one Arch:all package for the 64-bit architectures. A >> meta-package would provide the correct dependency for a given >> architecture. So, my question, what to name the 32-bit package, the >> 64-bit package, and the meta-package? At the moment, I think I'm >> leaning towards... >> >> libswt-gtk-3.2-java32 >> libswt-gtk-3.2-java64 >> libswt-gtk-3.2-java >> >> Any other suggestions, or completely different approaches? > > As I did not fully understand the question, I can not really answer > but if it is not architecture independent (all) then it should not > be marked as such, which means that it should be marked as any, or > the specific architectures that it really support. > > Regards, > > // Ola The package is architecture independent except for the register/address size. So i386, m68k, ppc, mips all can use the 32bit version. S390x, amd64, ppc64, mips64 can use the 64bit version. I think having two arch:all packages is better than having 12 arch:any packages where they fall onto two sets of identical apckages. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Naming a 32-bit/64-bit specific Java package
Hi On Tue, Nov 28, 2006 at 02:13:26PM +0100, Goswin von Brederlow wrote: ...CUT... > The package is architecture independent except for the > register/address size. > > So i386, m68k, ppc, mips all can use the 32bit version. > S390x, amd64, ppc64, mips64 can use the 64bit version. > > I think having two arch:all packages is better than having 12 arch:any > packages where they fall onto two sets of identical apckages. But you will have complicated dependency problems. Or at least users will install the wrong version, or do you intend to only release the 64 bit version on 64 bit systems? and the 32 bit version on 32 bit systems? I do not really see the point. If you can not handle this really architecture independently then you should really have it arch: any. An other alternative is to provide both jars in the same package and have a startup routine to select the correct version automatically. Regards, // Ola > MfG > Goswin > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Naming a 32-bit/64-bit specific Java package
On Tue, 28 Nov 2006, Goswin von Brederlow wrote: libswt-gtk-3.2-java32 libswt-gtk-3.2-java64 libswt-gtk-3.2-java Any other suggestions, or completely different approaches? This seems like a really bad solution. The package is architecture independent except for the register/address size. How come it depends on this and is not architecture-dependent in another way? this seems really strange. If it's all bytecode there should be no dependency, and if there are native libraries it surely needs to be arch-dependent for other things. So i386, m68k, ppc, mips all can use the 32bit version. S390x, amd64, ppc64, mips64 can use the 64bit version. I think having two arch:all packages is better than having 12 arch:any packages where they fall onto two sets of identical apckages. I'd actually go for 12 arch:any packages myself, it's an implementation detail the users don't need to see. Alternatively, is it possible to detect at runtime and load different things on different architectures? Is it possible to upload two different versions of the any package to the different architectures? So that you get the -64 version on 64bit archs and the -32 version on 32 bit archs? It's definitely possible to have different versions in the archive for different architectures. Matt -- Matthew Johnson http://www.matthew.ath.cx/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Naming a 32-bit/64-bit specific Java package
Matthew Johnson writes: > On Tue, 28 Nov 2006, Goswin von Brederlow wrote: > > >>> libswt-gtk-3.2-java32 > >>> libswt-gtk-3.2-java64 > >>> libswt-gtk-3.2-java > >>> > >>> Any other suggestions, or completely different approaches? > > This seems like a really bad solution. > > > The package is architecture independent except for the > > register/address size. > > How come it depends on this and is not architecture-dependent in > another way? this seems really strange. If it's all bytecode there > should be no dependency, and if there are native libraries it > surely needs to be arch-dependent for other things. It is all bytecode. There is a wordlength dependency because the shortest Java integer type that will fit an address is used. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Conditionally applying an architecture-dependent patch
Pierre Habouzit <[EMAIL PROTECTED]> writes: > On Mon, Nov 27, 2006 at 07:21:53PM -0500, Daniel Jacobowitz wrote: >> On Mon, Nov 27, 2006 at 04:04:41PM -0800, Steve Langasek wrote: >> > I would normally recommend quilt, but I'm not sure it has a concept of >> > conditional patches, which may make things awkward later if further patches >> > are required. >> >> It doesn't. I think I've seen this done before by processing the >> series file. But it's not pretty. > > well you also can have many series files, the basic one, and the extra > one for architecture dependants files. I suppose one could hack quite > esaily a makefile using quilt and debian/patches/series + > debian/patches/series.$(arch) if it exists e.g. I need exactly the same thing. I was lloking for an include statement for series files though. Something like debian/patches/series.common: version.patch foo.patch barf.patch debian/patches/series.amd64: #include "series.common" amd64.patch debian/patches/series.i386: #include "series.common" i386.patch Quilt does not seem to have this. But it shouldn't be hard to write a makefile target that creates the series file by running debian/patches/series.$ARCH through cpp. That is the way I'm going anyway, hence the syntax. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mirror pulses now twice a day
Andreas Barth <[EMAIL PROTECTED]> writes: > * Santiago Vila ([EMAIL PROTECTED]) [061128 11:34]: >> It seems testing and unstable change twice a day now, which is fantastic. > > Also britney runs now twice per day, and ftp-master host has changed > (now ries). > > Cheers, > Andi Unfortunately that means ftp(2).de.debian.org is broken twice a day now. I don't know what they do but the md5sum of the Packages or Sources files doesn't match the Release file or the Release file doesn't match Release.gpg. A short time later all is fine again. I'm assuming the mirror script is missing --delay-updates to make the 2nd phase mirroring non disruptive. Can someone update the example mirror script provided by debian and then notify all mirror admins to also update their scripts? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Conditionally applying an architecture-dependent patch
On Mon, 2006-11-27 at 16:04 -0800, Steve Langasek wrote: > I would normally recommend quilt, but I'm not sure it has a concept of > conditional patches, which may make things awkward later if further > patches are required. I've never used it but I think that what the "guards" feature of quilt 0.46 does. Unfortunately unstable only has 0.45. Ian. -- Ian Campbell Current Noise: Ektomorf - Outcast Horses are forbidden to eat fire hydrants in Marshalltown, Iowa. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Popularity-contest passes 20000 submitters
I'm happy to report that today Debian popularity-contest passed 2 participants/machines. On http://popcon.debian.org/> you can see 20005 submissions considered. :) >From the stats, one can see that these are the 10 most used non-Debian packages (http://popcon.debian.org/unknown/by_vote): #rank nameinst vote old recent no-files 1 lame3130 1006 1749 375 0 2 transcode 2015 912 724 379 0 3 skype 1464 816 502 145 1 4 opera 1123 704 33186 2 5 sun-j2sdk1.51095 702 33555 3 6 mjpegtools 2097 644 1050 403 0 7 realplayer 1456 632 6749258 8 j2re1.4 858 557 27916 6 9 sun-j2re1.5 812 519 24345 5 10mencoder1884 499 376 1008 1 As you can see, multimedia tools are the most popular tools currently missing in the Debian archive. Not too surprising. :) The submitters are also providing information on their architecture. This give a nice view on the diversity of the Debian community. 16612 84.12% i386 2048 10.37% amd64 460 2.33% arm 266 1.35% powerpc 132 0.67% sparc 49 0.25% alpha 44 0.22% hppa 32 0.16% ia64 25 0.13% mipsel 18 0.09% s390 17 0.09% mips 14 0.07% armeb 12 0.06% kfreebsd-i386 10 0.05% m68k 5 0.03% hurd-i386 2 0.01% kfreebsd-amd64 2 0.01% i486 1 0.01% ppc64 19749 100.00% total (ignored 256 without arch info) If you want your machine to participate as well, all you need to do is 'aptitude install popularity-contest', and accept when asked if you want to participate. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Naming a 32-bit/64-bit specific Java package
Hi On Tue, Nov 28, 2006 at 01:41:22PM +, Matthew Johnson wrote: ...CUT... > >I think having two arch:all packages is better than having 12 arch:any > >packages where they fall onto two sets of identical apckages. > > > > I'd actually go for 12 arch:any packages myself, it's an implementation > detail the users don't need to see. Agree. > Alternatively, is it possible to detect at runtime and load different > things on different architectures? That would be the best thing, but maybe not that easy to implement, or? > Is it possible to upload two different versions of the any package to > the different architectures? So that you get the -64 version on 64bit > archs and the -32 version on 32 bit archs? It's definitely possible to > have different versions in the archive for different architectures. Not unless you make them arch specific, and then you do not really have any benefit from it anyway. If you have defined it arch: all, then that means that it will work on _all_ architectures (if you have fullfilled the dependencies). If you have something that depend on 32 vs 64 bit then it is not architecture independent. We could of course try to optimize and introduce a new category 32 bit and 64 bit, but I do not think it is that interesting to have that, especially if it is just a few (or one) package there. Regards, // Ola -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Conditionally applying an architecture-dependent patch
On 11/28/06, Loïc Minier <[EMAIL PROTECTED]> wrote: If you use simple-patchsys, you can prepend before any "include" line: ifeq ($(DEB_HOST_ARCH),m68k) DEB_PATCHDIRS = debian/patches debian/patches/$(DEB_HOST_ARCH) endif to add debian/patches/m68k to the list of directories with patches to apply. Obviously, this can be adapted for many use cases, and different patch orders. I like the simplicity of this approach. I settled on the following: alpha := 64 amd64 := 64 ia64 := 64 DEB_PATCHDIRS = debian/patches/$($(DEB_HOST_ARCH)) include /usr/share/cdbs/1/rules/simple-patchsys.mk Thanks for your help, Shaun
ITP: stardict-xmlittre
Hi, do you have any news from this ITP? There haven't been any news for 6 months, and no reply to the long description request. I have prepared a package and intend to upload it in a few days if no one objects. Here is the complete ITP information. * Package name: stardict-xmlittre Version : 2.4.2 Upstream Author : Émile Littré François Gannaz <[EMAIL PROTECTED]> * URL : http://francois.gannaz.free.fr/Littre/ * License : Public domain, GPL Programming Lang: XML Description : French Littré dictionary for stardict This package contains a XML version of the French language dictionary written by Émile Littré and published in 1863, suitable for the stardict dictionary software. . Despite its age, this dictionary now fallen in the public domain is still a widely used reference source for French language and litterature. It features 78,423 entries and 239,009 quotes from 3,910 authors. I consider placing the following copyright statement in the copyright file: According to French copyright law, the Littré dictionary has been put into public domain in the late fifties. It is questionable whether the XML formatting is subject to copyright at all. In the case it is, the following license applies. [GPL blurb] -- Josselin Mouette/\./\ "Do you have any more insane proposals for me?" signature.asc Description: Ceci est une partie de message numériquement signée
Re: Naming a 32-bit/64-bit specific Java package
On 11/28/06, Ola Lundqvist <[EMAIL PROTECTED]> wrote: But you will have complicated dependency problems. Or at least users will install the wrong version, or do you intend to only release the 64 bit version on 64 bit systems? and the 32 bit version on 32 bit systems? I do not really see the point. If you can not handle this really architecture independently then you should really have it arch: any. I'm personally leaning towards to two arch: all packages (one 32-bit, one 64-bit) and a meta-package which depends on the right one. I am considering and open to the one arch: any package though. If it affects the decision, the binary package is roughly 1.2 MB. Would anyone that's interested in this technical choice please throw in their opinion? The options are: 1. 2 arch-all packages, one meta-package 2. 12 arch-any packages An other alternative is to provide both jars in the same package and have a startup routine to select the correct version automatically. I veto the runtime option on the grounds that I don't like it. =) Cheers, Shaun -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Naming a 32-bit/64-bit specific Java package
On 11/28/06, Shaun Jackman <[EMAIL PROTECTED]> wrote: I'm personally leaning towards to two arch: all packages (one 32-bit, one 64-bit) and a meta-package which depends on the right one. I am considering and open to the one arch: any package though. If it affects the decision, the binary package is roughly 1.2 MB. I take it back. I implemented the arch: all method, and it wasn't that tricky, but the arch: any method is definitely technically simpler. Without a good reason, I can't see why I shouldn't use the simpler method. The argument for the arch: any case is obvious -- it's simpler -- what's the best argument for the arch: all case? Cheers, Shaun -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Which architectures are 64-bit?
Here is my list: 64-bit: alpha amd64 ia64 The rest are 32-bit. Am I missing any? Perhaps this is a suitable feature for dpkg-architecture. Cheers, Shaun -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Which architectures are 64-bit?
On mar, 2006-11-28 at 14:41 -0700, Shaun Jackman wrote: > Am I missing any? sparc64, ppc64, ... -- Yves-Alexis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Naming a 32-bit/64-bit specific Java package
Shaun Jackman wrote: > On 11/28/06, Shaun Jackman <[EMAIL PROTECTED]> wrote: >> I'm personally leaning towards to two arch: all packages (one 32-bit, >> one 64-bit) and a meta-package which depends on the right one. I am >> considering and open to the one arch: any package though. If it >> affects the decision, the binary package is roughly 1.2 MB. > > I take it back. I implemented the arch: all method, and it wasn't that > tricky, but the arch: any method is definitely technically simpler. > Without a good reason, I can't see why I shouldn't use the simpler > method. The argument for the arch: any case is obvious -- it's simpler > -- what's the best argument for the arch: all case? > > Cheers, > Shaun > > Less archive/mirror bloat. signature.asc Description: OpenPGP digital signature
Re: Which architectures are 64-bit?
On Tue, Nov 28, 2006 at 02:41:13PM -0700, Shaun Jackman wrote: > Here is my list: > 64-bit: alpha amd64 ia64 > The rest are 32-bit. > Am I missing any? Nope. > Perhaps this is a suitable feature for dpkg-architecture. You could just as well do a build-time test of the system. :) Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request to mailing list Pkg-qof-maintainers rejected
On Monday 11 September 2006 11:11, Steve Langasek wrote: > On Mon, Sep 11, 2006 at 09:22:08AM +0200, Thomas Weber wrote: > > Am Sonntag, den 10.09.2006, 21:22 -0700 schrieb Steve Langasek: > > > For my part, I find it pretty offensive that a mailing list that's set > > > as the maintainer of a package would have mail filters configured this > > > way in the first place. For the samba packaging team, for instance, > > > I've taken pains to adjust the spam filters to allow bts mail in > > > automatically before ever setting the maintainer field to point to the > > > list; I would expect other packaging teams to take the same care. > > > > Can you publish/describe your setup? > > Sorry, I should have been clearer: to date, we have not yet pointed the > maintainer field at this list, out of concern over bouncing legitimate bug > mail. I've just made this change in the svn repo though, so we'll have a > chance to test these rules out following the next upload and I'll be happy > to publish the details as soon as I know we have something that works as > intended. Did your rules worked as intended? Can you publish your setup now? Thanks, Frank -- "Die beiden Männer sonnten sich in dem herrlichen Gefühl, weitaus weniger zu wissen als gewöhnliche Leute, die nur von gewöhnlichen Dingen nichts wußten." -- Terry Pratchett in "Das Erbe des Zauberers" pgpRJzmF54mgG.pgp Description: PGP signature
Re: Mirror pulses now twice a day
On Tue, Nov 28, 2006 at 05:04:13PM +0100, Goswin von Brederlow wrote: > Andreas Barth <[EMAIL PROTECTED]> writes: > > > * Santiago Vila ([EMAIL PROTECTED]) [061128 11:34]: > > > It seems testing and unstable change twice a day now, which is fantastic. > > > > Also britney runs now twice per day, and ftp-master host has changed > > (now ries). That shows that push mirroring should be the prefered solution to make mirrors, since it is frequency-proof :) http://www.debian.org/mirrors/push_mirroring > Unfortunately that means ftp(2).de.debian.org is broken twice a day > now. > > I don't know what they do but the md5sum of the Packages or Sources > files doesn't match the Release file or the Release file doesn't match > Release.gpg. A short time later all is fine again. > > I'm assuming the mirror script is missing --delay-updates to make the > 2nd phase mirroring non disruptive. > > Can someone update the example mirror script provided by debian The example mirror script was updated ten days ago after a discussion on debian-mirrors : http://lists.debian.org/debian-mirrors/2006/11/threads.html#2 The up to date script is available at http://www.debian.org/mirrors/anonftpsync > and then notify all mirror admins to also update their scripts? Sure, updating anonftpsync was only the first step, the second one will come soon. Regards, -- Simon Paillard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt hangs for ever
> "Henrique" == Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: Henrique> Use --save-after-login and pbuilder login to open the Henrique> chroot, add the new apt key, and only then run the Henrique> update. I tried that, it didn't help. The only solution I found when I checked last was to run apt-get via strace... I also have plenty of diskspace. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Which architectures are 64-bit?
* Shaun Jackman ([EMAIL PROTECTED]) wrote: > 64-bit: alpha amd64 ia64 mips/mipsel, sparc, s390 and powerpc can all come in a 64-bit flavors, iirc. Thanks, Stephen signature.asc Description: Digital signature
Re: Which architectures are 64-bit?
* Steve Langasek ([EMAIL PROTECTED]) wrote: > On Tue, Nov 28, 2006 at 02:41:13PM -0700, Shaun Jackman wrote: > > 64-bit: alpha amd64 ia64 > > The rest are 32-bit. > > > Am I missing any? > > Nope. *smirk > > Perhaps this is a suitable feature for dpkg-architecture. > > You could just as well do a build-time test of the system. :) Or dpkg-architecture could. Thanks, Stephen signature.asc Description: Digital signature
Re: Which architectures are 64-bit?
On Tue, Nov 28, 2006 at 08:03:33PM -0500, Stephen Frost wrote: > * Shaun Jackman ([EMAIL PROTECTED]) wrote: > > 64-bit: alpha amd64 ia64 > mips/mipsel, sparc, s390 and powerpc can all come in a 64-bit > flavors, iirc. None of which are full Debian ports, nor TTBOMK do we ship JVMs for any of these. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Automatic bootstrap?
As I just installed an amd64 system, I discovered that the cmucl is not already available for that port. If I'm not mistaken, cmucl needs some manual bootstrapping. Wouldn't it be useful to make it possible for a package needing bootstrap to specify it, so that an unattended bootstrap be possible, e.g. on a buildd? If yes, has it already been tried? Curiously, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Ftpmaster bug reports are not processed nearly fast enough.
To start with, congratulations to the ftpmasters for keeping up with the NEW queue. Unfortunately, this email is going to be a case of damning with faint praise I'm seeing bugs which were filed as removal requests as early as August 14 which are still waiting for processing. Unfortunately, they are really beginning to pile up; there are slightly over 100 now, so I think it will take quite a lot of work to catch up. As for the bugs requesting change of priorities in the Overrides file, many appear to simply be ignored permanently. #263887 is the canonical example. I recommend eliminating the overrides file for packages of priority 'standard' and lower, and instead always allowing package maintainers to set their own package priority among 'extra', 'optional', and 'standard', As for bugs requesting stuff which actually needs the manual touch of an ftpmaster, like #224469, they're also ignored. I pinged in August. This bug, for which a trivial solution was described in December 2005, is getting rather urgent; once woody is removed from ftpmaster.debian.org and moved to archive.debian.org, it will be a license violation issue. It's really rather discouraging that the ftpmasters have not fixed this. FTPmaster is *still* one of the biggest bottlenecks in the whole of Debian. (The other one is DAM; "0 applicants became maintainers."). It needs more people, specifically on the routine processing of removals, new packages, and override changes, so that the existing highly-qualified people can focus on the more unusual and complicated problems. There's really no good reason for the removal requests to be delayed like this. There are plenty of people who are competent to go through removal requests and process them, starting with some of the more careful QA people. You don't need to give full ftpmaster powers out in order to do that; set up a system where DDs on the 'privileged list' can trigger package removal, much like DDs on the right 'privileged list' can hint packages into testing. It should be pretty easy to set up for someone who understands the DAK scripts, since it seems that the scripts do most of the removal work already. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
