ibotlog2html for #crosstool-ng

<< Previous 2011-10-07 Next >>

# 05:32:39 mnt_real quits : Quit: Leaving
# 07:35:04 y_morin joins #crosstool-ng
# 07:40:36 smartin joins #crosstool-ng
# 08:45:40 sinseman44 quits : Quit: leaving
# 09:11:56 y_morin quits : Ping timeout: 252 seconds
# 09:23:27 y_morin joins #crosstool-ng
# 11:04:43 esbenh joins #crosstool-ng
# 11:05:08 esbenh #!)(/#()/!"/! glibc release engineering
# 11:05:30 esbenh why on earth cannot they manage to tar up the glibc-ports release when tagged?
# 11:05:42 esbenh how hard can it be :-(
# 11:06:20 esbenh I am now trying to trick ct-NG into using it from git instead, but is running into some issues
# 11:11:22 y_morin esbenh: Hello! I'll put the tarball on the crosstool-ng.org server
# 11:18:14 y_morin esbenh: You can go to: Paths and misc options ---> [*] Use a mirror and then set: (http://crosstool-ng.org/mirrors/) Base URL
# 11:19:01 y_morin esbenh: that tarball for ports was made around july the 3rd, 2011.
# 11:21:07 esbenh yes, but that won't really help me
# 11:21:33 esbenh I have just changed the OE-lite integration of ct-NG, to always use CT_FORBID_DOWNLOAD, and then let the OE-lite fetcher do the fetching
# 11:21:57 esbenh this is needed for me to properly handle source signatures for ct-NG builds
# 11:24:01 y_morin esbenh: Ah...
# 11:24:44 esbenh so I fetch the glibc-ports.git repo and checks it out at glibc-2.14 tag
# 11:24:53 esbenh so far, so good.
# 11:25:22 esbenh but do_libc_extract does not take that to well
# 11:28:02 esbenh I am now trying to figure out why the ports is not properly moved to glibc-2.14/ports
# 11:28:12 esbenh which is done when it is fetched as tarball
# 11:30:25 y_morin esbenh: How did you create the ports tarball ?
# 11:30:54 esbenh I don't have a tarball
# 11:31:13 esbenh I just have glibc-ports-2.14/.git
# 11:31:34 esbenh which CT_Extract finds, and does a CT_ExtractGit with
# 11:32:22 y_morin esbenh: Oh, that has never, ever been tested so far! :-(
# 11:32:55 y_morin esbenh: it was a tentative on my part to try to use git instead of tarballs, but I never finished that... :-(
# 11:33:26 y_morin esbenh: it dates back... a long time ago...
# 11:34:00 esbenh I sort of sensed that :-)
# 11:34:14 esbenh newer the less, I want to get it working now :-)
# 11:34:41 y_morin esbenh: Ah, that's nice.
# 11:40:16 esbenh seems like the only permanent solution to working wiht glibc releases
# 11:56:48 esbenh y_morin: so CT_ExtractGit is not to be considered used in any context currently?
# 11:57:04 esbenh y_morin: I might want to change the API slightly...
# 11:57:08 y_morin esbenh: indeed, there's no official caller so far.
# 11:57:16 y_morin esbenh: go on! ;-)
# 11:58:40 esbenh thanks :-)
# 12:00:32 esbenh hmm... might not even be needed :-)
# 12:41:11 esbenh I think I have a working pathc
# 12:41:13 esbenh patch even
# 12:41:21 esbenh need to figure out the hg diff thingy
# 12:41:52 esbenh I still miss installing git-fu in my brain
# 12:43:22 y_morin esbenh: hg commit (babla); hg email --outgoing --to crossgcc@...
# 12:51:29 esbenh I guess the hg email command requires a working email setup of some kind.
# 12:58:12 esbenh does hg has a command-line helper for add sob's?
# 13:14:07 y_morin esbenh: there is no provision for the SoB thingies in Hg. I have a hook for MQ that appends one on new MQ patches, but that requires use of MQ.
# 13:14:16 y_morin esbenh: and for the email setup: hg help email.
# 13:16:05 esbenh well, I have never figured out how to handle this )(/¤#)(!/! Exchange server at work, so I cannot send email from Linux like that :-(
# 13:16:19 esbenh and port 25 is "of-course" blocked :-(
# 13:16:59 esbenh anyway, it seems like it actually went through
# 13:17:03 esbenh forgot the sob line though.
# 13:23:01 y_morin esbenh: just saw the mail, so yes, it went through. Just reply to the mail on the list with your SoB line, i'll add it locally before the final push.
# 13:23:24 y_morin esbenh: I'll handle that tonight, when back at home...
# 13:23:25 y_morin esbenh: thank you! :-)
# 13:25:45 esbenh np
# 13:26:24 esbenh already did so, but it first tried to get out through one fo my (now) broken mailservers
# 13:27:18 esbenh are you (or someone else) working on a method for dumping the list of sources to be downloaded?
# 13:27:55 esbenh I would like to add a QA step in OE-lite, comparing the list of sources I am providing to ct-NG, with what ct-NG needs.
# 13:28:07 y_morin esbenh: you're not the first to ask... There is already this need for buildroot to use such a feature in crosstool-NG, but no code so far...
# 13:28:27 y_morin esbenh: it is not currently possible with the way crosstool-NG handles downloads...
# 13:28:32 esbenh I get proper failure when missing sources (thanks for CT_FORBID_DOWNLOAD!), but I would like to have a way for printing a warning if to many sources were provided.
# 13:28:53 esbenh it is not in any way critical for me
# 13:29:00 esbenh just a nice-to-have feature
# 13:29:40 y_morin esbenh: I have a few ideas I'd like to ponder, on the way we handle downloads. So far, it's not even totally clear in my head...
# 13:31:30 y_morin esbenh: basically, I'd like to review completely the way crosstool-NG handles dependencies (such as: "building foo" require "building bar", but also: "building foo" requires "downloading foo" and "extracting foo")
# 13:32:26 y_morin esbenh: currently, these are completely handled by conditionals and sequences, but that not scalable in the long term...
# 13:33:52 y_morin So, instead of using a single script with conditionals, I'd like to move to a Makefile with proper dependencies, eg: ifeq ($(BLA),y) / gcc_deps+=gmp / endif; and add $(gcc_deps) as pre-requisites to the gcc rule.
# 13:44:00 smartin quits : Ping timeout: 252 seconds
# 14:11:02 esbenh y_morin: hehe, I think I should really present you how OE-lite works at ELCE ;-)
# 14:14:53 y_morin esbenh: I'll be there! ;-)
# 14:31:02 esbenh I booked my return to saturday afternoon, so I will be at the workshop also
# 14:34:27 y_morin esbenh: you mean, the crosstool-NG workshop on staurday? Great! :-)
# 16:07:22 y_morin quits : Ping timeout: 252 seconds
# 17:22:20 y_morin joins #crosstool-ng
# 17:54:33 y_morin is now known as: y_morin|away
# 18:04:23 y_morin|away is now known as: y_morin
# 18:23:33 y_morin is now known as: y_morin|away
# 18:45:52 KAeL quits : Quit: Changing server
# 18:58:58 kpet joins #crosstool-ng
# 19:25:26 josec joins #crosstool-ng
# 19:25:44 josec quits : Client Quit
# 19:30:09 smartin joins #crosstool-ng
# 19:38:59 y_morin|away is now known as: y_morin
# 19:59:50 smartin quits : Ping timeout: 252 seconds
# 20:36:55 mnt_real joins #crosstool-ng
# 21:40:24 sh4rm4 sigh, the gcc build system is so fucked up
# 21:40:44 sh4rm4 i'm thinking about creating a "makefiles-for-gcc" project
# 21:41:29 sh4rm4 analyes what gcc builds in which order, and add a single makefile that does the same (if it even makes sense)
# 21:42:21 sh4rm4 that'd probably cut compilation time in half, and reduce build errors to near zero
# 21:43:11 y_morin sh4rm4: but that would not be portable/reaptable/...
# 21:43:22 y_morin *repeatable
# 21:43:26 sh4rm4 why not ?
# 21:43:52 sh4rm4 i wouldn't care really if it builds for IRIX 0.07
# 21:44:03 y_morin I mean, I would not be able to use your Makefile on my machine, it's not necessarily the same libs, the same versions, the same paths...
# 21:44:21 sh4rm4 it should just compile on a posix compliant system without further ado..
# 21:44:41 sh4rm4 well, you want to customize which path's it uses, of course
# 21:45:18 y_morin sh4rm4: but you'd need a few variants, at least: one with cloog+ppl for GRAPHITE, one with libelf for LTO, but only for gcc-4.5, and so on...
# 21:45:26 sh4rm4 and for cross compilation, build stuff that like xgen or how it is called with $HOSTCC
# 21:46:12 sh4rm4 y_morin, the Makfile would be accompanied by a config.mak, where you can just enable/disable those options by putting a #
# 21:47:23 y_morin sh4rm4: but what about those systems where libcloog would be in /usr/lib, and another in /usr/local/lib, or in a place ld does not know about?
# 21:47:39 y_morin ./configure is here just to solve those issues...
# 21:47:44 sh4rm4 you'd just pass -L in CFLAGS
# 21:47:52 y_morin is now known as: y_morin|away
# 21:47:56 y_morin|away is now known as: y_morin
# 21:48:05 y_morin Woops.. Bad key-combo...
# 21:48:10 sh4rm4 heh
# 21:48:50 y_morin sh4rm4: So you'd want to replace ./configure? ;-)
# 21:49:02 sh4rm4 remove it, yes
# 21:49:22 sh4rm4 because it really is just a waste of time and epic failure
# 21:49:43 sh4rm4 testing size of uint8_t ... 1
# 21:49:48 sh4rm4 how amazing.
# 21:50:04 y_morin sh4rm4: I can't agree more on the "waste of time", and no less on the "epic failure" part! :-)
# 21:50:38 y_morin sh4rm4: yep, autocrap was not conceived with cros-compilation in mind.
# 21:51:41 sh4rm4 it looks as if they had not much in mind at all... maybe except creating somthing so huge and complex that they can keep their jobs because nobody else understands the build system
# 21:52:06 y_morin sh4rm4: don't make me laugh, please! :-)
# 21:52:30 sh4rm4 ;)
# 21:56:51 ccct http://code.google.com/p/quagmire/
# 21:57:03 ccct tromey (one of autotools authors) tried to replace it many years ago
# 21:57:16 ccct http://tromey.com/blog/?p=394
# 22:00:25 y_morin ccct: interesting. Thx.
# 22:02:03 sh4rm4 unfortunately dead
# 22:02:15 y_morin yep... :-(
# 22:03:59 y_morin quits : Quit: Night is for sleeping...

Generated by ibotlog2html by Yann E. MORIN