Community
Participate
Working Groups
We need a place to host a git repository and a directory on downloads for sharing the CBI build for the Eclipse platform. 1) Git repository We have decided to share the work we have done for the CBI Eclipse platform build under an open source license (EDL). Making this work public now makes sense. It's going to take time to push everything upstream to the Eclipse platform repositories. In the meantime, we need a repository we can push to that will allow public read-only access. Only Thanh Ha, Igor Federenko, and Andrew Ross need write/commit access for now. We'll request others as the need arises. 2) Downloads We're building packages based on the CBI Eclipse platform build. We need a place to share them from to encourage people to test and report bugs.
I thought about this a bit more. Rather than initialize a new repository and push the repository and submodules to it, I think the easiest way to do this would be to simply copy the git repository from Igor's directory as it is today. dev.eclipse.org:/home/data/users/cbi/platform-aggregator.git
> 1) Git repository Your repository is at git.eclipse.org/gitroot/cbi/platform-aggregator.git. Browse: http://git.eclipse.org/c/cbi/platform-aggregator.git/ Clone URLs: git://git.eclipse.org/gitroot/cbi/platform-aggregator.git ssh://git.eclipse.org/gitroot/cbi/platform-aggregator.git http(s)://git.eclipse.org/gitroot/cbi/platform-aggregator.git > 2) Downloads You have space on download.eclipse.org/cbi. Please use an SSH-enabled client, such as SFTP or SCP to upload your files. Important: since download.eclipse.org is mirrored worldwide, please do not link directly to files on http://download.eclipse.org/cbi/ Instead, use the mirror script. More information: http://wiki.eclipse.org/IT_Infrastructure_Doc#Downloads
FWIW, to keep things simple, the git repo and the downloads space are owned by the existing 'foundation.cbi' group that we've been using.
I tried checking out the new public branch. While the branch itself works. The submodules don't. We'll need to move all the submodules over as well to the new site. Specific Submodules from .gitmodules below: [submodule "eclipse.jdt"] path = eclipse.jdt url = ../eclipse.jdt [submodule "eclipse.jdt.core"] path = eclipse.jdt.core url = ../eclipse.jdt.core [submodule "eclipse.jdt.core.binaries"] path = eclipse.jdt.core.binaries url = ../eclipse.jdt.core.binaries [submodule "eclipse.jdt.debug"] path = eclipse.jdt.debug url = ../eclipse.jdt.debug [submodule "eclipse.jdt.ui"] path = eclipse.jdt.ui url = ../eclipse.jdt.ui [submodule "eclipse.pde"] path = eclipse.pde url = ../eclipse.pde [submodule "eclipse.pde.build"] path = eclipse.pde.build url = ../eclipse.pde.build [submodule "eclipse.pde.ui"] path = eclipse.pde.ui url = ../eclipse.pde.ui [submodule "eclipse.platform"] path = eclipse.platform url = ../eclipse.platform [submodule "eclipse.platform.common"] path = eclipse.platform.common url = ../eclipse.platform.common [submodule "eclipse.platform.debug"] path = eclipse.platform.debug url = ../eclipse.platform.debug [submodule "eclipse.platform.resources"] path = eclipse.platform.resources url = ../eclipse.platform.resources [submodule "eclipse.platform.runtime"] path = eclipse.platform.runtime url = ../eclipse.platform.runtime [submodule "eclipse.platform.team"] path = eclipse.platform.team url = ../eclipse.platform.team [submodule "eclipse.platform.text"] path = eclipse.platform.text url = ../eclipse.platform.text [submodule "eclipse.platform.ua"] path = eclipse.platform.ua url = ../eclipse.platform.ua [submodule "eclipse.platform.ui"] path = eclipse.platform.ui url = ../eclipse.platform.ui [submodule "rt.equinox.bundles"] path = rt.equinox.bundles url = ../rt.equinox.bundles [submodule "rt.equinox.framework"] path = rt.equinox.framework url = ../rt.equinox.framework [submodule "rt.equinox.p2"] path = rt.equinox.p2 url = ../rt.equinox.p2 [submodule "eclipse.platform.swt"] path = eclipse.platform.swt url = ../eclipse.platform.swt.git
I've moved all that over too. There's one directory left, and it's called natives.
The natives directory is a cached copy of swt and eclipse launchers. We need to make it publicly available too. People will need to wget -r this directory.
Well, both you guys have shell accounts on build.eclipse.org, so I'll let you guys get your feet wet and move it to the downloads area recently created.
I created a natives.zip and put it on the CBI downloads section. The new instructions should be: 1. Download natives.zip wget http://www.eclipse.org/downloads/download.php?file=/cbi/natives.zip 2. Unzip natives.zip unzip natives.zip -d /var/tmp/lts Should be tested once the mirrors are synced up.
> Should be tested once the mirrors are synced up. Just so you know, from the eclipse.org network (including the Foundation office) you will never see any mirrors, but you will see them from an outside line.
I'm unable to git push to the eclipse.jdt repository. With the following Error: % git push Counting objects: 29, done. Delta compression using up to 4 threads. Compressing objects: 100% (14/14), done. Writing objects: 100% (14/14), 2.71 KiB, done. Total 14 (delta 11), reused 0 (delta 0) error: insufficient permission for adding an object to repository database ./objects fatal: failed to write object error: unpack failed: unpack-objects abnormal exit To ssh://tha@git.eclipse.org/gitroot/cbi/eclipse.jdt ! [remote rejected] master -> master (n/a (unpacker error)) error: failed to push some refs to 'ssh://tha@git.eclipse.org/gitroot/cbi/eclipse.jdt' I've only tried with the eclipse.jdt repo so far but I bet the same issue exists on all of them. Do I have permissions to commit to these new repos?
None of these repositories were set up with sharedrepository = 1, so some group permissions are missing. I've fixed the group permissions -- please fix your repos.
Figured out how to set sharedrepository. I used the command "git repo-config core.sharedrepository true" and confirmed it's set with "cat config" on the repo. Unfortunately I'm still getting the same error with eclipse.jdt
Hi Denis, could you delete the eclipse.jdt project on the public server and reimport from Igor's original? You and I did some test commits yesterday to troubleshoot why I couldn't commit so there's extra history in the repo now and it's probably easiest to just reimport Igor's original repo for this project. Here's what I found regarding the issue though. Case 1: git clone eclipse.jdt project and modify master. git push successful. Case 2: git clone aggregator repo and modify eclipse.jdt submodule and merge the changes into master before pushing. git push fails. Case 3: git clone eclilpse.jdt project and checkout the specific commit HEAD from the submodule, then merge that into master. git push fails. Here's my understanding of git submodules. A submodule stores a reference point to a commit hash. When you rung "git submodule update" it pulls the reference point and if you do "git branch" it'll say your working no "no branch". To work on a submodule you need to "git checkout -b <new_branch>" make your changes then merge it back into master if you so desire before pushing back to upstream. Igor's modifications are actually not merged into any branches (no branch) so they are stuck to a reference point that only git submodule knows about. When I try to merge these changes into master and push this is where it fails. I'm not sure why but likely something in this none branch is preventing me from pushing.
Did some more investigation. Looks like I can commit to some repos successfully pushed to the following: - eclipse.jdt.core.binaries.git - eclipse.jdt.core.git - eclipse.jdt.debug.git - eclipse.jdt.ui.git I wasn't able to commit to these ones: - eclipse.jdt.git - platform-aggregator.git After poking around a bit more I think the issue really is permissions. For example in the objects directory of platform-aggregator.git we had some directories with the wrong group. Such as: drwxrwsr-x+ 2 ifedorenk common 4096 2011-12-15 11:37 b5 In the case eclipse.jdt.git the directories in objects have the correct permissions / group assigned but a few files inside the directories have read only permissions. For example: ef: total 4 -r--r--r-- 1 tha foundation.cbi 192 2012-02-29 16:22 4d0d49bfcd3793d46fd643a4f4055ec32bfabe
(In reply to comment #14) > After poking around a bit more I think the issue really is permissions. For > example in the objects directory of platform-aggregator.git we had some > directories with the wrong group. Such as: > > drwxrwsr-x+ 2 ifedorenk common 4096 2011-12-15 11:37 b5 I've reset all the group ownership to foundation.cbi on the entire tree. > > > In the case eclipse.jdt.git the directories in objects have the correct > permissions / group assigned but a few files inside the directories have read > only permissions. For example: > > ef: > total 4 > -r--r--r-- 1 tha foundation.cbi 192 2012-02-29 16:22 > 4d0d49bfcd3793d46fd643a4f4055ec32bfabe I think this is intentional, and how git operates. Once a hash is put in the repo, it should never be modified. All of our git repos have similar read-only objects.
> Hi Denis, could you delete the eclipse.jdt project on the public server and > reimport from Igor's original? I don't have Igor's original anymore. I had moved the repos out of /home/data/users/cbi and into the public gitroot. We don't have this on our backup sets either, since we don't back up user home directories... Can't you just revert/delete those two commits?
(In reply to comment #16) > > Hi Denis, could you delete the eclipse.jdt project on the public server and > > reimport from Igor's original? > > I don't have Igor's original anymore. I had moved the repos out of > /home/data/users/cbi and into the public gitroot. > > We don't have this on our backup sets either, since we don't back up user home > directories... Can't you just revert/delete those two commits? Sure we can do that.
(In reply to comment #15) > (In reply to comment #14) > > After poking around a bit more I think the issue really is permissions. For > > example in the objects directory of platform-aggregator.git we had some > > directories with the wrong group. Such as: > > > > drwxrwsr-x+ 2 ifedorenk common 4096 2011-12-15 11:37 b5 > > I've reset all the group ownership to foundation.cbi on the entire tree. > > > > > > > In the case eclipse.jdt.git the directories in objects have the correct > > permissions / group assigned but a few files inside the directories have read > > only permissions. For example: > > > > ef: > > total 4 > > -r--r--r-- 1 tha foundation.cbi 192 2012-02-29 16:22 > > 4d0d49bfcd3793d46fd643a4f4055ec32bfabe > > > I think this is intentional, and how git operates. Once a hash is put in the > repo, it should never be modified. All of our git repos have similar read-only > objects. Ok that's strange then because I still cannot commit to some repos. I've tested all of them now and only the following are giving me the permissions error: - eclipse.platform - eclipse.platform.common - eclipse.platform.resources - eclipse.platform.runtime - eclipse.platform.swt - eclipse.platform.text - platform-aggregator The good news is whatever you did to the eclipse.jdk seems to have worked. I was able to successfully commit to that repo. Maybe if you redid that on the other repos I listed above it'll work.
> The good news is whatever you did to the eclipse.jdk seems to have worked. I > was able to successfully commit to that repo. Maybe if you redid that on the > other repos I listed above it'll work. In the interest of sending you on your way, I've done this to the entire cbi directory: dev1:/gitroot/cbi # chgrp foundation.cbi * -R dev1:/gitroot/cbi # find . -type d -exec chmod u+w,g+ws {} \; dev1:/gitroot/cbi # find . -type f -exec chmod u+w,g+w {} \; I haven't had to do that to any of the other git repos on our server, so there must be something peculiar with what you're doing.
(In reply to comment #19) > > The good news is whatever you did to the eclipse.jdk seems to have worked. I > > was able to successfully commit to that repo. Maybe if you redid that on the > > other repos I listed above it'll work. > > In the interest of sending you on your way, I've done this to the entire cbi > directory: > > dev1:/gitroot/cbi # chgrp foundation.cbi * -R > dev1:/gitroot/cbi # find . -type d -exec chmod u+w,g+ws {} \; > dev1:/gitroot/cbi # find . -type f -exec chmod u+w,g+w {} \; > > > I haven't had to do that to any of the other git repos on our server, so there > must be something peculiar with what you're doing. Unfortunately that didn't fix it I'm still unable to push to the repos. Here is the workflow I've been using: For example updating eclipse.platform 1. git clone ssh://tha@git.eclipse.org/gitroot/cbi/eclipse.platform.git 2. git checkout tycho-monolith-build 3. make some changes and git commit 4. git push origin tycho-monolith-build
Andrew had a suggestion of maybe setting my user as the owner of the repositories to see if that changes anything.
Can you paste the push error?
(In reply to comment #22) > Can you paste the push error? % git push origin tycho-monolith-build Counting objects: 70, done. Delta compression using up to 4 threads. Compressing objects: 100% (36/36), done. Writing objects: 100% (36/36), 3.73 KiB, done. Total 36 (delta 32), reused 0 (delta 0) error: insufficient permission for adding an object to repository database ./objects fatal: failed to write object error: unpack failed: unpack-objects abnormal exit To ssh://tha@git.eclipse.org/gitroot/cbi/eclipse.platform ! [remote rejected] tycho-monolith-build -> tycho-monolith-build (n/a (unpacker error)) error: failed to push some refs to 'ssh://tha@git.eclipse.org/gitroot/cbi/eclipse.platform'
> fatal: failed to write object > error: unpack failed: unpack-objects abnormal exit > To ssh://tha@git.eclipse.org/gitroot/cbi/eclipse.platform > ! [remote rejected] tycho-monolith-build -> tycho-monolith-build (n/a > (unpacker error)) > error: failed to push some refs to I think it specifically has a problem with the tycho-monolith-build branch, but I've made you the owner of everything. Go nuts!
$ git clone ssh://droy@git.eclipse.org/gitroot/cbi/eclipse.platform.git Cloning into 'eclipse.platform'... remote: Counting objects: 116478, done. remote: Compressing objects: 100% (23335/23335), done. remote: Total 116478 (delta 60499), reused 116189 (delta 60367) Receiving objects: 100% (116478/116478), 35.59 MiB | 711 KiB/s, done. Resolving deltas: 100% (60499/60499), done. $ cd eclipse.platform/ $ git checkout tycho-monolith-build Branch tycho-monolith-build set up to track remote branch tycho-monolith-build from origin. Switched to a new branch 'tycho-monolith-build' $ ls -l total 16 drwxrwsr-x. 7 toofast root 4096 Mar 1 2012 ant drwxrwsr-x. 4 toofast root 4096 Mar 1 2012 platform -rw-rw-r--. 1 toofast root 1404 Mar 1 2012 pom.xml drwxrwsr-x. 13 toofast root 4096 Mar 1 2012 update $ vi pom.xml $ git commit pom.xml $ git push origin tycho-monolith-build Counting objects: 5, done. [snip] 469c59d..b1104f0 tycho-monolith-build -> tycho-monolith-build And on the server: dev1:/gitroot/cbi/eclipse.platform.git/objects # find . -user droy -ls 4785735 4 -r--r--r-- 1 droy foundation.cbi 179 Mar 1 19:32 ./3c/44a48a92b63cab2fcebc10ff4ee1600e0a9898 4794009 4 -r--r--r-- 1 droy foundation.cbi 173 Mar 1 19:32 ./b1/104f0d5db7a7bcc750b4a5d3599a57f7df7eb8 4794010 4 -r--r--r-- 1 droy foundation.cbi 449 Mar 1 19:32 ./87/1ea495fe758d0e90e6805e0ee7b0f575d7a95f What version of git are you using?
I' using git version 1.7.7 I was able to push to the 7 repos this morning so I guess we're good to go.
What did you do anything to solve this?
No, I assume you setting me as owner may have done it.
Igor is now seeing this same issue as I did when he tries to push to platform-aggregator.git He's likely affected with the same repos that were problematic to me: - eclipse.platform - eclipse.platform.common - eclipse.platform.resources - eclipse.platform.runtime - eclipse.platform.swt - eclipse.platform.text - platform-aggregator
Hmmm, Igor wasn't even in the foundation.cbi group. I've added him. He will need to close all his existing SSH sessions.
Looks like Igor still can't push: Igor-Fedorenkos-MacBook-Pro:R3_platform-aggregator igor$ git pull --rebase Current branch R3_tycho-monolith-build is up to date. Igor-Fedorenkos-MacBook-Pro:R3_platform-aggregator igor$ git push origin HEAD Counting objects: 7, done. Delta compression using up to 8 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (4/4), 391 bytes, done. Total 4 (delta 2), reused 0 (delta 0) error: insufficient permission for adding an object to repository database ./objects fatal: failed to write object error: unpack failed: unpack-objects abnormal exit To ssh://ifedorenk@git.eclipse.org/gitroot/cbi/platform-aggregator.git ! [remote rejected] HEAD -> R3_tycho-monolith-build (n/a (unpacker error)) error: failed to push some refs to 'ssh://ifedorenk@git.eclipse.org/gitroot/cbi/platform-aggregator.git'
There is definitely something odd about these CBI repos. I copied the platform-aggregator.git repo as denis.git and was able to reproduce the push error. However, at the SSH shell, I am able to create files all over in the various repo/objects directories. If I chown the denis.git files to me, I am able to push. I then created a completely different container (/gitroot/z_denis) and init'ed a blank repo. I changed ownership to tha:foundation.cbi as it is on these CBI repos, and I was able to clone and push successfully. Although I haven't seen anything wrong in the config file, would you be aware of anything in these repo's configurations that could be causing us grief?
From what I can tell the configs look fine. I've been poking around today too and so far one pattern I've noticed is, of all the repositories that fail. They have a few folders in the objects folder that don't have permissions g+w. For example: drwxr-sr-x 2 tha foundation.cbi 4096 2012-02-10 11:09 e9 instead of: drwxrwsr-x 2 tha foundation.cbi 4096 2012-01-12 17:47 e5 All the ones that work fine have g+w set for every folder in the objects folder. Which is strange because core.sharedrepository=true is set so when we push these permissions should be set correctly server side and I recall you did run some commands to set all the folders in the repositories with the right permissions so I'm not sure what's causing these folders to be created without g+w. I checked my user's umask as well and it's 0002.
Actually some more thought, some of these folders were created before I started working on this project such as: drwxr-sr-x 2 tha foundation.cbi 4096 2011-12-26 22:56 cb drwxr-sr-x 2 tha foundation.cbi 4096 2012-01-06 07:12 cc Is it possible your script missed a few folder permissions?
> Actually some more thought, some of these folders were created before I started > working on this project such as: I fail to see how, but I suppose everything is possible. I re-ran the commands I typed in comment 19, and I was able to push to my bogus repo. However, running this command, it's obvious git has a mind of its own when doing file perms: dev1:/gitroot/cbi/denis.git/objects # find . -user droy -ls 4678799 4 -r--r--r-- 1 droy foundation.cbi 841 Mar 9 14:19 ./c4/8559360d17c144f6ffffd0fa65a7b7aa47ca32 4882924 4 -r--r--r-- 1 droy foundation.cbi 875 Mar 9 14:19 ./da/8e28b64db7f86db5ecd80f1f6387df185f9c84 4882877 4 -r--rw-r-- 1 droy foundation.cbi 158 Mar 9 11:46 ./b2/a61385466bc86ce7e3ca1b29a0ca471bb6d7d3 I don't know why ./b2/a61385466bc86ce7e3ca1b29a0ca471bb6d7d3 would be group-writable when all others aren't, and there's nothing different about the b2 directory. Anyway, all your repos are shared: dev1:/gitroot/cbi # find . -name 'config' -print -exec grep shared {} \; ./eclipse.platform.team.git/config sharedrepository = true ./eclipse.pde.build.git/config sharedrepository = true ./eclipse.jdt.core.git/config sharedrepository = true ./rt.equinox.p2.git/config sharedrepository = true ./rt.equinox.framework.git/config sharedrepository = true ./eclipse.platform.resources.git/config sharedrepository = true ./eclipse.platform.text.git/config sharedrepository = true ./eclipse.platform.debug.git/config sharedrepository = true ./eclipse.jdt.debug.git/config sharedrepository = true ./eclipse.platform.git/config sharedrepository = true ./eclipse.platform.ua.git/config sharedrepository = true ./eclipse.platform.swt.git/config sharedrepository = true ./eclipse.jdt.ui.git/config sharedrepository = true ./eclipse.platform.ui.git/config sharedrepository = true ./eclipse.jdt.git/config sharedrepository = true ./eclipse.jdt.core.binaries.git/config sharedrepository = true ./denis.git/config sharedrepository = true ./eclipse.platform.runtime.git/config sharedrepository = true ./platform-aggregator.git/config sharedrepository = true ./eclipse.pde.git/config sharedrepository = true ./rt.equinox.bundles.git/config sharedrepository = true ./eclipse.platform.common.git/config sharedrepository = true ./eclipse.pde.ui.git/config sharedrepository = true
I believe this bug is fixed/done.
