Re: Debian 2.0 CDs back in place on ftp1
Johnie Ingram writes: 620062720 Jun 3 13:30 CD0/Debian-i386-2.0-980603-1730Z.iso So main+contrib finally fits on 1 CD ? 335355904 Jun 3 11:16 CD1/Debian-misc-2.0-980603-1516Z.iso Could you give a brief description of what this misc CD is ? Thanks, -- Yann Dirson [EMAIL PROTECTED] | Stop making M$-Bill richer richer, alt-email: [EMAIL PROTECTED] | support Debian GNU/Linux: debian-email: [EMAIL PROTECTED] | more powerful, more stable ! http://www.a2points.com/homepage/3475232 | Check http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
intent to package vmailer
I intend to package VMailer (Wietse Venema's mail transport agent, see http://www.porcupine.org/vmailer). In keeping with Wietse's desires, the package will not be available until he releases it... LaMont Jones -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New Project: COPYRIGHT HOWTO.
Some time around 03 Jun 1998 23:25:12 +0200, Jens Ritter wrote: Hallo all, as a lot of us developers have to deal with copyright problems, I would like to start this (hopefully) littly project. I would like to write a COPYRIGHT HOWTO, which might be send to authors of software, which a) do not state what copyright is associated with their software and b) who do not use a free (enough) license. This is a very good idea. Don't forget to take a look at http://www.debian.org/intro/free.html . This is an excellent introduction to freeness/licensing and it has some of the information you are trying to gather. I've been using it in my conversations about copyright with non-free software authors. -- Proudly running Debian Linux! Linux vs. Windows is a no-Win situation Igor Grobman [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Debian Bazaar Politics (was: Debian Re-organization proposal)
I just split the subject of the previous to take more about politics in Debian and let people discuss about the proposal. I think we too much mess up with wordin like democracy and government. Debian are neither. It's a bunch of volunteers trying to work together. If voting let you think it's a democracy, don't be foul. It's a really an officialisation of a concensus. Debian needs it to ensure that's it's not only the big talker who leads, and loose all the silent majority of developpers. Voting is not need for submitting decisions, discussing about it or deciding who's working on what. Debian already works correctly for most of the Decision making process. Ideas are submit, discussed and most of the time, something came out [may be I'm a little optimistic here, but see apt, see the quality of the distribution. We are the only one who really supports that much features and without being paid for!] The problems came when it's time to put it out to the world. Are we sure that everybody agreed? Will we loose all ours maintainers by doing the move? Having a leader it's the easy solution. Whatever he decided, we can always blame it if it's not right. And I'm sure you'll do it! Even for petty thing like the Blue Eye Captain. The SPR are the solution proposes by Ian for helping thing a little. By this mean,he intents to ensure that everybody could talk even about subject it even doesn't have time to heard before. I'm pretty sure that most of the vote taken will be a big yes with no compromise. I think we are a little more than whatever cat crowd Bruce deems to call us when in his bad mood. I think we can recognize wise decision as a crowd and, contrarely to the common tought, us IQ aren't the lesser IQ of all of us divided by the number of people. If this was right, Debian will be the worst distribution in the World. We are an example. We do the Bazaar all the way. We should be proud about it. Not even red hat or slackware want to deal with so a big goal as we do in Debian [eh, we triple the number of package and support not two or three but four architectures!] Debian is still an example, and for now, we just try to solve the normal organisational problem it's happen, I mean ensuring that an idea wasn't lost in the under the normal mess of any bazaar. [sorry about my english, it's the first I try myself on something that's complicated in englis :) ] -- Fabien Ninoles Running Debian/GNU Linux E-mail:[EMAIL PROTECTED] WebPage: http://www.callisto.si.usherb.ca/~94246757 WorkStation [available when connected!]: http://nightbird.tzone.org/ RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Bazaar Politics (was: Debian Re-organization proposal)
Fabien Ninoles [EMAIL PROTECTED] writes: I just split the subject of the previous to take more about politics in Debian and let people discuss about the proposal. I think we too much mess up with wordin like democracy and government. Debian are neither. It's a bunch of volunteers trying to work together. Yes. Debian already works correctly for most of the Decision making process. Ideas are submit, discussed and most of the time, something came out Yes. We are an example. We do the Bazaar all the way. We should be proud about it. Not even red hat or slackware want to deal with so a big goal as we do in Debian [eh, we triple the number of package and support not two or three but four architectures!] Debian is still an example, and for now, we just try to solve the normal organisational problem it's happen, I mean ensuring that an idea wasn't lost in the under the normal mess of any bazaar. What he said! Seriously people, don't get too psyched out by missing a release deadline. Every project struggles to meet release deadlines, every project occasionally fails. Especially when a major system-wide change is made, like libc6. And the nature of release engineering is such that the further you fall behind the harder it is to get the release out. Really, don't jump to conclusions like Debian obviously can't continue the way it's been going. We screwed up once. We should keep that in mind next time a deadline looms or release requirements start getting overambitious. greg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: About the Hamm Freeze (!)
On Tue, May 12, 1998 at 11:36:14AM -0400, Brian White wrote: The freeze of Hamm is about to become much more solid. The installation has been determined to be stable and now testing is proceeding to the individual packages. This will start with the testing of those marked essential and work on down to those marked standard. Packages marked optional or extra will not be tested (beyond installation) by the testing group unless they are given more time simply because not all the release-necessary bugs have been fixed. I was told that dselect has problems with hamm being distributed on more than one cd rom. Ian Jackson suggested that we should take a look at dpkg-mountable. This means that a) dpkg-mountable might need to be included in the boot floppies and b) we'll need at least one another set of boot floppies - or someone invents a different method for this. This is based on the idea that only packages up to a certain priority are included on the first cdrom and lower priorities are distributed through the second one. dark: Could you run your script that checks each priority for completeness? (don't depend/... on packages of lower priority) Regards, Joey -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / / http://home.pages.de/~joey/ / VFS: no free i-nodes, contact Linus -- finlandia, Feb '94 / pgpYE389mo4RR.pgp Description: PGP signature
Re: About the Hamm Freeze (!)
On Fri, Jun 05, 1998 at 12:14:33AM +0200, Martin Schulze wrote: On Tue, May 12, 1998 at 11:36:14AM -0400, Brian White wrote: The freeze of Hamm is about to become much more solid. The installation has been determined to be stable and now testing is proceeding to the individual packages. This will start with the testing of those marked essential and work on down to those marked standard. Packages marked optional or extra will not be tested (beyond installation) by the testing group unless they are given more time simply because not all the release-necessary bugs have been fixed. I was told that dselect has problems with hamm being distributed on more than one cd rom. Ian Jackson suggested that we should take a look at dpkg-mountable. This means that a) dpkg-mountable might need to be included in the boot floppies and b) we'll need at least one another set of boot floppies - or someone invents a different method for this. I plan to upload boot-floppies 2.0.7 next week, to fix some remaining bugs. I will include dpkg-mountable in the base system for that set. -- Enrique Zanardi[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: advantage of new kernel 2.0.34
Previously Miquel van Smoorenburg wrote: Well, our news server (Diablo, #threehundredsomething in the top1000) crashed regulary with all the 2.0.x kernels but with the later 2.0.34pre kernels it has been rock-stable. 2.0.33 regulary hangs on newer Intel chipsets. I installed Debian on a friend's computer a week ago and the system would always hang within the hour. Installing 2.0.34pre16 fixed everything. Furthermore, 2.0.34 fixes a lot of security problems, not all of which are in the Debian 2.0.33 package IIRC. IMHO we really should put 2.0.34 in hamm. It's already been stress-tested by a lot of people, so it shouldn't be a risk for us. 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/ pgpaxhR4imNHu.pgp Description: PGP signature
Advice for release critical bug (WAS: Bug#22942: libpaper depends on libpaperg)
Hi! Recently, Santiago opened a bug against libpaper. This is one of the RELEASE CRITICAL bugs, and we were not able to find a satisfactory solution. Hopefully, you have some useful suggestion... Here is the history: On Thu, 28 May 1998, Santiago Vila wrote: Subject: Bug#22942: libpaper depends on libpaperg I think there is not (or there should not be) anything in libpaper to make it to depend on libpaperg. I'm tagging this bug as important because the upgrade will be smoother having this bug fixed (users should be able to upgrade libraries from oldlibs before installing any other libc6 library). The problem is that libpaper does not provide just the library, but also a pair of executables (paperconf and paperconfig). A package that depends on libpaper can use both the library and the executables. When i had to provide both the libc5 and the libc6 version of the package, i decided to put the binaries only in the libc6 (i.e., libpaperg). The libc5 package (libpaper) should however depend on the libc6 package, to assure that the packages depending on libpaper can use the executables.[1] It is not possible to put the executables in both packages: the packages would conflict, and this is not good, since it can be required to have both the libc5 and the libc6 versions of a library installed. It is also not possible to put the executables in both packages AND to put in libpaperg a Replaces: libpaper (or vice-versa), since in this case it is possible to end with libpaper installed but without the executables (1- install libpaper; 2- install libpaperg; 3- remove libpaperg). The possible solutions are: SOLUTION 1 (Suggested by Wichert) - Create the packages: libpaper - the old libc5 library. May suggest libpaper-bin. libpaperg - the new libc6 library. May suggest libpaper-bin. libpaper-bin - the binariesmanpages. Depend on libpaperg Here the problems are that we do not guarantee, by installing libpaper, that the executables are present in the system. OTOH, by making libpaper depend on libpaper-bin, the installation of libpaper would also force the installation of libpaperg, which is what we wanted to avoid. Moreover, one on the executables (paperconfig) is used in the postinst of libpaper to configure the library; if the executables do not appear in the libpaper package, it is not possible to call paperconfig in the postinst, so a different way to initialize the library should be used (for instance, a subset of paperconfig should be included in the postinst). SOLUTION 2 -- Create the packages: - libpaper: man pages + binaries + libc5-libraries in /usr/lib/libc5-compat; does NOT depend on libpaperg - libpaperg : man pages + binaries + libc6-libraries; conflicts with libpaper - libpaper-oldlib : only the libc5-libraries in /usr/lib/libc5-compat; depends on libpaperg, conflicts with libpaper, provides libpaper When using only the libc5 libraries, it is sufficient to install the new version of libpaper; when you want to install also libpaperg, you have to replace libpaper with libpaper-oldlib. In this way, however, there would be two versions of the libc5 packages and the situation is not exactly clean. SOLUTION 3 -- Well, we can also decide that to leave the situation as it is. In this way, however, users would not be able to install the new version of the library without also installing libpaperg (and libc6...) Any comment and help is welcome! Thank you, Marco Pistore (libpaper maintainer) - [1] There is also another reason to make libpaper depend on libpaperg: these two packages share a config file. However, this file is not part of the package, but is created in the postinst and removed in the postrm, in case of purge. The config file should be removed only when both libpaper and libpaperg are purged, and this can be easily guaranteed in the postrm scripts. So, in my opinion, it should not be too difficult to solve _this_ problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Advice for release critical bug (WAS: Bug#22942: libpaper depends on libpaperg)
SOLUTION 3 -- Well, we can also decide that to leave the situation as it is. In this way, however, users would not be able to install the new version of the library without also installing libpaperg (and libc6...) That isn't the real problem, but the upgrade from an old system (e.g. bo). The libc6 version libpaperg surely conflicts with older versions of libpaper, where the libs weren't installed to /usr/lib/libc5-compat yet. So to upgrade, the user has to: - Install a new libpaper before libpaperg (due to conflict) - Install libpaperg before libpaper (due to dependency) Obviously, this is Catch-22 :-) The only remedy is to remove the old libpaper, and then to install libpaper and libpaperg. I guess apt will do something like this, and dftp can handle those cases, too. But dselect surely not :-) In any case, it's unconvenient and not obvious to the average user. Additionally, you loose your paper config in the process. SOLUTION 1 (Suggested by Wichert) - Create the packages: libpaper - the old libc5 library. May suggest libpaper-bin. libpaperg - the new libc6 library. May suggest libpaper-bin. libpaper-bin - the binariesmanpages. Depend on libpaperg Here the problems are that we do not guarantee, by installing libpaper, that the executables are present in the system. OTOH, by making libpaper depend on libpaper-bin, the installation of libpaper would also force the installation of libpaperg, which is what we wanted to avoid. Yep. Such a dependency would reintroduce the problem we wanted to fix. But I think this alternative is the only one that fix the problem really, so I'd vote for it. Moreover, one on the executables (paperconfig) is used in the postinst of libpaper to configure the library; if the executables do not appear in the libpaper package, it is not possible to call paperconfig in the postinst, so a different way to initialize the library should be used (for instance, a subset of paperconfig should be included in the postinst). I don't know what paperconfig exactly does now, but the idea of replacing the call to it by some simple script can do the job. Additionally you should recommend libpaper-bin, in whose postinst paperconfig can be called. Roman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Advice for release critical bug (WAS: Bug#22942: libpaper depends on libpaperg)
Roman Hodek [EMAIL PROTECTED] writes: SOLUTION 3 -- Well, we can also decide that to leave the situation as it is. In this way, however, users would not be able to install the new version of the library without also installing libpaperg (and libc6...) That isn't the real problem, but the upgrade from an old system (e.g. bo). The libc6 version libpaperg surely conflicts with older versions of libpaper, where the libs weren't installed to /usr/lib/libc5-compat yet. So to upgrade, the user has to: - Install a new libpaper before libpaperg (due to conflict) - Install libpaperg before libpaper (due to dependency) Obviously, this is Catch-22 :-) The only remedy is to remove the old libpaper, and then to install libpaper and libpaperg. Where *did* you get this idea from? It's 200% bogus. | 14:19:[EMAIL PROTECTED]| ~/temp $dpkg -l libpaper | tail +6 | ii libpaper1.0.3-3Library for handling paper characteristics [ ^^ This is bo's ] | 14:20:[EMAIL PROTECTED]| ~/temp $sudo dpkg -iEG libpaper_1.0.3-9.deb libpaperg_1.0.3-9.deb | (Reading database ... 34403 files and directories currently installed.) | Preparing to replace libpaper 1.0.3-3 (using libpaper_1.0.3-9.deb) ... | Unpacking replacement libpaper ... | Selecting previously deselected package libpaperg. | Unpacking libpaperg (from libpaperg_1.0.3-9.deb) ... | Setting up libpaperg (1.0.3-9) ... | | Setting up libpaper (1.0.3-9) ... | | 14:20:[EMAIL PROTECTED]| ~/temp $ [ You can even do it the other way round, albeit with two dpkg runs ] [ We've had this discussion before about xview ] Additionally, you loose your paper config in the process. Additionally, you so *don't*. The config file is a config file enough that it's only removed on purge not remove (not that the remove is necessary as you claim). -- James ~Yawn And Walk North~ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: advantage of new kernel 2.0.34
So, where do I find the source? Helsinki only has 2.0.33? On Fri, 5 Jun 1998, Wichert Akkerman wrote: Previously Miquel van Smoorenburg wrote: Well, our news server (Diablo, #threehundredsomething in the top1000) crashed regulary with all the 2.0.x kernels but with the later 2.0.34pre kernels it has been rock-stable. 2.0.33 regulary hangs on newer Intel chipsets. I installed Debian on a friend's computer a week ago and the system would always hang within the hour. Installing 2.0.34pre16 fixed everything. Furthermore, 2.0.34 fixes a lot of security problems, not all of which are in the Debian 2.0.33 package IIRC. IMHO we really should put 2.0.34 in hamm. It's already been stress-tested by a lot of people, so it shouldn't be a risk for us. 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/ Dwarf -- _-_-_-_-_- Author of The Debian Linux User's Guide _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: advantage of new kernel 2.0.34
According to Dale Scheetz: So, where do I find the source? Helsinki only has 2.0.33? I downloaded 2.0.34 from ftp.funet.fi yesterday morning (the patch that is, I did not check to see if a complete kernel was there). You can also find a copy of the 2.0.34 patch on ftp://ftp.linux.org.uk/pub/linux/linux-2.0/ ftp://ftp.cistron.nl/pub/linux/kernel/v2.0/ Mike. -- Miquel van Smoorenburg | Our vision is to speed up time, [EMAIL PROTECTED] | eventually eliminating it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intent to fix base-passwd
Hi, sorry for being such a nuisance :-/ On Wed, Jun 03, 1998 at 11:20:52PM +0200, Christian Meder wrote: On Wed, Jun 03, 1998 at 10:18:40AM +0100, James Troup wrote: Christian Meder [EMAIL PROTECTED] writes: while testing the base packages I hit the critical bugs surrounding the update-passwd binary contained in base-passwd. Uh, which critical bugs? --sanity-check now works as expected, is run by default and update-passwd is no longer run automatically, it has to be run by the user if it is to be used. Ok. So 19839, 19946 and the related passwd bug 21275 should be considered fixed ? James, you downgraded 19839 and 19946. Could you downgrade 21275 as well ? I agree totally. My only remaining concern is the fact that update-passwd was intended as helper utility to keep passwd/group uptodate but it's still somewhat broken. passwd/group are no conffiles anymore. Everybody who upgrades won't notice that passwd/group have changed because the usual 'want to keep your version of conffile'-kind of dialog won't happen anymore. update-passwd isn't run by default, too. The majority of systems will keep their bo-passwd/group files because the users aren't notified that passwd/group have changed. I checked the diff: msql, gnats and amanda will be affected (msql entry missing, gnats entry wrong and backup entry wrong). Suggestions what to do ? Still an open question how to notify the users during upgrade. Greetings, Christian -- Christian Meder, email: [EMAIL PROTECTED] What's the railroad to me ? I never go to see Where it ends. It fills a few hollows, And makes banks for the swallows, It sets the sand a-blowing, And the blackberries a-growing. (Henry David Thoreau) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Documentation/License freeness (what RMS says about it) [rms@santafe.edu: Re: GPL itself non-free]
Hello! This is thereply I got from RMS about the copyright freeness issue. I think it is clear that we should lay the license freeness issue ad acta. Debian should include all licenses in whole, and the dfsg should not exactly apply to them. Note that we require the dfsg-freeness for the benefit of the free software community. It is a catalog of the minimum rights we need to improve software even without the authors agreement. We have no real benefit of dfsg-free licenses. Comments? Marcus - Forwarded message from Richard Stallman [EMAIL PROTECTED] - Return-path: [EMAIL PROTECTED] Envelope-to: [EMAIL PROTECTED] Delivery-date: Fri, 5 Jun 1998 15:17:31 +0200 Received: from localhost (mailhost.rz.ruhr-uni-bochum.de) [127.0.0.1] (root) by localhost with esmtp (Exim 1.92 #1 (Debian)) id 0yhwN9-0006PS-00; Fri, 5 Jun 1998 15:17:31 +0200 Delivered-To: [EMAIL PROTECTED] Received: (qmail 22069 invoked from network); 5 Jun 1998 03:15:56 - Received: from sfi.santafe.edu (192.12.12.1) by mailhost.rz.ruhr-uni-bochum.de with SMTP; 5 Jun 1998 03:15:56 - Received: from wijiji.santafe.edu by sfi.santafe.edu (4.1/SMI-4.1) id AA08441; Thu, 4 Jun 98 21:11:10 MDT Received: by wijiji.santafe.edu (SMI-8.6/SMI-SVR4) id VAA28436; Thu, 4 Jun 1998 21:11:09 -0600 Date: Thu, 4 Jun 1998 21:11:09 -0600 Message-Id: [EMAIL PROTECTED] From: Richard Stallman [EMAIL PROTECTED] To: [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] (message from Marcus Brinkmann on Thu, 4 Jun 1998 00:54:49 +0200) Subject: Re: GPL itself non-free Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] It seems to imply, that I'm not allowed to derive a new license, using portions of the GPL (even when changing the name). Is that correct? Yes and no. There is a legal principle (in the US at least) that copyright cannot restrict what license terms you use. So if you want a license which has legal wording somewhat similar to the GNU GPL, but somewhat different, you can write one. However, it shouldn't be similar to the GPL in other respects; only in the actual legal wording that implements the desired effect. Is it allowed to say copyright is GPL, except that you ...(additional clauses, for example the right to link with some commercial libraries), when the GPL is included as a whole? You can get that result, but not in precisely the way you have stated it. What you need to do is the following: You can distribute this program under the terms of the GNU General Public License... In addition, we give permission to link this file with other libraries under the following conditions... But please think twice before you do this! In some cases--such as, when your program is a library--this will not do any great harm. The FSF has used this method with libgcc.a (part of GCC) and in Guile, for example. But if you do this for an application program, and if your program needs a non-free library in order to function, then it will suffer the KDE problem--it will be off limits to free operating systems because we cannot include the non-free library in them. If you decide at the outset not to use the non-free library, that may take some extra work--but the result will be a program we can use! - End forwarded message - -- Rhubarb is no Egyptian god.Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: About the Hamm Freeze (!)
Martin Schulze wrote: dark: Could you run your script that checks each priority for completeness? (don't depend/... on packages of lower priority) http://master.debian.org/~dark/lintian/reports/depcheck.html#i386 :-) It's generated daily. I was going to announce it together with a number of other lintian changes, but it seems that's going to take a while. Richard Braakman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: About the Hamm Freeze (!)
Richard Braakman [EMAIL PROTECTED] wrote: http://master.debian.org/~dark/lintian/reports/depcheck.html#i386 :-) Looks like libstdc++2.8 and libgdbmg1 should be required, and that dpkg-dev, dpkg-perl, and libnet-perl should be standard. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: About the Hamm Freeze (!)
Raul Miller [EMAIL PROTECTED] writes: Looks like libgdbmg1 should be required, [ ... ] No; perl shouldn't depend on libgdbmg1. libgdbmg1 is obsolete and deprecated. I asked the perl maintainer if he could fix this back in March or so, apparently it hasn't happened. -- James ~Yawn And Walk North~ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: About the Hamm Freeze (!)
James Troup [EMAIL PROTECTED] wrote: No; perl shouldn't depend on libgdbmg1. libgdbmg1 is obsolete and deprecated. I asked the perl maintainer if he could fix this back in March or so, apparently it hasn't happened. This close to hamm's release, we should probably rely on non-maintainer fixes for most outstanding problems (if we can get a maintainer release that's better, of course). -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On holiday next week
I'm going on holiday until the 15th, feel free to make NMU of any packages I maintain for hamm (and slink if it's really that urgent). None have important bugs outstanding AFAIK. Cheers Adrian email: [EMAIL PROTECTED], http://www.poboxes.com/adrian.bridgett Windows NT - Unix in beta-testing. PGP key available on public key servers Debian Linux http://www.debian.org The superior Linux distribution -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Documentation/License freeness (what RMS says about it) [rms@santafe.edu: Re: GPL itself non-free]
On Fri, 5 Jun 1998, Marcus Brinkmann wrote: Hello! This is thereply I got from RMS about the copyright freeness issue. I think it is clear that we should lay the license freeness issue ad acta. Debian should include all licenses in whole, and the dfsg should not exactly apply to them. The DFSG does not speak to the freeness of licenses. It only speaks to the freeness of software. Note that we require the dfsg-freeness for the benefit of the free software community. It is a catalog of the minimum rights we need to improve software even without the authors agreement. We have no real benefit of dfsg-free licenses. And much potential damage to the freeness of the software could result in freeing the copyright/license. The license is empowered by the inviolate nature of the copyright. The freeness of that license can only be insured by the unmodifiability of both the copyright and the license. In case I have been confusing, I am in total agreement with your statements on this issue. Waiting is, Dwarf -- _-_-_-_-_- Author of The Debian Linux User's Guide _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#22942: Advice for release critical bug (WAS: Bug#22942: libpaper depends on libpaperg)
On Fri, 5 Jun 1998, Marco Pistore wrote: [libpaperg contains binaries also needed by libpaper - libpaper depends on libpaperg, which is undesired] The possible solutions are: SOLUTION 1 (Suggested by Wichert) - Create the packages: libpaper - the old libc5 library. May suggest libpaper-bin. libpaperg - the new libc6 library. May suggest libpaper-bin. libpaper-bin - the binariesmanpages. Depend on libpaperg [snip] SOLUTION 2 -- Create the packages: - libpaper: man pages + binaries + libc5-libraries in /usr/lib/libc5-compat; does NOT depend on libpaperg - libpaperg : man pages + binaries + libc6-libraries; conflicts with libpaper - libpaper-oldlib : only the libc5-libraries in /usr/lib/libc5-compat; depends on libpaperg, conflicts with libpaper, provides libpaper [snip] SOLUTION 3 -- Well, we can also decide that to leave the situation as it is. In this way, however, users would not be able to install the new version of the library without also installing libpaperg (and libc6...) SOLUTION 4 Let the programs be in both packages, but use dpkg's diversions to move away the libc5 binaries when libpaperg is installed and remove the diversions on remove of libpaperg. Only drawback: a little (?) waste of hard drive space. See 'dpkg-divert --help' for help. I couldn't find a man page for it. [1] There is also another reason to make libpaper depend on libpaperg: these two packages share a config file. However, this file is not part of the package, but is created in the postinst and removed in the postrm, in case of purge. The config file should be removed only when both libpaper and libpaperg are purged, and this can be easily guaranteed in the postrm scripts. So, in my opinion, it should not be too difficult to solve _this_ problem. If this problem can be solved, I propose to use mu solution (#4). Remco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Problems with the undead (zombies)
I was hacking around on xfstt earlier today. I decided that it was too limited in that it would only accept 1 simultaneous connection (ie for each xfstt you run you can only have 1 session of X using it as a font path) so I decided to see if I could make it accept multiple connections... This turned out to be almost trivial...simply a few mods, instead of servicing requests after connect, it fork()s and lets the child service that connection while the parent loops and waits fo rthe next connect. [I think I changed 10 lines of code total] This SEEMS to work fine (I havn't really given it a good test -YET) except when I connect and then disconnect...the child exists (via _exit(0)) after the client disconnects. The problem is that the child then become a zombie. The zombie does go away when I kill xfstt...unfortunatly that is not a great solution (for obvious reasons)...soo... How do I avoid this? I seem to remember it had something to do with a child exiting..and when it does this it goes into kernel code to send the SIGCHLD signal to its parent but it hangs there forever because the parent never takes the signal (am I way off base?) I installed a signal handler for SIGCHLD which does nothing what should I do? how can I make th eparent clean up its little zombie children? [btw I plan to give this hack on xfstt a good stress test over the weekend and upload a new version of the package when I am satisfied...will also send my patch to the upstream author -- eventually I would like to give the network portion of the code a major overhaul/re-write/face-lift but thats another story] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#22942: Advice for release critical bug (WAS: Bug#22942: libpaper depends on libpaperg)
Hi, I think I'm failing to follow something basic here. Does paperconf depend on the libc6 shared libraries? If so, there is no way one could use the binaries without loading libpaperg, right? Secondly, Hamm is supoposed to be libc6. Marco == Marco Pistore [EMAIL PROTECTED] writes: Marco The problem is that libpaper does not provide just the Marco library, but also a pair of executables (paperconf and Marco paperconfig). A package that depends on libpaper can use both Marco the library and the executables. libpaper contains this, or libpaperg? Marco When i had to provide both the libc5 and the libc6 version of the Marco package, i decided to put the binaries only in the libc6 (i.e., Marco libpaperg). The libc5 package (libpaper) should however depend on the Marco libc6 package, to assure that the packages depending on libpaper can use Marco the executables.[1] Which library do the executable depend on? I think this is about time we reduced continuing support for libc5 in Hamm, especially when a libc6 replacement is available. Marco The possible solutions are: Marco SOLUTION 1 (Suggested by Wichert) Marco - Marco Create the packages: Marcolibpaper - the old libc5 library. May suggest libpaper-bin. Marcolibpaperg - the new libc6 library. May suggest libpaper-bin. Marcolibpaper-bin - the binariesmanpages. Depend on libpaperg Marco Here the problems are that we do not guarantee, by installing libpaper, Marco that the executables are present in the system. OTOH, by making Marco libpaper depend on libpaper-bin, the installation of libpaper would also Marco force the installation of libpaperg, which is what we wanted to avoid. Why do we want to avoid this? Hamm is libc6 all the way. I think asking people to have libc6 libraries is reasonable (I would be considering ways to get rid of the libc5 libraries, really). What packages depend on libpaper and not on libpaperg? Why are they in Hamm? Marco SOLUTION 2 I fail to see the need for libpaper. Marco SOLUTION 3 Marco -- Marco Well, we can also decide that to leave the situation as it is. In this Marco way, however, users would not be able to install the new version of the Marco library without also installing libpaperg (and libc6...) The objection, for hamm, seems ridiculous to me. I mean, is libc6 not a release goal for Hamm? We are strenuously trying to save people from a release goal? What am I missing? BTW, I think Solution 3 is not really a solution. I think we should just get rid of libpaper. On my machine, no package actually depends on libpaper anyway; they all depend on libpaperg. libpaperg should just replace and conflict with libpaper, and no libpaper be provided in Hamm. What am I missing? manoj -- Computers are like Old Testament gods; lots of rules and no mercy. Joseph Campbell Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems with the undead (zombies)
On Fri, 5 Jun 1998, Stephen Carpenter wrote: This turned out to be almost trivial...simply a few mods, instead of servicing requests after connect, it fork()s and lets the child service that connection while the parent loops and waits fo rthe next connect. [I think I changed 10 lines of code total] This SEEMS to work fine (I havn't really given it a good test -YET) except when I connect and then disconnect...the child exists (via _exit(0)) after the client disconnects. The problem is that the child then become a zombie. [ how do I get rid of zombies? ] See wait(2). Brandon - Brandon Mitchell [EMAIL PROTECTED] We all know linux is great... it PGP: finger -l [EMAIL PROTECTED] does infinite loops in 5 seconds Phone: (757) 596-5550 --Linus Torvalds Debian Testing Group status: http://bhmit1.home.ml.org/deb/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Advice for release critical bug (WAS: Bug#22942: libpaper depends on libpaperg)
Hi, James == James Troup [EMAIL PROTECTED] writes: The only remedy is to remove the old libpaper, and then to install libpaper and libpaperg. James Where *did* you get this idea from? It's 200% bogus. 14:20:[EMAIL PROTECTED]| ~/temp $sudo dpkg -iEG libpaper_1.0.3-9.deb libpaperg_1.0.3-9.deb (Reading database ... 34403 files and directories currently installed.) Preparing to replace libpaper 1.0.3-3 (using libpaper_1.0.3-9.deb) ... Unpacking replacement libpaper ... Selecting previously deselected package libpaperg. Unpacking libpaperg (from libpaperg_1.0.3-9.deb) ... Setting up libpaperg (1.0.3-9) ... Setting up libpaper (1.0.3-9) ... Well, in cases like this the order in which the deb files are presented to dpkg is relevant. So if a novice is upgrading a large set of packages, and the packages are not presented in the corect order, the upgrade process issues ominous sounding threats. This situation is better avoided. manoj -- Open the pod bay doors, HAL. Dave Bowman, 2001 Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Advice for release critical bug (WAS: Bug#22942: libpaper depends on libpaperg)
Manoj Srivastava [EMAIL PROTECTED] writes: Well, in cases like this the order in which the deb files are presented to dpkg is relevant. So if a novice is upgrading a large set of packages, and the packages are not presented in the corect order, the upgrade process issues ominous sounding threats. This situation is better avoided. ``This situation'' is similar to that of almost all libc5-libc6 shared library upgrades. Avoiding it might be non-trivial. -- James ~Yawn And Walk North~ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Twin Package
I've heard that somebody is packaging twin. Does anybody know who? Brian ( [EMAIL PROTECTED] ) --- Generated by Signify v1.04. For this and more, visit http://www.verisim.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Hamm install on laptop
I'm getting unresolved symbol errors when cardmgr tries to insmod the 3c589_cs module for my 3Com PCMCIA ethernet card. Is this a problem with the boot disks, and/or is there a solution for this? The laptop is an AST Ascentia J series, and the card is a 3C589C. Steve. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hamm install on laptop
On Fri, 5 Jun 1998, Steve Tonnesen wrote: I'm getting unresolved symbol errors when cardmgr tries to insmod the 3c589_cs module for my 3Com PCMCIA ethernet card. Is this a problem with the boot disks, and/or is there a solution for this? The laptop is an AST Ascentia J series, and the card is a 3C589C. This was just reported a while ago on debian-testing by [EMAIL PROTECTED], I don't know if he had a solution, but he filed a bug report and the boot disks maintainers follow the list and therefore well aware of the problem. Check on 2.0.7 due in incoming next week. Brandon - Brandon Mitchell [EMAIL PROTECTED] We all know linux is great... it PGP: finger -l [EMAIL PROTECTED] does infinite loops in 5 seconds Phone: (757) 596-5550 --Linus Torvalds Debian Testing Group status: http://bhmit1.home.ml.org/deb/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
