2016-02-01 06:10:19 <coredumb> Hello, I'm hitting this with php-memcache
2016-02-01 06:10:22 <coredumb> NOTICE: PHP message: PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib/php/modules/memcache.so' - Error relocating /usr/lib/php/modules/memcache.so: mmc_buffer_alloc: symbol not found in Unknown on line 0
2016-02-01 06:10:39 <coredumb> how should I proceed to fix it ?
2016-02-01 06:48:17 <coredumb> mmmh seems to be an error where it look at other php libraries
2016-02-01 06:48:53 <coredumb> or not :P
2016-02-01 07:00:02 <coredumb> ok needs a patch for gcc5
2016-02-01 07:00:09 <coredumb> gonna send modifications
2016-02-01 07:10:20 <coredumb> ok sent
2016-02-01 15:35:17 <skarnet> Good afternoon
2016-02-01 15:36:06 <skarnet> So, I have a friend who would like to use apk to manage packages, but only on top of a given software base not managed by apk
2016-02-01 15:36:19 <skarnet> basically, he has the apk and abuild binaries, but no installed /lib/apk/db
2016-02-01 15:36:45 <skarnet> and of course, apk fails
2016-02-01 15:37:06 <skarnet> what would be the best way to initialize an "empty" database for apk?
2016-02-01 15:44:42 <clandmeter> skarnet: --initdb?
2016-02-01 15:44:58 <przemoc86> hi.  skarnet, this almost sounds like those embarassing question you allegedly ask for someone, because in fact you're too afraid to admit that this someone is you. :)
2016-02-01 21:26:18 <ammunta> przemoc: well many people are their own friend, right
2016-02-01 21:26:30 <ammunta> though I'm not so sure if skarnet is the friendly type
2016-02-01 21:26:53 <ammunta> :)
2016-02-01 21:58:24 <ammunta> which list do I mail a patch to abuild to
2016-02-01 22:37:59 <skarnet> ammunta: there was a big netsplit and I missed the conversation, basically
2016-02-01 22:38:14 <skarnet> what was that about friendliness? :P
2016-02-01 22:42:02 <ammunta> skarnet: don't think you missed anything in that netsplit
2016-02-01 22:47:05 <skarnet> including nobody answering the question I asked earlier in the day?
2016-02-01 22:57:32 <coredumb> skarnet: 16:44   @clandmeter | skarnet: --initdb?
2016-02-01 23:03:03 <skarnet> thanks :)
2016-02-01 23:03:50 <skarnet> afaik it's undocumented in apk -h
2016-02-01 23:04:17 <skarnet> and I didn't think of checking the source...
2016-02-01 23:08:16 <skarnet> ah, it's in the "apk add" options...
2016-02-02 08:03:30 <ScrumpyJack> hmm, http://patchwork.alpinelinux.org/patch/1522/
2016-02-02 08:10:53 <ScrumpyJack> i don't see the function in abuild that handles this. have i missed something?
2016-02-02 08:13:15 <fcolista> newapkbuild foo : it creates by default preapre() funciont
2016-02-02 08:13:17 <fcolista> *function
2016-02-02 08:15:46 <ScrumpyJack> yes. has done for a while. perhaps I missread the patch. it sounds like that function is now in abuild
2016-02-02 08:15:58 <clandmeter> ScrumpyJack: i dont know either.
2016-02-02 08:16:07 <ScrumpyJack> instead of being a script in APKBUILD
2016-02-02 08:17:06 <fcolista> ScrumpyJack, yes. That's what i've understood.
2016-02-02 08:17:11 <clandmeter> abuild gitlog also doesnt say anything for prepare()
2016-02-02 08:20:48 <ScrumpyJack> prepare in APKBUILD is quite useful imho
2016-02-02 08:41:01 <ncopa> default_prepare() in abuild is not yet implemented
2016-02-02 08:41:08 <ncopa> its only talk so far
2016-02-02 08:46:54 <clandmeter> ah, so this dev is a visionair?
2016-02-02 08:49:52 <coredumb> as I asked on the ml, how does it behave when one adds a prepare() in the APKBUILD ?
2016-02-02 08:52:18 <coredumb> cause we can do other things than patch in prepare()
2016-02-02 08:52:26 <coredumb> or is it not recommended to do so ?
2016-02-02 09:15:46 <ncopa> coredumb: prepare can do anything that needs to be done before build
2016-02-02 09:16:06 <ncopa> in theory you could do the patching in build() too
2016-02-02 09:16:19 <ncopa> but it may make sense to split it
2016-02-02 09:16:35 <ncopa> because then you can do: abuild clean unpack prepare
2016-02-02 09:16:49 <ncopa> and then go modify or inspect the sources
2016-02-02 09:16:57 <ncopa> before doing abuild build
2016-02-02 09:29:13 <coredumb> ncopa: sure
2016-02-02 09:29:32 <coredumb> my question was about will prepare() in APKBUILD take prevalence on the default one ?
2016-02-02 09:29:42 <ncopa> it wil
2016-02-02 09:33:13 <coredumb> ok
2016-02-02 09:33:18 <coredumb> all fine then :)
2016-02-02 09:33:38 <coredumb> ncopa: btw could you push my php-memcache patch ?
2016-02-02 09:33:56 <coredumb> stable's php-memcache is unusable as it is :(
2016-02-02 09:44:46 <ncopa> patch queue is huge!
2016-02-02 09:45:07 <coredumb> :)
2016-02-02 09:45:51 <ncopa> %1516 ?
2016-02-02 09:46:15 <coredumb> yep
2016-02-02 09:46:34 <ncopa> and %1517?
2016-02-02 09:47:30 <coredumb> yeah sorry about the second one
2016-02-02 09:47:39 <coredumb> didn't see this line from copy pasting
2016-02-02 10:26:08 <ammunta> ScrumpyJack: ooooh I misunderstood
2016-02-02 10:26:30 <ammunta> ScrumpyJack: that's 2/3, 1/3 implements default_prepare
2016-02-02 10:28:17 <ammunta> not visionary, just presumptuous :)
2016-02-02 10:31:36 <ammunta> anyway there's already a prepare() in abuild (which is a noop) that APKBUILD definitions override
2016-02-02 10:36:02 <ammunta> I actually had a thought to how extra options to patch could be passed, too
2016-02-02 10:37:40 <ammunta> those can be just passed in to default_prepare, which can do patch "${@--p1}"
2016-02-02 10:37:59 <ammunta> althought that might be a bit ... too magical
2016-02-02 10:50:51 <clandmeter> ammunta: the idea is to keep apkbuild as transparent as possible. so we prefer a bit of clutter if it makes it easier to understand the logic.
2016-02-02 10:51:14 <ammunta> yeah, too magical
2016-02-02 10:51:22 <clandmeter> exactly
2016-02-02 10:52:01 <clandmeter> gentoo does lots of magic, and it makes it hard to steal things from them... uhmm borrow of course ;-)
2016-02-02 10:53:59 <ammunta> [ ${1+1} ] || set -- -p1 or equivalent, then pass in "$@", maybe?
2016-02-02 10:54:45 <ammunta> although how common is modifications to the patcher anyway
2016-02-02 10:54:55 <ammunta> there's a few -p0, but
2016-02-02 11:18:24 <skarnet> ammunta: the whole point of package builders is to provide syntactic sugar, so "too magical" can't be absolute here - it has to be balanced against "worth the gains or not"
2016-02-02 11:24:30 <ammunta> skarnet: not in the implementation though ...
2016-02-02 11:36:15 <skarnet> true
2016-02-02 14:05:02 <fcolista> ncopa, re %5049
2016-02-02 14:05:03 <fcolista> http://sprunge.us/OSRT
2016-02-02 14:05:16 <fcolista> sorry, #5049
2016-02-02 14:05:52 <fcolista> I'm wondering if would be a better way to handle -fno-builtin
2016-02-02 14:09:59 <fcolista> nevermind. Does not solves the bug
2016-02-02 16:42:59 <ScrumpyJack> i have an empty libc-utils, and the package doesn't seem to exist in aports. it is obsolete?
2016-02-02 16:44:04 <ScrumpyJack> i must come from somewhere :)
2016-02-02 16:46:20 <ScrumpyJack> ok, it seems to come from libc-dev
2016-02-02 16:47:06 <ScrumpyJack> no it doesn't :) that just a meta package
2016-02-02 16:47:16 <ScrumpyJack> 
ACTION plays chase the package

2016-02-02 16:55:28 <ScrumpyJack> pkgdesc = Meta package to pull in correct libc
2016-02-02 16:55:33 <ScrumpyJack> origin = libc-dev
2016-02-02 18:16:27 <nmeum> ncopa: do you have more time these days? If so: Would you mind taking another look at my abuild patches from last year. It's still annoying that abuild doesn't handle hardlinks properly on filesystem where inodes aren't ordered sequentially
2016-02-03 09:31:11 <starefossen> The Node.js Build & Infra is planing to start testing Node.js releases also on Alpine Linux to make sure we are fully compatible. I just have some quick questions regarding versioning and releases of alpine. Which version should we be testing agains, how long is it expected to be maintained, and how likely is it to be breaking changes within a major version
2016-02-03 09:31:11 <starefossen> cycle?
2016-02-03 09:33:33 <barthalion> starefossen: we have nodejs in main repository
2016-02-03 09:33:52 <barthalion> it means it's supported for 2 years since release, obviously only security backports or critical bugfixes
2016-02-03 09:34:14 <barthalion> edge is our rolling release, where latest releases land
2016-02-03 09:34:59 <barthalion> I guess the main reason behind the testing you want to perform is our popularity in containers community
2016-02-03 09:35:23 <barthalion> official alpine image pulls latest stable release by default, so I guess you should follow this
2016-02-03 09:36:00 <starefossen> Yes, that is correct. I am maintaining the official Docker Image for Node.js but we have been holding of adding an `alpine` variant before we know we have all the test running under Alpine.
2016-02-03 09:36:13 <barthalion> it's really up to you anyway, our breaking changes are usually unrelated to high level stuff like nodejs
2016-02-03 09:37:20 <barthalion> so to be really sure, I'd run tests for maintenance releases on our latest stable, and development on edge
2016-02-03 09:38:31 <starefossen> great, thanks! hopefully we'll have Alpine available on some of our Jenkins slaves this week or the next.
2016-02-03 09:38:44 <barthalion> ncopa: I thought Valery has push access to testing?
2016-02-03 09:39:48 <barthalion> ncopa: looks like no though – I'd like to have him on board for testing and community
2016-02-03 09:39:55 <barthalion> starefossen: great to hear :)
2016-02-03 10:06:18 <ncopa> starefossen: hi!
2016-02-03 10:06:22 <ncopa> great to hear
2016-02-03 10:06:26 <ncopa> i can help you with it
2016-02-03 10:07:05 <ncopa> as said, edge is our rolling release branch (git master)
2016-02-03 10:07:25 <ncopa> every 6 month we do a stable branch of it
2016-02-03 10:07:33 <ncopa> basically, take what we have in edge and ship it
2016-02-03 10:07:56 <ncopa> we try to do that every november and may
2016-02-03 10:08:41 <ncopa> then for the last stable release (currently 3.3) we do bugfixes only and after that we do sec fixes only
2016-02-03 10:09:00 <ncopa> total support for 2 years
2016-02-03 10:09:02 <ncopa> thats the idea at least
2016-02-03 10:09:08 <starefossen> thank you ncopa!
2016-02-03 10:09:35 <ncopa> bit it has proven to be difficult to supoprt everything for 2 years
2016-02-03 10:09:46 <ncopa> sometimes upstream does not care for 2 year old release
2016-02-03 10:09:54 <ncopa> often, that is
2016-02-03 10:10:13 <ncopa> and sometimes the sec fixes are very timeconsuming to backport
2016-02-03 10:10:32 <ncopa> so with the v3.3 release we also introduced a "community" repo
2016-02-03 10:10:40 <ncopa> which we only do sec fixes for 6 months
2016-02-03 10:10:51 <ncopa> after that it is 'best-effort'
2016-02-03 10:11:03 <ncopa> so we may fix critical things when possible
2016-02-03 10:11:42 <ncopa> starefossen: i looked at the node test suite
2016-02-03 10:12:01 <ncopa> and i can help you make the tests pass
2016-02-03 10:13:09 <ncopa> this was the first issue i bumped into: http://tpaste.us/GBWn
2016-02-03 10:14:25 <ncopa> re "how likely is it to be breaking changes within a major version"
2016-02-03 10:14:38 <ncopa> very unlikely
2016-02-03 10:14:49 <ncopa> we try hard to avoid breakages
2016-02-03 10:15:27 <ncopa> we dont permit ABI breakages there
2016-02-03 10:15:40 <starefossen> that is great to hear!
2016-02-03 10:16:03 <ncopa> but i think we have had atleast one exception as far i can remmeber for last 10 years
2016-02-03 10:17:04 <starefossen> I haven't had time to actually run nodejs the test suite on alpine, but we would be more than happy for any help fixing breaking tests.
2016-02-03 10:17:38 <ncopa> where do we take that discussion? here? or in some nodejs-dev channel?
2016-02-03 10:19:54 <starefossen> the build and infra team hangs out in #nodejs-build
2016-02-03 10:20:12 <starefossen> #node-build
2016-02-03 11:51:13 <clandmeter> those new APU's from pcengines are interesting
2016-02-03 11:52:27 <clandmeter> quad core GX-412TC, AES-NI support, AVX support, 3x Intel nic's
2016-02-03 14:48:58 <tdtrask> ncopa: please apply http://tpaste.us/AQdQ to alpine-conf to add community repo to repositories file
2016-02-03 14:49:59 <tdtrask> or fabled
2016-02-03 14:50:09 <tdtrask> or I can do it myself if you approve
2016-02-03 14:51:27 <ncopa> ack
2016-02-03 14:51:37 <ncopa> i think we dont need to add the leading #
2016-02-03 14:51:43 <ncopa> hm
2016-02-03 14:51:57 <ncopa> maybe keep it like that for now
2016-02-03 14:52:04 <ncopa> please push it as is
2016-02-03 14:52:06 <ncopa> and thanks!
2016-02-03 14:52:46 <nmeum> ncopa: do you have more time these days? If so: Would you mind taking another look at my abuild patches from last year. It's still annoying that abuild doesn't handle hardlinks properly on btrfs and other btree based filesystems.
2016-02-03 14:53:45 <nmeum> If you dislike my proposed solution then just tell me I will try to come up with another one then but the fact that man pages compression breaks due to hardlink sucks :(
2016-02-03 15:05:19 <tdtrask> ncopa: pushed
2016-02-03 15:05:25 <tdtrask> 
ACTION will wait for you to make a release

2016-02-03 15:16:19 <ncopa> nmeum: i looked at it this morning but it didnt apply
2016-02-03 15:16:26 <ncopa> will fix it asap
2016-02-03 15:16:38 <ncopa> and no, i dont have more time these days :-(
2016-02-03 18:12:48 <nmeum> ncopa: I could rebase them against master
2016-02-03 18:13:01 <ncopa> nmeum: can you please do that?
2016-02-03 18:13:07 <nmeum> sure
2016-02-03 18:13:18 <ncopa> and git format-patch --stdout ... | tpaste
2016-02-03 18:13:23 <ncopa> and i'll pull it here an now
2016-02-03 18:16:18 <nmeum> ncopa: http://sprunge.us/ZcbE
2016-02-03 18:16:38 <nmeum> do you want me to remove the section change?
2016-02-03 18:19:49 <ncopa> i think its okish
2016-02-03 18:20:00 <ncopa> lets keep it for now
2016-02-03 18:20:17 <ncopa> and i'll know who to spank if things break in future :)
2016-02-03 18:21:32 <ncopa> thanks for writing good commit message
2016-02-03 18:22:57 <nmeum> good commit messages make it easier to fix stuff if it breaks in the future, though I hope that it doesn't :)
2016-02-03 18:23:39 <ncopa> does this fix the issue with double compressed manpages too?
2016-02-03 18:23:42 <ncopa> i suppoes not
2016-02-03 18:24:53 <nmeum> I didn't take a look at the double compressed manpage issue yet
2016-02-03 18:24:57 <ncopa> ok
2016-02-03 18:25:02 <ncopa> i have something for it
2016-02-03 18:25:07 <nmeum> alright
2016-02-03 18:25:11 <ncopa> +               -a \! \( -name '*.gz' -o name '*.bz2' -o name '*.xz' \) \
2016-02-03 18:28:33 <nmeum> yeah that should work
2016-02-03 18:29:36 <ncopa> so, my worry was that it would be slower
2016-02-03 18:29:39 <ncopa> and it is
2016-02-03 18:29:46 <ncopa> for openssl it takes 3 seconds more
2016-02-03 18:30:03 <ncopa> but i suppose its not a deal-breaker
2016-02-03 18:30:10 <ncopa> better be correct
2016-02-03 18:31:47 <BitL0G1c> mini-sendmail is still a worthwhile patch - I got dns working in a chroot without busybox
2016-02-03 18:33:29 <ncopa> nmeum: which package do you use as testcase?
2016-02-03 18:45:21 <nmeum> ncopa: nvi
2016-02-03 18:45:58 <nmeum> and yeah the solution is not optimal but I couldn't think of a better one
2016-02-03 18:46:31 <nmeum> gentoo for example seems to be breaking all hardlinks on purpose before compressing the man pages but that should be even slower
2016-02-03 18:52:27 <ncopa> i have a suggesetion for speed improvement
2016-02-03 18:52:44 <ncopa> http://tpaste.us/2KoP
2016-02-03 18:53:06 <ncopa> that will recude number of forks significantly
2016-02-03 18:54:02 <ncopa> instead of forking stat N times (where N is number of files), we fork stat once but adds all the files as arg
2016-02-03 18:58:10 <ncopa> hm
2016-02-03 18:58:16 <ncopa> does not work as expected
2016-02-03 19:14:25 <ncopa> nmeum: can you please test that this does not break anything for you? http://tpaste.us/AoNB
2016-02-03 19:17:50 <nmeum> sure
2016-02-03 19:18:44 <ncopa> if its all fine then i'll just push i think
2016-02-03 19:18:49 <ncopa> and probably do release tomorrow
2016-02-03 19:19:01 <ncopa> i think there were a few patches sent to ml too
2016-02-03 19:20:12 <nmeum> yeah maybe would could add the default_prepare patch for the next release too?
2016-02-03 19:20:18 <nmeum> s/would//
2016-02-03 19:20:45 <nmeum> though the patch that was sent to the maillinglist doesn't include an option to set additional patch(1) flags
2016-02-03 19:22:16 <nmeum> ncopa: your changes don't seem to break anything here
2016-02-03 19:24:30 <nmeum> the fix for the double man page compression issue works as well here
2016-02-03 19:24:36 <ncopa> very well
2016-02-03 19:24:40 <ncopa> i'll push that
2016-02-03 19:24:45 <nmeum> great
2016-02-03 19:25:06 <ncopa> drats
2016-02-03 19:25:36 <nmeum> huh?
2016-02-03 19:26:14 <ncopa> my tree was not rebased
2016-02-03 19:28:18 <pluesch> finally got time to setup a new dedicated server with alpine and test qemu-kvm a bit more
2016-02-03 19:28:33 <ncopa> nmeum: i messed up. i pushed a broken commit
2016-02-03 19:28:37 <ncopa> i'll clean it up
2016-02-03 19:29:42 <pluesch> I've got the same error (vm dies and the only message is qemu-system-x86_64: Guest moved used index from 17207 to 17432) but this time with a vm that was just running tor and nothing else. I've used qemu from edge.
2016-02-03 19:29:59 <pluesch> It did however take about 4 days for it to crash
2016-02-03 19:30:07 <ncopa> thats annoying
2016-02-03 19:30:14 <ncopa> i prefer when it crashes instantly
2016-02-03 19:30:22 <pluesch> I have no idea how to debug this really...
2016-02-03 19:30:54 <ncopa> you need find some way to reliable reproduce it
2016-02-03 19:31:01 <ncopa> in shorter time than 4 days
2016-02-03 19:31:04 <pluesch> I know
2016-02-03 19:31:18 <ncopa> you can look for resource leaks
2016-02-03 19:31:24 <ncopa> check if it leas filedescriptors
2016-02-03 19:31:26 <ncopa> or memory
2016-02-03 19:33:56 <ncopa> nmeum: i pushed the changes
2016-02-03 19:35:40 <pluesch> Is it normal for "random: nonblocking pool" to take 60-180 seconds to get initialized after bootup?
2016-02-03 19:35:44 <pluesch> [  168.707910] random: nonblocking pool is initialized
2016-02-03 19:35:59 <pluesch> maybe it's related to this?
2016-02-03 19:36:15 <ncopa> maybe it does not have enough entropy?
2016-02-03 19:36:16 <ncopa> i dont know
2016-02-03 19:36:22 <ncopa> 60-180 sec sounds much
2016-02-03 19:51:51 <tdtrask> ncopa: if you're going to push a release tomorrow, do you want me to tag a release of alpine-conf?
2016-02-03 20:09:32 <ncopa> i havent checked what is in the queue of alpine-conf
2016-02-03 20:29:02 <tdtrask> ncopa: just the one change to add community repo
2016-02-03 20:30:18 <ncopa> do we want add nvme there too while at it?
2016-02-03 20:30:27 <ncopa> i'm ok with you tagging it if you want
2016-02-03 20:31:45 <tdtrask> nvme?
2016-02-03 20:32:33 <ncopa> http://forum.alpinelinux.org/forum/installation/installing-m2-drive-root-partition-not-mounted-boot
2016-02-03 20:32:57 <ncopa> i think we only need add the nvme kernel module(s) as a 'feature' for mkinitfs
2016-02-03 20:33:06 <ncopa> then from setup-disk detect if its needed
2016-02-03 20:33:18 <ncopa> and add it to mkinitfs config if it is
2016-02-03 20:33:31 <ncopa> i dont have the hardware to test
2016-02-03 20:33:40 <ncopa> but it looks like kvm can simulate it
2016-02-03 20:33:47 <tdtrask> 
ACTION will leave that for you :)

2016-02-03 20:33:48 <ncopa> qemu
2016-02-03 20:34:03 <ncopa> im ok to tag a release
2016-02-03 20:34:09 <tdtrask> k
2016-02-03 20:34:10 <ncopa> or you cah cherrypick a patch
2016-02-03 20:34:22 <tdtrask> 
ACTION will tag release

2016-02-03 20:39:43 <tdtrask> done
2016-02-03 20:40:02 <tdtrask> and backported to 3.3
2016-02-03 20:49:23 <yth> may I ask a general question - what's the current thinking about long-term use of grsecurity since the stable patch policy change?
2016-02-03 20:49:58 <ncopa> yth: thats a tough question
2016-02-03 20:50:07 <ncopa> for now we try hang on to grsec
2016-02-03 20:50:22 <ncopa> port the free patch for our stable kernel
2016-02-03 20:50:30 <ncopa> i dont know for how long that will be doable
2016-02-03 20:52:46 <yth> ncopa: thanks - how difficult is is to keep it ported?
2016-02-03 20:52:59 <ncopa> normally doable
2016-02-03 20:53:04 <ncopa> but it takes time
2016-02-03 20:53:14 <ncopa> need to rebase the patch
2016-02-03 20:53:23 <ncopa> basically, we use the last available free patch
2016-02-03 20:53:31 <ncopa> and pull in mainline changes
2016-02-03 20:53:59 <ncopa> alos run diff on the free patch to see if there is something we want backport
2016-02-03 20:54:13 <ncopa> but unfortunally, we have not been able to keep up lately
2016-02-03 20:57:20 <yth> sure - obviously difficult... is there any way to leverage (presumably) similar porting going on with other distributions like Gentoo Hardened?
2016-02-03 20:57:36 <ncopa> they do that porting?
2016-02-03 20:57:47 <ncopa> i thought other distros only use the free patch
2016-02-03 20:59:17 <yth> ah - no, I don't really know - just trying to understand the landscape better
2016-02-03 20:59:50 <ncopa> i think we are the only ones crazy enough to even try :)
2016-02-03 21:01:01 <yth> yes, I see :)
2016-02-03 21:01:50 <yth> is switching to (or at least offering) the mainline free patch something you'd consider as an alternative later?
2016-02-03 21:02:46 <ncopa> the problem is that we try do stable branches
2016-02-03 21:03:00 <ncopa> so we rely on mailine longterm kernels
2016-02-03 21:03:06 <ncopa> mainline*
2016-02-03 21:03:27 <ncopa> when we do a stable release, we want maintain that branch for 2 years
2016-02-03 21:03:47 <ncopa> and only do sec fixes
2016-02-03 21:03:51 <ncopa> no new features
2016-02-03 21:04:25 <ncopa> we did ship some relase with non-longterm kernel (v2.5 iirc)
2016-02-03 21:04:33 <ncopa> and i tried to bacport sec fixes
2016-02-03 21:04:49 <ncopa> i basically ended up maintaining a stable kernel branch
2016-02-03 21:04:58 <ncopa> which is a huge amount of work
2016-02-03 21:05:03 <ncopa> and had to give that up
2016-02-03 21:07:48 <yth> ah, I see - so I a step change in the difficulty of porting grsecurity at each stable alpine release
2016-02-03 21:09:27 <yth> thanks for taking the time to explain
2016-02-03 23:57:17 <babasbot> sup! any plans for this request?
2016-02-03 23:57:18 <babasbot> https://bugs.alpinelinux.org/issues/3642
2016-02-03 23:58:38 <babasbot> can anyone submit a new package?
2016-02-04 14:48:56 <ScrumpyJack> are there any interesting binary signing implementation that someone might have an opinion on?
2016-02-04 14:49:15 <ScrumpyJack> s/are/is
2016-02-04 15:55:09 <ScrumpyJack> it shouldn't be difficult to sign every ELF binary at build time, but how would you check the "signature" at exec?
2016-02-04 15:57:36 <ScrumpyJack> that's a silly idea
2016-02-04 15:59:46 <ScrumpyJack> http://disec.sourceforge.net/
2016-02-04 16:00:09 <ScrumpyJack> it's lonely in here
2016-02-04 16:01:42 <skarnet> 
ACTION silently watches ScrumpyJack behind a way mirror

2016-02-04 16:07:29 <ScrumpyJack> 
ACTION wonders why this room is padded

