Re: Release-critical Bugreport for March 24, 2000
On 24-Mar-2000, Gregor Hoffleit [EMAIL PROTECTED] wrote: On Fri, Mar 24, 2000 at 03:15:02AM -0600, BugScan reporter wrote: Package: gnucash (debian/main) Maintainer: Tyson Dowd [EMAIL PROTECTED] 60417 docs are split between /usr/doc/gnucash and /usr/share/doc/gnucash 60615 gnucash: LANG=de_DE does weird things 60655 should depend on libesd0 | libesd-alsa0, not just libesd0 I just noticed that #60615 and 60655 are fixed in woody's gnucash package, gnucash_1.2.5.cvs.2204-1. #60417 is easy to fix. If the maintainer doesn't speak up now, I will take gnucash_1.2.5.cvs.2204-1, fix #60417 and upload it to frozen and unstable as NMU. Hi, I'm the maintainer for gnucash. An NMU would be great. I've run out of time to work on this stuff at the moment. I have a prospective new developer in the wings who would like to take over this package, but it hasn't been time to do this before potato is released. Tyson.
Re: Et voila! (was: Re: Slink not installable from CDs)
On 16-Oct-1998, Martin Schulze [EMAIL PROTECTED] wrote: Jason Gunthorpe wrote: I don't much care for the notion of a single master package file on the first CD.. I rather was intending APT to read the package files from each CD and use that to determine what is on which CD. (This fits with the URI Please implement it. Debian can only benefit from multiple ways to interoperate with multiple binary cd-roms. Please take a quick look at my proposal in the other part of this thread. Although I agree that it doesn't matter too much if we use an inferior method for this release while a better one is worked on. The proposal allows both schemes to work -- you can have one Packages file per CD, or multiple ones on the first CD. scheme, X-Media does not) Can we perhaps have a Packages.AllCds in some dir that has this header and leave the normal package files with their normal meaning (.debs avail at that URI) Na, we cannot! Doing this we would mixing up free, partially free and non-free stuff. The user still has to be able to install a completely free system. If he wants to use the other parts too, that's up to him. This is just a technical problem. There is no reason why the X-Media field has to be in the Packages files on the CD -- that information could be stored by the multi-cd method when it reads in the CD info. -- Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin Tyson Dowd [EMAIL PROTECTED] http://tyse.net
Re: Et voila! (was: Re: Slink not installable from CDs)
On 16-Oct-1998, Heiko Schlittermann [EMAIL PROTECTED] wrote: On Fri, Oct 16, 1998 at 02:39:38PM +1000, Tyson Dowd wrote: : : There is no reason why the X-Media field has to be in the Packages : files on the CD -- that information could be stored by the multi-cd : method when it reads in the CD info. ... but not, if the first CD contains all packages files (as our datom/schlittermann hamm-CDs do already ... ) Not true. There just needs to be an association between packages file and CD label. A file in each directory that says which CD the packages are on would be sufficient. E.g. /.packages/non-free/Packages.gz /.packages/non-free/media (contains CD 2) /.packages/main/Packages.gz /.packages/main/media (contains CD 1) Or something like that. The multi-cd approach is fairly well tested by (I think) the most of our customers. I know, that the current implementation is a rather bad hack, but due to limited time and since _nobody_ seemed to be able to solve this when hamm appeared, I've implemented is myself ... Yes, there are some drawbacks that should be solved, but probably not for slink ... Sure. You've done the work, and it will be fine for this release, but it's worth discussing ways we can improve on it in future. The basic scheme is fine, it's just the X-Media can be put elsewhere, which means the same pacakges files can be used everywhere. It would be *less* work to actually leave dpkg-scanpackages as it is, and just add this change to the multi-cd method. But *more* work has already been done, so it isn't necessarily worth changing now. -- Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin Tyson Dowd [EMAIL PROTECTED] http://tyse.net
Re: Differences of Debian vs. the Other Guys
On 02-Jun-1998, Javier Fernandez-Sanguino Pen~a [EMAIL PROTECTED] wrote: I'm currently writting an article for Linux Actual (an spanish magazine on Linux) about the Debian Packaging System (more on the .deb format than other policies) and I would like to make the BIG question, considering there is a lot of discussion about LSB. start big question --- What are the main differences/advantages/disadvantages of Debian's Packaging System vs The Other Guys (tm) ? --- end big question --- Manoj addressed most of the big differences in his mail. One that he missed (or glossed over) is the difference in generation of packages. dpkg encourages (practically enforces) building a package in a working directory, installing files to a temporary directory, and packaging from that directory. e.g.configure --prefix ./debian/tmp make make install package up ./debian/tmp is what the debian/rules file says. rpm encourages (practically enforces) building a package, installing it in /usr, then listing all the files that were just installed. e.g.configure --prefix /usr make make install package up all listed files This is very error prone. Three big problems can occur: 1. Maintainer lists files that were on their system, but were not generated by the source archive. This means that the source RPM cannot generate the binary RPM on anyone elses system (except perhaps if they install the binary first, then create the package -- but it's a risk, and might eventually lead to packages that cannot be effectively maintained). 2. Maintainer fails to list files that were installed. Package works fine for them, because they installed the files using make install, so all files are present. Package doesn't work for anyone else. 3. Package maintainers machines get full of junk files, because they are only *producing* packages for people, their own system is used to install packages. When I discovered this is how rpm works, I was very disappointed. dpkg has gone the extra mile, and done things properly, despite being a bit more difficult to implement. dpkg makes packaging quicker, cleaner, and less error-prone. Add to this the lovely cvs-buildpackage (automatically builds packages out of CVS archives), and dpkg is a formidable packaging system. .deb vs .rpm isn't much competition -- they are both functionally equivalent at this level (so are .tar.gz or a .zip files really). But when you look at the tools and process used to create a .deb versus a .rpm, I think RPM needs some work. But chances are there are things I don't know about RPM -- I looked at it a while ago. Good luck on your article. -- Tyson Dowd # So I asked Sarah: what's the serial number on # your computer? She replied: [EMAIL PROTECTED]# A-C-2-4-0-V-/-5-0-H-Z http://www.cs.mu.oz.au/~trd # -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Differences of Debian vs. the Other Guys
On 03-Jun-1998, Joel Klecker [EMAIL PROTECTED] wrote: At 23:38 -0700 1998-06-02, Tyson Dowd wrote: Manoj addressed most of the big differences in his mail. One that he missed (or glossed over) is the difference in generation of packages. Another one is that he didn't explain what dpkg-shlibdeps does. dpkg encourages (practically enforces) building a package in a working directory, installing files to a temporary directory, and packaging from that directory. e.g.configure --prefix ./debian/tmp make make install package up ./debian/tmp is what the debian/rules file says. That isn't the right way to do it, the executables may end up depending on being run from the same directory as the one they were built with (in practice, it doesn't seem that too many packages are like that, but it's good to keep it in mind). Oops, sorry, you are of course correct. -- Tyson Dowd # So I asked Sarah: what's the serial number on # your computer? She replied: [EMAIL PROTECTED]# A-C-2-4-0-V-/-5-0-H-Z http://www.cs.mu.oz.au/~trd # -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
New packages: xbae and xacc
Hi, I'm intending to package xacc (X Accountant), a financial tracking program (somewhat like quicken). It's a motif app, but works with lesstif, and is GPLed. Xacc uses the XbaeMatrix Motif widget (which provides a grid of fields, like a spreadsheet), so I'm going to package that as well. Xbae has a BSD-like license (which I include below in case anyone wants to give it a quick once over). -- Copyright (c) 1991, 1992 Bell Communications Research, Inc. (Bellcore) Copyright (c) 1995-97 Andrew Lister All Rights Reserved. Permission to use, copy, modify and distribute this material for any purpose and without fee is hereby granted, provided that the above copyright notices and this permission notice appear in all copies, and that the name of any author not be used in advertising or publicity pertaining to this material without the specific, prior written permission of an authorized representative of Bellcore and current maintainer. BELLCORE AND OTHER CONTRIBUTORS MAKE NO REPRESENTATIONS AND EXTEND NO WARRANTIES, EXPRESS OR IMPLIED, WITH RESPECT TO THE INFORMATION, INCLUDING, BUTNOTLIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR ANY PARTICULAR PURPOSE, AND THE WARRANTY AGAINST INFRINGEMENT OFPATENTS OR OTHER INTELLECTUAL PROPERTY RIGHTS. THE SOFTWARE IS PROVIDED AS IS, AND IN NO EVENT SHALL ANY AUTHOR OR ANY OF THEIR AFFILIATES BE LIABLE FOR ANY DAMAGES, INCLUDING ANY LOST PROFITS OR OTHER INCIDENTAL OR CONSEQUENTIAL DAMAGES RELATING TO THE INFORMATION. -- Tyson Dowd # If I'm unusually agressive in this email, it's # probably because USENET has been down here for [EMAIL PROTECTED]# over a week, and I'm missing my usual dosage http://www.cs.mu.oz.au/~trd # of flamewars. My apologies in advance. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: [Gonzalo A. Diethelm gonzo@ing.puc.cl] Re: Moving topics from debian-private (was Re: SPI money out)
On 17-Dec-1997, James Troup [EMAIL PROTECTED] wrote: Alex Yukhimets [EMAIL PROTECTED] writes: When doing 'g'roup reply in elm, the e-mail of the person goes into the To: header and list address (along with all other thread participant's adresses) to Cc: header. So, umm, fix elm? This isn't a solution. There are already fixed mailers, people aren't using them because they aren't even aware there is a problem. Debian doesn't just fix bugs, it provides mechanisms for those bug fixes to be send to where they are useful. Telling people in the web pages about the problems and recommending one of [gnus, mutt, other good mailer] *is* a solution. Munging reply-tos is another solution. Pick one. -- Tyson Dowd # If I'm unusually agressive in this email, it's # probably because USENET has been down here for [EMAIL PROTECTED]# over a week, and I'm missing my usual quota http://www.cs.mu.oz.au/~trd # of flamewars. My apologies in advance. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Moving topics from debian-private (was Re: SPI money out)
On 16-Dec-1997, Ian Jackson [EMAIL PROTECTED] wrote: Tyson Dowd: A couple of us discussed this (and other problems with the mailing list), in the thread Duplicate messages on this list in debian-devel about a week ago and eventually came to a standstill where most people in the discussion were happy with the following solution: Set the mailing lists up so that the headers are munged in the following way: [deleted] Please let noone think that just because that absurd and awful suggestion was the last thing anyone said that everyone is happy with it. Rather, the rest of us have more important things to do than to fight battles with people with broken mailers and broken ideas about how mailers ought to work. I'm sorry that you think a simple fix that would solve a potentially very embarrasing problem is too distateful to discuss. I have brought the matter up only when the current mail configuration has caused problems. I figured if it was important enough for Bruce to reply to the original poster and give a rap on the knuckles for jumping lists, then it's important enough to stop. If I've gone too far wasting people's time with these issues, I won't bring it up again - but I'd seriously recommend not using debian-private for anything that should remain private, until the world upgrades their mailers. Tyson. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Moving topics from debian-private (was Re: SPI money out)
On 16-Dec-1997, Christian Schwarz [EMAIL PROTECTED] wrote: Please check out http://www.unicom.com/pw/reply-to-harmful.html . The page contains several arguments against the use of Reply-To. I fully agree to what Ian said. Please don't quote this URL as if all the issues in this web page haven't already been discussed. Just because it's on a web page and uses the trendy considered harmful phrase doesn't mean it's relevant, and doesn't mean it's right. The reply-to munging solution is unfairly attacked, while the current configuration has at least as many drawbacks. The fact is, the current mail RFCs are not designed to cope with mailing lists. New mailers do a better job, but when we have new mail standards that have better mailing list support, their solutions will be considered impure too. I've also presented another solution, which is to just clearly document the problems on the web pages, so that developers are aware they need to be careful, and they should upgrade their software. I've offered to do the work for this solution, but haven't receieved any feedback on whether it should be done or not (I am truly more interested in stopping the various mail problems than winning any arguments). Tyson. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Duplicate messages on this list
On 08-Dec-1997, Manoj Srivastava [EMAIL PROTECTED] wrote: Hi, Kai == Kai Henningsen [EMAIL PROTECTED] writes: Kai [EMAIL PROTECTED] (Manoj Srivastava) wrote on 06.12.97 in Kai [EMAIL PROTECTED]: If I set a reply-to address for the list manually, then having it munged is not just being less pleasing, it is *broken* behaviour. Why should we break perfectly standard mail processing because some mailers are broken out there? Kai No such thing. It is pretty clear to me (after the discussion on Kai DRUMS) that there currently is no perfectly standard Reply-To: Kai processing; the header is used in too many incompatible ways. Umm, can it be that there is no perfectly standard Reply-To: processing simply because too many lists stomped right over the RFC 822's first two examples of reply-to usage (namely, for the author to send mail elsewhare)? I'll re-read the RFC's in question (because of my disk crash, I have lost my mirror), but I have yet to read anything to convince me to break reply-to's by munging them. Reply-To:s are already broken because there are no promises in RFC 822, merely suggestions about how you might use them. You claim the first two suggestions are more important than the last one (which approximates reply-to munging for the lists). Kai There are _no_ universally accepted, useful conventions for Kai Reply-To:. Sad but true. 822 was too imprecise in it's Kai definition, plus current mailing lists were unknown back then. From the quote on this mailing list, I think 822 was precise enough; but I am no expert. I'm not an expert either, but since we can both point to it and say it proves our point it seems quite inadequate! Since Kai seems to have some expertise in this area, I'm prepared to trust his judgement. Kai If you can't get your mailer to reply to From: when you want to, Kai complain to it's programmer - it's broken. I thought that is the author sets reply-to, then that should be used for replies, and not from. I can reply to from: unless there is a reply-to, when that takes precedence. If people munge reply-to, I'll never knoe, will I? As an aside, when munging reply-tos, if there is an existing reply to, why not set the From: to that address. From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Becomes: From: [EMAIL PROTECTED] Reply-To: debian-devel@lists.debian.org Surely this would address most of the concerns. Or am I missing something here (surely this has been thought of before). -- Tyson Dowd # # Linux versus Windows is a [EMAIL PROTECTED]#Win lose situation. http://www.cs.mu.oz.au/~trd # -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Duplicate messages on this list
On 06-Dec-1997, Manoj Srivastava [EMAIL PROTECTED] wrote: Tyson Considering most mailing lists seem to be configured to reject Tyson email that isn't From the person on the list, I find this is Tyson a pretty feeble argument. But it's the strongest argument for Tyson not munging Reply-Tos on mailing lists. Even the mail RFC (I Tyson forget the number) suggests using Reply-Tos for mailing lists. Chapter and verse, please. This may be the most valid of your arguments. Quote the RFC, and you may well have a point. RFC-822: 4.4.3. REPLY-TO / RESENT-REPLY-TO This field provides a general mechanism for indicating any mailbox(es) to which responses are to be sent. Three typical uses for this feature can be distinguished. In the first case, the author(s) may not have regular machine-based mail- boxes and therefore wish(es) to indicate an alternate machine address. In the second case, an author may wish additional persons to be made aware of, or responsible for, replies. A somewhat different use may be of some help to text message teleconferencing groups equipped with automatic distribution services: include the address of that service in the Reply- To field of all messages submitted to the teleconference; then participants can reply to conference submissions to guarantee the correct distribution of any submission of their own. Note: The Return-Path field is added by the mail transport service, at the time of final deliver. It is intended to identify a path back to the orginator of the mes- sage. The Reply-To field is added by the message originator and is intended to direct replies. It doesn't actually say mail lists, but I think this is what they meant by text message teleconferencing with automatic distribution services (it was written in 1983 ;-). This in particular addresses my concern of information leaving the list because private replies are the default. For what is essentially a technical discussion list, I'd rather have useful information recorded in the archives than in individual mail folders. Tyson With the current situation, what are the solutions to the 4 Tyson problems I outlined? -- and what is the likelihood of these Tyson solutions actually solving problems (as opposed to the spend Tyson 30 seconds pruning your headers solution, which given the Tyson number of CCs on this list, is clearly not workable). I think people should get decent mail user agents. I never have to spend time pruning CC's. (and when I use other mail user agents, I _do_ trim the headers to follow good ettiquette). I also think it is bad policy to break standards to cater to rude people (those who do not follow good net ettiquette). I accept your point that munging reply-tos is undesirable, but I'd like to mitigate the problems (particularly the messages jumping from one mailing-list to another -- this has bitten me, and it seems a number of other people). But if munging is unacceptable, I'm open to other suggestions. Simply recommending a few good mailers in the Internet of the Debian Developer's Reference talking about mailing lists (which is where it says no CCs) is a possible compromise (along with a quick explanation of the problems with the common mailers). I'd be happy to write the text for such a change and get it organized if you think this is a reasonable compromise. -- Tyson Dowd # # Linux versus Windows is a [EMAIL PROTECTED]#Win lose situation. http://www.cs.mu.oz.au/~trd # -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Duplicate messages on this list
On 02-Dec-1997, Manoj Srivastava [EMAIL PROTECTED] wrote: Hi, No, please don't muck with reply-to. That's evil. And if I hadn't lost my disk, I'd have a handy-dandy url for you. Hmmm. Try http://www.unicom.com/pw/reply-to-harmful.html Which, as we have discussed before on this list, is an incorrect assesment of the problem as it applies to the debian lists. 1. We have a policy of no cc:s, but nearly everyone uses them because there is no Reply-To: set. 2. We have information that should be on the list going into private email instead (where it is effectively *lost* to all other developers). 3. We have threads jumping from debian-private to debian-devel because people accidently add the wrong To: or Cc: header by hand after replying to the individual instead of the list. Nothing too confidential has been disclosed yet. 4. We are penalizing people with low-bandwith or high-cost net connections by forcing them to download things multiple times. On the plus side, in the very occasional situations where a Reply-To: is useful, we don't munge it. This is useful when you want to reply to someone in person, but their From: address doesn't work, or if you want to move a discussion from one mailing list to another (except that if people use group reply as advocated by that URL, it will probably just move it to *both* lists). I'd like it to be fixed, but it seems that there are a few people who have strong opinions on the matter, but are not prepared to discuss or fix the problems it causes. -- Tyson Dowd # # Linux versus Windows is a [EMAIL PROTECTED]#Win lose situation. http://www.cs.mu.oz.au/~trd # -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Duplicate messages on this list
On 05-Dec-1997, Tyson Dowd [EMAIL PROTECTED] wrote: I'd like it to be fixed, but it seems that there are a few people who have strong opinions on the matter, but are not prepared to discuss or fix the problems it causes. Sorry, this came out sounding harsher than it was supposed to. I just think that there are some problems that could really do with solving, and Reply-To: would do it at a relatively small cost. -- Tyson Dowd # # Linux versus Windows is a [EMAIL PROTECTED]#Win lose situation. http://www.cs.mu.oz.au/~trd # -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
