| === Sarvatt is now known as Sarvatt_ | ||
| === smb` is now known as smb | ||
| * smb yawns | 07:19 | |
| ppisati | reboot | 07:46 |
|---|---|---|
| * apw waves | 08:08 | |
| smb | apw, We were speaking of you but mumble decided you need not to know. :-P | 08:09 |
| 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:58 |
| 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) | 08:59 |
| 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:01 |
| 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:02 |
| smb | henrix, That is enough of an estimate for my purpose (just need to relate that in a bug report) | 09:03 |
| henrix | smb: cool, so i was able to provide useful information on a monday morning :) | 09:04 |
| smb | henrix, :D | 09:04 |
| === fmasi_afk is now known as fmasi | ||
| * ppisati -> out for lunch | 11:37 | |
| rtg_ | apw, https://launchpadlibrarian.net/142644121/buildlog_ubuntu-saucy-i386.linux_3.10.0-0.5_FAILEDTOBUILD.txt.gz is a weird failure | 12:19 |
| 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:24 |
| 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:25 |
| 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:26 |
| rtg_ | ogra_, ok, so shall I leave mako as it is then ? | 12:27 |
| ogra_ | yeah, its fine | 12:27 |
| rtg_ | ack | 12:27 |
| 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:29 |
| ogra_ | well, either that or we find a way to deploy modules from outside the image somehow | 12:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| ogra_ | (keeping a module needs planning we dont have in place, not having the module will probably make grouper and maguro explode) | 12:34 |
| 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:35 |
| ogra_ | might be helpful to have some size comparison data | 12:36 |
| ogra_ | the initrd is 2.1M currently | 12:36 |
| rtg_ | ogra_, if you have MODULES=none then why would the initrd size ever change ? | 12:37 |
| ogra_ | it wouldnt ... but if the kernel grows to 6M it will break | 12:38 |
| ogra_ | with ecryptfs support builtin | 12:38 |
| 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:39 |
| 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:42 |
| larsduesing | "The changelog says we are creating 3.10.0-rc5+ | 12:43 |
| larsduesing | very strange | 12:43 |
| apw | larsduesing, that implies there are commits after the actual commit changing the version number, doesn't it ? | 13:27 |
| apw | rtg_, i rebased unstable and uploaded it to the pre-proposed ppa | 13:29 |
| rtg_ | apw, saw that | 13:29 |
| larsduesing | apu - there is a patch applied, yes. | 13:32 |
| apw | larsduesing, then the version should be + to tell you that indeed | 13:40 |
| === kentbout is now known as kentb | ||
| joshhunt | sconklin, around? | 14:22 |
| sconklin | joshhunt: yes | 14:22 |
| 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:23 |
| 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:24 |
| 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:41 |
| 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 | 14:58 |
| 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:01 |
| 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:02 |
| 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:03 |
| rtg_ | ogra_, which means nothing to me. will modules get loaded when user space requests ? like udev ? | 15:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| ogra_ | (no idea for what though) | 15:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 | |
| 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:26 |
| lamont | good to know | 15:27 |
| sconklin | still looking, and I asked infinity to have a look' | 15:27 |
| joshhunt | sconklin: thx | 15:27 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| apw | rtg_, i did not, will put it on my todo to look at next | 15:35 |
| sconklin | joshhunt: I guess I'm not sure exactly what you're asking about. which specific deltas? 44-45, or 45-48? | 15:38 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| jsalisbury | arges, great, thanks | 15:44 |
| joshhunt | sconklin: i'm diff'ing 45 to 48. maybe i am looking at it wrong. | 15:45 |
| sconklin | I don't see how comparing two diffs makes sense, when each one is between to consecutive releases | 15:46 |
| 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:48 |
| sconklin | one diff shows you what the difference is between two releases. | 15:49 |
| 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:50 |
| 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:53 |
| 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:57 |
| 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:58 |
| 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 | 15:59 |
| kamal | joshhunt, sconklin: yup, the only things I see "missing" is just that ... old debian.master/abi files | 16:00 |
| joshhunt | yeah a quick du of that dir with both old and new release shows ~7MB difference now. 7.4MB vs 15MB | 16:01 |
| 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:05 |
| 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:11 |
| 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:13 |
| 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:32 |
| jsalisbury | arges, ahh, ok. thanks! I also asked for testing in the bug, so no need to go out of your way | 16:33 |
| bjf | apw, i noticed last week that we were still doing oneiric mailine builds | 16:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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 | 16:45 |
| === fmasi is now known as fmasi_afk | ||
| 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:24 |
| * rtg_ -> lunch | 17:27 | |
| apw | greping for the -f option for that thing will find the bit which it checks for them | 17:28 |
| rtg_ | apw, I found it. I was looking at the wrong include file. doh! http://permalink.gmane.org/gmane.linux.kernel.commits.head/326441 | 18:01 |
| === alexbligh1 is now known as alexbligh | ||
| * rtg_ -> EOD | 20:26 | |
| === BenC_ is now known as BenC | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!