[00:06] <Sarvatt> building a new one now with that patch applied to see if it's any faster :)
[00:07] <Sarvatt> plymouth is kind of useless as-is otherwise since it loads the firmware so slow :(
[00:08] <RAOF> Yeah.
[00:12] <RAOF> Checking out nouveau_grctx.c it doesn't look like anything amazingly wrong is happening.
[00:13] <Sarvatt> sheesh this laptop is burning hot with nouveau
[00:13] <Sarvatt> WHOOPS
[00:13] <Sarvatt> nevermind, building the new lbm :)
[00:14] <RAOF> You've already uploaded one based on rc6, and this is your personal voodoo-generator-patched version, right?
[00:14] <Sarvatt> i'm just building this locally, wasnt planning on putting it on edgers/nouveau unless you think we should?
[00:15] <RAOF> I don't think we should.  Unless someone stops us shipping nouveau-firmware, I think that's the right thing to use until the voodoo generator goes mainline.
[00:16] <Sarvatt> yeah
[00:18] <Sarvatt> have to try all of this stuff out on a non-nvidia machine still
[00:19] <Sarvatt> dont have any ati that can use a PPA though (its a powerpc) and thats what i'm worried about
[00:21] <RAOF> I'd also like someone to try it out on a PPC-nvidia machine, too.
[00:22] <RAOF> My Intel laptop is perfectly happy running xorg-edgers/nouveau
[00:23] <Sarvatt> you installed linux-backports-modules-nouveau on it?
[00:24] <Sarvatt> is it using drm or lbm-drm if so?
[00:25] <Sarvatt> this lbm stuff doesnt apply to ports arches it looks like anyway
[00:25] <Sarvatt> rebooting into a voodoo generator lbm-nouveau now
[00:28] <RAOF> I installed linux-backports-modules-nouveau on it; it's using standard drm.
[00:28] <Sarvatt> http://pastebin.com/fc76bc53
[00:29] <RAOF> That's freaky and weird.
[00:29] <Sarvatt> only visual change was it had a black screen until plymouth instead of an 80x25 with a blinking cursor, no change in that plymouth wasnt up until right before X
[00:30] <RAOF> It's pulled up fb0 @ 3sec, then waits until 13sec to actually finish probing your output & switching modes.
[00:31] <Sarvatt> http://sarvatt.com/downloads/arcueid-lucid-20100203-6.png
[00:31] <Sarvatt> yeah thats strange
[00:32] <RAOF> You've got your display on, right?
[00:32] <RAOF> Or is the laptop still headless?
[00:33] <Sarvatt> yeah i'm on that machine now
[00:33] <apw> RAOF, Sarvatt you are not menat to run MUNGE-NOUVEAU ... it occurs at build time
[00:33] <Sarvatt> wanted to be sure that wasnt the problem
[00:34] <RAOF> apw: Yeah, we figured that out pretty quickly.  Thanks anyway :)
[00:34] <apw> you'll be telling me my shit makes sense next
[00:35] <RAOF> Quite a lot of sense, yes. :)
[00:35] <RAOF> Sarvatt: Feel like booting that laptop with some drm debugging enabled?
[00:36] <Sarvatt> doing it now
[00:38] <Sarvatt> http://sarvatt.com/downloads/nouveau.debug.log
[00:39] <RAOF> apw: Is there any special reason that linux-backports-modules-nouveau is only i386 & amd64?  Nouveau should work - and there's relevant nvidia hardware - on PPC as well.
[00:43] <RAOF> Sarvatt: I'm not sure that's actually nouveau's fault, now.  It looks like nouveau is set up & ready to go @ 3sec, then gets asked to do a modeset @ 13sec, and after that everything is right.
[00:50] <kklimonda> Sarvatt, the new lbm you have uploaded looks broken - all .debs are 5KB
[00:55] <Sarvatt> oh nasty
[00:57] <Sarvatt> RAOF: mind uploading yours? looks like a bunch of files got corrupted on my filesystem
[00:58] <Sarvatt> everything in updates/ is 0 bytes
[00:58]  * RAOF bumps the version and uploads.
[00:58] <Sarvatt> sorry about that :(
[00:59] <RAOF> S'ok.
[01:09] <Sarvatt> ok the plymouth problem isn't even nouveau specific, my intel machine is having the same problem since the update to plymouth 0.8.0~-8
[01:09] <RAOF> I don't think I've booted this intel laptop recently enough to pick that up.
[01:10] <RAOF> Also, I need to bust out the busybox to mount my dm-crypt home anyway.
[01:10] <Sarvatt> can't shutdown or suspend or anything with this plymouth because it just hangs
[01:11] <Sarvatt> which is the default plymouth theme again?
[01:11] <Sarvatt> ah --reset works
[01:12] <Sarvatt> theres nothing plymouth related in the initrd anymore when i extract it
[01:12]  * kklimonda said so
[01:12] <kklimonda> ;)
[01:15] <Sarvatt> ugh, i haven't been following #ubuntu-devel today, alot of talk about it's broken-ness right now :D
[01:54] <bryce2> pitti and I debugged the rethrow signals patch
[01:54] <bryce2> it works now and I've uploaded it to lucid.
[01:54] <bryce2> cya
[01:58] <Sarvatt> so apparently the change to not having a splash for more than a second is an intentional change now
 you could set the FRAMEBUFFER=y option in /usr/share/initramfs-tools/conf-hooks.d/ to force it
