Re: xinetd is a viable inet-superserver
On Tue, Nov 27, 2007 at 05:42:43PM +, Klaus Ethgen wrote: > Hello, > > Am Di den 27. Nov 2007 um 16:13 schrieb Pierre Habouzit: > > (1) xinetd reads and honours /etc/inetd.conf ; > > As long as this is default switched of this might be ok. No it's on by default, and easy to change in /etc/default/xinetd. But I do believe (and there was an RC open on xinetd for that, and I agree about it) that it being off by default is wrong, because xinetd cannot document it's a proper inet-superserver without doing that. If as an administrator you disagree, you can change that anytime. > > (2) if a service is configured through /etc/xinetd.d/ own > > configuration files _and_ inetd.conf then the former wins, which > > sounds like a reasonable thing. > > And what if a service is intentional _not_ configured for xinetd and the > inetd.conf is ignored? Since xinetd conflicts with inet-superserver it's the sole one that can honour /etc/inetd.conf. The final plan is to let update-inetd work on both the xinetd configuration and /etc/inetd.conf. This way, here are the possible scenarios and administrator can use: (1) only honour /etc/xinetd* files, by disabling compat mode altogether. (2) work in compat mode, with the (probable, I did not checked but it's likely) drawback that a service "disabled" in the /etc/xinetd* and enabled in /etc/inetd.conf will probably be run. There are 2 ways of not falling in the (2) trap: - either always use update-inetd to enable or disable services (once it'll support xinetd configuration files btw) - or me patching xinetd if it behaves like I fear it does to ignore services from /etc/inetd.conf that are filed under the same name than in /etc/xinetd*. I believe it to be the proper approach, I'll try to write a patch asap. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpdEJMBOsgLl.pgp Description: PGP signature
Ùتاب Ù٠٠ا شاÙ٠رج٠Ùا٠٠� �ÙÙ Ùسخ٠ÙزÙجتÙ
= sh44.com = Ùتاب جدÙد Ù٠٠ا شاÙ٠رج٠Ùا٠٠٠Ù٠اخذ Ù ÙÙ Ùسخ٠ÙزÙجت٠http://sh44.com/vb/showthread.php?t=167 === ... FOOTER === http://www.sh44.com/vb Unsubscription : http://alwwn.com/subscription.php?list_id=17&op=leave&email_addr=debian-devel%40lists.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xinetd is a viable inet-superserver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Pierre, Am Mi den 28. Nov 2007 um 9:45 schrieb Pierre Habouzit: > > As long as this is default switched of this might be ok. > > No it's on by default, and easy to change in /etc/default/xinetd. So it is easy switchable. (May there are a debconf question?) > But I do believe (and there was an RC open on xinetd for that, and I > agree about it) that it being off by default is wrong, because xinetd > cannot document it's a proper inet-superserver without doing that. If > as an administrator you disagree, you can change that anytime. Well the problem is that this change the expected and desired way on existing installations. If you are a admin and didn't (want to) care about /etc/inetd.conf and with a update your xinetd will use it silently (and may open big, big security hole in your server) this is a very big issue! (And a security bug I think!) The only solutions would be eider: 1. Implement a debconf question and explain that there is a problem or 2. Switch it of by default for updates and maybe on by default on new installs. > Since xinetd conflicts with inet-superserver it's the sole one that > can honour /etc/inetd.conf. Well, not completely true. There might be more than one understanding. Mine is that providing a inet-superserver provides the _functionality_ of a inet-superserver not the same _config file_. > (1) only honour /etc/xinetd* files, by disabling compat mode > altogether. Would be the best in my understanding. > (2) work in compat mode, with the (probable, I did not checked but it's > likely) drawback that a service "disabled" in the /etc/xinetd* and > enabled in /etc/inetd.conf will probably be run. Disabled can also mean that the respective file is not created or deleted. > There are 2 ways of not falling in the (2) trap: > - either always use update-inetd to enable or disable services (once > it'll support xinetd configuration files btw) Only if it provides the full functionality of xinetd (like ie. only allow specified ip range or only few connection at once). > - or me patching xinetd if it behaves like I fear it does to ignore > services from /etc/inetd.conf that are filed under the same name > than in /etc/xinetd*. I believe it to be the proper approach, I'll > try to write a patch asap. Why using the name of the service? In inetd.conf the name has to be the same than the port in /etc/services (and even some service might have multiple names). In xinetd the name can be any if you specify the service port in the config. So why not using the port to decide if the service is enabled or not? Regards Klaus Ethgen - -- Klaus Ethgenhttp://www.ethgen.de/ pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <[EMAIL PROTECTED]> Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBR00xmZ+OKpjRpO3lAQLGXwf9HtZwVqWrWuEEPGAVZoWxksc0hQWLMWF+ c1AGgzYCNw/0Nx0DbLIf8gXbdCVBmjblFWgQAEGqBvpMAA5ccvj+u3U+OWF3jFA3 Ru5LkwuwfdoF6KEh0BwDd1jOsABcps1altX41zPkAX/kHMjU3nx2XwdO+UKc7POs sUTJl8LgCf7XxQGIjoa8SrU6WNqaHV3JwKsoPg+PQ+9ithkTLgQVYiVz4hFHv1sK PjoyU8BtwLdY13qvuYieD9ZhgUfKkq++ADWQIX360gwEb/42biH6c5LlXVg/p6Bb qvYB3GEii+gyTq7gHFV5Hxz8eeN6FZgc6q3Gz4mzc4O5rXuLPag4yg== =0VQF -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems with double-word alignment on hppa and sparc
* Uwe Steinmann <[EMAIL PROTECTED]> [071127 14:02]: > I need some help with #94 since I'm neither an ocaml nor a > hppa, sparc specialist. The package orpie ships with its own > gsl ocaml bindings and they cannot be compiled on hppa and sparc > due to an alignment problem. I contacted upstream of orpie and > got the following answer: > > > I've looked into this a bit, and I'm not sure it can be fixed very > easily. The OCaml bindings for libgsl avoid some expensive copy > operations by making the assumption that the platform can accept double > arrays aligned on word boundaries. Apparently hppa and sparc don't > provide this capability. > Uh, what are meant by word binaries? If word is 32bit, then this is false. If word means (not so absurd as it might sound as first, the 8086 had that as word size, so it sticks in some people's mind) is 16bit then this is indeed true. (And I am quite supprised that it only fails on hppa and sparc, I'd have guessed it to fail on almost anything but i386. (perhaps some other architectures only print warnings to syslog instead of punishing it directly with a sigbus)). What you can, even on sparc, is having 32 or even 64 bit quantities aligned to 16 bit in packed structs (and perhaps arrays). But you have to make sure you are not triggering undefined behaviour (which means sigbus here) by giving away pointer to unaligned data, nor forget that even an packages struct as a whole has an enforced alignment. (so having an struct with something on an +2 offset and and pointer to that struct which is not 0(mod 4) may mean the data is aliged but the compiler think it is misaligned and you get a buserror). Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages with httpd needs
It looks like thttpd works okay with php[45]-cgi, provided that all of the .php files have the appropriate #!/usr/bin/php[45]-cgi set On Nov 27, 2007 10:57 AM, Leo costela Antunes <[EMAIL PROTECTED]> wrote: > Hans-J. Ullrich wrote: > > Well, I wondered, whenever an application needs a http-demon (for > example > > phpgroupware, egroupware, prelude and many others), all packages force > to > > install apache. There is no way, to get rid of this. As we say "Small is > > beautifull" or "KISS = Keep it simple stupid" , IMO there is no need, to > > install mighty apache ! A simple http demon (I prefer thttpd) would do > the > > same but would be more secure. > > THTTPD doesn't (AFAIK) support PHP, so the applications you mentioned > can't be use with it. > > Thanks for the interest in helping out, but please file bugs to specific > packages when you are certain they could use a suggestion such as yours. > > I don't dismiss your suggestion completely, but bear in mind that given > the number of people and packages in debian, a non-specific email to > debian-devel is hardly likely to generate any sort of positive outcome. > > Cheers > > -- > Leo "costela" Antunes > [insert a witty retort here] > > -- moo.
Re: xinetd is a viable inet-superserver
On Wed, Nov 28, 2007 at 09:15:05AM +, Klaus Ethgen wrote: > Hi Pierre, > > Am Mi den 28. Nov 2007 um 9:45 schrieb Pierre Habouzit: > > > As long as this is default switched of this might be ok. > > > > No it's on by default, and easy to change in /etc/default/xinetd. > > So it is easy switchable. Yes. > (May there are a debconf question?) No I won't use debconf here, because it's definitely the most viable way to use xinetd nowadays. Though the next upload will document that fact completely in the README.Debian > > But I do believe (and there was an RC open on xinetd for that, and I > > agree about it) that it being off by default is wrong, because xinetd > > cannot document it's a proper inet-superserver without doing that. If > > as an administrator you disagree, you can change that anytime. > > Well the problem is that this change the expected and desired way on > existing installations. If you are a admin and didn't (want to) care > about /etc/inetd.conf and with a update your xinetd will use it silently > (and may open big, big security hole in your server) this is a very big > issue! (And a security bug I think!) It won't do that because new defaults /etc/inetd.conf are empty. And it's documented in NEWS.Debian properly, which administrators are supposed to read. apt-listchanges does that for you. > The only solutions would be eider: > 1. Implement a debconf question and explain that there is a problem or I don't want to use debconf. It's an overkill. Though I may force the setting to "No" instead of "Yes" if upgrading from an existing install. That's safer indeed. Will do that. > 2. Switch it of by default for updates and maybe on by default on new >installs. > > Since xinetd conflicts with inet-superserver it's the sole one that > > can honour /etc/inetd.conf. > > Well, not completely true. There might be more than one understanding. > Mine is that providing a inet-superserver provides the _functionality_ > of a inet-superserver not the same _config file_. wrong. providing inet-superserver means that you are able to perform what any implementation of inetd(8) does, namely, reading /etc/inetd.conf, and _then_ possibly have extended features on its own. > > (1) only honour /etc/xinetd* files, by disabling compat mode > > altogether. > > Would be the best in my understanding. You can do that, it's up to you as an administrator. > > (2) work in compat mode, with the (probable, I did not checked but it's > > likely) drawback that a service "disabled" in the /etc/xinetd* and > > enabled in /etc/inetd.conf will probably be run. > > Disabled can also mean that the respective file is not created or > deleted. Too bad. Note that given that xinetd proposes the handly "disabled = yes" configuration option, that's unwise. > > There are 2 ways of not falling in the (2) trap: > > - either always use update-inetd to enable or disable services (once > > it'll support xinetd configuration files btw) > > Only if it provides the full functionality of xinetd (like ie. only > allow specified ip range or only few connection at once). Gni ? I don't understand what you're talking about. > > - or me patching xinetd if it behaves like I fear it does to ignore > > services from /etc/inetd.conf that are filed under the same name > > than in /etc/xinetd*. I believe it to be the proper approach, I'll > > try to write a patch asap. > > Why using the name of the service? In inetd.conf the name has to be the > same than the port in /etc/services (and even some service might have > multiple names). In xinetd the name can be any if you specify the > service port in the config. So why not using the port to decide if the > service is enabled or not? because the duplicated configuration in stock /etc/inetd.conf _and_ /etc/xinetd.c/* configuration will come from packages that want to support both, and then the service name will be the same. I don't expect administrators to be dumb enough to configure mutual exclusive services in their /etc/inetd.conf _and_ xinetd.conf. Or if they do, then I'm sure they already have plenty of rope and I don't mind giving them some more. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp4mX6hG96VE.pgp Description: PGP signature
Re: dpkg-substvars
Magnus Holmgren wrote:
> If I'm not mistaken, there is no standard way of getting the value of just a
> single arbitrary substitution variable, such as ${source:Upstream-Version}.
> Consequently, countless of debian/rules and other scripts reinvent the wheel
> using dpkg-parsechangelog together with slightly varying sed programs, which
> sometimes give an incorrect result.
>
> So I thought that it might be a good idea to implement a general-case
> dpkg-substvars. Turns out somebody already did that - seven years ago.
> However, http://bugs.debian.org/66336 was tagged wontfix, probably because it
> tried to make it possible to use substitution variables in package names.
>
> But if we forget about variable package names, wouldn't dpkg-substvars be a
> good idea?
It would be a good idea *with* variable package names.
http://www.hogyros.de/?q=node/173
It would also save me a fair bit of work in emdebian-tools where I'm
always querying the source package name and various other components of
the parsechangelog output.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
signature.asc
Description: OpenPGP digital signature
Re: xinetd is a viable inet-superserver
On Wed, Nov 28, 2007 at 11:51:07AM +0100, Pierre Habouzit wrote: > > Well, not completely true. There might be more than one understanding. > > Mine is that providing a inet-superserver provides the _functionality_ > > of a inet-superserver not the same _config file_. > wrong. providing inet-superserver means that you are able to perform > what any implementation of inetd(8) does, namely, reading > /etc/inetd.conf, and _then_ possibly have extended features on its own. Where is that documented? Watching the progression of inetd packages in Debian has been dizzying, I don't have the sense that there's any sort of central plan that everyone's following. This virtual package's semantics certainly aren't documented in policy. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xinetd is a viable inet-superserver
On Wed, Nov 28, 2007 at 11:08:27AM +, Steve Langasek wrote: > On Wed, Nov 28, 2007 at 11:51:07AM +0100, Pierre Habouzit wrote: > > > Well, not completely true. There might be more than one understanding. > > > Mine is that providing a inet-superserver provides the _functionality_ > > > of a inet-superserver not the same _config file_. > > > wrong. providing inet-superserver means that you are able to perform > > what any implementation of inetd(8) does, namely, reading > > /etc/inetd.conf, and _then_ possibly have extended features on its own. > > Where is that documented? Watching the progression of inetd packages in > Debian has been dizzying, I don't have the sense that there's any sort of > central plan that everyone's following. This virtual package's semantics > certainly aren't documented in policy. Well I'd say that it's what common sense would expect[0], and with the -4 I just uploaded, the "issues" about -inetd_compat are discussed in NEWS.Debian, README.Debian and the changelog. And upgrading xinetd from a previous version won't activate it by default (with the except of -3 sorry for them). I believe this is the best way to handle the transition: statu quo for "old" users, new behavior for new ones. [0] the reasoning is: this is clear to me that through update-inetd that is the debian way to enable inet-like services, something that claims to be an inet-superserver must react on update-inetd triggered changes. update-inetd atm only acts on /etc/inetd.conf, so as a consequences I believe it's necessary for an inet-superserver provider to grok /etc/inetd.conf. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpziVHgfNNe2.pgp Description: PGP signature
Re: xinetd is a viable inet-superserver
Pierre Habouzit schrieb: > On Wed, Nov 28, 2007 at 09:15:05AM +, Klaus Ethgen wrote: > >>> Since xinetd conflicts with inet-superserver it's the sole one that >>> can honour /etc/inetd.conf. >> Well, not completely true. There might be more than one understanding. >> Mine is that providing a inet-superserver provides the _functionality_ >> of a inet-superserver not the same _config file_. > > wrong. providing inet-superserver means that you are able to perform > what any implementation of inetd(8) does, namely, reading > /etc/inetd.conf, and _then_ possibly have extended features on its own. > I don't think this reasoning is correct. Take the existing implementations of system-log-daemon/linux-kernel-log-daemon, like rsyslog, syslog-ng or metalog. All use a different config file than /etc/syslog.conf. 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
Bug#453290: ITP: timelimit -- Simple utility to limit a process's absolute execution time
Package: wnpp Severity: wishlist Owner: Peter Pentchev <[EMAIL PROTECTED]> * Package name: timelimit Version : 1.0 Upstream Author : Peter Pentchev <[EMAIL PROTECTED]> * URL : http://devel.ringlet.net/sysutils/timelimit/ * License : Two-clause BSD Programming Lang: C Description : Simple utility to limit a process's absolute execution time The timelimit utility executes a command and terminates the spawned process after a given time with a given signal. A "warning" signal is sent first, then, after a timeout, a "kill" signal, similar to the way init(8) operates on shutdown. Actually, I already have a pretty much ready package for the timelimit utility which may only need minor fixes: dget -x http://devel.ringlet.net/sysutils/timelimit/debian/timelimit_1.0-1.dsc -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-amd64 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#451799: new evince cannot display Japanese characters correctly
> However I don't think there is anything copyrightable in these files; > they only contain series of numbers that describe the mappings. Do you > people think it could be suitable for main? > (Please follow-up on -legal only for licensing discussions.) > > Ondrej, are you willing - if the legal problems are settled out - to > package it? Otherwise I guess me or any of the co-maintainers could do > it, the packaging is absolutely trivial. It's already packaged in pkg-freedesktop SVN, but it was rejected by ftp-masters due licensing problems. Ondrej. -- Ondřej Surý <[EMAIL PROTECTED]> *** http://blog.rfc1925.org/ Kulturní občasník *** http://www.obcasnik.cz/ Nehoupat, prosím *** http://nehoupat.blogspot.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages with httpd needs
Steve Langasek wrote: > On Tue, Nov 27, 2007 at 07:57:44PM +0100, Leo costela Antunes wrote: >> THTTPD doesn't (AFAIK) support PHP > > Does THTTPD not support CGI or FastCGI? > Oops, you're right. But would the apps run "out of the box" with php-cgi? If so, then yes, these bugs could be filed in the appropriate packages. (even if not, probably related wishlist bugs could also be filed, asking for CGI compat) Cheers -- Leo "costela" Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Bug#453301: ITP: gpe-login -- login window for the G Palmtop Environment
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: gpe-login Version: 0.90 Upstream Author: Philip Blundell <[EMAIL PROTECTED]> URL: http://gpe.linuxtogo.org/download/source/ License: GPL2 Description: login window for the G Palmtop Environment Multi user login and session manager for GPE. Depends on gpe-ownerinfo-dev also being packaged. Replaces packages like gdm, xdm, kdm on GPE. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpzrrwaJ4oWO.pgp Description: PGP signature
Bug#453300: ITP: gpe-ownerinfo -- access the device owner information in GPE
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: gpe-ownerinfo Version: 0.28 Upstream Author: Colin Marquardt <[EMAIL PROTECTED]> Florian Boor <[EMAIL PROTECTED]> URL: http://gpe.linuxtogo.org/download/source/ License: GPL2 Description: details of the GPE device owner Used by the G Palmtop Environment (GPE). Also builds: gpe-ownerinfo-dev Description: access the device owner information Contains a static library used by gpe-login to display details of the owner of the device . Used by the G Palmtop Environment (GPE). -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpBUdOpKvdZl.pgp Description: PGP signature
console login : number of access failures
Hi lists, 1- by default on our Debian system after a successful login through a tty we are presented with the number of failures (unsuccesful logins) that took place before using the same login name.For a non root user this number is correct. But what about the root user ? That number is "correct" unless no one tried to do "su logins" (login using the command su). Do you think that su-logins must be considered as "general logins" and then the super user must know how many unsuccessful "su-logins" took place ? And what about the date and time of the last root login ? :-) Well, as a solution one could forbid the "su-login" but sometimes that command can be useful. 2 - by default whenever I press CTRL-D to log out as a non root user the screen is cleaned ... whenever I press CTRL-D to log out as a root user the screen is not cleaned - and maybe a non root user can see what the root did before ! Why did they choose this behavior ?? thank you for your attention, I appreciate suggestions and opinions ;) saluti, daniele p.s. copy of this message has been sent also to debian-laptop list -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xinetd is a viable inet-superserver
On 28-Nov-07, 05:25 (CST), Michael Biebl <[EMAIL PROTECTED]> wrote: > Pierre Habouzit schrieb: > > wrong. providing inet-superserver means that you are able to perform > > what any implementation of inetd(8) does, namely, reading > > /etc/inetd.conf, and _then_ possibly have extended features on its own. > > > > I don't think this reasoning is correct. Take the existing > implementations of system-log-daemon/linux-kernel-log-daemon, like > rsyslog, syslog-ng or metalog. All use a different config file than > /etc/syslog.conf. The difference is that other packages don't manipulate log file configuration. 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: xinetd is a viable inet-superserver
On Nov 28, Steve Langasek <[EMAIL PROTECTED]> wrote: > On Wed, Nov 28, 2007 at 11:51:07AM +0100, Pierre Habouzit wrote: > > wrong. providing inet-superserver means that you are able to perform > > what any implementation of inetd(8) does, namely, reading > > /etc/inetd.conf, and _then_ possibly have extended features on its own. No, not really. Providing inet-superserver means that a package supports the /usr/sbin/update-inetd API. > Where is that documented? Watching the progression of inetd packages in > Debian has been dizzying, I don't have the sense that there's any sort of > central plan that everyone's following. This virtual package's semantics I made one a long time ago, but people keep ignoring it. -- ciao, Marco signature.asc Description: Digital signature
Re: xinetd is a viable inet-superserver
Steve Greenland schrieb: > On 28-Nov-07, 05:25 (CST), Michael Biebl <[EMAIL PROTECTED]> wrote: >> Pierre Habouzit schrieb: >>> wrong. providing inet-superserver means that you are able to perform >>> what any implementation of inetd(8) does, namely, reading >>> /etc/inetd.conf, and _then_ possibly have extended features on its own. >>> >> I don't think this reasoning is correct. Take the existing >> implementations of system-log-daemon/linux-kernel-log-daemon, like >> rsyslog, syslog-ng or metalog. All use a different config file than >> /etc/syslog.conf. > > The difference is that other packages don't manipulate log file > configuration. > Well, packages shouldn't manipulate the inetd.conf file directly anyway but use the update-inetd interface. 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: xinetd is a viable inet-superserver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Am Mi den 28. Nov 2007 um 11:51 schrieb Pierre Habouzit: > > (May there are a debconf question?) > > No I won't use debconf here, because it's definitely the most viable > way to use xinetd nowadays. Though the next upload will document that > fact completely in the README.Debian [...] > I don't want to use debconf. It's an overkill. Pardon? debconf overkill? This is right the correct place for it as it change the basic way the package work completely. > > > Since xinetd conflicts with inet-superserver it's the sole one that > > > can honour /etc/inetd.conf. > > > > Well, not completely true. There might be more than one understanding. > > Mine is that providing a inet-superserver provides the _functionality_ > > of a inet-superserver not the same _config file_. > > wrong. providing inet-superserver means that you are able to perform > what any implementation of inetd(8) does, namely, reading > /etc/inetd.conf, and _then_ possibly have extended features on its own. There we have completely other understanding of. xinetd is a replacement (with its own configuration). Using the inetd.conf you have no benefit of using the plain old one. The compat mode is only good for migration. > > Disabled can also mean that the respective file is not created or > > deleted. > > Too bad. Note that given that xinetd proposes the handly "disabled = > yes" configuration option, that's unwise. Why? I know the option. But a deleted (or truncated to zero size) file is more clear than a option inside. > > Only if it provides the full functionality of xinetd (like ie. only > > allow specified ip range or only few connection at once). > > Gni ? I don't understand what you're talking about. See manpage options only_from or instances or log_on_* for example. > because the duplicated configuration in stock /etc/inetd.conf _and_ > /etc/xinetd.c/* configuration will come from packages that want to > support both, and then the service name will be the same. Untrue. If I look for my configuration, around 50% of the xinetd services are handmade. > I don't expect administrators to be dumb enough to configure mutual > exclusive services in their /etc/inetd.conf _and_ xinetd.conf. Well, just to think about a (fictive) common one, admins might start with inetd and /etc/inetd.conf and configure there stuff. Then after years they decide switching to xinetd to have a more granularly way to control there services. They ignore the old inetd.conf and configure all services in xinetd. Sometimes later they decide to switch of a service (by deleting the file as they don't need it anymore). But it is still running as xinetd uses the entry in inetd.conf. A horror thought! Am Mi den 28. Nov 2007 um 12:34 schrieb Pierre Habouzit: > And upgrading xinetd from a previous version won't activate it by > default (with the except of -3 sorry for them). I believe this is the > best way to handle the transition: statu quo for "old" users, new > behavior for new ones. True. > [0] the reasoning is: this is clear to me that through update-inetd > that is the debian way to enable inet-like services, something > that claims to be an inet-superserver must react on update-inetd > triggered changes. update-inetd atm only acts on /etc/inetd.conf, > so as a consequences I believe it's necessary for an > inet-superserver provider to grok /etc/inetd.conf. Well, it might be clear for you but I install xinetd to get away from this crap of the old inetd config. So for me the idea that xinetd might use /etc/inetd.conf is a horror! (Well I controll it after each update now but what about other who see that the same than I?) Regards Klaus Ethgen - -- Klaus Ethgenhttp://www.ethgen.de/ pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <[EMAIL PROTECTED]> Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBR028JZ+OKpjRpO3lAQLrjAf7B6erOuJ+yKJdaCvdwlQqC9LSz8XuhLsj P4KoPy8M+FpswpdyaIVdhqAnavs7TY4228eFhT8MDtK5r2f4zQYKUwZhCxunNFNk HyOg7Sz2uml8ZH+Erjv0nTBvGckh56xaReGlXFvNewEMIH+Xf+T0NatNOFUY61Ek BeH1BJyumFyhFFkrSnpqchHLV+FHc3AYI3Fq6YcYz2aOsh+nxZ3dEewHi+o18btj K9r7QdqaZBZ/ebChXdntE8UNdncWC/tKpyjti9ksggmp0LykvbCLpJ9sGH11gRLw mYosNbLuYkfBhQzfUNmqMiX4S1JY1hiL8/0OnYVnkAuJwevqtkPUMA== =B9iW -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mass bugs filing: bogus debian/watch files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everybody, Yesterday, after fixing some bugs on DEHS (I'm now part of the team), I ran the script that performs all the checks. That means there's new, fresh, information regarding the watch files so I'd like to report the new watch files failing to report upstream's version. I've already reopened some bug reports which were not really fixed. Some highlights regarding the recent changes made to improve the prevention/detection of false positives: On DEHS side: latest uscan is now used, preventing those silly reports about an unsupported protocol being used, i.e. https. On the reporting script side: 'cpan.org' was added as a keyword to the filter so no further reports will be sent because of bogus/failing CPAN mirrors. This time the number of watch files to be reported is 88, reason why I'm posting to the list. I hope there won't be any objection and that nobody disagrees on me making an other, probably mass (depends on the watch files, not me :), bug filling in the future. On the generated email messages I'm now also suggesting the maintainer to set the 'help' tag on the bug report if they can't figure out how to fix it. This is so next time I review the list of bugs for need of patches I pay more attention to those reports. Kind regards, Raphael Geissert -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHTNcEYy49rUbZzloRAqDXAJ9aV1+iZxbk5vb1ckxOAZMg/qgiFQCbBLmU 9SZ+yj12Af7ED7rKKPSHCk0= =RLPv -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xinetd is a viable inet-superserver
On Wed, Nov 28, 2007 at 07:01:13PM +, Michael Biebl wrote: > Steve Greenland schrieb: > > On 28-Nov-07, 05:25 (CST), Michael Biebl <[EMAIL PROTECTED]> wrote: > >> Pierre Habouzit schrieb: > >>> wrong. providing inet-superserver means that you are able to perform > >>> what any implementation of inetd(8) does, namely, reading > >>> /etc/inetd.conf, and _then_ possibly have extended features on its own. > >>> > >> I don't think this reasoning is correct. Take the existing > >> implementations of system-log-daemon/linux-kernel-log-daemon, like > >> rsyslog, syslog-ng or metalog. All use a different config file than > >> /etc/syslog.conf. > > > > The difference is that other packages don't manipulate log file > > configuration. > > > > Well, packages shouldn't manipulate the inetd.conf file directly anyway > but use the update-inetd interface. I'd be glad if you provide a patch to let it modify xinetd configurations. Until that, I'll let the inetd compat mode enabled by default, with a trivial way to remove it for the admin. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpGCps8ZPQ7S.pgp Description: PGP signature
Re: xinetd is a viable inet-superserver
On Wed, Nov 28, 2007 at 07:06:13PM +, Klaus Ethgen wrote: > Am Mi den 28. Nov 2007 um 11:51 schrieb Pierre Habouzit: > Pardon? debconf overkill? This is right the correct place for it as it > change the basic way the package work completely. Debconf can be used if there isn't a sane default. > > wrong. providing inet-superserver means that you are able to perform > > what any implementation of inetd(8) does, namely, reading > > /etc/inetd.conf, and _then_ possibly have extended features on its own. > > There we have completely other understanding of. xinetd is a replacement > (with its own configuration). Using the inetd.conf you have no benefit > of using the plain old one. The compat mode is only good for migration. and to allow the auto-configuration debian is supposed to give for inetd-powered services. > > > Disabled can also mean that the respective file is not created or > > > deleted. > > > > Too bad. Note that given that xinetd proposes the handly "disabled = > > yes" configuration option, that's unwise. > > Why? I know the option. But a deleted (or truncated to zero size) file > is more clear than a option inside. your call. > > > > Only if it provides the full functionality of xinetd (like ie. only > > > allow specified ip range or only few connection at once). > > > > Gni ? I don't understand what you're talking about. > > See manpage options only_from or instances or log_on_* for example. I still don't understand how it's relevant to -inetd_compat. > > because the duplicated configuration in stock /etc/inetd.conf _and_ > > /etc/xinetd.c/* configuration will come from packages that want to > > support both, and then the service name will be the same. > > Untrue. If I look for my configuration, around 50% of the xinetd > services are handmade. oh and there are services with the same name in /etc/inetd.conf ? I bet that not. I try to make the packager life simple with this one. Nothing more. I still don't understand why you're fighting here. I don't force you to also write an /etc/inetd.conf right ? > > I don't expect administrators to be dumb enough to configure mutual > > exclusive services in their /etc/inetd.conf _and_ xinetd.conf. > > Well, just to think about a (fictive) common one, admins might start > with inetd and /etc/inetd.conf and configure there stuff. Then after > years they decide switching to xinetd to have a more granularly way to > control there services. They ignore the old inetd.conf and configure all > services in xinetd. Sometimes later they decide to switch of a service > (by deleting the file as they don't need it anymore). But it is still > running as xinetd uses the entry in inetd.conf. A horror thought! Admins are supposed to read the documentation about the package they install, and if they believe it's a dangerous thing, they can change the default in /etc/default/xinetd once for all. > Am Mi den 28. Nov 2007 um 12:34 schrieb Pierre Habouzit: > > And upgrading xinetd from a previous version won't activate it by > > default (with the except of -3 sorry for them). I believe this is the > > best way to handle the transition: statu quo for "old" users, new > > behavior for new ones. > > True. > > > [0] the reasoning is: this is clear to me that through update-inetd > > that is the debian way to enable inet-like services, something > > that claims to be an inet-superserver must react on update-inetd > > triggered changes. update-inetd atm only acts on /etc/inetd.conf, > > so as a consequences I believe it's necessary for an > > inet-superserver provider to grok /etc/inetd.conf. > > Well, it might be clear for you but I install xinetd to get away from > this crap of the old inetd config. So for me the idea that xinetd might > use /etc/inetd.conf is a horror! (Well I controll it after each update > now but what about other who see that the same than I?) I grow tired of that argument, why should I sacrifice Debian auto-configurability for the 99% of the users that use xinetd extensions for some of the services only ? Again, just edit your /etc/default/xinetd. It's a conffile, it won't be overwritten behind your back, give me a break. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp8v7Rka3zKy.pgp Description: PGP signature
Bug#453334: general: apt and aptitude stop work
Package: general
Severity: important
apt-get or aptitude stop work when i uninstall a linux image and
/boot/grub/menu.lst was deleted.
Installer should create automatically a new menu.lst file, but when it's time
to do it, process stop.
watch the console output:
BEGIN
[EMAIL PROTECTED]:~$ sudo aptitude purge linux-image-2.6.18-5-686
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done
Reading task descriptions... Done
Building tag database... Done
The following packages will be automatically REMOVED:
linux-image-2.6.18-5-686{p}
The following packages will be REMOVED:
linux-image-2.6.18-5-686{p}
0 packages upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
Need to get 0B of archives. After unpacking 48.0MB will be freed.
Do you want to continue? [Y/n/?]
Writing extended state information... Done
(Reading database ... 141661 files and directories currently installed.)
Removing linux-image-2.6.18-5-686 ...
Running postrm hook script /sbin/update-grub.
Searching for GRUB installation directory ... found: /boot/grub
Searching for default file ... found: /boot/grub/default
Testing for an existing GRUB menu.lst file ...
Could not find /boot/grub/menu.lst file. Would you like /boot/grub/menu.lst
generated for you? (y/N) y
END
Just after i answer 'y' (yes) nothing more happens, i have to kill the process.
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.22-3-686 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: severity of 453334 is normal
Processing commands for [EMAIL PROTECTED]: > # Automatically generated email from bts, devscripts version 2.10.10 > severity 453334 normal Bug#453334: general: apt and aptitude stop work Severity set to `normal' from `important' > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Contents-source.gz
On Tue, Nov 27, 2007 at 10:38:51PM +0100, Bernd Zeimetz wrote: > So what? Space is cheap these days. Contrary to popular belief, space will never become free. -- Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
E-Ticketing your Events
To Whom It May Concern, This is Dan Gargano - Owner/CEO of www.ticketmuncher.com. I just wanted to give you, promoters, and event planners a heads up that we are now offering a free consulting service to help you sell tickets to your events. Basically, as a company with over 3,000 clients (all being event promoters) we have seen it all, and we know what works, and what doesn't. Bottom line is, if your holding event, tickets need to be sold in order for you to maintain your bottom line. If you would like free advice feel free to send an e-mail to [EMAIL PROTECTED] Be sure to include information on the type of event you are planning, what types of people you would like to have attend, what you are currently doing to advertise your event, and how you plan to push ticket sales. We do not charge our clients for our advance ticketing service, and it is in our best interest to help you push your eventbecause in the end, we don't make money unless you do. Ticketmuncher.com's FREE service offers an advanced system of e-ticketing, sales reports, bar coding, credit card processing, ticket scanners, kiosks, and more. If you are in the PROCESS of planning an event, TELL US! We may be able to help. We have worked with all kinds of event planners all over the country, and can definately help you give your tickets the bump they deserve. Nothing feels better than logging in to www.ticketmuncher.com and seeing your ticket sales have skyrocketed! Feel free to go to ticketmuncher.com and register under the "Sell Tickets" section, check out the system and poke around at it a little. The website offers a self-serve system that can get your event tickets on sale in a matter of minutes. If you would like to discuss capabilities outside of what the self-serve system has to offer, send me an email. Our staff, and myself, are also available for private consultations (at a VERY minimal rate) should you want to go above and beyond with your event. Feel free to contact me with any questions, Dan Gargano | Owner/CEO | www.ticketmuncher.com | [EMAIL PROTECTED] | 973-796-6029 You are subscribed as [EMAIL PROTECTED] To unsubscribe please click here: http://cmpgnr.com/r.html?c=1108805&r=1107867&t=1218918141&l=6&[EMAIL PROTECTED]&la=1&o=-75. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xinetd is a viable inet-superserver
On Wed, Nov 28, 2007 at 08:06:13PM +0100, Klaus Ethgen wrote: > Am Mi den 28. Nov 2007 um 11:51 schrieb Pierre Habouzit: > > > (May there are a debconf question?) > > No I won't use debconf here, because it's definitely the most viable > > way to use xinetd nowadays. Though the next upload will document that > > fact completely in the README.Debian > [...] > > I don't want to use debconf. It's an overkill. > Pardon? debconf overkill? This is right the correct place for it as it > change the basic way the package work completely. There are three principal cases in which debconf is useful: - you have a setting to configure for which there is no reasonable default - you have a setting to configure that it's useful to allow preseeding for on initial install - you have an error message to display *conditionally* on upgrade. I don't think any of these apply to xinetd. Debconf should not be used as a substitute for either NEWS.Debian or for doing the hard work of figuring out the correct reasonable default. Doing so wastes translators' time and users' disk space. > There we have completely other understanding of. xinetd is a replacement > (with its own configuration). Using the inetd.conf you have no benefit > of using the plain old one. The compat mode is only good for migration. Well, no, the other benefit is that you actually get integration with update-inetd, which is how packages declare themselves to the inet-superserver. But I'm not overly happy with this implementation, xinetd ought to be providing its own update-inetd script instead. But even in that case, there would be an upgrade issue on account of the fact that pre-existing entries in /etc/inetd.conf corresponding to packages that have previously called update-inetd would not be handled automatically upon installation of xinetd; or that they would at best suddenly become active when those packages are upgraded, rather than when xinetd is upgraded. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RC buggy package migrated to testing
On Nov 24, 2007 11:05 PM, Steve Langasek <[EMAIL PROTECTED]> wrote: > On Sat, Nov 24, 2007 at 05:52:31PM -0700, Shaun Jackman wrote: > > azureus has a RC bug filed against it, #449176. Why did it migrate to > > testing? > > Because there's no version information on bug #449176, so britney concludes > that both the old and new versions of the package are equally buggy. That does not seem like a very safe default behaviour. When a new RC bug has been submitted, it's a rather likely situation that the bug is present in unstable and wasn't present before. Cheers, Shaun -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RC buggy package migrated to testing
"Shaun Jackman" <[EMAIL PROTECTED]> writes: > On Nov 24, 2007 11:05 PM, Steve Langasek <[EMAIL PROTECTED]> wrote: > > Because there's no version information on bug #449176, so britney > > concludes that both the old and new versions of the package are > > equally buggy. > > That does not seem like a very safe default behaviour. When a new RC > bug has been submitted, it's a rather likely situation that the bug is > present in unstable and wasn't present before. I don't see how you get the "and wasn't present before" part of that. Surely this is exactly what version tagging is for? -- \ "I was married by a judge. I should have asked for a jury." -- | `\ Groucho Marx | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RC buggy package migrated to testing
On Nov 29, 2007 9:48 AM, Ben Finney <[EMAIL PROTECTED]> wrote: > > That does not seem like a very safe default behaviour. When a new RC > > bug has been submitted, it's a rather likely situation that the bug is > > present in unstable and wasn't present before. > > I don't see how you get the "and wasn't present before" part of that. > Surely this is exactly what version tagging is for? Only way would be to map dates to versions. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RC buggy package migrated to testing
On Wed, Nov 28, 2007 at 04:49:31PM -0700, Shaun Jackman wrote: > That does not seem like a very safe default behaviour. When a new RC > bug has been submitted, it's a rather likely situation that the bug is > present in unstable and wasn't present before. That's why you use reportbug, so the version information gets right. :-) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RC buggy package migrated to testing
[Please preserve attribution lines on quoted material, so we can see who said what in your message.] "Paul Wise" <[EMAIL PROTECTED]> writes: > On Nov 29, 2007 9:48 AM, Ben Finney <[EMAIL PROTECTED]> wrote: > > > > That does not seem like a very safe default behaviour. When a > > > new RC bug has been submitted, it's a rather likely situation > > > that the bug is present in unstable and wasn't present before. > > > > I don't see how you get the "and wasn't present before" part of > > that. Surely this is exactly what version tagging is for? > > Only way would be to map dates to versions. Not the "only way"; the BTS already has the ability for the user to *explicitly state* which version of the package has the bug. -- \ "Our products just aren't engineered for security." —Brian | `\ Valentine, senior vice-president of Microsoft Windows | _o__)development, 2002 | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xinetd is a viable inet-superserver
On Wed, Nov 28, 2007 at 12:34:47PM +0100, Pierre Habouzit wrote: > [0] the reasoning is: this is clear to me that through update-inetd > that is the debian way to enable inet-like services, something > that claims to be an inet-superserver must react on update-inetd > triggered changes. update-inetd atm only acts on /etc/inetd.conf, > so as a consequences I believe it's necessary for an > inet-superserver provider to grok /etc/inetd.conf. This is at odds with many years of discussion on this mailing list, where the consensus was that xinetd should have its own update-inetd that supports the xinetd config format natively. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RC buggy package migrated to testing
On Nov 29, 2007 10:11 AM, Ben Finney <[EMAIL PROTECTED]> wrote: > > > I don't see how you get the "and wasn't present before" part of > > > that. Surely this is exactly what version tagging is for? > > > > Only way would be to map dates to versions. > > Not the "only way"; the BTS already has the ability for the user to > *explicitly state* which version of the package has the bug. You seem to have misinterpreted what I meant, perhaps I wasn't clear enough: In the absence of version tags, the only way to infer the "and wasn't present before" part would be to map timestamps (of bugs and uploads) to versions (of bugs and uploads). -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RC buggy package migrated to testing
On Wed, Nov 28, 2007 at 04:49:31PM -0700, Shaun Jackman wrote: > On Nov 24, 2007 11:05 PM, Steve Langasek <[EMAIL PROTECTED]> wrote: > > On Sat, Nov 24, 2007 at 05:52:31PM -0700, Shaun Jackman wrote: > > > azureus has a RC bug filed against it, #449176. Why did it migrate to > > > testing? > > Because there's no version information on bug #449176, so britney concludes > > that both the old and new versions of the package are equally buggy. > That does not seem like a very safe default behaviour. When a new RC > bug has been submitted, it's a rather likely situation that the bug is > present in unstable and wasn't present before. The vast majority of bug submitters use tools that document the version number of the package they're reporting the bug against. The current BTS semantics with regard to bug versioning have been widely discussed and are in place for well over a year. I suggest you update your expectations regarding the meaning of a bug report with no version information and no suite tags... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RC buggy package migrated to testing
On Thu, 29 Nov 2007, Paul Wise wrote: > In the absence of version tags, the only way to infer the "and > wasn't present before" part would be to map timestamps (of bugs and > uploads) to versions (of bugs and uploads). Though the BTS actually has that information available (and uses it to handle archiving) the huristics of figuring out whether a user is reporting a bug against a version in testing which has recently been uploaded or merely recently been upgraded or the version in unstable which has recently been uploaded or merely recently upgraded to the version in stable which has recently been uploaded or ugpraded to or the version in any of the architectures which has just been installed or a version which has no relationship to the versions we distribute at all but the user happens to have installed you clearly must be a massochist to have read this sentence to this point continue on to the next paragraph already. So yeah, kind of not possible to do in a reasonable fashion without ESP (and if you've got that working, I know of many bugs that could use it first.) [I imagine we're probably in violent agreement here.] Don Armstrong -- We cast this message into the cosmos. [...] We are trying to survive our time so we may live into yours. We hope some day, having solved the problems we face, to join a community of Galactic Civilizations. This record represents our hope and our determination and our goodwill in a vast and awesome universe. -- Jimmy Carter on the Voyager Golden Record http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
So Cal Linux Expo Calls For Papers close Friday!
The Calls for Paper for the So Cal Linux Expo, and its Friday special sessions, Women in Open Source, Demonstrating Open Source Software Health Care Solutions, and Open Source Software in Education, close Friday 11/30. If you're contemplating submitting a paper for any of these session, don't delay - there are only a few speaker slots left. -- Gareth J. Greenaway <[EMAIL PROTECTED]> Voice - 877-831-2569 x130 Southern California Linux Expo http://www.socallinuxexpo.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
pfmon build
It has been months since pfmon 3.2.070507-1 was uploaded. What happened to its build? Why is it not built on i386 yet? -- Seo Sanghyeon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mass bugs filing: bogus debian/watch files
Quoting Raphael Geissert ([EMAIL PROTECTED]): > This time the number of watch files to be reported is 88, reason why I'm > posting to the list. > I hope there won't be any objection and that nobody disagrees on me making > an other, probably mass (depends on the watch files, not me :), bug filling > in the future. Let's be active: I fully support this initiative and, from this thread, you made all the required efforts to take care of doing your "mass" bug report, so I would say in short: go for it! signature.asc Description: Digital signature
