[21:52:30] what is this "multiarch proposal"? is it a linux-standard-to-be ? [21:52:37] the bad thing is that amd64 people rushed stuff and made stuff biarch. they should have discussed first and pushed multiarch instead [21:53:04] quitte: that would slow down the devel process to release it with sarge, imho [21:53:05] or just a proposal for "multiarch" debian ? [21:53:07] spuk: do you see the biarch problem of i386 and amd64? [21:53:50] spuk: you can and want to run i386 binaries on amd64. but you have to have proper diversion of libraries [21:53:54] quitte: just a bit, i see people talking but havent cared much [21:54:04] understand so far? [21:54:56] i think so [21:55:06] both amd64 and i386 binaries can be executed on amd64. but they have to be able to find their proper libraries [21:55:10] ok [21:55:36] so someone came up and mentioned that with emulation you could run any binary on any machine [21:55:41] quitte: can you forward me the email you have sent to the qemu guys? [21:55:55] so the idea appeared to have multiarch libraries instead of just biarch [21:56:18] i haven't sent anything,yet. but i will forward any relevant mail i might send [21:56:24] ok [21:56:26] as i did in the past ;) [21:56:56] we should set up a project in alioth [21:57:02] quitte: what emulation ? [21:57:15] so /usr/lib64 is just bad. as you would have a conflict with ppc64 for example which would use lib64,too [21:57:28] spuk: anything that qemu emulates for example [21:57:55] spuk: or sbrsh could be used. so basically it really is any arch can run on any arch - theoretically. [21:58:02] but most of it has been proven [21:58:09] for example by scratchbox [21:58:39] and the binfmt-support package [22:00:05] ok, but is this multiarch proposal an "all distributions unite and lets do this", or "hey, we are debian and we know better, lets do this" kidn of thing ? [22:00:30] it is a proposal that others are free to pick up i think [22:00:48] i have just seen it in the debian context so far [22:00:50] were this proposal came from ? [22:01:07] does it matter? [22:01:33] not for debian-purists, i think [22:01:39] if we say it came from debian, you're so biased that you're gonna say "bah", but if we say it came from suse you're gonna like it [22:01:39] spuk: google for debian multiarch proposal [22:02:13] it was a technical discussion that turned into a "debian-purists" and "we are debian and we know better" shit [22:02:28] no [22:02:37] caio1982: no, if it came from debian, i think it will be a debian-only thing forever, if it is from others, maybe everyone will do it [22:02:41] *i think* [22:02:49] think it twice [22:02:58] it was just a technical discussion and it didn't turn into "we are debian and we know better" [22:03:32] spuk: take update-alternatives for example. it was a debian only thing. and everybody picked it up [22:03:37] i'm waiting technical arguments [22:04:00] spuk: take even the conectiva's build proccess before getting bought by mandrake [22:04:02] debian is free to do it the right way. if others don't follow it's good for debian [22:04:41] and doing biarch when it is just a special case of multiarch doesn'T make sense [22:05:30] also it seems the fsf is heading the same direction. binutils for example have a lot of multiarch included now. also gcc while i still dont understand multiarch in gcc at all [22:05:51] s/fsf/gnu project [22:06:24] it wont ever happen in others distros just because they'll never support anything but 386/64 and ppc [22:06:36] that would be a nice "fuck debian" argument, right? [22:06:58] still they might move to usr/host-triplett as it makes life easier for the future and potential ne arches [22:07:29] it might even make it possible to migrate from one platform to another without having to do a fresh install one day [22:07:53] they'll then have to support others arch, which actually is far away from being real [22:07:53] it is a very nice solution that fixes a lot of things i wouldn't even have thought are a problem before [22:08:01] no they dont [22:08:29] biarch is a special case of multiarch. if they have just two architectures in it it'd still work [22:09:14] do you got what support means for commercial distros? you'd have to come to them with the whole shit working and *easy* do migrate to and dont harass them to adjust things [22:09:19] is lsb going to account for "biarch" ? [22:09:38] i don't give a fuck. [22:09:48] and i bet debian doesn't too [22:10:12] hehe [22:10:19] "so we wont support it" [22:10:20] debian is not a framework for other vendors to see what is good or not. it's just a project that makes the best distribution it can [22:10:30] and happens to make the best distro there is [22:10:32] yes, period :) [22:10:50] and while debian is not officially lsb compliant it still is pretty close [22:10:55] "4 legs good, 2 legs bad" [22:11:15] and there allways will be someone that makes debian act lsb conform even if it isn't [22:11:24] lsb? fuck it, some distros even dont have a policy for packages names, come on [22:11:28] spuk: huh? [22:11:51] XfreeShit-1.2-CVS20060101_i386.RPM [22:12:02] 1.2? [22:12:07] nice [22:12:17] yeah! there's a package called XfreeShit in real life :P [22:12:35] ok. i dont want to know [22:13:06] i still dont understand why lsb chose rpm as its package management format. [22:13:07] uh? [22:13:23] quitte: monetary arguments [22:13:27] but then this leaves debian the freedom to change dpkg whenever they want [22:13:59] yes. companies lsb proprietary are all irrelevant [22:15:43] my butt is flat... i must to buy a real office chair quickly [22:16:03] warm bed to the rescue [22:16:31] multiarch is a special case in real life [22:17:01] comparing to single arch or biarch? [22:17:08] biarch [22:17:11] the biarch special case is real life now [22:17:17] pfft [22:17:37] i guess thats the reason why biarch was included too early [22:17:50] what you mean ? [22:17:53] but it can be fixed and it will be fixed [22:18:06] i mean /usr/lib64 [22:18:47] extra trouble to get rid of and amd64 people had a lot of work to modify packages when they could have done the same work for multiarch instead [22:18:56] so work will be done at least twice now [22:19:14] hehe [22:19:23] see [22:19:40] [21:53:04] quitte: that would slow down the devel process to release it with sarge, imho [22:19:53] if people think multiarch is needed, then double work will have to be done, but is it needed ? :] [22:19:54] you meant etch. but thats fine [22:20:00] no, sarge [22:20:04] spuk: yes [22:20:14] they released in parallel, even not being a official release [22:20:19] caio1982: sarge was no amd64 release arch [22:20:26] [22:20:14] they released in parallel, even not being a official release [22:20:31] yes. [22:20:36] stupid bastards [22:20:44] they had all that shit of RC bugs and dates and stuff [22:21:00] yes. stupid rushing things [22:21:16] and now things are delayed because everybody thinks we need etch [22:21:32] another thing: bsds have been able to run linux binaries forever, and didnt need this multiarch thing [22:21:33] if etch get a longer delay to be released, maybe the multiarch thing can be supported at last [22:21:37] and multiarch isn't in enough heads of course [22:21:53] fuck off bsd, we're talking about it in linux [22:21:57] arent we? [22:22:05] we know bsd are better [22:22:16] nah. i bet the freeze will be as soon as gcc-4.1 is considered stable. not enough time to move _every_ library to a new location [22:22:21] im not talking about bsd, im talking about "multiarch" [22:22:26] really? [22:23:13] linux could do that,too. by telling where the libraries are. but you have to clearly define which library should be put in which place [22:23:24] and that is what multiarch is [22:23:26] running a linux binary in a bsd system = running another arch binary [22:23:29] a clear definition [22:24:27] spuk: can you run i386-linux-gnu ppc-linux-gnu sh3-linux-gnu i386-bsd-bsd and all those transparently by just running the binary? [22:24:56] and if you can - do you know where the libraries are and if all dependencies are met for all those arches? [22:25:08] quitte: how would you do that? with the qemu thing? [22:25:13] yes [22:25:15] ha! [22:25:32] you tell qemu where to find the libraries, no? [22:25:35] multiarch is not limited to linux [22:25:47] you tell qemu the loader [22:25:54] the rest is automagic [22:26:13] spuk: that'S a rather trivial thing to do. qemu configure already has %M to have machine type in the default library path [22:26:43] caio1982: so even that is automagic - or up to the maintainer [22:26:52] sure [22:27:16] the point is: why change the filesystem layout, causing trouble to stablished programs and practices, and adding complexity to the system? [22:27:28] change the FS layout? where? [22:27:41] nono. it is adding simplicity. everything is well defined and fairly easy [22:27:43] i guess you didnt get the /lib64 thing [22:27:55] it's the problem, not the solution [22:28:22] --> Amaya has joined this channel (n=amaya@debian/developer/Amaya). [22:28:46] hey catwoman [22:28:48] isnt the multiarch thing about adding a directory to separate arch-specific libs ? [22:28:52] right. havin lib and lib64 works for biarch. but if you add a possibly infinite number of arches you cannot add more /usr/libsth by random names [22:28:54] NO [22:28:57] oh man [22:29:12] multiarch is about to solve it [22:29:21] spuk: even /usr/lib is going to be moved to a arch specific directory [22:29:29] to mix the things and let the system magically guess what and where is everything for each arch [22:29:39] thats what im saying! [22:29:41] Amaya: hola [22:30:06] spuk: you figured it out in some reverse way, i bet it [22:30:13] it's the opposite [22:30:21] you move */lib to elsewhere, and then causes trouble to auto*, binary-only stuff (ok you dont care, but ubuntu cares :]), etc. [22:30:40] it wont move anything away [22:30:48] spuk: you are also implying that this is complex. but it is more complex to assume that there is a host arch and the others are additions. you just treat the host arch as any other arch and problem disappears [22:30:49] that was amd64 people tried [22:31:02] and keeps hoping everyone else will see the light and move to multiarch world [22:31:08] bah [22:31:32] spuk: i actually hope others won't do it and loose market share to debian [22:31:37] haha [22:31:41] at least for multiarch projects [22:32:17] btw, your siemens partner seems very interested in ubuntu and debian stuff so guess what they will can use in the near future [22:32:26] i think that would be more correct written as "at least for "for multiarch" projects" [22:32:29] Amaya: unfortunately you missed the last uhm 1 hour. was a nice introduction to multiarch i think [22:33:01] caio1982: uh? [22:33:27] caio1982: is that slind related? [22:33:35] quitte: maybe [22:33:50] they didnt confirm if it's slind [22:34:07] i think ill try to discuss about this multi-arch thing with more experienced people and get opinions [22:34:19] do that [22:34:23] do that [22:35:07] could any of you comment on how this could relate to netbsd ? [22:35:42] like: why netbsd (the most "multi arch" project by now, i guess) never did this ? [22:35:42] debian will blow netbsd argument of cross compilability to nowhere [22:36:03] what argument ? [22:36:20] you can compile base on any arch for any arch [22:36:37] with debian it will be you can compile everything anywhere for anywhere [22:36:42] it's a hard argument to beat up [22:37:02] quitte: where the multiarch idea fits into sbox2? [22:37:08] and run anything for anything anywhere [22:37:23] since it will be almost useless for simple emulation and cross-c [22:37:30] sbox2 is the part that adds the transparent compiling into the transparent running [22:37:47] for things that dpkg-cross cannot do [22:37:58] ah [22:38:24] Amaya: i have logs of the last 1h, btw [22:38:54] caio1982: online them. or even better clean it and put it online so thers can comment. [22:38:55] in fact ihave logs of the last five hours [22:39:19] would it worth? [22:39:44] it's just us trying to make spuks mind without any success (for obvious reasons) [22:40:04] i think so. this is something that a lot of people do not understand. and the proposal is too short and doesnt explain what the result of it is in enough detail, i guess [22:40:50] there are enough people but spuk to convince this is good. also we probably misunderstood a few concepts - so having that corrected by those that know better was great. [22:41:02] what is the use of that multiarch besides amd64 ? [22:41:12] any arch [22:41:21] all of them