Re: modified email address in debian/copyright file
On 2007-09-27 16:39 +1000, Ben Finney wrote: Lars Wirzenius [EMAIL PROTECTED] writes: I don't think there is any requirement to have any upstream contact information whatsoever in order to be able to distribute a package. This seems to be the point of disagreement. I think this should be required, in order that Debian users can have more confidence [0] in the copyright status of works in Debian. This is your goal. It's up to you to find a way to meet it while respecting the wishes of the upstream authors. If you can't, the wishes of the upstream authors take precedence and you don't distribute the package. Do we agree on that ? -- André Majorel http://www.teaser.fr/~amajorel/ Thanks to the Debian project for going to such lengths never to disclose the email addresses of their users. Think of all the spam we would get if they didn't ! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: modified email address in debian/copyright file
On 2007-09-24 13:17 -0500, Steve Greenland wrote: On 24-Sep-07, 04:30 (CDT), Andre Majorel [EMAIL PROTECTED] wrote: On 2007-09-24 18:21 +1000, Ben Finney wrote: Andre Majorel [EMAIL PROTECTED] writes: On 2007-09-23 17:22 -0700, Don Armstrong wrote: The package should include in the copyright file the correct email address for whatever contact information the upstream author(s) use to receive queries from users and other people. This email address will be used by humans. Why does it have to be machine readable ? So that the information can be presented *to* humans *by* machines. How do you determine that being able to do that is more important than concerns over disseminating other people's email addresses without their permission ? These would be the same people who are distributing the code, right? And who put their preferred public e-mail address in the associated documentation? If you don't want a particular e-mail address distributed, then don't distribute it. The people who mind having their address published are not likely to hand it out without obfuscating it. -- André Majorel http://www.teaser.fr/~amajorel/ bugs.debian.org, a spammer's favourite. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: modified email address in debian/copyright file
On 2007-09-23 17:22 -0700, Don Armstrong wrote: On Sun, 23 Sep 2007, Andre Majorel wrote: On 2007-09-20 23:10 +1000, Ben Finney wrote: I would not be against a policy requirement that email addresses in package metadata should be the literal address without munging. I would not be against a policy requirement that packagers *ask* third parties before publishing their email addresses. The package should include in the copyright file the correct email address for whatever contact information the upstream author(s) use to receive queries from users and other people. This email address will be used by humans. Why does it have to be machine readable ? Contacting authors when you package something is always a good idea, but I see no reason to make it a requirement I see no reason not to make it a requirement. -- André Majorel http://www.teaser.fr/~amajorel/ M. X, éleveur de spambots, recommande lists.debian.org. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: modified email address in debian/copyright file
On 2007-09-24 18:21 +1000, Ben Finney wrote: Andre Majorel [EMAIL PROTECTED] writes: On 2007-09-23 17:22 -0700, Don Armstrong wrote: The package should include in the copyright file the correct email address for whatever contact information the upstream author(s) use to receive queries from users and other people. This email address will be used by humans. Why does it have to be machine readable ? So that the information can be presented *to* humans *by* machines. How do you determine that being able to do that is more important than concerns over disseminating other people's email addresses without their permission ? -- André Majorel http://www.teaser.fr/~amajorel/ lists.debian.org, a spammer's delight. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: modified email address in debian/copyright file
On 2007-09-20 23:10 +1000, Ben Finney wrote: I would not be against a policy requirement that email addresses in package metadata should be the literal address without munging. I would not be against a policy requirement that packagers *ask* third parties before publishing their email addresses. -- André Majorel http://www.teaser.fr/~amajorel/ Thanks to the Debian project for keeping my email address secret and keeping me from being spammed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: many packages FTBFS, if $TAPE is set
On 2007-08-28 12:22 -0700, Russ Allbery wrote: I don't have any time to work on this, but it occurred to me reading this that it might be useful for QA purposes to have a version of debuild that *unsanitizes* the environment to test robustness. An evil-debuild that sets every problematic environment variable that it can think of (TAPE, QUILT_PATCHES, LANG, LC_ALL, PWD, etc.), builds the source in a directory name containing a space, and otherwise tries all the environmental things that have broken packages in the past. Setting POSIXLY_CORRECT is an easy way to break lots of scripts. -- André Majorel http://www.teaser.fr/~amajorel/ Choosy spammers prefer lists.debian.org. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: many packages FTBFS, if $TAPE is set
On 2007-08-29 10:58 -0500, John Goerzen wrote: On Tue August 28 2007 3:11:20 pm Eduard Bloch wrote: Oh, come on. People who put $TAPE into the default environment may also link /dev/null to /dev/hda (or /dev/sda) and complain to the coretutils maintainer because ln isn't unable to think for them. I don't think so. Hasn't tar defaulted to something approximately /dev/rmt0 for *YEARS*, not just on Linux but on just about every platform, if -f is not given? Yes. By default, tar c writes to some tape drive, not to stdout. The exact device is implementation-defined. It's /dev/rmt/0m on HP-UX, /dev/rmt0 on AIX, /dev/ntape/tape0 on Digital Unix... GNU tar defaults to stdout because it's cross-platform. Assuming that tar goes to stdout is a losing proposition, I think, and not just because of TAPE. Exactly. The safe, portable way to write to stdout is -f -. -- André Majorel http://www.teaser.fr/~amajorel/ Choosy spammers prefer lists.debian.org. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
User-defined fields in control file
Would it be OK for an ISV to insert a user-defined field (X-Yoyodyne-Peanuts) in their binary Debian packages ? Name collisions aside, no chance of causing problems with dpkg, apt and friends ? Thanks in advance. -- André Majorel URL:http://www.teaser.fr/~amajorel/ Do not use this account for regular correspondence. See the URL above for contact information. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
First spam
First use of email address: 2004-10-06 18:56 (UTC) First spam received at email address: 2004-10-09 17:12 (UTC) If you've been wondering how long it takes for an email address to propagate from the Debian list archives to spammers, here's one data point: less than 71 hours. -- André Majorel URL:http://www.teaser.fr/~amajorel/ Do not use this account for regular correspondance. See the URL above for contact information.
Installed-Size and block size
Is the Installed-Size field supposed to be computed for a specific block size, or can I just go with a usual block size like 4k ? -- André Majorel URL:http://www.teaser.fr/~amajorel/ Do not use this account for regular correspondance. See the URL above for contact information.
Re: Installed-Size and block size
On 2004-10-06 16:09 +0100, Henning Makholm wrote: Scripsit Andre Majorel [EMAIL PROTECTED] Is the Installed-Size field supposed to be computed for a specific block size, or can I just go with a usual block size like 4k ? Do not try to compute Installed-Size by hand - dpkg-gencontrol will do it for you correctly. For my enlightenment, what does dpkg-gencontrol do that is more correct than summing st_blocks ? That is, unless you have a specific very good reason to bypass dpkg-gencontrol (or its debhelper wrapper). I only use dpkg-architecture and dpkg-deb -b. Everything under DEBIAN/ is generated by hand. Do you? Those are packages for a proprietary product. I looked into debhelper but it was just getting in the way by forcing me to use a framework that seemed overly complex and not well suited to our (my employer's) procedures. -- André Majorel URL:http://www.teaser.fr/~amajorel/ Do not use this account for regular correspondance. See the URL above for contact information.
Re: doom source GPL'd
At 00:57 1999.10.04 +0100, you wrote: Andre Majorel [EMAIL PROTECTED] wrote: How can they put limitations on your piece off work, I do not understand, do they have a patent on wad files (I do not think so). I don't think so either but they act like they had. IIRC, the deal was : OK, we'll let you reverse-engineer the wad format and write tools to create wad files but we'll sue you if - you make wads that work with shareware Doom (because then no-one would register) - you sell wads (we want to be the one who make money with Doom). I don't know whether this contract has any legal value but, so far no-one I know of has violated it. Probably in part because almost everyone in the Doom hacking community respects and loves id (the fact is they've always been surprisingly friendly to us). On the other hand, this is 1999 and Doom is probably a marginal part of their revenue now. And they've released it under the GPL (where is the announcement, BTW ?) -- that might void any restrictions on the wad format. So, - should their contract be enforced on the tools ? - if so, would that prevent them from going in the main section ? André Majorel [EMAIL PROTECTED] http://www.teaser.fr/~amajorel/
Re: doom source GPL'd
At 13:17 1999.10.03 -0700, Joseph Carter wrote: On Sun, Oct 03, 1999 at 12:41:51PM -0700, Joey Hess wrote: It looks like the doom source is now under the GPL. (http://www.doomworld.com/). This clears up the previous licencing problems that were keeping it out of debian. It will still be fit only for contrib for now, since it needs non-free WAD files. Who's going to mackage it? Joe Drew has lxdoom and I have agreed to sponsor his packages as soon as I'm caught up with school again. I (will) have dosdoom as soon as Andrew Apted gets the dosdoom team off their tails to release the new version! =p Nobody has offered yet to take xdoom, but I suppose we don't NEED linuxdoom really except for comparison's sake, so it's not exactly a big deal. Careful with that term xdoom. There is a Doom hack really called XDoom and that has nothing to do with linuxxdoom. It was AFAIK the first working X port of Doom after linuxxdoom and it is certainly worth packaging, even if it doesn't support high-res. Because the IWAD is non-free, before DOOM can go into main I have to get a WAD editor packaged. I'm looking at yadex now, which is based on DEU. Please by all means use the latest semi-public beta (no link from the home page) http://www.teaser.fr/~amajorel/yadex/yadex-1.1.0.tar.gz. Yadex 1.0.1 is severely obsolete. Now that I'm done with DeuTex, I hope to resume work on Yadex and release v1.1.1 this month. Let me know how it goes for you. I would also love to see the following utilities packaged : - xwadtools (ftp://ftp.cdrom.com/pub/idgames/source/xwadtools-*.tar.gz) A large collection of Doom hacking utilities, including an editor, tkwadcad. Definitely a must. - DeuTex (http://www.teaser.fr/~amajorel/deutex/) I'm unsure whether Doom hacking utils can go in the main section at all because I seem to remember that id set some conditions on them. They shouldn't work with the shareware iwad, the resulting wads shouldn't be sold for profit, stuff like that. Would the GPLization of Doom change that ? André Majorel [EMAIL PROTECTED] http://www.teaser.fr/~amajorel/
