[00:22] <BenC> apw: Two patches sent to mailing list
[07:55] <apw> BenC, thanks
[08:33] <AceLan> apw: Hi, is there a wiki page describes the SRU kernel release schedule? I would like to know when I'll have a fixed (proposed) kernel if I submit a SRU now.
[08:33] <apw> AceLan yeah there is, hang on
[08:52]  * AceLan is trying to find the reset button on apw, looks like he hangs
[08:52] <apw> AceLan, i am more going a bit mad trying to find it :)
[08:52] <apw> http://people.canonical.com/~kernel/reports/sru-report.html
[08:53] <apw> that is part of the story, what is currently where and verified
[08:53] <apw> plus ...
[08:54] <AceLan> hmm
[08:56] <apw> AceLan, the other part i get as email and in the IRC report, but i suspect it is also out there somewhere too
[08:57] <apw> though this cycle does not appear to have beeen announced
[08:59] <AceLan> apw: are there dates about the SRU freeze, testing, and release?
[09:00] <apw> AceLan, yes there are
[09:00] <AceLan> apw: on wiki? or only in email?
[09:01] <apw> i am sure it is in the wiki, i cannot find it right now there, the latest dates were in the transcript of yesterdays meeting which is on email
[09:01] <apw> and normally he emails them to kernel-sru-announce but does nto appear to have done so this cycle
[09:01] <apw> bjf, ^
[09:03] <AceLan> apw: ok, please keep an eye on it, if you found the wiki, please let me know, thanks
[09:04] <apw> https://lists.ubuntu.com/archives/kernel-sru-announce/2014-April/000015.html
[09:04] <apw> so that was the announce for the previosu cycle
[09:05] <AceLan> apw: cool, I'll keep an eye on that list, thanks
[09:05] <apw> https://lists.ubuntu.com/archives/ubuntu-devel/2014-April/038262.html
[09:05] <apw> that second one has the announced dates per our meeting yesterday
[09:06] <AceLan> apw: thanks a lot
[09:07] <apw> BenC, that makes things much happier ... thanks
[11:12] <BenC> apw: Excellent
[12:18] <ppisati> https://launchpad.net/ubuntu/+source/u-boot-linaro
[12:18] <ppisati> it's in main and it's available for T
[12:18] <ppisati> _but_
[12:19] <ppisati> wget http://ports.ubuntu.com/dists/trusty/main/binary-armhf/Packages.gz
[12:19] <ppisati> zgrep "Package: u-boot" Packages.gz
[12:19] <ppisati> Package: u-boot
[12:19] <ppisati> Package: u-boot-tools
[12:19] <ppisati> no u-boot-linaro there
[12:19] <ppisati> why?
[12:19] <ppisati> and indeed, mt lb build complains:
[12:20] <ppisati> e.g. E: Unable to locate package u-boot-linaro-omap3-beagle
[12:20] <ppisati> *my
[12:20] <ppisati> probably #ubuntu-devel was more appropriate, but anyway
[12:21] <ppisati> infinity: can you help me here? ^
[12:24] <apw> the binaries are all called u-boot-linaro-* ... hmmm
[12:25] <apw> what section are they in though
[12:25] <apw>  u-boot-linaro                    | 2012.08.2-ubuntu1 | trusty/universe  | source
[12:25] <apw> ok this is all in component universe, so you have the wrong Packages.bz file
[12:26] <ppisati> doh
[12:26] <ppisati> Component:*
[12:26] <ppisati> main
[12:27] <apw> apw@bark:~/plusone$ zgrep "Package: u-boot" Packages.gz
[12:27] <apw> Package: u-boot-linaro-ca9x4-ct-vxp
[12:27] <ppisati> https://launchpad.net/ubuntu/+source/u-boot-linaro
[12:27] <apw> Package: u-boot-linaro-efikamx
[12:27] <apw> Package: u-boot-linaro-highbank
[12:27] <apw> [...]
[12:27] <ppisati> *actual publishing details may vary in this distribution, these are just the package defaults.
[12:27] <ppisati> ah
[12:28] <ppisati> bloddy asterisk :)
[12:28] <ppisati> *bloody
[12:28] <ppisati> well, in saucy was in main
[12:28] <ppisati> it was moved to universe in T
[12:29] <ppisati> (/me is blackbelt in finding excuses...)
[12:29] <apw> yep, rmadison is your friend there
[12:29] <ogra_> you are italian ... 
[12:31] <ppisati> soooo
[12:31] <ppisati> lb needs a fix
[12:31] <ppisati> ubuntu-server)
[12:32] <ppisati> ...
[12:32] <ppisati> COMPONENTS='main'
[12:32] <ppisati> that's why it was working before
[12:32] <ppisati> ok
[12:37] <ppisati> ogra_: shhht... i'm "fixing" your rootstock-ng
[12:37] <ogra_> heh
[12:43]  * ppisati go grab a kebab...
[13:12] <ppisati> uhm
[13:12] <ppisati> E: Handler silently failed
[13:12] <ppisati> E: config/hooks/100-preinstall-pool.chroot failed (exit non-zero). You should check for errors.
[13:18] <infinity> ppisati: Oh dear, are you trying to resurrect the icky server preinstalled images?
[13:22] <ppisati> infinity: yes and no - i'm trying to teach rootstock-ng to build ubuntu images for arm boards but in the mean time i need a woarking target for lb thus i'm picking ubuntu-server
[14:49] <sconklin> so apw I should be able to run the latest 'current' image on trusty?
[15:34] <apw> yes, it is built with utopic's config but i am running that here
[16:01] <ppisati> root@luxor:/build# cd chroot
[16:01] <ppisati> root@luxor:/build/chroot# cat etc/apt/sources.list
[16:01] <ppisati> root@luxor:/build/chroot# ls -la etc/apt/sources.list.d/
[16:01] <ppisati> total 8
[16:01] <ppisati> drwxr-xr-x 2 root root 4096 Apr 10 13:10 .
[16:01] <ppisati> drwxr-xr-x 6 root root 4096 Apr 30 12:43 ..
[16:01] <ppisati> root@luxor:/build/chroot# 
[16:01] <ppisati> that might be a problem...
[16:08] <rtg> apw, shall I grab the powerpc64-emb patches ?
[16:26] <apw> i have applied them ?
[16:26] <apw> rtg, 
[16:26] <apw> unless that doesn't mean the 2 benc sent this morning
[16:26] <apw> and they work too
[16:28] <apw> rtg, and i switched the base version to 3.15 cause we were still making binary packages with 3.14 as the name
[16:28] <rtg> apw, nm re: powerpc. I just forgot to update.
[16:28] <apw> ahh
[16:31] <niluje> where and when the /run is mounted?
[16:31] <ogra_> in the initrd 
[16:31] <rtg> cking, uploaded sysvinit_2.88dsf-41ubuntu7
[16:31] <ogra_> first thing it does
[16:32] <cking> rtg, /me tries it
[16:32] <rtg> cking, it'll take a bit to percolate into the archive
[16:32] <cking> doh, too eager is me
[16:33] <ogra_> niluje, /usr/share/initramfs-tools/init
[16:33] <niluje> hm
[16:36] <niluje> thansk ogra_ 
[16:51] <niluje> ogra_: are you sure?
[16:51] <niluje> isn't it mounted by init?
[16:51] <niluje> my problem: I create a process in the initramfs that I want to exclude from the killing process of init when the system reboots or shutdowns
[16:52] <niluje> I need to write the PID of the process in /run/sendsigs.omit.d/
[16:52] <apw> so can't that process put itself in there ?
[16:52] <niluje> nope
[16:53] <apw> why so
[16:53] <niluje> the process is nbd-client and is used to mount the rootfs
[16:53] <niluje> at the time the process is created /run doesn't exist yet
[16:53] <apw> why not?
[16:53] <niluje> ?
[16:53] <apw> i thought we mounted /run on the initramfs /
[16:53] <niluje> because init hasn't been called?
[16:53] <apw> and real / on /root
[16:54] <apw> and then move mounted /run into /root before pivoting into it
[16:54] <apw> so if you are staring it before mounting real / you must have it in the initramfs and thus after the /run is made
[16:55] <niluje> hm
[16:55] <niluje> calling "mount" after the rootfs is mounted doesn't list the /run
[16:55] <niluje> (in the initramfs)
[16:56] <apw> check out cat /proc/mounts, i'd not trust mtab
[16:56] <niluje> mtab?
[16:56] <apw> mount just tells you what mtab the userspace copy of the mount table says
[16:57] <apw> and that is often a lie in this two roots sceario
[16:57] <niluje> ok
[16:57]  * niluje still has a lot to learn :p
[16:57] <apw> but if you look at the initrd /init which is just a shell script, it mounts /run
[16:58] <niluje> http://pastebin.com/W6jij8dD
[16:58] <apw> and then we do this to move it into the real root before pivot
[16:58] <apw>         mount -n -o move /run ${rootmnt}/run
[16:58] <niluje> seem to be the same
[16:58] <apw> where in the initramfs handling are you doing this
[16:59] <apw> and actually what release
[16:59] <niluje> scripts/init-bottom
[16:59] <niluje> ubuntu 14.04
[16:59] <apw> as we mount /sys /proc /dev/pts and then /run
[17:00] <apw> and during init-bottom it is mounted still and not yet moved
[17:01] <niluje> wait
[17:01] <niluje> I think I just understood something I should have known :p
[17:01] <niluje> where is the move from /root/run to /run and from /root to / ?
[17:02] <apw> /run is on /run in the initramfs and your root is /root
[17:03] <apw> last thing we do is move mount /run to /root/run (so the files stay in there)
[17:03] <apw> and chroot into /root (approximatly)
[17:03] <niluje> hm ok
[17:04] <niluje> so in what hook should I put the nbd-client pid in /root/run/sendsigs.omit.d/ ?
[17:04] <apw> you hsould put it in /run/sendsigs.omit.d/ in init-bottom
[17:04] <apw> and that will be /run on the real root "later"
[17:04] <apw> in theory
[17:04] <niluje> ok
[17:05] <niluje> cannot it be done sooner than init-bottom?
[17:05] <apw> i thought that was where you started the thing
[17:05] <niluje> sorry, we misunderstood
[17:05] <niluje> I start the process in scripts/local-top
[17:05] <apw> /run should be there for all of the hooks by the looks of it
[17:08] <apw> niluje, i am confused if i boot this machine here and 'break=bottom' i can see /run mounted in /proc/mounts
[17:15] <niluje> :/
[17:17] <xnox> cking: got down to the installer issues - efibootmgr upstream are working on supporting/generating entries for 1.1a devices, and i've sent patch for grub-mkdevicemap to colin which makes ubiquity/d-i just work with current efibootmanager and 1.0 devices.
[17:17] <apw> rtg, just pushed and aufs update, seems to work again
[17:17] <cking> xnox, cool, and I now have some working H/W again 
[17:17] <xnox> cking: grub fix is not in utopic/trusty yet, but once it's in utopic i'll Shepard it for SRU to trusty.
[17:18] <xnox> cking: oh, excellent =)
[17:18] <cking> xnox, ping me when it's ready to test and I'll get around to it
[17:18] <cking> Asap
[17:18] <xnox> cking: cool!
[17:18] <cking> xnox, I spent most of this afternoon breathing life back into my setup,  had various firmware issues and a dead box that wouldn't boot, so this is quite timely :-)
[17:32] <xnox> cking: since grub is actually part of life-fs / debian-installer, and is executed from /target, i have no easy way for you test this until we spin an image with fixed up grub.
[18:46] <infinity> ... why do I seem to need to pass "nolapic" on my kernel cmdline to boot a trusty kernel in qemu/kvm?  I must be doing something wrong.
[18:46] <infinity> Cause otherwise everyone would be complaining.
[18:48] <rtg> infinity, hmm, I run trusty kernels all the time using virt-manager on a trusty host (though I'd better re-check that just to be sure)
[18:50] <rtg> yup, works fine
[18:50] <infinity> rtg: I wonder if maybe grub2 pulls some magic here.  I needed "nolapic" to boot it raw with -kernel and to boot it from grub1 (don't ask).
[18:50] <infinity> rtg: Can you confirm that a raw boot with -kernel vmlinuz-3.13.0-24 also fails for you?
[18:50] <infinity> rtg: Cause if not, I'm doing something odd.
[18:50] <infinity> (Also -enable-kvm -cpu host)
[18:50] <rtg> I've just got grub-pc
[18:51] <infinity> Maybe setting the CPU emulation lower would also "fix" it.
[18:51] <rtg> copy host CPU configuration ?
[18:57] <infinity> rtg: "-cpu host" is that, yes.
[19:00] <infinity> rtg: http://lucifer.0c3.net/~adconrad/Screenshot%20from%202014-04-30%2012:59:35.png <-- That's what I see if I boot without nolapic.
[19:01] <infinity> rtg: (Well, what I really see is that it reboot there and loops, but the tail end of my qemu commandline prevents that)
[19:04] <rtg> infinity, is this a new qemu in utopic ? looks like slightly different versions between trusty and utopic. I assume trusty _used_ to boot without the APIC setting ?
[19:05] <infinity> rtg: This is the trusty one.
[19:05] <infinity> Well, trusty-updates/uptopic-release, same version.
[19:06] <infinity> Maybe the one in -proposed fixes this. :P
[19:06]  * infinity upgrades to see.
[19:06] <rtg> I'm just running tip of trusty -updates
[19:06] <infinity> Right, so same version as me.
[19:07] <infinity> I'm on utopic, but that shouldn't matter here.
[19:08] <apw> rtg, are you running a 3.13 kernel, or some home brew
[19:09] <rtg> apw, stock trusty
[19:10] <rtg> 3.13.0-24-generic
[19:11] <apw> not that then
[19:13] <infinity> Very confusing, this is.
[19:13] <infinity> I'd like to at least see if someone else can reproduce it so I know I'm not crazy. :P
[19:13] <infinity> I suppose it may be specific to my hardware.
[19:13] <apw> as you are passing through your cpu, yes
[19:13] <infinity> But weird that I can boot my actual laptop fine without nolapic, and then the KVM-emulated version of same doesn't work.
[19:14] <infinity> apw: Yeah, I tried with a more generic -cpu and same issue, though.
[19:14] <infinity> (But -enable-kvm in both cases)
[19:17] <infinity> ... and if I disable KVM, and feed it a -cpu that should be 64-bit, it tells me it's not.  Man, I love qemu.
[19:18] <infinity> Oh, FFS>
[19:19] <infinity> lrwxrwxrwx 1 root root 25 Feb  9  2013 /etc/alternatives/qemu -> /usr/bin/qemu-system-i386
[19:19] <infinity> THANKS HALLYN.
[19:19] <infinity> rtg: Fixed by running qemu-system-x86_64
[19:19]  * infinity sighs.
[19:19] <infinity> How the heck -i386 "works" when I pass through my host CPU and turn off local APIC, I don't know.
[19:19] <infinity> But x86_64 works better. :P
[19:20] <infinity> hallyn: Why is the default qemu alternative on amd64 pointing to i386?
[19:20] <rtg> infinity, i386 likely doesn't have an APIC. I wonder how you got linked to the wrong binary ?
[19:21] <infinity>   4            /usr/bin/qemu-system-i386           20        manual mode
[19:21] <infinity>   24           /usr/bin/qemu-system-x86_64         10        manual mode
[19:21] <apw> how the heck did we manage that
[19:21] <infinity> Because i386 has a higher prio.
[19:22] <apw> yeah but how the heck did they not have the same... sigh
[19:22] <rtg> rtg@gbyte:~/linux/linux-firmware$ ls -l /etc/alternatives/q*
[19:22] <rtg> lrwxrwxrwx 1 root root 25 Mar  3 17:26 /etc/alternatives/qemu -> /usr/bin/qemu-system-i386
[19:22] <infinity> They shouldn't be the same, x86_64 should be 20 on amd64 and 10 on i386, and vice versa on the other.
[19:22] <infinity> But they sure aren't.
[19:22] <infinity> hallyn: Plsfix.  I just wasted precious time thinking I was crazy.
[19:23] <rtg> infinity, note that I _only_ have i386, which doesn't make sense
[19:23] <infinity> rtg: Hrm?  You have both installed, surely, and your fancy virt-manager is calling qemu-system-x86_64 directly, not "qemu".
[19:24] <infinity> rtg: I call "qemu" cause I'm a lazy typist, which led me to this pain. :P
[19:24] <rtg> infinity, that is possible. I never use qemu from the CLI
[19:24] <rtg> (too lazy)
[19:25] <rtg> qemu-system-x86 must have both arches ?
[19:26] <infinity> It does, yes.
[19:26] <infinity> Which means its postinst needs to be more clever about the alternatives.
[19:27] <infinity> Cause the "qemu" binary is effectively useless.
[19:27] <infinity> Though, fun to see that a 686-class motherboard with my i7 CPU jammed in "works" with nolapic. :P
[19:29] <infinity>       # Set i386 as highest priority,
[19:29] <infinity>       # as it has been the default qemu for quite some time.
[19:29] <infinity>       case $arch in i386) prio=20;; *) prio=10;; esac
[19:29] <infinity> And evidently, this is intentional.
[19:30] <infinity> </3
[19:30] <rtg> seems like most folks using qemu are also likely to be running a 64bit host
[19:31] <rtg> these days
[19:31] <infinity> Well, I'd contend that the priority should just be set to match userspace.
[19:31] <infinity> So, people like Colin would get the wrong one.
[19:31] <infinity> But everyone else would get what they expect.
[19:31] <infinity> (Colin runs i386 userspace on amd64 kernels)
[19:31] <rtg> seems reasonable
[19:51] <hallyn> infinity: mjt feels pretty strongly about noth aving that be doen as an atlernative
[19:52] <infinity> hallyn: Bleh.
[19:52] <hallyn> not sure if there is a better way to get waht we really want...
[19:52] <infinity> hallyn: That makes /usr/bin/qemu pretty much useless to most 64-bit users.
[19:52] <infinity> hallyn: And certainly surprisingly confusing.
[19:53] <infinity> hallyn: Having /usr/bin/qemu be a wrapper that checks the running kernel (not userspace) and picks the most appropriate emulator as default would probably actually be the best.
[19:53] <hallyn> i thought /usr/bin/qemu hadn't existed for awhile already.  i dont' have it in precise
[19:53] <infinity> hallyn: I have it in trusty/utopic...
[19:53] <hallyn> /usr/bin/kvm is arlready a wrapper, though not as smart as thought
[19:53] <hallyn> as that*
[19:56] <hallyn> infinity: shall i revert the removal oft the alternative?
[19:56] <infinity> hallyn: Err, it wasn't removed?
[19:56] <hallyn> i think actuall colin's case might be an example of where it *is* an alternative,
[19:56] <infinity> hallyn: I've done nothing special here, your postinst sets up this alternative.
[19:56] <sconklin> stgraber, arges that kernel crash in conntrack is also reproduceable on Linus's tip
[19:57] <arges> sconklin: cool did you get a reliable reproducer and/or crashdump?
[19:57] <hallyn> infinity: aiui the whole point is that the alternatives are *removed* in utopic;  
[19:57] <hallyn> or, did i not take that change?  i thought i rejected it for trusty, and i haven't knowingly taken it for u
[19:58] <infinity> hallyn: utopic and trusty are the same version...
[19:58] <infinity> hallyn: And in both cases, the alternative is there.
[19:58] <infinity> hallyn: And pointing to i386 on my amd64 system.
[19:58] <hallyn> well, there's a one-lien change in utopic, probably still in -proposed
[19:58] <infinity> hallyn: Hence my incredible confusion.
[19:58] <hallyn> hm
[19:58] <hallyn> then i don't know whence the change
[19:59] <sconklin> arges: we have a reliable reproducer but it's not very portable outside our environment. I pasted all the stack traces into both the Ubuntu and kernel.org bug reports. If you have anything you want us to try, we can probably do it
[19:59] <hallyn> (meaning it's inadvertant) 
[20:01] <hallyn> ok, so postinst-in has
[20:01] <hallyn>       # Set i386 as highest priority,
[20:01] <hallyn>       # as it has been the default qemu for quite some time.
[20:01] <hallyn> which i seem to recall being the case even prior to precise...
[20:02] <infinity> hallyn: Sure, it's entirely possible I've never run "qemu" on this machine before now. :)
[20:02] <infinity> hallyn: Doesn't change that the default being something that can't boot my arch is rather surprisingly confusing.
[20:03] <hallyn> ok - sorry i thought you were saying something had changed
[20:03] <infinity> hallyn: No.  I don't think anything's changed, I just think it's wrong.
[20:03] <hallyn> so it soudns like the best way forward is in fact to proceed with dropping the /usr/bin/qemu alternative, andwrite an intelligent wrapper
[20:03] <hallyn> mjt agrees with you :) 
[20:04] <hallyn> heck i dno't knwo when it was introduced, bc indeed precise does nto have it (which is why my box doesn't have /usr/bin/qemu)