Re: [RFC] How should rsyslog handle .0 logfiles from sysklogd
Hi, 2008/9/19 Michael Biebl <[EMAIL PROTECTED]>: > rsyslog, in contrast to sysklogd, uses logrotate to rotate the default > log files. Unfortunately sysklogd uses a custom log rotate mechanism, > which starts the log rotate cycle at .0 > The default logrotate configuration starts the log rotate cyle at .1. ah, cool. :-) > This leaves .0 files around when you switch from sysklogd to rsyslog [2] > which will never be rotated. > > Afaics I have the following options. > 1.) Do nothing and simply document this fact in README.Debian, telling > the admin that he can safely delete this files if he no longer needs them. Hm. Thats probably a safe way. It does not include acting on files which are in the interest of the local admin without asking him first. Unfortunately it also means that the admin probably never pays attention for the logfile (and that he needs to know, which syslog is installed, so where to find the README.Debian but I guess we can assume that...). I'm a bit uneasy about that last thing, but general this is a valid approach. > 2.) Try to log rotate the .0 files for the default Debian log files in > postinst. I feel a bit uneasy about this approach, for several reasons: What does this mean, excatly? You try to log rotate like it would be normally done by logrotate? Hm. Probably what the user would expect, but I guess that way is over-complex. > 3.) Delete the .0 files in postinst. Is this covered by the policy? Not without a backup or asking the user first. You could ask the user via debconf. I think this is a case, which would justify it. > 4.) Use start 0 in /etc/logrotate.d/rsyslog, which would retain old > sysklogd behaviour. This would mean, that it would still be incompatible > with all other syslog alternatives [2] besides old sysklogd. That's why > I'd keep the logrotate standard configuration. Bad idea, IMHO. Best Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] How should rsyslog handle .0 logfiles from sysklogd
Michael Biebl <[EMAIL PROTECTED]> wrote: [...] > Unfortunately sysklogd uses a custom log rotate mechanism, > which starts the log rotate cycle at .0 > The default logrotate configuration starts the log rotate cyle at .1. > This leaves .0 files around when you switch from sysklogd to rsyslog [2] > which will never be rotated. [...] > 2.) Try to log rotate the .0 files for the default Debian log files in > postinst. I feel a bit uneasy about this approach, for several reasons: > - It adds fairly reasonable complexity to the maintainer scripts, if you > want to consider all corner cases. > E.g. if you switch from syslog-ng to rsyslog, it is very likely that you > have old .0 files lying around (from a sysklogd->syslog-ng switch), so > syslog.1 would be older than syslog.2 which would be very confusing. [...] I do not think it is that critical to work around the (same) bug in other syslog implementations. cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] How should rsyslog handle .0 logfiles from sysklogd
Patrick Schönfeld <[EMAIL PROTECTED]> wrote: > 2008/9/19 Michael Biebl <[EMAIL PROTECTED]>: [...] >> 3.) Delete the .0 files in postinst. Is this covered by the policy? > Not without a backup or asking the user first. You could ask the user > via debconf. I think this is a case, which would justify it. [...] I disagree that asking is a valid option. The right thing to do is to keep the latest n files, asking before deleting the second newest one does not make it the right thing. cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] How should rsyslog handle .0 logfiles from sysklogd
On Fri,19.Sep.08, 23:57:54, Michael Biebl wrote: > Afaics I have the following options. > 1.) Do nothing and simply document this fact in README.Debian, telling > the admin that he can safely delete this files if he no longer needs them. I would have rather suggested NEWS.Debian if apt-listchanges was higher priority. Anyway, this should also be documented in the release notes. After reading this I went on cleaning my /var/log/ and found some recent .0 files (I switched to rsyslog in July): $ ls -la /var/log/*.0 -rw-r- 1 root adm 51123 2008-09-19 22:09 /var/log/dmesg.0 -rw-r--r-- 1 root root 46714 2008-09-13 06:25 /var/log/popularity-contest.0 Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Re: [RFC] How should rsyslog handle .0 logfiles from sysklogd
Andrei Popescu wrote: > On Fri,19.Sep.08, 23:57:54, Michael Biebl wrote: > >> Afaics I have the following options. >> 1.) Do nothing and simply document this fact in README.Debian, telling >> the admin that he can safely delete this files if he no longer needs them. > > I would have rather suggested NEWS.Debian if apt-listchanges was higher > priority. Anyway, this should also be documented in the release notes. Agreed, mentioning this issue in the release notes would probably be a good idea in this case. > After reading this I went on cleaning my /var/log/ and found some recent > .0 files (I switched to rsyslog in July): I forgot to mention this in 2.). The .0 files will also be outdated if you have already switched to rsyslog (as user of testing or unstable), i.e. .1 will be newer than .0. What to do in this case? Rotating .0 imho would do more harm than good. 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: [RFC] How should rsyslog handle .0 logfiles from sysklogd
On 2008-09-20 11:14 +0200, Michael Biebl wrote: > Andrei Popescu wrote: >> I would have rather suggested NEWS.Debian if apt-listchanges was higher >> priority. Anyway, this should also be documented in the release notes. > > Agreed, mentioning this issue in the release notes would probably be a > good idea in this case. And they do not need to describe the issue in detail, just having a pointer to your (supposed) README.Debian is enough. >> After reading this I went on cleaning my /var/log/ and found some recent >> .0 files (I switched to rsyslog in July): > > I forgot to mention this in 2.). The .0 files will also be outdated if > you have already switched to rsyslog (as user of testing or unstable), > i.e. .1 will be newer than .0. > What to do in this case? Rotating .0 imho would do more harm than good. I think this pretty much rules 2.) out. Sven, who wishes that savelog and logrotate would agree on using .0 or .1 files. Had to hunt down /var/log/*.0 and examine which files there actually belong to sysklogd. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Can i Trust You? Call me if yes +226 78 03 96 12
I have a new email address!You can now email me at: [EMAIL PROTECTED] I am Ahmed DIALLO, a staf of Bank Of Africa I want to transfer US$14 Million to your account. - Ahmed Diallo
Re: Headsup: ncurses soname bump 5 to 6
On mar, 2008-09-16 at 21:21 +0200, Daniel Baumann wrote: > just a quick note: after lenny, ncurses will bump soname major from 5 > to > 6 in order to make mouse wheels work. The transition will be big, but > can be entirely handled with binNMUs only and this is what this mail > is > about: btw, wrt to that issue, and with LSB in head, it could be worth to synchronize with other distros, and see what they think about this. I guess using [EMAIL PROTECTED] for that would be a good idea. Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: Xen status in lenny?
On Thu, Sep 18, 2008 at 05:43:24PM +0200, Bastian Blank wrote: > This kernel have a critical problem: > > | Bad pte = 11764060, process = vsftpd, vm_flags = 100071, vaddr = b7f85000 > | Pid: 8129, comm: vsftpd Not tainted 2.6.26-1-xen-686 #1 > | [] handle_mm_fault+0x61b/0xe78 > | [] mprotect_fixup+0x6d3/0x735 > | [] do_page_fault+0x684/0xbd6 > | [] sys_mprotect+0x17a/0x1df > | [] sys_mprotect+0x1cc/0x1df > | [] do_page_fault+0x0/0xbd6 > | [] error_code+0x35/0x3c > | === > | VM: killing process vsftpd > > The pte have bit 6 set: PAGE_DIRTY aka PAGE_FILE. But the vm flags lacks > the marker for a nonlinear (file based) mapping. Got a response from Novell, including a workaround. Next try: http://194.39.182.225/debian/xen/try4. | a01d76fa67414fd157c7f50be89525cc1f03dace linux-headers-2.6.26-1-xen-686_2.6.26-6_i386.deb | 6ed1653d3f8f68026803529bee10dec9e772f706 linux-headers-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb | 7d70566bda9719b9e4c1c310150da76768019d9c linux-image-2.6.26-1-xen-686_2.6.26-6_i386.deb | 19e1a1d2f2dc085ac38968246fcb0e375c9cd14c linux-image-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb | e09de4e292cd7f00fc98689ddec3ad7712ec47e1 linux-modules-2.6.26-1-xen-686_2.6.26-6_i386.deb | 9af0b3015f8d0ea433d06cf2fe9d0055697be485 linux-modules-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb | cafb31d7ef45b26b23f1e3c30b0785b4bfc2cd4d xen-linux-system-2.6.26-1-xen-686_2.6.26-6_i386.deb | 250d7f2a59603e9203840f465a00dd0e990103d1 xen-linux-system-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb Bastian -- You! What PLANET is this! -- McCoy, "The City on the Edge of Forever", stardate 3134.0 signature.asc Description: Digital signature
Bug#195481: marked as done (Centralized configuration for location settings?)
Your message dated Sat, 20 Sep 2008 12:29:39 +0200 with message-id <[EMAIL PROTECTED]> and subject line upstream issue, not packaging related has caused the Debian Bug report #195481, regarding Centralized configuration for location settings? to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [EMAIL PROTECTED] immediately.) -- 195481: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=195481 Debian Bug Tracking System Contact [EMAIL PROTECTED] with problems --- Begin Message --- Package: general Severity: wishlist I'm not sure where to assign this, but ... there are too many packages in Debian that ask for your location or variants thereof, all in an uncoordinated fashion. To whit: time zone latitude/longitude (wmmoonclock, wmsun, various mapping programs) nearest ICAO station (wmweather) paper size a4 vs letter (papersize library, and a couple stragglers) language (locale, and a couple stragglers) country (something must request this I'll bet) altitude (again I bet something uses this) Right now, this stuff is easy to get inconsistent, and each one requires effort to figure out. Some of them are even tricky to change, or even to remember. It would be nice if these would *ALL* assume default values given just one, on both a global system-wide basis and over-ridable on a per-user and per-session basis. In other words, when I move my laptop I should be able to put in the new lat/long and, assuming everything else is set up to default, all these other things should be filled in with their most probably values. Eg the nearest ICAO station, the most popular language in the location I'm in, the size of paper they use there, etc. Similarly, if I fill in just a country and it is a small country, and I haven't filled in lat/long or anything else, everything should snap to reasonable values. If that's not enough to figure out eg the time zone, at least the timezone menu should start with a list of timezones in that country. If I fill in a lat/long outside that country, it should give me a warning. If I fill in a city it should take the lat/long in the center of that city. If some user fills in a different country & city, blam everything should "just work" for that user. I think this could be accomplished with appropriate debconf stuff and a "location-related-query" executable that looks at global info, per-user files in their home directory, and environment variables. Or maybe a library, for easier retrofitting into little programs. With some modular architecture so one can add new location-related values which can be derived from lat/long/alt, and which therefore if filled in can also be used to constrain this and therefore other derivable values. --- End Message --- --- Begin Message --- Hi, I'm closing this bug because basically it's too broad (it belongs into many packages) and also because these are upstream issues, nothing Debian can or should really do about this. It's a nice idea, but IMO nothing more than that at the moment. And it's an idea which should be dealt with upstream. regards, Holger pgpjsbTrfdlFd.pgp Description: PGP signature --- End Message ---
Re: [RFC] How should rsyslog handle .0 logfiles from sysklogd
On Sat, 2008-09-20 at 12:01:57 +0300, Andrei Popescu wrote: > On Fri,19.Sep.08, 23:57:54, Michael Biebl wrote: > > Afaics I have the following options. > > 1.) Do nothing and simply document this fact in README.Debian, telling > > the admin that he can safely delete this files if he no longer needs them. > > I would have rather suggested NEWS.Debian if apt-listchanges was higher > priority. Anyway, this should also be documented in the release notes. > > After reading this I went on cleaning my /var/log/ and found some recent > .0 files (I switched to rsyslog in July): > > $ ls -la /var/log/*.0 > -rw-r- 1 root adm 51123 2008-09-19 22:09 /var/log/dmesg.0 > -rw-r--r-- 1 root root 46714 2008-09-13 06:25 /var/log/popularity-contest.0 Those two are not obsolete, as they are being rotated by savelog, either by a cronjob or a boot script, the same applies for other .0 log files. So this would have to be documented as well to avoid users removing valid files. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#460504: marked as done (dh_desktop/dh_icons madness)
Your message dated Sat, 20 Sep 2008 12:39:57 +0200 with message-id <[EMAIL PROTECTED]> and subject line not a bug has caused the Debian Bug report #460504, regarding dh_desktop/dh_icons madness to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [EMAIL PROTECTED] immediately.) -- 460504: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460504 Debian Bug Tracking System Contact [EMAIL PROTECTED] with problems --- Begin Message --- Package: general Severity: normal For a while now some folks have been going around asking various package maintainers to inject dh_icons and/or dh_desktop calls into the package build rules. The basic argument appears to be that your package needs to do this so that my desktop environment will work correctly. I don't think this approach has correct and sustainable principles. And what is more, if some random third packages or user environments dictate what other, unrelated packages have to do to function with them, we will in practice never reach a state where everything works. Furthermore, if other desktop environments come up with their own variants of icon caching of MIME file registration (since these are supposedly Free Desktop standards) or perhaps completely new file registration requirements, we will have an unmaintainable mess of competing implementations of registration scripts, and thousands of packages stuck in a transition somewhere between all of them. It seems to me that, in principle, if some third package or user environment wants something to be done for its own functional benefit, it should be its own responsibility to arrange that, instead of bothering thousands of other packages with it. This appears to be the only robust and maintainable approach. On a technical level, the best approach would appear to be implementing some sort of global dpkg postinst and postrm hooks. Perhaps there are other ideas, but the current approach needs to stop; it won't work. --- End Message --- --- Begin Message --- Hi, as explained in the bug report, this is not a bug, but a feature (we want .desktop files and icons), thus closing. regards, Holger pgphW8TpTXtW5.pgp Description: PGP signature --- End Message ---
Bug#499606: ITP: tika -- a Java library for extracting textual information from various documents
Package: wnpp Severity: wishlist Owner: "Jan-Pascal van Best" <[EMAIL PROTECTED]> * Package name: tika Version : 0.2-SNAPSHOT Upstream Author : Jukka Zitting <[EMAIL PROTECTED]> and others * URL : http://incubator.apache.org/tika/ * License : Apache 2.0 Programming Lang: Java Description : a Java library for extracting textual information from various documents Apache Tika is a toolkit for detecting and extracting metadata and structured text content from various documents using existing parser libraries. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (400, 'unstable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] How should rsyslog handle .0 logfiles from sysklogd
On Sat, Sep 20, 2008 at 01:20:06AM +0300, Faidon Liambotis wrote: > Michael Biebl wrote: > > 3.) Delete the .0 files in postinst. Is this covered by the policy? > I think that deleting logfiles without warning is totally unacceptable. Outside of purge at least. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: nut package freeze exception request (dependency based boot)
On Thu, Sep 18, 2008 at 11:19:15PM +1000, Kel Modderman wrote: > Is the link just there to be a "virtual/persistent" link to whatever service > which is installed and provides the functionality? > Inspection of the nut package leads me to believe this may be the case, so > I wrote a patch for insserv which ignores any symlink in /etc/init.d/ which > points to another script in /etc/init.d/, as I am not aware of any cases where As for ups-monitor that yes, it's the case. As for symlinks I only heared about debian-edu earlier in this thread: > Petter Reinhold: >> 2) Changhe insserv to not count symlinks at all (do not know about >> possible affects about it) >This will break debian-edu (which symlink in a script used for the >first boot after installation, and remove it after the boot). I am >not sure about other effects. But I guess it's realted to ignoring symlinks at all. Can you fill a bug to push this patch to unstable? Thanks. -- Anton Martchukov http://www.martchukov.com 0xFC4FBF28 96BC 3DAB 231A 7FCC 4F49 D783 9A69 65C1 FC4F BF28 signature.asc Description: Digital signature
Re: nut package freeze exception request (dependency based boot)
On Thu, Sep 18, 2008 at 04:23:34PM +0200, Petter Reinholdtsen wrote: > Why is the symlink provided? Where is the definition of the > ups-monitor virtual package written down? What is using this symlink? > I assume a good solution should take into account the answers to these > questions. :) I am not a maintainer, but it looks like this is just to have a common name for any ups-monitor package. As you have found halt uses it to power off the ups without knowledge about which specififc ups daemon is installed. > Is it the only user? If so, perhaps the patch from Kel is the best > way to fix it. It should be ok, whenever we have one init.d linking to itself we have two scripts providing the same facility that is incorrect for insserv. If insserv will check such situation I do not see how it might be harmful. Another idea came to my mind, why can't we use alternatives for init.d scripts? -- Anton Martchukov http://www.martchukov.com 0xFC4FBF28 96BC 3DAB 231A 7FCC 4F49 D783 9A69 65C1 FC4F BF28 signature.asc Description: Digital signature
Re: DELAYED queue and upload hostname
On Sat, Sep 20, 2008 at 06:30:55PM +0200, Joerg Jaspert wrote: > ftp.upload.debian.org > - > To untie the upload queue from the archive DSA setup an alias to be used > for future uploads. Please change your configuration of dput, dupload or > whatever you use to no longer use ftp-master.debian.org but > ftp.upload.debian.org instead. Are default configurations for dput, etc. planned to be changed before Lenny? (this also applies to DELAYED queue, actually) Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DELAYED queue and upload hostname
On Sat, Sep 20, 2008 at 18:30:55 +0200, Joerg Jaspert wrote: > - the DELAYED queue is back on ftp-master > Some questions: 1) I use Tollef's DELAYED queue mostly for 0-day because it's accessible over ssh, so I can rsync files over which is more reliable than ftp on a bad link. It sounds like you're removing the possibility to use that (I know I can rsync files to some debian host and ftp from there, but that's more manual work). 2) Will files in DELAYED be readable? It's occasionally useful to inspect uploads there before they reach the archive, like if somebody forgot to send his nmu diff to the bts. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Headsup: ncurses soname bump 5 to 6
On Thu, 18 Sep 2008 23:03:25 +0200 Julien Cristau <[EMAIL PROTECTED]> wrote: > On Thu, Sep 18, 2008 at 13:40:14 -0700, Dan Kegel wrote: > > > On Thu, Sep 18, 2008 at 1:12 PM, Thomas Dickey <[EMAIL PROTECTED]> wrote: > > >> from the upstream POV, this would be another ABI transition. > > > > > > If there's no patch, there's nothing to discuss, then. > > > > Going forward, though, can you avoid potential issues like this > > by maintaining better ABI compatibility between versions? > > i.e. when you add a libncurses.so.7, can you make it so > > that all apps that linked against libncurses.so.6 still continue > > to work without recompilation? > > This doesn't make any sense. If all apps linked against the previous > version continued to work without recompilation, it wouldn't be an > incompatible ABI change, and so wouldn't require a SONAME bump. Take a different example - a library that retains all symbols during the current SONAME, migrating some into a "deprecated" section/file and adding new ones as bug fixes. When those deprecated symbols are finally removed, a SONAME bump is required. (This is the case for qof, glib2.0 and gtk2.0 use deprecated symbols too.) The symbols are versioned so that reverse dependencies can depend on the correct version. The library can support compile-time --no-deprecated option to ./configure so that all reverse dependencies can be tested upstream against the new ABI *before* the modified version of the library is released upstream. Those reverse dependencies then make a release before the next library upstream release, including whatever changes are necessary to work with the library when built with --no-deprecated, even though --no-deprecated is not enabled by default. Technically, the reverse dependencies are now ABI compatible across both versions - with and without the deprecated symbols. That cannot mean that the library itself can drop those deprecated symbols upstream without changing the SONAME. So the first upstream release of the library with all the deprecated symbols removed (not just disabled) needs to bump the SONAME, as does the Debian package. Just because all the reverse dependencies in Debian have migrated successfully, does not mean that upstream do not have to make a SONAME bump. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpZD41Nddyyu.pgp Description: PGP signature
Re: DELAYED queue and upload hostname
On 11514 March 1977, Mike Hommey wrote: >> To untie the upload queue from the archive DSA setup an alias to be used >> for future uploads. Please change your configuration of dput, dupload or >> whatever you use to no longer use ftp-master.debian.org but >> ftp.upload.debian.org instead. > Are default configurations for dput, etc. planned to be changed before > Lenny? (this also applies to DELAYED queue, actually) I know that at least dput will get this uploaded soon, guess dupload too. Getting it into lenny is a decision the release team has to do. I guess if the changes are otherwise small they will be in favor for it, but thats up to them. -- bye, Joerg [...] when an Idea and a developer get laid, code awakes to the world, then a Debian package is made and pulled in the unstable distribution[...] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DELAYED queue and upload hostname
On 11514 March 1977, Julien Cristau wrote: > 1) I use Tollef's DELAYED queue mostly for 0-day because it's accessible > over ssh, so I can rsync files over which is more reliable than ftp on a > bad link. It sounds like you're removing the possibility to use that (I > know I can rsync files to some debian host and ftp from there, but > that's more manual work). Yes, the way via .d.o hosts it is. > 2) Will files in DELAYED be readable? It's occasionally useful to > inspect uploads there before they reach the archive, like if somebody > forgot to send his nmu diff to the bts. Thomas plans to provide a similar overview as we have for NEW packages. We could enable that to have links to the files itself. Only problem is - if someone goes and uploads a NEW package there it would get us in trouble, as we would distribute it before it got its inspection if we really can do that. So if that ever happens it needs some extra code to look if its valid to give links or not. -- bye, Joerg I'm kinky and perverse, but my illness is laziness -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#195481: closed by Holger Levsen <[EMAIL PROTECTED]> (upstream issue, not packaging related)
What makes Debian a "distribution" rather than just a random collection of miscellaneous software is integration. This is an integration wishlist. It has to happen at the distribution level if it is to happen anywhere. I don't understand why you want to close this issue---the logic seems to be just that it's hard to address, but that doesn't seem like a very compelling reason. And I don't see how it can be filed against any (or many) particular packages---it is an issue that requires policy and coordination between many packages, and hence belongs on Package: general. --Barak. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: nut package freeze exception request (dependency based boot)
On Sunday 21 September 2008 01:12:34 Anton Martchukov wrote: > On Thu, Sep 18, 2008 at 11:19:15PM +1000, Kel Modderman wrote: > > Is the link just there to be a "virtual/persistent" link to whatever service > > which is installed and provides the functionality? > > Inspection of the nut package leads me to believe this may be the case, so > > I wrote a patch for insserv which ignores any symlink in /etc/init.d/ which > > points to another script in /etc/init.d/, as I am not aware of any cases > > where > > As for ups-monitor that yes, it's the case. I looked at a couple of the packages you identified and this was also the case. The nut package should reinstate the symlink then, and new insserv uploaded with modification to handle /etc/init.d/symlink -> script case. > As for symlinks > I only heared about debian-edu earlier in this thread: > > > Petter Reinhold: > >> 2) Changhe insserv to not count symlinks at all (do not know about > >> possible affects about it) > >This will break debian-edu (which symlink in a script used for the > >first boot after installation, and remove it after the boot). I am > >not sure about other effects. > > But I guess it's realted to ignoring symlinks at all. Yeah, the patch committed would ignore symlinks to a relative path which contain no path separator, which can only be scripts in the same dir that insserv is reading scripts from (/etc/init.d/). > > Can you fill a bug to push this patch to unstable? #485045 Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DELAYED queue and upload hostname
Joerg Jaspert wrote: > Only problem is - if someone goes and uploads a NEW package there it > would get us in trouble, as we would distribute it before it got its > inspection if we really can do that. So if that ever happens it needs > some extra code to look if its valid to give links or not. Well, and anyone can upload anything to his ~/public_html and have Debian servers distribute it. As long as it's not distributed as part of the official archive, I think we should be mostly OK. Not that I would disagree with having those extra checks, I'm just saying that we shouldn't overreact with this, IMHO. Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Xen status in lenny?
Bastian Blank wrote: > Got a response from Novell, including a workaround. > > Next try: http://194.39.182.225/debian/xen/try4. > > Hi Bastian, great stuff! Do you have any idea where I might get the package linux-headers-2.6.26-1-common-xen for amd64 needed by your provided package linux-headers-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb Or is there another way to build modules like drbd8 for this kernel ..? WR, Bruno signature.asc Description: OpenPGP digital signature
Re: DELAYED queue and upload hostname
On 11514 March 1977, Faidon Liambotis wrote: > Joerg Jaspert wrote: >> Only problem is - if someone goes and uploads a NEW package there it >> would get us in trouble, as we would distribute it before it got its >> inspection if we really can do that. So if that ever happens it needs >> some extra code to look if its valid to give links or not. > Well, and anyone can upload anything to his ~/public_html and have > Debian servers distribute it. > As long as it's not distributed as part of the official archive, I think > we should be mostly OK. *NO* we aren't. > Not that I would disagree with having those extra checks, I'm just > saying that we shouldn't overreact with this, IMHO. If you go and export unregistered crypto foo from debian.org systems it will get you into trouble, at least with Debian. -- bye, Joerg Contrary to common belief, Arch:i386 is *not* the same as Arch: any. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#499635: ITP: libgigi -- GUI library for OpenGL
Package: wnpp Severity: wishlist Owner: Ansgar Burchardt <[EMAIL PROTECTED]> * Package name: libgigi Version : 0.7.0 Upstream Author : T. Zachary Laine <[EMAIL PROTECTED]> * URL : http://gigi.sourceforge.net/ * License : LGPL-2.1+ Programming Lang: C++ Description : GUI library for OpenGL GiGi (aka GG) is a multi-platform GUI library for OpenGL. Its goals are * platform-independence * driver-independence * easy extensibility: new controls should be easy to incorporate * complete graphical control * independence of UI elements from source code * simplicity of use GiGi is a dependency of FreeOrion which I intend to package later (no ITP yet, #384270 is an old one). Ansgar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFC: update-rc.d
Hi all, This email describes an extension of update-rc.d to provide an interface for disabling and reenabling initscript sysvinit runlevel start links. It contains a patch that is the last in a series[0] of patches submitted to the sysvinit team. After speaking with Petter Reinholdtsen on irc he suggested sending the idea to a wider audience for review and discusion. Another proposed update-rc.d extension[1] is worth a mention too, though it is not described in detail by this communication. It is a proposal for a method providing an interface for maintainer scripts to facilitate change of runlevel scheme on package upgrades. Please have a comment and identify what you think is good and crap. [0] http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2008-September/002861.html [1] http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2008-September/002865.html --- DISABLING OR REENABLING INIT SCRIPT LINKS When run with the disable [ S|2|3|4|5 ] options, update-rc.d modifies existing runlevel links for the script /etc/init.d/name by renaming start links to stop links with a sequence number equal to the difference of 100 minus the orignal sequence number. When run with the reenable [ S|2|3|4|5 ] options, update-rc.d modifies existing runlevel links for the script /etc/init.d/name by renaming stop links to start links with a sequence number equal to the positive difference of current sequence number minus 100, thus returning to the original sequence number that the script had been installed with before disabling it. Both of these options only operate on start runlevel links of S, 2, 3, 4 or 5. If no start runlevel is specified after the disable or enable keywords, the script will attempt to modify links in all start runlevels. Below is an excerpt from a test suite script which shows the intended interface in action. At the very bottom of this email exists the patch (it depends on the other patches in the aforementioned series). --- update-rc.d hotkey-setup start 85 2 3 4 5 . stop 20 1 . Adding system startup links for /etc/init.d/hotkey-setup ... /etc/rc1.d/K20hotkey-setup -> ../init.d/hotkey-setup /etc/rc2.d/S85hotkey-setup -> ../init.d/hotkey-setup /etc/rc3.d/S85hotkey-setup -> ../init.d/hotkey-setup /etc/rc4.d/S85hotkey-setup -> ../init.d/hotkey-setup /etc/rc5.d/S85hotkey-setup -> ../init.d/hotkey-setup --- / `-- etc/ |-- init.d/ | `-- hotkey-setup |-- rc0.d/ |-- rc1.d/ | `-- K20hotkey-setup -> ../init.d/hotkey-setup |-- rc2.d/ | `-- S85hotkey-setup -> ../init.d/hotkey-setup |-- rc3.d/ | `-- S85hotkey-setup -> ../init.d/hotkey-setup |-- rc4.d/ | `-- S85hotkey-setup -> ../init.d/hotkey-setup |-- rc5.d/ | `-- S85hotkey-setup -> ../init.d/hotkey-setup |-- rc6.d/ `-- rcS.d/ --- update-rc.d hotkey-setup disable Disabling system startup links for /etc/init.d/hotkey-setup ... Removing any system startup links for /etc/init.d/hotkey-setup ... /etc/rc1.d/K20hotkey-setup /etc/rc2.d/S85hotkey-setup /etc/rc3.d/S85hotkey-setup /etc/rc4.d/S85hotkey-setup /etc/rc5.d/S85hotkey-setup Adding system startup links for /etc/init.d/hotkey-setup ... /etc/rc1.d/K20hotkey-setup -> ../init.d/hotkey-setup /etc/rc2.d/K15hotkey-setup -> ../init.d/hotkey-setup /etc/rc3.d/K15hotkey-setup -> ../init.d/hotkey-setup /etc/rc4.d/K15hotkey-setup -> ../init.d/hotkey-setup /etc/rc5.d/K15hotkey-setup -> ../init.d/hotkey-setup --- update-rc.d hotkey-setup reenable Re-enabling system startup links for /etc/init.d/hotkey-setup ... Removing any system startup links for /etc/init.d/hotkey-setup ... /etc/rc1.d/K20hotkey-setup /etc/rc2.d/K15hotkey-setup /etc/rc3.d/K15hotkey-setup /etc/rc4.d/K15hotkey-setup /etc/rc5.d/K15hotkey-setup Adding system startup links for /etc/init.d/hotkey-setup ... /etc/rc1.d/K20hotkey-setup -> ../init.d/hotkey-setup /etc/rc2.d/S85hotkey-setup -> ../init.d/hotkey-setup /etc/rc3.d/S85hotkey-setup -> ../init.d/hotkey-setup /etc/rc4.d/S85hotkey-setup -> ../init.d/hotkey-setup /etc/rc5.d/S85hotkey-setup -> ../init.d/hotkey-setup --- update-rc.d hotkey-setup disable 2 3 4 Disabling system startup links for /etc/init.d/hotkey-setup ... Removing any system startup links for /etc/init.d/hotkey-setup ... /etc/rc1.d/K20hotkey-setup /etc/rc2.d/S85hotkey-setup /etc/rc3.d/S85hotkey-setup /etc/rc4.d/S85hotkey-setup /etc/rc5.d/S85hotkey-setup Adding system startup links for /etc/init.d/hotkey-setup ... /etc/rc1.d/K20hotkey-setup -> ../init.d/hotkey-setup /etc/rc2.d/K15hotkey-setup -> ../init.d/hotkey-setup /etc/rc3.d/K15hotkey-setup -> ../init.d/hotkey-setup /etc/rc4.d/K15hotkey-setup -> ../init.d/hotkey-setup /etc/rc5.d/S85hotkey-setup -> ../init.d/hotkey-setup --- update-rc.d hotkey-setup reenable 3 4 Re-enabling system startup links for /etc/init.d/hotkey-setup ... Removing any system startup links for /etc/init.d/hotk
Re: Bug#195481: closed by Holger Levsen <[EMAIL PROTECTED]> (upstream issue, not packaging related)
Hi Barak, On Saturday 20 September 2008 21:09, Barak A. Pearlmutter wrote: > What makes Debian a "distribution" rather than just a random > collection of miscellaneous software is integration. This is an > integration wishlist. It has to happen at the distribution level if > it is to happen anywhere. I don't understand why you want to close > this issue---the logic seems to be just that it's hard to address, but > that doesn't seem like a very compelling reason. And I don't see how > it can be filed against any (or many) particular packages---it is an > issue that requires policy and coordination between many packages, and > hence belongs on Package: general. As said, feel free to reopen. And, as usual.., are you willing to work on this goal? Also IMO it's not really about integration (yet). First, some general plan and then an implementation needs to be found, maybe within freedesktop.org, maybe not. Then, packages would need to be changed to implement this plan. And then a mass bug filing could be done, if there is consensus on debian-devel@ that this should be done. In the bug report I read no consensus _and_ no activity since 5 years. But, as said, feel free to reopen. regards, Holger pgpC1cmwQsRdr.pgp Description: PGP signature
Re: What should be on a rescue CD ? (was Re: Debian Live Lenny Beta1)
Hello Ian, Is "Midnight Commander" on the Rescue-CD? I have gotten (from the net) some Rescue-CDs laking "mc" which I use daily on any of my systems... > What hex editor(s) should it have ? How important is it to have > python, tcl, ruby or other scripting languages ? Which ONE version > of Emacs ? Both nvi _and_ elvis ? mc/mcedit including its syntax highlighting Thanks, Greetings and nice Day/Evening Michelle Konzack Systemadministrator 24V Electronic Engineer Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 +49/177/935194750, rue de Soultz MSN LinuxMichi +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: What should be on a rescue CD ? (was Re: Debian Live Lenny Beta1)
Am 2008-08-28 14:41:38, schrieb Mark Allums: > Consider something akin to pico/nano as well. Something very small and > lightweight and easy to use. Something for the "near misses" in the > experience department: someone who is able to install and run Debian > (mostly) but still is a bit green/"wet behind the ears" when it comes to > something like a rescue. This is, WHY I prefer "Midnight Commander" since it is a FileManager, Viewer and Editor including syntax highlighting and of course, easy to use. Thanks, Greetings and nice Day/Evening Michelle Konzack Systemadministrator 24V Electronic Engineer Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 +49/177/935194750, rue de Soultz MSN LinuxMichi +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Bug#497304: general: packages cannot be partially installed
Am 2008-08-31 19:08:49, schrieb Mark Hobley: > eg: coreutils depends on coreutils-fileutils and > coreutils-fileutils depends on coreutils-fileutils-head, > coreutils-fileutils-split This would leed into over 200.000 Binary packages... > It is policy that internationalized (non-english) components are > packaged separately to the core package. For example, a package foobar, > would have its french documentation in a separate foobar-fr package. > > Packages should not install cruft on the system. This means that a > package should not install a foreign language file, unless the system > has been explicitly configured to support that foreign language. Hmmm, how many languages do we have? If each package is only translated into 10 languages, your wish will lead into over 15.000 additional packages. Thanks, Greetings and nice Day/Evening Michelle Konzack Systemadministrator 24V Electronic Engineer Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 +49/177/935194750, rue de Soultz MSN LinuxMichi +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Bug#497304: general: packages cannot be partially installed
Am Tuesday 02 September 2008 16:01:17 schrieb Michelle Konzack: > Am 2008-08-31 19:08:49, schrieb Mark Hobley: > > eg: coreutils depends on coreutils-fileutils and > > coreutils-fileutils depends on coreutils-fileutils-head, > > coreutils-fileutils-split > > This would leed into over 200.000 Binary packages... > > > It is policy that internationalized (non-english) components are > > packaged separately to the core package. For example, a package foobar, > > would have its french documentation in a separate foobar-fr package. > > > > Packages should not install cruft on the system. This means that a > > package should not install a foreign language file, unless the system > > has been explicitly configured to support that foreign language. > > Hmmm, how many languages do we have? > > If each package is only translated into 10 languages, your wish will > lead into over 15.000 additional packages. That's not what he said. If installation of language files (they can still be in the program package) could be only done for the language(s) that the user wants (many systems only will ever use one specific translation), you could reduce the installed files by many thousands. Actually nobody needs all of them but only a subset. Disc space of cheap most of the time, though. HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: update-rc.d
Kel Modderman wrote: > Hi all, > > This email describes an extension of update-rc.d to provide an interface > for disabling and reenabling initscript sysvinit runlevel start links. > > It contains a patch that is the last in a series[0] of patches submitted to > the sysvinit team. After speaking with Petter Reinholdtsen on irc he suggested > sending the idea to a wider audience for review and discusion. > > Another proposed update-rc.d extension[1] is worth a mention too, though it is > not described in detail by this communication. It is a proposal for a method > providing an interface for maintainer scripts to facilitate change of runlevel > scheme on package upgrades. > > Please have a comment and identify what you think is good and crap. > > [0] > http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2008-September/002861.html > [1] > http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2008-September/002865.html Imho long overdue, thanks for taking a look at this! I haven't looked at [1] yet, but what happens, if you update a disabled init script, will it update the K symlinks too, so when you (re)enable the service, that it has the correct priority? Example: # update-rc.d foo defaults /etc/rc[2345].d/S20foo /etc/rc[016].d/K20foo # update-rc.d foo disable /etc/rc[2345].d/K80foo /etc/rc[016].d/K20foo # update-rc.d foo from defaults to start 30 2 3 4 5 . stop 70 1 . /etc/rc[2345].d/K70foo /etc/rc1.d/K70foo Would it work like this? Would it also work together with insserv? 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: DELAYED queue and upload hostname
Quoting Julien Cristau ([EMAIL PROTECTED]): > Some questions: > 1) I use Tollef's DELAYED queue mostly for 0-day because it's accessible > over ssh, so I can rsync files over which is more reliable than ftp on a > bad link. It sounds like you're removing the possibility to use that (I > know I can rsync files to some debian host and ftp from there, but > that's more manual work). I have the same concern. Tollef's DELAYED queue for 0-day is my "regular" upload method for years now because I can upload with SSH, which is convenient for me in several situations where I can't use anything but SSH (often from my company's internal network). Will a possibility to "upload" with SSH be added at some moment? I recently saw mentions of /org/delayed.debian.org/ on ravel and thought that this was the new delayed queue, but it appears that files sent there are not processed. So, as of now, my only method to upload when I only have SSH/scp possible is using Tollef's old delayed queue. signature.asc Description: Digital signature
Re: DELAYED queue and upload hostname
Christian Perrier <[EMAIL PROTECTED]> (21/09/2008): > Will a possibility to "upload" with SSH be added at some moment? Maybe it'd be feasible to teach dput/dupload how to use an @d.o machine as “proxy”, where the files are scp'd to, and from which they're moved to the appropriate place afterwards? Mraw, KiBi. signature.asc Description: Digital signature
