[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 https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/amd64/c/conjure-up/20170309_034802_8947b@/log.gz
[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