| happyaron | jackpot51, cyphermox, just saw your discussions, and thank you! | 01:49 |
|---|---|---|
| === 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 | ||
| pitti | robru: britney email> niiiiice! | 07:20 |
| pitti | robru: does this use REJECTED_TEMPORARILY vs. _PERMANENTLY, so that it doesn't spam on large queue lagging? | 07:21 |
| rbasak | nacc: nice! | 09:41 |
| Laney | pitti: what's large queue lagging? | 09:43 |
| Laney | The policy uses PASS actually as it doesn't itself reject any items | 09:43 |
| 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:44 |
| Laney | I don't think policies have access to the current verdict, do they? | 09:46 |
| Laney | it just looks at is_valid | 09:46 |
| 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:53 |
| 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:54 |
| pitti | hmm, but would require changing the Policy API | 09:55 |
| 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:56 |
| Laney | right, but API break as you say | 09:57 |
| Laney | so just stuff it into something which already goes into the function | 09:57 |
| 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:01 | |
| pitti | Laney: oh right, maybe just excuse.current_verdict, as an extension (or even better, replacement) to exuse.is_valid | 10:16 |
| pitti | Laney: but aside from that, nice work | 10:17 |
| Laney | pitti: it's robru's work; I'm just reviewing/merging :) | 10:17 |
| Laney | trying to find out how the config generation happens so I can enable it for the dev release only | 10:18 |
| Laney | oho, it's in britney1 | 10:21 |
| * Laney dies slightly | 10:21 | |
| pitti | one can never have enough britneys | 10:23 |
| === marcusto_ is now known as marcustomlinson | ||
| bregma | tjaalton, is the plan to land x.org 1.19 in Zesty? | 11:35 |
| 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:36 |
| bregma | tjaalton, OK, thanks... so far works OK on my laptop sans a few dependency issues when installing (I assume those were fixed) | 11:37 |
| 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:38 |
| 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:42 |
| tjaalton | ah | 11:43 |
| tjaalton | ok | 11:43 |
| tjaalton | was fine here | 11:43 |
| * bregma hums as he run apt update | 11:44 | |
| bregma | tjaalton, confirmed the package in x-staging has my earlier dependency problems fixed, so no worries | 11:47 |
| tjaalton | ok, cool | 11:47 |
| === _salem is now known as salem_ | ||
| xnox | slangasek, is /etc/default/rcS:FSCKFIX=yes at all still in use? | 12:38 |
| 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 | 12:39 |
| jbicha | xnox: https://github.com/debops/ansible-console/issues/39 | 13:04 |
| 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. | 13:11 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| pitti | sil2100: this has some other things to consider too | 15:31 |
| * sil2100 hugs pitti | 15:31 | |
| * pitti hugs sil2100 back | 15:31 | |
| 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:32 |
| Laney | looks like it | 15:33 |
| Laney | nm | 15:33 |
| pitti | yes, that's set in the webhook | 15:36 |
| pitti | our machinery only sets $UPSTREAM_PULL_REQUEST | 15:37 |
| === Guest2979 is now known as karstensrage | ||
| mun24 | I created a executable in linux. which I need to change somtimes | 16:56 |
| mun24 | so I want to send a command to executable in linux and restart itself | 16:57 |
| mun24 | how can I do that | 16:57 |
| 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:03 |
| 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? | 17:16 |
| 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:00 |
| 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:06 |
| cjwatson | That is fairly weird | 18:07 |
| cjwatson | You can safely ignore it for this purpose though | 18:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:12 |
| 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 | 18:13 |
| bdrung_work | pitti, i saw https://www.piware.de/2011/08/apport-retrace-made-useful/ | 19:56 |
| 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? | 19:57 |
| === JanC is now known as Guest31591 | ||
| === JanC_ is now known as JanC | ||
| 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:10 |
| dobey | anyond around familiar with proposed-migration? | 21:16 |
| 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:18 | |
| dobey | oh | 21:19 |
| dobey | i wonder why the upload last week migrated then | 21:19 |
| dobey | Laney: can you upload a new ubuntu-meta with that dropped from ubuntu-touch? | 21:20 |
| Laney | dropped or updated? | 21:20 |
| 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:22 |
| 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:23 |
| 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:24 |
| slangasek | Laney: doesn't appear that a previous abi of gir1.2-ubuntu-app-launch was ever seeded before? | 21:25 |
| 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:26 |
| 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:27 | |
| 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:28 |
| 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:29 |
| 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:30 |
| slangasek | heh | 21:31 |
| Laney | dobey: it's uploaded | 21:33 |
| dobey | Laney: thanks! | 21:33 |
| dobey | hopefully it'll migrate now :) | 21:33 |
| 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:35 |
| * Laney 's conscience is clean | 21:36 | |
| dobey | hmm, i wonder where the upload went | 22:18 |
| dobey | don't see it on launchpad or in britney yet :-/ | 22:18 |
| Laney | dobey: it went in now | 22:27 |
| dobey | Laney: ok, thanks | 22:34 |
| dobey | ah was looking at ubuntu-meta instead of ubuntu-touch-meta | 22:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!