=== Sarvatt is now known as Sarvatt_ === smb` is now known as smb [07:19] * smb yawns [07:46] reboot [08:08] * apw waves [08:09] apw, We were speaking of you but mumble decided you need not to know. :-P [08:58] henrix, Do you have an estimate how soon or late the 3.5.7.14 stable release may make it into Quantal? [08:58] smb: i believe a new SRU cycle is starting this week [08:59] smb: so, it should be in Q in 3 weeks [08:59] henrix, Ah, ok. Thanks. [08:59] smb: (i may be wrong about the SRU cycle... its better to confirm that with bjf or sconklin) [09:01] henrix, Yeah, though it sounds correct as there were a whole lot of activity on tracking bugs. Of course there was also some emergency override, too [09:01] smb: i just checked some IRC logs, and the cycle is starting today [09:02] ok [09:02] smb: so, 3.5.7.14 should be in -proposed later this week, and in -updates in 3 weeks [09:03] henrix, That is enough of an estimate for my purpose (just need to relate that in a bug report) [09:04] smb: cool, so i was able to provide useful information on a monday morning :) [09:04] henrix, :D === fmasi_afk is now known as fmasi [11:37] * ppisati -> out for lunch [12:19] apw, https://launchpadlibrarian.net/142644121/buildlog_ubuntu-saucy-i386.linux_3.10.0-0.5_FAILEDTOBUILD.txt.gz is a weird failure [12:24] rtg_, your latest change to mako made the zImage quite big .... doesnt fit into the 8M boot.img anymore (together with the 2.1M initrd) [12:24] ogra_, drat [12:24] i bumped the boot.img size ... but we should probably take a llook if we can make it lose weight again [12:24] ogra_, so the zImage has to be <= 8M ? [12:24] or is it the combination ? [12:24] no, zImage + initrd has to be <= the partition size for the boot.img ... [12:24] the mako has a slightly bigger partition ... so we can bump it ... but that means special casing per arch now [12:24] ogra_, what is the last version that was small enough ? I don't see any major changes to the configs other then CONFIG_ECRYPT_FS=m [12:24] if it is possible it would be good to stay inside the 8M and not have to special case it ... but if it isnt i guess we have to live with that [12:24] (it doesnt break anything, its just an observation i made and had to react on ... ) [12:25] ogra_, well, it looks like its your choice, e.g., make mako a special case and have ecryptfs, or no special case and no ecryptfs. [12:25] the image of the 15th had no issues ... sadly the builder broke over the weekend so i cant really tell when it grew beyond the 8M ... [12:25] ok [12:25] its likely the ecryptfs change. I seem to remember apw having problems with that [12:25] do all the other arches have ecryptfs support already ? [12:26] maguro cant grow above 8M [12:26] ogra_, yes IIRC [12:26] ok, then we should eb good ... [12:26] *be [12:26] i can live with the special casing if needed [12:26] ogra_, maguro _has_ ecryptfs enabled as a module [12:26] just for grouper and maguro we are bound to the 8M [12:27] ogra_, ok, so shall I leave mako as it is then ? [12:27] yeah, its fine [12:27] ack [12:29] i'm not sure modules help us much btw [12:29] we dont install kernel packages in the image [12:29] ogra_, so we shouldn't have _any_ modules ? [12:30] well, either that or we find a way to deploy modules from outside the image somehow [12:31] i dont think there is ant planning for that yet [12:31] ogra_, what goes into the initrd ? aren't some modules picked up during the formation of the initrd ? [12:31] *any [12:31] no, the initrd is fully generic [12:31] MODULES=list ... without a list [12:31] so ecryptfs is useless as a module ? [12:31] (i.e. MODULES=none ... faked) [12:32] we will have a redonly system root, ecryptfs would be used for homedir/data decryption [12:32] so we dont need it in the initrd [12:32] which means it must be built-in [12:32] but we have no plan for getting the module into the rootfs either atm [12:33] no, it could stay modular, but we would need a way to deploy it [12:33] and that must be reproducable by the porters [12:34] (keeping a module needs planning we dont have in place, not having the module will probably make grouper and maguro explode) [12:35] ogra_, so really you're just thinking out loud ? [12:35] well, loud enough to get some input from you :) [12:35] i wasnty aware its modular in the other kernels ... [12:35] ogra_, I'm easy either way. its a simple config switch [12:36] might be helpful to have some size comparison data [12:36] the initrd is 2.1M currently [12:37] ogra_, if you have MODULES=none then why would the initrd size ever change ? [12:38] it wouldnt ... but if the kernel grows to 6M it will break [12:38] with ecryptfs support builtin [12:39] that makes 6M the effective limit for zImage, right ? [12:39] so knowing how the binary size of zImage differes with it would be good i think [12:39] well, 5.9 ... but yeah [12:39] ok, I can figure that out [12:42] Hi [12:42] I've got some troubles building a current git-kernel via make-kpkg [12:42] However, I thought the version is 3.10.0-rc5 [12:42] is what make-kpkg says to me [12:43] "The changelog says we are creating 3.10.0-rc5+ [12:43] very strange [13:27] larsduesing, that implies there are commits after the actual commit changing the version number, doesn't it ? [13:29] rtg_, i rebased unstable and uploaded it to the pre-proposed ppa [13:29] apw, saw that [13:32] apu - there is a patch applied, yes. [13:40] larsduesing, then the version should be + to tell you that indeed === kentbout is now known as kentb [14:22] sconklin, around? [14:22] joshhunt: yes [14:23] sconklin, hey i was in the process of pulling in the latest USN for 3.2 and noticed the diff/patch seems to be much smaller for the new USN which seems odd to me. https://launchpad.net/ubuntu/+source/linux/3.2.0-44.69 vs https://launchpad.net/ubuntu/+source/linux/3.2.0-48.74 [14:24] i'm referring to the linux...diff.gz files [14:24] looking [14:24] when i diff their contents i notice that a lot of patches which were in the previous patch have been removed. this seems suspicious to me. [14:41] for ex: it looks like all patches to linux-3.2.0/fs/dcache.c are removed in the new USN, which seemed a little odd. [14:58] ogasawara: hi! did I set bug #1191197 correctly? [14:58] Launchpad bug 1191197 in linux-nexus7 (Ubuntu) "kernel config does not support ufw firewall" [Undecided,New] https://launchpad.net/bugs/1191197 [15:01] josepht: the git tree all looks ok, I suspect a packaging error, looking at that [15:01] jdstrand, its more likely going to be an issue of size. ogra tells me that we're already over the 8M limit for the boot image [15:02] though we should be able to enable these as modules [15:02] rtg_: and we aren't going to have modules either? [15:02] modules is fine [15:03] jdstrand, thats the part I'm finding a bit confusing. ogra says we are not using packages for the kernel, so I'm not sure if modules are used. guess I'd better find out. [15:03] not having modules and having a very small kernel is fairly limiting [15:03] we are using packages during the android build ... but not in the ubuntu rootfs [15:04] ogra_, which means nothing to me. will modules get loaded when user space requests ? like udev ? [15:05] no [15:05] and udev wont handle hardware at all [15:05] well then, why have _any_ modules ? [15:05] the android container will, udev startup is held back until ueventd in android is done [15:06] some are needed by the android side [15:06] not sure how we do that, sergiusens or rsalveti could elaborate [15:06] all hardware related bits need to happen in the container [15:07] udev is only used for permissions of devices on the ubuntu side or if needed to set up symlinks [15:07] ogra_, is this in adroid outside/ubuntu inside ... or ubuntu outside/android inside ? [15:08] this is in the flipped container ... android under lxc [15:08] and we have no udev for module loading [15:08] (teh future image we will use hopefully from next week on by default) [15:08] we hold back udev [15:08] the modules need to be loaded from the container [15:08] well, we don't have any solution for the kernel packages yet [15:08] we thought about installing the package during first boot/installer [15:08] rsalveti, how do we get the modules in place atm ? [15:09] but we can't necessarily do that anymore once we have ro rootfs [15:09] on the android side [15:09] ogra_: I think we're copying them over [15:09] k [15:09] * apw is slightly confused as to why modules need to be inside at all [15:09] what we can surely do is set up a link from /lib7modules to /vendor/lib/ [15:10] apw, inside what now ? [15:10] :) [15:10] inside the android lxc [15:10] because thats what ships the binary blobs used in the modules [15:10] and it ships the setup (wpa_supplicant config for example= [15:10] ) [15:11] the ubuntu side only talks to the hardware through platform-api [15:11] ogra_: would that link fix loading via requests from userspace?? [15:11] (and through some /dev entries we have on both sides and sockets) [15:11] jdstrand, well, we will have to teach udev to never load anything, it would just make the modules visible [15:12] (no idea for what though) [15:13] ubuntus udev should only set up device permissions and possible links to make the android device names recognized by a linux system [15:13] jdstrand, if there is a /lib/modules/`uname -a`, then ufw->iptables ought to do the right thing. [15:13] ogra_: well, I'm talking about if I use iptables to add a rule, and it needs to have a module loaded. on the desktop, this happens without any help. if we enable these things as modules, will I need to load them manually or will they autoload? [15:13] nothing should autload [15:13] and they should be loaded from android [15:14] (which doesnt know modprobe) [15:14] I see [15:14] ogra_: do we have an /etc/modules that we can populate? [15:14] we dont really have any plan for that yet :) [15:14] but iptables _does_ know how to insmod [15:14] probably worth a meeting [15:14] ogra_, why does it matter which side of the line (ubuntu/android) that the modules live ? [15:14] apw, races ... [15:15] ogra_, the kernel is there to moderate races surely [15:15] (for things like iptables) [15:15] we have two concurring HW managers running [15:15] and ueventd needs to be the master so we get the android configs [15:16] for iptables (if that works at all with the android networking stack) we might be able to make an exception but would need the link [15:16] I can say that iptables works with JENKINS_BUILD=saucy-11 on mako (unflipped) [15:16] ok, that answers the android network bit :) [15:17] the whoile container flip thing had not had *any* planning so we mostly plan and design on the go [15:17] it does for a lot of things actually, there are just a few kernel configs that we need for ufw to be happy (see aforementioned bug) [15:17] the iptables requirement didnt come up yet [15:18] jdstrand, I'm working on it [15:18] rtg_: cool, thanks [15:18] rtg_, if you are about to do a mako i have a patch i want on it [15:18] apw, ack [15:18] ogra_: I'll check if we're copying the modules over, as that would probably be the way to go anyway [15:19] rtg_: did I use all the right kernels in that bug? [15:19] ogra_: as the image will be ro, the only way to updated would be via the update image process [15:19] I picked linux-nexus4 and linux-nexus7 [15:19] which would flash both the android and ubuntu side [15:19] jdstrand, I'm changing the names to linux-mako and linux-grouper [15:19] and during that flash, we can bring the new kernel and modules [15:19] rsalveti, well, we wont have apt/dpkg anyway [15:19] right [15:19] so flashing is the only option [15:19] rtg_: ok, thanks, noted for the future. I imagine the nexus 10 has the same issue [15:19] ok, I'll check if the copying is indeed happing [15:19] its just that we need to plan that wrt flip [15:20] jdstrand, N10 -> manta [15:20] since i have no idea how to handle that on the ubuntu side yet [15:20] * ogra_ will ponder about that a bit [15:26] it seems that one cannot configure a ifenslaved bond interface as part of a bridge... is this expected? [15:26] sconklin: did you find a problem with the packaging? [15:26] lamont, arges is the expert on that IIRC [15:27] good to know [15:27] still looking, and I asked infinity to have a look' [15:27] sconklin: thx [15:29] lamont: how are you setting this up? and are you seeing dropped packets? [15:29] apw, did you notice that saucy unstable no longer builds for armhf ? [15:30] arges: I am seeing no packets [15:30] as for capturing the config, that'll take me a bit, since well, no internet [15:30] er, network [15:30] lamont: let me see if its similar to a bug i'm looking at [15:31] lamont: pad.lv/736226 [15:31] arges: eth0 and eth1 bonded into a cisco channel-group compatible config, layer2+3, etc. then br0 attemts to have bond0 as a member of the bridge. I see traffic on bond0, but nothing on br0 [15:32] lamont: it could be a matter of disabling arp monitoring, give that a try [15:32] arges: bond is configured as: [15:32] bond-miimon 100 [15:32] bond-mode 4 [15:32] bond-slaves none [15:32] bond-xmit-hash-policy layer2+3 [15:33] bridge is as per that bug [15:33] also vlans over the bond seemed to have issues [15:33] arges: sounds like you would like some more / additional concrete data on the subject? [15:35] rtg_, i did not, will put it on my todo to look at next [15:38] joshhunt: I guess I'm not sure exactly what you're asking about. which specific deltas? 44-45, or 45-48? [15:40] sconklin: i only checked 44-48, but it looks like the same holds true for 45 to 48 [15:40] the diff.gz file size in 45 is 5.3MB where as in 48 it's 3.7 [15:40] MB [15:41] when you extract them both there's a difference of about 7MB [15:41] when i do diff -u linux_3.2.0-44.69.diff linux_3.2.0-48.74.diff [15:41] i see a lot of things removed in the latest diff which were in the .44 diff. i guess that i would see the same if i were to diff the 45 to the 48 as well [15:42] given the change in size [15:42] josepht: so your concern is abotu the size, and not the content of the diffs? [15:42] no my concern is the content [15:42] did you look at the diffs? [15:42] the first clue they were different was the size [15:42] then i diff'd them [15:43] arges, It looks like the fix for bug 1186932 landed in v3.10-rc6. Can you give that kernel a test when you have a chance? [15:43] Launchpad bug 1186932 in linux (Ubuntu Saucy) "Regression: kernel 3.8.0-24 breaks WPA enterprise auth [iwlwifi]" [High,Confirmed] https://launchpad.net/bugs/1186932 [15:43] jsalisbury: cool yea i'll give it a shot [15:44] arges, great, thanks [15:45] sconklin: i'm diff'ing 45 to 48. maybe i am looking at it wrong. [15:46] I don't see how comparing two diffs makes sense, when each one is between to consecutive releases [15:48] kamal: you here? [15:48] sconklin: b/c that will show me what has changed b/t the two releases. and why they are different by 7MB [15:49] one diff shows you what the difference is between two releases. [15:50] two diffs together shows you the difference between three releases, if they're consecutive [15:50] the difference between the diffs doesn't mean anything [15:53] the .diff.gz files you produce are applicable to the vanilla kernel. a diff b/t the two diffs shows what's changed b/t releases. i'm not sure why that doesn't make sense. [15:57] joshhunt, sconklin: for whatever its worth (maybe not much) ... I'm looking at this now also. I do see that the 44.69 diff is quite a bit larger than the 48.74 diff [15:57] sconklin: i think i found the issue. there appears to be a large number of EXPORT_SYMBOLs which were removed. possibly just a cleanup on your side? [15:58] things from linux-3.2.0/debian.master/abi/3.2.0-41.66/armhf/highbank [15:58] tons of removes there [15:58] -+EXPORT_SYMBOL crypto/gf128mul 0x00000000 gf128mul_4k_bbe [15:58] -+EXPORT_SYMBOL crypto/gf128mul 0x00000000 gf128mul_4k_lle [15:59] i'm not familiar with what the debian.master/abi dir contents are for, but it appears this is the main explanation for the size difference [15:59] joshhunt, those list the contents of the abi [15:59] joshhunt, of course when the abi number changes the whole abi directory is removed and replaced by one with a new name [15:59] joshhunt: we did recently discover and delete some old cruft in the ABI directory, but I can't remember off hand which release it was for [15:59] joshhunt, and when the abi is suppressed, it may be empty temporarily in an upload [16:00] joshhunt, sconklin: yup, the only things I see "missing" is just that ... old debian.master/abi files [16:01] yeah a quick du of that dir with both old and new release shows ~7MB difference now. 7.4MB vs 15MB [16:05] thx for your help. the other "changes" i thought i saw can be explained by reordering of the contents of the diff. patches that looked like they had been removed were just found further down in the new patch file. [16:11] joshhunt, forgive if this is old hat to you ... what I did was to run each of the diffs through "lsdiff | sort", thus generating two sorted lists of the files contained in each diff. then I diff'ed those two lists, and the abi changes jumped right out [16:11] kamal: yeah i should have done that first. thx! [16:13] joshhunt, truth be told, there is one other non-abi diff there, but it looks like a source file just got renamed (but I didn't look in detail): [16:13] -linux-3.2.0/fs/lockd/clntproc.c [16:13] +linux-3.2.0/fs/lockd/clntlock.c [16:32] jsalisbury: hey just realized that it was WPA enterprise. I don't have time to setup something here to test, but i'll try to swing by the cafe that had WPA Enterprise to test when i can [16:33] arges, ahh, ok. thanks! I also asked for testing in the bug, so no need to go out of your way [16:40] apw, i noticed last week that we were still doing oneiric mailine builds [16:41] bjf, as in stable against something like 2.6.35 [16:41] apw, i'll try to find it but yes, i think so [16:42] bjf, so i think i would expect us to still build any stable we see, though i am supprised it is still being updated regardless [16:43] bjf, must be one of gregs specials [16:43] apw, so even though we don't support it we'll continue to do those builds? [16:45] bjf, well the point more is to build all the mainline things that come out, that is using an oneiric config as the 'nearest' is the only association with the series [16:45] apw, ack === fmasi is now known as fmasi_afk [17:24] apw, do you remember where gcc checks are enabled in the kernel ? For example, '/ubuntu-saucy/net/netfilter/xt_connbytes.c:23:2: warning: passing argument 1 of 'atomic64_read' discards 'const' qualifier from pointer target type [enabled by default]' [17:27] * rtg_ -> lunch [17:28] greping for the -f option for that thing will find the bit which it checks for them [18:01] apw, I found it. I was looking at the wrong include file. doh! http://permalink.gmane.org/gmane.linux.kernel.commits.head/326441 === alexbligh1 is now known as alexbligh [20:26] * rtg_ -> EOD === BenC_ is now known as BenC