| === tzero_ is now known as tzero | ||
| === MasterPieceF is now known as MasterPiece | ||
| === pitti` is now known as pitti | ||
| pitti | Good morning | 04:43 |
|---|---|---|
| Unit193 | Howdy. | 04:44 |
| pitti | hey Unit193, how are you? I see you eagerly backport systemd :) | 04:46 |
| Unit193 | pitti: Heh, yeah. Started doing that in trusty, did a couple Debian merges, not fun with systemd. :P | 04:47 |
| 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:48 |
| Unit193 | Awesome! Saw you got added as uploader, congrats. Great to see you work "upstream" too. :) | 04:49 |
| 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:52 |
| Unit193 | pitti: Yep! Just rebooted into it (only slight hickups.) | 04:54 |
| pitti | Unit193: I'm not aware of any regressions, so bug reports appreciated | 04:58 |
| Unit193 | pitti: Heh, only upon reboot the clock was off a few hours. | 05:20 |
| pitti | zul: python-taskflow is still failing its tests, so it doesn't propagate | 06:54 |
| dholbach | good morning | 08:12 |
| highvoltage | good morning! | 08:12 |
| 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:22 |
| dpm | pitti, morning. Ok, let me file the RT | 08:23 |
| LocutusOfBorg1 | hi dholbach :) | 08:40 |
| dholbach | hi LocutusOfBorg1 | 08:42 |
| 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 | 09:45 |
| ubottu | 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 | 09:45 |
| pitti | seb128, dpm: ubuntu vivid langpacks uploaded and updates cron'ed | 10:05 |
| seb128 | pitti, great! | 10:05 |
| dpm | thanks pitti | 10:08 |
| === 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 | ||
| xnox | cjwatson: infinity: was it intentional for 14.04 core tarballs to stop enabling i386 foreign arch? | 12:12 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| === Ursinha is now known as Ursinha-brb | ||
| === Ursinha-brb is now known as Ursinha | ||
| 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 |
| ubottu | Launchpad bug 1337200 in upower (Ubuntu RTM) "High CPU due to excessive device changed signals from upower" [High,Confirmed] | 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:30 |
| rsalveti | pitti: I agree it's unfriendly, but having 2 bugs opened at the same time is not ideal either =\ | 12:31 |
| 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:32 |
| 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:33 |
| rsalveti | pitti: just because the comments from ken vandine are all covering the issue described by the other bug | 12:34 |
| rsalveti | but yeah, let's keep both of them opened then | 12:35 |
| rsalveti | thanks | 12:35 |
| === MacSlow|lunch is now known as MacSlow | ||
| === Guest74903 is now known as Pici | ||
| 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:03 |
| stgraber | xnox: Edubuntu actually ships with two DEs, just saying :) | 15:46 |
| 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:47 |
| stgraber | :) | 15:48 |
| === roadmr is now known as roadmr_afk | ||
| tgm4883 | xnox: no, mythbuntu just has xfce start mythfrontend | 15:58 |
| === caribou_ is now known as caribou | ||
| === roadmr_afk is now known as roadmr | ||
| 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:49 |
| pitti | bug 1398458 | 16:50 |
| ubottu | bug 1398458 in systemd (Ubuntu) "kernel fails to load iwlwifi firmware" [Undecided,New] https://launchpad.net/bugs/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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| pitti | /sys/class/firmware/ only has a single "timeout" file here | 16:55 |
| Sarvatt | yours is 6000g2a | 16:56 |
| Sarvatt | going by http://wireless.kernel.org/en/users/Drivers/iwlwifi | 16:56 |
| 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:57 |
| 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:58 |
| pitti | E: FIRMWARE=iwlwifi-6000-5.ucode | 16:59 |
| pitti | apw: ^ | 16:59 |
| apw | pitti, was that yours or his | 16:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| pitti | apw: so I'm a bit puzzled where the -5 comes from, if the module advertises -4 only | 17:04 |
| 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:05 |
| 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:06 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:12 |
| 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:13 |
| 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:14 |
| pitti | hm, the latest firmware on http://wireless.kernel.org/en/users/Drivers/iwlwifi also only has 6000-4 | 17:15 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| pitti | seb128, apw: I followed up to the bug with the explanation | 17:23 |
| 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:24 |
| pitti | seb128: I'll work on a stub now, and will ask you to test it | 17:25 |
| seb128 | pitti, ok, I'm happy to do testing ;-) | 17:26 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| pitti | not sure if it notices that the uevent was processed, that would be magic | 17:33 |
| pitti | oh, I think the helper needs to write -1 into <syspath>/loading | 17:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| apw | pitti, can't we just read the loader? is a c prog right? | 17:39 |
| === salem_ is now known as _salem | ||
| pitti | apw: yes, that 's the line above (with strscpyl) | 17:39 |
| pitti | seb128: can you try this: | 17:39 |
| pitti | SUBSYSTEM=="firmware", ACTION=="add", ATTR{loading}="-1" | 17:40 |
| apw | that looks like that sort of thing | 17:40 |
| pitti | apw: yeah, that would be nice and efficient, and avoid calling out to shell or building a dummy program | 17:42 |
| 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:43 |
| 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 |
| ubottu | 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 |
| 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:44 |
| 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" | 17:45 |
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| pitti | seb128: 217-3ubuntu1 uploaded, with that fix | 18:42 |
| seb128 | pitti, \o/ | 18:44 |
| seb128 | pitti, I can delete the file you asked me to add then? | 18:44 |
| 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) | 18:47 |
| Noskcaj | Could we re-add the libusb-1.0 package? libusbx has been RMed in debian, and is outdated in ubuntu | 20:30 |
| === greyback_ is now known as greyback | ||
| === salem_ is now known as _salem | ||
| 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:40 |
| cjwatson | Noskcaj: Not at this time; send me mail? | 20:54 |
| Noskcaj | ok | 20:54 |
| 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:55 |
| 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:57 |
| 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 | 20:58 |
| Ice-x | 6 Please buy this game http://www.desura.com/games/WipeGround-Wpx = | 22:05 |
| mterry | doko, you around? I wanted to ask about python:any in build-deps | 22:14 |
| 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:49 |
| doko | mterry, yes, exactly. that's the only reason. have a look at zope.interface | 22:53 |
| === beuno_ is now known as beuno | ||
| berz3rk | Hey | 23:15 |
| berz3rk | Can you help on this bug #1355698 | 23:15 |
| ubottu | bug 1355698 in elementary OS "Unable to boot via UEFI into installed freya system [$500]" [High,Confirmed] https://launchpad.net/bugs/1355698 | 23:15 |
| berz3rk | somehow there are big issues with uefi | 23:16 |
| ScottK | Shouldn't you be asking the elementary devs? | 23:24 |
| teward | I was about to say the same thing | 23:25 |
| teward | berz3rk: that's something you should bring up with the Elementary OS devs, not here, I believe. | 23:26 |
| berz3rk | well yes | 23:26 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!