Project

General

Profile

Bug #3176

osmocom debian packages are not install / upgrade tested

Added by laforge 3 months ago. Updated 3 months ago.

Status:
New
Priority:
Normal
Assignee:
sysmocom
Target version:
-
Start date:
04/16/2018
Due date:
% Done:

0%

Estimated time:
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


Related issues

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

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

History

#1 Updated by laforge 3 months ago

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

#2 Updated by laforge 3 months ago

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

#3 Updated by laforge 3 months ago

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

#4 Updated by laforge 3 months ago

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

#5 Updated by neels 3 months 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?

#6 Updated by zecke 3 months 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.

#7 Updated by laforge 3 months 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.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)