IRC Logs for #crux-devel Friday, 2013-02-01

RomsterteK_, when you get a chance to add an alias for # Maintainer: CRUX compat-32 Team, compat-32-ports at crux dot nu00:11
Romsterto mail00:11
*** horrorStruck has joined #crux-devel00:16
*** horrorStruck has quit IRC00:20
*** sepen has joined #crux-devel01:04
teK_Romster: sure, who are the recipients?01:07
Romsteras far as i know jaeger and myself01:08
Romsternogagplz would like to join compat-32 but i need consensus if he can or not yet from the others.01:16
Romsternogagplz and I are maintaining the emulator ports. mostly nogagplz though. and nogagplz did help me out with wine in the past.01:17
Romsteri asked him and he is not opposed to being included.01:17
sepenall contrib x32 ports will be moved to compat-32 too?01:30
sepenor compat-32 is part of contrib?01:31
Romstercompat-32 is all 32bit only ports for crux 3.001:33
Romsterfor anything that needs 32bit support.01:33
sepenI prefer to have a contrib-32 instead of mix ports01:34
sepenRomster: yep, compat-32 is to have 32b support, not to host emulators/games IMHO01:34
Romsterso why didn't you say anything when all this was being decided? guess you were busy.01:34
Romsterno those stay in emulators repo01:34
sepenwhere? on irc?01:35
Romsterbut the more common ports for dependencies can be in compat-3201:35
Romsteryes on irc.01:35
sepenirs is the official channel now? not ML?01:35
Romstercrux/3.0 contrib is now 64bit.01:35
Romsterboth are..01:36
Romsterbut seems most discussion happens in irc.01:36
Romsterbefore it's put on the ML.01:36
sepennever was the official way01:36
Romsteryou've been around here long enough to know what goes on.01:36
Romsterwhich way was?01:36
sepenML and FS01:36
Romsterhave you not ever seen meetings held on irc before/01:37
Romsteri have01:37
sepenI don't have too much time to be sitting in front of my pc to connect irc01:37
Romsterbut the ones we had wern't really planned they just sort of happened.01:37
sepennah, this is another discussion01:37
sepen+1 Romster01:38
Romsterdid't you say you now have internet at home so you'll be on more often now? Or am i confused again.01:38
juegood morning01:39
Romsteri should ask that question on the ML for contributing to compat-32 if it's really required to do so.01:39
Romstermorning jue01:39
sepenI'll never use compat-32 if I can use mpup to pickup individual ports, it's fine for me Romster, don't worry01:39
sepengm jue01:39
sepenjust was my POV01:40
juesepen: what do you mean with 'all contrib x32'01:40
Romstercompat-32 is just core opt xorg contrib 32bit equivalents.01:40
sepenjue: I'm a bit confussed with new changes, and seems that I should read all the irc backlogs (not hosted now by morpheus)01:41
juedon't think so, but what's your problem?01:41
sepenthere is no problem at all01:42
juelooks like you are a bit confused about the compat-32 repo?01:42
sepenjust I didn't have the time to connect irc the past days01:42
juewell, I don't see that you've missed anything important01:43
jueit's still as we have defined it in the two or three posts to the ML01:43
sepenhmm but there are one thing I want to know more, about 'CRUX compat-32 Team'01:45
sepen should mention this Team?01:46
Romstertilman got emailed about a 32bit port so all comapt-32 ports got there own group email for those that maintain the 3bit compat-32 ports.01:46
Romstersepen, it just got added like 20 minutes ago.01:46
sepenI see Romster's changeset01:46
Romstertilman got mailed about a port he doesn't even maintain.01:47
sepenRomster: I saw your changeset, but can't find a place in our about page saying something about this new team01:47
juesepen: it's more or less the same as with xorg, we switched form one person to a team01:47
sepenshould be have it?01:47
sepenjue: +1, I liked that01:48
Romsterhmm yeah xorg group isn't listed either.01:48
sepenbut xorg teams are core/opt maintainers, right?01:48
Romsterxorg and compat-32 probably should be added to about page.01:48
juesepen: don't get me wrong, but do you really understand what the purpose of the compat-32 repo is?01:48
Romsteri think so01:48
sepenI don't think so if System Team and opt Maintainers only take part01:49
sepenthat was my point01:49
Romsterwell not everyone in opt is in xorg. but i htink all core members are. then again i don't think frinnst  is in xorg and he is in core.01:49
sepenI said: System Team + opt maintainers01:50
juesorry, I don't get it what we really discussing here ...01:51
sepen10:14 < Romster> nogagplz would like to join compat-32 but i need consensus01:51
sepenI said no with our current model01:51
sepenbut just only my pov01:52
sepenand thats for what I was wondering about the need of another contrib-32 (or with another name) repo01:53
Romsteri would not recommend anyone that i didn't think could handle the task01:54
juewhat's the purpose of a contrib-32 repo?01:54
sepenthis time is nogagplz but just we recently switched to x86_64, more people will appear with the same thing01:54
sepenjue: let contrib maintainers to have a 32 based repo separated from contrib?01:55
juesorry, but what's a 32 based repo?01:55
sepensorry I'll try to explain my case01:56
sepenI'm reviewing my contrib ports, and I have some games that are only 32b, so should I remove those ports?01:57
jueyou mean binary ports?01:57
sepenwell, binary ports is not a problem if all deps are in compat-32, but if not?01:58
juethat's a good reason for you to join the compat-32 team, I'd say ;)01:59
sepenyep for me01:59
sepenbut I'm trying to imagine what would happen with other contrib guys02:00
jueTBH, I don't really care about contrib, but having ports with an -32 extension in contrib seems to be one possibility02:03
Romsteri thought we are going to keep anything that requires 32bits in compat-3202:03
Romsterwell the dependencies at least.02:04
Romsteras opt/wine is still there but needs compat-3202:04
jueif a opt/core member is going to maintain the port in question, sure02:04
Romstercan not see why contrib/opt other repos have 32bit ports but keeping compat-32 for the dependencies... this area is really gray.02:05
juefor me it's the same like opt, opt in not a selection of ports, but the repo for the opt maintainers, same with compat-3202:06
sepen+1 jue02:06
sepenjue: so where is the repo for non for opt maintainers? thats my point02:07
juewell, as I said above, that's something the contrib team/group has to decide02:08
Romsterok so my efforts to keep the emulators port low on deps by moving common stuff to compat-32 means i'll have to keep maintaining that side of emulators which is fine. just thought it be best if nogagplz was also a compat-32 maintainer as he also is a wine user too.02:09
Romsteri'm not fussed just thought it's meant to be a calibration than me whoring ports :D02:10
*** mike_k has quit IRC02:11
juewell, if nogagplz official applies for becoming an opt maintainer and he got accepted, I don't see a problem at all02:11
sepenjoin nogagplz to compat-32 means to have a new opt maintainer and I vote no (for now)02:12
Romsteri can ask him to apply if he wants to.02:12
Romsterthough shouldn't he be a contrib maintainer first before even being accepted into opt?02:13
Romsterand for existing contrib maintainers they'll have to converse with the compat-32 team for dependencies to there 32bit only contrib ports.02:14
*** mike_k has joined #crux-devel02:14
sepento be a contrib maintainer is not a requeriment02:15
sepenbut to know his previous work02:15
juewhat's the problem with having a port like foo-32 in contrib?02:15
sepenit's ok to me02:16
sepenis like the separate contrib-32 I said but in contrib.git02:16
sepenand that let people from contrib to continue work fine02:16
sepenofftopic: where is the irc log now??02:16
sepenRomster pasted to me the link somedays ago02:17
sepenah ok02:17
sepenshould I fix our COmunninty page?02:17
sepenor it is a temp place?02:17
jueyeah, please do02:17
sepenjue: did you see I updated the Development page?02:23
sepenand the contrib-howto too02:23
Romsterso compat-32 is really for opt/core/xorg only related ports and those that are related to contrib belong in contrib?02:23
sepenwe have some old links pointing to 2.7 :P02:23
sepenRomster: +102:23
Romsterthat means i have some stuff in compat-32 that can be moved to contrib if that is the case.02:23
Romsterwhich also means nogagplz will only need contrib access. to put common ports in there.02:23
*** horrorStruck has joined #crux-devel04:27
*** pitillo has quit IRC04:44
*** pitillo has joined #crux-devel04:48
*** pitillo has quit IRC05:07
*** pitillo has joined #crux-devel05:09
*** pitillo has quit IRC05:28
*** pitillo has joined #crux-devel05:30
*** pitillo has quit IRC05:33
*** pitillo has joined #crux-devel05:38
*** pitillo has quit IRC05:57
*** pitillo has joined #crux-devel06:05
frinnstooh, intel 2.21.006:08
frinnstgonna give it a spin06:08
frinnst* Stable 830gm/845g support, at last!06:08
frinnsttypical, when i no longer use one of those gpus :(06:08
*** pitillo has quit IRC06:10
*** pitillo has joined #crux-devel06:11
*** pitillo has quit IRC06:14
juejaeger: no sucess with bdb, I've tried ruby-bdb from too06:15
juejaeger: guess the compat-32 maintainer lines problem is already solved?06:17
juejaeger: what is your suggestion wrt nvidia?06:18
*** pitillo has joined #crux-devel06:19
jaegerI haven't messed with the maintainer lines yet06:22
*** c0x` has quit IRC06:22
jaegertilman's still listed in a few of them06:23
jaegerDo we want to make them all a compat-32 alias or something?06:23
juewell, Romster did that already for a couple of ports06:24
Romstercouple i did the lot. or should be the lot.06:26
jaegerAh, ok06:26
*** pitillo has quit IRC06:26
Romsteri figure if you want it something else just change them, i made it conform to the same standard as core xorg only compat-3206:26
jaegerreading the backlog now06:27
*** deus_ex has joined #crux-devel06:27
*** pitillo has joined #crux-devel06:28
jaegerIt's fine with me if compat-32 only contains 32-bit versions of core,opt,xorg and the rest move to contrib06:28
jaegermakes more sense for maintainers that way06:28
jueRomster: I've found 59 where Tilman is listed as the maintainer06:29
jaegerjue: in the case of nvidia pedja was the arch maintainer for 64-bit and wanted to continue to maintain it for 3.0 instead of me taking it over06:29
jaegerso we'd either need to give him opt access, move nvidia to contrib, or update it ourselves06:29
jueto give him opt access, he has to apply to become a opt maintainer, I'd say06:30
juebut having nvidia in contrib is just fine for me too06:32
jaegerI don't have a strong preference06:32
jaegerpedja: any opinion? :)06:32
jueme neither06:32
jueso we agree that compat-32 is a team effort like xorg and the maintainer of every port should be 'CRUX compat-32 Team'?06:36
pedjajaeger: most elegant solution would be for you to maintain nvidia, if you like, since you are already member of opt, and you are doing a fine job :)06:39
jaegerjue: that is fine with me, sure06:40
jaegerpedja: I'll be happy to take it if you want me to but last time we talked about it I thought that you wanted to do it yourself. I'm fine with either way, I don't think moving it to contrib is a problem06:41
frinnstspreading the workload is a good thing06:41
jueRomster: would you care to update the remaining ports?06:41
jaegerfrinnst: agreed06:42
frinnstthere are other clashing ports that "has two maintainers", the binary-only stuff such as java and flash06:42
pedjajaeger: I'll send you update patches for nvidia port in case you forget/are too busy :)06:43
frinnstvirtualbox to some degree too06:43
jaegerpedja: that would be fine. Should I take it over, then, officially?06:44
pedjajaeger: yup.have fun.06:44
jaegerfun, hehe06:45
jaegerok, will try :)06:45
jaegeroops, fat fingers this morning06:45
jaegerI'll update the maintainer line next time there's a new driver06:45
jaegerI've got a ck4up line for it in place already anyway06:46
frinnstwanna keep maintaining flash and java?06:47
jue.oO another thing: looks like we have partly dropped 2.8 support already?06:47
pedjafrinnst: will both virtualbox and vbox-bin be in contrib?06:47
frinnstpedja: dunno. personally i prefer vbox-bin over the source version06:48
frinnstalso one of sepens ports06:48
jaegerPersonally I have very little stake in 2.8 now, I kinda figured at some point we'd be focusing on 3.0 but backporting security fixes06:48
frinnstI still push to 2.806:48
jueme too and most others too06:49
jaegerWell, assuming for now that we want to keep pushing to 2.8, how long do we do that?06:49
juejust saw some 3.0-only commits today06:49
rmullI may be out of line here, but why is crux-arm an independent project? Wouldn't it benefit the crux network as a whole to incorporate it into the crux infrastructure?06:50
juejaeger: yeah, that's one question06:51
juethe other is how we proceed with i686 after then06:51
frinnsthas anybody volunteered to keep 32bit alive?06:52
jueIMO we should ann it to the ML if we stop the 2.8 support06:52
jaegernot that I've seen yet06:52
juewell, I'd help06:52
Romsterwhy does this happen06:52
jaegerrmull: I don't think that would be a smooth or easy thing to do. ARM is too much a distributed and moving target in my mind06:52
Romster$ sed -i -e 's|^# Maintainer:.*$|# Maintainer: CRUX compat-32 Team, compat-32-ports at crux dot nu|g' */Pkgfile06:52
Romstersed: couldn't open temporary file glew-32/sedahFes9: Permission denied06:52
frinnsti've seen some whiny remarks about the lack of support for 32bit with 3.0, but thats about it06:52
Romsterand it wont update them all..06:52
Romsteri thought i got the lot with the sed command damn it06:53
rmulljaeger: Agreed, it wouldn't be easy. They've been having hosting issues, which is why I ask. Anyway, thanks for addressing it.06:53
jaegeryeah, I've been watching in the arm channel. Isn't sepen hosting it at his home now or something?06:54
rmullHe is06:54
pitilloreally it can be as distributed as any other arch jaeger. Putting some guidelines/rules about how to develop, it can be generic (related to ABI's) and optimized (per device and their compat)06:54
pitillojaeger: yes, currently it's hosted on sepen's house and finishing all the stuff related to the release06:55
Romsterno idea ran it as root worked some permission issue...06:56
rmullThe ARM stuff all seems fairly hierarchical to me, which makes it manageable to some degree. Just needs to be planned with a good amount of forethought.06:56
jaegerPerhaps a better question is this: What do you mean by "incorporate it into the crux infrastructure"? The ARM stuff is much more complicated with several different toolchains, hardfp vs. softfp, cross-compiling tools, etc.06:56
pitilloI think this was talked some time ago and the real fact was that there were other arch (ppc) which were splitted from (and 64b begins too), as CRUX officially was oriented directly to i68606:57
jaegerRomster: if that permissions issue was in your local git checkout it might be worth fixing06:57
rmullSpecifically, hosting development, mailing lists, web content, etc from the same server would be a start, since it would be a recognition that crux-arm is of value to crux as a whole (which is just, like, my opinion, man)06:58
juehelp :) would be nice to discuss one point after each other06:58
pitillormull: we are trying to make it versatile and hierarchical, covering all ARM stuff currently.06:58
rmullpitillo: I think it's shaping up nicely, I'm just worried about the at-home hosting mostly06:58
jueIMO we are still at 2.8/i686 support06:59
jaegerjue: true, this could get rather confusing, heh06:59
rmullSorry, shelving the ARM debate for the moment06:59
pitillojaeger: all the cross-stuff, is used in both ABI's just to build generic releases (some kind of iso.git but splitted in this arch per ABI)06:59
pitillosorry for the noise06:59
juelooks like nobody is voting for ongoing updates for 2.8?07:01
jaegerWell, it seems like some people have come out of the woodwork, so to speak, to complain about 3.0 being 64-bit - with that said, we gave quite a LOT of time on the ML and in IRC for people to voice complaints if they wanted to07:02
jueyep, that's right07:03
jaegerIt's possible that we could support both architectures indefinitely but I don't know for sure, we're a small team07:03
jueno, that's not an option for me07:03
jaegerIf another person wants to step in and maintain a 32-bit 3.0 I would not object to that, but I'd consider it like your previous i586 contribution07:05
jaegeror 2.8 multilib, even07:05
jaegercontributed but not official07:05
rmullThat sounds reasonable to me07:05
Romsteri'd drop 2.8 multilib stuff if i were you jaeger07:05
jueyeah, makes sense07:05
Romsterafter a short while i need to move to 3.0 yet07:05
jaegerhell, I will even build a 32-bit toolchain if someone wants it07:05
frinnstthere shouldnt be too much work involved in keeping a 32bit toolchain running07:05
jaegerRomster: I've not updated 2.8 multilib since 3.0 hit07:05
Romsternether have i except a few ports.07:06
pitilloI think the work will be related to its maintenance frinnst07:06
Romsteri need to make a move but i'm working this weekend too07:06
frinnstyep, but even that isnt much work, as long as somebody has an interest in it07:06
frinnstjust like x86_64 was very low maintenance07:07
frinnstbut yeah, I dont want to keep maintaining it :)07:07
jueok, so we agree that we stop pushing to 2.8 right right now ;)07:08
pitillothat's the point and may be the problem, someone (or a group) who will be able to develop/run/maintain all the 686 stuff IMHO07:08
Romsterwhy don't we get a group for i686 3.0 like i've said to those that need it.07:09
Romsterthan for them to complain there is on 32bit support.07:09
pitillojue: that should be done if none was pushing in 2.8 systems and checking all was running right (I don't now if push were done in 2.8 when they were tested on it)07:09
jaegerjue: +107:09
Romsteri need sleep i'm off to bed if nothing else concerns me. got work tomorrow.07:10
jueRomster: good night07:11
jaegerRomster: in order for us to have a group for i686 3.0 we need people who are interested to be that group :)07:11
Romsterwell i may have a use for it at work on some old pentium D machines for data recovery07:12
Romsterbut it wont be anything mroe than core ddrescue and a couple of others partedmagic07:12
Romsternot gonna maintain the entire xine or anything massive i got enough todo in 64bit now07:13
Romsteri agree with not pushing to crux 2.8 unless you gonna use it.07:14
Romsterbut then there is a whole whos gonan build the iso and stuff...07:14
pitillojaeger: there are more things related if that happens, all the infraestructure should be adapted to give support for that arch probably in a lot of services (git, ML, FS...) There is more work around that kind of choice if I'm right (and that work won't be only related to that group, it will directly related to core members)07:14
Romsterright bed i'm pretty tired and probably making no sense right about now.07:14
jaegerpitillo: It doesn't have to be, jue's i586 and my 2.8 multilib are examples of that... neither were part of the crux infrastructure07:16
pitillojaeger: it can be done in that way too, providing only an iso and letting user pick upstream ports and fighting with them if there are problems. It was in this way how i585 contributed image worked in the past?07:18
jaegeras far as I know there were no i586 repos, only the ISO. jue can correct me if I'm wrong, of course07:19
jaegermultilib had repos on my site but not on before 3.007:19
juewhat should we do with the *-x86_64.git repos? I'd suggest to keep but hide them in our gitweb?07:19
jaegerWhen crux was only 32bit the i586 thing was no big deal07:19
jaegernot likely to have footprint differences for 2 32bit builds, just for 32bit vs. 64bit07:20
frinnstjue: yeah some history might be nice07:20
jaegerhiding them is fine by me07:20
juejaeger: yep, no repo for the i58607:20
pitillothat's what I meant, there were only an ISO and the final user was the maintainer (there weren't any kind of development related to 586, which is different to multilib, where there were an ISO and a development to maintain it, outside CRUX infraestructure, but it was. Both, 586 and multilib have similarities but there are some differences too)07:23
juedone, see
jaegerI guess I don't understand what you're saying/asking, then07:25
jaegerjue: looks good to me07:25
juerepos are still browseable, e.g.
pitillomay be I didn't understand right the "group" part, but that sound for me as a group of people maintaining not only the ISO (all the work around a maintenance)07:26
jaegerWell, if we had people interested in doing that, sure. So far it doesn't seem like there are people willing07:26
pitilloyes, people and resources in this last case, this is what I tried to explain07:27
jaegerwow, someone is rsyncing 2.7 multilib ports right now :P07:28
juepedja: wrt sqlite, there was no request for that option until now, but I'm on the way to commit a new version with it07:30
juegreat, all problems solved :)07:32
juefrinnst: are you able to reproduce the glibc/regexp crash? I'm not07:34
pedjajue: thank you :)07:38
juenp, thank you for the report07:39
sepensorry for the delay, +1 to stop pushing into 2.8, only security fixes, right?!07:48
sepenthey can be cherry-pick'ed from 3.0 imho07:48
jaegerThat's my preference07:48
sepenI worked in that way since 3.0 branches appeared, so I was not sure about merge from 2.8 (32b) to 3.0 (64b), can be arch differences and thats not good to merge07:50
sepenI prefer to cherry-pick commits07:50
sepenfor now only security commits its fine for me07:51
sepenabout the ARM talk, for 3.0 we have in mind to release only the hardfp stuff, and move softfp to attic as we're doing with i686 in 3.007:52
sepenwow gitweb cleanup!07:54
jaegerI also prefer cherry-pick to merge when going backwards... not as much of an issue forward07:57
pitillois there any specified way to create a 3.0 branch on repos currently? I've tested e17 from 2.8 branch in 3.0 and all is all right. I want to create 3.0 branch from 2.8 but I'm not sure if there is an official way to do this. Any comments about or can I go ahead with this way (checkout 2.8; branch 3.0; push origin 3.0:3.0)?08:13
jaegerthat seems the best way to me08:14
pitillogreat jaeger, I prefer to ask before doing anything as I'm not very good with git and I don't know how it's managed officially08:14
sepenpitillo: git branch 3.0; git push origin 3.0/3.0 but you should be in 2.8 when create that08:15
sepenif not it will be created from master, not from 2.808:15
sepen*err, 3.0:3.0 as you said ;)08:16
sepenis for rebase heheh08:16
pitilloyes sepen, first, before creating 3.0 branch, checkout 2.8 branch and start the new onr from there. Thank you both08:17
frinnstjue yeah i tried it yesterday08:33
frinnstcompletely forgot about it since then :D08:33
frinnstnever tried the patch08:33
frinnstnew intel xorg-driver should be safe to apply if someone has the opportunity08:38
jaegerhrmm.. nss doesn't build for me in 2.8 currently, will get a log08:43
juejaeger: that's a left-over from the 3.0->2.8 merge08:45
juejaeger: reported the issue to teK_ already08:46
jaegerah, ok08:46
jaegerwell, it won't affect building a toolchain anyway so no worries08:46
jueshould work if you remove the USE_64=1 from the make line08:47
jaegeryeah, found a bug post that hinted at that, thanks08:47
pitilloteK_: when you have time, can you check rsync export in e17's 3.0 branch? May be could be added irc announce to its hooks too?08:56
*** joe9 has joined #crux-devel09:17
*** pitillo has quit IRC09:58
*** pitillo has joined #crux-devel10:00
*** pitillo has quit IRC10:11
jueupdated my netbook from 2.8/i686 to 3.0 without troubles, have to recompile a lot of stuff now :)10:21
Amnesiahm, how can I escape source URLs which contain special chars like &'s10:29
jueAmnesia: you can use %26 for &10:36
Amnesiaah ofc, ty10:37
Amnesiajue: hm no succes10:47
Amnesia <- not found10:47
Amnesiahm nvm, pkgmk accepts quotes:p10:56
sepenteK_: pitillo shouldn't have pitillo:e17 perms for e17.git/hooks/post-update?11:29
sepenso he would be able to edit this file and append 3.0 to BRANCHES variable11:30
*** mike_k has quit IRC12:56
frinnstbunch of updates16:09
prologicWho uses Java though16:10
prologicI don't think I even have it installed16:11
frinnstare you kidding?16:11
frinnstits fucking everywhere16:11
prologicThis is strictly true16:15
prologicthere are lots of software (entrprise especially) writtein Java16:15
prologicbut still16:15
frinnstevery one of our customer uses it for something stupid16:15
prologicif I see xyz in Java I tend to ignore it16:15
prologicand look for something written in Python :)16:16
frinnsthp uses it for their ilo2 stuff16:16
prologickeyword "something stupid" :)16:16
frinnstso i have to use it at work to do simple stuff as open a console or mount an iso16:16
frinnstI like how they released the patch on a friday.......16:16
jaegerAll the ilo type things use java16:26
jaegermy supermicro and oracle ones as well16:26
prologicI wish they'd replace the software16:32
prologichtml5 and javascript ffs16:32
*** sepen has quit IRC18:06
*** __mavrick61 has quit IRC19:30
*** __mavrick61 has joined #crux-devel19:31

Generated by 2.11.0 by Marius Gedminas - find it at!