[01:55] nacc: I've verified that the extension works :) [02:07] infinity, oh the symlink was borked, can you take a look at this fix http://pastebin.com/ttxZLdxP [02:16] slangasek: ^-- Can you sponsor/review that for Tim? [02:50] infinity: slangasek: I will sponsor that ^ if you haven't already taken care of it [02:54] cyphermox: is the destination of that symlink correct? it's still /root/etc/.. [02:54] the file needs to go in /root, but what it links to should be the path without /root [02:54] the diff looks correct to me [02:55] thanks [02:55] this is because casper runs outside the chroot where our live system is [02:56] I always think of /root as a user directory, for uid 0 .. not as a mount point. It kinda hurts my head. :) [02:57] ;) [04:09] cyphermox, thanks! [04:10] np [04:33] doko: i don't have time to wait for it to get past debian NEW, there's no diff [04:50] pitti: morning. if you want to look at one before I publish the silo, here's one stuck Test in progress: https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-010/excuses.html [05:40] good monring [05:40] may be too early for a well typed morning :-) [05:50] morning pitti, thanks for htop! [05:51] Good morning [05:52] Mirv: right, let me look into the logs in some 10 mins [06:22] pitti: hi, you might remember working with mlankhorst 2y ago on xorg-lts-transitional? any idea why the packages were limited to just amd64 & i386? [06:22] this package was added to trusty to allow upgrades from lts-foo stacks [06:22] and I had no idea about it until yesterday :P [06:23] tjaalton: yes, I think we discussed the upgrade approach back then; but no idea why it's limited to these arches [06:24] tjaalton: perhaps because we only did the enablement stacks on those? [06:25] well they are built on every arch but I guess there are no desktop images for other than these [06:26] images that use an lts stack === athairus is now known as afkthairus [06:51] Mirv: I followed up to bug 1571353 [06:51] bug 1571353 in Auto Package Testing "test requests sometimes get lost and stay "in progress" forever" [Undecided,Incomplete] https://launchpad.net/bugs/1571353 [06:51] Mirv: so the tests actually did run, but there's something between ci train and britney that doesn't pick them up [06:51] Mirv: I asked robru about getting a debug log [06:52] pitti: Hmmmmmmm? [06:53] pitti: you want me to re enable -v on the britney runs? [06:53] (OTP, brb) [06:59] robru: yes, that would be nice; either in production, or an one-off run [07:26] pitti: Mirv: ok I added the -v flag back, you should see the verbose logs in the next run, maybe ~1hr [07:26] robru: cool, thanks [07:27] yw [07:39] pitti: thank you for looking into it [07:46] mwhudson: so, I started another run from your branch with -s, and will let you ssh into the testbed right after the failure happens [07:46] mwhudson: then we can poke around [07:46] pitti: yeah that would be very useful i think [07:47] step 1: wtf is actually listening on 10.0.8.1:8443 [08:11] infinity: Did you see we have powerpc images at http://cloud-images.ubuntu.com/xenial/current/? ^_^ If you have the time (you don't have much else going on this week, right?), a test would be appreciated. :) [08:12] (Getting them in to streams is WIP; I'm poking this along when I have a minute between tamping down release-critical fires, and it doesn't matter too much if this lands post-GA :) [09:40] nacc: lazr.restfulclient fix working its way into xenial-proposed now; thanks for the nudge [09:56] are there differences between debians ppc64el and ours? [09:57] seems like at least some compiler macros are defined in xenial that aren't in unstable [10:01] ah no the compiler reports itself as ibm oO [10:19] pitti: did you get better logs now? === victorp_ is now known as victorp [10:49] does someone have access to a ppc64el box for a quick test? [10:49] not necessary as I can likely fix it without access but I am curious what the compiler doing === xavigarcia is now known as xavigarcia_lunch [11:02] Mirv: yes, I did, and I just finished writing the followup to the bug [11:02] robru: you can disable verbosity again, thanks for your help === hikiko is now known as hikiko|ln [11:02] Mirv: it's clear now what happened, I'll restart your lost test [11:05] pitti: thanks a lot! the silo is already gone through QA so I was just holding off for getting this debugged which should help people in the future. [11:05] pitti: interestingly the silo was already britney approved last week (which is why it went to QA queue), but at some point I noticed all of its tests, including passed ones, were restarted. [11:05] Mirv: ah! well, nothing lost except for some additional universe heating then :) [11:06] :) [11:06] Mirv: hm, that's curious -- it should see the previously passed results then [11:06] unless the whole silo got cleared [11:06] or did that involve a followup upload? (this would re-trigger all tests) [11:06] pitti: nothing happened in the silo, I guessed it was some sort of global restart of things. [11:07] the silo has stood still since last Wednesday [11:07] Mirv: ok, whatever then :) I understand what's going on, I'll think about how to solve this in the least possible ugly way [11:07] yet something caused that. so I noticed it from the fact that suddenly bileto showed "Running" instead of "Approved" [11:07] thank you again for looking into it [11:13] What is the difference from Ubuntu core and a system which is debootstrapped? [11:16] jtaylor: can test something for you if you want [11:16] pitti: if you have time great, I already fixed the problem but my curiousity remains :) [11:17] meh, no xenial schroot on the porter box; -- moving to a scalingstack instance [11:18] jtaylor: so what do you want me to run? [11:19] pitti: http://paste.ubuntu.com/15928177/ [11:19] should be cat ftest.s, not cat test.s [11:23] jtaylor: http://paste.ubuntu.com/15928232/ [11:23] jtaylor: that's actually the first piece of Fortran that I'm looking at, from the last 20 or so years :) [11:23] pitti: thx so there is an IBM in there which trips the package up [11:24] and also looks like its ubuntu specific which explains why debian is not affected [11:24] pitti: if only I could say the same ._. [11:25] still ahve to occasionally deal with f77 code, written when f77 was actually new ... [11:25] + * Update the ibm branch to 20160324. [11:25] jtaylor: ^ in https://patches.ubuntu.com/g/gcc-5/gcc-5_5.3.1-14ubuntu2.patch [11:25] jtaylor: can I delete that ppc instance again, or do you still need anythign? [11:26] pitti: no thats it thanks [11:26] the ibm in the output in ubuntu is fine its just the package that does a pretty dumb check [11:26] it just does essentially grep IBM = ibm compiler [11:26] nice, I was eyeing that failure [11:26] Laney: the latest upload has fixed it [11:27] I see that [11:27] I did check debian if all arches work first but this was ubuntu specific :/ === hikiko|ln is now known as hikiko [11:40] barry: sounds like https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/t/tox/20160419_041620@/log.gz is caused by the new virtualenv === xavigarcia_lunch is now known as xavigarcia [12:13] Laney: see, i don't quite understand that because 15.0.1+ds-2 fixes it for me locally :( [12:15] Laney: and the same versions work in an sid chroot [12:15] *and* a xenial chroot [12:15] * barry retries [12:16] at least it will give me time to get some breakfast and caffeine first ;) [12:16] :( [12:22] barry: adt-run --output-dir /tmp/virtualenv/out --timeout-copy=6000 --setup-commands 'if grep -q trusty /etc/lsb-release; then apt-get install -y build-essential; fi; apt-get purge --auto-remove -y ubuntu-snappy-cli || true' --apt-pocket=proposed=src:python-virtualenv --apt-upgrade tox --env=ADT_TEST_TRIGGERS=python-virtualenv/15.0.1+ds-2 --- qemu ~/temp/adt-xenial-amd64-cloud.img [12:22] this makes it reproduce [12:22] with an adt-buildvm-ubuntu-cloud thing === _salem is now known as salem_ [12:50] Laney: okay thanks. let me see if i can figure out what's up === davidcalle_ is now known as davidcalle === zyga_ is now known as zyga [13:08] Laney: so the problem with your reproducer is that it doesn't pick up python-pip-whl 8.1.1-2 which is where one half of the fix is. if you add ,src:python-pip to the --apt-pocket option, then it does pick up 8.1.1-2 and all the tests pass. notice in the excuses log file that it is picking up pip 8.1.1-2 but it's still picking up virtualenv 15.0.1+ds-1 but the other half of the fix is from 15.0.1+ds-2. [13:08] https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/p/python-virtualenv/20160418_153721@/log.gz [13:08] Laney: so why isn't excuses picking up both pip 8.1.1-2 and virtualenv 15.0.1+ds-2? [13:09] similarly, the tox failure is picking up python-pip-whl 8.1.1-1 and virtualenv 15.0.1+ds-2 [13:10] barry: It's using the smallest amount of stuff possible from -proposed [13:10] do you want a Breaks or something? [13:11] Laney: i guess, if that'll make sure the right versions of both are picked up [13:11] barry: We could retry with both, but it seems correct to add it if you need both pieces to have working stuff [13:11] Laney: let me look [13:12] doesn't help that debian broke my sbuild ;) [13:13] maybe just add a Depends: python-pip-whl (>= 8.1.1-2) to virtualenv? (and similar to tox) [13:13] Laney: ^^ [13:27] barry: Probably just virtualenv is enough? [13:32] Laney: possibly. let's try that first and see. i'll upload to debian momentarily and syncpackage it over when lp picks it up. if that's not good enough i'll add a version constraint to tox on virtualenv [13:32] Laney: http://paste.ubuntu.com/15929623/ [13:32] barry: That'll force the new one to be installed, which I think is Good Enough [13:32] Laney: +1 [13:33] feel free to syncpackage --no-lp imho [13:33] Laney: ack === maxb_ is now known as maxb [14:11] Excuse the noob's question but I've been running Xenial since the beginning so why is the archive pushing me >500 packages two days from release ? [14:12] caribou: what packages? I maybe got 30 in last two days [14:14] gQuigs: well, 629 packages to be exact so most of everything including LibreOffice, vim, xorg,juju [14:15] caribou: are you using a mirror that has just been kicked into life perhaps or something? [14:15] rbasak: archive.ubuntu.com [14:15] There have been many minor (bugfix) updates flowing through recently BTW. [14:18] libreoffice was last changed in xenial on 2016-04-08 [14:19] caribou: I last updated libreoffice on 2016-04-13 [14:19] perhaps your apt-get update was failing for some reason [14:20] cjwatson: I was on training last week, I didn't do any upgrade during this time so the dates make sense [14:20] caribou: do you have IPv6 by any chance? [14:20] oh ok [14:20] gQuigs: no still ipv4 but looks like it's normal, sorry for the noise [14:20] there you go, so not "two days before release" :) [14:21] cjwatson: indeed [14:56] stgraber, apw, smoser: FYI, I filed bug 1572188 about the underlying bug for the weird lxc test failures [14:56] bug 1572188 in cloud-utils (Ubuntu) ""ubuntu-cloudimg-query xenial daily" fails with "confused by argument: xenial"" [Undecided,New] https://launchpad.net/bugs/1572188 [14:57] cjwatson: thanks! [14:57] Pharaoh_Atem: awesome, thanks! [14:57] pitti, apt-get install distro-info [14:57] smoser: ooh [14:58] smoser: curious, why does it work for precise and trusty then? [14:58] $ grep KNOWN_RELEASES /usr/bin/ubuntu-cloudimg-query [14:58] KNOWN_RELEASES="hardy karmic lucid maverick natty oneiric precise quantal [14:58] local releases="${KNOWN_RELEASES}" r="" [14:58] some hardcoded fallback list? (I thought this queries the remote json for available releases, not distro-info) [14:58] aah [14:59] ubutnu-cloud-image-query just needs *really needs* to be replaced by something reading the stream data. [15:02] smoser: thanks for this [15:02] I guess it recommends distro-info but doesn't depend on it or something? [15:02] yep [15:02] and we somehow had some images that did have it for whatever reasons, explaining the random results [15:03] stgraber: I think I know this [15:03] pitti: is distro-info something we should have in the adt image or do you prefer a new test dep on lxc instead? [15:03] stgraber: for a while now creating adt images on lcy01 has failed [15:03] it is a recommends. [15:03] ah, so old images have it, new ones do or something [15:03] stgraber: so sometimes we run tests on full fat cloud images (on lcy01), and sometimes on adt images (on lgw01 or bos01) [15:03] and the latter are minimized and presumably don't have distro-info [15:03] smoser: yeah, won't do us much good since adt doesn't pull recommends [15:04] stgraber: well, you can tell it to [15:04] Either add "Restrictions: needs-recommends" or add "distro-info" as a test dependency [15:04] (just wrote that to the bug) [15:04] oh, then I guess I should do that everywhere because that's kinda what we expect with it being the distro default :) [15:04] "The Recommends field should list packages that would be found together with this one in all but unusual installations. " [15:04] well, depends what you want to test [15:04] I want to test the thing my users will get [15:04] which means, having the recommends [15:04] unless you want to test unusual installations :) [15:04] if you want to verify that your recommends are really optional, then you don't want that [15:05] for days now i've not been able to update my xenial laptop, alwyas get Hash Sum mismatches [15:05] well, someone installing lxc with --no-install-recommends wouldn't be getting the templates at all :) [15:05] stgraber: anyway, let me know if I should upload lxc with that, or you want to do it from teh airpirt [15:05] airport too [15:05] hallyn, hm... those shoudl be gone the way of the dinosaur [15:05] pitti: I can do it [15:06] smoser: ... [15:06] https://bugs.launchpad.net/launchpad/+bug/1430011 [15:06] Launchpad bug 1430011 in Launchpad itself "support apt by-hash mirrors" [High,Fix released] [15:06] and http://www.chiark.greenend.org.uk/~cjwatson/blog/no-more-hash-sum-mismatch-errors.html [15:06] hallyn: using apt-cacher-ng by any chance? [15:06] so that is interesting that you see it. [15:06] smoser: then i call that a big fat fail :) [15:06] yeah [15:06] i was thinking i should turn it off for a bit, but... [15:06] There will still be some people who won’t yet benefit from this. debmirror doesn’t support by-hash yet; apt-cacher-ng only supports it as of xenial, although there’s an easy configuration workaround [15:06] hallyn: I had lots of troubles with that until cjwatson helpfully pointed out /etc/apt-cacher-ng/backends_ubuntu [15:06] (see the cjwatson link there, hallyn) [15:06] hallyn: for me this was pointing to "de.archive.ubuntu.com", i. e. it would divert all requests to *archive.ubuntu.com to that [15:07] hallyn: which caused hash sum mismatches to no end [15:07] pitti, we can update cloud-utils if yiou want. [15:07] pitti: so you removed it? pointed it to locahost? [15:07] to contain 'xenial' [15:07] I changed that to just a.u.c. and I've never gotten it ever since [15:07] a? [15:07] I raised this in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819852; no response yet [15:07] Debian bug 819852 in apt-cacher-ng "apt-cacher-ng: support by-hash index files" [Normal,Open] [15:07] a = archive [15:07] hallyn: archive.ubuntu.com [15:08] cjwatson: oh, so i should turn it off? [15:08] hallyn: well, full contents is: http://archive.ubuntu.com/ubuntu/ [15:08] pitti: ok, thats where mine is pointing [15:08] pitti: uploaded [15:08] no, us.archive... ok lemme try dropping us. [15:08] hallyn: hmm, so it's not that then; for me that was it [15:08] hallyn: that's not what I said :) [15:08] hallyn: dropping us.archive.ubuntu.com from /etc/apt-cacher-ng/backends_ubuntu will probably indeed deal with it for the moment [15:08] stgraber: cheers [15:08] cjwatson: i'm having a hard time following [15:08] pitti: didn't test to see if we may need more than that though, not enough bandwidth for that, but since all the other tests passed, that should really be it [15:08] hallyn: just interleaved IRC conversations [15:09] hallyn: my last-but-one statement is in agreement with pitti, so do that [15:09] neither emptying the file nor using http://archive.ubuntu.com/ubuntu/ seems to help [15:10] stgraber: should be fine [15:10] do i need to apt clean? [15:10] hallyn: apt-get -oDebug::Acquire::http=1 -oDebug::Hashes=1 update [15:10] hallyn: apt clean -> no, that's entirely useless here [15:12] http://paste.ubuntu.com/15931040/ and http://paste.ubuntu.com/15931043/ [15:14] that doesn't look like a hash sum mismatch [15:14] just google's repo not being signed enough [15:14] I had that too, I just removed it [15:14] indeed, I see no hash sum mismatches there. [15:15] I'm happy to debug a hash sum mismatch, but only if you can show me update output with those debug options that actually exhibits a hash sum mismatch [15:15] d'oh, sorry, http://paste.ubuntu.com/15931102/ [15:15] i pasted the same file twice [15:15] that's a mismatch on debs, rather than on indexes [15:15] which suggests apt-cacher-ng has cached corrupt data [15:15] [15:15] ok [15:15] you may shrug but it's important! [15:16] I would probably rm -rf the relevant bit of apt-cacher-ng's cache and start again [15:16] it's clearly got itself hopelessly lost [15:16] There was an apt bug causing deb download corruption. [15:16] ok, lemme rm -rf its cache [15:16] * rbasak looks [15:16] those files don't change content without changing URL and never have [15:17] so it seems to me this should be self-healing [15:17] I've seen acng corrupting data in the past, but not for a while [15:17] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810796 [15:17] Debian bug 810796 in apt "HTTP pipelining is broken and causes download failures" [Normal,Fixed] [15:17] i'm on the road, there's a good chance acng isn't entirely to blame, [15:17] Should be fixed in the archive. [15:17] it can probably only be self-healing with cooperation from acng [15:18] But if it's regressed or soemthing, then turning off HTTP pipelining may help. [15:18] if it's cached lies and persistently continues to serve them, there's not a whole lot apt can do [15:18] cjwatson: as a naive user, seems like it should be able to tell acng "that doesn't seem right, try again" [15:19] hallyn: that still requires cooperation from acng ... [15:19] of course [15:19] why is that bad? [15:19] it's not, but it's what I said above and you appeared to be contradicting me? [15:20] hm, no, wasn't contradicting you [15:20] AFAICS apt-cacher-ng does not implement the relevant cache-busting headers at all [15:20] there are such headers? [15:20] it just entirely ignores stuff like Pragma: no-cache and Cache-Control [15:21] might be something i could look into this spring [15:22] https://tools.ietf.org/html/rfc2616#section-14.9 [15:24] the thing that's needed would be for it to implement Cache-Control: max-age=, I think [15:25] is apt sending that now? [15:25] no, but it's the basic mechanism that would be necessary to recover from this sort of thing [15:26] seems like 'fetch url1; hash some mismatch; fetch url1?refetch' would more directly fix it [15:26] apt could at least conceivably send it as an attempt to recover from a hash mismatch on a package [15:26] but i guess that doesn't fit into the spec [15:26] hallyn: the "refetch" step in your pseudocode would need to be implemented by adding the Cache-Control: max-age=0 header [15:26] right [15:27] ok, maybe i'll look into that, thx [15:27] np [15:27] just for clarity, this is unrelated to any of the stuff I changed recently [15:27] cjwatson: right, [15:30] and i think i know wha thappened - damned internet provider a few days ago redirected requests to their signin page and corrupted apt-cache-ng. so yeah i want to code the automatic fix for that [15:31] right, captive portals are the work of the devil [15:31] apt itself is a lot better at dealing with those than it used to be [15:31] i.e. it doesn't save stuff that doesn't validate [15:31] but I don't think acng is clever enough for that :-/ [15:32] so that's a separate fix, if acng understood the current state of the archive it's trying to fetch well enough, it could just not cache resources that can't possibly fit into it. I don't know if that's feasible within acng's design [15:32] and then once google chrome gets redirected it caches that value, and send sme back to the portal every time until i go to settings to clear all cached pages :) [15:32] hm, yeah, that could be simpler [15:32] and good enough for me [15:33] I suspect that right now it doesn't parse the archive's index files in enough detail to be able to do that [15:34] probably something to discuss with upstream before thinking about implementing it [15:36] hallyn: NM can help you distinguish if you're behind a captive portal, if it helps [15:36] cyphermox: NM can't even find my mr3020 hotspot half the time [15:37] o.O? [15:37] cyphermox: but the problem is captive portals which randomly and frequently recet [15:37] (crappy-ass tengo internet in particular) [15:37] reset even [15:38] yeah, but that's what I'm saying, it can poll some website of your choosing, look for a string, every $interval [15:38] so it's not at connect time - apt is going along fine, then it resends me to the portal [15:38] right but interval isn't actually regular. sometimes it's every day, sometimes every 2 minutes (at the same location) [15:38] and flip a key available in DBus that tells whether you have local or global connectivity (global meaning said website got the string) [15:38] they really are broken... [15:38] ok [15:38] i had a script doing it by hand, every 5 minutes - still not good enough :) [15:39] ok [15:39] threaten them with less money? [15:39] cyphermox: now maybe i should be doing something like keeping a connection open and detecting when it's hung [15:39] hah, the curse of free [15:39] oh ;) [15:39] i *should* get satelite internet. but $$ [15:39] hallyn: what kind of internet right now? [15:40] now meanwhile, yes, i shoudl file a bug on NM and my hotspot. soemtimes it just doesn't find it [15:40] maybe you could do some keepalive magic. [15:40] cyphermox: at this very moemnt, it's tengo internet at an rv park in austin. [15:40] right, but that's wifi? [15:40] or dialup? [15:40] oh, yeah. [15:41] so a ubiquity m.2 rocket connected to tengo internet, with tp-link mr-3020 serving that to other devices [15:41] sometimes NM doesn't find th emr-3020, so i use scripts manually using wpa-supplicant :( [15:41] 'manually' [15:41] what kind of logs can i provide for a bug report? [15:42] pretty much just syslog would have everything [15:42] 'sudo dmesg', or journalctl -u network-manager or something? [15:42] NM just gets whatever wpasupplicant returns, but it has some issues in wily, and different issues in xenial [15:42] nah, /var/log/syslog [15:42] i'm on xenial atm, [15:43] ok, i'll switch back to n-m after a meeting and file a bug when it happens [15:43] thx [15:43] i should see if nmcli usage has changed recently too.... [15:59] slangasek: fyi, debian testing may just remove php-horde-mongo; not sure if we'd want to follow suit (it's one of our two remaining known-broken packages). Only has reverse-recommends in the archive, and will probably need to add a new package (https://github.com/mongodb/mongo-php-library) which Debian is not planning on adding [16:00] nacc: yes, removal is fine/appropriate; file a bug? [16:01] slangasek: ack, will do [16:03] pitti: Will you be testing the SRUs in bug 1560797? If not I can do it. [16:04] bug 1560797 in apt (Ubuntu Wily) "apt does not configure Pre-Depends: before depending package" [High,Fix committed] https://launchpad.net/bugs/1560797 [16:12] Hi [16:20] Hi my name is Ajith kumar, I am a newbie to the world of Linux environment. I started working with Ubuntu for the past few weeks and i am eager to contribute to the the vibrant community and i have absolutely no idea how to get started.Can some Guide me what to do? P.S:I am a Computer science student and interested to work in coding part. [16:23] !contribute | Ajith there are some good links here [16:23] Ajith there are some good links here: To contribute and help out with Ubuntu, see http://community.ubuntu.com and https://wiki.ubuntu.com/ContributeToUbuntu [16:28] Thank you for your help ubottu and Pici [16:54] doko: fyi a numpy delta and the fftw delta could now be dropped due to build depends on universe for main being allowed now [16:55] numpy is just for plots in the docs and fftw is an mpi library which can stay in universe [17:17] nacc: archive removals, ~ubuntu-archive should be subscribed (done for bug #1564103) [17:17] bug 1564103 in php-horde-mongo (Ubuntu) "Please remove php-horde-mongo from the archive" [Undecided,New] https://launchpad.net/bugs/1564103 [17:19] slangasek: ack, was just about to, sorry [17:24] nacc: ok - figured that might be the case, but you subscribed me first so I interfered ;) [17:24] slangasek: absolutely, appreciate it :) [17:32] bdmurray: I'll do some tests, but if you have a setup ready for doing upgrade tests with that, that'd be appreicated of course [17:33] pitti: I did wily already [17:33] bdmurray: oh wow, thanks [18:21] infinity, hi [18:25] tkamppeter: I'm getting there. [18:25] tkamppeter: You're in a queue. [18:26] .. all alike [18:27] OK [18:27] pitti: You still around? === salem_ is now known as _salem === afkthairus is now known as athairus === _salem is now known as salem_ [19:00] infinity: I am now (for another hour or so) [19:00] pitti: did you do anything to fix lxd before? [19:00] Laney: sorry, before what? [19:00] pitti: [19:00] Apr 19 12:24:20 nosferatu systemd-fsck[574]: /dev/sda1: 7 files, 7094/489976 clusters [19:01] pitti: ^-- That line's hitting the console on boot. lolwut. [19:01] It had some proxy / network problem, but then started passing [19:01] The latest upload is failing again [19:01] Wondering if you did some magic or if it's a real bug [19:01] pitti: Purely cosmetic, but between that and 1 line from the kernel, we're close to a completely quiet boot. [19:02] Laney: hm, no; my first reaction was that it might depend on whether it runs on lcy01 (standard cloud images) vs. lgw01 (minimized adt images), but we purge lxd on lcy01 too [19:02] infinity: oh dear, I smell some plymouth ordering/race again [19:03] Laney: not sure what you mean, http://autopkgtest.ubuntu.com/packages/l/lxd/xenial/amd64/ looks pretty good? [19:03] Laney: or do you mean lxc? [19:03] pitti: oh, whoops, brain fart, I mean snapd [19:03] s/lxd/snapd/g === pat_ is now known as pmcgowan [19:04] Laney: don't do that :) [19:04] infinity: oh, wait, yeah -- that's initramfs [19:05] infinity: when we merged that from debian the last time, fsck and r/w mount of / moved into initramfs [19:05] pitti: Oh, right. [19:05] pitti: So, would be nice to figure out how to shut that up on !error. [19:05] back then I mentinoed that this will give us non-pretty fsck for root fs, but we didn't seem overly concerned [19:05] infinity: well, fsck might take several minutes, you do want to see this [19:06] If there's an actual fsck, that's a different case than the mount-time fake fsck. [19:07] infinity: yeah, if it's quick it would be nice to hide indeed [19:08] infinity: ah, the thing you quoted above is a "short" one? [19:08] pitti: Yeah, that wasn't a "real" fsck, that's the "you asked me to fsck a clean filesystem, so I didn nothing" fsck. [19:08] pitti: ie: I see it on every boot. [19:09] Oh! [19:09] That's not even my root. [19:09] That's the EFI filesystem. [19:09] Hence having "7 files". :P [19:11] ah ok, so that should be under the control of the real root then [19:12] Indeed. [19:12] Hence why it's systemd-fsck, and in the journal. [19:12] Laney: I interpreted http://autopkgtest.ubuntu.com/packages/s/snapd/xenial/amd64/ as "1.9.3 was broken", 1.9.4 fixed, and 2.0.2 introduced another failure [19:13] But maybe the one we saw was from the initramfs. [19:13] Laney: and the first and second result both ran on lgw (i. e. on a minimized adt image), so not much infra difference there [19:14] pitti: We're going to have another look before blaming systemd. I think your theory makes more sense. [19:14] Laney: did you already try running this locally? [19:14] pitti: I'm suspicious because the failures look the same (i.e. what we created a debug instance for mvo to mess around on the other day) [19:14] infinity: I'm trying to reproduce with a fake fsck which takes very long [19:14] Didn't run it myself, will do. [19:15] infinity: it wouldn't surprise me at all if any of this regressed :/ [19:15] Laney: the "error: no snaps found for "hello-world" [19:15] ...thingy? [19:15] pitti: Yeah [19:16] * Laney runs it [19:17] pitti, Laney: I think its a store issue, I work on this with the store team as we speak [19:17] hey mvo! [19:17] you mean a real bug? [19:17] is that what you found out the other day? [19:19] pitti, Laney: I am waiting for a new rollout, I think this will fix it [19:19] pitti, Laney: however there might be yet another issue, but we fixed the http proxy thing so that should be ok [19:19] the store also moved to a cdn but that should be ok with the proxy fix we did [19:20] infinity: just FAOD, this is with "splash", right? [19:21] Laney, pitti: so hopefulyl in ~1h we have a new store rollout and I will retrigger the tests (I hope I can actually do that) [19:21] yeah, you can if you can upload it [19:22] Ah yeah, this fails locally [19:22] mvo: you can test the retry button now on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#snapd (the machinery is mostly idle, so no harm) [19:23] pitti: excellent, thanks. will do as soon as the store is updated [19:23] pitti: With splash, yes (though you only catch it for a brief flickery moment), shows without too, obviously. [19:25] infinity: hmm, I created a partition for /mnt in fstab, and I get plymouth-y pretty fsck [19:25] (with a fake fsck that takes long) [19:26] * pitti runs update-initramfs to get that into the initrd [19:27] for the root fs I seem to have the opposite problem: I *don't* get the fsck output in initramfs [19:27] oh, I see -- it uses bash, and that's not in the initrd [19:29] And shouldn't be... [19:29] right, I just need to change the mock to use sh [19:35] pitti: What have we decided WRT snapd? [19:35] infinity: AFAICT, wait for the store to get fixed (< 1 h) and retrigger the tests? [19:35] that's what mvo asked above, at least [19:36] otherwise I'm fine to hint it in if it blocks stuff [19:37] pitti: Well, it sort of blocks some world rebuilds slightly. [19:38] go and hint if it blocks stuff [19:38] * pitti goes and hints [19:39] I went and I hinted :) [19:41] !regression-alert [19:41] bdmurray, cjwatson, Daviey, didrocks, doko, infinity, jdstrand, pitti, RAOF, Riddell, ScottK, seb128, skaet, slangasek, SpamapS, stgraber: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive [19:41] https://launchpad.net/ubuntu/+source/samba/2:3.6.25-0ubuntu0.12.04.2 [19:41] https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1572122 [19:41] Launchpad bug 1572122 in samba (Ubuntu) "Samba upgrade break LDAP authentification only for my w7 clients" [Undecided,New] [19:41] ^ someone pointed me to this [19:42] mdeslaur: ^ [19:42] fwiw; I have two more links about the issue: http://serverfault.com/questions/771388/how-can-i-fix-samba-3-6-25-the-trust-relationship-between-this-workstation-and http://askubuntu.com/questions/759123/samba-23-6-25-0ubuntu0-12-04-2-as-pdc-samba3-nt4-domain-windows-machines-lost [19:43] cyphermox: I should point out this sounds like a known issue in Microsoft's recent patches [19:43] (not entirely related, but lots of domain auth issues on w7 after recent patches) [19:43] cyphermox: yeah, it's broken [19:43] ^ thats what i guessed though [19:43] teward: no idea, I don't know Samba well enough to know, and don't typically run any Windows machines here [19:43] have to wait for fixes from upstream/redhat [19:43] mdeslaur: ok [19:44] cyphermox: stgraber and I already yelled at mdeslaur about it. [19:44] (After stgraber's mom yelled at him) [19:44] infinity: unrelated issue [19:44] infinity: sorry, I scrolled back and didn't see. [19:44] mdeslaur: Oh. Two similar breakages? [19:45] what's the other issue? [19:45] cyphermox: can you remind me where that regression-alert is documented? because I'd really like to deprecate it :) we ought to just use the regression-updates tag on bugs [19:45] Forcing TLS unconditionally. [19:45] infinity: the other one isn't similar, it's that the whole point of the samba update was to disable plain text ldap [19:45] mdeslaur: Well, similar from the bug subject, I didn't click and read it. :P [19:45] slangasek: https://wiki.ubuntu.com/StableReleaseUpdates#Regressions [19:46] slangasek: https://wiki.ubuntu.com/StableReleaseUpdates#Regressions [19:46] there are currently 4 different regression from the samba badlock updates [19:46] infinity: ^^ can I rip !regression-alert out of there? :) [19:46] slangasek: Go nuts. [19:46] slangasek: Want the trigger gone from ubottu? [19:47] It is useful to be able to be heard on occasion, as opposed to wondering if somebody's about for something one things is important. [19:47] (and time-critical) [19:47] I mean not for any old regression, but one that is actively breaking users and might be worth suspending. [19:49] rbasak: well, the trigger in question also has a somewhat stale list of people to highlight [19:49] That's true. [19:49] Could update it. [19:50] I suggest updating it and updating the docs to suggest that it be used only in more restricted circumstances. [19:50] feel free to add me to that list [19:51] I wouldn't mind seeing those pings either [19:51] Yeah, the one time I used it it was massive overkill. [19:51] Had I realised what it would do, I would just have mentioned it in here and seen what happened. [19:51] (by an Ubuntu dev perhaps, if not ask for an Ubuntu dev to check on the same channel, and only if suspending the update would be helpful) [19:53] infinity: I finally have an initramfs compatible mock fsck, but when I boot (the VM) with the default quiet splash $vt_handoff, I just keep the slightly purple plymouth screen and the initrd's fsck happens on VT7 [19:53] meh [19:53] rbasak: I don't think it's used that often anyway [19:53] and not for just any regression either [19:53] I see it being used once a month or less [19:53] right [19:54] I certainly wouldn't go nuts for a NM regression ;) [19:54] shim/grub/boot stuff, maybe more. [19:54] pitti: S'ok. I'll sort this one out with Andy, lay blame, and fix it in an SRU. Perfectly pretty boot isn't RC, it's just nice to have. :P [19:54] infinity: did we actually ever manage that? [19:54] Well, an NM regression in an SRU I'd say is important. Depending on what it is. Since it could break users from updating to a regression fix. [19:55] * pitti still remembers some lonesome kernel driver message in quiet mode [19:55] rbasak: you can usually still get wired, and the big bad regressions we do catch ahead of time [19:56] infinity: http://people.canonical.com/~pitti/scripts/fsck-mock-initrd is the mock I replaced /sbin/fsck with, FTR [19:56] pitti, until u upgraded to xenial my XPS13 never showed me anything but plymouth til lightdm (now i have two lines of fsck output since the upgrade) [19:56] so yes, at least on preinstalled OEM hardware we achieved it :) [19:57] we merged initramfs-tools like three months ago, this can hardly be a new thing? [19:57] cyphermox: not everyone can get wired. This laptop I'm on cannot, and I don't have a dongle that'll work handy. [19:57] so seeing fsck output was actually known; the bit that's not known is *not* seeing it, i. e. hiding it behind plymouth if fsck happens in the initrd [19:57] pitti: Probabaly not new, I think I was blaming the kernel unti lnow. [19:57] actually, we did know that too [19:57] pitti: Don't worry about it. [19:57] pitti: I'll worry for both of us. :P [19:58] Anyway, my point is that some regressions are bad, and I'd like to shout (and have a good chance of being heard) about time critical ones. That's all. [19:58] infinity: okay :) I guess bedtime then [19:58] rbasak: don't upgrade for my next upload then, we started dropping wifi, it was too broken ;P [19:58] just kidding, of course [19:58] :) [19:59] cyphermox: actually, NM 1.2 landed remarkably quietly, well done [19:59] "wifi support removed due to unreliability issues" [19:59] yeah, only joking, we've been dropping wifi forever [19:59] pitti: so you say. [19:59] slangasek: ah ah only serious [19:59] "tinfoil DoS vulnerability" (cover the aerial) [19:59] pitti: a little too quietly, right cyphermox? [20:00] * slangasek looks at his empty logs [20:00] it's not a murder, but it's not as pretty as it seems either [20:00] well, it's not like I'm reading NM bugs, but I didn't hear any complaints [20:00] slangasek: on that subject, would you mind bringing up logging in wpasupplicant to 11 and looking if the logging gets better? [20:00] cyphermox: if you give me directions how [20:01] slangasek: It's one louder. [20:01] Odd_Bloke: look over there, it's a cloud shaped like a velociraptor [20:01] xnox: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qemu seems to make nova unhappy (uninstallable), can you have a look? [20:02] slangasek: add many -d 's to the Exec line in /usr/share/dbus-1/system-services/fi.w1.wpa_supplicant1.service [20:02] -dd or -ddd would be good [20:03] it *will* log a lot more though [20:04] meh, what's up with s390x tests [20:04] cyphermox: ok. also the wireless hasn't dropped since yesterday so now it's teasing us [20:04] cyphermox: So that'd be add you and md, drop Riddell, Scott, skaet, and SpamapS? [20:04] why do I always get the heisenbugs? [20:04] Unit193: I suppose yeah, unless slangasek really wants to drop it completely [20:04] pitti: I see no reason that should actually be true. [20:05] cyphermox, Unit193: I honestly don't think it's useful; I think rbasak knows how to get ahold of SRU team members without it, and generally it renders for me as a contentless highlight well after I've read the bug in email (if the bug is tagged appropriately) [20:05] if you want to omit me from the highlight list that is also ok ;) [20:06] if it's not documented, why bother keeping it? [20:08] * rbasak shrugs [20:08] if someone who knows about it wants it there and wants to use it, I don't mind it being there and won't tell other people how to run their bot [20:08] I don't particularly mind either way. [20:08] Since I can always highlight people manually if I feel the need as you point out I suppose. [20:09] I don't read mid-line highlights anyway. [20:09] As long as it doesn't result in some additional delay for some serious could-have-acted regression. [20:09] So lists don't work for me. [20:10] (I only recall having found one or two since I started Ubuntu development in 2011) [20:10] So I can talk about infinity all I want and he'd not see it? Awesome. :D [20:10] * Unit193 ducks. [20:11] I don't particularly mind either way> I suppose that's different to what I said earlier. I'm weakening my objection. [20:15] !forget regression-alert [20:15] I'll forget that, Unit193 [20:15] cyphermox: There you go. [20:22] Does reverse-depends tell me about the release pocket or the proposed pocket? [20:22] release [20:22] OK, thanks [20:33] The following packages have unmet dependencies: [20:33] qemu-system : Depends: qemu-system-s390x [20:33] infinity: ^ my xenial-proposed schroot says there is a problem -- maybe just publisher delay from binNEW or so? [20:33] qemu-system-s390x | 1:2.5+dfsg-5ubuntu9 | xenial-proposed | s390x [20:33] it doesn't exist on any arch but s390x [20:33] but all arches depend on it [20:34] xnox: ^ [20:34] pitti: Oh. [20:34] pitti: Yeahp, that's a bug. [20:34] infinity, pitti: shall I fix? [20:34] slangasek: Go nuts, if you know how. [20:34] Three uploads the charm [20:34] slangasek: The qemu packaging is whack, yo. [20:34] is it meant to exist on all arches, or is the dep only meant to exist on s390x? [20:34] No, it's meant to only exist on s390x due to not having system emulation. [20:34] * pitti guesses/hopes the former, would be nice :) [20:34] it's a kvm implementation, should not exist on other archs [20:34] qemu-system shouldn't depend on it. [20:34] ah, ok [20:35] Note qemu-system doesn't depend on qemu-system-aarch64 for the same reason, so there should be precedence in the packaging. [20:38] Alright, I'm confused how seed blacklists are supposed to work then, it doesn't appear to as in the manpage. If I blacklist !foo, and it's in an inherited seed, the manpage says it should still be blacklisted and I see in the output '* Blacklisting foo from bar' but it still ends up in the bar-recommends-arch. What gives? [20:40] infinity: would you prefer when I fakesync python-virtualenv -3 (to fix the regression in -proposed) now, or wait until tomorrow when it published in Debian and gets imported into LP? [20:40] (see barry's email) [20:40] although, this change looks strange, just saw the diff [20:41] pitti: It's not seeded, don't care about timing. [20:41] ack [20:43] pitti, infinity: qemu uploaded to fix the bug introduced by that old engineer who refuses to recognize non-mainframes are real architectures [20:43] "old"? :-) [20:44] isn't he like the youngest of us all? :-) [20:44] pitti: he aged 50 years instantaneously the first time he connected to z/VM [20:44] oh, right -- time acceleration near super-fast machines [20:45] am I glad that this doesn't affect ssh connections [20:49] ssh going too fast? [21:00] cjwatson: Perhaps you can tell me what I'm doing wrong, re: above? [21:10] slangasek, Laney, infinity, /etc/X11/Xsession.d/60x11-common_xdg_path do "XDG_DATA_DIRS=/usr/share/"$DESKTOP_SESSION":"$XDG_DATA_DIRS"", and worth case if that would be missing it would only means the override doesn't work so not break much, also the Name= translations are stripped by dh_translations in favor of using gettext so we can langpacks [21:11] Unit193: blacklist doesn't cause the package to be un-seeded; instead it causes the seed as a whole to be considered buggy and invalid if a package is in the seed and matches the blacklist [21:12] slangasek, oh, and please tell me what is wrong with my sed use so I do the correct thing next time :-) [21:13] seb128: two sed commands operating on the same file, so you're repeating the filename... you can pass multiple commands to sed, either as multiple '-e' arguments or just as commands separated by semicolons [21:13] slangasek: Dang, I knew it didn't prevent installation, but from the manpage it seemed like it at least prevented from explicitly being selcted. :/ [21:13] slangasek, oh, good point, I didn't think much when doing that :-/ [21:13] Unit193: it will cause an image build to fail, which is a bit late in the process [21:13] seb128: and it wasn't a critical blocker ;) [21:13] slangasek, I'm going to change it with the next upload [21:13] ...Wow, that's near useless. [21:13] slangasek: Thanks for the info. [21:14] right, was just curious why you meant by "non-DRY" [21:14] seb128: DRY == Dont Repeat Yourself :-) [21:15] ooh, gotcha! [21:15] win 8 [21:16] slangasek, also I'm pondering doing another upload tomorrow (if we get a respin) to include some translations, we could strip the X-Gettext-Domain= for release and put Name[locale]= entries in the new desktop [21:16] then go back to langpacks in a SRU when we get a new langpack export which contains translations for the string [21:17] infinity: ^^ === salem_ is now known as _salem [23:30] cyphermox, console-setup ftbfs [23:46] wat