[00:00] <bulletxt|2> thanks sbeattie
[00:00] <sarnold> sbeattie: wow that's cool
[00:00] <wxl> wow i did NOT know about lkddb sbeattie thanks!
[00:00] <bulletxt|2> any way to understand if ubuntu ever backported it to the  3.13, or 3.16 series?  even 3.19 would be fine
[00:00] <sarnold> way easier than hunting through git trees :)
[00:00] <sbeattie> rando googling for the win (TIL also)
[00:00] <wxl> bulletxt|2: why not ask if you can get the kernel that includes the support you're looking for?
[00:01] <bulletxt|2> im on 12.04 and for the moment I cant upgrade
[00:01] <wxl> 12.04 is still supported
[00:01] <bulletxt|2> I cant install 4 series can I ?
[00:01] <sarnold> it'd be best to test on a staging machine before production but I'd expect it to work
[00:02] <bulletxt|2> I tried installing 4.4 but it complains it cant find kmod package
[00:02] <wxl> bulletxt|2: linux-generic-lts-xenial will get you 4.4
[00:02] <bulletxt|2> reallyé
[00:02] <bulletxt|2> ?
[00:02] <bulletxt|2> let me check
[00:02] <wxl> yuup
[00:03] <wxl> were you otherwise trying to compile 4.4 yourself?
[00:03] <sarnold> that's probably only available on 14.04 LTS
[00:03] <wxl> oh derp
[00:03] <wxl> sorry
[00:03] <wxl> i take it back
[00:03] <bulletxt|2> yea
[00:03] <wxl> precise not trusty :(
[00:03] <bulletxt|2> yea :(
[00:03] <sarnold> but it might still be the easiest way to get there
[00:03] <wxl> you can get 3.13 with linux-generic-lts-trusty but that's not 4.1
[00:04] <bulletxt|2> yea, so the question is, does latest 3.13 have backportd that driver? :)
[00:04] <sbeattie> it does not (just checked)
[00:04] <bulletxt|2> :(
[00:04] <bulletxt|2> sbeattie: what about 3.16 or 3.19 ?
[00:04] <wxl> you could request an SRU (yeah, i doubt it)
[00:05] <wxl> or you could just upgrade the version
[00:08] <sbeattie> looks like the 3.19 kernel(vivid/linux-lts-vivid) has it backported; *however* that kernel is not officially supported by the kernel team anymore.
[00:09] <bulletxt|2> 3.19? really? that because I can install this on 12.04  http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.19.8-vivid/
[00:10] <bulletxt|2> when was that backported?
[00:10] <bulletxt|2> because this actually is newer, http://kernel.ubuntu.com/~kernel-ppa/mainline/linux-3.19.y.z-review/current/
[00:10] <bulletxt|2> not sure what's the differenfe thoughù
[00:11] <sbeattie> mainline == upstream's 3.19 kernel != the ubuntu kernel team's kernel
[00:11] <bulletxt|2> mm
[00:11] <wxl> i mean if you don't care about it being supported there's quite a few ways you could probably go
[00:12] <bulletxt|2> for example?
[00:12] <wxl> compile it yourself, maybe search for ppas, etc.
[00:14] <bulletxt|2> wxl: intel seems to offer source   https://downloadcenter.intel.com/product/82185/Intel-Ethernet-Connection-I219-LM
[00:14] <bulletxt|2> but I cant even compile that doing "make"
[00:14] <bulletxt|2> not sure what im doing wrong
[00:15] <wxl> heh
[00:16] <wxl> well if i click on linux for OS, it gives me stuff for freebsd :)
[00:16] <bulletxt|2> it says OS linux... not sure what intel is doing on that page..
[00:17] <wxl> https://downloadcenter.intel.com/download/17509/Intel-Network-Adapter-Gigabit-Base-Driver-for-FreeBSD-?product=82185
[00:17] <sbeattie> (For the record, this was the commit in the vivid 3.19 kernel that added support for it https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/vivid/commit/drivers/net/ethernet/intel/e1000e/hw.h?id=bb198e17affadccf6273253b295dbf100e367b56 )
[00:17] <bulletxt|2> thanks
[00:17] <sbeattie> (sorry, wrong url, https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/vivid/commit/?id=bb198e17affadccf6273253b295dbf100e367b56 )
[00:18] <bulletxt|2> who knows if the ubuntu kernel ppa team put that too
[00:18] <sbeattie> it's not going to be in the 3.19 mainline kernel
[00:19] <bulletxt|2> yea
[00:19] <sbeattie> also, 12.04 has about 1 more month of maintenance left to it.
[00:19] <bulletxt|2> yea :S
[00:19] <wxl> there's the "connections cd" which is supposedly os independent, but they only list red hat for supported linux systems
[00:20] <bulletxt|2> I could try that
[00:20] <sbeattie> moving to 14.04 and the linux-lts-xenial kernel would get you to a kernel/OS combination that will be maintained for 2 more years.
[00:20] <sbeattie> that will support your hardware.
[00:20] <wxl> oh sorry, that's for FCoE
[00:21] <wxl> given that it's a "CD" that suggests an ISO
[00:21] <wxl> which would make sense for something "OS independent"
[00:24] <bulletxt|2> wxl: so its not ok for me?
[00:24] <bulletxt|2> oh well
[00:24] <bulletxt|2> Ill just try
[00:28] <bulletxt|2> thanks for the moment to everyone!
[00:28] <bulletxt|2> have a nice day
[01:53] <smoser> bdmurray, my cloud-init bug referenced a security bug
[01:53] <smoser> err.. cloud-init upload
[01:54] <smoser> not a private one, a security one. it isn't particularly necessary to be security, but i would have expected that is allowed.
[01:57] <slangasek> smoser, bdmurray: I spoke with jgrimm about this; we do expect that by the time a bugfix is pushed to a public queue, the bug is also public, and the process doesn't really allow for verification of bugs that the scripts can't see
[01:58] <smoser> slangasek, tahts fine. i can just make it public
[01:58] <slangasek> smoser: I understand this bug may or may not be made public, but we expect there to be /a/ public bug for tracking this issue
[01:59] <smoser> thats fine. i didn't realize that.
[01:59] <smoser> bug is set public now
[01:59] <smoser> .
[02:00] <slangasek> ok
[02:00] <smoser> rharper, found an issue so i'm not going to re-upload at the moment :-(
[02:00] <slangasek> well, I was going to rescue it from the rejected queue anyway
[02:00] <slangasek> but if there's a known issue, I won't do that ;)
[02:02] <smoser> slangasek, if you're looking for work, and want to start your reviewing of it, that is perfectly fine
[02:02] <smoser> i dont expect anything other than this one issue to change.
[02:02] <slangasek> smoser: is it fine to accept the current version, or should I wait for the upload?
[02:02] <slangasek> (I started reviewing much earlier)
[02:03] <smoser> don't accept it.
[02:04] <slangasek> ok
[02:05] <slangasek> smoser: this version also includes the ds-identify sleep, which AIUI is to be dropped?
[02:06] <smoser> it doesnt hurt much.
[02:07] <smoser> ie, having that support doesnt cause any real issues. it just wont be used
[02:08] <smoser> slangasek, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/318975
[02:08] <smoser> that is the one change that i think we will need.
[02:09] <slangasek> smoser: since it's all part of ds-identify which is new in this upload, I'll trust that is the case
[02:10] <smoser> and on that note, /me goes afk.
[02:46] <jgrimm> thanks smoser, hope you are feeling better
[04:13] <tsimonq2> infinity, slangasek: So patch pilot is no longer a thing, or did the calendar move?
[04:55] <slangasek> tsimonq2: I'm not aware of any calendar moving; which one were you looking at?
[04:56] <tsimonq2> slangasek: https://calendar.google.com/calendar/embed?src=6k1e5rq45m1bdqq0n1ge3oqaok%40group.calendar.google.com&ctz=America/Chicago
[04:56] <slangasek> tsimonq2: we probably do have less than perfect coverage on it, however, since the person who managed it is no longer at Canonical
[04:56] <tsimonq2> slangasek: I miss Daniel :(
[04:56] <slangasek> so it's possible no roster was set beyond Feb
[04:56] <tsimonq2> (yes I know who you're talking about :P)
[04:58] <tsimonq2> slangasek: Ok, well I found it very useful to have a person in here who I can ping and ask questions to.
[04:58] <tsimonq2> slangasek: I understand the attendance wasn't good, but the couple of people who did end up doing it were really helpful. ;)
[04:59] <slangasek> tsimonq2: people are not immune to pinging just because their name isn't in the channel topic ;)
[04:59] <slangasek> (but if you ping me now, I'm going to be unhelpful, as I have a one-year-old to go put to bed in the next few minutes)
[05:00] <tsimonq2> slangasek: Sure they aren't, but it's saying, "I am setting aside some time to look at patches and go through the sponsorship queue" - I guess that's more inviting than pinging someone who might be working on something else.
[05:00] <tsimonq2> slangasek: <3
[05:03] <tsimonq2> slangasek: I guess I wanted to ping you and Adam because I was hoping someone could send an email or take the time to fill in for Daniel on managing the Patch Pilot roster (not saying you or Adam should do it, bringing up the usefulness of it).
[05:05]  * tsimonq2 's thoughts are a bit jumbled at the moment, I need some sleep
[05:05] <tsimonq2> But otherwise I just wanted to send a ping :)
[05:05] <tsimonq2> slangasek: Have a good night :)\
[12:24] <bulletxt|2> wxl:         sbeattie:       at the end, what I am attempting now is to compile vanilla 4.4 kernel on ubuntu 12.04 :)
[12:24] <bulletxt|2> following this simple guide http://veithen.github.io/2013/12/19/ubuntu-vanilla-kernel.html
[13:04] <javier4> I'm trying to cross-compile a modified version of the wpa package from amd64 to armhf through sbuild. Every time I make a change to the orig tar or the debian overlay I have to reset the sieze and checksums inside the .dsc file. I need something like this --debbuildopt=--source-option=--nocheck that obviously doesn't work. Anyone?
[14:25] <cjwatson> javier4: in nearly 20 years of Debian-based development I've never had to do this; I am confident you are doing something fundamentally wrong
[14:25] <cjwatson> javier4: you should normally just rebuild the source package using the usual tools, e.g. debuild -S
[14:26] <cjwatson> javier4: do not try to work around .dsc checksum verification; you are on the wrong path
[14:28] <javier4> cjwatson: I have a .dsc, an .orig archive and a debian overlay archive. If I made a change inside one of the two, how can I build without changing the checksums? I normally use
[14:28] <javier4> sbuild -A -d vivid-amd64-armhf --host armhf wpa_2.3-1+deb8u4.dsc
[14:30] <cjwatson> javier4: you should not be editing any of those by hand; you edit the unpacked tree and then use debuild -S to construct a new source package
[14:30] <cjwatson> javier4: all of the files you listed are output files, and editing them directly is a mistake
[14:32] <javier4> should I pass to sbuild the unpacked source tree instead of the .dsc as argument?
[14:33] <cjwatson> you can do that if you like, but you don't have to.  rebuilding the .dsc etc. using debuild -S will work fine (that's what I normally do)
[14:33] <cjwatson> but whatever you do, do *not* hack about with the .debian.tar.* (or .diff.gz) directly, that's a mistake
[14:34] <javier4> cjwatson: debuild will work even for croos-compile?
[14:35] <cjwatson> the .orig.tar.* should come unmodified from upstream and any time it changes then its version number (and hence file name) should also change; the .debian.tar.* and the .dsc are *outputs* of the process of building the source package and are not to be edited manually
[14:35] <cjwatson> javier4: debuild -S means "build a source package", and it is irrelevant whether you're later going to be cross-compiling that source package
[14:36] <cjwatson> debuild without -S would be a binary package build, and is not what I am suggesting
[14:39] <javier4> cjwatson: If I understood: 1) create the debian source tree (orig+overlay unpacked) 2)apply my changes to the tree 3) recreate a new overlay and a new .dsc with debuild -S 4) use these two new files together with the original .orig file to build my package
[14:39] <javier4> right?
[14:43] <cjwatson> javier4: roughly, yes
[14:44] <cjwatson> javier4: use dpkg-source -x foo.dsc to unpack the source tree
[14:45] <javier4> cjwatson: yes I already did it that way. Thanks a lot. :-)
[14:48] <javier4> Another question: I don't wanna lose the edits I already made inside the archives. Could I dpkg-source -x my custom-archives, then substitute the my-custom-.orig with the original one, to make debuild -S put all my editings inside the new overlay that it will create?
[14:48] <cjwatson> you are getting yourself into a dreadful tangle
[14:49] <cjwatson> why were you editing the orig in the first place?
[14:51] <cjwatson> so yes, you probably can do something along those lines, but it sounds like you should take backup copies of everything before going any further
[14:52] <javier4> It's complicated: I have a mediatek-customized wpa source in an android tree. I'm trying to port UbuntuTouch, but it seems that the vanilla wpa doesn't work. Then I'm trying to build the customized version and install it inside the rootfs of Ubuntu Touch.
[14:52] <cjwatson> depending on the source format, you may find that debuild -S makes you transform your changes into patches
[14:52] <cjwatson> but cross that bridge if you come to it
[16:22] <javier4> @cjwatson unfortunately my try failed. It seems that debuild -S tries to apply the patches on the orig.tar.gz (that I substituted with the original one) instead of using the already extracted&patched tree.
[16:22] <udevbot> Error: "cjwatson" is not a valid command.
[16:22] <javier4> cjwatson unfortunately my try failed. It seems that debuild -S tries to apply the patches on the orig.tar.gz (that I substituted with the original one) instead of using the already extracted&patched tree.
[16:26] <cjwatson> javier4: Yes, that's how it works.  It's trying to build a source package based on the given orig and the given source tree.
[16:27] <cjwatson> javier4: I'm afraid I can't help you further right now, though.  I suggest doing some reading - there are lots of manual pages and such describing how the source format works.
[16:34] <tsimonq2> javier4: Did you get it working?
[17:35] <javier4> tsimonq2: Hi Simon. Still learning some man-pages. Perhaps the --no-pre-clean flag dor dpkg-buildpackage could help?
[17:36] <tsimonq2> I'm unsure. What are you attempting at this point?
[17:41] <javier4> Build a deb-source directly from a debian tree instead than from an .orig archive.
[18:07] <tsimonq2> javier4: Like cjwatson said, you should probably use a clean orig tarball and just use debian/patches for any needed modifications.
[18:07] <tsimonq2> javier4: My favorite guide on this: https://raphaelhertzog.com/2012/08/08/how-to-use-quilt-to-manage-patches-in-debian-packages/
[18:07] <tsimonq2> javier4: I'd save whatever changes you had and just use uscan to get a new tarball
[18:08] <tsimonq2> javier4: Then like I said, use debian/patches and try it
[18:08] <tsimonq2> javier4: You can also just cd into the source dir and build it directly from there with sbuild -d CHROOTNAME
[18:12] <javier4> too much work. I'm doing this just as a try that I'm not sure will fix my ubuntu touch problem. I'm already losing too much time, and I'm losing sight of my original objective: ports ub-touch.
[18:30] <tsimonq2> Ok
[18:30] <tsimonq2> javier4: Then it won't build properly
[18:30] <tsimonq2> But I guess that's your choice...
[18:41] <javier4> tsimonq2: I just gave a wuick look at your page: I should give a quilt add for every modified file? No possibilities of making just a diff from origin to mediatek-wpa and make a single commit?
[18:44] <tsimonq2> javier4: Well you can just quilt add everything then apply the diff and you're good
[18:44] <tsimonq2> javier4: So yeah you can do it all in one patch if you want