| # 00:42:21 |
djerome |
joins #crosstool-ng |
| # 00:47:30 |
djerome |
quits : Remote host closed the connection |
| # 00:56:58 |
djerome |
joins #crosstool-ng |
| # 03:48:51 |
feepbot |
quits : Ping timeout: 256 seconds |
| # 03:50:36 |
feepbot |
joins #crosstool-ng |
| # 03:53:35 |
djerome |
quits : Remote host closed the connection |
| # 04:02:26 |
feepbot |
quits : Ping timeout: 246 seconds |
| # 04:03:17 |
feepbot |
joins #crosstool-ng |
| # 04:28:26 |
enunes |
quits : Read error: Connection reset by peer |
| # 04:38:43 |
enunes |
joins #crosstool-ng |
| # 06:34:12 |
diorcety |
joins #crosstool-ng |
| # 06:39:51 |
diorcety |
quits : Read error: Connection reset by peer |
| # 07:38:14 |
diorcety |
joins #crosstool-ng |
| # 08:07:54 |
mingwandroid_ |
quits : Read error: Connection reset by peer |
| # 08:17:14 |
voltagex |
bhundven: sorry, have been afk - I run Debian |
| # 09:08:24 |
smartin |
quits : Ping timeout: 276 seconds |
| # 09:33:24 |
smartin |
joins #crosstool-ng |
| # 12:50:53 |
Net147 |
joins #crosstool-ng |
| # 13:38:37 |
Net147 |
quits : Quit: HydraIRC -> http://www.hydrairc.com <- s0 d4Mn l33t |t'z 5c4rY! |
| # 16:05:37 |
bhundven |
voltagex: which version? Jessie, Sid, Wheezy? |
| # 16:43:53 |
diorcety |
quits : Quit: Leaving. |
| # 16:51:41 |
bhundven |
voltagex: I run debian, ubuntu, centos, and fedora. I've had no problems with ncurses at all. |
| # 16:52:03 |
bhundven |
voltagex: I'd start to think about what in your environment that is causing the issue. |
| # 17:19:56 |
diorcety |
joins #crosstool-ng |
| # 17:45:35 |
y_morin |
joins #crosstool-ng |
| # 17:47:05 |
bhundven |
y_morin: good evening! (morning here ;) ) |
| # 17:48:08 |
y_morin |
bhundven: Heyda! :-) |
| # 17:59:00 |
diorcety1 |
joins #crosstool-ng |
| # 18:02:11 |
diorcety |
quits : Ping timeout: 264 seconds |
| # 20:10:58 |
diorcety1 |
quits : Read error: Connection reset by peer |
| # 22:06:55 |
bhundven |
enunes: btw, I have had a task on my plate for a while, which is to come up with a way to do nightly/weekly build tests of the samples. |
| # 22:07:21 |
bhundven |
enunes: I don't have a lot of hardware, but there is always qemu-system- |
| # 22:09:53 |
bhundven |
enunes: the build test would be to do something kind of bootstrap-ish, like: 1) use a previous known working build of the sample to build buildroot for the target and boot it to qemu. 2) build latest crosstool-ng for the sample 3) use the latest build of crosstool-ng to build buildroot and run the test-suite 3) if it passes the test-suite, try running the |
| # 22:09:53 |
bhundven |
latest build of buildroot built with the latest ct-ng to make sure the ct-ng build worked. |
| # 22:10:12 |
bhundven |
I'm way open to suggestions |
| # 22:10:18 |
bhundven |
thoughs |
| # 22:10:20 |
bhundven |
flames |
| # 22:10:25 |
bhundven |
sarcasm |
| # 22:10:30 |
bhundven |
etc... |
| # 22:12:11 |
y_morin |
quits : Quit: Nighty Night! |
| # 22:23:53 |
enunes |
bhundven: hey, well I think that the idea is great, an additional thought that I have now is that it is possible to run only the tests which don't depend on target hardware, maybe doing this first would be an easier first step |
| # 22:24:37 |
bhundven |
right, I'd like both |
| # 22:24:43 |
bhundven |
but good first steps |
| # 22:25:15 |
enunes |
I've been running them but always with target hardware though |
| # 22:25:29 |
bhundven |
I mean, if we could... It would be nice to rsync the src/build to the target and run the test (make check for binutils for instance) |
| # 22:25:54 |
bhundven |
or make check for gmp or glibc |
| # 22:26:00 |
bhundven |
for instance |
| # 22:26:19 |
bhundven |
I have to bail for a bit, but I'll be back later |