2016-02-05 03:58:35 <kimo_sabe> pluesch: Forgot to reconnect to this screen session at work. I'm having the same issue. It seems to be disk IO triggered. Switching from virtio to emulated SATA lowers the frequency but doesn't eliminate it. (from <2 hours to multiple days between crashes).
2016-02-05 03:59:40 <kimo_sabe> pluesch: I've been able to reproduce it on a non-production VM just using cp on a big Maildir, but not perfectly consistently
2016-02-05 06:04:41 <pluesch> I'll try that
2016-02-05 06:05:09 <pluesch> I remember trying dd=/dev/zero of=testfile... but didn't manage to get it crashed that way
2016-02-05 10:01:30 <ncopa> fcolista: http://git.alpinelinux.org/cgit/aports/commit/main/speex?id=7dc403832ad1316a25bcd411b87375289494a6a6
2016-02-05 10:01:33 <ncopa> that is wrong
2016-02-05 10:01:55 <ncopa> abuild should autocreate the provides=pc:.....
2016-02-05 10:02:29 <ncopa> what happens in speex case is that the speex package gets the provides=pc:speex instead of speex-dev
2016-02-05 10:02:54 <ncopa> so libshout will pull in 'speex' instead of 'speex-dev' as dep
2016-02-05 10:03:02 <ncopa> libshout-dev i mean
2016-02-05 10:03:16 <ncopa> libshout-dev will pull in 'speex' instead of 'speex-dev' as dep
2016-02-05 10:03:20 <fcolista> ncopa, i'm wondering why i did it
2016-02-05 10:03:31 <ncopa> abuild probably gave you a warning
2016-02-05 10:03:38 <ncopa> when you built libshout
2016-02-05 10:03:52 <fcolista> oh, ok. I'm sure that it was behind a suggestion.
2016-02-05 10:04:07 <fcolista> So might be due to a warning
2016-02-05 10:04:23 <ncopa> can you remove that provdes line, rebuild with pkgrel=4
2016-02-05 10:04:34 <fcolista> I was not aware fully of the purpose of provides=
2016-02-05 10:04:37 <fcolista> yes sure
2016-02-05 10:04:46 <ncopa> verify that speex-dev gets provides=so:speex?
2016-02-05 10:05:10 <ncopa> clandmeter: i think that is the only thing needed^^^
2016-02-05 10:05:10 <fcolista> yes
2016-02-05 10:05:15 <ncopa> rebuild of speex
2016-02-05 10:05:48 <clandmeter> ok ill wait till it gets pushed
2016-02-05 10:05:56 <fcolista> ./speex-dev/usr/lib/libspeex.so
2016-02-05 10:07:23 <clandmeter> fcolista: check the control dir
2016-02-05 10:07:41 <clandmeter> it will hold provides
2016-02-05 10:08:06 <clandmeter> ncopa: what about depends_dev="speex-dev" for libshout?
2016-02-05 10:08:31 <clandmeter> pr will pkgconf take care of that?
2016-02-05 10:08:36 <clandmeter> or*
2016-02-05 10:08:52 <ncopa> abuild should take care of it
2016-02-05 10:08:54 <fcolista> http://sprunge.us/IWGI
2016-02-05 10:08:56 <fcolista> clandmeter, ^^^
2016-02-05 10:09:11 <ncopa> i think libshout-dev already has a depends=pc:speex
2016-02-05 10:09:15 <ncopa> which is correct
2016-02-05 10:09:20 <clandmeter> fcolista: ./.control.speex-dev/.provides-pc
2016-02-05 10:09:25 <ncopa> problem is that wrong package has the provides
2016-02-05 10:10:21 <fcolista> clandmeter, ncopa, sorry, but i'm not understanding what i should to check
2016-02-05 10:10:26 <fcolista> where and how
2016-02-05 10:10:40 <clandmeter> verify that speex-dev gets provides=so:speex
2016-02-05 10:10:48 <clandmeter> it should be in one of the provides files
2016-02-05 10:10:58 <ncopa> grep provides  ./.control.speex-dev/.PKGINFO
2016-02-05 10:11:07 <clandmeter> or pkginfo :)
2016-02-05 10:11:14 <fcolista> provides = pc:speex=1.2rc2
2016-02-05 10:11:22 <ncopa> that is correct
2016-02-05 10:11:25 <ncopa> push that
2016-02-05 10:11:33 <ncopa> abuild does that for you
2016-02-05 10:11:40 <fcolista> ok
2016-02-05 10:11:54 <ncopa> what happened was
2016-02-05 10:12:00 <ncopa> speex was built with old abuild
2016-02-05 10:12:16 <ncopa> old speex built with old abuild, without the provides=pc:* support
2016-02-05 10:12:24 <ncopa> new abuild complained
2016-02-05 10:12:31 <ncopa> or warned
2016-02-05 10:12:48 <ncopa> the only thing needed was a rebuild os speex
2016-02-05 10:12:50 <ncopa> of*
2016-02-05 10:12:56 <ncopa> with new abuild
2016-02-05 10:13:18 <ncopa> i didnt bother rbuilding world when i pushed updated abuild
2016-02-05 10:13:22 <fcolista> i see
2016-02-05 10:13:28 <clandmeter> sounds like we should have dont a complete rebuild when we made those abuid changes?
2016-02-05 10:13:34 <ncopa> correct
2016-02-05 10:13:37 <clandmeter> s/dont/done
2016-02-05 10:13:42 <ncopa> thats the technicall correct thing to do
2016-02-05 10:13:58 <ncopa> i just didnt have those extra 2-3 days for that :)
2016-02-05 10:14:02 <clandmeter> but it would have caused more issus then it would solve...
2016-02-05 10:14:24 <ncopa> i figured that it would correct itself over time
2016-02-05 10:14:37 <clandmeter> everyting does :)
2016-02-05 10:14:50 <ncopa> i better get back to work
2016-02-05 10:15:10 <clandmeter> send us the invoice :)
2016-02-05 10:15:26 <clandmeter> make that fcolista ;-)
2016-02-05 10:16:04 <fcolista> :)
2016-02-05 10:25:04 <clandmeter> fcolista: something is wrong
2016-02-05 10:25:29 <clandmeter> speex-dev does not provide pc:speex
2016-02-05 10:27:42 <fcolista> clandmeter, : http://pastebin.com/nZcm4zkq
2016-02-05 10:28:02 <clandmeter> yes thats broken
2016-02-05 10:28:23 <fcolista> http://pastebin.com/nZcm4zkq
2016-02-05 10:28:24 <clandmeter> remove the provides entry compleetely
2016-02-05 10:28:36 <clandmeter> you are settting it to null
2016-02-05 10:28:41 <fcolista> aaaaahhh
2016-02-05 10:29:07 <fcolista> so why the provides appear correctly in .control dir?
2016-02-05 10:29:31 <clandmeter> probably how abuild works
2016-02-05 10:29:37 <clandmeter> i dont know the inner workings
2016-02-05 10:29:52 <fcolista> pushed
2016-02-05 10:30:02 <fcolista> clandmeter, what is provides= used for, actually?
2016-02-05 10:30:29 <clandmeter> it uses to cross reference depends
2016-02-05 10:30:33 <clandmeter> used..
2016-02-05 10:30:43 <clandmeter> so packages know where to depens on
2016-02-05 10:30:48 <clandmeter> depend...
2016-02-05 10:30:59 <clandmeter> damn i should think before hitting enter :)
2016-02-05 10:31:04 <fcolista> lol
2016-02-05 10:31:35 <fcolista> aren't the binary able to figure out themselves from where depends?
2016-02-05 10:31:57 <fcolista> When you compile and you link the libraries
2016-02-05 10:32:00 <clandmeter> the binary as in?
2016-02-05 10:32:10 <clandmeter> abuild will take core of it.
2016-02-05 10:32:13 <clandmeter> lol
2016-02-05 10:32:15 <clandmeter> care
2016-02-05 10:33:01 <fcolista> so it's abuild actually that does the linking.
2016-02-05 10:33:12 <clandmeter> no
2016-02-05 10:33:37 <clandmeter> abuild makes sure dependencies are met
2016-02-05 10:34:07 <clandmeter> then whatever compiler is used will build and link it
2016-02-05 10:34:12 <clandmeter> then abuild will scan the result
2016-02-05 10:34:23 <clandmeter> and make sure depends and provides are correct
2016-02-05 10:35:28 <clandmeter> abuild didnt make use of pkgconf file (*.pc) but since some time ncopa added support for it.
2016-02-05 10:38:47 <clandmeter> ncopa: speex-dev still doesnt provide anything.
2016-02-05 10:39:14 <clandmeter> pc:speex (missing): required by: libshout-dev-2.4.1-r0[pc:speex] libshout-dev-2.4.1-r0[pc:speex]
2016-02-05 10:39:47 <ncopa> maybe a bug in abuild?
2016-02-05 10:40:42 <ncopa> thats weird
2016-02-05 10:41:08 <clandmeter> i think so
2016-02-05 10:41:13 <clandmeter> .PKGINFO file is correct
2016-02-05 10:41:17 <clandmeter> could it be the rc2?
2016-02-05 10:41:41 <fcolista> might be that ignores the pkgrel
2016-02-05 10:41:55 <clandmeter> provides = pc:speex=1.2rc2
2016-02-05 10:42:02 <clandmeter> but it doesnt get added to the apkindedx
2016-02-05 10:42:32 <clandmeter> fcolista: this was probalby the issue you were bumping into.
2016-02-05 10:42:49 <fcolista> 1.2rc3 is out
2016-02-05 10:42:59 <fcolista> i bet if we upgrade to that version, it works
2016-02-05 10:43:10 <clandmeter> i dont think so.
2016-02-05 10:43:47 <fcolista> ah not...it's speexdsp
2016-02-05 10:43:50 <fcolista> not speex
2016-02-05 10:44:08 <clandmeter> are you sure there is rc3?
2016-02-05 10:44:14 <clandmeter> yes
2016-02-05 10:44:16 <fcolista> no is speexdsp
2016-02-05 10:44:18 <fcolista> not speex
2016-02-05 10:44:18 <clandmeter> cause i checked before
2016-02-05 10:49:19 <clandmeter> fcolista: this hack would probalby make it work http://tpaste.us/Apxg
2016-02-05 10:50:07 <clandmeter> but its better to find out what is *really* causing it.
2016-02-05 10:51:04 <fcolista> clandmeter, do you want me to apply that patch?
2016-02-05 10:51:23 <clandmeter> no, or ncopa should be ok with it.
2016-02-05 10:51:45 <clandmeter> but he is busy atm, so just give it some time.
2016-02-05 10:51:49 <fcolista> ok
2016-02-05 10:54:14 <ncopa> i dont like that patch
2016-02-05 10:54:51 <ncopa> but im' ok with adding depends_dev="speex-dev" to libshout for now
2016-02-05 10:55:06 <ncopa> add a comment there
2016-02-05 15:21:31 <yolosnow> hi all
2016-02-05 15:22:24 <yolosnow> is there a policy for porting packages from other distros like debian i.e. glibc or libunwind?
2016-02-05 15:35:23 <skarnet> I am definitely NOT speaking for Alpine when I say this, and this can in NO WAY be interpreted as an official answer
2016-02-05 15:35:55 <skarnet> but IMNSHO it should be written in a FAQ somewhere and the answer should be: "If you want crap, there are a zillion distributions out there that will serve you crap"
2016-02-05 15:38:01 <yolosnow> k thx
2016-02-05 15:38:31 <coredumb> skarnet: :D
2016-02-05 15:38:35 <ncopa> :D
2016-02-05 15:38:39 <yolosnow> then what is the alternative? compiling it myslef?
2016-02-05 15:39:06 <ncopa> i think we have some libunwind package some place
2016-02-05 15:39:11 <ncopa> but i dont know if it works
2016-02-05 15:39:48 <ncopa> and i'm not too excited about stuffing debug code into the binaries
2016-02-05 15:39:56 <ncopa> i prefer core dumps and gdb
2016-02-05 15:40:22 <jirutka> > "If you want crap, there are a zillion distributions out there that will serve you crap"
2016-02-05 15:40:22 <jirutka> I’m with you! 👍
2016-02-05 15:40:39 <ncopa> re glibc, i think andyshinn has something for that
2016-02-05 15:40:59 <ncopa> i am not 100% sure we want a glibc binary
2016-02-05 15:41:18 <skarnet> I wish you were 100% sure you don't want one XD
2016-02-05 15:41:33 <ncopa> https://github.com/andyshinn/alpine-pkg-glibc
2016-02-05 15:41:34 <yolosnow> might be. the problem i have atm is that there is a 3rd party binary which was linked dynamically. i can copy all dependencies myself but i though, maybe somebody else also needs them
2016-02-05 15:42:05 <fcolista> http://wiki.alpinelinux.org/wiki/Running_glibc_programs
2016-02-05 15:42:14 <ncopa> yolosnow: 3rd party binaries is the only reason for a such thing
2016-02-05 15:42:20 <ncopa> but i have mixed feelings about it
2016-02-05 15:42:32 <ncopa> you will often need more than just glibc
2016-02-05 15:42:52 <ncopa> musl libc provides some glibc abi compat
2016-02-05 15:43:58 <andyshinn> i mostly agree... but i have been asked many times if "it can just be added to Alpine repo so we can apk add glibc-compat"
2016-02-05 15:44:11 <andyshinn> so, that is why i ask :)
2016-02-05 15:44:19 <yolosnow> ok ok. its not only them. like i said ...
2016-02-05 15:44:52 <ncopa> what 3rd party binaries needs glibc?
2016-02-05 15:45:21 <yolosnow> but i understand what you mean. i wish it would have been compiled statically. i think microsoft won't care because for them linux is ubuntu
2016-02-05 15:45:33 <yolosnow> it is dnx
2016-02-05 15:45:39 <ncopa> i think, if you want/need glibc, then alpine is not the right thing for you
2016-02-05 15:46:21 <yolosnow> just playing arround, nothing serious
2016-02-05 15:46:30 <yolosnow> (maybe not, yes)
2016-02-05 15:47:27 <ncopa> have you tried dnx with libc6-compat?
2016-02-05 15:47:39 <andyshinn> if you want to play around, here are some commands (specific to a Docker build but should work for any Alpine install): https://github.com/frol/docker-alpine-glibc/blob/master/Dockerfile#L7-L16
2016-02-05 15:48:03 <ncopa> personally, there is one thing i want glibc(-compat) for, and it is netflix :)
2016-02-05 15:49:06 <ncopa> andyshinn: *if* we are to include glibc, then i'd prefer build it from source
2016-02-05 15:49:37 <andyshinn> yea, i agree... i tried pretty hard to build from source, but i ran into some stuff that is way beyond me :(
2016-02-05 15:50:05 <yolosnow> lulz
2016-02-05 15:51:07 <andyshinn> actually, the original use case was for some Golang binaries that we don't have source for and are only compiled Linux x64 dynamic, but i think since then, they are now compiled static and work on musl without change, so my actual use for the glibc package doesn't really exist
2016-02-05 15:51:26 <ncopa> thats better
2016-02-05 15:51:27 <andyshinn> but somehow... people really wanted to do crazy things like Oracle Java on Alpine
2016-02-05 15:51:36 <ncopa> yes
2016-02-05 15:51:43 <ncopa> thats crazy
2016-02-05 15:51:47 <yolosnow> ok i think i got it. no ports. compiling from source is ok too if i find the time.
2016-02-05 15:51:50 <yolosnow> :D
2016-02-05 15:51:50 <andyshinn> and it seems popular enough... so i just leave it for now and try to support them :)
2016-02-05 15:52:18 <jirutka> Oh, just avoid any Go crap, especially binary without sources.
2016-02-05 15:53:00 <yolosnow> why not to try runnng java on it
2016-02-05 15:53:53 <jirutka> Speaking about Java, I’m so happy that there’s already custom OpenJDK build in Alpine, so I don’t have to make it yourself. Gentoo, that I use as my primary OS on servers, probably resigned, because there are stil only ebuilds for Oracle JDK 8. :(
2016-02-05 15:54:11 <yolosnow> yeah maybe it hurst if you rub your ass off to get an image to that size and then java gets installed and it its 200MB again ^^
2016-02-05 15:54:24 <ncopa> openjdk is not so fun either
2016-02-05 15:54:34 <ncopa> i cannot understand how that have could become so popular
2016-02-05 15:54:36 <jirutka> I hope that it’ll get better with JDK 9, thanks to jigsaw.
2016-02-05 15:55:17 <jirutka> me neither… and I basically grow up on Java… I can’t understand how I could be so blind.
2016-02-05 15:55:19 <yolosnow> it is the run for small size OSs
2016-02-05 15:55:34 <andyshinn> yolosnow: yes, exactly, i actually tried it out for a lot of Java apps here, and it is like 250 MB vs 330 MB for base Debian, not really worth it, i love Alpine, but sometimes you just got to know your use case, and another distro might be better suited
2016-02-05 15:55:39 <yolosnow> because of docker
2016-02-05 15:56:01 <jirutka> However, JVM is quite good piece of software, they must just clean it, it’s totally bloated nowdays.
2016-02-05 15:56:16 <yolosnow> there is only ubuntu left then, it doesn't even run on debian
2016-02-05 15:56:29 <yolosnow> nobody likes ubuntu
2016-02-05 15:56:33 <ncopa> :)
2016-02-05 15:57:03 <skarnet> jirutka: I did my masters thesis on the JVM, 19 years ago. It was *already* bloated at the time - to my taste.
2016-02-05 15:57:05 <andyshinn> yea, i think i saw some images where people are deleting all kinds of stuff from the Oracle JDK to slim it down and it still works... scary...
2016-02-05 15:57:34 <ncopa> i think the proper fix is to ask oracle to provide a jdk build against musl libc
2016-02-05 15:57:40 <ncopa> or static
2016-02-05 15:57:48 <skarnet> the proper fix is to ask oracle to die
2016-02-05 15:58:01 <skarnet> and have Java be taken over by better people :P
2016-02-05 15:58:06 <andyshinn> ncopa: i will fly you out to Texas to have beer the day that happens :p
2016-02-05 15:58:38 <ncopa> andyshinn: so you are in texas timezone nowdays :)
2016-02-05 15:58:46 <yolosnow> so since we are off-topic anway ... i am trying to create a minimal service runtime for dnx (.Net) programs
2016-02-05 15:58:48 <andyshinn> :)
2016-02-05 15:59:49 <ncopa> andyshinn: i think its me who owe you a beer for your work on alpine docker images
2016-02-05 15:59:52 <yolosnow> since .Net is used at the company i work in and i want to provide some good reasons to get away from Windows Server
2016-02-05 16:01:16 <andyshinn> haha, that is very minimal in comparison to what you do! i just hope your venture with this Docker stuff is fruitful. please ping me if there is anything we need to do to make the base images better. i already saw some of the official stuff you are working on :)
2016-02-05 16:01:56 <ncopa> worked on nodejs today
2016-02-05 16:02:07 <andyshinn> maybe if you fly out to San Francisco sometime i will try to go there as well (maybe Dockercon?)
2016-02-05 16:02:34 <ncopa> upstream nodejs is looking into oficially support alpine
2016-02-05 16:02:43 <andyshinn> ooooh, that is cool
2016-02-05 16:02:57 <ncopa> i got 'make check' working
2016-02-05 16:03:22 <ncopa> found one issue in our openssl
2016-02-05 16:03:24 <andyshinn> i think now you can start to leverage some klout to get languages and runtimes to better support musl, everyone will win, Alpine and musl will take over the world
2016-02-05 16:03:26 <ncopa> and its fixed
2016-02-05 16:03:46 <ncopa> andyshinn: thats what i am currently working on :)
2016-02-05 16:04:00 <andyshinn> i saw Rich is adding some DNS stuff to musl too, exciting times!
2016-02-05 16:04:05 <ncopa> yes
2016-02-05 16:04:16 <skarnet> I can't wait to finish what I'm working on and jump in with you guys
2016-02-05 16:04:20 <skarnet> I love what you're doing
2016-02-05 16:05:15 <skarnet> (and I want to be there when we take over the world)
2016-02-05 16:05:25 <ncopa> slim down s6
2016-02-05 16:05:30 <ncopa> and youre in ;)
2016-02-05 16:05:56 <skarnet> Man, I still can't believe it's *too big*
2016-02-05 16:06:22 <ncopa> as long as its bigger than openrc its too big
2016-02-05 16:07:04 <skarnet> You do realize that openrc cheats by doing everything in shell, right?
2016-02-05 16:07:16 <ncopa> yup
2016-02-05 16:08:17 <ncopa> you have 2 options:
2016-02-05 16:08:28 <ncopa> 1) work on slimming down s6
2016-02-05 16:08:38 <ncopa> 2) work on adding more features to openrc
2016-02-05 16:08:50 <ncopa> til it gets to the point that it becomes bigger than s6 :)
2016-02-05 16:08:54 <skarnet> XD
2016-02-05 16:09:22 <skarnet> I have my work cut out for me this summer
2016-02-05 16:09:36 <skarnet> damn I hoped to be able to take some vacation this year
2016-02-05 16:17:13 <ncopa> andyshinn: there is one thing with the docker image that i think we need fix
2016-02-05 16:17:23 <ncopa> the download mirror
2016-02-05 16:17:27 <ncopa> we need fix that some way
2016-02-05 16:17:47 <ncopa> what we need is a url for a mirror that will work for everyone
2016-02-05 16:17:58 <ncopa> some kind of CDN
2016-02-05 16:18:06 <andyshinn> hmmm, did you see the alpine.gliderlabs.com one?
2016-02-05 16:18:27 <ncopa> sponsored by fastly?
2016-02-05 16:18:34 <ncopa> i think i saw it
2016-02-05 16:18:39 <andyshinn> yep, global CDN sponsored by them
2016-02-05 16:18:48 <ncopa> how does it work?
2016-02-05 16:19:34 <andyshinn> they use Varnish underneath, so it is basically Varnish running in many geos, and your geo will connect to the closest Varnish, and that Varnish caches stuff from nl.a.o
2016-02-05 16:19:55 <andyshinn> right now i have it set to never cache APKINDEX.tar.gz
2016-02-05 16:20:11 <andyshinn> and 2 weeks for apks, but i think the apk cache can be much larger (maybe couple months)
2016-02-05 16:21:06 <andyshinn> i don't know a good way to cache APKINDEX.tar.gz and invalidate it when it changes, so i just made a rule to not cache it, so it will have pointers to the latest files, and since the apks don't change they can be cached for a long time
2016-02-05 16:22:03 <andyshinn> so give it a try and compare to nl.a.o, and maybe we can switch it to be something like  dl-cdn.a.o?
2016-02-05 16:22:28 <andyshinn> or actually, i can add multiple hostnames, so it will respond on dl-cdn.alpinelinux.org as well
2016-02-05 16:23:16 <andyshinn> i need to ask Fastly if they are ready for the traffic though, cause it will surly jump ten-fold once it is more official
2016-02-05 16:30:11 <ncopa> we are looking for soemthing we can push rync to
2016-02-05 16:30:26 <ncopa> hm
2016-02-05 16:30:48 <ncopa> not caching apkindex
2016-02-05 16:31:07 <ncopa> i thin that should work actually
2016-02-05 16:32:12 <ncopa> we got a couple of instances from scaleway
2016-02-05 16:32:32 <ncopa> i think i'd like move nl.a.o to there
2016-02-05 16:32:47 <ncopa> maybe rename it too
2016-02-05 16:33:02 <ncopa> dl-master.a.o or similar
2016-02-05 16:33:18 <ncopa> dl-cdn.a.o sounds good
2016-02-05 16:33:28 <andyshinn> well, i think this model, you don't really "rsync" to the CDN, you rsync to a master, and the CDN will pull once (or a couple times) from the master to cache
2016-02-05 16:33:43 <andyshinn> so dl-cdn would just cache from dl-master
2016-02-05 16:33:52 <andyshinn> and we don't give out dl-master as a mirror
2016-02-05 16:34:07 <clandmeter> talking about scaleway and docker, whats this about? Error response from daemon: Cannot start container 923379cb9e700432045cf4e4ed84427f22eb49ff47ddb0689b44ddbf472ab51d: [8] System error: write /sys/fs/cgroup/docker/923379cb9e700432045cf4e4ed84427f22eb49ff47ddb0689b44ddbf472ab51d/cgroup.procs: no space left on device
2016-02-05 16:34:24 <clandmeter> (i never touched docker before)
2016-02-05 16:34:43 <andyshinn> so build -> rsync to dl-master <- CDN pull cache from dl-master <- user dl from CDN dl-cdn
2016-02-05 16:35:07 <ncopa> clandmeter: i dont think scaleway has the proper hw support for docker
2016-02-05 16:35:11 <ncopa> but i dont know really
2016-02-05 16:35:23 <andyshinn> clandmeter: it works, but you need to load a custom kernel
2016-02-05 16:35:33 <clandmeter> ok
2016-02-05 16:35:37 <clandmeter> i know docker should work
2016-02-05 16:35:41 <clandmeter> its their config
2016-02-05 16:35:50 <andyshinn> it is an advanced option when you boot the instance, check out https://blog.scaleway.com/2015/05/22/scaleway-bootscript-simple-kernel-management-for-your-c1-server/
2016-02-05 16:36:47 <clandmeter> i know how to change the kernel, jsut didnt know i had to for docker.
2016-02-05 16:41:16 <clandmeter> hmm, im running a newer kernel then the ones that are listed.
2016-02-05 16:41:47 <clandmeter> i have a feeling its time for weekend.
2016-02-05 16:42:15 <clandmeter> drink a bottle of wine tonight and reset my brains cells (the ones that survive)
2016-02-05 16:43:11 <andyshinn> well, you are making room for those remaining cells to relax better
2016-02-05 16:44:07 <andyshinn> ncopa: i added dl-cdn.alpinelinux.org to the responding hosts for the Varnish config, you can add CNAME to global.prod.fastly.net and it should start working, i also bumped the cache TTL for apk to 6 months
2016-02-05 16:53:40 <ncopa> i'll add it right away
2016-02-05 16:55:11 <ncopa> 6 month sounds much
2016-02-05 16:55:29 <ncopa> its probalby good
2016-02-05 16:55:38 <ncopa> thats a stable release cycle
2016-02-05 16:59:42 <ncopa> seem sot work
2016-02-05 16:59:51 <ncopa> seems to work i mean
2016-02-05 19:37:39 <pluesch> kimo_sabe: when you are here, can you try to crash your kvm vm by using dd?
2016-02-05 19:38:06 <pluesch> I can't crash my testing vms by throwing i/o at them.
2016-02-05 20:08:35 <przemoc> ncopa: I don't remember whether you said it clearly back then, but only just now I read that you work at Docker.  it sounds like a good place for Alpine Linux related efforts.  so after these few weeks, is it a good place? :)
2016-02-05 20:14:14 <ncopa> przemoc: its great :)
2016-02-05 20:17:09 <przemoc> good to hear that
2016-02-05 20:17:23 <przemoc> motivation is crucial in keeping open source in healthy state
2016-02-05 20:17:47 <przemoc> in what way s6 is too big for AL right now?
2016-02-05 20:19:33 <ncopa> iirc its 2MB?
2016-02-05 20:19:52 <ncopa> openrc is 620kB
2016-02-05 20:20:33 <ncopa> this is kind of a piece that you you dont easily can opt out
2016-02-05 20:21:06 <ncopa> the idea with alpine is that the core is as small as possible
2016-02-05 20:21:07 <jirutka> interesting, why it’s so big? it’s just a process supervisor, isn’t it?
2016-02-05 20:21:24 <ncopa> then you can add whatver bloat you want
2016-02-05 20:21:41 <ncopa> thats a question for skarnet
2016-02-05 20:22:06 <przemoc> https://pkgs.alpinelinux.org/contents?pkgname=s6&arch=x86_64&repo=main there are many tools in it, but yes, 2 MB is still more than really necessary, I guess
2016-02-05 20:22:17 <jirutka> do you know about any other process supervisor that is more lightweight and plays well with OpenRC?
2016-02-05 20:22:58 <ncopa> i think s6 is about the only process supervisor that plays well with openrc
2016-02-05 20:23:09 <ncopa> if it plays well i dont know
2016-02-05 20:23:12 <jirutka> hmm, I’m thinking that this may be quite interesting theme for thesis
2016-02-05 20:23:15 <ncopa> that play at all
2016-02-05 20:23:28 <jirutka> me neither, I just know that OpenRC has support for s6
2016-02-05 20:23:49 <ncopa> s6 has lots of ideas from djb
2016-02-05 20:23:59 <ncopa> qmail
2016-02-05 20:24:12 <ncopa> that is a bit untraditional
2016-02-05 20:24:47 <ncopa> imho it feels a bit "weird"
2016-02-05 20:24:47 <przemoc> it's spiritually based on daemontools
2016-02-05 20:24:53 <ncopa> right
2016-02-05 20:24:55 <skarnet> why is s6 big? simple: it does lots of things
2016-02-05 20:25:04 <jirutka> are you able to specify requirements for process manager that would statisfy needs of Alpine Linux etc?
2016-02-05 20:25:31 <skarnet> process supervision, notification, fd-holding, tools for writing daemons, tools for logging
2016-02-05 20:26:04 <skarnet> what I'm going to do is separate what's essential to boot a system with s6-rc from what is not
2016-02-05 20:26:19 <skarnet> and see if the size of the "essential" package is acceptable
2016-02-05 20:26:31 <ncopa> http://skarnet.org/software/s6/
2016-02-05 20:26:43 <ncopa> the ideas presented there is great
2016-02-05 20:26:58 <ncopa> http://skarnet.org/software/s6/why.html
2016-02-05 20:27:31 <ncopa> skarnet: thats actually a great idea, split out what is essential boot system
2016-02-05 20:27:38 <skarnet> Honestly, I never expected disk size usage to be an issue. I can truthfully say s6-rc will be the most efficient thing you'll ever see when it comes to correctly booting a system (dependencies, short paths, low CPU and RAM usage)
2016-02-05 20:27:39 <ncopa> and the other stuff can be opt-in
2016-02-05 20:27:49 <skarnet> because little use of CPU and RAM is what I focused on
2016-02-05 20:28:10 <ncopa> maybe we can just split the packages a bit?
2016-02-05 20:28:18 <skarnet> yes, that's what I'm going to try
2016-02-05 20:28:36 <przemoc> s6-boot, s6-core, s6-extras and so on
2016-02-05 20:29:37 <skarnet> I feel this metric is unfair because openrc will spawn a zillion shells and eat a lot of cpu and ram
2016-02-05 20:29:46 <przemoc> I agree
2016-02-05 20:30:24 <skarnet> s6-rc will never spawn a shell unless a package's init scripts themselves do so
2016-02-05 20:30:59 <skarnet> but challenge accepted, I'll give you something that fits on the disk
2016-02-05 20:31:19 <przemoc> 1.44MB floppy
2016-02-05 20:33:29 <ncopa> this also feels a it weird: http://skarnet.org/software/skalibs/libstddjb/
2016-02-05 20:34:15 <skarnet> what is weird ? (apart from the fact a lot of doc is still lacking)
2016-02-05 20:34:57 <ncopa> feels like libc replacement
2016-02-05 20:35:20 <skarnet> it is, partly.
2016-02-05 20:35:49 <ncopa> im not sayin its bad
2016-02-05 20:36:07 <ncopa> just weird
2016-02-05 20:36:11 <ncopa> or different
2016-02-05 20:36:18 <jirutka> these are examples of ”runscripts”? o.O https://github.com/skarnet/s6-rc/tree/master/examples/source
2016-02-05 20:36:18 <skarnet> the most important thing, I think, is that libc provides no interface from asynchronous buffered i/o
2016-02-05 20:36:33 <skarnet> and I need a lot of asynchronous buffered i/o
2016-02-05 20:36:39 <skarnet> jirutka: no
2016-02-05 20:36:54 <ncopa> execline is also a bit weird
2016-02-05 20:36:58 <skarnet> those are s6-rc service definitions
2016-02-05 20:37:00 <ncopa> but concept is interesting
2016-02-05 20:37:28 <ncopa> how big is skalibs?
2016-02-05 20:37:35 <jirutka> skarnet: so it’s a replacement of runscripts, yes?
2016-02-05 20:37:44 <ncopa> 170k
2016-02-05 20:38:11 <skarnet> jirutka: s6-rc services can be longruns (i.e. daemons that will be supervised by s6) with run scripts, or oneshots (i.e. scripts that run once) with just an up and a down script
2016-02-05 20:38:52 <skarnet> ncopa: execline is mostly what I use to auto-generate scripts, because it's much easier to auto-generate than a shell script
2016-02-05 20:39:02 <skarnet> (and also faster to launch)
2016-02-05 20:39:14 <ncopa> i figured its faster
2016-02-05 20:39:27 <ncopa> due to it just forwards the exec without forking
2016-02-05 20:39:33 <jirutka> skarnet: this is what is quite a problem for me: https://github.com/skarnet/s6-rc/tree/master/examples/source/smtpd-4 … service defintion is spread across gazilion files, it’s quite unclear
2016-02-05 20:39:33 <ncopa> if i understood things correctly
2016-02-05 20:39:42 <ncopa> which is why i say its interesting
2016-02-05 20:40:06 <ncopa> skarnet: please remember: weird != bad
2016-02-05 20:40:13 <skarnet> ncopa: yes, and you also save on a lot of signal management, memory management etc.
2016-02-05 20:40:32 <skarnet> but the most important thing is you only parse the command line once
2016-02-05 20:41:12 <skarnet> jirutka: if that's a UI problem, I fully expect people to write format converters
2016-02-05 20:41:37 <skarnet> the s6-rc service definition format was intentionally made to be easy to parse and also easy to write
2016-02-05 20:41:49 <skarnet> (by automated tools)
2016-02-05 20:42:04 <ncopa> would be nice if fabled could have a closer look at s6 at some point
2016-02-05 20:42:04 <jirutka> skarnet: like OpenRC runscript (or something similar) → your service definition?
2016-02-05 20:42:22 <skarnet> that's harder
2016-02-05 20:43:03 <skarnet> I meant, if you don't like the fact that the definition is spread across multiple files, you can write a config file in your own format and have a simple parser (perl/python/whatever) turning your favorite format into the s6-rc source format
2016-02-05 20:43:06 <jirutka> skarnet: so I should look at it like a FS-based database more than a configuration format?
2016-02-05 20:43:16 <skarnet> exactly
2016-02-05 20:43:32 <skarnet> also, this is the "source" format, which will be compiled
2016-02-05 20:43:35 <jirutka> :)
2016-02-05 20:44:00 <skarnet> the dependency analysis is done at compile-time
2016-02-05 20:44:15 <skarnet> so at run-time you already have your dependency tree done
2016-02-05 20:45:09 <jirutka> hmm, interesting
2016-02-05 20:46:15 <jirutka> i’ll bookmark it and read more about it
2016-02-05 20:46:24 <skarnet> compilation produces a binary db containing the dependency tree and oneshot scripts, a service name -> service number map, and a collection of service directories suitable for s6
2016-02-05 20:48:29 <skarnet> the point is for you to be able to just define your dependencies (i.e. can only log stuff to /var/log once /var/log is mounted...) in the source, and then at run-time the service manager will only start your /var/log loggers once the "mount /var/log" oneshot service has completed successfully
2016-02-05 20:48:32 <skarnet> and so on
2016-02-05 20:49:39 <jirutka> I guess that it doesn’t need any PID files…?
2016-02-05 20:50:43 <skarnet> if I say one day that something I wrote needs a PID file, shoot me - it's an alien impersonating me
2016-02-05 20:50:50 <jirutka> :)
2016-02-05 21:24:44 <kimo_sabe> pluesch: trying to crash
2016-02-05 21:48:47 <kimo_sabe> pluesch: ssfalskdjf
2016-02-05 21:52:44 <kimo_sabe> jjj
2016-02-05 21:53:12 <kimo_sabe> pluesch: err, stupid lag. Anyway, no luck crashing with dd yet, but yes with rm after a cp
2016-02-05 21:59:03 <pluesch> kimo_sabe: like that? http://sprunge.us/PARi
2016-02-05 21:59:37 <pluesch> I can't get a crash with this script btw.
2016-02-05 22:01:20 <kimo_sabe> pluesch: trying that script now
2016-02-05 22:53:57 <kimo_sabe> pluesch: still going strong, go plain block IO doesn't seem to cause it. Though with the urandom it's pretty slow
2016-02-05 23:09:28 <skarnet> I know ncopa left, but this is for the record
2016-02-05 23:09:54 <skarnet> stripped down skalibs+execline+s6+s6-rc to 712k by only keeping essentials
2016-02-05 23:10:44 <jirutka> Does he log IRC communication when he’s offline or should I remind it to him?
2016-02-05 23:10:54 <skarnet> this channel is logged \o/
2016-02-05 23:10:58 <jirutka> okay
2016-02-05 23:11:42 <jirutka> Is it possible to strip s6 just to process supervisor, i.e. omit s6-rc? How big it’ll be then?
2016-02-05 23:11:56 <skarnet> yup, it's possible
2016-02-05 23:12:10 <skarnet> let me check the deps
2016-02-05 23:12:59 <skarnet> but if you do that you basically won't have init scripts, you'll only have supervision
2016-02-05 23:13:10 <skarnet> which is great but you'll still need to use something for your init scripts
2016-02-05 23:13:11 <jirutka> yeah, that’s exactly what I mean
2016-02-05 23:13:23 <jirutka> I’m thinking about using OpenRC with s6 just for supervising.
2016-02-05 23:13:39 <skarnet> and get the worst of both worlds ? :P
2016-02-05 23:13:51 <pluesch> kimo_sabe: how can we isolate this crash better? -.-
2016-02-05 23:15:22 <jirutka> Nope… Alpine (and Gentoo) currently use OpenRC, there are a lot of runscripts already written. I don’t think that it’s realistic to change it in short-term. However, it’d be great to utilize s6 as a process supervisor, because OpenRC doesn’t handle this.
2016-02-05 23:15:53 <skarnet> I know :/
2016-02-05 23:16:08 <jirutka> And is I know, OpenRC already provides some support for s6 supervisor; however I didn’t try it.
2016-02-05 23:16:14 <skarnet> it's already packaged, you can install it - it's just not stripped for minimal disk usage yet
2016-02-05 23:16:41 <jirutka> Yeah, but as we know, it’s kinda deal breaker for ncopa.
2016-02-05 23:17:36 <skarnet> what functionality do you want me to include in the calculation? do you want the completely barebones thing without even s6-log ?
2016-02-05 23:17:48 <jirutka> what is s6-log?
2016-02-05 23:18:00 <skarnet> the logger with automatic rotation
2016-02-05 23:18:28 <jirutka> uh, what? is it init system or everything-but-kitching-sink as systemd hell?
2016-02-05 23:18:35 <skarnet> reads its stdin, stores stuff in an automatically rotated directory. Only way to avoid the syslog/logrotate race condition.
2016-02-05 23:19:58 <skarnet> it's a toolbox, that provides lots of tools. Why do you think it's big? The difference with systemd is that it's actually modular, and follows Unix principles.
2016-02-05 23:21:03 <jirutka> Sorry for comparison with systemd, it was just the first what came into my mind when I read that it handles also logs.
2016-02-05 23:22:48 <jirutka> Okay, could you calculate the size with just supervisor, without s6-log etc?
2016-02-05 23:22:51 <skarnet> "s6" doesn't "handle logs". It provides mechanism for reliable log storage. Don't want to use it? then don't.
2016-02-05 23:23:46 <jirutka> So it’s not a syslog replacement, but more a logrotate replacement? i.e. handles just a storage?
2016-02-05 23:25:25 <skarnet> It's both. The thing is, syslogd is horribly designed, and so is logrotate; the modularity shouldn't happen by splitting those tools, the modularity should happen by not fanning in all the logs into syslogd.
2016-02-05 23:26:15 <skarnet> You *can* emulate the syslogd mechanism with s6 tools, if you so choose, and for less resources than a "traditional" syslogd would use. But it's not "what s6 does".
2016-02-05 23:27:15 <jirutka> well, so how it works? catches stdout of the process and writes it into a file, instead of syslog socket?
2016-02-05 23:28:43 <skarnet> s6-logs reads its stdin and processes it according to instructions that it has been given; most likely write it into a file that it rotates when it grows beyond a certain size.
2016-02-05 23:28:50 <skarnet> s6-log*
2016-02-05 23:29:30 <skarnet> the best practice is to have one logger per daemon. Each logger instance uses little private dirty memory, so that's fine.
2016-02-05 23:29:38 <jirutka> aha
2016-02-05 23:30:18 <skarnet> you can also have a superserver listening to /dev/log, processing the data, and funneling it into a s6-log process, if you so choose.
2016-02-05 23:31:08 <skarnet> 309k would be the size of the minimal set you're asking for.
2016-02-05 23:31:43 <jirutka> this is not bad, thanks for calculation! :)
2016-02-05 23:31:53 <skarnet> But that's probably not a good idea - it's everything linked dynamically, so you'd actually lose CPU and RAM.
2016-02-05 23:32:38 <jirutka> Not if I’ll use just supervisor, not anything else…?
2016-02-05 23:33:15 <skarnet> you still have to use the dynamic loader every time you spawn a binary.
2016-02-05 23:33:45 <jirutka> it’s not possible to compile it statically?
2016-02-05 23:34:22 <skarnet> of course it's possible and that's what I recommend. But it generally takes a bit more disk. I'd guesstimate +50% in this case.
2016-02-05 23:34:54 <jirutka> oaky
2016-02-05 23:34:54 <skarnet> so if your goal is to save disk space, dynamic binaries are smaller.
2016-02-05 23:35:19 <skarnet> (I obviously included the size of the .so's in the calculation.)
2016-02-05 23:35:21 <jirutka> do you know about some efforts to create a configuration format for s6-rc?
2016-02-05 23:36:15 <skarnet> Not yet, because the tool isn't well known yet. We're probably 3-4 people using it, and AFAIK, the others are also happy with the current format. :)
2016-02-05 23:37:09 <skarnet> But when I'm free, i.e. probably towards the end of this year, I intend to do a complete pass over all the Alpine init scripts and convert them by hand.
2016-02-05 23:37:30 <skarnet> so examples will abound.
2016-02-05 23:37:39 <jirutka> Wow, this is impressive commitment!
2016-02-05 23:38:44 <skarnet> It's something that must be done at least once if we want to escape the grim "systemd/openrc/sysvrc" landscape.
2016-02-05 23:39:38 <jirutka> However, I think that it’d be better to design some nice configuration format before that. ;)
2016-02-05 23:40:36 <skarnet> "nice" is in the eye of the beholder. My automation loves the current format. Automation that produces service definitions will also love it.
2016-02-05 23:40:39 <skarnet> What you want is a UI.
2016-02-05 23:41:11 <skarnet> I'm not UI-oriented at all - I suck at those things. But lots of people have interest and practice in those things; I expect they'll contribute.
2016-02-05 23:42:34 <yth> out of interest - where'd the name (s6) come from?
2016-02-05 23:42:35 <jirutka> What exactly do you mean with UI? Command line utility like rc-service, rc-status, …?
2016-02-05 23:43:02 <jirutka> yth: skarnet.org's small and secure supervision software suite
2016-02-05 23:43:02 <skarnet> jirutka: you want a human-friendly configuration format.
2016-02-05 23:43:11 <skarnet> ^
2016-02-05 23:43:11 <jirutka> yeah, exactly
2016-02-05 23:43:50 <yth> fair enough!
2016-02-05 23:44:49 <skarnet> jirutka: so, you want a config file. I don't like writing config file parsers (especially in C). But the s6-rc source format is intentionally easy to generate. So, if you (or anyone else) is so incline, you can take your favorite Perl and hack a quick format converter.
2016-02-05 23:45:11 <jirutka> That’s what I’m thinking about :)
2016-02-05 23:45:14 <skarnet> That would read your config file and create a definition directory that s6-rc understands.
2016-02-05 23:46:13 <jirutka> However, I’d definitely not prefer Perl. :P
2016-02-05 23:46:35 <jirutka> I think that Lua would be good choose, especially when we consider Alpine.
2016-02-05 23:47:37 <jirutka> The bad is that I have already too many projects and interests, but this is so tempting… damn XD
2016-02-05 23:49:11 <skarnet> Ha. Take your time. World domination isn't for tomorrow. Next year, perhaps.
2016-02-05 23:50:14 <jirutka> Maybe I’m too pessimist, but if people chose systemd and allow it to colonize linux world, then we’re just doomed. :(
2016-02-05 23:50:51 <jirutka> People almost always choose the worst solution that is available.
2016-02-05 23:51:07 <skarnet> You are a bit pessimistic: there are a lot of resistance islands and with Alpine, you're in a solid one
2016-02-05 23:51:22 <skarnet> the fact that ncopa works at Docker now is pretty huge.
2016-02-05 23:51:39 <jirutka> I know, Gentoo is the other one, but these lands are pretty small.
2016-02-05 23:51:57 <skarnet> if Alpine becomes the de facto standard for guests in containers, then that's a place systemd isn't going to invade.
2016-02-05 23:52:04 <jirutka> Well, I consider Docker as one of the examples of how people choose the worst solution…
2016-02-05 23:52:30 <skarnet> oh, Docker is far from perfect, but my point is that containers *are* the future, one way or another
2016-02-05 23:52:41 <jirutka> yeah, containers
2016-02-05 23:52:47 <jirutka> but containers are not just Docker
2016-02-05 23:53:04 <jirutka> you really don’t need Docker or even LXC to use containers
2016-02-05 23:53:26 <skarnet> I know, I'll be doing my own containers in a month or two :P
2016-02-05 23:53:45 <jirutka> Really? I’m very interested!
2016-02-05 23:54:01 <jirutka> I’m so depressed from the current state that I’m also thinking about creating my own tool.
2016-02-05 23:54:14 <skarnet> oh? is lxc bad?
2016-02-05 23:54:18 <jirutka> Something very simple, yet usable and secure.
2016-02-05 23:54:23 <jirutka> 40k LOC is bad
2016-02-05 23:54:28 <skarnet> ew. indeed.
2016-02-05 23:55:03 <jirutka> I’m thinking about something like https://github.com/stamf/shocker, but not in Bash…
2016-02-05 23:55:20 <jirutka> and with more security
2016-02-05 23:55:28 <skarnet> well I'll be doing it as part of the project for my current customer. I'll see what I can reuse afterwards, but he shouldn't have objections to opensourcing it.
2016-02-05 23:56:02 <kimo_sabe> there's only so much security you can have when making 20 copies of a vulnerable copy of openssl
2016-02-05 23:56:31 <jirutka> I’m currently looking at https://github.com/tailhook/vagga; the best is that it’s written in Rust, not in shitty Go as almost all other container tools.
2016-02-05 23:56:35 <skarnet> kimo_sabe: that's not on the container implementation, that's on the person who designs the stack. :)
2016-02-05 23:57:55 <skarnet> jirutka: Go is actually a pretty decent language. The only beef I have with it is its runtime, that needs a nuclear power plant to execute.
2016-02-05 23:57:58 <kimo_sabe> skarnet: the whole drive behind containerizing things is to now have to upgrade from the crusty old version of X just because no distribution in their right mind would keep that version around :)
2016-02-05 23:58:00 <jirutka> If you like C, then maybe https://github.com/ghedo/pflask can interest you.
2016-02-05 23:58:21 <kimo_sabe> s/now/not/
2016-02-05 23:59:07 <jirutka> I disagree. I think that Go is so horribly designed, denies so many really good best practices, that it must be some evil intention.
2016-02-05 23:59:10 <skarnet> kimo_sabe: yes, but don't blame the people who provide solutions to crap problems: they adapt to the market. Blame the people who perpetuate the crap problems instead. :)
2016-02-06 00:01:06 <skarnet> jirutka: a lot of what people see in a language is religion. I won't enter religious wars. :)
2016-02-06 00:01:10 <kimo_sabe> skarnet: I don't blame the tool makers. They aren't the ones deciding we need to upload all our core business functions to "the cloud" so amazon can bill us for what we're already doing
2016-02-06 00:01:15 <jirutka> okay XD
2016-02-06 00:03:24 <skarnet> kimo_sabe: the only way to remain sane in a crapsack world with clueless decision makers is to create your own island of competency and do things you like inside of it while disregarding what's happening outside.
2016-02-06 00:04:07 <jirutka> Yeah, but it’s extremly time consuming :(
2016-02-06 00:05:00 <kimo_sabe> skarnet: here here.
2016-02-06 00:06:23 <jirutka> I must go. It was interesting discussion, thanks! bye
2016-02-06 00:06:28 <skarnet> gn!
2016-02-06 00:14:44 <kimo_sabe> pluesch: hmm, what similarties do we have. LVM-backed block devices? Alpine obviously. Procs? Xeon E5405s here, 2x4 core
2016-02-06 00:34:16 <pluesch> kimo_sabe: I'm using qemu from edge, because ncopa did some changes to the package after I reported the issue. Procs: Xeon E5-2620v3
2016-02-06 00:35:09 <pluesch> it should not be related to procs, because I have no problem when I'm using Void Linux and their qemu package.
2016-02-06 00:38:18 <kimo_sabe> pluesch: I was thinking maybe some sort of SMP/synchronization glitch (long shot), but you've tried both alpine & void on the same hardware, right? So that rules that out
2016-02-06 00:42:03 <kimo_sabe> pluesch: I think I saw it on an alpine vm when checking out aports as well as my prod Debian. And multiple times just rsyncing over the Maildir for testing to my Debian VM for trying to nail this down
2016-02-06 01:45:35 <nmeum> > 00:09 < skarnet> stripped down skalibs+execline+s6+s6-rc to 712k by only keeping essentials
2016-02-06 01:45:41 <nmeum> very good \o/
2016-02-06 01:46:15 <nmeum> hm, ncopa doesn't seem to have an irc bouncer anymore
2016-02-06 01:47:04 <nmeum> anyways, am I missing something or is it completly useless to set the reporev variable in an APKBUILD when using the dafault snapshot function with git repositories? http://git.alpinelinux.org/cgit/abuild/tree/abuild.in#n2041
2016-02-06 01:47:12 <nmeum> *default
2016-02-06 03:33:44 <ammunta> skarnet: what's "essentials"
2016-02-06 03:40:53 <ammunta> anyway I suspect the use cases for "needs detailed dependency management" and "prefers to fit on a floppy" are p disjoint
2016-02-06 03:47:02 <ammunta> I have a (p stupid, terrible) lua tool which takes in lua code and executes it to build up a dict which it spits out as a directory tree
2016-02-06 03:48:44 <ammunta> I'm not satisfied with the code itself, but
2016-02-06 03:53:32 <ammunta> extending it to make config nicer to write was basically a matter of writing some tree-generating functions
2016-02-06 03:54:27 <ammunta> i mean ... it's hideously overpowered for the purpose, but
2016-02-06 03:57:04 <ammunta> in the process I discovered why lua has that ridiculous function called on single string/table parens omission syntactic sugar abomination probably
2016-02-06 04:01:05 <ammunta> lua isn't a great language for uh ... doing anything with files
2016-02-06 04:01:05 <ammunta> though
2016-02-06 04:01:38 <ammunta> well
2016-02-06 04:01:42 <ammunta> directories, worse
2016-02-06 07:44:17 <skarnet> ammunta: "essentials" = supervision tree + all the binaries needed by s6-rc
2016-02-06 08:34:23 <xming> https://www.brianchristner.io/docker-is-moving-to-alpine-linux/
2016-02-06 09:04:08 <fabled> so...
2016-02-06 09:04:10 <fabled> we got slashtted
2016-02-06 09:04:16 <fabled> hope the servers take it ;)
2016-02-06 09:06:39 <skarnet> excellent stress-test for Alpine software :)
2016-02-06 09:07:26 <fabled> fortunately we have static web pages, non-bloated html, and decent pipes; and very performant software stack. so far itlooks ok :)
2016-02-06 09:08:33 <skarnet> prepare a press release: "Alpine servers survive slashdotting without a sweat"
2016-02-06 09:26:06 <xming> What slashdotting? Our server didn't even notice anything particular
2016-02-06 09:44:28 <pluesch> kimo_sabe: yes. tested it with exact same hw
2016-02-06 09:45:41 <pluesch> kimo_sabe: so the script that I gave you was not crashing the vm for you either?
2016-02-06 09:46:23 <pluesch> can you try to make a script with what I can get a crash?
2016-02-06 09:57:03 <kunkku> heh, systemd mentioned in the 1st comment at /.
2016-02-06 09:59:11 <kunkku> Lennart's world domination plan gets seriously disrupted by Docker switching to non-systemd distro
2016-02-06 10:12:20 <pluesch> :D
2016-02-06 10:15:06 <xming> not much meaningful comments these days on /.
2016-02-06 10:15:15 <xming> I've got 5 mod points to spend :D
2016-02-06 12:34:28 <nmeum> could someone take a look at %1542 ?
2016-02-06 13:52:15 <NIN101> shouldn't this commit http://git.alpinelinux.org/cgit/aports/commit/?id=6a5bee5ff0ce482289000c1b5c51983d4e9445b0 be cherry picked to stable as it security relevant?
2016-02-06 13:55:35 <nmeum> NIN101: yes, generally speacking this should have been cerry picked ask ncopa maybe there is a specific reason why it wasn't…
2016-02-06 13:55:39 <nmeum> *speaking
2016-02-06 14:02:23 <NIN101> nmeum: do you know whether he hangs out on IRC or should I write an email?
2016-02-06 14:08:42 <nmeum> NIN101: usually he doesn't hang out here on the weekend, you could create an issue in redmine and assign it to him
2016-02-06 16:14:14 <raees> hey everyone!
2016-02-06 16:14:54 <raees> I'm trying to building something and get an error that execinfo.h file was not found. Any ideas?
2016-02-06 21:05:22 <xming> musl doens't have execinfo.h
2016-02-06 21:06:02 <xming> oh (s)he's gone
2016-02-06 23:12:54 <mosez> there is no phantomjs package available on alpine?
2016-02-06 23:21:22 <antonym> has anyone looked at adding support for memdisk from pxe into the alpine ISOs using memdiskfind/phram/mtdblock?  it lets you use memdisk to load the ISO into RAM and then allows it to actually locate the mountpoint
2016-02-06 23:32:27 <mosez> hum... i tried to get meteor web apps running on alpine... seems to be not possible :(
2016-02-07 13:03:43 <nmeum> does anybody have access to the armhf builder? If so: Is slock-1.2.tar.gz still located in /var/cache/distfiles what is its checksum?
2016-02-07 21:42:31 <mitchty> what is meteor
2016-02-07 21:43:03 <jirutka> a JS framework? provide some context…
2016-02-07 21:43:26 <mitchty> catching up on old irc didn't look at how old mosez's comment was
2016-02-07 21:43:54 <mitchty> i'm not too hip to javascript stuff
2016-02-07 21:44:30 <jirutka> ah, I see now… yeah, he probably mean https://www.meteor.com
2016-02-07 21:46:19 <mitchty> danke jirutka, quick look and it looks complex, going back to porting ghc to arm :)
2016-02-07 21:46:43 <jirutka> ghc… that’s Haskell?
2016-02-07 21:46:48 <mitchty> yep
2016-02-07 21:46:51 <jirutka> cool!
2016-02-07 21:47:24 <mitchty> currently testing out an experiment with llvm
2016-02-07 21:47:55 <mitchty> getting a bootstrap compiler is my main issue
2016-02-07 21:48:40 <mitchty> have a rather evil plan to build all the binaries statically, have hit too many linker issues
2016-02-07 21:49:18 <jirutka> good luck!
2016-02-07 21:49:40 <mitchty> only problem is it takes ages to compile this stuff
2016-02-07 21:50:12 <mitchty> in between trying to get alpine running on my hummingboard gate
2016-02-07 21:50:25 <jirutka> distcc and some nice cluster can’t help?
2016-02-07 21:50:50 <mitchty> ghc is self hosted, doesn't use c for much past the runtime
2016-02-07 21:51:06 <jirutka> aha
2016-02-07 21:51:33 <mitchty> it also does a 3 stage compile when cross compiling so you're compiling 3x
2016-02-07 21:51:35 <jirutka> hmm http://stackoverflow.com/a/10323536/2217862
2016-02-07 21:52:10 <mitchty> heh, my port is already crazy enough as it is
2016-02-07 21:52:39 <mitchty> https://github.com/mitchty/alpine-linux-ghc-bootstrap/blob/master/ghc/APKBUILD
2016-02-07 21:52:56 <mitchty> looks like next rc for 8.0 is out, if this experiment works i should be able to build it
2016-02-07 21:55:37 <mitchty> but more want the arm soc working, 4g of ram is nice
2016-02-07 22:06:10 <ScrumpyJack> i've compiled something on alpine on RPi2, runs fine, I copy it to a A+ and it seg faults
2016-02-07 22:06:50 <ScrumpyJack> what's missing on my A+ i wonder?
2016-02-07 22:07:17 <ScrumpyJack> same musl libraries on both CD cards
2016-02-07 22:13:49 <ScrumpyJack> strace shows a SIGV_MAPERR
2016-02-07 22:27:12 <ScrumpyJack> it was different releases of musl
2016-02-08 08:44:07 <ScrumpyJack> morning
2016-02-08 08:44:29 <ScrumpyJack> how is tmpfs size calulated on raspberry pi?
2016-02-08 08:45:23 <clandmeter> you can check kernel documentation
2016-02-08 08:45:32 <clandmeter> i think its half of the available memory?
2016-02-08 08:46:05 <clandmeter> size:	   The limit of allocated bytes for this tmpfs instance. The
2016-02-08 08:46:05 <clandmeter>            default is half of your physical RAM without swap. If you
2016-02-08 08:46:06 <clandmeter> 	   oversize your tmpfs instances the machine will deadlock
2016-02-08 08:46:07 <ScrumpyJack> minus video memory i guess
2016-02-08 08:46:35 <clandmeter> video is not calculated as availble memory i think
2016-02-08 08:46:49 <clandmeter> but i think you can set it as a boot flag
2016-02-08 08:46:52 <clandmeter> not sure though
2016-02-08 08:47:03 <clandmeter> check init script
2016-02-08 08:47:09 <clandmeter> if you need of ofc
2016-02-08 08:47:20 <clandmeter> s/of/it
2016-02-08 08:47:40 <ScrumpyJack> (physical RAM - video reserved RAM) /2
2016-02-08 08:51:48 <ScrumpyJack> alpine-sdk doesn't fit on an RPi (512M RAM) any more
2016-02-08 08:52:04 <ScrumpyJack> (tmpfs is 218M)
2016-02-08 08:56:24 <ScrumpyJack> i read that some folks have a non-squashfs SD card installation of Alpine Linux on RPi.
2016-02-08 08:56:59 <ScrumpyJack> are there any notes about that lying around?
2016-02-08 08:58:04 <ScrumpyJack> I had to remount / with 400M to get X11 + alpine-sdk to installed
2016-02-08 09:05:11 <clandmeter> ScrumpyJack: you can mount /var on the sd
2016-02-08 09:06:19 <ScrumpyJack> sorry, I'm not quite sure what do you mean
2016-02-08 09:06:37 <clandmeter> but probably /usr is the biggest partition
2016-02-08 09:08:17 <clandmeter> ScrumpyJack: partition your sd, boot fat32, var ext4, usr ext4
2016-02-08 09:08:57 <clandmeter> then setup your fstab and mount them on the sd
2016-02-08 09:09:09 <clandmeter> but its probalby not very fast..
2016-02-08 09:09:36 <ScrumpyJack> "mount them on the sd"?
2016-02-08 09:09:45 <clandmeter> yes?
2016-02-08 09:09:51 <clandmeter> its a raspberry right?
2016-02-08 09:09:54 <ScrumpyJack> yes
2016-02-08 09:10:12 <clandmeter> so it has a sd card to boot from
2016-02-08 09:10:20 <ScrumpyJack> obvs :)
2016-02-08 09:10:21 <clandmeter> and it needs 200mb for booting
2016-02-08 09:10:35 <clandmeter> so you can use the rest to run from
2016-02-08 09:11:26 <ScrumpyJack> i'm looking at the RPi persistant storages notes on the wiki
2016-02-08 09:11:44 <clandmeter> i guess you can also tell init to use second partition to use as root. i never tried that.
2016-02-08 09:13:30 <clandmeter> ScrumpyJack: hmm I never tried overlayfs approach
2016-02-08 09:13:56 <ScrumpyJack> do you mean mount an SD card partition onto /var, not mount /var on the SD card - which confused  me
2016-02-08 09:14:42 <clandmeter> like a regular linux system, you can mount any dir on any partition.
2016-02-08 09:15:03 <clandmeter> you just have to have multiple partitions on the sd card
2016-02-08 09:15:18 <ScrumpyJack> s/on/from
2016-02-08 09:19:37 <ScrumpyJack> so anyway, if i mount a device on /var or /usr, how will that help? if it gets written to, won't it be mounted over on the next boot by squashfs?
2016-02-08 09:20:27 <clandmeter> squashfs?
2016-02-08 09:20:50 <clandmeter> the only thing squashfs are the modules.
2016-02-08 09:20:58 <ScrumpyJack> aren't packages actually installed on every boot?
2016-02-08 09:21:22 <clandmeter> depends
2016-02-08 09:21:30 <clandmeter> if you have var on persistance not
2016-02-08 09:21:41 <clandmeter> err
2016-02-08 09:21:53 <clandmeter> no thats etc
2016-02-08 09:22:11 <ScrumpyJack> I need to get me head round this :)
2016-02-08 09:22:17 <clandmeter> even if they do, that doesnt matter, cause var will be mounted first
2016-02-08 09:22:57 <clandmeter> so things in var will be on sd
2016-02-08 09:23:17 <ScrumpyJack> how about /usr?
2016-02-08 09:23:38 <clandmeter> and things in usr will be on sd also if you mount it on/in/over/within/from
2016-02-08 09:23:45 <clandmeter> sd
2016-02-08 09:23:47 <clandmeter> :)
2016-02-08 09:24:51 <clandmeter> i mounted var on/from a file located on fat32 partition.
2016-02-08 09:25:14 <clandmeter> cause i didnt partition the sd card before.
2016-02-08 09:25:22 <clandmeter> and i couldnt resize fat32
2016-02-08 09:28:12 <ScrumpyJack> i need to get my head round sqashfs and how everything is copied to tmpfs
2016-02-08 09:28:40 <ScrumpyJack> what happens during the ########################### on a diskless install is a bit fuzzy
2016-02-08 09:29:55 <clandmeter> it is?
2016-02-08 09:30:10 <clandmeter> forget about squashfs
2016-02-08 09:30:15 <clandmeter> its only for the modules
2016-02-08 09:30:23 <clandmeter> modloop is squashfs
2016-02-08 09:30:31 <ScrumpyJack> at some point, the local packages and packages added to cache are installed
2016-02-08 09:30:39 <clandmeter> yes
2016-02-08 09:30:50 <clandmeter> first init willl restore your ovl
2016-02-08 09:31:03 <clandmeter> which will create your /etc
2016-02-08 09:31:08 <clandmeter> and populate it
2016-02-08 09:31:26 <clandmeter> then it will run apk to restore your system based on /etc/apk/world
2016-02-08 09:31:35 <ScrumpyJack> now, if /usr is on a new device, how does that stop the the local packages and packages added to cache being installed again at the next boot?
2016-02-08 09:31:59 <clandmeter> what does it matter if it does?
2016-02-08 09:32:10 <ScrumpyJack> because the end up in tmpfs
2016-02-08 09:32:41 <clandmeter> not if you mounted stuff from fstab
2016-02-08 09:32:57 <clandmeter> because it will first mount fstab which has been restord from your ovl file
2016-02-08 09:33:17 <clandmeter> so some parts will go to the sdcard
2016-02-08 09:34:52 <ScrumpyJack> I still don't get it. What's stopping init from installing the local packages and packages added to cache, even if it mounts fstab contents first?
2016-02-08 09:36:50 <clandmeter> im not sure which part tells init its a tmpfs install or disk install. probably based on the root option on boot cmd line.
2016-02-08 09:37:29 <clandmeter> if its a tmpfs install, apk will restore apk's, thats the part with ##### early in boot
2016-02-08 09:37:42 <clandmeter> so it will install them in root wich is tmpfs
2016-02-08 09:39:10 <clandmeter> but if you mount some dirs on/from other paritions, those files will end up on those partitions (i believe) not tmpfs.
2016-02-08 09:41:50 <ScrumpyJack> just going thought init
2016-02-08 11:04:39 <ncopa> fabled: i think we have an apk feature request coming up: https://github.com/lxc/lxc/pull/751#issuecomment-181021658
2016-02-08 11:57:12 <ScrumpyJack> :0
2016-02-08 11:57:15 <ScrumpyJack> oops
2016-02-08 12:09:07 <ScrumpyJack> ncopa: doesn't he mean repo?
2016-02-08 12:10:32 <ScrumpyJack> something like lxc-create -n alpine [..] -- -r /var/apk.cache ?
2016-02-08 12:25:28 <jirutka> “he” is here :)
2016-02-08 12:25:46 <jirutka> no, I mean APK cache, not remote repository
2016-02-08 12:26:05 <kunkku> I just commented there that you can create /etc/apk/cache in the container root
2016-02-08 12:26:32 <jirutka> Ah, I see, great, this would help!
2016-02-08 12:26:35 <kunkku> you also need to bind mount the cache to root
2016-02-08 12:27:19 <jirutka> You mean bind container’s cache to the cache directory on the host?
2016-02-08 12:27:57 <kunkku> yes, or some directory in $LXC_CACHE_DIR unless you want to share the cache with host
2016-02-08 12:28:52 <jirutka> Great idea, I’ll do it.
2016-02-08 12:28:54 <kunkku> might not be a good idea to share the cache at run-time (for security reasons), but just to speed up the installation
2016-02-08 12:30:16 <kunkku> looking at apk code, seems as if it defaulted to $root/var/apk/cache if $root/etc/apk/cache did not exist, but this seems not to work for some reason
2016-02-08 12:30:44 <kunkku> hm, fabled is not here
2016-02-08 12:33:26 <kunkku> jirutka: maybe better to check with fabled if you need to use that 'run_exclusively' when accessing the cache
2016-02-08 12:48:20 <jirutka> kunkku: APK doesn’t verify signatures of the packages taken from the cache?
2016-02-08 12:48:56 <jirutka> If it does, then there should not be any security issue with sharing APK cache between containers…?
2016-02-08 12:52:44 <ncopa> i think it verifies
2016-02-08 12:52:45 <kunkku> I was thinking DoS type of threats
2016-02-08 12:53:04 <jirutka> ?
2016-02-08 12:53:07 <kunkku> if there is some file locking etc.
2016-02-08 12:53:12 <jirutka> aha
2016-02-08 12:53:53 <kunkku> but we should verify whether multiple apk processes can safely share the cache at all
2016-02-08 12:54:20 <kunkku> otherwise, we need locking in the lxc template
2016-02-08 12:59:25 <kunkku> fabled: we were discussing on how apk cache works
2016-02-08 12:59:58 <kunkku> is it ok if multiple apk instances running in parallel share the cache?
2016-02-08 13:00:23 <fabled> currently no
2016-02-08 13:00:47 <fabled> the thing is that along with cache apk stores 'installed' file which describes certain things
2016-02-08 13:01:02 <kunkku> the use case is to speed up lxc container creation
2016-02-08 13:01:18 <fabled> it should be relatively simple to modify it so that the part with .apk files can be shared
2016-02-08 13:01:29 <kunkku> what's inside 'installed'?
2016-02-08 13:01:35 <jirutka> btw I’ve just made container with JDK8 on f*cking Ubuntu, because colleague insist on it… 876 MiB… this is insane.
2016-02-08 13:02:15 <fabled> kunkku, it contains description of packages that are not found in any upstream repository (either because apk add file.apk or installed .apk was upgraded in upstream repo)
2016-02-08 13:02:16 <jirutka> …and about gazilion packages installed just for sshd, not even talking about JDK
2016-02-08 13:02:36 <fabled> kunkku, also it contains the package tag pinning information
2016-02-08 13:05:26 <kunkku> what if we just remove the 'installed' file before creating new rootfs?
2016-02-08 13:05:56 <kunkku> (assuming the cache is not shared with the host system but just used to speed up lxc-create?)
2016-02-08 13:06:47 <jirutka> I think it’d be even more useful to share cache between running containers, but it seems that it’s not possible now…?
2016-02-08 13:07:41 <kunkku> yeah, kind of local proxy for .apk
2016-02-08 13:07:43 <jirutka> I currently cache complete rootfs, but some folks want the template to also install additional packages and this quite complites the situation :/
2016-02-08 13:12:39 <kunkku> fabled: do you think the ^^^ use case makes sense or should we be doing something else?
2016-02-08 13:13:15 <fabled> i'd like to make it separate feature. but yeah, on install time that should be ok
2016-02-08 13:13:29 <fabled> alternative is to use http proxy in between
2016-02-08 13:14:21 <kunkku> and removing 'installed' between serialized installations is a decent workaround for now?
2016-02-08 13:16:45 <fabled> mmm.. i think it does not even need to be removed
2016-02-08 13:16:58 <fabled> in fact, it's really needed only for run-from-tmpfs installs
2016-02-08 13:17:10 <fabled> on disk installs it should not need that installed file
2016-02-08 13:17:13 <kunkku> ok
2016-02-08 13:17:35 <kunkku> another question:
2016-02-08 13:18:38 <kunkku> does the following code mean the cache dir should default to $root/var/apk/cache if $root/etc/apk/cache does not exist?
2016-02-08 13:18:45 <kunkku> http://git.alpinelinux.org/cgit/apk-tools/tree/src/database.c#n1607
2016-02-08 13:20:20 <fabled> yes, but in that case it stores only the copies of APKINDEX of http repos there
2016-02-08 13:20:24 <fabled> not the .apk packages
2016-02-08 13:21:38 <kunkku> so the lxc template should both create the symlink and bind mount the shared cache in the container root
2016-02-08 13:21:51 <fabled> yes
2016-02-08 13:22:13 <kunkku> and umount the cache afterwards until cache sharing becomes possible
2016-02-08 13:23:00 <kunkku> jirutka: do you now know how to proceed?
2016-02-08 13:25:01 <jirutka> I think that I do.
2016-02-08 13:25:17 <jirutka> However, I’ll do it later, I’m budy now.
2016-02-08 13:25:18 <jirutka> busy
2016-02-08 13:25:55 <jirutka> Thanks for help, fabled and kunkku!
2016-02-08 13:26:13 <kunkku> you are welcome
2016-02-08 13:26:27 <kunkku> big thanks for you to improving the template
2016-02-08 13:30:21 <ncopa> +1
2016-02-08 13:30:25 <ncopa> thanks indeed
2016-02-08 13:55:15 <xsteadfastx> even if i use linux for 10+ years i never build a package myself... now i use alpine for some docker images and i need vim with the python interpreter. i see that lua is enabled in the alpine vim package but not python. i edited the vim APKBUILD file that python support gets compiled in. it works. but what do i do with that? should i make a vim-python package? i dont know what to do with that. maybe
2016-02-08 13:55:17 <xsteadfastx> someone has an idea :) btw thanks for alpine linux. i like it alot
2016-02-08 14:14:54 <ncopa> hi
2016-02-08 14:16:49 <ncopa> --enable-pythoninterp ?
2016-02-08 14:19:15 <xsteadfastx> yes
2016-02-08 14:19:37 <ncopa> how does that work? it does not seem to link against libpython?
2016-02-08 14:19:40 <ncopa> (which is good)
2016-02-08 14:20:16 <xsteadfastx> exactly. and added python-dev to makedepends
2016-02-08 14:21:06 <xsteadfastx> ncopa: honestly. i dont know exactly :) i will search for it
2016-02-08 14:24:13 <xsteadfastx> ncopa: i will test it some more
2016-02-08 14:24:34 <ncopa> it looks that other distro has a vim-minimal
2016-02-08 14:24:42 <ncopa> compiled without python and stuff
2016-02-08 14:24:43 <ncopa> hm
2016-02-08 14:25:18 <xsteadfastx> and what is with the lua support? is that necessary?
2016-02-08 14:25:33 <ncopa> its not big
2016-02-08 14:25:41 <ncopa> lua is 300k
2016-02-08 14:25:44 <ncopa> python 40MB
2016-02-08 14:25:46 <ncopa> or so
2016-02-08 14:26:07 <xsteadfastx> hehe ok... :)
2016-02-08 14:26:59 <xsteadfastx> i just wonder whats the best way to include it somehow. in ubuntu there is vim-nox too. thats vim-minimal with scripting
2016-02-08 14:27:15 <xsteadfastx> thats what i use under ubuntu
2016-02-08 14:28:17 <ncopa> im ok with adding python support
2016-02-08 14:28:22 <ncopa> how do i test that it works?
2016-02-08 14:30:12 <xsteadfastx> :py print 'this is a test'
2016-02-08 14:30:13 <ncopa> :python import sys; print(sys.version)
2016-02-08 14:30:20 <ncopa> works
2016-02-08 14:30:51 <xsteadfastx> and then there is the question if its python 2 or python 3 support to add
2016-02-08 14:31:06 <ncopa> i wonder if we should just go with python3?
2016-02-08 14:31:20 <xsteadfastx> thats what i would do
2016-02-08 14:31:41 <ncopa> i mean, thats the future
2016-02-08 14:31:54 <xsteadfastx> thats what i think
2016-02-08 14:34:58 <ncopa> http://tpaste.us/3JKv
2016-02-08 14:35:09 <ncopa> im' pushing that
2016-02-08 14:35:31 <xsteadfastx> perfect :) thank you alot
2016-02-08 14:35:34 <ncopa> and its pushed
2016-02-08 14:35:58 <xsteadfastx> makes alot easier for me :)
2016-02-08 14:38:35 <skarnet> please don't link the default vim against python - or at least provide an untainted alternative!
2016-02-08 14:39:57 <xsteadfastx> maybe a vim-tiny is an alternative
2016-02-08 14:41:23 <ncopa> skarnet: it does not look like it is linked against python
2016-02-08 14:41:58 <ncopa> i wouldnt do such a thing...
2016-02-08 14:42:21 <skarnet> ncopa: so it can make python calls if python is available, and just fail if it's not, without pulling in a compile-time dep on python ?
2016-02-08 14:42:24 <skarnet> That would rock.
2016-02-08 14:42:40 <ncopa> looks like that is what it does
2016-02-08 14:42:58 <ncopa> well, it seem to check for python from configure script
2016-02-08 14:43:07 <ncopa> so it needs to be there at compile time
2016-02-08 14:43:21 <skarnet> now that is stupid.
2016-02-08 14:43:33 <skarnet> complete toctou there.
2016-02-08 14:44:09 <skarnet> But still, respect for not needing libpython and being graceful about it.
2016-02-08 14:46:19 <ncopa> clandmeter: did you see that we were on slashdot this saturday?
2016-02-08 14:46:45 <ncopa> i wonder if we could fish out some stats on number of visits...
2016-02-08 14:47:47 <clandmeter> i didnt
2016-02-08 14:48:06 <clandmeter> im not sure we are storing any logs
2016-02-08 14:48:10 <ncopa> http://linux.slashdot.org/story/16/02/06/0433228/docker-images-to-be-based-on-alpine-linux
2016-02-08 14:51:46 <clandmeter> ncopa: did you do some logging on www?
2016-02-08 14:53:43 <ncopa> looks like we have logs yes
2016-02-08 14:54:13 <ncopa> # wc -l /var/log/darkhttpd/access.log
2016-02-08 14:54:13 <ncopa> 3791520 /var/log/darkhttpd/access.log
2016-02-08 14:54:32 <ncopa> hum, i need some tool to analyze the darkhttpd log
2016-02-08 14:54:35 <clandmeter> :)
2016-02-08 14:54:44 <clandmeter> the tools is probably called lua
2016-02-08 14:56:30 <ncopa> i'm glad we run static pages
2016-02-08 15:09:11 <skarnet> darkhttpd? that sounds shady
2016-02-08 15:14:27 <ncopa> we have 522418 entries in the access.log since 2016
2016-02-08 15:15:47 <ncopa> 215263 enitres since feb
2016-02-08 15:16:48 <ncopa> it means we had as many visits first week in feb as total january
2016-02-08 15:17:08 <ncopa> skarnet: darkhttpd only serves static pages
2016-02-08 15:34:25 <clandmeter> so its around 4x more then usual
2016-02-08 15:49:21 <ScrumpyJack> clandmeter: following on from ealier, /run is tmpfs and is 43.6 precious M. 156K in use. do i really need it to be that big?
2016-02-08 15:52:20 <ScrumpyJack> i wonder how it's calculated :)
2016-02-08 15:55:57 <skarnet> ScrumpyJack: it's like virtual memory in processes, you only really use what you need
2016-02-08 16:00:08 <ScrumpyJack> ah yes, of course :) available tmpfs != reserved RAM
2016-02-08 16:57:31 <nmeum> ncopa: what's your opinion on the following abuild patch http://sprunge.us/Cgii if I am not misstaken $reporev was always ignored for git repositories so far
2016-02-08 16:57:42 <nmeum> *mistaken
2016-02-08 17:25:09 <NIN101> ncopa: is there a reason this wasn't cherry-picked into stable? http://git.alpinelinux.org/cgit/aports/commit/?id=6a5bee5ff0ce482289000c1b5c51983d4e9445b0
2016-02-08 17:52:16 <ncopa> NIN101: i'll do it now
2016-02-08 19:39:32 <ncopa> nmeum: i wonder if it is reporev that should have been used instead of _rev
2016-02-08 19:39:57 <ncopa> abuild should not use any variable prefixed with _
2016-02-08 19:41:20 <nmeum> the comment above the functions says you should set $reporev or do you mean we should use $reporev instead of $_rev directly as an argument to git-archive?
2016-02-08 19:55:41 <kaniini> so
2016-02-08 19:55:51 <kaniini> what is the future plans for alpine now that docker is paying the bills
2016-02-08 19:57:37 <coredumb> wut ?
2016-02-08 20:01:33 <nmeum> ncopa works for docker now, but why should that change anything kaniini?
2016-02-08 20:02:34 <nmeum> oh, totally missed the slashdot post linked above
2016-02-08 20:03:11 <kaniini> nmeum: generally the guys doing the bankrolling have an effect on the thing they bankroll, regardless of whether or not it is intentional
2016-02-08 20:03:49 <kaniini> therefore, some insight as to what they wish to do
2016-02-08 20:03:57 <kaniini> and how that intersects with alpine
2016-02-08 20:04:00 <kaniini> would be desirable :)
2016-02-08 20:05:10 <ncopa> https://news.ycombinator.com/item?id=11000827
2016-02-08 20:05:47 <ncopa> for now it seems they just want docker images built on alpine
2016-02-08 20:07:44 <ncopa> my impression so far have been that they love alpine and want use it
2016-02-08 20:09:46 <ncopa> the effect i have seen so far has been less time for me to look at patches sent to aports list
2016-02-08 20:10:02 <ncopa> and less time for me to do maintenance work
2016-02-08 20:10:11 <ncopa> but i am not the only with git push access ;)
2016-02-08 20:41:10 <yth> to propose a fix for an issue - is the preferred thing to attach the suggestion to issue notes in redmine, or to mail the patch straight to alpine-aports?
2016-02-08 21:02:12 <ncopa> yth:  i think sendind patch directly to alpine-aports is ok
2016-02-08 21:02:24 <ncopa> specially if you have a 'ref #<number>' in there
2016-02-08 21:02:31 <ncopa> or 'fixes #<number>'
2016-02-08 21:02:50 <ncopa> then will the issue in redmine be resolved automatically
2016-02-08 21:03:20 <yth> ncopa: thanks, I'll do that
2016-02-08 21:28:36 <mitchty> so i slightly forgot and wasn't in too much of a rush, but the ghc patch I posted to the ML will soon be out of date, i've updated the bootstrap compiler generation and patched ghc to us llvm 3.6, but curious if I need to do anything differently when I re-submit the patch
2016-02-08 22:14:57 <barthalion> well, I'd love to push more, but packaging didn't really pay my bills even once
2016-02-08 22:15:08 <barthalion> and I like my bills to be paid, so
2016-02-08 22:17:11 <pluesch> kimo_sabe: you still there? I think the qemu-kvm issue is more related to network activity.
2016-02-08 22:18:24 <pluesch> I don't know why I think that, but my current vm which is crashing like every 3-6 hours is only running tor. For the first 3-4 days there was like no crash at all, because the relay was new and therefore nore traffic was routed over it, but now the crash happens pretty fast.
2016-02-08 22:26:02 <nmeum> mitchty: I also looked into cross compiling ghc for alpine you are the guy who used docker to cross compile it, arent't you?
2016-02-08 22:26:27 <mitchty> nmeum: yep
2016-02-08 22:27:36 <mitchty> nmeum: https://github.com/mitchty/alpine-linux-ghc-bootstrap/compare/llvm-3.6-experiment2 has the newer dockerfile i'll be using
2016-02-08 22:28:06 <mitchty> have to test it against a lot of the cabal packages that worked before that takes hours but my crazy hack worked
2016-02-08 22:29:14 <nmeum> one problem I am seeing is that you (if I am informed correctly) can't start a docker container on the builders since the builders already run inside an lxc container
2016-02-08 22:30:07 <mitchty> thats why the APKBUILD lets you specify the bootstrap via env
2016-02-08 22:30:38 <mitchty> once you have the bootstrap ghc apk then its like a normal build
2016-02-08 22:31:42 <mitchty> aka the gist is, whereever you can run docker, you run make, get a tar.xz of the bootstrap compiler, put that wherever
2016-02-08 22:31:56 <nmeum> you could also create a snapshot role which builds a ghc for bootstraping locally and than you could fetch that from the builders
2016-02-08 22:32:09 <mitchty> then just BOOTSTRAP=tarfileloc abuild checksum && abuild -r
2016-02-08 22:33:10 <mitchty> i'm not wedded to docker it was just convenient, but i already spend a ton of time upkeeping this port so not in a huge rush to change too much
2016-02-08 22:33:35 <mitchty> nmeum: can you explain on the snapshot role
2016-02-08 22:34:13 <nmeum> well could create that tarball for the bootstrap compiler in snapshot() and upload it to a disturl than it shouldn't be a problem
2016-02-08 22:34:27 <nmeum> there is an article on the wiki somewhere I will send you the link in a second
2016-02-08 22:34:49 <mitchty> ah, ok so you mean the snapshot would override the inputs
2016-02-08 22:34:54 <kimo_sabe> pluesch: hmm, I haven't pushed much on the network side, but I can catch it on mass small file IO, most of the time. Probably hitting the same virtio synchronization issue in either case
2016-02-08 22:36:04 <pluesch> kimo_sabe: any idea why this only happens on alpine linux?
2016-02-08 22:36:33 <nmeum> mitchty: no, snapshot() would only build the bootstrap compiler and create a tarball and then upload it to dev.alpinelinux.org/archive usually snapshot() is used for creating a tarball for git/svn repositories but you could use it for this purpose as well I guess
2016-02-08 22:36:51 <pluesch> kimo_sabe: yeah... it's probably really related to virtio
2016-02-08 22:36:53 <nmeum> here is an example with a git fetch http://wiki.alpinelinux.org/wiki/APKBUILD_examples:Git_checkout
2016-02-08 22:37:45 <kimo_sabe> pluesch: someone in one of the IRC logs mentioned -Os, is that in the default compiler options in Alpine but not the others? I haven't dug into the toolchain differences until I find a reliable crash case
2016-02-08 22:40:15 <pluesch> kimo_sabe: that's true
2016-02-08 22:40:55 <mitchty> nmeum: ah, cool, guess that would handle how i could do git checkouts too, which is in the nearish future, so basically you build the snapshot in say docker outside of the builders then have the apkbuild pick that up?
2016-02-08 22:42:07 <nmeum> mitchty: excactly snapshot is usally invoked locally. It uploads the stuff it has create to an url and that url is added to $source and then the builders only fetch the file from $source and thus don't need to run docker
2016-02-08 22:42:15 <nmeum> *created
2016-02-08 22:42:58 <pluesch> kimo_sabe: voidlinux is using "-O2" so it would support the case why the bug isn't present there.
2016-02-08 22:43:58 <mitchty> nmeum: that would work too, right now i've got the whole thing into a simple "run make, receive bootstrap compiler" step, so it would amount to make && scp tar.xz dest
2016-02-08 22:44:00 <kimo_sabe> pluesch: it feels "racy", like some bit of synchronization code is getting wrongly optimized out
2016-02-08 22:44:12 <mitchty> with caveat of just have docker running wherever you do that
2016-02-08 22:47:42 <nmeum> mitchty: yeah, if that works just resubmit your patch and I will give you some more feedback on your GHC aport and we can hopefully include it in the official repositories at some point :)
2016-02-08 22:48:56 <mitchty> nmeum: ok i'll have a go with it tonight, i have to wait for this to all finish compiling anyway and validate what I did still works and I didn't break anything
2016-02-08 22:51:06 <mitchty> i'm guessing the funnest stuff will be that I started to compile llvm for ghc due to it needing only a certain llc/opt https://github.com/mitchty/alpine-linux-ghc-bootstrap/blob/master/ghc/APKBUILD#L237
2016-02-08 22:51:26 <nmeum> is it no longer possible to compile ghc with gcc?
2016-02-08 22:51:41 <mitchty> oh no you can, but that only really works for x86_64
2016-02-08 22:51:52 <mitchty> newer platforms are just going through llvm
2016-02-08 22:51:58 <mitchty> e.g. arm
2016-02-08 22:52:29 <mitchty> actually this huge hack of getting 3.6 to work was more for arm porting
2016-02-08 22:53:00 <nmeum> so you managed to compile GHC for all arches supported by alpine (armhf, x86 and x86_64)?
2016-02-08 22:53:35 <mitchty> x86_64 atm, i386 would be pretty easy but i've not put time into it, arm i've hit fun bugs and not yet fully worked around them
2016-02-08 22:53:54 <mitchty> but x86_64 works so don't see a need to hold up the other arches
2016-02-08 22:54:35 <mitchty> that and i need to get the arm soc I bought running alpine so I can do compiles faster than qemu can do
2016-02-08 22:55:01 <mitchty> when it takes over a day to test things it limits progress
2016-02-08 22:55:27 <nmeum> yeah
2016-02-08 22:55:58 <mitchty> i've managed to get a cross compiler built, but had fun symbol lookup issues
2016-02-08 22:56:14 <nmeum> wouldn't it be easier to use the llvm version available in the official repositories instead of using the included one? Or did the GHC folks patch llvm to an extend where it is no longer possible to buidl GHC with the vanilla llvm version?
2016-02-08 22:56:16 <mitchty> which look to be related to some linker ug
2016-02-08 22:56:29 <mitchty> the issue lies more with this
2016-02-08 22:56:49 <mitchty> llvm bytecode from llc/opt tends to change and there is no future guarantee
2016-02-08 22:57:06 <mitchty> that the version of ghc you run will work with say 3.7+
2016-02-08 22:57:24 <mitchty> 3.6 as an example changed some things up to that point
2016-02-08 22:57:55 <mitchty> for the main platforms they're basically going to do what I did in the port https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend
2016-02-08 22:58:12 <mitchty> just include llc/opt with known working versions
2016-02-08 22:58:53 <nmeum> interesting
2016-02-08 23:00:52 <mitchty> either way, i'll need the right version of llvm for arm
2016-02-08 23:01:34 <mitchty> the arm backend is exclusively llvm
2016-02-08 23:04:02 <nmeum> I will be off to bed now. As I said: Just resubmit your patch at some point I would definitly appreciate it if we had GHC in the official repositories
2016-02-08 23:04:57 <mitchty> nmeum: sure, have to finish some cleanup and i'll add that in, beware it takes a long time to compile :)
2016-02-08 23:05:37 <mitchty> and thanks for the info! night!
2016-02-08 23:05:40 <nmeum> just take your time no need to rush this :)
2016-02-08 23:05:43 <nmeum> night
2016-02-09 06:11:30 <kaniini> hah :p
2016-02-09 14:26:28 <vkris> is dev.a.o down ?
2016-02-09 14:28:04 <ncopa> http://www.isitdownrightnow.com/dev.alpinelinux.org.html
2016-02-09 14:28:16 <ncopa> Dev.alpinelinux.org is UP
2016-02-09 14:28:16 <ncopa> The website is probably down just for you...
2016-02-09 14:48:54 <vkris> ok now, thanks, seems some net issue, dns maybe
2016-02-09 16:46:30 <nmeum> ncopa: is it ok to have packages in testing/ which don't have any license at all?
2016-02-09 16:47:04 <nmeum> I am asking because I wanted to apply %1554 and just noticed that the software doesn't have a license
2016-02-09 16:50:22 <ammunta> dovecot is LGPL, does that affect anything
2016-02-09 16:50:33 <ammunta> oh wait is that a standalone program
2016-02-09 17:00:28 <nmeum> yeah it's a standalone program
2016-02-09 17:01:51 <ncopa> does other distros ship it?
2016-02-09 17:02:03 <ncopa> what do they do?
2016-02-09 17:03:18 <nmeum> I don't think that any other distros ship it (it doesn't seem to be a very popular package)
2016-02-09 17:03:32 <ncopa> we should ask upstream what license it is
2016-02-09 17:03:51 <ncopa> or
2016-02-09 17:03:59 <nmeum> the repository contains some gentoo ebuilds which explicitly set license to an empty string
2016-02-09 17:04:07 <nmeum> https://github.com/lexbrugman/dovecot_deleted_to_trash/blob/master/ebuilds/dovecot_deleted_to_trash-9999.ebuild#L13
2016-02-09 17:04:15 <ncopa> "can we redistribute it under the MIT license?"
2016-02-09 17:04:17 <ammunta> doesn't look like we can distribute it without a license, ask upstream
2016-02-09 17:04:19 <ncopa> or aimilsr
2016-02-09 17:04:27 <ncopa> yes
2016-02-09 17:04:30 <ncopa> we need ask upstream
2016-02-09 17:04:49 <ammunta> isn't that line either default or cribbed from somewhere
2016-02-09 17:05:13 <ammunta> I wouldn't take assigning empty string to be indicative of an explicit no-license choice
2016-02-09 17:06:23 <nmeum> yeah
2016-02-09 17:06:24 <ncopa> there is a license
2016-02-09 17:06:27 <nmeum> I will open an issue upstream
2016-02-09 17:06:30 <nmeum> oh where?
2016-02-09 17:06:35 <ncopa> https://github.com/lexbrugman/dovecot_deleted_to_trash/blob/master/dovecot-deleted-to-trash.spec#L12
2016-02-09 17:06:44 <ncopa> but we shoudl ask him
2016-02-09 17:07:13 <nmeum> alrgiht
2016-02-09 17:07:18 <nmeum> I will open an issue right away
2016-02-09 17:07:21 <ncopa> ask if its ok that we redistribute with MIT or BSD license
2016-02-09 17:07:28 <ncopa> or whatever license dovecot uses
2016-02-09 17:07:47 <ncopa> does not look like he has enabled github issues
2016-02-09 17:07:51 <ammunta> wait does he have issues disabled
2016-02-09 17:08:01 <nmeum> oh indeed
2016-02-09 17:08:06 <nmeum> well that sucks
2016-02-09 17:08:15 <ammunta> well
2016-02-09 17:08:23 <ammunta> does he have an email listed
2016-02-09 17:08:28 <nmeum> yeah
2016-02-09 17:08:32 <nmeum> I will write him an email *sigh*
2016-02-09 17:08:37 <ammunta> sigh
2016-02-09 17:08:55 <ncopa> i have got similar emails :)
2016-02-09 17:10:40 <ammunta> I mean it makes me at least three kinds of hypocrite but it's obnoxious when people give no indication of license
2016-02-09 17:14:57 <skarnet> don't sigh when you have to contact upstream by email
2016-02-09 17:15:14 <skarnet> email is infrastructure, github is a company
2016-02-09 17:15:44 <skarnet> the more you rely on companies to make foss work, the more shit can (and will) hit the fan at some point
2016-02-09 17:16:31 <nmeum> I don't have an issue with writing upstream emails (I dislike github as well) but I have the feeling that I won't get a reply :p
2016-02-09 17:17:14 <skarnet> ok, sorry for lecturing - it's an important subject to me, so I tend to be quick on the trigger
2016-02-09 17:17:22 <nmeum> no problem
2016-02-09 17:18:34 <ncopa> i'm glad to hear that i am not th eonly one who things its a good idea to keep git.a.o running...
2016-02-09 17:18:50 <nmeum> no definitly not
2016-02-09 17:19:35 <skarnet> I trust projects that have their own git much more that projects that are hosted somewhere else, in particular a corporate platform
2016-02-09 17:20:29 <skarnet> projects having their own hosting means people are invested enough into it, and technically savvy enough, to maintain a hosting
2016-02-09 17:22:16 <ncopa> or stupid enough to spend time on it...
2016-02-09 17:22:16 <ncopa> :)
2016-02-09 17:24:16 <skarnet> It's natural selection. Projects with their own hosting survive if they're using good enough tools, so not much time is spent sysadmining. ;)
2016-02-09 17:27:19 <nmeum> speaking of git self hosting: we should upgrade cgit
2016-02-09 17:28:01 <nmeum> there have been a few CVEs in cgit (CVE-2016-1901, CVE-2016-1900 and CVE-2016-1899)
2016-02-09 17:46:21 <ammunta> speaking of self-hosting though if you do that at least sig your releases though :||
2016-02-09 17:46:38 <ammunta> (do that even if you don't self-host)
2016-02-09 17:48:16 <ammunta> there is still a difference between trusting github to mitm you and ¯\_(ツ)_/¯
2016-02-09 17:54:07 <jirutka> I personally trust more projects hosted on GitHub than self-hosted. I know A LOT projects that eventually dissapeard, they shutted down their hosting, their domain has expired… so you don’t have access to sources, documentation, nothing. Projects on GitHub may be abandoned for years, but still there.
2016-02-09 17:56:16 <jirutka> I generally prefer self-hosted solutions (I’m using even self-hosted email), but GitHub is an exception.
2016-02-09 17:56:58 <skarnet> jirutka: what makes you think github will not suffer the fate of freshmeat? or sourceforge?
2016-02-09 18:00:58 <jirutka> Well, we can’t know, but it’s not happening now and there’s no single evidence that it should happen soon.
2016-02-09 18:01:55 <skarnet> Oh, really? http://uk.businessinsider.com/github-the-full-inside-story-2016-2
2016-02-09 18:01:57 <jirutka> Meanwhile, many many projects died even with their self-hosted platform, so sources are not accessible anymore. This is not happening with projects on GitHub.
2016-02-09 18:03:32 <jirutka> I haven’t read this article, but I will read it at evening.
2016-02-09 18:03:59 <skarnet> Yes, many projects died. That's what projects do. They die even when they're hosted on github. Sure, the sources are there, but they aren't maintained, so if you want to integrate them, you better maintain a patch repository yourself. Which is pretty close to maintaining the source tree yourself.
2016-02-09 18:04:31 <jirutka> There’s one huge difference and very simple. You do have access to sources, or you don’t.
2016-02-09 18:04:37 <jirutka> If you don’t, then you can’t do anything.
2016-02-09 18:05:14 <jirutka> Unmaintained codebase is IMO better than no codebase. At least, you have something to start with.
2016-02-09 18:05:52 <jirutka> You can fork it and GH makes it very very simple, even for other people to discover that some maintained fork exists.
2016-02-09 18:06:37 <skarnet> ah, yes, github makes forks easy. WAY too easy.
2016-02-09 18:06:54 <jirutka> And GH makes it extremly simple to contribute…
2016-02-09 18:07:18 <jirutka> You can send pull request, discuss about it, other people can see what’s happening.
2016-02-09 18:07:32 <skarnet> I'm not saying github has no added value. I'm glad it HAS value - it's not a complete waste of time.
2016-02-09 18:07:40 <jirutka> Sending patches via e-mail is like from Stone Age.
2016-02-09 18:07:50 <skarnet> I'm only saying that it's not good for projects to *rely* on github.
2016-02-09 18:08:08 <ncopa> github pull requests and feature to comment on commits is nice
2016-02-09 18:08:14 <skarnet> It should be in the "nice to have" category, not in the "needed for the project to work" category.
2016-02-09 18:08:44 <jirutka> Of course you always should have copy of all the data, but with git, you always have.
2016-02-09 18:09:07 <skarnet> There you go. Git is the real MVP.
2016-02-09 18:09:18 <jirutka> of course
2016-02-09 18:10:24 <jirutka> I’m aware of negatives, as I said before, I almost always prefer self-hosted solutions, but I believe that the positives outweigh the negatives in case of GitHub.
2016-02-09 18:12:58 <jirutka> I also totally agree that it’s not good idea to rely on GitHub so much, that it would kill the project if GitHub had dissapeard.
2016-02-09 18:14:25 <skarnet> then we're in agreement. FOSS should not depend on a company-driven platform - that's all I'm saying.
2016-02-09 18:15:33 <jirutka> yeah
2016-02-09 18:27:35 <ammunta> at least we /have/ usable dvcs now
2016-02-09 18:42:16 <BitL0G1c> ncopa - I will redo the mini-sendmail patch with the author's notice in the $pkg-doc
2016-02-10 06:13:24 <pluesch> kimo_sabe: I was testing with -O2 compiled kernel and qemu package now. Same issue.
2016-02-10 06:13:38 <pluesch> maybe I've forgotten something...
2016-02-10 07:34:08 <ncopa> morning
2016-02-10 07:34:22 <ncopa> clandmeter: seems like scaleway isp has fixed the packet loss issue
2016-02-10 07:34:27 <ncopa> speed is all good
2016-02-10 07:35:52 <clandmeter> morning
2016-02-10 07:35:54 <clandmeter> nice
2016-02-10 07:36:08 <ncopa> i have also added a dns name for it: fr.a.o
2016-02-10 07:36:47 <clandmeter> 212.47.247.118 right?
2016-02-10 07:36:52 <ncopa> correct
2016-02-10 07:37:03 <clandmeter> ok thats the correct one
2016-02-10 07:37:07 <clandmeter> it has extra space
2016-02-10 07:37:09 <ncopa> i am currently running an rsync
2016-02-10 07:37:20 <clandmeter> a resync i hope?
2016-02-10 07:37:30 <ncopa> yes
2016-02-10 07:37:36 <clandmeter> ok
2016-02-10 07:38:21 <clandmeter> so we can cname rsync to fr.a.o
2016-02-10 07:38:28 <ncopa> thats the idea yes
2016-02-10 07:39:10 <ncopa> and have all the builders to push to there
2016-02-10 07:39:11 <clandmeter> i think they still didnt fix their out of stock issue
2016-02-10 07:39:17 <ncopa> :)
2016-02-10 08:29:47 <ScrumpyJack> what's fr?
2016-02-10 08:30:18 <ScrumpyJack> ah, french mirror on scaleway
2016-02-10 08:40:53 <ScrumpyJack> the fish shell requires mdocml-apropos for tab completion. shall i add it to the APKBUILD? I doesn't stop fish running, but it does make tab completion useless, which can look scruffy
2016-02-10 10:24:20 <ncopa> nmeum: ack for %1561
2016-02-10 10:24:32 <ncopa> lgtm
2016-02-10 10:25:03 <nmeum> alright will comitt it then
2016-02-10 10:40:44 <fabled> ncopa, is gnu patch installed by default on builders?
2016-02-10 10:41:04 <ncopa> i think so
2016-02-10 10:41:09 <ncopa> i think its part of build-base
2016-02-10 10:41:11 <fabled> i got private mail that musl 'prepare' fails. and it seems to fail due to busybox patch not applying it with fuzz
2016-02-10 10:41:39 <fabled> build-base: depends="binutils gcc make libc-dev fortify-headers g++"
2016-02-10 10:41:51 <ncopa> hm
2016-02-10 10:42:07 <ncopa> abuild
2016-02-10 10:42:13 <ncopa> its a dep of abuild
2016-02-10 10:42:51 <skarnet> huh?
2016-02-10 10:43:04 <fabled> ah, yes
2016-02-10 10:43:06 <ncopa> i never got bb patch working properly
2016-02-10 10:43:24 <skarnet> I built abuild without having unrar. Maybe it's used as a plugin, for sources provided via .rar files?
2016-02-10 10:43:43 <skarnet> ah, sorry, you were talking about gnu patch.
2016-02-10 10:44:11 <skarnet> yes, gnu patch is good to have - *some* patches won't apply with bb patch.
2016-02-10 10:44:50 <skarnet> typically, the patch provided on the mpfr home page requires gnu patch (so, a gnu toolchain requires gnu patch)
2016-02-10 10:45:23 <skarnet> (and yes, mpfr provides a tarball that you have to apply a patch to. Because making another release is, you know, hard.)
2016-02-10 11:38:53 <ncopa> ScrumpyJack: %1480 has checksum errors
2016-02-10 11:39:11 <ncopa> and the Functions.patch does not apply
2016-02-10 11:39:40 <ncopa> and it adds the files in community/wbar while commit message says testing/wbar
2016-02-10 11:43:13 <nmeum> ncopa: what's your opinion on %1550 do we want to add a seperate package for php7 or do we want to upgrade the package in main?
2016-02-10 11:43:39 <ncopa> that is actually a good question
2016-02-10 11:43:59 <ncopa> if you would have asked me 2-3 weeks ago i'd give you different answer
2016-02-10 11:44:13 <ncopa> but i think php7 as idderent package is ok
2016-02-10 11:44:29 <ncopa> different*
2016-02-10 11:45:16 <ncopa> i think we can do php7 for now, and then in march or so re-evaluate
2016-02-10 11:45:19 <nmeum> what about the few php-* package we have do they work with php7 too? Or do we need to maintain seperate versions for php7?
2016-02-10 11:45:51 <nmeum> php-redis, php-zmq and so on
2016-02-10 11:45:57 <ncopa> we will probably need to maintain different versions for those
2016-02-10 11:46:01 <ncopa> and that we probably dont want
2016-02-10 11:46:12 <ncopa> however
2016-02-10 11:46:18 <ncopa> this is in testing
2016-02-10 11:46:38 <ncopa> while it is in testing i think its ok that we call it php7
2016-02-10 11:46:47 <ncopa> before we move to main we discuss it again
2016-02-10 11:47:02 <ncopa> in general
2016-02-10 11:47:12 <nmeum> sounds good to me
2016-02-10 11:47:16 <ncopa> i think we want avoid maintainig both php 5.6 and php 7
2016-02-10 11:48:29 <nmeum> before deciding that we should probably figure out how many of our php packages work with php7 out of the box
2016-02-10 11:49:01 <ncopa> yes
2016-02-10 11:49:26 <ncopa> pushing php7 to testing makes it easier for people to test
2016-02-10 11:50:19 <nmeum> alright, I will test if it compiles here and if it does I will push the patch
2016-02-10 11:50:34 <ncopa> thanks!!!
2016-02-10 12:14:24 <ScrumpyJack> ncopa: thanks for the info. moved it to testing, and it builds fine here
2016-02-10 12:14:39 <ScrumpyJack> no checksum error so it must be my mailer
2016-02-10 12:14:56 <ncopa> can you please git format-patch -1 --stdout | tpaste
2016-02-10 12:15:02 <ncopa> and i'll apply it here
2016-02-10 12:25:48 <nmeum> ncopa: php7 doesn't seem to built on x86 (seems to be a problem with the pear subpackage) how do you want me to handle this?
2016-02-10 12:29:05 <ncopa> hm
2016-02-10 12:29:12 <ncopa> looks like permission denied
2016-02-10 12:29:18 <ncopa> you can either try fix it
2016-02-10 12:29:53 <ncopa> or you could set arch to exclude x86 and respond to mailing list
2016-02-10 12:30:55 <ncopa> PHP Warning:  PHP Startup: Unable to load dynamic library '/home/buildozer/aports/testing/php7/src/php-7.0.3/modules/bz2.so' - Error loading shared library /home/buildozer/aports/testing/php7/src/php-7.0.3/modules/bz2.so: Permission denied in Unknown on line 0
2016-02-10 12:31:18 <ncopa> PHP Warning:  PHP Startup: Unable to load dynamic library '/home/buildozer/aports/testing/php7/src/php-7.0.3/modules/xml.so' - Error loading shared library /home/buildozer/aports/testing/php7/src/php-7.0.3/modules/xml.so: Permission denied in Unknown on line 0
2016-02-10 12:31:36 <nmeum> yeah, I saw that the thing is I need to go soon so. I could work on the fix in the evening, do you want me to disable the arch in the meantime?
2016-02-10 12:31:44 <nmeum> s/so//
2016-02-10 12:32:02 <ncopa> probably a good idea
2016-02-10 12:32:25 <ncopa> i'd disable it on x86 for now and send email to aports list
2016-02-10 12:33:17 <nmeum> ok, thank you maybe you should consider waiting until the build finished (or failed) on armhf
2016-02-10 14:19:09 <xsteadfastx> its my second try to build a package. i need phantomjs. can i build packages from git repos too? or do i need a tarball or archive as source?
2016-02-10 14:26:31 <xsteadfastx> its because phantomjs does some things with submodules http://phantomjs.org/build.html
2016-02-10 16:14:17 <mitchty> nmeum: quick question re ghc port and snapshot(), should I detect if I have ghc available locally and if so build the bootstrapped version, and if not build the "normal" version?
2016-02-10 16:15:35 <mitchty> i had this broken out between ghc-bootstrap and regular ghc, but that was a bit of a pain, the bootstrap compiler is also a bit hobbled intentionally
2016-02-10 17:06:34 <nmeum> mitchty: snapshot() should always create a bootstrap compiler and upload it to a $disturl. If GHC is available locally you might as well build the bootstrap compiler using the version that is available locally (at least I don't see why you shouldn't)
2016-02-10 17:06:58 <nmeum> is that what you meant or did I misunderstand your question?
2016-02-10 17:07:48 <mitchty> nope thats the question, it was more what to do to detect that i should build the bootstrap apk or not
2016-02-10 17:08:33 <mitchty> basically, if there is no ghc apk, build via the bootstrapped compiler, setup via snapshot(), otherwise use the existing compiler
2016-02-10 17:09:29 <mitchty> the way i have things currently the bootstrap compiler is simply a tarball of a make install DESTDIR=/dir with a prefix of /usr
2016-02-10 17:10:59 <mitchty> essentially the bootstrap compiler should really only be used for building ghc natively
2016-02-10 17:11:50 <mitchty> its missing a fair bit intentionally, its using integer-simpler for its internal number crunching vs gmp, and missing 3 packages relating to curses/terminfo
2016-02-10 17:12:39 <mitchty> hopefully that makes sense, i never really planned on the bootstrap compiler to be used for much beyond building ghc itself
2016-02-10 17:19:12 <mitchty> i suppose I could build llvm when i build ghc itself, thats the biggest thing it would be missing
2016-02-10 17:58:19 <nmeum> hm
2016-02-10 18:00:54 <nmeum> have you considered moving the bootstrap ghc compiler to a seperate package? This is what we do with go, we have a go-bootstrap package only used for boostraping a go compiler
2016-02-10 18:01:37 <mitchty> i had things split out that way about 6 months ago actually
2016-02-10 18:01:39 <nmeum> is it an issue to always use the bootstraped GHC to compile GHC again?
2016-02-10 18:01:49 <mitchty> it'll take longer
2016-02-10 18:02:01 <mitchty> its built with -O basically
2016-02-10 18:03:57 <nmeum> I don't think that compiletime is a big issue
2016-02-10 18:03:59 <mitchty> also once you've got the native ghc you can use that from then on, the bootstrap compilers not all that useful past porting
2016-02-10 18:04:25 <nmeum> sure
2016-02-10 18:04:54 <nmeum> you don't need to split the packages if you don't think that it has any advantages
2016-02-10 18:05:54 <mitchty> i can, its not a huge deal to be honest, just dont' want to have to keep the bootstrap compiler stuff up to date
2016-02-10 18:06:20 <nmeum> but regarding your inital question: I think the best solution is to simply always use the cross compiled bootstrap compiler to compile the GHC APKBUILD
2016-02-10 18:06:34 <mitchty> though i suppose more testing of cross compiling for ghc would be a good thing
2016-02-10 18:07:09 <mitchty> one mini snag, not using gmp does prevent building newer cabal-install versions
2016-02-10 18:07:35 <nmeum> I thought you compiled GHC wtih gmp support?
2016-02-10 18:07:56 <mitchty> not the bootstrap compiler
2016-02-10 18:08:29 <mitchty> was removing any cross compiler c dependencies on that
2016-02-10 18:09:12 <nmeum> but you only use the bootstrap compiler to compile GHC nativly don't you? I assumed that you compile cabal and all the other stuff with the nativly compiled GHC?
2016-02-10 18:09:16 <nmeum> 
ACTION is confused

