[07:24] <wooo> hey guys I have a doubt about vnode. I think the inode for a specific file system is the vnode for virtual file system. Am I right?
[07:36] <ppisati> moin
[07:49] <wooo> guys please help !!
[07:51] <wooo> hey guys I have a doubt about vnode. I think the inode for a specific file system is the vnode for virtual file system. Am I right?
[09:08]  * apw yawns
[09:20] <ppisati> brb
[10:27] <cnf> apw: package is working now, btw
[10:27] <cnf> apw: ugly, ugly hacks, but it works :P
[10:29] <apw> cnf, send it back, and don't forget the brick
[10:29] <cnf> indeed :P
[10:29] <cnf> and the herpes!
[10:29] <apw> too true
[10:38] <apw> ppisati, well it hasn't crashed yet
[10:38] <apw> ppisati, and none of the 'regular' oopsy things we used to see in dmesg
[10:39] <apw> ppisati, now if you could just add a patch to make teh cpus 4x faster ...
[10:40] <ppisati> apw: just wait for the new panda omap5, i heard it's so awesome (when it comes out) :)
[10:41] <apw> ppisati, heh sounds good, the build will likely still running when they do :)
[13:00] <smb> apw, So just for additional info, it seems that indeed an objdump -g on the raring ddeb gives me nothing while it seems still ok for the vmlinux file. But the modules in debian/build seem to be stripped already. Got a log of that build to look at
[13:01] <apw> smb, ok ... likely it is something to do with module signing, so perhaps i should poke it ?
[13:01] <apw> that alll caused chaos when we first added it, as it changes where things are
[13:02] <smb> If you have the time. I may have a bit too, but then I have not looked into the whole signing issue the first place
[13:11] <jjohansen> bjf: I'll be in at about 7:30
[13:14] <smb> apw, Hm, CONFIG_DEBUG_INFO seems to be gone
[13:15] <smb> ah no
[13:15] <smb> still there
[13:15] <ogra_> its stable enough now ... screw debugging
[13:17] <smb> apw, Interestingly only amd64 =y i386 =n
[13:24] <apw> smb, doh ... will look into it ...
[13:24] <smb> apw, more doh... the same vmlinux has output on the raring objdump -g but nothing on precise objdump -g
[13:26] <smb> apw, probably whatever that output is, its not the things I tried to look for
[14:16] <ppisati> apw: is your panda still ok?
[14:18] <apw> ppisati, yes and no panics indeed no dmesg messages since 13s after boot
[14:18] <apw> ppisati, and it has been up 4 hours
[14:18] <ppisati> apw: nice, then we can safely assume that patch fixed it
[14:18] <apw> ppisati, i would say so, about 15m was the best i got before
[14:18] <rtg_> ppisati, apw is that with a DT kernel ?
[14:19] <apw> rtg_, thats the 'unified' kernel
[14:19] <rtg_> DT == device tree kernel
[14:19] <ppisati> rtg_: our img don't use DT by default
[14:19] <ppisati> rtg_: but if you modify the uEnv.txt, it works
[14:19] <apw> but they are unified :)
[14:19] <rtg_> cool
[14:21] <rtg_> apw, on a different topic, shouldn't 'apt-get autoremove' be removing old kernel in raring ?
[14:21] <apw> rtg_, if you didn't install them by hand yes
[14:21] <rtg_> hmm
[14:22] <rtg_> apw, ok, looks like it removes them but doesn't purge them
[14:23] <apw> rtg_, does headers or image contain anything a purge would make go away any harder
[14:23] <rtg_> apw, huh ? a 'dpkg -P' makes the listing go away
[14:23] <apw> ahh you mean you can still see the old package names yeah
[14:25] <rtg_> apw, so, some are marked 'rc', but most are still 'ii'. the 'ii' kernels are the ones I would expect to get removed, but I may have installed them by hand
[14:25] <apw> righjt if you installed it by hand, then it is marked as permenant
[14:26] <rtg_> apw, I've seen them cleanup on gomeisa and tangerine, so that capability must have been backported
[14:26] <apw> apt-mark showmanual linux-\*
[14:26] <apw> rtg_, yes it has, that will show which it thinks you installed manually
[14:27] <apw> rtg_, yes it has, that will show which it thinks you installed manually
[14:27] <apw> apt-mark showmanual linux-\*
[14:32]  * smb thinks there is a flaw in the matrix
[14:42] <apw> yeah :)
[14:48] <rtg_> 3.9 is telling me my SB server is insane. arch/x86/kernel/smpboot.c:324 topology_sane.isra.2+0x6f/0x80()
[14:48] <rtg_> sched: CPU #1's llc-sibling CPU #0 is not on the same node! [node: 1 != 0]. Ignoring dependency.
[15:34] <xnox> reboot syscall supports passing a string which is used as rebootcommand further down the stack. Thus for example on nexus7 one can "reboot bootloader" to reboot into fastboot/flashing mode.
[15:34] <xnox> is there any way to discover supported reboot commands from the running kernel/sysfs/etc?
[15:35] <xnox> Because we may want to expose these features to the user in the future of e.g. UEFI Fastboot modes and/or booting multiple operating systems on devices (e.g. reboot into recovery)
[15:36] <xnox> apw ^ would you know about this?
[15:36]  * xnox got lost in per-arch trees in the kernel sources.
[15:45]  * ogasawara back in 20
[16:11] <avoine> ppisati: Hi, if you have 2 min, I would like to test your multi-plateform kernel on a imx6 board and I have some questions about the installation.
[16:11] <ppisati> avoine: i'm here, shot
[16:11] <avoine> Do you know if there is some documentation about the u-boot part? 
[16:11] <avoine> Right now, I have the linaro's U-boot and image installed from here: https://wiki.linaro.org/Boards/MX6QSabreLite
[16:12] <avoine> but I think it won't work unless I update the u-boot for ubuntu
[16:15] <ppisati> avoine: we never released an official ubuntu img for imx6
[16:16] <ppisati> avoine: do you have uboot on imx6's flash? and do you read the kernel from sd?
[16:16] <ppisati> avoine: if yes, you should be ok
[16:17] <avoine> yeah it boot from SD
[16:17] <avoine> ppisati: ^
[16:18] <avoine> ppisati: ok, I'll try to update the kernel to the latest one and see if it boot
[16:19] <ppisati> avoine: would you use the .deb? or would you build the zimage from src?
[16:19] <avoine> ppisati: the deb
[16:19] <ppisati> avoine: in the first case, flash-kernel will complain (-omap doesn't match your arch)
[16:20] <ppisati> avoine: so be aware that you need some hacking on it
[16:20] <ppisati> avoine: ping me and i'll try to dig up what exactly do you have to do
[16:20] <ppisati> avoine: if you can't figure out
[16:20] <avoine> ppisati: ok, thanks
[17:04]  * ppisati goes for some sweating... later...
[17:06] <doanac> bjf: i've added a comment to bug 1092924.
[17:06] <ubot2> Launchpad bug 1092924 in UTAH "Cobbler install of recent raring-desktop images failing" [High,Triaged] https://launchpad.net/bugs/1092924
[17:07] <doanac> I think the easiest way to help move forward would be to give you access so that you can re-produce and poke around.
[17:08] <bjf> doanac, the easiest way was for you to find a kernel / iso that was successfully working. 
[17:08] <doanac> bjf: i can't find an ISO that does work
[18:27]  * rtg_ -> lunch
[21:08]  * rtg_ -> EOD
[21:37] <infinity> zequence: Around?
[21:37] <zequence> infinity: Yep
[21:37] <infinity> zequence: Once bjf sorts out the bugs so you're working on the right one, there's a fairly urgent (quantal-only) lowlatency rebase needed.
[21:38] <bjf> zequence, bug 1132942 is the one to use, i'll fix any others
[21:38] <ubot2> Launchpad bug 1132942 in Kernel SRU Workflow "linux-lowlatency: <version to be filled> -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1132942
[21:40] <zequence> Ok, so I'll do a rebase shortly and let you know when it's done
[21:41] <infinity> bjf: According to your lts-q changelog, you seem to have broken your stated "use the oldest bug" rule. ;)
[21:41] <infinity> bjf: (Not that it matter, just make sure you close the right ones)
[21:41] <bjf> infinity, i refused to wait so i created that one by hand :-)
[21:41] <infinity> bjf: But it's newer than the others. :P
[21:42] <bjf> infinity, i was busy working on it and had not refreshed so i missed the fact that shankbot created it for me
[21:42] <infinity> Ahh.
[21:42] <infinity> Twice, no less.
[21:42] <infinity> Overzealous bot.
[21:44] <bjf> impatient me
[21:46] <zequence> infinity: Who's doing the pulling?
[21:46] <infinity> bjf or apw, I imagine.
[21:46] <infinity> apw: If you're around and feel like helping zequence.
[21:47] <zequence> apw: quantal source ready to be pulled
[21:47] <bjf> zequence, where from?
[21:48] <zequence> It's at https://github.com/zequence/ubuntu-quantal-lowlatency.git
[21:48] <zequence> branch lowlatency
[21:49] <infinity> zequence: You should make the bug reference an actual closure.
[21:49] <infinity> ie: have the magic sequence "LP: #1132942"
[21:49] <ubot2> Launchpad bug 1132942 in Kernel SRU Workflow "linux-lowlatency: <version to be filled> -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1132942
[21:50] <zequence> Ah, sorry. I messed it up this time.
[21:50] <infinity> You messed it up last time too, by omitting the space.  I had to close your bug by hand. :)
[21:50] <zequence> infinity: There's a bot scanning for that, right?
[21:52] <infinity> zequence: Not a bot, per se.  When you build a source package, things with the proper syntax get torn out of the changelog and put in a special field in .changes
[21:52] <infinity> zequence: https://launchpadlibrarian.net/132343151/linux-lts-quantal_3.5.0-25.39~precise1_source.changes
[21:52] <infinity> zequence: ^-- See "Launchpad-Bugs-Fixed:" in there.
[21:52] <infinity> zequence: The archive then obeys that to auto-close bugs on accept.
[21:53] <infinity> zequence: So, broken syntax means no closures.  If you use vim, it actually highlights bug closures in gold, so they show up as correct.
[21:53] <bjf> zequence, is your tree the authoritative tree, we are missing a number of rebases from out git repo. does apw normally just build and upload a package based on your git repo?
[21:53] <zequence> infinity: I see. I'll try to be more careful with the changelog. Should I make some changes, and reapply the last git tag? 
[21:54] <zequence> bjf: I don't know how apw does. I know one time (again a problem with the changelog :( ), he added one commit to change that, and uploaded it to his own tree at kernel.ubuntu.com
[21:55] <bjf> zequence, ack
[21:55] <zequence> ..or pushed
[21:56] <bjf> infinity, looks like i don't have upload rights for linux-signed-lts-quantal :-(
[21:57] <infinity> bjf: Irksome.  Ask stgraber to fix that?
[21:57] <infinity> stgraber: ^
[21:58] <stgraber> bjf: added
[21:58] <bjf> stgraber, can you check sconklin as well? thanks
[21:58] <stgraber> bjf: anyone with rights to the packageset will be fine now. That source simply wasn't in the set.
[21:59] <bjf> stgraber, ah, thanks
[21:59] <bjf> infinity, do i need to do a new package or can i just try again?
[22:02] <stgraber> bjf: just retry
[22:02] <bjf> stgraber, thanks
[22:03] <zequence> infinity: bjf: I've deleted the tag, and redoing it now. Hope that doesn't mess anything up for you?
[22:03] <bjf> zequence, nope, i'm going to leave for apw and then i'll talk to him about how he normally does this
[22:04] <bjf> zequence, i'd think that if your tree was authoritative, you'd just be producing souce packages which he could sponsor for you
[22:06] <zequence> bjf: I think that's the plan, yes. For now, he has been doing the packages.
[22:06] <bjf> zequence, ack
[22:33] <bjf> infinity, ok, i just reuploaded the same pkg again that was rejected, i guess i'll roll the version and upload another
[22:36] <bjf> infinity, this is a pita
[22:37] <infinity> bjf: Hrm?  Shouldn't have needed to rev the version if the first was rejected.
[22:40] <bjf> infinity, actually, it wasn't the signed pkg that was rejected
[23:22] <bjf> infinity, you still around?
[23:23] <bjf> infinity, i think i know what i did, i uploaded it to the wrong pocket
[23:27] <infinity> bjf: Oh?  Pockets don't matter to PPAs.
[23:28] <infinity> bjf: Oh, you uploaded directly to the archive. :)
[23:29] <bjf> infinity, yes, i'm out of practice
[23:29] <infinity> bjf: Want me to reject that one, and we can use the PPA instead?  Doesn't actually matter to me, we can just use the archive one.
[23:29] <infinity> bjf: It has to rebuild in the archive ANYWAY (we don't copy those binaries from the PPA), so no big deal.
[23:29] <infinity> bjf: I'll just accept the one in the queue after I copy the kernel.
[23:30] <infinity> bjf: Work for you?
[23:30]  * infinity -> food.
[23:30] <bjf> infinity, linux-lts-quantal_3.5.0-25.39~precise1 this was rejected and the signed-lts pkg is waiting
[23:30] <infinity> Yeah, I'm looking at the queue right now.
[23:31] <bjf> infinity, if you can make it just work, do so, otherwise let me know if i need to re-upload
[23:31] <infinity> So, what I'm saying is that when the linux-lts-quantal in the PPA is done building, I'll copy it, and accept the linux-signed-lts-quantal that's in the queue.
[23:31] <infinity> That'll work fine.
[23:31] <infinity> I'll get to it after dinner.
[23:32] <bjf> ok, i'll not do anything at this point, i'll be around if you need me to do anything
[23:32] <bjf> infinity, ^
[23:52] <infinity> bjf: Err, what I need you to do is not botch the linux-lts-quantal upload.  I didn't look at that carefully. :/
[23:53] <bjf> infinity, ack
[23:53] <bjf> infinity, do i need to roll the version number or just upload correctly this time?
[23:53] <infinity> Maybe I can fix that with a copy.
[23:56] <infinity> bjf: Can you try running this (I don't have rights to the PPA) http://paste.ubuntu.com/5566371/
[23:57] <infinity> bjf: Assuming you have ubuntu-archive-tools checked out somewhere.
[23:57] <bjf> ack
[23:57] <infinity> bjf: You can't reupload, since it's the same version, but a copy should work, since the binaries never built.
[23:58] <infinity> (Depending on whatever artificial constraints the PPA may have)
[23:58] <infinity> If that doesn't work, I'll cheat and copy it to the security PPA to build it there. :P
[23:59] <bjf> Traceback (most recent call last):
[23:59] <bjf>   File "./copy-package", line 27, in <module>
[23:59] <bjf>     from ubuntutools.question import YesNoQuestion
[23:59] <bjf> ImportError: No module named ubuntutools.question
[23:59] <bjf> infinity, ^
[23:59] <infinity> That can't be a recent checkout of ubuntu-archive-tools...
[23:59] <bjf> infinity, i'm on precise by the way
[23:59] <bjf> i just did: bzr branch bzr+ssh://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/