[01:52] <jo-erlend> LocutusOfBorg, hey, that's great! Thank you very much!:)
[09:12] <gdalusr> there seems to be a QGIS or QT packaging bug in ubuntu (atleast 18.04), when installing it in docker it crashes because it can't find libssl1.0
[09:13] <gdalusr> I assume it's masked as an issue, because on a normal desktop libssl1.0 get's installed by something else
[09:28] <gdalusr> https://stackoverflow.com/questions/42094214/why-is-qsslsocket-working-with-qt-5-3-but-not-qt-5-7-on-debian-stretch might be related
=== didrocks999 is now known as didrocks
=== sem2peie- is now known as sem2peie
[13:51] <bluca> when a package has multiple autopkgtest tests/suites, does the CI have any facilities for running them in parallel?
[13:52] <bluca> (looking at more ways to speed up the systemd-ci autopkgtest runs)
[13:52] <ddstreet> no, but for the ubuntu ci infrastructure it wouldn't make sense to, since by default test instances are m1.small (1 cpu)
[13:53] <ddstreet> (which i've tried to increase for systemd/systemd-upstream...unsuccessfully, so far)
=== sem2peie- is now known as sem2peie
[13:56] <gdalusr> I wonder if it's possible to test if packages work in side docker containers, that way maybe it's easier to see missing dependencies
[13:58] <bluca> ddstreet: given autopkgtest accepts the test suite name as argument, would it be feasible to add multiple hooks/calls?
[13:58] <bluca> ie, instead of bionic-arch have bionic-arch-suitefoo bionic-arch-suitebar
[13:59] <bluca> doesn't even need to be a full matrix, just 2 sets would already help a lot
[14:00] <ddstreet> it's not possible with the current autopkgtest-cloud code, i don't think: https://code.launchpad.net/autopkgtest-cloud
[14:00] <ddstreet> IIRC, the test submissions from github don't allow specifying a test name
[14:00] <ddstreet> the autopkgtest cmd line does though
[14:00] <ddstreet> of course, the code could be changed to do it
[14:02] <ddstreet> bluca hmm i had it backwards, the github submissions do allow specifying 'testname' it appears: https://git.launchpad.net/autopkgtest-cloud/tree/webcontrol/request/submit.py
[14:02] <ddstreet> the 'validate_git_request' function is what handles the systemd ubuntu ci tests
=== zyga_ is now known as zyga
[14:03] <bluca> so we are missing hooking that into the autopkgtest call?
[14:07] <ddstreet> bluca i'm unable to test the github test submission path, so i can't say if it works for sure or not, but reading the code it appears to pass the 'testname' param on to the autopkgtest runner, which would allow restricting the test run to a single one of the tests in the debian/tests/ dir
[14:08] <ddstreet> if the systemd github ci config was updated to add the 'testname' param it should work, i think - but i believe that would affect all PRs
[14:09] <bluca> can it be passed multiple times?
[14:09] <cpaelzer> doko: on the test rebuilds already 2/4 cases I've looked at have issues like "error: lto-no-text-in-archive: debian/lib" is that something kown/common and has a comman pattern to be resolved?
[14:10] <bluca> thinking whether we can have 2 jobs per arch with multiple suites, or if it must be one job per suite
[14:11] <ddstreet> no, it looks like it can be only used once
[14:11] <bluca> mmh bummer
[14:12] <bluca> would it be worth trying? the github actions CI already lists every job separately
[14:12] <bluca> the list would get verboser, but it already is
[14:15] <bluca> there's 14 suites, times 5 archs is quite a lot...
[14:15] <ddstreet> yeah, and i suspect Laney would not like systemd-upstream ci tests taking up 90 times more test instances than it currently does
[14:16] <bluca> eheh true
[14:16] <ddstreet> there has been resistance already to my request to just increase each instance from 1cpu to 4cpus due to resources
[14:16] <doko> cpaelzer: which ones?
[14:16] <bluca> is this running on canonical infra, or public cloud (payed by canonical)?
[14:17] <ddstreet> canonical infra
[14:17] <doko> cpaelzer: in the normal test rebuild?
[14:17] <ddstreet> it runs on the same hw as tests for our distro packages
[14:17] <bluca> I see
[14:18] <bluca> well I'll keep making improvements to the suite upstream
[14:18] <bluca> with some changes from yesterday, those suites should already take half the time they used to
[14:18] <bluca> there's some more things I can do to reduce runtime a little
[14:19] <bluca> if you can think of anything we can do cloud-side and want to experiment, let me know
[14:19] <ddstreet> yep will do, and i'll try to get back to the qemu PR, i think that'll help speed things up
[14:20] <bluca> which one?
[14:20] <ddstreet> https://github.com/systemd/systemd/pull/13409
[14:21] <ddstreet> did you get a change in for that already? i haven't looked at all since i got back from the holidays
[14:21] <bluca> no most of those should still be good
[14:21] <bluca> what I did was adding a mode to run most tests under nspawn, and to avoid rebuilding the same iamge over and over again
[14:22] <bluca> so now only half a dozen or so tests use qemu, the rest use nspawn
[14:22] <ddstreet> excellent that's good, qemu was really slowing it down
[14:22] <ddstreet> even with kvm, i'm pretty sure nspawn will be faster
[14:22] <bluca> yep that's why it's 2x as fast :)
[14:23] <bluca> but there's some tests that really need qemu
[14:23] <bluca> so your changes would be really great to ahve too
[17:00] <doko> mitya57: could you give me a hint how to disabled a build with precompiled headers in e.g. qtdeclarative-opensource-src-gles ?
[17:25] <mitya57> doko: try adding -no-pch to configure options in d/rules
=== ijohnson is now known as ijohnson|lunch
=== ijohnson|lunch is now known as ijohnson