| Message ID | 20160526191624.GA23739@macbookair |
|---|---|
| State | New |
| Headers | show |
On Thu, May 26, 2016 at 09:16:24PM +0200, Ruben Undheim wrote: > I tried 30 seconds to figure out how to use Gerrit, but I couldn't figure out > how to login, so I rather just post here. Instructions: http://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit In short, first be logged in on osmocom.org, then go to gerrit sign-in and enter this openid url: https://osmocom.org/openid I agree that it's somewhat harder than pasting the patch into a mail, but it is achievable ;) Call again if you truly can't be bothered and I'll submit your patch for review -- this once ;) Thanks! ~Neels
> In short, first be logged in on osmocom.org, then go to gerrit sign-in and > enter this openid url: > https://osmocom.org/openid After struggling for some time I was finally able to logon and add the SSH key. I kept getting a blank window every time I tried to log in, but it worked in the end. But now I get: "Unable to negotiate with 144.76.43.76 port 29418: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1" Seems to be some compatibility issues with the SSH versions. > I agree that it's somewhat harder than pasting the patch into a mail, but it is > achievable ;) Hmm, it's probably achievable if you are planning on working on the project for some time, but for me who just want to provide a patch, it appeared to be a bit of a pain. :) I'm sure it's great when it works though! > Call again if you truly can't be bothered and I'll submit your patch for review > -- this once ;) Best regards, Ruben
> On 27 May 2016, at 21:32, Ruben Undheim <ruben.undheim@gmail.com> wrote: > >> In short, first be logged in on osmocom.org, then go to gerrit sign-in and >> enter this openid url: >> https://osmocom.org/openid > > After struggling for some time I was finally able to logon and add the SSH key. I kept > getting a blank window every time I tried to log in, but it worked in the end. > > But now I get: > > "Unable to negotiate with 144.76.43.76 port 29418: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1" > > > Seems to be some compatibility issues with the SSH versions. not yet on the main page, but if you are willing to create a .ssh/config entry Host gerrit.osmocom.org HostName gerrit.osmocom.org Port 29418 User yourusername KexAlgorithms +diffie-hellman-group1-sha1 IdentityFile ~/.ssh/id_rsa_gerrit.osmocom.org I will explore if gerrit supports more key exchange algorithms. holger
> On 27 May 2016, at 21:36, Holger Freyther <holger@freyther.de> wrote: > > > > > I will explore if gerrit supports more key exchange algorithms. That was quick. Gerrit offers to download bouncy castle when installing, just that this one version can not be downloaded anymore and I didn't find a copy of that file. *yeah* to stable urls. It seemed to work just but now I have a reason spend more time on it. holger
> On 27 May 2016, at 21:39, Holger Freyther <holger@freyther.de> wrote: > > > That was quick. Gerrit offers to download bouncy castle when installing, just that this one version can not be downloaded anymore and I didn't find a copy of that file. *yeah* to stable urls. It seemed to work just but now I have a reason spend more time on it. Can you please try again? thank you holger
> Can you please try again?
Thanks! I was able to push. As I said, it's great when it works! Since my key is
now in there, next time will be a lot easier.
Cheers
Ruben
> On 27 May 2016, at 22:11, Ruben Undheim <ruben.undheim@gmail.com> wrote: > > >> Can you please try again? > > Thanks! I was able to push. As I said, it's great when it works! Since my key is > now in there, next time will be a lot easier. yes, sorry it was not as smooth as it could have been. I will CC you on the debian package changes when merging your work into our repository. have a nice weekend holger
On Fri, May 27, 2016 at 09:32:41PM +0200, Ruben Undheim wrote: > > I agree that it's somewhat harder than pasting the patch into a mail, but it is > > achievable ;) > > Hmm, it's probably achievable if you are planning on working on the project for > some time, but for me who just want to provide a patch, it appeared to be a bit > of a pain. :) I'm sure it's great when it works though! My humble opinion for the last time: gerrit has overly complicated nearly every aspect of working on the code. The web ui is bloated and cumbersome to navigate, and every commit and push needs goofy hacks just for gerrit :( It does add handy features of tracking patches and managing reviews, yet it kind of removes the concept of patch-set grouping. Of course, the integrated jenkins build is excellent to have (though would be sufficient after pushing). I submit to the community's decision to use gerrit, and I don't think it would be worth the trouble to switch yet again (if I'm the only one moaning), but I wouldn't introduce gerrit a second time. End-Of-Rant for all eternity ;) ~Neels
> On 30 May 2016, at 12:39, Neels Hofmeyr <nhofmeyr@sysmocom.de> wrote: > > > My humble opinion for the last time: gerrit has overly complicated nearly every > aspect of working on the code. The web ui is bloated and cumbersome to > navigate, and every commit and push needs goofy hacks just for gerrit :( Can you elaborate? What are the goofy hacks? There is the sign-up (but compared to two days of SSL issues to submit emails) OpenID + username + setting ssh key is more quick? And then to download the hook to generate a Change-Id on commits? > It does add handy features of tracking patches and managing reviews, yet it > kind of removes the concept of patch-set grouping. Of course, the integrated > jenkins build is excellent to have (though would be sufficient after pushing). The main advantages for a reviewer: * I don't have to look at stuff that doesn't compile * I don't have to see if I need to download the mbox or the patch * I can easily submit the resulting change In fact reviewing has been more pleasant for me than before (besides the pain of having to wrangle with Java and doing a FreeBSD port of buck to build and debug it) > > I submit to the community's decision to use gerrit, and I don't think it would > be worth the trouble to switch yet again (if I'm the only one moaning), but I > wouldn't introduce gerrit a second time. For patch-series: Either way, sending a 40 patches en-block is not well received. This wouldn't be any better with git dump-email. ;) > End-Of-Rant for all eternity ;) Besides the smiley I think you could have been more constructive, e.g you have admin rights and shell access to the system and I have already pointed you to the "Submit Type" in the project settings. Did you have a look at it to see if for your workflow we are using the wrong "type"? In osmo-sip-connector.git I changed from cherry-oick to always merge (probably fast-forward is closer to what we want in our change history) and pushed two changes. The last patch can be seen here https://gerrit.osmocom.org/#/c/127/1. It shows "Related changes" for both of them and for the second (and probably third) it has "Submitted Together" that shows my entire "series". After +2/+1 on them I have a button called "Submit including parents". Is this closer to what you want? I have picked "Cherry Pick" as many times there is a patch series but only a few commits are actually ready to be merged. To reduce work it seemed good to accept the raisins more quickly. cheers holger
On Mon, May 30, 2016 at 01:56:08PM +0200, Holger Freyther wrote: > Can you elaborate? What are the goofy hacks? Before it was just git, now gerrit has its tag on near everything I do with the code. I wish gerrit were less visible: - add gerrit remote - two upstream repos to sync to (origin and gerrit) - gitk shows every branch twice, once for each remote - checking out a new branch is more complex; because of two remotes, one needs to use the full 'git co -b <localname> --track <remote>/<name>' instead of just 'git co -b <name>' (I could probably work with just the gerrit remote, but then I wouldn't see what our public master repositories are up to) - commit id. I can't just clone, I have to do extra cycles for each clone. - access rules = obstructed access to branches = add 'users/' to all private branches = we have scores of old branches now in a namespace we can't use anymore - elaborate command line args instead of simple pushes Things just got so much more noisy on the git end. > In fact reviewing has been more pleasant for me than before (besides the pain of having to wrangle with Java and doing a FreeBSD port of buck to build and debug it) ok, that's a good thing. My position + smiley means: I found it a hard process but it works the way it is now; I'd have liked gerrit to be less visible in the daily workflows, but whatever. If it's better for your reviewing, it's an improvement. > For patch-series: Either way, sending a 40 patches en-block is not well received. This wouldn't be any better with git dump-email. ;) It doesn't make much sense to split the IuPS dev into separate bits... The branch makes sense as a whole. This is not a typical patch submission, right? Subdividing would be artificial, but ok, can do, if that helps reviewing. > Besides the smiley I think you could have been more constructive, e.g you have admin rights and shell access to the system and I have already pointed you to the "Submit Type" in the project settings. Did you have a look at it to see if for your workflow we are using the wrong "type"? I've spent enough time on gerrit overhead. Do I have to understand this? At least I would prefer not to, to use my resources for the tasks "piling up on my desk" instead. > In osmo-sip-connector.git I changed from cherry-oick to always merge (probably fast-forward is closer to what we want in our change history) and pushed two changes. The last patch can be seen here https://gerrit.osmocom.org/#/c/127/1. yes, that kind of makes sense, but how does this work. I go to the website, reconfigure the project, submit my branch so it comes in as <type> and then configure the project back to what it was? :P What was your <type>, "always merge"? Well, as I said, I hope I don't need to explore that right now... Please confirm that I should/can just push the first handful of IuPS changes to for/master. ~Neels
> On 30 May 2016, at 18:56, Neels Hofmeyr <nhofmeyr@sysmocom.de> wrote: > > > On Mon, May 30, 2016 at 01:56:08PM +0200, Holger Freyther wrote: >> Can you elaborate? What are the goofy hacks? > > Before it was just git, now gerrit has its tag on near everything I do with the > code. I wish gerrit were less visible: > > - add gerrit remote > - two upstream repos to sync to (origin and gerrit) Do you know you can directly clone from ssh (one command)? You can also define one _remote_ and have different pull/push urls (okay would require post-clone work but maybe a script)? > - gitk shows every branch twice, once for each remote > - checking out a new branch is more complex; because of two remotes, one > needs to use the full 'git co -b <localname> --track <remote>/<name>' > instead of just 'git co -b <name>' > (I could probably work with just the gerrit remote, but then I wouldn't > see what our public master repositories are up to) > - commit id. I can't just clone, I have to do extra cycles for each clone. Okay, maybe a clone script? I assume you have one already? Yes, a small change in workflow but should be manageable? git config remote.origin.pushurl ssh://<GERRIT_HOST>:29418/<PROJECT_PATH>.git git config remote.origin.push refs/heads/*:refs/for/* git push origin imaginary script (typos..): $ cat git gerrit-clone git://git.osmocom.org/libosmocore #!/bin/sh set -e git clone $1 cd `basename $1 git` git config remote.origin.pushurl ... git config remote.origin.push.. scp .. .git/hooks echo "tada" yes, a change in muscle memory. When cloning you have to remember your gerrit username and that the repository was using gerrit. But from daily workflow it doesn't look that bad? Either way you have to make the mental decision if you push a wip branch or if you want to have review. > - access rules = obstructed access to branches = add 'users/' to all private branches > = we have scores of old branches now in a namespace we can't use anymore Then let's create one group like you did and allow everything for that group again? So one manual intervention and one can push to everything again. No issue with that. > - elaborate command line args instead of simple pushes > > Things just got so much more noisy on the git end. Can you try with the above options? Does it make more natural again? >> For patch-series: Either way, sending a 40 patches en-block is not well received. This wouldn't be any better with git dump-email. ;) > > It doesn't make much sense to split the IuPS dev into separate bits... > The branch makes sense as a whole. This is not a typical patch submission, > right? > > Subdividing would be artificial, but ok, can do, if that helps reviewing. Nobody will review 40 patches with full mental power. I didn't peek at the branch yet but I assume there are some general changes to the structure first, or adding Iu support first before using it? So start with something one can review within 30 minutes? > I've spent enough time on gerrit overhead. Do I have to understand this? At > least I would prefer not to, to use my resources for the tasks "piling up on my > desk" instead. We are stronger together. I certainly don't know everything about gerrit, I have not looked at which submit type makes the most sense for us, I picked one that looked reasonable (from allowing to pick patches of a series because we are picky). So try fast-forward only or merge or rebase if necessary. :) >> In osmo-sip-connector.git I changed from cherry-oick to always merge (probably fast-forward is closer to what we want in our change history) and pushed two changes. The last patch can be seen here https://gerrit.osmocom.org/#/c/127/1. > > yes, that kind of makes sense, but how does this work. I go to the website, > reconfigure the project, submit my branch so it comes in as <type> and then > configure the project back to what it was? :P > > What was your <type>, "always merge"? > Well, as I said, I hope I don't need to explore that right now... > > Please confirm that I should/can just push the first handful of IuPS changes to > for/master. Under Projects -> "openbsc.git" change it to "Rebase if necessary" and give it a small try (push a slightly outdated commit so we can see
On Mon, May 30, 2016 at 09:00:05PM +0200, Holger Freyther wrote: > Do you know you can directly clone from ssh (one command)? like, use the ssh shell access and then I get the hook cloned along?? > You can also define one _remote_ and have different pull/push urls (okay would require post-clone work but maybe a script)? > > git config remote.origin.pushurl ssh://<GERRIT_HOST>:29418/<PROJECT_PATH>.git > git config remote.origin.push refs/heads/*:refs/for/* > git push origin Ah ok, that would be better. Can I also push -f to users/* branches in a similar fashion? > Okay, maybe a clone script? I assume you have one already? not yet, I have only put openbsc and libosmocore on gerrit so far. > $ cat git gerrit-clone git://git.osmocom.org/libosmocore interesting, you can cat git URLs these days! ;) > #!/bin/sh > set -e > git clone $1 > cd `basename $1 git` > git config remote.origin.pushurl ... > git config remote.origin.push.. > scp .. .git/hooks > echo "tada" heh "tada" If we can have the users branch push enabled I'll complete the script and put it in the Gerrit wiki page. > yes, a change in muscle memory. When cloning you have to remember your gerrit username and that the repository was using gerrit. But from daily workflow it doesn't look that bad? I have to type "users/" a lot more :P (ok see below) But it would help to get rid of the duplicate remotes = duplicate branches. For me personally, the gerrit username matches my shell username, so no problem there. > Either way you have to make the mental decision if you push a wip branch or if you want to have review. that's not a problem. But one more thing here: pushing a branch to gerrit is slightly easier than format-patch, but what is really cumbersome now is to push just one commit from a private branch (cherry pick to for/master). With git format-patch I could just supply a range 123abc..ef0987, with gerrit I first need to create a fresh branch with just that commit. Especially if I have a couple of unrelated commits sitting in line on a private branch and I want to submit them separately, I have to create a new branch for each single commit to push for/master. Do I? > > - access rules = obstructed access to branches = add 'users/' to all private branches > > = we have scores of old branches now in a namespace we can't use anymore > > Then let's create one group like you did and allow everything for that group again? So one manual intervention and one can push to everything again. No issue with that. agreed. I have allowed global push permission for the "known users" group. Since we already have a sysmocom group, sysmocom/* push permission is still exclusive for the sysmocom group. I also made push to master exclusive to admins as a gimmick. I hope it doesn't interfere with the normal merges, we can just drop the rule again if it does. > Under Projects -> "openbsc.git" change it to "Rebase if necessary" and give it a small try (push a slightly outdated commit so we can see I did that and submitted two test branches with two commits each: One should not have any conflicts during a rebase: https://gerrit.osmocom.org/130 https://gerrit.osmocom.org/131 The other should have a conflict on the first commit: https://gerrit.osmocom.org/132 https://gerrit.osmocom.org/133 For some reason both the second commits on the branches also show a conflict. changed back to 'cherry pick' for now. ~Neels
On Tue, May 31, 2016 at 12:00:26PM +0200, Neels Hofmeyr wrote: > I did that and submitted two test branches with two commits each: > > One should not have any conflicts during a rebase: > https://gerrit.osmocom.org/130 > https://gerrit.osmocom.org/131 > > The other should have a conflict on the first commit: > https://gerrit.osmocom.org/132 > https://gerrit.osmocom.org/133 > > For some reason both the second commits on the branches also show a > conflict. > > changed back to 'cherry pick' for now. Did another branch commit without conflict in cherry pick mode, and the commits show as "Related" but not "Submitted together"... That's not news I guess. ~Neels
On Tue, May 31, 2016 at 12:00:26PM +0200, Neels Hofmeyr wrote: > One should not have any conflicts during a rebase: > https://gerrit.osmocom.org/130 > https://gerrit.osmocom.org/131 There's a conflict on 131 that shouldn't happen. Does anyone know how to see gerrit's problem with this commit? ~Neels
diff --git a/include/osmocom/gsm/protocol/gsm_04_08.h b/include/osmocom/gsm/protocol/gsm_04_08.h index 4800b48..0c2fcf2 100644 --- a/include/osmocom/gsm/protocol/gsm_04_08.h +++ b/include/osmocom/gsm/protocol/gsm_04_08.h @@ -4,6 +4,8 @@ #include <stdbool.h> #include <osmocom/core/utils.h> +#include <osmocom/core/endian.h> + /* GSM TS 04.08 definitions */ struct gsm_lchan; @@ -42,6 +44,7 @@ struct gsm48_classmark2 { } __attribute__ ((packed)); /* Chapter 10.5.2.1b.3 */ +#if OSMO_IS_LITTLE_ENDIAN == 1 struct gsm48_range_1024 { uint8_t w1_hi:2, f0:1, @@ -75,8 +78,44 @@ struct gsm48_range_1024 { uint8_t w16:6, w15_lo:2; } __attribute__ ((packed)); +#else +struct gsm48_range_1024 { + uint8_t form_id:5, + f0:1, + w1_hi:2; + uint8_t w1_lo; + uint8_t w2_hi; + uint8_t w2_lo:1, + w3_hi:7; + uint8_t w3_lo:2, + w4_hi:6; + uint8_t w4_lo:2, + w5_hi:6; + uint8_t w5_lo:2, + w6_hi:6; + uint8_t w6_lo:2, + w7_hi:6; + uint8_t w7_lo:2, + w8_hi:6; + uint8_t w8_lo:1, + w9:7; + uint8_t w10:7, + w11_hi:1; + uint8_t w11_lo:6, + w12_hi:2; + uint8_t w12_lo:5, + w13_hi:3; + uint8_t w13_lo:4, + w14_hi:4; + uint8_t w14_lo:3, + w15_hi:5; + uint8_t w15_lo:2, + w16:6; +} __attribute__ ((packed)); +#endif /* Chapter 10.5.2.1b.4 */ +#if OSMO_IS_LITTLE_ENDIAN == 1 struct gsm48_range_512 { uint8_t orig_arfcn_hi:1, form_id:7; @@ -110,8 +149,44 @@ struct gsm48_range_512 { uint8_t w17:5, w16_lo:3; } __attribute__ ((packed)); +#else +struct gsm48_range_512 { + uint8_t form_id:7, + orig_arfcn_hi:1; + uint8_t orig_arfcn_mid; + uint8_t orig_arfcn_lo:1, + w1_hi:7; + uint8_t w1_lo:2, + w2_hi:6; + uint8_t w2_lo:2, + w3_hi:6; + uint8_t w3_lo:2, + w4_hi:6; + uint8_t w4_lo:1, + w5:7; + uint8_t w6:7, + w7_hi:1; + uint8_t w7_lo:6, + w8_hi:2; + uint8_t w8_lo:4, + w9_hi:4; + uint8_t w9_lo:2, + w10:6; + uint8_t w11:6, + w12_hi:2; + uint8_t w12_lo:4, + w13_hi:4; + uint8_t w13_lo:2, + w14:6; + uint8_t w15:6, + w16_hi:2; + uint8_t w16_lo:3, + w17:5; +} __attribute__ ((packed)); +#endif /* Chapter 10.5.2.1b.5 */ +#if OSMO_IS_LITTLE_ENDIAN == 1 struct gsm48_range_256 { uint8_t orig_arfcn_hi:1, form_id:7; @@ -151,8 +226,50 @@ struct gsm48_range_256 { w21:4, w20_lo:3; } __attribute__ ((packed)); +#else +struct gsm48_range_256 { + uint8_t form_id:7, + orig_arfcn_hi:1; + uint8_t orig_arfcn_mid; + uint8_t orig_arfcn_lo:1, + w1_hi:7; + uint8_t w1_lo:1, + w2:7; + uint8_t w3:7, + w4_hi:1; + uint8_t w4_lo:5, + w5_hi:3; + uint8_t w5_lo:3, + w6_hi:5; + uint8_t w6_lo:1, + w7:6, + w8_hi:1; + uint8_t w8_lo:4, + w9_hi:4; + uint8_t w9_lo:1, + w10:5, + w11_hi:2; + uint8_t w11_lo:3, + w12:5; + uint8_t w13:5, + w14_hi:3; + uint8_t w14_lo:2, + w15:5, + w16_hi:1; + uint8_t w16_lo:3, + w17:4, + w18_hi:1; + uint8_t w18_lo:3, + w19:4, + w20_hi:1; + uint8_t w20_lo:3, + w21:4, + spare:1; +} __attribute__ ((packed)); +#endif /* Chapter 10.5.2.1b.6 */ +#if OSMO_IS_LITTLE_ENDIAN == 1 struct gsm48_range_128 { uint8_t orig_arfcn_hi:1, form_id:7; @@ -194,6 +311,49 @@ struct gsm48_range_128 { w27:3, w26_lo:1; } __attribute__ ((packed)); +#else +struct gsm48_range_128 { + uint8_t form_id:7, + orig_arfcn_hi:1; + uint8_t orig_arfcn_mid; + uint8_t orig_arfcn_lo:1, + w1:7; + uint8_t w2:6, + w3_hi:2; + uint8_t w3_lo:4, + w4_hi:4; + uint8_t w4_lo:1, + w5:5, + w6_hi:2; + uint8_t w6_lo:3, + w7:5; + uint8_t w8:4, + w9:4; + uint8_t w10:4, + w11:4; + uint8_t w12:4, + w13:4; + uint8_t w14:4, + w15:4; + uint8_t w16:3, + w17:3, + w18_hi:2; + uint8_t w18_lo:1, + w19:3, + w20:3, + w21_hi:1; + uint8_t w21_lo:2, + w22:3, + w23:3; + uint8_t w24:3, + w25:3, + w26_hi:2; + uint8_t w26_lo:1, + w27:3, + w28:3, + spare:1; +} __attribute__ ((packed)); +#endif /* Chapter 10.5.2.1b.7 */ struct gsm48_var_bit {
Hi, One test case fails for openbsc on big-endian architectures. This was traced back to struct erros in libosmocore. Please see patch below: commit fb3d353ab238a2d14cb8e9704995f14a2acd6c1b Author: Ruben Undheim <ruben.undheim@gmail.com> Date: Mon Dec 7 19:34:28 2015 +0100 Patched structs for big-endian architectures I tried 30 seconds to figure out how to use Gerrit, but I couldn't figure out how to login, so I rather just post here. Best regards, Ruben