[00:00] hehe :-) [00:00] according to http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html, it seems %U is for urls whereas %F is for a list of files directly [00:00] I want to upload the near-perfect theseus package before ending tonite [00:00] so i think that %U makes more sense since it appears it can take either or [00:00] superm1_: http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s06.html [00:00] do you agree? [00:01] superm1_: yes, it makes sense [00:02] okay i'll finish this merge then now :) [00:03] oh well, that was the coup de grace [00:04] g'night all ..... [00:04] night [00:05] 33 [00:05] oops === Nightrose_ is now known as Nightrose [00:16] Well goodnight folks, it was good fun [00:18] that's what... that's what.... *must resist* ahhh that's what she said! [00:19] jdong: :-) hehe [00:34] mok0: About theseus: why gawk vs. mawk? mawk is smaller and more efficient for most cases. (doesn't really matter: I just couldn't resist the challenge) === superm1_ is now known as superm1 [00:57] some reviewer online? [01:03] dsop: Yes. Which package? [01:09] Hey folks. Anyone familiar with/run OpenSUSE? [01:10] persia: My buddy!! :-) [01:10] * Fujitsu stabs bddebian over to #opensuse [01:10] bddebian: I haven't run SUSE since before Novell had an interest. Can't really help you here. [01:11] persia: No I still have to bug you about comixcursors ;-P [01:11] * StevenK has never run SuSE [01:11] bddebian: The preinst / postinst still doesn't work? [01:11] persia: gcutils [01:11] I don't want to run SUSE, I want to figure out if they have patch clanbomber to build against clanlib 0.8 [01:12] persia: No, I suck :-( I think it should work. [01:13] dsop: It's best when advertising your package to put something like: "Could a reviewer please look at http://revu.ubuntuwire.com/details.py?package=gcutils ? I've addressed the last set of comments, and am looking for my first advocate". I'll take a look, and let you know if I see anything in particular. [01:13] bddebian: The CVS is fairly easy to read, and the patches reasonably organised. Take a look :) [01:14] Okay persia, please can you review my package http://revu.ubuntuwire.com/details.py?package=gcutils. I tried to fix things and i'm looking for an advocate. [01:14] persia: for sure you are right, i've to be friendly [01:15] dsop: Just comparing the debdiff to the last comments, I don't see the changes for the manpage differentiation. [01:15] persia: because i'm the upstream author, i also changed the orig.tar.gz [01:16] dsop: Right. That's what I get for looking at the debdiff :) [01:18] * StevenK kicks automake [01:19] persia: Sorry, what CVS? [01:19] dsop: Looks fairly clean to me. I don't have the tools available to put it through proper testing now, but perhaps another reviewer might. If you're feeling especially cool, you might make the scripts point to the local license file pre-installation, and to the /usr/share/doc/ file post-installation, but that's certainly not important enough to block. [01:20] persia: thx, i'll think about that. [01:24] bddebian: I'm not finding the link now: maybe google will be nicer to you. http://download.opensuse.org/repositories/ has all the code though. [01:27] Hi Hobbsee. [01:27] * Fujitsu requests that rkward be given back on all archs but lpia and hppa. [01:27] * Hobbsee waves [01:28] Fujitsu: given back [01:29] Hmm, I can find the source rpm, does that help me any? [01:29] Hobbsee: Thanks. [01:29] bddebian: Yes. Unpack it. There should be separated patches for all the changes. [01:29] no problem [01:30] How do I unpack an rpm? [01:30] Use rpm2cpio, I guess. === mneptok_ is now known as mneptok === zakame1 is now known as zakame [01:52] Hobbsee: online? [01:52] i was told that you are a revu admin> [01:53] dsop: yes and yes [01:53] i've a problem with my accound [01:53] Could someone tell me their thoughts on Tormod Volden's comment at the bottom of https://bugs.edge.launchpad.net/ubuntu/+source/nvu/+bug/99433 ? It seems like it might make sense, but I'm not sure what policy issues might be involved. [01:53] Launchpad bug 99433 in nvu "[needs-packaging] nvu html editor is not in the repositories" [Wishlist,Fix released] [01:54] my key is synced, so i can upload packages, but i never received an email concerning my revu accopunt [01:54] and if i try to recover, no message is display to descript [01:54] descrypt [01:54] decrypt... [01:54] you dont get a new account untill you make your first upload [01:54] imbrandon: There are uploads [01:54] Hobbsee: and I checked twice if i entered the right email address :) [01:55] whats one of th uploads ? [01:55] dsop: which email address are you using, and have you uploaded anything to revu yet? [01:55] tonyyarusso: I don't think it makes sense for SRU, but it would be nice for LTS->LTS upgrades. [01:55] sn_@gmx.net and yes i uploaded some packages (approx 10 times, and every package was shown on the revu site) [01:56] persia: Fair point. So I should just remember to do a second package for Hardy and not worry about the others too much? [01:56] Hobbsee: Can you please give back the following? They're some of the remaining fallout from the texlive mess. ara, backup-manager, blitz++, bobcat, bochs, cfengine2, cffi, cjk, cl-asdf, cmucl [01:56] * tonyyarusso guesses that a significant portion of the userbase is probably LTS - Edubuntu especially [01:57] tonyyarusso: I'd say so. If there are people with leftovers from edgy, they should get fixed during gutsy -> hardy, but pushing NEW in SRU is discouraged. [01:57] imbrandon: you deal with revu, i'll do the givebacks [01:57] Hobbsee: ok [01:57] persia: okay, thanks [01:57] dsop: looking into it now [01:57] * Fujitsu wonders if somebody can be poked into doing a mass-giveback soonl [01:57] s/l$/./ [01:57] imbrandon: thanks [01:58] * persia thinks there are enough blow-by-blow givebacks happening that the "mass-give-back" won't have many candidates by the time it is decided. [01:59] * emgent heya [01:59] apachelogger__: ah, just saw the e-mail about you - and now I know what on earth this nick is! Congrats. [02:00] Fujitsu: given back all but blitz++ [02:00] Hobbsee: Because your buildd.py doesn't urlencode properly? [02:01] cjk also may be botched [02:01] Fujitsu: yeah [02:02] * Fujitsu concocts a package name that does bad things. [02:03] Fujitsu: appears it doesn't like searching [02:05] Hobbsee: What? [02:05] File "/usr/lib/python2.5/re.py", line 134, in search [02:05] return _compile(pattern, flags).search(string) [02:05] File "/usr/lib/python2.5/re.py", line 233, in _compile [02:05] raise error, v # invalid expression [02:05] sre_constants.error: multiple repeat [02:05] (there's more than that) [02:05] Hobbsee: oh that's a GREAT error message. Go python! [02:06] heh [02:06] Traceback (most recent call last): [02:06] File "/usr/local/bin/buildd.py", line 39, in [02:06] m = re.search('"/ubuntu/%s/\+source/%s/(\d[^"]+)"' % (release, package), page) [02:06] is the top bit [02:06] * persia likes stacktraces [02:06] Hobbsee: reminds me of a popular embedded chipset C compiler, whose only error message is "syntax error" or "Abort. [02:06] :D [02:06] dsop: hrm even looking at the code i dont know whats up, you will likely have to get siretart's attention and/or email him [02:06] hah! [02:07] imbrandon: What's the issue? [02:07] i'd imagine its soemthing with the _ in your email [02:07] Fujitsu: http://revu.ubuntuwire.com/lostpw.py?email=sn_@gmx.net [02:08] imbrandon: hm, okay [02:09] imbrandon: do you have his email? [02:09] dsop: i think Fujitsu is also looking into the issue [02:09] k [02:09] dsop: siretart@ubuntu.com [02:09] if it comes to that [02:09] Well. It is now a known fact that the upper blue mountains power grid is as flaky as the first Linux release. :p [02:10] TheMuso: solar :) [02:10] imbrandon: Trees + not enough sun most of the year. === doko_ is now known as doko [02:18] Mmm. There's going to be a huge storm [02:18] oh dear [02:19] StevenK: We just had a lot of thunder and lightning here for about 45 minutes. [02:19] StevenK: Probably similar to what we just had. [02:19] StevenK: However your power grid will likely stay up. [02:19] OK so how the hell is rpm2cpio supposed to work? [02:19] Unlike ours... [02:19] bddebian: rpm2cpio < .rpm > .cpio [02:19] c [02:19] ugh fingers [02:21] StevenK: I tried that but it just dumps a bunch of crap to the console [02:22] Am I suppose to dump it to something? [02:22] Hobbsee: Can you please resync the REVU keyring? [02:23] bddebian: The output is the .cpio file, no? [02:23] bddebian: Can you paste the exact command you ran? [02:24] imbrandon: I've sorted out dsop's issue (the key on keyserver.ubuntu.com was out of date). [02:24] rpm2cpio clanbomber-1.05-76.5.src.rpm [02:24] bddebian: Right, that will output the cpio archive to stdout. [02:25] Oh those are redirects not options for < foo > eh? :-) [02:26] Ahah, you're right, it did look a bit like that. [02:26] OK so then wtf do I do with a cpio file? [02:26] Use cpio to extract things from it. [02:36] Fujitsu: ahh [02:37] imbrandon: The UID containing that email address wasn't on REVU's keyring, so it died. [02:38] Well shit, that was a waste of time for nothing.. :-( Thanks though StevenK, Fujitsu, persia [02:39] bddebian: No patches? :( [02:39] Yeah but not to build against clanlib 0.8 [02:40] I'm freaking sucking more than usual lately :-( [02:41] btw is there an review admin that might review my gcutils package. It would be really nice. So i please an revu reviewer to take a look at this package, as I tried to fix all the problems from the previous comments. [02:42] * persia thinks it looks pretty good and someone should give it a proper review [02:45] As soon as I've finished my buntuStudio work, I'll take a look. [02:45] UbuntuStudio [02:45] c [02:45] ugh [02:51] persia: If you get bored/have time: http://www.bddebian.com/packages/debian/comixcursors/ [02:51] persia: what is the policy on applying patches to software that is in the repository? [02:51] * joejaxx never attempted to add his gnupg patch [02:51] Or if anyone else feels like seeing how I have f'd up the pre/post/rm/inst [02:52] joejaxx: ??? [02:52] it makes the maximum bit key limit higher :D [02:52] instead of it being at 4096 [02:52] joejaxx: no. you may only add patches to newly done software. nothing in the archive is allowed to be patched! [02:52] :( [02:52] oh ok [02:52] :) [02:52] :P [02:52] heh [02:52] joejaxx: you can fix it in hardy [02:52] Hobbsee: that is what i meant :D [02:53] :) [02:53] right now the limit is 4096 [02:53] i want to make it higher lol [02:53] joejaxx: Patches are welcome, but new functional changes require a bit of justification. [02:54] persia: the maximum is too low [02:54] :P [02:54] bddebian: Be careful about publishing a signed changes file. [02:54] Gah, crap [02:54] thx [02:54] * imbrandon uploads bddebian packages to ubuntu [02:54] persia: Best not upload to PPA, then. [02:54] Fujitsu: Does that expose .changes publically? [02:55] Fujitsu: what?!? [02:55] persia: In 1.1.10 in did, but it has been mostly fixed now. [02:55] bddebian: you are running hurd? debian/hurd? [02:55] "semi-fixed" [02:55] Fujitsu: That's very dangerous. If that's true, anyone on earth can put anything I put on a PPA directly into hardy. [02:55] dsop: On about 5 machines, yes [02:56] persia: Exactly. [02:56] persia: at least you don't have main upload rights [02:56] bddebian: i have not tried that in a while, thanks for reminding me :D [02:56] bddebian: wow, nice i've to try it out, but it's not that easy to get a lot of information about the current progress ,is it ? [02:56] Hobbsee: That's fine. I only maintain 1 package in main anyway. [02:56] There was a semi-workaround put in place for 1.1.11, so it's not quite as blatant (ie. the links have been removed). [02:57] * persia decides not to prep the libopenal1 transition in the PPA until 1.1.12 is out and fixes that. [02:57] Good idea. [02:57] woot, $70 in my new computer fundraiser , its getting there :) [02:57] lol :) [02:57] Fujitsu: grr all the more reason for them to clear my /pool [02:57] dsop: Sure it is, see the wiki on that same site. ;-) http://www.bddebian.com/~wiki/ :-) [02:58] Pity though, as it allows for lots of acceleration on amd64 & powerpc. [02:58] Fujitsu: Do you happen to know the bug #? [02:58] Fujitsu: it's a private bug [02:58] persia: It's private4. [02:58] Hobbsee might know it, though. [02:59] i don't [02:59] * persia fails to subscribe, and hopes there will be public disclosure of the fix. [02:59] ha [02:59] It's fairly safe at the moment. [02:59] Fujitsu: Safe enough to process an entire library transition with ~50 packages that might not work, and doesn't belong in hardy? [03:00] I probably wouldn't risk it. [03:01] * persia rejects that definition of "fairly safe2 [03:08] bddebian: Looks sane to me, but might be worth a mention in the changelog. I can't test now :( [03:09] I finally managed to compile juce against it's packaged external dependencies [03:09] instead of relying on inlined sources in the tarball [03:10] proppy: Excellent. You get a gold star! [03:11] persia: thanks for supporting ! [03:11] next step will be to be the new upstream [03:11] I don't know if there are any guidance in this field [03:12] I guess just crafting a new tarball and host it on a http is not enought [03:12] persia: It doesn't work, I've tried it. I get: /var/lib/dpkg/tmp.ci/preinst: 13: ComixCursors-Orange-Regular: not found [03:12] * persia looks again, more carefully [03:14] bddebian: Try putting quotes around REPLACE_ME_SHIP_LIST. I suspect it's doing something like `REPLACE_ME_SHIP_LIST=/some/theme/file /some/other/theme/file and attempts to execute the second argument. [03:14] I was just thinking that a minute ago. [03:22] Hi all. [03:22] I would like to join the MOTU team - but I need a mentor first [03:22] choudesh: well you dont "need" [03:22] a mentor to help [03:23] and after helping a while you will be invited to join [03:23] imbrandon: true - I would like the help of a mentor. ;-) [03:23] imbrandon: I know how to package debs - just not sure what needs to be packaged. is there a launchpad page on what needs to be packaged? [03:23] ahh okies :) well in that case i would email the mentors front desk as usgested on the wiki [03:24] and request one to be assigned [03:24] imbrandon: can I get some linkage to the front desk? [03:24] choudesh: well NEW packages really arent the best way for new contributors IMHO, you might check qa.ubuntuwire.com for bugs [03:25] to get some experince [03:25] and buys taged "bite-size" on LP are also good [03:25] bugs* [03:25] persia: Well at least it acts differently: :-) [03:25] /var/lib/dpkg/tmp.ci/preinst: 35: SHIP_LIST: not found [03:25] /var/lib/dpkg/tmp.ci/preinst: 35: TMP_THEME: not found [03:30] imbrandon: seems at the moment all bitesize bugs have fixes proposed. ;-( [03:30] sure then apply the fixes and request a sponsord upload :) [03:30] thats the point of them [03:31] how do I request a sponser upload? === _czessi is now known as Czessi [03:43] * emgent heya [03:54] choudesh: I'd recommend reading https://wiki.ubuntu.com/MOTU/Contributing to get started. http://qa.ubuntuwire.com/uehs/no_watch.php is a good list of packages that need work. [03:55] morning mdomsch [03:55] good evening Hobbsee [03:55] mdomsch: keep up with the times, will you? [03:56] it's 3pm! [03:56] 5pm, even! [03:56] * Hobbsee mutters about backwards people :) [03:56] Damnit, fixed that, now getting a grep usage error :-( [03:56] you're always a step (or 17 time zones) ahead of me [03:57] bddebian: Put quotes around $(TMP_THEME) :) [03:58] http://www.ideastorm.com/article/show/75123?comment_id=98964#comment98964 [03:58] rough draft of how to do BIOS updates on 240+ Dell system types from within Ubuntu [03:58] heya mdomsch [03:59] greetings imbrandon [03:59] bddebian: Also, line 14 might benefit from sed -n "s!$(ICONDIR)/$.*$.theme/p" [03:59] Err.. "s!$(ICONDIR)!$.*$.theme!p" [04:00] single quotes won't expand the variable, and there's not usually a good reason to call sed twice. [04:02] Oh, use double quotes instead of single quotes? [04:02] zomg, i got past the iniramfs bug on hardy ppc and got X and all working :) [04:02] bddebian: If you want $(ICONDIR) to mean anything :) You might need to escape * - best to test. [04:03] means UW will soon have a ppc box to access soonish [04:03] :) [04:03] brb [04:04] mdomsch: Might it be worth adding `aptitude install $(bootstrap_firmware -a)` in a small wrapper so people don't need to remember commands? [04:06] persia, yeah; on other distros it's yum install $(bootstrap_firmware) or up2date -i $(bootstrap_firmware -u) [04:06] mdomsch: do you have a lsit of all the dell systems that works on? [04:06] and apt-get is *supposed* to be able to ignore not-available packages, but it doesn't [04:06] Hobbsee, not really; most have "pretty names", but there are a few I don't have the name mappings for yet [04:07] * Hobbsee nods [04:07] basically, every system sold in the past 4-5 years, modulo a few with very early and broken update capability [04:07] mdomsch: Maybe you could have /usr/sbin/install-firmware-updates that checks /etc/release (or whatever), determines $dist and calls one of `yum install $(bootstrap_firmware)`. `up2date -i $(bootstrap_firmware -u)` or `aptitude install $(bootstrap_firmware -a)` [04:07] and modulo a few of the newest Vostro systems [04:08] persia, yes, a 'download_firmware' app would be a welcome addition I agree [04:08] mdomsch: nice :) [04:08] * Hobbsee wonders if there's anything of interest in them [04:08] * persia doesn't have tools available now, but thinks it's a 10-15 line shell script. [04:09] mdomsch: I guess the only thing that confuses me in particular is the for loop. Should be able to do without that. The rest looks rather exciting. [04:11] persia, yeah, it should be [04:11] the only challenge is knowing which tool should be used [04:12] when multiple tools are present [04:12] mdomsch: Of apt-get, aptitude, or dpkg? They should all be present by default. [04:12] apt-get vs aptitude vs yum vs up2date vs Novell tool hell vs [04:12] heh. I see now. I would think that /etc/lsb-release should provide hints, but it's a fair bit of detective work. [04:13] mdomsch: the solution to that is, of course, trivial [04:13] Hobbsee, when we sell considerably more Ubuntu/Debian systems than we do Red Hat systems on the whole, I'd agree with you. We're not there yet. :-) [04:14] mdomsch: if [! -e /usr/bin/dpkg]: ubuntu.install(). or something. [04:15] Hobbsee: doesn't help. dpkg.rpm is available. /etc/lsb-release is the key. [04:15] my syntax sounds wrong [04:15] persia, not all distros provide that by default :-( [04:15] but I could make firmware-tools depend on it I suppose... [04:16] if they don't, format them to ubuntu. i tell you, the problem is trivial! [04:16] mdomsch: They should. Not providing that is a bug. Not providing aptitutde or up2date or yum or what-have-you is a distro decision. [04:16] mdomsch: actually, i have a slight question -- does the script check for battery power? [04:16] pwnguin, no - that's an interesting idea though [04:17] the actual flash happens after a reboot, during very early POST [04:17] and *that* does check for AC [04:17] persia: Nice, well I got no errors and everything seems to work but I don't really know if it did the right thing for update-alternatives.. [04:17] ok [04:17] what happens if ac isnt found? [04:17] mdomsch: Ah, that's nice. [04:17] So what happens if you prep for flash update on batteries? Is the system in a good state after reboot? [04:17] pwnguin, the it tells you it can't flash and continues without flashing [04:18] persia, yes [04:18] how visible is that warning about the flash? [04:18] * Hobbsee wonders what happens if the flash fails. [04:18] bddebian: Test case: install the package from the repos. update-alternatives to a new theme. upgrade to your version. make sure your theme didn't get reset. [04:18] mdomsch: Ah. Good :) [04:18] pwnguin, it's on the screen for several seconds [04:18] persia: Oh aye, duh :-) [04:19] it might make sense to add a info popup (however that's done) to inform users that power is needed on reboot [04:19] Hobbsee: We laugh at you. [04:19] awww [04:19] Hobbsee, if the flash starts writing to the flash, and fails midway through for some reason, you're in trouble of course [04:19] oh, if the flash fails, we blame mdomsch, and come and kill him. got it. [04:19] but I've never seen that happen [04:19] * Fujitsu looks for BIOS upgrades for his Inspiron. [04:20] * Hobbsee just wants a battery upgrade :P [04:20] that's one of the reasons it's done by BIOS itself during POST - there's few things that can go wrong short of yanking the power cord [04:20] Oh and stop shipping broadcom wireless adapters in your laptops.. ;-P [04:20] out of curiosity, what happens if the power cord is pulled halfway through a flash? [04:20] mdomsch: it's only likely in cases of sudden power failure or extreme environmental conditions. [04:20] bddebian, we don't sell those with our Ubuntu systems :-) [04:20] mdomsch: assuming a battery backup, of course [04:20] Hopefully the battery is charged enough. [04:20] mdomsch: Ah nice. Smart. [04:21] * Hobbsee only managed to land one broadcom component [04:21] Mine has Broadcom Ethernet NIC, but that works fine. [04:21] mdomsch: also, this two stage install can introduce semantic inconsistancies -- the package can be "installed" but the BIOS can still be out of date. im not sure what can be done about that though [04:21] Fujitsu: 6400? [04:21] Other than parts of the card reader, everything works flawlessly. [04:21] Both laptops I "borrowed" from work had them. Luckily we had a few other so I switched to the Intel's that they had. -) [04:21] Hobbsee: 630m. [04:21] broadcom wired is fine, wireless sucks with Linux [04:22] pwnguin: postinst? [04:22] Fujitsu: ahhh. what, even now? [04:22] it's easily remedied with a $30 "customer kit" [04:22] persia: on a reboot? [04:22] mdomsch: ie. new MiniPCI card? [04:22] Fujitsu, yep [04:22] pwnguin: On install. State is inconsistent until next powered reboot. Notification to the user that powered reboot is required. [04:22] pwnguin, sure - I can have 240 bios images "installed", though only 1 would be appropriate for my system [04:23] I've got a bootable USB key like that, for manually running the update tool [04:23] anyways, i like the idea [04:23] just wanted to double check that it's not a recipe for disaster once digg finds out [04:24] pwnguin, we've been using it on RPM-based systems for a couple years [04:24] mdomsch: Out of interest, will it reflash the first time you're powered, or only on the first reboot? [04:24] Fujitsu, only on the first reboot [04:24] OK. [04:24] because the tool itself only throws the image into memory, and sets a cmos flag [04:24] Ah. [04:24] BIOS POST sees the flag, re-assembles the image, and does the flash [04:25] and kaboom! [04:25] http://linux.dell.com/firmware-tools for more details [04:25] Hobbsee, always the pessimist :-) [04:26] mdomsch: :P [04:26] Are there changelogs for the BIOSes around somewhere? [04:26] mdomsch: anyways, i brought up the semantics not because of the 240 images, but because you may have 0 installed if you reboot on battery [04:26] Fujitsu, great question [04:26] mdomsch: so i've been told. but really, watching things blow up is fun! [04:26] assuming they're not *my* things, of couse [04:26] Hobbsee: only when you have spares [04:26] Fujitsu, yes there are, but they're not included in the BIOS packages posted on support.dell.com, so they're not included in the .deb packages either [04:27] these days, you cant be a good computer student without a second computer ;) [04:27] It's only fun when you can see the magic smoke *and* have a spare. [04:27] pwnguin: as someone else does teh blowing up, and on their own equipment, it's all good [04:27] they're posted separately on support.dell.com alongside the windows images [04:27] which sucks [04:27] well, i'm surprised my toshiba hasn't caught fire yet. [04:27] and is something we're looking to get changed [04:27] Ah, found it. [04:27] evening MOTU land! [04:27] Hey LaserJock. [04:27] hey LaserJock [04:27] LaserJock: Ponies! [04:27] How'd I guess. [04:27] *? [04:28] pwnguin, run 'update_firmware' again and it'll tell you. :-) [04:28] * persia fondly remembers the IBM 5151 [04:28] mdomsch: i dont own any dells, but its encouraging the progress im seeing ;) [04:29] pwnguin, it's just a framework - it could be extended to handle IBM, Toshiba, ... [04:29] pwnguin: id' really prefer not to test on my production machine :P [04:29] we spoke with the IBM team a few months ago about it, they liked the idea [04:29] Crap, didn't seem to work [04:29] mdomsch: anyways, as long as you prompt the user to remind them about AC before reboot, sounds good [04:29] there's one more catch [04:29] depending on the age of the system, you may need to reboot, run update_firmware, reboot again [04:29] * Fujitsu blinks. [04:30] 1. Update 2006 Intel logo. [04:30] because it needs 1-2MB _physically contiguous" kernel memory [04:30] What a useful update. [04:30] bddebian: OK. Now, take a backup of everything, and run one script at a time, to figure out what breaks. Might be the new theme installation. [04:30] which we've fixed for newer systems [04:31] the first reboot gives you a better chance of your memory not being too fragmented yet [04:33] i dont do any kernel hacking, but what happens if you request a kmalloc of 2MB and theres no existing holes big enough? [04:34] pwnguin, 1) you can't kmalloc >128KB; you use get_free_pages() [04:35] 2) get_free_pages fails, and the error is reported to update_firmware to tell you [04:35] so the kernel doesnt push user memory into VM to make more room [04:35] pwnguin, no [04:35] mdomsch: gonna make packages to flash the PERC controlers too ? hehe [04:35] * imbrandon would love that [04:36] imbrandon, we have them in RPMs yes, so it's quite conceivable [04:36] imbrandon: you need to get a new email server or something [04:36] mdomsch: rockin [04:36] PERC? [04:36] imbrandon, patches welcome... :-) [04:36] pwnguin: i havent resent [04:36] mdomsch: the only box i could "test" on only has a PERC 3 [04:36] :( [04:37] upgrade! [04:37] but mostly we have 5's in production with an occasional 4 [04:37] speakinig of upgrades.. [04:37] mdomsch: heh trust me all our production systems are on the 4hour plan :) [04:38] * Fujitsu wonders why the Inspiron 630m doesn't have a bios package. [04:39] Or at least it's not detecting any. [04:39] * Fujitsu checks Packages. [04:39] mdomsch: well, as long as that old system setup fails gracefully, that's at least something that can be addresed or fixed [04:39] mdomsch: are the .spec / srpms files available for the PERC firmware ? [04:39] Fujitsu, running as root? [04:39] i might be able to convert them [04:40] Fujitsu, 'sudo bootstrap_firmware | grep -i bios' [04:40] Fujitsu: PERC is the raid controlers in most modern dell rack servers [04:40] maybe other things too [04:40] imbrandon: Ahh. [04:41] mdomsch: Ahh, I didn't sudo it. [04:41] Fujitsu, yeah, it needs root to make the call to get the system type [04:41] So I just got PCI IDs. [04:41] Yep. [04:41] it should find an A04 package [04:41]