Project

General

Profile

Actions

Bug #3176

closed

osmocom debian packages are not install / upgrade tested

Added by laforge almost 6 years ago. Updated over 5 years ago.

Status:
Resolved
Priority:
High
Assignee:
Target version:
-
Start date:
04/16/2018
Due date:
% Done:

100%

Spec Reference:

Description

We've recently seen some packaging bugs related to library version handling / package naming in both the 'nightly' and the 'latest' feeds that could have been discovered months earlier by automatic testing.

This could e.g. be achieved by some dockefiles which would do things like
  • try to install all packages given feed (nightly or latest) from scratch on the respective base distro (debian 8/9, ...)
  • start with a docker image that has older versions of packages installed already (like nightly from a week ago, or the previous "latest" packages) and try to upgrade all packages

Of course there's no need for Docker, I just think it could come in handy for related tests


Checklist

  • get conflicts in the binary repo resolved
  • run --version on all osmocom binaries in the script
  • code review
  • merge to master
  • create Jenkins CI job that runs the script (once for latest, once for nightly)

Subtasks 3 (0 open3 closed)

OsmoBSC - Bug #3540: Conflicting Debian packages: osmocom-bsc-sccplite and osmo-bsc-mgcpClosedosmith09/10/2018

Actions
Bug #3543: Conflicting Debian packages: abisip-find and osmocom-ipaccess-utilsClosedosmith09/10/2018

Actions
OsmoBSC - Bug #3544: Conflicting Debian packages: osmo-bsc-* and osmocom-*Closedosmith09/10/2018

Actions

Related issues

Related to libosmocore - Bug #3175: Packaging: Upgrading libosmocore impossibel due to dpkg error overwriting libosmoctrl.so.0Resolvedkeith04/16/2018

Actions
Related to Cellular Network Infrastructure - Feature #1649: automatic nightly build of dpkgs for Debian GNU/LinuxClosedzecke03/11/2016

Actions
Related to Cellular Network Infrastructure - Bug #3541: Conflicting Debian packages: python3-osmopy-utils and osmocom-nitbRejectedosmith09/10/2018

Actions
Related to Cellular Network Infrastructure - Feature #3555: debian-repo-install-test: check if binaries report UNKNOWN as version stringResolvedosmith09/14/2018

Actions
Related to Cellular Network Infrastructure - Bug #3369: no automatic testing of Debian/Ubuntu packagesResolvedosmith06/29/2018

Actions
Related to Cellular Network Infrastructure - Feature #4563: install test for centos packages (like the debian install test)Resolvedosmith05/25/2020

Actions
Actions #1

Updated by laforge almost 6 years ago

  • Related to Bug #3175: Packaging: Upgrading libosmocore impossibel due to dpkg error overwriting libosmoctrl.so.0 added
Actions #2

Updated by laforge almost 6 years ago

  • Related to Feature #1649: automatic nightly build of dpkgs for Debian GNU/Linux added
Actions #3

Updated by laforge almost 6 years ago

  • Related to Bug #3160: /usr/local/lib/libosmocore.so: undefined reference to `clock_gettime' collect2: ld returned 1 exit status added
Actions #4