[01:58] <Sarvatt> thats what we have to do to see the splash
[02:00] <Sarvatt> no plymouth in the initrd so it's mountall (virtual-filesystems) -> udev -> udevtrigger -> plymouth-splash then X with it's less than 1 second start time now :)
[02:03] <kklimonda> Sarvatt, dont forget about ureadahead
[02:03] <RAOF> Ok.
[02:04] <RAOF> I wonder why my laptop throws up the splash early, then.
[02:04] <kklimonda> it does boot really fast though - but the experience sucks although the pre3 lbm package helped me - no londer weird colors at boot but the expected console
[02:06] <Sarvatt> it's a shame because it was a really nice boot process yesterday and you didn't get to see it because of that :D
[02:08] <Sarvatt> having the splash up at 2 seconds at full resolution was nice
[02:15] <Sarvatt> phew yeah changing OPTION=FRAMEBUFFER to OPTION=FRAMEBUFFER=Y at the top of /usr/share/initramfs-tools/hooks/plymouth and doing an update-initramfs -u got it back in the initrd
[02:17] <RAOF> Now, does that make nouveau bring up a nice framebuffer earlier?
[02:17] <Takyoji> Looking for testers of proprietary drivers on 10.04?
[02:18] <Takyoji> (just joined the mailing list, and noticed a message in the archives for the ubuntu-bugsquad mailing list)
[02:19] <Sarvatt> http://paste.ubuntu.com/368600/
[02:19] <Sarvatt> XD
[02:19] <Sarvatt> rebooting now to find out
[02:24] <Sarvatt> http://pastebin.com/f7a4c889e
[02:24] <Sarvatt> 6 seconds in it showed up, udev starts like 10 seconds sooner this way too
[02:26] <Sarvatt> it still waits for mountall and fsck checks where it didnt before
[02:26] <Sarvatt> so its not as early as before, the fsck stuff happened underneath the splash before
[02:26] <Sarvatt> but i get about 10 seconds of splash and can see the progress bar this way instead of just a flicker before X starts
[02:42] <RAOF> Oh!  It's probably udev that triggers the console update.
[02:48] <Sarvatt> we might get classic mesa drivers for nv0x-nv2x in edgers by the time lucid releases too :)
[02:49] <Sarvatt> heck, i could import and build it now
[02:50] <Sarvatt> http://cgit.freedesktop.org/~currojerez/mesa/commit/?h=mesa-next&id=9d4bcd1afb7b483954ef96af65397c2cf687eb65
[02:51] <Sarvatt> vish: http://cgit.freedesktop.org/mesa/drm/commit/?id=1802e1a4e747b5906d3af10c4a53fd457eddcbb4
[02:51] <Sarvatt> fix for your log spam if the ddx patch didnt fix it completely
[02:52] <Sarvatt> maybe we should just do a git checkout of libdrm if nouveau is going in anytime soon
[02:53] <RAOF> How easy is it to make mesa build the gallium drivers, too?
[02:54] <RAOF> I guess it's easier to add a classic driver to the build than to work out how to make gallium fly.
[02:55] <Sarvatt> its over my head, i dont know how it changes the resultant libGL.so.1 when you compile gallium into it and if things work with non-gallium when you build gallium stuff
[02:57] <Sarvatt> i know it wants to use the gallium dri modules instead of the classic ones when i build it here but dont know if thats because of how i configured it
[02:58] <Sarvatt> the mesa build system is a nightmare :(
[03:00] <Sarvatt> would be super easy to add the classic mesa nouveau driver. just a patch and adding it on one line in the rules
[03:01] <RAOF> Yeah.
[03:02] <Sarvatt> they disable the gallium drivers to let the classic ones work it looks like in that branch so something tells me if you build gallium at all its gallium or nothing like I feared :(
[03:05] <Sarvatt> with mesa being shoved away to /usr/lib/mesa for the alternative stuff maybe it'd be easier though, just throwing it in /usr/lib/mesa-gallium and setting up the alternatives for it
[03:06] <RAOF> Mayhap.
[03:07] <RAOF> This isn't urgent, though; it'll be MM stuff at best.
[03:10] <Sarvatt> that actually doesnt seem *that* hard to do now that i think about it, I stopped messing with it because it seemed like they wouldnt coexist but i could reuse alot of the alternatives stuff already there that I was sketchy on. maybe if I get a day off of work someday I'll work on it :D
[03:11] <Sarvatt> figuring out the right configure flags to use will be the hardest part
[03:13] <Sarvatt> I bet I can snag that info off gentoo too
[03:16]  * Sarvatt tries to dig up a nv0x-nv2x nvidia card to test the classic mesa nouveau drivers
[03:19] <bjsnider> Danag can do it for you in the other channel
[03:19] <bjsnider> he's got an old riva tnt or something
[03:20] <Sarvatt> nv2x is geforce 5 isnt it? or geforce4?
[03:20] <Sarvatt> thinking its 5 because 4 was just a speed bumped and rebranded 3 afaik
[03:20] <bjsnider> i dunno. naming conventions are dull
[03:23] <Sarvatt> woohoo, remembered i have a geforce4mx with a pci-agp adapter in my efika
[03:24] <Sarvatt> geforce 5 was nv4x ah
[03:24] <Sarvatt> err nv3x
[03:25] <RAOF> The geforce4mx is actually a geforce2
[03:25] <Sarvatt> yepyep
[03:25] <bjsnider> then why is it called..
[03:25] <bjsnider> never mind
[03:26] <RAOF> bjsnider: BECAUSE
[03:26] <bjsnider> there you go
[03:26] <RAOF> It's higher-clocked, IIRC.  But it's a geforce2 core
[03:26] <bjsnider> nvidia still does this stuff to this day
[03:33] <Sarvatt> hmm libgl1-mesa-dri-gallium? libgl1-mesa-gallium-dri?
[03:34] <Sarvatt> libgl1-gallium-dri? I dunno
[03:35] <RAOF> libgs1-gallium-dri probably.
[03:35] <RAOF> What do we do with the other statetrackers?
[03:35] <Sarvatt> libgjs on the brain? :D
[03:36] <RAOF> I FIXED THAT, DAMNIT!
[03:36] <RAOF> :)
[03:36] <Sarvatt> yeah I saw, and thank you :)
[03:36] <RAOF> Do we care to split out the other state trackers?
[03:37] <RAOF> Maybe it's just libgl1-gallium
[03:37] <Sarvatt> i'm just going to start with the basics, was just using -dri as an example to try to figure out how to name it
[03:38] <RAOF> Yeah.  I don't think we need the dri in the name; maybe libgl1-mesa-gallium?
[03:39] <Sarvatt> well I mean I was thinking of building the gallium dri drivers too and putting them all in the seperate package, could just install everything in one package though to start
[03:40] <Sarvatt> the radeong_dri.so is apparently in a usable state now
[03:40] <RAOF> fun!
[03:47] <Sarvatt> i need a complete configure flag that enables nouveau/intel/radeon gallium drivers and builds the gallium dri stuff too to make a new confflags target in the rules
[03:48] <bryce2> https://wiki.ubuntu.com/X/Troubleshooting/NvidiaDriverSwitching#preview
[03:48] <Sarvatt>  ./configure --with-state-trackers=dri --with-dri-drivers= --with-driver=dri --enable-gallium-intel --enable-gallium-radeon --enable-gallium-nouveau?
[03:50] <RAOF> You can drop the --with-driver=dri bit.
[03:50] <RAOF> I pass "glx,dri,vega" to --with-state-trackers, personally.  I'm not totally sure why, though :)
[03:51] <Sarvatt> ah defaults to dri, I see
[03:56] <Sarvatt> need --disable-gallium-svga now it looks like
[03:59] <RAOF> I didn't think that actually built by default, did it?
[03:59] <RAOF> You also need newer dri2 protocol headers, don't you?
[04:01] <Sarvatt> they're in edgers
[04:02] <RAOF> Nifty.
[04:17] <Sarvatt> what does 101_ubuntu_hidden_glname.patch in mesa do?
[04:19] <Sarvatt> "Re-add debian/patches/101_ubuntu_hidden_glname.patch since we use GLX_TLS now. An explanation of the patch would be nice though.." is all i see in the history
[04:19] <Sarvatt> http://git.debian.org/?p=pkg-xorg/lib/mesa.git;a=blob;f=debian/patches/101_ubuntu_hidden_glname.patch;h=1d1d066c7e8b10bb594f7b3171b2bb3cb1d6ebdc;hb=0748753b1fbb808dc4a6e501a80b822dcea661ac
[04:25] <RAOF> Sarvatt: That's a fine question.
[04:26] <bjsnider> someone's not commenting a patch? unheard of
[04:29] <bjsnider> doesn't the code itself provide some notion of what it's doing?
[04:31] <RAOF> It looks like it's unhiding a function, but the source it's modifying is assembly, and it's been ages since I touched a microprocessor like that.
[04:32] <bjsnider> no clue about who wrote it?
[04:32] <bjsnider> or should it be who diffed it
[04:33] <bjsnider> somebody had to originally post it to a mailing list right?
[04:36] <RAOF> No.  We don't use revision control for packaging (yet).
[07:28] <tjaalton> trying to trace the hidden_gl change, but it probably was split from the diff at some point
[07:28] <tjaalton> should also add the Old changelog entries to git
[09:15] <tjaalton> looks like fedora added nouveau dri to dri-drivers-experimental
[09:31] <RAOF> tjaalton: Where do you see these things?
[09:32] <tjaalton> RAOF: fedora cvs
[09:32] <tjaalton> http://cvs.fedoraproject.org/viewvc/devel/mesa/
[09:32] <RAOF> Are you subscribed to commits, or do you just browse every now and then?
[09:32] <tjaalton> though it looks like they missed adding gallium/nouveau to the for-loop :)
[09:32] <tjaalton> browse every now and then
[09:32] <tjaalton> this time to see how they handle gallium
[09:33] <tjaalton> looks like just the way the current dri drivers are handled..
[09:36] <RAOF> Spec files are wierd!
[09:36] <RAOF> But it does look like they don't do anything special.
[09:37] <tjaalton> yeah I don't like how everything is in one file..
[09:40] <RAOF> I guess the one file has its advantages, but once you're familiar with the various files in debian/ I think multiple files make it easier to understand what's happening.
[13:15] <Cobalt> Sarvatt: I know the Intel driver Eee PC crashes have been fixed with the new Intel drivers of newer kernels, are there any plans to isolate what's causing the crashes in the newer Xorg drivers in older kernels?
[13:20] <libv> Cobalt: check libv.livejournal.com and answer the question at the end of the post :)
[13:21] <Cobalt> libv: Thank you.
[13:21] <libv> it has no direct solution for this, but does point at the same fundamental issue you are pointing at
[13:21] <Cobalt> libv: Latest post?
[13:22] <libv> yes, it talks about the xorg devroom and the talk i will be holding there
[13:23] <Cobalt> I'm sorry if I'm a bit slow with this, but I see no mention of crashes or the Intel driver... or have those issues been noted on other drivers as well?
[13:25] <libv> "For those using, or those who have used, the nvidia or ati closed source drivers: how would you like it if nvidia or ATI told you that you needed the very latest upstream kernel, X, and mesa to be able to run the latest catalyst or nvidia driver, especially when you might need this version for its new hardware support or for bugfixes?"
[13:26] <Cobalt> I see.
[13:26] <Cobalt> Ah well, I'll follow that, I guess, and see what comes of it. Thanks.
[13:28] <Cobalt> I can see a lot of people not liking the idea of upgrading their kernels. Especially if their distribution don't provide stable packages.
[13:32] <libv> Cobalt: about the drm, until a year/year and a half ago, you could just grab the drm tree and build kernel modules
[13:32] <libv> there was a small bit of compat code to level over the bumps in a few kernel versions
[13:32] <Cobalt> Yes, but still, it's not within everyone's grasp to do that. I'd personally shun from compiling anything kernel-related. :S
[13:33] <libv> Cobalt: make; make install
[13:33] <Cobalt> You make it sound terribly easy.
[13:33] <libv> it was
[13:33] <Cobalt> Not anymore?
[13:34] <libv> no, now it is assimilated in the kernel
[13:34] <Cobalt> See?! Terribly complex stuff.
[13:35] <libv> which they finally also mentioned to the BSD people a few months ago, and they were thrilled :)
[13:35] <Cobalt> So that's a good thing?
[13:36] <libv> telling the BSD folk to port their stuff directly from the linux kernel?
[13:36] <Cobalt> No, that the thing was integrated in the kernel now.
[13:37] <libv> some people say it is
[13:37] <Cobalt> I suppose it's going to be a lot more stable and tested.
[13:37] <libv> with graphics hardware?
[13:37] <libv> graphics hardware is hugely complex and its drivers are in constant flux
[13:37] <libv> part of why linus held off the boat for so long and treated the fb drivers that stepmotherly
[13:38] <libv> but seems that his appreciation of that has changed
[13:38] <Cobalt> You can hardly get anything out of the fb these days.
[13:38] <Cobalt> Not such a dinosaur, then.
[13:38] <Cobalt> Still, for him to have accepted, it's pretty big.
[13:38] <libv> well, go back a few years, and you could hardly get anything out of X either
[13:39] <libv> politics/money goes a long way
[13:39] <Cobalt> That has moved quite a bit, now that you mention it. Drastically too. And for a bit, without much thought to the consequences.
[13:39] <Cobalt> I use Ubuntu, I remember the hue and cry when Jaunty came out.
[13:39] <libv> yes, and it is only going to become worse
[13:40] <Cobalt> I thought things were evening out a bit.
[13:40] <libv> this is what people say will happen
[13:40] <libv> but there is a difference between what is stated and what is done
[13:40] <Cobalt> Still, I'm not much in those circles, only started getting interested in the issue because of performance and stability hits on my EeePC.
[13:40] <libv> next great idea is to move xorg drivers into the xserver tree again so the API "can get fixed"
[13:41] <libv> first week and someone will run s/xf86/xorg/ on the whole thing
[13:42] <Cobalt> That's the only way you'll get to debug it.
[13:43] <libv> err... i am talking about exchanging the string xf86 to xorg on all the symbols in the xserver
[13:43] <Cobalt> Oh. I'm not sure I understand what the consequences of that would be. Pretty much of a noob where all that stuff is concerned, I'm afraid.
[13:44] <libv> Cobalt: this means that there will be a massive API breakage for no reason except for a lingering oedipus complex
[13:45] <Cobalt> Well, at least, the sooner they get over that, the better, surely, even though it's going to be hell to go through the transition period?
[13:45] <libv> it's a pointless transition
[13:45] <Cobalt> Having said that, wouldn't they just stick to stability versus change? There's a lot of enterprise grade applications that depend on X.
[13:46] <libv> well, i used to work for suse, and i had some of those big shots on the phone with suse management and his companies management
[13:46] <libv> and he pretty much blatantly said that suse had to go change its business model to adapt to his way of working
[13:46] <Cobalt> What'd come of it?
[13:47] <Cobalt> Admin and bureaucracy (I think it's universal) has a way having their heads in the clouds. I have similar issues at work - at a hospital.
[13:50] <libv> well, in normal business you expect things like that, 5 or so years ago i never though that open source software could be just as bad or even worse.
[13:50] <libv> you'd expect technical stuff to be more important than politics and talking rubbish
[13:50] <Cobalt> Not so good when you have a megalomaniac running the show.
[13:51] <Cobalt> Well, that's the exact same thing with hospitals. Sometimes decisions coming form the top just does not make sense. Like painting over a whole A&E department (for only 2 hours, granted) while business is still ongoing.
[16:15] <jcristau> libv: it's so much better to be able to hide a few bug fixes in lots of regressions!
[16:17] <libv> jcristau: that's not regressions, thatt's progress :)
[16:17] <jcristau> ah, right
[16:17] <jcristau> easy to get confused..
[16:18] <libv> too bad you're not there this weekend :)
[16:19] <libv> i'll still mention your debianised git trees in my talk though :)
[16:30] <jcristau> libv: do you know if any of the intel people will be at fosdem?
[16:56] <Sarvatt> tjaalton: wow, interesting, looks like we can build nouveau gallium at least along with the rest of the dri stuff going by what they are doing, I guess the tricky part comes when you build gallium drivers for things that have classic mesa ones as well
[17:32] <tjaalton> Sarvatt: I think those should be in another (libgl1-mesa-dri-experimental?) package that would provide/conflict with l-m-d, and when the gallium versions are considered stable, move them over
[17:33] <tjaalton> though mesa supports an alternative path now
[17:33] <libv> jcristau: i had to remove a talk in the wiki today
[17:34] <libv> jcristau: anholt inserted one at 11:00on the second of february, never said a word to me
[17:34] <libv> so yes, i guess so
[17:34] <libv> but no talk, as the morning slots are all taken by openmoko
[17:34] <jcristau> :/
[17:35] <libv> serves him right though, it's thanks to stunts like this that we will not have a devroom next year
[18:20] <vish> Sarvatt: hi... the two patches you showed me , have they landed in lucid or in the -edgers ppa?  [right now i have your ppa pinned and dont seem to have any trouble with it so far]
[18:21] <vish> the patches for the gdm flood errors*
[18:21] <Sarvatt> the ati patch is, i'm working on libdrm now to prevent the errors getting flooded under any circumstances also
[18:22] <vish> you mean they are in the edgers ppa?
[18:27] <Sarvatt> the ati fix is in the upstream git, the same fix i added as a patch to that -ati you used from my ppa
[18:27] <Sarvatt> thats been in edgers for a few days now yeah
[18:27] <vish> ah , cool , thanks
[18:27] <Sarvatt> but the libdrm one isnt yet, i'm working on that right now, taking a bit of tweaking because of the ubuntu branch in debian git being a little messed up
[18:29]  * vish nids
[18:29] <Sarvatt> all done and it built fine, uploading now
[18:29] <vish> nods*
[18:30] <Sarvatt> are you on karmic?
[18:30]  * Sarvatt forgot
[18:31] <vish> no.. lucid
[18:31] <Sarvatt> well, uploaded karmic too but that might not build right
[18:31] <Sarvatt> ah ok
[18:34] <vish> Sarvatt: would i have to watchout for Bug #436546 in the edgers ppa? last i heard was it[legacy_is_pending() or ? ] was required for some other bug
[18:59] <Sarvatt> i wouldnt expect cairo-dock to work right in any circumstances, all i've heard is bad things by the mesa devs about how it tries to do things :)
[19:02] <vish> hehe  , i can switch to different dock , but If X doesnt crash that would be sufficient for me :D
[19:04] <Sarvatt> i really dont have any idea though, if it doesn't work still just install ppa-purge and sudo ppa-purge xorg-edgers to go back to stock :)
[19:05] <vish> yeah.. i'm already installing -edgers [thats the plan]
[19:29] <baptistemm> * Add klingon language definition. wtf???
[19:29] <jcristau> baptistemm: wtf indeed.
[19:29] <baptistemm> :)
[19:30] <baptistemm> dear X developper, are you aware of a X corruption (on Intel at least) in lucid since yesterday
[19:47] <seb128> baptistemm, what do you call corruption?
[20:12] <bryce2> Sarvatt, hey you suggested something the other day to get vt switching to work on nouveau but I've forgotten
[20:13] <bryce2> Sarvatt, btw just removing splash from the kernel boot line wasn't sufficient for getting 3D working.  but that's fine I think we're missing some more fundamental bits
[20:14] <tjaalton> like the dri driver?-)
[20:19] <bryce2> tjaalton, indeed
[20:24] <Sarvatt> yeah bryce2 nouveau isn't going to have 3D support in lucid almost guaranteed, it would be easy to add nv0x-nv2x classic mesa 3D support if we go with mesa 7.8 though. removing splash was to fix the GPU hang and reset which was making the ddx use noaccel so there was no 2D acceleration happening but the fixed plymouth i uploaded there fixed that
[20:24] <bryce2> heh, rotating screen upside down --> crash
[20:25] <bryce2> ok
[20:25] <bryce2> ideas on the vtswitching issue?
[20:25] <Sarvatt> what happens when you try to VT switch?
[20:25] <bryce2> it leaves the X graphics on the screen
[20:25] <bryce2> doesn't show the console
[20:26] <bryce2> vt switching back to vt7 gets back to functioning X
[20:26] <bryce2> er, vt8 (ctrl-alt-f8) actually.  weird
[20:28] <Sarvatt> got a dmesg handy? wondering if you are having a similar problem to kklimonda's
[20:40] <Sarvatt> hmm /lib/udev/rules.d/78-graphics-card.rules needs an update for lbm-nouveau too
[20:40] <bryce2> apw is working on a new lbm update, should be coming in soon
[20:41] <bryce2> suspend resume failed on nouveau for me
[20:41] <bryce2> (at least, I couldn't get it to resume)
[20:42] <Sarvatt> theres going to be so many places we need to update the checks for nouveau to lbm-nouveau like this udev rule :(
[20:45] <Sarvatt> http://paste.ubuntu.com/369097/
[20:46] <bryce2> Sarvatt, might be useful to compile a list
[20:46] <Sarvatt> is there any place I should mark changes that need to be made to accomidate lbm-nouveau? i've got a plymouth and a udev patch now that need to be added
[20:46] <bryce2> nothing appears in dmesg after doing the vt switch
[20:46] <bryce2> yeah, we've got a wiki page for tracking these tasks
[20:46] <Sarvatt> dmesg | grep "GPU hang" return anything?
[20:47] <bryce2> https://wiki.ubuntu.com/X/Nouveau
[20:47] <Sarvatt> ok I'll add a TODO section there and start putting changes on it
[20:47] <bryce2> nope, no GPU hang
[20:47] <bryce2> great
[20:48] <Sarvatt> oh should I add it to outstanding issues?
[20:48] <bryce2> Implementation
[20:48] <Sarvatt> I was going over libdrm to see if theres anywhere else we are missing that talks to the drm module instead of lbm-drm which is where i caught the udev thing
[20:49]  * bryce2 nods
[20:56] <Sarvatt> updated with what i have for now, the list is going to grow alot :D
[20:59] <Sarvatt> i'm doing it headless for the most part so i havent tried suspend or vt switching to see if they're screwed up yet :(
[21:00] <Sarvatt> we've got the newest nouveau in lbm in the xorg-edgers/nouveau ppa though, updated it yesterday. it's a piece of cake to update thanks to apw's scripts :D
[21:02] <Sarvatt> oh boy
[21:02] <Sarvatt> theres calls to /proc/dri all over the place that are screwed
[21:02] <Sarvatt> because its /proc/lbm-dri/
[21:11] <Sarvatt> RAOF: should we have the /proc/dri calls in xf86drm.c also check /proc/lbm-dri ?
[21:16] <Sarvatt> hmm still some /proc/dri stuff in nouveau after munging, ./nouveau/drm_proc.c:		DRM_ERROR("Cannot create /proc/dri/%s\n", name);  ./nouveau/drm_drv.c:		DRM_ERROR("Cannot create /proc/dri\n"); ./nouveau/drm_proc.c:			DRM_ERROR("Cannot create /proc/dri/%s/%s\n",
[21:17] <Sarvatt> just the error messages though
[21:25] <Sarvatt> the udev rules change explains why plymouth was waiting for udev to finish at least
[21:31] <Sarvatt> wonder how much it would break things if we just didnt rename everything to lbm-* with this
[21:37] <Sarvatt> would be nice to add intel and radeon to this :D
[21:41] <kklimonda> huh, has something broke in the last 24 hours or so? I can't boot with nouveau.. I even managed to get a dmesg without seeing anything. http://pastebin.com/f4ae73417
[22:07] <apw> kklimonda, looks like plymouth had you for lunch
[22:07] <apw> that has changed recently
[23:09] <ara> tseliot, hi!
[23:39] <Sarvatt> did you reboot since updating nouveau kklimonda or is that the first time? does it boot ok without splash in the kernel command line?
[23:44] <kklimonda> Sarvatt, I've booted with lbm ~pre3 successfully, removing splash from command line doesn't change anything
[23:44] <Sarvatt> could you try booting with plymouth:debug added maybe?
[23:44] <Sarvatt> looks like thats a new option in the most recent one
[23:46] <Sarvatt> just to be sure it was PAE it was working on before and PAE thats the problem now?
[23:47] <Sarvatt> nothing else was updated in edgers/nouveau since the nouveau update you said was working :(
[23:48] <tseliot> Sarvatt: shall I blacklist both nouveau and nouveau_lbm when using nvidia?
[23:49] <Sarvatt> its lbm-nouveau, probably best blacklisting both yeah
[23:49] <RAOF> That's probably a good idea.
[23:50] <Sarvatt> kklimonda: booting with lbm-drm.debug=6 might have useful info too
[23:52] <kklimonda> plymouth:debug or plymouth.debug ?
[23:52] <kklimonda> Sarvatt, ^
[23:53] <Sarvatt> plymouth:debug i think it is, let me check
[23:54] <Sarvatt> ./src/main.c:     || (path = strstr (state->kernel_command_line, " plymouth:debug=file:")) != NULL)
[23:55] <Sarvatt> =file is optional i'm pretty sure
[23:57] <Sarvatt> btw might want to make this change to /lib/udev/rules.d/78-graphics-card.rules
[23:57] <Sarvatt> http://paste.ubuntu.com/369097/


[13:04] <rly> ikonia is on a mission to harass me.
[13:04] <ikonia> yawn
[13:04] <ikonia> not this again
[13:04] <rly> He banned me for no reason at all.
[13:04] <ikonia> you'll just get kicked from this channel
[13:05] <ikonia> please stop this silly crusade
[13:05] <rly> I don't personally understand why you would allow such mentally limited people in your peer group.
[13:05] <ikonia> ahh, now the insults start again
[13:05] <rly> I cannot stand to be around this stupidity for even 10 seconds.
[13:05] <rly> He is unable to comprehend any question.
[13:05] <rly> Any context.
[13:05] <rly> Anything remotely complicated.
[13:06] <ikonia> and yet you are here
[13:06] <ikonia> if you can't stand it - just /part
[13:06] <rly> He would be best used as landfill material, IMHO.
[13:06] <rly> It's just a waste of stardust.
[13:07] <ikonia> not sure what your goal is here, if it's to get another ban, ok, if it's to actually cause a problem, then you're not really doing move
[13:07] <rly> I have ikonia on ignore btw.
[13:07] <ikonia> but you actually don't as you're referencing my comments
[13:07] <ikonia> you're trying to pretend you do
[13:08] <rly> Can someone please undo my bans, because I don't like to be victimized by people with an IQ under 50?
[13:08] <rly> Thanks
[13:08] <ikonia> #ubuntu-ops is where you get that sorted - the channel you just got kicked from
[13:09] <rly> Feel free to send me a private message when you have it resolved. I have no interest in any discussion.
[13:09] <rly> If you really think ikonia is not the most retarded people that has ever been on IRC, there is nothing to be discussed.
[13:09] <rly> Note that the only person who I have an issue with is with ikonia.


[00:47] <DonkeyHotei_> release party commencing
[00:48] <ianorlin> yay
[00:53] <DonkeyHotei_> hi
[01:19] <not-rww> whooooooooooooooooooooooooooooooo
[01:20]  * ianorlin has to get dinner for his father for his birthday today
[01:22] <DonkeyHotei_> even jono is here
[01:22] <not-rww> wait where did jono come from
[01:22] <not-rww> i swear he snuck in the back
[01:54] <nhaines> not-rww: someone tell Jono I said hi.  :P
[02:31] <DonkeyHotei_> nhaines: reply was "hey, nathan! how's it goin'?"
[02:33] <nhaines> DonkeyHotei_: thanks.  :)  Of course I'm bummed not to be there but I'm there in spirit. (Specifically a Stone Sublimely Self-Righteous Black IPA).
[02:47] <DonkeyHotei_> nhaines: how do i pass that on, and to whom?
[03:10] <nhaines> DonkeyHotei_: as is, and to jono or whomever.  Or not at all.  Just a joke.  :)
[03:14] <DonkeyHotei_> just showed him this screen
[03:14] <nhaines> Probably best for all involved.
[03:14] <DonkeyHotei_> eps's idea
[03:16] <DonkeyHotei_> "i love him. he's awesome" in reference to you
[03:16] <nhaines> :D
[03:16] <DonkeyHotei_> jono, not eps
[03:17] <DonkeyHotei_> i'm intending to leave early, so signing off
[04:50] <pleia2> https://www.flickr.com/photos/pleia2/sets/72157644280395482/
[04:50] <darthrobot> Title: [San Francisco 14.04 Release Party - a set on Flickr]
[04:52] <nhaines> pleia2: +1
[04:53] <jyo> Yay, some of the more crappy pictures in there are by me.
[05:05] <nhaines> pleia2: looks like it was a huge success  :)
[05:16] <DonkeyHotei> leaving early didn't end up happening
[05:17] <nhaines> DonkeyHotei: was it fun?
[05:17] <DonkeyHotei> you saw the pics
[05:27]  * ianorlin likes the pics
[05:30] <DonkeyHotei> i'm the one always on the phone
[05:46] <nhaines> I did see the pics.
[05:50] <arrith> whewww
[05:50] <arrith> that was intense
[05:51] <arrith> i have questions.. for people. if i can remember them
[05:51] <arrith> pleia2: do you happen to remember the rankings of the quiz winners?
[05:51] <arrith> i think i know which i got wrong
[05:53] <arrith> also i guess support for the 3.13 kernel is being dropped, just... not exactly sure when. people have been saying 2 years
[06:11] <nhaines> Okay, time to reimage this VPS with Ubuntu 14.04 LTS instead of 12.04 -> upgrade.  Be back. :)
[06:15] <arrith> rww: https://www.youtube.com/watch?v=EJ_wXOFQV3M
[06:15] <darthrobot> Title: [GNU/STALLMANQUEST - YouTube]
[19:09] <rww> so, how did the san diego release party go?
[19:23] <raevol> it was fun!


