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 because of upstream problems, and the holes have been there all along anyway. -- 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/CAJYzjmf45nMJ5=gMpA2JFGgXYb0iyD4CK9A7-z=e+vqj6eb...@mail.gmail.com
