gcc.gnu.org/bugzilla is currently running Bugzilla 2.20, which reached end-of-life on November 29, 2008, see http://www.bugzilla.org/news/#release32. This means that this installation is vulnerable to all security bugs found in the last 15 months. This installation should be upgraded to Bugzilla 3.4.5, our most stable release, see http://www.bugzilla.org/download/#stable.
I cannot find the emails saying why this has not been done yet but I remember the issue comes down to custom fields which need to be moved correctly over to the new version of bugzilla.
(In reply to comment #1) > I cannot find the emails saying why this has not been done yet but I remember > the issue comes down to custom fields which need to be moved correctly over to > the new version of bugzilla. Well, from what I can see, this is trivial enough to port. You only have one drop-down field (Reported against) and five free text fields (Known to work, Known to fail, Host, Target, Build). Both types exist in Bugzilla 3.4. I can certainly help if you need some help with the upgrade (I am one of the main developers of Bugzilla).
Subject: Re: Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5 I think the call for volunteers at http://gcc.gnu.org/ml/gcc/2008-03/msg00276.html still applies.
Hey Daniel, still need some help? :)
Subject: Re: Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5 There may be a few local code changes (Daniel mentioned email handling) to carry over (it's quite possible newer versions don't need code changes for whatever the local changes do, but have some better way to achieve the desired effect), as well as converting the database schema. I expect we can get you a copy of the database if you'd like to help with the conversion. As for the code changes, our Bugzilla code is all in CVS http://gcc.gnu.org/cvs.html so you can check it out and see exactly what local modifications have been made.
Hard to see all the changes made to 2.20 via CVS. Is there a patch somewhere done against vanilla Bugzilla showing all the customizations which have been done?
Created attachment 19830 [details] Local Bugzilla changes Here's a diff generated with "cvs -z9 diff -uN -rBUGZILLA_2_20 -rHEAD". There are some oddities - cases where there appear to be GCC-related things both before and after the diff - that could relate to CVS peculiarities of some kind, or to BUGZILLA_2_20 not quite being a tag for unmodified upstream. So checking out the sources and generating a diff from a vanilla 2.20 release tarball may be safer to show exactly what's changed.
Created attachment 19831 [details] Diff from tarball Here is a larger, probably more accurate diff generated using a release tarball.
Subject: Re: Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5 I think we agreed some time ago to remove the gccbug script - if we do that then we shouldn't need to bring over anything related to processing incoming GNATS-formatted email submissions (just make the gcc-gnats address bounce with a pointer to Bugzilla). So that may reduce the extent of local code needing porting to a new Bugzilla version.
Could someone having access to the Bugzilla server install the PatchReader Perl module? It's way easier to read patches this way.
(In reply to comment #10) > Could someone having access to the Bugzilla server install the PatchReader Perl > module? It's way easier to read patches this way. I think it is already installed, just the attachments need to be marked as patches which I just did.
The changes in the core code do not look too terrific and should be easy to port (some of which are now useless in the 3.4 code). I guess most changes in contrib/bug_email.pl can go away now that we have email_in.pl, but I have no idea what the Python and other Perl scripts in contrib/ are doing. Note that many of the existing scripts in contrib/ are now gone.
Subject: Re: Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5 The main email-related functionality for GCC is: all bugs in the "gcc" product automatically get CC:ed to gcc-bugs@gcc.gnu.org (maybe other lists depending on the component, or for other products). Email replies get body and attachments automatically entered in the relevant bug, with an account created for the sender if they didn't already have one. If you preserve that, most of the important email handling functionality is there. There is I think some mechanism for other bug manipulations by email, but I don't think many people (if any at all) use it. contrib/regress-submit.pl might once have been used for automatic bug submissions by regression testers, but there hasn't been such submission for years, so I think it can be ignored. User accounts with email addresses @gcc.gnu.org automatically get some extra privileges. I don't know where this is configured. As noted, we can reasonably kill gccbug and so ignore anything related to GNATS. As discussed, there are various new fields added to GCC Bugzilla - while some of the standard Bugzilla fields are removed as inapplicable (build / host / target is the proper way of describing the platform where a GCC bug is observed). There are also some changes to the set of states a bug can be in. Hopefully the conclusion will be that we don't need GCC-specific scripts in contrib/ but can preserve the various GCC-specific logic (possibly implemented in a better way using newer 3.4 infrastructure).
(In reply to comment #13) > Email replies get > body and attachments automatically entered in the relevant bug, with an > account created for the sender if they didn't already have one. If you > preserve that, most of the important email handling functionality is > there. Is there any check that the email sender is really the one he pretends to be? It's easy to hack the From: header of emails from the email client and impersonate another user (e.g. to gain privileges).
Subject: Re: Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5 On Wed, 10 Feb 2010, LpSolit at netscape dot net wrote: > ------- Comment #14 from LpSolit at netscape dot net 2010-02-10 00:29 ------- > (In reply to comment #13) > > Email replies get > > body and attachments automatically entered in the relevant bug, with an > > account created for the sender if they didn't already have one. If you > > preserve that, most of the important email handling functionality is > > there. > > Is there any check that the email sender is really the one he pretends to be? > It's easy to hack the From: header of emails from the email client and > impersonate another user (e.g. to gain privileges). No such check for adding comments from email replies, but adding a comment doesn't require privileges (and the password for an autocreated account is of course sent to the email address for that account, so an impersonator won't get the password). I don't know about the functionality for doing anything else by email.
(In reply to comment #15) > No such check for adding comments from email replies, but adding a comment > doesn't require privileges (and the password for an autocreated account is > of course sent to the email address for that account, so an impersonator > won't get the password). I don't know about the functionality for doing > anything else by email. Newer Bugzilla releases no longer send you an email with your password in it. They send you an email with a URL in it which brings you to a page where you enter your name and password (this avoids creating fake accounts with invalid or undesired email addresses). About what you can do by email, newer releases let you edit almost all aspects of bugs, including the CC list, assignee, severity, priority, bug status and resolution, etc... etc.... You can even attach files if you want to (in Bugzilla 3.6). :)
It would be really great if someone would update the sourceware.org bugzilla at the same time, so we could run a single version on the machine.
(In reply to comment #17) > It would be really great if someone would update the sourceware.org > bugzilla at the same time, so we could run a single version on the machine. Wow, http://sourceware.org/bugzilla/ runs Bugzilla 2.17.5, a development snapshot which was released in November 2003 and which got replaced the week after by 2.17.6 because it had a security hole. You guys like to live dangerously. :)
Subject: Re: Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5 It has the security patch ;) None of this would have been a big deal if it hadn't taken bugzilla 10 years to decide on custom fields ;) THe main changes in both bugzilla is to remove the opsys/platform fields and add our triplet fields. On Thu, Feb 11, 2010 at 3:23 PM, LpSolit at netscape dot net <gcc-bugzilla@gcc.gnu.org> wrote: > > > ------- Comment #18 from LpSolit at netscape dot net 2010-02-11 20:23 ------- > (In reply to comment #17) >> It would be really great if someone would update the sourceware.org >> bugzilla at the same time, so we could run a single version on the machine. > > Wow, http://sourceware.org/bugzilla/ runs Bugzilla 2.17.5, a development > snapshot which was released in November 2003 and which got replaced the week > after by 2.17.6 because it had a security hole. You guys like to live > dangerously. :) > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011 > > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is. >
(In reply to comment #19) > None of this would have been a big deal if it hadn't taken bugzilla 10 > years to decide on custom fields ;) No comment! :-D > THe main changes in both bugzilla is to remove the opsys/platform > fields and add our triplet fields. Porting triplet fields should be trivial to do. About the OS/platform fields, we only need to hide it from the UI and let Bug.pm ignore them. I did it once already, for another Bugzilla, and it's really easy. Daniel, how do you plan to do the upgrade? I'm willing to help, but we need a test installation and all.
About merging both Bugzilla installations into a single one, the problem is about bug IDs. They would conflict.
Yes, I think we should not merge the databases. All I meant was that we should have a single version of the code running. And, when upgrading, upgrade both instances at the same time.
(In reply to comment #22) > All I meant was that we should have a single version of the code running. That's doable, see http://www.bugzilla.org/docs/tip/en/html/multiple-bz-dbs.html. Can someone confirm this bug? :)
We are very close from releasing Bugzilla 3.6: https://bugzilla.mozilla.org/show_bug.cgi?id=554523 The plan is to release it next week. So you may as well upgrade to 3.6 directly. Note that I'm on vacation this week and next week. If you need help for the upgrade, now is a good time! :)
Subject: Re: Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.6 Note: I have no urge or time to upgrade gcc's bugzilla anymore. If ya'll want to work on it, i'm happy to give you all the info i have and get you shell access to gcc.gnu.org + the current bugzilla code + it's mysql so you can do it. On Tue, Mar 30, 2010 at 5:54 AM, LpSolit at netscape dot net <gcc-bugzilla@gcc.gnu.org> wrote: > > > ------- Comment #24 from LpSolit at netscape dot net 2010-03-30 09:54 ------- > We are very close from releasing Bugzilla 3.6: > > https://bugzilla.mozilla.org/show_bug.cgi?id=554523 > > The plan is to release it next week. So you may as well upgrade to 3.6 > directly. Note that I'm on vacation this week and next week. If you need help > for the upgrade, now is a good time! :) > > > -- > > LpSolit at netscape dot net changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Summary|Upgrade gcc.gnu.org/bugzilla|Upgrade gcc.gnu.org/bugzilla > |to Bugzilla 3.4.5 |to Bugzilla 3.6 > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011 > > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is. >
(In reply to comment #25) > Subject: Re: Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.6 > > Note: I have no urge or time to upgrade gcc's bugzilla anymore. > If ya'll want to work on it, i'm happy to give you all the info i have > and get you shell access to gcc.gnu.org + the current bugzilla code + > it's mysql so you can do it. I'll volunteer to do it.
For those who are interested, I'm on vacation till mid-August, meaning that I have some free time to help upgrading GCC Bugzilla to 3.6.1. As it's not acceptable to play with a production installation, we would need a test installation on which we can apply patches and test them (we could file bugs and attach patches to the test installation directly, so that we can test the installation for real). Once everybody is happy with how things work, and thinks everything which is needed has been ported to the new installation, we can make a monolithic patch with all changes in it, and attach it to this bug for the record (as the test installation will probably go away once the upgrade process is complete). The only efficient way I know to customize a Bugzilla installation is to use e.g. CVS or bzr to apply patches, and let the test installation be upgraded from there, so that we can easily generate patches and back them out. Else it's going to be a mess pretty quickly. Is this doable by the GCC team? Else I would have to do it locally, and apply patches manually to the test installation, meaning that I would be the only one able to generate patches on top of other patches. What do you think?
Subject: Re: Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.6 On Thu, Jul 15, 2010 at 7:04 PM, LpSolit at netscape dot net <gcc-bugzilla@gcc.gnu.org> wrote: > > > ------- Comment #27 from LpSolit at netscape dot net 2010-07-15 23:04 ------- > For those who are interested, I'm on vacation till mid-August, meaning that I > have some free time to help upgrading GCC Bugzilla to 3.6.1. > > As it's not acceptable to play with a production installation, we would need a > test installation on which we can apply patches and test them (we could file > bugs and attach patches to the test installation directly, so that we can test > the installation for real). That's fine. I used to do this on my local machine (home.dberlin.org). You could also setup a test instance on sourceware.org (which is what gcc.gnu.org is really running on) > Once everybody is happy with how things work, and > thinks everything which is needed has been ported to the new installation, we > can make a monolithic patch with all changes in it, and attach it to this bug > for the record (as the test installation will probably go away once the upgrade > process is complete). > Sounds right > The only efficient way I know to customize a Bugzilla installation is to use > e.g. CVS or bzr to apply patches, and let the test installation be upgraded > from there, so that we can easily generate patches and back them out. Else it's > going to be a mess pretty quickly. Is this doable by the GCC team? Currently bugzilla is under cvs, but it's a bit of a mess (my fault, of course ;P). The rest of GCC uses SVN, the www stuff has never been moved over because there are a bunch of automated checkin scripts/etc that nobody has had the urge to port. > Else I would > have to do it locally, and apply patches manually to the test installation, > meaning that I would be the only one able to generate patches on top of other > patches. > > What do you think? I think you should probably set yourself up an account on sourceware. Fill out this form: http://sourceware.org/cgi-bin/pdw/ps_form.cgi and list me as your referrer. The bugzilla stuff for GCC is in /www/gcc/bugzilla I honestly do not remember the qmail related magic that makes the incoming aliases go to the right perl scripts. However, overseers@ has the folks who set this up and understand how qmail works. --Dan
(In reply to comment #28) > I think you should probably set yourself up an account on sourceware. > Fill out this form: http://sourceware.org/cgi-bin/pdw/ps_form.cgi and > list me as your referrer. Done! I selected "sourceware" as project. I hope that was the correct one.
Daniel, did you get the email I sent you on August 19? I need some help to start working on this project. Just in case someone else can help too, here is the content of the email I sent to Daniel: The welcome email I got contains this command, which doesn't work: $ cvs -z9 -d :ext:lpsolit@sourceware.org:/cvs/sourceware co sourceware cvs server: cannot find module `sourceware' - ignored cvs [checkout aborted]: cannot expand modules Same for this broken link: http://sourceware.org/cgi-bin/cvsweb.cgi/sourceware?cvsroot=sourceware I saw that the Bugzilla code is located at /cvs/gcc/wwwdocs/bugzilla/. How am I supposed to access it, then? Have I been added to the wrong group? I also tried: $ cvs -z9 -d :ext:lpsolit@sourceware.org:/cvs/gcc/wwwdocs co bugzilla Cannot access /cvs/gcc/wwwdocs/CVSROOT No such file or directory Is the welcome message obsolete or am I doing something wrong?
(In reply to comment #30) > $ cvs -z9 -d :ext:lpsolit@sourceware.org:/cvs/sourceware co sourceware > cvs server: cannot find module `sourceware' - ignored > cvs [checkout aborted]: cannot expand modules Use the module name "infra" instead: cvs -z9 -d :ext:lpsolit@sourceware.org:/cvs/sourceware co infra I haven't looked at the welcome instructions in a long time, but they are auto-generated, so maybe they are misleading in this case. > I saw that the Bugzilla code is located at /cvs/gcc/wwwdocs/bugzilla/. > How am I supposed to access it, then? Have I been added to the wrong > group? I also tried: > > $ cvs -z9 -d :ext:lpsolit@sourceware.org:/cvs/gcc/wwwdocs co bugzilla Check out the wwwdocs module from gcc's cvs repository: cvs -z9 -d :ext:lpsolit@sourceware.org:/cvs/gcc co wwwdocs There are actually 2 bugzilla instances running on sourceware. I am not certain that the second one is in cvs at all. Also, of course, the databases are not in cvs, you will have to get them by some other means.
I believe the following should work: cvs -z9 -d :ext:lpsolit@gcc.gnu.org:/cvs/gcc co wwwdocs bugzilla is a subdirectory there, not a module. sourceware.org and gcc.gnu.org should both work, but since is GCC Bugzilla and I am using the gcc.gnu.org server name, I figured I'd provide those. :-)
I guess you meant to be CC'ed?
(In reply to comment #33) > I guess you meant to be CC'ed? > Yes. The work I started was a Perl script to convert a 2.20+ database to the latest version. The last question I had of Daniel was could we get a test bed so others could try out the new bugzilla setup--looks like that is underway. There was another problem I had that I don't remember at the moment, but that was where I left it.
(In reply to comment #34) > The last question I had of Daniel was could we get a test bed > so others could try out the new bugzilla setup--looks like that is underway. Yes, we will have a test installation, as discussed in comment 27. But I first need shell access, which is why I'm blocked right now. Waiting for Daniel or someone else for help here.
You're all set with plain shell access now. Connect to irc.freenode.net #overseers for any further needs.
Subject: Re: Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.6 You should have shell access, do you not? On Tue, Sep 7, 2010 at 2:11 PM, LpSolit at netscape dot net <gcc-bugzilla@gcc.gnu.org> wrote: > > > ------- Comment #35 from LpSolit at netscape dot net 2010-09-07 18:11 ------- > (In reply to comment #34) >> The last question I had of Daniel was could we get a test bed >> so others could try out the new bugzilla setup--looks like that is underway. > > Yes, we will have a test installation, as discussed in comment 27. But I first > need shell access, which is why I'm blocked right now. Waiting for Daniel or > someone else for help here. > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011 > > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is. >
(In reply to comment #37) > You should have shell access, do you not? I have now, yes, thanks to fche, see comment 36. I now have a working local copy of GCC Bugzilla to play with (both code and DB). I have one question for you, Daniel: what is the extra_emails DB table used for?
I have done some progress. The DB has been successfully upgraded to 3.6.2 (locally, of course), and I have converted GCC hardcoded columns into custom fields, i.e. using offically supported features in Bugzilla 3.x. So I will be able to install a test installation on the server soon, so that you can have a first look at the new installation.
A test installation based on a copy of the GCC Bugzilla database (snapshot taken today, September 9) and upgraded to Bugzilla 3.6.2 is now live at http://gcc.gnu.org/bugzilla-test/. Please give it a look, and file bugs related to missing or broken customizations in the new "Bugzilla" product on the test installation, i.e. using this link: http://gcc.gnu.org/bugzilla-test/enter_bug.cgi?product=Bugzilla Note that I didn't port *any* customization yet, so you probably have a lot to say. ;)
(In reply to comment #40) > A test installation based on a copy of the GCC Bugzilla database (snapshot > taken today, September 9) and upgraded to Bugzilla 3.6.2 is now live at > http://gcc.gnu.org/bugzilla-test/. > > Please give it a look, and file bugs related to missing or broken > customizations in the new "Bugzilla" product on the test installation, i.e. > using this link: > http://gcc.gnu.org/bugzilla-test/enter_bug.cgi?product=Bugzilla > > Note that I didn't port *any* customization yet, so you probably have a lot to > say. ;) You probably should announce this on gcc@gcc.gnu.org.
(In reply to comment #40) > Please give it a look, and file bugs related to missing or broken > customizations in the new "Bugzilla" product on the test installation, i.e. > using this link: > http://gcc.gnu.org/bugzilla-test/enter_bug.cgi?product=Bugzilla FYI, I can't login to the new bugzilla because my current password is 5 chars, which seemingly is less than the minimum for the new bugzilla.
" The attachment is not viewable in your browser due to security restrictions enabled by Bugzilla. In order to view the attachment, you first have to download it." I think at least text/* attachments should be shown. I think the restriction is to avoid problems with, e.g., HTML attachments, which can steal cookies. Thus some sites (like bugzilla.mozilla.org) use a different (sub)domain for the attachments. (A different subdomain would be fine for me as well - as would be HTTPS [at least for the login] but I think that's an item for overseers.) In any case, I would like to see the possibility to view patches and examples w/o downloading. Example: http://gcc.gnu.org/bugzilla-test/attachment.cgi?id=21126&action=edit
(In reply to comment #43) > I think at least text/* attachments should be shown. Ah yes, sorry, I forgot to enable the allow_attachment_display parameter (which is off by default). This is now fixed. Thanks for catching that! :)
The Log In line in elinks looks quite weird. There is a text field Bugzilla_login, then Bugzilla_password (both expected), but then there is another text field prefilled with password: <input id="Bugzilla_login_top" class="bz_login" name="Bugzilla_login" onfocus="mini_login_on_focus('_top')" > <input class="bz_password" id="Bugzilla_password_top" name="Bugzilla_password" type="password" > <input class="bz_password bz_default_hidden bz_mini_login_help" type="text" id="Bugzilla_password_dummy_top" value="password" onfocus="mini_login_on_focus('_top')" > Took me a while to figure out one shouldn't input password in there...
I read the patch attached to this bug, and I created a TODO list from it: http://gcc.gnu.org/bugzilla-test/buglist.cgi?quicksearch=%3ABugzilla Tell me if some of these features are no longer needed, to not make me waste my time. Also file a bug (on the test installation) if I missed something which should be ported to the new installation. I intentionally ignored all scripts in the contrib/ directory, because I'm pretty sure everything can already be accomplished with the official email_in.pl script. There are also some minor tweaks which I ignored as they don't seem important enough, at least for now.
Per the email Ian sent a few minutes ago, we will upgrade Bugzilla this Friday, September 17, for three hours starting at 18:00 GMT (11:00 PDT). So *please* give a try at our test installation, and report any problem with it asap.
The existing Bugzilla breaks long lists of bugs with a repeat of the header, every 100 bug reports. See: http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&cf_known_to_fail_type=allwords&cf_known_to_work_type=allwords&component=fortran&product=gcc&query_format=advanced&query_based_on=&columnlist=bug_severity%2Cpriority%2Cassigned_to%2Cbug_status%2Cshort_desc This is a list of 417 bugs (in the test database). The current bugzilla has extra separating lines with the column names. The new installation does not. This is useful, in the current bugzilla anyway, because very often you get strange formatting of the bugs list if one of the bug summaries is very long, or something like that.
(In reply to comment #48) > The current bugzilla has > extra separating lines with the column names. The new installation does not. Yeah, it is so by design. Not something I'm going to reimplement. Note that we finally won't upgrade tomorrow. I have severe hardware failures with my PC, and I cannot reliably run the upgrade process under these conditions. It's a miracle when I can comment in a bug without seeing my PC shut down for no reason. Sorry about that.
Created attachment 21851 [details] upgrade to 3.6.2 patch, final Here is my last iteration of the patch for the 3.6.2 upgrade. This patch alters core code. I will attach the GCC extension separately.
Created attachment 21852 [details] GCC extension for 3.6.2, final Here is the final version of GCC extension itself. You untar it from the bugzilla/ base directory, i.e. you will get bugzilla/extensions/GCC/. Now is a good time to hammer the test installation. I prefer bugs to be reported *before* the upgrade. If you see something wrong after the upgrade, don't complain. :)
Created attachment 21864 [details] upgrade to 3.6.2 patch, final (v2) Based on recently filed bugs and on some changes which have been accepted upstream meanwhile, here is an updated version of the core changes. This is the version I plan to use tomorrow.
Created attachment 21865 [details] GCC extension for 3.6.2, final (v2) And its extension counterpart. I fixed all bugs reported yesterday and today, so we are ready to upgrade.
Upgrade complete. Have fun!
(In reply to comment #54) > Upgrade complete. Have fun! By the way, I think I speak for the GCC project and its users when I say: Merci beaucoup, Frédéric! I hope we weren't very annoying with the little fiddling and bike-shedding. The new bugzilla looks nice. You indeed did something that many of us thought was an impossible feat!
(In reply to comment #55) > By the way, I think I speak for the GCC project and its users when I say: > > Merci beaucoup, Frédéric! > > I hope we weren't very annoying with the little fiddling and bike-shedding. Thanks a lot! I really appreciate. :) No worry, the GCC team was very nice. It was a pleasure to work with you all.
Thank you very much for doing this. I am hoping you would also be interested in upgrading the sourceware.org bugzilla installation. It is hosted on the same machine...
(In reply to comment #57) > I am hoping you would also be interested in upgrading the > sourceware.org bugzilla installation. It is hosted on the > same machine... Yup, see http://sourceware.org/bugzilla/show_bug.cgi?id=4790
This deserves mentioning on gcc.gnu.org. Thanks for the upgrade!
(In reply to comment #59) > This deserves mentioning on gcc.gnu.org. Thanks for the upgrade! Yep, I had asked Frédéric for some input already. :-)
Created attachment 21883 [details] upgrade to 3.6.2 patch, final (v3) This updated patch includes changes made since the production installation has been upgraded 2 days ago. I don't expect much more changes, and so this is probably my last contribution. The updated GCC extension will follow.
Created attachment 21884 [details] GCC extension for 3.6.2, final (v3)