Updated by laforge almost 6 years ago

  • Related to deleted (Bug #3160: /usr/local/lib/libosmocore.so: undefined reference to `clock_gettime' collect2: ld returned 1 exit status)
Actions #5

Updated by neels almost 6 years ago

What confuses me about this is that we do use docker images that install nightly packages for the docker-playground ttcn3 tests.
On my machine, I rebuild those images many times a week, and I have so far not seen a single failure to install nightly packages via apt.
What am I doing "wrong" to be missing the packaging failures that users reported?

Aren't our ttcn3 jobs rebuilding the "osmo-foo-master" docker images?
They should see the nightly package updates and rebuild every day, right?
And if they fail, hopefully the jenkins jobs result in failure?

Actions #6

Updated by zecke almost 6 years ago

I assume docker doesn't do upgrades but installs the packages from a clean debian state? The easiest to reproduce would be to put old packages into a docker container and then always upgrade from this old version to a new one (and generate new versioned containers every n-weeks.. to have a kind of rolling upgrade test...)

But doing "full" upgrade tests is complex one would need to upgrade from any combination of base packages to any combination of upgrades. That feels like being 100 or more testcases (sure can be automated but complexity in a test is not nice. E.g. ttcn3 is appealing because it is real programming but that comes at the cost of needing a test for your test). What might be better and easier is to enforce certain packaging standards.

A libfoo.so.3.1.0 should always be in a package called libfoo3? A binary should be in a NAME package.

Actions #7

Updated by laforge almost 6 years ago

On Tue, Apr 17, 2018 at 12:34:42PM +0000, neels [REDMINE] wrote:

What confuses me about this is that we do use docker images that install nightly packages for the docker-playground ttcn3 tests.

good point.

On my machine, I rebuild those images many times a week, and I have so far not seen a single failure to install nightly packages via apt.

same here. I've never seen any problem whatsoever.

What am I doing "wrong" to be missing the packaging failures that users reported?

maybe:
  • we're typically only installing a single program + its library dependencies,
    i.e. not testing to install all programs at once
  • we're not installing osmo-nitb, as we don't do ttcn3-testing for it
  • we don't test "latest"

Aren't our ttcn3 jobs rebuilding the "osmo-foo-master" docker images?
They should see the nightly package updates and rebuild every day, right?
And if they fail, hopefully the jenkins jobs result in failure?

yes.

Actions #8

Updated by laforge over 5 years ago

  • Assignee changed from 4368 to osmith
Actions #9

Updated by laforge over 5 years ago

  • Priority changed from Normal to High
Actions #10

Updated by osmith over 5 years ago

  • Status changed from New to In Progress
Actions #11

Updated by osmith over 5 years ago

  • % Done changed from 0 to 50

Getting a list of all packages in the repository and installing them in a plain debian:stretch container is working:

https://gerrit.osmocom.org/#/c/docker-playground/+/10862/

However, some packages are conflicting with others. So further development is blocked until that is resolved. I will open new issues for the conflicts.

Actions #12

Updated by laforge over 5 years ago

On Mon, Sep 10, 2018 at 12:57:37PM +0000, osmith [REDMINE] wrote:

However, some packages are conflicting with others. So further development is blocked until that is resolved. I will open new issues for the conflicts.

Looking forward to that.

TODO:

minor stylistic note: It makes sense to add thse as checkbox items to this ticket, rather than
in the body/description.

Actions #13

Updated by osmith over 5 years ago

  • Blocked by Bug #3542: Conflicting Debian packages: soapysdr0.5-module-lms7 and soapysdr0.6-module-lms7 added
Actions #14

Updated by osmith over 5 years ago

  • Checklist item get conflicts in the binary repo resolved added
  • Checklist item run --version on all osmocom binaries in the script added
  • Checklist item code review added
  • Checklist item merge to master added
  • Checklist item create Jenkins CI job that runs the script (once for latest, once for nightly) added

It makes sense to add thse as checkbox items to this ticket, rather than
in the body/description.

Thanks for the hint, done!

Actions #15

Updated by neels over 5 years ago

About the conflicts between openbsc.git and the newer gits, if you can't find the origin of these packages automatically:
It would be ok to keep a manual list of packages to ignore. We aren't really interested in testing the openbsc.git derived packages.
So you can still discover packages automagically, and skip all those we know to be derived from openbsc.git.

(Once that works, we can still consider checking the old packages in a separate step.
But we don't want to spend time on openbsc.git anymore, and those aren't likely to change anyway,
so that's very very optional.)

Actions #16

Updated by osmith over 5 years ago

So you can still discover packages automagically, and skip all those we know to be derived from openbsc.git.

This makes sense, I'll close the OpenBSC conflict related issues (#3540, #3543, #3544) and implement it like that.

Thank you very much for going through all these issues, neels!

Actions #17

Updated by osmith over 5 years ago

  • Related to Bug #3541: Conflicting Debian packages: python3-osmopy-utils and osmocom-nitb added
Actions #18

Updated by osmith over 5 years ago

  • Checklist item get conflicts in the binary repo resolved set to Done
  • Checklist item run --version on all osmocom binaries in the script set to Done
Actions #19

Updated by osmith over 5 years ago

  • % Done changed from 50 to 80

Code is ready for review

(I've set this to 80% instead of 90%, because the Jenkins job is still missing to complete this issue.)

Actions #20

Updated by osmith over 5 years ago

  • Related to Feature #3555: debian-repo-install-test: check if binaries report UNKNOWN as version string added
Actions #21

Updated by osmith over 5 years ago

  • Checklist item create Jenkins CI job that runs the script (once for latest, once for nightly) set to Done
Actions #23

Updated by osmith over 5 years ago

  • Checklist item code review set to Done
  • Checklist item merge to master set to Done

Almost finished - the only missing piece is the jenkins job builder config getting merged to master:

https://gerrit.osmocom.org/#/c/osmo-ci/+/11031/

Actions #24

Updated by osmith over 5 years ago

  • % Done changed from 90 to 100
Actions #25

Updated by osmith over 5 years ago

This is finished now. I can't set the status to "Resolved" though, there's only "New", "In Progress", "Feedback", "Stalled".

Actions #26

Updated by laforge over 5 years ago

On Thu, Sep 20, 2018 at 08:20:33AM +0000, osmith [REDMINE] wrote:

This is finished now. I can't set the status to "Resolved" though, there's only "New", "In Progress", "Feedback", "Stalled".

please try again, should work now.

Actions #27

Updated by osmith over 5 years ago

unfortunately not, I've also logged out and in again to make sure.

Actions #28

Updated by osmith over 5 years ago

laforge: can you set this to resolved/closed, or how to we proceed here?

Actions #29

Updated by laforge over 5 years ago

On Tue, Sep 25, 2018 at 09:52:26AM +0000, osmith [REDMINE] wrote:

laforge: can you set this to resolved/closed, or how to we proceed here?

I had changed your permissions, can you please try again?

Actions #30

Updated by osmith over 5 years ago

I had changed your permissions, can you please try again?

It is not working.

Actions #31

Updated by laforge over 5 years ago

On Thu, Sep 27, 2018 at 01:24:09PM +0000, osmith [REDMINE] wrote:

I had changed your permissions, can you please try again?

It is not working.

not for this particular ticket, which is quite special as it has subtasks and
lots of special rules apply. In fact, not even I with admin privileges can
change that ticket status.

One thing that made me puzzled that all of the subtasks were closed at 0%
completion, which is very odd. I changed it to 100% on all subtasks, but
without any success.

Actions #32

Updated by laforge over 5 years ago

osmith wrote:

I had changed your permissions, can you please try again?

It is not working.

The problem is that the ticket is "Blocked by #3542". So you first need to close that one, and then you can close this.

Initially, your permissions were wrong so you couldn't close #3542 or this one. I guess after I changed permissions you only tried this ticket without checking the one blocking this issue?

Actions #33

Updated by osmith over 5 years ago

  • Blocked by deleted (Bug #3542: Conflicting Debian packages: soapysdr0.5-module-lms7 and soapysdr0.6-module-lms7)
Actions #34

Updated by osmith over 5 years ago

  • Status changed from In Progress to Resolved

Initially, your permissions were wrong so you couldn't close #3542 or this one. I guess after I changed permissions you only tried this ticket without checking the one blocking this issue?

That is true, I did not try the other one. However, I tried it just now, and I still can't change anything in #3542, I can only leave a comment there.

But I did delete the "blocked by" relation, and now it allowed me to set the status to "Resolved".

Actions #35

Updated by laforge over 5 years ago

On Mon, Oct 01, 2018 at 09:25:13AM +0000, osmith [REDMINE] wrote:

That is true, I did not try the other one. However, I tried it just now, and I still can't change anything in #3542, I can only leave a comment there.

This is due to the fact that #3542 is a different osmocom sub-project.
OsmoSDR and/or its child projects rtl-sdr, gr-osmosdr, osmo-fl2k, gr-gsm
are all projects in which sysmocom is not involved, and where sysmocom
developers do not automatically get 'developer' privileges.
https://osmocom.org/projects/sdr will show you that the sysmocom
developers / employees are only listed in the 'Reporters' category.

Should sysmocom get involved in related projects, we could change that,
but I think in general it would be awkward to those projects and their
maintainers if employee status at sysmocm would automatically introduce
some role there.

I think the key problem is that this particular issue #3542 was filed in
the "Osmocom SDR" project. Sure, it affects SDR hardware or drivers,
but not the Osmocom SDR software projects, which I've listed above.
Sorry for the confusion :).

I'm moving it now.

But I did delete the "blocked by" relation, and now it allowed me to set the status to "Resolved".

great.

Actions #36

Updated by osmith over 4 years ago

  • Related to Bug #3369: no automatic testing of Debian/Ubuntu packages added
Actions #37

Updated by osmith almost 4 years ago

  • Related to Feature #4563: install test for centos packages (like the debian install test) added
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)