text:
Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Modeling Project Releng/Releasing
- 1 Release Process
- 2 Build Naming Conventions
- 3 Promoting A Build
- 4 Promotion FAQ
Release Process
All components are requested to follow this release schedule:
- Tuesday/Wednesday night:
- Your code in CVS must be "compile error free". Feel free to run N builds that afternoon to verify this.
- Wednesday/Thursday morning:
- One Integration (I) build from your main branch (HEAD), and/or
- One Maintenance (M) build from your maintenance branch (eg., R1_0_maintenance).
If your component is participating in a Coordinated release such as Ganymede (June 2008), please be aware of the release schedule for Milestones and Release Candidates, and provide Stable (S) builds in alignment with those dates.
Rampdown to Release
After the M7/RC0 builds are published, it's usually time to review the copyrights in your sources to ensure they're accurate. You may also be asked at some point to provide all of the about.* files to the Eclipse Management Organization (EMO) legal department so they can review them prior to the release.
You will also be required to provide a slide deck to your PMC, as he will be representing your component at your Release Review. For samples of past release review slides, see
Collecting Abouts
- First, sources are collected using this script and the map file listed on your downloads page for your most recent milestone build. (If you don't have access to your own linux box, you can run this on emft.eclipse.org or build.eclipse.org.)
- Next, check out Jeff McAffer's org.eclipse.orbit.releng.aboutextractor tool from CVS and use that to process your sources into a new directory containing only the Abouts.
- Finally, that new directory can be zipped and sent to email@example.com and/or email@example.com, as required.
Maintaining Your IP Log
As part of being an Eclipse project, everyone is responsible for keeping the IP clean. This includes:
- Contributors: by attaching patches to bugs
- Committers: by committing patches and filing CQs for large contributions, and using the 'contributed' keyword on bugs with contributions which have been committed to your code base
- Project/Component Leads: by enforcing the IP rules for your committers/contributors, updating IP Logs in the event they ever get out of date, and filing CQs on behalf of soon-to-be committers
- PMCs: all of the above, plus liasing with the Foundation in terms of Release & Graduation Reviews -- collecting Abouts, Slide Decks, and IP Logs.
Currently, there are three ways to log your project or component's IP.
Method | Provider | Example | How to Update |
Dynamic | Eclipse Foundation | ip_log.php | Contribute to this log by modifying bugs in Bugzilla and by opening CQs in IPZilla. |
Half & Half | Modeling Project | ipquery.php | Contribute to this log by modifying bugs in Bugzilla and by opening CQs in IPZilla; you can also add static information by editing your ipquery.php file. |
Static | project/component committers | eclipse-project-ip-log.csv | Contribute to this log by editing your eclipse-project-ip-log.csv file. |
For more on how to keep your IP Log up to date, see Modeling Project Releng - Releasing - IP Log.
Release Reviews / x.y.0 Final Builds
- DO NOT PUBLISH an R build until you've been through a release review.
- DO NOT PUBLISH any build using a vanity name ending in ".0" without a release review.
- DO PUBLISH as many I or S builds as you want -- ideally, you should be publishing one build a week, but only if there are changes.
You can have unlimited weekly Integration (I) builds, then about once every 6 weeks and at the end of your development cycle, you should publish a Stable (S) build. These are usually vanity-named with "0.8.0M2" or "0.8.0RC" to describe the Milestone or Release Candidate status and number.
At the end of your development cycle, you should do an RC build at least one week before your final planned release date. When you pass your Release Review, you can use the /home/www-data/build/modeling/scripts/renameBuild.sh
script to rename your "0.8.0RC" Stable (S) build to a "0.8.0" Release (R) build, and repromote it under the new name. This will ensure the correct metadata is properly updated (RSS feed, release notes).
Once your x.y.0 build is reviewed, passed, and released, you can continue in HEAD working on x.y.1 (or branch immediately). Publish as many (M)aintenance builds as you want, then again, as you get close to the end, a Stable 0.8.1RC can be done. Maintenance branch releases need not be reviewed prior to release.
At some point you'll want to branch HEAD (eg., 0.9.0) and R0_8_maintenance (eg., 0.8.1 or 0.8.2). When you start doing 0.9.0 builds, they will be I builds, interspersed with S milestone builds and RC build(s) towards the end of the cycle. Finally, your last RC will be reviewed and you'll once again rename and repromote.
It is HIGHLY ADVISABLE to not branch midway through a release, in order to preserve accurate release notes.
Please also be aware that your build server is SHARED -- clean up your old builds (especially any -noclean builds) when they are obsoleted by newer ones in order to save space for others.
Renaming a Build / Releasing Your GM Build
- When releasing your final build, you may decide to rename an RC build if nothing bad has happened since that build was released. For example, you might plan to release your final build on Sept. 28, so you'd do an RC1 build two weeks before. If any stop-ship bugs were found, you'd spin an RC2 build the week after, on the 21st. Then, if no more bugs were found, you'd be able to promote that build as your GM (Golden Master) on Sept. 28 - however, you'd have to rename the zips, md5 files, dependencies listed in build.cfg, etc.
- The good news is that there's an easy way to do this - renameBuild.sh. This script contains detailed instructions and examples of usage; just run it from the commandline w/o options to see. Additionally, here's an example showing a rename of JET from 0.7.1RC2 to 0.7.1:
sudo -u www-data ./renameBuild.sh -proj jet -verbose -branch 0.7.1 \ -buildID S200609210820=R200609210820 -buildAlias 0.7.1RC2=0.7.1 \ eclipse-SDK-M20060919-1045-linux-gtk.tar.gz=eclipse-SDK-3.2.1-linux-gtk.tar.gz \ M20060919-1045=R-3.2.1-200609210945 \ S200609210005=R200609210005 \ 2.2.1RC2=2.2.1 \ fullmoon.torolab.ibm.com=download.eclipse.org \ emf.torolab.ibm.com=download.eclipse.org
- When you're done renaming, you can simply promote the new build as you did the previous week (-buildID S200609210820), using the new ID (-buildID R200609210820), and you'll have your GM build published. *HOWEVER**, if you are participating in a coordinated release, you must adhere to the process rules for that release. For example: Ganymede - Final Daze - Modeling Project, Ganymede - Final Daze.
- After releasing the final build of a given version, you need to remember to upgrade the version of the plugins you change. In other words, if a plugin is not changed then its version remains the same. After upgrading the version of a plugin, you need to ensure that the version of the appropriate features and branding plugins are also upgraded, and that the feature is referring to the new versions of the plugins. Also, if you change a plugin with source code, you may need to upgrade the appropriate documentation plugin (and documentation feature and branding plugin) if the build is adding Javadoc to it.
Build Naming Conventions
Because Modeling consists of many projects with an ever-expanding set of components, it's important that we all adhere to consistent naming rules for each build type. It's also important to be consistent within your component or your release notes will be sloppy or incomplete. Build Aliases must conform to one of these patterns in order to be automatically added to the release notes database:
When building, use the Build Alias field to name your S and R type builds.
The rules are very simple.
- If it's a Milestone (build type S), call it "x.y.zMn", eg., 0.7.0M6
- If it's an RC (build type S), call it "x.y.zRCn", eg., 0.8.0RC1 or 0.8.2RC
- If it's a Release (build type R), call it "x.y.z", eg., 0.9.0 or 2.0.2
- All other builds (I, M) use no alias and are named using the default pattern of
, eg., I200802070245
Promoting A Build
The First Time
- First, ensure you've set up all your SSH keys, including the one for the web user.
- Next, ensure your promoteToEclipse.*.properties file is up to date. Once your file is correct in CVS, you can run this (sudo'd as the web user, www-data or apache) to check out the latest version of that file from CVS:
/home/www-data/build/modeling/scripts/getPromotePropertiesFromCVS.sh emf.ecoretools |
- Contact User:Nickb, and ask that he:
- add your component to relupdate.php,
- add a "0.0.0" release to releases table for your component, and
- check out your project and releng sources for use with searchcvs
- Load up promo.php. You can only promote I, M, S, and R builds this way. If your branch is not listed, make sure your _common.php file is up to date. See also Website Maintenance.
- Review the log file generated by the promote process. Log files are stored in
. If you encounter any errors in the log, review Modeling Project Releng or contact User:Nickb.
- Should a step fail, you can re-run the whole promote (but you may get duplicate entries in your RSS feed and update site). To avoid this, you can remove the new content before re-running the build, or you can run only the relevant parts that failed via the commandline promote script interface. For example, to re-run the javadoc generation step, use:
cd /home/www-data/build/modeling/scripts/;./promoteToEclipse.sh -sub ecoretools -docsonly -Q -buildID I200712031234 ... |
- To see all the commandline options available to you, run
without options for the inline help.
- PLEASE NOTE! Once your promote is done, you will not see it on eclipse.org for at least 20-30 minutes as the various eclipse.org cluster nodes replicate. Why?
- download.eclipse.org is served via nfs on all of the nodes from the nfsslave. The master and slave replicate every 4-6 hours depending on system loads.
- So, unfortunately, the only recourse is patience.
- When your build does appear at eclipse.org, download the zip and test it out to ensure it works for you. Then try and install via the update site.
- When you're satisfied, update the _projectCommon.php file for your project (EMFT, MDT, etc.) to remove your project from the
array. Wait 30-60 seconds and then refresh your project's homepage, downloads page, release notes, etc. to ensure your component is listed correctly. See also Website Navigation.
- If you plan to contribute to a coordinated release such as Ganymede, make sure you've added your component to the list, and that you have write access to
. If you don't, open a bug assigned to email@example.com and cc:'d to your PMC User:Nickb. You should ask:
- "Please add user yourusername to group callisto-dev for Ganymede .sc file contributions."
- If you don't set up your SSH keys, including the one for the web user correctly, you may see this in your promo log:
Permission denied, please try again. Permission denied, please try again. Permission denied (publickey,gssapi-with-mic,password).
- If you see Permission denied errors in the promote log, you may not have sufficient permission to create files on the download server.
mkdir: cannot create directory `/home/data/httpd/download.eclipse.org/modeling/m2t/mtl': Permission denied
- Open a bug assigned to firstname.lastname@example.com and cc:'d to your PMC and User:Nickb, asking "Please add user yourusername to group groupname for publishing buildname builds."
- Groupname will be in the form m2tadmin (old style) or modeling.emf.website (new style).
Scheduled Releases (Promoting Automatically)
See Scheduled Releases.
Update Manager Sites & Build Types
If you go to http://www.eclipse.org/modeling/emft/updates/, you'll see a note about two different UM sites. These two sites are there to split final, release builds from interim builds, so that the two types of users can benefit from the two types of releases.
A release build (R) is anything that's done as a final GM (aka Golden Master) release, eg., 0.7.0, 0.7.1, 1.0.0, 1.0.1. Everything else is considered "interim" - Nightly, Integration, Maintenance, Stable (N, I, M, S).
So, for example, when you publish an I build (eg., 0.7.5 I200610050000), it gets added to site-interim.xml. When you do your final build for that stream, (eg., 0.7.5 R200612020000), it will be added to site.xml.
Note also that the URL to give to Update Manager (or to put in your features) is NOT http://www.eclipse.org/modeling/emft/updates/, but download.eclipse.org. www.eclipse.org stores website content only, and provides a location for extracting, updating, and committing changes to the site.xml and site-interim.xml files, in order to provide CVS versioning & history. The actual site is http://download.eclipse.org/modeling/emft/updates/site*.xml, which is also benefitted by the fact that it's mirrored (unlike www.eclipse.org).
- For more on build types, see http://www.eclipse.org/modeling/downloads/build-types.php.
Generating Update Manager Site Jars
- For details on generating Update site XML, jars, digest, and metadata, see: Update Site Generation.
- For troubleshooting, see Troubleshooting.
Contributing To Ganymede Update Site
# pattern to use when searching for features to include in coordsite; defaults to ".*eclipse/features/org.eclipse..*(${subprojectName}|${subprojectName}.sdk)_.*\/$" coordsiteFeaturePattern=".*eclipse/features/org.eclipse..*(emf|emf.sdk|xsd|xsd.sdk|emf.ecore.sdo|emf.ecore.sdo.sdk|emf.common|emf.common.ui|emf.ecore|emf.ecore.edit|emf.edit|emf.edit.ui|xsd.edit)_.*\/$" # pattern to use when setting feature to include in coordsite's main feature ('Models and Model Development'); all other matching features will go in 'Enabling Features' coordsiteMainFeaturePattern="org.eclipse.(emf|emf.sdk|xsd|xsd.sdk|emf.ecore.sdo|emf.ecore.sdo.sdk)$" Thus, EMF contributes 6 "main" features:
And 7 "enabling" features:
# pattern to use when searching for features to include in coordsite; defaults to ".*eclipse/features/org.eclipse..*(${subprojectName}|${subprojectName}.sdk)_.*\/$" coordsiteFeaturePattern=".*eclipse/features/org.eclipse.(emf.ocl|ocl.all|ocl.all.sdk|ocl|ocl.uml)_.*\/$" coordsiteMainFeaturePattern="org.eclipse.ocl.(all|all.sdk)" To create aggregate features, such as EMF Transaction does to bundle up EMF Query, EMF Validation, and EMF Transaction into a single "emfqtv.all.sdk" feature: # pattern to use when searching for features to include in coordsite; defaults to ".*eclipse/features/org.eclipse..*(${subprojectName}|${subprojectName}.sdk)_.*\/$" #omit SDK because this is only to create a temp file which will be combined w/ rest of QTV components coordsiteFeaturePattern=".*eclipse/features/org.eclipse.emf.(emfqtv.all|emfqtv.all.sdk|query|query.ocl|validation|validation.ocl|transaction|workspace)_.*\/$" coordsiteMainFeaturePattern="org.eclipse.emf.emfqtv.(all|all.sdk)" Then, in the EMF Validation (and EMF Query) properties files: # pattern to use when searching for features to include in coordsite; defaults to ".*eclipse/features/org.eclipse..*(${subprojectName}|${subprojectName}.sdk)_.*\/$" #omit SDK because this is only to create a temp file which will be combined w/ rest of QTV components coordsiteFeaturePattern=".*eclipse/features/org.eclipse.emf.(validation|validation.ocl)_.*\/$" coordsiteMainFeaturePattern="NONE" |
See Troubleshooting.
Generating Release Notes
Generating release notes is easy - promoteToEclipse.sh does it for you! However, there are a few simple steps to follow to ensure the generated content is accurate & non-duplicative. Here's the general process for closing a bug and using Bugzilla & CVS to provide the information required to generate release notes.
- Working in Eclipse, fix your code. Test is as much as possible before committing it to CVS.
- Commit your change(s) to CVS, using the bug's number in square brackets to begin your commit comment, eg:
[127509] javadocs now available
- If you use Mylyn you can use this template, with a space at the end:
- Note that you can include multiple bugs (each number on its own line) and comments are not required. The information that will appear in the release notes comes from the bug's Summary field, not your CVS comments.
- Browse to the bug's webpage, and assign it the status Assigned. Your bugzilla comment could be something like:
Committed to CVS
- Tip: to save time, you can create & save a named Bugzilla query for All Assigned, in order to quickly Change Several Bugs At Once.
- Produce a build, and promote it. Unless you use the -norss flag:
- Your RSS feed will be updated,
- The Modeling database will see that new entry,
- A corresponding entry will be added to the Releases table, and
- A refresh of the release notes will now show that new entry.
My new build isn't listed on the website!
Mirror replication takes time. Please try again in 30 mins, or re-read your promote log to verify everything went OK.
My new build isn't listed in the Release Notes!
First, check your RSS feed file to ensure it's been updated. If it hasn't, check your promote log for failures in updating the feed. If it has, please be patient and wait for the next database update. Your RSS feed file controls the list of releases that are imported into the Releases table of the Search CVS database, and thus appear on the Release Notes page.
There are three rules to consider when building, naming, and publishing maintenance builds:
- If you've branched, you need to tell the build system (and thus the RSS feed generator). Maintenance builds from HEAD are ok, but may confuse the database if you try to branch during a release rather than immediately afterwards. Branching right after your 1.0 release is recommended.
- Maintenance builds on, say, 1.0.0 MUST BE VERSIONED to 1.0.1, 1.0.2: if 1.0.0 has already been released, everything since must be > 1.0.
- Maintenance builds should NOT use an alias of "1.0.0"; they should simply default to MyyyymmddHHMM. You can only have ONE unique "1.0.0" in the database.
There are errors in my release notes! How do I edit?
If you want to remove or edit values in your RSS feed and flush old/incorrect values from the database, please edit the file /cvsroot/org.eclipse/www/modeling/projectName/feeds/builds-componentName.xml (eg., projectName = emft; componentName = teneo). When done, send an email to User:nickb requesting a database flush for your component's releases.
Bugs are missing from the Release Notes!
Database updates can take a while. If it's been 24hrs and you *still* are missing data, contact User:nickb.
RSS Update Errors When Promoting
Problem | Solution |
addEntry: [AddEntry] [Fatal Error] builds-teneo.xml:13:2: The content of elements must consist of well-formed character data or markup. [AddEntry] org.xml.sax.SAXParseException: The content of elements must consist of well-formed character data or markup. |
Check the file on the build server in /var/www/html/emft/feeds/. Is it corrupt? Is it full of invalid XML due to a CVS update/merge? If so, so the following:
cd /var/www/html/emft/feeds/; \ rm -f builds-projectName.xml; \ cvs up -Pd; \ chmod 664 builds-projectName.xml; \ chgrp www builds-projectName.xml; Then rerun your promote using the -rssonly flag to redo that single step. After that, you can force an update of the database - including loading any new CVS commits - with the -searchcvsonly flag. If you don't need to refresh commits, just the Releases table, you can run this (on emft.eclipse.org only): cd /shared/modeling/searchcvs; \ php relupdate.php -noheat |
Permission denied |
Check the file on the build server in /var/www/html/emft/feeds/. Is it writable by you or one of the groups of which you're a member? Try this:
cd /var/www/html/emft/feeds/; \ ls -la; groups; \ chmod 664 *; chgrp www *; Then rerun your promote using the -rssonly flag to redo that single step. After that, you can force an update of the database - including loading any new CVS commits - with the -searchcvsonly flag. If you don't need to refresh commits, just the Releases table, you can run this (on emft.eclipse.org only): cd /shared/modeling/searchcvs; \ php relupdate.php -noheat |
Automated 'Fix available in ...' Bugzilla Comments
As of 2008-01-21, you can use promo.php or the -bugzonly flag to automatically move your RESOLVED:FIXED bugs to VERIFIED:FIXED, and place a comment stating in which build & branch the bug was fixed. See also bug 206558, bug 191571.
If you prefer, you can enable this step to happen automatically with every promoted build using these parameters in your promoteToEclipse.*.properties file
# do search cvs / release notes database update - 1 = do, 0 = skip searchCVS=1 # how long to block before giving up (in seconds, eg., 1200 for 20 mins wait) searchCVSTimeout=1200 #automatically move bugzillas from RESOLVED:FIXED to VERIFIED:FIXED - 1 = do, 0 = skip bugz=1 # check for the existence of the new build in the release notes database # before trying to close bugs - 1 = do, 0 = skip checkReleaseExists=1 |
Setup / Troubleshooting
The first time you use this option, or if your bugzilla cookie expires, you will receive an error like this:
[promote] ERROR: login cannot be read from ~/.ssh/UpdateBugStateTask.properties. |
If your cookie expires (and one day, it will), you'll see this:
[UpdateBugState] Could not use your login/logincookie credentials to log in. [UpdateBugState] Bugzilla replied: "I need a legitimate login and password to continue." |
To regenerate credentials / cookie information, log in to the build server and run:
cd /home/www-data/build/modeling/scripts; ./bugzillaLogin.sh |
If you pipe the command's syserr directly to your UpdateBugStateTask.properties file, you won't have to copy & paste (as per the directions in the script).
cd /home/www-data/build/modeling/scripts; ./bugzillaLogin.sh 2> ~/.ssh/UpdateBugStateTask.properties |
Newsgroup Announcement Setup
Setup for posting automatically to the newsgroup to announce new builds is easy.
- 1. Copy newsgroup-post.txt into your ~/.ssh folder.
build_id@build_server:~ $ mkdir -p ~/.ssh; cp /home/nickb/newsgroup-post/newsgroup-post.txt ~/.ssh
You are now set up to post automatically to the newsgroup while promoting a build. If you want to post as a specific person, rather than the default name & email, there are two additional steps.
- 2. Edit org.eclipse.emft/releng/[subproject]/promoteToEclipse.[subproject].properties <example>, placing the correct name and email address for the person whose name will appear on newsgroup posts. This step - and the next one - is ONLY required if the name & email are not the same as the default value recorded here.
newsgroupPublisherEmail="John Q. Committer <email@example.com>"
- 3. Copy org.eclipse.emft/releng/[subproject]/promoteToEclipse.[subproject].properties <example> into /home/www-data/build/emft/scripts.
To announce a build that's already been built, you can use the -announceonly flag to skip all other steps and ONLY post to the newsgroup. Otherwise, adding -announce when promoting will add the extra step of posting a quick note to the newsgroup.
Newsgroup Post Threading
Should you want to thread your announcements so that they can be hidden or categorized, here's how you can do so:
- create the parent thread into which subsequent posts will go (just post a message to the newsgroup), then
- get the post's Message-ID (using Thunderbird, just turn on all headers to see this), and
- update the appropriate entry in your /home/www-data/build/modeling/scripts/promoteToEclipse.*.properties file on your build server (emf.torolab or emft.eclipse).
Looking at promoteToEclipse.jet.properties as an example:
# publisher of newsgroup announcements newsgroupPublisherEmail="John Q. Committer <email@example.com>" newsgroup=eclipse.technology.emft # to thread posts under an existing post (or posts) enter the slash-escaped Message-ID for which this is a reply, # eg: <e0i2gc\$an5\$firstname.lastname@example.com> newsgroupThreadReferences=""
If you put the Message-ID in the newsgroupThreadReferences property, announcements about builds will be nested under that existing message.
Note that to edit this file you must sudo to the web user:
- On emf.toro: sudo -u www-data vi promoteToEclipse.jet.properties
- On emft.eclipse: sudo -u apache vi promoteToEclipse.cdo.properties
If you'd like to store a copy of your changes in CVS, please contact your releng manager so that your changes can be committed into your releng module for safekeeping/versioning.
SSH Key Setup
Getting Access
You must have ssh access to your build server, download1.eclipse.org, and dev.eclipse.org. If you do not have access, please contact the administrators of these servers to gain access. You need a full login shell (eg., bash), not just a CVS login shell (cvssh). If you cannot ssh into dev.eclipse.org or download1.eclipse.org, please open a bug asking for a full login shell, eg., bug 206146.
To get access to your build server, you must forward your static IP address to the server's administrator. If you do not have a static IP, you can set up your router to broadcast your IP to a domain name registration service like dyndns.org and provide your domain name for access to the build server.
Once you have ssh access, you need to set up limited ssh key access between your build server and the eclipse.org download and cvs servers. This will allow you to run the promote script without being prompted for a password periodically.
Connecting in
To grant yourself ssh access from your build server to eclipse.org, ssh to the build server normally.
Under windows, you can use cygwin or PuTTY. Under Linux, open a shell and type `ssh`.
Generating private and public SSH keys
If you don't already have an ssh key pair created, you will need to generate one.
- build_id@build_server:~ $ mkdir -p ~/.ssh; chmod 700 ~/.ssh; cd ~/.ssh; ssh-keygen -b 2048 -t rsa
When prompted for a passphrase, hit enter to skip. Having a passphrase, while more secure than having no passphrase, prevents automated login.
Save your public key in the default place: ~/.ssh/id_rsa.pub.
Then, you have to create the authorized_keys file and append to it your public key :
- build_id@build_server:~/.ssh $ touch ~/.ssh/authorized_keys;
- build_id@build_server:~/.ssh $ cat ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys;
Connecting out: authorizing remote hosts to let you in
To copy your local public key to the remote machine, you will need to scp (secure copy) the file. From the build server, copy the file to the remote server, then ssh to that server and combine the new key with the any existing keys in the authorized_keys file. In most cases, build_id == eclipse_id, eg., jlescot == jlescot:
Note that if you have not created yet the .ssh folder on the dev.eclipse.org server, you first need to achieve it using the following instructions :
- build_id@build_server:~/.ssh $ ssh firstname.lastname@example.com
- firstname.lastname@example.com:~ $ mkdir -p ~/.ssh; chmod 700 ~/.ssh;
- email@example.com:~/.ssh $ exit
Then you can execute the following scp command :
- build_id@build_server:~/.ssh $ scp id_rsa.pub firstname.lastname@example.com:~/.ssh/eclipse_id.temp
- build_id@build_server:~/.ssh $ ssh firstname.lastname@example.com
- (you will still be prompted for a password when connecting)
- firstname.lastname@example.com:~ $ cd ~/.ssh;
- firstname.lastname@example.com:~/.ssh $ touch ~/.ssh/authorized_keys ~/.ssh/known_hosts;
- firstname.lastname@example.com:~/.ssh $ cp ~/.ssh/authorized_keys ~/.ssh/authorized_keys_old; # backup
- firstname.lastname@example.com:~/.ssh $ cat ~/.ssh/eclipse_id.temp ~/.ssh/authorized_keys_old > ~/.ssh/authorized_keys; # prepend new key into old file; save as new file
- firstname.lastname@example.com:~/.ssh $ rm -fr ~/.ssh/eclipse_id.temp ~/.ssh/authorized_keys_old;
- email@example.com:~/.ssh $ chmod 644 authorized_keys id_rsa.pub known_hosts; chmod 600 id_rsa; # fix perms
- firstname.lastname@example.com:~/.ssh $ exit
- build_id@build_server:~/.ssh $ ssh firstname.lastname@example.com
- (this time you should get in using your key instead of needing a password)
Once you have ~/.ssh/authorized_keys and ~/.ssh/known_hosts updated with your public key and server fingerprint(s) (respectively), you should be able to connect to these systems without being prompted, and the promote script should be good to go unassisted.
Connecting out: creating host keys
SSH to your build server (if not already there). Then, one by one, ssh from there to these target systems, accepting whatever yes/no questions are posed about host keys or IP addresses. Once in, exit
back to your build server. In most cases, build_id == eclipse_id, eg., jlescot == jlescot:
- build_id@FQDN, build_id@localhost,
- email@example.com, email@example.com
For example:
ssh email@example.com exit ssh jlescot@localhost exit ssh email@example.com [publishing build folder, zips, and javadoc] exit ssh email@example.com [CVS access] exit ssh firstname.lastname@example.com [jar signing and update site generation] exit |
All of those should work without being prompted for a password. If you are prompted, you need to set an ssh key in your ~/.ssh/authorized_keys file for each user & hostname pair to which you want to connect. The first time you try each of these connections, you should be be prompted to add the host's fingerprint to your ~/.ssh/known_hosts file. This is also required.
Connecting the web user to your account
In order to run builds from the web site on the build server, the web user (apache or www-data) must be able to ssh to your account on the build server. Put its public key in your authorized_keys file to make this work.
If you require further assistance setting up key access, try here: http://cfm.gs.washington.edu/security/ssh/client-pkauth/.
Promotion FAQ
Many things can go wrong when promoting a build (CVS or SCP errors, artifacts not created, java failures). Most are a result of network or permission problems, and can be fixed by trying again or correcting the permission problem.
RSS Feeds
The log file for my promoted build shows a FileNotFoundException (Permission denied), NullPointerException, or SAXParseException when publishing my RSS feed!
Either the permissions on the file do not allow you to edit it...
Buildfile: feedPublish.xml publishFeed: addEntry: [AddEntry] java.io.FileNotFoundException: /var/www/html/modeling/emft/feeds/builds-net4j.xml (Permission denied)
... or your file has been corrupted by a CVS merge/update, and contains "<<<<<<<" and "=======" which makes it an invalid XML file.
addEntry: [AddEntry] [Fatal Error] builds-gef.xml:7:2: The content of elements must consist of well-formed character data or markup. [AddEntry] org.xml.sax.SAXParseException: The content of elements must consist of well-formed character data or markup. [AddEntry] at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:264)
To fix this, delete the file on filesystem, refresh from cvs & redo the promote. See also bug 254645
Here's how:
$ cd /var/www/html/modeling/mdt/feeds/ $ less builds-uml2.xml (note the <<<<<<<<<<<<< and =============== markers that the cvs server added) $ rm -fr builds-uml2.xml $ cvs up builds-uml2.xml cvs update: warning: `builds-uml2.xml' was lost U builds-uml2.xml $ chmod g+w builds-uml2.xml $ chgrp www builds-uml2.xml
Then rerun the promote to fix the missing feed entry (required for release notes)...
./promoteToEclipse.sh -sub uml2 -Q -buildID somebuildID -rssonly -cvsbranch somebranchvalue ...
If you decide to repromote completely using the web UI, make sure you've removed this build's site*.xml contribution because a full promote will add it again, slowing down the operation of the update site and presenting users with confusing duplicate entries.
Finally, since the RSS is now updated, you can force the database to be refreshed and have the new release appear in your Release Notes.
Update Site
Please check your promote logs for errors or transient glitches, like CVS disconnects or SCP problems. Sometimes one problem can manifest as several problems, as in the case of this EMFT Validation build's UM jar creation, which threw four warnings that something had gone wrong, all starting from a transient CVS checkout problem (bandwidth overload or connection reset).
[promote] [9] [13:53:18] Create & promote Update Manager jars: [promote] Running buildUpdate.sh:
[umj-co] [1] Checking out org.eclipse.releng.basebuilder from dev using HEAD cvs checkout: failed to open /home/vramaswamy/.cvspass for reading: No such file or directory cvs [checkout aborted]: recv() from server dev.eclipse.org: Connection reset by peer
The java class is not found: org/eclipse/core/launcher/Main features/*.jar: No such file or directory plugins/*.jar: No such file or directory
[umj] [7d] [13:54:47] Comparing local and remote folders MD5 sums to ensure SCP completeness...
[compare] Compare md5sums... [compare] MD5s do not match! Compare failed.
[umj] [13:54:52] ERROR! Script exiting from compareFolders.sh [promote] [9] [13:54:52] Create & promote Update Manager jars done.
In this case, the problems were:
- CVS disconnected while checking out required builder code
- Build failed looking for Eclipse Main, so no build occurred
- Copying files from temp to /var/www/technology/emft/updates/ failed as they were not created
- MD5 check failed as nothing was copied to download1.eclipse.org
In this case, the solution was to:
- Verify that nothing had been produced on either the build server or download1.eclipse.org.
- Confirm that site*.xml had not been changed in CVS, and rollback any changes for this build's ID (if any).
- Re-run the promote using the -jarsonly flag in order to bypass all the steps that completed successfully and ONLY do the UM jar creation step.


text:
MIT Builds A Needle-Free Drug Injector
The needle and syringe are icons of modern medicine.
But a device developed at MIT to squirt medicines quickly and pretty much painlessly through the skin suggests that the future of medicine could be needle-free.
The idea is to shoot an extremely thin, extremely fast jet of medicine straight through skin and into muscle. "It's sort of like a laser beam," project leader and mechanical engineering professor Ian Hunter tells Shots.
But because the jet is so thin — he compares it to a mosquito's proboscis — it's unlikely to produce much pain. Details of the prototype are published in the journal Medical Engineering and Physics.
Needles, as we all know, can be quite painful, and it's estimated that at least 10 percent of the population has needle phobia. There's also the risk of accidental jabs, which can spread disease. Jet injections could avoid these problems.
Jet injection technology has been around for quite a while. It's been used in mechanical devices for more than a century (think of a car's fuel injector), and was first used to deliver vaccines in the 1960s. The technology even showed up on Star Trek as "hypospray." Nor is it the only needle-free alternative in the works for vaccines and other medicines.
But Hunter says this device has big advantages, thanks to some 21st-century technology.
Existing medical jet injectors use a spring or other mechanical method to force liquid out. All the medicine comes rushing out at once, at a fixed speed and pressure. It gets the job done, but it's not very precise. The diameter of the jets also tends to be several times bigger than those from Hunter's device, causing more pain and raising the risk of infection.
Hunter's injector uses a piston made from a coil of wire wrapped around a magnet. A computer chip calls the shots for the injection, so to speak, allowing for millisecond-by-millisecond control over the speed and pressure of the jet.
Once the skin is penetrated with a quick burst, the injector can back off a bit to deliver a precise quantity of the drug, exactly where it's needed.
"I think that's the big difference between this device and other devices, is the degree of precision," Hunter says. "We have a degree of control that hasn't been possible before."
The new injector has yet to be tested on people, but has been used on animals, like sheep, without apparent discomfort. "The sheep did not seem to even be aware that they were being injected," Hunter says. But it will be a few years yet before the injector could be ready for use at home or in a hospital near you.
In the meantime, Hunter's team will work on additional features that take advantage of the injector's built-in computer. They want to combine it with a separate device that can sense the thickness and elasticity of the patient's skin, so the injector could adjust its speed and pressure accordingly. It could also tell the difference between the patient's skin and that of the health care worker, to prevent accidental self-injections.

subset: commoncrawl


text:
"Armed pro-Russian separatists in eastern Ukraine said Friday that they were not bound by an international deal ordering them to disarm and were looking for more assurances about their security before leaving the public buildings they are holding," Reuters reports.
What's more, "the separatists' spokesman told the BBC that the Kiev government was 'illegal,' so they would not go until the Kiev government stepped down."
The Washington Post sums up the situation this way:
"The pro-Russian militants occupying the Donetsk government offices said they supported an accord signed Thursday in Geneva that seeks to calm the potential for violence in the restive region. But they said they would lay down their weapons and leave only if the new national government in Kiev steps down."
Thursday evening in Geneva, as we reported, U.S. Secretary of State John Kerry and his Russian counterpart, Sergei Lavrov, emerged from meetings with foreign ministers from Ukraine and the European Union to say the parties had agreed that all "illegal armed groups" in Ukraine should immediately lay down their weapons. Also, all "illegally seized buildings" in eastern Ukraine were to be returned to that nation's authorities.
The deal was seen as something of a breakthrough. But as Kerry cautioned, it would need to be followed by actions on the ground.
Now, the BBC notes, "a tense standoff continues in eastern Ukraine, where pro-Russian separatists — many of them armed — are occupying official buildings in at least nine cities and towns."
On Morning Edition, NPR's Soraya Sarhaddi Nelson said it doesn't appear the protesters in eastern Ukraine will be leaving those locations anytime soon. Some of them have said, she pointed out, that they want to see the demonstrators in Kiev's Maidan Square — the people whose protests led to the February collapse of Ukraine's previous, pro-Russia government — dismantle their camps first.
Copyright 2021 NPR. To see more, visit https://www.npr.org.


text:
Behind The Mic: Here's Why The 11 A.M. Newscast Was All 'Live'
We don't usually write about what happens in the NPR newsroom. That old line about not wanting to know how the sausage is made certainly applies in most cases.
But if you were tuned in at 11 a.m. ET and the newscast sounded a little different, it's because some technical gremlins got hold of the pre-recorded reports from NPR's correspondents and wouldn't let go. So, it was "live radio" time.
Which meant that this blogger got to spend a few moments on the air talking with newscaster Paul Brown about the California manhunt story. Then the real radio professionals — Dave Mattingly, Craig Windham and Korva Coleman followed. They had conversations with Paul about today's retail sales report, cyber security, and the president's climate change proposals.
It was a bit of a circus as everyone switched places at the microphone. Thankfully, there had been time to prepare notes or to grab the scripts that had been written for the reports that were stuck somewhere in our audio system.
We'll embed the audio. Hopefully, you'll think it all worked out OK in the end.
The gremlins, by the way, have disappeared. Things are back to normal now. So, this blogger's 60 seconds of radio fame have come and gone.
Update at 12:55 p.m. ET. Everbody's A Comic:
A "friend" just stopped by to say "you've got a voice for the blog."


text:
For example, tell me you don't get a brain-ache from trying to comprehend...
(Now with matching ladybug!)
You know what every caramel cheesecake needs?
Pretty much anything but large poo-swirls topped with plastic mold-specked hot dogs and hamburgers, that's what. Although I'd be lying if I said I didn't like the little surfing 'dog on the left:
C'mon, a mini hot dog riding a poo wave? What's not to love?
And lastly, check out what Amy S. got for her rehearsal dinner when she requested a simple sheet cake with a logo on it:
I don't know what that is either, Amy, but I hear the chocolate coating helps it go down easier.
Moira & Stephanie E., these cakes are inconceivable.


text:
The Shaw Prize is an international award established in 2002 to pay tribute to those who have made distinguished contributions to modern civilization. The three awards for Astronomy, Life Science and Medicine, and Mathematical Sciences will be presented on Wednesday, 28 September 2011. Each prize carries a monetary award of US$1 million.
The results will be announced at the press conference on Tuesday, 7 June in Hong Kong. Details are as follows:
Date: | Tuesday, 7 June 2011 |
Time: | 3:00 pm |
Venue: | Magnolia and Camomile Rooms, Lower Level II, Kowloon Shangri-La Hotel, 64 Mody Road, Kowloon, Hong Kong |
Attending Guests:
Professor Chen-Ning Yang | Council Member & Chairman of the Board of Adjudicators, The Shaw Prize Foundation |
Professor Kenneth Young | Council Member & Vice Chairman of the Board of Adjudicators, The Shaw Prize Foundation |
Professor Lin Ma | Council Member, The Shaw Prize Foundation |
Professor Sheung-Wai Tam | Council Member, The Shaw Prize Foundation |
You are cordially invited to attend and cover the event. For press enquiries, please contact:
Joanne Yik | Tel: 2918 0901 / 9216 3710 |
Karen Sze | Tel: 2918 0907 / 9613 4164 |
Invited by The Shaw Prize Foundation
Presented by Link-Work Communications (HK) Ltd
24 May 2011 Hong Kong