[05:03] <fabbione> morning
[05:37] <jbailey> g'm Fabio!
[05:40] <fabbione> hey jeff
[10:02] <T-Bone> ola
[10:13] <fabbione> hey T-
[10:13] <T-Bone> ola fabbione!
[10:14] <T-Bone> fabbione : i like your mails: 45% text, 65% gpg key ;o]
[10:14] <fabbione> it is still worth 100% of the data
[10:14] <T-Bone> not for me ;)
[10:15] <fabbione> you are special
[10:15] <fabbione> but that's not my fault
[10:15] <T-Bone> 1) because most of the time i don't read gpg signs, and 2) because i know how to fetch a gpg key ;)
[10:15] <fabbione> :)
[10:15] <fabbione> T-Bone: my MUA just tells me if the gpg sig is valid or not
[10:15] <T-Bone> well, it depends on which side you stand. from my PoV, *you* (damned Italian) are special ;o)
[10:15] <fabbione> i don't read all the gpg crap
[10:16] <fabbione> T-Bone: that works the otherway around with french
[10:16] <T-Bone> fabbione : when i use a MUA that can do gpg it does the same, yet it doesn't need to have the key in the message ;) And from work i'm bound to webmail, so gpg ain't much useful there ;)
[10:16] <T-Bone> fabbione : i knew you'd say that ;)
[10:17] <T-Bone> fabbione : so, how's the sparc port going? ;)
[10:17] <fabbione> T-Bone: fine.. hoary main is all built and installable
[10:17] <T-Bone> lucky bee ;)
[10:17] <T-Bone> lol
[10:18] <fabbione> no i am not kidding :)
[10:18] <T-Bone> that'd be fairly unfair, given the *very* reduced size of the patch
[10:18] <fabbione> i need to rediff the patches
[10:18] <T-Bone> ah, you mean the old bloated patch?
[10:18] <fabbione> yes.. but i got you anyway :P
[10:18] <fabbione> that was good enough for me
[10:18] <T-Bone> yeah sure that one can be ditched.   What would ya've said if ya were born french? 8))
[10:26] <T-Bone> (and don't tell me you'd commit suicide, i wouldn't believe that ;)
[10:27] <fabbione> i would probably be bashing other french :)
[10:29] <T-Bone> lol
[10:29] <T-Bone> you are sick in your head ;)
[10:33] <fabbione> no, really???
[11:03] <T-Bone> yeah, reeaaaaally 8)
[11:14] <dilinger> so are you guys not planning on turning on DMA for cdroms and dvds?
[11:14] <dilinger> (drives, that is)
[11:15] <fabbione> no way
[11:16] <dilinger> :/
[11:16] <fabbione> i rather prefer a user that complains about slow performance than people that can't use their CD/DVD at all
[11:16] <fabbione> dilinger: or do you have good arguments on how to do it in a sane way?
[11:16] <dilinger> but the number of people that can't use their cd/dvd at all due to dma is relatively small, and those devices should simply be blacklisted as not supporting DMA
[11:17] <dilinger> the kernel has the functionality to do that already; people w/ nonworking cdroms should report them, so that we can add more to the blacklist
[11:18] <fabbione> hmmm
[11:19] <fabbione> dilinger: i am afraid of landing in the a huge list to maintain outside the kernel
[11:19] <fabbione> + i always had the feeling that DMA is way too much binded by chipset/cdrom combo
[11:19] <fabbione> not just one or the other
[11:20] <dilinger> it should be fairly easy to get patches to add blacklisted devices accepted upstream
[11:22] <fabbione> we will take a look to it @ UDU
[11:22] <fabbione> i really don't want to take too many decisions right now
[11:22] <fabbione> specially when we are 2 weeks far from it
[11:22] <dilinger> i would recommend it as a breezy thing, certainly
[11:22] <fabbione> and we are still far away to have a kernel for breezy :)
[11:25] <fabbione> The God Father theme is amazing
[11:25] <T-Bone> hoho
[11:25] <T-Bone> a contract on my head? ;)
[11:27] <T-Bone> this isn't what scares me the most. What scares the hell out of me is that you've been living in sicily for so long and have moved to .dk. Yet, you're still alive. Means you've got strong connections ;o)
[11:27] <God_Father> T-Bone: picciriddu
[11:27] <T-Bone> lol
[11:27] <T-Bone> I knew you were nuts but i didn't figured out how much ;)
[11:29] <fabbione> T-Bone: you still don't know me enough...
[11:29] <T-Bone> fabbione : one of these i'll have you pay for treating me like a bambino ;)
[11:29] <fabbione> this is still all inside my standards
[11:29] <fabbione> T-Bone: you are a kid
[11:29] <T-Bone> if you say so ;)
[11:30] <T-Bone> you must be fsckin old geezer to "kid" me whilst i'm about a quarter century old ;)
[11:31] <fabbione> i 1/3 century old kid
[11:31] <T-Bone> wow. Talk about a difference ;)
[11:31] <fabbione> dude.. when i was turning on my first computer, you were still a dream in your father's testicles
[11:31] <fabbione> no offence to your father :)
[11:32] <Mithrandir> fabbione: you played with computers before you were eight?
[11:32] <T-Bone> i wonder
[11:32] <T-Bone> you've been turning on your first computer at the age of 5 or somethign? ;)
[11:32] <fabbione> Mithrandir: i got my first zx81 when i was 6
[11:32] <fabbione> yes..
[11:32] <fabbione> i started learning basic at that time
[11:32] <Mithrandir> fabbione: old man.  I started playing with computers at the age of 1.5 :P
[11:32] <fabbione> since it was almost impossible to find tapes with games :)
[11:32] <T-Bone> fabbione : pfff, spoiled child ;)
[11:33] <fabbione> Mithrandir: ehehe
[11:33] <fabbione> T-Bone: well yeah.. kinda
[11:33] <T-Bone> that's why i can enjoy *other* things in life ;)
[11:34] <fabbione> T-Bone: so.. why are you spending time on hppa???
[11:34] <T-Bone> fabbione : because i can
[11:34] <T-Bone> ;)
[11:34] <fabbione> instead of going out scoring chicks?
 that's why i can enjoy *other* things in life ;)
