Netscape packages and lesstif
The dmotif netscape packages seem to depend on lesstif, does this mean you can run them with just lesstif? Or is that in addition to requiring real Motif libraries? I'm surprised (but happily so) since i thought lesstif aimed only at source-level compatibility not binary level. greg
Re: Possible serious problem with the newest sysklogd?
Martin Schulze <[EMAIL PROTECTED]> writes: > > You'll also find the new version which has the offending code removed: > > ftp://ftp.infodrom.north.de/pub/people/joey/debian/sysklogd_1.3-28_i386.deb Does -29 have it reinserted? I'm seeing the same problem. greg
Re: (WARNING) xfree86 3.3.2.3a-2 (source all i386) uploaded to master
Branden Robinson <[EMAIL PROTECTED]> writes: > On Fri, Oct 16, 1998 at 10:25:57AM -0700, Ben Gertzfield wrote: > > > > Branden Robinson <[EMAIL PROTECTED]> writes: > > > > > > W: xext: shlib-without-dependency-information > > > usr/X11R6/lib/modules/xf86Jstk.so=20 > > > > > > I have always gotten this error. I don't know how to fix it, but it > > > doesn't seem to hurt anyone. > > > > Well, this isn't a shared library that's going to be linked to, so > > there should be a way to override lintian's behavior. > > Oh, I get it. The complaint's not about the file itself, but the absence > of mention in a shlibs file. Okay. Well, yeah, that should be overridden. > The only thing that uses those modules is the X server. Maybe lintian should be modified to only run the shared library checks on files in the standard directories listed in /etc/ld.so.conf ? greg
Re: I2O specs mailed to webmaster
Craig Sanders <[EMAIL PROTECTED]> writes: > it was mailed from a dummy hotmail account ([EMAIL PROTECTED]), and the > originating IP was from an ISP in Norway. On the off chance that the original sender is reading this, or looking at the e-mail archive: Hotmail is not an anonymous mailing system, and makes no pretense of such. They will happily hand over records if needed. If you want to send something anonymously I suggest using the cypherpunk PGP remailers. Of course there's no reason not to combine that with sending from hotmail or something like that, but don't count on a system like hotmail for your anonymity. greg
Re: GPL'd libforms dependent package
John Lapeyre <[EMAIL PROTECTED]> writes: > This a kind of interesting looking package. It is GPL'd but > depends on a no-source-available library. I just reread the relevant > portions of the GPL, but I'm no Talmudic scholar. > Can the GPL be properly applied to this ? > > http://ifb.bv.tu-berlin.de/JOCHEN/XSTAB/xstab.html All the author has to do is add something to the effect that ``As a special exception the software may be distributed linked against the libforms library without including the source of the libforms library even though the GPL would normally bar this, as long as the requirements of the license are followed in every other respect.'' or something like that. i'm not a lawyer, check dejanews for how RMS phrased it when he was suggesting something like that for the gimp w.r.t. plugins. In which case the package can go in contrib. However, a better solution would be to try compiling it against fltk. We have a fltk package based on the last stable release (i think) of it before it went non-free. It's a nice lightweight LGPL'd toolkit which is nearly drop-in compatible with libforms. If he isn't using anything tricky it is likely to work with fltk without any source modifications, in which case it can go in main. greg
Re: PGP in the US (Re: formal documents)
[EMAIL PROTECTED] writes: > Kikutani Makoto writes: > > I'm a Japanese living in the United States, but not a permanent > > resident. I've heared that the usage of PGP in the States by a person > > like me is controversial. > > You heard wrong. Your nationality and residency status is irrelevant. Well, not entirely irrelevant, though not really important for this case. It might not be legal for someone to give him PGP or explain how crypto works even while he's in the US. However, Japan is not exactly a big terrorist nation and this is weakest part of the whole thing as far as first amendment violations goes. The government has not to my knowedge even threatened to apply this part anywhere, and many universities with foreign grad students would line up to help defend someone prosecuted on such a basis. In any case it wouldn't be you breaking the law, but the person helping you use PGP. But really, i wouldn't worry about this, the only things the government or the patent holders are likely to worry about are export of crypto and significant commercial use of RSA, respectively. So the safe thing to do is use pgp-us while in the US, and delete it from your computer before leaving the US. (that said, i'm not a lawyer and don't blame me if i'm wrong) greg
Re: Canada to remain mostly free
Avery Pennarun <[EMAIL PROTECTED]> writes: > On Fri, Oct 02, 1998 at 10:35:54AM -0400, Greg Stark wrote: > > > Manley announced new crypto policies, and though the speech is low on > > detail, despite being particularly long-winded, it seems Canada may > > remain in the free world. > > Very cool. It looks like they've really listened to the industry's > concerns! The only thing i'm still worried about is whether they'll change the current system which makes it very easy to distribute free software. It seems likely they'll write whatever regulations they write with the needs of commercial software in mind, and whereas a company would not really mind paying a few dollars for an rubber-stamp permit, any such scheme would kill free crypto development. greg
Re: /usr/X11R6/lib/X11/app-defaults/ may not be conffile ?
Peter S Galbraith <[EMAIL PROTECTED]> writes: > Policy states: > > *Application defaults* files have to be installed in the directory > `/usr/X11R6/lib/X11/app-defaults/'. They are considered as part of the > program code. Thus, they should not be modified and should not be > tagged as *conffile*. If the local system administrator wants to > customise X applications globally, the file `/etc/X11/Xresources' > should be used. > > What's the logic here? app-defaults files are very version specific. If you have the app-defaults file from one version of a program that depends heavily on it installed and update to a newer version the program then that program would probably not display correctly at all. greg
Re: 2.0.34 and x-bit on libraries
Heiko Schlittermann <[EMAIL PROTECTED]> writes: > Hello, > > as somebody (Harald Schueler <[EMAIL PROTECTED]> pointed out > and as we (Paul Seelig <[EMAIL PROTECTED]> and me) could > reproduce after some grief about a non-functional ftp server (using > wu-ftpd-academ) we got the impression, that > > . 2.0.34 needs the x-bit on shared libraries! The kernel doesn't know about shared libraries at all. The place this policy could change would be in ld.so / ld-linux.so. There has in fact been a related change in policy: * Changed ld-linux.so and libdl.so to match glibc by not allowing user preloads of system libraries into setu/gid binaries unless the library itself is setuid. But I don't think it requires the execute bit as well. greg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bad kernel 2.0.34 bug ?
> > > On Wed, Jun 24, 1998 at 12:24:52AM -0700, G John Lapeyre wrote:
> > > > A typical error message is (this occurs on 2 of three drives):
> > > >
> > > > Jun 23 20:35:40 homey kernel: hdb: read_intr: status=0x59 { DriveReady
> > > > SeekComplete DataRequest Error }
> > > > Jun 23 20:35:40 homey kernel: hdb: read_intr: error=0x40 {
> > > > UncorrectableError }, LBAsect=6766956, sector=211869
> > > > Jun 23 20:35:40 homey kernel: end_request: I/O error, dev 03:46, sector
> > > > 211869
Are you running with unmasked interrupts?
hdparm -v /dev/hdb
and look at the unmaskirq flag.
If so try turning it off?
greg
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Including non-PIC code in a shared library?
Charles Briscoe-Smith <[EMAIL PROTECTED]> writes: > > I asked about this on ggi-devel, and the responses I got indicated that > it probably wasn't a problem, because there would only ever be one > libGGI program running the xf86dga target at once on a given machine > (not true for multi-headed machines) and that if multiple copies were > run, the kernel would simply load multiple copies of the code. I'm a > little worried that mixing PIC and non-PIC code might do some other harm. > Does it? Or will it just make this "shared" object unsharable? It will "work" it's just very inefficient. The loader needs to fix every memory reference in the code to point to the location it loaded the library code. It also can't load the library using shared memory, it has to make private mappings for each process using the library. It's not the end of the world, it just defeats the purpose of using shared libraries. In fact it's worse than statically linking which can at least share memory across invocations of the same executable. greg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libc6_2.0.7 release notes...
Hamish Moffatt <[EMAIL PROTECTED]> writes: > On Mon, Jun 22, 1998 at 11:54:05AM -0400, Dale Scheetz wrote: > > In both these examples the "cludge" only hangs around for a while, while > > the epoch gets stuck on the version forever. > > Is it really that bad? You said you don't want the clutter of it but > I can't really see how there is much clutter. I find Santiago's > suggestion of a manual upgrade absurd. Here's another reason using the epoch for this situation is bad, if you continue the process you get something like: 2.0.6 2.0.7pre1 1:2.0.7 1:2.0.8pre1 2:2.0.8 2:2.0.9pre1 3:2.0.10 3:2.0.10pre1 4:2.0.11 ... Essentially you are completely overriding the version number with a hidden version number that the user isn't presented with. If we want to go this route we could just abandon sorting on upstream package version and number our releases sequentially. That may not be an unreasonable way to go, but it certainly isn't the system we're using now. greg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
packaging PAM modules? anyone?
I asked once earlier, but no one responded: Does anyone know how PAM modules should be packaged? Where should they be installed? Is there some way to register them, or some script to run to offer the sysadmin the option of making the new module the global default? Personally I think PAM modules are one of the big missing links for Unix system and no distribution would be complete without a solid architecture for dealing with them. We have ppp-pam and pam packages, but how does packaging further modules work? Kerberos won't be properly supported until there's a PAM module for it packaged. There are a couple around, but I have no idea how to package them. I don't even know how PAM is configured and I don't use it here at all. greg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: fltk anyone? + packaging questions
I already uploaded a fltk package. BTW, this is why you're supposed to announce intention to package something before working on it. Incidentally, I just skipped form.h and glut.h, on the assumption that someone could just could just create a dummy file like it in their build directory. Another place they could go is inside /usr/include/FL, people would add -I FL to get them. Another issue is that I built it with a prefix of /usr, not /usr/X11. The FSSTND is ambiguous on this, but seems to imply /usr/X11 is for the "X Window System" itself, not just any program that happens to use X. And Personally I don't see any reason to put X programs in a separate directory. greg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Proposal, new system for dealing with non-us stuff
Here's an idea for another way to deal with non-us stuff that should be less error-prone and make it easier to implement some new features. I would like to see each package include an "Excluded" header listing country codes the package should be excluded from. The header could be used in several steps to get packages to the rights places. some ideas of how to make use of this information: 1) A single control file could contain all the packages and debhelper/dupload could automatically exclude non-us packages when building on a US build engine or build them all but segregate the restricted packages and upload them where they belong. 2) A complete archive could contain all the files, but generate file excluded.us, excluded.fr, etc. which mirrors could use to exclude the appropriate files. 3) The US archive could still contain the complete Packages file, but APT could be made aware of which exclusions each archive follows and choose one that should have a given package. In fact the US archive could be a complete mirror except for the files listed in the excluded.us file. A further refinement might be "virtual domains" like crypto, weak-crypto, crypto-authentication. Which would avoid problems if new countries ban crypto or existing ones change their laws. Maybe this isn't important enough compared to having apt/dselect deal with source packages, but the current situation just seems awkward and i think we could do a lot better. [ I've sent this to debian-policy but Bcc'd debian-devel. Further discussion should continue on debian-polcy. ] greg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: INTENT: to pkg netscape 4.5 full debs(not 4.05)
Adam Heath <[EMAIL PROTECTED]> writes: > As some of you might know, I have been working on full debs of netscape > 4.05. I have everything almost perfect, except for the reporting clause. Is there any possibility we could get permission from Netscape to skip the reporting clause? Frankly I'm concerned any such reporting directly from the client machine would be a nasty privacy violation. Since it's going in non-free anyways it doesn't particularly matter if it has debian-specific permissions. It would also be interesting to generate a pre-fortified version for nonus. greg PS: this may all be a distraction from working on real free software, but it's a darned attractive distraction... It would be real nice to a have a proper netscape package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#22942: Advice for release critical bug (WAS: Bug#22942: libpaper depends on libpaperg)
Marco Pistore <[EMAIL PROTECTED]> writes: > > Now, in hamm the binaries are only in libpaperg, since they are linked > against libc6 libraries; package libpaper in hamm contains only the > libraries. So, the original cause of the problem is that the binaries were in the library package. The policy specifically prohibits that precisely because of these problems. And you're proposing the libc6 versions keep doing the same thing that caused the problem in the first place. What I would suggest would be: libpaper: libc5 libraries only libpaperg: libc6 libraries only libpaper-utils: both binaries, depends on libpaper|libpaperg with wrapper scripts to choose the right ones somehow This will at least avoid the problem in the future, as another version of the library can be installed simultaneously without conflicting with the existing libraries. greg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: packaging kernel modules
Hamish Moffatt <[EMAIL PROTECTED]> writes: > On Wed, Jun 10, 1998 at 10:41:41AM +0200, Yann Dirson wrote: > > > I think the various modules should be primarily packaged in source > > form, just as the kernel is, and installed under /usr/src/modules/. > > This sounds excellent. On one machine I am running 2.0.33 > and have the appropriate ntfs package installed, but it will not insert > (many missing symbols), presumably because it is my own compilation > of 2.0.33. Similarly I just upgraded another box to 2.0.34 and have > installed ftape-3.04d from sources. It is presently much easier to work > with sources to such kernel addons, imho. I disagree. You're about to follow the same path that was followed for kernel-source which has various awkward problems. Forcing .deb files into handling source packages is a bad idea. Instead we should add an option to dselect/apt to download and unpack the real source package in /usr/src. If we compiled the standard kernel with CONFIG_MODVERSIONS then we can safely install modules in /lib/modules or /lib/modules/2.0 instead of for a specific version. This doesn't really handle conflicts between different incompatible versions of a 2.0 kernel, but for modules like alsa would probably work fine. Otherwise the user can download the source package and recompile. greg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Uploaded mpsql 2.0-1 (source i386) to erlangen
Michael Meskes <[EMAIL PROTECTED]> writes: > Yann Dirson writes: > > Hm, assuming the "b1" means it's beta stuff, I think it would be > > better to keep it in the Debian version. Changing the version number > > Yes, but then slink is also beta. > > > * heavily using epochs > > I HATE epochs! > > > * add a string like "final" to the version when out of beta (I'll use > > this for fweb) > > I did that for my NMU of lyx, but it's not exactly nice either. this problem keeps coming up. i was thinking it would be handy to have a character that is defined to sort before 0 and before the empty string. tilde seems like the best choice to me, so something like: krb4-0.9.9~980514 fltk-0.9.9~980527 mpsql-2.0~b1 which i think is probably clearer than what i actually did: krb4-0.9.8.980514 fltk-0.9.8.980527 or the other suggestions. just an idea. greg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#22928: New upstream security fix release
Branden Robinson <[EMAIL PROTECTED]> writes: > 2) There needs to be a new terminal type, xterm-debian, which tracks the > latest XFree86 xterm entry but incorporates our keyboard policy (and > anything else we want to customize). I need to coordinate with the > ncurses-base maintainer and some other folks about this. Ideally I should > provide an xterm-debian termcap entry to the maintainer of termcap-compat > as well. There are some issues with terminfo/termcap I don't grok yet, so > yesterday I bought the O'Reilly book on them and will be dredging it for > clues. An "xterm-debian" terminal type may sound strange at first, but > please don't jump on me saying it's a bad idea. Ian Jackson, Mark Baker > and I took at this issue and it looks like the best solution. I don't have > the bug number for that discussion handy. Would this be the default TERM value for xterm? I assume you realize that this means any user telnetting from a debian machine to any other distribution or OS will not get a useful terminal. I think this is an truly awful idea, instead we should simply not make local customizations beyond the necessary BackSpace/DEL handling. Few programs depend on the setting of the kdch and many other machines also use DEL for BackSpace, so really that isn't a problem. Just resist the temptation to customize various other keys and you'll avoid problems. Really, it would suck a lot to not be able to telnet to other hosts without manually setting TERM to a useful value. Many people won't even realize what's wrong. Providing an additional entry for use by people who want it might be a nice feature, but only if it's not the default, and not necessary for Hamm. What should really happen is that X11R6.n should provide a new terminfo entry for the new xterm behaviour which should include using DEL for kdch and we can assume that entry is widely available. Trying to fix it with a local hack like "xterm-debian" will only cause more problems than it will solve. greg PS: I'm sorry for ignoring your expressed wish not to be told it was a bad idea, but, well, it's just that it's a really really really bad idea. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
What version of glibc in Hamm?
Currently the version of glibc in frozen is older than the version in Slink. Does this mean we plan to release Hamm with that prerelease of glibc? Or are we planning on including 2.0.8 when it's released? If we plan to include 2.0.8 we really ought to push the latest prerelease into frozen to test packages against it. greg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Bazaar Politics (was: Debian Re-organization proposal)
Fabien Ninoles <[EMAIL PROTECTED]> writes: > I just split the subject of the previous to take more about politics in > Debian and let people discuss about the proposal. > > I think we too much mess up with wordin like democracy and government. > Debian are neither. It's a bunch of volunteers trying to work together. Yes. > Debian already works correctly for most of the Decision making process. > Ideas are submit, discussed and most of the time, something came out Yes. > We are an example. We do the Bazaar all the way. We should be proud about > it. Not even red hat or slackware want to deal with so a big goal as > we do in Debian [eh, we triple the number of package and support not > two or three but four architectures!] Debian is still an example, and for > now, we just try to solve the normal organisational problem it's happen, > I mean ensuring that an idea wasn't lost in the under the normal mess of > any bazaar. What he said! Seriously people, don't get too psyched out by missing a release deadline. Every project struggles to meet release deadlines, every project occasionally fails. Especially when a major system-wide change is made, like libc6. And the nature of release engineering is such that the further you fall behind the harder it is to get the release out. Really, don't jump to conclusions like "Debian obviously can't continue the way it's been going". We screwed up once. We should keep that in mind next time a deadline looms or release requirements start getting overambitious. greg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package inorwegian, norwegian words for ispell. (and a bit about wnorwegian)
Stig Sandbeck Mathisen <[EMAIL PROTECTED]> writes: > all that's left is the copyright document > As for the norwegian wordlist "wnorwegian", I've been unable to produce > a copyright, seems that this just evolved on the net. In at least some countries simple lists of words are not copyrightable. I'm not sure what the status is on that as far as international law and the Berne convention. greg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Differences of Debian vs. the Other Guys
Manoj hit all the major points, and about every other point under the sun :) But I would like to expand on what I think are the key differences. 1) It's a distributed volunteer based system with lots of contributors. This sometimes leads to long arguments, but it means that policies must be thrashed out and specified precisely. It means that systems must have well designed modular interfaces to make it possible for packages to be maintained effectively by different maintainers. It also means we have a huge number of packages, all of which are held to the same standards and using the same bugtracking system. No directories of "use at your own risk" contributions. 2) Debian has a very strong commitment to Free Software. Everything in the distribution proper is supposed to be Free Software. Non-free software is in a separate section which isn't included on most CDs. Users of Debian can be sure they have the freedom to use and modify any component of the distribution without breaking restrictive licenses. I've included our Social Contract and the Debian Free Software Guidelines below to help make this clearer. Debian GNU/Linux Social Contract We are Software In The Public Interest, producers of the Debian GNU/Linux system. This is the "social contract" we offer to the free software community. "Social Contract" with the Free Software Community 1. Debian Will Remain 100% Free Software We promise to keep the Debian GNU/Linux Distribution entirely free software. As there are many definitions of free software, we include the guidelines we use to determine if software is "free" below. We will support our users who develop and run non-free software on Debian, but we will never make the system depend on an item of non-free software. 2. We Will Give Back to the Free Software Community When we write new components of the Debian system, we will license them as free software. We will make the best system we can, so that free software will be widely distributed and used. We will feed back bug-fixes, improvements, user requests, etc. to the "upstream" authors of software included in our system. 3. We Won't Hide Problems We will keep our entire bug-report database open for public view at all times. Reports that users file on-line will immediately become visible to others. 4. Our Priorities are Our Users and Free Software We will be guided by the needs of our users and the free-software community. We will place their interests first in our priorities. We will support the needs of our users for operation in many different kinds of computing environment. We won't object to commercial software that is intended to run on Debian systems, and we'll allow others to create value-added distributions containing both Debian and commercial software, without any fee from us. To support these goals, we will provide an integrated system of high-quality, 100% free software, with no legal restrictions that would prevent these kinds of use. 5. Programs That Don't Meet Our Free-Software Standards We acknowledge that some of our users require the use of programs that don't conform to the Debian Free Software Guidelines. We have created "contrib" and "non-free" areas in our FTP archive for this software. The software in these directories is not part of the Debian system, although it has been configured for use with Debian. We encourage CD manufacturers to read the licenses of software packages in these directories and determine if they can distribute that software on their CDs. Thus, although non-free software isn't a part of Debian, we support its use, and we provide infrastructure (such as our bug-tracking system and mailing lists) for non-free software packages. The Debian Free Software Guidelines 1. Free Redistribution The license of a Debian component may not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license may not require a royalty or other fee for such sale. 2. Source Code The program must include source code, and must allow distribution in source code as well as compiled form. 3. Derived Works The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software. 4. Integrity of The Author's Source Code The license may restrict source-code from being distributed in modified form _only if the license allows the distribution of "patch files" with the source code for the purpose of
Re: Image names "rescue" and "default" was: Re: April 11th bootdisks - major failure
Oh, also another problem. Various commands from the ramdisk hung, i had to reboot a couple times when all the virtual terminals were hung. And many commands on the installed partition didn't work. I imagine this might be some kind of shared library snafu, though who knows? Maybe it would make sense to ship the ramdisk with a ld.so.conf listing /target/lib and /target/usr/lib after the normal directories. greg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Install process
Sigh, after writing that whole thing i looked at the new install.html and saw that more or less precisely what i described is in there. As someone recently said on linux-kernel, what tasty shoe leather i'm wearing today. Sorry, greg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Install process
I just went through the process yesterday, and I found it quite tedious. Downloading and creating all those floppies, plus debugging problems with rawrite and the bios floppy drivers. And it should all be completely unecessary. It would be really nice if we supported the loadlin method of mkrboot. It would result in a zip2exe executable that could be downloaded and run straight out of dos. It might even be possible to pass a parameter from loadlin with the dos path the kernel was loaded from; the user could mount the msdos filesystem and the install program could read the base disks (or a single image) straight from the original dos partition. greg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: April 11th bootdisks - major failure
Chris Fearnley <[EMAIL PROTECTED]> writes: > Hoo boy, I've been having bad luck with the bootdisks. > > This time, After I hit [ENTER] to load the ramdisks, the system hangs with > the floppy drive light lit after displaying "Loading root.bin..." > > Note the three dots. I take the same boot disk and it works like a charm > on another system. I don't recall having to press enter to continue, i guess you're using the 1.2m disks. Regardless, try another floppy. The instructions talk this, the BIOS disk reading code is a lot less robust than the normal drivers and often has problems reading marginal disks. I had a different problem, after finishing the entire sequence I rebooted and saw the very frightening: Invalid partition table I rebooted with the rescue disk and tried to use the rescue image but got something to the effect that there was no such image. When I used the regular image and ran fdisk and saved the partition table from there it was ok. My confidence in cfdisk is correspondingly lowered. greg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg memory usage
Ian Jackson <[EMAIL PROTECTED]> writes: > On `small memory' systems dpkg switches to a different data structure > which is about twice as slow for general access on a big machine, but > has a much smaller working set so is much faster for setup and access > on small machines. dpkg uses sysinfo(2) to guess which algorithm to > use, and you can force one or the other using command line options. I > have checked this on a 3Mb system and it worked as expected. You might want to tune the threshold upwards. At least on this 16M machine --smallmem is noticeably faster and causes less disk thrashing. > (The resulting structures will still be editable with emacs.) Yay, of course everything is editable with emacs... > It does ask the kernel to confirm that changes have been committed to disk > before it continues. Using fsync, you realize Linux's fsync implementation is to do a full sync. It's probably the cause of much of the disk activity, but quite important. Steve Dunham <[EMAIL PROTECTED]> writes: > I think a single text file would be noticably faster than a bunch of *.list > files, but I don't know how much time is spent on I/O and how much is spent > on building data structures in memory. (It would save the time of scanning > the directory, opening and closing all the files.) Opening files in a large directory can be extremely inefficient in many Unix varieties. The kernel has to do a linear search for each the file. Linux 2.1 should be faster because of the dentry stuff, but even so it would be more efficient to use a directory for each package with the various control files inside. greg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Free-World maintainer for xpdf ?
Dirk Eddelbuettel <[EMAIL PROTECTED]> writes:
> As a Canadian resident, I don't think I can deal with the encryption
> code (as I understand it, the US laws for encryption technology make
> no difference between US and Canadian residents).
The status of Canadian crypto laws is currently in flux.
A summary of the current situation is at:
http://www.efc.ca/pages/doc/crypto-export.html
And also, the government is requesting public comments, the dealine for
submissions is April 21, help keep your country in the free world:
http://strategis.ic.gc.ca/SSG/cy5e.html
Basically the upshot is that if the code wasn't developped in the US and it's
widely available ("Public Domain", only not the same definition as copyright
law, it seems to include basically any Free Software) then you don't have to
worry.
If it's commercial software with restricted distribution then you need a
permit (which is true of many commercial exports anyways).
If it was developped in the US the case becomes murkier and worse the US
officials can consider you involved in exporting it from the US. This might
not matter to you if you don't ever plan on visitting the US and you don't
think they're likely to send the marines after you.
Don't trust me though, you'll have to read the information available yourself
and make judgements for your own legal safety.
greg
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Test Report (was: Re: boot-floppies_2.0.4 (source i386) uploaded)
Enrique Zanardi <[EMAIL PROTECTED]> writes: > > >After running kbdconfig manually, basis layouot was okay, but I > > >couldn't enter german keys. I think this is because /etc/inputrc > > > has > > >"set convert-meta off" commented out. I think it should be the > > >default. > > In fact that was the default for a few libreadline*.deb versions, because > we wanted Debian to be latin1-compatible "out of the box", but Guy Maor > (readline maintainer) changed it back because leaving it "on" broke "META-x" > handling, and there were a few bug reports about that. (Guy also removed some > definitions that made the Home, End and Delete keys work). I guess it's time > (again) to discuss which should be the defaults. Perhaps asking the user at > installation/upgrade time. ick, this should be switched back, I immediately noticed this myself. I don't understand the M-x detail, it doesn't do anything now either. Perhaps alt_is_meta shouldn't be on in the kernel map; if we use ESC prefixes for meta it should work without disturbing 8-bit-cleanliness. greg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is this a bug in libc6?
Avery Pennarun <[EMAIL PROTECTED]> writes: > On Sun, 12 Apr 1998, Hamish Moffatt wrote: > > Is it really so difficult to handle this situation though? Using > > Steve's test program on Solaris does as expected: > > Yes, it would be quite difficult to do efficently. There's no good way to > tell that the pointer you're passing is _really_ a FILE* pointer. Once it's > closed, the pointer's value is meaningless. One cheap solution which will usually work is to put a magic number at the head of the FILE* structure and clear it when the close is done (before the free). This doesn't work 100% of the time but in practice would it would work. > If you try to fclose(NULL) (like when the file can't open and you close it > anyway) it's easy to ignore -- just return immediately if the file pointer > is NULL. But should we do that? > Personally, as a programmer myself, I much prefer to work on a system that > gives up consistently when I do something wrong. That's what segmentation > faults are all about. Well, the problem with the current setup is really that it may or may not crash depending on what data is in the previously allocated structure. It's a source of randomness which is always bad for debugging. And not all programs running with this library were developped with this library. For people compiling software that was developped under solaris or libc5, this will be a real pain. I don't know if there are any run-time debugging flags for glibc, if there are making this print a warning if they're set and always return EBADF would be ideal, imho. greg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is this a bug in libc6?
Manoj Srivastava <[EMAIL PROTECTED]> writes: > Permissible undefined behaviour ranges from ignoring the > situation completely with unpredictable results, to behaving > during translation or program execution in a documented manner > charecteristic of the environment (with or without the > issuance of a diagnostic message), to terminating a > translation or execution (with the issuance of a diagnostic > message). > > Seems like a requirement to me, or else it is not permitted > undefined behaviour. Tell me how fclose in Debian does not volate > this from 1.6 of the standard (IEEE versioning). No it's not a requirement. Requirements are stated in the for "the implementation shall" or "the implementation must", not "permissable behaviour ranges from ... to ...". First of all the latter phrasing doesn't say anything about whether other behaviour is premissable, and second who's to say what falls between the three stated points in the "range" or what constitutes "unpredictable results". What has happened here is that gnu libc has chosen the first choice. Failing to check the input and print a diagnostic message or exit, it completely ignored the situation. The "unpredictable results" (or not so unpredictable really) was that the program received a SEGV. Experience shows checking arguments is not usually hard or expensive and I would support suggesting the glibc people change this behaviour. But it's certainly permissable under ISO to not do so. Thanks for quoting the spec so we can all verify that it explicitly allows the implementation to not check. > (You must admit the comments about monkeys, first made by Chris Torek, was > made under frustation and extreme provocation; and was meant more to drive > the lesson home that to be an interpretation of the standard). If this conversation goes on much longer i'll be in a similar state soon. greg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: intent to package Netscape Communicator
Adam Heath <[EMAIL PROTECTED]> writes: > The nice side effect of my packaging, is that in the original tarball, you > have to download both the static and dynamic versions. My packaging has them > split up. Also, -java is the same between Navigator and Communicator. Any chance of getting a standalone navigator as well? It starts up much faster than the monolithic Communicator. greg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is this a bug in libc6?
Manoj Srivastava <[EMAIL PROTECTED]> writes: > -- > 1.6 Definitions of terms > > ... Permissible undefined behaviour ranges from ignoring > the situation completely with unpredictable results, to ... > __ > > Please show why my statement is incorrect wrt to the above > statement from the C standard. I said: "Corupting memory is not > acceptable behaviour! (Unless you document this)". The standard says > "permissible undefined behaviour ..." > > I understand that it is fashionable in comp.lang.c to say that > undefined behaviour means "It can corrupt memory, re-format your hard > disk, or make monkeys fly out of your nose; all of these are ISO C > compliant.", but the standard does make a statement about permissible > undefined behaviour, and unless such action is documented, it is not > permitted by the standard. Making monkeys fly out of my nose certainly sounds unpredictable to me. greg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT broken ?
So as I see it there are at least three cases here: The install is accidentally broken. Because we've all been living without apt for so long, various inconsistencies can arise. It would indeed be a great feature if apt offered to fix the problems. Since there may be many ways of fixing things it might be best if this were handled in the front-end though. This would give the sysadmin a chance to adjust the solution. The install is broken because of unnecessary dependencies. This is the case the other person (sorry I don't keep old mail from lists) was talking about. Either the sysadmin has installed software in /usr/local or the package maintainer was overeager with dependencies. Currently the best solution is equivs. It might be nice one day to have a front-end for equivs though. The install is broken and the sysadmin doesn't want to fix it. Possibly the sysadmin actually wants a package unpacked but not configured (for example, if the configuring the package changes the systems behaviour and he just wanted the files to be available.) Or possibly the sysadmin simply doesn't want to or can't fix the problem right now (Such as when waiting for an imminent new package that will fix the problem). This last case is the case i'm concerned with. I strongly suggest APT simply refuse to handle any package that directly or indirectly depends on the unconfigured packages, but continue to work on any other packages. A related case is what happens when an error occurs downloading files. Currently it panics and doesn't upgrade anything. Ideally it should check what files have been downloaded, exclude any that can't be satisfied without the erroneous package, and handle the valid ones. For example, just today I tried to upgrade 16 packages. One wasn't in the archive, which caused the entire upgrade to fail. None of the other packages were dependant on that one package. greg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to install editor lisp files?
You should just include the .el file, without bytecompiling, in /usr/share/emacs/site-lisp// If there's code you want every user to run on startup. you can create a file in /etc/emacs/site-start.d/ ideally it should only contain autoloads. The imporant section from /usr/doc/emacsen-common/debian-emacs-policy.gz: 5) Packages with only marginal emacs relevance Generally, if a normal package just contains some emacs helper files, and does not need to perform any byte-compilation or other emacs dependent activities upon installation (for performance or other reasons), then it is not necessary to specify a dependency on emacsen or any flavor of emacs, and the package may just include files located in the standard emacs add-on directories. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
packaging Pam modules?
This package includes a pam module. How should it be packaged? Currently lintian seems to treat it as a normal shared library and complains about the symlinks being wrong. greg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: intent to package: coda (+ copyright question)
Anders Hammarquist <[EMAIL PROTECTED]> writes:
> This file contains some code identical to or derived from the 1986
> version of the Andrew File System ("AFS"), which is owned by the IBM
> Corporation.This code is provded "AS IS" and IBM does not warrant
> that it is free of infringement of any intellectual rights of any
> third party.IBM disclaims liability of any kind for any damages
> whatsoever resulting directly or indirectly from use of this software
> or of any derivative work. Carnegie Mellon University has obtained
> permission to distribute this code, which is based on Version 2 of AFS
> and does not contain the features and enhancements that are part of
> Version 3 of AFS. Version 3 of AFS is commercially available and
> supported by Transarc Corporation, Pittsburgh, PA.
I think it's clear the intent is to say that CMU is legally distributing AFS.
the terms under which CMU is distributing it are as stated above and are DFSG
compliant. I think that's all we're concerned with: the terms under which our
users can use, modify, and distribute the software.
So IBM owns the copyright, they gave CMU the right to distribute their code
under the above terms, and we received the software under those terms from
CMU.
Actually the situation is a little more convoluted than that. AFS was
originally developped at CMU. Some students started a comany to develop and
market it, to which CMU gave the rights to AFS with the proviso that CMU have
the rights mentioned above. Later IBM bought this company, so we end up with
the above strange situation.
greg
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
