This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC maintainer volunteer?


On 2/27/2013 11:23 PM, JonY wrote:
On 2/27/2013 21:59, Corinna Vinschen wrote:
On Feb 27 21:29, JonY wrote:
On 2/27/2013 21:10, Corinna Vinschen wrote

Just upload the test release to the release area and write a TEST mail to cygwin-announce. Or is there anything special you'd like to do?



I'm worried that I might break gcc installs if I overlooked something obvious.

The upload will be overwriting the .hint files, java and libffi are
empty packages (I could not get java to build yet).

I'm not concerend about java (dum di dum), but why is libffi missing?



libffi only gets built when Java is enabled.


I can't figure out
how to pack the debuginfo package, it is always empty.

Yaakov might be able to help here.



Hi Yaakov, I have gcc4_debuginfo_CONTENTS="usr/lib/debug/" in the cygport file, any ideas?

Will you be able to rollback my uploads in case something does go wrong?

In theory, yes. If you leave the dependencies in place for the "curr" release, then the test release shouldn't interfere and testers will have to care for the stuff themselves. Let's assume for a start, that downmloaders of a gcc test package know what they are doing.


Now this brings up a good question. libgnat4.5 became libgnat4.7 in 4.7.2, likewise for libobjc2 to libobjc4. So you are saying that I should leave the runtime depends for 4.5.x?

yes, otherwise you break it for current Put the test depends in the test announcement, so who want to test will add by hand.

http://cygwin.com/ml/cygwin-apps/2012-11/msg00067.html


Another way to distinguish the new gcc from the current on would be
perhaps to create a "gcc472" package set, distinct from the other gcc
packages.  It could install itself into /usr/local, just for the test
period.
Yeah, I know, I know, no official package should install into
/usr/local.  Maybe /opt would be fine for once, too.


That might be a saner approach to testing. Do I need to use postinstall to add it to PATH? If so, how do I do that?

looks at: /etc/profile.d/lapack0.csh /etc/profile.d/lapack0.sh



Marco


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]