[11:34] <fabbione> i find difficult to consider hppa *other* things in life <-
[11:35] <T-Bone> fabbione : nonono, you don't get it. I'm the one being dated by chicks. I have little effort to do 8)
[11:35] <fabbione> T-Bone: and do you wake up all swet in the morning after these dreams?
[11:36] <T-Bone> fabbione : lol; dude, you see, i may be a kid, yet i can enjoy some freedom you can no longer feel ;o)
[11:36] <T-Bone> (that was a proper lart! ;o)
[11:37] <fabbione> T-Bone: are you so sure? :)
[11:37] <T-Bone> i do
[11:37] <T-Bone> ;)
[11:38] <T-Bone> and other things in life == guitar, sport (funboard, horse riding, ski, moutain climbing, etc), readings, do-it-yourself, parties, and girls dating ;)
[11:38] <T-Bone> (and that's only the major stuff)
[11:39] <T-Bone> actually you can s/guitar/music/ cause i'm diversifying in that area ;)
[11:40] <fabbione> how can you be sure that i didn't elevated my way of pleasures to another level?
[11:40] <T-Bone> fabbione : i'm sorry, but i'm french. I have to live up to my country's expectation, wrt chicks. That may be the other point Italian and French are always arguing about: who are the most handsome?. My answer is "I am" ;o] ]
[11:41] <fabbione> hmmm
[11:41] <fabbione> i was actually talking to a more general level
[11:41] <fabbione> not just chicks
[11:41] <T-Bone> i know
[11:41] <fabbione> but still.. sometimes there is no need to score chicks to elevate your sexual pleasure
[11:41] <fabbione> thinking of three-some.. orgies...
[11:42] <T-Bone> ewww
[11:42] <T-Bone> and you do that whilst married? ;)
[11:42] <T-Bone> what an surprising spouse you must have 8)
[11:59] <dilinger> fabbione: are you a sopranos fan?
[11:59] <fabbione> dilinger: nah.. just a mafia's fan :)
[12:00] <dilinger> hehe
[12:01] <fabbione> hmm 12rc2 is coming up nice and clean
[12:02] <fabbione> specially now that i managed to track all the external drivers in details
[12:03] <dilinger> it's kind of upsetting that linus is wasting his time working on yet another SCM instead of spending it on 2.6.12
[12:04] <fabbione> i read that thread.. but well i think he is only using it as PoC to see what he really wants/needs
[12:05] <fabbione> i don't believe he will ever release a SCM
[12:08] <fabbione> food... it's almost a good idea
[12:11] <dilinger> fabbione: i dunno, i'd still much rather see him pick a SCM that he likes the concept of, and help bring the code up to speed
[12:34] <fabbione> dilinger: yes i agree... but still....
[01:19] <fabbione> goodie goodies....
[01:19] <fabbione> all the non external-* patches are done (missing 2 to check that should be upstream)
[01:20] <fabbione> all the external-* documentation is updated
[01:20] <fabbione> from now on it will be almost a breezy
[01:20] <wido> moin guys
[01:21] <wido> is reiser4 supported by the current kernel?
[01:21] <fabbione> nope
[01:21] <wido> couldn't find any reference on the homepage
[01:21] <fabbione> it's too unstable to be shipped with ubuntu
[01:21] <fabbione> perhaps for breezy
[01:22] <T-Bone> reiser4 is still a mess atm, indeed
[01:22] <wido> ah, ok. then i have to figure uot a way how to backup my mp3s in order to install ubuntu
[01:23] <wido> btw, reiser4 worked without problems on my gentoo box
[01:24] <mjg59> reiser4 will be included when it's included in Linus's kernel
[01:24] <mjg59> The patch is likely to apply to the Ubuntu sources though, so you can probably build your own
[01:24] <T-Bone> mjg59 : sounds like a wise word ;)
[01:25] <fabbione> wido: for my experience with reiserfs4... it will enter ubuntu when Linus will bless it upstream
[01:26] <wido> currently i don't care which filesystem i use. the only question was, if i could reuse my existing partions, or if i have to convert them in order to install ubuntu
[01:26] <T-Bone> fabbione : that's yet another point i won't discuss, for i agree ;o)
[01:27] <fabbione> T-Bone: ahhaha
[01:27] <T-Bone> fabbione : see, we can tag along! ;)
[01:27] <fabbione> wido: well it depends how you system is partitioned, but that's more #ubuntu question
[01:27] <fabbione> T-Bone: die young kid!  My work is sooooooo boring :P
[02:01] <T-Bone> jbailey : btw, you're late. We've been talking about chicks n' sex a bit earlier. I'm sure you'd have had something to say 8)
[02:01] <jbailey> *moi*?
[02:01] <T-Bone> oui!
[02:03] <T-Bone> fabbione was expressing some unappeased sexual fantasy 8)
[02:04] <fabbione> T-Bone: fortune this: ..|..
[02:04] <T-Bone> given he's an old geezer, he can't do much nowadays 8-D
[02:04] <fabbione> T-Bone: i have a big reserve of viagra
[02:04] <T-Bone> fabbione : that's the difference man: i don't need viagra =]
[02:05] <fabbione> T-Bone: you will.. one day..
[02:05] <fabbione> you can't escape.. as much as i did
[02:05] <T-Bone> fabbione : maybe, when i'm an old geezer as you are, but i expect this to happen far later than it did for you ;o)
[02:05] <fabbione> T-Bone: that because i managed to burn myself faster and better
[02:05] <T-Bone> because, you see, i'm french.    I'd like an option in kernel-mg.conf to be able to choose a different initrd handler.
[03:34] <fabbione> jbailey: probably kernel-package
[03:35] <jbailey> As in, you'd like an enh filed on bugzilla?
[03:35] <fabbione> jbailey: no, i had like a tested patch
[03:35] <jbailey> Right.  But do you want discussion around it first?
[03:36] <fabbione> jbailey: sure.. we can either do it here or on kernel-team.. up to you
[03:36] <fabbione> first explain me the problem
[03:36] <fabbione> and what we need to achive
[03:37] <jbailey> The idea is that I want to test my initramfs replacement.  I can hack around the package all I want for now, but when it comes time to do a call for testing, I'd like to be able to give people 2 lines to add to their kernel-img file to hook to the initramfs generation stuff.
[03:38] <jbailey> Same way as we do for grub and friends.
[03:38] <fabbione> works for me....
[03:38] <fabbione> i don't see any problem with that
[03:39] <fabbione> "break it early" works perfectly fine for me
[03:39] <fabbione> + we can help testing it, if you can explain what this initramfs hack should do
[03:40] <jbailey> fabbione: It's a complete rework of the initrd system that uses udev instead of devfs, and uses hotplug to detect the modules that need to be loaded rather than having all the ugly magic of trying to detect it at install time.
[03:40] <jbailey> fabbione: There are some other clever bits, but those are the particularily important ones.
[03:41] <fabbione> jbailey: hmm interesting...
[03:41] <fabbione> jbailey: i think you want to look at kernel-package
[03:41] <fabbione> it has the postinst files that gets smashed in the final linux-image
[03:41] <fabbione> and that generates the initrd
[03:41] <fabbione> now
[03:42] <fabbione> the best way would be to modify such a best in a way that "if [ -e /etc/breakmehard ] ; then generate_initramfs; fi
[03:42] <fabbione> so that you can add the changes even now
[03:42] <fabbione> but they will be enabled only on demand
[03:43] <jbailey> Hmm.  I had been thinking of doing it the same way grub is handled:  do_bootloader = no , posthook = update-grub
[03:43] <jbailey> Rather than hardcode another constant idea in.
[03:43] <fabbione> i know that make-kpkg has a bunch of hooks that can be installed at kernel build time
[03:44] <fabbione> so perhaps you want to explore that option too
[03:44] <fabbione> the most important thing for me are:
[03:44] <fabbione> a) don't fork kernel-package
[03:44] <fabbione> b) keep compatibility with the old stuff during development
[03:44] <fabbione> if you can't respect b) you will block us on working/testing the kernel
[03:45] <fabbione> a) it's a bit less important, but if you fork, you will also maintain in the future :)
[03:45] <fabbione> so it's up to you :)
[03:46] <zul> crappers..
[03:47] <fabbione> hi zul
[03:47] <zul> hey fabbione, good weekend?
[03:47] <fabbione> zul: yeah great
[03:48] <fabbione> had big fun in London :)
[03:48] <zul> good to hear...i hardly  touched a computer this weekend
[03:48] <zul> so im ready to get back to the grind ;)
[03:49] <fabbione> zul: just gimme another 10/15 minutes
[03:49] <zul> sure
[03:49] <fabbione> i have a couple of interesting commits pending :)
[03:49] <fabbione> we are almost ready to start the build orgy :P
[03:49] <zul> like what?
[03:49] <fabbione> all the patches are cleandup
[03:49] <fabbione> missing a few bits here and there
[03:49] <fabbione> all the external-drivers have been documented
[03:50] <fabbione> but they still need updates
[03:50] <zul> cool...i can update the drivers tonight once i get baz working again
[03:50] <zul> shiney new hard drive this weekend :)
[03:52] <fabbione> zul: that's an option
[03:52] <fabbione> right now the only external that doesn't apply is inotify
[03:52] <fabbione> so i was thinking to update inotify
[03:52] <fabbione> and start the build orgy on i386
[03:52] <zul> yeah 0.22 is supposedly suppose to work
[03:52] <fabbione> and update the drivers after we know that the core kernel can atleast compile
[03:52] <zul> but that is what they said about 0.21
[03:53] <fabbione> zul: yes. they talk by revision numbers
[03:53] <zul> are you going to try compiling it with gcc 4.0
[03:53] <fabbione> but i can reproduce the problem here so it will be easy to check
[03:53] <fabbione> no.. we need to wait the greenlight from doko
[03:53] <zul> ok..
[03:53] <fabbione> he said that the actual gcc-4.0 pre6 in ubuntu cannot compile the kernel
[03:53] <zul> heh
[03:53] <fabbione> so he was asking us to wait for pre7 or a ping from him
[03:54] <fabbione> both ways work fine with me
[03:54] <fabbione> we need to do much work before we can really switch to gcc-4
[03:54] <fabbione> like getting the new upstream working with the actual gcc
[03:54] <zul> there are alot of warnings when compiling with gcc-4
[03:54] <zul> i think most of them have been cleaned up upstream
[03:55] <fabbione> yeah well.. we are tracking upstream now :)
[03:55] <zul> heh...we were always were...i was trying to at least ;)
[03:57] <fabbione> ehehe
[03:57] <fabbione> we are more bleeding edge now :)
[03:57] <zul> just have to wait for linus to get his ass in gear ;)
[03:58] <fabbione> yeah
[04:01] <zul> heh..http://internetnews.com/dev-news/article.php/3496541
[04:03] <fabbione> old news
[04:04] <fabbione> zul: do a baz update now
[04:04] <fabbione> and tell how sexy 00list-1 looks like :)
[04:05] <fabbione> zul: btw that article was posted on an ubuntu ml :)
[04:06] <zul> heh so shoot me..i been stuck outside all weekend ;)
[04:06] <zul> not literally
[04:09] <zul> fabbione: not bad ;)
[04:10] <fabbione> zul: sexy eh?
[04:10] <zul> yeah i think you are missing a patch for inotify though
[04:11] <fabbione> the first one that will break the name convention will be pubblically cross burned on top of the eiffel tower
[04:11] <fabbione> zul: nope
[04:11] <zul> so it will be t-bone since he is the closest to the eifel tower
[04:11] <fabbione> zul: all the patches are there
[04:12] <fabbione> inotiify = external + alpha sort = last one
[04:12] <fabbione> but i am updating it right now to 0.22
[04:12] <zul> the disable inotify patch by default?
[04:12] <fabbione> zul: i will drop it for now
[04:13] <zul> ok
[04:13] <fabbione> i will keep the source around, but we will not apply it
[04:13] <fabbione> also because it will need rediff anyway
[04:13] <fabbione> let see how my tests go
[04:13] <zul> true...
[04:13] <fabbione> and we can still stick it back
[04:14] <zul> fsck...it says i have a conflict but its a pristine copy
[04:14] <fabbione> zul: ?
[04:15] <fabbione> is that baz?
[04:15] <zul> 1 conflicted items in this tree. Please resolve each conflict with baz
[04:15] <zul> yeah
[04:16] <fabbione> WEIRD
[04:16] <fabbione> let me check out
[04:16] <zul> i should only need <IP_ADDRESS> in my arch should i?
[04:16] <fabbione> zul: are you using baz from ubuntu or from the daily baz build?
[04:17] <zul> baz from ubuntu
[04:17] <zul> Bazaar version 1.2<EMAIL_ADDRESS>)
[04:17] <fabbione> i am testing
[04:17] <fabbione> deb http://bazaar.canonical.com/packages/debs/ ./
[04:17] <fabbione> i use this one
[04:18] <fabbione> but let me check
[04:18] <zul> 1.3?
[04:18] <fabbione> yeah
[04:18] <fabbione> works fine here
[04:18] <fabbione> try to get the tree again...
[04:18] <fabbione> baz get kernel-debian--pre1--<IP_ADDRESS> debian/
[04:19] <zul> hmm...no default archive set
[04:19] <fabbione> zul: sorry..
[04:19] <fabbione> i use the kernel archive as default
[04:19] <fabbione> baz get<EMAIL_ADDRESS>debian/
[04:20] <zul> getting it
[04:20] <fabbione>   Enable full-sized data structures for core (BASE_FULL) [Y/n/?]  (NEW)
[04:20] <zul> hmm?
[04:21] <fabbione> Preemptible Kernel (PREEMPT) [Y/n/?]  y
[04:21] <fabbione>   Preempt The Big Kernel Lock (PREEMPT_BKL) [Y/n/?]  (NEW) ?
[04:21] <fabbione> This option reduces the latency of the kernel by making the
[04:21] <fabbione> big kernel lock preemptible.
[04:21] <fabbione> Say Y here if you are building a kernel for a desktop system.
[04:21] <fabbione> these are the new options for 2.6.12rc2...
[04:21] <zul> ah
[04:21] <fabbione> doesn't it ring a bell?
[04:21] <zul> okies...nope it doesnt
[04:23] <zul> fudge..PANIC: conflict applying patch in arch_build_revision
[04:24] <fabbione> hmmmm
[04:24] <fabbione> try to update baz and see if that fixes
[04:24] <zul> tree already up to date
[04:25] <zul> baz is really starting to get to me
[04:29] <fabbione> sorry.. i was busing updating the config
[04:29] <zul> not probs
[04:29] <fabbione> try to use baz from the archive i pasted before
[04:29] <fabbione> they might have broke compatibility or something
[04:30] <zul> ill update my baz tonight then
[04:30] <fabbione> zul: ok
[04:30] <fabbione> i am building here :)
[04:30] <fabbione> just for fun
[04:30] <zul> :P
[04:30] <T-Bone> lamont : ping...
[04:31] <fabbione> T-Bone: of the 3 hppa patches...
[04:31] <T-Bone> ditch them all
[04:31] <fabbione> can i kill all of them and just grab the new one from cvs?
[04:31] <T-Bone> correct
[04:31] <fabbione> ok
[04:31] <fabbione> but only after i will have sparc kernels...
[04:31] <T-Bone> LOL
[04:31] <fabbione> right now i am owning hppa :)
[04:31] <fabbione> MUHA MUHA MUHA
[04:32] <T-Bone> i hate you, you silly little kernel caporal of my bollocks ;)
[04:33] <T-Bone> fabbione : in any case, this won't bring universe to sparc ;o)
[04:33] <T-Bone> jbailey : i'll have to bug you for hppa installer, btw ;)
[04:34] <zul> "i hate you, you silly little kernel caporal of my bollocks ;)" i thought you said buttocks
[04:34] <T-Bone> lol
[04:34] <T-Bone> you psycho-perv
[04:35] <jbailey> T-Bone: Erm, for Ubuntu or Grub2?
[04:35] <T-Bone> jbailey : for ubuntu. Grub2 is none of my concerns ;o)
[04:35] <T-Bone> we have palo... ;o)
[04:36] <jbailey> Right.  And I don't know enough about hppa stuff to port grub2 to that yet.  Perhaps that can be an autumn project.
[04:36] <jbailey> I'm more likely to do ia64 first.
[04:36] <T-Bone> you're the SM type, right? :)
[04:36] <jbailey> Sure.  Now decided if I'm a top or a bottom...
[04:36] <T-Bone> LOL
[04:37] <jbailey> ;)
[04:37] <T-Bone> given the palo hack, i doubt it'll be easy to port something else to hppa :)
[04:37] <T-Bone> s/the// s/hack/hackyness/
[04:38] <fabbione> i am impressed.. it's compiling the modules!
[04:38] <jbailey> Dude, can anything be uglier than booting on ia32?
[04:38] <T-Bone> hackery even. Call it whatever you like
[04:38] <fabbione> without any failure.. yet
[04:38] <T-Bone> jbailey : fair enough ;)
[04:39] <T-Bone> fabbione : that's sparc? :)
[04:39] <jbailey> fabbione: At some point I want to talk to you about sparc and glibc. =)
[04:40] <fabbione> T-Bone: not yet
[04:41] <fabbione> jbailey: anytime...
[04:41] <fabbione> even now.. if you want to
[04:42] <jbailey> In an hour would be better for me.
[04:42] <fabbione> hmm in one hour i might be off...
[04:43] <jbailey> Okay, now then makes as much sense as any other time. =)
[04:44] <fabbione> T-Bone: in anycase i would kid too much about sparc and universe.. because hoary it's building pretty fast and breezy isn't open yet
[04:44] <jbailey> I have 2.3.5 packages up here.  I haven't finished pushing all the Ubuntu modifications to it yet, but a question I have for each arch is which threading libraries to enable.
[04:44] <zul> is there a meeting this week?
[04:44] <fabbione> jbailey: well is it only question to try to build and test or to do something specific?
[04:44] <T-Bone> fabbione : yeah yeah. Thing is, we're about 95% up to date on hppa, and could get maybe 1 more point with KDE building ;)
[04:44] <fabbione> zul: 2
[04:45] <fabbione> T-Bone: see... i have kde builded :)
[04:45] <zul> 2?!
[04:45] <jbailey> I have a bias towards moving people to nptl online on as fast of a schedule as they can cope with, since: 1) LinuxThreads is considered deprecated by upstream.  2) The hacks to make both LT and NPTL are not supported by upstream and keep breaking in subtle ways. 3) It's far nicer to only have one threading library to support, especially considering that otherwise it automagically detects which one it should
[04:45] <jbailey>  use.
[04:45] <fabbione> zul: one tomorrow for the CC/TB and one in 2 days TB/CC
[04:45] <T-Bone> fabbione : i'd be glad to ask a few questions about that then. What i'm facing looks mostly like a circdep issue
[04:45] <fabbione> can't remember the order :)
[04:45] <zul> bleah..
[04:46] <fabbione> jbailey: i see.. but what can i do to help?
[04:46] <zul> hmmm...im might not make them..oh well
[04:46] <zul> fabbione: yeah it was the baz verison i was using
[04:46] <jbailey> The biggest blocker against NPTL is usually commerical software.  Folks with precompiled binaries that either make assumptions about threading layout, or use extern int errno, which nptl can't support (#include <errno.h> good)
[04:46] <fabbione> T-Bone: well i kept kicking back the packages
[04:46] <jbailey> fabbione: Tell me what the right thing for your pet arch is. =)
[04:47] <fabbione> jbailey: well afaik there are not many binary only drivers for sparc
[04:47] <jbailey> Not drivers, applications.
[04:47] <fabbione> so i think it is pretty safe to move
[04:47] <fabbione> i mean applications sorry
[04:47] <fabbione> at least not that i am aware of
[04:47] <T-Bone> fabbione : that's waht i'm doing. Yet, it complains that kdelibs aren't installed (which they are), and looking at config.log, it seems that the culprit is some QT lib missing
[04:48] <fabbione> usually companies that produce applications for sparc, run on slowlaris
[04:48] <jbailey> 'kay.  I should receive a sparc box later this week, I can do some testing.
[04:48] <jbailey> I don't know how iBCS interacts with the threading system.
[04:48] <fabbione> T-Bone: /var/cache/apt/archives is your enimy
[04:48] <T-Bone> fabbione : it's being regularly cleaned by me and the autobuilder.
[04:48] <jbailey> I think it's just a syscall wrapper, isn't it?  In which case Solaris emulation shouldn't be affected.
[04:48] <Mithrandir> T-Bone: is nekkid up?
[04:48] <fabbione> jbailey: to be hounest, i love sparc, but i don't know enough to play with libc and stuff like that
[04:48] <fabbione> it's too deep for me
[04:49] <fabbione> T-Bone: well.. do you ever update the chroot?
[04:49] <jbailey> fabbione: It's more the how prevalent is commercial applications.  The Free software world has already figured out generally how to cope.
[04:49] <fabbione> T-Bone: and apt-get update && apt-get dist-upgrade must be done regularly
[04:50] <fabbione> jbailey: tbh for ubuntu we can switch as test platform
[04:50] <fabbione> we are not even officially released with sparc
[04:50] <fabbione> go ahead and do your changes
[04:50] <jbailey> fabbione: That would be lovely.
[04:50] <fabbione> we can still be the drive arch for it
[04:50] <T-Bone> fabbione : i do that too :P
[04:50] <jbailey> Thanks.  I'll test it enough to make sure that you at least have bash and apt working ;)
[04:50] <fabbione> i really don't mind to kill proprietary applications
[04:50] <fabbione> jbailey: i can test in a chroot.. can't i?
[04:50] <jbailey> fabbione: Sure. =)
[04:51] <fabbione> jbailey: plus i have an extra partition where i can isntall and run "natively"
[04:51] <jbailey> But I mean before I hand it to you, I'll make sure of that.
[04:51] <zul> heh someone broke the naming scheme
[04:51] <zul> parisc-irq.dpatch
[04:51] <fabbione> zul: right!
[04:51] <T-Bone> fabbione : give me a few secs, i'll show you the error
[04:51] <fabbione> let's burn T-Bone !
[04:51] <fabbione> T-Bone: no no.. you are the hppa porter.. go figure it yourself :P
[04:52] <fabbione> T-Bone: or now is time to call the oracle because of the experience?
[04:52] <T-Bone> zul : that's an *old* patch, when there was no such a thing a a naming scheme. Besides, if you have issues with that patch name, i suggest you discuss it with lamont.
[04:52] <zul> heh...
[04:52] <fabbione> ahhaa
[04:52] <zul> maybe i will..frog :)
[04:52] <T-Bone> zul : bear in mind that lamont is an pyrotechnist and expert in all kinds of explosives ;)
[04:53] <T-Bone> fabbione : you're so overconfident ;o)
[04:53] <zul> yeah i have to wear my flap jacket around him
[04:53] <T-Bone> fabbione : i'll call you the oracle if you can *actually* help me ;)
[04:53] <fabbione> T-Bone: you talk like if you can convince lamont to bomb us....
[04:54] <T-Bone> fabbione : i think it's pretty easy to convince lamont to bomb anyone getting in the way of Ubuntu hppa ;o))
[04:54] <fabbione> T-Bone: well fire the error log somewhere
[04:54] <zul> T-Bone: is lamont in michigan?
[04:54] <T-Bone> fabbione : generating it as I speak :)
[04:54] <fabbione> T-Bone: i guess you don't want a kernel anymore.. do you?
[04:54] <T-Bone> zul : lamont is everywhere ;)
[04:54] <T-Bone> fabbione : you can't do that. I'll put a contract on your feet (your head ain't worth it) if you do that ;o)
[04:55] <fabbione> yes i can :)
[04:55] <T-Bone> (on the feet, one can always grab a pair of shoes, if anything ;)
[04:55] <fabbione> oh hell
[04:55] <fabbione> fTBFS
[04:55] <fabbione> and you know where?
[04:55] <fabbione> right on one of this retarted external drivers
[04:56] <T-Bone> lol
[04:56] <T-Bone> Mithrandir : lol don't tempt me too much ;o)
[04:57] <Mithrandir> T-Bone: 16:48 < Mithrandir> T-Bone: is nekkid up?
[04:57] <T-Bone> Mithrandir : it'll be in 1h
[04:57] <Mithrandir> ok
[04:57] <Mithrandir> I need to trash her around a bit
[04:57] <T-Bone> (too bad i haven't hooked the serial cable, i could have powered it up now)
[04:57] <T-Bone> sure
[04:57] <Mithrandir> I'm doing a new ia32-libs, which is so horrible you can't imagine
[04:57] <T-Bone> i can
[04:57] <T-Bone> i've seen the old ones ;)
[04:58] <Mithrandir> this is worse
[04:58] <T-Bone> ewww
[04:58] <T-Bone> this must be *really* scary then ;}
[04:58] <Mithrandir> more ugly, actually
[04:58] <Mithrandir> since it supports both ubuntu and debian
[04:58] <Mithrandir> which puts libs in different places
[04:58] <T-Bone> yum!
[04:59] <T-Bone> aah. Iron Maiden is good to hear when hacking ;)
[05:00] <fabbione> T-Bone: iron maiden ++
[05:00] <T-Bone> fabbione : hehe ;)
[05:00] <fabbione> but right now i am in love with the God Father theme :)
[05:00] <T-Bone> lol
[05:00] <fabbione> * committed<EMAIL_ADDRESS>[05:00] <fabbione> given this version.. you should be able to compile 2.6.12rc2
[05:00] <T-Bone> ain't "peachy" enough :)
[05:00] <fabbione> no config updates yet
[05:00] <fabbione> no hppa patches
[05:01] <T-Bone> (re GodFather theme)
[05:01] <fabbione> T-Bone: eeheh
[05:01] <fabbione> note: none of the external drivers (other than the one documented as | ok | are guarenteed to work)
[05:01] <fabbione> simply because they are obsoleted
[05:06] <zul> Maiden rocks..
[05:08] <T-Bone> heh. There ain't only Maiden in life. You'd be quite surprised at the range of music i enjoy. Eg, i'm now listening to "A Man Called Adam / Eastern Song", which could be classified as "ambient dub" probably ;)
[05:08] <T-Bone> s/Eastern/Easter/
[05:11] <zul> i listen to a vaiety as well: punk, metal, celtic, and classical
[05:13] <zul> mostly system of a down right now though
[05:14] <T-Bone> fabbione : http://buildd.slashdirt.org/kde/ if you want to take a look
[05:14] <T-Bone> zul: I like Aerials quite much :)
[05:14] <zul> T-Bone: same..
[05:14] <T-Bone> and Boom does rock
[05:15] <zul> i been listening stuff from their new album ;)
[05:15] <T-Bone> hehe
[05:21] <fabbione> T-Bone: it looks to me like qt3-free-something has been miscompiled on hppa
[05:21] <fabbione> the UIC thing is not from kdelibs
[05:21] <fabbione> the error is bogus
[05:22] <fabbione> usr/share/qt3/bin/uic                                       devel/qt3-dev-tools
[05:22] <fabbione> qt3-dev-tools
[05:23] <T-Bone> fabbione : yeah the error is definitely bogus, that's what i think too
[05:23] <T-Bone> qt3-dev-tools-compat_3.3.3-7ubuntu3_hppa.deb
[05:23] <T-Bone> qt3-dev-tools-embedded_3.3.3-7ubuntu3_hppa.deb
[05:23] <T-Bone> qt3-dev-tools_3.3.3-7ubuntu3_hppa.deb
[05:23] <T-Bone> these are the packages i have available
[05:24] <fabbione> T-Bone: i would check the qt3-dev-tools build log and compare it with another arch
[05:24] <fabbione> T-Bone: yes.. same versions as the one used to build ia64
[05:24] <fabbione> but perhaps something in the log is different and worth checking
[05:24] <T-Bone> ok
[05:24] <fabbione> dpkg-deb: building package `linux-image-2.6.12-1-686' in `../linux-image-2.6.12-1-686_<IP_ADDRESS>-1_i386.deb'.
[05:24] <fabbione> YAY
[05:24] <T-Bone> thx for the hint, i'll look at that
[05:25] <fabbione> ok.. i am off
[05:25] <fabbione> cya tomorrow fellas
[05:25] <T-Bone> cya
[05:25] <zul> toodles
[05:42] <zul> lunch..
[05:50] <T-Bone> hey lamont!
[06:19] <fabbione> hey lamont
[06:20] <fabbione> uname -a
[06:20] <fabbione> Linux gundam 2.6.12-1-686 #1 Mon Apr 11 16:35:21 CEST 2005 i686 GNU/Linux
[06:20] <fabbione> impressive!
[06:20] <fabbione> it even boots!!!1
[06:20] <fabbione> lamont: if you can get around today to update the hppa patches, it would be very nice
[06:25] <lamont> fabbione: I'll make some time to work on that \
[06:26] <lamont> first I need to really do some mail to kernel-team for UDU, etc...
[06:26] <fabbione> lamont: sure.. don't worry.. if you don't get around it before i wake up tomorrow, i will do it
[06:27] <fabbione> mdz was also talking about setting goals for breezy
[06:27] <fabbione> and have a preliminary discussion done before
[06:27] <fabbione> including sabdfl
[06:27] <fabbione> so perhaps you want to CC him?
[06:27] <fabbione> i don't think he is subbed to the mailing list
[06:27] <fabbione> there was also another thing.. who is actually moderating the mailing list?
[06:27] <fabbione> i keep receiving the mails about posts/subscription
[06:28] <fabbione> but i don't have the admini passwd
[06:36] <zul> me either
[06:44] <T-None> Mithrandir: nekkid is booting, all yours. Might want to update it...
[06:44] <Mithrandir> cool
[07:02] <lamont> fabbione: <IP_ADDRESS> is based on rc1 or rc2?
[07:03] <zul> rc2
[07:03] <zul> but im not fabbione :)
[07:03] <zul> you know those president bush masks we should make one a fabio mask
[07:20] <lamont> zul: hehe
[09:47] <T-Bone> Mithrandir: seems that nekkid is having issues
[09:47] <T-Bone> with hotplug, for a change
[09:48] <T-Bone> and since there ain't no kbd driver in the kernel, i'm fucked up
[09:49] <T-Bone> jbailey: wouldn't it be possible to have usb drivers loaded on the ramdisk? (that applies for ppc btw, and imho to any machine that has usb-only keyboards)
[09:51] <jbailey> T-Bone: Yup.  Just include them in /etc/mkinitrd/modules for now.
[09:52] <jbailey> T-Bone: I do that on my ppc64 box for testing initrd stuff.
[09:52] <T-Bone> jbailey: i don't understand why this has been changed again. I already had that problem, already pointed out how *stupid* it was not to have kbd working at that point, and IIRC the default was changed to something more coherent. I guess the change has been reverted at some point
[09:53] <T-Bone> jbailey: i'd love to include them, but for that to happen i'd need to have control over my machine, which i haven\t
[09:53] <jbailey> T-Bone: As far as I know, it's never been included in the initrd.
[09:53] <jbailey> T-Bone: It gives use insufficient sex.
[09:53] <jbailey> s/use/you/
[09:53] <T-Bone> jbailey: no. I think they were builtin
[09:53] <jbailey> Oh, I see.
[09:54] <jbailey> I can see not wanting them built-in when you're trying to get consistant configs.
[09:54] <T-Bone> (which wasn't very good, but at least much better than the present case, for i'll have to burn an ia64 cd, go into rescue mode and toy around
[09:54] <jbailey> But there's no reason to need them built-in.  The right thing is that your initrd should always include those bits.
[09:54] <T-Bone> of course it should
[09:54] <T-Bone> i'm glad i'm not the only one to think that way :P
[09:55] <T-Bone> this is so pissing me off: it's a simple matter of ctrl-C'ing the fucker, and i can't do that :(
[09:55] <T-Bone> i *hate* hotplug when used in stupid ways :P
[09:56] <T-Bone> btw that's a poorly designed script: it should have timeout mechanisms :P
[09:57] <T-Bone> Mithrandir: i'm sorry, you'll have to wait or find yourself another ia64. I don't plan to fix that tonight :P
[09:57] <jbailey> Mithrandir: What do you need?
[09:58] <Mithrandir> jbailey: root on a ia64 debian and ubuntu box.
[09:59] <jbailey> T-Bone: I will provide you with some initramfs love after UDU.  I told Fabio earlier that I would give him a tested patch to kernel-package to do the hooks I need.
[09:59] <jbailey> Mithrandir: my ia64 box is Debian running, although I think I have a hoary chroot.
[09:59] <Mithrandir> jbailey: would you mind lending me root and abusing your network connection?  (The source package is 250-ish MB)
[10:00] <jbailey> That's fine.  It's colo'd at a university, so you might even have a decent connection between you.
[10:00] <Mithrandir> yay.
[10:00] <jbailey> Mithrandir: Put your ssh key on chinstrap or something?
[10:01] <Mithrandir> jbailey:  chinstrap:tfheen-err.no.ssh.dsa.pub
[10:03] <T-Bone> jbailey: heh cool.  I prefer chicks ;P
[10:04] <ogami1972> hello room- Q. whta is best kernel choice for an amdk6 (building is not an option at this stage)
[10:04] <ogami1972> ?
[10:04] <T-Bone> jbailey: and the day i'll consider ia64 for sex, i'll grant you full clearance to erase me from the surface of the Earth ;0)
[10:05] <ogami1972> oooooookkkkk......
[10:05] <T-Bone> ogami1972: that's a question for #ubuntu
[10:05] <ogami1972> ok - thanks
[10:33] <Mithrandir> uhm, what's a decent place to point apt to?  Seems like ia64 is removed from hoary?
[10:38] <zul> heading home...later
[10:40] <jbailey> Is it completely removed?  I thought that they were just not building CDs for it.
[10:41] <Mithrandir> I get 404s, at least.
[10:41] <Mithrandir> and http://archive.ubuntu.com/ubuntu/pool/main/o/openjade/ (random sample) doesn't show any ia64 debs.
[10:57] <Mithrandir> jbailey: yay, this seems to work.  I think it'll work for ia64 in Hoary too.
[10:58] <jbailey> Mithrandir: Cool.  Are you running i386 binaries?
[10:58] <Mithrandir> jbailey: ldd on libc worked. :P
[10:58] <jbailey> Wow, crazy.
[10:58] <jbailey> I didn't know that the kernel was setup to allow that to work. =)
[10:59] <Mithrandir> it's a kinda weird situation, since I want to get it working for {amd64,ia64} {Ubuntu,Debian} where amd64+Ubuntu and ia64+Debian is supported, but not amd64+Debian or ia64+Ubuntu
[11:00] <Mithrandir> oh, it doesn't work since I removed ia32-libs. :P
[11:00] <Mithrandir> yay:
[11:00] <Mithrandir> ia64:/# ~tfheen/ls  -d b*
[11:00] <Mithrandir> bin  boot
[11:00] <Mithrandir> ia64:/# file ~tfheen/ls
[11:00] <Mithrandir> /home/tfheen/ls: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped
[11:09] <jbailey> Crazy.
[11:13] <Mithrandir> (unstable_tfheen)tfheen@ia64:~/ia32-libs$ du -sh .
[11:13] <Mithrandir> 207M    .
[11:13] <Mithrandir> this seems to work, so I'll upload
[11:15] <Mithrandir> I'm off to bed; I'll clean up tomorrow morning
[11:15] <jbailey> *lol*
[11:15] <jbailey> Run away from ther terminal so he can't find you? =)


[14:50] <wilkmar> Hello. Since yesterday I have been trying to add crashdump archive to the bug at https://bugs.launchpad.net/charm-mysql-router/+bug/1959755 but every time I have been getting "Something has gone wrong. We're sorry!" error. The attachment size is less than 300MB. I have been using "Add attachment or patch" for uploading the file. Is it something known? Is there anything I can do about it? Thanks in advance for help.
[23:13] <nickle> Hi everyone, I'm having issues with launchpad and ssh key auth. My public key is uploaded, it's an ssh-rsa key, I have a ssh config for git.launchpad.net and all that, I get this error<EMAIL_ADDRESS>Permission denied (publickey). Also get this error when trying to ssh and testing with -vvv, it offers up my key and seems to be rejected?
[23:14] <nickle> My git config is being applied because if I comment out the lines, I get a different error. The key specified in that config is the private key. The one uploaded is the public key. I'm not understanding what is wrong at this time.
[23:45] <nickle> Update, I got it working by adding 'PubkeyAcceptedKeyTypes +ssh-rsa' to my git config