| 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:24 |
|---|---|---|
| ppisati | moin | 07:36 |
| wooo | guys please help !! | 07:49 |
| 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:51 |
| * apw yawns | 09:08 | |
| === henrix_ is now known as henrix | ||
| ppisati | brb | 09:20 |
| cnf | apw: package is working now, btw | 10:27 |
| cnf | apw: ugly, ugly hacks, but it works :P | 10:27 |
| 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:29 |
| 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:38 |
| apw | ppisati, now if you could just add a patch to make teh cpus 4x faster ... | 10:39 |
| ppisati | apw: just wait for the new panda omap5, i heard it's so awesome (when it comes out) :) | 10:40 |
| apw | ppisati, heh sounds good, the build will likely still running when they do :) | 10:41 |
| 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:00 |
| 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:01 |
| 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:02 |
| jjohansen | bjf: I'll be in at about 7:30 | 13:11 |
| smb | apw, Hm, CONFIG_DEBUG_INFO seems to be gone | 13:14 |
| smb | ah no | 13:15 |
| smb | still there | 13:15 |
| ogra_ | its stable enough now ... screw debugging | 13:15 |
| smb | apw, Interestingly only amd64 =y i386 =n | 13:17 |
| 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:24 |
| smb | apw, probably whatever that output is, its not the things I tried to look for | 13:26 |
| ppisati | apw: is your panda still ok? | 14:16 |
| 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:18 |
| 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:19 |
| 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:21 |
| rtg_ | apw, ok, looks like it removes them but doesn't purge them | 14:22 |
| 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:23 |
| 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:25 |
| 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:26 |
| apw | rtg_, yes it has, that will show which it thinks you installed manually | 14:27 |
| apw | apt-mark showmanual linux-\* | 14:27 |
| * smb thinks there is a flaw in the matrix | 14:32 | |
| apw | yeah :) | 14:42 |
| 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. | 14:48 |
| === kentb-afk is now known as kentb | ||
| 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:34 |
| 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:35 |
| xnox | apw ^ would you know about this? | 15:36 |
| * xnox got lost in per-arch trees in the kernel sources. | 15:36 | |
| * ogasawara back in 20 | 15:45 | |
| === kentb is now known as kentb-afk | ||
| 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:11 |
| avoine | but I think it won't work unless I update the u-boot for ubuntu | 16:12 |
| ppisati | avoine: we never released an official ubuntu img for imx6 | 16:15 |
| 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:16 |
| avoine | yeah it boot from SD | 16:17 |
| avoine | ppisati: ^ | 16:17 |
| avoine | ppisati: ok, I'll try to update the kernel to the latest one and see if it boot | 16:18 |
| 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:19 |
| 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 | 16:20 |
| === kentb-afk is now known as kentb | ||
| * ppisati goes for some sweating... later... | 17:04 | |
| 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:06 |
| 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:07 |
| 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 | 17:08 |
| === henrix is now known as henrix_ | ||
| === henrix_ is now known as henrix | ||
| * rtg_ -> lunch | 18:27 | |
| === sabayonuser2 is now known as Tuxkalle | ||
| === henrix is now known as henrix_ | ||
| * rtg_ -> EOD | 21:08 | |
| 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:37 |
| 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:38 |
| zequence | Ok, so I'll do a rebase shortly and let you know when it's done | 21:40 |
| 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:41 |
| 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:42 |
| bjf | impatient me | 21:44 |
| 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:46 |
| zequence | apw: quantal source ready to be pulled | 21:47 |
| bjf | zequence, where from? | 21:47 |
| zequence | It's at https://github.com/zequence/ubuntu-quantal-lowlatency.git | 21:48 |
| zequence | branch lowlatency | 21:48 |
| 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:49 |
| 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:50 |
| 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:52 |
| 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:53 |
| 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:54 |
| bjf | zequence, ack | 21:55 |
| zequence | ..or pushed | 21:55 |
| bjf | infinity, looks like i don't have upload rights for linux-signed-lts-quantal :-( | 21:56 |
| infinity | bjf: Irksome. Ask stgraber to fix that? | 21:57 |
| infinity | stgraber: ^ | 21:57 |
| 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:58 |
| bjf | stgraber, ah, thanks | 21:59 |
| bjf | infinity, do i need to do a new package or can i just try again? | 21:59 |
| stgraber | bjf: just retry | 22:02 |
| bjf | stgraber, thanks | 22:02 |
| 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:03 |
| 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:04 |
| zequence | bjf: I think that's the plan, yes. For now, he has been doing the packages. | 22:06 |
| bjf | zequence, ack | 22:06 |
| === arges_ is now known as arges | ||
| bjf | infinity, ok, i just reuploaded the same pkg again that was rejected, i guess i'll roll the version and upload another | 22:33 |
| bjf | infinity, this is a pita | 22:36 |
| infinity | bjf: Hrm? Shouldn't have needed to rev the version if the first was rejected. | 22:37 |
| bjf | infinity, actually, it wasn't the signed pkg that was rejected | 22:40 |
| bjf | infinity, you still around? | 23:22 |
| bjf | infinity, i think i know what i did, i uploaded it to the wrong pocket | 23:23 |
| infinity | bjf: Oh? Pockets don't matter to PPAs. | 23:27 |
| infinity | bjf: Oh, you uploaded directly to the archive. :) | 23:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| === kentb is now known as kentb-out | ||
| 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:52 |
| 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:53 |
| infinity | bjf: Can you try running this (I don't have rights to the PPA) http://paste.ubuntu.com/5566371/ | 23:56 |
| 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:57 |
| 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:58 |
| 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/ | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!