Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] CDT 9.0/Neon M4 posted

Thanks Marc-Andre. That is the bar that we need to reach, i.e. reproducible milestone builds and we can do that by making sure each one get's it's own CDT p2 repo.

On Thu, Jan 7, 2016 at 3:16 PM, Marc-André Laperle <marc-andre.laperle@xxxxxxxxxxxx> wrote:
Hi Jonah,

Thank you for the follow up and nice summary. If there are no objections, for the future milestones, I suggest to use the non-composite repo in the b3aggrcon file and not update the versions. That should be the least amount of work and it will be safer than what we do right now. I think we can keep the composite repo for people who what to upgrade from miletones to milestones...or not if there is no interest.

Rergards,
Marc-Andre


From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Jonah Graham [jonah@xxxxxxxxxxxxxxxx]
Sent: Thursday, 07 January 2016 2:47 PM

To: CDT General developers list.
Subject: Re: [cdt-dev] CDT 9.0/Neon M4 posted

(I am still getting up to speed on simrel rules and operations, debugging the plugin version in the Neon M4 release was a great way to learn all about it, but do forgive me if I have the wrong end of the stick)

Quick follow up brought to my attention by conversation on cross project [1]

From [2]:
> We could use the non-composite repo next time but we still should double check the plugin version because the CDT plugins could end up coming from other update sites with wrong versions (projects that depend on CDT). 

It seems to be a requirement going forward, not an option, that the plug-in versions are specified in a way that the M4 mixup cannot happen going forward. I don't know if CDT specify the version in an absolute way if that completely prevents the problem of the wrong version (David Williams says the locked versions achieve 80% of the solution[3])

From [4]:
> [added 12/2015, for Neon] While part of the mechanics of contributing to the build, it is required that any contribution to the Simultaneous Release repository be done by a unique change to the b3aggrcon file. There are two ways to do this. First, your contribution repository can point to a simple repository where you know for sure there is only one version of your contribution available. Second, your contribution repository can be a composite repository but then you name exactly which versions to include. That is you need to specify all 4 version fields. You can, of course, do both methods, simple repository and name exact versions if you want the safety of that 
redundancy. 

I know that Marc K recently commented "We could put the correct versions, but then at every milestone we would have to update this file, which I'd like to avoid." [5] but it seems the bar has moved now.



~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com

On 25 December 2015 at 18:27, Marc-André Laperle <marc-andre.laperle@xxxxxxxxxxxx> wrote:
Hi Jonah,

My bad, when I tested the package, I must have forgotten to double check the CDT plugin versions (I remember doing so for Trace Compass though). I think my attention was too diverted toward the exceptions in M4. We use a composite repository for the aggregation just for convenience of not having to update that every time. We could use the non-composite repo next time but we still should double check the plugin version because the CDT plugins could end up coming from other update sites with wrong versions (projects that depend on CDT). We'll make sure to double check the versions in M5.

Regards,
Marc-Andre


From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Jonah Graham [jonah@xxxxxxxxxxxxxxxx]
Sent: Friday, 25 December 2015 9:06 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] CDT 9.0/Neon M4 posted

Hi folks,

2 issues with M4:

1) 
I can't install the Neon M4 version linked here into (for example) Neon M4a's platform because the launchbar part of Neon M4 is too old. If you manually install the launchbar from https://hudson.eclipse.org/cdt/job/launchbar-master/lastSuccessfulBuild/artifact/repo/target/repository it works though. See log [1] below for details.


2)
The Neon M4a version of C/C++ tools does not have the expected versions of all the plug-ins. The M4 version should all have 201512141104 as the qualifier, but most of the CDT plug-ins in the download [2] have qualifier 201511071104 which is the M3 version. e.g. org.eclipse.cdt.debug.ui.memory.floatingpoint is 201512141104, but org.eclipse.cdt.dsf.ui is 201511071104.

The releases staging area had the mixed versions: http://download.eclipse.org/releases/staging/plugins/?d

I assume the staging area has the mixed versions because when the aggregator ran it pulled in the latest resolvable versions of the plug-ins which led to the mix and match.

I note that there is a desire not to have to update individual bundle versions in the cdt.b3aggrcon[3], perhaps to prevent the wrong versions being picked up, the b3aggrcon can be updated to have the specific milestone as part of the URL. e.g:

