2014-04-01 05:43:55 oh, arm builders 2014-04-01 05:44:00 nice :) 2014-04-01 06:06:44 :) 2014-04-01 06:06:49 nice indeed 2014-04-01 06:06:51 hopefully it works now without looping 2014-04-01 06:06:59 i think ncopa's arch fixes solved the issue 2014-04-01 06:07:19 i wonder how it will handle a git tag for iso generation 2014-04-01 06:07:31 fabled: will arm be able to build an iso? 2014-04-01 06:07:36 with alpine-iso 2014-04-01 06:07:48 ncopa, no, i think isolinux and some other stuff is not built 2014-04-01 06:08:10 i suppose it does not make much sense to build an *iso* with arm... 2014-04-01 06:08:13 we should be able to somehow tell what release binaries to make 2014-04-01 06:08:16 yeah 2014-04-01 06:08:19 iso is useless with arm 2014-04-01 06:08:44 we need the rpi tar.gz + generic tar.gz + n variants of u-boot bootloader 2014-04-01 06:09:13 even for x86 iso serves just as a container, like tar.gz 2014-04-01 06:09:25 yes, mostly that nowadays 2014-04-01 06:10:13 i wonder if we should look at isohybrid or something 2014-04-01 06:10:22 problem is fat 2014-04-01 06:10:34 or go with .tar.gz distribution for x86/x86_64 too? 2014-04-01 06:10:51 'extract to memory stick' 2014-04-01 06:10:58 and run syslinux 2014-04-01 06:11:01 tar.gz for x86 can be useful as well 2014-04-01 06:11:12 we use .iso as if it was tar.gz 2014-04-01 06:11:33 so only difference is that you can boot .iso but not tar.gz as is 2014-04-01 06:11:52 we could say 'use unetbootin' 2014-04-01 06:11:58 or isolinux 2014-04-01 06:12:11 calling it tar.gz will make it more visible what it is 2014-04-01 06:12:13 i think with arm we need to install u-boot manually too 2014-04-01 06:12:28 the u-boot needs to be specifically compiled for the board 2014-04-01 06:12:34 since it contains early init 2014-04-01 06:12:53 arm is a bit tricky hm 2014-04-01 06:12:58 so i'm wondering if the arm .tar.gz would need to contain: 2014-04-01 06:13:03 kernel + initrd + modloop 2014-04-01 06:13:10 dtbs for all boards 2014-04-01 06:13:15 u-boot for all boards 2014-04-01 06:13:31 setup-bootable would copy /boot and /apks as usual 2014-04-01 06:13:40 and have switch to select u-boot variant 2014-04-01 06:13:47 dtbs are named in u-boot 2014-04-01 06:13:58 so depending on u-boot chosen, the correct dtb would get used 2014-04-01 06:14:23 in fact: u-boot loads: kernel + initrd + dtb 2014-04-01 06:14:37 jumps to kernel and says: use initramfs at memoy X, and dtb at memory Y 2014-04-01 06:15:00 so we could get quite nice arm setup 2014-04-01 06:15:12 rpi being big exception of course 2014-04-01 06:22:27 i wouldnt mind drop support for rpi 2014-04-01 06:22:34 rpi is getting old new nowdays... 2014-04-01 09:36:57 ncopa: drop rpi support? 2014-04-01 09:37:20 as in completely or something i missed? 2014-04-01 09:37:51 i wouldnt mind, but i suppose my opinion doesnt matter there. i'm not doing the job ;) 2014-04-01 09:39:24 ist still the most used platform 2014-04-01 09:39:31 wouldnt make sence to remove it. 2014-04-01 09:40:06 ok 2014-04-01 09:40:29 i dont have strong opinion there 2014-04-01 09:42:08 and i guess its the only *full* open platorm? 2014-04-01 09:45:29 I don't think that rpi is fully open 2014-04-01 09:55:55 barthalion: http://www.raspberrypi.org/archives/6299 2014-04-01 09:56:40 it doesn't mean it's open… 2014-04-01 09:58:06 barthalion: which part isnt open? 2014-04-01 09:58:26 the boot firmware was the only thing still closed 2014-04-01 10:38:48 duh 2014-04-01 10:39:01 ncopa, is your git-hook to check files/checksums ready yet? ;) 2014-04-01 11:01:18 no :-( 2014-04-01 11:01:44 i think its not easy really 2014-04-01 11:01:54 i could have it revert stuff that break thins 2014-04-01 11:01:56 but basically 2014-04-01 11:02:10 when it can be tested, then the push has already happened 2014-04-01 11:02:15 the damage is already done 2014-04-01 11:09:37 ncopa, how about making it as local commit hook? 2014-04-01 11:10:32 local hook is simple 2014-04-01 11:10:38 but you cannot enforce it... 2014-04-01 11:11:01 ncopa, you can, just remove push access until people install it 2014-04-01 11:11:26 how? 2014-04-01 11:11:34 oh 2014-04-01 11:11:39 you mean manually 2014-04-01 11:12:08 it works til someone want set up more than one work box 2014-04-01 11:19:19 why would you want to enforce it? 2014-04-01 11:19:50 cant it be conciderd a feature? 2014-04-01 11:54:21 the point is to add a santity check for the people who doesnt do it locally 2014-04-01 11:54:31 and reject their push 2014-04-01 11:56:50 fcolista, I was able to do a basic test for xapian-core + xapian+omega, more still to do 2014-04-01 11:57:14 could you pls check xapian-bindings pkgs if it build ok, with required files 2014-04-01 11:58:23 Hi vkrishn 2014-04-01 11:58:35 xapian-bindings build ok 2014-04-01 11:58:37 I think mode for php5 -> xapian.so is missing 2014-04-01 11:59:04 module* 2014-04-01 11:59:10 Building goes fine. I'm checking this. 2014-04-01 11:59:45 I tried re-building, and found some error but build does goes fine 2014-04-01 11:59:55 Ok 2014-04-01 11:59:56 error in build msgs 2014-04-01 12:02:30 ok saw the errors 2014-04-01 12:02:58 well, they are actually warnings 2014-04-01 12:03:31 some issues are here: http://xapian.org/docs/bindings/php/ 2014-04-01 12:03:53 aaaah 2014-04-01 12:03:54 ok 2014-04-01 12:04:01 yes 2014-04-01 12:04:06 php builds actually fails. 2014-04-01 12:04:10 Let me check 2014-04-01 12:04:31 I suspect xapian 2014-04-01 12:04:55 did not update the php binding files with new release 2014-04-01 12:16:29 umh 2014-04-01 12:49:45 vkrishn, still here? 2014-04-01 12:50:06 I found the error 2014-04-01 12:50:23 now xapian.so compiles 2014-04-01 12:50:46 Just wondering about movin lua from 5.1 to 5.2 2014-04-01 12:51:14 http://xapian.org/docs/bindings/lua/ 2014-04-01 12:51:22 "These bindings require Lua version 5.1 or later, and have been tested with Lua 5.1 and 5.2. " 2014-04-01 12:52:20 i can create bingings for both: xapian-bindings-lua5.1 and 5.2 2014-04-01 12:52:37 um 2014-04-01 12:52:39 umh 2014-04-01 12:53:39 what is current state for upcoming AL v3.0, will it have lua 5.1 ? 2014-04-01 12:57:43 I was wondering if there is a way of knowing php module directory via phpize, and not hardcoding in APKBUILD, 2014-04-01 12:57:44 eg. mv "$pkgdir"/usr/lib/php/20090626/* "$subpkgdir"/usr/lib/php/20090626/ 2014-04-01 12:57:56 this is the error 2014-04-01 12:58:08 it should go to /usr/lib/php/modules 2014-04-01 12:58:46 libtoolize makes xapian.la to /usr/lib/php/modules/xapian.so 2014-04-01 12:59:41 PHP_EXTENSION_DIR 2014-04-01 12:59:47 hmm 2014-04-01 13:00:08 env PHP_EXTENSION_DIR = $php_modules 2014-04-01 13:00:30 php5.5 where puts modules? 2014-04-01 13:00:55 In /usr/lib/php/modules 2014-04-01 13:02:03 ok, :) would test php today, I don't know if I would test other bindings but could try 2014-04-01 13:02:32 PHP_EXTENSION_DIR override the default modules dir 2014-04-01 13:02:48 that could changes when php version changes 2014-04-01 13:02:53 btw 2014-04-01 13:03:00 i'm going to bump pkgrel 2014-04-01 13:03:15 i'll bump also the other xapian-* packages 2014-04-01 13:03:35 also noticed why does xapian-core building pull "cfdisk.apk" 2014-04-01 13:04:14 uh? 2014-04-01 13:05:17 what do u mean? 2014-04-01 13:07:27 hi 2014-04-01 13:07:51 just a short question: why not crosscompiling for arm (rpi)? 2014-04-01 13:08:08 problems? 2014-04-01 13:08:54 I think even with bindings, when you abuild -r in clean alpine-sdk environment, it pull cfdisk 2014-04-01 13:12:00 Quit strange 2014-04-01 13:12:02 *quite 2014-04-01 13:15:50 ? 2014-04-01 13:25:07 fcolista: do you mean my question or something else? 2014-04-01 13:27:25 StarWarsFan, i was replying to vkrishn, but i can't read the backlog :) 2014-04-01 13:27:29 *you 2014-04-01 13:28:46 now i'm completely confused... 2014-04-01 13:28:51 :) 2014-04-01 13:29:01 :) 2014-04-01 13:29:21 StarWarsFan: if you read backlog, it would make sence 2014-04-01 13:29:45 You entered in the middle of a conversation that i was doing with vkrishn, what you read is my reply to vkrishn...but you can't read the backlog... 2014-04-01 13:29:50 make sense now? :) 2014-04-01 13:30:09 aaahhhhh X-) 2014-04-01 13:30:14 sure, absolutely 2014-04-01 13:30:30 ACTION should'nt do too much things at the same time... ;-) 2014-04-01 13:30:34 http://www.irclogger.com/.alpine-devel/2014-04-01 2014-04-01 13:30:43 StarWarsFan: about your Q, fabled takes care of rpi. 2014-04-01 13:31:41 s/rpi/ARM 2014-04-01 13:31:56 done vkrishn. Let me know. 2014-04-01 13:32:01 Lua is still to 5.1 2014-04-01 13:32:16 ok 2014-04-01 13:39:43 StarWarsFan, crosscompiling has certain issues, not all packages are easily fixable for that 2014-04-01 13:39:51 so i'm native building on ARM Quadcore wandbox 2014-04-01 13:40:01 it's a lot faster than rpi 2014-04-01 13:40:17 but not nearly fast as the 12-core x86_64 buildboxes we use for x86/x86_64 2014-04-01 21:14:12 n8@all 2014-04-02 09:57:41 msg.a.o like -- build/build-edge-musl-x86_64 128/242 875/1115 gitstats 2012.08.30 -- 2014-04-02 09:57:54 does not make clear if it belongs to main or testing 2014-04-02 13:50:14 wheee!! virt-manager built with musl 2014-04-02 14:19:52 i think we might be able to switch edge to musl tomorrow 2014-04-03 06:23:03 ncopa: upstream patches for readline are out, but please wait with the upgrade, it has some missing symbols on i686 2014-04-03 06:23:33 well, actually one, but enough to break 2014-04-03 06:23:41 gawk for example 2014-04-03 06:31:54 heh 2014-04-03 06:32:03 morning barthalion 2014-04-03 06:32:19 well... I think i'd like to replace readline with libedit wherever possible 2014-04-03 06:38:36 kaniini: are you ok with this change: http://sprunge.us/hVNL 2014-04-03 06:38:56 note that the version goes from 3.1 -> 20140213.3.1 2014-04-03 06:39:28 it is closer to upstream http://thrysoee.dk/editline/ 2014-04-03 06:40:31 hm 2014-04-03 06:40:37 utf8 doesnt work really 2014-04-03 06:40:46 chartype.h:52:3: error: #error wchar_t must store ISO 10646 characters 2014-04-03 06:40:46 #error wchar_t must store ISO 10646 characters 2014-04-03 06:40:46 ^ 2014-04-03 06:45:08 LOL!!! https://lkml.org/lkml/2014/4/2/415 2014-04-03 06:45:20 "What happens is that the user space tool parses the 2014-04-03 06:45:20 kernel command line, and if it sees "debug" it will spit out so much 2014-04-03 06:45:20 information that the system fails to boot. This basically renders the 2014-04-03 06:45:20 "debug" option for the kernel useless." 2014-04-03 06:54:42 i dont know what to say: https://bugs.freedesktop.org/show_bug.cgi?id=76935 2014-04-03 06:54:59 i think it pretty much sums up the attitude of systemd devs 2014-04-03 06:56:52 i took arm builder offline; i'm working fixing the kernel packaging there 2014-04-03 06:56:59 ok 2014-04-03 06:57:13 it's slow box, so it can't build kernel + aports same time 2014-04-03 07:24:32 wtf @ systemd bug #76935 2014-04-03 07:25:27 I'm wondering why someone with push access to systemd haven't fixed that before it escalated this way 2014-04-03 07:26:07 ncopa: not really systemd devs', but Sievers's attitude 2014-04-03 07:26:28 yup 2014-04-03 07:26:49 but I sense a similar attitude with lennart 2014-04-03 07:27:33 Lennart is usually more thoughtful, at least from my experience 2014-04-03 07:28:16 could be he is influenced by kay, i dunno 2014-04-03 07:29:06 but i agree with linus, be careful to accept code from there - unless you want end up fork it and maintain it yourself 2014-04-03 07:35:50 this stuff is why alpine does not supply pulseaudio or systemd, and why i plan during this summer to replace udev with an api/abi-compatible replacement free of kay sievers' code 2014-04-03 07:36:14 it is also why we replace uclibc with musl 2014-04-03 07:36:29 too many people are willing to let obvious regressions slide 2014-04-03 07:37:32 I guess it'd be better to help eudev devs instead of jumping on Alpine-only project 2014-04-03 07:37:47 the good side is that OpenBSD devs are working on logind replacement 2014-04-03 07:45:54 i wonder if we could do something like: runit + + https://github.com/uggedal/going or similar 2014-04-03 07:46:37 barthalion: i disagree. eudev is much like openrc 2014-04-03 07:47:21 we're playing with fire there, and really udev is an awful quality codebase 2014-04-03 07:47:35 i havent digged much into uedev, but it doesn't give the the warm fuzzy feeling 2014-04-03 07:47:42 so i'm sceptic to uedev 2014-04-03 07:47:49 i think eudev will likely go away at the same time openrc does 2014-04-03 07:48:01 gentoo will eventually cave into systemd, they are already pushing on it 2014-04-03 07:48:22 i mean, we now live in a world where debian uses systemd... don't expect gentoo to follow suit 2014-04-03 07:48:25 erm, to not* 2014-04-03 07:52:15 you can't trust freedesktop guys 2014-04-03 07:52:25 they play fast and loose and don't care about regressions 2014-04-03 07:52:29 remember pkg-config 0.26 here 2014-04-03 07:53:04 it was obvious to me *then* that these guys couldn't be trusted to play right 2014-04-03 07:53:14 have you seen https://github.com/chneukirchen/ignite ? 2014-04-03 07:53:27 some Arch users are using it with success 2014-04-03 07:57:15 well i think the problem there is 2014-04-03 07:57:19 it's very arch centric 2014-04-03 07:58:24 yup i remember pkg-config 2014-04-03 07:58:42 and yes, i think yre right, freedesktop guys cannot be trusted to play right 2014-04-03 07:59:37 i mean that's the thing really 2014-04-03 07:59:50 freedesktop solution was: yeah figure out the solution yourself 2014-04-03 07:59:58 i figured out a solution to pkg-config 0.26 alright 2014-04-03 08:00:25 eudev is no solution 2014-04-03 08:00:31 pkgconf has been a great success 2014-04-03 08:00:36 because they're going to have to follow udev upstream anyway 2014-04-03 08:01:01 but unfortunally, we cannot rewrite every software out there (were not ubuntu :) 2014-04-03 08:01:05 and it will die anyway when (WHEN) gentoo goes systemd 2014-04-03 08:01:34 ignite concept looks a bit interesting 2014-04-03 08:01:46 ncopa: nope, we cannot, but i think i can get together a cabal to make kerneld or whatever i call it a reality 2014-04-03 08:01:48 ;p 2014-04-03 08:02:21 we talked about kuevend 2014-04-03 08:02:26 kueventd 2014-04-03 08:02:38 i'd like to have more on the board 2014-04-03 08:02:51 dalias has some good ideas too 2014-04-03 08:03:03 see that's my position 2014-04-03 08:03:05 screw those guys 2014-04-03 08:03:17 make a superior alternative and let the free market sort it out 2014-04-03 08:03:36 yes 2014-04-03 08:03:50 problem is that we are 2 years behind systemd 2014-04-03 08:04:02 that is a problem, but their attitude is our advantage 2014-04-03 08:04:10 but otoh, we can do thing "right" fromt he start 2014-04-03 08:04:16 and lears from the systemd mistakes 2014-04-03 08:05:06 this is the thing i like about musl 2014-04-03 08:05:16 dalias will never let a regression slide 2014-04-03 08:05:36 people can be confident in knowing that he will not tolerate a regression 2014-04-03 08:05:41 yes 2014-04-03 08:05:58 that is not a feeling i get when i look in the direction of uclibc or fd.o 2014-04-03 08:06:12 +1 2014-04-03 08:07:49 i have some ideas for kueventd 2014-04-03 08:07:58 set up a netlink socket listener 2014-04-03 08:08:08 send buffer to Lua 2014-04-03 08:08:20 the rest is done from lua 2014-04-03 08:10:27 yep 2014-04-03 08:11:02 and this is the thing really, alpine has a lot of legitimacy 2014-04-03 08:11:18 alpine adopting musl is a bfd for musl 2014-04-03 08:11:32 because it's a real distribution using it, and not a toy distribution 2014-04-03 08:11:51 perhaps not as huge a deal as say, debian switching 2014-04-03 08:11:54 but it's a pretty big deal 2014-04-03 08:25:16 we need fix/refactor alpine-iso 2014-04-03 08:25:19 to support arm 2014-04-03 08:25:32 + there are some things i'd like fix while at it 2014-04-03 08:25:39 maybe have helper scripts for each stage 2014-04-03 08:26:03 and i'd like to reuse the update-extlinux for generating the syslinux.cfg 2014-04-03 08:26:56 would also be nice to have an update-boot script, that can fetch new kernel and generate modloop in lets say /media/usb/boot/ 2014-04-03 08:27:30 i'm also thinking that it might make sense to have the bootmedia generation scripts/makefile in aports git repo 2014-04-03 08:27:42 as we tag releases in aports 2014-04-04 06:05:04 morning 2014-04-04 06:05:20 fabled: bug with apk upgrade -U -a 2014-04-04 06:05:42 $ apk version | sprunge 2014-04-04 06:05:42 http://sprunge.us/eAQe 2014-04-04 06:06:52 i think what happens is: 2014-04-04 06:06:53 nss-3.15.5-r0 provides: 2014-04-04 06:06:53 so:libfreebl3.so=15 2014-04-04 06:06:53 so:libnss3.so=15 2014-04-04 06:06:53 so:libnssckbi.so=15 2014-04-04 06:06:53 so:libnssdbm3.so=15 2014-04-04 06:06:55 so:libnssutil3.so=15 2014-04-04 06:06:57 so:libsmime3.so=15 2014-04-04 06:06:59 so:libsoftokn3.so=15 2014-04-04 06:07:01 so:libssl3.so=15 2014-04-04 06:07:10 nss-3.15.3.1-r0 provides: 2014-04-04 06:07:10 so:libfreebl3.so=15.3 2014-04-04 06:07:10 so:libnss3.so=15.3 2014-04-04 06:07:11 so:libnssckbi.so=15.3 2014-04-04 06:07:13 so:libnssdbm3.so=15.3 2014-04-04 06:07:15 so:libnssutil3.so=15.3 2014-04-04 06:07:17 so:libsmime3.so=15.3 2014-04-04 06:07:19 so:libsoftokn3.so=15.3 2014-04-04 06:07:21 so:libssl3.so=15.3 2014-04-04 06:07:23 you see the version difference? 2014-04-04 06:07:59 it seems that apk prefers nss-3.15.3.1 over 3.15.5 because the so version is higher 2014-04-04 06:08:14 su apk upgrade will not pick 3.15.5 2014-04-04 06:08:18 that is kinda okish 2014-04-04 06:08:48 (how would it pick version if multiple different packages provides same so: ?) 2014-04-04 06:10:17 but i think it currently prefers the higher so version, even if it is no available. 2014-04-04 06:10:25 it should pick whats available with -a 2014-04-04 06:20:31 ncopa, it depends on how the dependency is pulled in 2014-04-04 06:20:46 but yes, if the package is pulled in by the so:foo.so dependency 2014-04-04 06:20:49 then yes 2014-04-04 06:21:07 it would use the provided version as primary version preference 2014-04-04 06:21:23 imho, that is packaging bug 2014-04-04 06:22:01 should depend on nss>3.15.5 then i suppose 2014-04-04 06:22:04 there is code that if the provides version is same 2014-04-04 06:22:17 then it falls back to check of both packages are provided by same-named package 2014-04-04 06:22:28 and then it compares the 'master' version 2014-04-04 06:22:49 but it's fallback code if the provided names have same version number 2014-04-04 06:25:12 but if user does --available 2014-04-04 06:25:39 then it should prefer the repo version over the already installed, even if so version is lower? 2014-04-04 06:26:09 otherwise, when switching to musl, it will be happy with the current installed uclibc version... 2014-04-04 06:26:59 yes 2014-04-04 06:27:10 but in your case both must've been available 2014-04-04 06:27:21 e.g. from boot repository 2014-04-04 06:28:04 $ apk search --exact nss 2014-04-04 06:28:04 nss-3.15.5-r0 2014-04-04 06:28:07 nope 2014-04-04 06:28:11 i have remove the local repo 2014-04-04 06:28:25 there must be some conflict then 2014-04-04 06:28:36 hmm 2014-04-04 06:28:50 or it could be bug too 2014-04-04 06:28:53 + !!(repos & ss->default_repos); 2014-04-04 06:28:57 whats the !! ? 2014-04-04 06:29:02 why double ! 2014-04-04 06:29:17 not not (repos & ss->default_repos) ? 2014-04-04 06:29:19 it maps any-nonzero number to 1, and 0->0 2014-04-04 06:29:33 aha 2014-04-04 06:29:56 i added debug print info 2014-04-04 06:30:07 apk thinks nss-3.15.3.1 is available 2014-04-04 06:30:13 ah 2014-04-04 06:30:15 maybe its in cache 2014-04-04 06:30:37 mmm 2014-04-04 06:30:38 yes 2014-04-04 06:30:42 installed + cached = available 2014-04-04 06:31:20 which is actually might not be good idea 2014-04-04 06:31:36 well, it's debatable 2014-04-04 06:31:40 yes 2014-04-04 06:31:47 it should be available during boot 2014-04-04 06:31:53 but perhaps not during system upgrade 2014-04-04 06:31:54 because what if you apk update 2014-04-04 06:32:08 maybe --available should disable that? 2014-04-04 06:32:39 apk update on tmpfs install and then reboot 2014-04-04 06:32:48 without doing apk upgrade or apk cache sync 2014-04-04 06:33:04 i think current behaviour fixes that situation 2014-04-04 06:42:31 fabled: should i file a bug about it? 2014-04-04 06:49:23 db->available_repos 2014-04-04 06:49:31 is set when db is opened 2014-04-04 06:54:10 if you think something needs changing, then yes, please file a bug 2014-04-04 07:02:16 http://bugs.alpinelinux.org/issues/2831 2014-04-04 07:03:11 i thin it needs to mask out cached repo from db->available_repos when APK_SOLVERF_AVAILABLE is set 2014-04-04 07:04:26 i dont know if we want to do that when we open the db or when discover_name 2014-04-04 07:05:31 i'm thinking we want to do that only in the package preference calculation 2014-04-04 07:06:02 otherwise during boot, with --no-network, you might not get things right 2014-04-04 07:06:26 thats what i'm thinking to... 2014-04-04 07:06:37 i suppose we could pass the solver flag on db open 2014-04-04 07:06:54 apk_solverd_available is only set on upgrade i think 2014-04-04 07:08:02 i'll think about it 2014-04-04 07:08:02 ..in case we'd want it at db open 2014-04-04 07:08:27 but i think it makes more sense on package preference calc 2014-04-04 07:08:43 i wonder if 'db: allow using cached packages with --no-network' introduced this 2014-04-04 07:09:02 db->available_repos |= BIT(APK_REPOSITORY_CACHED); 2014-04-04 07:09:08 in database.c 2014-04-04 07:09:19 did it most likely 2014-04-04 07:10:36 the thing is that the available_repos is used for other things 2014-04-04 07:10:54 i think it's compare code we need make ignore that special repository 2014-04-04 07:11:31 hmmm 2014-04-04 07:11:53 yeah 2014-04-04 07:11:58 maybe aas a macro 2014-04-04 07:12:11 it's not bitmask tested 2014-04-04 07:12:20 i think we need one more helper bit 2014-04-04 07:13:07 (db->available_repos & db->repos) 2014-04-04 07:13:18 looks like bitmask? 2014-04-04 07:13:36 oh 2014-04-04 07:13:44 pkg_available is only used for preferences 2014-04-04 07:15:35 ncopa, maybe something like http://sprunge.us/VfYO 2014-04-04 07:15:42 db->repos & ((solver_flags & APK_SOLVERF_AVAILABLE) ? (db->available_repos & ~BIT(APK_REPOSITORY_CACHED)) : db->available_repos) 2014-04-04 07:16:39 oh, now i know 2014-04-04 07:16:55 reinstall is allowed to check cache 2014-04-04 07:17:33 i think i'd be ok if we only exclude cache on APK_SOLVERF_AVAILABLE 2014-04-04 07:17:46 yes, i'm looking at it 2014-04-04 07:19:52 ncopa, something like http://sprunge.us/cQLF 2014-04-04 07:21:58 i need update musl too 2014-04-04 07:22:25 and we need to rework the release image creation scripts 2014-04-04 07:42:20 that diff made my desktop want install 262 packages 2014-04-04 07:42:21 hm 2014-04-04 07:43:37 i think thats correct 2014-04-04 07:44:12 with -a, or without ? 2014-04-04 07:44:21 with -a 2014-04-04 07:44:24 not without 2014-04-04 07:44:35 i'll make another simulate test 2014-04-04 07:44:41 with musl http repo 2014-04-04 07:45:13 i tried --repositories-file /dev/null --repository http://nl.alpinelinux.org/alpine/edge-musl/main yesterday 2014-04-04 07:45:21 and it didnt really replace anythin 2014-04-04 07:45:24 (with --simulate) 2014-04-04 07:46:32 yes 2014-04-04 07:46:36 looks much better now 2014-04-04 07:47:44 little bit cleaner patch http://sprunge.us/aEMW 2014-04-04 07:47:50 removed some redundant tests 2014-04-04 07:47:55 should work identically 2014-04-04 07:48:12 ok. i guess i'll push that 2014-04-04 07:57:35 very well 2014-04-04 07:58:06 oh 2014-04-04 07:58:21 one more related bug 2014-04-04 07:58:34 Installed: Available: 2014-04-04 07:58:34 libva-intel-driver-1.0.20-r0 < 1.3.0-r0 2014-04-04 07:58:39 apk upgrade -a 2014-04-04 07:58:48 did not upgrade libva-intel-driver 2014-04-04 07:58:53 it's held back? 2014-04-04 07:58:58 what does apk upgrade --latest say? 2014-04-04 07:59:15 ncopa-desktop:~/Projects/apk-tools$ apk upgrade --latest --simulate 2014-04-04 07:59:15 OK: 3034 MiB in 1041 packages 2014-04-04 07:59:29 its pulled in from install_if 2014-04-04 07:59:53 libva-intel-driver-1.0.20-r0 has auto-install rule: 2014-04-04 07:59:53 libva 2014-04-04 07:59:53 xf86-video-intel 2014-04-04 08:00:08 which is not versioned 2014-04-04 08:00:08 and what's the rule in 1.3.0 ? 2014-04-04 08:00:17 libva-intel-driver-1.3.0-r0 has auto-install rule: 2014-04-04 08:00:17 libva 2014-04-04 08:00:17 xf86-video-intel 2014-04-04 08:00:54 hmm 2014-04-04 08:01:01 depends are identical 2014-04-04 08:01:47 and apk policy ? 2014-04-04 08:02:13 libva-intel-driver policy: 2014-04-04 08:02:13 1.0.20-r0: 2014-04-04 08:02:13 lib/apk/db/installed 2014-04-04 08:02:13 1.3.0-r0: 2014-04-04 08:02:13 http://nl.alpinelinux.org/alpine/edge/main 2014-04-04 08:02:39 i can work around it by apk add -u it 2014-04-04 08:02:48 ncopa-desktop:~/Projects/apk-tools$ apk add -u --simulate 'libva-intel-driver' 2014-04-04 08:02:48 (1/1) Upgrading libva-intel-driver (1.0.20-r0 -> 1.3.0-r0) 2014-04-04 08:03:04 so its the installed_if that messes things up 2014-04-04 08:03:22 but in general, its kinda stupid to have install_if without exact version deps 2014-04-04 08:04:57 ncopa, testdisk needs rebuild after ntfs-3g upgrade 2014-04-04 08:07:45 ok 2014-04-04 08:07:47 i'm on it 2014-04-04 08:08:07 i'm on the install_if issue 2014-04-04 08:22:07 ok, i know why things fail with install_if upgrade, i'm thinking up solution - should not be hard 2014-04-04 08:22:18 nice 2014-04-04 09:05:29 ncopa, can you test http://sprunge.us/VjSI 2014-04-04 09:05:32 should fix install_if 2014-04-04 09:06:13 1 file changed, 28 insertions(+), 56 deletions(-) 2014-04-04 09:06:19 i like fixes like that :) 2014-04-04 09:06:32 indeed :) 2014-04-04 09:07:38 i'm off for lunch 2014-04-04 09:07:42 will commit after that if it's ok 2014-04-04 09:07:45 i think it should be ok 2014-04-04 09:08:07 ncopa-desktop:~/Projects/apk-tools$ sudo src/apk upgrade --simulate 2014-04-04 09:08:07 (1/1) Upgrading libva-intel-driver (1.0.20-r0 -> 1.3.0-r0) 2014-04-04 09:08:11 looks good to me 2014-04-04 09:08:51 (1/11) Upgrading sqlite-libs (3.8.4.2-r0 -> 3.8.4.3-r0) 2014-04-04 09:08:51 (2/11) Replacing krb5-conf (1.0-r0 -> 1.0-r0) 2014-04-04 09:08:51 (3/11) Replacing libnice (0.1.4-r0 -> 0.1.4-r0) 2014-04-04 09:08:51 (4/11) Upgrading php-common (5.5.10-r0 -> 5.5.11-r0) 2014-04-04 09:08:51 (5/11) Upgrading php-cgi (5.5.10-r0 -> 5.5.11-r0) 2014-04-04 09:08:52 (6/11) Upgrading php (5.5.10-r0 -> 5.5.11-r0) 2014-04-04 09:08:54 Executing php-5.5.11-r0.post-upgrade 2014-04-04 09:08:56 (7/11) Upgrading php-xml (5.5.10-r0 -> 5.5.11-r0) 2014-04-04 09:08:58 (8/11) Replacing thunar-vcs-plugin-svn (0.1.4-r4 -> 0.1.4-r4) 2014-04-04 09:09:00 (9/11) Upgrading php-wddx (5.5.10-r0 -> 5.5.11-r0) 2014-04-04 09:09:02 (10/11) Upgrading libva-intel-driver (1.0.20-r0 -> 1.3.0-r0) 2014-04-04 09:09:04 (11/11) Upgrading sqlite (3.8.4.2-r0 -> 3.8.4.3-r0) 2014-04-04 09:09:06 i wonder why he replaced those 2014-04-04 09:10:06 cannot send custom mqtt msg.a.o -- -t "irc/%alpine-devel" -m "$message" 2014-04-04 09:10:27 seems disabled now 2014-04-04 09:11:58 vkrishn: works for me? 2014-04-04 09:12:26 trying from mosquitto 1.3.1 2014-04-04 09:12:35 v1.3 2014-04-04 09:12:49 $ apk version mosquitto-clients 2014-04-04 09:12:49 Installed: Available: 2014-04-04 09:12:49 mosquitto-clients-1.3.1-r0 = 1.3.1-r0 2014-04-04 09:13:02 ok will retry 2014-04-04 09:18:21 ncopa: are those builders drinking redbull? 2014-04-04 09:18:28 lol 2014-04-04 09:24:51 ncopa: did they recently witch to new msg system? 2014-04-04 09:25:09 clandmeter: who? the builders? 2014-04-04 09:25:15 algitbot 2014-04-04 09:25:23 and maybe the builders. i dont know how it all works 2014-04-04 09:25:30 looks like it works snappoier 2014-04-04 09:25:34 snappier 2014-04-04 09:25:45 i recently replaced the old shell based buildrepo script to a lua based 2014-04-04 09:25:51 should be much faster 2014-04-04 09:26:47 anyone now can send crap to msg.a.o? 2014-04-04 09:45:49 yup 2014-04-04 09:45:58 if it gets abused we'll close it 2014-04-04 09:49:57 vkrishn: if mqtt -> irc gets abused (or people start complain) I'll close it down 2014-04-04 09:50:13 ok 2014-04-04 09:56:50 maybe use acl or pwf 2014-04-04 09:57:36 sorry for last few test msgs, moving to other test servers now :) 2014-04-04 12:39:43 last msg build/# and git/# are retained but not irc/# 2014-04-04 13:08:11 ncopa, i need ldap support to cyrus-sasl. Do you think is going to be a problem, now, compiling sasl with ldap support? 2014-04-04 13:13:04 wasnt there a circular dep problem? 2014-04-04 13:13:13 yup it was 2014-04-04 13:13:50 you need cyrus-sasl to build openldap and if you enable it in cyrus-sasl, you'll need openldap to buidl cyrus-sasl 2014-04-04 13:13:51 aa 2014-04-04 13:13:57 aah 2014-04-04 13:14:06 i wonder if we could build it as a module 2014-04-04 13:14:13 from a second package 2014-04-04 13:14:23 as subpkg ? 2014-04-04 13:14:24 from a secon cyrus-sasl-openldap 2014-04-04 13:14:25 no 2014-04-04 13:14:32 separate apkbuild 2014-04-04 13:14:35 its not a runtime problem 2014-04-04 13:14:45 ok 2014-04-04 13:14:48 its a buildtime problem 2014-04-04 13:15:11 hm 2014-04-04 13:15:24 i wonder if we should enable a BOOTSTRAP flag 2014-04-04 13:15:44 set BOOTRAP=true on the first build 2014-04-04 13:15:58 then rebuild without it 2014-04-04 13:16:35 that woudl probably also let us bootstrap openjdk and similar 2014-04-04 13:16:40 hm 2014-04-04 13:16:59 ACTION is looking for BOOTSTRAP 2014-04-04 13:17:32 we dont have any such flag atm 2014-04-04 13:17:37 the idea is when building a new arch 2014-04-04 13:17:50 we do the first build with BOOTSTRAP=true 2014-04-04 13:18:04 "The goal should be to produce a compiler that is exactly the same as if it were bootstrapped" 2014-04-04 13:18:10 ok now i understand 2014-04-04 13:18:18 in cyrus-sasl you then only add openldap subpackage if BOOTSTRAP is not build 2014-04-04 13:18:35 so first run, you will not get cyrus-sasl-ldap 2014-04-04 13:18:52 because you need cyrus-sasl to build openldap istelf first time 2014-04-04 13:18:57 then we do a second pass 2014-04-04 13:19:07 and rebuild all packages that use the BOOTSTRAP flag 2014-04-04 13:19:15 so second round we have openldap 2014-04-04 13:19:28 and can build cyrus-sasl-ldap 2014-04-04 13:19:37 ok make sense 2014-04-04 13:19:44 we could do simlar with openjdk 2014-04-04 13:19:45 compile in two steps 2014-04-04 13:19:53 which needs openjdk to build itself 2014-04-04 13:19:55 yes 2014-04-04 13:20:58 sounds like $programming_language that was made using $programming_language... 2014-04-04 13:21:54 yes 2014-04-04 13:22:22 but it means that rebuilding world, or build a new arch from scratch 2014-04-04 13:22:27 needs special handling 2014-04-04 13:22:35 needs to be done twice 2014-04-04 13:22:43 i have tried avoid that as much as possible 2014-04-04 13:23:14 basically with this arch we can't 2014-04-04 13:23:25 the second option is that you cp cyrus-sasl/APKBUILD cyrus-sasl-ldap/APKBUILD 2014-04-04 13:23:54 and on -ldap variant you dont in tall the init.d, the main binary or anything, *only* the ldap plugin 2014-04-04 13:24:20 then we get maintenance burden 2014-04-04 13:24:42 when upgrading cyrus-sasl, we need update cyrus-sasl-ldap 2014-04-04 13:24:46 I think we can postpone this when musl will be available 2014-04-04 13:24:51 ok 2014-04-04 13:25:06 i'd prefer second option 2014-04-04 13:25:21 since i need this atm, i can compile the apk and install it manually 2014-04-04 13:25:23 circular build deps will cause many problems 2014-04-04 13:25:26 yes 2014-04-05 18:04:49 kaniini, are you working on kueventd? I found your kueventd repo on github, but see only initial commit. 2014-04-05 21:00:47 j_v: i plan to this summer 2014-04-05 21:35:39 OK, I'll have to find another name then. 2014-04-05 21:36:23 I was looking at using ueventd, search brought me to kueventd. 2014-04-05 21:40:36 I've got the netlink and rule parsing pretty well tested, but still have to work on rule matching/actions as well as compatiblity lib for libudev. 2014-04-06 17:28:53 is dkimproxy still in testing? 2014-04-06 17:31:44 and prosody 2014-04-06 17:37:08 yes 2014-04-07 07:27:12 sweet virt-manager-1.0 has support for disk image snapshots 2014-04-07 07:27:30 will be handy when testing the upgrade-to-musl 2014-04-07 07:28:08 I am installing a v2.7 vm now and test the migration to musl 2014-04-07 07:45:55 moin 2014-04-07 07:46:19 ncopa: any news regarding the switch of edge-systems to musl? 2014-04-07 07:46:35 can/should i update? 2014-04-07 07:52:17 StarWarsFan, not done yet, planning to it today sometime 2014-04-07 07:52:47 ok, thx 2014-04-07 07:59:25 StarWarsFan: you can do: apk upgrade -U -a now though 2014-04-07 07:59:32 so your box is latest uclibc 2014-04-07 07:59:47 I just did that with my work desktop 2014-04-07 07:59:56 i am testing the migration from v2.7 to edge-musl 2014-04-07 08:02:48 ok, thx 2014-04-07 08:06:06 i think the migration process will be something like: 2014-04-07 08:06:14 (edit /etc/apk/repositories) 2014-04-07 08:06:24 apk add -U apk-tools-static busybox-static 2014-04-07 08:06:28 apk upgrade -U -a 2014-04-07 08:06:30 and thats it 2014-04-07 08:12:32 very promising 2014-04-07 08:12:54 after doing the upgrade (and apk fix a couple of times) 2014-04-07 08:12:58 firefox started up :) 2014-04-07 08:13:02 busybox-static is probably unnecessary 2014-04-07 08:13:08 even before reboot 2014-04-07 08:13:10 yes 2014-04-07 08:13:14 its a saftynet 2014-04-07 08:13:19 and you want to use apk.static instead of apk 2014-04-07 08:13:29 yes, try 2014-04-07 08:13:30 true 2014-04-07 08:13:39 (probably pointless too, but haven't tested shared apk yet) 2014-04-07 08:13:57 no, i think its a good idea 2014-04-07 08:13:59 alternatively 2014-04-07 08:14:20 apk add -U -u apk-tools && apk upgrade -U -u 2014-04-07 08:14:31 could be it will just work with apk upgrade -U -a too 2014-04-07 08:14:42 since it will upgrade apk-tools first 2014-04-07 08:14:46 and then re-run upgrade 2014-04-07 08:14:51 ah, maybe not 2014-04-07 08:15:12 due to shared zlib and openssl is still there 2014-04-07 08:15:18 yeah, you should rather defer the upgrade of apk 2014-04-07 08:15:32 so, yes apk.static is what we want to use 2014-04-07 08:15:33 i think 2014-04-07 08:17:27 prrof that it worked: http://imgur.com/1b21il5 2014-04-07 08:17:35 i did apk upgrade and then started firefox 2014-04-07 08:18:09 fabled: no need to bump musl? 2014-04-07 08:18:41 clandmeter, oops, mistake. 2014-04-07 08:19:01 i had it there, but needed to revert something and accidentally that got reverted 2014-04-07 08:20:00 hm 2014-04-07 08:20:16 but xorg broke after the reboot 2014-04-07 08:21:58 clandmeter, i'll bump musl in a bit - i need to change one of the patches too 2014-04-07 08:24:56 fabled: no worries, i was just suprised algitbot claimned to have build musl and send it to nl.a.o in just 1 second. thats why i checked your commit. 2014-04-07 08:25:15 clandmeter, musl builds in few seconds ;) 2014-04-07 08:25:32 it was less then a few seconds i think 2014-04-07 08:33:48 ok. it took like 5-6 seconds to build... 2014-04-07 08:47:53 :) 2014-04-07 08:59:43 ok. arm box is catching up now. 2014-04-07 08:59:50 i'm off to lunch 2014-04-07 09:08:01 fabled: i dont know if it is a bug or a feature, but 2014-04-07 09:08:08 apk upgrade -U -a 2014-04-07 09:08:21 will first replace apk-tools itself 2014-04-07 09:08:28 it installs musl as a dependency 2014-04-07 09:08:39 but then it fails to run again 2014-04-07 09:09:33 http://imgur.com/vHs619X 2014-04-07 09:10:04 i think the problem is taht the 'update-your-self-before-continue' does not get the --available first 2014-04-07 09:10:14 so apk-tools itself will be linked to musl 2014-04-07 09:10:26 while openssl and libc will be linked to uclibc 2014-04-07 09:10:28 and boom 2014-04-07 09:42:56 ok, i have a musl blocker 2014-04-07 09:43:01 dhcpcd does not work 2014-04-07 09:56:40 ncopa, someone said hwclock does not work on x86 either (non-blocker) but still important 2014-04-07 10:50:47 any thoughts on adding diffutils to vim deps to make vimdiff work? or maybe create a subpackage with the vimdiff symlink and the dep? 2014-04-07 11:07:42 uggedal: i liked the second option better 2014-04-07 12:44:40 ok 2014-04-07 12:44:44 so we have a problem 2014-04-07 12:45:04 it apperas that musl if_nameindex does not return interfaces with any ipv4 addr 2014-04-07 12:45:10 so dhcpcd breaks big time 2014-04-07 12:45:22 we have 3 options 2014-04-07 12:45:56 1) fix musl libc's if_nameindex/getifaddr to use netlink so it gets all needed info properly 2014-04-07 12:46:51 2) hack musl libc to parse /proc/net/dev and possibly fill NULL in getaddrinfo 2014-04-07 12:47:29 3) hack dhcpcd to instead of rely on getaddrinfo, parse the /proc/net/dev itself to get a list of vaild interfaces 2014-04-07 12:48:02 the question is, should this be a blocker for switchign to musl libc? (i think yes) 2014-04-07 12:54:00 mmm. bb dhcpcd works? 2014-04-07 12:55:19 udhcpc, yes it works 2014-04-07 12:57:26 but hum - desktop probably needs the dhcpcd with dbus stuff 2014-04-07 12:57:38 i use it on my work desktop 2014-04-07 12:57:46 i disabled it for not on my laptop 2014-04-07 12:57:54 but, yes would be nice to ahve that working 2014-04-07 12:58:03 if it's fixable in a day, i'm ok holding the switch for a day 2014-04-07 12:59:53 i can try to write a patch (iterating over names in /proc/net/dev and SIOCGIFINDEX them) 2014-04-07 13:23:03 ncopa: got it. vimdiff subpkg patch sent to ml 2014-04-07 14:43:04 hi 2014-04-07 14:43:20 I am still alive, but I need to finish my university right now :( since 2 months... 2014-04-07 20:51:12 patch for OpenSSL to bump to v1.0.1g sent to fix heartbleed exploit 2014-04-07 21:17:25 good night 2014-04-07 21:20:22 files from v2.5.4-272-gc86404f uploaded 2014-04-08 05:49:03 2.4 builder is down 2014-04-08 05:49:39 barthalion, i think it's up, i got openssl update to my alpine 2.4 2014-04-08 05:54:13 so it's just quiet, thanks 2014-04-08 06:01:34 yeah 2014-04-08 06:01:41 barthalion, and thanks for the cherry-picks to stable 2014-04-08 06:01:53 i just upgraded and left to get some sleep. didn't realize how major issue it was. 2014-04-08 06:03:35 fabled: np, I suspected so and I had spare 10 minutes 2014-04-08 06:19:39 wow 2014-04-08 06:20:00 i wake up and every one is heartbleed here and heartbleed there 2014-04-08 06:20:14 but its all fixed :) 2014-04-08 06:20:24 thanks alot fabled and barthalion 2014-04-08 09:53:47 we should probably consider regenerating openssh servers keys and reissuing certificates, if we have any 2014-04-08 09:58:11 i thought openssh was not affected? 2014-04-08 09:58:30 but we should probably generate new keys for https://*.alpinelinux.org 2014-04-08 09:59:00 from what I've heard openssh was not using this features 2014-04-08 10:01:51 yes, openssh is not affected. 2014-04-08 10:01:59 the bug affects SSL/TLS only 2014-04-08 11:58:16 i like how 2014-04-08 11:58:23 openssl basically made ssl worthless 2014-04-08 11:58:27 yet again 2014-04-08 12:14:15 clandmeter: i upgraded www.a.o/bugs.a.o 2014-04-08 12:14:29 k 2014-04-08 12:14:30 http://filippo.io/Heartbleed/#bugs.alpinelinux.org 2014-04-08 12:14:43 simple apk upgrade and restart nginx 2014-04-08 12:59:04 anybody know how I could debug apk segfault? 2014-04-08 12:59:14 I'm trying to upgrade openssl on my firewall 2014-04-08 12:59:31 jrt-vm-fw01 [~]# apk --simulate upgrade 2014-04-08 12:59:31 ERROR: ERROR! requirers not restored between decisions 2014-04-08 12:59:31 Segmentation fault 2014-04-08 12:59:33 jrt-vm-fw01 [~]# apk add openssl 2014-04-08 12:59:35 ERROR: 1 unsatisfiable dependencies: 2014-04-08 12:59:37 libpthread-0.9.33.2-r10: so:ld-uClibc.so.0.9.32 so:libc.so.0.9.32 so:libdl.so.0.9.32 2014-04-08 12:59:39 Segmentation fault 2014-04-08 12:59:42 what apk version? 2014-04-08 12:59:47 apk --version 2014-04-08 12:59:50 apk-tools 2.3.2, compiled for x86. 2014-04-08 13:00:03 and what alpine version? 2014-04-08 13:00:12 there should be an apk-tools-static package 2014-04-08 13:00:16 you should be able wget it 2014-04-08 13:00:20 it's a bit older: 2.5_alpha20121002 2014-04-08 13:00:33 so in between v2.4 and v2.5 2014-04-08 13:00:57 what version of you openssl? 2014-04-08 13:01:36 i think youre affected, 2014-04-08 13:01:37 yeah 2014-04-08 13:01:37 OpenSSL 1.0.1c 10 May 2012 2014-04-08 13:01:41 yeah, I am 2014-04-08 13:01:59 so you want upgrade to v2.4 or v2.5? 2014-04-08 13:02:02 or soemthign else? 2014-04-08 13:02:05 to v2.7? 2014-04-08 13:02:18 whatever the easiest upgrade path is 2014-04-08 13:02:53 32bit or x86_64? 2014-04-08 13:03:00 this vm would be a pain to regen because it handles the incoming network connection on a vmware esx host, and if I shut off the vm I need physical or kvm access to fix it all 2014-04-08 13:03:08 32 2014-04-08 13:03:17 wget http://nl.alpinelinux.org/alpine/v2.4/main/x86/apk-tools-static-2.3.4-r0.apk 2014-04-08 13:03:35 mkdir /tmp/apk && cd /tmp/apk 2014-04-08 13:03:58 wget -O - http://nl.alpinelinux.org/alpine/v2.4/main/x86/apk-tools-static-2.3.4-r0.apk | tar -zx sbin/apk.static 2014-04-08 13:04:26 then use that apk.static to upgrade 2014-04-08 13:19:13 ncopa: you're awesome! thank you!!!! 2014-04-08 13:19:15 Actively checking if CVE-2014-0160 works: Your server appears to be patched against this bug. 2014-04-08 13:33:04 well its fabled and barthalion that are awesome for so quickly push fixes to stable branches and fabled is awesome for apk-tools 2014-04-08 13:33:22 i just git tag replease once in a while ;) 2014-04-08 13:33:26 releases* 2014-04-08 15:01:37 files from v2.5.4-273-g3b20c95 uploaded 2014-04-09 08:40:55 seems like we god the musl getifaddrs issue fixed 2014-04-09 08:44:51 I think we will switch to musl this afternoon then 2014-04-09 08:44:58 I'll just test the migration in a vm 2014-04-09 08:52:55 great 2014-04-09 09:21:15 ncopa, i've some mixed packages (v2.7 and edge). I put v2.7 in repos, but apk upgrade -a doesn't downgrade packages. 2014-04-09 09:21:45 would be fine to upgrade everything in edge before musl switch? 2014-04-09 09:22:45 i think it should be ok to upgrade everything to musl after the switch 2014-04-09 09:22:46 but 2014-04-09 09:22:47 ... 2014-04-09 09:22:51 it might break things :) 2014-04-09 09:22:56 we havent tested all apps yet 2014-04-09 09:23:07 :) 2014-04-09 09:23:08 Ok 2014-04-09 09:23:13 since is a production server 2014-04-09 09:23:15 what apk version do you have 2014-04-09 09:23:19 apk --version 2014-04-09 09:23:19 2.4.1 2014-04-09 09:23:36 try upgrade apk first: apk add -U -u apk-tools 2014-04-09 09:23:42 to 2.4.2 2014-04-09 09:23:57 it's in edge? 2014-04-09 09:24:02 should be yes 2014-04-09 09:24:06 k 2014-04-09 09:24:19 i think that should downgrade your thing 2014-04-09 09:24:19 oh 2014-04-09 09:24:39 apk upgrade -U -a --no-self-upgrade 2014-04-09 09:24:49 should bring it down to v2.7 2014-04-09 09:25:06 ok 2014-04-09 09:25:09 the 2.4.2 fixes -a option in apk-tools 2014-04-09 09:25:14 oh 2014-04-09 09:25:15 ok 2014-04-09 09:25:53 ACTION is hoping to not break anything :) 2014-04-09 09:25:57 we should probably add apk 2.4.2 to v2.7 branch 2014-04-09 09:26:06 use --simulate first if unsure 2014-04-09 09:26:15 yes is what i did 2014-04-09 09:26:23 bus since kerberos is involved 2014-04-09 09:26:46 i hope that winbind doesn't stop to work 2014-04-09 09:28:40 everyhing has been downgraded to 2.7 2014-04-09 10:02:01 fcolista, downgrading is fixed in apk 2.4.2 2014-04-09 10:02:12 ncopa, yes, that and awall should be cherry-picked to 2.7-stable 2014-04-09 10:02:25 thx fabled. Has worked. 2014-04-09 10:08:12 fabled: i'm waiting for getifaddrs in musl 2014-04-09 10:08:21 oh its lunch.. 2014-04-09 10:08:23 ncopa, yes, i'm on it 2014-04-09 10:08:29 will push in 10-15 mins 2014-04-09 10:10:38 incidentally 2014-04-09 10:10:51 do i need to spank anyone at redhat for not telling us about this openssl thing 2014-04-09 10:11:04 since they claim they told other distributions 2014-04-09 10:11:48 we should probably try to subscribe to the closed lists they have for those kind of things 2014-04-09 10:12:54 openssl does not have one 2014-04-09 10:12:58 already looked into that 2014-04-09 10:13:35 it's unsurprising that heartbleed was a disaster 2014-04-09 10:13:43 that bug is too hot to keep under wraps 2014-04-09 10:15:38 yeah. it was a major mess up on so many levels. 2014-04-09 10:16:08 kaniini: did they? 2014-04-09 10:16:12 they didn't tell Arch 2014-04-09 10:16:16 barthalion: yes, nor debian 2014-04-09 10:16:53 punching them will be very appreciated 2014-04-09 10:17:36 considering if they told debian, we would have found out that way most likely 2014-04-09 10:17:39 or arch 2014-04-09 10:19:03 i wonder if *BSD was told 2014-04-09 10:19:56 i'm member of netbsd foundation... and the chatter on private lists indicate that netbsd was not informed. 2014-04-09 10:20:19 mmm 2014-04-09 10:20:22 well there's this: 2014-04-09 10:20:31 so apparently only RH knew and kept this info for themselves 2014-04-09 10:20:40 We did not have advance warning before this morning (Pacific time), and even that was a generic "there will be openssl bugs embargoed until April 9th". 2014-04-09 10:21:11 i believe *everyone* got hit by surprised with this. and there's a mighty amount of angry people. 2014-04-09 10:24:34 well 2014-04-09 10:24:36 it is april 9 2014-04-09 10:24:44 and i can see that embargo really worked out 2014-04-09 10:33:28 very nice 2014-04-09 10:34:08 ncopa, ok. i think we should be set for musl migration 2014-04-09 10:36:03 can we keep the uclibc tree around as edge-uclibc for a little while 2014-04-09 10:36:27 i have a few hundred installs that i don't necessarily want to upgrade to musl quite yet 2014-04-09 10:36:44 kaniini, yes, that was the plan 2014-04-09 10:36:51 rename edge to edge-old or edge-uclibc 2014-04-09 10:37:00 works for me 2014-04-09 10:37:01 and then rename edge-musl to edge 2014-04-09 10:37:10 or keep pushing to edge-musl 2014-04-09 10:37:14 rename edge to edge-uclibc 2014-04-09 10:37:17 and symlink edge-musl to edge 2014-04-09 10:37:19 or whatever 2014-04-09 10:54:02 brb 2014-04-09 10:57:49 http://article.gmane.org/gmane.os.openbsd.misc/211963 2014-04-09 11:01:46 an email from Theo dropping crap on everyone else, classic :) (not that he is not right) 2014-04-09 11:04:48 Ted's tests show you can't turn it off because they haven't tested 2014-04-09 11:04:49 without it in ages. 2014-04-09 11:04:51 well 2014-04-09 11:04:56 clearly i know what we must do with openssl in alpine now 2014-04-09 11:05:40 oh thats brilliant 2014-04-09 11:05:43 So then a bug shows up which leaks the content of memory mishandled by 2014-04-09 11:05:43 that layer. If the memoory had been properly returned via free, it 2014-04-09 11:05:43 would likely have been handed to munmap, and triggered a daemon crash 2014-04-09 11:05:43 instead of leaking your keys. 2014-04-09 11:05:58 time to fix this 'feature' 2014-04-09 11:06:01 to aports i go 2014-04-09 11:06:10 so the bug could have been discovered... 2014-04-09 11:06:41 ok 2014-04-09 11:06:51 i will test migration again 2014-04-09 11:08:46 i wonder if i should run som service or web app too 2014-04-09 11:08:48 for the test 2014-04-09 11:09:04 > OpenSSL is not developed by a responsible team. 2014-04-09 11:09:10 yeah.. 2014-04-09 11:09:18 someone should point theo to ralf engelschall's website 2014-04-09 11:09:23 that guy has a giant ego 2014-04-09 11:09:39 http://engelschall.com/ 2014-04-09 11:10:33 http://engelschall.com/canvas-crop-canvas-any.jpg 2014-04-09 11:10:38 this pretty much covers it 2014-04-09 11:10:41 haha 2014-04-09 11:12:39 looks like OPENSSL_malloc() is the function we have to lobotomize 2014-04-09 11:14:47 I cannot belive this is his own webpage, seems like a very big joke... 2014-04-09 11:15:15 software artist hehehehe 2014-04-09 11:15:25 yeah, he's delivered some art for sure 2014-04-09 11:15:36 rofl 2014-04-09 11:15:40 maybe he will write something like 2014-04-09 11:16:06 "in an art installation in 2014, we made all ssl private keys worthless by replacing malloc() because we're more competent than everyone else" 2014-04-09 11:16:26 "especially c standard library developers" 2014-04-09 11:19:24 its the same guy that brought us pth... 2014-04-09 11:20:52 as i recall it 2014-04-09 11:20:55 pth is not very great either 2014-04-09 11:25:22 pth is pretty pointless 2014-04-09 11:26:03 http://turtle.dereferenced.org/~kaniini/openssl-labotomy.patch 2014-04-09 11:26:23 this seems to be all we need to permanently fix any future heartbleed issues 2014-04-09 11:27:09 kaniini, should we not just #define OPENSSL_NO_BUF_FREELISTS ? 2014-04-09 11:27:14 fabled: it breaks ABI 2014-04-09 11:27:19 really? 2014-04-09 11:27:21 yes 2014-04-09 11:27:27 it elides the members from the struct entirely 2014-04-09 11:27:29 that's messed up 2014-04-09 11:27:57 it's openssl. 'messed up' does not begin to describe it 2014-04-09 11:28:48 hmm 2014-04-09 11:29:10 i'd rather just #define the magic define, and fix the struct definition 2014-04-09 11:29:16 that way all the extra crap code is left out 2014-04-09 11:29:58 lol 2014-04-09 11:30:00 sure 2014-04-09 11:30:03 they say malloc is slow 2014-04-09 11:30:12 and then they contend in single big mutex the freelist code 2014-04-09 11:30:33 well OPENSSL_malloc() is just a wrapper around malloc with debug hooks 2014-04-09 11:30:34 that kinda.... makes the freelists slower than sane modern alloc 2014-04-09 11:30:35 like g_malloc() 2014-04-09 11:31:05 (at least on our 24-core boxes ;) ) 2014-04-09 11:32:02 i think even if you're running on a 486 2014-04-09 11:32:06 you have a bigger problem than that 2014-04-09 11:32:24 yes 2014-04-09 11:32:44 just that... whatever they tried to achieve... is actually made worse in modern systems. 2014-04-09 11:33:09 well, it wouldn't be openssl without that level of sillyness really 2014-04-09 11:33:19 but yes 2014-04-09 11:33:27 even the simples asn1 stuff keeps mallocing, copying, and freeing 2014-04-09 11:33:37 so yeah. that follows the general pattern 2014-04-09 11:34:57 kaniini, you fixing the patch to #define OPENSSL_NO_BUF_FREELISTS unconditionally + adding padding in that one struct? 2014-04-09 11:36:10 i can 2014-04-09 11:36:34 i'm just wanting to verify that the basic idea looks sound 2014-04-09 11:37:29 i havent looked at the code but it sounds like the only sane thing to do is use system malloc 2014-04-09 11:37:57 and see what else that shakes out... 2014-04-09 11:40:11 kaniini, yeah, i think turning off freelists is good idea 2014-04-09 11:40:16 better to double check still 2014-04-09 11:40:52 hum 2014-04-09 11:40:53 ecure Connection Failed 2014-04-09 11:40:53 An error occurred during a connection to www.kernel.org. The OCSP server has no status for the certificate. 2014-04-09 11:42:05 lol. i wonder why lwn.net's Tuesday's security updates has everyone updating openssl 2014-04-09 11:43:55 yep 2014-04-09 11:44:36 now i just need to figure out how to add custom cflags to this junk 2014-04-09 11:50:51 http://turtle.dereferenced.org/~kaniini/openssl-labotomy-2.patch 2014-04-09 11:50:53 fabled: ^ 2014-04-09 11:54:14 whee! 2014-04-09 11:54:29 the musl migration in vm was great success 2014-04-09 11:54:54 i'm stopping buildservers now 2014-04-09 11:56:08 brb 2014-04-09 11:58:25 hm 2014-04-09 11:59:46 i wonder if i should wait for the sync mirror job at 12:00 UTC 2014-04-09 11:59:55 in 10 secs 2014-04-09 12:00:50 probably 2014-04-09 12:00:57 http://trainofthoughts.org/blog/ 2014-04-09 12:01:12 mr. openssl likes that photo a lot 2014-04-09 12:03:20 i kind of want to run openssl through coverity 2014-04-09 12:03:26 i bet there's a lot more where that came from 2014-04-09 12:05:14 kaniini, yeah, looks good for me. just wondering if the #define should go in the header, or APKBUILD. just in case... you know openssl might accidentally break their CFLAGS... 2014-04-09 12:05:53 you have a good point there 2014-04-09 12:06:02 we might be expecting too much competence from openssl still 2014-04-09 12:10:25 i'm building the package and making sure openssl seems sane still 2014-04-09 12:11:03 kaniini, thanks 2014-04-09 12:16:31 >>> openssl-dev*: Package size: 339.6 MB 2014-04-09 12:16:33 ow 2014-04-09 12:16:41 -rw-r--r-- 1 kaniini kaniini 297M Apr 9 12:12 libcrypto.a 2014-04-09 12:16:45 seems a bit large ? 2014-04-09 12:23:16 seems to work fine 2014-04-09 12:23:22 pushing... 2014-04-09 12:39:27 edge is now musl 2014-04-09 12:39:34 i will restart the builders 2014-04-09 12:40:09 whee! 2014-04-09 12:47:21 hm 2014-04-09 12:47:31 it does not sart networking at boot for some reason 2014-04-09 12:48:21 brb 2014-04-09 12:53:37 ha 2014-04-09 12:53:40 i think i know why now 2014-04-09 12:53:44 OpenRC 0.12.4.b5858b1 is starting up Linux 3.10.33-0-grsec (i686) [VSERVER] 2014-04-09 12:53:46 VSERVER 2014-04-09 12:56:13 that was first package upgraded 2014-04-09 12:56:19 i will start up x86_64 now 2014-04-09 13:01:34 and build-edge-x86_64 is now up 2014-04-09 13:06:09 nice 2014-04-09 13:07:49 I sent email 2014-04-09 13:07:55 i should post on news too 2014-04-09 13:07:57 on www.a.o 2014-04-09 13:10:34 upgrading my work desktop now... 2014-04-09 13:22:33 ncopa: something wrong with www.a.o? 2014-04-09 13:27:38 i was about to ask the same 2014-04-09 13:27:53 i logged in and tried to do preview of the annoucement 2014-04-09 13:27:57 you are the last to touch it 2014-04-09 13:27:57 and boom 2014-04-09 13:28:00 so i blame you 2014-04-09 13:28:06 :) 2014-04-09 13:28:09 bah :) 2014-04-09 13:28:25 um 2014-04-09 13:28:30 im might have problem though... 2014-04-09 13:28:41 i'm in the middle of musl migration.. 2014-04-09 13:41:51 http://alpinelinux.org/edge-musl 2014-04-09 13:41:55 does it look ok? 2014-04-09 13:42:51 i think so 2014-04-09 13:45:25 for point 1. -- there should be only one enty in /etc/apk/repositories 2014-04-09 13:45:50 or two if using testing pkgs 2014-04-09 13:47:01 clandmeter, will the test server (shell) be upgraded to musl or wait for a day or 2 ? 2014-04-09 13:47:25 vkrishn: its up to you 2014-04-09 13:49:07 ok, would try upgrading tomorrow 2014-04-09 13:50:08 no date here http://alpinelinux.org/edge-musl 2014-04-09 13:55:07 hum 2014-04-09 13:55:10 it died again 2014-04-09 13:56:28 something is going on with www.a.o 2014-04-09 13:56:44 bugs.a.o is find 2014-04-09 13:56:48 fine 2014-04-09 13:56:54 so its something with drupal site 2014-04-09 13:57:56 really... it is unreacheable her 2014-04-09 13:57:58 from here 2014-04-09 13:58:30 yes 2014-04-09 13:58:40 me and clandmeter are looking into it 2014-04-09 14:35:21 ncopa, should i change arm-hf push address too? 2014-04-09 14:36:06 mmm 2014-04-09 14:36:08 i think i yes 2014-04-09 14:40:26 ok. edge builder renamed and updated to push directly to edge (not edge-musl) 2014-04-09 14:41:12 fabled did you rename the dir on rsync.a.o too? 2014-04-09 14:41:27 ncopa, you renamed it 2014-04-09 14:41:33 edge-musl -> edge 2014-04-09 14:41:36 oh :) 2014-04-09 14:41:36 it contains all archs 2014-04-09 14:41:39 yup 2014-04-09 14:41:39 :) 2014-04-09 14:41:53 sorry. 2014-04-09 14:42:06 np 2014-04-09 14:47:21 for some reason apk upgrade is very slow here 2014-04-09 14:47:28 i thin its network to nl.a.o 2014-04-09 14:47:30 dunno why 2014-04-09 14:47:55 yes 2014-04-09 14:47:57 we are capping 2014-04-09 14:48:04 and i dont know why 2014-04-09 14:48:29 i suppose mirrors syncing 2014-04-09 14:48:36 edge-musl -> edge 2014-04-09 14:48:43 means they all transfer various GBs 2014-04-09 14:48:44 i guess so 2014-04-09 14:49:20 looks like 100Mbit is full utilized... 2014-04-09 14:49:32 need to upgrade to 10Gbit 2014-04-09 14:50:07 ncopa: didnt we have a limit on rsync? 2014-04-09 14:50:11 like 50Mbit 2014-04-09 14:51:27 we do 2014-04-09 14:51:35 it's per-transfer? 2014-04-09 14:51:37 real 1h 39m 29s 2014-04-09 14:51:37 or total? 2014-04-09 14:51:54 /usr/bin/rsync --daemon --bwlimit=5000 2014-04-09 14:51:55 i mean per-client, or total? 2014-04-09 14:51:57 it too me 1hour 40 mins to replace 1022 pakages 2014-04-09 14:52:26 over 1 hour? 2014-04-09 14:52:35 i think --bwlimit is per-client 2014-04-09 14:52:36 yup 2014-04-09 14:52:44 oh 2014-04-09 14:52:47 problem 2014-04-09 14:52:50 gnupg 2014-04-09 14:53:01 (3/3) Reinstalling gnupg1 (1.4.16-r3) 2014-04-09 14:53:01 ERROR: gnupg1-1.4.16-r3: trying to overwrite usr/bin/gpg owned by gnupg-2.0.22-r1. 2014-04-09 14:53:12 i think we should let gnupg1 overwrite gnupg2 2014-04-09 14:53:24 replace and conflict? 2014-04-09 14:53:24 ha! 2014-04-09 14:53:34 mmm 2014-04-09 14:53:35 terminal compes up again 2014-04-09 14:53:35 no 2014-04-09 14:53:40 it provides gnupg 2014-04-09 14:53:47 yes, just add replaces 2014-04-09 14:53:54 why do we have gnupg1 in repositories in the first place? 2014-04-09 14:54:04 barthalion, gnupg2 depends on pth 2014-04-09 14:54:08 and pth does not work on musl 2014-04-09 14:54:15 pth is horribly broke in other ways too 2014-04-09 14:54:26 oh 2014-04-09 14:54:28 and the gnupg 2.1.x that uses npth, is not out yet 2014-04-09 14:55:05 so no gnupg2 for musl 2014-04-09 14:56:07 ncopa: i think bwlimit is client side config only 2014-04-09 14:56:15 atleast i cannot find it in rsyncd 2014-04-09 14:56:25 and pth is written by Engelschall… 2014-04-09 14:56:41 so much yay 2014-04-09 14:57:04 yup.. :) 2014-04-09 14:59:50 ncopa-desktop:~$ sudo apk del gnupg 2014-04-09 14:59:51 World updated, but the following packages are not removed due to: 2014-04-09 14:59:51 gnupg: gnupg1 gpgme mutt claws-mail-plugins-pgp pacman debian-archive-keyring 2014-04-09 15:00:21 ncopa, yes, gnupg1 provides gnupg 2014-04-09 15:00:32 looks correct to me 2014-04-09 15:00:51 ncopa-desktop:~$ apk info | grep gnupg 2014-04-09 15:00:51 gnupg 2014-04-09 15:00:51 gnupg1 2014-04-09 15:00:57 it does not remove gnupg 2014-04-09 15:01:14 as long gnupg is installed it will not purge uclibc 2014-04-09 15:01:49 hm 2014-04-09 15:01:57 i have lots from testing repo 2014-04-09 15:01:59 ok 2014-04-09 15:02:03 i will have to clean up my desktop tm 2014-04-09 15:04:11 see u 2014-04-09 15:04:27 and thanks *lot* for eveyone helping making the musl migratino possible 2014-04-09 15:04:32 great work everyone! 2014-04-09 15:08:19 ncopa, weird. you have gnupg1 installed, so the uclibc gnupg should not be installed anymore 2014-04-09 15:08:24 apk will refuse to install both 2014-04-09 15:08:31 sounds like someone else is holding uclibc 2014-04-09 15:08:36 try apk del uclibc 2014-04-09 15:21:54 14:53:31 @fabled | pth is horribly broke in other ways too 2014-04-09 15:22:06 between openssl and pth, is there anything that guy makes that isnt a disaster 2014-04-09 15:27:04 surely not websites 2014-04-09 15:39:05 barthalion: i dont understand how one can pose that way 2014-04-09 15:39:08 like 2014-04-09 15:39:14 i seriously tried to mimic it earlier 2014-04-09 15:40:58 I don't know either, I won't even try 2014-04-09 15:41:06 I can't visualize myself posing like that 2014-04-09 19:21:57 re 2014-04-09 19:22:01 hm: 2014-04-09 19:23:07 trying to update an edge box 2014-04-09 19:23:09 but: http://pastebin.com/2kdyUqDr 2014-04-09 19:23:28 apk fix did not fix the syslinux problem 2014-04-09 19:23:33 ideas? 2014-04-09 19:24:02 this machine is running as a xen domu 2014-04-09 19:39:37 have you tried to run setup-syslinux or whatever we named this script? 2014-04-09 19:57:12 no, will try 2014-04-09 20:00:45 hm, there is no setup-syslinux 2014-04-09 20:00:54 but still a lot of setup-* 2014-04-09 20:02:57 ok, need some sleep now... 2014-04-09 20:02:58 c ya 2014-04-09 21:56:06 ncopa: i think it is appropriate to release an edge iso soon 2014-04-09 22:53:49 can MOSH be moved into main please so it uses MUSL ? 2014-04-09 23:22:37 wait so 2014-04-09 23:22:40 if we're on edge 2014-04-09 23:22:45 and we update/upgrade 2014-04-09 23:22:54 are we automatically going to be pushed into musl 2014-04-09 23:25:26 yes, so be careful 2014-04-09 23:25:46 what do we need to know before we upgrade 2014-04-09 23:26:36 it's on the mailing list and website 2014-04-09 23:26:44 oh ok 2014-04-09 23:49:10 https://www.youtube.com/watch?v=mzSPGkOyzW8 <- we should hire this guy to make a vid of alpine. AMAZING! :) 2014-04-10 05:21:14 Moinmoin 2014-04-10 06:32:15 clandmeter: alpinelinux.org/about says uclibc 2014-04-10 06:32:40 i think we should say uclibc still on front page since the current releases are uclibc 2014-04-10 06:33:22 A security-oriented, lightweight Linux distribution based on uClibc (soon musl libc) and Busybox. 2014-04-10 06:33:26 or similar 2014-04-10 06:53:01 do we have any wikipage descibing how to become an official alpine mirror? 2014-04-10 06:53:05 with requirements? 2014-04-10 07:04:53 I don't think so 2014-04-10 07:05:01 I think that there is a page how to setup a mirror 2014-04-10 07:05:12 but no formal procedure about adding one and requirements 2014-04-10 07:05:14 let the bleed flaming begin: http://openssl.6102.n7.nabble.com/openssl-org-3298-URGENT-quot-Heartbleed-quot-bug-td49214.html 2014-04-10 07:33:35 fabled: i now have onlyl 2 packages which apk version reports '?' 2014-04-10 07:33:38 ncopa-desktop:~$ apk version -l '?' 2014-04-10 07:33:38 Installed: Available: 2014-04-10 07:33:38 abuildhelper-0.0.1-r2 ? 2014-04-10 07:33:38 gnupg-2.0.22-r1 ? 2014-04-10 07:33:49 abuildhelper is pulled in with install_if 2014-04-10 07:34:00 and gnupg i think you know about 2014-04-10 07:34:15 gnupg is fixed 2014-04-10 07:34:18 err 2014-04-10 07:34:22 apk is fixed to do itright now 2014-04-10 07:34:29 abuildhelper is deleted from repos 2014-04-10 07:34:50 that's actually good question 2014-04-10 07:35:01 how to handle install_if pulled stuff if it gets deleted from repositories 2014-04-10 07:35:35 did you push apk-tools fix? 2014-04-10 07:35:38 for fixing gnupg 2014-04-10 07:35:42 to apk-tools.git, yes 2014-04-10 07:35:45 to aports, no 2014-04-10 07:35:48 ok 2014-04-10 07:35:51 i can cherry pick 2014-04-10 07:35:53 thanks 2014-04-10 07:36:02 thought abuildhelper is not fixed yet 2014-04-10 07:36:10 i think 'upgrade -a' should remove it 2014-04-10 07:36:25 since it's no longer available and install_if is "weak" 2014-04-10 07:36:30 but just 'upgrade' should not 2014-04-10 07:36:36 sounds good to me 2014-04-10 07:38:17 ok 2014-04-10 07:38:19 i'll do that too 2014-04-10 07:38:23 should fix the known issues then 2014-04-10 07:40:06 (1/2) Purging gnupg (2.0.22-r1) 2014-04-10 07:40:06 (2/2) Upgrading apk-tools-static (2.4.2-r0 -> 2.4.2-r1) 2014-04-10 07:40:07 whee 2014-04-10 07:40:10 ok 2014-04-10 07:40:22 I will reboot my computer now 2014-04-10 07:40:30 i have it all merged and cleaned up 2014-04-10 07:45:31 ncopa: from yesterday evening: 2014-04-10 07:45:33 trying to update an edge box 2014-04-10 07:45:33 but: http://pastebin.com/2kdyUqDr 2014-04-10 07:45:33 apk fix did not fix the syslinux problem 2014-04-10 07:45:33 ideas? 2014-04-10 07:45:33 this machine is running as a xen domu 2014-04-10 08:11:28 my work desktop is now full musl 2014-04-10 08:12:23 StarWarsFan: what happens if you run: apk fix 2014-04-10 08:12:24 again? 2014-04-10 08:13:04 it looks like you run apk fix before the musl migration 2014-04-10 08:13:16 so you extlinux is likely broke at that point 2014-04-10 08:13:26 right 2014-04-10 08:13:47 and I did not try to update to musl because i dont know if box is coming up after that 2014-04-10 08:14:22 root@builder06:~ apk.static upgrade --no-self-upgrade -U -a --simulate 2014-04-10 08:14:22 fetch http://alpine-mirror.nettworks.org/edge/main/x86_64/APKINDEX.tar.gz 2014-04-10 08:14:22 fetch http://alpine-mirror.nettworks.org/edge/testing/x86_64/APKINDEX.tar.gz 2014-04-10 08:14:22 fetch http://eisfair-ng.nettworks.org/edge/main/x86_64/APKINDEX.tar.gz 2014-04-10 08:14:22 fetch http://eisfair-ng.nettworks.org/edge/testing/x86_64/APKINDEX.tar.gz 2014-04-10 08:14:28 ... 2014-04-10 08:14:34 that did migrate to musl 2014-04-10 08:14:38 all the replacing 2014-04-10 08:14:42 root@builder06:~ apk fix 2014-04-10 08:14:42 (1/1) Reinstalling syslinux (6.02-r0) 2014-04-10 08:14:42 ERROR: syslinux-6.02-r0: BAD signature 2014-04-10 08:14:42 1 errors; 1757 MiB in 491 packages 2014-04-10 08:14:43 root@builder06:~ 2014-04-10 08:15:02 ah, mom 2014-04-10 08:15:04 now: 2014-04-10 08:15:04 apk update first? 2014-04-10 08:15:05 root@builder06:~ apk fix 2014-04-10 08:15:05 (1/2) Installing musl (1.0.0-r8) 2014-04-10 08:15:05 (2/2) Installing syslinux (6.02-r0) 2014-04-10 08:15:05 Executing busybox-1.22.1-r3.trigger 2014-04-10 08:15:05 Executing uclibc-utils-0.9.33.2-r27.trigger 2014-04-10 08:15:07 Executing syslinux-6.02-r0.trigger 2014-04-10 08:15:12 extlinux: no previous syslinux boot sector found 2014-04-10 08:15:14 ERROR: syslinux-6.02-r0.trigger: script exited with error 1 2014-04-10 08:15:16 OK: 1762 MiB in 493 packages 2014-04-10 08:15:19 root@builder06:~ 2014-04-10 08:15:20 hm 2014-04-10 08:15:22 ah 2014-04-10 08:15:26 you did simulate only 2014-04-10 08:15:29 well 2014-04-10 08:15:33 yes 2014-04-10 08:15:34 it still updated index 2014-04-10 08:15:39 you have 'edge' 2014-04-10 08:15:42 because there was the error before 2014-04-10 08:15:44 edge = musl 2014-04-10 08:16:08 if you dont want edge you can either downgrade to v2.7 2014-04-10 08:16:14 ur use edge-uclibc repo 2014-04-10 08:16:26 the edge-uclibc repo will not get any new fixes 2014-04-10 08:17:22 fwiw, i have compelely replaced my work desktop to musl now 2014-04-10 08:17:58 but if you want downgrade back to v2.7 2014-04-10 08:18:11 they i could probably backport quassel for v2.7 2014-04-10 08:18:18 then* 2014-04-10 08:18:31 no, i dont want to downgrade to 2.7 2014-04-10 08:18:35 oh my TZ config is broke 2014-04-10 08:18:36 this is an edge-buildnode 2014-04-10 08:18:40 ok 2014-04-10 08:18:48 i have another buildnodes for 2.7 ;-) 2014-04-10 08:18:49 then you should take the step to musl ;) 2014-04-10 08:18:54 right 2014-04-10 08:19:03 is quassel in main? 2014-04-10 08:19:04 but i was just confused because of the syslinux error 2014-04-10 08:19:16 quassel is in main 2014-04-10 08:19:23 then i think it shoudl all work 2014-04-10 08:19:24 by the way, i have a fix for it 2014-04-10 08:19:34 cause i found an error regarding user setup 2014-04-10 08:19:47 i mean a fix for quassel... 2014-04-10 08:20:02 but has nothing to do with compilation a.s.o. 2014-04-10 08:20:11 ok, i will try to switch to musl now 2014-04-10 08:40:31 ncopa: cool, box came up again ;-) 2014-04-10 08:41:16 418 apk's replaced 2014-04-10 08:41:37 got a lot of these: 2014-04-10 08:41:38 ERROR: musl-dev-1.0.0-r8: trying to overwrite usr/lib/libdl.a owned by uclibc-dev-0.9.33.2-r27. 2014-04-10 08:42:10 but after 'apk del uclibc-dev' and 'apk fix' they went away 2014-04-10 08:42:54 so only the syslinux problem still exists 2014-04-10 08:42:55 root@builder06:~ apk fix 2014-04-10 08:42:55 (1/1) Reinstalling syslinux (6.02-r0) 2014-04-10 08:42:55 Executing syslinux-6.02-r0.post-upgrade 2014-04-10 08:42:55 Executing busybox-1.22.1-r3.trigger 2014-04-10 08:42:55 Executing syslinux-6.02-r0.trigger 2014-04-10 08:42:59 extlinux: no previous syslinux boot sector found 2014-04-10 08:43:02 ERROR: syslinux-6.02-r0.trigger: script exited with error 1 2014-04-10 08:43:04 OK: 1707 MiB in 494 packages 2014-04-10 08:43:06 root@builder06:~ 2014-04-10 08:45:44 extlinux: no previous syslinux boot sector found 2014-04-10 08:46:04 i think thats what extlinux --update /dev/ 2014-04-10 08:46:05 returns 2014-04-10 08:46:20 i have not really experience with xen 2014-04-10 08:46:33 it might be you can extlinux --install 2014-04-10 08:46:40 but i dont know really 2014-04-10 09:01:30 i c 2014-04-10 10:01:59 reinstalling main workstation to musl here now 2014-04-10 10:02:32 apk says i'll free up 67MB of disk space on the switch over 2014-04-10 10:03:14 seems i have slow network 2014-04-10 10:03:28 only 30% done after 3mins 2014-04-10 10:04:30 and it's mostly idle. :/ 2014-04-10 10:08:15 i'm getting 851 apks replaced 2014-04-10 10:12:33 ok. apks installed, doing triggers stills 2014-04-10 10:13:32 ~11mins for complete OS reinstall with ~3GB of stuff installed. and most of that 11min was network wait. not too bad. 2014-04-10 10:14:06 rebooting to see what broke 2014-04-10 10:43:15 fabled: did you use nl.a.o for your upgrade? 2014-04-10 10:43:22 yes 2014-04-10 10:43:53 i wonder if its nl.a.o, although i dont see much load. 2014-04-10 10:44:02 dunno 2014-04-10 10:44:03 ncopa also complained about slow update 2014-04-10 10:44:11 it was not _that_ slow 2014-04-10 10:44:22 11mins to reinstall 3GB 2014-04-10 10:48:19 fabled: your alpine install is 3GB? 2014-04-10 10:48:25 on-disk. yes. 2014-04-10 10:48:28 lot of -dev stuff 2014-04-10 10:48:38 well 2014-04-10 10:48:40 i removed some -dev 2014-04-10 10:48:43 now it's OK: 2826 MiB in 882 packages 2014-04-10 10:49:39 mmm 2014-04-10 10:49:42 TZ 2014-04-10 10:49:49 wrong time-zone 2014-04-10 11:01:29 ncopa, there used to be "building main/pidgin-otr-4.0.0-r1" in msg.a.o 2014-04-10 11:03:38 sent patches for go and docker abuilds to the ml 2014-04-10 11:07:13 vkrishn: what does it say now? 2014-04-10 11:08:57 rest are same, except lines "building main..." 2014-04-10 11:10:30 also went missing "building pkgname" for stable versions 2014-04-10 11:11:46 what does numbers '57/60 1678/1734' refer to ? 2014-04-10 11:16:14 after "building v131211-1590-g3ae8433" there use to be "building main/pidgin-otr-4.0.0-r1" 2014-04-10 11:16:47 now just "57/60 1678/1734 main/pidgin-otr 4.0.0" 2014-04-10 11:29:29 hm, got a problem mit nfs after musl-switch 2014-04-10 11:29:43 ERROR: rpc.statd failed to start 2014-04-10 11:29:48 ERROR: cannot start nfsmount as rpc.statd would not start 2014-04-10 11:34:48 '57/60 1678/1734' 2014-04-10 11:35:05 means that it is currently trying to build 60 packages in this run 2014-04-10 11:35:12 it is right now at 57 2014-04-10 11:35:30 the 1678/1734 are the grand totals 2014-04-10 11:35:35 so its for progress meter 2014-04-10 11:36:12 StarWarsFan: ok, we will have to try fix that too soonish then 2014-04-10 11:36:21 i'm trying to get my libvirt up and run 2014-04-10 11:36:50 nice :) 2014-04-10 11:37:25 StarWarsFan: can you try strace or something to find out why it fails to start? 2014-04-10 11:37:58 sure, if you give me details how what to do 2014-04-10 11:38:13 check logs 2014-04-10 11:38:17 check dmesg 2014-04-10 11:38:46 try start rpc.statd from command line with debug to stdout/stderr 2014-04-10 11:38:53 (look in the init.d script how its started) 2014-04-10 11:38:58 ok 2014-04-10 11:39:31 if that doesnt help try run it from cmdline with strace 2014-04-10 11:39:42 http://sprunge.us/baIM 2014-04-10 11:39:46 that's dmsg 2014-04-10 11:40:11 ha 2014-04-10 11:40:13 segfaults 2014-04-10 11:40:27 [ 6.626119] rpcbind[1232]: segfault at a52655b0 ip 000072d3a5256317 sp 00007460238032b8 error 4 in ld-musl-x86_64.so.1[72d3a520a000+82000] 2014-04-10 11:41:11 the kernel warnings before that is interesting too 2014-04-10 11:41:24 the kernel stuff yes 2014-04-10 11:43:04 nothing to see on /var/log/messages 2014-04-10 11:44:36 here the last 100 lines from /var/log/kern.log 2014-04-10 11:44:37 http://sprunge.us/WYCd 2014-04-10 14:45:36 ncopa, msg ok on stable "build/build-2-7-x86_64 building linux-virt-grsec" 2014-04-10 14:46:22 missing on edge 2014-04-10 14:58:19 ok, remind me tm about that 2014-04-10 14:58:25 thsoe msgs are low prio 2014-04-10 15:01:37 ok 2014-04-10 18:03:12 kaniini, seems like openssl has nasty bug if freelists are off, http://marc.info/?l=openssl-dev&m=139715003729180&w=2 2014-04-10 18:04:28 openssl, like russian roulette with 6 bullets loaded 2014-04-10 18:04:50 fabled: i am hereby proposing that openssl is *intentionally* this bad 2014-04-10 18:07:06 yeah, a bunch load of dung 2014-04-10 18:11:35 seems the blog post is this: http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse 2014-04-10 18:13:16 the patch seems kosher 2014-04-10 18:13:34 but i mean, we're basically toying with software which is most likely intentionally awful 2014-04-10 18:14:56 i mean, if i were working for the NSA or GCHQ or whatever the german one is 2014-04-10 18:14:59 i'd be like 2014-04-10 18:15:12 "man, openssl has billions of installs, how can we screw that up even more" 2014-04-10 18:15:53 i mean, it's the best code quality for them to attack in that way 2014-04-10 18:15:56 you can't read it 2014-04-10 18:16:33 supposed the patch in http://rt.openssl.org/Ticket/Display.html?id=2167&user=guest&pass=guest is better 2014-04-10 18:18:12 yeah, the idea seems more sound 2014-04-10 18:30:43 lol. http://marc.info/?l=openssl-dev&m=139715446330891&w=2 2014-04-10 18:31:25 though 2014-04-10 18:31:36 i suppose they don't return -1 unless you have wacky default engine 2014-04-11 06:47:09 i want make bootable iso images today 2014-04-11 06:47:25 we should probably add a config option to opt out iso buildling on the build servers 2014-04-11 06:47:35 so we can have arm builders not building iso 2014-04-11 06:48:02 right 2014-04-11 06:48:10 mmm. looks firefox is not building on arm 2014-04-11 06:58:14 http://sprunge.us/cCdD 2014-04-11 06:58:57 i wonder if its that fno-stack-check 2014-04-11 06:59:34 was fixed in dec 26 2014-04-11 07:00:04 but i wonder if we need rebuild things to get relro? 2014-04-11 07:17:28 i am rebuilding parts of x86 2014-04-11 07:17:51 if there are more x86 breakages please let me know and i'll prioritize those 2014-04-11 07:25:55 nl.a.o firewall reboot 2014-04-11 07:42:02 re 2014-04-11 07:42:03 moinmoin 2014-04-11 07:42:13 ncopa: any news regarding the nfs-problem? 2014-04-11 07:46:03 StarWarsFan: no, I havent been able to look at it, sorry 2014-04-11 07:46:20 but we should try fix it soonish 2014-04-11 07:46:35 fabled: any ideas about that nfs issue? 2014-04-11 07:48:54 regarding nfs, its also broken on arm. 2014-04-11 07:53:43 that could be due to arm is musl too 2014-04-11 07:59:50 yes arm musl nfs is a nogo 2014-04-11 08:23:11 ncopa: can we update lxc in 2.7? 2014-04-11 08:24:43 and preferable btrfs also 2014-04-11 08:27:47 hmm maybe better to wait till v3, ill keep using edge-uclibc 2014-04-11 08:37:13 algitbot: build 2.6-stable 2014-04-11 08:44:15 clandmeter: i'm ok adding lxc-1.0 to v2.7/backports 2014-04-11 08:49:08 anyon objects to remove vserver? 2014-04-11 08:50:36 not really 2014-04-11 08:50:42 some infra still using it though 2014-04-11 08:51:03 can continue use it as long v2.7 is supported 2014-04-11 08:51:19 so we have a year and a half to think about migrate to lxc 2014-04-11 08:51:25 need to reserve some time to migrage to lxc 2014-04-11 08:51:34 migrate 2014-04-11 08:51:39 i migrated build.a.o to lxc 2014-04-11 08:51:45 it was fairly easy 2014-04-11 08:52:00 maybe i want to cancel that box and move to the new one. 2014-04-11 08:52:09 not sure het. 2014-04-11 08:52:10 yet 2014-04-11 08:52:36 lxc-create -n thehost -t alpine -- --release v2.7 2014-04-11 08:53:05 rsync vserverhost:/vservers/thehost/* /var/lib/lxc/thehost/rootfs/ 2014-04-11 08:53:18 fix network config 2014-04-11 08:53:22 and that its more or less 2014-04-11 09:00:12 ncopa: then please update lxc and if possible btrfs-utils in 2.7 2014-04-11 10:55:58 Hello guys 2014-04-11 10:56:25 please tell me, what is the last version of Alpine linux based on UClibc ? 2014-04-11 10:57:06 ah, I see, it should be Alpine 2.7.5 released 2014-04-11 11:03:02 zhivatma, yes, currently all releases are uclibc based 2014-04-11 11:03:09 the musl stuff will be 3.x.y 2014-04-11 11:05:06 fabled, thank you 2014-04-11 11:51:11 ncopa: feel free to set go arch to x86_64 only. I can bring up a x86 container and check the breakage next week 2014-04-11 11:52:00 ok 2014-04-11 11:52:00 ncopa: docker is forcred to x86_64 only by upstream 2014-04-11 12:36:41 i have x86 box 2014-04-11 12:36:48 and it would be nice with x86 2014-04-11 12:36:53 but i dont have time atm 2014-04-11 12:37:12 im not sure google support x86 go anyways... 2014-04-11 12:37:35 i suppose you need to be nuts to run docker on x86 :) 2014-04-11 12:44:39 Guys... Maybe we'll have a chance to publish an article on Hack Insight Magazine... We need a volunteer to write a good article about Alpine Linux + PaX/grsec/musl 2014-04-11 12:53:58 nice! 2014-04-11 12:54:16 i wont be able to sorry :-( 2014-04-11 13:00:53 ncopa, go on x86 is broke for real life use. the GC does not do 32-bits right. 2014-04-11 13:00:57 the last i checked 2014-04-11 13:04:09 ok 2014-04-11 13:04:11 makes sense 2014-04-11 13:10:59 fabled: I think the story of go on x86 is better with 1.2 2014-04-11 13:11:25 fabled: 1.3 will get a more precise gc which should help: http://code.google.com/p/go/issues/detail?id=909 2014-04-11 13:13:14 clandmeter: how do i change the frontpage in drupal? 2014-04-11 13:13:39 i'd like to clarify that we are currently an uClibc distro but soon musl libc 2014-04-11 13:14:07 uggedal, oh, cool, good to know. i stopped following that bug a year ago since nothing was happening... 2014-04-11 14:03:02 upgrading from 2.7 (stable) to edge doesn't work 2014-04-11 14:03:13 ERROR: unsatisfiable constraints: 2014-04-11 14:03:13 scanelf (missing): 2014-04-11 14:03:13 required by: lddtree-1.25-r1[scanelf] 2014-04-11 14:03:25 step: install new v2.7 2014-04-11 14:03:34 modify repository to edge 2014-04-11 14:03:42 apk update 2014-04-11 14:03:53 apk add -U apk-tools-static busybox-static 2014-04-11 14:03:59 a 2014-04-11 14:03:59 pk.static upgrade --no-self-upgrade -U -a --simulate 2014-04-11 14:04:12 returns the scanelf missing error 2014-04-11 14:05:14 fcolista, which arch? 2014-04-11 14:05:18 x86 2014-04-11 14:05:32 i think x86 is being rebuilt now, and might be missing packages 2014-04-11 14:05:49 ok 2014-04-11 14:05:50 mmm 2014-04-11 14:05:51 no 2014-04-11 14:05:58 of yes 2014-04-11 14:06:01 scanelf is gone 2014-04-11 14:06:02 actually scanelf doesn't exists 2014-04-11 14:06:03 ncopa, ^^^ 2014-04-11 14:06:15 is a dependency of world 2014-04-11 14:06:28 scanelf (missing): 2014-04-11 14:06:28 required by: world[scanelf] 2014-04-11 14:06:41 oh 2014-04-11 14:07:06 it should exist 2014-04-11 14:07:09 should be part of busybox, isn't it? 2014-04-11 14:07:10 build must've failed 2014-04-11 14:07:19 yep 2014-04-11 14:07:23 or it's deleted intentionally and being rebuilt 2014-04-11 14:08:28 is no part of bb 2014-04-11 14:09:53 fcolista, yeah. we nuked musl/x86 packages since they all need rebuild 2014-04-11 14:10:01 and seems it got partially synced out 2014-04-11 14:10:05 k 2014-04-11 14:10:13 the builder is rebuilding *everything*. can take a day or two 2014-04-11 14:10:35 seems scanelf is not built yet 2014-04-11 14:11:02 ok, just scared about a bug 2014-04-11 14:11:11 it's only matter to wait 2014-04-11 14:11:35 until that moment, is better to not give the news uclibc > musl switch publicly 2014-04-11 14:11:44 true 2014-04-11 14:11:48 many machines are still x86 2014-04-11 14:11:55 we realized the rebuild need only today 2014-04-11 14:12:06 is not a problem 2014-04-11 14:12:08 x86-64 we rebuilt in similar manner a week ago 2014-04-11 14:12:16 'cause it is announce "only" in our ML 2014-04-11 14:12:23 just wondering of something more official 2014-04-11 14:12:24 we have the post on www.a.o 2014-04-11 14:12:29 exactly 2014-04-11 14:12:36 do we already posted? 2014-04-11 14:12:46 yes 2014-04-11 14:12:47 http://alpinelinux.org/edge-musl 2014-04-11 14:12:51 is on front page 2014-04-11 14:12:54 i did on twitter and linkedIn 2014-04-11 14:13:10 olè :) 2014-04-11 14:13:23 pasting this link 2014-04-11 14:13:33 ok, what is done is done 2014-04-11 14:49:56 upgrade x64 went smoothly 2014-04-11 14:50:00 *to x64 2014-04-11 15:07:24 fcolista, x86 is building at build/build-edge-x86 835/1335 1167/1740 main/gnome-themes 2014-04-11 15:08:00 some 500pkgs still to go 2014-04-11 15:08:02 in main 2014-04-11 15:08:27 wow 2014-04-11 15:08:59 do we have a listo of pkgs that won't build with musl ' 2014-04-11 15:09:00 ? 2014-04-11 15:09:09 I've seen it somewhere 2014-04-11 15:09:13 don't remember where 2014-04-11 15:09:14 we had pastes of it 2014-04-11 15:09:28 i think it was sprunged here few times 2014-04-11 15:09:37 no official / automated thing for it 2014-04-11 15:09:45 oh - maybe on mailing list it was mentioned 2014-04-11 15:10:15 ok i'll take a look 2014-04-11 15:10:42 fcolista, http://lists.alpinelinux.org/alpine-devel/3614.html 2014-04-11 15:10:51 i think some have been fixed since 2014-04-11 15:11:36 thx a lot 2014-04-11 16:01:38 hi 2014-04-11 21:13:00 n8@all 2014-04-12 19:24:27 ncopa, kaniini, fabled: http://thread.gmane.org/gmane.comp.encryption.openssl.user/51243 2014-04-13 02:21:28 barthalion: NAK 2014-04-13 02:21:55 barthalion: the entire thing is botched, adding features to make people feel warm and fuzzy about some things does not correct the issue that the entire thing is botched 2014-04-13 02:22:42 barthalion: the only way in my opinion to fix openssl, is to take a list of the apis, study them, and then reimplement them in a clean room, under a license like ISC instead of that fucked up openssl license 2014-04-13 05:46:02 ncopa: is there a reason that the storage and sound directories aren't set in the freeswitch init file by default? 2014-04-13 06:00:15 iirc, fabled has more to do with maintaining that package 2014-04-13 06:04:11 kaniini: hmm k was just going off the APKBUILD 2014-04-13 06:05:52 either way sounds like a bug you should file one or sth 2014-04-13 06:06:46 yea def is, without them set in the init file voicemail won't work without editing the conf.d to append them 2014-04-13 06:07:12 because it tries to default to /usr/storage and /usr/sounds 2014-04-13 11:36:10 please git pull git://git.alpinelinux.org/fab/aports 2014-04-13 11:36:17 there are updates 2014-04-13 15:05:11 fabian_a, what's the "initial commit" junk commits about? 2014-04-13 15:06:10 there's few commits with whitespace damage too 2014-04-13 15:07:34 fixing license on py-sphinxcontrib-git but no pkgrel bump? 2014-04-13 15:08:01 otherwise looks good 2014-04-13 15:08:05 fabled: can you skip that please? it's a leftover from repo initialization because my old one was a bit messy 2014-04-13 15:08:34 i'll need to then cherry pick the commits, i think 2014-04-13 15:08:49 py-sphinxcontrib-git is a new aport was never built 2014-04-13 15:09:24 so why two commits, the one commit should be fixed 2014-04-13 15:10:32 right 2014-04-13 15:10:53 could you fix those, or should i cherry pick the good looking ones? 2014-04-13 15:11:55 fabled: hm, by the way, how do you cherry pick commits from a not merged remote? 2014-04-13 15:12:18 barthalion, pull to local branch. switch back to master, and cherry-pick works. 2014-04-13 15:12:45 thanks, will try 2014-04-13 15:13:28 for anyone interested i pushed edge and 2.7 trusted builds of alpine to the docker index: https://index.docker.io/u/uggedal/ 2014-04-13 15:26:16 fabled: can you please cherry-pick the commit. it seems that i'm not able squash the commits right now 2014-04-13 15:26:47 fabian_a, ok, i'll look into it in few minutes time 2014-04-13 19:52:47 fabian_a, fixed few commits, and pushed. thanks. 2014-04-14 00:40:58 can perl-git be added to musl-edge please (so git-email is installable) 2014-04-14 06:13:28 morning 2014-04-14 06:33:41 Moinmoin 2014-04-14 07:34:47 working on musl update 2014-04-14 07:54:26 ncopa: anything holding back a fresh edge iso? 2014-04-14 07:55:01 clandmeter, i think we still need to fix the iso creation scripts; though for x86 and x86_64 they should work as-is 2014-04-14 07:55:06 but no armhf image generation yet 2014-04-14 07:55:38 fabled: i saw multiple ppl request it. maybe we could please them :) 2014-04-14 07:55:39 what holding back is that i need to make it possible to configure if the iso should be autogenerated or not 2014-04-14 07:55:47 so we can config arm to not yet generate iso 2014-04-14 07:56:50 but yes, we really should create new images asap 2014-04-14 08:24:04 we should also do v2.7.6 now 2014-04-14 08:26:18 yeah, that'd be good too 2014-04-14 08:26:30 should i tag new apk-tools still? 2014-04-14 08:26:57 yeah, maybe 2014-04-14 08:27:04 ok 2014-04-14 08:27:10 need to upgrade apk in 2.7-stable too 2014-04-14 08:27:12 seems it's still old 2014-04-14 08:41:12 ncopa fabled: how do we manage pkgname-gdb packages when the source already strips the symbols? 2014-04-14 08:51:49 we make the source not strip things 2014-04-14 09:26:18 ncopa: please let me know if you need further details regarding the nfs-problem, if you need some testing or if i should file a bug on the bugtracker... 2014-04-14 09:30:47 yeah, maybe file it on bug tracker 2014-04-14 09:30:54 i will neable -dbg build for it 2014-04-14 09:31:03 so you can apk add nfs-utils-gdb 2014-04-14 09:31:15 and provide a gdb backtrace or similar 2014-04-14 15:27:07 ok, opened http://bugs.alpinelinux.org/issues/2842 2014-04-14 21:29:52 ncopa there is an issue creating lxc on i486 hardware. From log 'xc-start 1397509590.814 WARN lxc_confile - unsupported personality 'i586'' . When i change the lxc.arch = i586 inside 'config' file to x86, guest can be started and kernel is "Linux edgemusl 3.10.36-0-grsec #1-Alpine SMP Wed Apr 9 11:40:01 UTC 2014 i586 Linux" 2014-04-15 06:00:56 i'm trying to fix xbmc, and the code is utter garbage 2014-04-15 06:19:13 just realizing that fixing compilation problem with musl is harder than uclibc 2014-04-15 06:19:45 fcolista, depends on the application 2014-04-15 06:20:03 fcolista, but sometimes the applications do really horrendous things assuming lot of glibc internals 2014-04-15 06:20:07 those will break hard 2014-04-15 06:20:08 well, the easiest apps were fixed already 2014-04-15 06:20:14 generally speaking, you can find uclibc patch with openwrt and other places 2014-04-15 06:20:33 xmbc is braindamaged 2014-04-15 06:20:35 with musl you should do by yourself 2014-04-15 06:20:37 it's misusing FILE struct 2014-04-15 06:20:48 and a lot of other nastyness too 2014-04-15 06:21:08 I'm just trying to fix iputils 2014-04-15 06:21:38 and 'til now i had to change include files path 2014-04-15 06:21:58 and includes some include :) 2014-04-15 06:31:55 ncopa, i think depends=!uclibc-dev would have better than replaces 2014-04-15 06:32:17 oh 2014-04-15 06:32:18 true 2014-04-15 06:33:13 how sould htat handle the migration from uclibc? 2014-04-15 06:33:43 i upgraded my old edge x86_64 box 2014-04-15 06:33:56 and it compilaed about files beeing owned by uclibc-dev 2014-04-15 06:42:40 ncopa, i think it should force delete you dependencies that prevent uclibc from being removed 2014-04-15 06:42:57 and it also makes sure uclibc-dev is deleted first 2014-04-15 06:43:00 so no conflict should occur 2014-04-15 06:49:36 fcolista: sabotage linux has patches for musl for some packages 2014-04-15 06:52:23 fcolista, also gregor's gcc-musl has some patches 2014-04-15 06:53:02 libvirt is still buggy 2014-04-15 06:53:08 reports to little memory 2014-04-15 06:53:27 the uclibc-physmem.patch needs be ported 2014-04-15 06:53:38 andi have some other libvirt cleanups 2014-04-15 06:53:44 xbmc is doing some really nasty things 2014-04-15 06:53:56 it seems they have a weird emulation layer to load windows dlls in linux 2014-04-15 06:53:59 maybe should spank them 2014-04-15 06:54:09 and that emulation layer is doing lot of nastyness 2014-04-15 06:54:50 ncopa: trying to look at the go x86 failure, but alpine-sdk seems to be missing from edge 2014-04-15 06:55:21 go added x86 support? 2014-04-15 06:55:27 i'll check up alpine-sdk 2014-04-15 06:56:25 ncopa: go has x86 and arm support 2014-04-15 06:56:31 you may be thinking of docker 2014-04-15 06:56:50 which can be made to run on both, but are not supported by upstream 2014-04-15 06:57:06 no, i just heard that go earlier had bad or no x86 2014-04-15 06:57:17 ncopa: nevermind, all the depends of alpine-sdk are there 2014-04-15 06:57:34 but alpine-sdk itself is missing? 2014-04-15 06:57:37 fully possible... 2014-04-15 06:57:46 ncopa: ah that, yes historically you could expect suboptimal performance and some memory leaks on x86 2014-04-15 06:58:07 but the situation has gotten better and better still in the upcoming 1.3 release 2014-04-15 06:58:21 ok, good 2014-04-15 06:58:35 alpine-edge-x86:~# apk add alpine-sdk 2014-04-15 06:58:35 yes, looks like alpine-sdk and aports-build are missing in x86 2014-04-15 06:58:36 ERROR: unsatisfiable constraints: 2014-04-15 06:58:46 they probbably got lots in last rebuild i tried 2014-04-15 07:00:20 hm... 2014-04-15 07:03:13 fabled: do you reember the mqtt message stdout flush problem? 2014-04-15 07:03:21 ncopa, yes? 2014-04-15 07:03:30 i asked, making stdout fully cached is intentional 2014-04-15 07:03:41 i made buildrepo do io.stdout:flush() 2014-04-15 07:03:45 ok? 2014-04-15 07:03:50 that seems to be the problem 2014-04-15 07:03:56 i think it works now 2014-04-15 07:03:56 flush should fix it 2014-04-15 07:03:58 ok 2014-04-15 07:03:59 good 2014-04-15 07:04:22 we should still add support for lua-mosquitto there i think 2014-04-15 07:09:19 ncopa: ncopa go builds in my x86 lxc container and a simple hello-world.go program runs 2014-04-15 07:09:32 hm 2014-04-15 07:09:39 i think alpine-sdk should be there now 2014-04-15 07:10:03 /usr/bin/go: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped 2014-04-15 07:10:23 # os/user 2014-04-15 07:10:24 pkg/os/user/lookup.go:9: undefined: current 2014-04-15 07:10:24 pkg/os/user/lookup.go:15: undefined: lookup 2014-04-15 07:10:24 pkg/os/user/lookup.go:9: not enough arguments to return 2014-04-15 07:10:24 pkg/os/user/lookup.go:15: not enough arguments to return 2014-04-15 07:10:24 pkg/os/user/lookup.go:21: undefined: lookupId 2014-04-15 07:10:26 pkg/os/user/lookup.go:21: not enough arguments to return 2014-04-15 07:10:28 # net 2014-04-15 07:10:30 pkg/net/lookup_unix.go:56: undefined: cgoLookupHost 2014-04-15 07:10:32 pkg/net/lookup_unix.go:64: undefined: cgoLookupIP 2014-04-15 07:10:34 pkg/net/lookup_unix.go:72: undefined: cgoLookupPort 2014-04-15 07:10:36 pkg/net/lookup_unix.go:80: undefined: cgoLookupCNAME 2014-04-15 07:10:38 >>> ERROR: go: all failed 2014-04-15 07:10:40 it looks like it fails on make check or similar 2014-04-15 07:14:49 strange. works for me on a freshly created x86 lxc container (running on a x86_64 host) 2014-04-15 07:14:57 which itself is running under xen 2014-04-15 07:15:19 only non standard thing I can think of is pax_nouderef in my kernel cmd line 2014-04-15 07:18:44 oh, that could be it 2014-04-15 07:18:56 we might need to pax mark binaries? 2014-04-15 07:21:36 yeah, would need to patch the go build script then since it uses the compiled binary to compile the stdlib 2014-04-15 07:22:10 let me try to boot without pax_nouderef to confirm 2014-04-15 07:32:09 ncopa: still builds for me with pax_nouderef removed from my cmdline 2014-04-15 07:37:38 weird 2014-04-15 07:41:30 and afaik hardened gentoo builds go fine without pax trickery 2014-04-15 07:42:13 interestin it build when I ran it from cmdline 2014-04-15 07:43:07 actually, the go linker does pax marking: https://codereview.appspot.com/6326054 2014-04-15 07:44:35 hten it could be that ccacahe does some trickery 2014-04-15 07:45:40 yup 2014-04-15 07:45:41 thats it 2014-04-15 07:45:53 i set CC=gcc and it works 2014-04-15 07:46:10 hum 2014-04-15 07:46:14 almost.... 2014-04-15 07:46:19 >>> go*: Tracing dependencies... 2014-04-15 07:46:19 >>> ERROR: go*: libc.so.6: path not found 2014-04-15 07:47:08 ET_EXEC libc.so.6 pkg/go/usr/lib/go/src/pkg/debug/dwarf/testdata/typedef.elf 2014-04-15 07:47:08 ET_EXEC libc.so.6 pkg/go/usr/lib/go/src/pkg/debug/elf/testdata/gcc-amd64-linux-exec 2014-04-15 07:47:08 ET_EXEC libc.so.6 pkg/go/usr/lib/go/src/pkg/debug/elf/testdata/gcc-386-freebsd-exec 2014-04-15 07:47:32 those are precompiled with libc.so.6 2014-04-15 07:47:34 glibc 2014-04-15 07:47:44 but um... 2014-04-15 07:47:52 it looks like 'testdata' 2014-04-15 07:48:15 i'd say we just ignore that for now 2014-04-15 07:49:04 yeah, saw those 2014-04-15 07:50:13 ncopa: there seems to be a problem with lxc on i486 (ie alix devices) 2014-04-15 07:50:22 debian patches them out (but only to comply with DFSG) 2014-04-15 07:52:46 ncopa: i guess its caused by the alpine template setting the wrong arch and wont boot. 2014-04-15 08:08:18 clandmeter yea like we saw yesterday it wont start with lxc.arch = i586 but with lxc.arch = x86 it do 2014-04-15 10:00:36 clandmeter: did you submit it to upstream lxc? 2014-04-15 10:00:50 yes check commit msg . 2014-04-15 10:00:57 ah 2014-04-15 10:00:57 good 2014-04-15 10:00:59 thanks! 2014-04-15 10:44:04 ncopa: I've tested go on x86{,_64} and docker. Can we move them to main? 2014-04-15 10:56:18 ncopa, seems x86 was blocked by polkit not building due to the parallel issue. it's building more stuff now 2014-04-15 11:06:17 uggedal: ok, I'll move them 2014-04-15 11:07:02 fabled: no objection wrt moving 'go' to main? 2014-04-15 11:07:36 no major ones 2014-04-15 11:07:53 ok i'll move it 2014-04-15 11:08:50 huh 2014-04-15 11:09:03 as-if abuild hung on edge-x86 2014-04-15 11:09:44 oh 2014-04-15 11:09:47 it was just slow 2014-04-15 11:09:53 oh 2014-04-15 11:09:56 the shared mime info stuff 2014-04-15 11:09:59 it's dog slow 2014-04-15 11:10:01 meh 2014-04-15 11:10:06 i thought i had fixed that 2014-04-15 11:10:14 but apparently things does not work as expected 2014-04-15 11:10:40 i wonder if i should just add a reverting patch for it 2014-04-15 11:11:12 well. i can say that it's getting annoyingly slow. 2014-04-15 11:11:34 fcolista: nice work with iputils 2014-04-15 11:11:39 thx ncopa 2014-04-15 11:11:50 i think the bug said there's a autoconf trick you can disabke the fdatasync or whatever it was calling 2014-04-15 11:11:55 i've the list of packages who don't compiles 2014-04-15 11:12:06 i think i got xbmc fixed 2014-04-15 11:12:06 just going trough all of these 2014-04-15 11:12:13 fabled: i thought i do that trick 2014-04-15 11:12:19 but it doesnt seem to work as expected 2014-04-15 11:12:40 could i i have misspelled anything 2014-04-15 11:12:47 xbmc was doing nasty stuff... so i posted http://forum.xbmc.org/showthread.php?tid=192355&pid=1682574#pid1682574 2014-04-15 11:12:48 but iirc i did check the output of configure script 2014-04-15 11:14:06 so probablyit's not working as expected 2014-04-15 11:14:57 ncopa, when should we fix the iso creation + write armhf image creationstuff 2014-04-15 11:51:42 fabled, i've finished porting all RTO VPNc stuff from SVN -> GIT 2014-04-15 12:06:57 I am giving git push access to uggedal 2014-04-15 12:12:48 uggedal: you might want subscribe to alpine-devel@lists.alpinelinux.org too if you are not already 2014-04-15 12:12:54 its fairly low traffic 2014-04-15 12:13:00 most happens here in IRC 2014-04-15 12:13:28 ncopa: thanks. I'm already subscribed 2014-04-15 12:14:36 say welcome to our new git pusher: uggedal 2014-04-15 12:14:46 uggedal: thanks for helping us. 2014-04-15 12:14:54 and welcome :) 2014-04-15 12:21:00 np :) and thanks again for the access 2014-04-15 12:22:15 ncopa: could you cherrypick my lxc commit to 2.7? 2014-04-15 12:22:30 i'm not sure its affected? 2014-04-15 12:23:46 why wouldnt it? 2014-04-15 12:24:19 its inside the alpine tempalte 2014-04-15 12:24:23 template 2014-04-15 12:25:16 oh 2014-04-15 12:25:37 does x86 work as arch on lxc 0.9? 2014-04-15 12:26:20 i think crow was using 2.7 2014-04-15 12:27:00 i think you were going to upgrade 2.7 to 1.0.x? 2014-04-15 12:29:50 no, but we could add 1.0 to v2.7/backports 2014-04-15 12:30:54 since when do we have that? 2014-04-15 12:31:10 im sleeping under a rock :) 2014-04-15 12:32:29 ncopa: from what i read only i686 is a valid arch out of i*86. 2014-04-15 12:36:00 we added v2.7/backports mainly because 3.0 will be musl, so instead of making both v2.8 and v3.0, we add stuff to v2.7 2014-04-15 12:36:18 will look at the lxc arch thingy later 2014-04-15 12:36:26 ncopa: has backporting been announces anywhere? 2014-04-15 12:41:44 no. we just did it :) 2014-04-15 12:41:53 nice 2014-04-15 12:41:53 there was only one app initialy, zabbix iirc 2014-04-15 12:42:00 how does it work? 2014-04-15 12:42:06 it works like this 2014-04-15 12:42:29 you have an app that you are interested in, that has a new release 2014-04-15 12:42:33 new major release 2014-04-15 12:42:40 for example zabbix 2.2 or so 2014-04-15 12:42:47 but current stable has older 2014-04-15 12:43:14 if the need for the newer version is big enough, we can add it to v2.7/backports 2014-04-15 12:43:22 so you can choose which you want 2014-04-15 12:43:29 but how do you add it to git? 2014-04-15 12:43:35 i mean what makes it diffrerent? 2014-04-15 12:43:48 copy files to aports/backports// 2014-04-15 12:43:51 git add ... etc 2014-04-15 12:44:19 the point is that when you run a stable branch, you should be able to do apk upgrade, without needing change any config 2014-04-15 12:44:20 ah now i see 2014-04-15 12:44:30 switch branch and commit in backports 2014-04-15 12:44:39 yes 2014-04-15 12:44:51 so if you already use lxc from v2.7 2014-04-15 12:45:05 you should not need to change config when doing apk upgrade 2014-04-15 12:45:12 you should be able to do apk upgrade without anything breaking 2014-04-15 12:45:25 thats why we cannot just upgrade v2.7/main/lxc to 1.0 2014-04-15 12:45:33 because it wlil break things for stable users 2014-04-15 12:45:34 yeah, adding it as a pinned repo makes sence 2014-04-15 12:46:03 and pinning edge repo is generally a bad idea... 2014-04-15 12:46:11 yep 2014-04-15 12:46:16 for sure now :) 2014-04-15 12:46:16 specially now that we did the musl jump 2014-04-15 12:46:30 so that was the motivator for v2.7/packports repo 2014-04-15 12:58:49 looks that fix coova-chilli is not that easy. 2014-04-15 12:58:50 http://blog.gmane.org/gmane.linux.lib.musl.general/month=20131101 2014-04-15 12:59:02 That's the same error i got: /usr/include/netinet/if_ether.h:94:8: error: redefinition of 'struct ethhdr' 2014-04-15 13:00:46 we have a hack for that 2014-04-15 13:01:14 i wonder that this is not the only package with this kind of error.. 2014-04-15 13:01:16 make sure #include comes after #include <*.h> and 2014-04-15 13:01:24 lots have had them 2014-04-15 13:01:32 the problem is when you mix libc headers with linux/*.h 2014-04-15 13:01:48 we have added a workaround in our linux-headers package 2014-04-15 13:02:21 but for it to actually the musl headers needs to be included first 2014-04-15 13:02:52 ok so this can't be fixed in upstream. I've to create a patch for that 2014-04-15 13:45:57 openvswitch depends on libatomic.so.1 which is provied by gcc 2014-04-15 13:46:06 so gcc is pulled in as runtime dep for openvswitch 2014-04-15 13:46:21 maybe we should ship libatomic in a subpackage? 2014-04-15 13:48:30 what about making gcc-libs? 2014-04-15 13:54:58 seems like it does not happen on musl 2014-04-15 13:55:07 no point spending time on trying to fix uclibc 2014-04-15 13:57:01 oh 2014-04-15 13:57:07 it does affect x86 musl 2014-04-15 13:57:13 # automatically detected: 2014-04-15 13:57:13 depend = so:libatomic.so.1 2014-04-15 13:57:26 BitL0G1c: would you mind create an issue for that on bugs.a.o? 2014-04-15 13:58:18 ok 2014-04-15 15:35:28 hm, 2014-04-15 15:35:39 after apk update && apk upgrade on the host 2014-04-15 15:35:49 i can't login to the lxc containers 2014-04-15 15:36:09 both systems edge, host and container 2014-04-15 15:36:44 root@builder06:~ lxc-console -n alpine_edge_x86 2014-04-15 15:36:44 Connected to tty 1 2014-04-15 15:36:44 Type to exit the console, to enter Ctrl+a itself 2014-04-15 15:36:44 Welcome to Alpine Linux 3 2014-04-15 15:36:45 Kernel 3.10.23-0-grsec on an i686 (/dev/tty1) 2014-04-15 15:36:47 alpine_edge_x86 login: root 2014-04-15 15:36:50 Welcome to Alpine! 2014-04-15 15:36:52 The Alpine Wiki contains a large amount of how-to guides and general 2014-04-15 15:36:54 information about administrating Alpine systems. 2014-04-15 15:36:56 See . 2014-04-15 15:36:58 You may change this message by editing /etc/motd. 2014-04-15 15:37:01 Error relocating /usr/lib/libncurses.so.5: __fputc_unlocked: symbol not found 2014-04-15 15:37:03 Error relocating /usr/lib/libncurses.so.5: __ctype_b: symbol not found 2014-04-15 15:37:05 Welcome to Alpine Linux 3 2014-04-15 15:37:07 Kernel 3.10.23-0-grsec on an i686 (/dev/tty1) 2014-04-15 15:37:09 alpine_edge_x86 login: 2014-04-15 15:42:59 StarWarsFan, seems not all packages were updated 2014-04-15 15:44:31 there was a problem with uclibc-utils during the update 2014-04-15 15:44:33 so i did 2014-04-15 15:44:36 apk del uclibc-utils 2014-04-15 15:44:38 apk fix 2014-04-15 15:54:07 todays build numbers: 2014-04-15 15:54:09 main testing 2014-04-15 15:54:09 musl-x86: 1707/1741 901/1127 2014-04-15 15:54:09 musl-x86_64: 1709/1740 884/1114 2014-04-15 15:54:09 musl-armhf: 1681/1733 880/1113 2014-04-15 15:54:35 fabled: that's what builds successfully? 2014-04-15 15:54:55 / 2014-04-16 06:30:48 morning 2014-04-16 06:31:16 morning 2014-04-16 06:31:42 is testing only for ports which are untested or needs some cleanup etc? 2014-04-16 06:32:06 both 2014-04-16 06:32:11 what normally happens is 2014-04-16 06:32:15 someone asks for a package 2014-04-16 06:32:18 so, if I deem a port stable it should always go to main? or are less used ports left in testing to not make main grow huge? 2014-04-16 06:32:36 i or someone builds the pkg 2014-04-16 06:32:42 but we dont test it 2014-04-16 06:32:51 i see 2014-04-16 06:32:54 so we push it to testing so others can test 2014-04-16 06:32:58 and give feedback 2014-04-16 06:33:15 but as you see, the feedback is not always as good as hoped :) 2014-04-16 06:33:33 before moving to main, i like to verify that init.d script is good enough 2014-04-16 06:33:50 sometimes we push things without init.d script too, to testing 2014-04-16 06:34:17 pushing to testing first only verifies that the build server builds it correctly too 2014-04-16 06:34:27 yeah, I was a bit surprised by the large number of packages in testing and thought maybe I had missing some sort of policy other than stability and correctness for entering main 2014-04-16 06:35:02 i think many packages in testing are abandoned 2014-04-16 06:35:11 yeah, I see the value of pushing to testing first 2014-04-16 06:35:11 someone contributed 2014-04-16 06:35:20 but nobody maintains 2014-04-16 06:35:54 but we dont have any policy that says that it needs to stay in testing for X days/months before move to main 2014-04-16 06:36:48 if someone has tested that the package built from build server works and no more work needs to be done (fix init.d scripts etc) 2014-04-16 06:36:57 and someone is listed as maintainer 2014-04-16 06:37:02 then its just to move it to main 2014-04-16 06:38:04 i am open for improvements 2014-04-16 06:38:16 the number of packages in main is pretty big now 2014-04-16 06:38:41 we might need to do what arch does, with a core repo and an AUR repo or similar 2014-04-16 06:40:36 fabled: any objection to split out libatomic as subpackage from gcc? 2014-04-16 06:47:05 hmm, ruby broke overnight without an update: Error relocating /usr/lib/libruby.so.2.0: __syscall: symbol not found 2014-04-16 06:48:00 ncopa-desktop:~$ ruby 2014-04-16 06:48:00 Error relocating /usr/lib/libruby.so.2.0: __syscall: symbol not found 2014-04-16 06:48:04 hm 2014-04-16 06:48:31 could it be the recent musl cherry-picks? 2014-04-16 06:48:34 maybe we had a __syscall symbol before in musl, that got removed? 2014-04-16 06:50:02 __attribute__((visibility("protected"))) was changed to __attribute__((visibility("hidden"))) 2014-04-16 06:50:21 on __syscall(syscall_arg_t, ...) 2014-04-16 06:50:43 when? 2014-04-16 06:50:50 http://git.alpinelinux.org/cgit/aports/commit/?id=224118a61689b5c5b0ccf4588a74b6a47611f040 2014-04-16 06:51:51 hm 2014-04-16 06:52:01 i wonder what upstream commit introduced that 2014-04-16 06:52:27 http://git.musl-libc.org/cgit/musl/commit/src/internal/syscall.h?id=83c98aac4c43f9571e8f92a1c795afe02c237d4b 2014-04-16 06:53:08 sigh 2014-04-16 06:53:12 yes 2014-04-16 06:53:18 it sounds like rich if right 2014-04-16 06:56:35 seems there is a configure check for __syscall in ruby, trying to rebuilding it now 2014-04-16 06:57:40 same here 2014-04-16 06:57:49 hmm i think that's a bug in ruby 2014-04-16 06:57:50 __syscall is not a public symbol and is not declared in any header 2014-04-16 07:02:45 should we update to 2.1? 2014-04-16 07:02:56 ruby still builds ok 2014-04-16 07:03:21 i suppose ruby-2.1 woudl be nice 2014-04-16 07:03:56 but i still get an error 2014-04-16 07:04:31 will redmine work with ruby-2.1? 2014-04-16 07:04:42 rebuild worked for me 2014-04-16 07:04:52 http://www.redmine.org/issues/16194 2014-04-16 07:05:01 everything listed is closed or merged 2014-04-16 07:05:16 good 2014-04-16 07:05:20 but seems nobody updated the redmine bug 2014-04-16 07:05:40 should i push a revbump? 2014-04-16 07:05:47 speaking of redmine, i *really* want that feature for support multiple branches in tickets 2014-04-16 07:05:51 uggedal: yes, i think so 2014-04-16 07:05:52 thanks 2014-04-16 07:06:46 ncopa: start coding ;-) 2014-04-16 07:07:15 clandmeter: there was a redmine ticket with a patch for it 2014-04-16 07:07:30 yeah a very old one right? 2014-04-16 07:07:35 yes 2014-04-16 07:09:48 uggedal: you are not only good at finding/fixing things. you're also a talent in writing good commit messages :) 2014-04-16 07:10:58 rebuild seems to work 2014-04-16 07:11:02 ncopa: heh, thanks 2014-04-16 07:11:04 i didnt bump pkgrel :) 2014-04-16 07:12:12 its 2 bugs 2014-04-16 07:12:26 ruby shouldnt AC_CHECK_FUNC(__syscall) ... 2014-04-16 07:13:04 and autoconf shouldnt detct __syscall when its not declared 2014-04-16 07:13:10 http://ewontfix.com/13/ 2014-04-16 07:15:37 yup that fixed it 2014-04-16 07:22:03 seems like that ruby __syscall business was really bad 2014-04-16 07:22:26 i tried to have a look at io.c but gave up... 2014-04-16 07:22:30 the __syscall in musl doesnt returns what ruby thinks it returns 2014-04-16 07:22:42 dalias had an analyze of it 2014-04-16 07:22:44 in #musl 2014-04-16 07:22:53 i'm glad we caught it 2014-04-16 07:23:02 basically ruby expects -1 on error 2014-04-16 07:23:08 but musl return -errno 2014-04-16 07:23:27 so ruby wouldnt detect all errors 2014-04-16 07:24:19 and indeed: 2014-04-16 07:24:19 if (retval == -1) 2014-04-16 07:24:19 rb_sys_fail(0); 2014-04-16 07:24:19 so by returning -errcode rather than -1, rb_sys_fail was not getting called 2014-04-16 07:24:19 this was probably bad :) 2014-04-16 07:25:49 nice ruby 2.1.1 is musl proof 2014-04-16 07:26:11 ncopa: should i push it? 2014-04-16 07:28:15 yeah, i'd say so 2014-04-16 07:28:21 might need rebuild ruby-* 2014-04-16 07:28:33 we could probably upgrade those too 2014-04-16 07:28:45 ruby-* packages scares me to death... 2014-04-16 07:29:13 :D 2014-04-16 07:31:54 we should take new Qt from testing too 2014-04-16 07:33:45 true 2014-04-16 07:37:50 ok 2014-04-16 07:38:00 i think i will make iso snapshot for edge now 2014-04-16 07:38:19 ncopa, did you fix the armhf to not try to create isos? 2014-04-16 07:39:25 i think so 2014-04-16 07:39:27 ncopa, before tagging next 2.7-stable, i'd like to upgrade awall / cherry-pick some fixes to it 2014-04-16 07:39:53 you'll have to either do it or file bugs or i'll forget 2014-04-16 07:40:05 i think i need to do new kernel for v2.4 too 2014-04-16 07:42:04 moin 2014-04-16 07:46:00 fabled: i'm splitting out libatomic, #2844 2014-04-16 07:46:45 my edge dev box was broken due tu CHOST was still uclibc in /etc/abuild.conf 2014-04-16 07:53:26 ncopa, yes, libatomic split sounds good. and since it's pulled in by soname, i think the patch as-is is good. no need for rebuilds. 2014-04-16 07:53:29 though 2014-04-16 07:53:33 it might need replaces 2014-04-16 07:54:05 i think libatomic needs replaces gcc (or where ever the .so used to be) 2014-04-16 07:59:59 true 2014-04-16 08:16:52 ok i think its time to tag edge snapshot? 2014-04-16 08:17:04 gcc is done 2014-04-16 08:17:25 v131211-1665-g7b1de29 2014-04-16 08:17:30 1665 commits... 2014-04-16 08:21:00 hm 2014-04-16 08:21:05 no release built.. 2014-04-16 08:21:15 please hold your git pushes for a sec 2014-04-16 08:21:35 any ideas to the problem from yesterday evening? 2014-04-16 08:21:38 Error relocating /usr/lib/libncurses.so.5: __fputc_unlocked: symbol not found 2014-04-16 08:21:38 Error relocating /usr/lib/libncurses.so.5: __ctype_b: symbol not found 2014-04-16 08:22:11 sounds like you have some libs using uclibc and some using musl 2014-04-16 08:22:51 right 2014-04-16 08:23:29 and the problem is, that this happens if i try to login into the lxc container 2014-04-16 08:23:46 and the login fails 2014-04-16 08:25:33 StarWarsFan, you can upgrade the container using the apk on the host 2014-04-16 08:25:43 apk --root /path/to/container 2014-04-16 08:26:09 ah, interesting! 2014-04-16 08:28:21 seems a bigger task: 2014-04-16 08:28:23 http://sprunge.us/JTEW 2014-04-16 08:54:36 StarWarsFan, openjdk6 is likely the blocker. it's no longer in edge. use openjdk7 instead 2014-04-16 08:55:22 ok, will try... 2014-04-16 08:59:18 fabled i have a weird issue on build-edge-x86_64 2014-04-16 08:59:23 oh? 2014-04-16 08:59:29 $ apk fetch --simulate -R linux-grsec 2014-04-16 08:59:29 linux-grsec: unable to select package (or it's dependencies) 2014-04-16 08:59:38 but on my desktop it works 2014-04-16 08:59:55 $ apk add --simulate linux-grsec 2014-04-16 08:59:55 (1/2) Installing linux-firmware (20140327-r0) 2014-04-16 08:59:55 (2/2) Installing linux-grsec (3.13.10-r0) 2014-04-16 08:59:55 OK: 748 MiB in 287 packages 2014-04-16 09:00:02 apk add seems to work 2014-04-16 09:03:23 apk fetch --simulate libgcc 2014-04-16 09:03:42 is probably what is broken 2014-04-16 09:04:29 ncopa, works here too 2014-04-16 09:05:21 hwy 2014-04-16 09:05:23 hey 2014-04-16 09:05:31 i have stopped the x86_64 builder 2014-04-16 09:05:43 til we sort out the iso generation error 2014-04-16 09:05:55 delete tag? 2014-04-16 09:05:59 and tag later with new musl 2014-04-16 09:06:20 i thought it was ok to commit since it said release uploaded 2014-04-16 09:06:21 i really hate the way we fetch depencies with apk fetch -R --simulate | sed 's:Downloading ::' 2014-04-16 09:06:27 only x86 built 2014-04-16 09:06:29 x86_64 2014-04-16 09:06:34 has issues 2014-04-16 09:06:38 yes, apk fetch | sed is bad 2014-04-16 09:06:50 but i start suspect its apk bug 2014-04-16 09:06:55 possible 2014-04-16 09:07:23 Installed: Available: 2014-04-16 09:07:24 libgcc-4.8.2-r6 ? 2014-04-16 09:07:29 seems like gcc build failed? 2014-04-16 09:07:57 could be yes 2014-04-16 09:08:19 gcc seems success on x86 2014-04-16 09:08:22 there was tons of .makedepends-* 2014-04-16 09:08:26 that i had to clean up 2014-04-16 09:08:34 lua-aports seems to leave them 2014-04-16 09:08:44 and i think since build failed it cleaned up the apks 2014-04-16 09:08:51 so you have no gcc apk's now on x86_64 2014-04-16 09:09:00 that would explain why fetch libgcc fails there 2014-04-16 09:09:10 yes 2014-04-16 09:09:19 lua-aports just call abuild 2014-04-16 09:09:26 and abuild cleans up the .makedepends 2014-04-16 09:09:41 it does look like it is configured correctly too 2014-04-16 09:09:44 in /etc/abuild.conf 2014-04-16 09:09:47 hm 2014-04-16 09:10:25 earlier it would fail with noise, but not its continue and build what you can... 2014-04-16 09:10:30 yes 2014-04-16 09:10:39 and the new cleanup code nukes failed pkgs 2014-04-16 09:10:42 so... 2014-04-16 09:10:45 well 2014-04-16 09:10:49 build-edge-x86_64: files from v131211-1665-g7b1de29 uploaded 2014-04-16 09:10:59 i think we should now tag all packages not building as !libc_musl 2014-04-16 09:11:03 it didnt error out 2014-04-16 09:11:09 yes 2014-04-16 09:11:11 and enable the stop-on-fail in abuild 2014-04-16 09:11:25 i think its time for that yes 2014-04-16 09:11:35 lunch 2014-04-16 09:21:26 ncopa: musl doesnt support recvmmsg()? 2014-04-16 09:21:53 dunno, is it posix? 2014-04-16 09:21:59 http://man7.org/linux/man-pages/man2/recvmmsg.2.html 2014-04-16 09:22:03 might be you need set _GNU_SOURCE 2014-04-16 09:22:15 SYNOPSIS top 2014-04-16 09:22:15 #define _GNU_SOURCE 2014-04-16 09:22:15 #include 2014-04-16 09:22:33 try add -D_GNU_SOURCE to CFLAGS 2014-04-16 09:26:03 already defined 2014-04-16 09:26:07 so i guess its missing 2014-04-16 09:26:31 unless something undefs _GNU_SOURCE 2014-04-16 09:27:09 https://github.com/perexg/tvheadend/blob/satip/src/input/mpegts/satip/satip_frontend.c#L20 2014-04-16 09:27:59 $ nm -D /lib/libc.musl-x86_64.so.1 | grep recv 2014-04-16 09:27:59 0000000000039fe8 T recv 2014-04-16 09:27:59 0000000000039ff4 T recvfrom 2014-04-16 09:27:59 000000000003a024 T recvmsg 2014-04-16 09:28:07 looks like its not implemented 2014-04-16 09:29:55 ok, i think the dev will use its own implementation. 2014-04-16 09:31:47 clandmeter you got your new toy? (as i see you are talking about satip) 2014-04-16 09:32:02 crow: yes just got it in the mail :) 2014-04-16 09:33:51 but support is not yet merged into tvheadend, so the code is not 100% tested. 2014-04-16 09:35:09 i see :) 2014-04-16 09:36:15 crow: any oscam crash recently? 2014-04-16 10:02:37 clandmeter, it's trivial to add. it's simple syscall wrapper 2014-04-16 10:02:42 seems it's not there. should add it 2014-04-16 10:04:01 i need to fix few things in musl utils. i can look at recvmmsg while at it 2014-04-16 10:04:47 can look at sendmmsg too 2014-04-16 10:06:59 clandmeter no, but i hope i have everything ready for core dumps 2014-04-16 10:09:18 fabled: looks like he worked around it https://github.com/perexg/tvheadend/commit/0e220b0591c8ac98bf25c4ee992a804605098ad9 2014-04-16 10:16:09 just wondering if it would be good idea to have in AL infra, 2014-04-16 10:16:10 dev.a.o/man-pages-posix/ 2014-04-16 10:16:23 from, https://www.kernel.org/pub/linux/docs/man-pages/man-pages-posix/man-pages-posix-2003-a.tar.xz 2014-04-16 10:16:50 I don't think so 2014-04-16 10:17:09 any public url for posix man pages ? 2014-04-16 10:17:12 I mean… almost everyone keep man pages locally, and if not, he has internet connection anyway 2014-04-16 10:17:21 posix ? 2014-04-16 10:21:41 eg. there is difference in http://man7.org/linux/man-pages/man2/recvmmsg.2.html 2014-04-16 10:24:05 and posix version 2014-04-16 10:37:17 fabled ncopa: is getaddrinfo different on musl? 2014-04-16 10:47:02 clandmeter, yes, i think it's not fully identical, there's some places it's not the same. i think it's on the roadmap that getaddrinfo() and other resolver function would be fixed 2014-04-16 10:48:15 fabled: ok, im getting daemon.err tvheadend[4541]: upnp: getaddrinfo: *: Non-recoverable error 2014-04-16 10:48:34 not sure this is due to musl or because im in container. 2014-04-16 10:49:17 clandmeter, it could be also application error - not checking the return code properly 2014-04-16 10:49:24 but sounds musl issue 2014-04-16 10:51:42 vkrishn: there are different sections 2014-04-16 10:51:58 fabled: this looks correct? https://github.com/perexg/tvheadend/commit/5043acd596e22090b8ebac2ee47577e784e0655e#diff-8f903079458c72ea0dd1fce578229203R58 2014-04-16 10:52:10 vkrishn: usually section 2 is for system calls, which means here "Linux functions" 2014-04-16 10:52:31 vkrishn: 3 is for library calls 2014-04-16 11:01:58 fabled: when is openjdk7 coming to 2.7? 2014-04-16 11:02:11 ok... checking man-pages on edge 2014-04-16 11:02:14 StarWarsFan|afk, not sure we want openjdk7 there 2014-04-16 11:03:04 hm... 2014-04-16 11:05:33 fabled: any comment on that part of code? 2014-04-16 11:05:52 clandmeter, sorry, i'm busy looking at musl related thigns atm 2014-04-16 11:06:30 ok no problem, take your time. 2014-04-16 11:15:22 clandmeter, re: recvmmsg patch upstream, dalias said that it's bug on 64-bit arch to just map it directly to syscall 2014-04-16 11:17:48 clandmeter, what's the other commit about? 2014-04-16 11:18:19 it's the getaddrinfo change? 2014-04-16 11:40:59 fabled: yes its an issue with getaddrinfo 2014-04-16 11:58:02 hmm... there is no recmmsg for posix 2014-04-16 11:58:10 recvmmsg 2014-04-16 11:58:39 vkrishn, correct, it's linux extension 2014-04-16 11:58:54 :) thanks 2014-04-16 12:00:26 a stub page included in posix-pages would be nice 2014-04-16 12:16:02 we have bootable musl iso images now 2014-04-16 12:17:33 for x86 and x86_64 that is 2014-04-16 12:21:46 ncopa: where ? :D 2014-04-16 12:22:47 http://nl.alpinelinux.org/alpine/edge/releases/ 2014-04-16 12:23:42 will there be a xen one? 2014-04-16 12:24:51 77M musl vs 247M uClibc 2014-04-16 12:25:23 barthalion, there is no http://man7.org/linux/man-pages/man3/recvmsg.3p.html 2014-04-16 12:25:30 OR http://man7.org/linux/man-pages/man3/recvmsg.3.html 2014-04-16 12:25:45 so no public url for those pages yet 2014-04-16 12:25:53 alacerda, the edge iso images are stripped down 2014-04-16 12:26:03 you cannot compare them directly to release iso images 2014-04-16 12:26:14 release iso images contain a lot more packages in them 2014-04-16 12:26:34 I can compare only with the AL 3.0, isn't it? 2014-04-16 12:28:26 yes. when AL 3.0 is tagged and we create musl based full iso images - those are comparable to a degree 2014-04-16 12:28:31 but yes, musl packages seem to be smaller 2014-04-16 12:28:59 when switching to musl, apk told i'll free up 50MB on my 2GB install 2014-04-16 12:29:20 :^) 2014-04-16 12:29:21 greta 2014-04-16 12:29:23 great 2014-04-16 12:37:38 Will there be python 3? 2014-04-16 12:41:06 sfdisk,e2fsprogs, lvm2 and syslinux missing. I tried to install it on sda 2014-04-16 12:51:34 Frosh: one day, sure 2014-04-16 12:51:55 Frosh: but not until we find reasonable way to deal with 2 + 3 2014-04-16 12:52:31 Frosh: there is also a possibility to ship python 3.x as python3, but we haven't discussed it yet 2014-04-16 13:02:56 ansible supported yet? 2014-04-16 13:07:24 Frosh: yes, but afaik upstream has no apk support 2014-04-16 13:08:25 Frosh: but you could use this: https://github.com/fabaff/alpine-ansible/blob/master/modules/apk 2014-04-16 13:22:51 Frosh: there is also mine module, but I guess that Fabian uses his daily 2014-04-16 13:23:31 for some ridiculous problem upstream accepted patches to detect Alpine and running release, but not a module for apk-tools 2014-04-16 14:32:13 royger: freebsd dom0, nice! 2014-04-16 14:37:57 kaniini: still a long road, but it's looking good :) 2014-04-16 19:10:54 ok, i've installed nfs-utils-dbg on my musl-edge-box 2014-04-16 19:11:54 lets see if i could help with http://bugs.alpinelinux.org/issues/2842 2014-04-16 19:12:04 "nfs-utils segfaults on musl" 2014-04-16 19:52:20 hm, no way for me :-( 2014-04-16 20:20:43 I really love that small delay between x86* and armhf 2014-04-16 20:21:12 it's cute 2014-04-16 20:24:20 :) 2014-04-16 20:24:53 barthalion: bump pkgrel on openjdk ;-) 2014-04-16 20:42:42 n8@all 2014-04-16 21:27:05 hi 2014-04-16 21:28:04 i wonder if somebody could go to the startssl website and let them sign the csr for the ssl certificate for dl-5.alpinelinux.org? 2014-04-16 21:28:33 as the domain is verified against the email address @alpinelinux.org i won't be able todo it on my own 2014-04-16 21:28:38 it's for free btw 2014-04-16 23:13:18 hi 2014-04-17 07:02:15 files from v2.5.4-274-g5b835f2 uploaded 2014-04-17 07:31:05 moinmoin 2014-04-17 13:03:49 bah 2014-04-17 13:04:44 mmm 2014-04-17 13:04:49 oh yeah the new build system remembers this 2014-04-17 13:07:28 ncopa, we really should make builders fail-on-error now... and mask non-building packages 2014-04-17 13:07:37 yup 2014-04-17 13:07:58 but coffe has higher prio :) 2014-04-17 13:18:47 i should have made gold default in binutils 2014-04-17 13:18:54 linking mozilla would have been so much faster 2014-04-17 13:22:08 spooky. firefox 28 built 2014-04-17 13:22:12 i wonder if it works 2014-04-17 13:23:44 here we go... 2014-04-17 13:24:09 \o/ 2014-04-17 13:25:57 start page search box does not still work 2014-04-17 13:30:00 and session restore i suppose 2014-04-17 13:50:30 fabled: if you have time and energy to debug session restore and startpage search box: https://bugzilla.mozilla.org/show_bug.cgi?id=949375 2014-04-17 13:50:52 ncopa, uh. maybe later. i'm doing openjdk7 upgrade now. and kamailio hacking 2014-04-17 13:51:33 seems openjdk7 has again like 20-30 CVEs updated 2014-04-17 13:51:38 bah 2014-04-17 13:51:59 update from April 15 2014-04-17 13:52:08 i have it test building now 2014-04-17 13:52:23 the new verison has ARM JIT enabled by default too 2014-04-17 13:52:31 out of memory 2014-04-17 13:53:17 ? 2014-04-17 13:53:34 browser console says that 2014-04-17 13:53:35 in ff 2014-04-17 13:53:39 ctrl-shitf-j 2014-04-17 13:54:28 ok, I'll let taht be for now 2014-04-17 13:55:13 it's kinda annoying 2014-04-17 13:55:17 i might look at it tm 2014-04-17 13:56:20 my guess is that its something in javascript that goes wrong 2014-04-17 13:57:42 HA! 2014-04-17 13:57:44 i found it 2014-04-17 13:58:29 cool! 2014-04-17 13:58:59 is it something we laugh at? ;) 2014-04-17 14:03:39 i need to run 2014-04-17 14:03:46 i'll push java out later if it built 2014-04-17 14:03:50 (i have commit ready) 2014-04-17 14:05:19 at least bootstrap compile succeeded. now it's rebuilding itself. i'd assume that to work too 2014-04-17 14:07:32 apk add firefox-pfdjs 2014-04-17 14:28:33 that makes it work? 2014-04-17 14:30:26 lol 2014-04-17 14:30:27 yes 2014-04-17 14:30:29 whatta?! 2014-04-17 17:21:43 hi 2014-04-18 05:25:09 (armhf is building openjdk7 now that xulrunner built. so it can appear 'offline' for some hours. but no fear, it's just working hard.) 2014-04-18 06:02:04 build-2-4: retry 2014-04-18 06:02:29 build64-2-4: retry 2014-04-18 06:11:32 ncopa, i would like to add 'issue closed' tick on 'Resolved' state on redmine. do you think that'd make sense 2014-04-18 06:11:44 because now i need to click on the issue to see if it's been fixed or nto 2014-04-18 06:22:06 clandmeter, why redmine is not latest? was there some upgrade issues? 2014-04-18 06:30:20 there's also 2.5.1 already out. but not sure if it works as-is. so i just did a 'stable' upgrade 2014-04-18 06:30:23 fabled: i was planning to upgrade it together with ruby, but it was blocked upstream 2014-04-18 06:31:10 clandmeter, was 2.4.x broken too? 2014-04-18 06:31:15 i thought it was 2.5.x 2014-04-18 06:31:26 no it wasnt. jus didnt think about it anymore... 2014-04-18 06:31:37 ok 2014-04-18 06:31:47 yes, i remember 2.5.x had something broke wrt. ruby version we have 2014-04-18 06:31:58 should be ok now i think 2014-04-18 06:32:18 i think we need the stable redmine upgrade to 2.7-stable 2014-04-18 06:32:23 i believe there was one security fix 2014-04-18 06:32:46 ruby-* release engineering is scary 2014-04-18 06:33:02 please push to 2.7 2014-04-18 06:33:04 [re-msg] ncopa, i would like to add 'issue closed' tick on 'Resolved' state on redmine. do you think that'd make sense 2014-04-18 06:33:12 for example upgrading 3.4.1 -> 3.4.2 might break things 2014-04-18 06:33:32 thats why people use the ruby gems package manager 2014-04-18 06:33:49 i'm not sure 2014-04-18 06:34:03 i think its nice to have the extra QA check between resolved and closed 2014-04-18 06:34:31 hmm. clandmeter, redmine on 2.7 is still 2.3.x 2014-04-18 06:34:46 for example, could verify that package is actually getting built 2014-04-18 06:35:14 fabled: yes it is. 2014-04-18 06:35:21 there's 2.3.4 out 2014-04-18 06:36:06 for example: http://bugs.alpinelinux.org/issues/2485 2014-04-18 06:36:14 i think i have fixed the issue 2014-04-18 06:36:19 but i havent verified it 2014-04-18 06:36:36 so i think its nice to be able to get some verification before closing the issue 2014-04-18 06:36:38 why not just use 'ref' then? 2014-04-18 06:36:56 in 90% cases it's simple upgrade request 2014-04-18 06:37:02 well... 2014-04-18 06:37:13 but i think we could have autocolose after some days 2014-04-18 06:37:23 i'm just annoyed since we fixed many issues. and they all look like 'not fixed' 2014-04-18 06:37:37 and i lost track and end up clicking same bugs just to find that it's fixed already 2014-04-18 06:37:39 the sec issues we fixed yesterday 2014-04-18 06:37:40 ? 2014-04-18 06:37:48 for example, yes 2014-04-18 06:37:56 the current work flow there 2014-04-18 06:38:10 we fix the same cve on all stable branches 2014-04-18 06:38:38 once all stable brnaches are fixed (and resolved, complete 100%), we verify that the package was built 2014-04-18 06:39:07 then we close and move them from alpine security project (whihc is private) to alpine linux (public) 2014-04-18 06:39:34 mm.ok. 2014-04-18 06:40:03 i'm not saying this is the optiaml way to work, just explaining how things work currently 2014-04-18 06:40:29 i would love to have that support for multiple git branches per issue in redmine 2014-04-18 06:40:31 i really hope redmine gets soon the 'multiple branches' per issue support 2014-04-18 06:40:33 yes 2014-04-18 06:40:37 absolutely 2014-04-18 06:40:52 qemu 2.0 is out 2014-04-18 06:41:37 build-2-7-x86_64 failure 2014-04-18 06:41:55 >>> redmine: Fetching http://rubyforge.org/frs/download.php/77138/redmine-2.3.4.tar.gz 2014-04-18 06:41:55 % Total % Received % Xferd Average Speed Time Time Time Current 2014-04-18 06:41:55 Dload Upload Total Spent Left Speed 2014-04-18 06:41:55 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 2014-04-18 06:41:55 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 2014-04-18 06:41:56 mv: can't rename '/var/cache/distfiles/v2.7/redmine-2.3.4.tar.gz.part': No such file or directory 2014-04-18 06:42:05 sounds download failure 2014-04-18 06:42:10 wrong url 2014-04-18 06:42:14 or a race? 2014-04-18 06:42:25 you cannot rename the version only 2014-04-18 06:42:26 it worked on test box / x86. url should be right 2014-04-18 06:42:27 afaik 2014-04-18 06:42:46 you updated the complete url fabled? 2014-04-18 06:42:50 yes the the FRS in rubyfoge is horrible... 2014-04-18 06:43:05 you probably need to change the 77138 2014-04-18 06:43:15 why checksum works then? 2014-04-18 06:44:28 someone had downloaded it earlier? 2014-04-18 06:44:31 dunno 2014-04-18 06:44:38 could be 2014-04-18 06:44:42 in edge maybe 2014-04-18 06:44:44 i use http://files.rubyforge.vm.bytemark.co.uk/redmine/redmine-2.3.4.tar.gz ? 2014-04-18 06:44:55 sounds better yet 2014-04-18 06:45:43 that doesnt have 2.5.x 2014-04-18 06:45:49 http://www.redmine.org/releases/redmine-2.3.4.tar.gz 2014-04-18 06:45:55 i think that works 2014-04-18 06:46:00 hope the keep archives long enough 2014-04-18 06:47:14 seems edge is on the redmine.org url already 2014-04-18 06:48:14 ill try to update bugs now. fingers crossed. 2014-04-18 06:48:24 no time today to fix breakage though. 2014-04-18 06:52:03 hmm. openjdk failed 2014-04-18 06:52:05 on arm 2014-04-18 06:52:34 bah. it's trying to use kuser_helpers too 2014-04-18 06:57:05 i should probably enable that in grsec 2014-04-18 06:57:14 seems no VM will work without them 2014-04-18 07:16:01 whats kuser_helpers? 2014-04-18 07:18:00 ncopa, on arm, it's a special memory address where kernel ships certain functions to do SMP synchronization like cmpxchg and memory barriers 2014-04-18 07:18:24 grsec disables it's by default as it's fixed address and _may_ make certain type of attacks easier 2014-04-18 07:18:41 but later added an config option to turn them back on 2014-04-18 07:19:01 since it seems pretty much all virtual machines that run on ARM have been hardcoded to use those 2014-04-18 07:19:14 that was the musl issue i had in the beginning. musl used them unconditionally too 2014-04-18 07:22:22 hmm... seems wireshark isn't working 2014-04-18 07:22:57 $ dumpcap -D -Z none 2014-04-18 07:22:57 ETEKCan't get list of interfaces: Can't open /sys/class/net: Permission deniedE 2014-04-18 07:23:00 and then it hangs 2014-04-18 07:23:12 and wireshark seems to hang in wait4() on calling dumpcap 2014-04-18 07:23:55 smells grsec issue 2014-04-18 07:24:49 hmm 2014-04-18 07:25:00 running dumpcap as root, dumps interface list, but it hangs again 2014-04-18 07:26:11 hmm https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9609 2014-04-18 07:28:53 that's different though 2014-04-18 07:28:57 it hangs in futex 2014-04-18 07:29:06 sounds g_mutex_* issue 2014-04-18 07:34:36 re issues closed/resolved 2014-04-18 07:34:50 on this page: http://bugs.alpinelinux.org/versions/78 2014-04-18 07:34:58 click on "12 open" 2014-04-18 07:35:14 http://bugs.alpinelinux.org/projects/alpine/issues?fixed_version_id=78&set_filter=1&status_id=o 2014-04-18 07:35:23 an you see clean which is 'resolved' 2014-04-18 07:39:18 ok 2014-04-18 07:55:10 i have a libvirt/virt-manager issue 2014-04-18 07:55:25 when win7 boots, it crashes virt-manager 2014-04-18 07:57:23 the latest sysconf patch didn't help? 2014-04-18 08:56:27 hum. wireshark hang seems to be application misusing atexit()/exit() or similar. looking more into it 2014-04-18 09:26:52 hi 2014-04-18 09:27:14 If I add ipv6 to my interfaces, I get "ip: ioctl 0x8913 failed: No such device" on restart :( 2014-04-18 09:27:36 what program gives you that? 2014-04-18 09:27:42 udhcpc? 2014-04-18 09:27:43 dhcpcd? 2014-04-18 09:27:49 busybox ifup? 2014-04-18 09:28:02 I am doing "rc-service networking restart" 2014-04-18 09:28:02 does it help if you apk add iproute2? 2014-04-18 09:28:12 is it static ip? 2014-04-18 09:28:16 yes 2014-04-18 09:28:28 so ifup 2014-04-18 09:28:30 fails 2014-04-18 09:28:36 try apk add iproute2 2014-04-18 09:28:44 and see if that makes any difference 2014-04-18 09:29:00 is it edge? or v2.7 2014-04-18 09:29:04 2.7 2014-04-18 09:29:27 now, it says: "Cannot find device "br0"" 2014-04-18 09:30:51 on 2014-04-18 09:30:53 nosuch device 2014-04-18 09:31:03 the br0 interface does not exist 2014-04-18 09:31:12 can you try: apk add bridge 2014-04-18 09:31:23 thats already installed 2014-04-18 09:31:57 it fails when setting up bridge interface for soem reason 2014-04-18 09:32:01 brctl show 2014-04-18 09:32:11 br0 8000.0090fb461628 no eth0 2014-04-18 09:32:50 what version of musl do you have? 2014-04-18 09:32:55 If I remove ipv6 and restart networking, everything is okay 2014-04-18 09:33:05 I am using 2.7 without musl (I think) 2014-04-18 09:33:51 it kinda sounds like the if_nameindex() issues we had on early musl 2014-04-18 09:34:13 check what busybox is linked against 2014-04-18 09:34:20 apk add scanelf 2014-04-18 09:34:27 scanelr -n /bin/busybox 2014-04-18 09:34:33 scanelf -n /bin/busybox 2014-04-18 09:34:36 ERROR: unsatisfiable constraints: scanelf-0.7-r4: masked in: @edge satisfies: world[scanelf] 2014-04-18 09:34:44 @edge 2014-04-18 09:34:44 I don't want to break the machine :) 2014-04-18 09:34:55 sounds like it already is... 2014-04-18 09:34:55 I tried musl yesterday on another machine and broke it completly 2014-04-18 09:35:14 mixing v2.7 and @edge means mixing uclibc and musl 2014-04-18 09:35:18 and will completely break things 2014-04-18 09:35:36 remove @edge from /etc/apk/repositories 2014-04-18 09:35:38 and apk upgrade -U -a 2014-04-18 09:35:43 actually 2014-04-18 09:35:56 apk add -U -u apk-tools-static 2014-04-18 09:35:59 do that fist 2014-04-18 09:36:14 and in case things breaks, maybe install busybox-static too 2014-04-18 09:36:36 then: apk.static upgrade -U --no-self-upgrade -a 2014-04-18 09:36:49 make sure you have no edge repo in /etc/apk/repositories first 2014-04-18 09:37:36 Ok I did that all 2014-04-18 09:37:54 and now, what apk add scanelf say? 2014-04-18 09:38:02 # apk add scanelf ERROR: unsatisfiable constraints: scanelf (missing): required by: world[scanelf] 2014-04-18 09:38:07 pk 2014-04-18 09:38:08 ok 2014-04-18 09:38:16 try apk add pax-utils then 2014-04-18 09:38:39 Ok 2014-04-18 09:38:50 scanelf -n /bin/busybox 2014-04-18 09:38:59 should show uclibc and nothing musl 2014-04-18 09:39:02 TYPE NEEDED FILE ET_DYN libcrypt.so.0.9.32,libm.so.0.9.32,libc.so.0.9.32 /bin/busybox 2014-04-18 09:39:06 yup 2014-04-18 09:39:10 looks correct 2014-04-18 09:39:14 does ipv6 work now? 2014-04-18 09:39:48 It still says: "Cannot find device "br0" [ !! ]" 2014-04-18 09:40:09 how does your /etc/network/interfaces look like? 2014-04-18 09:40:16 i dont have experience with ipv6... 2014-04-18 09:40:29 do you have bridge-ports defined? 2014-04-18 09:40:56 http://pastebin.com/8aUkiKnR 2014-04-18 09:41:57 hm 2014-04-18 09:42:17 i dont know how bridge scrip is supposed to work with ipv6 and ipv4 2014-04-18 09:42:29 the br0 inet6 stanza has no bridge_ports 2014-04-18 09:42:39 I added it there too 2014-04-18 09:42:48 what happens if you add bridge_ports to inet6? 2014-04-18 09:42:57 should use the 'link' instead of 'inet' or 'inet6'. i think kunkku fixed that 2014-04-18 09:43:17 it says Cannot find device "br0" [ !! ] 2014-04-18 09:43:23 and brctl: bridge br0: File exists run-parts: /etc/network/if-pre-up.d/bridge exited with code 1 [ !! ] 2014-04-18 09:43:28 was that pushed to 2.7-stable? 2014-04-18 09:43:49 switch from inet to link? 2014-04-18 09:43:52 or how is it meant? 2014-04-18 09:45:32 ah I think, ipv4 is removing the br0 and ipv6 is trying to do it too 2014-04-18 09:45:41 and then it says Cannot find device "br0" 2014-04-18 09:56:39 files from v2.5.4-281-g79b5871 uploaded 2014-04-18 10:15:15 Do i need modprobe dm-mod for lvm? 2014-04-18 10:15:47 I tried it without and it worked... 2014-04-18 10:16:11 Is musl already "usable"? 2014-04-18 10:16:20 I get many kernel panics on virtualbox :-( 2014-04-18 10:20:50 shafire, i run musl on my desktop 2014-04-18 10:21:01 it fixes several issues; but introduces some different ones. 2014-04-18 10:21:11 so far i think it's in pretty good shape 2014-04-18 10:21:19 timezone selection is one user visible issue 2014-04-18 10:21:26 and now i'm debugging why wireshark is broke 2014-04-18 10:21:42 but e.g. firefox no longer crashes randomly, and utf8 works a lot better 2014-04-18 10:21:49 feels also faster 2014-04-18 10:22:52 sounds good 2014-04-18 10:24:55 ipv6 works now 2014-04-18 10:25:09 I did it another way with up/down ip -6 addr... 2014-04-18 10:25:37 ncopa: thanks for holding flashcache 2014-04-18 10:26:21 I tried to get docker running on musl yesterday :-) 2014-04-18 11:19:13 How do you configure start a qemu guest with a bridge network? 2014-04-18 11:35:31 openntpd is missing in edge 2014-04-18 11:36:56 http://s7.directupload.net/images/140418/s3l63p4g.png 2014-04-18 11:42:46 oh i think thatas because we renamed optnntpd's init.d script to ntpd and added support for busybox ntpd 2014-04-18 11:42:53 shafire: could you please file a bug for that? 2014-04-18 11:42:56 so we dont forget 2014-04-18 11:48:29 done 2014-04-18 13:06:32 files from v2.4.11-228-g1df893d uploaded 2014-04-18 13:41:37 files from v2.5.4-283-ge9ac511 uploaded 2014-04-18 13:53:58 files from v2.4.11-229-gf93dd45 uploaded 2014-04-18 18:27:29 barthalion: Do you know what might have happened to apk-tools* in Arch's AUR? Oddly enough I can download the tarball directly, but it can't be found through the AUR's search UI. 2014-04-18 18:29:15 jlyo: I have removed them as I didn't see enough interest 2014-04-18 18:29:29 jlyo: feel free to reupload them if you want, or let me do so 2014-04-18 18:29:46 but I use apk-tools-static unpacked to somewhere in $PATH anyway 2014-04-18 18:31:35 barthalion: It's not a huge deal. I'm just suprised by the tarball existing when it's not "in" the AUR. 2014-04-18 18:31:44 it's a feature I guess 2014-04-18 18:31:49 or someone broke cleanup script 2014-04-18 18:32:01 I removed them long time ago 2014-04-18 18:32:15 (I'm actually wondering if there is any cleanup script…) 2014-04-18 18:33:00 anyways 2014-04-18 18:33:54 kaniini: moved libseccomp to [core], however I don't see why you wouldn't had other repos enabled 2014-04-19 10:20:01 jlyo: I've resubmitted apk-tools to AUR 2014-04-19 14:46:39 so does edge-uclibc still get updates or is it done? 2014-04-19 15:06:28 with apk upgrade musl returns error: http://pastebin.com/xDcbn3VG 2014-04-19 15:06:37 Linux buildenv 3.13.10-0-grsec #1-Alpine SMP Tue Apr 15 06:51:46 GMT 2014 x86_64 Linux 2014-04-19 15:06:48 buildenv:~# apk info -v | grep musl 2014-04-19 15:06:48 musl-dev-1.0.0-r8 2014-04-19 15:06:48 musl-1.1.0-r0 2014-04-19 15:06:48 musl-utils-1.1.0-r0 2014-04-19 15:07:04 apk update && apk upgrade returns: http://pastebin.com/xDcbn3VG 2014-04-19 15:07:22 cat /etc/apk/repositories: 2014-04-19 15:07:23 http://dl-4.alpinelinux.org/alpine/edge/main 2014-04-19 15:40:15 hi 2014-04-19 15:40:22 apk does not have any ipv6 support? 2014-04-19 16:28:32 hey guys 2014-04-19 16:28:40 is it safe to upgrade edge to musl right now? 2014-04-19 16:30:37 the thing that fcolista pasted above is worrying me 2014-04-19 16:31:36 it should be ok 2014-04-19 16:31:45 i think fcolista's problem is that he has installed manually uclibc-dev 2014-04-19 16:31:46 oh ok 2014-04-19 16:31:48 oh 2014-04-19 16:31:59 that does not exists in musl repo, and if it's installed musl-dev will not install 2014-04-19 16:32:14 one should install libc-dev anyway instead of {uclibc,musl}-dev 2014-04-19 16:35:34 ok 2014-04-19 16:35:37 upgrading now 2014-04-19 16:35:45 using the instructions on the website 2014-04-19 16:35:53 (11/104) Installing musl-utils (1.1.0-r2) 2014-04-19 16:35:53 ERROR: musl-utils-1.1.0-r2: trying to overwrite usr/bin/iconv owned by libiconv-1.12-r8. 2014-04-19 16:35:55 ACTION shrugs 2014-04-19 16:36:14 it continued 2014-04-19 16:36:36 yes, just run 'apk fix' in the end 2014-04-19 16:36:40 ok 2014-04-19 16:36:46 i think musl-utils needs to replace libiconv 2014-04-19 16:36:54 yeah 2014-04-19 16:36:54 or depend=!libiconv 2014-04-19 16:37:00 I think I saw that libiconv was going to be purged 2014-04-19 16:37:04 yes 2014-04-19 16:37:08 it's just ordering 2014-04-19 16:37:14 libiconv is not in musl edge 2014-04-19 16:37:21 we use the musl's iconv implementation 2014-04-19 16:37:31 oh ok 2014-04-19 16:37:52 http://puu.sh/8f3W8.png 2014-04-19 16:37:57 is that bad 2014-04-19 16:38:03 or normal 2014-04-19 16:38:25 normal. you should just update mkinitfs.conf to new ones 2014-04-19 16:38:30 ij 2014-04-19 16:38:31 ok 2014-04-19 16:45:30 hmm 2014-04-19 16:45:47 is it just me 2014-04-19 16:45:50 or is syslinux package gone 2014-04-19 16:47:17 oh 2014-04-19 16:47:18 there it is 2014-04-19 17:09:17 mounting root failed 2014-04-19 17:09:30 initramfs emergency recovery shell launched 2014-04-19 17:09:31 o.O 2014-04-19 17:12:07 mount: mounting /dev/mapper/vg0-root on /sysroot failed: No such file or directory 2014-04-19 17:12:12 that's what it was 2014-04-19 17:14:08 (I think) 2014-04-19 19:01:25 arrgh 2014-04-19 19:03:16 gonna see if I can boot into an alpine live cd and fix it that way 2014-04-19 19:50:02 yeah something is wrong 2014-04-19 19:50:26 I try to mkinitfs after upgrading to edge musl 2014-04-19 19:50:35 but it gives me all those no such file or directory errors 2014-04-19 19:50:38 and I think that's why I can't boot 2014-04-19 21:01:30 yeah, docker is cool 2014-04-20 00:39:16 trying to get my install to boot up again 2014-04-20 00:39:16 http://puu.sh/8fBKG.png 2014-04-20 00:39:27 but that keeps happening 2014-04-20 00:39:32 anyone know how to fix it? 2014-04-20 00:39:37 it has the latest mkinitfs and all that 2014-04-20 14:12:41 ncopa: do you know how to fix this after upgrading to musl edge? http://puu.sh/8fBKG.png 2014-04-20 14:12:49 I can't boot afterwards 2014-04-20 14:13:03 I get put into an emergency boot shell or something 2014-04-20 14:16:02 it's the latest mkinitfs 2014-04-20 19:12:36 fabled: I think there's a problem with full disk encryption and musl 2014-04-20 19:12:54 I can't think of anything else that might give the error I get 2014-04-20 19:15:39 Mp5shooter, possible. we have not tested that. 2014-04-20 19:15:47 Mp5shooter, file a bug or email the list. 2014-04-20 19:16:04 ok 2014-04-20 19:23:35 ooo... 2014-04-20 19:23:38 I screwed around some more 2014-04-20 19:23:42 tried the same things i was doing earlier 2014-04-20 19:23:48 and this time i rebooted and got the passphrase prompt 2014-04-20 19:23:49 :OP 2014-04-20 19:23:50 :O 2014-04-20 19:34:00 ugh. 2014-04-20 19:39:27 fails to mount root 2014-04-20 19:39:28 still 2014-04-20 20:24:53 Mp5shooter: can you mount it with a 2.7 iso? 2014-04-20 20:25:05 yes 2014-04-20 20:25:18 I've been booting into an alpine 2.7.5 iso to try and fix it 2014-04-20 20:25:36 I can mount the drive no problems 2014-04-20 20:25:41 so when you mount wiht musl it wont work? 2014-04-20 20:26:24 s/mount/boot 2014-04-20 20:26:29 nope 2014-04-20 20:26:30 I get uh 2014-04-20 20:26:39 http://puu.sh/8gBMT.png 2014-04-20 20:27:12 that's when I try to boot 2014-04-20 20:27:24 everything worked fine until I upgraded 2014-04-20 20:27:38 does lvm work? 2014-04-20 20:27:44 devices are present? 2014-04-20 20:28:03 when I boot or when I'm doing stuff with it while booted into a live cd? 2014-04-20 20:28:14 on musl 2014-04-20 20:28:26 i guess lvm works and the device is available? 2014-04-20 20:28:27 idk 2014-04-20 20:28:29 I can't boot into it 2014-04-20 20:28:45 you have emergecy shell right? 2014-04-20 20:28:48 yes 2014-04-20 20:29:13 does that lvm tools? 2014-04-20 20:29:32 you see stuff in /dev/mapper? 2014-04-20 20:29:42 hm 2014-04-20 20:29:59 all I see in /dev/mapper is lvmcrypt and control 2014-04-20 20:30:39 I don't see any lvm tools though 2014-04-20 20:30:44 like lvcreate and stuff 2014-04-20 20:31:05 i dotn think its in that shell 2014-04-20 20:31:45 but lvm devices should be present, or else init cant mount them. 2014-04-20 20:32:49 :S 2014-04-20 20:33:41 I wonder why it's not showing up 2014-04-20 20:35:36 i never used lvm on root so im not a big help 2014-04-20 20:35:48 nor did i use encryption 2014-04-20 20:36:26 :( 2014-04-21 08:01:30 found this interesting http://dyncall.org/ 2014-04-21 11:23:31 hi ncopa. Dunno if you are aware of that, but lxc-alpine template doesn't work on archlinux. The function get_static_apk fails when tries to determine the last release. But it works on Alpine. I suppose is a different behaviour in redirect of gnu/wget and busybox wget 2014-04-21 11:23:34 FYI 2014-04-21 11:24:04 hm 2014-04-21 11:24:12 i think it works in fedora too 2014-04-21 11:29:51 lxc-create -t alpine -n alpine-musledge-x64 -f /etc/lxc/lxc.conf -- --arch x86_64 2014-04-21 11:29:51 which: no apk in (/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/opt/kde/bin:/usr/bin/vendor_perl:/usr/bin/core_perl:/usr/sbin:/usr/bin:/sbin:/bin) 2014-04-21 11:29:51 Determining the latest release...
< Using static apk from http://wiki.alpinelinux.org/cgi-bin/dl.cgi/ 2014-04-21 11:29:51
< 2014-04-21 11:29:53 2014-04-21 11:29:55 basically wget doesn't follow the dl.cgi redirect 2014-04-21 11:30:23 wget supports --max-redirect flag 2014-04-21 11:30:30 but is for gnu wget 2014-04-21 11:30:41 (and doesn't work anyway) 2014-04-21 11:30:54 is not important, just FYI 2014-04-21 11:31:54 curl could be used as well, but it implies having culr installed (that is true for all the major distro but alpine) 2014-04-21 12:35:34 ncopa, any comments for http://sprunge.us/RdIL ? 2014-04-21 12:36:59 nothing more than, i trust you ;) 2014-04-21 12:40:50 ncopa, do we have anything using the update-ca-certs hooks? 2014-04-21 12:40:53 those are not yet implemented 2014-04-21 12:41:08 i dont know 2014-04-21 12:41:15 and in fact, i think the way update-ca-certificate does it originally... is sort of broken 2014-04-21 12:45:50 I don't think update-ca-certificates works at all 2014-04-21 12:46:20 barthalion, oh? 2014-04-21 12:49:32 or I'm simply too stupid to use it 2014-04-21 12:49:47 I tried some time ago to add cacert root certs locally and it couldn't find it 2014-04-21 12:51:19 i think it wants them to end with .crt 2014-04-21 12:51:24 amonst other things 2014-04-21 12:51:45 it's little picky on what it adds. it's all doc'ed in the man page 2014-04-21 12:52:21 clandmeter: did you see the msg i left for you? 2014-04-21 13:03:49 ncopa, i fixed the lxc-alpine template. http://pastebin.com/6N6x8t6k 2014-04-21 13:04:13 Just take advantage of http://rsync.alpinelinux.org/alpine/MIRRORS.txt 2014-04-21 13:04:24 pickup randomly one of the mirrors there 2014-04-21 13:04:53 but dunno if dl.cgi check the closer mirror 2014-04-21 13:17:18 dl.cgi just take a random 2014-04-21 13:17:38 but the intention was to later add smarts that picks a mirror closer to you 2014-04-21 13:18:41 ok. So this is not the best solution in the long term, but atm make the lxc container works on Arch. 2014-04-21 13:19:12 do what you think is best.. 2014-04-21 13:19:40 what was the wget command for 'follow redirects' ? 2014-04-21 13:19:51 or maybe check for existance of curl 2014-04-21 13:19:51 --max-redirect=$n 2014-04-21 13:20:16 yeah, in that case there are more control to do 2014-04-21 13:20:24 even if you have gnu/wget or bb/wget 2014-04-21 13:20:41 if which curl >/dev/null; then curl ...; else wget ...; fi 2014-04-21 13:21:07 so fallback to wget if curl is missing 2014-04-21 13:21:40 yep 2014-04-21 13:21:49 but atm wget doesn't work 2014-04-21 13:21:56 *with wget 2014-04-21 13:31:07 clandmeter: re https://github.com/lxc/lxc/pull/201 2014-04-21 13:31:09 it looks wrong 2014-04-21 13:31:33 if you do: lxc-create -t alpine -- --arch i386 2014-04-21 13:31:53 then it will in lxc config set lxc.arch=x86 2014-04-21 13:32:07 but if you do: lxc-create -t alpine -- --arch x86 2014-04-21 13:32:11 then it will set .i686 2014-04-21 16:19:06 barthalion: Great, thanks! (For resubmitting apk-tools to the AUR) 2014-04-21 16:21:43 the lua update-ca-certificates is steadily 0.25s on my arm box (the shell script was 3-20 seconds depending on if the box was doing anything else) 2014-04-21 18:09:05 ncopa: yes, its not perfect, its just less wrong. 2014-04-21 18:19:34 ncopa, the awall issue is pretty bad in 2.7.6 2014-04-21 18:19:59 fabled: i might have one other one, but could be local policy issue 2014-04-21 18:20:15 error while enabling a policy that used to work: 2014-04-21 18:20:20 awall: Expected comma or object end but found T_STRING at character 136 while parsing /usr/share/awall/optional/webproxy.json 2014-04-21 18:20:49 sounds like typo 2014-04-21 18:20:51 i had similar 2014-04-21 18:21:01 i think lua-cjson in new awall is stricter 2014-04-21 18:21:16 probably is - a colleague made this one, so might just have not been tested since last commit 2014-04-22 03:36:36 is it possible to build linux-grsec with a custom config? 2014-04-22 03:36:47 for our application, we need a smaller kernel than provided by stock 2014-04-22 03:46:34 oh 2014-04-22 03:46:35 I see how 2014-04-22 03:46:37 although 2014-04-22 03:46:45 kernelconfig.armhf: FAILED 2014-04-22 03:46:50 that sha512sum fails :p 2014-04-22 04:39:22 Moinmoin 2014-04-22 06:21:41 morning 2014-04-22 06:21:47 we have issues with udev now 2014-04-22 06:21:56 gnome-bluetooth need udev_hwdb_* 2014-04-22 06:22:11 which is not available in our outdated udev package 2014-04-22 07:39:56 kaniini, www.libressl.org 2014-04-22 07:41:19 ncopa: eudev seems to have udev_hwdb_* 2014-04-22 07:42:04 and they may be more friendly towards non glibc support than systemd 2014-04-22 08:43:34 hm 2014-04-22 08:43:57 might be eudev can be used as short time solution 2014-04-22 08:44:12 i hacked gnome-bluetooth to work without udev_hwdb_* 2014-04-22 12:53:41 ha 2014-04-22 12:53:54 that fixes a 2 year old annoying bug 2014-04-22 12:54:01 musl makes me feel really good :) 2014-04-22 12:56:53 :-) 2014-04-22 12:58:02 by the way, did you see that http://bugs.alpinelinux.org/issues/2842 seems to happen only on x86_64? 2014-04-22 12:59:15 (the nfs-issue) 2014-04-22 12:59:39 oh right 2014-04-22 12:59:46 maybe i should have a look at that now 2014-04-22 13:00:04 that would be great (blush) 2014-04-22 13:00:14 so it only happens on x86_64 nfs server? 2014-04-22 13:00:15 musl 2014-04-22 13:00:20 exactly 2014-04-22 13:00:39 the x86 lxc container works without problems 2014-04-22 13:00:49 and a native installed box too 2014-04-22 13:00:58 and a native installed x86 box too 2014-04-22 13:01:07 * Starting NFS daemon ... 2014-04-22 13:01:07 Segmentation fault (core dumped) [ !! ] 2014-04-22 13:01:07 * Starting NFS smnotify ... [ ok ] 2014-04-22 13:01:07 * ERROR: nfs failed to start 2014-04-22 13:01:13 i can reproduce atleast :) 2014-04-22 13:01:29 dunno if :) or :( now... ;-) 2014-04-22 13:02:24 #0 0x000067be3b1c0ddf in strlen () from /lib/ld-musl-x86_64.so.1 2014-04-22 13:02:24 (gdb) bt 2014-04-22 13:02:24 #0 0x000067be3b1c0ddf in strlen () from /lib/ld-musl-x86_64.so.1 2014-04-22 13:02:24 #1 0x000067be3b1c0c4f in strdup () from /lib/ld-musl-x86_64.so.1 2014-04-22 13:02:24 #2 0x0000000000000000 in ?? () 2014-04-22 13:02:38 i'll find some coffe 2014-04-22 13:30:10 warning: no loadable sections found in added symbol-file system-supplied DSO at 0x73af533ef000 2014-04-22 13:30:29 fabled: are there some way in gdb to tell what DSO it is at that given address? 2014-04-22 13:30:35 ^^^ 2014-04-22 13:31:10 i'm not sure. but yes, that's a PITA with musl; debugging doesn't really work that weel 2014-04-22 13:31:13 well* 2014-04-22 14:58:40 StarWarsFan: did you file a bug for nfs? 2014-04-22 14:58:46 i think i know how to fix it 2014-04-22 14:58:51 but I'm not 100% sure 2014-04-22 14:58:58 i will have to test it tm 2014-04-22 14:59:16 yure 2014-04-22 14:59:18 sure 2014-04-22 14:59:36 http://bugs.alpinelinux.org/issues/2842 2014-04-22 14:59:59 sounds good! 2014-04-22 16:25:21 fabled: i like it 2014-04-22 19:13:06 ncopa, ding 2014-04-22 19:13:20 ncopa, so I was wondering if the ability to serve modules via NFS is possible yet, using this: http://wiki.alpinelinux.org/wiki/PXE_boot 2014-04-22 19:56:25 Elizacat: it doesnt work for you? 2014-04-22 20:15:14 hmm, 7 days ago docker was moved to main in commit 4ee2c8e and algibot logged: build-edge-x86_64: files from v131211-1658-g4ee2c8e uploaded 2014-04-22 20:15:59 but the apk is nowhere to be found on nl.alpinelinux.org 2014-04-22 22:41:20 clandmeter, no I was checking before I go and expend hte effort 2014-04-22 22:41:21 *the 2014-04-23 06:56:09 Elizacat: nfs is broken on musl atm 2014-04-23 06:56:14 i will rty fix it today 2014-04-23 06:59:35 and /me ist "pushing all thumbs" that the fix will be a success ;-) 2014-04-23 08:35:32 ncopa: any insight into why docker apk is missing from the mirrors after move to main even though algitbot reported upload? 2014-04-23 08:37:56 uggedal: yeah, i think it failed to build 2014-04-23 08:38:21 while working on musl we did 'keep-going-even-if-it-fails' 2014-04-23 08:38:27 edge builders are still set up like that 2014-04-23 08:38:43 and then if it previously failed, then it will not retry 2014-04-23 08:40:00 we should implement per package logs 2014-04-23 08:40:56 i think i know why it failed too 2014-04-23 08:41:06 >>> docker: Unpacking /var/cache/distfiles/docker-0.10.0.tar.gz... 2014-04-23 08:41:07 env: can't execute 'bash': No such file or directory 2014-04-23 08:41:14 it needs bash in makedepends 2014-04-23 08:41:22 argh 2014-04-23 08:41:42 will look at it 2014-04-23 08:41:43 thanks 2014-04-23 08:41:51 i'm on it 2014-04-23 08:42:20 thanks 2014-04-23 08:42:44 we need improve error reporting on build failures 2014-04-23 08:42:57 and we should keep per package build logs 2014-04-23 08:43:27 is there a public place to see the global logs? 2014-04-23 08:44:23 http://bld1.alpinelinux.org/buildlogs/build-edge-x86.log 2014-04-23 08:44:33 http://bld2.alpinelinux.org/buildlogs/build-edge-x86_64.log 2014-04-23 08:49:35 fabled: edc1ec2c (main/musl: align with upstream git, fixes for timezone handling) 2014-04-23 08:49:43 breaks things for us... 2014-04-23 08:50:23 i think that commit requires that we remove all libiconv-dev buildtime deps and rebuild anything that touches libiconv 2014-04-23 08:50:43 >>> xfce4-volumed: Installing packages on builder: xfconf-dev libnotify-dev gst-plugins-base-dev keybinder-dev build-base xfce4-mixer 2014-04-23 08:50:43 ERROR: unsatisfiable constraints: 2014-04-23 08:50:43 libiconv-1.12-r8: 2014-04-23 08:50:43 breaks: musl-utils-1.1.0-r3[!libiconv] 2014-04-23 08:50:43 satisfies: 2014-04-23 08:50:45 libiconv-dev-1.12-r8[libiconv=1.12-r8] 2014-04-23 08:50:47 >>> ERROR: xfce4-volumed: all failed 2014-04-23 08:51:02 ah so its not me 2014-04-23 08:51:09 i just tried to upgrade... 2014-04-23 08:52:04 utils() { 2014-04-23 08:52:04 - replaces="uclibc-utils" 2014-04-23 08:52:04 + depends="!uclibc-utils !libiconv" 2014-04-23 08:52:04 license="MIT BSD GPL2+" 2014-04-23 08:52:04 2014-04-23 08:53:13 fabled: the replaces was there so it was possible to upgrade from uclibc 2014-04-23 08:53:21 i'm not sure it is now 2014-04-23 08:56:21 something is pulling in libiconv 2014-04-23 08:56:26 we don't have that in musl 2014-04-23 08:56:30 so i rather have it deleted 2014-04-23 08:57:15 libiconv-dev i guess 2014-04-23 08:58:03 so basically, there is no way to build anything against libiconv anymore? 2014-04-23 08:58:57 does musl suppose iso-8859-1? 2014-04-23 08:59:01 support 2014-04-23 08:59:09 the iconv api, yes 2014-04-23 08:59:51 i think there are some applications like mailing list archive -> web 2014-04-23 09:00:13 that needs to be able to handle all kinds of weird charsets 2014-04-23 09:00:19 and convert those to utf8 for web 2014-04-23 09:01:17 hmm 2014-04-23 09:01:28 having iconv would still break things 2014-04-23 09:01:30 food 2014-04-23 09:01:54 maybe we could port hypermail to use icu or similar 2014-04-23 09:01:59 idunno 2014-04-23 09:03:13 what are the policy on the non-free/ dir? should it be used for all non-free software or only software which is not allowed to distribute in binary form? 2014-04-23 09:03:26 the exact list that has libiconv-dev http://sprunge.us/hRYN 2014-04-23 09:03:43 uggedal: I havent really thought of it 2014-04-23 09:04:06 but basically anything that we cannot ship in binary form 2014-04-23 09:05:07 but if we are allowed to ship a binary apk, then we dont really need put it in non-free 2014-04-23 10:22:47 fabled: do we have a fix for libiconv (or a workaround)? 2014-04-23 10:23:00 clandmeter, apk del libconv-dev ? 2014-04-23 10:23:20 its not installed 2014-04-23 10:23:51 ncopa, hmm 2014-04-23 10:24:04 i thought libiconv was never installed 2014-04-23 10:24:12 or built for musl 2014-04-23 10:24:21 oh it is 2014-04-23 10:24:23 type 2014-04-23 10:24:25 typo 2014-04-23 10:24:51 i shouldnt just copy things from you ;-) 2014-04-23 10:25:22 oh 2014-04-23 10:25:31 libiconv-dev is empty 2014-04-23 10:25:42 well, it has empty libiconv.a 2014-04-23 10:25:50 ok 2014-04-23 10:25:52 my mistake 2014-04-23 10:25:59 should have checked that before adding the conflict 2014-04-23 10:26:04 it was pulled in by avahi i think 2014-04-23 10:27:19 yeah i cant add avahi anymore 2014-04-23 10:28:50 clandmeter, try now 2014-04-23 10:29:28 thats it. 2014-04-23 10:52:42 fabled: threading is handled different in musl as in uclibc? 2014-04-23 10:54:39 i have a program that doesnt want to terminate correctly on musl, but it does on uclibc 2014-04-23 11:13:54 clandmeter, yes 2014-04-23 11:14:08 though. that sounds like atexit() usage issue 2014-04-23 11:14:20 could be some dead lock too 2014-04-23 11:39:00 fabled: does this help? http://sprunge.us/CTKh 2014-04-23 11:39:16 it refers to https://github.com/tvheadend/tvheadend/blob/master/src/timeshift/timeshift_filemgr.c#L365 2014-04-23 11:40:05 "info threads" and "thread apply all bt" 2014-04-23 11:40:08 in gdb 2014-04-23 11:41:51 http://sprunge.us/QMUa 2014-04-23 11:52:07 fabled: doesnt seem any usefull info for me. maybe its different from your side? 2014-04-23 11:54:56 well. it basically hangs waiting for the other threads. dunno why they don't terminate as expected 2014-04-23 11:55:00 sounds application error 2014-04-23 11:55:27 but it's annoying that backtrace does not work over the cancellation functions in musl 2014-04-23 11:55:36 there's some assembly that needs .cfi annotations 2014-04-23 12:45:15 arch 2014-04-23 12:45:18 argh 2014-04-23 12:45:57 alptmpfs:~# setup-timezone 2014-04-23 12:45:57 ERROR: You tried to add a non-repository package to system, but it would be lost on next reboot. Enable package caching (apk cache --help) or use --force if you know what you are doing. 2014-04-23 12:45:57 Which timezone are you in? ('?' for list) [UTC] 2014-04-23 12:45:57 'UTC' is not a valid timezone on this system 2014-04-23 12:45:57 Which timezone are you in? ('?' for list) [UTC] 2014-04-23 12:45:59 'UTC' is not a valid timezone on this system 2014-04-23 12:46:15 fabled: i'm not too happy with apk-tools trying to be smarter than me 2014-04-23 12:46:42 i suppose i have to use --force ... 2014-04-23 12:47:09 the entire idea is that i dont want this package to stay after reboot 2014-04-23 12:48:27 :) 2014-04-23 12:51:26 setup-timezone works now 2014-04-23 13:08:56 fabled: i wonder if we should upgrade binutils to 2.24 2014-04-23 13:09:13 possibly 2014-04-23 13:09:22 if we go there, we might want to consider enabling gold by default 2014-04-23 13:09:42 it's a new linker thats a lot faster then the old one 2014-04-23 13:09:45 hm yes 2014-04-23 13:10:02 i think we have some patches that needs to be rebased 2014-04-23 13:10:28 i think i'd like binutils-2.24 upgrade before we start up the v3.0 builders 2014-04-23 13:13:41 i wonder if gold breaks anything 2014-04-23 13:13:45 should not 2014-04-23 13:13:51 i think some use it as default already 2014-04-23 13:16:21 i wonder if i should apk add gzip on the builders 2014-04-23 13:16:34 gnu gzip is much faster than busybox 2014-04-23 15:00:53 hmm... they day flew by... i didnt have time for nfs 2014-04-23 17:41:43 ncopa: so a new day will come 2014-04-23 17:42:06 new day, new challenges, new chances... ;-) 2014-04-24 05:07:43 ncopa, seems bluez has failed 2014-04-24 06:13:35 on what builder? 2014-04-24 07:00:30 ncopa, bluez still failed? 2014-04-24 07:02:12 probably just ditn pick up the change and src/ existed 2014-04-24 07:02:14 i'm fixing 2014-04-24 07:03:31 ah. thanks. 2014-04-24 07:06:11 was firefox-29 released? 2014-04-24 07:08:24 no 2014-04-24 07:36:49 fabled: I am having problems figuring out what goes wrong with nfs 2014-04-24 07:37:05 i get a coredump, but I am not able to get any useful symbols 2014-04-24 07:42:39 ncopa, yes, it's a musl issue 2014-04-24 07:42:52 the syscall_cp assembly function needs .cfi annotations 2014-04-24 07:43:01 should probably fix that 2014-04-24 08:14:48 fabled: what does this mean? bigger task to do? 2014-04-24 08:17:16 ha 2014-04-24 08:17:22 it segfaults veryvery early 2014-04-24 08:17:29 i'm doing printf debugging now 2014-04-24 08:17:40 basename(argv[0]) is segfaulting... 2014-04-24 08:50:48 rebooting brb 2014-04-24 08:55:35 StarWarsFan: i think that was your fix 2014-04-24 08:55:53 :-) 2014-04-24 09:05:34 so waiting for the mirror sync... 2014-04-24 09:07:04 hm, but why is it working on x86? 2014-04-24 09:07:11 shouldn't it be the same problem there? 2014-04-24 09:07:45 depends on the implementation i suppose 2014-04-24 10:11:45 ncopa: bad news: http://bugs.alpinelinux.org/issues/2842#note-5 2014-04-24 10:34:53 StarWarsFan, ncopa, the basename patch is wrong 2014-04-24 10:35:02 musl only provides posix compliant basename() 2014-04-24 10:35:13 if the application assumes GNU version, it crashes 2014-04-24 10:36:15 hm... 2014-04-24 10:47:24 StarWarsFan, does nfsd work on x86? 2014-04-24 10:47:37 yes 2014-04-24 10:47:54 but not on x86_64? 2014-04-24 10:48:00 exactly 2014-04-24 10:48:47 StarWarsFan, it crashes on startup, or later on? 2014-04-24 10:49:02 seems it crashed on startup 2014-04-24 10:49:35 builder06:~# rc-service nfsmount start 2014-04-24 10:49:35 * Starting NFS statd ... 2014-04-24 10:49:35 * start-stop-daemon: /usr/sbin/rpc.statd is already running [ !! ] 2014-04-24 10:49:35 * ERROR: rpc.statd failed to start 2014-04-24 10:49:35 * ERROR: cannot start nfsmount as rpc.statd would not start 2014-04-24 10:49:37 builder06:~# 2014-04-24 10:49:59 but: 2014-04-24 10:50:09 builder06:~# rc-status 2014-04-24 10:50:10 ... 2014-04-24 10:50:22 rpc.statd [ stopped ] 2014-04-24 10:50:24 ... 2014-04-24 10:50:34 nfsmount [ stopped ] 2014-04-24 10:50:53 perhaps it's tale 2014-04-24 10:51:03 /etc/init.d/rpc.statd zap 2014-04-24 10:51:04 /etc/init.d/rpc.statd start 2014-04-24 10:51:32 builder06:~# /etc/init.d/rpc.statd zap 2014-04-24 10:51:32 * Manually resetting rpc.statd to stopped state 2014-04-24 10:51:32 builder06:~# /etc/init.d/rpc.statd start 2014-04-24 10:51:33 * Starting NFS statd ... 2014-04-24 10:51:36 * start-stop-daemon: /usr/sbin/rpc.statd is already running [ !! ] 2014-04-24 10:51:38 * ERROR: rpc.statd failed to start 2014-04-24 10:51:40 builder06:~# 2014-04-24 10:52:13 btw, i've rebootet the machine to double check, no difference... 2014-04-24 10:52:37 I also had issues with nfs on musl, but on arm. lots of errors in syslog. 2014-04-24 10:53:44 /usr/sbin/rpc.statd -F -d 2014-04-24 11:00:54 builder06:~# /usr/sbin/rpc.statd -F -d 2014-04-24 11:00:54 rpc.statd: Version 1.2.9 starting 2014-04-24 11:00:54 rpc.statd: Flags: No-Daemon Log-STDERR TI-RPC 2014-04-24 11:00:54 sm-notify: Version 1.2.9 starting 2014-04-24 11:00:54 sm-notify: No hosts to notify; exiting 2014-04-24 11:00:55 rpc.statd: Failed to read /var/lib/nfs/state: Address in use 2014-04-24 11:00:57 rpc.statd: Initializing NSM state 2014-04-24 11:00:59 rpc.statd: Local NSM state number: 3 2014-04-24 11:01:01 rpc.statd: Failed to unregister program 100024, version 1 2014-04-24 11:01:03 rpc.statd: Running as root. chown /var/lib/nfs to choose different user 2014-04-24 11:01:06 rpc.statd: Failed to register (statd, 1, udp) 2014-04-24 11:01:08 rpc.statd: Failed to register (statd, 1, tcp) 2014-04-24 11:01:10 rpc.statd: Failed to register (statd, 1, udp6) 2014-04-24 11:01:12 rpc.statd: Failed to register (statd, 1, tcp6) 2014-04-24 11:01:14 rpc.statd: failed to create RPC listeners, exiting 2014-04-24 11:01:16 builder06:~# 2014-04-24 11:04:05 rpc.statd: Failed to read /var/lib/nfs/state: Address in use 2014-04-24 11:04:44 soudns like something is listening laready 2014-04-24 11:05:33 i have no idea but how about this: 2014-04-24 11:05:38 rpcbind [ started ] 2014-04-24 11:06:12 see all services here: http://sprunge.us/VMbG 2014-04-24 11:08:02 hmm 2014-04-24 11:08:06 rpcbind starts, but exists 2014-04-24 11:08:11 ncopa-desktop:~$ sudo exportfs 2014-04-24 11:08:11 10.65.65.0/24 2014-04-24 11:08:17 i think it's rpcbind crashing 2014-04-24 11:08:23 ncopa-desktop:~$ sudo ps xa | grep rpc 2014-04-24 11:08:24 4290 ? S 0:00 /sbin/rpcbind -w 2014-04-24 11:08:26 it runs here... 2014-04-24 11:10:47 builder06:~# ps xa | grep rpc 2014-04-24 11:10:47 1459 ldap 0:00 /sbin/rpcbind -w 2014-04-24 11:10:47 1475 root 67:55 /usr/sbin/rpc.statd --no-notify 2014-04-24 11:10:47 1494 root 0:00 /usr/sbin/rpc.mountd 2014-04-24 11:10:47 1504 root 0:00 [rpciod] 2014-04-24 11:10:48 1996 root 0:00 grep rpc 2014-04-24 11:10:51 builder06:~# 2014-04-24 11:10:55 but hum... i cannot mount 2014-04-24 11:12:41 was there some special option needed to be given to enable nfsv2 or similar? 2014-04-24 11:15:10 seems like there is an nfs-utils-1.3.0 out too 2014-04-24 11:15:55 StarWarsFan: does rpcinfo give any info? 2014-04-24 11:16:27 builder06:~# rpcinfo 2014-04-24 11:16:27 rpcinfo: can't contact rpcbind: RPC: Remote system error - Connection refused 2014-04-24 11:16:27 builder06:~# 2014-04-24 11:29:29 yes 2014-04-24 11:29:35 rpc.statd seems to be broke 2014-04-24 11:29:43 ncopa-desktop daemon.err rpc.statd[4310]: my_svc_run() - select: Invalid argument 2014-04-24 11:34:18 yes thats the same issue i had on arm 2014-04-24 14:18:14 whoo, my first commit since month 2014-04-24 14:37:45 nice to have you back! :) 2014-04-24 14:40:33 [20766.105651] traps: rpc.mountd[8649] trap stack segment ip:73b81930885e sp:7e64c2186380 error:0 2014-04-24 14:40:33 [20766.105660] grsec: Invalid alignment/Bus error occurred at (nil) in /usr/sbin/rpc.mountd[rpc.mountd:8649] uid/euid:0/0 gid/egid:0/0, parent /bin/busybox[init:1] uid/euid:0/0 gid/egid:0/0 2014-04-24 14:41:47 ok, let's see if everything builds before I push a bunch of upgrades 2014-04-24 14:42:30 ok, i'm making progress with nfs 2014-04-24 14:42:35 statd now runs 2014-04-24 14:42:45 rpc.mountd give bus error 2014-04-24 16:23:29 So the ntp thing looks more difficult than expected... 2014-04-25 07:44:42 ncopa: can i backport btfrs-utils to 2.7? im using it with lxc. 2014-04-25 07:47:28 does it introduce any incompat changes? 2014-04-25 07:47:40 oh, we dont have btfrs-utils at all? 2014-04-25 07:47:44 in v2.7? 2014-04-25 07:47:58 if we dont have any btrfs-utils, then please go ahead and backport 2014-04-25 07:48:16 what i dont want is that v2.7 gets unexpected surprises 2014-04-25 07:48:33 they should be able to do apk upgrade without worring if things will work after that or not 2014-04-25 07:49:06 we have it in 2.7 2014-04-25 07:49:09 but its old... 2014-04-25 07:50:57 ncopa: i thought that wouldnt matter if its in backports? 2014-04-25 07:55:51 will it break compatibility with the old in some way? 2014-04-25 07:55:58 if not, then i'd prever keep it in main 2014-04-25 07:56:13 makes it much easier to do sec fixes etc 2014-04-25 07:56:28 it turns out that doing sec fixes in backports/ is a pain 2014-04-25 07:56:48 as you cannot chererypick 2014-04-25 08:28:16 royger: hi 2014-04-25 08:29:07 royger: how do i debug hvm never executing the bios 2014-04-25 08:31:13 kaniini: hypervisor built with debug=yes and boot with "guest_loglvl=all loglvl=all" 2014-04-25 08:31:39 royger: anything less than debug=yes that i can do? 2014-04-25 08:32:01 kaniini: I think "guest_loglvl=all loglvl=all" 2014-04-25 08:32:11 should still work even with a non-debug hypervisor 2014-04-25 08:32:42 and will allow you to see the output of early bios in the hypervisor console (xl dmesg) 2014-04-25 08:33:09 okay 2014-04-25 08:37:38 royger: i will debug it. 2014-04-25 08:37:47 royger: but it appears hvm is broken on musl 2014-04-25 08:37:59 royger: any thoughts on why that could be 2014-04-25 08:38:16 i'm thinking hairyness in the ACPI table 2014-04-25 08:38:44 i made a change, i dont know if you noticed it 2014-04-25 08:40:47 I see, musl-support.patch 2014-04-25 08:41:38 I'm not familiar at all with this ACPI crap, but the bios shouldn't use it I think 2014-04-25 08:41:55 any output on the Qemu log file? 2014-04-25 08:42:15 no 2014-04-25 08:43:13 if ASCII64('R','S','D',' ','P','T','R',' ') == 0x2052545020445352LL it should be fine 2014-04-25 08:44:11 did the loglevel boot options make Xen spit some messages? 2014-04-25 08:46:26 ACTION -> coffe 2014-04-25 08:48:58 nfs and musl doesnt play well either... 2014-04-25 08:49:35 musl is not happy with ugly code 2014-04-25 08:53:21 (XEN) HVM4: HVM Loader 2014-04-25 08:53:22 (XEN) HVM4: Detected Xen v4.3.2 2014-04-25 08:53:24 (XEN) HVM4: Xenbus rings @0xfeffc000, event channel 10 2014-04-25 08:53:51 thats it 2014-04-25 08:53:59 now it's just using 100% CPU in the guest 2014-04-25 08:55:37 fabled: is this needed with musl? http://git.alpinelinux.org/cgit/aports/tree/main/binutils/binutils-ld-fix-static-linking.patch 2014-04-25 08:55:44 i assume yes? 2014-04-25 08:56:24 ncopa, i think that is needed due to gentoo gcc hardening patches 2014-04-25 08:57:52 I should rebase it for 2.24 then 2014-04-25 09:00:19 this is meaningful: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=patch;h=a621549d28266198cfd5fd9360d63ff565acaeff 2014-04-25 09:00:23 ...not 2014-04-25 09:00:24 hmm 2014-04-25 09:00:27 this is meaningful 2014-04-25 09:00:30 because 2014-04-25 09:00:46 the next line should be "System requested SeaBIOS" 2014-04-25 09:01:01 lots of those commits "daily update" 2014-04-25 09:01:08 init_hypercalls() -> pass 2014-04-25 09:01:31 so it fails, either in xenbus_setup() or detect_bios() 2014-04-25 09:01:59 xenbus setup printf() Xenbus rings @0xfeffc000, event channel 10 right before exiting though 2014-04-25 09:02:02 so it doesnt fail there 2014-04-25 09:02:22 so that takes us back to detect_bios() 2014-04-25 09:03:09 which means, we either fail at 2014-04-25 09:03:15 http://code.metager.de/source/xref/xen/tools/firmware/hvmloader/hvmloader.c#226 2014-04-25 09:03:17 here 2014-04-25 09:03:19 or 2014-04-25 09:03:25 http://code.metager.de/source/xref/xen/tools/firmware/hvmloader/hvmloader.c#228 2014-04-25 09:03:27 there 2014-04-25 09:04:24 i think 228 is more likely 2014-04-25 09:04:29 because PV works fine 2014-04-25 09:05:04 add a printf("DEBUG"); ? 2014-04-25 09:08:16 yep, seems to be the solution 2014-04-25 09:08:29 kaniini: printk and figure out exactly were it is failing :( 2014-04-25 09:09:23 you mean printf 2014-04-25 09:09:24 but yes 2014-04-25 09:16:25 fabled: did we have any issues with static linking currently? 2014-04-25 09:17:15 wait, is hvmloader a kernel 2014-04-25 09:17:19 derp 2014-04-25 09:17:31 fabled: i think i have found a place where *crtend*.o was missing 2014-04-25 09:23:55 (XEN) HVM7: HVM Loader 2014-04-25 09:23:57 (XEN) HVM7: Detected Xen v4.3.2 2014-04-25 09:23:59 (XEN) HVM7: Trying to set up Xen bus! 2014-04-25 09:24:01 (XEN) HVM7: Xenbus rings @0xfeffc000, event channel 10 2014-04-25 09:24:03 (XEN) HVM7: Gonna try to read from xenstore! 2014-04-25 09:24:06 grumble 2014-04-25 09:24:40 so it happens in http://code.metager.de/source/xref/xen/tools/firmware/hvmloader/hvmloader.c#226 ? 2014-04-25 09:25:01 i wonder if i ahouls enable glod by default... 2014-04-25 09:25:50 gold* 2014-04-25 09:27:13 kaniini: it basically gets stuck trying to read from xenstore then? 2014-04-25 09:32:40 http://paste2.org/GKapOV5d 2014-04-25 09:32:49 slotting in tons of debug code slows it down 2014-04-25 09:33:21 and it kinda works 2014-04-25 09:35:09 ... except for the triple fault :) 2014-04-25 09:35:23 this also looks suspicious: CPU speed is 0 MHz 2014-04-25 09:35:58 this smells more of a toolchain regression 2014-04-25 09:36:02 than musl 2014-04-25 09:36:13 i do not see how musl would even affect this code 2014-04-25 09:36:50 anyway 2014-04-25 09:36:53 this is a pretty boring machine 2014-04-25 09:36:56 E5-2680v2 2014-04-25 09:39:10 for shits and giggles, since this is a kernel 2014-04-25 09:39:15 lets try using an old hvmloader 2014-04-25 09:40:42 so 2014-04-25 09:40:50 you're not going to like my answer for that one 2014-04-25 09:40:57 hvmloader from about 3 months ago 2014-04-25 09:41:00 boots fine 2014-04-25 09:41:24 compiled with? 2014-04-25 09:41:38 who knows 2014-04-25 09:41:41 lets find out 2014-04-25 09:43:50 /usr/lib/xen/boot/hvmloader is owned by xen-4.3.1-r1 2014-04-25 09:43:55 HMMMMMMM 2014-04-25 09:44:00 i believe this is compiled with gcc 4.7! 2014-04-25 09:44:50 but it's not 2014-04-25 09:44:52 localhost:/usr/lib/xen/boot# strings ./hvmloader | grep GCC 2014-04-25 09:44:53 GCC: (Alpine 4.8.2) 4.8.2 2014-04-25 09:44:55 hmm! 2014-04-25 09:45:08 *but* 2014-04-25 09:45:10 on the new one 2014-04-25 09:46:14 http://paste2.org/Bj7pdkJ4 2014-04-25 09:46:17 something changed 2014-04-25 09:46:24 royger: ^ 2014-04-25 09:47:09 wait no 2014-04-25 09:47:13 that's just debug stuff 2014-04-25 09:48:05 kaniini: if they are compiled using the same gcc, a binary diff might shed some light on this 2014-04-25 09:50:21 kaniini: just for curiosity, why did you change ASCII64, it seems like it should work OK (or else ASCII32 doesn't work also) 2014-04-25 09:53:00 ASCII64 threw a compile error 2014-04-25 09:53:12 if you revert it, you'll see 2014-04-25 09:53:24 in the meantime i just pushed out the old hvmloader blob 2014-04-25 09:54:09 that said, i am pretty certain gcc has changed between xen-4.3.1-r1 and now 2014-04-25 09:58:51 royger: i suspect something relating to the atomics code 2014-04-25 09:59:02 which are headers provided by GCC 2014-04-25 10:00:04 lets see 2014-04-25 10:00:40 fabled: getconf doesnt support LONG_BIT? 2014-04-25 10:00:49 clandmeter, no, not atm. 2014-04-25 10:01:04 someone else asked about it too 2014-04-25 10:01:09 should probably add it to both: musl and getconf 2014-04-25 10:01:24 so, xen 4.3.1-r1 was at 2013-11-12 10:13:01 (UTC) 2014-04-25 10:01:42 older than i thought 2014-04-25 10:03:05 http://git.alpinelinux.org/cgit/aports/commit/main/gcc/APKBUILD?id=e89835b7d45a362bc47fee45c68102683921a761 2014-04-25 10:03:11 i wonder if this is the regression! 2014-04-25 10:04:39 mostly that one sticks out 'cause the others about Ada 2014-04-25 10:04:44 which obviously has nothing to do with it 2014-04-25 10:04:55 i think it fixes a regression 2014-04-25 10:05:11 we were supposed to do relro by default 2014-04-25 10:05:17 yes 2014-04-25 10:05:21 i am thinking perhaps 2014-04-25 10:05:25 but at some point it got disabled 2014-04-25 10:05:28 hvmloader needs to be compiled -fno-relro 2014-04-25 10:05:31 or whatever the flag is 2014-04-25 10:05:41 sounds plausible yes 2014-04-25 10:05:56 i'll try it when i wake up 2014-04-25 10:06:17 i migrated like 60 machines to alpine 3.x earlier 2014-04-25 10:06:21 never doing that again 2014-04-25 10:06:51 the alpine upgrade part wasn't bad 2014-04-25 10:06:59 the upgrading the SSD cache device part was bad 2014-04-25 10:11:52 it builds hvmloader with: -mno-tls-direct-seg-refs -nopie -fno-stack-protector -fno-exceptions -fno-builtin -msoft-float 2014-04-25 10:12:01 these seem correct 2014-04-25 10:14:14 anyway, goodnight or something 2014-04-25 10:15:37 royger: my other theory is perhaps there is a type mismatch somewhere 2014-04-25 10:15:56 royger: i could swear that hvmloader was including musl's definition of uint64_t ;) 2014-04-25 10:17:19 kaniini: curious how alpine always have problems with hvmloader, thank good it works just fine on FreeBSD :) 2014-04-25 10:17:30 s/good/god 2014-04-25 12:17:02 fcolista: around? 2014-04-25 12:17:12 yes 2014-04-25 12:17:14 hre i am 2014-04-25 12:17:36 hi clandmeter 2014-04-25 12:17:38 hi 2014-04-25 12:17:40 perl-io-tty 2014-04-25 12:17:45 you added right? 2014-04-25 12:17:55 i think so 2014-04-25 12:18:06 in testing 2014-04-25 12:18:14 shoudnt it depend on perl? 2014-04-25 12:18:34 you meand in depends array right? 2014-04-25 12:18:38 *mean 2014-04-25 12:19:14 'cause i needed as dependency for netdot 2014-04-25 12:19:19 i mean does it depend on perl? 2014-04-25 12:19:25 any perl code in it? 2014-04-25 12:19:46 dunno clandmeter 2014-04-25 12:19:54 i only needed it as dependency 2014-04-25 12:19:59 didn't look on that 2014-04-25 12:20:08 but i suppose the answer is yes 2014-04-25 12:20:09 its a perl module 2014-04-25 12:20:24 i guess it wont work without perl :) 2014-04-25 12:20:39 not all perl module have perl in "depends" 2014-04-25 12:20:46 perl-io-tty has perl-dev in makedepends 2014-04-25 12:20:56 that is neede for compilation 2014-04-25 12:21:03 si 2014-04-25 12:21:04 so 2014-04-25 12:21:13 yes to build it 2014-04-25 12:21:21 im taking about runtime 2014-04-25 12:21:22 to use it surely needs perl 2014-04-25 12:21:53 i just installed mosh and it pulled in perl-io-tty 2014-04-25 12:21:57 but not perl 2014-04-25 12:22:16 does mosh works? 2014-04-25 12:22:27 i dont know, could be. 2014-04-25 12:22:54 but even if it does work. this doesnt seem right. 2014-04-25 12:23:38 I understand your point 2014-04-25 12:24:09 just wondering that this means that all perl-module needs perl 2014-04-25 12:24:50 i would assume its by default by the helper script to create the apkbuild 2014-04-25 12:25:19 right. But it only adds perl-dev 2014-04-25 12:26:05 I'm not sure that having a library includes the installation of the interpreter, perhaps perl is quite big 2014-04-25 12:26:19 well, it should can the src and see if it has any perl scripts and add perl if found. 2014-04-25 12:26:54 hmm, what happened to /script in irssi? (I installed irssi-perl) 2014-04-25 12:27:13 well, perl-io-tty doesn't have perl script 2014-04-25 12:27:17 but i like your idea 2014-04-25 12:27:27 uggedal: i just splitted it. 2014-04-25 12:27:50 uggedal: something i missed? 2014-04-25 12:28:04 fcolista: i do see perl scripts in perl-io-tty 2014-04-25 12:28:04 clandmeter: but shouldn't irssi-perl give me script support? 2014-04-25 12:28:13 it should 2014-04-25 12:28:16 did you load the modules? 2014-04-25 12:28:30 clandmeter: no 2014-04-25 12:28:33 :) 2014-04-25 12:29:02 clandmeter, test.t 2014-04-25 12:29:29 uggedal: i never use scripting with irssi 2014-04-25 12:29:42 but i build it as module and loaded it. it loaded just fine. 2014-04-25 12:30:21 uggedal: if it still causes issues, let me know and ill desplit it. 2014-04-25 12:31:04 fcolista: Installing /home/clandmeter/aports/testing/perl-io-tty/pkg/perl-io-tty/usr/lib/perl5/vendor_perl/IO/Pty.pm 2014-04-25 12:32:14 clandmeter, all pm contains perl codes 2014-04-25 12:32:25 so 2014-04-25 12:32:40 clandmeter: printf 'load libperl_core\nload libfe_perl\n' > ~/.irssi/startup fixed it 2014-04-25 12:32:44 should we add "perl" as dependency of all perl-$modules ? 2014-04-25 12:33:19 how can you use it without perl? 2014-04-25 12:34:10 ok, so the answer is yes 2014-04-25 12:35:18 yes its yes 2014-04-25 12:35:28 look at other perl modules, they all have depend=perl 2014-04-25 12:35:54 not really 2014-04-25 12:36:05 example? 2014-04-25 12:36:17 perl-universal-moniker 2014-04-25 12:36:28 perl-yaml 2014-04-25 12:36:34 check main please 2014-04-25 12:36:46 ok 2014-04-25 12:37:11 i supposed we were talking about testing, since perl-io-tty is in testing. It's ok for me. 2014-04-25 12:37:23 I can add perl in depends and move it in main 2014-04-25 12:37:47 it doesnt matter if its testing or main 2014-04-25 12:38:06 it should have it anyways. but code in testing is in testing for a reason. 2014-04-25 12:38:27 yes please move it to main 2014-04-25 12:38:34 i will move mosh to main too 2014-04-25 12:38:38 and its deps 2014-04-25 12:38:52 k 2014-04-25 12:39:08 im getting crazy from my home router which keeps clearing its nat table after x time. 2014-04-25 12:39:51 i wonder how well this chrome plugin works as ssh client. 2014-04-25 12:41:59 seems to work 2014-04-25 12:47:03 fcolista: thx! 2014-04-25 12:47:40 thx to you clandmeter 2014-04-25 13:27:50 I was reading the apk-tools source code.. And saw an "apk_" reference. Do we still use it? 2014-04-25 13:32:18 we dont, but I think the code has compat for it 2014-04-25 13:32:24 that could probably be removed now 2014-04-25 13:32:40 it means that you can ln -s apk apk_add 2014-04-25 13:32:45 and then run apk_add 2014-04-25 14:21:18 according to commit msg, i should go home :| 2014-04-25 14:24:12 ncopa: setup-timezone is not musl compat? 2014-04-25 14:25:28 ah it is :) 2014-04-25 14:31:36 clandmeter, yes, it was fixed one or two days ago 2014-04-25 14:37:52 clandmeter: with lates snapshot iso it should be ok 2014-04-26 10:59:25 anybody know if abuild also automaticaly scans subpkgdirs for depends? I remember it does, but currently im having issues. 2014-04-26 20:04:40 fabled: thx! 2014-04-26 20:07:53 fabled: looks like finaly i have correct chars in irssi because of musl :) 2014-04-26 20:19:45 ACTION just released refresh of ACF to clean up HTML views 2014-04-26 20:20:07 vkrishn and I are also working to get a jquery-mobile based skin working and released 2014-04-26 20:20:44 basic functionality of new acf- packages is still the same 2014-04-26 20:20:51 but please let me know of any bugs found 2014-04-27 06:56:14 for some reason my messages are not appearing on mailing list 2014-04-27 06:56:20 think it's a problem with my email 2014-04-28 07:16:08 morning 2014-04-28 07:16:19 ncopa: i have an apkbuild issue 2014-04-28 07:16:25 hi 2014-04-28 07:16:31 subpkg's are not scanned for deps? 2014-04-28 07:17:03 when? 2014-04-28 07:17:16 they are scanned post build pre package 2014-04-28 07:17:30 and only runtime deps are scanned 2014-04-28 07:17:49 build time deps for subpackages are not 2014-04-28 07:17:50 i splitted a package 2014-04-28 07:18:02 but then the runtime deps of those subpkgs are not scanned. 2014-04-28 07:18:54 sounds weird 2014-04-28 07:19:00 i cannot see why they shouldnt 2014-04-28 07:19:11 i guess then this is wrong? http://git.alpinelinux.org/cgit/aports/tree/main/mosh/APKBUILD 2014-04-28 07:19:57 why should it be wrong? 2014-04-28 07:20:27 try to install mosh-server 2014-04-28 07:20:30 and run it 2014-04-28 07:20:37 lots of symbols missing 2014-04-28 07:20:56 its missing protobuf 2014-04-28 07:21:03 which is in buildeps 2014-04-28 07:21:42 Error loading shared library libprotobuf.so.8: No such file or directory (needed by /usr/bin/mosh-server) 2014-04-28 07:21:42 Error relocating /usr/bin/mosh-server: _ZNK6google8protobuf8internal12ExtensionSet24SerializeWithCachedSizesEiiPNS0_2io17CodedO 2014-04-28 07:21:51 and lots simliar 2014-04-28 07:22:01 yes, thats protobuf missing 2014-04-28 07:22:19 0x0000000000000001 (NEEDED) Shared library: [libprotobuf.so.8] 2014-04-28 07:22:57 ncopa-desktop:~$ apk info -R mosh-server 2014-04-28 07:22:57 mosh-server-1.2.4-r3 depends on: 2014-04-28 07:23:52 probably im doing something worng, but i dont know what. 2014-04-28 07:24:03 no, this looks like a bug 2014-04-28 07:25:16 I was about adding manual depends again, but i felt like going back in time :) 2014-04-28 07:25:31 we shouldnt do that 2014-04-28 07:25:37 we should try fix why it was not autodetected 2014-04-28 07:25:40 and try fir that 2014-04-28 07:25:56 readelf find the NEEDED 2014-04-28 07:26:10 but i wonder why it was not added to the depends in apk 2014-04-28 07:27:16 >>> mosh-server*: Tracing dependencies... 2014-04-28 07:27:16 >>> mosh-server*: Package size: 280.0 KB 2014-04-28 07:27:16 >>> mosh-server*: Compressing data... 2014-04-28 07:27:16 >>> mosh-server*: Create checksum... 2014-04-28 07:27:16 >>> mosh-server*: Create mosh-server-1.2.4-r3.apk 2014-04-28 07:27:55 ha 2014-04-28 07:27:57 i know why 2014-04-28 07:28:10 it says arch="noarch" 2014-04-28 07:28:36 so abuild thinks there is no point in searching for shared elf deps 2014-04-28 07:28:42 not for subpkgs? 2014-04-28 07:29:40 i think it does not realize that the subackages are arch specific 2014-04-28 07:29:47 ok, so the funct is just stops at main arch 2014-04-28 07:30:08 hm 2014-04-28 07:30:11 -is 2014-04-28 07:30:21 i think this should have worked... 2014-04-28 07:30:25 no 2014-04-28 07:30:31 it cannot work 2014-04-28 07:30:53 it does not scan for deps when running split function 2014-04-28 07:30:58 it is in separate step 2014-04-28 07:31:21 the arch=all in subpkgs is only set in splitfunc context 2014-04-28 07:31:39 so when splitting the package it knows that its a arch=all 2014-04-28 07:31:51 but then it exits the split func, and forgets that 2014-04-28 07:32:16 and then when tracing deps, it thinks it all is noarch 2014-04-28 07:32:44 in practice, i think this means you cannot have different arch settings for different subpackages 2014-04-28 07:33:57 you can but just not noarch and then all? 2014-04-28 07:34:47 i can set it to all and subpkg to noarch. just not vice versa? 2014-04-28 07:34:59 i think so yes 2014-04-28 07:35:09 I have been thinking of a new APKBUILD format 2014-04-28 07:36:23 something that is better in handling subpackages 2014-04-28 07:36:47 something similar rpm's spec file 2014-04-28 07:36:57 or similar sabotage linux's format 2014-04-28 07:37:30 but if we switch format, then a requirement is that we can convert our current APKBUILD format with script 2014-04-28 07:40:55 moin 2014-04-28 07:41:27 ncopa: i like the way our format is now. its simple and clear, thats what i dont like from rpm's format (but maybe just because i dont read them that much) 2014-04-28 07:42:06 it wouldnt be that different 2014-04-28 07:49:02 im thinking something like this: https://gist.github.com/ncopa/11364645 2014-04-28 07:50:34 there are 3 things i'd like to fix from current way we do it 2014-04-28 07:51:21 1) run the script parts as sh -x (so we dont need || return 1 for every line) 2014-04-28 07:51:23 and parse it with lua? 2014-04-28 07:51:53 2) be able to set variables for subpackages *before* the split is actually happening 2014-04-28 07:51:57 3) parse with lua 2014-04-28 07:52:59 as it is right now, there i no way to know the depends, pkgdesc or any other variable before the split func is actually executed 2014-04-28 07:54:10 ok, makes sence. 2014-04-28 07:54:33 this format doesnt look too bad. 2014-04-28 07:58:28 alternatively something like this: https://gist.github.com/ncopa/11364645 2014-04-28 07:58:32 or a combination 2014-04-28 07:58:46 eg, define [sub mysybname] 2014-04-28 07:58:55 and have a split=[[ shellcode ]] 2014-04-28 07:59:58 well its just ideas so far 2014-04-28 08:00:26 in any case, we dont want rewrite 1700 APKBUILDs manually... 2014-04-28 08:03:16 actually leaving testing behind doesn't sound that bad 2014-04-28 08:08:56 :) 2014-04-28 08:11:42 I mean… we don't have man power or willigness to clean it up 2014-04-28 08:12:30 so maybe a fresh start and a bit more strict policy about it would be better 2014-04-28 08:21:11 im mostly worried about whats in main 2014-04-28 08:21:40 hm 2014-04-28 08:21:56 why not support both formats 2014-04-28 08:22:03 so, we shoudl have something that can either pull int he APKBUILD as is 2014-04-28 08:22:05 that way APKBUILDs can be ported over 2014-04-28 08:22:18 and then over time we clean them up 2014-04-28 08:22:44 kaniini: maybe we coudl do the initial import with a script 2014-04-28 08:22:51 and then over time clean up 2014-04-28 08:22:53 or similar 2014-04-28 08:23:01 hm 2014-04-28 08:23:37 support 2 different formats in parallel can be burdensome i think 2014-04-28 08:24:32 actually, not necessarily 2014-04-28 08:24:37 i think it can be doable 2014-04-28 08:24:46 to support 2 formats in parallel 2014-04-28 08:43:29 ahahaahaha 2014-04-28 08:43:41 sorry: wrong window :) 2014-04-28 08:43:47 :) 2014-04-28 09:49:26 hm, is there any chance to get nfs running again in the next days? 2014-04-28 09:56:16 StarWarsFan: it was harder than I thought 2014-04-28 09:56:26 i found and fixed a couple of errors with nfs 2014-04-28 09:56:31 but it still dont run 2014-04-28 09:56:47 i will continu working on it today 2014-04-28 10:09:14 that would be cool 2014-04-28 12:04:08 i cannot find out why its not working :-( 2014-04-28 12:04:15 apparently nfsd is running 2014-04-28 12:04:22 rpc.statd is running 2014-04-28 12:04:26 rpcbind is running 2014-04-28 12:04:43 rpc.mountd is running too 2014-04-28 12:04:58 but still 2014-04-28 12:05:00 $ sudo rpcinfo -p 2014-04-28 12:05:00 No remote programs registered. 2014-04-28 12:29:42 strange... 2014-04-28 12:40:58 let me know if i should test something... 2014-04-28 12:55:23 i think i know what goes wrong 2014-04-28 12:55:46 its getaddrinfo again 2014-04-28 12:55:58 getaddrinfo and getservbyname 2014-04-28 13:06:33 ok i am making progress 2014-04-28 13:06:54 afer working around getservbyname(), mountd will segfault again 2014-04-28 13:09:10 as long as a segfault is a "progress" ;-) 2014-04-28 13:09:18 well 2014-04-28 13:09:25 but i know what you mean, never mind :-) 2014-04-28 13:09:35 just kiddin... 2014-04-28 13:09:38 ;-) 2014-04-28 13:09:41 atleast rpcbind now reconizes remotes 2014-04-28 13:09:51 nice 2014-04-28 13:09:53 there have been a number of errors 2014-04-28 13:10:04 and i am fixing them one by one 2014-04-28 13:10:28 i think the current nfs-utils in edge sill not segfault 2014-04-28 13:10:33 will* 2014-04-28 13:10:39 but you wont be able to mount either 2014-04-28 13:10:58 due to rpcbind not beeing able to find the service "portmapper" 2014-04-28 13:11:25 i changed it to "sunrpc" and now rpcbind will set up tcp and udp 2014-04-28 13:12:00 I was also able to get contact with the nfs server: 2014-04-28 13:12:09 alp27:~# mount -o nfsvers=2 10.65.65.1:/var/cache/distfiles /mnt 2014-04-28 13:12:09 mount.nfs: requested NFS version or transport protocol is not supported 2014-04-28 13:12:17 so its progress 2014-04-28 13:12:22 but now mountd segfautls again 2014-04-28 13:12:41 (after enabling nfs v2 in nfsd that is...) 2014-04-28 13:21:43 ok 2014-04-28 13:21:51 mount.nfs is also segfaulting 2014-04-28 13:21:58 i need cofe 2014-04-28 13:29:46 no coffe.. :-( 2014-04-28 13:29:58 but i managed to get mount.nfs working 2014-04-28 13:30:20 so now i can mount a v2.7 export on edge 2014-04-28 13:44:06 :-) 2014-04-28 13:44:19 ACTION brings a huge coffe-cup 2014-04-28 13:44:31 !coffee 2014-04-28 13:44:53 hm, the bot did not know what's a real requirement... ;-) 2014-04-28 13:50:45 it might be that it works now 2014-04-28 13:50:55 but im not sure 2014-04-28 14:09:17 ok, will check later today... 2014-04-28 14:17:57 it doesnt 2014-04-28 14:18:02 i think it doesn 2014-04-28 14:18:04 but not sure 2014-04-28 14:18:14 we are closer anyway 2014-04-28 14:59:15 ncopa: vim broken in edge? 2014-04-28 15:00:22 ncopa: http://sprunge.us/UTdb 2014-04-28 15:05:05 ncopa: no, still not working 2014-04-28 15:05:05 see http://bugs.alpinelinux.org/issues/2842#note-6 2014-04-28 15:12:25 clandmeter: dunno. i have to go home. is it x86 or x86_64? 2014-04-28 15:12:34 i can look at it tm 2014-04-29 06:00:27 morning 2014-04-29 06:00:44 ncopa, others, has any one tested LVM on edge/musl ? 2014-04-29 06:00:54 morning 2014-04-29 06:01:05 Mp5shooter's LUKS setup uses LVM. So I'm wondering if it's LVM failing, or cryptomapper. 2014-04-29 06:01:06 I use lvm on my desktop 2014-04-29 06:01:26 did i install it as new. or upgrade from old edge? 2014-04-29 06:01:31 s/i/you/ 2014-04-29 06:01:34 i *think* i have tried set up a luks partition too 2014-04-29 06:01:43 my desktop was upgraded 2014-04-29 06:02:02 but i think i have cryptsetup a new too, just to test 2014-04-29 06:02:13 he upgraded right? 2014-04-29 06:02:27 he upgraded, yes 2014-04-29 06:02:27 i wonder if his /etc/mkinitfs/ stuff is correct 2014-04-29 06:02:49 I have a v2.7 qemu setup with root on crypto 2014-04-29 06:03:00 i could try upgrade it (thanks to qemu disk snapshot...) 2014-04-29 06:04:09 mmm 2014-04-29 06:04:22 that could be possible the mkinitfs stuff was changed quite a bit 2014-04-29 06:04:28 ok 2014-04-29 08:07:03 clandmeter ncopa i yesterday install vim on edge-musl lxc and did not have these IO-Error you posted 2014-04-29 08:08:17 follow up from log: http://sprunge.us/UEIX 2014-04-29 08:10:49 crow: which repos do you have in use? 2014-04-29 08:19:07 clandmeter http://sprunge.us/gECU 2014-04-29 08:20:19 crow: x86? 2014-04-29 08:20:59 clandmeter yes x86 ( Linux edgemusl 3.10.37-0-grsec #1-Alpine SMP Wed Apr 16 14:44:08 UTC 2014 i586 Linux ) 2014-04-29 08:21:19 im using 64 2014-04-29 08:26:43 clandmeter ok then meybe there is something wrong 2014-04-29 08:44:54 ERROR: http://nl.alpinelinux.org/alpine/v2.7/main: Bad address 2014-04-29 08:44:54 WARNING: Ignoring APKINDEX.6e4ea7fb.tar.gz: No such file or directory 2014-04-29 08:45:13 friend is getting that after installing with alpine-2.7.6-x86.iso 2014-04-29 08:46:37 no dns? 2014-04-29 08:51:47 seems like heh 2014-04-29 08:53:44 he selected static ip, can i change that within live system 2014-04-29 08:55:56 ncopa: vim pkg is broken on nl.a.o 2014-04-29 08:56:04 should just bump pkgrel? 2014-04-29 08:58:53 x86? 2014-04-29 08:58:56 or x86_64 2014-04-29 09:01:18 weird, yes 2014-04-29 09:01:23 vim is modified 2014-04-29 09:01:35 filesize is identical 2014-04-29 09:01:45 but checksum differs 2014-04-29 09:04:10 i removed the bad file 2014-04-29 09:07:03 x86 was fine yesterday 2014-04-29 09:07:18 it still is i guess 2014-04-29 09:09:37 its x86_64 2014-04-29 09:09:47 i'm glad we sign the packages :) 2014-04-29 13:01:13 abuild prepare is not documented 2014-04-29 13:02:57 http://sprunge.us/ZgPU 2014-04-29 13:04:33 crow: care to file a bug about it so i dont forget it? bugs.alpinelinux.org 2014-04-29 13:26:16 ncopa sure after i finish building first package :) 2014-04-29 13:28:04 ncopa seems alpinelinux.org cert expired: The certificate expired on 26.04.2014 00:30. The current time is 29.04.2014 15:27. 2014-04-29 13:29:05 bugs.alpinelinux.org one 2014-04-29 13:38:08 ncopa bug filed https://bugs.alpinelinux.org/issues/2878 2014-04-29 13:40:31 whops... clandmeter, jbilyk ^^^ 2014-04-29 13:41:08 ncopa: we talked about this last week with nangel I thought and we weren't going to renew the startcom or startssl (whatever it's called) and go with a self-signed cert 2014-04-29 13:41:14 or was that for another a.o box? 2014-04-29 13:41:34 this was was issued by startssl.com 2014-04-29 13:42:02 ncopa: we can grab a new startssl one if you want 2014-04-29 13:42:19 (and maybe add an ssl cert expiry check) 2014-04-29 13:42:41 i dont have strong opinions there 2014-04-29 13:42:51 would actually be nice wiht a slef generated CA 2014-04-29 13:42:54 self* 2014-04-29 13:42:55 ACTION likes self-signed, but dunno if others actually care 2014-04-29 13:43:07 i'd like to have an alpine CA 2014-04-29 13:43:21 ACTION hasn't had cycles to set one up :/ 2014-04-29 13:43:35 and make it easy for ppl to install it 2014-04-29 13:43:42 yeah, thats the problem... 2014-04-29 14:31:25 if i created newpackage in aports/testing/noip/ i need to do git init inside that noip to have it in git status for commit? 2014-04-29 14:32:05 no 2014-04-29 14:32:15 git add testing/noip 2014-04-29 14:32:20 git commit 2014-04-29 14:32:44 as commit message you can have something like: 2014-04-29 14:32:50 testing/noip: new aport 2014-04-29 14:32:53 2014-04-29 14:33:06 2014-04-29 14:33:14 2014-04-29 14:41:46 ok thanks :) 2014-04-29 14:44:26 you can then sprunge it here: git format-patch -1 --stdout | sprunge 2014-04-29 14:44:32 (given you have done apk add sprunge) 2014-04-29 14:44:36 and paste url here 2014-04-29 14:44:43 and i can have a look at it 2014-04-29 14:49:30 clandmeter is helping me on pm :) 2014-04-29 14:49:41 hides behinde low git knowelage 2014-04-29 14:49:50 sprunge is a must :) 2014-04-29 14:56:33 sprunge is really cool 2014-04-29 15:33:55 hmm how to add my sing to my local repo? apk add ./noip-2.1.9-r0.apk ERROR: ./noip-2.1.9-r0.apk: UNTRUSTED signature 2014-04-29 15:34:53 ncopa here is patch but clandmeter will commit it later, http://sprunge.us/GZMf , but the first line (Date) looks weird to me 2014-04-29 15:35:20 crow: install your apk signing key into /etc/apk/keys 2014-04-29 15:41:34 jbilyk thanks copied it to second server and it is now trusted :) 2014-04-29 15:41:38 just have this: ERROR: noip-2.1.9-r0.pre-install: script exited with error 1 2014-04-29 15:42:01 sounds like you need to fix the pre-install script :) 2014-04-29 15:42:50 jbilyk well its empty :/ 2014-04-29 15:43:03 then you should remove it 2014-04-29 15:43:13 but abuild complains about missing then 2014-04-29 15:45:32 noip: Checking sanity of /home/crow/aports/testing/noip/APKBUILD ERROR: noip: install script noip.pre-install is missing 2014-04-29 15:46:05 crow: remove all references to .pre-install from the APKBUILD 2014-04-29 15:46:08 fixed it 2014-04-29 15:46:10 basic :( 2014-04-29 16:18:35 when i start this noip over init.d it crash, if i start it manually i see this in log http://sprunge.us/ieMP 2014-04-29 16:49:00 ncopa clandmeter last patch for noip package: http://sprunge.us/aCgI (build info: http://sprunge.us/MFjd ), one problem which seems exist is unable to create pid file: http://sprunge.us/iUUW , startup options are these: http://sprunge.us/TVNX 2014-04-30 08:12:25 morning, 2014-04-30 08:14:19 ncopa clandmeter did someone from you have time to check thi noip packages? 2014-04-30 08:35:18 crow: is this the vurrent version? http://sprunge.us/GZMf 2014-04-30 09:02:31 ncopa no this one http://sprunge.us/aCgI 2014-04-30 09:02:52 what i dont understand is this first line? Date 2001? From da955704af9efddc94eeadb9242c241a8bb92cd8 Mon Sep 17 00:00:00 2001 2014-04-30 09:03:05 ncopa this was last what i wrote yesterday 2014-04-30 09:03:07 18:49:00) (crow) ncopa clandmeter last patch for noip package: http://sprunge.us/aCgI (build info: http://sprunge.us/MFjd ), one problem which seems exist is unable to create pid file: http://sprunge.us/iUUW , startup options are these: http://sprunge.us/TVNX 2014-04-30 09:25:27 seems like it does not create pidfile 2014-04-30 09:32:22 yea any hint why? 2014-04-30 09:32:53 maybe it does need to go /var/run/noip/noip.pid ? 2014-04-30 09:34:03 i dont see any indication that noip application has the code to create any pid 2014-04-30 09:34:44 looks like there are no option for 'create pidfile' 2014-04-30 09:34:48 http://sprunge.us/TVNX 2014-04-30 09:35:58 theoretically, you only need pidfile if you want support multiple instances of the daemon 2014-04-30 09:49:06 well i am not sure how i could do multiple instances of the daemon? as with init.d it starts only one? 2014-04-30 09:52:28 yes, and i suppose you only need one instance 2014-04-30 09:52:34 so i dont think you need pidfile 2014-04-30 09:52:59 ok i will remove it and make new patch. 2014-04-30 09:54:13 i have already applied it 2014-04-30 09:54:19 so git pull --rebase first 2014-04-30 09:54:27 and create a patch against what we have in testing 2014-04-30 09:54:32 and increase pkgrel 2014-04-30 09:55:03 ok no problem thanks 2014-04-30 09:56:52 ncopa if i used branch (noip) is --rebase then neede with git pull? 2014-04-30 09:57:35 um 2014-04-30 09:58:04 i mean my local master is clean 2014-04-30 09:58:19 i always use --rebase just in case 2014-04-30 09:58:27 i see ok 2014-04-30 09:58:28 but i suppose you dont need 2014-04-30 09:59:48 i followed recomendation from clandmeter and did a branch, to keep master clean. So i suppse this is ok http://sprunge.us/EGgN 2014-04-30 10:00:51 I usually keep things in master 2014-04-30 10:00:56 samehere 2014-04-30 10:01:02 I do git pull --rebase before I push anything 2014-04-30 10:01:18 i only do branch if i have an abi compat lib 2014-04-30 10:01:20 and use git stash if I want to pull, but not to commit my changes yet 2014-04-30 10:01:30 and i have to rebuild lots of packages 2014-04-30 10:01:49 http://youtu.be/5pOxlazS3zs 2014-04-30 10:02:16 new firefox 29 built 2014-04-30 10:02:20 and appears to work 2014-04-30 10:04:59 barthalion i am new to git so i can easy do some things in master without willing to do them :) 2014-04-30 10:09:36 when you are new to git and dont have commit access, imho its easier to have a seperate branch to mess with. 2014-04-30 10:10:21 clandmeter correct :) 2014-04-30 10:10:32 can someone explain me what is this: (11:02:52) (crow) what i dont understand is this first line? Date 2001? From da955704af9efddc94eeadb9242c241a8bb92cd8 Mon Sep 17 00:00:00 2001 2014-04-30 10:10:40 in my patch 2014-04-30 10:12:09 crow: http://stackoverflow.com/questions/15790120/what-is-the-first-line-of-git-format-patch-output 2014-04-30 10:13:17 thanks 2014-04-30 10:40:41 ncopa that noip patch was not last one i send here :( 2014-04-30 10:42:41 11:02:30) (crow) ncopa no this one http://sprunge.us/aCgI 2014-04-30 10:43:43 crow: thats not going to work anymore 2014-04-30 10:43:56 your new patche needs to be based on the previous commit 2014-04-30 10:44:11 i see :/ 2014-04-30 10:44:20 ok no problem :) 2014-04-30 10:49:08 creating patch based on master 2014-04-30 11:56:04 barthalion: that was a pretty cool video 2014-04-30 11:56:07 really nice 2014-04-30 13:43:13 algitbot: build master 2014-04-30 15:27:13 ncopa: and funny, that part about packaging was so true :p