Re: RFC: The BTS, Severity: Fixed, etc. (Was: An idea for the BTS)
Hi, I think that not only should bugs be marked by the distributions they exist in, they should also be classified by architecture; since it is quite possible for a bug to only exist in a specific arch. This opens to dor for arch specific maintainers; which is not a bad idea since the original maintainer may not have access to all the diffrent architectures supported. manoj -- Always look over your shoulder because everyone is watching and plotting against you. Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: where is sed in slink?
Craig Sanders wrote: i remember the discussion, but the links were never made. i stopped caring about it when i found that apt could use both frozen and unstablesolves the problem without having to wait for our overworked ftp site manager. Unfortunately, that doesn't help me, since mirror can't do things like that and I need to kep a local mirror for other purposes. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hamm Beta: Delay #1
Roberto Lumbreras [EMAIL PROTECTED] writes: Here you have the log. Thanks. From looking at your log, as I expected, the problem occurs when you try to install emacs20 and cvs-pcl simultaneously. This is because elib is not being properly configured (by the emacsen-common script) before cvs-pcl. This is a bug, but I'm worried about having time to fix it before the hamm release. I do know what needs to be done (emacsen-common needs to depend on pkg-order and needs to use it to determine the install/remove script order). Brian, what's your take on this? It could conceivably affect a number of emacsen installs depending on the particular combination of emacsen add-on packages selected. I was of the opinion that this could wait for slink, but now that I can see more clearly that this could break a *bunch* of installs/upgrades (depending on what the user selects) I'm not so sure... I'm beginning to think that I need to fix this *now*. -- Rob Browning [EMAIL PROTECTED] PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Intent to package pavuk
Hi, I like to package pavuk. It is a wget like programm with optional GTK interface from http://www.idata.sk/~ondrej/pavuk/ Comments? Ciao, Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Mon, Jun 22, 1998 at 11:54:05AM -0400, Dale Scheetz wrote: In both these examples the cludge only hangs around for a while, while the epoch gets stuck on the version forever. Is it really that bad? You said you don't want the clutter of it but I can't really see how there is much clutter. I find Santiago's suggestion of a manual upgrade absurd. Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: where is sed in slink?
Joey Hess [EMAIL PROTECTED] writes: Unfortunately, that doesn't help me, since mirror can't do things like that and I need to kep a local mirror for other purposes. Yeah, I had to re-do my whole mirror setup to accomodate this. What I wanted was just an unstable mirror, but I had to switch to mirroring unstable and frozen. Fortunately a bunch of disk space rained on me at just the right time... -- Rob Browning [EMAIL PROTECTED] PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Mon, 22 Jun 1998, Dale Scheetz wrote: There has got to be a better way to deal with this problem (which is fundamentally a sorting problem). Santiago's suggestion of 2.0.7r-1 is more satisfying but, if you consider the situation, doesn't really resolve the long term problem any better. What we need here is a better way of dealing with this problem. My mind has no solution at the moment, but my gut says that there is one, so I will keep looking. The reason I think this is a continuing problem is that the next round of glibc development is just a likely to run through several preX versions before a release is made. IMO, the problem is caused by the fact that the packages are given the new version number before that version is actually released. how about using 2.07pre8-1, 2.07pre8-2, and so on for the next set of glibc pre-releases? maybe this should be policy for all pre-release packages? In the mean time, unless anyone can object within the next several hours, I will construct and upload a new release of glibc with the version number: 2.0.7r-1 cool, that'll solve the immediate problem. craig -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: intent to package: rplay
This sounds idential to nas, which is already in debian. Is it the same thing? Package: nas Status: install ok installed Priority: optional Section: sound Installed-Size: 1612 Maintainer: Steve McIntyre [EMAIL PROTECTED] Version: 1.2p5-2 Depends: libc6, xlib6g (= 3.3-5) Conffiles: /etc/init.d/nas c9e6d316838fb680851d8006f4d21c42 Description: The Network Audio System (NAS). The Network Audio System was developed by NCD for playing, recording, and manipulating audio data over a network. Like the X Window System, it uses the client/server model to separate applications from the specific drivers that control audio input and output devices. lantz moore wrote: RPlay is a flexible network audio system. RPlay, written by Mark Boyns [EMAIL PROTECTED], is provided under the GPL. Package: rplay Version: 3.3.0a2-4 Architecture: i386 Depends: libc6 Suggests: xpm, mpg123 Installed-Size: 521 Maintainer: lantz moore [EMAIL PROTECTED] Description: RPlay is a flexible network audio system that allows sounds to be played to and from local and remote Unix systems. Sounds can be played with or without sending audio data over the network using either UDP or TCP/IP. RPlay audio servers can be configured to share sound files with each other. . Support for RPlay is included in several applications. These include xpilot, xlockmore, xboing, fvwm, and ctwm. . mailsound or Mailsound can be used to play sounds when mail arrives. -- lantz moore, contigo software [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package pavuk
Only that someone else posted their intentions last week. Sorry. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Please follow protocol when you announce your Intents to package
I have seen numerous people post Intentions to package apps that are already being worked on. Please read the wnpp (it is made for a reason). And when you do announce you intentions PLEASE cc wnpp so that it gets added to the list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[OFF-TOPIC] UKUUG Linux Developers Event -- Who's going ?
Hi, Just wondering how many Debianites are signed up to attend the UK Unix User Group's Linux Developers Event this weekend (27-28 June) in Manchester, UK. BTW Anyone that is attending ought to bring a copy of their PGP public key, and proof of ID so we can do some key signing can happen. Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package pavuk
S == Shaleh [EMAIL PROTECTED] writes: S Only that someone else posted their intentions last week. Sorry. I am subscribed to debian-devel for a week, so I missed that. But I checked http://www.debian.org/doc/prospective-packages.html and there is no entry for it. Actually this site looks out of date. tcd is mentioned as worked on, but is available for slink. I hereby withdraw my proposal. Cc: goes to [EMAIL PROTECTED] as I received an ACK from them. Ciao, Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Hamish Moffatt [EMAIL PROTECTED] writes: On Mon, Jun 22, 1998 at 11:54:05AM -0400, Dale Scheetz wrote: In both these examples the cludge only hangs around for a while, while the epoch gets stuck on the version forever. Is it really that bad? You said you don't want the clutter of it but I can't really see how there is much clutter. I find Santiago's suggestion of a manual upgrade absurd. Here's another reason using the epoch for this situation is bad, if you continue the process you get something like: 2.0.6 2.0.7pre1 1:2.0.7 1:2.0.8pre1 2:2.0.8 2:2.0.9pre1 3:2.0.10 3:2.0.10pre1 4:2.0.11 ... Essentially you are completely overriding the version number with a hidden version number that the user isn't presented with. If we want to go this route we could just abandon sorting on upstream package version and number our releases sequentially. That may not be an unreasonable way to go, but it certainly isn't the system we're using now. greg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
X-tended input
Hi all, Where are the extended input modules for X in hamm? I mean the files that lived in /usr/X11R6/lib/modules with bo, like xf86Wacom.so? I need to have that module to run my Wacom tablet! Please get back to me! Thanks very much, Chris --- Debian GNU/Linux Ooohh You are missing out! --- Reply with subject 'key' for PGP public key. KeyID A9E087D5 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X-tended input
On Tue, Jun 23, 1998 at 02:33:13PM +1000, Chris wrote: Where are the extended input modules for X in hamm? I mean the files that lived in /usr/X11R6/lib/modules with bo, like xf86Wacom.so? xext -- G. Branden Robinson | Purdue University | The noble soul has reverence for itself. [EMAIL PROTECTED] | -- Friedrich Nietzsche http://www.ecn.purdue.edu/~branden/ | pgpF7PwHubOii.pgp Description: PGP signature
Re: intent to package: rplay
Joey This sounds idential to nas, which is already in debian. Is it the Joey same thing? no. while nas and rplay have simliar goals, they are different packages. Joey Package: nas Joey Status: install ok installed Joey Priority: optional Joey Section: sound Joey Installed-Size: 1612 Joey Maintainer: Steve McIntyre [EMAIL PROTECTED] Joey Version: 1.2p5-2 Joey Depends: libc6, xlib6g (= 3.3-5) Joey Conffiles: Joey /etc/init.d/nas c9e6d316838fb680851d8006f4d21c42 Joey Description: The Network Audio System (NAS). Joey The Network Audio System was developed by NCD for playing, Joey recording, and Joey manipulating audio data over a network. Like the X Window System, Joey it uses Joey the client/server model to separate applications from the specific Joey drivers Joey that control audio input and output devices. -- lantz moore, contigo software [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
bsd/sgtty.h
Hi! I've got a problem compiling csound with libc6. The source includes bsd/sgtty.h which is not in libc6-dev, but there's a sgtty.h. I've tried to use this one. But the compiler told me that he don't know the size of struct sgttyb. Any ideas? cu, Marco -- Uni: [EMAIL PROTECTED] Mailbox: [EMAIL PROTECTED] Fido: 2:240/5202.15 http://www.tu-harburg.de/~semb2204/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please follow protocol when you announce your Intents to package
On Mon, 22 Jun 1998, Shaleh wrote: I have seen numerous people post Intentions to package apps that are already being worked on. Please read the wnpp (it is made for a reason). And when you do announce you intentions PLEASE cc wnpp so that it gets added to the list. It probably wouldn't be a bad idea at all if a web-page was put together where ppl can submit which packages they are working on. If this is done using forms, there also wouldn't be the need for someone scanning all mailing-lists to build a wnpp list. Maarten _ | TU Delft, The Netherlands, Faculty of Information Technology and Systems | | Department of Electrical Engineering| | Computer Architecture and Digital Technique section | | [EMAIL PROTECTED] | - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Dale Scheetz writes: I like Santiago's suggestion better: 2.0.8pre1 = 2.0.7.99.1 2.0.8pre2 = 2.0.7.99.2 : 2.0.8 = 2.0.8 Which scales properly and solves the problem. Mmm, well, this was actually suggested by Vincent Renardias, but yes, I also like this proposal :-). I used a similar approach for procmail and smartlist (only similar, because I don't have a 99), with a clarification about the version number in the extended description. Well, it is know solution, but with a disavantage: we don't use upstream version number... -- Yann Dirson[EMAIL PROTECTED] | Stop making M$-Bill richer richer, isp-email: [EMAIL PROTECTED] | support Debian GNU/Linux: debian-email: [EMAIL PROTECTED] | more powerful, more stable ! http://www.mygale.org/~ydirson/ | Check http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Dale Scheetz writes: In the mean time, unless anyone can object within the next several hours, I will construct and upload a new release of glibc with the version number: 2.0.7r-1 I would advise for 2.0.7final instead. IMHO 2.0.7r looks much like an additional patch-level. -- Yann Dirson[EMAIL PROTECTED] | Stop making M$-Bill richer richer, isp-email: [EMAIL PROTECTED] | support Debian GNU/Linux: debian-email: [EMAIL PROTECTED] | more powerful, more stable ! http://www.mygale.org/~ydirson/ | Check http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Handling of pre/alpha/beta (Was: libc6_2.0.7 release notes...)
For all of you who seem interested by these issues of version numbering, I signal we started not long ago a thread in debian-policy about this. You'll find this under Summary: dpkg and alpha/beta versioning. I noted some possible ways of dealing with this issue that I did not include in my 1st summary; I will probably issue an updated one shortly. A number of us are of the opinion that we should take a decision on this once and for all, and that it gets included in the Packaging Manual. -- Yann Dirson[EMAIL PROTECTED] | Stop making M$-Bill richer richer, isp-email: [EMAIL PROTECTED] | support Debian GNU/Linux: debian-email: [EMAIL PROTECTED] | more powerful, more stable ! http://www.mygale.org/~ydirson/ | Check http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Craig Sanders writes: how about using 2.07pre8-1, 2.07pre8-2, and so on for the next set of glibc pre-releases? Seems like it doesn't work: $ dpkg --compare-versions 2.07pre8-1 '' 2.0.8 echo yes || echo no no -- Yann Dirson[EMAIL PROTECTED] | Stop making M$-Bill richer richer, isp-email: [EMAIL PROTECTED] | support Debian GNU/Linux: debian-email: [EMAIL PROTECTED] | more powerful, more stable ! http://www.mygale.org/~ydirson/ | Check http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: The BTS, Severity: Fixed, etc. (Was: An idea for the BTS)
Rob Browning writes: Yann Dirson [EMAIL PROTECTED] writes: [Note: I don't know much about the internals of the BTS; I hope this will be accurate enough, though] * These fields would be named by the codename of the dist (eg. `hamm_status') - can this be achieved easily ? Why not just go with something more heirarchical like: Status: (hamm fixed) (bo known-workaround) That may be easier to implement - what do the BTS maintainers think ? etc. That way we don't have a potentially ever growing number of fields, just field contents... Well, I forgot to insert: * When a dist is dropped (is that exactly when a new stable is released ?), the corresponding status field can simply be dropped from the bug db. That should fix the problem. However, it may be good to keep the field for a dist for some time after it is dropped, to allow people who did not upgrade yet to report bugs correctly for the dist they use, and get some info about bugs they suffer from, which have been fixed in the next release ;) -- Yann Dirson[EMAIL PROTECTED] | Stop making M$-Bill richer richer, isp-email: [EMAIL PROTECTED] | support Debian GNU/Linux: debian-email: [EMAIL PROTECTED] | more powerful, more stable ! http://www.mygale.org/~ydirson/ | Check http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Here's another reason using the epoch for this situation is bad, if you continue the process you get something like: 2.0.6 2.0.7pre1 1:2.0.7 1:2.0.8pre1 2:2.0.8 2:2.0.9pre1 3:2.0.10 3:2.0.10pre1 4:2.0.11 ... No, that's not what happens at all. It's more like this: 2.0.6-1 2.0.6-2 2.0.7pre1-1 2.0.7pre2-1 Doh! (maintainer thinks: ``I just used a version number that will clearly cause a sequence problem. Oh well, this is the situation epochs were created for, but I'll have to think of an alternative the next time) 1:2.0.7-1 1:2.0.7-2 1:2.0.8-0pre1.1 1:2.0.8-0pre1.2 1:2.0.8-0pre1.2.1 (NMU) 1:2.0.8-1 etc. RANT If people weren't being childish about the addition of 2 characters to the changelog, which the users generally never see, we wouldn't be having this discussion. I think we need a policy statement saying that packages uploaded with kludgey version numbers (that are clearly there to avoid the introduction of an epoch) will not be allowed into the archive. Otherwise we will be getting a repeat of this discussion on a bi-monthly basis for all future time. People make mistakes choosing version numbers, and we have a mechanism for recovering these mistakes. People being ``inventive'' so they can maintain the aesthetic beauty of a control file that is rarely seen by anyone is a waste of all our time. Use the tools provided! /RANT Hmm. I feel better for that :-) Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
-BEGIN PGP SIGNED MESSAGE- On Tue, 23 Jun 1998, Hamish Moffatt wrote: On Mon, Jun 22, 1998 at 11:54:05AM -0400, Dale Scheetz wrote: In both these examples the cludge only hangs around for a while, while the epoch gets stuck on the version forever. Is it really that bad? You said you don't want the clutter of it but I can't really see how there is much clutter. I find Santiago's suggestion of a manual upgrade absurd. It may be true that forcing our users to upgrade by hand one day before the beta release day, once that hamm is in deep freeze mode, and once that lots of people have already installed hamm is a great inconvenience for many of them and a bad idea, but it would not be the first time we tell our users to upgrade a package by hand (remember the upgrade from Debian 1.2 to 1.3?). So the issue about being absurd or not would be relative, not absolute. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNY90HCqK7IlOjMLFAQFpKgP7BaV8lbBqBUICCNsLCYxGHxlG93CWSyOJ 57IvvumGv6RwR565sRHxJpMA38DZGfyTenGtU9HQj0VjrvoQnk0J80xSONkTCTwF UYLiAsgx6+sR9/PPf5TRRziofwJBeMwp+ozksT0bHeqVmTeIFCeolMLScfbuDYuB ZYYnkDAyJjU= =PCNn -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
[EMAIL PROTECTED] said: Dale Scheetz writes: In the mean time, unless anyone can object within the next several hours, I will construct and upload a new release of glibc with the version number: 2.0.7r-1 I would advise for 2.0.7final instead. IMHO 2.0.7r looks much like an additional patch-level. Um. f comes before p in the alphabet, whereas r comes after p. 2.0.7final 2.0.7pre 2.0.7r Craig Sanders writes: how about using 2.07pre8-1, 2.07pre8-2, and so on for the next set of glibc pre-releases? Seems like it doesn't work: $ dpkg --compare-versions 2.07pre8-1 '' 2.0.8 echo yes || echo no no You missed a dot out of the first one (should be 2.0.7pre8-1) I'd go and get some sleep, or a coffee, if I were you, Yann ;-) Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Upgrade report from bo to hamm :-(
On Tue, Jun 23, 1998 at 05:07:37AM +0200, Paul Seelig wrote: [...] The initial update to libc6 via the autoup.sh went very smooth and flawlessly. I fetched the .deb packages via FTP over a decent bandwith and this went pretty fast. The bad thing afterwards was the painfully slo o o o o w w w w unpacking and installation process with dpkg especially on the slower machine, but believe me, this was no fun either on the K6 machine. The final killer was the configuration process at the end which asked questions i wouldn't really want to bother answering and where i mostly simply accepted the default by constantly pressing enter. Can't this be automated and the questioning be minimized to a more acceptable degree? I would like to see an upgrade mechanism which would allow me to start it and go home, checking all configuration issues the next morning. I see no problem in packages dictating the sysadmin a certain default, possibly coming along with a nice script for later customization and fine tuning. [...] There are a few problems with our current package-installation process: 1) dpkg takes a lot of time to start. 2) dpkg takes a lot of time recursing down the directory tree to install a few packages only. 3) there's no way to do unattended installations. but luckily, there are a few answers too: 1) dpkg uses plain text databases. It takes a lot of time to parse them to build its internal tables. IIRC, dpkg-next-generation (the one that is being actively developed, and probably will be in slink RSN) doesn't use the text databases directly, it uses hash tables to speed the process. 2) dselect methods are the ones that call dpkg with the recursive option. If you use one of the new methods (dpkg-mountable, apt, ...) you will find they don't do recursive installs anymore. You won't have wait for hours while a list of Skipping foo. Skipping bar. is displayed at the screen. 3) Now that is a big problem. And one that has been discussed frequently. I can't remember what was the final decision (if any) that came out of the last thread, but you may find it at debian-dpkg or debian-admintool maillists archives. Thanks, -- Enrique Zanardi[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#23742: emacs19 should probably be just emacs
-BEGIN PGP SIGNED MESSAGE- On 21 Jun 1998, Mark W. Eichin wrote: Perhaps you could review the discussion 6 months ago (or more!) when we first concluded that this was the *only* way it would work... Is anybody able to do a brief summary, please? If emacs is abolished as a virtual package name, what is the point in forbidding a package to name itself as emacs? Users *will* get somewhat confused. Then again, that's because they don't read the release notes, or perhaps don't run autoup which I think handles this gracefully. Users should not be forced to use any particular upgrade method. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNY93oSqK7IlOjMLFAQFc9AP+ILrYcHwP+N0LLzkEA8ReV/I1VHbtuKmJ +Zj2pdZ5LC5OJ4/s2F1zb6Qi5kRoQTHqzJ9V6UYTE3Z/Qi2d/x+gcgpqf1zJAtaH S8To9zN5ME4lmM1b5iTrOtGScQ7smFm0G3plH+XdBt1lCVtxhXhG11p2Iy4Ir73o IqRQyQze6/o= =YXSb -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hamm Bug Stamp-Out List for June 22, 1998
-BEGIN PGP SIGNED MESSAGE- Hi. Guy Maor said to me a few days ago that he will fix all non-wishlist bugs against ftp.debian.org before release. However, normal bugs against ftp.debian.org are not in the list of important or higher bugs. So please include all ftp.debian.org normal bugs in the list, or better, scan the bug list for ftp.debian.org for bugs about hamm and raise them to important. I'm Cc:ing debian-devel and Guy Maor. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNY961yqK7IlOjMLFAQG28AP+MQWiDTNbesUCcCBMJlBh2qGNuPkhDswF bSVeIsWKPrs/uyW//RUwP89+r6MdQErLypE0YwubjAO5w95JcN9NoCUOkoGZDUJb RJQwnbJrDDqYdG8JDh3caQvyE5ak3dfN4Dy9rJhdK7oUt66OPcWMxFvHue661aUn gkotzefwQIo= =hDPL -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Tue, 23 Jun 1998, Philip Hands wrote: Yann Dirson wrote: Craig Sanders writes: how about using 2.07pre8-1, 2.07pre8-2, and so on for the next set of glibc pre-releases? Seems like it doesn't work: $ dpkg --compare-versions 2.07pre8-1 '' 2.0.8 echo yes || echo no no You missed a dot out of the first one (should be 2.0.7pre8-1) I'd go and get some sleep, or a coffee, if I were you, Yann ;-) actually, it was me who forgot the . before the 7. Yann just copied my mistake. after looking at some of the other comments, i'd change my suggestion to 2.0.7pre8.1-1 for pre-release #1 2.0.7pre8.2-1 for pre-release #2 2.0.7pre8.3-1 for pre-release #3 alternatively, 2.0.7pre8#1-1 (but i don't think # is a valid character and having to escape the # would be an annoyance on the command line and scripts/config files which use # as the comment char.) any of the similar suggestions would be fine too. the exact form doesn't matter, as long as it a) works :) and b) the meaning of the version number is fairly clear. whatever format is chosen, it should be put in policy so that we don't have to figure it all out again in future, and also document a new standard/convention. craig -- craig sanders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release management - technical
Enrique Zanardi wrote: On Mon, Jun 22, 1998 at 01:38:21PM +0100, Ian Jackson wrote: Enrique Zanardi writes (Re: Release management - technical): On Tue, Jun 09, 1998 at 04:21:57PM +0100, Ian Jackson wrote: ... I think we can only do one of these. With hamm we're doing the latter; in the future I think we should do the former. Fine, as long as we have some long term goals that must be achieved, better sooner than later (FHS compliance, for example). NO! Absolutely not, if you're going to say `must be achieved'. I read `must be achieved' to mean `we will delay the release if these are not achieved'. Oops. That's not what I wanted to express. Long-term goals shouldn't delay the release. Personally I have the feeling that it should read must be achieved but that long-term-goals should be broken up in realisable chunks. Otherwise there is never a deadline for things and even if you can't coerce somebody to do something, a dealine still forces some preassure on people. (This is incidently the reason why the freeze caused so many uploads and made the distribution unstable for a while). In the libc5 to libc6 changeover we had get the fundamental libs going and then get the apps those landmarks could have made a realease possible. The problem, IMHO is that we were to ambitious not that it is inherently wrong to strive for some release goals. I agree. An example of long term goal is apt. We want to substitute dselect with apt eventually, and there is a group of volunteers working towards it, but that goal won't delay hamm's release.. But getting the command-line backend working is one of the subgoals and having it has produced a release landmark. Luis. -- Luis Francisco Gonzalez [EMAIL PROTECTED] PGP Fingerprint = F8 B1 13 DE 22 22 94 A1 14 BE 95 8E 49 39 78 76 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: The BTS, Severity: Fixed, etc. (Was: An idea for the BTS)
Previously Manoj Srivastava wrote: I think that not only should bugs be marked by the distributions they exist in, they should also be classified by architecture; Actually, I think we can do the same way more efficent. Each bug already has a Version-number. Now we if we add a field Fixed-in-Version the BTS can simply look for which architectures the fixed version is available. Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgpDOdEGKzz3a.pgp Description: PGP signature
Bug-System: Why no mail to maintainer on reassign?
Hello! When a new bug is reported against a given package, the package maintainer gets this bug report as a personal mail. I consider this really useful as the maintainers don't have to check the bug-lists to know if there are new bug reports against their packages. Later someone will reassign that bug to the correct package, but the maintainer of that package won't get any mail. He won't notice the existance of that bug until he checks the Bug-System online. I suggest if a bug report is reassigned to a given package the maintainer of that package gets the bug report as well as any replies to it. I didn't file this as a bug against bugs.debian.org as I am not very long on the debian-lists and I fear I touch some old, well discussed point here. ;) So, suggestions appreciated. Florian --- Florian Hinzmann [EMAIL PROTECTED] [EMAIL PROTECTED] NEW PGP-Key fingerprint: DD 61 74 34 04 FB 8A BD 43 54 83 38 0C 82 EF B1 pgp5uhAo7oInZ.pgp Description: PGP signature
Re: Bug-System: Why no mail to maintainer on reassign?
Florian Hinzmann [EMAIL PROTECTED] writes: Later someone will reassign that bug to the correct package, but the maintainer of that package won't get any mail. That's simply not true. -- James ~Yawn And Walk North~ http://yawn.nocrew.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Tue, 23 Jun 1998, Yann Dirson wrote: Dale Scheetz writes: In the mean time, unless anyone can object within the next several hours, I will construct and upload a new release of glibc with the version number: 2.0.7r-1 I would advise for 2.0.7final instead. IMHO 2.0.7r looks much like an additional patch-level. As f comes before p in the ascii sort, this is no better than 2.0.7. Both will be treated as a downgrade. Check out: dpkg --compare-versions '2.0.7final' '' '2.0.7pre3'; echo $? 0 (Thanks Rob ;-) This will return 0 0, indicating 2.0.7final is less than 2.0.7pre3 Next time check out your suggestion before proposing it ;-) Luck, Dwarf -- _-_-_-_-_- Author of The Debian Linux User's Guide _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Tue, 23 Jun 1998, Yann Dirson wrote: Dale Scheetz writes: I like Santiago's suggestion better: 2.0.8pre1 = 2.0.7.99.1 2.0.8pre2 = 2.0.7.99.2 : 2.0.8 = 2.0.8 Which scales properly and solves the problem. Mmm, well, this was actually suggested by Vincent Renardias, but yes, I also like this proposal :-). I used a similar approach for procmail and smartlist (only similar, because I don't have a 99), with a clarification about the version number in the extended description. Well, it is know solution, but with a disavantage: we don't use upstream version number... Well, only for the pre-release versions. The release version (the one we expect to distribute) does match the upstream in the above proposal. In the current scheme all the pre-release version numbers are correct, but the release version must be changed, and will not match upstream. I like the proposal much better. It also is reasonable enough that even the glibc upstream maintainer might be encouraged to adopt our numbering scheme. Waiting is, Dwarf -- _-_-_-_-_- Author of The Debian Linux User's Guide _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Philip Hands [EMAIL PROTECTED] writes: RANT If people weren't being childish about the addition of 2 characters to the changelog, which the users generally never see, we wouldn't be having this discussion. [...] Use the tools provided! /RANT (Sorry for the AOL, but...) Well said; I wish people would get over their epoch-phobia already. -- James ~Yawn And Walk North~ http://yawn.nocrew.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On 23 Jun 1998, James Troup wrote: (Sorry for the AOL, but...) Well said; I wish people would get over their epoch-phobia already. And I wish people would stop suggesting a poor solution. Epochs are not, were never, intended to be used for this purpose. They are only for dealing with upstream renumbering that would cause conflicts. This is not a phobia, but an unwillingness to use the wrong method. Luck, Dwarf -- _-_-_-_-_- Author of The Debian Linux User's Guide _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Tue, Jun 23, 1998 at 11:23:43AM +0200, Santiago Vila wrote: On Mon, Jun 22, 1998 at 11:54:05AM -0400, Dale Scheetz wrote: In both these examples the cludge only hangs around for a while, while the epoch gets stuck on the version forever. Is it really that bad? You said you don't want the clutter of it but I can't really see how there is much clutter. I find Santiago's suggestion of a manual upgrade absurd. It may be true that forcing our users to upgrade by hand one day before the beta release day, once that hamm is in deep freeze mode, and once that lots of people have already installed hamm is a great inconvenience for many of them and a bad idea, but it would not be the first time we tell our users to upgrade a package by hand (remember the upgrade from Debian 1.2 to 1.3?). So the issue about being absurd or not would be relative, not absolute. Actually I don't remember that upgrade, although I have performed it a few times (but not in a year or more). However in this case it would only be for aesthetic reasons, which I don't think is good enough. Fortunately 2.0.7r seems to be a good enough solution. Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Tue, Jun 23, 1998 at 09:52:05AM +0100, Philip Hands wrote: If people weren't being childish about the addition of 2 characters to the changelog, which the users generally never see, we wouldn't be having this discussion. Well said, Phil. Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Tue, Jun 23, 1998 at 08:32:41AM -0400, Dale Scheetz wrote: On 23 Jun 1998, James Troup wrote: (Sorry for the AOL, but...) Well said; I wish people would get over their epoch-phobia already. And I wish people would stop suggesting a poor solution. Epochs are not, were never, intended to be used for this purpose. They are only for dealing with upstream renumbering that would cause conflicts. This is not a phobia, but an unwillingness to use the wrong method. The upstream version numbering is incompatible with our package management tool, which seems to fit your reason just fine. Therefore use epochs. Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#23742: emacs19 should probably be just emacs
On Tue, Jun 23, 1998 at 11:39:31AM +0200, Santiago Vila Doncel wrote: Is anybody able to do a brief summary, please? If emacs is abolished as a virtual package name, what is the point in forbidding a package to name itself as emacs? Because we cannot banish it for all time past. Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug-System: Why no mail to maintainer on reassign?
On 23-Jun-98 James Troup wrote: Florian Hinzmann [EMAIL PROTECTED] writes: Later someone will reassign that bug to the correct package, but the maintainer of that package won't get any mail. That's simply not true. I've read some bug reports online containing entries saying Report forwarded or Information forwarded after both the initial bug report and any replies. I thought this kind of entries are generated everytime any mail is being sent by the bug system. Reading www.debian.org/Bugs/db/23/23725.html I found an initial entry Information forwarded, but no additional entry after the reassignment. I thought: No entry -- No mail has been sent. And I took a part of www.de.debian.org/Bugs/server-control.html as a confirmation for my assumption: --- reassign bugnumber package Records that bug #bugnumber is a bug in package. This can be used to set the package if the user forgot the pseudo-header, or to change an earlier assignment. No notifications are sent to anyone (other than the usual information in the processing transcript). --- If mail is sent to the maintainer on reassignments and just no entry stating this is generated for some reason then I am satisfied and will be quiet. ;) Greetings Florian --- Florian Hinzmann [EMAIL PROTECTED] [EMAIL PROTECTED] NEW PGP-Key fingerprint: DD 61 74 34 04 FB 8A BD 43 54 83 38 0C 82 EF B1 pgp5WxASYqaXf.pgp Description: PGP signature
Debian and gnuhoo.com
Last week I received mail from the people at gnuhoo.com asking that we submit an entry for Debian. It sounded like a good idea and put it (low down) on my list of things to do and didn't give it another thought until today. Slashdot has an article about gnuhoo.com that people might want to read (http://slashdot.org/articles/9806230849239.shtml). While I'm not as upset as some of the people who wrote in, I must admit that the name almost lead to me making a contribution. It definitely evokes the impression of a free software project. Debian should not contribute to a 'free' project if it is not based on Open Source. Hopefully GNU is trademarked and they will be forced to change the name. We can't stop anyone from contributing an entry for Debian, but please don't make one. Jay Treacy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Dale Scheetz [EMAIL PROTECTED] writes: On 23 Jun 1998, James Troup wrote: (Sorry for the AOL, but...) Well said; I wish people would get over their epoch-phobia already. And I wish people would stop suggesting a poor solution. How is it a ``poor'' solution? I'll tell you what _is_ poor and that's the absurd suggestion that we abandon the convenience of dpkg and friends and force people to do by hand upgrades of several (including an essential one) packages. Epochs are not, were never, intended to be used for this purpose. They are only for dealing with upstream renumbering that would cause conflicts. Wrong. | It is provided to allow mistakes in the version numbers of older | versions of a package, and also a package's previous version | numbering schemes, to be left behind. [ Packaging Manual; Chapter 5 ] This is not a phobia, but an unwillingness to use the wrong method. IMO it clearly *is* a phobia; and we are stuck with the timezones/timezone farce for the same reason. [ BTW: I'm happy with 2.0.7r; or rather happy with anything other than 2.0.7-1. I'm just annoyed by the recurring debate about epochs and phobics wanting to bypass them. ] -- James ~Yawn And Walk North~ http://yawn.nocrew.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hamm Beta: Delay #1
Thanks. From looking at your log, as I expected, the problem occurs when you try to install emacs20 and cvs-pcl simultaneously. This is because elib is not being properly configured (by the emacsen-common script) before cvs-pcl. This is a bug, but I'm worried about having time to fix it before the hamm release. Just to be sure I understand... emacs20 has to be configured before cvs-pcl is _installed_ or before cvs-pcl is _configured_? I do know what needs to be done (emacsen-common needs to depend on pkg-order and needs to use it to determine the install/remove script order). Brian, what's your take on this? It could conceivably affect a number of emacsen installs depending on the particular combination of emacsen add-on packages selected. I was of the opinion that this could wait for slink, but now that I can see more clearly that this could break a *bunch* of installs/upgrades (depending on what the user selects) I'm not so sure... Since you're unfamiliar with pkg-order, it sounds like starting to use it could be a source of other problems. I'd rather avoid that. What is the fix if it breaks? Can somebody just do dpkg --configure emacs20 cvs-pcl once the rest of the install is finished? Brian ( [EMAIL PROTECTED] ) --- Only half the people in the world are above average intelligence. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Including non-PIC code in a shared library?
Hi,
I finally got packages of libGGI built and uploaded. I was quite pleased
to find that the generic debian/rules that I've been using for the last
9 months really -does- work correctly for multiple binary packages.
I always thought it would, but never had a multi-binary package to try
it on. ;-)
But, to the point. LibGGI has various display targets, each
of which is kept in a separate *.so file under /usr/lib/ggi/.
The problem is that the xf86dga target contains code linked in from
/usr/X11R6/lib/libXxfs86{dga,vm}.a. This code in compiled non-PIC, and
lintian complains about it; that's why the xf86dga target is missing in
the current release, ICYWW.
I asked about this on ggi-devel, and the responses I got indicated that
it probably wasn't a problem, because there would only ever be one
libGGI program running the xf86dga target at once on a given machine
(not true for multi-headed machines) and that if multiple copies were
run, the kernel would simply load multiple copies of the code. I'm a
little worried that mixing PIC and non-PIC code might do some other harm.
Does it? Or will it just make this shared object unsharable?
Thanks,
--
Charles Briscoe-Smith
White pages entry, with PGP key: URL:http://alethea.ukc.ac.uk/wp?95cpb4
PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
xanim plugins
Here is the reply from xanim author regarding xanim plugins. I also tried to prod him for making it free software, but apparently that is not happening because he is making money on xanim. --- Forwarded Message From: [EMAIL PROTECTED] (Mark Podlipec) Message-Id: [EMAIL PROTECTED] Subject: Re: Some random ideas for xanim. To: [EMAIL PROTECTED] (Igor Grobman) Date: Sun, 21 Jun 1998 23:10:58 -0400 (EDT) In-Reply-To: [EMAIL PROTECTED] from Igor Grobman at Jun 21, 1998 10:50:25 AM Organization: Bay Networks Inc. Billerica MA X-Mailer: ELM [version 2.5 PL0b2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-UIDL: 91f0cf1af168d22bc3c40f68a2cad7e7 Hi! This is your debian maintainer yet again ;-). Oh no. :^) This thread, a message from which I forwarded below started with someone looking for codec modules for alpha, finding them, and suggesting we include them all (i386, alpha and other platforms) in the debian source package. The rest of this small thread can be seen below... Plug-ins instead of objects that have to be compiled in is an interesting idea. Yes, it is and it will happen for some platforms. I'm working on redefining the video/audio decompression API's. Once that happens, I plan on also setting up plugins. However note that Linux isn't quite stable enough to be worth working on plugins. They're making major changes to the libraries and are breaking things left and right. readdir() and dynamic loading are two key things that broke between revs. So they'll need to recompile anyways. Also, while we are on the copyright subject, is there a good reason you have the non-commercial use restriction on xanim? Yes, that's how I pull in enough money to keep developing xanim. It's how I buy the machines, peripherals and software needed. It's how I hire the lawyers and how I pay for licensing some of the codecs. I hate when someone pushes ideas onto others as much as the next guy, but I think some of my ideas are good ;-), so take this with a grain of salt or skip it if you've already seen too much free software advocacy. I really hate non-commercial use clauses on otherwise free software, because it puts a big restriction on the user usually without a good reason. Do you have someone paying you for a commercial license? Yes, it is currently being licensed. ... restrictive, but makes sure software stays free. If the reason for your non-commercial use clause is the fear of someone taking your code and making money on it, GPL will protect your code from that occurence. GPL doesn't do that at all. GPL just prevents them from claiming they wrote it and makes sure they will make the source available. Also keep in mind that without the codecs, xanim is not that useful. ... As you suspect my point is to convince you of applying one of the free licenses to xanim. It would be really cool if you did that, since that would produce the first truly free viewer for some of the video formats. While I agree in principal, I don't believe I could continue working on xanim if it didn't pay its own way. While I'm sure others would pick it up, I happen to like working on it. Mark --- End of Forwarded Message -- Proudly running Debian Linux! Linux vs. Windows is a no-Win situation Igor Grobman [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Including non-PIC code in a shared library?
On Tue, Jun 23, 1998 at 03:39:07PM +0100, Charles Briscoe-Smith wrote: little worried that mixing PIC and non-PIC code might do some other harm. Does it? Or will it just make this shared object unsharable? Everything I've ever heard suggests that the GGI people are correct---it will merely be unshareable because the pages all get dirtied doing fixups on the absolute addresses. Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Offering packages
I'm offering most of my packages. I will still maintain those of them, which nobody wants to take over. Maintenance of most these packages is trivial, upstream releases are rare. Since some of them are related to Czech, Slovak, or Latin-2 environment, it could be good opportunity for someone from Czech Republic or Slovakia to take some of them and become a new Debian maintainer. The list of offered packages: comm/casio - Casio diary backup utility text/cstocs - recoding utility (Latin-2 countries charsets mostly) devel/cweb - literate programming in C/C++ devel/cweb-latex- CWEB with LaTeX editors/emacs-czech - Czech and Slovak support for Emacs 19 games/fortunes-cs - Czech and Slovak fortunes math/sgb- The Stanford Graphbase x11/xntil2 - Latin-2 fonts for X x11/xtoolwait - serializing startup of X applications I would be especially happy if anyone took sgb, which is a program I never use. Milan Zamazal -- Having GNU Emacs is like having a dragon's cave of treasures. Robert J. Chassell -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
JED anyone?
`jed' is an orphaned package. I'm considering to take its maintanence, since I've found JED is a small and quick start editor, good for quick editing of configuration files, etc. (I've wiped out all vis from my disk, and ae+ed do not satisfy me fully:-). However I'm no way an experienced JED user, so if anyone else wants to maintain it, I've nothing against it. Milan Zamazal -- Having GNU Emacs is like having a dragon's cave of treasures. Robert J. Chassell -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: JED anyone?
On 23 Jun 1998 17:20:09 +0200, Milan Zamazal wrote: `jed' is an orphaned package. I'm considering to take its maintanence, since I've found JED is a small and quick start editor, good for quick editing of configuration files, etc. (I've wiped out all vis from my disk, and ae+ed do not satisfy me fully:-). However I'm no way an experienced JED user, so if anyone else wants to maintain it, I've nothing against it. I'm in the same boat. My main editor is JOE and I use JED only on the rare occasion that I want context hightlighting when programming in Perl. I've given thought to maintaining it but not being a regular JED user I don't think I'd be the best qualified. -- Steve C. Lamb | Opinions expressed by me are not my http://www.calweb.com/~morpheus| employer's. They hired me for my ICQ: 5107343 | skills and labor, not my opinions! ---+- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
annual update of Maintainer Contacts
As usual, the list of Maintainer Contacts has become a bit dated. Please go through http://www.debian.org/devel/maintainer_contacts.html and report any changes you know of. Also, Bruce was still listed as the contact for hardware donations in donations.html so I changed it to [EMAIL PROTECTED] temporarily. Any volunteers to take this over? BTW, the new web pages are almost ready. Only being in town for 5 days in the last three weeks slowed down their release. Jay Treacy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
it is your responsibility to provide Debian news
Bruce was very good at making announcements on events affecting Debian. These were the main source of entries to the news section of the web page. Items posted to debian-announce still are included, but their rate is much slower than in the past. If you know of any good Debian news items, please send them to [EMAIL PROTECTED] . It is up to you to keep the news flowing. Jay Treacy P.S. Please keep it relevant to Debian. I occasionally get more general notices that just aren't appropriate. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
James Troup [EMAIL PROTECTED] wrote: How is it a ``poor'' solution? Epochs solve the problem where version prefix b version prefix a but where b should follow a. The current problem can be solved by a version suffix and therefore does not require an epoch. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Tue, Jun 23, 1998 at 09:52:05AM +0100, Philip Hands wrote: If people weren't being childish about the addition of 2 characters to the changelog, which the users generally never see, we wouldn't be having this discussion. If we could keep this discussion to its technical merits, we wouldn't have to dip into criticisms of each others maturity. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hamm Beta: Delay #1
Brian White [EMAIL PROTECTED] writes: Just to be sure I understand... emacs20 has to be configured before cvs-pcl is _installed_ or before cvs-pcl is _configured_? Actually, now it seems like the problem in this case is that cvs-pcl currently has a dependency on emacsen-common rather than emacsen. This means that it's possible to have cvs-pcl installed with emacsen-common, but without *any* flavor of emacs. This is not something I had anticipated when developing the emacs add-on code, so I'm not surprised it breaks things. While I don't know exactly what's causing the problem, it seems that installing cvs-pcl along with (or after) a flavor of emacs works fine. Given that, changing cvs-pcl's dependency from emacsen-common to emacsen should fix the problem. Accordingly I've filed important bugs against the three packages that had this problem. Since you're unfamiliar with pkg-order, it sounds like starting to use it could be a source of other problems. I'd rather avoid that. Actually, Manoj pointed out that I should probably just use tsort, though I haven't figured out yet whether you can actually call dpkg --status or use the perl dpkg modules from within a postinst (i.e. recursive dpkg entry). Anyway, I think that the dependency changes will fix our current problem, and given that, I think that the dependency code should wait for slink. I would like to upload a new version of emacsen common for frozen that makes the add-on package dependency issue explicit. Thanks -- Rob Browning [EMAIL PROTECTED] PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Raul Miller [EMAIL PROTECTED] writes: The current problem can be solved by a version suffix and therefore does not require an epoch. Eh? Almost any version-number problem can be solved by a version suffix[1]. What's your point? Are you saying we don't need epochs? Or anyone using epochs is opting for the ``poor'' solution? [1] 2.9.1-0.1.this.is.really.2.8.1 anyone? -- James ~Yawn And Walk North~ http://yawn.nocrew.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Adding dependency order to emacsen add-on install/remove process
Though I think we've found that hamm can get by as is (as long as cvs-pcl, hyperlatex, and elib change their package dependencies), it seems likely that there may be cases in the future where we really do have to account for inter add-on dependencies when ordering the add-on install/remove scripts. Hoever, after thinking about it, I fear that just using Depends: doesn't really allow us to take *any* control over the emacsen-common install/remove script ordering. For example, cvs-pcl depends on elib. Now presume that this is because elib's emacsen-common install script has to be run before cvs-pcl's, and then consider the following scenario: dpkg -i cvs-pcl elib Isn't it true that dpkg ignores the Depends: lines when ordering the configure scripts for these packages? If so, then the cvs-pcl configure step, if it goes first, would fail. So what's the solution? I suppose you *could* use Pre-Depends, but is that the right answer? Thinking about it, that really may be the only thing that'll do what you mean. Thanks -- Rob Browning [EMAIL PROTECTED] PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please follow protocol when you announce your Intents to package
On Mon, Jun 22, 1998 at 10:36:11PM -0400, Shaleh wrote: I have seen numerous people post Intentions to package apps that are already being worked on. Please read the wnpp (it is made for a reason). And when you do announce you intentions PLEASE cc wnpp so that it gets added to the list. This seems to indicate that the Debian System has nearly grown up --- not much things left to package out there (I know this isn't true, there are lot of things left, but themost important stuff is here). Maybe people who find their software already packed want to contribute to it in some other way (bug fixes, patches, documentation, etc.) I know that a lot of people do this already. There is not only packaging :) Marcus PS: If you seek the point of my message, sorry, there is none. -- Rhubarb is no Egyptian god.Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Dale Scheetz writes: I like the proposal much better. It also is reasonable enough that even the glibc upstream maintainer might be encouraged to adopt our numbering scheme. I integrated this one in my 2nd summary in the dpkg and alpha/beta versioning thread in deb-policy. You're welcomed to comment other points there ! Regards, -- Yann Dirson[EMAIL PROTECTED] | Stop making M$-Bill richer richer, isp-email: [EMAIL PROTECTED] | support Debian GNU/Linux: debian-email: [EMAIL PROTECTED] | more powerful, more stable ! http://www.mygale.org/~ydirson/ | Check http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Philip Hands writes: [EMAIL PROTECTED] said: Dale Scheetz writes: In the mean time, unless anyone can object within the next several hours, I will construct and upload a new release of glibc with the version number: 2.0.7r-1 I would advise for 2.0.7final instead. IMHO 2.0.7r looks much like an additional patch-level. Um. f comes before p in the alphabet, whereas r comes after p. 2.0.7final 2.0.7pre 2.0.7r Aïe, where did I leave my head... Craig Sanders writes: On Tue, 23 Jun 1998, Philip Hands wrote: Yann Dirson wrote: Craig Sanders writes: how about using 2.07pre8-1, 2.07pre8-2, and so on for the next set of glibc pre-releases? Seems like it doesn't work: $ dpkg --compare-versions 2.07pre8-1 '' 2.0.8 echo yes || echo no no You missed a dot out of the first one (should be 2.0.7pre8-1) I'd go and get some sleep, or a coffee, if I were you, Yann ;-) Well, according to the clock, coffee would be the better choice ;) But for this point, the error you spotted was not the real one ;) It was intended to be: $ dpkg --compare-versions 2.07pre8-1 '' 2.0.7 echo yes || echo no no actually, it was me who forgot the . before the 7. Yann just copied my mistake. after looking at some of the other comments, i'd change my suggestion to Ah, with this I understand better... any of the similar suggestions would be fine too. the exact form doesn't matter, as long as it a) works :) and b) the meaning of the version number is fairly clear. Well, I don't find this solution very (visually) clear either... but yes, it's only for pre-releases. whatever format is chosen, it should be put in policy so that we don't have to figure it all out again in future, and also document a new standard/convention. That's the purpose of the dpkg and alpha/beta versioning thread in debian-policy. You're welcomed there. -- Yann Dirson[EMAIL PROTECTED] | Stop making M$-Bill richer richer, isp-email: [EMAIL PROTECTED] | support Debian GNU/Linux: debian-email: [EMAIL PROTECTED] | more powerful, more stable ! http://www.mygale.org/~ydirson/ | Check http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
location of 2.0.7 boot disks
I don't see the 2.0.7 boot disks for an i386 system on master.debian.org yet. Could someone please remind me where to get them from Enrique's computer? I don't seem to have that message any more. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Tue, 23 Jun 1998, Hamish Moffatt wrote: On Tue, Jun 23, 1998 at 08:32:41AM -0400, Dale Scheetz wrote: On 23 Jun 1998, James Troup wrote: (Sorry for the AOL, but...) Well said; I wish people would get over their epoch-phobia already. And I wish people would stop suggesting a poor solution. Epochs are not, were never, intended to be used for this purpose. They are only for dealing with upstream renumbering that would cause conflicts. This is not a phobia, but an unwillingness to use the wrong method. The upstream version numbering is incompatible with our package management tool, which seems to fit your reason just fine. Therefore use epochs. What is with this snake like facination with epochs? Epochs are intended to be a fix for version number overlap. This, on the other hand, while it does deal with version numbers, the similarity ends there. This is a temporary problem that is better solved by some careful planning in the future. (Yes, it is a recurring problem, but each time, it is temporary.) Luck, Dwarf -- _-_-_-_-_- Author of The Debian Linux User's Guide _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: JED anyone?
On Tue, Jun 23, 1998 at 08:47:53AM -0700, Steve Lamb wrote: On 23 Jun 1998 17:20:09 +0200, Milan Zamazal wrote: `jed' is an orphaned package. I'm considering to take its maintanence, since I've found JED is a small and quick start editor, good for quick editing of configuration files, etc. (I've wiped out all vis from my disk, and ae+ed do not satisfy me fully:-). However I'm no way an experienced JED user, so if anyone else wants to maintain it, I've nothing against it. I'm in the same boat. My main editor is JOE and I use JED only on the rare occasion that I want context hightlighting when programming in Perl. I've given thought to maintaining it but not being a regular JED user I don't think I'd be the best qualified. I've been thinking about taking over maintenance too as the upstream version is a fair bit ahead. OTOH I havn't been doing much maintaining recently and I'd like to finish doing SOCKSv5 and a few new upstream releases of other packages first. One thing I've noticed is that the debian diff includes the compiled packages, these should be generated my the build process and not be in the diff. Adrian email: [EMAIL PROTECTED], http://www.poboxes.com/adrian.bridgett Windows NT - Unix in beta-testing. PGP key available on public key servers Debian Linux http://www.debian.org The superior Linux distribution -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please follow protocol when you announce your Intents to package
On Mon, Jun 22, 1998 at 10:36:11PM -0400, Shaleh wrote: I have seen numerous people post Intentions to package apps that are already being worked on. Please read the wnpp (it is made for a reason). And when you do announce you intentions PLEASE cc wnpp so that it gets added to the list. Maybe someone should keep posting this to devel and user every now-and-again. In fact, how about a charter to be posted to each mailing list every now and again? A 2k email every week might save quite a few off-topic posts. We could say what each list is for, and *not* for: - newbie packaging - debian-mentor - bo/hamm - debian-user - slink - debian-devel - policy - debian-policy - flamewars - /dev/null etc. etc. Adrian email: [EMAIL PROTECTED], http://www.poboxes.com/adrian.bridgett Windows NT - Unix in beta-testing. PGP key available on public key servers Debian Linux http://www.debian.org The superior Linux distribution -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Summary[2]: dpkg and alpha/beta versioning
Yann == Yann Dirson [EMAIL PROTECTED] writes: Yann Needed: Some technical info about why people consider epochs as bad. Yann It seems most arguments only used aesthetic reasons. Please someone Yann correct me if I'm wrong. Manoj Srivastava [EMAIL PROTECTED] wrote: You'd be hard pressed to find any. One possible reason could be that the actual ordering of numbers would be confusing to humans (since epochs are not encoded in files names, epochs can be used to set up ordering of revisions in a fashion that is totally different from what one may assume looking at the names of the files) The primary objection to the use of epochs is that they're unnecessary. Why use a version prefix (which has a very large scope) when using a version suffix (which has a much smaller scope) will do? Anyways, it's a solved problem at this point... -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
James Troup [EMAIL PROTECTED] wrote: Eh? Almost any version-number problem can be solved by a version suffix[1]. Not where 1.0 follows 3.14, for example. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Raul Miller [EMAIL PROTECTED] writes: James Troup [EMAIL PROTECTED] wrote: Eh? Almost any version-number problem can be solved by a version suffix[1]. Not where 1.0 follows 3.14, for example. You clearly can, as I demonstrated in my footnote. Anyway, this is obviously somewhat of a religious issue, and having said that I whole heartedly agree with Manoj (that there are *zero* technical arguments against epochs), I will now shut up and ignore this thread. -- James ~Yawn And Walk North~ http://yawn.nocrew.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Tue, 23 Jun 1998, Yann Dirson wrote: Dale Scheetz writes: I like the proposal much better. It also is reasonable enough that even the glibc upstream maintainer might be encouraged to adopt our numbering scheme. I integrated this one in my 2nd summary in the dpkg and alpha/beta versioning thread in deb-policy. You're welcomed to comment other points there ! I bearly have the time to keep up with debian-devel, and so, cannot afford to subscribe to other lists, like debian-policy. I would be pleased if folks would CC me when they think the topic is of import to one of my packages. Luck, Dwarf -- _-_-_-_-_- Author of The Debian Linux User's Guide _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: location of 2.0.7 boot disks
On Tue, Jun 23, 1998 at 12:26:58PM -0500, Douglas Bates wrote: I don't see the 2.0.7 boot disks for an i386 system on master.debian.org yet. Could someone please remind me where to get them from Enrique's computer? I don't seem to have that message any more. I'm uploading them to master right now. -- Enrique Zanardi[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Adding dependency order to emacsen add-on install/remove process
James Troup [EMAIL PROTECTED] writes: No; it ignores the dependencies when *unpacking* the packages but if foo depends on bar, dpkg will run bar's postinst before foo's. Try it and see. OK, that makes sense. Then I suppose that the only place that the dependency ordering is needed is in the calls to the add-on pacakges install scripts that happen en-masse when a flavor of emacs is installed. A little work with tsort (presuming I can get dpkg to cooperate at that point and hand over the relevant Depends lines) and we should have everything fixed up. Thanks -- Rob Browning [EMAIL PROTECTED] PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please follow protocol when you announce your Intents to package
--On Tue, Jun 23, 1998 6:47 pm +0100 Adrian Bridgett [EMAIL PROTECTED] wrote: On Mon, Jun 22, 1998 at 10:36:11PM -0400, Shaleh wrote: I have seen numerous people post Intentions to package apps that are already being worked on. Please read the wnpp (it is made for a reason). And when you do announce you intentions PLEASE cc wnpp so that it gets added to the list. Maybe someone should keep posting this to devel and user every now-and-again. In fact, how about a charter to be posted to each mailing list every now and again? A 2k email every week might save quite a few off-topic posts. We could say what each list is for, and *not* for: - newbie packaging - debian-mentor - bo/hamm - debian-user - slink - debian-devel - policy - debian-policy - flamewars - /dev/null Actually, it would be very neat to have an automated procedure which could be activated by some list maintainers. For example, after the start of that version number debate, some maintainer could have typed 'reassign thread debian-policy' into some email-bot. That would ideally cause 3 things: 1) The originator would be sent a message indicating that his message was in the wrong list, and has been moved. It will check if he is also on that list, and if he is not comment that he might like to subscribe (although he may be OK with the Cc: line). 2) It will send a message to the original list, indicating that the discussion has been moved. 3) [Magic - tricky!] It will automatically intercept and move any emails with that subject line to the other list as long as it remains active. Any thoughts, anyone? I fall prey to my own logic, since I don't know what list to put this on. I'm Cc:ing policy. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
--On Tue, Jun 23, 1998 2:19 pm -0400 Dale Scheetz [EMAIL PROTECTED] wrote: I integrated this one in my 2nd summary in the dpkg and alpha/beta versioning thread in deb-policy. You're welcomed to comment other points there ! I bearly have the time to keep up with debian-devel, and so, cannot afford to subscribe to other lists, like debian-policy. I would be pleased if folks would CC me when they think the topic is of import to one of my packages. I find this alarming, Dale, since are you not on the technical committee? Perhaps some effort should be made to keep policy and such like lists low-bandwidth so that subscribing is less painful. I would also suggest (if you don't already use one) a threaded email reader can speed up email list reading... Although, of course, personally I would always Cc: the package author, if I thought he ought to know... Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
-BEGIN PGP SIGNED MESSAGE- On 23 Jun 1998, James Troup wrote: Raul Miller [EMAIL PROTECTED] writes: The current problem can be solved by a version suffix and therefore does not require an epoch. Eh? Almost any version-number problem can be solved by a version suffix[1]. What's your point? Are you saying we don't need epochs? Or anyone using epochs is opting for the ``poor'' solution? [1] 2.9.1-0.1.this.is.really.2.8.1 anyone? The point, I think, is that 2.0.7r is exactly the upstream version number (2.0.7) plus a suffix (r). However, 2.9.1-0.1.this.is.really.2.8.1 is not that way, because the non-suffix part (2.9.1) is not the upstream version number (2.8.1, really). Using epochs is adding things to the left, while using prefixes is adding things to the right. If we can add things to the right to solve a version-number problem at the same time we keep the main version number intact, then we don't need an epoch. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNY/5LyqK7IlOjMLFAQGLZwP8DkTvhz2QcNf8N/PMl8A0TkZ9fVkB7TuV eSb81gh1+8e4bJ5qNsLgVUtq5DZcCazXY/aLi0KTeYXyGj9zcqCBjPKedDAwZSFY mlzEvCWGkxNDdVQaW7StptGSeSSQ419bNR3Qdi2rsmNUXtPDXQ4Y2iy+Z96r+o7K l+vaDSf97y0= =7mLw -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: The BTS, Severity: Fixed, etc. (Was: An idea for the BTS)
On Tue, Jun 23, 1998 at 12:38:19PM +0200, Wichert Akkerman wrote: Previously Manoj Srivastava wrote: I think that not only should bugs be marked by the distributions they exist in, they should also be classified by architecture; Actually, I think we can do the same way more efficent. Each bug already has a Version-number. Now we if we add a field Fixed-in-Version the BTS can simply look for which architectures the fixed version is available. Except that sometimes bugs are architecture-related. For instance, an endian assumption bug. Dan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Raul Miller [EMAIL PROTECTED] writes: Not where 1.0 follows 3.14, for example. James Troup [EMAIL PROTECTED] wrote: You clearly can, as I demonstrated in my footnote. No. If your footnote was applicable at all, it was not providing a suffix to the current version number. Instead it was providng a prefix. We already have epochs to provide a prefix. Anyway, this is obviously somewhat of a religious issue, and having said that I whole heartedly agree with Manoj (that there are *zero* technical arguments against epochs), I will now shut up and ignore this thread. I believe the scope issue constitutes a technical argument. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Santiago Vila [EMAIL PROTECTED] wrote: Using epochs is adding things to the left, while using prefixes is adding things to the right. Most of your message was accurate, but I have a minor technical nit here: prefixes, including epochs, are both to the left. suffixes are to the right. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
--On Tue, Jun 23, 1998 2:59 pm -0400 Raul Miller [EMAIL PROTECTED] wrote: Anyway, this is obviously somewhat of a religious issue, and having said that I whole heartedly agree with Manoj (that there are *zero* technical arguments against epochs), I will now shut up and ignore this thread. I believe the scope issue constitutes a technical argument. [Cc to policy added] I personally feel that the scope issue is a minor, aesthetic, but valid, technical argument. My personal suggested scheme would be: 2.0.7.pre.2.0.8pre3 Or some such (I haven't got the bit of policy handy which specifies exactly which characters I can use), since it includes the full upstream version, but sorts correctly. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: location of 2.0.7 boot disks
On 23 Jun 1998, Douglas Bates wrote: I don't see the 2.0.7 boot disks for an i386 system on master.debian.org yet. Could someone please remind me where to get them from Enrique's computer? I don't seem to have that message any more. I believe it is in: ftp://molec2.dfis.ull.es/pub/debian-spanish/boot-floppies/ but I can't get a connection to verify it right now. HTH, Brandon --+-- Brandon Mitchell [EMAIL PROTECTED] | Debian Testing Group Status PGP Key: finger -l [EMAIL PROTECTED] | http://bhmit1.home.ml.org/deb/ Dijkstra probably hates me (Linus Torvalds, in kernel/sched.c) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Tue, 23 Jun 1998, Jules Bean wrote: --On Tue, Jun 23, 1998 2:19 pm -0400 Dale Scheetz [EMAIL PROTECTED] wrote: I integrated this one in my 2nd summary in the dpkg and alpha/beta versioning thread in deb-policy. You're welcomed to comment other points there ! I bearly have the time to keep up with debian-devel, and so, cannot afford to subscribe to other lists, like debian-policy. I would be pleased if folks would CC me when they think the topic is of import to one of my packages. I find this alarming, Dale, since are you not on the technical committee? Along with several other put interesting adjective here people, I have been asked to serve on that committee when it finally comes into existance. I suppose at that time, I will be forced to reorganize my time to deal with policy issues at some level. Perhaps some effort should be made to keep policy and such like lists low-bandwidth so that subscribing is less painful. I would also suggest (if you don't already use one) a threaded email reader can speed up email list reading... The whole point of splitting lists (which I do not think is actually realized) is to reduce the load on the necessary lists. As soon as these spin-off lists become necessary they loose their purpose for existance. While the different mailing lists make threading or filtering the mail easier, they do not deal with the problem of having to read the *%$*# stuff ;-) When my RL schedule was not as hectic as it has become these last few months (gee...it's been a year?) I subscribed, and participated in debian-user as well as debian-devel, and had no problem keeping the two separate. We need a device like the Riddler built, but instead of stealing brain waves, just borrow the viewing time, for resale to those of us who need it so much more ;-) Although, of course, personally I would always Cc: the package author, if I thought he ought to know... Good idea... Luck, Dwarf -- _-_-_-_-_- Author of The Debian Linux User's Guide _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: location of 2.0.7 boot disks
On Tue, Jun 23, 1998 at 03:01:53PM -0400, Brandon Mitchell wrote: On 23 Jun 1998, Douglas Bates wrote: I don't see the 2.0.7 boot disks for an i386 system on master.debian.org yet. Could someone please remind me where to get them from Enrique's computer? I don't seem to have that message any more. I believe it is in: ftp://molec2.dfis.ull.es/pub/debian-spanish/boot-floppies/ but I can't get a connection to verify it right now. Please don't use molec2 right now! I'm stuffing boot-floppies down the line to master. It's almost there, so please wait a few minutes and they will be in Incoming. Thanks, -- Enrique Zanardi[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
-BEGIN PGP SIGNED MESSAGE- On Tue, 23 Jun 1998, Raul Miller wrote: Santiago Vila [EMAIL PROTECTED] wrote: Using epochs is adding things to the left, while using prefixes is adding things to the right. Ooops! I meant *suffixes* here, of course! [ Thanks for the correction ] -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNZAETiqK7IlOjMLFAQH09AP/TrMD7+KVUrIRCGvmUMFjtpwW4DP862MG 5dt1aawszcgffRm4JGpbfu8XGYsYSc5ZAdihBKCrOk2+fGjOibJ3a+cGec64gBkk kWT4804t9xrnjmal2lDMJFOjYzPh7tGV1Sw7pOfVsedSM7bgywk/lYKFrcR+fN66 pm6e8W6KAvY= =XrUs -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Upgrade report from bo to hamm :-(
On Tue, Jun 23, 1998 at 08:09:51PM +0200, Paul Seelig wrote: Actually the true killer was the upgrade of the teTeX packages. It is pretty hard to stand seeing three time in a row Running initex [...] This will take some time on a 486DX-2/66 at the configuration stage. This alone consumed almost half an hour IIRC. Would apt have made a difference with this? Like installing and configuring all teTeX packages in a row and running initex afterwards just once? Or is this simply impossible? Which reminds me - the same method that we come up with to fix this, if it can be fixed, might be usable for iamerican/ibritish. What we need is something along the line of what update-menus does but interactive. Perhaps DPKG:TNG wil include some way of registering a script to run at the end of the configuration? Any interactive but non-vital configurations could then happen at the very end, easing one point. It would probably allow one running of inittex and one selection of ispell dictionaries. Ideas? Dan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Anyone at Rice University?
Are there any Debian users/developers at Rice University in Houstin, Texas? My cousin came back home for summer vacation and I've set up his computer running Debian. However, it's got an Ethernet card (EtherLink III - set it up fine with the 3c509 module) and someone's going to have to set it up to use Rice's network when he gets back. He barely knows tcsh, unfortunately, I wonder if there are any Debian people at Rice that are familiar with the network to set it up for him. -- Robert Edmonds -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Offering packages
MZ == Milan Zamazal [EMAIL PROTECTED] writes: MZ x11/xtoolwait - serializing startup of X applications I can take this package, if there are no objections. Ciao, Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: JED anyone?
Milan Zamazal writes: `jed' is an orphaned package. I'm considering to take its maintanence, since I've found JED is a small and quick start editor, good for quick editing of configuration files, etc. (I've wiped out all vis from my disk, and ae+ed do not satisfy me fully:-). However I'm no way an experienced JED user, so if anyone else wants to maintain it, I've nothing against it. Well, it seems I now use it the same as you do, but it used some time ago to be the only useful editor I had (on a 386SX-16 box), and I hacked some slang files for its purpose. I think I could take it over for slink, but I remember someone recently saying there was already work in progress on this. Don't remember who it was - just hope he'll read this thread. OTOH, I've also several other plans for early slink, so someone else with less plans than me could have a try a jed... -- Yann Dirson[EMAIL PROTECTED] | Stop making M$-Bill richer richer, isp-email: [EMAIL PROTECTED] | support Debian GNU/Linux: debian-email: [EMAIL PROTECTED] | more powerful, more stable ! http://www.mygale.org/~ydirson/ | Check http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: The BTS, Severity: Fixed, etc. (Was: An idea for the BTS)
Wichert Akkerman writes: Previously Manoj Srivastava wrote: I think that not only should bugs be marked by the distributions they exist in, they should also be classified by architecture; Actually, I think we can do the same way more efficent. Each bug already has a Version-number. Now we if we add a field Fixed-in-Version the BTS can simply look for which architectures the fixed version is available. No, that's not so simple. As already explained, and with a recent example, I fixed a specific bug in kbd_0.95-16 and kbd_0.96a-4. It does occur in all versions bewteen and including 0.96-1 and 0.96a-3. Filling a Fixed-in-Version field with either of 0.95-16 or 0.96a-4 would be wrong. We don't want that. -- Yann Dirson[EMAIL PROTECTED] | Stop making M$-Bill richer richer, isp-email: [EMAIL PROTECTED] | support Debian GNU/Linux: debian-email: [EMAIL PROTECTED] | more powerful, more stable ! http://www.mygale.org/~ydirson/ | Check http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[OFF-TOPIC] hmm, that didn't work. (WAS: Anyone at Rice University?)
As stated below, I'm enrolled at Rice, although I've been on leave this past semester. A direct reply to the original message didn't work, so I'm sending this all back to the list in hopes it gets to the right place. Anyone else who wants to comment -- feel free, but I doubt most of it is of any interest to debian-devel in general. Andy - Forwarded message from [EMAIL PROTECTED] - --- Below this line is a copy of the message. Return-Path: [EMAIL PROTECTED] Received: (qmail 20646 invoked by uid 1014); 23 Jun 1998 21:21:45 - Message-ID: [EMAIL PROTECTED] Date: Tue, 23 Jun 1998 17:21:44 -0400 From: Anderson MacKay [EMAIL PROTECTED] To: Robert Edmonds [EMAIL PROTECTED] Subject: Re: Anyone at Rice University? References: [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: [EMAIL PROTECTED]; from Robert Edmonds on Tue, Jun 23, 1998 at 08:54:42PM + On Tue, Jun 23, 1998 at 08:54:42PM +, Robert Edmonds wrote: Are there any Debian users/developers at Rice University in Houstin, Texas? My cousin came back home for summer vacation and I've set up his computer running Debian. However, it's got an Ethernet card (EtherLink III - set it up fine with the 3c509 module) and someone's going to have to set it up to use Rice's network when he gets back. He barely knows tcsh, unfortunately, I wonder if there are any Debian people at Rice that are familiar with the network to set it up for him. Oooh! Cool. I'm sorta a student-in-exile from Rice at the moment. I can give you some details on setting up for the network there if you want, although I can't physically help out. (I'm currently on leave doing a co-op with NASA at Kennedy Space Ctr -- so I'm a little out of the Rice loop at present. :) But I successfully ran oceania.brown.rice.edu as a Debian 1.1, 1.2, and 1.3 machine with the very same Etherlink III you're using. It was quite painless after wrestling with BOOTP to get an IP address. The secret is this -- rather than wrestle with bootp under Linux, just grab a handy Mac or PC laptop from someone around whatever college he's at, and plug that into the candidate port. The bootp addresses are hard-wired to the physical ports, so once you figure out the IP address of a specific port, then just statically config the Debian box in /etc/init.d to come up at that IP address. IIRC, the netmask is the usual 255.255.255.0 for a class B subnet (I could be wrong on that, though ...), the primary DNS server is moe.rice.edu at 128.42.5.4, the broadcast is standard 128.42.xx.255, and I -think- the default gateway for a given college subnet is 128.42.xx.254. A second guess would be 128.42.xx.2, but I'm pretty sure the 254 address is who you want to route through. If it's helpful I'll be glad to send him my home phone number -- and if he wouldn't mind calling I'll talk him through whatever. Also, the problem tracking system out at Rice is -very- helpful, although I'm not sure you can get to it through their firewall. Try http://problem.rice.edu, or if you need specific info try emailing [EMAIL PROTECTED] -- they even gave me a second IP address on my ethernet port so that I could hook my Newton MessagePad 2000 up using the Debian box as a router via PPP. Really nice and helpful folks. Related, what college (residential college, that is ...) is he at? Is he a freshman this year, or what? I'll be back at Rice either in about 6 months, or about 10 months from now ... I'll be roughly of senior status at that point. Oh, well ... let me know if I can be of further help. - Anderson MacKay| Merritt Island, Florida, US Microsoft != standard. Just trust me. | http://oceania.tnn.net/~iris | -- PGP key and other goodies - Check out Debian GNU/Linux, http://www.debian.org - End forwarded message - -- - Anderson MacKay| Merritt Island, Florida, US Microsoft != standard. Just trust me. | http://oceania.tnn.net/~iris | -- PGP key and other goodies - Check out Debian GNU/Linux, http://www.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: JED anyone?
On Tue, Jun 23, 1998 at 05:20:09PM +0200, Milan Zamazal wrote: `jed' is an orphaned package. I'm considering to take its maintanence, since I've found JED is a small and quick start editor, good for quick editing of configuration files, etc. (I've wiped out all vis from my disk, and ae+ed do not satisfy me fully:-). However I'm no way an experienced JED user, so if anyone else wants to maintain it, I've nothing against it. I use jed for programming, and joe for other tasks. Jed is very nice, but it would be better still if someone could figure out its weird C++ autoindent problems (bug#15197). It's a pretty cool bug, actually. I certainly have no time to maintain the package. I say go for it! Have fun, Avery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
On Jun 23, Philip Hands decided to present us with: 1:2.0.8-0pre1.1 1:2.0.8-0pre1.2 1:2.0.8-0pre1.2.1 (NMU) 1:2.0.8-1 etc. No, that's very bad, because it implies that the upstream source is the same and the only difference is in the Debian packaging. Wrong. I think we need a policy statement saying that packages uploaded with kludgey version numbers (that are clearly there to avoid the introduction of an epoch) will not be allowed into the archive. Agredd. []s, |alo + -- Howling to the moonlight on a hot summer night... http://www.webcom.com/lalo mailto:[EMAIL PROTECTED] pgp key in the web page Free Software Union -- http://www.fslu.org Debian GNU/Linux --http://www.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
xterm-debian terminfo entry
Now that debian is going to be using a nonstandard terminfo entry for xterms, can the default colors be setup like a normal linux console, black background with white foreground. I liked this when the xterm was setup this way a while back. I believe the reason for switching back to white background was for compatibility sake. Since xterm-debian is the standard terminfo entry for debian, a black background would also be nice. The black background is much more pleasing to the eye, especially with colors enabled. Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: xterm-debian terminfo entry
Or at least offer an xterm-cons or xterm-black-bg. Also, could someone PLEASE figure out the remaining options to make xterm behave graphically like a console? I can't get the combination of bold and 16 colors to work correctly. Dan On Tue, Jun 23, 1998 at 05:43:54PM -0500, Alexander E. Apke wrote: Now that debian is going to be using a nonstandard terminfo entry for xterms, can the default colors be setup like a normal linux console, black background with white foreground. I liked this when the xterm was setup this way a while back. I believe the reason for switching back to white background was for compatibility sake. Since xterm-debian is the standard terminfo entry for debian, a black background would also be nice. The black background is much more pleasing to the eye, especially with colors enabled. Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
