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