Re: ftpmaster accepts packages that have been rejected a few days ago
On Thu, Nov 13, 2003 at 10:43:51AM -0600, Adam Heath wrote: > (for reference, I have commit access to dpkg, apt, and debbugs. this can > arguably be more important than accepting new packages into debian, as doing > something wrong with the above is very visible; ftpmaster is more of a hidden > thing) Spoken like a man who has never accidentally deleted an architecture :-) Richard Braakman
Re: ftpmaster accepts packages that have been rejected a few days ago
On Tue, Nov 11, 2003 at 11:04:04PM +0100, Rico -mc- Gloeckner wrote: > Saying that "another ftpmaster might think different" is proof enough > of a doubt; it would be better to say: "your package has to wait, i will > clear up with the group of ftpmasters wether this package is acceptable > for debian." I think rejecting it during this process of deliberation is better than letting it sit there. A rejection alerts the maintainer that there's something wrong with the package. In most cases, the maintainer will agree and fix the package, so that it's no longer borderline and no longer needs discussion. In the rare cases where the maintainer disagrees, it makes sense to re-upload the package and/or start a discussion about it on debian-devel. Remember that this process has to scale to dozens of new packages per day. It should be optimized for the common case. At the same time, the proper default is that a package is only finally rejected if all the ftpmasters agree that it should be rejected. For some reason, Marc Haber is complaining about this default, and he wants James's first decision to be final. Then at the same time he complains about James being the Secret Master of Everything. This leaves me confused. Richard Braakman
Re: exec-shield (maybe ITP kernel-patch-exec-shield)
On Mon, Nov 03, 2003 at 07:42:27AM -0500, [EMAIL PROTECTED] wrote: > Go ahead and do it. I could frankly care less if your users get owned. In that case it seems safer to avoid using any software you helped to develop. Richard Braakman
Re: Hardcoding of .la file paths in .la files
On Tue, Oct 07, 2003 at 09:30:56AM +0100, Scott James Remnant wrote: > On Tue, 2003-10-07 at 07:33, Chris Cheney wrote: > > > Does anyone happen to know why .la files hardcode the paths to .la files > > that they depend on? > > > To guarantee that you don't end up linking with something totally > different if the app being compiled happens to have a different search > path. Do they really believe that? First, the filename of a .la file doesn't guarantee anything of the sort, because the name isn't versioned. It will be replaced with an incompatible one with every major upgrade. Second, if a distribution really wants to keep compatibility in such a case, the best way is to move the old library to a special oldlibs directory and tinker with the search path. (This is better than putting the new library in an unusual place, because the rest of the world expects libraries to be in /usr/lib). Thus, this approach breaks the best way in which compatibility CAN be preserved. Richard Braakman
Re: Bug#213897: ITP: libclass-dbi-abstractsearch-perl -- Abstract Class::DBI's SQL with SQL::Abstract
On Mon, Oct 06, 2003 at 04:36:50PM -0400, Joe Drew wrote: > On Fri, 2003-10-03 at 14:12, Branden Robinson wrote: > > It's::plainly::obvious::what::this::package::does.Why::don't::you::pull > > ::your::head::out::and::RTFM::once::in::a::while? > > > > It's::not::like::this::sort::of::jargon::is::difficult::to::understand,::or > > ::that::writing::package::descriptions::which::rely::entirely::on::one's > > ::understanding of::what::other::packages::do::is::uncommon. > > I really hope you used sed or some workalike to accomplish that. "workalike"? sed is a workalike for the real editor. :%s/ /::/g Richard Braakman
Re: The size of debian packages
On Tue, Sep 23, 2003 at 10:34:31PM +0100, Andrew Lyon wrote: > How can I find out the sizes of the > packages and try to establish what I can remove without disaster. I tried > using deborphan to do this but it didn't even put a dent in my 100% full > volume. I was faced with a similar problem some time ago, and made a patch to deborphan to make it show the size of the packages it listed. It's available as part of bug#189827, but I don't know if it still applies. It only shows the size of the specific packages it lists, though, so it's easily fooled by for example a package "silly-game" (100kB) that depends on a monstrous "silly-game-data" (800MB). Still, it's a start. -- Richard Braakman There's still time to save Europe from software patents. EuropeSwPatentFree - http://EuropeSwPatentFree.internautas.org
Re: killing virus e-mails with file types
On Mon, Sep 22, 2003 at 10:20:22PM -0500, Craig P. Steffen wrote: > I do it in an even simpler way (keep in mind I don't really have bandwidth > limitations). I have my mail filter (kmail) set up so it trashes any mail > message with the string ".exe", ".pif", ".bat", or ".scr". So presumably you will never see my reply. > I also eliminate messages containing ".com", but in those messages, I require > that they _don't_ contain "http" to prevent killing messages because of a > link. Then you probably also missed all the noise about Verisign abusing the registry for .com and .net. Maybe you live in a happier world than I :) Richard Braakman
Re: [Fwd: False Representation at Google.com]
On Sat, Sep 06, 2003 at 02:59:31PM -0500, Branden Robinson wrote: > Given the tone of Driscoll's messages to us, whom are innocent > bystanders in this affair, I think your solution is quite unlikely to > happen. Huh? What's wrong with the tone? The first message wasn't to us, it was to the spammer. It was just copied to us, albeit in a less than clueful way. The second message just said s/he didn't like the situation and asked for our help. "I am against SPAM and it hurts to have it associated with my name in any way." I can completely understand this sentiment. I also don't like it that there are zillions of spams out there purporting to come from me, and I wish I could do something about it. Richard Braakman
Re: [Fwd: False Representation at Google.com]
On Fri, Sep 05, 2003 at 05:12:35PM -0500, Adam Heath wrote: > On Fri, 5 Sep 2003, Ava Driscoll wrote: > > I do not appreciate the following showing up: > > http://lists.debian.org/debian-devel/2003/debian-devel-200306/msg01662.html > > That email was sent by a virus. This virus is really nasty. Are you sure? Looks like ordinary spam to me. And this cease & desist was sent to [EMAIL PROTECTED] and then forwarded to us -- by the person who sent it?!? Some very broken mail agents are involved here. Anyway, I don't think we're being addressed at all. Richard Braakman
Re: debian archive disk space requirements.
On Mon, Sep 01, 2003 at 12:19:36PM +0200, Goswin von Brederlow wrote: > How much space do those 500 odd packages take up? > > Given a 50% sizce increase on binaries alpha should have another 1.8G > of debs. If those 500 packages make up 1.2G (+50%=1.8G) then the 50% > claim would be right. You're assuming that executables make up the bulk of most packages, and that compression rates for those executables are similar. I highly doubt both of those assumptions. Richard Braakman
Re: MEI Whitelist Autoresponse
On Thu, Aug 28, 2003 at 02:55:35PM -0700, Adam McKenna wrote: > How many were challenges from mailing list software? Yes, another class of > software that automatically issues challenges (specifically, to new > subscriptions and to non-list members if the list is closed). So I guess you > should also file bugs against majordomo, mailman, ezmlm-src, and any other > mailing list managers that do this. I think virus scanners are in a different class, though. Mailing list software isn't designed to recognize viruses, while virus scanners are. It's disgustingly incompetent to recognize a mail as Sobig.F, which is known to fake the sender, and then reply to it anyway. (And yes, I get a lot of "notifications" that mention Sobig.F by name.) Richard Braakman
Re: 0 RC bugs == releasable quality?
On Mon, Aug 25, 2003 at 08:22:34PM +0100, Mark Howard wrote: > I know the default answer is that it's the package maintainer's decision > - but I don't know what to decide! I suggest you go with gut feeling :) Imagine a year from now. You're at a geekly convention. Someone walks up to you and says, "Hey, you're Mark Howard! I've been using your package in stable, and..." At this point, do you go "Uh-oh"? Does your gut start churning? Sweaty palms? Fight-or-flight response? Then it's best not to release the package. If, on the other hand, you lean back in preparation for the accolades and gratitude that you expect will follow, and you're already trying to decide what kind of beer to accept, then your package is probably ready for stable. Richard Braakman
Re: NMUs applying sleeping wishlist bugs about translation (was something else)
On Sun, Aug 24, 2003 at 09:30:19PM -0400, Stephen Frost wrote: > Just about everyone else appears to feel all they should care about is > the changes they make in their NMU instead of actually caring about the > package and the distribution. There's this feeling of "not my problem". Someone who has a feeling of "not my problem" won't be thinking of doing an NMU in the first place. I present myself as Exhibit A. Translators have an area of interest that doesn't fit neatly into a few packages. They're not alone in this -- porters, and people who manage transitions, are in the same boat. That doesn't mean they care less, it just means they care about specific aspects of all packages, rather than all aspects of specific packages. You are berating people who are working to improve the distribution because they're not doing as much volunteer work as you think they should be doing. That's rude. Richard Braakman
Re: NMUs applying sleeping wishlist bugs about translation (was something else)
On Sun, Aug 24, 2003 at 06:56:00PM -0400, Stephen Frost wrote: > You've obviously not been paying very much attention at all then. > You should have a pretty good idea if the package is unmaintained or > not prior to doing an NMU. If it's not then you're uploading a package > which fixes some specific bug but leaves the package unmaintained. > That's irresponsible. That just doesn't make sense. Is it somehow more responsible to skip the NMU and leave the package with an extra bug that you could have fixed? Richard Braakman
Re: Debian Weekly News - August 19th, 2003
On Fri, Aug 22, 2003 at 12:19:57PM -0500, Branden Robinson wrote: > No. It's a way to assess whether the "silent majority" arguments raised > by a few loud people on debian-legal, claiming that most people don't > really believe that the GNU FDL needs to satisfy the DFSG, are the real > consensus view. ??? The survey asks whether the GFDL _does_ satisfy the DFSG, not whether it needs to. Did you misspeak here? Richard Braakman
Re: Debian Weekly News - August 19th, 2003
On Fri, Aug 22, 2003 at 02:28:52AM +0200, Andreas Metzler wrote: > Jérôme, please use "darn cabal of debian-legal zealots" next time. >cu and- triple reading the original mail, stil smiling -reas And don't forget to call them "licensing geeks"! Richard Braakman
Re: About NM and Next Release
On Wed, Aug 06, 2003 at 08:31:23PM +0100, Andrew Suffield wrote: > It runs deeper than that. If you aren't sufficiently interested to do > the work for its own sake, why the hell are you trying to join Debian > in the first place? Because you think it's an awesome group with laudable goals and you want to contribute? "Sure," you say, "then contribute. We'll just sit here and tell you you suck. If after 6-48 months of being told you suck you still haven't gone away, we'll think about officially (though grudgingly) accepting you." Awesome group. I really want to contribute. Richard Braakman
Re: How to install X-Chat in five hours (or more)
On Wed, Aug 06, 2003 at 01:40:41AM -0400, Nathanael Nerode wrote: > Admittedly, I've seen some less than useful messages on boot (mostly > overly generic messages where I couldn't figure out what part of > the system could possibly be producing them). Still, most of the > messages are really pretty good, if you know how to filter for the key > words. No need to know that -- you can let google do it :) I often paste whole error messages into the search field. It tends to work. Richard Braakman
Re: NM non-process
On Wed, Aug 06, 2003 at 06:04:33PM +0200, Josip Rodin wrote: > I see how it could be construed as a conflict of interest[1], but it's > not like the process doesn't have plenty of means to prevent that. Ian Jackson could also see how it could :) Debian Constitution 2.2.2: 2. A person may hold several posts, except that the Project Leader, Project Secretary and the Chairman of the Technical Committee must be distinct, and that the Leader cannot appoint themselves as their own Delegate. Richard Braakman
Re: How to install X-Chat in five hours (or more)
On Tue, Aug 05, 2003 at 11:06:53PM +0200, Tollef Fog Heen wrote: > Tab completion or using /Va* is about as fast as /var. Heh, teach yourself to type /Va* and you're going to get BURNED one day. (Your co-sysadmin finds a rootkit on another machine and stores it in /Various Dangerous Programs/ for later examination...) Tab completion is fine in contexts where it works. Richard Braakman
Re: libraries being removed from the archive
On Mon, Aug 04, 2003 at 12:42:27PM -0500, Adam Heath wrote: > And of the users? Please read the social contract. I read it every day, just before bedtime. Richard Braakman
Re: libraries being removed from the archive
On Mon, Aug 04, 2003 at 10:53:00AM -0500, Adam Heath wrote: > In this case, libexif8 -> libexif9, this is a major soname bump, so should > have required a new source package. The maintainer was probably derelict in > this case. Uh, no. Changing the binary package name the way we've always handled soname changes, except with a small number of very popular libraries. It's a lot less work, and it doesn't require creating a new package that will be orphaned almost instantly. If it turns out to be a problem for a particular library, and oldlibs package can be created for it afterwards, when the need for it has been demonstrated. Richard Braakman
Re: libraries being removed from the archive
On Mon, Aug 04, 2003 at 10:08:04AM +0200, Jérôme Marant wrote:
> > Hence the need for policy to dictate to the maintainer not to allow the
> > package to be removed before all other packages have transitioned. It
> > usually doesn't take much more work as long as the maintainer is even
> > aware of what will happen.
>
> It is not policy problem, it is a common sense one!
Common sense says otherwise :) You see, before we had katie and the
testing scripts, such removal of orphan libraries was done manually.
("orphan" because they no longer had a source package that built them).
Our experience was that packages that depended on them did not even start
to get updated until after we removed the old library. As long as the
old library was there, there was apparently no incentive for anyone
to recompile.
That's when we decided to just remove such libraries immediately,
and just let unstable be broken for a while. With most libraries
this works fine. There were a few libraries with so many dependencies
that an "oldlibs" version was necessary -- ncurses was in that
category, for example. But they were the exception, not the rule.
Of course, these days we have gnome and kde depending on every library
they can possibly find, and every other package depending on gnome
or kde (or both, if they can manage it), so the terrain may have
shifted somewhat...
Richard Braakman
Re: setuid/setgid binaries contained in the Debian repository.
On Thu, Jul 31, 2003 at 01:17:01PM +0100, Steve Kemp wrote: > http://www.steve.org.uk/cgi-bin/debian/index.cgi If you're just scanning for binaries with s bits set, then you'll probably miss all the ones that use whatever that tool was (suidmanager?) that was used by some packages before we had dpkg-statoverride. Richard Braakman
Re: More mailing from BTS?
On Wed, Jul 30, 2003 at 11:17:09PM +0400, Nikita V. Youshchenko wrote: > Recently I have to mail a package maintainer personally because a (trivial) > patch I submitted to fix segfault in his package was in BTS since November > and still not applied. I got a reply in several hours. I see this fact as a > proof that mail reminders are effective, at least sometimes and for some > people. But did you notice how your personal mail was much more effective than the automated mail the BTS had sent about the bug? People learn to filter out automated mail :) The bugscan lists seem much less effective now than when they started. This might be because they're not eagerly being annotated anymore, though. Richard Braakman
Re: Who wants cgoban?
On Sat, Jul 26, 2003 at 02:59:59PM +0200, Martin Godisch wrote: > On Sat, Jul 26, 2003 at 14:59:50 +0300, Richard Braakman wrote: > > > One of the packages I "maintain" is cgoban. I packaged it ages ago when > > I was a fanatical Go player. Nowadays I only get Go fever about one week > > per year, and it's hard to make time for this package when I'm uninspired > > about the game. I'd like to give it to someone who actually uses it. > > I'm using it and I'd be glad to adopt it. Okay! Please make an upload within two weeks :) (I adopted the two-week rule after unsuccessfully giving away maelstrom and xconq a couple of times...) Richard Braakman
Killing off hextype
hextype - Hexdump according to DOS Debug output format I realize that this little program has a certain fan base, and I used to be part of that fan base, but I really think the time has come to retire it. These days the program "hd" (in bsdmainutils) provides all the same convenience. I find myself using hd instead of hextype (even though I maintain hextype!) because it has two advantages: - It's more flexible. If I want to adjust something about the output, or if I want to see only a specific part of a file, then I can just give it some options. With hextype there's only one exact format and I have to be happy with that. - It will condense repeated identical lines. This is hugely convenient when looking at tarfiles, filesystem dumps, and other things with large blocks of zeroes. The sole advantage of hextype is that it's smaller and faster, but I've never had a reason to care about that. Normally I would just file for hextype's removal after coming to these conclusions, but as I said earlier, I know that this program has a fan base :) So if you use hextype, and want to keep it in the archive, then please contact me and I'll happily accept your offer to maintain it... (If you're in the new maintainer queue, I'll also sponsor your uploads as long as you don't make a mess of them.) If I hear nothing about it in a week or two, then I'll assume that everyone hates hextype and I'll ask for it to be removed. Thanks, Richard Braakman
Who wants cgoban?
One of the packages I "maintain" is cgoban. I packaged it ages ago when I was a fanatical Go player. Nowadays I only get Go fever about one week per year, and it's hard to make time for this package when I'm uninspired about the game. I'd like to give it to someone who actually uses it. cgoban - Complete Go board This program presents a graphical Go board on which you can play. It doesn't play against you, you need another program (like gnugo) to do that. It's primarily designed to play on two Internet Go servers, IGS and NNGS. The author of cgoban is friendly and responsive, but he considers cgoban to be obsolete. He's working on cgoban2, which is written in Java and is a client for a different set of Go servers (KGS), so it's not a replacement for cgoban. There is now a sourceforge project for maintaining cgoban1, as one bugreporter rudely pointed out. Packaging that version would be a productive way to take over this package :) If you want it, please let me know, and (to avoid collisions) wait for me to confirm before you actually make an upload. Richard Braakman
Re: Future releases of Debian
On Sat, Jul 26, 2003 at 12:10:01AM -0400, Nathanael Nerode wrote: > dselect (required) depends on libstdc++5, libgcc1 (both important) > Upgrade priority of the latter two, or downgrade dselect. Alternately... is the difference between "required" and "important" really useful? We already have the "Essential" flag to indicate which packages are really required. We could just fold these levels into one to simplify things. Richard Braakman
Re: Future releases of Debian
On Fri, Jul 25, 2003 at 04:47:24PM +0100, Scott James Remnant wrote: > I think other answers in this thread speak for themselves. If you've > not even tried asking for an account to fix some bugs, then you're > obviously not that interested fixing them. You're talking as if fixing bugs is some kind of privilege. These people are *contributing* to Debian, despite the roadblocks we've set up. The least you could do is show a bit of courtesy when they complain that the roadblocks we've set up are inconvenient. Richard Braakman
Re: why mplayer not in Debian
On Tue, Jul 22, 2003 at 12:07:28PM +0200, A Mennucc1 wrote: > ( last time I tried, it looked as if there was some automatic filter that > drops mplayer from the incoming queue: indeed, I never received > the e-mail reply 'mplayer is new, please wait' that is > sent on upload of a new package) If you never got that email, then it's likely that there was something wrong with the upload and the ftpmasters never saw it. Was it properly signed, etc? Did it have a valid .changes file? Richard Braakman
Re: Please remove RFCs from the documentation in Debian packages
On Sat, Jul 05, 2003 at 11:41:51AM +1000, Brian May wrote: > Couldn't you write a new document along the lines of "This is based on > RFC1341 with the following exceptions "? Tell that to the authors of RFC2616 :-) Sometimes it's very valuable to NOT have people reading the old version first, for example because it's full of information that is almost but entirely not correct. Then you want them to instead read a consistent presentation of the new standard. Now, you might want to say that only the IETF should be allowed to produce something like RFC2616. That's fine as long as the IETF is the smart and effective body it is now and everyone is welcome to join it. But how do you know this will still be the case 20 years later? The arguments against forking standards are pretty similar to the arguments against forking gcc -- in both cases it's generally a bad idea, but the health of a free system depends on it being potentially possible. Richard Braakman
Re: Please don't misuse the debian/changelog to close bugs!
On Fri, Jun 27, 2003 at 08:19:14PM +1000, Herbert Xu wrote: > Are you proposing that we list important upstream changes regardless of > whether they fix bugs or not? > > If so then this may be worth considering. Hmm, I've always tried to do that, actually. And I appreciate it when other developers do it. If the upstream changelog is verbose and detailed (like the GNU ones tend to be) then it's nice to have the major changes as a short list. Richard Braakman
Re: Application files in $HOME
On Wed, Jun 25, 2003 at 02:02:04PM -0300, Daniel Ruoso wrote: > What if the packages tells to dpkg which files or directories it will > create on the user's home directory and when a package is purged the > user could run a program to purge the files of packages that no longer > exists. I have a better idea :) What if packages don't leave droppings in my home directory in the first place? I have all sorts of dotfiles (and even dot-directories) that I never asked for. It's reasonable for a program to install a dotfile when I configure it differently from the default, but there's no reason to create a dotfile that's identical to the default. In addition to being annoying in themselves, such useless dotfiles get in the way when a newer version has different defaults or incompatible configuration fields. When I do configure a program (if it doesn't have an interactive configuration interface), I want to do it by creating a small, human-editable file that contains the _differences_ from the defaults. So even then I have no use for a copy of the default configuration. (If I want an example, I can look in /usr/doc/$foo/examples, which is a better place for it than $HOME.) Richard Braakman
Re: kernel 2.5.73+, fakeroot, debuild - a small problem
On Wed, Jun 25, 2003 at 09:30:32PM +1000, Herbert Xu wrote: > Why is fakeroot calling the real chown(2)? I think it's to be able to report errors like ENOENT. You can turn it off by setting FAKEROOTDONTTRYCHOWN in the environment. It should be possible to replace this chown with something harmless that reports the same errors. Richard Braakman
Re: appropriate use of /etc/alternatives
On Sat, May 31, 2003 at 12:08:20PM -0400, Noah Meyerhans wrote: > On Sat, May 31, 2003 at 02:00:41PM +0100, Mark Brown wrote: > > The binary is going to have to be renamed - even if you use an > > alternative there'll still be a renamed binary there. > > yes, but the user would only need to know in the even that they had both > alternatives installed, which I don't see happening very often. This means that the result of using "xplot" is unpredictable. Something that worked yesterday can break tomorrow because the sysadmin installed a new package. That's not a good situation. > > Would it be possible to massage the data format for one xplot into the > > other or modify one to accept the input of the other in a compatibility > > mode? > > Possibly, but why create more work for the user? I think it's _less_ work for the user if you can have one xplot program which replaces both of the current ones. Richard Braakman
Re: Bug#194938: ITP: drivel -- A LiveJournal client for the GNOME desktop
On Wed, May 28, 2003 at 11:33:25PM -0400, David Z Maze wrote: > [...] I think > the service is popular enough that you don't need to explain what it > is, in the same way that you don't need to explain what an SNMP daemon > is to have and snmpd package. Ironically: Package: snmpd Description: NET SNMP (Simple Network Management Protocol) Agents. The NET SNMP agent allows remote monitoring of various network and system information. This is a good enough explanation for me. Richard Braakman
Re: Debian conference in the US?
On Tue, May 20, 2003 at 01:25:47PM -0400, Aaron M. Ucko wrote: > Two of the people I originally contacted said this too, but always in > the third person. I ask again, who on this list actually still feels > this way? I do. These days I won't travel to the US even if somebody would pay me to. It's just not safe. Don't let that stop you from holding a conference, though -- if you already live there, it's no extra risk :) Richard Braakman
Re: Dropping/splitting (proper) i386 support
On Sun, Apr 27, 2003 at 04:32:37PM -0400, Nathanael Nerode wrote: > This is an attempt to summarize some points. > > 1. Why do we have a problem, other than performance issues? > > * To maintain binary compatibility with other distributions for C++ > packages, Debian needs to use the i486+ version of atomicity.h supplied > by GCC. > * This version is significantly faster than the i386 version. > * GCC 3.2 doesn't even supply a working i386 version (GCC 3.3 does). > * This is exposed ABI (currently) and therefore cannot be solved by > multilibbing. > > 2. What performance benefits do we get as side effects of dropping 386? > > * i486 guarantees a 32-bit external data bus (386SX has a 16-bit bus.). > http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg02043.html > Not sure if there's anyone programming to the data bus. :-) > * i486 has a cache, and accordingly an 'invalidate cache' instruction. > * i486 has an 'invalidate TLB entry' instruction (INVLPG). 386 requires > the flushing of the entire page table. > * i486 has the BSWAP, XADD, and CMPXCHG instructions (and possibly > others -- I haven't found a complete list). > * OpenSSL is *much* faster on i486+ than on i386. The improvements for > going to i586, i686, etc. are not that great. > http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg02031.html > * The kernel is markedly faster compiled for i486+ than on i386. > Again, the improvements for subsequent chips are not as impressive. > This is at least partly *not* a tuning issue; for 386, the kernel needs > extra code whenever it writes to user pages > (http://www.cs.helsinki.fi/linux/linux-kernel/2002-13/0445.html), > has to clear the whole page table rather than using INVLPG, > and uses less efficient options rather than CMPXCHG,XADD, and > BSWAP in heavily-used code paths (including read-write semaphores). > > Other instances I've seen show a really sharp performance improvement > with i486-specific code rather than i386-specific code, and declining > benefits for each subsequent model. I'm not sure how much is tuning and > how much is architecture-specific, of course. > Oddly, it looks like > GCC doesn't currently ever generate 486-specific instructions; they are > only (currently) of benefit to assembly programmers. Note that uses asm statements to do byte swapping, and it has separate cases for i386 and i486. This file is used by which defines htonl() and friends, and by which defines bswap_32() and friends. Compiling for the i486 will make a difference here even if GCC doesn't care itself. Richard Braakman
Re: [debian-devel] Status of mICQ code audit
On Tue, Apr 22, 2003 at 04:25:11PM -0500, Drew Scott Daniels wrote: > I wouldn't call it malicious, but I question the use of the word "harmful". I would definitely consider an easter egg that disables the package to be "harmful". By contrast, an easter egg that makes a little penguin dance around your screen if you press the right key combination would be "not harmful". Easter eggs are usually in that category. > Although, was the behavior to do it at a specific > "time" or at startup everytime? At startup everytime, after a certain date. Richard Braakman
Re: stop abusing debconf already
On Mon, Apr 21, 2003 at 12:07:24PM +0100, Matt Ryan wrote: > Trouble is I need to know what the sender of the email, I'm replying to, > wanted in regards to getting copies of the response to both list and direct. > One could manually parse the email headers and set the reply appropriately > but this is a rather onerous task when replying to a large number of emails. If you're not sure, you should just follow list policy and not Cc. It's also nice to attribute your quotes, btw. Richard Braakman
Re: Do we need policy changes?
On Sun, Apr 20, 2003 at 10:34:10AM +0200, Eduard Bloch wrote: > Henrique de Moraes Holschuh schrieb am Sunday, den 20. April 2003: > > Go away. > > Come on, is fscking wish reports a good way to communicate with users? Yes. If they say things like "deb??an (and others) doesn't care much about internationalization, no matter what they say", then they should be told to go away. That kind of shit just demoralizes the people who are doing the work. Richard Braakman
Re: Bug#189566: amavisd-new: bad interaction with package amavis-ng
On Sun, Apr 20, 2003 at 09:00:51AM +0200, Marc Haber wrote: > In the last case, there should be a way to do this _easily_. Currently > the only way to do this is parsing dpkg --list output, which is mucho > ugly. I'd actually prefer the file check, and not involve the packaging system in the day-to-day running of the system. (Example: if I'm installing and configuring a firewall, I'd like to be able to delete the dpkg files from the final image before flashing it.) Richard Braakman
Re: Pre-linux Windows program - was Re: bill gates Linux
On Sun, Dec 08, 2002 at 04:30:10PM +0100, Emile van Bergen wrote: > Another idea: why not support an installation in an ext2 filesystem > which is really a big file on a Windows VFAT partition, mounted using a > loopback device? That would do away with all the partitioning; that > would only be needed when the user wants to get rid of the relatively > minor performance penalty of the extra FS layer. Are VFAT partitions still common? I thought Windows 2000 and XP both used NTFS by default. And last time I tried (about a year ago, I think) mounting NTFS read-write on Linux was still flaky. I also question whether the performance penalty would be "relatively minor", especially if you treat the swap device the same way. But that can be measured. If it's significant, then I think this option should not be encouraged, because it would give Linux an undeserved bad name among precisely the people we hope to convert. Richard Braakman
Re: Pre-linux Windows program - was Re: bill gates Linux
On Sun, Dec 08, 2002 at 04:22:52PM +0100, Adrian 'Dagurashibanipal' von Bidder wrote: > Hmmm, ok, on 2nd thought there's modems, printers, and old ISA cards. > Anything else? What about configurations for IP, DNS, mail and news? I don't see why it would be limited to hardware detection. Richard Braakman
Re: description writing guide
On Thu, Dec 05, 2002 at 02:49:12PM -0800, Thomas Bushnell, BSG wrote: > 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 was about to say that, but then I realized that it doesn't help if a period is at the end of a line. I use two spaces between sentences myself (old emacs habit), but it irks me that that's not a complete solution. Richard Braakman
Re: description writing guide
On Wed, Dec 04, 2002 at 08:05:43PM -0500, Colin Walters wrote: > I think this is hard to without switching to a format which allows us to > include more metadata (like XML). So we can explicitly use stuff like > and for lists, instead of relying on ASCII renderings. That > way we can safely word-wrap the description, instead of just treating it > as the equivalent of . The Description file used to have such a format. It had enough information to allow word-wrapping, a specified format for bulleted lists, and a way to add meta-information (even though no such information was yet defined). Sadly, it seems to have been lost. I can't find a description of the Description format anywhere in the current policy manual; not even in the version of the Packaging Manual that it carries as an appendix. Hmm, D.2.7 says the description is in "a special format", but does not say what that format is, and refers to a section that does not describe it. Richard Braakman
Re: Fwd: Please confirm your message
On Tue, Dec 03, 2002 at 11:09:02AM +0100, Gerrit Pape wrote: > Autoresponders, bouncers, and other mail handling programs use the > envelope sender address, not an address found in any header of the mail. > I doubt that any abuse@ address replies to a bounce message. This is no > problem. Practical experience contradicts this. Have you tried subscribing to debian-security? You get to learn fascinating things about the vacationing habits of random strangers. I also _frequently_ get bounces that should have gone to the mailing list software instead of to me. This happens less on unixy lists, so you might not have noticed on debian-*. Hmm, if I understand it right, your plan will mean that anyone operating such a broken mail system will get DoSed by spammers? Then maybe there's something to it after all :-) Richard Braakman
Re: location of UnicodeData.txt
On Mon, Dec 02, 2002 at 11:16:07AM -0500, Jim Penny wrote: > On Sun, Dec 01, 2002 at 11:06:12AM +1300, Nick Phillips wrote: > > There are all sorts of reasons why you might wish to create derivative > > works based on the standard -- a new standard for a different purpose, for > > example. > > Derivative works are covered by copyright. Period. I would advise that > you not base a defense of infringment of copyright on the fact that you > have only used it to create a derivative work. Umm, yes. That's exactly why the text of a standard should be free. You seem to be confusing the "should be" and "is" discussions. > > > On the other hand, if you wish to create a competitor to the unicode > > > standard, say the debicode standard, I see no moral right that you have > > > to incorporate, without permission, the unicode standard. You should > > > expect to start from scratch! > > > > Engage brain. Do you think that if I want to create a competitor to, say, > > GNU Emacs, that I should expect to have to start from scratch? Or fetchmail? > > Or any one of the thousands of DFSG-free packages that are in main? > > Brain engaged. OK, according to you, anyone can make a competitor to > GNU Emacs and may use the GNU emacs code. Great. So, now consider > microsoft visual gnu emacs, which is released under the MS-EULA. You seem to have hit the wrong button when you tried to engage your brain. Why would "create a competitor" have to mean "create a competitor under a conflicting license"? The GNU Emacs license allows you to create a competitor without starting from scratch. That is what makes it free! > What's that? Oh, you mean that anyone may produce a derivative work > that is licensed in a manner compatible with the original work's license, > provided the original license specifically grants that right? Oh. Yes, > I agree with that. Stated in those terms, it is not much of a surprise. I don't think he meant that at all. You're confusing "may" with "should expect to be able to". The whole "provided..." clause misses the point. Laws do not define morality. Now, why do you think that it would not be a good thing for the text of the text of the Unicode license to be free? Your only answer so far seems to be "because it currently isn't". Richard Braakman
Re: Package with non-free build-depends
On Mon, Dec 02, 2002 at 12:27:09PM +0100, Josip Rodin wrote: > > Hm, I don't think I like this. The gif images aren't the preferred form > > of modification. Would we accept it if someone had a program written in > > a language which only had a non-free compiler, then uploaded source > > packages to main which contained object files, and just set > > Architecture: i386 ? I don't think so. > > That's the wrong analogy, because images are not programs, they are data. > If I wrote this email in a non-free editor, would you consider the data in > the email non-free just because of that? On the other hand, if you change the program, you would like to change the documentation along with it, yes? And in an entirely free system, doing so would either destroy the images or leave them incorrect. Losing a feature just because you recompile is not the mark of a free program. Richard Braakman
Re: location of UnicodeData.txt
On Thu, Nov 28, 2002 at 07:02:07PM +0100, Emile van Bergen wrote: > On Thu, Nov 28, 2002 at 11:47:52AM -0600, John Hasler wrote: > > I'm arguing that the _creation_ _of_ _that_ _table_ > > involved no creativity, not that the invention of Unicode didn't. > > Well, so you say that if I write a novel, all my creativity is in the > abstract idea; putting the words down involved no extra creativity; thus > the sequence of words cannot be copyrighted? I don't think I would follow you that far, but I do agree that saying "it's just a table of data" is no more meaningful than saying "it's just a sequence of characters". The nature of the data is relevant. In this case, the data consists of two main components: - A mapping of character codes to character names - A list of attributes for each character Both of these components were carefully designed, with decisions that involve efficiency tradeoffs (use vs. compression vs. conversion) and that affect the usefulness of the result. Some of the decisions are still controversial. This data wasn't found engraved on some rock, and it's not a collection of pre-existing facts, it was created. > > Is it possible to create other Unicode tables that serve the same purpose > > as that one and differ from it non-trivially? > > Good question. Under your reasoning, merely writing the list down from > the unicode spec, possibly using | as separators instead of :, should do > the trick. Note that this file _is_ part of the unicode spec. As far as I know the character attributes are defined nowhere else. So "writing the list down from the unicode spec" means copying the file. Richard Braakman
Re: location of UnicodeData.txt
On Thu, Nov 28, 2002 at 06:07:57PM +0100, Emile van Bergen wrote: > However, in these perverse times, where companies patent hyperlinks, I > honestly have no idea whether Unicode itself is owned but licensed > royalty-free, or as free as say, ASCII or English. These days I wouldn't be eager to rely on the limits of copyrightability. CNN.com - Composer pays for piece of silence - Sep. 23, 2002 <http://www.cnn.com/2002/SHOWBIZ/Music/09/23/uk.silence/> Richard Braakman
Re: location of UnicodeData.txt
On Thu, Nov 28, 2002 at 02:58:38PM +0100, Tim Dijkstra wrote: > > UnicodeData is different, because we need the data in our program, > > not only the ideas. And it this case we see that as software! > > Maybe you're right that we don't really need the rfc's in main. They > actually are now and it would be a shame if we dropped them. But we need > files like this unicode file in main, which is part of a specification > (I think), so can't be altered. But do you think it's _okay_ for such a file not to be free? (Whether it actually is or not is a topic for debian-legal). We could be stuck with programs that we can't modify to support new languages, for example. Richard Braakman
Re: location of UnicodeData.txt
On Wed, Nov 27, 2002 at 08:50:10AM -0800, Thomas Bushnell, BSG wrote: > Heh. There's another: > > miscfiles: /usr/share/misc/unicode.gz > > The current version is Unicode 3.1.1. According to http://www.unicode.org/Public/UNIDATA/UnicodeData.html there's a version 3.2. Hmm, is this file Free? There's a license on that same page: Limitations on Rights to Redistribute This Data Recipient is granted the right to make copies in any form for internal distribution and to freely use the information supplied in the creation of products supporting the Unicode^TM Standard. The files in the Unicode Character Database can be redistributed to third parties or other organizations (whether for profit or not) as long as this notice and the disclaimer notice are retained. Information can be extracted from these files and used in documentation or programs, as long as there is an accompanying notice indicating the source. Richard Braakman
Re: Ye Olde optimization/mirror disk space debate
On Sun, Nov 24, 2002 at 11:45:24AM -0800, Thomas Bushnell, BSG wrote: > Once again, we tell mirrors that they can mirror only i386, and that > would be fine. We already have mirrors that mirror some arches and > not others, right? Currently we have a good, solid mirror infrastructure. I can expect to find one or more full, up-to-date mirrors in my country or a neighbouring country, and I don't even have to look them up -- I just try ftp.*.debian.org, possibly ftp1.*.debian.org, where the * is a country code. You propose to fragment that and make users play hunt-the-right-mirror every time they configure apt. For what benefit? Richard Braakman
Re: RFC: Handling of certificates in Debian
On Mon, Sep 02, 2002 at 02:22:52PM -0300, Henrique de Moraes Holschuh wrote: > > I would think most places want their own cert and not to share with > > other, probably totally unrelated, people. > > For that, you need a specification that allows you to send a number of certs > (instead of only one) and let the browser select the one that matches the > domain it wants, and verify that single one. I don't think thats scales sufficiently well. Some sites have *thousands* of virtual domains. Sending all those certificates for every https request would be expensive. If you're going to tinker with the specification anyway, I would suggest one where the client states up front whose certificate it wants. Richard Braakman
Re: Bug#158683: ITP: oggasm -- MP3 to Ogg converter
On Sat, Aug 31, 2002 at 05:15:00PM -0500, Adam Majer wrote: > > we definitely need an mp3 decoder in debian if we want to fight the > > patent oppression at all. i think we need another branch for that kind > > of problems. > > lol, I doubt it would help. Just go to US patent office website and > do a search on stuff like on title try "The Wheel". :) I know, it's getting > ridicules. What need to be done is for someone to sue the patent > office for stifling innovation and promoting monopolies. ie. something it > was originally created to fight. The wheel is patented in Australia, not in the US. On the other hand, in the US there is a patent on using a laser pointer to exercise your cat, and one on swinging sideways on a playground swing. I do think that discouraging the use of patent-encumbered "standards" is a useful way to fight patent oppression. It sends the message that a patented standard is a dead standard. Maybe companies will review their habits in that light. > > yes, but only non-free in states that impose patent restrictions. if we > > have such "non-patented" branch it would be free for users outside the > > circle. > > I'm not sure, but an app A that incorporates algorithm BOB and BOB is > "patented" > under a non-GPL license, then I don't think that A can be distributed as > a GPL program. Only if the patent holder for BOB is actively trying to enforce the license. If you're thinking of GPL section 7, then remember that it only applies to conditions specifically imposed on you, not merely the threat or possibility of such conditions. In general, I don't think we can adopt a useful and consistent stance on what to do with software that uses patented algorithms. There are just too many patents, and just about any program infringes on at least one of them. Even worse, it is impossible to prove that a program does NOT infringe on any patent. We'll have to consider the details of each case individually. Richard Braakman
Re: [ardour-dev] ardour in Debian
On Sat, Aug 31, 2002 at 11:18:26AM -0400, Paul Davis wrote: > This was not the only reason. Similar breakage occurs as soon as the > user acquires a C++ library in binary format that was compiled by a > g++ with either different options and/or a different ABI compared the > one used to compile and link the application. If someone upgrades from > g++ 2.95 to g++ 3.2, for example, and they fail to recompile *every* > C++ library on their system, problems will arise sooner or later > (depending on how many C++ apps they run and how they were built). The irony here is that Debian has stuck to g++ 2.95 for this reason, and is now preparing a plan for upgrading to g++ 3.2 in a sane and consistent manner. This will cause upgrades of Debian packages to go smoothly and correctly, but it may not work for locally compiled programs because those don't come with sufficient dependency information. If ardour can't be packaged for Debian, or if it links statically with a lot of C++ libraries, then the transition is less likely to be smooth. It's hard to be sure about this while the details are still being worked out. Still, there's a much better chance of it going right if ardour is simply packaged according to Debian policy, because that's what our upgrade plan will expect. Richard Braakman
Re: Bug#158683: ITP: oggasm -- MP3 to Ogg converter
On Fri, Aug 30, 2002 at 01:36:47PM -0500, Branden Robinson wrote: > In other words, if you write some free software, it's not your fault if > some company decides 15 minutes or 15 years later that they had a patent > on an algorithm you used, and sent packs of lawyers out to eradicate > your software from the planet. It might still be appropriate to move it to non-free, though. We did that for GIF, in order to discourage use of the format, while still allowing users who desperately needed it to install the packages. This case seems similar, with the alleged patent-holder allowing non-commercial use. (I say "alleged" because I have not yet seen any basis for their claim that decoding is patented. The FAQ at http://www.mp3licensing.com/help/developer.html implicitly makes this claim, but gives no details.) Richard Braakman
Re: Bug#158631: ITP: mp32ogg -- Converts mp3 file to Ogg Vorbis
On Wed, Aug 28, 2002 at 07:22:49PM +0200, Russell Coker wrote: > The users can then pay the $0.75 or not at their own choice. $0.75? >From http://www.mp3licensing.com/royalty/software.html Minimum Royalties Annual minimum royalties are payable upon signature and each following year in January and are fully creditable against annual royalties. US$ 15 000.00 per calendar year Presumably this is intended to apply to distributors, not individual users :) They don't actually say that, though. Richard Braakman
Re: Migration to /usr/share/doc
On Tue, Aug 27, 2002 at 10:48:13AM +0200, Michael Piefel wrote: > Perhaps I should use /usr/doc/ instead. Even shorter... I have been a happy man since I made a /doc symlink. Richard Braakman
Re: How to get rid of non-free packers?
On Sat, Aug 24, 2002 at 02:35:31AM +, Frank Copeland wrote: > It remains to be seen how easy it is to port code written for a defunct > proprietary (but supposedly ANSI-compliant) compiler on a vaguely > unix-like but non-POSIX OS. I would be happy to help with that, for what it's worth. I don't have experience with the platform in question, but I have experience with ugly code. The experience should be similar :-) Richard Braakman
Re: Bug#156503: microsoft changed its policy, msttcorefonts broken
On Thu, Aug 15, 2002 at 12:10:30AM -0700, Michael Cardenas wrote: > My main concern at this point is that it may be infeasible to generate > high quality truetype fonts without using apple's patented truetype > instructions (which is only a small subset of instructions, but they > are commonly used in fonts). I've contacted one of the freetype > authors to ask him what he thinks about this. As far as I can tell, it's the rendering which is patented, not the font information. So you can create TT fonts with the hinting information, and for example freetype2 can use it if you enable the bytecode interpreter. Otherwise it will use its auto-hinter to generate plausible output. You might want to boycott the patented features, though, and design the fonts so that they will (only?) render nicely using the autohinter. As an alternative, would it be acceptable to simply point at Apple and laugh at their silly patents? I've been looking at one of them (US patent 5,155,805), and it's a patent on basic math. You take a point and two vectors, project one vector on the other, and add it to the point. That's ALL. But if the point is part of a glyph outline, then this operation is Intelecutal Prupperty of Apple. (For reference, the USPTO patent search engine is at http://patft.uspto.gov/netahtml/srchnum.htm Unfortunately, it doesn't generate useful urls for individual patents.) -- Richard Braakman "I sense a disturbance in the force" "As though millions of voices cried out, and ran apt-get." (Anthony Towns about the Debian 3.0 release)
Re: XFree 4.2.0 - again
On Wed, Apr 17, 2002 at 08:41:41AM +1200, Corrin Lakeland wrote: > Incidentially, Lasse's email did convince me that Branden's job isn't just > hard, it is _really_ hard. The idea of having to deal with daily emails like > this horrifies me. I can see where his abrasive style comes from ;-) No... he had his style long before he became X maintainer :) The bitterness, on the other hand... But X will do that to a man. Imagine what it's like, not being able to browse "XXX" sites without being reminded of the latest chipset driver bugs. Richard Braakman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please see the GNU FDL discussion on debian-legal
On Tue, Apr 09, 2002 at 02:51:27PM -0400, Thomas Hood wrote: > Richard Braakman wrote: > > What you're advocating is the evil twin of censorship, > > namely forced speech. > > I don't think that placing restrictions on an otherwise > completely liberal license amounts to using any kind of > "force", but that's mere semantics I suppose. For what it's worth, I don't think I'm stretching the definition of forced speech any further than you were stretching the definition of censorship. We were both talking about voluntary actions that have no effect on others except to make more copies available than there were before. I think that the option to republish only parts of a work is an important freedom to have, even if exercising that freedom is in some cases a form of censorship. > I do agree > that the various authors of a document may disagree about > what they want it to contain, and that resolving the > matter by means of "invariant sections" licenses is not > to treat documentation in the same way as Debian treats > software. In that case, we might be remarkably close to agreement in general. (Remarkable for this list, that is :-) Richard Braakman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GNU FDL (was Re: Bug#141561: gnu-standards: Non-free =?iso-8859-15?q?software in?= main)
On Tue, Apr 09, 2002 at 02:03:11PM -0400, Dale Scheetz wrote: > The history section in my book, which is declared invarient in the > license, was written by Ian M. and has no technical bearing on the rest of > the book's content, but has every reason to be "protected" from > modification. These particular words have a value that must be protected. I would have no complaint against the GFDL if that was all it did. But it also binds those words eternally to the technical documentation that they accompany. > None of these issues force behavior on the reader, like code does for the > CPU. So no "freedoms" are being infringed upon by forcing the text to > remain unchanged. Here, and below, you speak about the freedoms of the reader as if the reader is merely a consumer and would never ever want to re-use parts of the work in future works. That view is contrary to what we are trying to create with free software. Why _should_ documentation be any different? I'll pull your example up from below: > Using my book as an example, there have been many patches submitted either > for spelling or content. I have included all those that were correct ;-) > I have never seen the book published with changes that were not made by > me, so it isn't clear to me just what the pressing modification > requirement is in the first place... Many authors of non-free software make exactly this argument. They have a right to think that way, but it does not make their software free. As a small example, consider that someone might wish to condense part of your book into a reference card that can be mounted on a mousepad. Unfortunately, the license will requires that Ian M's history of Debian be reproduced on this reference card somehow, thereby making it less useful. Would you still say the reader has all necessary freedoms? > The freedom of expression of the author is what is being > protected by this clause. The freedom to express opinion without having > those statements twisted into something completely different is one of the > reasons for the creation of the copyright in the first place. A version of the GFDL that allowed deletion but not modification of such sections would be perfectly acceptable to me. Richard Braakman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please see the GNU FDL discussion on debian-legal
On Mon, Apr 08, 2002 at 10:02:47PM -0400, Thomas Hood wrote: > While I don't regard the DFSG as already applying to > documentation, the spirit of it is naturally extended to cover > documentation. I would suggest that the GFDL is a reasonable > license to use for free documentation --- free as in 'free > to use and modify', but also free as in 'free speech'. If the GFDL were a "free to use and modify" license, then we would not be having this discussion. The problem is that the GFDL specifies parts that we are _not_ free to modify, or even to delete. > Several people said that they didn't want Debian > documentation to be full of political rants. They would > like to reserve the right to delete the parts they don't > like from the manuals they package. But what is this but > censorship? And how is censorship compatible with liberty? What you're advocating is the evil twin of censorship, namely forced speech. Richard Braakman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GNU FDL (was Re: Bug#141561: gnu-standards: Non-free software in main)
On Mon, Apr 08, 2002 at 10:30:18AM -0500, Jeff Licquia wrote: > On Mon, 2002-04-08 at 09:01, Richard Braakman wrote: > > On the other hand, by taking action we might be able to stop those projects > > from taking such a misguided course of action. I think the FSF is making > > a big mistake with the GFDL. > > I'm curious about your reasoning. Have you posted it already? If not, > maybe it would be good to hear once woody is out. It participated in the discussion that raged on debian-legal a while ago. I stated some points, but I never presented my opinion as a whole. I felt that others were already making my points quite adequately, and that's just the way a mailing list discussion works. Now that the discussion has died down (awaiting a response from the FSF), it might be worthwhile for me to summarize my position. If all the participants did that and put it on a web page somewhere, it would be a good introduction for people who missed the debate the first time around. I haven't had the energy, though. -- Richard Braakman "I sense a disturbance in the force" "As though millions of voices cried out, and ran apt-get." (Anthony Towns about the Debian 3.0 release) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GNU FDL (was Re: Bug#141561: gnu-standards: Non-free software in main)
On Mon, Apr 08, 2002 at 12:08:05AM -0500, Jeff Licquia wrote: > The point is that pulling everything out that's GFDL isn't really a good > option; it damages the project for zero gain. This is especially true > in the long term, as projects follow the FSF's lead and start releasing > GFDL docs. On the other hand, by taking action we might be able to stop those projects from taking such a misguided course of action. I think the FSF is making a big mistake with the GFDL. Richard Braakman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Conference 2 Registration
On Mon, Apr 08, 2002 at 06:30:29AM -0400, Joe Drew wrote: > Two quotes come to mind: [...] You left out my favourite :) "Nothing is impossible for the man who doesn't have to do it himself." - A. H. Weller, according to the first google hit. Richard Braakman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Conference 2 Registration
On Sun, Apr 07, 2002 at 01:53:07PM +0200, Jeroen Dekkers wrote: > IMHO the non-free section should be removed. Well, go for it. In the meantime, stop antagonizing people who do nice things for us. -- Richard Braakman "I sense a disturbance in the force" "As though millions of voices cried out, and ran apt-get." (Anthony Towns about the Debian 3.0 release) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Conference 2 Registration
On Sun, Apr 07, 2002 at 03:03:14AM +0200, Jeroen Dekkers wrote: > We should not advertise directly or indirectly non-free software. Er, we _host_ non-free software on our servers, and distribute it via our mirror network. If you want to go on a crusade, then there are targets closer to home. Richard Braakman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The GNU Free Documentation License (GFDL) and /usr/share/common-licenses
On Sat, Apr 06, 2002 at 05:57:43PM -0500, Dale Scheetz wrote: > There are an ever growing number of packages that make use of the GNU Free > Documentation License. Isn't it about time to put a copy of this license > into the common reference area? No, it would be premature. There's a draft for a new version up for review at the FSF site. There's also a still-open discussion about whether the GFDL is free enough for Debian if Invariant Sections are used. Richard Braakman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [2002-04-06] Release Status Update
On Sat, Apr 06, 2002 at 10:24:34PM +1000, Anthony Towns wrote: > Actually, as always, it'll release when it's ready: if we find that the > software doesn't meet our expectations on April 30th, you'll find me on > the ground writhing in pain with leaves, bark and wood all over the place > [1]. Well, I really hope we make this May 1st release date, because I've scheduled a really massive celebration party here in Helsinki[*]. There's going to be people dancing in the streets and everything. And of course excessive intake of alcohol. And then we'll all throw our hats in the air. -- Richard Braakman "I sense a disturbance in the force" "As though millions of voices cried out, and ran apt-get." (Anthony Towns about the Debian 3.0 release) [*] http://www.virtualtourist.com/m/?s=d&showpic=/p/.99868/t-159-8.jpg&mn=helimaarit&pn=Finland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: rootkit - a Ro0Tk1t 4 Deb1an boxxxen
On Mon, Apr 01, 2002 at 03:39:56AM +0200, Simon Richter wrote: > jU5T d0 apt-get install rootkit, 4n5W3r d4 q35t10nz && h4V3 fUn!!! ^^^ You misspelled "phUn". When will people learn to check their descriptions for spelling? Arrgh. Richard Braakman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pre-dependency for fetchmail, fetchmail-ssl
On Sun, Dec 23, 2001 at 07:49:10PM +0100, Torsten Landschoff wrote: > On Mon, Dec 17, 2001 at 08:51:51AM -0600, Adam Heath wrote: > > > So you can never have two packages that depend on each other? > > > > Correct. > > Isn't there this loop break hack in dpkg to allow for that? Not that > I would suggest having two packages depend on each other... :) Actually a number of packages already have this. For example, libfoo depending on libfoo-runtime, while libfoo-runtime depends on libfoo. Unfortunately I didn't have the tools to find an example with which to prove Adam wrong, but I do remember a FAQ about such a situation, where people were told to upgrade by installing both packages in one dpkg invocation. Apt also has an algorithm for breaking such cycles. -- Richard Braakman Will write free software for money. See http://www.xs4all.nl/~dark/resume.html
Re: Student Looking for A Final Year Project
On Sun, Sep 09, 2001 at 12:11:58PM +0200, Guus Sliepen wrote: > Actually, one good solution is turning on the Nagle algorithm, or rather not > using TCP_NODELAY (I don't know if ssh sets it, but I guess it does to improve > responsiveness). What you propose will break situations where you have to type > one non-interesting key to invoke an action, people wait for it to happen but > it won't be sent out because of your proposed terminal type. The only way you > could safely do this is if the server side would send cues whether or not to > do > character/word/line buffering. This problem was solved for telnet, see RFC 1184. -- Richard Braakman Will write free software for money. See http://www.xs4all.nl/~dark/resume.html
Re: libgal sonames
On Sat, Sep 01, 2001 at 11:25:32AM -0500, Colin Watson wrote: > On Sat, Sep 01, 2001 at 05:23:03PM +0200, Rodrigo Moya wrote: > > The only problem I can see is with the -dev packages, which may need > > some work to allow different versions to be installed. > > That's OK. We often only support one version of -dev packages, so that > people don't build against soon-to-be-obsolete versions by accident. It becomes problem if the versions are not source compatible, however. Then packages become unbuildable every time we release a new libgal version (and update the single libgal-dev). It may be better to have packages that link with libgal (other than evolution and gnumeric) link statically instead of dynamically. This would be a workaround until libgal stabilizes. Presumably it will stabilize at some point -- either that, or someone will take the most useful parts of libgal and give them a stable interface in another library. There's obviously enough need for what libgal provides, otherwise there wouldn't be so many packages using it now. -- Richard Braakman Will write free software for money. See http://www.xs4all.nl/~dark/resume.html
Re: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)
On Thu, May 03, 2001 at 04:36:43PM +0300, Shaul Karl wrote:
[...]
> [16:24:46 tmp]$ bash -c 'echo x-${IFS}-x'
> x- -x
>
> Ah, something might be wrong with the above tests:
Right. The invoked shell will expand ${IFS} to a string that happens
to be whitespace, then parse the line as an "echo" command with
arguments "x-" and "-x", and invoke echo accordingly.
bash -c 'echo "x-${IFS}-x"'
will do what you expect.
Richard Braakman
Re: ITP: darj - arj archive unpacking tool
On Sat, Apr 28, 2001 at 09:36:28PM -0700, Alexander Hvostov wrote: > Why not put the core into a library (libdarj.so or something)? This > sounds like something that could be used by a multitude of programs > (eg, Nautilus). This would also allow you to make one program that > wraps the library and behaves like a proper unix utility, and then > another that mimics unarj. I've been thinking about that. Unfortunately a library is harder to write. For example, darj simply exits if it runs out of memory, and this simplifies the internal interfaces a great deal. But it's not polite in a library. I will consider this after finishing the unarj clone. I'm a fan of refactoring :) I'll have a much better idea of what should go into the library after I've designed two different tools that use it. > Are you planning to make a compressor at some point? I imagine if you > can figure out the format well enough to extract from it, it wouldn't > be much harder to be able to create/modify archives as well. A compressor tends to be much harder to write than a decompressor, actually. And I don't think arj as an archive format has much going for it these days -- it's designed for msdos file attributes and file types. It can't represent symbolic links, for example. So, no, I don't intend to write a compressor. Richard Braakman
ITP: darj - arj archive unpacking tool
(I filed this as bug#95252, but used X-Debian-CC instead of X-Debbugs-CC. Strange... I remember it being X-Debian-CC once.) darj - arj archive unpacking tool I've started writing a free version of unarj. I have unarj installed in case I come across .arj files on the net or on old floppies, and vrms listed it once too often :) So this is more of an "intent to write" than "intent to package", but I do intend to package it once it is done. I will duplicate unarj's interface as closely as I can (except for the banner), both for ease of regression testing and in case there are scripts that parse unarj's output. I considered going the other way and making it behave like a proper unix utility, but... maybe in version 2. Its current state is that it can list the files in an archive, but can't uncompress or extract them. I'm not looking for help (I'm having fun writing this), but if you have any unusual arj archives lying around then I would appreciate a copy for testing. When it's done I will release it under the GNU GPL. Richard Braakman
Re: 2.4.x Kernel, ECN And Problem Websites
On Thu, Apr 26, 2001 at 05:52:10AM +1000, Daniel Stone wrote: > Yes, I know this. The bits are officially "reserved" in the RFC. Some people > took this to mean, "must be zero". This reminds me of my favourite quote from RFC2795: The Version, Sequence Number, Protocol Number, and Reserved fields are 32 bit unsigned integers. For IMPS version 1.0, the Version must be 1. Reserved must be 0 and will always be 0 in future uses. It is included because every other protocol specification includes a "future use" reserved field which never, ever changes and is therefore a waste of bandwidth and memory. [6] [7] [8]. (Reference 7 is in fact to the TCP standard :) Richard Braakman
Re: NMUers: STOP BEING STUPID
On Tue, Apr 24, 2001 at 11:32:42AM +0200, Arthur Korn wrote: > Richard Braakman schrieb: > > In that case the right "repository" could be a bugreport to the package > > involved. That way the diff submission is guaranteed. > > I agree with you that _something_ has to be done about > catastrophal NMUs, but just stopping to NMU and only submitting > diffs, even on packages where it is clear that the maintainer > stopped working on them some years ago can't be the solution. Oh, I didn't mean _only_ sending the diff. It was an addendum to Shaleh's suggestion. The idea is to send the diff, then have someone else look at it, and then do the NMU. I don't think we have to appoint any official diff reviewers, it could be enough to say that the person doing the NMU has to be someone other than the person who prepared the diff. That way you make sure that the package is buildable and the NMU is considered sane by at least two people. Ironically, it won't prevent the problem that sparked this thread, namely a weird build environment on the machine where the NMU is compiled. > Why is "abbreviation" such a long word? So that you can practice on it. Richard Braakman
Re: NMUers: STOP BEING STUPID
On Mon, Apr 23, 2001 at 04:52:08PM -0700, Sean 'Shaleh' Perry wrote: > So perhaps we need to come up with some more structure for the bug parties. > Perhaps the right thing to do is have those involved create diffs of their > work > and place these in a repository for some group of devels responsible for the > party to look at. Once the patch has been approved, a NMU can happen in short > order. In that case the right "repository" could be a bugreport to the package involved. That way the diff submission is guaranteed. If the diff turns out to be defective, then this can be explained in that bugreport, and a corrected diff submitted later -- and the package maintainer gets the warm happy glow of nuclear catastrophe having been avoided. Richard Braakman
Re: FYI: dh_upx compresses i386 executables
On Sat, Apr 21, 2001 at 07:42:00PM -0300, Carlos Laviola wrote: > There is: just upx -d it. (you can even run md5sum before and after > compression/decompression to find out for yourself that the decompressed file > is the same as before.) Will upx -d work on a binary that was compressed with an older version of upx? The code I've seen doesn't seem to care much about that, so I wonder if the author considers it a design requirement at all. Richard Braakman
Re: Qt going GPL ...
On Mon, Sep 04, 2000 at 03:50:03PM +0200, Hugues Marilleau wrote: > And what about Debian GNU/Hurd and Debian Win32 ? They are not Unix > (Linux is ?) and only Qt/Unix is GPL ? I think this is a good reason > to *not* include KDE in Debian. If there is a free version, the rest is a matter of porting. We have lots of unix-specific packages. I don't see a problem here. Richard Braakman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#70269: automatic build fails for potato
On Tue, Aug 29, 2000 at 08:22:16AM +1100, Hamish Moffatt wrote: > On Mon, Aug 28, 2000 at 06:21:55PM +0300, Antti-Juhani Kaijanaho wrote: > > I doubt you know what the logic was. > > No, I don't, because I can't see any logic in excluding debhelper. I don't know how the decision ended up being made, but the argument I presented at the time is that a dependency on debhelper is far more likely to be versioned than the others are. A package that makes use of a new feature of debhelper is going to have to declare its own build-depends anyway. Richard Braakman
Re: (Bug horizon) Problem bugs
On Thu, Mar 30, 2000 at 11:12:27AM -0800, Chip Salzenberg wrote: > According to Richard Braakman: > > Package: gcc (debian/main). > > Maintainer: Debian GCC maintainers <[EMAIL PROTECTED]> > > 58412 r-base: Can't build from source > > 59819 gcc_2.95.2-7(frozen): fails to compile itself on m68k > > 61258 missing header files in include/asm on non-i386 architectures > > May I assume that the latter two bugs will not delay the release of > potato for i386? No, you may not. It is not possible to release architectures separately without causing major damage to the mirror network. We're all in this together. Richard Braakman
Re: Packages removed from potato
On Thu, Mar 30, 2000 at 03:17:17PM +0200, Adrian Bunk wrote: > On Thu, 30 Mar 2000, Richard Braakman wrote: > > >... > > Package: libgd-graph-perl (debian/contrib). > > Maintainer: Piotr Roszatycki <[EMAIL PROTECTED]> > > 59442 libgd-graph-perl: Missing files, missing dependencies > >... > > This also takes out rmagic. You're right. My apt installation was set up only for main, so I didn't notice. I've now removed rmagic from frozen as well. Richard Braakman
(Bug horizon) Problem bugs
The following packages have survived the bug horizon, in some cases twice, because they are too important to drop. These bugs will delay the release of potato. Package: boot-floppies (debian/main). Maintainer: Debian Install System Team 58266 [fixed in CVS] PCMCIA network install is broken 58779 boot-floppies: Can't boot on my Powerpc 58857 The boot floppies do not work with milex raid on root. 60218 [fixed in CVS] error when setting active partition 60306 [fixed in CVS] Serial console does not work on initial boot 60370 [fixed in CVS] libdb2 missing from base? 60371 [fixed in CVS] base, installation glitches (configure network, start ne w system) 60956 [fixed in CVS] ARM is not supported (patch included) 61229 boot-floppies: lilo.conf refers to /boot instead of / 61280 i386 bootdisks fail with 8 MB of memory [ New boot-floppies are almost ready ] Package: debianutils (debian/main). Maintainer: Guy Maor <[EMAIL PROTECTED]> 59121 run-parts hangs during /etc/cron.daily runs Package: dpkg (debian/main). Maintainer: Wichert Akkerman <[EMAIL PROTECTED]> 33237 /etc/alternatives/emacs not managed properly - /usr/bin/emacs doesn't r un emacs20 [STRATEGY] Switches to manual-mode too quickly, maintainer will look at it this weekend. 58091 package name "Eterm" --> "eterm" 60973 zope names itself Zope in the control Package: g++ (debian/main). Maintainer: Debian GCC maintainers <[EMAIL PROTECTED]> [HELP] For gcc/g++ bug reports to be sent to the upstream maintainers, certain procedures must be followed, so help from clueful people is required 48530 g++ [fixed in 2.96 CVS Feb 2000] [alpha]: internal compiler error build ing open-amulet [WAITING] Maintainer was contacted on Dec 12, awaiting reply. 55291 [alpha] g++ causes internal compiler error compiling hatman Package: gcc (debian/main). Maintainer: Debian GCC maintainers <[EMAIL PROTECTED]> 58412 r-base: Can't build from source 59819 gcc_2.95.2-7(frozen): fails to compile itself on m68k 61258 missing header files in include/asm on non-i386 architectures Package: libc6-dev (debian/main). Maintainer: Joel Klecker 59962 sys/ucontext.h shouldn't define ERR Package: nscd (debian/main). Maintainer: Joel Klecker 58367 nscd: 'broken pipe' error causes entire box to be unusable Package: pdl (debian/main). Maintainer: Raul Miller <[EMAIL PROTECTED]> 55268 [Strategy: use older version on alpha] PDL fails to compile on alpha
Re: important vs release critical bugs
On Wed, Mar 29, 2000 at 09:24:38PM +1000, Brian May wrote: > That sounds good in theory, but does it work in practise? I don't > think so. Last time I checked, we were fixing some 30 bugs per day. Let's not look only at the unmaintained packages. > I have a number of bugs, which I consider important, but not release > critical, that are at two years old. Some of these bugs should be easy > to fix, often I never received a single reply. > > I don't have time to chase up the maintainer when he/she does not > reply to my messages... If you don't, and nobody else does, and the maintainer apparently has no time for it... then the bug is not that important, is it? If it is, make time for it. Simply putting it on some list of "important bugs" will not magically change any of that. Pretty soon that list will contain most of our bugs database and it will be useless. 200 release-critical bugs are already too many to deal with. (We got 21 new ones just today. Simply reading all of them takes more than an hour.) Richard Braakman
Re: Uninstallable packages & testing
On Tue, Mar 28, 2000 at 01:20:33PM +1000, Anthony Towns wrote: > tkirc (not installable on any arch, depends on ircii, which isn't in > potato or woody) ircii is now in non-us. Richard Braakman
Re: 0 days till bug horizon
On Wed, Mar 29, 2000 at 03:05:26PM +1000, Brian May wrote: > How do you say "this bug is important enough to be fixed for frozen"? > > Often, for instance, there are times when a really simple bug causes a > package to break seriously for some users. While the package should > not get dropped if it isn't fixed in time, it still looks bad for > Debian as a whole if this stuff gets released. Basically that means you need to make up your mind :-) Either the bug means the package is unfit for release, and the package should be dropped or the release delayed until it is fixed; or it does not. Certainly it would be good if such a bug were fixed before the release, but that is true for nearly any bug, and we'd end up never releasing anything. If you think a bug is particularly important, then by all means do whatever you can to fix it, or call attention to the bug in some other way. Severity "normal" does not mean "please ignore this bug until the sun goes out". If you mark a bug release-critical, then that means I have to worry about it, and have to make other people worry about it. Please don't do that unless the bug really is critical to the release. Richard Braakman
Re: 0 days till bug horizon
On Tue, Mar 28, 2000 at 10:03:33AM +1000, Brian May wrote: > I set the severity to important, as I feel that bbdb support is > important for gnus, and also, because I think it should be easy to fix > (if you know what you are doing --- I don't). [...] > I don't think it is worth dropping the package though. Classic mistake. The "important" severity is misnamed. It doesn't mean "this bug is important", it means "this package is unfit for release". The bug was fixed today, though. Richard Braakman
Re: 0 days till bug horizon
On Mon, Mar 27, 2000 at 11:55:49AM -0600, Manoj Srivastava wrote: > This should not be a RC bug: bbdb works just fine for > emacs19/20, and even the basic package continues to work for XEmacs > (for VM users, for example). Only the interface between bbdb and gnus > in _one_ of the flavours of emacs is broken; does it justify yanking > bbdb despite the fact it works for a large number of people? That depends on what happens. Does the install process fail because xemacs20 happens to be installed? > Richard> Package: communicator-smotif-461 (debian/non-free). > Richard> Maintainer: Adam Heath <[EMAIL PROTECTED]> > Richard> 43849 communicator-smotif: Floating point exception error > Richard> [ We have netscape 4.72 to replace it, but not for all > architectures. --RB ] > > Technically, this is not a part of Debian, and does not, per > se, get released. I don't think that bugs on non-fee packages should > be considered RC. They are release-critical for that package. In any case, I think we should have at least one working Netscape to go with a release. It is a special case. Richard Braakman
Re: 5 days till Bug Horizon
On Wed, Mar 22, 2000 at 12:50:19PM +0100, Wichert Akkerman wrote: > Previously Richard Braakman wrote: > > Package: autofs (debian/main). > > Maintainer: Justin Maurer <[EMAIL PROTECTED]> > > 52132 autofs: Race condition when expiring autofs submounts leaves daemon > > crippled > > [STRATEGY] Patch available, waiting for reply from upstream > > We should probably go with the patch in the bugreport, it seems to work > nicely and I haven't seen any objections to it on linux-autofs. I agree. > > Package: cvs (debian/main). > > Maintainer: Tom Lees <[EMAIL PROTECTED]> > > 59543 cvs: cvs-makerepos does not exist > > Isn't this just "cvs init"? This probably refers to this comment in the template file: If you have not yet created these repositories, you can create them after cvs has been installed. Use the command 'cvs-makerepos' to create them with fairly standard permissions, or create them yourself using 'cvs init'. I don't think this is release-critical. Someone who discovers that cvs-makerepos isn't there will just try cvs init. > > Package: dpkg (debian/main). > > Maintainer: Wichert Akkerman <[EMAIL PROTECTED]> > > 58091 package name "Eterm" --> "eterm" > > This is a residue of a bug in another package which violated policy by > using a capital in the packagename. I wonder if I could get away with > simply lowercasing the package-names when reading the available-file.. Hmm, I don't understand the problem. dpkg is documented to be partially case-sensitive, with uppercase names being deprecated. Perhaps the problem is in apt? The reporter mentioned that "dselect/apt" wouldn't upgrade eterm, but dpkg did. > > Package: mh (debian/main). > > Maintainer: Edward Brocklesby <[EMAIL PROTECTED]> > > 59227 htdig: Apparent infinite recursion > > 59891 Security problem in MIME-handling code > > Can we drop this package and tell people to use nmh instead? I've been > thinking of releasing a security advisory to that effect.. Apparently Edward is working on an upload as I type this. > > Package: netbase (debian/main). > > Maintainer: Anthony Towns <[EMAIL PROTECTED]> > > 59282 netbase: portmap is killed too early on shutdown > > Hasn't this one been fixed by now? Something is up with netbase; it has loads of RC bugs now. This happens to be the only one older than the snapshot date. > > Package: smail (debian/main). > > Maintainer: Soenke Lange <[EMAIL PROTECTED]> > > [HELP] Mail to Soenke bounced. > > 59135 smail: Smail doesn't work with the latest libraries > > We seem to have a history of release-critical bugs for smail until just > before the release... is Soenke reading this, or has anyone contacted > him? The last smail upload was an NMU. The last maintainer upload was October 1998. I sent mail to Soenke today, but I do not have much hope of reaching him. I think no-one cares about smail anymore; we've all switched to sexier mailers, and new users get exim. It may be time to drop smail. Richard Braakman
Re: 5 days till Bug Horizon
On Wed, Mar 22, 2000 at 07:54:54AM -0500, Daniel Burrows wrote: > > Package: rep-gtk (debian/main). > > Maintainer: Mikolaj J. Habryn <[EMAIL PROTECTED]> > > 58684 rep-gtk_0.8-2(unstable): build error (prototype mismatch) > > This appears to be an upstream problem specific to that version, which isn't > in frozen (and may not even exist in unstable anymore..) Okay, I'm excluding it from the list. Version 0.7-1 is in potato now, and it's been compiled for all architectures. Richard Braakman
Re: new version in frozen?
On Wed, Mar 15, 2000 at 08:32:48AM +0100, Michael Meskes wrote: > I just checked through the bugs open against quota and found that quite a > lot of them are fixed in the new upstream version 2.00-pre4. Yes, it is not > final so far but probably will be pretty soon. Now I wonder if it is > possible to add this version to frozen. If not all bug fixes have to be > backported and frankly I'm not interested in that kind of work. Re-packaging > the new upstream version seems to be much less work. There is a point where backporting is actually more risky than using the (presumably tested) new upstream version. However, what else has changed in quota 2.00? Are there incompatibilities? Richard Braakman
Re: 14 days till bug horizon
severity 59202 normal thanks On Mon, Mar 13, 2000 at 07:36:12PM -0700, Bdale Garbee wrote: > In article <[EMAIL PROTECTED]> you wrote: > > > Package: pilot-manager (debian/main). > > Maintainer: Darren Stalder <[EMAIL PROTECTED]> > > 59202 pilot-manager: Method "GetRecord" missing in SyncPlan > > The pilot-manager package is quite useful even if SyncPlan doesn't work, which > I can neither confirm nor deny. If there's a problem and it can be fixed, > great, but don't remove this from potato just for this! It really isn't > release-critical in that sense. Then it's not release-critical at all. Richard Braakman
Re: 14 days till bug horizon
On Mon, Mar 13, 2000 at 07:32:06PM -0700, Bdale Garbee wrote: > In article <[EMAIL PROTECTED]> you wrote: > > > Package: sawmill (debian/main). > > Maintainer: Mikolaj J. Habryn <[EMAIL PROTECTED]> > > 59760 sawmill: Sawmill fails to load -- missing file > > /usr/lib/rep/0.11/i686-pc-linux-gnu/timers.so > > This is filed against version 0.25-1. The version in potato is 0.20.1-2.1, > which I am using on several machines quite happily. I use essentially all of > gnome with it except session management... and see none of the symptoms > described. > > I assume this means this is a bug against woody, not potato, and that this > bug should not affect the release of sawmill with potato? Yes. There is an exclusion mechanism for this, but it is hard to identify such bugs. (Looking at the version number is not enough, it needs someone to actually test it on the potato version, like you did.) Richard Braakman
