IRC Logs for #crux-devel Friday, 2008-06-20

*** pitillo has joined #crux-devel00:01
*** mwansa has quit IRC00:03
*** mwansa has joined #crux-devel00:05
*** mwansa has quit IRC00:13
*** mwansa has joined #crux-devel00:15
cptntilman: any experience with cgit01:39
cptnor anyone else for that matter :-)01:40
*** mwansa has quit IRC01:51
*** mwansa has joined #crux-devel01:53
*** DarkNekros has joined #crux-devel02:34
*** sepen has joined #crux-devel03:53
*** pedja has joined #crux-devel04:37
nipuLso much better than gitweb imho05:15
nipuLtilman: yeah, i'm using nspluginwrapper, it's pretty stable these days05:27
nipuLcptn: ^^05:27
nipuLi would recommend it over 32bit firefox, i could never get that to print05:28
nipuL32bit kept trying to dynamically load the 64bit cups libraries and crash05:29
nipuLre: as to wether to choose pure64 over multilib, why not provide both it's only going to affect a handful of core ports05:35
nipuL:[ glibc stopped compiling for me05:36
nipuLugh, stupid squid cache05:53
cptnnipuL: okay, duplicating firefox and dependencies would have been quite a bit of work06:16
nipuLmost of the work to support 32 bit is on xorg due to the split06:20
nipuLthat said, it's not really that much work as long as a handful of other people are intrested, i've been managing to do it solo for a while now with no major hassles06:21
nipuLif we can come up with an automatic merge, things would be peachy06:22
nipuLbut cherry picking commits isn't overly difficult06:23
nipuLwhat did you want to know about cgit?06:23
cptnwell, I like the fact that you can directly link to files without having a hash06:26
cptnwhich would be nice for portdb06:26
cptnI was wondering if there was any reason not to switch on crux.nu06:26
nipuLplus it's like a gajillion times faster06:28
cptnokay, sounds good06:28
cptnhopefully I can check it out this weekend06:29
nipuLurls are a lot cleaner too06:36
cptnnice read, thanks06:40
*** mwansa has quit IRC06:41
nipuLi'm doing to more work on a multilib repo, upto glibc and it got me wondering about the best place to put 32 support libraries06:54
nipuLshould they be kept seperate or placed in a univeral multilib repo06:55
nipuLalso what would be a good naming convention, when danm first release crux64 he had a compat32 repo which held all the 32bit support stuff and simply tacked a 32 on the end06:56
cptnmmmh, good question06:57
cptn-compat might be nicer06:57
cptnyeah, maybe06:57
nipuLor is that too verbose?06:57
cptnhaven't really thought about that06:57
cptnexplicit is better ... :-)06:58
nipuLworks for me06:58
*** mwansa has joined #crux-devel07:00
nipuLwrt repos, if it was going to be called core-multilib is would make sense to put the compat32 ports there too07:01
cptnwould we maintain that in parallel of core(64)?07:07
nipuLthere's not much difference, bewteen the two setups outside of core07:08
cptnso the user could chose either core64 or core64-multilib?07:08
cptnokay, I see07:09
cptnsomething slightly different:07:09
cptnmaybe we should extract maintainer and packager infos from Pkgfiles07:09
cptnsince they'll only disturb merging07:09
nipuLgit needs a merge -i07:10
cptnI don't think we can use git to merge at this point in time07:10
nipuLor some form of semi-automatic cherry picking07:10
cptnthat would be a major hassle07:10
cptneven if you can cherrypick the changes, you'd still go through the whole tree07:11
nipuLi thought cherry picing just applied the diff07:11
nipuLyeah, "Given one existing commit, apply the change the patch introduces"07:12
cptnah, okay, that should work07:12
nipuLi suppose something could be scripted without too much difficulty07:13
nipuLit would mostly be useful for applying version changes07:13
cptnmaybe we wouldn't need git for that at all07:13
cptnI mean, we could pull the diff using git, and then just patch07:14
cptn*use patch07:14
nipuLchanges to build may have to be applied manually depending how much they differ07:14
nipuLhmm, i might leave my pkgutils alone for now07:15
nipuLi'm migrating back to traditional crux on a live system (my desktop)07:16
tilmanapart from being slow as crap i like gitweb07:40
tilmanon small sites it's nice07:40
nipuLdepends on how small your site is07:40
nipuLtry running it on a 128mb vps07:40
tilmani meant the number of repos07:40
cptnthe only thing I miss it that you can't link to files07:47
cptnoh wait07:47
cptnit actually seems to work07:47
cptnjust wondering how it finds the proper branch07:48
nipuLif it's anything like cgit, default is newest branch unless specified07:48
tilmansimone hax0red our gitweb to use the latest branch by default07:49
tilmanie 2.4 atm07:49
cptnah, nice07:49
tilmanplain gitweb probably assumes master :)07:49
tilmanwell, there's pros and cons07:49
tilmancons being that we cannot upgrade gitweb because i have no clue where the changes were made ;)07:49
nipuLyou hacked gitweb outside of a git repo?07:54
tilmani think so07:54
tilmanepic fail, i know07:54
nipuLoh the ironing!07:55
*** mwansa has quit IRC07:55
*** mwansa has joined #crux-devel07:57
nipuL(i know i said ironing)07:59
nipuLso you can't specify a default branch in gitweb?08:08
tilmani don't think so08:09
tilmancptn: re. syncing port updates from foo.git to foo64.git -- shouldn't it be easiest to just examine the diffs in opt.git?08:11
tilmanerr, s/opt/foo/08:11
tilmansince diffs between foo.git and foo64.git will always contain noise like +# Arch maintainer:08:12
nipuLif you merge08:13
cptnfor ports which are not changed, applying the diff will work fine08:13
cptnhowever if a port needs bigger changes, you'll have to merge manually08:13
cptnin which case it would be two lines less to ignore :-)08:13
cptnwe could attach a file to the notification mail containing the has08:14
cptnwhich I could then pipe through a merge tool, directly from mutt08:15
cptnso for simple merges, you could to it all from mutt :-)08:15
*** pedja has quit IRC08:17
j^2hey cptn08:19
j^2hey tilman08:19
tilmanhello j^208:19
aonhi j^2 (14)08:20
cptnhey j^208:23
nipuLpkgmk is going to need to be changed slightly to support multilib08:32
tilmancptn: /op tilman plz08:35
*** cptn sets mode: +o tilman08:35
tilmannipuL: sucks, but the diff isn't too bad ;)08:36
cptntilman: why do you need the op?08:36
nipuLthat's not the only diff08:36
tilmani invited rehabdoll08:36
tilmannipuL: oh i see08:37
nipuLthere needs to be a mechanism in pkgmk that sets $PKGMK_ARCH08:37
sepenohhh sounds like archlinux08:37
nipuLlike maybe arch=08:37
cptncould also be in the Pkgfile08:38
cptnalthough I'm not sure if that's better08:38
nipuLit would have to be in the pkgfile08:38
tilmani'll create some git repositories now08:39
nipuLor perhaps a .arch file08:42
sepen+1 for this last one08:42
*** mwansa has quit IRC08:52
*** mwansa has joined #crux-devel08:52
*** mwansa has quit IRC09:12
*** pitillo has quit IRC09:12
*** mwansa has joined #crux-devel09:19
*** mwansa has quit IRC09:24
j^2nipuL: :-O09:39
*** predatorfreak has joined #crux-devel09:40
j^2nope, just shocked on how pretty :P09:42
nipuLwho killed www.crux?09:58
*** predatorfreak has quit IRC10:00
*** mwansa has joined #crux-devel10:18
nipuLre: normal and 64bit repos, would 64 contain every port or just the ones that require changes?10:22
cptnwell, every port that has an arch maintainer10:23
cptnor specific to that arch10:23
nipuLso for example, would every port that currently exists in core be required to have a maintainer in core64?10:25
cptnI'd say so, yes10:25
cptnor not be in core6410:25
nipuLeg, these are all the ports in core that require changes for multilib10:25
cptnalthough for core64, most things are probably needed10:25
nipuLcouldn't you then use it in conjunction with core?10:26
cptnsure, it would be more efficient10:26
nipuLbut i guess that would possibly break for other possible alternative archs where a certain port just wont build ir isn't needed anyway10:27
cptnwhat I dislike about this approach, is that that ports don't get tested10:27
cptni.e. if a port isn't overridden in the core64 repo, and update that works fine on 32-bit might break on 64-bit10:27
cptnand that's not caught by the devs10:27
*** cptn has quit IRC10:28
nipuLcouldn't that be solved with a bit of process before the port hits rsync10:29
nipuLa port is updated, arch maintainers are notified and given a certain time frame to verify the port10:30
nipuLbut then i guess each port would still need an arch maintainer10:32
nipuLmaking my point moot10:32
*** pedja has joined #crux-devel10:39
*** mwansa has quit IRC10:48
*** mwansa has joined #crux-devel10:48
*** mwansa has quit IRC10:53
*** mwansa has joined #crux-devel11:14
*** mwansa has quit IRC11:15
*** mwansa has joined #crux-devel11:15
*** sepen has quit IRC11:26
*** cptn has joined #crux-devel11:44
cptnnot bad for a motherboard switch11:46
tilman# Primary Maintainer: ...11:47
tilman# Arch Maintainer: ...11:47
cptnmaybe a bit long11:52
tilman# Primary dude: / # Arch dude:11:52
cptn# Master:11:52
cptn# Apprentice:11:52
*** cptn has quit IRC11:57
*** mwansa has left #crux-devel12:15
aon# Maintainer: ...12:16
aon# Arch Maintainer: ...12:17
tilmani thought that one might be a bit confusing12:17
aonbut we're talking about people who have succesfully installed and are using crux12:17
tilmantrue :D12:17
aonat least in 99% of the cases12:17
aondoes elinks support javascript?12:19
aonor am i remembering totally wrong?12:19
tilmanno idea12:19
aoni'm trying to post to my blog but it's so ajaxy i can't use it with w3m12:19
aonof course i could mess with  the databvase directly :>12:19
tilmanomg, you have a blog?12:20
aonyes, although it doesn't have much content12:21
aoni mainly use it to keep track of my entertainment consumption12:21
aonie. movies and the like12:21
aoni really should dumb it down a bit :)12:22
aonchyrp is a bit overkill, then again i might want to do more full-featured blogging one day12:23
tilmanit looks VERY web2.012:24
aonyeah, it is12:24
aonbut i like it12:24
* tilman is debugging his zsh perofmrnace issues on logout12:26
tilmanwhy the hell do we use --enable-zsh-secure-free?12:31
aonbeats me :D12:31
* tilman hytter med naven at zsh for stripping things itself12:32
tilmanah, i mixed up --enable-debug and --enable-zsh-debug ;)12:33
aoni think i'll kill the gprs and read some books12:35
aonthey're like 10 days overdue, the library had already mailed me :)12:35
aongnight, i hope the guy with hsdpa is also "ill" tomorrow so i don't have to use my quota12:35
tilmanbye aon12:36
tilmandropping the secure-free crap also brings back tab completion back to normal speed12:38
*** cptn has joined #crux-devel15:17
tilmancptn: Maintainer and Arch Maintainer?15:24
cptnare you talking about the field in Pkgfile?15:24
cptnor the term in general?15:24
tilmanyes :D15:24
tilmanthe former15:24
cptnlet's make it explicit15:25
cptni.e. Arch Maintainer15:25
tilmanthe primary maintainer should be mentioned, too, no?15:25
cptnI think so, yes15:25
*** treach has joined #crux-devel15:26
cptnmaybe we could get rid of the packager field?15:26
cptnassuming we mention it in the git commit message15:26
tilmandunno, it's nice to give some credit15:26
*** DarkNekros has quit IRC15:37
tilmani still need to import all of the xorg ports that don't need to be changed for x86_6415:40
tilmani also created {opt,core}-x86_6415:41
tilmanthough their 2.4 branches don't exist yet ;)15:41
cptnnice, thanks15:41
cptnokay, I have to update my BIOS15:48
cptnhopefully, this will fix cpufreq :-)15:49
*** cptn has quit IRC15:49
*** treach has quit IRC16:26
*** treach has joined #crux-devel16:27
*** DarkNekros has joined #crux-devel16:33
*** DarkNekros has quit IRC16:39
*** sepen has joined #crux-devel18:54
nipuLare the ports you're using viewable online? i'd like to see how they really differ from mine19:15
*** treach has quit IRC20:12
*** predatorfreak has joined #crux-devel21:09
*** predatorfreak has quit IRC22:05
*** mwansa has joined #crux-devel22:38

Generated by 2.11.0 by Marius Gedminas - find it at!