IRC Logs for #crux-devel Sunday, 2012-05-13

*** acrux has quit IRC01:41
*** frinnst has quit IRC01:41
*** deus_ex has quit IRC01:41
*** jaeger has quit IRC01:41
*** teK_ has quit IRC01:41
*** hawksbill has quit IRC01:41
*** prologic has quit IRC01:41
*** tilman has quit IRC01:41
*** acrux|G4 has quit IRC01:41
*** jue has quit IRC01:41
*** mavrick61 has quit IRC01:41
*** c0x has quit IRC01:41
*** joe9 has quit IRC01:41
*** rmull has quit IRC01:41
*** pt_st1 has quit IRC01:41
*** Romster has quit IRC01:41
*** mike_k_ has joined #crux-devel03:11
*** mavrick61 has joined #crux-devel03:11
*** pt_st1 has joined #crux-devel03:11
*** tilman has joined #crux-devel03:11
*** acrux|G4 has joined #crux-devel03:11
*** acrux has joined #crux-devel03:11
*** hawksbill has joined #crux-devel03:11
*** c0x has joined #crux-devel03:11
*** joe9 has joined #crux-devel03:11
*** frinnst has joined #crux-devel03:11
*** rmull has joined #crux-devel03:11
*** deus_ex has joined #crux-devel03:11
*** prologic has joined #crux-devel03:11
*** jue has joined #crux-devel03:11
*** teK_ has joined #crux-devel03:11
*** jaeger has joined #crux-devel03:11
*** Romster has joined #crux-devel03:11
Romsteri've been thinking it would possibly less effort to maintain the 3 flavours if there was setup more like arch is with the 3 flavours merged in the same Pkgfile so they always track the same versions. but that's probably outside of crux's kiss principal.03:17
juegood morning04:27
juefrinnst: thanks04:28
jueRomster: sure, there are several possibilities to solve this from a technical point of view04:30
juebut in the end you have to test each port on every arch, at least if you want to be serious04:32
Romstertrue and that requires a dedicated maintainer of each arch.04:36
Romstermorning too jue.04:36
Romsteri for one would probably like to drop most of my 32bit contrib ports for 64bit ones but i haven't done so as that would hurt others.04:37
jueyeah, everything is more or less messy currently04:39
Romstersadly.04:40
jueour official arch is 32-bit but most, perhaps all but me, are working with a 64-bit CRUX04:41
juefrinnst is testing the newest gcc/glibc but with a different toolchain than jaeger ;)04:42
Romsteri saw that glibc git and gcc 4.7.004:43
jueat all not very effective04:43
Romsteri wouldn't mind knowing what ports are broken if any are mine for any possible fixing.04:43
Romsteri like the option --enable-obsolete-rpc we should wait for that glibc to be released.04:44
Romsterand use either gcc 4.6.3 or 4.7.1 if it's out by then.04:45
frinnstlots of stuff broke with latest glibc04:45
Romsterwe really need a meeting to discuss everything with all the devs04:45
Romsterfrinnst, even with --enable-obsolete-rpc ?04:45
juedon't get me wrong, I really like all of this activities, it's great to see that people are working hard to proceed with CRUX04:45
frinnstthey have messed around with the headers04:45
Romsterhmm damn...04:46
Romstertesting is always welcome, in my opinion but i know we should have something that does not break too many ports.04:46
Romsterand must be stable.04:46
frinnstnot the rpc ones, but other like mathinline.h04:46
Romsterit's a big catch up game for ports to catch up with glibc changes.04:47
Romsterhow broken is broken? some define for old behavior in mathinline.h and such? or if it's simply fix in ports to fix that. like later gcc had a new header that some ports needed patching.04:48
frinnsti'm sure it will be fixed04:48
Romsterhmm i'm wondering if i'm being too pushy i'm only a opt/core port maintainer, i really don't know how many levels of developers in crux there is. if i'm out of place/authority please let me know and i'l but out of that area.04:51
Romsteri realize some devs/users barely tolerate my behavior.04:52
Romstercould we have a dev private, not for users. proposed test version of new tool chain rolled iso with core opt, possabily my xorg fork thats way ahead of offical xorg for us only to test and comment. as currently we are all testing different things so fragmentedly04:55
jueRomster: as of http://crux.nu/Main/About we have core and opt maintainer, that's all04:55
Romsterah k that's clear. but very few of us.04:56
jueit's not only xorg, all ports of tilman are bit outdated currently04:56
Romsteri've bumped some in opt and contrib as well  http://romster.dyndns.org/linux/ports/crux/version-updates/ but seriously is too much for me to do alone. then there is that recent crux-list ML post "stabilized ports repo"04:58
Romsterand horrorstrucks attempt. https://github.com/horrorStruck/community-patches-queue04:58
Romstersome of sepens are a bit stale too.04:58
Romsterbut sepen is quite time restrained so to be expected and he has all that xfce too.04:59
jueI don't see a big problem with that, we don't need the latest versions of everything, but sometimes we should know what will happen04:59
Romsteri pretty much only bump stuff i'm using or others tell me about. if they care to test what i've done or been sent to me.05:00
Romsternot to undermine your awesome work but to try and push better quality less stale.05:00
Romstercore is stable and always updated sensibly without breaking stuff. the rest is not so often.05:01
Romsteri haven't updated the patch diffs in patches/ for a short while i must fix that.05:02
Romsterdiff between official git and what i've played on top, i don't clam to have done every patch myself but the majority i have done.05:02
jueRomster: well, having a bit outdated ports for some time isn't the main problem IMO, I wouldn't spend much work to create other/updated repos for that05:05
juebut the important part here is 'for some time'05:05
jueand currently I have the worry that we are on the way to lose a important maintainer05:07
Romsteri was thinking that i'm in opt contrib i've done so much work to xorg and stuff, that i could be a aliasion for users to submit patches/fixes/version bumps that they need for something to work in there private collection. than extra duplicated ports. for later inclusion into official repositories. can be cherry picked or what have you to your own decisions/liking's.05:07
frinnstwhile i approve of a community method of just bumping ports, it may lead to problems when it comes to involve bigger changes in a port05:09
frinnsteveryone has quirks in their ports. some abuse sed while others abuse patch :)05:11
jueRomster: yeah, that's all nice and great, but in the end we are all volunteers and working with CRUX should be fun. And sometimes it's a bit annoying if people are takeing all of this too serious ;)05:11
Romsteri'm worried about losing important maintainer(s) and that CRUX might fall apart. Everything I've been doing is been trying to help. but I think I've done some damage to xorg maintainer :( and i am sorry for pissing him off. I was accepted into opt reluctantly because of my behavior. I'm not happy with my past, I've been trying to turn a new leaf in my life. I think jue and jaeger can at least talk tome and not be all, "oh great not him again, l05:11
Romsterike". I don't know how much is my damage and how much is other factors IRL no time etc.05:11
Romsterjue, I do all this stuff for CRUX because I enjoy doing this. I enjoy the community. I'm scared it's gong to fall apart I'm trying to help. But my trying to help might be hurting more.05:13
frinnsti dont see how maintaining another version of a repo would be considered "offensive"05:13
frinnstand im not really worried of crux falling apart.05:13
RomsterI would like nothing more than to merge the good pats of it back into official crux. like jaeger provides the iso out of his own willingness, I've been port bumping testing using.05:14
Romsterfrinnst, i'm more thinking of me constantly harassing said xorg maintainer.05:15
frinnsthehehe05:15
RomsterI do not want to bug him anymore than I ave so I'm not highlighting him.05:15
jue:)05:16
Romsters/I ave/I have05:16
Romsterif you tell me to do or not do something I'll try to do that to help.05:16
RomsterI know latest and greatest is not the major priority. stability is more important.05:16
Romsteranyways this discussion should be about me all the time so what can we all do now to help crux in a group.05:17
Romstershouldn't*05:17
Romstersorry my typing..05:17
frinnstI only maintain a handful of ports in opt. I could maintain a lot more if needed.05:18
frinnstafk05:19
jueIMO the most important point currently is the arch decision05:20
jueif we switch the offical arch to x86_64, it's a big break after more that 10 years of CRUX05:23
jues/that/than/05:25
frinnst(.. not yet afk) perhaps throw out the question on the mailinglist?05:25
RomsterI was about to suggest what do the users want.05:26
frinnstI have a vacation coming up in a few weeks.. looking forward to play around with it then05:27
jueRomster: what/who is _the_ user?05:27
jueI thing it's out of question that we must switch to x86_6405:28
jueand the whole pure/multilib question is in the end a pure technical thing05:29
teK_who is still on i686in here?05:29
Romsterour user base of crux users that use crux.05:30
juethe _user_ wouldn't mind if our toolchain is able to produce 32-bit stuff, if he isn't forced to do that05:30
jueteK_: me05:30
Romsteri have 1 box on i686 but not for much longer it has 64bit capable cpu.05:31
jueteK_: sorry, not my primary box05:31
jueonly my old laptop05:31
Romsterif the majority of users are on 64bit woulnd't that be the best choice to move too?05:31
juebut I'm using our 32-bit CRUX everywhere05:32
teK_we will move..05:32
jueRomster: as I said above, the move is out of question IMO05:32
Romsterok so that leaves the split unofficial pure frinnest and multilib jaeger.  and official crux i686 as we are currently.05:33
juehmm?05:34
teK_I think we shall go the "jaeger-route" with glibc32 being non-mandatory for running CRUX05:35
Romsterthat perhaps jaeger and frinnst could come to some merge if they both agree. and i686 is kept offical and x86_64/x86_64-multilib is unofficial but anyone can use it if they care to.05:35
teK_64bit should be the new default.05:35
teK_with i686 still being supported05:35
jueRomster: no, one and only one x86_6405:35
Romsterjue is opposed to that change in his opinion. and jue is wise.05:35
teK_the differences between them are not that grave05:36
Romsterone and only x86_64 with multilib toolchian without glibc-32 not installed but can be for 32bit support05:36
Romster?05:36
Romsterbut still not being official as there are many x86 users still.05:36
jueRomster: to be clear, I'd vote for the multilib version05:36
jueRomster: official with a new CRUX version, of course05:37
juethat should be probably CRUX 3.0 than05:38
Romstersorry i'm confused, you said it's out of the question to switch to x86_64 but then you say your up for the multilib version for probably CRUX 3.005:40
juewe might lose some i686-only user with such a step, but CRUX will be more up-to-date05:40
jueno, I said that the switch to x86_64 is out of question05:41
Romsterif we have such a large userbase we should be keeping i686 around for a period of time much like you rolled your own i586 for some time.05:41
teK_I tried the jaeger iso with and without glibc32 and it worked hassle-free05:41
Romsterah switch to multlib right i get it now.05:41
Romsterthere is a hitch though teK_ if you try to recompile gcc it'll complain that glibc-32 is missing.05:42
Romsterif that's a big thing or not i don't know.05:42
teK_you simply have to pick the right gcc port05:43
Romstergcc verison bump, should one happen will involve those that don't have glibc-32 installed to install it update gcc then remove glibc-32 again or leave it installed.05:43
teK_which is a nobrainer IF you dare converting from/to multilib..05:43
teK_http://dpaste.com/747499/05:43
Romsterok that suggests we need a pure 64bit toolchain and a multilib one. and user picks what one they want to use.05:44
juewhy?05:44
teK_I don't know if other ports have to be switched, too05:44
Romsterwhy not just leave glibc-32 as the only 32bit port in the system the added space taken up is minimal. and it solves that breakage issue.05:44
teK_I don't care for 32 bit05:45
teK_ran linux for some years in pure 64 bit mode05:45
teK_but it won't be too much of a tragedy to have glibc32 included  I guess05:45
jueteK_: we should think a bit more about CRUX at all in that point05:46
jueand having one tool-cahin is always better than two IMO05:46
Romsteror scrap multilib and jaeger and I keep working on that as unofficial? I do not mind if that is how it goes.05:46
jueRomster: that's exactly what we should avoid ;)05:47
Romstersince only a minority will want multilib or need it...05:47
Romsterisn't it the saying majority wins?05:47
jueit's not a minority, it's me, jaeger any you05:48
Romsternogagplz and all his emulators i mgiht get more into emulation myself too. i was into it many years ago. if i did more gaming i'd be less bugging you guys :)05:49
jueI don't need multilib, but I accept that jaeger needs it, and if I'm not forced to use -32 stuff beyond glibc-32 I don't see a problem at all05:50
Romsterstill not many compared to how many using pure 64bit, why not submit to mailing list and have a vote where users add there name to the respected choice? there is voting sites for such a task.05:50
Romsteryes that's it only glibc-32 if tek can handle that too.05:51
Romsterthe rest is in it's own multilib git tree.05:51
Romsterdoes not make binaries any bigger for 64bit afaik.05:51
juehonestly, that's nothing to decide in the mailing list05:52
teK_jue: that's my point of view, too.05:52
jueteK_: great :)05:52
Romsterdoes anyone have a rough estimate of how many re using what flavours of crux currently? approximation. due to number of unique port updating off rsync?05:53
Romsters/re/are05:53
Romsterbut then that would probably say in this order i686 x86_64 and last x86_64-multilib05:54
Romsteranyhow i'll stop bugging you guys now :)05:54
*** joe9 has quit IRC05:58
juebbl06:04
*** joe9 has joined #crux-devel07:00
*** acrux has quit IRC07:18
*** acrux|G4 has quit IRC07:19
*** acrux has joined #crux-devel07:20
*** acrux|G4 has joined #crux-devel07:20
*** tilman has quit IRC09:41
*** tilman has joined #crux-devel09:42
*** acrux|G4 has quit IRC09:51
*** acrux has quit IRC09:51
*** acrux|G4 has joined #crux-devel09:53
*** acrux|G4 has joined #crux-devel09:53
*** acrux has joined #crux-devel09:53
jaeger05:00 < Romster> i pretty much only bump stuff i'm using or others tell me about. if they care to test what i've done or been sent to me.10:14
jaegeroops, sorry for that paste, accidentally hit my mouse button10:15
jaegerI was asleep during the large discussion you guys had about toolchains and the next release, etc.10:16
jaegerThere's one important thing I want to point out, though, concerning the idea of running multilib with only glibc-32 installed and no other -32 ports:10:16
jaegerYou cannot rebuild gcc (multilib) or glibc-32 without glibc-32 installed10:16
jaegerer, sorry, I meant to say with glibc-32 removed in the above10:17
jaegerif you remove glibc-32 the system behaves fine unless you want to rebuild glibc-32 or rebuild the multilib gcc10:17
jaegerOn a side note I have to say I've been rather surprised over the course of my CRUX usage how many people are anti-multilib. :)10:18
jaegerEveryone is entitled to their opinion, I wouldn't ever try to change that. All the same it has been a surprise.10:18
jaegerSomething I'd like to test at some point is this: install pure64, build firefox 5 times or so. install multilib, build firefox the same number of times. compare build times and see if there's really a tangible difference10:24
*** pt_st1 has quit IRC10:32
*** pt_st1 has joined #crux-devel10:34
frinnstwell my problem with multilib has nothing to do with speed, harddisk-usage or anything like that. I just dislike having binaries for an obsolete platform on my system :)10:39
frinnstI think one of the major things that attract users to crux is the cleanliness. not having 152134 libraries for each package like other distros like debian, fedora etc10:40
jaegerEveryone has their reasons, of course11:00
*** joe9 has quit IRC11:07
juere12:25
juefrinnst: does that mean that you are finally against the multilib tool-chain idea?12:25
*** pt_st1 has quit IRC12:43
teK_btw.. anone got an idea why my Xorg would literally swallow mousclicks?12:44
teK_+e12:44
teK_i.e. clicking on a link in Chromium or FF will not open it12:44
*** pt_st1 has joined #crux-devel12:47
jaegerno idea here, haven't seen that one12:48
teK_this *really* sucks12:49
jaeger:(12:49
teK_1st try will be to use nv instead of nnvidia12:49
teK_+ I have absolutely no idea how to debug this12:49
jaegerIf you haven't already, try rebuilding the input driver12:49
teK_I haven't12:50
jaegerIs it only chromium or firefox or all apps? or all gtk apps?12:50
teK_both. I have no gtk apps installed12:51
teK_this is: browser or ncursers or cli12:51
teK_=)12:51
jaegerdon't firefox and chromium both use gtk?12:54
juefrom time to time I have a probably related problem with firefox, the scroll- and menubar and doesn't work with the mouse, a reinit of my windomanger helps12:54
teK_well.. besides ff and chromium..12:54
teK_well fluxbox sometimes forgets to render the window around Terminal..12:55
teK_a restart helps there, also12:55
jaegerweird... sounds like something more than gtk, then12:57
teK_rebuilt evdev12:58
teK_did not help13:01
teK_next try: downgrade fluxbox13:01
teK_leaving the button "clicked" for a longer time seems to help13:03
jaegervery odd13:04
frinnstjue: no.. It's probably the best way forward. but we need to make it easy to not use it and run a pure 64bit system13:40
rmullteK_: Have you tried a different mouse?14:10
teK_no but I could14:11
teK_- tmorrow14:11
rmullmaybe the mouse button is on the blink14:12
teK_no problem with windows14:12
teK_same hw14:12
rmullah14:13
*** joe9 has joined #crux-devel14:32
*** mike_k_ has quit IRC14:59
*** mavrick61 has quit IRC21:50
*** mavrick61 has joined #crux-devel21:52

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