2016-08-01 00:00:31 <^7heo> But I'm THAT close to be able to package it now.
2016-08-01 00:01:16 <kazblox> hm
2016-08-01 00:01:29 <^7heo> it's just that, a package that requires to modify your running system to be built (not the builddir, the complete system, to install libs with go get -u and all), and requires multiple symlinks in various places to be added and deleted at some precise moments in the build...
2016-08-01 00:01:48 <^7heo> I don't think we ever want that.
2016-08-01 00:01:55 <kazblox> does Natanael Copa go on this chat
2016-08-01 00:02:11 <^7heo> kazblox: is it a pun with 'go'?
2016-08-01 00:02:20 <kazblox> no
2016-08-01 00:02:25 <^7heo> or did you mean to ask if ncopa sometimes comes here?
2016-08-01 00:02:31 <kazblox> ^ that
2016-08-01 00:02:36 <^7heo> yes he does.
2016-08-01 00:02:41 <^7heo> tomorrow he'll be here.
2016-08-01 00:04:53 <kazblox> thats when I'm in school
2016-08-01 00:04:55 <kazblox> doh
2016-08-01 09:42:30 <^7heo> jirutka: can we please merge the PR I did for gogs?
2016-08-01 09:42:53 <^7heo> jirutka: the assets I had in the version that is current in the repos aren't matching with the assest that gogs expect.
2016-08-01 09:42:59 <^7heo> because of version mismatch.
2016-08-01 09:43:05 <^7heo> therefore, the current gog doesn't work.
2016-08-01 10:30:04 <clandmeter> ^7heo: regarding gogs, the upstream glide files are incorrect, but the generated glide files are also incorrect?
2016-08-01 10:30:43 <^7heo> clandmeter: so, regarding gogs; the upstream glide files are *incomplete* afaik, and the generated files incorrect.
2016-08-01 10:31:16 <^7heo> clandmeter: to, to solve the issue, what I did was get the missing deps from the generated ones, and use the upstream ones for the rest.
2016-08-01 10:31:40 <clandmeter> interesting
2016-08-01 10:31:51 <clandmeter> so GO really does suck, and gogs is just like it.
2016-08-01 10:32:13 <^7heo> clandmeter: now, we can do that in two ways: either we keep it the way it is (i.e. patch the files at build time with .patch files); or as jirutka would rather have: patch the files at APKBUILD dev time, and commit the full files.
2016-08-01 10:32:30 <^7heo> clandmeter: yes go does suck, and gogs just happen to be one of the least sucky go programs ever.
2016-08-01 10:32:39 <^7heo> clandmeter: which is an acheivement in itself.
2016-08-01 10:32:53 <clandmeter> if you cannot build it, it sucks just as much.
2016-08-01 10:35:06 <^7heo> you can build it.
2016-08-01 10:35:12 <^7heo> it builds on gh and on my laptop.
2016-08-01 10:35:23 <^7heo> it doesn't build on the build servers, but that isn't related.
2016-08-01 10:36:08 <clandmeter> im not refering the build issue we are currently having.
2016-08-01 10:36:17 <^7heo> so what then?
2016-08-01 10:36:20 <^7heo> because it builds.
2016-08-01 10:36:28 <^7heo> or I am misunderstanding you?
2016-08-01 10:36:36 <clandmeter> you have to patch the build files because they are incomplete.
2016-08-01 10:37:13 <^7heo> yeah, that's something I am going to investigate.
2016-08-01 10:37:23 <^7heo> for now, the important part is to have a working package.
2016-08-01 10:37:50 <^7heo> but I guess that if it's really missing deps, I'll have no probelm to get a patch in upstream.
2016-08-01 10:38:00 <^7heo> else, it's a default with my/our build process.
2016-08-01 10:38:11 <clandmeter> the important part is to know how to procede with GO packages in the future.
2016-08-01 10:38:27 <clandmeter> and not keep patching aports because of GO madness
2016-08-01 10:39:11 <^7heo> clandmeter: agreed.
2016-08-01 10:39:16 <^7heo> totally agreed.
2016-08-01 10:39:24 <^7heo> unfortunately go is there.
2016-08-01 10:39:28 <^7heo> and we have to deal with it.
2016-08-01 10:39:35 <^7heo> so let's find a suitable way to mitigate that.
2016-08-01 10:39:40 <clandmeter> it looks like syncthing already has all its deps in vendor
2016-08-01 10:39:52 <clandmeter> so it doesnt pull in anything at build time.
2016-08-01 10:40:38 <jirutka> copying all the dependencies to the repo is one of the worst ways
2016-08-01 10:41:21 <jirutka> as I see it the glide way with lock files may be the less evil
2016-08-01 10:44:39 <jirutka> ad ^7heo’s two ways – me biggest concern is not about full files vs. patches, but how to update abuilds; when I look at clandmeter’s package https://github.com/alpinelinux/aports/commit/10c0bb8397a231f8a6f1db280e67de7bf7668005, it’s quite clear how to update the package, there’s a helper function that regenerates glide files; when I look at gogs, I have no idea how to update
2016-08-01 10:44:43 <^7heo> jirutka: +1
2016-08-01 10:45:02 <^7heo> you're right about that.
2016-08-01 10:45:12 <^7heo> and it's true, I have to fix that.
2016-08-01 10:45:40 <jirutka> and I should admit that I still don’t understand why the hell are gogs glide files incomplete and what you did to make them complete
2016-08-01 10:46:13 <jirutka> imho you should open an issue at gogs to fix it
2016-08-01 11:09:30 <fabled> i've thinking of the apk-tools features requests, etc.
2016-08-01 11:09:48 <fabled> and the backlog of features i already have on my todo
2016-08-01 11:10:08 <fabled> i would probably like to rewrite it... :-o
2016-08-01 11:10:23 <fabled> so if there's any crazy apk-tools features more, i'd like to hear about it
2016-08-01 11:11:20 <fabled> there was a thread in the ML last october
2016-08-01 11:16:04 <jirutka> fabled: when are you gonna merge cross-build (http://git.alpinelinux.org/cgit/abuild/log/?h=cross-build) to the master branch?
2016-08-01 11:17:00 <fabled> jirutka, hope to do it soon now
2016-08-01 11:17:05 <fabled> i think the code is stable
2016-08-01 11:17:14 <fabled> i managed to bootstrap multiple different architectures
2016-08-01 11:17:25 <fabled> and the abuild cross-compile mode also did not give out any errors
2016-08-01 11:18:05 <jirutka> great! I’d like to make it work with `set -e`, but since you’ve introduced many changes I should wait for cross-build to be merged before starting
2016-08-01 11:18:18 <fabled> oh right
2016-08-01 11:18:23 <fabled> was there plan how to do it
2016-08-01 11:18:29 <fabled> option="errexit" or similar?
2016-08-01 11:18:44 <fabled> and warn if that is not set
2016-08-01 11:19:13 <jirutka> I think that it should be set for abuild globally
2016-08-01 11:19:30 <jirutka> I consider it to be a mistake that it’s not here from the beginning
2016-08-01 11:19:34 <fabled> yes
2016-08-01 11:19:40 <fabled> though, it can break certain things
2016-08-01 11:19:59 <fabled> like "[ test ] && foo" will give you false but you should not abort on it
2016-08-01 11:20:13 <jirutka> it does not, at least on ash
2016-08-01 11:20:19 <fabled> oh?
2016-08-01 11:20:22 <jirutka> but yeah, it may break some abuilds, I will take care of it
2016-08-01 11:20:30 <skarnet> [ test ] && foo || true
2016-08-01 11:20:32 <skarnet> always
2016-08-01 11:20:46 <fabled> jirutka, it does
2016-08-01 11:20:46 <fabled> ~ $ [ -n "" ] && echo foo
2016-08-01 11:20:46 <fabled> ~ $ echo $?
2016-08-01 11:20:46 <fabled> 1
2016-08-01 11:20:47 <jirutka> `set -e` behaves a little differently on various shells
2016-08-01 11:21:00 <fabled> it gives false when the '&&' branch is not taken
2016-08-01 11:21:01 <jirutka> but some of them handles [ test ] && foo as a special case
2016-08-01 11:21:20 <jirutka> try it with set -e
2016-08-01 11:21:28 <fabled> but so set -e handles it special?
2016-08-01 11:21:34 <skarnet> it makes sense that "bar && foo" returns false if bar returns false
2016-08-01 11:21:53 <jirutka> I’ve been arguing about it with ^7heo few days ago, I was also surprised that even ash handles it specially
2016-08-01 11:21:55 <skarnet> if you want a construct that always returns true, you should write "if bar; then foo; fi"
2016-08-01 11:22:05 <jirutka> yes
2016-08-01 11:22:33 <fabled> but that's the only major thing i think
2016-08-01 11:22:40 <jirutka> yeah
2016-08-01 11:22:41 <fabled> otherwise -e by default is pretty much the right thing
2016-08-01 11:23:15 <jirutka> my plan is to review abuild code for potentially problematic places, add set -e and then try to rebuild all repos to make sure it it does not break anything
2016-08-01 11:24:13 <jirutka> and then we can FINALLY get rid of this silly `|| return 1` noise
2016-08-01 11:25:16 <fabled> yeah
2016-08-01 11:25:29 <fabled> you could work on the cross-branch already if you want
2016-08-01 11:25:38 <fabled> or maybe i just merge it now that ncopa is away ;)
2016-08-01 11:26:56 <jirutka> XD
2016-08-01 11:29:08 <fabled> i pull it
2016-08-01 11:29:17 <fabled> ncopa can make stable branch of abuild if needed
2016-08-01 11:29:33 <fabled> done
2016-08-01 11:34:09 <jirutka> thanks
2016-08-01 11:34:49 <jirutka> skarnet: btw I often prefer `[ ! test ] || foo` instead of `[ test ] && foo` for that reason
2016-08-01 11:35:27 <skarnet> and I prefer the test command to [ ] :)
2016-08-01 11:39:31 <jirutka> skarnet: how does it affect issue with &&?
2016-08-01 12:00:23 <kl3> Are there any plans to provide libre deblobbed kernels in the (near) feature?
2016-08-01 12:01:56 <jirutka> kl3: libre deblobbed? o.O
2016-08-01 12:02:11 <kl3> jirutka: Without binary blobs
2016-08-01 12:03:16 <kl3> jirutka: https://en.wikipedia.org/wiki/Linux-libre
2016-08-01 12:30:43 <skarnet> jirutka: it doesn't, it's totally orthogonal to && (which is parsed by the shell)
2016-08-01 12:32:17 <jirutka> skarnet: so why you’ve mentioned it? o.O
2016-08-01 12:32:27 <clandmeter> ortowho?
2016-08-01 12:33:01 <jirutka> clandmeter: orthogonal… like it does have anything in common
2016-08-01 12:33:04 <skarnet> just as a personal preference. You say "[ foo ]", I say "test foo". Nothing else.
2016-08-01 12:33:55 <jirutka> skarnet: maybe you’ve missed my point… it was reaction to your `[ test ] && foo || true`
2016-08-01 12:33:55 <skarnet> and, vacation time. See you, working class!
2016-08-01 12:34:53 <jirutka> clandmeter: ah, I mean It does have nothing in common… I’ve tried to avoid double negative and removed all negatives as a result XD
2016-08-01 13:17:25 <^7heo> How do we feel about "packaging" an app to be used via a docker image?
2016-08-01 13:17:49 <^7heo> (i.e. having a dep on docker, providing an init file that uses docker run, docker start, etc.)
2016-08-01 13:18:17 <jirutka> ^7heo: WHAT?! are you f*cking mad?!
2016-08-01 13:18:31 <^7heo> jirutka: it's the way drone is supposed to be 'shipped'
2016-08-01 13:18:36 <^7heo> jirutka: not my design ™
2016-08-01 13:18:40 <jirutka> ^7heo: that’s their problem
2016-08-01 13:18:52 <^7heo> to build it, it's REALLY hard.
2016-08-01 13:19:02 <^7heo> it's actually really fucked up.
2016-08-01 13:19:11 <jirutka> ^7heo: then just write dozens of lines in Dockerfile…
2016-08-01 13:19:19 <^7heo> jirutka: ?
2016-08-01 13:19:27 <jirutka> ^7heo: yeah, Docker is fucked up, but please don’t fuck up Alpine because of it
2016-08-01 13:20:00 <^7heo> jirutka: I'm just asking how *we* feel about that.
2016-08-01 13:20:08 <^7heo> jirutka: I'm not saying I intend to do it.
2016-08-01 13:20:27 <jirutka> ^7heo: don’t know how people usually use Docker? just create a huge Dockerfile with dozens of unreadable script lines to build it from source
2016-08-01 13:20:42 <^7heo> jirutka: that's not how people use it.
2016-08-01 13:21:17 <^7heo> jirutka: people use it with run -i org/image:version /bin/bash || while true; do whine; done
2016-08-01 13:21:45 <^7heo> it's not common to write a dockerfile.
2016-08-01 13:21:55 <^7heo> it's only the 'docker power users' who dare to go there.
2016-08-01 13:23:35 <jirutka> uh
2016-08-01 20:48:53 <^7heo> you know that software sucks when it takes you 4 days  to fail at packaging something, and 4h at writing something that povides the same base functionality
2016-08-01 21:20:43 <jirutka> ^7heo: you’ve already wrote CI? :)
2016-08-01 21:52:48 <^7heo> jirutka: well, it doesn't have much of an interface
2016-08-01 21:53:05 <^7heo> jirutka: and you gotta place the binary in the repo for now
2016-08-01 21:53:09 <jirutka> how have you solved streaming of logs?
2016-08-01 21:53:13 <^7heo> jirutka: but yeah
2016-08-01 21:53:29 <^7heo> jirutka: popen and read()?
2016-08-01 21:53:59 <jirutka> I mean streaming from leaf node to the master node…
2016-08-01 21:54:09 <jirutka> from worker to master node
2016-08-01 21:54:42 <^7heo> oh, it doesn't habdle nodes for now
2016-08-01 21:54:47 <^7heo> handle
2016-08-01 21:54:59 <jirutka> uh, so what does it do actually?
2016-08-01 21:55:03 <^7heo> it just runs testsnin containers
2016-08-01 21:55:10 <^7heo> tests in*
2016-08-01 21:55:16 <^7heo> and saves the output
2016-08-01 21:55:22 <^7heo> from a yaml file
2016-08-01 21:56:31 <^7heo> it does more than drone already
2016-08-01 21:57:58 <^7heo> (which is just a useless ui)
2016-08-01 22:14:36 <jirutka> talk is cheap. show me the code! :)
2016-08-01 22:17:17 <^7heo> it's not on my phone ;)
2016-08-01 23:00:22 <jirutka> ^7heo: btw I got response from libguestfs:
2016-08-01 23:00:22 <jirutka> If you grep for %Q or %R you'll see the uses of these custom printf
2016-08-01 23:00:23 <jirutka> specifiers.  They are IMHO very useful, as well as being a cool
2016-08-01 23:00:23 <jirutka> feature of glibc.  How about adding them to musl libc?
2016-08-01 23:00:25 <jirutka> Alternatively I notice that gnulib has an (unimplemented, sadly)
2016-08-01 23:00:25 <jirutka> replacement register_printf_*, so that could be implemented which
2016-08-01 23:00:27 <jirutka> would fix portability to BSD too.
2016-08-01 23:00:27 <jirutka> It's a shame that ISO or POSIX doesn't standardize a way to do this.
2016-08-01 23:01:06 <jirutka> it seems that they kinda don’t understand what the standard means
2016-08-01 23:02:12 <jirutka> and this https://github.com/libguestfs/libguestfs/blob/a5bf0e7e6429bfe4edb7f4eb04db9833391ed3ea/daemon/format.c#L27-L32
2016-08-01 23:04:14 <^7heo> interesting
2016-08-01 23:04:30 <^7heo> and yeah, POSIX is really insufficient
2016-08-01 23:06:31 <^7heo> we should do a CEXPOSIX
2016-08-01 23:06:50 <^7heo> (Complete Extended POSIX)
2016-08-01 23:08:31 <jirutka> well, it is, but why this should be in std libc? they can use another lib that provides this functionality or write it yourself
2016-08-01 23:09:05 <^7heo> true
2016-08-01 23:09:43 <^7heo> my problem with posix is that it does not define the userland entry point
2016-08-01 23:09:57 <^7heo> C defines an enty point for programs
2016-08-01 23:10:33 <^7heo> but there is no definition of the logical userland entry point
2016-08-01 23:17:05 <^7heo> init s role is clear, but isn't posix either
2016-08-02 00:44:38 <boingolov> jirutka: you around?  just noticed something squirrely with those php*-couchbase extensions
2016-08-02 00:45:39 <jirutka> boingolov: yea?
2016-08-02 00:49:07 <boingolov> looks like the json module doens't get loaded by the default Makefile generated form phpize, so make test fails
2016-08-02 00:49:14 <boingolov> of course, I don't think make test does much useful anyway
2016-08-02 00:49:16 <boingolov> in this case
2016-08-02 00:49:55 <boingolov> I don't think they bothered to define unit tests for that pecl extension
2016-08-02 00:50:08 <boingolov> so since the tests are empty, the exit code is still 0
2016-08-02 00:51:00 <boingolov> kind of messy.  but I thought it curious, the part that seems to be failing is the default Makefile.global that ships with the php5-dev tools from what I can tell
2016-08-02 00:52:57 <boingolov> another thing I noticed, that couchbase.ini fails to load the extension since it depends on json.so loaded from json.ini .  I can work around this by prepending zz or similar to the couchbase.ini filename (i.e., zz_couchbase.ini)
2016-08-02 00:53:06 <boingolov> is there anything "official" for handling this?
2016-08-02 00:53:56 <jirutka> I have no idea :/
2016-08-02 00:53:59 <jirutka> I don’t use php
2016-08-02 00:54:22 <boingolov> fair enough
2016-08-02 00:55:55 <boingolov> I'll think on it some more but I'll have a followup PR sometime in the near future
2016-08-02 10:59:59 <peterj> how come the last week's release of Alpine didn't get the latest musl-libc version? It is still using 1.1.14.r10, instead of newer 1.1.14.r11 or latest in aports main 1.1.15.r0 ..
2016-08-02 11:00:27 <peterj> usually when does the musl version get bumped in stable release of Alpine?
2016-08-02 11:01:54 <jirutka> peterj: there’s no 1.1.14.r11 https://pkgs.alpinelinux.org/packages?name=musl&branch=&repo=&arch=&maintainer=
2016-08-02 11:03:01 <jirutka> peterj: latest 1.1.15.r0 is in edge and it wasn’t backported to the stable branch
2016-08-02 11:03:30 <peterj> jirutka: r11 is removed for some reason but it surely was there few days ago.. https://github.com/dotnet/coreclr/issues/5872#issuecomment-228870232
2016-08-02 11:03:37 <jomat> Hey… I tried to reboot my notebook yesterday after upgrading to 4.4.15-1-grsec, now nlplug-findfs segfaults after entering the luks passphrase. Am I the only one with this problem?
2016-08-02 11:05:17 <jirutka> peterj: https://github.com/alpinelinux/aports/commits/3.4-stable/main/musl/APKBUILD
2016-08-02 11:05:56 <jirutka> peterj: r11 was only in edge https://github.com/alpinelinux/aports/commit/8b4bc947a74e8ca71490014a622ae0d8e4e72bcc
2016-08-02 11:10:37 <peterj> jirutka: ok so there is an r11.. my question remains; why musl doesn't get bumped for new Alpine release? Do we have to wait for next major version of Alpine to get it in stable package?
2016-08-02 11:10:48 <jirutka> peterj: peterj I’ve requested backport to v3.4 https://bugs.alpinelinux.org/issues/5984
2016-08-02 11:11:25 <peterj> jirutka: thanks!
2016-08-02 11:12:13 <jirutka> peterj: usually only bug fixes are backported back to stable branches, but I’m not sure about this case
2016-08-02 11:12:43 <jirutka> clandmeter: do you know what policy do we have about updating packages like musl in stable branches?
2016-08-02 11:13:29 <peterj> jirutka: this was a bug fix: http://git.musl-libc.org/cgit/musl/commit/?id=384d103d94dba0472a587861f67d7ed6e8955f86 to which Void guys also reacted: https://github.com/voidlinux/void-packages/issues/4392
2016-08-02 11:13:39 <clandmeter> jirutka: i think fabled maintains is, not sure his policy.
2016-08-02 11:14:43 <jirutka> peterj: I know, r11 is a bug fix and it should be IMO backported, 1.1.15 is an update
2016-08-02 11:14:47 <clandmeter> but i think patch releases get applied to stable
2016-08-02 11:15:35 <jirutka> clandmeter: could you please resolve #5984 ? it seems that ncopa is on vacation or something
2016-08-02 11:17:08 <clandmeter> jirutka: i prefer not, fabled is around.
2016-08-02 11:17:18 <jirutka> okay
2016-08-02 11:17:45 <jirutka> jomat: nlplug-findfs is from mkinitfs and it there are some recent changes, so probably a bug http://git.alpinelinux.org/cgit/mkinitfs/log/
2016-08-02 11:18:09 <jirutka> jomat: could you please fill a bug report http://bugs.alpinelinux.org/projects/alpine/issues/new ?
2016-08-02 11:22:26 <jirutka> jomat: hm, from what version have you upgraded your system?
2016-08-02 11:23:11 <fabled> jirutka, we have not usually updated stable branch musl unless it's been security issue or major bug
2016-08-02 11:24:36 <fabled> even now the musl in 3.4-stable has the critical bug fixes cherry-picked
2016-08-02 11:24:59 <jirutka> fabled: do you consider https://github.com/alpinelinux/aports/commit/8b4bc947a74e8ca71490014a622ae0d8e4e72bcc to be a major bug?
2016-08-02 11:25:05 <jomat> jirutka: I don't know the old version… I'll try to reproduce that segfault in a vm later, right now I helped myself by adding "cryptsetup luksOpen /dev/dm-0 ar" somewhere near nlplug-findfs in /init
2016-08-02 11:25:33 <jomat> 
ACTION needs his notebook for $$ work now :-(

2016-08-02 11:25:45 <fabled> jirutka, yeah, i think it qualifies to be cherry-picked
2016-08-02 11:26:22 <fabled> is it committed upstream?
2016-08-02 11:27:13 <jirutka> jomat: okay, so just report it as a bug in the latest nlplug-finds (mkinitfs) and please also mention your workaround
2016-08-02 11:27:13 <fabled> it is
2016-08-02 11:28:43 <fabled> ok, i can go through the musl tree and cherry-pick relevant changes to 3.4-stable
2016-08-02 11:28:49 <fabled> seems there's one fix for edge too
2016-08-02 11:39:21 <fabled> jirutka, pushed to 3.4-stable
2016-08-02 11:39:30 <jirutka> fabled: thanks!
2016-08-02 11:39:45 <fabled> http://git.alpinelinux.org/cgit/aports/commit/main/musl?h=3.4-stable&id=584f9c9eea07c4530008b3335c4d355779e7a566
2016-08-02 11:45:51 <peterj> fabled: thanks. What is the difference between 3.4-stable branch and stable/3.4 ?
2016-08-02 11:46:30 <peterj> https://github.com/alpinelinux/aports/tree/3.4-stable/main/musl and
2016-08-02 11:46:31 <peterj> https://github.com/alpinelinux/aports/tree/stable/3.4/main/musl
2016-08-02 11:59:10 <clandmeter> hmm looks like somebody pushed that branch by accident? its not existing on official git repo.
2016-08-02 12:05:11 <clandmeter> peterj: it seems its done by accident.
2016-08-02 12:05:22 <clandmeter> please only use 3.4-stable
2016-08-02 12:07:44 <jirutka> clandmeter: yeah, barthalion pushed that branch, probably by accident, I’ve just removed it
2016-08-02 12:08:28 <clandmeter> yes ive seen it.
2016-08-02 12:08:51 <clandmeter> i wonder if i can block all users of push to it except git.a.o
2016-08-02 12:09:23 <clandmeter> to push...
2016-08-02 12:11:24 <peterj> Thanks! Is there a web page which shows the package build status?
2016-08-02 12:11:50 <peterj> as this is showing the old date: https://pkgs.alpinelinux.org/packages?name=musl&branch=v3.4&repo=&arch=&maintainer=
2016-08-02 12:12:04 <jirutka> peterj: build.alpinelinux.org
2016-08-02 12:12:21 <jirutka> peterj: give it few dozens of minutes
2016-08-02 12:12:48 <clandmeter> pkgs can be upmost 30 min off
2016-08-02 12:14:06 <leo-unglaub> https://marc.info/?l=openbsd-announce&m=147008907406976&w=2 the new feature from 2.4.2 is very nice! they added/updates the cipher groups
2016-08-02 12:14:16 <clandmeter> i still need to fix the flagged pager...
2016-08-02 12:14:29 <leo-unglaub> "secure" now only contains TLSv1.2+AEAD+PFS
2016-08-02 12:14:32 <leo-unglaub> i think thats awesome!
2016-08-02 12:15:06 <clandmeter> leo-unglaub: not playing with rust yet?
2016-08-02 12:15:31 <jirutka> clandmeter: the problem is that most of us have admin privileges in the GH org and as I know admins can do anything
2016-08-02 12:16:04 <clandmeter> and everybody needs it?
2016-08-02 12:16:17 <leo-unglaub> clandmeter: playing with it?
2016-08-02 12:16:23 <jirutka> leo-unglaub: hi! https://github.com/rust-lang/rust/issues/31322#issuecomment-235124632 ;)
2016-08-02 12:16:26 <leo-unglaub> i have mastered it a long time ago *g*
2016-08-02 12:16:37 <jirutka> leo-unglaub: and https://github.com/rust-lang/rust/issues/31322#issuecomment-236461594
2016-08-02 12:17:28 <jirutka> leo-unglaub: however, there are still issues… I can’t build rustc even using prebuilt rustc for musl on Alpine, this time because of some binutils problem
2016-08-02 12:17:48 <leo-unglaub> jirutka: yes, i have read the thread
2016-08-02 12:17:49 <jirutka> leo-unglaub: it’s really a nightmare… Julia was a piece of care comparing to this :(
2016-08-02 12:17:52 <leo-unglaub> but nice work on your part!
2016-08-02 12:18:49 <jirutka> leo-unglaub: I want to be finally working and officially supported; it’s just porting it from one libc to another, on the same platform, why the hell is it that complicated? :(
2016-08-02 12:19:18 <jirutka> leo-unglaub: s/care/cake/
2016-08-02 12:20:09 <leo-unglaub> i have no idea
2016-08-02 12:20:29 <leo-unglaub> propobly because the gnu people keep as much posix compat as i a am a java script developer ...
2016-08-02 12:20:38 <leo-unglaub> but the rust build system sucks in general
2016-08-02 12:20:44 <leo-unglaub> its way to complicated
2016-08-02 12:31:07 <peterj> can we get lldb out of testing in edge branch? it is working fine.
2016-08-02 12:32:17 <jirutka> peterj: it currently doesn’t have maintainer
2016-08-02 13:13:49 <peterj> jirutka: lttng-ust is also ready. lttng-tools is a separate package, which is still under testing.
2016-08-02 13:14:23 <peterj> lttng-ust should be moved to main, IMO.
2016-08-02 17:17:52 <peterj> is the build machine functioning normally? The build status is unchanged since couple of hours: http://build.alpinelinux.org/
2016-08-02 17:42:26 <leo-unglaub> peterj: deadbeef is a "larger" package on arm
2016-08-02 17:42:32 <leo-unglaub> it can take some time
2016-08-02 17:44:47 <peterj> leo-unglaub: reasonable, earlier I saw parallel builds in progress, so it seems like concurrency is on frits.
2016-08-02 17:45:13 <leo-unglaub> also possible
2016-08-02 17:45:31 <peterj> Does the status idle mean the build has completed?
2016-08-02 17:45:51 <leo-unglaub> idne means there is nothing todo
2016-08-02 17:46:01 <leo-unglaub> and that he is wairing for new tasks
2016-08-02 17:46:31 <peterj> status 'pulling git' for build-3-4-* is there for 3+ hours now.
2016-08-03 09:20:57 <jirutka> Build completed… finally! I’ve built rustc on Alpine! \o/
2016-08-03 09:24:24 <^7heo> jirutka: gg
2016-08-03 09:25:49 <ncopa> jirutka: congrats!
2016-08-03 09:26:07 <ncopa> tweet screenshot! i want retweet it
2016-08-03 09:30:22 <^7heo> :P
2016-08-03 09:32:46 <jirutka> okay, but first I’m gonna figure out how to generate dist snapshot
2016-08-03 09:33:05 <^7heo> same here.
2016-08-03 09:33:31 <^7heo> I want to be able to test that nlplug-findfs by myself, without relying on ncopa's availablility and free time.
2016-08-03 09:37:11 <ncopa> ^7heo: do you have an alpine box?
2016-08-03 09:37:18 <ncopa> even vm would work i think
2016-08-03 09:41:45 <^7heo> ncopa: I have 3
2016-08-03 09:41:52 <^7heo> ncopa: I could make 4 if needed.
2016-08-03 09:42:02 <ncopa> you only need one
2016-08-03 09:42:07 <ncopa> install the build deps
2016-08-03 09:42:09 <ncopa> and make
2016-08-03 09:42:17 <ncopa> then create block devices
2016-08-03 09:42:29 <ncopa> and run ./nlplug-findfs ...
2016-08-03 09:43:44 <^7heo> oh you mean to test the nlplug-findfs only
2016-08-03 09:43:50 <^7heo> not to make a release.
2016-08-03 09:45:16 <^7heo> ncopa: I know it sucks and I know I complained about it a LOT but...
2016-08-03 09:45:35 <^7heo> ncopa: how do you feel about using something like drone (or my custom CI solution instead, but then it's later) to test our stuff?
2016-08-03 09:46:17 <ncopa> i kinda prefer make the feature work before pushing it
2016-08-03 09:46:26 <ncopa> currently the detached header does not work
2016-08-03 09:48:20 <^7heo> ncopa: well, true, that is useful with a PR based workflow only.
2016-08-03 09:48:47 <jirutka> there’s something wrong… why the hell is /usr/bin/ldd symlink to ../../lib ?
2016-08-03 09:49:12 <^7heo> jirutka: /usr/bin/ldd -> ../../lib/ld-musl-x86_64.so.1 ?
2016-08-03 09:49:25 <jirutka> no,
2016-08-03 09:49:26 <jirutka> lrwxrwxrwx    1 root     root            10 Aug  3 11:47 /usr/bin/ldd -> ../../lib/
2016-08-03 09:49:28 <^7heo> jirutka: instead of /usr/bin/ldd -> /lib/ld-musl-x86_64.so.1 I presume?
2016-08-03 09:49:41 <ncopa> huh
2016-08-03 09:49:43 <^7heo> oh, weird.
2016-08-03 09:49:46 <ncopa> that must be a bug
2016-08-03 09:50:05 <^7heo> ncopa: we need more and better testing anyway, so I'll try to find a solution to that.
2016-08-03 09:50:07 <jirutka> I’ve tried apk fix musl-utils and stil the same
2016-08-03 09:50:12 <jirutka> so it looks like a bug in musl package
2016-08-03 09:50:20 <ncopa> yes it is
2016-08-03 09:50:21 <^7heo> ncopa: that works locally AND (more importantly) remotely (i.e. after push)
2016-08-03 09:51:18 <jirutka> should I report it on bugs.a.o?
2016-08-03 09:51:26 <ncopa> jirutka: yes please
2016-08-03 09:51:28 <^7heo> jirutka: I guess, it's easier to track,t aht way.
2016-08-03 09:51:30 <^7heo> wow
2016-08-03 09:51:35 <jirutka> probably caused by https://github.com/alpinelinux/aports/commit/f2891b7653cdaae4e478503024f5e4bcaa45395e
2016-08-03 09:51:36 <^7heo> s/t aht/ that/
2016-08-03 09:52:39 <ncopa> jirutka: definitively caused by that commit
2016-08-03 09:53:15 <^7heo> ncopa: ideally, how would you see testing done?
2016-08-03 09:53:36 <ncopa> ^7heo: in what context?
2016-08-03 09:53:43 <ncopa> you mean in the nlplug-findfs case?
2016-08-03 09:53:50 <^7heo> ncopa: in the context of contributing to Alpine.
2016-08-03 09:54:04 <^7heo> ncopa: atm we rely way too much on people's skills and focus.
2016-08-03 09:54:15 <^7heo> ncopa: for skills, I don't know, but focus is surely highly variable.
2016-08-03 09:54:28 <^7heo> ncopa: and in the nlplug-findfs case too.
2016-08-03 09:54:33 <ncopa> it would be nice with some automatic testing
2016-08-03 09:54:44 <^7heo> I know, that's what I'm talking about.
2016-08-03 09:54:54 <^7heo> And I'm "working" on a CI solution, that's why I bring it up.
2016-08-03 09:54:54 <ncopa> but i dont really know how or what
2016-08-03 09:54:57 <^7heo> Ok
2016-08-03 09:55:01 <^7heo> I'll try to find a way
2016-08-03 09:55:18 <ncopa> i know fabled is working on new build pipeline
2016-08-03 09:55:34 <ncopa> we talked about automatic testing too
2016-08-03 09:55:54 <jirutka> #5993
2016-08-03 09:58:05 <^7heo> but, anyway, the *only* way to prevent contributions that don't pass tests is the pre-receive hook on the repo.
2016-08-03 09:58:47 <^7heo> And that way we could ensure that everything always builds (at least in theory, because changing a dep that passes the tests would still potentially break the rdeps)
2016-08-03 09:59:10 <^7heo> fabled: care to sync with me for testing?
2016-08-03 10:02:26 <ncopa> ^7heo: are you only thinking of compile testing?
2016-08-03 10:02:56 <^7heo> ncopa: no, actually, but compile testing would be the first step.
2016-08-03 10:03:09 <^7heo> (since you need the new object to test it anyway)
2016-08-03 10:03:28 <^7heo> what I'm afraid of is the resouces that would be needed for that.
2016-08-03 10:03:45 <ncopa> same here
2016-08-03 10:03:48 <ncopa> i mean
2016-08-03 10:03:49 <^7heo> esp. if we use drone or my solution (in its current state) since they use docker for containerisation.
2016-08-03 10:04:06 <^7heo> LXC would at least provide a somewhat lighter solution
2016-08-03 10:04:17 <^7heo> But anyway
2016-08-03 10:04:22 <ncopa> lets say some users wants contribute with some modification of libreoffice
2016-08-03 10:04:24 <^7heo> that's another issue, we need power anyway.
2016-08-03 10:04:28 <ncopa> it takes ages to compile it
2016-08-03 10:04:30 <^7heo> ncopa: haha :D
2016-08-03 10:04:31 <ncopa> specially on arm
2016-08-03 10:04:35 <^7heo> ncopa: yeah, no but...
2016-08-03 10:04:48 <ncopa> so they just make a tiny change
2016-08-03 10:04:50 <^7heo> ncopa: let's just reject anything too big that doesn't come from GH :D
2016-08-03 10:04:53 <ncopa> spend 5 mins on it
2016-08-03 10:04:56 <^7heo> ncopa: so we don't pay for the testing :D
2016-08-03 10:05:02 <ncopa> exactly
2016-08-03 10:05:12 <^7heo> I mean
2016-08-03 10:05:26 <^7heo> travis's not fast, but at least we don't need to feed/maintain it.
2016-08-03 10:05:35 <ncopa> so far i kinda expect that the thing people send me is at a minimum compile tested
2016-08-03 10:05:42 <^7heo> so for stuff like small-ish software, it's fine.
2016-08-03 10:05:57 <^7heo> ncopa: yeah but no, it doesn't happen this way.
2016-08-03 10:06:08 <ncopa> that what i noticed
2016-08-03 10:06:18 <^7heo> and it's not always possible.
2016-08-03 10:06:21 <ncopa> people send garbage and expect us to spend time fixing it
2016-08-03 10:06:25 <fabled> ^7heo, i emailed alpine-devel recently
2016-08-03 10:06:35 <ncopa> and maintain it
2016-08-03 10:06:46 <^7heo> Consider barthalion and his armhf contributions.
2016-08-03 10:07:00 <^7heo> it's not easy to test anyway.
2016-08-03 10:07:05 <fabled> http://lists.alpinelinux.org/alpine-devel/5427.html
2016-08-03 10:07:28 <^7heo> fabled: Not sure I'm actually subscribed to that ML.
2016-08-03 10:07:55 <fabled> the last 2-3 paragraphs
2016-08-03 10:08:58 <RieSh2be> looks like he fixed it eventually
2016-08-03 10:09:12 <RieSh2be> I think crossbuild will be benefitial to everyone
2016-08-03 10:10:09 <fabled> abuild (git version) does cross building now. aports has limited packages supporting it. builder infra does not support that yet.
2016-08-03 10:10:15 <fabled> so heading that way
2016-08-03 10:10:17 <jirutka> and not just people around, also some members of our community sometimes sends garbage to build server without even minimum local testing…
2016-08-03 10:10:39 <ncopa> and sometimes minimum local testing does not catches things
2016-08-03 10:10:42 <^7heo> jirutka: +1
2016-08-03 10:11:00 <jirutka> sometimes not, but that’s not what I meant
2016-08-03 10:11:07 <fabled> ncopa, reminds me, i pushed abuild cross-build branch to master :)
2016-08-03 10:11:13 <ncopa> good
2016-08-03 10:11:25 <ncopa> fabled: time for another release?
2016-08-03 10:11:38 <fabled> i'd wait for set -e support still
2016-08-03 10:11:43 <ncopa> ok
2016-08-03 10:11:45 <fabled> someone was working on it
2016-08-03 10:12:26 <clandmeter> jirutka was thinking of working on it. not sure thats the same.
2016-08-03 10:12:53 <ncopa> i have other issue i need to look at: busybox gzip is really bad
2016-08-03 10:13:04 <jirutka> yeah, I thope that I’ll do it this weekend
2016-08-03 10:13:09 <fabled> ncopa, ?
2016-08-03 10:13:27 <fabled> compression ratio? or something else?
2016-08-03 10:13:35 <ncopa> compression ratio
2016-08-03 10:13:42 <ncopa> i am investigating
2016-08-03 10:13:49 <jirutka> ncopa: there’s the tweet https://twitter.com/jakubjirutka/status/760780645161377792
2016-08-03 10:14:31 <^7heo> anyway, testing ftw.
2016-08-03 10:14:38 <ncopa> +1
2016-08-03 10:14:44 <fabled> ncopa, even with -9 ?
2016-08-03 10:14:46 <jirutka> speaking about gzip, does checkapk work for anyone? it always prints some errors with invalig gzip magic etc.
2016-08-03 10:14:47 <^7heo> fabled: oooh, you ARE Timo!
2016-08-03 10:14:53 <^7heo> fabled: I didn't make the link yet.
2016-08-03 10:14:58 <fabled> fabled, yes :)
2016-08-03 10:15:00 <jirutka> heh:)
2016-08-03 10:15:11 <ncopa> fabled is not just TIMO
2016-08-03 10:15:18 <ncopa> he is *the* Timo :)
2016-08-03 10:15:21 <^7heo> :P
2016-08-03 10:15:21 <jirutka> XD
2016-08-03 10:15:25 <^7heo> ok ok :P
2016-08-03 10:15:33 <jirutka> the Timo we’re looking for!
2016-08-03 10:15:37 <^7heo> fabled: I should refer to you as "The Timo" from now on.
2016-08-03 10:15:43 <fabled> lol
2016-08-03 10:16:31 <^7heo> Sometimes the FOSS community is what causes you to lose it; sometimes it is all you needed to brighten you day.
2016-08-03 10:16:42 <^7heo> Today, fortunately, it's the latter.
2016-08-03 10:16:49 <ncopa> :)
2016-08-03 10:20:20 <ncopa> fabled: its busybox gzip -9 thats broke
2016-08-03 10:20:45 <ncopa> its creates files almost double size
2016-08-03 10:21:08 <ncopa> without the -9 it seems okish
2016-08-03 10:21:18 <ncopa> no. it seems good without -9
2016-08-03 10:24:03 <^7heo> would it be okay for you to have algibot use channel wide notices on #alpine-commits
2016-08-03 10:24:06 <^7heo> ?
2016-08-03 10:24:23 <ncopa> channel wide notices?
2016-08-03 10:24:30 <^7heo> yeah like
2016-08-03 10:25:22 <^7heo> at least this wouldn't register as "someone talking"
2016-08-03 10:25:26 <jirutka> okay, now I’ll try it with jemalloc enabled
2016-08-03 10:26:21 <^7heo> ncopa: and we could even report errors with normal messages, all the rest with notices.
2016-08-03 10:26:30 <^7heo> ncopa: that way we can see much more easily if there are errors.
2016-08-03 10:26:47 <^7heo> (without actively checking the chan)
2016-08-03 10:27:15 <clandmeter> that will trigger my irssi notifictionas. not sure im waiting for that.
2016-08-03 10:28:03 <ncopa> busybox gzip -9 is definitively broke
2016-08-03 10:28:18 <ncopa> $ ls -l /tmp/busybox.* | sprunge
2016-08-03 10:28:18 <ncopa> http://sprunge.us/GHha
2016-08-03 10:28:20 <^7heo> clandmeter: what?
2016-08-03 10:28:43 <clandmeter> that notice triggers my irrsi
2016-08-03 10:28:51 <^7heo> clandmeter: I'm using irssi and I'm requesting this exactly because I do *not* want to get notified that someone spoke on #alpine-commits for every successful push
2016-08-03 10:29:07 <^7heo> clandmeter: triggers? Any event triggers irssi.
2016-08-03 10:29:13 <^7heo> clandmeter: how is that different from talking?
2016-08-03 10:29:54 <clandmeter> normally i only get notified when ny nick is mentioned or in query
2016-08-03 10:30:06 <clandmeter> but this also seems to trigger my irssi
2016-08-03 10:30:26 <^7heo> clandmeter: can you please try to /notice #alpine-devel test ?
2016-08-03 10:31:12 <^7heo> clandmeter: shows as join/part/quit level to me.
2016-08-03 10:31:23 <^7heo> clandmeter: you have a custom irssi level configuration.
2016-08-03 10:31:31 <^7heo> clandmeter: maybe you want to change that.
2016-08-03 10:42:00 <^7heo> so as a perfect example as how we could use testing: watch #alpine-commits
2016-08-03 10:42:12 <^7heo> esp the last 20 mins.
2016-08-03 10:48:25 <RieSh2be> heh, so someone is fixing a build failure that nobody bothered to take a look at since at least yesterday, and you're complaining? that makes perfect sense
2016-08-03 10:50:59 <^7heo> RieSh2be: stop complaining about your interpretation.
2016-08-03 10:51:33 <^7heo> RieSh2be: I have not been complaining, I was just stating that our current workflow sometimes forces contributors to use the build servers as test benches.
2016-08-03 10:52:05 <RieSh2be> you should really take into account how something you said might sound like
2016-08-03 10:52:41 <^7heo> RieSh2be: No.
2016-08-03 10:53:02 <^7heo> RieSh2be: I should really not.
2016-08-03 10:53:39 <RieSh2be> up to you, if you like communities to shrink
2016-08-03 10:53:47 <^7heo> RieSh2be: or I'll end up reading everything a hundred times with different interpretations, states of awareness, use of different drugs, and what not.
2016-08-03 10:54:01 <^7heo> RieSh2be: I think it's with behaviors like you have that communities shrink.
2016-08-03 10:54:06 <RieSh2be> anyway, it's not my circus, so let's cut this pointless discussion
2016-08-03 10:54:07 <^7heo> RieSh2be: we do not need such a discussion.
2016-08-03 10:54:22 <^7heo> RieSh2be: glad that you agree.
2016-08-03 10:54:50 <RieSh2be> cheers :)
2016-08-03 11:31:19 <vkris> ncopa: would it ok to run http://tpaste.us/ApbW on current v3.4 builder + edge ?
2016-08-03 11:32:10 <vkris> any testing/ too ! any error here can be given 24hrs notice to move to unmaintained if cannot be fixed
2016-08-03 11:33:12 <vkris> grep -i testing /tmp/distverify.log
2016-08-03 11:33:21 <vkris> is what would show all issues if any
2016-08-03 11:35:10 <ncopa> vkris: what should that solve?
2016-08-03 11:35:40 <vkris> if upstream is unavailable how is it still building ?
2016-08-03 11:35:59 <ncopa> its cached
2016-08-03 11:36:14 <vkris> we need to make sure distfiles has it cached
2016-08-03 11:36:19 <vkris> ok then
2016-08-03 11:38:55 <vkris> ncopa: once the builder say 3.4 does finish building what happens to <path>/to/packages/<arch>/files ?
2016-08-03 11:39:16 <vkris> pushed to nl.a.o ?
2016-08-03 11:39:25 <vkris> and then deleted ?
2016-08-03 11:39:38 <ncopa> old files deleted
2016-08-03 11:39:52 <ncopa> then pushed with rsync to rsync.a.o (which points to fr.a.o currently)
2016-08-03 11:40:03 <vkris> does it mean for v3.4.1 the folder is all clean ?
2016-08-03 11:40:46 <vkris> or say everything from v3.4 upto v3.4.1
2016-08-03 11:42:00 <vkris> if its cleaned after every version/git-tag then there is already a simpler way to have updates folder in nl.a.o
2016-08-03 11:43:49 <vkris> ok, I would outline and add to bugs.a.o
2016-08-03 12:12:39 <vkris> ncopa: #5999
2016-08-03 12:13:16 <^7heo> wow, 6k bugs soon!
2016-08-03 12:19:44 <vkris> ^7heo: care to add another to cut that ribbon ;)
2016-08-03 12:24:53 <^7heo> well, jirutka wanted to report a bug earlier ;)
2016-08-03 12:28:07 <clandmeter> #6000
2016-08-03 12:29:12 <^7heo> clandmeter: maybe join #alpine-offtopic then?
2016-08-03 12:30:02 <vkris> http://tpaste.us/3gY6
2016-08-03 12:30:11 <vkris> these I could not verify
2016-08-03 12:30:25 <vkris> on testing/
2016-08-03 12:35:29 <vkris> combined main/community/testing sources are ~3DVDs, bravo!
2016-08-03 12:35:32 <vkris> what is that debian equivalent to etch, lenny ?
2016-08-03 12:37:24 <vkris> looks like Etch
2016-08-03 12:38:36 <vkris> who plays games on AL, xonotic is ~1GB ;)
2016-08-03 13:05:09 <tx> lol someone made it an actual bug
2016-08-03 14:08:09 <Mo0O> hi there
2016-08-03 14:08:48 <Mo0O> it looks like the alpine golang pkg is broken, all standard library packages are missing
2016-08-03 14:08:57 <Mo0O> do you confirm that?
2016-08-03 14:10:22 <RieSh2be> hello, 3.4 or edge?
2016-08-03 14:10:45 <Mo0O> RieSh2be: edge
2016-08-03 14:11:51 <Mo0O> go1.7rc3
2016-08-03 14:12:00 <ncopa> hum
2016-08-03 14:12:35 <ncopa> ok, will have a look at that. if i forget, then please file a bug for it
2016-08-03 14:12:40 <ncopa> on bugs.a.o
2016-08-03 14:12:48 <ncopa> i'm working on busybox gzip atm
2016-08-03 14:12:57 <ncopa> gzip -9 is broken
2016-08-03 14:13:04 <Mo0O> on a fresh install, trying a `go get` for any random package tries to install package like `runtime/internal/sys`, for example
2016-08-03 14:13:05 <ncopa> well all the levels are wrong
2016-08-03 14:13:24 <Mo0O> ok
2016-08-03 14:13:32 <Mo0O> thanks ncopa
2016-08-03 14:29:47 <nmeum> the go package looks pretty broken atm, also stuff that should be shipped with go-cross is currently shipped with go
2016-08-03 14:31:52 <ncopa> i'd be happy if someone with go experience could help fixing that
2016-08-03 14:32:01 <ncopa> go 1.7 should be out soonish
2016-08-03 14:32:21 <ncopa> go 1.6 has a broken memory allocator
2016-08-03 14:33:08 <ncopa> which does not work well with ASLR
2016-08-03 14:33:34 <nmeum> I would be happy to help out but I am currently somewhat busy, if nobody else fixes it in the next few days I might be able to take a look at it
2016-08-03 14:37:07 <^7heo> ncopa: among other broken things.
2016-08-03 21:45:23 <kazblox_> damn ncopa left
2016-08-04 07:39:49 <ncopa> new binutils is out
2016-08-04 07:40:08 <ncopa> there is a --enable-relro that enables -z relro by default
2016-08-04 07:40:11 <ncopa> nice
2016-08-04 08:24:44 <Mo0O> hi
2016-08-04 08:25:06 <ncopa> hi
2016-08-04 08:26:53 <Mo0O> ncopa: hello, I've dig a little bit yesterday evening about go1.7rc3, it appears that all stdlib pkg are available and installed, but all *.a compiled files looks compiled for a wrong arch, at least they doesn't fit amd64, I'll continue to dig this evening
2016-08-04 08:32:59 <ncopa> ok
2016-08-04 09:16:06 <jirutka> hi all
2016-08-04 09:16:51 <jirutka> ncopa: I can’t believe how many favs I got on the tweet about Rust and Alpine… 69! https://twitter.com/jakubjirutka/status/760780645161377792
2016-08-04 09:45:37 <ncopa> jirutka: well deserved, imho :)
2016-08-04 09:47:25 <jirutka> ncopa: well, I don’t think so in this case, the hardest part made japaric from Rust: https://gist.github.com/japaric/52b8816a4c86f5a4699bcc50ebc3e020
2016-08-04 10:40:06 <jirutka> omg, llvm build system is awful… it seems that there’s no way how to change location of includedir, sharedir etc, only common prefix
2016-08-04 10:40:49 <jirutka> it seems that less evil is to install it into /usr/lib/llvm-$ver/{bin,include,lib,share} :/
2016-08-04 10:42:15 <^7heo> jirutka: SYMLINK ALL THE THINGS!
2016-08-04 11:28:20 <jirutka> ^7heo: that’s not necessary, only for bin files
2016-08-04 13:38:54 <fcolista> what's up to the builders ?
2016-08-04 13:40:24 <clandmeter> fcolista: i think ncopa is struggling with busybox
2016-08-04 13:40:42 <fcolista> it's due to binutils upgrade?
2016-08-04 13:40:49 <clandmeter> i have no clue
2016-08-04 13:40:58 <clandmeter> i have my own issues :|
2016-08-04 13:41:02 <fcolista> k
2016-08-04 13:41:18 <fcolista> the important thing is that someone is working on it
2016-08-04 13:44:21 <clandmeter> fcolista: im not sure, im just guessing
2016-08-04 13:44:34 <fcolista> oh..ok
2016-08-04 13:46:23 <ncopa> whats wrong with build boxes?
2016-08-04 13:55:30 <fcolista> ncopa, when i pushed corebird it tooks ~1 hours before the build was completed, and build.alpinelinux.org showed "pulling git"
2016-08-04 13:57:42 <ncopa> hum
2016-08-04 13:57:45 <ncopa> something is wrong
2016-08-04 13:58:16 <ncopa> building v3.4.0
2016-08-04 13:58:24 <fcolista> definetly
2016-08-04 13:58:25 <fcolista> sh: local: line 103: not in a function
2016-08-04 13:58:25 <fcolista> sh: local: line 103: not in a function
2016-08-04 13:58:25 <fcolista> sh: eval: line 1: syntax error: unexpected ")"
2016-08-04 13:58:25 <fcolista> ERROR: /home/buildozer/aports/main: Failed to open apkbuilds
2016-08-04 13:58:59 <ncopa> ha
2016-08-04 13:59:07 <ncopa> busybox 1.25
2016-08-04 13:59:10 <ncopa> thanks...
2016-08-04 13:59:11 <ncopa> ok
2016-08-04 14:18:43 <jirutka> fcolista: is it really related to busybox upgrade? this looks like someone messed some shell script
2016-08-04 14:18:58 <ncopa> i think its related bb upgrade
2016-08-04 14:19:11 <ncopa> and yes someone messed up some shell script
2016-08-04 14:19:20 <jirutka> aha, which one?
2016-08-04 14:19:30 <ncopa> i think previous bb was more forgiving
2016-08-04 14:19:40 <ncopa> new bb seems to be more strict
2016-08-04 14:19:41 <jirutka> so changed behaviour in ash?
2016-08-04 14:19:49 <ncopa> i am trying to find the script
2016-08-04 14:19:52 <ncopa> looks like that yes
2016-08-04 14:19:59 <jirutka> isn’t that configurable?
2016-08-04 14:20:07 <ncopa> not that i know
2016-08-04 14:21:46 <ncopa> what is weird is that i cannot reproduce locally
2016-08-04 14:26:44 <ncopa> ok, i found it
2016-08-04 14:26:46 <ncopa> its u-boot
2016-08-04 14:26:53 <jirutka> ncopa: `local` doesn’t work anymore?! https://github.com/alpinelinux/aports/commit/8450b7e4e4c242f5edff093d96dfb7f94308fe65
2016-08-04 14:27:12 <ncopa> i thikn it only works in a function
2016-08-04 14:27:26 <jirutka> yes, that’s right
2016-08-04 14:27:44 <ncopa> now it will choke when you use 'local' in global scope
2016-08-04 14:28:00 <jirutka> aha, and this is not inside a function… hm, how did it worked before?
2016-08-04 14:28:20 <ncopa> busybox ash just ignored it before i think
2016-08-04 14:28:26 <ncopa> now it will error
2016-08-04 14:29:45 <ncopa> aha
2016-08-04 14:29:52 <ncopa> hm
2016-08-04 14:30:00 <ncopa> i need arm to test it
2016-08-04 14:37:58 <ncopa> ok
2016-08-04 14:38:04 <ncopa> i think its ok nw
2016-08-04 14:40:19 <clandmeter> nice
2016-08-04 14:40:32 <clandmeter> ncopa: have time to look at qt? or should i open a bug?
2016-08-04 14:50:53 <jirutka> great, paxmark is also broken
2016-08-04 14:51:03 <jirutka> the same problem, local at top-level
2016-08-04 14:52:46 <ncopa> ok
2016-08-04 14:53:33 <jirutka> I’m just preparing a patch… should I send it or have you already done it? :)
2016-08-04 14:53:44 <ncopa> i'm almost done
2016-08-04 14:53:47 <jirutka> okay
2016-08-04 14:55:47 <jirutka> it’s also weird that it didn’t halted the build…
2016-08-04 14:56:33 <jirutka> paxmark failed, so it should return non-zero status and hence build() return non-zero… but it apparently did not, b/c it failed later, in tests
2016-08-04 15:00:23 <jirutka> ncopa: can I somehow tell algibot to retry some specific package/commit?
2016-08-04 15:01:30 <jirutka> ncopa: or what exactly `retry master` do?
2016-08-04 15:02:55 <jirutka> ncopa: when will be the fixed paxmark used on build servers? it’s still using the old version
2016-08-04 15:07:27 <jirutka> ncopa: this also doesn’t look good https://travis-ci.org/alpinelinux/aports/builds/149781662#L181
2016-08-04 15:10:02 <^7heo> jirutka: did you send the rust aport in?
2016-08-04 15:10:17 <jirutka> ^7heo: not yet
2016-08-04 15:10:41 <^7heo> do you know when you will?
2016-08-04 15:10:43 <jirutka> ^7heo: I have to fix llvm3.7, that was completely unusable…
2016-08-04 15:10:49 <jirutka> ^7heo: soon
2016-08-04 15:10:56 <^7heo> ah yeah
2016-08-04 15:10:58 <^7heo> makes sense
2016-08-04 15:13:01 <fcolista> umh
2016-08-04 15:13:01 <fcolista> apk upgrade
2016-08-04 15:13:01 <fcolista> (1/3) Upgrading busybox (1.25.0-r0 -> 1.25.0-r1)
2016-08-04 15:13:02 <fcolista> Executing busybox-1.25.0-r1.post-upgrade
2016-08-04 15:13:02 <fcolista> (2/3) Upgrading busybox-suid (1.25.0-r0 -> 1.25.0-r1)
2016-08-04 15:13:02 <fcolista> (3/3) Upgrading paxmark (0.8-r1 -> 0.8-r2)
2016-08-04 15:13:04 <fcolista> Executing busybox-1.25.0-r1.trigger
2016-08-04 15:13:06 <fcolista> Segmentation fault
2016-08-04 15:13:13 <^7heo> ooh, neat
2016-08-04 15:13:35 <^7heo> that's why I always use -s
2016-08-04 15:13:42 <^7heo> for some reason, it never segfaults with -s
2016-08-04 15:13:45 <^7heo> 
ACTION hides

2016-08-04 15:14:01 <jirutka> upgrade of busybox revealed, that some people don’t know that `local` can be used only inside a function, so we have some scripts broken now :/ one of them is paxmark, we’ve alredy fixed that, but now I have to wait until it arrive to the build servers, so I can trigger rebuild of llvm…
2016-08-04 15:14:20 <^7heo> meh
2016-08-04 15:14:31 <jirutka> what do you mean, apk upgrade -s ?
2016-08-04 15:14:47 <ncopa> fcolista: i cannot reproduce that
2016-08-04 15:14:56 <ncopa> fcolista: what does dmesg say?
2016-08-04 15:15:22 <ncopa> which process is segfaulting
2016-08-04 15:15:34 <fcolista> ncopa:
2016-08-04 15:15:35 <fcolista> grsec: Segmentation fault occurred at 0000000000000800 in /bin/busybox[busybox:24796] uid/euid:0/0 gid/egid:0/0, parent /var/cache/misc/busybox-1.25.0-r1.trigger[busybox-1.25.0-:24795] uid/euid:0/0 gid/egid:0/0
2016-08-04 15:15:35 <fcolista> [4422912.521076] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /bin/busybox[busybox:24796] uid/euid:0/0 gid/egid:0/0, parent /var/cache/misc/busybox-1.25.0-r1.trigger[busybox-1.25.0-:24795] uid/euid:0/0 gid/egid:0/0
2016-08-04 15:16:02 <^7heo> jirutka: yes
2016-08-04 15:16:21 <^7heo> jirutka: 9bf92fec7ff2f532a6a8bfcfda9b7c463ac932ac
2016-08-04 15:16:37 <jirutka> hm, resource overstep, this is sometimes related to PaX
2016-08-04 15:17:24 <mitchty> jirutka: did I miss something in the llvm3.7 port? it was a bit of a hack to be sure
2016-08-04 15:17:31 <ncopa> fcolista: can you please try run: sh -x aports/main/busybox/busybox.trigger
2016-08-04 15:17:42 <ncopa> and see if it segfaults
2016-08-04 15:17:43 <jirutka> ^7heo: what about 9bf92fec7ff2f532a6a8bfcfda9b7c463ac932ac?
2016-08-04 15:18:02 <^7heo> jirutka: check your query
2016-08-04 15:19:44 <ncopa> fcolista: i think it is either depmod or /bin/busybox --install -s that makes it segfault, but i dont know which
2016-08-04 16:25:56 <ncopa> stateless: problem with g++ 6.x, fortify-headers and libreoffice: http://tpaste.us/A8mW
2016-08-04 16:26:01 <ncopa> i dont know why it happens
2016-08-04 16:32:15 <stateless> ncopa, you've only seen this with libreoffice?
2016-08-04 16:32:36 <stateless> on g++ 6.x
2016-08-04 16:35:26 <ncopa> yes
2016-08-04 16:36:03 <ncopa> i think c++ ships their own C headers for stdlib.h
2016-08-04 16:36:11 <ncopa> but i dont remember where i read it
2016-08-04 16:38:02 <ncopa> https://gcc.gnu.org/gcc-6/porting_to.html
2016-08-04 16:38:59 <ncopa> more specific: https://gcc.gnu.org/gcc-6/porting_to.html#stdlib.h
2016-08-04 16:46:09 <ncopa> i have not been able to create a reproducer
2016-08-04 18:33:27 <iz> nnn/win close
2016-08-04 19:10:23 <XgF> hey ncopa, I encountered an issue with update-ca. You added a fallback for sendfile failures but check the return value, not errno: http://git.alpinelinux.org/cgit/aports/commit/main/ca-certificates/update-ca.c?id=447c5aa36c467893598124fc0899c7c0bdbaf957
2016-08-04 19:15:35 <natoka> hi
2016-08-04 19:17:20 <natoka> i'm trying to create a package for bareos that includes debug symbols, because i need to debug it
2016-08-04 19:18:20 <natoka> i've tried to find some doc about apk in that direction, but i've not been succesful
2016-08-04 19:19:03 <natoka> any hints how to prevent abuild from stripping debug symbols?
2016-08-04 19:20:32 <kazblox__> ncopa
2016-08-04 19:20:52 <kazblox__> https://bugs.alpinelinux.org/issues/5906
2016-08-04 19:20:53 <kazblox__> turns out
2016-08-04 19:20:56 <kazblox__> its libwfb
2016-08-04 19:21:27 <kazblox__> that crashes X on older cards
2016-08-04 19:25:10 <RieSh2be> natoka: hi
2016-08-04 19:25:18 <RieSh2be> natoka: add $pkgname-dbg to subpackages
2016-08-04 19:57:07 <natoka> RieSh2be: thx
2016-08-05 07:05:29 <ncopa> XgF: good catch. do you have any suggestion how i can reproduce it?
2016-08-05 07:05:38 <ncopa> so i can test that a fix actually works
2016-08-05 08:38:27 <nindustries> Hi guys, so php5-pgsql pdo driver is broken, aswell as php7. Bug report is https://bugs.alpinelinux.org/issues/5761 . Still no replies. Ideas?
2016-08-05 08:38:33 <nindustries> php7-pgsql *
2016-08-05 08:48:40 <ncopa> nindustries: i the the bug report is somewhat misleading
2016-08-05 08:49:02 <ncopa> ldd /path/to/plugin.so is not expected to work
2016-08-05 08:49:37 <ncopa> need the exact error
2016-08-05 09:13:18 <ncopa> nindustries: i am pretty confident that php5-pdo_pgsql works.
2016-08-05 09:14:26 <nindustries> hm
2016-08-05 09:14:29 <nindustries> Then I am confused
2016-08-05 09:15:13 <nindustries> well, my actual error is: Unable to load dynamic library '/usr/lib/php5/modules/pdo_pgsql.so' - Error relocating /usr/lib/php5/modules/pdo_pgsql.so: pdo_handle_error:  │ `slikts
2016-08-05 09:15:14 <nindustries>  9.#openvpn        │                     | symbol not found in Unknown on line 0
2016-08-05 09:16:01 <nindustries> ncopa: ^
2016-08-05 09:16:33 <nindustries> And I don't see why ldd wouldn't work
2016-08-05 09:16:53 <ncopa> because those sybols are provided by php binary
2016-08-05 09:17:02 <ncopa> those functions are in /usr/bin/php
2016-08-05 09:17:07 <^7heo> moin ncopa
2016-08-05 09:17:19 <ncopa> the ph pbinary will dlopen(/path/to/module.so)
2016-08-05 09:18:21 <nindustries> hm
2016-08-05 09:18:43 <nindustries> Any idea about the symbol not found thingy ?
2016-08-05 09:18:52 <ncopa> yes
2016-08-05 09:18:59 <ncopa> the symbols are provided by /usr/bin/php
2016-08-05 09:19:09 <ncopa> to test: nm -D /usr/bin/php
2016-08-05 09:19:33 <nindustries> Then I don't see why I get that error at all
2016-08-05 09:19:42 <ncopa> oh that other error
2016-08-05 09:20:07 <nindustries> yeah
2016-08-05 09:20:16 <ncopa> can you help me reproduce it?
2016-08-05 09:20:30 <ncopa> i dont get that error here
2016-08-05 09:20:41 <nindustries> sure, I can give you my dockerfile
2016-08-05 09:21:40 <ncopa> i'm closing #5761
2016-08-05 09:22:07 <ncopa> please create new issue with the real error message
2016-08-05 09:22:17 <ncopa> ok?
2016-08-05 09:22:42 <ncopa> i will try help you fix it
2016-08-05 09:22:49 <nindustries> Thanks!
2016-08-05 09:24:43 <nindustries> sec, reproducing it atm
2016-08-05 09:24:51 <nindustries> I was switching back over to debian :/
2016-08-05 09:25:09 <ncopa> understandable
2016-08-05 09:28:49 <nindustries> but debian containers are massive tough
2016-08-05 09:28:58 <ncopa> i knkow :)
2016-08-05 09:38:08 <nindustries> omg.
2016-08-05 09:38:11 <nindustries> so err
2016-08-05 09:38:18 <nindustries> Now I can't reproduce it
2016-08-05 09:39:36 <nindustries> sec
2016-08-05 09:40:44 <nindustries> sigh
2016-08-05 09:40:44 <ncopa> it might happen if you mix stable with edge repos
2016-08-05 09:40:49 <nindustries> Im on stable tough
2016-08-05 09:41:05 <nindustries> I was thinking because i did a apk add apache2 and then a php5-apache2
2016-08-05 09:41:06 <clandmeter> we have mgical customer support, issues just disapear :)
2016-08-05 09:43:03 <ncopa> it is quite possible that there was a real error that got fixed with a rebuild or so
2016-08-05 09:45:45 <nindustries> yeah, perhaps
2016-08-05 09:47:27 <nindustries> Something unrelated; are there known issues with chrooting inside a container ?
2016-08-05 09:47:48 <ncopa> should not be problem
2016-08-05 09:47:51 <nindustries> For example, I have a openvpn server that chroots to /etc/openvpn. But it can never execute any script in /etc/openvpn/scripts
2016-08-05 09:48:01 <nindustries> When not chrooting and passing the absolute path, it works
2016-08-05 09:48:32 <nindustries> e.g. client-connect scripts/login.py
2016-08-05 09:49:01 <ncopa> in chroot it needs to start /scripts/ and not /etc/openvpn/scripts
2016-08-05 09:49:57 <ncopa> oh
2016-08-05 09:50:00 <ncopa> the scripts
2016-08-05 09:50:10 <ncopa> they are like #!/bin/sh ?
2016-08-05 09:50:28 <ncopa> then you need /etc/openvpn/bin/sh to exist as well
2016-08-05 09:50:33 <nindustries> #!/usr/bin/python3
2016-08-05 09:50:41 <nindustries> oh
2016-08-05 09:50:51 <ncopa> that does not exist when you are chroot in /etc/openvpn :)
2016-08-05 09:50:59 <nindustries> You, my lord, are a hero
2016-08-05 09:51:07 <ncopa> that said
2016-08-05 09:51:15 <nindustries> What's the best practice? Would a symlink work?
2016-08-05 09:51:25 <ncopa> i dont see any point with chrooting when you have container
2016-08-05 09:51:39 <ncopa> i would not bother chroot at all
2016-08-05 09:51:43 <nindustries> meh, so they can't touch the keys
2016-08-05 09:53:01 <ncopa> symlink wouldnt help you
2016-08-05 09:53:13 <nindustries> I tried copying the executable
2016-08-05 09:53:19 <nindustries> Trying*
2016-08-05 09:53:22 <ncopa> and you need all the libs too
2016-08-05 09:53:26 <nindustries> hm
2016-08-05 09:53:33 <ncopa> hardlinks might work
2016-08-05 09:53:52 <ncopa> but its much fuzz for little gain imho
2016-08-05 09:55:05 <ncopa> what might work is: apk add --initdb --root /vpnroot python3
2016-08-05 09:55:14 <ncopa> then copy your script to /vpnroot/
2016-08-05 09:55:19 <ncopa> and chroot into there
2016-08-05 09:55:24 <nindustries> initdb ?
2016-08-05 09:55:39 <ncopa> you will likely also need to mount --bind /proc /vpnroot/proc
2016-08-05 09:55:54 <ncopa> create new apk db
2016-08-05 09:55:57 <nindustries> brb
2016-08-05 09:55:57 <ncopa> as a new root
2016-08-05 10:28:48 <jirutka> omg, these poor people writing enterprise Java crap… https://github.com/gliderlabs/docker-alpine/issues/11#issuecomment-237813342
2016-08-05 10:29:44 <jirutka> he needs a stable solution and so he installs unofficial glibc package on Alpine and OracleJDK… totally makes sense
2016-08-05 11:17:42 <kazblox> ncopa: ping
2016-08-05 11:19:06 <ncopa> kazblox: pong
2016-08-05 11:20:15 <kazblox> ncopa: https://bugs.alpinelinux.org/issues/5906 so apparently my crashing problem with X is wfb
2016-08-05 11:21:24 <ncopa> i wonder why we add wfb in the first place?
2016-08-05 11:21:24 <kazblox> somehow wfb causes X to not generate the screen keys
2016-08-05 11:21:51 <ncopa> i suppose some of the driver needs wfb
2016-08-05 11:22:28 <ncopa> we should probaly remove wfb in the default config
2016-08-05 11:23:00 <kazblox> it caused multiple problems on some other machines according to bug reports
2016-08-05 11:23:08 <kazblox> including virtualbox
2016-08-05 11:24:55 <nindustries> ncopa: thanks for the suggestion, but it complains about missing gcc now
2016-08-05 11:25:54 <ncopa> kazblox: i saw
2016-08-05 11:26:03 <ncopa> nindustries: what is complaining?
2016-08-05 11:27:46 <ncopa> kazblox: i think i need some suggestion how to fix it
2016-08-05 11:28:00 <ncopa> i suppose that there are some drivers that needs wfb
2016-08-05 11:28:16 <nindustries> Error loading shared library libpq.so.5:
2016-08-05 11:28:51 <ncopa> kazblox: we should probably have a separate /etc/X11/xorg.conf.d/00-$driver.conf with the exact deps
2016-08-05 11:28:53 <nindustries> sec
2016-08-05 11:29:01 <ncopa> which is shipped with each driver
2016-08-05 11:29:24 <kazblox> nah not really, wfb is a wrapped framebuffer mainly for nouveau which is not needed
2016-08-05 11:29:37 <kazblox> "Enable or disable wfb, only affects nv50+. Useful for some legacy configurations where high rendering latency is perceived. Default: wfb is disabled."
2016-08-05 11:29:53 <ncopa> ok
2016-08-05 11:30:01 <ncopa> so maybe we just disable it
2016-08-05 11:30:14 <ncopa> and if someone needs they'll have to enable it
2016-08-05 11:30:25 <kazblox> yeah
2016-08-05 11:30:35 <kazblox> not that hard to add an xorg module entry
2016-08-05 11:31:18 <ncopa> alternatively we could add it to the nv driver
2016-08-05 11:32:25 <nindustries> ncopa: i think i'll just create a user that only has access to the script dir
2016-08-05 11:32:44 <kazblox> woops
2016-08-05 12:29:57 <ncopa> hum
2016-08-05 12:30:23 <ncopa> seems like dhcp client does not manage to set route now
2016-08-05 12:30:29 <ncopa> with busybox 1.25 upgrade
2016-08-05 12:49:10 <^7heo> ncopa: did you already fix nlplug-findfs's leak?
2016-08-05 12:49:17 <^7heo> ncopa: (fd leak, not memleak)
2016-08-05 12:49:21 <ncopa> nope
2016-08-05 12:49:24 <^7heo> Ok
2016-08-05 12:49:35 <^7heo> Then my goal for this week end is to fix that and the deported header.
2016-08-05 12:49:37 <^7heo> let's see.
2016-08-05 12:49:47 <ncopa> need to fix busybox depmod
2016-08-05 12:49:49 <ncopa> asap
2016-08-05 12:49:53 <ncopa> also
2016-08-05 12:49:55 <^7heo> ok?
2016-08-05 12:50:05 <^7heo> can you do it or should I try if I have time left over?
2016-08-05 12:50:13 <ncopa> ip route add 0.0.0.0/0 ... does not seem to work
2016-08-05 12:50:16 <^7heo> (I need the nlplug-findfs with deported header asap, so...)
2016-08-05 12:50:28 <^7heo> ncopa: does it work with default?
2016-08-05 12:50:33 <^7heo> I mean, 'default'
2016-08-05 12:50:44 <ncopa> ^7heo: would be great if you could work on nlplug-findfs
2016-08-05 12:50:51 <ncopa> i have a wild guess what might be wrong
2016-08-05 12:51:06 <ncopa> it will auto detect the header with blkkid
2016-08-05 12:51:22 <^7heo> ok
2016-08-05 12:51:29 <ncopa> i need to check if it tries to autostart the cryptsetup
2016-08-05 12:51:32 <ncopa> it should not
2016-08-05 12:51:37 <^7heo> in what event?
2016-08-05 12:51:45 <ncopa> if it finds LUKS header
2016-08-05 12:51:57 <ncopa> i got promoted for password twice iirc
2016-08-05 12:52:03 <^7heo> oh
2016-08-05 12:52:07 <^7heo> that's peculiar.
2016-08-05 12:52:16 <^7heo> Thanks for your input
2016-08-05 12:52:23 <ncopa> might also be some logic is wrong
2016-08-05 12:52:25 <^7heo> I unfortunately didn't save how test it.
2016-08-05 12:52:26 <ncopa> i dunno
2016-08-05 12:52:36 <^7heo> so I hope I won't spend too much time finding that out ;)
2016-08-05 12:52:42 <ncopa> you create 2 block devices
2016-08-05 12:52:49 <ncopa> loop0 loop1
2016-08-05 12:52:51 <ncopa> for example
2016-08-05 12:52:59 <ncopa> losetup a.img
2016-08-05 12:53:00 <^7heo> but I mean, I have a laptop I can test with.
2016-08-05 12:53:13 <^7heo> are you talking about reproducible setup?
2016-08-05 12:53:19 <ncopa> you need to test the nlplug-findfs without reboot
2016-08-05 12:53:23 <^7heo> (like, in a chroot?)
2016-08-05 12:53:26 <ncopa> no
2016-08-05 12:53:35 <ncopa> just run it from build dir
2016-08-05 12:53:36 <^7heo> oh yeah you don't need chroot.
2016-08-05 12:53:38 <^7heo> you're right.
2016-08-05 12:54:00 <ncopa> and pass what devices or UUID it shoudl look for
2016-08-05 12:54:03 <jirutka> ncopa: maybe you should read this https://github.com/gliderlabs/docker-alpine/issues/11#issuecomment-237834773
2016-08-05 12:54:22 <^7heo> ncopa: how do you invoke nlplug-findfs then?
2016-08-05 12:54:32 <^7heo> ./nlplug-findfs /dev/sda1?
2016-08-05 12:55:14 <ncopa> create loopdevices so you dont mess with the mounted devs
2016-08-05 12:55:18 <^7heo> sure.
2016-08-05 12:55:20 <ncopa> losetup a.img
2016-08-05 12:55:24 <ncopa> losetup b.img
2016-08-05 12:55:35 <^7heo> yeah sorry, I meant, the invocation of nfplug-findfs in general
2016-08-05 12:55:49 <^7heo> I didn't mean that I'll test with my /dev/sda ;)
2016-08-05 12:55:50 <ncopa> use loop0 as cryptdev and loop1 as header
2016-08-05 12:55:55 <^7heo> yeah yeah clearly.
2016-08-05 12:56:02 <ncopa> then you create crypt
2016-08-05 12:56:02 <jirutka> I hope that my response is right, it required few cycles of auto-censoring to avoid notes about Java idiots writing crappy incompatile shits
2016-08-05 12:56:09 <^7heo> I'm just asking about what parameters does nlplug-findfs expects
2016-08-05 12:56:29 <ncopa> $ nlplug-findfs -h | tpaste
2016-08-05 12:56:29 <ncopa> http://tpaste.us/2zJw
2016-08-05 12:56:34 <^7heo> oh
2016-08-05 12:56:35 <jirutka> the worst is that I quite know these sort of people… they are mostly really idiots that don’t know what are they doing
2016-08-05 12:56:39 <^7heo> okay I didn't expect a -h
2016-08-05 12:56:40 <^7heo> thanks
2016-08-05 12:56:43 <jirutka> because ENTERPRISE
2016-08-05 12:58:01 <ncopa> jirutka: we still need to treat them with respect. thats the challenge :)
2016-08-05 12:58:27 <ncopa> so something like: "sorry we cannot help you" instead of "are you acomplete moron?"
2016-08-05 12:58:28 <ncopa> :)
2016-08-05 12:58:40 <^7heo> ncopa: yeah, it's really challenging to treat the devs who write shit with respect.
2016-08-05 12:58:52 <^7heo> ncopa: we would need some PR people.
2016-08-05 12:59:01 <^7heo> even to settle internal problems.
2016-08-05 12:59:07 <ncopa> have you guys worked with user support
2016-08-05 12:59:36 <ncopa> i mean like, helping people with turning the mouse the rigw way (not upside down) kind of things
2016-08-05 12:59:44 <jirutka> I’m very good at PR… when you’d like to destroy company during single day XD
2016-08-05 13:00:36 <ncopa> or helping older people which need double time to get things
2016-08-05 13:00:40 <jirutka> just kidding, I’m trying to be polite even with these people, but it’s really very difficult
2016-08-05 13:00:49 <ncopa> and need 5 repeitions
2016-08-05 13:01:15 <jirutka> and don’t have enough patience for user support
2016-08-05 13:01:26 <ncopa> you should try
2016-08-05 13:02:02 <jirutka> btw that’s one of two reasons why you’ve never seen me in the #alpine-linux channel, I’m just in #alpine-devel :)
2016-08-05 13:02:02 <ncopa> when you manage to do that kind of user support - and do it in a way that you dont make them feel stupid
2016-08-05 13:02:11 <ncopa> then you have a win :)
2016-08-05 13:02:18 <ncopa> :)
2016-08-05 13:02:20 <jirutka> I disagree…
2016-08-05 13:02:32 <jirutka> It’s not a win when I feel like a shit after that…
2016-08-05 13:03:03 <ncopa> then problem is that you dont see that it is a win
2016-08-05 13:03:15 <jirutka> or how to express it… maybe psychically exhausted is a more accurate
2016-08-05 13:04:04 <jirutka> I should finally go to lunch
2016-08-05 13:04:10 <ncopa> i suppose part of the problem is that you cannot make them feel good unless you feel good yourself
2016-08-05 13:04:15 <ncopa> lunch helps :)
2016-08-05 13:25:22 <clandmeter> busybox still segfaults on me
2016-08-05 13:36:37 <^7heo> ncopa: it is extremely difficult to see how it is a win not to make stupid people feel stupid when stupidity is what makes your life miserable.
2016-08-05 13:36:57 <^7heo> ncopa: and it is impossible to do it without putting yourself in the position of their bitch,
2016-08-05 13:39:38 <ncopa> i have a fix for busybox depmod
2016-08-05 13:39:44 <ncopa> but ip route is broke
2016-08-05 13:40:42 <ncopa> argh
2016-08-05 13:40:45 <ncopa> and i need to go
2016-08-05 13:40:46 <ncopa> *now*
2016-08-05 13:41:07 <ncopa> for now, `apk add iproute2` should work around busybox ip route issue
2016-08-05 14:29:59 <clandmeter> sigh.. some issues can take too much time
2016-08-05 15:27:26 <leo-unglaub> hey there
2016-08-05 15:27:39 <leo-unglaub> did you do anything special to the ipv4 stack in the latest updates?
2016-08-05 15:27:41 <jirutka> leo-unglaub: hi
2016-08-05 15:27:53 <leo-unglaub> because my server with it crashed and it not reachable via ipv4 anymore
2016-08-05 15:28:10 <jirutka> leo-unglaub: iproute2 is broken…
2016-08-05 15:28:28 <jirutka> leo-unglaub: ncopa wrote: for now, `apk add iproute2` should work around busybox ip route issue
2016-08-05 15:29:47 <leo-unglaub> hmm, this is bad
2016-08-05 15:31:52 <jirutka> leo-unglaub: yeah
2016-08-05 15:34:00 <leo-unglaub> now i have to find a mirror that supports ipv6
2016-08-05 15:36:41 <jirutka> leo-unglaub: be my guest ;) https://repository.fit.cvut.cz/mirrors/alpine/
2016-08-05 15:38:22 <leo-unglaub> thanks, but apk does not use ipv6 ... it times out in ipv4 and exits
2016-08-05 15:39:04 <jirutka> hm, that’s bad, apk should support IPv6
2016-08-05 15:39:36 <leo-unglaub> well, this always happens 5 minutes befure you have an important meeeting you have to go !!!
2016-08-05 15:39:38 <leo-unglaub> hehehehe
2016-08-05 15:41:35 <leo-unglaub> well, lets upload the thinks manually and install them :)
2016-08-05 15:41:42 <leo-unglaub> big thanks jirutka
2016-08-05 15:41:44 <leo-unglaub> see you later
2016-08-05 15:42:01 <jirutka> see ya
2016-08-05 18:11:22 <orion> mitchty: Hi. Now that GHC 8 has been released, will you make an APK for it?
2016-08-05 18:12:34 <mitchty> orion: already did the week before release, https://github.com/mitchty/alpine-ghc/blob/master/Dockerfile has the repos and such
2016-08-05 18:13:46 <mitchty> should have arm in there too if you want to try it
2016-08-05 18:13:54 <mitchty> or if not i forgot to sync it
2016-08-05 18:17:25 <orion> Cool! When can we expect it to be merged it to the official repo?
2016-08-05 18:17:49 <orion> APK repo
2016-08-05 18:23:49 <mitchty> 1/5 of my patches got merged in, the apkbuilds are there and submitted though
2016-08-05 18:24:28 <mitchty> submitted to the test repo however, so wouldn't be official for a while i imagine
2016-08-05 18:24:47 <orion> aww :(
2016-08-05 18:28:13 <mitchty> iirc i think bpiotrowski was working on running the docker stuff so that this guy could work http://patchwork.alpinelinux.org/patch/2236/
2016-08-05 18:28:45 <mitchty> once thats done and the apkbuild updated to wherever the tar.xz files for the arm and x86_64 bootstrap compilers end up, then the rest should be straightforward
2016-08-05 18:32:16 <XgF> ncopa: I'm encountering the sendfile issue on an ext4 FS mounted on NBD
2016-08-05 18:33:00 <XgF> Part of me thinks "Just remove the sendfile" path because, really, it's unnecessary as an optimization (and evidently flaky as a simplification!)
2016-08-05 18:36:13 <scadu> mitchty: as far as I know barthalion don't have much time to get it done now.
2016-08-05 18:42:44 <RieSh2be> or actually never, from what I talked with him... speaking of exhaustion
2016-08-05 18:45:24 <scadu> RieSh2be: welp, he quit the project for a while.
2016-08-05 18:46:44 <mitchty> ah, well so whenever whomever works on it then i guess, good to know thanks scadu
2016-08-05 19:59:09 <RieSh2be> mitchty: so I gave your Dockerfile for amd64 bootstrap a try... and I got 0 size tarball
2016-08-05 20:03:01 <mitchty> RieSh2be: i may have messed up the snapshot commands, curl/wget this https://raw.githubusercontent.com/mitchty/alpine-linux-ghc-bootstrap/master/8.0/ghc-bootstrap/Makefile and then try make x86_64
2016-08-05 20:09:14 <mitchty> from the ghc-bootstrap directory rather
2016-08-05 20:24:21 <RieSh2be> yes, it's okay now
2016-08-05 20:24:29 <RieSh2be> I hope someone will merge it soon
2016-08-05 20:25:55 <mitchty> ok, so i did mess up the snapshot docker commands, thought I got them right but didn't test it well enough
2016-08-05 20:26:21 <mitchty> the armhf build takes a bit longer if you run it
2016-08-05 20:26:38 <mitchty> but i normally used the makefile so i could do make -j2 all
2016-08-05 20:27:40 <mitchty> also warning the armhf docker image is 10.22 gigs, which is apparently over the limit of some docker lvm or aufs thing
2016-08-05 20:28:50 <mitchty> but basically thats how i built the tar.xz's listed in that apkbuild
2016-08-05 20:29:30 <mitchty> and you'll probably want to delete those docker images, they're huge
2016-08-05 20:29:44 <mitchty> i didn't make them to be small but to make it easier to debug cross compilation
2016-08-06 00:32:34 <kazblox_> ncopa you there
2016-08-06 00:57:47 <jirutka> ncopa: rust and cargo just hit the build server https://github.com/alpinelinux/aports/pull/193/files; and going to bed, I’m totally exhausted… I’ll write some “warm” words to Rust team about their build system later…
2016-08-06 07:49:14 <barthalion> I built ghc-bootstrap, I'm uploading it now to dev.ao
2016-08-06 08:35:31 <barthalion> jirutka: reverted cargo, for someone who's so vocal about not building packages, I expected you won't contradict yourself on this
2016-08-06 08:40:55 <barthalion> mitchty: is there something wrong in my bootstrap tarball? >>> ERROR: ghc-bootstrap*: libHSCabal-1.24.0.0-ghc8.0.1.so: path not found
2016-08-06 08:41:23 <barthalion> doesn't seem to be error though, it's compressing now
2016-08-06 08:58:35 <barthalion> mitchty: x86_64 should available on mirrors soon, armhf will probably take longer due to compression
2016-08-06 08:59:27 <barthalion> mitchty: can you test remaining packages with bootstrap from testing and llvm 3.7 modified by jirutka?
2016-08-06 09:22:03 <^7heo> are we supposed to "not build" packages now? =/
2016-08-06 09:22:22 <^7heo> what's the operation for that, abuild not?
2016-08-06 09:29:28 <^7heo> barthalion, replacing other people's broken stuff by his broken stuff since 2014.
2016-08-06 09:31:49 <^7heo> looks like we can't have rust today anyway
2016-08-06 10:33:01 <jirutka> ^7heo: I will rather ignore him…
2016-08-06 10:33:53 <jirutka> ^7heo: however, it’s really my fault, I haven’t retested it again after modification of rust abuild
2016-08-06 10:43:59 <jirutka> ^7heo: whait, what? we already have rust! the problem is that I haven’t make rust depend on rust-stdlib and in the cargo package, I’ve added dependency just on rust… so it misses rust-stdlib
2016-08-06 12:02:47 <jirutka> here we go! apk add rust cargo :) https://twitter.com/jakubjirutka/status/761895185458528256
2016-08-06 15:52:52 <jirutka> hmm… maybe I should not utilize all the CPU cores on production server for building packages… (didn’t know that *that* build is so nicely paralleled)
2016-08-07 12:44:46 <mitchty> so x86_64 seems to be building, can't get armhf to build, ghc-bootstrap for armhf doesn't seem to exist atm
2016-08-07 13:04:09 <jirutka> mitchty: armhf is still blocked on omxplayer… >_<
2016-08-07 13:04:47 <mitchty> jirutka: ah, no worries, but takes me 10 hours to build ghc there, arm is slooooow i'll keep trying
2016-08-07 13:05:31 <jirutka> mitchty: uh, 10 hours o.O and I’m angry when rust builds ~40 min on x86_64
2016-08-07 13:06:03 <mitchty> jirutka: heh, well llvm/opt spent a lot of time trying to reoptimize what ghc gives it
2016-08-07 13:06:23 <mitchty> i'm used to it at this point
2016-08-07 13:06:50 <jirutka> mitchty: don’t even talk about llvm… I spent a lot of time with fixing broken llvm3.7 package
2016-08-07 13:07:24 <mitchty> jirutka: out of curiosity what was broken? it worked with llc/opt for ghc at least, but i didn't need much from it
2016-08-07 13:07:38 <jirutka> mitchty: read comments in the abuild
2016-08-07 13:08:36 <jirutka> mitchty: https://github.com/alpinelinux/aports/commit/ad87dec75adfbd5c5eaad0d7f01b67de49caeb17
2016-08-07 13:09:01 <jirutka> mitchty: and https://github.com/alpinelinux/aports/blob/master/testing/llvm3.7/APKBUILD#L44-L60
2016-08-07 13:12:20 <mitchty> jirutka: gotcha, i didn't test all of the other stuff, sorry you had to deal with it, i would have fixed it for you
2016-08-07 13:13:20 <jirutka> mitchty: I don’t blame you for this, but the person how merged it… some of the issues was very obvious
2016-08-07 13:14:07 <mitchty> my main goal with it was being able to use llvm 3.7 with the system llvm
2016-08-07 13:18:04 <jirutka> this was possibly only partially, llvm3.7-{dev,static} conflicted with llvm-{dev,static}
2016-08-07 13:18:23 <jirutka> s/possbily/possible/
2016-08-07 13:19:47 <jirutka> now it should hopefully work for both static and dynamic linking, I’ve verified it on rust (static) and julia (dynamic)
2016-08-07 13:19:53 <jirutka> so I hope that it’ll work even for ghc
2016-08-07 13:24:32 <jirutka> mitchty: btw why is ghc-bootstrap so big?
2016-08-07 13:25:07 <mitchty> jirutka: ghc builds static and dynamic libraries for 3 types of its runtime, profiled, threaded and normal
2016-08-07 13:25:40 <mitchty> the size is mostly the static libraries
2016-08-07 13:26:15 <jirutka> mitchty: ghc-bootstrap is just for bootstrapping upcoming ghc package?
2016-08-07 13:26:49 <mitchty> jirutka: yep, but you could use it to build other things, though it is slower since its using a bsd integer library and not gmp
2016-08-07 13:27:50 <mitchty> i could never get cross compilation and gmp to work sanely, and was asked to make ghc work like the go package in bootstrap process
2016-08-07 13:28:14 <jirutka> mitchty: have you tried to request bootstrap binary for musl from ghc upstream?
2016-08-07 13:28:25 <mitchty> became the first real user of cross compilation like this in ghc :)
2016-08-07 13:28:54 <mitchty> jirutka: i can ask but its probably unlikely unless I do it
2016-08-07 13:29:10 <mitchty> and this port will likely be how I build it or get it added
2016-08-07 13:29:16 <jirutka> mitchty: for example Rust team will provide prebuilt binary for bootstrapping linked with musl, hopefully very soon
2016-08-07 13:30:30 <mitchty> jirutka: it wouldn't be hard now with a native ghc to build a release install
2016-08-07 13:30:46 <jirutka> mitchty: so I skipped this step, built bootstrap binary semi-manually, uploaded to my server and used as a dependency in rust package; once Rust team start providing binary for musl, I’ll replace it
2016-08-07 13:32:28 <mitchty> jirutka: ah, yeah that would have been easier, i spent a while getting the bootstrap process repeatable and whatnot, was a PITA tbh
2016-08-07 13:32:39 <jirutka> mitchty: exactly
2016-08-07 13:33:18 <mitchty> i know a lot about how ghc's makefiles work, and cross compilation is a huge hack
2016-08-07 13:34:33 <mitchty> so i can open up a ticket to see if we can't get release binaries for ghc building, but not sure if they'd treat musl libc as a tier 1 platform
2016-08-07 13:34:53 <mitchty> and armhf throws more fun in the mix as i don't think they have builders for that
2016-08-07 13:35:02 <jirutka> mitchty: if there’s no real chance that ghc team will provide bootstrapping binary for musl soon, then there’s probably no other way; btw very good work with ghc-bootstrap package!
2016-08-07 13:37:51 <mitchty> jirutka: 8.0.1 has a lot of fixes for cross compilation that i got upstreamed past 7.10.3
2016-08-07 13:38:32 <jirutka> aand here we go, rebuilding julia package against llvm3.7!
2016-08-07 13:38:57 <jirutka> I hope Julia devs will be finally happy… there really didn’t like that I’ve used llvm 3.8
2016-08-07 13:40:16 <mitchty> jirutka: i got the same reaction to my porting 7.10.3 to use llvm3.6 was basically good luck with that
2016-08-07 13:46:10 <jirutka> mitchty: btw with llvm3.7 there’s also a problem that they have to build systems – old based on make files and new based on CMake… most distributions still use the old one
2016-08-07 13:46:48 <mitchty> jirutka: yep 3.8 is cmake only iirc, and it doesn't let you suffix things like autoconf could
2016-08-07 13:47:03 <jirutka> mitchty: and the CMake based still have flaws, they’re still fixing it
2016-08-07 13:50:22 <mitchty> jirutka: out of curiosity how does julia use llvm? does it link it in and use the c api or does it pipe/feed things to opt/llc?
2016-08-07 13:51:01 <jirutka> mitchty: link it
2016-08-07 13:51:42 <jirutka> mitchty: I didn’t know that there’s also a third option
2016-08-07 13:51:51 <jirutka> mitchty: what does ghc use?
2016-08-07 13:52:15 <mitchty> jirutka: so ghc just emits llvm ir and pipes it to llc and opt to get them to generate things
2016-08-07 13:52:58 <mitchty> only issue with that is they generate fairly optimized ir and opt as an example spends a lot of time trying to reoptimize things
2016-08-07 13:53:16 <jirutka> mitchty: aha, have you already tried if it works with llvm3.7-3.7.1-r1 and newer?
2016-08-07 13:54:18 <jirutka> mitchty: if it just executes opt or llc binary, then it should be the same as before for you, but just to be sure
2016-08-07 13:54:18 <mitchty> jirutka: its compiling now on x86_64, actually it got past that and is building stack right now
2016-08-07 13:54:51 <mitchty> jirutka: yep built fine so far, armhf i'll test when ghc-bootstrap shows up
2016-08-07 13:55:14 <mitchty> but generally if x86_64 works arm will now, i forced the ghc build to use llvm for all of em
2016-08-07 14:11:23 <jirutka> mitchty: btw it may be worth to backport support for dynamically linked LLVM binaries into 3.7, to decrease size of the llvm3.7 package
2016-08-07 14:13:15 <jirutka> mitchty: I don’t mind it for julia, because it needs just llvm3.7-libs, but if ghc use opt/llc in runtime, then it needs whole llvm3.7 in runtime
2016-08-07 14:14:36 <mitchty> jirutka: ah, yeah i can work on that next
2016-08-07 14:14:56 <mitchty> also as a note ghc/cabal/stack all built fine with llvm3.7 and ghc-boostrap for x86_64 off testing
2016-08-07 14:15:17 <jirutka> mitchty: I think that it’s this patch plus some related, but not sure https://github.com/llvm-mirror/llvm/commit/f5148ebe0ac2e89cf991b7d6e01778bbb8d55034
2016-08-07 14:15:31 <jirutka> mitchty: great :)
2016-08-07 14:16:34 <mitchty> thats part of why i had a ghc-llvm apkbuild which just built opt/llc statically and included just those binaries
2016-08-07 14:16:47 <jirutka> mitchty: when you compare llvm and llvm3.7 – 6 MiB vs. 233 MiB… that’s because all the llvm’s binaries are statically linked
2016-08-07 14:17:17 <mitchty> jirutka: yep, i only see libc/zstdc++/gcc_s
2016-08-07 14:17:31 <mitchty> i didn't know the cmake build didn't do shared builds at all
2016-08-07 14:18:09 <jirutka> mitchty: but I don’t know how hard it would be to backport support of dynamic linking into 3.7, they changed CMake files quite a lot between 3.7 and 3.8
2016-08-07 14:20:10 <mitchty> jirutka: shouldn't be too bad i hope
2016-08-07 14:20:52 <mitchty> as a note, ghc built natively with llvm is a wee bit smaller at 182.2M ~308M installed
2016-08-07 14:23:50 <mitchty> as a note for barthalion ERROR: ghc-bootstrap*: libHSCabal-1.24.0.0-ghc8.0.1.so: path not found is normal, its a weird symlink chain that isn't resolvable
2016-08-07 14:24:02 <mitchty> well until installation
2016-08-07 14:24:53 <jirutka> I don’t think that unresolvable symlink chains are _normal_…
2016-08-07 14:25:23 <mitchty> the DESTDIR prefix gets put into the symlink
2016-08-07 14:25:52 <mitchty> if i remember right, once you unpack it to /usr its fine let me look again
2016-08-07 14:26:20 <jirutka> why not to make these symlinks relative?
2016-08-07 14:28:31 <mitchty> that i dont' remember, the makefile rules for DESTDIR as not intuitive
2016-08-07 14:31:02 <mitchty> ah, think i know the reason
2016-08-07 14:31:59 <mitchty> not sure its worth a fix though, i'm somewhat sick of the cross compiler setup
2016-08-07 14:34:11 <mitchty> one of my next goals is getting http://www.idris-lang.org ported, since it uses haskell to build its compiler
2016-08-07 14:34:23 <mitchty> but that means tackling ghc libraries and whatnot
2016-08-07 14:34:47 <jirutka> Idris! :)
2016-08-07 14:35:01 <jirutka> I heard a lot good about this lang
2016-08-07 14:35:21 <mitchty> i like it, but its pretty new, i'm working on getting a decent popen type thing working for it
2016-08-07 14:36:02 <mitchty> idris compiles and runs fine but it requires a ton of libraries to build
2016-08-07 14:36:46 <mitchty> jirutka: https://www.manning.com/books/type-driven-development-with-idris that book is rather good
2016-08-07 14:37:06 <jirutka> is there a chance that haskell package manager will work on Alpine and compile haskell libs?
2016-08-07 14:37:11 <mitchty> its not finished yet but its fun, I need to go through the last 2 chapters
2016-08-07 14:37:23 <mitchty> jirutka: yep thats what cabal is basically
2016-08-07 14:38:00 <mitchty> stack is built using cabal (the library) and does similar, its a long story but with cabal or stack you've all you need to build
2016-08-07 14:38:03 <jirutka> yes, cabal, I couldn’t remember how it’s named
2016-08-07 14:39:23 <mitchty> the more annoying part is getting all the subpackages, and haskell is big on lots of small libraries
2016-08-07 14:39:24 <jirutka> once we have ghc, we can create package for pandoc! :)
2016-08-07 14:39:51 <mitchty> oh yeah that'll work, i use this port to build a static pandoc actually
2016-08-07 15:36:33 <mitchty> wow, omxplayer is a long building process, well time to go for a run before it gets too crazy
2016-08-07 17:16:20 <jirutka> grrr, C world is totally insane, poorly maintained mess
2016-08-07 18:03:45 <mitchty> jirutka: true, however i have to admit i still like using c, but then again I'm normally in kernel mode at $dayjob
2016-08-07 18:03:59 <mitchty> and you can make islands of sanity in that regard
2016-08-07 18:04:58 <mitchty> though everyone got angry when i ran everything through clang-scan-build and fixed a ton of memory leaks
2016-08-07 18:08:56 <jirutka> with more sane lang you don’t have to fix any memory leaks… ;)
2016-08-07 21:06:42 <jirutka> RieSh2be: why are you messing with privileges in our GitHub organization?
2016-08-07 21:09:40 <jirutka> barhalion, you’ve crossed a line now… how allowed you to revoke me an admin access to GH organization?!
2016-08-07 21:12:27 <^7heo> yeah but ncopa's away...
2016-08-07 21:15:56 <^7heo> fcolista: ping
2016-08-07 21:15:59 <^7heo> clandmeter: ping
2016-08-08 06:13:16 <ncopa> morning
2016-08-08 06:13:30 <ncopa> my desktop computer does not boot :-(
2016-08-08 06:13:37 <ncopa> will have to figure out what went wrong
2016-08-08 08:05:29 <^7heo> moin ncopa
2016-08-08 08:06:15 <ncopa> hi
2016-08-08 08:25:50 <^7heo> ncopa: I forgot my laptop's charger @work
2016-08-08 08:26:24 <ncopa> and i'm trying to get my desktop to boot
2016-08-08 08:26:33 <^7heo> ncopa: I couldn't work on nlplug-findfs since I didn't have the patches
2016-08-08 08:27:26 <ncopa> ok
2016-08-08 08:55:45 <nindustries> Hi, is there something like tc on alpine ?
2016-08-08 08:55:51 <nindustries> I would like to traffic shape openvpn traffic
2016-08-08 09:12:24 <ncopa> iproute2
2016-08-08 09:17:28 <nindustries> Hi ncopa ! Does iproute2 overwrite iproute ?
2016-08-08 09:17:41 <nindustries> iproute was already installed but I could install iproute2
2016-08-08 09:18:26 <vkris> ncopa: are we planning for full uefi compat for next iso or installations?
2016-08-08 09:18:31 <nindustries> oh, it adds tc
2016-08-08 09:18:36 <nindustries> thanks
2016-08-08 09:19:26 <vkris> I came across this file and thought it might be useful or worth packaging, https://download.clearlinux.org/image/OVMF.fd
2016-08-08 09:19:42 <vkris> I can add to bugs.a.o if so
2016-08-08 09:20:36 <vkris> and I thought you worked from laptop ;)
2016-08-08 09:34:12 <^7heo> vkris: many of us have many computers ;)
2016-08-08 09:38:13 <ScrumpyJack> good morning climbers. happy monday o/
2016-08-08 09:38:34 <^7heo> myeah...
2016-08-08 09:38:36 <^7heo> monday...
2016-08-08 09:38:52 <^7heo> Time to remember that cloudflare and cloudfront exist.
2016-08-08 09:38:55 <^7heo> v_v
2016-08-08 09:38:59 <^7heo> and fortigate.
2016-08-08 09:47:29 <jirutka> hi
2016-08-08 09:47:43 <jirutka> ncopa: have you read email from me?
2016-08-08 09:48:29 <^7heo> ncopa seems pretty busy this morning ;)
2016-08-08 09:54:48 <leo-unglaub> hey friends :)
2016-08-08 09:58:28 <^7heo> Hey :)
2016-08-08 10:01:46 <jirutka> leo-unglaub: hi
2016-08-08 10:01:59 <jirutka> leo-unglaub: have you already tried `apk add rust cargo`? ;)
2016-08-08 10:02:28 <leo-unglaub> jirutka: no i have not. i was not at the computer the last couple days
2016-08-08 10:03:13 <leo-unglaub> but i noticed it *g* my hourly cron script apk search rust | sendmail ... alreaady discovered it *g*
2016-08-08 10:03:49 <leo-unglaub> you did an excelent job dude!
2016-08-08 10:05:09 <jirutka> heh :)
2016-08-08 10:05:50 <leo-unglaub> let me get my laptop, i wrote down some minor notes about things i noticed
2016-08-08 10:06:51 <jirutka> okay, I go to launch now, but I have IRC bouncer, so you can read it later
2016-08-08 10:07:29 <leo-unglaub> just enjoy lunch ... i write you when you get back
2016-08-08 11:02:12 <jirutka> leo-unglaub: I’m back :)
2016-08-08 12:02:12 <jirutka> How to work with XML namespaces… step 1, remove namespaces
2016-08-08 12:03:04 <jirutka> really, how me 6 years ago could be so stupid to use XML?! the worst format ever
2016-08-08 12:03:42 <jirutka> ah, sry, wrong channel
2016-08-08 12:24:34 <^7heo> jirutka: it's like "how to fix audio in any linux distribution in one step, the easy way."
2016-08-08 12:24:40 <^7heo> "remove pulseaudio"
2016-08-08 12:26:17 <leo-unglaub> jirutka: its like "how to fix every problem with the linux desktop" --- >  remove GTK3 and to back to GTK2
2016-08-08 12:28:50 <^7heo> leo-unglaub: well, that's not untrue, but GTK sucks anyway.
2016-08-08 12:29:42 <leo-unglaub> i never had those problems with gtk2 ... i really liked it ... i mean, yes it has some api's that where designed very complicated ... but in general it worked great
2016-08-08 12:30:05 <leo-unglaub> but now that more and more applicaitons switch to gtk3 i spend nearly half of my time developing trying to fix gk3 themes
2016-08-08 12:30:12 <leo-unglaub> currently broken: firefox 48
2016-08-08 12:30:13 <leo-unglaub> ...
2016-08-08 12:36:43 <jirutka> hm, isn’t gtk3 under freedesktop…?
2016-08-08 12:39:32 <leo-unglaub> i have no idea what those idiots are doing ...
2016-08-08 12:39:44 <leo-unglaub> its time to get rid of it!
2016-08-08 12:39:52 <leo-unglaub> lets build it it rust :)
2016-08-08 12:41:03 <leo-unglaub> but as soon as you see *freedesktop or *gnome* those days you can be sure its horrible slow, breaks, is insecure, unurable and simply bad ...
2016-08-08 12:53:18 <jirutka> leo-unglaub: so what’s about rust, what have you noticed?
2016-08-08 12:54:31 <leo-unglaub> ah, yes ... from the rust package itself. maybe you can also remove /usr/share/rust/etc/debugger_pretty_printers_common.py. rust does not depend on python (and thats good!!!!) so this file is not needed at all. if you use it, maybe put it into a sub package
2016-08-08 12:55:08 <jirutka> this file is shared between rust-gdb and rust-lldb
2016-08-08 12:55:33 <leo-unglaub> rust-doc and cargo-doc both contain LICENSE-APACHE, COPYRIGHT, LICENSE-MIT and README.md. its just a personal thing, but i hate it to have licence files floating around
2016-08-08 12:55:42 <jirutka> it’s a tiny file and I didn’t declare runtime dependency on python for rust package; i don’t think that it’s worth to create another subpackage just for this file :)
2016-08-08 12:56:05 <jirutka> okay, I’ll remove the license files
2016-08-08 12:56:49 <jirutka> BTW, there’s an alternative to LLVM, but with worse performance http://c9x.me/compile/
2016-08-08 12:57:21 <leo-unglaub> jirutka: there is a better llvm alternative ...
2016-08-08 12:57:37 <jirutka> leo-unglaub: which one? :)
2016-08-08 12:58:01 <leo-unglaub> Rich Felker once tweeted it
2016-08-08 12:58:07 <leo-unglaub> let me look it up
2016-08-08 12:58:24 <leo-unglaub> its like llvm, but no c++, just c and clean internals
2016-08-08 13:00:23 <jirutka> leo-unglaub: we have prof. Vítek at our faculty that recently received pretty big ERC grant for project Evolving Language Ecosystems… I’d like to talk with him about possibility to port Rust or Julia to another backed than LLVM, as a proof of concept
2016-08-08 13:00:44 <jirutka> leo-unglaub: it seems that LLVM is really huge PITA
2016-08-08 13:00:54 <leo-unglaub> jirutka: http://pp.ipd.kit.edu/firm/
2016-08-08 13:01:35 <leo-unglaub> jirutka: https://twitter.com/RichFelker/status/710899135562567684
2016-08-08 13:01:37 <jirutka> leo-unglaub: looks interesting, how about performance?
2016-08-08 13:02:07 <leo-unglaub> https://twitter.com/RichFelker/status/710512973626920960
2016-08-08 13:03:16 <leo-unglaub> i like Rich Felker because he knows what he does ... and alpine has benefited largly from using his software. so when he recommends rust language with firm/cparser then this is a solid statement
2016-08-08 13:03:59 <jirutka> :)
2016-08-08 13:06:59 <leo-unglaub> did you notice that he retweetet you finishing rust on alpine? he clearly is interrested in it :)
2016-08-08 13:07:17 <jirutka> so I have few interesting topic, now I have to arrange a meeting with him
2016-08-08 13:08:16 <jirutka> well, this tweet was incredibly popular, it has 36 RTs and 79 favs, so I didn’t noticed him specifically
2016-08-08 13:08:31 <jirutka> I’ve just followed him and now see that he indeed retweeted it
2016-08-08 14:01:17 <oneinsect> folks is a there a chance we could include way land instead x
2016-08-08 14:01:29 <oneinsect> or in addition to x11
2016-08-08 14:01:56 <oneinsect> what about including mesa with vulkun drivers
2016-08-08 14:02:15 <oneinsect> ncopa
2016-08-08 14:04:31 <jirutka> it would be awesome to finally replace X with Wayland!
2016-08-08 14:05:03 <jirutka> however, I don’t use Linux on desktop, so I have no experience with that
2016-08-08 14:05:47 <^7heo> I dunno about wayland, I would welcome it but I don't know if I can ever try to build it.
2016-08-08 14:05:53 <^7heo> looks hellish to maintain to me.
2016-08-08 14:06:27 <jirutka> more hellish than X? o.O
2016-08-08 14:09:51 <ncopa> oneinsect: i think we have some wayland bits already
2016-08-08 14:09:51 <leo-unglaub> jirutka: yes ...
2016-08-08 14:10:01 <leo-unglaub> wayland is llvm ^ 10000
2016-08-08 14:10:07 <ncopa> i dont object wayland, but its not a priority for me
2016-08-08 14:10:49 <leo-unglaub> oneinsect: do you have a speciffic usecase where you would need wayland?
2016-08-08 14:13:29 <leo-unglaub> i would be interrested in your usecase where it would benefit you over X because i simply cannot come up with a usecase where wayland would be better than X ...
2016-08-08 14:20:48 <oneinsect> well arm devices especially where there is too much lack of proper drivers
2016-08-08 14:21:10 <oneinsect> wayland with libhybris
2016-08-08 14:21:42 <oneinsect> But I wonder if libhybris will work on muslc alpine
2016-08-08 14:22:04 <oneinsect> leo-unglaub:
2016-08-08 14:25:02 <oneinsect> ncopa: for arm devices wayland is a way forward
2016-08-08 14:25:16 <oneinsect> exception is rpi
2016-08-08 20:27:01 <^7heo> ncopa: what about setting up letsencrypt certificates for alpinelinux?
2016-08-08 20:40:13 <clandmeter> ^7heo: did you check the certs?
2016-08-08 20:40:25 <clandmeter> or which certs are you talking about?
2016-08-08 20:46:20 <ncopa> we should set up letsencrypt for git.a.o too
2016-08-08 20:46:33 <ncopa> good night
2016-08-08 20:53:17 <jirutka> and also make HTTPS mandatory for most of the sites and set up HSTS
2016-08-08 20:53:26 <^7heo> clandmeter: I didn't see anything on HTTPS
2016-08-08 20:53:35 <jirutka> it’s quite a shame that security-oriented distro still doesn’t use HTTPS
2016-08-08 20:53:42 <jirutka> https://alpinelinux.org/
2016-08-08 20:53:51 <jirutka> https://bugs.alpinelinux.org/
2016-08-08 20:53:52 <^7heo> clandmeter: now that you mention it
2016-08-08 20:54:01 <^7heo> clandmeter: there ALSO is https there it seems
2016-08-08 20:54:18 <clandmeter> there is a bug on the tracker about it.
2016-08-08 20:54:19 <jirutka> the problem is that it’s not default, so it’s actually quite useless as a protection against attacks
2016-08-08 20:54:28 <jirutka> yea
2016-08-08 20:54:28 <clandmeter> you can add your comments
2016-08-08 20:54:47 <clandmeter> the problem is, there should also be some fallback.
2016-08-08 20:55:16 <jirutka> no, it shouldn’t be… not just that, it MUST NOT be
2016-08-08 20:55:24 <jirutka> for security reasons
2016-08-08 20:55:29 <^7heo> clandmeter: what about using location headers with a 301 to redirect to https, and Strict-Transport-Security headers too?
2016-08-08 20:55:47 <jirutka> that’s the whole purpose of stripping attack and why HSTS exists
2016-08-08 20:55:54 <^7heo> yeah
2016-08-08 20:55:56 <jirutka> ^7heo: you can’t
2016-08-08 20:55:59 <^7heo> why?
2016-08-08 20:56:11 <clandmeter> please add your comments to the issue, as else we are discussing in loops
2016-08-08 20:56:18 <^7heo> ok
2016-08-08 20:56:22 <^7heo> I wasn't aware of the issue, sorry
2016-08-08 20:56:24 <jirutka> ^7heo: wait a moment… redirect from HTTP to HTTPS, of course that should be supported
2016-08-08 20:56:28 <jirutka> I misunderstood that
2016-08-08 20:56:42 <^7heo> jirutka: I am basically asking for HSTS too.
2016-08-08 20:56:47 <jirutka> but not support both HTTP and HTTPS
2016-08-08 20:56:51 <jirutka> that’s the current state
2016-08-08 20:56:59 <^7heo> we have hsts?
2016-08-08 20:57:02 <jirutka> no
2016-08-08 20:57:10 <^7heo> ok
2016-08-08 20:57:11 <clandmeter> we had it
2016-08-08 20:57:14 <^7heo> because otherwise it's broken for me
2016-08-08 20:57:16 <jirutka> I’ll add more information to the issue
2016-08-08 20:57:17 <clandmeter> but i removed it
2016-08-08 20:57:26 <^7heo> clandmeter: is the information about why on the issue?
2016-08-08 20:57:46 <clandmeter> no it was done before
2016-08-08 20:57:52 <jirutka> with HSTS you obviously can’t support both HTTP and HTTPS, except redirect from HTTP to HTTPS
2016-08-08 20:57:53 <clandmeter> and i dont exactly remember why i did it.
2016-08-08 20:58:07 <^7heo> jirutka: well, you CAN support HTTP
2016-08-08 20:58:13 <^7heo> jirutka: as long as people don't go to HTTPS
2016-08-08 20:58:21 <jirutka> ^7heo: not with HSTS
2016-08-08 20:58:25 <jirutka> please find how it works ;)
2016-08-08 20:58:35 <^7heo> jirutka: yeah sure you can, you just have to send different headers.
2016-08-08 20:58:46 <jirutka> the issue is here https://bugs.alpinelinux.org/issues/5720
2016-08-08 20:58:58 <^7heo> jirutka: prior to people connecting to HTTPS, the browser does not know about the HTTPS page.
2016-08-08 20:59:21 <^7heo> jirutka: so essentially, HTTP is then possible.
2016-08-08 20:59:24 <jirutka> ^7heo: no
2016-08-08 20:59:37 <jirutka> ^7heo: do you know how so called HTTPS stripping attack works?
2016-08-08 20:59:47 <^7heo> I've read about it, but it was years ago
2016-08-08 20:59:53 <^7heo> please refresh my memory, I forgot totally.
2016-08-08 21:00:33 <jirutka> ^7heo: classic MiT, the site supports HTTPS, but the attacker strips HTTPS and sends you HTTP, so he can read the communication
2016-08-08 21:00:54 <^7heo> yes and?
2016-08-08 21:01:03 <jirutka> ^7heo: BFU usually doesn’t notice that he’s not on HTTPS site, but just HTTP
2016-08-08 21:01:15 <^7heo> yes, and?
2016-08-08 21:01:17 <jirutka> ^7heo: the site thinks that you talk via HTTPS, because the site doesn’t know about attacker
2016-08-08 21:01:23 <^7heo> yes.
2016-08-08 21:01:26 <^7heo> obviously.
2016-08-08 21:01:27 <^7heo> and?
2016-08-08 21:01:55 <jirutka> ^7heo: well, when you deploy HSTS, the site sends a special header telling the browser that it must always use HTTPS for the site
2016-08-08 21:02:01 <^7heo> no
2016-08-08 21:02:04 <jirutka> ^7heo: the header have some expiration time, usually many years
2016-08-08 21:02:12 <^7heo> you can configure the website NOT to send HSTS headers on HTTP
2016-08-08 21:02:17 <^7heo> and then, you can do either.
2016-08-08 21:02:20 <jirutka> so when attacker sends you HTTP, the browser immediatelly switch to HTTPS
2016-08-08 21:02:25 <^7heo> and as long as the people don't go to the HTTPS website
2016-08-08 21:02:32 <^7heo> the HTTP website is accessible.
2016-08-08 21:02:46 <^7heo> of course, it is a bogus setup.
2016-08-08 21:02:52 <^7heo> But it is technically very possible.
2016-08-08 21:03:00 <jirutka> well, that is possible
2016-08-08 21:03:07 <^7heo> so now
2016-08-08 21:03:10 <^7heo> let's take your example againt
2016-08-08 21:03:12 <^7heo> again*
2016-08-08 21:03:17 <jirutka> hm, I think that I understand you now
2016-08-08 21:03:21 <^7heo> attacker
2016-08-08 21:03:26 <^7heo> MITM
2016-08-08 21:03:39 <^7heo> the attacker gets the request from you to the HTTP version of the website
2016-08-08 21:03:51 <^7heo> EVEN if the website sends HSTS headers
2016-08-08 21:03:58 <^7heo> if the website serves content over HTTP
2016-08-08 21:04:03 <^7heo> HSTS is rendered useless
2016-08-08 21:04:10 <^7heo> because all the attacker has to do is to strip the header.
2016-08-08 21:04:13 <^7heo> from plain text.
2016-08-08 21:04:19 <^7heo> I can do that with sed and nc.
2016-08-08 21:04:27 <^7heo> and a bash loop
2016-08-08 21:04:29 <jirutka> yes
2016-08-08 21:04:30 <^7heo> s/bash/sh/
2016-08-08 21:04:41 <^7heo> I actually can't do that with a bash loop
2016-08-08 21:04:45 <^7heo> because I won't install bash
2016-08-08 21:04:49 <^7heo> but that's a different topic here.
2016-08-08 21:04:57 <^7heo> so yes, HSTS has to be exclusive HTTPS.
2016-08-08 21:04:59 <jirutka> HSTS is based on memory and assumption that it’s not the first time you access the site
2016-08-08 21:05:10 <^7heo> but, it is totally possible to have a website over HTTP at the same time.
2016-08-08 21:05:22 <^7heo> therefore giving a free attack vector to any attacker.
2016-08-08 21:05:36 <jirutka> well, you can allow to use HTTP and when you don’t have HSTS header in your user agent, then it’s fine
2016-08-08 21:05:43 <^7heo> but at the same time
2016-08-08 21:05:57 <^7heo> even if you're using the HTTPS connection
2016-08-08 21:06:12 <^7heo> (as the server)
2016-08-08 21:06:25 <^7heo> and HSTS
2016-08-08 21:06:31 <^7heo> you can't be sure of anything.
2016-08-08 21:06:35 <^7heo> because if I MITM you
2016-08-08 21:06:46 <^7heo> and you don't KNOW that the website (or don't pay attention) should be over HTTPS
2016-08-08 21:06:55 <^7heo> I strip both HTTPS and HSTS headers
2016-08-08 21:06:56 <jirutka> the problem is that then you can’t enforce redirect from HTTP to HTTPS… and that’s quite bogus setup, to require user to manually change URL to HTTPS
2016-08-08 21:06:59 <^7heo> and serve you full HTTP
2016-08-08 21:07:07 <^7heo> and welcome to my proxy.
2016-08-08 21:07:25 <^7heo> it requires sending a Location: https://... header.
2016-08-08 21:07:28 <jirutka> maybe you can hack it and send redirect based on User Agent… so when someone use curl, you don’t send redirect… if you detect some browser, send redirect
2016-08-08 21:07:38 <^7heo> The real issue here
2016-08-08 21:07:41 <jirutka> but why to do that?
2016-08-08 21:07:44 <^7heo> is that HTTPS is broken.
2016-08-08 21:07:51 <^7heo> because CAs.
2016-08-08 21:08:02 <jirutka> maybe it makes sense for *some* of our domains, but IMO not all
2016-08-08 21:08:05 <^7heo> having a central authority that is not EXCLUSIVE to a domain is broken
2016-08-08 21:08:29 <^7heo> what I would like is to have a slug mail (post, physical) with the QR code of the certificate fingerprint
2016-08-08 21:08:36 <^7heo> every time we change the certificate.
2016-08-08 21:08:46 <jirutka> please don’t start about CAs :) I know that this system is far from perfect, but still MUCH better than using plain unecrypted HTTP or self-signed certs
2016-08-08 21:08:55 <^7heo> then I can use/write a browser extension to pin that certificate down to a.o
2016-08-08 21:09:05 <^7heo> and only THEN it's some sort of security
2016-08-08 21:09:15 <jirutka> yes, but users will not get it
2016-08-08 21:09:18 <^7heo> until then, there's no point in doing anything
2016-08-08 21:09:22 <^7heo> I don't care about users
2016-08-08 21:09:29 <jirutka> and actually there’s a better mechanism, it’s called DANE
2016-08-08 21:09:32 <^7heo> I care about the POSSIBILITY of having security.
2016-08-08 21:09:35 <jirutka> that solves most of the problems of CA
2016-08-08 21:09:37 <^7heo> The DNS extension?
2016-08-08 21:09:43 <jirutka> everything is ready… except browsers
2016-08-08 21:09:50 <jirutka> yes, it’s DNS extension
2016-08-08 21:09:52 <^7heo> yeah
2016-08-08 21:09:54 <^7heo> I know of it.
2016-08-08 21:10:14 <^7heo> The problem is that DANE is relying on DNSSEC
2016-08-08 21:10:26 <jirutka> it’s quite curious… it seems like some CAs pays browsers to not adopt DANE
2016-08-08 21:10:30 <jirutka> yes
2016-08-08 21:10:39 <jirutka> ah, of course, .com is still not signed :(
2016-08-08 21:10:41 <^7heo> jirutka: ofc
2016-08-08 21:10:57 <^7heo> jirutka: it's rendering their CA authority less important, can't MITM anymore.
2016-08-08 21:11:11 <jirutka> for example .cz is already signed, we have one of the biggest DNSSEC adoption :)
2016-08-08 21:11:16 <^7heo> And DNSSEC, in addition of being a free DDoS amplifier, isn't THAT secure.
2016-08-08 21:11:37 <jirutka> however, we can’t fix that, not now :/
2016-08-08 21:11:49 <^7heo> nope
2016-08-08 21:12:01 <^7heo> the issue is that users are used to be hand helded
2016-08-08 21:12:05 <^7heo> nothing else.
2016-08-08 21:12:16 <jirutka> not just that
2016-08-08 21:12:18 <^7heo> if you tell someone that using a computer is requiring SOME brains sometimes...
2016-08-08 21:12:25 <^7heo> a lot of people will stop using them
2016-08-08 21:12:33 <^7heo> but at the same time, we might then get SOME security
2016-08-08 21:13:08 <^7heo> Anyway
2016-08-08 21:13:10 <^7heo> no matter how you put it
2016-08-08 21:13:24 <jirutka> however, my concern is about Alpine domains… even silly blogs already use HTTPS, it’s propagated everywhere, so how does it look when Linux distribution with security in mind doesn’t use it? :/
2016-08-08 21:13:26 <^7heo> there can not be any way to have security if you send all the information over one channel.
2016-08-08 21:13:30 <^7heo> ful stop.
2016-08-08 21:13:32 <^7heo> full*
2016-08-08 21:13:54 <^7heo> jirutka: I perfectly understand why we do not use something broken.
2016-08-08 21:14:11 <^7heo> jirutka: what we SHOULD do is allow people to get their data via another protocol
2016-08-08 21:14:16 <jirutka> it’s still less broken than using unencrypted HTTP
2016-08-08 21:14:25 <jirutka> that’s the fact
2016-08-08 21:14:25 <^7heo> nah it's more broken IMHO
2016-08-08 21:14:32 <jirutka> no, trust me, it’s not
2016-08-08 21:14:38 <^7heo> wont't rust you.
2016-08-08 21:14:41 <^7heo> won't trust you.
2016-08-08 21:14:48 <^7heo> first, because it gives a false sense of security
2016-08-08 21:14:55 <jirutka> I know that
2016-08-08 21:14:56 <^7heo> second, because it's useless overhead.
2016-08-08 21:15:08 <^7heo> it's like saying that C++ is more secure because it's harder to reverse engineer.
2016-08-08 21:15:26 <jirutka> I know quite a lot about this topic… current CA system isn’t really good, but it’s definitely much better than not using encryption at all
2016-08-08 21:15:28 <^7heo> the point is, if your ISP wants to read your comms
2016-08-08 21:15:32 <^7heo> they WILL read your comms
2016-08-08 21:15:34 <^7heo> period.
2016-08-08 21:15:43 <jirutka> how?
2016-08-08 21:15:44 <^7heo> it isn't.
2016-08-08 21:15:47 <^7heo> How?
2016-08-08 21:16:06 <jirutka> when you use HTTPS
2016-08-08 21:16:09 <^7heo> MITM, generating a certificate for the domains you're visiting on the fly, with any CA that is in your browser
2016-08-08 21:16:14 <^7heo> (and there are a LOT of them)
2016-08-08 21:16:18 <jirutka> that’s not so simple
2016-08-08 21:16:20 <jirutka> not at all
2016-08-08 21:16:21 <^7heo> it is.
2016-08-08 21:16:27 <jirutka> not, it’s definitely not
2016-08-08 21:16:29 <^7heo> it is.
2016-08-08 21:16:34 <jirutka> CA system is not totally stupid
2016-08-08 21:16:44 <^7heo> add me as a CA authority
2016-08-08 21:16:47 <^7heo> and use my DNS servers
2016-08-08 21:16:53 <^7heo> you'll see.
2016-08-08 21:17:12 <jirutka> lol
2016-08-08 21:17:33 <jirutka> of course when I explicitly add your certificate as trusted CA…
2016-08-08 21:18:00 <jirutka> but that’s like asking me for giving you a key from my car so you can “steal” it
2016-08-08 21:18:02 <^7heo> so you really think that there are only 3 very trusted CAs in the browser list?
2016-08-08 21:18:10 <jirutka> no, there are quite a lot CAs
2016-08-08 21:18:12 <^7heo> yeah.
2016-08-08 21:18:17 <jirutka> but there are organizations watching it
2016-08-08 21:18:18 <^7heo> one is Telekom for example.
2016-08-08 21:18:21 <^7heo> yeah lol.
2016-08-08 21:18:35 <jirutka> well, try it… try to get for example certificate for google.com
2016-08-08 21:18:39 <jirutka> then tell me how simple it was
2016-08-08 21:18:41 <^7heo> they are watching your computer's hard drive to check that nobody added a rogue CA while you downloaded your distribution via HTTP
2016-08-08 21:18:58 <jirutka> no
2016-08-08 21:19:09 <^7heo> exactly, no.
2016-08-08 21:19:18 <jirutka> of course when you download some malware and give it root access, then nothing can save you
2016-08-08 21:19:20 <^7heo> openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days XXX
2016-08-08 21:19:25 <^7heo> type google.com in
2016-08-08 21:19:28 <jirutka> that’s your responsibility to make your computer secure
2016-08-08 21:19:31 <^7heo> etc etc.
2016-08-08 21:19:40 <^7heo> done, cert is there.
2016-08-08 21:19:56 <^7heo> dude, please stop following the orders like a mindless soldier.
2016-08-08 21:20:02 <jirutka> even DANE or basically anything else can’t help you when your system is compromised
2016-08-08 21:20:04 <^7heo> "your responsability" "make your computer secure"
2016-08-08 21:20:13 <^7heo> there is no such thing as a secure computer anyway
2016-08-08 21:20:15 <^7heo> and second
2016-08-08 21:20:29 <^7heo> you didn't let me explain
2016-08-08 21:20:30 <jirutka> well, then we can give up… stop using encryption at all
2016-08-08 21:20:30 <^7heo> but
2016-08-08 21:20:33 <jirutka> becuase nothing is secure
2016-08-08 21:20:37 <vkris_> ^7heo: is not newer mate-desktop build with GTK3+ ?
2016-08-08 21:20:42 <^7heo> ah no, you *can* have some secure setups
2016-08-08 21:20:45 <^7heo> "secure"
2016-08-08 21:20:48 <^7heo> but better.
2016-08-08 21:21:11 <jirutka> sry, dinner is waiting for me
2016-08-08 21:21:12 <^7heo> I'd rather do HTTP over ssh to the same host (localhost)
2016-08-08 21:21:16 <^7heo> no problem
2016-08-08 21:21:33 <^7heo> vkris_: I don't use mate. why?
2016-08-08 21:22:20 <^7heo> jirutka: long story short: anyone with a little more power than you and me can obtain a valid, signed certificate (by a CA in your browser), for any website.
2016-08-08 21:22:28 <^7heo> s/website/domain/
2016-08-08 21:22:48 <^7heo> jirutka: and that in itself is already having a broken HTTPS
2016-08-08 21:22:52 <vkris_> recalled testing parrot(debian) based desktop, and seemed okish , low resource
2016-08-08 21:23:03 <^7heo> it's like relying on DNT for browsing "anonymously"
2016-08-08 21:23:14 <vkris_> it has mate build with gtk3+
2016-08-08 21:23:28 <^7heo> jirutka: I would find it funny, but people like you believe in it, so it's pretty sad.
2016-08-08 21:24:02 <^7heo> vkris_: I'll try to build it once I've solved that nlplug-findfs problem
2016-08-08 21:28:05 <jirutka> ^7heo: prove it; give me valid certificate and private key for some well known domain that will be signed by one of the root’s CAs in Firefox
2016-08-08 21:28:22 <^7heo> jirutka: as soon as I get employed by telekom.
2016-08-08 21:28:27 <jirutka> ^7heo: then do it
2016-08-08 21:28:40 <^7heo> sure, I'm gonna quit my job just to prove something obvious to you.
2016-08-08 21:28:42 <jirutka> ^7heo: you can always never get absolute security; this is pointless
2016-08-08 21:29:11 <^7heo> sure, it's pointless to have absolute security, so let's dream and send all our "encrypted" data to everyone who already has power.
2016-08-08 21:29:26 <^7heo> I don't know if you are extremely naive
2016-08-08 21:29:33 <^7heo> or if you fail to see the technical point there.
2016-08-08 21:29:40 <^7heo> knowing you, I'd bet for the first one.
2016-08-08 21:29:51 <jirutka> ^7heo: do you use keys? do you lock your apartment? why? it’s not secure, someone with great power can simply get in even without keys… or just call to company who sold you that lock… so why to use locks?
2016-08-08 21:29:55 <^7heo> but still, I don't get how you can say aht you're saying.
2016-08-08 21:30:04 <^7heo> we're not talking about the same thing.
2016-08-08 21:30:11 <jirutka> ^7heo: I know very well what I’m talking about
2016-08-08 21:30:14 <^7heo> if you consider your appartment
2016-08-08 21:30:17 <^7heo> let's put it this way
2016-08-08 21:30:21 <^7heo> SSH is secure.
2016-08-08 21:30:25 <^7heo> how come HTTPS is not?
2016-08-08 21:30:55 <^7heo> because, I defy telekom to enter my SSH server without me wanting.
2016-08-08 21:30:58 <vkris_> seems interesting, http://blog.cryptographyengineering.com/2016/03/attack-of-week-apple-imessage.html
2016-08-08 21:30:58 <jirutka> ^7heo: also you misses another point and that is how ordinary people see it… they read that every site should use HTTPS… Alpine tells that it’s secure and yet, no HTTPS… most of the people doesn’t know that CA is not perfectly secure
2016-08-08 21:31:12 <clandmeter> im going to bed. and dont forget we have a alpine-linux and alpine-offtopic channel.
2016-08-08 21:31:12 <^7heo> I don't care.
2016-08-08 21:31:17 <^7heo> HTTPS is a lure.
2016-08-08 21:31:19 <vkris_> nice ! https://isi.jhu.edu/~mgreen/imessage.pdf
2016-08-08 21:31:23 <^7heo> I want images over SOMETHING ELSE.
2016-08-08 21:31:33 <^7heo> SSH would work perfectly to me.
2016-08-08 21:31:40 <jirutka> no, SSH is not absolute secure… how do you verify key footprint, hm?
2016-08-08 21:31:53 <^7heo> via slug mail, phone call, text, etc.
2016-08-08 21:32:03 <jirutka> and clandmeter is right, we should not spam in this channel with this
2016-08-08 21:32:11 <^7heo> best would be a random (but with an order decided in advance) combination of those
2016-08-08 21:32:19 <^7heo> yeah, that is true.
2016-08-08 21:32:33 <jirutka> oh so I will call to alpinelinux.org to tell me fingerprint jsut to visit the site! brilliant!
2016-08-08 21:32:35 <^7heo> clandmeter: noted.
2016-08-08 23:19:26 <^7heo> okay at last nlplug-findfs is now testable with a script.
2016-08-08 23:19:35 <^7heo> it segfaults, yes, but it's reproducible.
2016-08-09 00:06:19 <jirutka> reproducible segfaults are always better than totally random ones! :)
2016-08-09 00:06:30 <jirutka> so, great work!
2016-08-09 00:51:28 <koorogi> Has the idea of adding multilib support been discussed before?
2016-08-09 00:51:56 <koorogi> I noticed the wine package on x86_64 is 64-bit only, which makes it much less useful
2016-08-09 00:52:17 <koorogi> And I assume that's due to lack of multilib in alpine
2016-08-09 07:54:16 <fabled> ncopa, time to tag lddtree ?
2016-08-09 07:56:46 <ncopa> fabled: sigh...
2016-08-09 07:56:50 <ncopa> there are 2 pull requests
2016-08-09 07:56:55 <ncopa> with 10ish commits
2016-08-09 07:57:05 <ncopa> apparently some of the commit is fixing something that is broken
2016-08-09 07:57:11 <ncopa> the others are adding new features
2016-08-09 07:57:21 <ncopa> the 2 pull requests also have overlapping commits
2016-08-09 07:57:30 <ncopa> so i need to clean up that mess
2016-08-09 07:58:38 <ncopa> i'm dissapointed of syncthing too
2016-08-09 07:58:49 <ncopa> in May they did v0.13
2016-08-09 07:58:58 <ncopa> with incompatible protocol
2016-08-09 07:59:09 <ncopa> meaning all nodes need upgrade at the same time
2016-08-09 07:59:20 <ncopa> 0.13.0 was released 17 May
2016-08-09 07:59:22 <ncopa> now
2016-08-09 07:59:28 <ncopa> 17 July they did same thing again
2016-08-09 07:59:38 <ncopa> new incompatible protocol
2016-08-09 07:59:41 <ncopa> 0.14
2016-08-09 07:59:59 <ncopa> i dont know what to do with syncthing in 3.4-stable
2016-08-09 08:00:51 <ncopa> i'd say its unsuitable for anything "production"
2016-08-09 08:01:12 <ncopa> breaking protocol every 2 months...
2016-08-09 08:01:25 <coredumb> I agree
2016-08-09 08:16:29 <ScrumpyJack> what's syncthing used for in AL infra?
2016-08-09 08:17:41 <ncopa> not used in AL infra
2016-08-09 08:17:50 <ncopa> i'm using it privately
2016-08-09 08:18:02 <ncopa> but am now looking for a stable alternative
2016-08-09 08:31:54 <ScrumpyJack> I am using owncloud successfully. The owncloud-client has been in the AL repos for 18 months and works perfectly. I have not updated my owncloud server for a while though, it's still on 8.0.2, for fear that it might break.
2016-08-09 08:33:11 <ScrumpyJack> What i don't like about owncloud is the "bloat"
2016-08-09 08:33:23 <^7heo> moin
2016-08-09 08:34:13 <^7heo> ncopa: did you see my issues on gh about mkinitfs?
2016-08-09 08:39:31 <ncopa> i suppose i should switch to owncloud or nextcloud or whatever it is called this week
2016-08-09 08:39:39 <ncopa> ^7heo: no
2016-08-09 08:55:43 <^7heo_> trace for the other ^7heo
2016-08-09 08:56:05 <^7heo_> so yeah nothing is frozen on the other side, just the input
2016-08-09 08:57:39 <ScrumpyJack> how about sparkleshare? anyone used that?
2016-08-09 08:57:51 <^7heo_> ScrumpyJack: what for?
2016-08-09 08:58:33 <^7heo_> I love how fdflush is related to floppy disks and not file descriptors.
2016-08-09 08:58:37 <^7heo_> not confusing at all.
2016-08-09 08:59:21 <ScrumpyJack> ^7heo_: ncopa wants to move away from syncthing
2016-08-09 08:59:47 <^7heo_> I can understand why.
2016-08-09 09:13:43 <^7heo_> I fear that my terminal is completely stalled
2016-08-09 09:13:56 <^7heo_> that sucks.
2016-08-09 09:48:27 <clandmeter> ncopa: i introduced syncthing13 in master
2016-08-09 09:48:33 <clandmeter> just because of that issue.
2016-08-09 09:51:26 <leo-unglaub> hey :)
2016-08-09 09:51:30 <ncopa> hi
2016-08-09 10:11:01 <^7heo> So, all, I lost all my history
2016-08-09 10:11:08 <^7heo> if you need me to know anything, please tell me again,.
2016-08-09 10:13:52 <^7heo> ncopa: and that was the link that killed my tmux/irssi: https://github.com/7heo/mkinitfs/issues
2016-08-09 10:14:11 <^7heo> ncopa: I opened 2 issues there, mentionned you in one, so I expected you to maybe see it.
2016-08-09 10:19:06 <ScrumpyJack> syncthing13?
2016-08-09 10:19:31 <ncopa> should probably be renamed to syncthing0.13
2016-08-09 10:19:55 <ScrumpyJack> what next, syncthing14 when syncthing-15.0 is released with another proto?
2016-08-09 10:20:09 <clandmeter> it is what it is. and yes it sucks.
2016-08-09 10:20:21 <clandmeter> ncopa: go ahead and rename it.
2016-08-09 10:20:53 <ScrumpyJack> can we keep syncthing as 0.13 and call new one syncthing14?
2016-08-09 10:20:58 <clandmeter> i just wanted to add something so ppl have a way to fix it.
2016-08-09 10:21:27 <ScrumpyJack> otherwise it breaks nodes with different repos. ie 3.4 vs edge
2016-08-09 10:22:23 <clandmeter> ill leave the dicission up to ncopa
2016-08-09 10:22:35 <ScrumpyJack> for example apk add syncthing on 3.4 gives my 0.13 but on edge it gives me 0.14 and won't work together
2016-08-09 10:33:55 <ncopa> 0.13 is the problem imho
2016-08-09 10:34:09 <ncopa> the 0.14 introduced changes to make backwards compat easier
2016-08-09 10:34:43 <ncopa> my guess is that they did 0.13 with incompat changes, realizes the consquences of breaking protocol compat
2016-08-09 10:34:54 <ncopa> and make 0.14
2016-08-09 11:01:11 <jirutka> ncopa: could you please merge https://github.com/alpinelinux/aports/pull/197 ?
2016-08-09 11:01:11 <ScrumpyJack> so 0.13.6 won't work with 0.13.[1-5] but 0.14.x will?
2016-08-09 11:41:25 <jirutka> when some subpackage is available only subset of archs, how what is the recommended approach to disable executing it when building on non-compatible arch?
2016-08-09 11:42:16 <fabled> if the pkg needs explicit checking for each arch, list the arches individually
2016-08-09 11:42:38 <fabled> if the build just fails due to some bizarre reason (or temporarily), you can use the !arch syntax
2016-08-09 11:42:52 <fabled> though, not sure if we updated lua-aports yet with the new !arch syntax
2016-08-09 11:43:00 <jirutka> https://github.com/jirutka/alpine-aports/blob/82a3e01ac1b25c4211d1dda7030d69e7da5b514f/testing/openblas/APKBUILD
2016-08-09 11:43:13 <jirutka> this should not be run on !x86_64 https://github.com/jirutka/alpine-aports/blob/82a3e01ac1b25c4211d1dda7030d69e7da5b514f/testing/openblas/APKBUILD#L82-L88
2016-08-09 11:43:45 <fabled> oh
2016-08-09 11:43:57 <fabled> setting arch on subpkg like that does not work
2016-08-09 11:44:10 <fabled> use something like
2016-08-09 11:44:19 <jirutka> I see, but how to deal with it? add that subpackage to $subpackages conditionally?
2016-08-09 11:44:27 <fabled> [ "$CARCH" = x86_64 ] && subpackages="$subpackages $pkgname-ilp64"
2016-08-09 11:44:34 <jirutka> okay
2016-08-09 11:44:35 <fabled> yes
2016-08-09 11:50:38 <jirutka> does arch="all" already include aarch64?
2016-08-09 12:04:37 <fabled> yes
2016-08-09 12:30:27 <mitchty> ok testing that the ghc-bootstrap works with armhf, i'll look at it again after I'm off work today, might be finished by then
2016-08-09 12:46:23 <jirutka> fabled: always when I tried checkapk, it printed gzip and tar errors; is it some problem on my side or in checkapk? http://haste.fit.cvut.cz/zuhagey.log
2016-08-09 12:47:00 <jirutka> another pull requests ready to merge into master https://github.com/alpinelinux/aports/pulls?q=is%3Apr+is%3Aopen+label%3Aready
2016-08-09 12:47:12 <fabled> i think that happens when the old package does not exist or there was failure to download it
2016-08-09 12:48:20 <jirutka> I’m quite sure that the old package does exist; what can be a reason for download failure, when apk works fine?
2016-08-09 12:48:55 <jirutka> really?! `grep ^http: /etc/apk/repositories > $tmpdir/repositories`
2016-08-09 12:49:17 <jirutka> I use https…
2016-08-09 12:52:20 <clandmeter> fabled: getting an error with qt, i think its related to gcc6
2016-08-09 12:52:32 <clandmeter> fedora has a gcc6 patch
2016-08-09 12:52:48 <fabled> clandmeter, i think ncopa mentioned something similar
2016-08-09 12:52:52 <clandmeter> but then it will error on ../3rdparty/javascriptcore/JavaScriptCore/wtf/TypeTraits.h:173:69: error: 'std::tr1' has not been declared
2016-08-09 12:53:13 <clandmeter> ah he did look into it?
2016-08-09 12:53:21 <clandmeter> i pinged about it, but never got a ping reply
2016-08-09 12:54:18 <clandmeter> i read stuff about C++11
2016-08-09 12:54:47 <clandmeter> ncopa: did you look into qt issue?
2016-08-09 12:57:04 <clandmeter> looks like jack is also failing because of gcc6
2016-08-09 13:03:15 <ncopa> clandmeter: no, but there was something in libreoffice that also affected kde or qt
2016-08-09 13:03:32 <ncopa> i think it was different error
2016-08-09 13:04:52 <jirutka> fabled: fix checkapk to work with https repos https://github.com/alpinelinux/abuild/pull/8
2016-08-09 13:27:35 <jirutka> someone is trying figure out how we compute checksums for abuilds: http://stackoverflow.com/questions/38837679/alpine-apk-package-repositories-how-are-the-checksums-calculated
2016-08-09 13:44:08 <fabled> heh
2016-08-09 13:44:25 <fabled> i'm planning to rewrite apk index/package format later this year/early next year
2016-08-09 13:44:51 <fabled> we originally wanted text-based index
2016-08-09 13:44:54 <fabled> and installed database
2016-08-09 13:45:06 <fabled> but our package pool size has grown large enough to justify binary formats
2016-08-09 13:45:17 <fabled> especially for embedded platforms such as armv6
2016-08-09 14:11:38 <clandmeter> ncopa: would it be an idea to add ccache support to abuild? and be able to disable it per: options="!ccache"
2016-08-09 14:23:04 <ncopa> possibly
2016-08-09 14:23:13 <ncopa> you can also set CC=gcc
2016-08-09 14:23:28 <ncopa> in apkbuild
2016-08-09 14:23:57 <clandmeter> you can, but options seems more clear to me.
2016-08-09 14:24:06 <clandmeter> and you dont have to set ccache in abuild.conf anymore
2016-08-09 14:24:25 <clandmeter> so if you install it, it will pick it up automagically
2016-08-09 14:25:05 <clandmeter> i think the path based approach also support c++ compiler cache
2016-08-09 14:29:35 <clandmeter> we could set export PATH="/usr/lib/ccache/bin/:$PATH" by abuild and let options disable it.
2016-08-09 14:56:09 <clandmeter> ncopa: i think by replacing cdrkit, we do not pull in file anymroe.
2016-08-09 14:56:27 <clandmeter> looks to me abuild needs file
2016-08-09 14:56:33 <ncopa> that is likely correct
2016-08-09 14:56:41 <ncopa> what in abuild needs file?
2016-08-09 14:56:47 <clandmeter> i have no idea
2016-08-09 14:56:53 <clandmeter> at the end somwhere
2016-08-09 14:57:27 <clandmeter> -- Installing: /home/buildozer/aports/main/llvm/pkg/llvm/usr/share/llvm/cmake/./LLVMExternalProjectUtils.cmake
2016-08-09 14:57:30 <clandmeter> /usr/bin/abuild: line 2258: file: not found
2016-08-09 14:57:33 <clandmeter> /usr/bin/abuild: line 2258: file: not found
2016-08-09 14:57:35 <clandmeter> >>> llvm*: Running split function static...
2016-08-09 14:58:10 <clandmeter> that line doesnt have file
2016-08-09 14:58:18 <ncopa> its llvm itself
2016-08-09 14:58:21 <ncopa> the APKBUILD
2016-08-09 14:58:45 <ncopa> http://tpaste.us/AjQq
2016-08-09 14:58:45 <clandmeter> ah i didnt check it.
2016-08-09 14:58:49 <ncopa> i'm pushing that
2016-08-09 14:59:00 <clandmeter> ok
2016-08-09 14:59:43 <ncopa> done
2016-08-09 16:41:21 <^7heo> ncopa: did you see the mentions on gh?
2016-08-09 16:51:44 <ncopa> sometimes
2016-08-09 16:51:49 <ncopa> they tend to drown
2016-08-09 17:18:01 <oneinsect> friends quick question
2016-08-09 17:18:31 <oneinsect> when i flash the iso via setup-bootable to an internal emmc
2016-08-09 17:18:35 <oneinsect> it boots fine
2016-08-09 17:19:03 <oneinsect> but lbu ci doesnt work and setup-apkrepos doesnt seem to take /media/mmcblk0p1
2016-08-09 17:19:12 <oneinsect> any ideas?
2016-08-09 17:19:34 <oneinsect> sorry setup-apkcache*
2016-08-09 17:20:29 <oneinsect> okie got it
2016-08-09 17:20:41 <oneinsect> the problem is i should run setup-lbu first
2016-08-09 17:20:44 <oneinsect> thanks solved
2016-08-09 17:27:30 <clandmeter> glad we could help ;-)
2016-08-09 17:32:00 <oneinsect> lol
2016-08-09 17:32:02 <oneinsect> :-D
2016-08-09 17:32:08 <oneinsect> what about wayland
2016-08-09 17:32:14 <oneinsect> are we moving in that direction?
2016-08-09 17:36:52 <clandmeter> I have no idea, there was short talk about it here yesterday.
2016-08-09 18:36:50 <oneinsect_> friends quickly
2016-08-09 18:38:00 <oneinsect_> when i run Xorg -configure.... /var/log/Xorg.0.log says intel_drv.so error relocating intel_drv.so fbPutImage: symbol not found
2016-08-09 18:38:13 <oneinsect_> is it an issue of lazy loading?
2016-08-09 18:51:29 <clandmeter> oneinsect_: yes
2016-08-09 18:51:58 <oneinsect_> darn
2016-08-09 18:52:09 <oneinsect_> according to this guide
2016-08-09 18:52:10 <oneinsect_> http://wiki.alpinelinux.org/wiki/XFCE_Setup
2016-08-09 18:52:31 <oneinsect_> that problem occures here
2016-08-09 18:52:32 <oneinsect_> Xorg -configure
2016-08-09 18:52:47 <oneinsect_> however this seems to work rc-service lxdm start
2016-08-09 19:14:02 <oneinsect_> also no icons when starting lxdm
2016-08-09 19:22:50 <clandmeter> oneinsect_: change theme
2016-08-09 19:22:59 <clandmeter> make sure you have one installed
2016-08-09 19:23:12 <oneinsect_> can you tell me which one to install
2016-08-09 19:23:57 <oneinsect_> apk search theme returns so many
2016-08-09 19:24:59 <oneinsect_> rather suggest something good???
2016-08-09 19:25:12 <oneinsect_> okie let me try gnome-dust-icon-theme
2016-08-09 19:25:35 <oneinsect_> and any ideas on how run Xorg -configure without the lazy loading issue??
2016-08-09 19:27:07 <oneinsect_> and pray where chromium browser??
2016-08-09 19:27:10 <oneinsect_> is*
2016-08-09 19:28:44 <clandmeter> adwaita-icon-theme?
2016-08-09 19:29:01 <oneinsect_> hmmm
2016-08-09 19:29:21 <oneinsect_> darn i get a blank screen now if i run rc-service lxdm start
2016-08-09 19:30:04 <clandmeter> there is only one person who puts love into X on alpine.
2016-08-09 19:30:27 <clandmeter> so its full of issues :|
2016-08-09 19:30:42 <oneinsect_> hmmmmm
2016-08-09 19:31:53 <clandmeter> but you are using the right setup, so i think you should be able to make it work
2016-08-09 19:33:12 <oneinsect_> the blank screen stays for a couple of minutes and then i get lxdm prompt for login
2016-08-09 19:33:29 <oneinsect_> which one works best...any ideas? gnome or mate or xfce ?
2016-08-09 19:33:49 <clandmeter> xfce is what ncopa uses
2016-08-09 19:33:55 <clandmeter> with intel video
2016-08-09 19:33:59 <clandmeter> afaik
2016-08-09 19:34:56 <oneinsect_> hmmmm
2016-08-09 19:36:33 <oneinsect_> i so much wish alpine had a non muslc version
2016-08-09 19:41:46 <jirutka> I thought that there were already discussion about nginx and dynamic modules, so we can modularize nginx package, but I don’t see it in the repo… why?
2016-08-09 19:52:08 <scadu> jirutka: probably because you made the guy who planned it quit :)
2016-08-09 19:52:27 <jirutka> scadu: I didn’t made him to quit
2016-08-09 19:53:11 <jirutka> he quit himself, it was his decision and I even didn’t know what’s happening
2016-08-09 19:53:46 <jirutka> also I have more reasons to quit because of him than he has because of me… so please don’t say that
2016-08-09 19:56:58 <scadu> -> -offtopic or /dev/null
2016-08-09 19:57:32 <jirutka> you’ve started that… but okay, I have nothing more to say about it, if you have, then I’m also in alpine-offtopic :)
2016-08-09 21:25:26 <mitchty> is there any way to have abuild use pigz say for compression? gzip on one core is annoying
2016-08-09 21:29:00 <jirutka> mitchty: hmm, I didn’t know about pigz… is it fully compatible with gzip format?
2016-08-09 21:29:09 <mitchty> jirutka: yep
2016-08-09 21:29:34 <jirutka> mitchty: so you can more or less use it as a drop-in replacement for gzip command?
2016-08-09 21:31:02 <mitchty> jirutka: mostly, it plugs into gnu tar fine, the pigz compressed stuff might be a skosh bigger than gzip due to how it doles out work though, but its no big deal normally
2016-08-09 21:31:25 <mitchty> worst i saw was 2megs on a multigigabyte compression
2016-08-09 21:31:29 <jirutka> hmm, it seems that it has even same CLI arguments
2016-08-09 21:31:43 <jirutka> it may not be so hard to add support for it to abuild
2016-08-09 21:33:11 <jirutka> mitchty: I’ll tell about it to fabled
2016-08-09 21:33:53 <mitchty> jirutka: ok cool, thought i'd ask, would speed up some build processes where compression is the bottleneck
2016-08-09 21:34:04 <jirutka> mitchty: I’m currently working on some bigger packages and Busybox gzip is really very slow
2016-08-09 21:34:17 <jirutka> like, really very very slow
2016-08-09 21:34:35 <jirutka> but not sure if it’s not just a problem of Busybox implementation of gzip
2016-08-09 21:34:48 <mitchty> yeah, takes an hour to compress the ghc-bootstrap package, and all that is is uncompress a file and recompress it, only on one core
2016-08-09 21:34:52 <mitchty> well on an arm box
2016-08-09 21:35:11 <jirutka> it’s slow even on x86_64
2016-08-09 21:35:19 <mitchty> not sure on that to be honest, have not looked at busybox gzip
2016-08-09 23:17:54 <kaniini> yes any issue involving X is most likely an issue of musl's ELF loader being incompliant with the ELF spec
2016-08-09 23:18:24 <^7heo> hhm?
2016-08-09 23:18:44 <kaniini> from earlier
2016-08-09 23:18:48 <^7heo> kaniini: I never saw you here before
2016-08-09 23:19:04 <^7heo> strange that there's an op I discover :p
2016-08-09 23:19:09 <kaniini> ELF requires RTLD_LAZY to actually work correctly
2016-08-09 23:19:43 <kaniini> POSIX also requires (assumes that) the system linker is properly implemented
2016-08-09 23:19:46 <kaniini> the irony
2016-08-09 23:19:49 <kaniini> ;)
2016-08-09 23:43:50 <mitchty> ok so ghc built fine on armhf via the ghc-bootstrap, so that apkbuild should be peachy to import, waiting for cabal and stack to build, but i doubt they'll have issues
2016-08-09 23:45:16 <koorogi> are there any plans to support multilib?
2016-08-10 02:44:56 <mitchty> is this a reasonable way to build an arm alpine docker image? https://raw.githubusercontent.com/lifeeth/docker-arm/master/contrib/mkimage-alpine.sh
2016-08-10 04:02:06 <boingolov> mitchty: that looks schmoove.  but I've yet to do docker on arm
2016-08-10 04:02:43 <boingolov> so far only on intel
2016-08-10 04:04:15 <boingolov> does arm support docker?
2016-08-10 04:04:25 <boingolov> I am assuming yes?
2016-08-10 09:28:12 <leo-unglaub> hey :)
2016-08-10 09:32:57 <ScrumpyJack> hay dude! how's the fire-fighting?
2016-08-10 09:33:21 <ScrumpyJack> hmm, probably off-topic :)
2016-08-10 09:33:27 <ScrumpyJack> ignore me
2016-08-10 09:37:36 <leo-unglaub> fire? dont know ...
2016-08-10 09:37:47 <leo-unglaub> i am a paramedic *g* i just come in when the fire is out *g*
2016-08-10 09:42:11 <suqdiq> not going well
2016-08-10 09:42:23 <suqdiq> fucking country is burning up, 500+ active fires :D
2016-08-10 10:50:59 <^7heo> suqdiq: where? =/
2016-08-10 10:55:26 <suqdiq> Portugal
2016-08-10 10:56:22 <suqdiq> this is why i think we should take our army and disband them and convert them to firemen. firemen are the only heroes in a modern nationstate :D #acab
2016-08-10 11:14:37 <^7heo> =/ Sounds bad.
2016-08-10 11:47:26 <nmeum_> ncopa: I noticed some syslog errors from udev complaining that the input group doesn't exist. This is a group used by udev for input devices by default https://github.com/gentoo/eudev/blob/master/rules/50-udev-default.rules#L30 do you think we should add this group when installing eudev or add it by default by modifying alpine-baselayouts group file?
2016-08-10 11:48:13 <ncopa> nmeum: we should probably add it to alpine-baselayout
2016-08-10 11:48:33 <ncopa> and adjust the permissions for mdev too
2016-08-10 11:48:39 <nmeum> yeah
2016-08-10 11:50:04 <nmeum> any idea which devices are part of udevs input Subsystem?
2016-08-10 11:56:47 <nmeum> ncopa: http://sprunge.us/YZEJ ok?
2016-08-10 11:58:17 <nmeum> (has gid 23 been used before? should I pick a different gid?)
2016-08-10 11:58:30 <ncopa> i wondered the same
2016-08-10 11:58:37 <ncopa> sould probably check git log
2016-08-10 12:00:08 <nmeum> according to the git log it has (at least) not been used since 2.3.0
2016-08-10 12:00:26 <ncopa> what was it used for?
2016-08-10 12:00:49 <ncopa> telnet?
2016-08-10 12:01:12 <^7heo> ncopa: thanks for your comments.
2016-08-10 12:01:15 <nmeum> I don't know the current group file didn't exist before 2.3.0
2016-08-10 12:01:19 <^7heo> ncopa: I'll generate the bt as soon as possible.
2016-08-10 12:01:41 <^7heo> ncopa: don't you have a segfault with the detached header functionality?
2016-08-10 12:01:54 <ncopa> ^7heo: not that i can remember
2016-08-10 12:02:03 <^7heo> that is weird.
2016-08-10 12:02:08 <ncopa> but its probably related
2016-08-10 12:02:11 <^7heo> yeah.
2016-08-10 12:02:23 <ncopa> i think i ctrl-c after 2 tries something
2016-08-10 12:15:35 <nmeum> ncopa: according to http://git.alpinelinux.org/cgit/alpine-baselayout/log/group gid 23 has not been used (at least) since 1.0.1 (no idea where the group file was hosted before that)
2016-08-10 12:15:51 <ncopa> ok
2016-08-10 12:15:54 <ncopa> fair enough
2016-08-10 12:15:59 <ncopa> lets use it
2016-08-10 12:16:11 <ncopa> i wonder if we should bother add it to pre-upgrade script too
2016-08-10 12:16:20 <ncopa> so upgraders also gets it
2016-08-10 12:17:08 <nmeum> well…upgraders get it when merging their existing /etc/group file with /etc/group.apk-new
2016-08-10 12:17:16 <nmeum> but I assume most people don't do that after every upgrade
2016-08-10 12:18:02 <ncopa> exactly
2016-08-10 12:18:27 <nmeum> but well…unless your are using udev you won't need the group until you merged your /etc/mdev.conf with /etc/mdev.conf.apk-new
2016-08-10 12:18:38 <nmeum> and even if your are using udev not having the group only causes a warning
2016-08-10 12:19:23 <nmeum> so I guess it doesn't really matter but it won't really hurt either
2016-08-10 12:26:44 <przemoc> hi, guys.  haven't got time for AL lately, sadly, but I truly believe that introducing some centralized default uids+gids list for given names would be beneficial for many, especially managing many machines.  that would ease maintenance, e.g. making package installation order irrelevant re obtained uids or gids (nowadays most added users/groups do not specify id explicitly).  my passwd/group manageme
2016-08-10 12:26:51 <przemoc> nt library (+ sample app) has not been started yet either, though
2016-08-10 12:42:30 <nmeum> ncopa: so…would you mind if I push the addition of the input group without adding a post-upgrade file or should I add one?
2016-08-10 13:03:12 <ncopa> lets push it without
2016-08-10 13:03:20 <ncopa> and if it causes problems, then we add post-upgrade
2016-08-10 13:03:30 <ncopa> nmeum: ^^^
2016-08-10 13:05:12 <nmeum> alright
2016-08-10 13:10:47 <nmeum> ok it does cause problems if you modified /etc/group but didn't modify /etc/mdev so I guess it is infact a good idea to add it to the post-upgrade script
2016-08-10 13:10:50 <nmeum> will do so
2016-08-10 13:15:20 <nmeum> the mkinitfs group file also needs to be updated
2016-08-10 13:15:56 <nmeum> the group file in the mkinitfs repository is supposed to be identical to the one from alpine-baselayout, right? If that's the case: Why do we keep a seperate group file in the mkinitfs repo?
2016-08-10 13:20:51 <ncopa> i think thats only for early initramfs
2016-08-10 13:21:08 <ncopa> before sysroot is mounted
2016-08-10 13:21:19 <ncopa> so i don think we need modify it
2016-08-10 13:22:03 <nmeum> since the input group is now used by mdev it is also used in the early initramfs => it needs to be added to the initramfs group file
2016-08-10 13:23:36 <nmeum> this is the updated patchset: http://sprunge.us/OBJZ
2016-08-10 13:27:48 <ncopa> ok
2016-08-10 13:28:02 <ncopa> i'll look at in a couple of hours
2016-08-10 13:30:00 <nmeum> could push it on my own as well ;)
2016-08-10 13:34:58 <clandmeter> if you can, why not.
2016-08-10 15:04:00 <mitchty> ok so the ghc-bootstrap in testing works building ghc/cabal/stack and the rest of my patch series so they should be ok to import the rest of the patch series
2016-08-10 15:11:21 <jirutka> what’s the problem with upgraded main/hunspell?
2016-08-10 15:19:04 <^7heo> I just submitted a PR for SIXEL support in xterm. It passed travis. Can we merge? :)
2016-08-10 15:19:48 <^7heo> I would *love* to have sixel support in alpine :)
2016-08-10 15:19:51 <^7heo> with at least some software.
2016-08-10 15:21:33 <kaniini> fabled: what is your opinion on moving apk-tools outside of the alpine project umbrella?
2016-08-10 15:23:18 <jirutka> ^7heo: this looks amazing https://en.wikipedia.org/wiki/Sixel#/media/File:Sixel_Wikipedia_logo.png
2016-08-10 15:24:45 <jirutka> ^7heo: I assume that you’ve already tried that it works as expected?
2016-08-10 15:24:57 <^7heo> I didn't try it no.
2016-08-10 15:25:03 <^7heo> I'm at work, can't build here.
2016-08-10 15:25:37 <jirutka> ^7heo: could you tried at at evening?
2016-08-10 15:31:50 <^7heo> sure
2016-08-10 15:37:42 <fabled> kaniini, not against it, though i'm planning a complete rewrite within next 6months :P
2016-08-10 15:37:57 <fabled> binary file formats for index / installed database
2016-08-10 15:38:06 <kaniini> fabled: well, i'm thinking given that other APK distributions exist now, it makes sense to have it maintained independently
2016-08-10 15:38:14 <fabled> oh?
2016-08-10 15:38:43 <kaniini> fabled: yes, awilfox has been making a distribution called Adelie which uses gentoo
2016-08-10 15:39:15 <^7heo> kaniini: it's only partly relying on apk afaik.
2016-08-10 15:39:34 <kaniini> ^7heo: it uses the apk package manager itself, not abuild etc of course :)
2016-08-10 15:39:46 <kaniini> ^7heo: abuild and apk-tools are two separate products :)
2016-08-10 15:39:48 <^7heo> kaniini: not sure if this is a temporary state to get things working or if it is intended to be permanent.
2016-08-10 15:40:12 <kaniini> ^7heo: permanent
2016-08-10 15:40:30 <^7heo> kaniini: where do you get the information from? IRC or is there some public source?
2016-08-10 15:41:16 <fabled> web site has 'why apk' saying it's fast
2016-08-10 15:41:22 <fabled> so i guess it's more or less permanent
2016-08-10 15:41:39 <^7heo> ok
2016-08-10 15:42:12 <kaniini> ^7heo: the person who started adelie works for me
2016-08-10 15:42:41 <^7heo> kaniini: ah.
2016-08-10 15:42:46 <fabled> :)
2016-08-10 15:43:30 <fabled> anyways, apk is going be on sterdoids if i get done with the binary index / smp support i have in mind.
2016-08-10 15:43:43 <kaniini> we would like to have a single distribution to cover all of our usecases, that is one thing adelie is meant to excel at :P
2016-08-10 15:48:27 <jirutka> fabled: what format are you gonna use for the binary index? sqlite or something more lightweight?
2016-08-10 15:48:57 <fabled> djb cdb type custom binary format with hash table for lookups
2016-08-10 15:49:08 <fabled> i'm going to do atomic updates too
2016-08-10 15:49:41 <fabled> and reuse the format in index, installed db, and .PKGINFO (in .tar pax header)
2016-08-10 15:50:27 <jirutka> fabled: are you sure that custom format is worth it? I mean, I’m always a little suspicious when someone say that he’s gonna develop very custom format for the app
2016-08-10 15:52:09 <fabled> if we want to keep it fast
2016-08-10 15:52:41 <fabled> the point is to be able to mmap it
2016-08-10 15:52:45 <fabled> and use it as run-time data structure
2016-08-10 15:53:11 <fabled> so startup data file loading time is close to 0 (just mmap it)
2016-08-10 15:53:29 <jirutka> apk is already blazing fast, isn’t it? :) I can’t even imagine to be even faster XD
2016-08-10 15:54:34 <fabled> it's tempting my pationt on rpi with multiple full repos
2016-08-10 15:54:49 <fabled> currently the slow bit is loading installed db and indexes
2016-08-10 15:54:57 <jirutka> aha
2016-08-10 15:55:41 <fabled> the other thing that can be sped up is installation, by doing n+1 parallel downloads/extractions/checksumming where n is either number of cores, or user set (long-fat networks)
2016-08-10 15:55:52 <fabled> current architecture does not easily allow for that
2016-08-10 15:55:57 <jirutka> aha
2016-08-10 15:56:09 <fabled> but the way i'm planning to do it fixes that, and few other long term issues
2016-08-10 15:56:17 <fabled> and it's all tied to the way the db works
2016-08-10 15:56:27 <jirutka> how generic will be that format? does it make sense to think about using it even for totally different applications?
2016-08-10 15:56:40 <fabled> using cdb type approach allows incremental modifications, and atomic updates (not in parallel though)
2016-08-10 15:56:59 <fabled> cdb is generic format (key=value)
2016-08-10 15:57:21 <fabled> i want apk's cdb derivative to have fast key lookups, but have structured data
2016-08-10 15:57:42 <fabled> also fast range lookups, so the records are sorted with known seek points
2016-08-10 15:57:57 <fabled> i try to make the file format generic enough
2016-08-10 15:58:10 <fabled> the index and files db are using same format but very different content
2016-08-10 15:58:23 <fabled> i'll probably throw in offline content indexes
2016-08-10 15:58:29 <fabled> so you can lookup files from non-installed packages
2016-08-10 15:59:13 <jirutka> that would be very useful
2016-08-10 16:00:12 <fabled> i actually did the design part few weeks ago, and have pretty much everything drafted out
2016-08-10 16:00:28 <fabled> need to just code the beast
2016-08-10 16:00:49 <fabled> hope to get started in next month or so; i'm finishing up the image building scripts first
2016-08-10 16:00:56 <fabled> aka alpine-iso replacement
2016-08-10 16:00:59 <jirutka> do you have somewhere online? I’d be very interested to read it
2016-08-10 16:01:20 <fabled> no, private notes, that do not make much sense unless you're me ;)
2016-08-10 16:01:32 <jirutka> aha
2016-08-10 16:01:36 <^7heo> I wish there would be more information on who works on what
2016-08-10 16:01:40 <^7heo> and more visibility
2016-08-10 16:01:46 <fabled> it's been adhoc so far
2016-08-10 16:01:52 <fabled> but we've grown
2016-08-10 16:01:55 <^7heo> because if you want to know the distro and its contributors, you kinda have to lurk on IRC 24/7
2016-08-10 16:01:59 <fabled> should probably start updatingsomethinglike that
2016-08-10 16:02:12 <jirutka> good idea, we should probalby start updating that wiki page with todo list
2016-08-10 16:02:23 <fabled> roadmap or similar
2016-08-10 16:02:49 <fabled> the work-in-progress image building script looks something like http://sprunge.us/HSec
2016-08-10 16:03:18 <fabled> documented in ash ;)
2016-08-10 16:03:37 <fabled> it can cross build images
2016-08-10 16:03:43 <fabled> and do incremental builds
2016-08-10 16:03:54 <fabled> need to just finalize the last fixmes
2016-08-10 16:04:27 <jirutka> btw I have a use case, don’t know if you have already support for that… I need to prepare custom VM and i’d like to do it in the same way I’m building rootfs for LXC containers
2016-08-10 16:04:50 <jirutka> so instead of booting ISO image, just build entire disk image on the host system and then just boot it
2016-08-10 16:05:45 <fabled> rootfs ?
2016-08-10 16:05:58 <fabled> or tmpfs image
2016-08-10 16:06:13 <fabled> the new scripts are plugin type to create custom tmpfs images easily
2016-08-10 16:06:23 <jirutka> no tmpfs, persistent FS
2016-08-10 16:06:25 <fabled> for rootfs, you can just do apk --root blah --initdb add
2016-08-10 16:06:47 <jirutka> that’s how we install Alpine on LXC https://github.com/lxc/lxc/blob/master/templates/lxc-alpine.in
2016-08-10 16:06:57 <jirutka> it’s basically like installing it into chroot
2016-08-10 16:07:01 <jirutka> well, exactly like that
2016-08-10 16:07:19 <jirutka> but you don’t need boot loader, kernel etc here
2016-08-10 16:07:41 <jirutka> for VM I need to also setup syslinux
2016-08-10 16:08:38 <jirutka> but I haven’t looked into it much, until now I’ve been installing Alpine only in LXC and plain chroot (these scripts for travis)
2016-08-10 17:10:48 <^7heo> t0mmy [~tprrt@ram31-1-82-234-79-177.fbx.proxad.net] has quit [Ping timeout: 244 seconds]
2016-08-10 17:10:53 <^7heo> damn client
2016-08-10 18:16:33 <vkris> seems useful https://github.com/lxc/lxcfs
2016-08-10 20:11:58 <koorogi> are there any plans for/interest in multilib support in alpine?
2016-08-10 20:25:03 <koorogi> Or is there somewhere else I should be asking to get a response?
2016-08-10 20:40:45 <skarnet> Ask during EU daytime, most Alpine devs are EU-based
2016-08-10 20:43:30 <koorogi> thanks
2016-08-10 22:08:43 <mitchty> woo got idris building as a standalone ish package (no real docs are building yet)
2016-08-10 22:21:15 <mitchty> so as a note, i validated that the ghc-bootstrap in testing builds the remaining bits of my series http://patchwork.alpinelinux.org/patch/2237/ http://patchwork.alpinelinux.org/patch/2238/ http://patchwork.alpinelinux.org/patch/2239/
2016-08-10 22:21:50 <mitchty> so those should be good to go unless there is something egregious in the apkbuilds
2016-08-10 22:23:14 <mitchty> and a general question, should i continue to use patchwork or the github mirror for things
2016-08-10 22:33:29 <vkris> fcolista: testing/dynamips seems belongs to non-free
2016-08-10 22:47:34 <vkris> nope! sorry to bother, https://github.com/GNS3/dynamips/blob/master/RELEASE-NOTES
2016-08-11 07:23:27 <iscsi> morning
2016-08-11 07:23:58 <iscsi> is there official way to add glibc support for certain packages?
2016-08-11 07:24:08 <iscsi> e.g. asterisk
2016-08-11 07:24:19 <iscsi> https://bugs.alpinelinux.org/issues/3503
2016-08-11 07:26:08 <iscsi> because asterisk patch for this issue is untested/unmaintained and not easy for maintaining https://issues.asterisk.org/jira/browse/ASTERISK-24517
2016-08-11 07:33:12 <^7heo> iscsi: wait, you want glibc in alpine?
2016-08-11 07:33:17 <^7heo> iscsi: why are you using alpine then?
2016-08-11 07:34:19 <iscsi> ^7heo: hi
2016-08-11 07:35:55 <^7heo> hi.
2016-08-11 07:36:24 <iscsi> ^7heo: because alpine linux fast, secure and minimalistic and satisfy my requirements
2016-08-11 07:36:48 <^7heo> you have other linuxes which are providing such advantages
2016-08-11 07:36:49 <iscsi> ^7heo: but unfortunately have broken abuild
2016-08-11 07:37:11 <^7heo> and they have asterisk
2016-08-11 07:37:14 <iscsi> like main/asterisk
2016-08-11 07:37:30 <^7heo> iscsi: if you need it, you're welcome to maintain it.
2016-08-11 07:37:34 <skarnet> <iscsi>^7heo: because alpine linux fast, secure and minimalistic and satisfy my requirements
2016-08-11 07:37:48 <skarnet> the thing is, passing on glibc is a big part of why it is so
2016-08-11 07:37:56 <iscsi> sure
2016-08-11 07:37:59 <iscsi> I get it
2016-08-11 07:38:20 <^7heo> skarnet: yeah exactly, so we can't really put glibc in there.
2016-08-11 07:38:25 <skarnet> we *could*
2016-08-11 07:38:33 <^7heo> skarnet: especially not for something like asterisk.
2016-08-11 07:38:45 <^7heo> skarnet: technically yet, but it would defeat the purpose.
2016-08-11 07:38:45 <skarnet> but that's a lot of work for a benefit I'm not qualified to estimate
2016-08-11 07:38:55 <^7heo> s/yet/yes/
2016-08-11 07:40:37 <skarnet> apparently fabled has taken a look at the asterisk problem already
2016-08-11 07:41:24 <skarnet> looks like the Alpine way of solving it would be "instead of putting in the work to make glibc work on Alpine, put in the work to make asterisk work with musl"
2016-08-11 07:41:50 <skarnet> which is the right thing (even if it scales badly ^^)
2016-08-11 07:42:04 <iscsi> agree
2016-08-11 07:42:09 <ScrumpyJack> morning
2016-08-11 07:42:12 <iscsi> but no place for workaround?
2016-08-11 07:43:47 <iscsi> 
ACTION don't want to go back to yocto

2016-08-11 07:43:51 <skarnet> that's not for me to say, but my pov is that workarounds are cool when they're quick to implement - duct tape should be easy to apply
2016-08-11 07:44:32 <skarnet> if there's currently no glibc package in Alpine, then the "workaround" would be a lot of work, maybe just as much work as the real fix XD
2016-08-11 07:50:13 <^7heo> skarnet: what do you mean, scales badly?
2016-08-11 07:50:45 <skarnet> effort has to be spent for every package instead of just one
2016-08-11 07:50:57 <skarnet> but that's still the right thing ;)
2016-08-11 07:51:48 <^7heo> yeah sure, every piece of crap has to be fixed separately...
2016-08-11 07:51:51 <^7heo> we don't do magic here.
2016-08-11 07:52:00 <^7heo> or do we?
2016-08-11 08:24:17 <iscsi> so my only option now is downgrade to asterisk 11
2016-08-11 08:25:14 <ncopa> fabled: what is the status on https://issues.asterisk.org/jira/browse/ASTERISK-24517
2016-08-11 08:26:28 <fabled> ncopa, https://gerrit.asterisk.org/#/c/2932/
2016-08-11 08:28:27 <ncopa> june 2016. moving forward
2016-08-11 08:28:29 <ncopa> very nice
2016-08-11 08:29:00 <ncopa> 	+979, -1104	
2016-08-11 08:29:02 <ncopa> :)
2016-08-11 08:33:55 <fabled> :)
2016-08-11 09:19:08 <vkris> https://github.com/aperezdc/ngx-fancyindex can this be checked if its ok, seems compile / work on knoppix + nginx-1.10.1
2016-08-11 09:19:23 <vkris> if ok I can add to bugs.a.o as request
2016-08-11 09:21:55 <vkris> ok would give a try compiling in AL too
2016-08-11 09:23:20 <ScrumpyJack> would someone be find enough to rebuild mu in edge against libxapian.so.30. It's currently built against libxapian.so.22 (in main)
2016-08-11 09:24:50 <^7heo> damn, the sixel support in xterm doesn't do anything =/
2016-08-11 12:20:57 <kaiyou_> Hi everyone, I asked yesterday on #alpine-linux and I am sorry if it was the wrong place or if my question is simply inappropriate
2016-08-11 12:21:24 <kaiyou_> Still, there are a couple of packages I noticed that would require a rebuild against newer dependencies versions
2016-08-11 12:21:58 <kaiyou_> Someone mentionned bumping and rebuilding the packages but I cannot find any documentation about the process, should I use apkgrel?
2016-08-11 12:26:54 <nmeum> yes, you could use apkgrel -a and send the patches to the ML (there is a wiki article on this subject) or you could open a bug report on bugs.alpinelinux.org
2016-08-11 12:28:58 <ncopa> kaiyou: you mean this?  Details: rsyslog requires so:libfastjson.so.3 but libfastjson now ships libfastjson.so.4 I believe
2016-08-11 12:30:15 <kaiyou_> ncopa, yes this plus a dovecot extension that is still built against an old ABI
2016-08-11 12:30:38 <kaiyou_> I will apkgrel -a and push to patchwork then, thank you!
2016-08-11 12:30:48 <nmeum> ScrumpyJack: testing/mu?
2016-08-11 12:30:53 <ncopa> kaiyou_: do you mix stable repos with edge in /etc/apk/repositories?
2016-08-11 12:31:27 <kaiyou_> not as far as I know, I use the edge Docker image for testing
2016-08-11 12:31:35 <ncopa> ok
2016-08-11 12:31:36 <ncopa> good
2016-08-11 12:32:18 <ncopa> $ apk info -R rsyslog | grep fastjson
2016-08-11 12:32:18 <ncopa> so:libfastjson.so.3
2016-08-11 12:32:21 <ncopa> yes you are right
2016-08-11 12:32:33 <ncopa> we need to check if there are more
2016-08-11 12:33:40 <ScrumpyJack> nmeum: yes
2016-08-11 12:33:46 <ncopa> hm
2016-08-11 12:34:03 <ncopa> looks like we have a bug in apk
2016-08-11 12:34:13 <ncopa> or something else fishy is going on
2016-08-11 12:34:31 <ncopa> $ apk search -r --exact so:libfastjson.so.3
2016-08-11 12:34:36 <ncopa> shows nothing
2016-08-11 12:35:08 <ncopa> but  apk info -R rsyslog shows so:libfastjson.so.3
2016-08-11 12:35:49 <kaiyou_> maybe because so:libfastjson.so.3 is only referenced but never declared?
2016-08-11 12:40:00 <ncopa> abuild and apk should handle that automatically
2016-08-11 12:40:40 <ncopa> ok, only rsylog seems to use it
2016-08-11 12:40:42 <ncopa> i'll rebuild it
2016-08-11 12:41:09 <kaiyou_> okay, and I will bump and send a patch for the dovecot related package
2016-08-11 12:41:38 <^7heo> kaiyou_: the abuild process is VERY simple.
2016-08-11 12:41:50 <^7heo> kaiyou_: I'd encourage you to maintain the package you need, if you can.
2016-08-11 12:42:15 <^7heo> kaiyou_: it shouldn't be too much work, unless the package is hell to build (i.e. is in Go or something)
2016-08-11 12:42:20 <kaiyou_> I will read some documentation and probably keep maintaining those 3 or 4 packages I use yes
2016-08-11 12:42:52 <^7heo> \o?
2016-08-11 12:43:01 <^7heo> yes keyboard, '?' indeed.
2016-08-11 12:43:02 <ncopa> kaiyou_: i pushed rsyslog rebuild
2016-08-11 12:43:05 <kaiyou_> I tried and wrote an abuild script for a new package, could you provide some feedback on what I did right or wrong?
2016-08-11 12:43:09 <kaiyou_> Thank you ncopa (:
2016-08-11 12:43:54 <ncopa> re dovecot
2016-08-11 12:44:16 <ncopa> the plugins needs to be rebuilt for every dovecot update
2016-08-11 12:44:37 <kaiyou_> not every update, but mostly yes, everytime the ABI number is bumped
2016-08-11 12:44:44 <ncopa> which means that we could in theory build the plugins with the dovecot package
2016-08-11 12:45:03 <ncopa> i think the module checks the minor version number
2016-08-11 12:46:11 <ncopa> is it testing/dovecot-antispam-plugin?
2016-08-11 12:46:19 <^7heo> the sixel support for xterm is harder to test than expected.
2016-08-11 12:46:21 <^7heo> damn
2016-08-11 12:46:41 <kaiyou_> ncopa, yes indeed every upstream update will lead to an ABI update, and plugins should be rebuilt
2016-08-11 12:46:51 <kaiyou_> and yes, the one I use and noticed is the antispam plugin
2016-08-11 12:48:38 <ncopa> kaiyou_: i pushed that too now
2016-08-11 12:48:39 <ncopa> thanks!
2016-08-11 12:48:49 <nmeum> ncopa: there seems to be a bug in apk indeed `apk search -r --exact so:libxapian.so.22` also shows nothing but when you do `apk add mu` you get an error that libxapian.so.22 is missing
2016-08-11 12:50:54 <kaiyou_> ncopa, okay, just saw your commit, should I just go and send to the ML next time I see one of those?
2016-08-11 12:53:43 <nmeum> ScrumpyJack: done
2016-08-11 12:54:46 <nmeum> and thanks
2016-08-11 12:56:21 <kaiyou_> ^7heo, if you have feedback on this monstruosity of mine, I would be happy to fix it and learn a bit more about abuild :) https://patchwork.alpinelinux.org/patch/1976/
2016-08-11 13:00:09 <^7heo> I'm gonna review that asap
2016-08-11 13:00:50 <ncopa> kaiyou_: dovecot plugins are an exception, or special case
2016-08-11 13:04:57 <ncopa> i wonder if we should do something similar to this: http://git.alpinelinux.org/cgit/aports/commit/main/dovecot?id=9f3024f08dff221dc786e7430e809cde383688fb
2016-08-11 13:05:06 <ncopa> as it would make maintenance simpler
2016-08-11 13:10:40 <kaiyou_> ncopa, as long as there are not too many plugins I do not see the issue, but maintainance might become a nightmare if many plugins are included
2016-08-11 13:11:14 <ncopa> i think thats the case even if they are not build with main dovecot
2016-08-11 13:12:18 <kaiyou_> also, some of them are currently built from external sources like mercurial, which could be an issue
2016-08-11 13:13:28 <ncopa> yeah
2016-08-11 13:13:46 <ncopa> in theory, we should make a snapshot and provide a tarball for those
2016-08-11 13:14:20 <kaiyou_> I could work on that, where should we host the snapshot?
2016-08-11 13:15:26 <ncopa> ideally you should find something yourself
2016-08-11 13:15:40 <ncopa> alternatively we can put it on dev.alpinelinux.org/archive/
2016-08-11 13:16:14 <ncopa> but that makes it significantly more difficult to maintain it without having ssh access to there
2016-08-11 13:19:20 <kaiyou_> ncopa, I will host it myself then, thank you
2016-08-11 13:20:21 <kaiyou_> if the repository system provides downloadable snapshots for a given commit, is it fine to point there?
2016-08-11 13:23:55 <ncopa> kaiyou_: as long as the checksum of the downloaded snapshot does not change
2016-08-11 13:24:15 <ncopa> for example, gzip has a timestamp field in the header
2016-08-11 13:24:46 <ncopa> so unless its explicitly set to zero, it will cause the checksum to differ every download
2016-08-11 13:26:01 <kaiyou_> okay, I will work on this and get back when I have at least Dovecot and the main plugins as subpackages
2016-08-11 13:27:15 <ncopa> thanks!
2016-08-11 13:27:46 <ncopa> i will likely be away for two weeks from next week
2016-08-11 13:27:55 <ncopa> so you may need ask someone else for feedback
2016-08-11 13:28:46 <kaiyou_> ok, thanks (:
2016-08-11 13:30:17 <ncopa> kaniini: it seems that pkgconf does not include /usr/local/lib/pkgconfig in its default search path
2016-08-11 14:04:41 <vkris> ncopa: kernel modules for exfat seems opensource and available, any interest in  pkging it ?
2016-08-11 14:04:51 <^7heo> Damn, I need a second brain.
2016-08-11 14:04:59 <^7heo> One with a lot more RAM and storage.
2016-08-11 14:05:57 <ncopa> vkris: i'm more interested in getting it into mainline kernel
2016-08-11 14:07:00 <^7heo> ncopa: wouldn't that contribute to bloating the kernel with (mostly) dead weight for most of us?
2016-08-11 14:07:19 <ncopa> it would
2016-08-11 14:07:24 <^7heo> or is there a very important advantage in having that compiled in?
2016-08-11 14:07:30 <ncopa> together with all the other drivers
2016-08-11 14:07:45 <ncopa> i woudl add it as module, not compiled in
2016-08-11 14:08:06 <^7heo> wait
2016-08-11 14:08:08 <vkris> ok, but sdcards are fatning ;)
2016-08-11 14:08:15 <^7heo> <@ncopa> vkris: i'm more interested in getting it into mainline kernel
2016-08-11 14:08:21 <^7heo> what did you mean by that then?
2016-08-11 14:08:29 <^7heo> PACKAGED in the kernel package? ;)
2016-08-11 14:08:35 <ncopa> yes
2016-08-11 14:08:38 <^7heo> ah ok :)
2016-08-11 14:08:46 <^7heo> makes sense.
2016-08-11 14:08:50 <ncopa> not as a thirdparty kernel module package
2016-08-11 14:09:54 <^7heo> yeah yeah, gotcha
2016-08-11 14:09:57 <^7heo> makes sense.
2016-08-11 14:16:14 <kaniini> ncopa: indeed not.  nor does pkg-config itself.
2016-08-11 14:18:30 <ncopa> debians pkg-config apparently search there
2016-08-11 14:18:42 <kaniini> ncopa: --with-pkg-config-dir
2016-08-11 14:18:46 <kaniini> ncopa: configure option :)
2016-08-11 14:18:51 <ncopa> thanks
2016-08-11 14:18:57 <ncopa> what is the default?
2016-08-11 14:19:19 <kaniini> /usr/lib/pkgconfig:/usr/share/pkgconfig
2016-08-11 14:19:34 <ncopa> found it
2016-08-11 14:19:38 <ncopa>             PKGCONFIGDIR="${libdir}/pkgconfig:${datadir}/pkgconfig")
2016-08-11 14:20:06 <kaniini> debian actually patches (!) pkg-config to change the search path
2016-08-11 14:20:17 <ncopa> huh
2016-08-11 14:20:20 <ncopa> ok
2016-08-11 14:27:24 <kaniini> :p
2016-08-11 14:27:54 <ncopa> https://cgit.freedesktop.org/pkg-config/tree/configure.ac#n63
2016-08-11 14:27:59 <ncopa> they do similar
2016-08-11 14:28:12 <ncopa> i suppose i just need to set --with-pkg-config-dir
2016-08-11 14:28:25 <ncopa> i think it makes sense to search in /usr/local
2016-08-11 14:37:33 <leo-unglaub> hey :)
2016-08-11 14:38:38 <nmeum> grüß gott
2016-08-11 14:38:41 <leo-unglaub> :)
2016-08-11 14:38:48 <leo-unglaub> servus :)
2016-08-11 14:39:37 <leo-unglaub> today is a huge day for alpine!
2016-08-11 14:42:10 <leo-unglaub> i am compiling apk for the use on OpenBSD :)
2016-08-11 14:55:12 <ncopa> :)
2016-08-11 14:56:11 <leo-unglaub> yeah, i thought why use a bad package manager on openbsd when i have an excelent one on Alpine ... thats why we have open source, right? to use the tools we love where we want
2016-08-11 15:14:49 <mitchty> so the ghc-bootstrap that barhilion(sp?) uploaded works so this specific patch can be ignored as it has the wrong paths http://patchwork.alpinelinux.org/patch/2236/ all the rest build for x86_64 and armhf so if/when anyone gets a chance to review the rest of that series it should be fine to import functionality wise
2016-08-11 15:16:37 <jirutka> mitchty: are you gonna write ghc package using ghc-bootstrap to compile ghc? so ghc-bootstrap would be used only for bootstrapping ghc itself and not as a dependency for packages?
2016-08-11 15:16:52 <mitchty> jirutka: thats how it works now
2016-08-11 15:17:03 <jirutka> mitchty: aha, great
2016-08-11 15:17:13 <jirutka> mitchty: could you send me link for that ghc package?
2016-08-11 15:17:16 <mitchty> ghc-bootstrap only gets used to build ghc
2016-08-11 15:17:23 <mitchty> http://patchwork.alpinelinux.org/patch/2237/
2016-08-11 15:18:01 <jirutka> does this also build three variants of files as ghc-bootstrap? as you tould me previously, that it builds both static and dynamic…
2016-08-11 15:18:04 <mitchty> noticed i might have left in some git/date related build stuff in it just now
2016-08-11 15:18:18 <mitchty> the ghc runtime? yes
2016-08-11 15:18:23 <mitchty> you need that to build packages
2016-08-11 15:18:43 <jirutka> is it always needed to have three variants? I mean, does it make sense to split them into subpackages?
2016-08-11 15:18:59 <mitchty> that basically is the GhcLibWays variable
2016-08-11 15:19:20 <mitchty> not exactly, it would be 3 separate ghc builds if you did
2016-08-11 15:19:59 <mitchty> and not all of them would be able to compile/build cabal packages if you did that
2016-08-11 15:20:07 <jirutka> it should be possible to identify fails that belongs to a specific variant, after the build, shouldn’t be?
2016-08-11 15:20:17 <jirutka> s/fails/files/
2016-08-11 15:20:51 <mitchty> to a degree, but if you build it with profiled support, which you need for some cabal packages, and don't install those, you can't build
2016-08-11 15:20:59 <mitchty> not sure subpackages would help much tbh
2016-08-11 15:21:36 <jirutka> btw ad these echos – http://haste.fit.cvut.cz/guduraq.sh
2016-08-11 15:23:37 <mitchty> i tried going down the route of subpackages for the runtime system last year, but that was a quagmire
2016-08-11 15:23:52 <jirutka> okay, understand
2016-08-11 15:24:02 <jirutka> I don’t know ghc well, so it was just a suggestion
2016-08-11 15:24:10 <mitchty> things like ghci failed to run unless you had all the runtimes it was compiled with etc...
2016-08-11 15:24:29 <jirutka> just when I see package that has 1 GiB… uff
2016-08-11 15:24:44 <mitchty> its mostly static binaries
2016-08-11 15:24:48 <mitchty> err libraries
2016-08-11 15:25:16 <jirutka> ghc is not requires by packages for runtime, right?
2016-08-11 15:25:20 <mitchty> nope
2016-08-11 15:25:34 <jirutka> okay, then it shouldn’t be such big deal
2016-08-11 15:25:39 <mitchty> well unless you force them to be dynamic
2016-08-11 15:25:45 <mitchty> which is the non default
2016-08-11 15:26:04 <jirutka> okay
2016-08-11 15:26:14 <mitchty> example, i have idris compiling standalone now
2016-08-11 15:26:42 <^7heo> leo-unglaub: a lot of people misunderstand that; and don't get the advantage of portability
2016-08-11 15:26:58 <mitchty> and yeah its big, but its big everywhere really
2016-08-11 15:27:02 <jirutka> also please be consistent in indentation, the lines below `_date=` are indented using two spaces instead of tab
2016-08-11 15:28:04 <leo-unglaub> ^7heo: yeah .. sadly ... but luckily for me i do get it :)
2016-08-11 15:28:25 <mitchty> sure, i can make a pass over all the files and fix that, my bad for not validating beforehand
2016-08-11 15:32:42 <^7heo> mitchty: what's the bootstrap for exactly, in the context of ghc?
2016-08-11 15:32:56 <jirutka> ^7heo: you need ghc to compile ghc ;)
2016-08-11 15:33:00 <mitchty> ^7heo: to build ghc you need ghc to compile itself
2016-08-11 15:33:07 <jirutka> ^7heo: classic chicken and egg problem of self-hosted compilers
2016-08-11 15:33:15 <^7heo> oh
2016-08-11 15:33:18 <^7heo> yeah
2016-08-11 15:33:48 <mitchty> so ghc-bootstrap is a cross-compiled ghc for musl libc
2016-08-11 15:33:56 <mitchty> then you use that to build the native ghc
2016-08-11 15:34:07 <^7heo> I wonder if there are compilers that are written in ASM, that support a very minimal set of the language, sufficient to compile more elaborate compilers, which can in turn compile more elaborate compilers, until the whole thing.
2016-08-11 15:34:15 <^7heo> because that is the way I would do it.
2016-08-11 15:34:25 <jirutka> I have the same problem with Rust, but Rust is gonna provide prebuilt binary for bootstrapping on musl, so we don’t need -bootstrap package :)
2016-08-11 15:34:35 <^7heo> yeah
2016-08-11 15:34:45 <jirutka> ^7heo: that’s more complicated
2016-08-11 15:34:48 <^7heo> ofc it is.
2016-08-11 15:34:52 <^7heo> but it self sufficient.
2016-08-11 15:34:55 <jirutka> I need to go now, see you guys
2016-08-11 15:34:56 <mitchty> easier to cross compile
2016-08-11 15:35:02 <^7heo> sure, much easier.
2016-08-11 15:35:28 <^7heo> but with the solution I'm suggesting, it can essentially be built from scratch each time.
2016-08-11 15:36:00 <mitchty> you're basically describing how old lisp compilers/runtimes were bootstrapped
2016-08-11 15:38:41 <^7heo> I guess
2016-08-11 15:38:56 <^7heo> and that makes sense to me
2016-08-11 15:39:05 <^7heo> as it is entirely testable
2016-08-11 15:39:26 <^7heo> without having to rely on previous versions
2016-08-11 15:40:00 <^7heo> which are essentially those 'less elaborate versions'
2016-08-11 15:40:25 <^7heo> the first one being probably written in asm or something
2016-08-11 15:40:40 <mitchty> http://canonical.org/~kragen/sw/urscheme/ is the closest to that for now
2016-08-11 15:41:02 <mitchty> its a tradeoff
2016-08-11 15:41:22 <mitchty> generally not taken because bootstrapping is so uncommon
2016-08-11 15:42:48 <^7heo> yeah
2016-08-11 18:54:10 <mitchty> jirutka: as a note, only the bootstrap compiler is so large, forcing split-objs, llvm, and ld.gold gets to this size with the native package https://gist.githubusercontent.com/mitchty/3df2dc446b4071c3d81cd720fd5db07b/raw/2a387ff4c0797e4bf0e1b4d4e72a8369852ce575/gistfile1.txt
2016-08-11 19:05:16 <^7heo> why are all those hype techs so brittle?
2016-08-11 19:05:32 <^7heo> docker is pretty solid compared to the rest and it's still rather fragile.
2016-08-11 20:19:33 <StarWarsFan> hi@all
2016-08-11 20:19:48 <StarWarsFan> currently i'm running into an issue with svn checkout on alpine
2016-08-11 20:20:10 <StarWarsFan> using alpine 3.4 and svn 1.9.4
2016-08-11 20:20:25 <StarWarsFan> try the following command:
2016-08-11 20:20:33 <StarWarsFan> svn checkout https://ssl.nettworks.org/svn/fli4l/branches/4.0/trunk/bin/x86_64/usr/share/ca-certificates/mozilla
2016-08-11 20:20:52 <StarWarsFan> this checkout fails with the following error:
2016-08-11 20:21:36 <StarWarsFan> http://sprunge.us/UCcU
2016-08-11 20:22:50 <StarWarsFan> any ideas what happens here?
2016-08-11 20:24:14 <StarWarsFan> i'm just using this on my .zshrc:
2016-08-11 20:24:15 <StarWarsFan> export LANG=en_US.UTF-8
2016-08-11 20:24:15 <StarWarsFan> export LANGUAGE=en_US.UTF-8
2016-08-11 20:24:15 <StarWarsFan> export LC_ALL=en_US.UTF-8
2016-08-11 20:24:21 <StarWarsFan> makes no difference
2016-08-11 20:26:56 <ncopa> StarWarsFan: that smells like an musl issue
2016-08-11 20:27:05 <ncopa> i'll forward it to #musl
2016-08-11 20:27:27 <StarWarsFan> hi!
2016-08-11 20:27:30 <StarWarsFan> ok, thx
2016-08-11 21:13:16 <Klowner> I'm running into a weird linking error against boost which seems to be resolved by rebuilding boost, anyone have any idea what might be up with that?
2016-08-11 21:14:37 <Klowner> as can be seen here: https://travis-ci.org/alpinelinux/aports/builds/151594677
2016-08-11 21:18:43 <^7heo> seriously, "helpers" on devs channels...
2016-08-11 21:19:07 <^7heo> most of them are clueless and just a giant waste of time; assorted with some troll...
2016-08-11 21:19:45 <^7heo> report a bug about the software not treating newlines right, get a giant troll about what newlines are and what binary/builtin does what.
2016-08-11 21:19:48 <^7heo> v_v
2016-08-11 21:20:32 <Klowner> ^7heo: do you suggest they pass up an opportunity to be right about something? :D
2016-08-11 21:23:28 <^7heo> Klowner: yeah I feel like that.
2016-08-11 21:23:34 <^7heo> Klowner: I just wanted to report a bug...
2016-08-11 21:23:42 <^7heo> I guess it doesn't matter, the software sucks anwyay.
2016-08-11 21:23:45 <^7heo> anyway*
2016-08-11 21:23:50 <^7heo> I tried to package it for alpine for 2 or 3 days
2016-08-11 21:23:53 <^7heo> wasted my time.
2016-08-11 21:24:42 <Klowner> toxic dev teams--
2016-08-11 21:25:56 <^7heo> yeah well
2016-08-11 21:26:06 <^7heo> everybody can be toxic given enough annoyance down the line
2016-08-11 21:26:26 <^7heo> I was taxed to be toxic on -offtopic by two persons at least, two days ago.
2016-08-11 21:26:35 <^7heo> but that was the result of a giant annoyance.
2016-08-11 21:27:15 <^7heo> The issue is especially when people can't take a step back and inhaaaaaale deeply to feel better before going back to stuff.
2016-08-11 21:28:04 <^7heo> In any case, it's really hard on IRC to judge the skill level of the person in front of you
2016-08-11 21:28:29 <^7heo> and yet 99% of the people (I'd easily go for 100%, rounded up) judge you after a few sentences.
2016-08-11 21:30:13 <Klowner> that is very true
2016-08-11 21:30:38 <Klowner> and if your initial interactions with someone are based on them asking possibly silly questions, it's easy to default to assuming they're stupid
2016-08-11 21:31:04 <^7heo> yeah
2016-08-11 21:31:32 <^7heo> In any case
2016-08-11 21:31:40 <^7heo> let's replace all the crap.
2016-08-11 21:31:47 <^7heo> and then we will have nice software to rely on.
2016-08-11 21:38:49 <Klowner> preach it!
2016-08-11 21:49:46 <^7heo> my eyes are almost bleeding
2016-08-11 21:49:48 <^7heo> it's almost midnight
2016-08-11 21:50:48 <^7heo> my deadlines are going to kick in, in 11 minutes.
2016-08-11 21:50:50 <^7heo> 10 now v_v
2016-08-11 21:50:52 <^7heo> :'(
2016-08-11 21:53:28 <Klowner> noo
2016-08-11 21:54:21 <^7heo> yeah well
2016-08-11 21:54:26 <^7heo> I will sleep next week end
2016-08-11 21:59:08 <mosez> ^7heo: sorry but you really suck! you are acting like a jackass... there have been multiple people who tried to help you. so just tell the truth!
2016-08-11 21:59:21 <^7heo> mosez: where?
2016-08-11 21:59:52 <mosez> ^7heo: you know where i mean... you are ignoring me now on this mentioned developer chat...
2016-08-11 22:00:09 <^7heo> mosez: if I would be ignoring you, I would ignore you everywhere.
2016-08-11 22:00:19 <^7heo> mosez: I don't ignore "by chat"
2016-08-11 22:00:50 <mosez> ^7heo: here you see my nickname while on gitter i'm using my real name. you know tboerger aka thomas boerger aka mosez ;)
2016-08-11 22:01:04 <^7heo> aaah, I knew I've seen the name somewhere.
2016-08-11 22:01:17 <^7heo> Well, feel offended, not me problem.
2016-08-11 22:01:20 <^7heo> Want to waste my time?
2016-08-11 22:01:22 <^7heo> My problem.
2016-08-11 22:01:22 <mosez> but you already said it... i'm such a troll because i said you should read the docs first
2016-08-11 22:01:29 <^7heo> mosez: what docs?
2016-08-11 22:01:48 <^7heo> you mean the 3 losely put together words for stupid people who don't know how docker works?
2016-08-11 22:01:57 <^7heo> my problem is about what's not in the docs.
2016-08-11 22:02:18 <^7heo> I have had an issue for a long time about two grsec parameters that were preventing me from using drone.
2016-08-11 22:02:41 <^7heo> there's not a SINGLE word of that outside of a very specific post in the alpine linux forums.
2016-08-11 22:03:00 <mosez> yeah... constructive criticism is not your strength. oh, the docs are bad, the docs are wired... i think that's what you said today instead of hey dude, you are missing this and that.
2016-08-11 22:03:26 <^7heo> so yeah, docker isn't ideal, but when people say "Error: Image not found", don't assume that they fucked up installing a software that doesn't even compile to start with.
2016-08-11 22:03:28 <mosez> because nobody ran into this issue so far? otherwise it would be mentioned in the docs...
2016-08-11 22:03:47 <^7heo> mosez: I am not willing to spend time a software I plan to abandon as soon as I have written better.
2016-08-11 22:03:55 <mosez> and even for that brad said please read the logs or at least docker events.
2016-08-11 22:04:38 <mosez> as soon as you have written better.... hahahahaha, good one :D
2016-08-11 22:05:05 <^7heo> mosez: I actually found the error once I knew what image was failing.
2016-08-11 22:05:23 <^7heo> mosez: that wouldn't be TOO hard to say what image is failing, from the output of drone, would it?
2016-08-11 22:05:38 <^7heo> mosez: took me days to find what image was failing, 3 seconds to know why.
2016-08-11 22:05:59 <^7heo> mosez: to be honest, drone sucks quite a lot, it's not hard to write better.
2016-08-11 22:06:33 <^7heo> I have put a losely written python script that uses popen to invoke docker and does some buffering control
2016-08-11 22:06:37 <^7heo> and it's already not too far.
2016-08-11 22:06:40 <^7heo> took me one evening.
2016-08-11 22:07:03 <^7heo> so yeah, if you need hype and go, I guess you can laugh.
2016-08-11 22:07:08 <^7heo> but I don't need either.
2016-08-11 22:07:37 <^7heo> now, it's enough wasted time, and if you want to continue trolling about that, -> -offtopic. I won't answer here.
2016-08-11 22:08:14 <mosez> ^7heo: drone 0.5 is not a stable realease yet, drone just returned the error from docker.
2016-08-11 22:09:11 <mosez> if you are using an unstable developer version what do you expect? full featured without an issues? dreamer...
2016-08-11 22:10:17 <mosez> YOU have started to talk about it here. so who's the troll that needs to talk about the bad drone community that wasted the time to help you getting something running?
2016-08-11 22:10:53 <mosez> now i will ignore your bullshit from now on.
2016-08-11 22:14:02 <Klowner> :parrot:
2016-08-11 22:14:29 <mosez> that makes me so angry -.-
2016-08-11 22:19:04 <^7heo> Klowner: it's all about the noise, there's nothing tangible behind in the end.
2016-08-12 00:31:27 <skarnet> ok, first #musl, now this. Can't I take one week of vacation without everybody losing it and the world going haywire?
2016-08-12 01:19:15 <^7heo> skarnet: u w0t m8?
2016-08-12 09:30:01 <ncopa> StarWarsFan: do you need the svn fix in 3.4-stable?
2016-08-12 09:30:25 <StarWarsFan> exactly
2016-08-12 09:37:29 <ncopa> StarWarsFan: pushed. apk upgrade in a few mins
2016-08-12 09:45:05 <StarWarsFan> great!
2016-08-12 09:47:15 <StarWarsFan> perfect, is working now!
2016-08-12 11:03:05 <sameera88> hi i have created alpine 3.3 docker container and i have installed meteor then i try to run meteor it says like this
2016-08-12 11:04:17 <sameera88> "  /var/www/.meteor/meteor: line 135: /var/www/.meteor/packages/meteor-tool/.1.4.0-1.13j49n2++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/dev_bundle/bin/node: No such file or directory"
2016-08-12 11:33:28 <ncopa> gnu.org is down
2016-08-12 11:33:30 <ncopa> sigh
2016-08-12 11:34:24 <skarnet> why the sigh
2016-08-12 11:34:35 <skarnet> it's its stable state!
2016-08-12 11:34:43 <ncopa> because builder is trying to download diffutils
2016-08-12 11:35:07 <ncopa> and the list of mirrors is on gnu.org too
2016-08-12 11:35:18 <skarnet> you need a mirror for the list of mirrors
2016-08-12 11:35:48 <skarnet> and a list of mirror mirrors
2016-08-12 11:36:12 <skarnet> with a little luck, you won't have to recurse infinitely
2016-08-12 11:36:26 <ncopa> google helped me with a mirror mirror: http://gnu.ist.utl.pt/order/ftp.html
2016-08-12 12:07:31 <clandmeter> its been down whole day
2016-08-12 12:07:59 <clandmeter> probably due to bad software.
2016-08-12 12:10:24 <skarnet> probably due to gnu software.
2016-08-12 12:10:48 <clandmeter> is that ==
2016-08-12 12:10:53 <clandmeter> isnt..
2016-08-12 12:11:02 <skarnet> left to the reader's interpretation :)
2016-08-12 12:11:33 <clandmeter> right, lets not start another rant :)
2016-08-12 12:11:36 <clandmeter> its friday!
2016-08-12 12:11:54 <clandmeter> we love gnu and all its infrastructure!
2016-08-12 12:12:08 <skarnet> my beef today is with uclibc-ng, not with glibc
2016-08-12 12:12:14 <skarnet> so GNU gets a pass today
2016-08-12 12:23:13 <clandmeter> skarnet: i like their release names.
2016-08-12 12:25:06 <skarnet> yeah, if only "delirium tremens" wasn't so descriptive of the dev's normal state
2016-08-12 12:26:10 <^7heo> clandmeter: yeah, let's the the opposite of the rest of the world
2016-08-12 12:26:16 <^7heo> clandmeter: let's troll on EVERY DAY BUT FRIDAY
2016-08-12 12:26:19 <^7heo> 
ACTION hides

2016-08-12 12:26:47 <vkris> is tcp/udp redirection useful or security issue, I guess ash does not have it, http://xmodulo.com/tcp-udp-socket-bash-shell.html
2016-08-12 12:27:33 <skarnet> you wanna do network, get utilities that do network
2016-08-12 12:27:48 <vkris> :), yes I guessed it
2016-08-12 12:28:08 <^7heo> vkris: the point in busybox is to use a minimal tool to avoid the bloat
2016-08-12 12:28:23 <^7heo> vkris: so let's use the UNIX philosophy there. Do one thing and do it well.
2016-08-12 12:28:36 <^7heo> vkris: otherwise you get GNUtemd.
2016-08-12 12:28:50 <vkris> there are 188 pkgs in aports that depend on bash
2016-08-12 12:29:10 <^7heo> vkris: can you please list them, flag them or else?
2016-08-12 12:29:21 <^7heo> vkris: I'd like to solve that.
2016-08-12 12:29:38 <vkris> I wonder if the main/* ones can be revisited to see if bash dep can be avoided
2016-08-12 12:29:40 <clandmeter> vkris: i cound 50
2016-08-12 12:29:45 <clandmeter> count even
2016-08-12 12:30:03 <clandmeter> are you refering to makedep or deps?
2016-08-12 12:30:23 <vkris> clandmeter: hmmm sorry just did a full grep
2016-08-12 12:30:38 <vkris> I guess deps is more accurate
2016-08-12 12:30:55 <clandmeter> we try to prevent the deps.
2016-08-12 12:31:28 <clandmeter> but its impossible to prevent them all, or we need a few more devs for rewriting bash scripts.
2016-08-12 12:31:49 <clandmeter> err converting bash scripts
2016-08-12 12:33:44 <clandmeter> we should make a tool bash2go...
2016-08-12 12:34:12 <skarnet> 
ACTION slaps clandmeter with a large trout

2016-08-12 12:34:20 <vkris> maybe set aside go/rust enthusiasm for while :)
2016-08-12 12:39:22 <vkris> grep ^depends */*/APKBUILD | grep bash | grep ^main | wc -l
2016-08-12 12:39:30 <vkris> looks ok , not much
2016-08-12 12:39:43 <clandmeter> vkris: dont compare those two, or leo-unglaub will get angry.
2016-08-12 12:39:56 <clandmeter> vkris: check pkgs.a.o ;-)
2016-08-12 12:40:01 <vkris> ok ;)
2016-08-12 12:41:39 <^7heo> vkris: I would actually `grep -rl '/bin/bash\|/usr/bin/env\s*bash' . | sort -u | wc -l`
2016-08-12 12:42:44 <leo-unglaub> WUT
2016-08-12 12:42:47 <leo-unglaub> GO SUCKS
2016-08-12 12:42:50 <leo-unglaub> RUST FTW
2016-08-12 12:43:00 <leo-unglaub> 
ACTION mission is done for today!

2016-08-12 12:43:29 <vkris> I think the go/rust devs should make a challenge to create pure linux core distro
2016-08-12 12:43:53 <vkris> where aside linux kernel everything is either go or rust
2016-08-12 12:43:59 <skarnet> nah, they need a new kernel too
2016-08-12 12:44:10 <skarnet> because those languages are so great for low level
2016-08-12 12:44:10 <vkris> :D
2016-08-12 12:44:41 <vkris> go.alpinelinux.org !!
2016-08-12 12:44:58 <vkris> algo , goal ports
2016-08-12 12:56:20 <vkris> sucks or not, a pure blend could prove it, imagine poping the live dvd in, and if it sucks, would result in event->horizon
2016-08-12 12:56:23 <vkris> and if other does not voila ! we have 2 equal and opposite forces ;)
2016-08-12 12:57:10 <vkris> do I recall someone say CERN likes AL
2016-08-12 13:20:11 <ScrumpyJack> I'm trying to get ESA interested
2016-08-12 13:21:23 <ScrumpyJack> (woah, sorry, that sounded a bit name-droppy. and offtopic)
2016-08-12 13:24:04 <leo-unglaub> well, we rust people have our own kernel
2016-08-12 13:24:23 <leo-unglaub> https://www.redox-os.org/
2016-08-12 13:24:29 <leo-unglaub> suck on that GO
2016-08-12 13:27:14 <^7heo> leo-unglaub: <3
2016-08-12 14:08:19 <vkris> any thoughts on pkging https://ctdb.samba.org/ for samba
2016-08-12 14:10:44 <vkris> or maybe just separately
2016-08-12 15:12:00 <Klowner> vkris: looks like it depends on rpc/rpc.h which musl doesn't appear to have
2016-08-12 15:19:57 <leo-unglaub> i have to go
2016-08-12 15:20:02 <leo-unglaub> okay, bad choice of words ..
2016-08-12 15:20:05 <leo-unglaub> i have to rust
2016-08-12 15:20:07 <leo-unglaub> see you later
2016-08-12 15:21:08 <ncopa> lol
2016-08-12 15:22:19 <scadu> kek
2016-08-12 16:16:08 <Klowner> oh, musl :|
2016-08-12 16:16:37 <Klowner> vkris: what's that ctdb package do?
2016-08-12 16:50:39 <vkris> I think it can be used instead of tdb, and samba >= 4.2.0 already has it in source
2016-08-12 17:21:29 <mitchty> quick query for people here, this morning I updated my patches locally for ghc/cabal/stack as jirutka asked, I can fire them off as an updated patch series, but would it be ok to just use a PR to the github mirror?
2016-08-12 17:21:54 <mitchty> would be nice to turn my security back up in gmail so I don't have to use git send-mail, if not no big deal
2016-08-12 17:24:19 <ncopa> mitchty: its ok if you push a PR to github
2016-08-12 17:25:17 <mitchty> ncopa: ok thanks, thought i'd make sure first, if you like you can kill the rest of my patch series in patchwork then
2016-08-12 17:26:16 <ncopa> ok
2016-08-12 17:26:23 <ncopa> thanks
2016-08-12 18:00:48 <przemoc> ncopa: upgrading ffmpeg should be followed by mpv rebuild, because "Running mpv with different versions of the FFmpeg/Libav libraries than
2016-08-12 18:00:51 <przemoc> it was compiled with is no longer supported."
2016-08-12 18:01:41 <przemoc> (it's like that since mpv 0.18.1, which is in edge)
2016-08-12 18:27:28 <Klowner> I mentioned it yesterday, but I needed to rebuild boost because I was getting a couple linker errors with another project. My searching provided some information regarding the need to rebuild boost after upgrading gcc
2016-08-12 21:05:06 <ncopa> przemoc: the ffmpeg ABI changed?
2016-08-13 07:18:01 <coredumb> Hey is that normal that 3.4.3 doesn't yet appear on apk update ?
2016-08-13 07:18:11 <coredumb> fetching from nl.a.o
2016-08-13 13:45:38 <przemoc> ncopa: well, apparently this time ffmpeg upgrade is 100% backward compatible - http://abi-laboratory.pro/tracker/objects_report/ffmpeg/3.1.1/3.1.2/report.html
2016-08-13 13:46:50 <przemoc> it wasn't the case last time, that's why I promptly advised to bump mpv, which doesn't seem to be needed now
2016-08-13 15:33:24 <clandmeter> jirutka: around?
2016-08-13 15:37:14 <clandmeter> is the nginx pkg considered broken?
2016-08-13 16:39:49 <Klowner> jirutka is on vacation, according to his post on my pr :)
2016-08-13 16:40:12 <Klowner> clandmeter: ^
2016-08-13 16:51:59 <Klowner> I now wonder if I should have just put all my APKBUILDs in one pr
2016-08-13 16:53:39 <Klowner> how is pr formed
2016-08-13 16:53:58 <skarnet> just like babby
2016-08-13 16:54:29 <Klowner> haha
2016-08-14 07:42:19 <przemoc> clandmeter: distributions usually keep iperf 2.x as iperf and iperf 3.x as iperf3.  IIRC they're not fully compatible and iperf 3.x feature set is not superset of 2.x, so I'm not sure it's a good move to simply upgrade iperf 2.x to 3.x instead of introducing new package as was requested some time ago (#4864)
2016-08-14 07:44:19 <przemoc> does apk tooling / alpine infrastructure even support downgrading package version if higher one already hit servers?
2016-08-14 07:45:53 <przemoc> I guess it should, because I vaguely remember that I've seen such action in the past in git log, but maybe I'm mistaken
2016-08-14 11:51:21 <clandmeter> przemoc: right, but iperf2 has issues with gcc6, so if somebody is so kind to build iperf2 we can rename iperf to iperf3
2016-08-14 12:08:37 <clandmeter> przemoc: restored :)
2016-08-14 12:42:58 <ncopa> i managed to setup alpine/osx dual boot on my macbook
2016-08-14 14:25:59 <nmeum> fcolista: http://git.alpinelinux.org/cgit/aports/commit/main/py-paramiko/APKBUILD?id=4c22e83130794c8db8c0c05c4d980294e7a35a1a py-cryptography is in community and not in main packages in main should not depend on packages in community (at least if I recall correctly). Would you mind moving py-cryptography and all its dependencies that are not in main/ to main/?
2016-08-14 15:12:56 <jirutka> clandmeter: I’m back; what’s up?
2016-08-14 15:13:04 <jirutka> Klowner:
2016-08-14 15:31:26 <jirutka> Klowner: it’s no problem to put patches for more abuild into single PR, actually it’s better when there are some dependencies between these patches; but these still should be in separate commits
2016-08-14 17:25:02 <przemoc> clandmeter: thanks.  I wasn't aware that someone took iperf 2.x and maintains it further.  2.0.9 was released fairly recently (2016-06-06).
2016-08-14 17:33:57 <przemoc> bvi came to main, so I'll have to check it to evaluate whether it's better or good enough replacement for hexer that I usually use (on debian systems).  bvi didn't have any new release for a few years, so unless it's a feature-complete app, it's not a good sign.  maybe I'll simply package hexer one day.
2016-08-14 17:36:35 <przemoc> sorry, I guess such message should possibly go to -offtopic, haven't joined it yet, but I'll fix my behavior immediately
2016-08-14 18:47:06 <mitchty> jirutka: getting dynamic llvm 3.7.1 is more work than I had planned, up to about 7 patches right now, most unrelated but the cmake build system has changed a ton
2016-08-14 19:11:22 <clandmeter> jirutka: nginx fails to build.
2016-08-14 19:11:29 <clandmeter> i remember you talking about it.
2016-08-14 19:18:38 <clandmeter> przemoc: i took the version fedora is using.
2016-08-14 19:19:46 <mitchty> i'm tempted to take 3.8 versions of most of these files and build a diff manually, so many rejected hunks
2016-08-14 21:18:48 <jirutka> clandmeter: it fails because of luajit… why the hack there’s beta version in luajit package?
2016-08-14 21:18:58 <jirutka> mitchty: dynamic llvm?
2016-08-14 21:19:04 <jirutka> clandmeter: it fails in check phase, maybe because /usr/bin/luajit is a symlink… I’ll look at it… however, it’s IMO very bad idea to use beta version…
2016-08-14 21:23:39 <mitchty> llvm linked dynamically
2016-08-14 21:23:49 <mitchty> aka the executables not being static
2016-08-14 21:23:59 <mitchty> for llvm3.7
2016-08-14 21:24:15 <mitchty> via cmake at least
2016-08-14 21:28:53 <jirutka> mitchty: for ghc?
2016-08-14 21:32:05 <jirutka> clandmeter: I’ve fixed it and gonna push it to the PR in a moment
2016-08-14 21:44:55 <jirutka> clandmeter: the problem was that nginx-lua-module can’t autodetect luajit-2.1 in its configure script, so I’ve added env variables to tell it where to find luajit; according to readme luajit-2.1 is supported and it builds fine, we’re green again https://github.com/alpinelinux/aports/pull/200 :)
2016-08-14 21:47:43 <jirutka> clandmeter: I did a quick test with `ngx.say("Hello world!")` and it didn’t crashed, so hopefully it will be okay :)
2016-08-14 21:48:29 <mitchty> jirutka: pretty much, that package is just big, was wanting to slim it down
2016-08-14 21:52:16 <jirutka> mitchty: what’s upstream opinion about dynamic linking of llvm? do they care that their package is awfully huge? :)
2016-08-14 21:52:50 <mitchty> jirutka: haven't asked yet, but i'm on 9 patches and ready to go get a few stouts
2016-08-14 22:00:37 <mitchty> wonder if it would be easier to convert 3.7.1 to using autoconf
2016-08-14 22:01:59 <jirutka> I’ve been also thinking about it
2016-08-14 22:02:51 <jirutka> wait a moment… so you’re not patching ghc, but llvm3.7?
2016-08-14 22:03:00 <mitchty> yep
2016-08-14 22:03:06 <jirutka> it’s so broken?
2016-08-14 22:03:14 <jirutka> what exactly?
2016-08-14 22:03:20 <mitchty> not that bad but i was trying to get patches to cleanly apply
2016-08-14 22:03:31 <mitchty> a lot changed in cmake from 3.7.1 to 3.8
2016-08-14 22:03:39 <mitchty> err the cmake files
2016-08-14 22:03:53 <mitchty> i was trying to be lazy, but it turns out i probably am doing more work
2016-08-14 22:04:09 <jirutka> I know, but what exactly is broken that you cannot dynamically link it in ghc?
2016-08-14 22:04:15 <mitchty> nothing
2016-08-14 22:04:23 <mitchty> i just wanted to make the llvm3.7 package smaller
2016-08-14 22:04:28 <jirutka> ahaa
2016-08-14 22:04:31 <jirutka> sorry, I’m too tired
2016-08-14 22:04:42 <jirutka> I thought that you want to make ghc smaller
2016-08-14 22:04:51 <jirutka> ah, yeah, not it makes more sense XD
2016-08-14 22:04:57 <jirutka> I should go sleep
2016-08-14 22:04:58 <mitchty> its 300MiB installed
2016-08-14 22:05:05 <jirutka> yea, I know
2016-08-14 22:05:12 <mitchty> ghc i mean
2016-08-14 22:05:17 <mitchty> the bootstraps the huge one
2016-08-14 22:05:30 <jirutka> aha
2016-08-14 22:07:02 <jirutka> well, about llvm, there are really too many changes between 3.7 and 3.8, using autoconf instead of CMake for 3.7 will be probably really easier and more reliable way
2016-08-14 22:07:29 <jirutka> well, if autoconf supports dynamically linked llvm binaries
2016-08-14 22:07:30 <mitchty> yeah, just a lot of conflicting changes to the cmake builds from windows and go and other packages
2016-08-14 22:09:49 <jirutka> okay, good luck with that :) I go to sleep, I’ll look at your PR 205 tomorrow
2016-08-14 22:09:54 <jirutka> see ya
2016-08-15 08:00:56 <coredumb> question about APKBUILD
2016-08-15 08:01:31 <coredumb> can a subpackage not be dependant of its original package ?
2016-08-15 08:02:04 <coredumb> or if not deps on $package set not detected this would make it "standalone" ?
2016-08-15 08:53:40 <ScrumpyJack> coredumb: subpackages don't depend on "parent" package
2016-08-15 08:55:09 <coredumb> ScrumpyJack: excellent maked my life easier then :)
2016-08-15 08:55:13 <coredumb> makes*
2016-08-15 10:10:23 <coredumb> ScrumpyJack: what's the correct way to have man pages included in subpackage ?
2016-08-15 10:13:31 <przemoc> coredumb: usually packages have only one -doc subpackage that by default (i.e. without the need for specifying own doc() function) grab /usr/share/doc and /usr/share/man content
2016-08-15 10:14:22 <coredumb> przemoc: I know but let's say for corner cases where subpackage has binary not needed by the parent package
2016-08-15 10:14:37 <coredumb> wouldn't make sense to have the man pages in parent package right ?
2016-08-15 10:15:12 <coredumb> so I can compress the man pages manually and it will only warn me that there's a man/ directory without being a -doc pkg ?
2016-08-15 10:17:31 <przemoc> I think we tend to ship man pages collectively even if binaries are split into more than one package
2016-08-15 10:17:57 <coredumb> I think we do but this one bothers me a bit :D
2016-08-15 10:17:59 <przemoc> but would have to investigate aports thoroughly to say it with 100% certainty
2016-08-15 10:20:16 <coredumb> don't bother I'll wait for my build to fail (or not) :D
2016-08-15 10:20:23 <coredumb> it's just a bit long ^^
2016-08-15 10:24:16 <ScrumpyJack> coredumb: what are you packaging?
2016-08-15 10:24:43 <coredumb> upgrading the testing/pdns package
2016-08-15 10:24:55 <coredumb> adding pdns-recursor at the same time
2016-08-15 10:25:51 <coredumb> maybe adding a pdns-recursor as a separate package is the correct solution but as their versions are linked it felt a bit weird not doing them at the same time
2016-08-15 10:26:25 <coredumb> but indeed as pdns-recursor can be installed without pdns it doesn't make sense to bundle man pages for it in the parent pdns package
2016-08-15 10:28:10 <przemoc> coredumb: yeah, you'll get warning if there are man pages in non -doc package
2016-08-15 10:29:01 <przemoc> default doc packaging compresses man pages for you
2016-08-15 10:29:43 <coredumb> przemoc: it fails if they're not compressed though, so it should be acceptable if I compress them in the subpackage
2016-08-15 10:29:56 <coredumb> I mean is the warning acceptable or not ?
2016-08-15 10:32:43 <przemoc> I don't remember having -Werror in abuild ;)
2016-08-15 10:34:20 <coredumb> :D
2016-08-15 10:34:38 <coredumb> ok so pre-compressed man pages went through
2016-08-15 10:34:46 <coredumb> let's try this out :D
2016-08-15 10:40:11 <coredumb> yeah ok can't have pre/post script in subpackages ... guess that's my answer to all this tinkering ...
2016-08-15 10:44:01 <przemoc> I understand desire for splitting -doc, but to make it all consistent packaging would need to be reworked a bit IMHO, main package would always install all binary subpackages, and -doc package would always install all doc subpackages.  IOW main binary package and main doc package would never have any files and only depend on subpackages, which could be often only 1 of each kind in most cases.  it wou
2016-08-15 10:44:07 <przemoc> ld be different than what most distros do, but it would be cleaner.
2016-08-15 10:47:35 <jirutka> clandmeter: are you here?
2016-08-15 10:51:46 <coredumb> przemoc: I think I'll just add a new separate package for pdns-recursor
2016-08-15 10:51:53 <coredumb> will make things easier I guess
2016-08-15 10:55:52 <przemoc> sure, pdns already have docs (schemas) related to its backedns (that have separete subpkgs), so I think that adding pdns-recursor stuff there won't be a problem at all
2016-08-15 12:04:45 <coredumb> przemoc: actually the backend requires pdns to work but recursor is a complete entity and can be used without installing pdns at all so I'm gonna go for the separate package, will be cleaner ^^
2016-08-15 12:11:44 <vkris> skarnet: http://www.phoronix.com/scan.php?page=news_item&px=Google-Fuchsia-OS
2016-08-15 12:12:24 <vkris> great now we can make AL in peace no DARTing, RUSTing or making it GO :-))
2016-08-15 12:24:30 <clandmeter2> jirutka: here i am
2016-08-15 12:25:46 <jirutka> clandmeter2: could you please merge http://tpaste.us/2zXv ? (it’s extracted from https://github.com/alpinelinux/aports/pull/204)
2016-08-15 12:28:15 <clandmeter2> jirutka: done
2016-08-15 12:29:00 <jirutka> clandmeter2: thanks
2016-08-15 12:29:01 <clandmeter2> jirutka: it doesnt bump pkgrel
2016-08-15 12:29:33 <clandmeter2> jirutka: whats up with nginx pg?
2016-08-15 12:29:36 <clandmeter2> pkg..
2016-08-15 12:29:44 <jirutka> clandmeter2: uh, right, I overlooked this :(
2016-08-15 12:30:05 <jirutka> clandmeter2: I think that it’s ready to be merged https://github.com/alpinelinux/aports/pull/200
2016-08-15 12:30:29 <clandmeter2> ok, cause current master also has build issues.
2016-08-15 12:30:45 <jirutka> clandmeter2: this is fixed by the last commit in this PR
2016-08-15 12:30:54 <jirutka> clandmeter2: https://github.com/alpinelinux/aports/pull/200/commits/629477bd44f422343c2754ee23e6cb55cd35f6c3
2016-08-15 12:31:20 <clandmeter2> btw, i pushed luajit cause it didnt build on aarch64
2016-08-15 12:31:43 <clandmeter2> i hope it goes stable before new 3.5
2016-08-15 12:32:50 <jirutka> clandmeter2: I’m not so optimistic about luajit-2.1, Mike Pall is not working on it anymore and the development seems to be quite stuck
2016-08-15 12:33:51 <jirutka> clandmeter2: hmm, but according to commit history he’s still working on it
2016-08-15 12:34:29 <clandmeter2> lets see what happends, if we have issues in master, we can revert it and ill disable it on aarch64
2016-08-15 12:35:11 <jirutka> clandmeter2: yeah
2016-08-15 12:35:32 <clandmeter2> that change pulls in pkgconf, but isnt that a part of alpine-sdk?
2016-08-15 12:35:43 <clandmeter2> or build-base?
2016-08-15 12:35:49 <jirutka> clandmeter2:
2016-08-15 12:35:51 <jirutka> 5 months ago 	v2.1.0-beta2
2016-08-15 12:35:51 <jirutka> 11 months ago 	v2.1.0-beta1
2016-08-15 12:35:53 <jirutka> 15 months ago 	v2.0.4
2016-08-15 12:36:41 <jirutka> clandmeter2: not as a direct dependency, maybe just a transitive dep
2016-08-15 12:38:28 <clandmeter2> oh i didnt see the other 2 lines...
2016-08-15 12:38:37 <clandmeter2> im not on my desktop
2016-08-15 12:41:28 <clandmeter2> jirutka: can you squash them and summerise?
2016-08-15 12:42:54 <jirutka> clandmeter2: all of the commits? I think that I’d be better to keep them separate, maybe just squash “add dynamic module XYZ” into a single commit
2016-08-15 12:44:03 <clandmeter2> ok np.
2016-08-15 12:44:20 <jirutka> clandmeter2: okay, give me a sec
2016-08-15 12:55:49 <jirutka> clandmeter2: done, now it’s in 5 commits; I prefer to keep these separated to be easier for review (later if someone needed to find why/when was something changed), each contains single logical bunch of work
2016-08-15 14:30:00 <Klowner> bah, darn git config hosing up whitespace in my patch files
2016-08-15 16:27:29 <BitL0G1c> does anyone use logcheck ?
2016-08-15 19:09:06 <Klowner> yep, definitely can't build this package unless I first rebuild boost
2016-08-15 19:16:05 <ncopa> hi
2016-08-15 19:16:13 <ncopa> jirutka: thanks for fixing discout. you beat me to it
2016-08-15 19:16:21 <ncopa> and sorry for messing it up
2016-08-15 19:16:38 <jirutka> ncopa: you’re welcome :)
2016-08-15 19:17:17 <ncopa> yesterday i managed to get alpine installed on my mbp (with dual boot osx)
2016-08-15 19:17:28 <ncopa> but icons are super tiny
2016-08-15 19:17:45 <ncopa> and xorg thinks the dpi is 96x96
2016-08-15 19:22:29 <Klowner> is main/boost currently buildable? 6c94177 seems to have broken it for me (and travis)
2016-08-15 19:23:08 <Klowner> /usr/bin/abuild: line 1: /home/travis/build/alpinelinux/aports/main/boost/src/boost_1_60_0/tools/build/src/engine/bin.linux/bjam: not found
2016-08-15 19:25:03 <Klowner> also thanks for merging my stuff, jirutka !
2016-08-15 19:26:59 <scadu> built mopidy 2.0.1 with py-gst1 but mopidy failed to run: http://tpaste.us/3qXB anyone has an idea? checked 1.1.2 which seems to work with gst-*0.10. maybe I'm just blind or too tired today. mopidy APKBUILD: http://tpaste.us/Aydk py-gst1: http://tpaste.us/3YNM yep, if it comes py-gst1 I just bumped from 0.10 to the current gstreamer version in Alpine which is 1.8.1.
2016-08-15 19:54:01 <ncopa> oh no /o\
2016-08-15 19:55:10 <ncopa> http://tpaste.us/AvdZ
2016-08-15 19:55:22 <ncopa> libpng seems to have broken ABI
2016-08-15 20:02:13 <ncopa> yes
2016-08-15 20:02:20 <ncopa> downgrading solved it
2016-08-15 21:17:06 <mitchty> jirutka: ok so i recompiled the bootstrap package with -fPIC but then i thought why not compare all the relocs to what was there, and there is no difference, so is your system just a 3.4.2 system with a grsec kernel where you get the fun ld error too?
2016-08-15 21:18:18 <mitchty> specifically, i don't see any relocation that would kick that off in any shared library https://gist.githubusercontent.com/mitchty/53c5a0da021ed380c7309752dc9fcb18/raw/cb757c43cf0a992be36c89e9f7d3d7803c80de27/gistfile1.txt
2016-08-15 21:21:09 <tiaz> hey all, is there any provision for preseed files/autoinstall? if not, is it planned?
2016-08-15 21:21:19 <tiaz> I'd be happy to help with that if it's underway
2016-08-15 21:40:53 <Klowner> is there a master build server that builds all the official packages periodically? Anyone know how that's set up?
2016-08-15 21:46:00 <clandmeter> Klowner: sorry about boost, fix is applied.
2016-08-15 21:46:26 <Klowner> yay, thanks clandmeter
2016-08-15 21:47:39 <clandmeter> Klowner: its not periodically
2016-08-15 21:47:52 <Klowner> it seemed like it needed a rebuild anyway, I was having weird linker issues
2016-08-15 21:48:37 <clandmeter> we have an mqtt msg system, git announces to it and then the builders pick that up.
2016-08-15 21:48:46 <Klowner> ahh, nifty
2016-08-15 22:12:19 <Klowner> that boost change was literally character for character identical to the change I added and confused me for a good minute
2016-08-15 22:39:56 <Klowner> clandmeter: so would that change to boost would trigger a rebuild? And if so, is it possible that it hasn't been reflected in the repositories yet?
2016-08-15 22:43:45 <jirutka> clandmeter: you haven’t bumped pkgrel, so boost will not be rebuilt…
2016-08-15 22:45:10 <jirutka> Klowner: ^
2016-08-15 22:45:44 <Klowner> cool, thanks, jirutka
2016-08-15 23:02:19 <Klowner> yep, still linker errors against boost
2016-08-15 23:12:07 <nmeum> I just triggered a boost rebuild
2016-08-15 23:12:24 <Klowner> eeeexcellent
2016-08-16 00:50:21 <Klowner> yeeeah, builds now
2016-08-16 07:07:06 <clandmeter> jirutka: yes, it didnt need a rebuild.
2016-08-16 08:59:29 <clandmeter> where are all the smart people today?
2016-08-16 09:00:10 <skarnet> they're back at work, so the smart is going away real fast
2016-08-16 09:04:42 <jirutka> hi
2016-08-16 09:06:50 <clandmeter> jirutka: thats the spirit!
2016-08-16 09:10:33 <skarnet> 
ACTION has no spirit

2016-08-16 09:10:56 <clandmeter> 
ACTION hugs skarnet 

2016-08-16 09:11:17 <jirutka> XD
2016-08-16 09:11:25 <jirutka> what’s up? :)
2016-08-16 09:11:51 <clandmeter> fftw fails on aarch64
2016-08-16 09:12:55 <clandmeter> good thing is, i have a fix. bad thing, i have no idea why.
2016-08-16 09:12:59 <jirutka> fastest fourier transform in the west… maybe they don’t have aarch64 in the west yet? :P
2016-08-16 09:13:23 <skarnet> transforms faster than its shadow
2016-08-16 09:13:51 <clandmeter> the issue is here: https://github.com/FFTW/fftw3/blob/master/kernel/cycle.h#L441
2016-08-16 09:14:03 <clandmeter> CLOCK_SGI_CYCLE is defined.
2016-08-16 09:14:14 <clandmeter> i have no idea what that is.
2016-08-16 09:15:10 <clandmeter> it should instead use https://github.com/FFTW/fftw3/blob/master/kernel/cycle.h#L542
2016-08-16 09:15:16 <jirutka> I’m sure that skarnet has definitely more spirit in C stuff than me
2016-08-16 09:15:21 <clandmeter> which it ofcourse does.
2016-08-16 09:15:37 <clandmeter> but using both is probably not a good idea :)
2016-08-16 09:16:00 <clandmeter> just removing the first part makes it build.
2016-08-16 09:16:13 <clandmeter> but that doesnt really *fix* it.
2016-08-16 09:17:47 <jirutka> it’s weird that CLOCK_SGI_CYCLE is defined on aarch64, it should exist only on SGI platform
2016-08-16 09:19:29 <jirutka> what do you mean that it makes it build, but doesn’t really fix it?
2016-08-16 09:20:59 <clandmeter> its a hack to remove the first part
2016-08-16 09:21:31 <clandmeter> looks like musl defines it http://git.musl-libc.org/cgit/musl/tree/include/time.h#n95
2016-08-16 09:23:33 <jirutka> hm, so what about adding `&& !defined(__aarch64__)`?
2016-08-16 09:26:22 <jirutka> clandmeter: ready for merge https://github.com/alpinelinux/aports/pull/210
2016-08-16 09:28:03 <clandmeter> jirutka: thx again for the hint about .patch on PR.
2016-08-16 09:32:08 <scadu> anyone has an idea what might be wrong http://tpaste.us/AoJg ? asked yesterday around 10PM CEST so probably too late. I build mopidy 2.0.1 with gst-*1 and py-gst1. mopidy APKBUILD: http://tpaste.us/Ajg1 py-gst1: http://tpaste.us/2DRO
2016-08-16 09:51:49 <clandmeter> scadu: no idea, could be that some module is using py3?
2016-08-16 09:56:50 <^7heo> scadu: missing symlink?
2016-08-16 09:57:20 <^7heo> scadu: `sudo find /usr/lib/ -name '*libpython*'`
2016-08-16 10:01:15 <scadu> clandmeter: ^7heo will check both.
2016-08-16 10:07:33 <scadu> clandmeter: well, same error when python3 added to depends and python3-dev added to makedepends.
2016-08-16 10:08:09 <^7heo> scadu: so it's an APKBUILD problem?
2016-08-16 10:08:25 <^7heo> sorry, I stopped reading after the first paste.
2016-08-16 10:08:35 <^7heo> useless question; I'll check the apkbuild.
2016-08-16 10:12:44 <^7heo> scadu: wait, did Mopidy switch to python3 between 1.1.2 and 2.0.1?
2016-08-16 10:15:16 <scadu> ^7heo: no.
2016-08-16 10:16:25 <^7heo> ok
2016-08-16 10:22:15 <jirutka> scadu: python-dev should pull python2-dev, but to be sure, replace python-dev with python2-dev
2016-08-16 10:30:59 <scadu> jirutka: still the same. http://tpaste.us/GBVW error with loading libpython2.7.so does nothing.
2016-08-16 10:33:12 <^7heo> scadu: did you check for a missing link?
2016-08-16 10:33:18 <jirutka> scadu: hmm, this doesn’t mean that it can’t find libpython, the actual error is: ValueError: Namespace GstPbutils not available
2016-08-16 10:33:29 <^7heo> scadu: because according to your trace, there is no such file.
2016-08-16 10:33:57 <^7heo> jirutka: "No such file or directory" is clear for me
2016-08-16 10:34:12 <jirutka> ^7heo: read the rest of the stack trace
2016-08-16 10:34:18 <^7heo> jirutka: I did.
2016-08-16 10:34:31 <^7heo> jirutka: but I ususally treat the "No such file or directory" errors first.
2016-08-16 10:34:39 <^7heo> jirutka: as it usually solves the rest of the issues.
2016-08-16 10:34:55 <scadu> jirutka: that's right. and I'm not sure how to deal with it since gstreamer-plugins-base1 is installed
2016-08-16 10:35:12 <jirutka> scadu: does /usr/lib/libpython2.7.so exists? it should be a symlink to /usr/lib/libpython2.7.so.1.0… does that file exists?
2016-08-16 10:36:07 <^7heo> yeah, exactly my question.
2016-08-16 10:36:19 <scadu> jirutka: already checked.
2016-08-16 10:36:23 <scadu> jirutka: jirutka: ls -l /usr/lib/libpython2.7.so.1.0
2016-08-16 10:36:25 <scadu> -r-xr-xr-x    1 root     root       1585304 Jul 18 19:21 /usr/lib/libpython2.7.so.1.0
2016-08-16 10:36:52 <jirutka> so that’s how I said, the problem is not missing libpython, it’s just misleading error message
2016-08-16 10:36:53 <^7heo> scadu: ls -l /usr/lib/libpython2.7.so
2016-08-16 10:37:18 <^7heo> scadu: cd /usr/lib; sudo ln -s libpython2.7.so.1.0 libpython2.7.so
2016-08-16 10:37:49 <jirutka> which abuild provides gstreamer-plugins-base1?
2016-08-16 10:39:05 <scadu> jirutka: you are right, /usr/lib/libpython2.7.so does not exist. there is only libpython2.7.so.1.0
2016-08-16 10:39:36 <^7heo> god I hate being ignored when I provide a solution.
2016-08-16 10:39:57 <skarnet> you and me and everyone else :D
2016-08-16 10:40:00 <^7heo> scadu: jirutka != ^7heo
2016-08-16 10:40:11 <^7heo> skarnet: yeah...
2016-08-16 10:40:15 <^7heo> skarnet: moin btw.
2016-08-16 10:40:21 <scadu> jirutka: main/gst-plugins-base1
2016-08-16 10:41:18 <^7heo> scadu: what's wrong with you ffs? =/
2016-08-16 10:41:18 <scadu> ^7heo: I thought it's not the case.;)
2016-08-16 10:42:04 <^7heo> what did I ever do to you to for you to seldom answer to what I write you, ignore what I advise to you do (which would fix at least part of your error trace)
2016-08-16 10:42:14 <jirutka> ^7heo: you were right, master
2016-08-16 10:42:21 <^7heo> jirutka: wat?
2016-08-16 10:43:08 <jirutka> ^7heo: about missing libpython
2016-08-16 10:43:20 <^7heo> jirutka: the symlink?
2016-08-16 10:43:42 <^7heo> jirutka: well, it's missing it, it doesn't cost much to create it, at least we know what's the problem then; if the issue goes away.
2016-08-16 10:43:55 <^7heo> jirutka: as I pasted, it's only `cd /usr/lib; sudo ln -s libpython2.7.so.1.0 libpython2.7.so`
2016-08-16 10:44:09 <jirutka> ^7heo: yeah; I thought that when we both asked scadu to check it, then I should not doubt that these files exists
2016-08-16 10:44:25 <^7heo> jirutka: and then if the error is there, we can troubleshoot further.
2016-08-16 10:44:45 <^7heo> jirutka: and then if the error is NOT there, we can ponder where to create that symlink (probably in the libpython APKBUILD)
2016-08-16 10:45:29 <^7heo> I mean, I usually fix my system as I go, for simple stuff like this; but it's obviously better to take the time to fix the distro for everyone, should we encounter that kind of issue.
2016-08-16 10:45:33 <jirutka> ^7heo: yeah, but this is very obvious, so I thought that he should be able to check this even without us and thus problem must be somewhere else
2016-08-16 10:46:00 <^7heo> jirutka: you've never worked in a hotline :D
2016-08-16 10:46:01 <jirutka> ^7heo: wait a moment, these files are correct on my Alpine system
2016-08-16 10:46:17 <skarnet> Have you tried turning it off and on again?
2016-08-16 10:46:23 <jirutka> ^7heo: no, but ppl are often angry when I underestimates them…
2016-08-16 10:46:26 <^7heo> jirutka: lrwxrwxrwx    1 root     root            19 Aug  1 00:06 /usr/lib/libpython2.7.so -> libpython2.7.so.1.0
2016-08-16 10:46:29 <^7heo> Same here.
2016-08-16 10:46:42 <przemoc> verless-so .so are usually provided by -dev packages only, as apps should link to what SONAME is, which is usually .so.MAJVER, so this .so.MAJVER should be provided with non-dev package
2016-08-16 10:46:56 <^7heo> skarnet: I am pretty much sure it has been attempted.
2016-08-16 10:47:16 <jirutka> ll /usr/lib | grep python2.7
2016-08-16 10:47:16 <jirutka> lrwxrwxrwx    1 root     root          19 Aug 16 12:38 libpython2.7.so -> libpython2.7.so.1.0
2016-08-16 10:47:16 <jirutka> -r-xr-xr-x    1 root     root        1.5M Jul 18 21:21 libpython2.7.so.1.0
2016-08-16 10:47:16 <jirutka> drwxr-xr-x    1 root     root       13.7K Aug 16 12:38 python2.7
2016-08-16 10:47:25 <scadu> edge?
2016-08-16 10:47:29 <^7heo> edge here.
2016-08-16 10:47:39 <jirutka> same here, also edge
2016-08-16 10:47:45 <^7heo> but anyway, if you develop APKBUILDs, you need to use edge.
2016-08-16 10:47:50 <^7heo> we obviously should test against non-edge
2016-08-16 10:47:57 <^7heo> but never develop with non-edge.
2016-08-16 10:47:57 <jirutka> aha
2016-08-16 10:48:11 <jirutka> so it’s broken in v3.4?
2016-08-16 10:58:15 <scadu> ^7heo: checked once again with clean environment to make it sure. libpython2.70.so links to libpython2.7.so.1.0 but the issue remains. http://tpaste.us/2bjZ
2016-08-16 10:59:36 <^7heo> scadu: yep, but at least we have cleared that it's not from the missing lib now ;)
2016-08-16 11:00:55 <scadu> ^7heo: sorry I didn't reply you earlier.
2016-08-16 11:01:04 <^7heo> what I would check, now, is if the GstPbutils you're using have the version 1.0
2016-08-16 11:01:20 <^7heo> scadu: all good, I'm tired and a little grumphy.
2016-08-16 11:02:00 <^7heo> scadu: can you try to open a python interpreter and try: from mopidy.internal.gi import Gst?
2016-08-16 11:03:43 <jirutka> clandmeter: https://github.com/alpinelinux/aports/pull/212
2016-08-16 11:07:58 <scadu> ^7heo: gst-plugins-base1 already in APKBUILD depends but let's see. import Gst results: http://tpaste.us/37Zw
2016-08-16 11:11:03 <^7heo> can you tell me the output of 'apk info --who-owns /usr/lib/python2.7/site-packages/mopidy/internal/gi.py'?
2016-08-16 11:11:16 <^7heo> oh wait, that's your package
2016-08-16 11:11:17 <^7heo> nevermind.
2016-08-16 11:11:28 <^7heo> I meant to ask for '/usr/lib/python2.7/site-packages/gi/__init__.py'
2016-08-16 11:11:36 <^7heo> can you tell me the output of 'apk info --who-owns /usr/lib/python2.7/site-packages/gi/__init__.py'?
2016-08-16 11:11:53 <^7heo> but that isn't relevant
2016-08-16 11:11:56 <^7heo> so please ignore ;)
2016-08-16 11:12:08 <^7heo> looks like a version problem to me.
2016-08-16 11:15:24 <^7heo> it is.
2016-08-16 11:15:28 <^7heo> https://gstreamer.freedesktop.org/src/gst-python/
2016-08-16 11:16:04 <^7heo> http://git.alpinelinux.org/cgit/aports/tree/main/py-gst0.10/APKBUILD
2016-08-16 11:16:08 <^7heo> pkgver=0.10.22
2016-08-16 11:16:21 <clandmeter> \o/
2016-08-16 11:16:26 <clandmeter> i just got confirmation from GIGABYTE, they will sponsor Alpine Linux with http://b2b.gigabyte.com/products/product-page.aspx?pid=5864#ov
2016-08-16 11:16:31 <^7heo> archive date: 2011-10-29 16:36
2016-08-16 11:16:45 <^7heo> we're using gstreamer from 2011.
2016-08-16 11:16:49 <^7heo> scadu: can't work that way.
2016-08-16 11:17:05 <^7heo> scadu: you have to update gst-python fisrt.
2016-08-16 11:17:09 <scadu> ^7heo: I built mopidy against py-gst1 (version 1.8.1)
2016-08-16 11:17:16 <^7heo> ah.
2016-08-16 11:17:29 <scadu> that's why I attached py-gst1 APKBUILD too.
2016-08-16 11:17:43 <^7heo> yeah
2016-08-16 11:18:01 <scadu> clandmeter: o/
2016-08-16 11:18:05 <^7heo> scadu: did you install the package py-gst1 before building the second APKBUILD?
2016-08-16 11:19:12 <przemoc> jirutka: IIRC ${var/word} and ${var//word} are not part of POSIX sh, so it's better to avoid them in portable scripts.  it looks that busybox's ash does implement it, but dash for instance does not.
2016-08-16 11:19:12 <^7heo> scadu: where did you find that py-gst1 APKBUILD btw?
2016-08-16 11:19:27 <scadu> ^7heo: otherwise I wouldn't build mopidy. however py-gst1 require py-gobject3-dev so maybe here is the issue.
2016-08-16 11:19:28 <^7heo> przemoc: what's that syntax supposed to do?
2016-08-16 11:19:49 <^7heo> scadu: ok, but where did you find it?
2016-08-16 11:19:58 <scadu> ^7heo: just bumped pkgver based on py-gst0.10
2016-08-16 11:20:06 <^7heo> scadu: ah. And it builds?
2016-08-16 11:22:05 <scadu> ^7heo: yes, but as I wrote above py-gobject3-dev is required in makedepends. otherwise you'll get checking for PYGOBJECT... configure: error: Package requirements (pygobject-3.0 >= 3.0) were not met:
2016-08-16 11:25:26 <^7heo> scadu: did you also bump gst-plugins-base0.10-dev and gstreamer0.10-dev?
2016-08-16 11:25:41 <^7heo> scadu: hmm
2016-08-16 11:27:12 <przemoc> ^7heo: sorry, thought shortcut.  I meant ${var/patt/repl} and ${var//patt/repl} - it's for replacing parts of variables (// is for all instances)
2016-08-16 11:28:34 <^7heo> oh, it's like a sed rule, in the variable expression.
2016-08-16 11:28:52 <^7heo> like, ${foo/foo/bar}
2016-08-16 11:29:08 <przemoc> well, not regexp pattern, but yeah
2016-08-16 11:29:15 <^7heo> ah ok
2016-08-16 11:29:18 <^7heo> just plain text.
2016-08-16 11:29:20 <^7heo> good to know.
2016-08-16 11:29:26 <^7heo> but yeah it doesn't sound posix to me.
2016-08-16 11:29:33 <przemoc> but it should be avoided in portable scripts
2016-08-16 11:30:48 <przemoc> and I look at APKBUILD files as portable scripts, IMHO they shouldn't expect sh on steroids
2016-08-16 11:31:36 <^7heo> przemoc: +1
2016-08-16 11:32:11 <^7heo> it's better than having package scripts expecting sh on steroids tho.
2016-08-16 11:35:24 <przemoc> line of defense could be:  "but busybox'sh supports it, so why bother?"  because people are free to replace busybox's sh and even alpine could switch to something else some day.
2016-08-16 11:36:16 <przemoc> actually 'local' keyword is also non-POSIX, but this one got wider adoption, so it's kind of ok-ish if we're tolerant enough
2016-08-16 11:36:55 <skarnet> if you use #!/bin/sh, you need to be POSIX, no discussion
2016-08-16 11:37:21 <skarnet> #!/bin/ash is a different beast, and obviously #!/bin/bash is too
2016-08-16 11:38:31 <skarnet> "we use /bin/sh but maybe this extension is ok because it's widely supported..." is a recipe for failure at an arbitrary point later in time
2016-08-16 11:39:03 <przemoc> well, I try to sound practical here, maybe alpine should start using ash explicitly in few places, otherwise scripts would need overhaul to get rid of local, and local is one thing that removed makes scripts actually worse in maintainability
2016-08-16 11:39:53 <skarnet> I agree that the absence of local variables in function is a major pain point of POSIX shells
2016-08-16 11:40:16 <skarnet> but if you want them, then yes, you need to depend on ash, or bash, or zsh, or anything that explicitly has them
2016-08-16 11:40:26 <skarnet> because "sh" is the least common denominator
2016-08-16 11:41:49 <przemoc> the problem with ash is that it's not provided by most shells IIRC (symlink/compat mode/whatever), OTOH having explicit busybox's sh dependency is not nice
2016-08-16 11:42:53 <skarnet> #!/bin/busybox sh
2016-08-16 11:43:46 <skarnet> I agree it's not satisfying :/ but it's still better than having #!/bin/sh and relying on something that a /bin/sh may not be able to provide
2016-08-16 11:44:20 <przemoc> linux treats everything after space in shebang as one argument, which is major PITA
2016-08-16 11:44:42 <przemoc> so you cannot do #!/bin/busybox sh -x for instance
2016-08-16 11:44:46 <skarnet> I know >.>
2016-08-16 11:45:14 <skarnet> the best answer is #!/bin/execlineb obviouslt
2016-08-16 11:45:20 <skarnet> obviously* :D
2016-08-16 11:46:07 <skarnet> (that's not even 100% a joke: I wrote execlineb because the kernel's shebang parser is so limited :P)
2016-08-16 11:46:46 <przemoc> Linux's kernel, it's not true for all of them
2016-08-16 11:47:51 <przemoc> I don't remember, but env possibly workarounded it too
2016-08-16 11:48:24 <skarnet> you still have to write #!/usr/bin/env yourbinary
2016-08-16 11:48:30 <skarnet> env isn't a solution to this
2016-08-16 11:49:17 <skarnet> anyway, for now what I'd do is: whenever a script needs extra functionality to /bin/sh, document it at the top of the script
2016-08-16 11:49:20 <skarnet> #!/bin/sh
2016-08-16 11:49:28 <skarnet> # (this script requires a shell that supports "local")
2016-08-16 11:49:52 <skarnet> so any breakage can be quickly diagnosed
2016-08-16 11:52:47 <przemoc> it assumes that people know what is and what isn't in POSIX sh, and it's usually not the case.  in alpine ecosystem it's possibly not that bad, but I've seen thousands of /bin/sh scripts out there that wouldn't work without bash, possibly even high numbered version of bash.  well, life...
2016-08-16 11:53:34 <skarnet> yeah, the scope was APKBUILD scripts here :D
2016-08-16 11:53:47 <skarnet> we can't fix the world more than one step at a time!
2016-08-16 12:04:12 <jirutka> przemoc: that’s right, but we use ash on Alpine and it does support this syntax
2016-08-16 12:09:02 <iscsi> morning
2016-08-16 12:10:20 <jirutka> przemoc: we can also use sed instead, it’d be still more readable and maintainable, but slower…
2016-08-16 12:11:04 <skarnet> won't be that much slower if it's busybox, tbh (no external binary invocation)
2016-08-16 12:11:31 <jirutka> przemoc: or if you insist, I can get back these crazy unreadable 5 lines workaround…
2016-08-16 12:12:14 <iscsi> how I can fetch apks with specific package version? apk fetch package=version doesn't work
2016-08-16 12:12:21 <jirutka> skarnet: that’s true, but I can argue in the same way as you before… WHAT IF Alpine switch to something else than Busybox? ;)
2016-08-16 12:12:53 <jirutka> skarnet: but yeah, not exactly comparable, b/c this will not cause failure, just slower invocation
2016-08-16 12:14:42 <skarnet> exactly
2016-08-16 12:15:13 <skarnet> if Alpine switches, scripts will be slower, but they will not break, which is the whole point :P
2016-08-16 12:16:22 <^7heo> skarnet: actually, nowhere in the POSIX spec is said that /bin/shneeds to exist, let alone be posix
2016-08-16 12:20:34 <jirutka> so should I replace `_pkgver="${pkgver//./_}"` it with `_pkgver="$(echo "$_pkgver" | sed "s/\./_/g")"`?
2016-08-16 12:20:49 <skarnet> ^7heo: you're right that POSIX doesn't mandate /bin, but the "sh" binary is fully specified.
2016-08-16 12:21:26 <^7heo> skarnet: yep. it is. it just does not say which one and where to find it.
2016-08-16 12:22:06 <skarnet> every Unix except Solaris agrees on /bin/sh, though, so I think it's reasonable to hardcode it.
2016-08-16 12:22:10 <^7heo> afaik it is POSIX that /bin/sh is tcsh
2016-08-16 12:22:41 <^7heo> as long as you have sh POSIX somewhere in the path
2016-08-16 12:22:43 <skarnet> no. If you're called "sh" and are reached by PATH resolution, you need to follow the specification for "sh".
2016-08-16 12:23:05 <^7heo> s/somewhere/& with higher priority/
2016-08-16 12:23:44 <skarnet> it's conforming, yes. It's also incredibly stupid. :P
2016-08-16 12:23:50 <^7heo> yes
2016-08-16 12:24:04 <^7heo> imho we should introduce /posix
2016-08-16 12:24:12 <jirutka> what?
2016-08-16 12:24:22 <^7heo> and start calling #!/posix/sh
2016-08-16 12:24:27 <jirutka> omg no
2016-08-16 12:24:37 <^7heo> so it will break evrywhere
2016-08-16 12:24:46 <^7heo> but not for us.
2016-08-16 12:24:49 <^7heo> :D
2016-08-16 12:25:18 <skarnet> "you are assuming /bin/sh is a POSIX shell. You are non-conforming and bad, and you should feel bad."
2016-08-16 12:25:40 <skarnet> which exactly happened to me on Solaris, lol.
2016-08-16 12:25:41 <^7heo> huhu
2016-08-16 12:25:42 <jirutka> ^7heo: https://i.kinja-img.com/gawker-media/image/upload/q6hcfdoyf4tr02xlke84.jpg
2016-08-16 12:26:03 <^7heo> skarnet: anyway, the loader doesn't parse PATH
2016-08-16 12:26:18 <^7heo> so we cant #!sh
2016-08-16 12:26:22 <^7heo> so
2016-08-16 12:26:32 <^7heo> /bin/sh HAS to be posix
2016-08-16 12:26:42 <^7heo> there's just no other way
2016-08-16 12:26:50 <skarnet> which loader?
2016-08-16 12:28:01 <^7heo> I'm not sure if the term loader is correct. Isn't it the Linux loader that reads the first line of a file marked executable on execve; and calls the related binary?
2016-08-16 12:29:33 <skarnet> maybe. You mean the shebang interpreter then. And arguably #!/bin/sh is wrong, you need #!/posix/sh on your jerkass system. :D
2016-08-16 12:29:41 <^7heo> (in case there is a shebang)
2016-08-16 12:30:20 <przemoc> jirutka: sorry, was afk.  I would simply replace ${var//./_} with $(echo "$var" | sed 's,\.,_,g')
2016-08-16 12:32:11 <przemoc> not sure whether it is accepted style within APKBUILD, though.
2016-08-16 12:32:32 <jirutka> clandmeter: what do you think about ^ ?
2016-08-16 12:33:11 <skarnet> ^ is a nice character, usually pronounced "caret"
2016-08-16 12:34:04 <jirutka> skarnet: LOL
2016-08-16 12:35:11 <mitchty> https://github.com/torvalds/linux/blob/master/fs/binfmt_script.c thats what parses the shebang
2016-08-16 12:35:19 <przemoc> or we can stick to ${//}, but abuild should start using ash in shebang for consistency (and depend on busybox explicitly)
2016-08-16 12:35:57 <skarnet> ugh the number of branches and copies
2016-08-16 12:36:09 <jirutka> przemoc: AFAIK abuild already declares dependency on busybox, but /usr/bin/abuild has /bin/sh in shebang
2016-08-16 12:37:21 <skarnet> execlineb is probably faster than load_script() :P
2016-08-16 12:37:57 <^7heo> can't we define a function in abuild for that otherwise?
2016-08-16 12:38:01 <^7heo> like
2016-08-16 12:38:38 <^7heo> nah actually bad idea.
2016-08-16 12:39:30 <^7heo> Shell isn't too good with variable indirection.
2016-08-16 12:40:15 <przemoc> no, it's not that bad idea, I mean basic stuff like string replacement, which isn't provided by mere POSIX sh, could be abstracted to ease life of packagers and to avoid different style of solving same issues
2016-08-16 12:40:35 <jirutka> przemoc: ^ agree
2016-08-16 12:40:54 <jirutka> przemoc: however, in this case, I would prefer to stick on ash and use variable replacement
2016-08-16 12:42:38 <jirutka> anyway, there are more important things I’d like to improve on abuild and don’t like to block PR212 on this discussion… I’m quite fine with all approaches, the are more important fixes and improvements in this PR than just this variable
2016-08-16 12:43:14 <przemoc> I understand that well, ${var/pat/rep} notation is quite convenient after all (it's not universally known, though, like our discussion already shown)
2016-08-16 12:43:32 <przemoc> sorry for delaying, I just noticed it and wanted to provide some input to make you aware of the stuff for future
2016-08-16 12:43:39 <jirutka> btw I added a comment about it https://github.com/alpinelinux/aports/pull/212#discussion_r74925690
2016-08-16 12:44:06 <^7heo> I agree with skarnet that /bin/sh has to be POSIX tho,.
2016-08-16 12:44:13 <^7heo> let's not be the ones who break what we fight for.
2016-08-16 12:44:19 <jirutka> przemoc: no problem, I appreciate your input
2016-08-16 12:44:47 <jirutka> ^7heo: APKBUILDs don’t have shebang ;)
2016-08-16 12:44:57 <^7heo> jirutka: true.
2016-08-16 12:45:09 <^7heo> then I'm fine with ash.
2016-08-16 12:45:22 <^7heo> but this should be documented somewhere
2016-08-16 12:45:36 <przemoc> they have implicit shebang, inherited from abuild, and the quickest solution is to make it switch to ash
2016-08-16 12:45:42 <jirutka> yeah
2016-08-16 12:46:25 <^7heo> +1
2016-08-16 12:46:37 <^7heo> that's indeed the best move IMHO too.
2016-08-16 12:46:38 <przemoc> the only question is whether there can be AL in the wild not having busybox installed at all?
2016-08-16 12:46:44 <^7heo> explicit is better than implicit.
2016-08-16 12:46:57 <jirutka> that’s why this discussion is worthy, because we should agree how to deal with such things
2016-08-16 12:47:05 <^7heo> so if we have to ditch POSIX because of ${var/syn/tax} let's make it explicit.
2016-08-16 12:47:23 <^7heo> Even tho I'm not a fan of ${var/syn/tax}
2016-08-16 12:47:28 <jirutka> actually we already use more non-POSIX syntax than just this… for example local
2016-08-16 12:47:42 <^7heo> yeah but for local, we could totally use subshells.
2016-08-16 12:47:45 <^7heo> they're "local" too.
2016-08-16 12:47:58 <jirutka> ^7heo: definitely not
2016-08-16 12:48:01 <^7heo> jirutka: ?
2016-08-16 12:48:14 <^7heo> jirutka: they are.
2016-08-16 12:48:21 <jirutka> subshells are slower and in this case it’s just a mere workaround
2016-08-16 12:49:20 <^7heo> well, it's a POSIX workaround.
2016-08-16 12:49:22 <^7heo> ;)
2016-08-16 12:49:38 <jirutka> let’s be honest, POSIX sh is very outdated, it’s not worth to be 100% compatible with it for the price of worse maintainability and robustness…
2016-08-16 12:49:51 <^7heo> I actually think that we could benefit from a POSIX 2.0 spec
2016-08-16 12:50:02 <^7heo> should it be adopted industry-wide.
2016-08-16 12:50:03 <jirutka> we should find some golden mean between purity and practicality
2016-08-16 12:50:17 <^7heo> jirutka: there's nothing golden between black and white.
2016-08-16 12:50:19 <^7heo> jirutka: just gray.
2016-08-16 12:50:31 <^7heo> jirutka: dirty, every-day, practical gray.
2016-08-16 12:50:33 <skarnet> you just lack imagination
2016-08-16 12:50:43 <^7heo> skarnet: that's what she said.
2016-08-16 12:50:50 <^7heo> 
ACTION hides

2016-08-16 12:51:16 <jirutka> for example, it’s bad to rely on syntax supported just be bash, but it’s imho okay okay to relay on syntax supported by most of the commonly used shells, including minimalistic ones (like Busybox ash)
2016-08-16 12:51:35 <skarnet> "there's nothing golden between black and white" -> and that's not what she said, maybe? :P
2016-08-16 12:51:57 <^7heo> skarnet: technically it's in that order: golden, white, black.
2016-08-16 12:53:02 <skarnet> bacteria-free allergy-free silicone golden?
2016-08-16 12:53:26 <^7heo> v_v
2016-08-16 12:53:41 <^7heo> if it's golden, chances are that it's metal anyway.
2016-08-16 12:53:47 <skarnet> you just lack imagination
2016-08-16 12:53:57 <^7heo> skarnet: that's what she said.
2016-08-16 12:53:58 <przemoc> guys, it's going off-topic
2016-08-16 12:54:02 <^7heo> you're right
2016-08-16 12:54:10 <przemoc> ;)
2016-08-16 12:54:11 <jirutka> right
2016-08-16 13:19:24 <Klowner> pr #202 finally builds, woo
2016-08-16 13:19:47 <Klowner> oh, algitbot, not that one
2016-08-16 13:20:24 <przemoc> it is unaware of GH
2016-08-16 13:20:33 <przemoc> we need algithubot
2016-08-16 13:22:20 <skarnet> or patch algitbot so it recognized GH PR numbers if they're prefixed differently
2016-08-16 13:22:23 <skarnet> like %202
2016-08-16 13:22:35 <skarnet> ... okay, not % then
2016-08-16 13:22:49 <skarnet> &202
2016-08-16 13:23:08 <przemoc> GH prefix would be safer
2016-08-16 13:23:23 <przemoc> or PR even
2016-08-16 13:25:17 <^7heo> Klowner: yeah we need to patch algitbot so it stops checking for bugs when we mean PRs
2016-08-16 13:25:40 <^7heo> on the other hand, it would help if algitbot would understand PR#202 or PR202.
2016-08-16 13:25:47 <^7heo> yeah, no.
2016-08-16 13:25:53 <skarnet> pr202 sounds good
2016-08-16 13:25:58 <^7heo> yeah
2016-08-16 13:26:06 <skarnet> so it can be triggered everytime przemoc writes something
2016-08-16 13:26:33 <^7heo> huhu
2016-08-16 13:26:44 <przemoc> I meant PR[0-9]+
2016-08-16 13:27:00 <^7heo> przemoc: until GH allow for a PR to have the id 'zemoc'
2016-08-16 14:20:23 <Klowner> anyone have an opinion on variant packages? like a headless version of an app, is it preferred to jam multiple builds into the same APKBUILD? I suppose since the library dependencies differ it needs to be separate?
2016-08-16 14:29:37 <przemoc> the only problem I see is that build solutions usually build one variant at the time, so you have to perform separate configure+builds into different directories, but one installation directory still should be fine (unless there are variants of library, yuck).  abuild lacks of some automated support for multiple builddirs, so you have to do the work yourself.  in future some partial support could be
2016-08-16 14:29:43 <przemoc> built it I think.
2016-08-16 14:29:47 <przemoc> s/built it/built in/
2016-08-16 17:57:50 <Klowner> przemoc: know of any packages that do that sort of thing?
2016-08-16 18:01:15 <przemoc> no (but it doesn't mean there isn't such for sure)
2016-08-16 18:01:34 <nmeum> main/mtr builds two different variants of the same package
2016-08-16 18:03:34 <jirutka> Klowner: https://github.com/alpinelinux/aports/blob/master/testing/keepalived/APKBUILD
2016-08-16 18:05:58 <przemoc> mtr is not modernized, so it's not the best starting point I would say
2016-08-16 18:06:53 <przemoc> but it shows a way, yeah
2016-08-16 18:11:19 <jirutka> przemoc: then look at keepalived
2016-08-16 18:13:10 <przemoc> ok, now I see it
2016-08-16 18:15:32 <przemoc> personally I wouldn't go outside of builddir, but into subdirectories for each variant, which would seem cleaner
2016-08-16 18:18:16 <przemoc> but other than this nitpick it's a fine example
2016-08-16 19:30:00 <leo-unglaub> hey :)
2016-08-16 19:30:41 <leo-unglaub> jirutka: asume you could change one thing on apk .. what would that be?
2016-08-16 19:31:03 <jirutka> leo-unglaub: hi
2016-08-16 19:31:19 <jirutka> leo-unglaub: not easy question…
2016-08-16 19:31:28 <leo-unglaub> thats why i am asking the expert
2016-08-16 19:31:57 <jirutka> leo-unglaub: does abuild also count?
2016-08-16 19:32:44 <leo-unglaub> not for now
2016-08-16 19:32:57 <leo-unglaub> currently i am just asking about the userspace utility apk
2016-08-16 19:34:48 <jirutka> leo-unglaub: maybe an ability to find a package by a contained file (without horrible hacks like parsing HTML form pkgs.a.o…)
2016-08-16 19:35:40 <scadu> jirutka: +1
2016-08-16 19:36:09 <scadu> currently it is possible, but only if packages is installed :c
2016-08-16 19:36:15 <jirutka> I know
2016-08-16 19:36:37 <jirutka> btw someone is already working on this feature, IIRC fabled
2016-08-16 19:36:53 <scadu> \o/
2016-08-16 19:37:01 <jirutka> it’s related to a new index format
2016-08-16 19:37:22 <leo-unglaub> thats an interresting point
2016-08-16 19:38:42 <leo-unglaub> my biggest change would be removing the fetch functionallity ... it confuses a lot of people and should be in a seperate utility in my opinion
2016-08-16 19:38:50 <leo-unglaub> but very interresting to know your point of view there
2016-08-16 19:57:24 <nmeum> clandmeter: what kind of aarch64 device do you own?
2016-08-16 20:02:22 <skarnet> leo-unglaub: the ability to have several versions of the same package, with one default. Also, the ability to atomically upgrade.
2016-08-16 20:03:09 <leo-unglaub> skarnet: any ideas on how that would be possible?
2016-08-16 20:03:16 <leo-unglaub> i asume they share the same path?
2016-08-16 20:03:35 <leo-unglaub> AH
2016-08-16 20:03:36 <leo-unglaub> stop
2016-08-16 20:03:41 <leo-unglaub> i know what you mean
2016-08-16 20:03:46 <leo-unglaub> like flavours in OpenBSD?
2016-08-16 20:03:56 <skarnet> I don't know what flavours are.
2016-08-16 20:04:37 <skarnet> The ability to atomically upgrade isn't possible as long as we follow FHS, so that's pretty much out.
2016-08-16 20:04:40 <leo-unglaub> flavours are different versions of the same package. basically the same package with multiple configure uptions
2016-08-16 20:04:56 <skarnet> The ability to have several versions of the same package, however, is independent from file layout.
2016-08-16 20:05:46 <skarnet> well, flavours would be nice, but I'm not even thinking of multiple configure options (although that's certainly a possibility). I'm talking about successive versions.
2016-08-16 20:05:54 <leo-unglaub> skarnet: installing vim on OpenBSD looks liek that: http://paste.debian.net/plain/789941
2016-08-16 20:05:57 <leo-unglaub> do you mean that?
2016-08-16 20:06:46 <skarnet> No. I want the ability to install all of those simultaneously. And have a utility to choose which one is the default.
2016-08-16 20:06:54 <leo-unglaub> WTF??
2016-08-16 20:07:04 <leo-unglaub> that would create a huge mess
2016-08-16 20:07:21 <leo-unglaub> gnome does that in there new package manager
2016-08-16 20:07:28 <leo-unglaub> also the snappy package from ubundu do that
2016-08-16 20:07:37 <skarnet> Only in your head. And on the disk, if the layout isn't appropriately thought out.
2016-08-16 20:07:51 <leo-unglaub> they create a sandbox in a directory and allow installing multiple versions in there
2016-08-16 20:08:08 <ammunta> skarnet: isn't that the problem slashpackage is meant to solve!!!!
2016-08-16 20:08:33 <skarnet> ammunta: shhh. You can't play, you know too much.
2016-08-16 20:08:47 <ammunta> oh wait wrong context sorry
2016-08-16 20:09:35 <leo-unglaub> i cannot help me ... having multiple version of the same application sounds stupid to me
2016-08-16 20:09:43 <leo-unglaub> i am propobly getting trolled currently
2016-08-16 20:09:47 <leo-unglaub> so i am getting some food
2016-08-16 20:10:00 <skarnet> consider python 2 and python 3
2016-08-16 20:10:08 <ammunta> I mean have you ever tried "testing" a web page in ies 5-8
2016-08-16 20:10:11 <skarnet> now does it still sound trolly?
2016-08-16 20:10:24 <leo-unglaub> yes
2016-08-16 20:10:30 <leo-unglaub> python ...
2016-08-16 20:10:40 <leo-unglaub> basically every big framework moved to python3
2016-08-16 20:10:59 <skarnet> TIL X.org isn't a big framework
2016-08-16 20:11:42 <leo-unglaub> you can move from python2 to python3 with 2 or 3 changes that can even be detected by grep
2016-08-16 20:11:48 <leo-unglaub> so if someone does not ... who cares
2016-08-16 20:11:52 <skarnet> but of course
2016-08-16 20:12:04 <skarnet> tell that to ncopa
2016-08-16 20:13:42 <ammunta> besides, someone has to actually write the code so it'll work on all relevant versions
2016-08-16 20:15:23 <ammunta> ... to be fair, 90% of the reasons I can come up with for multiple versions are either testing or compat
2016-08-16 20:16:08 <skarnet> what about libraries and dependency hell
2016-08-16 20:17:57 <ammunta> it's probably wishful thinking to want that to only be 10% of the time, right
2016-08-16 20:25:11 <jirutka> leo-unglaub: skarnet is right, but it’s not just about apk, this would lead to total change of the distribution
2016-08-16 20:30:37 <jirutka> leo-unglaub: this idea is about self contained bundles; instead of messing with single global mutable filesystem tree (that’s what FHS is all about), you install each application with all of its dependencies into isolated directories… most of the hard problems with packaging magically disappears, the price is basically just higher disk space consumption
2016-08-16 20:32:13 <Klowner> that's what docker/containers are for
2016-08-16 20:32:30 <jirutka> exactly
2016-08-16 20:32:42 <jirutka> but docker is just a stupid workaround
2016-08-16 20:33:00 <jirutka> it doesn’t solve cause, just a symptom
2016-08-16 20:33:21 <Klowner> some sort of fancy de-dupe lxc system would be neat
2016-08-16 20:34:15 <jirutka> filesystem already provides dedupe capabilities
2016-08-16 20:37:21 <jirutka> I think that this is a great illustration: bundles, slash package or how we call it, is like a man’s brain https://youtu.be/3XjUFYxSxDk?t=20sconventional FHS is like a woman’s brain https://youtu.be/3XjUFYxSxDk?t=2m24s
2016-08-16 20:37:35 <jirutka> sry
2016-08-16 20:37:57 <jirutka> https://youtu.be/3XjUFYxSxDk?t=20s and https://youtu.be/3XjUFYxSxDk?t=2m24s
2016-08-16 20:44:49 <clandmeter> nmeum: we are currently using R120-P30
2016-08-17 06:07:43 <coredumb> Anyone using puppet on alpine would share me an apk or APKBUILD ?
2016-08-17 07:56:15 <clandmeter> ScrumpyJack: hi
2016-08-17 07:57:17 <clandmeter> did you recently discuss about cleaning up testing repo?
2016-08-17 08:18:09 <ScrumpyJack> yes
2016-08-17 08:34:02 <clandmeter> any volunteers to help fix testing repo?
2016-08-17 08:34:17 <clandmeter> well fix is a big word, rather call it cleanup.
2016-08-17 08:35:05 <coredumb> clandmeter: would you give more details about the cleanup ?
2016-08-17 08:35:16 <clandmeter> yes of course :)
2016-08-17 08:35:32 <clandmeter> failed source check: http://tpaste.us/GPze
2016-08-17 08:35:33 <coredumb> else I'm not volunterring :P
2016-08-17 08:36:03 <clandmeter> the idea is to fix things that are not older then X days
2016-08-17 08:36:19 <coredumb> clandmeter: I just sent yesterday a major cleanup of testing/pdns
2016-08-17 08:36:23 <clandmeter> everything not building and older the X, we move to unmaintained.
2016-08-17 08:36:37 <coredumb> sounds good to me
2016-08-17 08:37:21 <clandmeter> from my list, only 20% build
2016-08-17 08:37:30 <coredumb> I'd love having exim jumping in main/ :D
2016-08-17 08:38:06 <clandmeter> anything that has a maintainer can move to main/community if the maintainer is active of course.
2016-08-17 08:38:44 <clandmeter> we should probably not move anything to main.
2016-08-17 08:38:45 <coredumb> I think I'll claim maintenership for pdns stuff
2016-08-17 08:38:58 <coredumb> got interest in there recently
2016-08-17 08:39:09 <coredumb> maintainership*
2016-08-17 08:39:23 <clandmeter> anybody has a good TTL for testing?
2016-08-17 08:39:44 <clandmeter> something like 60 days?
2016-08-17 08:39:51 <coredumb> what's the deadline ? I can't do anything this week
2016-08-17 08:40:33 <clandmeter> im also rather busy, but i try to chip in every evening and sometimes at daytime
2016-08-17 08:41:02 <coredumb> I should find some time next week
2016-08-17 08:41:46 <clandmeter> im wondering if we shouldnt first do a mass cleanup of 180+ days of NON activiy aports
2016-08-17 08:41:59 <coredumb> agree
2016-08-17 08:42:22 <clandmeter> lets see if i can generate a list
2016-08-17 08:42:24 <coredumb> we could then cherry-pick from that list what should stay in testing or not
2016-08-17 08:42:30 <clandmeter> ill post some info here.
2016-08-17 08:42:41 <coredumb> like pdns as I said :P
2016-08-17 08:42:46 <coredumb> ok let me know
2016-08-17 08:42:47 <clandmeter> well, if stuff is still in testing after half year, there is something wrong with the contributor :)
2016-08-17 08:44:27 <coredumb> http://git.alpinelinux.org/cgit/aports/log/testing/cfengine/APKBUILD you mean something's wrong with me ? :P
2016-08-17 08:46:01 <skarnet> either that or things just work so you don't have to update them that often :P
2016-08-17 08:46:36 <coredumb> I should take care of a list I sent in testing and keep them up to date more thoroughly and whish to claim maintainer status
2016-08-17 08:47:58 <coredumb> I'd be happy to have borgbackup to go in main/community as well :)
2016-08-17 08:48:22 <scadu> well, if it comes to testing repo there is  one packages I maintain -- mopidy. after upgrade to 2.0.1 does not work anymore. didn't push changes yet but I'm in dead end now and have no idea how to fix it. I think we should move it to community once fixed.
2016-08-17 08:50:21 <coredumb> what's the decision process to move from testing to community ?
2016-08-17 08:50:48 <clandmeter> it needs a maintainer
2016-08-17 08:51:16 <clandmeter> and it needs to build of course
2016-08-17 08:51:48 <coredumb> fine by me
2016-08-17 08:53:41 <coredumb> oh anyone using puppet on alpine btw ?
2016-08-17 08:54:05 <scadu> clandmeter: and should run :p
2016-08-17 08:55:08 <clandmeter> scadu: yes a basic test should do.
2016-08-17 09:09:26 <clandmeter> ok im generating a list of pkgs that have no update since 1 jan 2016
2016-08-17 09:09:34 <clandmeter> ill send this list to the ml
2016-08-17 09:14:20 <jirutka> clandmeter: why is testing/pcre2 on the list? this abuild certainly works
2016-08-17 09:15:10 <clandmeter> jirutka: ill check it
2016-08-17 09:16:26 <clandmeter> testing/pcre2$ abuild sourcecheck
2016-08-17 09:16:26 <clandmeter> wget: ftp error: Transfer aborted. Broken pipe
2016-08-17 09:16:27 <clandmeter> >>> ERROR: pcre2: sourcecheck failed
2016-08-17 09:17:06 <jirutka> clandmeter: I’ve just built it on my machine without any problem
2016-08-17 09:17:26 <clandmeter> cause you have the source local?
2016-08-17 09:17:37 <jirutka> clandmeter: nope, I’ve wiped distfiles
2016-08-17 09:18:46 <clandmeter> jirutka: can you check abuild sourcecheck
2016-08-17 09:19:17 <clandmeter> seems to build just right.
2016-08-17 09:19:20 <jirutka> clandmeter: `abuild sourcecheck` hangs…
2016-08-17 09:19:25 <clandmeter> looks like sourcecheck is broken
2016-08-17 09:19:31 <jirutka> yeah…
2016-08-17 09:19:44 <clandmeter> sigh
2016-08-17 09:20:05 <clandmeter> ill have to rerun it with abuild checksum
2016-08-17 09:21:03 <clandmeter> or write my own
2016-08-17 09:21:41 <jirutka> clandmeter: I think we should write some guidelines about testing repo… most of my abuilds are in the testing, because I move them up only when I’m really sure that it works without any problem and that I’ll be able to maintain it for at least half a year
2016-08-17 09:23:22 <clandmeter> we had a discussion about it a few months ago
2016-08-17 09:23:26 <jirutka> clandmeter: for example Julia works, but upstream is still not satisfied how we build it (that we use system-provided llvm without their patches), so it stays in testing for now, until I resolve it somehow
2016-08-17 09:23:27 <clandmeter> and yes we need a guideline
2016-08-17 09:23:51 <clandmeter> thats why i opted for documentation
2016-08-17 09:24:01 <jirutka> clandmeter: R also works, but there are some issues with some R packages and since R is quite a mess, I’m really not sure about it
2016-08-17 09:24:05 <jirutka> clandmeter: yeah
2016-08-17 09:24:17 <clandmeter> jirutka: things can stay in testing.
2016-08-17 09:24:26 <clandmeter> but we need to define what stays and what goes
2016-08-17 09:24:31 <clandmeter> its a mess now
2016-08-17 09:24:35 <jirutka> yeah
2016-08-17 09:24:50 <jirutka> I’ll review my packages in testing today
2016-08-17 09:24:52 <clandmeter> so if its not updated for X days, then it should move to unmaintined
2016-08-17 09:25:12 <jirutka> what if there’s just no new version…?
2016-08-17 09:25:22 <clandmeter> its too much trouble for me and ncopa when we do a new branch/arch/whatever.
2016-08-17 09:25:38 <jirutka> it should be imo: “if there are outdated for X days, then…”
2016-08-17 09:26:10 <jirutka> s/there are it’s/
2016-08-17 09:26:17 <jirutka> s/there are/it’s/
2016-08-17 09:35:07 <clandmeter> jirutka: i think if a package has not been updated since X days, and it didnt have new release since, it should still be moved to unmaintained.
2016-08-17 09:37:10 <clandmeter> if that X days is almost 9 months, this package has a serious issue.
2016-08-17 09:37:18 <clandmeter> testing != aur
2016-08-17 09:50:12 <przemoc> 60 days for testing seems a bit low.  while there is a merit in such tight requirement, there are also problems like jirutka mentioned.  and issues with testing comes from the fact it's hybrid of different kind of packages that could be classified as:  abandoned / forgotten, barely working / untested, apparently working but not fully tested, fully working but without mainainership.
2016-08-17 09:51:02 <przemoc> maybe packages with maintainer that cannot be merged to main or community for some technical reasons should receive their own category like staging?
2016-08-17 09:56:12 <clandmeter> przemoc: 60 says is too short probably.
2016-08-17 09:57:29 <clandmeter> i just tested since 1 jan 2016, it would purge 717 pkgs
2016-08-17 09:57:44 <przemoc> there are that many?  wow
2016-08-17 09:58:04 <clandmeter> yes, thats a reason to clean it up.
2016-08-17 09:58:35 <clandmeter> currently we have 1832pkgs in testing.
2016-08-17 09:58:48 <clandmeter> well thats just apkbuilds
2016-08-17 10:05:06 <ScrumpyJack> 755 are perl and python modules
2016-08-17 10:10:02 <przemoc> maybe it would be better to half-tie it to AL releases, which happen somewhat half-yearly, usually near the turn of Q4/Q1 and Q2/Q3.  testing could be simply cleaned (moving non-marked [be it maintainer field or something else] packages to unmaintained) at the end of each quarter.  it's easier to describe, explain to people and script if needed.
2016-08-17 10:10:18 <clandmeter> http://tpaste.us/36aa no update since 1 jan 2016
2016-08-17 10:14:16 <przemoc> packagement needs involvement and it needs to be at least a bit forced on contributors/requesters, so they don't vanish when package hits testing.
2016-08-17 10:15:35 <przemoc> http://lists.alpinelinux.org/alpine-devel/201608byindex.html  404?
2016-08-17 10:15:50 <przemoc> it's ok now
2016-08-17 10:17:29 <coredumb> clandmeter: you can drop testing/cantata completely
2016-08-17 10:19:21 <coredumb> I'll check the rest of mine...
2016-08-17 10:20:26 <clandmeter> im still in doubht of the TTL
2016-08-17 10:20:42 <clandmeter> year/half year/...
2016-08-17 10:21:07 <przemoc> fixed point in time than TTL is much easier to manage
2016-08-17 10:21:15 <clandmeter> now we have almost 9 monts in the list
2016-08-17 10:21:25 <clandmeter> 6 will make it bigger.
2016-08-17 10:21:54 <clandmeter> ill just the mail to the ml and see what others have to say.
2016-08-17 11:25:43 <fcolista> clandmeter, re "calanup of testing repository"
2016-08-17 11:25:48 <fcolista> *cleanup
2016-08-17 11:26:03 <fcolista> "As an example you can find a list of not updated packages since 1 jan 2016 here: http://tpaste.us/36aa"
2016-08-17 11:26:15 <fcolista> what do you mean with "not updated"?
2016-08-17 11:26:33 <fcolista> There are packages where the upstream does not release any upgrade
2016-08-17 11:26:41 <clandmeter> they are stale
2016-08-17 11:26:43 <fcolista> how would you discern that?
2016-08-17 11:27:03 <clandmeter> diswhat?
2016-08-17 11:27:28 <fcolista> how would you figured?
2016-08-17 11:27:50 <clandmeter> im not sure i understnad your question.
2016-08-17 11:29:08 <fcolista> how can you understand that a package is not "updated" beacuse the maintainer is not taking care of that, from one that is doing, but the upstream does not relase an upgrade since months/years?
2016-08-17 11:29:27 <clandmeter> ok
2016-08-17 11:30:08 <clandmeter> we do not know the difference
2016-08-17 11:30:43 <clandmeter> all we know is, if a package is stale for longer then X days, we can concider it unmaintained.
2016-08-17 11:31:05 <^7heo> clandmeter: what do you call "stale"?
2016-08-17 11:31:07 <fcolista> i don't think that this is right.
2016-08-17 11:31:21 <^7heo> fcolista: depends on the definition of stale.
2016-08-17 11:31:29 <jirutka> clandmeter: it’s quite hard to fix packages on list http://tpaste.us/GVV8 when there are no build logs…
2016-08-17 11:31:40 <^7heo> fcolista: but I agree, it might cause quite some stress.
2016-08-17 11:31:59 <fcolista> moreover, there are packages depending from "old" packages
2016-08-17 11:32:14 <clandmeter> jirutka: i have the logs
2016-08-17 11:32:16 <^7heo> fcolista: true.
2016-08-17 11:32:26 <jirutka> clandmeter: the logs in #alpine-commits returns 404…
2016-08-17 11:32:32 <fcolista> so that might cause trouble
2016-08-17 11:32:39 <clandmeter> jirutka: I can provide them.
2016-08-17 11:32:42 <clandmeter> its no issue
2016-08-17 11:32:45 <fcolista> a possible solution would be moving that ones in community
2016-08-17 11:32:50 <clandmeter> but fixing them is not the idea of that email.
2016-08-17 11:33:04 <clandmeter> the problem is the list is too large.
2016-08-17 11:33:14 <clandmeter> it takes too much time to fix them all.
2016-08-17 11:33:17 <^7heo> yeah
2016-08-17 11:33:22 <^7heo> that's a recursive problem
2016-08-17 11:33:26 <^7heo> takes too muchj time to fix
2016-08-17 11:33:27 <clandmeter> so we need to cut that list.
2016-08-17 11:33:29 <^7heo> not fixing
2016-08-17 11:33:32 <clandmeter> then start fixing.
2016-08-17 11:33:34 <^7heo> so the list grows
2016-08-17 11:33:37 <^7heo> yeah
2016-08-17 11:34:10 <clandmeter> if you start fixing things in testing, why not move it to community?
2016-08-17 11:34:28 <jirutka> I will take care of my packages, but I can’t fix them for aarch64, because there are not build on build infra regulary as other packages… I’ve updated several packages with arch=all few days ago and they didn’t hit aarch64 build
2016-08-17 11:34:56 <fcolista> because some of them are not actually tested, but simply built.
2016-08-17 11:35:01 <clandmeter> jirutka: i will provide you the logs, dont worry
2016-08-17 11:35:14 <clandmeter> i know a few of them are probably because of config.guess.
2016-08-17 11:35:20 <fcolista> But I agree that should be tested and eventually moved to community
2016-08-17 11:35:51 <jirutka> clandmeter: wait a moment, the packages on http://tpaste.us/GVV8 fails to build on aarch64? for example R has arch="x86 x86_64"
2016-08-17 11:36:19 <^7heo> jirutka: are you saying that we try to build stuff on aarch64 that shouldn't be tried there?
2016-08-17 11:36:46 <clandmeter> jirutka: the fail list is just a ls -d testing/*/src
2016-08-17 11:36:50 <jirutka> ^7heo: I dunno… but I’m sure that some of the packages on the list don’t have aarch64 in arch=
2016-08-17 11:37:12 <jirutka> clandmeter: what’s that? R builds fine, I’ve built it successfully just few minutes ago
2016-08-17 11:37:14 <^7heo> yep
2016-08-17 11:38:50 <clandmeter> that could be of abuild checksum test.
2016-08-17 11:39:09 <jirutka> clandmeter: no, this package is totally correct
2016-08-17 11:40:02 <clandmeter> damn its becuase of abuild checksum
2016-08-17 11:40:23 <clandmeter> it will also create the src dir
2016-08-17 11:41:32 <jirutka> I’ve double checked it, the checksum is correct
2016-08-17 11:41:44 <clandmeter> you dont understand what im trying to say
2016-08-17 11:41:54 <clandmeter> if you run buldrepo, all failed pkgs will have a src dir.
2016-08-17 11:42:06 <clandmeter> its an easy way to get a list of which pkg fail to buld.
2016-08-17 11:42:25 <clandmeter> but afterwards i tried abuild sourcecheck
2016-08-17 11:42:30 <clandmeter> which is ok
2016-08-17 11:42:38 <clandmeter> but it failed as we know.
2016-08-17 11:42:50 <jirutka> aha
2016-08-17 11:42:54 <clandmeter> so another way to verify it is to run abuild checksum on each dir.
2016-08-17 11:43:18 <clandmeter> i think i cancled it after a few hits.
2016-08-17 11:44:03 <jirutka> another example, cargo has arch="x86_64" and still, it’s on your list
2016-08-17 11:45:05 <clandmeter> forget that list.
2016-08-17 11:45:16 <clandmeter> the start of the list is probably not correct.
2016-08-17 11:45:26 <clandmeter> ill see if i can get a new one.
2016-08-17 11:45:41 <jirutka> okay, this calms me down :)
2016-08-17 11:46:22 <jirutka> ad email… the problem is that we don’t know if a package is outdated… I was thinking about integrating with https://release-monitoring.org/, then we can simply query outdated packages
2016-08-17 11:46:24 <clandmeter> but
2016-08-17 11:46:33 <jirutka> it’s on my TODO list… that is already quite long :/
2016-08-17 11:46:49 <clandmeter> buildrepo still showed me there are approx failed pkgs.
2016-08-17 11:47:12 <clandmeter> 462
2016-08-17 11:48:20 <clandmeter> jirutka: http://tpaste.us/GmOx   config.guess issues (most probably)
2016-08-17 11:48:23 <jirutka> btw can we build openjdk8 for armhf and aarch64?
2016-08-17 11:48:48 <clandmeter> currently there are 2 issues
2016-08-17 11:49:05 <clandmeter> if you rebuild testing on x86_64, you will alos have lots of failed pkgs.
2016-08-17 11:49:10 <clandmeter> thats all due to gcc6
2016-08-17 11:49:43 <clandmeter> most notable is: The default mode for C++ is now -std=gnu++14 instead of -std=gnu++98.
2016-08-17 11:50:49 <clandmeter> ive tried to build openjdk7 but it failed. same as firefox.
2016-08-17 11:51:08 <clandmeter> i wonder if they build on x86*
2016-08-17 11:51:44 <clandmeter> i think ive also bumped into an issue with libreoffice.
2016-08-17 11:52:09 <clandmeter> i think some dep of a dep of libreoffice got updated which is not compatible.
2016-08-17 11:53:35 <clandmeter> but i would prefer to first cleanup testing, and then we can continiu cleaning up the rest (should save us half of the work)
2016-08-17 12:04:08 <vkris> there are issues associated with upstream source not being available
2016-08-17 12:04:08 <vkris> 1. claiming souce code maintainership, this mean either upload write permission to distfiles or the maintainer keeps a copy and provides via some public url, OR push it to github and then have a AL Git copy of source with AL branch for local changes.
2016-08-17 12:04:12 <vkris> 2. claiming maintainership for APKBUILD itself
2016-08-17 12:04:12 <vkris> (both can be done separately)
2016-08-17 12:04:17 <vkris> And important to note, a pkg not being updated could be 1.stale 2.feature-complete 3.stable 4.hard-depends-for-another-pkg
2016-08-17 12:06:02 <vkris> I ran `apk fetch && verify` for v3.4.1 and somehow managed to get 99% for the src pkgs for repo
2016-08-17 12:06:21 <vkris> it could be more grimm now
2016-08-17 12:07:50 <vkris> so we have resouce to GIT maintain upstream sources with AL related changes in al branch ?
2016-08-17 12:09:07 <vkris> I could scale to 2TB in few AL cycle
2016-08-17 12:10:41 <vkris> start /testing by just doing `apk fetch` and getting the error logs
2016-08-17 12:15:58 <vkris> it could scale*
2016-08-17 12:19:53 <fcolista> i'd really like to have http://bugs.alpinelinux.org/issues/5011 done
2016-08-17 12:20:10 <fcolista> i would spent some time on it
2016-08-17 12:20:15 <fcolista> but i need an help from where to start
2016-08-17 12:25:53 <vkris> sorry, `abuild fetch` and `abuild verify` ^^
2016-08-17 12:30:50 <nmeum> fcolista: did you see my comment regarding py-paramiko?
2016-08-17 12:31:01 <fcolista> nmeum, where?
2016-08-17 12:31:46 <nmeum> fcolista: few days ago in this channel
2016-08-17 12:31:48 <nmeum> > 16:25 < nmeum> fcolista: http://git.alpinelinux.org/cgit/aports/commit/main/py-paramiko/APKBUILD?id=4c22e83130794c8db8c0c05c4d980294e7a35a1a py-cryptography is in community and not in main packages in main should not depend on packages in community (at least if I recall correctly). Would you mind moving py-cryptography and all its dependencies that are not in main/ to main/?
2016-08-17 12:31:53 <fcolista> nope
2016-08-17 12:32:06 <fcolista> umh
2016-08-17 12:32:10 <fcolista> good catch
2016-08-17 12:32:31 <fcolista> k, thx
2016-08-17 12:32:41 <nmeum> thanks for taking care of it :)
2016-08-17 12:33:01 <fcolista> that was a dependency i needed for other packags
2016-08-17 12:33:03 <fcolista> *packages
2016-08-17 12:33:10 <fcolista> ok
2016-08-17 12:33:13 <fcolista> let me do that
2016-08-17 12:33:22 <nmeum> I don't have much experience with python packages
2016-08-17 12:33:25 <nmeum> otherwise I would have done it myself
2016-08-17 12:33:34 <nmeum> but I am not the maintainer of those packages therefore I decided not to
2016-08-17 12:33:51 <vkris> or testing/pcre2 suggestion first build all pcre dependant pkgs in testing/ with pcre2 and see how it works out
2016-08-17 12:33:58 <vkris> but I may be mistaken
2016-08-17 12:34:28 <vkris> it could save some work on builders and breakage
2016-08-17 12:39:35 <vkris> http://tpaste.us/ARVb testing/pcre2 depends
2016-08-17 12:40:05 <vkris> oh! julia is already done
2016-08-17 12:54:36 <jirutka> what is current maximum number of cores available on aarch64 systems?
2016-08-17 12:57:01 <clandmeter> i have no idea
2016-08-17 12:57:19 <clandmeter> as in a limit on linux kernel?
2016-08-17 13:23:08 <vkris> ok db is fairly updated now, so one can can do,
2016-08-17 13:23:09 <vkris> curl 'http://api.alpinelinux.org/index.php?_url=/packages/name/pcre/provides&branch=edge&arch=x86&repo=testing' | jq -C .data[].attributes.name | sort
2016-08-17 13:23:43 <vkris> or
2016-08-17 13:23:45 <vkris> curl 'http://api.alpinelinux.org/packages/name/pcre/provides&branch=edge&arch=x86&repo=testing' | jq -C .data[].attributes.name | sort
2016-08-17 13:24:02 <mitchty> jq -rS
2016-08-17 13:24:06 <mitchty> save the sort
2016-08-17 13:24:13 <vkris> ok, thanks!
2016-08-17 13:25:06 <vkris> nope
2016-08-17 13:35:04 <Klowner> anyone happen to know how to programatically get "python3.5m" in an APKBUILD? "3.5" is easy enough but I'm not sure where that "m" comes from
2016-08-17 13:43:08 <mitchty> jirutka: ok so some other hacks to the ghc-bootstrap package got things working until travis timed out at least https://travis-ci.org/mitchty/aports/builds/152686989
2016-08-17 13:59:40 <clandmeter> jirutka, fcolista, anyone else: these pkgs need update_config_guess http://tpaste.us/GXaj (they have had an git update this year)
2016-08-17 14:07:22 <fcolista> clandmeter, sure that with update_config_guess the package build?
2016-08-17 14:11:25 <clandmeter> it will fix the current issue :)
2016-08-17 14:11:40 <clandmeter> but you are right, ill try them local tonight
2016-08-17 14:11:59 <fcolista> i've done a couple so far
2016-08-17 14:12:04 <fcolista> dhcping and yersinia
2016-08-17 14:12:37 <clandmeter> lets see
2016-08-17 14:12:56 <fcolista> they built
2016-08-17 14:14:18 <clandmeter> fcolista: build correctly on aarch64 :)
2016-08-17 14:14:18 <clandmeter> thx
2016-08-17 14:14:35 <clandmeter> i think its safe to update them
2016-08-17 14:14:49 <clandmeter> if there is another build error, i can update it later.
2016-08-17 14:14:53 <fcolista> abook doesn't build
2016-08-17 14:15:17 <clandmeter> gcc6?
2016-08-17 19:00:03 <nmeum> ncopa: did you verify that http://git.alpinelinux.org/cgit/aports/tree/community/go/APKBUILD#n84 was fixed in go 1.7?
2016-08-17 19:00:06 <nmeum> argh
2016-08-17 20:00:24 <coredumb> clandmeter: dunno why borgbackup is in your "do not build" list but it certainly does and works flawlessly
2016-08-17 20:00:48 <clandmeter> i know
2016-08-17 20:01:23 <coredumb> did I misundertand your email ?
2016-08-17 20:02:13 <coredumb> or is your list the ones that build ?
2016-08-17 20:02:34 <clandmeter> no i made a mistake
2016-08-17 20:02:41 <coredumb> ah
2016-08-17 20:02:44 <clandmeter> but
2016-08-17 20:02:50 <clandmeter> i mean
2016-08-17 20:02:53 <coredumb> I thought I was too drunk to check my emails
2016-08-17 20:02:55 <coredumb> \o/
2016-08-17 20:02:57 <clandmeter> from enlightenment/src it should be correct
2016-08-17 20:03:11 <coredumb> ok
2016-08-17 20:04:53 <clandmeter> coredumb: and my list is from an aarch64 box
2016-08-17 20:05:05 <clandmeter> could be some things because of diff arch
2016-08-17 20:08:08 <coredumb> guess so
2016-08-17 20:08:15 <coredumb> I don't have one to verify
2016-08-17 21:18:22 <leo-unglaub> hey :)
2016-08-17 21:18:27 <jirutka> maintainer hi
2016-08-17 21:18:30 <jirutka> sry
2016-08-17 21:18:31 <jirutka> hi
2016-08-17 21:19:19 <leo-unglaub> have you all seen https://lists.gnupg.org/pipermail/gnupg-announce/2016q3/000395.html ?
2016-08-17 21:21:03 <leo-unglaub>  "An attacker who obtains 4640 bits from the RNG can trivially predict the next 160 bits of output"
2016-08-17 21:21:12 <leo-unglaub> so basically ... its complete fucked ...
2016-08-17 21:21:28 <leo-unglaub> also very nice: "This bug exists since 1998 in all GnuPG and Libgcrypt versions" ...
2016-08-17 21:21:40 <ncopa> what!?
2016-08-17 21:22:16 <leo-unglaub> yeah, its horrible ...
2016-08-17 21:22:51 <leo-unglaub> a lot of xfce componentd depend on that garbage as well ... the funny thing is .. its complete avoidable by simply doing an fopen on /dev/urandom ..
2016-08-17 21:23:04 <leo-unglaub> i never understood why they created this wrapper layer
2016-08-17 21:24:52 <jirutka> leo-unglaub: what exactly was wrong in the source?
2016-08-17 21:26:17 <leo-unglaub> its better if you read the diff yourself ..
2016-08-17 21:26:31 <leo-unglaub> but in general ... the entire library has no reason to exist in the first place
2016-08-17 21:27:07 <jirutka> maybe I’m blind, but I don’t see any diff
2016-08-17 21:28:06 <leo-unglaub> http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=shortlog;h=refs/heads/master
2016-08-17 21:35:19 <leo-unglaub> a good friend of mine who is a security researcher and who told me about this release already before the anouncement told me a little bit about his research ... he estimates that a normal linux desktop (Deskop environment, browser, mail client, media player, chat program, ...) contains around 150 - 200 high security bugs at least
2016-08-17 21:35:50 <leo-unglaub> from those aroung 50 are covered by kernel medigations ...
2016-08-17 21:36:12 <leo-unglaub> but that means that bugs like thos one in libgcrypt are aroung 100 times on my current setup
2016-08-17 21:36:20 <leo-unglaub> i dont know about you, but that freaks me out a bit
2016-08-17 21:40:31 <skarnet> Does I mean I can start dancing on the smoking corpses of GnuPG and libgcrypt now, while pointing at their users and laughing?
2016-08-17 21:40:37 <skarnet> Does it*
2016-08-17 21:41:49 <leo-unglaub> yes
2016-08-17 21:42:42 <leo-unglaub> he claims that key are not weakened by this ... however .. i dont trust that statement ..
2016-08-17 21:42:56 <leo-unglaub> knowing what a rng will produce always wreakens stuff
2016-08-17 21:43:00 <leo-unglaub> thats the point of it
2016-08-17 21:43:40 <skarnet> I just tweeted the honest announcement, as you can see :D
2016-08-17 21:46:04 <leo-unglaub> *g*
2016-08-18 09:40:36 <fcolista> does it make sense that we have phonon in main ?
2016-08-18 09:41:11 <^7heo> couldn't we have a `bloat` repository for such things?
2016-08-18 09:41:52 <fcolista> qt in main builds withoug phonon bindings
2016-08-18 09:42:15 <ScrumpyJack> morning
2016-08-18 09:42:30 <^7heo> I mean, if it has to be politically correct, we could call the `bloat` repository `GUI`
2016-08-18 09:42:36 <^7heo> moin ScrumpyJack
2016-08-18 09:42:51 <clandmeter> fcolista: its currently in community?
2016-08-18 09:43:00 <fcolista> i would move in community: phonon, phonon-backend-gstreamer, automoc4 and quassel
2016-08-18 09:43:01 <fcolista> no
2016-08-18 09:43:05 <fcolista> clandmeter, are in main
2016-08-18 09:43:10 <fcolista> morning ScrumpyJack
2016-08-18 09:43:16 <clandmeter> oh ok
2016-08-18 09:43:23 <clandmeter> now i understand your question :)
2016-08-18 09:43:29 <fcolista> but, frankly...
2016-08-18 09:43:34 <clandmeter> i get your point
2016-08-18 09:43:35 <fcolista> havin kde stuff in main..
2016-08-18 09:43:42 <fcolista> i don't like it
2016-08-18 09:43:44 <clandmeter> nothing in main depends on it?
2016-08-18 09:44:01 <clandmeter> if not, just move to community.
2016-08-18 09:44:06 <fcolista> i did a grep -r for phonon and automoc4
2016-08-18 09:44:28 <fcolista> but i think that i should use a more scientific approach with that
2016-08-18 09:45:45 <fcolista> maybe looking at the .so library
2016-08-18 09:45:52 <fcolista> and apk search -r $lib.so
2016-08-18 09:46:21 <^7heo> all jokes (about bloat) aside, I think that it would simplify and ease maintaining and usage to have GUI stuff in a GUI dedicated repo
2016-08-18 09:46:36 <^7heo> then we can keep what's system essential in main (aka system)
2016-08-18 09:46:43 <^7heo> and what's user-important in gui
2016-08-18 09:46:44 <fcolista> that's not a bad idea at all...
2016-08-18 09:47:01 <fcolista> *after all
2016-08-18 09:47:04 <^7heo> because honestly, by default, we don't install much GUI
2016-08-18 09:47:13 <^7heo> if we can call CLI GUI, which I don't, anyway
2016-08-18 09:47:29 <clandmeter> fcolista: you can also use pkgs.a.o :)
2016-08-18 09:47:31 <^7heo> but the default UI is limited to CLI, and that should anyway stay that way.
2016-08-18 09:47:32 <clandmeter> http://pkgs.alpinelinux.org/package/edge/main/x86_64/phonon
2016-08-18 09:47:44 <^7heo> clandmeter: do we have an API there?
2016-08-18 09:47:51 <fcolista> clandmeter, yeah :) waiting fro API :)
2016-08-18 09:47:52 <^7heo> clandmeter: so to be able to use CLI tools to query it?
2016-08-18 09:47:53 <fcolista> *for
2016-08-18 09:48:03 <^7heo> ah ok that answers my quesiton
2016-08-18 09:48:06 <^7heo> s/it/ti/
2016-08-18 09:48:11 <clandmeter> we have apk to do cli stuff
2016-08-18 09:48:19 <^7heo> clandmeter: apk is limited.
2016-08-18 09:48:22 <clandmeter> except for contenst of course
2016-08-18 09:48:25 <^7heo> clandmeter: yeah
2016-08-18 09:48:46 <^7heo> and also apk misses various information
2016-08-18 09:48:51 <^7heo> i.e. there is no way to filter by maintainer afaik
2016-08-18 09:49:01 <clandmeter> vkris: is building an json api from pkgs db.
2016-08-18 09:49:02 <fcolista> o would move attica as well in community
2016-08-18 09:49:05 <^7heo> or it's not possible to find the SHA of a commit corresponding to a package, etc.
2016-08-18 09:49:29 <^7heo> vkris: if your work's already open source, I'd be interested in checking it
2016-08-18 09:49:37 <clandmeter> check his repo
2016-08-18 09:49:48 <^7heo> gh/g.a.o?
2016-08-18 09:49:56 <clandmeter> https://github.com/insteps?tab=repositories
2016-08-18 09:50:40 <^7heo> thx
2016-08-18 09:51:18 <clandmeter> fabled will start working on new apk-tools.
2016-08-18 09:51:25 <^7heo> didn't he start already?
2016-08-18 09:51:31 <clandmeter> kind of
2016-08-18 09:51:32 <^7heo> I thought he had
2016-08-18 09:51:39 <clandmeter> but not the coding part
2016-08-18 09:51:44 <^7heo> ah ok
2016-08-18 09:51:59 <^7heo> well implementation is important, but that's usually not where this community can screw up ;)
2016-08-18 09:52:18 <clandmeter> it will have the missing features
2016-08-18 09:52:28 <clandmeter> plus i hope it have lua bindings for all of them.
2016-08-18 09:52:39 <clandmeter> then we can hook pkgs.a.o directly into aok
2016-08-18 09:52:40 <^7heo> \o/
2016-08-18 09:52:41 <clandmeter> apk
2016-08-18 09:52:44 <^7heo> yeah
2016-08-18 09:52:51 <^7heo> and then behold the load!
2016-08-18 09:53:36 <^7heo> damn, are we really doing this in PHP?
2016-08-18 09:53:40 <^7heo> https://github.com/insteps/aport-api
2016-08-18 09:56:09 <clandmeter> please respect what a developer choses. if you can do it better in another language, you are free to do so.
2016-08-18 09:56:51 <fcolista> +1
2016-08-18 09:57:11 <^7heo> yeah sorry
2016-08-18 09:57:24 <^7heo> I just didn't expect someone here to do programming in a templating language.
2016-08-18 09:57:42 <^7heo> but okay, I'll be quiet about this unless I do better.
2016-08-18 09:58:18 <clandmeter> we will be monitoring your github repo ;-)
2016-08-18 09:58:25 <^7heo> Huhu
2016-08-18 09:58:32 <^7heo> What a waste of monitoring ;)
2016-08-18 09:58:44 <^7heo> but okay, I'll give it a spin
2016-08-18 09:58:47 <fcolista> boom
2016-08-18 09:58:56 <^7heo> afterall, it's something that interests me quite a lot
2016-08-18 09:58:59 <fcolista> pushed :)
2016-08-18 09:59:03 <^7heo> I just have already a lot on my plate.
2016-08-18 09:59:11 <^7heo> but let's see if I can eat more :)
2016-08-18 10:00:09 <clandmeter> fcolista: nice!
2016-08-18 10:00:18 <clandmeter> keeping main clean is good!
2016-08-18 10:01:47 <clandmeter> I just received some arm goodness :D
2016-08-18 10:12:05 <clandmeter> https://twitter.com/clandmeter/status/766215821257543680
2016-08-18 10:13:22 <fcolista> clandmeter, WOW :)
2016-08-18 10:16:37 <leo-unglaub> hey
2016-08-18 10:23:55 <clandmeter> hi
2016-08-18 10:24:56 <fcolista> clandmeter, i've upgraded openjpeg.
2016-08-18 10:24:59 <fcolista> checkapk returns:
2016-08-18 10:25:00 <fcolista> https://github.com/uclouvain/openjpeg/archive/v2.1.1.tar.gz
2016-08-18 10:25:06 <fcolista> sorry
2016-08-18 10:25:08 <fcolista> this:
2016-08-18 10:25:09 <fcolista> -usr/lib/libopenjp2.so.2.1.0
2016-08-18 10:25:09 <fcolista> +usr/lib/libopenjp2.so.2.1.1
2016-08-18 10:25:10 <^7heo> clandmeter: wait, for free?!
2016-08-18 10:25:28 <fcolista> so, it breaks abi compat?
2016-08-18 10:27:49 <clandmeter> ^7heo: http://alpinelinux.org/sponsors
2016-08-18 10:28:42 <clandmeter> fcolista: https://github.com/uclouvain/openjpeg/blob/v2.1.1/NEWS.md
2016-08-18 10:29:01 <fcolista> clandmeter, thx :)
2016-08-18 10:29:10 <fcolista> gotta read the readme :)
2016-08-18 10:29:11 <^7heo> I see
2016-08-18 10:30:47 <clandmeter> fcolista: i doesnt break abi, but i would still be carefull.
2016-08-18 10:30:52 <^7heo> well, that's cool
2016-08-18 10:30:56 <^7heo> really, really cool
2016-08-18 10:31:01 <^7heo> (about gigabyte)
2016-08-18 10:31:08 <^7heo> Since when do they sponsor us?
2016-08-18 10:31:17 <fcolista> clandmeter, fwiw, we have few packages redepnding from openjpeg anyway
2016-08-18 10:38:05 <clandmeter> what is the easiest way to connect SFP+ to existing SFP or RJ45?
2016-08-18 11:12:14 <skarnet> clandmeter: I'm taking ownership for s6-dns and s6-networking. I know they work. Do I simply move them to main/ or is there more to the procedure?
2016-08-18 11:15:47 <clandmeter> ownership is the only thing needed.
2016-08-18 11:16:13 <clandmeter> and moving of course.
2016-08-18 11:16:17 <clandmeter> i guess main should be ok.
2016-08-18 11:17:28 <jirutka> clandmeter: not just ownership, it should also work and maintainer should be able to maintain it for half a year for community or 2 years for main, isn’t that right?
2016-08-18 11:17:46 <skarnet> jirutka: I can commit to that ;)
2016-08-18 11:18:12 <clandmeter> jirutka: of course, but i have faith in skarnet ;-)
2016-08-18 11:18:31 <jirutka> :)
2016-08-18 11:23:29 <coredumb> clandmeter: AFAIK there's no way ... SFP+ goes with SFP+
2016-08-18 11:25:57 <clandmeter> coredumb: hmm im reading some transefers do support it?
2016-08-18 11:26:16 <clandmeter> my procurve only has SFP
2016-08-18 11:26:56 <coredumb> 10Gb SFP ?
2016-08-18 11:27:27 <clandmeter> http://www.fit-foxconn.com/Product/ProductDetail?topClassID=Electronic%20Module&&PN=AFBR-709DMZ
2016-08-18 11:28:20 <coredumb> yeah what connectic do you want ?
2016-08-18 11:28:46 <clandmeter> well my switch support gigabit rj45 and SFP
2016-08-18 11:28:57 <clandmeter> and this server does 10G and 40G
2016-08-18 11:29:07 <clandmeter> lets not talk about 40G :)
2016-08-18 11:29:16 <coredumb> ethernet or SFP for the server ?
2016-08-18 11:29:34 <coredumb> the switch does only gigabit or the SFPs do 10Gb ?
2016-08-18 11:29:40 <clandmeter> server only has SFP+ or the QSFP
2016-08-18 11:29:59 <coredumb> then you need 10G SFP+ to connect to it
2016-08-18 11:30:16 <clandmeter> so i need to upgrade my switch to connect to it?
2016-08-18 11:30:21 <coredumb> guess so
2016-08-18 11:30:43 <clandmeter> there are not transceivers that can convert SFP+ to ethernet?
2016-08-18 11:30:50 <coredumb> wnot in 10G
2016-08-18 11:31:01 <clandmeter> i dont care about the speed.
2016-08-18 11:31:10 <coredumb> it just won't work
2016-08-18 11:31:27 <clandmeter> nice for backwards compat....
2016-08-18 11:31:47 <clandmeter> maybe ill just buy an usb3 gigabit ethernet ;-)
2016-08-18 11:31:52 <coredumb> you'd take 10G rj45 for backward compat
2016-08-18 11:32:21 <clandmeter> well, i have no choice ;)
2016-08-18 11:32:37 <coredumb> so you have to change somting
2016-08-18 11:32:48 <clandmeter> whats this? https://ic.tweakimg.net/ext/i/1333527891.gif
2016-08-18 11:32:52 <coredumb> may be cheaper to just buy a 1Gb ethernet card
2016-08-18 11:32:55 <coredumb> :)
2016-08-18 11:33:18 <coredumb> it's a 1Gb rj45 SFP
2016-08-18 11:33:18 <^7heo> clandmeter: an SFP adapter?
2016-08-18 11:33:35 <coredumb> AFAIK that's not compatible with 10G SFP
2016-08-18 11:33:41 <^7heo> AFAIK too
2016-08-18 11:34:08 <coredumb> clandmeter: just get yourself a gigabit intel card
2016-08-18 11:34:42 <coredumb> in gigabit you can mix rj45 <> SFP + rj45 tranceivers
2016-08-18 11:34:51 <coredumb> in 10G you chose the hardware
2016-08-18 11:35:02 <coredumb> either you do copper rj45 all the way
2016-08-18 11:35:03 <^7heo> yeah but it's not the same price obv.
2016-08-18 11:35:04 <coredumb> or SFP
2016-08-18 11:35:09 <coredumb> but you can't mix
2016-08-18 11:35:20 <coredumb> ^7heo: clearly
2016-08-18 11:35:30 <^7heo> the required switching circuits for 10G are a tad more 'spensive.
2016-08-18 11:35:55 <coredumb> usually high end 10G switches don't even come with rj45 it's SFP only
2016-08-18 11:36:09 <coredumb> "high end"
2016-08-18 11:36:12 <coredumb> ;)
2016-08-18 11:36:32 <coredumb> so yeah ... that sh*t is pricy
2016-08-18 11:36:54 <skarnet> by trying to be fancy and hesitating, you already lost whatever benefit SFP could bring you. If you choose to go that way, you will lose a lot more time making it work.
2016-08-18 11:37:24 <^7heo> skarnet: care to elaborate?
2016-08-18 11:37:32 <coredumb> yeah ?
2016-08-18 11:38:33 <skarnet> when the goal is "make things work" and you have a choice between a technology you master and one that's slightly less ubiquitous and you have less experience with, what do you do?
2016-08-18 11:40:03 <skarnet> if the goal is "learn things and make things work *better*" then it's an entirely different perspective and answer :P
2016-08-18 11:40:22 <coredumb> skarnet: well you're not entirely wrong but it's not only working like that
2016-08-18 11:40:40 <coredumb> let's say you need stackable switches in 10G
2016-08-18 11:40:59 <coredumb> AFAIK any decent stackable switch in 10G uses SFP
2016-08-18 11:41:18 <coredumb> so you got no choice but to have your servers connected with SFP as well
2016-08-18 11:41:30 <coredumb> even if you don't really know it "better"
2016-08-18 11:41:39 <skarnet> then you're at a point where the decision has already been made for you, and you better learn the tech if you don't know it yet :P
2016-08-18 11:41:58 <coredumb> I don't think we were arguing over that :D
2016-08-18 11:42:10 <clandmeter> this will do just fine: http://www.intel.com/content/www/us/en/wireless-products/dual-band-wireless-ac-7260-bluetooth-desktop.html
2016-08-18 11:42:18 <coredumb> I don't think we were arguing at all actually
2016-08-18 11:42:27 <clandmeter> :p
2016-08-18 11:42:50 <skarnet> looks like a weird hook on a rope
2016-08-18 11:44:31 <coredumb> clandmeter: I stick to my words... any gigabit card would do better :D
2016-08-18 11:44:37 <skarnet> clandmeter: unless cables are a real hindrance (e.g. computers in human living quarters) you should never choose wifi over wired :/
2016-08-18 11:45:31 <clandmeter> skarnet: sarcasm mode was turned on.
2016-08-18 11:47:27 <skarnet> sorry, my sarcasmometer comes from GNU, it randomly fails sometimes
2016-08-18 11:48:17 <coredumb> lol
2016-08-18 11:48:31 <leo-unglaub> clandmeter: i think your proposal is great
2016-08-18 11:48:46 <leo-unglaub> better to have less packages, but working and high quality packages
2016-08-18 11:48:58 <leo-unglaub> i would give you a +1 for it, but thats sooo 2014 ...
2016-08-18 11:51:54 <skarnet> how about a 'like'
2016-08-18 11:51:57 <skarnet> 
ACTION hides

2016-08-18 11:52:22 <leo-unglaub> 
ACTION hunts down skarnet

2016-08-18 12:03:37 <vkris> clandmeter: re ^^ intel Linux*
2016-08-18 12:03:38 <vkris> (most features not available on Linux)
2016-08-18 12:03:50 <vkris> check product brief pdf
2016-08-18 12:08:20 <jirutka> 
ACTION is old-school, still gives favs :P

2016-08-18 12:16:38 <^7heo> jirutka: what 'bout cookies?
2016-08-18 12:16:55 <jirutka> ^7heo: ?
2016-08-18 12:17:05 <^7heo> favs == cookies
2016-08-18 12:17:10 <^7heo> or stickers
2016-08-18 12:17:26 <^7heo> or you know, any token that has a value
2016-08-18 12:17:33 <^7heo> ;)
2016-08-18 12:20:52 <clandmeter> vkris: what are you talking about?
2016-08-18 12:22:33 <vkris> http://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/dual-band-wireless-ac-7260-bluetooth-desktop-brief.pdf
2016-08-18 12:23:24 <clandmeter> ok thx.
2016-08-18 12:23:42 <^7heo> what was that?
2016-08-18 12:23:52 <clandmeter> now i wont put an wifi adapter in this 48core server.
2016-08-18 12:23:54 <clandmeter> ;-)
2016-08-18 12:24:04 <vkris> hmmm.. why can't we just use open air lasers installed overhead(ceilings) for net connection ;)
2016-08-18 12:24:35 <^7heo> vkris: because if you have a cat, you'll get the worst connection stability ever.
2016-08-18 12:24:50 <^7heo> and it's well known that netengs like cats.
2016-08-18 12:25:39 <^7heo> also because of the complexity of keeping the lasers aligned.
2016-08-18 12:26:26 <vkris> you mean a zombie cat that can walk on ceilings
2016-08-18 12:28:36 <fcolista> had to revert openvas stuff
2016-08-18 12:29:19 <fcolista> i miss a perl package and i was entrapped in perl-nightmare-dependencies-hell
2016-08-18 12:29:30 <vkris> if you have good fixtures and concave mirror receivers ?
2016-08-18 13:02:51 <skarnet> what kind of carpet has gcc-6.1.1 smoked?
2016-08-18 13:03:24 <skarnet> not/ usrbe/ libused/ gccwhen/ x86_64making- alpine-linux-musl/6.1.1/../../../../x86_64a- alpineshared-linux -objectmusl;/ binrecompile/ ldwith :-fPIC
2016-08-18 13:03:24 <skarnet>  /finalusr /linklib /failedgcc:/ x86_64Bad- alpine-linux-musl/6.1.1/../../../../x86_64-valuealpine
2016-08-18 13:03:24 <skarnet> -collect2: error: ld returned 1 exit status
2016-08-18 13:03:45 <skarnet> yes, that's legit output
2016-08-18 13:03:45 <fcolista> lol
2016-08-18 13:13:33 <skarnet> I'm definitely having trouble with that latest gcc, when linking a shared lib with -lothersharedlib
2016-08-18 13:13:57 <skarnet> it doesn't detect the shared lib with -l, but the static one instead, so it obviously fails
2016-08-18 13:23:06 <coredumb> can someone merge patches 2316 and 2317 so I could move them to community ?
2016-08-18 13:41:26 <przemoc> skarnet: even when prepended with following? -Wl,-Bdynamic
2016-08-18 13:44:06 <skarnet> przemoc: please, my lunch hasn't entirely been digested yet
2016-08-18 13:44:27 <skarnet> I'm good, I think I understand the problem and I have an easy fix
2016-08-18 13:47:24 <przemoc> not sure about your lunch, but it's kind of linking idiom to do  -Wl,-Bstatic $(SLIBS) -Wl,-Bdynamic $(DLIBS)  so you can do -lwhatever for both static and shared libs (and easily change it if needed)
2016-08-18 13:49:46 <skarnet> anything that involves -Wl,-B* is definitely not idiomatic and you should normally not need to do that
2016-08-18 14:06:50 <skarnet> clandmeter: patch sent to alpine-aports
2016-08-18 14:48:50 <Klowner> does alpine have a something like an `update-alternatives`? This package ends up with variant packages, I'm not sure if I should name each binary differently or what the general proper way to do that is
2016-08-18 17:26:32 <stwa> is there any rule to decide which packages from testing move to main and which to community?
2016-08-18 17:26:52 <stwa> i can't find anything about it in the wiki
2016-08-18 17:47:51 <ncopa> stwa, in general move it to community
2016-08-18 17:47:59 <ncopa> we want as much as possible in community
2016-08-18 17:48:49 <ncopa> if we need support the package for longer than 6month in stable, then we move it to main
2016-08-18 17:49:02 <ncopa> that does require that it will be possible for us to maintain it
2016-08-18 17:49:11 <ncopa> eg that upstream provides sesc fixes etc
2016-08-18 17:53:21 <stwa> ncopa: ahh thanks, i understand
2016-08-18 17:53:39 <stwa> then i will start moving my pkgs to community
2016-08-18 17:57:47 <ncopa> would be great
2016-08-18 17:57:48 <ncopa> thanks
2016-08-18 18:17:49 <skarnet> ncopa: you ok with me moving my packages to main, if I commit to maintaining them?
2016-08-18 18:26:56 <ncopa> the s6 stuff?
2016-08-18 18:27:01 <ncopa> yes i think we want that in main
2016-08-18 18:27:29 <Klowner> ohh, travis and your 1hr time limit :|
2016-08-18 18:27:38 <ncopa> :D
2016-08-18 18:29:26 <Klowner> idk how many people will actually be interested in having blender
2016-08-18 18:30:22 <vkris> HTTP/2 by default, http://www.phoronix.com/scan.php?page=news_item&px=Clear-Linux-Highlights-3
2016-08-18 18:31:04 <vkris> I thought we were more edgy
2016-08-18 18:33:39 <Klowner> sounds weird
2016-08-18 18:51:02 <skarnet> ncopa: I also meant the other stuff such as s6-dns and s6-networking (natural extensions, but not strictly necessary)
2016-08-18 18:54:51 <clandmeter> apk add powershell
2016-08-18 18:54:56 <clandmeter> oh sorry
2016-08-18 18:54:59 <clandmeter> wrong window
2016-08-18 18:59:15 <scadu> clandmeter: nice try :P
2016-08-18 18:59:35 <clandmeter> :p
2016-08-18 19:01:10 <clandmeter> im waiting for the news to say: windows server core to support linux kernel :)
2016-08-18 19:02:02 <scadu> RIP
2016-08-18 19:16:13 <clandmeter> ncopa: do we have a way to test if packages dont depends on repo's they shouldnt?
2016-08-18 19:18:28 <przemoc> you mean like main pkg depending on community pkg?
2016-08-18 19:20:22 <clandmeter> like ppl moving stuff to community and and didnt check if some of the deps are still in testing.
2016-08-18 19:20:26 <clandmeter> see #commits
2016-08-18 19:20:37 <clandmeter> it was to be expected.
2016-08-18 19:23:01 <clandmeter> skarnet: can you keep your commit subjet in a more respectable lenght next time?
2016-08-18 19:28:29 <przemoc> vim should already wrap the subject for you and make second line red
2016-08-18 19:28:38 <przemoc> 
ACTION doubts skarnet uses emacs

2016-08-18 19:29:01 <clandmeter> is emacs posix?
2016-08-18 19:29:04 <clandmeter> :p
2016-08-18 19:33:44 <^7heo> 
ACTION coughs

2016-08-18 19:36:17 <skarnet> clandmeter: ok, I just wanted to be descriptive ^^'
2016-08-18 19:36:49 <skarnet> if you don't like long commit messages, never look at musl's git log
2016-08-18 19:37:06 <clandmeter> atleast you used words i could understand this time ;-)
2016-08-18 19:37:29 <clandmeter> they dont break them after x chars?
2016-08-18 19:38:16 <skarnet> musl's commit logs are where most of the comments are
2016-08-18 19:38:18 <skarnet> not in the source
2016-08-18 19:38:20 <skarnet> in the git logs
2016-08-18 19:48:30 <clandmeter> skarnet: i just checked it, the commit subject is never that long.
2016-08-18 19:49:16 <clandmeter> we usualy have a short subject and put the rest of the info on the next line.
2016-08-18 20:03:32 <skarnet> well I just used git format-patch
2016-08-18 20:03:43 <skarnet> and git send-email
2016-08-18 20:08:13 <przemoc> the thing is how you form commit message.  there is convention in git that subject (synopsis) is no longer than 72, which is IMHO sane actually.  provide details in next paragraph when needed.
2016-08-18 20:12:05 <przemoc> possibly silly question coming.  is  /var/run -> /run  by default in AL?  I don't see such thing in alpine-baselayout, yet I have it on my system and lxcs.  I cannot remember whether I created such symlinks myself (I doubt it), so where they could come from?
2016-08-18 20:14:12 <clandmeter> openrc?
2016-08-18 20:22:04 <przemoc> right, openrc's /etc/init.d/bootmisc migrate_to_run calls
2016-08-18 20:23:19 <jirutka> ncopa: could you please look at https://github.com/alpinelinux/aports/pull/215 and https://github.com/alpinelinux/aports/pull/212 ?
2016-08-18 20:24:23 <przemoc> shouldn't we make the var/run symlink (and possibly var/lock too) in alpine-baselayout already?
2016-08-18 20:25:46 <przemoc> while var/lock symlink can be not nice if run is not populated, there shouldn't be any problem with var/run I think
2016-08-18 20:30:40 <przemoc> rephrasing question:  is there any good argument against making  var/run -> ../run  symlink in alpine-baselayout?
2016-08-18 20:31:59 <skarnet>  /run is a tmpfs, right? What is /var? part of / ? another fs?
2016-08-18 20:33:42 <przemoc> > [/var/run] This directory contains system information data describing the system since it was booted. Files under this directory must be cleared (removed or truncated as appropriate) at the beginning of the boot process.
2016-08-18 20:33:53 <przemoc> since /run introduction it's kind of redundant
2016-08-18 20:34:45 <skarnet> I'm not asking what FHS says
2016-08-18 20:34:52 <skarnet> I couldn't care less about what FHS says
2016-08-18 20:35:00 <skarnet> I'm asking what Alpine does
2016-08-18 20:35:24 <przemoc> AL purpose of /var/run seems the same
2016-08-18 20:35:46 <skarnet> I must be expressing myself like a potato
2016-08-18 20:36:17 <skarnet> I want to know the technical details of /var mounting
2016-08-18 20:36:21 <skarnet> not the purpose
2016-08-18 20:37:00 <skarnet> I could look into the baselayout myself but I thought it'd be faster to ask
2016-08-18 20:37:05 <skarnet> (I was wrong)
2016-08-18 20:37:36 <przemoc> baselayout has run and var/run as normal directories
2016-08-18 20:37:44 <przemoc> I guess that was obvious from my question already
2016-08-18 20:37:53 <skarnet> yes
2016-08-18 20:37:56 <skarnet> and what about var
2016-08-18 20:37:57 <przemoc> and openrc bootmist boot service already does the conversion
2016-08-18 20:38:02 <przemoc> s/mist/misc/
2016-08-18 20:38:08 <skarnet> am I speaking English? just checking
2016-08-18 20:38:39 <jcmartins> hi I'm run latest alpine but ppp don't load ?
2016-08-18 20:39:33 <jcmartins> modprobe ppp_generic
2016-08-18 20:39:34 <jcmartins> modprobe: FATAL: Module ppp_generic not found in directory /lib/modules/4.4.17-0-virtgrsec
2016-08-18 20:40:17 <jcmartins> it't the same to moprobe ppp and modprobe rp-pppoe
2016-08-18 20:46:11 <jzono1_> did you try the non-virt kernel package?
2016-08-18 20:46:46 <jcmartins> no I'm using xen package
2016-08-18 20:47:53 <jzono1_> even if you're actually running alpine as a guest of some hypervisor, it sometimes makes sense to run a full kernel instead of the stripped down virt-kernel package
2016-08-18 20:48:42 <jzono1_> (say if you want to use hardware that normally don't appear in vm guests... like something that uses ppp)
2016-08-18 20:49:45 <przemoc> skarnet: is there any reason you try hard being mean here?  I value your input, but don't get your behavior now.  /run is mounted rather early enough (openrc's /lib/rc/sh/init.sh does that), so what kind of problems do you envision?  care to be more elaborate?  /var is not mounted unless you make it so yourself.
2016-08-18 20:50:33 <skarnet> so /var, by default, is part of the root filesystem? that's all I wanted to know.
2016-08-18 20:53:04 <jcmartins> I would like test a pppoe client connect
2016-08-18 20:54:09 <jzono1_> jcmartins: get the regular grsec kernel and you can do that
2016-08-18 20:54:34 <przemoc> the only problem I envision is backward compatibility, therefore tar within itself shouldn't contain such symlink, but conversion should be done in post-install/upgrade script
2016-08-18 20:57:21 <jcmartins> tks I will try
2016-08-18 21:13:09 <jcmartins> tks @jzono1  it's work!!!
2016-08-18 21:13:39 <jcmartins> I used vanilla and it's worked!
2016-08-18 21:15:27 <skarnet> grats!
2016-08-18 21:15:32 <skarnet> \o/
2016-08-18 21:40:31 <przemoc> my question came from the fact I noticed some problem (I'll send the patch later for that) on AL machine where bootmisc is in fact not started and /var/run and /run are different (as they are in alpine-baselayout), though I strongly suspect it's expected there they are the same, that's why it seems very good to make it true already after alpine-baselayout installation and not depend on some boot
2016-08-18 21:40:37 <przemoc> service to make such migration.
2016-08-18 21:45:07 <skarnet> I agree that /var/run and /run have the exact same semantics so it would make sense to merge them, and statically instead of dynamically by a boot service.
2016-08-18 21:47:10 <przemoc> I guess I'll send mail about this matter to alpine-devel@ to gather more input whether we should change/improve the way things are now.  maybe there are some good reasons of how it is now I don't know.
2016-08-18 21:48:07 <przemoc> even in AL's data mode, where var is explicitly mounted (because the rootfs is ro), it shouldn't be a problem
2016-08-18 21:49:04 <skarnet> no, there's no impact when /var is mounted, a /var/run -> /run symlink works all the time
2016-08-18 21:52:02 <przemoc> that much I know, but I haven't used data mode myself, so maybe there are some "expectations" hardcoded somewhere, if you know what I mean...
2016-08-18 21:53:11 <skarnet> any expectation that /var/run is persistent is wrong, so if something breaks, that's an excellent opportunity to fix it :D
2016-08-18 21:55:02 <przemoc> I just don't like how absolute symlink  /var/run -> /run  doesn't work properly for nested rootfses
2016-08-18 21:55:53 <skarnet>  /var/run -> ../run
2016-08-18 21:57:39 <przemoc> that doesn't work in your case, e.g. /mnt/rwfs/var, i.e. if var is somewhere else originally where parent directory doesn't have run, I mean it doesn't work if you traverse via /mnt/rwfs/var
2016-08-18 21:59:20 <przemoc> there should be something like relsymlink with absolute path fallback :D
2016-08-18 21:59:39 <przemoc> I'm not aware of any such thing, though
2016-08-18 22:00:57 <skarnet> that works because we control the policy: we know that /var is the real mount point, and not /mnt/rwfs/var
2016-08-18 22:01:20 <skarnet> that wouldn't work in a vacuum, but in the AL framework, it does
2016-08-18 22:04:27 <przemoc> well, you're right and I needlessly wanted to make anyone happy for a moment.  and I don't see any reason to make this policy configurable in distro, after all distro has to lay some basic axioms, otherwise it would be kind of mess.
2016-08-18 22:05:21 <przemoc> s/anyone/everyone/ ;)
2016-08-18 23:48:30 <przemoc> http://lists.alpinelinux.org/alpine-aports/3366.html  is the patch I said I'd send later
2016-08-18 23:56:04 <przemoc> but mail about improving /run & /var/run state will have to wait (possibly around 24h), as it's sleep time for me now. ;)
2016-08-19 07:07:17 <ScrumpyJack> morning alpine climbers. Happy Friday!
2016-08-19 07:14:04 <coredumb> morning
2016-08-19 07:21:07 <scadu> o/
2016-08-19 07:25:15 <fcolista> clandmeter, py3-setuptools conflicts with python3
2016-08-19 07:25:37 <fcolista> 	10.250.16.173	
2016-08-19 07:25:42 <fcolista> ERROR: py3-setuptools-24.0.3-r2: trying to overwrite usr/bin/easy_install-3.5 owned by python3-3.5.2-r1.
2016-08-19 07:25:42 <fcolista> ERROR: py3-setuptools-24.0.3-r2: trying to overwrite usr/lib/python3.5/site-packages/easy_install.py owned by python3-3.5.2-r1.
2016-08-19 07:25:43 <fcolista> ERROR: py3-setuptools-24.0.3-r2: trying to overwrite usr/lib/python3.5/site-packages/setuptools/sandbox.py owned by python3-3.5.2-r1.
2016-08-19 07:25:43 <fcolista> ERROR: py3-setuptools-24.0.3-r2: trying to overwrite usr/lib/python3.5/site-packages/setuptools/depends.py owned by python3-3.5.2-r1.
2016-08-19 07:25:49 <fcolista> etc.
2016-08-19 07:25:49 <fcolista> etc
2016-08-19 07:25:52 <clandmeter> hmm
2016-08-19 07:26:06 <clandmeter> i didnt have that issue.
2016-08-19 07:26:36 <clandmeter> python is giving me a headache
2016-08-19 07:26:41 <clandmeter> not only me.
2016-08-19 07:26:42 <clandmeter> :)
2016-08-19 07:26:49 <fcolista> heh
2016-08-19 07:28:18 <clandmeter> i dont have this issue on aarch64
2016-08-19 07:29:05 <clandmeter> seems its not bundled on aarch64
2016-08-19 07:29:26 <clandmeter> fcolista: what happends if you rebuild python3?
2016-08-19 07:29:56 <clandmeter> is the inclusion really arch specific?
2016-08-19 07:30:35 <clandmeter> http://tpaste.us/Ayzk
2016-08-19 07:30:46 <clandmeter> thats my apk info -L python3 |grep setuptools
2016-08-19 07:31:46 <fcolista> that's my
2016-08-19 07:31:46 <fcolista> http://sprunge.us/ZCZA
2016-08-19 07:31:49 <clandmeter> http://tpaste.us/3Y6M this is on 64bit
2016-08-19 07:31:56 <clandmeter> x96
2016-08-19 07:32:00 <clandmeter> -10 :)
2016-08-19 07:32:20 <fcolista> my paste is on x86_64
2016-08-19 07:33:01 <ScrumpyJack> it's lovely to see people responding to your call clandmeter, and moving stuff to community
2016-08-19 07:35:03 <fcolista> i need to move openvas and gns3
2016-08-19 07:35:08 <przemoc> well, fear of loss is a great motivation :)
2016-08-19 07:35:20 <fcolista> but there are _tons_ of perl dependencies for openvas
2016-08-19 07:35:28 <fcolista> which is quite an hell
2016-08-19 07:35:32 <fcolista> gotta find the time to do that
2016-08-19 07:36:09 <clandmeter> yes
2016-08-19 07:36:19 <clandmeter> ppll are move stuff without checking their deps from testing.
2016-08-19 07:36:29 <clandmeter> most of it is perl
2016-08-19 07:36:40 <fcolista> do we have a clever way to visually track dependencies?
2016-08-19 07:36:42 <clandmeter> i remember some of them were yours.
2016-08-19 07:36:46 <fcolista> yes
2016-08-19 07:36:47 <clandmeter> yes
2016-08-19 07:37:01 <clandmeter> move them to community, disable testing repo, and build.
2016-08-19 07:37:02 <clandmeter> :)
2016-08-19 07:37:15 <fcolista> heh. which ones? :)
2016-08-19 07:37:25 <clandmeter> which ones?
2016-08-19 07:37:27 <fcolista> dependency1 -> 2 -> 3
2016-08-19 07:37:39 <clandmeter> check the ml
2016-08-19 07:37:49 <clandmeter> i replied somebody with some of the packages he moved
2016-08-19 07:37:55 <clandmeter> but the are missing deps.
2016-08-19 07:38:15 <clandmeter> actually the developers should contact you to ask if you can move them (if you are the maintainer).
2016-08-19 07:38:44 <fcolista> but this does not answer to my question :)
2016-08-19 07:39:01 <fcolista> do we have a clever way to visually track dependencies?
2016-08-19 07:39:36 <clandmeter> in which context?
2016-08-19 07:39:51 <fcolista> perl-A dependes from perl-B
2016-08-19 07:39:56 <ScrumpyJack> can someone take a look at bogofilter? it seems to be in both community and testing
2016-08-19 07:40:02 <fcolista> Perl-B depends to Perl-C and Perl-D
2016-08-19 07:40:18 <fcolista> so, we have a tree where perl-A is the root
2016-08-19 07:40:33 <fcolista> and then Perl B -> Perl-C / Perl-D
2016-08-19 07:41:32 <fcolista> http://collab-maint.alioth.debian.org/debtree/
2016-08-19 07:41:44 <fcolista> debian has
2016-08-19 07:42:08 <clandmeter> I dont know.
2016-08-19 07:42:24 <clandmeter> ask ncopa or fabled
2016-08-19 07:42:36 <clandmeter> of which both are not here
2016-08-19 07:42:40 <fcolista> http://kmkeen.com/pacgraph/
2016-08-19 07:42:45 <clandmeter> maybe send an email
2016-08-19 07:42:48 <fcolista> pacman too has
2016-08-19 07:43:06 <clandmeter> i remeber we had such feature in apk
2016-08-19 07:43:18 <clandmeter> which can create an pic
2016-08-19 07:43:49 <clandmeter> apk dot --help
2016-08-19 07:48:15 <fcolista> that's fine with libraries, yes. But perl is a different kind of dependency
2016-08-19 07:52:50 <fcolista> is someone remeber how to use api.alpinelinux.org ?
2016-08-19 07:53:25 <fcolista> I can start from there for tracking dependency
2016-08-19 07:58:22 <przemoc> grep #alpine-* logs for vkris's examples of use and check https://github.com/insteps/aport-api/tree/master/docs
2016-08-19 07:58:50 <przemoc> what's different about perl dependencies?
2016-08-19 07:59:43 <ScrumpyJack> does stuff need a Maintainer before going into community?
2016-08-19 08:00:58 <clandmeter> ScrumpyJack: yes
2016-08-19 08:01:25 <fcolista> przemoc, thx
2016-08-19 08:01:39 <fcolista> perl is different because does not add .so files
2016-08-19 08:02:00 <fcolista> they are not dynamically linked to the main elf
2016-08-19 08:02:14 <fcolista> so apk dot is not the tool in this case
2016-08-19 08:04:27 <przemoc> new grandiose apk should have plugins for tracking non-elf dependencies :)
2016-08-19 08:04:40 <przemoc> abuild
2016-08-19 08:05:02 <fcolista> yes
2016-08-19 08:05:39 <skarnet> that would be in addition to the manually declared dependencies, right?
2016-08-19 08:06:02 <przemoc> of course
2016-08-19 08:06:55 <przemoc> and should be possible to turn off when really-needed-I-know-what-I-am-doing
2016-08-19 08:26:03 <clandmeter> fcolista: you could try to look at aports-build and lua-aports
2016-08-19 08:26:40 <clandmeter> i think lua-aports can calculate deps from aport tree
2016-08-19 08:28:58 <fcolista> yes
2016-08-19 08:29:03 <fcolista> thx clandmeter
2016-08-19 08:30:32 <clandmeter> the problem with apk is, it doesnt know the build time deps.
2016-08-19 08:30:44 <clandmeter> only runtime
2016-08-19 08:33:06 <clandmeter> afk for today.
2016-08-19 08:45:54 <ScrumpyJack> there are 298 packages without maintainers. perhaps they could go straight into unmaintained?
2016-08-19 08:46:47 <ScrumpyJack> http://tpaste.us/G5gE
2016-08-19 08:49:43 <ScrumpyJack> or http://tpaste.us/AvzZ even
2016-08-19 09:17:35 <vkris> is there a way of knowing which repo its going to install from, eg `apk info ffmpeg`, output -> "http://...main/" ?
2016-08-19 09:18:30 <vkris> I could have multiple repo both having ffmpeg (same or diffrent versions)
2016-08-19 09:19:10 <vkris> maybe have `apk info -p <pkgname>` implemented
2016-08-19 09:21:14 <vkris> fcolista: for now would not `apk add <pkgname> --simulate` be useful to get deps?
2016-08-19 09:21:48 <fcolista> no
2016-08-19 09:21:58 <fcolista> that does not show what is in makedepends
2016-08-19 09:22:04 <fcolista> but only in depends
2016-08-19 09:22:31 <vkris> ah ! yes
2016-08-19 09:23:35 <vkris> maybe ask clandmeter to add another columns in db for that, and we call it "mdepends"
2016-08-19 09:23:42 <vkris> if possible
2016-08-19 09:27:02 <vkris> or table
2016-08-19 09:38:59 <clandmeter> that info is not available in apkindex, so its not possible.
2016-08-19 09:39:42 <clandmeter> pkgs.a.o uses apkindex, and as extra stored the filelist of each pkg.
2016-08-19 09:40:18 <clandmeter> so if you want this feature, its best to add a feature request on bugs.a.o under apk-tools project.
2016-08-19 09:43:09 <przemoc> clandmeter: apparently your afking was not strong enough.  could you wait with moving testing packages w/o maintainership till next weekend at least?  IIRC you wrote that it will be this or next, so I propose to not make it overly hasty.
2016-08-19 09:47:24 <^7heo> yeah and my answer to te mail of clandmeter didn't make it to the ML, just to the mailbox of clandmeter
2016-08-19 09:47:58 <^7heo> due to a combinated PEBKAC and horrific phone UI
2016-08-19 09:48:23 <^7heo> so +1 przemoc
2016-08-19 09:50:48 <przemoc> well, at least clandmeter's response to your mail was public:  http://lists.alpinelinux.org/alpine-devel/5436.html  (unless you sent more mails)
2016-08-19 09:53:19 <clandmeter> przemoc: i am not planning to move pkgs without maintainer
2016-08-19 09:53:32 <clandmeter> im planning to move them wihtout update of 6 months.
2016-08-19 09:54:01 <clandmeter> and if somebody has a problem, they can request them to be added back to testing/community.
2016-08-19 09:54:59 <clandmeter> we have 1800+ pkgs in testing, +/- 750 will be moved.
2016-08-19 09:55:18 <przemoc> even for those, I'm just asking to postpone the action till next weekend
2016-08-19 09:55:45 <clandmeter> i dont see a reason for this other then it makes my life harder.
2016-08-19 09:56:19 <clandmeter> but you can try to convice me
2016-08-19 09:58:37 <clandmeter> afk again :)
2016-08-19 09:58:44 <przemoc> it's to avoid moving packages around needlessly.  it's already Friday, not everyone has time to improve testing packages she or he was somewhat involved before Saturday (when I guess you want to do the move).  you sent the message only on Wednesday, so giving people at least week to improve stuff _before_ the grand move seems fair
2016-08-19 10:17:57 <przemoc> OTOH I understand that moving is quite cheap, so if you truly not care about messy aports history (when people will start moving packages back from unmaintained), you need to have clear aarch64 AL status right now (for whatever reason, like satisfying your employer for instance :>), then sure, go ahead and do the move.  in such case there is possibly no reason to even wait till this weekend (but
2016-08-19 10:18:03 <przemoc> possibly only after applying testing related patches from alpine-aports@ ML as they can change the status of some endangered packages).
2016-08-19 10:19:05 <przemoc> and now I'll be afk for many hours
2016-08-19 10:24:52 <^7heo> przemoc: ah then all is good.
2016-08-19 10:25:02 <^7heo> przemoc: I didn't realize
2016-08-19 11:02:47 <leo-unglaub> oh boy ... i am sooo fucking pissed today
2016-08-19 11:03:32 <leo-unglaub> a client of us hires a new IT consultant that wants to implement email vacation mails (complete bullshit, but okay) ... i tell that guy that he has sieve filters on theserver and he can do it with that. ... but now he wants a tutorial ...
2016-08-19 11:03:45 <leo-unglaub> that is an IT guy and wants a tutorial for sieve???
2016-08-19 11:03:46 <leo-unglaub> WTF
2016-08-19 11:05:36 <clandmeter> www.gmail.com
2016-08-19 11:05:41 <clandmeter> :)
2016-08-19 11:05:52 <leo-unglaub> his it company uses outlook.com *g*
2016-08-19 11:06:02 <leo-unglaub> so thats everything you need to know about a person
2016-08-19 11:34:43 <coredumb> leo-unglaub: there's THE IT guy, and there the IT consultant who's a nice bullshiter that doesn't know jack shit anyway
2016-08-19 11:35:06 <coredumb> you want a funny one ?
2016-08-19 11:35:34 <fcolista> boom
2016-08-19 11:35:43 <coredumb> something like 5y ago, we were overloaded with my colleague and so asked a consultant to finish one job for us
2016-08-19 11:35:48 <skarnet> well I've never had to use sieve filters, so I have no idea how they work. But I wouldn't have asked for a tutorial... just a pointer to the documentation.
2016-08-19 11:36:14 <coredumb> the job included creating a local copy a RHNS repo using mrepo
2016-08-19 11:36:22 <coredumb> nothing too fancy right ?
2016-08-19 11:36:37 <coredumb> my colleague had done half the job already
2016-08-19 11:36:51 <coredumb> so here comes the guy
2016-08-19 11:37:00 <coredumb> all certified RH
2016-08-19 11:37:34 <coredumb> "okok don't worry I fully understand your issue, will tackle that in 3 days"
2016-08-19 11:37:37 <coredumb> fair enough
2016-08-19 11:38:05 <coredumb> "here's the shell on a jumphost you're root you can distribute your key to the machines if you need"
2016-08-19 11:38:42 <coredumb> couple hours later: "coredumb please? Well you just gave me a shell, and whitout the gnome desktop I can't declare my ssh key"
2016-08-19 11:38:49 <coredumb> :O
2016-08-19 11:38:51 <coredumb> :O
2016-08-19 11:38:53 <coredumb> :O
2016-08-19 11:39:12 <coredumb> yep consulting proficiency at its best \o/
2016-08-19 11:40:10 <coredumb> indeed he didn't stay 3 days and we didn't pay his consulting  company
2016-08-19 11:42:51 <coredumb> I don't think there's another branch of work with as much incompetent ppl as computing/IT
2016-08-19 11:44:28 <leo-unglaub> coredumb: hahaha
2016-08-19 11:44:35 <leo-unglaub> thats awesome *g*
2016-08-19 11:44:51 <coredumb> leo-unglaub: sadly I could tell a lot more of these kinds
2016-08-19 11:44:54 <coredumb> like A LOT
2016-08-19 11:45:21 <coredumb> like way too much I wanna start wood working or another job
2016-08-19 11:45:32 <leo-unglaub> coredumb: actually its getting more and more ... the new tech  generation is mostly fucked as soon as they dont see a button that does exactly what they want
2016-08-19 11:45:47 <clandmeter> coredumb: bookmark #alpine-offtopic ;-)
2016-08-19 11:45:50 <coredumb> if only ...
2016-08-19 11:45:57 <coredumb> clandmeter: true
2016-08-19 11:46:53 <leo-unglaub> clandmeter: sorry, you are right
2016-08-19 11:47:31 <clandmeter> no need to be sorry, just reminding ppl.
2016-08-19 11:47:53 <clandmeter> i know some dont like too much verbosity in dev channel.
2016-08-19 11:54:53 <nmeum> could someone with access to an arm machine test %2340? Try building docker with it for instance.
2016-08-19 11:58:17 <clandmeter> nmeum: building on aarch64
2016-08-19 11:58:25 <clandmeter> if you concider that arm.
2016-08-19 11:59:42 <nmeum> nah, for aarch64 GOARCH is set to arm64 therefore the binary wasn't paxmarked before anyhow
2016-08-19 12:04:22 <clandmeter> aarch64 has no pax
2016-08-19 12:05:37 <clandmeter> ill have to patch our kernel to support arm compat, then we can build arm32 on this box.
2016-08-19 12:06:09 <clandmeter> but still without grsec...
2016-08-19 12:32:48 <leo-unglaub> nmeum: @i3 and stuff .. it can be merged into main .. i am using it from time to time and i am in the release mailinglist ... so i can keep it current
2016-08-19 12:33:23 <leo-unglaub> this here looks like a nice plugin for pidgin: https://github.com/majn/telegram-purple before i start building it, has anyone already done it?
2016-08-19 13:00:19 <fcolista> clandmeter, you there?
2016-08-19 13:02:38 <clandmeter> kind of
2016-08-19 13:02:58 <clandmeter> im still wondering about leo-unglaub question.
2016-08-19 13:03:00 <fcolista> just to let you know that i've pushed another tons of commit..
2016-08-19 13:03:12 <clandmeter> yes i see it.
2016-08-19 13:03:18 <fcolista> which question?
2016-08-19 13:03:24 <leo-unglaub> what question?
2016-08-19 13:03:30 <clandmeter> if i already done it.
2016-08-19 13:03:42 <leo-unglaub> clandmeter: i never asked you speciffic
2016-08-19 13:03:51 <leo-unglaub> i asked if someone else did it already
2016-08-19 13:03:58 <clandmeter> yes right
2016-08-19 13:04:15 <clandmeter> am i not part of someone?
2016-08-19 13:04:26 <leo-unglaub> hehe, sure you are
2016-08-19 13:04:52 <clandmeter> you can read that question in two ways.
2016-08-19 13:05:13 <clandmeter> :)
2016-08-19 13:06:18 <clandmeter> and its friday, we should keep an openmind :)
2016-08-19 13:06:26 <leo-unglaub> it is?
2016-08-19 13:06:29 <leo-unglaub> oh shit ...
2016-08-19 13:12:06 <^7heo> leo-unglaub: what's wrong with Friday?
2016-08-19 13:15:16 <leo-unglaub> nothing .. i just worked this week 2 time night ... so i am off by one day and thought its one day before friday
2016-08-19 13:16:48 <^7heo> ah ok
2016-08-19 13:16:55 <clandmeter> i had that ones between sunday and monday, but never on a friday.
2016-08-19 13:23:06 <skarnet> leo-unglaub: are you at least getting paid for it? :P
2016-08-19 13:23:12 <leo-unglaub> skarnet: nope
2016-08-19 13:24:03 <leo-unglaub> a thought about the entire testing directory in aports
2016-08-19 13:24:04 <skarnet> then that's not called night shifts, that's called partying all night and not wanting to admit it!
2016-08-19 13:24:36 <leo-unglaub> we could keep packages in testing until they get 3 positive reviews from knows reviewers
2016-08-19 13:24:38 <clandmeter> finaly a technical question here, does anybody know how to build an uefi compatible boot media? and i dont mean gumiboot as its x86_64 only.
2016-08-19 13:25:07 <leo-unglaub> only if they say that the package is clean and secure and okay it can be merged into community
2016-08-19 13:25:29 <clandmeter> i could only find info like this: http://wiki.osdev.org/UEFI
2016-08-19 15:18:48 <Klowner> there's no APKBUILD "best practices" doc or anything is there?
2016-08-19 15:26:09 <Klowner> hoping to save jirutka some effort by writing my junk right the first time
2016-08-19 15:29:48 <jirutka> Klowner: sadly we currently do not have this, but it’s on TODO list :)
2016-08-19 15:41:28 <vkris> clandmeter: mdds was in main/ ?
2016-08-19 15:41:41 <vkris> ca661f064fe894af1b2f36466953d8932c770f9b kinda dissapeared
2016-08-19 15:43:16 <vkris> hmmm libreoffice issue, cfec768f087fddb4b15a41290570a27091682841
2016-08-19 15:56:42 <clandmeter> libreoffice build on aarch64 :)
2016-08-19 15:57:01 <ncopa> really?
2016-08-19 15:57:03 <ncopa> wow
2016-08-19 15:57:07 <ncopa> thats kind of impressing
2016-08-19 15:57:19 <ncopa> tweet that
2016-08-19 15:58:16 <clandmeter> ncopa: there was an issue with libreoffice deps
2016-08-19 15:58:45 <clandmeter> seems you upgraded mdds to 1.2
2016-08-19 15:59:07 <clandmeter> libetonyek needs 1.0
2016-08-19 15:59:11 <ncopa> oh
2016-08-19 15:59:14 <ncopa> hum
2016-08-19 15:59:15 <clandmeter> so i added mdds1.0
2016-08-19 16:00:43 <clandmeter> i also bumped libetonyek to 1.4 so it would detect mdds1.0 correctly (but there is also an 1.6 out)
2016-08-19 16:00:54 <clandmeter> ill leave that to fabled if he wants to ugprade it.
2016-08-19 16:01:56 <ncopa> thanks
2016-08-19 20:08:29 <ncopa> anyone knows where build-edge-armhf went?
2016-08-19 21:46:03 <skarnet> it built the edge and went over it?
2016-08-19 21:48:30 <ncopa> ha
2016-08-19 21:48:34 <ncopa> ha
2016-08-19 21:48:40 <ncopa> ... ha .
2016-08-19 21:48:41 <ncopa> :)
2016-08-19 21:56:56 <clandmeter> crazy friday!
2016-08-19 22:02:46 <skarnet> thanks for pretending it was funny. I do appreciate it!
2016-08-19 22:07:20 <ncopa> i was not pretending
2016-08-19 22:07:30 <ncopa> i'm just slow at getting jokes
2016-08-19 22:07:31 <ncopa> :)
2016-08-20 01:55:48 <mitchty> so, I was double checking that my updates for things in testing were working, but it seems like the 2 packages that were there are now gone, llvm3.7 doesn't seem to show there any longer nor does ghc-bootstrap, both for x86_64 and armhf
2016-08-20 10:55:49 <jirutka> mitchty: llvm3.7 has been moved to the community repo
2016-08-20 10:56:15 <jirutka> mitchty: https://pkgs.alpinelinux.org/packages?name=llvm3.7&branch=&repo=&arch=&maintainer=
2016-08-20 10:56:30 <jirutka> mitchty: https://pkgs.alpinelinux.org/packages?name=ghc-bootstrap&branch=&repo=&arch=&maintainer=