/srv/irclogs.ubuntu.com/2014/06/25/#ubuntu-kernel.txt

geekintimeWhere would I direct this: Having extremely long waits returning from pcap_findalldevs.  Lookup of system interfaces is taking a LONG time.  tcpdump is also seeing this problem.  00:59
geekintimeWhat would cause the pcap_findalldevs function to take >60 seconds to return? Seeing this in my own application and tcpdump.01:22
ubuntu-harrassedplease introduce pre-built VPN to install ubuntu in a secure manner and without consuming much bandwidth which happens when a MITM/MITB attacker uses my laptop as a node for establishing the attack against another computer.09:58
ubuntu-harrassedplease introduce pre-built VPN to install ubuntu in a secure manner and without consuming much bandwidth which happens when a MITM/MITB attacker uses my laptop as a node for establishing the attack against another computer.09:58
ubuntu-harrassedplease introduce pre-built VPN to install ubuntu in a secure manner and without consuming much bandwidth which happens when a MITM/MITB attacker uses my laptop as a node for establishing the attack against another computer.09:58
ubuntu-harrassedplease introduce pre-built VPN to install ubuntu in a secure manner and without consuming much bandwidth which happens when a MITM/MITB attacker uses my laptop as a node for establishing the attack against another computer.09:58
ubuntu-harrassedplease introduce pre-built VPN to install ubuntu in a secure manner and without consuming much bandwidth which happens when a MITM/MITB attacker uses my laptop as a node for establishing the attack against another computer.09:58
ubuntu-harrassedplease introduce pre-built VPN to install ubuntu in a secure manner and without consuming much bandwidth which happens when a MITM/MITB attacker uses my laptop as a node for establishing the attack against another computer.09:59
ubuntu-harrassedplease introduce pre-built VPN to install ubuntu in a secure manner and without consuming much bandwidth which happens when a MITM/MITB attacker uses my laptop as a node for establishing the attack against another computer.09:59
ubuntu-harrassedplease introduce pre-built VPN to install ubuntu in a secure manner and without consuming much bandwidth which happens when a MITM/MITB attacker uses my laptop as a node for establishing the attack against another computer.09:59
ubuntu-harrassedplease introduce pre-built VPN to install ubuntu in a secure manner and without consuming much bandwidth which happens when a MITM/MITB attacker uses my laptop as a node for establishing the attack against another computer.09:59
ubuntu-harrassedplease introduce pre-built VPN to install ubuntu in a secure manner and without consuming much bandwidth which happens when a MITM/MITB attacker uses my laptop as a node for establishing the attack against another computer.09:59
ubuntu-harrassedplease introduce pre-built VPN to install ubuntu in a secure manner and without consuming much bandwidth which happens when a MITM/MITB attacker uses my laptop as a node for establishing the attack against another computer.09:59
hyperairubuntu-harrassed: if you've gotten a valid ISO, there isn't really a chance for a MITM attack while installing ubuntu10:04
hyperairalso, spamming a channel (and the wrong one at that) isn't going to get you anywhere10:05
ubuntu-harrassedhttp://packetstormsecurity.com/news/view/24247/2012-RCE-Bug-Is-Still-Highly-Exploited-In-Targeted-Attacks.html10:19
ubuntu-harrassedhyperair10:19
ubuntu-harrassedhttp://packetstormsecurity.com/news/view/24238/NCA-Gameover-Zeus-Malware-Fix-Deadline-Passes.html10:19
ubuntu-harrassedhttp://packetstormsecurity.com/news/view/24164/National-Crime-Agency-Warns-About-Botnet-Epidemic.html10:20
ubuntu-harrassedscammer hyperair10:20
ubuntu-harrassed#NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA vvv10:20
ubuntu-harrassed#NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA 10:20
ubuntu-harrassed#NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA 10:20
ubuntu-harrassed#NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA 10:20
ogra_!ops10:21
ubot5Help! lamont, zul, T-Bone, mdz, or jdub10:21
ogra_ah, to late 10:21
ogra_(and that ops list should be updated)10:22
rtgtseliot, there is a 3.16 kernel in https://launchpad.net/~canonical-kernel-team/+archive/ppa for you to test against.12:33
tseliotrtg: thanks, any chance we can run automated tests against it first. My plate is kind of full now. apw ^^12:35
smbrtg, Good morning. Do you remember how AMD cpu microcode happened to end up in linux-firmware? At least in Trusty there now seems the problem that linux-firmware does not come with the scripts to cause the microcode to load and installing amd64-microcode will get rid of not only linux-firmware but also the meta-packages related (linux-generic, etc)12:35
rtgsmb, AMD ucode is in the upstream repo12:37
smbrtg, ok, so we "just" inherited the problem :/12:38
rtgsmb, plus amd64-microcode is a multiverse package. 12:38
smbrtg, Same as intel-microcode12:38
rtgright.12:39
rtgwhich I sort of keep up to date.12:39
smbThat why I am surprised the AMD files are in linux-firmware12:39
rtgI suppose 'cause AMD requested it, and provided the right licensing12:39
rtgIIRC the Intel ucode is not licensed so that it can be included in main12:40
rtgsmb, so you're saying the AMD ucode doesn't load from a udev rule ?12:42
smbJust a pity that the firmware files alone aren't helping. As for as I can see one needs initramfs hooks to copy them there and then do some sysfs magic12:43
smbAt least the seperate package comes with those. But let me make sure before whining too loud12:43
smbrtg, Unfortunately my AMD server currently is busy in Xen...12:46
rtgtseliot, automated test builds are already happening: https://jenkins.qa.ubuntu.com/view/DKMS/view/U%20KT-PPA%20-generic/13:22
infinityrtg: To be fair, the AMD microcode license doesn't look main-compatible either.13:22
infinityrtg: There's no explicit right to modify, only to copy.13:22
rtginfinity, I've never read it for content. my eyes start to bleed13:23
infinityrtg: It's short. :P13:23
infinityrtg: Anyhow, if we want to operate under the assumption that people might want the multiverse packages because of the initramfs hooks (ie: they actually do something), we might want to strip the files from linux-firmware and drop the P/C/R.13:24
rtgIIRC Intel's license limitation is that it is a click-thru 13:24
rtginfinity, lets make sure that it really _isn't_ working first. 13:26
infinityrtg: Well, unless the kernel somehow loads it...13:26
rtgthere is that early load mechanism13:27
tseliotrtg: ok, thanks I'll have a look at them soon13:28
smbinfinity, rtg, I am not sure AMD and Intel use the same mechanisms. If I understand the script right on AMD its echoing a 1 into /sys/devices/system/cpu/microcode/reload13:29
infinitysmb: Yeah, I just got there too.13:30
infinitysmb: Same mechanism for both, just checked.13:30
smbthats nifty... and kind of unexpected... but good13:31
infinitysmb: So, it doesn't NEED to be in initramfs, since you can patch a live system, it could just as easily be an init script.  But it needs to be *something* that triggers the reload when the files are available.13:31
smbRight, so the hook could be supplied in a generalized way. When being careful not to clash with what the Intel package provides right now13:32
rtglooks like the intel-microcode package has an initramfs hook13:32
infinityrtg: They both have identical hooks, except for the intel/amd check.13:33
infinityWhich makes sense, since it's the same maintainer.13:33
rtgso, why are the AMD bits in linux-firmware ?13:34
infinityrtg: That's what we were asking you. ;)13:34
rtgwell, I didn't put 'em there13:35
smbProlly because the debian maintainer for that is not the same?13:35
rtgwe could dump the bits from linux-firmware and fix the packaging for amd-microcode such tat its doesn't remove the world.13:35
infinityThe versions in linux-firmware and amd64-microcode are identical, I just checked.13:35
smbrtg, its actually in linux-firmware13:36
rtgsmb, the conflicts ?13:36
infinityrtg: amd64-microcode does nothing wrong, it's just linux-firmware's conflict that breaks it.13:36
smbrtg, yes I assume so13:36
rtgwell, thats easy enough to fix.13:36
smbsince the other package only conficts with intel-microcode13:36
infinityWell, the P/C/R, all three should be dropped.13:36
infinitysmb: It only conflicts with an old version of intel-microcode.  They can co-exist now.13:37
rtgthats twice you've mentioned P/C/R. wtf is that ?13:37
smbinfinity, Ah yeah the <<213:37
infinityrtg: Provides/Conflicts/Replaces13:37
infinityrtg: Sorry, Debian shorthand.13:37
rtgpackaging weenies.13:37
rtgI'm happy to just rip out all the AMD bits in favor of the external package that carries the right hook scripts.13:38
infinityrtg: That sounds like the sane plan to me too.13:38
rtgalright, gimme a bit. smb - is there an existing bug moaning about amd-microcode conflicts with linux-firmware ?13:39
infinityrtg: FWIW, both licenses are about the same as far as restrictions (except the Intel one also says you can't disassemble it).13:39
infinityrtg: Either would be fine for restricted, if we ever decide to go that route, neither is fine for main.13:40
smbinfinity, I think that says the other too13:40
smbrtg, No not yet 13:40
smbbut I can make one13:40
rtgsmb, please do and I'll follow up13:40
infinitysmb: Oh, you're right, the AMD one also whines about disassembly, I skipped that line. :P13:40
smbinfinity, So rtg was right about the blurring effect. :)13:40
rtgwhich is a good reason to get it out of main13:41
infinityrtg: Right, I think we should tear it out for licensing reasons, the fact that it also fixes the multiverse package is just a happy accident. ;)13:41
rtgserendipitous indeed13:41
infinityrtg: I seriously can not picture you saying "serendipitous" out loud.13:42
rtgin truth it was muttered under my breath with a bit of sarcasm13:43
smbrtg, Actually it seems there already might be one: bug 118114513:43
ubot5bug 1181145 in linux-firmware (Ubuntu) "linux-firmware conflict with amd64-microcode" [Undecided,Confirmed] https://launchpad.net/bugs/118114513:43
rtgsmb, seems like I've already stuck my foot in mouth in that bug13:44
smbrtg, Heh, yeah I was just noting that fact13:44
smb:)13:44
rtgand recently even.13:44
smbMeh, last year13:45
tseliotrtg: fglrx-updates is a false failure, in that it succeeded but it was reported as a failure13:45
rtgtseliot, have you bugged jibel about it ?13:45
tseliotrtg: I'll check them all first13:46
infinityrtg: I think that bug was about file overlaps, and you fixed it (but without closing it) by adding the P/C/R. At least, that's how I read it.13:46
infinityrtg: But reusing it to remove the offending files and the P/C/R seems fine by me. ;)13:46
infinityErr, wait.  That last comment is two days ago.13:47
infinityWeird.13:47
infinityWhatever.13:47
rtgyeah, Richard Laager has a point13:47
infinityOh.  It's people running precise, that's why.13:47
smbinfinity, Meh, you know people suddenly coming back 13:47
rtginfinity, this should probably ripple back to Precise as well.13:48
infinityrtg: precise has the file overlap without the Conflict, which is admittedly even worse than the trusty situation.13:48
infinitySo, yeah, let's add us some tasks here...13:48
rtgrefresh13:49
infinityWhich I can't do because someone added and removed some in the past, breaking LP's tiny mind.13:49
infinityOh, or you added them while I was clicking.13:49
infinityHah.13:49
jibeltseliot, fglrx-update fails because PACKAGE_NAME is not defined in dkms.conf13:52
jibeltseliot, it is set to PACKAGE_NAME="#DRIVERNAME" 13:53
jibelwell, it is defined but not the name of the module13:53
tseliotjibel: that would be in the dkms.conf.in though, the dkms.conf should be fine, or dkms wouldn't work13:53
rtginfinity, https://bugs.launchpad.net/ubuntu/+source/amd64-microcode/+bug/1181145/comments/513:53
ubot5Ubuntu bug 1181145 in linux-firmware (Ubuntu Utopic) "linux-firmware conflict with amd64-microcode" [Undecided,In progress]13:53
infinityrtg: Heh, I beat you to the same comment, it looks like.  Whee.13:54
rtginfinity, get out of my bug and go do something else13:55
rtglike reviewing openipmi for precise13:56
* smb whistles the high noon theme13:56
infinityrtg: Done and rejected.13:57
rtgah, thanks for being so gentle13:57
infinityrtg: Rejected for the version number, but the rest looks a bit messy too...13:58
jibeltseliot, /usr/src/fglrx-updates-13.350.1/dkms.conf has #DRIVERNAME in it13:58
rtginfinity, I couldn't figure out how to not generate config.sub et al13:58
jibeltseliot, I don't use BUILT_MODULES_NAME[#] because it is not always defined13:58
infinityrtg: Build without cleaning, if debian/rules clean is doing that.13:59
rtgit is13:59
infinityrtg: Add '-nc' to your dpkg-buildpackage/debuild.13:59
rtgseems obvious in retrospect. duh!13:59
tseliotjibel: if so, that would be a bug, and dkms should fail. I'm downloading the deb package to check14:00
tseliotjibel: it is indeed a bug. I'm surprised that even works. Let me fix that14:08
jibeltseliot, good, I'm glad the test found a bug :)14:09
tseliotjibel: exactly, thanks14:10
tseliotjibel: will you have to run the test against the new release or will it happen automatically?14:20
jibeltseliot, it's automatic when there is a new kernel or a new version of a dkms module14:21
jibeltseliot, if it doesn't, let me know and I'll check14:21
tseliotjibel: this is just a new package revision i.e. 2:13.350.1-0ubuntu3 (vs the ubuntu2 rev)14:22
tseliotok14:22
jibeltseliot, that's fine it should be automatic14:22
tseliotjibel: great14:23
=== zequence_ is now known as zequence
jibeltseliot, https://jenkins.qa.ubuntu.com/job/dkms-utopic-release_canonical_kernel_team_ppa-generic-fglrx_updates/15/ passes on amd64 but fails on i38615:45
jibelFATAL: modpost: GPL-incompatible module fglrx.ko uses GPL-only symbol '__static_cpu_has_safe'15:45
tseliotjibel: hmm... maybe the made a symbol GPL only... I'll look into that, thanks15:46

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!