=== tzero_ is now known as tzero === MasterPieceF is now known as MasterPiece === pitti` is now known as pitti [04:43] Good morning [04:44] Howdy. [04:46] hey Unit193, how are you? I see you eagerly backport systemd :) [04:47] pitti: Heh, yeah. Started doing that in trusty, did a couple Debian merges, not fun with systemd. :P [04:48] Unit193: tell me about it :) [04:48] Though, looks as if the new cryptsetup added much better support for it! [04:48] Unit193: but with our current workflow (shared git with Debian, rebasing ubuntu on top of master/experimental) it actually works reasonably well [04:49] Awesome! Saw you got added as uploader, congrats. Great to see you work "upstream" too. :) [04:52] Unit193: so with 172-2ubuntu1 in vivid you should now have a reasonably current version? [04:52] (it includes the v217-stable patches, too) [04:54] pitti: Yep! Just rebooted into it (only slight hickups.) [04:58] Unit193: I'm not aware of any regressions, so bug reports appreciated [05:20] pitti: Heh, only upon reboot the clock was off a few hours. [06:54] zul: python-taskflow is still failing its tests, so it doesn't propagate [08:12] good morning [08:12] good morning! [08:22] dpm: good morning [08:22] dpm: can you please set up http://people.canonical.com/~dpm/data/ubuntu-l10n/ for vivid? [08:22] dpm: I'm building the first set of vivid packages now, but I had to fall back to utopic there ^ [08:23] pitti, morning. Ok, let me file the RT [08:40] hi dholbach :) [08:42] hi LocutusOfBorg1 [09:45] slangasek, hey, I can trigger bug #1372193 by updating systemd (like if I dpkg -i the old version and use update-manager I seem to consistently hit it), let me know if you need debug info [09:45] bug 1372193 in pam (Ubuntu) "package libpam-systemd:amd64 208-8ubuntu4 failed to install/upgrade: subprocess installed post-installation script returned error exit status 128 in pam-auth-update" [Undecided,Confirmed] https://launchpad.net/bugs/1372193 [10:05] seb128, dpm: ubuntu vivid langpacks uploaded and updates cron'ed [10:05] pitti, great! [10:08] thanks pitti === greyback__ is now known as greyback === _salem is now known as salem_ === MacSlow is now known as MacSlow|lunch === doko__ is now known as doko [12:12] cjwatson: infinity: was it intentional for 14.04 core tarballs to stop enabling i386 foreign arch? [12:14] I don't remember that coming up [12:14] Of course core is meant to be minimal and it's trivial to enable. [12:15] cjwatson: it looks like previous cores used to have it, and e.g. it affects docker images - as since 14.04 they stopped having i386 support out of the box. Maybe it should be just enabled on the docker side, but I wanted to check first that this not an accidental regression [12:15] (e.g. dpkg postinst refactoring, moving builds to launchpad, et.al) [12:16] but rather intentional choice / change. [12:16] Build location has nothing to do with it. [12:16] We might have decided we didn't need to carry the dpkg delta any more because apt-setup handles it in most cases, I suppose. [12:16] Although it seems to be still there in vivid. [12:17] Anyway, I think it's fine to say that you need to do "dpkg --add-architecture i386" before "apt-get update" if you want multiarch, and you probably wanted to run "apt-get update" anyway. === Ursinha is now known as Ursinha-brb === Ursinha-brb is now known as Ursinha [12:30] pitti: added https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1337200 as a duplicate of the other one because this bug is hardware specific [12:30] Launchpad bug 1337200 in upower (Ubuntu RTM) "High CPU due to excessive device changed signals from upower" [High,Confirmed] [12:30] and the other project is to cover basically hardware specific bugs [12:30] rsalveti: ok, then let's track those as two independent bugs then; making a public bug a dupe of a private one is rather unfriendly [12:31] pitti: I agree it's unfriendly, but having 2 bugs opened at the same time is not ideal either =\ [12:32] rsalveti: I still don't understand this then; #1337200 covers teh general case for all hardware, why would a bug for specific platform now become the master bug? [12:32] well, *shrug*, I don't care enough to fight over this [12:32] pitti: because the problem is the kernel sending way too much uevents related with power [12:32] which makes upower to be quite a bit verbose, and dbus as well [12:33] rsalveti: that's then not really a duplicate [12:33] rsalveti: #1337200 is about queueing up d-bus signals while a process is sleeping, and then flushing them on wakeup [12:33] rsalveti: if on that other platform the kernel is sending too many events, that's a separate cause [12:34] pitti: just because the comments from ken vandine are all covering the issue described by the other bug [12:35] but yeah, let's keep both of them opened then [12:35] thanks === MacSlow|lunch is now known as MacSlow === Guest74903 is now known as Pici [15:03] pitti: the new upload of systemd 217 works fine here. I did not encounter any problems so far :) [15:03] pitti: thanks [15:03] brainwash: cheers [15:46] xnox: Edubuntu actually ships with two DEs, just saying :) [15:47] stgraber: shh, i knew that when typing it out. Dito e.g. mythbuntu ships in a way two DEs - boot to xfce & boot to mythtv-frontend. [15:48] :) === roadmr is now known as roadmr_afk [15:58] xnox: no, mythbuntu just has xfce start mythfrontend === caribou_ is now known as caribou === roadmr_afk is now known as roadmr [16:49] apw: do you happen to know how in-kernel firmware loading works these days, or who to talk about it? [16:49] pitti, i know an amount, what do you need [16:49] apw: latest udev removed the userspace helper for this, but it seems on seb128's laptop the kernel can't load the iwlwifi firmware (works on mine) [16:50] bug 1398458 [16:50] bug 1398458 in systemd (Ubuntu) "kernel fails to load iwlwifi firmware" [Undecided,New] https://launchpad.net/bugs/1398458 [16:50] apw: i. e. my first question would be, is there some way to squeeze some more verbosity out of the kernel? right now it just says [16:50] [ 6.586593] iwlwifi 0000:02:00.0: Direct firmware load failed with error -2 [16:50] laptop is a latitude e6410 i5 [16:50] [ 6.586598] iwlwifi 0000:02:00.0: Falling back to user helper [16:51] apw: I suggested to boot with "debug log_buf_len=1M" as a first step, but I wonder if there's something more specific that we should try? [16:51] apw: i. e. I can certainly put back the userspace helper, but I thought the intention was that the kernel does fw loading by iself now since 3.7 [16:52] apw: and it seems to work just perfectly on my centrino Advanced-N 6205 (almost the same model as seb128's) [16:52] pitti, well, it may depend on which kernel he has, as i assume the direct loader cannot handle the firmware in non-standard places [16:52] seb128, are you using an lts backport kernel perhaps [16:52] apw: I assume bog standard vivid with the distro kernel, much like I have [16:53] pitti: http://web.archiveorange.com/archive/v/wmeLD6rhIrHWG2dyJEUG looks like its because iwlwifi tries to load 3 different firmwares since it supports it, but -4 is the only released one [16:53] except seb128 is using i386, I'm amd64 [16:53] apw, no, vivid with 3.16.0-26-generic on i386 [16:53] seb128, the fimware it fails to load, do you know where it is on disk ? [16:54] apw, no, but I only have 1 partition [16:54] no separate /usr or anything like that [16:54] seb128: ah thanks, that looks very similar [16:54] apw: how can I tell which file it loaded on my system? [16:54] [ 2.898239] iwlwifi 0000:03:00.0: loaded firmware version 18.168.6.1 op_mode iwldvm [16:54] apw: ^ that's not saying much? [16:55] /sys/class/firmware/ only has a single "timeout" file here [16:56] yours is 6000g2a [16:56] going by http://wireless.kernel.org/en/users/Drivers/iwlwifi [16:57] iwlwifi-6000g2a-6.ucode exists, it tries to load the -6 abi then -5 abi then -4 abi and -4 is the only one released for the 6200/6300 [16:57] well, the firmware is obviously somewhere, as udev 215 can load it with the userspace helper [16:58] pitti, seb128, so that error is saying ENOENT, that the file was not found anywhere [16:58] add_uevent_var(env, "FIRMWARE=%s", fw_priv->buf->fw_id) [16:58] it uses that as the filename, so seb128 can you see that in your udev logs anywhere? [16:59] E: FIRMWARE=iwlwifi-6000-5.ucode [16:59] apw: ^ [16:59] pitti, was that yours or his [17:00] apw: his [17:00] apw: I can't see it in my udev db, as the fw loading happens very early at boot, so it's not anywhere [17:00] /lib/firmware/iwlwifi-6000-4.ucode [17:00] that's what we ship in linux-firmware [17:01] so it seems the udev userspace helper is trying various fallbacks, while the in-kernel loader doesn't? [17:01] cirtainly the kernel is correctly saying it cannot find that as it is not on disk [17:01] quite what udev thinks it is doing loading somethign completely different, is suspcious at best [17:01] seb128: wait, does it eventually initialize? [17:02] seb128: i. e. if the kernel doesn't find that after 60 seconds (/sys/class/firmware/timeout is 60 here), does it try another file name? [17:02] seb128: that would correspond with "Need to wait 2 minutes before wireless connects" on the suse bug [17:03] normally we step backwards through the versions in the dirver [17:03] apw: modinfo iwlwifi shows various "firmware:" bits, in particular iwlwifi-6000-4.ucode [17:03] though i don't see why it would timeout either, as the ENOENT is a hard failure [17:03] apw: that's what the udev loader uses [17:03] apw: interestingly, modinfo iwlwifi does *not* show -5 [17:03] apw: yeah [17:04] apw: so I'm a bit puzzled where the -5 comes from, if the module advertises -4 only [17:05] apw: anyway, I suppose in the short term I need to put back the udev userspace loader, but I suppose at some point the kernel shoudl be able to load by itself? [17:06] apw: so we need to figure out where the 6000-5 comes from; i. e. in-kernel loader loads something different than what the module advertises through "firmware:" [17:06] pitti, sorry, was away a few minutes [17:06] pitti, it eventually works, because after boot if I turn network off and on using nm-applet or the laptop switch it manages to connect [17:06] it just don't do it or boot or not by itself if I wait [17:08] seb128: interesting; after you do that, can you attach dmesg again? somethign needs to load that firmware after all, so it seems the kernel can find it eventually [17:08] pitti, so the minimum firmware U will accept for that device is -5 according to the dirver [17:09] pitti, that should be in my syslog from previous boots right? [17:09] seb128: yeah, I guess so; grep for "firmware"? [17:09] pitti, Dec 2 11:37:08 localhost kernel: [ 127.133185] iwlwifi 0000:02:00.0: loaded firmware version 9.221.4.1 build 25532 op_mode iwldvm [17:09] apw: and that's 6000, not 6000g2a? [17:10] I think [17:10] yep [17:10] pitti, and it iterates through the firmare versions via the firmware ABI highest accepted to lowest [17:12] seb128: It would be a real mystery if manually enabling wifi would magically load the firmware; it rather seems the firmware gets loaded automatically, but NM doesn't notice this, so you can manually enable only after that happened? [17:12] pitti, you mean "manually enable"? [17:12] seb128: can you reboot, keep the network as-is, "sudo dmesg -c | grep firmware" [17:12] if I don't turn network off/on, nm-applet doesn't list any aps [17:13] pitti, sure [17:13] seb128: then wait for two minutes, and "dmesg | grep firmw" again? I strongly suspect this will turn up eventually by itself [17:13] seb128: yes, I suspect NM doesn't "see" when the fw gets loaded and the card becomes ready [17:13] k [17:13] apw: so we mostly need to update linux-firmware to have -5? [17:13] let me try, back in a few minutes [17:14] apw: I still wonder why modinfo iwlwifi says -4 then [17:14] if it wants >= -5 [17:14] pitti, maybe, though what is being loaded by the usermode helper, as the versions which are valid are not there [17:14] pitti, well frankly it cannot be accurate, as the versions acceptable per chipset differ [17:14] but presumably the modinfo is wrong at best [17:15] hm, the latest firmware on http://wireless.kernel.org/en/users/Drivers/iwlwifi also only has 6000-4 [17:17] apw: "loaded firmware version 9.221.4.1" (on seb128's machine) correlates with the 6200 on http://wireless.kernel.org/en/users/Drivers/iwlwifi, and that has 6000-4 [17:17] pitti, you said you got rid of the usermode helper, but the kernel still calls it right ? [17:17] apw: yes, if it can't load it by itself [17:17] and if you have removed it, that will timeout [17:17] CONFIG_FW_LOADER=y [17:17] CONFIG_FW_LOADER_USER_HELPER=y [17:17] as nothing is responding [17:18] apw: oh! [17:18] apw: so you figure it goes like this: [17:18] - try -5 [17:18] - in-kernel loader: ENOENT [17:18] - try userspace helper [17:18] - time out [17:18] - try -4 [17:18] - in-kernel loader: success [17:18] so ... i think that that means, we try ... yes that [17:18] now, that makes perfect sense [17:18] apw: if seb128 comes back and confirm that the fw gets loaded automatically after 2 mins or so, we solved it [17:19] apw: so that means we need to disable CONFIG_FW_LOADER_USER_HELPER=y first, and then disable the udev helper [17:19] pitti, ok, I was wrong [17:19] pitti, and yes that is what the code is doing, iwlwifi is looking -5 -4 -3 stylee, and then each is tries direct load, usermode, iterate [17:19] pitti, the firwmware loads after 126 seconds [17:19] and nm sees it, connects [17:19] seb128: it loads automatically? (pleeease say that) [17:19] pitti, _or_ you make the firmware loader in userspace a stub we can turn off [17:19] yay! [17:20] pitti, I just never waiting a full 120 seconds [17:20] waited [17:20] it feels ages :p [17:20] seb128: then we completely solved the mystery [17:20] pitti, make it report failed for the load [17:20] apw: which always fails with an error immediately? sure, taht works too [17:20] then we can make it something "you and i" can turn on to test etc until we are happy the kernel one is working [17:20] pitti, why does it take so long? [17:20] apw: I guess eventually we shoudl still disable CONFIG_FW_LOADER_USER_HELPER, but at least that removes the lockstep [17:21] apw: many thanks for your help! [17:21] pitti, right, we can test, then default it off in userspace for a bit [17:21] then turn it off in the kernel, and be happy [17:22] pitti, as in some sense we want the helper there and available and _on_ in userspace in case someone has a non-standard kernel [17:23] seb128, apw: I followed up to the bug with the explanation [17:24] apw: right, but even wit the stub we don't support kernels without CONFIG_FW_LOADER=y [17:24] seb128: (that also explains the two minutse) [17:24] pitti, reading [17:24] pitti, thanks a lot for looking at the issue! [17:25] seb128: I'll work on a stub now, and will ask you to test it [17:26] pitti, ok, I'm happy to do testing ;-) [17:29] seb128: can you create an /etc/udev/rules.d/50-firmware.rules with [17:29] SUBSYSTEM=="firmware", ACTION=="add", RUN="/bin/false" [17:29] seb128: then reboot, and see whether that fixes it? [17:30] seb128: there's still some tweaking to be done (I think we should put that into initramfs too), but for a first test that should do [17:31] pitti: just curious (while seb is testing) what is the communication protocol? There is no way for the kernel to detect there is no available helper? [17:32] didrocks: yeah, I'm wondering about that [17:32] apw: ^ do you know what the kernel expects as a response? in particular for a failure? [17:33] not sure if it notices that the uevent was processed, that would be magic [17:34] oh, I think the helper needs to write -1 into /loading [17:35] pitti, there is a loading, which you shove a 0 in to say you are loading, a 1 in to say you did it ok, -1 to say it broke [17:36] apw: that would be e. g. /sys/devices/pci0000:00/0000:00:1c.1/0000:02:00.0/net/wlan0/loading for seb128's case? [17:36] pitti, that files doesn't work (e.g still the 2 minutes delay) and it feels like it made boot slower [17:36] seb128: yeah, we just figured that out [17:36] hmmm, isn't a firmware thing somewhere else like /sys/class/firmware/ [17:36] but the boot slower might be a wrong impression [17:36] what does the udev rule use [17:37] - strscpyl(loadpath, sizeof(loadpath), udev_device_get_syspath(dev), "/loading", NULL); [17:37] +E: DEVPATH=/devices/pci0000:00/0000:00:1c.1/0000:02:00.0/firmware/iwlwifi-6000-5.ucode [17:37] so probably that plus /loading === salem_ is now known as _salem === _salem is now known as salem_ [17:39] pitti, can't we just read the loader? is a c prog right? === salem_ is now known as _salem [17:39] apw: yes, that 's the line above (with strscpyl) [17:39] seb128: can you try this: [17:40] SUBSYSTEM=="firmware", ACTION=="add", ATTR{loading}="-1" [17:40] that looks like that sort of thing [17:42] apw: yeah, that would be nice and efficient, and avoid calling out to shell or building a dummy program [17:43] pitti, that one works :-) [17:43] ! [17:43] sweet! [17:43] * pitti ^5s seb128 and apw [17:43] * seb128 ^5s pitti back [17:43] ok great :) [17:44] pitti, what was the bug# for that [17:44] seb128: ok, I'll prettify this (including initramfs) [17:44] hey, you could just include that rule from ubuntu touch, we use it as default there ;) [17:44] convergence !! [17:44] apw: bug 1398458, I kept track of the discussion there [17:44] bug 1398458 in systemd (Ubuntu) "kernel fails to load iwlwifi firmware - disable CONFIG_FW_LOADER_USER_HELPER" [Medium,In progress] https://launchpad.net/bugs/1398458 [17:44] ogra_: and you only tell me now, after an hour of debugging :) [17:44] pitti, i didnt see the conversation til now [17:44] apw: so we can use that to track the disabling of that kernel config, in the meantime I'll add that rule [17:45] ogra_: (see the smiley) [17:45] * ogra_ is wrangling with a broken heating since last night ... i'm afk on and off [17:45] ;) [17:45] ogra_: quick, write an udev rule for it! [17:45] haha [17:45] that will surelyy fix my pumps [17:45] SUBSYSTEM=="heating", ATTR{state}=="autodestruct}, ATTR{power}="0" === _salem is now known as salem_ === salem_ is now known as _salem === _salem is now known as salem_ [18:42] seb128: 217-3ubuntu1 uploaded, with that fix [18:44] pitti, \o/ [18:44] pitti, I can delete the file you asked me to add then? [18:47] seb128: yes, you should (unless you need to reboot again until it hits vivid) [18:47] pitti, no, I'm fine, deleting it, thanks [18:47] (worth case I need to wait for the timeouts) [20:30] Could we re-add the libusb-1.0 package? libusbx has been RMed in debian, and is outdated in ubuntu === greyback_ is now known as greyback === salem_ is now known as _salem [20:40] libusb and libusbx were merged [20:40] (upstream) [20:40] cjwatson, looks like you did the RM, can you take a look? [20:54] Noskcaj: Not at this time; send me mail? [20:54] ok [20:55] Noskcaj: also, while we're both at least sort of here: [20:55] 2014-10-30.log:10:48 Noskcaj: you uploaded a new upstream release of gnuhealth a while back, which is now causing a bunch of other stuff to be stuck in -proposed due to strict dependencies on tryton-*; since then, gnuhealth has been removed from Debian. are you actually interested in maintaining this package permanently in Ubuntu or can I remove it from Ubuntu to match Debian? [20:57] I have no use for the package or reason to maintain it. I just did the new release so utopic had a fuctional version [20:58] Noskcaj: righto, I'll remove that then, thanks [20:58] ok [20:58] and yeah, libusb* has been nagging at me to sort out for a while ... [20:58] will have a look tomorrow morning if reminded by mail [22:05] 6 Please buy this game http://www.desura.com/games/WipeGround-Wpx = [22:14] doko, you around? I wanted to ask about python:any in build-deps [22:49] mterry, yep? [22:49] doko, I think I figured it out, I was just curious about the practice of using python:any in build-deps, but I guess it's for crossbuilding, eh? [22:53] mterry, yes, exactly. that's the only reason. have a look at zope.interface === beuno_ is now known as beuno [23:15] Hey [23:15] Can you help on this bug #1355698 [23:15] bug 1355698 in elementary OS "Unable to boot via UEFI into installed freya system [$500]" [High,Confirmed] https://launchpad.net/bugs/1355698 [23:16] somehow there are big issues with uefi [23:24] Shouldn't you be asking the elementary devs? [23:25] I was about to say the same thing [23:26] berz3rk: that's something you should bring up with the Elementary OS devs, not here, I believe. [23:26] well yes