| # 00:05:36 |
smartin |
quits |
| # 00:09:54 |
y_morin |
quits : Quit: Night! |
| # 00:42:36 |
bhundven |
is now known as: bhundven|afk |
| # 09:05:32 |
smartin |
joins #crosstool-ng |
| # 18:22:17 |
smartin |
quits |
| # 18:38:24 |
bhundven|afk |
is now known as: bhundven |
| # 18:42:26 |
y_morin |
joins #crosstool-ng |
| # 19:11:44 |
smartin |
joins #crosstool-ng |
| # 19:12:11 |
y_morin |
is now known as: y_morin|away |
| # 19:37:28 |
sh4rm4 |
quits : Ping timeout: 276 seconds |
| # 19:40:41 |
sh4rm4 |
joins #crosstool-ng |
| # 19:50:01 |
smartin |
quits : Ping timeout: 245 seconds |
| # 20:00:46 |
daggs1 |
joins #crosstool-ng |
| # 20:01:15 |
daggs1 |
y_morin|away, hello :) did you was the log I've posted? |
| # 20:02:25 |
y_morin|away |
is now known as: y_morin |
| # 20:03:10 |
y_morin |
daggs1: hey! Yes, I looked quickly yesterday evening. |
| # 20:03:29 |
y_morin |
daggs1: yet, I did not look too much in details, though, so I did not find the cause... |
| # 20:04:13 |
daggs1 |
ok, I assume you'd want the config.log right? |
| # 20:04:46 |
daggs1 |
what strikes me odd is that the config.log seems ok, e.g. finished succseffully |
| # 20:05:05 |
y_morin |
daggs1: can you check that you have the static version of ncurses on your system? |
| # 20:05:30 |
y_morin |
daggs1: you selected to build a static toolchain, so you need the appropriate .a libraries |
| # 20:06:00 |
y_morin |
daggs1: that's my initial guesstimate as to the cause of this issue. |
| # 20:08:04 |
y_morin |
daggs1: yes, the top-level config.log is OK, the issue occurs in a sub-dir (but which one is not obvious, due to parralelism) |
| # 20:08:30 |
daggs1 |
y_morin, I doubt ubuntu/fedora are shipping static versions of ncurses, is this a must? |
| # 20:09:37 |
y_morin |
daggs1: Yes, they do. Ubuntu has them in libncurses5-dev (or ibncursesw5-dev for the wide-chars version) |
| # 20:09:55 |
y_morin |
daggs1: For Fedora, it might be a similar package, ending in -dev or -devel, I think. |
| # 20:10:03 |
daggs1 |
mmm sec |
| # 20:10:19 |
y_morin |
daggs1: and yes, the static version must be installed if you want to build statically... |
| # 20:11:16 |
daggs1 |
I see, I'll ask at fedora's room, one sec |
| # 20:11:20 |
y_morin |
daggs1: canyou check if you have: /usr/lib/libncurses.a (or /usr/lib/libncursesw.a) |
| # 20:11:52 |
daggs1 |
y_morin, I'm not at work now so nope, I'll check tomorrow and post findings here. |
| # 20:12:03 |
y_morin |
daggs1: OK. |
| # 20:13:06 |
bhundven |
yea, there are seperate -static packages that are not installed when you install the -devel package on fedora |
| # 20:13:42 |
y_morin |
bhundven: hello! Thanks for the clarification! :-) |
| # 20:13:50 |
bhundven |
hey yann |
| # 20:13:51 |
daggs1 |
bhundven, what do I need to install to get static ncurses? |
| # 20:14:14 |
bhundven |
yum install ncurses-static |
| # 20:14:31 |
bhundven |
I don't have any fedora boxes right now though |
| # 20:14:33 |
bhundven |
to verify |
| # 20:14:46 |
y_morin |
bhundven: BTW, I applied two of your three patches. What's the status about eglibc, then? |
| # 20:14:56 |
bhundven |
I have a patch to submit |
| # 20:15:10 |
bhundven |
I'll send that today |
| # 20:15:23 |
y_morin |
bhundven: great! Thx. :-) |
| # 20:15:24 |
bhundven |
I have a bunch of patch queues |
| # 20:15:41 |
bhundven |
if only the patch I want to hg email is in qapplied |
| # 20:15:45 |
bhundven |
will it be the only one sent? |
| # 20:16:04 |
daggs1 |
bhundven, thanks, I'll try it in a few hours and report back |
| # 20:16:56 |
y_morin |
bhundven: yep: hg email --outgoing -> sends only changesets that are not present in the upstream repository. |
| # 20:17:37 |
bhundven |
k |
| # 20:34:17 |
bhundven |
btw, y_morin, I have gotten a ton of bounces when I email patches from your email address |
| # 20:34:35 |
y_morin |
bhundven: @anciens.enib.fr ? |
| # 20:34:40 |
bhundven |
yea |
| # 20:34:49 |
y_morin |
bhundven: this email is dead, I switched to @free.fr |
| # 20:34:55 |
bhundven |
ok |
| # 20:35:39 |
bhundven |
should probably update docs/C - Misc. tutorials.txt |
| # 20:35:53 |
y_morin |
bhundven: Yep, right. |
| # 20:37:28 |
bhundven |
emailed patch for eglibc-2.15 |
| # 20:38:24 |
y_morin |
Sigh... A lot of old emails to update through-out the code... :-/ |
| # 20:38:33 |
y_morin |
Time for a find + xargs! :-) |
| # 20:38:37 |
bhundven |
:D |
| # 20:38:38 |
y_morin |
bhundven: Thanks! |
| # 20:38:49 |
bhundven |
no problem! |
| # 20:39:07 |
y_morin |
bhundven: this is to be applied on-top of your previous one, or to replace it? |
| # 20:39:18 |
bhundven |
they are seperate changes |
| # 20:39:32 |
y_morin |
bhundven: OK. |
| # 20:39:47 |
bhundven |
one adds eglibc-2.15, and the other is a fix to not test __builtin_expect |
| # 20:40:31 |
y_morin |
bhundven: I'll coalesce the two patches into a single one, as eglibc-2.15 would be unusable without the patch, I guess... |
| # 20:41:14 |
bhundven |
right |
| # 20:41:17 |
bhundven |
that's fine with me |
| # 20:41:21 |
bhundven |
thanks yann |
| # 20:44:32 |
bhundven |
I have some idea's for fixing the multi-arch multilib configs, but I'm going to wait until you do your 'incoming build/host/target frontends' |
| # 20:46:15 |
y_morin |
bhundven: I also have an idea, too: always ask the multilib list to the core gcc. That requires that my candian-revamp is finished first, though. |
| # 20:46:29 |
y_morin |
bhundven: so, in the meantime, canadian+multilib is broken. |
| # 20:47:16 |
y_morin |
bhundven: never mind, I mixed up the latest canadian+multilib vs. your 32/64 issues... |
| # 20:48:39 |
y_morin |
bhundven: anyway, don't hold your beath, the MQ for the canadian revamp has been floating for 14 months, now... :-/ |
| # 20:48:46 |
y_morin |
*breath |
| # 20:49:48 |
y_morin |
bhundven: on a side note, in case you find it interesting: http://ymorin.is-a-geek.org/hg/kconfig-frontends/ |
| # 20:52:36 |
bhundven |
yea, I saw that |
| # 20:52:40 |
bhundven |
very cool |
| # 20:52:46 |
y_morin |
:-) |
| # 20:53:50 |
bhundven |
that'll help you keep in sync with kernel.org's kconfig |
| # 20:54:05 |
bhundven |
got a few projects I might make kconfig'urable |
| # 20:54:17 |
bhundven |
anyways, off to lunch |
| # 20:54:22 |
bhundven |
is now known as: bhundven|0xf00d |
| # 21:08:57 |
daggs1 |
quits : Quit: Leaving |
| # 21:29:31 |
y_morin |
is now known as: y_morin|away |
| # 21:50:01 |
bhundven|0xf00d |
is now known as: bhundven |
| # 22:21:59 |
y_morin|away |
is now known as: y_morin |
| # 22:34:21 |
bhundven |
http://www.cmcrossroads.com/bradapp/acme/branching/branch-creation.html |
| # 22:34:28 |
bhundven |
heh |
| # 22:36:44 |
bhundven |
I feel crazy when I've worked with multiple vcs's in one day |
| # 22:37:07 |
bhundven |
but it makes me feel good that I can use the same vcs patterns in all of them |
| # 22:38:52 |
y_morin |
bhundven: I disagree with C2 (Branch per task). Before merging back to '/devel_line', a first merge from '/devel_line' to the branch should be done, as solving conflicts on the branch is better than holding the 'trunk' /locked/ in the meantime. |
| # 22:39:14 |
y_morin |
bhundven: plus, regular nerges are important, especially for long-lived branches (more than a week). |
| # 22:39:24 |
bhundven |
true |
| # 22:40:01 |
y_morin |
bhundven: but yes, dissociating the 'process' from the 'tool' is a major point in any VCS solution. |
| # 22:40:52 |
bhundven |
yup, and it seems to me that each company I've worked for has used the same patterns, but like you said above with C2... may have different policies |
| # 22:40:53 |
y_morin |
bhundven: but globally, that pointer is a must read! Thanks! |
| # 22:41:00 |
bhundven |
yea |
| # 22:41:32 |
bhundven |
I was looking for something to point git newbies to, and figured it would be better to understand process then the tool |
| # 22:41:51 |
y_morin |
bhundven: I have the exact same issue here! :-) |
| # 22:43:12 |
y_morin |
I will probably need to set up some introduction to VCS in general, and the process we use, then introduce the tool (undecided yet, 50% git 50% hg). |
| # 22:43:31 |
bhundven |
I like hg for this project |
| # 22:43:46 |
bhundven |
mq is so much nicer then stash |
| # 22:44:06 |
y_morin |
bhundven: but even before you introduce people to VCS, you have to instruct people *why* VCS is a good thing, and that, *no*, it's not wasted time. |
| # 22:44:20 |
y_morin |
bhundven: yes, MQ is, IMHO, the best selling point of hg. |
| # 22:45:00 |
y_morin |
Plus, hg syntax is very straight forward (for people coming fom, eg. svn). |
| # 22:45:18 |
bhundven |
it's slightly confusing coming from git |
| # 22:45:29 |
bhundven |
but after you figure it out, it rocks |
| # 22:45:38 |
bhundven |
I just haven't been able to use hg for large projects |
| # 22:45:58 |
y_morin |
Man, git is awfull... Want to see the delta between two cset, use 'diff'. Want to see the delta of a single cset, use 'show'. Man, what the heck?... :-( |
| # 22:46:10 |
bhundven |
lol |
| # 22:46:15 |
y_morin |
:-) |
| # 22:46:20 |
bhundven |
seriously |
| # 22:46:46 |
bhundven |
or: git log -p |
| # 22:46:57 |
y_morin |
Yes, the git->hg transition may get a bit frustrating. But the other way around is, too. |
| # 22:47:07 |
bhundven |
yup |
| # 22:47:14 |
bhundven |
I can imagine |
| # 22:48:25 |
y_morin |
bhundven: no, 'log -p cset' prints the log from that cset to HEAD, not only of _that_ cset. |
| # 22:48:39 |
y_morin |
Plus, if you just need the diff (for whatever post-processing), log -p gives you the log message,too. |
| # 22:49:43 |
y_morin |
Anyway, git is like any other tool. Once one knows his ways with it, it gets easy. It;s just that the learning curve is steeper than with any other VCS tool I used. |
| # 22:56:26 |
bhundven |
yea |
| # 23:00:09 |
bhundven |
is now known as: bhundven|mtg |
| # 23:41:11 |
bhundven|mtg |
is now known as: bhundven |