Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
James Troup wrote: Joey Hess [EMAIL PROTECTED] writes: James Troup wrote: They don't compile from freshly unpacked source. How odd. Other maintainer must work substantially differently than I, then. If you're building foobar 1.1-3, do you really recompile from a freshly unpacked foobar_1.1-3.dsc? Yes. Binary-only and normal NMU's are the same thing, No they're not. Why do you insist on this obvious falsehood? Um, how are they different? Will you please get off your high horse and stop being so incredibly condescending? It doesn't help in anyway whatsoever and without some facts to back up your anti-non-i386 rants, it's really rather pointless. What exactly makes us second class citizens (your wishes aside)? I've heard complaints from porters many times that the ports are treated as second class citizens. I think I could dig up complaints form *you* saying that. -- see shy jo
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
Manoj Srivastava wrote: Really? I use cvs, and hence all my packages are indeed built from scratch. I was under the impression that more and more people are etting converted to CVS, but I guess that is wishful thinking. Well I don't use cvs, but my hand-crafted version control and package building system has the exact same effect. We should encourage people to build from scratch. Maybe that should be noted in some document. -- see shy jo
Re: Debian 2.[01] -- Only rudimentary support for Laptops?
On Thu, 15 Oct 1998, Alexander Kushnirenko wrote: kushni kushniIf there were some Debian oriented database, where one could kushniadd his experience about installation of Debian on some kushniunusual hardware, I would add mine about ThinkPad 380XD. THERE IS ! FAQ-O-MATIC ! (Excuse my yelling, I just wanted to advertise ;) ) Why don't you put an entry in this nice, underutilized tool. And reward Mr. Grobman for his effort. See: http://www.debian.org/fom/1.html John Lapeyre [EMAIL PROTECTED] Tucson,AZ http://www.physics.arizona.edu/~lapeyre
Re: Which PGP?
Joseph Carter wrote: Dpkg now does support gpg though not by default (you might have still been away at the time this came up) and it was planned to modify dinstall to support both. Did the dinstall mod not happen or something? Indeed not. It turned out that gpg was not consistent enough in its exit codes, and this was filed as a bug. Richard Braakman
Re: Removing Gnome [was: Removing Packages in Slink for Debian 2.1]
On Thu, 15 Oct 1998, Stephen Crowley wrote: crowThat is ridiculous, there is no reason to remove gnome before the freeze, if you FWIW, one of the slashdot commenters on the slink-freeze, commends slink for including gnome ( he did install the packages, too) . John Lapeyre [EMAIL PROTECTED] Tucson,AZ http://www.physics.arizona.edu/~lapeyre
Re: moving mutt-i from non-us to main
Marc Singer writes: I was under the impression that putting hooks in to use crypto was enough to raise the hackles of the export hounds. Standing near the border and thinking about prime numbers is enough to raise the hackles of the export kooks. Ihere has got to be some limit to the amount of crap we'll take from these jerks. Ignore the nonsense about 'hooks' and ship it. -- John HaslerThis posting is in the public domain. [EMAIL PROTECTED] Do with it what you will. Dancing Horse Hill Make money from it if you can; I don't mind. Elmwood, Wisconsin Do not send email advertisements to this address.
Re: Removing Packages in Slink for Debian 2.1
On Thu, 15 Oct 1998, Michael Meskes wrote: meskesOn Wed, Oct 14, 1998 at 12:19:30PM -0400, Brian White wrote: meskes libmagick4-dev19332 libmagick: ldconfig-symlink-before-shlib-in-deb LI#67 [217] ([EMAIL PROTECTED] (Scott K. Ellis)) meskes meskesI wish I would understand a message like that. :-) meskes You can ! ... homey 11 echo 'E: libmagick: ldconfig-symlink-before-shlib-in-deb' | lintian-info E: libmagick: ldconfig-symlink-before-shlib-in-deb N: N: In the package contents list, the shared library has to come before N: any symbolic links referencing the shared library. N: N: Refer to Packaging Manual, chapter 12 for details. N: John Lapeyre [EMAIL PROTECTED] Tucson,AZ http://www.physics.arizona.edu/~lapeyre
Re: Gnome 0.30 fix?
This is characteristic of reading and writing outside of array bounds. (as determined by malloc) I linked it with Electric Fence. It didn't report anything though... M. S. Martin A. Soto J. Profesor Departamento de Ingenieria de Sistemas y Computacion Universidad de los Andes [EMAIL PROTECTED]
Re: Debian 2.[01] -- Only rudimentary support for Laptops?
Hi, John! Thanks for reminding me about that. Part of the reason I forgot is that there is no direct link to it from main Web page. Perhaps FAQ-O-Matic deserved it's place on Main page. Sasha. kushni kushniIf there were some Debian oriented database, where one could kushniadd his experience about installation of Debian on some kushniunusual hardware, I would add mine about ThinkPad 380XD. THERE IS ! FAQ-O-MATIC ! (Excuse my yelling, I just wanted to advertise ;) ) Why don't you put an entry in this nice, underutilized tool. And reward Mr. Grobman for his effort.
glibc 2.1 (test release 2.0.98) for i386 (was: Re: The freeze and IMMINENT 2.2.0p1!!)
At 21:19 +0200 1998-10-10, Marco d'Itri wrote: On Oct 09, J.H.M. Dassen Ray\ [EMAIL PROTECTED] wrote: I can see pcmcia (28-Sep-98 is needed) and netutils (so that IPv6 is supported), but not a lot of packages. IIRC, libc6 doesn't support IPv6; you need a beta version for that. So this is only an issue if we intend to release one of the libc6.1 using ports. In the next weeks my site will go on the 6bone and I plan using debian for our IPv6 gateway box. Where can I find a libc6.1 for intel? I have uploaded i386 binaries and source to http://master.debian.org/%7Eespy/glibc/. I built the package with 2.1.125ac2 kernel headers. Note that the binary packages have had no testing, the packaging is *probably* OK, but I can't vouch for the libraries themselves. The packaging should support all Debian architectures, i386, powerpc, and sparc have all been tested with this or somewhat earlier incarnations of my packaging. Will the current netutils just work with IPv6 after recompiling or do I have to patch it? AFAIK, the current Debian net-tools is new enough that a reconfig (net-tools has an interactive configure script to decide which protocols it should support) and recompile should offer IPv6 support. BTW, please be aware that this is only a test release, and you probably will find bugs. -- Joel Klecker (aka Espy) URL:mailto:[EMAIL PROTECTED]URL:http://web.espy.org/ Debian GNU/Linux user/developer on i386 and powerpc. URL:mailto:[EMAIL PROTECTED] URL:http://www.debian.org/
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
James Troup wrote: Who said they were bad? You did. A few days ago you agreed that bin-only NMU's were not ideal. I can't dig it up right now. They are very rarely necessary however, since 99.5% of the time (the only exception I know of is Hartmut's packages) i386 packages are already compiled for i386 and don't need to be compiled by someone other than the maintainer. That's when binary-only-NMUs occur on non-i386. Plenty of people rebuild i386 stuff from scratch for various reasons. Lars Wirenzious autobuilds i386. Joe User/Developer will occasionally extract a package's source and build it from scratch. That doesn't make it right for those people to do i386 binary only NMU's to fix clean-buiild bugs, does it? [ snip remainder of flamage] Please, calm down. -- see shy jo
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
Hartmut Koptein wrote: 1. binary-only NMUs breaks policity Probably. 2. every NMU must be with source I hope. 3. Porters needn't to ask maintainers for permission No-one has to ask for permission for a NMU. That's the point of a NMU. You file a bug, you wait a reasonable time, if it's not closed, you do a MNU. 4. a NMU fixes bugs; no need to forward this to the BTS or the maintainer No, you still have to put a patch for yuor NMU in the BTS. -- see shy jo
bug in xinit/startx or /etc/X11/Xsession?
At the top of /etc/X11/Xsession, a comment is given: # global Xsession file -- used by both xdm and xinit (startx) However, neither xinit or startx appear to be aware of its existence. Does anyone know whether this is a question of the comment being obsolete, ahead of its time, or simply wrong? Does it merit having a bug filed against it?
Re: moving mutt-i from non-us to main
On Thu, Oct 15, 1998 at 06:02:28PM -0500, [EMAIL PROTECTED] wrote: I was under the impression that putting hooks in to use crypto was enough to raise the hackles of the export hounds. Standing near the border and thinking about prime numbers is enough to raise the hackles of the export kooks. Ihere has got to be some limit to the amount of crap we'll take from these jerks. Ignore the nonsense about 'hooks' and ship it. applause pgpA3Ib8PDnrD.pgp Description: PGP signature
Re: gdselect alpha 3
Hmm, I think this is my first comment on this.. On Thu, 15 Oct 1998, Tom Lees wrote: On Wed, Oct 14, 1998 at 02:29:04PM -0700, Joey Hess wrote: Are there any plans to merge this with apt? Seems gdselect has the frontend, and apt has the backend. Well, I could do with some apt in-built dependency handling :) There isnt time before the freeze, and AFAIK there are no plans now (which means there are no plans now). I think this idea of 'lets quickly do something fast' is ill concieved and is ultimately going to hurt our image. I've looked at the latest version, it looks rather pretty, it's slightly more functional than dselect but that's about it.. It doesn't support any of the more sophisticated things that people are clamoring for, and it requires X, GTK and a wack of ram. The fact that it doesn't use the APT library only makes things worse as now it could have big bugs in odd places! Only problem is, apt is in C++, this is in C... So compile your code as C++, it's not hard, change the gcc call to g++ and rename the source files. Then you have to fix up a couple casts and some other things and presto, it's C++. You don't need to use gtk-- or anything else like that. Everything else is done, and I'm adding more UI features. In alpha3? Quick IRC survey shows that it locked one persons machine hard, takes huge amounts of ram+time and has randomly segfaulted for another... I belive Adam Heath has been investigating porting gdselect to libapt, perhaps you should talk to him. Jason
Re: gdselect alpha 3
Quoting Jason Gunthorpe ([EMAIL PROTECTED]): I think this idea of 'lets quickly do something fast' is ill concieved and is ultimately going to hurt our image. I've looked at the latest version, it looks rather pretty, it's slightly more functional than dselect but that's about it.. It doesn't support any of the more sophisticated things that people are clamoring for, and it requires X, GTK and a wack of ram. But it answers the people who think dselect is ugly and unintuitive and want something that runs under X. Perhaps an incremental approach is good: a good gui for the existing product in this release, other features in other releases. Maybe apt will be better, but we haven't seen it yet (referring to the UI). Apt's been in development for a long time, maybe some friendly competition will help. And why can't we have multiple UI's to the package management system? This is linux: one size doesn't fit all. Mike Stone
Re: latest sysklogd broken?
On Fri, Oct 16, 1998 at 12:12:52AM +0200, Martin Schulze wrote: What do you mean by break? If you restart syslogd you have to restart some other programs as well (squid, teergrube, inn, named come to my mind.) Can you explain this? This doesn't sound very normal to me. Sure. Many programs open the socket to syslogd and never re-open it. Thus whenever you restart the syslogd (contrary to SIGHUP' it). These files will log into nowhereland, i.e. the console. This sounds like a fixable libc bug. For the Unix domain socket, it should easily be able to notice when send() fails -- and it should re-open the log socket in that case. I don't think any programs bypass libc to do their syslog calls... You should submit a bug against libc6, I think... Have fun, Avery
Re: latest sysklogd broken?
Avery Pennarun wrote: On Fri, Oct 16, 1998 at 12:12:52AM +0200, Martin Schulze wrote: What do you mean by break? If you restart syslogd you have to restart some other programs as well (squid, teergrube, inn, named come to my mind.) Can you explain this? This doesn't sound very normal to me. Sure. Many programs open the socket to syslogd and never re-open it. Thus whenever you restart the syslogd (contrary to SIGHUP' it). These files will log into nowhereland, i.e. the console. This sounds like a fixable libc bug. For the Unix domain socket, it should easily be able to notice when send() fails -- and it should re-open the log socket in that case. I don't think any programs bypass libc to do their syslog calls... You should submit a bug against libc6, I think... Please go ahead. Regards, Joey -- Install joe (Joey's Own Editor) correct: Joe's Own Editor
Re: Slink not installable from CDs
On Wed, Oct 14, 1998 at 06:48:24PM +0200, Martin Schulze wrote: Enrique Zanardi wrote: Are we going to include apt in the base system? Its package ordering feature (and a few others) obsoletes the other methods, but currently apt doesn't work with mountable media. A multi-cdrom-apt method should be added quick. NO! It does not _obsolete_ other methods. It add new methods. I would begin to hate somebody if it would replace e.g. the ftp method. Apt and apt-get are some more alternatives. They don't replace existing tools. Most of the older methods should be removed. I installed hamm using the CD-ROM method (seemed logical enough) and it tediously went through _all_ the packages on the CD in randomly-ordered dpkg -iGROEB fashion. APT functionality really does obsolete that. Choice is good, but when the choice is between slow and inferior and faster and better there really isn't much point. APT isn't a tradeoff, merely an improvement. That said, multi-CD support in APT would make me an extremely happy camper... Have fun, Avery
Re: Slink not installable from CDs
On Thu, Oct 15, 1998 at 11:39:28AM -0700, David Welton wrote: On Thu, Oct 15, 1998 at 08:31:59PM +0200, Santiago Vila wrote: What would you like to see on the first CD? Why don't we look at what the most popular downloads have been? Some Perl/Python type person ought to be able to parse them nicely, include information about relative sizes of things, and then output something based on that. I don't have time for this, so feel free to can the idea of no one is interested in doing it. I can whip up something like that if someone can feed me the FTP statistics. Have fun, Avery
Re: Slink not installable from CDs
On Thu, 15 Oct 1998, Avery Pennarun wrote: That said, multi-CD support in APT would make me an extremely happy camper... This is being worked on, it's a bit of a tricky problem and got caught up in the Big Rewrite : So it will take a bit to arrive, maybe before release, depending how long the freeze is. Jason
Re: Removing Packages in Slink for Debian 2.1
Previously Martin Schulze wrote: I vote for leave them in. I feel much in favour of presenting them to the world. Basically they work. rantPlease remove gnome, esp. gnome-freecell and gnome-mahjong. My productivity has severly dropped since I discovered them. They are just too darned good and addictive... /rant Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgpeRQk2areTr.pgp Description: PGP signature
Re: Intend to package, create OSS/Free
Previously Manoj Srivastava wrote: Hmm. The revision can be passed through the env var DEBIAN_REVISION, and possibly pcmcia is aware of that and uses that? From what I saw pcmcia parses $(KSRC)/debian/changelog to get the correct version. And since make-kpgd didn't pass the Debian revision I needed to parse that file anyway. So I just changed the regexp a bit and extracted $(KVERS) from there as well.. In short, I don't know -- I'll have to look into pcmcia rules file to see what they do. I'ld rather have you come up with a clean solution so both pcmcia and ALSA can use that.. Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgpF26jcoZBwM.pgp Description: PGP signature
Re: bug in xinit/startx or /etc/X11/Xsession?
Replying to one's own message on the same day... sign of not enough research having been done on my part. Sorry; here's the update: On Oct 15, Nick Cabatoff wrote: At the top of /etc/X11/Xsession, a comment is given: # global Xsession file -- used by both xdm and xinit (startx) However, neither xinit or startx appear to be aware of its existence. Does anyone know whether this is a question of the comment being obsolete, ahead of its time, or simply wrong? I didn't see the /etc/X11/xinit/xinitrc link, which points to Xsession, and which is used if the user has no .xinitrc file. However, this still seems fishy to me... for one thing, Xsession will use the user's .xsession file regardless of where it was called from, which isn't the standard behaviour for startx/xinit. Moreover, the existence of a .xinitrc will prevent the system Xsession file from being used when running startx, whereas the presence of a .xsession file doesn't prevent Xsession from being used. It seems to me that if Xsession is intended to be universal, then the current setup should be changed. I'm willing to make the changes if the maintainer is too busy, but I first want to be reassured that others are in agreement with me.
Re: Slink not installable from CDs
Avery Pennarun wrote: I can whip up something like that if someone can feed me the FTP statistics. One set of stats is available at http://www.lh.umu.se/~bjorn/linux/debian/toplist.packagesnoversion.txt that's only for one ftp mirror, though. -- see shy jo
Secure Locate 1.2 (findutils?)
Anyone give any thought to packaging Secure Locate 1.2? Is there any way to package this without it conflicting with the standard locate provided in findutils? This seems like a much better way to enhance privacy without running updatedb as nobody and thus making users unable to 'locate' files in their own private directories. I'd do this myself, but I haven't been accepted as a maintainer yet, findutils is part of the required base install which I'd rather not be resposible for breaking, and slocate might require some special permissions which could decrease security in a ways I haven't fully explored yet. -- Brian Ristuccia [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Secure Locate 1.2 (findutils?)
If the package replaces the utilities from findutils and is commandline compatible, you might want to find out how dpkg-divert and update-alternatives work. I'd vote for update-alternatives. In any case please negotiate with the findutils maintainer. Regards, Joey Brian Ristuccia wrote: Anyone give any thought to packaging Secure Locate 1.2? Is there any way to package this without it conflicting with the standard locate provided in findutils? This seems like a much better way to enhance privacy without running updatedb as nobody and thus making users unable to 'locate' files in their own private directories. I'd do this myself, but I haven't been accepted as a maintainer yet, findutils is part of the required base install which I'd rather not be resposible for breaking, and slocate might require some special permissions which could decrease security in a ways I haven't fully explored yet. -- Brian Ristuccia [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Install joe (Joey's Own Editor) correct: Joe's Own Editor
APT 0.1.7 released!
The APT team is proud to announce release 0.1.7 of the next-generation packaging tool, APT, which enables users to easily upgrade their whole system of Debian GNU/Linux packages to the latest versions on the world-wide network of Debian HTTP and FTP mirrors. This release covers a few issues with linking with the newest versions of the stdc++ library (2.9) and fixes a glitch in file URI handling with mismatched sizes. To experience all the other improvements for yourself, why not install APT on your Debian system and make sure your system is in synch with the latest and greatest security updates today? Ben Gertzfield [EMAIL PROTECTED], Debian GNU/Linux APT Package Maintainer -- Brought to you by the letters J and C and the number 14. I wanna be Twist Barbie! -- Shonen Knife Debian GNU/Linux -- where do you want to go tomorrow? http://www.debian.org/ I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox.
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
Ok, fine, then please insert a pointer to the patchs in the description, Sorry for that.. But that still leaves the rest of my argument fully intact, and someone stated in past messages that they sent the patchs directly to the maintainer and NOT through the BTS, for a binary only NMU. Zephaniah E, Hull.. On Thu, Oct 15, 1998 at 08:30:46PM +0100, James Troup wrote: [EMAIL PROTECTED] writes: binary-only MNU hits only one arch normal NMU hits possible all archs=20 A binary-only MNU violates the GPL, end of story. FUD, FUD, FUD and more FUD. The source changes for our binary-only NMUs are _always_ sent to the BTS. Also, please get over this GPL obsession, there is *plenty* of software in main _not_ covered by the GPL. -- James [Want to know how Debian violates the GPL all the time? Check how many GPLed packages in Debian have modifications yet don't obey 2(a).] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] pgpnnbxbf34li.pgp Description: PGP signature
Et voila! (was: Re: Slink not installable from CDs)
Martin Schulze wrote: I brought it up already but nobody jumped on. Great, this time people were sensitively watching. Slink currently cannot be installed on a single-cd system using cd images. Everybody agrees? Heiko Schlittermann has written a new dselect installation method that supports multiple cds.[1] The reason why he hasn't uploaded it yet is that it depends on a hax0red version of dpkg-scanpackages to support a new field for each package CD which contains the CD on which the package is stored. I have negotiated myself with Heiko, picked the package from him, debugged and grok'ed it, verified it, wrote some documentation for it, corrected some text, completed it with a specialized version of dpkg-scanpackages, included an adjusted manpage and got Che_Fox to proofread the text. Here is how it works: Installation methods for multiple binary CDs This package provides three new methods to be used within dselect in order to access Debian binary package stored across multiple binary CD ROMS. It will install itself into the methods directory from dselect so the user will be able to use them immediately. These are the three new methods: . Multiple binary CD-ROMs . Multiple binary CD-ROMs, accessed through NFS . Multiple binary CD-ROMs, pre-mounted Acquiring package data - Since this method is derived from the `mounted' method the user is able to access up to five binary directories within `dists/stable': . main . contrib . non-free . non-US . local The selected method will try to read the `Packages' file from each of these directories if it is available. Installing the files At the beginning of the installation the `multicd' package will sort the list of to-be-installed packages and install them CD by CD. If a different CD-ROM is required the user will be prompted to exchange the CD-ROM. Preparing multiple binary CD-ROMs - Since the `multicd' methods need to know which packages are on which CD-ROMs one cannot use regular `Packages' files. An additional data field X-Medium: is required. The first CD-ROM from the set should contain all `Packages' files. To be more convenient you should include the `Packages' files on all CD-ROMs. Additionally the package needs to gain information which CD-ROM is currently used. Thus each CD-ROM contains the file `.disk/info' which contains the symbolic name for the CD-ROM as specified by X-Medium:. In order to be able to create the modified Packages files, this package installs a modified version of `dpkg-scanpackages' in /usr/bin. You'll need to specify the used medium with `-m medium'. To split the `main' distribution into two CD-ROMs you'll need to create a `Packages' file for each `binary-$arch' directory. Afterwards you simply append the second one to the first one and put the resulting `Packages' file into both `binary-$arch' directories. dpkg-scanpackages - This package provides an improved version of `dpkg-scanpackages' which comes with the following additional features: . It can read compressed overrides files . Using `-m medium' you can tell the program to add the new data field X-Medium: for each record in the output. This version is installed using `dpkg-divert' which will disable the original `dpkg-scanpackages' program. Sample Layout - CD1 .disk/info = Debian GNU/Linux binary-i386 dists/stable/main/binary-all/ binary-i386/Packages.gz binary-i386/net/foo.deb contrib/binary-i386/Packages.gz non-free/binary-i386/Packages.gz non-US/binary-i386/Packages.gz CD2 .disk/info = Debian GNU/Linux contrib-i386 dists/stable/main/binary-i386/Packages.gz contrib/binary-all/ binary-i386/Packages.gz binary-i386/net/foo.deb non-free/binary-i386/Packages.gz non-US/binary-i386/Packages.gz CD3 .disk/info = Debian GNU/Linux non-free-i386 dists/stable/main/binary-i386/Packages.gz contrib/binary-i386/Packages.gz non-free/binary-all/ binary-i386/Packages.gz binary-i386/net/foo.deb non-US/binary-all/ To re-generate the Packages file you have to chdir into `dists/stable/$part' and issue `dpkg-scanpackages' as follows. It's assumed that you have copied and gunzipped the overrides files in /tmp. CD1: dpkg-scanpackages -m Debian GNU/Linux binary-i386 \ binary-i386 /pub/debian/indices/override.hamm.gz \ dists/stable/ binary-i386/Packages CD2: dpkg-scanpackages -m Debian GNU/Linux contrib-i386 \ binary-i386 /pub/debian/indices/override.hamm.contrib.gz \ dists/stable/
Re: Which PGP?
On Thu, Oct 15, 1998 at 03:34:54PM -0700, Joseph Carter wrote: On Thu, Oct 15, 1998 at 03:08:46PM +0100, Dave Swegen wrote: Out of curiosity, which version of PGP is the debian de facto standard. I'm currently using v5, but I've seen a number of people use 2.6... The Debian standard is RSA/IDEA (2.6.x compatible) keys, though Debian is slowly adjusting to include gpg (5.x compatible plus more and it's free, with the ability to add RSA and IDEA as modules if you don't mind that they're non-free due to patent BS) In case anyone was expecting me to upload these modules, the IDEA module is strongly discouraged by the gpg author (patented in at least Japan, US, and Europe until 2011), and I've decided for immigration reasons not to get involved in crypto packages. The RSA module could be packaged separately for compatibility with the existing PGP keyring, IDEA isn't necessary. The modules are easy to compile yourself, see the /usr/doc/gnupg for ftp site.
Re: Et voila! (was: Re: Slink not installable from CDs)
All I can say, Joey and Heiko, is congratulations. :) Debian's needed this for a long time, and now we've got it! :) Ben -- Brought to you by the letters D and O and the number 5. I wanna be Twist Barbie! -- Shonen Knife Debian GNU/Linux -- where do you want to go tomorrow? http://www.debian.org/ I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox.
Re: Slink not installable from CDs
Philip Hands wrote: So, slink is more than 760 Megabytes big for i386 machines. This does not fit on one single CD. This means that even without contrib, non-free, non-US etc. we already need two cds. This needs to be addressed quick! Heiko Schlittermann has written a new dselect installation method that supports multiple cds.[1] The reason why he hasn't uploaded it yet is that it depends on a hax0red version of dpkg-scanpackages to support a new field for each package CD which contains the CD on which the package is stored. Phil, as debian-cd maintainer and maintainer of the OfficialCD, I'd like to hear your oppinion. If there's a way of making multi CD installs work, then I'm all for it. Of course there is. Aren't we all able to do some programming? Please take a look at the mail I've just sent and take a look at the dpkg-multicd package which provides three methods for accessing multiple binary cd-roms. ftp://ftp.infodrom.north.de/pub/people/joey/debian/dpkg-multicd_0.7.1_all.deb One thing: Do people think it's important to keep the possibility of doing a one CD install, and still ending up with a useful system ? Yes! I don't think this is too difficult. There are a lot of packages which can be moved onto the second cd-rom. If so, I would think the thing to do is to move the ``most optional'' packages from main onto the second CD, so that the first CD still contains the ``most important'' bits of main. How do we determine what's important, and what's optional ? Some people already mentioned that we need to distinguish between certain packgages. I propose: . First try to separate by section, move the least important section to the second cd and check the remaining disk space. . Secondly check some packages and their priority, move some back onto the first cd and some others off of the first cdrom. . Thirdly you could try to move whole subsystems off of the first CD, like already mentioned: sound, tex, scientific (partially in math, partially somewhere else), misc etc. Regards, Joey -- The MS-DOS filesystem is nice for removable media. -- H. Peter Anvin
Re: Et voila! (was: Re: Slink not installable from CDs)
On Fri, 16 Oct 1998, Martin Schulze wrote: Heiko Schlittermann has written a new dselect installation method that supports multiple cds.[1] The reason why he hasn't uploaded it yet is that it depends on a hax0red version of dpkg-scanpackages to support a new field for each package CD which contains the CD on which the package is stored. I have negotiated myself with Heiko, picked the package from him, debugged and grok'ed it, verified it, wrote some documentation for it, corrected some text, completed it with a specialized version of dpkg-scanpackages, included an adjusted manpage and got Che_Fox to proofread the text. I don't much care for the notion of a single master package file on the first CD.. I rather was intending APT to read the package files from each CD and use that to determine what is on which CD. (This fits with the URI scheme, X-Media does not) Can we perhaps have a Packages.AllCds in some dir that has this header and leave the normal package files with their normal meaning (.debs avail at that URI) Thanks, Jason
Can I create a sym-link in CVS?
I know this question is slightly off-topic but I don't know where else to ask. There are some files which are required in multiple places in the CVS such as debian/kderules. When I find bugs in such files I'd like to fix them all at one go (otherwise I'll surely miss some and make things more of a PITA for the next person). Is there any way I can link a bunch of files in CVS? I'd either like to have the equivalent of sym-links or hard links in CVS, or would it be possible for the CVS database files to be links? The CVS man page doesn't mention any possibility of doing this... -- I'll be in Denver from 30 Oct 1998 to 7 Nov 1998 (or maybe a few days longer). I'll be in London from ~9 Nov 1998. I'd like to meet any Linux users or users groups in these places at these times. I plan to work in London for 3 - 6 months...
Re: Et voila! (was: Re: Slink not installable from CDs)
Jason Gunthorpe wrote: On Fri, 16 Oct 1998, Martin Schulze wrote: Heiko Schlittermann has written a new dselect installation method that supports multiple cds.[1] The reason why he hasn't uploaded it yet is that it depends on a hax0red version of dpkg-scanpackages to support a new field for each package CD which contains the CD on which the package is stored. I have negotiated myself with Heiko, picked the package from him, debugged and grok'ed it, verified it, wrote some documentation for it, corrected some text, completed it with a specialized version of dpkg-scanpackages, included an adjusted manpage and got Che_Fox to proofread the text. I don't much care for the notion of a single master package file on the first CD.. I rather was intending APT to read the package files from each CD and use that to determine what is on which CD. (This fits with the URI Please implement it. Debian can only benefit from multiple ways to interoperate with multiple binary cd-roms. scheme, X-Media does not) Can we perhaps have a Packages.AllCds in some dir that has this header and leave the normal package files with their normal meaning (.debs avail at that URI) Na, we cannot! Doing this we would mixing up free, partially free and non-free stuff. The user still has to be able to install a completely free system. If he wants to use the other parts too, that's up to him. Regards, Joey -- The MS-DOS filesystem is nice for removable media. -- H. Peter Anvin
Re: Et voila! (was: Re: Slink not installable from CDs)
On Fri, 16 Oct 1998, Martin Schulze wrote: I don't much care for the notion of a single master package file on the first CD.. I rather was intending APT to read the package files from each CD and use that to determine what is on which CD. (This fits with the URI Please implement it. Debian can only benefit from multiple ways to interoperate with multiple binary cd-roms. I'm workin on it : scheme, X-Media does not) Can we perhaps have a Packages.AllCds in some dir that has this header and leave the normal package files with their normal meaning (.debs avail at that URI) Na, we cannot! Doing this we would mixing up free, partially free and non-free stuff. The user still has to be able to install a completely free system. If he wants to use the other parts too, that's up to him. Erm, that's not what I ment. A package file is one like debian/dists/stable/main/binary-i386/Packages it describes every archive available from debian/dists/stable/main/binary-i386 and only from that path. Extended to a CDROM URI that would mean the package file cdrom:Debian 2.1r1/debian/dists/stable/main/binary-i386/Packages Describes .debs of the form cdrom:Debian 2.1r1/debian/dists/stable/main/binary-i386/*/*.deb And nothing else. You new X-Media feild makes a package file describe .debs of the form *:*/debian/dists/stable/main/binary-i386/*/*.deb Which is not really acceptable to APT and is infact in direct conflict with how it is designed to operate! Jason
Re: Et voila! (was: Re: Slink not installable from CDs)
On 16-Oct-1998, Martin Schulze [EMAIL PROTECTED] wrote: Jason Gunthorpe wrote: I don't much care for the notion of a single master package file on the first CD.. I rather was intending APT to read the package files from each CD and use that to determine what is on which CD. (This fits with the URI Please implement it. Debian can only benefit from multiple ways to interoperate with multiple binary cd-roms. Please take a quick look at my proposal in the other part of this thread. Although I agree that it doesn't matter too much if we use an inferior method for this release while a better one is worked on. The proposal allows both schemes to work -- you can have one Packages file per CD, or multiple ones on the first CD. scheme, X-Media does not) Can we perhaps have a Packages.AllCds in some dir that has this header and leave the normal package files with their normal meaning (.debs avail at that URI) Na, we cannot! Doing this we would mixing up free, partially free and non-free stuff. The user still has to be able to install a completely free system. If he wants to use the other parts too, that's up to him. This is just a technical problem. There is no reason why the X-Media field has to be in the Packages files on the CD -- that information could be stored by the multi-cd method when it reads in the CD info. -- Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin Tyson Dowd [EMAIL PROTECTED] http://tyse.net
Re: [warp@whitestar.soark.net] Bug#27841: apt: apt depends on a missing library
On Wed, Oct 14, 1998 at 10:56:56PM -0700, Ben Gertzfield wrote: Dan == Dan Jacobowitz [EMAIL PROTECTED] writes: Dan See, it's not Is anyone going to? or Do we agree we Dan should? right now. It's does anyone but Dan have the time Dan to look at http://master.debian.org/~dan and figure out why Dan the compiled libstdc++2.8 package whose source is there is Dan missing a lot of important symbols. I can't figure it out. The source in http://master.debian.org/~dan in the libstdc sir is for 2.9. Could this be the problem? I present http://master.debian.org/~dan/libstdc/libstdc++_2.90.29-1.dsc for your enjoyment... Notice it says Binary: libstdc++2.8. Dan
Re: Et voila! (was: Re: Slink not installable from CDs)
On Fri, 16 Oct 1998, Tyson Dowd wrote: There is no reason why the X-Media field has to be in the Packages files on the CD -- that information could be stored by the multi-cd method when it reads in the CD info. Indeed, why don't we do that instead of complicating the CD making process with a new dpkg-scanpackages? This new method can say 'Stick in a CD' during Update, copy the package file add X-Media to each Package: section and feed to to dpkg --merge-avail, then it can repeat for each CD the user has. This would even scale to Debian Official and a Extra CD'o'Stuff (3 binary CD's) quite nicely. When you grab the package file you can also record something unique about the CD so you can tell if the right one has been inserted at a later date. It would mirror the technique I plan to use in APT. Jason
Re: Et voila! (was: Re: Slink not installable from CDs)
Jason Gunthorpe wrote: On Fri, 16 Oct 1998, Tyson Dowd wrote: There is no reason why the X-Media field has to be in the Packages files on the CD -- that information could be stored by the multi-cd method when it reads in the CD info. Indeed, why don't we do that instead of complicating the CD making process with a new dpkg-scanpackages? Maybe because nobody except Heiko and me have stepped forward? Again: Please implement it. There is room for both methods. It just has to be implemented. Regards, Joey -- The MS-DOS filesystem is nice for removable media. -- H. Peter Anvin
Re: [warp@whitestar.soark.net] Bug#27841: apt: apt depends on a missing library
Dan == Dan Jacobowitz [EMAIL PROTECTED] writes: Dan See, it's not Is anyone going to? or Do we agree we Dan should? right now. It's does anyone but Dan have the time Dan to look at http://master.debian.org/~dan and figure out why Dan the compiled libstdc++2.8 package whose source is there is Dan missing a lot of important symbols. I can't figure it out. Ben The source in http://master.debian.org/~dan in the libstdc Ben sir is for 2.9. Could this be the problem? Dan I present Dan http://master.debian.org/~dan/libstdc/libstdc++_2.90.29-1.dsc Dan for your enjoyment... Dan Notice it says Binary: libstdc++2.8. Wow. How does 2.90 compile out to become 2.8? -- Brought to you by the letters U and N and the number 8. Frungy! Frungy! Frungy!! -- ZokFotPik, SCII Debian GNU/Linux -- where do you want to go tomorrow? http://www.debian.org/ I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox.
Re: octave-plplot: intention to package
On 15-Oct-1998, Joao Cardoso [EMAIL PROTECTED] wrote: | Rafael Laboissiere wrote: | | Hurrying before the slink freeze, here is my intention to package: | | Package: octave-plplot | Version: 0.3-1 [...] | [This will be a great improvement for Octave, IMHO.] | | Actually, I already packaged it. It is lintian-clean and all the demos | are working. I have just a problem with the copyright, as there is no | copyright notice in the upstream source. I obtained it from the | octave-sources mailing list, so I am assuming that it is in the public | domain. | | I know nothing about copyrights, so I include none in the sources. | My intention is that plplot_octave could be available in a future release of | Octave, if Octave's author wants to. If including it in a Debian release | disallows my intention, than I would not approve it. | | As I told before, my intention is to enable it to be used as Octave | is, with a GNU General Public License (which I have never fully read | :-)) . If you want to add/include in all modified sources or | scripts the GNU licence header, I will be happy (if this is still | possible after I have put the package un-intentionally in the public | domain). | | Anyway, I already have latter versions, but they are not packaged | for public usage. | | Thanks, | Joao | | PS- John Eaton: do you have any comments? I don't have any objection to this being distributed as a separate Debian package. Eventually, it may make it in to the core Octave distribution in some form, but I can't say yet when that might happen. Thanks, jwe
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
3. Porters needn't to ask maintainers for permission No-one has to ask for permission for a NMU. That's the point of a NMU. You file a bug, you wait a reasonable time, if it's not closed, you do a MNU. ^^^ Ahhh! Now you have it! This is very bad! Because: low on time, low on hd space, low brain :-), and so on ... Forget it then. This is not possible. (Reminder: porters (i) talk about 200 packages, and after my list 'work for developers' only two people get in contact). I think, we should it do as we have it done the last three years. Thanks, Hartmut -- Hartmut Koptein EMail: Friedrich-van-Senden-Str. 7 [EMAIL PROTECTED] 26603 Aurich Tel.: +49-4941-10390 [EMAIL PROTECTED]
Re: Removing Gnome [was: Removing Packages in Slink for Debian 2.1]
Hi, Brian == Brian White [EMAIL PROTECTED] writes: I'm not sure if it's a good idea to release them as a part of a stable distribution, as they really aren't. There aren't any guarantees that the stuff that runs today is going to run tomorrow. Brian I would agree with you. They should probably be removed from slink Brian at the time of the freeze. Do you have a list of these packages? If we are going to staret removing packages because of the quality of the software, wonderful. I move to remove all traces of the travesty of editors, vi, from Debian, since obviously as editors they are less than alpha quality software. I also want to remove csh and variants, cause they all suck And we should remove them right now, like yesterday. Since when has Debian yanked software that seems to work based on quality? It is not as if there were higher quality older versions that were superceded by inferior versins; this is new software, and not likely to violate the principle of least surprise. manoj -- Men are machines, with all their boasted freedom, Their movements turn on some favorite passion; Let art but find the foible out, We touch the spring and wind them at our pleasure. -- Brooke Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Re: Intend to package, create OSS/Free
Hi, Wichert == Wichert Akkerman [EMAIL PROTECTED] writes: Wichert From what I saw pcmcia parses $(KSRC)/debian/changelog to get the Wichert correct version. And since make-kpgd didn't pass the Debian revision Wichert I needed to parse that file anyway. So I just changed the regexp Wichert a bit and extracted $(KVERS) from there as well.. Heh. Clever. Really cute. Wichert I'ld rather have you come up with a clean solution so both pcmcia Wichert and ALSA can use that.. I can arrange to have the debian version passed in the ENV variable KDREV, or something. That would be clean. manoj -- What is involved in such [close] relationships is a form of emotional chemistry, so far unexplained by any school of psychiatry I am aware of, that conditions nothing so simple as a choice between the poles of attraction and repulsion. You can meet some people thirty, forty times down the years, and they remain amiable bystanders, like the shore lights of towns that a sailor passes at stated times but never calls at on the regular run. Conversely, all considerations of sex aside, you can meet some other people once or twice and they remain permanent influences on your life. Everyone is aware of this discrepancy between the acquaintance seen as familiar wallpaper or instant friend. The chemical action it entails is less worth analyzing than enjoying. At any rate, these six pieces are about men with whom I felt an immediate sympat - to use a coining of Max Beerbohm's more satisfactory to me than the opaque vogue word empathy. Alistair Cooke, Six Men Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
pgp = gpg
Hi all, At the moment I am using pgp2i, but I would like to try and change to gnupg. My question is - will I need to generate a new public/private key, or is it possible to use my pgp one with gnupg? I would really prefer to keep my old one, as otherwise I'll have to distribute a new key, not to mention get signatures, etc, etc. Also, can gnupg use pgp public keys (and which versions of pgp?). And which versions of pgp can use gnupg keys? Sorry if this sounds very nieve.if I've got myself all muddled up could someone please explain how all this stuff really does work? Thanks, Chris -- -- REALITY.SYS corrupted: Reboot universe? (Y/N/Q) Debian GNU/Linux -- Reply with subject 'request key' for PGP public key. KeyID 0xA9E087D5
Re: gdselect alpha 3
Hi, Michael == Michael Stone [EMAIL PROTECTED] writes: Michael Quoting Jason Gunthorpe ([EMAIL PROTECTED]): I think this idea of 'lets quickly do something fast' is ill concieved and is ultimately going to hurt our image. I've looked at the latest version, it looks rather pretty, it's slightly more functional than dselect but that's about it.. It doesn't support any of the more sophisticated things that people are clamoring for, and it requires X, GTK and a wack of ram. Michael But it answers the people who think dselect is ugly and Michael unintuitive and want something that runs under X. A quick and dirty answers is not really a good thing, don't you think? Michael Perhaps an incremental approach is good: a good gui for the Michael existing product in this release, other features in other Michael releases. Maybe apt will be better, but we haven't seen it Michael yet (referring to the UI). Apt's been in development for a Michael long time, maybe some friendly competition will help. And Michael why can't we have multiple UI's to the package management Michael system? This is linux: one size doesn't fit all. Competition is fine, let it get time to mature. The idea is simple: no new code after freeze. let this new system vie with apt at the next release. Since when have we considered scrapping quality just because people want something that ``looks pretty''? manoj -- I have never seen anything fill up a vacuum so fast and still suck. Rob Pike, on X. Steve Jobs said two years ago that X is brain-damaged and it will be gone in two years. He was half right. Dennis Ritchie Dennis Ritchie is twice as bright as Steve Jobs, and only half wrong. Jim Gettys Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Re: Deleting uncompressed Info/Doc files at upgrades
On Thursday 15 October 1998, at 17 h 31, the keyboard of Michael Stone [EMAIL PROTECTED] wrote: Hmm. We have zless to less gz'd files. Magicfilter will print them, as will a2ps (maybe some others will too, haven't tried it.) Netscape reads ... will grep them. vim reads them just fine. I'm drawing a blank on things I can't do with .gz'd files... emacs glimpse (don't tell me about .glimpse_filters, it's awfully slow) mutt -a (if the recipient does not have gzip, for instance a regular MacOS or MS-Windows user. The problem is probably the same for all MUA.) agrep (an approximative grep) And this is just what I use often. Do you mean that *every* application in Debian should be patched to read *.gz files?
Re: pgp = gpg
On Fri, Oct 16, 1998 at 04:06:18PM +1000, Chris Leishman wrote: At the moment I am using pgp2i, but I would like to try and change to gnupg. My question is - will I need to generate a new public/private key, or is it possible to use my pgp one with gnupg? Technically it is possible to use your PGP one with gnupg, but it requires the use of non-free (because of patents) extensions to gnupg (namely, the RSA and idea modules). Also, can gnupg use pgp public keys (and which versions of pgp?). It can, with the same problems. And which versions of pgp can use gnupg keys? PGP 5, I suspect. Sorry if this sounds very nieve.if I've got myself all muddled up could someone please explain how all this stuff really does work? Check out the bug reports against debian-keyring. There's an updated README in there that e.g. explains how to sign your gnupg key with your PGP one. HTH, Ray -- J.H.M. Dassen | RUMOUR Believe all you hear. Your world may [EMAIL PROTECTED] | not be a better one than the one the blocks | live in but it'll be a sight more vivid. | - The Hipcrime Vocab by Chad C. Mulligan
Re: Removing Gnome [was: Removing Packages in Slink for Debian 2.1]
On 16 Oct 1998, Manoj Srivastava wrote: If we are going to staret removing packages because of the quality of the software, wonderful. I move to remove all traces of the travesty of editors, vi, from Debian, since obviously as editors they are less than alpha quality software. and we should get rid of that emacs thing too. any editor which takes that much memory and takes that long to start up is way too bloated to be in debian. :-) (a joke. i'm not serious. read on for a more serious comment.) I also want to remove csh and variants, cause they all suck And we should remove them right now, like yesterday. agreed. i'd vote for that. (i'll leave it up to the reader to decide whether i'm serious about this one or not :) Since when has Debian yanked software that seems to work based on quality? It is not as if there were higher quality older versions that were superceded by inferior versins; this is new software, and not likely to violate the principle of least surprise. ordinarily i would agree with you on this issue. however, Jim Pick (who wrote the original message suggesting that gnome should be removed) is the maintainer of the gnome packages. i reckon it's his call...if he doesn't want the bug reports from alpha quality software, that's up to him to decide. maybe a compromise would be to leave the packages in slink, make sure the Description: field highlights their alpha status, and automatically close all non-packaging bugs (and forward them upstream if it makes sense to do so). craig -- craig sanders
Re: Deleting uncompressed Info/Doc files at upgrades
On Fri, Oct 16, 1998 at 08:51:45AM +0200, Stephane Bortzmeyer wrote: emacs M-x toggle-auto-compression M-x auto-compression-mode depending on your Emacs. Somebody will probably know how to put this into a .emacs. My Elisp is quite ... rusty. Antti-Juhani -- Antti-Juhani Kaijanaho A7 [EMAIL PROTECTED] ** URL:http://www.iki.fi/gaia/ ** 118. Editing is a rewording activity. (Epigrams on Programming, Alan J. Perlis)
Re: Debian 2.[01] -- Only rudimentary support for Laptops?
On Thu, Oct 15, 1998 at 02:40:38PM -0500, Alexander Kushnirenko wrote: Hi, I have an IBM ThinkPad 380XD. I have found that 2.0.x kernels just don't work properly, my machine will crash or shutdown during boot. I believe that the best thing that can be done to support laptops is to create boot disks with 2.1.125 kernels. 2.1.125 works well on my laptop in every way and has fixed the problems with RAM disks that older 2.1.x kernels had. Sorry to jump into discussion... Well, I ABSOLUTELYU agree with Russel. I also installed linux on IBM ThinkPad 380XD. It's my 6-th Debian installation around and definitly the most embarrasing one. I DO agree that ThinkPad 380XD is quite new piece of hardware, and don't want to blame anyone or anything, but perhaps we may pay closer attention to Laptop instalation problems. 1. Official booting disketes - DOES NOT work (tecra also!) 2. Official kernel 2.0.34 - DOES NOT work (constant reboot) The only thing that work was loadlin thru Win95 :( To identify the bug (and try to fix it) a little bit of info is needed. At which step is the system crashing? Before displaying the boot: prompt? Before displaying the Color or Monochrome dialog? Elsewhere? It looks like a kernel-related problem, and not one that applies to any laptop model. -- Enrique Zanardi[EMAIL PROTECTED]
Re: Et voila! (was: Re: Slink not installable from CDs)
On Fri, Oct 16, 1998 at 02:39:38PM +1000, Tyson Dowd wrote: : : There is no reason why the X-Media field has to be in the Packages : files on the CD -- that information could be stored by the multi-cd : method when it reads in the CD info. ... but not, if the first CD contains all packages files (as our datom/schlittermann hamm-CDs do already ... ) The multi-cd approach is fairly well tested by (I think) the most of our customers. I know, that the current implementation is a rather bad hack, but due to limited time and since _nobody_ seemed to be able to solve this when hamm appeared, I've implemented is myself ... Yes, there are some drawbacks that should be solved, but probably not for slink ... Best Regards from Dresden/Germany Viele Gruesse aus Dresden Heiko Schlittermann --- internet unix support ** Heiko Schlittermann -- [a href=http://debian.schlittermann.de/; Debian 2.0 CD /a] Heiko Schlittermann HS12-RIPE finger:[EMAIL PROTECTED] --- pgp: A1 7D F6 7B 69 73 48 35 E1 DE 21 A7 A8 9A 77 92 -
Help needed
Is there anyone out there who could do an upload for me? I have a new better iceconf package ready for upload but I´m sitting on a mail-only account. So I could mail the package to someone who then copies it to incoming on master. Michael -- Dr. Michael Meskes | Th.-Heuss-Str. 61, D-41812 Erkelenz | Go SF49ers! Senior-Consultant | business: [EMAIL PROTECTED] | Go Rhein Fire! Mummert+Partner | private: [EMAIL PROTECTED] | Use Debian Unternehmensberatung AG | [EMAIL PROTECTED] | GNU/Linux!
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
Hartmut Koptein wrote: Ahhh! Now you have it! This is very bad! Because: low on time, low on hd space, low brain :-), and so on ... Forget it then. This is not possible. (Reminder: porters (i) talk about 200 packages, and after my list 'work for developers' only two people get in contact). Well, then, keep a list of the bugs you've filed. Each day you autobuild say, 30 packages from Incoming. If they fail to build, you file bugs and add them to the bottom of your list. Then you look at the top 1/7th [1] of the list. For each bug, if the maintainer has fixed the bug, you build binaries (if you haven't already). If the maintainer hasn't, you do a NMU. If the list starts getting too small, great, you can start looking at more packages each day from incoming. If it gets too long, you can cut back on how many new packages you build each day. -- see shy jo [1] So you go through the full list in a week, giving the maintainer a week to react.
Re: Sources consisting of multiple tarballs
On Sat, Oct 10, 1998 at 01:56:06PM +1000, Stuart Lamble wrote: The bootstrap compiler is distributed (mostly) as assembler source, so they're clearly platform dependant. The sources for the rest of the system are distributed as Modula 3 source code, so they're clearly platform _in_dependant. Unfortunately, the pm3 makefiles are setup in such a way as to require the bootstrap sources to be unpacked as part of the Modula 3 source code tree heirarchy. Couldn't you extract the arch dep parts in different subdirectories and move them to the correct place in the debian/rules file just before building? So you would put all sources in one source package. I could do that, yes. The main problem is that, as far as I can tell, there are currently only i386 sources for the arch dependant stuff at the upstream site (the address for which I've misplaced.. d'oh..) Doing things this way would entail a new source package each time a new architecture is bootstrapped. Probably the cleanest way overall, though, when all's said and done.. and no doubt Guy (or whoever's currently maintaining the FTP archive) would be happy to assist with fixing source packages and the like. Thanks for the suggestion.
1FA: problem still in hamm disks
i've seen postings about this before, but as yet no solution (either as a message or in the boot disks). when debian is made bootable from the hard disk on certain systems, the prompt 1FA: comes up, but the system will not boot off partition 1. the disk controller is AHA-2940. any solutions to this problem? -duncan
Bug with xv?
Hi all, I was just working away on my machine, and using xv to display the latest results from my raytracing project. The pic came out too small, and so I went to press shift '' to zoom it up, only I missed and hit shift ''. Low and behold my xserver crashed. I've since tested and found that if you open xv, and press shift '' continually until the window becomes small enough, the xserver dies. Can anyone else verify this? I am running XF86_SVGA server, at 1280x1024 res, 16-bit. I am running slink and have updated everything to the latest releases. Thanks, Chris -- -- REALITY.SYS corrupted: Reboot universe? (Y/N/Q) Debian GNU/Linux -- Reply with subject 'request key' for PGP public key. KeyID 0xA9E087D5
Wrong dependencies for a single deb: How to reupload ?
Probably a pretty dumb question: dpkg-shlibdeps got the dependencies wrong for a single deb in the python package (tkstep8.0 instead of tk8.0). The package is already DONE; is it possible to reupload just that single python-tk with a fixed control file and the same revision, or do I have to reupload a complete new revision of all python packages ? The source is completely unchanged, only packed with a different configuration. Gregor
Re: 1FA: problem still in hamm disks
On Fri, Oct 16, 1998 at 09:18:23AM +, Duncan Thomson wrote: i've seen postings about this before, but as yet no solution (either as a message or in the boot disks). when debian is made bootable from the hard disk on certain systems, the prompt 1FA: comes up, but the system will not boot off partition 1. the disk controller is AHA-2940. any solutions to this problem? Where does it stops? Does it shows the typical LI message? -- Enrique Zanardi[EMAIL PROTECTED]
Re: Removing Gnome [was: Removing Packages in Slink for Debian 2.1]
Hi, Doesn't the version number convey the alpha nature to people? Like, it isn't even version 1.0? Anyway, seeing that it is the maintainer who is asking for the removal, and the fact that I am not that much of a GNOME user (I fail to see the point, so far), I withdraw my objection in this specific case (in the genertal case I still think it is OK to ship alpha software). manoj -- If anyone has seen my dog, please contact me at x2883 as soon as possible. We're offering a substantial reward. He's a sable collie, with three legs, blind in his left eye, is missing part of his right ear and the tip of his tail. He's been recently fixed. Answers to Lucky. Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Re: Wrong dependencies for a single deb: How to reupload ?
On Fri, Oct 16, 1998 at 10:19:22AM +0200, Gregor Hoffleit wrote: Probably a pretty dumb question: dpkg-shlibdeps got the dependencies wrong for a single deb in the python package (tkstep8.0 instead of tk8.0). Hi, I am the maintainer of tkstep. Can you please make your package to depend on either tk or tkstep. Simply add tk8.0 | tkstep8.0 to your Depends: line. Thank you very much. Ciao Federico The package is already DONE; is it possible to reupload just that single python-tk with a fixed control file and the same revision, or do I have to reupload a complete new revision of all python packages ? The source is completely unchanged, only packed with a different configuration. Gregor -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- --** * Federico Di Gregorio | / *-=$ ;-) TeX Wizard?* * Debian developer! | / -1pgp: finger [EMAIL PROTECTED] * * friend of penguins |/try http://www.debian.org* **DE 9E B2 75 B4 F6 CC 5B C3 D5 71 51 04 AB F3 B2**
Re: login time limits in slink???
On Thu, Oct 15, 1998 at 12:21:06PM -0400, Mitch Blevins wrote: FWIW - I have the same problem. No idled. No logoutd. No lines in /etc/porttime. Still get booted off the console after several hours. Perhaps it's your shell; tcsh has auto-logout functionality. Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org pgpwlQQ9mmyXl.pgp Description: PGP signature
Re: Debian 2.[01] -- Only rudimentary support for Laptops?
On Thu, Oct 15, 1998 at 03:52:12PM -0400, Seth M. Landsman wrote: Hmm, I'm going to have to add a negative data point here. Debian installed almost perfectly on my laptop (a Gateway 2300SE) right off of a CD. I did have to recompile the kernel for APM stuff and pcmcia utilities, which was exceedingly painless (for me, that is, YMMV). I also had to get and install the NeoMagic X Server manually, but this was before a package for it existed. Therefore, I don't think this is laptop installation problems in general. I think that this may be specific to some laptops, but not all. I'd say it's a high percentage. It was trouble on my Toshiba Satellite 310CDS, and although the source disc has the Toshiba boot image on it, it doesn't know how to install the Toshiba kernel later. Although a friend of mine installed it on his Acer Extensa without problems and wouldn't have known that the Tecra disks existed. I need zImage for my desktop too. Don't know why; it's just a generic clone PC. Probably something in my BIOS options. On the other hand I'm yet to see why the Debian default needs to be bzImage anyway -- we compile as much as we can as modules. If the kernel works as a zImage there is no need to build it as a bzImage! And no confusion later. Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: Removing Gnome [was: Removing Packages in Slink for Debian 2.1]
On Thu, Oct 15, 1998 at 04:02:41PM -0500, Stephen Crowley wrote: That is ridiculous, there is no reason to remove gnome before the freeze, if you dont like it dont use it. There are several programs that wont run without it, including GtkICQ which is about the only usuable icq replacement available (if you dont count those crappy console ones) I use text terminals (telnet, Linux console, etc) quite a lot and rather like micq as it happens. Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org pgp94G5frPBuJ.pgp Description: PGP signature
Re: Removing Packages in Slink for Debian 2.1
On Thu, Oct 15, 1998 at 03:46:58PM -0700, Stephen Zander wrote: While you're all on this thread, what about mozilla? The current Debian package doesn't work with the current libc (#27181, severity: grave). I was going to ask Brian for an extension for mozilla as I won't make 00:00 Saturday GMT That's not a problem. The freeze deadline is for regular package uploads. Now that we're in the freeze, only bugfixes are allowed. If you get mozilla to work again, that fixes 27181 (which is release-critical), so such an upload should be accepted. Ray -- Tevens ben ik van mening dat Nederland overdekt dient te worden.
Re: Removing Gnome [was: Removing Packages in Slink for Debian 2.1]
On Thu, Oct 15, 1998 at 05:29:11PM -0500, Havoc Pennington wrote: Whether or not a program sucks or is alpha has never been a criteria for inclusion or noninclusion in Debian, as far as I know. Debian evaluates only the quality and policy conformance of the *package*, not the *packaged program*. Right? If we're going to slash all the alpha software, geda would have to go to. It runs but isn't useful, but the people on the gEDA mailing list tell me they appreciate the .debs and definately want me to keep them in the main archive. Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
notebook infra red driver needed
Does anyone know where to find the patches for the infra red serial port? At least I think there are patches floating around somewhere Michael -- Dr. Michael Meskes | Th.-Heuss-Str. 61, D-41812 Erkelenz | Go SF49ers! Senior-Consultant | business: [EMAIL PROTECTED] | Go Rhein Fire! Mummert+Partner | private: [EMAIL PROTECTED] | Use Debian Unternehmensberatung AG | [EMAIL PROTECTED] | GNU/Linux!
Re: Deleting uncompressed Info/Doc files at upgrades
On Thu, Oct 15, 1998 at 05:31:10PM -0400, Michael Stone wrote: snip Hmm. We have zless to less gz'd files. zless nothing, a simple lesspipe.sh works great, for bigger stuff a not so simple lesspipe.sh (Can give a real complete one if you want, its what I use) works GREAT... Gives file listings for .tar's, handles .bz2 and .gz compression on a file transparently, gives nice readouts for .deb's and .rpm's, renders groffs (man pages), and transparently handles uuencoded files (under .uxx, .uux, and .uue) And its designed in such a way that something like less foo.tar.gz.uue.bz2.uue.gz works perfectly.. (=:] /plug Zephaniah E, Hull. snip Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] pgpgkvyccXUou.pgp Description: PGP signature
Re: Et voila! (was: Re: Slink not installable from CDs)
On 16-Oct-1998, Heiko Schlittermann [EMAIL PROTECTED] wrote: On Fri, Oct 16, 1998 at 02:39:38PM +1000, Tyson Dowd wrote: : : There is no reason why the X-Media field has to be in the Packages : files on the CD -- that information could be stored by the multi-cd : method when it reads in the CD info. ... but not, if the first CD contains all packages files (as our datom/schlittermann hamm-CDs do already ... ) Not true. There just needs to be an association between packages file and CD label. A file in each directory that says which CD the packages are on would be sufficient. E.g. /.packages/non-free/Packages.gz /.packages/non-free/media (contains CD 2) /.packages/main/Packages.gz /.packages/main/media (contains CD 1) Or something like that. The multi-cd approach is fairly well tested by (I think) the most of our customers. I know, that the current implementation is a rather bad hack, but due to limited time and since _nobody_ seemed to be able to solve this when hamm appeared, I've implemented is myself ... Yes, there are some drawbacks that should be solved, but probably not for slink ... Sure. You've done the work, and it will be fine for this release, but it's worth discussing ways we can improve on it in future. The basic scheme is fine, it's just the X-Media can be put elsewhere, which means the same pacakges files can be used everywhere. It would be *less* work to actually leave dpkg-scanpackages as it is, and just add this change to the multi-cd method. But *more* work has already been done, so it isn't necessarily worth changing now. -- Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin Tyson Dowd [EMAIL PROTECTED] http://tyse.net
Re: Removing Gnome [was: Removing Packages in Slink for Debian 2.1]
On Thu, Oct 15, 1998 at 02:24:53PM -0700, Marc Singer wrote: IMHO it is not appropriate to ship beta software under the guise of release software. If it is really desirable to ship gnome, it sould be categorized as ALPHA and installed only when a user explicitly requests it. I wonder what you would have done several years ago when distributions were routinely shipping with development kernels. Michael -- Dr. Michael Meskes | Th.-Heuss-Str. 61, D-41812 Erkelenz | Go SF49ers! Senior-Consultant | business: [EMAIL PROTECTED] | Go Rhein Fire! Mummert+Partner | private: [EMAIL PROTECTED]| Use Debian Unternehmensberatung AG | [EMAIL PROTECTED]| GNU/Linux!
Re: Removing Packages in Slink for Debian 2.1
On Thu, Oct 15, 1998 at 03:46:58PM -0700, Stephen Zander wrote: While you're all on this thread, what about mozilla? Please keep it in, too. This one's another major visibility package for free software. I was going to ask Brian for an extension for mozilla as I won't make 00:00 Saturday GMT, but if you're throught out alpha packages maybe I should do something else this week-end? Since your new upload is for removing bugs by using a new upstream that should be okay. Brian? Michael -- Dr. Michael Meskes | Th.-Heuss-Str. 61, D-41812 Erkelenz | Go SF49ers! Senior-Consultant | business: [EMAIL PROTECTED] | Go Rhein Fire! Mummert+Partner | private: [EMAIL PROTECTED]| Use Debian Unternehmensberatung AG | [EMAIL PROTECTED]| GNU/Linux!
Re: freetype1 is gone from slink, imagemagick still depends on it
On Thu, Oct 15, 1998 at 02:39:05PM -0700, Philippe Troin wrote: Will try to do an upload before the freeze. Which brings me to a general question. Let's say I maintain software A version 1.0 and it has open bugs during freeze. Then shortly after it I find time to look at it and find that version 1.4 has been out already which among others fixes some of the bugs. Am I allowed to put this into frozen? Michael -- Dr. Michael Meskes | Th.-Heuss-Str. 61, D-41812 Erkelenz | Go SF49ers! Senior-Consultant | business: [EMAIL PROTECTED] | Go Rhein Fire! Mummert+Partner | private: [EMAIL PROTECTED]| Use Debian Unternehmensberatung AG | [EMAIL PROTECTED]| GNU/Linux!
Re: Et voila! (was: Re: Slink not installable from CDs)
On Fri, Oct 16, 1998 at 09:10:20PM +1000, Tyson Dowd wrote: : On 16-Oct-1998, Heiko Schlittermann [EMAIL PROTECTED] wrote: : On Fri, Oct 16, 1998 at 02:39:38PM +1000, Tyson Dowd wrote: : : : : There is no reason why the X-Media field has to be in the Packages : : files on the CD -- that information could be stored by the multi-cd : : method when it reads in the CD info. : : ... but not, if the first CD contains all packages files (as our : datom/schlittermann hamm-CDs do already ... ) : : Not true. There just needs to be an association between packages : file and CD label. : : A file in each directory that says which CD the packages are on : would be sufficient. : : E.g. : /.packages/non-free/Packages.gz : /.packages/non-free/media (contains CD 2) : /.packages/main/Packages.gz : /.packages/main/media (contains CD 1) : : Or something like that. Ok, and what if the the main packages are split over multiple CDs? : Yes, there are some drawbacks that should be solved, but probably not : for slink ... : : Sure. You've done the work, and it will be fine for this release, : but it's worth discussing ways we can improve on it in future. : : The basic scheme is fine, it's just the X-Media can be put elsewhere, : which means the same pacakges files can be used everywhere. We use the original packages files here, but when creating the images the X-Media header is added. : It would be *less* work to actually leave dpkg-scanpackages as it : is, and just add this change to the multi-cd method. But *more* : work has already been done, so it isn't necessarily worth changing : now. Best Regards from Dresden/Germany Viele Gruesse aus Dresden Heiko Schlittermann --- internet unix support ** Heiko Schlittermann -- [a href=http://debian.schlittermann.de/; Debian 2.0 CD /a] Heiko Schlittermann HS12-RIPE finger:[EMAIL PROTECTED] --- pgp: A1 7D F6 7B 69 73 48 35 E1 DE 21 A7 A8 9A 77 92 -
Re: what's after slink
On Thu, Oct 15, 1998 at 03:45:49PM -0700, Joseph Carter wrote: On Thu, Oct 15, 1998 at 03:29:34PM -0700, Joey Hess wrote: theone wrote: Names after Slink is very simple. They should just be named after userfriendly characters. Oooh.. that means our releases would even have their own geek code blocks (http://www.userfriendly.org/cast/) ;-) dust_puppy pitr aj chief cobb erwin greg hillary mike smiling_man stef tanya miranda now too... Don't forget her. (I still want an iWhack) Debian GNU/Linux Erwin/iWhack! Zephaniah E, Hull, --- Thought he suggested this before? pgpSshXkxBnfl.pgp Description: PGP signature
Re: freetype1 is gone from slink, imagemagick still depends on it
On Fri, Oct 16, 1998 at 08:56:02AM +0200, Michael Meskes wrote: Which brings me to a general question. Let's say I maintain software A version 1.0 and it has open bugs during freeze. Then shortly after it I find time to look at it and find that version 1.4 has been out already which among others fixes some of the bugs. Am I allowed to put this into frozen? It is my impression that this would not have been allowed during the previous code freeze. Brian has made some comments that lead me too believe he intends to be slightly less strict this time than during the previous one. Personally, I think that this question should be answered on a case by case basis, after deliberation between the maintainer(s) in question and the release engineer (and perhaps, the general developer community), depending on factors such as the feasibility of extracting just the desired bug fixes out of the new code, the amount of changes that aren't related to those bugfixes, the importance of the package, the (potential) impact on other packages, how long we're in the freeze etc. Ray -- UNFAIR Term applied to advantages enjoyed by other people which we tried to cheat them out of and didn't manage. See also DISHONESTY, SNEAKY, UNDERHAND and JUST LUCKY I GUESS. - The Hipcrime Vocab by Chad C. Mulligan
Re: Wrong dependencies for a single deb: How to reupload ?
On Fri, Oct 16, 1998 at 10:19:22AM +0200, Gregor Hoffleit wrote: Probably a pretty dumb question: dpkg-shlibdeps got the dependencies wrong for a single deb in the python package (tkstep8.0 instead of tk8.0). The package is already DONE; is it possible to reupload just that single python-tk with a fixed control file and the same revision, or do I have to reupload a complete new revision of all python packages ? The source is completely unchanged, only packed with a different configuration. I think it should have a new debian revision... The reason being that, then anyone who has the old version installed, will still properly get upgraded with apt, etc. -Steve -- /* -- Stephen Carpenter [EMAIL PROTECTED] --- [EMAIL PROTECTED] */ E-mail Bumper Stickers: A FREE America or a Drug-Free America: You can't have both! honk if you Love Linux
Re: gdselect alpha 3
On Thu, Oct 15, 1998 at 05:52:59PM -0600, Jason Gunthorpe wrote: Hmm, I think this is my first comment on this.. On Thu, 15 Oct 1998, Tom Lees wrote: On Wed, Oct 14, 1998 at 02:29:04PM -0700, Joey Hess wrote: Are there any plans to merge this with apt? Seems gdselect has the frontend, and apt has the backend. Well, I could do with some apt in-built dependency handling :) There isnt time before the freeze, and AFAIK there are no plans now (which means there are no plans now). I think this idea of 'lets quickly do something fast' is ill concieved and is ultimately going to hurt our image. I've looked at the latest version, it looks rather pretty, it's slightly more functional than dselect but that's about it.. It doesn't support any of the more sophisticated things that people are clamoring for, and it requires X, GTK and a wack of ram. But, it does answer an immediate need... dselect is now too unwieldy to use with the number of packages we have... apt is not ready. Compare it with the package pre-selections in hamm. They were quick and dirty, but they worked, and I believe they helped a lot of users in installation (they were useful last time I used them). The only idea is not lets quickly do something fast. I started playing around with a simple package browser about a month ago... that's where the base came from. Converting it into a fully-blown package selector is what I decided to do. The fact that it doesn't use the APT library only makes things worse as now it could have big bugs in odd places! ^^ Probably does have... but then APT isnt perfect either. I think the point is APT has had much more debugging, this hasn't. I agree, but I needed something to get it up off the ground quickly. It could now almost certainly be ported to libapt very quickly, whereas writing it to libapt in the first place would have been harder, especially considering I already had the basics done a while ago. Only problem is, apt is in C++, this is in C... So compile your code as C++, it's not hard, change the gcc call to g++ and rename the source files. Then you have to fix up a couple casts and some other things and presto, it's C++. You don't need to use gtk-- or anything else like that. Oh. In that case, I will redirect my efforts to this. Everything else is done, and I'm adding more UI features. In alpha3? Quick IRC survey shows that it locked one persons machine hard, takes huge amounts of ram+time and has randomly segfaulted for another... AFAIK, UI features aren't what cause these - its my q+d package lib. The UI features are very quick, IMHO cleanly coded, and I thought them out a lot. I also need to run it through a malloc debugger soon to check out some possible memory leaks/boundary probs. I belive Adam Heath has been investigating porting gdselect to libapt, perhaps you should talk to him. OK, good idea (he's CCd)... Adam, how far have you got? Maybe we should collaborate on this. I believe its probably not much effort to port to libapt - the main problem is the dependency screen bit. -- Tom Lees [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.lpsg.demon.co.uk/ PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkeys.asc.
Re: gdselect alpha 3
Quoting Manoj Srivastava ([EMAIL PROTECTED]): Michael == Michael Stone [EMAIL PROTECTED] writes: Michael Quoting Jason Gunthorpe ([EMAIL PROTECTED]): I think this idea of 'lets quickly do something fast' is ill concieved and is ultimately going to hurt our image. I've looked at the latest version, it looks rather pretty, it's slightly more functional than dselect but that's about it.. It doesn't support any of the more sophisticated things that people are clamoring for, and it requires X, GTK and a wack of ram. [snip] Michael Perhaps an incremental approach is good: a good gui for the Michael existing product in this release, other features in other Michael releases. Maybe apt will be better, but we haven't seen it Michael yet (referring to the UI). Apt's been in development for a Michael long time, maybe some friendly competition will help. And Michael why can't we have multiple UI's to the package management Michael system? This is linux: one size doesn't fit all. Competition is fine, let it get time to mature. The idea is simple: no new code after freeze. let this new system vie with apt at the next release. I didn't mean to argue that gdselect should necessarily ship now; by release I meant this release of gdselect. What I was trying to answer was an attitude that seemed to be saying we shouldn't do anything about dselect until we have a solution that not only provides a decent gui, but also everything else. (Which I took to mean automatic package dselection, superpackages, seamless x/tty transition, and everything else that apt is supposed to provide.) Some people just want a gui, and I think it's reasonable to provide it. It's not fair to compare gdselect with what apt is supposed to be, if for no other reason than that they're not trying to acheive the same goals. BTW, since I don't see how gdselect could be used on initial installation anyway, I don't think it would hurt to leave it off the cd's and make it available for download later. We can call it a beta or whatever, but those who want it could still use it. Mike Stone
Re: Removing Packages in Slink for Debian 2.1
Let's look a bit further at those bugreports.. balsa 27726 balsa cannot be run [0] ([EMAIL PROTECTED] (Ole J. Tetlie)) balsa 27894 balsa is linked against ancient version of gtk [0] ([EMAIL PROTECTED] (Ole J. Tetlie)) A new balsa has already been uploaded (0.4.6-1), I think that fixes these bugs. gnus 25609 Gnus: prerm script failure make it impossible to upgrade/pruge [64] (Michael Alan Dorman [EMAIL PROTECTED]) Removing that will make a _lot_ of people really angry I think.. htdig 25412 htdig: htdig ignores config file stuff/absolute pathnames compiled in [70] (Gergely Madarasz [EMAIL PROTECTED]) infocom 21478 infocom: Integrating infocom interpreters [175] (Brian White [EMAIL PROTECTED]) jdk1.127097 jdk1.1: error in installing jdk1.1: links are in a mess [18] (Stephen Zander [EMAIL PROTECTED]) jdk1.127330 jdk1.1: Files should be conffiles [12] (Stephen Zander [EMAIL PROTECTED]) jove 27219 jove: Jove wants /usr/tmp [14] (Loic Prylli [EMAIL PROTECTED]) junkbuster25258 junkbuster: junkbuster has security holes [74] (Paul Haggart [EMAIL PROTECTED]) kaffe 20980 kaffe: kaffe depends on jdk-common [186] () kdebase 23655 kdebase includes /etc/X11/Xsession [118] (Stephan Kulow [EMAIL PROTECTED]) kdebase 25903 kdebase doesn't include rights to distribute kvt [56] (Stephan Kulow [EMAIL PROTECTED]) kdebase 25974 kvt creates ~/.kde with root as owner and insane permissions [55] (Stephan Kulow [EMAIL PROTECTED]) kdegraphics 25627 kdegraphics violates copyright [63] (Stephan Kulow [EMAIL PROTECTED]) kdelibs0g 24643 kdebase: We have no licence to distribute KDE binaries when linked against Qt [90] (Stephan Kulow [EMAIL PROTECTED]) kdemultimedia 25628 kmultimedia violates copyright law (and debian policy) [63] (Stephan Kulow [EMAIL PROTECTED]) kdeutils 25630 kdeutils copyright problems [63] (Stephan Kulow [EMAIL PROTECTED]) Needles to these have been removed. knfs 27250 knfs (remote root exploit) [14] (Anders Hammarquist [EMAIL PROTECTED]) Is that actually in slink? It also has a security problem which has not been fixed yet, but I seem to remember knfs is still in experimental. mozilla 27181 mozilla dumps core [15] (Debian QA group debian-qa@lists.debian.org) That seems to be a problem with library versions: for some people mozilla works fine (for me for example), for others it dumps core on startup. We might want to investigate that further. netatalk 25598 netalk: several problems (and the solution) [64] (Joel Klecker [EMAIL PROTECTED]) Looking at the bugreporttitle there already is a solution, so removing this should not be necessary. pcmcia-modules-2 27395 pcmcia-modules are totally broken out of the box [11] (Brian Mays [EMAIL PROTECTED]) pcmcia-source 26657 pcmcia-source: Needs this patch to work on 2.1.118+ kernels [32] (Brian Mays [EMAIL PROTECTED]) 27395 is more of a local problem iirc, 26657 should be easy to fix, since the patch is already supplied. Besides, removing pcmcia will also break the boot-floppies, so we can't really remove these. strace26065 strace confused about sigaction flags [51] (Wichert Akkerman [EMAIL PROTECTED]) Let's keep this one :) yagirc24747 yagirc: Binary and Libs for yagirc stored in /bin and /lib [87] ([EMAIL PROTECTED] (David N. Welton)) yagirc has just switched maintainer and a new package was uploaded, so this might already have been fixed. Again, please let me know if you feel differently. If I don't hear otherwise, I'll be removing all of those packages in the list directly above to be removed from slink during the freeze. Note: the above lists are made directly from the bug logs. I haven't actually correlated them with the list of packages that actually exist. If a package listed above has already been removed from the distribution, don't worry about it. Again, I offer my help with the bugscripts, since my scripts do check if a package is still available. Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgpEh6eXRfyOI.pgp Description: PGP signature
Re: PROPOSAL: one debian list for all porting efforts
Agreed. To think otherwise is silly. As I am about to swith to Alpha, I have a conern: I maintain some dozen or so packages, currently under i386. There are people that go around compiling all the i386 stuff for the other archs. But nobody goes around compiling the stuff from the other archs for i386! So if I suddenly do all my package development on Alpha, the Alpha will have the current versions, and perhaps the Sparc and m68k too, but i386 will be obsolete! Fix anybody? John Joel Klecker [EMAIL PROTECTED] writes: At 12:30 +0200 1998-10-14, Paul Slootman wrote: On Mon 12 Oct 1998, Hartmut Koptein wrote: :-) debian/i386 is also a port! No. For 90% (I think more) of the packages it is the primary architecture. The word port implies carrying to _another_ architecture. Hence the package on the primary architecture is _not_ a port. To me it is a port, a port of Debian GNU/Linux. -- Joel Klecker (aka Espy) URL:mailto:[EMAIL PROTECTED]URL:http://web.espy.org/ Debian GNU/Linux user/developer on i386 and powerpc. URL:mailto:[EMAIL PROTECTED] URL:http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- John Goerzen Linux, Unix consulting programming [EMAIL PROTECTED] | Developer, Debian GNU/Linux (Free powerful OS upgrade) www.debian.org | + Visit the Air Capital Linux Users Group on the web at http://www.aclug.org
Re: Removing Packages in Slink for Debian 2.1
thread... == It's alpha software, but it's free and doesn't break your system. Let's ship it. If we are going to remove all packages which are buggy, we have to ship an empty CD ROM. Bug free software doesn't seem to exist per definition :) Who cares if Gnome is buggy? People who want to use it will use it, and find bugs and report them, they'll do some testing. We need to encourage testing. This is how the bazaar model works. As long as people don't expect it to work smoothly, there's no problem. == The debian CD's have had software marked alpha or beta in the past, (sometimes marked VERY alpha). So what's the problem with Gnome? (RedHat is shipping gnome). _ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com
Debian Emacs breaks GPL?
James Troup [EMAIL PROTECTED] wrote: Subject: Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs X-Mailing-List: debian-devel@lists.debian.org archive/latest/16743 [Want to know how Debian violates the GPL all the time? Check how many GPLed packages in Debian have modifications yet don't obey 2(a).] I think there should be a /usr/doc/emacs20/README.Debian what says that /usr/share/emacs/20.3/lisp/startup.el was modified to load debian-startup.el at startup. --- When I first switched to using a Debian-packaged emacs-20 in hamm (having always used my own build), I tried to figure out how the /etc/emacs/site-start.d/ stuff worked, and couldn't figure out what was loading debian-startup.el. It wasn't a site default.el, and there was nothing in /usr/doc/emacs20 specifically about it. The file /usr/doc/emacsen-common/debian-emacs-policy.gz describes how it all works, but not how emacs20 source code is modified to do it... So unless I missed something in the existing docs, I think there should be a /usr/doc/emacs20/README.Debian what says that /usr/share/emacs/20.3/lisp/startup.el was modified to load debian-startup.el at startup. Should I file a bug report against emacs20? This presumably applies to all favours of Emacs. -- Peter Galbraith, research scientist [EMAIL PROTECTED] Maurice Lamontagne Institute, Department of Fisheries and Oceans Canada P.O. Box 1000, Mont-Joli Qc, G5H 3Z4 Canada. 418-775-0852 FAX: 775-0546 6623'rd GNU/Linux user at the Counter - http://counter.li.org/
Re: gdselect alpha 3
On Fri, 16 Oct 1998, Michael Stone wrote: Michael Perhaps an incremental approach is good: a good gui for the Michael existing product in this release, other features in other Michael releases. Maybe apt will be better, but we haven't seen it Michael yet (referring to the UI). Apt's been in development for a Michael long time, maybe some friendly competition will help. And Michael why can't we have multiple UI's to the package management Michael system? This is linux: one size doesn't fit all. There was a feature on slashdot a while ago saying that projects that sit around and talk constantly never do anything. Ones that have someone just put up some code for the public to critique seem to be the fastest and the best. The code has been put up, now its our turn to suggest how it can be fixed/improved, not complain that it shouldn't be there at all. I didn't mean to argue that gdselect should necessarily ship now; by release I meant this release of gdselect. What I was trying to answer was an attitude that seemed to be saying we shouldn't do anything about dselect until we have a solution that not only provides a decent gui, but also everything else. (Which I took to mean automatic package dselection, superpackages, seamless x/tty transition, and everything else that apt is supposed to provide.) Some people just want a gui, and I think it's reasonable to provide it. It's not fair to compare gdselect with what apt is supposed to be, if for no other reason than that they're not trying to acheive the same goals. Perhaps this can encourage the apt maintainers to finalize how the different ui's interface with their libraries in a universal way. Since all they have had is the CLI, there may be some work to finish for this. BTW, since I don't see how gdselect could be used on initial installation anyway, I don't think it would hurt to leave it off the cd's and make it available for download later. We can call it a beta or whatever, but those who want it could still use it. I think sid is the place for this. When you are ready, you can move it to the current unstable. Brandon P.S. just looking at the screen shots, I think this is a really good thing. Bravo. --+-- Brandon Mitchell [EMAIL PROTECTED] | Debian Testing Group Status PGP Key: finger -l [EMAIL PROTECTED] | http://bhmit1.home.ml.org/deb/ Dijkstra probably hates me (Linus Torvalds, in kernel/sched.c)
Re: Sources consisting of multiple tarballs
On Fri, Oct 16, 1998 at 06:26:38PM +1000, Stuart Lamble wrote: On Sat, Oct 10, 1998 at 01:56:06PM +1000, Stuart Lamble wrote: Couldn't you extract the arch dep parts in different subdirectories and move them to the correct place in the debian/rules file just before building? So you would put all sources in one source package. I could do that, yes. The main problem is that, as far as I can tell, there are currently only i386 sources for the arch dependant stuff at the upstream site (the address for which I've misplaced.. d'oh..) Doing things this way would entail a new source package each time a new architecture is bootstrapped. Probably the cleanest way overall, though, when all's said and done.. and no doubt Guy (or whoever's currently maintaining the FTP archive) would be happy to assist with fixing source packages and the like. Thanks for the suggestion. Yes, you are right, but this is okay. A new source code release upstream requires a new source upload anyway (okay, if they distribute arch dep parts seperately, there is no real requirement for this, but I still think its the cleanest solution to consider the whole thing source and all arch dep parts as one source). If you don´t mind the additional upload (or two), this would be the best way to do it, IMHO. bye, marcus -- Rhubarb is no Egyptian god.Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Re: gdselect alpha 3
Manoj Srivastava wrote: Hi, Michael == Michael Stone [EMAIL PROTECTED] writes: Michael Quoting Jason Gunthorpe ([EMAIL PROTECTED]): I think this idea of 'lets quickly do something fast' is ill concieved an d is ultimately going to hurt our image. I've looked at the latest version, it looks rather pretty, it's slightly more functional than dselect but that's about it.. It doesn't support any of the more sophisticated things that people are clamoring for, and it requires X, GTK and a wack of ram. Michael But it answers the people who think dselect is ugly and Michael unintuitive and want something that runs under X. A quick and dirty answers is not really a good thing, don't you think? Competition is fine, let it get time to mature. The idea is simple: no new code after freeze. let this new system vie with apt at the next release. Since when have we considered scrapping quality just because people want something that ``looks pretty''? manoj If it's rather pretty and slightly more functional than dselect but that's about it... then include it! Please! What I need from dselect is more screen space, more pixels, a less crampled selection environment. It takes forver to navigate through dselect because of the sheer number of packages. It seems that gdselect would help a lot in this respect (I use 1600x1200 on X). -- Peter Galbraith, research scientist [EMAIL PROTECTED] Maurice Lamontagne Institute, Department of Fisheries and Oceans Canada P.O. Box 1000, Mont-Joli Qc, G5H 3Z4 Canada. 418-775-0852 FAX: 775-0546 6623'rd GNU/Linux user at the Counter - http://counter.li.org/
what is non-free in this license?
I may be clueless, but could someone explain to me why this license is automatic ticket to non-free? quote 6. Legal This software can be used freely for any purpose. It can be distributed freely, as long as it is not sold commercially without permission from Tomislav Uzelac [EMAIL PROTECTED]. However, including this software on CD_ROMs containing other free software is explicitly permitted even when a modest distribution fee is charged for the CD, as long as this software is not a primary selling argument for the CD. Building derived versions of this software is permitted, as long as they are not sold commercially without permission from Tomislav Uzelac [EMAIL PROTECTED]. Any derived versions must be clearly marked as such, and must be called by a name other than amp. Any derived versions must retain this copyright notice. /* This license is itself copied from Tatu Ylonen's ssh package. It does * not mention being copyrighted itself :) */ THERE IS NO WARRANTY FOR THIS PROGRAM - whatsoever. You use it entirely at your risk, and neither Tomislav Uzelac, nor FER will be liable for any damages that might occur to your computer, software, etc. in consequence of you using this freeware program. /quote -- Jakob Borg [EMAIL PROTECTED] [Debian GNU/Linux 2.0 narayan 2.1.125 i586] GCS/M d- s a?@ C++ ULSIU+++ P+++ L+++ E W+@ N++ !o K- w--- O-- M-- V PS+ PE- Y+ PGP++ t++@ 5+++ R- tv b+ DI++ D+ G++ h r++ y? pgph7i9buQtr0.pgp Description: PGP signature
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
Joey Hess [EMAIL PROTECTED] writes: Hartmut Koptein wrote: 1. binary-only NMUs breaks policity Probably. Wrong. -- James
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
Joey Hess [EMAIL PROTECTED] writes: If you're building foobar 1.1-3, do you really recompile from a freshly unpacked foobar_1.1-3.dsc? Yes. Congratulations; you're in the minority. Binary-only and normal NMU's are the same thing, No they're not. Why do you insist on this obvious falsehood? Um, how are they different? Are you trolling? As I've said 3 times already (at least): because they only affect one architecture. And because there are perfectly valid reasons to do binary-only NMUs (which you seem to want to ignore) [see my bash example in [EMAIL PROTECTED]]. I think I could dig up complaints form *you* saying that. That would be a cunning trick. -- James
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
Joey Hess [EMAIL PROTECTED] writes: Each day you autobuild say, 30 packages from Incoming. Building (especially auto-building) packages from Incoming is a bad idea, please don't encourage it. -- James
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
Joey Hess [EMAIL PROTECTED] writes: James Troup wrote: Who said [binary-only NMU's for i386] were bad? You did. No, I said binary-only NMUs as a whole were not ideal; I didn't say anything about binary-only NMU's for i386. Please try to stick to the facts. They are very rarely necessary however, since 99.5% of the time (the only exception I know of is Hartmut's packages) i386 packages are already compiled for i386 and don't need to be compiled by someone other than the maintainer. That's when binary-only-NMUs occur on non-i386. Plenty of people rebuild i386 stuff from scratch for various reasons. It's not even vaguely comparable to ports, because of the scale of the recompilation (so Lars and Johnie do the occasional auto-building, big deal.. it hardly compares to the constant building done by the 6 ports) and because if compiling from the source doesn't work on i386 there is always the binary to fall back on, which isn't the case for non-i386. [ snip remainder of flamage ] i.e. I can't actually respond to this, so I'll dismiss it as flames. Good effort. -- James
Re: Deleting uncompressed Info/Doc files at upgrades
I wrote: It occurs to me that upgrading a package should delete old versions of user-uncompressed doc and info files. Santiago Vila wrote: The package system is not supposed to read your mind. You should never uncompress files in place because then dpkg will be unable to remove the files which belong to a certain package when it is removed or replace by a new one. I wrote back: But... That was my point! Uncompressing docs or info is *not* unusual, nor should it be frowned upon. We should accommodate the possibility of that happening. The same way that a properly-configured Emacs will read-in a compressed file correctly, dpkg should treat an uncompressed file as the same and upgrade it. Craig Sanders wrote: no tool will ever be smart enough to cope perfectly with users leaving crud all over the disk. users should uncompress their files to /tmp or under /usr/local or some other more suitable location. if they choose to do otherwise, then they should accept the consequences of their actions and deal with it themselves. So, at least Craig Sanders and Santiago Vila are so engrained into Debian that they now think the original usable file is the gzip'ed one, not the author's original text. I disagree. Sure, dealing with uncompressed files on upgrade is a special case. Sure dpkg should have to be changed, or maybe /var/lib/dpkg/info/*.list file could have regular expressions, like: /usr/info/emacs-e20-2(.gz)? Mike Stone wrote: Hmm. We have zless to less gz'd files. You see, I didn't even know about that program! Magicfilter will print them, as will a2ps (maybe some others will too, haven't tried it.) Netscape reads them, so does lynx. And of course man and info work with them. zgrep will grep them. vim reads them just fine. I'm drawing a blank on things I can't do with .gz'd files... - A new user won't know about special setups needed for emacs, less and other program. - When I switched to Debian, I used ghostview and not gv for postscript (out of luck there too). - A new user may need the docs on a crippled system, or on a system with only the base system installed. - If you are using some docs often on a 486, you end up uncompressing them because it's too slow otherwise. I'm not arguing that dpkg should handle .aux files files behind after someone has latex'ed docs. I'm arguing that the `intent' of packaging a compressed file is to have the uncompressed original available on the system. Debian upgrades should therefore acknowledge the possibility that files have been decompressed. -- Peter Galbraith, research scientist [EMAIL PROTECTED] Maurice Lamontagne Institute, Department of Fisheries and Oceans Canada P.O. Box 1000, Mont-Joli Qc, G5H 3Z4 Canada. 418-775-0852 FAX: 775-0546 6623'rd GNU/Linux user at the Counter - http://counter.li.org/
Re: Debian Emacs breaks GPL?
On Fri, Oct 16, 1998 at 09:20:02AM -0400, Peter S Galbraith wrote: James Troup [EMAIL PROTECTED] wrote: Subject: Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs X-Mailing-List: debian-devel@lists.debian.org archive/latest/16743 [Want to know how Debian violates the GPL all the time? Check how many GPLed packages in Debian have modifications yet don't obey 2(a).] I think there should be a /usr/doc/emacs20/README.Debian what says that /usr/share/emacs/20.3/lisp/startup.el was modified to load debian-startup.el at startup. I agree that such notifications are useful. The question is, if we must enfore them and if yes, if they not better belong in the copyright file. let me point out that we distribute _pristine_ source packages in most cases, and a diff file makes very clear (byte by byte) which files have been changed. So, I think, if the maintainer uploads the original source unmodified, the changes don´t need to be listed in the Debian files, as the diff file is enough documentation. If the Debian maintainer repacks changed source code, the changes must be written down in the copyright file. Should I file a bug report against emacs20? This presumably applies to all favours of Emacs. please do not file bug reports before we have at least discussed it a bit. Maybe policy should be changed to the effect I proposed above. Marcus -- Rhubarb is no Egyptian god.Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Re: Secure Locate (findutils?)
[Cc'd to debian-devel and the findutils maintainer] In debian-devel, [EMAIL PROTECTED] wrote: Anyone give any thought to packaging Secure Locate 1.2? Yeah, I posted an intent to package about the same time you posted this. BTW, at least version 1.3 is out now. Is there any way to package this without it conflicting with the standard locate provided in findutils? It has to seamlessly replace both updatedb and locate. Then you can use dpkg's diversion features to properly shove them out of the way. Unfortunately it seamlessly replaces neither yet, and since dpkg isn't yet supposed to be able to properly divert configuration files, I can't touch /etc/updatedb.conf or /etc/cron.daily/find (even to make sure they don't run - who would want two locate databases?). So the only thing left for me to muck with is the updatedb script itself. I have contacted the upstream author and he's working to make slocate compatible with locate, however the updatedb end needs quite a bit of work. (slocate currently uses the same binary for indexing and searching!) updatedb is a good chunk of functionality to replace, considering it's a shell script. This seems like a much better way to enhance privacy without running updatedb as nobody and thus making users unable to 'locate' files in their own private directories. I concur :) I'd do this myself, but I haven't been accepted as a maintainer yet, findutils is part of the required base install which I'd rather not be resposible for breaking, and slocate might require some special permissions which could decrease security in a ways I haven't fully explored yet. It wants to be setgid slocate so it can read the slocate db. If a user can exploit slocate they get to read the database. The database is actually owned by root, and I'll need to make sure the directory it's in is as well. I made a suggestion to the upstream author about storing the databases in separate files, owned by whoever should be able to read them (yeah, one for each uid), so nothing would have to be set[ug]id. He never commented on it. -- Robert Woodcock - [EMAIL PROTECTED] Unix and C are the ultimate computer viruses -- Richard Gabriel
Re: gdselect alpha 3
On Fri, Oct 16, 1998 at 09:48:18AM -0400, Peter S Galbraith wrote: Manoj Srivastava wrote: Hi, Michael == Michael Stone [EMAIL PROTECTED] writes: Michael Quoting Jason Gunthorpe ([EMAIL PROTECTED]): I think this idea of 'lets quickly do something fast' is ill concieved an d is ultimately going to hurt our image. I've looked at the latest version, it looks rather pretty, it's slightly more functional than dselect but that's about it.. It doesn't support any of the more sophisticated things that people are clamoring for, and it requires X, GTK and a wack of ram. Michael But it answers the people who think dselect is ugly and Michael unintuitive and want something that runs under X. A quick and dirty answers is not really a good thing, don't you think? Competition is fine, let it get time to mature. The idea is simple: no new code after freeze. let this new system vie with apt at the next release. Since when have we considered scrapping quality just because people want something that ``looks pretty''? manoj If it's rather pretty and slightly more functional than dselect but that's about it... then include it! Please! What I need from dselect is more screen space, more pixels, a less crampled selection environment. It takes forver to navigate through dselect because of the sheer number of packages. It seems that gdselect would help a lot in this respect (I use 1600x1200 on X). So... shall I release it using my pkg code (takes lots of memory, blah, blah, blah, but it works, and its written), or apt's class system? I now think its too silly to try to include it in the slink freeze; I will upload it to unstable after the freeze has happenned. However, making a note of it on the Debian web pages might not be such a bad idea. -- Tom Lees [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.lpsg.demon.co.uk/ PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkeys.asc.
Re: Debian Emacs breaks GPL?
[EMAIL PROTECTED] wrote: [Want to know how Debian violates the GPL all the time? Check how many GPLed packages in Debian have modifications yet don't obey 2(a).] I think there should be a /usr/doc/emacs20/README.Debian what says that /usr/share/emacs/20.3/lisp/startup.el was modified to load debian-startup.el at startup. I agree that such notifications are useful. The question is, if we must enfore them and if yes, if they not better belong in the copyright file. let me point out that we distribute _pristine_ source packages in most cases, and a diff file makes very clear (byte by byte) which files have been changed. So, I think, if the maintainer uploads the original source unmodified, the changes don´t need to be listed in the Debian files, as the diff file is enough documentation. If the Debian maintainer repacks changed source code, the changes must be written down in the copyright file. Very good point about diff files. I hadn't thought of that. However, including said changes in either copyright or README.Debian would be a good service to users who typically don't look at diff's (most new users don't know the workings of Debian's packaging system anyway) and would better comply with GPL Section 2a. I think that Debian policy hints that such modifications should be listed in the `copyright' file, but I've always thought it more natural that they go in README.Debian (which is why I looked there when I was a new user, and din't know Debian policy). Peter
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
On Fri, Oct 16, 1998 at 02:54:53PM +0100, James Troup wrote: Joey Hess [EMAIL PROTECTED] writes: snip Are you trolling? As I've said 3 times already (at least): because they only affect one architecture. And because there are perfectly valid reasons to do binary-only NMUs (which you seem to want to ignore) [see my bash example in [EMAIL PROTECTED]]. If the changes break the other architectures then the changes are BROKEN, learn how not to do it, simple.. We all make mistakes, its a fact of life, and there are some RARE cases where a binary only NMU is needed, however they are the EXCEPTION, not the rule.. Basicly, your argument of it only affecting one architectures is bogus, if your worried about your changes not working on other architectures then go over to master and compile it, if you need testers go over to #debian and ASK, if I'm there (nick Mercury, idle a LOT) and I use the package I'll test it for 80x86, so in the end, give one GOOD reason why they should be the norm, and the only affecting one architecture is not a good reason.. Zephaniah E, Hull.. -- I think I could dig up complaints form *you* saying that. That would be a cunning trick. -- James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] pgpmP9YnPAu2w.pgp Description: PGP signature
Re: octave-plplot: intention to package
Hi, I agree with the enclosed copyright notice. Octave's author also has no objections. Please correct, if still possible, my e-mail address: [EMAIL PROTECTED]> Thanks, Joao Rafael Laboissiere wrote: Ola Joao, Thanks for your prompt reply. > "JC" == Joao Cardoso [EMAIL PROTECTED]> writes: JC> I know nothing about copyrights, so I include none in the JC> sources. My intention is that plplot_octave could be available JC> in a future release of Octave, if Octave's author wants to. If JC> including it in a Debian release disallows my intention, than I JC> would not approve it. Absolutely, inclusion in the Debian distribution will _not_ prevent any inclusion of the plplot_octave interface into a future release of Octave. One of my intentions in packaging it for Debian is to give more visibility to your great software (as well as to PLplot itself), such that development can be speeded up. A better plotting interface is really needed for Octave at present. JC> As I told before, my intention is to enable it to be used as JC> Octave is, with a GNU General Public License (which I have never JC> fully read :-)) . If you want to add/include in all modified JC> sources or scripts the GNU licence header, I will be happy (if JC> this is still possible after I have put the package JC> un-intentionally in the public domain). It is too much work to do that, and as it is getting colder and colder (slink freeze is imminent) I just changed the copyright file to satisfy your desire. I am attaching the modified copyright below. Debian developers: do you think that this is acceptable? JC> Anyway, I already have latter versions, but they are not JC> packaged for public usage. Great. They will appear in Debian 2.2 (or 3.0?). -- Rafael Laboissiere Institut de la Communication Parlee | Email: [EMAIL PROTECTED] UPRESS A CNRS 5009 / INPG | Voice: +33 4.76.57.48.49 46, av. Felix Viallet | Fax: +33 4.76.57.47.10 F-38031 Grenoble CEDEX 1 France | URL: http://www.icp.inpg.fr/~rafael = /usr/doc/octave-plplot/copyright This package was debianized by Rafael Laboissiere [EMAIL PROTECTED] on Thu, 15 Oct 1998 14:20:19 +0200. This package was built from a tarball sent by Joao Cardoso [EMAIL PROTECTED]> to the octave-sources mailing list (see the announcement in http://www.che.wisc.edu/octave/mailing-lists/octave-sources/1998/5). Copyright: The files in the source distribution have no copyright notice, but by explicit request from the author, the following terms apply: Copyright (C) 1998 Joao Cardoso. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. [In Debian systems, see file /usr/doc/copyright/GPL.] This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. Many files under /usr/share/octave/site/m/PLplot have the following line: ## Copyright (C) 1996 John W. Eaton and were released under the GPL. They were modified by Joao Cardoso and are assumed to be released under the same licencing terms. -- Joao Cardoso | e-mail: [EMAIL PROTECTED] INESC, R. Jose Falcao 110 | tel: + 351 2 2094322 4050 Porto, Portugal | fax: + 351 2 2008487
apache-ssl 1.3.3+1.27-1 depends on libssl09
...and as of yet, no libssl09 on non-us.debian.org. (there's a 180 day old bug report on this one) -Thomas
