[00:08] wgrant: that was fast :) [00:10] calc: That's one of the fastest rollouts I've seen them do. Pleasantly surprising. [00:15] wgrant: yea :) short outages are fine with me :) [00:15] i'm just scared of those 8hr+ outages ;-) [00:16] I remember back when they used to take it down for >2 hours every Tuesday night. That was annoying. [00:18] yea [00:25] 12 minutes total downtime [00:25] we're getting better! [00:29] beuno: But I guess you can't be so quick during normal rollouts :( [00:30] wgrant, probably not, but quick-er [00:31] and just wait until read-only launchpad lands... [00:31] That has been coming for a long time... but it does seem to have a hard target now... [00:31] well, you know, good things come to those who wait... [00:31] if you don't, onlt bad things (>) === MacSlow_ is now known as MacSlow [00:36] I has haircut [00:37] * wgrant blames developers' haircuts for RC being buggy. [00:39] wgrant, You think it's better to fix bugs than cut hair? [00:39] persia: You obviously haven't seen my hair. [00:40] No :) [00:40] Although, personally, every five or six months, my hair starts getting in the way of my doing useful things like seeing or typing, and I find a haircut assists in bug closure. [00:41] persia: indeed [00:41] There are workarounds for that which don't involve cutting it, fortunately. [00:42] timing haircuts to coincide with lp downtimes == priceless [00:42] bryce, Admit it: it was luck. [00:42] yeah pretty much [00:43] wgrant, Depends on your hair. Mine tends to break. [00:44] pfft heairs [00:44] *hairs [00:44] Mine has survived quite well for a number of years. [00:45] mine too ... but i find beards more significantly showing that state of my workload :) [00:45] *the [00:55] pitti: Heh, there’s already a bug report about it. I’ll see whether i’ll get around to creating a patch for the issue. [01:14] * StevenK appears [01:16] StevenK, There's no kernel, and been no word for ~8 hours. Apparently it was evening in Europe. [01:16] Oh, and Good morning :) [01:28] Hmm [01:47] cjwatson: you there? [01:48] munckfish: if you don't mind a zombie [01:48] well I am one myself :) [01:48] :S [01:49] cjwatson: could we add a "recovery" option to the kboot-installer package? [01:49] I needed that today [01:49] not now, maybe for jaunty [01:49] ok [01:49] can't add features 12 days before release :) [01:49] yeah true, it's a feature [01:49] sorry [01:49] so you mean like a rescue CD type thing? [01:50] umm like we have in grub [01:50] "rewrite my kboot.cnf" [01:50] two items for each kernel [01:50] oh, you mean a separate boot menu entry [01:50] second one boots kernel with "single" as it's arg [01:50] yeah, sure, that would make sense for jaunty [01:51] which boots into that recovery menu which allows you to get root shell or fix X etc [01:51] cool [01:51] Oh I nearly cried today [01:51] I never expected to see such bad bad problems so late [01:51] can't you edit the menu in kboot to some degree? [01:51] or boot manually or something [01:51] especially as Intrepid was running so nice just last week :( [01:51] cjwatson: oh yeah I can edit it [01:52] I agree the framebuffer thing is bad, you'll have to delve into initramfs to figure that one out [01:52] It just occurred to me it'd be useful for "users" [01:52] hopefully my kboot-installer change will fix the label thing, I'm pretty confident [01:52] it's definitely a correct fix [01:52] ah cool [01:52] roughly what did you change? Or where can I see the patch? [01:53] munckfish: http://paste.ubuntu.com/59077/ [01:53] cjwatson: do you ever sleep? [01:53] was a global change across partman, we just missed kboot-installer :-( [01:54] munckfish: not nearly so much as I'd like [01:54] aha that defo looks like the thing [01:54] you in BST/GMT? [01:54] BST, yes [01:55] me too [01:55] ... and I have to be up in reasonable time tomorrow so I think that has to be a wrap :) [01:55] yeah I need to quite now too [01:55] thx for your help so late [01:55] no problem [01:55] c ya! [02:05] Oh ffs. [02:05] Is there somebody around with an amd64 xserver with a Synaptics touchpad? [02:05] Something continues to be borked in the X stack. [02:06] wgrant: sadly my amd64 box is a desktop [02:06] bryce: Are you able to run xinput list-props on one of your real mice? [02:07] Somebody is complaining that my new syndaemon version doesn't work properly, but xinput is segfaulting, so I think we can blame it elsewhere... [02:07] Oh. [02:07] wgrant: amd64 w/ synaptics here, yes [02:07] I can reproduce it with an i386 server... but only on the synaptics device. [02:07] What the.... [02:07] The other devices work fine. [02:08] So amd64 clients don't like synaptics properties for some reason. [02:08] Regardless of server arch. [02:08] amd64 needs to die. Or X. [02:09] slangasek: btw, fix for targeted bug 275285 is tested and uploaded [02:09] Launchpad bug 275285 in xserver-xorg-video-intel "[intrepid] Flash, VirtualBox, Dosbox etc. video freezes after few seconds" [High,Fix released] https://launchpad.net/bugs/275285 [02:10] So XGetDeviceProperty now works fine. [02:10] slangasek: wait a sec [02:10] But XListDeviceProperties segfaults for -synaptics. How stupid. [02:12] slangasek: ok 275285 ready for approval [02:12] wgrant: Uuuh, yeah! What the hell happened there? xinput list-props "Syn..." _worked_ for one blessed day, and now segfaults? [02:13] bryce: well, hasn't reached the queue yet :) [02:13] RAOF: I'm stepping through upgrades to work out what broke it. [02:14] * RAOF 's internet is currently capped at a princely 64kbit/sec, so is not the ideal candidate for that. :( [02:14] * bryce turns attention to 261977 [02:15] RAOF: I've only been capped once this year, but back two years ago when we were on the 1GB plan we were frequently capped to 28.8kbps for half a month... [02:15] hi devels \o/ [02:15] wgrant: I forgot how utterly dependent on a fast connection Intrepid testing is. [02:15] RAOF: Yes... [02:16] Though it's not so bad now we're frozen. [02:16] At the current rate, it'll be _tomorrow_ before I finish downloading yesterday's updates. [02:16] * RAOF thanks OOo and Java for that. [02:16] Why won't X just stay unbroken? [02:16] so, I would like to fix the braindeadness in logout funcionality ( https://bugs.launchpad.net/ubuntu/+bug/285141 ) but there are rumors of APIC changes... So, what is now the proper way to have script power.sh executed when ever someone presses power button (the one on PC, not on keyboard) [02:16] Launchpad bug 285141 in ubuntu "logout box + no way to kill computer = data corruption" [Wishlist,Confirmed] [02:16] wgrant: what fun would that be?? [02:17] LimCore: the acpi stuff is sort of in a state of flux [02:18] LimCore: acpi-support is still used for some things, but other stuff is moving towards hal, and pm-utils [02:18] bryce: True... [02:18] But I think this might be a clientside change. [02:18] Hmm. [02:18] bryce: but I hope, that no matter what system uses, in the end system WILL provide a way to execute user script on common ACPI event like power-off button, right?! [02:18] Er, serverside. [02:19] LimCore: I haven't had a chance to go through pm-utils and learn the new world order for acpi, so sorry I don't know [02:19] there should be some powerdown.d/ directory or something. And there my patch would go, to fix above bug (to do, so that pressing power button repeataly will turn off pc) [02:20] *turn off the system [02:20] LimCore: I'd encourage you to review the pm-utils source [02:20] bryce: I dont have now time for that, unfortunatelly, yet I like to fix the problem. If I do it using current acpi-support, then can I ask someone to port it to the new way, pack it, and include in 8.10? current way of logout is realllly brain dead [02:21] Looks loosely like they belong under /etc/pm/ somewhere, although one wants to check the implementation before blindly stuffing something there. [02:21] LimCore: is that release critical? [02:21] if not, it won't get done. [02:21] Hobbsee: yes [02:22] bad design of logout funcionality leads to fs corruption. seems horrible to me [02:22] LimCore: provide patches then. [02:22] I almost lost my fs today, thanks to that [02:22] Hobbsee: thats what I want to do, and therefore my question. [02:23] LimCore: for intrepid, if you can make it work in acpi-support, porting it to pm-utils should not be necessary [02:24] bryce: cool, thanks [02:24] can I implement this in C++? [02:25] or in C or even bash, this utility must go to base system imho [02:25] LimCore: bash would probably be the only thing likely to get accepted [02:25] ok [02:25] Well, actually, POSIX shell would be preferred to bash, generally. [02:25] like, /bin/sh ? [02:25] right [02:26] /bin/sh means different things for different people, but yes :) Test with dash. [02:26] acpi-support is currently a mix of bash and sh. I did convert some simpler stuff to sh [02:27] um, have you tried on an up-to-date Intrepid Ubuntu (GNOME)? [02:27] james_w, tried which? [02:27] doesn't pressing the power button show a menu to shutdown, with a 60 second timeout that shuts down the machine? [02:27] * Hobbsee notes kde used to support that, too. [02:27] (as in, automatic shutdown when power button is pressed) [02:28] james_w, Does for me. [02:28] james_w: Actually, it shows a logout dialog, not a shutdown dialog (at least here). [02:28] RAOF, how updated are you? [02:28] RAOF: are you up to date, it was changed this week. [02:29] A day or two late. [02:29] james_w: 60 s is too much. Plus, the goal is pressing button will also shutdown machine that is partially hanging (i.e. 100% cpu usage) [02:29] Might be it. I got the logout yesterday. [02:29] LimCore: well, that's quit a bit more work. [02:29] also, it will not work when not in X [02:29] my idea is simple: system (scripts) react to pressing the power button. first 1,2,3 times nothing (but WM can react) [02:30] 4 - shutdown 5 - more aggressive shutdown etc [02:30] another use case is to get machine almost hanging by fork bomb [02:30] * jdong mumbles Alt-sysrq-REISUB under his breath [02:30] LimCore: if it's partially hanging, or fully hanging, will it really result in the filesystem getting finished properly anyway? [02:30] * jdong agrees with Hobbsee [02:30] * LimCore jdong points to his use cases in which lights are out and/or keyboard doesnt work. but yes, this is the goal, only by power button instead [02:30] you want to run a script when the system is being fork-bombed? [02:30] In the case of a hang, it doesn't help at all, as it won't trigger acpi-support|pm-utils [02:31] there's no guarantee that the flurry of shutdown scripts will execute correctly if it's fork-bombed [02:31] ok, perhaps this is not solution for forkbomb use case. it is for no-keyboard and no-screen cases [02:31] why is 60s too long? [02:31] user perhaps wants it off in 10s [02:32] a) ups will die in 30 s [02:32] * persia notes that it would be nice if the 60s didn't count down in 10s increments. [02:32] will the user die if the computer turns off in 60s? [02:32] b) thunderstorm [02:32] c) fire [02:32] etc [02:32] ok those are ridiculously far-fetched usecases. [02:32] jdong: no, but FS will [02:32] jdong: if you were out drinking, and didn't notice that there was a thunderstorm. [02:32] LimCore, It's going to take a while to sync the disks and shut down anyway. [02:32] jdong: until the first boom [02:32] persia: well, that's what I would have thought. [02:32] persia: that is why waiting 60 is too long. sync takes 1-3 sec usually [02:32] d) nuclear holocaust [02:33] jdong: thunderstorm and ups die in 30 s are my own use cases [02:33] ion_: i'm sure that c & d mean that you don't care about the laptop, in that case. [02:33] LimCore, How long does it take your machine after you select shutdown from the menu? Takes me 20-30 seconds. [02:33] or other computer. [02:33] so for that we should make the shutdown button work with less confirmation? [02:33] persia: correct, this is why 6th press will just sync and remount ro [02:33] frankly I already think Intrepid has gone off the nazi end for lacking confirmation [02:33] i.e. the logout/restart/shutdown buttons all have no confirmation prompt [02:33] jdong: as long as they *never* become like my work system... [02:34] Hobbsee, What's that like? [02:34] jdong: "shutdown". "OK! bang!" "oh, shit, another 3+ min wait for it to boot again" [02:34] jdong: first 3 presses do nothing. its not like users will press them by accident [02:34] persia: ^ [02:34] sync and remount-ro is not any less likely to corrupt your data! [02:34] particularly if it involves some SIGKILLS first [02:34] Oh. I had a configuration like that once. Very annoying. [02:34] LimCore: hmm, given this is sounding feature-ish, you may find it challenging to get such a thing accepted by the intrepid release team [02:35] jdong: sync + remount-ro is not less likelly to corrupt file system, then pulling out the plug? [02:35] bryce: yeah, i can outright decline it now, if you like :) [02:35] and we don't need morse code sequences for the power button... I'd be very much against that idea from a UI perspective. [02:35] but i figured i should at least listen to it first. [02:35] Hobbsee: *nods* [02:35] LimCore: it is not any less likely to corrupt the data, no. [02:35] jdong: ++. Little kids and computers. argh. [02:35] arent' filesystems good enough nowadays to handle this stuff, particularly when the machine is locked, anyway? [02:36] jdong: ok, then unmount, or whatever is needed [02:36] LimCore: are you listening? interrupting all disk activity via SOFTWARE is no safer than doing the same in HARDWARE. [02:36] Hobbsee: if you are so sure, you can try right away, especially try with XFS fs [02:36] LimCore: XFS doesn't even remount-ro when you tell it to [02:36] LimCore: nor does it completely sync. [02:36] LimCore: right, well, last I checked, we don't use xfs by default... [02:37] if you are worried about powerdown corruption you shouldn't be anywhere *NEAR* XFS. [02:37] hell XFS makes assumptions about disks that aren't even true except on expensive corporate storage devices. [02:37] jdong: well, then unmount [02:37] LimCore: how do you propose doing that? :) [02:38] this is a related problem, it should be more userfriendly to unmount DVD in use etc, is that fixed [02:38] why don't you test it? [02:38] afair latest gnome finally shows a list why it cant unmount [02:38] actually, last ichecked with a dvd in use, pressing the eject button worked fine. Maybe tha'ts not user friendly enough for you, i'mnot sure. [02:38] it could use a button to kill thoes applications. but that is not critical [02:39] lol no, we shouldn't give users a magical button to kill processes. [02:39] you do that and I will personally write an exploit for it. [02:39] jdong: there already is one, anyway. [02:39] jdong: well, at least, for GUI bits. in the panel. [02:39] (not on by default, fortunately) [02:39] why not? [02:39] hobbsee: It should only eject after you hit the eject button five times. :-P [02:40] jdong: it's how i save firefox's state :P [02:40] *sigh* where is desktop Linux going these days... [02:40] LimCore: because it can be used to kill processes maliciously? [02:40] jdong: just be greatful that the ones who tend to make the decisions upstream aren't currently here and talking... [02:40] ion_: no no, sudo something something ; ps aux ; kill -9 etc etc, is much more user friendly. For humanbeings. [02:40] LimCore: you shouldn't *have* to be force killing anything *at all*. [02:41] you shouldn't be using kill -9 if you care about corruption either. [02:41] I still don't see *ANY* sense in fscking killall -9'ing userland to "unmount the filesystem safely" [02:41] isn't there something counterproductive about doing this? anyone? [02:41] if the program's freezing, it's a bug. fix the program, instead of making it easier to killthings. [02:41] jdong: corruption of filesystem -vs- corruption of data in file written by given program because I terminated that [02:41] jdong: sure, but i don't thinkhe'slistening... [02:41] LimCore: your filesystem should not be corrupting when you uncleanly shut down [02:41] well, Im reading all you say [02:42] LimCore: take that up with your hardware and filesystem vendor. [02:42] namely for XFS this is a hardware problem [02:42] your hardware was obviously not designed to run XFS [02:43] jdong: I had such corruptions on ext3 as well, but I did not test recently. Still Im quite sure randomly pluging out power cable in middle of writes to ext3 will corrupt more then just the files that where being written to [02:43] * jdong thinks hard about why we don't configure to use XFS by default... [02:43] LimCore: it won't corrupt the filesystem but any in-transit data is at risk for being stale or incompletely written. [02:44] and that's *GASP* the same symptoms of killall -9. [02:44] so you are saying that killing -9 one program is not better then randomly pulling out the plug from pc? [02:44] guys, we have a release soon. This being discussed now is *not* a release critical bug, and it would be great if these discussions could be held elsewhere. [02:44] * jdong agrees with Hobbsee [02:45] LimCore: depending on what program, absolutely not. [02:45] it would be great if the participants would go and fix RC bugs instead of discussing it :-) [02:45] * bryce +1 [02:45] data corruption sounds like RC problem, doesnt it? With the confirmation box, no need to kill -9 anything [02:46] james_w: that too. [02:47] so, is it not? [02:48] LimCore: RC bugs are ones targeted | milestoned in launchpad [02:49] do we want to make some users have to hard reboot their boxes, or do we want to take 2 hours to fix it? [02:49] 2 hours? [02:49] LimCore, i'm not a developer, and not even i can take what you're saying here seriously. [02:50] elkbuntu: do you have some reasoning for that? [02:50] LimCore: provide the patch, and get it uploaded. It will then be reviewed. It may be declined for intrepid, which means you can get it into jaunty. [02:50] LimCore, yes. you're refusing to listen to other people's reasoning. [02:50] yes. what you are saying does not make much sense, you have not provided any valid solutions, and now you are continuing to disobey the requests to keep this channel on topic. [02:51] LimCore: unless you do this, no it will not be considered, and the discussions will not continue here. [02:51] elkbuntu: I responded to all arguments so far. Ok, which channel is on topic for this then? [02:52] LimCore, responding does not mean you listened properly. [02:55] apachelogger: how does it happen that a patch that's been in kde4libs for a year was responsible for bugs just filed? [02:55] (in the past two months, that is) [02:56] * Hobbsee eyes that kdebase-workspace upload [02:57] Hobbsee: yes, I skipped over that one in the queue [02:57] slangasek: the one about kmenuedit wasn't visible in KDE 4.0, because there was no visible way to start the editor at all [02:58] I am not sure why he broken icons one isn't older though, TBH bug reports for KDE 4 are really rare still [02:58] s/he/the [02:58] slangasek: i don't think it's right, either. [02:59] Hobbsee: what's it changing? [02:59] apachelogger: well, it's bumping an unsatisfiable recommends to an unsatisfiable suggests, to start with. [03:00] StevenK, hola [03:00] Hobbsee: python-plasma-examples is available here [03:00] apachelogger: in what repository? [03:01] Origin: Ubuntu [03:01] apachelogger: (apt-get policy python-plasma-examples) [03:01] 500 http://archive.ubuntu.com intrepid/main Packages [03:02] apachelogger: hmmmm, i'll try updating again, but my apt-cache isn't finding it. [03:03] Hobbsee: kdebase-workspace is actually the source package for python-plasma-examples [03:04] apachelogger: ah. wonder why it refused to find it previously. p.u.c doesn't know about it either yet [03:05] https://edge.launchpad.net/ubuntu/intrepid/i386/python-plasma-examples/4:4.1.2-0ubuntu10 [03:05] Hobbsee: puc is not the fastest ;-) [03:06] very weird either way though [03:07] apachelogger: ahh. so itis new. [03:08] pretty much [03:09] slangasek: if we're not building cds yet, then i presume that one's safe. [03:14] Hobbsee: kdebase-workspace? If you think it's appropriate, feel free to push it through [03:14] slangasek: OK [03:15] slangasek: i'm just not sure of cd building status. [03:16] CDs on Monday [03:16] right. [03:28] mdke: was ubuntu-docs going to get updated before release? [03:28] he is probably sleeping [03:30] nixternal: that's a point. it's been updated in the bzr branch, but never got uploaded. [03:30] actually, the final upload of ubuntu-docs will be for translations only [03:31] and that typically happens like, damn right now [03:31] nixternal: https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/ubuntu-docs/+bug/272772 too, preferably. it's RC. [03:31] Launchpad bug 272772 in ubuntu-docs "packages that Depend/Recommend/Suggest firefox (meta-package) must alternatively Depend/Recommend/Suggest abrowser" [High,Fix committed] [03:31] ya, I just saw that [03:32] ubuntu-docs shouldn't depend/recommend/suggest firefox as they aren't built to HTML, they stick in DocBook/XML format for ubuntu-docs [03:32] unless something has changed [03:32] nixternal: ubuntu-serverguide does [03:32] ahhh [03:32] does it dep on www-browser? [03:33] www-browser | x-www-browser or whatever it is [03:33] haven't looked in a while to be honest [03:33] * nixternal looks [03:33] nixternal: not on my sysetm. [03:33] looking now [03:33] Suggests: firefox [03:34] hrmm, that is nuts [03:34] should just recommend either www-browser | x-www-browser, not a specific browser [03:34] oh,score, Keybuk's tracking down this iwl3945 bug for us! [03:34] what is the bug? [03:34] nixternal: well, yes. [03:34] nixternal: the one above? [03:34] or the iwl? [03:35] 0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev [03:35] mine has worked great actually, but then again I don't use it all that much [03:35] nixternal: boot hang bug - https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/linux/+bug/263059 [03:35] Launchpad bug 263059 in linux "[regression] 2.6.27-7 sometimes fails to boot (iwl3945 issue?)" [High,In progress] [03:38] Hobbsee: yes, mdke fixed ubuntu-docs in bzr by suggesting www-browser .... [03:38] nixternal: right, yes, I see that in the bug, but it's not in the archive yet :) [03:38] Hobbsee: looks like he is currently importing translations [03:38] nixternal: oh, so that's related. right. [03:39] not related, but he will probably prepare the package shortly and get it uploaded [03:39] ah, cool. [03:39] he has been highlighted enough, he will update us in the next 12 or so hours I am sure :) [03:59] * calc back, and got his hair chopped off [04:08] slangasek: thanks wrt 223476 [04:08] slangasek: i'm pretty sure i brought that bug up before but it was several months ago [04:09] slangasek: and we were already too low on space at the time [04:09] * Hobbsee kills more bugs off the intrepid list. [04:10] kill kill kill [04:13] * calc is getting rid of his bugmail queue [04:13] * nixternal is trying === LimCore_ is now known as LimCore [04:23] gar, new vmware installs into /usr without asking you [04:23] it should at least into /opt if not /usr/local [04:26] the FHS is for other people [04:27] sbeattie: were you planning to provide a patch for https://bugs.edge.launchpad.net/ubuntu/+source/djvulibre/+bug/277301? [04:27] Launchpad bug 277301 in djvulibre "package update-manager 1:0.93.18 failed to install/upgrade: ErrorMessage: SystemError in cache.commit(): E:Sub-process /usr/bin/dpkg returned an error code (1)" [High,Triaged] [04:31] lifeless: until 6.5 it asked where you wanted to install it [04:33] well it is a lot simpler install, but too simple i think since it installs into an illegal (for 3rd party) location :\ [04:38] calc: 223476 should probably be fix committed / fix released - i accepted the u-m upload to add -math to the seeds. [04:39] * NCommander is finally free from classwork! [04:41] NCommander: yay! so, fix some bugs! [04:41] Hobbsee: cool :) [04:41] Hobbsee, working on fixing lpia's kernel ;-) [04:41] NCommander: that's good too :) [04:42] Hobbsee: done, i added it to hardy as well on the bug report to have it examined when i get a chance [04:43] calc: I was being droll [04:43] calc: \o/ [04:45] lifeless: i know, i just wanted to rant about it since it is really annoying :\ [04:45] * lifeless hands calc a blog [04:46] heh :) [04:46] (it is ontopic here, just saying, a good rant deserves an audience) [04:47] yea [04:47] i haven't had a blog in several years, i probably should set one up again [04:48] calc, join the planet [04:51] NCommander: Hey hey [04:51] StevenK, so amitk broke the lpia build ;-) [04:51] (he forgot to bump the abi folder name) [04:51] Argh [04:51] Yeah [04:51] I'm getting closer to nailing this [04:52] Almost everything is getting built now, but I'm debating if I should move the binary-indep rules to binary-arch [04:52] (since the lpia kernel strictly speaking has no arch all packages) [04:52] Right [04:52] Personally, do whatever makes the diff smaller [04:52] amitk might feel differently [04:53] Well, that would technically make the diff get larger, but having binary-indep called from binary-arch shouts hack [04:53] "Duh" [04:54] launchpad should host blogs :) [04:54] it does everything else already, heh [04:54] calc: erk. [04:54] Yes, "Erk" [04:56] calc, SourceForge has that feature even [04:58] * calc wonders why up arrow in vmware 6.5 causes printscreen [05:02] StevenK, WOOO< success! [05:02] Woot [05:02] dpkg-deb: building package `linux-headers-2.6.27-4-lpiacompat' in `../linux-headers-2.6.27-4-lpiacompat_2.6.27-4.8_lpia.deb'. [05:02] <[reed]> calc: 8.10 remapped all my keybindings on my thinkpad [05:02] Need to go through and make sure everything actually worked sanely [05:02] <[reed]> I wasn't happy at all [05:02] <[reed]> considering they are all wrong [05:03] <[reed]> and like three different random buttons now printscreen instead [05:03] StevenK, I can upload this to a PPA, and then smoke test lpia-lrm/lpia-meta [05:06] StevenK, second woo moment, it appears at first glance the linux-lpia-headers packages are also properly working [05:06] dh_installchangelogs: I have no package to build [05:06] NCommander: To be honest, don't bother with a PPA [05:06] That however I'm still figuring out [05:06] NCommander: I just want it in the archive [05:07] Find someone who can commit to the git tree :-) [05:09] NCommander: It's more to be in the archive than the git tree at this point, given where we are in the release [05:09] more important [05:10] StevenK, well, right now, I'm ripping the rules a new one [05:10] THe actual debs are not being built because the debhelper magic is screwed up [05:10] So give me some time to finish twisting the rules into submission (everything is getting built which is a good thing) [05:12] and since I just need to rerun the install phase over and over, its not that time consuming [05:13] ^- StevenK [05:13] Fair enough [05:14] It will probably take me an hour or so to get this properly locked down (an install run takes about 10 minutes), and then I would like to do a full build run if you can tolerate it ;-) [05:19] I'd like to upload before I have to leave at 4:45pm local [05:22] StevenK, how long is that? [05:22] NCommander: An hour and change away [05:22] 1.5 hours. [05:27] StevenK, its building packages, I'll post the list once it finishs so we can make sure all the necesities are there [05:52] -rw-r--r-- 1 root root 556K 2008-10-18 00:41 linux-headers-2.6.27-4-lpia_2.6.27-4.8_lpia.deb [05:52] getting closer [05:54] We knew that one built [05:54]