[04:43] <pitti> Good morning
[04:44] <Unit193> Howdy.
[04:46] <pitti> hey Unit193, how are you? I see you eagerly backport systemd :)
[04:47] <Unit193> pitti: Heh, yeah.  Started doing that in trusty, did a couple Debian merges, not fun with systemd. :P
[04:48] <pitti> Unit193: tell me about it :)
[04:48] <Unit193> Though, looks as if the new cryptsetup added much better support for it!
[04:48] <pitti> Unit193: but with our current workflow (shared git with Debian, rebasing ubuntu on top of master/experimental) it actually works reasonably well
[04:49] <Unit193> Awesome!  Saw you got added as uploader, congrats.  Great to see you work "upstream" too. :)
[04:52] <pitti> Unit193: so with 172-2ubuntu1 in vivid you should now have a reasonably current version?
[04:52] <pitti> (it includes the v217-stable patches, too)
[04:54] <Unit193> pitti: Yep!  Just rebooted into it (only slight hickups.)
[04:58] <pitti> Unit193: I'm not aware of any regressions, so bug reports appreciated
[05:20] <Unit193> pitti: Heh, only upon reboot the clock was off a few hours.
[06:54] <pitti> zul: python-taskflow is still failing its tests, so it doesn't propagate
[08:12] <dholbach> good morning
[08:12] <highvoltage> good morning!
[08:22] <pitti> dpm: good morning
[08:22] <pitti> dpm: can you please set up http://people.canonical.com/~dpm/data/ubuntu-l10n/ for vivid?
[08:22] <pitti> dpm: I'm building the first set of vivid packages now, but I had to fall back to utopic there ^
[08:23] <dpm> pitti, morning. Ok, let me file the RT
[08:40] <LocutusOfBorg1> hi dholbach :)
[08:42] <dholbach> hi LocutusOfBorg1
[09:45] <seb128> 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
[10:05] <pitti> seb128, dpm: ubuntu vivid langpacks uploaded and updates cron'ed
[10:05] <seb128> pitti, great!
[10:08] <dpm> thanks pitti
[12:12] <xnox> cjwatson: infinity: was it intentional for 14.04 core tarballs to stop enabling i386 foreign arch?
[12:14] <cjwatson> I don't remember that coming up
[12:14] <cjwatson> Of course core is meant to be minimal and it's trivial to enable.
[12:15] <xnox> 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] <xnox> (e.g. dpkg postinst refactoring, moving builds to launchpad, et.al)
[12:16] <xnox> but rather intentional choice / change.
[12:16] <cjwatson> Build location has nothing to do with it.
[12:16] <cjwatson> 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] <cjwatson> Although it seems to be still there in vivid.
[12:17] <cjwatson> 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.
[12:30] <rsalveti> 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] <rsalveti> and the other project is to cover basically hardware specific bugs
[12:30] <pitti> 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] <rsalveti> pitti: I agree it's unfriendly, but having 2 bugs opened at the same time is not ideal either =\
[12:32] <pitti> 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] <pitti> well, *shrug*, I don't care enough to fight over this
[12:32] <rsalveti> pitti: because the problem is the kernel sending way too much uevents related with power
[12:32] <rsalveti> which makes upower to be quite a bit verbose, and dbus as well
[12:33] <pitti> rsalveti: that's then not really a duplicate
[12:33] <pitti> rsalveti: #1337200 is about queueing up d-bus signals while a process is sleeping, and then flushing them on wakeup
[12:33] <pitti> rsalveti: if on that other platform the kernel is sending too many events, that's a separate cause
[12:34] <rsalveti> pitti: just because the comments from ken vandine are all covering the issue described by the other bug
[12:35] <rsalveti> but yeah, let's keep both of them opened then
[12:35] <rsalveti> thanks
[15:03] <brainwash> pitti: the new upload of systemd 217 works fine here. I did not encounter any problems so far :)
[15:03] <brainwash> pitti: thanks
[15:03] <pitti> brainwash: cheers
[15:46] <stgraber> xnox: Edubuntu actually ships with two DEs, just saying :)
[15:47] <xnox> 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] <stgraber> :)
[15:58] <tgm4883> xnox: no, mythbuntu just has xfce start mythfrontend
[16:49] <pitti> apw: do you happen to know how in-kernel firmware loading works these days, or who to talk about it?
[16:49] <apw> pitti, i know an amount, what do you need
[16:49] <pitti> 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] <pitti> bug 1398458
[16:50] <pitti> 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] <pitti> [ 6.586593] iwlwifi 0000:02:00.0: Direct firmware load failed with error -2
[16:50] <seb128> laptop is a latitude e6410 i5
[16:50] <pitti> [ 6.586598] iwlwifi 0000:02:00.0: Falling back to user helper
[16:51] <pitti> 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] <pitti> 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] <pitti> apw: and it seems to work just perfectly on my centrino Advanced-N 6205 (almost the same model as seb128's)
[16:52] <apw> 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] <apw> seb128, are you using an lts backport kernel perhaps
[16:52] <pitti> apw: I assume bog standard vivid with the distro kernel, much like I have
[16:53] <Sarvatt> 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] <pitti> except seb128 is using i386, I'm amd64
[16:53] <seb128> apw, no, vivid with 3.16.0-26-generic on i386
[16:53] <apw> seb128, the fimware it fails to load, do you know where it is on disk ?
[16:54] <seb128> apw, no, but I only have 1 partition
[16:54] <seb128> no separate /usr or anything like that
[16:54] <pitti> seb128: ah thanks, that looks very similar
[16:54] <pitti> apw: how can I tell which file it loaded on my system?
[16:54] <pitti> [    2.898239] iwlwifi 0000:03:00.0: loaded firmware version 18.168.6.1 op_mode iwldvm
[16:54] <pitti> apw: ^ that's not saying much?
[16:55] <pitti> /sys/class/firmware/ only has a single "timeout" file here
[16:56] <Sarvatt> yours is 6000g2a
[16:56] <Sarvatt> going by http://wireless.kernel.org/en/users/Drivers/iwlwifi
[16:57] <Sarvatt> 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] <pitti> well, the firmware is obviously somewhere, as udev 215 can load it with the userspace helper
[16:58] <apw> pitti, seb128, so that error is saying ENOENT, that the file was not found anywhere
[16:58] <apw> add_uevent_var(env, "FIRMWARE=%s", fw_priv->buf->fw_id)
[16:58] <apw> it uses that as the filename, so seb128 can you see that in your udev logs anywhere?
[16:59] <pitti> E: FIRMWARE=iwlwifi-6000-5.ucode
[16:59] <pitti> apw: ^
[16:59] <apw> pitti, was that yours or his
[17:00] <pitti> apw: his
[17:00] <pitti> 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] <pitti> /lib/firmware/iwlwifi-6000-4.ucode
[17:00] <pitti> that's what we ship in linux-firmware
[17:01] <pitti> so it seems the udev userspace helper is trying various fallbacks, while the in-kernel loader doesn't?
[17:01] <apw> cirtainly the kernel is correctly saying it cannot find that as it is not on disk
[17:01] <apw>  quite what udev thinks it is doing loading somethign completely different, is suspcious at best
[17:01] <pitti> seb128: wait, does it eventually initialize?
[17:02] <pitti> 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] <pitti> seb128: that would correspond with "Need to wait 2 minutes before wireless connects" on the suse bug
[17:03] <apw> normally we step backwards through the versions in the dirver
[17:03] <pitti> apw: modinfo iwlwifi shows various "firmware:" bits, in particular iwlwifi-6000-4.ucode
[17:03] <apw> though i don't see why it would timeout either, as the ENOENT is a hard failure
[17:03] <pitti> apw: that's what the udev loader uses
[17:03] <pitti> apw: interestingly, modinfo iwlwifi does *not* show -5
[17:03] <pitti> apw: yeah
[17:04] <pitti> apw: so I'm a bit puzzled where the -5 comes from, if the module advertises -4 only
[17:05] <pitti> 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] <pitti> 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] <seb128> pitti, sorry, was away a few minutes
[17:06] <seb128> 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] <seb128> it just don't do it or boot or not by itself if I wait
[17:08] <pitti> 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] <apw> pitti, so the minimum firmware U will accept for that device is -5 according to the dirver
[17:09] <seb128> pitti, that should be in my syslog from previous boots right?
[17:09] <pitti> seb128: yeah, I guess so; grep for "firmware"?
[17:09] <seb128> 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] <pitti> apw: and that's 6000, not 6000g2a?
[17:10] <seb128> I think
[17:10] <pitti> yep
[17:10] <apw> pitti, and it iterates through the firmare versions via the firmware ABI highest accepted to lowest
[17:12] <pitti> 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] <seb128> pitti, you mean "manually enable"?
[17:12] <pitti> seb128: can you reboot, keep the network as-is, "sudo dmesg -c | grep firmware"
[17:12] <seb128> if I don't turn network off/on, nm-applet doesn't list any aps
[17:13] <seb128> pitti, sure
[17:13] <pitti> seb128: then wait for two minutes, and "dmesg | grep firmw" again? I strongly suspect this will turn up eventually by itself
[17:13] <pitti> seb128: yes, I suspect NM doesn't "see" when the fw gets loaded and the card becomes ready
[17:13] <seb128> k
[17:13] <pitti> apw: so we mostly need to update linux-firmware to have -5?
[17:13] <seb128> let me try, back in a few minutes
[17:14] <pitti> apw: I still wonder why modinfo iwlwifi says -4 then
[17:14] <pitti> if it wants >= -5
[17:14] <apw> pitti, maybe, though what is being loaded by the usermode helper, as the versions which are valid are not there
[17:14] <apw> pitti, well frankly it cannot be accurate, as the versions acceptable per chipset differ
[17:14] <apw> but presumably the modinfo is wrong at best
[17:15] <pitti> hm, the latest firmware on http://wireless.kernel.org/en/users/Drivers/iwlwifi also only has 6000-4
[17:17] <pitti> 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] <apw> pitti, you said you got rid of the usermode helper, but the kernel still calls it right ?
[17:17] <pitti> apw: yes, if it can't load it by itself
[17:17] <apw> and if you have removed it, that will timeout
[17:17] <pitti> CONFIG_FW_LOADER=y
[17:17] <pitti> CONFIG_FW_LOADER_USER_HELPER=y
[17:17] <apw> as nothing is responding
[17:18] <pitti> apw: oh!
[17:18] <pitti> apw: so you figure it goes like this:
[17:18] <pitti> - try -5
[17:18] <pitti> - in-kernel loader: ENOENT
[17:18] <pitti> - try userspace helper
[17:18] <pitti> - time out
[17:18] <pitti> - try -4
[17:18] <pitti> - in-kernel loader: success
[17:18] <apw> so ... i think that that means, we try  ... yes that
[17:18] <pitti> now, that makes perfect sense
[17:18] <pitti> apw: if seb128 comes back and confirm that the fw gets loaded automatically after 2 mins or so, we solved it
[17:19] <pitti> apw: so that means we need to disable CONFIG_FW_LOADER_USER_HELPER=y first, and then disable the udev helper
[17:19] <seb128> pitti, ok, I was wrong
[17:19] <apw> 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] <seb128> pitti, the firwmware loads after 126 seconds
[17:19] <seb128> and nm sees it, connects
[17:19] <pitti> seb128: it loads automatically? (pleeease say that)
[17:19] <apw> pitti, _or_ you make the firmware loader in userspace a stub we can turn off
[17:19] <pitti> yay!
[17:20] <seb128> pitti, I just never waiting a full 120 seconds
[17:20] <seb128> waited
[17:20] <seb128> it feels ages :p
[17:20] <pitti> seb128: then we completely solved the mystery
[17:20] <apw> pitti, make it report failed for the load
[17:20] <pitti> apw: which always fails with an error immediately? sure, taht works too
[17:20] <apw> 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] <seb128> pitti, why does it take so long?
[17:20] <pitti> apw: I guess eventually we shoudl still disable CONFIG_FW_LOADER_USER_HELPER, but at least that removes the lockstep
[17:21] <pitti> apw: many thanks for your help!
[17:21] <apw> pitti, right, we can test, then default it off in userspace for a bit
[17:21] <apw> then turn it off in the kernel, and be happy
[17:22] <apw> 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] <pitti> seb128, apw: I followed up to the bug with the explanation
[17:24] <pitti> apw: right, but even wit the stub we don't support kernels without CONFIG_FW_LOADER=y
[17:24] <pitti> seb128: (that also explains the two minutse)
[17:24] <seb128> pitti, reading
[17:24] <seb128> pitti, thanks a lot for looking at the issue!
[17:25] <pitti> seb128: I'll work on a stub now, and will ask you to test it
[17:26] <seb128> pitti, ok, I'm happy to do testing ;-)
[17:29] <pitti> seb128: can you create an /etc/udev/rules.d/50-firmware.rules with
[17:29] <pitti> SUBSYSTEM=="firmware", ACTION=="add", RUN="/bin/false"
[17:29] <pitti> seb128: then reboot, and see whether that fixes it?
[17:30] <pitti> 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] <didrocks> 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] <pitti> didrocks: yeah, I'm wondering about that
[17:32] <pitti> apw: ^ do you know what the kernel expects as a response? in particular for a failure?
[17:33] <pitti> not sure if it notices that the uevent was processed, that would be magic
[17:34] <pitti> oh, I think the helper needs to write -1 into <syspath>/loading
[17:35] <apw> 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] <pitti> 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] <seb128> pitti, that files doesn't work (e.g still the 2 minutes delay) and it feels like it made boot slower
[17:36] <pitti> seb128: yeah, we just figured that out
[17:36] <apw> hmmm, isn't a firmware thing somewhere else like /sys/class/firmware/
[17:36] <seb128> but the boot slower might be a wrong impression
[17:36] <apw> what does the udev rule use
[17:37] <pitti> -        strscpyl(loadpath, sizeof(loadpath), udev_device_get_syspath(dev), "/loading", NULL);
[17:37] <pitti> +E: DEVPATH=/devices/pci0000:00/0000:00:1c.1/0000:02:00.0/firmware/iwlwifi-6000-5.ucode
[17:37] <pitti> so probably that plus /loading
[17:39] <apw> pitti, can't we just read the loader?  is a c prog right?
[17:39] <pitti> apw: yes, that 's the line above (with strscpyl)
[17:39] <pitti> seb128: can you try this:
[17:40] <pitti> SUBSYSTEM=="firmware", ACTION=="add", ATTR{loading}="-1"
[17:40] <apw> that looks like that sort of thing
[17:42] <pitti> apw: yeah, that would be nice and efficient, and avoid calling out to shell or building a dummy program
[17:43] <seb128> pitti, that one works :-)
[17:43] <pitti> !
[17:43] <didrocks> sweet!
[17:43]  * pitti ^5s seb128 and apw
[17:43]  * seb128 ^5s pitti back
[17:43] <apw> ok great :)
[17:44] <apw> pitti, what was the bug# for that
[17:44] <pitti> seb128: ok, I'll prettify this (including initramfs)
[17:44] <ogra_> hey, you could just include that rule from ubuntu touch, we use it as default there ;)
[17:44] <ogra_> convergence !!
[17:44] <pitti> apw: bug 1398458, I kept track of the discussion there
[17:44] <pitti> ogra_: and you only tell me now, after an hour of debugging :)
[17:44] <ogra_> pitti, i didnt see the conversation til now
[17:44] <pitti> apw: so we can use that to track the disabling of that kernel config, in the meantime I'll add that rule
[17:45] <pitti> ogra_: (see the smiley)
[17:45]  * ogra_ is wrangling with a broken heating since last night ... i'm afk on and off 
[17:45] <ogra_> ;)
[17:45] <pitti> ogra_: quick, write an udev rule for it!
[17:45] <ogra_> haha
[17:45] <ogra_> that will surelyy fix my pumps
[17:45] <pitti> SUBSYSTEM=="heating", ATTR{state}=="autodestruct}, ATTR{power}="0"
[18:42] <pitti> seb128: 217-3ubuntu1 uploaded, with that fix
[18:44] <seb128> pitti, \o/
[18:44] <seb128> pitti, I can delete the file you asked me to add then?
[18:47] <pitti> seb128: yes, you should (unless you need to reboot again until it hits vivid)
[18:47] <seb128> pitti, no, I'm fine, deleting it, thanks
[18:47] <seb128> (worth case I need to wait for the timeouts)
[20:30] <Noskcaj> Could we re-add the libusb-1.0 package? libusbx has been RMed in debian, and is outdated in ubuntu
[20:40] <Noskcaj> libusb and libusbx were merged
[20:40] <Noskcaj> (upstream)
[20:40] <Noskcaj> cjwatson, looks like you did the RM, can you take a look?
[20:54] <cjwatson> Noskcaj: Not at this time; send me mail?
[20:54] <Noskcaj> ok
[20:55] <cjwatson> Noskcaj: also, while we're both at least sort of here:
[20:55] <cjwatson> 2014-10-30.log:10:48 <cjwatson> 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] <Noskcaj> 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] <cjwatson> Noskcaj: righto, I'll remove that then, thanks
[20:58] <Noskcaj> ok
[20:58] <cjwatson> and yeah, libusb* has been nagging at me to sort out for a while ...
[20:58] <cjwatson> will have a look tomorrow morning if reminded by mail
[22:05] <Ice-x> 6 Please buy this game http://www.desura.com/games/WipeGround-Wpx =
[22:14] <mterry> doko, you around?   I wanted to ask about python:any in build-deps
[22:49] <doko> mterry, yep?
[22:49] <mterry> 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] <doko> mterry, yes, exactly. that's the only reason. have a look at zope.interface
[23:15] <berz3rk> Hey
[23:15] <berz3rk> Can you help on this bug #1355698
[23:16] <berz3rk> somehow there are big issues with uefi
[23:24] <ScottK> Shouldn't you be asking the elementary devs?
[23:25] <teward> I was about to say the same thing
[23:26] <teward> berz3rk: that's something you should bring up with the Elementary OS devs, not here, I believe.
[23:26] <berz3rk> well yes