2016-02-10 18:09:28 <mitchty> its a confusing process
2016-02-10 18:09:35 <mitchty> so order of operations i this
2016-02-10 18:09:52 <mitchty> install bootstrap compiler, build proper llvm for ghc
2016-02-10 18:10:11 <mitchty> then use bootstrap compiler to build cabal so I can build alex/happy to build native ghc
2016-02-10 18:10:21 <mitchty> there are layers of bootstrapping :)
2016-02-10 18:10:36 <nmeum> ah, right you need alex and happy to build ghc
2016-02-10 18:12:03 <barthalion> sounds like drugs
2016-02-10 18:12:35 <mitchty> its a bit of a mess to be sure, which is one reason i'm not a huge fan of the bootstrap compile for much past initial port
2016-02-10 18:13:30 <nmeum> yeah
2016-02-10 18:14:00 <nmeum> hm
2016-02-10 18:15:01 <nmeum> but I do think that it would be a good idea to always use the bootstrap compiler to compile the native GHC aport in the APKBUILD
2016-02-10 18:15:16 <nmeum> otherwise you would need to depend on ghc in the ghc APKBUILD
2016-02-10 18:23:25 <mitchty> well we need ghc one way or the other
2016-02-10 18:23:47 <mitchty> so if thats the case then i'd need to get gmp into the bootstrap compiler to be able to build newer cabal
2016-02-10 18:28:12 <nmeum> I would personally prefer this, otherwise we could ask ncopa if it would be okay to depend on ghc in the ghc apkbuild and only bootstrap the compiler (using cross compilation) once for each plattform/architecture
2016-02-10 18:30:17 <mitchty> sure, this apkbuild is already pretty crazy supporting the bootstrap process and having to compile cabal twice is going to make things more fun, most distributions just bootstrap then use the existing compiler
2016-02-10 18:37:28 <nmeum> I see your point that's why I suggested to reduce complexity by spliting the packages but I do get your approach just ask ncopa if it would be okay to do it this way
2016-02-10 18:41:12 <mitchty> how about ghc-bootstrap that provides ghc that then means the real ghc build can just use ghc as a package name
2016-02-10 18:41:27 <mitchty> then if its rebuilt via native or not its the same process
2016-02-10 18:42:05 <mitchty> the bootstrap compiler however is the brittle part of this whole port, its not always reliable
2016-02-10 18:43:07 <mitchty> i'm just not wanting to maintain 2 ports of ghc, the bootstrap compiler and the native one
2016-02-10 18:44:45 <mitchty> and building the bootstrap compiler takes 2 hours on my older box, testing times for this is a bit long and i'd like to move on to some other work and declare some of this 'done for now'
2016-02-10 22:06:10 <ammunta> we could do the bootstrap process once and leave that in unmaintained :&&
2016-02-10 22:06:27 <ammunta> (not serious)
2016-02-11 00:35:23 <LadyAlissa> Not sure if this is the best place to ask; what should I do if my application requires a `sys/sysctl.h`? What provides this, anyways?
2016-02-11 00:51:05 <skarnet> sysctl() is deprecated and the musl authors (rightly) don't want to add the interface. The best thing to do is to submit a bug-report to the application authors, and maybe a patch...
2016-02-11 00:51:22 <LadyAlissa> I'm reading up on that now, actually.
2016-02-11 00:51:26 <LadyAlissa> Someone else pointed out the answer.
2016-02-11 00:51:32 <LadyAlissa> That's also what I'm doing now.
2016-02-11 00:52:53 <LadyAlissa> https://github.com/wahern/luaossl/issues/54 :D
2016-02-11 00:52:59 <LadyAlissa> thanks anyways skarnet
2016-02-11 00:53:11 <skarnet> yw ^^
2016-02-11 00:53:38 <LadyAlissa> 
ACTION now has to wait on someone adding UNIX domain path support and /now/ someone else fixing sysctl()

