Re: Ubuntu discussion at planet.debian.org
Hamish Moffatt <[EMAIL PROTECTED]> writes: > I haven't seen much need here. It's usually possible to track > down earlier package versions if I really need through, from Debian, or > snapshot.debian.net, or out of date mirrors (:)). Well it was handy to have my originals here when gnu.org was compromised (for example). -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Is membership in staff supposed to imply root access?
It looks like our installs set up /usr/local/bin to be group staff and writable by staff, and place /usr/local/(s)bin before /usr/(s)bin in root's PATH. I was a little surprised because I thought we used to exclude the /usr/local directories from root's path by default, but perhaps we changed our policies or perhaps my memory is mistaken. Also, I wonder if our handling of /usr/local isn't a bit inconsistent since it doesn't look like we include /usr/local/lib in the ld.so defaults. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Re: Is membership in staff supposed to imply root access?
Santiago Vila <[EMAIL PROTECTED]> writes: > We have had /usr/local directories in the PATH for root at least > since 1995 (by looking at the "base" package version 1.1.0-13). Ahh, thanks. I haven't been depending on it either way (I'd have checked otherwise), so it's not a big deal. I'm not sure where I got the idea things were otherwise. -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Re: Reporting a bug that's already been reported...
Manoj Srivastava <[EMAIL PROTECTED]> writes: > rather than be scattered to the four [why four?] winds. N, S, E, and W -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
Manoj Srivastava <[EMAIL PROTECTED]> writes: > I would really like to get into using CVS for my package > development tree, but I have been held back by the hassle of > releasing packages. I wondered about this, and I had a question. I looked around in the CVS manual a little and didn't find anything, but feel free to tell me to RTFM if the answer's in the M. What do you do about packages whose upstream source is already being managed by CVS and already has $Id$ markers, etc in it? Thanks -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
Jason Gunthorpe <[EMAIL PROTECTED]> writes: > Nothing. When you check it into CVS it will rewrite all of the $Id: $ > markers and friends to reflect your CVS tree. It shouldn't have any > problems. You might not want that so you can turn off substitution with > -ko I think. I guess I was looking for -ko, since you wouldn't want to be rewriting the $Id$ values for the upstream source unless you actually changed things, and even then it's kind of iffy since your tree has nothing to do with theirs. In addition, without -ko, you'd get a bunch of spurious diffs against the upstream source. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
time stops on latest kernels
Is anyone else running the latest unstable kernels on a uniprocessor? I have noticed that with many of the recent kernels (including 2.1.40), time appears to be stopped. With these kernels, on my machine clock never returns anything but zero, and things like procmeter never register anything for cpu usage. I know that 2.1.26 doesn't have this problem, but I'm not sure where it was introduced. I have a suspicion that it's related to the new multiprocessor code... Thanks -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Problem with either xbase or ssh.
When the machine I have that's tracking unstable is rebooted, the xdm login screen will not appear until I use ssh to remotely connect to the machine. Until then the screen is blank. I don't know what's causing this, or I'd file a bug with the responsible package, but removing ssh makes the problem go away. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: RFC: Policy for arch specs
Galen Hazelwood <[EMAIL PROTECTED]> writes: > I think it also chooses some instructions differently for a 486, and > these choices are also good on the pentium. That's why, when building > binaries for my use, I use -m486 but add flags which turn off the > alignment. Right, I had heard that these were reasonably good flags for the pentium: -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Possible Xaw{3d,95} bug / Re: Debian freeciv bugs
[EMAIL PROTECTED] (joost witteveen) writes: > One possible solution is to link Xaw statically in the freeciv binary. > That's what I do with aXe. Or you can just use -rpath when you compile to force it to use a particular dynamically linked libXa*. I think that was the solution used in gv. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
New package notices via bug tracking system.
I'm moving this over to debian-devel. Hope that's OK. Joey Hess <[EMAIL PROTECTED]> writes: > The real reason I'm replying to this: I wonder what the other developers > think about bug reports that just say a new version is available (as opposed > to, a new version is available, and fixes this nasty bug). I ask because I > was planning on submitting about 50 bug reports on packages where a newer > version is available. I volenteered some time ago on the debian-qa list to > do this, and I have scripts that look at the LSM files on sunsite, and > automatically give me a list of out of date debian packages. > > If people don't like bug reports for this, I can just post the list to > debian-devel. What do people think? I think it's a good idea. I don't always notice when a new version of one of my packages is released, and the bug system makes a nice reminder once I've been notified. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: mgetty-voice
Camm Maguire <[EMAIL PROTECTED]> writes:
> Greetings! I've been reading here recently about the mgetty package
> looking for a new maintainer. What's the status on this? I'd like to
> suggest to the new maintainer to rebundle the vgetty extension, as the
> program is quite usable, IMHO, in spite of its being labeled as
> unstable by the author.
A new maintainer has in fact taken over mgetty, and mgetty-voice is
back. See the recent post to debian-changes listed below.
From: "\(Paul Haggart\)" <[EMAIL PROTECTED]>
Subject: Uploaded mgetty 1.1.7-1 (source i386 all) to master
To: debian-devel-changes@lists.debian.org
Cc: recipient list not shown: ;;@cs.utexas.edu
Date: 10 Jun 1997 06:49:45 -
Resent-From: debian-devel-changes@lists.debian.org
X-From-Line: [EMAIL PROTECTED] Tue Jun 10 02:04:23 1997
Received: from mailbox.cs.utexas.edu ([EMAIL PROTECTED] [192.168.1.2])
by nevermore.csres.utexas.edu (8.8.5/8.8.5) with ESMTP id CAA26912
for ; Tue, 10 Jun 1997 02:04:22 -0500
Received: from debian.novare.net (debian.novare.net [205.229.104.5])
by mail.cs.utexas.edu (8.8.5/8.8.5) with SMTP id BAA02951
for <[EMAIL PROTECTED]>; Tue, 10 Jun 1997 01:50:08 -0500 (CDT)
Received: (qmail 3225 invoked by uid 38); 10 Jun 1997 07:48:48 -
Resent-Date: 10 Jun 1997 07:48:48 -
Resent-Cc: recipient list not shown: ;
X-Envelope-Sender: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
X-dupload: 1.14
Resent-Message-ID: <"HmSmP3.0.An.URGdp"@debian>
X-Mailing-List: archive/latest/1445
X-Loop: debian-devel-changes@lists.debian.org
Precedence: list
Resent-Sender: [EMAIL PROTECTED]
Lines: 53
Xref: nevermore.csres.utexas.edu debian-changes:2813
-BEGIN PGP SIGNED MESSAGE-
Format: 1.5
Date: Mon, 9 Jun 1997 18:22:44 -0400
Source: mgetty
Binary: mgetty-voice mgetty-fax mgetty-docs mgetty
Architecture: source i386 all
Version: 1.1.7-1
Distribution: unstable
Urgency: low
Maintainer: Paul Haggart <[EMAIL PROTECTED]>
Description:
mgetty - Smart Modem getty replacement
mgetty-docs - Documentation Package for mgetty
mgetty-fax - Faxing tools for mgetty.
mgetty-voice - Voicemail handler for mgetty
Changes:
mgetty (1.1.7-1) unstable; urgency=low
.
* new maintainer
* new upstream release
* mgetty-voice added
* policy.h, voice/include/paths.h: all log files generated by {m,v}getty
are now located in /var/log/mgetty/*
* policy.h: logging to syslog enabled
* policy.h: mgetty uses /usr/sbin/sendmail instead of /usr/lib
Files:
c239ad80e4bf5208613b5767d21853a6 711 comm extra mgetty_1.1.7-1.dsc
04caf85dcbc40aebef7b2a7aa1643f48 756054 comm extra mgetty_1.1.7.orig.tar.gz
498ad76faebc21b575595b85409c5d63 22858 comm extra mgetty_1.1.7-1.diff.gz
dc81e3c74c4cec76eb90c0c58bb97286 138200 comm extra mgetty-fax_1.1.7-1_i386.deb
ace78cb40ecce9d1545ca710026d6e3a 191824 comm extra
mgetty-voice_1.1.7-1_i386.deb
c792e63dd490792e8090d42dc55bf48b 601298 comm extra mgetty-docs_1.1.7-1_all.deb
af5c2a3819843f8b576773d21fe3f1f6 104396 comm extra mgetty_1.1.7-1_i386.deb
-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: noconv
Comment: http://www.cybertap.com/phaggart/pgpkey.txt
iQCVAwUBM5z1t/x6jjXWExPpAQHJ3AQAzCFQxj/UTucMd9cy96jkWjGNzpNajFoU
6635Yo/hKkwHpXpHE1I82E+xjKxJh33x+m9zv3opiNSWxA0KE4b3FuNmgzwvfSow
PNi+boWuu45wj1UwnjPuTY1meO8dXkQwTB0JMHT7SFjOCWTzYKnfJE5YtweaCkwM
zWYQvCDSLrE=
=8t1x
-END PGP SIGNATURE-
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
--
Rob
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: mgetty-voice
Sorry about the runaway mail headers in my previous article re-post. Emacs was hiding them from me. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Hamm: Exim + Chos standard?
Nathan E Norman <[EMAIL PROTECTED]> writes: > Not that anyone necessarily has the time, but would it be worthwhile to > create some documents listing categories of packages, comparing and > contrasting the competing packages? Right. I'm about to help someone set up a relatively busy mailserver, and though I'm only familiar with sendmail, it'd be nice to know if one of the others would be a better choice. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: thread support
Guenter Geiger <[EMAIL PROTECTED]> writes: > - libraries should be compiled reentrant This has been on the list of things to do (for bo and now for hamm) for a while. It'll propagate eventually. Note that just compiling with -D_REENTRANT doesn't mean that the library is suddenly multi-thread safe, but it does mean that it won't use any thread unsafe macros from stdio or other includes that respect -D_REENTRANT, so that it should then be possible to use it safely by using mutexes to make sure that no more than one thread is ever inside the library. I've had to do that here with X (3.2). -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: thread support
Douglas L Stewart <[EMAIL PROTECTED]> writes: > It's just a matter of making sure all of the other libraries get thread > safe, which will get partially done I'm sure. The ones that aren't, you > can work around it by just using them in a single thread usually. or often by just using a mutex to make sure that no more than one thread is in the library at any one time. Of course this can be defeated by unsafe libraries that call each other internally. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: thread support
Mark Eichin <[EMAIL PROTECTED]> writes: > debian's Xfree86 3.2 packages were not built reentrant. I'm working > on the 3.3 libraries now, and once they're stable and working, I'll > be adding other support to them. (have you ever tried programming > with X and threads? you probably want to only use Display* per-thread > anyhow...) Well, it's really nice if you have several data displays (graphs, progress meters, counters, etc) monitoring different sources of data generated by separate threads to be able to allow the threads to update their own displays when they're ready. You can do this if you use a big lock to keep multiple threads out of X at the same time. Everyone should be a little wary of the synchronization primitives in LinuxThreads. I believe I determined that semaphores (and condition variables) do not guarantee FIFO scheduling fairness (I guess I expected them to, even though the POSIX standard doesn't require it). I had to write C++ wrapper objects that use their own queues or I tended to get starvation in situations where I really didn't expect it. On the up side, not having these guarantees allows them to make the code more efficient. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: thread support
Guenter Geiger <[EMAIL PROTECTED]> writes: > Yes, I've tried - that's how I came to this topic. > The problem is with the global errno variable. As Xlib does a lot of > error checking using errno. After X encounters an error it checks what > kind of error ocurred with errno and deals with it. > It is possible that the "non X" thread resets the global errno > variable between these two steps -- > Xlib signals unknown error ( with number 0 ) and exits. That's not the only thing. For example, if you don't define -D_REENTRANT when compiling the X libs, they pick up macros for stdio that are not thread safe, and can cause segfaults when X tries to print things. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: thread support
Andy Mortimer <[EMAIL PROTECTED]> writes:
> Although how well this interacts with dynamically-loaded shared libraries
> is anyone's guess;
What do you mean?
> I suspect I may have to go the global-variable route myself, which
> is why I was asking for examples/docs.
Bruce is right that in general the best thing is to avoid globals and
statics, and pass everything as an argument, but assuming you can't,
let's assume that your global data structure is called the_state.
Here's an example of a function safely modifying the data:
GState the_state;
pthread_pmutex_t the_state_guard;
void
some_function() {
pthread_mutex_lock(&the_state_guard);
/* do whatever with the_state. No other thread that respects the mutex
can touch it while you're in here. They'll block until you
unlock the mutex. */
pthread_mutex_unlock(&the_state_guard);
}
int main(int argc, char **argv) {
pthread_mutex_init(&the_state_guard, NULL);
/* other stuff */
}
See "man pthread_mutex_init" and other pthread_* man pages in
libc6-doc.
--
Rob
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: RFC: libc6 policy supplement 2nd try
Helmut Geyer <[EMAIL PROTECTED]> writes: > - compile the library using -D_RENTRANT or -D_THREAD_SAFE There was some talk about adding -D_REENTRANT to the list of flags that are automatically included by gcc/g++. I don't recall what the resulting decision was, if there was one. > - there may be no permanent data residing in the library memory that > can be different for different threads. > this means in the first place no static or global variables that > are not in some way protected from access by a different threads. > - all write access to files from a library must be both protected > using some file locking mechanism in addition to using mutexes. > - library functions must be protected from being used at the same > time by two threads sharing the same memory space. This is done > using mutexes. In the general case, I'm not sure it's realistic to expect *all* libraries to be rewritten thread safe (though it would be nice). At the least, though, we should make certain that -D_REENTRANT is always used, and that it's at least safe to call a given library function if you make sure only one thread is in the library at a time. That should be easier to accomplish. >There will be a list available that lists all libraries part of >Debian and their current status regarding compliance with these >standard requirements. This list will be posted regularly to >debian-devel by Helmut Geyer <[EMAIL PROTECTED]>. This is a good idea. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: thread support
Andy Mortimer <[EMAIL PROTECTED]> writes: > the basic question I want to answer is: if I open a library in one > thread, is it then always accessible to all threads (presumably), > and what happens to any global variables in that library? Threading shoudln't have any affect on this. All the threads share the same address space, so anything one can "see" and manipulate, the others can too. In other words, minus sychronization and reentrancy issues, if it works for one of the threads, it'll work for all of them. My impression is that these days every non-threaded Linux program can be thought of structurally as a multi-threaded program with just a single thread. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Status of Debian Policy
[EMAIL PROTECTED] (Mark Baker) writes: > Would programs _have_ to use this library, or is implementing the same thing > in acceptable? The latter has problems in that it forces us to keep the same > method, but I don't want to see lots of #ifdef debian appearing in the > original source; apart from anything else it doesn't look good being > non-standard even if what we do is superior. I think that we should develop this library, and release it to the public just like any other upstream package. We should (if possible) write it as a distribution independent solution to the problem and then package it for Debian. Finally name it something other than libdebian, and we'd probably have a good chance of getting others to start using it in their upstream sources for all platforms. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Debian's mail daemons
Does anyone know of any document comparing comparing sendmail, exim, and qmail. The recent discussions and some upcoming installs here have made me start contemplating the issue again. I've poked around, but came up with nothing. I did see some bits in the Qmail+MH mini howto, claiming all its advantages over sendmail and other older mailers, but I'd rather have a more independent source. Happy to hear personal opinions too. Also should the qmail package in experimental be considered at all ready to go? Thanks -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian's mail daemons
Alexander Koch <[EMAIL PROTECTED]> writes: > (I'd vote for exim if uucp is guaranteed to work) Ok, so what are the arguments for exim over qmail (at least why do you prefer it?) I've heard arguments for qmail and exim over sendmail. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Status of Debian Policy
Christian Schwarz <[EMAIL PROTECTED]> writes: > This really is an _excellent_ idea! So, we just need a volunteer to > implement and maintain this "upstream library". (The packaging for Debian > should not be a problem.) Ideally we could provide C, perl, python, etc versions of the code. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Orphaning dftp.
I'd like to officially offer dftp up for adoption. I don't use it anymore -- dselect works much better for me now that I came to terms with it -- and so I don't really have much interest in maintaining dftp anymore (that and the fact that I have a bunch of other things I'm supposed to be doing). Thanks -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Orphaning dftp.
Roman Hodek <[EMAIL PROTECTED]> writes: > I'd volunteer for maintaining dftp, at least for a while, if nobody > else does. I also have a lot of things to do and not too much time > left, but I need dftp for my two machines at home Right. Just in case you hadn't thought of it you could use dselect's ftp method and an (NFS) shared or mirrored download directory for the two machines. That of course presumes that you have a net connection at home and that you don't have expensive line charges. > and there are some things in dftp that really should be done (re-add > the .installed file, at least some kind of dependency checking). True. I just don't have time for it right now. I put in the interactive mode as a hack until I or someone else did the dependency ordering code. Looks like you might be able to use pkg-order now. I guess we can wait a bit and see if anyone else wants dftp. If not, it's yours. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Hamm: Exim + Chos standard?
Chris Fearnley <[EMAIL PROTECTED]> writes: > If I might speculate on my "winning" sendmail configuration strategy: > ignore the irrelevant (like rule sets). Say you have three users who have accounts on your system, but their primary accounts are elsewhere. Now you want their email headers to be rewritten by *sendmail* to appear to come from their other provider so that it will be correct no matter what email client they use. This took me quite a while to figure out in sendmail. It requires (as far as I could tell) rewrite rules at just the right places to catch the relevant cases, both their fully qualified address, and their abbrevated local address. (I hear now there's a way to get sendmail to use a database for this, but I haven't gotten that to work yet.) > Hence I would appreciate it if the MTA debate could focus on design > criteria other than ease of configuration. I'm more interested in > performance and design considerations that impact on security and > the ability to configure (flexibility). Ease of configuration can directly impact the likelihood that the program will be set up properly, and hence be secure. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Rescue disk and Thinkpads (problem identified).
I had posted earlier about a problem getting Debian 1.2/1.3 installed on a 365x thinkpad. Several solutions were offered and in the end it turned out that the people claiming that some thinkpads could not handle the bzImage format were correct. It was not the "floppy=thinkpad" problem. I didn't need that at all. So, if it doesn't make the kernel too big, could we switch back to using zImages on the rescue disk rather than bzImages? It won't hurt any other machines, and there are apparently a (small) number of machines out there (some Thinkpads and some Toshibas I think) that it would greatly help. Thanks -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Policy wrt mail lockfile (section 4.3)
John Goerzen <[EMAIL PROTECTED]> writes: > Why are we using dotfile locking only? There are much better > mechanisms (flock, etc.) that should be used instead. I can see no > place where dotfile locking would work and flock-style locking would > fail... I think flock can fail across NFS in certain situations, but I'm no locking expert. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Rescue disk and Thinkpads (problem identified).
Bruce Perens <[EMAIL PROTECTED]> writes: > Is this when booting from the floppy only, or from hard disk too? > I suspect a software bug in SysLinux, the floppy bootstrap. Once I > get some more data from you I will take it up with H. Peter Anvin, > the SysLinux author. Hmm. I don't have access to the machine right now, and I'm only really familiar with booting from a HD via lilo. What would I need to do to test this if I get the machine back? Thanks -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Policy wrt mail lockfile (section 4.3)
John Goerzen <[EMAIL PROTECTED]> writes: > However, why is it bad if a given program (like Elm-ME+ which I > maintain, which brought the issue to my attention this time) uses > *both* locking mechanisms? The only problem I know of is that with two locking schemes, if all programs don't agree on the schemes and the order of their use, you can end up with nasty deadlock situations. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Re^2: Status of Debian Policy
"Scott K. Ellis" <[EMAIL PROTECTED]> writes: > Okay, show me how to search a HTML version of the bash info documentation > for a concept and I'll believe you. Absolutely, anything without regex and incremental search is broken and unacceptable for documentation purposes (IMO). -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Rescue disk and Thinkpads (problem identified).
Bruce Perens <[EMAIL PROTECTED]> writes: > Install a bzImage kernel on the hard disk using LILO, and see if it will > boot. If it boots, it's only a problem with the floppy bootstrap. All of > our kernels are bzImage, so that should be easy to test. Tried it, and it hangs when booting bzImage from the hard drive too. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Documentation Policy
[EMAIL PROTECTED] (Martin Schulze) writes: > I don't like the idea of splitting packages that much. It increses > the confusion for users. For new users it is incredible difficult > to install Debian because of >1000 packages. I think keeping the user from having to deal with this complexity (level of detail) should just be handled by dselect's next generation, and making the separate packages allows quite a bit more flexibility. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Rescue disk and Thinkpads (problem identified).
Bruce Perens <[EMAIL PROTECTED]> writes: > From: Rob Browning <[EMAIL PROTECTED]> > > Tried it, and it hangs when booting bzImage from the hard drive too. > > Please tell me exactly what ThinkPad model this is. I believe it's a 365X (16MB, ~800MB drive). -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Rescue disk and Thinkpads (problem identified).
Erv Walter <[EMAIL PROTECTED]> writes: > Bruce Perens <[EMAIL PROTECTED]> wrote: > > I'd rather fix the software bug that prevents bzImage from working on > > some computers. Thus, I need good data on what those computers are, > > and I need people with those computers to test new boot floppies. > > Sounds good to me. I'll check the model number and get back to you > (not my laptop). And I'd be ahppy to test possible solutions. Me too. I should be able to get the machine now and then for testing. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Anyone made a qmail-1.01 experimental package.
I was going to try out qmail, and I just wanted to see if anyone had made a package of 1.01. I mailed Christian, but I haven't heard back from him yet, and I thought someone else might have packaged it for their own internal use. Thanks -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Status of Debian Policy
Ricardas Cepas <[EMAIL PROTECTED]> writes: > As of current documentation, you can search only current > .html file. This is not very usefull. > Lynx ( on non-gzipped docs) is much slower then info ( on > gzipped). Oh, right I forgot to add "recursive" to my previous comment about searching. To revise: any documentation tool that doesn't support incremental, recursive, and regular expression searches is not acceptable IMO. As far as I know, that leaves out most html browsers at the moment. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Experiences with compiling Debian
[EMAIL PROTECTED] (joost witteveen) writes: > No, what I had in mind is changing chmod, chown and frends, and make > them log the intended permissions in a file (specified somewhere in > a environment variable), and then changing tar to look for that file > (agian in that environment variable), and ajust the > permissions/ownerships in the tar file according to that "permissons > file". I thought that when this idea was discussed in the past, it was decided that the best way to do this would be to write a stream editing tool that could edit a tar archive (I think the format's pretty simple) after it was created. The editor would change the owner, group, and mode on specified files inside the tar file after the file had been created. This, of course would require maintainers to change their packages, but it would allow non-root builds, and would avoid the problems with trying to guess where the current packages chown files. Just what I recall... -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug: cross-device link
Galen Hazelwood <[EMAIL PROTECTED]> writes: > /lib/cpp has _always_ been a symlink to /usr/bin/cpp. It has been that > way for years. And it's only _now_ causing a problem? Have you never > installed cpp or gcc before? > > Furthermore, symlinks are definitely allowed across devices. It's hard > links that aren't. That can't be the problem. Well, I don't understand what's going on, but here's what I think is the same problem with ispell, ibritish, and iamerican. At some point ibritish calls update-alternatives which tries to rename ispell-dictionary.hash.dpkg-tmp to ispell-dictionary.hash. It fails. If I cd to /etc/alternatives and try it manually as root: clare# mv ispell-dictionary.hash.dpkg-tmp ispell-dictionary.hash mv: cannot move `ispell-dictionary.hash.dpkg-tmp' across filesystems: Not a regular file clare# clare# ls -l i* lrwxrwxrwx 1 root root 29 Jun 21 12:20 ispell-dictionary.hash -> /usr/lib/ispell/american.hash lrwxrwxrwx 1 root root 28 Jun 21 14:01 ispell-dictionary.hash.dpkg-tmp -> /usr/lib/ispell/british.hash clare# df Filesystem 1024-blocks Used Available Capacity Mounted on /dev/hda1 156148938 5870 60% / /dev/hda4 256622 132644 110723 55% /usr It's probably something obvious, but I don't see it. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Summary: File locking discussion
Philip Hands <[EMAIL PROTECTED]> writes: > libmailaccess should be something like PAM for mail delivery, > providing access to a user's mailbox by use of either Maildir, or > dot-locking (via libnfslock say), or whatever other method --- as > selected by the user. Sounds good to me. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug: cross-device link
[EMAIL PROTECTED] (Bruce Perens) writes: > Uh-oh, I can't duplicate the bug today. I wonder if it has to do > with the fact that I was running kernel 2.1.43 yesterday, and not > today? A-ha. I'm running 2.1.43 on the relevant machine as well. I had to upgrade to that version because earlier versions didn't speak PCMCIA properly with that machine's modem... Sounds like a kernel problem (ouch). I suppose closing the related bug would be in order. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Experiences with compiling Debian
Mark Eichin <[EMAIL PROTECTED]> writes: > I'd prefer that this only be done using tar itself -- because debian > has had such a bad track record with handling tar format, particularly > in the fringes (long file names in particular -- I think dpkg might > have been fixed, but dpkg-source is still broken...) Oh, I had actually forgotten that the newest tar can already do what we want. Now we just need to figure out how we want to use it. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug: cross-device link
[EMAIL PROTECTED] (Bruce Perens) writes: > Get that 2.1.43 kernel off of there, and do an "fsck -f" (for _force_) on > all filesystems. On my system I had a lot of null-named directory entries > and other distressing but non-fatal filesystem problems. And that was without > the directory-cache code built in. I just god confirmation from someone on debian-user with the same "ispell problem", so it's pretty certain it's 2.1.43 now. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug: cross-device link
[EMAIL PROTECTED] (Bruce Perens) writes: > Get that 2.1.43 kernel off of there, and do an "fsck -f" (for > _force_) on all filesystems. On my system I had a lot of null-named > directory entries and other distressing but non-fatal filesystem > problems. And that was without the directory-cache code built in. I just got confirmation from someone on debian-user with the same "ispell problem", so it's pretty certain it's 2.1.43. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Documentation Policy
[EMAIL PROTECTED] (Bruce Perens) writes: > Someone brought up the point of recursive regular-expression > searching. Of course this should be done with a CGI script rather than > as a browser facility, so that it would be browser-independent. One > could build a tiny search engine with zgrep and the shell, for > example. That was me. I guess the cgi approach would make stuff like recursive incremental searches (a la C-s in the info tool) out of the question, but I kind of figured that was a losing battle. It's too bad, I really find it quite useful. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Documentation Policy
[EMAIL PROTECTED] (Bruce Perens) writes: > I-search would take a Java-equpped browser as far as I can tell. It's > not do-able all in free software today. That will not be the case forever. Right. Also might be do-able as a hack in something like dwww (assuming I understand what it's doing) or w3 one of these days with recursive page prefetching/searching... Oh, and I do agree with both the general principle of a unified documentation system, and that html is probably the best common destination format right now. I'm mostly just grumbling my feature wishlist... -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Experiences with compiling Debian
Nicolás Lichtmaier <[EMAIL PROTECTED]> writes:
> Note that you won't be able to overload fchmod and fchown unless you also
> overload open and close to know the filenames..!
>
> IMO we should go with the simplest solution: {chmod,chown}.sh and modify
> the packages.
Well, if we do this, we need to make sure to handle the case where
people do something like:
chown -R 755 debian/tmp/usr/bin
chown g+s debian/tmp/usr/bin/special-binary
i.e. later commands would have to override previous ones. (probably
obvious, but I just wanted to make sure this was kept in mind).
--
Rob
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Broken *deb's in hamm
Sten Anderson <[EMAIL PROTECTED]> writes: > I have tried downloading them from a different mirror with the same > result. Are these packages really bogus, or am I just cursed? I don't > rely on these packages, but dselect complains, and that is a little > annoying. As far as I can tell, there are corrupted files on master. I had to re-upload perl-tk (with a new revision) to fix the problem. -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Need someone to take some of my packages.
Dale Scheetz <[EMAIL PROTECTED]> writes: > The other two packages that I should find better homes for are; libident, > and m4. Each of these packages have "minor" bugs reported against them and > are not a maintainance problem. The also fall into the catagory of > "relatively untestable" packages, and would fair better under someone > elses care. > > Please contact me if you are interested in any of these packages. I'll take m4 for you. -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Config file management utility
Joey Hess <[EMAIL PROTECTED]> writes: > Another way, that sould comply with policy, were if cron came with a > update-crontab script, that was responsible for modifying /etc/crontab, > in a similar fasion to update-inetd. I think that this, or something similar, is in the end, the right solution. Ideally, I think this should be handled like the menu package. /etc/crontab would be augmented to have something like: # BEGIN AUTOMATICALLY GENERATED SECTION -- DO NOT EDIT # # END AUTOMATICALLY GENERATED SECTION -- DO NOT EDIT # Then each package would just have a file in /usr/lib/cron/auto (or whatever) which would be used to (re)build the contents of this section whenever a relevant package was installed. -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Config file management utility
Joe Emenaker <[EMAIL PROTECTED]> writes: > Well, that's pretty much what I was suggesting in the beginning. The only > difference is that you wouldn't have one, monolithic section. Rather, > you'd have sections placed there by the individual packages. For example: The only advantage to the monolithic section I can see is that then you only have one block that the tool is ever manipulating, and since the entire block is regenerated anytime any piece changes, it seemed like it might make the setup less affected by minor corruptions. Proabably not a big deal either way... -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Linking (ld) problem with package.
I'm trying to improve some stuff in the rscheme package, and I have several shared libraries (for rscheme internal use only), that I need to glom together into one big shared library -- i.e. I want the collected library to contain all the code from the sub-libraries -- no dynamic links to any of the others. Is this possible? I've looked through the ld info pages several times and haven't found anything that works. 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 FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Linking (ld) problem with package.
Stephen Zander <[EMAIL PROTECTED]> writes: > Do you only have access to the sub-libraries as *.so files? Yes. -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Linking (ld) problem with package.
Stephen Zander <[EMAIL PROTECTED]> writes: > Using libelfg0-dev seems like the likeliest sucessful approach. I'll > play with it on the way home tonight (I hope) if I can find my ELF > reference docs. Oh, don't go that far. If ld (or some other standard tool can't handle this) I'll just figure out some other way to deal with it. I think I can restructure the make process to get access to the .o files earlier. Thanks, though. -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: bo-updates packages
Steve Greenland <[EMAIL PROTECTED]> writes: > Nobody, but I don't *expect* it to, either. I guess my theory on this > is that if the change is "small enough" to expect no problems (i.e. > perl-5.003 -> perl-5.004 (or whatever the actual number are)), then > is it *really* necessary to provide the upgrade? Don't forget that installing this *minor* upgrade would break *all* the packages like perl-tk that depend on a particular version of perl. Come to think of it, I think I need to change my perl-tk Depends to be more restrictive... -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Intent to package: umich-ldap / WNPP: Dermot Bradley probably not maintaining packages
Dermot John Bradley <[EMAIL PROTECTED]> writes: > Ah I'd missed the bit there about simply renaming the existing tarball > after extracting the code and before running deb-make. Great, now all my > updated packages will use pristine source. You can even just make a symlink with the right name to the original tarfile. -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Does it conform our demands?
Jozef Bednarik <[EMAIL PROTECTED]> writes: Debian supports all of these features you mention in both the current stable release (1.3), also known as bo, and the upcoming release (2.0), also know as hamm. All of the software in our main distribution is free, and will remain that way (see our policy documents at www.debian.org for details). > 3Com fast ethernet adapter 3C905-TX (or at least any other fast ethernet > card available on the market) Note that you should probably avoid this card. Get a DEC tulip based card instead. I switched to the D-Link card with no problems. The tulip based cards are cheaper and are more compatible with Linux. The drivers for the 3Com 3C9xx cards have some serious problems on some machines, especially if you try to use them at 100MBit. Oh, and In the future, questions like this should be directed to debian-user@lists.debian.org rather than debian-devel. 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 FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Does it conform our demands?
Michael Meskes <[EMAIL PROTECTED]> writes: > I have to disagree with Bob on this issue. I had a 3c905 a while back It's Rob :> > and at that time the kernel driver (v0.40) had serious problems but > mostly when run on 10Mbit. Now that the 2.0 kernel series ships version > 0.46 I have yet to run into a 3c905 related problem. And my machine is > filleserver (samba), databse server (two instances of Oracle), web proxy > (squid) and nameserver (bind). Lot's of traffic and it works like a > charm. Sure. I wasn't claiming that some people don't have problems, but that others do. If you watch the vortex development list, you'll see what I mean. It's one of those YMMV things. I worked with a machine that would lock up on a daily basis at 10Mb with the early 0.46 drivers. It's calmed down with the newest ones, but it was a big hassle before that. The tulip cards are cheaper and better supported. I'd go with that, and I have both. Note that I'm not using them at 100Mbit if it matters. -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Thread safe X libs?
[EMAIL PROTECTED] (Mark W. Eichin) writes:
> Every X release for a long time has been built _REENTRANT, and the
> 3.3.1 libs are built with some threading options turned on (I'd have
> to look at the config files to see what, though.)
I would guess that this is essentially the stuff in
/usr/doc/libc6/README.Xfree3.2.linuxthreads.gz, but I don't know for
sure.
We do pass the only runtime test I know:
#include
#include
int main(int argc, char **argv) {
printf("Xt thread safe: %d\n", (int) XtToolkitThreadInitialize());
return 0;
}
$ gcc -Wall -o testx testx.c -L/usr/X11R6/lib -lX11 -lXt
$ testx
Xt thread safe: 1
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Our future compiler and default compile option problems.
This is not something that's critical at the moment, but we should probably be thinking about it if there's any chance that we'll ever switch to egcs as the default compiler. It's also important if we'd like to support people who want to use egcs as their local default. The goal being that when they build debian packages (or the kernel with make-kpkg), they get reasonable compile flags. [My understanding of this issue is not complete, so please correct me if I'm getting things wrong. ] The issue in this case is -fno-exceptions. I've heard that people have complained on the net about egcs, that even with it's haifa scheduler, and all the new optimizations like -mpentium, etc., it was building slower C binaries than g++. The reason seemed to be that these people were not specifying -fno-exceptions. By default, egcs includes exception handling in C binaries. This is because you must, if you ever want to link the resulting C object code against C++ object code and have exceptions work. Unfortunately, there's a non-trivial performance penalty. Assuming that we plan to support egcs as the main compiler (which we may not) what's the right thing to do? If we make -fno-exceptions the default, then it's my understanding that we won't be able to link the resulting libs against C++ code that uses exceptions. If we allow exceptions, then we'll take a performance hit. What's worse, gcc croaks on -fno-exceptions, so even if we wanted to make it the default, we couldn't just specify it for both compilers. -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Our future compiler and default compile option problems.
Jason Gunthorpe <[EMAIL PROTECTED]> writes: > I was under the impression you could get away without exceptions in C code > however? Absolutely, but my impression is that the problem occurs if you are generating libraries that might eventually be linked against C++ code, which is the case for any Debian libraries. I'm a little fuzzy on the details, though. -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Is "cp -a" allowed in debian/rules?
Douglas Bates <[EMAIL PROTECTED]> writes: > In creating the r-base package I need to manually copy a directory > tree into ./debian/tmp/usr/lib/R. Right now I do this using "cp -a". > Is that practice frowned upon? Would using tar for this be preferred? Well, I don't know if cp -a is frowned upon, but if so, I need to change at least one of my packages. In any case, here's a reasonable substitute: (cd src-dir && tar cf - .) | (cd target-dir && tar xpf -) -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug#15859: libc6 in stable is horribly broken
Scott Ellis <[EMAIL PROTECTED]> writes: > I HAVEN'T HEARD ANY REASONS WHY UTMP CORRUPTION IS SO EVIL THAT WE > NEED TO MAKE ANYONE WHO WANTS TO RUN A FEW LIBC6 PROGRAMS ON BO GO > THROUGH HELL. Say you're an ISP running Debian (bo) on a bunch of machines (and these people do exist). Now say you take dpkg and add libc6 because you want the latest proftpd, and at the same time decide you want the latest rxvt (for whatever reason). Now, without any warning from dpkg (with your suggested approach), you have a broken system where it's no longer possible to tell who's currently logged in or even who was logged in in the past. That data is lost. This is not likely to make us any friends. The only possible approach I can see (other than what we're doing now) would be to force all the libc6 packages that touch utmp to carry the "wtmp compatible libc5" dependency. Then upgrading one of those would force you to upgrade libc5. But determining what belongs in that list without a source search may be non-trivial. > If you don't upgrade anything that deals with utmp to libc6, you > don't have any problems). The problem is that maybe *you* know what packages those are, but most users expect to be able to upgrade without major system services breaking if dpkg/dselect doesn't indicate that there's a problem. Your approach would cause silent failures. Imagine that (given the eariler example) the ISP upgrades the stuff, then a week later realizes that someone may be trying to hack their system. The go to "who" (and friends) to see what's going on, and they get an empty listing. This is going to cause someone to need heartburn medication. (Hope I've got my facts straight and I'm not overlooking something obvious.) -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: I take debmake
Adrian Bridgett <[EMAIL PROTECTED]> writes: > What about using debhelper rather than having another packaging suite? IIRC > Ian said that debmake was "broken" in some respects and that Debian should > have a decent packaging tool - IMO debhelper fits that nicely :-) I don't believe that debhelper address one of Ian's main complaints at all. If I remeber correctly, that complaint was that when you use debmake (or debhelper), you end up with debian package source with non-deterministic behavior. Depending on the version of the packaging tool installed on the system you use to build the package, you may get a radically different resulting set of binaries. In addition (but less important), the current approach requires that you have the packaging tool package (debmake or debhelper) installed on the system where you're doing the build. Ian was proposing to fix these problems with a more automake/autoconfish apprach where the commands to build your package would reside within the package itself (rather than in /usr/bin via an external package), and there would be a higher level command (like autoconf) that when run would bring these embedded commands up to the current packaging tool standards. FWIW, I agree that Ian's objections are valid, and I think his approach should be preferred if someone gets the chance to implement it. (Sorry if I misrepresented your objection, Ian.) -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: I take debmake
Christian Leutloff <[EMAIL PROTECTED]> writes: > it's nice to have, but brings no advantages. If we change the > autoconfish thing we get the same different binaries as through > changing debhelper/debmake. It's IMHO only a different view but no > substantial change. And debhelper is working NOW - the other approach > is vaporware. I think you may still be missing the point. If you use Ian's approach, and then someone downloads foo_1.0-1.diff.gz foo_1.0-1.dsc foo_1.0.orig.tar.gz then when they build the package they should get a nearly identical (if not completely identical) set of binary packages to the ones residing on the ftp sites. If you use the debmake/debhelper approach, then you may get something *very* different, depending on the version of debmake/debhelper installed. This makes tracking down packaging problems reported by others unnecessarily difficult, with no real benefit. User: Building your package doesn't work right. Developer: Works fine for me. User: But I used the source packages you gave me? Isn't that supposed to be sufficient? [...time elapses...] Developer: Oh, wait. What version of debhelper/debmake do you have installed? User: That matters? Now granted, source dependencies could fix some of the problem, but usually we only include version specific dependencies in unusual cases. The nature of debmake/debhelper would essentially mandate that every package built with them include a specific version dependency to guarantee reproducable builds. That's pretty ugly IMO. All that said, I understand the vaporware argument. I'm not talking about whether or not we should continue to maintain debmake/debhelper, but about where future development resources should be allocated. -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: ppp's ip-{up,down} and possible utilization of 'run-parts'
"Adam P. Harris" <[EMAIL PROTECTED]> writes:
> I think that /etc/ppp/ip-up and /etc/ppp/ip-down should use
> 'run-parts' against, say, the directories /etc/ppp/ip-{up,down}.d/.
Stunningly good idea. Make it so :>
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Taking over production of emacs20 package.
Mark recently informed me that he'd accepted my offer to work on the new emacs20 package. I just wanted to let everyone know that I was getting started. I'd like to get something out very soon, but the holidays may interfere a little. Feel free to let me know if you have suggestions about how this package should be handled. I'm planning to cooperate with the xemacs and emacs (19) package maintainers to make sure we support the simultaneous installation of all three packages. The new main package will be named emacs20, and there will be an auxilliary emacs20-el package. -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Questions about emacs20 file system layout.
The newer emacs source wants to put some files in /usr/share/emacs and /usr/libexec/emacs by default. The emacs 19 package put all these files together in /usr/lib/. I would assume /usr/share is now OK since it's in the FSSTND (to some extent) and other packages are using it, but what about /usr/libexec? Am I correct in assuming that it should still be avoided until FHS? 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 FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Questions about emacs20 file system layout.
Christian Schwarz <[EMAIL PROTECTED]> writes: > As the current emacs package installs its libs into > /usr/lib/emacs/19.34/..., will moving this below /usr/share break other > packages? I'll certainly make sure that's not a problem before I do it, but so far, I doubt it will be. I don't think that the old and new emacs will be sharing many files. > The use of /usr/libexec is currently under discussion on debian-policy. > Please wait a few more days until we've decided of how to treat this > directory. No problem. -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Questions about emacs20 file system layout.
"Adam P. Harris" <[EMAIL PROTECTED]> writes: > Rob, you're talking about moving Xemacs arch-independant files from /usr/ > lib/xemacs-XX.XX to /usr/share, right? No, this is only for emacs20, James LewisMoss <[EMAIL PROTECTED]> maintains xemacs. > I think this is a good idea. When we do this for Emacs 19.XX we'll need > to make sure to change AucTeX and the lisp packages. See my recent post about improving the handling of .el files. I believe it address this. > BTW, are .elc files arch-dependant or arch-indep? I've always wondered > about this. I was under the impression that they're architecture independent. Please correct me if I'm wrong. -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Taking over production of emacs20 package.
"Adam P. Harris" <[EMAIL PROTECTED]> writes: > What if you have Xemacs *and* Emacs installed, and want to use auctex > from both? My suggestion would be that whichever package provides auctex, whether it's xemacs or a separate package, would register the .el files somehow so that when say emacs20 is installed, it will knows to go find these files and byte compile them to a private location. This, of course, only applies for packages with .el files that are compatible with more than one of the emacsen. -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Taking over production of emacs20 package.
Sten Anderson <[EMAIL PROTECTED]> writes: > If elisp files should be compiled in a postinst script, then which > postint script should do it? It should just be handled the same way as the menu package. It'll usually be the postinst of the package installing the .el files. All of these packages will either depend on a virtual package "emacs-editor", or be such an editor. To close the loop, each of the editors will have a postinst that scans the "database" of installed emacs files and byte-compiles each one that needs to be byte-compiled for itself (think Makefile patter rule). This scanner will just be the flip-side to the "install-elisp" tool. > What is installed first - dpkg-dev or emacs? In addition, an > otherwise portable elisp file becomes unportable when compiled. In the scenario I described above, it doesn't matter. The portability argument is a red herring. Byte compiling leaves the elisp file just as portable as it ever was. It's the .elc file that gets generated that's emacs version specific. However, it is still portable in the sense that it's architecture independent. What were you talking about? > There is no need to require that a file like debian-changelog-mode.el > is compiled. If the user wants such a file compiled he can do it > himself and put the compiled file in a /usr/local directory. Why add this hassle if we don't have to? I have yet to see a good argument not to make it automatic. > Large elisp packages, like auctex or vm, are either included in the > emacsen, or specific for GNU or XEmacs, thus they are already compiled > in the package. Even if this is true across the board, it may not always be true. We should plan for a scalable solution. > The most important thing is that the shared directory issue is > solved, and this is best done by not compiling elisp files from > packages otherwise unrelated to emacsen. I agree that the shared directory is important; I disagree with your solution. -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian-devel subscriber count
"Simon's Mailing List Account" <[EMAIL PROTECTED]> writes: > Well, I'm not a developer (yet), but am in the process of switching > various servers from Redhat to Debian, and wanted to get a feel for > how active the developer community is. Hope we didn't disappoint :> -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Taking over production of emacs20 package.
Sten Anderson <[EMAIL PROTECTED]> writes: > You are right, it might be possible. You would know that better than > me anyway. But I don't like the idea because it is unnecessary. Why > should a resource-hungry emacs compilation be executed just to > install dpkg-dev? Is it really that important that > debian-changelog-mode.el is byte-compiled during installation? OK, I haven't investigated the compilation resource requirements that thoroughly [1], and as I've said I'm pretty much just getting started with the package and trying to work out these ideas. However, if we don't generate the .elc files at install time (note that dpkg-dev oes include both the .el and .elc files) then we're going to severely increase the size of the debian emacs add-on packages because they'll have to include all of the .elc files for at least two, perhaps even three versions of emacs, and you'll get them on your hard drive, even if you don't have the relevant version of emacs installed. For example, I eventually want to provide a gnus add-on package that contains the latest "bleeding-edge" gnus for those interested. It really *has* to have all the files byte-compiled. If the files are generated at install time, the .deb file (uncompressed) will be about 800K. If I include the .elc files pre-generated, the package it'll probably be about 10MB. What's worse, people who don't have both emacs and xemacs installed will be wasting about 5MB of hard drive space for no reason. [1] Though is it really that big a deal as long as it gets forked off to the background like the TeX or manpage rebuilds? -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Questions about emacs20 file system layout.
"Larry 'Daffy' Daffner" <[EMAIL PROTECTED]> writes: > >>>>> "APH" == Adam P Harris <[EMAIL PROTECTED]> writes: > > APH> BTW, are .elc files arch-dependant or arch-indep? I've always > APH> wondered about this. > > .elc files are architecture independent. However, they are not > emacs-independent. What happens is: Thanks for the summary. This will be helpful as I try to decide what to do. In a little while I need to have a discussion with the other two emacs maintainers to see what they think (and are willing to try). But first I want to make sure we have a clear idea of what the issues and possibilities are. -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Taking over production of emacs20 package.
Sten Anderson <[EMAIL PROTECTED]> writes: > Imagine the initial dselect session. A zillion packages with elisp > files are being installed simultaneously with one or two emacsen... No, you'd want to do it like the menu package. If I understand correctly, menu forks off into the background waiting until the entire dselect session if finished, accumulating requests, and then runs them all at once in a single pass. > May I suggest a middleway: You write your compilation program as you > intended, but instead of calling the program from the postinst > scripts, it is left in /usr/sbin for the user to run manually. The > postint (and the user manual) could write a warning telling the user > to run the script. This way it only has to run once when multiple > packages are installed. I'd really like to avoid more messages during the install process if possible. Most likely, people will miss it unless I put a pause (which is even worse than the message), and then they'll just be annoyed that Debian's emacs is *really* slow. > (Maybe the program should also include an option for cleaning .elc's > if an emacsen is uninstalled?) Oh, I'm planning for that to be automatic. The emacs maintainer will just have to have an appropriate call in the postrm. -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Moving topics from debian-private (was Re: SPI money out)
Guy Maor <[EMAIL PROTECTED]> writes: > Gnus. While I agree that Gnus is the best thing since sliced bread, keep in mind those in other countries where net access is *much* more expensive. For these people, deleting the duplicates after they download them is closing the barn door after the horses have eaten the chickens. -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Questions about emacs20 file system layout.
Manoj Srivastava <[EMAIL PROTECTED]> writes: > Please also involve the people who maintain emacs lisp > packages as well, since the decision shall have major impact on us. Oh, of course. I certainly meant to include you. -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
Michael Alan Dorman <[EMAIL PROTECTED]> writes: > This is part of an email exchange Sven and I had. Simply put, I put > in a new alpha binary of dpkg-1.4.0.19 that represented nothing but a > recompile to pick up new libg++, ncurses, etc. Sven suggested that > this warranted a non-maintainer-release number, whereas I had gotten > the idea that non-maintainer-releases suggested code changes. I think if you browse the changlogs of various package, you'll see a number with non-maintainer releases with entries like: * recompiled for libc6. So I'd say the practice, at least, is that code changes are not a necessary criteria. -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Taking over production of emacs20 package.
Manoj Srivastava <[EMAIL PROTECTED]> writes: > Also consider the fact that all maintainers may not have > enough resources to have all possible flavours of Emacsen on their > machines (Xemacs19, Xemacs20, emacs19, emacs20, emacs20-no-mule, > Xemacs-no-mule, ...), and keep track of which versions were elc > compatible anyway. Read my mind. I actually had this objection in my previous mail, but took it out since it seemed a littly weaker and I wanted to stick with one point at a time. > On the other hand, some packages (Quassia gnus and VM are examples) > that do funny things in the Makefile in order to compile the el > files; it is not just a matter of > # $(EMACS) -batch -f batch-byte-compile *.el Yeah, my idea certainly won't work for every elisp package, but it would hopefully work for some. > Alternately, each maintainer can maintain a package for one > flavour of Emacs ;-(, and have co-maintainers for ther > flavours. I thought of that too, but that's certainly a little ugly. In the end, though, it may be necessary. As mentioned above, some packages may just fit the compile at install mold. > ps. Oh, I, too, thought of making public my private quassia gnus > package, but it is way too volatile, I think, for general > distribution. I'd put it in experimental. > It is not 10M, BTW, just 5675K. I was talking about the case where you had to have all the .elc files for all the byte-incompatible emacsen within one debian package. -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Taking over production of emacs20 package.
[EMAIL PROTECTED] (Christian Lynbech on satellite) writes: > I think the number one question we need to address is whether we want > to support running Xemacs and GNU emacs at the *same* time. The answer is "if it's not an unbelievable technical obstacle, then yes, we do." > I do not believe that one can sensibly in the longer *use* both Think multi-user system. > If we do, there is probably no way around having the .el files in one > directory and compile .elc files to another emacs variant specific > directory. But again, this does not need to be that complicated. One > could install the .el files in the standard shared directory > (/usr/share/emacs/site-lisp being my favourite, since this is the > default location) and then hack the bytecompiler to generate .elc > files into a subdirectory (say `.emacs-elc' and `.xemacs-elc') and > finally hack the loader to try the subdirectories first. Don't forget: > this is emacs, the extensible editor :-) Right, that's one of the proposals. > Separate packages such as auctex or cvs, which needs to install elisp > files, definitely should have one and only one central location to > stuff things into. Absolutely. > Requiring all packages to come compiled with both variants is NOT the > way to go. It will waste diskspace, both on users and for the > maintainers of packages containing elisp, that now *has* to have both > variants installed. That's my feeling. -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Service registration
Manoj Srivastava <[EMAIL PROTECTED]> writes: > This will not work for packages like Gnus, bbdb, w3, > hyperbole, vm, and psgml, since the compilation requires selectively > preloading some files, or even running complex build-scripts during > the compilation of the elisp files. Well, I think Guy's proposal has a lot of merit, but it just may not be the *whole* solution. As pointed out, though I haven't looked at the Gnus Makefile in detail, things like Gnus have a complicated build process that may involve more than just byte-compiling to handle several emacsen. In cases like that, it may make sense to do much of the work at pacakge build time. Then you might be able to end up with a package that containes all of the non-.elc stuff for each emacs, and then use the service registration procedure and appropriate hooks to handle the .elc generation. I guess what I'm saying is that Guy's proposal may be a good general purpose approach that can be used to completely solve simple cases (for emacs and other packages like menu, etc), and, when supported by some other work outside the scope of the service registration process, may be able to handle the more complex emacs cases as well. -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Near and long term plans for the new emacs20 package.
OK, after digesting the recent conversations about what needs to be done for the various Debian emacsen (thanks everyone). I've come to the following conclusions: There's a substantial amount of work to do to get this problem solved properly: to allow simultaneous install of all flavors, to support the auto-generation of .elc files when appropriate, and to allow elisp files to be easily shared when appropriate. Coming up with the right answer is going to require a conversation with the various emacs and emacs package developers, a policy proposal, and a (hopefully reasonably) brief revision process to be followed by an implementation. In the end, this is what I want to do, but it's going to take longer than I'm willing to wait with respect to getting an initial emacs20 package out. So, unless there's a good objection, I'm going to provide a short-term solution before working on the larger problem. I'm going to release an emacs20 package that's similar to the existing emacs 19 package. It won't coexist with xemacs any better than the current package, and it probably won't move the relevant files to /usr/share. Since it's byte-file compatible with the current emacs 19 package it won't have to conflict (I hope), so the install should be pretty painless. This will also keep me from biting off more than I can chew. I can get comfortable with the emacs build process and source, and make sure I get all the bugs worked out before tackling the bigger issues. Comments? -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: ppp's ip-{up,down} and possible utilization of 'run-parts'
Philip Hands <[EMAIL PROTECTED]> writes: > If people really think it is necesary I can add: > > PPP_TTYNAME=`/usr/bin/basename "$2"` I think this is a bad idea. Anyone who wants to do this, can, and throwing away information in situations like this is usually a bad idea. Consider this (obviouly contrived) example. Say I decide for some really strange reason to symlink a device file into my home directory: (cd ~/mydev && ln -s /dev/ttyS0 .) With the "basename" approach, you *completely* lose the ability to distinguish pppd /dev/ttyS0 and pppd /home/rlb/mydev/ttyS0 Note, that I'm not saying that I can come up with a good argument why it would be important to be able to make this distinction (or to even do what I'm depicting in the example), but I am saying that since I can't prove to myself that the exact arguement used to invoke pppd will *never* be crucial, you shouldn't mangle it. -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Recompiling elisp files (Re: Taking over production of emacs20 package.)
Christian Lynbech <[EMAIL PROTECTED]> writes: > 1) generating/editing .el files (gnats and tm are examples of this) at >build-time. This is not a problem since the generated .el file is >installed as part of the .deb file. This is a problem if these packages need to work with both emacs and xemacs. The two are .elc file incompatible. > Does anybody know of a concrete example where recompiling a set of > installed .el files in some specific (say alphabetic) order will fail? > Gnus in the emacs distribution used to have this problem, I seem to > remember, but it does not seem to be a problem in 19.34 (I maintain > emacs under CVS which by default ignores .elc files and thus want to > recompile lisp/). I think gnus might fit this criterion. It has a full blown makefile, but I haven't checked to see how complicated the actions are. I think at this point I favor Guy's service registration proposal, but there are some details that have to be considered. I won't be doing anything about any of this fancier stuff for a couple of weeks, though. -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Service registration
Manoj Srivastava <[EMAIL PROTECTED]> writes: > Because the normal build process is to say make build; And, as I just realized, this in itself could be problematic. Are we going to add "Depends: make" to the emacs lisp packages that do this in their postinst? I guess we could, but it seemed a little unsettling when I first realized that it would be required. > and it may need files that may not be available. Also, a script is > not easy to build from a complex multi directory make process: case > in point: tm-7.106. I maintain a local deb package (I have no real > reason for not using the official package), so I know how complex > that is. Well, I don't see how to fix the "needing files that aren't available" problem (when does this happen?), but the multi-directory make process shouldn't be a problem. There's no reason the hook file for tm in Guy's proposal couldn't just execute (cd && make) I do agree that there are other complexities to work out. -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Paranoia, "pristine sources", turnkeys, compiling, configuration
Hamish Moffatt <[EMAIL PROTECTED]> writes: > No no, Linus agrees with our method. Right, check out /usr/doc/libc6/FAQ.Debian.gz for the word from the horse's mouth. Also, people (rightfully) mentioned considering make-kpkg for building your kernels. You can find it in the Debian kernel-package package. It makes building your kernel much easier, and (more importantly in my view) leaves you with a Debian package containing the new kernel. This makes it easy to switch back and forth between kernel configurations (using different kernel packages) without worrying about making a mistake. -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: ppp's ip-{up,down} and possible utilization of 'run-parts'
Raul Miller <[EMAIL PROTECTED]> writes: > Rob Browning <[EMAIL PROTECTED]> wrote: > > Note, that I'm not saying that I can come up with a good argument why > > it would be important to be able to make this distinction (or to even > > do what I'm depicting in the example), but I am saying that since I > > can't prove to myself that the exact arguement used to invoke pppd > > will *never* be crucial, you shouldn't mangle it. > > Alternate devices directories might be useful in a secured network > environment (e.g. each physical set of connections gets its own > directory with its own permissions). Right... Pretend like I used what Raul said as my example. -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Emacs20 and mail file locking.
My question is, should I modify emacs to use maillock from liblockdev, or it the emacs mechanism OK (what about NFS)? My reading is that emacs needs to be modified, but since liblockdev requires you to call touchlock on a regular basis, I'm worried that the modification might be non-trivial. Here's the relevant bit from the Emacs config: /* define MAIL_USE_FLOCK if the mailer uses flock to interlock access to /usr/spool/mail/$USER. The alternative is that a lock file named /usr/spool/mail/$USER.lock. */ /* On GNU/Linux systems, both methods are used by various mail programs. I assume that most people are using newer mailers that have heard of flock. Change this if you need to. */ #define MAIL_USE_FLOCK And here's the relevant bit from debian-policy: All Debian MUAs and MTAs have to use the `maillock' and `mailunlock' functions provided by the `liblockfile' packages to lock and unlock mail boxes. These functions implement a NFS-safe locking mechanism. (It is ok if MUAs and MTAs don't link against liblockfile but use a *compatible* mechanism. Please compare the mechanisms very carefully!) If emacs' current mechanism *is* compatible, then I could save some hassle. 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 FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Taking over production of emacs20 package.
Brian White <[EMAIL PROTECTED]> writes: > Is the "emacs" package being renamed into "emacs19"? (I saw several > mentions of that name.) If so, could not both emacs19 and xemacsnn both > "Provides: emacs"? The new emacs package is going to be named emacs20. The older one may or may not be renamed to emacs19, and unless there's a reason not to, I agree that all three emacsen should "Provide: emacs". -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Emacs20 and mail file locking.
[EMAIL PROTECTED] (Mark W. Eichin) writes: > I'll note that emacs19 does what was right at one point, *before* > liblockfile was written; I don't know if they're compatible but figure > that before debian 2.0 it would be safest to code up a fix. (Or steal > your code from emacs20 :-) My suspicion is that the way it's done now in emacs 19 will still work as well as it did before, which is probably fine for everything but NFS. Using maillock would fix the problem completely, but will probably require some code weaselry. Unfortunately, the policy says to check the implementation in maillock to see if you're compatible, and the manpage for maillock says to see lockfile_create(3), which doesn't exist. I'll have to UTLSL, but I may release an initial package before doing all that. Things won't be any worse than they are now, and then then I can see about fixing both emacsen. -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dselect features request
[EMAIL PROTECTED] writes: > 1) Once all packages are selected, be able to dump the selections to > a file that could be later read in for subsequent identical > installations. Try $ dpkg --get-selections > foobar [ move foobar to another machine ] $ dpkg --set-selections < foobar > 2) Once all packages are selected, don't skip packages that are > deselected, just ignore them. Dselect for ftp install works this > way, why can't the disk based dselect as well? It looks like much > time is spent "skipping" packages that do not need to be > installed. I think that the dpkg-mountable package might eliminate this problem if you use it as the access method, but I haven't tried it yet. -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
potential mayhem with trial libc6 package and kernel-headers
I recently installed the new libc6 experiental pacakges which also wants you to install kernel-headers. The problem is that kernel-headers thinks it "owns" /usr/src/linux. For users using the kernel-package (or whatvever) to build their own kernels, this may be a problem. It was at least surprising. In my case, I didn't even notice that kernel-headers added the /usr/src/linux link, and since I normally don't ever have a /usr/src/linux on my machine, I can just assume that it's safe to untar a new kernel in /usr/src and then "mv linux linux-" [1]. However, when the kernel-headers package is installed, this means I'm unpacking my new kernel source into the kernel-header package's directory -- not good. Now I'm happy to just change my behavior, and unpack the kernels I download somewhere else, but I think you're going to see some mayhem when this pair of packages is released and other people doing something similar suddenly have to treat /usr/src/linux as read only without being warned. [1] Why Linus has linux-.tar.gz unpack linux rather than linux- has never made much sense to me. -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: potential mayhem with trial libc6 package and kernel-headers
Manoj Srivastava <[EMAIL PROTECTED]> writes: > I genrally unpack into /usr/src/local and mv things one level > up, personally. That seems reasonable. I guess I had just sort of always treated /usr/src/ as if it was local, even though I probably shouldn't have. > Rob> Now I'm happy to just change my behavior, and unpack the kernels > Rob> I download somewhere else, but I think you're going to see some > Rob> mayhem when this pair of packages is released and other people > Rob> doing something similar suddenly have to treat /usr/src/linux as > Rob> read only without being warned. > > What do you sugggest, modulo maintaining backward > compatibility to people who have old kernel-source packages > installed? I don't really have a good suggestion, but I think that this should be somehow *widely* advertised with the new libc6 arrangement. I don't know if I'd go so far as an actual pause in the postinst, but this could be a fairly serious problem. People who weren't using kernel-headers before (because they never needed it), may be in for a shock. -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Emacs20 and mail file locking.
David Frey <[EMAIL PROTECTED]> writes: > It isn't. The old policy mandated dot-lock, IIRC. OK, then I'll assume that we want to hack emacs to use liblockfile. This requires repeatedly calling touchlock() to keep the lockfile from being deleted during the period when the lock is being held. I think this may be a problem if emacs grabs the lock (with maillock()), and then the user suspends the program for more than 5 minutes (the default timeout for maillock). When emacs resumes, the lockfile has been deleted, but emacs still thinks it has the lock. The only simple way I can see around this problem is to have emacs spawn a small process to keep touching the lockfile (every 4 minutes or so) whenever it acquires the lock, and kill that process when the lock is released. Does that seen reasonable to everyone else? -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
What's Debian's /usr/src policy.
The question is, "who owns /usr/src, Debian or the local sysadmin?"
A recent run-in with the latest pre-release libc6 packages made me
realize that I hadn't fully considered the role of /usr/src on a
Debian system.
In general, I had always considered Debian as "owning" everything
outside /usr/local, /usr/src, and /home. By "owning" I mean that I if
I did anything fancy in the regions that belong to Debian, I should
expect that work might get clobbered later by new Debian packages, or
updates to existing packages.
Unfortunately, kernel-headers, which I had to install for the first
time because of a dependency from the upcoming libc6-dev package,
clobbered my existing *local* kernel source tree headers by writing to
/usr/src/linux which was already a link I had created to
/usr/src/linux-2.1.73. kernel-headers is not the only package
claiming space in /usr/src that might conflict with current practices;
pcmcia-source does as well.
I really only see two possible choices.
1) Flatly state /usr/src/ is owned by Debian. I.e. it is no safer to
put anything there than in /bin. If you want to put something in
/usr/src/ (because you're building kernels with kernel-package or
whatever), you should use /usr/local/src/ instead. This policy, if
adopted, will have to be *heavily* advertised.
2) Try to accomodate user files in /usr/src. This would cause the
least conflict with all the existing kernel/PCMCIA HOWTO's, etc about
where things you unpack should go, but having user files in /usr/src
would probably make it nearly impossible to write "safe"
{pre,post}{inst,rm} scripts for the relevant packages. (Note that the
"bug" that got me was in the kernel-header's postinst where it assumes
that if /usr/src/linux is a link, then it is safe to unpack there.)
I'm not sure what the right answer is, but I think we need to consider
the problem before the new libc6-dev gets released from the
experimental stages, and we certainly need a long-term policy.
--
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Emacs20 and mail file locking.
[EMAIL PROTECTED] (Karl M. Hegbloom) writes: > I don't think that the dot locking done by `movemail' is nfs-aware. > You'd need to use libnfslock for that, I guess, or patch `movemail'. Assuming you're right, and movemail is used for all mail locking, then if we patch movemail to use liblockfile, we should be fine. I'm under the impression that liblockfile handles everything, including nfs. I believe libnfslock is transitional, for use until everything's migrated to liblockfile. -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Emacs20 and mail file locking.
[EMAIL PROTECTED] (Karl M. Hegbloom) writes: > I volunteer to try rolling those patches into XEmacs 20.5. I think > that configure ought to detect `liblockfile' and compile `movemail' > accordingly. Sound right? Sounds good, but perhaps it should just fail to build on a debian system if liblockfile-dev's not installed. Otherwise, without source dependencies, it would be easy for a non-maintainer release (if there ever is one) to be built broken, such that mail could be lost. Given this possibility, messing with configure might be overkill. Just hard code the -llockfile, and be done with it. I guess you could go so far as to have a configure option that forces the use of liblockfile, and then put that in the rules file, but that may be more trouble than it's worth. In any case, let me know how it goes. I'd like to be able to steal your work for incorporation into the emacs 20 package, if possible. > Rob> I'm under the impression that liblockfile handles everything, > Rob> including nfs. I believe libnfslock is transitional, for use > Rob> until everything's migrated to liblockfile. > > Yes, that seems right... I looked them over once a few months ago. I > think after I've finished reading the two W. Richard Stevens Unix > programming books I've just begun, I will go over them again with > better understanding, and thus, better recollection. I don't think you even need to go that far; if the man page is to be believed, NFS is handled by liblockfile: DESCRIPTION The maillock function tries to create a lockfile for the users mailbox. This mailbox is typically located in /var/spool/mail. The name of the lockfile then becomes /var/spool/mail/username.lock. Maillock uses an NFS safe algorithm that is documented in lockfile_create(3). -- Rob Browning <[EMAIL PROTECTED]> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
