Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org
* Tollef Fog Heen > It's also a nice way for other packages to update exim's configuration > -- I'm considering shipping files for mailman, for instance. It would > be nice if SA did the same and so on. But you'd do it so that the routers/transports you add are disabled by default, right? I would consider it outright evil to change the generated configuration the Exim binary use, when you cannot be sure if the user has changed other files under conf.d/. -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to force an update if package names changed?
Hendrik Frenzel <[EMAIL PROTECTED]> writes: > Hi, > > i got a question regarding package updates. > > If I have a source pack-1.1 from which some packages including > pack-gui-lang-de-1.1_2 (Provides: pack-gui-lang) are build. > > Now i want to build the languages in seperade packages say > pack-lang-de-1.1. How can it be done to force an update between the > package from the main source (pack-gui-lang-de-1.1_2) to the package > from the seperated lang source (pack-lang-de-1.1_?)? > > Provides: pack-gui-lang-de, pack-gui-lang > Conflicts: pack-gui-lang-de You forgot Replaces as suggested in policy. > doesn't seem to work, since the old pack-gui-lang-de packages are still > installed. > > Any hints? > > Thanks in advice > Hendrik Create a dummy package for the old one that Depends on the new and add a versioned Conflict to the old one. Saddly that is the only way to make sure it gets updated. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org
On Sun, 20 Feb 2005 10:07:48 +0100, Tore Anderson <[EMAIL PROTECTED]> wrote: >* Tollef Fog Heen > > It's also a nice way for other packages to update exim's configuration > > -- I'm considering shipping files for mailman, for instance. It would > > be nice if SA did the same and so on. > > I would consider it outright evil to change the generated > configuration the Exim binary use, when you cannot be sure if the user has > changed other files under conf.d/. If people change the configuration, they will have to bear with breakage this has caused. I would consider it a feature to have mailman work immediately after installation on a default system, and the exim4 configuration scheme has explicitly invented with that possibility in mind. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org
Marc writes: > I would consider it a feature to have mailman work immediately after > installation on a default system, and the exim4 configuration scheme has > explicitly invented with that possibility in mind. I would consider it an obnoxious bug for the installation of a package to alter my email configuration. At least make enabling the change a Debconf question. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org
* Tore Anderson | * Tollef Fog Heen | | > It's also a nice way for other packages to update exim's configuration | > -- I'm considering shipping files for mailman, for instance. It would | > be nice if SA did the same and so on. | | But you'd do it so that the routers/transports you add are disabled by | default, right? No. If you have exim4 installed and install mailman, it's a reasonable expectation that you want to use those two together. | I would consider it outright evil to change the generated | configuration the Exim binary use, when you cannot be sure if the | user has changed other files under conf.d/. It will be documented in NEWS.Debian ifwhen I get around to it. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#296127: ITP: octave-gtk -- GTK+ binding for GNU Octave
Package: wnpp Severity: wishlist * Package name: octave-gtk Version : 0.1 Upstream Author : Muthiah Annamalai <[EMAIL PROTECTED]> * URL : http://octave-gtk.sf.net * License : GPL Description : GTK+ binding for GNU Octave Octave GTK+ is a Octave binding for GTK+, to help develop GUI programs from Octave, with GTK+. It aims to aid fast creation of scientific programs that need GUI's as well as number crunching power. I already built an experimental package and put it at the following apt-getable repository: http://pkg-octave.alioth.debian.org/octave-gtk The maintainer of this package will be the Debian Octave Group (http://alioth.debian.org/projects/pkg-octave). -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8-1-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org
Marc Haber <[EMAIL PROTECTED]> schrieb: > On 18 Feb 2005 17:54:42 -0800, Thomas Bushnell BSG <[EMAIL PROTECTED]> > wrote: >>Still, one piece of useful advice has come from the thread: that the >>installation comment should tell the user what to do, rather than what >>not to do. > > Fixing this is unfortunately a non-option for sarge. > > |[11/[EMAIL PROTECTED]:~/chroot/sid-exim4/home/mh/exim4/trunk$ find debian/po > -name '*.po' | wc -l > |40 > |[12/[EMAIL PROTECTED]:~/chroot/sid-exim4/home/mh/exim4/trunk$ > > The translators would kill us for doing that to them at this stage of > the release. I don't know how these translation things are handled technically. But since the intended meaning didn't change at all, I don't see why it is better to have a "bad" english version and 40 equally "bad" translated versions, over having a better english version, 10 better translated versions, and 30 working translated versions with formally one fuzzyness? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: mplayer, the time has come
hi I have uploaded mplayer 1.0pre6a-3 It ships a correctly repackaged upstream source; it has a 'debian/rules get-orig-source' (as asked in debian-devel) that creates the .orig.tar.gz It should appear in http://qa.debian.org/~anibal/debian-NEW.html and in I will put a copy in http://tonelli.sns.it/pub/mplayer/sarge please comment a. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#296140: ITP: mydms -- Document Management system
Package: wnpp Severity: wishlist Owner: Miguel Gea Milvaques <[EMAIL PROTECTED]> * Package name: mydms Version : 1.4.3 Upstream Author : Markus Whestfal * URL : http://dms.markuswestphal.de/about.html * License : GPL Description : Document Management System MyDMS is an open-source document-management-system based on PHP and MySQL published under the GPL. . Features: * Upload files through web-interface * Create folders to group your documents * Edit document and folder properties online * Detailed information on uploaded documents * Lock and unlock documents * Update documents - old versions are saved * Control access via detailed ACLs (access control lists) * And more... -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10 Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org
* John Hasler ([EMAIL PROTECTED]) [050220 15:25]: > Marc writes: > > I would consider it a feature to have mailman work immediately after > > installation on a default system, and the exim4 configuration scheme has > > explicitly invented with that possibility in mind. > I would consider it an obnoxious bug for the installation of a package to > alter my email configuration. At least make enabling the change a Debconf > question. why, in the default case? Is it also an "obvious bug" to change your apache configuration? 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org
> I don't know how these translation things are handled technically. But > since the intended meaning didn't change at all, I don't see why it is > better to have a "bad" english version and 40 equally "bad" translated > versions, over having a better english version, 10 better translated > versions, and 30 working translated versions with formally one > fuzzyness? One fuzzyness means the whole screen is shown in English. So the choice is between a supposedly "perfect" English screen shown to all users, no matter which language they prefer to use.and 40 quite good screens which users may read in their own language. The choice is also between translators happy to have achieved a full process and have a complete translation in their languageand angry teams because the templates have been broken again. Purely psychological issue, surebut that counts more than you may imagine. And, besides all this, a huge time wasting ot i18n coordinators trying to get updates in by warning translators, then warn them again...then make a status report to the package maintainersusually two weeks delay if we want to have the same translation ratio we had before the change decision. I handled the last change with exim4 maintainers and, believe me, that had a cost in matter of time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org
Christian Perrier <[EMAIL PROTECTED]> wrote: >> I don't know how these translation things are handled technically. But >> since the intended meaning didn't change at all, I don't see why it is >> better to have a "bad" english version and 40 equally "bad" translated >> versions, over having a better english version, 10 better translated >> versions, and 30 working translated versions with formally one >> fuzzyness? > > One fuzzyness means the whole screen is shown in English. Oh, sorry. I didn't think so far. But in fact in such case one could fake the translation and simply unfuzzy it without making a change, of course not before the unchanged file has been stored, and sent to the translators. No, it's not a good idea. Let's keep the change in mind for etch. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org
On Sun, 20 Feb 2005 08:06:46 -0600, John Hasler <[EMAIL PROTECTED]> wrote: >At least make enabling the change a Debconf >question. Impossible with current policy since maintainer scripts are forbidden to mess with dpkg-conffiles. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org
Quoting Frank Küster ([EMAIL PROTECTED]): > No, it's not a good idea. Let's keep the change in mind for etch. That, I fully agree with...:) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ITO: xkeycaps
I intend to orphan xkeycaps. xkeycaps is no longer maintained upstream (see http://www.jwz.org/xkeycaps/) and I haven't changed the Debian package in over two years, The package is in reasonable shape, but there are a number of bugs on record (http://bugs.debian.org/src:xkeycaps) which could be addressed by someone with more interest in xkeycaps than I have. If you are interested in taking over this package, do let me know. Ray -- A Microsoft Certified System Engineer is to information technology as a McDonalds Certified Food Specialist is to the culinary arts. Michael Bacarella commenting on the limited value of certification. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug 295175 followup
Bug 295175, the grave xfree86-common bug that was blocking many autobuilds has now had its fix uploaded to the archive. Unfortunately, the xfree86 build with the fix is failing, and looking at the build logs, I think it's because the buildd chroots are still corrupted with the damage that the buggy package did. We need the buildd maintainers to all clean the chroots by hand (perhaps it would be best to just rebuild them from scratch), and then reschedule builds of xfree86. Regardless of exactly what the correct procedure is, is there someone who is taking the lead of making sure all this happens? More than a few packages have gotten stalled by the corrupted chroots on the buildd's causing spurious build failures and it needs by-hand work to correct each one. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#217094: Ongoing efforts with packaging of GNU polyxmass
Package: wnpp Followup-For: Bug #217094 The packaging of the GNU polyxmass software suite for simulation and analysis of mass spectrometric data of (bio-)polymers has improved dramatically these last days. The packages are available from http://www.polyxmass.org/debian and are currently reviewed by a Debian Developer. Sincerely, Filippo Rusconi Author/Maintainer GNU polyxmass (www.polyxmass.org) -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8-fr8 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#296177: ITP: flpsed -- a WYSIWYG pseudo PostScript editor
Package: wnpp Severity: wishlist Owner: Morten Brix Pedersen <[EMAIL PROTECTED]> * Package name: flpsed Version : 0.3.2 Upstream Author : Johannes Hofmann <[EMAIL PROTECTED]> * URL : http://www.ecademix.com/JohannesHofmann/ * License : GPL Description : a WYSIWYG pseudo PostScript editor flpsed is a WYSIWYG pseudo PostScript editor. "Pseudo", because you can't remove or modify existing elements of a document. But flpsed lets you add arbitrary text lines to existing PostScript 1 documents. Added lines can later be reedited with flpsed. Using pdftops, which is part of xpdf one can convert PDF documents to PostScript and also add text to them. flpsed is useful for filling in forms, adding notes etc. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10 Locale: LANG=da_DK.UTF-8, LC_CTYPE=da_DK.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Add you site
Hello , Planstotravel.com is a website all about vacation , holiday and travel . We already have more than 5000 links on our website to hotels , resorts campsites / campings etc . Planstotravel.com have more than 35000 umique visitors per day . Take all those visitors to your website and to your hotel , resort , campings etc . Add your link here http://www.planstotravel.com/signup/index.htm . Note !! When you ad your link on our website , we are submitting your link to 250.000 search engines as a free service ! Also you can advertise on http://www.planstotravel.com/ , to take all those visitors to your website . Get advertising information on http://www.planstotravel.com/advertising.php We hope to see you soon on our website . Best Regards HT Oud PlansToTravel.com If you dont want this email no more , mail us at [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Clint Byrum spamaps.org> writes: > Now, can someone please tell me how messages like the one below, and > others, aren't indicative that debian should drop s390, mipsel, and > maybe hppa from the list of architectures? How about we release for > i386, sparc, and powerpc, and let the others release on their own > schedule? This business of supporting 11 architectures and making sure > they're all 100% right before releasing is just about the worst idea > ever. Couldn't agree more. Our chances of actually releasing one day could only increase if we dropped arches such as mipsel, s390, m68k, ... and concentrated on those that actually mattered: i386, powerpc, amd64 -- and I'll gladly add a few more. But a total of eleven is insane. But then it doesn't matter anymore. These days, Debian is "infrastructure". We no longer make releases. We provide the basis from which others make releases -- Ubuntu, Prodigy, Knoppix, Custom debian dists etc pp. Still, the hours we maste on fixing, building, maintaining, ... code on unused platforms is hysterical waste of resources. Resources we don't really have. It would be better to concentrate on a core of packages, and platforms, and then get on with it. One day it will break the infrastructure provision, at which point someone will fork our high-priority core packages. Dirk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote: > Clint Byrum spamaps.org> writes: > > Now, can someone please tell me how messages like the one below, and > > others, aren't indicative that debian should drop s390, mipsel, and > > maybe hppa from the list of architectures? How about we release for > > i386, sparc, and powerpc, and let the others release on their own > > schedule? This business of supporting 11 architectures and making sure > > they're all 100% right before releasing is just about the worst idea > > ever. > > Still, the hours we maste on fixing, building, maintaining, ... code on > unused platforms is hysterical waste of resources. Resources we don't > really have. I'd like to see your numbers on how many manhours have been wasted in the past, say, 6 months on fixing code on unused platforms which would have gone into other things had those architectures not been in Debian. - Matt signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ...
Matthew Palmer <[EMAIL PROTECTED]> writes: > On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote: >> Clint Byrum spamaps.org> writes: >> > Now, can someone please tell me how messages like the one below, and >> > others, aren't indicative that debian should drop s390, mipsel, and >> > maybe hppa from the list of architectures? How about we release for >> > i386, sparc, and powerpc, and let the others release on their own >> > schedule? This business of supporting 11 architectures and making sure >> > they're all 100% right before releasing is just about the worst idea >> > ever. >> >> Still, the hours we maste on fixing, building, maintaining, ... code on >> unused platforms is hysterical waste of resources. Resources we don't >> really have. > > I'd like to see your numbers on how many manhours have been wasted in the > past, say, 6 months on fixing code on unused platforms which would have gone > into other things had those architectures not been in Debian. > > - Matt Not to mention that i386 is the most non working architecture of them all when it comes to the buildd and m68k probably the one with the fastest responce time. And how does having gtk not being blocked for a few days by a buildd get ftp-master to implement t-p-u and testing-security any faster, which is what we've all been waiting for the last 6+ month. Not to mention the number of arm, mips, mipsel, m68k, hppa, alpha, ia64, s390 developers that would drop away starting their own distribution depriving Debian of manpower. A lot of bugs are found by those extra architectures Debian supports and also fixed by their porters. Nothing better to find bugs than a large variety. Dropping some archs would only have one benefit. There would be mirror space to include amd64. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote: > Clint Byrum spamaps.org> writes: > > Now, can someone please tell me how messages like the one below, and > > others, aren't indicative that debian should drop s390, mipsel, and > > maybe hppa from the list of architectures? How about we release for > > i386, sparc, and powerpc, and let the others release on their own > > schedule? This business of supporting 11 architectures and making sure > > they're all 100% right before releasing is just about the worst idea > > ever. > Our chances of actually releasing one day could only increase if we dropped > arches such as mipsel, s390, m68k, ... and concentrated on those that > actually > mattered: i386, powerpc, amd64 -- and I'll gladly add a few more. But a > total of > eleven is insane. > But then it doesn't matter anymore. These days, Debian is "infrastructure". > We no longer make releases. We provide the basis from which others make > releases > -- Ubuntu, Prodigy, Knoppix, Custom debian dists etc pp. Any maintainer who believes that trying to release "doesn't matter" is invited to file serious bugs against all his optional/extra packages so that the release team can remove them from testing outright rather than worrying about whether they're in a releasable state. The more people believe that releasing does not matter, the longer it takes the rest of us to pull off a release. > Still, the hours we maste on fixing, building, maintaining, ... code on unused > platforms is hysterical waste of resources. Resources we don't really have. It > would be better to concentrate on a core of packages, and platforms, and then > get on with it. One day it will break the infrastructure provision, at which > point someone will fork our high-priority core packages. The four most common porting problems for software are endianness (differs between i386/amd64 and powerpc), word size (differs between i386/powerpc and amd64), char signedness (differs between i386/amd64 and powerpc), and use of non-PIC code in shared libs (which is a problem on *all* non-i386 platforms). A fifth, less significant portability issue involves arm-specific weirdness with floating point handling, which affects only a handful of packages that try to do their own direct manipulation of floats. So which portability problems are the ones that we waste time fixing code for? I certainly don't think that maintainers/packages should be penalized for failures of porters to provide viable build infrastructure for their architectures, and I think that we should have stricter standards in this area for etch; but the actual amount of work that maintainers have to do to their packages that's only of benefit to a single, little-used architecture is negligible. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org
* Tollef Fog Heen > No. If you have exim4 installed and install mailman, it's a > reasonable expectation that you want to use those two together. But you cannot know if I have changed, added, or removed files under conf.d/ in such a way which would make your drop-in routers and transports break the entire configuration. The files are after all configuration the user is allowed to change as he pleases. Policy 10.7.3 says: Configuration file handling must conform to the following behavior: * local changes must be preserved during a package upgrade, [..] Even though you're not strictly changing _a_ configuration file by dropping files under conf.d, you're changing the configuration that Exim ends up reading. I've always felt that the general principle that requirement is there for is something like "the user should be able to trust us not to fuck around with his custom configuration behind his back". And unless you ensure that the snippets belonging to exim4-config isn't changed [in a significant way], you certainly will violate that principle. > It will be documented in NEWS.Debian ifwhen I get around to it. As far as I know NEWS.Debian is only displayed on upgrades, so that isn't sufficient. That said, documenting that you're doing something undesireable isn't really an excuse for doing it in the first place. Please consider putting the snippets somewhere else, like under /etc/mailman/, and rather tell the user where to symlink them under /etc/exim4/conf.d/. -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Feb 21, Steve Langasek <[EMAIL PROTECTED]> wrote: > So which portability problems are the ones that we waste time fixing code > for? You are right, close to none. The usual sources of problems are slow or broken buillds, broken toolchains and buggy kernels. -- ciao, Marco signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Dirk Eddelbuettel <[EMAIL PROTECTED]> writes: > Our chances of actually releasing one day could only increase if we > dropped arches such as mipsel, s390, m68k, ... and concentrated on > those that actually mattered: i386, powerpc, amd64 -- and I'll > gladly add a few more. But a total of eleven is insane. There isn't any evidence I've seen that these arch's actually slow down the release. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org
* Marc Haber > If people change the configuration, they will have to bear with > breakage this has caused. If the users cannot safely change Exim's configuration (save using the Debconf scripts), it cannot be considered "configuration" by any Debian standard I have ever seen. And if so, /etc is certinly not the right place for it. I really hope you didn't mean it the way I interpreted you.. -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#294491: RFA: povray -- Persistence of vision raytracer
Daniel Burrows <[EMAIL PROTECTED]> writes: >> It's disheartening because while there seem to be other free ray-tracers >> out there with even better rendering quality than povray, I've not found >> one with anything like povray's wonderfully expressive input language -- >> most other projects seem to follow the "all input is giant lists of >> primitives output by modelling programs" method. Anyone know of a >> similarly expressive alternative to povray? > > Would it be feasible to create a frontend that takes in a higher-level > language and spits out a list of primitives in the format that the better > free raytracers understand? That would work for some things, but I suspect it's very hard to approach the richness of what povray offers. In particular, it's probably possible to do this for "objects", as long as the underlying tracer supports enough primitive object types (my impression is that some ray-tracers only support primitives like meshes, which I suppose fits well with GUI modelling programs, but seems pretty anemic for anyone used to povray). One of the coolest things about povray is its algorithmic texture support; I have no idea if anything else even gets close. BTW, I don't have much experience with other free ray-tracers; usually I look at them just long enough to get depressed at how impoverished they seem compared with povray (even if they have more solid basic rendering)... Does anyone here have any pointers? -Miles -- Somebody has to do something, and it's just incredibly pathetic that it has to be us. -- Jerry Garcia
Bug#296210: ITP: xchat-systray -- xchat systray notification icon
Package: wnpp Severity: wishlist Owner: David Moreno Garza <[EMAIL PROTECTED]> * Package name: xchat-systray Version : 2.4.5 Upstream Author : Patrizio Bassi <[EMAIL PROTECTED]> * URL : http://www.blight.tk/ * License : GPL Description : xchat systray notification icon Plugin for IRC client X-Chat which adds an icon in your systray that flashes when you got highlighted message. Configurable events and actions. Integrates with KDE, GNOME and XFce4. -- System Information: Debian Release: 3.1 APT prefers experimental APT policy: (500, 'experimental'), (250, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.6.9-powerpc Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > Dirk Eddelbuettel <[EMAIL PROTECTED]> writes: > >> Our chances of actually releasing one day could only increase if we >> dropped arches such as mipsel, s390, m68k, ... and concentrated on >> those that actually mattered: i386, powerpc, amd64 -- and I'll >> gladly add a few more. But a total of eleven is insane. > > There isn't any evidence I've seen that these arch's actually slow > down the release. Getting debian-installer working across all architectures was certainly an issue at one time, though that time passed a few months ago. Also, really huge stuff, like KDE, cannot be uploaded as frequently as perhaps the maintainers would like because it kills the slower buildd's for a few days. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Sun, 20 Feb 2005, Brian Nelson wrote: > > There isn't any evidence I've seen that these arch's actually slow > > down the release. > > Getting debian-installer working across all architectures was certainly > an issue at one time, though that time passed a few months ago. Well, if the installer ever holds etch, we can think about it. Right now, the installer is not even semi-close to being the worst problem. > Also, really huge stuff, like KDE, cannot be uploaded as frequently as > perhaps the maintainers would like because it kills the slower buildd's > for a few days. The answer to that is to setup a dist-cc cluster for these archs, where only the master node is in the slow arch, and everything else is a fast arch. i.e. far stricter buildd requirements would fix it. Even mirror space problems can be fixed without dropping an arch. -- "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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pwc-source headed for unstable this weekend
Scripsit Eduard Bloch <[EMAIL PROTECTED]> >> it might be a good idea for make-kpkg to check whether the >> necessary files are present in the kernel tree (and warn loudly if >> they are not) when one tries to build modules. On the other hand I >> have no idea what would be involved in checking this, so it might >> be probitively difficult. > It is difficult. Many modules need just the kernel build scripts (which > are included in most kernel-headers package nowadays, either completely > or shared with others via the kernel-kbuild package). Hm, I thought it was just a matter of some generated .o file from which some magic checksum of "struct_module" was imported during the finalization process. > Currently there is no see what the module-source really needs. > Maintainers document that in README.Debian but nobody reads that. Not all maintainers do. I recently took over vaiostat-source after day of trial-and-error hocus pocus hacking made me able to compile it on 2.6 kernels. I would most happily document in README.Debian what it needs to have present, but I have no idea what the right answer is. This probably means that I shouldn't ever have thought of maintaining a kernel module package, but it works better now with recent kernels than the old maintainer was able to make it do [1], so I'm not too ashamed of myself. [1] Which was not his fault; he had the very excellent excuse of not anymore owning the hardware that the module is supposed to communicate with, and thus not being able to test anything himself. -- Henning Makholm "Also, the letters are printed. That makes the task of identifying the handwriting much more difficult." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The ghost of libc-dev
Scripsit Bill Allombert <[EMAIL PROTECTED]> > On Sat, Feb 19, 2005 at 12:58:15AM +, Henning Makholm wrote: >> I don't think there can be much argument that anything that Provides >> c-compiler also has to make sure that standard header files like >> or are present on the system. Otherwise it >> wouln't be able to do its job, namely compiling C programs. > There is no definition of c-compiler: bcc Provides c-compiler > but generate 16bit 8086 code that don't run natively on Linux. > This make the c-compiler virtual package quite useless. Erm.. right. That somewhat weakens my argument. I naively assumed without checking that c-compiler was something that provided a /usr/bin/cc alternative. > On the other hand, the ISO C standard mandate stdio.h and unistd.h, so > it seems reasonnable to expect ISO C compliants compilers to depend on > libc-dev. On the other-other hand, doesn't the ISO C standard expliclily say that stdio.h and unistd.h do not need to be files in the file system? C89 did, at least. (No, I don't think this matters much.) >> > Really, I think the simplest answer is a tool that detects *all* of the >> > relevant -dev packages, in a simple and automated fashion, >> I agree with this - it would need some compile-time parallel to shlibs >> files in order to discover which possibly virtual package is the right >> one to depend on to get /usr/include/foo.h. > Actually, there might be no need for virtual packages, since the tool > will be run at compile time and can look up which libc is in use. Libc would not be the only thing decided. Imagine you're creating libbar-dev and one of the .h files you ship contains #include When the -dev package is built, dpkg says that /usr/include/foo.h comes from libfoo3-dev, which Provides libfoo-dev, libfoo3.1-dev and obsoletepackagename-dev. If you were an automated -dev detector, which package name would you let libbar-dev Depend on? You can't tell without knowing something about which binary and source compatibility policy libfoo tries to follow. >> However, for as long as we have to trace the dependencies by hand, I >> see little benefit in requiring an explicit dependency on a libc-dev. > There is little benefit, yes. However I feel it is cleaner that way. The > -dev package #include files from another -dev package and that warrant a > dependency. It is cleaner to not make libc-dev an exception. I have no objections if you as a maintainer of a library package wishes to include libc-dev among the dependencies of your -dev. I don't think it hurts anybody much. But should it be a bug if somebody else does differently for his package? I don't think so. -- Henning MakholmBlessed are those with no shoes, for the earth shall kiss them. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug 295175 followup
On Sun, Feb 20, 2005 at 01:16:58PM -0800, Thomas Bushnell BSG wrote: > Bug 295175, the grave xfree86-common bug that was blocking many > autobuilds has now had its fix uploaded to the archive. > > Unfortunately, the xfree86 build with the fix is failing, and looking > at the build logs, I think it's because the buildd chroots are still > corrupted with the damage that the buggy package did. Well, the damage is in part the package's fault, and in part (apparently) dpkg's -- if you do a --purge of an installed package, the package does not pass through the "removed ok conffiles-only" stage. Instead, despite the package payload being removed, the package is marked as still being installed, which is where all this grief comes from. > We need the buildd maintainers to all clean the chroots by hand Yes, but... > (perhaps it would be best to just rebuild them from scratch), I don't think that's necessary. Just apply the attached patch[1] in /var/lib/dpkg/info. > and then reschedule builds of xfree86. That part's necessary too. :) > Regardless of exactly what the correct procedure is, is there someone > who is taking the lead of making sure all this happens? More than a > few packages have gotten stalled by the corrupted chroots on the > buildd's causing spurious build failures and it needs by-hand work to > correct each one. Steve Langasek has been working with me and some of the buildd admins on this via IRC, but it is good to give this cleanup procedure broader exposure. [1] also available at http://redwald.deadbeast.net/tmp/xfree86-common_postrm_buildd_fix.diff > -- G. Branden Robinson| The software said it required Debian GNU/Linux | Windows 3.1 or better, so I [EMAIL PROTECTED] | installed Linux. http://people.debian.org/~branden/ | --- xfree86-common.postrm~ 2004-02-17 18:20:44.0 -0500 +++ xfree86-common.postrm 2005-02-19 14:07:19.323055852 -0500 @@ -599,7 +599,7 @@ if [ "$1" = "purge" ]; then - update-rc.d "$THIS_PACKAGE" remove + update-rc.d "$THIS_PACKAGE" >/dev/null remove for DIR in /etc/X11/Xresources /etc/X11/Xsession.d /etc/X11; do rmdir "$DIR" 2> /dev/null || true done signature.asc Description: Digital signature
Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org
* Tore Anderson | * Tollef Fog Heen | | > No. If you have exim4 installed and install mailman, it's a | > reasonable expectation that you want to use those two together. | | But you cannot know if I have changed, added, or removed files under | conf.d/ in such a way which would make your drop-in routers and | transports break the entire configuration. The files are after all | configuration the user is allowed to change as he pleases. Yes, he might for instance remove the files added by mailman and add his own. | Policy 10.7.3 says: | | Configuration file handling must conform to the following behavior: | | * local changes must be preserved during a package upgrade, [..] | | Even though you're not strictly changing _a_ configuration file by | dropping files under conf.d, you're changing the configuration that | Exim ends up reading. Yes, and that's allowed. That's half the point of conf.d, AIUI. [...] | > It will be documented in NEWS.Debian ifwhen I get around to it. | | As far as I know NEWS.Debian is only displayed on upgrades, so that | isn't sufficient. That said, documenting that you're doing something | undesireable isn't really an excuse for doing it in the first place. It's not undesireable -- it's very much desired. It makes Mailman and Exim operate better together out of the box. Yes, it might break custom configurations where the admin doesn't check his stuff properly, but that's a fault of the admin, not the package. | Please consider putting the snippets somewhere else, like under | /etc/mailman/, and rather tell the user where to symlink them under | /etc/exim4/conf.d/. The user can just remove them if he doesn't want them. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote: > Our chances of actually releasing one day could only increase if we dropped > arches such as mipsel, s390, m68k, ... and concentrated on those that > actually > mattered: i386, powerpc, amd64 -- and I'll gladly add a few more. But a > total of > eleven is insane. Ah, are the 6 months over and it's time for your regularly "drop those archs!"-rant again? Linux is about freedom - freedom of whatever software you want to use and even what arch you want to use to run your chosen software. And even it's freedom of you to support an arch or not - but keep in mind that dropping support for some archs might trigger the freedom of release managers to not include your packages because of missing arch support. Isn't freedom a great thing? Yet you haven't come up with proofs to support your call to remove those archs. I think you're just annoyed to deal with more than (let's say) 3 archs. But hey, that's your personal problem then. I do see some structural problems (or say management problems) for some archs, but not problems with those archs itself. While m68k has solved those problems long time ago and still continuing to work on those problems, other archs don't want to take over the way of m68k to prevent problems. But again, that's a managing problem. Remove the responsible porters if they are not successful in doing their duties, but not the arch. > But then it doesn't matter anymore. These days, Debian is "infrastructure". > We no longer make releases. We provide the basis from which others make > releases > -- Ubuntu, Prodigy, Knoppix, Custom debian dists etc pp. That's true in some regards, but hasn't to do anything with the number of archs. > Still, the hours we maste on fixing, building, maintaining, ... code on unused > platforms is hysterical waste of resources. Resources we don't really have. It > would be better to concentrate on a core of packages, and platforms, and then > get on with it. One day it will break the infrastructure provision, at which > point someone will fork our high-priority core packages. Concentrating on a core set of packages for release was one of the aspects I already proposed last year, well, 2 years ago in the meantime. The problem is quite simple: Debian is too huge for the current structure. It worked fine so far, but that's easy. You can easily release 2000 packages for 3 archs with that grown structure, but you will get real problems with >1 packages and >10 archs. Change the structure how Debian works and you'll be able to deal again with those problems easily. -- Ciao... // Ingo \X/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
The installer is not a release blocker...but interest in the installer is decreasing
(from a thread in -devel) Quoting Henrique de Moraes Holschuh ([EMAIL PROTECTED]): > On Sun, 20 Feb 2005, Brian Nelson wrote: > > > There isn't any evidence I've seen that these arch's actually slow > > > down the release. > > > > Getting debian-installer working across all architectures was certainly > > an issue at one time, though that time passed a few months ago. > > Well, if the installer ever holds etch, we can think about it. Right now, > the installer is not even semi-close to being the worst problem. Sure. The only problem with the installer is that we froze in early October for RC2, didn't move that much since then (no new featuresthe few ones added are waiting in the trunk branch)and it seems that the interest in it is decreasing among developers with a "core team" slowly shrinking to a few individuals. Not a problem per se, but only a small worry at this moment. We shouldn't have a frozen installer for a too long timeor we take the risk of losing valuable contributors interest. More specifically, I'm thinking about the work on a graphical interface, a rescue package, partman enhancements, new languages support -several are waiting since September because we decided then to not add more languages We also have an increasing number of unprocessed install reports (of half-processed) : a usual good sign of lack of resources. Don't misunderstand me : I agree completely with the current installer "semi-freeze". Joey handles this the best way, for sure (I am and I have always been 100% supportive fo the way D-I development is handled) I just want to enhance the concerns I had during last weeks/months. The installer team needs to move on. For this, we need to first release RC3 (which is on its way), then be sure that that release is enough for a sarge release (here, the blocker is obviously the final choice about the kernel). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
[Henrique de Moraes Holschuh] > The answer to that is to setup a dist-cc cluster for these archs, > where only the master node is in the slow arch, and everything else > is a fast arch. i.e. far stricter buildd requirements would fix it. > Even mirror space problems can be fixed without dropping an arch. Stricter buildd requirements might do it. Perhaps an upper limit on the number of days allowed to pass from a package is upload until the autobuilder did its first build, and an upper limit on the number of days allowed to pass with a broken toolchain before the arch is removed would work. But at the moment, there are very few problems with the autobuilders, it seem. The packages with missing builds on some archs are listedon http://developer.skolelinux.no/info/cdbygging/distdiff-all.html.gz>, and it is not bad compared to earlier. Missing archiectures blocking packages: arm(86) mips(84) ia64(74) alpha(65) mipsel(64) m68k(61) sparc(60) powerpc(59) s390(51) hppa(46) i386(5) Of course, the relative order and package count in this list varies a lot over time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Mon, 21 Feb 2005, Ingo Juergensmann wrote: On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote: ... But then it doesn't matter anymore. These days, Debian is "infrastructure". We no longer make releases. We provide the basis from which others make releases -- Ubuntu, Prodigy, Knoppix, Custom debian dists etc pp. That's true in some regards, but hasn't to do anything with the number of archs. Especially it is wrong regarding the fact about Custom Debian Distributions (if you mean this special term) because they reside inside Debian and in consequence do also cope with all architectures. There are reasons that people use such CDDs for only a single architecture and do some further adaptations to a CDD but this is a different issue. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
On Mon, Feb 21, 2005 at 12:33:24AM +0100, Goswin von Brederlow wrote: > Matthew Palmer <[EMAIL PROTECTED]> writes: > > > On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote: > >> Clint Byrum spamaps.org> writes: > >> > Now, can someone please tell me how messages like the one below, and > >> > others, aren't indicative that debian should drop s390, mipsel, and > >> > maybe hppa from the list of architectures? How about we release for > >> > i386, sparc, and powerpc, and let the others release on their own > >> > schedule? This business of supporting 11 architectures and making sure > >> > they're all 100% right before releasing is just about the worst idea > >> > ever. > >> > >> Still, the hours we maste on fixing, building, maintaining, ... code on > >> unused platforms is hysterical waste of resources. Resources we don't > >> really have. > > > > I'd like to see your numbers on how many manhours have been wasted in the > > past, say, 6 months on fixing code on unused platforms which would have gone > > into other things had those architectures not been in Debian. > > > > - Matt > > Not to mention that i386 is the most non working architecture of them > all when it comes to the buildd and m68k probably the one with the > fastest responce time. > > And how does having gtk not being blocked for a few days by a buildd > get ftp-master to implement t-p-u and testing-security any faster, > which is what we've all been waiting for the last 6+ month. > > Not to mention the number of arm, mips, mipsel, m68k, hppa, alpha, > ia64, s390 developers that would drop away starting their own > distribution depriving Debian of manpower. A lot of bugs are found by > those extra architectures Debian supports and also fixed by their > porters. Nothing better to find bugs than a large variety. Isn't that what ESR said about the bazaar: the more eyes, the faster bugs get squished! In this case, the more arch differences, the more bugs that will be found, too! -Kev -- counter.li.org #238656 -- goto counter.li.org and be counted! (__) (oo) /--\/ / ||| * /\---/\ ~~ ~~ "Have you mooed today?"... signature.asc Description: Digital signature
