| pitti | Good morning | 04:42 |
|---|---|---|
| === marcusto_ is now known as marcustomlinson | ||
| === cpaelzer_ is now known as cpaelzer | ||
| pitti | rharper, smoser: https://launchpad.net/ubuntu/+source/nplan/0.12 -- my name is Bond. Net Bond. | 06:33 |
| Unit193 | BTW, is that going to Debian? | 06:40 |
| pitti | Unit193: still a bit early I think | 06:41 |
| Unit193 | pitti: So that'd seem to indicate the plan is to push it there eventually, still an answer. :) | 06:42 |
| Unit193 | Thanks. | 06:42 |
| pitti | needs upstreaming of some NetworkManager patches first | 06:42 |
| ccshell | exec fc-match weight=80:family=宋体:lang=zh-cn => it print:DejaVuSerif.ttf: "DejaVu Serif" "Book" | 06:49 |
| ccshell | but fc-match weight=80:family=宋体 => uming.ttc: "AR PL UMing CN" "Light" | 06:49 |
| ccshell | bug? | 06:50 |
| sarnold | $ fc-match weight=80:family=宋体:lang=zh-cn | 06:51 |
| sarnold | NotoSansCJK-Regular.ttc: "Noto Sans CJK SC" "Regular" | 06:51 |
| sarnold | $ fc-match weight=80:family=宋体:lang=zh_CN | 06:51 |
| sarnold | DejaVuSans.ttf: "DejaVu Sans" "Book" | 06:51 |
| === jamespag` is now known as jamespage | ||
| LocutusOfBorg | jbicha, sorry, wrt refcard we reopened the bug at the same time :D | 08:11 |
| === dpm_ is now known as dpm | ||
| tseliot | pitti: hi, are you familiar with this error in u-d-c? I can't build u-d-c in sbuild any more http://pastebin.ubuntu.com/23115343/ | 09:56 |
| tseliot | pitti: with a yakkety schroot | 10:01 |
| tseliot | it builds fine in a xenial schroot | 10:04 |
| pitti | tseliot: doesn't happen here, maybe your yakkety schroot has a different profile whose fstab doesn't mount /dev/pts? | 10:15 |
| tseliot | pitti: I have this in the fstab: /dev/pts /dev/pts none rw,bind 0 0 | 10:17 |
| tseliot | in /etc/schroot/sbuild/fstab | 10:18 |
| pitti | hm, no idea then, I'm afraid :/ | 10:18 |
| tseliot | no problem | 10:25 |
| caribou | shouldn't the ssh-agent be started automagically when you log in ? | 10:28 |
| tseliot | pitti: I have another question. I start the nvidia-persistenced daemon using a udev rule, but the daemon seems to die in Xenial and yakkety. Starting the daemon using systemd (from the udev rule) seems to work though (the only dependency in the systemd job being "Wants=syslog.target"). Is this a reasonable way to do it? | 10:42 |
| pitti | tseliot: you can't start long-running processes from a udev rule directly | 10:43 |
| tseliot | pitti: ah. So what do you recommend? | 10:44 |
| pitti | tseliot: the udev rule can add ENV{SYSTEMD_WANTS}+="some.service" | 10:44 |
| pitti | this will then also respect dependencies etc, i. e. just queue it for startup but not block the rule on it | 10:44 |
| tseliot | pitti: so that will start the systemd job? That would be awesome | 10:44 |
| tseliot | or is it just a dependency? | 10:45 |
| pitti | yes; there's a few existing examples in /run/udev/rules.d | 10:45 |
| pitti | tseliot: well, it will start the given unit plus all of its dependencies | 10:45 |
| pitti | (or in the case of syslog.target, wait unti that is active) | 10:45 |
| tseliot | pitti: that's really cool, thanks! | 10:46 |
| tseliot | pitti: BTW is there an environment variable for udev rules to stop a systemd service? | 10:53 |
| pitti | tseliot: no, there isn't; at most you could run "/bin/systemctl stop --no-block foo.service", but what are you trying to do? | 10:53 |
| pitti | tseliot: making this declarative in the .service itself sounds better, like binding it to a particular device | 10:53 |
| tseliot | pitti: the udev rule should start and stop the daemon when the nvidia module is loaded/unloaded, and when the relevant acpi device is available (for hybrid graphics) | 10:58 |
| tseliot | pitti: are there any examples on how to bind the service to a device? | 10:59 |
| pitti | tseliot: you can't bind to a module, only to a device; if you must react to the module unloading itself, use the RUN+="/bin/systemctl stop --no-block .." approach | 11:00 |
| pitti | well, maybe you can, haven't tried this | 11:00 |
| tseliot | pitti: ok, good. Thanks again | 11:02 |
| === hikiko is now known as hikiko|ln | ||
| xnox | my sbuild is b0rked... can anybody help me what is it trying to tell me? http://paste.ubuntu.com/23115674/ | 11:23 |
| === hikiko|ln is now known as hikiko | ||
| === _salem is now known as salem_ | ||
| === JanC is now known as Guest73215 | ||
| === JanC_ is now known as JanC | ||
| juliank | Hmm | 12:58 |
| juliank | I just synced apt 1.3~rc3 some hours ago, and it fails on amd64 in the tagfile tests | 12:59 |
| juliank | we did not do any changes in the tagfile handling or the test since ~rc2ubuntu3 however | 12:59 |
| juliank | all other architectures work fine, and the test runs successfully on debian unstable and xenial. | 13:00 |
| juliank | So, what else changed since last thursday? Compiler maybe? | 13:01 |
| juliank | Hmm, I only see 6.2.0-1ubuntu11 => 6.2.0-1ubuntu12 change in the build log | 13:05 |
| KurousagiMK2 | binutils? | 13:06 |
| juliank | that changed too | 13:08 |
| juliank | Complete package diff: https://paste.ubuntu.com/23115984/ | 13:09 |
| juliank | Hmm, the tests also run successfully in my yakkety chroot | 13:25 |
| juliank | (via sbuild) | 13:25 |
| xnox | juliank, we can hit the retry button, and assume it's kvm cosmic rays | 13:33 |
| juliank | xnox: I tried that | 13:33 |
| xnox | horum | 13:33 |
| juliank | the only real difference my chroot has is that it uses binutils binutils_2.27-2ubuntu2, not 7ubuntu1 | 13:38 |
| juliank | But I don't really see that affecting parsing of tagfile data embedded string literals | 13:38 |
| sil2100 | slangasek: hey! Who should I ping related to libc issues? Would that be infinity? | 13:44 |
| xnox | sil2100, usually yes. | 13:54 |
| === clobrano1 is now known as clobrano | ||
| seb128 | cjwatson, wgrant, dpm, what's the status about opening translations for yakkety? does it need some stakeholder to get it on a priority list so somebody got assigned the cycles to do the launchpad work? | 13:57 |
| seb128 | willcooke, ^ | 13:57 |
| cjwatson | seb128: it mostly needs me to not be absolutely flat-out sorting out account-key assertions for snappy GA | 13:57 |
| cjwatson | and we need to work out what's going on database-wise with the previous abortive opening | 13:58 |
| seb128 | is wgrant on vac/busy with other things? | 13:58 |
| cjwatson | it was attempted and failed so left some debris | 13:58 |
| kgunn | tjaalton: hey, so hitting a weird errorwhen i try to compile mesa on dragonboard... some.lo's "not a valid libtool" | 13:58 |
| cjwatson | William is also flat-out with snappy GA stuff AFAIK | 13:58 |
| seb128 | k | 13:58 |
| kgunn | tjaalton: i disabled first nouveau... | 13:58 |
| seb128 | so it sounds like "let's talk again in a week"? | 13:58 |
| kgunn | now it's xa | 13:58 |
| cjwatson | which is why not very much LPish has happened lately | 13:58 |
| kgunn | just wondering if you knew the root of the issue | 13:59 |
| kgunn | googling wasn't much help | 13:59 |
| kgunn | ...i'll keep disabling in rules if that's easiest | 13:59 |
| cjwatson | seb128: I'll see if we can squeeze it in somewhere, since yakkety translations can't really wait a few weeks for us to be properly out from under this | 13:59 |
| cjwatson | seb128: but I need to finish my absolutely critical things first ... | 13:59 |
| tjaalton | kgunn: what arch is it? | 14:00 |
| kgunn | arm64 tjaalton | 14:00 |
| kgunn | AH | 14:00 |
| kgunn | oops | 14:00 |
| tjaalton | why isn't the distro provided one good enough? | 14:00 |
| tjaalton | ie. what are you trying to do?-) | 14:00 |
| kgunn | tjaalton: i was just trying to compile the freedreno drivers on the device... | 14:01 |
| sil2100 | xnox: is infinity on holidays this week, or do I remember that wrong? | 14:01 |
| kgunn | but now that you mention it | 14:01 |
| kgunn | tjaalton: since someone recently enabled gallium | 14:01 |
| kgunn | maybe i don't need to compile | 14:01 |
| kgunn | ....altho, it would be nice to know how | 14:01 |
| tjaalton | kgunn: freedreno should be available | 14:02 |
| juliank | OK, so it's also not binutils fault | 14:04 |
| xnox | sil2100, can't remember, but his usual timezone is central/central-west canada... | 14:05 |
| Sweet5hark1 | ricotz: whats up? | 14:07 |
| ricotz | Sweet5hark1, why is moving liblosessioninstalllo.so depending on ENABLE_PACKAGEKIT anyway? | 14:08 |
| ricotz | seems broken to do so when its building doesnt depend on it | 14:09 |
| ricotz | so better check with rene | 14:09 |
| Sweet5hark1 | ricotz: I think rene just wanted to kill liblosessionstalllo.so for debian anyway. Maybe he later did, but not at the point were we are based on. | 14:10 |
| Sweet5hark1 | ricotz: so -- its renes thing, we shouldnt bother. | 14:10 |
| ricotz | Sweet5hark1, better don't depend on packagekit | 14:10 |
| ricotz | aka dont pass --enable-packagekit | 14:10 |
| Sweet5hark1 | ricotz: nope, we want packagekit when we can and it isnt a dealbreaker if its missing. | 14:12 |
| ricotz | Sweet5hark1, note that I am just assuming since you didnt push your packaging changes | 14:12 |
| ricotz | Sweet5hark1, this will be a libreoffice dependency never used before on ubuntu | 14:13 |
| Sweet5hark1 | ricotz: not pushing yet what I havent at least test build, so if you dont want to waste your time dont read too much into what is happening in -staging. Staging is not final. | 14:14 |
| Sweet5hark1 | ricotz: we used the lib before and it only does dbus ... so? | 14:14 |
| ricotz | Sweet5hark1, you get my point and doing it so it plain confusing | 14:15 |
| ricotz | you are saying "--enable-packagekit" was passed before? | 14:15 |
| ricotz | I am saying the existence of this library is not depending on packagekit | 14:17 |
| ricotz | Sweet5hark1, btw you made me look since I am desperately waiting for those tarballs | 14:18 |
| ricotz | seems there is no such thing as --enable-packagekit anymore | 14:21 |
| ricotz | g2g | 14:21 |
| Sweet5hark1 | ricotz: yes, there is no --enable-packagekit -- so it doesnt change anything about the build. | 14:22 |
| Sweet5hark1 | ricotz: something to cleanup and sync with debian on yakkety+1, I guess. but as is no harm (except some confusion in ./debian/rules but hey ...) | 14:23 |
| ricotz | Sweet5hark1, passing invalid confflags might result in an autoconf error | 14:24 |
| Sweet5hark1 | ricotz: nothing is passed to configure | 14:25 |
| slangasek | sil2100: infinity is the one and yes he's out this week; what's the issue re: libc? | 14:32 |
| juliank | OK; I now did 3 runs of the APT amd64 build, all failed with the same error | 14:34 |
| juliank | I am unable to reproduce this, thoug | 14:34 |
| sil2100 | slangasek: I see a funny thing happening on yakkety armhf, possibly libc related - related to the mknod syscall | 14:37 |
| slangasek | sil2100: mknod seems an unlikely syscall to give problems... what's the context? | 14:38 |
| sil2100 | slangasek: not exactly with mknod itself - I don't know the internals too much, but there's different behavior between architectures it seems when trying to fetch the the mknod symbol through dlsym() | 14:38 |
| sil2100 | slangasek: on armhf it just fails to find mknod, on others it's all good | 14:38 |
| slangasek | sil2100: ah, let's see | 14:39 |
| sil2100 | I think looking for __xmknod instead wouldn't be a good idea | 14:39 |
| sil2100 | Anyway, I have a test-case that works fine on xenial-amd64 (and most probably on yakkety-amd64 as well since there are no problems with the click preload lib there) but fails on armhf | 14:40 |
| cjwatson | sil2100,slangasek: I ran into exactly that with click and there's a bileto ticket waiting for QA that switches to __xmknod | 14:40 |
| sil2100 | Couldn't find any obvious reasons for this, as just using the mknod syscall itself works | 14:40 |
| cjwatson | I can't explain why it worked beforehand, since there is AFAICS no mknod symbol in older libcs either | 14:41 |
| sil2100 | cjwatson: yeah, good question how it worked, there's an inline mknod wrapper around __xmknod | 14:41 |
| cjwatson | (I'm assuming it's inlined or something, but that doesn't explain why overriding it apparently worked; maybe it didn't and we just never noticed) | 14:41 |
| sil2100 | But I didn't know that was resolvable | 14:41 |
| cjwatson | sil2100: anyway, click was already using __xstat in a similar way and since click is in theory EOL I don't have a particular problem with switching it to __xmknod | 14:42 |
| sil2100 | Or that, but if it never worked then we would get the same issue as now | 14:42 |
| sil2100 | Oh, ok | 14:42 |
| cjwatson | sil2100: that's https://requests.ci-train.ubuntu.com/#/ticket/1878 | 14:42 |
| sil2100 | cjwatson: thanks! I was investigating this as our yakkety touch builds were failing because of this | 14:42 |
| cjwatson | from all the test suite crap I had to fix I think something has got stricter somewhere | 14:43 |
| cjwatson | but I can't really complain because click (especially its tests, but also that preload library) was doing a lot of very weird stuff | 14:43 |
| cjwatson | also the assertion that there are no problems with the click preload library on yakkety-amd64 is I'm afraid untrue | 14:44 |
| cjwatson | https://bugs.launchpad.net/ubuntu/+source/click/+bug/1615757 was reported from amd64 and is reproducible there | 14:44 |
| ubottu | Launchpad bug 1615757 in click (Ubuntu) "click install fails on 16.10, causing user install and autopkgtest failures" [High,In progress] | 14:44 |
| sil2100 | cjwatson: it seemed to be okayish when I last tried, since first I tried to reproduce out click install issues on my yakkety-amd64 chroot but there it just worked | 14:44 |
| cjwatson | well, I reproduced it in my yakkety-amd64 chroot and used that to fix i | 14:45 |
| cjwatson | t | 14:45 |
| sil2100 | While on the yakkety-armhf click installed was failing on the preload library dying when trying to fetch mknod | 14:45 |
| sil2100 | But, well, I might have missed something there | 14:45 |
| cjwatson | anyway, just needs QA to confirm I haven't broken anything obvious and then we can land that | 14:45 |
| sil2100 | slangasek: ok, no issue then, this seems like unexpected behavior that we shouldn't have relied on the first place, cjwatson's fix is good enough for this :) | 14:48 |
| juliank | So, the APT tagfile issue also happened sometimes on hurd-i386 @ debian | 14:49 |
| juliank | not that we ever managed to reproduce it there either | 14:49 |
| sil2100 | cjwatson: reviewed changes and approved as well | 14:49 |
| cjwatson | sil2100: my entirely unsupported theory is that dlsym was letting us get away with fetching internal unexported libc symbols, but I'm not really sure | 14:49 |
| cjwatson | ta | 14:50 |
| sil2100 | Possible, yes, I was even disassembling some mknod test-apps to see if the actual mknod behavior was changing but it was all the same, so probably dlsym got stricter | 14:51 |
| sil2100 | (like, if obviously it was inline in one and an external symbol in the other) | 14:51 |
| sil2100 | Anyway, good to see this in a silo ready already! | 14:52 |
| GhostLyrics | how can I determine whether I have a defect RAID controller, a possible kernel bug or a bug in the vendor's proprietary CLI if my online output is that the kernel could not allocate some buffer? | 14:52 |
| pkern | cjwatson: I'm looking for a sponsor for https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1604209 which is a broken backport in trusty. Approved by -backports but component restrictions don't let me upload it. :( | 14:53 |
| ubottu | Launchpad bug 1604209 in trusty-backports "apache2 in trusty-backports is vulnerable to CVE-2016-5387" [Undecided,New] | 14:53 |
| cjwatson | pkern: I'm not going to have time, sorry | 14:54 |
| pkern | cjwatson: Do you have any recourse of how I could escalate this? :/ | 14:55 |
| pkern | -sponsors is subscribed but that doesn't seem to help. | 14:55 |
| pkern | Security says we don't care, it's backports. | 14:55 |
| pkern | -backports says it's ok, go ahead. And I'm only a MOTU. | 14:55 |
| cjwatson | pkern: I don't, but should be plenty of other core-devs around on this channel who can help | 14:55 |
| juliank | Ah, that's probably the APT issue: Conditional jump or move depends on uninitialised value(s) | 14:56 |
| rbasak | pkern: it seems to me that ~ubuntu-backporters needs more (active) members :-/ | 15:05 |
| pkern | rbasak: They ack'ed it. So you think they'd also need to upload it? | 15:19 |
| pkern | rbasak: Why do we have component restrictions on backports in the first place? | 15:19 |
| rbasak | pkern: I'm not sure. This stuff predates me. | 15:21 |
| rbasak | pkern: I guess it's somewhere between development release uploads and SRUs in terms of the risk of breaking people, so it does make sense to limit it a little. | 15:22 |
| rbasak | I asked and I can spend a little time on helping this kind of thing through on Canonical Server Team time - given that we have people giving us patches, we should take them. | 15:23 |
| rbasak | So if it helps and I can join the backporters team on that limited basis, I'd be happy to help. | 15:23 |
| xnox | pkern, i think i can sponsor that, if i can remember the right way to do it. | 15:24 |
| xnox | however Laney you did upload apache2 backports last =) mind tossing https://launchpadlibrarian.net/275623430/apache2_2.4.10-1ubuntu1.1~ubuntu14.04.1_2.4.10-1ubuntu1.1~ubuntu14.04.2.debdiff there too? | 15:25 |
| Laney | TIL doesn't work for backports since only the backporters team uploads there really | 15:26 |
| Laney | Someone with more energy for it than me should propose scrapping the current system | 15:27 |
| rbasak | What should it be replaced with? | 15:28 |
| Laney | Dunno | 15:28 |
| Laney | Something where every developer can upload and some team reviews the queue, maybe. Like SRUs. | 15:28 |
| Laney | Or something where everyone can upload, like Debian's | 15:29 |
| Laney | Normally we would want to re-backport in this situation too | 15:33 |
| Laney | Rather than maintain a package in -backports | 15:34 |
| pkern | Laney: Thank you! | 16:11 |
| Laney | you're welcome | 16:11 |
| doko | jamespage: is ubuntu-openstack a team with a canonical affiliation? | 16:45 |
| slangasek | doko: are you asking because MIR , in which case http://reqorts.qa.ubuntu.com/reports/m-r-package-team-mapping.html#ubuntu-openstack ? | 17:28 |
| doko | slangasek: ahh, ok | 17:29 |
| pitti | PSA: taking down autopkgtest.ubuntu.com for maintenance and redeploying a new web UI | 18:58 |
| tumbleweed | will it have data that isn't a few days old? :) | 19:04 |
| tumbleweed | I've been finding it a bit frustrating when trying to get things through proposed, without access to recent test history | 19:05 |
| pitti | tumbleweed: yes, that's the point of it | 19:14 |
| pitti | tumbleweed: I spent two nightshifts completely rewriting the thing | 19:15 |
| pitti | tumbleweed: latency should now be ≤ 10 mins | 19:15 |
| pitti | I'll still look at optimizing the swift→ database upload | 19:15 |
| pitti | but there aren't a gazillion small files any more but a proper database, and pages are now generated on the fly instead of statically by cron | 19:15 |
| pitti | infinity: ^ FYI | 19:15 |
| pitti | plus, the whole thing shrank to 10 or 5 % of the code :) | 19:16 |
| pitti | apw: ^ will break your lsadt thingy, as running.json got split and currently isn't available; on the list to fix | 19:17 |
| slangasek | pitti: woo currency | 19:18 |
| pitti | slangasek: yeah, the latency got annoying and it kept running out of inodes despite adding an extra cinder volume | 19:19 |
| pitti | now it's just a single 60 MB sqlite db which is lightning fast to query \o/ | 19:19 |
| doko | is lp just slow for me? | 19:19 |
| slangasek | inodes> haha | 19:20 |
| pitti | slangasek: and the whole thing is outright absurdly small now: https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/tree/webcontrol/browse.cgi | 19:20 |
| pitti | doko: has been slow for a few days for me too | 19:20 |
| pitti | loading/updating bugs, publisher, etc. | 19:20 |
| pitti | well, https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/tree/webcontrol/templates too, but still small | 19:21 |
| apw | pitti, bah ... ok | 19:23 |
| pitti | apw: http://autopkgtest.ubuntu.com/running.json is back, but now only contains the actually running tests | 19:28 |
| apw | pitti, running.shtml seems to be bust | 19:30 |
| pitti | apw: queue information is now not polled every 10 s (as that's quite taxing on the amqp server), but queried on demand by the running html page; I'll build you an URL which generates the queue data in JSON format on demand | 19:30 |
| pitti | apw: yep, working on it | 19:30 |
| apw | pitti, sounds good, you know me, just let me know what all it looks like after | 19:30 |
| pitti | http://autopkgtest.ubuntu.com/browse.cgi/running -> should be back | 19:31 |
| pitti | there are still some warts obviously, but the most important functionality is back; I'll announce to u-devel@ | 19:31 |
| sarnold | pitti: wow that sqlite version feels a lot easier to think about than the older swift version (sorry :) | 19:38 |
| pitti | sarnold: it's still swift; that's awesome and won't go away | 19:38 |
| pitti | sarnold: but this is too slow for using directly, the result metadata needs to be downloaded | 19:39 |
| jbicha | pitti: do the package pages have to be regenerated or something? for instance https://autopkgtest.ubuntu.com/browse.cgi/packages/gjs is out of date | 19:40 |
| pitti | jbicha: looking at that ATM | 19:40 |
| jbicha | oh it has yakkety now, a moment ago it was only trusty | 19:40 |
| pitti | (of course this didn't happen on the previous test instance..) | 19:41 |
| jbicha | I think I just need to be more patient | 19:41 |
| pitti | I think it's a problem with locking the DB (for swift updates) | 19:41 |
| pitti | then the reading part doesn't get the results | 19:41 |
| pitti | oops, wait, what | 19:42 |
| pitti | jbicha: ok, now everything is back | 19:43 |
| jbicha | yes it looks better now, thanks | 19:44 |
| semiosis | someone marked bug 1605795 as a duplicate, but it is an SRU bug to backport a fix from yakkety to xenial. | 19:48 |
| ubottu | bug 1565985 in cloud-images "duplicate for #1605795 vagrant vb ubuntu/xenial64 cannot mount synced folders" [Undecided,In progress] https://launchpad.net/bugs/1565985 | 19:48 |
| semiosis | should it be marked a duplicate of the underlying bug reporting the problem? | 19:49 |
| semiosis | wanted to check with the experts here before removing the duplicate marker | 19:49 |
| bdmurray | pitti: The pending SRU links to autopkgtest pages like http://autopkgtest.ubuntu.com/browse.cgi/packages/u/ubuntu-release-upgrader/trusty/i386/ notice the "/u/" and ending "/" after the arch. Does that report need to be updated? | 21:31 |
| tumbleweed | pitti: \o/ :) | 21:32 |
| bdmurray | pitti: Also the ubuntu-release-upgrader tests for T and Y started failed around 2016-08-25. X hasn't run since then. | 21:38 |
| infinity | pitti: \o/ | 22:04 |
| === salem_ is now known as _salem | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!