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