ibotlog2html for #crosstool-ng

<< Previous 2016-06-10 Next >>

# 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

Generated by ibotlog2html by Yann E. MORIN