=== bjf is now known as bjf[afk] === bjf[afk] is now known as bjf [02:32] cooloney: hey! [02:32] cooloney: any news about the mem issue bug? [02:44] robclark: do you know if we're going to get the fb resize feature from the omap 4 x11 video driver? [02:46] rsalveti: I guess the new pvr driver eventually.. although it would help to get DRM support into the kernel in a sane way for non PCI systems.. [02:48] rsalveti: nothing new here. [02:48] rsalveti: i got the same result like you [02:49] 2G:2G split to disable highmem [02:49] robclark: that's for sure.. [02:49] robclark: was thinking for maverick, how we're going to deal with people changing monitors, and even when we can't probe the correct edid when booting [02:49] the case of my monitor [02:50] cooloney: for me it's quite stable with 2G:2G, no highmem and using just one cpu, or no L2 [02:50] yeah, that's ture [02:50] Need at least a sane default. [02:50] for monitor resolutions. [02:50] rsalveti: but one cpu might not be acceptable, i think [02:50] GrueMaster: for default there's a bug currently for monitors that turns off and on during probe (my case) [02:51] I hit the same thing with my HDMI switchbox. [02:51] that the screens turns 640x480 initially and then it changes to the correct one [02:51] probably the same bug [02:51] I'm looking at it now.. [02:51] Except mine stays at 640x480. [02:51] yeah, probably same bug [02:51] cooloney: probably not, even without L2 [02:52] GrueMaster: pls send your edid.. /sys/devices/omapdss/display0/edid [02:52] L2 will have some impact to the performance [02:52] that's the problem ... [02:52] rsalveti: so there is not good solution now, [02:52] yeah, disabling L2$ or 1 cpu is not ideal.. but 768m has been relatively stable for me so far.. [02:52] GrueMaster: yeah, can you paste your edid when using the switchbox? [02:52] rsalveti: i also applied the patches in 2.6.35.4, 2.6.35.5 and 2.6.35.6 [02:53] from stable tree [02:53] got the same result [02:53] if we get a correct edid then it's just timing issues when probing the edid [02:53] hey all... is current build having any issues? [02:53] just if you're using omap 4 [02:53] Erm, is there a tool for reading this? It looks like garbage. [02:53] * III is using omap4 [02:53] GrueMaster: yep, binary [02:53] parse-edid [02:54] III: currently when using 1GB we get build issues when building the kernel [02:54] with highmem you can easily get it, without highmem you get it some times [02:54] if we disable L2 or use just one cpu, everything works fine [02:54] another workaround is to use 768MB (the one we're using now) [02:55] * III moves to older build :D [02:55] and if we don't fix it for the release, this will probably be the way to go [02:56] cooloney: the problem is that it's quite hard to trace it, I'm out of ideas [02:56] rsalveti: me either, i tried to enable ftrace with dynamic tracing [02:57] but it took me lots of time to get some useless information [02:57] it works fine with all mem stress software I use, but breaks when building the kernel [02:57] cooloney: but were you able to get something? [02:59] rsalveti: i get function tracing information from the abort handler [02:59] and it changes every time before the abort handler [02:59] cooloney: hm, can you paste it? [03:00] i think we need another simpler test case [03:00] rsalveti: np, man. let me find it. paste it to you guys [03:00] cooloney: sure, but I tested a lot of mem stress software and unable to reproduce the issue [03:00] GrueMaster: can you email me the binary? [03:00] mem stress with disk io and etc, and nothing [03:01] rsalveti: cool, what are those mem stress test cases? [03:01] robclark: working on it. [03:01] k, thx [03:01] brb [03:01] the problem probably happens with mem + i/o + dma [03:01] system is being real sluggish. [03:02] (actually, all networked systems are). [03:04] rsalveti: that combination is too complicated. sign [03:04] * cooloney brb [03:04] http://paste.ubuntu.com/502398 - text version. [03:04] cooloney: maybe something at arch/arm/plat-omap/iodmm.c, uses l2... [03:06] Gotta run. I'm being drug away. [03:06] GrueMaster: the problem at bug 644714 is that the resolution is not changed at the x11 driver [03:06] Launchpad bug 644714 in linux-ti-omap4 (Ubuntu) "Screen corruption waking from screen blank if no monitor present (affects: 1) (heat: 526)" [Undecided,New] https://launchpad.net/bugs/644714 [03:07] the fb is changed with latest code from robclark, but not x11 [04:07] * rsalveti out [05:41] does anyone know of a good working build I can use? I just tried 20100926 and 20100927 but I am not able to boot.. anyone else seen this issue? [05:41] sorry that is for OMAP4 [05:48] What issue do you see booting? [05:52] seems to hang on boot [05:54] take that back... seems to boot in to busybox [05:57] Ah, good. Not booting is complex. Any messages before being dumped to a busybox prompt? [05:59] no init found... I'm trying again but with a new card. [05:59] I had that on an upgrade, and was certain it was PEBKAC (and it was omap3), but maybe it wasn't. [06:02] ogra, So, it might be nice to have manifest files also for non-omap4 preinstalls :) [06:07] III, Hrm. Please let me know if it works/doesn't work with the new card. Seems 20100927 has the latest upstart, sysvinit, initramfs-tools which are the bits that are immediately suspicious (but the changelogs don't show anything worrisome). [06:07] * persia waits for rsync for 20100927/omap for a parallel test === JaMa|Zzz is now known as JaMa [08:19] persia, ?? [08:20] http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/current/ : note the number of .manifest files [08:20] oh [08:20] did NCommander kill acorn again with extenbsive dove builds ? := [08:20] I thought you were the person who put them in, and don't happen to know which bit to frob for that [08:20] :P [08:21] persia, manifers files are installed some point around bootloader install ;) [08:21] My issue isn't the lack of ...0928 images (although that's frustrating), but the lack of a manifest for the images that are posted. [08:21] And bootloader is broken for omap? [08:21] the images without bootloader logically have no manifest (and no partition table either) [08:21] was broken [08:21] without a livefs i cant tell [08:22] i would expect that archive to have settled by now though [08:22] On the 27th? There *is* an omap livefs (or something using 509M compressed) [08:22] wintout bootloader partition [08:23] Aha! === hrw|gone is now known as hrw [08:23] morning [08:23] just on a sidenote i have debian lenny running natively on the ac100 (with the existing kernly only somethin that old (and without update) works) [08:23] Would that also be why III couldn't boot? [08:24] no, didnt affect omap4 [08:24] Excellent! [08:24] Dunno then. [08:24] i cant ifup the wlan card though [08:24] something is blocking [08:24] driver issue? [08:24] no, premission issue [08:24] *per [08:24] god, i cant type tofay [08:25] *today [08:25] ogra: it was still running when it spit out hte last image [08:25] ogra: I need a package merged :-) [08:26] NCommander, i was making a bad joke :) [08:26] can you review the patch so I can get the feature freeze exception? [08:26] NCommander, post RC ? [08:26] ogra: bah, now I know this is reality. the real ogra doesn't joke :-/ [08:26] ogra: its critical enough that I want to at least run it by the release team [08:26] ogra: if it flops, it flops, but I have to at least *try* [08:27] * NCommander wants his ubiquity bug fixed :-/ [08:27] you can start uibiquity from the terminal, right ? [08:27] ogra: well, yes, but that's less than ideal [08:27] * ogra wants his "rootfs fillt to 100% wint encrypted home" bug fixed ... but i wouldnt risk RC for that [08:28] ogra, Did you make a patch for that yet? [08:28] thats really something you can release note [08:28] persia, nope [08:28] It's a trivial patch, if you want to test it. [08:28] but i expect to have one before end of the week [08:28] Ah, OK. [08:29] oh,you worked on it already ? [08:29] Only in the sense of the IRC session a few days ago. [08:29] sure i'll test :) [08:29] ah, k [08:29] But it's < 15 lines of code :) [08:29] yep [08:32] NCommander, i'll review it (and nod it off if its ok) later today ... but i wouldnt push for getting it into RC (get it to the queue though) [08:35] NCommander, the changelog disagrees with the change in your branch [08:35] NCommander, scripts/casper/47une_ubiquity is missing completely [08:35] ogra: argh, i readded tha tand push it [08:35] Hold on [08:36] * NCommander goes to get pants so I can turn the Dove on [08:36] NCommander, also dont forget to check for executability (i cant see that in the LP UI) i dont remember which files need to be executable and which dont [08:36] is your dove on the balcony ? [08:40] ogra: no, I'm just living in a place that if I walk to the room where the board is without pants, someone will scream [08:40] the board is without pants too ?!? [08:40] geez ! [08:40] * NCommander decides to discontinue this line of conversation [08:41] check the quotes page :P [08:42] damn it [08:42] ogra: re-pushing. bzr hates me [08:42] (I miss git) [08:43] bzr add isnt that hard :) [08:44] ogra: I just forgot to bzr push [08:44] ogra: its there and executable [08:44] NCommander: there is git-bzr-ng project on github to provide "git bzr" plugin [08:44] NCommander: I use it to manipulate bzr repos but so far failed to push with it [08:47] NCommander, so why do you apt-get remove ? [08:47] NCommander, i would bet it slows down booting a lot [08:47] * ogra would just have removed the diversion instead of waiting for the package DB [08:48] ogra: because it also removes the desktop file oem-config installs asking to finalization the installation [08:48] ogra: well, I wanted to remove it during image building :-P [08:49] NCommander, well, your call, butu i'D say it surely adds 10-20sec to the boot [08:49] and ubiquity will remove it anyway [08:49] ogra: didn't see that bad, and ubiquity doesn't remove it until AFTER installation [08:49] Kinda confusing to have it there before you install [08:49] *seem [08:50] whats confusing about it ? [08:50] if you want a livecd-rootfs patch, I already have one of those, though its not quite as tested (I can fix that though now) [08:50] the user never sees it [08:50] ogra: er, yes theydo? [08:50] Its right therein Settings. [08:50] no, i dont want to tinker with livecd-rootfs [08:50] NCommander, where do you test for the arch ? [08:50] i dont see any code for that [08:51] currently your patch breaks all oem installs [08:51] good morning all [08:51] ogra: no it won't, because OEM installs don't install eom-config until after installation which doesn't use casper. [08:52] the action should be arch (or even subarch) specific [08:52] NCommander, i dont think thats true [08:52] anyone knows if there's a particular issue with building webkit on arm? [08:52] NCommander, did you talk to superm1 about that ? i bet you break all dell installations with that [08:53] berco, Shouldn't be. What issue are you seeing? [08:53] (note i dont talk about the OSG team here but about oem's using modified images) [08:53] persia: It fails all the time [08:53] persia: wondering if not enough memory would be the issue [08:54] ogra: you can't hav eoem-config in the same image as installed ubiquity with the later working properly since it will hide the installer icon [08:54] doesnt seem to fail for us ... http://qa.ubuntuwire.org/ftbfs/ [08:54] ogra: I *wanted* to remove in livecd-rootfs, you said remove it in casper [08:54] NCommander, well, every thought why superm1 added that diversion ? [08:54] NCommander, no, i said remove the diversion [08:54] ogra: er, I think ev wrote that diversion [08:54] ogra: and that's the wrong bloody solution [08:54] well, from casper, but you know what i mean [08:54] The package shouldn't be there [08:55] the packages are there in some setups [08:55] there is an OEM who uses an automated preseeded ubiquity to create images with oem-install [08:56] ogra: oem-config however is installed on fht elfy if its needed [08:56] That's why its in ship [08:56] anyway, make it arch specific and i'll approve [08:56] Looking at oem-config code, the postinst doesn't handle the case if the diversion is already there [08:57] i dont care if you fiddle with the diversion ... but i do care if you make it a default for everyone [08:57] * NCommander will sit down at do it a bit later then [08:57] remove it or remove the diversion ... as you like [08:58] but make sure people explicitly installing oem-config dont get screwed by it [09:00] * persia vaguely wonders why there are both "webkit" and "webkitkde" packages [09:00] berco, Seems to build on the buildds: https://launchpad.net/ubuntu/+source/webkit/1.2.4-1ubuntu1/+build/1948880 [09:00] Might be RAM, might be missing patch. Might be different version. [09:02] looks like KDE needs an older version [09:03] That's not a good reason, but potentially. [09:04] NCommander, was a meta uploaded for the dove kernel ? [09:07] ogra: no idea [09:07] i though you'd care ... thats why i talked about it in the meeting yesterday [09:07] though if you dont ... [09:07] * ogra shrugs [09:08] persia: I was looking at that page too :). Argh! [09:08] will probably break d-i though [09:08] on dove [09:09] berco, My recommendation would be to compare your build log to the build log on LP and find the point at which they differ: this will probably be a hugely valuable hint to getting the build to work. [09:09] persia: do you know the board hubbard? [09:09] Never heard of it. [09:09] armel package was built on this board [09:10] on Launchpad [09:10] Oh, you mean https://launchpad.net/builders/hubbard ? [09:10] yes sorry [09:11] I believe that's a Freescale Babbage 3.0 board, but I could be mistaken. Should be ~800MHz, ~512MB unless someone did something special compared with other implementations of that SoC I've seen. [09:12] yes, all buildds are babbage 3.0 [09:13] thanks [09:20] ogra: patch added and pushed via bzr. I can test a respun image you want to confirm the updated code [09:23] NCommander, if Riddell allows ... triger a full set of armel then please [09:24] ogra: Riddell gave me permission to respin ARM at will === asac_ is now known as asac [09:24] ogra: I meant a locally respun image [09:24] oh, yeah, test it [09:25] * NCommander groans [12:32] http://pandaboard.org/ [12:37] ogra: yep. [13:24] ogra: the patch seems valid, but I'm having testing issues due to instability [13:25] ogra: I am going to commit a slightly newer version, and ask you to merge and handle getting the RC freeze exception, but hold off on the actual upload until I can get someone beside myself to reconfirm the test results [14:09] Does anyone still use redboot-imx? Can it be dropped from the archive? === ApOgEE__ is now known as ApOgEE === zyga is now known as zyga-cold [15:46] persia: our Lucid imx51 images use it. [15:47] afaik [15:48] GrueMaster, But do we need/want it in maverick? [15:49] III, Just FYI, there's a 0929 image that ought be in better shape. [15:49] True. imx51 was disabled sometime around alpha 2-3. [15:49] iirc [15:50] persia: thanks... just downloaded it [16:00] ndec: do you think you could get me access to some ABE routing documentation ? [16:02] mpoirier: you know, now ther is a #igep channel, could be easier to find igep testers now [16:03] mpoirier: hi... sorry I saw your email, but didn't have too much time to digg into this. [16:03] rlameiro: indeed, but I would really need to get a board. [16:03] mpoirier: why do you need this info? [16:03] mpoirier: If i was rich, i would buy you one :D [16:03] mpoirier: I am not sure which document you would need in fact [16:05] ndec: we are bound to repeat the current sound investigation on our other omap3 boards. [16:05] ndec: omap4 too for that matter. [16:05] mpoirier: ABE is OMAP4 only, this is a complete different solution for audio h/w on OMAP3 [16:05] ndec: the more I understand, the better I can give meaningful information to your team. [16:05] mpoirier: sure... [16:05] ndec: I suspected that much. [16:06] ndec: I'm mostly interested by the process berco took to produce the omap4_sound_config.sh script. [16:07] those commands come from some sound data somewhere and that's what I'm after. [16:07] mpoirier: this file is produced by the audio dev team, not us. I will reply to your email. [16:08] ndec: cool - you're my contact into that world. [16:09] ndec: if I'd have some clue on how omap4_sound_config.sh and the SDP4430.conf were generated, I could help on my side. [16:27] rsalveti: RE: Bug 644714 I have another edid output that essentially is blank. THis is what I get when the system wakes and no monitor is attached. The bad thing is, Xwindows is garbage, which is why I recommended 1024x768 as a fallback. [16:27] Launchpad bug 644714 in linux-ti-omap4 (Ubuntu) "Screen corruption waking from screen blank if no monitor present (affects: 1) (heat: 526)" [Undecided,New] https://launchpad.net/bugs/644714 [16:27] I'll try to add the data after RC testing. [16:30] GrueMaster: yep, this would explain the issue [16:30] boot with edid -> 1440x900 [16:31] then when it gets back, finds no edid -> 640x480 [16:31] but the x11 continues to think the fb is 1440x900 [16:31] Well, 640x480 is absolute garbage. looks like 4 screens side by side only partially drawn. [16:31] Can't get a screen capture atm. [16:32] GrueMaster: I get this with my monitor: http://www.flickr.com/photos/rsalveti/4932601965/ [16:33] That is actually usable. Mine is much worse [16:33] I'll try to get a capture during testing. Heavily into RC atm. [16:34] GrueMaster: np === kmargar is now known as markos_ [16:53] hrw: is there some trick to install your cross compiler packages on a lucid box? [16:53] Package libmpfr4 has no installation candidate [16:53] robclark: http://people.canonical.com/~hrw/ubuntu-lucid-armel-cross-compilers/ for amd64 [16:54] robclark: i386 in next few days [16:54] perfect, amd64 is what I need [16:54] robclark: libmpfr4 is in maverick [16:54] robclark: maverick pacakges on p.c.c. are obsolete anyway [16:54] yeah.. but I was trying to use your maverick PPA on lucid.. [16:54] let me try this other site instead [16:55] ppa is also obsolete [16:55] I just keep both because some toold use them [16:55] * robclark can't keep track of what isn't obsolete [16:56] for maverick: use maverick archive. for lucid: use what i just gave you [16:56] k, will do [16:58] ohh.. I think it's working :-) [16:59] rsalveti: you have a significant head start on b644714 due to your previous work on EDID. Do you have the cycles to work on it or you'd be happy to offload it ? [17:21] mpoirier: I'm working on it today [17:21] ok [17:21] first debugging the issue when booting and activating/deactivating the hdmi with my monitor [17:21] and then the x11 part === hrw is now known as hrw|gone [17:31] mpoirier: on the omap4 sound issue, this should probably be changed to libasound2 instead of the kernel, as libasound2 contains all the /usr/share/alsa/cards/*.conf files. [17:31] Thoughts? [17:32] I have the same issues with Beagle (omap) and now Dove A0. [17:32] humm... there is also a kernel portion of it. [17:32] the TI patch for omap4, and some work to differentiate card on beagle and others. [17:33] as you said, there will be a libasound2 part of it. [17:33] Ok. Guess I should file separate bugs for each system then. [17:34] Or should we just track them all centrally? [17:34] Better to have multiple tasks for one bug. [17:34] "Also affects distribution ..." [17:34] is there a way do link two bugs in lp ? i.e this bug will only be completed if that bug is completed... [17:34] I should say "Please file one bug per platform, with as many tasks for each bug as are required to address the issue." [17:35] mpoirier, Intentionally not (although debate continues on this subject) [17:35] We either have one main bug and list all the kernels & asound, or one bug for each kernel. [17:35] Oh, ok [17:35] I think we should have one bug for each *board*, and list asound & relevant kernel for each. [17:35] persia: That makes the most sense. [17:35] Potentially list multiple kernels for a single board if it's supported by multiple kernels and multiple kernel maintainers want to apply the same class of patch (e.g. for omap3) [17:36] GrueMaster: I also think we should have a bug per board. Otherwise bugs never get closed. [17:36] as persia indicate, the fixes will span multiple kernels. [17:37] mpoirier, Only in cases where multiple kernels support a given board. For some hardware (e.g. imx51), there may only be one kernel available. [17:38] Ideally, this is a short-term thing, until linaro fixes things so that there is only one true kernel. [17:54] http://www.elinux.org/Panda_Bamboo [17:54] for anyone that is interested, the deadline for features for the bamboo board is october 8th [17:55] prpplague: IR receiver? [17:55] (and lasers... sharks with lasers) [17:55] robclark: hehe [17:55] robclark: i have IR on my list to look at [17:55] cool [18:03] Talk of SATA was for a different extender, right? [18:05] persia: still trying to figure that out [18:05] persia: i'm considering dropping the second sd/mmc in favor of a 32GB eMMC [18:06] Unless you can find a way to boot off that, I'd rather see a second SD/MMC. [18:06] persia: boots fine [18:06] Off a secondary eMMC? [18:06] yea, same as blaze [18:07] Oh, please do that then. I'd dearly like to return to having a sane "install" path. [18:07] And I'll have good arguments to do that if the Bamboo works with it :) [18:07] (extra benefit: the same codepath would work for both panda and blaze, etc.) [18:08] GrueMaster, did that fsl-imx51 kernel show up for you yet? [18:08] Not sure, will check. [18:09] GrueMaster, https://launchpad.net/ubuntu/+source/linux-fsl-imx51/2.6.31-608.20/+build/1978184 [18:11] I know it is listed on launchpad. But until it shows up in http://ports.ubuntu.com/pool/main/l/linux-fsl-imx51/, it is more difficult to deal with, and it still isn't there. [18:11] GrueMaster, ok, trying to figure out where it's hung up [18:11] If it's not published by the turn of the next hour, might ask if the release team has the publisher on manual. [18:12] persia: This is for lucid-proposed. Shouldn't be affected afaik. [18:12] bjf, I haven't checked current performance, but it used to take 43-103 minutes to get from "built" to "available in the archive" [18:12] GrueMaster, it's the *same* publisher. [18:12] persia, thanks for the info [18:12] ah [18:13] Well, since I'm deep into Maverick RC testing, it will have to wait until Late tomorrow/Friday for testing. [18:14] GrueMaster, np, mostly i'm just trying to make sure its available to you when you are ready to work it [19:05] ogra: Around? === amitk is now known as amitk-afk [19:31] Well, now this is odd. Attempted to change only the font in une-efl, the system seems to have completely changed themes. Very unusual. [19:39] Question: Is there any progress being made with suspend on imx51? [19:45] A new kernel was uploaded yesterday, but I'm not sure what was changed in it. It is currently pending publication after Maverick RC freeze is lifted. [19:45] rc freeze for a lucid SRU ? [19:45] GrueMaster, it should just go in [19:46] should be in -proposed for testing if it has build [19:48] Well, that's what I have been told. I'm too busy with RC to go hunting for it. [19:49] And the kernel team just keeps sending me links to launchpad where the packages are sitting. Need it in lucid-proposed for apt-get to pull. [20:05] GrueMaster, The acceptance queue is different from the publisher. [20:05] lool, yes (as long as this tegra WLAN stays stable) [20:07] persia: I don't really care about the background processes and the mechanisms that they work through. What I do care about is when I get an email requesting me to test a kernel update in lucid-proposed, and people asking me why it isn't there for apt-get to work. [20:08] GrueMaster, That's fair: it's sensible for the uploader to take responsibility for ensuring the upload ends up being distributed in the repositories. [20:09] my point exactly. :P [20:11] Anyway, I'll continue to explain workflows and background processes and mechanisms as long as people ask questions. Appropriate folk (e.g. bjf) might want to chase up on things. [20:13] explaining them is fine, as long as they are also addressed to the people that should be able to do something about the process when it doesn't work. [20:13] persia, i'm interested in the workflows and background processes so i appreciate the info [20:14] GrueMaster, Sorry then, I'll try to read more carefully and not mis-highlight. [20:14] Don't get me wrong, I too am interested. Just not when I have 1 day to test multiple releases on multiple platforms. :P [20:17] bjf, So, anyway, once LP gets a build, it submits it to the queue (e.g. https://launchpad.net/ubuntu/lucid/+queue ). The queue has a few states, and things can be in one or another depending. Nothing will land in the archives until it gets to Accepted (NEW and UNAPPROVED need manual action by an archive-admin). Stuff in Accepted will be pushed to the archive each publisher run (typically once an ho [20:17] ur: sometimes set to manual for release management purposes). [20:18] bjf, So, find out where your package is: if it's not anywhere in the queue (including DONE), then something is odd with the LP build. If it's in the queue, but not ACCEPTED or DONE, you need an archive-admin (and likely some associated paperwork). [20:18] best place to find archive admins is #ubuntu-devel [20:19] If it's been in ACCEPTED for a couple of hours or more, and it's around some special time in the Ubuntu Release schedule, you might check with the folk in #ubuntu-release to make sure the publisher is running. [20:19] persia, there isn't a way for me to check if the publisher is running without asking? [20:21] I think only LOSAs can check, but there may be some other interface exposed. You could ask in #launchpad, but I generally just assume it's running except when it clearly hasn't for about 3 hours. [20:46] Hi. Is anybody aware of fast mirrors to the arm preinstalled daily builds ? [20:48] I believe they are all private. [20:50] Hm. Currently only getting around 50kB/s from cdima.ubuntu.com [20:50] but it might be the library hating me [20:53] ah seems to be a local problem really [20:53] 3,3MB/s now [20:57] That's a much better speed :) [21:00] Bye [21:17] persia, all ubuntu boxes shipped, exactly the numbers from the email [21:18] Neko, Cool. Thanks for the confirmation. Please let me know if anything isn't happening to your satisfaction. [21:19] I expect about a month while people get used to it [21:19] they all shipped with maverick+xfce but I assume the kde guys etc. will wipe it immediately [21:21] Shipping with maverick will make lots of folk happy. I hear markos_ is coming to UDS, and I suspect people will be asking questions there. === linuxlover is now known as Riotta [21:39] so quick question.. does dkms log to somewhere, so I can see *why* it failed to rebuild some module? [21:45] robclark: perhaps in /usr/src? [21:46] * robclark looks [21:49] hmm.. src is there.. but don't see a log.. [21:51] ok.. well, I think I figured out how dkms is invoked, so I can do this manually.. [21:52] robclark: yep, /var something, let me see it [21:52] had the same question when I created the sgx package [21:53] make.log, something like that [21:53] rsalveti: the sgx package is the one I'm having trouble with ;-) [21:53] in my case it was /var/lib/dkms/powervr-omap3/3.01.00.07/2.6.35-22-omap/armel/log/make.log [21:54] robclark: well, I created only the omap 3 one :-) [21:54] ahh, perfect.. found the log.. thx rsalveti [21:55] np [21:55] hmm.. tho the log has no errors.. I wonder why dpkg thought it failed when I tried to install new kernel? [21:56] robclark: can you paste the error you got? [21:56] could be that it couldn't find the proper headers for your kernel [21:57] http://paste.ubuntu.com/502859/ [21:59] robclark: it looks like you are installing the wrong headers. the OMAP4 kernel should be linux-headers-2.6.35-903 [21:59] robclark, you are building omap3 stuff [22:00] ahhh... [22:00] apt-get install linux-headers-omap4 iirc [22:00] robclark: yep, that should be your problem [22:00] (there is a metapackgae for everything ;) ) [22:00] even a meta of the meta [22:01] heheh [22:01] heh [22:02]