[01:00] slangasek: what package are we assigning hotkey issues to nowadays? [01:55] * lamont looks around for jdstrand or any ufw-literate person so he can grumble at them [01:55] I can use it, but I didn't write it, does that help? [01:56] lamont: yes? [01:56] StevenK: how the hell do I add a rule to ufw-user-forward through the &%(%) CLI? [01:56] lamont: you don't-- ufw doesn't allow modification to that chain (yet) via the cli [01:56] lamont: but you can add it to /etc/ufw/before.rules (or after.rules if it makes sense to you) [01:57] jdstrand: ah... that would explain my frustration.... so... given ufw alive and well on the machine, how do I have forward rules [01:57] ? [01:57] or do I just throw baby and bathwater out? [01:57] * lamont learns to read while typing [01:57] lamont: think of ufw as two parts: a) the cli command and b) the framework [01:57] eh? [01:57] Haha [01:57] rotfl [01:58] I would love it if ufw would support SNAT and forwarding rules. [01:58] lamont: the cli command allows for very easy host-based firewalls. the framework allows for all the power of iptables [01:58] lamont: so, add what you want to before.rules, then do 'sudo ufw disable ; sudo ufw enable' [01:59] StevenK: nat would be nice yes [01:59] jdstrand: Fix it? :-D [02:00] StevenK: sure, I don't seem to have your patch... :P [02:00] yeah... my big issue is (1) two different users with firewall needs that are not up to iptables, but want to co-admin what I set up for them, and (b) the pain that an incomplete ufw brings [02:00] Haha! [02:00] mixed in with the fact that I've never even used iptables-restore... [02:00] That's my current firewall script [02:00] * lamont has always just rolled his own - it's not like it's complicated or anything... [02:01] (given a network-engineering background) [02:01] lamont: Simplest way to use iptables-restore is run iptables-save > file, edit the file and iptables-restore it [02:01] * jdong has observed most people struggling with setting up iptables general don't have a solid grasp of what they are trying to do conceptually... [02:01] lamont: for the most part, you can write an iptables rules, and leave iptables off the front [02:01] not to downplay the significance of that hurdle of course :) [02:02] heh [02:02] lamont: if I may say, ufw works quite well for host-based firewalls. more than that and there are a few niggles, but works pretty well for the most part [02:03] jdong: exactly. given a firm understanding of the protocol interactions, iptables is trivial. without it, well... pain [02:03] right. [02:03] Pain and insecurity. [02:03] lamont: using it for routing is doable, but likely too hard for now [02:03] generally when you find someone griping about iptables and ask them to explain specifically what they are trying to do, they fail to be able to do so without resorting to magical terms :) [02:04] but, it is actively being developed... I seem to remember StevenK offering a nat patch not too long ago ;) [02:04] * StevenK kicks jdstrand [02:04] hehe [02:05] * kees waves good-bye to opera [02:06] hey StevenK [02:06] kees: Why? [02:06] * StevenK waves to NCommander [02:06] StevenK, how was your flight? [02:06] wgrant: it's not in the partner archive any more except for jaunty [02:06] NCommander: Crap [02:06] kees: Oh, why? Security? [02:06] wgrant: yeah [02:06] * wgrant sleeps at StevenK. [02:06] StevenK, ah, I know the feeling [02:07] kees: security hard. lets go shopping [02:07] wgrant, NCommander: I slept on the plane for 6 hours, that wasn't why it was crap [02:07] Oh. [02:07] * wgrant fidgets instead. [02:07] * NCommander had turberance all the way from Chicago to Rochester [02:07] First time I ever got quizzy while flying [02:07] * StevenK kills wgrant, casts Redepmtion on him, and then brutally kills him again [02:08] * wgrant is uninterruptable. [02:08] NCommander: The flight was bumpy and turblent, the service was terrible, and BABIES! [02:08] Argh, babies! [02:08] * NCommander removes the NMI for wgrant and then calls int wgrant [02:08] Ah yes, the babies. [02:08] They weren't too bad from where we were (the back row), but they were present. [02:09] What was wrong with the service? [02:09] Slow [02:09] I pressed my call button and waited ten minutes, two times [02:09] I did notice that they seemed to do only one side at once and were fairly late. [02:09] Hah. [02:12] hey erbody [02:57] * lamont grumbles at the menu system.. generally speaking, where is the command associated with a menu in the stock menus found? more specifically, how do I see what command is exceuted for "administration -> create a usb startup disk'?? [02:58] or should I just go to bed/ [02:59] * lamont finds his answer, or at least enough of one [03:21] * wgrant wonders what is going on with yorick's armel build. [03:21] I've seen it building at least three times today. [03:22] what does the log look like when it dies? [03:22] Illegal instruction. [03:25] \o/ [03:26] But somebody keeps retrying it, but it doesn't look like a normal give-back. [03:28] interesting [03:35] * lamont -> home [03:36] I'd like to see an SRU for LP #216761 in both Hardy and Intrepid. Is there some way I can represent in ths bug status that the bug has been fixed in Jaunty, but Intrepid is still affected? [03:36] Launchpad bug 216761 in xen-3.2 "errors in xendomains init script" [Undecided,Confirmed] https://launchpad.net/bugs/216761 [03:39] Should I just open a separate bug for the SRU? [03:41] calc: suitesparse> that's fine [03:41] doko: cython> ah, thanks [03:42] Good morning everyone [03:42] * StevenK waves to pitti [03:42] * pitti hugs StevenK [03:42] pitti: where are you? it seems quite late for DE [03:42] LaserJock: no, it's rather terribly earliy [03:43] 4:42 [03:43] but I can't sleep any more [03:43] pitti: can't sleep? :) [03:43] ugg [03:43] pitti: jet lag? [03:43] yeah [03:43] I slept 2 hours in the plane Sat-Sun, and four hours last night, now 5 hours [03:43] so I'm making progress :-P [03:50] I'd have thought by now you'd be used to UDSlag [03:50] maybe a person's body never really gets used to it [03:51] I'm dealing with jetlag much better than when I started going to UDS [03:51] hey pitti [03:51] awake here (3am) [03:52] I think I'll need one more sleep cycle, and I'll be back in the timezone [03:53] I've only been to 2 out of my timezone, but I think I had more problems while I was there than when I got home [03:54] 'course the Ubuflu got me a few days sleep post- [03:54] That's what Melatonin is for, but I only needed that once [03:54] UDS [03:55] StevenK: it helps if you don't have a regular sleep cycle anyway :) [03:55] perhaps you could try adjusting to the new time zone a few weeks before going to UDS [03:56] ajmitch: I do so! [03:56] fortunately I didn't get UbuFly on either the way there nor back this time \o/ [03:56] erm, UbuFlu [03:56] Very few got UbuFlu. [03:56] I think I missed out, too [03:57] Hmph. How am I supposed to modify $PATH in debian/rules ? [03:58] StevenK: "export PATH" ? [03:59] make variables are not exported as environment variables by default [03:59] Well, I want to modify it first [03:59] Neither $$PATH, $PATH or $(PATH) are giving me love [03:59] export PATH := whatever:$(PATH) [04:00] Oh, duh, := [04:00] * StevenK kicks make for being obtuse [04:01] ":=" to evaluate immediately [04:01] Yup [04:01] Hence the "Oh, duh, :=" [04:01] * calc was one of the UbuFlu victims [04:05] * NCommander may be developing UbuFlu [04:05] Freaking free viruses [04:05] NOT WHAT I WANT! [04:09] NCommander: that's why you are using Linux, aren't you? [04:09] Viruses shouldn't be freeware ... [04:09] or shareware [04:09] it's all about sharing [04:19] NCommander: Next time you'll know to sit next to people you don't like and breath on them. [04:19] * StevenK stares at the buildlog for apex which insists -Bsymbolic-functions isn't valid [04:19] ScottK-laptop: Harsh [04:19] But realistic. [04:20] Someone remind me to keep at least one room distance from ScottK-laptop [04:20] StevenK, apex is packaged? [04:21] And in both Ubuntu and Debian [04:21] Apparently not very well. [04:21] I think it's an upstream thinko [04:23] * StevenK hits ScottK-laptop with the shovel he just used to move blame around [04:23] lol [04:24] * NCommander grumbles :-/ [04:24] * ScottK-laptop has had too much Scotch to actually feel it, so whatever. [04:24] o_o; [04:24] * NCommander decides to take another whack at kde [04:26] NCommander: KDE on armel? [04:26] yeah [04:26] Argh [04:26] kde4libs is still building [04:27] * LaserJock just lost his grading pen :( [04:27] * NCommander is currently waiting for a few more test images to finish with imagewriter-qt [04:27] LaserJock: all you need is a big red pen, right? [04:27] ajmitch: yeah, but i was down to my last one [04:27] I got up, got a drink of water, came back, no pen [04:28] but I just found it behind my laptop so all is not lost [04:28] poor students :-) [04:28] Ah ha. Now I get why apex built on Debian, but not Ubuntu. [04:28] dpkg-buildpackage: set LDFLAGS to default value: -Wl,-Bsymbolic-functions [04:42] So apex is fixed StevenK [04:42] NCommander: Oh? [04:43] ^? [04:43] NCommander: Fixing. It's in the queue after this schroot build [04:43] ah, nice :-) [04:43] We should probably have redboot packaged ... [04:44] gcc-snapshot adds a whole lot to the Build-Depends [04:58] calc: no, suitesparse is in hardy/universe, and I can't find a MIR wiki page or bug [04:58] pitti: Looks like I need three armel packages promoted for d-i, shall I write three MIRs and prod you? [05:03] pitti: it had been in main for 3.0.0-3 in gutsy but got knocked back into universe [05:04] pitti: lp-solve had also been in gutsy main at one point but got knocked back out as well [05:41] For a package that's not in Debian, am I supposed to set XSCB-Original-Maintainer, or am I the maintainer? === nxvl_ is now known as nxvl [06:42] morning [06:43] morning [06:47] * pitti recovers from X segfault after dist-upgrade [06:47] StevenK: just subscribe ubuntu-mir, I'll get mailed [06:47] calc: okay [06:48] pitti: good morning [06:48] hey nxvl [06:48] slightly more civilized time now :) [06:49] pitti: Hum? Do I need to write 3 seperate MIRs, or something else? [06:49] StevenK: if it's three unrelated sources, yes; if they are trivial, just file bug tasks [06:50] * StevenK needs to fix one of them to build first [06:50] tjaalton: so you broke X on G945 :) [06:54] pitti: Do you think it's specific to this chip? I'm pondering dist-upgrading to jaunty, but then not if I'd miss xorg on intel (I have g33 though) [06:54] pitti: you have a 2 lines terminal, right? [06:54] lool: I don't know [06:54] good morning [06:54] nxvl: "2 lines"? [06:54] s/terminal/promt [06:54] hey dholbach [06:54] promt [06:54] nxvl: yes, why? [06:55] hi pitti [06:55] pitti: i'm playing with mine, and i'm having a strange issue, when i type a long command which doesn't fit in my terminal it continues on the beggining on the same line [06:55] pitti: have you seen something like this [06:55] dholbach: hi! [06:56] nxvl: only on the VTs, not in gnome-terminal [06:56] i've it everywhere [06:56] hiya nxvl [06:57] pitti: yes, and no way to fix it until the drm.h issue is solved (the segfault is fixed upstream) :) [06:58] tjaalton: oh, is that the linux-libc-dev vs. libdrm-dev file conflict? [06:58] pitti: yes [06:58] tjaalton: ah, so if I rebuild -intel against the right one, it shuold work? [06:58] everything that b-deps libdrm-dev should fail to build [06:58] pitti: it's a bug in the xserver, not the driver [06:58] tjaalton: I just tried locally rebuilding -intel, doesn't work [06:58] oh, ok [06:59] tjaalton: so that's xorg-server? [06:59] pitti: yes [06:59] bug 308225 [06:59] Launchpad bug 308225 in xserver-xorg-video-intel "X intel driver crashed at xf86CrtcSetMode()" [Unknown,Confirmed] https://launchpad.net/bugs/308225 [06:59] duh [06:59] tjaalton: I'll duplicate my bug then (bug 308464) [06:59] Launchpad bug 308464 in xorg-server "1.5.99.3 crashes on G945: intel(0): Unable to write to SDVOCTRL_E for SDVOB Slave 0x70" [Undecided,New] https://launchpad.net/bugs/308464 [07:00] pitti: oh, that might be different, let me check [07:00] tjaalton: I do have the current version, though, so it's not FTBFS [07:00] pitti: I meant that uploading a new version would FTBFS [07:01] pitti: slugimage and uboot-mkimage look completly trivial, do you still want MIRs? [07:01] StevenK: as I said, only for nontrivial packages; we always need MIR bugs, but not always wiki pages [07:03] pitti: looks similar enough, I'll dupe it [07:03] pitti: Okay, I'll file one bug for all three, but only do a report for apex. [07:14] k, fixed [07:32] bryce: depends on the kind of issue? :) [07:42] what should be done about bug 308387? [07:42] Launchpad bug 308387 in linux "[Jaunty] trying to overwrite `/usr/include/drm/drm_sarea.h', which is also in package libdrm-dev" [Undecided,Triaged] https://launchpad.net/bugs/308387 [07:43] debian does not have drm/* in their package, so the change seems to have pulled in a bit too much [07:43] tjaalton: can you set https://blueprints.edge.launchpad.net/ubuntu/+spec/xorg-jaunty to completed (unless you wish to use it for tracking progress or something)? [07:45] bryce: hmm ok [07:48] pitti: MIR filed. Bug 308465 [07:48] Launchpad bug 308465 in uboot-mkimage "MIR for slugimage, uboot-mkimage, devio and apex" [Undecided,New] https://launchpad.net/bugs/308465 [07:48] pitti: I should say sorry for including the word "hand-wave" in an MIR [08:04] tjaalton: bug 308225 updated; I have my normal X back \o/ [08:04] Launchpad bug 308225 in xserver-xorg-video-intel "X intel driver crashed at xf86CrtcSetMode()" [Unknown,Confirmed] https://launchpad.net/bugs/308225 [08:05] yay pitti [08:05] tjaalton: hey, and the "Control-C kills server" bug is fixed, too === dholbach_ is now known as dholbach [08:10] pitti: great, I've pulled 1.6-branch and will upload. it will FTBFS though because of the aforementioned kernel bug [08:18] tjaalton: thanks [08:22] bryce: my pleasure ;) [08:22] pitti: strange, AllowEmptyInput is the default [08:22] tjaalton: I killed xorg.conf again, doesn't crash any more; I needed the file with 1.5 [08:22] pitti: so the ctrl-c thingy should've not had any effect [08:24] tjaalton: I found I needed to tell evdev to GrabDevice on statik's VM last week. [08:24] Same on my machine. [08:24] It works fine without now. [08:24] huh, weird [08:25] Yes. [08:25] but, if it works now.. \o/ [08:25] Yep. [08:25] Once that segfault gets fixed. [08:26] yep.. and not everyone can/should touch the kernel [08:26] Of course. [08:26] so it'll take some time [08:26] heya fabbione [08:26] hey bryce [08:27] I guess no-one has tried nvidia/fglrx with the new xserver? === tkamppeter_ is now known as tkamppeter [08:28] I don't think anybody is that crazy. [08:28] There's a new video ABI, isn't there? [08:29] wgrant: yes, the packages should be rebuilt if they work [08:31] I assume both are busted now [08:31] And probably will be until the day before release. [08:31] safer to assume that :) [08:32] but not necessarily, since there shouldn't be same kind of API changes like with 1.5, AIUI [08:32] wgrant: well, I'm scheming to get them working sooner than that ;-) [08:32] I'll install a box with 8600GT to test nvidia.. [08:47] tjaalton: concerning drm, I wrote to upstream a while ago and he said that the drm headers were now moving to the kernel; so I understand that we should drop them from libdrm and add Replaces [08:48] I can forward you the emails if you like [08:48] lool: ok, that would be nice [08:50] heya lool [08:57] hey [09:09] tjaalton, bryce: forwarded [09:12] lool: thanks [09:16] pitti, hi [09:18] <\sh> pitti: taking care of bug #298611 [09:18] Launchpad bug 298611 in ia32-libs "ia32-libs 2.7ubuntu1 missing libuuid.so.1, breaks flash" [High,In progress] https://launchpad.net/bugs/298611 === Tonio__ is now known as Tonio_ [09:29] <\sh> pitti: why didn't you merge all the changes from intrepids into jaunties ia32-libs regarding debian/rules? [09:30] \sh: I did, TTBOMK; there might have been some obsolete stuff; what do you mean in particular? [09:30] <\sh> pitti: the libnspr4.so.0d symlinks as an example :) [09:31] \sh: that didn't apply any more (I don't remember the reason any more, though) [09:31] <\sh> pitti: ah ok...I'll have a look...I hope that they are set now by default :) [09:31] I didn't just ignore it, I remember investigating this [09:34] is it okay to request a sync now if it build-depends on something i need to 0ubuntu1 this evening? [09:35] directhex, what needs syncing? [09:35] <\sh> does anyone has problems connecting to a.u.c (91.189.88.40)? [09:35] a.u.c? [09:35] expansion needed :-) [09:35] archive.ubuntu.com [09:36] Yes. [09:36] \sh: WFM [09:36] NCommander, gnome-subtitles from experimental. it has a new dep which is in debian NEW right now, so i need to 0ubuntu1 it [09:36] directhex, no Ubuntu changes? [09:36] \sh: well, I might have caught a different mirror, of course [09:36] Is that in main or universe? [09:36] NCommander, ubuntu changes? this is pkg-mono you're talking about! and it's universe [09:37] fair enough [09:37] Ok [09:37] What you can do is a fast sync [09:37] Version an upload with 0build0 (or something equivelent) [09:37] Essentially what your doing is making it so when gnome-subtitiles clears NEW, it will autosync [09:37] aha, clever [09:38] thanks for that [09:38] (you could probably use 0sync0, but the version string must be less than 1, and not contain the ubuntu substring for this handy trick to work) [09:39] Rather handy that "ubuntu" comes late in the alphabet, all things considered :-) [09:40] Actually, the ubuntu substring is what kate uses to determine if it should autosync something [09:40] (as far as kate is concerned, 0ubuntu1, 0~ubuntu1, etc. are all equivelent) [09:41] What I mean is, it's because b < u that it doesn't have to be -0~build0, right? [09:43] Yeah [09:43] I know we do some funny things w.r.t. to versioning in dpkg [09:44] the alphabet is one of my main complaints about the popular "~ppa" suffix ;) [09:44] * NCommander hates that hack [09:44] PPAs should autoversion like REVU [09:45] NCommander, perhaps. they certainly shouldn't encourage use of ~ppa which supersedes foo-backports' ~foo [09:45] ACK [09:45] well, that problem goes away once persistent prawn gets released [09:45] TBH, crackport and SRU versioning is fairly miserable [09:45] crackports are slightly better [09:46] I wish SRU would just standardize on one style of versioning and that would be that :-) [09:46] the most awesome package version in the world though has to be 10.0.1.218+10.0.0.525ubuntu1~hardy1+really9.0.124.0ubuntu2 [09:46] * NCommander hears Scott groan [09:46] There is a really sad story about that one [09:47] directhex: it's clearly missing +added+salt+and+pepper+stab+stab+stab in the version number. [09:47] directhex, well, that happened because we had a crackport that broke firefox and flash [09:47] :-) [09:47] <\sh> sounds like flash ,-) [09:47] We had to do an emergency downgrade [09:48] NCommander, or qt3? 3:3.3.8really3.3.7-0ubuntu11.1 [09:48] TBH, I don't know the story about that one. [09:48] it was flash. I backoprted it before it was final and it broke the 64 bit users so it was reversioned [09:49] Flash doesn't even work on 64-bit archs O_o; [09:49] NCommander, iirc 3.3.8 had a completely broken databse lib [09:49] NCommander: it sure does [09:49] there's a 64-bit flash lib now [09:49] flash-nonfree works on 64-bits out of the box? [09:49] We don't support it in Ubuntu [09:49] 64-bit flash is not freely redistirbutable [09:49] but nspluginwrapper is a sorry beast. it takes me ~7 browser restarts to read my daily webcomics [09:50] * NCommander hugs his 64-bit flash plugin [09:50] NCommander: we dont support it due to it being non-free [09:50] No more sudden firefox crashs [09:50] gnomefreak, when I say support [09:50] I mean any support [09:50] YOu can't install 64-bit flash via apt-get [09:50] NCommander: why cant you? [09:50] <\sh> oh darn... [09:50] you can't redistribute the 64-bit flash binaries [09:50] NCommander, meanwhile, i have a nice friendly 64-bit moonlight plugin sat right here... [09:50] It says so in the license [09:51] directhex, right, but there are no useful silverlight pages out there [09:51] <\sh> if this ia32-libs insaneness doesn't stop...we deliver a complete libubuntu 32bit version in it [09:51] NCommander, that's because everyone(tm) uses flash! [09:51] \sh, multiarch dpkg! [09:51] directhex, try dpkg-cross/apt-cross [09:52] <\sh> pitti: what do you think about bug #277454 [09:52] Launchpad bug 277454 in ia32-libs "libSDL_image.1.2.so.0 and libpython2.5.so.1.0 are missing in ia32-libs" [Wishlist,New] https://launchpad.net/bugs/277454 [09:52] \sh: at the given rate/size I seriously consider replacing it with a 1 KB shell script to set up a 32 bit chroot [09:52] * NCommander has coded against SDL [09:52] NCommander, showing my age here. i remember discussing multiarch amd64 with Mithrandir yeeeeeeeears ago [09:52] Why can't we simply use apt-cross in this case [09:52] this is and remains a pain in the butt, and it is a gross and unsupported hack [09:52] the ia32 linker actually works last time I checked [09:53] ^with apt-cross's paths [09:53] * NCommander would love if we could kill ia32-libs [09:53] lool: so, linux-libc-dev needs Replaces: libdrm-dev (<= current), and the new libdrm-dev should just drop the headers and possibly depend on linux-libc-dev? [09:56] oss/c [09:58] that was weird [09:58] updated to intrepid-updates, and every single process segfaulted after the reboot === Sp4rKy is now known as Guest46561 === Guest46561 is now known as Sp4rKy [10:00] tjaalton: No, you need to push a new libdrm first [10:00] Keybuk: ! [10:00] tjaalton: then replace libdrm << new-version [10:01] tjaalton: You might also want to add some versionned dep one way or the other e.g. let the new libdrm dep on the new linux-libc-dev [10:01] pitti: it's mysteriously fine now [10:01] things went wrong after the nvidia module was build and assumedly inserted [10:01] but after a reboot it was ok [10:01] I'm also suspicious that the machine gave one of its strange beeps on the reboot before, and may have needed a full power down [10:04] lool: of course, libdrm is first. and I can't add the Replaces to linux-libc-dev, so that'll just have to wait [10:04] The two uploads need to be coordinated [10:04] tjaalton: Do you have a new libdrm upstream version without the headers? [10:04] lool: in a minute [10:05] upstream? no [10:05] tjaalton: Perhaps you want to poke upstream about it? [10:05] the thread was in september [10:05] and we're well within 2.6.28 now [10:05] lool: why? isn't it enough to just drop them from the package? [10:05] oh you mean it's newer in .28? [10:06] gah, those are never going to be in sync [10:06] tjaalton: It's enough, but if you get a new upstream version it will be best that this API move is made upstream and your dependency will look like replaces: libdrm << x.y and will be compatible with debian's [10:06] libdrm releases are rare [10:06] Yeah :-/ [10:07] tjaalton: still wouldn't hurt to ask for a heads up [10:08] lool: ask who? I'm lost now :) [10:08] Dave Airlie [10:15] <\sh> pitti: the symlinks are provided now automagically ,-) [10:17] lool: seems to be too late/early to get a prompt reply [10:19] tjaalton: I guess you need to grab someone from the kernel team to ack this move and coordinate your uploads [10:20] <\sh> bah uploaded that monster of source package [10:22] asac: Michael Biebl was on a NM packaging spree yesterday and today; might be an useful merge (not sure how closely you cooperate) [10:25] \sh: it was nice while it consisted of 10 packages, but right now it is an unmaintainable and very brittle monster; WDYT about dropping it completely and providing a shell script around debootstrap instead? [10:25] Can someone explain to me why ia64 is building ia-32libs? [10:25] I honestly think that would be much more maintainable [10:25] NCommander: because it needs it to run ia32 executables? [10:25] NCommander: It can use it. [10:25] ia64 can run ia-32 binaries? [10:25] <\sh> pitti: well, the problem will be wine32 for amd64 [10:25] I thought that only worked in Windows because MS enginneereed a software emulator [10:25] \sh: can't that run in a chroot? [10:26] <\sh> pitti: that was what I was proposing since ages...but nobody agreed on this one with me :) [10:27] <\sh> pitti: talk to Yokozar (Scott) about it..because the whole ia32-libs situation is a mess...and should be cleaned up asap [10:27] \sh: that's what I did last week [10:27] Scott said he might go for changing the packages to build lib32foo [10:27] but that's a huge effort as well [10:28] so until (if ever) we get proper multiarch support, people should install a 32 bit chroot [10:28] <\sh> pitti: that will take ages.. [10:28] NCommander, it's emulated, but YES [10:28] There's been some effort to move to lib32 in Debian. [10:28] It's an enormous amount of work in either case [10:28] but even building lib32foo is just a hack, and far from a proper solution [10:28] besides utterly complicating packaging [10:29] <\sh> pitti: and yes...the 32bit chroot with dchroot magic will help us all...but that was my proposal for people needing wine on amd64 in 2005/2006 already... [10:29] .... [10:29] wine works on amd64 [10:30] And if you don't think it doesn't, at least ajmitch and I use it to play WoW [10:30] StevenK: without ia32-libs? [10:30] <\sh> StevenK: it does work because of the ia32-libs madness [10:30] jms@orac:~> uname -m [10:30] ia64 [10:30] jms@orac:~> file a.out [10:30] a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.4, dynamically linked (uses shared libs), for GNU/Linux 2.6.4, not stripped [10:30] jms@orac:~> ./a.out [10:30] Hello World! [10:30] NCommander, ^^ [10:30] <\sh> StevenK: and no, wine on amd64 doesn't work...because they are starting right now to implement win64 apis ,-) [10:31] directhex, you must love your itantic [10:31] and wine works fine on amd64 [10:31] NCommander, jms@orac:~> grep -c ^processor /proc/cpuinfo [10:31] 256 [10:31] doko_: should packages still b-dep on java-gcj-compat-dev? or default-jdk-builddep only? [10:31] o_o; [10:31] NCommander, who couldn't love that face? [10:31] Ah, but with ia32-libs [10:31] directhex: Guh? [10:32] wine is 64-bit native app [10:32] It just can only run 32-bit windows apps [10:32] And given the state of 64 on Windows, I think Linux will have 64-bit windows apps before windows users :-) [10:32] NCommander: It does require ia32-libs, though [10:32] StevenK, would you believe me if i said gnome is still a big sluggish on there? [10:32] It does? [10:32] <\sh> NCommander: yes [10:32] NCommander: It's in the Depends line [10:33] neat [10:33] <\sh> NCommander: because native wine on amd64 would give you win64 compatiblity ;) [10:33] directhex: Gnome is perfectly usable on my amd64 :-P [10:33] \sh, not that simple [10:33] <\sh> directhex: if it would work right now...but it never worked ;) [10:35]