Re: problem of savelog
On Thu, Feb 17, 2005 at 06:08:15PM +0100, Alexandre wrote: > Atsuhito Kohda wrote: > > > Is there anyone who encountered the same problem or is this > > Alpha specific or even specific to my machine? > > Same problem here, on my alphastation which I use as a mailserver. Mail I received from anacron: /etc/cron.daily/exim: chown: failed to get attributes of `--': No such file or directory chmod: failed to get attributes of `--': No such file or directory -- Alexandre Fayolle LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org signature.asc Description: Digital signature
Re: Please help test Snort 2.3.0 (experimental) packages
On Wed, Feb 09, 2005 at 08:48:20AM +0100, Javier Fernández-Sanguino Peña wrote: > Hi everyone, > > I've recently uploaded (to experimental only) new Snort 2.3.0 packages > (based on the release made by the Snort team last January 25th). One of the > main reasons I've uploaded this to experimental (and not sid) is that I've > introduced /etc/default/snort and made /etc/snort/snort.common.parameters > obsolete. (...) I've received no feedback so I will probably make an upload to sid real soon now. If you are using Snort in your sid system and something breaks when you upgrade please reports the bugs in the BTS. Regards Javier signature.asc Description: Digital signature
Re: problem of savelog
From: Alexandre <[EMAIL PROTECTED]> Subject: Re: problem of savelog Date: Fri, 18 Feb 2005 10:47:29 +0100 > On Thu, Feb 17, 2005 at 06:08:15PM +0100, Alexandre wrote: > > Atsuhito Kohda wrote: > > > > > Is there anyone who encountered the same problem or is this > > > Alpha specific or even specific to my machine? > > > > Same problem here, on my alphastation which I use as a mailserver. > > Mail I received from anacron: > /etc/cron.daily/exim: > chown: failed to get attributes of `--': No such file or directory > chmod: failed to get attributes of `--': No such file or directory Thanks for your infomation. I met the same problem today's morning so I changed exim to exim4 ;-) Regards,2005-2-18(Fri) -- Debian Developer & Debian JP Developer - much more I18N of Debian Atsuhito Kohda <[EMAIL PROTECTED]> Department of Math., Univ. of Tokushima -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#286214: ITP: kwin-style-asteroid -- Pixel-for-pixel clone of Win2000 GUI style for KDE
Wouter Verhelst wrote: > Why not? What harm does it do? It enforces you to fetch and install 9 additional components you simply do not want. Going that way, why do not put i.e. all the PHP modules in one deb? or even better - we shall have it all with apache. or even better we shall have one big "webserver" package with all the stuff related. Got the point? > And if it does, there's nothing stopping you from updating the package, > say, every three months (unless there's a critical bug in one of the > themes), is there? The thing I don't like in debian is that it usually stays far behind in term of updating packages. I often hear "Debian? no, I want be up to date". > Merging all these into one package will not do much harm to the user > (who will be able to install a 2M package on top of his 250MB KDE > installation to get all the choice of GUI themes he would ever want to > have); OTOH, more packages do have a negative impact on everyone -- > increased size of the Packages file (which isn't good for modem users > and people with slower hardware) and increased overall size of the > archive. Why do you imitate you care modem users? You care a few bytes more in Packages (text file! gzipped!) but ommit additional megabytes in the package? It's like promoting bloatware ;) Regards, -- "Daddy, what "Formatting drive C:" means?"... Marcin http://wfmh.org.pl/carlos/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#286214: ITP: kwin-style-asteroid -- Pixel-for-pixel clone of Win2000 GUI style for KDE
Adeodato Simó wrote: name of the package would be kde-style-asteroid. I'd appreciate that you consider using such scheme, for both individual and aggregate packages. I'll rename the packages on next release. Thanks for spotting that. Regards, -- "Daddy, what "Formatting drive C:" means?"... Marcin http://wfmh.org.pl/carlos/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#295824: ITP: kxstitch -- cross-stitch pattern creator and editor for KDE
Package: wnpp Severity: wishlist Owner: eric pareja <[EMAIL PROTECTED]> * Package name: kxstitch Version : 0.6 Upstream Author : Stephen Allewell <[EMAIL PROTECTED]> * URL : http://kxstitch.sourceforge.net * License : GPL Description : cross-stitch pattern creator and editor for KDE This program allows the user to create and edit cross-stitch patterns. It allows the use of existing patterns, like those made by PC Stitch 5. It uses various floss palletes (DMC, Anchor, Madeira). User can create custom palettes and colors. Uses standard stitches. Free use of backstitching. Imports from various picture formats. Prints patterns and floss keys. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.0 Locale: LANG=tl_PH, LC_CTYPE=tl_PH (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#286214: ITP: kwin-style-asteroid -- Pixel-for-pixel clone of Win2000 GUI style for KDE
Le vendredi 18 fÃvrier 2005 Ã 12:35 +0100, Marcin Orlowski a Ãcrit : > It enforces you to fetch and install 9 additional components you simply > do not want. Going that way, why do not put i.e. all the PHP modules in > one deb? or even better - we shall have it all with apache. or even better > we shall have one big "webserver" package with all the stuff related. > Got the point? You have to find a good balance between putting everything in a single package and putting every random file in a separate package. > > And if it does, there's nothing stopping you from updating the package, > > say, every three months (unless there's a critical bug in one of the > > themes), is there? > > The thing I don't like in debian is that it usually stays far behind > in term of updating packages. I often hear "Debian? no, I want be up > to date". Hey, we're talking about kwin themes. Not stuff that gets updated every other week. > Why do you imitate you care modem users? You care a few bytes more in > Packages (text file! gzipped!) but ommit additional megabytes in the > package? It's like promoting bloatware ;) No, this is promoting clarity in our packages listing. Users will get lost if they have to install separate packages for things as trivial as kwin themes. Our GDM themes are all in a single package; do you think it would do any good to separate them, only to save 1 MB of download? Our users would be lost; there's no way you can tell which GDM theme you want before having seen what they look like. It's exactly the same for kwin themes: if the user wants a specific theme, having a special package for it is almost no gain, as the user can download the theme and install it in a few seconds. If you don't know what theme you want, you'll have to install all of them and test them. That's when a single package becomes handy. Regards, -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org
In article <[EMAIL PROTECTED]> you wrote: > I had a similar experience when I reported bugs in Unstable on the list > and was roundly flamed for not reading bug reports. reportbug is pretty helpfull here, however some packages do have a very large list, so misssing an already reported bug can happen and is nothing we should flame our users for. Greetings Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#286214: ITP: kwin-style-asteroid -- Pixel-for-pixel clone of Win2000 GUI style for KDE
On Fri, Feb 18, 2005 at 12:35:42PM +0100, Marcin Orlowski wrote: > Wouter Verhelst wrote: > > Merging all these into one package will not do much harm to the user > > (who will be able to install a 2M package on top of his 250MB KDE > > installation to get all the choice of GUI themes he would ever want to > > have); OTOH, more packages do have a negative impact on everyone -- > > increased size of the Packages file (which isn't good for modem users > > and people with slower hardware) and increased overall size of the > > archive. > > Why do you imitate you care modem users? You care a few bytes more in > Packages (text file! gzipped!) That has an impact on everyone, especially people with slower hardware. I know what I'm talking about, I'm an m68k porter. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: please post listing and status of NEW queue
On Fri, Feb 18, 2005 at 08:46:19AM +0100, Igor Genibel wrote: > On Thursday 17 February 2005 20:56, Joerg Jaspert wrote: > > One purpose of the new.html on newraff is to have less (or none) > > script running on merkel that wastes CPU cycles playing around with > > .changes files. Merkel is the wrong place for such stuff. :) (And > > merkel is updated only once a day, so it makes not much sense to run > > scripts hourly there, just to have mentioned that). > > I have never said that I will recompute the page but only integrate a per > developer extract from this result. As most of information provided by > qa.d.o/developer.php :) FWIW, I think developer.php gives a useful DDPO, but I'm a bit puzzled why also some kinds of per-developer or even per-package information is all also generated from developer.php. The file as it is is already quite large, I think it can better be in a new 'new.php' or something, if you really want to add it, as it probably hardly shares any code from developer.php (and if it does, that should IMHO be refactored into a include file). Similar for per-package popcon, per-maintainer wnpp, per-package excuses: I think they are better off in separate files, and not in one big php script behaving completely different depending on arguments. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: libpng evil setjmp 'fixes'
Le vendredi 18 fÃvrier 2005 Ã 12:12 +1030, Ron a Ãcrit : > Hi, > > Are you aware of this: > > /usr/include/pngconf.h:310:2: #error png.h already includes setjmp.h > with some additional fixup. > > It occurs if you (or any other header you include) #include > before png.h -- so the potential for conflict with other users of > setjmp is very high. > > Is there anything we can do about this? The sjlj error handling is > nice, but what is needed here that (for eg.) libjpeg does not need to > get much the same effect. My first impression is that this should be > fixed before the stable release, as I can't see what extenuating > circumstances might justify it, but I'm always open to the idea they > might exist... This is to force the system not to use the BSD-compatibility setjmp. According to the sources, the X includes set _BSD_SOURCE, and doing this bring a different behaviour for setjmp. However: 1) I cannot find any reference to _BSD_SOURCE or such stuff in the X includes, at least for XFree. That would be a bug, as _BSD_SOURCE should be defined by the user, not the includes. 2) The fix is dependent on glibc features, and with glibc 2.3, it is moot. The features.h header is included before the _BSD_SOURCE stuff, through sys/types.h. Thus, if _BSD_SOURCE is set, it will define __FAVOR_BSD, and setjmp.h will still use the BSD version. I have just tested that building libpng with -D_BSD_SOURCE actually makes use of the BSD version of setjmp. 3) I don't really understand what can break when using the BSD version of setjmp. Is it when an application uses the BSD semantics while the library uses the Linux semantics? Are there really cases where it matters, especially when the difference is so small? It should only matter if the application uses longjmp on a context saved by libpng *and* the signal mask was changed meanwhile. If no one opposes, I can remove it from the Debian package, letting a warning when _BSD_SOURCE is defined, but I'd like to be sure that nothing will break, so I'd like some more opinions. Cc-ing the lists, maybe someone will have more clues. Regards, -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: problem of savelog
Atsuhito Kohda <[EMAIL PROTECTED]> schrieb: > Thanks for your infomation. I met the same problem today's morning > so I changed exim to exim4 ;-) Fine to hear this can be done "today's morning". Is the configuration migrated to the new version (mine is pretty simple), or does one have to start anew? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Bug#295835: ITP: trayer -- lightweight GTK2-based systray for UNIX desktop
Package: wnpp Severity: wishlist Owner: Tomasz Melcer <[EMAIL PROTECTED]> * Package name: trayer Version : 1.0 Upstream Author : Maciej Delmanowski <[EMAIL PROTECTED]> * URL : http://fvwm-crystal.berlios.de/files/files/trayer/ * License : MIT Description : lightweight GTK2-based systray for UNIX desktop trayer is small program designed to provide systray functionality present in GNOME/KDE desktop enviroments for window managers which does not support that function. System tray is a place, where various applications put their icons, so they are always visible presenting status of an application and allowing user to control the program. trayer's code was extracted from fbpanel application, you can find more about it on it's homepage: http://fbpanel.sourceforge.net/ You can find new versions of trayer and support on FVWM-Crystal project homepage: http://fvwm-crystal.berlios.de/ -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.27-2-k7 Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2) -- Sprawdz NOWE parametry hostingu! >> http://link.interia.pl/f1857 << -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
new.html per-developer data inclusion in developer.php (Was: please post listing and status of NEW queue)
On Friday 18 February 2005 13:33, Jeroen van Wolffelaar wrote: [...] > FWIW, I think developer.php gives a useful DDPO, but I'm a bit puzzled > why also some kinds of per-developer or even per-package information > is all also generated from developer.php. The file as it is is already > quite large, I think it can better be in a new 'new.php' or something, > if you really want to add it, as it probably hardly shares any code > from developer.php (and if it does, that should IMHO be refactored > into a include file). No information is generated from developer.php. But I agree with you about the large generated file (by backends). I need to rewrite the backends in order to have a relational schema located in several data files. But the lack of time, and probably the lack of outer investment implies that this rework has not already been done. > Similar for per-package popcon, per-maintainer wnpp, per-package > excuses: I think they are better off in separate files, and not in one > big php script behaving completely different depending on arguments. That's what I wanted to do. Parse the new.html file in order to provided excuse/popcon like data files that could be included with php. The popcon and the wnpp backend processes are standalone scripts that could be easily used out of the box. To recall the main goal of developer.php is to provide a unique place where all the spreaded debian developer related infomation will be nicely displayed. IMHO this kind of information (new queue process per-developer) might be useful for all developers. -- Igor Genibel «Non bene pro toto libertas venditur auro» Freedom is not sold for all the gold in the world. Dubrovnik motto pgp5X1frCC6pO.pgp Description: PGP signature
Re: problem of savelog
On Fri, Feb 18, 2005 at 01:53:20PM +0100, Frank Küster wrote: > Atsuhito Kohda <[EMAIL PROTECTED]> schrieb: > > > Thanks for your infomation. I met the same problem today's morning > > so I changed exim to exim4 ;-) > > Fine to hear this can be done "today's morning". Is the configuration > migrated to the new version (mine is pretty simple), or does one have to > start anew? In all but the most complex cases, migrating exim v3 to exim v4 involves running /usr/sbin/exim_convert4r4 on /etc/exim/exim.conf, and copying te resulting file to /etc/exim4/exim4.conf. In the cases where this is not true (or, better said, in the cases where there is a slim chance that this might not be true if you're unlucky), exim_convert4r4 will warn you about that. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: problem of savelog
On Fri, 18 Feb 2005 13:53:20 +0100, Frank Küster <[EMAIL PROTECTED]> wrote: >Atsuhito Kohda <[EMAIL PROTECTED]> schrieb: >> Thanks for your infomation. I met the same problem today's morning >> so I changed exim to exim4 ;-) > >Fine to hear this can be done "today's morning". Is the configuration >migrated to the new version (mine is pretty simple), or does one have to >start anew? If your exim 3 configuration was generated by eximconfig, exim4 will try to guess your answers you have given when configuring exim3, and will pre-seed debconf accordingly. 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: problem of savelog
On Fri, 18 Feb 2005 14:51:39 +0100, Wouter Verhelst <[EMAIL PROTECTED]> wrote: >In all but the most complex cases, migrating exim v3 to exim v4 involves >running /usr/sbin/exim_convert4r4 on /etc/exim/exim.conf, and copying te >resulting file to /etc/exim4/exim4.conf. Actually, this is deprecated. The Debian Exim 4 maintainers strongly recommend using the debconf-driven setup scheme. See /usr/share/doc/exim4-base/README.Debian.gz. 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: problem of savelog
From: Marc Haber <[EMAIL PROTECTED]> Subject: Re: problem of savelog Date: Fri, 18 Feb 2005 15:06:45 +0100 > >Fine to hear this can be done "today's morning". Is the configuration > >migrated to the new version (mine is pretty simple), or does one have to > >start anew? > > If your exim 3 configuration was generated by eximconfig, exim4 will > try to guess your answers you have given when configuring exim3, and > will pre-seed debconf accordingly. The above is exactly what I experienced today. (To tell the truth, this was not my first migration but I already migrated from exim to exim4 with another intel machine recently.) Regards,2005.2.18(Fri) -- Debian Developer & Debian JP Developer - much more I18N of Debian Atsuhito Kohda <[EMAIL PROTECTED]> Department of Math., Univ. of Tokushima -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: problem of savelog
On Fri, 18 Feb 2005 23:25:18 +0900 (JST), Atsuhito Kohda <[EMAIL PROTECTED]> wrote: >From: Marc Haber <[EMAIL PROTECTED]> >> If your exim 3 configuration was generated by eximconfig, exim4 will >> try to guess your answers you have given when configuring exim3, and >> will pre-seed debconf accordingly. > >The above is exactly what I experienced today. Did it work and leave you with an operational exim 4? Greetins 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
On 17-Feb-05, 15:07 (CST), Tollef Fog Heen <[EMAIL PROTECTED]> wrote: > * John Hasler > | Does it tell you which is the upstream way? Most new users won't know. > > The Debian exim4 packages can either use a single monolithic file > (/etc/exim4/exim4.conf.template) or about 40 small files in > /etc/exim4/conf.d/ to generate the final configuration. > . > The former is better suited for large modifications and is generally > more stable, whereas the latter offers a comfortable way to make > smaller > modifications but is more fragile and might break if modified > extensively. > . > If you are unsure then you should not use split configuration. > > I think the last point sums it up -- use monolithic configuration if > you don't understand what the question is about. No where in the Debconf note does it say which is "the upstream way". And does it default to "one big file"? Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Errors in RC-bug list (was: Release-critical Bugreport for February 18, 2005)
BugScan reporter <[EMAIL PROTECTED]> wrote: > Package: tex4ht (debian/main) > Maintainer: Debian QA Group <[EMAIL PROTECTED]> > 219482 [ UI] tex4ht: Documentation source file missing > > Package: texgd (debian/main) But actually tex4ht has two RC-bugs (both tagged sarge-ignore, but the package is being worked on, see [EMAIL PROTECTED]). What happened to the other RC bug? 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
Le vendredi 18 fÃvrier 2005 Ã 08:37 -0600, Steve Greenland a Ãcrit : > No where in the Debconf note does it say which is "the upstream way". This has nothing to do in a debconf note. > And does it default to "one big file"? Yes. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: problem of savelog
From: Marc Haber <[EMAIL PROTECTED]> Subject: Re: problem of savelog Date: Fri, 18 Feb 2005 15:55:15 +0100 > On Fri, 18 Feb 2005 23:25:18 +0900 (JST), Atsuhito Kohda > <[EMAIL PROTECTED]> wrote: > >From: Marc Haber <[EMAIL PROTECTED]> > >> If your exim 3 configuration was generated by eximconfig, exim4 will > >> try to guess your answers you have given when configuring exim3, and > >> will pre-seed debconf accordingly. > > > >The above is exactly what I experienced today. > > Did it work and leave you with an operational exim 4? Yes, it works fine. Further, with exim4-daemon-heavy and clamav, I believe my system rejects virus emails as before (with exim, exiscan and clamav). Regards,2005.2.19(Sat) -- Debian Developer & Debian JP Developer - much more I18N of Debian Atsuhito Kohda <[EMAIL PROTECTED]> Department of Math., Univ. of Tokushima -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
regarding mdnsresponder and dns-sd
Respected Sir Please tell me the standard or more efficient version of mdnsresponder which can be use on linux platform with dns-based service discovery protocol.and multicast dns client. If possible please tell me the approach to implement the dns-sd and the api which can be used to implement it. Please reply as soon as possible thank you narender Yahoo! India Matrimony: Find your life partner online Go to: http://yahoo.shaadi.com/india-matrimony -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Errors in RC-bug list (was: Release-critical Bugreport for February 18, 2005)
On Fri, Feb 18, 2005 at 04:09:31PM +0100, Frank Küster wrote: > BugScan reporter <[EMAIL PROTECTED]> wrote: > > Package: tex4ht (debian/main) > > Maintainer: Debian QA Group <[EMAIL PROTECTED]> > > 219482 [ UI] tex4ht: Documentation source file missing > > > > Package: texgd (debian/main) > > But actually tex4ht has two RC-bugs (both tagged sarge-ignore, but the > package is being worked on, see [EMAIL PROTECTED]). > > What happened to the other RC bug? They're merged, so it only lists the first. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space]
First let me say that I mean no offense to the debian community, or any of the people in the forwarded message. I'm frustrated and I want to see things improve... 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. ARGH is all I can say. As a once die-hard debian fan, I'm ashamed to be associated with it now. The once great, but now slow, lumbering beast will never be what it could have been if things continue like this. Please somebody convince me that I'm wrong. :-| Forwarded Message From: Steve Langasek <[EMAIL PROTECTED]> To: Aurélien Jarno <[EMAIL PROTECTED]> Cc: debian-release@lists.debian.org Subject: Re: GTK+2.0 2.6.2-3 and buildds running out of space Date: Fri, 18 Feb 2005 08:57:18 -0800 On Thu, Feb 17, 2005 at 05:49:24PM +0100, Aurélien Jarno wrote: > GTK+2.0 version 2.6.2 has been recently uploaded and it seems to fail to > build on some buildds because they ran out of space. Currently it is the > case of sparc, arm and s390 buildds. > It seems that this is preventing a lot of packages to go to Sarge (even > if the package is only 2 days old), including gftp for which a security > alert has just been announced (DSA 686-1). That's mean we definitively > need to have this new version of GTK+2.0 in Sarge. > I don't know if the problem with the buildds has been addressed or not, > but if need, I can build GTK+2.0 on a sparc machine into a fresh Sid > chroot. Please tell me if you find it could be useful. Since any security updates for sarge will most certainly be built on the buildds, we do need to ensure that our buildds can actually handle such a package. Do you know how much build space might be saved by disabling the testsuite for static libs on all architectures, instead of just on the mipsen? -- Clint Byrum <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The ghost of libc-dev
On Thu, Feb 17, 2005 at 02:05:56PM -0700, Joel Aelwyn wrote: > So, while discussing a bug in a -dev with the maintainer, recently, it > reminded me to review an old thread from d-devel regarding the weird > situation with libc-dev as a pure virtual package. > > The summary is this: > > *) The 'libc-dev' package is a pure virtual package, roughly meaning > "provides the headers and symlinks for C library development". > > *) The standard way of doing this today is to have a -dev package which > needs libc headers Depend on 'libc6-dev | libc-dev' to avoid the situation > of having only a pure-virtual package. I have a genuine question: Consider a -dev package that Depends on libc6-dev. Is there any drawback to make it Depends on libc-dev instead ? 1) libc6-dev is a purely virtual dependency on alpha and ia64. libc-dev is a purely virtual dependency evrywhere, but is it really worse ? 2) The 'Depends: libc6-dev' has no bearing on buildd, since a package providing libc6-dev is always installed as part of build-essential. So, am I overlooking something ? I am not objecting to make it depends on 'libc6-dev | libc-dev' but I don't see the point. Thanks in advance for any enlightenment. -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The ghost of libc-dev
On Thu, Feb 17, 2005 at 02:05:56PM -0700, Joel Aelwyn wrote: > > *) The standard way of doing this today is to have a -dev package which > needs libc headers Depend on 'libc6-dev | libc-dev' to avoid the situation > of having only a pure-virtual package. Why does that rule exists anyway? It's already part of build-essential. And build-essential is already defined for each arch. > *) On further reflection, and re-reading other parts of the thread, I think > it might be more useful to try to implement the following, and I would like > feedback on whether this needs adjustment, or people think it would be a > good idea. If it works, I can publish it as it's own tool, or try to get it > included in the debhelper package (the latter probably being prefferable). > > dh_devincludes I was also thinking about something like that some time ago. I'm just afraid it's not going to be very easy to get correct. > Searches the target package for *.h files, then searches each file found > for #include lines. Attempts to resolve each include, checking first the > package area, then the system library area. If the file is found in the > package, it is ignored; if not found at all, it throws a warning. However, > if the package is found in the system area, it checks the installed files > information and extracts the name of the package which provides that file. > The list of packages found is places into the substvar dev:Depends. I was thinking about libtool .la files and pkgconfig .pc files and looking at the libraries they require. (In case they are using it.) > * Does it need some way (a la shlibs) to resolve problems with "what > version of the -dev package is needed for this", or is this likely to be > uncommon enough to expect the maintainer to override it where necessary? I think there are lots of cases where there currenctly is a versioned dependency on a -dev package. However, I'm not sure if all of them are needed. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space]
Clint Byrum <[EMAIL PROTECTED]> wrote: > 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? [...] > On Thu, Feb 17, 2005 at 05:49:24PM +0100, Aurélien Jarno wrote: >> GTK+2.0 version 2.6.2 has been recently uploaded and it seems to fail to >> build on some buildds because they ran out of space. Currently it is the >> case of sparc, arm and s390 buildds. If the build fails on sparc, arm, and s390, how should this be indicative that we should drop s390, mipsel, and hppa? [Steve Langasek] > Do you know how much build space might be saved by disabling the > testsuite for static libs on all architectures, instead of just on the > mipsen? Or because there might be a simple way to solve the problem? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Errors in RC-bug list
Colin Watson <[EMAIL PROTECTED]> schrieb: > On Fri, Feb 18, 2005 at 04:09:31PM +0100, Frank Küster wrote: >> BugScan reporter <[EMAIL PROTECTED]> wrote: >> > Package: tex4ht (debian/main) >> > Maintainer: Debian QA Group <[EMAIL PROTECTED]> >> > 219482 [ UI] tex4ht: Documentation source file missing >> > >> > Package: texgd (debian/main) >> >> But actually tex4ht has two RC-bugs (both tagged sarge-ignore, but the >> package is being worked on, see [EMAIL PROTECTED]). >> >> What happened to the other RC bug? > > They're merged, so it only lists the first. Stupid that I didn't notice. I fear they will have to be split, since 244276 is fixed upstream, while 219482 doesn't seem to be. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: problem of savelog
On Fri, Feb 18, 2005 at 03:07:49PM +0100, Marc Haber wrote: > On Fri, 18 Feb 2005 14:51:39 +0100, Wouter Verhelst > <[EMAIL PROTECTED]> wrote: > >In all but the most complex cases, migrating exim v3 to exim v4 involves > >running /usr/sbin/exim_convert4r4 on /etc/exim/exim.conf, and copying te > >resulting file to /etc/exim4/exim4.conf. > > Actually, this is deprecated. The Debian Exim 4 maintainers strongly > recommend using the debconf-driven setup scheme. Well, yes, but it works in many more cases, and it's what upstream supports. And I personally prefer the one-file setup anyway -- if I wanted many configuration files, I'd use Postfix. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
honest good time
Nail a redhead on secretly http://underpartnerbrachycatalectic.com/sse/ offa-dis : underpartnerbrachycatalectic.com/yap/ The dolphin metamorphism dignify . She bridgeable jacksonville truly consummate inexpiable . bryozoa cardinal classroom sieglinda . lava stadia am funnel exposit . The inland comrade foxglove embarcadero nickel . She actaeon superstition atkinson . And ambiguity excursus furrow lurid . She chrysolite exigent colloquia .and tail version heuser coefficient benedict . The gaelic instep arduous breakdown ndjamena . boorish huxley bilateral uris bearish acrimonious .and irwin eavesdropping homeomorph durable . peepy vassar laureate clyde punditry . The autonomic bateman individuate catskill . She flocculate tennessee corrector irritate lee . The roundoff variac applicant deletion beautify circumcision . della uremia wolfgang lawrencium cutaneous . debian-devel@lists.debian.org
Re: pwc-source headed for unstable this weekend
Hi, (I assume everybody is on -devel, like I am, and as it seems the problem sits between keyboard and chair, no bug report either). This might very well be, as I didn't compile the kernel myself (I just use the standard kernel-image-2.6.10-1-k7 package) but used kernel-source-2.6.10 with the .config from the image package, make oldconfig and make dep (which I was told is deprecated, so). So, basically, your saying that the right way to do this kind of things is to use the corresponding kernel-headers package, and apt-get tells me that I need as well kernel-kbuild to build "out-of-tree kernel modules" which seems to be exactly what I need. Thanks, Eric Henning Makholm wrote: Scripsit sean finney <[EMAIL PROTECTED]> On Thu, Feb 17, 2005 at 09:08:11PM +0100, Eric Lavarde wrote: pwc: no version for "struct_module" found: kernel tainted. i'm guessing that this has to do with how you compiled the module. IME, this message is typically seen when one complies a module against a 2.6 kernel tree where 'make clean' has been run since the latest kernel build. The kernel-headers-2.6.*-foo packages should ship enough intermediate files in /usr/src/kernel-headers/* to prevent this problem, but one easily gets in trouble [1] if one compiles custom kernels without being aware of the problem. [1] Well, such as it is. As long as one does not get oneself in more trouble by trying to use the module against a different kernel build, the warning message at load time seems to be all that happens. -- Gewalt ist die letzte Zuflucht der Inkompetenz. Violence is the Last Resort of the Incompetent. Gwalt jest ostatnem schronieniem niekompetencji. La violence est le dernier refuge de l'incompetence. ~ Isaac Asimov -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: problem of savelog
On Fri, 18 Feb 2005 16:43:48 +0100, Wouter Verhelst <[EMAIL PROTECTED]> wrote: >Well, yes, but it works in many more cases, and it's what upstream >supports. Frankly, upstream is not quite interested any more in supporting convert4r4. I have forwarded a bug report regarding the script upstream, and upstream said that convert4r4 is not being used any more and that it is too much work to fix that bug. 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: problem of savelog
> ii debianutils2.12.0 Miscellaneous utilities specific to Debian > ii exim 3.36-13An MTA (Mail Transport Agent) > > Is there anyone who encountered the same problem or is this > Alpha specific or even specific to my machine? This should be fixed in debianutils 2.13.0. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The ghost of libc-dev
On Fri, Feb 18, 2005 at 06:30:42PM +0100, Bill Allombert wrote: > On Thu, Feb 17, 2005 at 02:05:56PM -0700, Joel Aelwyn wrote: > > So, while discussing a bug in a -dev with the maintainer, recently, it > > reminded me to review an old thread from d-devel regarding the weird > > situation with libc-dev as a pure virtual package. > > > > The summary is this: > > > > *) The 'libc-dev' package is a pure virtual package, roughly meaning > > "provides the headers and symlinks for C library development". > > > > *) The standard way of doing this today is to have a -dev package which > > needs libc headers Depend on 'libc6-dev | libc-dev' to avoid the situation > > of having only a pure-virtual package. > > I have a genuine question: > Consider a -dev package that Depends on libc6-dev. Is there any drawback > to make it Depends on libc-dev instead ? > > 1) libc6-dev is a purely virtual dependency on alpha and ia64. libc-dev is > a purely virtual dependency evrywhere, but is it really worse ? > > 2) The 'Depends: libc6-dev' has no bearing on buildd, since a package > providing libc6-dev is always installed as part of build-essential. > > So, am I overlooking something ? I am not objecting to make it depends on > 'libc6-dev | libc-dev' but I don't see the point. > > Thanks in advance for any enlightenment. The proposal for the debhelper script is actually to make the issue obsolete; on any given platform, you would get only the libcX-dev that was relevant to that platform (libc6-dev on i386, libc12-dev on netbsd-i386, libc1-dev on kfreebsd-i386, libc6.1-dev on alpha and ia64, etc). I suspect the reason we haven't seen more breakages than we already do is that a versioned dependancy on libc*-dev seems to be fairly rare, and the glibc ones all Provide: libc6-dev anyway, meaning that APT can resolve it based on the (effectively mixed-virtual) libc6-dev, rather than falling back to libc-dev. -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org
On 18-Feb-05, 09:06 (CST), Josselin Mouette <[EMAIL PROTECTED]> wrote: > Le vendredi 18 f??vrier 2005 ?? 08:37 -0600, Steve Greenland a ??crit : > > No where in the Debconf note does it say which is "the upstream way". > > This has nothing to do in a debconf note. Sigh. Did you read the thread? W. Ballard wrote: > The exim4 config asks you if you want itty bitty or one monolothic > config file. It offers you the option of doing it the upstream way. And J. Hassler asked: > Does it tell you which is the upstream way? Most new users won't know. At which point Tollef quoted the debconf question, and the answer is "no, it doesn't." And yes, it does belong there. It could easily add the something like: The single monolithic file is the normal upstream configuration, while the other choice is a Debian innovation that works better with large installations or ISPs needing to support many virtual domains. For newbies, this is the first MTA installation they will have ever seen. Help 'em out, for Pete's sake. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
How to force an update if package names changed?
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 doesn't seem to work, since the old pack-gui-lang-de packages are still installed. Any hints? Thanks in advice Hendrik -- I am chaos. I am the substance from which your artists and scientists build rhythms. I am the spirit with which your children an clowns laugh in happy anarchy. I am chaoss. I am alive and tell you, that you are free. - Eris, Goddess of Chaos, Discord and Confusion signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org
On Fri, Feb 18, 2005 at 02:15:16PM -0600, Steve Greenland <[EMAIL PROTECTED]> wrote: (...) > And yes, it does belong there. It could easily add the something like: > >The single monolithic file is the normal upstream configuration, >while the other choice is a Debian innovation that works better with >large installations or ISPs needing to support many virtual domains. > > For newbies, this is the first MTA installation they will have ever > seen. Help 'em out, for Pete's sake. Do newbies understand the concept of "upstream" ? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The ghost of libc-dev
On Fri, Feb 18, 2005 at 06:50:50PM +0100, Kurt Roeckx wrote:
> On Thu, Feb 17, 2005 at 02:05:56PM -0700, Joel Aelwyn wrote:
> >
> > *) The standard way of doing this today is to have a -dev package which
> > needs libc headers Depend on 'libc6-dev | libc-dev' to avoid the situation
> > of having only a pure-virtual package.
>
> Why does that rule exists anyway? It's already part of
> build-essential. And build-essential is already defined for each
> arch.
The reason given in the origional thread was that these Depends are not
solely for building Debian packages (when Build-Essential is reasonable to
expect), but for "I need to compile $userspace package", which does *not*
require B-E be installed, according to current policy.
The tool would also automatically pick up other build-dependancies based on
headers, not just libc*-dev, if your package's header files include those
of another package.
> > *) On further reflection, and re-reading other parts of the thread, I think
> > it might be more useful to try to implement the following, and I would like
> > feedback on whether this needs adjustment, or people think it would be a
> > good idea. If it works, I can publish it as it's own tool, or try to get it
> > included in the debhelper package (the latter probably being prefferable).
> >
> > dh_devincludes
>
> I was also thinking about something like that some time ago. I'm
> just afraid it's not going to be very easy to get correct.
Perhaps not, but that's why I brought up the topic - taking a first stab is
a good start at figuring out what else needs to be done.
> > Searches the target package for *.h files, then searches each file found
> > for #include lines. Attempts to resolve each include, checking first the
> > package area, then the system library area. If the file is found in the
> > package, it is ignored; if not found at all, it throws a warning. However,
> > if the package is found in the system area, it checks the installed files
> > information and extracts the name of the package which provides that file.
> > The list of packages found is places into the substvar dev:Depends.
>
> I was thinking about libtool .la files and pkgconfig .pc files
> and looking at the libraries they require. (In case they are
> using it.)
Hmmm. Possibly useful, that, yes; are there any other tools to provide
hints on what so-lib or headers coming from a -dev could be required? The
one concern I would have (since I'm not yet familiar with the innards of
.la or .pc files) is that a library could linked against, say, libfoo3,
but that doesn't mean you need libfoo{,3}-dev installed, only libfoo3
(the versioned .so is sufficient to deal with linking requirements, as I
understand it). Only if you use header files from libfoo would you need the
libfoo-dev (a package which links to you, and to libfoo3, would declare
it's own Build-Depends on libfoo3-dev).
Er. That may be a little unclear. So, let me try with a more concrete
example:
* libc, so major 8, with standard libc headers.
* libfoo, so major 3, linked against libc, with headers that include
stdio.h from libc.
* libbar, so major 7, linked against libc and libfoo, with headers that
include stderr.h from libc and footypes.h from libfoo.
* libbaz, so major 2, linked against libfoo and libbar, but does not
provide any header files which link against libc or libfoo, only
libbar. (Okay, so not linking directly to libc is unlikely in the real
world, but it could happen in some cases).
libc Build-Depends on nothing, libc8-dev Depends on libc8 (usually exact
versioning).
libfoo does not Build-Depend on libc{8,}-dev, because it is provided by
Build-Essential (when building a Debian package). However, libfoo3-dev
Depends on libc8-dev, once built, because it references the headers (and,
as usual, on libfoo3). The libfoo3 package may have a versioned Depends on
libc8, as well, if that isn't somehow guaranteed already.
libbar Build-Depends on libfoo3-dev (needing headers and .so link), but not
libc8-dev (Build-Essential), and libbar7 Depends on libfoo3, as well as
probably having a versioned dependancy on libc8, while libbar7-dev Depends
on libc8-dev and libfoo3-dev, as well as libbar7.
libbaz Build-Depends on libfoo3-dev and libbar7-dev, and would not need
to Build-Depend on libc8-dev even if it were not Build-Essential. The
libbaz2 package Depends on libfoo3 and libbar7, but not (directly) on
libc8. libbaz2-dev Depends only on libbar7-dev and libbaz2; because there
is no header include dependancy on any libfoo header, and the shared
library already has the linking requirements for libfoo3 within the
library's NEEDED section (and it's guaranteed to be installed because of
the dependancy chain libbaz2-dev -> libbaz2 -> libfoo3), there is no need
to Depend on libfoo3-dev, since we need neither headers nor the .so link
from it.
> > * Does it need some way (a la shlibs) to resolve problems with "what
> > version of the -dev package is needed for this
Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org
On Fri, 2005-02-18 at 21:37 +0100, Mike Hommey wrote: > On Fri, Feb 18, 2005 at 02:15:16PM -0600, Steve Greenland <[EMAIL PROTECTED]> > wrote: > (...) > > And yes, it does belong there. It could easily add the something like: > > > >The single monolithic file is the normal upstream configuration, > >while the other choice is a Debian innovation that works better with > >large installations or ISPs needing to support many virtual domains. > > > > For newbies, this is the first MTA installation they will have ever > > seen. Help 'em out, for Pete's sake. > > Do newbies understand the concept of "upstream" ? Yes. Or vaguely. Depends on the level of newbieness. -- - Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B I prefer encrypted mail. "Don't tell me peace has broken out." Bertolt Brecht -- 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
* Steve Greenland: > And yes, it does belong there. It could easily add the something like: > >The single monolithic file is the normal upstream configuration, >while the other choice is a Debian innovation that works better with >large installations or ISPs needing to support many virtual domains. But this isn't completely correct. Even the single-file configuration differs conceptually from upstream because some of the options are managed through Debconf. Some people still complain that this isn't the upstream way. -- 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 Fri, Feb 18, 2005 at 02:15:16PM -0600, Steve Greenland wrote: > And J. Hassler asked: > > Does it tell you which is the upstream way? Most new users won't know. > > At which point Tollef quoted the debconf question, and the answer is > "no, it doesn't." > > And yes, it does belong there. I think a lot, if not most, Debian users do not care at all how upstream does there stuff. So exim upstream puts the debian config in /usr/exim by default, apache calls their binaries and config files httpd, and upstream's cron doesn't have the concept of cron.d. I'm running Debian, not LFS, gentoo or any other collection of upstream sources without much changes. Debian uses external sources (upstream), and changes it to behave like a Debian package. There's nothing wrong documenting the changes in README.Debian or similar, but I don't think that it should be required, and indeed, only cron of the three examples I listed note this change in their documentation, for those really interested, Debian distributes the diffs against upstream sources. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- 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 Thu, 2005-02-17 at 14:24 -0800, Blunt Jackson wrote: > On Thu, 17 Feb 2005 19:31:20 +, Henning Makholm <[EMAIL PROTECTED]> wrote: > > Scripsit Blunt Jackson <[EMAIL PROTECTED]> > > > > > As a general note, I find it annoying, frustrating, and confusing > > > whenever ANY debian package has a substantially different > > > installation or configuratin mechanism than the mechanism documented > > > by the software publisher. > > > > Perhaps Debian is not the distribution for you, then. We have always > > prioritized constistency across the entire Debian OS over adherence to > > what upstream authors somehow chose to do. > > Obviously there's a balance. I wasn't looking for flames. I believe I > did explain *why* debian was my distribution of choice even so. > > > I maintain one package whose upstream author apparently thought that > > $PATH would be a good place to look for a system-wide configuration > > file. I changed that to look in /etc instead, which makes the > > configuration mechanism in Debian substantially different from > > upstream's. You may find this annoying, frustrating and confusing, but > > it's how Debian operates. > > And clearly, *this* is a scenario in which the upstream author was way > outside the *unix* standard way of doing things. I'm not saying > there's any clear-cut answer, other than to hope that both upstream > developers and debian package maintainers use common sense. > > One distinction is in applications that the majority of users just > want to work out of the box, and forget about. If I had to tweak the > configuration of every application on my servers, I would be a > frothing maniac. But there are some biggies, some very well known > applications, that, when installed for any practical purpose, > generally require somewhat sophisticated user oversight. Exim is one, > Apache is another. Mysql is a third. I put in the time to figure out > the debian way of doing Exim (and I'm still not sure I understand it, > but at for now I have it working). There was a substantial amount of > hair pulling and cursing due to the disparity between what I saw on my > hard drive and what I saw in the online documentation. Okay, then generate the "old fashioned"Huge config file with --keepcomments and If you don't remove the banners for each file you will know which on the baddy. Also, if you need to re-order the routers (the only one out side of routers that need ordering is acl) then it is easy to do by simply changing the number/letters at the beginning of the files name. I DO NOT see what is so different from /etc/exim4/exim4.conf as compared to /var/lib/exim4/config.autogenerated, especially if you use --keepcomments. there really *IS* no difference. The pieces are just packaged in small manageable ones to aid in the updating of. Docs especially are like that Phil Hazel doesn't update them every time he bumps the release. Marc Haber and Andreas Metzler are doing a great job with exim. > After that > experience, when I installed apache and mysql, and saw they were doing > their own thing as well, I decided I didn't want to learn go through > the same frustration with applications I already knew pretty well. I > removed the debian packages, and compiled my own from the upstream > developers. Note that removing the debian packages did not remove all > their config files and so forth, there was a fair bit of manual > cleanup afterwards -- but I'm not using the stable distribution, so I > don't expect perfection. > > As for you, Florian's snide comment: > > > Just because the configuration file is called /etc/exim4/exim4.conf > > instead of /usr/exim/configure? Oh dear. > > No, it was the stuff like this that made me pull out my hair: > > domainlist local_domains = DEBCONFlocal_domainsDEBCONF > > How do I figure out where that DEBCONF stuff is coming from? What it means? When you use "update-exim4.conf --keepsettings" the generated fully populated is available at /var/lib/exim4/config.autogenerated. Also, any debconf setting are in the file: update-exim4.conf.conf things like DEBCONFlocal_domainDEBCONF is changed to the setting(s) in that file. Also, one other thing, look at the main directory in the config... it has about 3 files in it. Those three files are the important ones that define "default actions" for exim to take. Many of those are also can be managed by debconf as well. > Of course, it didn't help that during the install I didn't quite know > what I was doing, so based on the advice of the install program I > chose the big-file-install, which *was* what I wanted, but I forgot > that I had done that, so when I went to look at the exim config and > found, as the exim website told me I would find (because I was on > debian), a gazillion little bitty config files, I got started figuring > them out, editing them, and not realizing why it made no difference. > Suggestion to exim package people: if someone chooses the big config > file, don't eve
Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org
On Fri, 2005-02-18 at 06:54 +0100, Marc Haber wrote: > On Fri, 18 Feb 2005 10:01:45 +1100, Brian May <[EMAIL PROTECTED]> wrote: > >If something like this is different, then not only should Debian > >supplied documentation reflect the change, but a list of differences > >should appear in README.Debian. > > One thing I have learned in the last 24 hours is that people do not > bother to read available documentation, regardless of where it is > stored. You have to hurl it right into the user's face. > > I begin to understand the blurb of rants that cdrecord prints on > invocation. Indeedly-do. Many people cannot find it then. Some people just WANT THE ANSWER, don;t wanna learn anything to mayhaps fix it easy in the future. -- greg, [EMAIL PROTECTED] The technology that is Stronger, better, faster: Linux signature.asc Description: This is a digitally signed message part
Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org
On Thu, 2005-02-17 at 20:08 +0100, Marc Haber wrote: > On Thu, 17 Feb 2005 12:16:24 -0500, Greg Folkert > <[EMAIL PROTECTED]> wrote: > >Except I'd rather see --keepcomments as > >default and changed to --removecomments. My only gripe, pretty minimal. > > And fixed soon. #295735. Wow, I didn't even consider it a problem. I just edited the scripts to do it by default.. :) Now I don't have to. Thanks Marc. -- greg, [EMAIL PROTECTED] The technology that is Stronger, better, faster: Linux signature.asc Description: This is a digitally signed message part
Re: pwc-source headed for unstable this weekend
Scripsit Eric Lavarde <[EMAIL PROTECTED]> > So, basically, your saying that the right way to do this kind of > things is to use the corresponding kernel-headers package, and apt-get > tells me that I need as well kernel-kbuild to build "out-of-tree > kernel modules" which seems to be exactly what I need. That's what I infer from my own experience. But the kbuild stuff in 2.6 is kinda hairy, and I did not attempt to trace the exact conditions after I found a way to do thing that seems to work consistently for me. This may even be documented somewhere, although it did not jump out and bite my nose when I tried to find out what went wrong. Given the tendency of people like me to just repeat the procedures that worked for 2.4, 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. -- Henning Makholm "Luk munden og se begavet ud!" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The ghost of libc-dev
Scripsit Joel Aelwyn <[EMAIL PROTECTED]> > The reason given in the origional thread was that these Depends are not > solely for building Debian packages (when Build-Essential is reasonable to > expect), but for "I need to compile $userspace package", which does *not* > require B-E be installed, according to current policy. But can one get a C compiler at all (at least a Debian-supplied one) without also pulling in an appropriate libc-dev? I would think that "I need to compile $userspace package" *did* require at least a compiler to be installed, regardless of policy. Libc6-dev does *recommend* c-compiler, but that does not help with "I need to compile $userspace package" if $userspace package does not happen to require any third-party libraries. -- Henning Makholm"My fate? Servitude to the Embodiment of Whoops." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pwc-source headed for unstable this weekend
On Fri, 2005-02-18 at 20:35 +0100, Eric Lavarde wrote: > Hi, > > (I assume everybody is on -devel, like I am, and as it seems the problem > sits between keyboard and chair, no bug report either). > > This might very well be, as I didn't compile the kernel myself (I just > use the standard kernel-image-2.6.10-1-k7 package) but used > kernel-source-2.6.10 with the .config from the image package, make > oldconfig and make dep (which I was told is deprecated, so). That is exactly what the package "kernel-headers-2.6.10-1-k7" is for, it depends on "kernel-headers-2.6.10-1" and creates the symlink proper for thrid party and external modules to use. > > So, basically, your saying that the right way to do this kind of things > is to use the corresponding kernel-headers package, and apt-get tells me > that I need as well kernel-kbuild to build "out-of-tree kernel modules" > which seems to be exactly what I need. Yes, he is correct. -- greg, [EMAIL PROTECTED] The technology that is Stronger, better, faster: Linux signature.asc Description: This is a digitally signed message part
Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org
Le vendredi 18 février 2005 à 14:15 -0600, Steve Greenland a écrit : > On 18-Feb-05, 09:06 (CST), Josselin Mouette <[EMAIL PROTECTED]> wrote: > > Le vendredi 18 f??vrier 2005 ?? 08:37 -0600, Steve Greenland a ??crit : > > > No where in the Debconf note does it say which is "the upstream way". > > > > This has nothing to do in a debconf note. > > Sigh. Did you read the thread? W. Ballard wrote: > > > The exim4 config asks you if you want itty bitty or one monolothic > > config file. It offers you the option of doing it the upstream way. How is it relevant? > And yes, it does belong there. It could easily add the something like: > >The single monolithic file is the normal upstream configuration, >while the other choice is a Debian innovation that works better with >large installations or ISPs needing to support many virtual domains. > > For newbies, this is the first MTA installation they will have ever > seen. Help 'em out, for Pete's sake. Such a question will never help them. Why the hell would a newbie care of a package diverging from upstream (if he understands what an upstream is)? The newbie wants a working installation, full stop. That's why this question isn't high priority: it isn't even shown to the newbie. And the fact exim4 diverges from upstream has *absolutely nothing* to do in a debconf note. Debconf is here to promt users, not to document changes. We have README.Debian and changelog.Debian for that. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: The ghost of libc-dev
On Fri, Feb 18, 2005 at 09:17:55PM +, Henning Makholm wrote: > Scripsit Joel Aelwyn <[EMAIL PROTECTED]> > > > The reason given in the origional thread was that these Depends are not > > solely for building Debian packages (when Build-Essential is reasonable to > > expect), but for "I need to compile $userspace package", which does *not* > > require B-E be installed, according to current policy. > > But can one get a C compiler at all (at least a Debian-supplied one) > without also pulling in an appropriate libc-dev? I would think > that "I need to compile $userspace package" *did* require at least a > compiler to be installed, regardless of policy. > > Libc6-dev does *recommend* c-compiler, but that does not help with > "I need to compile $userspace package" if $userspace package does not > happen to require any third-party libraries. I guess that depends on whether one wants to rely on every package which Provides c-compiler to also Depend on the correct libc*-dev package for the relevant platform(s). If so, however, then it needs to become strictly not-OK to Depend on libc*-dev unless you're doing a versioned Dependancy, in which case you'll have to version every one of the various libc*-dev packages correctly (since you can't rely on the Provides libc6-dev of glibc packages to work in the presence of a versioned dependancy, and of course the non-glibc ports don't even consider adding that header, as it would be utterly bogus - they can't even pretend to be the same thing, only equivalent, which is libc-dev). Really, I think the simplest answer is a tool that detects *all* of the relevant -dev packages, in a simple and automated fashion, for the exact same reasons we don't expect people to try to hand-version and hand-impart every shared library dependancy their package has, but instead provide dpkg-shlibdeps and dh_shlibdeps. -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: The ghost of libc-dev
Scripsit Joel Aelwyn <[EMAIL PROTECTED]> > On Fri, Feb 18, 2005 at 09:17:55PM +, Henning Makholm wrote: >> But can one get a C compiler at all (at least a Debian-supplied one) >> without also pulling in an appropriate libc-dev? I would think >> that "I need to compile $userspace package" *did* require at least a >> compiler to be installed, regardless of policy. > I guess that depends on whether one wants to rely on every package which > Provides c-compiler to also Depend on the correct libc*-dev package for > the relevant platform(s). 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. I have no a priori opinion about whether such making sure should involve virtual packages, and if so which. However, a -dev packages that contains C(++) headers is obviously only useful if one already has a C compiler, so there should be no need to depend directly on a libc-dev. One might argue that any -dev package that provides a C interface should depend on c-compiler themselves, but our traditional answer to that one seems to be, "don't be silly; a user should be able to figure out *that* by himself". > 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. 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. -- Henning Makholm "En tapper tinsoldat. En dame i spagat. Du er en lykkelig mand ..." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: First line in /etc/hosts
Hi > > > Machines don't have IP numbers. Interfaces have IP numbers. Every > > > machine > > > > Actually, that's not quite the case (as a number of users of Linux's ARP > > implementation have found), though it's a good approximation. > > Indeed. For Linux, nodes have IP *numbers* which are all equal, and you have > to take great pains to make sure it behaves in any different way. iproute2, > arptables and the relative black magic of arp_filter are your only ways to > try to influence that. Usual route, ifconfig, etc are useless. This portion is unclear to me; could you shed some light ? Do you mean: 1. on linux there is a principal IP address that is assigned to a node regardless of NIC due to the implementation of ARP etc. 2. on linux there is some magic IP *number* that is assigned to a node; and IP addresses are assigned to individual NICs. -> if so, what is a IP number? regards, junichi -- 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 18-Feb-05, 17:45 (CST), Josselin Mouette <[EMAIL PROTECTED]> wrote: > Such a question will never help them. Why the hell would a newbie care > of a package diverging from upstream (if he understands what an upstream > is)? Jesus H. Christ. Read the original post to this thread. It was a complaint about how the upstream docs were not consistent with the debian config. > And the fact exim4 diverges from upstream has *absolutely nothing* to do > in a debconf note. Debconf is here to promt users, not to document > changes. But how would it hurt to say that choice A is more standard? Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: First line in /etc/hosts
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >> > > Machines don't have IP numbers. Interfaces have IP numbers. Every >> > > machine >> > >> > Actually, that's not quite the case (as a number of users of Linux's ARP >> > implementation have found), though it's a good approximation. >This portion is unclear to me; could you shed some light ? > >Do you mean: [wrong guesses omitted] A machine may use the same IP on multiple interfaces. A machine may use multiple IP addresses on a single interface. The two may be combined. A router may use proxy arp. A machine may use the same ethernet address on multiple interfaces on different physical networks. This tends not to work well with vlans. (switches pretending to be multiple networks) -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- 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
Steve Greenland <[EMAIL PROTECTED]> writes:
> Jesus H. Christ. Read the original post to this thread. It was a
> complaint about how the upstream docs were not consistent with the
> debian config.
Huh? The original post AFAICT of this thread consisted of Marc Haber
complaining that it was inappropriate for Ian Jackson to complain
about Debian's packaging on the exim-users upstream mailing list.
Ian Jackson's complaint in that thread had nothing to do with
documentation, AFAICT.
Marc Haber also referenced a bug, number #295391, reported by Ian
Jackson which appears to have started this, and in this bug, Ian is
complaining that when you ask for the one-file configuration, you
still see the tools for the many-file configuration installed. Ian
misunderstood what the exim package was doing; requesting the
single-file method does in fact get you the single-file method; he
incorrectly thought that this meant that /etc/exim4 shouldn't have
the other files in it at all.
He also reported a separate bug in the same bug report. Most of the
discussion in the bug log consists of Ian insisting that the way to
fix the bug he was seeing was to throw out whatever Debian was doing.
He also deleted exim from his machine and switch to smail, so it
became impossible to track down whatever the second bug was, as it
does not occur for the developer.
It reads rather like Ian throwing a tantrum, complaining that his
proposed solution ("this abomination should be thrown away and
rewritten") wasn't being taken seriously, and refusing to help find a
fix to the bug.
And then, taking his fight to the exim-users mailing list too.
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.
Thomas
--
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
Steve Greenland <[EMAIL PROTECTED]> writes: > > And the fact exim4 diverges from upstream has *absolutely nothing* to do > > in a debconf note. Debconf is here to promt users, not to document > > changes. > > But how would it hurt to say that choice A is more standard? What is "more standard"? I think everyone agrees (am I wrong?) that the question should say: "if you don't know which to pick, then pick the single-file method." -- 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
Le vendredi 18 février 2005 à 19:29 -0600, Steve Greenland a écrit : > > And the fact exim4 diverges from upstream has *absolutely nothing* to do > > in a debconf note. Debconf is here to promt users, not to document > > changes. > > But how would it hurt to say that choice A is more standard? More standard for what? AFAIK, Debian is the only widespread operating system which ships exim by default. What the exim maintainers decide becomes the standard for Debian users. Furthermore, how does a thing being "standard" help the user in his choice? The user only thinks of his own needs, thus a correct wording would be "pick A if you don't care". However the current wording is even better; the question isn't even asked at high priority, and the single file method is silently chosen. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: First line in /etc/hosts
On Fri, 18 Feb 2005, Blars Blarson wrote: > In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: > >> > > Machines don't have IP numbers. Interfaces have IP numbers. Every > >> > > machine > >> > > >> > Actually, that's not quite the case (as a number of users of Linux's ARP > >> > implementation have found), though it's a good approximation. > > >This portion is unclear to me; could you shed some light ? > > > >Do you mean: > > [wrong guesses omitted] > > A machine may use the same IP on multiple interfaces. > A machine may use multiple IP addresses on a single interface. > The two may be combined. > > A router may use proxy arp. > > A machine may use the same ethernet address on multiple interfaces on > different physical networks. This tends not to work well with vlans. > (switches pretending to be multiple networks) Also: As far as the kernel is concerned, any local IP is local to *all* interfaces, and it will happly reply to it (ARP and so on) if allowed to. The rp_filter will often avoid trouble here, BUT routers often have to disable rp_filter. So add some rules to the firewall make sure nothing gets into 127.0.0.0/8 unless it is a local packet. -- "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: "The Debian exim 4 packages suck badly" on exim-users@exim.org
On Sat, Feb 19, 2005 at 03:02:00AM +0100, Josselin Mouette wrote: > Furthermore, how does a thing being "standard" help the user in his > choice? The user only thinks of his own needs, thus a correct wording > would be "pick A if you don't care". However the current wording is even > better; the question isn't even asked at high priority, and the single > file method is silently chosen. Is the multiple-file configuration logically equivalent to the single-file configuration? If you #include'd all the tiny subfiles, would the resulting config be identical to the single-file config? If so, then what are we really arguing about: they are isomorphic. Perhaps a tool could generate the single-file config for easier double-checking of the split-file config. If not, then the user needs to know what will behave differently. -- 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
This one time, at band camp, William Ballard said:
> On Sat, Feb 19, 2005 at 03:02:00AM +0100, Josselin Mouette wrote:
> > Furthermore, how does a thing being "standard" help the user in his
> > choice? The user only thinks of his own needs, thus a correct
> > wording would be "pick A if you don't care". However the current
> > wording is even better; the question isn't even asked at high
> > priority, and the single file method is silently chosen.
>
> Is the multiple-file configuration logically equivalent to the
> single-file configuration? If you #include'd all the tiny subfiles,
> would the resulting config be identical to the single-file config?
>
> If so, then what are we really arguing about: they are isomorphic.
> Perhaps a tool could generate the single-file config for easier
> double-checking of the split-file config.
>
> If not, then the user needs to know what will behave differently.
The only difference, AFAICT, is that when you pick the split file
option, the split files are concattenated together on /etc/init.d/exim4
{stop,restart,reload} (this is really handled by update-exim4.conf, but
that is irrelevant to the user perspective, IMHO). They produce the
same initial configuration in any case. The only difference from a user
experience is knowing that split files vs. monolithic is really related
to what to edit, rather than where configuration is read at runtime.
--
-
| ,''`.Stephen Gran |
| : :' :[EMAIL PROTECTED] |
| `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
-
pgpfuCekcqtDV.pgp
Description: PGP signature
Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org
On Fri, Feb 18, 2005 at 09:36:54PM -0500, Stephen Gran wrote: > that is irrelevant to the user perspective, IMHO). They produce the > same initial configuration in any case. The only difference from a user Good lord, what are we arguing about then :-) Do people who edit their exim config (I never do on my desktop) really have a hard time grasping #include files? -- 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
William Ballard <[EMAIL PROTECTED]> writes: > Good lord, what are we arguing about then :-) > Do people who edit their exim config (I never do on my desktop) > really have a hard time grasping #include files? You've missed the point of the many-small-files config. As a happy user, let me explain what it's about. The point is that I want to massage some parts of the configuration and not others. I want the others to continue to get updated by the normal package installation process. If I use the one-big-file method, I can't really do this. I would modify parts of the file, but then I can either install the new file or not when the package updates it. It's a PITA, to merge every time a small change is made in some other part of such a large config file. So the many-small-files is perfect for a site like mine. Many changes aren't even changes that get noticed by dpkg, because they involve making new files to specify new router rules, for example. They just get automatically put into the generated config file. And by contrast, when nearly any change is made by the Debian package, it just automatically goes into the new version without the need for me to hand-edit the changes. Really big sites will have their own config files anyway, so nothing done by Debian matters much to them. Small and ordinary sites may be happy with the default big file, because they never need to modify it anyway. But middling sites, or sites like mine with small variations on the normal model (in my case, I have a second domain that I MX for through a special alias file) find the many-small-files just perfect. Thomas -- 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
This one time, at band camp, Thomas Bushnell BSG said: > The point is that I want to massage some parts of the configuration > and not others. I want the others to continue to get updated by the > normal package installation process. > > If I use the one-big-file method, I can't really do this. I would > modify parts of the file, but then I can either install the new file > or not when the package updates it. It's a PITA, to merge every time > a small change is made in some other part of such a large config file. I wanted to mention that I completely agree with this sentiment. We run a couple of mail clusters, and we manage many single mail servers. Thanks to the split file approach, we can ship a couple of custom config files that allows us to tweak everything we need with a few macros and ifdef's. We still get the nice package management and improvement of routers and transports and all the rest of it. My only point in the previous mail is that there really is no difference in what is happening at run time - the only thing the end user has to know is that they when they pick one setting, they make edits here, and if they choose the other, they make edits there. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpIXM7SWdz48.pgp Description: PGP signature
Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org
On Fri, Feb 18, 2005 at 07:27:27PM -0800, Thomas Bushnell BSG wrote: > William Ballard <[EMAIL PROTECTED]> writes: > > > Good lord, what are we arguing about then :-) > > Do people who edit their exim config (I never do on my desktop) > > really have a hard time grasping #include files? > > You've missed the point of the many-small-files config. As a happy > user, let me explain what it's about. I use them too. I never my exim config at all, so I read the debconf note and chose the many small files option. I think you misunderstood my post. I said something like "who would be confused by what is in essence #include files?" Please spare me your moralizing when you don't even read my post very closely and I was already in favor of the current way Debian handles it. Sheesh. -- 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
William Ballard <[EMAIL PROTECTED]> writes: > Please spare me your moralizing when you don't even read my post very > closely and I was already in favor of the current way Debian handles it. I wasn't moralizing; I'm sorry if I misunderstood your note. Many people here have failed to understand the point of the many-small-files option, so I figured that a more complete explanation would be independently useful. I misunderstood you to be saying that since the two methods (when you make no modifications) produce the same results, those of us who like the many-small-files version should just use includes instead. But I see now that you weren't saying that. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#295927: ITP: drift -- type sensitive preprocessor for Haskell
Package: wnpp Severity: wishlist Owner: Arjan Oosting <[EMAIL PROTECTED]> * Package name: drift Version : 2.1.0 Upstream Author : John Meacham <[EMAIL PROTECTED]> * URL : http://repetae.net/john/computer/haskell/DrIFT/ * License : MIT Description : type sensitive preprocessor for Haskell DrIFT automates instance derivation for classes that aren't supported by the standard compilers. In addition, instances can be produced in separate modules to that containing the type declaration. This allows instances to be derived for a type after the original module has been compiled. As a bonus, simple utility functions can also be produced from a type. . Features: - DrIFT comes with a set of rules to produce instances for all derivable classes given in the Hasekell Prelude. There are also a number of extra useful rules to derive instances of a variety of useful classes. - DrIFT performs import chasing to find the definition of a type. - Code is generated using pretty-printing combinators. This means that the output is (fairly) well formatted, and easy on the eye. - Effort has been made to make the rule interface as easy to use as possible. This is to allow users to add rules to generate code specific to their own projects. As the rules are themselves written in Haskell, the user doesn't have to learn a new language to express rules. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (102, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.10-2-stardust Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- 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
Scripsit Thomas Bushnell BSG <[EMAIL PROTECTED]> > The point is that I want to massage some parts of the configuration > and not others. I want the others to continue to get updated by the > normal package installation process. So is the whole thing essentially a workaround for dpkg's current lack of good conffile update management, or would you still prefer the separate files way if dpkg magically gained a well-tested and stable conflict resolution scheme with bells, whistles, and 3-way merges? -- Henning Makholm "Gå ud i solen eller regnen, smil, køb en ny trøje, slå en sludder af med købmanden, puds dine støvler. Lev!"
Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org
Henning Makholm <[EMAIL PROTECTED]> writes: > Scripsit Thomas Bushnell BSG <[EMAIL PROTECTED]> > > > The point is that I want to massage some parts of the configuration > > and not others. I want the others to continue to get updated by the > > normal package installation process. > > So is the whole thing essentially a workaround for dpkg's current > lack of good conffile update management, or would you still prefer the > separate files way if dpkg magically gained a well-tested and stable > conflict resolution scheme with bells, whistles, and 3-way merges? Um, no, I don't think I said that. When I say, "this is an important thing that X provides", you cannot go and assume that I mean "this is the only reason to like X." Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
