geekintime | Where 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 |
---|---|---|
geekintime | What would cause the pcap_findalldevs function to take >60 seconds to return? Seeing this in my own application and tcpdump. | 01:22 |
ubuntu-harrassed | please 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-harrassed | please 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-harrassed | please 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-harrassed | please 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-harrassed | please 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-harrassed | please 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-harrassed | please 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-harrassed | please 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-harrassed | please 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-harrassed | please 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-harrassed | please 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 |
hyperair | ubuntu-harrassed: if you've gotten a valid ISO, there isn't really a chance for a MITM attack while installing ubuntu | 10:04 |
hyperair | also, spamming a channel (and the wrong one at that) isn't going to get you anywhere | 10:05 |
ubuntu-harrassed | http://packetstormsecurity.com/news/view/24247/2012-RCE-Bug-Is-Still-Highly-Exploited-In-Targeted-Attacks.html | 10:19 |
ubuntu-harrassed | hyperair | 10:19 |
ubuntu-harrassed | http://packetstormsecurity.com/news/view/24238/NCA-Gameover-Zeus-Malware-Fix-Deadline-Passes.html | 10:19 |
ubuntu-harrassed | http://packetstormsecurity.com/news/view/24164/National-Crime-Agency-Warns-About-Botnet-Epidemic.html | 10:20 |
ubuntu-harrassed | scammer hyperair | 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 #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA #NSA vvv | 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 #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_ | !ops | 10:21 |
ubot5 | Help! lamont, zul, T-Bone, mdz, or jdub | 10:21 |
ogra_ | ah, to late | 10:21 |
ogra_ | (and that ops list should be updated) | 10:22 |
rtg | tseliot, there is a 3.16 kernel in https://launchpad.net/~canonical-kernel-team/+archive/ppa for you to test against. | 12:33 |
tseliot | rtg: thanks, any chance we can run automated tests against it first. My plate is kind of full now. apw ^^ | 12:35 |
smb | rtg, 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 |
rtg | smb, AMD ucode is in the upstream repo | 12:37 |
smb | rtg, ok, so we "just" inherited the problem :/ | 12:38 |
rtg | smb, plus amd64-microcode is a multiverse package. | 12:38 |
smb | rtg, Same as intel-microcode | 12:38 |
rtg | right. | 12:39 |
rtg | which I sort of keep up to date. | 12:39 |
smb | That why I am surprised the AMD files are in linux-firmware | 12:39 |
rtg | I suppose 'cause AMD requested it, and provided the right licensing | 12:39 |
rtg | IIRC the Intel ucode is not licensed so that it can be included in main | 12:40 |
rtg | smb, so you're saying the AMD ucode doesn't load from a udev rule ? | 12:42 |
smb | Just 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 magic | 12:43 |
smb | At least the seperate package comes with those. But let me make sure before whining too loud | 12:43 |
smb | rtg, Unfortunately my AMD server currently is busy in Xen... | 12:46 |
rtg | tseliot, automated test builds are already happening: https://jenkins.qa.ubuntu.com/view/DKMS/view/U%20KT-PPA%20-generic/ | 13:22 |
infinity | rtg: To be fair, the AMD microcode license doesn't look main-compatible either. | 13:22 |
infinity | rtg: There's no explicit right to modify, only to copy. | 13:22 |
rtg | infinity, I've never read it for content. my eyes start to bleed | 13:23 |
infinity | rtg: It's short. :P | 13:23 |
infinity | rtg: 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 |
rtg | IIRC Intel's license limitation is that it is a click-thru | 13:24 |
rtg | infinity, lets make sure that it really _isn't_ working first. | 13:26 |
infinity | rtg: Well, unless the kernel somehow loads it... | 13:26 |
rtg | there is that early load mechanism | 13:27 |
tseliot | rtg: ok, thanks I'll have a look at them soon | 13:28 |
smb | infinity, 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/reload | 13:29 |
infinity | smb: Yeah, I just got there too. | 13:30 |
infinity | smb: Same mechanism for both, just checked. | 13:30 |
smb | thats nifty... and kind of unexpected... but good | 13:31 |
infinity | smb: 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 |
smb | Right, so the hook could be supplied in a generalized way. When being careful not to clash with what the Intel package provides right now | 13:32 |
rtg | looks like the intel-microcode package has an initramfs hook | 13:32 |
infinity | rtg: They both have identical hooks, except for the intel/amd check. | 13:33 |
infinity | Which makes sense, since it's the same maintainer. | 13:33 |
rtg | so, why are the AMD bits in linux-firmware ? | 13:34 |
infinity | rtg: That's what we were asking you. ;) | 13:34 |
rtg | well, I didn't put 'em there | 13:35 |
smb | Prolly because the debian maintainer for that is not the same? | 13:35 |
rtg | we could dump the bits from linux-firmware and fix the packaging for amd-microcode such tat its doesn't remove the world. | 13:35 |
infinity | The versions in linux-firmware and amd64-microcode are identical, I just checked. | 13:35 |
smb | rtg, its actually in linux-firmware | 13:36 |
rtg | smb, the conflicts ? | 13:36 |
infinity | rtg: amd64-microcode does nothing wrong, it's just linux-firmware's conflict that breaks it. | 13:36 |
smb | rtg, yes I assume so | 13:36 |
rtg | well, thats easy enough to fix. | 13:36 |
smb | since the other package only conficts with intel-microcode | 13:36 |
infinity | Well, the P/C/R, all three should be dropped. | 13:36 |
infinity | smb: It only conflicts with an old version of intel-microcode. They can co-exist now. | 13:37 |
rtg | thats twice you've mentioned P/C/R. wtf is that ? | 13:37 |
smb | infinity, Ah yeah the <<2 | 13:37 |
infinity | rtg: Provides/Conflicts/Replaces | 13:37 |
infinity | rtg: Sorry, Debian shorthand. | 13:37 |
rtg | packaging weenies. | 13:37 |
rtg | I'm happy to just rip out all the AMD bits in favor of the external package that carries the right hook scripts. | 13:38 |
infinity | rtg: That sounds like the sane plan to me too. | 13:38 |
rtg | alright, gimme a bit. smb - is there an existing bug moaning about amd-microcode conflicts with linux-firmware ? | 13:39 |
infinity | rtg: FWIW, both licenses are about the same as far as restrictions (except the Intel one also says you can't disassemble it). | 13:39 |
infinity | rtg: Either would be fine for restricted, if we ever decide to go that route, neither is fine for main. | 13:40 |
smb | infinity, I think that says the other too | 13:40 |
smb | rtg, No not yet | 13:40 |
smb | but I can make one | 13:40 |
rtg | smb, please do and I'll follow up | 13:40 |
infinity | smb: Oh, you're right, the AMD one also whines about disassembly, I skipped that line. :P | 13:40 |
smb | infinity, So rtg was right about the blurring effect. :) | 13:40 |
rtg | which is a good reason to get it out of main | 13:41 |
infinity | rtg: 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 |
rtg | serendipitous indeed | 13:41 |
infinity | rtg: I seriously can not picture you saying "serendipitous" out loud. | 13:42 |
rtg | in truth it was muttered under my breath with a bit of sarcasm | 13:43 |
smb | rtg, Actually it seems there already might be one: bug 1181145 | 13:43 |
ubot5 | bug 1181145 in linux-firmware (Ubuntu) "linux-firmware conflict with amd64-microcode" [Undecided,Confirmed] https://launchpad.net/bugs/1181145 | 13:43 |
rtg | smb, seems like I've already stuck my foot in mouth in that bug | 13:44 |
smb | rtg, Heh, yeah I was just noting that fact | 13:44 |
smb | :) | 13:44 |
rtg | and recently even. | 13:44 |
smb | Meh, last year | 13:45 |
tseliot | rtg: fglrx-updates is a false failure, in that it succeeded but it was reported as a failure | 13:45 |
rtg | tseliot, have you bugged jibel about it ? | 13:45 |
tseliot | rtg: I'll check them all first | 13:46 |
infinity | rtg: 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 |
infinity | rtg: But reusing it to remove the offending files and the P/C/R seems fine by me. ;) | 13:46 |
infinity | Err, wait. That last comment is two days ago. | 13:47 |
infinity | Weird. | 13:47 |
infinity | Whatever. | 13:47 |
rtg | yeah, Richard Laager has a point | 13:47 |
infinity | Oh. It's people running precise, that's why. | 13:47 |
smb | infinity, Meh, you know people suddenly coming back | 13:47 |
rtg | infinity, this should probably ripple back to Precise as well. | 13:48 |
infinity | rtg: precise has the file overlap without the Conflict, which is admittedly even worse than the trusty situation. | 13:48 |
infinity | So, yeah, let's add us some tasks here... | 13:48 |
rtg | refresh | 13:49 |
infinity | Which I can't do because someone added and removed some in the past, breaking LP's tiny mind. | 13:49 |
infinity | Oh, or you added them while I was clicking. | 13:49 |
infinity | Hah. | 13:49 |
jibel | tseliot, fglrx-update fails because PACKAGE_NAME is not defined in dkms.conf | 13:52 |
jibel | tseliot, it is set to PACKAGE_NAME="#DRIVERNAME" | 13:53 |
jibel | well, it is defined but not the name of the module | 13:53 |
tseliot | jibel: that would be in the dkms.conf.in though, the dkms.conf should be fine, or dkms wouldn't work | 13:53 |
rtg | infinity, https://bugs.launchpad.net/ubuntu/+source/amd64-microcode/+bug/1181145/comments/5 | 13:53 |
ubot5 | Ubuntu bug 1181145 in linux-firmware (Ubuntu Utopic) "linux-firmware conflict with amd64-microcode" [Undecided,In progress] | 13:53 |
infinity | rtg: Heh, I beat you to the same comment, it looks like. Whee. | 13:54 |
rtg | infinity, get out of my bug and go do something else | 13:55 |
rtg | like reviewing openipmi for precise | 13:56 |
* smb whistles the high noon theme | 13:56 | |
infinity | rtg: Done and rejected. | 13:57 |
rtg | ah, thanks for being so gentle | 13:57 |
infinity | rtg: Rejected for the version number, but the rest looks a bit messy too... | 13:58 |
jibel | tseliot, /usr/src/fglrx-updates-13.350.1/dkms.conf has #DRIVERNAME in it | 13:58 |
rtg | infinity, I couldn't figure out how to not generate config.sub et al | 13:58 |
jibel | tseliot, I don't use BUILT_MODULES_NAME[#] because it is not always defined | 13:58 |
infinity | rtg: Build without cleaning, if debian/rules clean is doing that. | 13:59 |
rtg | it is | 13:59 |
infinity | rtg: Add '-nc' to your dpkg-buildpackage/debuild. | 13:59 |
rtg | seems obvious in retrospect. duh! | 13:59 |
tseliot | jibel: if so, that would be a bug, and dkms should fail. I'm downloading the deb package to check | 14:00 |
tseliot | jibel: it is indeed a bug. I'm surprised that even works. Let me fix that | 14:08 |
jibel | tseliot, good, I'm glad the test found a bug :) | 14:09 |
tseliot | jibel: exactly, thanks | 14:10 |
tseliot | jibel: will you have to run the test against the new release or will it happen automatically? | 14:20 |
jibel | tseliot, it's automatic when there is a new kernel or a new version of a dkms module | 14:21 |
jibel | tseliot, if it doesn't, let me know and I'll check | 14:21 |
tseliot | jibel: this is just a new package revision i.e. 2:13.350.1-0ubuntu3 (vs the ubuntu2 rev) | 14:22 |
tseliot | ok | 14:22 |
jibel | tseliot, that's fine it should be automatic | 14:22 |
tseliot | jibel: great | 14:23 |
=== zequence_ is now known as zequence | ||
jibel | tseliot, https://jenkins.qa.ubuntu.com/job/dkms-utopic-release_canonical_kernel_team_ppa-generic-fglrx_updates/15/ passes on amd64 but fails on i386 | 15:45 |
jibel | FATAL: modpost: GPL-incompatible module fglrx.ko uses GPL-only symbol '__static_cpu_has_safe' | 15:45 |
tseliot | jibel: hmm... maybe the made a symbol GPL only... I'll look into that, thanks | 15:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!