Hello,

And, what is the different of "nano3G" and the "sysmocell 5000" !?


Chears,



De : "openbsc-request@lists.osmocom.org" <openbsc-request@lists.osmocom.org>
À : openbsc@lists.osmocom.org
Envoyé le : Jeudi 4 mai 2017 18h32
Objet : OpenBSC Digest, Vol 31, Issue 6

Send OpenBSC mailing list submissions to

To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to

You can reach the person managing the list at

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OpenBSC digest..."


Today's Topics:

  1. Re: osmo-bts-trx error / osmo-trx illegal instruction (core
      dumped) (Max)
  3. Re: 3G openBSC (Harald Welte)
  4. RE: 3G openBSC (dga-mi.imi.fct@intradef.gouv.fr)
  5. Re: dependency artifacts for faster
      builds/gerrit-verifications (Neels Hofmeyr)
  6. gerrit: thanks for login link (Neels Hofmeyr)
  7. Re: gerrit: thanks for login link (Holger Freyther)
  8. Re: dependency artifacts for faster
      builds/gerrit-verifications (Neels Hofmeyr)


----------------------------------------------------------------------

Message: 1
Date: Wed, 3 May 2017 13:48:57 +0200
Subject: Re: osmo-bts-trx error / osmo-trx illegal instruction (core
    dumped)
Content-Type: text/plain; charset=utf-8

You might want to have a look at 78b5627fa1c911713a776e4aa1cb2d8f3a04bd8f in osmo-trx
which seems to be related.

On 03.05.2017 13:45, Vadim Yanitskiy wrote:
> Hi Alexander and all,
>
> > I don't think those patches will change this if your seeing a failure with
> > a --without-sse build.
>
> I hope, it should, because even with --without-sse we still had -march=native.

--
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte






------------------------------

Message: 2
Date: Thu, 4 May 2017 09:40:14 +0000
Subject: 3G openBSC
Message-ID:
   
Content-Type: text/plain; charset="us-ascii"

Hello,

I would like to know whether the 3G openBSC platform is enough stable to start using it  for data and voice  services.
Which 3G femtocell do you recommand ?
Is it possible  to  use  Sysmocom SIM for 3G UE registration?

Best regards,

Remi



[ENVOYE PAR INTERNET]


-------------- next part --------------
An HTML attachment was scrubbed...

------------------------------

Message: 3
Date: Thu, 4 May 2017 14:40:43 +0200
From: Harald Welte <laforge@gnumonks.org>
Subject: Re: 3G openBSC
Content-Type: text/plain; charset=us-ascii

Hi Remi,

On Thu, May 04, 2017 at 09:40:14AM +0000, dga-mi.imi.fct@intradef.gouv.fr wrote:
> I would like to know whether the 3G openBSC platform is enough stable
> to start using it  for data and voice  services.

I think it is the right time to start with trials and testing, but not
for production use.

> Which 3G femtocell do you recommand ?

We have currently tested it with nano3G and with a small cell hardware
we call sysmoCell 5000.  you can contact sales@sysmocom.de for related
information.

Of course anyone is free to integrate and/or tests osmo-iuh with other
femtocell or small cell products, but so far I have not heard of anyone
doing that.

> Is it possible  to  use  Sysmocom SIM for 3G UE registration?

sure!

--
- Harald Welte <laforge@gnumonks.org>          http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


------------------------------

Message: 4
Date: Thu, 4 May 2017 15:28:40 +0000
Subject: RE: 3G openBSC
Message-ID:
   
Content-Type: text/plain; charset="iso-8859-1"

Harald,

Thank you very much for your  response. I will contact  sysmocom sales to get further information on 3G nano cell.

Best regards,

Remi

[ENVOYE PAR INTERNET]

-----Message d'origine-----
De?: Harald Welte [mailto:laforge@gnumonks.org]
Envoy??: jeudi 4 mai 2017 14:41
??: dga-mi.imi.fct
Objet?: Re: 3G openBSC

Hi Remi,

On Thu, May 04, 2017 at 09:40:14AM +0000, dga-mi.imi.fct@intradef.gouv.fr wrote:
> I would like to know whether the 3G openBSC platform is enough stable
> to start using it  for data and voice  services.

I think it is the right time to start with trials and testing, but not for production use.

> Which 3G femtocell do you recommand ?

We have currently tested it with nano3G and with a small cell hardware we call sysmoCell 5000.  you can contact sales@sysmocom.de for related information.

Of course anyone is free to integrate and/or tests osmo-iuh with other femtocell or small cell products, but so far I have not heard of anyone doing that.

> Is it possible  to  use  Sysmocom SIM for 3G UE registration?

sure!

--
- Harald Welte <laforge@gnumonks.org>          http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


------------------------------

Message: 5
Date: Thu, 4 May 2017 17:52:28 +0200
From: Neels Hofmeyr <nhofmeyr@sysmocom.de>
To: Andr? Boddenberg <dr.blobb@gmail.com>
Subject: Re: dependency artifacts for faster
    builds/gerrit-verifications
