FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian GCC

 
 
LinkBack Thread Tools
 
Old 09-27-2012, 04:18 PM
Guo Yixuan
 
Default 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 <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.
>

How's it going now? Samuel has done much work in packaging
gcc-4.[67]-doc, while there doesn't appear to be any real uploads.

I've updated debian/4.7 branch in my personal git repo at Alioth, you
can check it out:

git clone git://git.debian.org/users/yixuan-guest/gcc-doc.git

Regards,

Guo Yixuan


--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 50647C42.6050709@gmail.com">http://lists.debian.org/50647C42.6050709@gmail.com
 
Old 09-27-2012, 05:05 PM
Игорь Пашев
 
Default 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.gyx@gmail.com>:
> Hi,
>
> On 02/15/2012 04:02 AM, Samuel Bronson wrote:
>> 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.
>>
>
> How's it going now? Samuel has done much work in packaging
> gcc-4.[67]-doc, while there doesn't appear to be any real uploads.
>
> I've updated debian/4.7 branch in my personal git repo at Alioth, you
> can check it out:
>
> git clone git://git.debian.org/users/yixuan-guest/gcc-doc.git
>
> Regards,
>
> Guo Yixuan
>
>
> --
> To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: http://lists.debian.org/50647C42.6050709@gmail.com
>


--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/CALL-Q8yR3mViwZTaC7QhBAP0=K8ps8aO39hCpFsKG7buxKfEEg@mai l.gmail.com
 
Old 09-28-2012, 01:46 AM
Guo Yixuan
 
Default 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.gyx@gmail.com>:
>> On 02/15/2012 04:02 AM, Samuel Bronson wrote:
>>> 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.
>>>
>>
>> How's it going now? Samuel has done much work in packaging
>> gcc-4.[67]-doc, while there doesn't appear to be any real uploads.
>>
>> I've updated debian/4.7 branch in my personal git repo at Alioth, you
>> can check it out:
>>
>> git clone git://git.debian.org/users/yixuan-guest/gcc-doc.git
>>
>> Regards,
>>
>> Guo Yixuan


--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 5065015C.80203@gmail.com">http://lists.debian.org/5065015C.80203@gmail.com
 
Old 09-28-2012, 01:53 AM
Paul Wise
 
Default 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-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/CAKTje6FbPaMCV8JQOS=BUsZs3eZF+fY08Z8b8sKwwWRo=PDJ1 Q@mail.gmail.com
 
Old 09-28-2012, 01:02 PM
Matthias Klose
 
Default 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-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 50659FCB.6020107@debian.org">http://lists.debian.org/50659FCB.6020107@debian.org
 

Thread Tools




All times are GMT. The time now is 07:33 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org