**** BEGIN LOGGING AT Thu Oct 01 02:59:59 2015 Oct 01 07:38:38 build #103 of cobalt is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/cobalt/builds/103 Oct 01 07:41:07 build #103 of cns21xx is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/cns21xx/builds/103 Oct 01 07:46:07 build #103 of orion is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/103 Oct 01 08:09:48 txomon|sauron: so far all projects that i've seen using scons were annoying to deal with, especially regarding cross compiling Oct 01 08:16:31 nbd: yeah, me too, but I have seen potential in there... Those were complex projects, although maybe they were wrong already and scons was just a way to make them compile Oct 01 08:17:55 crosscompiling in scons they should probably give guidelines at least about how to make a good project Oct 01 08:18:17 it's like using python without any pep nor anything else... There are good and bad ways of doing things Oct 01 08:32:09 txomon: i think that's just a natural downside of encouraging people to use the power of a full programming language just for making a package build system Oct 01 08:32:25 that leads to more people coming up with strange convoluted custom build hackery Oct 01 08:32:48 which they might not have needed in the first place if they had built it in a more standard way Oct 01 08:33:15 the kde attempt at using scons seems to have been a big dysfunctional mess Oct 01 08:33:21 after that attempt, they tried cmake Oct 01 08:33:23 and it worked Oct 01 08:34:33 nbd: probably Oct 01 08:35:06 anyway I still don't fully like the idea of generating a makefile from cmakelists... I would prefer it to run automatically Oct 01 08:37:54 main downside of cmake is that it is relatively .. ugly .. and complex set of magic (variable X does Y) built-in features; main upside is that those magic features work on variety of platforms without per-package customization :p Oct 01 08:38:45 when i look at random projects using scons, they all seem to have custom hackery to try to be portable across linux, mac os x, etc. Oct 01 08:39:02 people also seem to have different ideas on how to handle build options Oct 01 08:39:16 i see lots of hardcoded path names in cflags and other places Oct 01 08:39:34 the cmake language is a bit ugly, yes Oct 01 08:39:56 but at least the build systems built with it usually turn out to be very simple and portable Oct 01 08:40:10 i take that over 'clean' python build code any day Oct 01 08:40:12 yep, and I consider it least of the evils due to that :) Oct 01 08:40:19 nbd: totally agree, that's why the guidelines should be written for scons Oct 01 08:40:27 worst is e.g. make+auto* hell Oct 01 08:40:38 indeed Oct 01 08:40:50 txomon: people don't read guidelines, if the language itself doesn't encourage consistency, people will build lots of wildly different crappy things Oct 01 08:41:12 the theoretical possibility of being able to build something clean becomes irrelevant Oct 01 08:41:24 nbd: you got the point Oct 01 08:47:18 this is an interesting read: https://lwn.net/Articles/188693/ Oct 01 08:47:37 though a bit old Oct 01 09:40:15 big downside of scons is so few people use it. Oct 01 09:42:32 karlp and what nbd said about not encouranging guidelines Oct 01 09:42:42 that is a must have really Oct 01 09:42:55 did anybody look into that new google buildsystem? Oct 01 09:42:56 else, please checkout allseen alliance software Oct 01 09:43:34 bazel or what it was called Oct 01 09:44:40 yes, bazel.io Oct 01 09:44:50 I haven't tested it yet, but seems promising Oct 01 09:45:30 cyrusff: oh, yet another build system :) let me guess its written in nodejs and go? Oct 01 09:45:54 jow_laptop: even better. Java! Oct 01 09:45:59 seems to be c++ Oct 01 09:46:10 https://github.com/bazelbuild/bazel Oct 01 09:46:11 whoa# Oct 01 09:46:26 you didn't expect that heh! Oct 01 09:46:29 haha Oct 01 09:46:33 so we can wrap the brokenness of auto* into yet an other build container Oct 01 09:46:49 the fuck it is really java Oct 01 09:46:52 lol Oct 01 09:46:52 to make it super cool we should distribute it as docker containers Oct 01 09:47:14 blink.. java, fast? Oct 01 09:47:15 because reproducing shit from source is for luddites Oct 01 09:47:21 never thought of seeing those in same sentence Oct 01 09:47:33 its appliance now, because appliances are cool Oct 01 09:47:37 who wouldn't want to use a java buildsystem for c/c++ Oct 01 09:48:06 java is fast Oct 01 09:48:16 the real problem is about memory usage Oct 01 09:48:36 I am not willing to have a 10-100x memory overcommit Oct 01 09:48:39 haha Oct 01 09:49:28 hah, bazel is actually client-server Oct 01 09:49:46 can't remember last time I saw such build system Oct 01 09:49:52 doesn't matter. its new, its google and its beta - it will be a winner Oct 01 09:50:09 txomon: do you really want to install 100MB of java vm for compiling? Oct 01 09:50:27 your buildsystem is 10x bigger than your compiler :P Oct 01 09:52:16 I like this example: https://github.com/bazelbuild/examples/blob/master/protobuf-2.5.0/BUILD.src.google.protobuf Oct 01 09:52:31 cyrusff: take into account that bazel is all about distributed. It's ccache + cdist Oct 01 09:52:38 a pythonic build manifest syntax, interpretered by a java vm and yet shelling out to massage configs with sed & awk Oct 01 09:53:17 my dream build system would be a docker based workers, distributed and cached Oct 01 09:53:35 sounds like buildbot with ccache Oct 01 09:53:37 docker because I don't want the burden of configuring, updating, etc. Oct 01 09:53:45 jow_laptop: it is Oct 01 09:54:05 the thing is that it's more advanced Oct 01 09:54:49 docker is mostly shit, they don't really emphasize reproducibility of the stuff -> 'look, ma, we have this 500MB blob of , want to use it'? Oct 01 09:55:07 for me, the answer is usually 'no, not really, for anything critical anyway' Oct 01 09:55:08 txomon: I'll be impressed if it solves the problems of inherent flaws in upstream build systems Oct 01 09:55:30 like broken autoconf projects, projects not made for cross compiilation etc. Oct 01 09:55:33 idli: ++ Oct 01 09:55:38 idli: is not meant to be used like that Oct 01 09:56:00 I create my own docker containers, and deploy there whenever I need to provide the service they give Oct 01 09:56:21 well, main argument _for_ docker is the binary blob library + magic binary blobs at Amazon + .. Oct 01 09:56:26 and I really don't need to care about the base system, I am sick of configuring, RHEL, CEntos, different versions of them, etc. etc. Oct 01 09:56:28 txomon: of course itsn ot meant to be like this but many people use it as excuse to not document / work on reproducible environments anymore Oct 01 09:56:32 I _do_ create my own docker blobs too, but I suspect I am in minority as the tooling is not really good for it Oct 01 09:56:59 jow_laptop: the Dockerfile is a way to reproduce the build system Oct 01 09:57:03 it's like using travis-ci Oct 01 09:57:10 I think that is the way to go Oct 01 09:57:16 not really, how do you create e.g. Debian image using Dockerfile? Oct 01 09:57:38 (answer lies in depths of debootstrap and not docker) Oct 01 09:58:01 idli: there are already images built using debootstrap Oct 01 09:58:06 I use them as a base Oct 01 09:58:10 magic binary blobs that you trust Oct 01 09:58:19 which frequently change their behavior to boot Oct 01 09:58:25 idli: I can build them if I wish to, I mean, is just download the Dockerfile and run it Oct 01 09:58:27 idle: http://www.vitavonni.de/blog/201503/2015031201-the-sad-state-of-sysadmin-in-the-age-of-containers.html Oct 01 09:58:27 e.g. they change the included package list at times semirandomly Oct 01 09:58:43 sorry, idli ^ Oct 01 09:58:48 idli: I just use base systems Oct 01 09:58:56 isn't it bit like .app on osx, hurr durr we overlay fs instead of installing? Oct 01 09:59:07 jow_laptop: haha, that's amusing :) Oct 01 09:59:36 my favourite installers are of type 'sudo wget http://.. -o -' Oct 01 09:59:37 yeah, I had read that one hahaha Oct 01 10:00:07 (well, not exactly that syntax, need `s etc but still) Oct 01 10:00:07 but at the end, if you are not reviewing all the code before compilation and compiling it yourself, you are trusting someone Oct 01 10:00:15 whole java ecosystem is a big fuckup Oct 01 10:00:23 or well webdevelopment in general Oct 01 10:00:26 my favorite quote is: "Stack is the new term for "I have no idea what I'm actually using"." Oct 01 10:00:33 jow_laptop: yeah hahaha Oct 01 10:00:40 you just include 100s of 3rd party libraries Oct 01 10:00:48 and combine them in magic ways Oct 01 10:01:08 txomon: docker is really nice if used properly, as always right tool right job yadda yadda Oct 01 10:01:18 indeed Oct 01 10:01:21 favourite quote: Essentially, the Docker approach boils down to downloading an unsigned binary, running it, and hoping it doesn't contain any backdoor into your companies network. Oct 01 10:01:27 anyway, I like gitlab due to that Oct 01 10:01:33 I do not dislike docker but the docker mentality many projects have Oct 01 10:01:50 they are launching automatic testing, and IIRC they are on the way for docker container based testing Oct 01 10:07:19 well, they already had gitlab-ci for a long time, but now they have build config integrated within the repo Oct 01 10:07:27 before they just supported buildbot way Oct 01 10:29:13 i think it's much better to stick with cmake instead of trying to find yet another quirky rarely used build system that promises to do a few things better (but usually doesn't) ;) Oct 01 10:30:08 nbd: sure, I was talking about buildbot now :) CMake makes it's work quite remarkably Oct 01 11:01:08 txomon: well, the guidelines come from having users :) Oct 01 11:01:56 karlp: I suppose so haha, anyway, if you develop something, you may as well give guidelines :) Oct 01 11:06:12 I scons got discarded years and years ago, then just kept alive in quirky niches. Oct 01 11:06:51 * karlp shrugs. thing with google tools is that basically no-one else is google, so what they need is largely irrelevant for just about everyone else. Oct 01 11:07:14 karlp: The idea is actually quite good, the fact that there is no intermediate files, which is what I would like to see from cmake. The rest is just ok Oct 01 11:08:27 i remember scons from mongodb Oct 01 11:08:54 and that piece of ... software really honors its name Oct 01 11:09:13 haha Oct 01 11:15:39 if everyone's feeling chatty, does anyone have any opinions ideas or feedback on https://lists.openwrt.org/pipermail/openwrt-devel/2015-September/036237.html ? Oct 01 11:18:24 but if you'd rather talk about cmake, I like it, but I couldn't figure out a neat way of getting "git describe" output done everytime _make_ gets run, rather than when cmake runs the first time to generate the make/ninja files. Oct 01 11:33:39 build #102 of pxa is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/pxa/builds/102 Oct 01 13:32:40 if I want to use /etc/rc.buttons to be a good person and use procd buttons, where are the names defined? in /sys/kernel/debug/gpio I have a button "restore button" defined like so: https://paste.fedoraproject.org/273597/37063191/ how do I figure out what the file name needs to be? or what debugging can I turn on to see procd button events? Oct 01 13:34:50 I have an old hotplug.d 00-button file form atheros that works justfine on trunk, but it would be nice to move forward to the procd way to live in the future. Oct 01 14:18:01 blogic r47071 branches/chaos_calmer/package/utils/bzip2/Makefile * bzip2: add host build Oct 01 14:18:04 blogic r47072 branches/ (6 files in 6 dirs) * CC: ramips: Added WIZnet WizFi630A Platfrom based on Ralink RT5350 Oct 01 14:41:48 any thoughts on expanding libubox/usock.c to support broadcast? Oct 01 14:41:54 nbd: ^ Oct 01 14:43:06 I have a protocol that uses udp broadcasts to comunicate, and in v2 of that protocol, it changes later to unicast once discovery has been done Oct 01 14:44:17 or maybe making possible to add more flags to the socket? Or would all that just make rubish usock? Oct 01 14:51:41 txomon: depends on how much code it is and what the api changes look like Oct 01 14:51:54 feel free to propose a patch and i'll let you know if it's acceptable or not Oct 01 14:54:21 build #88 of octeon is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/octeon/builds/88 Oct 01 14:55:55 Has anyone tested an x86_64 build of trunk recently? When I do so (using glibc 2.21), procd segfaults very early in the boot process. Oct 01 14:58:52 I have tried with both GCC 4.8 and 5 and with binutils 2.24 and 2.25.1, the behavior is the same in each case. I am about to try a build with musl and see if that makes a difference. Oct 01 15:31:36 nbd: I was going to say I would, but after looking on your C coding style-expertise, I don't think I will be able to do it as good as I think it should be... :/ Oct 01 15:32:06 but I will be doing it, and when I get comfortable enough with libubox etc. will submit Oct 01 15:37:07 blogic r47073 trunk/target/linux/ramips/patches-3.18/0061-SPI-ralink-add-mt7621-SoC-spi-driver.patch * ralink: speed selection was broken in spi-mt7621 Oct 01 16:41:19 what pakcage have I lost/not configured if I get this on bootup with trunk? "/etc/preinit: line 1: ip: not found" Oct 01 16:41:49 ip? Oct 01 16:42:02 but I didn't know it was needed Oct 01 16:42:08 on CC, it's not included by default Oct 01 16:42:35 perhaps you have customized preinit ;) Oct 01 16:42:46 yeah, perhaps not :) Oct 01 16:42:51 in trunk it is included by default I thought Oct 01 16:42:58 busybox version of ip that is Oct 01 16:47:09 yep Oct 01 16:47:11 must be related to me adding busybox options. Oct 01 16:47:35 I thought if I just enabled custom busybox that it would have what it needed already, and I could then add stuff, Oct 01 16:47:48 well you can deselect stuff as well Oct 01 16:47:50 but this may have been from moving forward Oct 01 16:48:02 so if we update default settings you need to adjust your config Oct 01 16:48:04 i doubt I would have deliberately deselected it, but possible Oct 01 16:48:04 if you had 'old' config with custom busybox selected, new defaults would not be there when you move forward Oct 01 16:48:13 exactly Oct 01 16:48:14 I probably had an old custom and didn't ge the new ones moving forwards Oct 01 16:48:49 scripts/diffconfig doesn't help very much with this unfortunately :| Oct 01 16:49:10 It appears that my procd segfault problem is specific to glibc; it doesn't happen with musl. Oct 01 16:49:33 (But it worked fine with glibc in CC.) Oct 01 16:50:09 karlp: http://git.openwrt.org/?p=openwrt.git;a=commitdiff;h=15010a9e31dbfa9ad0531783321a7d88ed668cce;hp=54b61868fca0d520fa6aec7cf80b6e5180b0849a Oct 01 16:50:41 mm, looking forward to getting rid of ifconfig :) Oct 01 16:50:45 it teaches people bad habits Oct 01 16:50:49 (relying on it, instead of ip) Oct 01 16:51:17 yeah but we even have a lot of stuff still using it in trunk Oct 01 16:51:31 cyrusff: thanks, I didn't go far enough in the git log looking for it. so much action in the commit logs :) Oct 01 16:51:36 probably same with route too Oct 01 16:51:55 (at least in packages and their scripts, if not main OpenWrt) Oct 01 16:52:19 yeah there is a lot of target-specific switch or network setup that sill uses ifconfig Oct 01 16:52:39 and in packages there is some stuff as well Oct 01 16:53:57 while we're complaining of busybox, why e.g. opkg install procps-top fails? Oct 01 16:54:05 (busybox and procps both provide top to same path in CC) Oct 01 16:54:30 yep that should be fixed Oct 01 16:56:59 Any hints on how to debug a procd segfault that occurs very early in the boot process? Oct 01 16:57:30 I would run it in UML image, and just gdb the UML itself Oct 01 16:57:46 plan B (not so pretty) is to sprinkle debugs that you get somehow to e.g. serial console Oct 01 16:58:12 This is in an x86 VM, so I can see the boot messages without any trouble. Oct 01 16:59:29 Any idea how to fix iwinfo segfault in 15.05 Oct 01 16:59:35 The crazy thing is that it happens on glibc but not musl. Oct 01 16:59:36 ? Oct 01 17:00:09 Justanick: do you have a backtrace? if not, get one Oct 01 17:04:35 cyrusff: I will create one. Oct 01 17:05:28 thanks Oct 01 17:53:53 cyrusff: With gdb attached it didn't trigger a segmentation fault. I used this guide. Oct 01 18:15:11 blogic r47074 trunk/target/linux/ramips/patches-3.18/0053-mmc-MIPS-ralink-add-sdhci-for-mt7620a-SoC.patch * ralink: the mmc driver can now handle CD lines that are active low Oct 01 18:45:49 blogic r47075 trunk/package/system/rpcd/Makefile * rpcd: update to latest git HEAD Oct 01 19:13:38 blogic r47076 trunk/target/linux/ramips/dts/mt7628an.dtsi * ralink: add irq to mt7628 gpio node Oct 01 19:28:57 So my problem is actually considerably more extensive than I thought. Many/most binaries (including procd, less, cat, lscpi, and a number of others) crash with a message along the lines of "procd[1]: segfault at 1f2840f0028 ip 00007fc365ebc805 sp 00007ffdf73a2d10 error 4 in libc-2.21.so[7fc365e44000+199000]" Oct 01 19:29:21 This happens regardless of whether I compile with GCC 4.8 or 5.2. Oct 01 19:32:05 nbd: ping Oct 01 19:32:34 jow_laptop: pong Oct 01 19:32:47 I am about to recompile with the binary-stripping turned off so maybe I can use gdb on it. Oct 01 19:33:03 nbd: you removed a number of crypt ciphers in musl but that breaks MS-CHAP in PPTP/PPPoE Oct 01 19:33:10 nbd: iirc it requires at least DES support Oct 01 19:33:44 ok, will add it back Oct 01 19:33:57 but not sure if other ciphers are needed too Oct 01 19:37:20 i don't think so. pppd doesn't use crypt(), it uses a different legacy API that only supports des Oct 01 19:40:41 I actually cannot execute gdb. That segfaults too. I have no idea what to do about this. Oct 01 19:41:34 nbd: it uses crypt() in auth.c and session.c Oct 01 19:41:40 mamarley: try if a musl build segfaults as well Oct 01 19:41:52 nbd: Musl is fine, I already tried that. Oct 01 19:42:41 nbd: but from a simple code review I do not know what is getting passed as salt - I suppose nothing and the original CHAP protocol relies on DES Oct 01 19:42:57 nbd: so reenabling DES is likely enough Oct 01 19:43:03 mamarley: you could use gdb from the musl build on a rootfs chroot from the glibc build Oct 01 19:43:10 shouldn't be too big either Oct 01 19:48:19 nbd: OK, but I am not sure how to get such a chroot set up. The broken build has very little functionality, so I can't download it. Oct 01 19:49:36 copy the rootfs tarball from the broken build to the system running the working build Oct 01 19:49:40 unpack it there Oct 01 19:50:14 Oh, chroot from the working build into the broken one. That I can do. Oct 01 19:51:25 nbd r47077 trunk/toolchain/ (27 files in 2 dirs) * toolchain/uClibc: add support of uClibc-ng Oct 01 19:51:29 nbd r47078 trunk/toolchain/musl/patches/901-crypt_size_hack.patch * musl: re-enable des crypto support, fixes pppd MPPE issues Oct 01 19:52:19 Could I just chroot into the broken build from a regular desktop Linux system? Oct 01 19:53:36 yeah, well, you probably don't have to chroot directly Oct 01 19:53:45 you just make sure that gdb uses the right path Oct 01 19:53:58 for searching libraries Oct 01 19:57:23 nbd: It doesn Oct 01 19:57:28 't segfault in the chroot. Oct 01 21:01:00 * swalker loves the anonymous commenting on #11779 Oct 01 21:04:30 damnit, why did I go and look Oct 01 21:05:46 build #92 of mpc83xx is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/mpc83xx/builds/92 Oct 01 23:27:32 build #92 of ep93xx is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/ep93xx/builds/92 **** ENDING LOGGING AT Fri Oct 02 02:59:59 2015