2016-10-27 09:04:34 <ncopa> algitbot: hi
2016-10-27 09:04:52 <ncopa> \o/
2016-10-27 12:58:38 <ncopa> \o/
2016-10-27 13:00:54 <ncopa> vkris: the log issue was permissions
2016-10-27 13:01:11 <ncopa> i ran the script as root so the logfile was created as root
2016-10-27 14:31:26 <mikolaj9> hello
2016-10-27 14:42:15 <^7heo> moin
2016-10-27 14:46:08 <mikolaj9> is possible to ad package novnc ?
2016-10-27 14:46:44 <mikolaj9> vnc trought browser. I need this for gui software (for example firefox)
2016-10-27 14:52:34 <clandmeter> mikolaj9: why would you want it packaged?
2016-10-27 14:53:44 <clandmeter> its mostly javascript/html
2016-10-27 14:57:04 <mikolaj9> meybe yes
2016-10-27 14:57:04 <mikolaj9> i'm beginer
2016-10-27 14:57:04 <mikolaj9> I not know how
2016-10-27 15:07:29 <scadu> mikolaj9: you can base on Arch's PKGBUILD from AUR and make appropriate changes.  For more details regarding packaging on Alpine please visit our wiki: https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package
2016-10-27 15:07:42 <^7heo> mikolaj9: http://kanaka.github.io/noVNC/noVNC/vnc.html
2016-10-27 15:07:52 <^7heo> or you can point your browser there ^
2016-10-27 15:38:42 <kaniini> pkgconf-1.0.2 is out if someone could bump it.  https://distfiles.dereferenced.org/pkgconf/pkgconf-1.0.2.tar.xz
2016-10-27 15:39:58 <mikolaj9> kaniini: can You create novnc package?
2016-10-27 15:45:19 <^7heo> gosh, who let this chanel spill over to #alpine-linux?
2016-10-27 15:45:47 <^7heo> I would personally need a 'A' package, for every time I need to type the 'A' letter.
2016-10-27 15:45:51 <^7heo> thanks kaniini
2016-10-27 15:46:48 <nidan_> =)
2016-10-27 15:47:09 <mikolaj9> ok I undestuud
2016-10-27 15:47:43 <nidan_> sarcasm.ftw
2016-10-27 15:48:18 <nidan_> When I have $500k I'm going to reg .ftw. =) Unless someone beats me to it. =)
2016-10-27 15:52:23 <scadu> lul
2016-10-27 15:56:30 <^7heo> nidan_: someone DID beat me to it.
2016-10-27 15:56:36 <^7heo> I wanted systemd.org
2016-10-27 15:56:41 <^7heo> but yeah...
2016-10-27 15:57:04 <nidan_> Why, for making a clone of antisystemd?
2016-10-27 15:57:13 <^7heo> yeah
2016-10-27 15:57:16 <nidan_> =)
2016-10-27 15:57:29 <nidan_> Isn't .net/.com/.?? free?
2016-10-27 15:57:38 <nidan_> systemd.lol
2016-10-27 15:57:45 <nidan_> systemd.lulz
2016-10-27 15:57:56 <nidan_> systemd.nsfw
2016-10-27 15:58:00 <nidan_> =)
2016-10-27 15:58:17 <^7heo> systemd.fekt
2016-10-27 15:58:23 <scadu> let's move to -offtopic maybe.
2016-10-27 15:58:28 <nidan_> Hahahahah, literal lol!
2016-10-27 15:58:28 <^7heo> right
2016-10-27 15:58:34 <nidan_> sry
2016-10-27 16:00:35 <clandmeter> http://systemd.FAIL
2016-10-27 16:02:07 <^7heo> clandmeter: great ;)
2016-10-27 16:03:16 <^7heo> clandmeter: "¿Por qué systemd es una mierda?"
2016-10-27 16:03:53 <^7heo> clandmeter: literally means: "Why is systemd an excrement?"
2016-10-27 16:04:09 <nidan_> Haha, yeah, I read that too, lots of laughing today.
2016-10-27 16:04:45 <^7heo> nidan_: welcome to alpine :P
2016-10-27 16:04:51 <nidan_> =)
2016-10-27 16:12:41 <jirutka> ^7heo: ph crap, I totally forgot to systemd.org, it seems that someone was faster then us
2016-10-27 16:12:52 <jirutka> ^7heo: I hope that someone from anti-systemd camp and not the other one
2016-10-27 17:14:55 <^7heo> jirutka: yeeep
2016-10-27 18:20:10 <boingolov> so could I get anyone to review my cockroachdb PR?  https://github.com/alpinelinux/aports/pull/358
2016-10-27 18:20:39 <^7heo> boingolov: yeah, not me, sorry, I'm really swamped.
2016-10-27 18:20:43 <coredumb> boingolov: is that any usable ?
2016-10-27 18:21:14 <^7heo> clandmeter: s/any/of &/; s/able/e/
2016-10-27 18:21:15 <boingolov> coredumb: it's still beta, but it's actually pretty usable
2016-10-27 18:21:22 <coredumb> boingolov: ok
2016-10-27 18:21:42 <boingolov> I mean, probably not "replace all of your production databases with it"
2016-10-27 18:21:44 <^7heo> I would never trust Go to do anything close to what they pretend.
2016-10-27 18:21:46 <coredumb> I'm tinkering a bit with influxdb these days
2016-10-27 18:21:52 <^7heo> let alone a database in it.
2016-10-27 18:22:30 <boingolov> go has a lot of evangelists, and sometimes evangelists get carried away.  but I do think the language is overall pretty good
2016-10-27 18:24:29 <boingolov> and for the most part, the language something is written in doesn't really imply much about the software itself
2016-10-27 18:25:06 <^7heo> boingolov: http://yager.io/programming/go.html
2016-10-27 18:25:11 <boingolov> a lot of people badmouth java for instance but there is a lot of excellent open source software written in it
2016-10-27 18:25:14 <coredumb> well sorry but ruby does
2016-10-27 18:26:08 <boingolov> ^7heo: I've read that.
2016-10-27 18:26:08 <^7heo> boingolov: we do not have the same concept of "excellent" apparently.
2016-10-27 18:26:33 <boingolov> he brings up some good points
2016-10-27 18:26:40 <^7heo> The main problem with IT is that most IT people consider something good if "it crashes only less than half of the time"
2016-10-27 18:26:56 <jirutka> boingolov: I grow up on Java, have experience with many OSS projects written in Java and really can’t remember any that I can call “excellent”…
2016-10-27 18:27:05 <^7heo> jirutka: +1
2016-10-27 18:27:19 <boingolov> lucene in general
2016-10-27 18:27:25 <boingolov> elastic search in particular
2016-10-27 18:27:56 <^7heo> which is horrific.
2016-10-27 18:27:59 <boingolov> of course, logstash is kind of a companion bit of software and we've already discussed why that one is a pita
2016-10-27 18:28:07 <jirutka> language itself and especially its ecosystem has pretty big impact on software written in it
2016-10-27 18:28:26 <coredumb> then you learn that you're limited by the jvm to 32GB of ram allocation for your ES process
2016-10-27 18:28:55 <coredumb> logstash is worse ... java + ruby ... :O
2016-10-27 18:29:13 <coredumb> can something be worse ?
2016-10-27 18:29:31 <coredumb> still I like Go ^^
2016-10-27 18:29:45 <^7heo> https://github.com/ksimka/go-is-not-good
2016-10-27 18:29:47 <jirutka> yes, go and PHP are definitely worse ;)
2016-10-27 18:29:50 <^7heo> jirutka: did you star that? ^ :F
2016-10-27 18:29:53 <^7heo> s/F/D/
2016-10-27 18:30:09 <jirutka> ^7heo: of course :P
2016-10-27 18:30:13 <^7heo> yeah I agree that Go is worse than Java
2016-10-27 18:30:27 <^7heo> And that PHP is worse than Ruby
2016-10-27 18:30:46 <coredumb> hey folks if we go that way
2016-10-27 18:30:54 <coredumb> we should definitely include Docker
2016-10-27 18:30:57 <coredumb> \o/
2016-10-27 18:31:05 <boingolov> go lacks generics, so maybe in that way it's worth than java.  but I much prefer writing, and more importantly, reading, go
2016-10-27 18:31:23 <jirutka> boingolov: please move this to #alpine-offtopic
2016-10-27 18:31:30 <boingolov> it's easy to write code that you yourself understand in a given language.  it's another thing altogether to be able to quickly and easily decipher someone else's
2016-10-27 18:31:39 <coredumb> damn comparing Go and PHP ...
2016-10-27 18:31:53 <skarnet> oh, it's that conversation again! Hello my old friend, I haven't seen you in at least 2 days! Such a long time!
2016-10-27 18:31:58 <boingolov> lol
2016-10-27 18:32:13 <jirutka> boingolov: please, this is really #alpine-offtopic
2016-10-27 18:32:24 <coredumb> ahhhhh skarnet we were missing you :P
2016-10-27 18:32:25 <boingolov> jirutka: I have stopped talking about it
2016-10-27 18:32:29 <jirutka> ok
2016-10-27 18:32:38 <boingolov> I asked someone to review my PR initially
2016-10-27 18:32:51 <boingolov> and then in with the snarky comments on go
2016-10-27 18:33:20 <^7heo> http://dtrace.org/blogs/wesolows/2014/12/29/golang-is-trash/
2016-10-27 18:33:26 <^7heo> seems to be pretty on point.
2016-10-27 18:33:45 <coredumb> boingolov: yeah I agree it's ^7heo's fault :P
2016-10-27 18:36:58 <^7heo> wayt wat?
2016-10-27 18:37:42 <jirutka> boingolov: what PR?
2016-10-27 18:37:50 <^7heo> the db one
2016-10-27 18:37:54 <boingolov> cockroachdb
2016-10-27 18:37:56 <^7heo> the cockraochdb one
2016-10-27 18:39:55 <boingolov> https://github.com/alpinelinux/aports/pull/358
2016-10-27 18:40:49 <jirutka> boingolov: please take into account that there is A LOT of work that’s needed to be done, there are only few active members in Alpine team and only one is able and willing to review Go abuilds
2016-10-27 18:42:23 <jirutka> boingolov: and Go staff is generally quite hard to package correctly, because its ecosystem is total mess
2016-10-27 18:43:18 <coredumb> I disagree with that
2016-10-27 18:43:37 <coredumb> it's not the ecosystem, it's the app devs that are doing messy crap
2016-10-27 18:44:08 <coredumb> on projects were the devs are willing to do things correctly there's no issue
2016-10-27 18:44:24 <jirutka> boingolov: it’s connected
2016-10-27 18:44:33 <boingolov> cockroachdb uses a version manager and pins its dependencies to a point in time, so the builds should be repeatable
2016-10-27 18:44:38 <coredumb> it's just a bit too easy imho to blame it on the ecosystem
2016-10-27 18:45:11 <boingolov> that's a common issue with some go projects, but they do take steps to address it.  I am not a fan of their chosen dependency manager as it happens, but it works
2016-10-27 18:49:22 <boingolov> also, packaging go apps is comparatively easy, since they're usually (mostly) self-contained big fat binaries.  it's the building that can be tricky, and doing it consistently and repeatably.
2016-10-27 19:03:20 <jirutka> of course we are talking about building them, packiging just native binaries downloaded from somewhere is not acceptable
2016-10-27 19:04:41 <boingolov> I meant packaging the resulting binary is easy since in many cases it's one file
2016-10-27 19:05:48 <jirutka> packiging resulting files is always easy, it’s just a tar :P
2016-10-27 19:30:42 <mikolaj9> i have trouble with ping
2016-10-27 19:30:42 <mikolaj9> 21:28
2016-10-27 19:30:42 <mikolaj9> when i using ping as user i get ping: permission denied (are you root?)
2016-10-27 19:30:42 <mikolaj9> 21:29
2016-10-27 19:30:42 <mikolaj9> permision are ok lrwxrwxrwx    1 root     root            12 Oct 18 18:58 ping -> /bin/busybox
2016-10-27 19:30:57 <mikolaj9> where is trouble?
2016-10-27 19:31:16 <jirutka> mikolaj9: what version of Alpine do you have?
2016-10-27 19:32:30 <nmeum> mitchty: are you still working on the ghc aport? what's the current state of it?
2016-10-27 19:32:33 <mikolaj9> 3.4
2016-10-27 19:33:10 <mikolaj9> jirutka: RUN addgroup -g 1000 user \
2016-10-27 19:33:10 <mikolaj9>    && adduser -D -h /home/user -G user -u 1000 user
2016-10-27 19:33:39 <jirutka> mikolaj9: I don’t speak docker language, please write plain commands… ;)
2016-10-27 19:33:48 <mikolaj9> the trouble is 'su' too
2016-10-27 19:34:19 <mikolaj9> jirutka: ;-)
2016-10-27 19:34:20 <mikolaj9> addgroup -g 1000 user \
2016-10-27 19:34:20 <mikolaj9>    && adduser -D -h /home/user -G user -u 1000 user
2016-10-27 19:34:36 <mikolaj9> su user and ping
2016-10-27 19:34:37 <jirutka> hm, it doesn’t work even on edge
2016-10-27 19:34:55 <jirutka> IIRC ncopa fixed it somehow to allow unprivileged user to use ping
2016-10-27 19:35:41 <mikolaj9> 3.3 working?
2016-10-27 19:35:43 <jirutka> so it should work… but I don’t remember any details
2016-10-27 19:35:53 <mikolaj9> $ ping google.com
2016-10-27 19:35:53 <mikolaj9> PING google.com (172.217.20.142): 56 data bytes
2016-10-27 19:35:53 <mikolaj9> ping: permission denied (are you root?)
2016-10-27 19:36:47 <mikolaj9> and  … $ su -
2016-10-27 19:36:47 <mikolaj9> su: must be suid to work properly
2016-10-27 19:37:09 <mikolaj9> or tel me how creating a user
2016-10-27 19:37:14 <jirutka> IIRC this is due to some limitation in latest ping command, but I remember that ncopa solved it somehow
2016-10-27 19:37:35 <jirutka> whait, su doesn’t work for you?
2016-10-27 19:37:47 <mikolaj9> yes
2016-10-27 19:37:49 <jirutka> ^7heo: isn’t that the problem you’ve mentioned today?
2016-10-27 19:37:54 <mikolaj9> not working su
2016-10-27 19:37:57 <mikolaj9> too
2016-10-27 19:38:04 <jirutka> this is pretty bad
2016-10-27 19:38:18 <mikolaj9> send Dockerfile?
2016-10-27 19:38:41 <jirutka> mikolaj9: please open an issue http://bugs.alpinelinux.org/projects/alpine/issues/new
2016-10-27 19:39:20 <jirutka> and add output of cat /etc/alpine-release
2016-10-27 19:40:00 <mikolaj9> latest 3.4
2016-10-27 19:40:09 <jirutka> hm, there’s su both in /bin and /usr/bin
2016-10-27 19:40:19 <jirutka> lrwxrwxrwx    1 root     root            12 Mar 26  2016 /bin/su -> /bin/busybox
2016-10-27 19:40:23 <jirutka> lrwxrwxrwx    1 root     users           11 Oct 27 00:54 /usr/bin/su -> /bin/bbsuid
2016-10-27 19:40:34 <jirutka> ---s--x--x    1 root     root          9984 Oct 11 10:48 /bin/bbsuid
2016-10-27 19:40:47 <jirutka> what do you have on your system?
2016-10-27 19:42:06 <mikolaj9> $ cat /etc/alpine-release
2016-10-27 19:42:07 <mikolaj9> 3.4.4
2016-10-27 19:42:45 <mikolaj9> no I'm not have bbsuid
2016-10-27 19:42:49 <stwa> cat /etc/sysctl.d/00-alpine.conf
2016-10-27 19:42:52 <stwa> > net.ipv4.ping_group_range=999 59999
2016-10-27 19:43:06 <boingolov> don't docker images typically only have root / run as root?
2016-10-27 19:43:07 <mikolaj9> no /bin/bbsuid
2016-10-27 19:43:30 <jirutka> mikolaj9: like there’s no /bin/bbsuid at all?
2016-10-27 19:43:33 <boingolov> if so, they may skip bbsuid
2016-10-27 19:43:38 <jirutka> mikolaj9: do you have /usr/bin/su symlink?
2016-10-27 19:44:24 <boingolov> I have some alpine docker images here, no bbsuid at all
2016-10-27 19:44:42 <boingolov> and my no /usr/bin/su
2016-10-27 19:44:44 <mikolaj9> $ /usr/bin/su
2016-10-27 19:44:44 <jirutka> I would say that it’s a docker issue, if ^7heo haven’t talked me today that he had problem with suid on his machine
2016-10-27 19:44:45 <mikolaj9> /bin/sh: /usr/bin/su: not found
2016-10-27 19:45:06 <boingolov> on my alpine edge VM, it works fine
2016-10-27 19:45:17 <jirutka> even on mine
2016-10-27 19:45:32 <boingolov> and on my 3.4 vm it's fine
2016-10-27 19:45:46 <jirutka> a haven’t updated to 3.4.5 yet, but I have many instances with 3.4.4… but not installed from scratch, but updated from older versions
2016-10-27 19:45:50 <boingolov> well, not ping
2016-10-27 19:45:51 <boingolov> but su
2016-10-27 19:46:59 <Klowner_> after abuild -r completes, it tries to update the APKINDEX.tar.gz automatically right? does it also sign it with the PACKAGER_PRIVKEY or is that a manual step?
2016-10-27 19:47:05 <mikolaj9> here my info http://pastebin.com/raw/pBr1uZrM
2016-10-27 19:47:14 <boingolov> Klowner_: automatic
2016-10-27 19:47:32 <Klowner_> boingolov: kk thx
2016-10-27 19:49:29 <jirutka> Klowner_: yes, it update and sign inex automatically
2016-10-27 19:50:39 <stwa> mikolaj9: what is the output of grep ping /etc/group and echo $UID ?
2016-10-27 19:50:40 <jirutka> mikolaj9: well, this looks more like a docker problem; what docker image do you use?
2016-10-27 19:50:53 <jirutka> mikolaj9: hmm, actually, this solution for ping can’t work in docker
2016-10-27 19:51:05 <mikolaj9> ihave trouble on 3.3 too
2016-10-27 19:51:13 <jirutka> mikolaj9: however, it doesn’t work even on my VMs, so there’s really something wrong
2016-10-27 19:51:14 <boingolov> mikolaj9: are you using the gliderlabs image?
2016-10-27 19:51:23 <mikolaj9> http://pastebin.com/pzZ2V619
2016-10-27 19:51:55 <mikolaj9> ok i send my dockerfile
2016-10-27 19:56:21 <mikolaj9> boingolov: i send You my dockfile
2016-10-27 19:56:58 <boingolov> can you pastebin it?
2016-10-27 19:58:06 <mikolaj9> i send
2016-10-27 19:58:37 <mikolaj9> You get my pastebin?
2016-10-27 19:59:10 <mikolaj9> i'm using mac os
2016-10-27 19:59:28 <jirutka> this should not matter
2016-10-27 19:59:35 <boingolov> I don't get notifications for PMs
2016-10-27 19:59:37 <boingolov> in my client
2016-10-27 19:59:42 <boingolov> but I saw your docker file
2016-10-27 20:00:01 <mikolaj9> ok
2016-10-27 20:00:04 <jirutka> moreover docker does not run natively on OS X, but inside a virtual machine running some linux distro
2016-10-27 20:00:18 <boingolov> yeah, you're running docker-machine most likely
2016-10-27 20:00:30 <mikolaj9> jirutka: not yet, now natively
2016-10-27 20:00:49 <jirutka> you can’t run docker natively on non-linux system
2016-10-27 20:00:57 <mikolaj9> ersion 1.12.1 (build: 12133)
2016-10-27 20:01:13 <boingolov> actually I think Windows now supports native docker
2016-10-27 20:01:32 <jirutka> because the container part of docker is just setting namespaces and cgroups, both provided by linux kernel, non-portable to Darwin
2016-10-27 20:01:39 <jirutka> sigh, no
2016-10-27 20:01:51 <boingolov> but not macosx last I checked.  docker-machine spins up a coreos vm and then that holds the docker containers
2016-10-27 20:01:54 <jirutka> not in the same way like on linux
2016-10-27 20:02:49 <jirutka> they just managed to replace VirtualBox with native virtualization support in OS X and Windows
2016-10-27 20:03:20 <jirutka> utilizing Hypervisor.framework on OS X (since 10.10) and HyperV on Windows
2016-10-27 20:04:00 <jirutka> so you can virtualize linux kernel on it and then run docker on it
2016-10-27 20:04:48 <boingolov> you can actually ahve windows docker containers running on the windows kernel.  no linux kernel involved afaict
2016-10-27 20:05:11 <jirutka> no, you can’t, this is technically impossible
2016-10-27 20:05:36 <jirutka> Docker does *not* implement containterization technology
2016-10-27 20:05:54 <jirutka> it just utilizes features provided by Linux kernel (namespaces and cgroups)
2016-10-27 20:07:35 <boingolov> Before getting started, It’s important to understand that Windows Containers run Windows executables compiled for the Windows Server kernel and userland (either windowsservercore or nanoserver). To build and run Windows containers, a Windows system with container support is required.
2016-10-27 20:07:36 <jirutka> if you do this somehow natively on Windows, then it would be very different runtime and so the same docker image probably could not be run on both linux and windows host
2016-10-27 20:07:41 <boingolov> https://blog.docker.com/2016/09/build-your-first-docker-windows-server-container/
2016-10-27 20:08:02 <boingolov> jirutka: sure.  you cannot run linux images on a windows docker host
2016-10-27 20:08:23 <boingolov> not without a linux vm / kernel in the mix
2016-10-27 20:08:42 <boingolov> but that's what I'm telling you, as of pretty recently, Windows now has containerzation support built into their kernel, and docker has added support for it
2016-10-27 20:08:51 <jirutka> huh, they really implemented windows-specific containerization? o.O
2016-10-27 20:09:01 <jirutka> I didn’t know about this
2016-10-27 20:09:01 <boingolov> surprisingly, yes
2016-10-27 20:09:11 <boingolov> I would be surprised if it caught on
2016-10-27 20:09:14 <boingolov> in the windows world
2016-10-27 20:09:19 <jirutka> I’d like to know how secure it is… :)
2016-10-27 20:09:29 <boingolov> lol
2016-10-27 20:10:48 <jirutka> it took many years in linux to make it somehow secure and it’s still far from perfect
2016-10-27 20:11:08 <jirutka> and I’m talking about LXC and similar, Docker is much worse in security
2016-10-27 20:11:33 <boingolov> docker doesn't use LXC any longer, for better or worse
2016-10-27 20:11:37 <jirutka> I know
2016-10-27 20:12:08 <boingolov> it's a step up over chroot I guess
2016-10-27 20:12:20 <boingolov> certainly a lot easier to manage
2016-10-27 20:12:25 <jirutka> yes
2016-10-27 20:12:27 <boingolov> and more secure than chroot
2016-10-27 20:13:20 <boingolov> but I guess that's not a terribly high bar
2016-10-27 20:15:58 <mitchty> nmeum: yes, just swamped at work, i have updates I need to have tested in a branch on my sports repo that should fix the pic stuff for building ghc in the pr
2016-10-27 20:16:28 <mitchty> once the arbitrary deadline of nov 1 is over i should get some more time
2016-10-27 20:17:39 <mitchty> trust me I want it upstreamed too :)
2016-10-27 20:17:47 <mitchty> that way i can also submit my idris apk
2016-10-27 20:19:21 <mitchty> basically i just need to double check this https://github.com/mitchty/aports/commit/8dd9b9155a72991b7282813fe58a459fb99898c9 fixes the ghc pic stuff along with a bunch of other changes to the ghc apk build
2016-10-27 20:37:18 <tdtrask> was someone complaining about sudo being broken?
2016-10-27 20:37:25 <tdtrask> for some reason, I can't build packages now
2016-10-27 20:37:41 <tdtrask> ERROR: Unable to open root: No such file or directory
2016-10-27 21:08:11 <jirutka> tdtrask: wat? Unable to open root? o.O
2016-10-27 21:10:24 <Klowner_> seems not good
2016-10-27 21:15:45 <boingolov> I might skip updates for a minute then :)
2016-10-27 21:23:18 <jirutka> it’s very important to report it and provide some information so we can fix it
2016-10-27 21:23:29 <jirutka> if it’s a bug in 3.4.5, then it’s really very serious problem
2016-10-27 22:50:26 <tdtrask> jirutka: sorry, left at 5, now noticed your comment
2016-10-27 22:50:37 <tdtrask> this is on my build box running the latest from edge
2016-10-27 22:51:06 <tdtrask> I run abuild non-root, as required, but it seems to have a problem accessing the apk repo, which requires root
2016-10-27 22:51:29 <tdtrask> if noone else has seen this, it's possible my machine got messed up while working on current project
2016-10-27 22:51:38 <tdtrask> I can try again from a clean box tomorrow
2016-10-28 01:31:15 <Klowner> yay, my lil custom apk repo works
2016-10-28 01:31:34 <Klowner> auto-building in my private gitlab runners
2016-10-28 01:43:48 <Klowner> ^7heo: you still working on the mkinitfs test stuff?
2016-10-28 05:30:24 <scadu> jirutka: no issue with sudo on latest edge, however alpine-release shows 3.4.0 for some reason.
2016-10-28 06:03:17 <ncopa> re ping, stwa is correct: "net.ipv4.ping_group_range=999 59999" you need allow ping_group_range in kernel
2016-10-28 06:57:44 <ScrumpyJack> morning. Happy Friday!
2016-10-28 08:19:14 <^7heo> Klowner: yes
2016-10-28 11:48:07 <^7heo> Klowner: yes
2016-10-28 11:48:16 <^7heo> Klowner: slowly but surely.
2016-10-28 12:25:58 <nidan_> Who's up for some sh-explaining? =)
2016-10-28 12:26:15 <nidan_> http://pastebin.com/sbndx7yE
2016-10-28 12:26:34 <nidan_> Why doesn't the backgrounded cat quit when fd 3 is closed?
2016-10-28 12:28:19 <nidan_> Only thing I can think of is that fifo (named pipe) != pipe() (unnamed pipe). I thought they were the same, only that the FIFO had an entry in the filesystem.
2016-10-28 12:43:04 <skarnet> \o/ netsplits \o/
2016-10-28 12:48:31 <nidan_> Never mind, I wasn't thinking.
2016-10-28 13:30:50 <m5p3nc3r> Hi Guys - I am just trying to rebuild my alpine docker image for aarch64 using the docker mkimage-alpine script.  This was working earlier in the week, but today all of the packages are refusing to install with BAD signature errors.
2016-10-28 13:31:14 <m5p3nc3r> Is there something wrong with the metadata?  Or do I have a caching issue my end?
2016-10-28 13:33:04 <clandmeter> m5p3nc3r: probably due to libressl migration
2016-10-28 13:36:09 <m5p3nc3r> Is this a problem that will go away over time, or is there something fundamentally broken?
2016-10-28 13:54:41 <m5p3nc3r> In the short term, is there anything I can do to get apk to ignore the package signatures?
2016-10-28 13:54:42 <nidan_> http://pastebin.com/sVRR20Uw <- difference in time is due to new ldso resolving...
2016-10-28 13:56:29 <clandmeter> m5p3nc3r: yes run apk with --allow-untrusted
2016-10-28 13:56:52 <m5p3nc3r> That is what I am doing already and that is failing with the BAD signature error
2016-10-28 13:57:08 <clandmeter> then you are doing it wrong
2016-10-28 13:57:09 <m5p3nc3r> I have also tried with the -f option, but that does not work either
2016-10-28 13:57:28 <clandmeter> --allow-untrusted should not verify the signatures
2016-10-28 13:59:02 <m5p3nc3r> I assume it is down to driver error...
2016-10-28 13:59:41 <m5p3nc3r> I think the issue is that apk is still returning a non-zero code, which the mkimage-alpine script is picking up as an error.
2016-10-28 14:00:16 <m5p3nc3r> So, apk is installing the packages being asked for, but the script is ultimately reporting an error
2016-10-28 14:01:41 <nidan_> So, I've done some (pretty much) changes to mkinitfs; speedup, a number of bugfixes, broken out/separated data from code, clarification, support for new syntax in /etc/mkinitfs/features.d/*, maybe something more.
2016-10-28 14:02:24 <nidan_> Now, it works for me (tm), but before making a patch and sending to the mailing list it would be nice if someone else wanted to test it.
2016-10-28 14:02:29 <nidan_> Anyone interrested?
2016-10-28 14:03:23 <m5p3nc3r> adding apk <commands> || true fixes the problem for me for now.
2016-10-28 14:18:14 <ncopa> i will need some help
2016-10-28 14:18:31 <ncopa> i need help fixing the build issues we currently have
2016-10-28 14:19:15 <ncopa> those are the failing packages in main: http://tpaste.us/G5yX
2016-10-28 14:19:18 <nidan_> I haven't done any updates for a while, what's wrong?
2016-10-28 14:19:40 <ncopa> i will be afk most of the next week
2016-10-28 14:19:47 <ncopa> so i really depend on help this time :-/
2016-10-28 14:22:34 <ncopa> seems like things break due to new flex
2016-10-28 14:34:42 <skarnet> new flex? the C++ stroke of genius?
2016-10-28 14:35:54 <ncopa> i think this is what bits us: https://github.com/westes/flex/issues/113
2016-10-28 14:36:25 <ncopa> oh man... m4 quote fixes
2016-10-28 14:36:43 <skarnet> \o/ no major version bump when introducing incompatible changes \o/
2016-10-28 15:38:49 <nlf> hi, so i'm wondering, how hard would it be to build a custom rootfs based on alpine? do you folks have a process intended to do that?
2016-10-28 15:39:05 <nlf> basically i'd like to curate the installed packages, as well as add a few of my own init scripts
2016-10-28 19:53:53 <tdtrask> ncopa / jirutka / anyone else who saw my comments yesterday about "Unable to open root": Seems it was a problem on my box
2016-10-28 19:54:06 <tdtrask> 
ACTION reinstalled and the problem is gone

