| # 00:01:17 | codyps | quits : Ping timeout: 252 seconds |
| # 01:48:52 | bhundven|afk | is now known as: bhundven |
| # 03:16:20 | bhundven | is now known as: bhundven|afk |
| # 04:59:24 | alan_o | quits : Quit: Leaving |
| # 05:06:51 | codyps | joins #crosstool-ng |
| # 05:39:28 | sspiff | quits : Ping timeout: 252 seconds |
| # 06:44:38 | smartin_ | joins #crosstool-ng |
| # 06:59:31 | sfan5|OFF | is now known as: sfan5 |
| # 07:22:45 | sspiff | joins #crosstool-ng |
| # 07:22:45 | sspiff | quits : Changing host |
| # 07:22:45 | sspiff | joins #crosstool-ng |
| # 07:22:47 | sspiff | quits : Remote host closed the connection |
| # 07:34:33 | sh4rm4 | quits : Ping timeout: 276 seconds |
| # 07:38:51 | sspiff | joins #crosstool-ng |
| # 07:43:09 | sh4rm4 | joins #crosstool-ng |
| # 08:01:38 | sspiff | quits : Remote host closed the connection |
| # 08:10:52 | aaribaud | quits : Ping timeout: 245 seconds |
| # 08:13:39 | sspiff | joins #crosstool-ng |
| # 08:17:53 | y_morin | joins #crosstool-ng |
| # 08:36:45 | aaribaud | joins #crosstool-ng |
| # 09:21:25 | Net147 | joins #crosstool-ng |
| # 11:16:14 | Net147 | quits : Quit: HydraIRC -> http://www.hydrairc.com <- Like it? Visit #hydrairc on EFNet |
| # 12:05:30 | ssspiff | joins #crosstool-ng |
| # 12:05:51 | sspiff | quits : Ping timeout: 246 seconds |
| # 12:10:15 | al` | quits : Ping timeout: 256 seconds |
| # 12:14:18 | al` | joins #crosstool-ng |
| # 12:35:27 | smartin_ | quits : Read error: Operation timed out |
| # 12:40:57 | smartin_ | joins #crosstool-ng |
| # 13:02:12 | ssspiff | quits : Ping timeout: 246 seconds |
| # 13:02:15 | sspiff | joins #crosstool-ng |
| # 15:25:38 | Kasreyn | quits : Read error: Connection reset by peer |
| # 15:32:08 | y_morin | quits : Quit: Going home... |
| # 16:52:27 | sfan5 | is now known as: sfan5|OFF |
| # 16:52:30 | sfan5|OFF | is now known as: sfan5 |
| # 16:59:42 | y_morin | joins #crosstool-ng |
| # 17:11:16 | smartin_ | quits : Quit: heading home |
| # 17:16:18 | sh4rm4 | quits : Ping timeout: 276 seconds |
| # 17:37:06 | sh4rm4 | joins #crosstool-ng |
| # 21:00:08 | y_morin | bhundven|afk: Hello there? |
| # 21:13:38 | sfan5 | is now known as: sfan5|OFF |
| # 21:45:36 | bhundven|afk | y_morin: heh, just got in |
| # 21:45:40 | bhundven|afk | is now known as: bhundven |
| # 21:46:15 | y_morin | bhundven: Have you seen the recent "custom location" patch series for all components? |
| # 21:46:29 | bhundven | I took quick glance, but nothing detailed |
| # 21:47:01 | y_morin | bhundven: Recently, you've added "gcc from svn". Do you think that would be covered by "custom location" instead? |
| # 21:47:08 | bhundven | yes |
| # 21:47:30 | bhundven | I'm gonna take a little bit of time and work on the CT_Get stuff |
| # 21:47:33 | bhundven | in that |
| # 21:47:44 | y_morin | bhundven: I see that "custom location" as some sort of "I am developping that component, just use my own local changes, for ${DEITY}'s sake". |
| # 21:47:47 | bhundven | I will remove the svn thing and move it to the new CT_Get interface |
| # 21:48:19 | y_morin | bhundven: I was thinking of removing the "gcc form svn" code path, for the above reason. |
| # 21:48:27 | bhundven | sure |
| # 21:48:37 | bhundven | that totally makes sense |
| # 21:48:59 | y_morin | bhundven: If a non-developper wants to use a gc from svn, it would be his/her responisibility to check it out first, then use "custom location" |
| # 21:49:06 | y_morin | gc --> gcc |
| # 21:49:09 | bhundven | right |
| # 21:50:06 | y_morin | bhundven: So, you agree that, if I strip it off, the "custom location" fills your use-case? |
| # 21:50:29 | bhundven | david and I both seem to agree on a view that ct-ng has another use-case for toolchain integrators. Such that, I might have an existing source base with changes to components like gcc, binutils, etc... |
| # 21:50:50 | bhundven | it is definitely not for non-developers |
| # 21:51:17 | bhundven | I actually propose a CT_DEVELOPER config option under CT_EXPERIMENTAL |
| # 21:51:22 | y_morin | bhundven: Sure. I never envioned it this way, but if users fidn it usefull for that, then all the better! :-) |
| # 21:51:47 | bhundven | but I'm not sure your view on that |
| # 21:51:53 | bhundven | sure |
| # 21:52:55 | bhundven | just so that toolchain developer options are seperated from what may be considered experimental |
| # 21:53:13 | bhundven | as a user may want experimental options, but not developer options |
| # 21:53:36 | y_morin | bhundven: I would prefer we not have yet another hidding option. We already have OBSOLETE and EXPERIMENTAL. I guess EXPERIMENTAL conveys the proper meaning: it's experimental, either in ct-ng itself, or in a component. |
| # 21:53:51 | bhundven | i c |
| # 21:54:11 | bhundven | and really, a lot of what is under experimental mostly says it hasn't been tested |
| # 21:54:14 | y_morin | bhundven: but maybe the help text for EXPERIMENTAL needs updating, then. |
| # 21:54:24 | y_morin | yep. |
| # 21:54:43 | bhundven | so many things I want to contribute to ct-ng, so little time... |
| # 21:54:44 | bhundven | :p |
| # 21:54:59 | y_morin | bhundven: have you seen Johannes' debug-shell feature? It is a neat litle trick! ;-) |
| # 21:55:33 | bhundven | no. I just got back from talking with a recruiting/consulting agency and have been dealing with that kind of stuff for the last week |
| # 21:55:37 | bhundven | I'll take a peek |
| # 21:56:32 | y_morin | bhundven: when a command fails, it spawns a shell with the current environment variables, and allows you to fix up things, then {resume,re-run,abort} |
| # 21:57:02 | bhundven | ah, nice! |
| # 21:57:03 | y_morin | bhundven: how did things go with the startup thingy? |
| # 21:57:32 | bhundven | still waiting for the funding to go through. but when we talk with them, they are really excited. |
| # 21:57:49 | bhundven | sounds like it will be at most a month away |
| # 21:57:55 | bhundven | :D |
| # 21:57:58 | y_morin | Good thing for you! :-) (except you'll get less time for ct-ng... ;-] ) |
| # 21:58:07 | bhundven | I hope not |
| # 21:58:39 | bhundven | I'm actually hoping that my part for the startup should be fairly trivial |
| # 21:58:44 | y_morin | crosses fingers for both outcomes (job + time for ct-ng! :-) ) |
| # 21:59:05 | bhundven | "get servers up, deal with the fall-out of applications doing bad things." |
| # 21:59:56 | y_morin | Well, that can be a challenge, if uptime is a high-risk constrain. |
| # 22:00:29 | bhundven | hybrid cloud based, with some scaling things that need some minor tuning |
| # 22:02:12 | bhundven | I'm hoping to get back to my personal project with the car stuff |
| # 22:02:29 | bhundven | sooner if I can be a rockstar and pound this startup stuff out |
| # 22:04:05 | y_morin | ;-) |
| # 22:04:55 | bhundven | I've been looking at directfb, buildroot and yocto project, and ct-ng... and twittling my fingers... chanting... "soon..." |
| # 22:05:07 | bhundven | :D |
| # 22:05:35 | bhundven | but I'm also looking at wayland |
| # 22:05:38 | bhundven | instead of directfb |
| # 22:06:22 | bhundven | http://wayland.freedesktop.org/ |
| # 22:11:11 | bhundven | I really need a timemachine |
| # 22:11:17 | bhundven | so i can just stop time and code |
| # 22:11:44 | bhundven | forget about going forwards/backwards in time. Just stop. |
| # 22:15:59 | y_morin | bhundven: I know the feeling! |
| # 22:18:02 | y_morin | wrt wayland: I'm a bit skeptic. The idea is good. I didn't see the code, but there's no reson it can't be good. The issue I see is about migrating all the existing (even if there's an Xserver on-top). |
| # 22:18:13 | y_morin | reson --> reason |
| # 22:18:56 | y_morin | There is a lot of inertia all over the place, so much that the migration can take years, if not decades. |
| # 22:19:25 | bhundven | I don't think that is the goal. I think it's to cut the xserver api/abi in half. The technology of X11 is mostly wasted on desktops and laptops. I would never have multiple xdmc sessions on my laptop for instance. |
| # 22:19:40 | bhundven | xdmcp |
| # 22:19:41 | bhundven | eh |
| # 22:19:46 | bhundven | so many acronyms |
| # 22:19:59 | y_morin | bhundven: Ah, the network-transparency! I for one tend to have a few of them. |
| # 22:20:08 | bhundven | for a server, it makes sense |
| # 22:20:16 | bhundven | and that's why you'd run x11 on wayland |
| # 22:20:26 | bhundven | but for an embedded project |
| # 22:20:41 | bhundven | just wayland and a custom gtk/kde interface could be sufficient |
| # 22:20:57 | bhundven | no x11 overhead |
| # 22:21:08 | bhundven | just straight kms/fb access |
| # 22:21:17 | y_morin | bhundven: not only for servers. I have a bunch of desktop machines which I do not want to attach a display to each, so I login via XDMCP from my main machine. XDMCP in Xnest, for that matters. |
| # 22:21:30 | bhundven | ah, yea. |
| # 22:21:34 | y_morin | bhundven: yep, on specialised setups such as embedded, it makes sense. |
| # 22:21:40 | bhundven | yes. |
| # 22:21:58 | bhundven | I don't think many people with your use-case or servers would move to this |
| # 22:22:14 | bhundven | embedded/mobile otoh |
| # 22:22:29 | bhundven | and directfb is a direct competitor |
| # 22:22:37 | bhundven | ...directly... :p |
| # 22:22:48 | bhundven | lol |
| # 22:23:14 | y_morin | bhundven: for Joe Random User on his laptop to edit spreadsheets, show pictures to Grandma, send mails and play games, yes, wayland is the way to go. |
| # 22:23:21 | y_morin | bhundven: lol! ;-) |
| # 22:23:32 | bhundven | yup |
| # 22:23:51 | bhundven | yea, all the need for user-space server drivers |
| # 22:24:08 | bhundven | could be elimnated by just having applications draw to the framebuffer |
| # 22:24:18 | bhundven | through wayland or directfb |
| # 22:24:59 | bhundven | and with the nouveau and open source ati stuff getting squared away |
| # 22:25:02 | bhundven | it's a good time |
| # 22:25:16 | bhundven | to get away from that driver model |
| # 22:25:31 | bhundven | less package dependencies |
| # 22:25:35 | y_morin | I haven't followed wayland too much, but would it be possible to 'tunnel' a remote frambuffer through a VNC-like connection (eg. with comporession, and stuff like that) ? |
| # 22:25:45 | bhundven | :/ idk |
| # 22:25:51 | y_morin | bhundven: yep, kill the NVidia binary blob! ;-) |
| # 22:25:58 | y_morin | hides... |
| # 22:26:00 | bhundven | hehe |
| # 22:26:29 | y_morin | Well, back to some coding... |
| # 22:26:34 | bhundven | indeed |
| # 22:26:50 | bhundven | I'll take some time tonight to get back to the ct_get |
| # 22:26:58 | bhundven | and clean it up |
| # 22:27:01 | y_morin | Just one before: do you find the new patchwork usefull |
| # 22:27:02 | y_morin | ? |
| # 22:27:08 | bhundven | if you want to kill off gcc/svn thing |
| # 22:27:19 | y_morin | bhundven: Yep, I'm eager to see that CT-Get! |
| # 22:27:21 | bhundven | didn't even notice |
| # 22:28:09 | y_morin | bhundven: http://patchwork.ozlabs.org/project/crosstool-ng/ |
| # 22:28:46 | y_morin | Yep, not hosted on ct-ng.org: needs Django and a DB. I'm not too much fond of running those heavy-weights on the machine. |
| # 22:29:25 | bhundven | nice |
| # 22:29:35 | bhundven | that gets us a bit away from hg email |
| # 22:29:51 | bhundven | well, to the mailing list anyways |
| # 22:29:52 | bhundven | ? |
| # 22:30:00 | y_morin | bhundven: well, you still need to send the patches so pathwork gets them. |
| # 22:30:06 | bhundven | ah, ok |
| # 22:30:20 | y_morin | bhundven: patchwork is only a mean to see the pending stuff. |
| # 22:30:34 | bhundven | I see |
| # 22:30:43 | bhundven | ok, I'll have to read up on that when I do my stuff |
| # 22:31:44 | y_morin | bhundven: that should be transparent to you: send the patches as usual,patchwork is subscribed to the list, and when a patch is sent, it stores it. |
| # 22:31:59 | bhundven | ah, ok |
| # 22:32:14 | bhundven | new process: everything is the same. |
| # 22:32:15 | bhundven | :D |
| # 22:32:23 | y_morin | bhundven: then, anyone can run: pwclient list -p crosstool-ng to get the list of pending patches |
| # 22:32:35 | bhundven | nice |
| # 22:32:40 | y_morin | bhundven: and run: pwclient view to see the patch. |
| # 22:33:17 | y_morin | bhundven: and I have a script here that gets a patch and applies it to my local tree. Then when I push, patchwork is updated, and a mail is sent to the author. |
| # 22:33:37 | bhundven | very cool |
| # 22:33:49 | y_morin | bhundven: I've recently learnt how to use 'git rebase -i' (thanks to kos_tom!). It rocks! :-) |
| # 22:33:55 | bhundven | now if we could automate supporting people on irc/email |
| # 22:33:58 | bhundven | :p |
| # 22:34:10 | bhundven | yea.... |
| # 22:34:15 | y_morin | bhundven: but I don't think I'm ready to switch over to git. |
| # 22:34:30 | bhundven | for this project, I'm rather fond of hg |
| # 22:34:41 | y_morin | bhundven: yep. an bot that replies to questions with something like : RTFM. :-p |
| # 22:34:48 | bhundven | for other projects I work on, git is a better solution |
| # 22:35:04 | bhundven | I just dislike svn |
| # 22:35:06 | bhundven | and perforce |
| # 22:35:08 | bhundven | and cvs |
| # 22:35:16 | y_morin | bhundven: perfarce, you mean? ;-) |
| # 22:35:22 | bhundven | lol |
| # 22:35:34 | bhundven | don't even get me started on clearcase |
| # 22:35:49 | y_morin | bhundven: ditto. I;ve suffered enough on it... |
| # 22:50:45 | bhundven | is now known as: bhundven|afk |
| # 23:07:57 | devcoder | joins #crosstool-ng |
| # 23:08:44 | y_morin | quits : Quit: Nighty Night! |