26 May
2016
26 May
'16
9:16 p.m.
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(a)gmail.com>
Date: Mon Dec 7 19:34:28 2015 +0100
Patched structs for big-endian architectures
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 {
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
27 May
27 May
1:47 p.m.
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
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
9:32 p.m.
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
9:36 p.m.
On 27 May 2016, at 21:32, Ruben Undheim
<ruben.undheim(a)gmail.com> wrote:
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
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.
9:39 p.m.
On 27 May 2016, at 21:36, Holger Freyther
<holger(a)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
9:46 p.m.
On 27 May 2016, at 21:39, Holger Freyther
<holger(a)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
10:13 p.m.
On 27 May 2016, at 22:11, Ruben Undheim
<ruben.undheim(a)gmail.com> wrote:
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
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.
30 May
30 May
12:39 p.m.
On Fri, May 27, 2016 at 09:32:41PM +0200, Ruben Undheim 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 :(
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
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!
1:56 p.m.
New subject: Gerrit and branches (Was: Re: libosmocore: patch for big-endian architectures)
On 30 May 2016, at 12:39, Neels Hofmeyr
<nhofmeyr(a)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
6:56 p.m.
New subject: Gerrit and branches (Was: Re: libosmocore: patch for big-endian architectures)
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
9 p.m.
New subject: Gerrit and branches (Was: Re: libosmocore: patch for big-endian architectures)
On 30 May 2016, at 18:56, Neels Hofmeyr
<nhofmeyr(a)sysmocom.de> wrote:
On Mon, May 30, 2016 at 01:56:08PM +0200, Holger Freyther wrote:
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)?
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.
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. 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.
31 May
31 May
noon
New subject: Gerrit and branches
On Mon, May 30, 2016 at 09:00:05PM +0200, Holger Freyther wrote:
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.
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.
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
12:14 p.m.
New subject: Gerrit and branches
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
12:18 p.m.
New subject: Gerrit and branches
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
2908
days inactive
2913
days old
14 comments
3 participants
participants (3)
-
Holger Freyther -
Neels Hofmeyr -
Ruben Undheim