24 May
2016
24 May
'16
11:41 p.m.
Dear Ruben,
I wonder if you could give us/me a hand in closing the gap between the official packages.
In general we are willing to drop backwards compatibility with our install base to reach
Debian standards. Ideally a user can easily upgrade from a Debian version to our nightly
builds and you and other debian developers can hopefully easily take our source packages
and move them forward as well.
Do you have experience with upstream making their own debian packages and a proper package
being included in debian as well?
Shall I create tickets in our osmocom.org redmine to coordinate synchronization? Are you
aware of different sysv init script names, paths for config/hlr files, package names?
From a very brief look:
+ We never handled the .copyright files correctly you do
+ debian/control you have nice short and long terms descriptions we should have
+ You have patches for typos and other parts (i have pushed the ggsn one and will go
through the patches later)
+ Your have manpages and we never bothered with it. I think it is a really good debian
rule (and good Unix legacy to force a manpage for binaries in /usr!)
- At least for OpenBSC you do not seem to package the -dbg symbols. As a developer I am
always annoyed (e.g. with sofia sip) when I can't install the debug symbols.
- You seem to not include sysvinit (and systemd) service files?
Do you have a proposal on how we could move forward? How do you manage/maintain the extra
debian/ directory?
kind regards
holger
26 May
26 May
7:30 a.m.
Hi Holger!
Just a short answer from me this morning.
I wonder if you could give us/me a hand in closing the
gap between the official packages.
Good idea!
In general we are willing to drop backwards
compatibility with our install base to reach Debian standards.
I don't have a total overview of the backwards incompatible discrepancies. I probably
should have, but hopefully there aren't too many.
Ideally a user can easily upgrade from a Debian
version to our nightly builds and you and other debian developers can hopefully easily
take our source packages and move them forward as well.
Sounds convenient for the users.
Do you have experience with upstream making their own
debian packages and a proper package being included in debian as well?
No, I don't have any experience. But technically, it shouldn't be too hard. The
debian dir in the upstream tarball will always be overwritten when building the package,
so whatever you do there, will be invisible in the official package unless we manually
merge it in.
Shall I create tickets in our osmocom.org redmine to
coordinate synchronization? Are you aware of different sysv init script names, paths for
config/hlr files, package names?
Sounds like a plan!
From a very brief look:
+ We never handled the .copyright files correctly you do
+ debian/control you have nice short and long terms descriptions we should have
+ You have patches for typos and other parts (i have pushed the ggsn one and will go
through the patches later)
+ Your have manpages and we never bothered with it. I think it is a really good debian
rule (and good Unix legacy to force a manpage for binaries in /usr!)
All the packaging is done with the same license as the upstream software, so you're
free (and encouraged!) to pull in all the things you find useful into your source tree or
debian dir.
- At least for OpenBSC you do not seem to package the
-dbg symbols. As a developer I am always annoyed (e.g. with sofia sip) when I can't
install the debug symbols.
-dbg packages are now handled automatically by Debian. Any package with binaries, will
automatically get "-dbgsym" packages. Just google it. This is also the case for
Ubuntu AFAIK. This will however not be of any help for older Ubuntu and Debian releases
(if you desire to support them also with -dbg symbols)
- You seem to not include sysvinit (and systemd)
service files?
I'm willing to add this when we're absolutely 100% sure that the default is sane
for every user. It was simply excluded from the first versions of the official packages
because I'm not familiar enough with the configuration.
Do you have a proposal on how we could move forward?
How do you manage/maintain the extra debian/ directory?
The extra debian dir is no problem. As said above, it will be overwritten automatically by
the build tools when building the package. To move forward: we just pull interesting stuff
from each other's debian dir. However, it may make sense to pull some things out of
the debian dir and into the main source tree - for instance the man pages.
Best regards
Ruben
6:04 p.m.
Hi again,
Btw. I just noticed that you have actually started the debian
packaging on the master branch of osmo-bts - not yet
released. Then you're probably not aware of the ongoing
effort since Februrary where I've been packaging it:
See this branch:
https://anonscm.debian.org/cgit/debian-science/packages/osmo-bts.git/log/
The only thing missing is writing the man pages, the
short/long description in d/control and d/copyright, and then
it can be uploaded.
Note that I prepared a openbsc-dev package (already in the
archive) which provides the gsm_data_shared.h related files,
and osmo-bts build-depends on this. I don't know how you
solved this.
Cheers,
Ruben
7:58 p.m.
On 26 May 2016, at 18:04, Ruben Undheim
<ruben.undheim(a)gmail.com> wrote:
Hi again,
Btw. I just noticed that you have actually started the debian
packaging on the master branch of osmo-bts - not yet
released. Then you're probably not aware of the ongoing
effort since Februrary where I've been packaging it:
See this branch:
https://anonscm.debian.org/cgit/debian-science/packages/osmo-bts.git/log/
oh, I was not aware of it. I mostly created it ad-hoc. I will try to copy as much as
possible.
The only thing missing is writing the man pages, the
short/long description in d/control and d/copyright, and then
it can be uploaded.
Note that I prepared a openbsc-dev package (already in the
archive) which provides the gsm_data_shared.h related files,
and osmo-bts build-depends on this. I don't know how you
solved this.
ah nice! I cheat and copy the file over when building the source package.
8:06 p.m.
On 26 May 2016, at 07:30, Ruben Undheim
<ruben.undheim(a)gmail.com> wrote:
Hi Holger!
Just a short answer from me this morning.
thank you. Let me merge your better/great description, manpages and symbols. In regard to
symbols files when and how to update it? Can you point me to the docs for that?
I don't have a total overview of the backwards
incompatible discrepancies. I probably should have, but hopefully there aren't too
many.
It's okay, we can have a flag day once if we keep compat after.
No, I don't have any experience. But technically,
it shouldn't be too hard. The debian dir in the upstream tarball will always be
overwritten when building the package, so whatever you do there, will be invisible in the
official package unless we manually merge it in.
Okay, but it would be somehow nice if our descriptions will not drift too much and we
re-use the same parts? Can you agree to that?
- At least for
OpenBSC you do not seem to package the -dbg symbols. As a developer I am always annoyed
(e.g. with sofia sip) when I can't install the debug symbols.
-dbg packages are now handled automatically by Debian. Any package with binaries, will
automatically get "-dbgsym" packages. Just google it. This is also the case for
Ubuntu AFAIK. This will however not be of any help for older Ubuntu and Debian releases
(if you desire to support them also with -dbg symbols) The extra debian dir is no problem. As said above, it
will be overwritten automatically by the build tools when building the package. To move
forward: we just pull interesting stuff from each other's debian dir. However, it may
make sense to pull some things out of the debian dir and into the main source tree - for
instance the man pages.
Where would you put them? Makefile.am and install them? Shall we use asciidoc to generate
manpages?
holger
9:07 p.m.
In regard to symbols files when and how to update it?
Can you point me to the docs for that?
I use:
dpkg-gensymbols -plibname0 -Odebian/libname0.symbols -q
after building the package.
Then I open up the generated file debain/libname0.symbols and remove the debian
suffix from the version number ("-1"). See "man dpkg-gensymbols".
There might
be easier ways also that I'm not aware of.
I don't
have a total overview of the backwards incompatible discrepancies. I probably should have,
but hopefully there aren't too many.
It's okay, we can have a flag day once if we keep compat after. Okay, but it would be somehow nice if our descriptions
will not drift too much and we re-use the same parts? Can you agree to that?
Whenever integrating a new upstream release, I do a diff with the previous
version. This is mainly to see if any copyright information has changed, but I
will also spot changes to the packaging, and therefore the descriptions. I do
of course agree to keep it in sync.
finally! I never understood (okay compats) why so many
packages don't have a -dbg(sym). Should -dbgsym packages be listed on
https://packages.debian.org/source/sid/openbsc? So even when going to a mirror I don't
see a -dbgsym package next to the other packages? Does one need to raise the compat
version for it?
One of the reasons mentioned for implementing automatic -dbgsym packages was to
prevent waste of disk space on mirrors, so the -dbgsym can be found on some
separate servers only and not on every mirror. You'll have to add it explicitly
to /etc/apt/sources.list
The extra
debian dir is no problem. As said above, it will be overwritten automatically by the build
tools when building the package. To move forward: we just pull interesting stuff from each
other's debian dir. However, it may make sense to pull some things out of the debian
dir and into the main source tree - for instance the man pages.
Where would you put them? Makefile.am and install them? Shall we use asciidoc to generate
manpages?
9:10 p.m.
On 26 May 2016, at 21:07, Ruben Undheim
<ruben.undheim(a)gmail.com> wrote:
I hope to get the osmo-bts formal stuff done soon, so
it can get uploaded, and
then everything for a base station will be available in the official archive!
great. Please ping us before so we can tag a release that is closer to master than the
last tagged version.
holger
9:18 p.m.
I hope to get
the osmo-bts formal stuff done soon, so it can get uploaded, and
then everything for a base station will be available in the official archive!
great. Please ping us before so we can tag a release that is closer to master than the
last tagged version.
30 May
30 May
9:27 p.m.
Hi Holger,
It went very quickly this time. osmo-bts was accepted into Debian before I got
the time to tell you that it had been uploaded!:
https://tracker.debian.org/pkg/osmo-bts
Now is the time to make a new tag if you want something more fresh in there.
Then both openbsc, osmo-bts and osmo-trx are in Debian making it possible to have
a complete base station with an "apt get".
One test case fails ("bursts") for the architecture ppc64el. Unfortunately I
forgot to add the code snippet to d/rules which dumps out the test case log.
https://buildd.debian.org/status/fetch.php?pkg=osmo-bts&arch=ppc64el&am…
Best regards,
Ruben
On Thu, May 26, 2016 at 09:10:38PM +0200, Holger Freyther wrote:
On 26 May 2016, at 21:07, Ruben Undheim
<ruben.undheim(a)gmail.com> wrote:
I hope to get the osmo-bts formal stuff done
soon, so it can get uploaded, and
then everything for a base station will be available in the official archive!
great. Please ping us before so we can tag a release that is closer to master than the
last tagged version.
holger
3309
days inactive
3315
days old
8 comments
2 participants
participants (2)
-
Holger Freyther -
Ruben Undheim