2016-10-28 19:54:13 <tdtrask> sorry for the false alarm
2016-10-28 21:42:54 <ncopa> curl: (22) The requested URL returned error: 402 Payment Required
2016-10-28 21:42:56 <ncopa> whatta
2016-10-28 21:43:26 <clandmeter> lol
2016-10-28 21:43:30 <clandmeter> bitcoins?
2016-10-28 21:44:24 <ncopa> aiccu
2016-10-28 21:44:29 <ncopa> is the package
2016-10-28 21:44:40 <ncopa> http://build.alpinelinux.org/buildlogs/build-3-5-x86/main/aiccu/aiccu-20070115-r3.log
2016-10-28 21:44:48 <ncopa> maybe we should move it to non-free?
2016-10-28 22:04:36 <tdtrask> never seen that response before :D
2016-10-28 22:05:13 <tdtrask> 
ACTION votes to say "see you" at aiccu

2016-10-28 22:05:48 <tdtrask> ay, I see ... see you
2016-10-28 22:07:44 <tdtrask> according to their website: "SixXS (Six Access) is a free, non-profit, non-cost service for Local Internet Registries (LIR's) and endusers."
2016-10-28 22:07:53 <tdtrask> but, payment required
2016-10-28 22:09:11 <tdtrask> I may be talking to myself, but at least I'm enjoying the conversation
2016-10-28 22:22:48 <skarnet> that's the only way to be sure
2016-10-28 22:23:06 <skarnet> also, "SixXS" reads more like "Six Excess" to me
2016-10-28 22:25:01 <skarnet> and I'm willing to bet the original meaning was "Sex Excess", i.e. IPv6 nerds' wishful thinking
2016-10-29 07:12:11 <nidan_> nlf: I have something called initlets, it's not released yet and is perhaps something along the lines of what you want to do. They're intended to make it easy to change the initramfs or replace the system's init. I'm in the process of cleaning it up, it'll take a few more days. If you'd like to check it out I can send a link your way next week.
2016-10-29 07:25:50 <skarnet> nidan_: I'm very interested :) but no hurry, please finish cleaning it up to your heart's content
2016-10-29 07:33:23 <nidan_> skarnet: np, cool to hear. =)
2016-10-29 07:56:10 <nidan_> I have an annoying error with gpg (on the initramfs) segfaulting in musl when entering the wrong password.
2016-10-29 07:56:49 <skarnet> ew, gpg on an initramfs.
2016-10-29 07:56:52 <nidan_> Not top priority to fix atm as it only happens when the wrong password is entered, in which case you won't boot anyway so..
2016-10-29 07:57:02 <nidan_> smartcard decrypted hdd.
2016-10-29 07:57:10 <nidan_> very nice. =)
2016-10-29 07:57:26 <skarnet> meh.
2016-10-29 07:57:56 <skarnet> when we have crypto that doesn't require a nuclear power plant to run, maybe.
2016-10-29 07:58:36 <nidan_> What aspect of crypto are you refering to?
2016-10-29 08:00:14 <skarnet> gpg. Don't you need half of the GNU ecosystem on the initramfs in order to make it work? Oh, you wouldn't know, because it's not working yet - you get a segfault in some cases. :P
2016-10-29 08:01:47 <nidan_> Haha, well, actually no, it doesn't depend on anything but its libs; assuan, gpg-error, maybe one or two more. gpg-agent and pinentry for password entry, scdaemon for smartcard.
2016-10-29 08:02:29 <nidan_> And it does work, the segfault when entering the wrong password happens inside musl so I'm not 100% that that is gpg doing something wrong, or musl doing something wrong.
2016-10-29 08:02:50 <skarnet> oh, only 2 to 4 libraries and 2 daemons! I guess it's perfectly fine then!
2016-10-29 08:04:59 <nidan_> I don't get it, would it make a difference if it would be one monolithic blob?
2016-10-29 08:05:12 <nidan_> Or do you think the code is bloated?
2016-10-29 08:05:31 <nidan_> It it the size requirements?
2016-10-29 08:06:32 <nidan_> libs are 185kB + libgcrypt which is huge, 1MB.
2016-10-29 08:06:48 <skarnet> there are several things. First, yes, the code is bloated, *obviously*. You can reasonably assume that when you get to the first 'g' in "gpg".
2016-10-29 08:07:03 <nidan_> Hahaha, made me lol, ok. =)
2016-10-29 08:07:14 <nidan_> True true
2016-10-29 08:07:33 <skarnet> Second, starting long-running processes in the initramfs is difficult to do right.
2016-10-29 08:07:57 <nidan_> You mean gpg-agent?
2016-10-29 08:08:08 <skarnet> gpg-agent and scdaemon.
2016-10-29 08:09:04 <skarnet> The thing is, when your real init starts, the system should be pristine, or as close as possible to it. If you run daemons in the initramfs, this is not the case.
2016-10-29 08:09:13 <nidan_> They live until the key material has been retrieved, I guess though that the time span itself is unimportant to your argument, you mean that by concept they're long running?
2016-10-29 08:09:24 <nidan_> Ofc.
2016-10-29 08:09:28 <nidan_> That's obvious.
2016-10-29 08:09:42 <skarnet> Do you kill them after you've used them?
2016-10-29 08:09:43 <nidan_> That's why they die the instant I have the key material.
2016-10-29 08:09:50 <nidan_> I'm not crazy.
2016-10-29 08:09:51 <nidan_> =)
2016-10-29 08:10:00 <nidan_> Yes, they're slaughtered.
2016-10-29 08:10:16 <nidan_> Everything is cleaned up.
2016-10-29 08:10:39 <nidan_> Only thing I ever cary over to the real init is (if one wants to) some environment, like TERM, PATH.
2016-10-29 08:10:41 <skarnet> What kind of person are you? Killing daemons after you have no more use for them? Using them then throwing them away? You sadistic, heartless bofh!
2016-10-29 08:10:45 <nidan_> But that's selectable.
2016-10-29 08:10:51 <nidan_> HAhaha
2016-10-29 08:11:08 <nidan_> As ^7heo said, this is a humorous place. =)
2016-10-29 08:11:13 <nidan_> I approve. =)
2016-10-29 08:11:27 <skarnet> ok, that's the only reasonable course of action. But it requires some careful management. You need to keep their pids, etc. etc.
2016-10-29 08:12:00 <skarnet> basically you're running a small system in the initramfs, then tearing it down and booting the real system afterwards.
2016-10-29 08:12:55 <skarnet> and "small" is a relative term.
2016-10-29 08:13:03 <nidan_> Yeah, I've thought about their pids; as of now, as I know I'm running prestine when booting, I don't care about their pids but kill all/any of them.
2016-10-29 08:13:34 <skarnet> yay for nuke buttons in an initramfs
2016-10-29 08:13:54 <nidan_> =)
2016-10-29 08:14:13 <nidan_> The rawcrypt initlet is the only one that starts anything long running.
2016-10-29 08:17:03 <skarnet> I think at this point we should treat initramfses as real, if ephemeral, systems, that spawn a complete hierarchy of stuff, with services and everything, and shut down when their job is done, only to exec into the full system.
2016-10-29 08:17:24 <skarnet> That would make nlplug-findfs less of a giant C hack.
2016-10-29 08:29:46 <nidan_> I've not really understood nlplug-findfs, what's the rationale behind it?
2016-10-29 08:30:16 <nidan_> It's like a recursive modprobe/check to see if the root device showed up right?
2016-10-29 08:32:42 <nidan_> mkinitfs takes 0.12 seconds now, PLUS the time it takes cpio to archive and pack it. 4.5 secs or so.
2016-10-29 08:42:56 <skarnet> nlplug-findfs is a way to find the correct rootfs no matter where it is and what it is (lvm, encrypted, remote device over carrier pigeons, etc.)
2016-10-29 08:51:56 <nidan_> On a general note, how does your work process look like when it comes to patching/updating alpine stuff? I have an aports checkout, do stuff in that dir, ... hm. Just thought about that it's git, I should probably branch my stuff.
2016-10-29 08:52:27 <nidan_> I run into trouble because I rsync stuff...
2016-10-29 08:52:30 <nidan_> Stupid.
2016-10-29 08:52:44 <nidan_> I need to learn to love git. Maybe watch Torvalds git-talk again.
2016-10-29 08:54:09 <nidan_> Ah, nice to do an apk upgrade of mkinitfs and only have to wait 4.5 secs on the mkinitfs trigger... =)
2016-10-29 09:07:22 <nidan_> Damn, I've happened to use find -empty to find empty dirs... Not posix and not supported by busybox, need to work around that.
2016-10-29 09:07:34 <nidan_> Out of time for today though. =/
2016-10-29 09:23:18 <dminca> 
ACTION says YO!

