IRC Logs for #crux-devel Wednesday, 2010-02-24

*** pazo has joined #crux-devel03:11
*** pazo has quit IRC04:54
*** tnut has quit IRC05:35
*** tnut_ has joined #crux-devel06:47
*** tnut_ has quit IRC11:12
*** jue has joined #crux-devel11:59
rehabdolljaeger: could you pull from my repo if i create a x86_64 specific branch of the iso?12:31
rehabdollhavent set up a repo yet, but i plan to12:31
juerehabdoll: btw, do you still have issues with dcron? I've carefully looked at this the last days but couldn't see any problem12:37
jaegerrehabdoll: I assume so, why to you ask? want me to try to build an ISO?12:38
rehabdollnope, jue12:41
rehabdolli actually ran two instances of dcron D;12:41
rehabdollim such a retard :)12:41
rehabdolljaeger: nah, just thought it would be a good idea to have some x64 stuff in the iso-repo12:42
jaegerrehabdoll: no objections from me :) I was just curious why you asked if I could pull from it, that's all12:43
juerehabdoll: indeed a good idea, but probably easier if you push the stuff yourself12:51
juejaeger: btw, is the iso.git repo update-to-date currently?12:53
jaegerrehabdoll: oh, did you mean for me to pull from your repo and push to iso.git myself?12:53
jaegerjue: the 2.6-newmedia branch is working but could use some updates, probably12:54
jaegernew deps, updated kernel, etc.12:54
jaegerI want to rewrite the Makefile to product both an ISO and an image suitable for USB thumbdrives, etc., but haven't finished it yet12:54
rehabdolleither is fine with me12:54
rehabdollim building from the newmedia branch at the moment12:55
rehabdollhad to do some addition to the packages.{opt,xorg}12:55
juerehabdoll: new firefox deps?12:58
rehabdolllibnotify. also building xulrunner configure complained about cairo needing xcb-utils13:01
jaegeryeah, some of the deps have changed since my last push13:01
jaegerover all it should still work reasonably well, though13:01
rehabdolli think something complained about gperf too13:02
rehabdollyep13:02
jaegers/product/produce/13:04
jueone note: if you we are doing changes to packages.{opt,xorg} we probably have to adjust setup-helper as well13:09
jaegerPerhaps we should put a document in the wiki that details how those files affect each other when changed13:10
juejaeger: yeah, good idea, it's very easy to forget something here13:11
jaegeryes, I have forgotten things like that in the past :)13:12
juehmm, any ideas for a good name of such a doc? ;)13:21
jaegerPerhaps it would be best in a sub-section of the ISO Building info13:22
jaegerBuildingISO probably needs to be updated as well13:23
teK_rehabdoll: would you mind sharing your openoffice port for x64?13:29
rehabdollhttp://www.obra.se/crux/c64/13:31
teK_thx13:31
jaegerI'll work on producing some updated instructions for BuildingISO13:33
juejaeger: I think a pure developer doc would be easier than a how-to for everyone ;)13:34
jaegerThat's fine with me13:35
jaegerI will also try to finish my modifications of the Makefile before 2.7, that would be a nice feature13:37
juejaeger: if it's possible to put everything in one document, that's even better13:37
jaegerI think one document will be fine. I'll post a draft on my site or to the ML or something for devs to review before it goes into the wiki13:37
tilmanjaeger: if any of your gnome buddies want to have commit access, send t hem here13:38
jaegertilman: probably maro and pazo but I will ask them13:39
juejaeger: cool, thanks13:40
juetilman: you've seen udev 151?13:40
jaegerupdating my build environment now, will hopefully have a document started tonight13:40
jaegerI'm back to crux x86_64-multilib on my build box, finally13:43
tilmanjue: updating now13:49
maro\o_14:29
jaegermaro: do you see the gnome repo comments in your scrollback/log?14:30
maroonly saw one14:30
marobut haven't scrolled long14:31
jaegersorry, only one, just tilman's comment about commit access14:31
marooh yes :)14:31
maroI could look into integrating the post-install auto thing14:31
maroand the makefile for nls hacks14:32
jaegertilman: I thought about the branch thing a bit more and wondered how difficult it would be to make branches that contain both gnome and crux releases14:32
jaegermaro: feel free to offer suggestions on the branch subject, too14:32
jaegerI was thinking of something like 2.6-gnome_2.28.2 or similar14:33
jaegerit's a bit ugly but would clearly define which crux release a gnome release was intended for14:33
maroin theory I'd prefer that too14:33
marobut with the man power we have I think it would be too much maintenance14:33
jaegeror even smaller like 2.6-2.28.214:33
maroso would you run a 2.5-2.28.2 too etc.?14:34
jaegeryeah, not sure how much work it'll be at the moment but that's certainly possible14:34
jaegerI personally wouldn't maintain any that are older than the current crux release14:34
maroin any case I think we should at most track x.y releases of gnome which should always be the newest14:35
jaegertoo much work there14:35
maroe.g. 2.28 would be 2.28.2 at the moment14:35
jaegeryeah, that would be ideal in my opinion14:35
jaegerso theoretically there's only one important branch at a given time14:35
maroperhaps do a 2.28.3 to work on, and merge into the 2.28 branch afterwards14:35
marosort of like FreeBSD stable branch14:36
jaegerseems reasonable14:36
jaegerso we might have a branch like <CRUX x.y>-<GNOME X.Y> (2.6-2.28) be the stable branch that users get and 2.6-2.28.3 would be our dev branch for the next point release14:37
jaegerthen merge 2.6-2.28.3 into 2.6-2.28 when it's ready14:37
maroyeah14:37
jaeger(just making sure we're on the same page)14:37
maroso 2.28.3 would only be used for like 2 days while the tarballs are getting uploaded to gnome ftp14:37
jaegerassuming we could build and properly test it in 2 days =)14:38
maroobviously, but for .3 that usually isn't a problem here :)14:38
maro.0 is another story14:38
jaegeryeah, probably not too bad14:38
jaegerheh14:38
marohow many crux releases would you like to support?14:40
jaegerideally only the current one :)14:40
maropersonally I think only the latest for us, but if someone is willing to support an older release then they could do that14:40
jaegeryeah, that would be fine14:40
jaegerand I don't mind leaving old branches available for users that don't want to upgrade right away14:41
maronope :)14:41
jaegerI imagine pazo would be willing to help as well since he's been working on gnome lately, too14:41
maroactually I found an old disk with gnome 2.12 on crux on it (from an upgrade where I migrated the data and forgot about the disk)14:42
jaegerheh, nice14:42
maromuch snappier than recent releases, I was totally surprised14:42
jaegerI actually haven't been successful at building 2.28 yet but every time I try to delve deeper I get busy with work or whatever =/14:43
marograduallity is a bitch when it goes the wrong way14:43
jaegerso my latest gnome repo online is 2.24.3, I think14:43
maroyikes :(14:43
marowhat parts are giving you trouble?14:43
jaegerIt would probably be best to start from your tree than mine in the crux.nu repo14:43
marono way, mine's waaay too messy14:44
jaegerdevicekit, consolekit, pam, etc.14:44
maroit would be like publishing dirty laundry14:44
jaegerheh14:44
jaegerperhaps a start from scratch, then14:44
maroI'd like to take your tree since that's what crux gnomers use already14:44
maroand incorporate any good stuff from my tree14:45
jaegerwell, I don't mind trying that, just keep in mind it needs some work14:45
marosure :)14:45
marohm, about the branches14:46
jaegerI've been slowly trying to find and collect good links for packagers but they're hard to find14:46
jaegerseems like a LOT more info for gnome app devs than packagers available14:46
marowould it be stupid to only run gnome branches, and perhaps a temporary branch for crux releases?14:46
jaegertilman may correct me on this but as far as I understand git we have complete control over what branches we create... the part where he comes in is the git->rsync script to offer them up as rsync ports14:47
marothe only thing I can come to think of in base crux that would affect gnome is things like requiring newer udev14:47
jaegerso we can create whatever intermediate/dev branches we want14:47
maroah14:48
jaegerwe would just specify for example '2.6-2.28' to be the one that gets offered for rsync14:49
marobut what do you think of the chances for trouble only tracking gnome releases?14:49
marothen freezing the tree with each crux release14:49
maroor do a tag14:50
jaegerpersonally, I'm fine with whatever way we all like and presents a consistent gnome build to the user14:50
marosay, 2.5 when 2.5 is abandoned14:50
jaegerif that's tracking the gnome release and tagging for crux releases, fine by me14:50
maroyeah, all I'm interested in is as few branches as possible14:50
jaegerright14:50
jaegerwould it be better to do tags when a releases is abandoned or tags when a new release happens? 2.5 tag when 2.6 comes out, for example14:51
jaegeralong the lines of our "just support the current release" thing14:51
jaeger(assuming those aren't the same time, which they might be)14:52
maroyeah, as the way I see it, this is "the last supported version for 2.5"14:52
jaegerright14:52
marobut then again I'm no expert in relmgmt :)14:52
maroI'm very much a rolling release type of guy14:53
jaegertilman: if you (or someone else who has more git experience) have an opinion on this, feel free to suggest :)14:53
marothis install was from a crux 2.1 cd :)14:53
jaegerI use git every day at work but we don't have any branches at the moment, just storing config files with history14:54
jaegercool, hehe14:54
maroperhaps we would be better off just using HEAD and do tags14:54
maroand branches for special work14:55
marosay the integration stuff14:55
jaegernot sure, to be honest... at least branches are very cheap and pretty easy to manage in git14:55
marotrue14:56
jaegerI would be inclined to use branches just in case, though we can certainly limit the number of them14:58
maroyeah14:58
marowould fit better with the rest of crux14:58
jaegerone advantage of that would be that if someone else joins in to help us later a '2.28' branch is more obvious than HEAD :)14:58
marotrue :)14:59
marofor gnome, branches would probably also be better than tags14:59
jaegerso far the idea I like best is to use the major.minor release as the branch14:59
marosince sometimes a tarball didn't make it in time14:59
jaegerhrmm, yeah15:00
maroyep15:00
marowould it be reasonable to ditch crux versions alltogether in the branches?15:00
maroand expect people to use the most recent crux at the time of release15:00
jaegeras long as we can equate a crux version with a branch for the rsync repos, sure15:01
marosay, no gnome 2.30 on crux 2.315:01
marocould we do that on a case by case basis?15:01
jaegersay to the users rsync://crux.nu/ports/crux-2.6/gnome/ is your source15:02
jaegerI think that's where the git to rsync script comes in15:02
jaegerI could be wrong but tilman seems to be gone right now :)15:02
maroah :)15:02
jaegerin my mind the git to rsync script would match our '2.28' branch to 'ports/crux-2.6/gnome/' in rsync15:03
maroyeah15:03
jaegerthen if we decide 2.30 is stable, the user still sees 'ports/crux-2.6/gnome/' but they get updated ports, etc.15:03
jaegerregardless of which way we decide to finalize branches, do you want me to go ahead and push my 2.24 stuff so we can start with that?15:11
marojaeger: yeah :)15:13
maroI'd say in general anything but .0, but that should probably be decided on a case by case basis15:14
maroespecially as we're right next to the 3.0 blow15:14
jaegerI wonder how big a change 3.x will be15:15
marobut for now, just getting something up would give us something to work from15:15
marojaeger: my guess is that you can pretty much make 2.30 a 3.0 if you choose to replace the old standard components15:15
maropanel, metacity, etc.15:15
jaegerinteresting15:15
jaegertilman: I'll need to fix my ssh key on crux.nu again because I'm a tool and forgot to save it before I reinstalled. :(15:16
marobut I haven't looked into it at all yet, only know what I've read on desktop-devel-list15:16
jaegerok15:16
jaegerI'll try to get it pushed tonight from home, can't do it right now from work15:19
marocool :)15:19
jaegerglad to get started on this again, though, I'm missing my nice gnome desktop :)15:20
marolooking forward to start the maro-laziness branch15:20
marough, you don't have any?15:20
maroI could tar up my gnome dir for you, but it's _messy_15:21
jaegerat the moment I don't have one set up, recently reinstalled crux on my build machine and it's running evilwm :)15:21
maroyou can use it for reference though if something is causing trouble15:22
jaegerThat would be nice15:22
maroah, I miss evilwm too :)15:22
maroone sec15:22
jaegerI love evilwm and windowlab but I don't always want minimal15:22
maroyou'll get the dirty directory, not an svn export15:22
jaegerthat's fine15:23
maroas there are probably many things I haven't committed for one reason or another15:23
marohttp://borkware.net/~mark/nasty-gnome-ports.tar.gz15:24
jaegerhaha, nice15:25
maro:)15:25
maroreally unsexy stuff in there15:25
jaegerdownloaded, will take a look this evening15:25
marocool, feel free to probe for anything :)15:26
maroI'll kick the dog of the couch and watch a movie, ttyl :)15:26
jaegerok, take care :)15:27
maropretty awesome that you're in the US and I'm up all night so we don't bother the others ;)15:27
marowill do15:27
jaegerconvenient :)15:27
*** jue has quit IRC16:01
jaegertilman: never mind about the ssh key, I figured out the right ones18:50
jaegermaro: I pushed a '2.24' branch up, be afraid21:48

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