Skip to content

O
OHR Support

Gitlab migration of ohwr faq

Last edited by Erik van der Bij
Page history

Migrating to Gitlab.

Here are some of the most frequently asked questions on the new ohwr.org site.

What was communicated via e-mail? Did I miss something?

The messages sent out on Feb 7th 2019 were a note on the Gitlab migration and another for mailing list subscribers

At the final steps of the migration, ohwr.org users were informed throug the following note and subscribers to mailing lists were sent this note

Ok, what should I do after the site is migrated?

Very little. After ohwr.org comes back,

  • go to the login screen by clicking the 'Sign In/Register' button.
  • do not try to login with your current credentials: that will fail!
  • click on the 'Forgot your password?' link in the login screen. A message with a link to reset your password will be sent to your registered e-mail address.
  • that's it

What happened to mailing lists?

Maintenance of a full mailing list server proved to be extremely costly; we have reduced manpower to keep the site up. After much reflection on the best way to communicate among members of the community, we decided that setting up a discussion forum would be the best alternative. Not much is lost, as you can still receive updates via e-mail by subscribing to topics.

How can I keep being notified by ohwr.org forums ?

The topic you were subscribed to (for instance, white-rabbit-dev) is now a category within the Discourse space of https://forums.ohwr.org.

Note (see attached screenshot) the top rightmost button in the interface, right next to the 'New topic' button. You can select there the amount of notification you will get whenever something is posted in the category.

What about my mailing list subscriptions? How do I login into forums.ohwr.org?

The procedure is really similar to the one described in the above answer. Your e-mail address (the one you used to subscribe to mailing lists) will be already registered in the forums.ohwr.org system.

  • Click the 'Login' button to access the login screen.
  • There, by clicking on the 'I forgot my password' link you will get an e-mail with a password reset link.
  • That's all!

Again: what happened to my subscriptions? I want to get e-mail notifications. What should I do?

Let us imagine you want to get notifications about the category white-rabbit-dev. The steps are very simple:

What happened to my Git repository references?

Git repository reference URLs have changed, as it is not possible to keep them as they were in the former platform. This implies that you will be submitted to the (hpefully minor) inconvenience of changing remote references in your current working copies.

For example, my working copy of spec-sw has the following remotes:

$ git  remote -v
ohwr    ssh://git@ohwr.org/fmc-projects/spec/spec-sw.git (fetch)
ohwr    ssh://git@ohwr.org/fmc-projects/spec/spec-sw.git (push)
origin  git://ohwr.org/fmc-projects/spec/spec-sw.git (fetch)
origin  git://ohwr.org/fmc-projects/spec/spec-sw.git (push)

This won't work with the new ohr.org. To change them to the correct values, pick the appropriate URLs from the project page, i.e.

    ssh://git@ohwr.org:7999/project/spec-sw.git
    https://ohwr.org/project/spec-sw.git

and issue the commands

$ git remote set-url origin https://ohwr.org/project/spec-sw.git
$ git remote set-url ohwr ssh://git@ohwr.org:7999/project/spec-sw.git

Now you're set:

$ git remote -v
ohwr    ssh://git@ohwr.org:7999/project/spec-sw.git (fetch)
ohwr    ssh://git@ohwr.org:7999/project/spec-sw.git (push)
origin  https://ohwr.org/project/spec-sw.git (fetch)
origin  https://ohwr.org/project/spec-sw.git (push)

What about submodules and submodule references?

If you use submodules, you deserve what you get 😄.

More seriously, the change of repository URL risks breaking absolute submodule references. If at any commit in your repository, you have a submodule ref with one of the old URLs as address part, your build will fail.