Content-Type: text/plain; charset="iso-8859-1"

On Tue, May 02, 2017 at 07:59:35PM +0200, Andr? Boddenberg wrote:
> Hi all,
>
> here's a (late) recap on the "dependency-artifacts" topic discussed
> with Holger and Neels at OsmoDevCon.
>
>
> The "mv $artifact"-issue, which occurs when run within a docker
> container has been resolved. Now artifacts are created inside a
> temporary directory within the ARTIFACT_STORE and not inside the
> Docker container, so the "mv" command won't take as long as a "cp"
> anymore.
>
> Moreover, artifacts are now stored per jenkins job and not per git
> project. A JOB_NAME-directory inside the ARTIFACT_STORE is created for
> each jenkins job to distinguish between them. This means artifacts
> aren't shared across jobs which build the same git project. This might
> change in the future, but is safe for now as some jenkins jobs might
> need dependencies built with different configurations.
>
> Note: the necessary disk space for openBSC artifacts of one
> matrix-configuration job is ~400 MB (~50 MB per axis).
>
> Furthermore, each jenkins job takes care about garbage collection on
> its own by simply deleting the entire content of its
> JOB_NAME-directory inside the ARTIFACT_STORE.

Which is, for the record, the reason to have it per-job: we always know
which artifacts need to be / we are allowed to clean up. With multiple
jobs accessing the same artifact store, GC is not trivial.

> The two scripts osmo-{build,artifacts}.sh have been tested [1][2],
> shellcheck'ed and pushed to gerrit [3].

nice!

> The following actions are pending to enable the use of artifacts
> inside contrib/jenkins.sh within each git repository, but can not be
> applied by me:
>
>  - setting ARTIFACT_STORE environment variable for each jenkins slave
>  - copying osmo-artifact.sh and osmo-build.sh to ~/bin of each slave user

Add to osmo-ci. Could you submit a patch for it?

>  - adding a new docker volume for the ARTIFACT_STORE to the image

We're talking about the docker invocation in the OpenBSC and
OpenBSC-gerrit jobs.

> But, let's review first. =)

I notice there are hashes of various dependent builds in the tar names:

libosmocore.master.33e0306_libosmo-abis.master.bf7976c_libosmo-netif.master.56add1e_libosmo-sccp.master.b354652_libsmpp34.master.cc0bcd6_openggsn.master.19e19e3.tar.gz

I remember that we said to instead have each on its own -- but not saying
we have to, just curious.

So the semantics are: figure out all of the hashes of all dependencies, as
soon as one of them mismatches rebuild all and make a new single tar with
all included. Right?

Also curious about how a matrix build would do it: would every matrix
rebuild the same dependency? (We said that that's fine IIRC)

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature

------------------------------

Message: 6
Date: Thu, 4 May 2017 22:35:12 +0200
From: Neels Hofmeyr <nhofmeyr@sysmocom.de>
Subject: gerrit: thanks for login link
Content-Type: text/plain; charset="us-ascii"

BTW, the "Sign in with Osmocom" link on the gerrit login page is really nice!
It even works as a bookmark.

Many Thanks!! (@holger?)

~N

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature

------------------------------

Message: 7
Date: Thu, 4 May 2017 22:49:51 +0200
From: Holger Freyther <holger@freyther.de>
To: Neels Hofmeyr <nhofmeyr@sysmocom.de>
Subject: Re: gerrit: thanks for login link
Content-Type: text/plain; charset=us-ascii


> On 4. May 2017, at 22:35, Neels Hofmeyr <nhofmeyr@sysmocom.de> wrote:
>
> Many Thanks!! (@holger?)

maybe I have a future in frontend development after all ;)



------------------------------

Message: 8
Date: Fri, 5 May 2017 00:31:09 +0200
From: Neels Hofmeyr <nhofmeyr@sysmocom.de>
To: Andr? Boddenberg <dr.blobb@gmail.com>
Subject: Re: dependency artifacts for faster
    builds/gerrit-verifications
Content-Type: text/plain; charset="iso-8859-1"

On Thu, May 04, 2017 at 05:52:28PM +0200, Neels Hofmeyr wrote:
> On Tue, May 02, 2017 at 07:59:35PM +0200, Andr? Boddenberg wrote:
> > The following actions are pending to enable the use of artifacts
> > inside contrib/jenkins.sh within each git repository, but can not be
> > applied by me:
> >
> >  - setting ARTIFACT_STORE environment variable for each jenkins slave
> >  - copying osmo-artifact.sh and osmo-build.sh to ~/bin of each slave user
>
> Add to osmo-ci. Could you submit a patch for it?


~N

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature

------------------------------

Subject: Digest Footer

_______________________________________________
OpenBSC mailing list


------------------------------

End of OpenBSC Digest, Vol 31, Issue 6
**************************************