[01:49] <happyaron> jackpot51, cyphermox, just saw your discussions, and thank you!
[07:20] <pitti> robru: britney email> niiiiice!
[07:21] <pitti> robru: does this use REJECTED_TEMPORARILY vs. _PERMANENTLY, so that it doesn't spam on large queue lagging?
[09:41] <rbasak> nacc: nice!
[09:43] <Laney> pitti: what's large queue lagging?
[09:43] <Laney> The policy uses PASS actually as it doesn't itself reject any items
[09:44] <pitti> Laney: I mean if a package is waiting for test results for more than a day
[09:44] <pitti> and temporarily vs. permanently is meant for telling these cases apart
[09:44] <pitti> "known broken" vs. "the machine is still working"
[09:46] <Laney> I don't think policies have access to the current verdict, do they?
[09:46] <Laney> it just looks at is_valid
[09:53] <pitti> Laney: ah, maybe; honestly I forgot the details
[09:53] <Laney> I guess it would be possible to add it in there though
[09:54] <Laney> indeed I think it would email in that case
[09:54] <pitti> maybe generalizing is_valid to current_verdict might not be too hard
[09:55] <pitti> hmm, but would require changing the Policy API
[09:56] <Laney> you could probably put it as an attribute on the excuse
[09:56] <pitti> in britney.py we already have that as "policy_verdict", we just don't pass it into apply_policy()
[09:57] <Laney> right, but API break as you say
[09:57] <Laney> so just stuff it into something which already goes into the function
[10:01] <Laney> I think I'll probably merge this (modulo code review) and file a bug for improvement in the future
[10:01]  * Laney is making it do a dry run for the first couple of runs too
[10:16] <pitti> Laney: oh right, maybe just excuse.current_verdict, as an extension (or even better, replacement) to exuse.is_valid
[10:17] <pitti> Laney: but aside from that, nice work
[10:17] <Laney> pitti: it's robru's work; I'm just reviewing/merging :)
[10:18] <Laney> trying to find out how the config generation happens so I can enable it for the dev release only
[10:21] <Laney> oho, it's in britney1
[10:21]  * Laney dies slightly
[10:23] <pitti> one can never have enough britneys
[11:35] <bregma> tjaalton, is the plan to land x.org 1.19 in Zesty?
[11:36] <tjaalton> bregma: yes, it's on ppa:canonical-x/x-staging now
[11:36] <tjaalton> just finished pushing all the drivers
[11:36] <tjaalton> and upgrading my laptop :P
[11:37] <bregma> tjaalton, OK, thanks... so far works OK on my laptop sans a few dependency issues when installing (I assume those were fixed)
[11:38] <tjaalton> what issues? needed dist-upgrade, cirrus and mga probably got removed which is fine
[11:38] <tjaalton> ooh, someone fixed n-m, my indicator shows the wifi status & networks again
[11:42] <bregma> tjaalton, when I did a dist-upgrade, it wanted to remove unity8 because of some kind of Qt-related dependency chain; I didn't follow up but I'll retest with the x-staging package
[11:43] <tjaalton> ah
[11:43] <tjaalton> ok
[11:43] <tjaalton> was fine here
[11:44]  * bregma hums as he run apt update
[11:47] <bregma> tjaalton, confirmed the package in x-staging has my earlier dependency problems fixed, so no worries
[11:47] <tjaalton> ok, cool
[12:38] <xnox> slangasek, is /etc/default/rcS:FSCKFIX=yes at all still in use?
[12:39] <xnox> it seems to have only affect init.d scripts; which are all masked by systemd
[12:39] <xnox> and it does not propagate into the initramfs
[13:04] <jbicha> xnox: https://github.com/debops/ansible-console/issues/39
[13:11] <xnox> jbicha, hm.
[13:11] <xnox> slangasek, jbicha: in _xenial_ FSCKFIX= appears to be present in /etc/default/rcS but is it really used?! =) i don't think so, or I am failing to trace that.
[15:26] <sil2100> pitti, Laney: hey guys! Sorry to bother you but I have an autopkgtest-infra related question - is there any way I could 'fetch' the info about how the autopkgtest for the given package has been run from inside the autopkgtest?
[15:26] <pitti> sil2100: it's in one of the first lines of the log
[15:27] <sil2100> pitti: but can I get it somehow from inside the test?
[15:27] <sil2100> Like, is that somehow exported in the environment of the test or something?
[15:27] <pitti> e. g. if you look at<EMAIL_ADDRESS>[15:27] <pitti> sil2100: no, it's not
[15:28] <pitti> the --env variables are, of course
[15:28] <pitti> but most everything else shouldn't concern the test itself
[15:28] <pitti> you can determine the type of testbed, release, etc. easily yourself too
[15:29] <sil2100> AH HA!
[15:29] <pitti> but the autopkgtest CLI isn't an API for tests -- e. g. it did change quite dramatically with 4.0
[15:29] <sil2100> pitti: \o/
[15:29] <sil2100> pitti: you just saved my life, I just noticed that a very useful thing that I needed is actually appended as --env
[15:29] <sil2100> Thanks!
[15:29] <pitti> sil2100: the trigger?
[15:29] <Laney> you want to do something like tell if you're running from a PR?
[15:30] <sil2100> I'm working on the u-i autopkgtest thingy and I needed the PR number that the test was executed for
[15:30] <sil2100> And I see now --env=UPSTREAM_PULL_REQUEST=123
[15:30] <pitti> sil2100: ah, yes -- I'm doing the same for systemd
[15:30] <sil2100> Awesome
[15:30] <pitti> sil2100: see https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Preparing_the_test
[15:31] <pitti> sil2100: this has some other things to consider too
[15:31]  * sil2100 hugs pitti
[15:31]  * pitti hugs sil2100 back
[15:32] <Laney> pitti: hm, where does TEST_UPSTREAM come from? I don't see that in ubuntu-image's --env
[15:32] <Laney> is that in the configuration on the github side?
[15:33] <Laney> looks like it
[15:33] <Laney> nm
[15:36] <pitti> yes, that's set in the webhook
[15:37] <pitti> our machinery only sets $UPSTREAM_PULL_REQUEST
[16:56] <mun24> I created a executable in linux. which I need to change somtimes
[16:57] <mun24> so I want to send a command to executable in linux and restart itself
[16:57] <mun24> how can I do that
[17:03] <cjwatson> mun24: The usual idiom is to have the program install a SIGHUP handler that sets a flag, and then when the program next gets back to its main event loop it checks the flag and re-execs itself if it's set.
[17:03] <cjwatson> mun24: That's hopefully enough to give you keywords that you can search for to find examples.
[17:03] <mun24> thx
[17:03] <mun24> program is running as a service
[17:03] <cjwatson> mun24: (Note that you have to be quite careful to do as little as possible in signal handlers, hence my "just set a flag" advice.)
[17:16] <slangasek> ogra_: you appear to have an Ubuntu phone which is fighting with the TB meeting events on the UES calendar; would you mind disabling syncing there?
[18:00] <mapreri> mattia@warren ~ % syncpackage -s ricotz -b 1671587 vala
[18:00] <mapreri> syncpackage: Blacklist Comments:
[18:00] <mapreri> syncpackage:   vala 0.34.2-1 in sid (same version has unpublished binaries in the
[18:00] <mapreri> syncpackage:   destination archive for Zesty, please wait for them to be published
[18:00] <mapreri> syncpackage:   before copying)   -- janitor  Wed, 26 Oct 2016 10:19:44 +0000
[18:00] <mapreri> syncpackage: Source vala -> zesty/Proposed: current version 0.34.5-1, new version 0.34.6-1
[18:00] <mapreri> What is that comment supposed to mean?
[18:06] <cjwatson> For some reason it appears that failed package copy jobs stuff the failure into a DistroSeriesDifferenceComment and then syncpackage gets confused by that ...
[18:07] <cjwatson> That is fairly weird
[18:07] <cjwatson> You can safely ignore it for this purpose though
[18:08] <cjwatson> Don't think I can even delete them, sigh
[18:08] <sarnold> cjwatson: is this cause for concern? 1671515 (a report of incorrect diff.gz download contents; I couldn't reproduce)
[18:09] <cjwatson> sarnold: Certainly merits investigation, but I'm about to EOD
[18:09] <cjwatson> sarnold: Could just be a bad cache
[18:09] <sarnold> cjwatson: where would you suggest following up? launchpad answers?
[18:10] <mapreri> cjwatson: you mean that due to some kind of failure in the past that package must stay forever in the autosync blacklist?
[18:10] <cjwatson> sarnold: I suggest getting the user to be clear about which URL they tried fetching first, and whether they tried forcibly reloading / sending cache-busting HTTP headers
[18:10] <mapreri> but can be manually synced anytime just fine?
[18:12] <cjwatson> mapreri: I don't know for sure, finding out would require more time than I have right now.  I suspect that at least the problem will go away with the next Ubuntu series ...
[18:12] <sarnold> cjwatson: thanks; enjoy your evening :)
[18:12] <mapreri> cjwatson: ok, so shall I go ahead and sync that, or do you prefer if I leave it there and you will look at it?
[18:12] <cjwatson> mapreri: just sync it
[18:13] <mapreri> I suppose it would be easier to just forget and wait for zesty+1
[18:13] <mapreri> ack, on it
[18:13] <cjwatson> first time I've seen this problem so I don't expect it's very common
[19:56] <bdrung_work> pitti, i saw https://www.piware.de/2011/08/apport-retrace-made-useful/
[19:57] <bdrung_work> pitti, i would like to use apport-retrace for our internal infrastructure (but without apport itself). we only have the coredumps and a list of installed packages with versions.
[19:57] <bdrung_work> could apport-retrace made work with that?
[21:10] <tdaitx> wgrant, I was told you could help me on this minor nitpick: the pts link from qa.ubuntuwire.com/ftbfs/ links to packages.qa.debian.org and that page suggests that tracker.debian.org should be used instead, I wonder if there is any reason for that (I'm not that familiar with the "old" debian pts)
[21:10] <tdaitx> on a second note, I tried to access the "source" link in the bottom of ubuntu's ftbfs (to see what would be required to update that link) but then I get a 403
[21:16] <dobey> anyond around familiar with proposed-migration?
[21:18] <Laney> dobey: For some unknown reason ubuntu-touch depends on the versioned gir1.2-ubuntu-app-launch-2 package and the new ubuntu-app-launch doesn't produce such a package any more
[21:18]  * Laney guesses what you wanted to know
[21:19] <dobey> oh
[21:19] <dobey> i wonder why the upload last week migrated then
[21:20] <dobey> Laney: can you upload a new ubuntu-meta with that dropped from ubuntu-touch?
[21:20] <Laney> dropped or updated?
[21:22] <dobey> Laney: i don't know any reason that it needs to be in the ubuntu-touch seed. only autopilot depends on it, which isn't seeded, and should pull it in when autopilot gets installed. so i'd say dropped
[21:22] <Laney> dobey: some attempt to provide a platform API maybe?
[21:23] <dobey> Laney: i'm pretty sure the only reason it was seeded was for autopilot on the phone, because running autopilot on the phone used to need things pre-installed
[21:23] <Laney> ok
[21:23] <Laney> it's in a "Utils" section so that sounds reasonable
[21:24] <Laney> weird though, I don't see why it migrated last time
[21:24] <Laney> must have traded off somehow but no mention of that in the log
[21:24] <Laney> maybe that's normal
[21:24] <dobey> yeah, no idea
[21:25] <slangasek> Laney: doesn't appear that a previous abi of gir1.2-ubuntu-app-launch was ever seeded before?
[21:26] <Laney> slangasek: ubuntu-touch.zesty touch-core
[21:26] <slangasek> gir1.2-ubuntu-app-launch-2 is in the seed, exists in zesty; gir1.2-ubuntu-app-launch-3 is the new one in zesty-proposed
[21:26] <Laney> right
[21:26] <slangasek> so there was never any previous "trade off"
[21:26] <Laney> so how did the old one migrate?
[21:26] <Laney> dobey says that one had 3
[21:26] <slangasek> ah
[21:26] <dobey> yeah, the -3 was added last week
[21:26] <slangasek> NBS and lack of cleanup
[21:27] <slangasek> something has changed now that makes the old gir1.2-ubuntu-app-launch-2 uninstallable
[21:27]  * slangasek handwaves based on first principles without looking to see what
[21:28] <dobey> anyway, no reason for the gir to be seeded any more, afaict
[21:28] <dobey> so let's drop it
[21:28] <Laney> that breaks my understanding of how britney works for us
[21:28] <Laney> but whatever :P
[21:28] <dobey> heh
[21:28] <dobey> i won't even pretend to understand how britney works
[21:29] <slangasek> Laney: "for us"?  we're using near-upstream code now, including support for partial transitions that will let new libs in alongside old provided any given package is individually installable
[21:29] <Laney> slangasek: That's smooth updates, right? I thought we weren't doing that
[21:30] <slangasek> Laney: I'm not aware that we had configured britney not to do it... and update_output.txt certainly shows evidence of this being done
[21:30] <slangasek> maybe that's a misconfiguration, or maybe that's something that happened when pitti rebased
[21:30] <Laney> # naming a non-existent section will effectively disable new smooth
[21:30] <Laney> # updates but still allow removals to occur
[21:30] <Laney> SMOOTH_UPDATES    = badgers
[21:31] <slangasek> heh
[21:33] <Laney> dobey: it's uploaded
[21:33] <dobey> Laney: thanks!
[21:33] <dobey> hopefully it'll migrate now :)
[21:35] <Laney> huh, THANKS proposed-migration for emailing me
[21:35] <Laney> oh yeah, I had already noticed and then forgot about that problem, nothing to do atm
[21:36]  * Laney 's conscience is clean
[22:18] <dobey> hmm, i wonder where the upload went
[22:18] <dobey> don't see it on launchpad or in britney yet :-/
[22:27] <Laney> dobey: it went in now
[22:34] <dobey> Laney: ok, thanks
[22:35] <dobey> ah was looking at ubuntu-meta instead of ubuntu-touch-meta


[00:04] <MTecknology> Is there anything like debian's git.debian.org for maintaining packaging stuff? I assume the answer is yes, my real question is "where?"
[00:06] <nacc> MTecknology: some of us have been working on an 'importer' of sorts. https://lists.ubuntu.com/archives/ubuntu-devel/2016-November/039549.html
[00:06] <nacc> MTecknology: but no, nothing officially the same as what debian does
[00:08] <MTecknology> ah, bummer
[00:08] <nacc> MTecknology: i mean, it depends on what you meant, I suppose -- Launchpad is available for hosting your code, of course (git or bzr)
[00:12] <MTecknology> I'm trying to work on a patch based on jabberd2 in ubuntu xenial and I'm trying to keep the patch done in a way that I can move the patch around more easily, including backports. It's just not a patch that has any place being sent upstream so I'll maintain it indefinitely.
[00:13] <nacc> MTecknology: and you're not planning on submitting the patch for the official packages?
[00:15] <MTecknology> nope, it's a custom patch that lets us have some hardware talk to internal jabber servers. Not useful to anyone but us.
[00:15] <sarnold> just smack an "IOT!!11!" header onthe patch and send it in? :) hehe
[00:16] <nacc> MTecknology: i see; i think our importer is probably what you want (you can then use git to rebase your changes as new versions publish in xenial, etc.) -- you can run the importer yourself, fwiw, and push to your own git tree
[00:19] <MTecknology> Any chance you know of anything that could explain that workflow to me?
[00:25] <nacc> MTecknology: the email i sent above and there is a wiki page: https://wiki.ubuntu.com/UbuntuDevelopment/Merging/GitWorkflow
[00:26] <MTecknology> nice, thanks!
[00:26] <nacc> MTecknology: feel free to ping me here if you have questions
[00:29] <rbasak> nacc: iproute2 merge> yes, though I'd ask apw, as the fan support delta is a feature addition.
[00:32] <nacc> rbasak: will do!
[00:33] <nacc> apw: --^ :) just fyi, was wondering about merging iproute2
[01:21] <rbasak> Do the old style "Ubuntu core" images not exist any more? I see them on old-releases.u.c, but on the current releases.u.c, the Snappy Ubuntu Core images seem to have taken over the URL.
[01:29] <jgrimm> rbasak, https://partner-images.canonical.com/core/   may be what you are looking for?
[01:35] <rbasak> jgrimm: I think that might be it. Thanks!
[01:48] <jgrimm> rbasak, no worries; I just happened to know because that's where ubuntu docker image building pulls from.
[01:50] <sarnold> the permissions on pool/universe/o/opl3-soundfont/ look funny to me; my mirror made it mode 700 instead of 755
[04:34] <chiluk> infinity: who's responsible for archive pocket copies ?  looks like transcode got missed https://bugs.launchpad.net/ubuntu/+source/transcode/+bug/1645556 ...
[04:34] <chiluk> is this something I can do?
[05:42] <ginggs> chiluk: transcode is in the yakkety new queue https://launchpad.net/ubuntu/yakkety/+queue?queue_state=0&queue_text=
[05:43] <chiluk> well that's just odd.
[05:43] <chiluk> ginggs: do you have powers to fix that?
[05:45] <chiluk> ginggs: the version there is already surpassed by what is in xenial and maybe whats in zesty.
[05:45] <chiluk> I'm very confused by the versioning of this package.
[05:46] <ginggs> chiluk: no, sorry. i'm guessing you need SRU team to review it
[05:47] <chiluk> doko do you mind looking at what's going on with transcode in yakkety... you seem to have touched it last in zesty.
[05:47] <ginggs> chiluk: version number seem ok to me for a yakkety SRU
[05:48] <ginggs> ubuntu1 > ubuntu0.1 > build4
[05:48] <chiluk> ginggs: exactly versioning is all screwed up.
[05:48] <chiluk> ginggs: exactly versioning is all screwed up.
[05:49] <chiluk> debian versioning is at least -9+b1 or -9+b4
[05:49] <ginggs> chiluk: zesty > yakkety > build4
[05:49] <chiluk> which is sensible.
[05:49] <chiluk> ginggs  just because it works doesn't mean it should have been named that way.
[05:49] <ginggs> chiluk: i mean zesty > yakkety > xenial which is correct
[05:51] <ginggs> chiluk: see https://wiki.ubuntu.com/StableReleaseUpdates#Procedure 5.1 and the link to the security policy document
[05:52] <chiluk> ginggs: I've got those relatively memorized.
[05:52] <chiluk> I'm just confused by why it never got approved
[05:53] <chiluk> I'll harass the sru team tomorrow when they wake up..
[05:54] <chiluk> ginggs I should have checked the upload queue before opening a bug, but I'm surprised the xenial version didn't just get pocket copied when yakkety was openned .. do you know that answer?
[05:54] <chiluk> I'm still trying to learn all this .
[05:55] <ginggs> chiluk: it was removed because it FTBFS with the new ffmpeg in yakkety
[05:55] <chiluk> ah..
[05:55] <chiluk> ok .
[05:55] <chiluk> that makes sense.
[05:56] <ginggs> chiluk: and being removed from debian testing didn't help
[05:56] <chiluk> ginggs: how are you finding that info?
[05:56]  * chiluk learning.
[05:57] <ginggs> chiluk: see comment 8 in LP: #1631796 and news in https://packages.qa.debian.org/t/transcode.html
[06:00] <chiluk> Yeah just saw that bug ginggs.. I assume you marked my bug as a duplicate ..
[06:00] <ginggs> chiluk: yes, that was me
[06:01] <chiluk> ginggs: do you know why that bug doesn't show up on https://bugs.launchpad.net/ubuntu/+source/transcode
[06:04] <ginggs> chiluk: not sure
[06:05] <chiluk> maybe I'll open a bug against launchpad.... that seems like that should work.
[06:39] <pitti> Good morning
[06:50] <ScottK> chiluk: It doesn't show up because it's marked fixed released in the development version.  That's normal and expected.
[10:20] <stub> Is zfs root partition support in the installer being worked on for zesty?
[12:25] <mapreri> pitti: pbuilder autopkgtests have been failing recently on armhf, with this error:
[12:25] <mapreri> mknod: /var/cache/pbuilder/build/3059/test-dev-null: Operation not permitted
[12:25] <mapreri> E: Cannot install into target '/var/cache/pbuilder/build/3059' mounted with noexec or nodev
[12:26] <mapreri> Shall I suppose that has something to do with the test bed?
[12:27] <mapreri> (+ did somebody forced debootstrap and ubuntu-keyring in without caring to clear this failure?)
[12:27] <pitti> mapreri: yes it does; apparently this doesn't work in lxd, while it still worked in lxc
[12:27] <mapreri> umh
[12:27] <mapreri> and only for armhf?
[12:28] <pitti> yes; s390x runs in lxc (without apparmor restrictions), i386/amd64/ppc64el run in full VMs
[12:28] <mapreri> ic
[12:28] <pitti> mapreri: so I figure "ignore" it is, I'll add a hint
[12:29] <mapreri> pitti: I suppose, if you don't have a fix pending... Thanks
[12:51] <Saviq> seb128, hey, IIUC you were working on "themes" interface at some point, is there anything I could read up on that?
[12:58] <pitti> seb128: what's the word on zesty langpacks?
[13:00] <seb128> pitti, sorry, got busy on other things and didn't get back to pinging wgrant about it, thanks for the reminder
[13:01] <ginggs> pitti: hi, recent versions of eigen3 and freecad have been failing autopkg tests on ppc64el and freecad on s390x as well for some months, except for when i included a patch to disable just those failing tests. do i keep applying the patch, or can you mark those 'always failed'?
[13:01] <seb128> Saviq, not really "working" on it, more listing theme as something we might want to share/integrate with but it's not an easy topic since there isn't a 1-to-1 matching with a toolkit stack/version or with the machine you integrate with
[13:02] <Saviq> seb128, good enough for us, anywhere I can point to some reading/considerations about it?
[13:03] <seb128> Saviq, https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1576300
[13:04] <seb128> Saviq, https://bugs.launchpad.net/snappy/+bug/1582784
[13:04] <Saviq> seb128, ack, thanks!
[13:04] <seb128> yw!
[13:05] <seb128> Saviq, but there was no proper discussion recorded I think, I mostly had IRC chats about it and some 1-to-1 offtrack discussions with e.g Didier
[13:05] <Saviq> ack
[13:42] <pitti> ginggs: better drop the delta and we add a hint
[13:43] <pitti> ginggs: eigen3 looks fine on s390x though? http://autopkgtest.ubuntu.com/packages/eigen3/zesty/s390x
[13:44] <ginggs> pitti: yes, only freecad on s390x as well
[13:44] <pitti> force-badtest eigen3/3.3~beta2-2ubuntu2/ppc64el
[13:44] <pitti> ginggs: ^ ah, we already had a hint, just need to bump it
[13:45] <pitti> ginggs: hints added
[13:46] <ginggs> pitti: ok thanks, but this requires some manual action everytime?  is it possible to reset it to 'always failed'?
[13:48] <pitti> ginggs: we can remove the existing results, but not as long as the "working" version (with the failing test patched out) is still current in zesty
[13:50] <ginggs> ok, so you could do for eigen3 now, but not for freecad
[13:50] <pitti>  eigen3  | 3.3~beta2-2ubuntu2  | zesty/universe          | source
[13:50] <pitti>  eigen3  | 3.3.0-1             | zesty-proposed/universe | source
[13:50] <pitti> not yet
[13:51] <ginggs> iirc 3.3~beta2-2ubuntu2 doesn't have that patch to skip the failing tests
[15:33] <hallyn> so where do i look for help with weird font issue?  we dont' have a font "server" any more right?
[15:34] <hallyn> after a certain random amount of time, certain applications (like pasaffe) will show garbage for text, like http://people.ubuntu.com/~serge-hallyn/brokenfonts.png
[15:44] <dobey> hallyn: intel video?
[15:46] <hallyn> yeah
[15:46] <hallyn> thinkpad t440s. didn't even think of that
[15:49] <hallyn> dobey: any known workarounds? :)
[15:50] <hallyn> sforshee: ^ is that something you've heard of before?
[15:52] <dobey> hallyn: don't know. just saw this recently on g+ so seemed relevant: https://plus.google.com/+philipperoux/posts/M41cozsF37J?sfc=true
[15:53] <hallyn> oh, yeah
[15:53] <hallyn> that's exactly it
[16:00] <nacc> bdmurray: i don't think my bind9 upload to xenial is the source of the uptick in bind9 bugs -- https://errors.ubuntu.com/?release=Ubuntu%2016.04&package=bind9&period=day&version=1%3A9.10.3.dfsg.P4-8ubuntu1.3 (the first is also seen with 16.10 and the latter two don' seem to have antying to do with bind9-resolvconf?)
[16:01] <nacc> rbasak: --^ as well, in case you have time to look
[16:02] <hallyn> dobey: hm, one person suggests 16.10 would fix it.  but that's too systemd-entrenched, not sure i can do that.  maybe if i run yakkety kernel though
[16:04] <bdmurray> nacc: Okay, I'll override it.  Thanks for looking.
[16:04] <nacc> bdmurray: np!
[16:04] <nacc> bdmurray: thank you!
[16:04] <hallyn> hate g+, can't comment on it
[16:05] <dobey> hallyn: yeah, is the HWE stack ready yet? or in a PPA or something for testing?
[16:07] <hallyn> no tyet
[16:11] <dobey> too bad. i could use the new x/mesa myself, for my amd card :)
[16:16] <hallyn> https://lists.ubuntu.com/archives/ubuntu-announce/2016-November/000215.html
[16:18] <dobey> nice
[16:19] <dobey> anyway, time to get some lunch
[17:22] <jbicha> any core dev interested in updating all the seeds for the system-config-printer transition? see the last comment on bug 1643129
[17:23] <nacc> jbicha: can't you do MRs against the appropriate bzr branch(es)?
[17:24] <jbicha> nacc: sure, that sounds like a good idea
[17:25] <nacc> jbicha: i only suggest that, as that's what I did in the past when I didn't have appropriate permissions for the server seeds -- do you have a link to the bzr repository handy? I can find it, if not
[17:25] <jbicha> yes, they should all be at https://code.launchpad.net/ubuntu-seeds
[17:25] <nacc> jbicha: yeah
[17:26] <rbasak> jbicha: you can point to the MP in your core dev application :-)
[17:27] <nacc> heh
[17:30] <jbicha> hmm, I often delete old bzr branches and MPs once they've been merged
[17:37] <rbasak> chrisccoulson: do you know about bug 1643467? Regression from your firefox upload to Trusty.
[17:43] <chrisccoulson> rbasak, yeah, I guess someone needs to update libav. It's in universe though
[17:44] <rbasak> That's puzzling. Should Firefox (in main) be using libav (in universe)?
[17:45] <chrisccoulson> rbasak, it's completely optional for h264 support. Firefox doesn't depend on it
[17:45] <rbasak> Still, a vulnerability in libav would make Firefox vulnerable, no?
[17:45] <rbasak> Isn't that against the spirit of the main/universe split?
[17:46] <rbasak> Though I suppose users know that because libav is in universe.
[17:46] <rbasak> chrisccoulson: would you mind explaining the situation in the bug please?
[17:49] <dobey> 17:35:22 dh: unable to load addon cli: Can't locate Debian/Debhelper/Sequence/cli.pm in @INC (you may need to install the Debian::Debhelper::Sequence::cli module) (@INC contains: /etc/perl /usr/local/lib/perl/5.18.2 /usr/local/share/perl/5.18.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.18 /usr/share/perl/5.18 /usr/local/lib/site_perl .) at (eval 16) line 2.
[17:49] <dobey> ^^ what does this come from?
[17:50] <nacc> dobey: are you missing cli-common-dev ?
[17:50] <nacc> cli-common-dev: /usr/share/perl5/Debian/Debhelper/Sequence/cli.pm
[17:51] <nacc> (that's from 16.10)
[17:51] <dobey> nacc: yes, well it's a jenkins job which tries to build the source package. hadn't come across that dep before. thankls
[17:51] <dobey> thanks
[17:52] <nacc> dobey: ah ok, presumably it's a missing build-dep then? maybe something changed in the dep-chain so it's not getting pulled in auomatically, if it's a regression
[17:52] <dobey> nacc: bzr bd doesn't automatically install build deps
[17:53] <nacc> dobey: oh i see
[17:55] <dobey> and most of them aren't needed. only the debhelper ones need to be pre-installed really. so we have to list certain debhelper-providing packages in our config and ensure they are installed in jenkins :-/
[17:59] <nacc> dobey: right, I can see why that would be necessary
[18:12] <infinity> chiluk: It has nothing to do with anyone (or thing) failing to copy it forward, it was removed.
[18:12] <chiluk> thanks for the response infinity... I got it figured out yesterday once I found the related bug.
[18:13] <chiluk> infinity while I have you, aren't you on the sru team?
[18:13] <chiluk> well I guess I just need another core dev.. can you approve the transcode upload that's in queue for yakkety..
[18:13] <chiluk> infinity.. not having mythfrontend working is pissing off my wife.
[18:14] <infinity> chiluk: You were right the first time, you need an SRU person.
[18:14] <chiluk> nuts...
[18:14] <infinity> (which I am)
[18:15] <chiluk> infinity can you approve it please..
[18:15] <infinity> chiluk: How about I review it first? :P
[18:15] <chiluk> also doable..
[18:18] <infinity> chiluk: Done.
[18:18] <chiluk> infinity: thanks sir...
[18:46] <nacc> jgrimm: keepalived uploaded
[18:52] <jgrimm> nacc, thanks sir
[18:53] <nacc> jgrimm: np, and sru template updated, so we should be good on that bug now
[18:53] <jgrimm> ack
[22:10] <dmj_s76> sforshee: I think I've found an issue with the linux-firmware package that's affecting a number of users, and will hit more when the next kernel update lands.  On a particular Kaby Lake laptop, updating the initramfs with (current) version 1.157.5 of the linux-firmware package installed causes broken sound behavior.
[22:12] <dmj_s76> In particular volume control doesn't work, hdmi devices show in the sound settings gui, and there's dmesg output relating to problems with snd_hda_codec_hdmi
[22:14] <dmj_s76> The laptop uses U-series Kaby Lake processors with a 100 series Sunrise Point chipset.
[22:18] <sforshee> dmj_s76: will you please file a bug with that information and assign it to me?
[22:20] <dmj_s76> The current theory is that the /lib/firmware/i915/kbl_dmc_ver1_01.bin
[22:20] <dmj_s76> sure
[22:21] <dmj_s76> Oh, and the bug only manifests on xenial, not yakkety.
[22:21] <sforshee> dmj_s76: thanks. I'll follow up on the bug tomorrow.
[23:32] <dmj_s76> sforshee: https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1645911
[23:42] <chiluk> can I get a sponsor for https://bugs.launchpad.net/ubuntu/+source/virt-manager/+bug/1634304... not sure if I should backport to trusty as well.
[23:46] <sarnold> hey chiluk :) that yakkety debdiff looks busted, all changelog and no code
[23:48] <nacc> mdeslaur: i'm still working my way through the php-imagick regression with imagemagick -- the merge didn't fix it, unfortunately. It looks like there is a bug there for sure. Annoyingly, running `make test` from the same source does work (except for one common failure to both cases).


