| # 03:49:53 | trigg | joins #crosstool-ng |
| # 03:50:03 | trigg_ | quits : Ping timeout: 240 seconds |
| # 03:53:32 | trigg_ | joins #crosstool-ng |
| # 03:54:14 | trigg | quits : Ping timeout: 244 seconds |
| # 05:54:50 | diorcety | joins #crosstool-ng |
| # 06:12:24 | diorcety | quits : Read error: Connection reset by peer |
| # 06:55:42 | lundmar | joins #crosstool-ng |
| # 08:41:03 | jyelloz | quits : Ping timeout: 276 seconds |
| # 09:21:25 | jyelloz | joins #crosstool-ng |
| # 09:49:23 | ragedragon | joins #crosstool-ng |
| # 10:56:47 | ragedragon | quits : Ping timeout: 260 seconds |
| # 12:20:54 | Net147 | quits : Read error: Connection reset by peer |
| # 12:24:48 | Net147 | joins #crosstool-ng |
| # 12:58:44 | lundmar1 | joins #crosstool-ng |
| # 12:58:44 | lundmar | quits : Read error: Connection reset by peer |
| # 14:00:22 | blueness | quits : Quit: blueness |
| # 14:02:16 | blueness | joins #crosstool-ng |
| # 14:15:41 | blueness | quits : Quit: blueness |
| # 14:16:16 | blueness | joins #crosstool-ng |
| # 14:31:32 | blueness | quits : Quit: blueness |
| # 14:32:34 | blueness | joins #crosstool-ng |
| # 14:36:00 | lundmar1 | is now known as: lundmar |
| # 15:59:11 | y_morin | joins #crosstool-ng |
| # 16:06:14 | bhundven | joins #crosstool-ng |
| # 16:06:19 | bhundven | y_morin: hello |
| # 16:18:10 | blueness | quits : Quit: blueness |
| # 16:20:41 | blueness | joins #crosstool-ng |
| # 16:48:53 | blueness | quits : Quit: blueness |
| # 16:51:26 | blueness | joins #crosstool-ng |
| # 18:16:12 | enunes | quits : Ping timeout: 240 seconds |
| # 19:00:53 | diorcety | joins #crosstool-ng |
| # 20:21:19 | blueness | quits : Quit: blueness |
| # 20:32:49 | lundmar | damnit, ct-ng travis-ci builds faster than my own machine. This is not good ^^ |
| # 20:41:28 | bhundven | heh |
| # 20:42:26 | bhundven | y_morin: are you avail? |
| # 20:45:44 | lundmar | bhundven: just pushed a oneline pull request in your general direction that you probably wanna merge and close ;) |
| # 20:48:01 | y_morin | bhundven: Hey! I am now. |
| # 20:48:22 | bhundven | y_morin: hello! :) |
| # 20:49:11 | bhundven | y_morin: I was wondering (as aneyman__ has...) if/when you would have some cycles to finish the multilib[#383] PR review? |
| # 20:49:48 | y_morin | bhundven, aneyman__: Not sure when I can look at it again... :-/ |
| # 20:50:25 | bhundven | y_morin: ok, could you point me to the commit you left off on, so that I can focus on the remaining commits? |
| # 20:50:37 | y_morin | I'm sorry about that. I find the topic quite complex, and since I'm not directly interested in multiarch/multilib, forcing myself to look at it is not really easy... :-/ |
| # 20:50:50 | bhundven | y_morin: totally understand |
| # 20:51:16 | y_morin | bhundven: And TBH, I find using github to do the review to be less than optimum (commits are not even ordered in commit-order...) |
| # 20:51:20 | bhundven | y_morin: I was hoping that mingwandroid would of had time to review this as well, since he and I wrote the original work |
| # 20:51:41 | bhundven | y_morin: I also dislike github's review process/tooling |
| # 20:52:02 | lundmar | reviewable.io ^^ |
| # 20:52:08 | bhundven | lundmar: I hated it |
| # 20:52:10 | y_morin | bhundven: I can try to have a look in a few minutes, but I'll simply give an overall "feeling" on the series. |
| # 20:52:25 | bhundven | y_morin: ok :) |
| # 20:53:01 | bhundven | lundmar: more specifically, the UI/UX wasn't compatible with my brain :) |
| # 20:53:08 | lundmar | bhundven: that pull request is the first time I saw reviewable.io and I agree - there is something off about it. |
| # 20:53:19 | blueness | joins #crosstool-ng |
| # 20:53:24 | lundmar | reviewninja might be better choice |
| # 20:53:33 | bhundven | lundmar: thanks. I look into it |
| # 20:59:58 | lundmar | I also agree with y_morin, multilib is troublesome. It might not be worth the added complexity or maintenance cost. I think most people use ct-ng to specifically optmize their toolchain for each arch so multiarch often becomes a mute point. However, some users obviously finds it useful. |
| # 21:00:49 | ragedragon | joins #crosstool-ng |
| # 21:02:17 | y_morin | lundmar: Yes, when I was maintraining it, my goal was to be able to build a toolchain optimised for a specific target. Hence multilib (and later multiarch) were not really into the equation. |
| # 21:02:37 | lundmar | nods |
| # 21:02:49 | y_morin | And given the size of storage these days, having a toolchain per target is really a no-brainer. |
| # 21:03:04 | lundmar | little cost that is yes |
| # 21:06:04 | lundmar | y_morin: are you still interested in build systems? I remember you once did a note comparing various build tools ;) |
| # 21:07:16 | y_morin | lundmar: Well, I would not contribute to Buildroot if I were not! ;-) |
| # 21:07:21 | lundmar | hehe |
| # 21:07:40 | y_morin | (and that note was really a loooong time ago, before Buildroot is in the shape it is today) |
| # 21:07:57 | lundmar | I know ^^ |
| # 21:08:06 | lundmar | y_morin: anyway, you might wanna add http://buildgear.io to the comparison ;) |
| # 21:08:30 | lundmar | I remember reading your note back then and I couldn't agree more with it hehe |
| # 21:08:34 | aneyman__ | bhundven, y_morin: well, then stop pretending like ct-ng supports multilib and just drop that config option completely |
| # 21:08:48 | y_morin | But I found that Buildroot was really looking to go the way I wanted to go, and is going the way I want to go, so I simply ditched the idea I had to come up with yet-another... ;-) |
| # 21:08:55 | aneyman__ | because currently it breaks more often than works |
| # 21:09:03 | lundmar | so I kind of made my own take on a simple build tool, buildgear - for fun. |
| # 21:09:57 | lundmar | y_morin: well, given the choice between buildroot and anything OE based I would pick buildroot any day |
| # 21:10:11 | aneyman__ | in the current state, it is effectively only supported for baremetal and the flavors of libc that are inherently multilib (think avr-libc) |
| # 21:10:35 | lundmar | however, both buildroot and OE based is troublesome if you want to do small and quick from scratch with clean meta |
| # 21:23:14 | y_morin | aneyman__: Hello! I certainly understand your frustration. I'm sorry about that. :-( |
| # 21:23:52 | y_morin | aneyman__: Fact is, reviewing takes a lot of time, especially on a topic I am not at ease with, and not entirely interested in. |
| # 21:25:13 | y_morin | aneyman__: I certainly understand that this is something you *are* interested in (or you would probably not have worked so hard on it!). |
| # 21:26:02 | y_morin | aneyman__: Yet, I'm doing that at home, in my sapre time, with various priorities all ontending for that spare (very spare!) time. |
| # 21:27:25 | y_morin | Ditto for bhundven; that's also a hobby activity for him. |
| # 21:28:18 | y_morin | Yes, it takes time for complex stuff to get in (eh, I even have series against Buildroot that I've started three years ago, and are not entirely upstream yet!) |
| # 21:28:29 | aneyman__ | y_morin: I understand that - but let's be honest, at the current rate it is not going to be ever reviewed |
| # 21:29:34 | y_morin | aneyman__: Then maybe because not many people are interested in it... (but yes, the ct-ng comunity is rather small...) |
| # 21:30:08 | y_morin | aneyman__: I'm not sure what to say. I'm really sorry that this has not lived to your expectation, and I can understand the frustration. |
| # 21:30:23 | aneyman__ | y_morin: so the choice here is (1) to just stop pretending ct-ng has any notion of multilib support (I can understand that - we'll find another way to do that), (2) do a cursory glance with a testing that it does not break anything or (3) speed up the review |
| # 21:30:34 | aneyman__ | just pick any of the three |
| # 21:31:11 | y_morin | aneyman__: You are probably right. I just have something else to suggest: |
| # 21:32:10 | y_morin | aneyman__: When doing complex series, from experience, it was much faster to go with short series of simple changes (e.g your initial changes) rather than a big and long series with a lot of complex patches. |
| # 21:32:37 | y_morin | aneyman__: A long series get the maintainer and reviewers all go like "Damn, this will be difficult!" |
| # 21:32:37 | aneyman__ | y_morin: we already went through this discussion |
| # 21:32:56 | aneyman__ | when I started this multilib work, more than 50% of ct-ng samples were not building |
| # 21:32:57 | y_morin | aneyman__: While a short series has more chances to get reviewd faster. |
| # 21:33:19 | aneyman__ | look up the "fix ct-ng samples" branch to get what I am doing |
| # 21:33:49 | aneyman__ | and even that branch - which didn't bring *ANY* new features, just restoring the status quo - took more than two months to merge |
| # 21:34:16 | aneyman__ | so what was I supposed to do during that time? of course, that meant that the multilib stuff kept accumulating on another branch |
| # 21:35:41 | y_morin | I understand... I don't have much solution, unfortunately... :-/ |
| # 21:35:43 | aneyman__ | and as a cherry on the cake - I already did that pass to restore the samples before - around last fall |
| # 21:36:25 | aneyman__ | but the merges of other branches just broke them - looks like the merges were not tested beyond from the samples built by travis-ci |
| # 21:36:53 | aneyman__ | e.g. new gdb, new uclibc, new gcc all broke one or more samples |
| # 21:37:12 | aneyman__ | I understand that 'ct-ng build-all' takes about 30 hours |
| # 21:37:23 | aneyman__ | but that's something that can be done at least weekly |
| # 21:40:39 | y_morin | An I guess travis is there for that, no? |
| # 21:41:30 | aneyman__ | travis builds only 5 or 6 samples |
| # 21:42:26 | aneyman__ | ok, it's 9 now |
| # 21:42:40 | y_morin | Ah, otherwise the build time is too long and the build is killed, right? |
| # 21:42:40 | aneyman__ | of which 5 are arm-based |
| # 21:43:15 | aneyman__ | no, it does not get killed as each sample is considered a separate build - so in finishes within the limit |
| # 21:44:53 | y_morin | bhundven: Any reason why you did not set up a travis build for each samples, and only a subset? |
| # 21:45:13 | bhundven | build time |
| # 21:47:02 | y_morin | bhundven: But if each sample is build as its own job, there is no time limit that would fail the build, is there? |
| # 21:47:16 | aneyman__ | https://travis-ci.org/crosstool-ng/crosstool-ng/builds/86550894 |
| # 21:47:23 | y_morin | bhundven: E.g. with Buildroot, our travis bot builds all our defconfigs. |
| # 21:47:26 | bhundven | there is a limit to the number of workers we get |
| # 21:47:27 | aneyman__ | that was our try to build all :) |
| # 21:47:37 | aneyman__ | since then, the number of samples doubled |
| # 21:47:43 | bhundven | more workers means we need to get a paid account |
| # 21:47:52 | bhundven | I don't have the resources for that |
| # 21:48:07 | aneyman__ | well maybe not doubled but still increased |
| # 21:48:34 | bhundven | I try to get a cross-section of samples that exercise ct-ng's features |
| # 21:49:00 | bhundven | while also not making contributors wait 2 days to test a PR |
| # 21:49:30 | bhundven | (or to wait a day to find out they misspelled a variable name) |
| # 21:49:59 | aneyman__ | bhundven: the latter should be something contributors find out in their own testing |
| # 21:50:12 | aneyman__ | before they even submit a pull request |
| # 21:50:22 | bhundven | you'd be surprised |
| # 21:50:28 | bhundven | :P |
| # 21:50:46 | aneyman__ | by not testing it, you're substituting it with "let's not tell contributors they misspelled a variable" :P |
| # 21:51:00 | y_morin | bhundven: I don't understand the "worker" issue. For Buildroot we have this: https://travis-ci.org/buildroot/buildroot-defconfig-testing/builds/136281896 <- notice: Total time more than 24 hrs |
| # 21:51:24 | y_morin | bhundven: And it's not a paid account. |
| # 21:51:26 | bhundven | hey, I mean if we want to run all the samples, by all means |
| # 21:51:39 | y_morin | You may only get two builds in aprallel, but the number of builds is not limited. |
| # 21:51:43 | bhundven | I don't *really* have a horse in that race |
| # 21:51:49 | bhundven | I just ride the horse |
| # 21:51:59 | bhundven | s/the/a/ |
| # 21:52:35 | y_morin | bhundven: Anyway, just merge the first four commits of the series. I've already reviewed it. |
| # 21:52:46 | y_morin | *them |
| # 21:52:58 | bhundven | y_morin: and that is the other problem with github |
| # 21:53:06 | bhundven | y_morin: the pull request is all of the commits |
| # 21:53:11 | y_morin | bhundven: Yes, that is really annoying. |
| # 21:53:38 | y_morin | bhundven: But don't come telling me you can't do a git fetch and a git cherry-pick locally! ;-) |
| # 21:53:46 | y_morin | Hehe! ;-) |
| # 21:53:48 | bhundven | I'm about a few more pain points from saying F#*K IT and going back to patchwork |
| # 21:54:08 | bhundven | since patchwork has improved a lot |
| # 21:54:28 | bhundven | and github is kind of useful, but super annoying |
| # 21:54:32 | lundmar | my recent pull request just finished travis-ci (9 samples) in 50 minutes, not too bad for a free cloud service. |
| # 21:54:50 | bhundven | lundmar: then add multilib and all of the other samples |
| # 21:55:03 | lundmar | ehhh, make that 99 minutes. |
| # 21:55:11 | bhundven | or more... |
| # 21:55:13 | aneyman__ | hey, I am ok with dropping arm-multilib :) |
| # 21:55:20 | aneyman__ | that was more of a proof-of-concept thing |
| # 21:55:34 | bhundven | aneyman__: I have no problem keeping it, really. It *might* change over time. |
| # 21:55:34 | aneyman__ | I know that sample alone builds for ~120 minutes :) |
| # 21:55:39 | lundmar | 30 samples would be about 300 minutes or so |
| # 21:56:02 | lundmar | depends on the load ofc |
| # 21:56:10 | y_morin | bhundven: Fifth patch is also OK to go. |
| # 21:56:17 | aneyman__ | --with-multilib-list=aprofile has 28 multilib configurations :) |
| # 21:57:18 | y_morin | bhundven: Sixth is OK too. |
| # 21:57:36 | y_morin | bhundven: So for now: 1 through 6: you can cherry-pick! ;-) |
| # 21:58:14 | bhundven | ok, I'm at work right now, and will be for a few more hours |
| # 21:58:15 | lundmar | remember, github pull requesting is an optional feature ^^ |
| # 21:58:42 | y_morin | bhundven: BTW, I'm speakign about commit ordering in the repository, not the list on github (in case that was not clear) |
| # 21:58:56 | y_morin | bhundven: Oh, sure! |
| # 21:58:56 | bhundven | lundmar: true, I can manually merge, but then I need aneyman__ to rebase and force push his work to update the PR with the rest of the changes |
| # 21:59:10 | y_morin | bhundven: I tend to forget about timezones... |
| # 21:59:33 | y_morin | bhundven: Yep, rebasing is often a pain-point... |
| # 21:59:44 | bhundven | just keep posting stuff here, I'll look at the ctngbot logs later. |
| # 21:59:51 | aneyman__ | y_morin: you can tell me how far you went, I'll create a separate branch with 1..X commits |
| # 22:00:11 | aneyman__ | not a big deal, that's how I lived with multlib branch on top of fix-samples branch :) |
| # 22:00:30 | aneyman__ | just tell me what the last reviewed commit is (i.e., the value of X) |
| # 22:01:57 | y_morin | aneyman__: OK, I'll continue a little review, and when I stop, I'll tell both you and bhundven the value of X. |
| # 22:15:50 | y_morin | aneyman__: OK, 1 through 10 are OK to go. Just minor nits that should not bar them from being applied, I guess. |
| # 22:15:53 | y_morin | bhundven: ^^^ |
| # 22:16:01 | y_morin | And now, sleep... |
| # 22:16:12 | y_morin | quits : Quit: Nighty Night! |
| # 22:23:15 | aneyman__ | bhundven: https://github.com/crosstool-ng/crosstool-ng/pull/403 |
| # 22:23:28 | aneyman__ | running through travis-ci right now |
| # 22:23:49 | bhundven | ok, I'm at work right now, and will be for a few more hours |
| # 22:23:57 | bhundven | just keep posting stuff here, I'll look at the ctngbot logs later. |
| # 22:23:59 | bhundven | :) |
| # 22:24:38 | aneyman__ | ok |
| # 22:25:02 | aneyman__ | mind if I'll start addressing Yann's comments on top of the existing changes? |
| # 22:25:23 | bhundven | sure |
| # 22:25:28 | aneyman__ | I am tired of rebasing them down to the commit that actually made that change |
| # 22:25:51 | aneyman__ | especially in the cases where the corresponding code moved a few times or does not even exist in HEAD |
| # 22:26:19 | bhundven | aneyman__: I am researching solutions to github, we may end up going to emailing PRs and using patchwork. I'm also not very happy with github's review process and management |
| # 22:26:43 | bhundven | but as lundmar mentioned, there are some external review tools that work with github that I have not looked at yet |
| # 22:27:11 | bhundven | but it is what we have now, painfully... |
| # 22:27:58 | aneyman__ | I am fine with it either way - whether we stay with github or move to something else |
| # 22:28:15 | aneyman__ | the biggest issue with GH is the disappearing comments during the rebase |
| # 22:28:53 | aneyman__ | but it seems that did something to address that - is the "made a comment on an outdated diff" the indicator that the original comment commented upon was rebased? |
| # 22:31:10 | lundmar | I think you will have a hard time finding something which is easier for devs to access than github. |
| # 22:34:40 | bhundven | lundmar: easy to access doesn't always mean that it matches your workflow |
| # 22:34:46 | bhundven | or improves it to that fact |
| # 22:35:58 | bhundven | I know a few people that used to contribute to ct-ng stopped when we moved to github, because they didn't want to create a github account |
| # 22:36:36 | lundmar | true, but still github is to git what fb is to social media. Just saying - if you want users to contribute github makes it easier for them. |
| # 22:36:50 | lundmar | hehe, the opposite argument can be made |
| # 22:36:56 | bhundven | indeed |
| # 22:37:41 | bhundven | well, I need to bail so I can get work done so I can go home and review changes, or else I will have to go home and go back to work. |
| # 22:37:48 | bhundven | quits : Quit: ttyl! |
| # 22:51:31 | diorcety | quits : Read error: Connection reset by peer |