[00:55] <Dan> Need help installing/configuring kernel-source so driver modules will build for conexant usb modem. My thread is here (not spam) http://ubuntuforums.org/showthread.php?t=2270054
[00:56] <Dan> If that is seen after i leave please reply to post, been trying to install these drivers for about 8 days now. Quite frustrated
[00:58] <Dan> More extensive thread on other forum http://www.linuxquestions.org/questions/ubuntu-63/compiling-kernel-source-build-modules-in-ubuntu-14-04-a-4175536945/
[00:58] <Dan> Replies and help are appreciated
[01:00] <apw> Dan, the source for the kernel has changed, moving the version.h file somewhere else (into the uapi directory)
[01:01] <apw> Dan, the driver is clearly not been updated to match in the recent past, and needs to be
[01:01] <Dan> Where is the uapi directory?
[01:01] <Dan> Thanks for reply
[01:02] <Dan> So i just move version.h into uapi directory and it should build?
[01:04] <Dan> Also yes, the drivers havent been maintained since i think 9.10
[01:04] <apw> i doubt that very much, if the code is writeen for the kernel since before uapi existed the chances of it workign with the new kernel is very low at best
[01:04] <apw> version.h is already in the uapi directory (under that build link) the driver expects it not to be
[01:05] <apw> but the uapi split isn't exactly new, so you are in uncharted territory
[01:05] <Dan> Could you reccomend me a distro that would support any of these? http://www.linuxant.com/drivers/dgc/downloads.php
[01:06] <Dan> Only reason im on 14.04 is because help was refused if i was running an EOTL release
[01:07] <Dan> I only need gnome-ppp so as long as it supports that but with a old enough kernel to install/build my drivers that's fine
[01:07] <apw> Dan, i find it supprising they arn't supported out of the box these days, they are anchient
[01:07] <Dan> I got version 1.01 out of the box lol and wouldnt even install
[01:08] <Dan> 1.13.0 installs but i have the module build issue
[01:09] <apw> i mean without any extra drivers, most of these things get core support over time
[01:09] <apw> though that page tells you what distros support the drivers, the last ones it lists are so old one normally assumes
[01:09] <apw> the driver has made it into mainline
[01:11] <Dan> So my best bet it to try 9.10?
[01:12] <apw> if the system doesn't work it out of the box, i'd say you are in a hole
[01:12] <apw> as the vendor clearly does not support their own h/w any more
[01:12] <Dan> I installed the generic dgcmodem-1.13.0.deb ill try the distro specific packages
[01:12] <Dan> Thanks for your help, at least i dont have to figure out the kernel-source
[01:15] <Dan> But just to verify, installing the kernel source would do nothing, yes?
[02:18] <mozmck> I'm running the following to build some custom kernel packages:  fakeroot debian/rules binary-indep; fakeroot debian/rules binary-perarch; and then fakeroot debian/rules binary-<custom flavour>
[02:18] <mozmck> Is this the right way to do this?  It is not building a linux-firmware package - should it?
[02:20] <mozmck> oh, and linux-libc-dev is not being built either, but I don't know if it should be.
[02:24] <infinity> mozmck: linux-firmware is built by the linux-firmware source package.
[02:27] <mozmck> oh, I'm using skipabi=true skipmodule=true - is that still necessary?  I had to do that when I built a custom ubuntu kernel for 10.04
[02:28] <infinity> mozmck: It's still necessary if you don't plan to track your ABI changes appropriately.
[02:29] <infinity> apw: The mind boggles that someone would apparently waste a week trying to make a 10 year old piece of hardware work that he could have replaced for 15 bucks.
[02:30] <mozmck> ok, thanks.
[02:32] <lifeless> infinity: ... that was the case 10 years ago too :)
[02:32] <infinity> lifeless: Yeah, true.
[02:33] <infinity> lifeless: But I get the motivation to make new kit go.  And if you're a hacker, I get the challenge of making old kit go.  But as a volue proposition, if you've gotten a decade out of your 15 dollar softmodem, it's time to find a bin for it.
[02:33] <infinity> s/volue/value/
[02:33]  * infinity side-eyes his fingers.
[02:35] <lifeless> Aye.
[02:35] <lifeless> But its his precious.
[02:35] <lifeless> Or maybe he has 10000 of them in retail stores all over the place.
[02:36] <infinity> Heh.
[02:37] <mozmck> if I want to build i386 packages on my amd64 machine, how would I do that?
[02:37] <lifeless> easiest way is probably a i686 lxc container
[02:37] <mozmck> I made a flavour for amd64 and i386, but only the amd64 flavour built
[02:37] <lifeless> lxc-create -t ubuntu -n fred -- -a i686 
[02:37] <infinity> Or just a chroot.
[02:38] <lifeless> personally find it more fiddly to manage cross-arch stuff in chroots, but sure, whatever :)
[02:38] <infinity> mozmck: Many ways to skin that proverbial cat, but the basic essence is that you want an i386 userspace.  So a chroot or lxc or a VM (in order from light to heavy).
[02:38] <mozmck> ok, I've heard of pbuilder but not used it, I'll do some reading.
[02:39] <infinity> lifeless: Well, your lxc-create call is creating an i386 chroot. :P
[02:39] <mozmck> ok, thanks.
[02:39] <infinity> lifeless: How you enter it defines if it's a chroot or a container.
[02:39] <infinity> mozmck: pbuilder is the devil's tool.  sbuild is the way and the light.
[02:39] <mozmck> can I easily use 8 cores in a chroot?
[02:39] <mozmck> heh, ok!
[02:39] <infinity> mozmck: A chroot changes nothing about your system.  It's just a directory with another root filesystem in it.
[02:40] <lifeless> infinity: yes indeed :)
[02:40] <mozmck> ah, ok.
[02:40] <lifeless> you should be able to use multi-arch in principle too
[02:40] <infinity> You can, yes.  And for a kernel, that's not a terrible option, since the build-deps are light.
[02:41] <mozmck> multi-arch?
[02:41] <infinity> mozmck: The man makes a fair point.  It could be as simple as taking your dpkg-buildpackage command and adding "-ai386" to the command line. :P
[02:41] <lifeless> can one do apt-get build-dep linux-kernel/i386? 
[02:41] <lifeless> I forgets
[02:42] <mozmck> hmm, ok.  I'm using debian/rules binary-...  
[02:42] <infinity> lifeless: I think apt also uses the -aarch syntax for that, but I don't recall.
[02:42] <mozmck> I presume that calls dpkg-buildpackage somewhere?
[02:42] <infinity> mozmck: Ahh, no.  Other way around, dpkg-buildpackage calls debian/rules.
[02:43] <infinity> mozmck: But if you're happier doing the manual fiddling instead of building the whole shebang, just build a quick chroot (or, as lifeless says, an lxc container), and build in there.
[02:44] <infinity> lxc might be simpler, just cause it automates the fiddly bind mount bits and whatnot.
[02:44] <mozmck> oh, well I haven't used that then I guess.  fakeroot debian/rules binary-<indep|perarch|flavour> is what I've been using.
[02:45] <mozmck> maybe I should be using dpkg-buildpackage.  I only want one flavour though - my custom (PREEMPT-RT) one.
[03:04] <gshmu> I want test the latest upstream kernel, so I install the last kernel, but I can't longin in new kernel at tty7. anyone can tell me how to build the linux-image-extra-000.deb package?
[03:07] <mozmck> I would like to know that as well!
[03:07] <gshmu> mozmck: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1432459
[03:07] <ubot5> Ubuntu bug 1432459 in linux (Ubuntu) "USB 3.0 automount after "Power off driver/safely remove"" [Low,Incomplete]
[03:10] <gshmu> Can you help me to build the linux-image-extra-4.000.deb ?   I'm just build this package: linux-firmware-image-4.0.0-rc1-gshmu_4.0.0-rc1-gshmu-1_amd64.deb linux-headers-4.0.0-rc1-gshmu_4.0.0 rc1-gshmu-1_amd64.deb linux-image-4.0.0-rc1-gshmu_4.0.0-rc1-gshmu-1_amd64.deb linux-image-4.0.0-rc1-gshmu-dbg_4.0.0-rc1-gshmu-1_amd64.deb linux-libc-dev_4.0.0-rc1-gshmu-1_amd64.deb
=== gerald is now known as Guest46672
[07:39] <zequence> infinity: Sorry, haven't been in for a few days. Both kernels tested now.
[09:13] <apw> gshmu, there is no linux-image-extra for mainline builds, they build with the split disabled so all modules should be in the linux-image package
[09:21] <stub> Anyone have some kernel boot parameters that might get some useful debug information for https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1434136 ?
[09:21] <ubot5> Ubuntu bug 1434136 in linux (Ubuntu) "HP Pavilion 13-b208tu fails to boot with F.26 bios, PSOD" [Undecided,Confirmed]
[09:33] <gshmu> apw: How to build it by my self?
[09:34] <apw> gshmu, you don't need it because all of its content are instead in linux-image
[09:34] <gshmu> apw: I can't login in tty7
[09:35] <apw> we do not split the package for mainline builds because it adds no value and can fail because of upstream changed
[09:36] <apw> gshmu, unsure, sounds likely that you are seeing a graphics hang from your bug discription, and those sort of things are pretty common in a -rc kernel, particularly as it happens after you are able to type username and password at lightdm
[09:37] <apw> gshmu, i would say as you are looking to see if a usb issue is resolved, that you try a v3.19.x kernel from there, as they tend to be more stable
[09:37] <gshmu> apw: thanks you 
[14:02] <mozmck> apw: how does the build system know that a mainline kernel is being used so it does not split out the *extra package?
[14:05] <apw> mozmck, the mainline builder specified it wants no split
[14:10] <mozmck> apw: ok, so I copied the debian and debian.master from vivid at the next commit after the 3.18.7 tag into a mainline 3.18.9 kernel.  I do not get the extra package, or the linux-libc-dev package.  should I be getting the latter?  I'm running debian/rules with binary-indep, binary-perarch, and binary-<myflavor> to build packages.
[15:08] <apw> mozmck, not sure, the config for the flavour contains the split info, so if you called it something other than generic likely not
[15:08] <apw> you can also tell from the size of the linux-image, if it is huge then it is not split
[15:28] <mozmck> apw: hmm, ok.  I called preemptrt, and the linux-image package is 54 MB, so I guess it is not split
[15:28] <mozmck> thanks.
[15:55] <apw> mozmck, yes the inclusion list is generic specific so you should avoid it
[16:39] <BeagleBug_97> Is it possible to install rt-preempt patch on BeagleBoard xM kernel running Ubuntu 14.04?
[21:38] <lamont> who knows precise iptables better than anyone should?
[21:39]  * lamont has very specific quesitons about conntracking in the 3.13.0 kernel (oops, s/precise/trusty/) and would prefer not to go read that much source
[21:40] <apw> lamont, i'd guess that without reading only jay might know any detailed questions, though i'd say ask anyhow
[21:42] <lamont> lets say I was being crazy and trying to move firewalling to another machine by doing this:  (1) insert the new machine in between the old machine and the outside link from same.  (2) turn on conntracking, but allow all traffic through the new-firewall-to-be, (3) at some point trade rules and make the new machine the active and statefully firewalling machine, and the old one becomes "let it all
[21:42] <lamont> through" (4) remove the old machine
[21:42] <lamont> would that even work?
[21:43] <lamont> what tcp sessions would not be stored in the new machine's conntrack? (does that only get written when new connections form, or does it care?)
[21:43]  * lamont doesn't want to rebuild his test lab, either
[21:44] <apw> so i would have expected that to have worked as you hope, that as long at the new machine is there long enough that it would pick up the connections, and indeed if you put it
[21:44] <apw> inside, so it only sees the valid ocnnections i _think_ it will intuite the ones which are already existing
[21:45] <apw> so i think i am saying it should be between the old and inside, else it will have established things where it ought to reject maybe
[21:46] <lamont> ah, good point
[21:46] <lamont> yeah, inside then
[21:46] <lamont> I may just see if I can test this out for sure
[21:47] <apw> cirtinaly it has estalished detection for existing connections when it starts watching too
[21:47] <lamont> next question: HTF do I see the conntrack table in a 3.13 kernel?
[21:47] <lamont> the pre-trusty way went away (conntrack in /proc/sys/(
[21:48] <apw> crontrack-tools perhaps
[21:48] <apw> it might be conntrack -L
[21:51] <apw> lamont, conntrack -L seems to do what i think you want
[21:52] <lamont> packagte is conntrack
[21:52] <lamont> cool
[21:52] <apw> yeha i've been doing a lot of cron stuff today, so i keep misstyping
[21:53] <lamont> and the 8-tuple is (src/dst IP/port side A, src/dst IP/port side B), yes?
[21:54] <lamont> actually, established/related requires the full SYN/SYN+ACK/ACK handshake to complete for TCP stuff , yes?
[21:54] <apw> right the two flow directions
[21:54] <apw> i believe there is some recovery for lost entries that could trigger when someone is clearly communicating
[21:55] <apw> but i'd not like to claim to how
[21:55] <lamont> heh
[21:56] <lamont> I'm thnking of the "new guy on the outside" case (since the firewall filters both directions) - if all it saw was the SYN (and old guy then dropped the packet), I would like to think that ESTABLISHED wouldn't make it when that finally got turned on...
[21:56] <lamont> obviously, the sequence would be: turn on firewalling on the new guy, then turn it off on the old guy
[21:57] <apw> lamont, that does sound believeable, so yes likely it works either way