[09:06] <zequence> infinity: All done
[22:56] <adrian15> I have an Ubuntu 14.04 server virtual machine which just disappears (the kvm process no longer runs). Can I blame the ubuntu kernel for that? Can the kernel just poweroff the computer? Does it have an special name for it? Kernel version: 3.13.0-43-generic . Thank you.
[23:06] <apw> adrian15, i would expect kvm to log the rewason it exited somewhere, and that to tell you if the inner kernel exited things, or kvm outside had an issue
[23:09] <adrian15> apw: I only have these two messages at the host's syslog: http://paste.ubuntu.com/9574257/ . I suspect they happen to be after the virtual machine poweroffs and not before it. Is there any specific kvm log files? Or is it ok by taking a look at syslog?


[10:50] <_ami_> i added allow_signal(SIGKILL) in my kernel thread work function. kill -9 <thread_id> does not stop the thread function. any pointers?
[11:31] <_ami_> code: http://pasted.co/0ac16746
[18:49] <dantab> Quick question, maybe people here can answer it quickly: Do xqd card readers already work on linux?  I assume yes, but I would like to hear from people before I buy one. Searching on the net was not so successful.


[06:42] <cxdeviit> How can I update cloud-init in AWS?
[08:58] <meena> https://github.com/canonical/cloud-init/pull/42#discussion_r353283759
[08:58] <meena> duh.
[11:23] <meena> i've started a patch here: https://github.com/canonical/cloud-init/pull/621 hope i can get it into the next release… along with my /other patch/
[11:26] <meena> this needs a better title than the title of the first commit
[13:22] <Odd_Bloke> cxdeviit: cloud-init generally comes from your distro vendor as part of the images you launch, and is generally updated via standard upgrade mechanisms or via new distro images being generated.  What distro are you using, and what's the motivation for needing cloud-init upgraded?
[14:17] <cxdeviit> One of my AWS instance has Amazon Linux 1 and Cloud-init version 0.7.6 which doesn't seem to support devel analyze etc , that's where I am stuck. If there was a way to patch it .
[14:23] <Odd_Bloke> cxdeviit: Aha, right.  I would be hesitant to recommend upgrading cloud-init in any way other than distro packages: that could break your machine in ways that are difficult to recover from.  So I don't know if you have a good path to a newer cloud-init.  That said, if you're looking to use `analyze`, it has a `--infile` parameter, so you could pull your log files to a newer cloud-init installation
[14:23] <Odd_Bloke> (locally or in a different distro instance in the cloud) and perform your analysis that way.
[14:25] <cxdeviit> Aha, will try that. Another issue is regarding requests dependency of urllib3 to be 1.21.1 , not sure if pip/python is messing here
[14:33] <minimal> Odd_Bloke: Hi. Re: Mac Addreses, as Netplan files are YAML also then they should also have all-numeric MAC addresses quoted, right?
[14:41] <Odd_Bloke> minimal: Presumably, yeah.
[14:42] <minimal> so then I've found a bug in the netplan renderer - when I fixed an all-numeric MAC address in a testcase then it failed due to the macaddress in the generated netconf file having no quotes
[14:43] <Odd_Bloke> Can you pastebin the error?
[14:53] <minimal> Odd_Bloke: https://gist.github.com/dermotbradley/bb7353c00bf505bbf2f1ce0eb2b56c17
[14:54] <minimal> its the 5th MAC address
[15:13] <Odd_Bloke> minimal: That's test_render_output_supports_both_grat_arp_spelling?  (I'm heading into a meeting, will look more after.)
[15:14] <minimal> Odd_Bloke: yupe, that's the one
[15:54] <meena> smoser:  that sure is one way to say, focus on  the other PR
[15:54] <smoser> meena: ? sorry... didnt' mean to be a pita.
[16:00] <smoser> oh. funny.
[16:00] <smoser> wow. total fail
[16:01] <smoser> meena: updated that comment https://aci-github.cisco.com/atom/atomix/pull/1269
[16:04] <meena> smoser, nah, it's cool. what you're doing is useful and important
[16:15] <meena> smoser, I'm getting address not found for that link
[16:15] <smoser> man. i totally cannot paste
[16:16] <smoser> https://github.com/canonical/cloud-init/pull/622
[16:16] <smoser> yeah, that other is my iternal github
[16:32] <Odd_Bloke> minimal: So I think that MAC address _doesn't_ need quoting because it has values that exclude it from being a timestamp (99 > 59, in the seconds and hour fields): https://paste.ubuntu.com/p/tddYNXWrbk/
[16:37] <minimal> Odd_Bloke: hmm, the YAML "timestamp" is actually whether something is treated as a base 60 number and according to https://yaml.org/type/int.html the definition for this is |[-+]?[1-9][0-9_]*(:[0-5]?[0-9])+
[16:40] <minimal> so you're right, I'll have to rewrite my PR docs change to be even more specific about when quoting is required ;-)
[16:57] <Odd_Bloke> minimal: OK, right, I was trying to figure out why I couldn't find reference to it in the spec; didn't occur to me that it was a base 60 number!  Good find, and I agree that more specificity is needed.
[16:58] <Odd_Bloke> (At least we know that anyone running cloud-init in ancient Sumeria will experience no problems. :p)
[17:05] <minimal> Odd_Bloke: search YAML docs to find that ref gave me a headache, lol
[17:25] <momousta> Hi, we would like to land this PR (https://github.com/canonical/cloud-init/pull/614) before the code cutoff for the next SRU, Can someone help taking a look at it?
[17:34] <minimal> Odd_Bloke: PR created for the MAC address docs. Any chance you could review it and PR 618 as well?
[17:35] <minimal> for PR 618 the question of how to test it is still open - /etc/shadow is normally only readable by root user, so guess it would need to be mocked
[18:48] <meena> wait, wait wait
[18:48] <meena> YAML, which is a superset of JSON knows integers, but JSON does not
[18:49] <meena> that's hilarious, i didn't realise how lossy the conversion between the two could be
[18:56] <minimal> meena: with JSON strings are quoted so there's no room for confusion, with YAML you don't have to quote (most) strings and magically the app reading the YAML works out if a value is a number or a string...
[18:58] <minimal> except in this case in YAML a MAC value of 11:22:33:44:55:66 (without quotes) will be treated as a Base 60 number whereas a value of 11:22:33:44:55:6a (without quotes) will be treated as a string
[19:07] <minimal> does anyone on here from Canonical look after cloud-utils? Am confused that https://launchpad.net/cloud-utils has 0.31 dated 10/12/2018 as latest release but that https://github.com/canonical/cloud-utils/ has no 0.31 and has 0.30 dated 10/07/2019 (i.e. dated far newer than 0.31 on the other site)
[19:09] <Odd_Bloke> minimal: It's getting even better: the YAML 1.2 spec doesn't include base 60 (which is why I couldn't find it!) but PyYAML only supports YAML 1.1 which _does_.
[19:10] <minimal> minimal: any cloud-init's network config uses with YAML schema? (Also didn't notice mention of YAML version on netplan's website)
[19:10] <minimal> s/minimal/Odd_Bloke/
[19:11] <Odd_Bloke> We (implicitly) use YAML 1.1, because we use PyYAML.
[19:12] <minimal> Odd_Bloke: any idea on what I pointed out about cloud-utils above?
[19:13] <meena> minimal, yeah, we've seen this issue in puppet / hiera
[19:13] <Odd_Bloke> minimal: I believe the tag in GitHub was created on that much later date, but if you look at the commit it points to it's older.
[19:14] <Odd_Bloke> (In fact, there are a whole bunch of version tags that were created on that same day, so that was presumably an import to GH?)
[19:15] <minimal> ok. I maintain the Alpine package for cloud-utils and 0.31 is downloaded from Launchpad........just wondered if I was using out of date code. Any idea if a 0.32 is going to happen any time soon? The last release has been out a while
[19:17] <Odd_Bloke> I know some cloud-utils things have been happening, but I haven't kept on top of them.
[19:19] <minimal> for example in "master" there a growpart LVM commit from July that's obviously significant for cloud-init users
[19:23] <Odd_Bloke> minimal: I'll look into it.
[19:24] <minimal> Thanks
[19:24] <powersj> heh smoser released 0.31 end of 2018 when he moved it to git
[19:25] <minimal> powersj: yeah found the 0.31 tag hidden on the 2nd (or 3rd?) Releases page in git. Have just downloaded from both Launchpad and Github and compared to verify both 0.31 files are identical
[19:26]  * meena quotes herself quoting someone else she heard saying it: release early release often
[19:26] <meena> also: why y'all afraid of 1.0
[19:26] <meena> what's up? why the 0.?
[19:26] <minimal> meena: as its a prime number? They're scary!
[19:35] <meena> you can skip primes
[19:40] <Odd_Bloke> Every number is prime if you define division the right way: https://paste.ubuntu.com/p/rcHw2M5pVf/
[19:43] <meena> Odd_Bloke: na na na. that means we're then skipping all numbers, which brings us back to where we started
[19:47] <minimal> Odd_Bloke: for the Ansible/Jinja2 templates I'm using to create network-config-v2.yaml adding "| to_yaml" to the macaddress variables sorts the automagic YAML string quoting for me
[19:57] <Odd_Bloke> OK, good, that's what I'm hoping will be the case for most generated YAML: the libraries will DTRT.  And most networking YAML will be generated in some way, because it's handled by the platform (which launches many instances) rather than the user (who may only launch a few and not bother investing in automation).
[19:57] <Odd_Bloke> That said, I wonder if YAML 1.2 libraries do the correct quoting for values which are strings in 1.2 but ints in 1.1.
[19:58] <minimal> To be honest I think YAML is trying to be too smart - they should have just required strings to always be quoted and been done with it
[19:59] <Odd_Bloke> Agreed.
[20:02] <meena> wait_for_physdevs_netcfg() is a terrible name for a function that's no longer in that class
[20:02] <meena> but it looks generally useful
[20:05] <minimal> Odd_Bloke: your command about ".. include:", does this support including from another part of the same document? or only from a separate file?
[20:05] <minimal> s/command/comment/
[20:06] <Odd_Bloke> minimal: I think we'd need a separate file with just that snippet.
[20:06] <Odd_Bloke> Which is perhaps overkill, but I also wouldn't be surprised if we find this info needs updating again in future.
[20:06] <Odd_Bloke> So I could go either way.
[20:10] <Odd_Bloke> I come bearing bad news: ruamel.yaml supports YAML 1.2, and `yaml.load(ruamel.yaml.dump({"x": "11:22:33:44:55:59"}))` gives `{'x':<PHONE_NUMBER>}` (whereas dumping with PyYAML round-trips correctly).
[20:14] <minimal> where is ruamel.yaml used? A quick grep doesn't show in anywhere in cloud-init
[20:14] <Odd_Bloke> It isn't, but it's a library that could be used to generate the networking YAML that is fed to cloud-init.
[20:15] <Odd_Bloke> And as it is a YAML 1.2 library, it does not quote base60 ints properly (because in YAML 1.2 base60 ints aren't a thing, so their unquoted form is unambiguously a string).
[20:16] <Odd_Bloke> This is in reference to "That said, I wonder if YAML 1.2 libraries do the correct quoting for values which are strings in 1.2 but ints in 1.1."
[20:16] <minimal> It describes itself as a YAML 1.2 loader/dumper, whereas you'd indicated earlier that network-config-v1.yaml and network-config-v2.yaml are YAML 1.1
[20:17] <minimal> though I guess that's just because c-i uses PyYAML and not stated anywhere in the c-i "specification" for those YAML files
[20:18] <Odd_Bloke> Yeah, that's the gap I'm worried about.
[20:18] <Odd_Bloke> Until today, I hadn't really thought too much about YAML 1.1 vs 1.2, and I strongly suspect I'm not alone in that.
[20:18] <minimal> same applies to Netplan - did'nt see any YAML version mentioned there either
[20:20] <minimal> now you'll have the fun of determining what each of the DataSources vendors (AWS, GCE, etc) do and try and get them to agree on YAML 1.1, doh!
[20:22] <Odd_Bloke> Practically speaking, if any of the large platforms could generate incorrect YAML in this way, we'd have heard about it, I think: this isn't a recently introduced "bug", we've always used PyYAML and therefore YAML 1.1.
[20:22] <Odd_Bloke> (And they obviously get through a lot of MAC addresses. :p)
[20:24] <minimal> Time to hurriedly insert "These files are in YAML 1.1 format" into the docs in big flashing letters eh? ;-) (damn, Mozilla decommissioned the HTML blink tag)
[20:24] <Odd_Bloke> I'm sure we can bring it back with some custom JS.
[20:25] <Odd_Bloke> But yeah, I think we do want to document this.
[20:25] <minimal> I'm guessing a all-numeric MAC address where all of the component part is 00-59 is statistically unusual
[20:26] <Odd_Bloke> Yeah, and it is possible they might be using a prefix (that's a MAC address thing, right, vendor prefixes?) that excludes all of their MACs from triggering this.
[20:32] <Odd_Bloke> minimal: https://bugs.launchpad.net/netplan/+bug/1901084
[20:35] <minimal> I'd already noticed that the page https://netplan.io/reference/ has at least 1 unquoted MAC address that needs to be quoted
[20:36] <minimal> Odd_Bloke: If you search online for OUI each hardware vendor that registers get a prefix to use for network cards they manufacture. Likewise a MAC beginning "52:54" is KVM (from memory). There's a OUI.txt file online managed by IETF that is regularily updated
[20:39] <minimal> in my case as I'm testing on KVM I'm using made up MACs within the KVM prefix and happened to use all numeric addresses.
[20:40] <minimal> The other PR I raised a few days ago about user-data YAML for user settings - I'd noticed that expirydate was being misinterpreted without quotes and what was being put into the field in /etc/shadow was incorrect
[20:41] <minimal> so potentially the impact is on more than just MAC addresses
[20:58] <meena> https://github.com/canonical/cloud-init/pull/617#issuecomment-714758289 ds-identify is a trash fire
[21:08] <meena> maybe reading disk labels doesn't work for bsd
[22:05] <minimal> Odd_Bloke: FYI https://en.wikipedia.org/wiki/Sexagesimal#YAML