$ git diff
diff --git a/cdt.b3aggrcon b/cdt.b3aggrcon
index 9c72caf..a061367 100644
--- a/cdt.b3aggrcon
+++ b/cdt.b3aggrcon
@@ -1,6 +1,6 @@
 <?xml version="1.0" encoding="ASCII"?>
 <aggregator:Contribution xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:aggregator="http://www.eclipse.org/b3/2011/aggregator/1.1.0" label="CDT">
-  <repositories location="http://download.eclipse.org/tools/cdt/builds/neon/milestones" description="CDT updates">
+  <repositories location="http://download.eclipse.org/tools/cdt/builds/neon/milestones/m4" description="CDT updates">
     <bundles name="org.eclipse.cdt.core.aix"/>
     <bundles name="org.eclipse.cdt.core.linux"/>
     <bundles name="org.eclipse.cdt.core.linux.ppc64"/>

Hopefully this would cause the aggregator build to at least fail instead of pulling in the wrong version?



PS I ended up in this area because of Bug 484894. For a while I was completely confused because my source tree checked out to 8a834d5 had non-functioning disassembly, but the M4 release it did work. 





[1] This is the log entry that P2 generated while trying to install CDT:

ENTRY org.eclipse.equinox.p2.operations 4 10053 2015-12-25 13:00:42.586
!MESSAGE Operation details
!SUBENTRY 1 org.eclipse.equinox.p2.director 4 10053 2015-12-25 13:00:42.586
!MESSAGE Cannot complete the install because one or more required items could not be found.
!SUBENTRY 2 org.eclipse.equinox.p2.director 4 0 2015-12-25 13:00:42.586
!MESSAGE Software being installed: C/C++ Development Tools 8.8.0.201512141104 (org.eclipse.cdt.feature.group 8.8.0.201512141104)
!SUBENTRY 2 org.eclipse.equinox.p2.director 4 0 2015-12-25 13:00:42.586
!MESSAGE Missing requirement: GCC support for CDT Build Core 1.0.0.201512141104 (org.eclipse.cdt.build.gcc.core 1.0.0.201512141104) requires 'bundle org.eclipse.launchbar.core 2.0.0' but it could not be found
!SUBENTRY 2 org.eclipse.equinox.p2.director 4 1 2015-12-25 13:00:42.586
!MESSAGE Cannot satisfy dependency:
!SUBENTRY 3 org.eclipse.equinox.p2.director 4 0 2015-12-25 13:00:42.586
!MESSAGE From: C/C++ Development Tools 8.8.0.201512141104 (org.eclipse.cdt.feature.group 8.8.0.201512141104)
!SUBENTRY 3 org.eclipse.equinox.p2.director 4 0 2015-12-25 13:00:42.586
!MESSAGE To: org.eclipse.cdt.gnu.build.feature.group [8.8.0.201512141104]
!SUBENTRY 2 org.eclipse.equinox.p2.director 4 1 2015-12-25 13:00:42.586
!MESSAGE Cannot satisfy dependency:
!SUBENTRY 3 org.eclipse.equinox.p2.director 4 0 2015-12-25 13:00:42.586
!MESSAGE From: C/C++ GNU Toolchain Build Support 8.8.0.201512141104 (org.eclipse.cdt.gnu.build.feature.group 8.8.0.201512141104)
!SUBENTRY 3 org.eclipse.equinox.p2.director 4 0 2015-12-25 13:00:42.586
!MESSAGE To: org.eclipse.cdt.build.gcc.core [1.0.0.201512141104]




~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com

On 14 December 2015 at 15:59, Marc Khouzam <marc.khouzam@xxxxxxxxxxxx> wrote:
Hi,

the CDT 9.0/Neon M4 build is now posted:
http://download.eclipse.org/tools/cdt/builds/neon/milestones/m4

zipfile:
http://download.eclipse.org/tools/cdt/builds/neon/milestones/m4/cdt-9.0m4.zip

It is based on commit: 8a834d59702025a3d1f44f379977b80068189213

M5 will be on Monday, Feb 1st, 2016

Enjoy

P.S. Thanks to Alexander Kurtakov for fixing compilation problems with M4 (not his own)
        during the weekend! And to Sergey for reviewing (the weekend too).

BR,
Marc
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev


Back to the top