| 00:05.06 | *** join/#uclibc bkuhn (~bkuhn@fsf/director/conservancy.president.bkuhn) |
| 00:53.02 | *** join/#uclibc zazenrasta (~chaoscrew@h69-130-144-36.nlsnga.dsl.dynamic.tds.net) |
| 00:54.20 | *** join/#uclibc niv_ (beacec48@gateway/web/freenode/ip.190.172.236.72) |
| 05:05.42 | *** join/#uclibc DuratarskeyK (~Duratar@93-181-207-156.pppoe.yaroslavl.ru) |
| 06:02.05 | *** join/#uclibc ashes (~ashes@modemcable162.103-21-96.mc.videotron.ca) |
| 06:03.52 | *** join/#uclibc ncopa (~ncopa@180.40.189.109.customer.cdi.no) |
| 06:25.39 | *** join/#uclibc kos_tom (~thomas@humanoidz.org) |
| 06:43.07 | *** join/#uclibc kos_tom (~thomas@humanoidz.org) |
| 06:50.34 | *** join/#uclibc Artemys (~quassel@stp25-1-82-225-18-227.fbx.proxad.net) |
| 06:56.08 | *** join/#uclibc nataraj (~nataraj@122.165.223.135) |
| 07:43.20 | CIA-46 | 03jacmet 07master * r5bf7eb2a72ed 10buildroot/CHANGES: CHANGES: #321 / #1393 are resolved |
| 07:43.22 | CIA-46 | 03m-starostik 07master * rfbc22ecaef7b 10buildroot/Makefile: Fix default skeleton path |
| 07:45.33 | *** join/#uclibc dougmencken (~quassel@93.123.156.139) |
| 07:47.53 | CIA-46 | 03raj.khem 07master * rfb6ca14d4d53 10uClibc/ldso/ldso/mips/dl-sysdep.h: ldso/mips: pltgot should array not address of array to dynamic info. |
| 07:54.05 | kos_tom | khem: hi! |
| 08:08.36 | kos_tom | Jacmet: if you're around sometime today, let me know. |
| 08:09.36 | Jacmet | kos_tom: around |
| 08:09.40 | kos_tom | Jacmet: hey :-) |
| 08:09.43 | Jacmet | ;) |
| 08:09.59 | kos_tom | Jacmet: I'm integrating some old patches from dj-death to bump the libglib/atk/pango stack. I'm wondering about what we should do on libgtk2. |
| 08:10.35 | kos_tom | libgtk2 2.12.x (that we have currently) is very very old, but is semi-working on DirectFB (still has issues). Newer versions of gtk2 do not even compile for the DirectFB backend. |
| 08:10.37 | Jacmet | kos_tom: well, the directfb stuff is still broken with modern gtk versions, right? |
| 08:10.44 | kos_tom | yes. |
| 08:11.06 | kos_tom | but I think it's time to give up and bump the gtk version anyway. Or to keep support for both versions. |
| 08:11.43 | kos_tom | but keeping gtk 2.12 around forever will not improve the situation in terms of DirectFB support. |
| 08:13.30 | kos_tom | Jacmet: dj-death has been working on DFB support in gtk 2.20 for quite some time. He has a semi-working thing, but it requires at least a dozen of patches. |
| 08:18.01 | dj-death | from what I remember, most of projects are more or less planning to drop directfb support (cairo, gtk, enlightenment, ...) |
| 08:20.19 | kos_tom | ah |
| 08:20.47 | dj-death | gtk because there is no maintainer |
| 08:21.00 | kos_tom | why not you ? |
| 08:21.11 | dj-death | cairo because they find dfb acclerations almost useless |
| 08:21.37 | dj-death | kos_tom: I'm not skilled enough ;) |
| 08:22.32 | dj-death | otherwise I would have fixed all the bugs |
| 08:22.39 | kos_tom | ok, so maybe we should drop the support for Gtk+DirectFB so that people don't start projects with this solution that isn't maintained. |
| 08:23.04 | kos_tom | interesting that Gtk is dropping DirectFB support, while at the same time, it has been added to Qt :) |
| 08:23.06 | Jacmet | kos_tom: sorry, just got interrupted |
| 08:23.12 | kos_tom | Jacmet: no pb. |
| 08:24.08 | Jacmet | kos_tom: I agree that trying to maintain something long term if upstream isn't interested isn't an option |
| 08:24.16 | dj-death | kos_tom: you seem to have a good experience with xorg |
| 08:24.46 | kos_tom | dj-death: you mean on using Gtk over Xfbdev ? |
| 08:24.53 | dj-death | kos_tom: yes |
| 08:24.54 | Jacmet | kos_tom: Is there a big size advantage to gtk+directfb compared to gtk+X11? Last time I looked (which is quite some time ago), the difference was quite small |
| 08:25.32 | Jacmet | kos_tom: or are people using directfb because of prop. accel. drivers? |
| 08:25.42 | kos_tom | Jacmet: I don't have numbers right now, but I could produce some. |
| 08:26.04 | kos_tom | Jacmet: I'm not sure why dfb is choosen. Maybe dj-death has thoughts about this. |
| 08:26.05 | Jacmet | kos_tom: you don't have to, just wondering |
| 08:26.19 | dj-death | dfb peoples would argue in size/responsiveness |
| 08:26.30 | khem | kos_tom: hello |
| 08:26.40 | Jacmet | kos_tom: the debian installer afaik also moved to gtk+X11 some time ago because of lack of upstream support |
| 08:26.44 | khem | Jacmet: hi |
| 08:26.48 | Jacmet | khem: hi |
| 08:27.03 | khem | Jacmet: did u try the nptl stuff |
| 08:27.14 | khem | or do you need more time |
| 08:27.27 | Jacmet | khem: sorry, no - I wasn't home most of the weekend and had lots of BR mails to catch up on |
| 08:27.41 | Jacmet | khem: I'll try it very soon, hopefully tonight |
| 08:28.26 | khem | Jacmet: ok thx |
| 08:28.30 | kos_tom | Jacmet: I've found some old numbers. Basic X.org is 5.4 MB, basic DFB is 1.4 MB. Then you have to add glib/pango/atk/gtk on top of it, but the size is similar for both backends. |
| 08:28.57 | Jacmet | kos_tom: hmm, perhaps I was thinking of tinyx instead of xorg |
| 08:28.58 | kos_tom | khem: have you received the bug I've CC'ed you about LINUXTHREADS_NEW and its sysdep.h build failure ? |
| 08:29.11 | khem | Jacmet: one think you should try before you build nptl is build your existing stuff and see if that still works if not let me know |
| 08:29.11 | kos_tom | Jacmet: well that was tinyx. |
| 08:29.17 | khem | because that should not break |
| 08:29.22 | dj-death | 5.4Mb ?? |
| 08:29.28 | khem | kos_tom: just saw email yes |
| 08:29.41 | khem | kos_tom: LT is receiving not much love |
| 08:30.02 | kos_tom | khem: so, should we just offer LINUXTHREADS_OLD ? |
| 08:30.03 | Jacmet | kos_tom: 5.4MB sounds pretty high for tinyx if you don't need all those legacy fonts and so on |
| 08:30.06 | khem | kos_tom: and NPTL going full steam I only see reduced love for it |
| 08:30.08 | khem | in future |
| 08:30.38 | khem | kos_tom: staating .32 yes |
| 08:30.46 | khem | err starting |
| 08:31.00 | kos_tom | dj-death: 1.2 MB for the server itself, 2.5 MB for libxcb/liblbxutil/libXfont/libX11/few other libs, 1.5 MB for dependencies (expat/dbus/libpng/libsysfs/zlib/pixman/freetype/fontconfig) |
| 08:31.50 | khem | we might depricate even LT.OLD with .32 |
| 08:31.54 | kos_tom | khem: not sure I get the relation between kernel versions and LINUXTHREADS_NEW vs. LINUXTHREADS_OLD (sorry I'm totally noob with all these thread implementations) |
| 08:32.09 | kos_tom | aah, uClibc 0.9.32. |
| 08:32.34 | khem | yes I am proposing new release to be called 1.0 |
| 08:32.35 | kos_tom | but for the moment, we have 0.9.31. LINUXTHREADS_NEW does not even compile. Should we just drop support for it and keep only LINUXTHREADS_OLD ? |
| 08:32.53 | khem | kos_tom: I wouldnt mind |
| 08:33.23 | dj-death | kos_tom: then how does dfb fit in 1.4Mb if there is 1.5Mb of others dependencies ? |
| 08:33.24 | khem | its not possible to carry 3 threading implementation + no threads |
| 08:33.29 | khem | given the people we have |
| 08:33.48 | kos_tom | dj-death: http://free-electrons.com/doc/embedded_linux_sysdev.pdf page 43 |
| 08:33.59 | dj-death | thx |
| 08:34.10 | kos_tom | and page 36 for DirectFB. |
| 08:35.28 | khem | kos_tom: I would expect people to use nptl as primary threading library after next relase which is only few months apart |
| 08:37.10 | khem | good night guys ttyl |
| 08:37.14 | kos_tom | khem: yes, understood. But we have a release next month, for which I'd like things to be fairly clean with 0.9.31. |
| 08:37.27 | dj-death | might be interesting to rewrite the gtk+ backend using xcb |
| 08:37.31 | khem | kos_tom: drop LT |
| 08:37.37 | kos_tom | LT_NEW ? |
| 08:37.42 | khem | yep |
| 08:37.45 | dj-death | and drop ~1Mb of libx11 |
| 08:37.46 | kos_tom | ok, thanks. |
| 08:37.50 | khem | I am not going to fix it |
| 08:38.01 | khem | if someone else does thats good |
| 08:38.28 | khem | but I am all ears open for problems with nptl |
| 08:39.57 | khem | -> sleep() |
| 08:40.23 | kos_tom | dj-death: http://julien.danjou.info/blog/2010.html. Search "Thoughts and rambling on the X protocol" and particularly "I used to believe in XCB" |
| 08:40.53 | kos_tom | Jacmet: ok, so, to sum up: drop Gtk+DFB support, drop LINUXTHREADS_NEW support. Do we agree ? |
| 08:41.43 | Jacmet | kos_tom: I think so, yes - But I'm not sure if we should drop gtk/DFB now or mark it deprecated for 1 more release |
| 08:41.46 | DuratarskeyK | oh guys, can you recommend a source-based package manager that can compile stuff with uclibc ? |
| 08:42.00 | Jacmet | DuratarskeyK: buildroot ;) |
| 08:42.13 | Jacmet | DuratarskeyK: or what do you exactly mean? |
| 08:42.40 | DuratarskeyK | package manager, buildroot has a small list of packages it can compile but not all I want |
| 08:43.04 | DuratarskeyK | and using ./configure && make && make install makes system dirty |
| 08:43.22 | kos_tom | DuratarskeyK: then add your packages to Buildroot. |
| 08:44.35 | DuratarskeyK | ouch, some of them have awful lot of deps |
| 08:45.02 | DuratarskeyK | btw, has anyone tested portage before including it into buildroot package list ? |
| 08:45.13 | DuratarskeyK | for me it doesn't work with python version buildroot has |
| 08:46.27 | kos_tom | DuratarskeyK: I don't think portage in BR has been used for years. |
| 08:46.44 | DuratarskeyK | I see |
| 08:47.05 | Jacmet | DuratarskeyK: portage has been removed from git as it was broken and noone cared |
| 08:48.50 | kos_tom | DuratarskeyK: if your deps are all using the autotools as their build system, then adding them to BR should be fairly easy. |
| 08:49.03 | DuratarskeyK | I also remember receiving complaint from dbus-glib about toolchain without gettext support, though I couldn't find anything about gettext in toolchain |
| 08:49.04 | DuratarskeyK | kos_tom: okay |
| 08:49.38 | kos_tom | DuratarskeyK: if you have build issues, please file reports in the bugzilla with the .config file. |
| 08:50.00 | DuratarskeyK | is build log needed ? |
| 08:50.22 | Jacmet | DuratarskeyK: no, but any extra info you have might help |
| 08:50.37 | Jacmet | DuratarskeyK: typically just the last 20 lines of otput or so |
| 08:50.38 | nataraj | http://pastebin.org/404610 |
| 08:50.52 | nataraj | but i didn't use ncurses at all |
| 08:51.55 | Jacmet | nataraj: presumably something depends on ncurses |
| 08:52.20 | DuratarskeyK | can I expect bash working with UTF8 locales if it is compiled against uclibc ? |
| 08:52.42 | Jacmet | nataraj: can you pastebin grep 'BR2_PACKAGE_.*=y' .config? |
| 08:54.53 | nataraj | Jacmet, http://www.pastebin.org/404617 |
| 08:55.59 | Jacmet | nataraj: ok, mysql-client depends on ncurses |
| 08:56.22 | Jacmet | nataraj: so what are those funky characters in ../ncurses/curses.priv.h:584 ? |
| 08:56.46 | Jacmet | nataraj: what locale do you use on the host? |
| 08:57.38 | nataraj | <PROTECTED> |
| 08:57.48 | nataraj | that what is on 584 |
| 08:58.30 | nataraj | LANG=en_US.UTF-8 |
| 08:59.38 | Jacmet | nataraj: odd that it tries to build for the host |
| 09:00.33 | Jacmet | nataraj: sorry, misred - it's a host tool |
| 09:00.33 | nataraj | <PROTECTED> |
| 09:01.05 | Jacmet | nataraj: what host distribution is this on? can you build ncurses-5.7 natively? |
| 09:01.32 | nataraj | debian lenny |
| 09:05.45 | Jacmet | nataraj: could you try building ncurses natively (./configure && make)? |
| 09:08.43 | nataraj | done, but same result |
| 09:09.28 | Jacmet | nataraj: so ncurses apparently doesn't build on lenny anymore |
| 09:10.10 | Jacmet | nataraj: not sure what we can do about that, either upgrade or bring it to the attention of the ncurses developers |
| 09:11.13 | kos_tom | ncurses has a crappy development model. It has no public VCS, and there are incremental patches being made available with a crazy organization scheme. |
| 09:12.23 | Jacmet | kos_tom: sigh :/ |
| 09:13.45 | kos_tom | however, I think we might need to build ncurses for the host. The ncurses build process uses a program called "tic" (term info compiler ?) and the tic of old ncurses breaks when building newer ncurses. |
| 09:13.51 | kos_tom | it has been reported/investigated on the list. |
| 09:15.15 | Jacmet | kos_tom: ok, but that won't fix a ncurses (host) build failure |
| 09:17.18 | kos_tom | Jacmet: no. |
| 09:17.38 | kos_tom | but I'm using a Debian Lenny chroot here, and ncurses built fine last time I tried. |
| 09:19.04 | Jacmet | kos_tom: when was that? we bumped ncurses on the 8th of June |
| 09:20.05 | kos_tom | I think I built it since then, but I can't be 100% sure. Will try. |
| 09:20.34 | Jacmet | kos_tom: thanks! |
| 09:30.34 | nataraj | ok, so where does this leave me? |
| 09:31.27 | nataraj | another distro? |
| 09:38.36 | Jacmet | nataraj: if it works for kos_tom then thee's presumably something wrong with your installation |
| 09:38.49 | kos_tom | wait, wait, I haven't tested yet. |
| 09:39.12 | Jacmet | kos_tom: yeah- "if" |
| 10:03.00 | kos_tom | Jacmet: nataraj ncurses builds fine here inside a Debian Lenny chroot. See http://free-electrons.com/~thomas/pub/ncurses.log |
| 10:03.22 | kos_tom | nataraj: can you post your full .config, with the toolchain configuration ? |
| 10:07.59 | Jacmet | kos_tom: ok, good (for us) - Thanks |
| 10:14.24 | kos_tom | Jacmet: for the gtk thing, one proposal: have separate gtk-dfb and gtk packages. gtk-dfb is 2.12, gtk is 2.20+. gtk-dfb is marked deprecated and will be dropped after 2010.08. |
| 10:14.45 | kos_tom | another solution is to have both versions handled by the gtk package, but it's going to be a bit messy. |
| 10:23.57 | Jacmet | kos_tom: a seperate package would mean complicating every package dependending on gtk, right? |
| 10:24.52 | Jacmet | depends on BR2_PACKAGE_GTK || BR2_PACKAGE_GTK_DFB and blah_DEPENDENCIES += $(if $(BR2_PACKAGE_GTK_DFB),gtk-dfb,gtk) |
| 10:35.26 | kos_tom | argh, yes. |
| 10:35.34 | kos_tom | ok, will do with one package then. |
| 10:35.57 | nataraj | Jacmet, i had disabled qt and done a 'make clean', after which it built well |
| 10:36.11 | nataraj | now enabled qt and building |
| 10:36.32 | nataraj | awaiting any ncurses issues |
| 10:43.53 | Jacmet | nataraj: I don't see the connection between you building qt in buildroot and ncurses failing when you building it for the host completely outside buildroot |
| 10:50.55 | *** join/#uclibc y_morin (~ymorin@ARennes-256-1-94-100.w90-32.abo.wanadoo.fr) |
| 10:56.03 | Jacmet | y_morin: hi |
| 11:15.40 | *** join/#uclibc nataraj (~nataraj@122.165.223.135) |
| 11:24.53 | *** join/#uclibc matteo (~matteo@openwrt/developer/matteo) |
| 11:29.07 | nataraj | jacmet, ncurses building in BR is for the target, aint it? |
| 11:29.23 | kos_tom | grr, the infamous "../libtool: line 828: X--tag=CC: command not found" libtool issue. |
| 11:31.29 | Jacmet | nataraj: yes, but you just told us that you couldn't build ncurses for your host outside buildroot |
| 11:33.13 | nataraj | build i could, (./configure; make;make install) but no difference in BR outcome |
| 11:33.33 | Jacmet | nataraj: ahh, good to know |
| 11:33.47 | nataraj | before a 'make clean ; make' |
| 11:33.53 | Jacmet | kos_tom: the test you did in the chroot, was that just ncurses for the host or for the target in br? |
| 11:35.30 | kos_tom | Jacmet: ncurses for the target in BR. |
| 11:36.14 | Jacmet | kos_tom: ok, thanks |
| 11:36.45 | Jacmet | nataraj: I guess the way forward is to post your .config to the mailing list or bugzilla so we can see if we can reproduce the problem |
| 11:37.03 | Jacmet | nataraj: if we cannot, then I'm afraid you'll have to dig deeper yourself |
| 11:38.23 | nataraj | i had done a dpk-reconfigure locales and disable en_IN, donno about the impact, BTW qt compilation is going on |
| 11:40.25 | nataraj | Jacmet, may i ask, does java in BR use jazelle ? my board is an arm926ej-s |
| 11:42.58 | Jacmet | nataraj: no it doesn't |
| 11:43.15 | Jacmet | nataraj: I'm not aware or any open source jvms supporting jazelle |
| 11:51.31 | nataraj | jazelle is closed? |
| 11:53.39 | *** join/#uclibc tsukasa` (~tsukasa@unaffiliated/tsukasa) |
| 11:55.56 | kos_tom | nataraj: yes |
| 11:56.41 | Jacmet | nataraj: yes |
| 11:56.48 | Jacmet | kos_tom: too fast ;) |
| 11:57.13 | Jacmet | nataraj: https://secure.wikimedia.org/wikipedia/en/wiki/Jazelle |
| 12:27.41 | *** join/#uclibc calculus (~calculus@gentoo/user/calculus) |
| 12:35.04 | nataraj | Jacmet, got "rw-r--r-- 1 root root 41447424 2010-07-19 17:47 output/images/rootfs.ext2" |
| 12:37.50 | nataraj | what coulda happened? stale files? |
| 12:40.10 | Jacmet | nataraj: what was you expecting? |
| 12:41.15 | nataraj | well, didnt get any ncurses issues this time |
| 12:43.07 | Jacmet | nataraj: so what is the problem? |
| 12:48.13 | nataraj | i believe there is no problem now |
| 12:50.28 | Jacmet | nataraj: if you find 40MB too big, take a look with ls -lahRS in output/target to see what the biggest files are |
| 12:50.39 | *** join/#uclibc bkuhn (~bkuhn@fsf/director/conservancy.president.bkuhn) |
| 12:50.41 | Jacmet | nataraj: and evaluate if you really need those |
| 12:54.10 | nataraj | Jacmet, 13353756 2010-07-19 18:06 /buildroot/output/images/rootfs.jffs2 , that's cool |
| 12:55.30 | nataraj | BR2_MKLIBS=y ,does it make a big difference? |
| 12:56.05 | Jacmet | nataraj: not in my experience |
| 12:59.27 | nataraj | now to check a proprietory libusb-0.1 app, i did have some problems with later version of BR , with BR2_MKLIBS=y |
| 13:12.16 | *** join/#uclibc matteo` (~matteo@openwrt/developer/matteo) |
| 13:29.08 | *** join/#uclibc Kiff (Kiff@187.42.233.220.static.exetel.com.au) |
| 14:02.28 | CIA-46 | 03jacmet 07master * r4e302ac83d89 10buildroot/ (3 files in 2 dirs): avahi: bump version |
| 14:03.27 | kos_tom | Jacmet: FWIW, as I said this morning, I'm working on bumping atk/cairo/pango/webkit/libsoup/midori using dj-death and other fixes. So no need to merge those ones (they are pending since february) |
| 14:08.59 | kos_tom | Jacmet: hu, there's already support for systemd in Avahi. systemd is Lenart Poetring's init, isn't it ? |
| 14:10.30 | Jacmet | kos_tom: yes, and avahi is (was?) also Lennarts baby |
| 14:10.57 | Jacmet | kos_tom: ok, I won't touch those then |
| 14:12.32 | kos_tom | Jacmet: what are the other release goals for 2010.08 ? |
| 14:14.26 | Jacmet | kos_tom: as stated in the announcement - http://lists.busybox.net/pipermail/buildroot/2010-May/034878.html |
| 14:14.26 | Jacmet | kos_tom: have you looked closer at y_morin's rfc toolchain patches? |
| 14:14.50 | kos_tom | Jacmet: I reviewed an earlier version, which I was ok with. I haven't reviewed the latest post, though, but I think it's ok. |
| 14:15.30 | Jacmet | kos_tom: ok, thanks |
| 14:15.33 | kos_tom | Jacmet: goal 1, conversion of to infrastructures, we're down to ~50 packages to convert to autotargets and ~50 packages to convert to gentargets |
| 14:15.56 | kos_tom | goal 2, work with ct-ng, not done. Not sure we'll have the time before the release |
| 14:16.13 | kos_tom | goal 3, uninstallation, not done. To me a conversion to all packages to the infrastructures is a requirement before doing this |
| 14:16.46 | kos_tom | goal 4, testing, not done (I personaly have a much better setup for testing than before, but nothing really permanent and automatic) |
| 14:17.01 | Jacmet | kos_tom: agreed about point 3 |
| 14:17.09 | kos_tom | the other goals I had were: bootloaders cleanup, linux cleanup and board cleanup. The first two are done, the last one no. |
| 14:17.31 | Jacmet | kos_tom: I'll give 4 a shot after I tended to most pending patches |
| 14:18.33 | Jacmet | kos_tom: no biggie - I think it's looking a lot better than a few months ago already |
| 14:20.29 | kos_tom | yes, I'm also quite satisfied with the progress we're making. It also seems that we have more people reporting issues on the list, which probably means that we have more users. |
| 14:20.40 | Jacmet | kos_tom: exactly |
| 14:35.43 | dj-death | kos_tom: don't you think that uninstallation could be handled in an efficient way by generating packages/tarballs of the install-target result ? |
| 14:36.09 | *** join/#uclibc mnt_real (~sinan@bas1-montreal43-2925255368.dsl.bell.ca) |
| 14:36.43 | kos_tom | dj-death: you want to tarball the full target/ directory ? |
| 14:36.54 | kos_tom | after every package installation ? |
| 14:37.04 | dj-death | not exactly |
| 14:37.05 | kos_tom | FWIW, uninstallation must also be done in host/ and staging/ |
| 14:38.18 | dj-death | I would to make an installation to somewhere like $(OUTPUT)/build/$(pkgname)_$(pkgversion)_target to tarball that |
| 14:38.54 | dj-death | so we can install/uninstall it to $(OUTPUT)/target |
| 14:39.05 | dj-death | would like |
| 14:39.15 | kos_tom | yes. Would have to see how it is possible to override TARGET_DIR differently for each package |
| 14:39.25 | kos_tom | but again, target/ is not sufficient at all. |
| 14:39.56 | dj-death | yes |
| 14:41.59 | dj-death | maybe using $(@D) |
| 14:42.19 | kos_tom | well in the TARGET_INSTALL steps, $(@D) is already the build directory |
| 14:42.31 | kos_tom | so many packages do "cp $(@D)/something $(TARGET_DIR)/usr/bin" |
| 14:42.59 | dj-death | hmmm... |
| 14:43.03 | dj-death | nice try :( |
| 14:44.05 | kos_tom | but definitely something is possible, someone needs to start hacking. As I said, as of today, this isn't my top priority because there are other things to fix before, but if you want to jump in and start proposing an implementation, feel free |
| 14:44.11 | dj-death | otherwise we would have to generate a PKG_NAME_TARGET_DIR variable |
| 14:44.54 | dj-death | just wanted to know if people are interested |
| 14:45.44 | Jacmet | kos_tom: we could either introduce per-package install dirs (FOO_TARGET_DIR) or simply override the value for the .stamp_target_installed (and host/staging) targets |
| 14:46.08 | Jacmet | kos_tom: like it's done for the PKG variable |
| 14:46.19 | kos_tom | Jacmet: yes. |
| 14:46.58 | kos_tom | dj-death: I'm definitely interested in seeing what we can come up with me, how much it would complexity BR usage for the user that doesn't need this, etc. |
| 14:47.07 | kos_tom | s/complexity/complexify/ |
| 14:47.10 | Jacmet | kos_tom: the last is easier to do, but kind of icky (basically you make a local variable shadow the global one for that target) |
| 14:47.51 | Jacmet | kos_tom: which certainy doesn't help readability |
| 14:48.56 | Jacmet | certainly even |
| 14:49.44 | dj-death | hmm |
| 14:49.47 | dj-death | indeed |
| 14:54.02 | dj-death | hmm |
| 14:55.09 | dj-death | TARGET_DIR could be a define of a function using the package name to build the path to per-packaget target directory |
| 14:56.06 | dj-death | I will try that later ;) |
| 14:57.35 | Jacmet | dj-death: you can simply do $(FOO_TARGET_INSTALL_TARGET): TARGET_DIR=blah |
| 14:58.06 | dj-death | really ?? |
| 14:59.55 | Jacmet | dj-death: yes - see how we do it for the PKG variable in package/Makefile.package.in |
| 15:00.57 | dj-death | whoa ;) |
| 15:01.13 | dj-death | it's going to be easy |
| 15:02.16 | *** join/#uclibc gustavoz (~gustavoz@host94.201-252-15.telecom.net.ar) |
| 15:27.15 | *** join/#uclibc kos_tom_ (~thomas@humanoidz.org) |
| 15:50.09 | *** join/#uclibc austinf (~austinf@74.92.231.110) |
| 16:31.07 | *** join/#uclibc matteo (~matteo@openwrt/developer/matteo) |
| 16:38.32 | y_morin | Jacmet: Hello! |
| 16:39.17 | y_morin | Jacmet: someone had a comment about the patch #5 in the series, and maybe that one can be dropped for now |
| 16:39.42 | y_morin | It's only purely for esthetics, and the renaming can be done later... |
| 17:14.49 | *** join/#uclibc bkuhn (~bkuhn@fsf/director/conservancy.president.bkuhn) |
| 17:19.30 | *** join/#uclibc matteo` (~matteo@openwrt/developer/matteo) |
| 18:00.23 | *** join/#uclibc trem (~trem@mol92-1-81-57-136-23.fbx.proxad.net) |
| 18:09.31 | kos_tom | -rwxr-xr-x 1 test test 14M Jul 19 18:03 libwebkit-1.0.so.2.17.5 |
| 18:09.31 | kos_tom | -rw-r--r-- 1 test test 11M Jul 19 10:10 libicudata.so.38.1 |
| 18:09.32 | kos_tom | ouch |
| 18:09.50 | khem | heh |
| 18:09.56 | khem | kos_tom: stripped ? |
| 18:11.56 | kos_tom | $ file libwebkit-1.0.so.2.17.5 |
| 18:11.57 | kos_tom | libwebkit-1.0.so.2.17.5: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, stripped |
| 18:15.53 | kos_tom | it means that a system with TinyX + Gtk2 + WebKit + Midori takes 82 MB |
| 18:23.38 | Jacmet | kos_tom: uch! |
| 18:24.56 | Jacmet | kos_tom: In a meeting last week some guy said 'we're going to make it really stripped down an simple - just webkit on directfb and do the UI in html and javascript' <- we seem to have a different idea of stripped down |
| 18:25.20 | Jacmet | y_morin: ok, thanks |
| 18:26.07 | Jacmet | kos_tom: I'm btw pretty certain that the xserver dependencies in BR is wrong for tinyx, some of the stuff is not needed |
| 18:26.10 | y_morin | Jacmet: Hey! I'm off for dinner in a few minutes, will be back around 21h30 GMT+2 |
| 18:26.19 | Jacmet | y_morin: ok, enjoy |
| 18:26.21 | kos_tom | Jacmet: why ? |
| 18:26.40 | kos_tom | Jacmet: on the server side, we don't build anything. However, on the client side, you need quite a few things to compile, e.g gtk2 |
| 18:27.17 | Jacmet | kos_tom: E.G. select BR2_PACKAGE_XLIB_LIBPCIACCESS <- tinyx afaik doesn't do anything with pci |
| 18:27.56 | Jacmet | kos_tom: openssl can afaik also relatively easily be patched out - it's only used for the sha1() implementation |
| 18:28.24 | kos_tom | Jacmet: yeah, it's on my TODO-list to use libmd instead of a full blown openssl. |
| 18:29.18 | kos_tom | Jacmet: well, for libpciaccess, probably, but it's only 22 KB. On the 82 MB I have, won't make a huge difference :-) |
| 18:29.32 | Jacmet | kos_tom: there afaik was some patches floating around a few months ago to do so |
| 18:30.15 | Jacmet | kos_tom: true - my point is just that if you take a closer look (besides webkit/icu) then the X stack can get trimmed quite a bit |
| 18:30.45 | kos_tom | Jacmet: yes, certainly. |
| 18:37.08 | Jacmet | kos_tom: something like http://people.freedesktop.org/~vignatti/scrutinizing-x-mem/0001-Revert-Revert-Render-Use-built-in-SHA1-library.patch |
| 18:37.18 | Jacmet | kos_tom: a variant on that patch is afaik in xserver tip |
| 18:39.03 | kos_tom | if it's in tip, then we'll just wait for it to land in the next xserver release, no? |
| 18:39.43 | Jacmet | kos_tom: well, yes - but xserver 1.9 will also mean we'll need to bump a bunch of deps |
| 18:39.50 | kos_tom | I also wanted to look at Xfbdev startup time, but didn't had the time to dig into this. |
| 18:40.04 | Jacmet | kos_tom: E.G. like the 7.4 -> 7.5 patches we had a little while ago |
| 18:40.18 | kos_tom | we can do that after 2010.08, can't we ? |
| 18:40.40 | Jacmet | kos_tom: yes, we 1.9 first needs to get released ;) |
| 18:50.00 | *** join/#uclibc gustavoz (~gustavoz@host91.201-252-5.telecom.net.ar) |
| 18:56.50 | dj-death | kos_tom: are you using the last webkit/gtk+ (from http://webkitgtk.org/) ? |
| 18:57.16 | kos_tom | dj-death: yes, 1.2.3 |
| 18:57.29 | kos_tom | dj-death: I started from your patches. |
| 18:57.44 | dj-death | 'k |
| 18:57.53 | kos_tom | I'll try to push them a little bit harder than you did to get them merged by Peter :) |
| 18:58.05 | dj-death | heh ;) |
| 18:58.22 | dj-death | at the time my boss really wanted webkit to work on sh4 |
| 18:58.47 | dj-death | I didn't have much time to fix all problems |
| 18:58.54 | dj-death | especially with gtk.. |
| 18:59.08 | kos_tom | well, I'm doing gtk over X11 |
| 18:59.34 | dj-death | a little less painfull |
| 18:59.43 | dj-death | than dfb |
| 19:00.17 | dj-death | webkit is so fat ;) |
| 19:03.36 | Jacmet | dj-death: yeah, it sounds like it |
| 19:03.53 | Jacmet | dj-death: what about memory consumption? also fat? |
| 19:04.36 | dj-death | I would say not more than a basic gtk+ applications |
| 19:05.17 | dj-death | I didn't had any problem to launch up to 9 webkit/gtk+ apps on a 150Mb system |
| 19:05.23 | Jacmet | dj-death: ok |
| 19:05.24 | dj-death | with 32Mb of video memory |
| 19:05.54 | dj-death | but it's slow if you don't have cache |
| 19:06.33 | dj-death | I was using a non cached webkit |
| 19:08.35 | dj-death | we have a plan in my next company to rewrite a webkit backend |
| 19:08.46 | dj-death | using libmx (the clutter based toolkit) |
| 19:11.30 | dj-death | http://gitorious.org/webkitgtk/stable/blobs/master/WebKit/gtk/webkit/webkitwebview.cpp copyright is impressive ;) |
| 19:12.47 | kos_tom | dj-death: who are you working for these days? |
| 19:14.22 | dj-death | http://nds.com/ until july 29th |
| 19:14.36 | dj-death | then http://pace.com |
| 19:19.28 | khem | dj-death: pace.com |
| 19:19.35 | khem | in LA or in FL |
| 19:19.44 | khem | or UK |
| 19:19.58 | khem | dj-death: my childhood buddy works for pace |
| 19:20.41 | khem | Jacmet: kos_tom it would be nice if you could release the new toolchain build sequence in upcoming BR release |
| 19:20.42 | dj-death | france ;) |
| 19:20.50 | khem | dj-death: ah |
| 19:20.57 | khem | will you be hacking on BR |
| 19:21.14 | gustavoz | do we have a nice way of stripping -Werror on BR? or just patch it away? |
| 19:21.23 | dj-death | khem: I hope |
| 19:21.39 | dj-death | khem: at least that how I will cross compile my stuff ;) |
| 19:21.42 | khem | dj-death: I know they have broadcom stuff |
| 19:22.01 | dj-death | khem: I will work on ST stuff |
| 19:22.06 | dj-death | crappy ST stuff... |
| 19:22.07 | khem | hmm ok |
| 19:22.18 | khem | ST is not that crappy |
| 19:22.24 | khem | will you be doing SH4 |
| 19:22.28 | dj-death | yes |
| 19:22.30 | khem | or new ARM based |
| 19:22.36 | khem | dj-death: ah ok |
| 19:22.41 | dj-death | khem: then you don't know about their drivers |
| 19:22.45 | khem | So you will be working on Carmelo's work :) |
| 19:23.01 | khem | let me know if you have any good or bad words to pass on to him hehe |
| 19:23.11 | dj-death | arf |
| 19:23.30 | dj-death | khem: surely good words |
| 19:23.49 | khem | dj-death: I think you will be using SH4/nptl/uclibc |
| 19:23.52 | khem | thats cool |
| 19:24.19 | dj-death | I've been using it since more than 2 years now |
| 19:24.22 | khem | now if we add to BR with the patch I posted you should be good to go |
| 19:24.38 | khem | dj-death: SH4/uclibc/nptl ? |
| 19:24.48 | dj-death | khem: sh4/glibc |
| 19:24.59 | khem | well glibc is a different story |
| 19:25.09 | khem | I though ST SDKs have uclibc on them |
| 19:25.10 | dj-death | khem: but your patch isn't about external toolchains |
| 19:25.17 | khem | no |
| 19:25.26 | khem | its for internal BR toolchain |
| 19:25.55 | khem | but external toolchain have also done the same think based on stuff I did in 2004 |
| 19:26.02 | dj-death | I don't think I'm going to integrate all the ST patches to uclibc inside buildroot |
| 19:26.49 | khem | dj-death: plus the version you will get is older than the one we have in uclibc master |
| 19:27.10 | dj-death | yes |
| 19:27.31 | khem | pace is doing good though I heard |
| 19:27.38 | khem | gustavoz: howdy |
| 19:27.58 | gustavoz | khem: hi |
| 19:28.01 | Jacmet | khem: I'm planning on merging the nptl stuff before the release, yes |
| 19:28.26 | khem | Jacmet: thats nice |
| 19:28.42 | khem | Jacmet: I have some cycles to fix things if they fall apart |
| 19:28.50 | khem | but I think it will be ok |
| 19:29.12 | dj-death | khem: I heard good things about the company too |
| 19:29.50 | khem | my buddy is quite excited |
| 19:29.59 | khem | although he wont be programming anymore |
| 19:30.05 | khem | there |
| 19:30.32 | Jacmet | khem: good |
| 19:31.27 | khem | Jacmet: at some point I was thinking same gcc src tree could be reused to do all three stages of cross compile |
| 19:31.28 | gustavoz | kos_tom: net-snmp almost done, testing linking stuff against it, also dropped the ucd compat bits (no other package used netsnmp so no breaks there and it's smaller) |
| 19:31.35 | khem | it wud speed up toolchain build |
| 19:31.41 | khem | but thats for future |
| 19:32.07 | kos_tom | gustavoz: ok, great. Are you testing both internal and external toolchains ? |
| 19:32.28 | gustavoz | kos_tom: only internal for now, it's supposedly broken for external but maybe this unbreaks it |
| 19:32.32 | y_morin | khem: hello! |
| 19:32.40 | y_morin | khem: but isn't that the case already? |
| 19:32.43 | khem | hmmm ldmia {r4,pc} should branch to calling function and also change mode based on value it fetches into pc |
| 19:32.48 | khem | but it seems it does not do that |
| 19:32.48 | y_morin | We build out-of-tree |
| 19:33.07 | khem | y_morin: I mean for objects and srcs |
| 19:33.35 | y_morin | khem: you mean build static-core + shared-core + final in the same directory ? |
| 19:33.44 | khem | yes |
| 19:35.18 | y_morin | khem: currently, building static-core is roughly 2mins while full final (C/C++/java/Fortran) takes roughly 25mins on my machine. |
| 19:35.39 | y_morin | khem: and for static-core, most is due to ./configure. |
| 19:35.42 | khem | y_morin: yeah thats what I wud expect |
| 19:35.54 | y_morin | Sounds like it's not a very impressive gain... |
| 19:36.05 | khem | y_morin: prolly less than 5 mins for shared-core |
| 19:36.18 | khem | y_morin: in that case yes |
| 19:36.27 | y_morin | khem: shared-core is les than 4mins here. |
| 19:36.49 | y_morin | Of course, if final is only C, then there's a gain! :-) |
| 19:36.54 | khem | y_morin: ok so effective I am adding 2 mins of build time to BR toolchain |
| 19:37.20 | khem | y_morin: yeah BR is mosting C,C++ |
| 19:37.37 | y_morin | khem: right. |
| 19:41.17 | khem | oh hum |
| 19:41.45 | khem | armv4t ldmia {r4,pc} is not interworking safe |
| 19:41.50 | khem | thats it |
| 19:41.59 | khem | now to fix it |
| 19:42.55 | khem | heh gcc is configured for armv5t |
| 19:42.58 | khem | no good |
| 19:43.59 | y_morin | khem: gcc has the bad habit to default to armv5t for EABI, IIRC... |
| 19:44.07 | khem | yep :) |
| 19:44.20 | y_morin | but I guess you know! ;-) |
| 19:44.24 | y_morin | hehe! |
| 19:44.31 | khem | more than that I am using TARGET_CC_ARCH = "-march=armv5te -mtune=arm926ej-s" |
| 19:44.43 | y_morin | Tss... :-) |
| 19:47.41 | khem | The ARM926EJ-S processor implements the ARMv5TEJ instruction set |
| 19:47.54 | khem | hrmmm so seems qemu is confused |
| 19:48.20 | y_morin | Ho, so qemu executes ldmia as if it was on a armv4t, that's it ? |
| 19:48.29 | khem | yes seems so |
| 19:48.36 | y_morin | Ouch... |
| 19:48.41 | khem | and actually it segfaults the program |
| 19:58.46 | khem | root@qemuarm:~# cat /proc/cpuinfo |
| 19:58.46 | khem | Processor : ARM926EJ-S rev 5 (v5l) |
| 20:00.32 | *** join/#uclibc animeloe[net] (~animeloen@unaffiliated/animeloe) |
| 20:06.31 | y_morin | khem: with: qemu-system-arm -cpu arm926 ? |
| 20:58.16 | khem | y_morin: I used -M |
| 20:58.36 | khem | y_morin: but that -M means -cpu arm926 |
| 21:18.34 | dj-death | awesome |
| 21:18.52 | dj-death | Jacmet: your trick works like a charm |
| 21:19.09 | dj-death | just need to generate package/tarball |
| 21:19.12 | dj-death | now |
| 21:23.57 | Jacmet | dj-death: cool |
| 21:24.39 | Jacmet | kos_tom: we have a new buildbot server ;) - 12-cores Magny-Cours @ 1.5GHz, 64GB RAM |
| 21:25.04 | dj-death | 11111111111111111111111111111111111111 |
| 21:25.07 | dj-death | oups |
| 21:25.11 | Jacmet | kos_tom: amd sponsored to fsffrance |
| 21:25.22 | dj-death | lol |
| 21:25.23 | y_morin | Jacmet: Magny-Cours! This is a well-known racing circuit here in France! |
| 21:25.27 | dj-death | Magny-Cours ;) |
| 21:25.57 | dj-death | Jacmet: 12 cores ? is that x86 based ? |
| 21:27.13 | y_morin | dj-death: Core i7 970 is hexa core with HT. |
| 21:27.19 | trem | nite all, sweet dreams |
| 21:27.44 | y_morin | Get two of them, you have 12 cores |
| 21:28.15 | y_morin | As a bonus, you have 24 hyper-threads |
| 21:28.26 | Jacmet | dj-death: yeah |
| 21:28.39 | dj-death | y_morin: 'k |
| 21:28.43 | dj-death | what a monster ;) |
| 21:29.31 | y_morin | likes Carmina Burana when coding! What a delight! |
| 21:30.41 | khem | y_morin: its not 970 it 975 |
| 21:30.52 | khem | 975 is on 32nm technology |
| 21:30.53 | khem | too |
| 21:32.01 | khem | ugh actually Intel Core i7 980X |
| 21:32.08 | khem | is the one with 6 cores |
| 21:32.21 | khem | chip itself is 999 USD :) |
| 21:32.55 | y_morin | EU: 1050 Euros... :-/ |
| 21:33.03 | *** join/#uclibc bernardl (~bernardl_@sxmail.verseon.com) |
| 21:33.08 | khem | AMD Phenom II X6 1090T is like 300 USD |
| 21:33.11 | y_morin | So we can say that we USD-Euros parity ! |
| 21:33.13 | khem | and has 6 cores |
| 21:33.14 | bernardl | hello all |
| 21:33.29 | y_morin | khem: yes, seems the beast is AMD-based. |
| 21:33.29 | bernardl | does anybody know if busybox awk supports -F '\t' (tab) ? |
| 21:33.57 | khem | y_morin: I am looking into buying a new box have you any comments or comparision on these two |
| 21:34.18 | khem | like corei7 930 and phenom II 6 core |
| 21:34.21 | y_morin | khem: not at all... Personnaly, I've had bad experience with AMD |
| 21:34.28 | khem | yeah me too |
| 21:34.34 | y_morin | But before that I was all-AMD |
| 21:34.41 | khem | but 1000 bvs 300 is a big gap |
| 21:34.44 | y_morin | And now I'm all-Intel |
| 21:34.48 | *** join/#uclibc bkuhn (~bkuhn@fsf/director/conservancy.president.bkuhn) |
| 21:34.57 | khem | I have a really poor laptop |
| 21:35.08 | y_morin | khem: definitely. Maybe for the same price you get dual-processor with AMD. |
| 21:35.16 | khem | not good for when you are building gcc 25 times a day |
| 21:35.40 | khem | I am looking for high end desktop |
| 21:35.44 | y_morin | Yes, that's why I bought my core2 quad two yeras ago. |
| 21:35.55 | khem | so core-i7 or phenom II 6 core |
| 21:36.08 | y_morin | AMD is not HT, Intel is. |
| 21:36.19 | khem | so 4cores mean 8 ? |
| 21:36.27 | khem | approx :) |
| 21:36.37 | kos_tom | Jacmet: eah, great! |
| 21:36.39 | y_morin | For pure compilation, it is roughly that, yes. |
| 21:36.47 | kos_tom | Jacmet: we'll find build issues faster than we can fix them :) |
| 21:36.57 | khem | y_morin: but hardware threads are still 4 |
| 21:37.03 | khem | and amd has 6 |
| 21:37.24 | khem | all boxes with i7 here are like 1500 usd |
| 21:37.27 | y_morin | khem: Intel hexa-core is 6 cores *and* 6 HT, so that makes it twelves HW threads. |
| 21:37.40 | khem | yeah |
| 21:37.42 | y_morin | AMD hexa-core is 6 cores, period. |
| 21:37.55 | khem | but I wil wait untill 2012 for those |
| 21:38.10 | y_morin | And hyper-threads are almost like real cores when you stick to integral computations. |
| 21:38.14 | khem | right now no money for beast |
| 21:38.20 | khem | yes |
| 21:38.40 | khem | y_morin: so in theory I could do make -j24 |
| 21:38.41 | y_morin | khem: money, money, must be funny... :-) |
| 21:39.10 | y_morin | khem, on a 6-core + HT, you have roughly ~= 12 cores. |
| 21:39.26 | khem | right and schedule 2 make jobs per core for best use |
| 21:39.31 | khem | or may be 1.5 |
| 21:39.37 | khem | which will be -j18 |
| 21:39.42 | y_morin | I do 1.5 here. |
| 21:39.49 | khem | hmm |
| 21:40.03 | khem | core2duo * 1.5 is -j6 ? |
| 21:40.08 | y_morin | And with a lot of RAM, all sources are in cache, so HDD is no bottle-neck. |
| 21:40.28 | khem | right and its DDR3 |
| 21:40.29 | y_morin | core2duo has no HT, so it is aonly 2 cores. |
| 21:40.29 | khem | :) |
| 21:40.54 | khem | right |
| 21:41.05 | khem | -j3 ? |
| 21:41.05 | y_morin | core2 quad * 1.5 is -j6 for me. |
| 21:41.19 | y_morin | core2duo: I'd go to -j4 |
| 21:41.30 | khem | all i7 have HT ? |
| 21:41.34 | y_morin | for small # of procs, I use *2, but |
| 21:41.47 | y_morin | i7: not so sure, but I think so... |
| 21:41.53 | y_morin | khem: http://en.wikipedia.org/wiki/Core_i7 |
| 21:42.54 | y_morin | khem: http://en.wikipedia.org/wiki/List_of_Intel_Core_i7_microprocessors |
| 21:43.06 | y_morin | khem: yes all i7 are HT. |
| 21:44.30 | y_morin | khem: and all have VT-x |
| 21:47.58 | khem | right |
| 21:48.31 | khem | I wonder why they did not put DDR3-1333 on 9xx series |
| 21:51.57 | Jacmet | ok, opening a 40MB .pdf with the openoffice pdfimport plugin wasn't a good idea - OOM killed most of my session |
| 21:54.53 | dj-death | ahaha ;) |
| 21:56.34 | dj-death | I read an article on lwn about the oom enhancement, about the value you set to process to make oomkiller a little bit smarter |
| 21:57.13 | dj-death | flash/mozilla/oo.org are definitively the ones you want to kill FIRST :) |
| 21:57.21 | Jacmet | dj-death: the OOM killer took down a bunch of processes - but it didn't touch the offending soffice.bin :/ |
| 21:57.48 | dj-death | too bad |
| 21:57.53 | Jacmet | splitting the pdf with pdftk before loading seems to be the way to go |
| 22:29.30 | *** join/#uclibc animeloe[net] (~animeloen@unaffiliated/animeloe) |
| 23:08.58 | *** join/#uclibc animeloe[net] (~animeloen@pool-71-190-171-38.nycmny.fios.verizon.net) |
| 23:09.03 | *** join/#uclibc animeloe[net] (~animeloen@unaffiliated/animeloe) |
| 23:10.00 | *** join/#uclibc animeloe[net] (~animeloen@unaffiliated/animeloe) |