IRC Logs for #crux-devel Wednesday, 2012-05-09

*** jue has joined #crux-devel01:28
*** pedja has quit IRC01:50
juejaeger, frinnst: good news wrt glibc -> http://thread.gmane.org/gmane.comp.lib.glibc.alpha/2090002:07
juethat's the release plan for 2.16 -> http://thread.gmane.org/gmane.comp.lib.glibc.alpha/2081102:08
*** mike_k_ has joined #crux-devel02:18
*** mike_k_ is now known as mike_k02:36
*** sepen has joined #crux-devel05:13
*** prologic has quit IRC06:42
*** frinnst has quit IRC06:42
*** frinnst has joined #crux-devel06:42
*** frinnst has joined #crux-devel06:42
*** prologic has joined #crux-devel06:42
*** prologic is now known as Guest9140106:43
*** Guest91401 is now known as prologic06:50
*** prologic has joined #crux-devel06:50
jaegerjue: cool07:16
*** acrux has quit IRC08:03
*** acrux has joined #crux-devel08:10
*** acrux has joined #crux-devel08:10
jaegerjue: I assume you're thinking glibc 2.16 should be the one we focus on for crux 2.808:10
*** joe9 has joined #crux-devel08:22
*** deus_ex has joined #crux-devel08:31
frinnstjue: nice09:18
frinnstthe rpc removal was quite stupid09:18
frinnstjust broke everything09:18
jaegeryeah, it was09:20
jaegerreplacing them with tirpc is a fine idea but it should have been tested first09:20
frinnstheh, considering tirpc doesnt even build without the glibc headers :)09:21
frinnst#glibc seems quite lively too, with devels hanging around09:22
jaegercool09:23
*** tilman has quit IRC09:39
juejaeger: well, if I look at their schedule it seems possible to use it, hopefully together with gcc 4.7.1 ;)09:41
juebut that's just an idea, we are free to do it in another way09:42
jaegerI've got no objection to that, was just curious09:44
jaegerI'm definitely against gcc 4.7.0 but if 4.7.1 is available that'd be worth a look09:44
*** tilman has joined #crux-devel09:46
jueagreed, we should use a .0 release of gcc09:47
juebtw, if we are talking about a new release09:47
jueany ideas about a senseful way to make a decision which arch will be our new default09:48
jaegershould or should not? :)09:48
juesorry, should not09:48
jaegerJust wanted to make sure, hehe09:49
jaegerMy personal preference would be to make x86_64 official. As for multilib vs. pure I don't really care which is official as it's easy to convert between the two09:49
jaegerI'm not even running i686 anywhere except VMs anymore09:49
jaegerThough it's certainly easy to keep around in a VM or a chroot09:52
juehere everything is still i686, but only my old pentium laptop is i68609:52
*** pitillo has quit IRC09:53
jaegerEven if we kept 32-bit as the official arch I'd still run x86_64 multilib on my stuff09:54
jaegerRegardless of which is the official "default" I think we should officially support x86_64 at least, even if we support both x86_64 and i68609:55
*** pitillo has joined #crux-devel09:55
juehmm, I'd prefer a switch to x86_64 as well09:55
frinnstI wonder how many new crux-installs are i68609:56
juethink it's too much work/hassle to support both archs09:57
jaegerPPerhaps it would be, not sure09:57
jaeger-P09:57
frinnstmaintaining i686 like i've maintained x86_64 isnt that much work10:00
frinnstjust the toolchain and specific ports10:00
juehmm, if we do it 'official' we should create two complete repo branches, with only tested port in it, IMO10:02
jue*ports10:02
juebut having only unofficial support for i686 shouldn't be a problem10:03
juefrom a repo point of view the easiest way go would be:10:04
juea) create a new branch, let's say CRUX 3.010:04
jueb) merge the stuff from frinnst and jaeger in10:04
jueb) done10:04
jueafter that we can delete or at least freeze the current *-x86_64 repos10:08
* teK_ votes for pure 64 bit with optional 32 bit (multilib)10:09
jaegerThe only downside I see for pure64 with optional multilib is that we have to maintain separate pkgutils10:12
jueteK_: what's your problem with a multilib tool-chain?10:12
jaegerNot that that's a problem, it's what we're doing now10:12
teK_i dont need it10:12
jaegerDoes it cause you problems or any tangible overhead? I haven't really tested that sort of thing10:12
teK_I cannot say for sure but I'd guess that it'll hurt hdd-usage wise only.10:13
teK_Romster10:13
jueteK_: sorry, what do you mean with 'hdd-usage wise'10:14
jue?10:14
teK_it'll just use more space on my hdd10:14
teK_which is no drama at all10:14
teK_but we're source-based and there how many ports requiring 32bit libs? .. 5?10:14
jaegerThat's undoubtedly true, I wonder how much more it uses10:14
teK_possibly skype and wine. I don't know of any other10:15
jueoops, that should be negligible if you don't install any *-32 packages10:15
jaegerhttp://jaeger.morpheus.net/linux/crux/files/multilib/toolchain/ <-- there are compressed toolchain packages here that could give an idea of the size comparison10:15
teK_glibc would be the only -32 package?10:16
jueIMO the only 32-package we should ship with our ISO is glibc10:16
teK_after installation one 'd have to rebuild the other toolchain stuff, right?10:16
teK_which would be the coolest thing to have, i.e. optional multilib support10:17
juefor me the best way is to have the multilib toolchain in place, and optionally have the possibility to start building -32 stuff10:19
teK_what'd -32 stuff be?10:20
teK_after quite *some* years 64 bit usage I only can imagine wine and binary stuff like skype10:20
juemostly libs I guess10:20
teK_whoot, do you have an example?10:20
jueglib-32, zlib-32 etc10:21
jaegerwine for example uses 58 -32 ports10:22
jaegera bunch of them are xorg ports10:22
teK_so basically it's wine. -_-10:23
juejaeger: btw, git://morpheus.net/jaeger/core-multilib.git doesn't work anymore?10:25
jaegerwine is the reason I worked on multilib :)10:25
jaegerjue: it should, git-daemon is probably confused again. give me a min10:25
teK_holy cow.. this just feels wrong  :\10:25
jueindeed10:27
jaegerjue: oh... I changed the repo paths when romster started committing, but the git-daemon-export-ok files keep getting removed somehow, too10:27
jaegertry git://morpheus.net/crux-multilib/{core,opt,xorg,contrib}.git10:28
teK_so I guess I +1 jue's suggestion as I can untick the glibc-32 package anyway10:28
juejaeger: thx, works again now10:29
jaegerWell, I certainly don't want to FORCE multilib on people who don't want it. I *do* think that is the easiest way to go to support both configurations but CRUX isn't always about the easiest way :)10:31
jaegerjue: you were running multilib without actually using the 32-bit ports, right? Did you remove glibc-32 or leave it alone?10:32
juehmm, I'd strongly suggest to keep the work together, we are only a few people and have only limited time and resources10:33
jueyeah, right, but not sure about glibc-3210:33
juechecking now10:33
jueyeah, right, glibc-32 is not installed10:34
jaegerAnd you haven't had any problems with gcc building things without it, right?10:37
jueno issues, works fine10:39
jaegergood deal... so there's definitely some small overhead to be considered but for the most part it seems like it solves both use-cases10:39
jueyeah10:40
jaegerhttp://morpheus.net/gitweb/ also works if you just wanted to view ports10:42
teK_so what will be 32bit-ish after installation, if I leave glibc32 out?10:43
jaegernothing10:43
teK_great 8)10:43
jueit might be a good idea to outline the whole idea with a mail to crux-devel a bit, if there are no objections I can try do that the next days?10:43
jaegergcc will support building 32-bit executables if you install glibc-32 but you don't have to install any of them, of course :)10:43
jaegerjue: sounds good to me10:43
teK_so gcc and ld will support 32bit ootb ok10:44
teK_this multilib stuff always has been somewhat mysterious to me10:44
jaegerbinutils already does, technically :)10:44
jaegerIt's just not that useful without gcc and glibc doing so as well10:44
teK_so you're the one I have to nag the next time I try entering crosscompilation hell? :-)10:45
jaegerNot sure about that, heh10:45
teK_that's what I'd say, too10:45
teK_:p10:45
jaegerhehe10:49
jaegerThere's one thing I'm not sure about and that we should probably test10:49
jaegerLet's say, for example, that you install the multilib version and then you remove (or just elect NOT to install) glibc-3210:50
jaegerwe release a gcc update10:50
jaegerCan that be built without glibc-32 installed? I think it can but I'm not 100% sure10:50
jueI can try that later this evening, but have to run now10:53
jaegerNo problem10:53
jaegerTake care10:53
teK_I got my qemu-stuff fast again.10:53
teK_I could try, too10:53
teK_(I'd only have to rebuild gcc for that, right?)10:53
jaegeryeah, I just want to be sure it builds without glibc-32 installed10:54
jaegerEven if it doesn't work without glibc-32, that should be the only -32 port that needs to be installed10:54
teK_downloading the multilib iso right now10:55
jaegerI'll test it here, too11:01
jaeger/usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory11:12
jaegerthe answer is no11:12
jaegerI should have remembered that file11:12
teK_unknown filesystem type btrfs11:13
teK_oops11:13
mike_kteK_: diff for the suslog-ng: https://gist.github.com/2646056 Not sure how to simplify the config. I'd just strip it down to match syslog.conf files to add as a default. anyone installing syslog-ng will modify it heavily =).11:16
*** pitillo has quit IRC11:33
*** pitillo has joined #crux-devel11:38
*** pitillo has quit IRC11:48
*** pitillo has joined #crux-devel11:48
teK_removed glibc-32, rebuilding gcc13:46
teK_jaeger: I have to put core-multilib into prt-get.conf and before x86_64, right?13:51
jaegeryes13:53
jaegerIt will fail on stubs-32.h13:53
teK_yep14:03
teK_meouh14:04
teK_(the multilib-gcc failed on stubs-32)14:04
teK_testing core-x86_64/gcc14:06
teK_build succeded14:32
teK_trying to build glibc-32 now14:33
teK_failed. :p14:33
teK_so I guess one has to readd the glibc-32 from the iso and rebuild gcc-multilib afterwards14:34
*** mike_k has quit IRC14:38
jaegerseems that way14:41
teK_I yhink moving from pure to multilib and back is not the typical day-to-day operation so that's fine imh14:42
teK_o14:42
teK_reinstalled glbic-32, rebuilding gcc-multilib14:43
jaegerwell, if you only removed glibc-32 and readded it no recompilation of gcc would be needed14:45
jaegerif you wanted to rebuild glibc-32 you'd need to readd it first, of course14:45
teK_I recompiled gcc (from x86_64)14:48
*** frinnst_ has joined #crux-devel15:29
*** frinnst has quit IRC15:34
*** frinnst_ is now known as frinnst15:34
*** y4llow has joined #crux-devel15:36
*** y3llow has quit IRC15:39
*** y4llow is now known as y3llow15:39
*** rmull_ has joined #crux-devel15:42
*** rmull has quit IRC15:46
teK_so gcc-multilib works again16:03
*** frinnst has quit IRC16:09
*** frinnst has joined #crux-devel16:09
*** frinnst has joined #crux-devel16:09
*** tilman_ has joined #crux-devel16:16
*** tilman has quit IRC16:25
Romsteremulators-i686 uses 32bit on some ports. wont work in 64bit pure17:37
Romsteri know crux hates complexity but i got another idea... toolchain being lower than core repo but have a pure 64bit and multilib with glibc-32 build that the user than switch over too? and host the binary ports for easy getting started.17:44
Romstercould even have 32bit toolchain then too, that works with core as is.17:45
Romsterincorporate jaegers pkgutils arch option but extend it to also include i686 support?17:46
Romsteri for one would like to move contrib to 64bit it's a pain using 32bit contrib when i'm now on multilib.17:47
Romsteralso could you consider elfutils in core for crux 2.8 for LTO support, but don't add the flag to pkgmk.conf elfutils does get linked into a few ports if present, and lter removing elfutils (not that i would) will break the system.17:50
Romsterbbl work17:51
*** sepen has quit IRC20:29
*** mavrick61 has quit IRC21:41
*** mavrick61 has joined #crux-devel21:42
*** joe9 has quit IRC21:51

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!