IRC Logs for #crux-devel Monday, 2012-07-30

*** horrorStruck has quit IRC02:54
juehello08:14
jaegerheyo08:14
juestarted today to do some works for 2.8, nothing dubious so far08:18
jaegernice08:19
juejaeger: adapted your multilib ports for the toolchain08:19
jaegerWhat parts would you like me to work on?08:19
jaegeradapted?08:20
juewell, for i68608:20
jaegerah08:20
jueand used newer kerenl headers08:20
jaegerWhich headers version did you pick?08:21
juethe latest stable, 3.4.708:22
jaegerok08:22
juejaeger: recently we talked about a testing repo, would be nice to have one now08:22
Romsteri must admit io've been a bit slack with ports in multilib probably a bunch need bumping.08:23
jaegerYeah, I've got a lot of xorg bumps queued up but have been concentrating on other things first08:23
juejaeger: I'd suggest to branch our repo as late as possible to avoid a lot of merges between 2.8 and 2.708:24
jaegerthat's fine with me08:24
jaegerThat makes me wonder, actually, why we don't use HEAD for testing and then branch or tag releases from it08:24
Romsterlet me know when so i don't waste effort with jaeger's multilib git tree.08:24
jaegerRomster: we're just talking about x86 for now08:25
Romsteri've asked that question years ago no one answered that jaeger -_-08:25
Romsterah k08:25
juehmm, maybe I'm wrong, but that wouldn't solve the merge problem?08:26
jaegerWhat exactly is the merge problem? 2.7 updates that happen after we test something in 2.8's test repo?08:27
juein past we need a long time to finish the next release, for that dev time we fully support bthe current version, thus we have to update both branches08:29
juebut the testing repo I've talked about has a different idea behind it08:30
juefor example:08:30
jueI want some other pepole to test a port update before it is official committed08:32
jueso I'd put it temporary in our sandbox repo08:33
jaegerok08:33
jueand remove it afterwards from there08:33
jaegersounds reasonable08:35
juebut yeah, our git usage is a bit, let's say; uncommon08:35
jaegerAre your updated x86 toolchain ports available somewhere? I don't think I should duplicate the work08:39
juemaybe we can solve it otherwise, currently I have the problem that I have a couple of ports that I'd like to share, but I'm not really willing to setup a git server here08:41
jaegersolve the uncommon usage or toolchain stuff?08:42
juesorry, I'm a bit confusing08:43
jaegerwell, we do jump around subjects a bit :)08:43
jueI meant to share the ports08:43
jaegerah, ok08:43
jaegerwell, setting that up is really quite simple but if you prefer not to, we could use a temp repo on crux.nu or morpheus.net08:44
juesorry, back in some minutes08:45
juere09:04
jaegerwelcome back09:05
jueyeah, having such a repo on crux.nu would be nice, so all core/opt maintainers can use09:05
jueuploaded the ports for now -> httpup sync http://jue.li/tmp/crux-2.8/09:14
jaegerok09:14
jaegerAre the extra (non-toolchain) ports just the changes needed to make those ports work with the new glibc or gcc?09:16
jueyeah, that's everything I've changed for now09:16
jaegerok09:17
frinnstwee, finally crux + multilib at work09:17
jaegerfrinnst: how do you like the SSD? :)09:17
juefrinnst: .oO that's nice :)09:17
frinnsttbh, it's not had a good run yet. only compiling :)09:18
jaegerah09:18
jaegerI'm really happy with my 520 here at work but it's a different controller09:18
frinnstboss bought me one for personal use too. gonna put btrfs on it and a bunch of subvolumes \o/09:18
jaegernice09:18
frinnstit will be nice to run virtual machines from a faster storage09:20
jaegerhttp://jaeger.morpheus.net/linux/crux/files/multilib/toolchain/tc-failed.txt <-- I made a list of the things that broke for me when I was testing the multilib glibc 2.16 and gcc 4.7.1 toolchain, not sure how many of those are still relevant, some may be fixed upstream that you haven't already fixed09:22
jaegerlike httpup09:22
jaegerwell, non-crux upstream stuff, I mean :)09:22
frinnstyeah there are a few. I posted a tracking bug in flyspray09:23
jaegerok09:23
jueIMO the biggest problem is the 'gets' issue, a lot of ports are or might be affected09:26
jaegeryeah, definitely09:27
juejaeger: most of the updates/changes I did are listed in TODO2809:29
jaegersome of that info is outdated, too, like the glibc 2.14 and RPC headers stuff09:30
juecritical are libpcre and libmpc, because it break grep resp. gcc09:30
jueyeah, indeed ;)09:30
juebtw, TODO28 is a wiki page, additions and correction are always welcome09:42
jaegerunderstood, just didn't want to jump into that until I'm more up-to-date on what we're doing09:44
*** mike_k has joined #crux-devel09:44
jaegergoing to get the toolchain updates built on my VM09:44
*** pidsley has quit IRC09:55
juewhat I've done so far is:09:55
jue- installed everything from our CRUX 2.7.1 ISO to a new partition09:56
jue- updated the tool-chain09:56
jue- installed new deps like mtdev and libnl09:56
jue- run a sysup09:57
jue- updated everything marked as postponed from TODO2809:57
jue- rebuild all core ports09:57
jue- did the util-linux-ng/sysvinit stuff from TODO2809:58
juethat's all09:59
jaegersounds like a lot :)09:59
Romsteroh renamed util-linux10:01
jaegerShould definitely use some kind of staging or temp repo to avoid duplication10:02
*** horrorStruck has joined #crux-devel10:03
jueyes10:04
juesomeone eager to build and test a newer udev version? See here -> http://www.linuxfromscratch.org/lfs/view/development/chapter06/udev.html10:26
juethere are some newer threads about that in lfs-devel -> http://thread.gmane.org/gmane.linux.lfs.devel/12790 for example10:27
jaegerI did that with 185 though haven't tested it a lot10:27
jaegerhttp://jaeger.morpheus.net/linux/crux/tmp/udev/ for reference11:13
rmullcrux.nu is down11:18
jaegerIf it's not back up soon I imagine mavrick61 will comment on why11:19
jaegerat some point11:19
juejaeger: looks like LFS is doing the work that upstream refused to do, it might be easier to use their stuff than manually extracting from systemd sources in the long run11:31
jaegermaybe so11:31
juebut well, I'd like to leave it up to you what to do with udev, of course only if you agree ;)11:35
jaegerup to me? heh, I'm certainly no expert on udev :D11:36
jaegerIf the LFS folks keep their "fork" or whatever it is maintained I'd be fine with using that, it's less work11:37
frinnstso, we still have real shitty 2d-performance with cairo and the workarounds, no?12:24
frinnstor did I dream that?12:26
juedon't think so, at least I've nothing to complain with nouveau, nvidia and intel12:33
juefrinnst: how do you see the poor performance, is it application specific?12:44
jaegerI've not tested it recently, locked cairo... but where I saw it the worst was switching tabs in chrome12:48
jaegerjust switching a tab would take up to 3 seconds sometimes12:48
frinnstnot really sure12:51
frinnstbut when they enabled the workaround in radeon i got the feeling 2d got considerably worse12:52
frinnstalso today at work I run on a intel gpu12:52
frinnstI felt some lag moving windows around12:52
frinnstbut might have been my imagination12:53
juea complete rebuild of all installed packages just finished, the only issue I finally see is the gnulib/gets problem :)12:57
jaegernice :)12:57
*** pidsley has joined #crux-devel13:54
jaegerAnyone have a copy of the iso-codes distfile handy?14:27
jaegerfound it in romster's distfiles, nm14:29
frinnsthmpf. I need to roll a iso with an updated toolchain. running a btrfs / i have the feeling i'll need it :)14:50
frinnstunable to chroot with the old glibc on the iso14:50
jaegerdoh14:52
frinnstI wussed out: ext4 /boot and mbr14:54
frinnstno fancy new bootloader and uefi :(14:54
jaegerwell, it will work :)15:00
*** mike_k has quit IRC15:28
*** mavrick61 has quit IRC16:08
*** mavrick61 has joined #crux-devel16:08
*** mavrick61 has quit IRC21:26
*** joe9 has quit IRC21:26
*** mavrick61 has joined #crux-devel21:27
*** pidsley has quit IRC22:15
*** jue_ has joined #crux-devel23:05
*** jue has quit IRC23:07
*** jue_ is now known as jue23:08

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