Re: cdrtools
Kevin Bube wrote: > What about switching to dvdrtools [1]? I think this project was started > to solve the frequently recurring arguments about the licensing and the > device adressing scheme cdrtools use. This was also considered as an option[0]. However, this is not the place and not the right people (no offence) to discuss this a second time again. The people in charge (CTTE and the maintainers) are working on an optimal solution. They will communicate it as soon as they are ready. [0] dvdrtools are currently in non-free (so not part of Debian at all) and therefore not a solution/replacement - but.. Eduard spoke with Julien why he did put it there: JS' interpretation of the GPL when it comes to derivates (read it's copyright file) may sound strange on the first look, but it is ok and does not conflict with any clause of the GPL; therefore, the consens was IIRC that it will go to main, sooner or later. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Poor quality of multipath-tools
On Thu, Jul 06, 2006 at 08:07:16AM -0500, John Goerzen wrote: > On Thu, Jul 06, 2006 at 02:39:16PM +0300, Pasi Kärkkäinen wrote: > > Not always true. Both paths can be active at the same time.. if supported by > > the SAN array. Then you do also load balancing between the paths.. > > Quite true, though my impression is that this is much more rare. Our > controller (HP MSA1500cs) seems to have added active/active controllers > as a recent option. > > I'm not really sure if multipath-tools supports active/active > controllers, though. Do you know? > Yes, active/active is working fine: $ multipath -ll system (30690a018c032d43ece43440cd044) [size=18 GB][features="0"][hwhandler="0"] \_ round-robin 0 [active] \_ 0:0:1:0 sda 8:0 [active][ready] \_ 1:0:1:0 sdc 8:32 [active][ready] that's LUN from Equallogic iSCSI SAN array.. loadbalanced with round-robin. Box is even booted from the SAN :) took some time to create the initrd images to set up multipathing for boot/system volume.. -- Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
On Fri, Jul 07, 2006 at 08:57:54AM +0200, Daniel Baumann wrote: > Kevin Bube wrote: > > What about switching to dvdrtools? I think this project was > > started to solve the frequently recurring arguments about the > > licensing and the device adressing scheme cdrtools use. > > dvdrtools are currently in non-free (so not part of Debian at all) > and therefore not a solution/replacement I completely fail to see any logic here: * cdrtools, obviously completely non-free, is in main * dvdrtools, a fork of the last GPLed version, is in non-free The only reason why dvdrtools would sit in non-free is a controversy whether a "clarification" can be retroactive. If it can be, it is quite a hit to the GPL in general. Freeness of dvdrtools is >= freeness of cdrtools, at least. > The people in charge (CTTE and the maintainers) are working on an > optimal solution. They will communicate it as soon as they are > ready. And of course, this particular case is already in good hands. What I am interested in is whether GPL can be withdrawn. Of course, the copyright holder can relicense new versions to his heart's content, but can he take away people's rights from older releases? The whole point of the GPL is to prevent _anyone_ from imposing further restrictions that could limit the freeness of covered software, so I would say that this would be a bad precedent. Cheers, -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
#include * Adam Borowski [Fri, Jul 07 2006, 10:38:32AM]: > * dvdrtools, a fork of the last GPLed version, is in non-free Please look at dvdrtools' files, eg. cdrecord.c before claiming that. > And of course, this particular case is already in good hands. What I > am interested in is whether GPL can be withdrawn. Of course, the > copyright holder can relicense new versions to his heart's content, > but can he take away people's rights from older releases? The whole Apparently not. The current cdrtools package in topic is relicensed with "some other license I'm not discussing here" but the initially GPLed contributions (mkisofs and its additional components) have been kept under the GPL. And that is what I am forking right now. If someone is volunteering as alpha tester or codeveloper, let me know. Regards, Eduard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: failure notice
If people don't want to read mail from me, don't ask me to do something to you. At 6 Jul 2006 22:53:27 -, [EMAIL PROTECTED] wrote: > > Hi. This is the qmail-send program at viper2.netfort.gr.jp. > I'm afraid I wasn't able to deliver your message to the following addresses. > This is a permanent error; I've given up. Sorry it didn't work out. > > <[EMAIL PROTECTED]>: > 211.115.216.226 does not like recipient. > Remote host said: 554 Access denied from 219.75.232.131. See > http://www.us.sorbs.net for more information > Giving up on 211.115.216.226. > > --- Below this line is a copy of the message. > > Return-Path: <[EMAIL PROTECTED]> > Received: (qmail 30669 invoked from network); 6 Jul 2006 22:53:24 - > Received: from unknown (HELO dancer64.netfort.gr.jp.netfort.gr.jp) (127.0.0.1) > by viper2.netfort.gr.jp with SMTP; 6 Jul 2006 22:53:24 - > Date: Fri, 07 Jul 2006 07:53:24 +0900 > Message-ID: <[EMAIL PROTECTED]> > From: Junichi Uekawa <[EMAIL PROTECTED]> > To: "Steinar H. Gunderson" <[EMAIL PROTECTED]> > Cc: Junichi Uekawa <[EMAIL PROTECTED]>, > [EMAIL PROTECTED], debian-devel@lists.debian.org > Subject: Contents file is empty, where is it gone ? > In-Reply-To: <[EMAIL PROTECTED]> > References: <[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> > User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 > (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/21.4 (x86_64-pc-linux-gnu) > MULE/5.0 (SAKAKI) > MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") > Content-Type: text/plain; charset=US-ASCII > > > > auto-apt update > > > Downloading http://ftp.jp.debian.org/debian//dists/unstable > > > Contents-amd64.gz ... > > > Warning: "+number" syntax is deprecated, please use "-n +number" > > > > > > put: 0 files, 0 entries done (0 sec) > > > > FWIW, this works for me, even though I get the same warnings (which I'd > > guess > > come from the new sort). > > Contents.gz seems empty, which sounds more like the culprit. > Ccing debian-devel; anyone know why this is the case? > > SNIP > ftp://ftp.debian.org/debian/dists/unstable/Contents-amd64.gz looks more empty. > > This file maps each file available in the Debian GNU/Linux system to > the package from which it originates. It includes packages from the > DIST distribution for the ARCH architecture. > > You can use this list to determine which package contains a specific > file, or whether or not a specific file is available. The list is > updated weekly, each architecture on a different day. > > When a file is contained in more than one package, all packages are > listed. When a directory is contained in more than one package, only > the first is listed. > > The best way to search quickly for a file is with the Unix `grep' > utility, as in `grep CONTENTS': > > $ grep nose Contents > etc/nosendfile net/sendfile > usr/X11R6/bin/noseguy x11/xscreensaver > usr/X11R6/man/man1/noseguy.1x.gzx11/xscreensaver > usr/doc/examples/ucbmpeg/mpeg_encode/nosearch.param graphics/ucbmpeg > usr/lib/cfengine/bin/noseyparkeradmin/cfengine > > This list contains files in all packages, even though not all of the > packages are installed on an actual system at once. If you want to > find out which packages on an installed Debian system provide a > particular file, you can use `dpkg --search ': > > $ dpkg --search /usr/bin/dselect > dpkg: /usr/bin/dselect > > > FILELOCATION > SNIP > > > > > regards, > junichi > -- > [EMAIL PROTECTED],netfort.gr.jp} Debian Project > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Eduard Bloch <[EMAIL PROTECTED]> writes: > * Adam Borowski [Fri, Jul 07 2006, 10:38:32AM]: >> * dvdrtools, a fork of the last GPLed version, is in non-free > > Please look at dvdrtools' files, eg. cdrecord.c before claiming that. What is wrong with that? The blurb [1] seems quite okay (i.e. GPL) to me. Regards, Kevin [1] http://www.arklinux.org/projects/dvdrtools/browser/releases/0.3.1/dvdrecord/cdrecord.c -- publickey 2048R/0AFDFB19 available at: http://pgpkeys.pca.dfn.de:11371/pks/lookup?op=get&search=0x1BF55C710AFDFB19 fingerprint: 542B 1378 04AA AF1F 572E 78BF 1BF5 5C71 0AFD FB19 pgpfWytHiO2IL.pgp Description: PGP signature
Re: header sanity check?
On Thu, Jul 06, 2006 at 09:05:28PM -0700, Tyler MacDonald wrote: > So it's really easy to package a -dev package with a header file, that > #include's a header file in a package that it doesn't depend on. Yes it is, it's a compile time problem of someones program. > to catch this or if there are any requirements. pbuilder won't even catch it > if the Build-Depends for the source package contains all the -dev packages > needed. If that particular header file is not used in the compiling then it cannot be caught, as it doesn't result in an error. It is not as easy as it sounds. We have enough trouble with libraries (it's a similiar sort of issue). Consider if you include stdio.h You need to depend on libc6-dev right? Until libc7 comes along, then you're in trouble. Also a lot of headers have things like #ifdef HAVE_FOO_H and only include foo.h if you have it. Lot's of portable autoconf'ed stuff does it like that. Or perhaps parts of the headers only "activate" under certain circumstances. A program that could use mysql or postgresql databases, for example, may need some of their headers if you use that feature. It would be nice to trap all sorts of problems, but I believe this would create more than it would solve. - Craig -- Craig Small GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.enc.com.au/ MIEE Debian developer csmall at : enc.com.au ieee.org debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#377211: ITP: unreal-ircd -- Full featured irc server
Package: wnpp Severity: wishlist Owner: "Iñaki Rodríguez" <[EMAIL PROTECTED]> * Package name: unreal-ircd Version : 3.2.5 Upstream Author : Stskeeps ([EMAIL PROTECTED]), codemastr ([EMAIL PROTECTED]), Syzop ([EMAIL PROTECTED]), Luke ([EMAIL PROTECTED]), cknight^ ([EMAIL PROTECTED]) * URL : http://www.unrealircd.com * License : GPL Programming Lang: C Description : Full featured irc server UnrealIRCd is an Open Source IRC Server. Development of UnrealIRCd began in May of 1999. Unreal was created from the Dreamforge IRCd that was formerly used by the DALnet IRC Network. Over the years, many new and exciting features have been added to Unreal. It is hard to even see a resemblance between the current Unreal and Dreamforge. Some of Unreal's most notable features include: * Channel Half-ops (+h) * Channel Owners (+q) and Channel Admins (+a) * Channel linking (+L) * Advanced anti-flood and anti-spam systems * Swear filtering (+G) * Hostname cloaking (+x) * Color blocking and stripping (+c/+S) * Vhosts * WebTV Support * DCCDeny * Ziplinks * SSL encrypted client and server connections * Advanced and highly configurable configuration file * Module support * And Much More... -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686-smp Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Re: These new diffs are great, but...
On Fri, 30 Jun 2006 11:10:37 +0200, Eduard Bloch <[EMAIL PROTECTED]> wrote: >I have doubts, have you measured the real difference? Yes, I have. Test was done in a sid chroot that hasn't been updated for like two weeks. |$ time sudo aptitude update |Reading package lists... Done |Building dependency tree... Done |Reading extended state information |Initializing package states... Done |Building tag database... Done |Ign http://zg.debian.zugschlus.de zg/sid Release.gpg |Ign http://zg.debian.zugschlus.de zg/sid Release |Ign http://zg.debian.zugschlus.de zg/sid/main Packages/DiffIndex |Ign http://zg.debian.zugschlus.de zg/sid/contrib Packages/DiffIndex |Get:1 http://zg.debian.zugschlus.de zg/sid/main Packages [7506B] |Hit http://zg.debian.zugschlus.de zg/sid/contrib Packages |Get:2 http://debian.debian.zugschlus.de sid Release.gpg [189B] |Get:3 http://debian.debian.zugschlus.de sid Release [38.3kB] |Ign http://debian.debian.zugschlus.de sid Release |Get:4 http://debian.debian.zugschlus.de sid/main Packages/DiffIndex [12.6kB] |Get:5 http://debian.debian.zugschlus.de sid/contrib Packages/DiffIndex [12.5kB] |Get:6 http://debian.debian.zugschlus.de sid/main Sources/DiffIndex [12.5kB] |Get:7 http://debian.debian.zugschlus.de sid/contrib Sources/DiffIndex [12.5kB] |Get:8 2006-06-22-1336.37.pdiff [16.0kB] |Get:9 2006-06-22-1336.37.pdiff [16.0kB] |Get:10 2006-06-22-1336.37.pdiff [180B] |Get:11 2006-06-22-1336.37.pdiff [9491B] |Get:12 2006-06-22-1336.37.pdiff [180B] |Get:13 2006-06-22-1336.37.pdiff [16.0kB] |Get:14 2006-06-22-1336.37.pdiff [172B] |Get:15 2006-06-22-1336.37.pdiff [9491B] |Get:16 2006-06-22-1336.37.pdiff [172B] |Get:17 2006-06-22-1336.37.pdiff [180B] |Get:18 2006-06-23-1348.02.pdiff [25.9kB] |Get:19 2006-06-22-1336.37.pdiff [9491B] |Get:20 2006-06-23-1348.02.pdiff [25.9kB] |Get:21 2006-06-23-1348.02.pdiff [329B] |Get:22 2006-06-23-1348.02.pdiff [329B] |Get:23 2006-06-22-1336.37.pdiff [172B] |Get:24 2006-06-23-1348.02.pdiff [25.9kB] |Get:25 2006-06-23-1348.02.pdiff [13.9kB] |Get:26 2006-06-23-1348.02.pdiff [13.9kB] |Get:27 2006-06-23-1348.02.pdiff [139B] |Get:28 2006-06-23-1348.02.pdiff [139B] |Get:29 2006-06-23-1348.02.pdiff [329B] |Get:30 2006-06-24-1338.23.pdiff [39.6kB] |Get:31 2006-06-23-1348.02.pdiff [13.9kB] |Get:32 2006-06-24-1338.23.pdiff [39.6kB] |Get:33 2006-06-24-1338.23.pdiff [155B] |Get:34 2006-06-24-1338.23.pdiff [155B] |Get:35 2006-06-23-1348.02.pdiff [139B] |Get:36 2006-06-24-1338.23.pdiff [18.9kB] |Get:37 2006-06-24-1338.23.pdiff [39.6kB] |Get:38 2006-06-24-1338.23.pdiff [18.9kB] |Get:39 2006-06-24-1338.23.pdiff [165B] |Get:40 2006-06-24-1338.23.pdiff [165B] |Get:41 2006-06-24-1338.23.pdiff [155B] |Get:42 2006-06-25-1342.37.pdiff [20.3kB] |Get:43 2006-06-24-1338.23.pdiff [18.9kB] |Get:44 2006-06-25-1342.37.pdiff [20.3kB] |Get:45 2006-06-25-1342.37.pdiff [205B] |Get:46 2006-06-25-1342.37.pdiff [205B] |Get:47 2006-06-24-1338.23.pdiff [165B] |Get:48 2006-06-25-1342.37.pdiff [20.3kB] |Get:49 2006-06-25-1342.37.pdiff [12.0kB] |Get:50 2006-06-25-1342.37.pdiff [12.0kB] |Get:51 2006-06-25-1342.37.pdiff [147B] |Get:52 2006-06-25-1342.37.pdiff [147B] |Get:53 2006-06-25-1342.37.pdiff [205B] |Get:54 2006-06-25-1342.37.pdiff [12.0kB] |Get:55 2006-06-26-1346.13.pdiff [24.6kB] |Get:56 2006-06-26-1346.13.pdiff [24.6kB] |Get:57 2006-06-26-1346.13.pdiff [151B] |Get:58 2006-06-26-1346.13.pdiff [151B] |Get:59 2006-06-25-1342.37.pdiff [147B] |Get:60 2006-06-26-1346.13.pdiff [24.6kB] |Get:61 2006-06-26-1346.13.pdiff [11.5kB] |Get:62 2006-06-26-1346.13.pdiff [11.5kB] |Get:63 2006-06-26-1346.13.pdiff [207B] |Get:64 2006-06-26-1346.13.pdiff [207B] |Get:65 2006-06-26-1346.13.pdiff [151B] |Get:66 2006-06-26-1346.13.pdiff [11.5kB] |Get:67 2006-06-27-1308.52.pdiff [1269kB] |Get:68 2006-06-27-1308.52.pdiff [1269kB] |Get:69 2006-06-27-1308.52.pdiff [14.7kB] |Get:70 2006-06-27-1308.52.pdiff [14.7kB] |Get:71 2006-06-26-1346.13.pdiff [207B] |Get:72 2006-06-27-1308.52.pdiff [13.0kB] |Get:73 2006-06-27-1308.52.pdiff [1269kB] |Get:74 2006-06-27-1308.52.pdiff [13.0kB] |Get:75 2006-06-27-1308.52.pdiff [29B] |Get:76 2006-06-27-1308.52.pdiff [29B] |Get:77 2006-06-27-1308.52.pdiff [14.7kB] |Get:78 2006-06-28-1245.43.pdiff [25.3kB] |Get:79 2006-06-27-1308.52.pdiff [13.0kB] |Get:80 2006-06-28-1245.43.pdiff [25.3kB] |Get:81 2006-06-28-1245.43.pdiff [391B] |Get:82 2006-06-28-1245.43.pdiff [391B] |Get:83 2006-06-27-1308.52.pdiff [29B] |Get:84 2006-06-28-1245.43.pdiff [25.3kB] |Get:85 2006-06-28-1245.43.pdiff [7672B] |Get:86 2006-06-28-1245.43.pdiff [7672B] |Get:87 2006-06-28-1245.43.pdiff [146B] |Get:88 2006-06-28-1245.43.pdiff [146B] |Get:89 2006-06-28-1245.43.pdiff [391B] |Get:90 2006-06-29-1245.21.pdiff [39.1kB] |Get:91 2006-06-28-1245.43.pdiff [7672B] |Get:92 2006-06-29-1245.21.pdiff [39.1kB] |Get:93 2006-06-29-1245.21.pdiff [818B] |Get:94 2006-06-29-1245.21.pdiff [818B] |Get:95 2006-06-28-1245.43.pdiff [146B] |Get:96 2006-06-29-1245.21.pdiff [11.9kB] |Get:97 2006-06-29-1245.21.pdiff [39.1kB] |Get:98 2006-06-29-1245.21.pdiff [11
Re: These new diffs are great, but...
* Marc Haber <[EMAIL PROTECTED]>: > Yes, I have. Test was done in a sid chroot that hasn't been updated > for like two weeks. ... > Updating with pdiffs took one minute nine seconds while downloading a > completely new set of list files took eight seconds. > > Test environment was quite unfair though (an old machine with an 1200 > MHz CPU and a single, slow disk on an 100 MBit link to a rather local > mirror). There should be limit on the number of diffs that will be downloaded before the whole list if used instead. -- Ralf Hildebrandt (i.A. des IT-Zentrums) [EMAIL PROTECTED] Charite - Universitätsmedizin BerlinTel. +49 (0)30-450 570-155 Gemeinsame Einrichtung von FU- und HU-BerlinFax. +49 (0)30-450 570-962 IT-Zentrum Standort CBF send no mail to [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: These new diffs are great, but...
Florian Weimer <[EMAIL PROTECTED]> writes: > * Marc Haber: > >> The machine in Question is a P3 with 1200 MHz. What's making the >> process slow is the turnaround time for the http requests, as observed >> multiple times in this thread alone. > > Then your setup is very broken. APT performs HTTP pipelining. Actualy it does NOT from what strace shows me. The apt http method uses keep-alive but not pipelining. For example apt-get source bash will send a GET request, read the file, send the next GET, read the file, send the third GET, read that file. With pipelining it should send all 3 GETs at once or at least intermixed with reading the files. But even with pipelining that would not help since the pdiff files are not queued up with the http method in advance but one after the other. > On my machines, I see the behavior Miles described: lots of disk I/O. > Obviously, APT reconstructs every intermediate version of the packages > file. Yes, I noticed that too. Patching a 15MB Packages file takes a lot of time. You can watch the progress during rred runs most of the time even on a modern amd64 system. > The fix is to combine the diffs before applying them, so that you only > need one process the large Packages file once. I happen to have ML > code which does this (including the conversion to a patch > representation which is more amenable to this kind of optimization) > and would be willing to port it to C++, but someone else would need to > deal with the APT integration because I'm not familiar with its > architecture. What code do you need there? If the rred method keeps the full Index file in memory during patching it can just be fed all the patches one after another and only write out the final result at the end. Combining the patches is a simple cat. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make -j in Debian packages
Adam Borowski <[EMAIL PROTECTED]> writes: > On Sun, Jul 02, 2006 at 11:57:50AM +0200, Wouter Verhelst wrote: >> Additionally, it puzzles me how you think a maintainer will be able to >> accurately predict how much RAM a certain build is going to use. There >> are so many variables, that I think anything but 'this is the fastest >> way to build it on my machine' is going to be unfeasible. Ram usage between architectures should not vary more than a factor of 4. Much less in normal cases. > Let's say: > program X consist of a number of C files; it seems like compiling > every file takes around 24MB, with the final link taking much more[1]. > I guess this can be called typical, in C you need to store just the > current file and the headers you use. > > Now, let's assume we use not the simple snippet I wrote [2] but a > "concurrency-helper" with the interface Goswin described, with some > unknown logic inside. > > The maintainer thus declares that package X takes 24MB, and says it's > good to use heavy concurrency: > concurrency-helper --ram-estimate 24 --more-concurrent > > The machine is a mid-range user box, with 512MB ram. > > Thus, if the helper decides to go with -j4, the safety margin is _5_ > times. I guess you can trust people to be at least within _that_ > error range. And even if they fail, you can always force the build > to use -j1. The amount of paging can also be gathered during a build and included in the buildd log. Too bad avgtext / avgdata / maxresident accounting is broken and always gives 0 (e.g. run /usr/bin/time ls). > If, let's say, the machine is a high-end one with 2GB ram, it runs 4 > buildds at once and the admin didn't specify his preferences, using > -j4 won't be any worse than on the user box mentioned above. And the concurrency-helper could easily know about 4 buildds being run in parallel and assume only 512MB ram and 1/4 the number of cpus being available per buildd for its calculations. The point of the helper is to remove the decision from the package alone to a central place that is easily configurable for a wide range of cases. > [1]. I was once forced to do a kernel compile on a critically memory > starved box. Going from .c to .o went quite smoothly, but the final > link was an unholy swappeathon that took hours. > > [2]. My idea was to simply go with -j1 if the machine has less than X > memory, or with a given constant otherwise. > > Cheers, MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: doc compilations: build-time or pre-built?
[EMAIL PROTECTED] writes: > Hi. > > My dillema: > > 1) compile docs pre-build-time; or > 2) compile docs in build-time > > > Pros of 1: < build-time and < Build-Depends Cons: - Docs that can be unbuildable or out of sync with the source. - Binary files in the diff.gz (have fun with that one) either always or if the user changes the sources of docs and rebuilds. > Pros of 2: < diff.gz and unnecessary manual intervention of downstream > maintainer (me :) ) You can keep the docs in orig.tar.gz and remove them in clean in many cases. Afaik that is perfectly legal. If that is not possible (unrepresentable changes to source) then renaming them and undoing that during build is an (ugly) alternative. > So, what are best practices about this? If there is source then build that (with the exception of running the auto* tools). If building takes long then don't have the build target build the architecture independent files but only the build-indep / binary-indep targets and use Build-Depends-Indep. Pro: - no need for buildds to install/remove Build-Depends-Indep - no need for buildds to compile indep files even though "build" is called Cons: - indep files will be build as (fake)root instead of as user. > Thanks in advance, MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FTWCA Policy Section 7.6 (Build-Depends/Build-Depends-Indep)
Ola Lundqvist <[EMAIL PROTECTED]> writes: > Hi > > If this is the case, then I think lintian should be updated to tell > people this. It is in fact lintian that have made me do this kind > of change for all the Arch: all packages that I maintain. > > Please CC me as I'm not on this list anymore if you have comments > on my post. > > Regards, > > // Ola > > On Thu, Jun 15, 2006 at 07:42:42PM +0200, Pierre Habouzit wrote: >> Dear fellow developers, >> >> >> Section 7.6[1] is an often misunderstood/forgotten part of the Policy >> that explains how Build-Depends and Build-Depends-Indep are used to >> build a package. Here is almost a copy&paste: >> >>The dependencies and conflicts they define must be satisfied >>in order to invoke the targets in debian/rules, as follows: >> >>The Build-Depends and Build-Conflicts fields must be satisfied >>when any of the following targets is invoked: >> build, clean, binary, binary-arch, build-arch, >> build-indep, binary-indep.· >> >>The Build-Depends-Indep and Build-Conflicts-Indep fields >>must be satisfied when any of the following targets is invoked: >> build, build-indep, binary and binary-indep. >> >> >> In particular, it means that having cdbs, yada, dbs, dh-make-php and >> other packaging helpers that are included from your debian/rules in >> B-D-I is wrong, and that having debhelper in B-D-I is wrong as soon as >> you use dh_clean in your clean target. There is also the issue of policy being wrong (or buildds if you like). Policy says *-Indep must be satisfied for "build" but is ignored when building only arch packages (-B option) despide "build" being called. Build-Depends-Indep can only be used for packages that are used exclusively by build-indep (if build does NOT call that) and/or binary-indep. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#377220: ITP: liblingua-de-ascii -- convert german umlauts to and from ascii
Package: wnpp Severity: wishlist Owner: Sebastian Harl <[EMAIL PROTECTED]> * Package name: liblingua-de-ascii Version : 0.11 Upstream Author : Janek Schleicher <[EMAIL PROTECTED]> * URL : http://cpan.org/modules/by-module/Lingua/ * License : GPL / Artistic Description : convert german umlauts to and from ascii This module enables conversion from and to the ASCII format of german texts. It has two methods: to_ascii and to_latin1 which each do exactly what they say. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make -j in Debian packages
On Thu, Jul 06, 2006 at 11:58:28PM +0200, Adam Borowski wrote: > On Wed, Jul 05, 2006 at 08:23:00PM +0200, Wouter Verhelst wrote: > > On Mon, Jul 03, 2006 at 03:04:14PM +0200, Adam Borowski wrote: > > > On Sun, Jul 02, 2006 at 11:57:50AM +0200, Wouter Verhelst wrote: > > > > Additionally, it puzzles me how you think a maintainer will be able to > > > > accurately predict how much RAM a certain build is going to use. There > > > > are so many variables, that I think anything but 'this is the fastest > > > > way to build it on my machine' is going to be unfeasible. > > > > > > Let's say: > > > program X consist of a number of C files; it seems like compiling > > > every file takes around 24MB, > > > > Like I said, there's just too many variables. Also, I wouldn't be > > interested in figuring out how much RAM the build takes if I were to > > maintain a package like, say, X or so. > > No one forces you to do so. No one even said a word about making > concurrency mandatory. It's just a way to make builds faster on > machines that are beefy enough (ie, virtually all). > > > You're not convincing me that you can indeed accurately predict for > > every compiled language out there how much RAM you're going to need > > during the build. > > So what? If you're not sure, you simply don't provide your > prediction. And with a huge safety margin, you would have to be > MALICIOUS to make a mistake. > > > Before you've proven that this is indeed possible, I don't think > > there's much point in this whole exercise; otherwise there > > *is* going to be a problem with you overloading build machines, and > > *you will* get bugs filed about that (from me, at the very least). > > Here, you got a piece of working code, is that not a good enough > proof? Tell me how exactly a build using 4 processes using ~24MB > each overloading a build machine which has 512+MB ram. And builds > which do require 1+GB of memory, well, simply are not going to use > any concurrency. > > And note that the system I propose actually _limits_ concurrency in > some cases. The whole thread started with gem packages choking the > m68k build. It's a big package, and the maintainer rightfully > thinked that it is completely useless on small arches. Err, AIUI, ruby gems are a way to automatically install extras to a running ruby environment, much in the same way that the CPAN module is used for Perl. I fail to see why this would be "completely useless" on smaller architectures. If you want to use ruby there, you may want to use gem. -- Fun will now commence -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: These new diffs are great, but...
On Friday 07 July 2006 15:36, Goswin von Brederlow wrote: > Florian Weimer <[EMAIL PROTECTED]> writes: > > * Marc Haber: > >> The machine in Question is a P3 with 1200 MHz. What's making the > >> process slow is the turnaround time for the http requests, as observed > >> multiple times in this thread alone. > > > > Then your setup is very broken. APT performs HTTP pipelining. > > Actualy it does NOT from what strace shows me. The apt http method > uses keep-alive but not pipelining. For example apt-get source bash > will send a GET request, read the file, send the next GET, read the > file, send the third GET, read that file. With pipelining it should > send all 3 GETs at once or at least intermixed with reading the files. Well, pipelining depends on the remote httpd server also (IFAIK thttpd does not support it) and apt's httpd method is smart enough to shut down pipelining when talks to HTTP/1.0-only capable servers to speed the things up. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: These new diffs are great, but...
On 7/7/06, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: What code do you need there? If the rred method keeps the full Index file in memory during patching it can just be fed all the patches one after another and only write out the final result at the end. Combining the patches is a simple cat. As far as I can see from the code, it reads the input file and the patch with fgets() and writes the output file with fputs(). Since the diffs in the file are in reverse order, it first reads one ed command and recurses so it forms on the stack a set of the file offsets of all the patches. As it unwinds it scans forward through the data file once to apply the patches. Not a terribly bad algorith as such, but it's got quite a bit of disk overhead if the individual files are on disk. It would appear that the algorithm would allow itself to stream output from one patch applier to another, but it would seem to be easiest to simply combine the diffs into one large diff. Techniques for combining diffs are not new, I imagine someone just needs to code it... Hope this helps, -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#377220: ITP: liblingua-de-ascii -- convert german umlauts to and from ascii
* Sebastian Harl <[EMAIL PROTECTED]> [2006-07-07 15:00]: > * Package name: liblingua-de-ascii > Version : 0.11 > Upstream Author : Janek Schleicher <[EMAIL PROTECTED]> > * URL : http://cpan.org/modules/by-module/Lingua/ > * License : GPL / Artistic > Description : convert german umlauts to and from ascii According to the Debian Perl Policy, your package should be called liblingua-de-ascii-perl (see http://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html) -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
#include * Kevin Bube [Fri, Jul 07 2006, 11:29:21AM]: > Eduard Bloch <[EMAIL PROTECTED]> writes: > > * Adam Borowski [Fri, Jul 07 2006, 10:38:32AM]: > > >> * dvdrtools, a fork of the last GPLed version, is in non-free > > > > Please look at dvdrtools' files, eg. cdrecord.c before claiming that. > > What is wrong with that? The blurb [1] seems quite okay (i.e. GPL) to > me. Grep for "not.allowed" and decide yourself whether such remarks are applicable to the GPL (as applicable in your country). Eduard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
On Fri, 2006-07-07 at 10:38 +0200, Adam Borowski wrote: > On Fri, Jul 07, 2006 at 08:57:54AM +0200, Daniel Baumann wrote: > > Kevin Bube wrote: > > > What about switching to dvdrtools? I think this project was > > > started to solve the frequently recurring arguments about the > > > licensing and the device adressing scheme cdrtools use. > > > > dvdrtools are currently in non-free (so not part of Debian at all) > > and therefore not a solution/replacement > > I completely fail to see any logic here: > * cdrtools, obviously completely non-free, is in main what? you think if it is non-GPL than it should go to non-free? This is nonsense. And, please, don't tell me that CDDL is less free than 3-clause BSD, etc. Its OSI approved, therefore it is *free* license. I'd like to see current Debian leaders to comment on this *political* issue and stop minority discrimination right there. > * dvdrtools, a fork of the last GPLed version, is in non-free dvdrtools - totally useless effort. Besides, its known to be buggy and linux-only which is against Debian philosophy therefore should never be in main. Please, reconsider and instead consolidate your efforts with current cdrtools project. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#377220: ITP: liblingua-de-ascii -- convert german umlauts to and from ascii
> > * Package name: liblingua-de-ascii > > Version : 0.11 > > Upstream Author : Janek Schleicher <[EMAIL PROTECTED]> > > * URL : http://cpan.org/modules/by-module/Lingua/ > > * License : GPL / Artistic > > Description : convert german umlauts to and from ascii > > According to the Debian Perl Policy, your package should be called > liblingua-de-ascii-perl (see > http://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html) Yes... thx - that was just a typo. Cheers, Sebastian -- Sebastian "tokkee" Harl GnuPG-ID: 0x8501C7FC http://tokkee.org/ signature.asc Description: Digital signature
Re: These new diffs are great, but...
On Fri, Jul 07, 2006 at 02:28:49PM +0200, Marc Haber wrote: > Updating with pdiffs took one minute nine seconds while downloading a > completely new set of list files took eight seconds. > > Test environment was quite unfair though (an old machine with an 1200 > MHz CPU and a single, slow disk on an 100 MBit link to a rather local > mirror). 1200MHz is slow these days? I ran this very test on Wednesday's night, on a super-duper machine overclocked to whooping 120MHz. But even though it was only ~10 diffs (installed from Sunday's d-i daily), I have to concur with your results :p And the installation isn't complete yet... -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
On Fri, Jul 07, 2006 at 08:09:43AM -0700, Erast Benson <[EMAIL PROTECTED]> wrote: > On Fri, 2006-07-07 at 10:38 +0200, Adam Borowski wrote: > > On Fri, Jul 07, 2006 at 08:57:54AM +0200, Daniel Baumann wrote: > > > Kevin Bube wrote: > > > > What about switching to dvdrtools? I think this project was > > > > started to solve the frequently recurring arguments about the > > > > licensing and the device adressing scheme cdrtools use. > > > > > > dvdrtools are currently in non-free (so not part of Debian at all) > > > and therefore not a solution/replacement > > > > I completely fail to see any logic here: > > * cdrtools, obviously completely non-free, is in main > > what? you think if it is non-GPL than it should go to non-free? This is > nonsense. And, please, don't tell me that CDDL is less free than > 3-clause BSD, etc. Its OSI approved, therefore it is *free* license. APSL 1.2 too is OSI approved. That doesn't make it a *free* license. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
On Fri, 07 Jul 2006, Erast Benson wrote: > On Fri, 2006-07-07 at 10:38 +0200, Adam Borowski wrote: > > I completely fail to see any logic here: > > * cdrtools, obviously completely non-free, is in main > > what? you think if it is non-GPL than it should go to non-free? This > is nonsense. No. The primary issue is that the mixture of a GPL+CDDL work creates a work that cannot be distributed by anyone else but the copyright holder. We don't even have to get into the argument of whether or not the CDDL is DFSG Free or not so long as this is the case. See #377109 et al. > And, please, don't tell me that CDDL is less free than 3-clause BSD, > etc. Clearly it is, but that's not at issue here. > I'd like to see current Debian leaders to comment on this > *political* issue and stop minority discrimination right there. The people involved in maintaining the cdrtools package have been commenting on this issue. They're the ones whose opinion actually matters first. [ftpmaster's opinion is next; unless you're calling for a GR about CDDL.] In this case, the bug has been refered to the tech-ctte, so when they make a ruling, you'll know about it. > > * dvdrtools, a fork of the last GPLed version, is in non-free > > dvdrtools - totally useless effort. Besides, its known to be buggy > and linux-only which is against Debian philosophy therefore should > never be in main. Something being linux-only has never precluded it from being distributed in main, just like a program which only runs on a single architecture. Even then, the only kernel we officially support right now is the linux kernel. Don Armstrong -- Clothes make the man. Naked people have little or no influence on society. -- Mark Twain http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Bug#377239: ITP: usb8338 -- Driver and supporting software for the Marvel USB 8338 Wireless NIC
Package: wnpp Severity: wishlist Owner: "Mike O'Connor" <[EMAIL PROTECTED]> * Package name: usb8338 Version : 318.p7 Upstream Author : Marvell International Ltd. * URL : http://marvell.com/drivers * License : GPL Programming Lang: C Description : Driver and supporting software for the Marvel USB 8338 Wireless NIC This package provides the source code for the usb8xxx kernel module, which supports for the Marvel USB 8338 Wireless NIC. The 8338 is the NIC that will be included in the One Laptop Per Child (OLPC) computers. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-k7-smp Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
On Fri, 2006-07-07 at 08:39 -0700, Don Armstrong wrote: > On Fri, 07 Jul 2006, Erast Benson wrote: > > On Fri, 2006-07-07 at 10:38 +0200, Adam Borowski wrote: > > > I completely fail to see any logic here: > > > * cdrtools, obviously completely non-free, is in main > > > > what? you think if it is non-GPL than it should go to non-free? This > > is nonsense. > > No. The primary issue is that the mixture of a GPL+CDDL work creates a > work that cannot be distributed by anyone else but the copyright > holder. It seems to be an offtopic here, but could you please elaborate a little bit further, which particular statement of which license prevents it? Erast -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make -j in Debian packages
On Fri, Jul 07, 2006 at 03:34:59PM +0200, Wouter Verhelst wrote: > Err, AIUI, ruby gems are a way to automatically install extras to a > running ruby environment, much in the same way that the CPAN module is > used for Perl. > > I fail to see why this would be "completely useless" on smaller > architectures. If you want to use ruby there, you may want to use gem. Uhm, gem seems to be a X11 package dealing with graphics rendering and animation. "grep -ir ruby" on its source doesn't show anything, too. Or am I missing something? Also: PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 18425 kilobyte 25 0 20904 15m 5660 R 29.5 3.2 0:01.00 cc1plus 18428 kilobyte 25 0 19880 14m 5552 R 23.6 2.9 0:00.71 cc1plus 18436 kilobyte 25 0 17496 10m 3232 R 10.3 2.0 0:00.31 cc1plus 18259 kilobyte 15 0 4940 1392 1008 S 1.7 0.3 0:00.59 mpc123 18426 kilobyte 23 0 5004 2372 1468 S 1.7 0.5 0:00.06 g++ 18434 kilobyte 25 0 5004 2376 1468 S 1.7 0.5 0:00.05 g++ 18423 kilobyte 16 0 2264 1152 852 R 0.3 0.2 0:00.02 top Doesn't sound that deadly... -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ITP: strigi -- fast indexing and searching tool for your personal data
Package: wnpp Severity: wishlist Owner: Fathi Boudra <[EMAIL PROTECTED]> * Package name: strigi Version : 0.3.2 Upstream Author : Jos van den Oever <[EMAIL PROTECTED]> * URL : http://www.vandenoever.info/software/strigi * License : LGPL Description: fast indexing and searching tool for your personal data Strigi is a program for fast indexing and searching your personal data. It can gather and index informations from files in the filesystem even if they are hidden in emails or archives. It comes with a Qt4 GUI and an HTML GUI. Main features: * very fast crawling * very small memory footprint * no hammering of the system * pluggable backend, currently clucene and hyperestraier, sqlite3 and xapian are in the works * communication between daemon and search program over an abstract interface, this is currently a simple socket but implementation of dbus is a possibility. There's a small perl program in the code as an example of how to query. This is so easy that any KDE app could implement this. * simple interface for implementing plugins for extracting information. we'll try to reuse the kat plugins, although native plugins will have a large speed advantage * calculation of sha1 for every file crawled (allows fast finding of duplicates) This a beagle like ;) cheers, Fathi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
pe, 2006-07-07 kello 08:52 -0700, Erast Benson kirjoitti: > On Fri, 2006-07-07 at 08:39 -0700, Don Armstrong wrote: > > No. The primary issue is that the mixture of a GPL+CDDL work creates a > > work that cannot be distributed by anyone else but the copyright > > holder. > > It seems to be an offtopic here, but could you please elaborate a little > bit further, which particular statement of which license prevents it? There were extensive discussion about this in November on debian-devel, in the thread called "Debian based GNU/Solaris: pilot program", in which Erast Benson also participated a lot. One article that seems pretty good to me: http://lists.debian.org/debian-devel/2005/11/msg00123.html I suggest we not repeat this discussion. We're not breaking new ground here, we're beating a dry, dark patch of ground where a long time ago (or so the elders tell us) some people used to have a hobby of hitting a horse carcass. If you do insist on re-iterating this discussion *again*, please do it elsewhere than debian-devel. Thanks. -- Policy is your friend. Trust the Policy. Love the Policy. Obey the Policy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
* Erast Benson <[EMAIL PROTECTED]> [2006-07-07 17:54]: > On Fri, 2006-07-07 at 08:39 -0700, Don Armstrong wrote: > > No. The primary issue is that the mixture of a GPL+CDDL work creates a > > work that cannot be distributed by anyone else but the copyright > > holder. > > It seems to be an offtopic here, but could you please elaborate a little > bit further, which particular statement of which license prevents it? I don't know if you have seen the videos of the CDDL talk at debconf6 but the guys from SUN (and one of their attorneys was there as well) clearly pointed out that CDDL is on purpose a GPL incompatible license. HTH Martin -- <[EMAIL PROTECTED]> Debian GNU/Linux - The Universal Operating System Können bitte alle doofen Menschen ein eigenes Land bekommen, und da hin gehen? BITTE? alphascorpii: gibt doch schon 2 alphascorpii: Frankreich und USA.
Re: make -j in Debian packages
On Friday 07 July 2006 19:06, Adam Borowski wrote: > On Fri, Jul 07, 2006 at 03:34:59PM +0200, Wouter Verhelst wrote: > > Err, AIUI, ruby gems are a way to automatically install extras to a > > running ruby environment, much in the same way that the CPAN module is > > used for Perl. > > > > I fail to see why this would be "completely useless" on smaller > > architectures. If you want to use ruby there, you may want to use gem. > > Uhm, gem seems to be a X11 package dealing with graphics rendering > and animation. "grep -ir ruby" on its source doesn't show anything, > too. Or am I missing something? He is talking about http://rubyforge.org/projects/rubygems Find the debian source package (not uploaded yet) at: http://svn.debian.org/wsvn/pkg-ruby-extras it is in packages/libgems-ruby/ This is also worth reading: http://pkg-ruby-extras.alioth.debian.org/rubygems.html but I do believe it is possible to install ruby extras (just like perl modules) as both: debian packages (packaging system domain) and via RubyGems (local admin domain) -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
On Fri, 2006-07-07 at 19:25 +0300, Lars Wirzenius wrote: > pe, 2006-07-07 kello 08:52 -0700, Erast Benson kirjoitti: > > On Fri, 2006-07-07 at 08:39 -0700, Don Armstrong wrote: > > > No. The primary issue is that the mixture of a GPL+CDDL work creates a > > > work that cannot be distributed by anyone else but the copyright > > > holder. > > > > It seems to be an offtopic here, but could you please elaborate a little > > bit further, which particular statement of which license prevents it? > > There were extensive discussion about this in November on debian-devel, > in the thread called "Debian based GNU/Solaris: pilot program", in which > Erast Benson also participated a lot. One article that seems pretty good > to me: http://lists.debian.org/debian-devel/2005/11/msg00123.html > > I suggest we not repeat this discussion. We're not breaking new ground > here, we're beating a dry, dark patch of ground where a long time ago > (or so the elders tell us) some people used to have a hobby of hitting a > horse carcass. > > If you do insist on re-iterating this discussion *again*, please do it > elsewhere than debian-devel. No, I don't want to re-iterate the discussion again. Situation were clarified by FSF leaders by Eben Moglen during GPLv3 discussion and Alex Ross summarized it in April here: http://lists.debian.org/debian-devel/2006/04/msg00085.html but those are bit different issues as I can see them. Erast -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question on setting setuid bit
LEE, Yui-wah (Clement) writes ("A question on setting setuid bit"):
> I am building a package in which one of the binary has
> to have the setuid and setgid bits set. I wonder which
> one of the following two is the more appropriate method
> to use?
Forgive my scepticism, but which package, and why ? set-id bits
should not be set lightly and they should only be used after careful
consideration by experts.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Tarifas telefónica
Estimado/a Nos dirigimos Ud. a fin de solicitare permiso para enviarle información sobre telefonía IP. Destacamos *Ahorro promedio de 68% en llamadas de media y larga distancia a cualquier número de telefono fijo. * Un número local en las principales ciudades del mundo o de ciudades del interior que le permitira recibir las llamadas efectuadas a ese número en su propio teléfono. Para solicitarla solo tiene que usar la opción responder de su programa de correos y agregar OK en el asunto. Si no responde este mensaje no le volverá a ser enviado. Grupo Physis Saludos Cordiales Monica Gerencia Comercial
Re: cdrtools
On Friday 07 July 2006 18:09, Erast Benson wrote: --cut-- > > * dvdrtools, a fork of the last GPLed version, is in non-free > > dvdrtools - totally useless effort. Besides, its known to be buggy and Could you please report issues you face with dvdrtools to the BTS, so that can be resolved if found to be valid. > linux-only which is against Debian philosophy therefore should never be > in main. Please check Debian Policy to get a notion of what could be in main. Furtheremore dvdrtools is (currently) not in main... find out why (hint: take a look at the copyright file). -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Debian Bug Tracking System
Hi, Not trying to start a flame war but can somebody give a convincing explanation as to why don't we have a standard BTS ? If I need to subscribe to a bug I can't use the web interface. The answer you might give is, "Oh! Send am email to [EMAIL PROTECTED]" Can't we have an interface to allow subscribing to a bug through the web interface just like Bugzilla does? Thanks, Ritesh -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." "Stealing logic from one person is plagiarism, stealing from many is research." "The great are those who achieve the impossible, the petty are those who cannot - rrs" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Bug Tracking System
la, 2006-07-08 kello 01:02 +0530, Ritesh Raj Sarraf kirjoitti: > If I need to subscribe to a bug I can't use the web interface. > The answer you might give is, "Oh! Send am email to > [EMAIL PROTECTED]" > > Can't we have an interface to allow subscribing to a bug through the web > interface just like Bugzilla does? Debian as a project, meaning most active developers, have a preference towards an e-mail based bug tracking system. This means, for example, that there is no need to manage yet another web site account. It would not be impossible to add a Bugzilla-like web interface to the Debian BTS, but nobody has done it yet. The best way to make it happen is to do it; asking others to do it hasn't worked before. -- Those who do, decide. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Bug Tracking System
Ritesh Raj Sarraf <[EMAIL PROTECTED]> wrote: > Hi, > > Not trying to start a flame war but can somebody give a convincing explanation > as to why don't we have a standard BTS ? I guess most "standard BTSses" can't be easily manipulated by E-Mail, while ours can. > If I need to subscribe to a bug I can't use the web interface. > The answer you might give is, "Oh! Send am email to > [EMAIL PROTECTED]" > > Can't we have an interface to allow subscribing to a bug through the web > interface just like Bugzilla does? Oh, that's just a missing feature, I don't think it's a problem of the design. Subscribing to bugs is rather new, and there just isn't a web interface for this. Please submit a wishlist bug report against bugs.debian.org, or better provide a patch. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: make -j in Debian packages
On Fri, Jul 07, 2006 at 02:46:15PM +0200, Goswin von Brederlow wrote:
> The point of the helper is to remove the decision from the package
> alone to a central place that is easily configurable for a wide range
> of cases.
Ok, here goes my stab at the helper:
(attached)
Usage:
$(MAKE) -j`debian/concurrency-helper`
(note: you'll need to either chmod +x or insert "perl " after the
first backtick)
Maintainer's manipulation:
on command line
User's manipulation:
ENV var
joeyh's manipulation:
upgrade clause
I see that the rules I used are probably way too cowardly memory-wise
but way too fork-happy where the number of CPUs is concerned. But oh
well, it's not me who is supposed to set the defaults anyway :p
This time an example isn't really needed, but just in case I've used
kbtin as the test package. mentors.debian.net seems to be down, so:
deb-src http://angband.pl/debian unstable main
dget http://angband.pl/debian/kbtin/kbtin_1.0.7-1.dsc
(in an uploadeable state, in case you'll want to test it against real
buildds :p)
Cheers,
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
#!/usr/bin/perl -w
use strict;
use integer;
#Upgrade clause:
my $dh='/usr/bin/dh_concurrency';
exec {$dh} $dh,@ARGV if -x $dh;
=head1 NAME
concurrency-helper - guess a reasonable concurrency level for make
=head1 SYNOPSIS
$(MAKE) -j`B [S>]`
=head1 DESCRIPTION
concurrency-helper is a program that will guess whether running more parallel
I jobs would speed up the build, and write a reasonable argument for I<-j>
on the standard output.
If the environment variable B is set, it will override any
guesses.
=head1 OPTIONS
This is the interface for the package maintainer.
=over 4
=item B<--ram-estimate> I [I]
Give some indication of ram usage, in megabytes. If the host has too
little ram the concurency will be tuned down to prevent swapping. A
broad indication +- a factor of 2 is probably sufficient. The [Y] would
be to indicate ram usage for 32bit and 64bit archs seperately. Given the
pointer size ram usage can vary between them a lot.
=item B<--more-concurrent>
Indicate that there are lots of small files that greatly benefit from
interleaving I/O with cpu time. Try to use more concurency than cpus.
=item B<--max-concurrency> I
Limit the concurrency to no more than X. Shouldn't be ever needed, you're
either SMP-safe or not.
=back
=head1 CAVEATS
This helper can't detect multiple builds running on the same host. In
that case, just set B appropiately; to 1 if you want
to disable any parallelism altogether.
=head1 SEE ALSO
L
=head1 AUTHOR
Adam Borowski <[EMAIL PROTECTED]>
=cut
#Leaving no output would lead to bare -j, that is, -j INFINITY.
sub die_1($)
{
print "1\n" unless -t STDOUT;
die "concurrenct-helper: $_[0]";
}
if (defined $ENV{'CONCURRENCY_LEVEL'})
{
$ENV{'CONCURRENCY_LEVEL'}=~/^(\d+)$/ && $1>0
or die_1 "E: CONCURRENCY_LEVEL malformed.\n";
print "$1\n";
exit;
}
my ($mem,$cpus); #machine's specs
my ($ram32,$ram64,$limit,$extra); #arguments
my $ram;
open FREE, "free|" or die_1 "W: can't run 'free'.\n";
while()
{
$mem=$1/1024 if /^Mem:\s+(\d+)/;
}
close FREE;
$mem or die_1 "W: can't get the amount of memory.\n";
if (open CPUS, ");
close CPUS;
}
$cpus=1 unless $cpus;
while(@ARGV)
{
$_=shift;
if (/^--max-concur(|r)ency$/)
{
$_=shift
or die_1 "E: --max-concurrency requires an argument.\n";
/^(\d+)$/ && $1>0
or die_1 "E: --max-concurrency expects a positive integer.\n";
$limit=$1;
}
elsif (/^--ram-estimate$/)
{
$_=shift
or die_1 "E: --ram-estimate expects an argument or two.\n";
/^(\d+)$/
or die_1 "E: --ram-estimate: ram32 malformed.\n";
$ram32=$1;
#The second argument is optional.
if (@ARGV && $ARGV[0]=~/^(\d+)$/)
{
$ram64=$1;
shift;
}
else
{
$ram64=$ram32;
}
}
elsif (/^--more-concur(|r)en(cy|t)$/)
{
$extra=1;
}
else
{
die_1 "E: invalid argument \"$_\"\n";
}
}
$ram=(length(pack('l!',0)) <= 4)? $ram32:$ram64;
### Here the fun starts.
# Edit this part to fine-tune the logic.
#Default to 24MB per job.
$ram=24 unless $ram;
#Be a coward, use no more than 1/5 of the memory.
$_=$mem/5/$ram;
#Don't have too many jobs waiting for CPU.
my $cap=$cpus+1;
$cap*=2 if $extra;
$_=$cap if $_>$cap;
#Obey --max-concurrency.
$_=$limit if (defined $limit && $_>$limit);
#But use at least _one_ job. We want to get the build done, don't we?
$_=1 if $_<1;
print "$_\n";
Re: Debian Bug Tracking System
On Sat, Jul 08, 2006 at 01:02:44AM +0530, Ritesh Raj Sarraf wrote: > Not trying to start a flame war but can somebody give a convincing explanation > as to why don't we have a standard BTS ? There is a whole host of reasons. Some I can think of offhand: - All other known alternatives have a number of serious problems (at least in the eye of many DDs); everything from "you need to login to do anything" via "it doesn't support version tracking" or "no support for working offline" or "can't be manipulated properly by e-mail". - Lots of tools would need substantial rewrites in order to switch to a new BTS (the amount of tools hooked up into the BTS is quite large). The BTS doesn't stand on its own, it's part of a quite intricate infastructure. - Migrating to a new BTS would probably be quite a lot of work (try migrating 35 bugs in a reasonable timeframe without losing data), and you'd need quite large gains in order to justify that (and to get the people in charge to do it). Others will probably add lots more. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question on setting setuid bit
Hi,
This is an experimental package that we built and
evaluate internally (up to this moment). The program
that needs setuid is a cgi-bin program that is invoked
by apache2, which runs as a regular user www-data. The
cgi-bin program however needs to interact with
iptables.
I know setuid programs are risky but I haven't got the
time to address the security risk yet (one thing at a
time ... :-)
Thanks for the alert.
Clement
On Fri, 7 Jul 2006, Ian Jackson wrote:
> LEE, Yui-wah (Clement) writes ("A question on setting setuid bit"):
> > I am building a package in which one of the binary has
> > to have the setuid and setgid bits set. I wonder which
> > one of the following two is the more appropriate method
> > to use?
>
> Forgive my scepticism, but which package, and why ? set-id bits
> should not be set lightly and they should only be used after careful
> consideration by experts.
>
> Ian.
>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question on setting setuid bit
On Fri, Jul 07, 2006 at 04:42:47PM -0400, LEE, Yui-wah (Clement) wrote: > Hi, > > This is an experimental package that we built and > evaluate internally (up to this moment). The program > that needs setuid is a cgi-bin program that is invoked > by apache2, which runs as a regular user www-data. The > cgi-bin program however needs to interact with > iptables. You are setting up an iptables interface through a setuid *root* cgi-bin? If so: ! > I know setuid programs are risky but I haven't got the > time to address the security risk yet (one thing at a > time ... :-) I can do the security risk analysis for you: granting remote root through a web server application is a recipe for disaster, those tactics where (or should have been) abandoned ages ago. Either you make really damn sure that the cgi-bin is not exploitable through fascist input data validation and a tight SELinux policy or you remove the setuid bit and try to make the functionality you need through other mechanisms. For example: a cgi-bin that locally communicates with a separate daemon and asks it to "pretty please" setup an iptable rule, if you do this the separate daemon can be very strict in which it permits and can do additional data validation, additionaly, a failure in the cgi-bin (i.e. a buffer overflow or similar programming mistake) does not equal to a remote root compromise (at most a remote www-data although that's bad enough already). Just my 2c. Javier signature.asc Description: Digital signature
Re: Debian Bug Tracking System
On Jul 07, Ritesh Raj Sarraf <[EMAIL PROTECTED]> wrote: > Not trying to start a flame war but can somebody give a convincing explanation > as to why don't we have a standard BTS ? Because no such a thing exists, for a start. HTH. -- ciao, Marco signature.asc Description: Digital signature
xmgrace ddd again
Neither xmgrace nor ddd will allow text input for AMD-64 architecture. This is a severe problem. I'm writing to the developers list because their common problem probably means there is, perhaps, a library issue. I shouild point out that I have built from sources and have exactly the same problem. For what it's worth, I have exactly the same problem in fedora core 5, but not on Fedora Corre 4. Art Edwards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xmgrace ddd again
Art Edwards <[EMAIL PROTECTED]> writes: > Neither xmgrace nor ddd will allow text input for AMD-64 > architecture. This is a severe problem. I'm writing to the > developers list because their common problem probably means there > is, perhaps, a library issue. I shouild point out that I have built > from sources and have exactly the same problem. For what it's worth, > I have exactly the same problem in fedora core 5, but not on Fedora > Corre 4. They both have the lesstif widget toolkit in common. That's probably where the bug lies. -- Roger Leigh Printing on GNU/Linux? http://gutenprint.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. pgpKNfZfHhejk.pgp Description: PGP signature
Re: Debian Bug Tracking System
Package: debbugs Version: 2.4.1 Severity: wishlist Tags: patch On Sat, Jul 08, 2006 at 01:02:44AM +0530, Ritesh Raj Sarraf wrote: >If I need to subscribe to a bug I can't use the web interface. >The answer you might give is, "Oh! Send am email to >[EMAIL PROTECTED]" This may be a simple way to add that behaviour. --bod diff -Naur debbugs-2.4.1.orig/cgi/bugreport.cgi debbugs-2.4.1/cgi/bugreport.cgi --- debbugs-2.4.1.orig/cgi/bugreport.cgi2003-05-26 02:26:24.0 +1000 +++ debbugs-2.4.1/cgi/bugreport.cgi 2006-07-08 10:43:23.900414007 +1000 @@ -417,6 +417,7 @@ print "$descriptivehead\n"; printf "View this report as an mbox folder.\n", mboxurl($ref); +print "mailto:[EMAIL PROTECTED]">Subscribe to this bug. print ""; print "$log"; print $tail_html; -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Marcelo Magallon (lib3ds maintainer) MIA?
Hi, Does anybody know if the lib3ds maintainer, Marcelo Magallon (email mmagallo), is still active? lib3ds seems to have gone untended for quite a while -- there are some very old bugs open which even have patches posted. I sent him email about a week about, but have not gotten a reply yet. I ask because I just sent a lib3ds bug report, with a patch, and if he's not around, I'd like to find some other way to get it dealt with... [It'd be nice if some other bugs were fixed too.] Thanks, -miles -- "Suppose He doesn't give a shit? Suppose there is a God but He just doesn't give a shit?" [George Carlin] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question on setting setuid bit
Hi, Thanks for articulating the risk. We will address it later. The machines involved are experimental prototypes not production machines. Clement On Fri, 7 Jul 2006, Javier [iso-8859-1] Fern嫕dez-Sanguino Pe鎙 wrote: > On Fri, Jul 07, 2006 at 04:42:47PM -0400, LEE, Yui-wah (Clement) wrote: > > Hi, > > > > This is an experimental package that we built and > > evaluate internally (up to this moment). The program > > that needs setuid is a cgi-bin program that is invoked > > by apache2, which runs as a regular user www-data. The > > cgi-bin program however needs to interact with > > iptables. > > You are setting up an iptables interface through a setuid *root* cgi-bin? > If so: ! > > > I know setuid programs are risky but I haven't got the > > time to address the security risk yet (one thing at a > > time ... :-) > > I can do the security risk analysis for you: granting remote root through a > web > server application is a recipe for disaster, those tactics where (or should > have been) abandoned ages ago. > > Either you make really damn sure that the cgi-bin is not exploitable through > fascist input data validation and a tight SELinux policy or you remove the > setuid bit and try to make the functionality you need through other > mechanisms. > > For example: a cgi-bin that locally communicates with a separate daemon and > asks it to "pretty please" setup an iptable rule, if you do this the separate > daemon can be very strict in which it permits and can do additional data > validation, additionaly, a failure in the cgi-bin (i.e. a buffer overflow or > similar programming mistake) does not equal to a remote root compromise (at > most a remote www-data although that's bad enough already). > > Just my 2c. > > Javier > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Bug Tracking System
On Sat, Jul 08, 2006 at 10:48:55AM +1000, Brendan O'Dea wrote: > This may be a simple way to add that behaviour. > +print "mailto:[EMAIL PROTECTED]">Subscribe to this bug. What about something like ``To subscribe to this bug, send an empty email to $email.'' to make more explicit that they don't need to fill anything out? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
NB: Please follow Debian list policy and refrain from Cc:'ing me. On Fri, 07 Jul 2006, Erast Benson wrote: > On Fri, 2006-07-07 at 08:39 -0700, Don Armstrong wrote: > > On Fri, 07 Jul 2006, Erast Benson wrote: > > > what? you think if it is non-GPL than it should go to non-free? > > > This is nonsense. > > > > No. The primary issue is that the mixture of a GPL+CDDL work > > creates a work that cannot be distributed by anyone else but the > > copyright holder. > > It seems to be an offtopic here, but could you please elaborate a > little bit further, which particular statement of which license > prevents it? It's pretty obvious if you read the CDDL and the GNU GPL, but just to make it abundantly clear for those who don't read licenses for fun: CDDL 3.1 requires that Covered Works made available in Executable form requires the Source Code form to be distributable only under the CDDL; CDDL 3.4 disallows additional restrictions. CDDL 6.2 (patent retaliation) is a restriction not present in the GPL. GPL 2 requires all of the work when distributed together to apply to the GPL. GPL 6 dissallows additional restrictions. GPL 2c is a requirement not present in the CDDL. As you can see, they're incompatible with eachother in either direction. Indeed, I've been told by those involved in the CDDL drafting that this was done by design. [See the video of the Solaris discussion if you want to see someone talk about it; you can also see me discussing this issue and others as well in the same video.] Don Armstrong -- Cheop's Law: Nothing ever gets built on schedule or within budget. -- Robert Heinlein _Time Enough For Love_ p242 http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: Debian Bug Tracking System
On Fri, 07 Jul 2006, Matthew R. Dempsky wrote: > On Sat, Jul 08, 2006 at 10:48:55AM +1000, Brendan O'Dea wrote: > > This may be a simple way to add that behaviour. > > > +print "mailto:[EMAIL PROTECTED]">Subscribe to this > > bug. > > What about something like ``To subscribe to this bug, send an empty > email to $email.'' to make more explicit that they > don't need to fill anything out? There are a whole host of commands which can be set using e-mail; I'm not averse to adding a link to subscribe to the bug, but adding unnecessary verbiage on every single page seems pointless to me. It is documented in the usage guides for the bts how to do this; I suppose it would be possible to make a page with all of the different things you can do to a bug with the bug numbers filled in already... but since I don't find such a thing particularly useful, I'm not the one to design it. Don Armstrong -- Our days are precious, but we gladly see them going If in their place we find a thing more precious growing A rare, exotic plant, our gardener's heart delighting A child whom we are teaching, a booklet we are writing -- Frederick Rükert _Wisdom of the Brahmans_ [Hermann Hesse _Glass Bead Game_] http://www.donarmstrong.com http://rzlab.ucr.edu
Re: Debian Bug Tracking System
On Fri, Jul 07, 2006 at 08:19:12PM -0700, Don Armstrong wrote: >On Fri, 07 Jul 2006, Matthew R. Dempsky wrote: >> What about something like ``To subscribe to this bug, send an empty >> email to $email.'' to make more explicit that they >> don't need to fill anything out? > >There are a whole host of commands which can be set using e-mail; I'm >not averse to adding a link to subscribe to the bug, but adding >unnecessary verbiage on every single page seems pointless to me. Agreed, hence the suggestion for a simple link. If anything, I think that I'd encode the instructions in the URL: mailto:[EMAIL PROTECTED]&body=not%20required --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
On Fri, 2006-07-07 at 20:15 -0700, Don Armstrong wrote: > NB: Please follow Debian list policy and refrain from Cc:'ing me. > > On Fri, 07 Jul 2006, Erast Benson wrote: > > On Fri, 2006-07-07 at 08:39 -0700, Don Armstrong wrote: > > > On Fri, 07 Jul 2006, Erast Benson wrote: > > > > what? you think if it is non-GPL than it should go to non-free? > > > > This is nonsense. > > > > > > No. The primary issue is that the mixture of a GPL+CDDL work > > > creates a work that cannot be distributed by anyone else but the > > > copyright holder. > > > > It seems to be an offtopic here, but could you please elaborate a > > little bit further, which particular statement of which license > > prevents it? > > It's pretty obvious if you read the CDDL and the GNU GPL, but just to > make it abundantly clear for those who don't read licenses for fun: > > CDDL 3.1 requires that Covered Works made available in Executable form > requires the Source Code form to be distributable only under the CDDL; > CDDL 3.4 disallows additional restrictions. CDDL 6.2 (patent > retaliation) is a restriction not present in the GPL. > > GPL 2 requires all of the work when distributed together to apply to > the GPL. GPL 6 dissallows additional restrictions. GPL 2c is a > requirement not present in the CDDL. > > As you can see, they're incompatible with eachother in either > direction. Indeed, I've been told by those involved in the CDDL > drafting that this was done by design. [See the video of the Solaris > discussion if you want to see someone talk about it; you can also see > me discussing this issue and others as well in the same video.] Thanks for explanations. I knew that they are incompatible but I never fully understood why. Its clear now. Erast -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
On Saturday 08 July 2006 06:15, Don Armstrong wrote:
> NB: Please follow Debian list policy and refrain from Cc:'ing me.
>
> On Fri, 07 Jul 2006, Erast Benson wrote:
> > On Fri, 2006-07-07 at 08:39 -0700, Don Armstrong wrote:
> > > On Fri, 07 Jul 2006, Erast Benson wrote:
> > > > what? you think if it is non-GPL than it should go to non-free?
> > > > This is nonsense.
> > >
> > > No. The primary issue is that the mixture of a GPL+CDDL work
> > > creates a work that cannot be distributed by anyone else but the
> > > copyright holder.
> >
> > It seems to be an offtopic here, but could you please elaborate a
> > little bit further, which particular statement of which license
> > prevents it?
>
> It's pretty obvious if you read the CDDL and the GNU GPL, but just to
> make it abundantly clear for those who don't read licenses for fun:
>
> CDDL 3.1 requires that Covered Works made available in Executable form
> requires the Source Code form to be distributable only under the CDDL;
> CDDL 3.4 disallows additional restrictions. CDDL 6.2 (patent
> retaliation) is a restriction not present in the GPL.
>
> GPL 2 requires all of the work when distributed together to apply to
> the GPL. GPL 6 dissallows additional restrictions. GPL 2c is a
> requirement not present in the CDDL.
>
> As you can see, they're incompatible with eachother in either
> direction. Indeed, I've been told by those involved in the CDDL
> drafting that this was done by design. [See the video of the Solaris
> discussion if you want to see someone talk about it; you can also see
> me discussing this issue and others as well in the same video.]
Well, I have the following 'and' vs. 'or' type of licensing question. While it
is clear now that Debian can not distribute a product when some of its parts
are under GPL and the rest are under CDDL ('and'), is it fine to
double-license {GPL|CDDL} the whole product like Perl does with GPL |
Artistic, so either the whole thing is under GPL or the whole thing under
CDDL as accepted by the licensee. In short, could you double license under
two incompatible licenses ? Should be fine imho, since licensee accepts just
one of them, and does not the other one.
--
pub 4096R/0E4BD0AB 2003-03-18
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Dual licensing [Was: Re: cdrtools]
We've stepped into -legal territory now. MFT set to send messages only
to -legal; please respond there only.
On Sat, 08 Jul 2006, George Danchev wrote:
> Well, I have the following 'and' vs. 'or' type of licensing
> question. While it is clear now that Debian can not distribute a
> product when some of its parts are under GPL and the rest are under
> CDDL ('and'), is it fine to double-license {GPL|CDDL} the whole
> product like Perl does with GPL | Artistic, so either the whole
> thing is under GPL or the whole thing under CDDL as accepted by the
> licensee. In short, could you double license under two incompatible
> licenses ?
As far as I understand it (TINLA, IANAL, YHBW, etc.) so long as there
is a subset of licenses available which you can use to actually
distribute the work, you ignore the licenses which you don't
distribute under. It is a good practice to list the other licenses in
the copyright file as a service to our users, but strictly speaking
they are superfluous. [In the cases where they are not, you're not
actually dual licensing the work.]
Of course, you have to actually own the copyright on the parts that
you are (re)licensing but that's probably obvious. ;-)
Don Armstrong
--
THERE IS NO GRAVITY THE WORLD SUCKS
-- Vietnam War Penquin Lighter
http://gallery.donarmstrong.com/clippings/vietnam_there_is_no_gravity.jpg
http://www.donarmstrong.com http://rzlab.ucr.edu
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
