[06:33] <cpaelzer> good morning
[08:41] <cult-> xnox: when it's going to be released just out of curiosity?
[09:00] <cpaelzer> hmm, when I upgrade from A to a newer A' which now has a recommends to B will be auto-installed on the upgrade
[09:01] <cpaelzer> I know it would on install
[09:01]  * cpaelzer heads raeading docs (but would be happy if one just knows)
[09:10] <LocutusOfBorg> yofel, please merge/sync libqapt and baloo? I have not enough knowledge for doing it by myself sorry
[10:26] <pitti> Laney: the two UPSTREAM_PULL_REQUEST=4670 ones in http://autopkgtest.ubuntu.com/running#pkg-systemd-upstream seem to loop; are there any errors in the logs?
[10:27] <pitti> Laney: yesterday they still ran and failed; then https://launchpad.net/ubuntu/+source/ifupdown/0.8.16ubuntu1 landed, maybe that changed/broke something
[10:28] <Laney> hey pitti
[10:28] <Laney> let me see
[10:28] <Laney> all arches?
[10:29] <pitti> Laney: both i386 and amd64, yes
[10:29] <pitti> (I didn't trigger s390x, no point)
[10:32] <Laney> pitti: don't those upstream ones run on xenial?
[10:32] <Laney> why would an ifupdown in zesty break that?
[10:32] <pitti> Laney: I  manually triggered test runs on zesty, as this is useful for that PR
[10:32] <Laney> oh right
[10:32] <pitti> Laney: that uses the new unified cgroup hierarchy on kernels that support enough of it, which isn't the case yet on xenial
[10:32] <Laney> ok, let me look for that then
[10:33] <pitti> so xenial is for "this doesn't break stuff on older kernels and continues to use cgroupsv1", and zesty is "this doesn't break on unified hierarchy"
[10:33] <Laney> there's one running, /me tail -fs that
[10:33] <pitti> Laney: I have a feeling that it already has ran several times since yesterday evening; they usually take 1:30 hours or so
[10:34] <pitti> Laney: so I was wondering if there's any nova console log (or similar) in the journal already
[10:35] <Laney> I just see the testbed failure
[10:35] <Laney> ah wait, there's an aborted worker
[10:36] <Laney> Feb 21 08:03:28 juju-prod-ues-proposed-migration-machine-3 sh[5696]: Selecting previously unselected package libio-html-perl.
[10:36] <Laney> it just ends on a package installation
[10:37] <Laney> Feb 21 06:57:03 juju-prod-ues-proposed-migration-machine-3 sh[5839]: Selecting previously unselected package autoconf.
[10:38] <Laney> Feb 21 06:21:49 juju-prod-ues-proposed-migration-machine-3 sh[5669]: Get:71 http://ftpmaster.internal/ubuntu zesty/main i386 libip4tc-dev i386 1.6.0-3ubuntu2 [6,534 B]
[10:53] <Laney> hmm
[10:54] <Laney> pitti: is this helpful?
[10:54] <Laney> Feb 21 01:01:46 juju-prod-ues-proposed-migration-machine-3 sh[26926]: [    2.128242] Unable to open file: /etc/ima/ima-policy (-2)[    2.129043] IMA: policy update failed
[10:54] <Laney> Feb 21 01:01:46 juju-prod-ues-proposed-migration-machine-3 sh[26926]: [    2.129613] audit: type=1802 audit(1487638604.548:2): pid=1 uid=0 auid=4294967295 ses=4294967295 op="policy_update" cause="fa
[10:54] <Laney> Feb 21 01:01:46 juju-prod-ues-proposed-migration-machine-3 sh[26926]: [    2.141903] ip_tables: (C) 2000-2006 Netfilter Core Team
[10:54] <Laney> Feb 21 01:01:46 juju-prod-ues-proposed-migration-machine-3 sh[26926]: [    2.146335] systemd[1]: Failed to create symlink /sys/fs/cgroup/net_cls: Operation not permitted
[10:54] <Laney> Feb 21 01:01:46 juju-prod-ues-proposed-migration-machine-3 sh[26926]: [    2.147550] systemd[1]: Freezing execution.
[10:54] <Laney> Feb 21 01:01:46 juju-prod-ues-proposed-migration-machine-3 sh[26926]: ---------------------------------------------------
[10:54] <Laney> Feb 21 01:01:46 juju-prod-ues-proposed-migration-machine-3 sh[26926]: <VirtSubproc>: failure: Timed out on waiting for ssh connection
[10:54] <Laney> Feb 21 01:01:46 juju-prod-ues-proposed-migration-machine-3 sh[26926]: autopkgtest [01:01:42]: ERROR: testbed failure: unexpected eof from the testbed
[11:12] <xnox> pitti, we landed 4.10 kernel too
[11:13]  * ogra_ hopes 4.10 passes quickly ... always makes me think "oh the warty kernel"
[11:16] <pitti> Laney: sorry, long phone call
[11:17] <pitti> Laney: it looks related, yes; /sys/fs/cgroup/net_cls wouldn't exist any more with the unified hierarchy, just not sure why this would cut the ssh connectino
[11:20] <pitti> xnox: oh right, only 10 hours ago, that could be relevant
[11:22] <Laney> pitti: Someone posted "Freezing execution" on the PR too
[11:23] <Laney> seems that was with 4.9 though
[11:25] <pitti> Laney: any chance you could put the /tmp/autopkgtest.*/binaries/*.deb somewhere? I'd like to see if I can reproduce this locally with today's cloud image
[11:25] <pitti> worked fine yesterday still
[11:25] <pitti> Laney: I could also rebuild it myself, but the binaries should already be there in the running tests, so convenience..
[11:26] <Laney> one second
[11:27] <Laney> got to pull this string
[11:27] <pitti> Laney: ah bummer, current retry is still at package building stage
[11:28] <Laney> no I've got binaries
[11:28] <pitti> oh, cool
[11:28] <Laney> no version in the filename
[11:28] <Laney> is that normal?
[11:34] <Laney> pitti: http://people.canonical.com/~laney/weird-things/systemd.tar.xz
[11:34] <pitti> Laney: yes, that's normal
[11:36] <pitti> Laney: many thanks!
[11:36] <Laney> pitti: just got them out in time ;-)
[11:36] <Laney> (died now)
[11:36] <Laney> I'll filter these out now if you don't mind
[11:37] <pitti> Laney: yes, please
[11:38] <pitti> [    2.080076] systemd[1]: Failed to create symlink /sys/fs/cgroup/net_cls: Operation not permitted
[11:38] <pitti> gotcha
[11:38] <pitti> trivial to repro locally
[11:38] <Laney> it killed the VM too?
[11:39] <Laney> I should throttle debmirror somehow, kills SSH latency when it's running
[11:40] <pitti> Laney: yep, same "freezing execution", I followed up to the PR
[11:40] <pitti> Laney: so presumably it's a regression from the followup pushes yesterday  evening
[11:41] <pitti> unfortuantely ridiculously hard to detect by heuristics
[11:41] <pitti> unless we add "Freezing execution" to the list of strings it watches out for; we now have strings for kernel crashes, don't we ?
[11:42] <pitti> similar to f9b3ee01e9
[11:43] <Laney> pitti: could do, if that always indicates a failure
[11:43] <Laney> bit of whack a mole, but what can you do?
[11:55] <doko> apw, infinity: what's the estimate for linux 4.10 and glibc 2.25 in z? asking for the test rebuild
[11:58] <pitti> doko: linux 4.10 landed yesterday (there's some fixes in -proposed, but hopefully shouldn't affect the headers much?)
[11:59] <doko> ahh, I see
[12:37] <mdeslaur> @pilot in
[13:43] <Laney> pitti: https://paste.ubuntu.com/24040277/ ?
[13:47] <pitti> Laney: nice! thanks
[13:52] <Laney> pitti: ok, deployed, could you trigger the test again to test it please?
[13:52] <Laney> just pick one arch
[13:53] <pitti> Laney: triggered amd64
[13:53] <Laney> merci
[13:53] <pitti> Laney: merci à toi ! I'll trigger i386 after amd64 failed "properly"
[13:54] <pitti> (although, that doesn't really tell us anything, nevermind)
[13:54] <Laney> You'll get a nice 'x' on the PR :P
[13:54] <pitti> I already get that with one failure
[14:14] <Bluefoxicy> I wish apt and update-manager had an integrated system to pull all process ids, identify all loaded binaries, and list everything using a binary which has been replaced
[14:14] <Bluefoxicy> that way when you update e.g. openssl, you can list everything running that's still using the previous version, and restart services or browsers
[14:16] <Snow-Man> uh
[14:16] <Snow-Man> check_libs
[14:16] <Snow-Man> Does basically exactly that...
[14:16] <Bluefoxicy> oh cool
[14:16] <Snow-Man> I agree that it'd be nice if apt would tell you too.
[14:16] <Bluefoxicy> command not found
[14:17] <Snow-Man> nagios-plugins-contrib: /usr/lib/nagios/plugins/check_libs
[14:17] <Snow-Man> heh
[14:17] <Bluefoxicy> oh lol
[14:17] <Snow-Man> lsof works too tho
[14:17] <Snow-Man> and is what check_libs runs
[14:20] <Saviq> wgrant, hey, looks like builders got a kernel upgrade again? https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2457/+build/12039740
[14:56] <ilmaisin> hi
[14:56] <ilmaisin> how do i report a disruptive user in launchpad?
[14:57] <ilmaisin> blacksheep001 keeps spamming some internet connection questions to cups bug reports
[14:57] <ilmaisin> won't believe when i ask him to stop
[15:05] <seb128> ilmaisin, you can try asking on #launchpad but I think the recommended way is to use https://answers.launchpad.net/launchpad/+addquestion
[15:05] <ilmaisin> seb128: thanks
[15:05] <seb128> ilmaisin, yw!
[16:02] <tinoco> cpaelzer: are u also taking care of qemu for trusty ?
[16:02] <tinoco> qemu/libvirt
[16:02] <cpaelzer> tinoco: as much as possible :-)
[16:02] <tinoco> cpaelzer: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1317491
[16:02] <tinoco> i'll probably block the "block-commit" feature in libvirt for Trusty
[16:02] <tinoco> (just for active block devices)
[16:02] <tinoco> its broken anyway
[16:03] <tinoco> cpaelzer: could u review it for me so I can prepare the SRU ?
[16:03] <cpaelzer> tinoco: yes, but not today
[16:03] <tinoco> cpaelzer: cool, i'll prepare the debdiffs and wait for you
[16:03] <cpaelzer> tinoco: drop me a mail and I'll look at it then
[16:03] <tinoco> cpaelzer: ill attach them to the case and email you
[16:03] <tinoco> cpaelzer: tks buddy
[16:25] <smoser> xnox, around ?
[16:25] <xnox> smoser, sure! what's up?
[16:25] <smoser> i saw you re-ran some tests or open-iscsi once
[16:25] <smoser> i filed https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1666573
[16:25] <smoser> with some diagnosis comparing the pass and fail, and wanted to know if anything jumped out as you asa the reason for the transient results.
[16:26]  * xnox learns a new word "posterity"
[16:26] <smoser> the top 4 runs at http://autopkgtest.ubuntu.com/packages/o/open-iscsi/zesty/amd64 show pass and fail of identical runs
[16:27] <xnox> smoser, what updates the /etc/fstab? is it done in the initramfs before systemd is started?
[16:27]  * nacc has noticed for a few packages in excuses that the oldest success has no logs -- is that something that can be avoided (i'm assuming maybe it got pushed off the bottom of the list, but still shows up on the web UI, e.g.: http://autopkgtest.ubuntu.com/packages/p/puppet/zesty/amd64)
[16:27] <smoser> overlayrooto before intiramfs
[16:27] <smoser> er...
[16:27] <smoser> in initramfs
[16:27] <smoser> by overlayroot
[16:27] <xnox> smoser, there is possibly a race between fstab-generator and /etc/fstab being updated; if the update is not done in the initramfs.
[16:27] <xnox> ah, good.
[16:29] <smoser> the attached .tar.xz has "short" logs (just the tgt-boot-test output)
[16:29] <smoser> and they actually compare side by side reasonably well with vimdiff
[16:30] <smoser> cpaelzer, ^ i think that could be part of your issue with open-iscsi tests
[16:30]  * cpaelzer reads backlog
[16:31] <zul> doko: ping can you review os-faults wen you get a chance its a new dependency for rally
[16:33] <doko> zul: yes, will do it tomorrow morning
[16:34] <zul> doko: thank you
[16:35] <mdeslaur> @pilot out
[16:47] <nacc> is there a convenient way for me to test the exact environment the autopkgtests run in? That is, http/https proxies and all. I think the puppet failure is due to https_proxy being set, but I'm not 100%
[16:56] <jgrimm> nacc, i'm interested in that too
[16:56] <nacc> jgrimm: will keep you posted
[16:57] <jgrimm> tx
[16:57] <nacc> Laney: --^ you may know
[16:57] <Laney> afraid not
[16:59] <nacc> Laney: np, thanks!
[16:59] <nacc> Laney: you've just educated me on several other autopkgtest nuances :)
[17:02] <nacc> jgrimm: ah, i think i see the puppet failure a bit clearer now (and why my initial 'fix' does workaround it, but is incorrect). I think the tests assume a host-naming pattern of 'puppet'.
[17:02] <nacc> jgrimm: so when it attemps to use https://puppet... it will alias to localhost when Debian tests
[17:05] <jgrimm> nacc, aha.  tho, i was more interested in the part of your question that asked how to create the exact autopkgtest environment. :)
[17:06] <nacc> jgrimm: understood, just fyi :)
[17:07] <nacc> stgraber: `lxc --sudo --name puppet-1487554013 adt-sid-amd64` -- would that set the container's 'hostname' to puppet-1487554013 ?
[17:10] <nacc> stgraber: ah nm, that's an autopkgtest-virt-lxc option
[17:12] <Laney> nacc: yes, it's passed to lxc-start --name
[17:13] <nacc> Laney: yep, i see that now, thanks!
[17:14] <Laney> nacc: One way to do your thing might be to make the lxc/d runner apply a profile, and construct one of those which blocks network access other than to a proxy
[17:14] <Laney> Assuming you can make such profiles (I don't actually know that)
[17:15] <nacc> Laney: yeah, that's a thought. I think a much simpler one (looking at the test case ruby now), would be to just have puppet use the actual hostname at run-time, rather than assuming it's 'puppet' (and accessible at that hostname). There's nothing in the tests that asserts that's true.
[17:19] <Laney> nacc: That helps for this one problem, but not in general :P
[17:19] <nacc> Laney: yeah :)
[17:19] <Laney> Well done potentially finding the issue though
[17:19] <Laney> you can invoke autopkgtests against a PPA FYI
[17:19] <nacc> Laney: only because in this case, I don't think the proxy is actually the problem
[17:19] <Laney> so no need to upload to the archive to verify your fix if it's environment dependent
[17:20] <nacc> Laney: ah that would be great -- documentation for it?
[17:20] <Laney> ...
[17:20] <Laney> I knew you'd ask that
[17:20] <nacc> heh
[17:20] <jgrimm> nacc, or bileto!
[17:20] <nacc> LP: #1550280 implies it's not present
[17:21] <nacc> jgrimm: good point
[17:21] <Laney> private no, but public ones sure
[17:21] <nacc> Laney: err, right!
[17:23] <Laney> meh, got to get this from the source
[17:25] <Laney> nacc: ok, I think it's &ppa=user/ppa (https://autopkgtest.ubuntu.com/request.cgi?release=zesty&arch=amd64&package=puppet&ppa=nacc/myppa)
[17:26] <Laney> if that works, would appreciate a sentence on https://wiki.ubuntu.com/ProposedMigration :-)
[17:26] <nacc> Laney: ack, will test that!
[17:41] <nacc> Laney: https://autopkgtest.ubuntu.com/request.cgi?release=zesty&arch=amd64&package=puppet&ppa=nacc/lp1570472&trigger=puppet/4.8.2-3ubuntu2~ppa1, FYI
[17:41] <nacc> Laney: will update the docs
[17:41] <Laney> nacc: it got published already?
[17:41] <nacc> Laney: my upload to my PPA did yeah
[17:41] <Laney> wowzers
[17:41] <Laney> things are fast these days
[17:41] <nacc> Laney: yeah, faster than I expected :)
[17:42] <Laney> next challenge is finding the results :P
[17:42] <nacc> :) was just going to ask
[17:42] <Laney> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty-nacc-lp1570472/?format=plain
[17:43] <nacc> hrm, I get Unauthorized
[17:43] <Laney> the container is made when the first result is uploaded
[17:45] <Laney> oops, and I've just clicked on a huge text file which has killed firefox for the next X months
[17:52] <nacc> Laney: so... once it's done, should i be able to access the above log?
[17:52] <Saviq> wgrant, hey, did you see my message before about arm64 builders crashing in QML again? (bug #1630906)
[17:53] <Laney> nacc: yup
[17:53] <Laney> well, it'll be an index, and then you construct the path from that
[17:53] <Laney> you can see that the UX here has had a lot of thought :/
[17:54] <Laney> to be fair it was mostly designed to be driven by machines
[17:54] <Laney> but I'm sure we could make it more user friendly somehow
[17:54] <nacc> Laney: totally understood
[17:57] <smoser> xnox, i did manage to catch a failure that i have emergency console access to if you were looking at bug 1666573 and needed anything
[17:59] <nacc> Laney: and i'll update the wiki to indicate you can see it running on the main autopkgtest page
[17:59] <xnox> smoser, a dump of journal would be nice
[18:00] <Laney> nacc: Aye - you can see the formula for getting the index from that URL I gave
[18:00] <xnox> if you can save / extract / copy if somwhere
[18:00] <Laney> autopkgtest-release-username-ppaname
[18:01] <Laney> in fact that's documented at https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Container_Names
[18:01] <Laney> but that tells you more than you need to know
[18:01]  * Laney imagines a CLI tool for all this
[18:03] <Laney> ok, those rocks aren't going to climb themselves
[18:03] <Laney> o/
[18:04] <nacc> Laney: thanks and enjoy!
[18:05] <nacc> jgrimm: in case you didn't see it: "Testing against a PPA" at https://wiki.ubuntu.com/ProposedMigration
[18:06] <jgrimm> nacc, tx
[18:58] <nacc> Laney: just fyi, my autopkgtest seems wedged
[18:58] <nacc> if anyone else has access: http://autopkgtest.ubuntu.com/running#pkg-puppet ran that aginst my PPA
[18:59] <nacc> it looks like it's done and passed, but i've not seen any log change in a while now
[18:59] <nacc> and I can't access the underlying logs until the jobs is done, afaict
[19:34] <nacc> Laney (and anyone else): nevermind, it worked, it was just taking a while to extract the logs, i think
[19:44] <robru> anybody around that can help with an autopkgtest issue? sqlparse update is held back because failing autopkgtest with python-django-debug-toolbar 1.5, the issue is fixed by 1.6, which is in -proposed, but it's invalidated by sqlparse, which is invalidated by the autopkgtest run from 1.5. Not sure how to kick that autopkgtest with 1.6 which should work (I
[19:44] <robru> checked the source and the traceback is resolved in 1.6)
[19:45] <nacc> robru: have you tried rerunning the test?
[19:45] <nacc> robru: i think it should use the new version if it's in z-p now
[19:46] <robru> nacc: yeah, gives very strange output where it claims to be installing 1.6 deb but traceback references 1.5 source tree (and same traceback): https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/amd64/p/python-django-debug-toolbar/20170221_180502_a55de@/log.gz
[19:48] <nacc> robru: ah it's using the z-p to satisfy the debends, but the test it is running is from the 1.5 src
[19:48] <nacc> *depends
[19:48] <robru> nacc: any thoughts how to fix that?
[19:49] <nacc> robru: thinking -- there is a proposed flag we can pass to the test to use proposed for everything, but i'm not sure if that's what we need here or not
[19:49] <robru> nacc: I have no idea. I mean the log already shows it's installing the correct version of the deb, so I'm not sure where it's even getting the 1.5 source tree from
[19:50] <nacc> robru: because that's the version the test is running (earlier you can see it downloads the 1.5 src)
[19:50] <nacc> robru: the way it works is that only sqlparse will come from z-p by default
[19:50] <nacc> robru: for this specific run
[19:50] <nacc> --apt-pocket=proposed=src:sqlparse
[19:51] <robru> nacc: oh well, can you rerun with --all-proposed then? should fix it
[19:51] <nacc> robru: let me try it
[19:51] <robru> thanks
[19:51] <nacc> robru: trying amd64 first, let's see if it passes
[19:52] <robru> nacc: I just double checked, v 1.6 absolutely fixes this traceback, no doubt.
[19:52] <robru> maybe some other problem will arise, not sure, but this specific traceback is for sure fixed by 1.6 ;-)
[19:52] <nacc> robru: ack
[19:57] <pitti> Laney: nice, that worked! proper failure with useful log now; thanks!
[20:02] <robru> nacc_: oooh I see the pass, thanks!
[20:03] <robru> nacc_: try the other arches please ;-)
[20:06] <jbicha> barry: hi, systemd-resolved hasn't been working smoothly here, bug 1666021
[20:07] <nacc> robru: ok, looks like it passed on amd64, will trigger the others
[20:07] <nacc> robru: will take excuses a bit to see the passes, ithink
[20:16] <barry> jbicha: interesting.  i haven't seen this, but then i don't suspend
[20:17] <jbicha> well the initial report wasn't about suspend, it was about first boot
[20:18] <jbicha> maybe there's multiple issues combined into one report but I didn't know where to split it
[20:20] <barry> jbicha: i have seen problems with resolving names right after first boot, but that predates the recent n-m or systemd uploads.  e.g. after first login, i have chromium set up as a start-up app, but after first login post-reboot, most of the tabs cannot load.  reloading always fixes it, so there is definitely something going on around boot
[20:24] <jbicha> ok, but with the symptoms I experienced and the workaround (just restart resolved), it's very convenient to blame resolved now
[20:29] <zul> doko: networking-bagpipe and networking-bgpvpn as well please
[20:30] <nacc> robru: yeah, amd64 just ticked over, at least, looks like it's passing elsewhere too
[20:31] <robru> nacc: thanks!
[21:01] <nacc> robru: and sqlparse is now a valid candidate
[21:01] <robru> nacc: yay, thanks!
[21:01] <nacc> robru: np!
[21:18] <scootergrisen> Can anyone help me get danish translation into the Ubuntu ISO live?
[21:18] <scootergrisen> So when i select danish language during boot its translated to danish without having to install danish language.
[21:25] <robru> nacc: http://people.canonical.com/~ubuntu-archive/proposed-migration/zesty/update_excuses.html#libseccomp all these regressions appear to me to be transient network issues, can you retry them?
[21:49] <nacc> robru: looking
[21:50] <nacc> robru: done
[21:50] <robru> nacc: thanks!
[22:38] <wgrant> Saviq: Not at 4am. Fixing.
[22:41] <Saviq> wgrant, duh, was sure you're closer than that on the timezone front... thanks :)
[23:11] <nacc> jgrimm: ping
[23:11] <jgrimm> nacc, pong
[23:12] <nacc> jgrimm: I *think* your openvpn upload may have inadvertently broken the Canonical VPN cxn with NM on upgrades :) related to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848062 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848062
[23:12] <nacc> specifically, i get "Options error: Unrecognized option or missing or extra parameter(s) in [CMD-LINE]:1: tls-remote (2.4.0)"
[23:14] <sarnold> nacc: from #distro "You have to change VPN -> Advanced -> TLS Authentication -> "Server certificate check" to "Verify name exactly" and remove the /CN: or whatever it is"
[23:14] <jgrimm> nacc, fun times!
[23:14] <nacc> sarnold: yeah, we should put that somewhere, though -- release notes, or in a NEWS file?
[23:15] <jgrimm> yeah, release notes at very minimum
[23:16] <nacc> sarnold: but thank you for the pointer!
[23:18] <nacc> sarnold: as to the remove the '/CN: ...' it doesn't let that be empty (understandably, i think) -- so does that mean remove the value for /CN?
[23:19] <nacc> sarnold: nm, i undestand now
[23:19] <sarnold> nacc: I assumed it meant the non-data annotations..
[23:19] <nacc> jgrimm: so in that particular case, elide the '/CN:' string specifically
[23:19] <jgrimm> nacc, correct
[23:19] <nacc> jgrimm: will you follow up on that with the release notes? i have a feeling it will bite people
[23:20] <jgrimm> nacc, yeah i'll go add a blurb now
[23:21] <nacc> jgrimm: thanks
[23:48] <Laney> nacc: FYI you can add extra triggers instead of all-proposed
[23:49] <Laney> when retrying tests
[23:51] <Laney> they translate into src:proposed things basically