To avoid this scenario, we have tried our best to keep mirrors of the old repositories at the same URLs as before. These are read-only, non-pushable, volatile copies that are kept for backward compatibility of submodule references only. They are accessible ONLY via HTTPS for the time being (we are looking into having access to these repos via GIT as well). If you have your submodules accessible via GIT (e.g. git://ohwr.org/hdl-core-lib/wr-cores.git), you will need to change this path to use HTTPS.

This is the least horrible way we have found till now to keep unbroken builds in case old repository URLs (and commits) are referenced. In particular, remote URLs with intermediate path components other than /project/ are certain to be invalid for any other purpose than the uses former submodule references gave to them.

If this sounds terrible, it is, but the sentence at the beginning says it all. Below are 3 simple steps to update URLs to the submodules and have your project working fine again:

  1. In the top folder of your repository with submodules, edit manually the file .gitmodules updating the URLs (for each submodule project, see what is the new HTTPS URL)
  2. Synchronize URLs of submodules:
$ git submodule sync
  1. add and commit the change
$ git add .gitmodules
$ git commit -m "update of submodule URLs after OHWR migration"

When cloning repository or submodule, I get error "fatal: unable to access 'https://[...]: gnutls_handshake() failed: Handshake failed"

You might experience this problem when using old version of GIT and trying to access ohwr.org repository via HTTPS. If this happens, you need to update your git version. We experienced this problem with git 1.9.1 while all works fine with 2.7.4.

My project looks weird and empty. Where's my stuff?

First of all, check the URL. After the migration, the hierarchical URLs of the old site were flattened. So, your project URL should look like https://ohwr.org/project/fmc-adc-400k18b4cha-iso and not like https://ohwr.org/fmc-projects/fmc-adc-400k18b4cha-iso with hierarchical information in the middle.

The first URL is the correct one, and your project and stuff is there, alive and kicking. The latter, although is an existent URL/project, is there only to keep old submodule URLs, and might eventually disappear.

When editing a wiki page, my attempt at attaching a file is rejected with a Forbidden 403 try again or another file error. What can I do?

This is a nasty one that we get quite often. There are different things you can try, and we're sorry that we have not yet found a sure way yet.

1. Try logging in to ohwr.org instead of www.ohwr.org

I was logged in at www.ohwr.org and there it failed. I revoked all sessions, went out of the browser, went back and it still failed.

Then I logged in to ohwr.org, not www.ohwr.org and it works like a charm!

2. Try removing old active sessions and authentication tokens

This is a bug related to authentication tokens in the framework that the current Gitlab version is based on. For the full technical story, you may visit issue 253. But to get this fixed for you, try the following first:

  • visit your account settings | active sessions page. If the link does not work for you, just click in the top right icon (i.e., the one with your avatar image), select 'Settings' in the dropdown list, then click the 'Active Sessions' link in the left bar
  • the list of all your active sessions is shown, with a red 'Revoke' button for each, except the current one
  • go ahead and revoke them all, by clicking in all the red buttons
  • once this is done, log out of your session, and log in again

If this procedure fixes the problem for you, congratulations.

3. Upload your file with a Python script

If nothing of the above worked, a workaround is still possible. You will use a Python script that uploads a file by talking directly to ohwr.org via its API, thus bypassing the web interface. You will need a Python installation with the requests package installed.

The attach script is quoted in the comment to issue 253 that introduces this technique. It requires you to provide a so-called personal access token, which is simply a cryptographic key that identifies you to the server, allowing you to make API calls.

Generate one (if you still do not have it) at Settings | Personal Access Tokens (again, under your avatar icon at the top right). Ensure that you check the api checkbox on the type of token. You will obtain some jimbo-jumbo like

  gZHNjZGV2ICAgICAzIE1he

In the attach script, replace the garbage in the line

  pat = '$%$%^$%%^#$%^$%'

by your actual token:

  pat = 'gZHNjZGV2ICAgICAzIE1he'

and you're good to go. Now you can run the script as follows:

  $ ./attach https://ohwr.org/project/ohr-support/wikis/<your-project-wiki-name-here> my-file-to-attach

and paste the text that the program prints in your wiki page to link to the just attached file.

This must work, as it does not rely on the clever authentication verification of Ruby on Rails.

4. Ask the maintainers to reboot the GitLab server

For some users, the issue seems to be more persistent. The next step would be to ask the maintainers (ohwr-support@cern.ch) a restart of the Gitlab server; this drastic action seems to have cured the problem of some users. Although this cannot be done on a regular basis, it is worth trying if the above recipe did not work.

Files