[00:59] <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.  
[01:22] <geekintime> What would cause the pcap_findalldevs function to take >60 seconds to return? Seeing this in my own application and tcpdump.
[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] <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.
[10:04] <hyperair> ubuntu-harrassed: if you've gotten a valid ISO, there isn't really a chance for a MITM attack while installing ubuntu
[10:05] <hyperair> also, spamming a channel (and the wrong one at that) isn't going to get you anywhere
[10:19] <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:20] <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:21] <ogra_> !ops
[10:21] <ubot5> Help! lamont, zul, T-Bone, mdz, or jdub
[10:21] <ogra_> ah, to late 
[10:22] <ogra_> (and that ops list should be updated)
[12:33] <rtg> tseliot, there is a 3.16 kernel in https://launchpad.net/~canonical-kernel-team/+archive/ppa for you to test against.
[12:35] <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:37] <rtg> smb, AMD ucode is in the upstream repo
[12:38] <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:39] <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:40] <rtg> IIRC the Intel ucode is not licensed so that it can be included in main
[12:42] <rtg> smb, so you're saying the AMD ucode doesn't load from a udev rule ?
[12:43] <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:46] <smb> rtg, Unfortunately my AMD server currently is busy in Xen...
[13:22] <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:23] <rtg> infinity, I've never read it for content. my eyes start to bleed
[13:23] <infinity> rtg: It's short. :P
[13:24] <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:26] <rtg> infinity, lets make sure that it really _isn't_ working first. 
[13:26] <infinity> rtg: Well, unless the kernel somehow loads it...
[13:27] <rtg> there is that early load mechanism
[13:28] <tseliot> rtg: ok, thanks I'll have a look at them soon
[13:29] <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:30] <infinity> smb: Yeah, I just got there too.
[13:30] <infinity> smb: Same mechanism for both, just checked.
[13:31] <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:32] <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:33] <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:34] <rtg> so, why are the AMD bits in linux-firmware ?
[13:34] <infinity> rtg: That's what we were asking you. ;)
[13:35] <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:36] <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:37] <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:38] <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:39] <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:40] <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:41] <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:42] <infinity> rtg: I seriously can not picture you saying "serendipitous" out loud.
[13:43] <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:44] <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:45] <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:46] <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:47] <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:48] <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:49] <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:52] <jibel> tseliot, fglrx-update fails because PACKAGE_NAME is not defined in dkms.conf
[13:53] <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:54] <infinity> rtg: Heh, I beat you to the same comment, it looks like.  Whee.
[13:55] <rtg> infinity, get out of my bug and go do something else
[13:56] <rtg> like reviewing openipmi for precise
[13:56]  * smb whistles the high noon theme
[13:57] <infinity> rtg: Done and rejected.
[13:57] <rtg> ah, thanks for being so gentle
[13:58] <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:59] <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!
[14:00] <tseliot> jibel: if so, that would be a bug, and dkms should fail. I'm downloading the deb package to check
[14:08] <tseliot> jibel: it is indeed a bug. I'm surprised that even works. Let me fix that
[14:09] <jibel> tseliot, good, I'm glad the test found a bug :)
[14:10] <tseliot> jibel: exactly, thanks
[14:20] <tseliot> jibel: will you have to run the test against the new release or will it happen automatically?
[14:21] <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:22] <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:23] <tseliot> jibel: great
=== zequence_ is now known as zequence
[15:45] <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:46] <tseliot> jibel: hmm... maybe the made a symbol GPL only... I'll look into that, thanks