IRC Logs for #crux-devel Tuesday, 2013-02-12

juegood morning00:08
juejaeger: nss is a left-over from the 3.0->2.8 merge, I reported it to teK_ back then but he forgot it probably00:10
frinnstI maintain nss01:14
frinnstah, i see01:14
frinnstUSE_64=1 in 2.8?01:15
jueyeah, as I said, it comes from the wrong 3.0->2.8 merge01:27
teK_I forgot about nss. Sorry02:05
Romstereasy to overlook03:00
*** horrorSt1uck has joined #crux-devel05:47
jaegerno worries :) just wanted to check, I started building an x86 overlay last night06:08
jaegerDo any of you object to me deploying the pre-receive and post-receive hooks in ports/opt.git?06:14
teK_haven't looked into it yet06:14
teK_lftp update06:41
teK_fixed a configure problem with included regex.06:42
juejaeger: no, go for it ;)06:47
jaegerlooks like crux-commits is working again07:27
jaegerteK_: do you want me to wait for you to look over those hooks? frinnst and jue have checked them out, wanted to ask you as well before putting them in place07:43
teK_I trust you and jue07:47
jaegerI'm only going to put them in opt for now since that's where the mistake happened. If they do well we can copy them into the other repos07:48
*** sepen has joined #crux-devel08:52
sepenjaeger: where are the hooks you wrote?08:53
jaegerpre-receive blocks master pushes, post-receive does notifications08:53
sepenwhich one starts git-to-rsync?08:56
jaegerpost-update, I think. I'm not changing that one08:56
sepenpre-receive seems ok08:57
sepenthat should avoid pushing to erroneous branches08:57
jaegerI did quite a lot of testing of them on a local server, hopefully worked out any bugs08:57
jaegernotifies worked in my tests as well as failing master pushes. also fixed the revert bounces08:57
sepenjaeger: and about the email notification did you change anything relevant or keep the same body/subject way?08:58
jaegerI kept the formatting, just cleaned up the mail generation08:59
jaegerthe original perl script was just piping text into /usr/bin/mail, basically, and some unquoted stuff was causing problems08:59
sepencan be centralized those script in any way?09:01
jaegerWhat do you mean?09:01
sepenshare scripts between port repos09:02
jaegerpresumably they could be symlinked into the hooks dirs09:02
jaegerInitially I only want to test in opt just in case something's buggy still09:02
sepenyeah meant that09:02
jaegerjust to clarify, the current setup uses 2 hooks:09:03
jaegerer, 1 hook:09:03
jaegerargh, sorry, it is 209:03
sepen+ post-update who runs export_repo.sh09:03
jaeger1) update - to send email notifications09:03
jaeger2) post-update - to update rsync09:03
jaegermy changes will use 3:09:04
jaeger1) pre-receive - to block master push09:04
jaeger2) post-receive - to send email notifications09:04
jaeger3) post-update - to update rsync09:04
jaegerpost-update is not modified, I'm just replacing 'update' with 'pre-receive' and 'post-receive'09:04
sepenyeah, at least pre-receive can block errors09:05
jaegeryes :)09:05
sepenyou can write a better message like 'Ooga-Chaka Ooga Ooga Ooga-Chaka .. Baby, please don't push to master branch!!!'09:06
jaegerI could but I preferred the professional approach :P09:06
teK_you let quote from excuses.txt, right?09:07
sepenjaeger: about this part: '# get the git log for this commit and add it to the email's body'09:10
sepencan't be added only the url link?09:10
sepenI'm wondering on large footprint files09:11
teK_*cough* texlive *cough*09:11
teK_maybe a  | head $MAXLINES would to the job09:12
jaegerthat is a possibility, yes09:13
jaegersomething I could add later09:13
juebtw, I always use the -x option with git cherry-pick, think it's nice if we can see where a commit comes from09:33
juejaeger: what are your plans with the x86 overlay? Is there anything I can help?09:42
jaegerjue: no concrete plans yet, just started it to see how much work it might actually be because the server isn't 64-bit capable11:08 isn't 64b capable and our idea is to stay in production for a long time ;)11:10
sepenATM is running 2.8 inside a safe-crux enviroenment11:12
sepenwell I should go now, later11:12
jaegertake care11:12
*** horrorSt1uck has joined #crux-devel11:20
juejaeger: I've started something in the same direction and created a repo on github for now, see
juedone it for two reasons: a) curious to see how a user httpup-repo can be hosted on githup and b) is my nice old laptop ;)11:22
juebut if there is more interest in a i686 overlay I'd say we should host one on crux.nu11:23
jaegerok, I'll take a look :) you're probably further along than I, just started it last night11:24
jaegeryeah, yours is further ahead. I only had gcc, binutils, glibc, nss, and python so far11:25
juenot really, just copied some ports from our 2.8 branch11:25
jaegerthat's what I did as well, just making sure versions matched 3.0 :D11:28
frinnsthaving versions or release missmatching with an overlay repo is *annoying*11:34
juewhy is a matching release important?11:48
juefor example the python port: we did some additions on 3.0 that are useless on i686?11:50
jaegerJust to make keeping track of versions less work11:51
jaegerOtherwise you have to think of things like, "Ok, python in 3.0 is 2.7.3-3, in 2.8 it's 2.7.3-2. Is that -3 because of something big or just because we had to change a small thing for multilib?"11:52
jueok, so you would bump to -3 without the multlib extension?11:53
jaegeryes. That way if it got bumped to -4 I'd know I need to look at the overlay version just to make sure, feature-wise, they are the same11:54
jueok, make sense11:55
jueanother corner case is the ugly libthread-stubs thing, doing the update to version 0.3 in a running will break mostly everything11:57
jueI'd say that keeping version 0.2 is the most user friendly way here12:00
jaegerIt's the easiest but honestly I prefer to update and fix, myself :)12:01
jueyep, that's indeed cleaner, but to fix means more or less to rebuild everything12:03
jaegerI guess I just prefer forks to be as close to upstream as possible, only changing what's required12:03
jaegerI developed multilib with the same goal, really12:03
jueok, agreed12:05
jaegerWith that said I'm not trying to demean your work at all, just explaining where I get my weird ideas :D12:09
jueno no, that's ok, I didn't spend much time to think about the whole problem12:10
jaegerfair enough :)12:10
juebut, honestly, I tend to say that it's not worth the trouble12:13
jaegerI can understand that12:13
juewell, if the server on is a real problem, I'll donor for it12:14
pitillocould a jail help in those cases? rebuilding shouldn't be the hard part... maintenance is the harder one IMHO (here I have a nice laptop which cries a bit but I hope a long way ahead for it)12:16
jaegerI would also donate for it12:17
jaegerwell, a jail won't help run 64-bit on a 32-bit CPU12:17
juefrinnst: don't get it why, but the regexp patch is still missing from glibc.git12:39
teK_but lftp is fixed12:39
juenice, so the only broken port we know of is bind12:44
teK_it builds for me12:47
teK_just tested it12:47
juehmm, thought that someone has reported that?12:49
teK_that's why I tested *g*12:49
teK_mind trying?12:49
jueoops, got a footprint error for named.root12:53
teK_21:46 < cruxbot> [contrib.git/3.0]: bind: update named.root12:53
jaegerI'm going to activate the opt hooks now12:54
jaegerbeen pretty busy today12:54
teK_UH-OH ;)12:54
jueteK_: :)12:54
jaegerok, they're enabled12:54
frinnstjue, its just been pushed12:55
frinnsthm, commit looks a bit strange12:56
frinnst[new file with mode: 0644]12:56
teK_unit test12:58
teK_what's wrong with it?12:58
jueteK_: see it now, it's a unversioned download I had to delete first12:58
frinnstthe glibc bug was assigned CVE-2013-024212:59
teK_so I'd have to host it on or something12:59
frinnst<jue> well, if the server on is a real problem, I'll donor for it13:00
frinnstwhats wrong with the server?13:00
jueteK_: well, named.root is only 3k, I'd add it to the port, you have to update the md5sum anyway13:01
juefrinnst: nothing, but the serer is 32bit only13:01
juebut we are at 2.4 currently, so we have some time :)13:02
teK_you are right, jue13:03
frinnstwell as i've said before, I/we have hardware to host it if necessary13:03
frinnstproblem is its my employer. Dunno how long it would still be hosted if i were to quit tomorrow13:03
frinnstbut the previous guy I replaced still has his server hosted for free 2 years on13:04
teK_we could have a bunker-hosted sticker on the website then :>13:05
frinnstheh, yeah13:05
frinnstwe are having a film-crew down to do marketing stuff in a couple of months too :)13:06
teK_as I already said I want to take care of the backup thingy (finally) and then we could discuss upgrades13:06
teK_sneak our crux penguin in13:06
frinnsthonestly im sure the company would love to sponsor a project like crux13:07
jaegerfrinnst: is hosted at a university I left 4 years ago :)13:07
juehehe, that's cool :)13:07
jaegerI still talk to them frequently and at my current job we have some hardware in their datacenter, but even without that I imagine they'd let me leave it there13:08
teK_before deciding anything I propose to talk to charly first13:09
teK_but as I said, I want to fix the backup issues first13:09
frinnstyeah honestly I would be *very* surprised if my employer would throw out a crux box if I were to leave tomorrow. but i guess it would depend on what terms i were to leave on :)13:09
jaegerindeed :)13:09
teK_don't burn a thing13:09
frinnstrm -rf13:10
teK_that's almost nothing *g*13:10
teK_"I had to test our backups one last time"13:10
juefrinnst: are you going to apply the patch or shall I do it?13:35
*** mike_k has quit IRC13:57
frinnstI dont have the one from git ready14:17
jueok, will do it14:25
sepenglic-32 hehe14:54
*** joe9 has quit IRC14:55
*** joe9 has joined #crux-devel14:57
jueoops :)15:02
frinnstI have xrandr 1.4.0 brewing here, gonna let it sit for a while before i push15:04
jaegerdeus_ex: finally getting a chance to look at the nvidia bug you posted, not sure how I feel about it... because it'll change every time a new kernel is released16:10
*** joe9 has quit IRC16:33
*** joe9 has joined #crux-devel16:34
*** joe9 has quit IRC16:59
*** joe9 has joined #crux-devel17:01
*** sepen has quit IRC17:49
Romsterjust make new 2.8.1 iso or actaully a 3.0 i686 for the libpthread fix18:51
Romsterwith the i686 overlay on it.18:51
*** joe9 has quit IRC18:51
Romsteri asked about a i686 overlay a while ago, prologic was against it everyone else didn't think it was worth the effort.18:51
rmullI'm getting some weird output when building glibc and glibc-3218:55
rmullgcc: error: l2-cache-size=1024: No such file or directory18:55
rmullThat string there is one of my CFLAGS18:55
rmullSpecified as "--param l2-cache-size=1024" to be precise18:56
rmullperhaps those params were deprecated?18:56
rmullI get very specific with my CFLAGS because my CPU is not known by -march=native18:57
rmullI'll paste the log18:58
rmullMy full CFLAGS is CFLAGS="-O2 -march=x86-64 --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=1024 -mmmx -msse -msse2 -msse3 -mssse3 -mcx16 -msahf -pipe"18:59
Romsteroh i have noticed issues with glibc and some other tool chain ports jsut set the arch to x86_64 and i686 respectfully for glibc and glibc-3219:04
Romsterit's most likely the sse/sse2 stuff that's killing glibc19:05
Romsterwhat's that --param foo stuff19:06
Romstertry this19:09
RomsterCFLAGS="-O2 -march=x86-64 --param=l1-cache-size=64 --param=l1-cache-line-size=64 --param=l2-cache-size=1024 -mmmx -msse -msse2 -msse3 -mssse3 -mcx16 -msahf -pipe"19:10
Romsterrmull, ^19:10
rmullRomster: Thanks, good call. I'll try this.19:32
rmullStrange that it only broke recently, as I've been using those CFLAGS since 2.719:33
*** mavrick61 has quit IRC19:43
*** mavrick61 has joined #crux-devel19:44
Romsterdid adding the extra = in --param=l1-cache-line-size=64 fix that rmull ?19:44
Romsteryeah tool chains are strange things.19:44
rmullRomster: Yeah, that seems to have done the trick, thanks again.19:52
rmullNow just waiting for the build to finish :)19:52
*** joe9 has joined #crux-devel19:53
Romstercool, i'll have to remember that one.19:53
*** mike_k has joined #crux-devel22:55

Generated by 2.11.0 by Marius Gedminas - find it at!