| tjaalton | linux-libc-dev conflicts with libdrm-dev now? (they both have drm.h) | 06:02 |
|---|---|---|
| tjaalton | bug 308387 | 06:08 |
| apw | now why would libdrm-dev carry headers from the kernel | 10:08 |
| apw | bug #308387 | 10:08 |
| apw | bah | 10:09 |
| tjaalton | apw: being changed as we speak | 10:09 |
| apw | so we are removing them from libdrm-dev? were they simply carrying them because our linux-libc-dev was short some headers? | 10:10 |
| tjaalton | upstream moved them into the kernel | 10:10 |
| apw | its my fault they are in there now, i fixed our package to track upstream form, carrying all userspace headers from the kernel in one place | 10:11 |
| apw | how would i have detected this in advance, so i could have warned the right people | 10:11 |
| tjaalton | well, it's fine now :) | 10:11 |
| apw | heheh yeah happy its sorted, just wondering if there are any others | 10:12 |
| tjaalton | but it's just difficult to know which API .28 has, and should libdrm be updated or what | 10:12 |
| apw | we did it as a result of another package carrying some out of date headers which we should be exporting | 10:12 |
| tjaalton | and what happens when we want to get 2.4.2 which the upcoming intel driver requires | 10:12 |
| apw | so they were aware of the change, having triggered it, but we missed drm | 10:12 |
| apw | the headers have to match whats in the kernel, thats the point of them | 10:13 |
| apw | having newer drm headers doesn't make the kernel have the updated interface | 10:13 |
| tjaalton | but in order to get the new intel driver we need newer drm headers in the kernel | 10:13 |
| apw | thats why they have to come with the kernel in the first place, yes | 10:13 |
| apw | by which i assume you mean you need an updated driver in the kernel? | 10:14 |
| tjaalton | probably that too | 10:14 |
| apw | right so thats a different problem, wanting a backport of a driver potentially | 10:15 |
| apw | and whether that is possible at the level you want | 10:15 |
| apw | if this is jaunty and the driver is mainlined then we should get it when we update our baseline | 10:15 |
| apw | on the next -rc or .28 itself | 10:15 |
| * abogani waves | 10:16 | |
| tjaalton | all I know is that the next intel X driver will require libdrm 2.4.2 and probably newer headers as well | 10:16 |
| abogani | Is there change to have Ubuntu Build Kernel infrastructure (aka debian/* excluding packaging files) under git *separately* from kernel? | 10:16 |
| apw | abogani, what would that do for you? | 10:17 |
| abogani | apw: I would want offer the same features (ABI consistency check for example) of the main kernels in community kernel as rt as well. | 10:18 |
| apw | oh i see you want to add it to other kernels, hmmm | 10:19 |
| smb_tp | I don't see that we would put it seperately | 10:19 |
| abogani | Manually tracking (of your changes) is painful. | 10:19 |
| smb_tp | But wouldn't it be possible to do a automated check for changes in that subdir? | 10:20 |
| apw | abogani, why is it hard to track the changes in there? can you not just take logs for that directory alone? | 10:20 |
| abogani | I can only see the date of the last commit in debian/ with git log (ignoring changelog etc) | 10:20 |
| tjaalton | apw: so, I need to upload a new libdrm-dev without the headers, and you need to add a Replaces for linux-libc-dev :) | 10:21 |
| abogani | apw: No. script and Makefile are -generic/server oriented. So for do it works on -rt i must do same changes. Every times that you change debian/* files i must rebase my commit (for example getabi script). | 10:22 |
| abogani | s/commit/commits | 10:22 |
| apw | oh we do, yeeks, what do i need to add | 10:22 |
| apw | can we fold your changes into our abi scripts without breaking them perhaps? | 10:23 |
| apw | i wonder if the filter thing could help here, there is a git filter for making new repositories out of old ones, taking say just one subdir | 10:24 |
| abogani | apw: I'll check it surely. | 10:24 |
| smb_tp | hm, getabi source would be different hosts and specific to whether it is -ports or -rt or ... | 10:24 |
| apw | tjaalton, ok so what specifically are we replacing | 10:25 |
| smb_tp | abogani, Did we recently add or change something specifically that you missed? | 10:25 |
| abogani | smb: rules and rules.d/* are heavily changed. | 10:26 |
| tjaalton | apw: the current libdrm-dev, which is 2.4.1-0ubuntu7 | 10:27 |
| apw | hmm we did clean things up a bit | 10:27 |
| tjaalton | lool: is this correct now ^^ | 10:27 |
| apw | so just that version or <= that version? | 10:27 |
| tjaalton | apw: right, <= that version | 10:27 |
| apw | Replaces: libc6-dev (<< 2.3.2.ds1-6), libc6.1-dev (<< 2.3.2.ds1-6), dvb-dev (<< 1.0.1-6), linux-kernel-headers, libdrm-dev (<= 2.4.1-0ubuntu7) | 10:28 |
| apw | as simple as that? | 10:28 |
| smb_tp | abogani, And perhaps, would it work for you to take "git log debian", take a start point, use this for git format-patch and re-import those. Maybe this could get automated | 10:28 |
| lool | Not really, it should be << next version | 10:28 |
| tjaalton | lool: what's the difference? | 10:28 |
| lool | It's cleaner for forks of Ubuntu, backports and the like | 10:28 |
| apw | so is the next version ubuntu8 ? | 10:28 |
| tjaalton | lool: ok, so you wanted to have just the upstream version there? | 10:28 |
| lool | The former way is asserting something about version ubuntu7 and older which isn't really specific to that version, while asserting about ubuntu8 is pretty clear | 10:29 |
| lool | tjaalton: An upstream version would have been ideal, but you don't have an upstream version just now so we'll live without | 10:29 |
| apw | its cirtainly clearer that the change is in ubuntu8 if that is the one mentioned | 10:29 |
| tjaalton | apw: yes, << ubuntu8 | 10:29 |
| abogani | smb_tp: Oh it is very quick and dirty! :-) I'll do some tests, thanks for suggestion. | 10:30 |
| apw | so: Replaces: libc6-dev (<< 2.3.2.ds1-6), libc6.1-dev (<< 2.3.2.ds1-6), dvb-dev (<< 1.0.1-6), linux-kernel-headers, libdrm-dev (<< 2.4.1-0ubuntu8) | 10:30 |
| lool | apw: BTW, I looked at the control file and it's cluttered by these very old and useless versions you see | 10:30 |
| lool | apw: Say 2.3.2.ds1-6, that's before *dapper*, we can happily drop these IMO | 10:31 |
| apw | abogani, if you recorded just the HEAD you last updated to you could do that with a git log <oldhead>.. debian | 10:31 |
| * lool adds to kernel package cleanup wiki page | 10:31 | |
| apw | that sounds reasonable, i won't do that in this change tho. that should be a separate pass over the file | 10:31 |
| lool | Yes | 10:31 |
| lool | Geez why is the session below BootPerformance | 10:32 |
| apw | we do not support updates to N from anything other than N-1 do we? | 10:32 |
| lool | apw: We do for LTS | 10:32 |
| lool | apw: LTS to LTS | 10:32 |
| apw | so from a kernel point of view we need to keep things | 10:32 |
| lool | So you should support upgrades from version of last release and version of last LTS | 10:32 |
| apw | back to and including the LTS N-1 | 10:33 |
| lool | apw: Last LTS is hardy | 10:33 |
| lool | Oh right, your sentence was cut, yeah | 10:33 |
| apw | yeah i have a keyboard with a central return key, and i've just come back from using my latop for a week so i am hitting it instead of h sometimes, very anoying | 10:33 |
| tjaalton | http://users.tkk.fi/~tjaalton/dpkg/drm.diff | 10:34 |
| lool | You want to support upgrades from CURRENT-1 and LTS in your dev tree and LTS-1 in your LTS tree | 10:34 |
| lool | LTS-1 isn't very clear, but you get the rules anyway | 10:34 |
| apw | tjaalton, there should be an LP#NNNN in there yes? | 10:34 |
| lool | tjaalton: Uh no | 10:35 |
| lool | tjaalton: /usr/include/xf86drm.h is still to be kept in libdrm | 10:35 |
| lool | See email thread I forwarded | 10:35 |
| apw | lool yes, we can drop the lts-1 when we cut lts+1 | 10:35 |
| apw | lts+1 normal cycle | 10:35 |
| tjaalton | lool: ah :) | 10:35 |
| lool | apw, tjaalton: did you compare the list of headers you're moving? | 10:36 |
| lool | I mean, I'd like one of you two to make sure that we're not losing any and that they change in a sane manner | 10:36 |
| apw | i didn't check as i was unaware they were in libdrm-dev | 10:37 |
| tjaalton | I'd like to see the list in l-l-d | 10:37 |
| apw | that was somewhat unexpected | 10:37 |
| tjaalton | ok see it now | 10:38 |
| tjaalton | libdrm-dev has /u/i/intel_bufmgr.h, which I can't find in l-l-d | 10:38 |
| lool | Not sure that is clear, but not only should linux-libc-dev Replace the libdrm package, it should actually ship these headers! :-) | 10:38 |
| apw | that package should ship all of the headers the kernel contains and exports, thats its function | 10:39 |
| apw | and as of now, that is exactly what it contains | 10:39 |
| apw | where are the other ones coming from? | 10:40 |
| lool | apw: The problem is that libdrm's drm is usually more recent than the kernel's drm | 10:41 |
| apw | but drm is provided by the kernel right? | 10:41 |
| lool | I guess this situation is slowly being fixed upstream, but in practice with this move this means we're going to regress the libdrm headers | 10:41 |
| lool | apw: The ABI yes, the API used to be provided by libdrm by pure accident for years | 10:42 |
| lool | Or because it made life easier for them I don't know | 10:42 |
| apw | the files we export define the interface in the kernel so don't they have to match to be meaningful | 10:43 |
| tjaalton | newer version: http://users.tkk.fi/~tjaalton/dpkg/drm.diff | 10:43 |
| apw | i would expect the lib to export its own headers for its incoming interface, not use the kernel ones for that side | 10:43 |
| lool | apw: To be meaningful, everything should match since forever, but because we had the two trees and are moving over, I'd like the delta to be reviewed to understand what might regress | 10:44 |
| apw | ie i could expect there to be two headers one for users from the library, and one for the library from the kernel | 10:44 |
| apw | if the library is capable of handling a missmatch then it can | 10:44 |
| apw | yep a check they match seems reasonable | 10:44 |
| apw | if i can figure out how to get the two to compare | 10:44 |
| lool | apw: For instance, some xorg stuff might have been built with libdrm's headers and make assumption about the drm which weren't true but we might only discover by a rebuild | 10:45 |
| apw | yep, worth worrying about for sure | 10:45 |
| lool | Or imagine macros which would only be provided by libdrm's version of the headers because it's slightly more recent, some packages might fail to build without the macros etc. | 10:46 |
| apw | tjaalton, still missing a LP reference in that changelog entry need that to close the bug automatically | 10:46 |
| tjaalton | apw: oh right | 10:48 |
| apw | normally a LP #NNNNN in that text part | 10:48 |
| tjaalton | fixed | 10:48 |
| tjaalton | yes I've done that a couple of times ;) | 10:49 |
| apw | ok so before any of this lot gets uploaded we need to confirm the headers are compatible | 10:51 |
| apw | in case we need to revert the kernel carrying the drm headers instead | 10:51 |
| apw | it'll probabally get unresolvable dependancy wise if we are not careful if we have to revert later | 10:52 |
| tjaalton | should I try to build the intel driver with these? | 10:54 |
| tjaalton | 2.4.1 was release five weeks ago | 10:54 |
| tjaalton | *releaseD | 10:54 |
| lool | I think the intel and ati drivers would be the most interesting ones | 10:55 |
| lool | Given that they moved the most in terms of kernel API usage in the last months | 10:55 |
| lool | apw, tjaalton: perhaps you can consider using a ppa with new linux, libdrm, intel and ati? | 10:56 |
| apw | first i am going to get the two sets of headers and find out if they are different or not | 10:58 |
| tjaalton | I could just upload the new libdrm to my ppa, followed by intel & ati | 10:59 |
| lool | tjaalton: Yeah | 10:59 |
| apw | these headers are pretty different | 11:05 |
| apw | and there are some worrying comments in there on the changed parts | 11:05 |
| apw | who owns libdrm | 11:06 |
| tjaalton | was that a question? | 11:07 |
| lool | I think these guys are http://dri.freedesktop.org/wiki/ | 11:08 |
| apw | i really meant who owns the package we ship | 11:09 |
| tjaalton | the x team | 11:09 |
| tjaalton | bryce is likely asleep, but that's why I'm here :) | 11:09 |
| lool | apw: (xorg team == tjaalton + bryce :-) | 11:10 |
| apw | the package seems to be a merge from debian and yet debian linux-libc-dev exports the drm headers, why don't they get this problem | 11:10 |
| lool | We inherit from Debian though which has a bunch more, most active probably jcristau | 11:10 |
| lool | apw: You just found out why I raised this problem in september :-) | 11:11 |
| tjaalton | apw: only the experimental version ships those headers | 11:11 |
| lool | Exactly | 11:11 |
| apw | oh poop | 11:11 |
| apw | sooooo .... we have two options 1) revert exporting the drm headers in our linux-libc-dev package, or 2) work out how we fix it properly | 11:12 |
| lool | apw: What types of discrepancies are we talking about here? | 11:12 |
| apw | with alphsa2 on thursday we need to decide now i guess | 11:12 |
| lool | As you pointed out, it's all the same in-kernel drm ABI in both cases anyway | 11:12 |
| apw | mostly its benign looking, but there is a bit about changing size_t to like unsigned long 'so the header can be used in the xserver' | 11:13 |
| apw | that sounds pretty worrying | 11:13 |
| lool | If that's a kernel ABI it's pretty clear we should align to whatever type is used there | 11:14 |
| apw | a lot of the rest of the changes seem to be due to picking up the raw headers and making them work, like __iomem, however the kernel export strips all that | 11:15 |
| lool | Is this something Ubuntu specific? | 11:15 |
| lool | I mean, is this stripping an extra step we take or is it done by the upstream installation process? | 11:16 |
| apw | the stripping of __user etc is a deliberate step the standard kernel header builder takes | 11:17 |
| apw | it also strips the _KERNEL_ sections too | 11:17 |
| apw | so they are 'clean' of kernel crap in theory | 11:17 |
| apw | tjaalton, so, what direction is the experimental stuff going in debian? any feel for their resolution | 11:18 |
| tjaalton | apw: libdrm hasn't seen any changes yet, so I guess jcristau doesn't know about the change either | 11:19 |
| apw | ok sooo, that sounds like a mess in the making, but not something we can resolve in days | 11:21 |
| apw | so it seems prudent to not change drm, but perhaps to remove the drm headers from the kernel package pending understanding the longer term resolution | 11:22 |
| lool | Hmm I wonder whether it's an issue to have a kernel with a version supposedly containing these headers but without the headers | 11:22 |
| lool | I poked jcristau | 11:23 |
| lool | I guess we should move the discussion to a place where he sits, perhaps #ubuntu-x or #ubuntu-devel | 11:23 |
| apw | lool, pick one (channel( | 11:24 |
| apw | the kernel has exported a bunch of headers for some time, we have not packaged them | 11:24 |
| apw | that was now out of step with upstream and was affecting another project which wanted them | 11:25 |
| tjaalton | lool: he's in india right now :) | 11:25 |
| lool | tjaalton: k he was around a couple of hours ago | 11:25 |
| apw | so it seemed reasonable to move to including them, perhaps that is not true for drm | 11:25 |
| apw | at this point in time | 11:25 |
| lool | I think it's sensible to stop shipping them until post-alpha2 | 11:26 |
| tjaalton | apw: yeah, I checked some of them, and apt-file showed that they were only shipped in linux-headers | 11:26 |
| lool | And work on a plan for just after alpha 2 :) | 11:26 |
| * lool lunch bbl & | 11:26 | |
| apw | i'll propose eliding drm in the headers for -alpha2, tjaalton sounds like you are in the frame for prodding a longer term fix | 11:28 |
| tjaalton | apw: sure | 11:28 |
| lool | In the ubuntu-hardy tree there was a debian/binary-custom.d dir with per arch or flavour patchsets; in ubuntu-intrepid and ubuntu-intrepid-lpia I don't see this dir; I can't find these patches in ubuntu-intrepid-lpia; does someone know about this dir and/or the lpia patches? | 12:46 |
| lool | amitk is on holiday today | 12:46 |
| smb_tp | lool custom build have been removed from the kernel tree. So you will not find them after that. special flavours and lpia have their own tree. About specific patches I cannot say something sure. | 12:49 |
| lool | smb_tp: Who would I be able to speak to for lpia matters when amitk isn't around? | 12:50 |
| lool | Geez I think this is really serious | 12:50 |
| lool | AFAICS all 13 lpia patches are simply ... not there | 12:51 |
| lool | Not committed and not present as patches | 12:51 |
| smb_tp | lool, currently there would be none directly. Let me take a look... | 12:52 |
| lool | One of the patch I'm looking at is half merged | 12:52 |
| lool | smb_tp: If you'd like to take a look, grab ubuntu-hardy and ubuntu-intrepid-lpia | 12:53 |
| lool | smb_tp: debian/binary-custom.d/lpia/patchset/* are the patches I'm looking at | 12:53 |
| lool | Hmm some patches have been merged upstream, just not the first ones I looked at | 12:54 |
| lool | smb_tp: I was checking this because of https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/280669 | 12:55 |
| smb_tp | lool, The hardy half I got here. Let me update the intrepid part. I few patches look like they might have gone upstream. | 12:55 |
| lool | Some parts of 0018-sdio_crown_beach are questionable, but some went missing; consider the marvell quirk for instance | 12:56 |
| lool | 0016-poulsbo_ide is the patch for LP 280669; that one went missing as well | 12:57 |
| lool | If I look at 0013-poulsbo_pci_ids, some ids have been added under a different names, some others not | 13:01 |
| lool | Hmm where's the lpia config for jaunty? | 13:01 |
| lool | Blah and other patches in lpiacompat/ | 13:03 |
| smb_tp | lool, I not highly convinced how much from the hardy lpia really was used. All the netbooks I know of used the netbook kernel of the mid team. And to get things back into order is current work in progress | 13:09 |
| lool | smb_tp: I don't think we're looking at this from the same angle | 13:10 |
| lool | smb_tp: I have a real life issue with the current intrepid and jaunty kernels, all arches | 13:10 |
| lool | And I would guess hardy i386 kernel would have the same issue | 13:11 |
| smb_tp | lool, So what is the issue? | 13:11 |
| lool | Which is that a 4 GB drive with two 2 GB parts appears as ony one 2 GB part | 13:11 |
| lool | That's bug ##280669: | 13:11 |
| lool | This report is public | 13:11 |
| lool | (EPASTE) | 13:11 |
| lool | This general issue brought to light that some of the poulsbo patches which we were putting in the hardy lpia build went missing in intrepid and jaunty | 13:12 |
| lool | We can argue whether these patches would best be kept on i386 or lpia (my opinion is that it doesn't make sense to use Debian architectures only to carry patches), but we need the patches somewhere in all cases at least for supporting the hardware | 13:13 |
| smb_tp | I did not follow lpia issues closely but I had the impression there had been moves to rather use the vesa driver. | 13:14 |
| lool | That's orthogonal: we didn't get a video driver for intrepid's kernel in time (we have it now though) so I moved xorg and all to using vesa for this pci id by default | 13:15 |
| lool | smb_tp: for the record, the psb drm lives in hardy-lum below ubuntu/media/drm-poulsbo | 13:26 |
| smb_tp | lool, Yes, right. This is split up | 13:28 |
| smb_tp | lool, There is also a intrepid-lpia tree in amits personal tree. This is older but seems to include the patches from hardy. So, we ahve to ask amit why those differences are there | 13:34 |
| lool | smb_tp: I think the patches were lost when he rebased against a new intrepid tree | 13:35 |
| smb_tp | Or he is somewhat in the middle of doing so | 13:35 |
| lool | smb_tp: We definitely used the tree without the patches for intrepid and I can tell you the intrepid i386 and lpia kernel behave the same and show only half of the disk | 13:46 |
| lool | While the hardy OEM image works fine | 13:46 |
| smb_tp | lool, I know that the hardy-lpia part has been a little neglected and maybe the intrepid tree also did not catch all changes. But we are working on that. The exact state of that progress I will have to find out | 13:52 |
| rtg | apw: did you ever get back to bug #297750 ? | 14:09 |
| apw | rtg i think thats the one you patched, and then i tried the kernel and found the black list was missing, and i posted another debdiff for | 14:11 |
| * apw checks what happened to that second patch | 14:12 | |
| rtg | apw: right, but I asked for a more general version of the patch so that the oversight didn't happen again. | 14:12 |
| apw | ahhh, then i've not got | 14:12 |
| apw | back to it yet. will look now, _if_ my computer gives me any computrons | 14:13 |
| rtg | pour caffeine on it? | 14:13 |
| apw | i _wish_ that worked | 14:13 |
| rtg | well, I need some. | 14:13 |
| apw | me too ... will sort that out next | 14:13 |
| lool | smb_tp: Thanks | 14:23 |
| Keybuk | jet lag and kernel signals | 14:32 |
| Keybuk | not a good combination | 14:32 |
| apw | rtg, i've just dropped a debdiff for that module-init-tools thing onto the mailing list | 15:39 |
| elmargol | Hi there is a rumor arround that ubuntu is going to have a vanilla kernel option in the future. Is this true? | 16:00 |
| rtg | elmargol: apw has been assigned that task. | 16:00 |
| silvergti | hello | 16:01 |
| ogra | rtg, silvergti is the guy with 8111b cards in his thin clients | 16:01 |
| apw | elmargol, indeed that is the plan, hoping to get to that sometime this week and get some samples up | 16:01 |
| silvergti | ty for the intro ogra :) | 16:01 |
| elmargol | apw: does this mean we can install 2.6.28 on intrepid too? | 16:01 |
| apw | it may well do. though they would be generic kernels, so if you needed any ubuntu'isms they won't be included | 16:02 |
| apw | tjaalton, in preparing the patch to remove the drm headers from the kernel package, it has been suggested that assuming we are meant to be moving to the virgin headers that we migth be better off using dpkg-diverts in the libdrm-dev package to overide the headers which are functionally different (which is not all of them) | 16:05 |
| silvergti | hi rtg, can u give some help? | 16:05 |
| rtg | silvergti: with regard to r8169 on Gutsy? | 16:06 |
| silvergti | r8111b/8111c Ltsp Ubuntu 8.10 | 16:08 |
| elmargol | Do you think it is safe to use the ubuntu .config and just compile the lastest kernel using make and make install? | 16:08 |
| apw | elmargol, well that won't likely attach the kernel correctly in the bootloader iirc but it should not affect your other kernels | 16:09 |
| silvergti | rtg r8111b/8111c Ltsp Ubuntu 8.10 | 16:18 |
| rtg | silvergti: so? what about 'em ? | 16:20 |
| ogra | rtg, it doesnt seem to pick up an IP via dhcp | 16:20 |
| rtg | ogra: well, the LP report is gonna need more info then that. | 16:21 |
| ogra | (using netboot and ipconfig -d eth0 from initramfs/busybox) | 16:21 |
| ogra | rtg, right, thats why i pointed silvergti here so you can tel him what he needs to collect for debugging | 16:22 |
| ogra | *tell | 16:22 |
| ogra | i see bug 208012 that might be the right place to attach more info | 16:23 |
| rtg | there is all kinds of standard info for those kinds of bugs. ogasawara has templates somewhere. | 16:23 |
| ogra | (and being still open but confirmed for the same device) | 16:23 |
| * ogra wonders why this channel has no bugbot | 16:24 | |
| ogra | https://bugs.launchpad.net/ubuntu/+bug/208012 | 16:24 |
| silvergti | but i think this is not exactly the same nic | 16:25 |
| silvergti | oh... sorry, it is | 16:25 |
| ogasawara | silvergti: in bug 208012 it would be good if you could attach debugging information that is outlined at https://wiki.ubuntu.com/KernelTeamBugPolicies | 16:38 |
| ogra | the minimal info at least (though being stuck in busybox might make transferring it a manually copy task) | 16:44 |
| ogra | (thin clients that dont get to their rootfs are a bit tricky) | 16:45 |
| silvergti | yes, it wont be easy :P | 16:46 |
| ogra | but it will help to nail it down properly :) | 16:47 |
| silvergti | :) | 16:49 |
| silvergti | theres no lspci on thin client | 17:02 |
| ogra | silvergti, do you have a possibility to boot the client off a USB CDRom or something ? | 17:05 |
| ogra | so you could run a livecd to get the right tools | 17:05 |
| ogra | initramfs is really a tricky place to collect debugging info | 17:06 |
| silvergti | no :( don't have any usb cdrom | 17:06 |
| ogra | do you have a usb key ? | 17:07 |
| silvergti | wait... this thin was an embedded O.S. | 17:07 |
| ogra | well, that wont get you the ubuntu info ... | 17:08 |
| ogra | though lspci should help a bit | 17:08 |
| silvergti | yep, just to get lspci | 17:08 |
| ogra | but if you have a usb key and the client cn boot off USB, you can create a live usb key on the server with the usb-creator tool from an ubuntu iso | 17:08 |
| ogra | that wuld get you all data at once | 17:09 |
| silvergti | no usb pen... left mine at home... | 17:18 |
| silvergti | lol | 17:18 |
| silvergti | tomorrow i will bring it | 17:18 |
| tjaalton | apw: I read what was discussed on #u-d.. and I agree with lool, diverts are ugly and should be avoided if at all possible :) | 17:58 |
| apw | ok i have posted my patch to our kernel list, and primed rtg on it | 17:59 |
| apw | whether we can actually get the kernel rebuilt in time for -alpha2 is unknonw right now | 18:00 |
| tjaalton | well, I'll build a couple of drivers on my ppa against the slimmed-down libdrm-dev then ;) | 18:01 |
| apw | i suspect major explosion from what i've seen of the headers we have | 18:02 |
| tjaalton | apw: yep, failed: https://edge.launchpad.net/~tjaalton/+archive/+build/815275 | 18:36 |
| iulian | Is there any meeting scheduled for today? | 18:37 |
| apw | tjaalton, thought it would | 18:38 |
| apw | iulian, what sort of meeting? | 18:38 |
| apw | tjaalton, if you are on the kernel email list then reply and say that divert are vile, if not i'll do it later | 18:38 |
| iulian | apw: The weekly ones, in #ubuntu-meeting. | 18:39 |
| apw | yeah there was | 18:39 |
| tjaalton | apw: airlied said that they'll release libdrm 2.4.2 when the intel headers won't conflict anymore. so perhaps the optimal solution for now would be to drop it from the linux-libc-dev and sort this out once there are new upstream releases available | 18:39 |
| tjaalton | apw: yes, will do | 18:39 |
| apw | it occurs at 17:00 UTC which was 1:39 ago | 18:40 |
| apw | tjaalton, that fits with my feelings too, and my patch does exactly that | 18:40 |
| iulian | apw: Ahh, OK, thanks. | 18:40 |
| apw | so if you get kernel emails then replyin saying both that diverts suck, and upstream is saying wait for 2.4.2 and things will be good. would help push the conversation alon | 18:41 |
| tjaalton | apw: yep, sure | 18:47 |
| apw | tjaalton, thanks | 18:48 |
| tjaalton | huh, now building ati on my ppa fails because it wants to install an older linux-libc-dev | 18:59 |
| zackr | hey, so what's the magic to compile a new kernel on ubuntu mobile? fakeroot make-kpkg --initrd kernel_image kernel_headers exits with debian/ruleset/misc/checks.mk:36 "Error. I do not know where the kernel image goes to [kimagedest undefined] ..." | 20:05 |
| NCommander | I thought make-kpkg was obsolete | 20:27 |
| === asac_ is now known as asac | ||
| === lamont` is now known as lamont | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!