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