Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian GCC (http://www.linux-archive.org/debian-gcc/)
-   -   Fwd: RFS: gcc-4.5-doc-non-dfsg (http://www.linux-archive.org/debian-gcc/625021-fwd-rfs-gcc-4-5-doc-non-dfsg.html)

Samuel Bronson 01-25-2012 05:05 PM

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 <naesten@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-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAJYzjmenUnsxw9D6Q8b1Pz7Z673Osx5wy+G-jUP0WVLMSMMwZg@mail.gmail.com">http://lists.debian.org/CAJYzjmenUnsxw9D6Q8b1Pz7Z673Osx5wy+G-jUP0WVLMSMMwZg@mail.gmail.com

Matthias Klose 01-25-2012 06:10 PM

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 Bronson<naesten@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-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F2053A5.5020301@debian.org">http://lists.debian.org/4F2053A5.5020301@debian.org

Samuel Bronson 01-25-2012 07:17 PM

Fwd: RFS: gcc-4.5-doc-non-dfsg
 
On Wed, Jan 25, 2012 at 2:10 PM, Matthias Klose <doko@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-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAJYzjmde7oMJo5+-RGDVJ6tgec1vvAJKRKUCN-ftzN5geJ8h8Q@mail.gmail.com">http://lists.debian.org/CAJYzjmde7oMJo5+-RGDVJ6tgec1vvAJKRKUCN-ftzN5geJ8h8Q@mail.gmail.com

Samuel Bronson 01-28-2012 10:47 PM

Fwd: RFS: gcc-4.5-doc-non-dfsg
 
On Wed, Jan 25, 2012 at 3:17 PM, Samuel Bronson <naesten@gmail.com> wrote:
> On Wed, Jan 25, 2012 at 2:10 PM, Matthias Klose <doko@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-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAJYzjmftSmw7Kjo6LTG9ObWf1EPOqzY_c3NMRJQg5qXJuW3rf w@mail.gmail.com">http://lists.debian.org/CAJYzjmftSmw7Kjo6LTG9ObWf1EPOqzY_c3NMRJQg5qXJuW3rf w@mail.gmail.com

"Nikita V. Youshchenko" 01-29-2012 05:49 PM

Fwd: RFS: gcc-4.5-doc-non-dfsg
 
> On Wed, Jan 25, 2012 at 3:17 PM, Samuel Bronson <naesten@gmail.com>
wrote:
> > On Wed, Jan 25, 2012 at 2:10 PM, Matthias Klose <doko@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-gcc@lists.debian.org

Just beware of ugly licensing issues. Ensure that gfdl.1 is forced in by
the dependences, etc

Nikita

Samuel Bronson 01-30-2012 07:47 PM

Fwd: RFS: gcc-4.5-doc-non-dfsg
 
On Sun, Jan 29, 2012 at 1:49 PM, Nikita V. Youshchenko <yoush@debian.org> wrote:
>> On Wed, Jan 25, 2012 at 3:17 PM, Samuel Bronson <naesten@gmail.com>
> wrote:
>> > On Wed, Jan 25, 2012 at 2:10 PM, Matthias Klose <doko@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-gcc@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-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAJYzjmf0j1OppTf6t8g2vopGAzGPWZrMYt4kg+TPSu95W+Xka A@mail.gmail.com">http://lists.debian.org/CAJYzjmf0j1OppTf6t8g2vopGAzGPWZrMYt4kg+TPSu95W+Xka A@mail.gmail.com

"Nikita V. Youshchenko" 02-05-2012 11:17 AM

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

Samuel Bronson 02-07-2012 06:59 PM

Fwd: RFS: gcc-4.5-doc-non-dfsg
 
On Sun, Feb 5, 2012 at 7:17 AM, Nikita V. Youshchenko <yoush@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-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAJYzjmfr77wJG6MUuBi6exOVZpSWqA7ZpODL+60+Uu_qsU91-g@mail.gmail.com">http://lists.debian.org/CAJYzjmfr77wJG6MUuBi6exOVZpSWqA7ZpODL+60+Uu_qsU91-g@mail.gmail.com

Samuel Bronson 02-14-2012 07:02 PM

Fwd: RFS: gcc-4.5-doc-non-dfsg
 
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.


--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAJYzjmf45nMJ5=gMpA2JFGgXYb0iyD4CK9A7-z=E+vqj6ebUrQ@mail.gmail.com">http://lists.debian.org/CAJYzjmf45nMJ5=gMpA2JFGgXYb0iyD4CK9A7-z=E+vqj6ebUrQ@mail.gmail.com

"Nikita V. Youshchenko" 02-19-2012 04:45 PM

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 <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.


All times are GMT. The time now is 04:52 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.