2013-07-01 05:42:43 kaniini, ping 2013-07-01 05:46:37 morning 2013-07-01 05:48:42 fabled: hi 2013-07-01 05:48:55 kaniini, what's up with the arm port? 2013-07-01 05:49:17 i'm experimenting with crosstool now 2013-07-01 05:49:23 fabled: well, if we are using musl 2013-07-01 05:49:32 fabled: we can just build musl from aports on raspbian 2013-07-01 05:49:52 fabled: and then set up dynamic linker to use ld-musl-arm.so 2013-07-01 05:50:01 on main/gcc 2013-07-01 05:50:01 right 2013-07-01 05:50:05 that's where i am right now 2013-07-01 05:50:15 raspbian seems to use linaro's gcc 2013-07-01 05:50:21 what i'd like to do 2013-07-01 05:50:22 oh 2013-07-01 05:50:22 i found a company 2013-07-01 05:50:23 selling odroid-u2's as dedis 2013-07-01 05:50:28 for $20/month 2013-07-01 05:50:35 so i might grab a few of those as builders 2013-07-01 05:50:40 since they are on fast connection etc 2013-07-01 05:50:44 is have first crosstool-ng generated cross builder 2013-07-01 05:51:03 modify apkbuild's so that we can cross build core items 2013-07-01 05:51:21 produce minimal rootfs - qemu-system-arm to it, and rebuild aports 2013-07-01 05:51:35 yeah, we could do it that way, but i think odroid-u2 will build faster 2013-07-01 05:51:38 :) 2013-07-01 05:52:18 can we stuff in our own rootfs + kernel to odroid-u2? 2013-07-01 05:58:48 i also wonder if it's worth using linaro gcc, or upstream gcc? 2013-07-01 06:03:20 upstream gcc seems okay. 2013-07-01 06:08:24 apparently it's usable. linaro seems to make it just compile better code. not sure how much the difference is. 2013-07-01 06:42:16 prymeroot: freetype does not build 2013-07-01 06:42:19 checking for zlib.h... yes 2013-07-01 06:42:19 checking for BZ2_bzDecompress in -lbz2... no 2013-07-01 06:42:19 checking for libpng... configure: error: `libpng-config' not found; 2013-07-01 06:42:19 either set the LIBPNG_CFLAGS and LIBPNG_LDFLAGS environment variables, 2013-07-01 06:42:19 or pass `--without-png' to the `configure' script. 2013-07-01 06:42:20 make: *** [setup] Error 1 2013-07-01 06:42:22 config.mk:25: builds/unix/unix-def.mk: No such file or directory 2013-07-01 06:42:26 config.mk:26: builds/unix/unix-cc.mk: No such file or directory 2013-07-01 06:42:28 make: *** No rule to make target `builds/unix/unix-cc.mk'. Stop. 2013-07-01 06:42:30 >>> ERROR: freetype: all failed 2013-07-01 06:42:32 >>> freetype: Uninstalling dependencies... 2013-07-01 07:26:17 ncopa: hm, I built it at x86 edge chroot with the same APKBUILD 2013-07-01 07:26:35 i have a fix for it 2013-07-01 07:26:41 add libpng-dev to makedepends 2013-07-01 07:26:47 you probably had it installed already 2013-07-01 07:29:49 oh, so it does 2013-07-01 07:30:59 testing/rsyslog also fails 2013-07-01 07:31:22 you forgot to include the *.conf*, *.initd and .logrotate files in the commit 2013-07-01 07:31:38 and it needs libuuid pkg-config 2013-07-01 07:31:50 add util-linux-dev to make depends solves that... 2013-07-01 07:33:12 and then it chokes on json.h 2013-07-01 07:35:01 let's see… 2013-07-01 07:35:06 i think i know why 2013-07-01 07:35:18 make -j1? 2013-07-01 07:35:20 i believe this will solve it: http://sprunge.us/TKRA 2013-07-01 07:35:22 nope 2013-07-01 07:35:33 i think json.pc is broke 2013-07-01 07:35:49 and its only a wrapper, it says that you should use json-c.pc 2013-07-01 07:39:41 also, json-c built without any changes 2013-07-01 07:40:07 yeah 2013-07-01 07:40:10 i noticed 2013-07-01 07:40:14 i think thats what broke it 2013-07-01 07:40:29 i think json-c-0.11 broke things 2013-07-01 07:43:40 the dont add JSON_C_CFLAGS 2013-07-01 07:43:46 they should 2013-07-01 07:44:01 instead they assume that json/json.h is there 2013-07-01 07:44:20 they should have done: #include 2013-07-01 07:44:27 and then add JSON_C_FLAGS 2013-07-01 07:44:43 (which is set from pkg-config) 2013-07-01 07:47:28 weird because rsyslog works with json-c-0.11 but only at my chroot, magic 2013-07-01 07:51:54 weird indeed 2013-07-01 07:52:35 can you check that json-c-0.11 is really installed? 2013-07-01 07:52:41 and that you dont have an old json-c 2013-07-01 07:52:46 apk version json-c-dev 2013-07-01 07:53:30 ncopa: yep, 0.11 is installed 2013-07-01 07:54:06 can you see if you have /usr/include/json/json.h there? 2013-07-01 07:55:11 huh, nope 2013-07-01 07:55:20 and it still builds? 2013-07-01 07:56:34 ffu, I mistake the path. json.h is present in /usr/include/json-c 2013-07-01 07:56:46 exactly 2013-07-01 07:56:57 thats the problem i have when building 2013-07-01 07:57:21 rsyslog has various #include 2013-07-01 07:57:44 and there's json.h: http://sprunge.us/eQHF 2013-07-01 07:57:59 they should have done: #include and then let add pkg-config json-c --cflags to CFLAGS 2013-07-01 07:59:04 hmmph 2013-07-01 07:59:09 where is royger 2013-07-01 07:59:32 i want to talk to him about xen packaging status 2013-07-01 07:59:45 for xen 4.3, i would like to use the qemu we ship as the qemu-dm 2013-07-01 07:59:53 that way i can get vnc over websockets 2013-07-01 08:00:10 and virtio 2013-07-01 08:00:30 maybe leave him a memo 2013-07-01 08:00:42 but if it's not feasible to do that, then i want to patch our qemu-dm to support vnc over websockets 2013-07-01 08:00:52 or just e-mail him to join, I bet he read e-mails sometimes 2013-07-01 08:00:55 (basically the outcome i want is: vnc over websockets) 2013-07-01 08:01:11 we can get there however we get there 2013-07-01 08:04:11 i plan to integrate cloudware components into alpine 2.7. there's a lot of work remaining from cloudware side of things though. 2013-07-01 08:11:40 talking about the sun :) 2013-07-01 08:11:52 royger: kaniini was missing you :) 2013-07-01 08:11:57 hehehe 2013-07-01 08:12:18 kaniini, ncopa: morning :) 2013-07-01 08:13:41 i want to talk to him about xen packaging status 2013-07-01 08:13:42 for xen 4.3, i would like to use the qemu we ship as the qemu-dm 2013-07-01 08:14:26 :D 2013-07-01 08:16:22 royger: basically my goal is VNC to HVM guests over websockets 2013-07-01 08:16:39 royger: if Xen 4.3 already supports this, then we can continue to ship that 2013-07-01 08:17:33 royger: that way, we can have console running in noVNC.js or something and it works nicely 2013-07-01 08:19:13 royger: alternately, patching the Xen 4.3 qemu-dm to support VNC over websockets (with TLS) using the qemu upstream patches would also work 2013-07-01 08:19:15 :) 2013-07-01 08:19:47 anyway. that is all, let me know your thoughts, i'm going to go outside for a bit because it's actually not 300 billion degrees, i'll see them when i get back 2013-07-01 08:22:49 kaniini: I have no idea of the status of qemu and websockets, let me take a look 2013-07-01 08:24:52 ncopa: I've pushed commit with rsyslog config files. 2013-07-01 08:26:21 Oh, too late. 2013-07-01 08:26:54 kaniini: Xen 4.3 will ship with Qemu 1.3, which AFAIK still doesn't support websockets (http://lists.nongnu.org/archive/html/qemu-devel/2013-01/msg03712.html) 2013-07-01 08:27:59 kaniini: using a different Qemu is possible (1.4 which supports websockets), but then 1.4 Xen support has not really been tested as extensively as 1.3, so who knows if there might be hidden bugs 2013-07-01 08:29:15 kaniini: if we agree that 1.4 is worth it, and we agree that the risk of using 1.4 is OK, I don't see any problem with it 2013-07-01 08:31:20 ACTION hides 2013-07-01 08:32:19 ACTION fixes sine everytone is has ran away 2013-07-01 08:33:19 prymeroot: i think we need a proper chroot (or lxc) builder 2013-07-01 08:33:42 buildlab is a good start 2013-07-01 08:34:32 i think buildlab should mount --bind $HOME and clone the current user to the chroot env 2013-07-01 08:36:53 prymeroot: built now. thanks! 2013-07-01 08:39:02 ncopa: I just followed the wiki article about Alpine in chroot. I also thank you. 2013-07-01 09:39:36 royger: we could backport the websockets patch ourselves 2013-07-01 09:39:41 royger: i have isolated it 2013-07-01 09:50:00 kaniini: do they apply cleanly on 1.3? 2013-07-01 09:50:17 royger: i believe so, if not, i can rebase them. 2013-07-01 09:50:29 kaniini: if earlier in the release process you could have asked for a backport into Xen stable qemu tree 2013-07-01 09:50:42 royger: yeah, we didn't get to HVM in time. 2013-07-01 09:50:56 royger: did you see what i am doing? 2013-07-01 09:51:13 kaniini: no, I don't think so? do you mean the ARM work? 2013-07-01 09:51:32 royger: http://www.youtube.com/watch?v=yg42yXphzCM -- this is what my day job is doing with xen + alpine 2013-07-01 09:53:42 royger: so that can probably put into perspective why websockets-vnc is interesting to us ;) 2013-07-01 09:54:24 kaniini: nice :) 2013-07-01 09:54:48 kaniini: I don't have much experience with this kind of tools, but looks much more useful than EC2 2013-07-01 09:55:05 I think EC2 only allows you to see the serial output, but not interact with it 2013-07-01 09:55:29 royger: yeah, we wrote a custom daemon to reflect any xen event-channel into websockets. 2013-07-01 09:56:02 royger: realistically, this is only useful for console, but it could be taught to do others too, like virtual ISO mounting or whatever. 2013-07-01 09:56:13 I'm fine with either using something newer than 1.3 (provided that we are fine with the risk or maybe your company can run test to check that all functionality in 1.4 works as expected) 2013-07-01 09:56:23 yes, we will test it of course :) 2013-07-01 09:56:49 or backporting the patches (which is lower risk), but I have no idea of how much work that is 2013-07-01 09:57:08 backporting is something that one of us on my team can do in a day probably. 2013-07-01 09:57:23 we have a working patch for xen 4.2, but with xen 4.3 right around the corner, we're not going to bother with it 2013-07-01 09:57:24 then if you don't need anything else I would go with that 2013-07-01 09:58:14 kaniini: would you be interested in writing about this tool on blog.xen.org? 2013-07-01 09:58:31 well, is it OSS? 2013-07-01 10:00:16 royger: yes. 2013-07-01 10:00:24 royger: we are planning to integrate it into alpine 2.7 2013-07-01 10:01:08 at least, most of it. some things, we're going to keep as non-OSS modules. 2013-07-01 10:01:45 kaniini: you will have to join the publicity ML (http://www.xenproject.org/help/mailing-list.html) and ask for a slot in the blog whenever you feel like it's ready for a prime time :) 2013-07-01 10:02:20 kaniini: that would be great (re integration with 2.7) 2013-07-01 10:06:01 kaniini: BTW, did you see my message about cubie2? 2013-07-01 10:06:11 royger: yes. 2013-07-01 10:06:32 royger: fabled and i are working on a plan. he wishes to modify aports to make it more friendly to crosscompile. 2013-07-01 10:06:36 I've already got mine, looks interesting (and has a SATA port) hehehe 2013-07-01 10:07:31 seems we have some basic things in aports already for cross compile. just need to improve it, and make a script that builds the initial system image. 2013-07-01 10:07:32 so you want to crosscompile aports for arm from x86 instead of using dedicated buidlers? 2013-07-01 10:07:46 royger, cross compile initial image 2013-07-01 10:08:01 then build using dedicated builders, or using x86_64 + qemu-system-arm 2013-07-01 10:08:50 i'm currently patching crosstool-ng to support musl. looks like i got it right now. 2013-07-01 10:09:00 the biggest problem I see if that arm boards usually need a specific kernel with patches that are not merged into upstream 2013-07-01 10:09:08 s/if/is 2013-07-01 10:09:08 yes 2013-07-01 10:10:00 which is crap :( cubie2 patches are only ported to 3.3 or 3.4, I think arndale is in a better position (with monstly everything needed upstream) 2013-07-01 10:10:19 raspberry pi has github with 3.8 based tree 2013-07-01 10:10:31 rpi is weird case anyway 2013-07-01 10:10:41 and slow I guess 2013-07-01 10:10:56 the GPU seems to be the "main" cpu. it boots, loads configs, loads kernel+initramfs, and kick starts the ARM CPU 2013-07-01 10:11:00 fabled: re rpi, but patches are not still merged into upstream linux? 2013-07-01 10:11:06 royger, nope 2013-07-01 10:11:21 and the videocore messaging system likely is not going to be merged 2013-07-01 10:11:39 the other soc drivers should be going in at somepoint 2013-07-01 10:11:41 that's quite crappy, having different kernel sources for each board sucks 2013-07-01 10:12:00 yes 2013-07-01 10:12:13 so dunno how to handle that 2013-07-01 10:12:28 arm used to be a giant mess 2013-07-01 10:12:35 the latest kernels are somewhat better 2013-07-01 10:12:59 linux-image-rpi, linux-image-arndale, linux-image-cubie... and so on is the only way until everything is merged into upstream and we can use the same sources 2013-07-01 10:13:16 yeah. 2013-07-01 10:13:38 then it should just be a matter of having different config files for each board 2013-07-01 10:13:39 we might need to build dedicated kernels anyway - to have proper config 2013-07-01 10:13:56 but yes - would be nice if could have at least same sources 2013-07-01 10:15:42 and then each board also has a patched uboot, which is also crap... anyway if you need I can test with the cubie2, or even try to add the necessary kernel sources/config (and maybe uboot) 2013-07-01 10:16:44 what about beagleboard xm? 2013-07-01 10:17:34 barthalion: I have no idea about this board 2013-07-01 10:17:42 hm, nvm, it also has modified kernel 2013-07-01 10:18:05 I think arndale is probably the only one with mostly everything upstreamed 2013-07-01 10:18:27 but it's f* expesive 2013-07-01 12:49:14 fabled: we could use paypal for *expensive* investments 2013-07-01 13:40:41 libvirt-1.1.0 is out 2013-07-01 13:40:55 seems like it supports xl interface got xen? 2013-07-01 13:42:36 what defines if an app will be moved from testing to main ? 2013-07-01 13:43:08 alacerda: that it runs and has more or less stable interface 2013-07-01 13:43:28 interface = ACF module? 2013-07-01 13:43:44 with stable interface, i mean that the etc/init.d/* files does not change in such way that the config files needs manual editing when upgrade 2013-07-01 13:44:09 once it hits main we should always have an upgrade path for upgrades 2013-07-01 13:44:33 while things in testing might miss init.d script 2013-07-01 13:44:44 or might have a halfdone init.d script 2013-07-01 13:45:01 also make sure that files are installed in sane locations 2013-07-01 13:45:03 hum... so my openvpn-ad-check is missing init.d script =] 2013-07-01 13:45:05 not like in /usr/var 2013-07-01 13:45:19 thanks i'll care of it! 2013-07-01 13:45:31 if it runs, then i think we can just move it 2013-07-01 13:45:54 basically, i use testing/ to make sure that the version built by buildservers works 2013-07-01 13:46:23 so it does not depend on something that i missed but have locally 2013-07-01 13:47:17 openvpn-ad-check needs initd? 2013-07-01 13:48:12 in fact we have to restar openvpn not openvpn-ad-check... maybe init.d script wold check something before reload openvpn 2013-07-01 13:48:35 something like openvpn-ad-check config file params 2013-07-01 13:51:57 clandmeter: do you think is is useless? 2013-07-01 13:52:00 it is* 2013-07-01 13:52:56 I wouldnt modify openvpn initd for a script which is not part of openvpn itself. 2013-07-01 13:53:18 i tend to agree with clandmeter 2013-07-01 13:56:12 alacerda: 1. make sure it works as expected. 2. add a README so users know how to use it. 3. add information to wiki (not necesairly) 4. move to main. 2013-07-01 13:56:35 clandmeter: thanks ; -) 2013-07-01 13:59:44 i'll move it 2013-07-01 13:59:53 rnalrd: do you mind if i upgrade libvirt to 1.1.0? 2013-07-01 13:59:59 and enable libxl driver 2013-07-01 14:00:09 and split out vbox driver in separate subpackage 2013-07-01 14:00:10 go tnx :) 2013-07-01 14:04:45 alacerda: have you seend http://code.google.com/p/openvpn-auth-ldap/ ? 2013-07-01 14:04:56 it was previously built for alpine, and some users reported success 2013-07-01 14:05:51 jbilyk_: Thought hard to config. 2013-07-01 14:06:04 ok 2013-07-01 14:06:22 alacerda: i haven't tried it, i'm happy to use certs only for openvpn in the installs I've done in the past 2013-07-01 14:06:51 with openvpn-ad-check we use cert + user and pass + group permission 2013-07-01 14:07:31 i moved it to main 2013-07-01 14:07:38 thanks ncopa 2013-07-01 14:10:12 i did a stupid gtk wrapper for apk-tools last week 2013-07-01 14:10:15 http://imgur.com/bXjNtf2 2013-07-01 14:16:32 rebooting brb 2013-07-01 15:14:32 files from v2.5.4-165-g02b9902 uploaded 2013-07-01 15:17:01 files from v2.5.4-165-g02b9902 uploaded 2013-07-01 15:19:39 files from v2.4.11-54-gf87a971 uploaded 2013-07-01 16:58:13 royger: i rebased the patch for xen 4.2 and xen 4.3 2013-07-01 16:58:24 royger: it seems to work 2013-07-01 17:16:34 kaniini: if you want to push them to edge I don't have any objections 2013-07-01 17:17:02 kaniini: I have to run now, c u tomorrow 2013-07-01 17:57:19 i'm about to push a huge change to main/xen and royger ain't gonna like it ;) 2013-07-01 19:57:04 hmm 2013-07-02 01:09:06 http://turtle.dereferenced.org/~kaniini/xen-hvm-websockets.png 2013-07-02 01:09:10 well, that's half the battle. 2013-07-02 01:09:14 now to make it support TLS. 2013-07-02 05:10:19 gonna see if i can enable http backend on qemu-xen 2013-07-02 05:38:03 ^^^ lol 2013-07-02 05:38:08 you don't even want to know how that works 2013-07-02 05:38:10 but, if you do: 2013-07-02 05:38:31 device_model_args_hvm = ['-cdrom', 'http://blah.tld/foo.iso'] 2013-07-02 07:32:21 kaniini, any preference on arch name for apk-tools armel (to signify little-end), or just arm and not do the big-endian for now 2013-07-02 07:32:29 i think i'll use -march=armv6 2013-07-02 07:32:42 armel is probably good 2013-07-02 07:32:58 should be ok for rpi, beagleboard, etc 2013-07-02 07:33:05 rpi seems to be the oldest core 2013-07-02 07:33:09 rest are cortex a8 or later 2013-07-02 07:33:45 i have working cross compiler now 2013-07-02 07:33:51 and am able to do .apk's of some packages 2013-07-02 07:33:55 for arm 2013-07-02 07:33:56 yap 2013-07-02 07:34:05 there's where i was when i first attempted it 2013-07-02 07:34:06 need to just extend that to all the core packages for bootable environment 2013-07-02 07:34:23 we will want to support vexpress for qemu 2013-07-02 07:35:16 that's the same as versatile? 2013-07-02 07:35:39 yes. "versatile express" 2013-07-02 07:35:46 yeah, i had the same plan 2013-07-02 07:36:49 do know if we want thumb support as well? 2013-07-02 07:37:08 it can be faster code in some cases 2013-07-02 07:38:04 but mixing thumb+regular means few extra opcodes for each function; causing some overhead 2013-07-02 07:38:18 though, i think somewhere it was said that thumb support was mandatory 2013-07-02 07:38:43 yes, i believe so 2013-07-02 08:47:47 royger: http://turtle.dereferenced.org/~nenolod/hvm-console-windows.png 2013-07-02 08:48:04 royger: patches work, and as a bonus, i wrote a custom patch providing TLS support for the websockets 2013-07-02 08:49:12 kaniini: impressive :) 2013-07-02 08:49:34 royger: oh, i also enabled qemu-xen to use curl 2013-07-02 08:49:39 can you also hook into qemu serial console? 2013-07-02 08:49:51 royger: so, you can do... device_model_args_hvm = ['-cdrom', 'http://blah.iso'] 2013-07-02 08:50:42 kaniini: interesting, might be good to integrate this with xl 2013-07-02 08:50:44 royger: yes, it is possible. 2013-07-02 08:51:06 although for PV guests it won't be possible 2013-07-02 08:51:49 you sure? i though that is what xenqemu service is for 2013-07-02 08:52:35 I'm not so sure Qdisk will be happy to parse things like http://... I guess it will need some plumbing 2013-07-02 09:07:48 kaniini: have you tried building new llvm? 2013-07-02 09:49:27 fcolista: why did you bump pkgrel on openldap? 2013-07-02 09:49:42 me? 2013-07-02 09:49:44 When? 2013-07-02 09:49:50 commit 2ed7daafa9891adec2dad78a326c7b334a1d05e9 2013-07-02 09:49:50 Author: Francesco Colista 2013-07-02 09:49:50 Date: Wed Jun 5 06:34:46 2013 +0000 2013-07-02 09:49:50 main/openldap: bumped pkgrel 2013-07-02 09:49:59 Ah 2013-07-02 09:50:05 because of dependency 2013-07-02 09:50:07 libsasl rebuild? 2013-07-02 09:50:11 right 2013-07-02 09:50:11 commit message does not tell anything about why 2013-07-02 09:50:21 libsasl makes sense 2013-07-02 09:50:24 sorry, you're right 2013-07-02 09:50:32 it was a series of commit 2013-07-02 09:50:40 because of libsasl 2013-07-02 09:51:04 but you're right, i should have write in every commit rebuild against libsasl 2013-07-02 09:52:20 makes it easier yes 2013-07-02 10:04:16 kaniini: is your project available somewhere? I would like to take a look at it :) 2013-07-02 10:04:38 royger: http://bitbucket.org/tortoiselabs/ 2013-07-02 10:05:29 kaniini: thanks :) 2013-07-02 10:09:39 files from v2.3.6-251-g14e8058 uploaded 2013-07-02 10:12:39 files from v2.3.6-251-g14e8058 uploaded 2013-07-02 10:15:40 kaniini: FYI, there seems to be a missing file: http://tortois.es/static/cloudware-images/cloudware-graphing.png 2013-07-02 10:18:54 those screenshots are outdated anyway 2013-07-02 11:51:08 files from v2.4.11-61-g98cc69a uploaded 2013-07-02 12:00:15 files from v2.4.11-61-g98cc69a uploaded 2013-07-03 07:37:01 algitbot: build master 2013-07-03 12:07:32 ok. i have now cross-compile toolchain. and cross-compile abuilds for linux-vanilla, musl, gcc, make. and managed to qemu-system-arm the minimal image. 2013-07-03 12:31:38 fabled: sounds like you've almost got a buildbot for arm :D 2013-07-03 12:40:38 well - i still need to cross-compile gcc for target. 2013-07-03 12:40:42 that's going to be messy 2013-07-03 12:40:58 but then the bootstrap chain should be complete 2013-07-03 13:01:09 hrmpf 2013-07-03 13:24:59 fabled: you want to crosscompile on builder for arm? 2013-07-03 13:25:39 clandmeter, not really. i need to crosscompile the initial rootfs. after that i want to run qemu-system-arm on the builder to do native builds. 2013-07-03 13:26:33 will that be faster than regular arm hardware? 2013-07-03 13:26:44 depends on your arm hardware 2013-07-03 13:26:56 it'll faster than on the "cheap" arm things 2013-07-03 13:28:24 will you do an java arm build? 2013-07-03 13:28:49 dunno yet. 2013-07-03 13:28:54 i'm still working on the bootstrap image 2013-07-03 20:13:53 https://github.com/prymeroot/aports upgraded mercurial and dbmail, so pull if you want. And yes, in my chroot everything is fine. 2013-07-04 06:13:32 clandmeter: our plan is to use qemu to bootstrap something since it's faster than say raspberry pi, and then use your odroid-u2 as the actual buildbot once you have it 2013-07-04 06:32:12 prymeroot: your branch was not rebased and the merge become a bit ugly 2013-07-04 06:32:19 i just cherry-picked the 2 commits 2013-07-04 06:32:27 you should probably rebase it 2013-07-04 06:32:40 rebase your aports tree i mean 2013-07-04 06:32:46 prymeroot: I told you should do pull --rebase more often 2013-07-04 06:33:22 (it is ok to rebase and push force to github as long as you dont have followers on github) 2013-07-04 06:43:58 force is *evil* 2013-07-04 06:44:28 I got 99 problems but a merge conflict ain't one. 2013-07-04 06:45:22 but right, even if used on personal repository, it teaches rather bad behaviour 2013-07-04 06:48:19 barthalion: Hm, I did it but something went wrong. Yep, PEBKAC. 2013-07-04 06:55:44 clandmeter: yes, but its the only way to undo a messed up remote repo 2013-07-04 06:56:15 think of git push --force as removing the remote repo, and creating a new fresh one 2013-07-04 07:07:51 kaniini: http://www.cnx-software.com/2013/06/30/99-parallella-supercomputer-is-now-open-source-hardware 2013-07-04 07:08:52 clandmeter: yes, alpine on parallela could be interesting 2013-07-04 07:09:10 I have a paralella coming in the mail 2013-07-04 07:09:17 Would be cool to have alpine on it 2013-07-04 07:23:04 yeah 2013-07-04 07:23:13 i just got native arm gcc cross-compiled for arm 2013-07-04 07:23:32 working on getting other base tools done, and finally builder up 2013-07-04 07:23:53 planning to test qemu-user-arm with ncopa instead of the system... i think it should work in vserver chroot 2013-07-04 07:25:25 i woner how fine grained i should do qemu sub packages 2013-07-04 07:25:36 will introduce qemu user stuff 2013-07-04 07:27:05 should i have qemu-i386 and qemu-system-i386 in different subpackages? 2013-07-04 07:27:26 dunno. i'm ok either way. 2013-07-04 07:28:38 we'd end up with like 50 subpackages 2013-07-04 07:28:51 yeah 2013-07-04 07:28:53 i think we want do that 2013-07-04 07:29:29 gives the enduser possibility to save more space 2013-07-04 08:11:08 qemu users: heads up 2013-07-04 08:11:29 the qemu-i386 previously had the qemu-system-i386 2013-07-04 08:11:49 now it has the user emuator, qemu-i386 and not the system 2013-07-04 08:12:00 the system emulator is now in qemu-system-i386 2013-07-04 08:12:09 same for all archs 2013-07-04 12:34:30 brilliant 2013-07-04 12:34:40 qemu-user has a bug that it fails to setup brk properly with PIE executables 2013-07-04 12:38:11 fabled: a show stopper? 2013-07-04 12:38:28 i think i found the bug 2013-07-04 12:38:44 needs to get fixed 2013-07-04 12:38:48 can't proceed before 2013-07-04 12:39:38 busybox.static runs in qemu-user; but busybox pie version runs only partially. whenever it tries to malloc() things break. meaning most things do not work. 2013-07-04 12:39:46 i'm 90% sure i found the issue in qemu 2013-07-04 12:40:08 the main loader assumes that program executable is not ET_DYN 2013-07-04 12:40:13 but pie executables are 2013-07-04 12:40:19 fortunately the fix looks simple 2013-07-04 22:16:41 n8@all 2013-07-05 15:57:42 ok. i basically now have usable cross-compiled arm .apks for doing builder. qemu-user also works. need to coordinate with ncopa to setup the builder next week. 2013-07-05 16:01:01 fabled: good job! 2013-07-05 16:01:35 are you going to package cross-compiler? 2013-07-05 16:01:39 not sure 2013-07-05 16:01:50 it's done with crosstool-ng 2013-07-05 16:01:57 ah, right 2013-07-05 16:02:17 well, you can post .config on wiki anyway 2013-07-05 16:02:39 i scratched brief notes + linkes to my configs at http://wiki.alpinelinux.org/wiki/User:Fabled 2013-07-05 16:02:56 cool, thank you 2013-07-05 16:03:06 the ugly crosstool patches are at http://sourceware.org/ml/crossgcc/2013-07/ 2013-07-05 16:06:36 oh, and, aports is not pushed out yet 2013-07-05 16:06:58 i have changes to multiple APKBUILDs for the core packages to make them cross build with build time sysroot 2013-07-05 16:07:07 they are all relatively clean small changes 2013-07-05 16:07:18 but want to discuss them first with ncopa before pushing out 2013-07-05 16:07:23 hope to get that done on Monday 2013-07-05 16:07:52 anyway... after this... bootstrapping new architectures or switching to musl should be a lot simpler. 2013-07-05 16:08:24 ok. i'm off for the weekend. 2013-07-05 16:39:51 I should backport some commits to earlier releases… 2013-07-05 16:40:00 probably php would be a good start 2013-07-05 16:40:30 also upgrading 5.3 branch shouldn't be harmful 2013-07-05 17:01:18 algitbot: retry 2013-07-05 17:01:21 or something 2013-07-05 17:01:48 build64-2-5: hey you 2013-07-05 17:01:51 build64-2-5: retry 2013-07-05 17:08:13 files from v2.5.4-166-g4831d52 uploaded 2013-07-05 17:08:45 files from v2.5.4-166-g4831d52 uploaded 2013-07-07 05:11:48 something fishy happened 2013-07-07 11:13:23