Re: exim, local resolver, host name lookups and IPv6
Marc Haber wrote: > On Sat, 12 Apr 2008 14:58:24 +, The Fungi <[EMAIL PROTECTED]> > wrote: >> On Sat, Apr 12, 2008 at 10:41:54AM +0200, Marc Haber wrote: >> [...] >>> Where can I obtain the FQDN of the system instead? >> [...] >> >> You can't, necessarily. > > So it needs to be in /etc/hosts. This would lead to broken config for a lots of *DSL box. When the machine is running on RFC 1918 addresses behind a NAT (made by the router), what you need is the external FQDN hostname of the router (which must be configured to forward the port 25) to answer to the EHLO greating. And adding the router fqdn in the machine /etc/hosts seems really wrong to me in that case: the machine is not the router and must not be reached when trying to reach the router. >> Is there any way to simply >> *insist* the FQDN be present in the config (provided by the >> administrator via debconf or by manual editing after installation) >> and just be done with all the guessing? This seems a good tip. The FQDN for mail must be in a config file. > I'd rather avoid this and guess the name from a central point created > during installation. This value can, indeed, be guested at installation time with any heuristic (/etc/mailname, gethostby*(), debconf, ...) >> Maybe even refuse to start >> the daemon until this is provided, with a clear error message to >> that effect? > > Nosireebob, people do not read error messages but post bug reports > instead. I am not prepared to handle these. So, in case the user REMOVE the config value, you can failback to these guesses (with a warning in the logs ?). But the normal (enforced at installation/upgrade time) way should be a documented value in a config file. Best regards, Vincent -- Vincent Danjean GPG key ID 0x9D025E87 [EMAIL PROTECTED] GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pacakges: http://www-id.imag.fr/~danjean/deb.html#package APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Initial configuration and installation through d-i
Hello, some packages require initial configuration of an external service. The most common case is the creation of a dedicated database (relational or LDAP). This is usually done in the postinst. When the database is hosted on the same server, it means that the database server needs to be running and functional. But that's not the case if you install the packages directly within debian-installer (the /target chroot is temporarily configured in a way that no services are started by invoke-rc.d, and that's a sane thing to do IMO). This is a pain for CDD that want to auto-install some of those packages. How should we handle this problem? For the the specific case that affected me, I resolved the problem by creating a simple mechanism to handle initial configuration of such packages: the initial configuration is moved to a dedicated script that can be called in 3 ways. The first way is with a "possible" parameter, the script needs to verify of the pre-requesite are satisfied (is the DB server up and usable?). The second way is with a "needed" parameter, the script checks if the initial configuration is needed or if it was already done by some other ways. And the third way is with a "configure" parameter and here the real job is done. The postinst runs "configure" only if "possible" and "needed" are true. If "possible" is false, then it registers the script for later execution (by creating a symlink to itself in some predetermined directory). A new init script has been added so that at the end of the boot sequence, when all services have been started, another try is made for all the registered scripts. On success, the symlink is removed, otherwise it's kept for as long as the configuration doesn't succeed. This means that initial configuration (usually) happens at the end of the first reboot. What would be the proper place for such a "deferred configuration" service? Does it require a dedicated package or would it fit in some existing one? The principle is generic enough to be applied to other cases than database creation but as it's the most important use, maybe dbconfig-common would be a good choice? Opinions welcome. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: initng -- full replacement of the old sysvinit init system
* David Paleino [Mon, 14 Apr 2008 12:26:08 +0200]: > it didn't give me much > problems. Sometimes happened that an upgrade failed (probably it could be > handled better via postinst), so I had to reboot with sysvinit to fix > things up (both systems can cohexist! :)). Uh. That doesn't sound suitable for unstale; upload to experimental until such problems are completely gone. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: The Wallflowers - Another one in the dark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ITP: initng -- full replacement of the old sysvinit init system
Package: wnpp Severity: wishlist Owner: David Paleino <[EMAIL PROTECTED]> (CCing debian-devel@ for comments on this) * Package name: initng Version : 0.6.10.2 Upstream Author : Jimmy Wennlund <[EMAIL PROTECTED]> Ismael Luceno <[EMAIL PROTECTED]> * URL : http://www.initng.org/ * License : GNU GPL v2+ Programming Lang: C Description : full replacement of the old sysvinit init system Hi, I'd like to reintroduce into Debian the initng package, since I've been using it for years and it didn't cause too much problems (yet, it's not as stable as sysvinit during upgrades, but does its job). It has been removed some time ago from the archive: = [Date: Mon, 30 Jul 2007 22:58:03 +] [ftpmaster: Joerg Jaspert] Removed the following packages from experimental: initng |0.3.0-1 | arm, powerpc, s390 initng |0.5.2-1 | source, alpha, hppa, i386, ia64, m68k, mips, mipsel, sparc Closed bugs: 435127 --- Reason --- RoM: obsolete; inactive upstream; buggy -- = I'd like to argument on those reasons. Firstly, it's not obsolete, since we only have sysvinit available (if we had upstart, or something similar to initng, I could've agreed here -- and upstart in Debian is way more experimental than initng). Secondly, upstream isn't "inactive". It has just slown down a bit; a fact is the release of initng-ifiles just yesterday (Apr 13, 2008). Thirdly, it's not that buggy. I've been using it since version 0.3.$something (I believe; well, it's been a long time ago), and it didn't give me much problems. Sometimes happened that an upgrade failed (probably it could be handled better via postinst), so I had to reboot with sysvinit to fix things up (both systems can cohexist! :)). I'm thus filing an ITP for initng (I'll soon file one for initng-ifiles, since they have different sources). I've CCed debian-devel@lists.debian.org for comments on this ITP. Kindly, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: ITP: initng -- full replacement of the old sysvinit init system
On Mon, 14 Apr 2008 12:48:26 +0200, Adeodato Simó wrote: > * David Paleino [Mon, 14 Apr 2008 12:26:08 +0200]: > > > it didn't give me much > > problems. Sometimes happened that an upgrade failed (probably it could be > > handled better via postinst), so I had to reboot with sysvinit to fix > > things up (both systems can cohexist! :)). > > Uh. That doesn't sound suitable for unstale; upload to experimental > until such problems are completely gone. I know what you mean. Maybe I wasn't too clear: some problems happened when I booted with, let's say, 0.5.*, and upgraded to 0.6.*, it tried to shutdown the system using the 0.6.* scripts. Now I don't really see these problems happen anymore, they should have gone away: that's why initng-ifiles exists (once the scripts were tightly connected to the core). (or, probably, they happen when there's a major upgrade, i.e. from 0.x to 0.y) Thanks for your reply, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: ITP: initng -- full replacement of the old sysvinit init system
On Mon, 14 Apr 2008 12:48:26 +0200, Adeodato Simó wrote: > * David Paleino [Mon, 14 Apr 2008 12:26:08 +0200]: > > > it didn't give me much > > problems. Sometimes happened that an upgrade failed (probably it could be > > handled better via postinst), so I had to reboot with sysvinit to fix > > things up (both systems can cohexist! :)). > > [..] upload to experimental until such problems are completely gone. Forgot to say, I perfectly agree to upload to experimental for quite some time. Yet I believe that experimental doesn't give the widest audience of possible testers (let's say it: bug-catchers); I believe that uploading to unstable (and than letting the migration to testing be blocked by filed bugs) would be better. But probably this is another question :) Cheers, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: ITP: initng -- full replacement of the old sysvinit init system
David Paleino wrote: Firstly, it's not obsolete, since we only have sysvinit available (if we had upstart, or something similar to initng, I could've agreed here -- and upstart in Debian is way more experimental than initng). I doubt you can back up this claim. My experiences with both initng and upstart have taught me the opposite. upstart was way more reliable and mature. One reason is, that the current version of upstart in experimental still uses the sysv init scripts. This is by design though, so you can have a smooth transition. initng doesn't offer something similar. With initng you have to replace everything and reconfigure your complete boot system (I know that there is a tool in initng which tries to guess which services to use and activates those ifiles, which is fragile at best). The reason why upstart is in experimental is different (unresolved issue about sysvinit being essential and upstart conflicting with it). But claiming that initng was more mature than upstart (or upstart way more experimental) is FUD, sorry. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: ITP: initng -- full replacement of the old sysvinit init system
On Mon, 14 Apr 2008 13:14:57 +0200, Michael Biebl wrote: > David Paleino wrote: > > > Firstly, it's not obsolete, since we only have sysvinit available (if we had > > upstart, or something similar to initng, I could've agreed here -- and > > upstart in Debian is way more experimental than initng). > > I doubt you can back up this claim. My experiences with both initng and > upstart have taught me the opposite. upstart was way more reliable and > mature. I can't really back up my claim; it was just my experience after an apt-get install upstart :) > One reason is, that the current version of upstart in experimental still > uses the sysv init scripts. This is by design though, so you can have a > smooth transition. This is great, thanks for the info. > [..] > > The reason why upstart is in experimental is different (unresolved issue > about sysvinit being essential and upstart conflicting with it). Probably this broke my system when I installed upstart. Going to read upstart's bug page. > But claiming that initng was more mature than upstart (or upstart way > more experimental) is FUD, sorry. I didn't mean to, sorry. It was just my one-day-experience. I'm happy that there's something more mature than initng then! :) Thanks, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: ITP: initng -- full replacement of the old sysvinit init system
David Paleino wrote: On Mon, 14 Apr 2008 13:14:57 +0200, Michael Biebl wrote: David Paleino wrote: Firstly, it's not obsolete, since we only have sysvinit available (if we had upstart, or something similar to initng, I could've agreed here -- and upstart in Debian is way more experimental than initng). I doubt you can back up this claim. My experiences with both initng and upstart have taught me the opposite. upstart was way more reliable and mature. I can't really back up my claim; it was just my experience after an apt-get install upstart :) I'd be very interested in a bug report. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: exim, local resolver, host name lookups and IPv6
On Sat, Apr 12, 2008 at 10:41:54AM +0200, Marc Haber wrote: > Where can I obtain the FQDN of the system instead? _Which_ FQDN? A machine may have several IP addresses, in the DNS there may be multiple A records for every IP address (and the reverse PTR records may be completely meaningless placeholders). Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: exim, local resolver, host name lookups and IPv6
This one time, at band camp, Gabor Gombas said: > On Sat, Apr 12, 2008 at 10:41:54AM +0200, Marc Haber wrote: > > > Where can I obtain the FQDN of the system instead? > > _Which_ FQDN? A machine may have several IP addresses, in the DNS there > may be multiple A records for every IP address (and the reverse PTR > records may be completely meaningless placeholders). Marc, I suspect that this line of enquiry is just going to make Debian's exim config setup even more baroque and less useful to people who actually use exim the way it was designed to be used. Can't you just document it, and close bugs as they come in with a note to the docs? I know it's not perfect, but I'm not completely convinced that running an MTA behind a dial on demand setup is so normal an endeavor that we should bend over backwards to support it out of the box. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: triggers wishlist
Anyone out there? On Tue, Apr 1, 2008 at 9:27 AM, Tshepang Lekhonkhobe <[EMAIL PROTECTED]> wrote: > On Mon, Mar 31, 2008 at 10:28 AM, Josselin Mouette <[EMAIL PROTECTED]> wrote: > > On dim, 2008-03-30 at 16:25 -0400, Joey Hess wrote: > > > Things I want to see use triggers, in approximate priority order: > > > > > > - scrollkeeper > > > > It will probably be deprecated soon, so I don't think it is necessary to > > put effort into it. > > Would rarian-compat be the replacement? If so, what's the delay? -- my place on the web: floss-and-misc.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Moving from console-tools to kbd [was: Bug#476097: kbd: Incorrect LSB init header]
Hi fellow DDs, I had two separate discussions today with Alistair and Michael, about the state of console-tools and kbd in Debian. I decided to take this discussion to debian-devel to get more feedback on this matter. Following are the relevant parts of the discussion: Michael Schutte wrote: On Mon, Apr 14, 2008 at 03:50:58PM +0200, Michael Biebl wrote: Btw, I asked the maintainer of console-tools, Alastair McKinstry, about the state of console-tools in Debian (lots of bug reports with patches, no upload since a long time) and I'll be quoting the relevant parts here: Alastair McKinstry wrote: Yes, I've been very busy, and a co-maintainer would be a good idea. The code is already in alioth. More importantly, console-tools has no upstream developer, for several years now. kbd, which it intended to replace, is in active development. Hence console-tools should be removed from Debian, but a plan for replacement needs to be tested (compare kbd to console-tools; look for patches to console-tools that should be ported back to kbd, either features or bugfixes; test upgrade scripts in Debian). kbd is a 'mostly' drop-in replacement, but has some binaries not present in kbd at the moment. So it looks like, if Alaistair preferred, if console-tools was deprecated in favor of kbd (after working out a migration plan). Yes, I know about the status of console-tools. A quote from #446030, where Anton Zinoviev wrote: The transition from console-tools to kbd has been planned for years and the only reason of the delay is the chronic shortage of console maintainers in Debian. It seems Alastair supports only console-tools and for the rest it is only me and Christian Perrier and we both are doing this only because nobody else does. I have been added to the pkg-kbd team since then. Do you think this could be done for lenny? Do you think it should be done at all? If so, would you be interested to look into that? I think it has to be done sooner or later, if only because of lacking upstream development in console-tools. I don’t know if it is possible to do this transition for Lenny, but having a brief look at it, it should not be so hard: fonty is the only package with a build-rdep on console-tools which doesn’t allow kbd as an alternative choice. It currently has an ITO and would probably need an NMU to fix this. And there are only three packages with binary rdeps (or r-recommends) on console-tools only; they are cmatrix, dynafont and freevo. I’ll have a look at how much stuff there is in console-tools that we do not have in kbd. After fixing the four packages I listed above and integrating possible patches, it should be safe to drop console-tools. Comments are welcome. console-tools is currently preferred over kbd and installed by default (on 97.41% of all machines according to popcon). Given the comments of Michael and Alistair, it seems clear to me that we should move away from console-tools (back) to kbd. Also, Michael seems to be willing to look into this matter. The question now is, if we should try to get this issue fixed for lenny or defer it to lenny+1. What other issues would need attention, d-i,..? Comments welcome. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Moving from console-tools to kbd [was: Bug#476097: kbd: Incorrect LSB init header]
(keeping CC, just in case) > console-tools is currently preferred over kbd and installed by default > (on 97.41% of all machines according to popcon). > > Given the comments of Michael and Alistair, it seems clear to me that we > should move away from console-tools (back) to kbd. Also, Michael seems > to be willing to look into this matter. > > The question now is, if we should try to get this issue fixed for lenny > or defer it to lenny+1. What other issues would need attention, d-i,..? At first glance, the move is probably what should be donebut I think it's now too late for lenny. signature.asc Description: Digital signature
Re: (English-speaking) Canadian users: default to US or "Canadian multilingual" keymap?
On Sun, Apr 13, 2008 at 08:28:12AM +0200, Christian Perrier wrote: > I'm seeking advices for #475482. > > console-data recently got a new keymap, namely "ca-multi", which > features the "Canadian multilingual" keymap. This keymap is > standardized by standard bodies in Canada and seems to be available > from several hardware vendors. > > My understanding is that local official bodies are required to use > this keymap (particularly in Quebecbut the standard seems to apply > to the entire country). On the other hand, it is pretty leikely that > English-speaking users in Canada traditionnally use the US keymap (see > #475482). > > The point is whether the *default* keymap preselected in D-I should be > "us" or "ca-multi" when English+Canada is chosen. That keymap choice > also influences the X keymap choice. > > That could be a sensitive choice (linguistic topics in Canada always > are), which is why I'm seeking for more advice, particularly from > Canadian users (or users living in Canada). Well I would say that I haven't seen a french canadian keyboard outside of quebec, although perhaps the government does use them. Certainly for the typical user that actually gets to install Debian on their machine, those that pick english as the language and canada as the region, will also pick US keyboard layout in 99.99% of cases, since that's what they have. If they were to pick french as their language and be in canada, then the french-canadian layout would almost certainly be what they have, since typing french on a US keyboard is quite a pain. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Initial configuration and installation through d-i
hiya, On Monday 14 April 2008 12:28:33 pm Raphael Hertzog wrote: > When the database is hosted on the same server, it means that the database > server needs to be running and functional. But that's not the case if you > install the packages directly within debian-installer (the /target chroot > is temporarily configured in a way that no services are started by > invoke-rc.d, and that's a sane thing to do IMO). there are also probably a few corner cases on live systems, where the "service" is being upgraded/installed simultaneously and is not available during postinst. > This is a pain for CDD that want to auto-install some of those packages. > > How should we handle this problem? shooting from the hip here, but i suspect there may be a fairly graceful and general way of doing this, via triggers plus something like what you mention here: > A new init script has been added so that at the end of the boot sequence, > when all services have been started, another try is made for all the > registered scripts. On success, the symlink is removed, otherwise it's > kept for as long as the configuration doesn't succeed. This means that > initial configuration (usually) happens at the end of the first reboot. in the case of dbconfig-common, my thought is that it could somehow use triggers to schedule deferred execution of the database configuration stuff until the very end, after the databases are guaranteed to be back up. that should cover the problem on "live" systems. in d-i, some kind of hook could be placed on the trigger execution, such that instead of executing it at the end of dpkg's run, the commands are placed into a batch script in /var/lib/somewhere and executed by a hypothetical "firstboot" script. and generally speaking, i imagine that CDD's (as well as those doing preseeded custom installs) would appreciate having such a "firstboot" feature from dpkg, anyway. i'm not at all familiar enough with either triggers or d-i to know if this is feasible though. sean signature.asc Description: This is a digitally signed message part.
Bug#476136: ITP: squirrelmail-logger -- SquirrelMail plugin: Add logging functionality to your webmail interface
Package: wnpp Severity: wishlist Owner: Jan Hauke Rahm <[EMAIL PROTECTED]> -BEGIN PGP SIGNED MESSAGE- Hash: SHA224 * Package name: squirrelmail-logger Version : 2.2 Upstream Author : Paul Lesniewski <[EMAIL PROTECTED]> and others * URL : http://www.squirrelmail.org/plugin_view.php?id=52 * License : GPL-2 Programming Lang: PHP Description : SquirrelMail plugin: Add logging functionality to your webmail interface This plugin implements logging functionality for your webmail interface. You can choose to log to a database, a file, your system log, or any combination thereof. You can also choose which kinds of events to log, including login events, logout events, login error events, all outgoing messages, possible outgoing spam messages, and other error events. . Also included is monitoring functionality that will send alert emails to the administrator when certain events trigger. Log message format is completely custom-defined to meet your needs in the configuration file. . SquirrelMail is a standards-based webmail package written in PHP. It runs on top of any IMAP server. - -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (700, 'testing'), (600, 'unstable'), (500, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iE8DBQFIA5EmGOp6XeD8cQ0RC4kPAN9acchcKGLxeaNh9TA1kxvGzGPdPaqSoprt TgssAN9DXeDF5Woai2d0KcEoln0A3JX0WTr1eyZxnoRP =7oXO -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Moving from console-tools to kbd [was: Bug#476097: kbd: Incorrect LSB init header]
On Mon, Apr 14, 2008 at 05:51:36PM +0200, Christian Perrier wrote: > (keeping CC, just in case) You can drop me at least. > > console-tools is currently preferred over kbd and installed by default > > (on 97.41% of all machines according to popcon). > > > > Given the comments of Michael and Alistair, it seems clear to me that we > > should move away from console-tools (back) to kbd. Also, Michael seems > > to be willing to look into this matter. > > > > The question now is, if we should try to get this issue fixed for lenny > > or defer it to lenny+1. What other issues would need attention, d-i,..? > > At first glance, the move is probably what should be donebut I > think it's now too late for lenny. Do you think that there is a specific step that will take a long time? Fixing the three packages is no problem. fonty and dynafont build from the same source and do well without console-tools, same with cmatrix; freevo actually needs a modification, but that’s just three characters. I’ll submit the relevant patches soon. If it is just a general feeling that the transition will break some things in unexpected ways, I think it is a good idea if some of the readers of this list could try switching from console-tools to kbd. I suppose that most users won’t see a difference, but more bugs could be reported that way. As d-i has been brought up: Moving from console-tools to kbd does not affect the installer; console-tools needs libconsole, which is too large for d-i, so it already uses kbd-udeb. I don’t have a problem with waiting for Lenny first. But reading #387129, for example, the transition probably should already have happened. So why not now :-) Cheers, -- Michael Schutte <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Plib, shared libraries issue.
Hi, I'm currently in the process of adopting plib and would like some advice regrading it's shared/static libraries. Upstream, plib is built as a set of static libraries due to the nature of it's use, i.e. a set of helper libraries that programs will only use part of. The Debian package currently has shared libraries that have been 'hacked' on top, (#475331 and #470503 are relevant to this). Currently I have fixed the way this has been done by patching the build system, so that shared libraries are produced properly. But this presents two questions: 1. Should these shared libraries be built, or should it just stick to static libraries as upstream intended? 2. If shared libraries /are/ built, should they all be in one package (there are 13 libraries in total), or should they be separated, and also what should be done about the sonames of the libraries and the name of the package(s)? (I have CC'd this to the maintainers of the packages that currently rdepend on plib, namely simgear, supertuxcart, stormbaancoureur, fgfs-atlas, flightgear and torcs. Any feedback from you would be much appreciated) Thanks in advance, Bradley Smith signature.asc Description: PGP signature
Bug#476153: ITP: phpicalendar -- iCal file web viewer
Package: wnpp Severity: wishlist Owner: Al Nikolov <[EMAIL PROTECTED]> * Package name: phpicalendar Version : 2.24 Upstream Author : Chad Little <[EMAIL PROTECTED]> and others * URL : http://phpicalendar.net * License : GPL Programming Lang: PHP Description : iCal file web viewer PHP iCalendar is a PHP-based iCal file viewer/parser to display iCals in a Web browser. Its based on v2.0 of the IETF spec. It displays iCal files in a nice logical, clean manner with day, week, month, and year navigation. It is available in 13 languages and includes support for printing, searching and RSS news feeds. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable'), (200, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-686 Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: exim, local resolver, host name lookups and IPv6
On 2008-04-12, Marc Haber <[EMAIL PROTECTED]> wrote: > On Fri, 11 Apr 2008 17:48:19 + (UTC), Robert Edmonds ><[EMAIL PROTECTED]> wrote: >>Yes, there is a much better way: do not perform name resolution to >>determine the host's FQDN. It is wrong. > > This is what exim does to determine the local host name: >|This variable contains the value set by primary_hostname in the >|configuration file, or read by the uname() function. If uname() returns a >|single-component name, Exim calls gethostbyname() (or getipnodebyname() >|where available) in an attempt to acquire a fully qualified host name. See >|also $smtp_active_hostname. > > Is this broken? IMO, yes: the nodename returned by uname() may have nothing to do with information in the DNS. I haven't looked at the exact sequence of calls exim makes, but a common one is: 1) obtain the hostname via uname() or gethostname() 2) obtain the IP address corresponding to this hostname by calling gethostbyname() 3) obtain the "fully qualified" hostname by calling gethostbyaddr() on this IP address This is somewhat damaged especially if the gethost* calls result in DNS lookups for some reason, because the information in DNS could be under a completely separate administrative domain. Another problem is insisting that a "single-component name" isn't fully qualified is wrong, too. E.g., "ai" is a fully-qualified Internet mail domain: [EMAIL PROTECTED]:~$ dig +short mx ai 10 mail.offshore.ai. > But this documentation is kind of incorrect in the first place, since > the lookup I see is caused by a call to gethostbyname_2_, which > is not mentioned int he docs at all. Thankfully, gethostbyname2 is > used in exim's source code only twice (with one of the occurrences > being inside an if( primary_hostname == NULL ) which doesn't apply if > primary_hostname is set in configuration, which is the case if exim is > configured with the minimaldns option. So, the lookup must be > triggered by the gethostbyname2 call in host.c line 1969, which I not > yet have fully understood. Can some more experienced C programmer > comment on this part of the code? > >> The MTA needs to know the >>"mail name" or FQDN of the system, and it may need to know specific IPv4 >>or IPv6 addresses to bind to if it is running an SMTP server, but it >>does not need to know any particular mapping between the two. > > Where can I obtain the FQDN of the system instead? Perhaps by asking the user at installation/configuration time, and storing this information in some sort of file that stores the, erm, "mail name" of the system :) > Don't I need the particular mapping between IP addresses and host > names to generate a proper HELO? But I wouldn't expect these lookups > to be made at startup, but only when an outgoing message is sent. No. >>It looks like there are functions in src/host.c for performing DNS-based >>determination of the system's FQDN. I don't know exactly under which >>circumstances these functions are invoked, but policy 11.6 implies that >>they are superfluous in the presence of the /etc/mailname file. > > /etc/mailname is unfortunately unclearly defined in Policy, and IIRC > the policy editors refused to clarify when asked years ago. The exim 4 > maintainers have then created http://wiki.debian.org/EtcMailName and > asked all MTA maintainers to comment how they use /etc/mailname, but > only a fraction of them bothered to comment. > > Exim 4 only uses /etc/mailname to qualify unqualified recipient > addresses and for some rewriting tricks. This has been the cause of > unspeakable grief in the past so I do prefer to avoid touching this > particular part of the system. > >>I don't see how this issue is analogous to the 127.0.1.1 hack. From >>reading the archived discussion[0], the problem is applications which >>use a sequence of legacy gethostname(), gethostbyname(), etc. calls to >>construct an FQDN, and avoiding accidentally using 'localhost' or >>'localhost.localdomain' as the system hostname. If you're using the >>newer getipnode* functions, it's possible that you'll get an AI_V4MAPPED >>address even when asking for an AF_INET6 address. > > It looks to me that the getipnode* functions are not available in > current Debian based on glibc 2.7. Yes, sorry. I meant the getaddrinfo() function. >>The analogous IPv6 hack, btw, would be something atrocious in /etc/hosts >>like: >> >>:::127.0.1.1 hostname.domainname > > I'll try that. Is there a bug report open where this is being discussed? >>> Any hints will be appreciated. >> >>IME, nullmailer and postfix seem to get along fine without generating >>spurious DNS traffic, so >> >>#include > > So please make postfix the default MTA for lenny and have exim > removed. It obviously sucks as badly as its maintainer. I'm _s_ > sick of that. Actually, I wonder if it's time for the semi-annual "do modern Linux systems need MTAs installed by default" argument. -
Re: Are Sha* checksums accepted by dak ?
Raphael Hertzog debian.org> writes: > Anthony Towns has applied a fix to dak and Format: 1.8 is accepted now. > He also resurrected the uploads which have been rejected due to this check > only. I am seeing my uploads rejected too as of right now. I just got back from a short trip and was trying to fix some bugs. Is a dpkg-dev downgrade the best option? Dirk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Are Sha* checksums accepted by dak ?
On Mon, Apr 14, 2008 at 11:08:41PM +, Dirk Eddelbuettel wrote: > Raphael Hertzog debian.org> writes: > > Anthony Towns has applied a fix to dak and Format: 1.8 is accepted now. > > He also resurrected the uploads which have been rejected due to this check > > only. > > I am seeing my uploads rejected too as of right now. I just got back from a > short trip and was trying to fix some bugs. > > Is a dpkg-dev downgrade the best option? If you're using debsign (from devscripts), then you need also need to upgrade devscripts to 2.10.25 as previous versions didn't handle the newer changes Format properly. Other situations to be careful of are using debrsign (remote debsign must be updated) and building packages in a sid chroot on a non-sid system. Basically, make sure you're aware of which package versions you're actually using. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#476189: ITP: gimp-dds -- DDS (DirectDraw Surface) plugin for the gimp
Package: wnpp Severity: wishlist Owner: Vincent Fourmond <[EMAIL PROTECTED]> * Package name: gimp-dds Version : 2.0.3 Upstream Author : Name <[EMAIL PROTECTED]> * URL : http://nifelheim.dyndns.org/~cocidius/dds/ * License : GPL2+ Programming Lang: C Description : DDS (DirectDraw Surface) plugin for the gimp gimp-dds is a plugin for the gimp that lets you manipulate Microsoft DirectDraw surfaces. These kind of files are widely used in 3D games for textures and the like. [probably should go to the debian-games team] -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) (ignored: LC_ALL set to en_GB) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Moving from console-tools to kbd [was: Bug#476097: kbd: Incorrect LSB init header]
On Mon, Apr 14, 2008 at 06:23:56PM +, Michael Schutte wrote: > As d-i has been brought up: Moving from console-tools to kbd does not > affect the installer; localechooser would need to be changed to install kbd rather than console-tools. > console-tools needs libconsole, which is too large for d-i, so it > already uses kbd-udeb. Are you thinking of console-setup here? Note that d-i still uses kbd-chooser, which has its own cloned-and-hacked implementation of bits of the keyboard utilities. (The most substantial thing we need to do to get console-setup ready is to sort out i18n, I think. I've been hoping to have time to work on this.) -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#476202: ITP: libbio-mage-utils-perl -- Extra modules for classes in the MAGE package: MAGE
Package: wnpp
Severity: wishlist
Owner: Charles Plessy <[EMAIL PROTECTED]>
Package name: libbio-mage-utils-perl
Version : 20030502.0
Upstream Author : The MAGE-Perl Hackers
URL : http://mged.sourceforge.net/
License : MIT/X
Programming Lang: Perl
Description : Extra modules for classes in the MAGE package: MAGE
MAGE-TAB (MicroArray Gene Expression Tabular) format is a standard from the
Microarray Gene Expression Data Society (MGED). This package contains Perl
modules in the Bio::MAGE hierarchy to manipulate MIAME-compliant (Minimum
Information About a Microarray Experiment) records of microarray ("DNA chips")
experiments.
.
Bio-MAGE-Utils contains extra modules for handling MAGE XML and MGED ontology,
as well as SQL utilities.
libbio-mage-utils-perl is needed for the mage2tab programs, that I will
package as well because I am using them at work right now.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Conditional dependency
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wine on amd64 has a problem with bug #430845. If libnss-mdns is installed, Wine won't work properly without lib32nss-mdns, but works if neither is installed. Since I haven't seen any signs of the nss-mdns guys being in a hurry to fix the problem, I wonder if I can do something about it in Wine. Is there a way for Wine to declare a "conditional dependency", where it says if you have libnss-mdns, you also need lib32nss-mdns - or in other words, if you want Wine, you need both installed or both uninstalled. Something like Depends: lib32nss-mdns | !libnss-mdns? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgEIQIACgkQA+GMa4PlEQ9XCACcDjXyJ3T/MUsYAWan2bgpEgIs yScAnjXf9Vj89UGElaFtucW6bU4P6Tts =X8/Q -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#476209: ITP: mage2tab -- MAGE-MLv1 converter and visualiser
Package: wnpp Severity: wishlist Owner: Charles Plessy <[EMAIL PROTECTED]> Package name: mage2tab Version : 0.9 Upstream Author : Junmin Liu ([EMAIL PROTECTED]), John Brestelli ([EMAIL PROTECTED]) URL : https://www.cbil.upenn.edu/magewiki/index.php/mage2tab License : CBIL Software and Data License, Version 1.0 (same as apache license 1.0, see: http://www.cbil.upenn.edu/downloads/RAD/ ) Programming Lang: Perl Description : MAGE-MLv1 converter and visualiser This tool-kit is part of MR_T, a framework for import or export various of MAGE (MicroArray Gene Expression) documents (MAGE-MLv1, MAGE-TAB, SOFT, MINiML) from or into databases like GUS (the Genomics Unified Schema, www.gusdb.org). . This package provides the following programs: mage2tab — MAGE-MLv1 to MAGE-TAB converter mage2graph— GraphViz-based mage data visualisation tool mage-checker — Validation tool In addition to the scripts and a xsl file, it contains perl modules in the RAD::MR_T::MageImport hierarchy. The upstream name of the package is mage2tab. Do I have to name the Debian package librad-mr-t-mageimport-perl, or is mage2tab acceptable ? Have a nice day, -- Charles Plessy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Moving from console-tools to kbd [was: Bug#476097: kbd: Incorrect LSB init header]
Quoting Colin Watson ([EMAIL PROTECTED]): > On Mon, Apr 14, 2008 at 06:23:56PM +, Michael Schutte wrote: > > As d-i has been brought up: Moving from console-tools to kbd does not > > affect the installer; > > localechooser would need to be changed to install kbd rather than > console-tools. > > > console-tools needs libconsole, which is too large for d-i, so it > > already uses kbd-udeb. > > Are you thinking of console-setup here? Note that d-i still uses > kbd-chooser, which has its own cloned-and-hacked implementation of bits > of the keyboard utilities. I should add to this that the most expected benefit of any change in that matter should be to get rid of *two* parallel keymap collections: the one in console-data (that's used, partly, in the installer, then later by either kbd or console-* stuff) and the one in X (that's later used by any user but Joey Schulze..:-)) As console-data maintainer (along with Alastair in theory, but all recent breakages are mine), I would love to see it become useless. This is why I did put a lot of hope in the ideas about dropping it and use console-setup in D-I (and thus later on the system)which unfortunately just remained ideas. As Colin points out, i18n of the keymap choice is currently the major blocker to get c-s used in D-I. Last time I looked at it, it required time and skills...two things I don't really have. Colin has one of those, at least..:-) signature.asc Description: Digital signature
