[01:24] slangasek: Pharaoh_Atem: fyi: https://3v4l.org/uMrcs [01:24] shows that the issue with zeta-console-tools test is an upstream thing, and probably something that is "expected", but shoudl be adjusted in their output [01:30] nacc: cool [01:59] hey cjwatson, I'm seeing a failure when doing an apt-get update for ppa:juju/devel on xenial (weak digest error). I found bug #1556666 and wondered if we had to push a new package to get InRelease resigned in that ppa? [01:59] bug 1556666 in Launchpad itself "PPA (In)Release files use SHA1 digests for GPG signature" [High,Fix committed] https://launchpad.net/bugs/1556666 [02:00] infinity ^^? === juliank is now known as Guest79559 === juliank_ is now known as juliank [02:38] cherylj: It needs fixing on the LP end, nothing you can do about it. [02:40] thanks, infinity [05:51] good morning [06:52] Morning! [07:31] Good morning [07:31] Mirv: landing-036 does not exist any more, I suppose this was taken care of already? [07:34] slangasek: there have been no testbed config changes on my side; in theory it could be that the QEMU config on the nova-compute side got changed somehow [07:34] slangasek: but if you can reproduce it locally, that error doesn't seem to be too specific to the qemu params in scalingstack [07:34] pitti: yes, we just forced QA:ing and publishing of it. no problem! [07:35] cjwatson: will look into it, this is tracked in bug 1558823 [07:35] bug 1558823 in Ubuntu "ddebs.ubuntu.com gpg signatures use sha-1" [Undecided,New] https://launchpad.net/bugs/1558823 [07:37] xnox: seems Stephane already approved your FFE [07:58] slangasek: ah, I get the same thing in apport now apparently [07:58] Failed to connect to Mir: Failed to connect to server socket: No such file or directory [07:58] ^ that? [08:19] good morning [08:34] morning all === rhuddie_ is now known as rhuddie [11:30] cherylj: there may be a period (which is not the case yet) in which pushing a new package is enough to get the PPA re-signed; but we're planning to do it in bulk [11:31] pitti: thanks [11:31] cherylj: Note that it's technically a warning, not an error [11:54] cking: #1527727 - I think Ned will release 0.6.5.6 early this week, the LLNL guys don't seem to work on weekends [11:55] dasjoe, yep, I emailed Ned for some clarification, but I will try and sync with 0.6.5.6 if it comes out this week for sure [11:59] cking: behlendorf asked me whether I was aware of any ZFS issues from Ubuntu which concerned the upstream ZFS on Linux project, neither rlaager nor me could name anything relevant [12:00] dasjoe, cool, thanks for that === xavigarcia is now known as xavigarcia_lunch [12:04] cking: one thing I've noticed, which may not be ZFS related, is grub-pc's installation fails when given multiple disks. I had to work around this for my installation: http://paste.debian.net/hidden/24d104e9/ - see line 173 [12:07] I didn't copy the error message, if I remember correctly grub-pc's normal installation process works for the first disk, then fails with "can't find /dev/disk/by-id/ata-xyz,", I assume the , breaks it [12:14] FYI: There doesn't seem to be any patches for GIT for CVE-2016-2324, CVE-2016‑2315 on Ubuntu 14.04 LTS [12:14] ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2324) [12:14] Sharcho: It's being worked on [12:15] mdeslaur: thanks [12:27] Laney: any idea about https://launchpadlibrarian.net/249221907/buildlog_ubuntu-xenial-amd64.gnubg_1.05.000-6_BUILDING.txt.gz ? seems to be introduced with the recent glib [12:34] doko: It's probably that de-duplicating thing [12:34] doko: Copy glib-gettext.m4 from glib or remove the local copy [12:47] Which team should I direct towards this bug? https://bugs.launchpad.net/ubuntu-mate/+bug/1559243 [12:47] Launchpad bug 1559243 in ubuntu-mate "Missing string translations for Ubuntu MATE flavour." [High,Triaged] [12:48] flexiondotorg: installer team. I'll have a look, I think I still remember how to do that [12:48] cjwatson, Thank you :-) [12:52] this signatures problem probably affects interaction with Debian too? meaning LP doesn't get updated information from Debian, so syncing of latest packages and such isn't possible. [12:53] "has not been picked up by LP yet" [12:53] pitti, http://paste.ubuntu.com/15401586/ <-- were you going to upload that ? [12:55] smoser: no, as I said it's the wrong way around; the Wants= should be added to units that want to run before the network is up [12:55] i. e. cloud-init in that case (according to systemd.special(7)) [12:55] oh. [12:55] hm.. that was the second part of my question. [12:56] i dont necessarily think its the wrong way around though. [12:56] I didn't read that properly when we talked about this [12:56] networking.service should want the network-pre.target to have been reached. [12:56] i'm sorry, i must have just misunderstood then. i can add Wants network-pre.target to cloud-init-local.service [12:57] no worries, it wasn't clear last week when we talked about it [12:57] one other question. [12:58] you can have multple 'Wants=' in a service [12:58] i think. [12:58] Wants=other-thing1 [12:58] Wants=other-thing2 [12:58] that multiline syntax does work, rigth? [12:59] is 'Wants=other-thing1 other-thing2' preferred for any reason ? [13:00] smoser: they are exactly identical [13:01] so just a matter of stylistic preference I guess [13:01] multi-line is nicer for patching or adding comments, but a bit more verbose [13:02] thats what i thought. [13:02] thanks. [13:05] xnox: FYI - LP: #1560024 [13:05] Launchpad bug 1560024 in s390-tools (Ubuntu) "/etc/kernel/postrm.d/zz-zipl fails when removing an old kernel" [Undecided,New] https://launchpad.net/bugs/1560024 === xavigarcia_lunch is now known as xavigarcia [13:10] Mirv: I explained that on ubuntu-devel recently. [13:18] * Mirv reads [13:22] flexiondotorg: Done; will require another upload to actually include localisations, so please remind us in a couple of weeks. [13:29] cjwatson, Thanks. But I can point translators at it now? [13:36] flexiondotorg: It'll probably take a little while before it's available for translation on LP. Check first [13:38] flexiondotorg: (https://translations.launchpad.net/ubuntu/xenial/+source/gfxboot-theme-ubuntu/+pots/bootloader, pick random language, search for mate) [14:06] pitti: yeah, wasn't a testbed change, turns out it was a genuine regression between glibc and mesa due to use of swrast on single-CPU VM guests (LP: #1559842) - thanks for looking though [14:06] Launchpad bug 1559842 in glibc (Ubuntu Xenial) "SIGFPE in pthread_barrier_destroy in glibc 2.23" [Critical,Triaged] https://launchpad.net/bugs/1559842 [14:08] slangasek: ah, thanks for the pointer! that means now that mesa is in it's worth retrying the failures? [14:08] slangasek: although the glibc task of the above bug is still open, does this need a glibc fix too? [14:08] slangasek: I tried to locally run apport against all of -proposed, and it seemed to work [14:08] (some 3 hours ago maybe) [14:09] cjwatson: I suppose it's ok to use syncpackage --no-lp for the time being? [14:09] pitti: yes, any of the autopkgtests that have regressed with glibc on amd64+i386 should be retried [14:09] slangasek: ack, doing [14:10] pitti: and the glibc task can be closed, I didn't clean that up before I went to bed [14:10] in fact, I retried a few already, and so did infinity [14:10] yep [14:10] pitti: hopefully not with --all-proposed though ;) [14:11] I might have done apport [14:11] but *shrug*, whatever makes them pass :) [14:12] pitti: Yes, though I just requested a deployment with the gina fix so if I can twist a webops' arm then it should hopefully be sorted out today [14:13] pitti: i.e. if it's not urgent it would be preferable to wait [14:13] cjwatson: no, it's not; thanks [14:28] pitti: So, the apport test still fails, for slightly different reasons. The rest seem to have been fixed by Steve's mesa. [14:30] infinity: indeed, a lot less red on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#glibc now; I'll look at apport, but this indeed looks unrelated now [14:31] pitti: Well, it's unrelated to the thing Steve fixed, but if you previously expected xvfb to exit and now it doesn't, either your assumption was silly or something is still a bit goofy. [14:31] AssertionError: 'no debug symbol package found for coreutils\n' != '' [14:31] infinity: no, the only two failures are in backend_apt_dpkg [14:31] search for ====== [14:32] the xvfb message at the end is normal (just for debugging) [14:32] not sure what's up with coreutils' ddebs [14:33] pitti: Oh. [14:33] pitti: Tests with ddebs are busted because you need to re-sign ddebs.u.c with a less crap key, IIRC. [14:34] infinity: I did this morning [14:34] pitti: Oh, so we should retry crash and see how it likes it? [14:34] see bug 1558823 [14:34] bug 1558823 in ddeb-retriever "ddebs.ubuntu.com gpg signatures use sha-1" [Medium,Fix released] https://launchpad.net/bugs/1558823 [14:34] infinity: I didn't look at crash's regression yet, but if that was it it's worth retrying indeed [14:35] pitti: crash was much whining from apt, followed by "E: some indexes not updated", so yeah. Pretty sure your new key will fix that, if apt now loves i. [14:35] s/i./it./ [14:42] infinity: hmm, http://keyserver.ubuntu.com/pks/lookup?op=get&fingerprint=on&search=0xC8CAB6595FDFF622 exists now, but I can't say for how long already [14:50] I will be filling a needs packaging FFe in a bit. Can some just confirm I've got the version numbering correct? [14:50] http://bazaar.launchpad.net/~ubuntu-mate-dev/ubuntu-mate/topmenu-qt/view/head:/debian/changelog [14:50] I realise the ~xenial1.0 suffix needs to be dropped. [14:50] This package is not going into Debian, so I want the confirm I've got the -0ubuntu1 bit right. [14:53] flexiondotorg: -0ubuntu1 is correct for something where our upstream is ahead of Debian, yes. [14:53] infinity, Thanks. This package will be entirely absent from Debian. [14:55] pitti: crash's tests might be statically configured to pull the old key or something. [14:55] * infinity looks. [14:56] pitti: Yeah, it is. [14:56] infinity: hm, perhaps this should pull http://ddebs.ubuntu.com/dbgsym-release-key.asc instead? [14:57] pitti: Maybe. What's the recommended way for people to get the key on live systems? [14:57] pitti: Should it perhaps be packaged instead, so there's a trusty path? [14:57] s/trusty/trust/ [14:57] I updated the key ID on https://wiki.ubuntu.com/DebuggingProgramCrash this morning [14:58] but that won't magically fix people's scripts indeed [14:58] infinity: hmm, we could put it into ubuntu-keyring [14:59] pitti: Yeah, in a split file, perhaps, the way debian-archive-keyring is now laid out. [14:59] does merely adding it to /usr/share/keyrings/ actually helps? I thought apt would expect them in /etc/apt/trusted.gpg.d [14:59] slangasek: i'm going to file a bug upstream for that php-zeta-console-tools failure, I think. Let me see if I can patch the testrunner to skip that error [15:00] pitti: apt wants them either added to the master keyring or in a trusted.d keyring, yes. [15:00] pitti: ubuntu-keyring adds its own keys to the master keyring. But shipping a snippet in trusted.d (like debian-archive-keyring does) might be better for ddebs. [15:01] pitti: Anyhow, I'm going to "fix" crash the naive and simple way for now, but I think shipping a proper keyring would be smart. And we'll need to look at fixing stables too. :/ [15:01] pitti: Or you could double-sign ddebs with old and new key, so the old one still works on stables. [15:01] pitti: Which might not be awful. [15:03] pitti: double-signing seems less evil than telling everyone to fix their stable machines that they manually configured. [15:03] pitti: And no risk of regression (ie: falling back to the old key) on >= xenial, since apt will outright reject the old key anyway. [15:04] pitti: Then we can work on doing it "right" in xenial, by shipping a key in the archive. [15:06] ok, that needs some reenginering (going from "just call gpg" to "call it with multiple configurable keys") [15:07] Wht has replaced libqt4-private-dev in Xenial? [15:07] I need some headers that package typically provides. [15:13] mpt: Do you have a moment to discuss that user page in the error tracker? [15:17] flexiondotorg: per the changelog, debian 4:4.8.7+dfsg-1 [15:18] flexiondotorg: " * Remove libqt4-private-dev. The only package using it is gammaray (#763852) [15:18] which at the moment of this writing has it fixed in it's repo." [15:18] nacc, Thanks. Well, that's dissapointing :-( [15:21] mpt: Well, I'm happy to change labels of columns and reorder them - just let me know. [15:22] bdmurray, sure [15:22] bdmurray, what did you mean by “Recorded”? [15:22] " I took "Recorded" to mean the time that the server received them and "Occurred" to mean when the crash actually happened on the client." [15:23] mpt: so recorded in the database [15:24] Ah, I see [15:24] So you were thinking in terms of the database, I was thinking in terms of the client [15:24] pitti, i've got another update of stress-ng i'd like to sync to Xenial under a FFe, bug 1560065, I was wondering if you could eyeball it [15:24] bug 1560065 in stress-ng (Ubuntu) "[FFE]: stress-ng: sync to 0.05.21 form 0.05.19" [Medium,In progress] https://launchpad.net/bugs/1560065 [15:24] pitti: It's hopefully easily reinventable, but just in case, lp:ubuntu-archive-publishing's code for doing this isn't too impenetrable [15:24] cking: I have zero concern about getting new stress-ng versions [15:24] (Since it doesn't bother with the "configurable" bit) [15:25] cking: responded for the records [15:25] bdmurray, so how about “Occurred” and “Sent”? Would that be less ambiguous? [15:25] ppisati, ok, shall I just sync it in then? ;-) [15:26] done [15:26] mpt: my issue with sent was the report could be sent multiple times and if something was wrong with the database it wouldn't get recorded / received. [15:27] bdmurray, ok, “Occurred” and “Received”? :-) [15:27] mpt: also thinking about it the not occurred time is in UTC which really wouldn't be the sent time. [15:27] understood [15:27] I noticed the different time zones [15:28] mpt: sure, Occurred and Received, in which order and with which as a link? [15:30] bdmurray, chronological order of occurrence I think — that way, the one at the top will nearly always correspond to the last time the user clicked “Send” (unless the DB is read-only or something weird like that) [15:31] (the last time they clicked “Continue” with sending agreed to, I mean) [15:33] mpt: okay, thanks! [15:33] you’re welcome, thanks for indulging me :-) [15:42] bdmurray, …I just noticed that I had previously written “Error reports should be listed in the order they were received”, but I can’t remember why I did [15:43] bdmurray, what would happen if your system clock was accidentally set to the year 2028 when you submitted an error report? Would it sit at the top of the list for 12 years? [15:48] slangasek: LP: #1560092 filed, with debdiff that passes the testsuite here [15:48] Launchpad bug 1560092 in php-zeta-console-tools (Ubuntu) "Workaround PHP bug #71870" [Low,In progress] https://launchpad.net/bugs/1560092 [15:48] mpt: I have it sorting by received in the database so the system clock being wrong wouldn't matter. [15:50] Ok, so I was wrong about “chronological order of occurrence” above. I’ll leave that sentence untouched. :-) === roaksoax-afk is now known as roaksoax [15:57] Pharaoh_Atem: https://bugs.php.net/bug.php?id=71870, just got fixed yesterday :) [16:00] Odd_Bloke: Have you tried a powerpc cloud image with the -14 kernel yet? [16:00] infinity: Not yet, no. [16:00] Odd_Bloke: Were those manual builds, or automated? [16:01] Odd_Bloke: If the latter, can I get a pointer to one that might work, if the former, want to spin a fresh one? [16:06] infinity: Manual; I'll (probably) have to rebase my livecd-rootfs changes on top of what's in place now (which has had a bit of a refactor); I'll try to have something for (your) tomorrow morning. [16:08] Odd_Bloke: Sure. No huge rush. Would just love to have this resolved by xenial release, so we can drop the P7 machines off a cliff. [16:08] (or mail them back to IBM) [16:38] meh, it seems I somehow broke ddebs.u.c. :( [16:39] * pitti files an RT, perhaps we happen to have a backup [16:40] pitti: ...? [16:40] pitti: Did you wipe out your archive? [16:40] it seems trusty's indexes only have those packages which have the same version in xenial [16:40] Ouch. [16:40] Laney | pitti: laney@nightingale> for r in trusty xenial; do echo -n "${r}: "; GET http://ddebs.ubuntu.com/dists/${r}/main/binary-amd64/Packages | grep-dctrl -c .; done [16:40] Laney | trusty: 121 [16:40] Laney | xenial: 3021 [16:40] That seems ungood. [16:40] doubleplusso [16:41] Is the pool also empty, or just the indexes? [16:41] the pool (otehrwise it would not be a big problem) [16:41] Ugh. [16:41] Not sure if IS backs that up. I guess you'll find out. :( [16:41] :( [16:42] We can reconstruct anything post-ddebs-in-librarian, but you may be SOL for history. [16:42] I hope I'm wrong. [16:42] But it was only a matter of time before the bubblegum slipped off that shoestring. [16:44] Unfortunately ddebs in librarian postdates trusty release. [16:44] cjwatson: Indeed. [16:45] But, hey, new LTS is upon us, if there's no backup, we can just fling our hands in the air, scream a collective "meh" and carry on knowing that xenial is debuggable. :P [16:45] It also presents an elegant solution to the "what do we do about all these loose ddebs with no strong relation to build records?" problem. [16:46] Which is, well. Nothing. Cause they're gone. [16:46] (silver lining anyone?) [16:46] hmm, what happened to gccgo on ppc archs in xenial? [16:46] "elegant" [16:46] cjwatson: :) [16:47] http://paste.ubuntu.com/15465001/ <- that looks promising to me though. [16:48] suggests that that whole tree is backed up. [16:48] Ah-ha. It does indeed. [16:48] wow [16:48] so a full recovery should be possible [16:48] pitti: Hit #is-outage and get them to freeze the backups in time ASAFP. [16:48] pitti: Cause if that's backing up with --delete, it's only a matter of time before the backup also goes poof. [16:49] (note "snapshot_mode: none") [16:49] dobey: i believe it's just go now? [16:49] pitti: This is too urgent for a ticket. [16:49] mwhudson: --^ do you have the answer to dobey's question? [16:50] nacc: https://launchpadlibrarian.net/249463768/buildlog_ubuntu-xenial-ppc64el.pay-service_15.10+16.04.20160321-0ubuntu1_BUILDING.txt.gz [16:50] turku defaults to retaining five days, I believe [16:50] nacc: "go: not found" doesn't sound like "it's just go now" :) [16:50] dobey: i meant based upon my reading of the logs of the channel from last week :) [16:50] ah, yes, but maybe not with snapshot_mode none [16:50] dobey: it's "supposed" to be ? :) [16:51] apparently I triggered a but when I told it to regenerate all indexes for the new gpg key [16:51] dobey: looking at my logs, either stgraber or mwhudson might have the context ... [16:51] s/but/bug/ [16:52] cjwatson: I'm not sure how that key is interpreted, to be fair, but the naive interpretation would be "oh shit". [16:52] cjwatson: (And a perfectly reasonable default for a backup of a deb archive...) [16:52] Quite. [16:54] slangasek: i believe we talked about this previously, but if Debian has/will be releasing a new 7.0.4-X, are you ok with merging to that (as it includes the backports of a few bugfixes), or would you rather i backport those directly to our current -X in ubuntu? [17:00] We're having some problems with our seeds (Ubuntu Studio). We've blacklisted a few unity packages, such as unity-control-center, as you can see here http://bazaar.launchpad.net/~ubuntustudio-dev/ubuntu-seeds/ubuntustudio.xenial/view/head:/blacklist. [17:01] ..but, we are still getting them on our ISO [17:01] Blacklisting isn't generally what you want. [17:01] Ok [17:01] Stop trying to use it. :-) [17:02] You need to arrange for apt to resolve alternative dependencies the way you want. [17:02] This normally involves ensuring that suitable alternatives are in the innermost possible seed whose expansion contains any of the packages with the alternative dependencies. [17:02] This can be a bit subtle and usually requires poring over germinate output in some detail. [17:03] cjwatson: Does it have to do with the order of seeds in the STRUCTURE file? [17:03] Yes. [17:03] Well, sort of. [17:03] It has more to do with their inheritance structure. [17:03] Right [17:04] The reason seed-level blacklisting isn't what you want is that apt doesn't know anything about it. At best it might cause an image build to fail or something as a circuit-breaker. [17:14] cjwatson: Thanks. Seems I have a lead. lighdm pulls in unity-greeter, which we have an alternative for === muktupavels_ is now known as muktupavels [18:24] @pilot in === udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: barry [18:25] pitti: Do you backport postgresql-common to old releases ever, or if I change it for xenial, can I just not worry about <= xenial legacy codepaths? [18:26] infinity: yes, it regularly gets auto-backported on apt.postgresql.org [18:27] pitti: Right, lecagy codepath it is, then. That's easy enough anyway. [18:27] infinity: and we keep it in sync, so if you change it for xenial we'll have to make that compatible with other D/U releases somehow [18:27] bug in mlmmj deb (package) "/usr/bin/mlmmj-recieve" and "/usr/bin/mlmmj-recieve" (no manual entry for mlmmj-receive) [18:27] bin dublicate filename bug. [18:27] pitti: Already in hand. Don't worry about it. [18:28] pitti: If it supports precise trusty vivid wily xenial, is that good enough, or do you backport for EOL releases too? [18:30] infinity: nope, p/t/w/x is fine [18:30] (and jessie/stretch/unstable of course) [18:31] * pitti waves good night [18:33] caribou: would you be able to review LP: #1552983 ? fairly trivial merge for logwatch [18:33] Launchpad bug 1552983 in logwatch (Ubuntu) "Please merge logwatch 7.4.2-1 from Debian" [Low,New] https://launchpad.net/bugs/1552983 [18:33] pitti: Sec, don't run away yet. [18:38] pitti: Still there? :P [18:38] * infinity guesses he ran fast. [18:38] * flexiondotorg sees dust. [18:38] he didnt run .. he waved away :) [18:39] showaz: as far as I can see mlmmj-recieve is the one without a manual entry, not mlmmj-receive, and since "recieve" is a misspelling that seems OK [18:40] showaz: though this is version-dependent. anyway, reporting bugs on IRC is not useful, bug reports go to Launchpad [18:40] cjwatson: docs only "mlmmj-receive" http://mlmmj.org/documentation/ [18:40] showaz: good! ignore mlmmj-recieve, looks like it's just there for backward compat [18:40] no doubt a historical mistake [19:23] nickserv identify digitsm [19:23] … [19:23] try again [19:23] momken: oops :) [19:23] and change your pw [19:23] preferably something a bit stronger, too [19:24] like 12345 [19:24] it's not my password [19:24] maybe Vu~W-f]zvOzY|57GGSMLe :D === momken is now known as digitsm [19:27] your password must be between 8-24 characters, and match the regex [A-Za-z0-9]+ [19:32] it's the websites where the 'change password' page will accept nearly anything, but the 'login' page doesn't work with certain characters that kills me [19:37] cjwatson, Just interested in how your wrangling is going with apt changes is going? [19:47] arges, Do you have time to review a pending upload for SRU in bug #1559307 [19:47] bug 1559307 in walinuxagent (Ubuntu) "[SRU] update walinuxagent to 2.1.3 in Wily" [Critical,In progress] https://launchpad.net/bugs/1559307 [19:48] rcj: in a bit [19:48] arges, thank you [19:52] pitti: gdnsd's i386 autopkgtest failure is curious; it's failing to install the package because it wants to start a systemd unit, which will fail if e.g. there's already a dns server installed and running on the system. Why do we not mask systemd services as part of autopkgtests (policy-rc.d)? [19:54] rcj: is the xenial task for walinuxagent is fixed? [19:55] removing the second is [19:55] arges, it's in xenial already [19:55] been there for a bit [19:55] sorry [20:08] infinity: back for a bit [20:09] pitti: Too late, I uploaded. :) [20:09] infinity, fyi, https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=2.23;users=debian-glibc@lists.debian.org [20:09] pitti: But do check the postgresql-common diff and grab it for Debian. [20:09] slangasek: err no, that would be entirely wrong -- the point of autopkgtests is to check that a package works, so not starting their services would certainly (for some packages)/hopefully (for many) break their tests [20:10] pitti: hmm, well, ok. what do you think we should do with gdnsd, then? Should the package conflict with e.g. dnsmasq? [20:11] doko: Pretty much all of those seem to be fallout from https://sourceware.org/bugzilla/show_bug.cgi?id=19439 [20:11] sourceware.org bug 19439 in math "Unix98 isinf and isnan functions conflict with C++11" [Normal,Resolved: fixed] [20:11] doko: And I think they probably all point to their upstreams being wrong, not glibc. But will have to go through and fix them all. [20:11] slangasek: if that's what it's conflicting with, yes; but I suppose that should rather be some C/R/P: dhcp-server virtual package or so? [20:11] pitti: dns server, not dhcp server [20:12] right, a simple apt-get install gdnsd fails in that manner [20:12] so, this spotted a packaging bug [20:12] gdnsd[1745]: Failed to bind() TCP DNS socket to 0.0. [20:12] question is why -- dnsmasq isn't even installed [20:13] (and we don't install it by default, only -base) [20:13] pitti: The follow-up question is why anything's bound to that on your adt VM. [20:13] we don't, as a rule, require packages to conflict with one another due to trying to provide services on the same port [20:13] oh, you see that failure even without dnsmasq? [20:13] tcp 0 0 10.0.3.1:53 0.0.0.0:* LISTEN 901/dnsmasq [20:13] hm, what's that [20:13] lsof -i TCP [20:14] ah, dnsmasq is running, owned by lxc-dns [20:14] ah, of course! we install lxc by default now [20:14] lxc-common in particualr [20:14] "we" do? [20:14] cloud images do [20:14] Only in cloud-image/server. [20:14] they ship all sorts of ... unnecessary stuff these days [20:14] Yeah, don't you already remove a bunch of cloud-image stuff we don't want in adt images? :) [20:15] yeah, I do [20:15] except on lcy01 [20:15] as building images is broken there [20:15] and it recently started failing on lgw01 as well (which is in some sort of semi-broken state) [20:15] I find "apt-get purge server^ && apt-get --purge autoremove" works well. [20:15] so before, depending on whether you ran on a minimal adt image or a standard cloud iamge it would pass or fail [20:16] infinity: pro tip, 'apt autoremove --purge server^' [20:16] Or that. [20:16] so I guess I'll add the purging of lxc/lxd to the setup commands again [20:16] it'll slow down every test, but avoid this [20:16] however, this just papers over the fact that the package still fails to install on a default server/cloud install [20:17] Any dns server will. [20:17] pitti: again, policy doesn't expect packages to conflict with other implementors of a network service just because they might want to share the same port [20:17] this definitely isn't gdnsd-specific [20:17] I'm inclined to think it's a bit of a bug that our default cloud/server install now binds to that port. [20:17] I hear people like to run DNS servers on servers. [20:17] well, it can be fixed either way (not make postinst fail if the port is taken, or conflict to other dns servers) [20:18] infinity: pitti: i can take it as an action to talk to the server team about it :) [20:18] nacc: Please do. [20:18] yep [20:18] pitti: I don't think packaging needs to be sorted for force conflicts all over, but I think cloud/server images binding to TCP:53 out of the box is a massive bug. [20:19] well, if you want lxc-net to work out of the box, you have to install a DHCP server [20:19] DNS, you mean. [20:20] but indeed it sucks a bit that you have to choose between "run a DNS server" and "use LXC" [20:20] infinity: henceforth I'll just call it D* :) [20:20] Surely, the solution is to only bind to TCP:53 on the lxc bridge. [20:20] Which shouldn't conflict with running a real DNS server on the host. [20:20] NMICT [20:20] infinity: unless that tries to bind on all interfaces? [20:22] hmm, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/g/gdnsd/20160320_184317@/log.gz actually *did* run on an adt image [20:22] ah, so apparently apt-get purge --auto-remove lxc does not remove lxc-common any more?! [20:23] yes, if lxc-net's dnsmasq was bound to the lxc bridge, another server coming along and binding to 0.0.0.0 should DTRT [20:23] ah, lxc1 now also depends on that, I guess I need to add to my ever-increasing purge list :) [20:23] slangasek: that sounds good [20:24] though I'm not sure if the lxc dnsmasq running only on the bridge IP is what's expected? questions of resolvconf integration [20:24] infinity: fwiw building valgrind from svn trunk doesn't get me anything that works any better [20:24] slangasek, so http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.xenial/view/head:/cloud-image [20:24] slangasek: Fun. [20:24] has ubuntu-snappy [20:24] slangasek: oh, how does that integrate with resolvconf? [20:24] now going to double-check whether this is a toolchain problem (rebuild current glibc with xenial) [20:25] why is that not installed in image ? [20:25] mwhudson: around? [20:25] smoser: Because ubuntu-snappy is in universe. [20:25] ok, purging lxc-common does the trick [20:25] smoser: So germinate will cull it out of the results as an unknown package. [20:25] i figured it would go in and create a component mismatch [20:25] ok. [20:26] :-( [20:26] smoser: it's listed in component-mismatches [20:26] but until it's in main it doesn't go on the image [20:26] I've been picking away at the MIR from the archive side over the past couple of days; ubuntu-snappy itself might be ready to go in now, I can look at that today [20:26] i expected the component mismatch, but thought it let it in and warn rather than ignore it. [20:26] smoser: http://people.canonical.com/~ubuntu-archive/component-mismatches.svg has a nice graph of it, FYI [20:26] ok. thank you all. so the other question related then, pitti hinted at [20:27] should we put 'ubuntu-server' into each of those seeds (cloud-image and server) [20:27] No. [20:27] Well, I put it in server already. [20:27] Didn't I? [20:27] Yeah, I did. [20:27] pitti: havne't read the whole backlog, but fwiw this week or next lxc-net should be removed from the seed again i think; [20:28] lxd will stop depending on it, and so it should get dropped automatically [20:28] at least that's my understanding [20:28] hallyn: lxc-common you mean? [20:28] infinity, yeah, you did. [20:28] i will add it now to cloud-image as it is desired ther also [20:29] pitti: that i'm not sure [20:29] pitti: but lxc1 [20:29] which has the lxc-net init job [20:29] hallyn: but I figure lxc and lxd actually do need lxc-net (i. e. a bridge with DHCP server) to work reasonably [20:29] lxd will stop using lxcbr0 so it won't be needed any more [20:29] no, lxd will not. [20:30] hallyn: oh, will the lxd-daemon have some builtin DHCP/DNS server then? [20:31] i think ipv6 only by default [20:32] nacc: rather than passing lots of flags to apt-cache rdepends, I bet you want to learn about grep-dctrl which has much more powerful filtering capabilities [20:35] slangasek, hallyn: hmm, lxc-net already uses --interface=lxcbr0 and listens on 10.0.3.1:53 only [20:36]