Bug Tracking System now supports MIME
Hi, New versions of the bug tracking system's mail-bots with full support for MIME have been rolled out. This means that you can now safely submit bugs with attachments without having to wait for the bug number to come back, GPG-sign bug submissions and control messages, and so on. (MIME always worked in contexts that didn't require scanning mail bodies for special text, such as follow-ups to existing bugs, and in other contexts used to work only if you were lucky.) If you encounter any problems with MIME submissions or notice any glitches as a result of these changes, please report a bug on the 'bugs.debian.org' pseudo-package. If you have problems doing even this, please contact us directly at [EMAIL PROTECTED] It will help to include the full MIME-encoded mail you're trying to send, complete with headers: the BTS should return this to you with any error messages. Cheers, -- Colin Watson, junior [EMAIL PROTECTED][EMAIL PROTECTED] pgppLy6OjHdiS.pgp Description: PGP signature
Bug-Squashing Party, July 9th-11th
Hello world, Huntin' Season never stops. Now that the Social Contract issues are apparently resolved, and the new installer is nearly ready, we need to do some hard work to raise the quality of sarge and finish off the release. In aid of this, we're going to hold a bug-squashing party this weekend. Sorry for the short notice; if you miss this one, I believe some people will be organizing an effort next weekend too, and we'll keep going until sarge is ready. At the time of writing, http://bugs.debian.org/release-critical/ says that there are 297 release-critical bugs affecting sarge. Many of these are easy: 93 of those have the patch tag set on them. If we make a concentrated effort now, we can get the number down to a figure where the number of packages that the release team has to remove from sarge is not too painful. We need to concentrate first and foremost on problems in the base system and in the set of packages installed as standard, namely those listed here, since there's no option of removing those: http://bugs.qa.debian.org/cgi-bin/base.cgi http://bugs.qa.debian.org/cgi-bin/standard.cgi However, help with anything on the RC bug list is welcome. Even if you aren't a Debian developer, you can help by diagnosing bugs, narrowing down their causes, and/or providing patches. There'll be a number of developers around to upload changes. For developers making non-maintainer uploads, please remember to keep your changes minimal, and to ensure that the changes are filed in the bug tracking system. You can use Tollef Fog Heen's delayed incoming queue at gluck:~tfheen/DELAYED/ to automate the task of mailing a patch, giving the maintainer a chance to respond, and uploading a fixed package. I suggest a delay of a few days should be sufficient for long-standing bugs. Remember to watch the package to make sure you haven't introduced any new problems, and do your best to produce changes that are correct and in line with how the maintainer maintains the package. We'll be coordinating in the #debian-bugs IRC channel on Freenode, irc.freenode.net (some people will be around on OFTC too). There are various links in the topic of that channel which may be helpful. If you need further incentive, the effectiveness of bug-squashing parties is likely to be a major input into release planning. If they do well, we have more room to be aggressive. For reference, it looks like the d-i team will be ready to put out a release candidate in a few weeks' time, and, if that and the bug count both look good, then we should be looking to freeze shortly afterwards and release once the security team has got up to speed and a final round of d-i tweaking is done. However, we can only do this with your help. Cheers, -- Colin Watson [EMAIL PROTECTED] pgpIcBNvo4V8r.pgp Description: PGP signature
Release update: base and standard frozen
You're only supposed to blow the bloody doors off! As of last night, thanks to Daniel Silverstone, no more base (as installed by debootstrap) or standard (by priority) packages will be accepted into testing from unstable. Fixes for RC and important bugs, as well as updated package translations, are still allowed through uploads to testing-proposed-updates. These uploads will be manually reviewed and approved by the release team; we would appreciate, even more than usual, that diffs be kept to an absolute minimum so that our job is easier. Please review your changes with 'debdiff' or similar before uploading. If in doubt, get in touch with debian-release@lists.debian.org first. Uploads of gcc-3.3 and gcc-3.4 are currently waiting in testing-proposed-updates/incoming for builds to complete. These will allow us to make packages built against unstable that depend on libgcc1 valid candidates for testing. As for the other major library transition that's happening, namely libtiff4, it seems to be well in hand thanks to some sterling efforts. The last few updates to unstable should happen over the next couple of days. Now, we have slipped a little bit, partly because of toolchain problems and partly because debian-installer needed a few extra days anyway, so here's an updated timeline: 7 August 2004 215 RC bugs Hard freeze of base+standard Here we are. We need to be fixing RC bugs as quickly as possible from now on, and RC bugs should not be staying open for longer than a week. If you're having trouble, contact debian-release or ask for help in #debian-bugs on irc.freenode.net. If any of the buildds are still having problems with testing-proposed-updates or testing-security uploads, we're going to need those to be fixed soon. Base and standard libraries in unstable may not make changes that require increased shared library dependencies. This is in order that lower-priority packages built against them can still propagate to testing. 7 August 2004 215 RC bugs Debian-installer RC1 released Also today, businesscard and netinst CD images of d-i RC1 have been built, and full CD sets are building. These should be available by dinstall time on 7 August. We now need developers and interested users to begin testing these images for release-worthiness, and reporting both successes and failures as bugs against the installation-reports package in the usual way. The release schedule allows time for another d-i release in late August to fix any release-critical problems found. The full CD sets (as opposed to businesscard and netinst images) may still need a lot of work. Based on feedback from d-i testing, the installation manual is refined and prepared for release. 12 August 2004 ~180 RC bugs testing-proposed-updates, testing-security working for all architectures Official security support for sarge begins Assuming the toolchain is in order, we can hope to have autobuilders for testing-proposed-updates and testing-security in working order for all architectures by this point. The testing-proposed-updates queue will already be in use for uploads of RC bugfixes, but up to now testing-security is not in use. Now that it's ready, the security team can begin providing security support for sarge. The sooner this can actually happen, the better. The biggest chunk of the security team's load is going to be in searching for regressions from woody, which is something that can easily be distributed over developers and users. Volunteers to help with this would be greatly appreciated. With security support in place, adventurous users can begin testing the upgrade path from woody to sarge. Their feedback will be used for further bugfixing of packages, and to start preparing release notes. Please report any problems as bugs against the upgrade-reports package. 17 August 2004 ~165 RC bugs Last call for low-urgency uploads 28 August 2004 100 RC bugs d-i RC2 if needed Freeze time! 16 September 2004 0 RC bugs Evaluate status and pick date for release 19 September 2004 Release target You know the rest. Over the next two or three weeks, we need to concentrate hard on stabilizing the system and fixing the 200-odd release-critical bugs that remain, either by making minimal changes to packages or by removing them. Cheers, -- Colin Watson [EMAIL PROTECTED] Debian Release Team pgp5ZY82pcOMj.pgp Description: PGP signature
Debian 3.1r0 CD/DVD image problem
A bug has been discovered in the 3.1r0 CD/DVD images: new installs from these images will have a commented-out entry in /etc/apt/sources.list for http://security.debian.org/ testing/updates rather than an active entry for http://security.debian.org/ stable/updates, and thus will not get security updates by default. This was due to incorrect Release files on the images. If you have already installed a system using a 3.1r0 CD/DVD image, you do not need to reinstall. Instead, simply edit /etc/apt/sources.list, look for any lines mentioning security.debian.org, change testing to stable, and remove # from the start of the line. If you installed other than from a CD or DVD (for example, netboot, or booting from floppy and installing the base system from the network), you are not affected by this bug. New 3.1r0a images will be available shortly to correct this flaw. In the meantime, CD vendors should delay pressing CDs or DVDs of Debian 3.1. We apologise for the inconvenience. -- Colin Watson [EMAIL PROTECTED] Debian Release Team signature.asc Description: Digital signature
Re: Uploading amd64 packages
On Fri, Nov 18, 2005 at 03:10:37PM +0100, Jérôme Marant wrote: Quoting Florian Weimer [EMAIL PROTECTED]: * Jérôme Marant: Is it currently possible to upload amd64 packages to ftp-master? amd64 is not yet part of the archive. It depends on the so-called mirror split. I guess so, but I haven't seen any status update about this. Are there even people working on it? Apparently so: http://azure.humbug.org.au/~aj/blog/2005/11/16#2005-11-16-dak -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#340404: ITP: libemail-valid-loose-perl -- Email::Valid which allows dot before at mark
On Wed, Nov 23, 2005 at 11:06:32AM +0100, Krzysztof Krzyzaniak (eloy) wrote: * Package name: libemail-valid-loose-perl Version : 0.04 Upstream Author : Tatsuhiko Miyagawa [EMAIL PROTECTED] * URL : http://search.cpan.org/~miyagawa/Email-Valid-Loose-0.04/ * License : Perl: Artistic/GPL Description : Email::Valid which allows dot before at mark Email::Valid::Loose is a subclass of Email::Valid, which allows dot (.) before at-mark (@). It is invalid in RFC822, $ perl -MEmail::Valid -le 'print Email::Valid-rfc822(q([EMAIL PROTECTED]))' 1 I think the description needs to be improved; perhaps it means dot (.) immediately before at-mark (@), which *is* invalid in RFC822. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Mon, Nov 28, 2005 at 07:07:22PM +1000, Anthony Towns wrote: (Note that dsum would probably need to become Priority:required, and possibly Essential:yes, with the complications that entails) Stick it in dpkg.deb. There's plenty of precedent for that (some not-so-good, but I think mostly good). -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Tue, Nov 29, 2005 at 02:20:55PM +0100, Florian Weimer wrote: * Anthony Towns: On Sat, Nov 26, 2005 at 10:59:57AM +0100, Florian Weimer wrote: In terms of security, there are some better hash functions. My understanding was that there aren't other hash functions that've had remotely similar levels of cryptographic analysis to md5 and sha. Neither MD5 nor SHA1 have received much public scrutiny. Dobertin's work on MD5 has never been fully published. I've already joked that the difference between Wang et al. and European or U.S. cryptographers is that the Chinese government doesn't tell their researchers not to publish their results. 8-P IIRC, the elliptic curve cryptography stuff was supposed to be similarly neat, until people started analysing it seriously, at which point it broke. The NSA has recently licensed ECC patents from Certicom. There are weak elliptic curves as far as cryptography is concerned, but there are also others: inefficient ones and those which have been patented by Certicom. A cryptographer friend of mine recently attended the NIST Hallowe'en Hash Bash (http://www.csrc.nist.gov/pki/HashWorkshop/index.html), and made a few notes in his blog: http://www.livejournal.com/users/sevenstring/7326.html His suggestion there was stick to SHA2 (or maybe Whirlpool) for now. Did anyone else here attend this workshop? That said, I suspect that any my favourite algorithm argument is going to get horribly bogged down in bikeshedding. As long as we don't fall into the multicollisions trap of spending more and more CPU time generating and checking more and more iterative hash functions that don't actually add significant collision-resistance when you check them all together, a generalised checksumming tool as proposed seems an obviously sensible and desirable thing to have. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Automatic closing of bugs
On Fri, Dec 02, 2005 at 02:01:28PM -0500, Joey Hess wrote: A lintian-like test to see if the listed bugs match the package before uploading seems more useful to me. It would have prevented this particular problem. yaclc provides this. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel-package hooks transition
On Sat, Dec 24, 2005 at 05:03:17PM +0100, Sven Luther wrote: Notice that the debconf helper scripts provide stdout on 3, so any scripts writing to stdout only need to redirect their output to 3, no ? No, that won't work; if you send something to fd 3, it will go to the debconf frontend and be interpreted as a debconf protocol command. In any case, it's only the shell confmodule that sets up fd 3 to go to the frontend, and the kernel-package-generated postinst is written in Perl; people may well have written postinst.d fragments in Perl too. Please use stderr instead, or, if possible, just make the script quiet. The fd 3 redirection (and the corresponding redirection of stdout to stderr in the shell confmodule) was always acknowledged as a nasty hack in debconf. At the time, as I understand it, Joey reckoned it was easier to do that than to try to get everyone to change maintainer script code that used stdout. It has various undesirable consequences, such as the requirement to call db_stop before starting daemons that don't take care to close down all their file descriptors, and some very weird workarounds in the confmodule bindings for other languages (see the changelog entry for debconf 0.3.74). My impression is that these days maintainer scripts are much better about not mixing up debconf interaction with normal use of stdout, and so it's still possible that the fd 3 hack will be removed some day. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel-package hooks transition
On Sun, Dec 25, 2005 at 01:43:19AM +0100, Sven Luther wrote: On Sat, Dec 24, 2005 at 05:30:26PM +, Colin Watson wrote: On Sat, Dec 24, 2005 at 05:03:17PM +0100, Sven Luther wrote: Notice that the debconf helper scripts provide stdout on 3, so any scripts writing to stdout only need to redirect their output to 3, no ? No, that won't work; if you send something to fd 3, it will go to the debconf frontend and be interpreted as a debconf protocol command. In Well, you are the expert, i said this, because the /usr/share/debconf/confmodule script i use in mkvmlinuz and recomended by debconf-devel says : # Redirect standard output to standard error. This prevents common # mistakes by making all the output of the postinst or whatever # script is using this library not be parsed as confmodule commands. # # To actually send something to standard output, send it to fd 3. which i read that 1 goes to debconf and 3 to stdout normally. But then i am largely out of my depth here, and would greatly greatly appreciate someone with a real clue (you or joeyh being likely candidates here :) to have a look at this issue. I already described the real behaviour in my previous mail. The comment above is certainly a bit confusing, but it's trying to say that fd 3 goes to the standard output of the confmodule *after* the frontend has been started up. At that point, the confmodule's stdout is connected to the frontend. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel-package hooks transition
On Sun, Dec 25, 2005 at 01:51:00AM +0100, Sven Luther wrote: On Sat, Dec 24, 2005 at 05:30:26PM +, Colin Watson wrote: On Sat, Dec 24, 2005 at 05:03:17PM +0100, Sven Luther wrote: Notice that the debconf helper scripts provide stdout on 3, so any scripts writing to stdout only need to redirect their output to 3, no My impression is that these days maintainer scripts are much better about not mixing up debconf interaction with normal use of stdout, and so it's still possible that the fd 3 hack will be removed some day. Ok, now i read it all, shouldn't really be replying to email after the christmas party ... :) Likewise, on Christmas Day I haven't really looked at this issue in any depth. :-) So, do you have any idea of what is going wrong here and how to fix it ? I mean having hosed powerpc kernels over christmas is really not the nicest thing to have happen, and i really don't understand the subtleties of what is going on here. k-p uses debconf (probably using the perl helpers you mentioned), and does a db_stop before calling the script hooks. The STOP command causes the debconf frontend to shut down; that would certainly break anything trying to talk to debconf after it. May be worth removing that and seeing if things start working. I haven't checked if kernel-package runs anything else that would require it to use STOP. It seems a little unlikely that it would be starting up any daemons, though. Note a common misconception: the STOP command does *not* put your file descriptors back the way they were before you started the debconf frontend. The script hooks, of which only mkvmlinuz uses debconf, but using debconf being the right thing to do probably given the debconf-related policy, so the script hooks calls debconf itself, which checks that debconf is not yet running and reruns it if not. While it's correct for your hooks to load an appropriate debconf confmodule library (/usr/share/debconf/confmodule, in your case), the check you mention only works if the debconf frontend has never been started. It won't notice that you've shut the frontend down with STOP in the meantime. debconf isn't designed to be repeatedly shut down and started up again in the same process. My belief is that somehow there is an inconsistency in the debconf helper, maybe in the interaction of the perl debconf helper and especially the perl db_stop, with the shell debconf helper. Can this be ? It's certainly possible, although those particular two confmodule libraries are fairly well-tested and I think other things use them that way round. I'd try removing the STOP command first. Do we have some kind of documented spec of how these helpers do handle the debconf interaction, or something, which would enable to investigate this issue without lengthy error-and-trial ? debconf-devel(7) documents a lot of it here and there, but it's not really in the form of a strict design document or anything. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
On Thu, Jan 05, 2006 at 04:32:29PM -0800, Matt Zimmerman wrote: On Fri, Jan 06, 2006 at 01:22:50AM +0100, Petter Reinholdtsen wrote: [Michael Vogt] Sorry for the delay. I'm preparing a new upload that adds the 2006 archive key to the default keyring. Sounds good. Will this automatically take care of the key update and make sure no manual intervention is needed to get packages upgraded? Isn't Ubuntu using the signed apt stuff? How are they handling the new archive keys? Ubuntu's apt package ships only the Ubuntu archive keyring, not the Debian archive keyring, so no update is needed when Debian keys change. That doesn't mean we (Ubuntu) have solved the problem of how to rotate *our* keys in the event of a key compromise. (To my knowledge, we haven't.) -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [ad-hominem construct deleted]
On Wed, Jan 18, 2006 at 09:41:58AM +0100, cobaco (aka Bart Cornelis) wrote: On Tuesday 17 January 2006 00:39, Matt Zimmerman wrote: Given that you saw this on a wiki page, a disclaimer about wiki contents should be implicit. However, regardless of whether it's an accurate quote, it's quite clear to me from context that your interpretation doesn't match the text. The full quote is We sync our packages to Debian regularly, because that introduces the latest work, the latest upstream code, and the newest packaging efforts from a huge and competent open source community. Without Debian, Ubuntu would not be possible. It should be obvious from the remainder of the sentence that it is talking about propagation of changes *from* Debian *to* Ubuntu. syncinc _to_ debian implies that changes are _pushed_ to Debian regularly, whereas in actuallity they're simply made available for pull by Debian (in most cases) It's meant to be shorthand for syncing [the package in Ubuntu] to [match the version in] Debian, or similar; I've certainly used the same colloquial shorthand in bug reports and such without realising that it could be confusing if stripped of all its context. Although, like Matt, I do think that the context (https://wiki.ubuntu.com/MarkShuttleworth, near the bottom) clarifies the meaning, I agree it's not the best phrasing and for grammatical reasons should be changed to synced from Debian. Matt has already said he'll ask for this to be changed (it's on Mark's personal wiki page, so changing it directly would be a bit rude), so hopefully we can stop going round in circles on this one. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
On Wed, Jan 18, 2006 at 11:36:13PM -0600, Joe Wreschnig wrote: On Thu, 2006-01-19 at 12:12 +1000, Anthony Towns wrote: Some reasons: * compatability with Ubuntu -- so that packages can be easily ported back and forth between us and them; I expect most of the work ubuntu might do on improving boot up will require python-minimal This would be nice. Right now it's accomplished through patches Ubuntu makes to dh_python and cdbs. They'd probably like to drop those. As a point of information, Ubuntu doesn't patch dh_python at present, and I don't see any Python-related changes in cdbs at the moment either. I don't know what's actually in (or more importantly not in) python2.4-minimal though. I'm eyeballing right now. Things that jump out at me: * No character encoding, translation, or locale handling. * A little oddly, loss of shutil. * No sockets. FWIW the relevant design docs from when this was done in Ubuntu are here: https://wiki.ubuntu.com/EssentialPython (requirements) https://wiki.ubuntu.com/PythonInEssential (details) The rationale for the set of included modules is in the latter, and was basically done by taking each module in perl-base and mapping it to its Python equivalent. The third seems like something software in base may want to do; I mention it specifically because perl-base include socket support. Socket support does seem to be there: $ dpkg -c /mirror/ubuntu/pool/main/p/python2.4/python2.4-minimal_2.4.2-1ubuntu2_i386.deb | grep socket -rw-r--r-- root/root 49608 2006-01-17 12:59:02 ./usr/lib/python2.4/lib-dynload/_socket.so -rw-r--r-- root/root 12876 2006-01-17 12:58:18 ./usr/lib/python2.4/socket.py Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Pre-Depends for Xorg 7.0
On Mon, Jan 23, 2006 at 12:15:23AM -0500, Joey Hess wrote: David Nusinow wrote: Currently, it fakes FHS compliancy by creating various symlinks (/usr/include/X11, /usr/bin/X11, /usr/lib/X11) to the appropriate directories in /usr/X11R6. For 7.0, we need to make those symlinks become actual directories. I thought that the idea instead was to move everything directly into /usr/include, /usr/bin, and /usr/lib. Why keep the X11 subdirectories? /usr/include/X11 is obvious enough (#include X11/*). There is some software that contains hardcoded paths to executables in /usr/bin/X11; for example, sshd hardcodes the path to /usr/bin/X11/xauth. sshd stats whatever it thinks is the location of xauth to find out whether it can do X11 forwarding, so it's not entirely trivial to unhardcode this path. Note that the FHS has this to say about /usr/bin/X11 and friends: In general, software must not be installed or managed via the above symbolic links. They are intended for utilization by users only. I always interpreted this as meaning that packages couldn't install files there via the symlink, but that it was OK to refer to files via the symlink. Current Ubuntu makes /usr/bin/X11 a symlink to . (i.e. /usr/bin) which means that this all continues to work fine after xauth and friends move to /usr/bin. David's paragraph above implies something different. David? Also, moving stuff to /usr/bin/X11 and making it a real directory will break things for anyone having /usr/X11R6/bin in their path instead. One example of such a path is in pbuilder. That much would continue to work fine if binaries were moved to /usr/bin rather than /usr/X11R6/bin, and with a /usr/bin/X11 - . symlink paths hardcoded as specified in policy (11.8.7, Installation directory issues) would continue to work as well. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
debconf and cdebconf are coinstallable now
Joey has been campaigning [1] for a while to get everything in the archive changed to depend on debconf | debconf-2.0 or similar rather than just debconf, in order that we can start rolling out cdebconf as its replacement. Like most jobs that involve touching the bulk of the archive, this looks set to take quite a while, as the list of bugs [2] should indicate. Recently it occurred to me that we didn't necessarily have to do it that way round. I've shuffled things around in the cdebconf package so that it no longer has any file conflicts with debconf or debconf-doc, and changed the debconf confmodule to fire up the cdebconf frontend rather than its own if the DEBCONF_USE_CDEBCONF environment variable is non-empty. These changes have been in unstable for about a month, as of debconf 1.4.70 and cdebconf 0.96. This allows you to install cdebconf, set that environment variable, and play around with cdebconf with relative ease; when we come to switch to cdebconf for real, instead of a huge conflicting mess that apt will probably have trouble resolving, it'll just be a matter of changing a couple of lines in /usr/share/debconf/confmodule. Of course, don't expect cdebconf to be a complete working replacement for debconf just yet; if you try using it for a dist-upgrade run it'll fall over. Due to its d-i heritage, it doesn't yet load templates automatically; that has to be done by hand. Frontend names differ from debconf's, which will need some migration code. At the moment it can only handle UTF-8 templates, which are mandated in the installer but only optional in the rest of the system. It doesn't have all of debconf's rich array of database modules. The list goes on. However, I think we at least stand a chance of getting a handle on the problem now. For those developers who want to try this out, the following should set up a reasonable initial cdebconf templates database (with the exception that non-UTF-8 templates will generate a warning and be ignored): find /var/lib/dpkg/info -name \*.templates | \ sed 's,.*/\(.*\)\.templates,\1 ,' | \ xargs -L1 /usr/lib/cdebconf/debconf-loadtemplate You can then set DEBCONF_USE_CDEBCONF=1 in the environment and/or use the programs in /usr/lib/cdebconf to try things out. Of course, I recommend against trying this for package installations or upgrades on a production system; using a chroot to play with that sort of thing might be a good idea. (I meant to repost this from http://riva.ucam.org/~cjwatson/blog/debian/2006-01-27-debconf-cdebconf-coinstallable.html a little while ago, but forgot. Sorry for the delay.) [1] http://lists.debian.org/debian-devel/2005/08/msg00136.html [2] http://bugs.debian.org/328498 Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Wed, Mar 01, 2006 at 11:48:56PM -0600, Peter Samuelson wrote: [Brian May] Even if nobody does this, it is still possible to integrate ndiswrapper with free software (such as debian-installer)[1]. The same thing cannot be said (IMHO) for an installer package. Eh? Why not? Why wouldn't you be able to integrate an installer package with other free software? It's possibly worth noting that d-i's habit of assembling itself out of component parts at run-time makes it not all that dissimilar to contrib installer packages, except for the nature of the material it acquires. ;-) And, speaking of d-i, here's another thing I've been unable to understand. Someone please enlighten me, because I feel sure I must be missing something: What possible use would it be to integrate ndiswrapper into debian-installer? Wouldn't the user _still_ have to provide a Windows driver in some format usable by ndiswrapper? Wouldn't that still have to come from some external source, like a web site or a floppy disk? And if so, why would it be a hardship to get ndiswrapper from an external source at the same time? (I have no particular position on ndiswrapper in main per se, and I haven't read all of this enormous thread.) It's common for e.g. network card manufacturers to provide their images on a floppy disk. If ndiswrapper were integrated into d-i, then it would be possible to let the user insert the floppy disk provided by the manufacturer and make their card work with just that. Without ndiswrapper integration, the user has to figure out that this thing called ndiswrapper that they've never heard of is needed, then go and get it and prepare a floppy disk with all the right stuff on it. This is a lot more error-prone, may not always be possible (they may not have any access to the Internet other than via the system they're trying to install), and even if possible raises the difficulty bar quite significantly beyond insert the floppy disk provided with your network card. Of course, it would be possible to prepare a special ndiswrapper driver image that could teach the installer how to do this without having to have it in the core installer; so ndiswrapper doesn't *have* to be in main for this to work, although it would make things easier from the point of view of making this trick work out of the box with Debian CDs. I can understand the appeal of having ndiswrapper on the installer image, but only if the image also has drivers to use with it. Are we talking about CIPE again? Is CIPE useful for an installer? Not in any way I can imagine. It's true that the trick outlined above is only (AFAIK) useful for getting your hardware to work using non-free software. Actually, I'm not certain whether packages in main are allowed to Suggest packages outside main. If not, the usual workaround is for ndiswrapper to instead declare an Enhances relationship on foo. Traditionally Suggests have been OK, although one of the main reasons why Enhances was invented as a reverse-Suggests was to allow all references to non-free packages to be removed from main's metadata. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Thu, Mar 02, 2006 at 10:27:48PM +1000, Anthony Towns wrote: On Thu, Mar 02, 2006 at 08:32:46AM +, Colin Watson wrote: It's common for e.g. network card manufacturers to provide their images on a floppy disk. If ndiswrapper were integrated into d-i, then it would be possible to let the user insert the floppy disk provided by the manufacturer and make their card work with just that. Note though that the code to grab the NDIS driver off the disk/cdrom/network and install it onto the filesystem would fit precisely under the installer package definition and thus belong in contrib, even with ndiswrapper in main... I suspect any code that handled driver disks would (or at least could, pretty plausibly and sensibly) be focused along the lines of supporting free drivers that didn't ship with the last Debian release. Even with Debian's highly modular kernels, we don't always include support for every single free driver out there, and it would not be at all unreasonable or unlikely for somebody to publish a driver disk that includes some free driver module backported to the kernel in Debian's most recent release so that you could install systems with the corresponding hardware. If somebody then came along and wanted to add a few lines of code to piggyback NDIS or firmware support onto the back of that, I find it surprising that we'd feel it worth punting that off to contrib; all the interesting stuff would be in the generic driver disk handling, and NDIS or firmware support would be an extra entry in a case statement or something like that. In fact, I could well believe that some firmware would fall into the scenario in the previous paragraph, being free but just not supported by the most recent Debian release, or you need a newer version for your card or something. I suppose it *could* be split out, although - insofar as I can make this claim of hypothetical code - it seems to me that it'd complicate things substantially to do so. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debconf and cdebconf are coinstallable now
On Thu, Mar 02, 2006 at 11:59:02AM +, Martin Michlmayr wrote: * Colin Watson [EMAIL PROTECTED] [2006-03-02 05:08]: Joey has been campaigning [1] for a while to get everything in the archive changed to depend on debconf | debconf-2.0 or similar rather than just debconf, in order that we can start rolling out cdebconf as its replacement. It would be nice if you could tell _why_ you're interested in migrating to cdebconf. What does it have that debconf doesn't, or what other advantages does it have? Is it easier to maintain, smaller, ...? * smaller * should generally be faster (relevant for upgrade times, reconfiguring, live CDs, etc.) * maintaining two debconf implementations is hard work, and we need cdebconf for the installer anyway * consistent UI between installer and installed system (though the obvious visual disconnect here has been helped greatly by killing off base-config) That's what I can think of at the moment, anyway. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release Date Update
On Mon, Mar 20, 2006 at 02:51:25PM -0800, Mark Shuttleworh wrote: (In case it wasn't clear, this wasn't Mark Shuttlewor*t*h posting. Please don't feed the troll.) -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: (no subject)
[EMAIL PROTECTED] (Mark) wrote: Not actually a bug, but a recommendation for later distributions security, i've noticed 2.1 only allows something along the lines of an 8 character password. If someone were to get ahold of someone's username, which is easy to do, and they of course had some queer password guessing tool that tried all combinations within the 8 char limit, it'd be pretty easy to at least do that. I've tested other distributions like slackware, slack7 allows a 126 character password at max which is a really good thing. Just a recommendation. Any administrator can change this by poking PAM to use MD5 passwords, but it's not enabled by default. This might be because other Unix systems don't necessarily support it, which can cause problems if you're using something like NIS and sharing crypted passwords around (or so I understand). -- Colin Watson [EMAIL PROTECTED]
Re: X Packages?
[EMAIL PROTECTED] (SCOTT FENTON) wrote: Greetings all. I am in the process of engeneering a tryout of XFree 4 and I need to know this to continue. What packages come directly from the XFree86 sources. I know the basics (xserver-*, xfree86-common), but does anyone have a complete list? Install the grep-dctrl package and use something like: grep-available -FSource -nsPackage xfree86 | sort -- Colin Watson [EMAIL PROTECTED]
ITP: javawrapper
Hi, I intend to package javawrapper. Package: javawrapper Version: 1.0-1 Section: utils Priority: optional Description: A wrapper for kernel execution of Java programs javawrapper uses the binfmt_misc feature of newer Linux kernels to execute a Java class file directly simply by supplying its filename on the command line like a normal executable. It also correctly handles classes contained in packages. I'm also the upstream maintainer for this package, and the source is already being distributed in the kernel documentation tree. I'm not yet a developer, so I'm looking for a sponsor - please mail me if you want to help! Thanks, -- Colin Watson [EMAIL PROTECTED]
Re: Bug#60753: mutt: /etc/Muttrc should not use colors
[EMAIL PROTECTED] (Craig Sanders) wrote: On Sun, Mar 19, 2000 at 09:04:24PM -0300, Nicolás Lichtmaier wrote: Pg-down advancing to next message? PgDn scrolls down the message, as expected. PgUp scrolls back up. the only annoying thing is that if you are already at the end of a message, then PgDn takes you to the next message. this should be optional behaviour. maybe it already is...it has never annoyed me enough to find out. 'set pager_stop=yes'? The key binding are so insame that prevent people (newbies) fom using mutt, they first must to learn how to change those defaults to something acceptable. it's not that bad. if newbies can pick up emacs' horribly contorted key bindings then mutt's a doddle. FWIW, I picked up mutt's keybindings from pine inside two days. I don't find them a problem. -- Colin Watson [EMAIL PROTECTED]
Re: Single architecture on -announce lists
[EMAIL PROTECTED] (Joey Hess) wrote: Ben Collins wrote: The lists already exist, they are just not used at all. Maybe it would be easier to keep just the one debian-devel-changes list to send to and write some extra procmail stuff into sending it to the write outlist. Well, we could just sign everyone who is currently subscribed to debian-devel-changes up to debian-devel-*-changes, and obsolete debian-devel-changes. Then post an announcement that people can easily selectively filter mail by unsubscribing from architectures they're not interested in. Although I guess that might mess with some people's mail filters, to change list names behind their backs.. A little, yes ... Couldn't we keep debian-devel-changes as is and simply copy the mail to debian-devel-*-changes, for backward compatibility? -- Colin Watson [EMAIL PROTECTED]
Re: Potato - update-alternatives (Ian Jackson) and window managers - doubt (and Slink to Potato Success)
[EMAIL PROTECTED] (Robert Bihlmeyer) wrote: Taupter [EMAIL PROTECTED] writes: Yes I did read the man 8 update-alternatives, but it was a bit confusing to me (as I think it is a bit confusing to anyone but the man writer aka Ian Jackson), since it was not sufficiently explanatory (at least to me. Shame on me...). I agree. Trial-and-error helps. I find 'update-alternatives --help' more useful, myself. It's mainly intended for developers, though - I only used it when I wanted to fix broken man page links in various packages. -- Colin Watson [EMAIL PROTECTED]
Re: Obsolete packages
Michael Meskes [EMAIL PROTECTED] wrote: After upgrading my machine I found some obsolete packages. Before purging them I'd like to know if there are replacements: html2latex Tomasz Wegrzanowski wrote a free reimplementation of this, gnuhtml2latex, so html2latex was removed. lde gtkbrowser These both still seem to be in woody. -- Colin Watson [EMAIL PROTECTED]
[PROPOSAL] update-binfmts - manages the binfmt_misc kernel module
Hi all, I've been working on javawrapper, a utility which uses the binfmt_misc kernel module to let you execute Java classes like any other program - './MyProgram.class' instead of 'java MyProgram.class'. For those of you unfamiliar with binfmt_misc, the documentation is in Documentation/binfmt_misc.txt in the kernel sources (since 2.1.43). It occurred to me while I was writing the init.d script (with the advice of my sponsor (cc'ed), IANYAD) that most of what I was doing was reusable. I'm not aware at the moment of any packages that use binfmt_misc; please somebody let me know if I'm wrong. The author of binfmt_misc says it would be useful for Python and elisp, and I've found it convenient to use it for WINE too. Now, at the moment, actually using this is rather complicated for both package maintainers and sysadmins. Maintainers have to cope with the fact that there's a bug in 2.2/2.3 binfmt_misc (patch sent, and with luck might make it in before 2.4) which allows you to register two binary formats with the same name and thus create two files with the same name in /proc. This needs to be handled consistently across packages. Sysadmins have to cope with the not-obviously-memorable syntax of what you have to echo to /proc/sys/fs/binfmt_misc/register to make the whole thing work. I've been working on a tool called update-binfmts which, along the same lines as update-alternatives, dpkg-divert, et al, keeps a database of binfmt_misc interpreters in /var/lib/dpkg/binfmts, and lets root register and unregister them at will. To take WINE as an example of how this might be used, the idea is that, instead of me using systune to effectively do: echo ':wine:M::MZ::/usr/bin/wine:' /proc/sys/fs/binfmt_misc/register ... at startup (without any error-detecting code around this, as I haven't done the same thing with wine as with javawrapper yet), the wine package ought to be able to do something in its postinst like: update-binfmts --package wine --add wine /usr/bin/wine --magic MZ ... and something in its prerm like: update-binfmts --package wine --remove wine /usr/bin/wine Then /etc/init.d/binfmt-misc (or similar) does this: start) [...] update-binfmts --register [...] ;; stop) [...] update-binfmts --unregister [...] ;; ... to (un)register all installed binary formats with the kernel, and a sysadmin can do something like 'update-binfmts --register wine' or 'update-binfmts --unregister wine' to turn support for an individual format on or off. Obviously this interface is fluid at the moment, but I think it has the benefit that it's quite close to the syntax used by tools like dpkg-divert so maintainers should be able to remember it, and it's almost trivial for an admin. I have a working implementation of something close to this running on my system, though it needs a few recent interface changes applied to it and to have its robustness improved more. Various issues I thought I ought to take to debian-devel before proposing this to the dpkg people: 1) Is this a solution in search of a problem? It's certainly a minority interest. I think that it's a useful feature which is woefully underused, but some may disagree. 2) Is the interface right? Once it's being used it will be difficult to change, and particularly as a non-developer I don't want to sound like I'm imposing my own ideas on everyone. There are several option switches other than those I've listed above (--offset, --mask, and --extension) and another action switch (--display). 3) Where should this go? The obvious place is dpkg, but am I being too arrogant there? It feels too small for its own package, though. Thanks, and please let me know if you think I'm in over my head, -- Colin Watson [EMAIL PROTECTED]
Re: [PROPOSAL] update-binfmts - manages the binfmt_misc kernel module
[EMAIL PROTECTED] wrote: On Sun, Apr 02, 2000 at 04:36:00PM +0100, Colin Watson wrote: 3) Where should this go? The obvious place is dpkg, but am I being too arrogant there? It feels too small for its own package, though. I like the idea, but I think it should go in its own package, like menu. For one thing, a lot of admins may not like the arbitrary enabling of executable formats in the kernel. This is true especially in its experimental phase (sort of like debconf is now.) OK, I see your point. I'd better use /var/lib/binfmts instead of /var/lib/dpkg/binfmts, then, I suppose. Thanks, -- Colin Watson [EMAIL PROTECTED]
Re: Bug#33993: general: Should log all the boot messages
Decklin Foster [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: Cesar Eduardo Barros [EMAIL PROTECTED] writes: There are too many boot messages, and they sometimes scroll too fast. It would be nice to log all the output from the boot scripts. Huh? does dmesg not do what you want? dmesg doesn't log the output from init.d scripts. (I usually recommend Ctrl-S (stop output) and Ctrl-Q (restart output).) -- Colin Watson [EMAIL PROTECTED]
Re: Essential virtual packages
Glenn McGrath [EMAIL PROTECTED] wrote: I cant find any details on the virtual package kernel-image except its name, do virtual packages have priorities and can they be marked essential ? Virtual packages are called that because they are just names that are provided by other packages. The packages that provide them have priorities and can be marked essential, sure. But, since there's no entry in the Packages file for them, there's nowhere to mark the virtual package itself essential. The situation is slightly different with mixed virtual packages, where you also have a real package by the same name; for instance, trn is a real package and is also provided by strn. However, the control fields of trn still don't apply to strn; the virtual package is a different entity to the real package by the same name. I'm sure I've explained this badly, because it's complicated. For the full, accurate details, you should look in section 2.3.5 of the Debian Policy Manual (package debian-policy) and section 8.4 of the Debian Packaging Manual (package packaging-manual). -- Colin Watson [EMAIL PROTECTED]
Re: howto (apt-)get only ./debian dir of a package?
[EMAIL PROTECTED] wrote: there is $ apt-get source pkg but usually i just want to peek at the ./debian directory to learn from others doing, or i want to try the official ./debian stuff on a cvs version, ... It's usually the case that debian/ directories are entirely added by Debian maintainers rather than being partially maintained upstream; not always, but usually. In that case you can fetch just package_version.diff.gz from the source directory of the Debian archive and apply it to an empty directory, or something similar. -- Colin Watson [EMAIL PROTECTED]
Re: qmail
Niall Young [EMAIL PROTECTED] wrote: What's the official stance on qmail? Is the licence (or lack thereof?) too restrictive (any modified versions can't be distributed without approval)? Yep. If you have a look at: http://www.debian.org/Packages/stable/mail/qmail-src.html ... you'll see the following paragraph: Dan Bernstein (qmail's author) only gives permission for qmail to be distributed in source form, or binary form by approval. This package has been put together to allow people to easily build a qmail binary package for themselves, from source. DJB has a habit of coming up with almost-free but restrictive licences. :( Any questions about those would probably be best answered on debian-legal. -- Colin Watson [EMAIL PROTECTED]
Re: Security of Debian SuX0r?
Robert van der Meulen [EMAIL PROTECTED] wrote: I don't like crossposting to mailinglists, so i post this to debian-devel, as well as a Cc to the original author. Maybe you should have *really* Cc'd the original author :) (Read the article again; he isn't Juhapekka, that's for sure ...) -- Colin Watson [EMAIL PROTECTED]
Re: Bug#70269: automatic build fails for potato
Antti-Juhani Kaijanaho [EMAIL PROTECTED] wrote: The definition is the following: It is not be necessary to explicitly specify build-time relationships on a minimal set of packages that are always needed to compile, link and put in a Debian package a standard Hello World! program written in C or C++. The required packages are called _build-essential_, and an informational list can be found in `/usr/share/doc/build-essential/list' (which is contained in the `build-essential' package). (Debian Policy v. 3.2.1.0, section 2.4.2.) This will be fun should there ever be another vaguely widely used package in main providing c-compiler or c++-compiler ... -- Colin Watson [EMAIL PROTECTED]
Re: Crazy idea: removing version numbers from debian
Vincent L. Mulhollon [EMAIL PROTECTED] wrote: I had a similar thought this weekend. Perhaps any package can live in unstable, but any package that has a release critical bug older than 1 week is zapped from stable and placed back in unstable. Upon next package upload, it will be reinstated into stable. New packages would not be allowed into stable until x days had passed in unstable status without a Release Critical Bug. [etc.] Those who do not understand ajt's testing distribution are doomed to reinvent it, poorly. :) -- Colin Watson [EMAIL PROTECTED]
Re: My recent bug's and continuing effort to debconf-ize Debian
Sean 'Shaleh' Perry [EMAIL PROTECTED] wrote: I started this afternoon submitting bugs against packages which print verbose output in their maintainer scripts. The future that Debian must take is to fully support debconf. To further this goal I will continue submitting patches to any package which prompts the user in a maintainer script. Are you also reporting bugs against packages whose priority is higher than that of debconf? Is the plan eventually to raise debconf's priority to 'standard' or higher? -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
Sergey I. Golod [EMAIL PROTECTED] wrote: Bas Zoetekouw wrote: Thus spake Sergey I. Golod ([EMAIL PROTECTED]): Why apt/dpkg doesn't use bzip2 for Packages file? -rw-r--r--1 root root 749427 Sep 3 00:56 Packages.bz2 -rw-r--r--1 root root 1024180 Sep 3 00:56 Packages.gz It's about 25% can be saved in download. Yeah, but I guess it would take about twice the time to unpack. Please don't do that to my poor 486 :-(( But extra size = extra traffic = extra money, that's worse. Unpack no cost at all (except you time, ofcourse). These days, my time costs a lot more than my connectivity. I'm lucky enough to have a not-too-badly-obsolete machine at home, and even it creaks quite a bit under the load dpkg puts on it with over 1500 packages installed. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: GUI tools for common Debian admin tasks
Daniel Burrows [EMAIL PROTECTED] wrote: I think it would also be interesting to integrate this into Nautilus (the new Gnome filemanager) and (now that KDE is finally legal) Konquerer. You could certainly display some package info this way -- in particular, being able to display (in the Properties dialog box of these programs) what package a file belongs to would be cool. (it can't be done efficiently yet, but you could cache this information somehow, as dlocate does..) Also, it might be intriguing to (ab)use the VFS support in these programs to convert them into Apt frontends. I'm not sure how far you could go, but it would be interesting to see if it worked. Reminds me of the time my roommate and I took a Packages file, munged it a bit to make it into an mbox mail folder, and then he told Gnus to pretend the mbox was a newsgroup so that he could start killfiling packages. It's one of the stranger things I've ever done. It would, again, be interesting to see how far you could go in terms of crowbarring one metaphor into the other. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RSA Released Into The Public Domain
On Wed, Sep 06, 2000 at 09:38:10AM -0400, Peter S Galbraith wrote: `The RSA algorithm was released into the public domain today (September 6th, 2000). This is in advance of their US patent expiring on the 20th.' http://slashdot.org/article.pl?sid=00/09/06/1252204mode=thread So some stuff can get moved from non-US/main into main proper? I think it's more likely to mean that packages like gpg-rsa, pgp-i, rsaref, and rsaref2 may be able to move into non-US/main if their licences are otherwise DFSG-free (as the US government still has some restrictions on exporting cryptography). Happy day, though. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian and KDE
On Thu, Sep 07, 2000 at 12:51:23PM -0300, Ben Woodhead wrote: If I was wrong, I would have expected to see some news on the homepage saying Yeah, KDEs is completely GPLed and will be included in debian, or at least something like that. After all the reading I did where debian was saying that they would love to have kde but its not free. Well its FREE know and I still don't see any of the people that where complaining about the license saying something about it. Before I post to a widely-read mailing list, I usually try to check the archives first to find out whether it's already been discussed, because I don't really like making a fool of myself in front of hundreds or thousands of people. From just two days ago, see: http://www.debian.org/Lists-Archives/debian-devel-0009/msg00329.html -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: alternatives for MUA and NUA?
Gerfried Fuchs [EMAIL PROTECTED] wrote: And, on the other hand, if you have any packages that are using hard coded pagers, editors or so into it's rc files waste a thought about changing it to the alternatives name ``pager'' and ``editor''. I really think that this should be a little more used so the people know about it and also use it... It's already a bug if packages don't. :) See policy section 5.4 for clarification of this - if (as a package maintainer) you aren't also checking the $EDITOR and $PAGER environment variables, and can't easily do so, then you should use /usr/bin/sensible-editor and /usr/bin/sensible-pager instead. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: fix for daemon start on package install/upgrade out-of-runlevel
Samuel Hocevar [EMAIL PROTECTED] wrote: On Sat, Sep 09, 2000, Robert D. Hilliard wrote: For some reason pidof doesn't work on the dictd daemon, so it may not work on others as well. See Bug#67021. Then I suggest the following : ps ax | grep '[ ]'daemon-name I think the 'grep -v grep' kludge usually taught should be avoided. I usually prefer this: ps acx | grep daemon-name -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: fix for daemon start on package install/upgrade out-of-runlevel
[EMAIL PROTECTED] (Henrique M. Holschuh) wrote: ISSUE: Is there a need for pre-depends? A package which needs a future version of the initsciptquery interface would need to pre-depends: sysvinit (=someversion) | filerc (=someversion). How is this done for update-rc.d ? If you're using initscriptquery in your postinst (as more or less anyone who uses it will be?) then you only need an ordinary dependency. initscript ID - Init script unique ID, as used for update-rd.d rc.d No other comments, really - I think this will help Debian packages to follow the course of least surprise in a very useful way. I don't know if this comes under the administrative reasons which you asked us to ignore for now :), but recently I was upgrading my work box from Red Hat 6.0 to potato, and to minimize downtime I did most of the work in a chroot. Unfortunately, installing daemons in this system resulted in a lot of them breaking because non-chrooted versions of themselves were already running and (say) bound to their normal TCP ports. With initscriptquery as it stands, I would at least have a common hook which I could hack to stop any of them being started; I could perhaps have pretended I was in runlevel 1 or something. I don't doubt you'll provide a cleaner solution in your local policy RFC, but I would certainly like to see the current system implemented for woody. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#70269: automatic build fails for potato
Antti-Juhani Kaijanaho [EMAIL PROTECTED] wrote: On 2829T092919+0200, Paul Slootman wrote: Really? I doubt that the package build-essential (to name a random example :-) needs the C compiler. You misread me (or did I express my badly?). I mean that there exists at least one program such that for all Debian developers, if said Debian developer packages said program, a C compiler is needed. The same does not hold for debhelper, since all programs *can* be packaged without debhelper. I'm trying here to assert that there exists a package for which a C compiler is essential for building. This is, IMHO, a necessary (but not sufficient) condition for build-essentiality. In addition to the definition, would a useful rule of thumb in arguments about build-essentiality be that the lists of essential and build-essential packages together comprise a minimal set of packages central to the Debian system [1] among which circular build dependencies are acceptable? [1] This is a kludge; I'm trying to avoid having my description include compilers for other languages which depend on themselves to build, but which are sufficiently rarely used that making them build-essential would be foolish. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: KDE is not working!
Ivan E. Moore II [EMAIL PROTECTED] wrote: yea..grab the .deb's out of incoming...or change your /usr/bin/startkde script iout with the one I'm attaching. [...] # Link socket resource to directory in /tmp # Creates a directory /tmp/ksocket-$USER and links $KDEHOME/socket-$HOSTNAME to it. I hope that last line is merged with the one before it in the uploaded version ... Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#80384: ITP: coldsync - Palm synchronizer/conduits tool
severity 80384 fixed thanks Peter Makholm [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: Package: wnpp Serverity: normal Version: N/A I intend to package the following program if nobody is working on it all ready (couldn't find anything at bugs.debian.org/wnpp): Package: coldsync It's already in unstable: [EMAIL PROTECTED] ~]$ dpkg -p coldsync Package: coldsync Priority: extra Section: otherosfs Installed-Size: 372 Maintainer: Bradley Marshall [EMAIL PROTECTED] Architecture: i386 Version: 1.4.6-2 [...] Regards, -- Colin Watson [EMAIL PROTECTED]
Re: List of packages needing a new maintainer
Martin Michlmayr [EMAIL PROTECTED] wrote: Below is a listing of packages needing a new maintainer. Speaking of which, dome hasn't had a maintainer upload in over four years, and it could do with somebody paying a little attention to it (apart from anything else, it's Standards-Version: 2.1.1.0). Is Chris Fearnley still working on Debian? I'd ask for a sponsor to help me adopt it, but I really haven't a clue what it does, even if it looks cool. :) -- Colin Watson [EMAIL PROTECTED]
Re: ITP: water -- A graphical water effect demo.
Hamish Moffatt [EMAIL PROTECTED] wrote: On Sat, Dec 16, 2000 at 02:38:15PM +0900, Miles Bader wrote: [The suggested alternative `sdlwater' is completely wrong, since it simply adds an arbitrary implementation detail to the name -- something OK, so call it water-demo or waterdemo or something along those lines. I looked through the output of 'dpkg -l' on one of my systems and saw very few packages with plain English names. For what it's worth, about 6% of the current distribution (355 packages) match entries in /usr/share/dict/words: abacus abuse ae aegis aide aleph alien ami ammonite amor amphetamine an anarchism andrew ant apache apt aptitude archie arena ark arrow artist ascii ash asp at august ava axe ... (OK, so 'ascii' is a bit dubious.) -- Colin Watson [EMAIL PROTECTED]
Re: Bug#80929: O: shaper -- Traffic Shaper for Linux
Christoph Lameter [EMAIL PROTECTED] wrote: Package: wnpp Severity: normal The current maintainer of shaper, Christoph Lameter [EMAIL PROTECTED], has orphaned this package. If you want to be the new maintainer, please take it -- fix the outstanding bugs and upload a new version with your name in the Maintainer: field. Some information about this package: Package: shaper I'd like to take shaper (I spent a couple of months at work working on traffic shaping [1]), but I'm still waiting for my application manager to write up my application and send it to the DAM. Would anyone like to sponsor me in the meantime? If so, I'll file an ITA. [1] Linux 2.2 has a more flexible way of handling it, but the userspace tools are much more difficult to use. -- Colin Watson [EMAIL PROTECTED]
Re: DEBIAN IS LOOSING PACKAGES AND NOBODY CARES!!!
Peter Palfrader [EMAIL PROTECTED] wrote: Hi GBechly! Fancylogin is reported to be in unstable and there also is a package page, but the package is not found from the download page and is also not present in any of the mirrors. marvin:~# apt-get install fancylogin Reading Package Lists... Done Building Dependency Tree... Done Package fancylogin has no available version, but exists in the database. This typically means that the package was mentioned in a dependency and never uploaded, has been obsoleted or is not available with the contents of sources.list However the following packages replace it: francine E: Package fancylogin has no installation candidate IIRC the upstream maintainer asked the Debian maintainer to remove the package (I don't know why - some sort of dispute?), so the Debian maintainer forked and called the new package francine. -- Colin Watson [EMAIL PROTECTED]
Re: autodetecting MBR location
Bart Schuller [EMAIL PROTECTED] wrote: On Tue, Jan 02, 2001 at 02:24:22PM +0100, Tollef Fog Heen wrote: | s/[0-9]*// | s/part$/disc/ What is the use of the first s/? Unless your first letter is a digit, it will just remove the zero-width string '' between the first / and the beginning of the string. A better solution will probably be to s/[0-9]$// which will remove 5 from /dev/hda5. You seem to know that $ and ^ anchor a match to the end or the beginning of a string. So you should also know that in the absence of one of these characters, the match may start anywhere in the string. So the statement works fine as it is. That's not true; try it. [EMAIL PROTECTED] ~]$ echo /dev/hda1 | perl -pe 's/[0-9]*//' /dev/hda1 [EMAIL PROTECTED] ~]$ echo /dev/hda1 | perl -pe 's/[0-9]+//' /dev/hda Contrary to the subconscious assumption many people make, the first priority for a regex is to match earliest, not to match longest. regex(7) specifically mentions this: In the event that an RE could match more than one sub- string of a given string, the RE matches the one starting earliest in the string. If the RE could match more than one substring starting at that point, it matches the longest. However, stylistically s/[0-9]*// is better written as s/[0-9]+// because the case where no digits match is better classified as not a match. True; even s/\d+// or s/\d+$// (assuming that the partition numbers are always at the end, even in devfs - I'm not familiar with that). -- Colin Watson [EMAIL PROTECTED]
Re: lynx 2.8.4dev.16 --with-ssl
Christoph Martin [EMAIL PROTECTED] wrote: Since ssl support (configure --with-ssl) is now integrated in the main lynx source, will lynx-ssl be obsolete? And will lynx has to go to non-US? Or do we still need separate version? Since lynx is GPLed, surely we shouldn't be linking it to OpenSSL at all? :( (Unless there's an exception I'm not aware of ...) -- Colin Watson [EMAIL PROTECTED]
POSIX regular expressions (was: autodetecting MBR location)
Tollef Fog Heen [EMAIL PROTECTED] wrote: * (Colin Watson) | Contrary to the subconscious assumption many people make, the first | priority for a regex is to match earliest, not to match longest. | regex(7) specifically mentions this: For a non-POSIX regex, that is. Could you point me to some documentation about this? regex(7) claims to describe POSIX 1003.2 regular expressions, and describes leftmost-first behaviour. regcomp(3) claims to describe POSIX regex compilation and execution, and refers to regex(7) and the GNU regex manual for further documentation. The GNU regex manual (assuming this means the documentation in librx1g-dev) is ambiguous: it says In every case like this, the longer match is preferred, but the example it gives is one of alternative subexpressions rather than an earliest vs. longest issue. Furthermore, a brief test program produces output consistent with earliest matches against both libc6 and librx1g, both of which claim to provide POSIX regex engines. So is there no correct POSIX regex library in Debian? Thanks, -- Colin Watson [EMAIL PROTECTED]
Re: bugs + rant + constructive criticism (long)
Peter Palfrader [EMAIL PROTECTED] wrote: On Wed, 03 Jan 2001, Branden Robinson wrote: But there is also this, which *is* standard[1], and which I also have: Mail-Copies-To: never So not only are people stupid, but their MUA's are as well. Mutt is broken too wrt Mail-Copies-To and shorty already asked on mutt-dev for it to be supported. IIRC they were not too excited about it tho. Branden, you should also set Mail-Followup-To headers. mutt does this for you if you set followup_to and declare this list as subscribed subscribe debian-devel. From: Branden Robinson [EMAIL PROTECTED] To: debian-devel@lists.debian.org Subject: Re: bugs + rant + constructive criticism (long) Message-ID: [EMAIL PROTECTED] Mail-Followup-To: debian-devel@lists.debian.org -- Colin Watson [EMAIL PROTECTED]
Re: bugs + rant + constructive criticism (long)
Peter Palfrader [EMAIL PROTECTED] wrote: On Wed, 03 Jan 2001, Colin Watson wrote: From: Branden Robinson [EMAIL PROTECTED] Mail-Followup-To: debian-devel@lists.debian.org ARGL, /me should really get glasses or whatever. Any reason you ignored my MailFup2 header? D'oh. All things considered, I really ought to sort out my trn4 configuration ... Bowing out of this now :), -- Colin Watson [EMAIL PROTECTED]
Re: our broken man package
Ethan Benson [EMAIL PROTECTED] wrote: On Wed, Jan 03, 2001 at 11:53:37PM -0800, Joey Hess wrote: I'll bet (have not verified) that you can already trick it into writing bogus file by sticking trojan pages elsewhere in your manpath. i just tried it, did not end up with a cached file. [EMAIL PROTECTED] eb]$ export MANPATH=/home/eb/test [EMAIL PROTECTED] eb]$ find /var/cache/man -name 'bogus*' [EMAIL PROTECTED] eb]$ ls -l /home/eb/test/man8/ total 8 -rw-r--r--1 eb eb 5193 Jan 3 23:03 bogus.8 [EMAIL PROTECTED] eb]$ man bogus Reformatting bogus(8), please wait... ... [EMAIL PROTECTED] eb]$ find /var/cache/man -name 'bogus*' Yes, there's no MANDB_MAP entry in /etc/manpath.config for /home/eb/test. 'MANPATH=/home/eb/test manpath -c' will tell you the catpath corresponding to a given manpath. I don't know if it's possible to subvert this. -- Colin Watson [EMAIL PROTECTED]
Re: Release-critical Bugreport for January 5, 2001
Branden Robinson [EMAIL PROTECTED] wrote: On Fri, Jan 05, 2001 at 06:00:08AM -0600, BugScan reporter wrote: Bug stamp-out list for Jan 5 05:13 (CST) Total number of release-critical bugs: 482 I thought aj introduced the serious severity so that important bugs wouldn't be considered release-critical anymore, but it looks like bugscan doesn't know that important bugs aren't RC. I notice that some porters are still filing can't build from source bugs as 'important'; I realize the developers-reference package hasn't been updated yet, although the version in CVS has. A lot of such 'important' bugs are going to need to be upgraded to 'serious'. -- Colin Watson [EMAIL PROTECTED]
Re: tar -I incompatibility
Scott Ellis [EMAIL PROTECTED] wrote: Of course the -I option to tar was completely non-standard. The changelog explains why it changed, to be consistant with Solaris tar. I don't see the reasoning in the changelog, but I may just have missed it. I'd prefer portability and consistancy any day, it shouldn't take that long to change any custom scripts you have. Why not have portability, consistency, *and* backward compatibility? Make -I an alias for -j, problem solved. Unless Solaris tar has -I as an alias for -T - I suppose it must, as I can't think of any reason for such a blatantly incompatible change. I always use long options for nonstandard commands when building scripts anyway :) All the upstream tar people are doing is encouraging people to go back to 'bzip2 -dc foo.tar.bz2 | tar xvf -', I think. And, hell, if you want to be portable across Unixes you have to do that anyway. -- Colin Watson [EMAIL PROTECTED]
Re: LILO 21.6-2
Russell Coker [EMAIL PROTECTED] wrote: On Sunday 07 January 2001 00:46, Adam Heath wrote: On Sun, 7 Jan 2001, Hamish Moffatt wrote: Also, [EMAIL PROTECTED] would really be better than a specific address. Not if he isn't the current maintainer of lilo. True. So how do I get registered as the maintainer? You are: [EMAIL PROTECTED] ~]$ grep '^lilo ' Maintainers lilo Russell Coker [EMAIL PROTECTED] Maybe the same thing happened to you as to me with shaper; it took until the next dinstall run for the BTS to get up to date, so perhaps there was some transient problem. See the sequence of events in #81327. -- Colin Watson [EMAIL PROTECTED]
Re: What is wrong with kde2.1 and unstable ?
[EMAIL PROTECTED] wrote: as of three days ago, every attempt to do a dist-upgrade tries to uninstall almost every kde package. What is wrong there. Use dselect or some apt frontend to find out what the conflicts are or what dependencies are missing. It's easier for you to do this work yourself than for debian-devel subscribers to try to work it out at a distance. -- Colin Watson [EMAIL PROTECTED]
Fatal problems with dpkg-dpkg-deb communication in 1.8.1
When I installed dpkg 1.8.1 at work a few hours ago I couldn't install any packages with it; while unpacking, it got EAGAIN when trying to read from its pipe to dpkg-deb, and then segfaulted. This was in lib/mlib.c:buffer_read() and lib/mlib.c:buffer_copy() at least, which at the moment tolerate EINTR but not EAGAIN. In the end I had to manually extract dpkg_1.7.2_i386.deb in the root directory and then reinstall dpkg 1.7.2 properly to get everything working again. This was on a machine being upgraded from potato to sid; the new libc6 had already been installed. It's running a 2.2.5 kernel at the moment, and runs dpkg 1.8.0 with no problems. Sorry I can't provide an strace right now, but I forgot to mail it to myself from work; if nobody else has seen this already then I'll file a proper bug report on Monday. Did somebody do something involving non-blocking file descriptors in 1.8.1? -- Colin Watson [EMAIL PROTECTED]
Re: Bug#81396: root shell fscked after upgrade to woody
Paul Slootman [EMAIL PROTECTED] wrote: On Sun 07 Jan 2001, Eray Ozkural wrote: About having telnet enabled: everybody on the campus knows how to use telnet but would be very surprised I didn't let them connect easily from windows clients. For me, using telnet is of course a bit insecure but when I'm not able to use an ssh client... it's easier. Search google for putty, if you need an ssh client for windows. http://www.chiark.greenend.org.uk/~sgtatham/putty/ (hmm, I appear to have that memorized - I end up grabbing it any time I'm at a public Windows-based Internet terminal). For what it's worth, I discovered entirely by accident that if you install telnetd-ssl then the telnet client in Windows 98 and above will connect to it and seamlessly do SSL negotiation, while of course non-SSL-capable telnet clients will still be able to connect insecurely. -- Colin Watson [EMAIL PROTECTED]
Re: RFDisscusion: Big Packages.gz and Statistics and Comparing solution
Goswin Brederlow [EMAIL PROTECTED] wrote: Also think of the benefit when updating. With some extra code on the client side (for example in apt) a pseudo deb can be created from the installed version and then rsynced against the new version. Coo, yes, and you don't even need that much extra code: check in /var/cache/apt/archives, and otherwise dpkg-repack. That would be nice. -- Colin Watson [EMAIL PROTECTED]
Re: Developer Behavior
Vince Mulhollon [EMAIL PROTECTED] wrote: Now that you and Eray have publically complained about the team's slowness, that means that after you complete the NM process, you both be joining the NM team to help your fellow developers get processed quicker, right? I'm not being sarcastic, my initial account manager who did the interviews and stuff had just completed the process a few months ago, so I assume you'll be joining the new maintainer team just like he did. I certainly intend to volunteer; I've had two AMs so far and extremely long delays with both of them, and would like to help get other people through a little more quickly than that. -- Colin Watson [EMAIL PROTECTED]
Re: FYI: dh_upx compresses i386 executables
Alexander Hvostov [EMAIL PROTECTED] wrote: Since UPX only runs when a program is loaded, and only takes a few seconds to do its thing, I see no reason why weaker (eg, 486) machines couldn't handle it. Even on old 386 machines, the slowdown shouldn't be much of a headache, unless what's being compressed is a very frequently executed program (like `ls'), in which case it'd be better not to UPX it. In any event, UPX shouldn't matter to people with fast machines (who have plenty of disk space and plenty of CPU power), and would benefit people with small disk drives (who can probably live with the small load time delay). For these reasons, I agree with the sentiment that UPX should be used on almost all (if not all) executables shipped with Debian. The reliability aspects (executables suddenly start failing if you temporarily run out of hard disk space in /tmp or wherever) would be a killer for me. (Given this, compressing /bin/rm would be extremely foolish. :)) Incidentally, I assume the temporarily decompressed executables created by UPX are mode 700? -- Colin Watson [EMAIL PROTECTED]
Re: Cryptic messages from installers
Filip Van Raemdonck [EMAIL PROTECTED] wrote: On Wed, Apr 18, 2001 at 11:35:42PM +0100, James Troup wrote: For a real world example: buildd uploads are signed by real maintainers but they do _not_ want either the upload queue or katie to mail them about the uploads; that mail needs to go to the Maintainer: field, i.e. the buildd so it can be processed. I thought the Changed-By: field was meant for the porters? No, Changed-By: is always the person who made the most recent changelog entry, for the benefit of NMUs. -- Colin Watson [EMAIL PROTECTED]
Re: Why does typing navigator run mozilla?
Alexander Hvostov [EMAIL PROTECTED] wrote: On Mon, 23 Apr 2001 14:52:00 -0400 Timothy H. Keitt [EMAIL PROTECTED] wrote: What's next? A talking paper-clip pops up when I type xterm? :-) Remember `vigor'? Please, please, PLEASE don't give anyone any ideas... Erm, I have a package of that lying around somewhere, although I haven't dared to upload it to Debian yet. :) -- Colin Watson [EMAIL PROTECTED]
Re: Why does typing navigator run mozilla?
Wichert Akkerman [EMAIL PROTECTED] wrote: Previously Colin Watson wrote: Erm, I have a package of that lying around somewhere, although I haven't dared to upload it to Debian yet. :) http://vim.sourceforge.net/vimgor/ fear. Wouldn't that be less painful than the original nvi-based one? -- Colin Watson [EMAIL PROTECTED]
Re: XFree 4.0.3 used by some debian developers and their sid packages depend on it (but not available)
John Goerzen [EMAIL PROTECTED] wrote: ARRGHH!!! It really ticks me off when someone: 1. NMU's one of my packages for a *normal* bug without even thinking of checking with me first, and 2. In so doing, manages to BREAK THE PACKAGE and give it a GRAVE BUG and 3. Doesn't bother to fix this bug, creating more work for me than if he had just asked me in the first place. There seems to be a rash of this going on lately. I'm not pleased. Marcelo Magallon, I'm talking to you! How ironic ... http://lists.debian.org/debian-devel-0104/msg00089.html -- Colin Watson [EMAIL PROTECTED]
Re: FYI: dh_upx compresses i386 executables
Ethan Benson [EMAIL PROTECTED] wrote: On Sun, Apr 22, 2001 at 09:00:13AM -0400, Itai Zukerman wrote: you want. The postinst code would call the compression routines, which might not do anything, depending on how the compressing package was configured (i.e., it wouldn't call the compressing code directly, but through a wrapper). makes sense Not if UPX were to be an option for all binaries. Having to add stuff to every package's postinst is evil (see /usr/doc, although that was necessary). -- Colin Watson [EMAIL PROTECTED]
Re: Packages not making it into testing
Anthony Towns aj@azure.humbug.org.au wrote: The following packages haven't been uploaded this year, and also haven't made it into testing for a while. If people could go through and make sure the maintainer knows about the issues, or do NMUs as appropriate, or work out what the problem actually is, or similar, that'd be pretty cool. There's a fair few doesn't build on sparc bugs (compared to any other architecture). This is for two reasons: one, alpha and i386 have a lot fewer such problems; and two, I'm ignoring arm, m68k and powerpc problems of that nature, although arm's actually doing pretty well too. Also because sparc and others don't autobuild contrib/non-free. I'm willing to bet that a fair amount of manual attention might be needed there, as problems in non-free can sometimes cause problems in main (see libdnd not being removable from testing because xzx depends on it on alpha, for example - possibly just a bad build environment). + lgrind uploaded 125 days ago, out of date by 115 days! doesn't build on sparc, no bug filed When I tried to build it it had an ugly build process that caused a file to be installed outside the build tree, so I didn't upload it (#90767). Incidentally, could I request one change to the format of update_output.txt that would make problems in testing easier to debug (unless there's some other set of information I don't know about)? I'd like to see the reports of uninstallability for each package mention all architectures, to help distinguish between problems on one or two architectures and problems on everything. The last time I looked they just showed the lexically first architecture that was causing problems, so for a while I was scratching my head and wondering why does alpha have so many problems?. -- Colin Watson [EMAIL PROTECTED]
Re: ITH (Intent To Hijack) pilot-manager
Michael Piefel [EMAIL PROTECTED] wrote: Am 2.05.01 um 12:36:45 schrieb Adrian Bunk: Martin usually marks packages of MIA maintainers as orphaned. I think it's better if a few persons take care of this instead of many more people sending ITHs. Though I'm not absolutely sure about his criteria. Mailing the previous maintainer once or twice should be part of the process; this makes it quite a lot of work and bookkeeping. Martin does indeed mail maintainers several times before resorting to marking unmaintained packages as orphaned. -- Colin Watson [EMAIL PROTECTED]
Bug#110959: ITA: doc-linux -- Linux HOWTOs, mini-HOWTOs, and FAQs
Package: wnpp Severity: normal Martin Michlmayr orphaned Marco Budde's packages today, as they don't appear to have been actively maintained for quite some time. I intend to adopt doc-linux (binary packages doc-linux-html and doc-linux-text), which is pretty seriously in need of an update before woody is released. I'm cc'ing this to -devel as doc-linux-text is Priority: standard. -- Colin Watson [EMAIL PROTECTED]
Re: ddts: notification about fr-translation of the libroxen-{roxpoll-doc|linkif|presentit}
On Sun, Sep 02, 2001 at 02:22:16PM +0200, Turbo Fredriksson wrote: I'm all for international descriptions. In roxen and roxen2 packages for debconf, I have a number of languages. But philippe, if you're to translate, then you have more job to do. You have 55 packages to translate! (just joking, don't take it the way it reads philippe, I _AM_ gratefull! :) Can I get more language translating, I'll upload asap. I didn't think package maintainers were supposed to upload packages with the translated descriptions? -- Colin Watson [EMAIL PROTECTED]
Re: probably FAQ: Uploading to sid with potato's dupload?
On Sun, Sep 02, 2001 at 10:01:50PM +0200, Marc Haber wrote: Hi, this might be an FAQ; but for security, I'll ask as well: I do my development in a sid chroot on potato. Can I use potato's dupload to upload the finished packages, or do I need to copy my keys into the chroot to be able to use sid's dupload? You can safely try it and find out. I think the only thing to note about potato's dupload is that you have to add ftp-master to /etc/dupload.conf (or ~/.dupload.conf) manually. -- Colin Watson [EMAIL PROTECTED]
Re: Error upgrading to woody: mv: cannot create file `/etc/exim/exim.conf'
(Mail-Followup-To: set to -user only. I'd also appreciate not being directly cc'ed on your questions; I read both -user and -devel, so I got three copies of this!) On Mon, Sep 03, 2001 at 11:01:56PM -0700, tluxt wrote: In fact, the directory: /etc/exim does not exist. You can create it yourself, as a workaround for now. In my /v/c/a/a I have: @debian:/var/cache/apt/archives$ ls -al exim* -rwxr-xr-x1 root root 650710 Jun 9 19:45 exim_3.12-10.1_i386.deb -rwxr-xr-x1 root root 650572 May 2 2000 exim_3.12-10_i386.deb -rwxr-xr-x1 root root 746472 Apr 11 17:28 exim_3.22-4_i386.deb -rwxr-xr-x1 root root 747228 Jul 18 16:50 exim_3.31-1_i386.deb -rwxr-xr-x1 root root 748988 Aug 14 17:30 exim_3.32-2_i386.deb @debian:/mnt/hda11/var/cache/apt/archives$ My Question: I don't know enough about Debian to know if this is a bug - would you please enlighten me? The msg from CW said, on 8/14, that exim 3.32-1 fixes this. I have exim 3.32-2 in my cache. You must have got that manually, or when apt was temporarily pointing at unstable. apt uses whatever's in its package list, not necessarily the contents of the cache. Q: Since it is over 2 weeks past 8/14, shouldn't my dist-upgrade be using 3.32, which, presumably, has this bug fixed? It's not that simple. Testing is not just two weeks behind unstable; the algorithm is a lot more complex than that, and is more like: * Look at the 'urgency' field of the new package. low = 10 days, medium = 5 days, high = 2 days, critical = 0 days. Wait that long before doing anything else. If a new version of the package is uploaded in the meantime, the count is reset. * Do all architectures in woody have the same version of the package compiled for them? If not, give up. * Does the version in sid have more release-critical bugs than the version in woody? If so, give up. * Experimentally upgrade the package in woody, together with all packages that come from the same source package. After doing this, does the number of packages that can't be installed at all in woody due to broken dependencies go down, or at least stay the same? If so, it's OK to upgrade the package. If not, the package has to wait. I'm sure you can see now that you can't just say wait two weeks, then it should be in testing. For the status of any individual package (plus some explanation), you can look at http://ftp-master.debian.org/testing/. Some of it's a bit cryptic, and you have to do more digging to find out exactly what's going on sometimes, but it's there. In the case of exim, update_excuses.html says: * exim 3.32-2 (currently 3.31-1) (important) (low) + Maintainer: Mark Baker [EMAIL PROTECTED] + exim uploaded 19 days ago, out of date by 9 days! + valid candidate (will be installed unless it's dependent upon other buggy pkgs) OK, so the first three steps above are passed. For the last, look at update_output.txt, which says, down near the end: exim: alpha: eximon This means that exim can't be upgraded because the eximon package would be uninstallable on alpha if it did. Doing some more investigation, this is because eximon depends on XFree86 4.1.0 on alpha, which hasn't got into testing yet. However, it should be there in two days, if nothing goes wrong in the meantime: * xfree86 4.1.0-4 (currently 4.0.3-4) (optional) (medium) + Maintainer: Branden Robinson [EMAIL PROTECTED] + only 3/5 days old + not considered At that point, exim should be upgraded too, unless there are other problems. Also, if this _is_ a bug that's not submitted yet, I don't know enough yet about the bug tracking system, etc., to properly submit this. So, I hope _you_, dear reader, will submit this bug to the system, if it is indeed a current, non-submitted bug. It's not a bug there's any point reporting. All that the exim maintainer can do about it is refrain from uploading anything for two days; package maintainers don't get to influence what's in testing directly. Anybody else will tell you to wait for the testing bot to synchronize things. Tracking bugs in the various distributions of Debian (potato, woody, and sid) is an outstanding general problem. We have a crude system of tags which helps a little, but really the best we can do is try to ensure that the testing and unstable distributions are as close to each other as possible. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: e2fsprogs as an essential package
On Wed, Sep 05, 2001 at 10:23:52PM +0800, [EMAIL PROTECTED] wrote: with reiserfs etc. shall we downgrade debian package e2fsprogs' essential state to at least to allow it to be removable? thanks! (one thing to notice is maybe the generic fsck wrapper?) Perhaps it would make sense to put /sbin/fsck in its own small essential package and have it depend on fsck-backend, which *fsprogs can provide. fsck does link against libext2fs, though ... it uses ext2fs_find_block_device() to get around a devfs problem. That function doesn't seem inherently ext2-specific. -- Colin Watson [EMAIL PROTECTED]
Re: How to fetch proper source for libc
On Sun, Dec 01, 2002 at 04:53:51PM -0800, Marc Singer wrote: On Mon, Dec 02, 2002 at 12:02:01AM +, Colin Watson wrote: On Sun, Dec 01, 2002 at 02:39:48PM -0800, Marc Singer wrote: I'm tracking a memory leak that appears to stem from regexec(). Hmm. What makes you think that this patch fixes a memory leak? I ask because the patch appears to deal with 16-bit characters. The crucial bit is the movement of the assignment to pstr-tip_context to inside the (offset pstr-valid_len) test; that assignment was where the crash happened, and when I gdb'ed into it the test indeed wouldn't have passed. (I say crash, while you say memory leak; the crash was intermittent enough and bothered valgrind enough that I'm guessing it could have been a memory leak under other circumstances. No, I have no particular proof of this, but it might be worth your while trying it out.) -- Colin Watson [EMAIL PROTECTED]
Re: Fwd: Please confirm your message
On Tue, Dec 03, 2002 at 08:56:10AM -0800, Adam McKenna wrote: On Mon, Dec 02, 2002 at 11:49:09PM +0100, Andreas Fuchs wrote: Thus, my conclusion: These things are evil. Don't use them or somebody might use them against you, eventually. This sounds vaguely like religion -- you haven't even taken the time to see how these filters work yet you are decrying them as evil. They happen to be the most effective filtering solution at present, /dev/null is the most effective filtering solution at present, and these days happens to be equivalent to these filters when applied to mail from me. It's easy to be effective if you don't care about false positives. -- Colin Watson [EMAIL PROTECTED]
Re: Fwd: Please confirm your message
On Tue, Dec 03, 2002 at 09:26:34AM -0800, Adam McKenna wrote: On Tue, Dec 03, 2002 at 05:13:42PM +, Colin Watson wrote: /dev/null is the most effective filtering solution at present, and these days happens to be equivalent to these filters when applied to mail from me. It's easy to be effective if you don't care about false positives. Yes, and unless you consider people who either: 1) are too lazy to confirm 2) have a philosophical objection to confirming false positives, I do. If you don't, I guess we have no common ground. Also consider systems like the BTS that send mail; I certainly don't think those confirmations get religiously replied to, although boredom might lead to somebody doing it on occasion. You're also assuming that the users of such systems don't periodically check out their pending queue to make sure there isn't any legitimate mail in there before purging it. Fair point. -- Colin Watson [EMAIL PROTECTED]
Re: Fwd: Please confirm your message
On Tue, Dec 03, 2002 at 09:55:34AM -0800, Adam McKenna wrote: BTW, anyone who e-mails you and then asks you to confirm your reply is either using broken software, or doesn't have their outgoing mail headers set up properly. So people who e-mail [EMAIL PROTECTED] and then ask for confirmation from [EMAIL PROTECTED] must be using broken software too, I guess. Similarly, people don't always use one of my canonical addresses. -- Colin Watson [EMAIL PROTECTED]
Re: why was there no bug filed?
On Wed, Dec 04, 2002 at 10:56:44AM +0100, martin f krafft wrote: speaks for itself. i didn't notice in months... http://buildd.debian.org/build.php?arch=armpkg=gradmver=1.5a-1 http://bugs.debian.org/gradm It's easier to notice these things in a timely fashion if you put 'grep-excuses your name' (or just 'grep-excuses' with GREP_EXCUSES_MAINTAINER='your name' in ~/.devscripts) in your crontab. -- Colin Watson [EMAIL PROTECTED]
Re: why was there no bug filed?
On Wed, Dec 04, 2002 at 01:34:07PM +0100, martin f krafft wrote: also sprach Colin Watson [EMAIL PROTECTED] [2002.12.04.1319 +0100]: It's easier to notice these things in a timely fashion if you put 'grep-excuses your name' (or just 'grep-excuses' with GREP_EXCUSES_MAINTAINER='your name' in ~/.devscripts) in your crontab. nice! still doesn't explain why the bug wasn't reported, does it? I'd be extremely surprised if the explanation wasn't something along the lines of we didn't get round to it or something more important came up. Humans, not automatic systems, file bugs. -- Colin Watson [EMAIL PROTECTED]
Re: package not entering testing
On Wed, Dec 04, 2002 at 01:38:08PM +0100, martin f krafft wrote: also sprach Joerg Jaspert [EMAIL PROTECTED] [2002.12.04.1331 +0100]: Testing scripts are dead since some time. okay, so no package will make it to testing in the mean time??? Correct. Also, multiple punctuation marks are a sign of insanity. ;-) -- Colin Watson [EMAIL PROTECTED]
Re: description writing guide
On Wed, Dec 04, 2002 at 07:19:38PM +, Scott James Remnant wrote: If you are writing text in something that uses variable width fonts, the program should know about English grammar and render the wider space itself on any whitespace. (LaTeX is about the only thing that gets it right though). *roff also does, provided that you start each sentence on a new line (to allow it to distinguish between full stops for abbreviations and full stops at the end of sentences). Thus it's good style for man pages to be written like this rather than wrapping the start of one sentence onto the same line as the end of the last: There are several common reasons why whatis parsing fails. Sometimes authors of manual pages replace \(oq.SH NAME\(cq with \(oq.SH MYPROGRAM\(cq, and then .B mandb cannot find the section from which to extract the information it needs. Sometimes authors include a NAME section, but place free-form text there rather than \(oqname \e\- description\(cq. However, any syntax resembling the above should be accepted. -- Colin Watson [EMAIL PROTECTED]
Re: description writing guide
On Thu, Dec 05, 2002 at 02:49:12PM -0800, Thomas Bushnell, BSG wrote: Steve Greenland [EMAIL PROTECTED] writes: However, this is all on *output* (display, whatever). The input text should have just a single space. The text has to be reformatted to fit the screen (display area) anyway (even on a terminal), and it's the job of the reformatter/text renderer/whatever to get it right. It is not possible for an automated renderer to figure out where sentence boundaries are without some kind of help, and a mere period is not sufficient help. So, a good convention to establish might be that the string . indicates the end of a sentence, and . does not. I think *roff's trick of put a line break after the full stop at the end of a sentence would be better. That way current frontends don't have to change (normal word-wrapping will sort it out) unless they take the decision that their output looks better with two spaces, at which point it's trivial to do so. (Easy things should be easy, and hard things possible.) -- Colin Watson [EMAIL PROTECTED]
Re: bill gates Linux
On Fri, Dec 06, 2002 at 03:07:17AM -0800, [EMAIL PROTECTED] wrote: The response I got to a simple request for an DOS or Windows based SETUP.EXE program which loads Linux onto my hard drive, would lead me to thick I was asking for the combination to Fort Knox. No, it's because you've misunderstood the nature of the problem. You have to reboot anyway to switch operating systems; there's vanishingly little point in us making the installation system run in Windows, where we can't easily reuse all the work we've done on producing a free operating system. We have enough to do building a standalone installer without trying to write code for a non-free operating system, one with whose innards the majority of our developers aren't familiar - and installation systems involve some fairly tricky code. It's simply not a useful thing to do. Just boot into the normal installer (or, if you find it too painful, use something like the Progeny installer where more work has been done on making it newbie-friendly). The Linux kernal can't be so foreign a language that it can be copied ??? All code that the computer uses must come from a bios chip or the hard drive not from outer space. I am trying to avoid the problem which I have of needing a degree in Rocket Science to even see anything on my computer which originates from the blessed Linus kernal. Who in this world can actually read hexadecimal code anyway. Who tries? The Linux kernel isn't directly written in hexadecimal, you know; people have better things to do than write machine code directly. -- Colin Watson [EMAIL PROTECTED]
Re: Porting Xconfigurator to Debian!
On Fri, Dec 06, 2002 at 08:19:43PM +, Michelle Konzack wrote: Am 10:00 2002-12-05 +0100 hat Josselin Mouette geschrieben: The configure script is usually launched before the Pre-Depends are even installed. There is currently no way to ensure a package is installed at configuration time. This is realy bizzar !!! Not really. How do you do preconfiguration otherwise? How can you configure a package which need pre-depends ? You don't. You can only use essential packages in a .config script. -- Colin Watson [EMAIL PROTECTED]
Re: started to make changelogs and copyright file online available
On Sun, Dec 08, 2002 at 03:33:10PM +0100, No?l K?the wrote: I started to make the changelog and copyright file of the Debian packages online available at: http://changelogs.credativ.org/ We should be able to start using the lintian lab on gluck for this again now that lintian is running regularly, shouldn't we? -- Colin Watson [EMAIL PROTECTED]
Re: project: vitual partial mirror with CGI/dpkg-repack
On Sun, Dec 08, 2002 at 09:26:55PM +0100, Wouter Verhelst wrote: On Sun, Dec 08, 2002 at 05:30:13PM +0100, Bill Allombert wrote: I will not do it myself since I know nothing about CGI programming, CGI programming is easy to learn ;-) CGI scripts or programs get whatever the client sends on his URL, starting after the '?' as a parameter, Not as a parameter - in the QUERY_STRING environment variable. http://hoohoo.ncsa.uiuc.edu/cgi/interface.html and send the HTML and, if necessary, extra HTTP headers to their stdout. They do need to output at least some HTTP headers, often just Content-Type: foo/bar\n\n. -- Colin Watson [EMAIL PROTECTED]
Re: WNPP pages are now over one month out of date.
On Tue, Dec 10, 2002 at 03:24:02AM +1100, Andrew Lau wrote: I just remembered that the WNPP www pages [1] have been stale for one month and one day now. Their last update was on November 9, and no one has yet looked into bug #171393: WNPP pages are severely out of date. Update mechanism broken? which I also filed. Anyone know what the current situation is? I had a quick look at wml_run.log, and there were a few complaints about very badly formatted wnpp bug titles. I've fixed those, so maybe that will improve matters. Looking at the code, wnpp.pl is supposed to avoid printing those messages to stderr when the host is klecker.debian.org, but this fails for some reason. Assuming my fix solves it, somebody needs to look into that to stop it happening in future. -- Colin Watson [EMAIL PROTECTED]
Re: Missing fields in control files
On Mon, Dec 09, 2002 at 12:34:27PM -0600, J.E. Starr wrote: After using debarchiver, for the first time, yesterday, I noticed 5 deb's didn't get placed in the archive. I unpacked the deb's and found they didn't have a section or priority field in the control file. My question is, is this a bug? It's not mandatory, although most new packages have it for convenience. I'd cal it a wishlist. -- Colin Watson [EMAIL PROTECTED]
Re: recursive build-depends or similar
On Tue, Dec 10, 2002 at 05:54:12PM +0100, Tomas Pospisek's Mailing Lists wrote: Mailsync depends on libc-client which can be compiled one way or another including or excluding ssl, kerberos etc. It happens that libc-client in woody did not include kerberos but libc-client in sid does. Is there a way to specify this in the build dependecies? Right know I have to decide if I want to make mailsync buildable on woody or on sid. I wouldn't mind if it could build on both. Is something like this possible: Build-Depends: libc-client-ssl2001-dev | ( libc-client2002-dev, libssl-dev, libkrb5-dev ) Apply Boolean algebra to that and you get: Build-Depends: libc-client2002-dev | libc-client-ssl2001-dev, libssl-dev | libc-client-ssl2001-dev, libkrb5-dev | libc-client-ssl2001-dev A bit messy, but it should work. Note that buildds don't understand |, but buildds won't be building the newer version on woody anyway. Just remember to put the version needed for sid first in each alternative. OTOH - couldn't the build system figure that out for itself - that is check libc-client2002(-dev) and find out that it depends on libkrb5-dev and make sure it's installed before building the package? The buildds just do 'apt-get install libc-client2002-dev', so dependencies of build-dependencies are processed (but not build-dependencies of build-dependencies). That should reduce the above to either: Build-Depends: libc-client2002-dev | libc-client-ssl2001-dev ... or: Build-Depends: libc-client2002-dev | libc-client-ssl2001-dev, libkrb5-dev | libc-client-ssl2001-dev (If libc-client2002-dev needs libkrb5-dev, shouldn't it depend on it? Or is it only for certain specialized cases?) -- Colin Watson [EMAIL PROTECTED]
Re: Jeff Sheinberg and the BTS
On Tue, Dec 10, 2002 at 01:14:22PM -0500, Branden Robinson wrote: Would someone care to tell Mr. Sheinberg about the new submitter feature? I did, before his e-mail address started bouncing. -- Colin Watson [EMAIL PROTECTED]
Re: installing package twice only differing in debian version
On Thu, Apr 10, 2003 at 10:13:58AM +0200, Andreas Metzler wrote: Jeremy Jackson [EMAIL PROTECTED] wrote: Is this supported? Suppose the files between revs are named not to conflict. It would be nice to be able to install a new version of a critical package, leaving the old one around while testing so you can fall back to it, then later remove the old one. The kernel and postgresql come to mind. No, dpkg does not supported this (and imho shouldn't, because the added complexity is not worth the minimal gain. - How many packages with differ only in the version number contain no commom files?) None, due to /usr/share/doc/package/copyright and changelog.Debian.gz. -- Colin Watson [EMAIL PROTECTED]
Re: Debian for x86-64 (AMD Opteron)
On Thu, Apr 10, 2003 at 12:39:25PM +0200, Cyrille Chepelov wrote: Le Thu, Apr 10, 2003, ? 10:40:47AM +0100, Hamish Marson a ?crit: I'm not sure how your logic works out that a 64 bit reg is going to be faster than a 32bit one. Or do you mean simply you're expecting a speedu because there are MORE 64 bit registers tahn 32 bit registers? Reg pressure is pretty bad on x86; and int is still 32 bit on x86-64 (IIRC, long is 64 bit and of course any T* ). So yes, anything which plays with pointers will be larger on x86-64, but it's not an automatic doubling in size of everything. And mapping libraries twice also eats a good deal of memory. OTOH, 16 general-purpose 8,16,32 or 64-bit registers (not even counting a large SSE2 register file as well) should help gcc feel more at home (especially with less code dedicated to handling register-memory swap-outs) I don't have numbers to back either choice, but it looks to me that a mixed userland with everything duplicated should be a last resort. And I'm sure some people have numbers out these. Based on the numbers I've seen, the factors mentioned seem to balance each other out fairly well. I'm not (yet) allowed to talk about the details though ... -- Colin Watson [EMAIL PROTECTED]
Re: Debian for x86-64 (AMD Opteron)
On Thu, Apr 10, 2003 at 12:43:38PM +0100, Colin Watson wrote: On Thu, Apr 10, 2003 at 12:39:25PM +0200, Cyrille Chepelov wrote: Reg pressure is pretty bad on x86; and int is still 32 bit on x86-64 (IIRC, long is 64 bit and of course any T* ). So yes, anything which plays with pointers will be larger on x86-64, but it's not an automatic doubling in size of everything. And mapping libraries twice also eats a good deal of memory. OTOH, 16 general-purpose 8,16,32 or 64-bit registers (not even counting a large SSE2 register file as well) should help gcc feel more at home (especially with less code dedicated to handling register-memory swap-outs) I don't have numbers to back either choice, but it looks to me that a mixed userland with everything duplicated should be a last resort. And I'm sure some people have numbers out these. Based on the numbers I've seen, the factors mentioned seem to balance each other out fairly well. I'm not (yet) allowed to talk about the details though ... (And what I mean by this is that the x86-64 seems to have bloody good 32-bit performance, not poor 64-bit performance. :)) -- Colin Watson [EMAIL PROTECTED]
Re: Release-critical Bugreport for April 4, 2003
On Fri, Apr 11, 2003 at 09:06:29AM +0200, Andreas Tille wrote: On Fri, 4 Apr 2003, BugScan reporter wrote: Package: xshipwars-server (debian/main) Maintainer: Adam Majer [EMAIL PROTECTED] 150411 [P ] xshipwars-server: POSIX shell incompatibilities 173966 [ ] xshipwars-server: won't uninstall unless the server is running! This package has is taged patch to one bug and in fact includes another patch in the text of the other bug which is tagged pending. Moreover it contains an offer from Colin Watson to sponsor the package from half a year ago. I guess someone should hijack the package. Hold it for a bit, please. I've been talking to the maintainer privately for the last week. An upload is waiting until the new libjsw is accepted. -- Colin Watson [EMAIL PROTECTED]
