17 Mar
2016
17 Mar
'16
6:53 p.m.
Hi,
It might interest you that OpenBSC has entered Debian unstable today!
https://tracker.debian.org/news/755641
Please test the package and file bugs as you find them. I haven't added init/service
files
yet to the package, since it needs some careful thought around what default is the best
for the general users.
Best regards,
Ruben
18 Mar
18 Mar
11:34 a.m.
On Thu, Mar 17, 2016 at 06:53:37PM +0100, Ruben Undheim wrote:
Hi,
It might interest you that OpenBSC has entered Debian unstable today!
https://tracker.debian.org/news/755641
Nice! Thanks, Ruben!!
Please test the package and file bugs as you find
them. I haven't added init/service files
yet to the package, since it needs some careful thought around what default is the best
for the general users.
I agree. Also, the binaries by default typically look in ./ for config
files, not using /etc/osmocom/ or something. Makes sense to me to not have
service files.
~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
11:43 a.m.
I disagree - having .service files is a perfect way to make sure that
openbsc by default use .config and hlr files in locations supplied by
the package. Also it helps to improve security of the setup by using
options like /"PrivateTmp", "/InaccessibleDirectories/",
"/ReadOnlyDirectories/" etc.
/On a related note - if there were some changes made to /debian
directories while packaging it probably make sense to merge them back to
upstream.
Thanks for great work.
//////
On 03/18/2016 11:34 AM, Neels Hofmeyr wrote:
On Thu, Mar 17, 2016 at 06:53:37PM +0100, Ruben
Undheim wrote:
--
Max Suraev <msuraev(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
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
Hi,
It might interest you that OpenBSC has entered Debian unstable today!
https://tracker.debian.org/news/755641
Nice! Thanks, Ruben!!
Please test the package and file bugs as you find
them. I haven't added init/service files
yet to the package, since it needs some careful thought around what default is the best
for the general users.
I agree. Also, the binaries by default typically look in ./
for config
files, not using /etc/osmocom/ or something. Makes sense to me to not have
service files.
~Neels
19 Mar
19 Mar
7:46 a.m.
Some tests are unfortunately failing for several architectures (even for i386).
Please see here:
https://buildd.debian.org/status/package.php?p=openbsc
For i386, the "db" test is failing.
For powerpc, the "gsm0408" test is failing.
For mips, both the "db" test and the "gsm0408" test are failing.
I would appreciate any hints!
Cheers,
Ruben
On Thu, Mar 17, 2016 at 06:53:37PM +0100, Ruben Undheim wrote:
Hi,
It might interest you that OpenBSC has entered Debian unstable today!
https://tracker.debian.org/news/755641
Please test the package and file bugs as you find them. I haven't added init/service
files
yet to the package, since it needs some careful thought around what default is the best
for the general users.
Best regards,
Ruben
8 a.m.
This is the error for i386 when it fails the "db" test:
3. testsuite.at:16: testing db ...
./testsuite.at:21: $abs_top_builddir/tests/db/db_test
--- experr 2016-03-19 06:58:27.308000000 +0000
+++ /tmp/buildd/openbsc-0.15.0/openbsc/tests/testsuite.dir/at-groups/3/stderr 2016-03-19
06:58:27.332000000 +0000
@@ -1,2 +1,2 @@
Going to migrate from revision 3
-
\ No newline at end of file
+/tmp/buildd/openbsc-0.15.0/openbsc/tests/testsuite.dir/at-groups/3/test-source: line 27:
3806 Segmentation fault $abs_top_builddir/tests/db/db_test
--- expout 2016-03-19 06:58:27.308000000 +0000
+++ /tmp/buildd/openbsc-0.15.0/openbsc/tests/testsuite.dir/at-groups/3/stdout 2016-03-19
06:58:27.308000000 +0000
@@ -1,4 +0,0 @@
-Testing subscriber database code.
-DB: Database initialized.
-DB: Database prepared.
-Done
./testsuite.at:21: exit code was 139, expected 0
3. testsuite.at:16: 3. db (testsuite.at:16): FAILED (testsuite.at:21)
Ruben
On Sat, Mar 19, 2016 at 07:46:07AM +0100, Ruben Undheim wrote:
Some tests are unfortunately failing for several
architectures (even for i386).
Please see here:
https://buildd.debian.org/status/package.php?p=openbsc
For i386, the "db" test is failing.
For powerpc, the "gsm0408" test is failing.
For mips, both the "db" test and the "gsm0408" test are failing.
I would appreciate any hints!
Cheers,
Ruben
On Thu, Mar 17, 2016 at 06:53:37PM +0100, Ruben Undheim wrote:
> Hi,
>
> It might interest you that OpenBSC has entered Debian unstable today!
>
> https://tracker.debian.org/news/755641
>
> Please test the package and file bugs as you find them. I haven't added
init/service files
> yet to the package, since it needs some careful thought around what default is the
best
> for the general users.
>
> Best regards,
> Ruben
>
9:23 a.m.
On 19 Mar 2016, at 07:46, Ruben Undheim
<ruben.undheim(a)gmail.com> wrote:
Some tests are unfortunately failing for several architectures (even for i386).
Please see here:
https://buildd.debian.org/status/package.php?p=openbsc
For i386, the "db" test is failing.
yes, libdbi and libdbd-sqlite3 has memory issues. They have been reported two years and
remain unfixed. It is best to migrate away from this library.
See https://sourceforge.net/p/libdbi/mailman/message/32607036/
For powerpc, the "gsm0408" test is failing.
properly byte ordering. Is GCC6 already in debian unstable? It might be easier to use
gcc's new pragma that mirroring the definition.
For mips, both the "db" test and the
"gsm0408" test are failing.
probably combination of the BE and memory corruption
20 Mar
20 Mar
noon
Thanks
I'll try to figure out this one.
Ruben
yes, libdbi and libdbd-sqlite3 has memory issues. They
have been reported two years and remain unfixed. It is best to migrate away from this
library.
See https://sourceforge.net/p/libdbi/mailman/message/32607036/
It seems like the memory issue is there only for 32 bits architectures.
Does this mean that OpenBSC does not support 32 bits architectures? or is the test case
just a bit conservative?
What do you propose we do? Should we ignore that test when building the Debian package,
or
should we not provide packages for 32 bits architectures?
For powerpc,
the "gsm0408" test is failing.
properly byte ordering. Is GCC6 already in debian unstable? It might be easier to use
gcc's new pragma that mirroring the definition.
12:04 p.m.
On 20 Mar 2016, at 12:00, Ruben Undheim
<ruben.undheim(a)gmail.com> wrote:
Thanks
it has nothing to do with 32bit bits.. we are just lucky on memory allocations with 64bit
that the out of bounds memory access does not cause a crash. The compiler or glibc might
change alignment and then there will be crashes on AMD64 as well.
a.) Somebody fixes libdbi/libdbd-sqlite3
b.) Somebody changes OpenBSC to not use libdbi (preferred)
c.) One downgrades to libdbi 0.8.x
d.) One doesn't build 32bit package
kind regards
holger
yes, libdbi and libdbd-sqlite3 has memory issues.
They have been reported two years and remain unfixed. It is best to migrate away from this
library.
See https://sourceforge.net/p/libdbi/mailman/message/32607036/
It seems like the memory issue is there only for 32 bits architectures.
Does this mean that OpenBSC does not support 32 bits architectures? or is the test case
just a bit conservative?
What do you propose we do? Should we ignore that test when building the Debian package,
or
should we not provide packages for 32 bits architectures?
9:45 p.m.
it has nothing to do with 32bit bits.. we are just
lucky on memory allocations with 64bit that the out of bounds memory access does not cause
a crash. The compiler or glibc might change alignment and then there will be crashes on
AMD64 as well.
a.) Somebody fixes libdbi/libdbd-sqlite3
b.) Somebody changes OpenBSC to not use libdbi (preferred)
c.) One downgrades to libdbi 0.8.x
d.) One doesn't build 32bit package
I tried to rebuild libdbi-drivers (it was last built for Debian in 2014), and
then the test suite for OpenBSC pass both on i386 and amd64.. That may be a
temporary workaround, although probably not very safe..
Regards,
Ruben
21 Mar
21 Mar
12:05 p.m.
On Sun, Mar 20, 2016 at 12:04:34PM +0100, Holger Freyther wrote:
b.) Somebody changes OpenBSC to not use libdbi
(preferred)
The alternative being to use libsqlite directly?
Or would you prefer a different db-wrapper lib?
I also get the "deprecated" warnings about some db function calls in my
compiles, so I there's a tiny incentive to fix that, too.
~Neels
4:01 p.m.
On 21 Mar 2016, at 12:05, Neels Hofmeyr
<nhofmeyr(a)sysmocom.de> wrote:
On Sun, Mar 20, 2016 at 12:04:34PM +0100, Holger Freyther wrote:
Use sqlite3 directly (and preferable change the interface at the same time)
b.) Somebody changes OpenBSC to not use libdbi
(preferred)
The alternative being to use libsqlite directly?
Or would you prefer a different db-wrapper lib? I also get the "deprecated" warnings about
some db function calls in my
compiles, so I there's a tiny incentive to fix that, too.
I disagree, you will force everyone to use a broken version of libdbi.
holger
5:38 p.m.
On Mon, Mar 21, 2016 at 04:01:31PM +0100, Holger Freyther wrote:
I meant, if we move away from libdbi, I will in consequence not see those
deprecation warnings anymore, which would be nice. That's all.
~Neels
I also get the
"deprecated" warnings about some db function calls in my
compiles, so I there's a tiny incentive to fix that, too.
I disagree, you will force everyone to use a broken version of libdbi.
11 May
11 May
11:01 p.m.
Hi,
a.)
Somebody fixes libdbi/libdbd-sqlite3
b.) Somebody changes OpenBSC to not use libdbi (preferred)
c.) One downgrades to libdbi 0.8.x
d.) One doesn't build 32bit package
I believe I've identified the issue in libdbd-sqlite3. See
https://bugs.debian.org/824067 .
It also seems like the issue has been fixed upstream in libdbi already in the
Spring of 2014, but no new releases has been made since then.
Could this be all, or are you aware of other memory issues or problems with libdbd?
Additionally, I've found another problem for big-endian architectures
(https://bugs.debian.org/818566)
You'll see my patch here:
https://anonscm.debian.org/cgit/debian-science/packages/libosmocore.git/tre…
Half of the patch has already been applied to libosmocore some time ago.
Cheers
Ruben
yes, libdbi and libdbd-sqlite3 has memory issues. They
have been reported two years and remain unfixed. It is best to migrate away from this
library.
See https://sourceforge.net/p/libdbi/mailman/message/32607036/
12 May
12 May
6:50 p.m.
On 11 May 2016, at 23:01, Ruben Undheim
<ruben.undheim(a)gmail.com> wrote:
Hi!
It also seems like the issue has been fixed upstream
in libdbi already in the
Spring of 2014, but no new releases has been made since then.
Could this be all, or are you aware of other memory issues or problems with libdbd?
ah cool. I didn't know that it was fixed by Jan. Can you get this into debian8.0 as a
bugfix?
Additionally, I've found another problem for
big-endian architectures (https://bugs.debian.org/818566)
You'll see my patch here:
https://anonscm.debian.org/cgit/debian-science/packages/libosmocore.git/tre…
Half of the patch has already been applied to libosmocore some time ago.
Do you want to try to use gerrit to push the missing hunks? But GCC6
26 May
26 May
9:24 p.m.
It also seems
like the issue has been fixed upstream in libdbi already in the
Spring of 2014, but no new releases has been made since then.
Could this be all, or are you aware of other memory issues or problems with libdbd?
ah cool. I didn't know that it was fixed by Jan. Can you get this into debian8.0 as a
bugfix? > Additionally, I've found another problem for
big-endian architectures (https://bugs.debian.org/818566)
> You'll see my patch here:
>
https://anonscm.debian.org/cgit/debian-science/packages/libosmocore.git/tre…
>
> Half of the patch has already been applied to libosmocore some time ago.
I just sent you the patch (only the relevant part)
Do you want to try to use gerrit to push the missing
hunks? But GCC6
Didn't figure out how. :(
Still using GCC5 here unfortunately. ;)
Ruben
3313
days inactive
3383
days old
15 comments
4 participants
participants (4)
-
Holger Freyther -
Max -
Neels Hofmeyr -
Ruben Undheim