[00:27] <mwhudson> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) 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-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mwhudson
[01:27] <mwhudson> nacc: around still?
=== _salem is now known as salem_
=== PHLin is now known as PHLin-mtg
[02:46] <pkern> .win 5
=== salem_ is now known as _salem
[05:37] <cpaelzer> mwhudson: thanks for pinging again on even more clarification on bug 1546565 after pitti asked a few days ago
[05:37] <ubottu> bug 1546565 in openvswitch (Ubuntu Xenial) "Ownership/Permissions of vhost_user sockets for openvswitch-dpdk make them unusable by libvirt/qemu/kvm" [High,Triaged] https://launchpad.net/bugs/1546565
[05:37] <cpaelzer> mwhudson: TL;DR is please unsubscribe sponsors and SRU Verification
[05:37] <cpaelzer> mwhudson: I putt a decent summary in the bug so that the next that might come by only need to read the last comment and knows about the overall state
[05:46] <mwhudson> cpaelzer: ah ok :)
[05:46] <mwhudson> sponsors unsubscribed, i'm not in ~sru-verification so can't unsubscribe them
[05:47] <cpaelzer> mwhudson: thanks, this is one of the cases that became super urgent around release and then everybody kind of forgot about the open debdiff for the config example
[05:47] <cpaelzer> mwhudson: pitti: thanks for continuously pushing to get this into a proper state
[05:48] <cpaelzer> I think we are good now code- and bug-wise
[05:52] <mwhudson> heh
[05:52] <mwhudson> noone cares about poor yakkety, just xenial :-)
[05:52] <mwhudson> (well, i exaggerate, but only a bit)
[05:53] <mwhudson> RAOF: hey, i have an sru type question
[05:53] <mwhudson> RAOF: there is an sru for docker in xenial, which has failed autopkgtests on i386
[05:53] <mwhudson> RAOF: it's just a flaky test, now fixed in yakkety
[05:53] <mwhudson> RAOF: should i upload the fix to xenial as well?
[05:54] <mwhudson> well, upload the yakkety version + ~16.04
[05:54] <mwhudson> eh that sounds silly when i say it out loud
[06:18] <RAOF> mwhudson: If the yakkety version is just xenial-proposed + a fix for the flaky test, yes please.
[07:00] <pitti> Good morning
[07:00] <dholbach> hey pitti
[07:01] <pitti> cpaelzer: thanks!
[07:01] <pitti> hey dholbach, wie gehts?
[07:01] <dholbach> sehr gut - wie geht's dir? :)
[07:03] <pitti> dholbach: auch gut, danke; viele lange Fussball-Naechte, aber ist ja bald vorbei :)
[07:05] <dholbach> am Wochenende waren wir auf einer Hochzeit in Südtirol - da hatte das Fest dann doch etwas Konkurrenzveranstaltung, einige konnten dann doch nicht feiern, ohne immer wieder auf's Telefon zu schauen :-)
[07:07] <pitti> haha
[07:08] <cpaelzer> dholbach: gleiches Erlebnis auf einem 50sten Geburtstag - aber die hatten gleich einen Projektor aufgestellt
[07:10] <dholbach> bei 'ner Hochzeit hätte ich das jetzt schon etwas komisch gefunden :-)
[07:10] <sladen> aber das war nicht Deutschland zu spielen zum Abend?
[07:11] <sladen> (oder waren die Paren aus Portugal/Wales?)
[07:12] <cpaelzer> bei mir war es Sonntag mit FRA/ISL - Fußballverrückte brauchen wohl einfach alle Spiele :-)
[07:13] <cpaelzer> aber Ich vermute Wochenendhochzeiten sind meist Samstags - also GER/ITA
[07:13] <pitti> aka "lose 5 years of your lifetime and all your fingernails" :)
[07:15] <cpaelzer> I'd so much would have liked to see what happens after all eleven players had shot their penality - I had fingernails left to stand it
[07:16] <pitti> the captains balance the ball on their head, and who can do that longer wins?
[07:17] <cpaelzer> do something for charity, they are all rich - the players spend personal money (secretly noted down), then they cound and the Team that spent most wins
[07:17] <cpaelzer> that way the Teamthat really want to win wins
[07:52] <michael-vb> Good morning.  I asked a question yesterday, but got no response.  See paste below:
[07:52] <michael-vb> (17:09:06) michael-vb: Afternoon.  Not sure if this is the right place to ask, but someone will probably know what is.
[07:52] <michael-vb> (17:09:06) michael-vb: I have the following problem with my VirtualBox Ubuntu 16.04 guest with development Guest Additions installed: when I start the guest I get the message "The system is running in low-graphics mode" (on VT 2) even though the X server is running fine (on VT 7).
[07:52] <michael-vb> (17:09:06) michael-vb: I would very much like to know exactly what logic triggers that message so I can work out why I am triggering it and change whatever is responsible (I am the developer of the VirtualBox guest driver and Additions installer).
[07:52] <michael-vb> (18:04:34) michael-vb: Interesting - I just booted the guest system twice with a loaded host (rebuilding VirtualBox) and did not get the "low-graphics mode" message.
[07:52] <michael-vb> (18:27:01) michael-vb: CRITICAL: session_get_login1_session_id: assertion 'session != NULL' failed in the lightdm log file.
[07:52] <michael-vb> (18:31:13) michael-vb: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814760
[07:52] <ubottu> Debian bug 814760 in lightdm "randomly fails to start" [Normal,Open]
[07:56] <sladen> michael-vb: https://irclogs.ubuntu.com/2016/07/06/%23ubuntu-devel.html#t15:09
[07:57] <sladen> michael-vb: http://askubuntu.com/questions/141606/how-to-fix-the-system-is-running-in-low-graphics-mode-error
[07:57] <michael-vb> Found that already.
[07:57] <michael-vb> I am wanting to understand this as a developer, not as a user.
[07:59] <michael-vb> sladen: it was following from that askubuntu question that I found the system log entry.
[07:59] <michael-vb> The session clearly gets started just after lightdm checks whether it is running.
[08:01] <michael-vb> As I said, this does not happen under high load.  I suppose the question is, who would understand this stuff well enough to tell me how I can avoid triggering it.
[08:01] <michael-vb> Or what causes the session to start too late, or lightdm too early.
[08:03] <michael-vb> I assume that some dependency is not specified well enough somewhere.
[08:03] <sladen> michael-vb: apt-get source lightdm && grep -r "Error message"   is probably the most effective way of identifing the logic causing the error (if it is coming from lightdm)
[08:03] <michael-vb> But it is annoying, because if it hits users they will blame us first, not you!
[08:04] <sladen> michael-vb: I'm not too familiar with the inner workings of lightdm; the developer was Robert Ancell in the DX team
[08:05] <sladen> michael-vb: if it's happening so of the time (seemingly randomly), then there's probably a race condition
[08:06] <michael-vb> I'm sort of suspecting that it is related to the change to systemd which upset some expectation in lightdm.
[08:08] <sladen> willcooke: if you're around later, could you get in contact with michael-vb (upstream developer of VirtualBox guest driver), about debugging and resolving the "The system is running in low-graphics mode" message.  https://irclogs.ubuntu.com/2016/07/07/%23ubuntu-devel.html#t07:52 onwards
[08:08] <michael-vb> willcooke: and michael dot thayer at oracle if I am not on IRC at that time.
[08:08] <michael-vb> sladen, willcooke: thanks.
[08:11] <willcooke> Trevinho, is this something you can help with? ^
[08:11] <willcooke> It looks like it's a problem with X rather than Unity though
[08:11] <willcooke> "problem"
[08:11] <willcooke> maybe tjaalton knows what triggers it? ^
[08:14] <tjaalton> I don't, if lightdm is randomly not starting on debian (which doesn't have "failsafe-x")
[08:15] <tjaalton> sounds like a lightdm bug to me
[08:17] <willcooke> oki
[08:17] <willcooke> thanks tjaalton
[08:30] <willcooke> michael-vb, Hmm, I can't see anything obvious here.  Please log a bug in Ubuntu against lightdm if there isn't already one, and we take take a look.
[08:30] <michael-vb> willcooke: to me it sounds like an init dependency problem.
[08:31] <sladen> michael-vb: can we get as much of the (known good) information into a Launchpad bug report
[08:31] <michael-vb> If I understood all this GNOME-systemd-login stuff better...
[08:31] <michael-vb> sladen: sounds reasonable.
[08:31] <sladen> michael-vb: and then get that linked to/from the debbugs and Askubuntu pages
[08:33] <michael-vb> Oh how nice, for reasons unknown I can no longer trigger it.
[08:33] <willcooke> \o/
[08:33] <willcooke> fixed!
[08:34] <willcooke> certainly smells like a race then
[08:34] <michael-vb> I think that is clear enough from the Debian bug.
[08:34] <michael-vb> I think that someone from the systemd camp would be best placed to solve it.
[08:36] <michael-vb> But before I open a bug report I will at least try to track down the error in the lightdm sources.
[08:39] <sladen> yes, it would be good to point in the bug report exactly where the origin of the assert is coming from, but if it can't be found, please file the bug report (and link to this IRC log and anytthing/everything that you've already found, so that we've got a trackable braindump in one place)
[08:40] <michael-vb> The assertion is easy to find, I am trying to logically work out the callers.
[08:42] <michael-vb> Ah, (about to show my lack of understanding of these things) is Ubuntu still using console-kit instead of systemd-logind?
[08:42] <michael-vb> I see "console-kit-daemon" in that Debian bug logging.
[08:44] <pitti> hell no
[08:44] <pitti> michael-vb: we switched to logind in saucy, I believe
[08:45] <pitti> oh, LXDE is still using it
[08:45] <michael-vb> Ah right, logging from systemd-logind there too.
[08:45] <pitti> (at least apparently)
[08:45] <michael-vb> This is an absolute plain Ubuntu installation.
[08:45] <pitti> then it shouldn't even be installed
[08:45] <michael-vb> No "L", "K" or anything else.
[08:47] <michael-vb> Got the error again.  Booting from power off did not produce it, clean rebooting did.
[08:48] <michael-vb> Will open a bug.
[08:49] <michael-vb> It would be good if I could find some way to at least avoid triggering the race, otherwise both we and you will have lots of annoyed users.
[08:51] <mwhudson> RAOF: yeah
[08:56] <cpaelzer> pitti: any hint where I do it wrong that my local adt is unhappy (http://paste.ubuntu.com/18689738/) while e.g. last build of the same looks good https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/c/clamav/20160706_174652@/log.gz
[08:57] <cpaelzer> I get the issue even if I just pull-lp-source and adt-run it, or is that just another case of me having not the bleddiest-edge autppkgtest :-)
=== zyga_ is now known as zyga
[09:21] <pitti> cpaelzer: hm, curious -- this is certainly not related to the autopkgtest version
[09:22]  * pitti runs autopkgtest clamav -- qemu /srv/vm/autopkgtest-xenial-amd64-cloud.img locally
[09:29] <pitti> cpaelzer: hm, works fine
[09:29] <pitti> cpaelzer: is that really the same clamav version in both cases? maybe your locally built package has some fancy/broken permissions on ./unit_tests/acc?
[09:48] <raphink> E: Failed to fetch http://fr.archive.ubuntu.com/ubuntu/pool/universe/n/npm/npm_3.5.2-0ubuntu4_all.deb  503  OUT OF DISK SPACE
[09:48] <raphink> looks like (one of) the French mirror  is out of space!
[09:50] <raphink> or the proxy…
[09:51] <raphink> more likely ;-)
[09:57] <cjwatson> yeah, that's a proxy somewhere
[09:57] <cjwatson> apache is not going to care that it's out of disk space when serving static files
=== hikiko is now known as hikiko|ln
[10:10] <cpaelzer> pitti: thanks for corss checking - I'll do a retest once more after it seems to work for you
[10:23] <cpaelzer> pitti: the following line fails for me, which I guess excludes local modification from the list of potential issues
[10:23] <cpaelzer> cd  /; rm -rf /tmp/test-adt-clamav; mkdir -p /tmp/test-adt-clamav; cd /tmp/test-adt-clamav; pull-lp-source clamav; adt-run --shell-fail --apt-upgrade --source clamav_0.99+dfsg-1ubuntu2.dsc --- adt-virt-qemu --cpus 4 --ram-size=2048 ~/work/adt-yakkety-amd64-cloud.img
[10:25] <cpaelzer> throwing into a lxd env now to see if it is any different
[10:27] <pitti> cpaelzer: oh, I tested xenial; as soon as my system load drops < 8 again, I'll re-test the y version
[10:27] <cpaelzer> pitti: sure - but for me it fails X&Y
[10:29] <cpaelzer> running with adt-virt-lxd adt/ubuntu/yakkety/amd64 triggers the same for me
[10:30] <cpaelzer> hmm, pitti is this permission denied happening at the host or guest level i.e. would running with sudo make any difference?
[10:30] <pitti> cpaelzer: no, that's something guest-level
[10:44] <cpaelzer> pitti: even more interesting, when running with -ddd on adr-run and -d on adt-virt-lxd it works
[11:20] <sladen> michael-vb: did you manage to work up a bug report?  Do you have the bug number in Launchpad so that it can be triaged?
[11:21] <cpaelzer> pitti: I got it working by adding the debug flags, and now I can remove them and it still works with the lxd case
[11:21] <cpaelzer> pitti: I'm running the kvm one just to be sure, but consider this strange issue resolved for now
[11:21] <cpaelzer> pitti: thanks for your help
[11:31] <cpaelzer> pitti: it keeps showing up in the kvm based adt - if your system load is low it would be nice to hear what happens for you if you just throw the same command I listed above at your system
[11:32] <pitti> cpaelzer: running
[11:33] <pitti> cpaelzer: my fingers protest about typing "adt-run", though :)
[11:35] <pitti> cpaelzer: also, calling adt to build the package is annoying and unnecessary..
[11:36] <pitti> but oh well, it's almost done now, doesn't take too long
[11:37] <cpaelzer> pitti: I wanted to stick close to what failed initially for me - of course to test what is in the archive could be done way more efficient :-)
[11:37] <pitti> cpaelzer: yep, get the same
[11:37] <cpaelzer> oh really
[11:37] <cpaelzer> pitti: bug report then?
[11:38] <cpaelzer> I got around it by switching to LXD and you neither want nor have to solve it like "now" - so I'd create a bug for you - ok?
[11:38] <pitti> yes (not sure whether against clamav or autopkgtest, but start with the latter -- reassinging is esay)
[11:38] <pitti> thanks
[11:38] <cpaelzer> ok
[11:38] <pitti> curious that -d helps, that sounds like an odd race
[11:39] <pitti> also, with -B it works fine, so the built package is somehow broken/strange
[11:39] <cpaelzer> pitti: well it only did in the lxd case, I'll put it in the bug
=== hikiko|ln is now known as hikiko
[12:09] <zyga> pitti: hey, how can I run autopkgtests from a source tree on 16.04 in a yakkety VM?
[12:23] <zyga> mwhudson: still around?
[12:23] <zyga> mwhudson: I broke my adt setup (it will be back in ~15 minutes) but have a look at this if you are around https://github.com/snapcore/snapd/pull/1504
=== _salem is now known as salem_
[12:34] <mdeslaur> doko: do we still need to keep blapi.h and alghmac.h in our libnss3-dev, or does openjdk-8 not use them anymore? (re: debian bug 754978)
[12:34] <ubottu> Debian bug 754978 in nss "please install the blapi.h and alghmac.h header files" [Normal,Open] http://bugs.debian.org/754978
[12:35] <mdeslaur> tjaalton: can you confirm we no longer need the shared cert and key databases in nss?
[12:35] <doko> mdeslaur, please ask tdaitx, probably won't have time for that during DebConf (and current SRUs ...)
[12:35] <mdeslaur> tdaitx: any idea? ^
[12:36] <tdaitx> mdeslaur, don't know about that, let me take a look
=== ivoks is now known as mirka
[12:41] <tdaitx> mdeslaur, openkjdk8 has no reference/includes to those files (in case it matters: openjdk 7 has a single reference to blapi.h)
=== mirka is now known as ivoks
[12:42] <mdeslaur> tdaitx: ok, thanks, I'll stop adding them then
[12:51] <tjaalton> mdeslaur: confirmed, freeipa-client uses a private one now
[12:51] <mdeslaur> tjaalton: great, thanks
[12:51]  * mdeslaur takes chainsaw to yakkety nss
[13:06] <cjwatson> does anyone know whether user namespaces are supposed to work properly when using precise lxd guests on a xenial host?
[13:10] <michael-vb> sladen: sorry, was away... #1599775
[13:10] <michael-vb> https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1599775
[13:10] <ubottu> Launchpad bug 1599775 in lightdm (Ubuntu) ""low-graphics mode" in VirtualBox guest, but X server running" [Undecided,New]
[13:10] <michael-vb> Right, was wondering how to trigger your bot.
[13:15] <michael-vb> sladen: thanks.
[13:44] <pitti> cjwatson: do you still remember the context of https://git.launchpad.net/~ubuntu-release/+git/britney2-ubuntu/commit/?id=a3b7baf3e ?
[13:45] <pitti> cjwatson: AFAICS this just matters when we have some self.options.fucked_arches, right? as otherwise the existing checks would already hold it back due to having missing builds
[13:46] <pitti> cjwatson: btw, I just converted the bzr branch to git and I'm now in rebase/patch review hell :)
[13:46] <pitti> as a precursor for merging to current britney, for getting support for versioned provides, etc.
[13:46] <cjwatson> pitti: I remember it being excruciatingly delicate, but I don't think it was to do with fucked_arches, it was something subtle about the set of built binaries changing between sources I think
[13:47] <cjwatson> I'm afraid I don't remember exactly
[13:47] <pitti> cjwatson: ok; nevermind
[13:47] <gQuigs> is the xenial archive fully locked for package removals?   just found out about "snappy" music player - our version is badly broken and it's been removed from Debian - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808518
[13:47] <ubottu> Debian bug 808518 in src:snappy-player "Please port to clutter-gst-3.0" [Serious,Fixed]
[13:47] <gQuigs> https://errors.ubuntu.com/?package=snappy&period=month
[13:47] <cjwatson> IRC logs from around that time might be informative, if you're lucky
[13:47] <gQuigs> it's also been removed from Yakkety already
[13:49] <cjwatson> not possible to remove from xenial I'm afraid
[13:49] <pitti> cjwatson: oh, turns out Debian actually has a  similar fix in http://anonscm.debian.org/cgit/debian-release/britney2.git/commit/?id=371ad0
[13:50] <cjwatson> pitti: I think that just changes the excuse text
[13:50] <gQuigs> cjwatson: k, just wanted to check, thanks!
[13:50] <cjwatson> it won't change whether something is a valid candidate
[13:51] <cjwatson> good luck working it out :)
[13:51] <pitti> cjwatson: right, but I I meant that our patch could/should now use uptodatebins
[13:51] <pitti> cjwatson: heh, thanks :)
[13:51] <pitti> it's only 290 patches or so to review, how long can it take..
[13:59] <pkern> .wub 8
[15:10] <michael-vb> willcooke: not sure what "trello" is, is it normal that I should not be able to access the link you added to the bug?
[15:10] <willcooke> michael-vb, yeah it's a task tracking system we are using
[15:10] <willcooke> michael-vb, dont worry about it - all important updates will go in to the bug
[15:11] <michael-vb> So short answer, yes it is expected.
=== JanC is now known as Guest55200
=== JanC_ is now known as JanC
=== olli_ is now known as olli
[17:27] <slangasek> mdeslaur: we missed a TB meeting this week, right?  I guess you didn't manage to un-break the calendar for it?
[17:27] <mdeslaur> slangasek: yeah, we missed it, nobody showed up. infinity was supposed to fix the calendar.
[17:27] <slangasek> ok
[17:31] <slangasek> calendar event recreated
[17:31] <slangasek> but need to get it on the fridge etc
[17:32] <slangasek> there, fridge added
[17:36] <mdeslaur> slangasek: thanks
[17:55] <nacc> tjaalton: would you be able to explain to me how/when the xserver-xorg-video-intel driver version was chosen for 16.04? Reading the version string, it seems to be a git snapshot from a particular date? In the context of LP: #1078068
[17:55] <ubottu> Launchpad bug 1078068 in xserver-xorg-video-intel (Ubuntu) "Video blinking blue during incoming call" [Undecided,Fix released] https://launchpad.net/bugs/1078068
[18:09] <tjaalton> nacc: yes it is
[18:09] <tjaalton> nacc: you need to bisect for that fix
[18:09] <nacc> tjaalton: ack, i'll do that once i know what fixes it :)
[18:09] <tjaalton> we're moving away from this driver in 16.10
[18:09] <nacc> tjaalton: as it worked for me, but one user already said it didnt' for them
[18:09] <tjaalton> to modesetting
[18:09] <nacc> tjaalton: ah ok
[18:10] <nacc> tjaalton: i'm afraid it's goign to be a large pile of changes (not just one) ... but will try and bisect later today
[18:10] <tjaalton> because there hasn't been a stable release in three years
[18:11] <nacc> tjaalton: i wondered :)
[18:13] <nacc> tjaalton: is there a good guide of installing from git for this driver?
[18:14] <tjaalton> clone debian packaging git
[18:14] <tjaalton> add upstream remote
[18:14] <juliank> pitti: http://autopkgtest.ubuntu.com/packages/a/apt/ lists a lost+found distribution...
[18:14] <tjaalton> hack away
[18:15] <juliank> I think we should have a Depends from apt on dpkg to have dpkg uploads trigger apt autopkgtest runs. Opinions?
[18:16] <juliank> (I don't think it currently does, I have a feeling 1.18.9 breaks the tests, but not sure...
[18:16] <nacc> tjaalton: thanks
[18:42] <infinity> juliank: Artificial deps for the sake of tests are wrong.
[18:42] <infinity> juliank: You can, however, make your *tests* depend on dpkg, and that'll end up in Test-Triggers.
[18:42] <juliank> infinity: That works fine for me
[18:44] <infinity> juliank: Which pitti hasn't yet implemented on the CI side, but it's on his TODO, I believe.
[18:44] <infinity> juliank: Ironically, this feature depends on the version of dpkg that broke your tests. ;)
[18:46] <slangasek> mitya57: how's the analysis going of the sphinx autopkgtest failures? I saw that breathe is a legitimate regression in -proposed; a re-test of the breathe package in yakkety passes, with sphinx 1.4.4-3 it fails
[18:50] <mitya57> slangasek, I will fix breathe (texlive-generic-extra was added to Build-Depends, but it should be in tests depends too)
[18:50] <zyga> h
[18:51] <mitya57> slangasek, … and we will be down to cryptography which has unrelated problems (something with python3-cffi-backend-api-{min,max})
[18:52] <slangasek> mitya57: right, I've triggered a no-proposed retest of python-cryptography as well to get us a baseline
[18:56] <mitya57> slangasek, breathe uploaded; thanks!
[19:10] <nacc> tjaalton: sorry for being dense, first time trying to bisect a package; i have the remote upstream and the good/bad points. But as it bisects, it puts me (as expected) into the upstream tree, which has no debian/ directory. So would i bisect strictly in the upstream commits and just do a merge into the debian-unstable tree to build it?
[19:31] <mwhudson> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) 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-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[19:51] <tjaalton> nacc: or bisect manually creating a diff that you put in debian/patches
[19:53] <tjaalton> diff between bad/good upstream, keep a record of the commits and bisect points
[19:56] <tjaalton> hum, no need to diff between bad and known good upstrean, but something in between of course
[19:57] <tjaalton> git diff a..b > d/p/bisect.diff; echo bisect.diff >>d/p/series; <build>
[19:57] <tjaalton> easy
[19:58] <tjaalton> maybe touch changelog so you know which is which
[20:53] <infinity> pitti: libnss-resolve has a derpy idea of valid domain names.
[20:55] <ogra_> caribou, congrats !
[20:57] <infinity> pitti: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1600000
[20:57] <ubottu> Launchpad bug 1600000 in systemd (Ubuntu) "libnss-resolve treats two trailing dots on a domain name incorrectly" [Undecided,New]
[20:57] <infinity> Ooo, I got a round number!
[21:19] <nacc> tjaalton: ah duh, thanks!
[21:38] <ogra_> infinity, oooh, conrats too !
=== freeflying__ is now known as freeflying
[23:45] <nacc> general question, the version of cobbler shipped in 16.04 (and presumably for some time) doesn't work OOB. I believe it is worth SRU'ing the version from 16.10 to 16.04 (sync'd from Debian), which does work OOB (and builds fine in 16.04). I don't believe there will be a clean upgrade path for users, though. Can I add cobbler to the release notes post-release? Feels icky if so. Or should I just pursue a
[23:45] <nacc> backport? Fixing the Cobbler version in 16.04 is not possible (the base version is so old that it's not worth doing, we're better of deleting it from the archive)
[23:47] <jbicha> I think it's fine to improve the release notes after release
[23:48] <rbasak> Yeah, Colin has said to me that it's fine too.
[23:48] <jbicha> some serious bugs we don't know about it before release day!
[23:48] <nacc> jbicha: rbasak: ok, cool, I'll propose the SRU then, given that
[23:48] <nacc> jbicha: makes sense! :)
[23:48] <rbasak> If the package in 16.04 is completely broken then an SRU carries no regression risk so is generally OK.
[23:48] <rbasak> OTOH if it works, then I see what you're saying but it's up to the SRU team really.
[23:49] <rbasak> (ie. if it can be made to work)
[23:49] <nacc> rbasak: i just did a quick test and installed and started cobbler as packagined in 16.04. It throws a python exception immediately :)
[23:49] <nacc> rbasak: the 16.10 version runs fine
[23:50] <rbasak> nacc: then it sounds like an SRU should be fine :)
[23:51] <nacc> rbasak: yeah, and i think it will close ... 10-15 bugs :)
[23:51] <nacc> rbasak: verifying that now
[23:53] <nacc> rbasak: what's the appropriate debdiff to provide in such a case? Or can I simply request we backport and version appropriately the 16.10 version? i have it in a ppa via requestbackport
[23:54] <rbasak> nacc: yeah a debdiff probably doesn't make sense. Perhaps point to a PPA with instructions on what to do with the changelog (eg. drop a ~ppa suffix, etc). Or put a full source package up somewhere, eg. people.c.c.
[23:55] <nacc> rbasak: ack, thanks; also, can i just close cobbler bugs not updated since 11.04/11.10? i'm 99% sure they simply don't apply anymore and no one cares
[23:57] <rbasak> nacc: I would do that with an explanatory comment and an invitation for others to reopen if they think still relevant.
[23:57] <nacc> rbasak: ack, thanks