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.
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
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
Note (see attached
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.
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:
There, you can select the level of notification intrusiveness with which you want to be notified by e-mail
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:
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:
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)
Synchronize URLs of submodules:
$ git submodule sync
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?
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.
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
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:
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 (firstname.lastname@example.org) 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.