2016-02-11 00:53:57 <LadyAlissa> Building an Alpine-based set of programs is proving to be slightly harder than I imagined. :P
2016-02-11 09:28:33 <clandmeter> ncopa: what is the reason we do not have a usb group?
2016-02-11 09:38:28 <clandmeter> i guess dialout instead of usb
2016-02-11 09:45:17 <ncopa> what is the usb group used for?
2016-02-11 09:50:00 <clandmeter> ncopa: i guess i was looking for dialout
2016-02-11 09:50:42 <clandmeter> tty* devices are root in alpine
2016-02-11 09:50:53 <ncopa> it did not help to just remove the get-monolite-latest
2016-02-11 09:51:09 <ncopa> i dont know what goes wrong
2016-02-11 09:51:09 <clandmeter> did you change the paxmark entry?
2016-02-11 09:52:49 <clandmeter> what i did was, just let it build mono to bootstrap, and when grsec kicks in paxmark the offending bin and then run make again.
2016-02-11 09:52:59 <clandmeter> its not pretty, but it works.
2016-02-11 09:53:06 <ncopa> does not help
2016-02-11 09:54:51 <clandmeter> right
2016-02-11 09:55:04 <clandmeter>  [13217723.055021] mono[19965]: segfault at 8 ip 00000c75b3512079 sp 000072acf5c97050 error 6 in mono-sgen[c75b342f000+2e8000]
2016-02-11 09:56:04 <clandmeter> which error does it give now?
2016-02-11 09:56:42 <ncopa> bah
2016-02-11 09:56:45 <ncopa> i think i know why it happens
2016-02-11 09:56:59 <ncopa> and why it worked in some places
2016-02-11 09:58:00 <ncopa> from runtime/_tmpinst/bin/mono
2016-02-11 09:58:09 <ncopa> exec "$r/libtool" --mode=execute "$r/mono/mini/mono" --config "/home/ncopa/aports/testing/mono/src/mono-4.2.2/runtime/etc/mono/config" "$@"
2016-02-11 09:58:26 <ncopa> $ head -n1 libtool
2016-02-11 09:58:26 <ncopa> #! /bin/bash
2016-02-11 09:59:42 <clandmeter> :)
2016-02-11 10:11:49 <pluesch> I'm currently trying to build the whole main repository with buildflags -O2 instead of -Os (In hope to fix my qemu issue with that) and don't seem to be able to get gcc built (edge). The error is: "configure: error: GNAT is required to build ada". Anyone knows how to get GNAT? There are some makepends (gcc-gnat and libgnat) but they don't seem to help/are already in the APKBUILD.
2016-02-11 10:15:27 <ncopa> pluesch: you need apk add gcc-gnat or so
2016-02-11 10:15:34 <ncopa> or bootstrap gcc :-(
2016-02-11 10:16:43 <pluesch> also when gcc-gnat is already present in the APKBUILD?
2016-02-11 10:41:42 <ncopa> yes thats the problem
2016-02-11 10:41:46 <ncopa> you need gnat to build gnat
2016-02-11 10:47:53 <skarnet> don't you just love gnu
2016-02-11 10:52:25 <ncopa> same problem with gcc itself. you need a C compiler to build the C compiler
2016-02-11 10:52:40 <ncopa> and openjdk
2016-02-11 10:52:43 <ncopa> you need java to build java
2016-02-11 11:52:21 <skarnet> ncopa: but the C part of gcc can bootstrap itself. It's hard because it's making a lot of undocumented assumptions, but it can.
2016-02-11 11:53:39 <ncopa> but i agree, its a pain that you need bootstrap gnat
2016-02-11 12:22:31 <xsteadfastx> is there a way to use git repos as source for building packages? like in arch? i have a big problem with submodules for phantomjs
2016-02-11 12:28:10 <clandmeter> xsteadfastx: yes, but we dont advise a direct git pull, as the source can be different per pull.
2016-02-11 12:28:29 <clandmeter> xsteadfastx: we suggest to create a snapshot and provide it somewhere for download.
2016-02-11 12:29:02 <xsteadfastx> clandmeter: ah ok. so to put everything together with all submodules and stuff together and use that
2016-02-11 12:29:47 <xsteadfastx> i will give that a try :)
2016-02-11 12:30:11 <xsteadfastx> its not easy for a package beginner. so sorry for all the questions
2016-02-11 12:30:15 <clandmeter> yes, ppl with commit access put snapshots in http://dev.alpinelinux.org/archive
2016-02-11 12:30:24 <clandmeter> but the location doesnt really matter.
2016-02-11 12:30:46 <clandmeter> abuild has a snapshot function
2016-02-11 12:30:56 <clandmeter> but its not much used.
2016-02-11 12:32:01 <xsteadfastx> ok cool. thats good informations. i will give it a try and i will see if i get further
2016-02-11 13:28:54 <xsteadfastx> clandmeter: do i see this right that abuild snapshot doesnt handle the submodules?
2016-02-11 13:29:32 <clandmeter> xsteadfastx: correct
2016-02-11 13:29:52 <clandmeter> but you can also write your own inside the apkbuild
2016-02-11 13:30:21 <clandmeter> any function defined in apkbuild can be excuted by abuild funcname
2016-02-11 13:30:43 <clandmeter> so if you add snapshot() it will overide the one in abuild
2016-02-11 13:31:14 <xsteadfastx> oh really? thats nice :) i will give it a try
2016-02-11 15:16:58 <kunkku> LadyAlissa: thanks for filing the issue on luaossl
2016-02-11 15:17:22 <kunkku> ... but just use 'apk add lua-ossl' to continue your actual work :)
2016-02-11 15:19:18 <vkris> any reason for not moving nodejs to 5.x (stable) ?
2016-02-11 15:21:01 <vkris> or do similar to php7 i.e testing/nodejs5
2016-02-11 15:37:50 <LadyAlissa> kunkku: unfortunately what I'm doing requires the luarocks version
2016-02-11 15:55:26 <Aragon> I've recently gotten Alpine installed into a KVM guest by making a PXE boot of the x86 ISO, but it required some manual commands and hacking to the init script.  Is there any interest to make it work better in such an environment out the box?
2016-02-11 16:14:51 <clandmeter> Aragon: there are notes on the wiki about pxe iirc.
2016-02-11 16:16:46 <Aragon> clandmeter: yea, I'm guessing they're outdated though.  Wasn't sufficient for 3.3.1.
2016-02-11 16:17:00 <Aragon> http://wiki.alpinelinux.org/wiki/PXE_boot
2016-02-11 17:10:02 <kunkku> Aragon: that has been on my todo list for 2 years :)
2016-02-11 17:11:27 <bfritz> Aragon: netboot.xyz users likely interested: https://github.com/antonym/netboot.xyz/issues/30
2016-02-11 17:13:24 <kunkku> iirc there were some issues with kernel module loading and more exotic network config (bridges etc.)
2016-02-11 17:29:52 <vkris> can some pls update http://wiki.alpinelinux.org/wiki/LXC, there is something missing,
2016-02-11 17:30:20 <vkris> was able to create all interfaces, even showed in container, but cannot ping either way
2016-02-11 17:30:40 <vkris> I tested on ALv3.3 (host+container)
2016-02-11 17:31:08 <vkris> seemed to work 2yrs back
2016-02-11 17:32:35 <vkris> btw is it bridge-ports or bridge_ports ?
2016-02-11 17:40:51 <kunkku> I use the former, but I'm not sure if it matters
2016-02-11 17:43:38 <kunkku> iirc I had to enable IP forwarding to make ^^^ work, which is strange
2016-02-11 17:46:01 <vkris> did that, as on wiki
2016-02-11 17:46:28 <vkris> I can see all interfaces in host and guest as expected
2016-02-11 17:46:52 <vkris> but ping or wget does not work
2016-02-11 17:47:23 <vkris> I have httpd on host, so tried to wget a file
2016-02-11 17:48:01 <kunkku> hm, I have ip_forward=0 on one host and it still works
2016-02-11 17:48:12 <kunkku> AL 3.2
2016-02-11 17:48:53 <vkris> yes, something changed in v3.3
2016-02-11 17:52:48 <kunkku> is your i/f up and has it an address?
2016-02-11 18:02:10 <vkris> guest http://tpaste.us/2zja
2016-02-11 18:03:03 <vkris> host , http://tpaste.us/GXw1
2016-02-11 18:04:25 <vkris> routes http://tpaste.us/2LBm
2016-02-11 18:05:04 <antonym> Aragon: bfritz: yes, that's relevent to my interests :), arch handles it pretty well with memdisk by using the phram module, i've been able to add a lot of arch distros to ipxe that were iso only
2016-02-11 18:06:34 <antonym> i'm mainly trying to avoid cracking open the original isos to network boot the bits as it needs to be trusted by not being modified
2016-02-11 18:06:56 <kunkku> vkris: you have used the same network address (192.168.0.0/24) for three interfaces
2016-02-11 18:08:18 <kunkku> your pings are leaving from wlan0
2016-02-11 18:08:21 <vkris> ok, would but br0 and eth1 on same
2016-02-11 18:08:45 <kunkku> yes on guest you would use the same network as br0
2016-02-11 18:09:10 <vkris> let me try
2016-02-11 18:09:34 <vkris> just followed the wiki
2016-02-11 18:11:37 <kunkku> yeah, the wiki kind of assumes you don't use the same network address elsewhere...
2016-02-11 18:12:48 <vkris> yesssss !! thanks
2016-02-11 18:13:04 <vkris> all OK
2016-02-11 18:15:15 <vkris> moved br0(host) and eth1(guest) to 192.168.2.x
2016-02-11 18:20:09 <vkris> ok, maybe it worked 2yrs back coz my host might have been 192.168.0.x
2016-02-11 18:20:29 <vkris> so just copy pasted from wiki and worked
2016-02-11 19:13:24 <Aragon> antonym: hmm, I use pxelinux, so I think cracking open the isos was necessary?
2016-02-11 19:16:23 <Aragon> I just removed the kernel, initramfs, and modloop, then it's just some changes to the init script to make bootup error-free.
2016-02-11 19:17:56 <antonym> Aragon: memdisk should work with pxelinux as well... the problem lies in where after memdisk loads the kernel and initrd, it can't mount the rootfs so it usually runs into a mount failure.  if the initrd uses memdiskfind, it locates the memdisk loaded ISO in RAM, and then creates a mountpoint using phram and mtdblock for it letting the OS boot
2016-02-11 19:18:38 <antonym> if that bit of functionality is in the ISO, you can use memdisk to boot the original iso directly from the website without having to crack it open
2016-02-11 19:19:05 <antonym> it probably wouldn't be too hard to add to alpine
2016-02-11 19:20:32 <Aragon> Hmmm, maybe I should give this memdisk method a poke first to understand.  I haven't seen something like that before.
2016-02-11 19:20:35 <antonym> more info here if curious: https://goo.gl/6ptNiU
2016-02-11 19:21:05 <Aragon> Thanks
2016-02-11 19:21:08 <antonym> arch figured that out a while ago, so a lot of their downstream stuff just works with memdisk
2016-02-11 19:27:37 <Aragon> antonym: I think it might be possible to avoid the phram+mtdblock trick.  The way my netboot hack worked, the installer ran entirely off kernel, initrd, and http:// links for everything else.  The init script just didn't handle detecting and setting things up for that scenario too well.
2016-02-11 19:27:57 <antonym> Aragon: but you had to crack open the ISO?
2016-02-11 19:28:04 <Aragon> Yes
2016-02-11 19:28:17 <antonym> yeah, the memdisk trick avoids that
2016-02-11 19:29:04 <Aragon> I'll do some more reading later and give it a whirl, combined with the hacks I made after bootup.
2016-02-11 19:29:15 <antonym> and the alpine isos are pretty small already so they'd probably boot really quickly from http
2016-02-11 19:29:54 <Aragon> Yea, majority is kernel and modules.  There's 7 MB of APKs that get wasted because they'd get refetched via HTTP, but that's not too bad.
2016-02-11 19:30:27 <Aragon> in 32 bit at least... I guess 64 bit will have a bit more waste.
2016-02-11 19:30:36 <antonym> yeah, that or the ISOs are hosted cracked open as well so you can just pull from those sources directly
2016-02-11 19:31:20 <antonym> running a public pxe server, people have trust issues, so i try to pull everything i can from the original sources :)
2016-02-11 19:31:22 <Aragon> Yes, a bit like Debian do it.  Alpine devs will need to be willing to maintain those releases though I guess. :)
2016-02-11 19:31:48 <antonym> yeah, being able to pull the installer kernels and streaming the packages is ultimately the easiest
2016-02-11 19:32:01 <antonym> but i'm sure thats a ton more dev work
2016-02-12 03:39:30 <kimo_sabe> pluesch: I added a little logging: "Guest moved used index from 63924 to 64031 on dev virtio-blk"
2016-02-12 03:41:43 <kimo_sabe> pluesch: http://sprunge.us/HRbX added to qemu/APKBUILD
2016-02-12 04:12:24 <kimo_sabe> pluesch: and I've managed to kill it with network as well. iperf seems to be a quick killer
2016-02-12 06:30:05 <pluesch> kimo_sabe: what iperf settings are you using?
2016-02-12 11:19:39 <mosez> is there any way to get https://github.com/andyshinn/alpine-pkg-glibc/blob/master/APKBUILD for example into the community repo? :)
2016-02-12 11:41:40 <ncopa> mosez: I think we'd need to build it from source
2016-02-12 11:42:02 <ncopa> but apparently that is not so easy
2016-02-12 11:50:00 <mosez> hum, yeah... andyshinn is doing it on ubuntu at https://github.com/andyshinn/docker-glibc-builder
2016-02-12 13:04:52 <ScrumpyJack> mosez: what does "compatibility layer" mean?
2016-02-12 13:06:59 <fabled> ewww.. seems a binary blob drop in of glibc
2016-02-12 13:13:45 <ncopa> fabled: its a hack for people who wants to run things like oracle java for linux on alpine linux
2016-02-12 13:14:01 <fabled> like i said. ewww.
2016-02-12 13:14:04 <ncopa> closed source apps "for linux"
2016-02-12 13:14:06 <fabled> ;)
2016-02-12 13:14:09 <ncopa> :)
2016-02-12 13:31:24 <nmeum> ncopa: what's your opinion on %1572 and %1573?
2016-02-12 13:32:59 <ncopa> ok with me. rnalrd? %1573
2016-02-12 13:40:04 <ncopa> testing algitbot: %1572 and %1573?
2016-02-12 14:15:15 <rnalrd> ncopa, fine w/ me, someone else ported umurmur on polarssl
2016-02-12 14:17:09 <nmeum> great, I will commit it
2016-02-12 16:26:55 <_fps__> hi, has anyone tried porting lldb to Alpine Linux?
2016-02-12 16:28:13 <_fps__> we have managed to port llvm-lldb on NetBSD via pkgsrc package system.
2016-02-12 16:29:13 <_fps__> I have just installed Alpine to give it a try via aports.
2016-02-12 17:28:41 <mitchty> ok broke my port apart into ghc-bootstrap and ghc ports for now
2016-02-12 17:28:46 <mitchty> https://github.com/mitchty/aports/commit/b3c5f7afaf38c1e20e72da4fdfd0147ca8b133a1
2016-02-12 17:28:55 <mitchty> is the ghc-bootstrap bit with the snapshot stuff
2016-02-12 17:29:10 <mitchty> and https://github.com/mitchty/aports/commit/1e76de0bd4bba04a07886d620350b5c1d675b363 is the ghc apkbuild
2016-02-12 17:29:29 <mitchty> the patch files are the same for ghc/llvm in both builds
2016-02-12 17:30:15 <mitchty> only question i have is where https://github.com/mitchty/aports/commit/b3c5f7afaf38c1e20e72da4fdfd0147ca8b133a1#diff-b333a199fb3ff29a67b50fd741dcc8d0R40 should scp to
2016-02-12 17:30:43 <mitchty> and then i can update the source line and include hashes
2016-02-12 23:29:10 <ammunta> mitchty: I'm not sure I understand why the patches are duplicated in ghc-bootstrap
2016-02-12 23:30:16 <ammunta> # Must also keep all the patch files in sync with
2016-02-12 23:30:17 <ammunta> # normal ghc package.
2016-02-12 23:30:19 <mitchty> ammunta: so the bootstrapped ghc is built the same way as ghc is natively, otherwise I was getting llvm bytecode errors due to different default expecttions
2016-02-12 23:30:24 <ammunta> are they actually applied though?
2016-02-12 23:30:33 <mitchty> yep
2016-02-12 23:31:17 <mitchty> https://github.com/mitchty/aports/commit/b3c5f7afaf38c1e20e72da4fdfd0147ca8b133a1#diff-a2abbf0238e849ba6d4224fa18755c96R71
2016-02-12 23:31:37 <mitchty> whoops wrong thing
2016-02-12 23:31:56 <mitchty> https://github.com/mitchty/aports/commit/b3c5f7afaf38c1e20e72da4fdfd0147ca8b133a1#diff-1a2a40da21312c3bce9876158f5f88e7R20
2016-02-12 23:32:33 <ammunta> ah okay I missed that
2016-02-12 23:34:08 <mitchty> yeah i was originally going to do the llvm stuff in that script but since the bootstrap bit got mentioned it kinda went by the wayside
2016-02-12 23:34:22 <ammunta> wow
2016-02-12 23:34:24 <ammunta> wow.
2016-02-12 23:34:43 <ammunta> hm did we end up deciding to always build from bootstrap?
2016-02-12 23:35:34 <mitchty> thats what got asked
2016-02-12 23:36:02 <mitchty> i dont' care too much either way
2016-02-12 23:36:23 <mitchty> just noticed a stray -fPIC in the bootstrap build.mk
2016-02-12 23:37:40 <mitchty> and to answer "why build llvm", the answer is: arm support will need it anyway
2016-02-12 23:38:26 <mitchty> and i tried building with 3.5.2 and that went nowhere fast
2016-02-12 23:38:30 <ammunta> I assume the older version is intentional because of reasons?
2016-02-12 23:39:05 <mitchty> https://github.com/mitchty/aports/commit/1e76de0bd4bba04a07886d620350b5c1d675b363#diff-04b6fa673e01f20846825ae0e6cd0164R38
2016-02-12 23:39:09 <mitchty> those are the reasons :)
2016-02-12 23:39:35 <mitchty> well that plus the para above
2016-02-12 23:41:16 <mitchty> using 3.6 was a bit of a science experiment, normally 7.10 doesn't work with anything but 3.5, and for arm 3.5.2 with some very specific patches (even then barely)
2016-02-12 23:42:11 <mitchty> i've been trawling through the ghc phabricator and think I know what to do now to get a cross compiled arm build (i hope)
2016-02-12 23:44:07 <ammunta> oh I was reading through and was about to say "arm port not in sight, then, I assume?"
2016-02-12 23:44:23 <mitchty> it kinda works, but i think i hit 2 bugs
2016-02-12 23:44:32 <ammunta> "Of course, it is easy to claim that a compiler works. The proof, however, is in the testsuite results," "That’s right, you can count the testsuite failures on two hands and a foot!"
2016-02-12 23:44:41 <mitchty> either way it can compile a basic hello world but not not itself
2016-02-12 23:44:55 <mitchty> err - one not there
2016-02-12 23:45:37 <mitchty> a lot of this nonsense is there for the not yet existent arm port
2016-02-12 23:46:13 <mitchty> like the splitdll patch, which is a cross compile bug relating to windows support
2016-02-12 23:46:23 <mitchty> given this isn't windows i just remove it entirely
2016-02-12 23:54:54 <mitchty> so one hitch to using the bootstrap compiler this way is that cabal will be using a text library with integer-simple and not gmp so it might be slower in degenerate cases
2016-02-12 23:56:08 <mitchty> and i can't recompile that with the ghc I am building, least I can't come up with a way to yet, and given bootstrapping needs of cabal I dont' want to deal with a separate cabal package yet
2016-02-12 23:58:28 <mitchty> but if you want me to change anything else let me know, it can't get much more convoluted than it already is
2016-02-13 00:23:06 <ammunta> "it can't get much more convoluted than it already is" ah
2016-02-13 00:23:11 <ammunta> famous last words
2016-02-13 06:20:37 <torment> is there a docker container that allows me to build the missing apps that i need in alpine thats easy to use?
2016-02-13 06:21:28 <torment> i looked at the how-to make an alpine package and it looks rediculous
2016-02-13 06:26:45 <torment> its like 5 pages -  set your github variables, edit these templates.  seriously this needs to stop
2016-02-13 07:20:01 <ammunta> torment: github variables????
2016-02-13 07:20:37 <ammunta> how does github even get involved here
2016-02-13 07:33:22 <coredumb> yeah this needs to stop :D
2016-02-13 07:33:47 <coredumb> docker is not the solution to everything :)
2016-02-13 07:57:01 <ammunta> docker is the solution to static-linking all of userspace into your app
2016-02-13 07:57:07 <ammunta> no more, no less
2016-02-13 07:57:42 <ammunta> it is invalidated if you (a) don't need a solution (b) don't need to static-link (b) all of userspace (c) into an app
2016-02-13 07:57:57 <ammunta> :&&
2016-02-13 08:46:31 <coredumb> ammunta: :D
2016-02-13 08:47:51 <coredumb> sadly ppl see it as the solution to _any_ deployment these days
2016-02-13 10:20:07 <yth> torment: not github, just git, if you want to use the aports tree or contribute patches
2016-02-13 10:39:03 <ammunta> coredumb: I'm aware
2016-02-13 10:39:08 <ammunta> hell, even I'm mildly guilty
2016-02-13 10:39:14 <coredumb> :O
2016-02-13 10:45:16 <coredumb> hey maybe torment was just trolling and we just walking right in ?
2016-02-13 10:47:10 <coredumb> walked*
2016-02-13 10:48:51 <skarnet> then it's bad taste. It's too easy to troll with github and docker.
2016-02-13 11:17:27 <ammunta> it's hard to tell
2016-02-13 11:34:00 <_fps__> is there anyway to get sys/sysctl.h header on alpin?
2016-02-13 11:34:03 <_fps__> alpine*
2016-02-13 12:05:15 <kunkku> _fps__: not easily
2016-02-13 12:05:38 <kunkku> the correct thing to do is to fix the application not to use that header
2016-02-13 12:05:51 <kunkku> that has been deprecated for 8 years now
2016-02-13 12:06:48 <_fps__> kunkku: did it by ifdef'ing out using __GNUC__
2016-02-13 12:08:22 <kunkku> yes, many applications try to use it if  __linux is defined
2016-02-13 12:08:36 <_fps__> is there a better preprocessor to detect musl-libc?
2016-02-13 12:09:58 <kunkku> one way is to change __linux to __GLIBC__, see e.g. http://git.alpinelinux.org/cgit/aports/tree/main/lua-ossl/musl-fixes.patch
2016-02-13 12:11:45 <kunkku> there are 172 patches in aports with 'musl' in the name
2016-02-13 12:12:34 <kunkku> ideally they should be fed to the upstream projects, but it's a lot of work to convince them on proper musl compatibility
2016-02-13 12:12:47 <_fps__> kunkku: hyva :)
2016-02-13 12:13:24 <kunkku> :)
2016-02-13 12:15:08 <_fps__> I am building dotnet/corefx on Alpine Linux (which installed yesterday for the first time). So through some idef magic, i am able to build it 31% so far.
2016-02-13 12:15:43 <_fps__> git clone https://github.com/dotnet/corefx; cd corefx; ./build.sh native
2016-02-13 12:15:54 <_fps__> working on the networkin stack
2016-02-13 14:46:26 <__gilles> hi
2016-02-13 14:46:47 <__gilles> no inet_net_pton() in alpine ?
2016-02-13 15:54:40 <ammunta> __gilles: do you have the headers installed
2016-02-13 15:55:17 <__gilles> yes, but it seems inet_net_pton is not in muslc, only inet_pton
2016-02-13 15:55:19 <__gilles> i worked around :-)
2016-02-14 01:18:51 <_fps__> hi, i am using cmake to detect 'struct in_pktinfo' in `netinet/in.h` and clang complains about incomplete type 'in_pktinfo'. is there another header which should appear before that? I tried using 'netinet/packet.h' and 'sys/types.h' headers in conjunction with 'netinet/packet.h', but didn't help.
2016-02-14 01:20:37 <_fps__> i checked in /usr/include/netinet/in.h and the said struct exists
2016-02-14 01:21:41 <_fps__> note that on other linx OSes, the same introspection works when we use 'linux/in.h' alone and on FreeBSD/NetBSD and OSX, it works with 'netinet/in.h'
2016-02-14 09:50:36 <skarnet> _fps__: it's very probably a question of feature test macros. Try compiling your file with -D_GNU_SOURCE.
2016-02-14 09:53:38 <_fps__> skarnet: that worked! also cmake adds -std=c11 flag to clang command, removing it also compiles it successfully.
2016-02-14 09:54:53 <skarnet> wow, if that's the case, it's a horrible bug in cmake. A build tool should never enforce the standard used for compiling!
2016-02-14 09:55:36 <skarnet> enforcing -std=c11 will undefine all the system-specific feature test macros.
2016-02-14 09:56:40 <skarnet> removing -std=c11 will make the compiler use the "standard" ftms for the language it compiles. For gcc, I think it's _GNU_SOURCE. For clang, I have no idea.
2016-02-14 10:14:22 <_fps__> skarnet: cmake let us configure those flags. in which case, it doesn't seem like a bug to me
2016-02-14 10:15:58 <skarnet> ah. Anyway, it's generally cleaner to stick to a C standard for the project by default and add the needed ftms to the compilation units that need them.
2016-02-14 11:07:30 <mosez> scrumpyjack: i dont care about any properitary java crap... i just wanted to get meteor js running on alpine with the glibc compat package
2016-02-14 11:09:50 <mosez> this damn crappy meteor ships with a node and npm binary compiled on glibc -.-
2016-02-14 11:10:08 <mosez> i want to get rid of the bloated ubuntu/debian containers on my cluster
2016-02-14 12:23:36 <_fps__> mosez: node.js guys build linux binaries on centos5(.11) to maximize backward & cross-linux distro compatibilities. If libuv and v8 are compiling with musl-libc, porting node.js would be less of a hassle.
2016-02-14 13:25:14 <coredumb> I hardly imagine someone using something as "new" as nodejs on something as "old" as EL5 ...
2016-02-14 14:47:01 <vinben> Can anyone give me any guidance for compiling a custom kernel for Alpine? I found this http://wiki.alpinelinux.org/wiki/Custom_Kernel but it is empty! I am familiar with compiling custom kernels for Debian.
2016-02-14 16:14:52 <e5fvAAmOistj> vinben i compile my kernels the same way on every system. the linux tree contains a README that should be ok irrespective of the distor
2016-02-14 16:14:57 <e5fvAAmOistj> s/distor/distro/
2016-02-14 16:18:07 <vinben> So I need to download kernel.org source for a version that matches GR security testing. Install source into my home dir. Download GR security testing patch and patch source. make oldconfig...
2016-02-14 16:19:32 <e5fvAAmOistj> well. you need an oldconfig for that
2016-02-14 16:20:12 <vinben> Yes, there is one sitting in /boot with a different name of course
2016-02-14 16:20:31 <coredumb> or like on other distro you take the package sources, you modify your config to your need and you redo the package
2016-02-14 16:22:03 <vinben> I have got lazy using make deb-pkg and wondered if there was a similar thing for packaging custom kernels for Alpine.
2016-02-14 17:00:24 <coredumb> know nothing about deb-pkg, but a "custom" kernel is just a matter of doing your own pkg anyway
2016-02-14 17:00:32 <coredumb> and this is fairly easy on alpine
2016-02-14 20:35:57 <vkris> php-fpm.conf has user/group set to nobody, hope its ok ?
2016-02-14 20:36:46 <skarnet> theoretical Unix here: the nobody user and group are precisely supposed to not own any files
2016-02-14 20:37:08 <skarnet> so it's probably a mistake, a .conf file should belong to root
2016-02-14 20:38:31 <vkris> iirc, there was some effort to add uniformly 'www-data' or app name
2016-02-14 20:39:48 <vkris> since unlike apache (php-apache) php-fpm process should write with 'php' user
2016-02-14 20:39:56 <skarnet> uniformisation of fake user names is pointless, and half the standard /etc/passwd is a waste of uid space
2016-02-14 20:40:16 <vkris> but I am guessing, have not use fpm much
2016-02-14 20:40:39 <skarnet> if php-fpm writes as "php", then the conf file should belong to *anyone but php*
2016-02-14 20:41:08 <skarnet> generally, /etc files should belong to root
2016-02-14 20:41:55 <vkris> hmmm.... was refering to files that php-fpm process writes during running
2016-02-14 20:42:01 <skarnet> yeah
2016-02-14 20:42:05 <skarnet> that's fine
2016-02-14 20:42:18 <vkris> like in /var or application's cache
2016-02-14 20:42:32 <skarnet> but it's not supposed to modify anything in /etc :)
2016-02-14 20:42:54 <vkris> yes, etc should be more protected
2016-02-14 20:43:06 <vkris> root
2016-02-14 20:43:26 <skarnet> if a conf file belongs to user X, then a process running as user X can modify it, so X=root is the safe option
2016-02-14 20:43:34 <vkris> unless you have web application like acf that writes to it
2016-02-14 20:43:57 <skarnet> then it should be in an app-specific directory
2016-02-14 20:51:44 <vkris> lxc seems to work nice!! on v3.3
2016-02-14 20:52:29 <vkris> I am able to do lamp developemnt work easily, with different setups
2016-02-14 20:53:18 <vkris> Thinking to write a howto-lxc-simple wiki page
2016-02-14 20:53:52 <vkris> or maybe howto-lxc-lamp-simple
2016-02-15 08:35:02 <ScrumpyJack> morning climbers. it's cold out
2016-02-15 08:36:11 <clandmeter> hello mountaineer
2016-02-15 08:37:42 <clandmeter> sun is shining here
2016-02-15 08:41:53 <ncopa> morning. i had -12C this morning
2016-02-15 08:45:59 <ammunta> it's -22 over here
2016-02-15 08:46:43 <ncopa> sounds fresh :)
2016-02-15 08:47:16 <clandmeter> where is that weather script in algitbot? :)
2016-02-15 08:52:24 <coredumb> -22 ? where are you leaving ? :O
2016-02-15 09:29:52 <vkris> http://lwn.net/Articles/674877, just wondering what would we call an AL powered microwave, AlpineWave !
2016-02-15 09:34:05 <skarnet> vkris: subscriber-only page
2016-02-15 09:38:25 <vkris> ooops, http://mirror.linux.org.au/linux.conf.au/2016/04_Thursday/D4.303_Costa_Theatre/Linux_driven_microwave.webm
2016-02-15 11:51:31 <vkris> created this wiki pg, http://wiki.alpinelinux.org/wiki/Howto-lxc-simple
2016-02-15 11:52:03 <vkris> if useful would create next series, Howto-lxc-lamp-simple
2016-02-15 12:11:18 <mosez> _fps__: node in general is not the problem... but a problem is if a node project ships with a custom binary for it...
2016-02-15 12:17:00 <mosez> ncopa: btw, i don't want to run crappy java shit, i just wanted to get meteor js running to get rid of all ubuntu/debian containers on my cluster :(
2016-02-15 12:17:34 <mosez> and as this damn meteor crap comes with a prebuilt binary for node and npm i wanted to try the glibc approach :)
2016-02-15 12:17:45 <ncopa> hi mozes
2016-02-15 12:17:48 <ncopa> whats up?
2016-02-15 12:18:18 <mosez> ncopa: just a response to the stuff from last week, i had been on vacation so i have not been able to respond :)
2016-02-15 12:18:25 <ncopa> so meteor js dont support running with system node?
2016-02-15 12:18:34 <ncopa> i have no idea what happened last week at this point :)
2016-02-15 12:18:44 <mosez> 12:19 < mosez> is there any way to get https://github.com/andyshinn/alpine-pkg-glibc/blob/master/APKBUILD for example into the community repo? :)
2016-02-15 12:18:51 <ncopa> oh ok
2016-02-15 12:19:03 <ncopa> yes, i understand the problem
2016-02-15 12:19:20 <ncopa> i dont like the attempted solution
2016-02-15 12:19:38 <ncopa> i'd like to see meteor js fixed
2016-02-15 12:19:46 <ncopa> start with sending them a bug report
2016-02-15 12:19:48 <mosez> i reallz dislike this behavior, but it looks like the company behind meteor won't change it in the near future because they say node-fibre won't compile on other than glibc :(
2016-02-15 12:20:16 <ncopa> node-fibre?
2016-02-15 12:20:20 <ncopa> whats that?
2016-02-15 12:20:32 <ncopa> what does it uses from glibc?
2016-02-15 12:21:09 <mosez> it's an npm package with native compiled part
2016-02-15 12:21:57 <mosez> @lpgeiger unfortunately this is not possible with Alpine Linux, because Meteor need to compile some modules with NPM, the principal in this case is the "node-fibers", which in turn depends on others using Python, then it not work. I try to do this for some time and still no success, 100%.
2016-02-15 12:22:02 <mosez> https://forums.meteor.com/t/docker-replace-ubuntu-for-alpine-linux-or-other/7453
2016-02-15 12:22:29 <mosez> so node-fibers, sorry :)
2016-02-15 12:25:12 <ncopa> "some Node dependencies which cannot be installed in Alpine."
2016-02-15 12:25:20 <ncopa> what are those node dependencies?
2016-02-15 12:25:33 <ncopa> what is the exact error message
2016-02-15 12:26:14 <ncopa> is it `npm install node-fibres` that fails?
2016-02-15 12:26:27 <mosez> i just know how it looked if i tried to install meteor on alpine, and this was just related to node-fibers which got a bundled nodejs binary which is compiled with glibc and thus it was not executable
2016-02-15 12:26:44 <ncopa> i have spent the last weeks trying to make node work on alpine
2016-02-15 12:26:58 <ncopa> and i have submitted fixes upstream
2016-02-15 12:27:02 <ncopa> we are getting there
2016-02-15 12:27:07 <ncopa> so node-fibers is broken
2016-02-15 12:27:19 <ncopa> if they just ship precompiled binaries
2016-02-15 12:27:23 <mosez> let me check what happens if i try to compile it
2016-02-15 12:27:36 <ncopa> report to node-fibres
2016-02-15 12:29:20 <mosez> Installed in `/app/node_modules/fibers/bin/linux-x64-v8-4.5/fibers.node`
2016-02-15 12:29:20 <fabled> ncopa, i got with ugprade:
2016-02-15 12:29:21 <fabled> (28/42) Installing nginx-common (1.8.1-r1)
2016-02-15 12:29:21 <fabled> Executing nginx-common-1.8.1-r1.pre-install
2016-02-15 12:29:21 <fabled> ERROR: nginx-common-1.8.1-r1: trying to overwrite etc/logrotate.d/nginx owned by nginx-initscripts-1.8.0-r0.
2016-02-15 12:29:21 <fabled> ERROR: nginx-common-1.8.1-r1: trying to overwrite etc/init.d/nginx owned by nginx-initscripts-1.8.0-r0.
2016-02-15 12:29:51 <fabled> oh, this is recent change
2016-02-15 12:29:56 <fabled> patch from valery
2016-02-15 12:31:21 <fabled> missing simple replaces
2016-02-15 12:31:29 <ncopa> yes
2016-02-15 12:31:35 <ncopa> valery tend to break things...
2016-02-15 12:31:43 <fabled> that was non-trivial change
2016-02-15 12:31:58 <ncopa> valerys changes tend to always be non-trivial
2016-02-15 12:32:11 <fabled> replaces is easily forgotten since it's implicit when source package is same
2016-02-15 12:32:21 <fabled> rebooting to newkernel
2016-02-15 12:33:30 <leo-unglaub> hey friends :)
2016-02-15 12:33:34 <leo-unglaub> how is everybody?
2016-02-15 12:33:34 <ncopa> h
2016-02-15 12:33:36 <ncopa> hi
2016-02-15 12:33:46 <ncopa> good i think :)
2016-02-15 12:37:57 <leo-unglaub> thats great :)
2016-02-15 12:42:29 <ncopa> leo-unglaub: and how are you doin?
2016-02-15 12:43:01 <leo-unglaub> well, not so good .. thats why i am not here so much
2016-02-15 12:43:13 <ncopa> :-/
2016-02-15 12:43:14 <leo-unglaub> and computers make me mad ...
2016-02-15 12:43:18 <ncopa> sorry to hear
2016-02-15 12:43:25 <ncopa> then i have an advice
2016-02-15 12:43:32 <skarnet> You can be here when you're not doing well! we'll offer support.
2016-02-15 12:43:34 <ncopa> throw them out of your window
2016-02-15 12:43:39 <leo-unglaub> hehehe
2016-02-15 12:43:43 <ncopa> without opening it...
2016-02-15 12:43:44 <leo-unglaub> its not so easy *g*
2016-02-15 12:44:06 <skarnet> ncopa's advice is best advice
2016-02-15 12:44:34 <skarnet> we can be mad at computers together!
2016-02-15 12:44:40 <leo-unglaub> the thing that makes me mad is that we have all the pieces of software to have the best operationg system on the planet, we just dont combine them the right way
2016-02-15 12:45:11 <skarnet> we will do so.
2016-02-15 12:45:13 <leo-unglaub> alpine -> fast, clean, secure, openbsd -> best bootloader, dbsd -> best file system, ...
2016-02-15 12:45:44 <leo-unglaub> mbedtls -> best crypto, openbsd -> best io manager
2016-02-15 12:45:45 <leo-unglaub> ...
2016-02-15 12:45:50 <skarnet> Have patience. Things come together slowly, but surely.
2016-02-15 12:46:24 <ncopa> step by step
2016-02-15 12:47:09 <leo-unglaub> yes, i know ... but it feels sometimes that open source is falling behind ..
2016-02-15 12:47:27 <skarnet> falling behind what? proprietary software?
2016-02-15 12:47:34 <leo-unglaub> sadly yes ..
2016-02-15 12:47:35 <skarnet> proprietary isn't doing any better. It sucks too.
2016-02-15 12:47:45 <skarnet> It's just you don't see how much it sucks, because you can't see the code.
2016-02-15 12:47:58 <leo-unglaub> on windows 7, hybernate, suspend, external usb drives work very well ... on linux ... usb stick still suck for data exchange
2016-02-15 12:48:22 <skarnet> you absolutely do not want to know how Windows 7 makes hibernate work.
2016-02-15 12:49:12 <jirutka> Windows totally sucks in many many other scenarios, e.g. networking
2016-02-15 12:49:47 <leo-unglaub> skarnet: sure, they have huge internal problems ... but if you plug in an usb drive it workd 99% of the time ...
2016-02-15 12:50:27 <leo-unglaub> maybe i am a little bit oversensitive ... but totay my girlfriend foced me to remove alpine with xfce from her laptop and reinstall windows for her because a lot of stuff did not work
2016-02-15 12:50:36 <jirutka> well, but there’s also a great chance that it will also load some nasty rootkit or something similar… ;)
2016-02-15 12:50:43 <leo-unglaub> so maybe today i am not the most optimistic person *g*
2016-02-15 12:50:53 <skarnet> leo-unglaub: "works 99% of the time" is YOUR experience. Mine is more around 75%.
2016-02-15 12:52:09 <skarnet> I am blessed to be technically savvy. My family members are absolutely *desperate* whenever they have to do something on a computer, even with Windows, because they are scared that it won't work. By experience.
2016-02-15 12:52:36 <skarnet> Anything more complex than powering it on and launching a Web browser is a huge mountain to climb for them.
2016-02-15 12:52:50 <skarnet> (and sometimes, even a web browser won't work.)
2016-02-15 12:53:15 <skarnet> So, don't think Windows has it better. Everything is awful.
2016-02-15 12:53:25 <leo-unglaub> hehe, maybe *g*
2016-02-15 12:53:48 <skarnet> (So is Apple. Have you heard of the Epoch bug that can permanently brick the iPhone 6?)
2016-02-15 12:53:58 <leo-unglaub> well, apple always sucked *g*
2016-02-15 12:54:16 <leo-unglaub> the epoch bug is not new, they screw up time every timezone change ...
2016-02-15 12:54:29 <jirutka> Same here… I admire my dad’s patience with his Windows notebook. From my POV, it’s totally unusable and it makes me totally crazy just after 5 minutes when I try to fix something.
2016-02-15 12:54:36 <leo-unglaub> but the other one was even worse, the one where adobe deleted the first hidden folder in / for no reason
2016-02-15 13:46:29 <ncopa> freetype 2.6.3 is out
2016-02-15 13:46:35 <ncopa> looks like the patches needs to be rebased
2016-02-15 13:46:47 <ncopa> clandmeter: looks like you're the maintainer ;)
2016-02-15 13:47:03 <clandmeter> :)
2016-02-15 13:48:43 <clandmeter> im trying to build latest chromium
2016-02-15 13:48:47 <clandmeter> what a joy
2016-02-15 13:49:00 <ncopa> sounds fun...
2016-02-15 13:58:54 <clandmeter> almost as much fun as freetype and its patches.
2016-02-15 14:21:45 <ScrumpyJack> which browser works on armhf?
2016-02-15 14:22:14 <ScrumpyJack> dillo? :)
2016-02-15 14:23:12 <Aragon> Hiya. Does anyone have any pointers for cross-compiling to ARM?
2016-02-15 14:23:42 <ScrumpyJack> using alpine linux?
2016-02-15 14:23:59 <Aragon> I've already gone through getting a musl-cross toolchain built. Yea, using alpine linux.
2016-02-15 14:24:30 <Aragon> Or anything.  I'd like to build an ARM Alpine from any x86_64 system.
2016-02-15 14:26:00 <Aragon> Been toying with abuild, but it doesn't seem to handle cross-compiling, although that's no surprise given how complicated that is. :)
2016-02-15 14:26:30 <Aragon> How are the ARM Alpine releases built?
2016-02-15 14:27:30 <ScrumpyJack> they are built on arm arch
2016-02-15 14:27:53 <Aragon> Really... using a Qemu VM?
2016-02-15 14:29:34 <fabled> Aragon, no, on native hw
2016-02-15 14:29:37 <ScrumpyJack> I think it's bare metal
2016-02-15 14:29:46 <ScrumpyJack> ninja'd again :)
2016-02-15 14:29:46 <fabled> currently using wandboard/quad
2016-02-15 14:30:12 <Aragon> Shucks, ok
2016-02-15 14:30:19 <Aragon> Thanks
2016-02-15 14:30:28 <fabled> initial bootstrap is cross built
2016-02-15 14:30:43 <fabled> the toolchain package and core packages have some cross-building support
2016-02-15 14:30:52 <fabled> but it's for bootstrapping only currently
2016-02-15 14:31:02 <Aragon> Ok cool
2016-02-15 14:41:58 <ScrumpyJack> can't see to get firefox onto an ARM thing that has less than 512M of ram
2016-02-15 14:44:41 <ScrumpyJack> tmpfs / needs to be 340M, leaving nothing much. lbu commit can't write after that unless I add more space to tmpfs. then a reboot breaks the whole thing as there isn't enough space to unpack the apks
2016-02-15 14:45:38 <ScrumpyJack> as it goes back to (RAM - GPU )/2 or 218M on reboot
2016-02-15 14:46:42 <ScrumpyJack> running from the SD card would be a welcome option
2016-02-15 15:13:24 <_mjones> ISTM that there are a lot of things in testing repo that should move to main, especially if testing is regarded as being mostly for Edge and not for stable.
2016-02-15 15:13:52 <_mjones> Is the criteria mainly that people confirm things are stable and ask for specific packages to move to main or community?
2016-02-15 15:14:48 <vkris> doesn't firefox comes for mobile too, don't know much about it
2016-02-15 15:15:48 <_mjones> Yes, there's a firefox on android. It's not terribly popular, fwiw.
2016-02-15 15:17:31 <_mjones> 
ACTION shakes head at ncopa's https://bugzilla.mozilla.org/show_bug.cgi?id=1243724 , but does approve of the good comments to the questionable optimisation.

