Nouvelle version du paquet developers-reference-fr (3.3.2)
* Frédéric Bothamy [EMAIL PROTECTED] [2003-04-18 15:47] : [...] J'ai validé les modifications dans le CVS Debian hier soir et la traduction sera présente dans le prochain paquet Debian developers-reference-fr 3.3.2. Elle sera également disponible sur le site Debian à l'adresse suivante : http://www.debian.org/doc/manuals/developers-reference/index.fr.html quand le document sera généré correctement. Bon, le responsable Debian du paquet a généré le nouveau paquet developers-reference-fr (3.3.2) qui vient d'arriver dans unstable. La version en ligne sur le site Debian n'est malheureusement pas à jour à cause du problème de génération évoquée précédemment (sur debian-l10n-french). Les personnes intéressées de debian-devel-french (et les autres) peuvent consulter en attendant ma version personnelle à partir de http://olympie.dyndns.org/debian/doc/dev-ref/developers-reference.fr.html/index.fr.html. Bonne lecture. Fred
Re: imlib-linked-with-libpng3
On Fri, Apr 18, 2003 at 08:43:45PM -0400, Steve M. Robbins wrote: Imlib is more-or-less dormant upstream. However, in late August, I was under the impression that upstream imlib was going to release a new version (with new SONAME) that would be linked with libpng3. In I forgot to comment on this part. Its not upstreams place to deal with what a particular user of the software decides to link stuff with. If you break ABI that is no reason to mess with the ABI numbering which is what SOVER's are for. This was already discussed to death in numerous other threads the one that most readily comes to mind was the gcc c102 thread. In Debian's case if you break ABI you are supposed to add some sort of differenation to the package name, such as imlib1foo and make it conflict with the old version. From what I am able to tell, other dists just rebuild against the current versions of libraries and don't bother with renaming the packages themselves. Chris
my computer
trying to fix my desktop setting on my computer
Re: why do we care about configuration files?
Is it just me, or would this fix the problem simply: 1) If a postinst generates a configuration file with debconf, it must place the md5sum of the generated configuration file in /var 2) A package should try and parse the current configuration file back into debconf before prompting. 3) After prompting, the package must confirm that the current md5sum matches the one stored in /var. If it does and the package succeeded at (2) it may replace the configuration file. Otherwise, use ucf. signature.asc Description: This is a digitally signed message part
Re: stop abusing debconf already
Package: binutils On Fri, 2003-04-18 at 19:14, Joey Hess wrote: Enough already. Folks, if you don't stop abusing debconf with useless notes that belong in README.Debian and config file overwriting, I will stop maintaining it. Amen. For example, we really need to kill that kernel link failure info message in binutils. Not only is it totally obsolete, it was a bad idea in the first place.
Re: imlib-linked-with-libpng3
Hi Chinput can use any of libpng2 or libpng3, it just need a rebuild. -- Yu Guanghui ygh at dlut.edu.cn Network Center Dalian University of Technology, China Steve M. Robbins [EMAIL PROTECTED]: Hello, I'd like to solicit opinions about what to do with imlib-linked-against-libpng3. Until August 2002, the Debian imlib packages were linked with libpng2. Even after libpng3 was released in early 2002, imlib remained linked with the older libpng2. This was done to retain the ABI of imlib, especially the ABI of the GNOME version, gdk-imlib. Imlib is more-or-less dormant upstream. However, in late August, I was under the impression that upstream imlib was going to release a new version (with new SONAME) that would be linked with libpng3. In anticipation of that, I introduced imlib2/imlib-dev into Debian but filed a Grave bug against it to keep it from moving to testing. It is still not in testing. I no longer believe that upstream will release any new versions of imlib and I plan to ask that imlib2 be removed from the archive. I don't want to change the current imlib1 linkage since imlib is pretty much dormant and probably on its way out. There are six packages currently linked against imlib2: chinput fnlib kdegraphics mgp picturebook wallp I'm not sure whether they strictly require png3 or whether they could simply be rebuilt with imlib1 and libpng2. In the past, however, some KDE folks have explicitly requested imlib+png3. What would be the best way to accomodate such a request? I can imagine introducing a new package of imlib linked with libpng3. But since it has to use the same SOVERSION as the current imlib1, it would have to conflict with imlib1. Each individual admin could then choose to use imlib+png2 or to use imlib+png3. However, each choice would have its own set of incompatible programs so this option doesn't appeal to me. Another option is to drop the idea of imlib+png3. The six packages mentioned above would then have to build either with png2 or somehow incorporate imlib into their source build. For the maintainers of the six packages: is that feasible? -Steve - web: http://mail.dlut.edu.cn
ITP: StarDict-2.0.0, an English-Chinese/Chinese-English dictionary
Dear all, StarDict-2.0.0-pre2 has been packaged and uploaded to Debian's incoming. StarDict 2 is a GNOME-based international dictionary, currently with English-Chinese/Chinese-English data included. It is a major rewrite by HU Zheng (http://stardict.cosoft.org.cn/) based on the an earlier Motif/LessTif-based implementation of StarDic 1.31/1.33 (packaged as stardic on Debian) by MA Su'an (and later on with enhancements from Opera Wang). MA Su'an no longer has time to continue its development, so he gave his blessings to the new efforts. Thanks to fellow Debian developer Yu Guanghui for telling this good news to the Debian community. License: GNU General Public License stardict_1.9.92+2.0.0-pre2-2_i386.deb - new debian package, version 2.0. size 12934446 bytes: control archive= 2413 bytes. 36 bytes, 1 lines conffiles 1312 bytes,16 lines control 2614 bytes,35 lines md5sums 730 bytes,33 lines * postinst #!/bin/sh 492 bytes,26 lines * postrm #!/bin/sh Package: stardict Version: 1.9.92+2.0.0-pre2-2 Section: utils Priority: optional Architecture: i386 Depends: bonobo-activation (= 1:2.2.1.1), libart-2.0-2 (= 2.3.8), libatk1.0-0 (= 1.2.2), libaudiofile0 (= 0.2.3-4), libbonobo-activation4 (= 1:2.2.1.1), libbonobo2-0 (= 2.2.1), libbonoboui2-0 (= 2.2.0.1), libc6 (= 2.3.1-1), libesd0 (= 0.2.29-1) | libesd-alsa0 (= 0.2.29-1), libgcc1 (= 1:3.3), libgconf2-4 (= 2.2.0), libgcrypt1 ( 1.1.11-0), libglib2.0-0 (= 2.2.1), libgnome2-0 (= 2.1.90), libgnomecanvas2-0 (= 2.1.90), libgnomeui-0 (= 2.1.90), libgnomevfs2-0 (= 2.2.3), libgnutls5 (= 0.8.0-1), libgtk2.0-0 (= 2.2.1), libjpeg62, liblinc1 (= 1:1.0.0), liborbit2 (= 1:2.6.0), libpango1.0-0 (= 1.2.1), libpopt0 (= 1.6.4), libstdc++5 (= 1:3.3), libtasn1-0 (= 0.1.1-2), libxml2 (= 2.5.0-1), xlibs ( 4.1.0), zlib1g (= 1:1.1.4) Installed-Size: 24205 Maintainer: Anthony Fok [EMAIL PROTECTED] Description: English-Chinese/Chinese-English dictionary for GNOME 2.2 StarDict is an international dictionary that runs in GNOME 2.2 environment. It has powerful features such as Glob-style pattern matching, Scan selection word, Fuzzy query, etc. English-Chinese/Chinese-English dictionary data from several sources are currently provided. . Home Page: http://stardict.cosoft.org.cn/ drwxr-xr-x root/root 0 2003-04-19 10:56:20 ./ drwxr-xr-x root/root 0 2003-04-19 10:56:19 ./etc/ drwxr-xr-x root/root 0 2003-04-19 10:56:19 ./etc/gconf/ drwxr-xr-x root/root 0 2003-04-19 10:56:19 ./etc/gconf/schemas/ -rw-r--r-- root/root 3784 2003-04-19 10:56:19 ./etc/gconf/schemas/stardict.schemas drwxr-xr-x root/root 0 2003-04-19 10:56:19 ./usr/ drwxr-xr-x root/root 0 2003-04-19 10:56:20 ./usr/bin/ -rwxr-xr-x root/root 99064 2003-04-19 10:56:20 ./usr/bin/stardict drwxr-xr-x root/root 0 2003-04-19 10:56:19 ./usr/lib/ drwxr-xr-x root/root 0 2003-04-19 10:56:20 ./usr/lib/menu/ -rw-r--r-- root/root 101 2003-04-19 10:54:47 ./usr/lib/menu/stardict drwxr-xr-x root/root 0 2003-04-19 10:56:19 ./usr/lib/bonobo/ drwxr-xr-x root/root 0 2003-04-19 10:56:19 ./usr/lib/bonobo/servers/ -rw-r--r-- root/root 681 2003-04-19 10:56:19 ./usr/lib/bonobo/servers/GNOME_Stardict.server drwxr-xr-x root/root 0 2003-04-19 10:56:19 ./usr/share/ drwxr-xr-x root/root 0 2003-04-19 10:56:19 ./usr/share/doc/ drwxr-xr-x root/root 0 2003-04-19 10:56:20 ./usr/share/doc/stardict/ -rw-r--r-- root/root 544 2003-04-07 22:43:05 ./usr/share/doc/stardict/ChangeLog.zh_CN -rw-r--r-- root/root 418 2003-04-19 02:07:27 ./usr/share/doc/stardict/NEWS.zh_CN.gz -rw-r--r-- root/root 1531 2003-04-19 10:44:09 ./usr/share/doc/stardict/copyright -rw-r--r-- root/root 102 2003-04-07 22:41:27 ./usr/share/doc/stardict/changelog.gz -rw-r--r-- root/root 788 2003-04-19 10:55:26 ./usr/share/doc/stardict/changelog.Debian.gz drwxr-xr-x root/root 0 2003-04-19 10:56:19 ./usr/share/man/ drwxr-xr-x root/root 0 2003-04-19 10:56:20 ./usr/share/man/man1/ -rw-r--r-- root/root 569 2003-04-19 10:56:19 ./usr/share/man/man1/stardict.1.gz drwxr-xr-x root/root 0 2003-04-19 10:56:19 ./usr/share/omf/ drwxr-xr-x root/root 0 2003-04-19 10:56:19 ./usr/share/omf/stardict/ -rw-r--r-- root/root 903 2003-04-19 10:56:19 ./usr/share/omf/stardict/stardict-C.omf -rw-r--r-- root/root 911 2003-04-19 10:56:19 ./usr/share/omf/stardict/stardict-zh_CN.omf drwxr-xr-x root/root 0 2003-04-19 10:56:19 ./usr/share/gnome/ drwxr-xr-x root/root 0 2003-04-19 10:56:19 ./usr/share/gnome/help/ drwxr-xr-x root/root 0 2003-04-19 10:56:19 ./usr/share/gnome/help/stardict/ drwxr-xr-x root/root 0 2003-04-19 10:56:19 ./usr/share/gnome/help/stardict/C/ -rw-r--r-- root/root 4034
Re: why do we care about configuration files?
On 19 Apr 2003 00:07:54 -0400, Anthony DeRobertis [EMAIL PROTECTED] said: Is it just me, or would this fix the problem simply: 1) If a postinst generates a configuration file with debconf, it must place the md5sum of the generated configuration file in /var 2) A package should try and parse the current configuration file back into debconf before prompting. 3) After prompting, the package must confirm that the current md5sum matches the one stored in /var. If it does and the package succeeded at (2) it may replace the configuration file. Otherwise, use ucf. Or, simply generate the file using debconf or whatever, and call ucf directly; then ucf handles storing the md5sum and comparing it for you seamlessly. manoj -- The best man for the job is often a woman. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Bug#189566: amavisd-new: bad interaction with package amavis-ng
On Sat, Apr 19, 2003 at 10:22:45 +1000, Brian May wrote: On Fri, Apr 18, 2003 at 09:33:01PM +0200, [EMAIL PROTECTED] wrote: Package: amavisd-new Version: 20021227p2-5 Severity: grave Grave would seem to be a bit of an overkill? amavisd-new still works OK for the majority of users... I chose grave, because in the state described below one of the amavisd ate 100% cpu constantly (this was how I noticed the problem). when - amavis-ng is installed (I used version 0.1.6.2-1), - and amavisd-new previously had been installed but now only its config-files are present, then the init-scripts of _both_ packages start the program /usr/sbin/amavisd I really don't know what to do about this bug. I think the same thing has happened before with similar situations, but I don't know what was decided. Both init-scripts check for the existance of /usr/sbin/amavisd, and assume it is their version of the program and will run it. yes. So maybe one of the packages should have its amavisd renamed. -- Ernst Kloppenburg Stuttgart, Germany
foo has reached testing, removing versioned build-depends?
Hi, [ obDebianDevel: just in case this has become popular beleif or something like that ] from menu's 2.1.7-3 changelog: * debiandoc-sgml 1.1.75 has reached testing so remove the versionned Build-Depends. what gave you the idea that because debiandoc-sgml 1.1.75 is now in testing, you can remove the versioned build-depends? Unless the comment is misleading, menu still depends on at least that version of debiandoc-sgml to build, doesn't it? Marcelo
Re: stop abusing debconf already
On Fri, Apr 18, 2003 at 07:14:19PM -0400, Joey Hess wrote: Enough already. Folks, if you don't stop abusing debconf with useless notes that belong in README.Debian and config file overwriting, I will stop maintaining it. Stop slapping incorrect uses of debconf in everywhere. Feel free to run any package using debconf by me before you upload it, or take the time to understand yourself how things should work. I do not understand exactly what is good and bad use of debconf. For instance all questions asked by the debconf package have good default values, so there is no reason to prompt user, a configuration file is enough. So what am I missing? Denis
Re: bad postinst in kernel-images
To debian-devel: Because it is a long time, we have been discussing this bug here, and the thread is broken, I remark, we are talking about http://lists.debian.org/debian-devel/2003/debian-devel-200302/msg00349.html. Please, let's return to the problem and let's try to solve it. On Fri, Apr 11, 2003 at 11:45:54AM +1000, Keith Owens wrote: When using a recent binutils, you need modutils = 2.4.17. The binutils team changed the output of the 'nm' command which changed the contents of System.map. Well, it looks like a dependency problem in Debian. What do you exactly mean with recent binutils? This problem appears on Woody, that means with binutils 2.12.90.0.1-4 and modutils 2.4.15-1. Regards, Marcel Kolaja Debian GNU/Linux Power User http://www.debian.org/ -- I could be wrong, of course. But I'm never wrong. -- Linus Torvalds
Re: bad postinst in kernel-images
On Sat, 19 Apr 2003 12:07:11 +0200, Marcel Kolaja [EMAIL PROTECTED] wrote: To debian-devel: Because it is a long time, we have been discussing this bug here, and the thread is broken, I remark, we are talking about http://lists.debian.org/debian-devel/2003/debian-devel-200302/msg00349.html. Please, let's return to the problem and let's try to solve it. On Fri, Apr 11, 2003 at 11:45:54AM +1000, Keith Owens wrote: When using a recent binutils, you need modutils = 2.4.17. The binutils team changed the output of the 'nm' command which changed the contents of System.map. Well, it looks like a dependency problem in Debian. What do you exactly mean with recent binutils? This problem appears on Woody, that means with binutils 2.12.90.0.1-4 and modutils 2.4.15-1. binutils was changed around July 15 2002. Unfortunately the binutils Changelog does not mention the change, nor does it say which releases of binutils were issued around that time. Does upgrading to modutils = 2.4.17 fix your problem? If so, the n this is a prely Debian dependency problem.
Re: stop abusing debconf already
At 7:22 pm, Saturday, April 19 2003, Denis Barbier mumbled: I do not understand exactly what is good and bad use of debconf. For instance all questions asked by the debconf package have good default values, so there is no reason to prompt user, a configuration file is enough. So what am I missing? Well, not all use of debconf is bad. For example, libnet-perl is a terrible misuse of debconf, *but* it can be remedied by dropping the priority of the questions from medium to low. Another bad example is binutils, which spits out that silly note even during a new install. If you test that $2 is empty, don't print it. Unfortunately, I don't want to point out a good usage of debconf, since I'd only be ringing my own bell. The barrier here is common sense. Personally, I feel that debconf asking questions during install is fine, if the priority is correct, and it does not forget the answers. Cheers, -- Steve
Re: 2000 packages still waiting to enter testing, 1500 over age
On Fri, Apr 18, 2003 at 06:11:16AM +1000, Anthony Towns wrote: On Thu, Apr 17, 2003 at 08:11:52PM +0200, Sven Luther wrote: I CCed you the bugreport where i explain everything, but the packages are : libpgsql-ocaml ocamlsdl These are the source packages. You missed: ocaml-core | 3.06.3 | unstable | all ocaml-libs | 3.06.3 | unstable | all meta-ocaml | 3.06.3 | unstable | source Since ocaml-libs apparently breaks, this needs to go too. Hello everyone. Ocaml 3.06 is now in testing. Apparently the dependencies i checked where enough. I write this mail to give Anthony a great thanks on behalf of me and the rest of the ocaml maintainers, for helping make this happen. Now, let's go hunt for other RC bugs and fix stuff so the sarge release can happen in a timely fashion. BTW, i will be unreacheable by mail until tuesday, since apparently my mail server is down, so if anybody tries to write to me, don't be surprised if you don't get a response until next week. Friendly, Sven Luther
Re: stop abusing debconf already
Enough already. Folks, if you don't stop abusing debconf with useless notes that belong in README.Debian and config file overwriting, I will stop maintaining it. Stop slapping incorrect uses of debconf in everywhere. Feel free to run any package using debconf by me before you upload it, or take the time to understand yourself how things should work. Great, helpful input to the debate. Let me see... 1) Toys 2) Pram 3) Throw 4) Profit? Matt.
Re: stop the manage with debconf madness
Personally I use the ask-about-overwrite question in debconf because the last time this thread came up the only sensible solution was put forward in the attached email. Now, I'm all for a better solution when it is determined what that is, *but* I'm not for a witch hunt based on what was seen to be previous best practice. Matt. ---BeginMessage--- On Mon, Jan 15, 2001 at 07:40:00PM +1000, Jason Henry Parker wrote: [1] : Actually the file in question was a conffile as well as being edited by debconf, but whatever. Herein lies the problem, as I see it. This is a common policy violation because maintainers often want this functionality, but it clashes with policy, or is not addressed. With old-style use of conffiles, package maintainers simply provided a default conffile, which they could update from time to time, and the USER was responsible for merging in their local changes. This was easy on package maintainers, but hard on users. Some packages cannot supply a reasonable default configuration for all users, and/or would like to make the user's life easier by asking a few questions and generating a configuration file. In the pre-debconf era, this would be done by a packageconfig script, a la exim or magicfilter. Once the config file was generated, it would be left alone forever. The user could reconfigure at any time by running the script. If the config file format changed or some such, the user is responsible for re-running the config script and generating a new config file. In this age of debconf, we now have standard tools for asking the user questions (debconf) and reconfiguring a package (dpkg-reconfigure). In order to use these mechanisms successfully, we need some way to peacefully coexist with the user's manual changes. The key change is that package configuration via these tools is done _by maintainer scripts_, rather than by supplying a default conffile or running a script. Policy specifically forbids the editing of conffiles by maintainer scripts ([1] (must not), [2] (should not)). Now, maintainer scripts using debconf have these options: 1. Hide in a hole, and do things the old way. 2. Only generate an initial configuration, and leave it alone forever thereafter (the configuration file may be a conffile). This is a waste of good infrastructure, and leaves the user feeling cheated. If they want to use that same slick process to create a new configuration, they must remove and reinstall the package. 3. Always overwrite the configuration (the configuration file is NOT a conffile). This may seem appropriate for some packages, for which there is a 1:1 mapping between debconf questions and configuration options, but does not allow the user to preserve their local changes (a bad thing). 4. Try to merge the user's changes into the configuration file (the configuration file is NOT a conffile). This is, in my opinion, almost always a bad idea. Regardless of how few lines such a hack adds to the maintainer scripts, this is not guaranteed to stay simple. If a config file format changes, for example, the maintainer scripts may be required to be able to parse both config file formats and convert between them. This means that the maintainer script's parser must be smarter than the program's own (which can only read one of the formats). Some programs, which use an ancient config file format that is unlikely to ever change, can get away with this, as can programs with very simple name=value shell-alike config files. But I still don't like it. 5. Ask the user whether or not to overwrite their configuration file (the configuration file is NOT a conffile). This is the approach taken by xserver-xfree86. One of the questions asked of the user is (in effect) whether their configuration file should be under their control, or that of the maintainer scripts. If the user opts to have their config file generated for them, manual changes are not preserved and their configuration is freshly generated (in the correct format) based on their answers. If the user opts to write their own config file, the maintainer scripts will leave it alone until the user changes their mind. Option #5 best meets the goals of both users and package maintainers. Its only problem is one of elegance. First, the code and templates to ask the user about each config file and how it should be handled must be duplicated in every package that takes this approach. Second, the packaging system does not know about these configuration files, so the user might have some difficulty determining which package owns it, or how it is managed. This functionality should, I think, be integrated into the packaging system, like the current conffile mechanism. A configuration file should be able to be tagged as either user-managed (behaving exactly as a current conffile) or script-managed. The user should be able to, at any time, switch between
Re: foo has reached testing, removing versioned build-depends?
On Sat, Apr 19, 2003 at 10:44:52AM +0200, Marcelo E. Magallon wrote: Hi, [ obDebianDevel: just in case this has become popular beleif or something like that ] from menu's 2.1.7-3 changelog: * debiandoc-sgml 1.1.75 has reached testing so remove the versionned Build-Depends. what gave you the idea that because debiandoc-sgml 1.1.75 is now in testing, you can remove the versioned build-depends? Unless the comment is misleading, menu still depends on at least that version of debiandoc-sgml to build, doesn't it? Read the reason why the debiandoc-sgml *versioned* build-dep was added latter on in the changelog, and check the control file, and then go back and I will give an explanation. Thanks, -- Bill. [EMAIL PROTECTED]
New project proposal: debian-lex
I am interested in coordinating a new sub-project called Debian-Lex, which would be Debian for Lawyers, akin to the Debian-Med, Debian-Jr and DebianEdu projects. Hopefully, these sub-projects will evolve into Bdale's idea of flavours (flavors, but I'm Australian) of Debian. I am a lawyer and also an IT consultant, which makes me one of a small handful of people who have a foot firmly in both camps. I have written for my local Law Society's magazine on free software for the legal office, but the lack of a packaged Linux system for lawyers does seem to be impeding the take-up of Linux within law firms, particularly on the desktop. The Debian-Lex project would in part just contain some obvious selections from the existing pool such as OpenOffice.org, Evolution and Gnotime, but it would also need some other packages that aren't yet in Debian such as SQL-Ledger (although this has been ITP'd), and I intend to put together a database schema that will serve as the basis for a legal client and matter database. If there are no major objections within the developer community I will liaise with the appropriate people to get this moving, and post for expressions of interest to the debian-users list to see if there are any other lawyers out there who would like to help. -- JEREMY MALCOLM [EMAIL PROTECTED] Personal: http://www.malcolm.id.au Providing online networks of Australian lawyers (http://www.ilaw.com.au) and Linux experts (http://www.linuxconsultants.com.au) for instant help! Disclaimer: http://www.terminus.net.au/disclaimer.html. GPG key: finger. signature.asc Description: This is a digitally signed message part
Re: stop abusing debconf already
Denis Barbier wrote: On Fri, Apr 18, 2003 at 07:14:19PM -0400, Joey Hess wrote: Enough already. Folks, if you don't stop abusing debconf with useless notes that belong in README.Debian and config file overwriting, I will stop maintaining it. Stop slapping incorrect uses of debconf in everywhere. Feel free to run any package using debconf by me before you upload it, or take the time to understand yourself how things should work. I do not understand exactly what is good and bad use of debconf. For instance all questions asked by the debconf package have good default values, so there is no reason to prompt user, a configuration file is enough. So what am I missing? The only reasons debconf itself asks those questions still are: - example of how debconf works - they _are_ overridable with the config file, in an appropriate way - it's not asked at new installs anyway - people are used to that I did have some bad ideas about how debconf could be used back years ago when I wrote it. Those debconf questions (and some really ill-advised stuff slrn used to do) were the result. -- see shy jo pgpede47N4y44.pgp Description: PGP signature
Re: stop abusing debconf already
On Sat, Apr 19, 2003 at 02:08:27PM +0100, Matt Ryan wrote: Joey Hess wrote: Enough already. Folks, if you don't stop abusing debconf with useless notes that belong in README.Debian and config file overwriting, I will stop maintaining it. Stop slapping incorrect uses of debconf in everywhere. Feel free to run any package using debconf by me before you upload it, or take the time to understand yourself how things should work. Great, helpful input to the debate. Let me see... 1) Toys 2) Pram 3) Throw 4) Profit? Or maybe realize that Joey might perhaps know what he's talking about with regard to debconf ... you could go find the text of his talk at the last Debian Conference if you like. -- Colin Watson [EMAIL PROTECTED]
Re: libc6 (security) update does not restart system-services?
At Fri, 18 Apr 2003 17:24:17 +0200, Markus Amersdorfer wrote: On Fri, 18 Apr 2003 13:06:07 +0900 GOTO Masanori [EMAIL PROTECTED] wrote: - /var/lib/dpkg/info/libc6.postinst checks for $1 == configure (which is the case when updating, isn't it?). If true it afterwards checks if $2 is lower than 2.1.95-1 (I assume this corresponds to the previously installed version) and _only if this the case_ it restarts most of the services. Woody comes with libc6 2.2.5-11.5, so the section about restarting services is never reached. This leaves the machine vulnerable as all services use the old library until restarted. Shouldn't the services be restarted when installing a new libc-version? What reasons would there be not to restart services? Restarting services is needed only once: upgrading from 2.2.x to 2.3.x. The reason is simple. NSS (Name Service Switch) is much changed, and it becomes incompatible between 2.2 and 2.3. So if you use woody server, not sarge, then you have no need to restart services. If you use libc6 2.2.x, it's not related. So restarting services is necessary when upgrading from 2.2.x to 2.3.x to make sure everything works fine (as e.g. the example of xdm you mention below). When staying with basically the same version and simply doing a security-update, there are no compatability-problems, of course, so everything keeps running smoothly. But my concern is that running programs such as system services use the old libraries instead of the new one as long as they continue running, don't they? If they do the security bug is still exploitable though the new libraries are already installed on the system. Yes, right, good point. This is not only glibc issue; this problem affects all library packages. The old libraries are remove-pending state on the file system, and reside in applications. So everytime we have to restart all binaries which use a library involving security-problem. In additionm this problem affects not only debian packages, but user-built binaries. I have to warn all users who believe that we needs only apt-get upgrade, yeah, that's all folks! concept. It's not true for this library upgrade issue. From our glibc upgrade experience, it's difficult to restart packages which have specific problem automatically... The simple method to detect old libraries are to use lsof, so debian package system can warn for users there are old libraries which has security problem, so you should restart these binaries. I don't know there is good way to fix this problem. If everything _is_ designed not to restart the services, I suppose telling the users to take care of that theirselves would be a good idea for example using a simple echo in the post-install script (or similar). The restarting message is not sufficient for you? Of course, but the message is only shown if the services _are_ to be restarted (which is only when doing a major version update). Services are not restarted by the security update though I think they should be (as stated above). If I'm wrong, please correct me. :) I think you confuse two issue. One is generic problem as I write above (memory resident libraries issue). Another is glibc NSS start problem as I write below. Or did you point the messages which are not appeared in libc6.postinst when you upgraded from 2.2 to 2.3 ? BTW, I plan to dupload 2.3.1-17 that has preinst message to choose libc6 upgrade or not. It's needed because for example xdm cannot authenticate after installing libc6, but we cannot restart xdm with postinst automatically (user's X11 session is destroyed). I add messages in next 2.3.1-17 as they have to restart xdm with their hand. If you have requests about restarting messages, please tell me. Though I don't know enough about the detailed processes running inside the library packages: Sounds great. :) Perhaps it's possible to delay installation of the libraries until the next reboot? The user would have the chance to have the libraries installed instantly (which would break xdm), automatically at the next reboot (is that what you meant above?) or not at all at the moment (though I currently can't think of a good reason why to do that). You said about generic problem (memory resident libraries issue), and I don't think it should be. Delay installation everytime requires system reboot. But some users know it needs only application restart. In addition, it's only applied in upgrade between the same library version. If this delayed installation is introduced for glibc, then upgrade from woody to sarge breaks all binaries. Sarge packages depends on glibc 2.3.x, and it can't run under woody's glibc 2.2.5 environment. If you run sarge/sid /bin/ls under woody glibc 2.2.5, then you get error: /bin/ls: /lib/libc.so.6: version `GLIBC_2.3' not found (required by /bin/ls) OK, now start to say about glibc NSS
Re: stop abusing debconf already
Steve Kowalik wrote: Well, not all use of debconf is bad. For example, libnet-perl is a terrible misuse of debconf, *but* it can be remedied by dropping the priority of the questions from medium to low. At least libnet-perl is actually asking questions and preserving some (though not all) user changes to libnet.cfg. Michael's idea to add a gateway question is probably sufficient to solve the too many questions thing. I'd be just as happy if it only asked about stuff that really needs to be configured, such as ftp passive mode though. Another bad example is binutils, which spits out that silly note even during a new install. Yes. If you test that $2 is empty, don't print it. Unfortunately, I don't want to point out a good usage of debconf, since I'd only be ringing my own bell. I'll ring it for you: xringd is one of the better users of debconf I have seen, and it gets everything right. The problem is that with debconf, even 10% of packages getting it wrong make the whole system into crap. And probably closer to 70% of packages are currently getting it wrong.. -- see shy jo pgpKTvmvVG4yb.pgp Description: PGP signature
Re: foo has reached testing, removing versioned build-depends?
On Sat, Apr 19, 2003 at 03:43:56PM +0200, Bill Allombert wrote: On Sat, Apr 19, 2003 at 10:44:52AM +0200, Marcelo E. Magallon wrote: [ obDebianDevel: just in case this has become popular beleif or something like that ] from menu's 2.1.7-3 changelog: * debiandoc-sgml 1.1.75 has reached testing so remove the versionned Build-Depends. what gave you the idea that because debiandoc-sgml 1.1.75 is now in testing, you can remove the versioned build-depends? Unless the comment is misleading, menu still depends on at least that version of debiandoc-sgml to build, doesn't it? Read the reason why the debiandoc-sgml *versioned* build-dep was added latter on in the changelog, and check the control file, and then go back and I will give an explanation. I've read the changelog and the bug report closed by that earlier change, and removing the version still makes no sense. If earlier versions of debiandoc-sgml produce incorrect output, as reported, then the versioned build-dep should be left there, as it will help people trying to build with older versions to know what the problem is. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: New project proposal: debian-lex
On 19 Apr 2003, Jeremy Malcolm wrote: I am interested in coordinating a new sub-project called Debian-Lex, Could you please explain the naming lex for non English speakers? In general I really like your idea because I think those internal projects are an important way to fit the needs of our users. I would recommend to read the slides of my talk about internal projects and also follow rhe link to the Subproject HOWTO. Good luck with your project Andreas. -- Mankind must put an end to war before war puts an end to mankind. John F. Kennedy
Re: libc6 (security) update does not restart system-services?
On Sun, Apr 20, 2003 at 12:05:49AM +0900, GOTO Masanori wrote: So everytime we have to restart all binaries which use a library involving security-problem. In additionm this problem affects not only debian packages, but user-built binaries. Well, this is why it is most often described in the security advisory. To be shure one can eighter use init 1 and get back to multi user mode, or use tools like lsof or my package of memstat to find loaded and deleeted libraries. This is also good to do on a regular interval if you update your systems for no security reasons: - it will free memory and will make the filesystem get rid of open/deleted files, which can cause problems like the inability to remount ro or messages like setting dtime of deleted inode on fsck. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: stop abusing debconf already
On Sat, Apr 19, 2003 at 03:46:32PM +0100, Colin Watson wrote: snip Or maybe realize that Joey might perhaps know what he's talking about with regard to debconf ... you could go find the text of his talk at the last Debian Conference if you like. /snip Could you (or someone else) give me a hint on where one could find Joey's talk ? I've already tried googling for it and looking at [1] but couldn't find it. [1] http://www.debconf.org -- ++--++ || André Luís Lopes [EMAIL PROTECTED] || || Debian-BR Project http://debian-br.cipsga.org.br || || Public GPG KeyID 9D1B82F6 || || Keyserver wwwkeys.eu.pgp.net || pgplhDHN8iHcp.pgp Description: PGP signature
debconf review of cvsd (was Re: stop abusing debconf already)
Arthur de Jong wrote: Ok, could you review my cvsd package for me for correct debconf usage and tell me what you do and don't like? Thanks for taking advantage of that offer. (So far you're the only one.) I am ccing this to -devel just because. All of the debconf questions are pretty well worded and clear, but there's always room for improvement: - I'm not sure why you capitalized Chroot in the second sentence of the cvsd/rootjail question (and in the short description of that question) and filehierarchy probably needs a space in it. - cvsd/rootjail: s/zero (0)/0/ # Apparently writing it out has the possibility to make # someone enter the number the wrong way so why not just # not write it out? - cvsd/nice: s/too much/too many/ - cvsd/listen: s/cvsd will listen on/on which cvsd will listen/ # Avoid dangling preposition - Though it's pretty obvious what you mean by RootJail in the cvsd/repositories question, that is in fact the first time that particular term has been used. Also, you could use a debconf substitution here to substitute in the user's choce of the chroot jail directory directly into the question, to remind them what it is. Oh you also use the inconsistently capitalized rootjail in cvsd/usedebconf. Wouldn't just chroot jail be better? Or at least some consistency there and with the Chroot jail term in cvsd/rootjail. - cvsd/limits: s/to limit of pserver process./of pserver process to limit:/ - Most of the questions have short descriptions that do not end in punctuation, and this has unfortunate results in some debconf frontends, like this: Location of Chroot jail /var/lib/cvsd It's better to put a colon or a question mark at the end. - It's sort of odd that you use spaces to separate multiple items in one question, and then colons to separate them in the next. - It was not clear to me in the cvsd/limits question what would be the result of picking any of those limits. At first I thought it would enable some kind of hard-coded limits, which made me not want to mess with it. I see reading that templates file that it in fact enables a whole set of additional questions about the limits. Noting that you'll ask these questions in cvsd/limits would be a good idea. - cvsd/limit_coredumpsize: s/filesize/file size/ # don't invent terminology s/coredump/core dump/ # I know, it sucks when one's spacebarbreaks :-) - cvsd/limit_cputime: s/prevent too much cpu time allocated/prevent too much cpu time from being allocated/ s/amount of seconds cputime/amount of cpu time/ # it is not just in seconds form, and seconds cputime is # incorrect English. - I was fairly confused by cvsd/limit_memorylocked, because I thought that only programs run as root could lock memory, and why would cvs want to? Was this just added for (over)completeness? - cvsd/limit_maxproc: s/Cvs/cvs/ # for consistency with every other mention of the program # including other starts of sentences - You have no translations for the debconf templates in the package. The DDTP project has a complete German translation at http://ddtp.debian.org/debconf/source/cvsd. Of course you may want to make the above changes first, and wait for an updated translation.. If I reconfigure cvsd, pick all the limits, and take the default value for everything else, it exits with code 20: debconf (developer): -- GET cvsd/limits debconf (developer): -- 0 coredumpsize, cputime, datasize, filesize, memorylocked, openfiles, maxproc, memoryuse, stacksize, virtmem debconf (developer): -- GET cvsd/limit_coredumpsize cputime datasize filesize memorylocked openfiles maxproc memoryuse stacksize virtmem debconf (developer): -- 20 Incorrect number of arguments zsh: exit 20DEBCONF_DEBUG=. dpkg-reconfigure cvsd Looks like a bug.. After doing this I also did not see all the limits stuff in cvsd.conf, it had only these config items: Uid cvsd Gid cvsd PidFile /var/run/cvsd.pid RootJail /var/lib/cvsd MaxConnections 10 Nice 1 Listen * 2401 You support backing up; very good job there! Looking at your priorities, I'm not sure why the maximum connection limit is at priority medium. Surely there is a sane default, and so it could be low priority? I'm iffy about asking about the jail directory at medium priority; I suppose many people will want to configure that, but /var/lib/cvsd seems reasonable. Medium is probably ok. I agree with your use of high priority for the repositories question, and all the rest look nice and low. I've set it up to ask first whether to use debconf to manage configuration of /etc/cvsd/cvsd.conf (not a conffile). If the user chooses to not use debconf, he's on his own (an example cvsd.conf is provided). Of course this is where in my opinion you lose. First of all, as Colin pointed out recently, any
plagiarism of reiserfs by Debian
Please explain your reasons for removing the credits and attributions from the reiserfs utilities in violation of our copyright. You'll note that ReiserFS anticipated the GNU GPL V3 by including clauses that forbid removal of credits in its license, and for a long time I have been telling Stallman that he needs to get V3 of the GPL out the door. By the way, does Debian support as a matter of principle the decrediting of Stallman and KDE by RedHat? I had really expected this from RedHat, not Debian, when I wrote those clauses. In the academic world, this is called plagiarism. In the academic world, knowledge is shared but fairly credited. The GPL is born of the academic tradition. -- Hans
Re: debconf review of cvsd (was Re: stop abusing debconf already)
One more thing that I didn't notice until purging the package. In the purge question, you refer to selecting yes and answering no. Don't do that, some debconf frontends do not use yes or no; the user might be staring at a check box when they see that text. Just ask the question, something like (changebarred): You may choose to remove the chroot jail but you will also loose all the repositories inside the chroot jail. If you have not | backed up your repositories you want to keep, do not remove it now; | manually remove it later once your repositories are safe. | If you do chose to remove the chroot directory, all directories under | it will be removed, even if they are on another filesystem. If you choose to keep the chroot jail please note that the cvsd user and group will be removed so uid and gid file information may no longer be consistent. And while it's probably ok to default it to true, the postrm should catch the db_input return code, and if the question is not displayed, do not remove anything (and say something to stderr about it maybe). Think of someone in noninteractive mode.. Good use of a debconf substitution in that last question, BTW. -- see shy jo pgpJf89k6aw5V.pgp Description: PGP signature
Re: stop the manage with debconf madness
On 18-Apr-03, 10:28 (CDT), Steve Langasek [EMAIL PROTECTED] wrote: If the package maintainers are correctly using the debconf priorities, and the admin has chosen a debconf priority that accurately reflects their preferences, why do you care? By definition, any prompts at priority medium or lower have reasonable defaults, If it has a reasonable default, then it should be defaulted. You should not ask questions about it. That's what Debian policy says. If you don't like this, then get policy changed. In particular, if you start asking questions about defaultable configuration values, then you can't make the file a conffile. Debian conffile handling is one of the great things about Debian. Breaking that is A Bad Thing(tm). That's it. Any other use is a clear violation of Debian configuration file policy. In particular, using debconf to modify existing configuration files, whether conffiles or not, is wrong. This claim is not reflected in our actual policy. It's perfectly valid for a maintainer script to make changes to non-conffile config file in response to a user's expression of assent. But only if that assent is obtained each and every time, not by checking what the admin answered 8 months ago on the original install. And the whole thing is better handled using conffiles, where I can diff and merge the changes, when it's convenient for me, rather than hiding them scripts in the middle of a massive upgrade. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: stop the manage with debconf madness
On Sat, 19 Apr 2003 14:07:04 +0100, Matt Ryan [EMAIL PROTECTED] said: Personally I use the ask-about-overwrite question in debconf because the last time this thread came up the only sensible solution was put forward in the attached email. Now, I'm all for a better solution when it is determined what that is, *but* I'm not for a witch hunt based on what was seen to be previous best practice. I'm sorry that all of us can't participate in all the discussions on -devel, and some times the optimal solutions are not reached. But when these solutions were starting to get implemented, I did point out the policy violations, and even filed a few serious bugs about them. I did not have the time or the energy then to do much more. Around the same time, ucf was written to allow one to manage a configuration file, allowing one to generate configuration files on the fly, and still afford the user changes dpkg like protection. In any case, pointing to an old discussion on -devel is not a justification for not preserving user changes. Asking the admin whether one may violate Debian policy ought not to be a license to do as one wishes. Secondly, this isnot a witch hunt. What is being done is that a policy violation in older practice is being pointed out. Alternatives are being discussed; a witch hunt would have involved mass RC bug filings. Debconf did not suddenly give people a reason to not preserve user changes; amd we had already rejected destruction of user changes before (one could have written a mainainter script in 1995 that asked the user once, populated a file in /var/lib/, and forever destroyed user changes, way before debconf). manoj -- Pardon this fortune. Database under reconstruction. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: stop abusing debconf already
On 19-Apr-03, 06:47 (CDT), Steve Kowalik [EMAIL PROTECTED] wrote: At 7:22 pm, Saturday, April 19 2003, Denis Barbier mumbled: I do not understand exactly what is good and bad use of debconf. For instance all questions asked by the debconf package have good default values, so there is no reason to prompt user, a configuration file is enough. So what am I missing? Well, not all use of debconf is bad. For example, libnet-perl is a terrible misuse of debconf, *but* it can be remedied by dropping the priority of the questions from medium to low. Huh? If all the questions it asks can be converted to priority low, then that means there are reasonable defaults, and therefore IT SHOULDN'T BE USING DEBCONF AT ALL. How hard is this? What is so unclear about Policy on this topic? Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: stop abusing debconf already
Andre Luis Lopes wrote: Could you (or someone else) give me a hint on where one could find Joey's talk ? I've already tried googling for it and looking at [1] but couldn't find it. Hmm, I don't have it online that I know of, it was mostly extemporaneous anyway. (Here, I've linked the slides online at http://kitenet.net/~joey/debconf-debconf) -- see shy jo pgpCvDzqK9Bd0.pgp Description: PGP signature
Re: New project proposal: debian-lex
On Sat, Apr 19, 2003 at 05:57:42PM +0200, Andreas Tille wrote: On 19 Apr 2003, Jeremy Malcolm wrote: I am interested in coordinating a new sub-project called Debian-Lex, Could you please explain the naming lex for non English speakers? s/English/Latin/ cheers, Michael
Re: New project proposal: debian-lex
On Sat, Apr 19, 2003 at 05:57:42PM +0200, Andreas Tille wrote: I am interested in coordinating a new sub-project called Debian-Lex, Could you please explain the naming lex for non English speakers? It's latin, not english. :-) It means law. -- Christian Surchi, [EMAIL PROTECTED], [EMAIL PROTECTED] | ICQ www.debian.org - www.softwarelibero.it - www.firenze.linux.it| 38374818 Bank error in your favor. Collect $200.
Re: stop abusing debconf already
On Sat Apr 19, 11:18am -0500, Steve Greenland wrote: On 19-Apr-03, 06:47 (CDT), Steve Kowalik [EMAIL PROTECTED] wrote: At 7:22 pm, Saturday, April 19 2003, Denis Barbier mumbled: I do not understand exactly what is good and bad use of debconf. For instance all questions asked by the debconf package have good default values, so there is no reason to prompt user, a configuration file is enough. So what am I missing? Well, not all use of debconf is bad. For example, libnet-perl is a terrible misuse of debconf, *but* it can be remedied by dropping the priority of the questions from medium to low. Huh? If all the questions it asks can be converted to priority low, then that means there are reasonable defaults, and therefore IT SHOULDN'T BE USING DEBCONF AT ALL. How hard is this? What is so unclear about Policy on this topic? From debconf-devel(8): low: Very trivial items that have defaults that will work in the vast majority of cases; oinly control freaks see these. pgpWKYL2Wz8BY.pgp Description: PGP signature
Re: New project proposal: debian-lex
On Saturday 19 April 2003 17:23, Christian Surchi wrote: On Sat, Apr 19, 2003 at 05:57:42PM +0200, Andreas Tille wrote: I am interested in coordinating a new sub-project called Debian-Lex, Could you please explain the naming lex for non English speakers? It's latin, not english. :-) It means law. In England there is a move to remove all the Latin and obscure language from the Law, so I would suggest that the project should be called Debian-law not Debian-lex. Regards David
Re: libc6 (security) update does not restart system-services?
Bernd Eckenfels wrote: GOTO Masanori wrote: So everytime we have to restart all binaries which use a library involving security-problem. In additionm this problem affects not only debian packages, but user-built binaries. Well, this is why it is most often described in the security advisory. It seems to me that while there is the reputation Rebooting is for adding new hardware that sometimes rebooting is also for security and other updates. I have been training people that Debian does not *force* a reboot at the time that the update is made but allows the admin to schedule a reboot at their convenience for critical library updates such as glibc, use your judgement. Coming from other system which force a reboot for almost any update this is seen as a breath of fresh air. (No, amazingly I am not talking about MS here, but rather HPUX which has many gratuitous reboots when swinstall'ing updates.) To be shure one can eighter use init 1 and get back to multi user mode, Basically moving through 'init 1' is almost the same as a reboot. It just preserves your uptime stats. :-) I would not move through 'init 1' programatically. or use tools like lsof or my package of memstat to find loaded and deleeted libraries. I believe this process to be much to complicated to be used successfully in the general case. You would need to match each running process back to a /etc/init.d restart methodology. These frequently do not have a one to one mapping. You could design a new methodology to be added to policy which packages with running daemons would need to register themselves to ensure a proper restart. So much work would be needed to make this happen smoothly. This is also good to do on a regular interval if you update your systems for no security reasons: - it will free memory and will make the filesystem get rid of open/deleted files, which can cause problems like the inability to remount ro or messages like setting dtime of deleted inode on fsck. Except for the uptime wars (2 years 2 weeks!, between power outs here) I generally reboot servers monthly. This has the added benefit that it also ensures that the servers will boot cleanly and an admin has not broken something with a manual tweak. Bob pgpSFjTrHWZtw.pgp Description: PGP signature
Bug#189689: ITP: libapache-mod-auth-radius -- Apache module for RADIUS authentication
Package: wnpp Version: unavailable; reported 2003-04-19 Severity: wishlist * Package name: libapache-mod-auth-radius Version : 1.5.7 Upstream Author : Alan DeKok [EMAIL PROTECTED] * URL : ftp://ftp.freeradius.org/pub/radius/ * License : Apache Software License 1.1 Description : Apache module for RADIUS authentication An apache module for authenticating users against information stored in a RADIUS server Regards Fabio
Re: plagiarism of reiserfs by Debian
On Sat, Apr 19, 2003 at 08:07:03PM +0400, Hans Reiser wrote: Please explain your reasons for removing the credits and attributions from the reiserfs utilities in violation of our copyright. You'll note that ReiserFS anticipated the GNU GPL V3 by including clauses that forbid removal of credits in its license, and for a long time I have been telling Stallman that he needs to get V3 of the GPL out the door. By the way, does Debian support as a matter of principle the decrediting of Stallman and KDE by RedHat? I had really expected this from RedHat, not Debian, when I wrote those clauses. In the academic world, this is called plagiarism. In the academic world, knowledge is shared but fairly credited. The GPL is born of the academic tradition. I'd hardly call it plagiarism. Your copyright is, by will of our own policy and to abide by authors wishes, distributed with the tools in /usr/share/doc/pkg/copyright. Now, I've never heard of such a copyright clause in your tools and I am quite sure that the individual maintainer of the package did not intentionally go against such clauses. Not to mention that the acts of that single maintainer of the software you wrote is not the will of the entire Debian project. Now I hope you stop with your trolling and consider speaking respectfully to us. I am pretty sure that if you emailed the maintainer of the package and pointed out the facts to him, he would revert the change. -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/
Re: New project proposal: debian-lex
* David Goodenough ([EMAIL PROTECTED]) [030419 19:20]: [debian-lex] In England there is a move to remove all the Latin and obscure language from the Law, so I would suggest that the project should be called Debian-law not Debian-lex. lex is the better word, as it is not only known in English, but also in most other (roman) Languages for law. Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C Fachbegriffe des Schienenverkehrs #1 von Marc Haber in dasr Alles wird billiger: 50 % Preiserhöhung für Stammkunden.
Re: plagiarism of reiserfs by Debian
On Sat, 19 Apr 2003 20:07:03 +0400 Hans Reiser [EMAIL PROTECTED] wrote: You'll note that ReiserFS anticipated the GNU GPL V3 by including clauses that forbid removal of credits in its license, and for a long time I have been telling Stallman that he needs to get V3 of the GPL out the door. Please provide a link that supports your assertian about a GPL v3. The BSD License Problemobnoxious BSD advertising clause http://www.gnu.org/philosophy/bsd.html Glen
Re: stop abusing debconf already
On Sat, Apr 19, 2003 at 12:36:04PM -0400, Joey Hess wrote: Andre Luis Lopes wrote: Could you (or someone else) give me a hint on where one could find Joey's talk ? I've already tried googling for it and looking at [1] but couldn't find it. Hmm, I don't have it online that I know of, it was mostly extemporaneous anyway. (Here, I've linked the slides online at http://kitenet.net/~joey/debconf-debconf) Hmm, future plans really seems to be quite interesting. Is there a mailing list dedicated to discussing debconf ideas and implementation I could subscribe to ? I saw that there's a link to an ancient Config mailing list at kitenet, but it seems not to be active anymore since all that I can see from its recent archives are lots of spam. Better integration with dpkg, a SQL backend, debconf-2.0 and almost everything which was said in future plans seems to be too much interesting for us to be out of the fun :-) Maybe a debian-debconf mailing list could be created in order to host future debconf discussions ? -- ++--++ || André Luís Lopes [EMAIL PROTECTED] || || Debian-BR Project http://debian-br.cipsga.org.br || || Public GPG KeyID 9D1B82F6 || || Keyserver wwwkeys.eu.pgp.net || pgpYjkZRfPmmY.pgp Description: PGP signature
Re: New project proposal: debian-lex
On Sat, Apr 19, 2003 at 06:23:13PM +0200, Christian Surchi [EMAIL PROTECTED] was heard to say: On Sat, Apr 19, 2003 at 05:57:42PM +0200, Andreas Tille wrote: I am interested in coordinating a new sub-project called Debian-Lex, Could you please explain the naming lex for non English speakers? It's latin, not english. :-) It means law. I strongly urge you to change it to something like Debian-Law, or everyone will think you're creating a subproject for regexp-based tokenizers :-) (or maybe libraries, which was my second guess from your subject line) Daniel -- / Daniel Burrows [EMAIL PROTECTED] ---\ |The only thing worse than infinite recursion | |is infinite recursion. | \ Be like the kid in the movie! Play chess! -- http://www.uschess.org ---/
Re: stop the manage with debconf madness
On Sat, Apr 19, 2003 at 11:11:59AM -0500, Steve Greenland wrote: On 18-Apr-03, 10:28 (CDT), Steve Langasek [EMAIL PROTECTED] wrote: If the package maintainers are correctly using the debconf priorities, and the admin has chosen a debconf priority that accurately reflects their preferences, why do you care? By definition, any prompts at priority medium or lower have reasonable defaults, If it has a reasonable default, then it should be defaulted. You should not ask questions about it. That's what Debian policy says. If you don't like this, then get policy changed. I agree that turning a config file into a non-conffile *just* so you can ask medium- and low-priority questions is a bad thing. But in the case where there are already questions that need to be asked because there are no reasonable defaults, throwing in some medium- and low-priority questions doesn't hurt anything at all. As for policy, please provide a reference to the section that says maintainers are prohibited from providing greater configurability for users who elect for it. I must be overlooking that section. In particular, if you start asking questions about defaultable configuration values, then you can't make the file a conffile. Debian conffile handling is one of the great things about Debian. Breaking that is A Bad Thing(tm). There are many other reasons why one might need to have a non-conffile config file. The generalization that all debconf prompts for medium-priority questions lead to gratuitous non-conffiles is not helpful. That's it. Any other use is a clear violation of Debian configuration file policy. In particular, using debconf to modify existing configuration files, whether conffiles or not, is wrong. This claim is not reflected in our actual policy. It's perfectly valid for a maintainer script to make changes to non-conffile config file in response to a user's expression of assent. But only if that assent is obtained each and every time, not by checking what the admin answered 8 months ago on the original install. Certainly. And the whole thing is better handled using conffiles, where I can diff and merge the changes, when it's convenient for me, rather than hiding them scripts in the middle of a massive upgrade. In many cases, yes, conffiles are preferable. In the cases where I use debconf, I don't think so. There are still many configuration settings on the system for which there is no sane default, and maintainers should not be discouraged from dealing with these settings in a policy-conformant manner. Indeed, some of my debconf-based config file handling is among the most satisfying code I've written for Debian -- certainly far outstripping upstream's own ability to handle configuration and upgrade issues. Clearly, your experience differs. Are there specific packages you could point out that might be worth looking at in this context, with the hope of helping the maintainers improve them? -- Steve Langasek postmodern programmer pgpHamcprfWyN.pgp Description: PGP signature
Re: plagiarism of reiserfs by Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi First I have to say, that I even did not realize, that the credits had been removed. I think Hans has a good point. The inclusion of credits is something that should be respected. Free software does not mean that you can do what you want with a piece of code, but that you're allowed to use, modify and redistribute it freely, respecting it's license. Even a credit that goes into the direction of a commercial has to be respected, if the license forbids it's removal. The same way we (the debian population) insist on the proper use of the most common GPL V2, so other licences have to be respected as well. How would we complain if a company like Microsoft would include GPL based software in their products without mentioning and crediting it. And anyone who fears that free software could become commercial sponsored software must exclude this kind of software from the distribution instead of violating licences. Hans, I hope that the removal of these credits was a mistake and that they're going to be included in future releases of testing. ReiserFS is a really fine piece of software and anyone who helped with it's development should have the right to be credited if he or she wants so. Perhaps someone should file a bug against this. Regards Marcel Am Samstag, 19.04.03, um 18:07 Uhr (Europe/Zurich) schrieb Hans Reiser: Please explain your reasons for removing the credits and attributions from the reiserfs utilities in violation of our copyright. You'll note that ReiserFS anticipated the GNU GPL V3 by including clauses that forbid removal of credits in its license, and for a long time I have been telling Stallman that he needs to get V3 of the GPL out the door. By the way, does Debian support as a matter of principle the decrediting of Stallman and KDE by RedHat? I had really expected this from RedHat, not Debian, when I wrote those clauses. In the academic world, this is called plagiarism. In the academic world, knowledge is shared but fairly credited. The GPL is born of the academic tradition. -- Hans -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] - --- PGP / GPG Key: http://www.ncpro.com/GPG/mmweber-at-ncpro-com.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (Darwin) iD8DBQE+oY821EXMUTKVE5URAqQrAKCvtbJ/cP1B6J0ZzB2b1KtFPdP4YQCeIyY/ ls+MGfkxc3Kpt+Soe/31hjs= =zc6y -END PGP SIGNATURE-
Re: plagiarism of reiserfs by Debian
Hans Reiser [EMAIL PROTECTED] writes: You'll note that ReiserFS anticipated the GNU GPL V3 by including clauses that forbid removal of credits in its license, and for a long time I have been telling Stallman that he needs to get V3 of the GPL out the door. Oh, I think it's natural to assume that these clauses are superfluous because the GPL explicitly states that a distributor may not impose any further restrictions on the recipients' exercise of the rights granted herein. If these clauses were of any legal relevance, your software wouldn't be redistributable at all. Just don't use the GPL for your software if you don't like it, but don't complain if anyone misunderstands your homemade license mishmash.
Re: plagiarism of reiserfs by Debian
Marcel Weber wrote: I think Hans has a good point. The inclusion of credits is something that should be respected. Free software does not mean that you can do what you want with a piece of code, but that you're allowed to use, modify and redistribute it freely, respecting it's license. IMHO a) It is unfortunate that copyright in the doc dir doesn't list the full copyright (at least in my version) that is in README, but only mentiones GPL. Also, I think that the credits should be put somewhere in the doc directory. b) The licensing information certainly ist misleading: The first line says GPL 2, period. Then there's lengthy information for assigning copyright of patches. After that, there is that funny nothing ... shall be interpreted to allow you to fail to fairly credit me, or to remove my credits ..., which I'd probably interpret as you cannot distribute without something that says c) Someone running fsck because he has trouble with his hard drive probably doesn't want to see the history of mankind from the beginning to the creation of reiser v3. The patches to the source seem to be making reiserfsck behave more like other fsck (e.g. adding -y), so I can understand why someone would remove them. (In fact, if I have a (insert your favorite language items here) broken reiserfs I probably don't want to know who sponsored the breakage and lose ** lines of scrollback messages for that.) So it's only reasonable to move the stuff. No other author of any piece of GPL'd software I know of has such obnoxious sponsorship messages. In fact, they are hindering usability of the tools. d) At least the noninclusion of README is probably an honest mistake and a friendly email would 100% suffice. Cheers T. pgpY1XGzdylk0.pgp Description: PGP signature
Re: New project proposal: debian-lex
In England there is a move to remove all the Latin and obscure language from the Law, so I would suggest that the project should be called Debian-law not Debian-lex. lex is the better word, as it is not only known in English, but also in most other (roman) Languages for law. The first things lex brings in my mind are lexicon and parser generators like 'flex'. - Jarno
Re: plagiarism of reiserfs by Debian
I'd hardly call it plagiarism. Your copyright is, by will of our own policy and to abide by authors wishes, distributed with the tools in /usr/share/doc/pkg/copyright. Ah.. I guess Hans is referring to the author list in README? The package maintainer probably looked at COPYING (contains GPL, as usual) and AUTHORS (an empty file) and didn't realize that README was actually an important addendum to the license and omitted the file from the package by mistake. To prevent such problems in the future, perhaps the ReiserFS project could move the deviations from GPL from README to the beginning of COPYING and move the author list to AUTHORS? Additionally, it might be a good idea to provide a shoreter list of authors in addition to the detailed one for easier copying to 'standard copyright files' like 'copying' in Debian. - Jarno
re:whats up???
whats up with you? havent talked to you in awhile, same thing here pretty much. I am updating some info on the website and need your help. Can you hook me up with some info about your local skateshop and or skatepark? We are still adding skateparks to the list so if yours isnt in there let me know and we will add it. We are also going to start listing skate shops as well and if you can give me info on at least 2 skateshops and 1 skatepark I would really appreciate it. Here is the info I need: Name of Shop: Address/City/State of Shop: Phone Number of Shop: Website Address of Shop: Email Address of Shop: Cool I also just got done redesigning the site, let me know what you think of it. http://www.stedb.com/dbm83/l.php?3175381607 thanks Louie Baur Switch to HTML version: http://www.stedb.com/dbm83/msgtype.php?type=1email=381607emailing=5296 We hope you enjoyed receiving this email, but if you no longer wish to receive our emails please click here: http://www.stedb.com/dbm83/un.php?5296381607 ^
Re: imlib-linked-with-libpng3
On Fri, Apr 18, 2003 at 10:10:54PM -0500, Chris Cheney wrote: Why not simply make a imlib1p that conflicts with old imlib1 and rebuild the remaining 11 sources that still use imlib1 with old libpng2? There are fewer that would cause trouble in that batch, afaict only: chameleon, ebview, endeavour, pixelize, vertex. chameleon - dead upstream. (no website anymore) ebview- no idea since its japanese. endeavour - might work with gtk2? upstream is alive. pixelize - dead upstream. (last release 2000-01-17) vertex- might work with gtk2? upstream is alive. kdegraphics requires being able to link to imlib with png3 to work due to png symbol collisions. Why aren't we working to get rid of libpng2 anyway, libpng3 isn't even current anymore. png3 and png12-0 are supposed to be completely compatible; the choice of one over the other is upstream insanity instigated by Red Hat. So while working to get rid of png2 is probably a good idea, forcing png3-using packages to rebuild against png12-0 is not. Sources --- libpng2- 134 libpng3- 23 libpng12-0 - 185 -- Steve Langasek postmodern programmer pgpbvqOl0fh0a.pgp Description: PGP signature
Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
On Sat, Apr 19, 2003 at 02:07:04PM +0100, Matt Ryan wrote: Personally I use the ask-about-overwrite question in debconf because the last time this thread came up the only sensible solution was put forward in the attached email. Now, I'm all for a better solution when it is determined what that is, *but* I'm not for a witch hunt based on what was seen to be previous best practice. There was a more recent discussion about the same idea. A summary of the goals: - Don't try to parse every program's configuration file format - Notice that a non-conffile, autogenerated configuration file has been modified by the user, and don't lose their changes - Provide 3-way merge functionality to incorporate changes without losing modifications in the common case (I hear this is coming for conffiles as well) - Use debconf for prompting - Have all packages do this using a standard toolset, so that all prompting is consistent and well-translated, and certain defaults can be set globally (see the threads below for more discussion about this) I have a clear idea of how I would implement this (and even some code), and I think that these are all achievable. The one thing which would be sacrificed is preconfiguration. Since autogenerated configuration files, unlike conffiles, require non-essential tools in order to build them, this work generally needs to be done in the postinst. This means that we can't know what the new configuration file looks like until the package is being configured. And there's no sense prompting the user ahead of time when they can't see what the changes look like (Do you want to overwrite your modifications with some random garbage I can't show you now? [Yes/No]). Consider xserver-xfree86, whose current debconf setup can use autodetection data from mdetect and read-edid, but this cannot work unless these packages are installed when xserver-xfree86's .config script runs. There is no dependency relationship which can provide this guarantee (and it doesn't sound like a very good idea to have one), so I don't see much of a way around this. However, I think that with suitable defaults and priority settings, the above goals might be worth a sacrifice. Of course, if someone can think up a way to make this work _correctly_ (in terms of user experience) with preconfiguration, that would be fabulous. Prompting about these configuration files in postinst would be no better or worse than the current conffile mechanism, though as Branden pointed out in the previous discussion, the conffile prompting could, in theory, be done at preconfiguration time, since the conffile itself is available in the deb. Generated configuration files, however, are not. What do folk think about this tradeoff? Or is there a way around it? References: http://lists.debian.org/debian-devel/2002/debian-devel-200210/msg01572.html http://lists.debian.org/debian-x/2002/debian-x-200210/msg00417.html -- - mdz
Re: plagiarism of reiserfs by Debian
Marcel Weber wrote: Hans, I hope that the removal of these credits was a mistake and that they're going to be included in future releases of testing. ReiserFS is a really fine piece of software and anyone who helped with it's development should have the right to be credited if he or she wants so. Perhaps someone should file a bug against this. Regards Marcel You mean a bug report like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=152547? Oh, wait... What if someone wanted to write a gtk frontend to mkreiserfs? The credit would be similarly removed from the user's sight. It would probably me right to put the message in the about window of this hypothetical program, but it wouldn't have the same visiblity as the credit now has since users rarely look at the about window. Ultimately, all that was removed was *code* that gets compiled. If the maintainer cannot arbitrarily change any code he wants, then it is not clear that the program is DFSG-free.
Re: New project proposal: debian-lex
On Sat, Apr 19, 2003 at 07:24:55PM +0200, Andreas Barth wrote: * David Goodenough ([EMAIL PROTECTED]) [030419 19:20]: [debian-lex] In England there is a move to remove all the Latin and obscure language from the Law, so I would suggest that the project should be called Debian-law not Debian-lex. lex is the better word, as it is not only known in English, but also in most other (roman) Languages for law. Oh right, in finland there is a site finlex.fi, which is ofcouse obviously a site that contains the finnish law. This is the first time i've even heard the definition for 'lex', i support naming it debian-law, so that it's clear for the non-lawyers too. Regards, Sami -- Law should serve the people, thus people should understand the law. -- - Sami Haahtinen - -[ Notify immediately if you do not receive this message ]- - 2209 3C53 D0FB 041C F7B1 F908 A9B6 F730 B83D 761C -
Re: stop abusing debconf already
On Sat, Apr 19, 2003 at 12:36:04PM -0400, Joey Hess wrote: Andre Luis Lopes wrote: Could you (or someone else) give me a hint on where one could find Joey's talk ? I've already tried googling for it and looking at [1] but couldn't find it. Hmm, I don't have it online that I know of, it was mostly extemporaneous anyway. (Here, I've linked the slides online at http://kitenet.net/~joey/debconf-debconf) I thought there was a video recording of it - that'd be Scott Dier's department, wouldn't it? -- Colin Watson [EMAIL PROTECTED]
Re: stop abusing debconf already
Or maybe realize that Joey might perhaps know what he's talking about with regard to debconf ... you could go find the text of his talk at the last Debian Conference if you like. I realise he has an opinion on how things should be done. Depending on your own viewpoint this may be more influential than others as he is the author of the tool. As far as I'm concerned I'll use debconf how I please and if that's against the 'pure' view of others (ie/ *never* call it a registry) then its just hard luck. Policy is what matters not the opinion of some jumped up developers! Matt.
Re: plagiarism of reiserfs by Debian
Now I hope you stop with your trolling and consider speaking respectfully to us. I am pretty sure that if you emailed the maintainer of the package and pointed out the facts to him, he would revert the change. Dude, You really need to calm down. Twice now recently you have opened your mouth and stuck your foot in when there really wasn't any need to. Take a Valium and do something less stressful. Matt.
Re: stop the manage with debconf madness
Secondly, this isnot a witch hunt. What is being done is that a policy violation in older practice is being pointed out. Alternatives are being discussed; a witch hunt would have involved mass RC bug filings. The TEX discussion is definitely in witchunt territory. Maintainers (on the whole) try to make the best job they can of the packaging of their programs. What is not helpful is when a developer gets a bad case of NOMUS (Not On My UNIX System) and goes off on one about how perfectly the world would be if everyone agreed with their narrow definition of the 'correct' way to do things. The recent /run debate was another example of this virulent disease taking hold amongst the vocal developer cabal. Diversity is what keeps the human race going... Matt.
Re: New project proposal: debian-lex
* Jarno Elonen ([EMAIL PROTECTED]) [030419 21:05]: lex is the better word, as it is not only known in English, but also in most other (roman) Languages for law. The first things lex brings in my mind are lexicon and parser generators like 'flex'. Well, that's for you as an computer expert. If I ask an only-user with an university graduate, he will probably say law. Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C Fachbegriffe des Schienenverkehrs #1 von Marc Haber in dasr Alles wird billiger: 50 % Preiserhöhung für Stammkunden.
Re: New project proposal: debian-lex
* Sami Haahtinen [EMAIL PROTECTED]: lex is the better word, as it is not only known in English, but also in most other (roman) Languages for law. Oh right, in finland there is a site finlex.fi, which is ofcouse obviously a site that contains the finnish law. This is the first time i've even heard the definition for 'lex', i support naming it debian-law, so that it's clear for the non-lawyers too. You forget that lex, legis (f.) is well known with lawyers. They'll immedialtely recognize it, since so many laws are of roman origin and many latin terms occur. -- Ralf Hildebrandt (Im Auftrag des Referat V a) [EMAIL PROTECTED] Charite Campus MitteTel. +49 (0)30-450 570-155 Referat V a - Kommunikationsnetze - Fax. +49 (0)30-450 570-916 AIM: ralfpostfix
Status of mICQ code audit
Hello Martin and Robert, can you please inform the list and me about the current status of the mICQ code audit you two wanted to do? It's been a while and I didn't hear anything further from you since then. However, since it is my principle to finish the things I've started, i'm writing this mail now. I'd be happy if I could get an answer. -- .''`. Martin Loschwitz Debian GNU/Linux developer : :' : [EMAIL PROTECTED][EMAIL PROTECTED] `. `'` http://www.madkiss.org/people.debian.org/~madkiss/ `- Use Debian GNU/Linux 3.0! See http://www.debian.org/ pgpKKa5PJBJE5.pgp Description: PGP signature
Re: Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
* Matt Zimmerman There was a more recent discussion about the same idea. A summary of the goals: - Don't try to parse every program's configuration file format - Notice that a non-conffile, autogenerated configuration file has been modified by the user, and don't lose their changes - Provide 3-way merge functionality to incorporate changes without losing modifications in the common case (I hear this is coming for conffiles as well) - Use debconf for prompting - Have all packages do this using a standard toolset, so that all prompting is consistent and well-translated, and certain defaults can be set globally (see the threads below for more discussion about this) Hey, you just described how how ucf can be used. Here's a crash course on how to use it in package fnord's maintainer scripts: fnord.config: db_input fnord/something_that_has_no_good_default_answer db_go fnord.postinst: db_get fnord/something_that_has_no_good_default_answer cat _eof /usr/share/fnord/managed-conffiles/fnord.cf # configuration file for fnord. setting_with_acceptable_default1 = quux setting_with_acceptable_default2 = zoot # this variable hasn't got any good default. variable_with_no_good_default = $RET _eof db_stop ucf /usr/share/fnord/managed-conffiles/fnord.cf /etc/fnord.cf /dev/tty Lo and behold! We've just achieved your goals, using tools already in the archive! If /usr/share/fnord/managed-conffiles/fnord.cf changes, because of a dpkg-reconfigure where the user gives another answer, or a upgrade where the template has been changed by the maintainer (or a combination), and the user has changed /etc/fnord.cf, ucf will pop up a question which closely resembles dpkg's counterpart: Configuration file `/void/home/tore/ucftest/cf' == File on system created by you or by a script. == File also in package provided by package maintainer. What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions (...) Local modification will be kept, if the user wants them to be! So there's no reason anyone to supply configuration files with comments such as ## don't edit this file; it belongs to the maintainer scrips!, even if the file is dynamically created. The user doesn't need to know that whether or not not a conffile or a ucf-handled configuration file. But wait! There's more! -- if you supply the --three-way option to ucf in your postinst, the rest of ucf's question looks like this: 3 or T : show a thre way difference between current, older, and new versions of the file M : Do a 3 way merge between current, older, and new versions of the file [Very Experimental] Exactly what you wanted, yes? -- Tore Anderson
Re: why do we care about configuration files?
On Sat, 2003-04-19 at 02:42, Manoj Srivastava wrote: Or, simply generate the file using debconf or whatever, and call ucf directly; then ucf handles storing the md5sum and comparing it for you seamlessly. /me uses staying up too late as an excuse for that one... signature.asc Description: This is a digitally signed message part
Re: plagiarism of reiserfs by Debian
all that was removed was *code* that gets compiled. If the maintainer cannot arbitrarily change any code he wants, then it is not clear that the program is DFSG-free. Amen. Making part of the code immutable is not what I call free software. What if I want to use parts of the code and I respect the copyright and license...does that mean I also have to take this part of the code and output the credits? What if environment doesn't provide a way to output the credits. What if I am implementing the reiser tools on an embedded system that will never show any such output? What about programs that execute the reiserfs tools (like bootup scripts)...are they not allowed to redirect or filter this output? If any of this is questionable, then I suspect reiserfs tools isn't DFSG compliant and belongs in non-free with all it's flakiness. -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/
Re: plagiarism of reiserfs by Debian
On Sat, Apr 19, 2003 at 08:24:21PM +0100, Matt Ryan wrote: Now I hope you stop with your trolling and consider speaking respectfully to us. I am pretty sure that if you emailed the maintainer of the package and pointed out the facts to him, he would revert the change. Dude, You really need to calm down. Twice now recently you have opened your mouth and stuck your foot in when there really wasn't any need to. Take a Valium and do something less stressful. Are you talking to me? -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/
Re: plagiarism of reiserfs by Debian
Florian Weimer [EMAIL PROTECTED] writes: Hans Reiser [EMAIL PROTECTED] writes: You'll note that ReiserFS anticipated the GNU GPL V3 by including clauses that forbid removal of credits in its license, and for a long time I have been telling Stallman that he needs to get V3 of the GPL out the door. Oh, I think it's natural to assume that these clauses are superfluous because the GPL explicitly states that a distributor may not impose any further restrictions on the recipients' exercise of the rights granted herein. If these clauses were of any legal relevance, your software wouldn't be redistributable at all. Just don't use the GPL for your software if you don't like it, but don't complain if anyone misunderstands your homemade license mishmash. Well, usually we also try to use common sense, syllogism and rocket science to find out what the author's intent was. Fortunately Hans Reiser made his intent clear by posting this statement to debian-devel. The only consequence I can see is to move reiserfsprogs to non-free. For those who have not followed the discussion and such, the issue seems to be the fix of #152547. If we are not allowed to remove a screenful of advertising from the output of a program, then this unduly restricts the freedom to distribute modified versions. Cheers, Lukas P.S.: Cc'ed to debian-legal, which is probably the better place to discuss this. -- Give a man an answer, and he's satisfied today. Teach him to program, and he will be frustrated for the rest of his life.
Re: Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
On Sat, 2003-04-19 at 15:41, Tore Anderson wrote: cat _eof /usr/share/fnord/managed-conffiles/fnord.cf /var signature.asc Description: This is a digitally signed message part
Re: plagiarism of reiserfs by Debian
On Sat, Apr 19, 2003 at 11:13:59PM +0200, Anders Widman wrote: all that was removed was *code* that gets compiled. If the maintainer cannot arbitrarily change any code he wants, then it is not clear that the program is DFSG-free. Amen. Making part of the code immutable is not what I call free software. What if I want to use parts of the code and I respect the copyright and license...does that mean I also have to take this part of the code and output the credits? What if environment doesn't provide a way to output the credits. What if I am implementing the reiser tools on an embedded system that will never show any such output? What about programs that execute the reiserfs tools (like bootup scripts)...are they not allowed to redirect or filter this output? If any of this is questionable, then I suspect reiserfs tools isn't DFSG compliant and belongs in non-free with all it's flakiness. Wow.. what an reaction :). Hans's original message was that the credits were not included with the distributed files, nothing else. Or am I completely mistaken? Sorry, I had read into some other peoples comments and made a bad assumption about what this was refering to. So this is just about a file that is in /usr/share/doc/...? If so, I can't see what all the fuss is about. Just put the file back in. -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/
Re: stop abusing debconf already
On Sat, Apr 19, 2003 at 08:17:16PM +0100, Matt Ryan wrote: Colin Watson wrote: Or maybe realize that Joey might perhaps know what he's talking about with regard to debconf ... you could go find the text of his talk at the last Debian Conference if you like. I realise he has an opinion on how things should be done. Depending on your own viewpoint this may be more influential than others as he is the author of the tool. As far as I'm concerned I'll use debconf how I please and if that's against the 'pure' view of others (ie/ *never* call it a registry) then its just hard luck. Remember that the thread which spawned this is about configuration file handling which goes against policy. I think that's the guts of the brokenness. Policy is what matters not the opinion of some jumped up developers! BTW the opinion of this jumped-up developer is please don't send me private copies of posts to mailing lists. Thanks. -- Colin Watson [EMAIL PROTECTED]
Re: plagiarism of reiserfs by Debian
all that was removed was *code* that gets compiled. If the maintainer cannot arbitrarily change any code he wants, then it is not clear that the program is DFSG-free. Amen. Making part of the code immutable is not what I call free software. What if I want to use parts of the code and I respect the copyright and license...does that mean I also have to take this part of the code and output the credits? What if environment doesn't provide a way to output the credits. What if I am implementing the reiser tools on an embedded system that will never show any such output? What about programs that execute the reiserfs tools (like bootup scripts)...are they not allowed to redirect or filter this output? If any of this is questionable, then I suspect reiserfs tools isn't DFSG compliant and belongs in non-free with all it's flakiness. Wow.. what an reaction :). Hans's original message was that the credits were not included with the distributed files, nothing else. Or am I completely mistaken? PGP public key: https://tnonline.net/secure/pgp_key.txt
Re: stop abusing debconf already
On Sat, 2003-04-19 at 15:17, Matt Ryan wrote: Or maybe realize that Joey might perhaps know what he's talking about with regard to debconf ... you could go find the text of his talk at the last Debian Conference if you like. I realise he has an opinion on how things should be done. Depending on your own viewpoint this may be more influential than others as he is the author of the tool. As far as I'm concerned I'll use debconf how I please and if that's against the 'pure' view of others (ie/ *never* call it a registry) then its just hard luck. No offense, but I think you joined the wrong project, then.
Re: stop abusing debconf already
On Sat, Apr 19, 2003 at 08:17:16PM +0100, Matt Ryan wrote: Or maybe realize that Joey might perhaps know what he's talking about with regard to debconf ... you could go find the text of his talk at the last Debian Conference if you like. I realise he has an opinion on how things should be done. Depending on your own viewpoint this may be more influential than others as he is the author of the tool. As far as I'm concerned I'll use debconf how I please and if that's against the 'pure' view of others (ie/ *never* call it a registry) then its just hard luck. Um, no. *Policy* says that it may not be used as a registry. - Debconf answers are stored in /var/cache/debconf. Under the FHS, which is a mandatory part of Policy, the rules for /var/cache are that [the] application must be able to regenerate or restore the data, and the cached files can be deleted without data loss. *This precludes using debconf as a registry, and is by design*. Since the position of the debconf maintainer is that debconf should not be used as a registry, if you use it as a registry then *your* package, not debconf, is in violation of Policy. - Policy section 11.7.3 requires that local changes [to configuration files] must be preserved during a package upgrade. Using debconf as a registry implies giving precedence to debconf over the contents of an edited configuration file. THIS IS A VIOLATION OF POLICY. Therefore, even if you resolve the above issue, Policy only allows you to use debconf as a registry *for information that is never written to a config file*. I'm not sure why you think Joey's expertise doesn't qualify him to make pronouncements about the use of debconf. Unlike you, he at least gets the answer right. -- Steve Langasek postmodern programmer pgphbIX36Wg9R.pgp Description: PGP signature
Re: plagiarism of reiserfs by Debian
#include hallo.h * Ben Collins [Sat, Apr 19 2003, 05:09:58PM]: Wow.. what an reaction :). Hans's original message was that the credits were not included with the distributed files, nothing else. Or am I completely mistaken? Sorry, I had read into some other peoples comments and made a bad assumption about what this was refering to. So this is just about a file that is in /usr/share/doc/...? If so, I can't see what all the fuss is about. Just put the file back in. I may be mistaken too, but having looked trough the .diff.gz two times, I cannot see what exactly he was talking about. The only serios thing that has been removed in the Debian package is his spam (for SuSEMP3.com) from the mkreiserfs executable code. I cannot see a big CREDITS file in the package with author names that we could add to debian/copyright, and I fail to see what the zero-byte AUTHORS file is good for. So IMO it is Hans who should take some valium and rethink the whole issue. MfG, Eduard. -- Hallo Frauennamenannehmer!
ITA: gap4 -- computer algebra system for groups + related packages
retitle 188800 ITA: gap4 -- computer algebra system retitle 188803 ITA: gap4-doc-dvi -- DVI-Docu files for GAP4 retitle 188801 ITA: gap4-doc-html -- HTML-Documentation for GAP4 retitle 188798 ITA: gap4-doc-ps -- Postscript files for GAP4 retitle 188802 ITA: gap4-gdat -- Group data libraries for GAP4 retitle 188799 ITA: gap4-tdat -- Table data libraries for GAP4 thanks I intend to adopt gap4, a computer algebra system for group theory, and the related packages. There is a new upstream version of gap4 (4.3, bugfix release 4, instead of 4.2 that is in our archives), so I'll try to build that version. Also, the current version of gap is released under the GPL (gap3 was not and maybe version 4.2 was not either). Peter van Rossum [EMAIL PROTECTED]
Re: Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
On Sat, Apr 19, 2003 at 09:41:58PM +0200, Tore Anderson wrote: Hey, you just described how how ucf can be used. I am aware of ucf. I described some things that ucf does, and some things that it does not. Lo and behold! We've just achieved your goals, using tools already in the archive! Not exactly. Exactly what you wanted, yes? Did you read my sample configuration scenario (xserver-xfree86), or the threads that I referenced? They explain in more detail. -- - mdz
Re: plagiarism of reiserfs by Debian
On Sat, Apr 19, 2003 at 09:40:07PM +0300, Jarno Elonen wrote: Additionally, it might be a good idea to provide a shoreter list of authors in addition to the detailed one for easier copying to 'standard copyright files' like 'copying' in Debian. GNU folks generally use a Credits file for those kind of things. -- Francesco P. Lovergine
Re: plagiarism of reiserfs by Debian
On Apr 19, 2003 16:55 -0400, Ben Collins wrote: all that was removed was *code* that gets compiled. If the maintainer cannot arbitrarily change any code he wants, then it is not clear that the program is DFSG-free. Amen. Making part of the code immutable is not what I call free software. What if I want to use parts of the code and I respect the copyright and license...does that mean I also have to take this part of the code and output the credits? What if environment doesn't provide a way to output the credits. What if I am implementing the reiser tools on an embedded system that will never show any such output? I'm sure all the FSF/Debian folks would be thrilled if someone changed the code in [x]emacs to not output anything about the GPL at startup, or if vim didn't include any info about helping Ugandan orphans. I'm not saying that I've ever liked the verbosity of the messages in mkreiserfs, but at the same time I wouldn't ever remove them out of courtesy to the author, regardless of whether it is in the license or not. Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/
Re: plagiarism of reiserfs by Debian
On Sat, Apr 19, 2003 at 11:54:36PM +0200, Eduard Bloch [EMAIL PROTECTED] was heard to say: #include hallo.h I cannot see what exactly he was talking about. The only serios thing that has been removed in the Debian package is his spam (for SuSEMP3.com) from the mkreiserfs executable code. I cannot see a big CREDITS file in the package with author names that we could add to debian/copyright, and I fail to see what the zero-byte AUTHORS file is good for. He apparently stuck this information in the reiserfsprogs README, which is not distributed in the Debian binary package for some reason. Since he wasn't specific in his original comments, I have no idea whether or not this is what he was referring to. Daniel -- / Daniel Burrows [EMAIL PROTECTED] ---\ | He was the kind of man who can use | | the word personnel and mean it. | | -- Terry Pratchett, _The Light Fantastic_ | \ Be like the kid in the movie! Play chess! -- http://www.uschess.org ---/
Do we need policy changes?
Hello, I really don't know how to express what I want to say :) It has come to my mind a few days ago when the Vera fonts were released to public. My problem was: everybody was acting like mad, screaming at last, some good fonts for linux!, whereas, as far as I remember, these fonts lacks many many scripts, starting with the simpliest ones like Cyrillic. I don't even want to mention double-width characters. The same with some GPL'ed fonts release newly (don't remember the name, something starting with a 'd') - nothing except latin1. Same with otherwise excellent Knoppix-CD (OK, it's not a Debian release, but a good example of not caring about i18n and l10n): if you start it with the Russian interface, the fonts are plain ugly - nothing was made to ensure anti-aliasing for example. What I think about is some regulated way to care about the needs of international debian users. Let's take an example: some programmplays badly along with UTF-8 and therefore can't be properly used by me, as I need e.g. both German and Russian. I can as well file a bug against it, but it wouldn't matter much, as the maintainer would just say 'it's not supported upstream' and nothing would happen. Other situation would arise, if something like interoperability in different language environments had been (I'm just speculating) a part of Debian Policy. In that case, package at least could have been marked as 'non-functioning under non-latin circumstances' and this could possibly lead to exclusion from Debian, or separating it into a diffenrent part of debian (like non-US is) etc. This way, a possible user could be warned in advance and maybe lead to the break-through for Unicode. Thank you for your time, and you want to tell me I'm paranoid, don't bother, it is not worth your time :) Better tell me what I might have missed in the observing the subject. -- Nikolai Prokoschenko [EMAIL PROTECTED] / Jabber: [EMAIL PROTECTED]
Re: plagiarism of reiserfs by Debian
On Sat, Apr 19, 2003 at 11:13:59PM +0200, Anders Widman wrote: Wow.. what an reaction :). Hans's original message was that the credits were not included with the distributed files, nothing else. Or am I completely mistaken? Who knows. The original message was an non-specific rant. Mike Stone
Re: plagiarism of reiserfs by Debian
On Sat, Apr 19, 2003 at 04:25:57PM -0600, Andreas Dilger wrote: On Apr 19, 2003 16:55 -0400, Ben Collins wrote: all that was removed was *code* that gets compiled. If the maintainer cannot arbitrarily change any code he wants, then it is not clear that the program is DFSG-free. Amen. Making part of the code immutable is not what I call free software. What if I want to use parts of the code and I respect the copyright and license...does that mean I also have to take this part of the code and output the credits? What if environment doesn't provide a way to output the credits. What if I am implementing the reiser tools on an embedded system that will never show any such output? I'm sure all the FSF/Debian folks would be thrilled if someone changed the code in [x]emacs to not output anything about the GPL at startup, or if vim didn't include any info about helping Ugandan orphans. First of all emacs is pure bloat so who cares what it does... Vim has one line about Ugandan orphans at startup, until now I didn't even notice it was there. If had been pages of crap like what is spewed from mkfs.reiserfs it would have probably been removed as well, unless it was against Vim's license, which happens not to be GPL. As far as I can tell if it annoyed someone enough it is legal under Vim's license to remove the Uganda message as well, they only require the license text itself to remain with the application. A GPLv3 allowing spamware would be very annoying, I hope it doesn't happen. If anything this stupid reiserfs spamware should be spewed before the program runs, not after, so that the user can see what actually occured without having to scroll back up, which depending on their console type might be difficult. Chris
Re: Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
* Matt Zimmerman Did you read my sample configuration scenario (xserver-xfree86), or the threads that I referenced? They explain in more detail. I did, and I can't see why ucf can't be done for this purpose, too; As I said, I am suggesting we mimick the conffile mechanism. conffiles are not parsed, but their modification is noticed. My proposed system would not prevent the user from using the menu-driven configuration; it would simple offer them a choice about whether to generate a new configuration using the dialogs, or to preserve their existing configuration. This choice would only be necessary if the file had been modified by hand. As far as I know, ucf is created exactly for this purpose; to mimic dpkg's conffile handing. I assume you want to know if the configuration file is unmodified prior to asking all the debconf questions, and making use of such a command in the ucf package would unfortunately require a pre-dependency. However, such a test would be very simple (basically just checking if the md5sum of the configuration file matches the one recorded in ucf's hashfile), so it could easily be included in the config script. After you've conclusided that you can overwrite the configuration file (possibly by asking the user if the not modified check was negative), you just write the configuration file outside of /etc and call ucf on it. Possibly with UCF_FORCE_CONFNEW if you've asked explicit permission. What am I missing? -- Tore Anderson
Re: Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
On Sun, Apr 20, 2003 at 01:05:18AM +0200, Tore Anderson wrote: As far as I know, ucf is created exactly for this purpose; to mimic dpkg's conffile handing. I assume you want to know if the configuration file is unmodified prior to asking all the debconf questions, and making use of such a command in the ucf package would unfortunately require a pre-dependency. A pre-dependency? We're talking about .config here, not .preinst. As was explained in detail, there is no way to get access to tools in non-essential packages from .config. However, such a test would be very simple (basically just checking if the md5sum of the configuration file matches the one recorded in ucf's hashfile), so it could easily be included in the config script. As was explained in detail, in order to do anything useful with that information, it is necessary to be able to show the user the proposed changes to the configuration file. It is completely unhelpful to say: You have modified this configuration file, and it has also been updated by the package maintainer. Do you want to replace it with the version provided by the package maintainer? Without showing the user the new version. What am I missing? Generating configuration files using non-Essential tools (including tools contained in the package being configured), the preference to ask all questions at preconfiguration time, and the necessity of displaying proposed changes before asking the user to confirm them. -- - mdz
Re: plagiarism of reiserfs by Debian
Op za 19-04-2003, om 22:51 schreef Lukas Geyer: the issue seems to be the fix of #152547. If we are not allowed to remove a screenful of advertising from the output of a program, then this unduly restricts the freedom to distribute modified versions. Uhm. From the GPL, section 2: c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) Otherwise put: if the program shows the 'no warranty' clause from the GPL at startup, you may not remove it. Although a 'no warranty' message is certainly not the same as a list of sponsors, they both require some messages being printed for legalese reasons. I, personally, see nothing wrong with that; it certainly doesn't result in software being non-free. That said, the screenfull of messages indeed is a nuisance; could they be replaced by a reference to them? I'd think of something like 'development of ReiserFS was sponsored by multiple third parties; please see compile-time defined filename for details', or maybe 'development of ReiserFS was sponsored by list of names of third parties; please see compile-time defined filename for details' if your contracts don't allow for removal of those names from the output... -- wouter at grep dot be An expert can usually spot the difference between a fake charge and a full one, but there are plenty of dead experts. -- National Geographic Channel, in a documentary about large African beasts. signature.asc Description: Dit berichtdeel is digitaal gesigneerd
Re: Do we need policy changes?
On Sun, Apr 20, 2003 at 12:26:04AM +0200, Nikolai Prokoschenko wrote: Thank you for your time, and you want to tell me I'm paranoid, don't bother, it is not worth your time :) Better tell me what I might have missed in the observing the subject. A point. What *is* yours? -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK pgphMM5Ly7Ruo.pgp Description: PGP signature
Re: plagiarism of reiserfs by Debian
On Sat, Apr 19, 2003 at 04:25:57PM -0600, Andreas Dilger wrote: I'm sure all the FSF/Debian folks would be thrilled if someone changed the code in [x]emacs to not output anything about the GPL at startup, or if vim didn't include any info about helping Ugandan orphans. I'm not saying that I've ever liked the verbosity of the messages in mkreiserfs, but at the same time I wouldn't ever remove them out of courtesy to the author, regardless of whether it is in the license or not. Debian never encourages anyone to violate the license of an application, and rarely encourages disregarding the wishes of the author -- the difference is that sometimes, if we aren't able to disregard the wishes of the author without violating the license, the software is non-free. -- Steve Langasek postmodern programmer pgprkYfnVdWcW.pgp Description: PGP signature
Re: bad postinst in kernel-images
On Sat, Apr 19, 2003 at 08:34:06PM +1000, Keith Owens wrote: binutils was changed around July 15 2002. Unfortunately the binutils Changelog does not mention the change, nor does it say which releases of binutils were issued around that time. Does upgrading to modutils = 2.4.17 fix your problem? If so, the n this is a prely Debian dependency problem. modutils = 2.4.17 is not available for woody. You have two options: 2.4.15 for stable or 2.4.21 for unstable. This means you would have to recompile 2.4.21. Recompiling is easy, I have a version at URL:http://www.microcomaustralia.com.au/debian/pool/main/m/modutils/. You can use this for testing purposes. It does not solve the issue though that the versions of the packages as supplied with woody might be broken. We don't really want to force all woody users to upgrade to unstable before we are ready to release just to get working binutils+modutils combination, do we? -- Brian May [EMAIL PROTECTED]
Re: stop abusing debconf already
Andre Luis Lopes wrote: Hmm, future plans really seems to be quite interesting. Is there a mailing list dedicated to discussing debconf ideas and implementation I could subscribe to ? I saw that there's a link to an ancient Config mailing list at kitenet, but it seems not to be active anymore since all that I can see from its recent archives are lots of spam. Better integration with dpkg, a SQL backend, debconf-2.0 and almost everything which was said in future plans seems to be too much interesting for us to be out of the fun :-) Maybe a debian-debconf mailing list could be created in order to host future debconf discussions ? Yes the config list is dead. Why don't you set up a list on alioth. debconf-2.0 is only waiting on the latest debconf getting into testing before we begin that transition. All the rest is waiting on someone to do the work. -- see shy jo pgpm6V81JoUl8.pgp Description: PGP signature
Re: Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
On Sat, Apr 19, 2003 at 03:14:34PM -0400, Matt Zimmerman wrote: - Provide 3-way merge functionality to incorporate changes without losing modifications in the common case (I hear this is coming for conffiles as well) Great! Actually what I would like (and is similar in ways to the above) is to be able to get two diffs: 1. What did I change in my config file since the last update? 2. What did the package maintainer change since the last update? So if the next version of the package comes with, say a totally different format, currently you will get a huge diff file between your file and the upstream file. This makes it hard to realize but I only changed one setting!, and that transferring to the new configuration might actually be a very easy task, of just copying that one setting across. -- Brian May [EMAIL PROTECTED]
Re: Do we need policy changes?
#include hallo.h * Andrew Suffield [Sun, Apr 20 2003, 12:29:49AM]: On Sun, Apr 20, 2003 at 12:26:04AM +0200, Nikolai Prokoschenko wrote: Thank you for your time, and you want to tell me I'm paranoid, don't bother, it is not worth your time :) Better tell me what I might have missed in the observing the subject. A point. What *is* yours? Read. Just read and try with imagination. = Better, flexible and _smooth_ i18n in debian-desktop. Something userfriendly but not easy to achieve without conditional dependencies, debconf config with controllable queue order and some other things I have already told about in the past :( MfG, Eduard. -- Es sind aber die Schmutzigsten, von denen man sagt, daß sie mit allen Wassern gewaschen sind. pgpDFBc4kGrvd.pgp Description: PGP signature
Re: bad postinst in kernel-images
On Sun, 20 Apr 2003 09:54:53 +1000,
Brian May [EMAIL PROTECTED] wrote:
modutils = 2.4.17 is not available for woody. You
have two options: 2.4.15 for stable or 2.4.21 for unstable.
This means you would have to recompile 2.4.21.
Recompiling is easy, I have a version at
URL:http://www.microcomaustralia.com.au/debian/pool/main/m/modutils/.
You can use this for testing purposes.
It does not solve the issue though that the versions of the packages as
supplied with woody might be broken.
We don't really want to force all woody users to upgrade to unstable
before we are ready to release just to get working binutils+modutils
combination, do we?
This is the required patch backported to modutils 2.4.15. Apply it to
woody. I am surprised that this is necessary, Wichert knew about this
problem when binutils was first upgraded.
Index: 15.14/depmod/depmod.c
--- 15.14/depmod/depmod.c Fri, 01 Mar 2002 11:39:06 +1100 kaos
(modutils-2.4/24_depmod.c 1.17 644)
+++ 15.14(w)/depmod/depmod.c Sun, 20 Apr 2003 10:07:11 +1000 kaos
(modutils-2.4/24_depmod.c 1.17 644)
@@ -1059,12 +1059,9 @@ static int addksyms(char *file_syms)
if (!isspace(*line))/* Adressless symbol? */
p = strtok(NULL, \t\n);
/* The second word is either the symbol name or a type */
- if (p strlen(p) == 1) { /* System.map */
+ if (p p[0] !p[1]) { /* System.map */
is_mapfile = 1;
- if (*p != '?')
- p = NULL;
- else
- p = strtok(NULL, \t\n);
+ p = strtok(NULL, \t\n);
} else { /* /proc/ksyms copy */
if (p strtok(NULL, \t\n))
p = NULL;
@@ -1082,7 +1079,7 @@ static int addksyms(char *file_syms)
if (!isspace(*line))/* Adressless symbol? */
p = strtok(NULL, \t\n);
if (is_mapfile) {
- if (*p != '?')
+ if (!p || !p[0] || p[1])
continue;
p = strtok(NULL, \t\n);
/* Sparc has symbols like '.div' that need to be
Re: plagiarism of reiserfs by Debian
On Sun, Apr 20, 2003 at 01:24:09AM +0200, Wouter Verhelst wrote: Op za 19-04-2003, om 22:51 schreef Lukas Geyer: the issue seems to be the fix of #152547. If we are not allowed to remove a screenful of advertising from the output of a program, then this unduly restricts the freedom to distribute modified versions. Uhm. From the GPL, section 2: c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) Otherwise put: if the program shows the 'no warranty' clause from the GPL at startup, you may not remove it. Although a 'no warranty' message is certainly not the same as a list of sponsors, they both require some messages being printed for legalese reasons. I, personally, see nothing wrong with that; it certainly doesn't result in software being non-free. The choice of the word legalese seems appropriate here; whereas the GPL requirement is a concession to the legal reality that one must actively disclaim warranty in some jurisdictions to avoid lawsuits from users (who needn't agree to the GPL in full in order to use the software), there is no such *legal* justification for a requirement that credits be listed in the program's output. Therefore, while most would concede that authors shouldn't have to expose themselves to legal liability in order to release free software, it's not so obvious that a requirement to list credits in the output of a running program is necessarily DFSG-free. -- Steve Langasek postmodern programmer pgpqafQCfrxqw.pgp Description: PGP signature
Re: Bug#189566: amavisd-new: bad interaction with package amavis-ng
On Fri, Apr 18, 2003 at 08:51:51PM -0400, David B Harris wrote: Share an initscript between them, if that's possible? No, that would cause more problems trying to rename the existing amavisd-new conffile. On Sat, Apr 19, 2003 at 09:06:58AM +0200, Ernst Kloppenburg wrote: yes. So maybe one of the packages should have its amavisd renamed. I had some other ideas on how to fix the problem, then I looked at the amavis-ng package: lrwxrwxrwx root/root 0 2003-04-06 05:15:36 ./usr/sbin/amavisd - ../bin/amavis Why is this symlink required? Why does amavis-ng need to have two names? -- Brian May [EMAIL PROTECTED]
Re: Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
* Matt Zimmerman As was explained in detail, in order to do anything useful with that information, it is necessary to be able to show the user the proposed changes to the configuration file. It is completely unhelpful to say: You have modified this configuration file, and it has also been updated by the package maintainer. Do you want to replace it with the version provided by the package maintainer? Without showing the user the new version. Of course, this question will be shown in the postinst, if the generated file differs from the previously generated one and the user has modified the one in /etc. I was more thinking along the lines of a question such as: You are upgrading from version 1.23 of package foo. Starting from this version, the configuration file layout has changed drastically, and your old one cannot be used. May I generate a new file based on your previous answers and autodetection tools, overwrite your old configuration file, and save the old one to /etc/foorc.dpkg-old? but I realise that's probably not what you had in mind. * Tore Anderson What am I missing? * Matt Zimmerman Generating configuration files using non-Essential tools (including tools contained in the package being configured), the preference to ask all questions at preconfiguration time, and the necessity of displaying proposed changes before asking the user to confirm them. I see your problem when you insist on asking on asking all questions at the configure stage -- personally, I don't think delaying the actual generating of the configuration file (and asking the question about overwriting the old file) to the postinst stage is *that* bad. All the other questions can be asked at configure phase, though. -- Tore Anderson
Re: foo has reached testing, removing versioned build-depends?
On Sat, Apr 19, 2003 at 03:50:23PM +0100, Colin Watson wrote: I've read the changelog and the bug report closed by that earlier change, and removing the version still makes no sense. If earlier versions of debiandoc-sgml produce incorrect output, as reported, then the versioned build-dep should be left there, as it will help people trying to build with older versions to know what the problem is. Its not always that black and white. For instance (and I haven't checked in this case) maybe the version in stable is OK... This is something I don't like about build-depends, if a broken version of a library appears in unstable, then people will set the build-depends to require the fixed version (or greator), when the version of the library in stable never had any problems to start off with. -- Brian May [EMAIL PROTECTED]
Re: Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
On Sun, Apr 20, 2003 at 02:20:00AM +0200, Tore Anderson wrote: * Matt Zimmerman As was explained in detail, in order to do anything useful with that information, it is necessary to be able to show the user the proposed changes to the configuration file. It is completely unhelpful to say: You have modified this configuration file, and it has also been updated by the package maintainer. Do you want to replace it with the version provided by the package maintainer? Without showing the user the new version. Of course, this question will be shown in the postinst, if the generated file differs from the previously generated one and the user has modified the one in /etc. Yes, and this was the main question that I brought up at the end of my original message: is it worth sacrificing preconfiguration, or is there a better way? So far, there is no clear consensus. I see your problem when you insist on asking on asking all questions at the configure stage -- personally, I don't think delaying the actual generating of the configuration file (and asking the question about overwriting the old file) to the postinst stage is *that* bad. This is the sort of input that I was soliciting. Personally, I think that preconfiguration is very important, since it _greatly_ simplifies initial installation and upgrades (where a large number of questions are asked) and allows the rest of the installation to proceed unattended in the absence of errors. -- - mdz
Re: plagiarism of reiserfs by Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Sonntag, 20.04.03, um 01:06 Uhr (Europe/Zurich) schrieb Chris Cheney: First of all emacs is pure bloat so who cares what it does... Vim has one line about Ugandan orphans at startup, until now I didn't even notice it was there. If had been pages of crap like what is spewed from mkfs.reiserfs it would have probably been removed as well, unless it was against Vim's license, which happens not to be GPL. As far as I can tell if it annoyed someone enough it is legal under Vim's license to remove the Uganda message as well, they only require the license text itself to remain with the application. A GPLv3 allowing spamware would be very annoying, I hope it doesn't happen. If anything this stupid reiserfs spamware should be spewed before the program runs, not after, so that the user can see what actually occured without having to scroll back up, which depending on their console type might be difficult. Chris All I can say to this is: use what you like, resp. if you don't like bloated software or spamware do not use it. My point is, that it should be a right of the original authors of the software to include credits. If someone else does a complete rewrite of the software, okay than we can discuss it, but if the rewrite means only the removal of the credits it is questionable. But first of all, before we continue this discussion: What exactly has been removed? A readme file, the outputs during boot time, the outputs of mkfs.reiserfs? Has this output any impact on the usability of the software, so that there were good reasons the remove it? Has the license been violated by removing the credits? Marcel - --- PGP / GPG Key: http://www.ncpro.com/GPG/mmweber-at-ncpro-com.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (Darwin) iD8DBQE+oe6k1EXMUTKVE5URAnmyAKCTpeRYv6c45/3NpK7/jFZvxa6hIACgw8OX VFGEUd3wnUNsuzu0JQTAXcY= =ZQWW -END PGP SIGNATURE-
Re: plagiarism of reiserfs by Debian
On Sat, Apr 19, 2003 at 08:07:03PM +0400, Hans Reiser wrote: Please explain your reasons for removing the credits and attributions from the reiserfs utilities in violation of our copyright. It appears that, in all likelihood, the credits were inadvertently omitted, and not intentionally removed. In the reiserfsprogs distribution, there is a file COPYING which contains as the software license a verbatim copy of the GPL, while these credits are in a separate README. I am confident that if you contact the maintainer of the package (Ed Boraas [EMAIL PROTECTED], [EMAIL PROTECTED], or via the bug tracking system), he will gladly observe your wishes and include this file with the documentation. -- - mdz