2016-10-29 15:19:49 <nlf> nidan_ yeah i'd be interested in taking a look at that
2016-10-30 08:38:55 <nidan_> Isn't it possible to force reinstalling a package? I can't get apk fix -f to work, played around with add and del too.. (Don't want to del -f, I think that will remove most of my system. Been there done that... =P )
2016-10-30 08:45:03 <nidan_> What does (1/1) [APK unavailable, skipped] Reinstalling mkinitfs (3.0.5-r6) mean? Add finds the package, the repos are setup, package is signed...
2016-10-30 08:45:50 <nidan_> (I added a 3.0.5-r6, did some changes to it and have not changed to -r7 since -r6 has never been released, in case you're wondering what I'm doing.)
2016-10-30 08:48:01 <nidan_> There, I modified /lib/apk/db/installed by hand, made apk shut up and do what I want. =)
2016-10-30 08:48:12 <nidan_> Probably not the recommended solution. =)
2016-10-30 11:38:26 <nidan_> Regarding kernel/mkinitfs, when the kernel is updated, imho it is undesirable to automatically remove the old kernel and the old initramfs, am I alone in that opinion?
2016-10-30 11:39:02 <nidan_> I'd like it to keep a configurable number of older kernels, normally one.
2016-10-30 11:39:27 <kaiyou> (sorry, copy/pasting from alpine-linux, just realized I was on the wronge channel)
2016-10-30 11:39:28 <kaiyou> I have been working for some weeks now on a single build file for dovecot and its modules, but I would like to push an upgrade to 2.2.26 to patchwork in the meantime
2016-10-30 11:39:35 <kaiyou> however, the build script uses '${pkgver%.*}' to extract '2.2' (part of the download URI) from 2.2.24, 2.2.25, etc. and for the first time, Dovecot released 2.2.26.0
2016-10-30 11:39:41 <kaiyou> what do you suggest, that I hardcode '2.2' in the download URI or use a more complexe pattern?
2016-10-30 11:39:53 <nidan_> kaiyou: Cut twice imho.
2016-10-30 11:40:10 <nidan_> kaiyou: More complex pattern, as you wrote.
2016-10-30 11:40:20 <kaiyou> and what if the next release is named 2.2.27?
2016-10-30 11:40:45 <nidan_> Either A) Handle it then
2016-10-30 11:40:56 <nidan_> or B) fix logic for testing it now.
2016-10-30 11:41:06 <nidan_> I don't think B is very easy though.
2016-10-30 11:41:26 <kaiyou> will try B for a couple minutes then probably fallback to A, thanks for the advice :)
2016-10-30 11:41:40 <nidan_> I don't think there is a way for the current download-parsing functionality to try different downloads in case one fails.
2016-10-30 11:41:57 <nidan_> np. =)
2016-10-30 11:52:40 <kaiyou> actually, the major version is already harcoded for pigeonhole download URIs, shouldn't I use a single underscored variable for this instead?
2016-10-30 11:53:51 <kaiyou> with something like _major=${pkgver%.*.*}
2016-10-30 11:54:15 <nidan_> Yeah, I just checked in the APKBUILD, that sounds reasonable.
2016-10-30 11:54:51 <nidan_> /2.2/ hardcoded in one place and extracted with %{_pkgver%.*} in one place isn't optimal.
2016-10-30 11:55:42 <nidan_> Replace those other hardcoded 2.2:s when you're at it.
2016-10-30 11:57:09 <kaiyou> thanks, I will and post to patchwork
2016-10-30 11:57:18 <nidan_> Great!
2016-10-30 11:59:38 <skarnet> echo $pkg_ver | { IFS=. read a b c d; _major=$a; _minor=$b; _thirdnumber=$c; _fourthnumnber=$d; }
2016-10-30 12:00:15 <skarnet> ah, damn, that won't work because _major and friends won't escape the subshell scope.
2016-10-30 12:00:51 <nidan_> In a pipe, thus subshell as you wrote, so yes, that won't work. =)
2016-10-30 12:00:55 <skarnet> fun with parameter expansion it is :/
2016-10-30 12:01:31 <nidan_> You can create a fifo, echo to the fifo in the background and then do { read ... } < fifo. ;)
2016-10-30 12:01:41 <nidan_> Overengineering ftw! =)
2016-10-30 12:04:38 <skarnet> but that would be the easiest way. It's when you consider things like this that you realize how badly designed the shell is. :/
2016-10-30 12:05:05 <nidan_> Yeah.. I want a new shell.
2016-10-30 12:05:15 <kaiyou> badly designed but tightly coupled with pretty much everything
2016-10-30 12:07:01 <nidan_> MHm.
2016-10-30 12:07:15 <nidan_> Very much organic growth there I think. =)
2016-10-30 12:08:16 <nidan_> Is there some block in apk that blocks trigger scripts from creating files?
2016-10-30 12:24:34 <kaiyou> just tested and pushed, thanks nidan_ for your help
2016-10-30 12:25:06 <nidan_> kaiyou: np, nice with more people helping out! =)
2016-10-30 13:01:14 <jirutka> nidan_: just add custom variable under the pkgver with hard-coded version, it’s imho not worth to overcomplicate it since the upstream apparently doesn’t follow any version format and just randomly add whatever they like that day
2016-10-30 13:01:30 <jirutka> eh, sorry, this is for kaiyou ^
2016-10-30 13:02:03 <jirutka> nidan_: thanks for that trick wih /lib/apk/db/installed, I had similar problem too and don’t know about any better workaround
2016-10-30 13:03:31 <skarnet> jirutka: don't blame dovecot, they're pretty good at following reasonable versioning.
2016-10-30 13:03:50 <skarnet> Switching to 4-number versioning is the smart thing. 3-number semver isn't enough.
2016-10-30 13:03:58 <nidan_> jirutka: np. Maybe we should add that to the wishlist for apk?
2016-10-30 13:04:16 <jirutka> skarnet: oh really? what the hell is reasonable with 2.2.25 → 2.2.26.0 ?
2016-10-30 13:04:35 <jirutka> nidan_: add what? support for random versioning schemas?
2016-10-30 13:04:58 <nidan_> jirutka: Sorry, unclear, no, I ment some way to actually force reinstall.
2016-10-30 13:05:04 <jirutka> skarnet: why 3-number semver isn’t enough? what the fourth part mean?
2016-10-30 13:05:13 <jirutka> nidan_: yeah, I totally agree
2016-10-30 13:05:49 <skarnet> 'I am clearly bumping 2.2.25 to 2.2.26 because of minor features, I would bump the middle "2" for API changes, and I would probably never bump the first "2". Time to add a 4th number for bugfixes release.'
2016-10-30 13:06:15 <jirutka> no, the third part is for bugfixes
2016-10-30 13:06:24 <skarnet> it's supposed to be.
2016-10-30 13:06:28 <skarnet> but it's not how people use it.
2016-10-30 13:06:31 <jirutka> minor is for new features
2016-10-30 13:06:43 <jirutka> major for backward incompatible changes
2016-10-30 13:06:45 <skarnet> yeah, yeah, you read your lesson pretty well.
2016-10-30 13:06:48 <jirutka> simple and clear
2016-10-30 13:06:52 <skarnet> you're a good schoolboy.
2016-10-30 13:07:02 <jirutka> I use it in that way and don’t see any problem with it
2016-10-30 13:07:06 <nidan_> skarnet: But, you have that first 2, the one that you wrote and I would probably never bump the first "2".
2016-10-30 13:07:17 <nidan_> Why not move everything "up" one level?
2016-10-30 13:07:53 <jirutka> ^ +1
2016-10-30 13:08:00 <skarnet> I have a rant somewhere about that. Let me find it.
2016-10-30 13:08:12 <nidan_> =)
2016-10-30 13:08:53 <nidan_> What happens with patches that are sent to the mailing list?
2016-10-30 13:09:23 <jirutka> nidan_: they appear in http://patchwork.alpinelinux.org/project/aports/list/
2016-10-30 13:09:45 <nidan_> I'd like to send those mkinitfs changes, but they're kind of major so it would probably not be so good to just include it in the mainstream stuff just yet.
2016-10-30 13:09:46 <jirutka> nidan_: if you want your patch to be merged sooner (and also automatically tested), then open pull request instead https://github.com/alpinelinux/aports
2016-10-30 13:10:05 <jirutka> nidan_: mkinitfs https://github.com/alpinelinux/mkinitfs
2016-10-30 13:10:46 <nidan_> Ok.
2016-10-30 13:11:09 <nidan_> I suck using git though, I've never been forced to learn.. =(
2016-10-30 13:11:53 <jirutka> nidan_: it’s not so hard, try https://www.codeschool.com/courses/git-real ;)
2016-10-30 13:12:23 <jirutka> nidan_: or https://try.github.io/levels/1/challenges/1
2016-10-30 13:12:42 <skarnet> jirutka: I can't find my rant, probably was posted on a private forum, but the gist of it is: the first number in semver, which is supposed to be the "major", is in practice used as a "lifetime" number, it hardly ever goes up. When it does, it signals a complete project rewrite more than a simple API change. "dovecot-2" is basically the current dovecot software, "dovecot-3" would be *significantly* different.
2016-10-30 13:13:01 <skarnet> And so, to signal an API change, people bump the "minor" number instead of the "major"
2016-10-30 13:13:01 <nidan_> jirutka: Thanks, I'll work through that so I don't make a fool of myself. =)
2016-10-30 13:13:23 <skarnet> and to signal new features, they bump "bugfix" instead of "minor"
2016-10-30 13:13:33 <skarnet> ... and there's no more room for real "bugfix"
2016-10-30 13:13:58 <jirutka> skarnet: this is just misunderstanding of semver…
2016-10-30 13:14:02 <skarnet> with a 4-number semver, you can have $lifetime.$major.$minor.$bugfix and everyone is happy
2016-10-30 13:14:07 <jirutka> skarnet: of course if you use it wrong, the result is wrong
2016-10-30 13:14:35 <jirutka> skarnet: I don’t see any reason for lifetime… with this mindset, you should probably rename the software instead of bumping lifetime
2016-10-30 13:14:46 <skarnet> well, do you prefer labelling practice wrong and yelling on top of your soapbox, or acknowledging existing practice and encouraging something that works?
2016-10-30 13:14:55 <nidan_> apache => apache2 ?
2016-10-30 13:15:15 <skarnet> including lifetime versions into the name of software is ugly as hell
2016-10-30 13:15:40 <jirutka> skarnet: well, to be honest, I’m not against 4-number semver, I’m just against changing versioning scheme in existing software
2016-10-30 13:15:41 <skarnet> jirutka: you don't see any reason for lifetime, maybe, but obviously people who write software on the long term do
2016-10-30 13:15:56 <skarnet> the need is there
2016-10-30 13:16:25 <jirutka> skarnet: I saw so incredibly stupid versioning schemes in existing software, that I really can’t accept this argument
2016-10-30 13:16:26 <skarnet> yeah, I agree that changing it in the middle is painful, but it's like any virginity, it's only painful once
2016-10-30 13:16:53 <skarnet> once you have 4-number semver, you're pretty much set, until the zeitgeist changes again (which I don't think it will)
2016-10-30 13:18:02 <skarnet> "some people defy logic, so I can't accept that you're telling me other people use and like logic"
2016-10-30 13:19:25 <jirutka> skarnet: hm, well, you’re right
2016-10-30 13:23:34 <nidan_> Well argued.
2016-10-30 13:58:12 <Gemsbok> Hey, got a quick question. I just finished writing a script that detects your GPU and picks appropriate drivers. I cannot decide whenever it's better to "append" the script to setup-xorg-base.in or create a seperate file.
2016-10-30 17:00:30 <skarnet> are you f*ing kidding me, abuild?
2016-10-30 17:00:42 <skarnet> >>> s6*: Script found. busybox added as a dependency for s6-2.4.0.0-r1.apk
2016-10-30 17:00:58 <skarnet> I wrote that script in execline, *precisely* to avoid adding a dependency
2016-10-30 17:01:17 <skarnet> and abuild thinks itself smarter than me
2016-10-30 17:02:06 <skarnet> Unless someone can tell me how to disable this *fast*, I'm going to find the relevant function in abuild and edit it with a chainsaw
2016-10-30 17:07:19 <skarnet> Ok, abuild tests for #!/bin/sh, which is reasonable. But it means it also check .post-install scripts and friends, which are stricto sensu not a part of the package, but package manager helpers.
2016-10-30 17:07:59 <skarnet> The dependency should not be added to the package, but to abuild... and abuild heavily depends on /bin/sh anyway.
2016-10-30 17:08:45 <skarnet> So, I question the usefulness of that whole block of code in the first place.
2016-10-30 17:09:02 <jirutka> skarnet: btw why s6-rc depends on execline (432 kiB) anway?
2016-10-30 17:09:20 <skarnet> because s6-rc-compile produces execline scripts.
2016-10-30 17:09:32 <jirutka> skarnet: your execline is half of the size of entire busybox…
2016-10-30 17:09:58 <skarnet> I'll partition it with a finer granularity when working on init.
2016-10-30 17:10:05 <jirutka> that would be great
2016-10-30 17:10:56 <jirutka> currently s6-rc pulls quite big dependencies
2016-10-30 17:11:11 <skarnet> I know. It's not finely partitioned right now.
2016-10-30 17:11:46 <jirutka> abuild’s autodetection can be turned off, but I’m afraid that you can disable only shebang detection and not also so libs detection
2016-10-30 17:11:56 <skarnet> Honestly, I care about CPU and RAM much more than disk space. I just don't pay attention to disk space as long as I use little RAM.
2016-10-30 17:12:18 <skarnet> So I'll have to do some more work to content you guys who care a lot about disk space.
2016-10-30 17:13:08 <jirutka> I don’t particularly care about disk space, but about program complexity that is correlated with disk space
2016-10-30 17:13:25 <skarnet> No, the problem here is that abuild's autodetection includes stuff in $install and $triggers, and adds a busybox dep if $install or $triggers contain a script.
2016-10-30 17:13:45 <jirutka> adds as a runtime dependency instead of build time?
2016-10-30 17:13:56 <skarnet> apparently.
2016-10-30 17:14:00 <jirutka> hm, but this is correct
2016-10-30 17:14:02 <skarnet> and this is not even build time
2016-10-30 17:14:04 <skarnet> this is install time
2016-10-30 17:14:17 <jirutka> because $install and $triggers scripts are run on the users machine, it’s not purely build time dependency
2016-10-30 17:14:18 <skarnet> busybox should be a dep for the _package manager_, which it is anyway
2016-10-30 17:14:54 <jirutka> so it’s not big deal, because you have busybox anyway
2016-10-30 17:14:56 <skarnet> yes, but it's not "s6" that depends on /bin/sh, it's apk
2016-10-30 17:15:02 <jirutka> yeah
2016-10-30 17:15:19 <skarnet> sure, in practice it doesn't change anything, but that dependency should not be added
2016-10-30 17:15:49 <jirutka> the question is how more correct handling of this can increase complexity and if it’s really worth it…
2016-10-30 17:16:10 <jirutka> adding special dependency type is not worth it, the result would be exactly the same
2016-10-30 17:16:21 <skarnet> more correct handling of this would be deletion of 12 lines of code in abuild.in
2016-10-30 17:16:30 <skarnet> which does not increase complexity :P
2016-10-30 17:16:38 <jirutka> this would break existing useful functionality
2016-10-30 17:16:59 <skarnet> no, it wouldn't
2016-10-30 17:17:07 <skarnet> this is a special case for $install and $triggers
2016-10-30 17:17:20 <skarnet> which is exactly the incorrect case
2016-10-30 17:17:42 <jirutka> what if install or trigger is not a /bin/sh script?
2016-10-30 17:17:55 <skarnet> the dependency isn't added
2016-10-30 17:18:17 <jirutka> could you send me a link to exact line in abuild.in?
2016-10-30 17:18:32 <skarnet> http://git.alpinelinux.org/cgit/abuild/tree/abuild.in#n842
2016-10-30 17:19:00 <jirutka> wut?
2016-10-30 17:19:12 <skarnet> I think the whole L842->L852 block of code is incorrect
2016-10-30 17:19:17 <jirutka> I quite don’t understand why is this here
2016-10-30 17:19:21 <jirutka> me too
2016-10-30 17:19:59 <jirutka> I thought that it handles shebangs in a generic way, but this is just a special case for $install + $triggers and /bin/sh, nothing more
2016-10-30 17:20:10 <skarnet> yes
2016-10-30 17:20:13 <jirutka> we should git blame and ask the author
2016-10-30 17:20:47 <skarnet> the comments at the top of the file say either ncopa or fabled :)
2016-10-30 17:21:34 <jirutka> let’s ask them
2016-10-30 17:22:04 <skarnet> just highlighted them :) (remind me to ping fabled when he's on)
2016-10-30 18:20:43 <bitmendicant> I see that py2-tkinter was recently changed to python2-tkinter on edge.  but other py-* modules still depend on py2-tkinter (e.g. py-matplotlib)
2016-10-30 18:21:23 <bitmendicant> or rather it was probably py-tkinter, right?
2016-10-30 18:27:28 <bitmendicant> let me try that again...  py2-tkinter was changed to python2-tkinder on edge, but py-matplotlib still depends on py2-tkinter.  are there plans to fix?  should the tkinter apk be renamed, or should the other apk dependencies be adjusted instead?
2016-10-30 18:27:40 <jirutka> ncopa: ^
2016-10-30 18:32:58 <bitmendicant> the relevant commit: http://git.alpinelinux.org/cgit/aports/commit/?id=ec356aebd5adedb9de23cbb54ff42a783fb835e7
2016-10-30 23:44:11 <dsabogal> jirutka: new release of neovim
2016-10-30 23:44:31 <jirutka> dsabogal: great! I’ll look at it later
2016-10-30 23:44:44 <jirutka> jirutka: I’d like to move neovim to the community repo very soon
2016-10-30 23:45:07 <jirutka> dsabogal: I’ve already moved most of the needed deps into community
2016-10-30 23:59:10 <skarnet> apparently with grsec the exported /proc is completely maimed :/
2016-10-30 23:59:21 <skarnet> there's not even a /proc/$pid/smaps
2016-10-30 23:59:40 <skarnet> so of course memstat fails :(
2016-10-31 00:01:29 <skarnet> I can't tell how much memory a process is using without memstat... VSZ and RSS are basically useless data points
2016-10-31 00:04:29 <dsabogal> jirutka: i saw, thanks.
2016-10-31 00:07:07 <skarnet> while I'm here: does anybody know if patchwork is still alive ? It has had a big queue of new packages for a few days and doesn't seem to be working on it
2016-10-31 00:19:05 <jirutka> skarnet: it is, but apparently nobody has time to check it; I’ve merged few patches from patchwork today, but I usually review and merge only pull requests on GH; patchwork is waste of time, there are no automatic tests to expose broken patches before trying them locally and doing a code-review on it is just PITA
2016-10-31 00:19:57 <jirutka> skarnet: also I don’t know how to close patch on patchwork when I merge it, but patchwork doesn’t detect it due to some minor modifications in the patch
2016-10-31 00:24:17 <jirutka> [01:19:22]  jirutka:	skarnet: it is, but apparently nobody has time to check it; I’ve merged few patches from patchwork today, but I usually review and merge only pull requests on GH; patchwork is waste of time, there are no automatic tests to expose broken patches before trying them locally and doing a code-review on it is just PITA
2016-10-31 00:24:17 <jirutka> [01:20:15]  jirutka:	skarnet: also I don’t know how to close patch on patchwork when I merge it, but patchwork doesn’t detect it due to some minor modifications in the patch
2016-10-31 00:26:09 <skarnet> jirutka: thanks. It's annoying, because I finally have a decent workflow that sends patches to alpine-aports, and I don't want to change it to use GH instead.
2016-10-31 00:27:46 <skarnet> What can I bribe you - or someone else - with to review the trivial series of patches to my name that were put in the patchwork queue 2 days ago?
2016-10-31 00:28:47 <jirutka> skarnet: I bet that it would require way less time for you to send patches via GH than for me to review and merge patches from that crappy patchwork
2016-10-31 00:28:50 <skarnet> I'm asking because I have another series on the way (mostly just as trivial, except one which has real work in it) and since the patches are diff'ed against my new aports git, I need the first series to be merged first.
2016-10-31 00:30:02 <jirutka> skarnet: you can also create just single PR with all of these patches
2016-10-31 00:30:14 <skarnet> Are there any command-line tools to automate PR creation?
2016-10-31 00:30:54 <skarnet> because if I have to go through the GH interface, this is a deal breaker - I can command-line and automate everything else
2016-10-31 00:31:42 <skarnet> (the GH interface is friendly, I'm not disputing that, but what I want to avoid is spending human time on it)
2016-10-31 00:31:51 <jirutka> skarnet: understand, give me a sec
2016-10-31 00:32:13 <skarnet> k, brb shower
2016-10-31 00:33:12 <jirutka> skarnet: I really hate to recommend you tool written in Go, but can’t find alternative with support for pull requests now; so https://hub.github.com/
2016-10-31 00:36:14 <jirutka> skarnet: this one is single purpose writtein in Python https://github.com/dataxu/github-pr
2016-10-31 00:37:07 <jirutka> skarnet: another single purpose written in Bash https://github.com/Idnan/github-pr
2016-10-31 00:49:14 <skarnet> I just had a look at the bash one
2016-10-31 00:49:27 <skarnet> Install
2016-10-31 00:49:27 <skarnet> You can install it either using cURL
2016-10-31 00:49:27 <skarnet> $ curl -L https://raw.githubusercontent.com/idnan/github-pr/master/installer.sh | sudo sh
2016-10-31 00:49:31 <skarnet> NEXT
2016-10-31 00:50:12 <skarnet> the python one suggest pip for installation
2016-10-31 00:50:13 <skarnet> NEXT
2016-10-31 00:50:35 <jirutka> pip is the right way to install python modules
2016-10-31 00:51:11 <skarnet> installing and learning to use all that shit is way more effort than I'm willing to provide
2016-10-31 00:51:29 <jirutka> but `| sudo sh`, I’ve overlooked that, he must be kidding
2016-10-31 00:51:43 <jirutka> skarnet: if you have Python 3 installed, then you already have pip
2016-10-31 00:51:43 <skarnet> just another curlbasher
2016-10-31 00:52:02 <jirutka> and `pip install foo` is not that hard… in comparison with manual installation of all dependencies
2016-10-31 00:52:15 <skarnet> I don't have Python 3 installed and I don't intend to have it, or Python 2, installed if I can avoid it
2016-10-31 00:52:23 <skarnet> and I very much hope that on Alpine I'll be able to avoid it
2016-10-31 00:52:25 <jirutka> ok
2016-10-31 00:53:04 <skarnet> the Go one:
2016-10-31 00:53:06 <skarnet> alias git=hub
2016-10-31 00:53:40 <skarnet> and why not 'alias sh="echo Go fuck yourself"'
2016-10-31 00:53:58 <jirutka> skarnet: you of course don’t want to download and install some random binary from the Internet and building go crap is much harder than installing python and pip
2016-10-31 00:54:24 <jirutka> that alias is not needed
2016-10-31 00:54:30 <jirutka> it’s just for convenience
2016-10-31 00:54:50 <skarnet> I'm willing to download and use a static binary from the Internet *if* the author wins my trust by showing they understand software development, administration and security
2016-10-31 00:55:10 <skarnet> so far the "hub" author hasn't been successful
2016-10-31 00:55:17 <jirutka> skarnet: ha ha, I don’t think that such authors exists
2016-10-31 00:56:06 <jirutka> definitely not in that rotten Go world
2016-10-31 00:57:30 <jirutka> well, I haven’t even tried to mention tools written in JavaScript, you would probably sent me to hell (and I would understand why)
2016-10-31 00:58:01 <skarnet> I'm not installing Node and npm in order to have fucking command line tools
2016-10-31 00:58:13 <jirutka> so it seems that the only option left is to write such tool yourself; that one written in Bash may be a good enough inspiration; basically it’s just about sending few HTTPS requests
2016-10-31 00:58:37 <jirutka> me neither, this is the last (desperate) option
2016-10-31 00:58:53 <skarnet> which brings us to my point: it will *definitely* be less work for you to merge my patches on patchwork than for me to send them via github. :)
2016-10-31 00:59:02 <skarnet> QED
2016-10-31 00:59:07 <jirutka> no, not in long-term
2016-10-31 00:59:31 <skarnet> I very much hope that longterm we can convince the bosses to make patchwork viable again
2016-10-31 00:59:43 <skarnet> because I *do not* want the workflow to rely on Github
2016-10-31 00:59:52 <skarnet> it's good to have it as an *option*
2016-10-31 00:59:57 <jirutka> then make patchwork to suck less
2016-10-31 01:00:16 <jirutka> currently it sucks, it’s waste of time for maintainers
2016-10-31 01:01:29 <skarnet> and GH is a waste of time for the authors with automation. I guess I'll study the bash script to see if it can be made to work, but I won't have time before a few days. :/
2016-10-31 01:02:09 <jirutka> this is just opposite, GH can be automated much better than patchwork
2016-10-31 01:02:31 <jirutka> I’ve tried it, patchwork API is just a joke
2016-10-31 01:02:52 <skarnet> then how come you were able to find exactly 3 tools, one of which is from a curlbasher and 2 of which require the kitchen sink, the garage and a nuclear power plant?
2016-10-31 01:03:13 <jirutka> you can find another tool yourself…
2016-10-31 01:03:19 <jirutka> I found few examples for you
2016-10-31 01:05:19 <skarnet> thanks for the effort. I'll see what can be done. I really didn't want to spend time on meta systems to merge a series of 3-lines patches -_-
2016-10-31 01:05:29 <jirutka> I can also say that I don’t want to manually test patches from patchwork, so you must find me some way how to automate it; it’s exactly the same situation ;)
2016-10-31 01:06:00 <skarnet> I thought there *was* an automated system
2016-10-31 01:06:10 <jirutka> no, there never was
2016-10-31 01:06:10 <skarnet> let me find what I got the previous times...
2016-10-31 01:06:34 <jirutka> or I can break my rule and merge them without testing them before; but you must promise me that all of them are correct and will not fail on the build server
2016-10-31 01:07:23 <skarnet> I can only promise that they're working for me
2016-10-31 01:07:32 <skarnet> I can't commit to anything else
2016-10-31 01:07:52 <jirutka> have you tested them on up-to-date Alpine edge?
2016-10-31 01:08:06 <skarnet> so the last time I got an automated mail from Patchwork, saying I had 6 patches moved from New to Accepted
2016-10-31 01:08:10 <skarnet> was that done manually?
2016-10-31 01:08:28 <skarnet> no, I have tested them on up-to-date Alpine 3.4, not edge.
2016-10-31 01:08:29 <jirutka> this is done when someone manually merge them into the repository
2016-10-31 01:08:49 <jirutka> all patches are merged to edge, so they must be tested on edge
2016-10-31 01:09:21 <skarnet> I have moved away from edge since edge made me waste TWO WEEKS in my customer's project because it would make my toolchain build fail for no reason.
2016-10-31 01:09:30 <skarnet> edge is unsuitable as a working platform.
2016-10-31 01:09:35 <jirutka> of course
2016-10-31 01:09:59 <skarnet> So, do I need a second machine just to test patches?
2016-10-31 01:10:01 <jirutka> but you can create some container just for creating packages
2016-10-31 01:10:08 <jirutka> or just chroot
2016-10-31 01:10:14 <jirutka> would be perfectly enough
2016-10-31 01:11:09 <skarnet> why do things have to be so hard?
2016-10-31 01:11:19 <skarnet> even with a distro that is supposed to do things right?
2016-10-31 01:11:33 <jirutka> because you’re doing it hard
2016-10-31 01:11:37 <jirutka> in this case
2016-10-31 01:13:08 <skarnet> I want to automate my workflow. This is not supposed to make my life hard, it's supposed to make it easier. If it makes my life hard, it's because we are lacking tools for automation, and *that* is what needs to be fixed, not my workflow. I did not expect you of all people to defend the dumbing down of developer workflow.
2016-10-31 01:13:24 <jirutka> instead of just creating PR using web interface, that would take about 10 seconds, you’re wasting our time with this discussion and want from me to waste me time with manual testing instead of testing it yourself or using GH to let it test automatically
2016-10-31 01:13:59 <jirutka> you’re kinda selfish, do you know?
2016-10-31 01:14:19 <skarnet> You are saying I should use a web interface, i.e. be physically in front of my screen and click things, when I want to run a script. Who are you, a systemd developer?
2016-10-31 01:14:53 <jirutka> no, I’m not saying that you should use it everytime, but if you want to let it merge quickly, this is the way
2016-10-31 01:15:24 <jirutka> I gave you several options how to automate it, you don’t like anyone of them because of your arbitrary criterias, that’s not my problem
2016-10-31 01:15:56 <skarnet> then I will wait, but if I have to wait until some overworked maintainer can find the time and generosity to look at the patchwork queue manually, then *that* is a problem and *that* should be fixed.
2016-10-31 01:16:29 <jirutka> so fix it
2016-10-31 01:16:49 <jirutka> I’ve fixed it several months ago for GitHub workflow (by setting up Travis CI)
2016-10-31 01:17:10 <skarnet> and I commend you for that
2016-10-31 01:17:16 <jirutka> I don’t have time to fix it even for patchwork that sucks for me on multiple levels, so it would not solve all the issues
2016-10-31 01:18:24 <jirutka> there’s a lot of work to done, we should release v3.5 in two weeks, and abuild tool is currently broken
2016-10-31 01:18:37 <skarnet> glad I'm not on edge then :P
2016-10-31 01:18:50 <jirutka> yeah, edge really should not be used for production
2016-10-31 01:19:01 <jirutka> especially not now
2016-10-31 01:19:20 <skarnet> if abuild is broken, I wonder what edge can even be used for XD
2016-10-31 01:19:50 <jirutka> nah, the problem is with current v3.5, edge should be okay, I hope
2016-10-31 01:20:24 <jirutka> and I need to finally finish my work and go sleep in some reasonable time
2016-10-31 01:20:32 <skarnet> "hey guys, we have a new release ready, everything works perfectly, *all* bugs fixed except one, /bin/sh randomly segfaults, we'll fix it later"
2016-10-31 01:20:44 <jirutka> nope
2016-10-31 01:21:09 <skarnet> go finish your work XD
2016-10-31 01:21:33 <jirutka> I’m just trying to tell you that we have much bigger and important problems than your workflow…
2016-10-31 01:22:24 <jirutka> this also reminds my that I should write that thesis topic for creating PRs on GH via email
2016-10-31 01:22:52 <jirutka> but such topic can probably accept only student that don’t know anything about emails, because mails are total mess
2016-10-31 01:23:23 <skarnet> thesis topic?
2016-10-31 01:23:30 <jirutka> yeah
2016-10-31 01:23:47 <skarnet> shouldn't it be more like a GSoC project oslt?
2016-10-31 01:24:08 <jirutka> I don’t have any experience with GSoC
2016-10-31 01:24:24 <skarnet> I mean, it sounds more like a 2-month project than a 3-year one
2016-10-31 01:24:31 <jirutka> but I work at university, so I can propose topics for thesis and lead students
2016-10-31 01:24:43 <jirutka> thesis are not 3-years projects
2016-10-31 01:24:49 <jirutka> more like half a year projects
2016-10-31 01:25:01 <skarnet> oh. not a PhD thesis then.
2016-10-31 01:25:06 <jirutka> no XD
2016-10-31 01:25:12 <jirutka> I mean bachelor and master thesis
2016-10-31 01:25:28 <jirutka> I cannot supervise PhD students, I don’t have PhD
2016-10-31 01:25:51 <skarnet> I can only supervise daemons
2016-10-31 01:26:04 <jirutka> :P
2016-10-31 01:26:14 <skarnet> that is very useful today!
2016-10-31 01:26:21 <jirutka> I know!
2016-10-31 01:28:40 <skarnet> but honestly I wouldn't give a bachelor/master student something involving both mail and security. If the student is good, they'll realize what a mess it is and will probably commit suicide and that will be a waste. If the student is not good, you'll end up with some more broken curlbash shit.
2016-10-31 01:29:26 <jirutka> EXACTLY!
2016-10-31 01:30:07 <jirutka> that’s why I hesitate if I should even try it
2016-10-31 01:31:23 <skarnet> if you can perform GH operations with purely asymmetric crypto then it's doable...
2016-10-31 01:31:43 <jirutka> now you should also see what’s wrong with this email-based approach of contributing patches…
2016-10-31 01:33:08 <skarnet> the security? there are ways to fix that (smtp/s, trusted senders)
2016-10-31 01:33:52 <skarnet> but I don't care if I have to send the patches via scp instead of e-mail, I'm not attached to e-mail (see what I did there?)
2016-10-31 01:34:37 <jirutka> XD
2016-10-31 01:34:39 <skarnet> I just want to write git format-patch -o /var/tmp/mypatches && send-stuff-to-alpine /var/tmp/mypatches
2016-10-31 01:34:49 <skarnet> idc how send-stuff-to-alpine is implemented
2016-10-31 01:35:31 <jirutka> what about using git just, e.g. git push -u upstream foo ?
2016-10-31 01:36:11 <skarnet> does that mean you'd give me push rights? Xmas is very early this year!
2016-10-31 01:36:16 <jirutka> I have an idea, the script that would automatically open a pull request when you push a new branch into your GH repository
2016-10-31 01:36:49 <jirutka> no, I’m not competent to give anyone a push rights
2016-10-31 01:37:24 <jirutka> (actually it can be any git repository, not just on GH)
2016-10-31 01:37:28 <skarnet> if someone gives me push rights, you're guaranteed to stop hearing me complaining, but there's also a chance you start hearing other people complaining :D
2016-10-31 01:38:11 <jirutka> yeah, that’s what I’m afraid of XD but this is out of question, I don’t have access to the infra servers, so cannot do that
2016-10-31 01:42:06 <jirutka> fuck that, now I can’t stop thinking about writing that script instead of finishing my work
2016-10-31 01:43:30 <skarnet> mission: accomplished
2016-10-31 01:44:01 <jirutka> ?
2016-10-31 01:44:42 <skarnet> I just pretended diverting you from your work was my entire plan from the start. ;)
2016-10-31 01:45:01 <jirutka> XD
2016-10-31 06:26:27 <fabled> jirutka, morning, you here?
2016-10-31 07:20:12 <coredumb> morning
2016-10-31 07:34:08 <clandmeter> good morning
2016-10-31 08:13:39 <ScrumpyJack> morning. Happy Monday!
2016-10-31 09:51:24 <_ikke_> hai
2016-10-31 10:13:20 <clandmeter> morge
2016-10-31 10:22:41 <_ikke_> :-)
2016-10-31 11:15:53 <jirutka> fabled: hi! I’ll be here in one hour, going to lunch now
2016-10-31 12:17:56 <jirutka> fabled: I’m back
2016-10-31 12:53:50 <fabled> jirutka, i got mail from ncopa about abuild issues you had with the new arch setting
2016-10-31 12:53:54 <fabled> what's the problem?
2016-10-31 12:55:12 <fabled> the intent of "arch" was changed slighty
2016-10-31 12:55:20 <fabled> well, in global scope you should set it as before
2016-10-31 12:55:40 <fabled> but in the split descriptor you need to use the "realized" arch
2016-10-31 12:55:46 <fabled> e.g. $CARCH
2016-10-31 12:56:20 <fabled> see gcc APKBUILD how cross-tool chain generates gcc for $CARCH, but libgcc for $CTARGET_ARCH
2016-10-31 13:14:21 <jirutka> fabled: the problem is that it’s very limited (you can’t set more arch for a subpkg) and not very conceptional
2016-10-31 13:14:30 <fabled> ?
2016-10-31 13:14:40 <fabled> my problem is
2016-10-31 13:15:00 <fabled> i need to know all subpkg arch from the main context of the file parsing
2016-10-31 13:15:05 <jirutka> fabled: I know
2016-10-31 13:15:28 <fabled> it's not "enable build for these archs"
2016-10-31 13:15:35 <fabled> it's "this package's arch will be X"
2016-10-31 13:15:56 <jirutka> fabled: more flexible approach would be e.g. define variable `arch_<splitfunc>` on top-level
2016-10-31 13:16:04 <jirutka> fabled: similar to depends_dev
2016-10-31 13:16:23 <fabled> we spoke about that with ncopa when designing the feature
2016-10-31 13:16:37 <fabled> and we ended up rejecting it due to requiring eval
2016-10-31 13:16:42 <fabled> and not really giving much benefit
2016-10-31 13:17:25 <jirutka> fabled: the main benefit is that you can define more architectures for a subpackage, that is needed for some packages
2016-10-31 13:17:31 <fabled> ?
2016-10-31 13:17:35 <fabled> it's not "enable"
2016-10-31 13:17:38 <fabled> it's define
2016-10-31 13:17:43 <jirutka> fabled: ?
2016-10-31 13:17:51 <fabled> you are never supposed to give muliple arches for subpkg
2016-10-31 13:18:00 <jirutka> fabled: that’s not true
2016-10-31 13:18:00 <fabled> you are supposed to tell what the arch will actually be
2016-10-31 13:18:17 <fabled> can you give an example?
2016-10-31 13:18:50 <fabled> the whole point of "overloading" subpackages split specifier was to avoid users of the mistake you are trying to do ;)
2016-10-31 13:19:20 <jirutka> fabled: for example multiversion packages like lua or python: base pkg is a metapackage that has arch="noarch", but the subpackages may not be noarch and also may not be available for arch="all", but just some arch
2016-10-31 13:20:08 <jirutka> fabled: another example is openblas… it has subpkg -ilp64 that is currently avaialble only for x86_64, but once upstream add support for aarch64, then it should be available for arch="x86_64 aarch64"
2016-10-31 13:20:26 <fabled> if subpkg is not available for package X, you need to leave it out from subpackages completely
2016-10-31 13:20:33 <fabled> arch X*
2016-10-31 13:20:55 <jirutka> fabled: and the biggest probelm right now is that this change breaks hundreds of packages and it’s really very problematic since we should release v3.5 in two weeks…
2016-10-31 13:21:07 <fabled> [ "$CARCH" == "x86_64" ] && subpackages="$subpackages $pkgname-x8664"
2016-10-31 13:21:29 <fabled> people have been misusing "arch" then
2016-10-31 13:21:35 <fabled> it was never supported in the split function
2016-10-31 13:21:42 <fabled> if it worked, it was just luck
2016-10-31 13:22:04 <fabled> how exactly it breaks things?
2016-10-31 13:22:11 <fabled> i tried to preserver backwards compatibility
2016-10-31 13:22:33 <fabled> that is, subpackage split function is allowed to overload things with arch=noarch
2016-10-31 13:22:39 <fabled> it gives a warning on it, though
2016-10-31 13:23:08 <jirutka> fabled: IIRC it fails the build when arch= is defined in split func
2016-10-31 13:23:17 <fabled> mmm
2016-10-31 13:23:19 <jirutka> fabled: but not sure now b/c there are more bugs
2016-10-31 13:23:30 <fabled> it allows changing it to noarch
2016-10-31 13:23:35 <jirutka> fabled: the biggest problem is that it ignores failed dependencies check
2016-10-31 13:23:35 <fabled> but not from noarch->$CBUILD
2016-10-31 13:23:53 <jirutka> fabled: but this is exactly what is used in most of the multilang pkgs
2016-10-31 13:24:10 <fabled> the above transform was never supported properly
2016-10-31 13:24:13 <jirutka> fabled: and it worked until now and no one told us that this should not be used in this way
2016-10-31 13:24:26 <fabled> i think it silently ignored arch
2016-10-31 13:24:28 <jirutka> fabled: and yet it’s used in all multilang pkgs…
2016-10-31 13:25:08 <fabled> that's a pity. :/
2016-10-31 13:25:17 <fabled> hum
2016-10-31 13:25:36 <fabled> the dependency thing should be fixed first. but i wonder what to do with the arch misusage then
2016-10-31 13:25:40 <fabled> let me check how it used to work
2016-10-31 13:25:45 <jirutka> fabled: yes; we shoud fix it, but IMHO it should be fixed after v3.5 is out, because now it’s blocking us
2016-10-31 13:26:26 <fabled> is the split func setting arch= or subpkgarch= ?
2016-10-31 13:26:52 <jirutka> fabled: I don’t even know that abuild support subpkgarch…
2016-10-31 13:26:56 <jirutka> fabled: so it’s arch=
2016-10-31 13:27:09 <fabled> oh, wrong file
2016-10-31 13:27:50 <fabled> oh yes
2016-10-31 13:27:53 <fabled> so
2016-10-31 13:27:56 <fabled> noarch was no-op
2016-10-31 13:28:01 <fabled> it was just written as $CARCH
2016-10-31 13:28:10 <fabled> so fundamentally you always got $CARCH
2016-10-31 13:28:19 <jirutka> fabled: actually it really exists in abuild (subpkgarch), but it’s not used in any APKBUILD, b/c probably no one know about it :/
2016-10-31 13:28:28 <fabled> i added subpkgarch
2016-10-31 13:28:41 <fabled> arch was not used to determine .apk arch
2016-10-31 13:28:46 <fabled> it was hardcoded to $CARCH
2016-10-31 13:28:57 <fabled> and noarch was equivalent of "all"
2016-10-31 13:29:06 <fabled> that's why it sort of worked
2016-10-31 13:30:03 <fabled> main pkg 'noarch' is not really valid if any of the subpkgs is platform dependant
2016-10-31 13:30:26 <fabled> i wonder if it makes to have main pkg 'noarch' and subpkg 'all'
2016-10-31 13:30:49 <fabled> but it was a bit of mess
2016-10-31 13:30:57 <fabled> we probably should have had two fields
2016-10-31 13:30:58 <jirutka> fabled: [14:21:27]  fabled: [ "$CARCH" == "x86_64" ] && subpackages="$subpackages $pkgname-x8664" … hm, you’re right, this is what I’ve used in openblas
2016-10-31 13:31:07 <fabled> we really need
2016-10-31 13:31:20 <fabled> build_arch to imply the list of arches / all where it builds
2016-10-31 13:31:32 <fabled> and then we need subpkg specific target arch
2016-10-31 13:32:29 <jirutka> fabled: I think that the former can be inferred from the latter
2016-10-31 13:32:39 <fabled> not necessarily
2016-10-31 13:32:47 <fabled> there's some rules implied
2016-10-31 13:32:52 <fabled> but they are fundamentally two different things
2016-10-31 13:33:10 <fabled> the trickyness comes with cross compiling
2016-10-31 13:33:26 <jirutka> fabled: uff, this really needs more time to discuss it, properly document and fix existing abuilds (A LOT of them)… I suggest to revert this change for now, release v3.5, and then return back to this
2016-10-31 13:34:29 <fabled> reverting only that might be non-trivial :/
2016-10-31 13:34:34 <jirutka> fabled: and the most important is to fix dependencies check, because now we have a lot of potentially incorrect packages in v3.5; it’s really a critical bug :(
2016-10-31 13:34:40 <fabled> yes
2016-10-31 13:34:56 <jirutka> fabled: how many pkgs uses this new cross-compile feature?
2016-10-31 13:35:03 <fabled> limited number
2016-10-31 13:35:21 <jirutka> fabled: maybe it would be less evil to revert to the previous version of abuild
2016-10-31 13:35:23 <fabled> what's the dependency isue?
2016-10-31 13:35:34 <fabled> hmm
2016-10-31 13:35:37 <jirutka> fabled: but IIRC there are also some important bug fixes :/
2016-10-31 13:35:38 <fabled> there's other nice fixes
2016-10-31 13:35:42 <fabled> yes
2016-10-31 13:35:52 <fabled> i think the earlier apkbuild had some of them cherry-picked
2016-10-31 13:36:04 <jirutka> fabled: for example here http://build.alpinelinux.org/buildlogs/build-3-5-armhf/community/firefox-esr/firefox-esr-45.4.0-r0.log
2016-10-31 13:36:18 <jirutka> fabled: “ERROR: unsatisfiable constraints” and yet it continue with build
2016-10-31 13:41:29 <fabled> hum
2016-10-31 13:41:36 <fabled> i think all the checks are proper
2016-10-31 13:41:53 <fabled> i wonder if it needs this: http://sprunge.us/HAKa
2016-10-31 13:45:48 <jirutka> fabled: of course that it needs it…
2016-10-31 13:45:53 <fabled> it should not
2016-10-31 13:45:58 <fabled> it's last line
2016-10-31 13:46:15 <jirutka> fabled: aha, pardon
2016-10-31 13:46:15 <fabled> function should return the result of last command
2016-10-31 13:46:28 <jirutka> fabled: you’re right, this is not needed since it’s the last line
2016-10-31 13:46:44 <jirutka> fabled: I’m doing 5 things at once now so I’m quite rash
2016-10-31 13:46:51 <fabled> same here... :)
2016-10-31 13:47:54 <fabled> thecode does:
2016-10-31 13:47:55 <fabled> 		deps "--quiet --simulate" || return 1
2016-10-31 13:47:55 <fabled> 		deps || return 1
2016-10-31 13:47:55 <fabled> 		return 0
2016-10-31 13:48:03 <fabled> in builddeps()
2016-10-31 13:48:31 <fabled> OH
2016-10-31 13:48:38 <jirutka> this is really weird
2016-10-31 13:48:42 <fabled> found it
2016-10-31 13:48:45 <jirutka> where?
2016-10-31 13:48:58 <fabled> http://sprunge.us/SIYb
2016-10-31 13:49:00 <fabled> the second hunk
2016-10-31 13:49:20 <fabled> i'll push that
2016-10-31 13:49:23 <jirutka> okay
2016-10-31 13:49:38 <jirutka> and please release patch version
2016-10-31 13:50:54 <fabled> pushed
2016-10-31 13:51:13 <fabled> seems to fix it
2016-10-31 13:51:18 <fabled> firefox-esr failed now with: http://build.alpinelinux.org/buildlogs/build-3-5-x86/community/firefox-esr/firefox-esr-45.4.0-r0.log
2016-10-31 13:54:10 <fabled> let me think about the arch issue
2016-10-31 13:54:15 <fabled> i'll either:
2016-10-31 13:54:18 <fabled> a) fix all packages
2016-10-31 13:54:26 <fabled> b) add more compatibility
2016-10-31 13:54:39 <fabled> c) (if all above fails) revert some of the checks
2016-10-31 13:55:00 <fabled> but i'd probably prefer a, since the existing apkbuilds have been broken in unspecified waybefore
2016-10-31 13:55:39 <fabled> i think the simplest solution is to just mass delete all arch setting in split functions and set package arch to something sensible
2016-10-31 13:55:49 <fabled> i can fix the mess by tomorrow
2016-10-31 13:59:58 <jirutka> fabled: okay
2016-10-31 14:00:31 <jbguerraz> Hello jirutka ! I've seen you're quite busy now, np!, just FYI I've finally updated https://github.com/alpinelinux/aports/pull/296/
2016-10-31 14:02:40 <jbguerraz> I'll add 2 sub-packages to it. Will start that *now*. Maybe better to review once sub-packages are added ? or maybe I should wait for that main package to be validated and then open a new PR in order to add the sub-packages ?
2016-10-31 15:15:54 <nidan_> Good afternoon.
2016-10-31 15:17:04 <nidan_> DrK.. nice.
2016-10-31 15:22:29 <nidan_> https://www.blackhat.com/docs/us-16/materials/us-16-Jang-Breaking-Address-Space-Layout-Randomization-KASLR-With-Intel-TSX-wp.pdf
2016-10-31 15:30:19 <jomat> 404 :(
2016-10-31 15:31:18 <nidan_> https://www.blackhat.com/docs/us-16/materials/us-16-Jang-Breaking-Kernel-Address-Space-Layout-Randomization-KASLR-With-Intel-TSX-wp.pdf
2016-10-31 15:31:25 <nidan_> Sorry, typed it wrong.
2016-10-31 15:36:02 <jomat> Thx! You wrote that link by heart? :-)
2016-10-31 15:38:43 <nidan_> Hehe, no, but I read it on another computer so I read on that screenf and typed it on this screen. =)
2016-10-31 15:40:10 <nidan_> https://github.com/sslab-gatech
2016-10-31 15:40:18 <nidan_> Nice video there.
2016-10-31 18:27:01 <Gemsbok> Hi
2016-10-31 18:29:57 <Gemsbok> I guess I could use some help with integrating one of my scripts with setup-xorg-base.in
2016-10-31 18:30:54 <Gemsbok> one sec, gonna re-log
2016-10-31 23:38:29 <skarnet> jirutka, fabled: your conversation from this afternoon reminds me of a question I had - I have a few packages creating doc subpackages. foobar has arch=whatever it's compiled for, and foobar-doc inherits the same arch, but foobar-doc should actually be noarch. It doesn't matter at all, but for aesthetics, I'd like to set foobar-doc noarch if possible.
2016-10-31 23:39:06 <skarnet> AIUI, fabled says it's currently impossible (i.e. if I try and it works, it will be a hack and is not supposed to be supported)
2016-10-31 23:39:24 <jirutka> skarnet: agree, this is intuitive… the problem is that it currently doesn’t work intuitively… I understand the reasons now, when fabled explained it to me, but still
2016-10-31 23:39:28 <skarnet> is my understanding correct?
2016-10-31 23:39:43 <jirutka> skarnet: yes, it is
2016-10-31 23:41:19 <skarnet> ok, so I'll abandon the idea for now, but it would be nice if it worked at some point in the future (next year I'll be available for some brainstorming about it)