[01:49] jackpot51, cyphermox, just saw your discussions, and thank you! === salem_ is now known as _salem === gavinlin_ is now known as gavinlin === not_phunyguy is now known as phunyguy === gavinlin is now known as Guest9388 === gavinlin_ is now known as gavinlin === gavinlin is now known as gavinlin_ === gavinlin_ is now known as gavinlin__ === gavinlin__ is now known as gavinlin === gavinlin is now known as gavinlin__ === gavinlin__ is now known as Guest15388 === Guest15388 is now known as gavinlin [07:20] robru: britney email> niiiiice! [07:21] robru: does this use REJECTED_TEMPORARILY vs. _PERMANENTLY, so that it doesn't spam on large queue lagging? [09:41] nacc: nice! [09:43] pitti: what's large queue lagging? [09:43] The policy uses PASS actually as it doesn't itself reject any items [09:44] Laney: I mean if a package is waiting for test results for more than a day [09:44] and temporarily vs. permanently is meant for telling these cases apart [09:44] "known broken" vs. "the machine is still working" [09:46] I don't think policies have access to the current verdict, do they? [09:46] it just looks at is_valid [09:53] Laney: ah, maybe; honestly I forgot the details [09:53] I guess it would be possible to add it in there though [09:54] indeed I think it would email in that case [09:54] maybe generalizing is_valid to current_verdict might not be too hard [09:55] hmm, but would require changing the Policy API [09:56] you could probably put it as an attribute on the excuse [09:56] in britney.py we already have that as "policy_verdict", we just don't pass it into apply_policy() [09:57] right, but API break as you say [09:57] so just stuff it into something which already goes into the function [10:01] 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] Laney: oh right, maybe just excuse.current_verdict, as an extension (or even better, replacement) to exuse.is_valid [10:17] Laney: but aside from that, nice work [10:17] pitti: it's robru's work; I'm just reviewing/merging :) [10:18] trying to find out how the config generation happens so I can enable it for the dev release only [10:21] oho, it's in britney1 [10:21] * Laney dies slightly [10:23] one can never have enough britneys === marcusto_ is now known as marcustomlinson [11:35] tjaalton, is the plan to land x.org 1.19 in Zesty? [11:36] bregma: yes, it's on ppa:canonical-x/x-staging now [11:36] just finished pushing all the drivers [11:36] and upgrading my laptop :P [11:37] tjaalton, OK, thanks... so far works OK on my laptop sans a few dependency issues when installing (I assume those were fixed) [11:38] what issues? needed dist-upgrade, cirrus and mga probably got removed which is fine [11:38] ooh, someone fixed n-m, my indicator shows the wifi status & networks again [11:42] 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] ah [11:43] ok [11:43] was fine here [11:44] * bregma hums as he run apt update [11:47] tjaalton, confirmed the package in x-staging has my earlier dependency problems fixed, so no worries [11:47] ok, cool === _salem is now known as salem_ [12:38] slangasek, is /etc/default/rcS:FSCKFIX=yes at all still in use? [12:39] it seems to have only affect init.d scripts; which are all masked by systemd [12:39] and it does not propagate into the initramfs [13:04] xnox: https://github.com/debops/ansible-console/issues/39 [13:11] jbicha, hm. [13:11] 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] 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] sil2100: it's in one of the first lines of the log [15:27] pitti: but can I get it somehow from inside the test? [15:27] Like, is that somehow exported in the environment of the test or something? [15:27] 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] sil2100: no, it's not [15:28] the --env variables are, of course [15:28] but most everything else shouldn't concern the test itself [15:28] you can determine the type of testbed, release, etc. easily yourself too [15:29] AH HA! [15:29] but the autopkgtest CLI isn't an API for tests -- e. g. it did change quite dramatically with 4.0 [15:29] pitti: \o/ [15:29] pitti: you just saved my life, I just noticed that a very useful thing that I needed is actually appended as --env [15:29] Thanks! [15:29] sil2100: the trigger? [15:29] you want to do something like tell if you're running from a PR? [15:30] I'm working on the u-i autopkgtest thingy and I needed the PR number that the test was executed for [15:30] And I see now --env=UPSTREAM_PULL_REQUEST=123 [15:30] sil2100: ah, yes -- I'm doing the same for systemd [15:30] Awesome [15:30] sil2100: see https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Preparing_the_test [15:31] sil2100: this has some other things to consider too [15:31] * sil2100 hugs pitti [15:31] * pitti hugs sil2100 back [15:32] pitti: hm, where does TEST_UPSTREAM come from? I don't see that in ubuntu-image's --env [15:32] is that in the configuration on the github side? [15:33] looks like it [15:33] nm [15:36] yes, that's set in the webhook [15:37] our machinery only sets $UPSTREAM_PULL_REQUEST === Guest2979 is now known as karstensrage [16:56] I created a executable in linux. which I need to change somtimes [16:57] so I want to send a command to executable in linux and restart itself [16:57] how can I do that [17:03] 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] mun24: That's hopefully enough to give you keywords that you can search for to find examples. [17:03] thx [17:03] program is running as a service [17:03] 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] 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] mattia@warren ~ % syncpackage -s ricotz -b 1671587 vala [18:00] syncpackage: Blacklist Comments: [18:00] syncpackage: vala 0.34.2-1 in sid (same version has unpublished binaries in the [18:00] syncpackage: destination archive for Zesty, please wait for them to be published [18:00] syncpackage: before copying) -- janitor Wed, 26 Oct 2016 10:19:44 +0000 [18:00] syncpackage: Source vala -> zesty/Proposed: current version 0.34.5-1, new version 0.34.6-1 [18:00] What is that comment supposed to mean? [18:06] 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] That is fairly weird [18:07] You can safely ignore it for this purpose though [18:08] Don't think I can even delete them, sigh [18:08] cjwatson: is this cause for concern? 1671515 (a report of incorrect diff.gz download contents; I couldn't reproduce) [18:09] sarnold: Certainly merits investigation, but I'm about to EOD [18:09] sarnold: Could just be a bad cache [18:09] cjwatson: where would you suggest following up? launchpad answers? [18:10] cjwatson: you mean that due to some kind of failure in the past that package must stay forever in the autosync blacklist? [18:10] 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] but can be manually synced anytime just fine? [18:12] 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] cjwatson: thanks; enjoy your evening :) [18:12] 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] mapreri: just sync it [18:13] I suppose it would be easier to just forget and wait for zesty+1 [18:13] ack, on it [18:13] first time I've seen this problem so I don't expect it's very common [19:56] pitti, i saw https://www.piware.de/2011/08/apport-retrace-made-useful/ [19:57] 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] could apport-retrace made work with that? === JanC is now known as Guest31591 === JanC_ is now known as JanC [21:10] 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] 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] anyond around familiar with proposed-migration? [21:18] 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] oh [21:19] i wonder why the upload last week migrated then [21:20] Laney: can you upload a new ubuntu-meta with that dropped from ubuntu-touch? [21:20] dropped or updated? [21:22] 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] dobey: some attempt to provide a platform API maybe? [21:23] 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] ok [21:23] it's in a "Utils" section so that sounds reasonable [21:24] weird though, I don't see why it migrated last time [21:24] must have traded off somehow but no mention of that in the log [21:24] maybe that's normal [21:24] yeah, no idea [21:25] Laney: doesn't appear that a previous abi of gir1.2-ubuntu-app-launch was ever seeded before? [21:26] slangasek: ubuntu-touch.zesty touch-core [21:26] 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] right [21:26] so there was never any previous "trade off" [21:26] so how did the old one migrate? [21:26] dobey says that one had 3 [21:26] ah [21:26] yeah, the -3 was added last week [21:26] NBS and lack of cleanup [21:27] 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] anyway, no reason for the gir to be seeded any more, afaict [21:28] so let's drop it [21:28] that breaks my understanding of how britney works for us [21:28] but whatever :P [21:28] heh [21:28] i won't even pretend to understand how britney works [21:29] 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] slangasek: That's smooth updates, right? I thought we weren't doing that [21:30] 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] maybe that's a misconfiguration, or maybe that's something that happened when pitti rebased [21:30] # naming a non-existent section will effectively disable new smooth [21:30] # updates but still allow removals to occur [21:30] SMOOTH_UPDATES = badgers [21:31] heh [21:33] dobey: it's uploaded [21:33] Laney: thanks! [21:33] hopefully it'll migrate now :) [21:35] huh, THANKS proposed-migration for emailing me [21:35] 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] hmm, i wonder where the upload went [22:18] don't see it on launchpad or in britney yet :-/ [22:27] dobey: it went in now [22:34] Laney: ok, thanks [22:35] ah was looking at ubuntu-meta instead of ubuntu-touch-meta