IRC Logs for #crux-devel Thursday, 2012-07-12

*** mike_k has joined #crux-devel02:02
*** sepen has joined #crux-devel03:44
*** mavrick61 has quit IRC04:07
*** Romster has joined #crux-devel04:12
*** Romster has joined #crux-devel04:12
*** prologic has joined #crux-devel04:19
*** prologic has joined #crux-devel04:19
*** pedja has quit IRC05:57
juesepen: just answered your email, even though still not sure if I understood correct what you meant, sorry06:00
juewrt xorg: the update went totally smooth for me, I did a sysup and recompiled the nouveau driver, that's all :)06:01
juethe only port that breaks was xorg-xf86-input-synaptics because of it's new dependency mtdev06:02
jueRomster: thanks, good work :)06:03
jueRomster: one question, why do we need the patch for gccmakedep?06:04
Romsterthat's me using CC and CXX as ccache ...06:12
Romsterthat breaks that port otherwise.06:12
Romsteri should honestly submit that patch to freedisktop06:13
Romsterjue, ^06:13
sepenjue: now I see your mail, thanks for answering all my questions ;)06:14
sepenI'm a bit lost with multilib (for now)06:14
Romsteri haven't replied to that email yet, still thinking before i type.06:15
sepenjue: perhaps the confusion is due to my poor knowledge of English06:17
sepenbut what I wanted to know is what scenario forces me to use multilib instead of purelib, just to run wine? or old 32 binaries?06:19
Romsterwine for exe's that are 32bit, old bineries that are 32bit and some emulators that only work in 32bit currently. if none of these affect you you don't need 32bit at all.06:21
juesorry, have to run now, back in some hours06:22
sepenRomster: so +1 for purelib06:28
sepenwine can only run obsolete w32 binaries, right?06:30
Romsteri'm thinking the only way to satisfy both multilib and pure64 is to have 2 toolchain repos to choose one or the other06:31
sepenfrom our homepage '...The secondary focus is utilization of new Linux features and recent tools and libraries...'06:31
Romsterwine if compiled as 32bit will run only 32bit PE wine compiled as 64bit only will only run 64bit PE binaries06:32
sepenmultilib is not as KISS as I've in mind06:32
sepenI like the word 'multilib ready' and 'multilib enabled' proposed by slackware06:33
frinnstI agree. but there is a genuine need for multilib in some situations06:33
sepenwe used 'multilib ready' in our ML thread too06:33
sepenfrinnst: which ones?06:33
frinnstfor example, I would be unable to run a pure 64bit system here at work06:33
frinnstbecause some applications we work against are for some really stupid reason linked against 32bit libraries06:34
frinnstrather, the installer is 32bit06:34
sepencan't you compiled them again?06:34
frinnstclosed source06:34
sepenyeah sounds difficult in those scenarious06:34
sepenbut just I didn't want to lost our KISS principle06:35
frinnstif you work with proprietary applications it is often quite common06:35
sepenthen you could install crux-i686 for that ;D06:35
frinnstme neither. I would never put multilib on my systems at home06:35
frinnstyes but then I would be unable to run the 64bit *application* :)06:35
sepenfrinnst: from my POV, I'd never planned to re-install my i686 production boxes here at office06:36
frinnstbut having *one* a 32bit package on the install media is a good compromise, no?06:36
sepenyep for a up-to-date system06:36
frinnstits easily removeable.06:36
Romsterthe complexity of two toolchains as opposed to 1 with glibc-32 is easier to go with the later.06:36
sepenfrinnst: but in that case, for servers in production, for me it is not important to have the latest version of glibc06:37
frinnstRomster: you can start out with a pure 64bit system and just install the glibc-32 binaries/package and then build a multilib system, right?06:37
sepenI think so frinnst06:37
frinnstno need for a special toolchain (except for glibc-32)?06:37
sepen^^ deprecated06:38
sepenbut something like that could do the trick06:38
Romsteryeah with modifyed gcc binutils etc.06:38
sepenjust I don't like to force all people to use multilib06:38
frinnstso a multilib-overlay with gcc, binutils etc?06:38
Romstercould overlay the core-32 and rebuild perhaps06:39
frinnstsepen: that's not what we are doing, no?06:39
sepenfrinnst: no06:39
frinnstthe iso would contain a pure 64bit system + glibc-32-compat-whatever and a masked(.inactive) mulitlib.rsync-repo06:40
Romsterthe iso could contain or have two iso's one pure one multilib06:40
Romsterthis very issue is such a pain to make everyone happy06:41
frinnstyeah and I dont think we can - we just need to find the best compromise that works for everybody06:41
Romstermultilib  with only glibc-32 is the easiest todo. but some would fine that few MB more space out of todays 4GB disks to be dirty having 32bit support06:42
frinnst4gb disks?06:43
Romsteryou lot always talk about KISS principal one tool cahin does both06:43
Romsteroops i meant 4TB06:43
rmullIf now were the time to voice my opinion, as a user, I would prefer not to have any 32-bit stuff06:44
frinnstyeah same here - at home06:44
frinnstbut I could live with a glibc-32 package being installed - easily removeable06:44
Romsterso lets make two two iso's then multilib and pure official06:44
rmullWhat about unifying the install ISO, presenting a boot-time option to choose 32, 64, or multi? Too much work?06:45
sepeniirc, was called 'multilib ready'06:45
sepenwhich means that, purelib + glibc32, righ?06:45
sepenswitch to multilib: 1 - glibc+gcc, 2 - libs06:45
frinnstsepen: yeah, that's what I meant06:45
Romsteror a mixed iso that can do i686,x86_64,x86_64-miltilib and let the installer do the magic06:45
*** deus_ex has joined #crux-devel06:45
rmullRomster: Yes please :D06:45
Romsterrmull, is thinking like me -_-06:46
frinnsthehe, but then it wont fit on my 256mb usb-stick! :)06:46
Romsteri wasn't even reading what rmull typed as i typed that06:46
sepenfrinnst: if I'm right, our multilib ready will have gcc-ready-for-multilib, so just we need to use glibc32 in addition to06:46
Romsterthe problem is if glibc-32 is not present you can't rebuild the multilib gcc06:47
sepenhmm yeah06:47
Romsterhence why it's inclusion06:47
frinnstwhat I would prefer is this: a pure 64bit iso with two new ports/packages: glibc-32 and a multilib-repo port06:48
sepenI think we talked about that in ML06:48
rmull64-bit gcc can build a glibc-32, right?06:48
sepenmultilib-repo --> lib32 repo06:48
sepenor I think jue said that06:48
Romsterif we must have a single 32bit repo call it compat3206:49
frinnstif you want 32bit support you would activate the multilib repo and use the overlay gcc-binutils-glibc whatever to produce a fully multilib environment06:49
sepenname doesn't matter, compat32, etc.06:49
frinnstif that's doable etc06:49
Romsterthat could be doable.06:49
sepenhmmm what are the more visible differences between gcc-pure and gcc-multilib?06:49
sepensize of executables?06:49
Romsterpure and rebuild option for multilib for those that need it.06:50
frinnstRomster: yeah06:50
sepenor /usr/include/<both-targets> ??06:50
sepenoops I did not ask that06:54
* sepen hides under the table06:54
frinnstyes you did! I have it on record!06:55
sepenhas someone a running multilib?06:55
sepenobjdump -x06:55
sepenthat show any interesting for gcc binaries?06:55
Romsteron what gcc?06:56
sepenjust wanted to compare both gcc, the one for purelib and the one in multilib06:56
Romsterobjdump -x /usr/bin/gcc |wgetpaste -s dpaste06:56
RomsterYour paste can be seen here:
sepenarchitecture: i386:x86-64,06:57
sepenwtf? I've the same here and I'm running purelib06:58
* Romster has a big cheesy grin06:58
sepenI'm running purelib (--disable-multilib) and objdump shows both archs? what I'm doing wrong?07:01
horrorStruckcan't the installer handle this multilib choice? it's doing much more complicated things, no?07:50
jaegerThe installer could be made to handle both easily. That's not the problem. The problem is manpower to maintain both. We're a tiny team, we don't really have the power to maintain both as well as i686 and keep them high-quality.08:02
jaegermultilib with only the glibc-32 port installed is the best compromise so far08:03
jaegerRegarding the comment earlier about removing glibc-32, you have a somewhat broken system at that point as gcc can't be rebuilt08:03
frinnsthm :(08:08
jaegersepen: want to push your 2.7-nosquashfs changes to my temporary iso repo at
sepensure, I could prepare a patch before08:22
sependid you see the differences for init that I pasted to you the other day?08:23
sepenhmm our gitweb doesn't have the git command info08:34
sepenwhich command I should use to clone a repo?08:35
sepengit@, ssh://, ...08:35
jaegerif you just want to clone, git://
jaegerif you want to push, send me a pubkey and it'll be
*** joe9 has joined #crux-devel08:36
sepennah, for now I'm going to clone it08:44
sepenif you're agree I prefer to send you a patch08:44
sepenjaeger: 'warning: remote HEAD refers to nonexistent ref, unable to checkout' you noticed that?08:45
jaegeryeah. there's no master branch, just 2.7-nosquashfs08:46
jaegerIt's only a temp repo anyway08:46
jaegerthanks, I'll give it a look/try as soon as I have time09:48
sepennote that there are many if [ $DEBUG ... sections09:50
sepenalso I've in mind to improve the init script, some abstractions, refactorization, etc09:51
sepenand also the section where some superfluous files are deleted can be reviewed too, so since Per days it changed a lot09:52
sepenthere are some binaries that ATM don't exists09:53
sepenbit a bit, there is no hurry for that09:53
*** c0x has joined #crux-devel10:07
*** acrux has quit IRC10:18
*** acrux has joined #crux-devel10:20
sepengoing back to home, see ya'10:55
*** sepen has quit IRC10:55
juethat's exactly my opinion -> 15:03 < jaeger> multilib with only the glibc-32 port installed is the best compromise so far10:56
juewell, I sometimes got the impression that I'm not able to describe in clear english words what 'multilib ready' means11:00
juejaeger: help needed probably ;)11:00
horrorStrucknothing beats a drawing :D11:01
juetime will tell, at the moment I'm more interested to get the xorg thing done :)11:03
juehorrorStruck: a nice drawing to clearify the situation is of course welcome11:07
horrorStrucki still dont gt it myself so not a good idea :D11:08
*** acrux has quit IRC11:09
horrorStruckjue will you enable graphite in 3.0 just OOC?11:09
horrorStruckit means 3 core ports more11:10
juejaeger has done it already for gcc 4.7.1, IIRC11:11
horrorStruckah OK nice11:12
*** acrux has joined #crux-devel11:12
*** acrux has joined #crux-devel11:12
*** acrux has quit IRC11:37
*** acrux has joined #crux-devel11:38
*** acrux has joined #crux-devel11:38
*** acrux has quit IRC11:46
*** acrux has joined #crux-devel11:48
*** acrux has joined #crux-devel11:48
*** c0x has quit IRC12:02
*** sepen has joined #crux-devel13:23
jaegerIt's only 2 ports as far as I can tell13:37
jaeger2 extras, at least. cloog and ppl13:38
frinnstjue: btw your btrfs snapshot works great, if you missed my previous comment13:38
jaegerand --with-cloog-backend=isl or whatever13:38
jaegerjue: to me, "multilib ready" indicates that the system can build and execute both 32- and 64-bit executables out of the box13:48
jaeger"ready" means now, not "with additional configuration"13:49
juefrinnst: thx for testing, will commit it tomorrow13:58
juejaeger: yeah, that is my understanding as well14:00
juebut we do not ship a complete mutlilib system with all the additional compat libraries14:02
jaegerAye, only the ones required to build more14:03
jaegerin this case only to build gcc14:03
juebut seems that not everyone is happy with a gcc that is _able_ to produce 32-bit stuff14:03
jaegerYeah, and there will never be 100% consensus on that14:04
juethat might be against a strict pure philosophy ;)14:04
juebut well, I'm pretty sure that we will find the right solution14:06
juejaeger: btw, you've read my comment from today wrt xorg?14:07
jaegerI saw your comment that your upgrade went smoothly if that's what you mean14:10
jaegerAre you wanting to do an xorg upgrade before a new release?14:12
jueyes, I don't see a real reason to wait until the new release14:14
jaegerI'll run a test of it on my laptop now but I don't really expect problems14:16
jueif we do it now, we have less work within the release process14:16
juegreat, so we have another test :)14:17
jueI'd suggest to let something like 'CRUX Xorg Team' be the maintainer of everything in our xorg repo14:19
jaegerthat's fine with me14:20
juelet's wait until your test has finished and decide then how to proceed14:23
sepenjue: I'm not against multilib14:26
sepenbut I think that soon or later we'll switch to purelib, when 32bits precompiled binaries for linux dissapeared14:26
jaegerIf that ever happens it'll be much later than sooner14:27
sepenif we were a team >100 purelib would be easy, but not for a small team14:27
sepenmy final decission is multilib + glibc3214:28
juesepen: TBH, I don't see the problem at all, if we do it as suggested to main difference is one additional configure option14:29
sepenyep, but hard to maintain both branches for now14:29
sepenthats for what I decided multilib to have consensous14:29
sepenjust I was discussion that I can't see the point to migrate a production i686 box (server at office) to x86_64 and try to run old pre-compiled binaries for i686, in this case I prefer to keep the same OS with only security updates14:31
sepenpersonally I have some crux i686 boxes at office, running some apps and some old precompiled binaries, and only planned to upgrade them to 2.7.2 whenever be available14:33
juesepen: sounds like a plan :)14:34
juebut if you have to setup a new server the scenario might be different, right?14:36
sepenjue: obviously14:36
sepenjust I discussed the point about i686 to x86_64 migration, but not related to multilib14:37
sepenI know my english sucks, so sorry if I can't explain things better :P14:38
juepersonally I don't see any use for a multilib system, but I see that there are use-cases for it14:38
sepenuse case: we're a small team ;)14:39
jueyeah, indeed, that's a big argument for it14:39
sepenjue: ATM on crux-arm we're maintaining 2 ABIs (softfp, hardfp) and I know how hard is to maintain14:39
sepenit's a similar scenario, not exactly but similar14:40
jaegersome of the ports in the xorg updates repo should be removed14:41
juejaeger: cause they are no longer needed?14:42
jaegerxorg-input-{acecad,aiptek} xorg-video-{apm,chips,i740,rendition,s3,s3virge,sisusb,suncg14,sunleo,suntcx,tseng,xgi.xgixp}14:42
jaegerprobably also xorg-video-{sunffb,suncg6} since we don't support the sparc architecture14:43
jaegerthe first set I mentioned is not including in 7.714:43
jaegernot included, I mean14:43
jaegerremoved due to no maintaners14:43
jaeger - "Removed in this Release" section14:44
sepenheh nice! xorg cleanup14:44
jueI'm all for removing that old, unused crap ;)14:44
jaegerI missed suncg3 in there but really sun* should go, I think14:44
jaegerok, running my sysup test now14:46
jaegershouldn't take too long14:48
frinnstjaeger: that sounds like the ones that fail for x86_6414:58
jaegerbuilt fine, checking linking and if anything works :)15:12
jaegerlots of noise about libxcb-aux.la15:23
jaegerso not a smooth sysup15:23
jaegerwell, the xorg build itself was smooth... rebuilding xfce4 packages is not15:23
*** mike_k has quit IRC15:25
jaegerhrmm... I wonder if it'd be simple to make a tool like revdep but for .la deps that are now gone15:25
jaegerok, X seems to be fixed and working now15:48
jaegerncurses and the mesa-demos package have a conflict for /usr/bin/clear15:50
jaegerotherwise it seems fine here15:59
*** acrux has quit IRC16:33
*** acrux has joined #crux-devel16:35
*** acrux has joined #crux-devel16:35
*** acrux_ has joined #crux-devel16:56
*** acrux has quit IRC16:58
*** acrux_ has quit IRC19:12
*** acrux has joined #crux-devel19:14
*** acrux has joined #crux-devel19:14
*** sepen has quit IRC20:33
*** acrux_ has joined #crux-devel20:39
*** acrux has quit IRC20:40
*** mavrick61 has joined #crux-devel21:36

Generated by 2.11.0 by Marius Gedminas - find it at!