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 <naesten@gmail.com> wrote: > > On Sun, Feb 5, 2012 at 7:17 AM, Nikita V. Youshchenko <yoush@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 > because of upstream problems, and the holes have been there all along > anyway.
Attachment:
signature.asc
Description: This is a digitally signed message part.