2016-02-15 17:16:09 <ncopa> _mjones: yes, the criteria for moving out of testing is that someone ask for it
2016-02-15 17:16:21 <ncopa> and that it is not tobably broken
2016-02-15 17:16:26 <ncopa> totally*
2016-02-15 17:20:03 <_mjones> ncopa: excellent. I'm in the process of confirming functionality on a few things before I ask (example: SDL2).
2016-02-15 17:20:16 <_mjones> Is the preference to file an issue or is asking on irc just as good?
2016-02-15 17:22:12 <ncopa> just askin irc is normally good enough
2016-02-15 17:23:08 <ncopa> but filing a bug may be good if nobody can do it immediately
2016-02-15 17:23:12 <ncopa> so its not forgotten
2016-02-15 17:23:32 <ncopa> would be great to get some help with cleaning up testing
2016-02-15 17:28:38 <_mjones> ncopa: great, I'm looking to do some of that work. Is the team preferring Github PR over mailing list?
2016-02-15 17:28:59 <ncopa> depends if it is 1 or 10 patches :)
2016-02-15 17:29:23 <ncopa> if you have more than 3 i'd prefer a PR
2016-02-15 17:30:19 <_mjones> ncopa: you mean patches in total, correct? So if I have submissions of 10 different patches against 10 different packages, you'd want a PR?
2016-02-15 17:30:44 <_mjones> I guess I'm asking if there's any case where mail is preferred over a PR, now.
2016-02-15 17:31:13 <ncopa> does not matter i suppose
2016-02-15 17:31:21 <ncopa> i think email is good if you want feedback
2016-02-15 17:31:34 <ncopa> or just have a single commit
2016-02-15 17:31:52 <ncopa> but if you have many commits then its easier for me to git pull from some place
2016-02-15 17:33:09 <_mjones> ok. That means you prefer mail for feedback over PR discussion?
2016-02-15 17:37:53 <skarnet> I think it means "stop relying on github so much" :)
2016-02-15 17:40:08 <_mjones> skarnet: ok, I'm just figuring out what I'm going to do. I don't currently have an email-intensive workflow and just using github is awfully appealing, but if the discussion is best on mailing-list that's probably fine.
2016-02-15 17:41:01 <_mjones> skarnet: I don't blame anyone for not wanting to use github discussion, or split discussion, but it potentially adds some wrinkles particular to my situation.
2016-02-15 17:41:18 <ncopa> _mjones: do what works for you
2016-02-15 17:41:20 <skarnet> honestly, I don't know what the preferred workflow for Alpine is.
2016-02-15 17:41:30 <ncopa> if github works for you then I'm ok with it
2016-02-15 17:42:03 <ncopa> it does not seem that we manage to keep up in any case :)
2016-02-15 17:44:01 <_mjones> ncopa: ok, tnx for blessing that direction for now.
2016-02-15 18:17:09 <clandmeter> nmeum: around?
2016-02-15 18:17:48 <nmeum> clandmeter: yes, what's wrong?
2016-02-15 18:18:26 <clandmeter> not much
2016-02-15 18:18:44 <clandmeter> pain in my back, but thats not why i called you :)
2016-02-15 18:19:01 <clandmeter> i remember i saw a patch for abuild regarding snapshot
2016-02-15 18:19:08 <clandmeter> what was it for/to fix?
2016-02-15 18:20:04 <nmeum> it fixed the fact that $repoenv wasn't used for git repositories. I already applied it
2016-02-15 18:20:13 <nmeum> http://git.alpinelinux.org/cgit/abuild/commit/?id=578ab740adb03486801856886b261aa48a1d9c30
2016-02-15 18:20:38 <clandmeter> reporev?
2016-02-15 18:21:07 <nmeum> I thought you wrote snapshot() :p $reporev is used to indicate a specific revesion to checkout…e.g a commit hash
2016-02-15 18:21:35 <nmeum> the comment above snapshot says: "$reporev will select the correct commit, revision or tag for you"
2016-02-15 18:21:49 <nmeum> however, for git repositories it always selected HEAD
2016-02-15 18:22:01 <clandmeter> ah ok
2016-02-15 18:23:12 <clandmeter> i think we need to add a switch to make it keep the .git directory.
2016-02-15 18:24:15 <clandmeter> many projects who dont properly do versioning, fetch info from git to provide some kind of version number.
2016-02-15 18:26:03 <clandmeter> this is for both git and svn, but git doesnt return an error cause it takes the parent (aports) git repo
2016-02-15 18:43:21 <nmeum> I think there is a lot of room for improvement of the snapshot function: besides keeping .git it would also be nice to be able to specify multiple git/svn urls
2016-02-15 20:32:47 <leo-unglaub> hey :)
2016-02-15 20:32:54 <leo-unglaub> is someone of you a python pro?
2016-02-15 20:32:59 <leo-unglaub> i am not that skilled in that language
2016-02-15 20:44:51 <yth> leo-unglaub: what's the question?
2016-02-15 20:46:31 <leo-unglaub> yth: https://github.com/freqmod/atemcontrol/blob/master/atem.py#L34
2016-02-15 20:46:43 <leo-unglaub> that should be an udp package
2016-02-15 20:46:52 <leo-unglaub> but its ... i have no idea why he generates a randum uid
2016-02-15 20:47:06 <leo-unglaub> the protokol is closed, but reverse engineered here: http://atemuser.com/forums/atem-vision-mixers/developers/controlling-atem#comment-251
2016-02-15 20:58:09 <nmeum> faffolter: what about your changes in http://git.alpinelinux.org/cgit/user/fab/aports/ can those be merged into the 'official' aports repo?
2016-02-15 21:06:04 <faffolter> nmeum: sure. i usually need to ask a couple of time here till my updates are merged.
2016-02-15 21:06:15 <faffolter> i'm too lazy to ask everyday so they are sitting around for a while
2016-02-15 21:07:52 <nmeum> faffolter: you don't have push access to aports.git?
2016-02-15 21:09:22 <faffolter> nmeum: nope
2016-02-15 21:11:38 <ammunta> 03:52 < coredumb> -22 ? where are you leaving ? :O
2016-02-15 21:11:49 <ammunta> nw mass, US, at 4 am in the morning
2016-02-15 21:43:31 <nmeum> faffolter: Your repo wasn't rebased against master, I cherry picked your commits
2016-02-16 06:38:44 <coredumb> ammunta: quite cold :P
2016-02-16 07:27:23 <fcolista> any objection to this?
2016-02-16 07:27:24 <fcolista> http://sprunge.us/adiT
2016-02-16 07:27:31 <fcolista> ncopa, ^
2016-02-16 08:22:37 <ammunta> fcolista: at that point, why not just use a heredoc
2016-02-16 08:22:53 <ammunta> also what's with the explicit exit 0
2016-02-16 09:13:31 <ncopa> fcolista: that .initd script is already in aports?
2016-02-16 09:13:42 <fcolista> i've added it
2016-02-16 09:13:52 <ncopa> looks good to me
2016-02-16 09:14:09 <fcolista> looks that nobody so far used hylafax on alpine..
2016-02-16 09:14:15 <ncopa> :)
2016-02-16 09:17:27 <ScrumpyJack> morning
2016-02-16 09:21:29 <clandmeter> ncopa: i though we didnt want those msg's in aports?
2016-02-16 09:21:48 <ncopa> true
2016-02-16 09:22:00 <ncopa> fcolista: i dontn mind of you remove the install message :)
2016-02-16 09:22:16 <clandmeter> if we have to put manual in each package ;-)
2016-02-16 09:22:24 <fcolista> ncopa, clandmeter that's even better..
2016-02-16 09:23:02 <fcolista> i don't see the maintainer around since a lot
2016-02-16 09:23:16 <clandmeter> didnt we already propose some post-install-msg idea?
2016-02-16 09:23:29 <fcolista> clandmeter, it was related to README.alpine iirc
2016-02-16 09:25:15 <fcolista> cat > $pkgdir/usr/share/doc/$pkgname/README.alpine <<EOF
2016-02-16 09:25:17 <fcolista> $MSG
2016-02-16 09:25:19 <fcolista> EOF
2016-02-16 09:25:39 <fcolista> in package() function. Is this still a valid approach?
2016-02-16 09:25:42 <clandmeter> yes, and we could have a switch in setup-alpine, Do we need to tell you what to do? Yes/NO (which would display those msg on install)
2016-02-16 09:25:58 <clandmeter> fcolista: no i dont think thats what we want.
2016-02-16 09:26:09 <clandmeter> we want to prevent a pkg doing that automtically
2016-02-16 09:26:20 <fcolista> clandmeter, i agree.
2016-02-16 09:27:08 <fcolista> for the moment i remove the post-install. Then, when a prototype of how this should work is available, i'll add it
2016-02-16 09:27:23 <fcolista> makes sense?
2016-02-16 09:27:45 <clandmeter> you could include the readme
2016-02-16 09:27:56 <clandmeter> it will not do anything yet, but we could in the future.
2016-02-16 09:28:14 <fcolista> cat > $pkgdir/usr/share/doc/$pkgname/README.alpine <<EOF
2016-02-16 09:28:19 <fcolista> that one you mean ^^^
2016-02-16 09:28:36 <clandmeter> just include the file in aports, and install it in the correct location.
2016-02-16 09:28:42 <fcolista> ok
2016-02-16 09:29:20 <clandmeter> altough i doubht its really that usefull
2016-02-16 09:29:35 <clandmeter> ppl who install such software should know how to make it work.
2016-02-16 09:29:37 <fcolista> ppl who uses hylafax on alpine knows what to do
2016-02-16 09:29:44 <fcolista> exactly :)
2016-02-16 09:29:47 <clandmeter> correct :)
2016-02-16 09:30:05 <clandmeter> only for alpine specifics we could include something like that.
2016-02-16 09:30:10 <fcolista> right
2016-02-16 09:30:21 <fcolista> Also, a README is already installed by default
2016-02-16 09:30:39 <clandmeter> like, this package will delete your home directories (post install)
2016-02-16 09:43:47 <skarnet> "this package will delete your entire / hierarchy". More fun!
2016-02-16 09:45:34 <clandmeter> we should also have pre install warnings for crappy software.
2016-02-16 09:45:51 <clandmeter> we will have to patch 50% of aports :)
2016-02-16 09:51:08 <ncopa> this package will delete your efivars!!!
2016-02-16 09:52:37 <fcolista> :)
2016-02-16 09:53:45 <clandmeter> i didnt know i had them?
2016-02-16 09:55:24 <clandmeter> is that a place to inject malicious code?
2016-02-16 10:08:50 <ncopa> clandmeter: thats where you brick your hardware https://github.com/systemd/systemd/issues/2402
2016-02-16 10:13:39 <fcolista> comments are very interesting in that 3rd
2016-02-16 10:13:49 <fcolista> *thread
2016-02-16 10:24:19 <ncopa> andyshinn: i have an issue with fastly proxies
2016-02-16 10:24:38 <ncopa> if the cache is cold, and package is big, it may time out
2016-02-16 10:24:43 <clandmeter> omg
2016-02-16 10:24:48 <clandmeter> thaat issue is crazy
2016-02-16 10:25:01 <ncopa> andyshinn: (12/75) Upgrading chromium (47.0.2526.106-r0 -> 48.0.2564.109-r0)
2016-02-16 10:25:01 <ncopa> ERROR: chromium-48.0.2564.109-r0: temporary error (try again later)
2016-02-16 10:25:09 <ncopa> (17/75) Upgrading libreoffice-common (5.0.4.2-r0 -> 5.1.0.3-r0)
2016-02-16 10:25:09 <ncopa> ERROR: libreoffice-common-5.1.0.3-r0: temporary error (try again later)
2016-02-16 10:26:05 <ncopa> it seems that proxy does not start send data till the entire file is fetched
2016-02-16 10:37:17 <pluesch_> Hi. I saw that we are using the grsecurity patch from TLD-Linux now as of 4.1.17 (currently in edge). Will we keep using the patch from TLD-Linux or is this just temporary until we catch up with our own patch?
2016-02-16 10:48:08 <fabled> pluesch_, depends on multiple things
2016-02-16 10:48:19 <fabled> his patch is basically same what i had
2016-02-16 10:49:02 <pluesch_> fabled: may I ask how you create those patches in the first place?
2016-02-16 10:49:21 <fabled> manually rebasing and resolving conflicts using git
2016-02-16 10:49:48 <fabled> at times we incorporate the newer grsec features by doing interdiff
2016-02-16 10:50:11 <fabled> or more like git diff between git rebased and newer patch
2016-02-16 10:52:34 <ncopa> buildservers will reboot tomorrow and will be down ~09.00 - 09.30 UTC
2016-02-16 10:52:45 <pluesch_> okay... so if he stops doing it (because TLD doesn't seem to be that active. It gained activity lately but was dead for some time.) you can do it again? If I can, I'm happy to help but probably manually rebasing isn't that easy if you aren't very familiar with the kernel?
2016-02-16 10:54:21 <fabled> pluesch_, we have 3 people who can do it. we took tld only because he did it before us.
2016-02-16 10:55:36 <pluesch_> k. thank you for explaining :)
2016-02-16 11:27:05 <xsteadfastx> i sent my first aport to the alpine-devel list. i followed the wiki page about creating packages. what are the next steps? do i get some informations if the patch got accepted? do i have to be a member of the devel mailinglist first? cause my patch doesnt seems to be in the archive
2016-02-16 11:29:29 <ScrumpyJack> I'm getting issues with xen
2016-02-16 11:30:26 <ScrumpyJack> running xl create: getting physinfo: permission denied \ failed to free memory for the domain
2016-02-16 11:31:22 <ScrumpyJack> does this ring any bells?  -just updated 3.2 - and I'm in prod without a browser :(
2016-02-16 11:32:25 <fabled> xsteadfastx, we are slightly backlogged, but generally we accept it and push it, or send reply with change requests
2016-02-16 11:32:43 <fabled> you can also follow your patch in http://patchwork.alpinelinux.org/project/aports/list/
2016-02-16 11:33:12 <xsteadfastx> fabled: yeah :) its the first time im submitting something and im pretty excited :) thank you
2016-02-16 11:41:13 <ScrumpyJack> hmm, mismatch xen hypervisor and xen tools
2016-02-16 11:41:27 <ScrumpyJack> let's reboot again
2016-02-16 11:43:59 <ScrumpyJack> hmm, xl info still says 4.4 while apk info says 4.5
2016-02-16 13:04:11 <StarWarsFan> in case you did'nt know: alpine is now available on proxmox:
2016-02-16 13:04:12 <StarWarsFan> https://git.proxmox.com/?p=pve-container.git;a=history;f=src/PVE/LXC/Setup/Alpine.pm;h=e35ea5a773ef775aa08e657a9706c7d1b7a31758;hb=c08ac339582ef0462c67f5caa40be04caf7719c3
2016-02-16 13:04:14 <StarWarsFan> :-)
2016-02-16 13:26:08 <andyshinn> ncopa: I'll check if there are any Varnish options to send data before whole file is cached
2016-02-16 13:46:56 <leo-unglaub> today i get my first raspberry pi :)
2016-02-16 13:47:07 <leo-unglaub> i know that i am late to the party, but i am still happy
2016-02-16 13:56:07 <ScrumpyJack> leo-unglaub: congrats! i'm crazy about them
2016-02-16 13:56:19 <ScrumpyJack> and Arduino
2016-02-16 13:56:33 <ScrumpyJack> my first beagleboardblack is on it's way this week
2016-02-16 13:57:13 <ScrumpyJack> I'm currently teaching myself electronics (attempting, anyway)
2016-02-16 13:57:58 <ScrumpyJack> leo-unglaub: which one did you get?
2016-02-16 13:59:20 <vkris> ncopa: will there be interest in bringing back suhosin, seems to compile for php-5.6.16 as module (suhosin.so)
2016-02-16 13:59:25 <vkris> with minor patch
2016-02-16 13:59:29 <vkris> ?
2016-02-16 14:00:02 <ncopa> is it maintained?
2016-02-16 14:00:23 <vkris> https://github.com/stefanesser/suhosin seems so
2016-02-16 14:00:30 <ncopa> https://suhosin.org/stories/download.html
2016-02-16 14:00:37 <ncopa> i see no 5.6
2016-02-16 14:00:40 <ncopa> nor 7.0
2016-02-16 14:00:56 <vkris> http://suhosin.org/stories/install.html
2016-02-16 14:01:11 <vkris> Compatibility: The current Suhosin-Extension has been tested with PHP 5.4, 5.5 and 5.6
2016-02-16 14:01:33 <vkris> for Php v7.0 its still in testing...
2016-02-16 14:01:44 <ncopa> oh
2016-02-16 14:01:53 <vkris> and I think would be better there till AL v3.5
2016-02-16 14:01:55 <ncopa> it can be used as an extension only too
2016-02-16 14:02:14 <vkris> yes, thats nice, so if enable if needed
2016-02-16 14:02:55 <ncopa> Note: The Suhosin-Patch is compatible only up to PHP version 5.3.9.
2016-02-16 14:03:15 <vkris> yes, read that, we are not planning to backport
2016-02-16 14:03:18 <ncopa> i suppose we could so a php-suhosin package
2016-02-16 14:03:56 <vkris> should I send APKBUILD+patch ?
2016-02-16 14:04:20 <ncopa> yes please
2016-02-16 14:04:22 <vkris> but would put you as maintainer ;)
2016-02-16 14:04:27 <vkris> ok
2016-02-16 14:17:24 <leo-unglaub> ScrumpyJack: the rpi 2 b
2016-02-16 14:18:17 <ScrumpyJack> what are you going to do with it? that's always interesting
2016-02-16 14:18:38 <leo-unglaub> ScrumpyJack: for the red cross a tally light system for live streaming
2016-02-16 14:18:48 <leo-unglaub> hopefully, if i get alpine to run on it *g*
2016-02-16 14:19:15 <ScrumpyJack>  a tally light system?
2016-02-16 14:19:20 <leo-unglaub> ncopa: vkris: i love php and do a lot of work with it but i would not recommend using suhosin
2016-02-16 14:19:41 <leo-unglaub> it causes all sorts of wired random errors
2016-02-16 14:20:35 <skarnet> still better than wifi random errors
2016-02-16 14:20:39 <skarnet> <g>
2016-02-16 14:20:51 <leo-unglaub> ScrumpyJack: https://en.wikipedia.org/wiki/Tally_light
2016-02-16 14:23:10 <leo-unglaub> ScrumpyJack: if you get your beagleboardblack, can you please tell me how you like it and if you would prefer it over a raspberry
2016-02-16 14:23:27 <vkris> leo-unglaub: its now an extention, so enable if needed
2016-02-16 14:24:06 <vkris> extension*
2016-02-16 14:24:40 <leo-unglaub> vkris: yeah, i have read. thats much better than the core hacks they used before
2016-02-16 15:11:55 <xsteadfastx> ok. i found a error by myself for the patch i submitted. i fixed it in my cloned repo. what to do now? just submit a new one? with $pkgrel+1? the first one is not merged yet in the official repo yet
2016-02-16 15:19:57 <xsteadfastx> feel a little dumb with my first packaging tries ;-)
2016-02-16 15:26:41 <skarnet> it only hurts the first time
2016-02-16 15:26:52 <skarnet> yes, make another one with $pkgrel++
2016-02-16 15:27:50 <skarnet> and get used to the feeling: you can triple-check, quadruple-check your code, you will *always* find a dumb error *right after* you send it
2016-02-16 15:29:24 <xsteadfastx> :) ok... i will do that
2016-02-16 15:35:26 <vkris> ncopa: http://tpaste.us/G5M9 <- testing/php-suhosin new aport
2016-02-16 15:56:25 <coredumb> skarnet: +1
2016-02-16 16:03:20 <ncopa> vkris: pished
2016-02-16 16:03:22 <ncopa> pushed*
2016-02-16 16:14:18 <ScrumpyJack> could someone have a look at patch 1599? just want to make sure the checksums are not b0rked again
2016-02-16 16:42:29 <ncopa> %1599
2016-02-16 16:45:14 <ncopa> ScrumpyJack: pushed
2016-02-16 16:45:15 <ncopa> thanks
2016-02-16 16:50:29 <ScrumpyJack> thanks ncopa
2016-02-16 17:27:27 <ammunta> oh huh when did ag get moved to main
2016-02-16 17:28:22 <ammunta> appreciated, though
2016-02-16 20:20:06 <ammunta> is nginx-common a rename of nginx-initscripts?
2016-02-16 20:20:15 <ammunta> there seems to be a problem with that
2016-02-16 21:59:32 <_fps__> is there any replacement for netlink headers in Alpine (since they aren't available)?
2016-02-17 02:40:10 <ammunta> __fps__: huh? what netlink headers are provided by the libc?
2016-02-17 06:29:59 <vitronic> Greetings, any advice to set the sound in my box?
2016-02-17 07:56:02 <ncopa> __fps__: netlink is a kernel feature, linux specific
2016-02-17 07:56:08 <ncopa> so its in linux-headers
2016-02-17 08:33:02 <fabled> ncopa, i'm trying to do my custom initramfs; and i kinda miss the feature that update-kernel / mkinitfs could get extra features from local directory
2016-02-17 08:34:22 <ncopa> ok?
2016-02-17 08:34:38 <fcolista> ncopa, lua-feedparser needs lua-expat. Would that be enough? http://sprunge.us/fJZj
2016-02-17 08:34:56 <ncopa> something like mkinitfs --extrea-features-from-local-dir?
2016-02-17 08:35:22 <fabled> yeah
2016-02-17 08:35:26 <ncopa> fcolista: i doubt
2016-02-17 08:35:33 <fabled> or that it takes up $PWD/features.d into account or similar
2016-02-17 08:35:50 <fabled> or $MKINITFS_LOCAL_FEATURES_DIR
2016-02-17 08:36:18 <ncopa> do you want it to only look there?
2016-02-17 08:36:21 <ncopa> or in addition
2016-02-17 08:36:42 <ncopa> i'm thinking ${MKINITFS_FEATURES_PATH}
2016-02-17 08:37:05 <ncopa> with a : separated list
2016-02-17 08:37:37 <ncopa> i'm rebaing the llvm/clang patches
2016-02-17 08:37:48 <fabled> yeah, something like that would be good
2016-02-17 08:38:04 <fabled> i'd also like to introduce shell snippets that can be merged in to iniramfs-init
2016-02-17 08:38:09 <fabled> under features.d
2016-02-17 08:39:58 <ncopa> tbh, i'd like to have the boot-from-tmpfs feature to be a shell snippet or plugin or hook or what we call it
2016-02-17 08:41:45 <ncopa> initramfs' job is to find and prepare/mount the rootfs and then switch to it
2016-02-17 08:46:48 <fabled> true
2016-02-17 09:06:57 <prt> hi
2016-02-17 09:08:37 <ncopa> we will reboot the builders today
2016-02-17 09:13:20 <ncopa> that is, the x86 and x86_64 builders
2016-02-17 09:18:17 <clandmeter> reason?
2016-02-17 09:24:35 <ncopa> clandmeter: maintenance
2016-02-17 09:24:49 <ncopa> and i update them to 3.3 while at it
2016-02-17 09:25:18 <ncopa> shutting it down now
2016-02-17 09:25:49 <ncopa> its going down...
2016-02-17 16:49:49 <ncopa> i tried to upgrade a varnish server to v3.3 but issue #4938 bites me :/
2016-02-17 21:51:51 <__fps__> ammunta: i don't know about the answer that's why I am simply posing a question. :)
2016-02-17 21:52:17 <__fps__> ncopa: i am building CoreFX (pinged you on GitHub)
2016-02-17 21:53:00 <__fps__> if that is ok, can i submit a PR against aports to further the work? :)
2016-02-17 22:21:39 <ammunta> __fps__: I mean something like which headers you discover you needed, which you didn't have
2016-02-17 22:21:53 <ammunta> most of the netlink stuff should be on the kernel, not the libc
2016-02-17 22:24:39 <__fps__> ammunta: i was in hunt for linux/netlink.h header
2016-02-17 22:25:20 <__fps__> < this guy is barely acquainted with Alpine, just started hacking into it recently
2016-02-17 22:25:55 <__fps__> here is the related discussion: https://github.com/dotnet/coreclr/pull/2262#issuecomment-184873230
2016-02-17 22:31:12 <andyshinn> ncopa: i enabled Streaming Miss on the new CDN: https://docs.fastly.com/guides/performance-tuning/improving-caching-performance-with-large-files
2016-02-17 22:35:34 <ammunta> __fps__: does install linux-headers solve that problem
2016-02-17 22:37:18 <__fps__> ammunta: many thanks! i will try it out. i don't have my Mac with me where i have all kinds of VMs installed to compile stuff. :)
2016-02-17 22:37:38 <__fps__> if someone else wants to beat me to it, please be my guest :D
2016-02-17 22:39:41 <ammunta> I mean, looks like ncopa suggested it earlier ...
2016-02-17 22:42:40 <__fps__> ah just saw the other message by ncopa above, i haven't got a chance to test it.
2016-02-17 22:47:26 <ammunta> also hm the __ is really throwing off my ability to read
2016-02-17 22:47:41 <ammunta> I was wondering why you were quoting everything but no that's just my brain misinterpreting
2016-02-17 22:48:43 <__fps__> ammunta: you mean those underscores in my nick?
2016-02-18 12:11:41 <coredumb> gcc  -g -O2   -o xte xte.o debug.o   -lXtst -lX11 -lm
2016-02-18 12:11:43 <coredumb> /usr/lib/gcc/x86_64-alpine-linux-musl/5.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: xte.o: undefined reference to symbol 'XOpenDevice'
2016-02-18 12:11:45 <coredumb> /usr/lib/libXi.so.6: error adding symbols: DSO missing from command line
2016-02-18 12:11:48 <coredumb> does that raise anything to someone ?
2016-02-18 12:43:16 <vkris> ncopa: http://tpaste.us/2bZe <- testing/php-suhosin: add re2c to makedepends
2016-02-18 12:46:29 <vkris> upstream pkg comes with suhosin.ini (42 kb~), should I include that ?
2016-02-18 13:22:18 <ncopa> sounds much
2016-02-18 13:22:27 <ncopa> a useable default config would be nice though
2016-02-18 14:31:01 <vkris> already set defaults seems ok, I would leave it for now and wait see what appears in other distros
2016-02-18 14:31:53 <vkris> arch has not even pkg'ed it
2016-02-18 14:40:13 <vkris> and I found this, https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-php/suhosin/files/suhosin-0.9.38-libcrypt.patch
2016-02-18 14:45:14 <coredumb> is it interesting to patch php with the suhosin patch or is the extention sufficient ?
2016-02-18 14:46:12 <vkris> the developer seems has removed all support for php<5.4
2016-02-18 14:46:29 <vkris> so for now only extension
2016-02-18 14:46:58 <coredumb> ok
2016-02-18 14:47:19 <coredumb> seeing the feature list is there any reasons that this hasn't been pushed to php core ?
2016-02-18 16:07:51 <vkris> seems ok, managed to bring 'make test'  to http://tpaste.us/3gVr
2016-02-18 16:08:48 <vkris> would mail to developer about BLOWFISH test
2016-02-18 19:30:11 <vkris> what happened to older bugs reports, eg http://bugs.alpinelinux.org/issues/3751
2016-02-18 22:01:11 <przemoc> zfs on linux had many bug fixes since 0.6.5 (in AL), they're at 0.6.5.4 now.  e.g. not honoring xattr=sa is problematic, because when xattrs are represented as files, there is a storage leakage, which is unresolved for a few years already.
2016-02-18 22:01:19 <przemoc> https://github.com/zfsonlinux/zfs/releases/tag/zfs-0.6.5.1
2016-02-18 22:01:23 <przemoc> https://github.com/zfsonlinux/zfs/releases/tag/zfs-0.6.5.2
2016-02-18 22:01:27 <przemoc> https://github.com/zfsonlinux/zfs/releases/tag/zfs-0.6.5.3
2016-02-18 22:01:31 <przemoc> https://github.com/zfsonlinux/zfs/releases/tag/zfs-0.6.5.4
2016-02-18 22:02:27 <przemoc> clandmeter: ncopa: ^
2016-02-18 22:05:28 <przemoc> I know it doesn't have any maintainer right now, but it would be good to have something more stable in AL (0.6.5.1 had even bugfix for data corruption - https://github.com/zfsonlinux/zfs/pull/3798), hopefully in upcoming 3.3.2 too.
2016-02-18 22:08:22 <clandmeter> przemoc: are all musl fixes already upstream?
2016-02-18 22:08:39 <przemoc> sorry, I don't know that
2016-02-18 22:08:42 <clandmeter> https://github.com/zfsonlinux/zfs/pull/2699
2016-02-18 22:15:03 <przemoc> they mostly want more descriptive commits, and I can relate to such attitude
2016-02-18 22:15:44 <przemoc> some are no longer needed, e.g. RLIM64_INFINITY is already defined in musl
2016-02-18 22:16:01 <przemoc> oh, musl had new release few days ago
2016-02-18 22:18:29 <przemoc> I relooked at ZFS, because Ubuntu is going to have it in 16.04
2016-02-18 22:25:48 <przemoc> clandmeter: you should fix url of Tvheadend to https://tvheadend.org/
2016-02-18 22:26:49 <clandmeter> i should go to bed
2016-02-18 22:52:06 <yth> what TZ would that be?
2016-02-19 01:14:06 <ammunta> wait what did ubuntu do about the licensing issues
2016-02-19 07:18:09 <coredumb> ammunta: they decided there was no issue and that as they decided so it's useless to talk about it
2016-02-19 07:18:43 <coredumb> but they're not so wrong in the fact there's no licensing issue providing the ZFS module
2016-02-19 07:19:24 <coredumb> there's a license issue if you patch the kernel to contain the zfs code - be it compiled inside or as module
2016-02-19 07:19:36 <ammunta> wait, how are they distributing it then
2016-02-19 07:19:49 <coredumb> as a module
2016-02-19 07:20:16 <coredumb> nothing against distributing a module - even proprietary see nvidia - linked to the kernel
2016-02-19 07:20:32 <coredumb> isn't Alpine distributing zfs module as well ?
2016-02-19 07:22:15 <ammunta> I'll be honest I never actually paid much attention to it and only had the inkling that there was something about the zfs license having its own similar restrictions being gpl-incompat or something going around a while ago
2016-02-19 07:22:19 <ammunta> I wouldn't know
2016-02-19 07:23:03 <coredumb> it's incompatible in the sense you can't merge the code
2016-02-19 07:23:23 <coredumb> but nothing against building one using the other's API
2016-02-19 09:11:05 <pluesch_> Hi. I've read the grsecurity patch from tld-linux for a bit. Does anyone know why the patch includes rewrites of "logo_linux_clut224.ppm" which were done in upstream more than a year ago? It seems to be bloated, but maybe there is a reason I don't see yet.
2016-02-19 09:13:32 <fabled> pluesch_, i think it's the change to replace standard logo to grsec logo
2016-02-19 09:13:47 <fabled> i deleted that change in our grsec patch. since we don't use the logo anyway.
2016-02-19 09:36:24 <pluesch_> oh. I see.
2016-02-19 09:46:03 <pluesch_> yeah. just looked at it again. it's definitly the grsec logo
2016-02-19 13:40:34 <fish_> hi
2016-02-19 13:44:21 <fish_> is there any way to create a armhf root filesystem on a x86 machine? if I do apk add --root foo/ --initdb --arch=armhf ..., the post-install scripts are failing
2016-02-19 13:53:29 <fabled> fish_, depending on things you could just not run the post-install scripts; or setup user mode qemu
2016-02-19 13:56:21 <fish_> fabled: I already started trying out qemu but not sure where to start. if I run apk under qemu I already need a alpine rootfs (or statically linked apk)
2016-02-19 13:58:55 <fish_> ah, found apk-tools-static :)
2016-02-19 14:04:54 <fabled> fish_, you could also just use binfmt_misc to enable transparent emulation
2016-02-19 14:05:36 <fish_> fabled: oh, intreesting.. didn't know that this exists
2016-02-19 14:05:48 <fabled> though, that might need static qemu-user
2016-02-19 14:08:56 <fish_> and I guess there is no static qemu-user package in alpine?
2016-02-19 14:10:49 <fabled> i had it done; but i think it was never pushed out due to few qemu issues, and ending up not using it to build stuff
2016-02-19 14:16:54 <fish_> well the reason I'm doing all this is because I want a raspberry pi alpine image and people seem to do this by running apk on their rpi and creating snapshots from the resulting rootfs
2016-02-19 14:17:01 <fish_> which is.. less ideal
2016-02-19 14:20:55 <fish_> guess binfmt is also required, hrm
2016-02-19 14:21:02 <fish_> eh missing
2016-02-19 14:21:46 <fabled> binfmt is kernel feature and should be there
2016-02-19 14:22:05 <fabled> but i build my rpi image on real arm hw (wandboard)
2016-02-19 14:22:14 <fabled> and yeah. it would be faster on x86_64.
2016-02-19 14:22:35 <fish_> hrm but there is at least on debian a package binfmt-support
2016-02-19 14:23:14 <fabled> isn't binfmt-support just some debian wrapper scripts to load the specifications to /proc
2016-02-19 14:24:22 <fish_> yes, maybe - I didn't look into. will trust you on this :) still, I'd need qemu-user-static for making this work
2016-02-19 15:09:34 <vkris> could some re-check the crypt related patched in main/php/*
2016-02-19 15:10:15 <vkris> for testing, http://tpaste.us/A8Jy <- script to run
2016-02-19 15:10:15 <vkris> http://tpaste.us/2rxz <- value to expect
2016-02-19 15:10:43 <vkris> seems to give ok result on knoppix
2016-02-19 15:11:08 <vkris> if a bug, I can add it to bugs.a.o
2016-02-19 16:00:12 <BitL0G1c> the bitcoin_RC4 patch can be cancelled - 0.12.0 has been released
2016-02-19 16:01:17 <BitL0G1c> *RC5
2016-02-19 18:05:13 <[nl]jouke> Any chance the ARMv5 patches sent to the list will be accepted?
2016-02-19 18:05:31 <[nl]jouke> Better yet: any chance of ARMv5 (armel) becoming a supported arch?
2016-02-19 18:29:14 <[nl]jouke> I'll ask again later :-P. Bye!
2016-02-19 19:46:00 <mpchlets> https://pkgs.alpinelinux.org/package/main/x86_64/nginx shows 1.9.11-r0 but when installed I get 1.8.1-r0 - what am I missing?
2016-02-19 19:49:25 <mpchlets> Does the site only show edge? and I am 3.3?
2016-02-19 19:56:15 <tdtrask> mpchlets: yes, exactly
2016-02-19 19:59:20 <mpchlets> yeah - thanks, just figured that out - anyway to just see what is in a version other than commandline?
2016-02-19 21:19:10 <tdtrask> mpchlets: nope. the index purposely does not contain the package contents to keep the size down.
2016-02-19 21:19:34 <tdtrask> so, you either install the package and use 'apk info' or use pkgs.alpinelinux.org (for edge)
2016-02-19 21:45:31 <clandmeter> in the future it will also contain latest-stable
2016-02-19 21:45:42 <clandmeter> just didnt have the time to finish it.
2016-02-19 22:20:14 <__fps__> is there any online man pages resource available for alpine linux?
2016-02-19 22:39:02 <saintdev> I would like to make a boot medium with a squashfs root instead of unpacking apks.
2016-02-19 22:39:32 <saintdev> It looks like initramfs-init is the place to handle this, is that correct?
2016-02-19 22:45:18 <__fps__> got it:  fossies.org/dox
2016-02-20 04:01:27 <ammunta> #4905
2016-02-20 11:36:32 <mosez> can somebody tell me why mono have been droped for 64bit? http://git.alpinelinux.org/cgit/aports/commit/?id=ba7a17db0f1e4b89edf538fa1e11f055a9b991dd
2016-02-20 11:36:50 <mosez> clandmeter: why? =)
2016-02-20 11:37:56 <mosez> we were using it at https://github.com/drone-plugins/drone-nuget/blob/master/Dockerfile totally fine
2016-02-20 11:38:38 <mosez> now we have to reimplement this nuget crap commands manually to be able to use that plugin :(
2016-02-20 11:51:12 <nmeum> mosez: http://bugs.alpinelinux.org/issues/5115#note-1
2016-02-20 15:10:21 <bfritz> [nl]jouke: Guessing armv5 will never be an officially supported platform, but I would love to see it.
2016-02-20 15:11:01 <bfritz> On my someday-maybe list is to convert my Seagate Dockstar router, currently running Arch, to Alpine.
2016-02-20 19:36:23 <mitchty> partially success, i built a stage 2 arm ghc compiler for the first time in months, only a 400 line diff of hacky patches :) now lets see if it does anything productive
2016-02-20 19:37:47 <mitchty> given it takes about 4.5 hours to compile ghc from x86_64 to arm, if this works anyone want to guess at the compile time on arm
2016-02-20 19:43:58 <mitchty> well so anyway, for the x86_64 portion of ghc, i set it up to do ghc-bootstrap which takes the cross compiled install off of debian (through docker cause why not), then build ghc from there
2016-02-20 19:44:25 <mitchty> i also hacked in support for 7.10.3 to use llvm 3.6, nothing seems to fail
2016-02-20 19:45:05 <mitchty> and also build llvm for ghc itself statically for opt/llc in preparation for llvm 3.7 to break ghc+llvm working
2016-02-20 19:46:16 <mitchty> also have the ghc-bootstrap setup to do the snapshot() business, so that you run the docker stuff to generate the make install DESTDIR= from the debian docker image that ghc-bootstrap will use to build that apk
2016-02-20 19:46:35 <mitchty> if that sounds OK for an initial port to evolve off of I can resubmit my patches
2016-02-20 19:47:17 <mitchty> been working/using this ghc port since june of last year so I think its functional
2016-02-20 19:48:07 <mitchty> anyway, curious on what steps are needed past all that, at the moment i'm more focused on the arm stuff so i can have an exuse to get alpine running on my hummingboard gate
2016-02-20 20:52:07 <Lemming2> hi, can someone help me with this error? i'm new to build apks and try to build the latest stable of burp: https://0.jmt.gr/?d9eb60240f7924e0#VyXp9hDDg11Ei1elA8WoVvcXZVs8H6HxqEcnLZU+B8Y=
2016-02-20 21:41:20 <Lemming2> https://0.jmt.gr/?71cc0c275612e2e6#Tcggx7StIv/sDXD7iHUdh+vPv1urf8TmbmtzzZAbZWI= with this modification it works...
2016-02-20 21:59:06 <ammunta> Lemming2: it's a gettext header
2016-02-20 21:59:37 <ammunta> what do you mean with that modification
2016-02-20 22:02:09 <ammunta> mitchty: nice!
2016-02-20 22:02:50 <Lemming2> without these two defines it builds fine
2016-02-20 22:04:24 <ammunta> hm, so docker actually does build on arm, it's just that there's not many images for it, right
2016-02-20 22:12:01 <__fps__> bpye: how is it going?
2016-02-20 22:13:21 <__fps__> any luck with coreclr?
2016-02-20 22:14:02 <__fps__> 4/6 corefx patches are merged upstream, two PRs are awaiting approval
2016-02-20 22:14:26 <__fps__> meanwhile, I am trying to build lldb build https://github.com/llvm-mirror/lldb on alpine, which requires llvm source
2016-02-20 22:14:57 <__fps__> i guess i need to provide the actual source of llvm36 which my alpine box is running..
2016-02-21 00:21:46 <pavlix> blueness: hi :)
2016-02-21 00:22:01 <blueness> pavlix: hi
2016-02-21 00:22:03 <pavlix> what a surprise
2016-02-21 00:22:07 <blueness> how so?
2016-02-21 00:23:38 <blueness> pavlix: why a surprise?
2016-02-21 00:24:11 <pavlix> I didn't expect you in this channel
2016-02-21 00:25:36 <pavlix> just installed alpine for a test and I'm trying to get X working
2016-02-21 00:25:40 <blueness> pavlix: i work on musl in gentoo and hardened kernel and toolchain, why wouldn’t i be here?
2016-02-21 00:26:27 <pavlix> never mind... at least not regarding my surprise...
2016-02-21 00:26:51 <pavlix> are you also doing something with alpine itself?
2016-02-21 00:57:54 <mitchty> well, this is the furthest i've gotten, next up is building itself /tmp/hi: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-armhf.so.1, not stripped
2016-02-21 00:58:17 <mitchty> assuming it works obviously
2016-02-21 02:00:32 <mitchty> is there a way to get a local file:// uri to work in source or is it http only
2016-02-21 05:52:33 <ammunta> mitchty: in source?
2016-02-21 07:39:31 <mitchty> ammunta: sorry in a source line in an APKBUILD file
2016-02-21 08:40:21 <mosez> nmeum: thanks
2016-02-21 14:21:21 <fish_> how can I debug post-inst scripts? even if i run with -vv it only says:
2016-02-21 14:21:23 <fish_> Executing busybox-initscripts-2.3-r1.post-install
2016-02-21 14:21:23 <fish_> ERROR: busybox-initscripts-2.3-r1.post-install: script exited with error 1
2016-02-21 14:42:02 <skarnet> edit the script, change the first line to #!/bin/sh -x
2016-02-21 14:42:03 <skarnet> I guess
2016-02-21 14:42:40 <skarnet> hmmm, it's post-install, maybe you can't easily edit it
2016-02-21 14:43:28 <skarnet> I'd be violent and just strace the apk invocation, but that's just me
2016-02-21 14:44:05 <skarnet> maybe apk allows you to specify the installation steps? in which case you could unpack first, then edit the post-install script, then run it
2016-02-21 14:48:16 <fish_> hoped there is some other debug setting which at least shows me the output of the scripts (assuming they print something when running into an error)
2016-02-21 15:05:09 <fish_> another question: should the armhf binaries work on both raspberry pi 2 and A/B/B+?
2016-02-21 15:08:31 <skarnet> afaict Pi 1 is armv6 and Pi 2 is armv7
2016-02-21 15:08:44 <skarnet> check (with readelf -a) what version the binaries are compiled for
2016-02-21 15:08:58 <skarnet> if it's armv7a, it probably won't work on a Pi 1
2016-02-21 15:13:14 <fish_> it's "ARM", "Version5 EABI" so I assume it's armv5?
2016-02-21 15:16:11 <skarnet> I think so, is that what's printed at the end of readelf -a?
2016-02-21 15:17:03 <fish_> skarnet: yes, in the ELF Header
2016-02-21 15:17:26 <fish_> https://gist.github.com/discordianfish/fd13d8f3f9e074a58c22
2016-02-21 15:19:41 <skarnet> you want what's at the end of the readelf -a output
2016-02-21 15:19:50 <skarnet> the Tag_CPU_arch
2016-02-21 15:21:22 <skarnet> also the Tag_FP_arch, if any
2016-02-21 15:22:18 <fish_>   Tag_CPU_arch: v6KZ
2016-02-21 15:22:20 <fish_> hrm....
2016-02-21 15:22:43 <fish_> the raspbian binaries have Tag_CPU_arch: v6
2016-02-21 15:23:18 <skarnet> then it should work on both
2016-02-21 15:23:27 <skarnet> if you have no Tag_FP_arch, then it's soft-float
2016-02-21 15:24:24 <skarnet> (apparently the RPi has no fpu so it's good XD)
2016-02-21 15:24:40 <fish_> v6KZ should work? what's the "KZ" part?
2016-02-21 15:24:49 <skarnet> I have no idea :P
2016-02-21 15:24:55 <skarnet> try it, tell us if it works!
2016-02-21 15:25:07 <fish_> Tag_FP_arch: VFPv2 <- hm?
2016-02-21 15:25:17 <fish_> well, it doesn't work on my pi 1 :)
2016-02-21 15:25:23 <skarnet> aha
2016-02-21 15:25:29 <skarnet> hard-float then
2016-02-21 15:25:43 <skarnet> armhf is supposed to mean arm with hard-float :P
2016-02-21 15:26:16 <fish_> i've copied over the busybox binary from alpine and the libc.musl-armhf.so.1 but when starting I get ./busybox: No such file or directory
2016-02-21 15:26:37 <skarnet> you mean /lib/ld-musl-armhf.so.1 ?
2016-02-21 15:26:47 <skarnet> you need the link AND the libc.so
2016-02-21 15:27:08 <fish_> raspberrypi:~# ldd busybox  libc.musl-armhf.so.1 => /lib/libc.musl-armhf.so.1 (0xb6d73000)
2016-02-21 15:27:16 <fish_> so yes, that's there
2016-02-21 15:27:23 <skarnet> no, that's not the right link
2016-02-21 15:28:07 <fish_> woops
2016-02-21 15:29:46 <fish_> maybe one of the failing post-inst steps should create the symlinks but didn't
2016-02-21 15:32:36 <fish_> ah nope, actually it works :) nice
2016-02-21 15:32:59 <fish_> still doesn't explain why that base image isn't working with resin.io, but that's another question
2016-02-21 17:03:09 <Moe> hey everyone
2016-02-21 17:03:52 <Moe> Short question: I have a package built "somewhere else", I have a APKINDEX and a public key .. how would one go about and verify the packages (the .apk files) on the command line, given that they're properly signed
2016-02-21 21:57:36 <ammunta> Moe: could use apk verify?
2016-02-21 21:58:25 <ammunta> I don't believe packages are verififed wrt the APKINDEX (that doesn't seem like the right thing to do), they're signed
2016-02-21 22:00:01 <ammunta> I don't recall whether there's a way to pass in a single key but --keys-dir will specify a dir
2016-02-21 22:01:59 <ammunta> mitchty: hm can't you just specify the path?
2016-02-21 22:20:04 <mitchty> ammunta: i tried it but didn't work, no big deal just threw it up on a webserver
2016-02-21 22:20:53 <mitchty> i don't know if this is right but for my cross compiler stuff i'm using --with-arch=armv6 --with-float=hard --with-fpu=vf
2016-02-21 22:22:01 <mitchty> last should be vfp sorry
2016-02-21 22:27:01 <mitchty> i don't have a normal rpi to validate that against
2016-02-21 22:55:02 <ammunta> hm scaleway is armhf, right, there's also that
2016-02-21 22:55:08 <ammunta> do they still have their 30min demo up
2016-02-21 23:08:17 <mitchty> actually i'm using the scaleway stuff to test my arm build
2016-02-21 23:08:32 <mitchty> its running my webserver too, half to convince me to get an arm port up quicker
2016-02-21 23:08:55 <mitchty> odd thing about scaleway is no neon support
2016-02-21 23:09:54 <mitchty> https://gist.github.com/mitchty/e703e570ea9f5c153a49
2016-02-21 23:10:49 <mitchty> its also running my quassel irc bouncer i'm using :)
2016-02-22 10:25:39 <fish_> hrm how do I get the apk keys in a secure manner when using apk.static to bootstrap a new alpine rootfs?
2016-02-22 10:27:13 <ncopa> fish_:  https://github.com/lxc/lxc/blob/master/templates/lxc-alpine.in#L84
2016-02-22 10:31:28 <fish_> ncopa: thanks! but not very convinient way..
2016-02-22 10:33:07 <ncopa> oh. you asked how to get the keys. not how to verify apk.static
2016-02-22 11:47:10 <fish_> ncopa: yeah.. but good point, I need to verify apk.static as well :)
2016-02-22 12:07:33 <fish_> well, I'll just copy over the pub keys to me repo from my existing images. guess that should be fine
2016-02-22 12:31:23 <fish_> so alpine armhf is ARM5, which works on raspberry pi 1 and 2 which is great. but does this come at a significant performance penalty?
2016-02-22 12:32:59 <skarnet> probably not
2016-02-22 12:33:51 <skarnet> it's the equivalent of running i486 binaries on a i686
2016-02-22 12:34:25 <skarnet> it may be a tad slower because you're not using the latest and greatest instructions, but really nothing noticeable except in very specific cases
2016-02-22 12:34:51 <fish_> yes that's what I would expected at well, though maybe someone knows more specifics
2016-02-22 12:34:53 <fabled> fish_, armhf is armv6+ using hard-float
2016-02-22 12:35:21 <fish_> fabled: but according to readelf and file, the alpine armhf binaries are "ARM5"
2016-02-22 12:35:30 <fabled> we might do armv7 in thumb2 later on
2016-02-22 12:36:00 <fabled> fish_, the gcc is configured with arch=armv6zk fpu=vfp float=hard
2016-02-22 12:36:08 <fabled> i'm pretty sure they don't run on armv5
2016-02-22 12:36:13 <fish_> and I got 'cross building' of alpine armhf images on x86 working :)
2016-02-22 12:36:38 <fabled> cool
2016-02-22 12:36:43 <skarnet> fish_: the only relevant things are what's at the end of readelf -a, and it requires careful reading because tags are often confusing
2016-02-22 12:36:56 <fish_> yeah.. it's really confusing :)
2016-02-22 12:37:16 <skarnet> you may see ARM5 and then "Version: 6" or something on the next line XD
2016-02-22 12:38:25 <fish_> https://github.com/discordianfish/alpine-arm-docker <- in case you're curious. I'm using this as my resin.io base images which is so much nicer experience than the default debian images :)
2016-02-22 12:53:21 <oneinsect> hello friends
2016-02-22 12:53:45 <oneinsect> can someone tell me how do i find on what kernel version is current alpine raspberry pi based on?
2016-02-22 12:54:37 <oneinsect> i am trying to install .ko modules but they say disagress about version of symbol module_layout
2016-02-22 12:54:48 <oneinsect> they compile successfully
2016-02-22 12:55:23 <oneinsect> RPI2 using linux-rpi-dev-4.1.15
2016-02-22 12:55:30 <oneinsect> -r1.apk package
2016-02-22 13:10:03 <fabled> oneinsect, 4.1.17 on edge, 4.1.15 probably on latest release
2016-02-22 13:11:43 <oneinsect> well fabled: things like v7 831
2016-02-22 13:11:46 <oneinsect> how do i know them?
2016-02-22 13:17:13 <fabled> oneinsect, could please elaborate a bit. i didn't quite understand the 'v7 831' part
2016-02-22 13:18:05 <oneinsect> there are driver files in raspberry pi forums like 8192eu-4.1.15-v7-829.tar.gz
2016-02-22 13:18:06 <oneinsect> etc
2016-02-22 13:18:16 <oneinsect> v7-830 etc
2016-02-22 13:19:22 <fabled> they are probably compiled against the stock rpi kernels, and likely would not work with alpine
2016-02-22 13:19:34 <fabled> unless you rebuild them
2016-02-22 13:19:37 <oneinsect> hmmmm
2016-02-22 13:21:12 <LeSpocky> the official raspberry pi kernel tree still contains patches which replace upstream/vanilla wireless drivers
2016-02-22 13:21:30 <oneinsect> https://bugs.alpinelinux.org/issues/5144
2016-02-22 13:22:12 <oneinsect> i still cant get  linux-headers properly installed...so i am download the apk and unzipping it and compiling
2016-02-22 13:22:27 <oneinsect> however the compiled .ko files say
2016-02-22 13:22:39 <oneinsect> disagree about the version of symbol module_layout
2016-02-22 13:22:46 <oneinsect> i am baffled why it would disagree
2016-02-22 13:22:57 <fabled> linux-headers is the generics for building libc + applications
2016-02-22 13:23:01 <oneinsect> even if i used same headers from rpi-dev 4.1.15
2016-02-22 13:23:12 <fabled> you need the specific kernel's -dev to compile modules
2016-02-22 13:23:19 <fabled> you also need same gcc
2016-02-22 13:24:16 <oneinsect> but the gcc compiler is same as compiled kernel version
2016-02-22 13:24:32 <oneinsect> cat /proc/version
2016-02-22 13:24:39 <oneinsect> and gcc --version are the same
2016-02-22 13:24:45 <oneinsect> i wonder what is causing this
2016-02-22 13:25:09 <fabled> is it -rpi2 or -rpi kernel you are compiling against?
2016-02-22 13:25:58 <oneinsect> rpi2 kernel 4.1.15 and i downloaded linux-rpi-dev-4.1.15-r1.apk package
2016-02-22 13:26:12 <oneinsect> gcc version is 5.3.0
2016-02-22 13:26:20 <fabled> that might be a problem. i think we ship -rpi kernel's -dev package only
2016-02-22 13:26:28 <oneinsect> ooooooooo
2016-02-22 13:26:38 <oneinsect> what about rpi2 dev package???
2016-02-22 13:26:50 <oneinsect> i thought both rpi and rpi2 packages are the same?
2016-02-22 13:26:52 <fabled> -rpi and -rpi2 have different configs, which could cause symvers to be different
2016-02-22 13:26:53 <oneinsect> dev*
2016-02-22 13:26:56 <fabled> it's same source
2016-02-22 13:26:58 <oneinsect> darn
2016-02-22 13:27:00 <fabled> but different config
2016-02-22 13:27:09 <oneinsect> right on the point fabled
2016-02-22 13:27:37 <oneinsect> so either i go back to b+ or how do i get the rpi2 Module.symvers file?
2016-02-22 13:27:40 <fabled> ncopa, did we have mechanism to ship -dev for different kernels that come from same source apkbuild ?
2016-02-22 13:28:54 <fabled> would be nice if the same -dev contained the symvers for all flavors, and symlinked the headers
2016-02-22 13:29:04 <oneinsect> indeed fabled,
2016-02-22 13:30:27 <oneinsect> another issue has been i got "makefile:1: *** missing separator. stop."
2016-02-22 13:30:32 <oneinsect> however hard i change the shells
2016-02-22 13:30:42 <oneinsect> edit the make files for tabs and spaces etc
2016-02-22 13:30:47 <oneinsect> in alpine-rpi2
2016-02-22 13:31:50 <oneinsect> it makes no difference
2016-02-22 13:32:54 <fabled> on which makefile?
2016-02-22 13:34:16 <oneinsect> https://github.com/housq/mt7601u/blob/master/Makefile
2016-02-22 13:34:57 <oneinsect> i have changed the pc target of https://github.com/housq/mt7601u/blob/master/Makefile.inc
2016-02-22 13:35:02 <oneinsect> to suit arm
2016-02-22 13:35:49 <oneinsect> basically include the LINUX_SRC from a custom dir and LINUX_SRC_MODULE as a well and CROSS_COMPILE=arm-linux-gnueabihf-
2016-02-22 13:35:55 <oneinsect> and ARM = arm
2016-02-22 13:36:06 <oneinsect> and exported ARCH and CROSS_COMPILE
2016-02-22 13:36:53 <oneinsect> copied (unfortunately) symvers directory from the linux-rpi-dev apk file ...
2016-02-22 13:53:24 <oneinsect> fabled:
2016-02-22 15:02:09 <oneinsect> anyone here
2016-02-22 15:02:11 <oneinsect> still
2016-02-22 20:23:55 <mitchty> would it make sense to have a community/llvm35 and llvm36? I ask mostly due to not really wanting to have to compile llvm with ghc constantly
2016-02-23 10:47:31 <leo-unglaub> hey friends
2016-02-23 10:47:38 <leo-unglaub> is the php package broken?
2016-02-23 10:47:45 <leo-unglaub> because here it appears empty: https://pkgs.alpinelinux.org/contents?pkgname=php&arch=x86_64&repo=main
2016-02-23 10:49:25 <skarnet> it's php, *of course* it's broken
2016-02-23 10:49:32 <skarnet> 
ACTION sees himself out

2016-02-23 10:49:46 <coredumb> :D
2016-02-23 10:50:51 <leo-unglaub> hehehe
2016-02-23 10:52:13 <coredumb> isn't pkgs.a.o only showing edge packages ?
2016-02-23 10:52:53 <coredumb> cause last time - not too long ago - I installed php from main it certainly wasn't broken
2016-02-23 10:57:51 <leo-unglaub> i am currently not on an alpine machine
2016-02-23 10:57:58 <leo-unglaub> so i could not tell to be hornest
2016-02-23 10:58:02 <leo-unglaub> thats why i am asking you *g*
2016-02-23 11:29:54 <nmeum> leo-unglaub: main/php should be available on x86_64
2016-02-23 11:30:30 <nmeum> http://nl.alpinelinux.org/alpine/edge/main/x86_64/php-5.6.18-r1.apk
2016-02-23 11:33:24 <ncopa> https://pkgs.alpinelinux.org/package/main/x86_64/php
2016-02-23 11:33:55 <leo-unglaub> ncopa: yeah, but when you click on show contents there its empty
2016-02-23 11:33:59 <leo-unglaub> thats why i asked
2016-02-23 11:34:02 <leo-unglaub> :)
2016-02-23 11:41:40 <ncopa> i think it is empty for real
2016-02-23 11:42:13 <ncopa> you want php-fpm or php-cli or php-cgi
2016-02-23 12:11:42 <leo-unglaub> sorry, my router crashed ...
2016-02-23 12:11:56 <leo-unglaub> ncopa: you where right, its just an empty package
2016-02-23 13:04:36 <ncopa> sweet lldb just built for me
2016-02-23 13:06:06 <fabled> cool
2016-02-23 13:06:22 <ncopa> now i'd like to figure out how to build a single libllvm.so
2016-02-23 13:06:30 <ncopa> instead of the zillion
2016-02-23 13:06:53 <skarnet> fun with toolchain and linker options
2016-02-23 13:07:11 <ncopa> great fun indeed
2016-02-23 13:07:32 <skarnet> well llvm has one redeeming quality
2016-02-23 13:07:39 <skarnet> it's not a GNU toolchain!
2016-02-23 13:07:56 <ncopa> the compiler-rt sanitizers needs to be disabled though
2016-02-23 13:08:17 <ncopa> hm
2016-02-23 13:08:19 <ncopa> 18 February: Tag final release.
2016-02-23 13:08:19 <ncopa> Soon thereafter: Release LLVM 3.8.0.
2016-02-23 13:08:33 <ncopa> there should soon be a 3.8.0 release
2016-02-23 15:23:01 <leo-unglaub> re
2016-02-23 20:56:30 <przemoc> hi, I'm slowly building my dead simple version tracking with shell & co.  there is not much stuff tracked yet, but I'm slowly adding more.
2016-02-23 20:56:35 <przemoc> https://github.com/vracker/vracker
2016-02-23 20:57:19 <przemoc> results are updated ~daily and go to:  https://github.com/vracker/archive/commits/master
2016-02-23 20:58:28 <przemoc> when clandmeter will provide API for pkgs, some moderately easy comparison should be possible
2016-02-23 21:00:21 <przemoc> I'm tracking upstream only so far, but I want to track packages in distros too, like edge, sid, rawhide
2016-02-24 08:26:53 <ncopa> przemoc: nice!
2016-02-24 09:58:17 <leo-unglaub> good morning
2016-02-24 10:51:28 <ncopa> morning
2016-02-24 11:11:54 <ScrumpyJack> morning
2016-02-24 11:28:21 <leo-unglaub> is it mandatory to install alpine in the diskless mode on a raspberry pi 2?
2016-02-24 11:29:07 <leo-unglaub> when i dd a ready installed image on the sd card i coukd directly boot it, right?
2016-02-24 11:50:16 <clandmeter> leo-unglaub: you cant
2016-02-24 11:50:46 <clandmeter> \
2016-02-24 11:51:00 <clandmeter> oops cleaning keyboard :)
2016-02-24 11:51:30 <clandmeter> leo-unglaub: rpi needs a fat32 partition to boot from
2016-02-24 12:28:03 <fish_> what does it mean if a package is masked? where can I see why?
2016-02-24 12:50:15 <przemoc> re
2016-02-24 12:50:20 <przemoc> ncopa: thanks
2016-02-24 12:50:36 <przemoc> sysstat is slowly getting support for SVG drawing.  rather unexpected, but nice development for these ancient utilities.
2016-02-24 14:25:54 <fish_> leo-unglaub: you can also run alpine in a docker container on the rpi, that's what I'm doing :)
2016-02-24 14:40:38 <mitchty> well arm ghc port is hitting an llvm bug https://gist.githubusercontent.com/mitchty/f613a0aeb63f68451b18/raw/a9c14fb35e543cf2925691e2105c80f3ae58a64b/gistfile1.txt
2016-02-24 14:42:16 <leo-unglaub> fish_: i am not really the biggest docker fan
2016-02-24 14:42:19 <leo-unglaub> but i will look into it
2016-02-24 14:43:08 <fish_> leo-unglaub: well it always depends on the use case. it's still pretty buggy so I understand if people aren't big fans
2016-02-24 14:43:21 <fish_> on the rpi I'm using resin.io and love that workflow though
2016-02-24 15:26:56 <fish_> hrm, somehow firefox crashes my Xorg on raspberry pi
2016-02-24 15:27:33 <fish_> nothing in the Xorg log but on stderr it prints: Assertion failed: key->initialized (../include/privates.h: dixGetPrivateAddr: 122)
2016-02-24 15:28:56 <fish_> https://bugs.alpinelinux.org/issues/4425 <- looks like this? issue was reported 8 months ago
2016-02-24 15:34:53 <fish_> coredumb: hi! just saw you had the same issue a year ago :)
2016-02-24 15:43:14 <mitchty> i'm not a huge docker fan either, but it comes in handy when you have a lot of weird things to do that take a long time
2016-02-24 15:43:29 <mitchty> that said i use it like a mini makefile more than anything
2016-02-24 15:47:47 <fish_> so looks like xorg in stable is broken somehow but given the several reports I found around that issue, I wonder if it's worth to open an issue
2016-02-24 16:01:32 <coredumb> fish_: did I ?
2016-02-24 16:02:11 <fish_> coredumb: yes :)
2016-02-24 16:02:12 <fish_> 2015-03-17 21:21:12 <coredumb> Assertion failed: key->initialized (../include/privates.h: dixGetPrivateAddr: 122)
2016-02-24 16:02:16 <coredumb> fish_: to be honest I don't remember ...
2016-02-24 16:02:25 <coredumb> dunno how I fixed this :O
2016-02-24 16:02:26 <fish_> http://dev.alpinelinux.org/irclogs/%23alpine-linux-2015-03.log
2016-02-24 16:02:42 <fish_> but it looks like you fixed it by using a different package, something you built yourself
2016-02-24 16:02:55 <fish_> I'll try edge now and hope it works
2016-02-24 16:05:54 <coredumb> did I ?
2016-02-24 16:05:56 <coredumb> damn
2016-02-24 16:06:51 <coredumb> oh yeah now I remember
2016-02-24 16:07:00 <coredumb> it never worked!
2016-02-24 16:07:35 <fish_> great :/
2016-02-24 16:08:02 <coredumb> oh yeah
2016-02-24 16:08:05 <coredumb> that's it
2016-02-24 16:08:32 <coredumb> 2015-03-18 07:23:53 <coredumb> my own package built on stable works
2016-02-24 16:08:34 <coredumb> 2015-03-18 07:24:05 <coredumb> the one built by alpine on edge doesn't work on stable
2016-02-24 16:09:06 <fish_> coredumb: right now I only use stable and run into the same issue
2016-02-24 16:09:15 <fish_> but maybe in stable is now what was in edge when you tried
2016-02-24 16:09:43 <fish_> nope, same error
2016-02-24 16:11:28 <coredumb> what's giving you this error btw ?
2016-02-24 16:11:48 <fish_> what's interesting: I can run feh to set a wallpaper, so not every interaction breaks X
2016-02-24 16:11:59 <fish_> Xorg
2016-02-24 16:12:05 <coredumb> ok
2016-02-24 16:12:11 <coredumb> then I dunno :)
2016-02-24 16:13:10 <xming> hmm stable has 18.0?
2016-02-24 16:13:21 <fish_> https://bugs.alpinelinux.org/issues/4425 <- it's reported but looks like nobody looked into it
2016-02-24 16:13:24 <xming> 1.18.0?
2016-02-24 16:14:04 <fish_> 1.18.1 in edge
2016-02-24 16:17:45 <fish_> same issue happen on raspberry pi 2
2016-02-24 16:19:24 <xming> weird, the bug I had in mind was fixed in 1.18.0
2016-02-24 16:19:55 <xming> but this looks similar
2016-02-24 16:20:09 <xming> fish_: are you using glamor?
2016-02-24 16:20:25 <fish_> never heard of that, so probably not :)
2016-02-24 16:21:06 <xming> okay nvm me then
2016-02-24 16:21:27 <fish_> I'll try it with 3.2 now (asusming stable is 3.3, right?)
2016-02-24 16:21:58 <xming> yeah
2016-02-24 16:22:50 <fish_> https://github.com/Jodel/dashboard-viewer/blob/switch-to-alpine/Dockerfile.template <- that's what I'm installing
2016-02-24 16:23:07 <fish_> https://github.com/discordianfish/alpine-arm-docker/blob/master/builder/build <- this is how I build the base image
2016-02-24 16:23:46 <xming> ah docker guy :D
2016-02-24 16:25:45 <vkris> would it be difficult to subpackage xul libs in firefox ?
2016-02-24 16:26:06 <vkris> xulrunner
2016-02-24 16:26:19 <fish_> xming: I guess so :)
2016-02-24 16:29:21 <fish_> no firefox in 3.2 and testing and community firefox doesn't work due to missing dependencies
2016-02-24 16:32:22 <fish_> weird issue tracker..
2016-02-24 16:32:55 <fish_> and it's not using https
2016-02-24 16:34:05 <fish_> (it supports https but happily sending my cookies via http which is what google returns)
2016-02-24 16:40:41 <fish_> exact same bug with v3.2 (xorg 1.17.2)
2016-02-24 16:42:54 <xming> fish_: I would say it's fishy :p
2016-02-24 16:47:02 <fish_> well, I've updated the issue: https://bugs.alpinelinux.org/issues/4425
2016-02-24 16:47:20 <fish_> now I'll try xfbdev and give up if that doesn't work either
2016-02-24 16:49:34 <fish_> that works
2016-02-24 16:50:15 <fish_> but I guess it lacks support for various thing, mh? need at least overlay stuff for fast video playback
2016-02-24 16:50:29 <fish_> at least it should work for the dashboard project :)
2016-02-24 17:23:03 <skazz> Hello, can someone please tell me how the modloop is created for the raspberry pi release? Creating a simple upgrade guide for going up to edge, is there a particular mksquashfs command used?
2016-02-24 17:35:06 <fabled> skarnet, update-kernel does that for you
2016-02-24 17:35:17 <fabled> skazz, ^
2016-02-24 17:35:37 <skarnet> I am not ska<TAB>!
2016-02-24 17:36:21 <fabled> :)
2016-02-24 17:41:58 <neotek> BitL0G1c: do you know if donoban's issues were resolved?  I've had similar issues that I was waiting for alpine devs to fix and noticed from logs he was in here trying to get them resolved.
2016-02-24 17:44:22 <skazz> fabled: Oh thanks, did not see that command here: http://wiki.alpinelinux.org/wiki/Upgrading_Alpine
2016-02-24 17:45:25 <neotek> (essentially 3.2.3 works great via usb but upgrading to 3.3.1 via setup-bootable results in an unbootable system)
2016-02-24 17:45:57 <neotek> 3.3.0 has the same problem, but due to the apk cache issue in that version there's no point in not using 3.3.1
2016-02-24 17:50:20 <BitL0G1c> neotek - I don't know if it's been fixed - I thought the changed kernel line in extlinux.conf was possibly the problem
2016-02-24 17:51:38 <BitL0G1c> as a brand new usb install didn't work either
2016-02-24 17:54:33 <ncopa> midipix will work on a new installer
2016-02-24 17:54:49 <ncopa> would be nice if fabled and kunkku joined #alpine-installer
2016-02-24 17:54:59 <ncopa> and others who might be interested
2016-02-24 17:55:10 <ncopa> like skarnet
2016-02-24 18:06:34 <oneinsect> thanks guys
2016-02-24 18:06:37 <oneinsect> for resolving
2016-02-24 18:06:39 <oneinsect> the rpi2 bugs
2016-02-24 18:06:41 <oneinsect> so fast
2016-02-24 18:36:36 <skazz> BitL0G1c: neotek: In regards to the USB boot, the fresh install requires the usb MBR to be wiped with DD as old MBR/GPT partition tables seem to get picked up on
2016-02-24 18:36:54 <skazz> BitL0G1c: Someone had that issue in the past week I helped them solve
2016-02-24 18:39:46 <BitL0G1c> skazz - ok noted thank you
2016-02-24 19:30:20 <neotek> skazz: any idea why upgrading from 3.2.3 fails?
2016-02-24 20:40:55 <leo-unglaub> anyone around with commit privileges?
2016-02-24 21:09:54 <ncopa> leo-unglaub: no :)
2016-02-24 21:10:04 <leo-unglaub> damn :(
2016-02-24 21:10:19 <leo-unglaub> because xfsettingsd segfaults and needs a rebuild
2016-02-24 21:10:27 <ncopa> single rebuild is enough?
2016-02-24 21:10:32 <leo-unglaub> i just talked to the xfce developers
2016-02-24 21:10:37 <ncopa> you know why it segfaults?
2016-02-24 21:10:43 <leo-unglaub> xfsettingsd[2814]: segfault at 0 ip 00007b10b814e2a7 sp 00007c8845d829e0 error 4 in libupower-glib.so.3.0.1[7b10b813f000+21f000]
2016-02-24 21:10:54 <leo-unglaub> libupower-glib changes something
2016-02-24 21:11:38 <leo-unglaub> and without xfsettingsd my xfce4 desktop looks bad ... no icons, no keyboard shortcuts, no themes, ..
2016-02-24 21:12:11 <ncopa> commit 550035ca859613d1827345251e6333dbe8555437
2016-02-24 21:12:11 <ncopa> Author: Natanael Copa <ncopa@alpinelinux.org>
2016-02-24 21:12:11 <ncopa> Date:   Tue Sep 15 08:52:12 2015 +0200
2016-02-24 21:12:11 <ncopa>     main/xfce4-setting: rebuild against upower-0.99
2016-02-24 21:13:40 <ncopa> leo-unglaub: do you mix edge and v3.3 repo?
2016-02-24 21:14:04 <leo-unglaub> no, i dont
2016-02-24 21:14:09 <leo-unglaub> i am on pure edge
2016-02-24 21:14:16 <ncopa> can i reproduce it some way?
2016-02-24 21:14:28 <leo-unglaub> simply start xfce4
2016-02-24 21:14:36 <ncopa> i run xfce4
2016-02-24 21:15:05 <ncopa> $ ps xa | grep xfsetting
2016-02-24 21:15:06 <ncopa>  2801 ?        Sl     0:00 xfsettingsd --display :0.0 --sm-client-id 2a2e43698-e763-4e51-9790-353853fa1799
2016-02-24 21:15:45 <leo-unglaub> a60db0c84060b8bf4cfa50b101807d965e478ef085da811b7c4a925a5595e565bba91fbab76c4a93a806150bafe6b8322d5d308bb63a2a3e29b74f0d19bec8de  /usr/bin/xfsettingsd
2016-02-24 21:16:25 <ncopa> same
2016-02-24 21:16:41 <ncopa> x86 or x86_64?
2016-02-24 21:16:45 <ncopa> or arm...
2016-02-24 21:17:26 <leo-unglaub> x86_64
2016-02-24 21:17:31 <ncopa> same
2016-02-24 21:18:15 <ncopa> $ apk version upower
2016-02-24 21:18:15 <ncopa> Installed:                                Available:
2016-02-24 21:18:15 <ncopa> upower-0.99.3-r1                        = 0.99.3-r1
2016-02-24 21:18:42 <leo-unglaub> apk version upower
2016-02-24 21:18:42 <leo-unglaub> Installed:                                Available:
2016-02-24 21:18:42 <leo-unglaub> upower-0.99.3-r1                        = 0.99.3-r1
2016-02-24 21:19:21 <ncopa> is dbus running?
2016-02-24 21:20:02 <ncopa> $ ps xa | grep dbus | tpaste
2016-02-24 21:20:02 <ncopa> http://tpaste.us/3qb5
2016-02-24 21:20:43 <leo-unglaub> http://tpaste.us/2NJZ
2016-02-24 21:21:17 <ncopa> $ apk version polkit
2016-02-24 21:21:17 <ncopa> Installed:                                Available:
2016-02-24 21:21:17 <ncopa> polkit-0.105-r5                         = 0.105-r5
2016-02-24 21:22:10 <leo-unglaub> polkit-0.105-r5                         = 0.105-r5
2016-02-24 21:23:26 <leo-unglaub> hmm, this is strange
2016-02-24 21:23:44 <ncopa> $ apk version consolekit
2016-02-24 21:23:44 <ncopa> Installed:                                Available:
2016-02-24 21:23:44 <ncopa> consolekit-0.4.6-r1                     = 0.4.6-r1
2016-02-24 21:23:53 <ncopa> i suspect dbus something
2016-02-24 21:24:04 <ncopa> in any case, it should not segfault
2016-02-24 21:24:10 <ncopa> so its a bug
2016-02-24 21:24:17 <leo-unglaub> no consolekit installed
2016-02-24 21:24:23 <ncopa> try install it
2016-02-24 21:24:47 <ncopa> how i believe it works:
2016-02-24 21:25:03 <leo-unglaub> ha, indeed
2016-02-24 21:25:04 <ncopa> xfsettings asks upower about some power settings
2016-02-24 21:25:06 <leo-unglaub> now i works
2016-02-24 21:25:31 <ncopa> upower needs access some hw related stuff (power off for example)
2016-02-24 21:25:54 <ncopa> so upower asks polkit, does this user have access to it
2016-02-24 21:26:29 <ncopa> polkit asks polkit, is this a local user, connected via a local console
2016-02-24 21:27:06 <leo-unglaub> hmm, you are propobly right ... but this sounds like a lot of stuff for a simple settings manager to rememver the selected theme and iconset ...
2016-02-24 21:27:15 <ncopa> lol
2016-02-24 21:27:43 <ncopa> i was thinking the same
2016-02-24 21:28:14 <ncopa> btw, consolekit is dead. long live systemd
2016-02-24 21:28:22 <leo-unglaub> WAAAAA
2016-02-24 21:28:23 <ncopa> same with polkit i think
2016-02-24 21:28:29 <ncopa> yeah
2016-02-24 21:29:02 <leo-unglaub> well, give me rust and i rewrite xfsettingsd for you into a simgle 300kb binary without dependencies *g*
2016-02-24 21:29:27 <ncopa> i dont think xfsettings is the problem
2016-02-24 21:29:33 <ncopa> well kind of
2016-02-24 21:29:57 <leo-unglaub> its part of the problem
2016-02-24 21:30:01 <leo-unglaub> but no the entire problem alone
2016-02-24 21:30:04 <ncopa> i think it stores things like, what happens when you close the lid, what to do when battery power is empty
2016-02-24 21:30:16 <ncopa> that is stored in config
2016-02-24 21:30:20 <ncopa> i think
2016-02-24 21:30:27 <ncopa> anyway
2016-02-24 21:30:33 <ncopa> it feels complicated
2016-02-24 21:31:11 <ncopa> consolekit-0.4.6-r1 installed size:
2016-02-24 21:31:11 <ncopa> 516096
2016-02-24 21:31:25 <ncopa> you need 500k code to figure out if user is on console or not
2016-02-24 21:32:11 <leo-unglaub> no, 500k to figure out if he is root or not and then provide an input field that accepts a password to become root !!!!111!! thats much more work!!!!111!!
2016-02-24 21:33:02 <ncopa> no thats polkit
2016-02-24 21:33:04 <ncopa> polkit-0.105-r5 installed size:
2016-02-24 21:33:05 <ncopa> 565248
2016-02-24 21:33:12 <ncopa> another 500k
2016-02-24 21:33:14 <ncopa> oh
2016-02-24 21:33:15 <leo-unglaub> thats a different package???
2016-02-24 21:33:17 <leo-unglaub> WTF??
2016-02-24 21:33:18 <ncopa> yes
2016-02-24 21:33:33 <ncopa> and it does not even provide the prompt
2016-02-24 21:33:39 <leo-unglaub> now i am interrested in what they are doing ...
2016-02-24 21:33:56 <leo-unglaub> i have seen entire webservers smaller than 500k
2016-02-24 21:34:44 <ncopa> if you want prompt for user to enter the password you need
2016-02-24 21:34:49 <ncopa> what was the name...
2016-02-24 21:35:01 <ncopa> xfce-polkit
2016-02-24 21:35:05 <ncopa> or polkit-gnome
2016-02-24 21:35:08 <ncopa> either works
2016-02-24 21:35:14 <ncopa> they only provide the prompt dialof
2016-02-24 21:35:17 <ncopa> dialog*
2016-02-24 21:35:23 <leo-unglaub> hahaha
2016-02-24 21:35:28 <ncopa> its true
2016-02-24 21:35:46 <ncopa> xfce-polkit is my project i think
2016-02-24 21:35:55 <leo-unglaub> when people complain that linux desktops are a mess ... they are right *g*
2016-02-24 21:36:14 <leo-unglaub> on the other hand,  i dont want to see how bad osx is behind the sience ..
2016-02-24 21:36:30 <ncopa> probably not that bad
2016-02-24 21:37:13 <leo-unglaub> well, lets fix it simply one by one
2016-02-24 21:37:34 <ncopa> ConsoleKit is currently not actively maintained. The focus has shifted to the built-in seat/user/session management of Software/systemd called systemd-logind!
2016-02-24 21:37:44 <ncopa> you risk end up beating your head into systemd
2016-02-24 21:38:07 <leo-unglaub> no, i dont
2016-02-24 21:38:07 <ncopa> i suspect that if you today want fix any part of the big mess
2016-02-24 21:38:31 <ncopa> you'll end up realizing that to fix that tiny little component you are interested in,
2016-02-24 21:38:32 <leo-unglaub> nah, before i dig into systemd, i rewrite the entire thing by myself first
2016-02-24 21:38:40 <ncopa> you'll end up need rewrite entire systemd
2016-02-24 21:39:52 <skarnet> people have tried
2016-02-24 21:39:58 <skarnet> they gave up
2016-02-24 21:40:12 <awilfox> having just had a conversation about the code of launchd in another channel: it's that bad
2016-02-24 21:40:23 <ncopa> :)
2016-02-24 21:40:45 <leo-unglaub> dont discurrage me today
2016-02-24 21:40:54 <skarnet> I don't want to discourage you
2016-02-24 21:40:59 <leo-unglaub> i just managed to clean up my desk ... today i can do anything *g*
2016-02-24 21:41:09 <skarnet> but I do want to discourage you from attempting a systemd rewrite
2016-02-24 21:41:32 <ncopa> yeah, lets stay out of systemd. thats discouraging
2016-02-24 21:41:39 <skarnet> because in the best case, you will end up with something just as architecturally bad as systemd
2016-02-24 21:41:57 <leo-unglaub> i never sayed that i want to rewrite systemd
2016-02-24 21:42:06 <leo-unglaub> i want my stuff to follow an old but great principle
2016-02-24 21:42:06 <ncopa> it was me who said that...
2016-02-24 21:42:09 <leo-unglaub> one tool, one job
2016-02-24 21:42:13 <leo-unglaub> and everything is a file
2016-02-24 21:42:21 <skarnet> leo-unglaub: that's exactly my point, hold on...
2016-02-24 21:42:24 <awilfox> oh, you want plan 9 then :)
2016-02-24 21:42:51 <skarnet> the systemd interfaces are so designed that you *cannot* make independent tools if you implement them
2016-02-24 21:42:57 <skarnet> they are tied to the general architecture.
2016-02-24 21:43:07 <skarnet> If you want to be compatible with a component,
2016-02-24 21:43:21 <skarnet> you basically have to write the component the same way the systemd component is written.
2016-02-24 21:43:36 <skarnet> I'm not sure if it's intentional (malicious) or not (stupid)
2016-02-24 21:44:03 <skarnet> but the thing is, the systemd interfaces make it so that systemd components *cannot* be replaced
2016-02-24 21:44:21 <skarnet> (and if you try, you get what ncopa says: you reimplement systemd)
2016-02-24 21:44:45 <skarnet> If you want more details on the subject, look for VR's posts on darkedgy.net
2016-02-24 21:44:51 <skarnet> the author of uselessd
2016-02-24 21:45:11 <skarnet> He tried to write a "systemd-lite", then ultimately gave up, for the reasons I just wrote.
2016-02-24 21:45:34 <skarnet> He's known as "vezzy-fnord" on hacker news, if that's your thing.
2016-02-24 21:46:46 <ncopa> i posted a (sarcastic) comment in a forum about systemd once
2016-02-24 21:46:51 <ncopa> someone complained about journald
2016-02-24 21:47:12 <ncopa> there are always so many claims that its modular
2016-02-24 21:47:14 <ncopa> and great
2016-02-24 21:47:20 <skarnet> you're still getting hate mail today for this comment ? :)
2016-02-24 21:47:44 <leo-unglaub> as i sayed before
2016-02-24 21:47:54 <ncopa> i think i cited 6 different comments on how modular and inter changeable the components are in systemd
2016-02-24 21:47:55 <leo-unglaub> lets fix one thing after another
2016-02-24 21:48:02 <ncopa> from the same trhead
2016-02-24 21:48:23 <leo-unglaub> first i need to get my wifi manager working on alpine because my girlfriend is killing me over the command line script *g*
2016-02-24 21:48:25 <ncopa> so i took all those comments
2016-02-24 21:48:53 <ncopa> sand said: look! its super duper easy to replace journald with syslogd according the systemd lovers
2016-02-24 21:49:16 <ncopa> i dont think they realized i was sarcastic :)
2016-02-24 21:49:21 <ncopa> i think it was fun :)
2016-02-24 21:49:25 <skarnet> leo-unglaub: yeah, one thing at a time :) You're unlucky, though: wifi management is still uncharted territory, as in there's no good software that does it atm
2016-02-24 21:49:35 <skarnet> ncopa: haha
2016-02-24 21:49:45 <ncopa> http://www.phoronix.com/forums/forum/software/general-linux-open-source/821873-systemd-starts-doing-ntp-timezones-unified-cgroup-hierarchy/page4
2016-02-24 21:49:51 <leo-unglaub> ncopa: hehe, they really dont get sarcassim very well *g*
2016-02-24 21:49:59 <leo-unglaub> skarnet: my wifi manager is great
2016-02-24 21:50:03 <leo-unglaub> but its written in rust
2016-02-24 21:50:08 <leo-unglaub> ;)
2016-02-24 21:50:22 <skarnet> ncopa: what are you doing on moronix
2016-02-24 21:50:35 <ncopa> what everyone else does: trolling
2016-02-24 21:50:57 <skarnet> good point
2016-02-24 21:51:12 <skarnet> leo-unglaub: eh, why not, if that's your thing
2016-02-24 21:52:07 <leo-unglaub> skarnet: the only problem is, rust does not work on alpine yet
2016-02-24 21:52:13 <ncopa> oh i actually got a reponse
2016-02-24 21:52:14 <leo-unglaub> so i cannot deploy it here
2016-02-24 21:52:18 <ncopa> haha
2016-02-24 21:52:42 <ncopa> the response was "no, its not that simple"
2016-02-24 21:53:10 <skarnet> leo-unglaub: because llvm+musl is broken atm and rust uses llvm
2016-02-24 21:53:15 <skarnet> but it's slowly changing :)
2016-02-24 21:53:23 <leo-unglaub> ncopa: i did not know that there is a troll in you somewhere ;) i always thought of you as a very serious person *g*
2016-02-24 21:53:24 <leo-unglaub> hehehe
2016-02-24 21:53:49 <skarnet> he goes to places where nobody knows him. At night. With a mask. And he trolls.
2016-02-24 21:54:31 <ncopa> so
2016-02-24 21:54:36 <ncopa> this is a bit fun
2016-02-24 21:54:46 <ncopa> everyone tells you how modular systemd is
2016-02-24 21:54:51 <ncopa> you can replace components
2016-02-24 21:54:56 <coredumb> oh gosh
2016-02-24 21:54:56 <ncopa> its almost like posix
2016-02-24 21:54:58 <coredumb> please
2016-02-24 21:55:01 <coredumb> not systemd
2016-02-24 21:55:15 <ncopa> then when actually trying to do that
2016-02-24 21:55:23 <ncopa> you get: "no its not that simple"
2016-02-24 21:55:23 <skarnet> it's actually true: you can replace components. What they're not saying is that said components need to follow the exact same design
2016-02-24 21:55:35 <skarnet> and they're not saying it because _they don't know_
2016-02-24 21:55:40 <coredumb> a transcript of my conversation on #centos
2016-02-24 21:56:01 <coredumb> me: "Hey, I'd like to know what's the best way to paint my car in red"
2016-02-24 21:56:12 <skarnet> because nobody knows half a shit in software engineering and supports systemd
2016-02-24 21:56:21 <skarnet> *nobody*
2016-02-24 21:56:23 <coredumb> them: "mmmmmh I'm pretty sure you don't want your car being red"
2016-02-24 21:56:32 <ncopa> coredumb: exactly
2016-02-24 21:56:42 <ncopa> "why would you?"
2016-02-24 21:56:55 <coredumb> them: "Why don't you start by telling us _why_ you think you want your car painted red"
2016-02-24 21:57:01 <coredumb> me: "WTF!"
2016-02-24 21:57:35 <skarnet> coredumb: and when you wouldn't get convinced, they called you a hater?
2016-02-24 21:57:36 <coredumb> them: "Well you see, usually people think they want their car red, but actually they need it to be black"
2016-02-24 21:58:07 <coredumb> skarnet: quite
2016-02-24 21:58:11 <coredumb> for the record
2016-02-24 21:58:37 <coredumb> my "car being red" was "how do I run something _last_ with systemd"
2016-02-24 21:59:08 <coredumb> and the solution compared to echo "last command" >> /etc/rc.local
2016-02-24 21:59:20 <coredumb> is nothing like "systemd made Linux easy"
2016-02-24 21:59:35 <coredumb> gosh I really have to blog about it
2016-02-24 21:59:44 <skarnet> why would you do that? I'm pretty sure you don't want to do that. Start by telling us *why* you think it would be useful.
2016-02-24 22:00:34 <coredumb> skarnet: actually I had to go to #systemd and repeat the whole red car again to start getting informations on those damn targets >_<
2016-02-24 22:00:57 <ncopa> yeah. please tell us why you think a red car would be useful
2016-02-24 22:01:14 <coredumb> seriously the ppl on #centos... they must be s*cking RH devs for breakfast to be that lobotomized
2016-02-24 22:01:39 <leo-unglaub> ncopa: your systemd thread is awesome
2016-02-24 22:02:19 <skarnet> coredumb: think about it - a distribution that is just like RedHat, without even the creativity of RedHat
2016-02-24 22:02:46 <skarnet> who do you think works on it
2016-02-24 22:03:39 <coredumb> damn you did put creativity _and_ RedHat in the same sentence :O
2016-02-24 22:03:57 <skarnet> they do have creativity
2016-02-24 22:04:36 <skarnet> they don't have good engineering, but they make stuff. They come up with original, if bad, solutions.
2016-02-24 22:04:40 <leo-unglaub> damn, pidgin lost all my irc channels ...
2016-02-24 22:04:55 <leo-unglaub> ncopa: what was the name of the one channel with all the alpine commits?
2016-02-24 22:05:07 <coredumb> you mean taking overly old version of softwares and applying 2500 patches on them ?
2016-02-24 22:05:30 <coredumb> (yep I counted them for their qemu package on EL6)
2016-02-24 22:05:55 <skarnet> no, I mean systemd, cgroupd, cups, and all the other RedHat-made horrors
2016-02-24 22:06:28 <leo-unglaub> skarnet: dont be to hard on redhat...they get payed to there work so what do you expect??
2016-02-24 22:06:53 <coredumb> skarnet: yeah ... creativity or bad taste ?
2016-02-24 22:07:00 <skarnet> coredumb: both
2016-02-24 22:07:04 <coredumb> :D
2016-02-24 22:07:34 <coredumb> and gosh their sales guys... you wanna punch them in the face
2016-02-24 22:08:09 <coredumb> at least I do
2016-02-24 22:08:13 <skarnet> leo-unglaub: I'm actually harder on RedHat's *managers*. Their job is to know a software engineer from a nitwit. They're not doing it.
2016-02-24 22:09:20 <leo-unglaub> skarnet: i am born in germany .. and we germans have done a lot of shit in the past ... but i was never to embarresed to say that i am from germany like in systemd times ...
2016-02-24 22:09:26 <leo-unglaub> we germans did that monster
2016-02-24 22:10:00 <skarnet> Bad software has no nationality
2016-02-24 22:10:06 <ncopa> leo-unglaub: #alpine-commits
2016-02-24 22:10:42 <coredumb> lol leo-unglaub
2016-02-24 22:12:14 <skarnet> leo-unglaub: if you're referring to some events of the past century, remember that the USA detonated two atom bombs on civilians. And that's where Microsoft Windows come from. See? you can always find more horrible somewhere.
2016-02-24 22:12:52 <leo-unglaub> hehe
2016-02-24 22:14:20 <leo-unglaub> isn't the systemd guy the same one that wrote the dbus replacement in the kernel?
2016-02-24 22:14:38 <skarnet> Kay Sievers is one of them.
2016-02-24 22:15:55 <leo-unglaub> and the lennart poet ... something, right?
2016-02-24 22:15:58 <skarnet> That's my hard deadline for skabus: I need to have written it before Linus stops stalling kdbus.
2016-02-24 22:16:10 <skarnet> leo-unglaub: we don't speak that name around here.
2016-02-24 22:17:28 <leo-unglaub> ;)
2016-02-24 22:17:53 <leo-unglaub> lets change the subject ...
2016-02-24 22:24:09 <awilfox> cups is apple
2016-02-24 22:24:20 <awilfox> that's why it tries very hard to "auto config"
2016-02-24 22:24:22 <awilfox> and fails very hard
2016-02-24 22:25:34 <skarnet> oh, it's Apple? Sorry. Now that's another company with a lot of misguided creativity.
2016-02-24 22:25:42 <leo-unglaub> i am trying to get away from bash as my default shell and want to give ash a try
2016-02-24 22:25:57 <leo-unglaub> is there a file like .bashrc where i can store my aliases?
2016-02-24 22:29:43 <xming> oh lennart bashing du jour? :D
2016-02-24 22:30:07 <skarnet> You missed it. It was fun.
2016-02-24 22:30:37 <xming> I just want my Linux Desktop of the '90 with less bugs
2016-02-24 22:31:05 <xming> now suspend to RAM is broken since kernel 4.2 :/ I blame lennart
2016-02-24 22:32:04 <xming> all those autogimatically things are just broken
2016-02-24 22:32:46 <LeSpocky> blaming single people is uhm, that's no good manners I guess
2016-02-24 22:33:18 <xming> but that single person wants all the blame, since pulse
2016-02-24 22:33:51 <xming> speaking of which, I need to deconfigure pulseaudio on my desktop
2016-02-24 22:35:00 <LeSpocky> someone wants all the blame sounds to me like someone needs a scapegoat
2016-02-24 22:35:02 <xming> leo-unglaub: ~/.profile ?
2016-02-24 22:35:19 <leo-unglaub> xming: its not sources
2016-02-24 22:35:26 <leo-unglaub> should ash source it?
2016-02-24 22:35:46 <LeSpocky> but I wont stop anyone from personal insults today anymore, going to bed now
2016-02-24 22:35:59 <xming> I think shells should source .profile
2016-02-24 22:36:58 <leo-unglaub> xming: no, it does not
2016-02-24 22:37:03 <skarnet> xming: no, .profile is only for a login shell
2016-02-24 22:37:49 <skarnet> leo-unglaub: put the name of a file in your ENV environment variable, and your shells will source that file
2016-02-24 22:38:16 <skarnet> i.e. in your .profile, use "ENV=~/.shrc ; export ENV"
2016-02-24 22:38:29 <skarnet> and then your shells will source ~/.shrc
2016-02-24 22:38:47 <xming> or make all your shells login shells :p
2016-02-24 22:38:58 <skarnet> xming: that's not a good idea at all.
2016-02-24 22:39:04 <xming> skarnet: neat trick
2016-02-24 22:39:39 <skarnet> it's not a trick, it's posix. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html  look for ENVIRONMENT VARIABLES
2016-02-24 22:40:32 <leo-unglaub> brb, reboot
2016-02-24 22:43:56 <xming> anyone knows how to debug an unsuccessful suspend to RAM, monitor blanks but PC doesn't go off
2016-02-24 22:46:10 <leo-unglaub1> yeah, it worked :)
2016-02-24 22:46:21 <leo-unglaub1> now it sources ~/.ashrc
2016-02-24 23:17:18 <ammunta> well interactive shells of that will end up sourcing it too, even if they're not ash
2016-02-24 23:20:39 <skarnet> as long as you have ENV in your environment, they will
2016-02-25 02:50:12 <Adran> hello, i'm trying to customize an alpine iso but I need to drop several files and customize the repo list for this livecd to install the packages I need and leave configurations where they're supposed to go - its a specialized recovery cd. how do I go about doing this?
2016-02-25 08:07:41 <ncopa> Adran: you could maybe ship the iso with am apkovl
2016-02-25 08:07:44 <ncopa> an*
2016-02-25 09:52:01 <fish_> now back to my yesterdays issues... with Xfbdev things seem to work! but now firefox from @community segfauls :(
2016-02-25 10:35:25 <ScrumpyJack> hey fish_ wassup?
2016-02-25 10:36:04 <ScrumpyJack> you're on a RPi? firefox segfaults?
2016-02-25 10:40:27 <fish_> ScrumpyJack: yes
2016-02-25 10:40:34 <fish_> I'm trying testing now
2016-02-25 10:41:28 <ScrumpyJack> i guess this is an RPi2
2016-02-25 10:41:41 <fish_> no, 1
2016-02-25 10:41:48 <ScrumpyJack> *blink*
2016-02-25 10:42:22 <ScrumpyJack> can you show me a df -h
2016-02-25 10:43:14 <fish_> ScrumpyJack: I don't think this is related..
2016-02-25 10:43:36 <ScrumpyJack> can you show me anyway? :)
2016-02-25 10:45:34 <ScrumpyJack> apk add sprunge
2016-02-25 10:45:40 <ScrumpyJack> df -h | sprunge
2016-02-25 10:45:50 <ScrumpyJack> and paste the link here :)
2016-02-25 10:48:22 <ScrumpyJack> no?
2016-02-25 12:23:01 <fish_> testing also crashes and both on rpi and rpi2
2016-02-25 12:23:23 <fish_> ScrumpyJack: https://gist.github.com/discordianfish/daaa91fdfadeb57ccb70 - pretty sure it's unrelated though ;)
2016-02-25 12:28:19 <ScrumpyJack> fish_: ok cool, so you have / *not* mounted as tmpfs
2016-02-25 12:29:32 <fish_> and that's why it segfaults?! that doesn't make sense
2016-02-25 12:30:01 <fish_> with tmpfs mounted it also segfaults
2016-02-25 14:49:47 <ncopa> starefossen: what is the status on making nodejs:alpine docker image?
2016-02-25 15:24:12 <starefossen> ncopa: setting up jenkins to run the test suite on alpine
2016-02-26 00:12:14 <martell> hey guys was talking to ncopa about getting llvm patches upstreamed for him a few days ago but haven't heard anything since
2016-02-26 00:12:47 <martell> also somewhat related I want to add APKBUILD files for v8 spidermonkey and javascriptcore
2016-02-26 00:13:07 <martell> whats the process for getting them into testing / approved etc once they are done
2016-02-26 01:35:21 <mitchty> I've a question as well regarding llvm, simpler though
2016-02-26 01:35:41 <mitchty> i'm reworking my port a bit to be split apart again mostly so cabal can use gmp
2016-02-26 01:36:07 <mitchty> but I don't see a huge point in having llvm be a subpackage of ghc if i'm splitting things apart
2016-02-26 01:36:31 <mitchty> really what I need is the ability to specify: this version of ghc depends on llvm version xyz
2016-02-26 01:36:59 <mitchty> it can be anywhere too, doesn't need to be /usr, so it could be say /usr/llvm35 etc...
2016-02-26 01:37:44 <mitchty> and the next release will require 3.6 (doesn't work with 3.7 without hacking about), otherwise I'd depend on system llvm but that will break as soon as 3.7.1 is pushed
2016-02-26 01:38:55 <mitchty> so just curious how I approach that? I'd rather not have to compile llvm every time I build ghc
2016-02-26 05:44:45 <ammunta> http://wiki.alpinelinux.org/wiki/Alpine_Linux:Mailing_lists "Send an email to <mailing-list>+subscibe@lists.alpinelinux.org" typo subscribe in a rather important bit of info :)
2016-02-26 07:14:53 <ammunta> oh luajit 2.1 is actually p neat
2016-02-26 07:32:21 <ncopa> martell: i have the patches more or less ready for sending upstream
2016-02-26 07:32:34 <ncopa> oh, he left :/
2016-02-26 08:44:44 <ScrumpyJack> morning
2016-02-26 08:50:37 <ScrumpyJack> rxvt-unicode seems to depend on perl :(
2016-02-26 08:50:44 <ScrumpyJack> is this essential?
2016-02-26 08:56:07 <ScrumpyJack> i wonder who else uses urxvt :) perhaps we could disable perl extenstions?
2016-02-26 08:56:27 <ScrumpyJack> i know it's nothing in the grand scheme of things
2016-02-26 10:07:38 <yth> ScrumpyJack: I use matcher (clickable URLs) on some systems
2016-02-26 10:12:42 <yth> I was wondering the other day about making the urxvt terminfo files a subpackage, too: it's be useful to have these on headless systems without any dependencies
2016-02-26 10:16:07 <yth> and also add the (tiny) urxvtcd script from debian :-)
2016-02-26 12:51:19 <vkris> would be nice to have this enabled, http://llvm.org/docs/LibFuzzer.html
2016-02-27 00:14:54 <jirutka> hi, I have question about writing abuild – how I can declare dependency on any version of openjdk-jre, i.e. currently openjdk7-jre or openjdk8-jre?
2016-02-27 17:27:40 <jirutka> hi, I have question about writing abuild – how I can declare dependency on any version of openjdk-jre, i.e. currently openjdk7-jre or openjdk8-jre?
2016-02-28 02:04:13 <transhuman> hi maybe this is the proper channel, is there a switch to debug a build process using ABUILD
2016-02-28 15:37:58 <mosez> oh... why does golang not work on alpine on my raspberry pi 1? :(
2016-02-28 15:39:11 <mosez> /usr/lib/go/bin/go: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-armhf.so.1, not stripped looks good so far
2016-02-28 16:15:07 <nmeum> so…what happen when you try to compile a go program on your raspberry pi?
2016-02-28 16:15:16 <nmeum> do you get any error message?
2016-02-29 03:36:34 <nmeum> ncopa: what's your opinion on adding an additional environment variable to abuild to make the patch args in default_prepare configurable?
2016-02-29 05:33:48 <kunkku> oh, there is a default_prepare function
2016-02-29 05:34:00 <kunkku> I was thinking of implementing that...
2016-02-29 07:47:25 <ammunta> #392
2016-02-29 08:19:11 <vkris> ncopa, was thinking to add /usr/bin/xvfb-run in xvfb pkg
2016-02-29 08:19:11 <vkris> from, https://packages.debian.org/wheezy/i386/xvfb/filelist
2016-02-29 08:19:11 <vkris> Seems to work with slimerjs with minor change
2016-02-29 08:19:11 <vkris> send patch ?
2016-02-29 10:00:08 <ncopa> nmeum: i am open to that if you can find a good way to do it
2016-02-29 10:00:14 <ncopa> vkris: yes send a patch
2016-02-29 10:18:13 <ncopa> fabled: could you please have a quick look at the patch submitted with #5192
2016-02-29 10:18:27 <ncopa> i think you mentioned ealier that we want limit the search depth
2016-02-29 10:19:08 <ncopa> we probably want add a boot option so you can override the default maxdepth
2016-02-29 10:19:41 <ncopa> but i think we need apply that patch for now
2016-02-29 10:20:07 <ncopa> possibly with maxdpeth 2 instead of 1
2016-02-29 10:35:53 <barthalion> rnalrd: any reason for bumping nginx to 1.9? it's not a stable release
2016-02-29 10:36:08 <barthalion> I want to revert this, you can put 1.9 in testing if you need it for something
2016-02-29 10:36:20 <barthalion> or add new package, named nginx-mainline for that
2016-02-29 10:37:07 <rnalrd> well, we have stable branches for stable releases, don't we?
2016-02-29 10:37:58 <barthalion> wat
2016-02-29 10:38:12 <barthalion> edge should also track stable releases
2016-02-29 10:39:01 <barthalion> unless you have some really good reason to think that nginx 1.10 will be released before 3.4
2016-02-29 10:45:41 <rnalrd> k, fine i'll use testing if needed
2016-02-29 11:04:04 <fabled> ncopa, huh? you do full recursive scan? why?
2016-02-29 11:05:16 <ncopa> fabled: because it was easy to implement
2016-02-29 11:05:36 <ncopa> and on the iso it is no problem
2016-02-29 11:05:42 <ncopa> not beig problem at least
2016-02-29 11:05:44 <fabled> the limit should be in .opts ?
2016-02-29 11:05:54 <fabled> oh
2016-02-29 11:05:57 <fabled> and it's needed in sysfs
2016-02-29 11:06:03 <ncopa> .opts?
2016-02-29 11:06:07 <fabled> &opts
2016-02-29 11:06:20 <fabled> struct recurse_opts
2016-02-29 11:06:20 <fabled> not separate argument
2016-02-29 11:06:50 <ncopa> i thought of that too but separate arg was easier
2016-02-29 11:06:55 <ncopa> not big diff though
2016-02-29 11:07:08 <ncopa> just need to remember +/- correct place
2016-02-29 11:07:27 <fabled> on recursive functions it's better to have less function arguments to limit stack usage
2016-02-29 11:07:32 <ncopa> yes i know
2016-02-29 11:07:56 <ncopa> but in this case it'll only be very few levels
2016-02-29 11:07:59 <fabled> for find_boorepos it makes sense
2016-02-29 11:08:13 <fabled> how about the /sys/* stuff?
2016-02-29 11:08:25 <ncopa> i think we limit the search already there
2016-02-29 11:08:36 <ncopa> to specific branches
2016-02-29 11:08:52 <ncopa> i dont know if there are any hard limit on how deep thing may go
2016-02-29 11:09:32 <fabled> there isnot
2016-02-29 11:09:46 <fabled> but it's not following symlinks
2016-02-29 11:09:49 <fabled> i think
2016-02-29 11:10:03 <ncopa> no i dont think we follow symlinks
2016-02-29 11:10:19 <ncopa> should not follow symlinks on recursive...
2016-02-29 11:10:34 <fabled> yeah
2016-02-29 11:10:53 <fabled> i think the concept in the patch is good
2016-02-29 11:11:02 <ncopa> i havent checked but i assume that i was not that stupid :)
2016-02-29 11:11:07 <ncopa> (re follow symlinks)
2016-02-29 11:11:15 <fabled> i'd just put the limit to the struct; and recheck what is the proper limit for /sys/*
2016-02-29 11:11:22 <fabled> i'm not sure limiting that to 1 is good
2016-02-29 11:11:37 <ncopa> limiting sysfs to 1 will not do
2016-02-29 11:11:44 <ncopa> sysfs needs deeper
2016-02-29 11:11:55 <fabled> yeah
2016-02-29 11:12:02 <ncopa> or disable
2016-02-29 11:12:06 <fabled> that's why it's full recursive
2016-02-29 11:12:08 <fabled> and why finding repos needs different limit
2016-02-29 15:17:17 <coredumb> what's the policy about kernel modules ?
2016-02-29 15:18:19 <coredumb> is it generally allowed providing aports patches that enable kernel modules/options or is it better to discuss it before ?
2016-02-29 15:21:28 <clandmeter> just sending the patches is enough to start a discussion
2016-02-29 15:21:49 <clandmeter> except dont expect out of tree modules
2016-02-29 15:23:29 <coredumb> clandmeter: ok
2016-02-29 15:23:51 <coredumb> can I/we expect updated in tree modules ? :)
2016-02-29 15:24:27 <clandmeter> anything thats merged and logic should be ok.
2016-02-29 15:24:42 <coredumb> ok
2016-02-29 15:24:48 <clandmeter> out of tree modules needs maintenance
2016-02-29 15:24:57 <clandmeter> and they are out of tree for a reason.
2016-02-29 15:24:58 <coredumb> ok
2016-02-29 15:25:26 <coredumb> clearly :)
2016-02-29 15:25:48 <coredumb> so for out of tree modules should one provide an external package ?
2016-02-29 15:25:54 <ncopa> what we will ask is: why is this kernel module not in mainline?
2016-02-29 15:26:15 <clandmeter> im sure we missed a few interesting modules, so adding them makes sense if ppl use it, ppl just never requested them.
2016-02-29 15:26:23 <ncopa> the problem we have had with 3rd party modules are often the same that mainline kernel has
2016-02-29 15:26:45 <ncopa> mainline kernel will not merge new code unless they believe someone will maintain it
2016-02-29 15:26:54 <coredumb> yeah sure
2016-02-29 15:26:57 <vkris> https://pkgs.alpinelinux.org/contents?pkgname=iw&arch=x86_64&repo=main , has man8/iw.8.gz
2016-02-29 15:27:51 <ncopa> when kernel devs has no intention maintaining the module, then *we* will end up doing the maintenanve
2016-02-29 15:27:58 <ncopa> which we don't want
2016-02-29 15:28:28 <ncopa> other reason that mainline don't want include new modules is because the code quality is bad
2016-02-29 15:28:47 <coredumb> how do you handle 3rd party modules recompilation on kernel upgrade ?
2016-02-29 15:29:05 <ncopa> we need recompile them aswell too
2016-02-29 15:29:17 <coredumb> sure is that a manual process ?
2016-02-29 15:29:33 <ncopa> we did it today: http://git.alpinelinux.org/cgit/aports/log/
2016-02-29 15:29:43 <ncopa> half manual and half scripted
2016-02-29 15:29:46 <coredumb> ok
2016-02-29 15:29:53 <clandmeter> vkris: thx fixed.
2016-02-29 15:30:03 <ncopa> i have scripts that edits the APKBUILDs
2016-02-29 15:30:08 <ncopa> and test build them
2016-02-29 15:30:19 <ncopa> but if they dont build, then we have a problem
2016-02-29 15:30:59 <ncopa> often when we upgrade kernel to new major.minor version (eg 4.1 -> 4.2) the 3rdparties don't build
2016-02-29 15:31:11 <ncopa> and can slow down the kernel upgrade
2016-02-29 15:31:33 <ncopa> in other words, 3rd party kernel modules are timeconsuming to maintain
2016-02-29 15:31:34 <coredumb> yeah
2016-02-29 15:31:42 <ncopa> so we want avoid if possible
2016-02-29 15:31:46 <coredumb> I believe you
2016-02-29 15:32:18 <ncopa> mainline kernel often dont want them for a good reason
2016-02-29 15:32:30 <ncopa> and often we dont want it either for the same reason(s)
2016-02-29 15:32:52 <coredumb> :)
2016-02-29 15:33:14 <ncopa> so first question you will get if you send a patch will be: why is this not in mainline kernel?
2016-02-29 15:35:07 <coredumb> gotcha
2016-02-29 15:39:01 <mitchty> ok so i've broken my ghc port apart again, so there is ghc-bootstrap ghc-llvm-35 ghc cabal and stack, and i've also gotten llvm 3.7.1 working for the 8.0 rc2 candidate
2016-02-29 15:39:41 <mitchty> i put the llvm stuff into /usr/lib/ghc/{llc|opt}-3.x for lack of a better spot
2016-02-29 15:39:51 <mitchty> but i only need those two binaries for ghc
2016-02-29 15:40:05 <mitchty> more for arm really but that has its own issues
2016-02-29 15:40:12 <mitchty> does that sound reasonable?
2016-02-29 15:54:42 <ncopa> mitchty: i'm working on llvm/clang 3.7.1
2016-02-29 15:55:10 <ncopa> i want upstream the patches
2016-02-29 15:55:19 <mitchty> ncopa: cool but i still need 3.5 no matter what, and ghc doesn't handle llvm version changes well
2016-02-29 15:55:32 <ncopa> 3.5?
2016-02-29 15:55:42 <ncopa> ok...
2016-02-29 15:55:44 <vkris> update nginx to  1.9.12 pls
2016-02-29 15:55:48 <ncopa> ghc sounds fun....
2016-02-29 15:55:50 <mitchty> yep thats what the codegen for 7.10.3 used
2016-02-29 15:56:05 <vkris> seems issue with pkgs.a.o
2016-02-29 15:56:06 <mitchty> i hacked 3.6 in but its really not that worth it
2016-02-29 15:56:26 <mitchty> its more llvm ir changes a lot between releases and isn't backwards compatible
2016-02-29 15:56:44 <ncopa> nmeum: re nginx, i am ok with using mainline nginx as log as we land ont stable for our stable release
2016-02-29 15:57:32 <mitchty> ncopa: the void linux llvm tree has most of things done if you want to look there
2016-02-29 15:57:46 <mitchty> and all i'm doing is the bare minimum for opt/llc https://github.com/mitchty/alpine-linux-ghc-bootstrap/blob/ghc8.0/ghc-llvm37/APKBUILD
2016-02-29 15:58:00 <nmeum> ncopa: huh? I didn't say anything regarding nginx :p
2016-02-29 15:58:23 <ncopa> ah
2016-02-29 15:58:27 <ncopa> it was barthalion
2016-02-29 15:58:28 <ncopa> sorry
2016-02-29 15:59:39 <vkris> 1.9.11 had regression which he might have hit upon ;)
2016-02-29 15:59:59 <vkris> http://nginx.org/en/CHANGES
2016-02-29 16:00:29 <ncopa> re niginx, i think we should built it similar to what official upstream does
2016-02-29 16:00:56 <ammunta> why is our nginx 1.9.x instead of 1.8.x btw
2016-02-29 16:01:28 <ncopa> and we should merge in the  nginx-naxsi to nginx pkg
2016-02-29 16:01:41 <ncopa> ammunta: i think someone wanted 1.9x for spdy or similar
2016-02-29 16:02:44 <vkris> spdy or http2 ;)
2016-02-29 16:03:40 <vkris> Changes with nginx 1.9.5                                         22 Sep 2015
2016-02-29 16:03:43 <vkris>     *) Feature: the ngx_http_v2_module (replaces ngx_http_spdy_module).
2016-02-29 16:03:46 <vkris>        Thanks to Dropbox and Automattic for sponsoring this work.
2016-02-29 16:04:46 <vkris> oops, I did not intend the dropbox line
2016-02-29 16:13:15 <vkris> ncopa: would it be easy to have xulrunner pkg again ?
2016-02-29 16:14:59 <vkris> and there is still a symlink in /usr/lib/firefox-38.3.0/ to xulrunner
2016-02-29 16:15:53 <ncopa> no. firefox does run well when xulrunner is built as external lib
2016-02-29 16:16:13 <vkris> ok
2016-02-29 18:24:14 <barthalion> ncopa: I pushed nginx-mainline to Arch due to repeating requests
2016-02-29 18:24:23 <barthalion> as in, "use mainline on your own risk"
2016-02-29 21:14:50 <ammunta> well, with both nginx and nodejs in consideration, do we have precedent as to what to do when we have both a "stable" and an "unstable" version of a thing, for which is tagged
2016-02-29 23:36:14 <nmeum> as of today I am no longer able to unlock aes-xts-plain64 encrypted luks volumes in the initramfs with a grsec kernel. Any idea which recent change might have caused this? Does anybody else experience this problem?
2016-02-29 23:36:22 <nmeum> It works with the linux-vanilla kernel
2016-02-29 23:53:10 <fmqw> Any staff around?