Re: Help on policy
Falco Cesare <[EMAIL PROTECTED]> writes: > Like all computer emulator, they need the original Spectrum roms. They can > be freely distributed with emulator, but Amstrad still owns the copyright, > so I can't consider them "free" according to the policy. What is the exact license of the ROMs? Are they dejure distributable or only defacto (i.e. too old that anybody bothers to sue, like the C64 kernel)? -- Robbe signature.ng Description: PGP signature
Re: dpkg-source -i on debian native packages
[EMAIL PROTECTED] (Stefan Hornburg (Racke)) writes: > IMHO, CVS files should never part of a .tar.gz. Why? Including CVS information enables receivers of the tarball to quickly update their version to a more current (actually any) version. Just transferring deltas eats less bandwidth than a checkout from scratch. -- Robbe signature.ng Description: PGP signature
Re: Help on policy
Falco Cesare <[EMAIL PROTECTED]> writes: > Like all computer emulator, they need the original Spectrum roms. They can > be freely distributed with emulator, but Amstrad still owns the copyright, > so I can't consider them "free" according to the policy. What is the exact license of the ROMs? Are they dejure distributable or only defacto (i.e. too old that anybody bothers to sue, like the C64 kernel)? -- Robbe signature.ng Description: PGP signature
Re: dpkg-source -i on debian native packages
[EMAIL PROTECTED] (Stefan Hornburg (Racke)) writes: > IMHO, CVS files should never part of a .tar.gz. Why? Including CVS information enables receivers of the tarball to quickly update their version to a more current (actually any) version. Just transferring deltas eats less bandwidth than a checkout from scratch. -- Robbe signature.ng Description: PGP signature
Re: dpkg-source -i on debian native packages
Adam Heath wrote: > Never build a full release from the cvs work directory. Always cvs export to > another directory first. > > Doing test builds from the cvs work dir is fine. But do final releases from a > temp dir. Sometimes, the cvs work dir is poluted, and having a fresh checkout > is safer for repeatability. It is pretty hard to cvs export when you are not on the net, or when you are behind a dog-slow dialup connection and a cvs export would take an hour. Any "pollution" of a cvs working directory should be easily detectable, and is no more likely than "pollution" of a directory that is not managed by cvs. Just make sure that your build script deals with .#* files at the same time it is dealing with *~ files and so on. The real problem to watch out for if building in this way is that any source files you add to the tree are included in the tarball, but may not yet be in cvs, which could result in an inconsistent tagging of your build tree. I used to have my build scripts copy the working directory to a temporary directory, remove all the cvs cruft from there, and build there (poor man's cvs export..), but the big problem with building in a temporary directory, no matter how it's generated is that this doesn't let you fully test your debian/rules clean. I found that my packages were accumulating many bugs in the clean rule and so I stopped building in a temporary tree. BTW, see bug #75947 -- see shy jo
Re: dpkg-source -i on debian native packages
On 26 Nov 2001, Stefan Hornburg (Racke) wrote: > Stefano Zacchiroli <[EMAIL PROTECTED]> writes: > > > On Sun, Nov 25, 2001 at 05:16:27PM +0100, Christian Surchi wrote: > > > On Sun, Nov 25, 2001 at 02:59:03PM +0100, Stefano Zacchiroli wrote: > > > > The problem is that I have a debian native package (so no .diff.gz) that > > > > came from a CVS repository and I'm guessing if there is a way to not > > > > delete by hand CVS and .cvs... files each time I check out to build the > > > > package. Never build a full release from the cvs work directory. Always cvs export to another directory first. Doing test builds from the cvs work dir is fine. But do final releases from a temp dir. Sometimes, the cvs work dir is poluted, and having a fresh checkout is safer for repeatability.
Re: dpkg-source -i on debian native packages
I'm jumping into this thread a bit late, but... On Mon, Nov 26, 2001 at 03:52:53PM +0100, Stefan Hornburg (Racke) wrote: > Stefano Zacchiroli <[EMAIL PROTECTED]> writes: > > > On Sun, Nov 25, 2001 at 05:16:27PM +0100, Christian Surchi wrote: > > > On Sun, Nov 25, 2001 at 02:59:03PM +0100, Stefano Zacchiroli wrote: > > > > The problem is that I have a debian native package (so no .diff.gz) that > > > > came from a CVS repository and I'm guessing if there is a way to not > > > > delete by hand CVS and .cvs... files each time I check out to build the > > > > package. What about cvs export !? -- Karl E. Jørgensen [EMAIL PROTECTED] www.karl.jorgensen.com Today's fortune: How many chunks could checkchunk check if checkchunk could check chunks? -- Alan Cox pgpdhYw1Gk7q6.pgp Description: PGP signature
Re: dpkg-source -i on debian native packages
Adam Heath wrote: > Never build a full release from the cvs work directory. Always cvs export to > another directory first. > > Doing test builds from the cvs work dir is fine. But do final releases from a > temp dir. Sometimes, the cvs work dir is poluted, and having a fresh checkout > is safer for repeatability. It is pretty hard to cvs export when you are not on the net, or when you are behind a dog-slow dialup connection and a cvs export would take an hour. Any "pollution" of a cvs working directory should be easily detectable, and is no more likely than "pollution" of a directory that is not managed by cvs. Just make sure that your build script deals with .#* files at the same time it is dealing with *~ files and so on. The real problem to watch out for if building in this way is that any source files you add to the tree are included in the tarball, but may not yet be in cvs, which could result in an inconsistent tagging of your build tree. I used to have my build scripts copy the working directory to a temporary directory, remove all the cvs cruft from there, and build there (poor man's cvs export..), but the big problem with building in a temporary directory, no matter how it's generated is that this doesn't let you fully test your debian/rules clean. I found that my packages were accumulating many bugs in the clean rule and so I stopped building in a temporary tree. BTW, see bug #75947 -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help on policy
On Mon, Nov 26, 2001 at 09:28:47AM +0100, Falco Cesare wrote: > > What would be best? > 1. A non-free debian package including both sources and needed roms > 2. Two debian packages: a contrib one including the source and a non-free > one with the roms only i'd go the latter route. if there are any DFSG free ROM's, then the DFSG free ROMS and the emulator can be main. now, to speak of your copyright issue, for example, linus owns the copyright to the linux kernel. the free software foundation owns the copyright to the GNU utilities. if the copyright ownership is the only thing that prevents the ROM's from being DFSG free, then consider that a moot point. not having read the license of the ROM's in question, i cannot tell you if that is the case or not. if you have questions, ask debian-legal, if you have not already. -john
Re: dpkg-source -i on debian native packages
On 26 Nov 2001, Stefan Hornburg (Racke) wrote: > Stefano Zacchiroli <[EMAIL PROTECTED]> writes: > > > On Sun, Nov 25, 2001 at 05:16:27PM +0100, Christian Surchi wrote: > > > On Sun, Nov 25, 2001 at 02:59:03PM +0100, Stefano Zacchiroli wrote: > > > > The problem is that I have a debian native package (so no .diff.gz) that > > > > came from a CVS repository and I'm guessing if there is a way to not > > > > delete by hand CVS and .cvs... files each time I check out to build the > > > > package. Never build a full release from the cvs work directory. Always cvs export to another directory first. Doing test builds from the cvs work dir is fine. But do final releases from a temp dir. Sometimes, the cvs work dir is poluted, and having a fresh checkout is safer for repeatability. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-source -i on debian native packages
I'm jumping into this thread a bit late, but... On Mon, Nov 26, 2001 at 03:52:53PM +0100, Stefan Hornburg (Racke) wrote: > Stefano Zacchiroli <[EMAIL PROTECTED]> writes: > > > On Sun, Nov 25, 2001 at 05:16:27PM +0100, Christian Surchi wrote: > > > On Sun, Nov 25, 2001 at 02:59:03PM +0100, Stefano Zacchiroli wrote: > > > > The problem is that I have a debian native package (so no .diff.gz) that > > > > came from a CVS repository and I'm guessing if there is a way to not > > > > delete by hand CVS and .cvs... files each time I check out to build the > > > > package. What about cvs export !? -- Karl E. Jørgensen [EMAIL PROTECTED] www.karl.jorgensen.com Today's fortune: How many chunks could checkchunk check if checkchunk could check chunks? -- Alan Cox msg04720/pgp0.pgp Description: PGP signature
Re: dpkg-source -i on debian native packages
Stefano Zacchiroli <[EMAIL PROTECTED]> writes: > On Sun, Nov 25, 2001 at 05:16:27PM +0100, Christian Surchi wrote: > > On Sun, Nov 25, 2001 at 02:59:03PM +0100, Stefano Zacchiroli wrote: > > > The problem is that I have a debian native package (so no .diff.gz) that > > > came from a CVS repository and I'm guessing if there is a way to not > > > delete by hand CVS and .cvs... files each time I check out to build the > > > package. > > > > but are you using cvs-buildpackage? > > No, I had a rapid look at it, and I still prefer to work "by hand". > Anyway, this is a general problem: how to remove some kind of files from > a debian native package source tree. IMHO, CVS files should never part of a .tar.gz. With automake you can do: dist-hook: find $(distdir) -type d -name CVS -print | xargs rm -rf Ciao Racke -- Die Erde bleibt keine Scheibe. --- The earth remains no disk. For projects and other business stuff please refer to COBOLT NetServices (URL: http://www.cobolt.net; Email: [EMAIL PROTECTED]; Phone: 0041-1-3884400)
Re: Help on policy
On Mon, Nov 26, 2001 at 09:28:47AM +0100, Falco Cesare wrote: > > What would be best? > 1. A non-free debian package including both sources and needed roms > 2. Two debian packages: a contrib one including the source and a non-free > one with the roms only i'd go the latter route. if there are any DFSG free ROM's, then the DFSG free ROMS and the emulator can be main. now, to speak of your copyright issue, for example, linus owns the copyright to the linux kernel. the free software foundation owns the copyright to the GNU utilities. if the copyright ownership is the only thing that prevents the ROM's from being DFSG free, then consider that a moot point. not having read the license of the ROM's in question, i cannot tell you if that is the case or not. if you have questions, ask debian-legal, if you have not already. -john -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-source -i on debian native packages
Stefano Zacchiroli <[EMAIL PROTECTED]> writes: > On Sun, Nov 25, 2001 at 05:16:27PM +0100, Christian Surchi wrote: > > On Sun, Nov 25, 2001 at 02:59:03PM +0100, Stefano Zacchiroli wrote: > > > The problem is that I have a debian native package (so no .diff.gz) that > > > came from a CVS repository and I'm guessing if there is a way to not > > > delete by hand CVS and .cvs... files each time I check out to build the > > > package. > > > > but are you using cvs-buildpackage? > > No, I had a rapid look at it, and I still prefer to work "by hand". > Anyway, this is a general problem: how to remove some kind of files from > a debian native package source tree. IMHO, CVS files should never part of a .tar.gz. With automake you can do: dist-hook: find $(distdir) -type d -name CVS -print | xargs rm -rf Ciao Racke -- Die Erde bleibt keine Scheibe. --- The earth remains no disk. For projects and other business stuff please refer to COBOLT NetServices (URL: http://www.cobolt.net; Email: [EMAIL PROTECTED]; Phone: 0041-1-3884400) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help on policy
> > What would be best? > 1. A non-free debian package including both sources and needed roms > 2. Two debian packages: a contrib one including the source and a non-free > one with the roms only > > Please note that it's a really weird situation: the programs can be built > without the roms, but they can't run without them! > either option makes sense. How does the upstream handle this? Is everything in one tarball? If so, keep it that way.
Re: Help on policy
Hi, Falco Cesare writes: > What would be best? > 1. A non-free debian package including both sources and needed roms > 2. Two debian packages: a contrib one including the source and a > non-free one with the roms only > Please note that it's a really weird situation: the programs can be > built without the roms, but they can't run without them! I wouldn't consider this weird but common to many emulators. I had a similar issue with the Mac-on-Linux emulator mol. At present, it depends strongly on Mac OS ROM files and since those are not even distributable, the package (without the ROM files) went into contrib. This will change when it becomes possible to also start the emulator from boot loaders for free OSes. In your case, I would put everything into one non-free package. If the roms become free, you can still change into main. If alternative roms become available, you can split the package. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Help on policy
Title: Help on policy I'm at present playing with a couple of Sinclair Spectrum emulator and would like to debianize them both. But here's the problem. Like all computer emulator, they need the original Spectrum roms. They can be freely distributed with emulator, but Amstrad still owns the copyright, so I can't consider them "free" according to the policy. What should I do regarding to the section? The packages are both GPL'd and they could be considered main-able, but strongly depends from the non-free roms. What would be best? 1. A non-free debian package including both sources and needed roms 2. Two debian packages: a contrib one including the source and a non-free one with the roms only Please note that it's a really weird situation: the programs can be built without the roms, but they can't run without them! Thanks in advance for any (welcome!) suggestion. Cesare.
Re: Help on policy
> > What would be best? > 1. A non-free debian package including both sources and needed roms > 2. Two debian packages: a contrib one including the source and a non-free > one with the roms only > > Please note that it's a really weird situation: the programs can be built > without the roms, but they can't run without them! > either option makes sense. How does the upstream handle this? Is everything in one tarball? If so, keep it that way. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help on policy
Hi, Falco Cesare writes: > What would be best? > 1. A non-free debian package including both sources and needed roms > 2. Two debian packages: a contrib one including the source and a > non-free one with the roms only > Please note that it's a really weird situation: the programs can be > built without the roms, but they can't run without them! I wouldn't consider this weird but common to many emulators. I had a similar issue with the Mac-on-Linux emulator mol. At present, it depends strongly on Mac OS ROM files and since those are not even distributable, the package (without the ROM files) went into contrib. This will change when it becomes possible to also start the emulator from boot loaders for free OSes. In your case, I would put everything into one non-free package. If the roms become free, you can still change into main. If alternative roms become available, you can split the package. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Help on policy
Title: Help on policy I'm at present playing with a couple of Sinclair Spectrum emulator and would like to debianize them both. But here's the problem. Like all computer emulator, they need the original Spectrum roms. They can be freely distributed with emulator, but Amstrad still owns the copyright, so I can't consider them "free" according to the policy. What should I do regarding to the section? The packages are both GPL'd and they could be considered main-able, but strongly depends from the non-free roms. What would be best? 1. A non-free debian package including both sources and needed roms 2. Two debian packages: a contrib one including the source and a non-free one with the roms only Please note that it's a really weird situation: the programs can be built without the roms, but they can't run without them! Thanks in advance for any (welcome!) suggestion. Cesare.
