| 00:12.25 | *** join/#uclibc tchan (n=tchan@lunar-linux/developer/tchan) |
| 01:01.18 | *** join/#uclibc hiyuh (n=hiyuh@KD059133117089.ppp.dion.ne.jp) |
| 05:15.02 | *** join/#uclibc doc|schaffen (n=doc@82.115.100.147) |
| 06:43.52 | *** join/#uclibc vinilios (n=k88@adsl77-101.ath.forthnet.gr) |
| 07:27.54 | *** topic/#uclibc by blindvt`_ -> discussion of uClibc and Busybox | uClibc 0.9.29 released 6 May 2007, 0.9.30-rc2 == trunk; PLEASE TEST! | busybox 1.12.1 28 September 2008 | for non uClibc/busybox such as buildroot and general setup issues try #elinux or #edev |
| 08:16.53 | CIA-9 | 03aldot * r23548 10uClibc/libc/sysdeps/linux/ (alpha/bits/atomic.h mips/bits/atomic.h): - fix ISO C keywords |
| 08:20.58 | *** join/#uclibc likewise (n=likewise@82-171-51-231.ip.telfort.nl) |
| 08:51.32 | CIA-9 | 03carmelo * r23549 10uClibc/libc/misc/wchar/wchar.c: (log message trimmed) |
| 08:51.32 | CIA-9 | i18n: Fix mbrtowc function to handle 0xc0 and 0xc1 sequence. |
| 08:51.32 | CIA-9 | When the first byte of the multibyte sequence start with 0xc0 |
| 09:37.08 | *** join/#uclibc k88_ (n=k88@212.89.168.145) |
| 09:57.12 | *** join/#uclibc k88_ (n=k88@adsl77-101.ath.forthnet.gr) |
| 11:07.38 | blindvt`_ | hi |
| 11:08.19 | fabo | hi blindvt`_ |
| 11:23.50 | *** join/#uclibc likewise (n=likewise@82-171-51-231.ip.telfort.nl) |
| 11:36.50 | CIA-9 | 03aldot * r23550 10uClibc/libc/sysdeps/linux/i386/ (Makefile.arch posix_fadvise.c posix_fadvise64.S): - now passes all LTP tests |
| 11:39.34 | blindvt`_ | on somewhat recent kernels, i may add. Although i even tested it on 2.6.11, i did not try something older |
| 11:56.05 | CIA-9 | 03carmelo * r23551 10uClibc/ldso/ldso/ldso.c: |
| 11:56.05 | CIA-9 | ldso: do not use hard-coded fd in _dl_dprintf. Use dl_debug_file consinstently. |
| 11:56.05 | CIA-9 | Signed-off-by: Carmelo Amoroso <carmelo.amoroso@st.com> |
| 11:58.18 | CIA-9 | 03carmelo * r23552 10uClibc/ldso/libdl/libdl.c: |
| 11:58.18 | CIA-9 | libdl: use stderr consistently. |
| 11:58.18 | CIA-9 | Signed-off-by: Carmelo Amoroso <carmelo.amoroso@st.com> |
| 12:09.53 | CIA-9 | 03carmelo * r23553 10uClibc/ldso/ldso/sh/elfinterp.c: |
| 12:09.53 | CIA-9 | ldso: allow undefined references to weak symbols |
| 12:09.53 | CIA-9 | Signed-off-by: Carmelo Amoroso <carmelo.amoroso@st.com> |
| 12:41.22 | blindvt`_ | HcE, ping |
| 12:41.22 | HcE | blindvt`_: You sent me a contentless ping. This is a contentless pong. Please provide a bit of information about what you want and I will respond when I am around. |
| 12:42.02 | blindvt`_ | HcE, i cannot reproduce http://bugs.busybox.net/view.php?id=4314 |
| 12:43.27 | HcE | blindvt`_: I thought that was fixed? |
| 12:43.41 | HcE | blindvt`_: hmmm, check if glob resets errno |
| 12:43.42 | blindvt`_ | HcE, is this your toolchain miscompiling something or a real issue somewhere? |
| 12:44.06 | HcE | blindvt`_: the user had not set the UCLIBC_HAS_GNU_GLOB, but used glob like it was set |
| 12:44.10 | blindvt`_ | HcE, it's not really fixed for he turned off glob-susv3 |
| 12:51.57 | blindvt`_ | HcE, where did he use GNU_GLOB specific stuff? I don't see any |
| 12:55.06 | HcE | uClibc? |
| 12:55.11 | HcE | perhaps it is removed in trunk? |
| 12:55.18 | HcE | this is 0.9.29 remember |
| 12:57.18 | blindvt`_ | HcE, hm. Could be but that's not really satisfying |
| 12:57.57 | HcE | In Big and tall, I can choose: |
| 12:57.58 | HcE | UCLIBC_HAS_GLOB=y |
| 12:57.58 | HcE | UCLIBC_HAS_GNU_GLOB=y |
| 12:58.11 | blindvt`_ | HcE, # UCLIBC_HAS_GNU_GLOB is not set |
| 12:59.46 | CIA-9 | 03carmelo * r23554 10uClibc/ldso/ldso/sh/elfinterp.c: Fix comment. |
| 13:00.22 | blindvt`_ | HcE, would be awesome if you see it with 0.9.29 but not trunk and can pinpoint the fix to make sure that it's not some fallout of a broken^W^Whis toolchain but that it's really fixed |
| 13:04.11 | CIA-9 | 03aldot * r23555 10uClibc/libc/sysdeps/linux/common/ssp.c: - honour UCLIBC_HAS_SYSLOG |
| 13:19.36 | CIA-9 | 03carmelo * r23556 10uClibc/ldso/ldso/sh/elfinterp.c: sh_ldso: Fix typo: missing semi-colon. |
| 13:19.55 | *** join/#uclibc hiyuh (n=hiyuh@KD125054017176.ppp-bb.dion.ne.jp) |
| 13:20.11 | blindvt`_ | HcE, likewise for 4514 |
| 13:20.44 | blindvt`_ | HcE, mind if i assign all those atmel stuff to you? |
| 13:31.35 | HcE | blindvt`_: sure, go ahead, but I am a bit stuck for two weeks, I forgot we have training here these weeks :/ |
| 13:32.49 | blindvt`_ | HcE, aha, so we will ship without further atmel updates, IIUC? |
| 13:36.22 | HcE | only bugfixes |
| 13:36.37 | HcE | I'll have time to go through the test framework |
| 13:39.23 | blindvt`_ | k |
| 13:50.05 | HcE | should I close the bug as well if a bug is fixed and verified by my co-worker? |
| 13:52.02 | blindvt`_ | HcE, if it's fixed then yes, please close it and set the version in which it will be fixed accordingly |
| 13:53.02 | blindvt`_ | HcE, i.e. 0.9.30 if it's fixed on trunk. TIA |
| 13:56.15 | HcE | blindvt`_: if it is not a uClibc bug, but toolchain bug? |
| 13:56.42 | HcE | hmm, perhaps I should have set it to something completely different :/ |
| 13:59.26 | HcE | blindvt`_: why did I get the gethostbyname() stuff? |
| 14:00.12 | HcE | blindvt`_: and please only assigne AVR32 stuff to me, I have little knowledge of ARM |
| 14:00.24 | blindvt`_ | HcE, if it's a toolchain bug then close it with "No fix required" or something like that. In these cases please state which toolchain version the user is supposed to use |
| 14:01.07 | blindvt`_ | HcE, i only assigned that "0004514: hang when sending request to netlink socket on AVR32 NGW100 dev kit " to you |
| 14:01.31 | blindvt`_ | HcE, i've updated the resolver bug, you just got a copy since you listen to -cvs |
| 14:01.46 | blindvt`_ | HcE, ok, no ARMs for you :) |
| 14:02.25 | blindvt`_ | HcE, oh and please *close* stuff. You set it to "resolved" which still makes it show up per default. |
| 14:04.38 | HcE | blindvt`_: I just closed it :) |
| 14:28.26 | *** join/#uclibc wberrier (n=wberrier@12.191.193.40) |
| 14:34.41 | CIA-9 | 03aldot * r23557 10uClibc/extra/Configs/Config.m68k: - do not pass bitwise-or to the assembler. Closes #3164 |
| 15:07.43 | HcE | hmmm, uClibc makefile in BR2 seems a bit broken, does $(cross_compiler) really exist? I think it should be cross_compiler without the $() |
| 15:19.10 | blindvt`_ | HcE, no, that's in fact ok. $(cross_compiler) refers to the binary sometimes later as opposed to cross_compiler (the target) which is handy for me |
| 15:19.38 | blindvt`_ | HcE, the $(cross_compiler) is needed for toplevel parallel make to get the deps right. |
| 15:20.05 | HcE | hmm, okay |
| 15:20.47 | blindvt`_ | HcE, i guess landley broke your uclibc, didn't he ;) |
| 15:23.39 | blindvt`_ | ~tell landley i'm looking forward to you adding ilnuxthreads.new (or nptl) support for m68k ;) |
| 15:23.58 | HcE | hihi |
| 15:23.59 | blindvt`_ | ~seen landley |
| 15:24.00 | ibot | landley <n=landley@static-71-162-243-5.phlapa.fios.verizon.net> was last seen on IRC in channel #uclibc, 1d 17h 17m 4s ago, saying: 'Hello world!'. |
| 15:25.04 | blindvt`_ | ibot, it's a pity that you don't keep or relay msgs. *sigh* |
| 15:37.27 | HcE | hmmm |
| 15:37.37 | HcE | does make headers in uClibc now require a working compiler? |
| 15:40.27 | fabo | HcE: broken recently. I built a rootfs using buildroot+uclibc trunk friday, not today ... |
| 15:40.59 | blindvt`_ | HcE, no it doesn't. later on pregen does |
| 15:41.32 | fabo | maybe commit r23534 |
| 15:41.43 | HcE | aha |
| 15:41.48 | HcE | I grabbed latest snapshot |
| 15:41.50 | HcE | silly me |
| 15:43.15 | blindvt`_ | it's just once again svn lagging a bit behind *shrug* |
| 15:43.25 | solar | blindvt`_: was r23550 you? if so thanks |
| 15:44.11 | HcE | -install_dev: install_headers |
| 15:44.11 | HcE | +install_dev: install_headers all |
| 15:44.14 | HcE | looks fishy |
| 15:45.22 | blindvt`_ | solar, yes that was me. I didn't test it on 2.4.x though, only 2.6.26.5 and 2.6.11-suse-something |
| 15:46.17 | blindvt`_ | solar, sorry that it took me so long to provide an accurate impl.. |
| 15:46.30 | HcE | yepp, the r23534 commit is not correct |
| 15:47.24 | HcE | it assumes you have a cross compiler, which is a bit tricky to make without headers |
| 15:47.47 | blindvt`_ | solar, please holler if you still encounter problems |
| 15:48.38 | solar | getting near a rc2 ? |
| 15:48.51 | solar | thats a better time for me to test |
| 15:49.33 | blindvt`_ | solar, i'll do an rc2 during this weekend or early next week |
| 15:49.48 | HcE | urk, something is wrong with the Linux headers as well |
| 15:49.50 | HcE | hmpf |
| 15:51.02 | blindvt`_ | solar, i'm aiming for friday evening, but i'm getting into the early-november-birthday-mindfield starting thursday, so i'm not yet sure how friday evening will work out |
| 15:51.20 | blindvt`_ | s/november/october/;# |
| 15:51.28 | *** join/#uclibc pcgeil (n=steffen@p549E6730.dip.t-dialin.net) |
| 15:53.43 | solar | skip friday. Tuesdays and Wednesdays oddly enough are the best days of the week to release (middle of work week) |
| 15:54.19 | solar | not just for me. But the same holds true for most vendor security updates as well |
| 15:58.05 | *** join/#uclibc pcgeil (n=steffen@p549E6730.dip.t-dialin.net) |
| 16:01.56 | HcE | in SVN, is there a smooth way of reverting a previous version? Or should I just do the change myself and commit with a message with says "reverting r<num>"? |
| 16:02.25 | blindvt`_ | HcE, followup landleys commit first and discuss reverting it, please |
| 16:02.55 | HcE | blindvt`_: on email you mean? For some reason, I do not have it :/ |
| 16:03.28 | blindvt`_ | HcE, while he's doing it in a inelegant way him doing that "all" doesn't really matter |
| 16:04.35 | HcE | my brain got a parse error on that sentence |
| 16:05.24 | blindvt`_ | HcE, that "all" dep is not elegant but does not impose any real damage. Fix your buildscript instead |
| 16:05.39 | HcE | blindvt`_: Buildroot in that matter then |
| 16:07.36 | blindvt`_ | HcE, I've forwarded that commit message to you |
| 16:07.53 | HcE | thanks |
| 16:08.13 | HcE | I'll see if I can massage Buildroot to install headers in the right order |
| 16:08.28 | HcE | it should not need the uClibc headers before making the gcc-final |
| 16:08.52 | HcE | so it should be kernel headers, gcc bootstrap, binutils, uClibc and gcc-final |
| 16:09.17 | blindvt`_ | HcE, let me explicitely point out that i've fixed this recently in my tree, fwiw. Perhaps that saves you some headache |
| 16:10.21 | HcE | smooth |
| 16:11.09 | blindvt`_ | that's what i mean with svn lagging behind, once again :P |
| 16:11.20 | HcE | hehe, well, did you commit it? ;) |
| 16:11.58 | blindvt`_ | HcE, i'm pretty sure i did. mompls |
| 16:12.18 | blindvt`_ | HcE, yes, i did. |
| 16:14.16 | HcE | hmmm |
| 16:14.37 | HcE | weird, I grabbed the snapshot from today |
| 16:14.41 | HcE | did I hit the wall again? |
| 16:27.49 | CIA-9 | 03egtvedt * r23558 10buildroot/package/qtopia4/qtopia4.mk: |
| 16:27.49 | CIA-9 | qtopia4: bump version to 4.4.3 |
| 16:27.49 | CIA-9 | Signed-off-by: Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com> |
| 16:40.37 | HcE | I could not find something about the build order of the toolchain in your GIT repo or SVN for BR2 |
| 16:41.25 | HcE | s/I/blindvt`_: I/ |
| 16:41.28 | HcE | hihi |
| 16:43.41 | blindvt`_ | HcE, it's the very last commit; fire up gitk or look at git log |
| 16:44.25 | blindvt`_ | HcE, the solution is easier than you think |
| 16:44.37 | HcE | thanks |
| 16:44.53 | HcE | I did not really connect the commit subject to the change :/ |
| 16:44.57 | HcE | sorry for making noise |
| 16:45.30 | blindvt`_ | HcE, no reordering, no fancy stuff. Heck, _I_ should ask you all that stuff, it's you who's lucky enough to be payed for that stuff, after all :-| |
| 16:46.23 | HcE | hihi |
| 16:46.32 | HcE | I attacked the problem from the wrong angle |
| 16:46.51 | blindvt`_ | yes, you did indeed. It's dead simple, as you can see |
| 16:46.53 | HcE | assume BR was fundamental wrong, instead it was the uclibc makefile which was wrong |
| 16:47.03 | HcE | but it is not committed upstream |
| 16:47.06 | HcE | I'll do that |
| 16:47.35 | blindvt`_ | fabo, that's not really constructive |
| 16:49.20 | blindvt`_ | fabo, there is absolutely no point in jumping up and down WRT threading right now. zilch reason, nada, überhaupt kei nwieauchimmer gearteter Grund |
| 16:50.48 | blindvt`_ | fabo, http://uclibc.org/lists/uclibc/2008-September/020191.html |
| 16:52.02 | blindvt`_ | adds a filter to thrash everything containing "/(linuxthreads|nptl)" to /dev/null |
| 16:57.33 | CIA-9 | 03aldot * r23559 10uClibc/libc/sysdeps/linux/m68k/sys/user.h: - add a copy of user_regs |
| 17:03.20 | *** join/#uclibc bbradley (n=bbradley@78-105-167-16.zone3.bethere.co.uk) |
| 17:06.16 | *** join/#uclibc Redhatter (n=vk4msl@2001:388:f000:0:0:0:0:279) |
| 17:23.19 | *** join/#uclibc pcgeil (n=steffen@p549E6730.dip.t-dialin.net) |
| 19:11.47 | *** join/#uclibc landley (n=landley@static-71-162-243-5.phlapa.fios.verizon.net) |
| 19:46.15 | *** join/#uclibc likewise (n=likewise@82-171-51-231.ip.telfort.nl) |
| 20:32.19 | *** join/#uclibc pcgeil (n=steffen@p549E6730.dip.t-dialin.net) |
| 20:41.00 | fabo | blindvt`_: the point is related to testing linuxthreads as suggested by some people on the ml. the results is linuxthread is broken for me (at least) and the conclusion is : IMHO, it's a bit premature to deprecate one of linuxthread implementation. |
| 20:41.17 | fabo | nothing more, nothing less |
| 21:02.59 | landley | is happy to remove the _new_ implementation instead. |
| 21:03.07 | landley | They're both being deprecated by NPTL when it arrives. |
| 21:03.16 | landley | Putting lots of effort into pthreads at this point seems kind of silly, that's all. |
| 21:12.50 | *** join/#uclibc pcgeil_ (n=steffen@p549E5C8D.dip.t-dialin.net) |
| 21:38.49 | *** join/#uclibc ivob (n=ivob@unaffiliated/tiny) |