Re: Fwd: RFS: gcc-4.5-doc-non-dfsg
On 28.09.2012 03:53, Paul Wise wrote: Has the FSF been asked to switch to plain GFDL so that we can move the GCC docs to main? They did that for the autoconf documentation recently. yes. but you may want to try again. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50659fcb.6020...@debian.org
Re: Fwd: RFS: gcc-4.5-doc-non-dfsg
Hi, On 02/15/2012 04:02 AM, Samuel Bronson wrote: On Tue, Feb 7, 2012 at 2:59 PM, Samuel Bronson naes...@gmail.com wrote: On Sun, Feb 5, 2012 at 7:17 AM, Nikita V. Youshchenko yo...@debian.org wrote: In good old days when I had time and motivation to maintain gcc-doc, I've used git repos to managed entire thing. I've just created externally-available mirror for those - please check http://yoush.homelinux.org:8079/git Could you please clone these repos, and reformat your work into this format? IMO this format greatly helps to keep things consistent. I can certainly try! Okay, I've cloned your gcc-doc repository and added my changes: git clone https://github.com/SamB/debian-gcc-doc (Or open it in your browser, or ...) I'm holding off on updating the 4.4 control files and the -defaults packages for the moment: I want to streamline the new X.Y process a bit more first. Maybe this could be moved to git.debian.org. Yes, that sounds like a good idea. Then I could add the Vcs-*: fields to debian/control. Of course, there will probably be a lot to update in README.source then... As for the rest, here are several more comments: *) I don't really understand the workflow of gcc-doc-non-dfgs converted to 3.0 (quilt) format. With old format, there was debian/patches, managed by dpatch, with part of patches managed by hands, and part managed by a perl script. Running the script altered debian/patches/* files, including series file. But isn't this unsafe for 3.0 (quilt) format since it will break metadata in .pc/ directory? Hmm. Perhaps the script should simply refuse to run whenever there is a .pc directory? (It seems that dpkg-source removes this after unapplying the patches.) In any case, most of this is changed very little; the script just gets to be a bit shorter since the patches no longer have to be shell scripts. Also, if you convert to 3.0 (quilt), why still mentioning dpatch in README.source? That was an accident. I've corrected this now. *) Looks like your command line for patch convertion script is much shorter that in was in previous times. How did you check which patches to apply and which not? Well, I grepped the GCC package's debian/patches for anything that changed .texi files, and looked through the debian/rules.patch to see which of those seemed to be applied for Debian builds on any architecture (in that alternate universe where GFDL_INVARIANT_FREE=no). Actually I've looked at updating gcc-doc during new year holidays, and stopped and postponed it exactly at this point. It was unclear what patches to apply, looked like some procedure/policy was needed, and I could not think your such a policy at that time. The idea was to check what patches are applied for each of in-debian architectures, and apply doc changes for all of those. This could likey be automated, e.g. by writing a makefile that will include debian/rules2 from gcc package, and then use vars set by that to print list of applied patches; some tricks with var-setting could do this for all archs. Hmm, not a terrible idea. I still think the *very* cleanest thing would probably be to build gcc-X.Y-doc-non-dfsg like this, though: [Oops, I forgot to finish this bit:] * Take the debian/ directory from gcc-X.Y + uncomment the documentation patches if necessary + replace debian/control with one that only builds the documentation packages + arrange for GFDL_INVARIANT_FREE=no to be set * Put a pristine upstream tarball in the root of the tree in place of the stripped one that gcc-X.Y uses. (Of course, this would turn the package into little more than a script to generate the *actual* packages.) However, as I'm always low on diskspace, I'm a bit reluctant to actually *try* this. *) [minor but still] it looks a bit unfair that there is only your signature under README.source, while large part of the text was written by me :). I agree with you that this was a very rude of the README.Debian Emacs mode to do this. I can understand updating the date; removing your name, not so much. Though, it also obviously shouldn't simply update the date next to your name. So I'm not really sure what it *should* do... If you can think what it should do, maybe we should open a bug against /usr/share/emacs/site-lisp/dpkg-dev-el/readme-debian.el to request the change? 2. In contemplating putting debian/copyright in DEP-5 format, I've realized that I'm not sure of the exact copyright/licensing status of anything in the debian/ directory, except: See debian/copyright from the old packages. Everything non-autogenerated under debian/ was stated to be GPL; I don't object changing that if needed. No, there's certainly no need to change that. (Of course, I would not object if they were to be put under the Expat license. :-) P.S. I apologize for returning the slow response time! I've now actually made an attempt at putting
Re: Fwd: RFS: gcc-4.5-doc-non-dfsg
Why not just do GCC docs in a way similar to GNU Make? Separately build docs from separate source package, and upload to non-free? (with regular package names) 2012/9/27 Guo Yixuan culu@gmail.com: Hi, On 02/15/2012 04:02 AM, Samuel Bronson wrote: On Tue, Feb 7, 2012 at 2:59 PM, Samuel Bronson naes...@gmail.com wrote: On Sun, Feb 5, 2012 at 7:17 AM, Nikita V. Youshchenko yo...@debian.org wrote: In good old days when I had time and motivation to maintain gcc-doc, I've used git repos to managed entire thing. I've just created externally-available mirror for those - please check http://yoush.homelinux.org:8079/git Could you please clone these repos, and reformat your work into this format? IMO this format greatly helps to keep things consistent. I can certainly try! Okay, I've cloned your gcc-doc repository and added my changes: git clone https://github.com/SamB/debian-gcc-doc (Or open it in your browser, or ...) I'm holding off on updating the 4.4 control files and the -defaults packages for the moment: I want to streamline the new X.Y process a bit more first. Maybe this could be moved to git.debian.org. Yes, that sounds like a good idea. Then I could add the Vcs-*: fields to debian/control. Of course, there will probably be a lot to update in README.source then... As for the rest, here are several more comments: *) I don't really understand the workflow of gcc-doc-non-dfgs converted to 3.0 (quilt) format. With old format, there was debian/patches, managed by dpatch, with part of patches managed by hands, and part managed by a perl script. Running the script altered debian/patches/* files, including series file. But isn't this unsafe for 3.0 (quilt) format since it will break metadata in .pc/ directory? Hmm. Perhaps the script should simply refuse to run whenever there is a .pc directory? (It seems that dpkg-source removes this after unapplying the patches.) In any case, most of this is changed very little; the script just gets to be a bit shorter since the patches no longer have to be shell scripts. Also, if you convert to 3.0 (quilt), why still mentioning dpatch in README.source? That was an accident. I've corrected this now. *) Looks like your command line for patch convertion script is much shorter that in was in previous times. How did you check which patches to apply and which not? Well, I grepped the GCC package's debian/patches for anything that changed .texi files, and looked through the debian/rules.patch to see which of those seemed to be applied for Debian builds on any architecture (in that alternate universe where GFDL_INVARIANT_FREE=no). Actually I've looked at updating gcc-doc during new year holidays, and stopped and postponed it exactly at this point. It was unclear what patches to apply, looked like some procedure/policy was needed, and I could not think your such a policy at that time. The idea was to check what patches are applied for each of in-debian architectures, and apply doc changes for all of those. This could likey be automated, e.g. by writing a makefile that will include debian/rules2 from gcc package, and then use vars set by that to print list of applied patches; some tricks with var-setting could do this for all archs. Hmm, not a terrible idea. I still think the *very* cleanest thing would probably be to build gcc-X.Y-doc-non-dfsg like this, though: [Oops, I forgot to finish this bit:] * Take the debian/ directory from gcc-X.Y + uncomment the documentation patches if necessary + replace debian/control with one that only builds the documentation packages + arrange for GFDL_INVARIANT_FREE=no to be set * Put a pristine upstream tarball in the root of the tree in place of the stripped one that gcc-X.Y uses. (Of course, this would turn the package into little more than a script to generate the *actual* packages.) However, as I'm always low on diskspace, I'm a bit reluctant to actually *try* this. *) [minor but still] it looks a bit unfair that there is only your signature under README.source, while large part of the text was written by me :). I agree with you that this was a very rude of the README.Debian Emacs mode to do this. I can understand updating the date; removing your name, not so much. Though, it also obviously shouldn't simply update the date next to your name. So I'm not really sure what it *should* do... If you can think what it should do, maybe we should open a bug against /usr/share/emacs/site-lisp/dpkg-dev-el/readme-debian.el to request the change? 2. In contemplating putting debian/copyright in DEP-5 format, I've realized that I'm not sure of the exact copyright/licensing status of anything in the debian/ directory, except: See debian/copyright from the old packages. Everything non-autogenerated under debian/ was stated to be GPL; I don't object changing that if needed. No, there's certainly no need to change that.
Re: Fwd: RFS: gcc-4.5-doc-non-dfsg
Hi, On 09/28/2012 01:05 AM, Игорь Пашев wrote: Why not just do GCC docs in a way similar to GNU Make? Separately build docs from separate source package, and upload to non-free? (with regular package names) It's in a similar way to GNU Make indeed. The only difference is more than one version of GCC are supported at the same time, so gcc-defaults and gcc-doc-defaults contain symlinks to the default versions. As packaging work in our git repos[1,2] are gerenerally completed, there're a few todos: 1. Remove gcc-doc-base from gcc-4.4-doc-non-dfsg (already in sid) and gcc-4.6-doc (only in debian/4.6 git branch) package. 2. Upload gcc-4.6-doc and gcc-4.7-doc to sid, at the same time upload new gcc-doc-defaults to point to 4.7. Or better, if gcc-defaults can generate gcc-doc/cpp-doc/... packages again, much work will be saved. [1] https://github.com/SamB/debian-gcc-doc [2] git://git.debian.org/users/yixuan-guest/gcc-doc.git Regards, Guo Yixuan 2012/9/27 Guo Yixuan culu@gmail.com: On 02/15/2012 04:02 AM, Samuel Bronson wrote: On Tue, Feb 7, 2012 at 2:59 PM, Samuel Bronson naes...@gmail.com wrote: On Sun, Feb 5, 2012 at 7:17 AM, Nikita V. Youshchenko yo...@debian.org wrote: In good old days when I had time and motivation to maintain gcc-doc, I've used git repos to managed entire thing. I've just created externally-available mirror for those - please check http://yoush.homelinux.org:8079/git Could you please clone these repos, and reformat your work into this format? IMO this format greatly helps to keep things consistent. I can certainly try! Okay, I've cloned your gcc-doc repository and added my changes: git clone https://github.com/SamB/debian-gcc-doc (Or open it in your browser, or ...) I'm holding off on updating the 4.4 control files and the -defaults packages for the moment: I want to streamline the new X.Y process a bit more first. Maybe this could be moved to git.debian.org. Yes, that sounds like a good idea. Then I could add the Vcs-*: fields to debian/control. Of course, there will probably be a lot to update in README.source then... As for the rest, here are several more comments: *) I don't really understand the workflow of gcc-doc-non-dfgs converted to 3.0 (quilt) format. With old format, there was debian/patches, managed by dpatch, with part of patches managed by hands, and part managed by a perl script. Running the script altered debian/patches/* files, including series file. But isn't this unsafe for 3.0 (quilt) format since it will break metadata in .pc/ directory? Hmm. Perhaps the script should simply refuse to run whenever there is a .pc directory? (It seems that dpkg-source removes this after unapplying the patches.) In any case, most of this is changed very little; the script just gets to be a bit shorter since the patches no longer have to be shell scripts. Also, if you convert to 3.0 (quilt), why still mentioning dpatch in README.source? That was an accident. I've corrected this now. *) Looks like your command line for patch convertion script is much shorter that in was in previous times. How did you check which patches to apply and which not? Well, I grepped the GCC package's debian/patches for anything that changed .texi files, and looked through the debian/rules.patch to see which of those seemed to be applied for Debian builds on any architecture (in that alternate universe where GFDL_INVARIANT_FREE=no). Actually I've looked at updating gcc-doc during new year holidays, and stopped and postponed it exactly at this point. It was unclear what patches to apply, looked like some procedure/policy was needed, and I could not think your such a policy at that time. The idea was to check what patches are applied for each of in-debian architectures, and apply doc changes for all of those. This could likey be automated, e.g. by writing a makefile that will include debian/rules2 from gcc package, and then use vars set by that to print list of applied patches; some tricks with var-setting could do this for all archs. Hmm, not a terrible idea. I still think the *very* cleanest thing would probably be to build gcc-X.Y-doc-non-dfsg like this, though: [Oops, I forgot to finish this bit:] * Take the debian/ directory from gcc-X.Y + uncomment the documentation patches if necessary + replace debian/control with one that only builds the documentation packages + arrange for GFDL_INVARIANT_FREE=no to be set * Put a pristine upstream tarball in the root of the tree in place of the stripped one that gcc-X.Y uses. (Of course, this would turn the package into little more than a script to generate the *actual* packages.) However, as I'm always low on diskspace, I'm a bit reluctant to actually *try* this. *) [minor but still] it looks a bit unfair that there is only your signature under README.source, while large part of the text was written by me :). I agree with you that this
Re: Fwd: RFS: gcc-4.5-doc-non-dfsg
Has the FSF been asked to switch to plain GFDL so that we can move the GCC docs to main? They did that for the autoconf documentation recently. -- 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 Archive: http://lists.debian.org/CAKTje6FbPaMCV8JQOS=BUsZs3eZF+fY08Z8b8sKwwWRo=pd...@mail.gmail.com
Re: Fwd: RFS: gcc-4.5-doc-non-dfsg
Samuel, I'm terribly sorry, but most likely I won't look into this in the near future. On weekdays, when done with current work and family stuff, I'm usually too tired to do anything useful. And it is already clear that at least next two weekends will also be occupied. It is a bad idea to postpone gcc-doc update for unpredictable time. I've already written that I don't own gcc-doc packages, and don't object upload by others. Nikita P.S. I should probably resign from Debian... but I don't feel ready for this. Once it was not easy to become a DD. And I still hope for some changes that will allow me to give more time to Debian. As for now, I hope my @debian.org account does not harm the project much... On Tue, Feb 7, 2012 at 2:59 PM, Samuel Bronson naes...@gmail.com wrote: On Sun, Feb 5, 2012 at 7:17 AM, Nikita V. Youshchenko yo...@debian.org wrote: In good old days when I had time and motivation to maintain gcc-doc, I've used git repos to managed entire thing. I've just created externally-available mirror for those - please check http://yoush.homelinux.org:8079/git Could you please clone these repos, and reformat your work into this format? IMO this format greatly helps to keep things consistent. I can certainly try! Okay, I've cloned your gcc-doc repository and added my changes: git clone https://github.com/SamB/debian-gcc-doc (Or open it in your browser, or ...) I'm holding off on updating the 4.4 control files and the -defaults packages for the moment: I want to streamline the new X.Y process a bit more first. Maybe this could be moved to git.debian.org. Yes, that sounds like a good idea. Then I could add the Vcs-*: fields to debian/control. Of course, there will probably be a lot to update in README.source then... As for the rest, here are several more comments: *) I don't really understand the workflow of gcc-doc-non-dfgs converted to 3.0 (quilt) format. With old format, there was debian/patches, managed by dpatch, with part of patches managed by hands, and part managed by a perl script. Running the script altered debian/patches/* files, including series file. But isn't this unsafe for 3.0 (quilt) format since it will break metadata in .pc/ directory? Hmm. Perhaps the script should simply refuse to run whenever there is a .pc directory? (It seems that dpkg-source removes this after unapplying the patches.) In any case, most of this is changed very little; the script just gets to be a bit shorter since the patches no longer have to be shell scripts. Also, if you convert to 3.0 (quilt), why still mentioning dpatch in README.source? That was an accident. I've corrected this now. *) Looks like your command line for patch convertion script is much shorter that in was in previous times. How did you check which patches to apply and which not? Well, I grepped the GCC package's debian/patches for anything that changed .texi files, and looked through the debian/rules.patch to see which of those seemed to be applied for Debian builds on any architecture (in that alternate universe where GFDL_INVARIANT_FREE=no). Actually I've looked at updating gcc-doc during new year holidays, and stopped and postponed it exactly at this point. It was unclear what patches to apply, looked like some procedure/policy was needed, and I could not think your such a policy at that time. The idea was to check what patches are applied for each of in-debian architectures, and apply doc changes for all of those. This could likey be automated, e.g. by writing a makefile that will include debian/rules2 from gcc package, and then use vars set by that to print list of applied patches; some tricks with var-setting could do this for all archs. Hmm, not a terrible idea. I still think the *very* cleanest thing would probably be to build gcc-X.Y-doc-non-dfsg like this, though: [Oops, I forgot to finish this bit:] * Take the debian/ directory from gcc-X.Y + uncomment the documentation patches if necessary + replace debian/control with one that only builds the documentation packages + arrange for GFDL_INVARIANT_FREE=no to be set * Put a pristine upstream tarball in the root of the tree in place of the stripped one that gcc-X.Y uses. (Of course, this would turn the package into little more than a script to generate the *actual* packages.) However, as I'm always low on diskspace, I'm a bit reluctant to actually *try* this. *) [minor but still] it looks a bit unfair that there is only your signature under README.source, while large part of the text was written by me :). I agree with you that this was a very rude of the README.Debian Emacs mode to do this. I can understand updating the date; removing your name, not so much. Though, it also obviously shouldn't simply update the date next to your name. So I'm not really sure what it *should* do... If you can
Re: Fwd: RFS: gcc-4.5-doc-non-dfsg
On Mon, Feb 20, 2012 at 1:45 AM, Nikita V. Youshchenko wrote: I should probably resign from Debian... but I don't feel ready for this. Once it was not easy to become a DD. And I still hope for some changes that will allow me to give more time to Debian. As for now, I hope my @debian.org account does not harm the project much... You may be interested in the emeritus status, which includes a lightweight procedure to return easily: http://www.debian.org/doc/manuals/developers-reference/developer-duties.html#s3.7 http://www.debian.org/doc/manuals/developers-reference/developer-duties.html#returning -- 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 Archive: http://lists.debian.org/CAKTje6E76qHGQDR_J=uq9wee-cid6ohygyhaknn0rmwm9ed...@mail.gmail.com
Re: Fwd: RFS: gcc-4.5-doc-non-dfsg
On Tue, Feb 7, 2012 at 2:59 PM, Samuel Bronson naes...@gmail.com wrote: On Sun, Feb 5, 2012 at 7:17 AM, Nikita V. Youshchenko yo...@debian.org wrote: In good old days when I had time and motivation to maintain gcc-doc, I've used git repos to managed entire thing. I've just created externally-available mirror for those - please check http://yoush.homelinux.org:8079/git Could you please clone these repos, and reformat your work into this format? IMO this format greatly helps to keep things consistent. I can certainly try! Okay, I've cloned your gcc-doc repository and added my changes: git clone https://github.com/SamB/debian-gcc-doc (Or open it in your browser, or ...) I'm holding off on updating the 4.4 control files and the -defaults packages for the moment: I want to streamline the new X.Y process a bit more first. Maybe this could be moved to git.debian.org. Yes, that sounds like a good idea. Then I could add the Vcs-*: fields to debian/control. Of course, there will probably be a lot to update in README.source then... As for the rest, here are several more comments: *) I don't really understand the workflow of gcc-doc-non-dfgs converted to 3.0 (quilt) format. With old format, there was debian/patches, managed by dpatch, with part of patches managed by hands, and part managed by a perl script. Running the script altered debian/patches/* files, including series file. But isn't this unsafe for 3.0 (quilt) format since it will break metadata in .pc/ directory? Hmm. Perhaps the script should simply refuse to run whenever there is a .pc directory? (It seems that dpkg-source removes this after unapplying the patches.) In any case, most of this is changed very little; the script just gets to be a bit shorter since the patches no longer have to be shell scripts. Also, if you convert to 3.0 (quilt), why still mentioning dpatch in README.source? That was an accident. I've corrected this now. *) Looks like your command line for patch convertion script is much shorter that in was in previous times. How did you check which patches to apply and which not? Well, I grepped the GCC package's debian/patches for anything that changed .texi files, and looked through the debian/rules.patch to see which of those seemed to be applied for Debian builds on any architecture (in that alternate universe where GFDL_INVARIANT_FREE=no). Actually I've looked at updating gcc-doc during new year holidays, and stopped and postponed it exactly at this point. It was unclear what patches to apply, looked like some procedure/policy was needed, and I could not think your such a policy at that time. The idea was to check what patches are applied for each of in-debian architectures, and apply doc changes for all of those. This could likey be automated, e.g. by writing a makefile that will include debian/rules2 from gcc package, and then use vars set by that to print list of applied patches; some tricks with var-setting could do this for all archs. Hmm, not a terrible idea. I still think the *very* cleanest thing would probably be to build gcc-X.Y-doc-non-dfsg like this, though: [Oops, I forgot to finish this bit:] * Take the debian/ directory from gcc-X.Y + uncomment the documentation patches if necessary + replace debian/control with one that only builds the documentation packages + arrange for GFDL_INVARIANT_FREE=no to be set * Put a pristine upstream tarball in the root of the tree in place of the stripped one that gcc-X.Y uses. (Of course, this would turn the package into little more than a script to generate the *actual* packages.) However, as I'm always low on diskspace, I'm a bit reluctant to actually *try* this. *) [minor but still] it looks a bit unfair that there is only your signature under README.source, while large part of the text was written by me :). I agree with you that this was a very rude of the README.Debian Emacs mode to do this. I can understand updating the date; removing your name, not so much. Though, it also obviously shouldn't simply update the date next to your name. So I'm not really sure what it *should* do... If you can think what it should do, maybe we should open a bug against /usr/share/emacs/site-lisp/dpkg-dev-el/readme-debian.el to request the change? 2. In contemplating putting debian/copyright in DEP-5 format, I've realized that I'm not sure of the exact copyright/licensing status of anything in the debian/ directory, except: See debian/copyright from the old packages. Everything non-autogenerated under debian/ was stated to be GPL; I don't object changing that if needed. No, there's certainly no need to change that. (Of course, I would not object if they were to be put under the Expat license. :-) P.S. I apologize for returning the slow response time! I've now actually made an attempt at putting debian/copyright in DEP5 form. There are a couple of holes in it still, but that's mostly
Re: Fwd: RFS: gcc-4.5-doc-non-dfsg
On Tue, Feb 14, 2012 at 03:02:43PM -0500, Samuel Bronson wrote: On Tue, Feb 7, 2012 at 2:59 PM, Samuel Bronson naes...@gmail.com wrote: On Sun, Feb 5, 2012 at 7:17 AM, Nikita V. Youshchenko yo...@debian.org wrote: In good old days when I had time and motivation to maintain gcc-doc, I've used git repos to managed entire thing. I'm holding off on updating the 4.4 control files and the -defaults packages for the moment: I want to streamline the new X.Y process a bit more first. Good, as there's 4.7 in experimental already. Not officially released and ICEs like hell, but it's meant to release soon... -- // If you believe in so-called intellectual property, please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. signature.asc Description: Digital signature
Re: Fwd: RFS: gcc-4.5-doc-non-dfsg
On Sun, Feb 5, 2012 at 7:17 AM, Nikita V. Youshchenko yo...@debian.org wrote: I will try to look sometime soon, but can't promise when. Hello Samuel The gcc-doc thing you've done looks great, however it is incomplete. Complete solution consists of gcc-doc-defaults package [contrib], and several gcc-X.Y.doc-non-dfsg [non-free], that all must match each other. There should be gcc-X.Y.doc-non-dfsg for each gcc-X.Y that is in debian main, and only one of those must provide gcc-doc-base package. Upload must be done for all components in sync (perhaps together with filing RM requests for obsolete source packages). Uploading only part of these will leave things in broken state. E.g. several source packages will provide gcc-doc-base binary package, or gcc-doc-defaults will provide packages with broken depends and/or symlinks. I see. In good old days when I had time and motivation to maintain gcc-doc, I've used git repos to managed entire thing. I've just created externally-available mirror for those - please check http://yoush.homelinux.org:8079/git Could you please clone these repos, and reformat your work into this format? IMO this format greatly helps to keep things consistent. I can certainly try! Maybe this could be moved to git.debian.org. As for the rest, here are several more comments: *) I don't really understand the workflow of gcc-doc-non-dfgs converted to 3.0 (quilt) format. With old format, there was debian/patches, managed by dpatch, with part of patches managed by hands, and part managed by a perl script. Running the script altered debian/patches/* files, including series file. But isn't this unsafe for 3.0 (quilt) format since it will break metadata in .pc/ directory? Hmm. Perhaps the script should simply refuse to run whenever there is a .pc directory? (It seems that dpkg-source removes this after unapplying the patches.) Also, if you convert to 3.0 (quilt), why still mentioning dpatch in README.source? That was an accident. *) Looks like your command line for patch convertion script is much shorter that in was in previous times. How did you check which patches to apply and which not? Well, I grepped the GCC package's debian/patches for anything that changed .texi files, and looked through the debian/rules.patch to see which of those seemed to be applied for Debian builds on any architecture (in that alternate universe where GFDL_INVARIANT_FREE=no). Actually I've looked at updating gcc-doc during new year holidays, and stopped and postponed it exactly at this point. It was unclear what patches to apply, looked like some procedure/policy was needed, and I could not think your such a policy at that time. The idea was to check what patches are applied for each of in-debian architectures, and apply doc changes for all of those. This could likey be automated, e.g. by writing a makefile that will include debian/rules2 from gcc package, and then use vars set by that to print list of applied patches; some tricks with var-setting could do this for all archs. Hmm, not a terrible idea. I still think the *very* cleanest thing would probably be to build gcc-X.Y-doc-non-dfsg like this, though: * Take the debian/ directory from gcc-X.Y, post-processing the *) [minor but still] it looks a bit unfair that there is only your signature under README.source, while large part of the text was written by me :). I agree with you that this was a very rude of the README.Debian Emacs mode to do this. I can understand updating the date; removing your name, not so much. Though, it also obviously shouldn't simply update the date next to your name. So I'm not really sure what it *should* do... If you can think what it should do, maybe we should open a bug against /usr/share/emacs/site-lisp/dpkg-dev-el/readme-debian.el to request the change? 2. In contemplating putting debian/copyright in DEP-5 format, I've realized that I'm not sure of the exact copyright/licensing status of anything in the debian/ directory, except: See debian/copyright from the old packages. Everything non-autogenerated under debian/ was stated to be GPL; I don't object changing that if needed. No, there's certainly no need to change that. (Of course, I would not object if they were to be put under the Expat license. :-) P.S. I apologize for returning the slow response time! -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cajyzjmfr77wjg6muubi6exovzpswqa7zpodl+60+uu_qsu9...@mail.gmail.com
Re: Fwd: RFS: gcc-4.5-doc-non-dfsg
I will try to look sometime soon, but can't promise when. Hello Samuel The gcc-doc thing you've done looks great, however it is incomplete. Complete solution consists of gcc-doc-defaults package [contrib], and several gcc-X.Y.doc-non-dfsg [non-free], that all must match each other. There should be gcc-X.Y.doc-non-dfsg for each gcc-X.Y that is in debian main, and only one of those must provide gcc-doc-base package. Upload must be done for all components in sync (perhaps together with filing RM requests for obsolete source packages). Uploading only part of these will leave things in broken state. E.g. several source packages will provide gcc-doc-base binary package, or gcc-doc-defaults will provide packages with broken depends and/or symlinks. In good old days when I had time and motivation to maintain gcc-doc, I've used git repos to managed entire thing. I've just created externally-available mirror for those - please check http://yoush.homelinux.org:8079/git Could you please clone these repos, and reformat your work into this format? IMO this format greatly helps to keep things consistent. Maybe this could be moved to git.debian.org. As for the rest, here are several more comments: *) I don't really understand the workflow of gcc-doc-non-dfgs converted to 3.0 (quilt) format. With old format, there was debian/patches, managed by dpatch, with part of patches managed by hands, and part managed by a perl script. Running the script altered debian/patches/* files, including series file. But isn't this unsafe for 3.0 (quilt) format since it will break metadata in .pc/ directory? Also, if you convert to 3.0 (quilt), why still mentioning dpatch in README.source? *) Looks like your command line for patch convertion script is much shorter that in was in previous times. How did you check which patches to apply and which not? Actually I've looked at updating gcc-doc during new year holidays, and stopped and postponed it exactly at this point. It was unclear what patches to apply, looked like some procedure/policy was needed, and I could not think your such a policy at that time. The idea was to check what patches are applied for each of in-debian architectures, and apply doc changes for all of those. This could likey be automated, e.g. by writing a makefile that will include debian/rules2 from gcc package, and then use vars set by that to print list of applied patches; some tricks with var-setting could do this for all archs. *) [minor but still] it looks a bit unfair that there is only your signature under README.source, while large part of the text was written by me :). 2. In contemplating putting debian/copyright in DEP-5 format, I've realized that I'm not sure of the exact copyright/licensing status of anything in the debian/ directory, except: See debian/copyright from the old packages. Everything non-autogenerated under debian/ was stated to be GPL; I don't object changing that if needed. Nikita signature.asc Description: This is a digitally signed message part.
Re: Fwd: RFS: gcc-4.5-doc-non-dfsg
On Sun, Jan 29, 2012 at 1:49 PM, Nikita V. Youshchenko yo...@debian.org wrote: On Wed, Jan 25, 2012 at 3:17 PM, Samuel Bronson naes...@gmail.com wrote: On Wed, Jan 25, 2012 at 2:10 PM, Matthias Klose d...@debian.org wrote: Samuel, thanks for doing this. However, I'm trying to get gcc-4.5 removed from unstable soonish, so I would like to see this for gcc-4.6 (and 4.7 as found in experimental). Could you do this? Nikita, could you sponsor the package? Sure, that was my real goal anyway; gcc-4.5 just looked lonely without its documentation, and it didn't seem like it would be much more work to do them both than to just do gcc-4.6. I wonder if I should interpret the silence from Nikita as meaning not now, I'm busy? Sorry for silence. I will try to look sometime soon, but can't promise when. Hoped to do so on this weekend, but weekend is already over and I did not. Real life sucks :( Yeah, that's more-or-less what I guessed. Btw, I don't claim ownership for these packages. I never did. I just once packaged gcc-doc because nobody did, and I did not want debian stable without gcc-doc. So absolutely don't object someone else uploading gcc-doc. Maintainer for gcc-doc has been always set to debian-...@lists.debian.org Yeah, I didn't think you did, and I doubt Matthias does either. On the other hand, as the last person to touch this stuff, it seemed plausible that you might find it easier to review than anyone else, and that you might have a particular interest in such packages getting uploaded. Just beware of ugly licensing issues. Ensure that gfdl.1 is forced in by the dependences, etc Yeah, I didn't touch that aspect of the control file at all, so I think I'm safe there. (And the description for gcc-doc-base makes this fairly clear, in any case.) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cajyzjmf0j1opptf6t8g2vopgazgpwzrmyt4kg+tpsu95w+x...@mail.gmail.com
Re: Fwd: RFS: gcc-4.5-doc-non-dfsg
On Wed, Jan 25, 2012 at 3:17 PM, Samuel Bronson naes...@gmail.com wrote: On Wed, Jan 25, 2012 at 2:10 PM, Matthias Klose d...@debian.org wrote: Samuel, thanks for doing this. However, I'm trying to get gcc-4.5 removed from unstable soonish, so I would like to see this for gcc-4.6 (and 4.7 as found in experimental). Could you do this? Nikita, could you sponsor the package? Sure, that was my real goal anyway; gcc-4.5 just looked lonely without its documentation, and it didn't seem like it would be much more work to do them both than to just do gcc-4.6. I wonder if I should interpret the silence from Nikita as meaning not now, I'm busy? Sorry for silence. I will try to look sometime soon, but can't promise when. Hoped to do so on this weekend, but weekend is already over and I did not. Real life sucks :( Btw, I don't claim ownership for these packages. I never did. I just once packaged gcc-doc because nobody did, and I did not want debian stable without gcc-doc. So absolutely don't object someone else uploading gcc-doc. Maintainer for gcc-doc has been always set to debian-...@lists.debian.org Just beware of ugly licensing issues. Ensure that gfdl.1 is forced in by the dependences, etc Nikita signature.asc Description: This is a digitally signed message part.
Re: Fwd: RFS: gcc-4.5-doc-non-dfsg
On Wed, Jan 25, 2012 at 3:17 PM, Samuel Bronson naes...@gmail.com wrote: On Wed, Jan 25, 2012 at 2:10 PM, Matthias Klose d...@debian.org wrote: Samuel, thanks for doing this. However, I'm trying to get gcc-4.5 removed from unstable soonish, so I would like to see this for gcc-4.6 (and 4.7 as found in experimental). Could you do this? Nikita, could you sponsor the package? Sure, that was my real goal anyway; gcc-4.5 just looked lonely without its documentation, and it didn't seem like it would be much more work to do them both than to just do gcc-4.6. I wonder if I should interpret the silence from Nikita as meaning not now, I'm busy? I had been waiting for something from Nikita before uploading anything for 4.6, preferably including some critical feedback, but in the interest of not having everyone wait for everyone else or anything like that, I've now uploaded the following: * Package name: gcc-4.6-doc-non-dfsg Version : 4.6.2-1~naesten1 Section : doc It builds those binary packages: cpp-4.6-doc - documentation for the GNU C preprocessor (cpp) gcc-4.6-doc - documentation for the GNU compilers (gcc, gobjc, g++) gcc-doc-base - several GNU manual pages gcj-4.6-doc - documentation for the GNU Java tools (gcj, gij) gfortran-4.6-doc - documentation for the GNU Fortran Compiler (gfortran) gnat-4.6-doc - documentation for the GNU Ada 95 Compiler (gnat) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/gcc-4.6-doc-non-dfsg Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/non-free/g/gcc-4.6-doc-non-dfsg/gcc-4.6-doc-non-dfsg_4.6.2-1~naesten1.dsc I've given it a strange version number again because: 1. I suspect I should probably simplify debian/changelog a lot 2. In contemplating putting debian/copyright in DEP-5 format, I've realized that I'm not sure of the exact copyright/licensing status of anything in the debian/ directory, except: (a) the files that are just lists of other files, which I don't believe are copyrightable (b) the Python script I wrote, because there's a clear notice at the top saying what the status is ;-) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cajyzjmftsmw7kjo6ltg9obwf1epoqzy_c3nmrjqg5qxjuw3...@mail.gmail.com
Fwd: RFS: gcc-4.5-doc-non-dfsg
Dear GCC Maintainers, Perhaps I should have CC'd you in the first place, but here's a copy now: -- Forwarded message -- From: Samuel Bronson naes...@gmail.com Date: Sat, Jan 21, 2012 at 12:38 AM Subject: RFS: gcc-4.5-doc-non-dfsg To: debian-mentors@lists.debian.org Dear mentors, I am looking for a sponsor for my package gcc-4.5-doc-non-dfsg. It provides the manuals for GCC 4.5, including its many compilers, and paves the way for gcc-4.6-doc-non-dfsg. (Figuring out what this package will do is left as an excercise for the reader.) * Package name : gcc-4.5-doc-non-dfsg Version : 4.5.3-1~naesten4 Upstream Author : Free Software Foundation * URL : http://gcc.gnu.org/ * License : GFDL with invariant sections Section : non-free/doc It builds those binary packages: cpp-4.5-doc - documentation for the GNU C preprocessor (cpp) gcc-4.5-doc - documentation for the GNU compilers (gcc, gobjc, g++) gcc-doc-base - several GNU manual pages gcj-4.5-doc - documentation for the GNU Java tools (gcj, gij) gfortran-4.5-doc - documentation for the GNU Fortran Compiler (gfortran) gnat-4.5-doc - documentation for the GNU Ada 95 Compiler (gnat) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/gcc-4.5-doc-non-dfsg Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/non-free/g/gcc-4.5-doc-non-dfsg/gcc-4.5-doc-non-dfsg_4.5.3-1.dsc It would be nice if someone could upload the package or, failing that, tell me what I must still change before it can be uploaded. Thanks, Samuel Bronson -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cajyzjmenunsxw9d6q8b1pz7z673osx5wy+g-jup0wvlmsmm...@mail.gmail.com
Re: Fwd: RFS: gcc-4.5-doc-non-dfsg
Samuel, thanks for doing this. However, I'm trying to get gcc-4.5 removed from unstable soonish, so I would like to see this for gcc-4.6 (and 4.7 as found in experimental). Could you do this? Nikita, could you sponsor the package? Matthias On 25.01.2012 19:05, Samuel Bronson wrote: Dear GCC Maintainers, Perhaps I should have CC'd you in the first place, but here's a copy now: -- Forwarded message -- From: Samuel Bronsonnaes...@gmail.com Date: Sat, Jan 21, 2012 at 12:38 AM Subject: RFS: gcc-4.5-doc-non-dfsg To: debian-mentors@lists.debian.org Dear mentors, I am looking for a sponsor for my package gcc-4.5-doc-non-dfsg. It provides the manuals for GCC 4.5, including its many compilers, and paves the way for gcc-4.6-doc-non-dfsg. (Figuring out what this package will do is left as an excercise for the reader.) * Package name: gcc-4.5-doc-non-dfsg Version : 4.5.3-1~naesten4 Upstream Author : Free Software Foundation * URL : http://gcc.gnu.org/ * License : GFDL with invariant sections Section : non-free/doc It builds those binary packages: cpp-4.5-doc - documentation for the GNU C preprocessor (cpp) gcc-4.5-doc - documentation for the GNU compilers (gcc, gobjc, g++) gcc-doc-base - several GNU manual pages gcj-4.5-doc - documentation for the GNU Java tools (gcj, gij) gfortran-4.5-doc - documentation for the GNU Fortran Compiler (gfortran) gnat-4.5-doc - documentation for the GNU Ada 95 Compiler (gnat) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/gcc-4.5-doc-non-dfsg Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/non-free/g/gcc-4.5-doc-non-dfsg/gcc-4.5-doc-non-dfsg_4.5.3-1.dsc It would be nice if someone could upload the package or, failing that, tell me what I must still change before it can be uploaded. Thanks, Samuel Bronson -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f2053a5.5020...@debian.org
Re: Fwd: RFS: gcc-4.5-doc-non-dfsg
On Wed, Jan 25, 2012 at 2:10 PM, Matthias Klose d...@debian.org wrote: Samuel, thanks for doing this. However, I'm trying to get gcc-4.5 removed from unstable soonish, so I would like to see this for gcc-4.6 (and 4.7 as found in experimental). Could you do this? Nikita, could you sponsor the package? Sure, that was my real goal anyway; gcc-4.5 just looked lonely without its documentation, and it didn't seem like it would be much more work to do them both than to just do gcc-4.6. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cajyzjmde7omjo5+-rgdvj6tgec1vvajkrkucn-ftzn5gej8...@mail.gmail.com
