Re: Reforming 'orig.tar.gz' with included tar-ball.
onsdag den 27 januari 2010 klockan 10:01 skrev Paul Wise detta: On Wed, Jan 27, 2010 at 10:00 AM, Mats Erik Andersson mats.anders...@gisladisker.se wrote: The upstream author is a long time Debian Developer that has not touched the code since 2004. Ah, I guess you could/should take over this project too. Which package is it BTW? It is Webfs, for its purpose a useful web server, but the present versions of Gcc emit warnings due to inconsistent string types. -- Mats Erik Andersson, fil. dr -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Reforming 'orig.tar.gz' with included tar-ball.
On Wed, Jan 27, 2010 at 10:46 PM, Mats Erik Andersson mats.anders...@gisladisker.se wrote: It is Webfs, for its purpose a useful web server, but the present versions of Gcc emit warnings due to inconsistent string types. Ah, looks like upstream doesn't use a hosting service like sf.net. If you're unable to contact upstream, you would have to fork it rather than take over the project. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Reforming 'orig.tar.gz' with included tar-ball.
torsdag den 28 januari 2010 klockan 07:11 skrev Paul Wise detta: On Wed, Jan 27, 2010 at 10:46 PM, Mats Erik Andersson mats.anders...@gisladisker.se wrote: It is Webfs, for its purpose a useful web server, but the present versions of Gcc emit warnings due to inconsistent string types. Ah, looks like upstream doesn't use a hosting service like sf.net. If you're unable to contact upstream, you would have to fork it rather than take over the project. I have no immediate intention to take over upstream, since I believe it to be responsive enough, my sturdieness concerns at the moment only the revival of the Debian package maintenance. The package did (and does) inactivate the SSL-library because of the license clash against GPL. According to the records in BTS, some efforts to develop a patch to use GnuTLS instead of OpenSSL was begun, but they never reached completion. Springtime will reveal whether I can do any better. For the learning experience I will develop a second version of my presently updated (which by the way works very well with a better provisions to use the capacities inherent in Webfs) to use the new 3.0-quilt format. Regards, Mats E A -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Reforming 'orig.tar.gz' with included tar-ball.
Hello all mentors, I am in the process of fulfilling an ITA filed on an orphaned package. However, I now experience a desire to begin patching the upstream source for compiling errors and spelling errors in the manual page. To my dismay the previous maintainer chose to let the 'orig.tar.gz'-file contain the packaged and compressed upstream tar archive. My personal taste is to abondon this practice, if for no other reason to simplify the rules-file. Is there some reverence that should prevent me from taking the step of letting a new 'orig.tar.gz' be a byte-for-byte copy of the upstream source archive? I will make the new package conform to 3.0 (quilt). -- Mats Erik Andersson, fil. dr signature.asc Description: Digital signature
Re: Reforming 'orig.tar.gz' with included tar-ball.
On Tuesday 26,January,2010 06:44 PM, Mats Erik Andersson wrote: Hello all mentors, I am in the process of fulfilling an ITA filed on an orphaned package. However, I now experience a desire to begin patching the upstream source for compiling errors and spelling errors in the manual page. To my dismay the previous maintainer chose to let the 'orig.tar.gz'-file contain the packaged and compressed upstream tar archive. My personal taste is to abondon this practice, if for no other reason to simplify the rules-file. Is there some reverence that should prevent me from taking the step of letting a new 'orig.tar.gz' be a byte-for-byte copy of the upstream source archive? I will make the new package conform to 3.0 (quilt). AFAIK the orig.tar.gz should be a byte-for-byte copy of the upstream source archive wherever possible, and packaging the upstream source archive within a separate, self-created orig.tar.gz is a practice to be avoided unless there is a very strong reason for it. I believe this holds true for both the 1.0 and 3.0 source formats. -- Kind regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
Re: Reforming 'orig.tar.gz' with included tar-ball.
Mats Erik Andersson wrote: Is there some reverence that should prevent me from taking the step of letting a new 'orig.tar.gz' be a byte-for-byte copy of the upstream source archive? I will make the new package conform to 3.0 (quilt). It's nothing wrong and even preferable to convert your package to 3.0 format. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Reforming 'orig.tar.gz' with included tar-ball.
Chow Loong Jin wrote: On Tuesday 26,January,2010 06:44 PM, Mats Erik Andersson wrote: Hello all mentors, I am in the process of fulfilling an ITA filed on an orphaned package. However, I now experience a desire to begin patching the upstream source for compiling errors and spelling errors in the manual page. To my dismay the previous maintainer chose to let the 'orig.tar.gz'-file contain the packaged and compressed upstream tar archive. My personal taste is to abondon this practice, if for no other reason to simplify the rules-file. Is there some reverence that should prevent me from taking the step of letting a new 'orig.tar.gz' be a byte-for-byte copy of the upstream source archive? I will make the new package conform to 3.0 (quilt). AFAIK the orig.tar.gz should be a byte-for-byte copy of the upstream source archive wherever possible, and packaging the upstream source archive within a separate, self-created orig.tar.gz is a practice to be avoided unless there is a very strong reason for it. I believe this holds true for both the 1.0 and 3.0 source formats. I'd like to temper the above. I think that creating changes in the upstream code is fine if the idea is to have the orig.tar.gz comply better to the policy (not sure if it's the case here), or if the upstream has non-free code that you want to get rid of, but my personal advice is to provide the script to do it in the debian/ folder and document it in README.Source, so that an eventual new maintainer can easily take over. Thomas -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Reforming 'orig.tar.gz' with included tar-ball.
Mats Erik Andersson mats.anders...@gisladisker.se writes: Hello all mentors, I am in the process of fulfilling an ITA filed on an orphaned package. However, I now experience a desire to begin patching the upstream source for compiling errors and spelling errors in the manual page. To my dismay the previous maintainer chose to let the 'orig.tar.gz'-file contain the packaged and compressed upstream tar archive. My personal taste is to abondon this practice, if for no other reason to simplify the rules-file. Is there some reverence that should prevent me from taking the step of letting a new 'orig.tar.gz' be a byte-for-byte copy of the upstream source archive? I will make the new package conform to 3.0 (quilt). -- Mats Erik Andersson, fil. dr I only know of one reason to have a upstream.tar file inside the orig.tar (but there might be more, not important here). It makes it simpler to build multiple flavours of a source. E.g.: - with different configure arguments when out-of-tree builds aren't supported - with different patches applied Unpacking the upstream.tar to build-flavour and deleting that in clean makes for a simple rules file. Also helps if upstreams build system doesn't have a working clean target. But now we have the 3.0 (quilt) format that supports multiple upstream tarballs. A little trick you can do there is to have an empty package_1.2.orig.tar.gz and the actual upstream source as package_1.2.orig-upstream.tar.gz/bz2. The source gets then automatically unpacked into a subdir (upsream in this example) and you can copy that to build-flavour. As a bonus you can use the 3.0 (quilt) debian/patches feature on the upstream dir and only need your own patch system for the per flavour patches (if you have any). So even for the case where I think tar-in-tar was better the 3.0 (quilt) format solves that. Having the upstream source unpacked and using pristine-tar saves a lot of space in a version conrol system and makes tracking changes in upstream a lot simpler imho. MfG Goswin -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Reforming 'orig.tar.gz' with included tar-ball.
Hello, Mats Erik Andersson mats.anders...@gisladisker.se wrote: To my dismay the previous maintainer chose to let the 'orig.tar.gz'-file contain the packaged and compressed upstream tar archive. My personal taste is to abondon this practice, if for no other reason to simplify the rules-file. I know one reason: inside the upstream package are binary files, which must be created new while packaging (build) and then the original binary files of upstream get lost ... This seems to be independent of the package format. For me the solution would be: creating a reduced orig.tar.gz file without those binaries. Would be this the right way? Fondest regards, Joachim Wiedorn signature.asc Description: PGP signature
Re: Reforming 'orig.tar.gz' with included tar-ball.
Joachim Wiedorn ad_deb...@joonet.de writes: Hello, Mats Erik Andersson mats.anders...@gisladisker.se wrote: To my dismay the previous maintainer chose to let the 'orig.tar.gz'-file contain the packaged and compressed upstream tar archive. My personal taste is to abondon this practice, if for no other reason to simplify the rules-file. I know one reason: inside the upstream package are binary files, which must be created new while packaging (build) and then the original binary files of upstream get lost ... This seems to be independent of the package format. For me the solution would be: creating a reduced orig.tar.gz file without those binaries. Would be this the right way? Fondest regards, Joachim Wiedorn Then you delete them in clean and ignore the dpkg-source output about ignoring deletion of stupid/binary. Unless the binaries are not illegal to distribute in main or overly big they are no reason why the upstream.tar must be repacked. MfG Goswin -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Reforming 'orig.tar.gz' with included tar-ball.
On Tue, Jan 26, 2010 at 6:44 PM, Mats Erik Andersson mats.anders...@gisladisker.se wrote: I am in the process of fulfilling an ITA filed on an orphaned package. However, I now experience a desire to begin patching the upstream source for compiling errors and spelling errors in the manual page. Since you are now part of upstream (I assume this is nettoe), just make those changes in the upstream version control repository and make a new release. If this isn't nettoe, send patches upstream and prod them into making a new release. To my dismay the previous maintainer chose to let the 'orig.tar.gz'-file contain the packaged and compressed upstream tar archive. My personal taste is to abondon this practice, if for no other reason to simplify the rules-file. Please do so, tarball-in-tarball packages are horrible. With 3.0 (quilt) format there is much less reason to use them. Is there some reverence that should prevent me from taking the step of letting a new 'orig.tar.gz' be a byte-for-byte copy of the upstream source archive? I will make the new package conform to 3.0 (quilt). You'll need to make the upstream version of the new tarball different to the current one in Debian, otherwise the new tarball will be rejected by dak. If you/upstream release a new upstream version you won't need to resort to version number hacks. The usual version number hack is to append +ds1 to the upstream version number. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Reforming 'orig.tar.gz' with included tar-ball.
Hello all, so many comments, but no two take similar viewpoints. The absolute winner from an informational point was the first exposition of Goswin von Bredow. Read it again! Let me comment lightly to indicate that I appreciate all your comments. Very useful learning material indeed. By chance I take Paul's letter for my cue lines. No offence intended! onsdag den 27 januari 2010 klockan 09:05 skrev Paul Wise detta: On Tue, Jan 26, 2010 at 6:44 PM, Mats Erik Andersson I am in the process of fulfilling an ITA filed on an orphaned package. However, I now experience a desire to begin patching the upstream source for compiling errors and spelling errors in the manual page. Since you are now part of upstream (I assume this is nettoe), just No, I nurish my own source better than this! (Or am I infamous?) Nettoe is in unstable since eleven days, a mips-machine is delaying! make those changes in the upstream version control repository and make a new release. If this isn't nettoe, send patches upstream and prod them into making a new release. The upstream author is a long time Debian Developer that has not touched the code since 2004. To my dismay the previous maintainer chose to let the 'orig.tar.gz'-file contain the packaged and compressed upstream tar archive. My personal taste is to abondon this practice, if for no other reason to simplify the rules-file. Please do so, tarball-in-tarball packages are horrible. With 3.0 (quilt) format there is much less reason to use them. Is there some reverence that should prevent me from taking the step of letting a new 'orig.tar.gz' be a byte-for-byte copy of the upstream source archive? I will make the new package conform to 3.0 (quilt). You'll need to make the upstream version of the new tarball different to the current one in Debian, otherwise the new tarball will be rejected by dak. If you/upstream release a new upstream version you won't need to resort to version number hacks. The usual version number hack is to append +ds1 to the upstream version number. I have spent most of today on the restoration of the package, thereby resolving four bugs and thirteen lintian warnings. It is now fully clean, only mentioning twelve overrides. The present package will undergo testing before I look for a sponsor, but for a starter I decided to keep the original packaging structure since I found out that a could drop five paches into a subdirectory package_0.0/dist/ which in the previous packaging only contained upstream's original tar-archive. The possibility to drop patches there was hidden in package_0.0/debian/prepare-work a good and sound script. regards -- Mats E Andersson -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Reforming 'orig.tar.gz' with included tar-ball.
On Wed, Jan 27, 2010 at 10:00 AM, Mats Erik Andersson mats.anders...@gisladisker.se wrote: The upstream author is a long time Debian Developer that has not touched the code since 2004. Ah, I guess you could/should take over this project too. Which package is it BTW? -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
