Re: [cross-project-issues-dev] End of an Era: shell access.
On 8/27/19 13:27, Denis Roy wrote: I think we're one of the last shops on earth that has SSH shell access right into our mission-critical infra. Even before 2009 this practice was pure insanity from a data/systems security perspective but it was maintained as there were not many options. While I am all in favor of the restricted shell efforts I think one perspective has not been well documented. Do the "official webmasters" have full shell access? (the answer I assume is: "yes, of course"). So from another perspective, those people that say they really need shell access are probably doing some level of "webmaster work". That is at least part of the reason a lot of this got started back when there was too much work for one webmaster to do and volunteers were needed from the community. So, perhaps part of the solution to the problem of shell access is for the "official webmasters" to take over the work that Markus and Ed (and others) are doing. Or, perhaps distinguish the use-cases some so that some very few people are declared as "honorary webmasters" -- complete with training and "security certification" or whatever you do for the "official webmasters" to ensure a secure system. I just had not seen the problem framed from this perspective and wanted to do that before the topic closed completely. Thanks for reading, P.S. I am certainly NOT one of those honorary webmasters (any longer :) so it does not really matter to me what you do -- just giving unsolicited advice. :/ ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] End of an Era: shell access.
On 8/23/19 14:24, Matthew Ward wrote:
Hi Everyone,
I just wanted to follow up with a reminder that on August
28th we will be moving committers that have an actual shell on
Eclipse.org to our restricted shell.
I'd like to thank both Donat and Etienne on the Buildship
RelEng team who volunteered to test this change, and helped me
confirm that this change should be minimally disruptive.
If you have any questions, please let me know.
-Matt.
Thanks for the reminder.
Will those of use that still want to use 'scp' and similar still
have a 'home directory' (on "build"?) and is that still the place
for .ssh/authorized_keys2? Or, does all that change with "restricted
shell"?
If a change, can you point me to instructions on how to set that up?
I would assume some form of "ssh-copy-id hostname" but thought best
not to assume and ask explicitly.
In case you are wondering, the use case, for using scp and similar
is to download a number of builds to my local machine (without going
through web interfaces).
Now that I think of it, I currently use rsync via ssh, such as
rsync -a -e ssh ${committer_id}@build.eclipse.org:${dlpath}
"${output_dir}"
Will that still work with a restricted shell? Or, will I need to
convert to "scp"?
Thanks,
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] http or https reference to P2 repos: (was Re: Initialization for 2019-06)
On 4/16/19 04:13, Ed Willink wrote: Hi I just changed the repo reference in the *.aggrcon from http: to https: but the resulting log changes from: 08:40:39 Adding child meta-data repository file:/home/data/httpd/download.eclipse.org/mmt/qvto/updates/releases/3.9.2 to 09:03:28 Adding child meta-data repository https://download.eclipse.org/mmt/qvto/updates/milestones/3.9.3/S201904160751 This suggests that the SimRel build is able to exploit a trusted path to file:/home/data/httpd for http: but not https: Is this a bug/limitation of the SimRel setup, or should we be using http: for references to EF-hosted repos in *.aggrcon? This is controlled via a property in the ant "build.xml" file (or related property files) that specify what is re-written. Since this efficiency step is pretty specific to the "SimRel" process ran "locally" on Eclipse infrastructure, I suspect it is fine to leave as is and not solve by anything complicated. What I mean is there is a property in 'production.properties': rewriteRepositoryURLValue=file:///home/data/httpd/download.eclipse.org And, if that property is defined, then in the build.xml file there is a target named rewriteRepositoryURL which does an ant task using the 'rewriteRepositoryURLValue' and replaces what ever is specified in 'commonRepositoryDownloadURLValue'. That "commonRepositoryDownloadURLValue" property is currently specified as "http://download.eclipse.org" in the build.xml file. So, if all repo lines in aggrcon files were changed at the same time to use 'https', then only the build.xml file need be changed to use 'https' in place of 'http' in that one property. (And then sanity checked since it is a simple "match and replace" task with no regard for context.) If there is a substantive reason to have a mix of 'http' and 'https', then I'd recommend using something like the task instead of the task. If any of this is desired, I'd suggest opening a 'cross project' bug (and assigning it to Fred :) HTH ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Will the Platform Start Making Major Version Increments?
On 10/30/18 11:29, Daniel Megert wrote: Hi Ed Last time we discussed this in 2017 there were different opinions on this topic but we never decided on the topic. Today we decided unanimously that in general we will NOT increase the major version when removing deprecated API. HTH Dani Wouldn't it be best to update the wiki document, Version Numbering [1], with some explicit guideline in the hope for consistency between projects? Or, do you think the pointer to Evolving Java-based APIs [2] suffices? It does have a section there that includes the following sentence: [...] obsolete API elements are notoriously difficult to get rid of. Obsolete API elements should be marked as deprecated and point new customers at the new API that replaces it, but need to continue working as advertised for a couple more releases until the expense of breakage is low enough that it can be deleted. But I think explicitness is best. I am not sure "... the expense of breakage is low enough ..." would be interpreted as "no major version change required". I have opened Bug 540859 in case further discussion is required it can be done there. Thanks, [1] https://wiki.eclipse.org/Version_Numbering [2] https://wiki.eclipse.org/Evolving_Java-based_APIs [3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=540859 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] The Oxygen's BUILD_CLEAN job might be stuck
On 02/28/2018 01:35 PM, Quentin Le Menez wrote: Hi Fred, It seems that its stuck again :/ Do you have some ideas as to why ? Thanks, Quentin I do not know what the problem is/was, but opened Bug 531827. I did change a "timeout" setting, since previous jobs were stuck for 10 hours, and should have timed out after about 3 hours. I also manually killed a stuck job, and the next one does seem to be doing better. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] p2 <-> aggregator sync.
On 01/28/2018 12:48 PM, Stephan Herrmann wrote: Result [2]: Unable to load repository p2:file:///home/data/httpd/download.eclipse.org/objectteams/updates/ot2.7/staging While I don't see the actual root error, this appears to be the case were the aggregator cannot handle current format of p2 meta data. (Any chance to access any details of this failure?) Did you try the aggregator editor? I can see some detail in the console log, when using the aggregator editor. This is with Oxygen.2 and aggregator 4.7 installed. The log says "can not load repository" (as does pop up dialog), but then the log continues with !MESSAGE Unable to load repository http://download.eclipse.org/objectteams/updates/ot2.7/staging !STACK 0 java.lang.IllegalArgumentException at org.eclipse.equinox.internal.p2.metadata.RequiredCapability.assertValid(RequiredCapability.java:271) at org.eclipse.equinox.internal.p2.metadata.RequiredCapability.extractRange(RequiredCapability.java:250) at org.eclipse.equinox.internal.p2.metadata.RequiredCapability.getRange(RequiredCapability.java:164) at org.eclipse.cbi.p2repo.p2.util.P2Bridge.importToModel(P2Bridge.java:458) at org.eclipse.cbi.p2repo.p2.util.P2Bridge.importToModel(P2Bridge.java:342) at org.eclipse.cbi.p2repo.p2.util.P2Bridge.importToModel(P2Bridge.java:280) at org.eclipse.cbi.p2repo.p2.util.P2Bridge.importToModel(P2Bridge.java:402) at org.eclipse.cbi.p2repo.p2.loader.impl.P2RepositoryLoader.load(P2RepositoryLoader.java:120) at org.eclipse.cbi.p2repo.p2.loader.impl.P2RepositoryLoader.load(P2RepositoryLoader.java:60) And, from looking at the code, there is something about (p2's) "getVersion" that p2 considers invalid -- that is, while processing your version in your required capability data. Only in the Oxygen stream, that I see. In my dev. environment where Photon M5 is installed, and the aggregator built from master branch, (i.e. installed from ...cbi/updates/aggregator/ide/4.8/ then there is no exception, and no problem. But, I do not know if it produces what you intend. In the Oxygen branch, I put in some debug statements, ran locally, and it is chocking on the capabilities involved with org.eclipse.objectteams.otequinox.branding, perhaps this part: So, how many others are going to have *that* sort of match statement and that sort of problem? :) IMHO, at least for M5 and Oxygen.3, the Oxygen update branch of Sim Release should still be aggregated with a base of Oxygen.2 and ...cbi/updates/aggregator/ide/4.7/ whereas the Photon branch of Sim Release should be aggregated with Photon M5 and ...cbi/updates/aggregator/ide/4.8/ Can always revert back to Oxygen version if something goes terrible wrong. But, I would be the last to have any true insight into current issues. I have not been following all the detail requirements of why "capabilities" is being changed in the way it has been so do not know the use cases or motivations for the change. I assume no one needs a change for Oxygen updates. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Change in Eclipse SDK release cadence
No, no specific concerns or doubts. In fact I decided it was a silly question, since it is the simultaneous release that has a policy of "no breaking API changes, off-cycle". So, the original announcement must have meant "update releases". Thanks, On 12/03/2017 02:08 PM, Daniel Megert wrote: Hi David The plan is to apply https://wiki.eclipse.org/Version_Numbering. If you have any concerns or doubts, please open a bug report and post it here. Thanks, Dani ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Change in Eclipse SDK release cadence
What's missing from this announcement is what this means regarding versions or versioning. I can guess, but it would be better for you to be explicit. I am assuming you mean something more than "maintenance release" (i.e., a change in the third field, or 'micro,' of version). Since to mean that, it would be a simple change in terminology (for the sake of marketing, I assume, but doubt that is the case). I am also assuming you do not mean a major, API breaking change (change in the first field, or 'major,' of version). Since to mean that, would be to break many adapters' product and maintenance strategies -- and if so, all the more reason to be very explicit! :) So, that leaves an "update release" -- a change in the second field (or, 'minor' in OSGi terms) -- typically done when the code has a new API or a new feature that does not break existing code. If that is the case, it seems that everyone else has been doing update releases for a long time and the Platform has had the ability to do so, but never has in practice. I would guess you mean this latter case (an "update release") but suggest you make it explicit or explain whatever else it may mean to you. Thanks, On 12/01/2017 06:47 AM, Aleksandar Kurtakov wrote: After the Eclipse Photon release, a change in the Eclipse SDK release cadence is coming: Releases will happen every 3 months from master. This will reduce the huge waiting time that happens now for people contributing early in the development cycle, who had to wait for up to almost a year to see their feature or fix become available. Given the ever increasing pace of software development this is needed to keep the Eclipse SDK competitive, and to eliminate the burden on maintainers of doing backporting. Maintenance releases will no longer happen and people requiring a fix will simply update to the next release. Regarding the release train, each of the quarterly releases will be contributed to the respective release train version. The API removal policy remains the same, including giving 2 years notice before removing deprecated API. API removals can be announced in all four releases, and as a consequence API removals can also happen in all releases. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Oxygen.1a is broken when installed on top of the BETA Patch feature
On 10/13/2017 06:04 PM, Stephan Herrmann wrote: On day 2 after the Oxygen.1a there was quite a disastrous report on SO: https://stackoverflow.com/questions/46731161/jdk-9-wont-let-me-use-strings-java-lang-string-is-ambiguous It turned out to be a "simple" installation problem, and I'm afraid that many users will run into this, too: Installing Oxygen.1a on top of the BETA Patch feature does not effectively install the released version of JDT plug-ins. I believe this needs to be communicated immediately to all those who previously installed the patch feature. Which channel? I don't know, "check for updates" doesn't have a web page ... Stephan PS: needless to say, that the RC2a respin is also without effect in this setting. = = = I have not looked at this in detail, but one solution would be to produce a new "Beta Java-9 patch" even though it is no longer needed with Oxygen.1. Its purpose would be to simply make sure the latest JDT was installed (instead of the patched parts of JDT). The idea is that if someone has the beta patch installed already, then "check for updates" would effectively pull in Oxygen 1a. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] download.eclipse.org down?
On 08/22/2017 11:47 PM, Sravan K Lakkimsetti wrote: Hi, Download.eclipse.org is down for me. Any one facing this issue? Thanks Sravan Down for me too. And, down for Down For Everyone Or Just Me as well. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] JDK8&9 Update
On 07/25/2017 08:53 AM, Frederic Gurr wrote: Hi, Paths to the latest JDK8 and JDK9 have been updated as follows: /shared/common/jdk1.8.0-latest -> /shared/common/jdk1.8.0_131 /shared/common/jdk1.8.0_x64-latest -> /shared/common/jdk1.8.0_131.x64 /shared/common/jdk-9_x64-latest -> /shared/common/jdk-9-ea+179_x64 Please let me know if you have any questions or concerns. A very minor concern, but isn't "*_141" the latest JDK for Java 1.8? I just barely glanced at the release notes and do not see any earth shaking changes, but some might be important for some people? ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] SimRel aggregation build
On 07/17/2017 01:33 PM, Frederic Gurr wrote: Hi, I've started preparations for the Photon SimRel aggregation build. New jobs have been created on the SimRel HIPP (https://hudson.eclipse.org/simrel/). The Photon jobs are pointing to the master branch of the SimRel aggregation repo. There was once another suggestion made by someone (sorry, I have forgotten who exactly) that we not use the "master" branch in Git repo, but simply have the branch named for the release. That way, less churn as we switch from "main, first release" to "update releases". I have opened the following bug for discussion and comments. Bug 519843 - avoid 'master' branch in SimRel build repo ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] [Brainstorming] Why (not) a "Final Daze" in SimRel?
On 06/27/2017 08:04 AM, Ed Merks wrote: The update sites are only hidden by virtue of not telling the user the location of the update site. Making it visible is mostly about publishing the location in documentation somewhere, or by updating a composite to point at it. Blocking release availability isn't really making projects feel more agile thanks to SimRel... To be honest, for the EMF builds, we just kind of ignored this. We don't do any big announcement, but someone installing from various composites will install EMF 2.13. In many cases, it will work fine if someone updates their composites early, but not necessarily all cases. At least, historically, there have been cases where a user will be told "updates are available" but then when they try to apply them will be told "those updates conflict" with something else they have installed, and then given a list of (possibly confusing) choices (such as, "remove web tools so that emf can be updated?" [to paraphrase, and it is just a hypothetical example]). Perhaps, these days, these mismatches would occur less often than in the past but I suspect not completely and the more projects violated the "Simultaneous" aspect of update sites the more likely users would see issues. That is the core technical reason why there is a Simultaneous Release in the first place. Another reason (again, historically) is more mechanical: If some projects (especially large ones) were available for updates early then potentially hundreds of thousands of "update downloads" would be occurring at the same time the mirrors were trying to download gigabits (from other projects) to get fully populated and they would less able to do so. In other words, a network bottleneck: downloads for updates would be slow since there were so few mirrors, and mirrors could not get populated because there were so many downloads. You can avoid this bottleneck by having bits in place (so mirrors can get them) but to not update the composites until the appointed day (so that users will not be doing mass updates early). I am glad when I see efforts made to improve the Sim Rel processes, but I wanted to be sure you kept these factors in mind as you did. These factors tend to be forgotten when they do not occur -- and they have not occurred for many years (I believe) because most projects follow the recommended procedures. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Validating Aggregator fails because of legacy update site -> MAT
On 05/23/2017 01:47 PM, Alexander Nyßen wrote: Hi all, when validating the Oxygen aggregator on my machine, the validation fails because of an unsupported legacy update site. It seems this was introduced by updating MAT. If I disable MAT and Andmore (which depends on it), the validation succeeds on my local machine. I will also add, in case not obvious, that "legacy update sites" are explicitly dis-allowed in the Sim. Rel. aggregation. The aggregator itself should still allow it, if someone was building their own site and set the property "Allow Legacy Sites" to "true". ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] [eclipse.org-planning-council] Neon.3 Update Problems
On 03/30/2017 02:45 PM, Gunnar Wagenknecht wrote: On 30. Mar 2017, at 19:10, Daniel Megert wrote: I have never seen an announcement from Orbit that service release builds for Orbit got dropped, but that seems to be the current reality, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=509412#c19. I'm not entirely sure we ever officially had a maintenance/service build story in Orbit. Shouldn't the retention policy keep old bundles in place so that projects referencing those would still consume them during the Neon series? FWIW, I recall that David did create a "maintenance" branch for a Mars SR back in the days but that was more of an "ad-hoc" thing. I never remember using a maintenance branch in Orbit. We always had a maintenance build in Orbit when it was required. And we deliberately kept it to as few changes as possible (i.e. only those that were required and requested by a participant in the Sim. Release maintenance/update release. I think there is also another thing to consider. IMHO projects should stop hard-pinning specific 3rd party versions in the feature.xml - This makes builds and installs non-deterministic. That seems like a lot to give up. This isn't just a theoretical nicety. Especially with third party jars (when we do not always know what versioning or API rules they follow). It implies one set of tests on installs/updates using the "project's repository" and another set of tests on installs/updates from the "Sim. Release repository" (times the number of prereq repositories, in theory). And THEN anyone doing long term maintenance addressing (possibly paying customer's) issues has to wade through the possibly numerous versions of a "release" that slightly differ based simply on which repositories were used to not only create the products, but also which ones their customers used to do updates (times the number of derivative products which might use other sets of repositories). And, don't forget, the looser you make the constraints the more you are leaving it up to p2 to decide the "optimal solution" -- which is not always what you would expect and not always the same, from one run to the next. Gee, wouldn't it be nice just to build one big application instead of all these pesky components. :) ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Bugzilla seem to be down again
Is it my imagination, or do major outages always occur on the weekend? :) On 03/12/2017 11:02 AM, Denis Roy wrote: Our database master failed. We had a new server in place, synced up and ready to go. We were going to make the switch next weekend. That switch just happened. Our database servers are all new hardware. Apologies for the inconvenience. Outages from databases should now be a thing of the past. Denis On 12/03/17 07:11 AM, Andrey Loskutov wrote: Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, webmas...@eclipse.org and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Problem withorg.apache.httpcomponents.httpclient bundle in Oxygen M5
For what it's worth, you are both right. :) Nothing in the platform depends directly on the Apache httpcomponents, but ECF does, and the platform depends on ECF. In fact, part of ECF is duplicated in our repository so that it will be a self-contained repository and hence the Apache httpcomponents get dragged along with it. Just thought, I'd clarify. I do not think it makes any difference to the main part of the discussion. [I mention this in part, because a year or two ago we removed it from our "target" definition, since we did not need it, directly]. HTH On 02/03/2017 01:24 PM, konstantin.komissarc...@oracle.com wrote: Yes, by root I mean platform, JDK, etc. > But I can comment for the Eclipse top-level project (a.k.a. as SDK and Platform): we never shipped 'org.apache.http.entity.mime'. That’s false. The eclipse top-level project repository for 4.6.2 includes version 4.3.6 of the org.apache.httpcomponents.httpclient bundle that does include the mime package. - Konstantin From: Daniel Megert Sent: Friday, February 3, 2017 9:42 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] Problem withorg.apache.httpcomponents.httpclient bundle in Oxygen M5 Hi Konstantin I have no clue what you mean with "root". But I can comment for the Eclipse top-level project (a.k.a. as SDK and Platform): we never shipped 'org.apache.http.entity.mime'. Dani From: To: Cross project issues Date: 03.02.2017 18:33 Subject: [cross-project-issues-dev] Problem with org.apache.httpcomponents.httpclient bundle in Oxygen M5 Sent by: cross-project-issues-dev-boun...@eclipse.org We are having troubling building our plugin against Oxygen M5. The org.apache.httpcomponents.httpclient bundle in M5 build of root eclipse project is missing org.apache.http.entity.mime package. In M5 root Eclipse project repo, the version is 4.5.2 (771KB) and is missing the mime package In M5 Orbit repo, the latest version is 4.3.6 (845KB) and does contain the mime package On Apache.org, the version 4.5.2is 1226KB and does contain the mime package So, I have the following questions: 1. Where did version 4.5.2 in root Eclipse project repo come from, as it’s not in Orbit M5 build? 2. Why is this version missing org.apache.http.entity.mime package? 3. Why are we shipping a different bundle then what’s produced by the original third-party project? Since we are using the same bundle symbolic name, it’s a rather problematic situation. Thanks, - Konstantin___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Fwd: Simrel repo contributions
I will answer to "cross-project" list, since may be of general interest. And before answering the question, I will remind everyone the purpose of the "checkpoint build" was primarily to allow any new projects, or projects with new features, to "get into" the build, on a relatively stable base. Unlike "RC builds" not all projects would be expected to update their contributions for mere bug fixes. I also noticed that this is stated in the Neon Plan, but not the Oxygen plan so ... someone ... should update the Oxygen plan as well (assuming the Planning Council still wants to provide that checkpoint, for Oxygen update releases). I am assuming that the original issue or question revolved around someone's URL in the aggrcon file was not literally the "final release" one, in the sense that repositories are normally moved or copied to their final location during quiet week, and then the project must remember to also update their URLs in the aggrcon file. If that is the issue, then I'll make the following comments: a. What you say is true, project decides "the release" URL. BUT the "right content" is a little stronger than you say. It should be exactly the same. Not simply "fit in". b. We (or, I) never hounded projects much to update their URLs to their final ones, because every year a few would not and unless everyone does it, it really does not make the build "reproducible" so I thought it not worth the hounding. c. I did, however, set the 'validate' job (on both branches) to not only run upon git repo changes, but also to run once every Monday morning, to help spot "broken URLs". [I did not write much about these triggering events, so just now added it to the Simrel release engineering wiki.] If that is not the issue, then I will need more specific questions, or symptoms. It appears all the URL stuff was fixed 5 days ago, so if it is still an issue, then I suspect something else is wrong. HTH On 01/19/2017 12:40 PM, Frederic Gurr wrote: Hi David, Can you help me with Sravan's questions? I assume that every project is responsible to put in the right URLs for a release. SimRel in general does not care if something is a "release" URL, as long as the right content (whatever a project considers to be right and what does not cause dependency issues) is available, right? Regards, Fred Forwarded Message Subject: Simrel repo contributions Date: Mon, 16 Jan 2017 07:51:06 + From: Sravan K Lakkimsetti To: frederic.g...@eclipse.org CC: Daniel Megert Hi Fred, I was trying to update simrel with latest 4.6.3 M-Build for 4.6.3 check point. I noticed an issue with Sirius project. This raised following questions in my mind relating to 4.6.2 1. Did we build 4.6.2 with right repos? 2. When do we do build with release urls? 3. If we did build with wrong repo urls, how to rectify that? 4. How can we catch this situation in future. It may turn out to be non-issue. But would like to have clarification. Thanks and Regards, Sravan Sravan Kumar Lakkimsetti IBM India Pvt Ltd, Embassy Golf Links Business Park, D Block, Off Indiranagar-Kormangla Inner Ring Road, Bangalore - 560071, India Phone: 91-80-41776858 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Neon.2 update release is now available
Congratulations! This is our first-ever December update release! (The first 2-of-3 update releases.) What a busy bunch you are. :) Neon.2 is now available at the build-in repository at .../download.eclipse.org/releases/neon/ EPP packages are at https://www.eclipse.org/downloads/ or more specifically, https://www.eclipse.org/downloads/eclipse-packages/ (It may take a bit for the packages to "show up" on those pages). Also, the "new and noteworthy" and "help" sites may not be updated immediately, but should be soon (within a day or two): https://www.eclipse.org/neon/noteworthy/ http://help.eclipse.org/neon/index.jsp Sincerest thanks for making Eclipse higher quality and more functionally rich. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Are we distributing software with known security issues?
This question is motivated by a recent article[1] I happened across. In short, it pointed to evidence that many software applications are re-distributing open source components with known security issues. "*Yes*, we are distributing software with known security issues", is the answer to the subject question. To walk through one example, the article named org.apache.commons.fileupload version 1.2.1 as being often redistributed, even though known security issue (CVE-2014-0050). Versions 1.0 to 3.0 had the flaw, and 1.3.1 is required to avoid it. Version 1.3.2 is the most recent Apache version. That 'fileupload' package sounded familiar so I began to look around and I found that in the Platform's repository they are re-distributing version 1.2.2 of that package but (luckily?) in the Sim Release repo we have version 1.3.1. In the platform, it is Equinox's Http servlet bundle that has an optional prereq on "fileupload" and in Sim Release, it is RAP, apparently, that is "pulling in" version 1.3.1. = = = = = = I call out this flaw in our release practices, here on cross-project list, for several reasons: 1) I wanted to open a bug on the Platform and Equinox to update that prereq (bug 509388), but I see that "fileupload" Version 1.3.1 is not available from Orbit. *Why not?* That alone appears to be a Simultaneous Releases "no no". 2) More importantly, I mention this on cross-project list to encourage all projects to take a look at their third party dependencies and I ask you to get "up to date". If you find it is hard to update, at least confirm that the version you use does not have any security advisories associated with it. This should likely become part of our standard review process. (I have opened bug 509389 where that idea can be discussed.) To emphasize, the "org.apache.commons.fileupload" is but one example, easily spotted because it sounded familiar to me. There could be many others -- I do not know -- perhaps it is the only one? Thanks for reading (and taking action! :) [1] http://www.infoworld.com/article/3136330/security/buggy-components-still-dog-java-apps.html ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Requirements to participate in the Oxygen (2017) Release repository
Every year, the Planning Council specifies that M4 is the deadline for the council to have the official, final version of the Simultaneous Release Requirements. This year is no exception (though, sorry, I am sending this note a bit late in the day). The requirements are the same as previous years, except we did add one new item. Its purpose is to help us all focus on the direction Eclipse needs to go with "continuous updates". At this point, though, the requirement is for projects to "document" such support and technically it is possible for a project to document "we do not support it". See the following section for the new requirement (and, please, read the whole document if you are new to the Sim. Release and, even if you are not new, I recommend at least skim reading it yearly! :) https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#Document_Yearly_Update_Policy As mentioned there I have also opened bug 509237 to have an ongoing discussion of what issues prevent "continuous updates". = = = = = Off topic: This is not related to requirements, but does not deserve its own note ... I have started a "trouble shooting" section in the Simultaneous Release FAQ called Common errors and what to do about them. Please contribute to it, if anyone has seen other common problems that I have forgotten about. = = = = = Thanks as always! ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Oxygen M4 is available
Oxygen M4 has been made available at the built-in URL of http://download.eclipse.org/releases/oxygen/ (It is a composite, now consisting of M4, M3, and M2.) The EPP Packages are (or will be soon) available at the "developers" tab for packages, at https://www.eclipse.org/downloads/index-developer.php (I believe EPP is still waiting for a few package maintainers to approve, before ALL packages will be visible there). Thanks everyone for participating! One more for 2016: Neon.2 next Wednesday! ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Projects that have not (AFAICT) declared participation in Oxygen
On 12/15/2016 08:56 AM, Sven Efftinge wrote: Xpand is in maintenance mode, but I understood that it needs to be included if other projects have a dependency on it. In that case, I assume it is a viable option to just include last year's release again. Is that correct? That is correct. With some possible complications. Are you, Sven, saying to include Xpand as a representative of Xpand? If so, then I think fine for you to include it, in your own ?.aggrcon file. My guess is it would be best to also have a release record, even if it was not a new release, just repeat the previously released version, and say "maintenance mode, same version" as its release documentation. (But Wayne is the authority on release records). I can envision a few other cases and one of those will get complicated: 1. In the past, projects wanted to "include" a previous release of a project (or a few bundles) that was maintenance mode, and had no ?.aggrcon file of their own (i.e. no one left to represent the project) so in those cases the participating project "included" it, either directly via features or by mirroring to their own repository. This is a direct analogy to "the Orbit case". 2. The new case that might need some new procedure or policy: If there is a large project, say like DTP (just as an example), which is required by many, but has no one real representative, then technically it should NOT be in its own ?.aggrcon file, and SOMEONE should say they will include a copy of the previous release in their repository (or, in their own ?.aggrcon file?) for themselves and others to use. That way, there is always someone at least partially responsible for it if something goes wrong. If nothing goes wrong, everything is fine. If something does go wrong, SOMEONE has to do SOMETHING! (even if it is to decide "not to include it"). I mention this last "special case" since it sounds like there are a number of projects "in maintenance mode" and I suspect they will all "work" for a while, but eventually, as I am sure you already know, they will no longer work. Hence, a long term "ownership" is required, even for maintenance mode. Thanks, ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Oxygen M4 - staging is complete, as before
I never heard any more about Ben's build issues, and never saw any activity that would cause a new build, so I will once again say that staging is complete. I assume it turned out to be a difficult issue. (Feel free to ask on this or one of the other lists, Ben, in case someone has any insights or suggestions). Staging has not changed since my previous note. The last staging repo was produced around 6 PM Eastern on Wednesday ... in case you have gotten a head start, Markus. :) On 12/14/2016 07:56 PM, David Williams wrote: This is fine by me *IFF* you are talking about "hours". I will turn the job back on until about, let's say, 10 PM Eastern. (Feel free to say at that point if you are "close to done with a little more time". My main concern is that it not be delayed 24 hours or something, but otherwise, I am not going anywhere tonight. :) On 12/14/2016 07:27 PM, Ben Gamble wrote: It is after 5 on Wednesday, no one has asked for an extension, and the servers are cooling down after many contributions the past few days. I could *severely* use an extension to figure out why some of my plugins are getting signed with unparseable SHA-256 signatures D: -- Ben Gamble / BIRT / bgam...@opentext.com ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Oxygen M4
This is fine by me *IFF* you are talking about "hours". I will turn the job back on until about, let's say, 10 PM Eastern. (Feel free to say at that point if you are "close to done with a little more time". My main concern is that it not be delayed 24 hours or something, but otherwise, I am not going anywhere tonight. :) On 12/14/2016 07:27 PM, Ben Gamble wrote: It is after 5 on Wednesday, no one has asked for an extension, and the servers are cooling down after many contributions the past few days. I could *severely* use an extension to figure out why some of my plugins are getting signed with unparseable SHA-256 signatures D: -- Ben Gamble / BIRT / bgam...@opentext.com ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Oxygen M4 staging repository is complete
It is after 5 on Wednesday, no one has asked for an extension, and the servers are cooling down after many contributions the past few days. Hence, I will the staging repository complete and disable any new contributions builds (until Friday, after EPP packages are done). Thanks to everyone for participating! = = = = = = BTW, on Friday, or shortly after, I will also start to look at removing contributions that are on Wayne's "not declared" list sent earlier today. I will try to do it progressively to minimize disruptions, but, as you will recall, we opted to minimize disruptions for M2 (and future M1s) knowing we would have some amount after M4. Thanks, ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Beginning "quiet week" for Neon.2
As I am sure you know, we are scheduled to release Neon.2 on 12/21/2016, at approximately 10 AM Eastern. Between now and then is what we call "quiet week" -- a time for final acceptance testing and preparation of websites, etc. While it is called "quiet", that does not mean there is nothing to do. While we do not update the dates in the "Final Daze" document for every update release, the concepts are the same (please read the document, if you never have). But otherwise, the main things are: archive old releases put final artifacts in their permanent home so they can be synced up the mirrors (but, leave them "invisible" to general public, until 12/21). final testing, especially "update site" testing. Here are the links you need to know to simulate what "check for updates" will do once everything is in .../releases/neon: http://download.eclipse.org/technology/epp/packages/neon/SR2-RC4 http://download.eclipse.org/staging/neon/ Plus, there is one new thing and one change to the way we have done things in the past: The new thing: Contribute to overall new and noteworthy (if you have new features, or are new to the update release). For "How To" information, see Overall Release New and Noteworthy. The changed thing: There will no longer be a bug to list plugins that go into the help info center. Instead, as per Bug 499411 we will automatically find all the "doc bundles" in the Sim Rel repository and automatically add them. This is still a work in progress but you can take a look at the Hudson test.infocenter job if interested. Eventually we should have a "staging" sort of URL you can use to test your help documentation. If there is no other communication about Neon.2, then check back around 10 on 12/21 to make sure there are no "WAIT! ..." messages where we have to defer the release for some reason before you publicize the release. As always, please ask if there are questions or issues. Thanks to everyone for contributing to this update release. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Neon.2 staging repository is complete
As far as I can tell, everyone has made their final contribution for Neon. (Linux tools came in at 5:06 PM (Eastern) ... and they were not even the last one! :) As always, test well! Thanks all! P.S. I say "as far as I can tell" since my ISP's email system has been broken at least all afternoon, if not longer :( While I did look at the cross-project mailing list website, I know sometimes there can be a delay between the actual 'mail' and the 'mailing list' (website). So, don't panic if you recently sent an email (but, you might re-send it, now that I have worked around my ISP) ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Enabling soa-bpmn2-modeler.aggrcon?
This file, soa-bpmn2-modeler.aggrcon, shows BPMN Modeler with a disabled contribution (enabled="false"). Is that right? From the list of List of participating projects it appears BPMN Modeler is intending to be part of the Oxygen release. With M4 not far off, I thought I should point this out so the project can enable it (soon). No need to wait until your +n day even if you have some further changes to make, the earlier you are "in" -- and testing -- the smoother M4 will go. My guess is it was "disabled" long ago and just left that way -- perhaps due to some pack.gz problems? From my IDE it does "validate aggregation" ok, but I know there might be other things wrong, so I won't enable it automatically (unless asked to). BTW, That was the only "disabled attribute". Thanks, ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Neon.2 RC3 staging repository is complete
Staging is complete and ready for EPP packages to be created. http://download.eclipse.org/staging/neon/ Remember, there is several different ways to test the staging repository (each way important!): https://wiki.eclipse.org/SimRel/Simultaneous_Release_FAQ#What.27s_the_best_way_to_test_with_the_staging_repository.3F Thanks, ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Subversive new version
On 11/30/2016 04:52 PM, Alexander Gurov wrote: [...] Also there is a question regarding the build failure. Missing requirement: mappedRepo_home_data_httpd_download.eclipse.org_technology_subversive_4.0_neon-site 1.0.0 requires 'org.eclipse.team.svn.resource.ignore.rules.jdt.feature.group [4.0.0,5.0.0)' but it could not be found I did run the aggregation after submitting new simrel configuration (without the deprecated feature) and there was no error. Why is it that this error happened now? Did I miss something yet again? I have opened the following bug to discuss this particular feature. Bug 508499 - Issues related to org.eclipse.team.svn.resource.ignore.rules.jdt feature I am not sure what issue you are seeing, or even what you want to "end up with". But normally it is not good to remove a feature in an update release (it might prevent updating from one version to another, depending on the details of its "relationship" to other features/products). And, in addition, if even things are as you want them now, I am still seeing an issue related to category definitions. So, we'll discuss in but bug and see if I can help. Thanks, ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Subversive new version
On 11/30/2016 12:58 PM, Quentin Le Menez wrote: Hi David, I just saw that subversive released a new version of their feature (strange as they are +2 offset) and it failed our builds and the simrel one. Does this mean I'll have to do a respin of our NEON release ? Thanks Quentin Yes, it sounds like it. I am assuming you have a requirement on subversive. I am sending to cross-project list too for broader awareness, plus it serves as a good reminder to all that if anyone is contributing after their +n day, you should send a message to cross-project list to let everyone know. This is especially important if bundles or features change versions! ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] [simultaneous release build process] Can't edit aggregation data
On 11/30/2016 11:24 AM, Alexander Gurov wrote: Hi, everyone! It seems I can't open simrel.aggr file with CBI AggregatorEditor. The only thing I get is the exception below: java.lang.RuntimeException: Deprecated resource was not transformed at org.eclipse.b3.aggregator.presentation.AggregatorEditor.createModel(AggregatorEditor.java:1061) And this happens in both: Mars and Neon. The Aggregator Editor version I've installed is the one specified here: https://wiki.eclipse.org/Simrel/Contributing_to_Simrel_Aggregation_Build#Install_the_CBI_p2Repo_Aggregator_.28previously_called_.22b3_aggregator.22.29 I didn't find any bug reports on the issue, so may be it is not a bug, but there is some other method to use Aggregator Editor that I don't know of? P.S. Also after CBI Aggregator Editor is installed, there is no association with the *.aggr file type. In order to open the file I'm forced to set the association manually. Is that also a normal behaviour? The URL for the aggregator in that document was wrong. It should have ended with "4.6" instead of "4.5". Similar, that version was build for a Neon.1 (Eclipse SDK 4.6.1). Apologies for missing that. (I did send a note to cross-project list, but I know that is not the definitive source). Thanks, ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Neon.2 RC2 Staging repo is complete
The ../staging/neon repository has the latest "neon.2" output -- it has been a busy couple of days with many people making updates! I have temporarily disabled the "Neon jobs" that lead to changing the staging repository and will re-enable them on Friday, after the EPP packages are done. Thanks, ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Aggreagtor Email questions
On 11/23/2016 08:53 AM, LE MENEZ Quentin wrote: Hi David, I was wondering if this was the case (it seems so): do the emails in the project aggregator file need to belong to a committer for the aggregator build to succeed? I ask this because we tried to put ours (François and mine) in it but the build kept failing (and the report seemed to point to that particular addition). Thanks, Quentin No, there is no restriction on the email address like that. A common cause for failure to add an email address is that the email must belong to a "Contact" that has been defined in the simrel.aggr file/model (using the CBI Aggregator editor). And then that "Contact" added to the contribution. And then, BOTH files, simrel.aggr and your specific contribution file (*.aggrcon) committed. I hope it is something simple like that. If you continue to have difficulties, please open a bug in cross-project component with details/files and I will take a closer look. Thanks I have CC'd cross-project list simply because this is a common issue so thought others might like to read the question and the answer. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] setting mirror URL in the p2 repository
On 11/21/2016 03:58 AM, Lorenzo Bettini wrote: [...] Does it make sense? Several sites that I am (or, was) in charge of use a similar strategy. Especially when a repo is "moved" (such as from "candidate" to "released"). And, similarly, currently even for a Platform build, since we wanted to add the md5 checksums in a "post-build" step, but that need should go away with Tycho 0.27 once its released. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] NOTICE: - DONE refactoring of "aggregator" coming Thursday
I have completed the steps I needed to do, so the rest is up to you. You can install the new aggregator from http://download.eclipse.org/cbi/updates/aggregator/ide/4.6/ (and remember, you need to uninstall the old one first, if you are going to install the new one into the same IDE). If you do not re-clone the simrel.build repo you should just be able to "pull" and get all the name and file changes. And you will need to do that before you can update your contribution. Thanks, P.S. I will re-enable the Neon.VALIDATE job on Friday, after the EPP packages have been verified (approximately noon). The Neon.VALIDATE.gerrit job remains open for business, though. On 11/16/2016 04:55 PM, David Williams wrote: Colleagues, I have been working on refactoring the old "b3 aggregator" to the "cbi aggregator" (bug 506726). That is, refactoring package names, etc. This will require two things of those participating in the Sim. Release. 1. You will need to get a fresh copy of the aggregator installed into your IDE. (You will either need to "start fresh" or uninstall the old one before installing the new one). The new one is based on "Neon.1a" -- that is, Eclipse SDK (or Platform) 4.6.1. 2. You will need to check out a fresh copy of "org.eclipse.simrel.build" because the filename extensions are changing (plus a small tweak to the files themselves) due to the refactoring. My plan is to make the new version available soon, but you should not use it for Sim. Release until the changes have been made to "simrel.build". I plan to make those tomorrow, Thursday, between Noon and 1 PM (Eastern) unless there are objections to that timing. To be explicit, I will make the required changes in both master and Neon_maintenance. After all that, it will probably take me another hour or so to change the SimRel Hudson jobs so they are using the correct version of the aggregator. I know the timing is not great, but there will not be a good time between now and the end of the year. Apologies in advance for the churn, but I do think it is an important change that will be good in the long run. Thanks, ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Neon.2 RC1 staging repository is complete
Sorry for the late notice, but the staging repository for Neon.2 RC1 is ready. http://download.eclipse.org/staging/neon/ A good time to check the "repo reports" if you haven't yet: http://download.eclipse.org/staging/neon/buildInfo/reporeports/ And, remember, we no longer do "warmups", and the next RC is due in one week. Thanks, ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] NOTICE: refactoring of "aggregator" coming Thursday
Colleagues, I have been working on refactoring the old "b3 aggregator" to the "cbi aggregator" (bug 506726). That is, refactoring package names, etc. This will require two things of those participating in the Sim. Release. 1. You will need to get a fresh copy of the aggregator installed into your IDE. (You will either need to "start fresh" or uninstall the old one before installing the new one). The new one is based on "Neon.1a" -- that is, Eclipse SDK (or Platform) 4.6.1. 2. You will need to check out a fresh copy of "org.eclipse.simrel.build" because the filename extensions are changing (plus a small tweak to the files themselves) due to the refactoring. My plan is to make the new version available soon, but you should not use it for Sim. Release until the changes have been made to "simrel.build". I plan to make those tomorrow, Thursday, between Noon and 1 PM (Eastern) unless there are objections to that timing. To be explicit, I will make the required changes in both master and Neon_maintenance. After all that, it will probably take me another hour or so to change the SimRel Hudson jobs so they are using the correct version of the aggregator. I know the timing is not great, but there will not be a good time between now and the end of the year. Apologies in advance for the churn, but I do think it is an important change that will be good in the long run. Thanks, ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Oxygen M3 repo and IDE products ready
The Oxygen M3 repository has been "made visible" to p2. The repo is now a composite of M3, M2, and M1. Please test and report any issues. http://download.eclipse.org/releases/oxygen/ The M3 packages will be available soon, if not already. (We are considering calling them "IDE Products" so I was trying that out in the subject line :) They will be available soon from the usual "developers tab" on www.eclipse.org/downloads https://www.eclipse.org/downloads/index-developer.php There are a number of them that are still waiting for package maintainers to give their plus one. (hint hint). Thanks for everyone's participation! P.S. As a reminder, both M4 and Neon.2 are due in December at about the same time, so please allow for that in your planning. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Oxygen M3 staging repository is complete
Its Wednesday evening. Nothing's building. No one's asked for more time. So I will declare the staging repository "complete" and ready for EPP and others to do their part. To confirm it has the content you expect, please test http://download.eclipse.org/staging/oxygen/ Assuming no blocking problems are discovered, then it will become the official "M3 Simultaneous Milestone" on Friday. That is, I will update the composite at http://download.eclipse.org/releases/oxygen/ Thanks everyone, ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Git servers not working well?
Thanks for this tip. I did confirm that works, but then thought why not go all the way and avoid the network protocols and use file:///gitroot/... for builds. Works well for me in my Hudson jobs running on Linux. While it should not be required to make such changes, even after "git://" is fixed, it seems that "file://" might be more reliable than depending on the "internal network". Thanks again, P.S. I suspect file:// doesn't avoid "the network" completely -- I assume "NFS" is involved, but if it goes very little would work. :/ On 10/29/2016 05:04 PM, Stephan Herrmann wrote: On build.eclipse.org I consistently received git: Connection refused, but after changing protocol from git: to https: all was fine. Stephan On 10/29/2016 08:07 PM, Ed Willink wrote: Hi With the OCL HIPP, I can usually (75% success) get one build after restarting before the GIT connection fails again. Regards Ed Willink On 29/10/2016 00:04, Matthias Sohn wrote: ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Git servers not working well?
On 10/28/2016 02:26 PM, Marc-André Laperle wrote: A lot of our Hudson builds have been failing with for example: Command "git fetch -t git://git.eclipse.org/gitroot/tracecompass/org.eclipse.tracecompass.git refs/changes/24/84124/2" returned status code 128: fatal: read error: Connection reset by peer This seems to have happened all morning. Even when I try to fetch locally, if often fails. Is is possible that the Git servers are overloaded? I have seen similar issues and opened Bug 506727 It might be related to Bug 398795? ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Update your desktop versions of "cbi aggregator" (aka b3 aggregator)
On 10/28/2016 08:11 AM, Andreas Sewe wrote: Hi David, Sorry, I gave wrong URL. The latest build is at: http://download.eclipse.org/cbi/updates/aggregator/ide/4.5/I20161027-1601/ will this URL make it into the "Simultaneous Release Train" Oomph setup file? ATM, it still refer to org.eclipse.b3.aggregator.editor.feature from . Best wishes, Andreas I do not know much about the "Simultaneous Release Train Oomph setup file", but I do have a composite site now which should be used "by users" instead of the specific simple repos. The composite is at http://download.eclipse.org/cbi/updates/aggregator/ide/4.5/ I have updated in instructions in https://wiki.eclipse.org/CBI/aggregator/manual#Installation though they need a bit more work to be better (Bug 506725). = = = = = Also, the latest version at that composite site (I20161028-0744) is probably the last one I will create for the "4.5" stream, and plan to move to "4.6" next week (Neon.1a, specifically). The "big" change coming though is that I would also like to refactor the code to have the correct namespace for its new home (Bug 506726). If anyone wants to document opinions about this refactoring please do so in the bug. = = = = = Thanks. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Update your desktop versions of "cbi aggregator" (aka b3 aggregator)
Sorry, I gave wrong URL. The latest build is at: http://download.eclipse.org/cbi/updates/aggregator/ide/4.5/I20161027-1601/ On 10/27/2016 01:59 PM, David Williams wrote: I have a build of the aggregator running in its new home, CBI, (see bug Bug 487478) but with the main fix I have made so far it may cause you to get an error if you use the old version. The first thing I did was to base the current build on "Mars.2" (previous was way back on Luna). So when you install it, it is best to start with a Mars.2 environment. I do not have a composite, yet, but you can use the URL of http://download.eclipse.org/cbi/updates/aggregator/ide/4.5/I20161027-0333/ The first thing I fixed was that the old model did not allow a "backup" for the buildmaster to me named. (So I would be the only one getting CC'd if there were problems). Now that I have added that "buildmasterBackup" to the model, if you try to "validate" your contributions in the older 44 version of the editor you will get an error message that says basically "model contains unknown buildmasterBackup". I have updated the SimRel HIPPs that do validation. Thanks, ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Update your desktop versions of "cbi aggregator" (aka b3 aggregator)
I have a build of the aggregator running in its new home, CBI, (see bug Bug 487478) but with the main fix I have made so far it may cause you to get an error if you use the old version. The first thing I did was to base the current build on "Mars.2" (previous was way back on Luna). So when you install it, it is best to start with a Mars.2 environment. I do not have a composite, yet, but you can use the URL of http://download.eclipse.org/cbi/updates/aggregator/ide/4.5/I20161027-0333/ The first thing I fixed was that the old model did not allow a "backup" for the buildmaster to me named. (So I would be the only one getting CC'd if there were problems). Now that I have added that "buildmasterBackup" to the model, if you try to "validate" your contributions in the older 44 version of the editor you will get an error message that says basically "model contains unknown buildmasterBackup". I have updated the SimRel HIPPs that do validation. Thanks, ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Neon.1a is now available
As you all should know, we have been working on fixing a bug in MPC (Market Place Client) that effected other projects too. (bug 501000). The repositories are now visible to p2. The "Neon.1a" specific repository is .../releases/neon/201610111000/ if anyone wants to use that in builds, etc. The only difference between it and Neon.1 (.../releases/neon/201609281000/) is the MPC feature and bundles. New packages were also created, so those getting a new version over the next few months would "start off correct". The packages will be available soon, at the usual URL: https://www.eclipse.org/downloads/eclipse-packages/ (be sure to hit "refresh" if you are repeatedly checking with your browser). They will be labeled with "1a" at various points in directories and filenames. We should spend some amount of time figuring out why it wasn't detected before the release, but I know these things happen -- especially when proxies are involved! Thanks to everyone who made this quick fix available. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] A warning note on "Neon.1" tag in o.e.simrel.builds project
The note is relevant to anyone that checks out the "org.eclipse.simrel.build" project. Yesterday I tagged the wrong commit has for the Neon.1 release. I could not delete it (and could not change repo settings that would have allowed me to delete it) so today the webmasters deleted it for me (thanks!). See Bug 504827 for details. And, just now I have re-tagged the repo using the correct commit. As far as I can tell, if you "fetched" the repo between yesterday and today (getting the wrong tag) then fetching again will not "replace" the wrong tag. I think there are two solutions (other than re-cloning): 1) from command line, I think git fetch --tags will be sure to get all the remote tags, effectively replacing your local (incorrect) version; 2) From an EGit advanced fetch page, select the option that says something like "Always fetch tags " instead of leaving at the default of "Automatically follow tags ". If you look at Git history from Eclipse, the correct Neon.1 tag should be associated with commit 449b9618f320e557e9adb05c5fc0d272d045fefd. (The incorrect tag I think would be associated with commit 2c4ae083c3d055a85ea0438b3cb5604945a9d071) Sorry for the inconvenience that required "changing history". ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Note we will be doing a respin of Neon.1 for a MPC fix
Per the Planning Council's decision yesterday, we will be doing a respin of Neon.1 for a fix in MPC (Market Place Client). Part of the reason, besides it being a very bad "cross-project bug" (several other common projects are impacted, such as using EGit via a proxy), is that there is no easy way for users to "get" the fix without a respin. See bug 501000 for the problem to be solved by the respin. See bug 502937 for the mechanics of doing the respin. NOTE: this will be easiest if we simply usurp .../staging/neon repository for a few days (until about next Tuesday) for the purpose of producing the respin. This means in effect I will be suspending "Neon.2 builds" until the fixed repository and EPP packages are ready. If this greatly inconvenience anyone working on or testing early "Neon.2" staging, please comment in bug 502937 and I will consider alternatives. Sorry for the short notice, but I will suspend Neon.2 and begin the work approximately noon today. Thank you, ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Neon.1 is available!
As scheduled, Neon.1 is now available. Both updates from the repository at .../releases/neon And the packages will be visible soon (if not already) at https://www.eclipse.org/downloads/eclipse-packages/ I am sure there will eventually be an official addition to the "new and noteworthy" but, in the mean time, Holger Voormann has created an "Unofficial Promotion Video" at https://youtu.be/hW0ENpGcP34 which I think is pretty cool (good music too! :) Thanks everyone for your participation in the Simultaneous Release. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Final release urls for Neon.1 on simrel
Sravan and others, You can update the URLs in your b3aggrcon files at any time. And, you can still submit to Gerrit, just to confirm no typos, etc. And, you can even push to HEAD (of the Neon_maintenance stream). This will not go any further, though. That is, it will not kick off the "VALIDATE"-to-"CLEAN_BUILD" sequence since that part has been disabled. It is important to keep the aggrcon files accurate, especially if anyone deletes the repository that is mentioned in the files. We like to be able to build "at any time", just in case. (Though, since the release is tomorrow, the chances of that are pretty small.:) A few final reminders: Don't forget to update your "docs" if they have changed since June's Neon: Bug 500938 - Will soon need a Neon.1 info center Don't forget to mention any New and Noteworthy items you have added in Neon.1 Bug 500939 - Create New and Noteworthy for Neon.1 And, I do not keep track, but if there are any Neon.1 EPP packages that have not gotten approval from the maintainer, then I would ask "what is taking so long!" :) We will do the promotion and "make visible" at about 10 AM tomorrow, Wednesday 9/28 (Eastern time). After 10, please first check this list for any "wait, not yet" messages, but assuming all is clear then you are free to "make visible" your final download artifacts, and make what ever other announcements you would like. Thanks, On 09/27/2016 02:09 AM, Sravan K Lakkimsetti wrote: Hi David, I updated the final release urls on simrel for eclipse and equinox. Here is the patch https://git.eclipse.org/r/#/c/81887/ Can you please confirm when can I push this? Thanks and Regards, Sravan Sravan Kumar Lakkimsetti IBM India Pvt Ltd, Embassy Golf Links Business Park, D Block, Off Indiranagar-Kormangla Inner Ring Road, Bangalore - 560071, India Phone: 91-80-41776858 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Oxygen M2 repository and packages are complete
Once I had time to look at it, the problem with the sim rel repository was "real" (Bug 502080) and I have fixed, so now the repositories should be working for everyone. If not, please open a cross-project bug. The packages are now visible also at https://www.eclipse.org/downloads/index-developer.php well, 6 of them are. The rest are waiting for maintainers to sanity check and give their plus 1. Thanks again, On 09/23/2016 10:41 AM, David Williams wrote: Congratulations and thanks to the Sim Release Projects! Oxygen M2 repository is available from from .../releases/oxygen And the packages should be available before long from a tab under https://www.eclipse.org/downloads/index-developer.php (for those not waiting for a vote from maintainer). BUT, some of us (between me and Markus :) were having trouble accessing ../releases/oxygen and some of us were not. So, if it does not work for you, give it a few hours to propagate and stabilize. Normally I would wait to even send this note, but I have to run now for an appointment. I will check back this afternoon to be sure there are no lingering problems. But, we think thinks are ok from several ways of inspecting the repositories, and I think it is just a matter of getting onto the correct "nodes" or load balancers or whatever is behind serving up the data. Thanks again, and keep your fingers crossed. :) ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Oxygen M2 repository and packages are (almost) complete
Congratulations and thanks to the Sim Release Projects! Oxygen M2 repository is available from from .../releases/oxygen And the packages should be available before long from a tab under https://www.eclipse.org/downloads/index-developer.php (for those not waiting for a vote from maintainer). BUT, some of us (between me and Markus :) were having trouble accessing ../releases/oxygen and some of us were not. So, if it does not work for you, give it a few hours to propagate and stabilize. Normally I would wait to even send this note, but I have to run now for an appointment. I will check back this afternoon to be sure there are no lingering problems. But, we think thinks are ok from several ways of inspecting the repositories, and I think it is just a matter of getting onto the correct "nodes" or load balancers or whatever is behind serving up the data. Thanks again, and keep your fingers crossed. :) ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Oxygen M2 staging repository is complete
Thanks everyone for your updates. As we ended up, only soa-bpmn2-modeler is disabled, and only 5 or 6 projects have "decreasing" feature versions (the Eclipse Platform being one of them). :/ I will promote this repo Friday morning around 10:00 and re-enable the Oxygen aggregation builds Friday afternoon. Thanks again, ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] How to provide HDPI icons in yourplug-in
On 09/21/2016 08:20 PM, Stefan Xenos wrote: What I proposed would occur once, so it would slow down *installation* time but not startup time. We could show a message along the lines of "installing icons" to make it clear to the user what's going on. Or do you have some reason to believe this would have some impact on startup time once the icons are installed? I do not know a definitive answer, but found some hints. At first I was thinking something similar and did some googling for "svg png performance" and "does OS cache SVG" and a) did not find much about icons, per se, but otherwise seemed to be a lot of out-of-date information that I think is not always currently true ... most of it browser and webpage focused but (that is, low signal to noise ratio) and b) also found some bugs in Firefox's system that had titles such as "SVG cache must be invalidated if System theme changes". That, and even "scaling" seems like the kind of thing that might effect us. At that point I decided "this is complicated" and didn't read further. :) HTH ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Status and outlook for Oxygen M2
As I am sure everyone is aware, Oxygen M2 input is due tomorrow (Wednesday 9/21 approx. 5 PM). By some standards things look much better for M2 than for M1, but looking deeper there are still many things very incorrect. Some projects still contributing their "Neon" content -- not even Neon.1!. There are two projects "disabled". I assume intentional. I am being explicit to this list in case not. qvtd.b3aggrcon soa-bpmn2-modeler.b3aggrcon Over 30 projects have feature versions that *decrease* in version number compared to Neon.1 candidate, instead of being equal to or greater than. Perhaps some of these could be fixed by tomorrow, especially if it is a simple matter of using your Neon.1 contribution as input, instead of leaving at the initial Neon level. See Bug 501872 for over 400 more details. :) Third, at least the EPP build completes without error, though the artifacts are still labeled as M1. I hope this note helps us have a little better M2 then if I had not looked at the output of our builds and not sent this note. Thanks, ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Sub-categories for the Simrel
On 09/16/2016 03:16 AM, Lars Vogel wrote: does the simrel b3 Aggregator editor support nestled categories? AFAIK p2 does since a while and I think it would be very user friendly to group features. As far as I know, p2 does not support *publishing* subcategories. Those that do create subcategories do so with custom code, which we would not like to have in the "Sim Rel" since we want the categories to be defined in a central place, independent of how projects might define categories on their own sites with their own custom code. If you know otherwise please provide some pointers. I do think subcategories might be useful in some cases, but I am not sure about the example you give. There you put the focus on "Eclipse Foundation Projects" which normally mean little to end-users. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Neon.1 RC4 staging repo is complete
And, I hope, Neon.1! Well, except for all the little things like EPP packages, final testing, updating the "info" center, etc. Speaking of which, as we enter this quiet week before releasing (scheduled for 9/28) there are two bugs to be aware of. If anyone has changed their "docs" for Neon.1, please include the usual info in bug 500938. Bug 500938 - Will soon need a Neon.1 info center And, if anyone has added anything worthy of promoting to the general user population, please make a note of it in bug 500939. Bug 500939 - Create New and Noteworthy for Neon.1 Thanks as always! ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Oomph b3 agregator
On 09/14/2016 02:25 PM, LE MENEZ Quentin wrote: Hi again, I just saw https://hudson.eclipse.org/simrel/job/simrel.neon.runaggregator.BUILD_CACHED/659/consoleFull which completed successfully. Does this means we (Papyrus) are out of the woods? Thanks, Quentin Just to answer your question, it is only after a "CLEAN" build that you are "out of the woods" (and, even then, technically, a project that you prereq might mess you up later ... I say all this just in case you are getting ready to leave for vacation or something. :) ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] [neonAggregation] Failed for build 2016-09-14_13-20-39
Hi Remi and Vincent, Are you two "around" and actively working on fixing this issue? It is preventing others from contributing. If I don't hear anything within 5 minutes or so, I will open a bug and start looking to see what I can do (which, I'd prefer not to, since I just fixed "Oomph" :/ Thanks, On 09/14/2016 01:20 PM, neonAggregator wrote: The following error occured when building Neon: Unable to load repository p2:file:///home/data/httpd/download.eclipse.org/modeling/mdt/papyrus/updates/milestones/2.0/RC4/main Check the log file for more information: https://hudson.eclipse.org/simrel/job/simrel.neon.runaggregator.BUILD_CACHED/658/console ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Web Tools Project for Eclipse Oxygen: WSDL feature references wrong version of javax.wsdl?
On 09/13/2016 11:09 AM, Bob Brodt wrote: Hi Web Tools! I'm trying to build BPMN2 Modeler for Eclipse Oxygen, which uses o.e.wst.wsdl. This feature apparently references version [1.5.0,1.6.0) of javax.wsdl (according to maven), but the artifact included in the R3.9.0 updatesite is javax.wsdl_1.6.2.v201012040545.jar Am I missing something? Thanks! Bob Hi Bob, There were some issues with WTP's repository/build as mentioned in Bug 501060 but I thought it was supposed to have been "fixed by now". So if you are still having issues, I suggest you open a "cross-project" bug and be specific about which repositories you are trying to use and I might be able to help you sort it out (or, find a work around) -- assuming WTP's release engineer doesn't respond. :) ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Oomph b3 agregator
On 09/14/2016 01:02 PM, Carsten Reckord wrote: This build, which promoted the 1.5.0 release build, also removed the old milestone drop: https://hudson.eclipse.org/oomph/job/integration/2601/console This currently blocks validation of all simrel contributions through Gerrit. Ed, would it be okay if we updated the oomph.b3aggrcon in simrel to point to http://download.eclipse.org/oomph/drops/release/1.5.0? I assume that's the build you'd want to contribute to Neon.1 RC4 anyway - otherwise Eike can still change it later. Best, Carsten In parallel, I have opened bug Bug 501441 and will merged the change into HEAD of Neon_maintenance assuming "validate" passes (which it does for me locally). ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] (some) Neon.1 RC3 packages are available
The Neon.1 RC3 packages have been made available at the usual place: https://www.eclipse.org/downloads/index-developer.php There are still quite a few waiting for the maintainer to sign-off. I suspect those missing from the page will show soon, as the maintainers finish their testing. Upgrades (using "check for updates") can be tested by adding the following URLs to your list of enabled p2 repositories. http://download.eclipse.org/technology/epp/packages/neon/SR1-RC3 http://download.eclipse.org/staging/neon/ Also, I have re-enabled the Neon aggregation builds for RC4 -- our final build for Neon.1. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Gerrit Oxygen aggregation validation is open for business
On 09/08/2016 09:00 AM, David Williams wrote: [...] So, I will ask that projects please contribute what you can to "be current" (even if it is the same your "neon input"). And, I ask that you do that even if Gerrit does not pass. I am not sure Gerrit will pass until a fair number of contributions have been updated. I will keep an eye on things, and if it ever appears we can get "green builds" by disabling only a few contributions, I will do that, so that you all make make use of Gerrit again. Much thanks to those of you who made a few quick fixes that now allows the Gerrit/Hudson validation job on Oxygen stream to run again with reasonable accuracy. I did have to disable one project, bpmn2-modeler (Bug 501098), but the rest are "enabled". That does not mean they are all correct! :) But at least they can correct themselves now using the preferred method of submitting to Gerrit/Hudson (preferred since that reduces the risk of "breaking the build" for others). I know most of you are busy finishing Neon.1, but I hope you find a few minutes to update your Oxygen contributions (if they need to be). Put another way, there is no need to wait until your +n day to provide something close to what you might provide on your +n day, just so that problems can be spotted earlier. Thanks, ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] ALERT: I have (re) enabled all contributions in Oxygen aggregation
At the Planning Council meeting yesterday, it was decided to no longer disable all contributions at the start of a development cycle, but instead assume an implicit "opt-in" and we will find other ways to track projects which are inactive or unresponsive or which never "declare intent" or submit release records. This is not entirely "good news" since the stream still does not "validate". There are many issues exposed now: some "missing repositories", many constraints not satisfied. I am thinking this is primarily due to people not making contributions since Gerrit would not "validate" due to something being disabled, and people just giving up and not updating their files to be "current". I tried just disabling a few, to see if I could get a complete build with only a few missing, but there were far too many "circular" dependencies and I gave up after disabling 5 or 6 since it was obvious not much progress could be made that way. So, I will ask that projects please contribute what you can to "be current" (even if it is the same your "neon input"). And, I ask that you do that even if Gerrit does not pass. I am not sure Gerrit will pass until a fair number of contributions have been updated. I will keep an eye on things, and if it ever appears we can get "green builds" by disabling only a few contributions, I will do that, so that you all make make use of Gerrit again. Thanks, ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Staging repo for Neon.1 RC3 is complete
Apologies for the delayed announcement, but the staging repo was complete about 7 PM last night. I have disabled new builds until the EPP packages are complete and declared. Thanks, ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
cross-project-issues-dev@eclipse.org
On 09/02/2016 01:59 PM, Wim Jongman wrote: Thanks David! Is there a N&N somewhere? Not so far (that I know of) but I suspect there should be. I have opened Bug 500939 to track the issue. Thanks, ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Neon.1 RC2 packages are available
Their location may not be as obvious as in the past but they are there (click on 'packages' from http://www.eclipse.org/downlaods and then you will see the familiar "developers" tab. Or, the direct URL is https://www.eclipse.org/downloads/index-developer.php I did not look closely but some packages may still be waiting for maintainer approval. Be sure to test "updates" from the initial Neon version, as well as your favorite functions. To test updates you need to add and enable these two repositories to your software sites list: http://download.eclipse.org/technology/epp/packages/neon/SR1-RC2 http://download.eclipse.org/staging/neon/ I am assuming that updates using the installer are also ready but I have not tried it myself and have not communicated directly with the "installer team". I have re-enabled the Neon aggregation builds. Thanks, ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Neon.1 RC2 staging repository is complete. One caution about WindowBuilder
It appears everyone got in their RC2 contributions despite the DNS issues (since I have not heard otherwise), so I have turned off the aggregation jobs so the EPP packages can be created and give a few days of a non-changing staging/neon repository for testing. = = = = = = = = My caution about WindowBuilder is the same as I mentioned last week in Bug 498276. https://bugs.eclipse.org/bugs/show_bug.cgi?id=498276#c5 As I understand it, from a post to this mailing list, version 1.9.0 is planned to be contributed to both Neon.1, but it appears the version in Neon.1 staging is still 1.8.x. Please correct me if I have misunderstood something. But, if not, I am concerned that WindowBuilder is still not meeting the requirements of being in the Simultaneous Release. This is "RC2" after all and it does not appear WB is providing a _Release Candidate_ and not actively participating. If the issue is not clarified or corrected promptly I'll propose that WB be pulled before RC3. = = = = = = = = Thanks to all for your efforts to improve quality and provide new features for Neon.1. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Gerrit is failing to connect to https://hudson.eclipse.org
On 08/30/2016 05:32 PM, Jeff Johnston wrote: I tried restarting our hipp instance and now linuxtools hudson pages are unavailable (503). This is bad timing since we are trying to get RC2 out for tomorrow. While I don't know if "restarting" will fix the issue, just thought I would mention that I have not seen "restart" work for a very long time. (Even though it "acts like" it does on the account page.) But what does work, for me, is to "stop" the server. And, then "start" it. [Not sure if you meant "restart" literally or not or if this is common knowledge.] HTH ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Restarted Neon aggregation, and status of EPP
I have restarted the Neon aggregation jobs. For EPP news, see https://dev.eclipse.org/mhonarc/lists/epp-dev/msg04242.html But to quote it here for your convenience: = = = based on the Neon.1 RC1 staging repository we have an EPP 4.6.1RC1 build available that needs testing... * https://hudson.eclipse.org/packaging/job/neon.epp-tycho-build/390/artifact/org.eclipse.epp.packages/archive/ The two p2 repositories that can be used for upgrade tests are * http://download.eclipse.org/staging/neon/ and * https://hudson.eclipse.org/packaging/job/neon.epp-tycho-build/390/artifact/org.eclipse.epp.packages/archive/repository/ At the moment I have no intention to go the extra mile and copy/rename/publish the RC1 packages to the download page. I'd propose to use this RC1 as a warm-up build to verify that everything is still building and the version increment works for all packages. = = = = Thanks, ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Neon staging repository for RC1 is complete
It is Wednesday, after 5, and no one has requested a delay, so I will consider RC1 staging repository complete. I have disabled the aggregation jobs for Neon (but not the VALIDATE.gerrit one) to be sure nothing accidentally and automatically gets promoted until after the EPP packages are ready. I will re-enable on Friday afternoon. Recall that since the RC builds are only a week apart, we do not "promote" the staging repository anywhere else until the final Neon.1 release, about a month from now. For exact dates, see https://wiki.eclipse.org/Neon/Simultaneous_Release_Plan#Neon.1 I am assuming, unless Markus says otherwise, that there will be EPP packages created for testing and made available (somewhere) on Friday approximately 10:00. Also, please pay attention to the "version reports" that were fixed just today (for the Neon stream, see bug 500224) and would encourage release engineers or or project leads to take a look at them (and other reports) for improvements that are needed for Neon.1. As always, it is at the URL below, which is also given as a link at the top of our SimRel HIPP instance. https://hudson.eclipse.org/simrel/job/simrel.neon.runaggregator.BUILD__CLEAN/lastSuccessfulBuild/artifact/aggregation/final/buildInfo/reporeports/index.html Thanks, ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Status of Neon.1 RC1 plus reminder about RC2
I do not know how RC1 "runs", but it was building ok until today. There is a problem from ECF contribution that is the same as Bug 492904 which I have re-opened. If I do not hear from the ECF team soon, I will revert their contribution in order to get a green build for RC1 and they can fix for RC2. Reminder for RC2: It is *next* week. There is no longer 2 week buffer for "warmup". Thanks, ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
