Re: Debian-Policy Manual
From: Francesco Tapparo [EMAIL PROTECTED] Of course ae will be used in the boot disks, but in the default installation, joe must be the choiche, IMO. Debian policy for systems 2.0 and above will be to have _no_editor_ as part of the base system. If you want an editor, you must install -- Bruce Perens K6BP [EMAIL PROTECTED] 510-215-3502 Finger [EMAIL PROTECTED] for PGP public key. PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6 1F 89 6A 76 95 24 87 B3 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: FW: [NTSEC] (Fwd) DESCHALL Press Release
I suggest to use [EMAIL PROTECTED] as common identifier for Debian friends. In case we get the money (why should we ?) I suggest to pass 50% to Linux International and keep 50% for Debian. Please use an address at Linux International, not one in the Debian domain. It is not our policy to compete with other Linux distributions. If we are to join this challenge, it should be for all Linux, not for Debian alone. Thanks Bruce -- Bruce Perens K6BP [EMAIL PROTECTED] 510-215-3502 Finger [EMAIL PROTECTED] for PGP public key. PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6 1F 89 6A 76 95 24 87 B3 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Editor wars considered harmful
Francesco Tapparo: Of course ae will be used in the boot disks, but in the default installation, joe must be the choiche, IMO. From: Lars Wirzenius [EMAIL PROTECTED] This is a editor war. Please don't continue it. Don't worry, whether or not he continues it, he will be ignored. There will be no editor in the 2.0 base system except perhaps for ae, and even then ae should only be used for long enough to get a real editor installed from a package. vi was included in the 1.3 base only because there was space for it, not as a policy decision, and I'm not sure that was a good idea. Editors are to be installed from packages. Period. Bruce Perens Debian Project Leader -- Bruce Perens K6BP [EMAIL PROTECTED] 510-215-3502 Finger [EMAIL PROTECTED] for PGP public key. PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6 1F 89 6A 76 95 24 87 B3 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Calendars (was: Re: leap second)
From: [EMAIL PROTECTED] (Kai Henningsen) Not everyone switched in 1752. This is Pope Gregory's calendar reform, isn't it? I think it goes back a century or more before 1752. Actually, it probably was a bad idea to use leap for both. Leap days are fixed by calendar design. Leap seconds are inserted or deleted (both are possible) after comparing the atomic clocks to astronomical observations, with no predictability at all. Two very different animals. Speaking of predictability, isn't 2000 a leap year? The rule is different for the turn of the century. System time should be counted as the number of seconds _elapsed_ since New Year's day 1970 (what Unix uses) or some other fixed point. These days it's the number of seconds elapsed minus the leap seconds, which is sort of silly. Bruce -- Bruce Perens K6BP [EMAIL PROTECTED] 510-215-3502 Finger [EMAIL PROTECTED] for PGP public key. PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6 1F 89 6A 76 95 24 87 B3 -- 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] (Marco Budde) wrote on 21.06.97 in [EMAIL PROTECTED]: But this requires a www server! Not a good idea for slow systems like my notebook. And the result doesn't look great. From: [EMAIL PROTECTED] (Kai Henningsen) Isn't there a mini www server in Perl's web modules Lynx can browse files directly, and can execute CGI scripts directly. Bruce -- Bruce Perens K6BP [EMAIL PROTECTED] 510-215-3502 Finger [EMAIL PROTECTED] for PGP public key. PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6 1F 89 6A 76 95 24 87 B3 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Re^4: Status of Debian Policy
Your're kidding ;-)? There're several really great HTML browsers like netscape, lynx etc. And you should remember that for example KDE will use I don't think he's kidding. Lynx is *awful* for searching (it doesn't even have a keystroke for same pattern, next occurance...) Netscape, well, is netscape :-) Even though I practically *live* in emacs, I'll still pop out to the info program because it's faster at searching, and C-s does the right thing... -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: I found the Xemacs problem!
Ahh. Now that I think about it, I had problems in the early days of 19.34 releases, where it worked fine with some libc's and not with others; it turned out that the best effect was compiling it with a very new libc, then it didn't matter as much what it ran with. (Yeah that sounds fuzzy -- it is, mostly because HJ Lu is, well, *sloppy* when it comes to software engineering. Prolific, but rather sloppy. I'm hoping libc6 is of higher quality...) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: FW: [NTSEC] (Fwd) DESCHALL Press Release
I suggest to use [EMAIL PROTECTED] as common identifier for Debian friends. In case we get the money (why should we ?) I suggest to pass 50% to Linux International and keep 50% for Debian. Please use an address at Linux International, not one in the Debian domain. It is not our policy to compete with other Linux distributions. If we are to join this challenge, it should be for all Linux, not for Debian alone. Thanks Bruce That's silly, Bruce... I get the impression that you've been hoodwinked into thinking there is an official Linux team - there ain't - there's a linuxnet.org team, organized by those IRC guys. The odds of winning any of these contests (even with a strong team) is something like 1 in 10,000 - so the objective isn't to win - it's just to compete. Your argument is sort of like saying we shouldn't buy a lottery ticket and write Debian on it, because someone else bought a lottery ticket and wrote Linux on it - and they might be offended if we won. Having teams makes it a bit more fun. Having 1 team (ie. a Linux team) sort of kills the competition aspect of it all. So I'm still in favour of using the [EMAIL PROTECTED] address, even though that address is just an auto-responder. Once I get my experimental dwww release out (hopefully tomorrow), I'll package up an rc5-bovine package to replace the des-solnet package. Cheers, - Jim pgpj8KA8GlAA8.pgp Description: PGP signature
Re: xterm terminfo entry
Except that the xterm-color entry isn't particularly widespread, yet; so if you rlogin or telnet somewhere that doesn't have it, you pretty much lose. This is the main reason I'm reluctant to force the change... though I might be convinced to do it for the unstable (with libc6 and all the other experimental funstuff) X release if it's likely to be more widespread in the future... -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: FW: [NTSEC] (Fwd) DESCHALL Press Release
From: Jim Pick [EMAIL PROTECTED] I get the impression that you've been hoodwinked into thinking there is an official Linux team - there ain't - there's a linuxnet.org team, organized by those IRC guys. Last time, a good many different Linux interests were competing as linuxnet.org, and we were off by ourselves for no reason I could understand. People did complain that we were promoting Debian to the detriment of Linux. Thanks Bruce -- Bruce Perens K6BP [EMAIL PROTECTED] 510-215-3502 Finger [EMAIL PROTECTED] for PGP public key. PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6 1F 89 6A 76 95 24 87 B3 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re^4: Status of Debian Policy
On Jun 22, Mark Eichin wrote I don't think he's kidding. Lynx is *awful* for searching (it doesn't even have a keystroke for same pattern, next occurance...) Eh? 'n' seems to do a pretty good job. Seems like it searches just fine to me :-) Chris -- |Chris Lawrence| My home page: | |[EMAIL PROTECTED]| http://www.clark.net/pub/lawrencc/| | | | | Amiga A4000/040 and |Are you tired of politics as usual?| | Linux/m68k 2.1.29 | http://www.lp.org/| -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: FW: [NTSEC] (Fwd) DESCHALL Press Release
People did complain that we were promoting Debian to the detriment of Linux. Yes - but remember, some of the people participating in these contests were acting pretty infantile. Instead of focusing on solving the problem, they want their team to be at the top of the list at all costs, including 'spamming' the servers to increase their odds. The people who wrote to you complaining about the fact that there was a [EMAIL PROTECTED] team were just trying to get people to join their team - so they could get some more nerd glory or something. I'm surprised that you've taken them so seriously, and that you think they even reflect the sentiments of even a fraction of the Linux community. This is such a small thing -- nobody cares. If you were to take a poll of Linux people about this, they'd overwhelmingly vote for 'go away, I don't care'. BTW, in case you didn't notice - we do compete with the other Linux distributions every day -- for the honour of having our system installed on users computers. But, I do agree that we shouldn't be competing against the wishes of the Linux community at large. In summary: Why the hell do we have to be so damn politically correct? I'm mostly in this for fun. :-) Cheers, - Jim pgp36FYtOOWOR.pgp Description: PGP signature
Re: FW: [NTSEC] (Fwd) DESCHALL Press Release
Jim Pick wrote: People did complain that we were promoting Debian to the detriment of Linux. Yes - but remember, some of the people participating in these contests were acting pretty infantile. Instead of focusing on solving the problem, they want their team to be at the top of the list at all costs, including 'spamming' the servers to increase their odds. The people who wrote to you complaining about the fact that there was a [EMAIL PROTECTED] team were just trying to get people to join their team - so they could get some more nerd glory or something. I'm surprised that you've taken them so seriously, and that you think they even reflect the sentiments of even a fraction of the Linux community. This is such a small thing -- nobody cares. If you were to take a poll of Linux people about this, they'd overwhelmingly vote for 'go away, I don't care'. BTW, in case you didn't notice - we do compete with the other Linux distributions every day -- for the honour of having our system installed on users computers. But, I do agree that we shouldn't be competing against the wishes of the Linux community at large. In summary: Why the hell do we have to be so damn politically correct? I'm mostly in this for fun. :-) Cheers, - Jim I have some computers up running in that challenge and I could easily contribute there output to the debian group, if we are going to have one. So will we have one, or will we do it each one by himself? May the source be with you. Mrvn -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: FW: [NTSEC] (Fwd) DESCHALL Press Release
I have some computers up running in that challenge and I could easily contribute there output to the debian group, if we are going to have one. So will we have one, or will we do it each one by himself? It's up to you - nobody's really organized anything. Some people are already running for [EMAIL PROTECTED] It's sort of fun watching the team stats move up the chart if the team is large enough. As I understand it, the Bovine RC5 challenge is just a continuation of the zero.genx.net effort that was discontinued earlier (same clients, different servers). I'll probably release the rc5-bovine package with a default for the [EMAIL PROTECTED] team, but that can be easily changed (just like the previous des-solnet package). I know that this is against Bruce's wishes - but hey, it's not like we're organizing a mutiny or anything (although Bruce seemed to take it that way last time). :-) Cheers, - Jim pgpPzqjWq0teT.pgp Description: PGP signature
Re: xterm terminfo entry
On Jun 22, Mark Eichin wrote Except that the xterm-color entry isn't particularly widespread, yet; so if you rlogin or telnet somewhere that doesn't have it, you pretty much lose. termcap supported the TERMCAP environmental variable, which solved problems like this (and like linux not being supported on Solaris). ncurses, near as I can tell, doesn't support anything like this. Maybe we could put together a portable (tar + sh based) solution that supports both termcap and ncurses on arbitrary unix systems? -- Raul -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Documentation Policy
/usr/info/emacs-info. I suggest to split this off into a new package called emacs-doc-info. In addition, we should create an emacs-doc-html Interesting. Not really an option, though; as far as emacs is concerned, that's part of how it documents itself. If you come up with a way that works as well as m-x info for use *within emacs* (and no, w3-mode *doesn't* cut it, especially for new users -- info has self-training support builtin...) This html/info split may make sense for other packages (I'm unconvinced) but it does *not* make sense for emacs in particular. _Mark_ [EMAIL PROTECTED] The Herd of Kittens Debian Emacs Maintainer -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Calendars (was: Re: leap second)
In [EMAIL PROTECTED] [EMAIL PROTECTED] (joost witteveen) writes: Now, we know the length of a year/day better, and only 1 in for of those turn-of-century years are leap years. Maybe that will change again. And about the seconds: we (currently, prossibly always) simply cannot calulate the length of a day accurately enough to know well in advance when to insert them. But I'd say the two animals are at least related, if not mother and daughter. It is my understanding that: Leap days are used to keep the calendar in sync with the season. That is, you don't want winter to be in August (in the northern hemisphere.) Leap seconds are used to keep the time of day in sync with the sun rise. That is, you don't want the sun to be rising at midnight (out side the article circles.) The length of the year is almost constant over time periods of thousands of years. It does vary due to gravitational interactions with other planets, but it only makes a significant difference (10%?) when dealing with time periods of around 100,000 years. These gravitational interactions are predictable, so if you really wanted to, you can calculate the exact length of the year 1million years ago. (It is my understanding that there are people who do this.) The length of the day is not quite as constant. It depends on how quickly the earth rotates which depends on things like how much snow has fallen on mountain peaks and how much water is in man made reservoirs. I kid you not, these things are significant enough to change things on the order of a second or two per year. Neither the weather nor people's water usage/reservoir building is very predictable. This makes predicting leap seconds futile. -wayne -- Wayne Schlitt can not assert the truth of all statements in this article and still be consistent. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: xterm terminfo entry
in practice, the linux entry not being supported by solaris (for example) was handled by people doing set term=vt100 and whining a lot... -- 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: Experiences with compiling Debian
On Jun 22, Lars Wirzenius wrote
The following sequence of commands:
dpkg-source -x foo.dsc
cd foo-something
dpkg-buildpackage -b -rsudo -us -uc
i switched to use debian/rules binary, debian/rules clean and
dpkg-genchanges in my script (why should dpkg-buildpackage call clean or
generate a diff or dsc file (that is turned of with -us -us i suppose) ?).
If there is an error, the build will stop, but there is too much output
to easily see all warnings and some minor errors that don't stop the
build.
yes. but i don't know, what we can do here ? with normal compiling,
every gcc call creates a line of output. and if the package is sed-ing
some files, creating html/info/whatever documentation, we get a lot of
output.
I doubt that the speed of the net connection is important, as long
as you can transfer everything to your machine. The actual build
can and must be automated.
that's not a problem. currently i scan one directory for new *.dsc
files, and build them (if they are not already in the list of *dsc files
proceded). i could change that to work with an source/ mirror of debian
packages (changing ${Incoming}/*.dsc to ${Incoming}/*/*.dsc :-).
About 480 packages built properly, and about 200 had problems.
Some packages had problems because they needed -dev versions
of libraries I had neglected to install. I didn't post the
full list because I hadn't investigated everything, and didn't
want to point fingers.
hey, 480 packages built properly is still a good goal.
do you have log files of the other packages ? maybe a team could look at
them. most other packages will not need much work, i think.
regards, andreas
--
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
On Jun 22, Alex Yukhimets wrote What's that problem with No new line thing? Who's creating this problem - diff, patch, dpkg-source? can you please download the newest version of patch, and try again ? this way we can get sure, if it's fiext with a new version of patch (some people told me that), or not. afaik, a new patch should fix it. regards, andreas -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Copyright question
Hi! I've got a copyright question. The selfhtml (doc section) package, that I'll release the next days, has got a copyright that forbid changing the files. Should I put the package in unstable/stable or in non-free? In my opinion the package should go to unstable/stable because it's not necessary to change something in a documentation only package. Any comments? Copyright = Dieses Dokument ist Freeware im Sinne des Software-Lizenzrechts. Die Regeln im einzelnen: * Das Kopieren und Weitergeben des Dokuments ist erlaubt. * Das Veroeffentlichen auf WWW-Servern, Online-Diensten oder Mailboxen ist erlaubt. * Das Veroeffentlichen auf Datentraegern wie CD-ROMs ist erlaubt, auch wenn diese Datentraeger kommerziell orientiert sind. * Das Aendern des Dokuments ist nicht erlaubt. Das gilt sowohl fuer den Inhalt als auch fuer das Dateiformat bzw. die Gestaltung. Auch das Entfernen unliebsamer Passagen ist nicht erlaubt. * Das Dokument muss stets in der vorliegenden Form und vollstaendig kopiert, weitergegeben oder anderweitig veroefftentlicht werden - das Kopieren, Weitergeben oder Veroeffentlichen von Teilen des Dokuments ist nicht erlaubt. Massgeblich hierfuer ist die Download-Datei. * Das Veroeffentlichen des Dokuments auf WWW-Servern oder Datentraegern im Zusammenhang mit illegalem pornografischem Material oder nazistischem Gedankengut ist unerwuenscht und wird bei Entdeckung juristisch verfolgt. Wenn Sie dieses Dokument an einer neuen Stelle im WWW plazieren oder an anderer Stelle publizieren wollen, besorgen Sie sich das Dokument an einer der Stellen zum Downloaden. Da das Dokument bereits an so vielen Adressen im WWW steht, uebernimmt der Autor hierfuer keine Betreuung. Bei Veroeffentlichung auf CD-ROM oder vergleichbaren Datentraegern ist es eine feine Geste, dem Autor ein Belegexemplar zukommen zu lassen. Senden Sie dieses per Post an TeamOne, z.Hd. Stefan Muenz, Kistlerhofstr. 111, D-81379 Muenchen. cu, Marco -- Uni: [EMAIL PROTECTED] Fido: 2:240/5202.15 Mailbox: [EMAIL PROTECTED]http://www.tu-harburg.de/~semb2204/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Calendars (was: Re: leap second)
On Jun 22, Bruce Perens wrote Speaking of predictability, isn't 2000 a leap year? The rule is different for the turn of the century. 2000/02/29 exists. (the rule is : every for years, but not every hundred years, but every 400 years). AFAIK. regards, andreas -- 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
On Jun 23, Lars Wirzenius wrote I only listed some problematic packages (not even all problematic packages). That wasn't meant to be a complete report, just some notes. Someone with more free time will have to take charge of this if it is going to happen systematically. what about forwarding the logfiles to the maintainer, if something goes wrong, or reporting it as bug ? regards, andreas -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Uploaded ppp 2.2.0f-26 (source i386) to master
Hi, Since discussing this in private resulted in me doing something stupid, I'll Cc: this to the list (all comments welcome). [EMAIL PROTECTED] said: pppd is not just a dialout tool but also used to allow dialin. The group dip has been designed for that purpose (dialup ip). A user might be a member of the dip group and thus allowed dialin access but he is not allowed to initiate an outgoing connection and thus not a member of dialout. That scheme will not work anymore with your setup. I agree with this. [ Erik, you said that the documentation refers to dialout, rather than dip. Please submit a bug report. ] In the mean time 2.2.0f-27 will be the same thing as 2.2.0f-25 (i.e. with pppd belonging to dip), unless someone comes up with a good reason for this not being the case. I would also suggest to disable IPX by default. Dialin users could be surprised to have access to corporate LAN resources. Negotiation with a Win95 client gets much more complex with IPX enabled. Similar issues are valid for dialout. It is customary to expect TCP/IP connectivity from Unix boxes but Novell Networking is something optional not regular. Absolutely --- The default /etc/ppp/options file disables IPX. Are you saying that this is not enough, and the user should have to recompile pppd to get the IPX functionality? How about if I make the default for IPX to be off in the executable ? I think that people should be able to do this easily if they want, since it means that Debian can do everything that NT RAS can do. Cheers, Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Re^4: Status of Debian Policy
On Jun 22, Chris Lawrence wrote On Jun 22, Mark Eichin wrote I don't think he's kidding. Lynx is *awful* for searching (it doesn't even have a keystroke for same pattern, next occurance...) Eh? 'n' seems to do a pretty good job. Seems like it searches just fine to me :-) 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). -- Riardas epas -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
RE: GCC cross-compilation
Does this mean I could upload all architecture version for my packages? If so yes, I think it's useful. Michael -- Dr. Michael Meskes, Projekt-Manager| topsystem Systemhaus GmbH [EMAIL PROTECTED]| Europark A2, Adenauerstr. 20 [EMAIL PROTECTED] | 52146 Wuerselen Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44 Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10 -Original Message- From: Galen Hazelwood [SMTP:[EMAIL PROTECTED] Sent: Sunday, June 22, 1997 8:41 PM To:Hamish Moffatt Cc:Die Adresse des Empfängers ist unbekannt. Subject: Re: GCC cross-compilation Hamish Moffatt wrote: It occurred to me that since most of the Debian packages are also available for m68k and also Sparc and Alpha now, the develops are probably using cross-compilation, rather than actually owning all these machines. Nope. What happens is most (single-cpu) developers upload the source and binaries for one architecture. Then helpful and nice developers who own other machines upload binaries for their cpu, built from the source. Is there a package for eg the m68k cross compiler? I couldn't find one with the package search on www.debian.org. I don't think so. At least, not one I built. Thinking about it, it would seem possible to have a gcc-core package which would include the gcc binary itself for [snip] There really isn't a core gcc package, just the native version. gcc cross compilers wouldn't need any other gcc packages to be useful. Is this plausible and/or useful? Plausible. Would anybody else consider this useful? --Galen -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] . -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
svgalib-dummy again
Now that svgalib seems orphaned, allow me to come up with this topic again... But first a brief summary of the history and the problems: svgalib-dummy is a dummy replacement for svgalib, which doesn't require any configuration, doesn't spit out messages when initialized by applications, and last but not least, can be used as a substitute on architectures where the real svgalib doesn't exist. Unfortunately, it cannot be easily installed. Though it Conflicts: and Replaces: svgalib1, dpkg's current dependency mechanism doesn't allow it to be a substitute for svgalib, because that is a shared lib and so all dependencies on it are versioned dependencies (coming from the .shlibs file). I now see two solution for this problem: 1) dpkg's dependency handling could be extended so that it knows about versioned Provides:. Then svgalib-dummy could provide svgalib1 (= 1:1.2.10-2) or something similar, and a dependency svgalib1 (= 1:1.2.10-1) could be satisfied by this. Not only that this is the most elegant way, it also solves another potential problem: The problem with versioned dependencies doesn't only hit svgalib-dummy, which wants to replace a shared lib, it will also effectively make replacements of any shlib package impossible... Just imagine we sometime want to rename a shared lib, or replace it by another, improved package. This won't be possible without rebuilding the *depending* packages, because providing a shared lib isn't possible... 2) A not-so-nice solution would be to change the .shlibs files of both, svgalib and svgalib-dummy, so that they read libvga1 svgalib1 (= 1:1.2.10-4) | svgalib-dummy1 libvgagl 1 svgalib1 (= 1:1.2.10-4) | svgalib-dummy1 This signals that either package is ok for providing libvga.so. The drawback is that all packages depending on svgalib must be rebuilt with an updated version of svgalib to get in this change. This could be handled by first announcing here that those packages should be rebuilt, and if no uploads follow in some reasonable amout of time, I could report bugs against those packages. So, what method do you prefer? Or do you have better ideas? How hard would it be to implement versioned Provides: in dpkg? Or are there other reasons not to implement it? Is solution 2) too kludgy? Roman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
RE: Copyright question
The way I read it the copyright just forbids to change the doc files itself. There is no problem adding our packages files etc. Even renaming the source tree is not forbidden. So I'd say put it in the core distribution. Michael -- Dr. Michael Meskes, Projekt-Manager| topsystem Systemhaus GmbH [EMAIL PROTECTED]| Europark A2, Adenauerstr. 20 [EMAIL PROTECTED] | 52146 Wuerselen Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44 Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10 -Original Message- From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED] Sent: Monday, June 23, 1997 8:25 AM To:debian-devel@lists.debian.org Cc:Die Adresse des Empfängers ist unbekannt. Subject: Copyright question Hi! I've got a copyright question. The selfhtml (doc section) package, that I'll release the next days, has got a copyright that forbid changing the files. Should I put the package in unstable/stable or in non-free? In my opinion the package should go to unstable/stable because it's not necessary to change something in a documentation only package. Any comments? Copyright = Dieses Dokument ist Freeware im Sinne des Software-Lizenzrechts. Die Regeln im einzelnen: * Das Kopieren und Weitergeben des Dokuments ist erlaubt. * Das Veroeffentlichen auf WWW-Servern, Online-Diensten oder Mailboxen ist erlaubt. * Das Veroeffentlichen auf Datentraegern wie CD-ROMs ist erlaubt, auch wenn diese Datentraeger kommerziell orientiert sind. * Das Aendern des Dokuments ist nicht erlaubt. Das gilt sowohl fuer den Inhalt als auch fuer das Dateiformat bzw. die Gestaltung. Auch das Entfernen unliebsamer Passagen ist nicht erlaubt. * Das Dokument muss stets in der vorliegenden Form und vollstaendig kopiert, weitergegeben oder anderweitig veroefftentlicht werden - das Kopieren, Weitergeben oder Veroeffentlichen von Teilen des Dokuments ist nicht erlaubt. Massgeblich hierfuer ist die Download-Datei. * Das Veroeffentlichen des Dokuments auf WWW-Servern oder Datentraegern im Zusammenhang mit illegalem pornografischem Material oder nazistischem Gedankengut ist unerwuenscht und wird bei Entdeckung juristisch verfolgt. Wenn Sie dieses Dokument an einer neuen Stelle im WWW plazieren oder an anderer Stelle publizieren wollen, besorgen Sie sich das Dokument an einer der Stellen zum Downloaden. Da das Dokument bereits an so vielen Adressen im WWW steht, uebernimmt der Autor hierfuer keine Betreuung. Bei Veroeffentlichung auf CD-ROM oder vergleichbaren Datentraegern ist es eine feine Geste, dem Autor ein Belegexemplar zukommen zu lassen. Senden Sie dieses per Post an TeamOne, z.Hd. Stefan Muenz, Kistlerhofstr. 111, D-81379 Muenchen. cu, Marco -- Uni: [EMAIL PROTECTED] Fido: 2:240/5202.15 Mailbox: [EMAIL PROTECTED]http://www.tu-harburg.de/~semb2204/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] . -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Correct path for upgrading to libc6-dev?
On Jun 21, Mark Baker wrote For libg++, I'd wait until there's a libg++272 package, and install the development stuff from that; for ncurses there are libc6 versions of the library itself, I'm not sure about the development stuff but a force-depends seems to work (the header files aren't changed). I don't know about slang. I uploaded S-lang last week: libc5 compatibility: ii slang0.99.340.99.38-2.4backward compatibility shared library for li ii slang0.99.34-de 0.99.38-2.4S-Lang libc5 backward compatibility developm libc6 versions: ii slang0.99.380.99.38-2.4The S-Lang programming library, shared libra ii slang0.99.38-de 0.99.38-2.4The S-Lang programming library, development Ray -- LEADERSHIP A form of self-preservation exhibited by people with auto- destructive imaginations in order to ensure that when it comes to the crunch it'll be someone else's bones which go crack and not their own. - The Hipcrime Vocab by Chad C. Mulligan -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: GCC cross-compilation
Does this mean I could upload all architecture version for my packages? If so yes, I think it's useful. But if you do that, you haven't tested whether your package is really running on another architecture... Roman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: svgalib-dummy again
Now that svgalib seems orphaned, allow me to come up with this topic
again... But first a brief summary of the history and the problems:
Well, nearly orphaned. I finally got an answer from Andy Mortimer
[EMAIL PROTECTED], who currently is the one interested in
being the maintainer. I did this as I wanted to make a non-maintainer
release of svgalib for libc6 (and Andy gave his OK for me to do so,
planned to release svgalib1g tonight, or tomorrow).
svgalib-dummy is a dummy replacement for svgalib
[..]
dpkg's current dependency mechanism doesn't allow it to be a
substitute for svgalib, because that is a shared lib and so all
dependencies on it are versioned dependencies (coming from the .shlibs
file).
Well, more to the point: when package foo Depends on a particular version
of package bar, dpkg ignores all packages that provides: bar.
(It'll only look at the exact package bar, and it's version).
I now see two solution for this problem:
1) dpkg's dependency handling could be extended so that it knows
about versioned Provides:. Then svgalib-dummy could provide
svgalib1 (= 1:1.2.10-2) or something similar, and a dependency
svgalib1 (= 1:1.2.10-1) could be satisfied by this.
Not only that this is the most elegant way, it also solves another
potential problem:
The problem with versioned dependencies doesn't only hit
svgalib-dummy, which wants to replace a shared lib, it will also
effectively make replacements of any shlib package impossible...
Well, it isn't the library stuff that goes wrong, it's the specific versions
that cause dpkg to ignore the Provides: packages.
Just imagine we sometime want to rename a shared lib, or replace
it by another, improved package. This won't be possible without
rebuilding the *depending* packages, because providing a shared
lib isn't possible...
Only if the *dpending* packages depends: on a particular version of the
shared lib package. Usually, this isn't the case (the soname of the
library is encoded in the package name, so a package could just depends:
libfoo272, with 272 the soname of libfoo. But yes, with the current
shlibs files, they will always depend on a particular version of the
library, and it will always go wrong.
2) A not-so-nice solution would be to change the .shlibs files of
both, svgalib and svgalib-dummy, so that they read
libvga1 svgalib1 (= 1:1.2.10-4) | svgalib-dummy1
libvgagl 1 svgalib1 (= 1:1.2.10-4) | svgalib-dummy1
Well, this at least woudn't hurt, I guess. Unless anyone objects against
this, I'll add this to the svgalib1g I'll upload tonight/tomorrow.
The drawback is that all packages depending on svgalib must be
rebuilt with an updated version of svgalib to get in this change.
They have to be rebuilt for libc6 anyway. So that's no problem.
This could be handled by first announcing here that those packages
should be rebuilt, and if no uploads follow in some reasonable
amout of time, I could report bugs against those packages.
Well, don't bother. Other people are already planning to do something
similar with old libc5 packages, you'd just be repeating them.
So, what method do you prefer? Or do you have better ideas? How hard
would it be to implement versioned Provides: in dpkg? Or are there
other reasons not to implement it? Is solution 2) too kludgy?
I strongly prefer method 1. I really think dpkg should be improved,
but as that doesn't seem to happen any time soon, I don't think
method 2 will hurt in the mean time. Anyone else see any problems
with method 2?
--
joost witteveen, [EMAIL PROTECTED]
#!/usr/bin/perl -sp0777iX+d*lMLa^*lN%0]dsXx++lMlN/dsM0j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$kSK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
#what's this? see http://www.dcs.ex.ac.uk/~aba/rsa/
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: svgalib-dummy again
dpkg's current dependency mechanism doesn't allow it to be a substitute for svgalib, because that is a shared lib and so all dependencies on it are versioned dependencies (coming from the .shlibs file). Well, more to the point: when package foo Depends on a particular version of package bar, dpkg ignores all packages that provides: bar. (It'll only look at the exact package bar, and it's version). Clear. What I meant with because it's a shared lib is that usually all dependencies on a shlib are versioned dependencies, because they come from the .shlibs file. Well, it isn't the library stuff that goes wrong, it's the specific versions that cause dpkg to ignore the Provides: packages. That's what I'm saying, isn't it? Only if the *dpending* packages depends: on a particular version of the shared lib package. Usually, this isn't the case (the soname of the library is encoded in the package name, so a package could just depends: libfoo272, with 272 the soname of libfoo. But yes, with the current shlibs files, they will always depend on a particular version of the library, and it will always go wrong. Yup, that's it. AFAICR, the (= x.y.z) there has been introduced to avoid that people use too-old shlibs at runtime, which is basically a good thing. Well, this at least woudn't hurt, I guess. Unless anyone objects against this, I'll add this to the svgalib1g I'll upload tonight/tomorrow. That would be fine! Would at least fix the problem for packages that are recompiled with the new glibc version of svgalib. They have to be rebuilt for libc6 anyway. So that's no problem. You're right here. I strongly prefer method 1. I really think dpkg should be improved, Me too... but as that doesn't seem to happen any time soon, I don't think method 2 will hurt in the mean time. Ok. Any other opinions? Roman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: FW: [NTSEC] (Fwd) DESCHALL Press Release
Jim Pick [EMAIL PROTECTED] writes: I suggest to use [EMAIL PROTECTED] as common identifier for Debian friends. In case we get the money (why should we ?) I suggest to pass 50% to Linux International and keep 50% for Debian. Please use an address at Linux International, not one in the Debian domain. It is not our policy to compete with other Linux distributions. If we are to join this challenge, it should be for all Linux, not for Debian alone. I get the impression that you've been hoodwinked into thinking there is an official Linux team - there ain't - there's a linuxnet.org team, organized by those IRC guys. The odds of winning any of these contests (even with a strong team) is something like 1 in 10,000 - so the objective isn't to win - it's just to compete. IMHO the primary objective is public visibility. It's about the size of Debian's user base and how many people identify themselves with Debian in some way. In the Sollentuna effort about 2% of the blocks were processed by [EMAIL PROTECTED], so the chance is a bit better than 1 in 10,000. But we are talking about only 1000$, and money isn't the primary thing here. If someone wants to contribute money to Debian, participating in such a cracking effort is no economic way. So I'm still in favour of using the [EMAIL PROTECTED] address, even though that address is just an auto-responder. An [EMAIL PROTECTED] address or even a mailing list, but this needs official blessing, and from Bruce's comments I deduce that this won't happen soon. So for now use [EMAIL PROTECTED] Sven -- Sven Rudolph [EMAIL PROTECTED] ; WWW : http://www.sax.de/~sr1/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: FW: [NTSEC] (Fwd) DESCHALL Press Release
Bruce Perens [EMAIL PROTECTED] writes: I suggest to use [EMAIL PROTECTED] as common identifier for Debian friends. In case we get the money (why should we ?) I suggest to pass 50% to Linux International and keep 50% for Debian. Please use an address at Linux International, not one in the Debian domain. I am not aware of a Linux International address in the RC5 cracking effort. It is not our policy to compete with other Linux distributions. Nor have I seen another distribution there. If we are to join this challenge, it should be for all Linux, not for Debian alone. I disagree. Neither are we making a Linux distribution against all Linux, nor are we competing in the RC5 challange against all Linux. For details see my other message. Sven -- Sven Rudolph [EMAIL PROTECTED] ; WWW : http://www.sax.de/~sr1/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Use of suidmanager
Could anyone please tell me the advantages of suidmanager as it is right now? I can see the usefullness of a tool like that, but I wonder if there should be a daily test run to make sure no other file are suid. Or is this dones elsewhere? Also why are there file in /etc/suid.conf that are not suid at all: debmake /usr/bin/build root root 755 debmake /usr/bin/debpkg root root 755 I'd like to know more about this (and other) security related packages. Michael -- Dr. Michael Meskes, Projekt-Manager| topsystem Systemhaus GmbH [EMAIL PROTECTED]| Europark A2, Adenauerstr. 20 [EMAIL PROTECTED] | 52146 Wuerselen Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44 Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: problems with debmake
On Jun 22, Dirk Eddelbuettel wrote Francesco, Did you add your userid to the sudo group? [EMAIL PROTECTED]:~ grep sudo /etc/group sudo:*:27:edd Regards, Dirk Yes, I made it. ciao Francesco Tapparo [EMAIL PROTECTED] -- 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)
Lars Wirzenius wrote: [replying to the list instead of privately, since this is of common interest, IMHO :-] If the protocol in the publib library has a way to get around that problem, I'd be interesting in learning more about it (and, possibly, dreaming up cases in which it might fail :-) I don't know if it does, but it tries. Please do find any problems. Here's the code: [...] fndir(dir, lockname); fnjoin(tempname, dir, .temp-lock); fd = open(tempname, O_CREAT | O_EXCL, 0600); if (fd == -1) return -1; This can create a lockfile that is never deleted. Consider the following case: Client code does open(tempname, O_CREAT | O_EXCL, 0600); Client kernel translates this into a NFSPROC_CREATE RPC call and sends it out on the wire as a UDP packet. Server receives the RPC call and executes it via doing an open(tempname, O_CREAT | O_EXCL, 0600) itself; the lockfile is created. Server sends back the the acknowledgement of success via a UDP package. UDP package is lost on the wire. Client kernel receives no confirmation and re-transmits the NFSPROC_CREATE request. Server receives RPC call and does open(tempname, O_CREAT | O_EXCL, 0600); This call fails; server transmits back indication of failure. Client user-space code sees call to open(tempname, O_CREAT | O_EXCL, 0600) fail and thinks that somebody else has already locked things. Result: oops... There is a - partial - way around this. Each RPC call is accompanied with a unique 32-bit number, the xid. A server can cache the first request and simply send back a done successfully if it sees the same (hostname,xid) tuple again within a certain time. However, there is no guarantee in the NFS protocol that this is indeed being done (and I don't know wether the current Linux nfsd does indeed follow that strategy). This will also not survive a server crash, and there is no way to enquire wether the server does support xid caching. -- Thomas Koenig, [EMAIL PROTECTED], [EMAIL PROTECTED] The joy of engineering is to find a straight line on a double logarithmic diagram. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: [klee@mit.edu: Bug#10795: makefiles for nethack are i386-specific]
Paul Haggart [EMAIL PROTECTED] writes: Okay, what's the recommended solution for this .. other than porting nethack over to use libc6 (which can't be done at the moment because of the lack of a libc6 xpm library). How does one detect the architecture of the machine being used? Cut and pasted from bash_2.01-0's debian/rules, but enough to get the idea? :- ARCH = $(shell dpkg --print-gnu-build-architecture) make [ ... ] CC=$(ARCH)-linuxlibc1-gcc [ ... ] -- James -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
libreadlineg2 missing
How on earth is it possible to get packages depending on libreadlineg2 into hamm when there is no package libreadlineg2 in the archive or in Incoming? At least I couldn't find the readline package. Michael -- Dr. Michael Meskes, Projekt-Manager| topsystem Systemhaus GmbH [EMAIL PROTECTED]| Europark A2, Adenauerstr. 20 [EMAIL PROTECTED] | 52146 Wuerselen Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44 Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10 -- 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
On Jun 22, Bruce Perens wrote Lynx can browse files directly, and can execute CGI scripts directly. True. However, it can't handle gzipped pages, and hacking it to do so seems a) special case (because chimera, w3, netscape and all the others still don't) and b) outside of its domain of relevance. As well, it (rightly) looks for references of the form `foo/bar.html', when it would have to look for `foo/bar.html.gz' and do the unzipping. In contrast, info browsers have been handling compressed files for what feels like eternity to this young'un ;-). You can configure a web server (almost any web server, if I remember correctly) to dynamically unzip the pages as they come down the line, however, and this seems more in line with what one expects a web server to do. If HTML is to be used in any form, a minimal web server would also be important, if only for this aspect. As far as *which* window manager, this is something else entirely. WN is nice, but requires slightly nonstandard update files, and Apache is occasionally too big but certainly capable (although I have never really understood this, having run it on every Linux machine since my 386SX). Boa might be a possibility, if it could be told how to transfer gzipped files; I have positive experiences with it, but I don't know whether this is something it can do by default. -- Graham Hughes [EMAIL PROTECTED] MIME PGP mail OK. (define pgp-fingerprint E9 B7 5F A0 F8 88 9E 1E 7C 62 D9 88 E1 03 29 5B) (require 'stddisclaim) pgpep7SyrXiZA.pgp Description: PGP signature
Re: libreadlineg2 missing
Michael Meskes [EMAIL PROTECTED] writes: How on earth is it possible to get packages depending on libreadlineg2 into hamm when there is no package libreadlineg2 in the archive or in Incoming? I removed libreadlineg2 and all other bash_2.01-0 related files from Incoming/ after they appeared to trash Christian Hudon's computer. I still don't know why, and am waiting on him to test something for me. At the moment I'm between the devil and the deep blue sea, I don't want to install a package which could trash people's computers into the distribution, but if I don't there are two packages with unsatisfied dependencies. At least I couldn't find the readline package. It's in ~troup/ on master for now. Caveat; Use at your own risk, the package worked fine for me and someone else but not for Christian. -- James -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
RE: Anyone using transparent proxying?
Do you really run it? The way I hear it from the authors (and according to my own experience) it won't work with 2.0.30 either. It's broken and these guys don't know yet, how to repair it. The last working version was 2.0.29. Michael -- Dr. Michael Meskes, Projekt-Manager| topsystem Systemhaus GmbH [EMAIL PROTECTED]| Europark A2, Adenauerstr. 20 [EMAIL PROTECTED] | 52146 Wuerselen Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44 Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10 -Original Message- From: Nils Rennebarth [SMTP:[EMAIL PROTECTED] Sent: Sunday, June 22, 1997 11:03 AM To:Michael Meskes Cc:Die Adresse des Empfängers ist unbekannt. Subject: Re: Anyone using transparent proxying? -BEGIN PGP SIGNED MESSAGE- On Fri, 13 Jun 1997, Michael Meskes wrote: The title almost says it all. I just upgraded to pre-patch-2.0.31-2, but it seems transparent proxying still doesn't work. My first rule says: acc/r tcp anywhere anywhere any - www = tproxy I run 2.0.30, my rules (to test masquerading a single client machine only) are: ipfwadm -I -a accept -P tcp -S dino.nus.de -D 0.0.0.0/0 80 -r 81 (Transparent proxy broken in pre 2.0.31?) Nils - -- \ /| Nils Rennebarth --* WINDOWS 42 *-- | Schillerstr. 61 / \| 37083 Göttingen | ++49-551-71626 Micro$oft's final answer | http://www.nus.de/~nils -BEGIN PGP SIGNATURE- Version: 2.6.3i Charset: noconv iQB1AwUBM6zqTFptA0IhBm0NAQGCIAL9EUxRE0fNQa1xBhmjNzy2pBuoG8MmCv9H ZGjH3AbQpDmf2lgc3MJuSUf/pyFZUEvKbzZJmD9v7Q/6fOfnLHbDu9++6/Bu76hs ybMMyFzPQ980Xt83F/kk0RDvEfqsJ2SN =m6JV -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] . -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Dpkg in C for speed?
Greetings! Well, what do you think? -- [EMAIL PROTECTED] Camm Maguire == The earth is one country, and mankind its citizens. Baha'u'llah -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Dpkg in C for speed?
dpkg in C for speed?
Greetings! Well, what do you think?
well, I think it will not make a difference. It's not slow because
of C++, it's slow because it has to read thousands of files
on startup, and do quite a lot of other interesting things. All
this has nothing to do with C/C++.
--
joost witteveen, [EMAIL PROTECTED]
#!/usr/bin/perl -sp0777iX+d*lMLa^*lN%0]dsXx++lMlN/dsM0j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$kSK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
#what's this? see http://www.dcs.ex.ac.uk/~aba/rsa/
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Documentation Policy
I like this proposal too. Yet another reason, why separate docs could be good: Sometimes I want only to check documentation, read more about something (e.g. some toolkit and/or programming language) and I don't want to install 20 MB package when I need only 1 MB documentation which I want to read at evenings. Problems with increasing number of packages is a problem of user interface, nothing more. And I think creating doc packages is the only simple (i.e. possible to have in reasonable time) solution we have now. Milan Zamazal -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Re^4: Status of Debian Policy
MB == Marco Budde [EMAIL PROTECTED] writes: MZ: I don't know any good browser for HTML, that's the main MZ: problem of HTML documentation. MB: Your're kidding ;-)? There're several really great HTML MB: browsers like netscape, lynx etc. No. Problems with netscape: - It's non-free. - It's buggy. - It's big. - It can't run on text console. - It has only very limited searching and navigation facilities. (Netscape is crippelware IMHO.) Problems with HTML/lynx for any user: - Limited possibilities of handling gzip files (typing xxx.html doesn't find xxx.html.gz) = problems with links (may be solvable by CGI skript = overhead on my notebook with only 8~MB RAM). - Limited searching facilities (general problem of HTML). - No indices, quick menu selection (see Emacs info documentation). - No highlighting/coloring? (I'm not sure.) Problems with HTML/lynx for Emacs users (they're many I think, so don't forget them, please): - How to do cut past easily. - Incompatible key bindings. - No direct access to documentation (like word-help). - Yet another window/console. (w3-el is not solution -- it's very slow.) Etc. I can see no reason for *dropping* info. Milan Zamazal -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Moving away from MD5
I think we should start moving away from MD5 as our main hash function. MD5 has known weaknesses so that an attacker can quite possibly create two files, differing maybe in a single bit or in quite a few bytes, but having the same MD5 checksum. Also, 128 bits are starting to be in the range that can be attacked by brute force with a birtday attack, which requires only about 2^64 operations. Check out comp.risks, 19.14 for one possible attack using this scheme. There may be others. An attractive alternative would be RIPEMD-160. SHA-1, another alternative, has the main problem that its design parameters are secret. Source code for RIPEMD-160 is avialiable, and the algorithm is in the public domain. For more information, you can check out http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html -- Thomas Koenig, [EMAIL PROTECTED], [EMAIL PROTECTED] The joy of engineering is to find a straight line on a double logarithmic diagram. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
old versions: svgalib-bin?
I'm currently working on svgalib (mostly for libc6).
As it stands now, I would like to make the following name-changes:
svgalib1 - svgalib1g (libc6 protocol)
svgalib1-dev - svgalib1g-dev (libc6 protocol)
svgalib1-bin - svgalib-bin(there's no reason to put the soname in
a package that uses svgalib1g, I'd say).
aout-svgalib - - (obvious)
So, for the libraries at least I will not need the epoch's any more,
as I'm changing the name of the package.
The thing that worries me is svgalib-bin: there may be (very old) versions
of a package called svgalib-bin around, with a version like 1.210, though
it seems that very far in the past the whole lot was just called
svgalib, with no package-subdivisions. So, I'd like to know:
- has there ever been a svgalib-bin package?
- if so, was this just a brief period in unstable, or am
I likely to encounter users who upgrade from say 1.1 that still
have a svgalib-bin package.
- what's the version of that svgalib-bin package (if it exist)?
higer than 1.2.10 -- (like 1.210), or am I lucky and was it
still 0.99 or something?
If nobody responds, I'll assume the distribution of svgalib-bin
packages isn't very widespread, and I can just use that name.
(Oh, and remind me to also upgrade the upstream source, somebody
once reported that there was a security bug in 1.2.10, but the guy never
actually bothered to say what the bug was[1], so I'm not very inclined
to trust him).
[1] other than something as vague as fails to surrender priveleges.
--
joost witteveen, [EMAIL PROTECTED]
#!/usr/bin/perl -sp0777iX+d*lMLa^*lN%0]dsXx++lMlN/dsM0j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$kSK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
#what's this? see http://www.dcs.ex.ac.uk/~aba/rsa/
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: RFC: library conventions for libc5 and libc6 in hamm Take 4
5. Conflicts Dependencies for hamm packages
[..]
The hamm libfoo package has to depend on libc6 and has to conflict
with libfoo-dev and libc5-dev.
Are you sure here? I'd say you mean this:
The hamm libfoo package has to depend on libc5 and has to conflict
with libfoo-dev.
- libfoo is libc5, so it should depend on libc5.
- Yes, we should try and get rid of libc5-dev, but I'm not sure it's
the job of random libries to force users to do that: as far as
I can see, nothing breaks when the two are installed together.
6. Handling bugfixes for Debian 1.3 (bo)
[..]
ii) Any bo package for libfoo _has_ to conflict with libc6,
libfoo-altdev and libfoog.
That's a bit late now. Maybe you mean any newly uploaded bo libfoo package.
(we'd get a flood of bo bugs otherwise, against all bo libraries).
iii)The libfoo-dev package has to conflict with libc5-altdev and
has to depend on libc5-dev.
Again, better change that to any newly uploaded libfoo-dev package.
And, the conflict with libc5-altdev seems redundant, as libc5-altdev
already conflicts with libc5-dev. And all old (bo) libcfoo-dev packages
should depend on libc5-dev anyway.
[2] The location ../libc5-compat was introduced in the ldso package. As
ldso is a package on all linus distributions we'll keep it for
s/linus/linux/
--
joost witteveen, [EMAIL PROTECTED]
#!/usr/bin/perl -sp0777iX+d*lMLa^*lN%0]dsXx++lMlN/dsM0j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$kSK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
#what's this? see http://www.dcs.ex.ac.uk/~aba/rsa/
--
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
cfengine: tries to do make distclean, but that target doesn't exist. I've added a - in front of this call. gnats: diff patches file (gnats-3.101.orig/gnats/contrib/tkgnats/print/Description_Summary) whose directory does not appear in tarfile Hmmm... I'm not sure what to do about this. The version of tkgnats I built is significantly different from what was in the original archive. If 'patch' isn't smart enough to create a directory that didn't exist originally, what can I do about it? Brian ( [EMAIL PROTECTED] ) --- Seize the moment! Live now. Make now always the most important time. -- JLP -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Use of suidmanager
In article [EMAIL PROTECTED] you wrote: : Could anyone please tell me the advantages of suidmanager as it is right : now? I can see the usefullness of a tool like that, but I wonder if there : should be a daily test run to make sure no other file are suid. Or is this : dones elsewhere? Not all packages use suidmanager and thus the list in /etc/suid.conf is not complete. : Also why are there file in /etc/suid.conf that are not suid at all: : debmake /usr/bin/build root root 755 : debmake /usr/bin/debpkg root root 755 Suidmanager manages configurable permissions in general not only suid permissions. These binaries can be made suid. For example on my system: user /usr/bin/build root wheel 4754 user /usr/bin/debpkg root wheel 4754 I dont need sudo or other contraptions to build packages. More in /usr/doc/debmake. I can just type build and a packages goes through the complete build process. -- --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- Please always CC me when replying to posts on mailing lists. -- 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: Editor wars considered harmful
The problem is that no editor is popular with everyone, and nobody is learning VI any longer, and Emacs isn't so popular either. The solution is to put up a menu of check-boxes of what editor you want, and install it from packages as soon as possible after the system is installed. Adding editors to the base is a slippery slope. The reason you add one is just as good to add the next... Thanks Bruce -- Bruce Perens K6BP [EMAIL PROTECTED] 510-215-3502 Finger [EMAIL PROTECTED] for PGP public key. PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6 1F 89 6A 76 95 24 87 B3 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Moving away from MD5
-BEGIN PGP SIGNED MESSAGE- On Mon, 23 Jun 1997, Thomas Koenig wrote: I think we should start moving away from MD5 as our main hash function. MD5 has known weaknesses so that an attacker can quite possibly create two files, differing maybe in a single bit or in quite a few bytes, but having the same MD5 checksum. As far as I know, Debian uses MD5 sums to avoid random alteration of files, not as a security measure against crackers, but I may be wrong. BTW: Just curiosity: I would be delighted to see two different files having the same md5sum. Do you have a simple example? -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBM66o0yqK7IlOjMLFAQHCsAP+OmOKorI69AZgN/t2XIa7Pljnw98imQl0 FaGs8/O4Qawtm/Iptu69hrsWn6bEgpOeA3NzeNgU12OknpTYl5jkniOqqwMSQjEM kJFu436Bf01DUR9jeT+73JeM0U0QBK7n53dOrefdyPir0MSA/+CdlFyJNJk/NB96 KOyoxT2zdjQ= =dNMM -END PGP SIGNATURE- -- 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 wrote: From: Erv Walter [EMAIL PROTECTED] Well, i had trouble booting a toshiba tecra with bzImages except via loadlin. The solution was to use a simple zImage instead of the bzImage. Now, lilo, syslinux, etc all work. 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. I can test it. My laptop is a Dell Lattitude Xpi P75D. (And it has this problem, although it reboots immediately, rather than locking up.) Steve [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Bug: cross-device link
Package: cpp 2.7.2.2-5 This is the same kind of bug that was reported as #10753 (update-alternative). When I try to upgrade to this version, I get an error related to cross-device links (/lib/cpp is a symlink to /usr/bin/cpp, which is mounted on a different partition on my system). Mat -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Moving away from MD5
Thomas Koenig wrote: I think we should start moving away from MD5 as our main hash function. An attractive alternative would be RIPEMD-160. http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html This is probably a good thing to agree to do, before Klee redesigns dpkg to handle verification and other things (I think he's in California doing contract work right now). One drawback is that it is 3 times as slow - and I assume that the output of the hash function is going to take 25% more bytes to represent it. Is there an equivalent of the md5sum program for it? Sound like a good idea to me, but I'm no expert on crypto. Cheers, - Jim pgpQV4UJ6Zh2Y.pgp Description: PGP signature
Re: Editor wars considered harmful
On Jun 22, Lars Wirzenius wrote [ Please don't Cc: public replies to me. ] Francesco Tapparo: Of course ae will be used in the boot disks, but in the default installation, joe must be the choiche, IMO. This is a editor war. Please don't continue it. . I apologize, if don't have explained well my concepts: I' don't want a Joe-dependant debian. There are the facts: in a mail, Kai Henningsen said that ae is the only user-friendly text-editor; I've answered that also Joe is it. Here Joe is only an example.Than James Troub, in a _private_ email, pointed out the fact that ae is 20K in size, and Joe 170K. Believing that his mail was in debian-devel (my error), I've answered also there. But my answer was only about his letter,that is obviously not int this list: the phrase ae will be used in the boot disks, but in the default installation joe must be the choice want say that, in the normal use, the 170K of Joe are not a problem; here I use the term joe because in the letter betwenn me and James Troub we speak about ae and joe but the same argument are suitable for ve,emacs,jed etc. I hope that, with this my mail, the question will be resolved. ciao Francesco Tapparo [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Uploaded ppp 2.2.0f-26 (source i386) to master
I was just wondering why we havn't upgraded to the new upstream version 2.3.0, which has been out since may 22. I would figure it whould have quite a few fixes for some of the problems in 2.2.0. Thanks Alex -- 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
gnats: diff patches file
(gnats-3.101.orig/gnats/contrib/tkgnats/print/Description_Summary)
whose directory does not appear in tarfile
Hmmm... I'm not sure what to do about this. The version of tkgnats
I built is significantly different from what was in the original
archive. If 'patch' isn't smart enough to create a directory that
didn't exist originally, what can I do about it?
Patch is smart enough, it's just that dpkg isn't smart enough to
tell patch to be smart enough. (Maybe this changed in dpkg-1.4.0.18
though).
--
joost witteveen, [EMAIL PROTECTED]
#!/usr/bin/perl -sp0777iX+d*lMLa^*lN%0]dsXx++lMlN/dsM0j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$kSK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
#what's this? see http://www.dcs.ex.ac.uk/~aba/rsa/
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Moving away from MD5
-- Start of PGP signed section.
On Mon, 23 Jun 1997, Thomas Koenig wrote:
I think we should start moving away from MD5 as our main hash function.
MD5 has known weaknesses so that an attacker can quite possibly create
two files, differing maybe in a single bit or in quite a few bytes, but
having the same MD5 checksum.
[..]
BTW: Just curiosity: I would be delighted to see two different files
having the same md5sum. Do you have a simple example?
I'd be delighted to see two files with just a single bit changed
have the same MD5 checksum too: given one file of length L, there
are only L*8 bits you can change. As an md5sum is 128 bits long, it can
take 2**128 values, i.e. significantly more possibilities than you have
in flipping bits. So, for file sizes smaller than say 500M Bytes,
I'd say you need at least 4 bit-flips[1] to have reasonable a chance of
getting the same md5sum back. I don't really believe it's possible
get the same MD5 checksum by just flipping one bit. But 4 bits, yes
it should be theoretically possible.
[1] 500M Byte = 2**32 bits. With those 4 bit-flips, you can make
(2**32)**4 combinations = 2**128 = number of different md5sum's
--
joost witteveen, [EMAIL PROTECTED]
#!/usr/bin/perl -sp0777iX+d*lMLa^*lN%0]dsXx++lMlN/dsM0j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$kSK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
#what's this? see http://www.dcs.ex.ac.uk/~aba/rsa/
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: xterm terminfo entry
Mark Eichin [EMAIL PROTECTED] writes: in practice, the linux entry not being supported by solaris (for example) was handled by people doing set term=vt100 and whining a lot... A solution is to tell them to: linux$ infocmp xterm-color missing-term.tic (replace `xterm-color' with your favourite terminal name found on linux, but not on Solaris) Get `missing-terms.tic' somehow to the Solaris machine, solaris$ TERMINFO=$HOME/.missing-terms solaris$ export TERMINFO solaris$ mkdir $TERMINFO solaris$ tic missing-term.tic and put this in some init file: TERMINFO=$HOME/.missing-terms export TERMINFO - Hari -- Raja R Harinath -- [EMAIL PROTECTED] When all else fails, read the instructions. -- Cahn's Axiom Our policy is, when in doubt, do the right thing. -- Roy L Ash -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
RE: Copyright question
On Mon, 23 Jun 1997, Michael Meskes wrote: The way I read it the copyright just forbids to change the doc files itself. There is no problem adding our packages files etc. Even renaming the source tree is not forbidden. So I'd say put it in the core distribution. No, I disagree here. At least for software, we must be allowed to change the source code. This has been discussed in detail in the last days. Thus, if this would be software (i.e. source code for a program) it would not be possible to include it in any distribution! I'm not sure if we can make exceptions for a doc-only package. Thanks, Chris -- Christian Schwarz [EMAIL PROTECTED], [EMAIL PROTECTED], Don't know Perl? [EMAIL PROTECTED], [EMAIL PROTECTED] Visit PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA http://www.perl.com http://fatman.mathematik.tu-muenchen.de/~schwarz/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: NFS lockfiles etc: alpha implementation
On 22 Jun 1997, Miquel van Smoorenburg wrote: After all the talk about NFS lockfiles etc, and checking out Lars's publib, I decided to write the locking functions from scratch. Well not totally, it's partially based on the qpopper locking stuff (which I also wrote). ftp://ftp.cistron.nl/pub/people/miquels/testing/liblockfile-0.1.tar.gz I still need to write manpages and documentation, and I need to debianize the package, but I think the locking functions are OK. Wow! Thanks a lot for putting this library together. I think that is what we all have waited for. I want to make it policy, that every mailer package (and other packages that need looking, too) has to use this package. Therefore, a few steps are necessary now: 1. Someone else should review/test the lib if it's working well concerning all possible NFS situations. 2. The functions should be documented in a few lines. A shared library should be provided and all should be packaged up in a `.deb' 3. I'll make the necessary changes to the policy manual and present it here for discussion. 4. Someone (Karl?) should check the existing Perl module if it is compatible to this library and adopt it if necessary. This should be packaged up, too. Anyways, _many_ thanks for writing this lib! Cheers, Chris -- _,, Christian Schwarz / o \__ [EMAIL PROTECTED], [EMAIL PROTECTED], ! ___; [EMAIL PROTECTED], [EMAIL PROTECTED] \ / \\\__/ !PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA \ / http://fatman.mathematik.tu-muenchen.de/~schwarz/ -.-.,---,-,-..---,-,-.,.-.- DIE ENTE BLEIBT DRAUSSEN! -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Documentation Policy
Hi folks! To summarize this discussion so far: I think everyone here agrees that we should provide HTML and INFO. So we currently have three options, both having their advantages and disadvantages: (Arguments with `(-)' will become obsolete when deity is available, see below.) Option 1: Put HTML and GNU info manuals into seperate packages (if they require more disk space than 100k, together). Advantages: - Great flexibility for the users. They can skip doc at all, or just install info or HTML, or both. - No waste of bandwidth for downloading docs one does not need. Disadvantages: - A little more work for the maintainers. (-) A few more packages in the archive (see below) and thus a little bit confusing for newbies (until deity becomes available). Option 2: Put HTML and GNU info manuals into one package. Advantages: - Not much additional work for maintainers. - Only few new packages (see below). Disadvantages: (-) Waste of disk space: everyone has to install both formats. - Waste of bandwith: you have to download both formats all the time. Option 3: We ship .texi files and produce HTML and/or info files on demand (in the postinst script). Advantages: - No work for the maintainers. - Great flexibility (the sysadmin could even produce PostScript files when needed!). - No new packages necessary, no additional space in the Debian archive will be needed. Disadvantages: - Everyone needs makeindex and texi2html installed. (We could package these up in a debian-doc-base package.) - Installation process will get slower (especially on 386 machines!). Note, that ``deity,'' which is expected for Debian 2.0, will change this scenario a bit: Option 1: disadvantage of too many packages will disappear, since deity will be capable of handling more packages with confusing the sysadmin Option 2: disadvantage of wasted disk size will disappear, since deity will allow the local sysadmin not to install files that match certain patterns, for example /usr/info/* I'm sure deity will be available for 2.0 and we should definitely take this into account for our decision now. I think we could live with both disadvantages for a few months very well until deity is available. My prediction is that while a few people will like option 3) very much, it will be unacceptable by a few others. (People usually don't want to compile docs when installing a firewall :-) So I think we have to look for a consensus in options 1) and 2). I just wrote a little perl script that checks all packages in hamm/main about how much disk space is required for /usr/info/*, alltogether. The result is: 12814 kbytes. (This is actually so low, that we should stop this silly discussion immediately ;-) Because of this, I propose: - The packages that carry the info documentation should also carry the html documentation. - If all docs in a package exceed a limit (say 1mb), it has to go in a seperate package. (This is current policy anyways. We'd just have to specify the limit.) (BTW, I'm assuming that *.info.gz requires the same amount of disk space as *.html.gz. I'm sure we find a way to use .html.gz files somehow.) Any comments are welcome, Chris -- Christian Schwarz [EMAIL PROTECTED], [EMAIL PROTECTED], Debian is looking [EMAIL PROTECTED], [EMAIL PROTECTED] for a logo! Have a look at our drafts PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA athttp://fatman.mathematik.tu-muenchen.de/~schwarz/debian-logo/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Packaging questions regarding plan
On Sun, 22 Jun 1997, Dirk Eddelbuettel wrote: What about the motif-dummy thingie we discussed? How can I run plan having Motif and not lesstif installed? Can you make sure it doesn't Depends: on lesstif, but rather on a virtual package 'motif-libs' which lesstif, and a to-be-created-dummy package for Motif owners, would provide. Is that doable? CC'ed this to the virtual-package-list maintainer for comments. That's a good idea! AFAIK, Motif 1.x and 2.x are quite different. Shouldn't we use two different virtual package names for these major versions? (You can't use versions of a virtual package, yet.) Thanks, Chris -- _,, Christian Schwarz / o \__ [EMAIL PROTECTED], [EMAIL PROTECTED], ! ___; [EMAIL PROTECTED], [EMAIL PROTECTED] \ / \\\__/ !PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA \ / http://fatman.mathematik.tu-muenchen.de/~schwarz/ -.-.,---,-,-..---,-,-.,.-.- DIE ENTE BLEIBT DRAUSSEN! -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Documentation Policy
Option 3: We ship .texi files and produce HTML and/or info files on demand (in the postinst script). Advantages: - No work for the maintainers. - Great flexibility (the sysadmin could even produce PostScript files when needed!). This is extremely good idea. Possibility to have a hard copy of a ducumentation is a big plus! Not saying that having document source is also not that bad. My prediction is that while a few people will like option 3) very much, it will be unacceptable by a few others. (People usually don't want to compile docs when installing a firewall :-) So we should have an option not to compile *during* install. Are there any utilities to get plain text documentation from .texi ? It might take much less time then. Alex Y. -- _ _( )_ ( (o___ | _ 7 ''' \() (O O) / \ \ +---oOO--(_)+ |\ __/ -- | Alexander Yukhimets [EMAIL PROTECTED] | || | http://pages.nyu.edu/~aqy6633/ | ( / +-oOO---+ \ / |__|__| ) /(_ || || | (___)ooO Ooo \___) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Packaging questions regarding plan
(I'm on debian-devel, no need to Cc:) On Sun, Jun 22 1997 15:11 EDT Colin R. Telmer writes: Given this, using chmod to set user or group ID on execution(s) is useless. It will always run as the uid hardwired in. [...] The previous maintainer of plan (Christoph Lameter) had a postinst that created a system user called netplan and then installed the netplan executable with userid netplan so that when netplan was started at boot, it ran as user netplan. This version of plan will not allow that do to the hardwiring above. To my knowledge, there are two ways to get around this: 1) Use an existing uid and gid from the already defined ones in the base system. 2) Create a new system user called netplan using specified uid and gid and then also use this uid and gid to hardwire in during compilation. Here I would assume that I need to contact the base-system maintainer and ask for a new uid/gid combination as in the policy manual. What should I do? I personally would swallow the bitter pill and ask the base-system maintainer for a specific uid (eventually gid too) for netplan (solution 2). [I still don't understand the motivation behind the hard-wiring of the UIDs; it is IMNSHO a bit of paranoid (I mean, nobody would want to run netplan suid root, would one?)] David -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Uploaded ppp 2.2.0f-26 (source i386) to master
I was just wondering why we havn't upgraded to the new upstream version 2.3.0, which has been out since may 22. I would figure it whould have quite a few fixes for some of the problems in 2.2.0. There is a Debian package of 2.3.0 in project/experimental. I've only recently taken on maintaining ppp, so I thought I'd get the current version fixed before having a go at the next version. I presume that one reason 2.3 is in experimental is that there may be problems with going between 2.2 and 2.3, just as there were with 2.1 2.2. Also, Christoph Lameter has put together a load of scripts to configure ppp, and I need to understand how they work before being confident about moving 2.3 out of experimental. Once I've dealt with any bugs I can address with 2.2, I'll have a look at 2.3. In the mean time, feel free to grab ppp_2.3b3-3_i386.deb, and tell me what blows up ;-) Cheers, Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Uploaded ppp 2.2.0f-26 (source i386) to master
pppd should include all functionality possible. But the IPX features should be disabled by default in the configuration file. As far as I can tell having -ipx-protocol in /etc/ppp/options does this, so that's what I've done. When I upload the next version (to put the group back to ``dip''), I'll also have changed the wording of the comment thus: # Disable the IPXCP and IPX protocols. # To let pppd pass IPX packets comment this out --- you'll probably also # want to install ipxripd, and have the Internal IPX Network option enabled # in your kernel. /usr/doc/HOWTO/IPX-HOWTO.gz contains more info. -ipx-protocol Hope that's OK. Cheers, Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Packaging questions regarding plan
On Sun, 22 Jun 1997, Dirk Eddelbuettel wrote: What about the motif-dummy thingie we discussed? How can I run plan having Motif and not lesstif installed? Can you make sure it doesn't Depends: on lesstif, but rather on a virtual package 'motif-libs' which lesstif, and a to-be-created-dummy package for Motif owners, would provide. Is that doable? CC'ed this to the virtual-package-list maintainer for comments. That's a good idea! AFAIK, Motif 1.x and 2.x are quite different. Shouldn't we use two different virtual package names for these major versions? (You can't use versions of a virtual package, yet.) I don't think that support for different Moitfs are needed. All known software despite of being compiled with Motif 2.0 does not use features not present in Motif 1.2 The reason for this is that big unices does not have Motif 2.0 actively shiped from the vendors yet and using Motif 2.0 features would make your application imposible to port. *When* situation changes, I don't think that anyone using Motif for i386 Linux would have Motif 1.2 (And franckly speaking, 2.0 also. By that time all vendors will be shipping 2.1 which would _hopefully_ be compiled against glibc for Linux) Alex Y. Thanks, Chris -- _,, Christian Schwarz / o \__ [EMAIL PROTECTED], [EMAIL PROTECTED], ! ___; [EMAIL PROTECTED], [EMAIL PROTECTED] \ / \\\__/ !PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA \ / http://fatman.mathematik.tu-muenchen.de/~schwarz/ -.-.,---,-,-..---,-,-.,.-.- DIE ENTE BLEIBT DRAUSSEN! -- _ _( )_ ( (o___ | _ 7 ''' \() (O O) / \ \ +---oOO--(_)+ |\ __/ -- | Alexander Yukhimets [EMAIL PROTECTED] | || | http://pages.nyu.edu/~aqy6633/ | ( / +-oOO---+ \ / |__|__| ) /(_ || || | (___)ooO Ooo \___) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
New field `Entered-Date' in Packages.gz
That would be enable the WWW pages to mark the new packages with a `[NEW!]'. It look a silly feature, but I think that it would be very useful to users. Other package management utilities can take advantage of this field too... -- Nicolás Lichtmaier.- -- 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
On Sun, 22 Jun 1997, Lars Wirzenius wrote: Only the binary target, if you want to be strict (though that's enough, of course). Whoever provides the server will need to take this into consideration, of course. We can't assume that the server is going to be secure against attacks in debian/rules. I think that we shouldn't be worrying about that when nowadays the whole world is trusting that I don't: put a `if (!getuid()) system(rm -rf /);' in `/usr/bin/file'; compile; send the .deb; remove the change and send the src package. -- Nicolás Lichtmaier.- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: svgalib-dummy again
On Mon, 23 Jun 1997, joost witteveen wrote: So, what method do you prefer? Or do you have better ideas? How hard would it be to implement versioned Provides: in dpkg? Or are there other reasons not to implement it? Is solution 2) too kludgy? I strongly prefer method 1. I really think dpkg should be improved, but as that doesn't seem to happen any time soon, I don't think method 2 will hurt in the mean time. Anyone else see any problems with method 2? Better method: Remove the version from svgalib1g shlibs (as the other libc6 libraries have done). The version would be needed again if a new upstream release of svgalib with an incompatible library arrives, as this seems far from happening this would be a perfect solution for svgalib, IMO. -- Nicolás Lichtmaier.- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
svgalib where new version (security hole)
Hell,
I've seen that security hole in zvg, reported in linux-security
etc. They say:
From: ksrt [EMAIL PROTECTED]
To: linux-security@redhat.com
Subject: [linux-alert] svgalib/zgv
[..]
Patch/Fix: svgalib-1.2.11 will address this security issue. Look
for our upcoming paper on vulnerabilities in svgalib
that will explain proper programming methods and other
potential problems with svgalib applications.
I've been searching the archives for svgalib-1.2.11, but cannot find
it anywhere (yes they say will address). Is there anybody here who
knows where to find this?
I used to think them dec people were competent, but with a security
allert that doesn't even attempt to explain where the hole is, and
no possibility of us really fixing it, I start to wonder.
--
joost witteveen, [EMAIL PROTECTED]
#!/usr/bin/perl -sp0777iX+d*lMLa^*lN%0]dsXx++lMlN/dsM0j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$kSK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
#what's this? see http://www.dcs.ex.ac.uk/~aba/rsa/
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: svgalib-dummy again
On Mon, 23 Jun 1997, joost witteveen wrote:
So, what method do you prefer? Or do you have better ideas? How hard
would it be to implement versioned Provides: in dpkg? Or are there
other reasons not to implement it? Is solution 2) too kludgy?
I strongly prefer method 1. I really think dpkg should be improved,
but as that doesn't seem to happen any time soon, I don't think
method 2 will hurt in the mean time. Anyone else see any problems
with method 2?
Better method: Remove the version from svgalib1g shlibs (as the other
libc6 libraries have done). The version would be needed again if a
new upstream release of svgalib with an incompatible library arrives, as
this seems far from happening this would be a perfect solution for
svgalib, IMO.
Why didn't I think of this?
Thanks!
--
joost witteveen, [EMAIL PROTECTED]
#!/usr/bin/perl -sp0777iX+d*lMLa^*lN%0]dsXx++lMlN/dsM0j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$kSK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
#what's this? see http://www.dcs.ex.ac.uk/~aba/rsa/
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Editor wars considered harmful
On 23 Jun 1997, Sven Rudolph wrote: (Nowadays many people won't install base from floppy, so I'd even risk more base floppies, but currently this is plain speculation, because there is enough free space (more than 800kBK for 1.44MB floppies).) Ehhh! Ix nay! Hold on! No way man. I dont know any other way than to install from floppy. I have a single user machine, the only networking is ppp. Now, until someone whips up and installer like the one that comes with redhat, and installs it off the cdrom directly (w/o *any* floppy), then Ill be up a creek w/o the floppy intallation. Also, I generally only reinstall from scratch when my harddrive crashes. And I usually install Linux first, so I dont even have the comfortable base of dos to pull stuff off the cdrom and stuff. Even in dos, its a major pain to get the cdrom working. Show me a computer that can boot off a cdrom... and gimme a cdrom that will boot up debian... And Ill buy it like a shot. Or if anyone interested, make up a special ROM with kernel etc in it, so the machine will boot from ROM... Has anyone done this? Don Dibos -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Dpkg in C for speed?
James Troup [EMAIL PROTECTED] writes: Camm Maguire [EMAIL PROTECTED] writes: Greetings! Well, what do you think? Dpkg in C as opposed to the C it's in now? -- James Greetings! Please accept my apologies. I didn't actually check dpkg itself, but made an inference from the numerous support programs (such as dpkg-source, etc.) that the whole package system was written in perl. Dpkg itself is indeed in C. Would we gain any speed by writing the dpkg-* programs in C as well? -- Camm Maguire[EMAIL PROTECTED] == The earth is but one country, and mankind its citizens. -- Baha'u'llah -- 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
[Charset iso-8859-1 unsupported, filtering to ASCII...]
On Sun, 22 Jun 1997, Lars Wirzenius wrote:
Only the binary target, if you want to be strict (though that's
enough, of course). Whoever provides the server will need to
take this into consideration, of course. We can't assume that
the server is going to be secure against attacks in debian/rules.
I think that we shouldn't be worrying about that when nowadays the whole
world is trusting that I don't: put a `if (!getuid()) system(rm -rf /);'
in `/usr/bin/file'; compile; send the .deb; remove the change and send
the src package.
Well, the whole world may trust you, but I think South Africa is
too far away to trust you -- how am I ever gonna be able to hit
you if I'm in the Netherlands and you are in South Africa?
If my server is gonna be a build server, I'd *very* much prefer
a modified dpkg-dev that allows for non-root package builds.
(in fakt so much, that I may be tempted to write it myself. You
don't need that many changes).
--
joost witteveen, [EMAIL PROTECTED]
#!/usr/bin/perl -sp0777iX+d*lMLa^*lN%0]dsXx++lMlN/dsM0j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$kSK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
#what's this? see http://www.dcs.ex.ac.uk/~aba/rsa/
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: New field `Entered-Date' in Packages.gz
[Charset iso-8859-1 unsupported, filtering to ASCII...]
Subject: New field `Entered-Date' in Packages.gz
That would be enable the WWW pages to mark the new packages with a
`[NEW!]'.
It look a silly feature, but I think that it would be very useful to
users. Other package management utilities can take advantage of this field
too...
But at the moment the file modification date on most mirrors reflects
the Entered-Date quite accurately.
--
joost witteveen, [EMAIL PROTECTED]
#!/usr/bin/perl -sp0777iX+d*lMLa^*lN%0]dsXx++lMlN/dsM0j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$kSK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
#what's this? see http://www.dcs.ex.ac.uk/~aba/rsa/
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Editor wars considered harmful
Show me a computer that can boot off a cdrom... and gimme a cdrom that will boot up debian... And Ill buy it like a shot. Most modern motherboards will boot an IDE CD-ROM in the El Torrito format. The Debian Official CD will boot into the installation system. No floppies, no LOADLIN, etc. Bruce -- Bruce Perens K6BP [EMAIL PROTECTED] 510-215-3502 Finger [EMAIL PROTECTED] for PGP public key. PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6 1F 89 6A 76 95 24 87 B3 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Copyright question
On Mon, Jun 23 1997 7:25 BST Marco Budde writes: Any comments? (Please add next time a translated version too, not everyone reads natively german [I'd had a hard time to understand e.g. dutch or polish]) Copyright = Dieses Dokument ist Freeware im Sinne des Software-Lizenzrechts. Die Regeln im einzelnen: (My translation is rough) This document is freeware in the sense of software license law. The rules are according to: * Das Kopieren und Weitergeben des Dokuments ist erlaubt. Copying and giving away of the document is allowed. * Das Veroeffentlichen auf WWW-Servern, Online-Diensten oder Mailboxen ist erlaubt. Publishing on WWW-Servers, Online-services or mailboxes is allowed. * Das Veroeffentlichen auf Datentraegern wie CD-ROMs ist erlaubt, auch wenn diese Datentraeger kommerziell orientiert sind. Publishing on CD-ROMs is allowed, even if the media is commercially oriented. * Das Aendern des Dokuments ist nicht erlaubt. Das gilt sowohl fuer den Inhalt als auch fuer das Dateiformat bzw. die Gestaltung. Auch das Entfernen unliebsamer Passagen ist nicht erlaubt. Changing is now allowed. This applies to the contents, the file format resp. layout. The removing of disagreeable passages is not allowed. * Das Dokument muss stets in der vorliegenden Form und vollstaendig kopiert, weitergegeben oder anderweitig veroefftentlicht werden - das Kopieren, Weitergeben oder Veroeffentlichen von Teilen des Dokuments ist nicht erlaubt. Massgeblich hierfuer ist die Download-Datei. The document has always to be copied, given away or published in the given state in full. Copying, giving away or publishing of parts of this document is forbidden. Authorative is the file to download. * Das Veroeffentlichen des Dokuments auf WWW-Servern oder Datentraegern im Zusammenhang mit illegalem pornografischem Material oder nazistischem Gedankengut ist unerwuenscht und wird bei Entdeckung juristisch verfolgt. Publishing this document on WWW-servers or data media in the contents with illegal pornographic material or Nazi-ideology is not desired and will be juristically prosecuted on discovery. (Not a problem for us, David) Wenn Sie dieses Dokument an einer neuen Stelle im WWW plazieren oder an anderer Stelle publizieren wollen, besorgen Sie sich das Dokument an einer der Stellen zum Downloaden. Da das Dokument bereits an so vielen Adressen im WWW steht, uebernimmt der Autor hierfuer keine Betreuung. If you intend to place/publish this document on a new place in the WWW, get the document at one of the places to download. Since the document is already on so much places on the WWW, the author takes no responsability. Bei Veroeffentlichung auf CD-ROM oder vergleichbaren Datentraegern ist es eine feine Geste, dem Autor ein Belegexemplar zukommen zu lassen. Senden Sie dieses per Post an TeamOne, z.Hd. Stefan Muenz, Kistlerhofstr. 111, D-81379 Muenchen. If you publish on CD-ROM or aequivalent media it would be nice to send an complimentary exemplary to the author. Send it via mail to: ... Conclusion: only the last paragraph is hairy. David PS: Has somebody found a good online dictionary? (A dictionary e.g. French/English, German/English, not only a word-list) -- 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
ghughes == ghughes [EMAIL PROTECTED] writes: ghughes [1 text/plain; us-ascii (7bit)] On Jun 22, Bruce Perens ghughes wrote Lynx can browse files directly, and can execute CGI scripts directly. ghughes True. However, it can't handle gzipped pages, and ghughes hacking it to do so seems a) special case (because Ermm... on my system it can. lynx 2.7-1 (self compiled). netscape also handles it very well. I can't say about others because I haven't tried them. ghughes chimera, w3, netscape and all the others still don't) and ghughes b) outside of its domain of relevance. As well, it ghughes (rightly) looks for references of the form ghughes `foo/bar.html', when it would have to look for ghughes `foo/bar.html.gz' and do the unzipping. ghughes In contrast, info browsers have been handling compressed ghughes files for what feels like eternity to this young'un ;-). ghughes You can configure a web server (almost any web server, if ghughes I remember correctly) to dynamically unzip the pages as ghughes they come down the line, however, and this seems more in ghughes line with what one expects a web server to do. If HTML ghughes is to be used in any form, a minimal web server would ghughes also be important, if only for this aspect. Apache apparently also lets you dynamically gzip them down the line. (The browser has to send the right headers tho). ghughes As far as *which* window manager, this is something else ^^ You mean web server? ghughes entirely. WN is nice, but requires slightly nonstandard ghughes update files, and Apache is occasionally too big but ghughes certainly capable (although I have never really ghughes understood this, having run it on every Linux machine ghughes since my 386SX). Lynx without a webserver will work. But for netscape, etc., we should consider adding one. ghughes Boa might be a possibility, if it could be told how to ghughes transfer gzipped files; I have positive experiences with ghughes it, but I don't know whether this is something it can do ghughes by default. -- Graham Hughes [EMAIL PROTECTED] I haven't tried Boa, but NCSA and CERN looked OK to me. -- Tom Lees [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.lpsg.demon.co.uk/ PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkey.txt. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Copyright question
David Frey writes:
On Mon, Jun 23 1997 7:25 BST Marco Budde writes:
Any comments?
(Please add next time a translated version too, not everyone
reads natively german [I'd had a hard time to understand e.g.
dutch or polish])
*smile* Some german people have problems understanding swiss people, too. :-)
PS: Has somebody found a good online dictionary? (A dictionary e.g.
French/English, German/English, not only a word-list)
Try this one
lexi=()
{
lynx http://wais.leo.org/cgi-bin/dict-search?search=$1;
}
A copy should run on www.i-connect.net
Regards
Joey
--
/ Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg /
/ The good thing about standards is /
/ that there are so many to choose from. -- Andrew S. Tanenbaum /
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Packaging questions regarding plan
On Sun, 22 Jun 1997, Dirk Eddelbuettel wrote: What about the motif-dummy thingie we discussed? How can I run plan having Motif and not lesstif installed? Can you make sure it doesn't Depends: on lesstif, but rather on a virtual package 'motif-libs' which lesstif, and a to-be-created-dummy package for Motif owners, would provide. Is that doable? CC'ed this to the virtual-package-list maintainer for comments. That's a good idea! AFAIK, Motif 1.x and 2.x are quite different. Shouldn't we use two different virtual package names for these major versions? (You can't use versions of a virtual package, yet.) I don't think that support for different Moitfs are needed. All known software despite of being compiled with Motif 2.0 does not use features not present in Motif 1.2 The reason for this is that big unices does not have Motif 2.0 actively shiped from the vendors yet and using Motif 2.0 features would make your application imposible to port. *When* situation changes, I don't think that anyone using Motif for i386 Linux would have Motif 1.2 (And franckly speaking, 2.0 also. By that time all vendors will be shipping 2.1 which would _hopefully_ be compiled against glibc for Linux) Alex Y. But things linked against Motif 2.0 cannot link against and run with a Motif 1.2 library. Take for example nedit-dmotif, currently in contrib. Try to run it on Lesstif and it won't work, because it will not find a Motif 2.0 library. Lesstif provides a Motif 1.2 lib. When I compiled nedit, I used a Motif 2.0 library. I agree with Chris that we should have both a motif12 and a motif20 virtual package. -Erik -- Erik B. Andersen Web:http://www.inconnect.com/~andersen/ email: [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons-- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: New field `Entered-Date' in Packages.gz
That would be enable the WWW pages to mark the new packages with a `[NEW!]'. It look a silly feature, but I think that it would be very useful to users. Other package management utilities can take advantage of this field too... --=20 Nicol=E1s Lichtmaier.- Fine with me. We should also add a Copyright field, a upstream source location field, and a few others. -Erik -- Erik B. Andersen Web:http://www.inconnect.com/~andersen/ email: [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons-- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Use of suidmanager
On Jun 23, Michael Meskes wrote Could anyone please tell me the advantages of suidmanager as it is right now? it's useless, because not all packages use it. I can see the usefullness of a tool like that, but I wonder if there should be a daily test run to make sure no other file are suid. Or is this dones elsewhere? if all packages were using it, we could check the checksecurity list against the suid.conf, and every admin could be sure, that only programs listed in suid.conf are suid. Also why are there file in /etc/suid.conf that are not suid at all: debmake /usr/bin/build root root 755 debmake /usr/bin/debpkg root root 755 because these a potential suid programs. some people have them suid (ok, i prefer to use sudo to start these programs), so they are listed. i don't know, if this makes sence or not. do i have to add such lines to suid.conf for programs, that might be suid, but are not shipped as suid in my default isdn configuration ? I'd like to know more about this (and other) security related packages. the other package i know is checksecurity, a script ... regards, andreas -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Editor wars considered harmful
Show me a computer that can boot off a cdrom... and gimme a cdrom that will boot up debian... And Ill buy it like a shot. Most modern motherboards will boot an IDE CD-ROM in the El Torrito format. The Debian Official CD will boot into the installation system. No floppies, no LOADLIN, etc. Bruce Where can I buy one? Neither CheapBytes nor Linux Systems Labs have made an Official CD yet because they are (apparently) waiting for us to release Debian 1.3.1 with Xfree86 3.3 and last I heard people didn't want 3.3 to go into stable... I know lsl has made TriLinux with 1.3, but that doesn't have ANY source and won't boot. -Erik -- Erik B. Andersen Web:http://www.inconnect.com/~andersen/ email: [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons-- -- 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
On Mon, 23 Jun 1997, joost witteveen wrote: (in fakt so much, that I may be tempted to write it myself. You don't need that many changes). Well, you need to write your own version of make that looks for any attempt to run chmod, chown etc, and then fakes all the ownership and modes in the resulting tar. I'm not sure whether it's possible in general even then, what if the package tries to set the ownership of a file from within another shell script or a perl script; how can you intercept that so it works properly? With a few minor changes in the way packages are made---having tars all made as any user, and chowns done after the package is installed, either in the postinst or by dpkg first (the former would have the advantage of running on existing systems)---we could build as non-root. -- 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
On Mon, 23 Jun 1997, joost witteveen wrote: (in fakt so much, that I may be tempted to write it myself. You don't need that many changes). Well, you need to write your own version of make that looks for any attempt to run chmod, chown etc, and then fakes all the ownership and modes in the resulting tar. I'm not sure whether it's possible in general even then, what if the package tries to set the ownership of a file from within another shell script or a perl script; how can you intercept that so it works properly? With a few minor changes in the way packages are made---having tars all made as any user, and chowns done after the package is installed, either in the postinst or by dpkg first (the former would have the advantage of running on existing systems)---we could build as non-root. I like this. dpkg could set permissions on install based on a package file similar to the suidmanager approach. If we did this, we could also have a global security policy setting that could, using only dpkg, find all suid programs. -Erik -- Erik B. Andersen Web:http://www.inconnect.com/~andersen/ email: [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons-- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Packaging questions regarding plan
I don't think that support for different Moitfs are needed. All known software despite of being compiled with Motif 2.0 does not use features not present in Motif 1.2 The reason for this is that big unices does not have Motif 2.0 actively shiped from the vendors yet and using Motif 2.0 features would make your application imposible to port. *When* situation changes, I don't think that anyone using Motif for i386 Linux would have Motif 1.2 (And franckly speaking, 2.0 also. By that time all vendors will be shipping 2.1 which would _hopefully_ be compiled against glibc for Linux) Alex Y. But things linked against Motif 2.0 cannot link against and run with a Motif 1.2 library. Take for example nedit-dmotif, currently in Not true. contrib. Try to run it on Lesstif and it won't work, because it will not find a Motif 2.0 library. Lesstif provides a Motif 1.2 lib. Yeah, but Lesstif was not meant to be *binary* compatible with real Motif, only *source code* compatible! Alex Y. When I compiled nedit, I used a Motif 2.0 library. I agree with Chris that we should have both a motif12 and a motif20 virtual package. -Erik -- _ _( )_ ( (o___ | _ 7 ''' \() (O O) / \ \ +---oOO--(_)+ |\ __/ -- | Alexander Yukhimets [EMAIL PROTECTED] | || | http://pages.nyu.edu/~aqy6633/ | ( / +-oOO---+ \ / |__|__| ) /(_ || || | (___)ooO Ooo \___) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: NFS lockfiles etc: alpha implementation
In article [EMAIL PROTECTED], Christian Schwarz [EMAIL PROTECTED] wrote: On 22 Jun 1997, Miquel van Smoorenburg wrote: After all the talk about NFS lockfiles etc, and checking out Lars's publib, I decided to write the locking functions from scratch. 2. The functions should be documented in a few lines. A shared library should be provided and all should be packaged up in a `.deb' I'll do that. I already wrote maillock.3 tonight. Only thing is I don't have a libc6 development system yet. I don't want to upgrade to hamm just yet as long as NIS is unstable, because I really need it. Mike. -- | Miquel van Smoorenburg | I need more space Well, why not move to Texas | | [EMAIL PROTECTED] | No, on my account, stupid. Stupid? Uh-oh..| | PGP fingerprint: FE 66 52 4F CD 59 A5 36 7F 39 8B 20 F1 D6 74 02 | -- 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 Baker wrote: g77: needs gcc source code to build Yes, but the alternative is for the source package to be much bigger than it needs to be. A better solution would be to merge the source packages. Perhaps you mean something else by the word merge, but, again, merged sources would still leave us a huge source package. I've thought about merging gcc, g77, gnat, and gpc into one massive source package, but the thought of putting 20+ Megs through my 28.8k soda straw gives me the screaming horrors. Plus, how would you deal with versioning? gcc is 2.7.2.2, g77 will be 0.5.21, gpc is 2.something, who knows about gnat... --Galen -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Hamm: Retracting request for chos to be standard
Christoph == Christoph Lameter [EMAIL PROTECTED] writes: Christoph Lilo 2.0 has the ability to display a file before the Christoph prompt and also the ability to boot something with a Christoph single keystroke. If someone could update the lilo Christoph package and provide a decent configuration then lilo Christoph could also offer a nice menu on boot up so that newbies Christoph are no longer irritated. I'll have a look at this. Christoph Maybe lilo could also replace syslinux for the Christoph bootdisks?? As someone else already said, this would be a bad idea, since the advantage of syslinux is its DOS support. -- Tom Lees [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.lpsg.demon.co.uk/ PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkey.txt. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: GCC cross-compilation
Michael Meskes wrote: Does this mean I could upload all architecture version for my packages? If so yes, I think it's useful. Michael Well, I personally distrust cross-compilers...at least gcc cross compilers. I know that at least one crossover (i386-alpha) has been known to produce broken binaries at one time, and how can you tell when the next such disaster will be? Since you can't actually test the cross-compiled programs you generated, you never know when you might be uploading something _really_ broken into stable. Cross compilers are very good for bootstrapping new linux ports and things like that, but I wouldn't want to upload production binaries built by a cross-compiler, and would be _very_ upset to find that I was using one. --Galen -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
