OpenBSC now in Debian!
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
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!
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@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
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:
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
-- Max Suraev <msuraev@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
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
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
On 19 Mar 2016, at 07:46, Ruben Undheim <ruben.undheim@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
Thanks
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.
I'll try to figure out this one. Ruben
On 20 Mar 2016, at 12:00, Ruben Undheim <ruben.undheim@gmail.com> wrote:
Thanks
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?
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
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
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
On 21 Mar 2016, at 12:05, Neels Hofmeyr <nhofmeyr@sysmocom.de> wrote:
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?
Use sqlite3 directly (and preferable change the interface at the same time)
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
On Mon, Mar 21, 2016 at 04:01:31PM +0100, Holger Freyther wrote:
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.
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
Hi,
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/
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/tree... Half of the patch has already been applied to libosmocore some time ago. Cheers Ruben
On 11 May 2016, at 23:01, Ruben Undheim <ruben.undheim@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/tree...
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
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?
Good idea, I'll ask if they want to backport it. It was fixed in sid at least.
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/tree...
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
participants (4)
-
Holger Freyther -
Max -
Neels Hofmeyr -
Ruben Undheim