2018-02-01 00:53:02 <Ceruleis[m]> Building an AMI, noticed that setting SWAP_SIZE and using `-s 0` doesn't actually prevent the swap partition being created. Had to hotpatch it out of setup-disk. Known bug?
2018-02-01 09:30:42 <Nebukadneza> hi there!
2018-02-01 10:14:21 <Nebukadneza> there’s a packages for bats, a shell testing framework, in community/bats. this project is abandoned, and succeeded by bats-core, a friendly(?) fork of it. as bats-core has quite some bugfixes that i need, i’d like to package it. however, bats-core doesn’t have any releases yet, so i’d need a git-version-package. first: if freezing on a commit, and noting in the version is that okay?
2018-02-01 10:16:23 <Nebukadneza> secondly, would you prefer an update to the current package, or a new package? — since it’s a fork, i’d have intuitively started a new package named bats-core.
2018-02-01 10:17:34 <Nebukadneza> if doing so, the question is how to tag the package? provides="bats" is not quite right, and i don’t see conflicts= (which is used by some packages) in dhe apkbuild docs … then there’s replaces, which seems to be made for moving file-owning between packages, so also not quite right
2018-02-01 10:17:36 <Nebukadneza> what’s the most alpine-y way to solve this, if going that route?
2018-02-01 10:38:56 <hs3dUBwdmCjy> you have to make a snapshot and host it somewhere, i think the alpine infra has a storage for that, but i have no details.
2018-02-01 10:39:32 <Nebukadneza> the snapshot can even be served by github
2018-02-01 10:40:09 <Nebukadneza> something like https://github.com/bats-core/bats-core/archive/b1da565f92ad9dabf66831d0877542dcacc735b8.zip
2018-02-01 10:43:21 <Nebukadneza> the more interesting question is whether creating a new package for this is the right way — and if so, how to properly handle the conflicting relation between the 2 packages
2018-02-01 10:49:33 <hs3dUBwdmCjy> i think there is a !replaces or so tag for dependencies
2018-02-01 10:51:36 <Nebukadneza> yes, but the documentation says: »This package will "take over" files owned by packages listed in the replaces variable« … which is not quite what’s the case here
2018-02-01 10:52:23 <Nebukadneza> i mean, most of bats-core has the same filenames/paths as bats, but it should simply not be possible to have both installed at the same time — not having both, with bats-core masquerading the files of bats(?)
2018-02-01 10:58:11 <Shiz> that's not what it means
2018-02-01 10:58:44 <Nebukadneza> mh, then i misread the meaning of that field, sorry
2018-02-01 10:59:29 <Shiz> sorry, i can't really help you further right now as my headache is killing me, hopefully someone else can soon
2018-02-01 10:59:54 <Nebukadneza> ah, a good example might be kodi that replaces="xbmc"
2018-02-01 10:59:55 <Nebukadneza> oh, do get well! please don’t strain yoursel :/
2018-02-01 11:01:03 <Nebukadneza> in any case thanks :-)
2018-02-01 13:48:36 <HRio> Nebukadneza: I guess bats-core continued exacly where bats it self ended, why not change upstream on the current bats package then, instead of creating a new one?
2018-02-01 13:49:45 <Nebukadneza> HRio: that was my question exactly, i’m not sure myself :-)
2018-02-01 13:49:46 <Nebukadneza> would everyone be okay with updating current bats from a release-version to a git-snapshot, i wonder?
2018-02-01 13:50:16 <HRio> Nebukadneza: it seems only three packages in aports declare bats as checkdepends (and two of them are maintained by me).
2018-02-01 13:51:08 <Nebukadneza> HRio: then this boils down to: are YOU fine with a git snapshot? :-)
2018-02-01 13:51:17 <HRio> the third package is maintained by jirutka
2018-02-01 13:51:57 <Nebukadneza> i can try to build these with the current snapshot …
2018-02-01 13:51:58 <HRio> if you prepare a PR I can test my packages against that PR and comment in it :-)
2018-02-01 13:52:06 <HRio> thanks
2018-02-01 13:52:20 <Nebukadneza> sure, will do then, gimme 10 minutes :-)
2018-02-01 13:53:08 <HRio> then I guess its also up to ncopa, if he is fine with a package built from a snapshot in community
2018-02-01 13:53:12 <Nebukadneza> btw, how do you feel about ncurses as a dependency? i think having tput available really makes bats behave nicer
2018-02-01 13:53:35 <HRio> does it work in travis with ncurses?
2018-02-01 13:53:54 <Nebukadneza> well, it only uses tput from ncurses
2018-02-01 13:54:04 <Nebukadneza> for some initialization magic
2018-02-01 13:54:13 <Nebukadneza> if it detects a non-interactive terminal, not difference is seen
2018-02-01 13:54:24 <Nebukadneza> so jenkins, travis, etc just stay working
2018-02-01 13:55:23 <HRio> https://git.alpinelinux.org/cgit/aports/tree/community/bats/0001-test-bats-Add-fake-tput-to-fix-Alpine-tests.patch
2018-02-01 13:55:45 <Nebukadneza> yes, that’s pretty much included now, we can get rid of that patch
2018-02-01 13:56:47 <HRio> OK
2018-02-01 13:57:20 <HRio> for me ncurses does not matter as its just a checkdepend, that also pulls bash :-)
2018-02-01 14:03:41 <Nebukadneza> HRio: https://github.com/alpinelinux/aports/pull/3182 here it is …
2018-02-01 14:03:44 <Nebukadneza> i hope you’re fine with this …
2018-02-01 14:03:54 <Nebukadneza> please poke me if i fucked up anything ^_^
2018-02-01 14:07:17 <ncopa> Nebukadneza: have you reported it upstream?
2018-02-01 14:07:28 <ncopa> you can file a bug upstream "please tag a new release"
2018-02-01 14:08:33 <Nebukadneza> agreed, that’s probably a good idea too
2018-02-01 14:09:20 <Nebukadneza> oh bummer https://github.com/bats-core/bats-core/issues/16
2018-02-01 14:10:22 <ncopa> TL;DR
2018-02-01 14:10:51 <Nebukadneza> TL;DR, they’re a bit too relaxed about it
2018-02-01 14:10:57 <Nebukadneza> i’m going to poke into this
2018-02-01 14:11:21 <ncopa> thank you!
2018-02-01 14:12:04 <Nebukadneza> ✔
2018-02-01 14:13:21 <Nebukadneza> would you prefer waiting in this case? cough since i need it, i’d really like to have a snapshot-version somewhat soon~ish
2018-02-01 14:13:30 <HRio> etckeeper and apt-dater-hosts, works fine with new bats, and also this PR https://github.com/DE-IBH/apt-dater-host/pull/24
2018-02-01 14:15:00 <Nebukadneza> thanks for testing, you were a bit quicker than me :-)
2018-02-01 14:19:29 <HRio> also git-secret from jirutka has !check
2018-02-01 14:19:50 <HRio> so it will pass with new bats ;-)
2018-02-01 14:21:03 <HRio> the reason they are disabled are that some of the tests are interactive
2018-02-01 14:22:34 <Nebukadneza> yay
2018-02-01 14:25:54 <HRio> ncopa: we have kind of the same situation with colormake, but that is stuck in testing due to no tags (or changes) from upstream. What do you think can we move it to community now? We are using it in a CI/CD setup without noticible issues.
2018-02-01 14:29:14 <ncopa> HRio: if we ship a git snapshot, then we are basically taking the responsability of making the release. I want upstream to do that for us
2018-02-01 14:29:24 <HRio> and would like to avoid @edge http://url.../edge/testing in /etc/apk/repositories as there are warnings from apk due to this... and warnings shall trigger "stuff"
2018-02-01 14:29:33 <ncopa> if its working, why are upstream not tagging a release?
2018-02-01 14:29:47 <HRio> upstream does not seem to do anything on github...
2018-02-01 14:30:03 <HRio> https://github.com/pagekite
2018-02-01 14:30:14 <Nebukadneza> are we talking colormake or bats now?
2018-02-01 14:30:17 <ncopa> they probably dont want support it?
2018-02-01 14:30:58 <ncopa> my thinking is: if <any upstream> does not want make release, the may have a reason for it
2018-02-01 14:30:59 <ncopa> they dont want support the code at current stage
2018-02-01 14:31:33 <HRio> they have 18 repostiries all stale
2018-02-01 14:31:36 <ncopa> if we make a release for them, we end up taking the support too
2018-02-01 14:32:01 <Nebukadneza> mhh
2018-02-01 14:32:07 <ncopa> sounds like upstream is dead?
2018-02-01 14:32:08 <HRio> ok
2018-02-01 14:32:32 <ncopa> do we want support it?
2018-02-01 14:32:47 <ncopa> what im trying to say is, i want be careful
2018-02-01 14:33:41 <HRio> mm, its kind of "feature" complete... but the compilers are a bit of a moving target.
2018-02-01 14:33:46 <HRio> ;-)
2018-02-01 14:33:57 <ncopa> if you are ok to maintain it for upstream, then great! if not, then we should be careful
2018-02-01 14:35:22 <HRio> I will think about it. its not that much code https://github.com/pagekite/Colormake/blob/master/colormake.pl, but its perl ;-(
2018-02-01 14:38:12 <Nebukadneza> quite readable for perl though :-)
2018-02-01 14:38:55 <HRio> ;-) and the best thing is that it works :-)
2018-02-01 14:41:46 <danieli> nothing short of 2 miracles
2018-02-01 14:41:48 <danieli> can i get an amen
2018-02-01 14:48:54 <HRio> ncopa: last time we discussed colormake I opened this https://github.com/pagekite/Colormake/issues/22
2018-02-01 14:49:04 <Nebukadneza> so, ncopa … you’d prefer to wait for an upstream release in the case of bats-core?
2018-02-01 15:14:34 <danieli> jirutka: bah, I was considering going to FOSDEM with a belgian friend, but I'll be busy :(
2018-02-01 15:19:09 <ncopa> looking at kernel config
2018-02-01 15:19:18 <ncopa> CONFIG_BPF_SYSCALL=y is only set on s390x
2018-02-01 15:19:28 <ncopa> do we want that on x86_64 too?
2018-02-01 15:19:49 <fabled> i thought grsec disabled that
2018-02-01 15:20:04 <ncopa> aha
2018-02-01 15:20:10 <ncopa> that is possible
2018-02-01 15:20:18 <ncopa> due to its risky?
2018-02-01 15:21:24 <fabled> or maybe it was just BPF JIT
2018-02-01 15:23:20 <ncopa> new kernel got a new knob CONFIG_BPF_JIT_ALWAYS_ON
2018-02-01 15:25:07 <przemoc> https://www.spinics.net/lists/netdev/msg476553.html
2018-02-01 15:25:31 <ncopa> which depends on BPF_SYSCALL
2018-02-01 15:25:31 <ncopa> so it only showed up on s390x
2018-02-01 15:25:34 <ncopa> yes
2018-02-01 15:25:51 <ncopa> thats why i ask about BPF_SYSCALL
2018-02-01 15:26:10 <przemoc> BPF is quite useful on its own for diagnosing problems, performance issues
2018-02-01 15:26:26 <ncopa> i think we should either disable BPF_SYSCALL on s390x or we should enable it on the other arches
2018-02-01 15:29:56 <przemoc> personally I prefer to have more available tools to diagnose problems, so it would be nice to have it everywhere.
2018-02-01 15:31:16 <przemoc> but if there are good reasons against having it, then well, s390x will need to have it disabled too
2018-02-01 15:32:01 <ncopa> something else is enabling it on s390x
2018-02-01 15:32:05 <ncopa> ok its lunch.. bbl
2018-02-01 16:13:54 <ncopa> hum
2018-02-01 16:14:04 <ncopa> ok so what do i write in commit message for enabling BPF_SYSCALL?
2018-02-01 16:14:13 <ncopa> "may be nice to have"?
2018-02-01 16:14:26 <danieli> -m "¯\_(ツ)_/¯@
2018-02-01 16:14:27 <ncopa> we need better reason than that
2018-02-01 16:14:30 <danieli> damn keyboard
2018-02-01 16:14:35 <danieli> s/@/"/
2018-02-01 16:15:37 <ncopa> i guess we wait with enable BPF_SYSCALL til there is a specific need/request for it
2018-02-01 16:15:40 <ncopa> we do have a request for AUDIT though
2018-02-01 16:15:43 <ncopa> https://bugs.alpinelinux.org/issues/8401
2018-02-01 16:23:39 <ncopa> ok its AF_KCM that pulls in BPF_SYSCALL
2018-02-01 16:23:46 <ncopa> its set to 'm' on s390x
2018-02-01 16:23:54 <ncopa> nobody cared about it on x86_64 apparently
2018-02-01 16:26:24 <ncopa> kernel connection multiplexor
2018-02-01 17:57:02 <kaniini> hi, what is the best way to get access to a ppc64le alpine box right now
2018-02-01 18:14:45 <ncopa> kaniini: is a lxc container enough?
2018-02-01 18:16:46 <kaniini> yes
2018-02-01 18:16:58 <kaniini> i have ppc64(be) but not ppc64le right now
2018-02-01 18:17:11 <kaniini> in theory same code works for either, but never know ;)
2018-02-01 18:32:23 <ncopa> ok i'll set a container up for you
2018-02-01 19:12:46 <clandmeter> I enabled new issue announcement from redmine in this channel. Any issue with the format let me know.
2018-02-01 19:13:44 <ncopa> great!
2018-02-01 19:13:47 <ncopa> thanks!
2018-02-01 19:15:08 <clandmeter> i guess only new issue announcements are of interest. else it could get a bit too verbose.
2018-02-01 19:16:00 <clandmeter> Natanael Copa: there is currently no limit on project, so if we have private projects, that could be an issue.
2018-02-01 19:18:42 <clandmeter> heh, color filter
2018-02-01 19:20:07 <danieli> clandmeter: did you add that issue just to test?
2018-02-01 19:20:46 <clandmeter> yes, and i will close it as fixed :)
2018-02-01 19:20:49 <ncopa> \o/
2018-02-01 19:37:14 <AWilcox[m]> I can vouch for the validity of https://github.com/alpinelinux/aports/pull/3151 fwiw, that was originally a PR to Adelie and I redirected them to submit it to Alpine instead once I verified it fixed the issue
2018-02-01 19:41:05 <Aerdan[m]> https://github.com/alpinelinux/aports/pull/3141 needs applying ASAP, since tf won't run as-is. (mea culpa.)
2018-02-01 20:28:49 <ncopa> kaniini: do you know where we are on the kernel 4.14 upgrade?
2018-02-01 20:28:57 <ncopa> what is needed for us to switch to vanilla in the 3.7-stable?
2018-02-01 20:33:58 <kaniini> ipt-netflow and dahdi-linux are still missing
2018-02-01 20:36:09 <kaniini> i believe i can sort ipt-netflow, but i need help on dahdi
2018-02-01 20:41:11 <kaniini> i think in reality
2018-02-01 20:56:32 <kaniini> i took care of both ipt-netflow/dahdi-linux
2018-02-01 20:57:47 <ncopa> good! thanks!
2018-02-01 20:58:10 <kaniini> oh
2018-02-01 20:58:13 <kaniini> virtualbox
2018-02-01 21:00:04 <ncopa> isnt virtualbox in testing?
2018-02-01 21:00:22 <ncopa> i think i have some virtualbox work in some branch that i never finished
2018-02-01 21:00:35 <kaniini> virtualbox-guest-modules is in community
2018-02-01 21:00:44 <ncopa> ok
2018-02-01 21:00:59 <ncopa> needs fix then
2018-02-01 21:01:01 <ncopa> let me find the commit i have
2018-02-01 21:02:39 <kaniini> took care of that
2018-02-01 21:02:58 <ncopa> ok
2018-02-01 21:03:14 <ncopa> looks like we have a virtualbox-guest-additions in testing too
2018-02-01 21:12:03 <kaniini> i'm inclined to just leave that alone
2018-02-01 21:13:02 <kaniini> ok
2018-02-01 21:13:16 <kaniini> next step is to annotate the vanilla packages with provides=
2018-02-01 21:13:32 <kaniini> this will force apk to upgrade to vanilla 4.14 from hardened 4.9
2018-02-01 21:13:49 <kaniini> i think we should let that sit over the weekend
2018-02-01 21:14:01 <kaniini> see if there is any troubles
2018-02-01 21:14:14 <kaniini> if all is good, then we backport it all to 3.7
2018-02-01 21:14:29 <ncopa> there are definitively problems
2018-02-01 21:14:36 <ncopa> bootloader configs
2018-02-01 21:14:43 <ncopa> custom boot loaders
2018-02-01 21:14:47 <ncopa> xen
2018-02-01 21:14:56 <ncopa> iso image generation scripts
2018-02-01 21:15:02 <kaniini> indeed
2018-02-01 21:15:17 <ncopa> probably more unforseen
2018-02-01 21:15:33 <kaniini> so in that case i think we need to consider how to move forward with the migration
2018-02-01 21:15:34 <HRio> sec fixes info was missed in this merge https://git.alpinelinux.org/cgit/aports/commit/?id=580f3ad70a6283a31bc29856820355ffbebea61b, it was here however https://github.com/alpinelinux/aports/pull/3144/files
2018-02-01 21:16:25 <kaniini> from apk side, to do the migration it is just a matter of rebuilding the packages with the proper annotations
2018-02-01 21:16:31 <kaniini> linux-grsec -> linux-hardened as requested by spender was not too bad
2018-02-01 21:16:48 <kaniini> but this is removing an entire profile, so more things will be affected
2018-02-01 21:19:58 <kaniini> so at this point, all of the modules we care about
2018-02-01 21:20:31 <kaniini> are available on -vanilla
2018-02-01 21:20:43 <ncopa> good. very good
2018-02-01 21:20:53 <kaniini> so it's literally just rebuild with the annotations now
2018-02-01 21:20:54 <kaniini> but i am not sure if we want to do this yet
2018-02-01 21:21:30 <HRio> fabled: can you add the secfixes info for the clamav update?
2018-02-01 21:22:27 <fabled> HRio, didn't see the github one. my bad.
2018-02-01 21:22:55 <kaniini> ncopa, since you're the one maintaining linux-hardened kernel on paper, i think i leave that decision to you :)
2018-02-01 21:23:11 <HRio> :-) yes there are a few t-security on github
2018-02-01 21:24:02 <kaniini> the annotations we will want to do are
2018-02-01 21:24:22 <kaniini> provides="linux-grsec=${pkgver}-r${pkgrel} linux-hardened=${pkgver}-r${pkgrel}"
2018-02-01 21:24:26 <kaniini> for the main kernel(s)
2018-02-01 21:24:29 <kaniini> and
2018-02-01 21:24:40 <kaniini> provides="whatever-grsec=${pkgver}-r${pkgrel} ..."
2018-02-01 21:24:42 <kaniini> for the modules
2018-02-01 21:24:58 <kaniini> assuming all of that is there, apk will replace linux-hardened with linux-vanilla
2018-02-01 21:25:25 <fabled> HRio, I merged the github PR's secinfo in a way that the PR should get closed
2018-02-01 21:25:32 <ncopa> we also need replaces
2018-02-01 21:25:33 <ncopa> i think
2018-02-01 21:26:00 <kaniini> replaces should not be necessary for either, but adding it to the main kernel packages would not be harmful
2018-02-01 21:26:21 <kaniini> if replaces were needed, you would not be able to install both kernel variants at the same time
2018-02-01 21:26:29 <ncopa> hm
2018-02-01 21:26:31 <ncopa> true
2018-02-01 21:26:45 <HRio> fabled: great!
2018-02-01 21:27:18 <ncopa> ok i need to go
2018-02-01 21:27:27 <kaniini> lets discuss migration strategy tomorrow
2018-02-01 21:27:31 <kaniini> i need to go as well
2018-02-01 21:30:41 <kaniini> one thought i had
2018-02-01 21:31:04 <kaniini> instead of using annotations for the main package, we could use a transitional package which includes a symlink
2018-02-01 21:31:15 <kaniini> i am not sure how that would play out with some bootloaders, though
2018-02-01 21:31:32 <HRio> diskless is fat32, som symlinks....
2018-02-01 21:31:36 <HRio> so
2018-02-01 21:31:37 <kaniini> but need to leave for real now
2018-02-01 21:33:41 <HRio> fabled: as you are working on patchwork, be careful with the shadow change
2018-02-01 21:35:14 <HRio> I was not subscribed to the list when it was posted, so I could not reply to it, but have been discussing it with Drew
2018-02-01 21:35:26 <kaniini> hrio: diskless is irrelevant
2018-02-01 21:35:58 <kaniini> diskless setup the kernel booted is the one on the ISO
2018-02-01 21:36:00 <HRio> ok, as long as update-kernel handles the change of pkg name?
2018-02-01 21:38:35 <koldbrutality> are we getting rid of the hardened kernel?
2018-02-01 21:43:49 <koldbrutality> 4.9 was their last release https://grsecurity.net/passing_the_baton.php
2018-02-01 21:43:59 <koldbrutality> for the community
2018-02-01 21:51:48 <Ceruleis[m]> Yeah.
2018-02-01 22:05:07 <clandmeter> freenode_ceruleis[m]: this channel is also on matrix see topic.
2018-02-01 22:18:02 <mksully22> Looks like gdb http://build.alpinelinux.org/buildlogs/build-edge-ppc64le/main/gdb/gdb-8.0.1-r5.log is failing to build. I'll take a look at it unless someone else has any insights?
2018-02-01 22:26:31 <Ceruleis[m]> clandmeter: neat ty
2018-02-01 22:26:46 <clandmeter> yw
2018-02-01 22:27:17 <Ceruleis[m]> Don't suppose you have any comments on my swap issue? :^)
2018-02-01 22:29:42 <clandmeter> not today, about to go to bed. i can check it tomorrow.
2018-02-01 22:32:37 <Ceruleis[m]> np ty
2018-02-01 22:48:37 <koldbrutality> chromium's build system sucks too complicated
2018-02-01 23:08:03 <koldbrutality> for abuild.conf the default is 2 jobs but TOP reports more spawn compile units.  its there a way to cap it? to the number of cpu cores?
2018-02-01 23:09:29 <koldbrutality> or N-1 cores
2018-02-02 01:08:03 <kaniini> no
2018-02-02 01:08:04 <kaniini> you have to specify
2018-02-02 02:10:06 <koldbrutality> i need a way to cache the github clone
2018-02-02 02:10:18 <koldbrutality> it takes too long trying to download
2018-02-02 02:14:05 <koldbrutality> If I clone then tar.gz it and reference it in sources= it will unpack the local copy right?
2018-02-02 02:14:49 <koldbrutality> place it in the same location as the patches
2018-02-02 02:16:05 <koldbrutality> the package system is very immature
2018-02-02 02:38:17 <AWilcox[m]> I don't understand what that means
2018-02-02 02:38:33 <AWilcox[m]> If you download the .tar.gz referenced in sources= and put it in /var/cache/distfiles, then it will work, yes.
2018-02-02 02:48:13 <tmh1999> I have a C question, not really Alpine thing. The executable has a symbol _abc_xyz but when I run it in gdb, its value is zero. What might be the catch ?
2018-02-02 02:59:49 <koldbrutality> what i am saying is will abuild precheck the server before checking distfiles
2018-02-02 03:00:53 <koldbrutality> on gentoo you can tell ebuild (equivalent to abuild) to not check by putting a fetch restriction
2018-02-02 03:03:59 <koldbrutality> i don't think it will check because it would check the hash first.
2018-02-02 03:13:00 <koldbrutality> before stepping in?
2018-02-02 03:13:16 <koldbrutality> or on return?
2018-02-02 05:13:14 <kaniini> it checks to see if file is in /var/cache/distfiles
2018-02-02 05:13:18 <kaniini> if it does not match the right checksum
2018-02-02 05:13:20 <kaniini> it will delete it
2018-02-02 05:13:23 <kaniini> and redownload
2018-02-02 05:13:52 <kaniini> because our "very immature" package system is clearly inferior to gentoo in all ways
2018-02-02 05:13:55 <kaniini> 
ACTION eyerolls

2018-02-02 05:27:27 <tmh1999> good night kaniini
2018-02-02 05:31:40 <koldbrutality> not really immature but lacking certain things friendly to package creators
2018-02-02 05:33:09 <koldbrutality> like extra modules or functions per different build system like the eclass system in gentoo
2018-02-02 05:33:48 <koldbrutality> if that is not created then it creates duplicate code within the packages itself
2018-02-02 05:35:14 <AWilcox[m]> Because kernel-2 and toolchain are the epitome of packaging, right? >_>
2018-02-02 05:36:10 <koldbrutality> the duplicate code creates problems like the patching boilerplate code doesn't do dry run so what happens is that it is a partial patch then i end up trying to disable up to the patch
2018-02-02 05:36:47 <AWilcox[m]> Patching is done by abuild now.  Any package that does it in prepare is old and should be updated.
2018-02-02 05:37:13 <AWilcox[m]> I wish Matrix had hostmasks, I would request recovering-gentoo-victim.foxkit.us <_<
2018-02-02 05:37:33 <koldbrutality> then people like in the rust APKBUILD don't do return sanity checks return 1
2018-02-02 05:38:14 <AWilcox[m]> APKBUILDs are run with -e
2018-02-02 05:38:34 <AWilcox[m]> 'return 1' isn't required either and is line noise
2018-02-02 05:39:30 <koldbrutality> for sed commands will still pass through as if okay it is all good
2018-02-02 05:39:44 <koldbrutality> even though it didn't patch it properly
2018-02-02 05:40:29 <AWilcox[m]> `sed` should not be used to patch.
2018-02-02 05:40:53 <AWilcox[m]> Also, packages with fetch restrictions shouldn't be packaged for Alpine.  Alpine requires all packaged software to be libre, free, and redistributable.
2018-02-02 05:41:14 <koldbrutality> depends on the convention
2018-02-02 05:41:22 <koldbrutality> here is is not okay
2018-02-02 05:41:42 <koldbrutality> in Arch and Gentoo it is okay
2018-02-02 05:42:14 <AWilcox[m]> > There is also RESTRICT="fetch", which prevents Portage from trying to fetch anything manually. The pkg_nofetch function will be called if any SRC_URI components cannot be found. This should only be used if a license requires it.
2018-02-02 05:42:27 <AWilcox[m]> Any package with such a license is not compatible with Alpine's packaging guidelines
2018-02-02 05:43:06 <AWilcox[m]> Or are you talking about RESTRICT="primaryuri"?  Because abuild will /always/ try the actual source URL listed
2018-02-02 05:46:50 <koldbrutality> no there is a trick
2018-02-02 05:47:14 <AWilcox[m]> Okay.  Why don't you tell me what this "trick" is...
2018-02-02 05:48:38 <AWilcox[m]> We've already given you the answer to your original question (yes, abuild checks /var/cache/distfiles before it downloads files from the server, but it will skip /var/cache/distfiles if the checksum doesn't match the checksum in the APKBUILD sha512sums)
2018-02-02 05:49:00 <koldbrutality> i meant that you don't want the ebuild/portage to refer to the SRC_URI you can use the RESTRICT="fetch" and use git functions
2018-02-02 05:50:14 <AWilcox[m]> And, as someone who spent many years of their life trying to improve Gentoo to be shut out and dismissed over petty crap perpetuated by comrel, I think I know a great deal more about Gentoo than most everyone here
2018-02-02 05:50:31 <AWilcox[m]> You don't fetch-restrict live ebuilds, you override fetch
2018-02-02 05:50:48 <AWilcox[m]> Er, src_unpack that is
2018-02-02 05:51:06 <koldbrutality> i don't really remember i was just guessing
2018-02-02 05:51:16 <AWilcox[m]> https://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/svn-sources/index.html
2018-02-02 05:51:49 <koldbrutality> what I was looking for was for abuild to cache the git but doesn't do that here
2018-02-02 05:51:59 <koldbrutality> or doesn't say in the APKBUILD document
2018-02-02 05:52:13 <AWilcox[m]> See main/kamailio
2018-02-02 05:52:44 <AWilcox[m]> The preferred way is to make a snapshot using git fetch and git archive, upload that to Alpine servers as a snapshot archive .tar.gz, and use that
2018-02-02 05:53:08 <AWilcox[m]> There's a few others if you grep -r 'git clone' **/*/APKBUILD in aports.git
2018-02-02 05:53:46 <AWilcox[m]> That way you aren't wasting network bandwidth, CPU time, disk space, etc on every builder (which Alpine have many, for different versions and different CPU architectures) with `git`
2018-02-02 05:54:40 <AWilcox[m]> And indeed, rootbld doesn't even support network access during builds (think FEATURES="network-sandbox" enforced)
2018-02-02 05:55:18 <AWilcox[m]> So you can't hit git in `unpack`, it's too late to make a network connecti othen
2018-02-02 05:55:23 <AWilcox[m]> Network connection then*
2018-02-02 06:45:54 <koldbrutality> I created the snapshot but I cannot create a checksum for it
2018-02-02 06:48:51 <koldbrutality> is scp upload public and how long will it stay up there for snapshot?
2018-02-02 06:50:38 <koldbrutality> or is that only available for the builder?
2018-02-02 06:50:45 <koldbrutality> machine
2018-02-02 09:21:07 <jailbox> ncopa: re. main/ncurses@3.6-stable  it seems that 20171125 $source tarball is no longer available on mirror
2018-02-02 09:21:37 <jailbox> ncopa: likewise for kbd, it seems to have relocated to https://www.kernel.org/pub/linux/utils/kbd/kbd-2.0.4.tar.gz
2018-02-02 10:52:18 <ArjunM> Hi All, a qq
2018-02-02 10:53:06 <ArjunM> Any idea as when would the latest version of puppeteer be supported on Alpine? As of now it is 0.12.0, I am looking for 0.13.0 or 1.0.0
2018-02-02 11:44:37 <_ikke_> Amount of open issues on github is increasing: https://zabbix.alpinelinux.org/history.php?action=showgraph&itemids[]=28584
2018-02-02 12:11:25 <Shiz> clandmeter: you not coming t o FOSDEM?
2018-02-02 13:32:01 <ncopa> jailbox: ncurses is a mess :-/
2018-02-02 13:58:37 <jailbox> ncopa: no need to 'hurry' a fix for my sake, i just tried to unpack and noticed, so i did a "s/p20171125/p20180121/" to get some src
2018-02-02 14:41:35 <clandmeter> Shiz: im afraid not.
2018-02-02 14:41:39 <clandmeter> Shiz: you need a ride?
2018-02-02 14:41:43 <Shiz> nah i'm already there
2018-02-02 14:41:53 <Shiz> was just hoping for more cool peeps to show up
2018-02-02 14:42:47 <clandmeter> ah nice. I think i will try to attent next year.
2018-02-02 14:43:11 <ncopa> tmh1999: gdb 8.1 fails to build on s390x:
2018-02-02 14:43:17 <ncopa> 
ACTION sent a long message: ncopa_2018-02-02_14:43:12.txt <https://matrix.org/_matrix/media/v1/download/matrix.org/gByAYdXWWPVxIuebrqhRCzXW>

2018-02-02 14:43:33 <ncopa> the current s390x patch does not apply so i removed it
2018-02-02 15:08:39 <danieli> "authetification"
2018-02-02 15:51:29 <tmh1999> ncopa : working on it. currently doing the setup-disk.in script
2018-02-02 16:14:33 <koldbrutality> is there a policy on which version of qt and gtk to compile with? for edge.  does alpine officially default to gtk3, it is up to upstream to decide, or we can force gtk3?
2018-02-02 16:15:09 <koldbrutality> i prefer gtk3 because of smooth scroll
2018-02-02 16:16:25 <koldbrutality> on electron they force gtk2 by default but you can repatch it with gtk3
2018-02-02 16:17:13 <tmh1999> hah this fpreg again... we've had it before in s390x.
2018-02-02 16:28:56 <danieli> when it comes to py2/py3 packages, I build and install for each python version into the respective $subpkgdir
2018-02-02 16:29:15 <danieli> but the py-$pkgname package is tiny compared to the other ones, what is the logic behind this, exactly?
2018-02-02 16:32:44 <koldbrutality> i think py-$pkgname is like a meta package the dependency will choose either py2 or py3
2018-02-02 16:33:28 <danieli> thought as much
2018-02-02 16:34:00 <danieli> but it's supposed to be an "empty" metapackage, right?
2018-02-02 16:34:29 <danieli> ah screw it, it's for patchwork - mind reviewing it in a bit, clandmeter? it'll go to alpine-aports@lists.a.o
2018-02-02 16:34:48 <koldbrutality> i don't know but it could be a placeholder
2018-02-02 16:34:58 <danieli> the committer will see
2018-02-02 16:36:52 <danieli> god dammit, I just reproduced a package nearly to detail due to a typo when first looking for an existing package
2018-02-02 16:37:50 <danieli> oh well, git reset and git pull it is
2018-02-02 18:10:31 <^7heo> I'm convinced it's very wrong to export PS1 in the /etc/profile
2018-02-02 18:10:52 <^7heo> it relies on every shell to set their own PS1 at invokation, and that cannot be reliably done.
2018-02-02 18:11:01 <^7heo> especially since ash does NOT read any rc file.
2018-02-02 18:11:11 <^7heo> (unless invoked as login shell)
2018-02-02 18:12:09 <AWilcox[m]> I feel like I'm missing context; that started with "especially since ash does NOT read any rc file."
2018-02-02 18:12:15 <AWilcox[m]> Did the Matrix bridge skip a few lines?
2018-02-02 18:12:20 <^7heo> nope.
2018-02-02 18:12:30 <^7heo> ash does not read any rc file if it's not started as login shell.
2018-02-02 18:12:44 <^7heo> if it is started as login shell, then it does read various profile files.
2018-02-02 18:12:50 <AWilcox[m]> Same with bash
2018-02-02 18:13:07 <^7heo> bash always reads bashrc.
2018-02-02 18:13:14 <^7heo> no matter if started as login shell or not.
2018-02-02 18:13:21 <^7heo> and zsh also does.
2018-02-02 18:13:58 <^7heo> the only files read by ash when started are /dev/tty, ~/.ash_history and /etc/passwd
2018-02-02 18:14:17 <^7heo> if started as login shell, you will also have: /etc/profile and /etc/profile.d/*.sh
2018-02-02 18:14:58 <^7heo> (btw when I said
2018-02-02 18:15:07 <AWilcox[m]> 
ACTION sent a long message: AWilcox[m]_2018-02-02_18:15:07.txt <https://matrix.org/_matrix/media/v1/download/matrix.org/jUZBsHLmibmhBlWzVKojeMsP>

2018-02-02 18:15:12 <^7heo> "zsh also does", I meant: it also reads its own rc file)
2018-02-02 18:15:17 <AWilcox[m]> I just put `echo "It's bashrc..."` in /etc/bash/bashrc
2018-02-02 18:15:59 <^7heo> yeah in /etc/bash/bashrc, but I'm talking about your ~HOME/.bashrc there.
2018-02-02 18:16:17 <^7heo> I actually never use bash, so I'm not sure what is the behavior of bash.
2018-02-02 18:16:28 <AWilcox[m]> Oh.
2018-02-02 18:16:34 <^7heo> I know that zsh reads .zshrc when starting tho; no matter if it's a login shell or not.
2018-02-02 18:17:10 <AWilcox[m]> Yes, and bash reads your $HOME bashrc.
2018-02-02 18:17:21 <^7heo> yeah
2018-02-02 18:17:26 <^7heo> but my point is: ash does not read anything.
2018-02-02 18:17:30 <AWilcox[m]> I don't know what that has to do with PS1 though, or ash.
2018-02-02 18:17:40 <^7heo> so the ONLY way to be sure that every child of the login shell will have the proper PS1 is to export it.
2018-02-02 18:17:45 <^7heo> However, this is wrong.
2018-02-02 18:17:59 <^7heo> Because you cannot unexport a variable.
2018-02-02 18:18:09 <^7heo> You can unset one, but if re-set it will be exported again.
2018-02-02 18:19:12 <AWilcox[m]> It sounds like ash is just a pain to deal with if you want a custom PS1
2018-02-02 18:19:24 <^7heo> So long story short; since ash does NOT read any file when starting; if you export PS1 when executing the login shell, and then another shell comes around and sets it (without exporting it mind you) to its own value; then any subsequent call of ash will use that PS1
2018-02-02 18:19:46 <^7heo> AWilcox[m]: all that is needed is for ash to read a simplistic $HOME/.ashrc
2018-02-02 18:20:03 <^7heo> but fixing it by exporting PS1 is just plain wrong.
2018-02-02 18:20:07 <^7heo> and that's what Alpine is doing.
2018-02-02 18:20:13 <AWilcox[m]> I agree.
2018-02-02 18:21:03 <^7heo> Yeah so, should I open a PR?
2018-02-02 18:21:10 <^7heo> 'cause I already commited a fix locally.
2018-02-02 18:25:03 <AWilcox[m]> Do you have a patch for ash to read .ashrc?
2018-02-02 18:25:56 <^7heo> no I did not write that part.
2018-02-02 18:25:59 <^7heo> but it should be trivial.
2018-02-02 18:26:14 <^7heo> I only unborked alpine so far.
2018-02-02 18:26:40 <^7heo> AWilcox[m]: https://github.com/7heo/aports/commit/c18e2c023fbfd0bf6ac24c1b54bf2ca02627e4ab
2018-02-02 18:27:26 <^7heo> AWilcox[m]: that would be the commit that would be in the PR I would open.
2018-02-02 18:27:52 <^7heo> I am not sure if I should spend the time to contribute to busybox; as my patch will likely be rejected.
2018-02-02 18:28:04 <^7heo> (at least I expect any patch, ever, to likely be)
2018-02-02 18:28:14 <^7heo> (not specifically with busybox)
2018-02-02 18:29:27 <AWilcox[m]> That is not a very compatible /etc/profile heh
2018-02-02 18:29:38 <^7heo> AWilcox[m]: I just changed the export.
2018-02-02 18:29:41 <^7heo> AWilcox[m]: I'm not gonna fix the rest.
2018-02-02 18:29:49 <^7heo> I mean, I remember the patch trying to implement less -r; being rejected directly because someone mentionned systemd in the context of the patch.
2018-02-02 18:30:04 <skarnet> and that's a bad thing because?
2018-02-02 18:30:07 <skarnet> :P
2018-02-02 18:30:17 <^7heo> skarnet: because refusing a patch for the wrong reasons is wrong.
2018-02-02 18:30:23 <AWilcox[m]> The escape sequences aren't standardised
2018-02-02 18:30:31 <^7heo> yeah well...
2018-02-02 18:30:39 <^7heo> At this rate, the output of ls also isnt.
2018-02-02 18:30:43 <AWilcox[m]> https://code.foxkit.us/adelie/adelie-base/blob/master/tree/etc/profile < this is a POSIX /etc/profile
2018-02-02 18:30:45 <^7heo> s/isnt/isn't/
2018-02-02 18:31:27 <^7heo> AWilcox[m]: I'd double quote the EDITOR value and PAGER value.
2018-02-02 18:31:36 <^7heo> You never know if they were previously set with spaces in them.
2018-02-02 18:32:01 <skarnet> it's a login shell.
2018-02-02 18:32:13 <skarnet> You're supposed to know what the environment is like at this point.
2018-02-02 18:32:18 <AWilcox[m]> Ooh, good point!
2018-02-02 18:32:52 <AWilcox[m]> skarnet: The order of initialisation scripts is implementation-defined.  /etc/profile may be read first, or last, or intermediately, compared to other shell-specific initialisation scripts.
2018-02-02 18:32:56 <^7heo> AWilcox[m]: I'm eating POSIX sh for breakfast those days. Those are not happy days; but I hopefully spot stuff like that better ;)
2018-02-02 18:33:21 <skarnet> if you can't swear what the value of EDITOR and PAGER are by the time /etc/profile is run, then I don't want to have anything to do with your login system.
2018-02-02 18:33:39 <^7heo> AWilcox[m]: also kudos for using whoami and uname -n in the PS1
2018-02-02 18:34:00 <^7heo> skarnet: you can swear they contain spaces; in some cases.
2018-02-02 18:34:11 <skarnet> ...
2018-02-02 18:34:18 <^7heo> what? People do weird things.
2018-02-02 18:34:21 <^7heo> Really.
2018-02-02 18:34:52 <skarnet> what part of "at this point, the user is JUST logging in, so you should know the state the process is in" is hard to understand?
2018-02-02 18:35:36 <^7heo> the part where the profile script is getting that information from the process itself.
2018-02-02 18:36:00 <skarnet> the process comes from login(8). The state it's in is DOCUMENTED.
2018-02-02 18:36:14 <skarnet> knowing what your system does is so 2017
2018-02-02 18:36:40 <^7heo> skarnet: is it documented anywhere that the env variables EDITOR and PAGER shall not contain any space character?
2018-02-02 18:36:48 <^7heo> because if so, that's news to me.
2018-02-02 18:37:18 <^7heo> (or, maybe that NO variable in the environment shall contain space characters; maybe. But same, that'd be news to me)
2018-02-02 18:37:45 <AWilcox[m]> Okay, I've just checked
2018-02-02 18:38:08 <AWilcox[m]> Yes, /etc/profile is read in first, before any other shell rc, by every shell we (Adelie) ship except fish
2018-02-02 18:38:19 <^7heo> except fish :D
2018-02-02 18:38:51 <AWilcox[m]> This is documented by the maintainers of fish: "fish is not a POSIX 1003.1-compliant shell, and does not read /etc/profile.  If you are using Linux, use /etc/environment; otherwise, consider /etc/login.defs."
2018-02-02 18:39:01 <^7heo> AWilcox[m]: but can you swear that any login(8) any user will ever use will let EDITOR and PAGER unset?
2018-02-02 18:39:52 <AWilcox[m]> I can audit the code of login(8) later tbh
2018-02-02 18:39:55 <AWilcox[m]> I have actual work to do today lol
2018-02-02 18:39:59 <^7heo> sure :D
2018-02-02 18:40:01 <skarnet> ^7heo: you don't seem to understand what I'm saying
2018-02-02 18:40:07 <^7heo> skarnet: maybe I'm not.
2018-02-02 18:40:19 <^7heo> skarnet: I'd actually not be against learning :)
2018-02-02 18:40:48 <skarnet> login descends from getty, which descends from init (more or less). All this chain of processes is controlled by root. So you're supposed to *know exactly what your environment is* at this point.
2018-02-02 18:41:10 <skarnet> Nowhere in this chain do users have the opportunity to mess up the environment the machine is configured with.
2018-02-02 18:41:20 <skarnet> they mess up the environment _later_.
2018-02-02 18:41:33 <^7heo> well, they'd do so, by replacing the components; if at all.
2018-02-02 18:41:47 <^7heo> and if POSIX does NOT specify what login(8) should NOT do with the environment...
2018-02-02 18:41:54 <^7heo> it'd still be posix to set EDITOR or PAGER.
2018-02-02 18:42:22 <skarnet> ok, I give up. I'll try again when you've turned your brain on.
2018-02-02 18:42:29 <^7heo> :D
2018-02-02 18:42:40 <^7heo> I'll tell you when I'm sober.
2018-02-02 18:43:34 <AWilcox[m]> FWIW, login(8) etc are not specified by POSIX on purpose.
2018-02-02 18:43:37 <Aerdan[m]> POSIX provides a list of variables it is unwise to tinker with. that is about the only reference it makes to PAGER and EDITOR, AFAICT: http://pubs.opengroup.org/onlinepubs/7908799/xbd/envvar.html
2018-02-02 18:43:43 <AWilcox[m]> The Open Group doesn't touch authentication, leaving it (on purpose) up to the implementation
2018-02-02 18:43:45 <^7heo> AWilcox[m]: yeah that I didn't know tho.
2018-02-02 18:44:02 <^7heo> I was currently wondering why login wasn't on opengroups
2018-02-02 18:45:07 <^7heo> But so there's no way to know what a POSIX system would do with the environment prior to calling /etc/profile, or is there?
2018-02-02 18:45:13 <AWilcox[m]>        ENVIRON_FILE (string)
2018-02-02 18:45:14 <AWilcox[m]>            If this file exists and is readable, login environment will be read from it. Every line should be in the form name=value.
2018-02-02 18:45:34 <AWilcox[m]> That's the man page of shadow's login.defs(5)
2018-02-02 18:45:46 <^7heo> yeah.
2018-02-02 18:45:47 <AWilcox[m]> So yes, you definitely can set EDITOR and PAGER before /etc/profile is read
2018-02-02 18:45:57 <AWilcox[m]> But that is implementation-defined
2018-02-02 18:46:01 <^7heo> great.
2018-02-02 18:46:23 <^7heo> so you could set crap there, including spaces; before /etc/profile is read. And still be POSIX.
2018-02-02 18:46:42 <AWilcox[m]> I don't know if shadow would accept spaces; it says name=value
2018-02-02 18:46:46 <skarnet> yes, if you're an admin
2018-02-02 18:46:50 <AWilcox[m]> Now I really need to audit the code of login(8) to be sure :P
2018-02-02 18:46:58 <skarnet> can a USER change that environment?
2018-02-02 18:47:03 <^7heo> skarnet: yeah well; anyone's an admin those days.
2018-02-02 18:47:12 <^7heo> this is one of those handholding vs education discussions.
2018-02-02 18:47:20 <skarnet> okay, so
2018-02-02 18:47:24 <^7heo> should we let the clueless admins break their systems or not.
2018-02-02 18:47:28 <AWilcox[m]> skarnet, no, but the point is adelie's /etc/profile should be usable even if an administrator changes ENVIRON_FILE.
2018-02-02 18:47:37 <^7heo> AWilcox[m]: ^ what I said.
2018-02-02 18:47:46 <AWilcox[m]> This argument is literally about adding two sets of double-quotes to a shell script
2018-02-02 18:47:50 <AWilcox[m]> It's 4 bytes to make everything safe
2018-02-02 18:48:02 <skarnet> AWilcox[m]: that's the first sensible thing I've heard on this subject, and I can't object to that
2018-02-02 18:48:06 <^7heo> yeah but skarnet has a point: maybe we WANT them to learn it's not safe.
2018-02-02 18:48:07 <kaniini> hi theo welcome back
2018-02-02 18:48:29 <^7heo> kaniini: hey kaniini; I'm just here to complain, don't worry, I'll be gone asap :D
2018-02-02 18:48:40 <^7heo> damn I should not drink so much before IRCing.
2018-02-02 18:48:47 <^7heo> sorry for the double highlight.
2018-02-02 18:48:57 <^7heo> bbl.
2018-02-02 18:49:12 <AWilcox[m]> It's one thing to know you shouldn't, but it's another thing to actually stop doing it :)
2018-02-02 18:49:21 <^7heo> AWilcox[m]: fair 'nuf.
2018-02-02 18:49:21 <skarnet> this argument isn't about two sets of doublequotes, it's about knowing what state your processes are in. But if the goal is supporting admins who change that state, then okay.
2018-02-02 18:49:29 <^7heo> that ^
2018-02-02 18:49:52 <^7heo> I'll go play pool now; I will have less chances to do weird crap.
2018-02-02 18:49:53 <^7heo> laters.
2018-02-02 18:50:34 <skarnet> inb4 hospital calling, patient came in with a cue stick stuck in weird places
2018-02-02 19:07:30 <kaniini> actually.
2018-02-02 19:07:33 <kaniini> ACTUALLY.
2018-02-02 19:10:43 <danieli> ACKCHUYALLY
2018-02-02 19:24:40 <kaniini> wrong chat :p
2018-02-02 19:25:44 <kaniini> "should we let the clueless admins break their systems or not."
2018-02-02 19:25:47 <kaniini> well
2018-02-02 19:25:58 <kaniini> when it comes to alpine, i mean, i don't really care either way
2018-02-02 19:26:55 <kaniini> when it comes to adelie, if some clueless person opens a ticket complaining their system is broken, well, that takes resources away from assisting people who actually know what they are doing and need our help for something interesting
2018-02-02 19:28:04 <kaniini> so it seems like if we can go out of our way to mitigate the possibility of a clueless admin breaking their system, that's probably good for business right?
2018-02-02 19:30:22 <skarnet> yes
2018-02-02 19:30:31 <skarnet> I have no objection to more safety :P
2018-02-02 19:38:40 <kaniini> OSHA-compliant computing experiences obviously
2018-02-02 21:17:22 <Ganwell> The update we did in ncurses crashes anything that is based libtermkey/unibilium and tmux
2018-02-02 21:17:54 <Ganwell> I guess it is this https://github.com/mauke/unibilium/issues/30
2018-02-02 21:18:59 <Ganwell> which means my computer turned completey useless, I have to edit in nano without tmux!
2018-02-02 21:59:06 <fugitive> Hello. Is there some well known issue with php7 on 3.7 ? I am getting segfaults
2018-02-02 22:12:08 <fugitive> nvm, php5 seems to work
2018-02-03 01:37:02 <koldbrutality> can we use patches from arch linux to build an alpine package?  or do we need to do chinese wall cleaning room design?  some of these are just 1 liner patches
2018-02-03 01:39:13 <danieli> depends on what kind of patch
2018-02-03 01:39:35 <danieli> pkgbuilds and apkbuilds are for entirely different systems, just so that's clear
2018-02-03 01:39:57 <danieli> if it's shell, it has to be ash, and if it's anything C, it has to build with musl
2018-02-03 01:42:48 <koldbrutality> it's for webkit and electron.  i can eliminate some patches to be less dependent on them
2018-02-03 01:43:20 <danieli> oh god
2018-02-03 01:43:28 <danieli> CEF and electron is gonna be a great deal of fun
2018-02-03 01:43:33 <koldbrutality> electron is a platform for building gui apps for javascript
2018-02-03 01:43:40 <danieli> i am fully aware of what it is and how it works
2018-02-03 01:43:49 <danieli> :')
2018-02-03 01:43:51 <koldbrutality> i have it someone compiling
2018-02-03 01:44:02 <danieli> what?
2018-02-03 01:45:01 <koldbrutality> [1659/19991] still bugs third_party/WebKit/Source/platform/wtf/Assertions.cpp:146:3: error: unknown type name 'Dl_info'
2018-02-03 01:47:41 <danieli> that's a struct from dlfcn.h
2018-02-03 01:47:56 <danieli> which exists in musl-dev
2018-02-03 02:42:19 <koldbrutality> I think the problem was the conditional.  I changed !defined(__UCLIBC__) to defined(__GLIBC__).
2018-02-03 04:55:26 <koldbrutality> wtf i put abuild startx and it launches X how is that possible
2018-02-03 05:02:44 <kaniini> :D :D :D
2018-02-03 05:03:03 <kaniini> abuild just execs whatever is $1
2018-02-03 05:03:04 <kaniini> you can even do
2018-02-03 05:03:07 <kaniini> abuild rm -rf /
2018-02-03 05:03:12 <kaniini> ;)
2018-02-03 05:03:12 <kaniini> well
2018-02-03 05:03:13 <kaniini> not really
2018-02-03 05:47:45 <koldbrutality> I can't hook ccache to GN/ninja
2018-02-03 06:22:39 <mepholic> lmao
2018-02-03 06:23:42 <koldbrutality> i fixed it
2018-02-03 06:24:17 <koldbrutality> had to add cc_wrapper = "ccache"
2018-02-03 06:24:47 <koldbrutality> i should distcc this
2018-02-03 06:25:50 <Aerdan[m]> good luck with that
2018-02-03 06:29:42 <koldbrutality> it doesn't really speed things up maybe shave off an hour or 3 for chromium
2018-02-03 06:30:36 <koldbrutality> the people at google use goma they said it takes 30 mins
2018-02-03 06:31:06 <koldbrutality> best case
2018-02-03 19:53:52 <_ikke_> clandmeter: ^ nice
2018-02-03 23:35:28 <koldbrutality> hum my emojis can't load when I startx
2018-02-04 00:01:38 <koldbrutality> err noto-color-emoji is a bit broken on chromium and it doesn't work on xfce4-terminal
2018-02-04 00:01:55 <koldbrutality> on my gentoo setup i had it working on both
2018-02-04 00:02:49 <koldbrutality> okay I see that it is disabled in cairo
2018-02-04 00:02:59 <koldbrutality> i will make a pull request to enable it
2018-02-04 00:14:01 <koldbrutality> err apk add is complaining about breakage.  i incremented the pkgrel and there should be no change in the ABI.
2018-02-04 00:14:32 <koldbrutality> oh that is because cairo-dev
2018-02-04 00:28:12 <koldbrutality> In Alpine does it store information about version information of dependency on the main package?
2018-02-04 00:29:33 <koldbrutality> It would require to compile the main package if I update the dependency's package rel right?
2018-02-04 00:50:33 <koldbrutality> apk del is being rebellious won't allow me to remove package it keeps installing instead
2018-02-04 00:52:46 <Aerdan[m]> if you have other rules which pull in the particular package, apk won't let you remove it.
2018-02-04 00:55:41 <koldbrutality> i think i found out why its because the .makedepends
2018-02-04 04:56:42 <jailbox> are there any "rules" on sequence of abuild cmd's (or maybe inter-depends between cmd's) that one should know about? like is there any diff between 'unpack, clean, undeps' and 'unpack, undeps, clean' etc.
2018-02-04 05:00:28 <TBB> there at least used to be a part in abuild itself that has the sequence neatly in one place
2018-02-05 02:02:15 <tmh1999> ncopa : the gdb bug is s390x thing or ppc thing ? it seems to be okay after the gdb ppc patch few days ago ?
2018-02-05 04:31:58 <koldbrutality> oh crap it is pulling more npm packages.  i gotta check a ton of licenses again.
2018-02-05 09:16:18 <koldbrutality> what does flagged mean in the package database?
2018-02-05 09:16:29 <koldbrutality> flagged for removal?
2018-02-05 09:20:36 <koldbrutality> oh out of date
2018-02-05 09:54:40 <clandmeter2> flagged out of date
2018-02-05 18:41:58 <AWilcox[m]> https://lists.spdx.org/pipermail/spdx-legal/2018-February/002462.html
2018-02-05 18:42:26 <AWilcox[m]> Y'all may want to keep up with that thread.  I'm trying to figure out what license identifier to use for main/bind.  They have a few special licenses that aren't in any of {OSI, FSF, SPDX}...
2018-02-05 22:36:01 <AWilcox[m]> Should packages that have .zips makedepends="unzip"?
2018-02-05 22:36:12 <AWilcox[m]> Or should unzip be added to abuild's depends=?
2018-02-05 22:36:17 <kaniini> good question
2018-02-05 22:36:36 <kaniini> i think the latter, because xz for example is a dependency of abuild
2018-02-05 22:36:39 <AWilcox[m]> abuild already has lzip and such in depends=, so it may make more sense to put unzip in there
2018-02-05 22:37:07 <kaniini> yes
2018-02-05 22:45:14 <ncopa> i think i didnt add unzip as depends since busybox provides an unzip
2018-02-05 22:47:59 <Aerdan[m]> Ad§'
2018-02-05 22:48:01 <Aerdan[m]> er
2018-02-05 22:48:15 <Aerdan[m]> Adélie doesn't use busybox.
2018-02-05 22:49:24 <AWilcox[m]> That's our problem.  I didn't realise it was a busybox thing.  I'll just carry a patch in our abuild package, no worries
2018-02-05 22:51:03 <Aerdan[m]> probably have busybox provides="unzip" then have abuild depend on unzip, then?
2018-02-05 22:51:10 <kaniini> yes, i think that is the way to do it
2018-02-05 22:52:39 <ncopa> we dont automatically add all the busybox's provides=cmd:...
2018-02-05 22:52:52 <ncopa> becase the symlinks are not shipped with the package
2018-02-05 22:53:00 <ncopa> the busybox package is a hack basically
2018-02-05 22:56:48 <AWilcox[m]> Not only that, but if unzip is installed then busybox stops providing it because of the way the trigger works (iirc)
2018-02-05 22:58:50 <ncopa> yes
2018-02-05 22:59:15 <ncopa> are there many package that uses .zip?
2018-02-05 22:59:43 <ncopa> i think fixing provides for busybox is in the apk3 roadmap
2018-02-05 23:04:37 <AWilcox[m]> docbook-xml is so far the only one
2018-02-05 23:05:14 <AWilcox[m]> But do note, I haven't built the entirety of main/ yet for Adelie
2018-02-05 23:10:32 <kaniini> ncopa: there are some things in the roadmap towards apk3 that will enable busybox to be less of a hack yes
2018-02-05 23:10:51 <AWilcox[m]> It's just docbook-xml, espeak, fts, glm, hunspell-en, logtail, lua-sqlite, proxychains-ng, five very old py-* modules, qextserialport, uvncrepeater, and then a few ttf-* fonts.
2018-02-05 23:10:54 <AWilcox[m]> That's all the packages that use .zip
2018-02-05 23:11:22 <AWilcox[m]> And three of those are just because they are using the GitHub auto-zip thing that can also do .tar.gz
2018-02-05 23:13:08 <danieli> auto-zip? that's uh, downloading a commit/branch directly?
2018-02-05 23:13:28 <danieli> releases provides at least zip, usually tgz and a tar.bz2
2018-02-05 23:14:05 <AWilcox[m]> Yes
2018-02-05 23:18:03 <AWilcox[m]> It doesn't seem like _FORTIFY_SOURCE=0 is needed any more for findutils (we removed it in Adelie almost a year ago and haven't seen any bad things, and in fact the test suite passes as well).  Should I remove it as part of our PRs?
2018-02-05 23:18:18 <AWilcox[m]> The commit log comment was that "gnulib breaks fortify source, so for now we disable it"
2018-02-05 23:20:36 <ncopa> they probably fixed it upstream
2018-02-05 23:20:47 <ncopa> i think the simplest thing to do for now is add unzip as makedepends for those few packages that needs it
2018-02-05 23:21:40 <ncopa> we could make unzip an abuild dependency too, but it would add another package needed to be boostrapped
2018-02-06 06:43:25 <koldbrutality> the font-noto is missing chinese, korean, japanese (cjk) use same package or seperate?
2018-02-06 06:47:26 <koldbrutality> there is no free alternative for comic sans in the package database.  we could package Comic Neue. https://en.wikipedia.org/wiki/Comic_Neue
2018-02-06 06:49:26 <koldbrutality> fantasque-sans is the monospaced comic sans for programmers https://github.com/belluzj/fantasque-sans
2018-02-06 07:48:02 <koldbrutality> i packaged Comic Neue.  working on fantasque-sans.  the latter has some dependencies not found in the package database.
2018-02-06 08:13:34 <Nebukadneza> *morning
2018-02-06 08:14:09 <Nebukadneza> ncopa: say … about our recent bats-on-git-snapshot discussion: while my upstream comment got lots of upvotes, nothing seems to have moved
2018-02-06 08:19:18 <Nebukadneza> (on upstream-side, that is)
2018-02-06 08:19:20 <Nebukadneza> how do you feel about the idea meantime…?
2018-02-06 08:41:05 <koldbrutality> this is a dependency nightmare
2018-02-06 09:04:08 <koldbrutality> i need to run paxmark before run.py ./mksnapshot  is run but GN script makes it difficult to do compared to simple edits with autotool scripts
2018-02-06 15:27:16 <ncopa> fabled: i think the s390x build failure may be an apk-tools bugg
2018-02-06 15:27:37 <ncopa> `apk add lua-dev` fails on the builder, but not in my dev env
2018-02-06 15:28:35 <fabled> huh
2018-02-06 15:28:42 <ncopa> i dunno if we want investigate it closer
2018-02-06 15:28:56 <ncopa> lua5.1-dev has a provides=lua-dev
2018-02-06 15:31:25 <ncopa> i think it is related that it does not have access to the http repos
2018-02-06 15:31:45 <ncopa> i mean, only local repos are in /etc/apk/repositories
2018-02-06 15:32:57 <ncopa> fabled: would you like to analyze it or should i just work around it
2018-02-06 15:33:12 <ncopa> i think i can change makdepends=lua-dev to makedepends=lua5.1-dev
2018-02-06 15:33:30 <ncopa> and it will work
2018-02-06 15:35:39 <fabled> so what's the problem?
2018-02-06 15:35:47 <fabled> i think apk is working as expected
2018-02-06 15:35:57 <fabled> you ask for lua-dev, but it's pure virtual provides so it's not auto selected
2018-02-06 15:36:12 <fabled> lua5.1-dev should have provides=$pkgver-r$pkgrel instead
2018-02-06 15:36:42 <fabled> oh
2018-02-06 15:36:49 <fabled> or it's the provider_priority now
2018-02-06 15:37:46 <fabled> provides priority is not in .PKGINFO
2018-02-06 15:37:51 <fabled> maybe just recompile lua5.1 ?
2018-02-06 15:37:56 <fabled> it was probably built with too old abuild
2018-02-06 15:38:12 <ncopa> aha
2018-02-06 15:38:30 <ncopa> that may make sense
2018-02-06 15:38:37 <ncopa> so, first update abuild, then rebuild lua5.1
2018-02-06 15:38:39 <ncopa> let me try that
2018-02-06 15:38:53 <fabled> y
2018-02-06 15:39:44 <ncopa> yup
2018-02-06 15:39:46 <ncopa> that worked
2018-02-06 15:40:15 <ncopa> thats a thing we need to fix with the new build infra
2018-02-06 15:40:38 <ncopa> first check everything in the build-base and abuild tree
2018-02-06 15:40:38 <ncopa> and build those first
2018-02-06 15:40:51 <ncopa> abuild is not in the dependency tree and may be built late
2018-02-06 15:42:29 <ncopa> thanks!
2018-02-06 15:42:57 <fabled> you're welcome
2018-02-06 15:43:37 <ncopa> on armhf: /usr/lib/gcc/armv6-alpine-linux-musleabihf/6.4.0/../../../libboost_context-mt.so: undefined reference to `std::__get_once_mutex()'
2018-02-06 15:43:49 <ncopa> i think i have seen something similar earlier
2018-02-06 15:51:44 <ncopa> tmh1999: s390x has a test in 'gc' that fails
2018-02-06 16:08:37 <Nebukadneza> yoho
2018-02-06 16:08:50 <Nebukadneza> … regarding what to do with the bats/bats-core package
2018-02-06 16:09:41 <ncopa> hi
2018-02-06 16:09:52 <Nebukadneza> ncopa: can i quickly get on your nerves again a bit?
2018-02-06 16:09:59 <ncopa> i'd like to continue ping upstream
2018-02-06 16:10:04 <Nebukadneza> (also, broken internet here messed my message order … sorry)
2018-02-06 16:10:16 <ncopa> i need to reloace
2018-02-06 16:10:16 <ncopa> relocate
2018-02-06 16:10:18 <ncopa> bbl
2018-02-06 16:12:13 <Nebukadneza> mh, ok — so you oppose merging the current snapshot proposal?
2018-02-06 16:12:13 <Nebukadneza> should i (or can you?) close the issue in that case? or shall we leave it open as a flag for upstream?
2018-02-06 16:12:16 <Nebukadneza> np, laters :-)
2018-02-06 16:16:14 <ncopa> im ok keeping it open
2018-02-06 16:22:54 <Nebukadneza> oki, let’s stay with that then
2018-02-06 16:47:09 <fabled> ncopa, you think https://github.com/alpinelinux/aports/pull/3140/files is ok?
2018-02-06 16:55:28 <danieli> do I change up community/py-pyldap's setup.cfg?
2018-02-06 16:55:33 <danieli> # Linux distributors/packagers should adjust these settings
2018-02-06 16:55:39 <danieli> and we're only making a minimal build
2018-02-06 17:23:53 <koldbrutality> is there a way to specify mutual exclusive package?
2018-02-06 17:24:17 <kaniini> yes
2018-02-06 17:24:20 <kaniini> put the other package as !package in depends
2018-02-06 17:25:33 <kaniini> fabled: well, we need to make sure file is cross-compileable
2018-02-06 17:36:04 <ncopa> i think it was for mips
2018-02-06 17:36:27 <danieli> i can look into getting us some help with mips, i have an idea about someone who can help
2018-02-06 17:36:34 <danieli> they might just provide build hw too
2018-02-06 17:38:15 <ncopa> im ok with it (give file is crosscompileable)
2018-02-06 17:38:15 <ncopa> i mean, im ok with https://github.com/alpinelinux/aports/pull/3140/files assuming its possible to crosscompile file.
2018-02-06 17:40:15 <danieli> considering i've seen it everywhere and it's a standard unix program, i would assume so
2018-02-06 18:00:48 <tmh1999> ncopa: seems like collectd is still not picking up lua-dev. hum
2018-02-06 18:01:09 <tmh1999> doing the gc thing
2018-02-06 18:04:10 <vkrishn> koldbrutality: koldbrutality, would it be a good idea to have aliases for pkgname either a metapkg or embedded in pkg itself (various languages), this could reduce some related complexities
2018-02-06 18:06:17 <vkrishn> I think the same could be done for licenses in aports (eg. apkbuild.meta file)
2018-02-06 18:06:27 <vkrishn> example "GPL-2.0+" is equally valid to "GPL-2.0-or-later"
2018-02-06 18:07:36 <vkrishn> or a single file in eg aports/.meta OR aports/.meta/aliases
2018-02-06 18:10:46 <vkrishn> as for other language pkg name, even search could be applied, and on advanced apk/installer specify lang=chinese in command line, then <pkg name in chinese>
2018-02-06 18:11:22 <vkrishn> but that is just rough idea
2018-02-06 18:12:59 <vkrishn> gtg, would read logs, if someone replies ;)
2018-02-06 18:17:02 <vkrishn> oops, sorry, I misread koldbrutality's msg
2018-02-06 18:18:05 <vkrishn> was trying to digest logs, I took it as other lang chars in pkg name ;)
2018-02-06 18:21:38 <HRio> kaniini: can you review https://github.com/alpinelinux/aports/pull/3154 for me?
2018-02-06 18:30:26 <ncopa> wow, the ifdefs in `gc` for detecting and setting thread stack size is impressively complicated
2018-02-06 18:30:47 <ncopa> lots of ifdefs for misc platforms
2018-02-06 18:31:03 <mitchty> does abuild not honor the EXTRADEPENDS_BUILD env var?
2018-02-06 18:31:51 <mitchty> i'm trying to setup a cross compile to other arches and its appearing that its not actually installing the stage2 gcc that gets built
2018-02-06 18:43:31 <koldbrutality> Does anyone see why it is breaking CI for https://github.com/alpinelinux/aports/pull/3215 ?
2018-02-06 18:46:22 <fabled> koldbrutality, https://travis-ci.org/alpinelinux/aports/builds/338137426?utm_source=github_status&utm_medium=notification
2018-02-06 18:46:27 <fabled> seems temporary networking glitch
2018-02-06 18:48:10 <koldbrutality> i see what what went wrong... it has a different implementation of mv
2018-02-06 18:48:29 <koldbrutality> and the log didn't expand the full log
2018-02-06 18:50:22 <koldbrutality> mv on remote doesn't support -t
2018-02-06 18:53:11 <koldbrutality> my system has coreutils version of mv but the remote has the busybox version of mv
2018-02-06 18:53:20 <koldbrutality> how did that happen?
2018-02-06 18:53:42 <koldbrutality> I thought the toolchain was isolated
2018-02-06 19:11:44 <koldbrutality> vkrishn: just stick to what is listed in https://spdx.org/licenses/ no alias needed
2018-02-06 19:16:21 <koldbrutality> clandmeter: you created the noto package.  merge or seperate package for noto-cjk? for the chinese-japanese-korean set
2018-02-06 19:26:10 <mitchty> figured out my issue, local abuild was too old
2018-02-06 19:26:36 <mitchty> also had to add make to gcc and musl dev depends to get bootstrap.sh to succeed
2018-02-06 19:26:45 <mitchty> and learnt don't bootstrap more than one arch at a time
2018-02-06 19:28:28 <mitchty> second question, anyone try installing alpine linux on a nvidia tx2?
2018-02-06 21:09:06 <tmh1999> ncopa : gc indeed, can you just allow the build-edge-s390x to continue to build and upload packages to https repo, instead of just stucking in main ?
2018-02-06 21:09:25 <tmh1999> gc sometimes 2 segfault for me on s390x. sometimes 1. still working
2018-02-06 21:15:47 <tmh1999> in fact the bug was introduced since 7.6.0, not just 7.6.4
2018-02-06 21:16:17 <ncopa> tmh1999: test runs out of stack
2018-02-06 21:17:21 <tmh1999> iirc musl is 81920 hum
2018-02-06 21:17:42 <ncopa> tmh1999: https://github.com/ivmai/bdwgc/issues/202
2018-02-06 21:18:09 <tmh1999> okay you are too quick ncopa
2018-02-06 21:18:16 <ncopa> yes, code i supposed to deal with it but hits a cornercase
2018-02-06 21:18:36 <Aerdan[m]> vkrishn, if you're still around: there's no real need to do all that because SPDX 3 tools are required to support SPDX 2 terms. the problem lies more in the ambiguity of terms like 'GPL-2.0'.
2018-02-06 21:18:36 <ncopa> i spent a while trying to figure out what really happens
2018-02-06 21:18:51 <tmh1999> thanks a lot
2018-02-06 21:20:00 <tmh1999> still working on it. seems interesting one. could learn a little bit more o/
2018-02-06 21:20:31 <ncopa> code is misleading
2018-02-06 21:20:51 <ncopa> what happens is not what you would expect after reading the code
2018-02-06 21:21:06 <ncopa> i can tell what i did
2018-02-06 21:21:33 <ncopa> first thing was i noticed there was a segfault
2018-02-06 21:21:34 <ncopa> so i enabled core dumps
2018-02-06 21:21:53 <ncopa> well first thing is to report it upstream, they often have an idea why things goes wrong
2018-02-06 21:22:31 <ncopa> after i got a core dump i did a backtrace which looked like a recursive function
2018-02-06 21:22:34 <ncopa> 500 calls deep or so
2018-02-06 21:22:47 <ncopa> at that point i was pretty convinced it ran out of stack
2018-02-06 21:22:57 <ncopa> since its a common problem with musl
2018-02-06 21:23:29 <ncopa> so i searched the code with 'ag' (the_silver_searcher)
2018-02-06 21:23:32 <ncopa> ag pthread_create
2018-02-06 21:23:34 <ncopa> or similar
2018-02-06 21:23:47 <ncopa> and found tests/test.c
2018-02-06 21:24:14 <ncopa> no, actually, i looked for the c file generating gctest, and found tests/test.c
2018-02-06 21:26:06 <ncopa> where i found the define DEFAULT_STACK_MAYBE_SMALL
2018-02-06 21:26:06 <ncopa> i injected a #error foo within the #ifdef to see if it was set at compile time
2018-02-06 21:26:07 <ncopa> and found out that it was not set
2018-02-06 21:26:28 <ncopa> a comment the include/private/gccconfig.h indicated that it was supposed to be set for musl (NO_GETCONTEXT should be set with musl libs)
2018-02-06 21:27:06 <ncopa> tat was basically it
2018-02-06 21:27:08 <ncopa> except that there are 2 pthread_create calls
2018-02-06 21:27:21 <AWilcox[m]> https://code.foxkit.us/adelie/patches/blob/master/dev-libs/boehm-gc/boehm-gc-7.4.2-testsuite.patch I think this maybe never got upstream
2018-02-06 21:27:21 <AWilcox[m]> I'm not sure
2018-02-06 21:27:56 <ncopa> first is not a problem (and code does reverse of what you'd expect)
2018-02-06 21:28:40 <ncopa> A. Wilcox: aha
2018-02-06 21:28:43 <ncopa> yeah that may make sense
2018-02-06 21:29:19 <tmh1999> nice !
2018-02-06 21:29:27 <ncopa> in general, the code is messy and upstream seem to prefer fix it by adding more mess
2018-02-06 21:29:36 <tmh1999> :D
2018-02-06 21:33:54 <ncopa> tm1999: main finally built on s390x
2018-02-06 21:35:27 <tmh1999> beautiful
2018-02-06 21:36:29 <tmh1999> o/ yay uploading
2018-02-06 21:49:07 <tmh1999> looking at its issues page, it has history with musl before
2018-02-06 21:49:40 <ncopa> looks like upload hang
2018-02-06 21:55:57 <ncopa> jirutka: im gonna disable mruby on armhf. build fails
2018-02-06 22:13:29 <tmh1999> ncopa : there were time when we/you had to disable s390x, maybe you left some config somewhere that not allowing it to upload packages ?
2018-02-06 22:14:35 <ncopa> no, i think its network issue
2018-02-06 22:15:18 <danieli> what's up with s390x?
2018-02-06 22:15:29 <ncopa> dunno
2018-02-06 22:15:36 <danieli> what are the symptoms and guesses?
2018-02-06 22:15:42 <ncopa> builder does rsync, but it seems to have hung
2018-02-06 22:15:50 <danieli> strace show anything interesting?
2018-02-06 22:16:08 <danieli> and is a connection made and the protocol initialized?
2018-02-06 22:17:45 <danieli> also `rsync -v` or `rsync -vv` (older rsync)
2018-02-06 22:18:06 <ncopa> strace lacks needed permissions
2018-02-06 22:18:53 <ncopa> strace: Process 55046 attached
2018-02-06 22:18:54 <ncopa> select(9, [8], [], [8], {38, 629149}
2018-02-06 22:19:02 <ncopa> thats the local process
2018-02-06 22:19:04 <ncopa> nothing happens
2018-02-06 22:19:56 <ncopa> same with the ssh rsync --server
2018-02-06 22:22:27 <danieli> lacks permissions, bleh
2018-02-07 04:24:26 <koldbrutality> is there an APKBUILD template to create desktop menu entry?
2018-02-07 04:25:59 <koldbrutality> i think i found something
2018-02-07 04:51:09 <koldbrutality> musl doesn't have isnanf?
2018-02-07 04:56:39 <lucy_bunny> isnan should work on floats and doubles
2018-02-07 05:01:29 <koldbrutality> yeah i used that with #define isnanf isnan
2018-02-07 05:02:20 <koldbrutality> i'm packaging the godot game engine right now
2018-02-07 07:37:56 <koldbrutality> i got 3.0 godot to run but i can't load the demos... going to try 2.1.4 stable
2018-02-07 09:46:17 <koldbrutality> godot 2.1.4 works but i'm not getting 3d acceleration for some reason with the 3d platformer demo
2018-02-07 09:47:01 <koldbrutality> the 2d platformer demo is fast enough
2018-02-07 10:03:36 <koldbrutality> the truck town level was more faster but not too slow
2018-02-07 10:20:50 <koldbrutality> scons doesn't autodetect ccache
2018-02-07 13:57:04 <fcolista> bah
2018-02-07 13:57:22 <fcolista> no way to compile qt5 5.10 with libressl
2018-02-07 14:20:02 <ncopa> fcolista: qt 5.10 does not support libressl?
2018-02-07 14:20:32 <fcolista> nope...and i can't find a patch to make it work
2018-02-07 14:21:29 <fcolista> tried to patch it but still having error on OPENSSL_STACK undeclared
2018-02-07 14:37:40 <PureTryOut[m]> same...
2018-02-07 14:38:06 <PureTryOut[m]> tried it, patch doesn't apply and trying to patch it manually still errors out
2018-02-07 14:41:20 <fcolista> PureTryOut[m], me too
2018-02-07 14:41:38 <fcolista> i need qt5 for gns4 and wireshark
2018-02-07 14:41:43 <fcolista> which crashed on qt5 as well
2018-02-07 14:41:57 <fcolista> Error relocating /usr/lib/libQt5Widgets.so.5: _ZN16QFileSystemEntry10isRootPathERK7QString: symbol not found
2018-02-07 14:48:56 <ncopa> i need to follow up on the bash hang bug
2018-02-07 14:49:08 <ncopa> which is not yet fixed for 32bit
2018-02-07 14:49:43 <ncopa> https://bugs.alpinelinux.org/issues/8447
2018-02-07 14:50:01 <ncopa> i also need get the s390x build complete and upload the packages properly :-/
2018-02-07 15:03:22 <fabled> ncopa, i'm looking at package upgrades
2018-02-07 15:03:29 <fabled> anything against https://github.com/alpinelinux/aports/pull/2964 ?
2018-02-07 15:03:39 <fabled> or https://github.com/alpinelinux/aports/pull/3053 ?
2018-02-07 15:11:41 <ncopa> im ok with upgrading wine
2018-02-07 15:12:00 <ncopa> im trying to figure out that bash hang bug
2018-02-07 15:12:12 <ncopa> apparently it still affects 32bit
2018-02-07 15:13:21 <ncopa> im ok with docker upgrade too
2018-02-07 15:17:03 <fabled> ok
2018-02-07 15:17:17 <fabled> how about the boost upgrade to 1.66.0 ?
2018-02-07 15:17:42 <ncopa> im ok as long as we rebuild everything needed at the same time
2018-02-07 15:17:55 <ncopa> it may require some work...
2018-02-07 15:17:58 <fabled> i see
2018-02-07 15:20:45 <ncopa> ocaml-csv build fails
2018-02-07 15:32:19 <kaniini> since we are doing mass rebuilds
2018-02-07 15:32:30 <kaniini> opinion on swapping openssl-dev back as default ssl (and keeping libressl-dev for things that use libtls etc)
2018-02-07 15:33:04 <kaniini> 2038 bug and increasing upstream API divergence are the main concerns
2018-02-07 15:45:00 <ncopa> re 2038 bug and libressl
2018-02-07 15:45:08 <przemoc> LibreSSL folks clearly state that they don't guarantee they will fully implement later OpenSSL APIs
2018-02-07 15:45:15 <przemoc> later than 1.0.1
2018-02-07 15:45:31 <ncopa> upstream libressl says its a problem in linux kernel, due to time_t being 32bit
2018-02-07 15:45:51 <ncopa> they will not work around that
2018-02-07 15:45:56 <kaniini> przemoc: that is not problem
2018-02-07 15:46:20 <kaniini> przemoc: there are *regressions* in the support of openssl 1.0.1 APIs
2018-02-07 15:46:32 <ncopa> which basically means we have to chose between: replace kernel or replace libressl
2018-02-07 15:46:42 <przemoc> kaniini: ok, so that's even worse than I thought.
2018-02-07 15:47:44 <kaniini> beyond that, libressl would still not be a valid provider of openssl because they do not follow upstream, imo
2018-02-07 15:48:06 <skarnet> that said, they're right when they say the 2038 bug is due to time
2018-02-07 15:48:09 <skarnet> _t being 32bit
2018-02-07 15:48:20 <skarnet> time_t needs to be 64-bit before 2038, there's no way around that
2018-02-07 15:48:59 <kaniini> while true
2018-02-07 15:49:01 <kaniini> it is being worked on upstream
2018-02-07 15:49:52 <przemoc> I meant that because not whole world switched to libressl, not supporting openssl APIs later than 1.0.1 can be bothersome to say the least and problem may increase in future.  but regressions in existing 1.0.1 API are much worse
2018-02-07 15:50:04 <kaniini> and they removed support for code that did work correctly (by using a structure instead of time_t)
2018-02-07 15:50:35 <kaniini> yeah, the major problem is the 1.0.1 regressions that have been introduced in later libressl releases
2018-02-07 15:51:29 <kaniini> i don't really have any opinion on libressl itself, i just do not think it is good to say "libressl is equivalent to openssl"
2018-02-07 15:52:09 <kaniini> my opinion on the openssl API is essentially "try to use anything else wherever possible"
2018-02-07 15:54:14 <ncopa> skarnet: its true, but its not an easy switch. will break ABI, so it is going to take time. kernel itself does not need to support y2038 yet, but certificate handling needs to handle it now
2018-02-07 15:54:14 <kaniini> (the time_t thing is one of several API regressions really)
2018-02-07 15:54:14 <ncopa> and we dont parse certificates in kernel
2018-02-07 15:54:15 <kaniini> probably the most painful though ;)
2018-02-07 15:54:15 <ncopa> so we need a temporary workaround til kernel time_t is fixed
2018-02-07 15:54:44 <przemoc> BTW is there any collective ticket regarding all these regression against openssl 1.0.1 found in libressl?
2018-02-07 15:54:49 <mitchty> is this telling me that the cross built gcc conflicts with gcc? https://gist.github.com/mitchty/38f099adb81268782ae6aa354e9aef55
2018-02-07 15:54:50 <kaniini> that one screws you at build time (if code used the calendar math structures) as well as runtime
2018-02-07 15:55:28 <ncopa> libressl upstreams response is "we dont support broken kernels" which translates to "we dont support linux"
2018-02-07 15:55:38 <kaniini> mitchty: yes basically
2018-02-07 15:56:01 <kaniini> which makes one wonder why bother with a libressl portable at all ;)
2018-02-07 15:56:02 <mitchty> if so, how exactly do I run bootstrap.sh as /usr/share/abuild/functions.sh looks for gcc when you source it in bootstrap.sh
2018-02-07 15:57:15 <kaniini> the issue is g++ not gcc
2018-02-07 15:57:15 <kaniini> ;)
2018-02-07 15:57:46 <kaniini> (more helpfully, your bootstrap.sh adventure should probably begin in a chroot)
2018-02-07 15:58:25 <ncopa> kaniini: +1 on the "libressl portable"
2018-02-07 15:58:25 <mitchty> looks like its more libstdc++
2018-02-07 15:58:41 <kaniini> so i think
2018-02-07 15:58:47 <kaniini> we should swap back
2018-02-07 15:58:51 <kaniini> keep libressl around for now, for libtls
2018-02-07 15:58:54 <kaniini> see if we can isolate it out
2018-02-07 15:59:12 <ncopa> fabled: what do you think about switching back to openssl?
2018-02-07 15:59:36 <ncopa> we need keep libressl around for a while yes
2018-02-07 15:59:51 <ncopa> should ask what void linux ppl thinks too
2018-02-07 16:01:35 <kaniini> i'm not sure what that has to do with anything but ok
2018-02-07 16:10:19 <kaniini> mitchty: yes, but g++ is what is pulling in libstdc++
2018-02-07 16:16:19 <mitchty> kaniini: right but it appears abuild depends on it as well, so I'm a bit unclear how i can bootstrap without abuild present
2018-02-07 16:20:31 <mitchty> example https://gist.github.com/mitchty/c711464d6f5f0436ba564909ccb797aa
2018-02-07 16:22:43 <mitchty> i'm a bit confused how a chroot will help in this regard, unless i just copy /usr|/bin|etc into the chroot and then run off an apk db that is mostly empty/lies?
2018-02-07 16:29:55 <fabled> ncopa, i'm not sure on openssl. but it seems akamai picked up openssl and it has significant development since.
2018-02-07 16:30:23 <fabled> otoh, libressl went ahead to delete stuff like the engine api so it's slowly becoming more limited on what it can do
2018-02-07 16:30:39 <fabled> so it might be an idea to revisit the question... or at least to reply something on the mailing list thread
2018-02-07 17:31:00 <AWilcox[m]> mitchty, that tripped me up for months
2018-02-07 17:31:12 <AWilcox[m]> mitchty, then I realised: the issue there is you have -r5 installed on your host and -r6 as your cross.
2018-02-07 17:31:33 <AWilcox[m]> mitchty, if all the -rX match, it DOES work
2018-02-07 17:34:04 <mitchty> AWilcox[m]: O.O that... is super unintuitive thanks, guess I need to update from edge then
2018-02-07 17:38:16 <mitchty> AWilcox[m]: wow, first time i'm seeing bootstrap.sh get to building the kernel, danke
2018-02-07 17:39:25 <tmh1999> mitchy: cool, but I thought fabled already made the aarch64 cross- work done ?
2018-02-07 17:39:59 <mitchty> tmh1999: i'm trying to get ghc building for all the other arches
2018-02-07 17:40:39 <tmh1999> mitchy: ah ghc. it's been for a while, isn't it
2018-02-07 17:41:31 <tmh1999> kudo to fabled made the bootstrap.sh and apk-tools, abuild so clean for cross-compiling
2018-02-07 17:41:37 <mitchty> tmh1999: yeah, and i hit bugs with armhf for 8.2.2 due to ... something but for now 8.0.2 is cross compilable similar to how I got it onto AL originally
2018-02-07 17:42:31 <mitchty> basically its like go, build first compiler then build off that natively, i'm wanting to make sure it all works
2018-02-07 17:43:04 <mitchty> plus people were asking for 32bit x86, and i wanted 64 bit arm as well so might as well kill all those birds while i'm at it
2018-02-07 17:43:17 <mitchty> and ppc i suppose if/when i get to it
2018-02-07 17:45:47 <mitchty> unless there is an easier way to go about this i'm unaware of
2018-02-07 17:53:16 <Aerdan[m]> adélie has been working on x32. unfortunately, llvm is kinda a stumbling block due to the single-.so build being >4GB (in part due to insisting on leaving in debug symbols)
2018-02-07 19:41:58 <AWilcox[m]> Aerdan, that is solved
2018-02-07 19:42:08 <AWilcox[m]> Aerdan, we shipped llvm4 on x86 shortly after the parasites were gone
2018-02-07 19:42:31 <Aerdan[m]> oh. well then.
2018-02-07 19:42:31 <AWilcox[m]> mitchty, you're welcome :)  I had to stumble on it for almost three months
2018-02-07 19:42:45 <AWilcox[m]> mitchty, if you need ppc computer access let me know
2018-02-07 19:43:11 <AWilcox[m]> Aerdan, also fwiw x32 is "32-bit pointers on 64-bit".  x86 is "32-bit x86".  and x86_64 or x64 is "64-bit x86" (though x64 can be confused with Itanium, because Windows calls Itanium x64)
2018-02-07 19:44:09 <AWilcox[m]> mitchty, I have ppc32 and ppc64 (not ppc64le).  I can give you an account on the ppc32, it is basically available to any Alpine/Adelie person (at least skarnet and kaniini have accounts)
2018-02-07 19:47:44 <AWilcox[m]> Aerdan, anyway the way I solved it was very unclean but it did work fully.  I used 64-bit computer to compile it with the 32-bit binutils, so it used PAE or whatever and went right ahead and used up 6.1 GB.  then stripped it, down to 1 GB :)
2018-02-07 19:52:55 <Aerdan[m]> jeez.
2018-02-07 19:54:38 <Aerdan[m]> glad I don't have to deal with that mess, tbh.
2018-02-07 20:09:55 <ncopa> tmh1999: fftw tests seems to hang
2018-02-07 20:09:56 <ncopa> on s390x
2018-02-07 20:10:06 <tmh1999> ncopa : i saw that
2018-02-07 20:10:17 <ncopa> my guess is that it is related to openmp
2018-02-07 20:10:19 <ncopa> we had similar issue with imagemagick
2018-02-07 20:10:40 <ncopa> i ended up disable openmp for imagemagick on s390x
2018-02-07 20:32:05 <tmh1999> not sure if make -j1 helps, but i am building
2018-02-07 20:35:07 <ncopa> i dont think make -j1 will help
2018-02-07 20:35:32 <ncopa> i think its the openmp feature in gcc that is broken and deadlocks
2018-02-07 20:38:02 <ncopa> i disabled openmp in fftw on s390x
2018-02-07 20:38:05 <ncopa> would be nice to fix openmp though
2018-02-07 20:38:19 <ncopa> eg, fix gcc
2018-02-07 20:40:55 <tmh1999> ncopa: noted that. i will do the overhaul of the git log for s390x.
2018-02-07 20:42:22 <ncopa> i wonder if there are some libgomp testsuite
2018-02-07 20:42:28 <ncopa> we need a testcase to reproduce it
2018-02-07 20:42:43 <AWilcox[m]> GCC has a rather massive test suite of all of its libraries
2018-02-07 20:42:59 <ncopa> yeah
2018-02-07 20:43:01 <AWilcox[m]> Unfortunately, when I ran it on Adelie, about 12000 test cases out of the 39000 failed
2018-02-07 20:43:27 <ncopa> :)
2018-02-07 20:43:59 <AWilcox[m]> I may be dedicated to fixing upstreams but that was a bit much for my blood ;)
2018-02-07 20:44:37 <skarnet> what? that is disappointing XD
2018-02-07 20:47:14 <AWilcox[m]> Whoever runs the Matrix server, it seems to have the wrong timestamp.  I'm sending this message at 14:47:00
2018-02-07 20:47:20 <AWilcox[m]> Matrix says I sent it at 14:46
2018-02-07 20:47:31 <AWilcox[m]> Unless it's Quaternion bug again...
2018-02-07 20:50:05 <Aerdan[m]> looks like quaternion bug, I see 14:47 here on nheko.
2018-02-07 20:51:50 <AWilcox[m]> Nice.
2018-02-07 20:56:38 <AWilcox[m]> This is an interesting one.
2018-02-07 20:56:47 <AWilcox[m]> So this package has the GPL 2.0 license in ./COPYING.  It has an RPM spec file, which just says "GPL" for license.  None of the source files have a header of any kind.
2018-02-07 20:57:35 <AWilcox[m]> Does that make it GPL-2.0-only, or is it GPL-1.0+?
2018-02-07 20:58:25 <AWilcox[m]> I'm looking specifically at GPL 2.0 §9, which states:
2018-02-07 20:58:30 <AWilcox[m]> If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation.  If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.
2018-02-07 20:58:46 <AWilcox[m]> The Program does not specify a version number of the license in any place.
2018-02-07 21:00:06 <Aerdan[m]> I'd say GPL-2.0-only, given that the full text of GPL-2.0 is given in COPYING but no other hints are given.
2018-02-07 21:00:09 <przemoc> people sometimes refer to whatever GPL version by GPL, and in files like RPM spec, Makefiles and what not there are rarely any license notices.  what's in the source code's license notice should be determining factor here IMHO
2018-02-07 21:01:23 <AWilcox[m]> The source code has no license notice at all, not even that it is GPL.  Unless you mean the COPYING file, in which case I'm still not 100% sure specifically because of GPL 2 §9, but I guess GPL-2.0-only is a "safe" choice?
2018-02-07 21:03:49 <Aerdan[m]> I'd say GPL-2.0-only for now, and file a ticket with upstream asking them to please annotate their source with their license intentions.
2018-02-07 21:03:50 <AWilcox[m]> LIke I said, the COPYING file specifically states "you may choose any version ever published"
2018-02-07 21:04:22 <przemoc> COPYING (GPL 2.0 license) file alone does not determine if it's -only or -later variant, sadly.  if there is no license notice that clarifies authors intent, I believe that -later is what should be used (even though I'm not fan of that).
2018-02-07 21:05:03 <przemoc> s/-later/-or-later/ of course
2018-02-07 21:05:20 <AWilcox[m]> The author abandoned it in 2009
2018-02-07 21:06:37 <przemoc> so GPL 3 was already there and author did not explicitly reject optional upgrade
2018-02-07 21:10:29 <AWilcox[m]> 
ACTION sent a long message: AWilcox[m]_2018-02-07_21:10:28.txt <https://matrix.org/_matrix/media/v1/download/matrix.org/tsVBoIcsrBEYWhUOsHMHhHNe>

2018-02-07 21:10:30 <AWilcox[m]> I found this mailing list post from author in 2011
2018-02-07 21:10:31 <AWilcox[m]> It looks like it is GPL 2 only
2018-02-07 21:10:37 <przemoc> I really don't like this upgradeable feature of GPLv2, because it's messy, especially because not everyone puts license notices to make clear how they see this matter, and if they don't care, it's sadly another argument for going -or-later, because restrictions to v2 only are mostly added by people that care
2018-02-07 21:10:55 <AWilcox[m]> The person was asking if it could be used in a GPL3 project and author said no
2018-02-07 21:11:09 <przemoc> ok, that clarifies it
2018-02-07 21:11:16 <przemoc> as GPL-2.0-only
2018-02-07 21:11:31 <kaniini> i think that makes that clear then :)
2018-02-07 21:11:42 <AWilcox[m]> I will go ahead and put link to https://sourceforge.net/p/gtkspell/mailman/message/27291338/ in commit message
2018-02-07 21:13:46 <przemoc> but people should really add license notices, especially for GPL stuff.  even if it isn't canonical one (which is a bit verbose), in one line you can state whether it's GPL v2 "only" or "or later".
2018-02-07 21:15:18 <AWilcox[m]> I totally agree.  It's unfortunate we can't poke maintainers when they are writing code initially to do that :P
2018-02-07 21:16:51 <AWilcox[m]> "Guile is covered under the terms of the GNU Lesser General Public License, version 3 or later.  See COPYING.LESSER and COPYING."
2018-02-07 21:16:57 <AWilcox[m]> Which is the GPL, not the LGPL
2018-02-07 21:17:12 <AWilcox[m]> They ship GNU readline, which is GPL-3, as part of Guile's REPL
2018-02-07 21:17:25 <AWilcox[m]> But all of Guile's source code is LGPL
2018-02-07 21:17:28 <AWilcox[m]> Oh, I do love it when this happens.
2018-02-07 21:17:34 <AWilcox[m]> I think this is "GPL-3.0+ AND LGPL-3.0+"
2018-02-07 21:18:38 <AWilcox[m]> You can't really pull readline out of the binary to make it LGPL only, at least not without a recompile, so we couldn't split it out and make the split package GPL
2018-02-07 21:19:53 <przemoc> I wouldn't use AND, because part of the code uses one license, and other part uses another one.  that's why I suggested in my mail using <separator> (possibly ", " in practice) to not deal with it.
2018-02-07 21:22:52 <przemoc> I see AND and OR only as operators to state multi-licensing in statements like "This code is licensed under the terms of THIS and THAT" or "This code is licensed under the terms of THIS or THAT, whichever suits you better" put in license notices within source files
2018-02-07 21:24:55 <przemoc> having <separator> allow us to not think whether OR or AND is better in SPDX terms and if it will be clarified definitely by them ever, we'll be able to easily change such <separator> into whatever they want to be 100% conformant
2018-02-07 21:25:03 <kaniini> i suspect what we really need is to implement your proposal to bring copyright metadata file to alpine
2018-02-07 21:29:48 <AWilcox[m]> Maybe I should just not touch guile license field
2018-02-07 21:30:17 <AWilcox[m]> At least until the separator is agreed on, or we use the copyright metadata file
2018-02-07 21:30:55 <kaniini> use comma i think
2018-02-07 21:31:50 <AWilcox[m]> Okay
2018-02-07 21:33:37 <przemoc> temporarily tracking copyright can be done outside of aports, as I suggested, with scripts to integrate it into current license var.  sorry I'm a bit behind with it, but I have some other problems to deal with.  when aports will get better at handling properly structured data in future, because happy shell variables are not the best way forward, we will be able to reintegrate license info in better
2018-02-07 21:33:43 <przemoc> way, because we'll still be having it in uncluttered way, outside of APKBUILDs
2018-02-07 21:39:58 <przemoc> tbh I hoped there would be a bit more discussion on ML regarding fixing license mess effort, but it's can of worms, arduous task, and not really rewarding.  I really believe that it requires many eyeballs and I meant it strongly when I wrote that at least 3 people should verify the license of package before it will seem ok-ish and therefore ready to be also used in APKBUILD replacing what's already
2018-02-07 21:40:04 <przemoc> there in license field.
2018-02-07 21:41:44 <przemoc> I'm not sure, though, if I wrote the mail in the right moment, because it may seem now as I don't want to move it forward because of lack of concrete and visible actions regarding it.
2018-02-07 21:43:09 <AWilcox[m]> przemoc: I'm trying to throughly review, but since there was no agreement on # license looked at by:, there's not much beyond git blame
2018-02-07 21:43:43 <AWilcox[m]> I'd be more than willing to help with a more focused/obvious review later
2018-02-07 21:43:51 <przemoc> ok, good to hear that
2018-02-07 21:45:10 <kaniini> (right now we are just trying to make sure that $license is basically correct for the adelie supported package set, because we're greedy ;))
2018-02-07 21:45:48 <AWilcox[m]> Not so much greedy, just I'd have to fix everything /else/ in the other APKBUILDs too (spaces vs tabs, modernise, remove || return 1, replace dumb repeated patch logic with default_prepare, etc.)
2018-02-07 21:45:53 <AWilcox[m]> That'd leave me no time to actually bump and improve stuff :P
2018-02-07 21:47:46 <ollieparanoid[m]> if someone has time to review this: here's a PR to fix the git errors appearing when running abuild without git installed: https://github.com/alpinelinux/abuild/pull/32
2018-02-07 21:50:50 <przemoc> I can understand that too, kaniini.  Adelie has its own agenda.  my idea of doing this work outside of aports and APKBUILDs may not seem appealing to many, especially in AL community, I presume, as it may seem as not AL-oriented enough.  but maybe when I'll have time do initial tasks of writing scripts and having some packages done, then maybe it will be easier to find more people supporting the
2018-02-07 21:50:56 <przemoc> idea and willing to help, even outside of AL, because I believe it may benefit all distributions out there
2018-02-07 21:52:15 <Aerdan[m]> well, it's more that they're focused on adelie right now due to wanting to ensure alpine community/ can be used with adelie safely.
2018-02-07 21:52:36 <Aerdan[m]> which is involving a lot of commit-shoveling.
2018-02-07 21:53:33 <Aerdan[m]> and if they're busy doing that they might as well tackle licensing on the packages they're working on. ;)
2018-02-07 21:54:36 <AWilcox[m]> It's not just for community/.  It is so that we can regularly contribute more often.  A lot of these changes have been since September or even before.  I whipped through the system set faster than Alpine could handle PRs and we didn't have a good flow of how to send PRs in so these changes piled up quickly.  And now when we (Adelie) try to pull from Alpine there are hundreds(!) of merge conflicts.
2018-02-07 21:54:48 <AWilcox[m]> This effort is designed to replace all of that crappy workflow with a nice one where as we make changes, we just send simple PR to Alpine, instead of carrying it for so long
2018-02-07 23:41:25 <przemoc> damn, looks like I'm screwed a bit.  after `apk upgrade` I got:  http://ix.io/Fsc  first thought was that mkinitfs's trigger should have better design, i.e. overwrite existing files only after successfully creating them.  second thought is worse, though: I'm possibly experiencing some memory errors (notice jernel for instance) - it's my best guess right now.  earlier I was wondering why gcc failed
2018-02-07 23:41:31 <przemoc> with -march something that wasn't even present in command-line...
2018-02-07 23:42:27 <przemoc> memory errors may possibly explain another "good" (/var/log/) message I found: http://ix.io/Fsd
2018-02-07 23:47:13 <AWilcox[m]> cpio: lib/modules/4.9.33/kernel/dviverscsi/s#sim/`.ko: No such file or directory
2018-02-07 23:47:41 <AWilcox[m]> This should be lib/modules/4.9.33/kernel/drivers/scsi/sim
2018-02-07 23:47:42 <AWilcox[m]> Something's definitely wonky
2018-02-07 23:52:51 <przemoc> uptime is only 107 days, and not sure of total uptime of this hardware, but it's less than 2 years for sure; most parts were bought in December 2014, some later, everything was fully assembled around 2015Q4 and I finally replaced old server in April 2016 (or later), so it's still quite young, too young to be failing on me.
2018-02-07 23:53:11 <przemoc> damn it
2018-02-07 23:53:28 <AWilcox[m]> Looks like maybe disk stuff
2018-02-07 23:55:20 <przemoc> but then standard gcc -c wouldn't fail with   Fatal error: invalid -march= option: `CV'   where last part can differ: `C' `CV' `Ck"V' `C[xV' etc.
2018-02-07 23:58:37 <przemoc> I definitely need reboot for fsck at least, but should do it on other hardware, yet I'm not sure my initramfs is even usable at this point
2018-02-08 00:04:21 <przemoc> it's late, don't have time to deal with it now, and have other problems queued tomorrow to deal with too.  why it had to hit my home server/router in particular...  hopefully there won't be any power outage until I'll have time to deal with this mess.
2018-02-08 00:04:30 <przemoc> sorry for the rant, I got OT here
2018-02-08 02:48:59 <mepholic> what's everyone's stance on apkbuilds which force a package to build with clang?
2018-02-08 02:49:33 <mepholic> I've run into a piece of software that doesn't play nice with gcc's gomp, but works fine with clang's openmp implementation
2018-02-08 02:57:42 <koldbrutality> heh xchat doesn't have a desktop menu icon
2018-02-08 03:23:38 <AWilcox[m]> Disable OpenMP.
2018-02-08 03:23:40 <AWilcox[m]> It's been giving issues on s390x as well
2018-02-08 18:01:40 <mmlb> what ever happened to the mkinitfs fork that was trying to be sort of `ng` of it? Where one could build a complete ramfs that would have embedded packages and files and such?
2018-02-08 18:16:44 <mmlb> oh it was TemptorSent's mkimage stuff that was abonded :(
2018-02-08 18:17:05 <mmlb> *abandoned
2018-02-08 20:28:14 <koldbrutality> it would be nice if abuild could scan for missing licenses before signing the package.
2018-02-08 20:28:42 <koldbrutality> and more quality control checks like missing .desktop files for gui apps
2018-02-08 20:30:15 <koldbrutality> and more q/a check if games are marked as group permission
2018-02-08 20:33:18 <koldbrutality> and also scan source code for potential suspicious payloads or privacy invasion
2018-02-08 20:35:34 <kaniini> it would also be nice if abuild could also make me a sandwich and clean my house
2018-02-08 20:35:44 <koldbrutality> heh
2018-02-08 20:37:55 <kaniini> (what you are looking for is a linter, and yes, somebody should write one)
2018-02-08 20:38:18 <kaniini> (but linting shouldn't be the responsibility of abuild itself, abuild should stick to building packages)
2018-02-08 20:38:43 <koldbrutality> it does do some checks but too minimalist
2018-02-08 20:39:43 <kaniini> yes, this is probably because linting should be the responsibility of some other tool
2018-02-08 21:50:37 <Shiz> 21:33:18 koldbrutality : and also scan source code for potential suspicious payloads or privacy invasion lol no
2018-02-08 21:51:19 <koldbrutality> i remember i was working with a word pressplugin and it had obfuscated payload...
2018-02-08 21:54:02 <koldbrutality> i was packaging another software called ramme instagram client and it had use google analytics to do usage check... some might consider that invasion of privacy
2018-02-08 21:55:23 <koldbrutality> for the obfuscated payload i think it was base64 encoded and was used for advertising
2018-02-08 21:57:55 <koldbrutality> i'm pretty sure apple does code auditing before they put the product on their software store
2018-02-08 21:59:55 <koldbrutality> or some way to detect if it is not malicious
2018-02-08 23:26:17 <kaniini> the alpine package repos are not the app store
2018-02-08 23:39:58 <AWilcox[m]> The Apple App Store has a 37 page agreement that you have to sign before you can put your apps on there; app developers publish their apps on it directly; and Apple have a legal team that has more funding than most countries' governments.
2018-02-08 23:40:12 <AWilcox[m]> I agree that there should be a linter, but it should not be a code linter.
2018-02-09 01:39:17 <tmh1999> ncopa: isn't it too late for you to be online ? btw, a commit to disable fftw s390x was merged, but the build-edge-s390x is hanged atm. Would you mind logging in and break the hang process, please ?
2018-02-09 01:40:54 <danieli> tmh1999: a couple days ago, he wasn't in GMT+1 :)
2018-02-09 01:41:01 <tmh1999> ncopa: thanks \o/
2018-02-09 01:41:33 <ncopa> tmh1999: seems like it still hangs in long-double tests of fftw
2018-02-09 01:42:03 <ncopa> maybe we should disable tests til its figured out?
2018-02-09 01:42:27 <tmh1999> ncopa: yeah it hang. I remember about IBM long-double conversation sometimes ago. I will readdress that. I disabled fftw in a recent commit.
2018-02-09 01:43:14 <ncopa> i think it will break things like alsa
2018-02-09 01:43:15 <ncopa> which depend on it
2018-02-09 01:43:30 <tmh1999> yeah alsa-utils
2018-02-09 01:43:31 <ncopa> but ok, we need the builder complete and upload the packages
2018-02-09 01:43:44 <tmh1999> just alsa-utils
2018-02-09 01:43:52 <ncopa> ok
2018-02-09 01:44:24 <danieli> is it about strtold()?
2018-02-09 01:44:49 <ncopa> dunno
2018-02-09 01:47:29 <tmh1999> only main/alsa-utils and 2-3 packages in community/ depends on fftw. without circle reverse-dependencies. which is fine.
2018-02-09 01:48:27 <danieli> or rather, *told()
2018-02-09 01:49:39 <danieli> iirc there's a wcstold() and a strtold()
2018-02-09 01:50:30 <tmh1999> cpan.org is down. wow.
2018-02-09 01:50:43 <danieli> tmh1999: it's up for me
2018-02-09 01:50:53 <tmh1999> *search.cpan.org
2018-02-09 01:51:12 <ncopa> weird indeed
2018-02-09 01:51:19 <danieli> tmh1999: still works for me :P
2018-02-09 01:51:43 <tmh1999> maybe the s390x builder is also in ny
2018-02-09 01:51:55 <danieli> says it's down on downforeveryoneorjustme.org
2018-02-09 02:54:14 <tmh1999> I thought the builder was configured to continue despite having an error.
2018-02-09 04:37:37 <Aerdan[m]> don't rely on search.cpan.org, use other mirrors.
2018-02-09 04:37:49 <kaniini> heyyyyy tmh1999
2018-02-09 04:37:58 <kaniini> you wanna take a crash course through s390x assembly
2018-02-09 04:38:07 <Aerdan[m]> the perl community has no control over search.cpan.org so it'll go down without warning.
2018-02-09 04:38:12 <kaniini> http://github.com/kaniini/libucontext you should make this work on s390x
2018-02-09 04:38:20 <kaniini> could probably write a paper on it
2018-02-09 04:38:21 <kaniini> get published
2018-02-09 04:38:26 <kaniini> i think its a good idea man
2018-02-09 04:38:31 <kaniini> mostly because i don't wanna
2018-02-09 04:39:34 <tmh1999> kaniini: I'll see what I can do
2018-02-09 04:39:40 <tmh1999> interesting
2018-02-09 04:39:57 <tmh1999> kind of surprised when you mention publication lol
2018-02-09 04:40:32 <kaniini> i am just bullshitting you, i don't think you can write a paper on "implementing context switching for the musl C library"
2018-02-09 04:40:34 <kaniini> (but if you can, go for it)
2018-02-09 04:40:39 <tmh1999> seems like everyone mistaken me with the researcher on IBM Watson, hum ...
2018-02-09 04:40:50 <tmh1999> yeah I can smell that though ..
2018-02-09 04:41:01 <Xe> it'd at least get you updoots on hacker news and reddit
2018-02-09 04:41:03 <kaniini> but we do need it for s390x
2018-02-09 04:41:10 <kaniini> it's the only thing blocking me putting it in alpine
2018-02-09 04:41:20 <kaniini> (mips support would also be cool, but i think i can manage that one myself)
2018-02-09 04:41:52 <tmh1999> kaniini: yep. I'll see but I cant guarantee. Maybe you should also send an email to musl list. Bobby Bingham is the guy ported musl to s390x
2018-02-09 04:42:07 <kaniini> i dont want to announce it there yet :D
2018-02-09 04:42:16 <kaniini> dalias is going to be like
2018-02-09 04:42:17 <kaniini> wow
2018-02-09 04:42:20 <kaniini> this is really ghetto kaniini
2018-02-09 04:42:41 <kaniini> you totally did not care about some specific POSIX nuance
2018-02-09 04:44:28 <tmh1999> kaniini: I bet Bobby would finish this task like a blink of an eye. save you, save me
2018-02-09 04:44:55 <tmh1999> not that I don't want to, just that if I do it, it's gonna take *a lot* of time
2018-02-09 04:45:14 <tmh1999> time is expensive for you, I guess, in this case
2018-02-09 04:47:19 <tmh1999> wow seems like you have almost every arch.
2018-02-09 04:48:11 <tmh1999> this is interesting
2018-02-09 04:53:25 <koldbrutality> it's so hard to debug this now.  if I run abuild and it says error it should tell me the line number but it doesn't have this feature.
2018-02-09 05:31:55 <_ikke_> koldbrutality: abuild is just a shell script where the APKBUILD is sourced
2018-02-09 05:32:07 <_ikke_> koldbrutality: abuild does not parse APKBUILDs or anything
2018-02-09 06:30:40 <danieli> the parser is the shell :P
2018-02-09 06:41:32 <fcolista> morning guys
2018-02-09 06:49:55 <danieli> good morning
2018-02-09 07:26:07 <zenny> Good morning. h2o still is at 2.2.0 in edge/community whereas there was 2.4 security patched version has been released. It seems like cherokee webserver has been abandoned because https://wiki.alpinelinux.org/wiki/Cherokee does not work anymore, nor there is any packages available.
2018-02-09 07:28:03 <danieli> cherokee seems pretty darn dead, and hmm, I'll check h2o
2018-02-09 07:30:00 <danieli> haven't heard h2o mentioned in a long long time
2018-02-09 07:30:31 <danieli> zenny: 2.2.4 is the latest version according to https://github.com/h2o/h2o/releases
2018-02-09 07:31:37 <danieli> and see https://pkgs.alpinelinux.org/packages?name=h2o&branch=edge
2018-02-09 07:40:24 <zenny> @danieli: my bad oversight. I was referring to 2.2.4 which fixes two vulnerablity (Version 2.2.4 has been released with two vulnerability fixes #1543 and #1544 from https://h2o.examp1e.net/index.html (at the bottom)
2018-02-09 07:42:25 <zenny> @danieli: lo and behold, now it has been updated!
2018-02-09 07:42:28 <zenny> :D
2018-02-09 07:42:41 <zenny> What about cherokee webserver?
2018-02-09 07:42:54 <danieli> it doesn't seem to be maintained upstream
2018-02-09 07:43:10 <danieli> also, protip, don't prefix usernames with "@" on IRC - it means channel operator here :)
2018-02-09 07:44:04 <danieli> zenny: looks like h2o was updated in December
2018-02-09 07:44:16 <danieli> built 19th Dec. 2017
2018-02-09 07:45:38 <zenny> danieli: apk search was pointeing to h2o-2.2.3-r3 before I asked and now it gives the correct version.
2018-02-09 07:46:06 <zenny> reverseproxy:~# apk search h2o
2018-02-09 07:46:06 <zenny> h2o-dev-2.2.3-r3
2018-02-09 07:46:06 <zenny> h2o-2.2.3-r3
2018-02-09 07:46:06 <zenny> h2o-doc-2.2.3-r3
2018-02-09 07:46:07 <danieli> you didn't happen to run `apk update' before you did `apk search'?
2018-02-09 07:46:59 <zenny> I did apk update && apk upgrade and then apk search by enabling all repos main/edge/testing/community
2018-02-09 07:47:27 <danieli> strange. I was thinking it was caching or giving old results for some other reason
2018-02-09 07:47:32 <danieli> 2.2.4 was built in december anyway
2018-02-09 07:47:57 <zenny> yep, cache could be the reason.
2018-02-09 10:26:58 <fcolista> anywone have been able to make wine work with alpine x86_64?
2018-02-09 10:28:21 <danieli> there is a wine package, not sure if it works or not though
2018-02-09 10:28:39 <danieli> ncopa might
2018-02-09 10:28:47 <fcolista> I'm referring to that package
2018-02-09 10:29:14 <danieli> ah okay. well, in that case, I'm no help. I usually stay away from wine and use VMs instead
2018-02-09 10:30:39 <fcolista> yeah..but for simple exe it's an overkill..
2018-02-09 10:30:55 <danieli> usually, yeah. old habits die hard I guess
2018-02-09 10:35:37 <fcolista> that's due to wine64 does not run 32bit executable
2018-02-09 10:36:00 <danieli> yeah, no WOW64
2018-02-09 10:36:25 <fcolista> most of the executables are still compiled 32bit
2018-02-09 10:36:26 <fcolista> uff
2018-02-09 10:36:30 <danieli> oof
2018-02-09 12:24:30 <fcolista> So appears to me that qt5 5.10 upgrade is blocked by libressl > openssl 1.1 switch
2018-02-09 12:24:47 <fcolista> qt5 5.10 introduces openssl 1.1
2018-02-09 12:25:15 <fcolista> and openssl 1.1 is not compatible with libressl /o\
2018-02-09 12:44:39 <Aerdan[m]> no, Qt 5.10 is blocked by not being an LTS release.
2018-02-09 12:50:57 <fcolista> Aerdan[m], no
2018-02-09 12:51:08 <fcolista> I'm talking about edge
2018-02-09 12:51:18 <fcolista> and we have 5.9.x
2018-02-09 12:51:37 <fcolista> but before we had 5.8
2018-02-09 12:51:43 <fcolista> which was not lts
2018-02-09 12:51:59 <danieli> edge is edgy
2018-02-09 12:52:16 <fcolista> qt5.10 is blocked by ssl, sadly
2018-02-09 12:52:38 <Aerdan[m]> before we did not have a downstream packaging KDE.
2018-02-09 12:53:19 <fcolista> where do we have kde ?
2018-02-09 12:53:42 <fcolista> If olliparanoid is fine, we can upgrade qt 5.10
2018-02-09 12:53:57 <fcolista> is only matter of let them know and an agreement
2018-02-09 12:54:01 <fcolista> but this is /not/ a blocker
2018-02-09 12:54:12 <fcolista> we don't have kde on alpine yet
2018-02-09 12:54:26 <danieli> adelie is not fine with non-LTS Qt, pmOS is, they'd like it
2018-02-09 12:54:26 <Aerdan[m]> it's not just pmOS, though. we also have Adelie, which provides a KDE desktop.
2018-02-09 12:55:44 <Aerdan[m]> more than that, Adelie is busy reducing the deleta between them and Alpine wrt aports, so as to make it easier for contributrs to one to be able to contribute to the other.
2018-02-09 12:55:51 <Aerdan[m]> delta*
2018-02-09 12:55:56 <fcolista> Sure
2018-02-09 12:56:25 <fcolista> still we have a problem now with qt5
2018-02-09 12:57:38 <fcolista> wireshark and gns3 are not working
2018-02-09 17:31:14 <ncopa> tmh1999: the list of packages that failed to build on s390x: http://tpaste.us/5Yk0
2018-02-09 17:31:15 <ncopa> i think we need to fix the kernel build to be able to have a working wireguard
2018-02-09 18:21:46 <tmh1999> ncopa : how do you mean the kernel build ?
2018-02-09 18:21:56 <tmh1999> oh
2018-02-09 18:22:18 <tmh1999> yeah, kernel build ?
2018-02-09 18:25:16 <ncopa> i may been wrong about that
2018-02-09 18:25:16 <ncopa> yeah, linux-vanilla-4.14.17 is built
2018-02-09 18:26:16 <tmh1999> yeah, also, some of these packages in community/ in above list are already disabled, btw.
2018-02-09 18:29:29 <AWilcox[m]> I wish the threads I opened on alpine-devel ML got even half this much attention haha
2018-02-09 18:29:53 <skarnet> get a troll in your threads
2018-02-09 18:29:57 <skarnet> you'll get the attention
2018-02-09 18:30:04 <skarnet> but be careful what you wish for
2018-02-09 18:30:24 <ncopa> tmh1999: im gonna clean it up
2018-02-09 19:15:21 <Fusl> 2018-01-09 11:15:01     @fabled Fusl, default stack size assumption is one of the most common things we need to fix when porting to musl
2018-02-09 19:15:33 <Fusl> anyone available for a quick explanation how this should be implemented?
2018-02-09 19:16:01 <Fusl> one of my software packages (testing/motion) throws this every now and then:
2018-02-09 19:16:04 <Fusl> [500434.749159] motion[11585]: segfault at 790fecf85bb0 ip 0000790fecd52b6c sp 00007acf0f5927c0 error 6 in ld-musl-x86_64.so.1[790fecd02000+89000]
2018-02-09 19:16:05 <Fusl> [500434.749172] grsec: From 10.240.241.0: Segmentation fault occurred at 0000790fecf85bb0 in /usr/bin/motion[motion:11585] uid/euid:101/101 gid/egid:27/27, parent /bin/busybox[init:1] uid/euid:0/0 gid/egid:0/0
2018-02-09 19:16:07 <Fusl> [500434.749230] grsec: From 10.240.241.0: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/bin/motion[motion:11585] uid/euid:101/101 gid/egid:27/27, parent /bin/busybox[init:1] uid/euid:0/0 gid/egid:0/0
2018-02-09 19:16:15 <Fusl> which i believe is due to the "default stack size assumption"
2018-02-09 19:32:57 <skarnet> Fusl: http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_attr_setstacksize.html
2018-02-09 19:33:24 <skarnet> basically, look for every occurrence of pthread_create() in the code, and patch it so pthread_create is always invoked with an attr argument
2018-02-09 19:33:53 <skarnet> and before calling pthread_create(), call pthread_attr_setstacksize() on the attr, to explicitly set the stack size you want
2018-02-09 19:34:21 <skarnet> so when the thread is created, it will use the stack size you gave, instead of the default
2018-02-09 19:41:55 <Fusl> skarnet: thank you very much! ill take a look into it and hopefully get it fixed
2018-02-09 19:42:34 <skarnet> `np :)
2018-02-09 19:43:56 <skarnet> if pthread_create() wasn't invoked with an attribute argument before, you'll need to pthread_attr_init() first, and pthread_attr_destroy() after
2018-02-09 19:44:38 <skarnet> it goes more or less like this:
2018-02-09 19:48:09 <skarnet> pthread_attr_t attr ; int e = pthread_attr_init(&attr) ; if (e) error-out ; e = pthread_attr_setstacksize(&attr, yourstacksize) ; if (e) error-out ; e = pthread_create(yourthread, &attr, yourfunction, yourarg) ; if (e) error-out ; pthread_attr_destroy(&attr) ;
2018-02-09 19:56:06 <koldbrutality> dang dataloss :'(
2018-02-09 19:56:40 <koldbrutality> i blame firefox 58.x for locking up the computer
2018-02-09 19:57:46 <koldbrutality> i was working on this APKBUILD since yesterday and now it is blank
2018-02-09 20:00:41 <ncopa> koldbrutality: ouch! :-(
2018-02-09 20:00:41 <Fusl> koldbrutality: some editors write .save or .swap/.swp files to restore unsaved changes from
2018-02-09 20:01:04 <HRio> hmm is travis really building now? "No packages found to be built." https://travis-ci.org/alpinelinux/aports/builds/339603344?utm_source=github_status&utm_medium=notification
2018-02-09 20:02:36 <HRio> this PR https://github.com/alpinelinux/aports/pull/3248
2018-02-09 20:02:42 <kaniini> fcolista: we tested Qt 5.10 in adelie and it's not ready to go
2018-02-09 20:02:56 <kaniini> there's a lot of bugs verses 5.9
2018-02-09 20:03:10 <kaniini> fcolista: if you are having a problem with GNS3, let me know and i will fix it to work with qt 5.9
2018-02-09 20:03:42 <PureTryOut[m]> kaniini: hmm do you have the APKBUILDs anywhere? it this with LibreSSL replaced by OpenSSL?
2018-02-09 20:04:26 <kaniini> PureTryOut: yes, we already did the openssl transition in adelie a while ago
2018-02-09 20:06:03 <PureTryOut[m]> ah ok
2018-02-09 20:09:21 <ncopa> oh looks like time_t in libressl is fixed
2018-02-09 20:10:00 <ncopa> https://github.com/libressl-portable/openbsd/commit/362ffef32c0fcae703d57838e9f5704240a63213
2018-02-09 20:16:09 <kaniini> it's not
2018-02-09 20:16:16 <kaniini> that fix is wrong
2018-02-09 20:16:30 <kaniini> all it does is say "oh, the date is past year 2038 it must be ok!"
2018-02-09 20:17:33 <ncopa> should buy us enough time til its fixed in kernel
2018-02-09 20:18:01 <kaniini> and the regressions verses 1.0.1g?
2018-02-09 20:18:19 <ncopa> will need to look closer at those
2018-02-09 20:18:47 <ncopa> i dont think we should rush it in any case
2018-02-09 20:19:59 <ncopa> lets fix the kernel first
2018-02-09 20:20:25 <kaniini> i have no objection to fixing the kernel first, but i feel like we are actually better off with openssl 1.1
2018-02-09 20:20:32 <kaniini> for many reasons
2018-02-09 20:20:40 <ncopa> might be
2018-02-09 20:20:59 <ncopa> my biggest worry was the time_t issue
2018-02-09 20:21:03 <ncopa> and their reaction to it
2018-02-09 20:21:22 <kaniini> my second worry is "what happens when there is a math error in the assembler code, can they fix it"
2018-02-09 20:21:59 <kaniini> does theo de raadt know how to solve montgomery squares
2018-02-09 20:22:01 <ncopa> we had an issue already with nginx where libressl broke stuff
2018-02-09 20:22:17 <ncopa> so i do think that is a good point
2018-02-09 20:22:47 <kaniini> openssl have actual cryptographers working on it, libressl does not as far as i know
2018-02-09 20:23:27 <kaniini> it is not like one is really truly any better than the other, the security problems of openssl usually come from the fact that you're shooting yourself in the foot
2018-02-09 20:23:57 <ncopa> i understand that none are good really
2018-02-09 20:24:44 <ncopa> i also think its not good to switch every year, go back and forth
2018-02-09 20:25:04 <ncopa> openssl will likely save us for a lot work
2018-02-09 20:25:07 <kaniini> i agree with that
2018-02-09 20:26:00 <kaniini> i just don't think libressl is the way to go, especially with more archs being added to alpine (mips port for example)
2018-02-09 20:26:09 <kaniini> have openbsd even tested their changes on those archs
2018-02-09 20:26:15 <kaniini> (admittedly have openssl?)
2018-02-09 20:26:37 <ncopa> at least libressl works for now
2018-02-09 20:26:44 <ncopa> with time_t issue it wasnt even working..
2018-02-09 20:26:47 <kaniini> last year, i would agree that libressl is way to go.  but openssl situation has gotten a lot better since then.
2018-02-09 20:27:20 <ncopa> let us think about it
2018-02-09 20:27:37 <mepholic> I, for one, support the move back to openssl
2018-02-09 20:28:02 <mepholic> libressl has solely been the biggest pain in my ass out of all of the things in alpine
2018-02-09 20:28:18 <ncopa> i'd like fabled have a look at openssl state
2018-02-09 20:28:24 <mepholic> which is interesting considering we use a "non-standard" libc
2018-02-09 20:28:35 <ncopa> heh
2018-02-09 20:28:35 <mepholic> you'd think that'd be more likely to have issues :P
2018-02-09 20:28:39 <ncopa> lol
2018-02-09 20:28:54 <ncopa> thats pretty interesting
2018-02-09 20:29:37 <mepholic> anyways, I feel like musl is proof that you can make better things without breaking API compatibility
2018-02-09 20:29:45 <mepholic> I know the story for openssl is different
2018-02-09 20:29:51 <mepholic> because the API is part of the problem
2018-02-09 20:29:57 <kaniini> ncopa: i mean, lets be honest here too.  the libressl transition was half done anyway
2018-02-09 20:30:12 <ncopa> mpeholic: *nod*
2018-02-09 20:30:16 <kaniini> the VPN software is still basically on openssl because of ENGINE
2018-02-09 20:31:05 <ncopa> i didnt think ENGINE was a big problem anymore
2018-02-09 20:31:08 <ncopa> but i may be wrong
2018-02-09 20:31:10 <mepholic> that's another huge bummer to me, is lack of ENGINE in libressl
2018-02-09 20:31:18 <mepholic> as I use alpine on lots of routers
2018-02-09 20:31:32 <kaniini> ncopa: it's a big problem if you are running a VPN concentrator
2018-02-09 20:31:47 <ncopa> doesnt libressl support AES-NI?
2018-02-09 20:32:00 <kaniini> it's "not a big problem" because the openssl package was dropped
2018-02-09 20:32:02 <kaniini> er wasn't
2018-02-09 20:32:03 <ncopa> intel
2018-02-09 20:32:04 <ncopa> ok
2018-02-09 20:33:09 <kaniini> yes, libressl support AES-NI
2018-02-09 20:33:13 <kaniini> but ENGINE is about the geode
2018-02-09 20:33:13 <kaniini> and crypto accelerator cards
2018-02-09 20:33:21 <kaniini> that too yes
2018-02-09 20:33:21 <ncopa> via padlock
2018-02-09 20:33:59 <mepholic> right
2018-02-09 20:34:05 <mepholic> and people like their pcengines boxes
2018-02-09 20:34:09 <ncopa> not so commone hw as i understand
2018-02-09 20:34:10 <mepholic> <-
2018-02-09 20:34:14 <kaniini> my point is, in practice there's a lot of installs with both openssl and libressl installed anyway
2018-02-09 20:34:29 <ncopa> nodejs is other problem
2018-02-09 20:34:33 <mepholic> ncopa: https://www.pcengines.ch/apu.htm
2018-02-09 20:34:33 <ncopa> not ported to libressl
2018-02-09 20:35:02 <mepholic> i chose to buy an apu2
2018-02-09 20:35:08 <mepholic> and spend more money than I needed to
2018-02-09 20:35:14 <mepholic> SPECIFICALLY because of libressl
2018-02-09 20:35:15 <ncopa> i use apu2 at home
2018-02-09 20:35:26 <mepholic> same
2018-02-09 20:36:04 <AWilcox[m]> "LibreSSL is API compatible with OpenSSL 1.0.1, but does not yet include all new APIs from OpenSSL 1.0.2 and later. LibreSSL also includes APIs not yet present in OpenSSL. The current common API subset is OpenSSL 1.0.1."
2018-02-09 20:36:05 <AWilcox[m]> This is direct from their README
2018-02-09 20:36:08 <AWilcox[m]> And it's a lie
2018-02-09 20:36:19 <AWilcox[m]> I still don't know why we want something that lies in our base distribution
2018-02-09 20:36:28 <kaniini> that lie is essentially why we don't use libressl in adelie
2018-02-09 20:36:28 <AWilcox[m]> Like, LibreSSL is required to use Alpine; apk-tools uses it
2018-02-09 20:36:50 <mepholic> ncopa: I find it sort of silly that libressl is 'preventing' me from using lower end systems
2018-02-09 20:37:17 <mepholic> for things they'd be perfectly suited for if the software supported the hardware
2018-02-09 20:37:29 <ncopa> understand
2018-02-09 20:37:29 <kaniini> awilfox: yes/no.  we only need libcrypto for apk-tools really, and we could use cryptlib for that :)
2018-02-09 20:37:57 <kaniini> mepholic: well can you write to the list and express your view :)
2018-02-09 20:38:02 <skarnet> or even bearssl XD
2018-02-09 20:38:10 <kaniini> that was the whole point of the thread
2018-02-09 20:38:19 <mepholic> that means I have to sign up for the list!
2018-02-09 20:38:19 <kaniini> the "i can do it next week" is just because i literally have that capability: we have the patches right now
2018-02-09 20:38:26 <mepholic> my sieve filters are busted right now :(
2018-02-09 20:38:27 <AWilcox[m]> The other thing is LibreSSL will never use optimised routines on POWER architecture, because their ppccpuid.c - even in portable - checks an OpenBSD sysctl path for altivec support.  It of course never succeeds on Linux.
2018-02-09 20:39:18 <mepholic> all in all, I think that libressl is having negative impacts on the portability and embeddability of alpine
2018-02-09 20:39:43 <mepholic> especially to some of the systems that would be most suited to use alpine on
2018-02-09 20:39:53 <skarnet> embeddability is not an argument
2018-02-09 20:40:10 <skarnet> if you wanna do embedded, you don't use LibreSSL, but you don't use OpenSSL either... ideally
2018-02-09 20:40:21 <kaniini> i agree with skarnet.  if we're talking embedded, we're talking mbedTLS or bearssl or something
2018-02-09 20:40:22 <mepholic> well yeah sure
2018-02-09 20:40:43 <ncopa> mepholic: i get your point
2018-02-09 20:40:58 <ncopa> if you have a lowend hw or old hw, what distro do you want to run?
2018-02-09 20:41:02 <mepholic> but even still, it makes it difficult to use alpine for 'general purpose usage on alternative architectures' as in AWilcox[m]'s case
2018-02-09 20:41:04 <AWilcox[m]> Except you have to use LibreSSL because Alpine apk-tools depends on it.  Unless you don't allow your embedded device to update itself, which I guess works fine for most IoT vendors.
2018-02-09 20:41:07 <kaniini> awilfox: well the other concern is that a lot of the asm routines have been rotting in libressl
2018-02-09 20:41:13 <mepholic> ncopa: alpine
2018-02-09 20:41:19 <mepholic> all day every day
2018-02-09 20:41:39 <mepholic> it's proven to be less thrashy and wasty with resources than pretty much any other 2018 distro
2018-02-09 20:41:45 <mepholic> :)
2018-02-09 20:41:46 <ncopa> so it makes sense alpine run on those devices
2018-02-09 20:42:19 <skarnet> AWilcox[m]: time to rewrite apk-tools with bearssl then :) I volunteer to do it some time this year.
2018-02-09 20:42:41 <kaniini> it should be noted that adelie was a huge proponent of libressl at the beginning too
2018-02-09 20:42:43 <kaniini> it got ripped out because we got tired of being burned
2018-02-09 20:42:44 <AWilcox[m]> Also to kaniini's question about MIPS: I don't know what testing OpenBSD does, but I know OpenSSL is used as the only SSL lib in OpenWRT and LEDE, which is running on a great number of MIPS boxes
2018-02-09 20:43:20 <AWilcox[m]> For all I know they do regression tests on MIPS.  They seem to be good about that.  But I don't know.  I certainly would doubt they test on Linux/mips.
2018-02-09 20:43:47 <kaniini> i'm glad they finally "fixed" time_t, but when we discussed it with them, they told us to just not use libressl on those systems
2018-02-09 20:43:55 <kaniini> i mean, there's a *lot* of reasons we gave up on libressl
2018-02-09 20:44:11 <mepholic> I think the important thing is that we tried
2018-02-09 20:44:34 <mepholic> nobody is happy with the state of openssl
2018-02-09 20:44:40 <mepholic> but some shit you just gotta live with
2018-02-09 20:45:02 <mepholic> there comes a point when productivity is more important than idealism
2018-02-09 20:45:03 <kaniini> (this was a private discussion because obviously "libressl does not validate certificate chains with roots expiring >2038 on 32-bit time_t" is a major security problem)
2018-02-09 20:45:26 <AWilcox[m]> If you look at the list I showed in the first email I sent in this thread, you'll note the number of patches that we(Alpine) *would not* have to maintain any more if there was a switch back to OpenSSL as well
2018-02-09 20:45:57 <kaniini> i mean, i'm okay with patching to make it work
2018-02-09 20:46:00 <kaniini> *if* libressl is worth it
2018-02-09 20:46:00 <AWilcox[m]> That's another big problem I feel.  Alpine should be focusing on innovating and porting to stuff like MIPS so it can be used there for routers and such.  Not focusing on keeping a bunch of patches maintained
2018-02-09 20:46:22 <ncopa> ok. maybe we will switch back to openssl. but not today.
2018-02-09 20:46:31 <ncopa> i will re-read the emails from awilfox a bit closer
2018-02-09 20:46:32 <kaniini> but being told to simply not use libressl because we reported that time_t bug was really a turnoff
2018-02-09 20:46:56 <AWilcox[m]> kaniini: That's the best part, we didn't report it, they knew about it since portable 2.3 was released.
2018-02-09 20:47:17 <AWilcox[m]> kaniini: I don't know why they chose to fix it *now* in 2.6.4.  Maybe there was big client that wanted it.
2018-02-09 20:47:17 <ncopa> and they fixed it silently
2018-02-09 20:47:31 <ncopa> i need to go
2018-02-09 20:51:48 <kaniini> see you
2018-02-09 20:51:58 <kaniini> lets continue libressl vs opensls on mailing list
2018-02-09 21:05:42 <Fusl> does anyone know if Mika Havela (https://bugs.alpinelinux.org/users/4) is active on irc?
2018-02-09 21:17:08 <Fusl> skarnet: thanks again for your help, here's the result, nothing spectacular: https://github.com/alpinelinux/aports/compare/master...Fusl:testing_motion_4.1.1_1
2018-02-09 21:17:39 <Fusl> i built a new pkg for myself, deployed it and let's see if it keeps running for longer than just a few days
2018-02-09 21:18:30 <skarnet> Fusl: 8 MB is the glibc default, but it's probably too big for most packages
2018-02-09 21:18:41 <skarnet> depending on what the software does, try with 1 MB
2018-02-09 21:19:12 <Fusl> skarnet: i'm sure 1 MB will suffice as well but i wanted to be sure that what i'm trying to track down here is really caused by the stacksize being too low
2018-02-09 21:19:20 <skarnet> good point
2018-02-09 21:19:23 <Fusl> sadly i have no way of triggering the segfault whenever i want
2018-02-09 21:19:35 <skarnet> anyway your patch looks good, except the original software doesn't test return codes
2018-02-09 21:19:57 <skarnet> I understand you wanted to mimic the style, but please at least test the return codes for the lines you're adding
2018-02-09 21:20:17 <skarnet> some checks are better than none at all ;)
2018-02-09 21:20:52 <Fusl> will add that to my list of cleanup steps once the actual issue is fixed
2018-02-09 21:21:00 <skarnet> sounds good.
2018-02-09 21:58:57 <tmh1999> _ikke_ : May I enable armhf, aarch64 for testing/fzf ? Looks like they are supported : https://github.com/junegunn/fzf/blob/b49f22cdf9f2ca021382ddeb026c739a22120781/Makefile#L26
2018-02-09 22:01:04 <_ikke_> tmh1999: sure, feel free
2018-02-09 22:01:20 <tmh1999> _ikke_ : Thanks. Just want to check it first since I don't have/know these archs.
2018-02-09 22:02:08 <_ikke_> me neither
2018-02-09 22:02:15 <_ikke_> That must have been added recent
2018-02-09 22:02:32 <_ikke_> because fzf has just been recently merged, and then it wasn't supported yet
2018-02-09 22:05:09 <_ikke_> are you sure they are supported?
2018-02-09 22:05:43 <_ikke_> kaniini: explicitly disabled them because they were not supported yet by the makefile, and I don't see anything has changed
2018-02-09 22:09:59 <mmlb> hey ncopa I just submitted https://github.com/alpinelinux/aports/pull/3252 that reenables Netronome nfp nic driver that was silently dropped, mind to take a look?
2018-02-09 22:11:08 <tmh1999> _ikke_ I am not very sure about arm*, my guess is kaniini disabled them because at that time frame, go wasn't available on those arch.
2018-02-09 22:11:23 <tmh1999> if any
2018-02-09 22:12:25 <tmh1999> oh not true. zzz
2018-02-09 22:12:32 <tmh1999> it's just Jan 2018
2018-02-09 22:12:40 <tmh1999> mistaken with the other patch
2018-02-09 22:12:56 <tmh1999> alright for safe,  I won't enable arm*. just let arm people decide it
2018-02-10 00:55:43 <duncan^> What's the process for moving a package from testing/ to community/
2018-02-10 00:56:16 <duncan^> I've used my kexec package quite extensively and have not identified any problems, so I think it would be appropriate to move it from testing/ to community/.
2018-02-10 00:56:36 <duncan^> (I have no idea if anyone else uses it. I hope they do.)
2018-02-10 00:56:58 <AWilcox[m]> Is there a reason that main/lame has textrel detection code in package()?  I think abuild does this itself for a long time now
2018-02-10 01:54:17 <danieli> clandmeter: what was that linux-4.9.7-rpi-XXXXXX.patch file we needed?
2018-02-10 01:54:27 <danieli> s/4.9.7/4.9.y/
2018-02-10 02:10:30 <kaniini> awilfox: no, it can be removed
2018-02-10 02:31:32 <tmh1999> audit-dev install header libaudit.h in /include. jesus.
2018-02-10 02:31:36 <tmh1999> is that right ?
2018-02-10 02:42:51 <kaniini> no
2018-02-10 02:42:54 <kaniini> definitely not
2018-02-10 02:46:54 <tmh1999> kaniini: https://github.com/alpinelinux/aports/blob/master/main/audit/APKBUILD#L33
2018-02-10 02:47:01 <tmh1999> it should be prefix=/usr, isn't it ?
2018-02-10 02:47:46 <tmh1999> I am compiling testing/libsemanage and it complains about missing libaudit.h, turns out it is inclued in /include.
2018-02-10 02:48:10 <tmh1999> I will create a pr
2018-02-10 03:05:31 <tmh1999> this is funny lol : https://git.alpinelinux.org/cgit/aports/tree/testing/emscripten/APKBUILD#n4
2018-02-10 03:06:09 <danieli> tmh1999: hahhaha, I've seen worse :P
2018-02-10 03:06:17 <tmh1999> :D
2018-02-10 03:06:37 <AWilcox[m]> tmh1999: note that audit will then have libraries in /usr/lib instead of /lib so -static will need to be fixed
2018-02-10 03:07:21 <tmh1999> AWilcox[m] : yes I also did that : https://github.com/alpinelinux/aports/pull/3256
2018-02-10 03:07:45 <tmh1999> danieli : do you have aports write permission and a minute ?
2018-02-10 03:07:48 <tmh1999> :D
2018-02-10 03:07:52 <danieli> tmh1999: I don't have access, no
2018-02-10 03:07:59 <tmh1999> okay
2018-02-10 03:08:06 <danieli> I have access to uk.alpinelinux.org and a very small number of other hosts
2018-02-10 03:08:19 <tmh1999> gotcha
2018-02-10 03:10:09 <kaniini> tmh1999: hi
2018-02-10 03:10:12 <kaniini> what do you need
2018-02-10 03:10:49 <tmh1999> kaniini: hi, not really urgent, I just made some pr. some will come soon.
2018-02-10 09:17:56 <clandmeter> danieli: that's the patch comping from rpi kernel. You need to generate it against the current vanilla.
2018-02-10 09:37:59 <danieli> clandmeter: didn't we lose it
2018-02-10 09:37:59 <danieli> ?
2018-02-10 09:42:31 <clandmeter> Loose it?
2018-02-10 09:42:35 <clandmeter> Idk
2018-02-10 09:44:06 <danieli> i remember everyone scrambling to find it last year
2018-02-10 09:49:00 <clandmeter> It's still an issue?
2018-02-10 09:49:08 <danieli> I don't know, I'm asking, because I found it
2018-02-10 11:29:34 <fcolista> kaniini, thx for the gns3 thinghy. And yes, there's an issue on gns3 due to pyqt5 compiled against qt 5.9.3
2018-02-10 11:29:35 <fcolista> 2ua4020qdl:/mnt/dati$ gns3
2018-02-10 11:29:35 <fcolista> Fail update installation: Error relocating /usr/lib/python3.6/site-packages/PyQt5/QtCore.so: _ZN23QOperatingSystemVersion11AndroidOreoE: symbol not found
2018-02-10 11:30:04 <fcolista> if/hwn you can take a look (and explain what you have done. hwo and why :) I'll be grateful
2018-02-10 11:30:05 <fcolista> thx
2018-02-10 11:30:12 <fcolista> *if/when
2018-02-10 14:59:20 <kaniini> fcolista: the problem is pyqt5 needs to be rebuilt
2018-02-10 15:13:17 <HRio> ncopa: roundcube mail in alpine v3.7 does not work due to missing .js files in the packaging.
2018-02-10 15:14:03 <HRio> the version in v3.6 works fine. This is due to a change introduced by upstream in >= 1.3
2018-02-10 15:17:35 <HRio> I have opened a PR this fix it https://github.com/alpinelinux/aports/pull/3263
2018-02-10 15:17:55 <HRio> s/this/to/
2018-02-10 16:31:54 <tmh1999> ncopa, jirutka : aw I sent a couple of patches regarding s390x last night ...
2018-02-10 16:32:07 <tmh1999> now it conflicts with your recent pushes
2018-02-10 16:32:33 <tmh1999> wished you
2018-02-10 17:06:18 <tmh1999> never mind, I updated it, not a big deal though ...
2018-02-10 20:55:39 <AWilcox[m]> I feel like license="custom" doesn't properly cover main/unrar
2018-02-10 20:55:45 <AWilcox[m]> I feel like license="non-free" would be better
2018-02-11 10:26:32 <fcolista> kaniini, is not a pyqt5 issue
2018-02-11 10:26:49 <fcolista> This was not working with the previous version
2018-02-11 10:27:06 <fcolista> so I upgraded it to the newer pyqt5
2018-02-11 10:27:09 <fcolista> and got the same issue
2018-02-11 10:27:23 <fcolista> if i bump pkgrel for pyqt5 i'll get the same error
2018-02-11 10:48:40 <kaniini> maybe underlinking
2018-02-11 20:37:08 <bjmg> hello, I have a question about the linux-virt package. is there a reason why it depends on linux-firmware-*?
2018-02-11 20:39:21 <bjmg> sorry wrong channnel, I think
2018-02-11 23:28:46 <kaniini> hmm
2018-02-11 23:29:28 <kaniini> bjmg: AFAIK so does -virthardened
2018-02-11 23:30:05 <ag> Hi, can a package in edge/main depend on edge/testing? I've found the wiki/Aports_what_is_edge page, but it's quite sparse, so I still don't understand exactly how the testing repo works. Thanks!
2018-02-11 23:30:23 <kaniini> no, it can't
2018-02-11 23:30:38 <ag> So only packages in testing can, correct?
2018-02-11 23:30:38 <kaniini> edge/main must only depend on edge/main
2018-02-11 23:30:45 <kaniini> yes
2018-02-11 23:30:55 <ag> And main cannot depend on community
2018-02-11 23:31:00 <kaniini> yes
2018-02-11 23:31:05 <ag> Got it. Thanks!
2018-02-11 23:31:12 <kaniini> but community may depend on main
2018-02-11 23:31:16 <kaniini> and testing may depend on both main and community
2018-02-11 23:31:23 <ag> 10-4
2018-02-11 23:32:17 <ag> So is testing a pathway to main?
2018-02-11 23:32:45 <kaniini> testing is work-in-progress packages that do not ship with the distribution (they only live in edge)
2018-02-11 23:33:01 <ag> So community packages also have to move through testing, in that case?
2018-02-11 23:33:18 <kaniini> yes
2018-02-11 23:33:28 <ag> What discerns whether a package ends up in main or community?
2018-02-11 23:34:07 <ag> Sorry for all the questions, lol
2018-02-11 23:34:13 <kaniini> most things should go into community, but not everything has been moved from main yet
2018-02-11 23:38:17 <ag> I ask because I created a PR with bundled mongodb support for main/syslog-ng and someone asked that I link to mongo-c-driver instead. I had testing enabled in my dev environment so I changed it, tested the build, and pushed without realizing mongo-c-driver was in testing. Now I'm thinking I should revert as the dependency may not even end up in main if it even makes it out of testing. Should I just close my PR and reopen with the
2018-02-11 23:38:17 <ag> older commit?
2018-02-11 23:40:29 <kaniini> no
2018-02-11 23:40:40 <kaniini> mongo-c-driver should move to main
2018-02-11 23:42:56 <ag> Ok ty
2018-02-12 09:17:26 <BernhardG> Hi, I just create #8481 in case you need more info about it just ask.
2018-02-12 10:24:02 <fcolista> problem with qt5 and gns3 is due to icu-libs
2018-02-12 10:25:45 <fcolista>  apk version icu-libs
2018-02-12 10:25:45 <fcolista> Installed:                                Available:
2018-02-12 10:25:45 <fcolista> icu-libs-58.2-r2                        < 59.1-r1
2018-02-12 10:25:55 <fcolista>  apk fix icu-libs
2018-02-12 10:25:56 <fcolista> (1/1) [APK unavailable, skipped] Reinstalling icu-libs (58.2-r2)
2018-02-12 10:25:56 <fcolista> OK: 5579 MiB in 1466 packages
2018-02-12 10:26:41 <fcolista> problem :  libQt5Core is part of qt5-qtbase-dev
2018-02-12 10:27:03 <fcolista> this is the version that i have:
2018-02-12 10:27:04 <fcolista>  apk version qt5-qtbase
2018-02-12 10:27:04 <fcolista> Installed:                                Available:
2018-02-12 10:27:04 <fcolista> qt5-qtbase-5.9.1-r0                     < 5.9.3-r0
2018-02-12 10:27:27 <fcolista> and this is the error
2018-02-12 10:27:27 <fcolista> apk add qt5-qtbase-dev
2018-02-12 10:27:27 <fcolista> ERROR: unsatisfiable constraints:
2018-02-12 10:27:27 <fcolista>   icu-libs-59.1-r1:
2018-02-12 10:27:27 <fcolista>     conflicts: icu-libs-58.2-r2
2018-02-12 10:27:28 <fcolista>     satisfies: world[icu-libs] qt5-qtbase-5.9.3-r0[so:libicui18n.so.59] qt5-qtbase-5.9.3-r0[so:libicuuc.so.59]
2018-02-12 10:27:31 <fcolista>   icu-libs-58.2-r2:
2018-02-12 10:27:33 <fcolista>     conflicts: icu-libs-59.1-r1
2018-02-12 10:27:35 <fcolista>     satisfies: world[icu-libs] firefox-54.0.1-r1[
2018-02-12 10:27:37 <fcolista> wondering if I'm the only having this issue
2018-02-12 10:27:53 <fcolista> my repository:
2018-02-12 10:27:53 <fcolista> cat /etc/apk/repositories
2018-02-12 10:27:53 <fcolista> http://dl-cdn.alpinelinux.org/alpine/edge/main
2018-02-12 10:27:53 <fcolista> http://dl-cdn.alpinelinux.org/alpine/edge/community
2018-02-12 10:27:53 <fcolista> http://dl-cdn.alpinelinux.org/alpine/edge/testing
2018-02-12 10:28:10 <fcolista> trying to build icu-libs and force install
2018-02-12 11:11:33 <fcolista> gns3 and wireshark are back to work
2018-02-12 11:13:46 <fcolista> ollieparanoid[m], AWilcox[m] : re qt5
2018-02-12 11:14:15 <fcolista> https://pkgs.alpinelinux.org/contents?file=libQt5Core.so&path=&name=&branch=edge
2018-02-12 11:14:23 <fcolista> I think that this should go to a subpkg
2018-02-12 11:14:40 <fcolista> like qt5-core
2018-02-12 11:32:50 <fcolista> https://dpaste.de/e562/raw
2018-02-12 11:33:03 <fcolista> AWilcox[m], ollieparanoid[m] ^^^
2018-02-12 11:33:28 <fcolista> sorry, wrong patch/paste
2018-02-12 11:34:49 <fcolista> this:
2018-02-12 11:34:50 <fcolista> https://dpaste.de/6Gq1/raw
2018-02-12 12:29:52 <fcolista> or perhaps move these .so from -dev to main pkg
2018-02-12 13:55:24 <kaniini> fcolista: no
2018-02-12 13:55:37 <kaniini> fcolista: libQt5Core.so itself must stay in -dev package
2018-02-12 13:56:10 <kaniini> fcolista: real problem is that firefox-54 needs to be rebuild against icu-libs 59
2018-02-12 13:56:46 <kaniini> at any rate that explains why i cannot reproduce it
2018-02-12 13:56:53 <kaniini> and i believe firefox is at 57 now
2018-02-12 13:57:39 <PureTryOut[m]> 58 even
2018-02-12 14:57:42 <tmh1999> kaniini: if you have a minute, would you mind checking those s390x pr I've made. red color in #alpine-commits is annoying. https://github.com/alpinelinux/aports/pulls/tmh1999
2018-02-12 15:01:46 <kaniini> something something a e s t h e t i c
2018-02-12 15:04:24 <mmlb> I'd love some eyeballs on https://github.com/alpinelinux/aports/pull/3252 that re-enables the netronome NFP nic driver that used to be built a few kernels ago.
2018-02-12 15:13:23 <kaniini> it doesn't, it just adds it to config
2018-02-12 15:13:28 <kaniini> kernel need to be rebuilt to do that (pkgrel and checksums need to be updated in config)
2018-02-12 15:13:31 <kaniini> er in APKBUILD
2018-02-12 17:34:52 <przemoc> AWilcox[m]: https://core.suckless.org/ - most stuff Cag mentioned is from suckless crew, from their core collection to be more specific
2018-02-12 17:37:54 <koldbrutality> anyone get this too https://pastebin.com/aWhrU1Dr   This is for main/libuv.  I need to patch it for electron.
2018-02-12 17:39:07 <przemoc> it doesn't show which test failed
2018-02-12 17:41:01 <koldbrutality> I can run the test alone (./test/.libs/run-tests and ./test/run-tests) but with the make check it fails
2018-02-12 17:44:13 <koldbrutality> this is with vanilla kernel also
2018-02-12 17:48:36 <koldbrutality> the error was above https://pastebin.com/Vy6jqqm5
2018-02-12 17:54:30 <przemoc> koldbrutality: what's your setup?  on x86_64 in alpine edge I got no errors.
2018-02-12 17:55:04 <koldbrutality> i use the same x86_64
2018-02-12 17:56:16 <koldbrutality> and edge
2018-02-12 18:00:03 <przemoc> well, libuv 1.19.1 is already packaged and available, and doesn't have !check in options, so it has to build w/o problems.
2018-02-12 18:00:28 <przemoc> "I need to patch it for electron" - does it mean you already modified it sources locally?
2018-02-12 18:04:00 <koldbrutality> i recompiled it without the patch and it does the same thing.  I need to add https://github.com/electron/node/commit/693b35014efe6416d52e3ae0c1bcfa173670e45b to libuv.
2018-02-12 18:04:47 <koldbrutality> or i could just build libvu with it's own internal libuv
2018-02-12 18:05:26 <koldbrutality> but the nodejs package compiles libuv as separate
2018-02-12 18:10:13 <AWilcox[m]> fcolista (@fcolista:alpinelinux.org): I don't see the point of splitting Qt5Core into its own packages, as that's what qt5-qtbase *is* (in fact, I've oft wondered why it isn't called qt5-qtcore)
2018-02-12 18:10:34 <AWilcox[m]> What does qt5-qtbase have if Qt5Core is removed from it?  A bunch of .sos that *require* Qt5Core?  I just don't see what that gets us
2018-02-12 18:10:45 <AWilcox[m]> Thanks przemoc
2018-02-12 18:13:08 <przemoc> koldbrutality: hard to tell why tests fail in your setup.  are you fully on edge or having mixed env?  cat /etc/alpine-release /etc/apk/repositories | ix
2018-02-12 18:13:46 <koldbrutality> I am on full edge
2018-02-12 18:15:55 <koldbrutality> i think... http://ix.io/GtV
2018-02-12 18:16:44 <koldbrutality> it could be a router problem.  upstream suggested that.
2018-02-12 18:16:58 <koldbrutality> i am trying a patch that might fix it
2018-02-12 20:17:39 <koldbrutality> I just disabled some tests to get it to work, but won't make a pull request for the work around.  it also bugs out when there is no connection.
2018-02-12 20:17:50 <koldbrutality> or if I disconnect from the network
2018-02-12 20:19:06 <koldbrutality> failed on linking electron: undefined reference to symbol 'drmIoctl'
2018-02-12 20:24:09 <AWilcox[m]> Underlinked to libdrm.
2018-02-12 21:07:09 <mps> algitbot: ^
2018-02-12 21:08:22 <mps> algitbot: I patched tcsh with the simple patch from Lede/openWrt and it works without visible problem
2018-02-12 21:12:30 <przemoc> algitbot is possibly not smart enough yet to propagate this info back to the redmine ticket ;)
2018-02-12 21:13:14 <mps> przemoc: hehe, ok. I see :)
2018-02-12 21:14:29 <mps> przemoc: BTW, do I need to post patch to bug report
2018-02-12 21:16:25 <przemoc> if it's available out there, as you already wrote, provide info where it can be found.
2018-02-12 21:17:25 <przemoc> it would be even better if you'd send a patch adding this patch and fixing APKBUILD to use it to alpine-aports ML
2018-02-12 21:17:26 <mps> huh, I copied it from Lede git repository on local disk
2018-02-12 21:18:29 <mps> I don't have much experience with aports, yet
2018-02-12 21:20:47 <przemoc> ok, no pressure, providing info in the ticket will already greatly help to pick it up by someone with aports experience
2018-02-12 21:22:36 <przemoc> I would help by guiding you in creating such patch, but have some other stuff still piled up, so not today
2018-02-12 21:23:42 <mps> przemoc: It would be nice from you to help me to learn about abuild i aport, and I'm not in hurry, also
2018-02-12 21:27:03 <mps> przemoc: for now, can you tell me is it possible to answer issue at https://bugs.alpinelinux.org/issues/8483
2018-02-12 21:28:12 <przemoc> yes, you have to register account (if you haven't already) and login to be able to comment there
2018-02-12 21:28:57 <przemoc> https://bugs.alpinelinux.org/account/register
2018-02-12 21:29:49 <mps> Tnx, I see.
2018-02-12 21:33:05 <mps> przemoc: I'm waiting registration mail. tnx again
2018-02-12 21:33:54 <przemoc> you're welcome.  sorry I cannot be of greater help today.
2018-02-12 21:34:08 <przemoc> I suspect  https://github.com/openwrt/packages/blob/master/utils/tcsh/patches/001-sysmalloc.patch  is the patch you were talking about
2018-02-13 10:37:22 <vkrishn> git.alpinelinux.org seem down
2018-02-13 10:37:40 <vkrishn> and dev.alpinelinux.org
2018-02-13 10:55:38 <kaniini> fcolista: the .so are only used for linking.  what exact problem are you seeing?
2018-02-13 10:55:59 <fcolista> kaniini, should .so be in -dev?
2018-02-13 10:56:07 <fcolista> Or should be in the main pkg?
2018-02-13 10:57:26 <skarnet> the .so should be in -dev, it's a symlink that's only used at build time for the build-time linker
2018-02-13 10:57:36 <skarnet> the .so.x.y should be in the main package, it's the real shared lib
2018-02-13 10:57:44 <skarnet> and used at run time
2018-02-13 10:59:09 <fcolista> skarnet, thanks for the clarification. This explain.
2018-02-13 10:59:24 <fcolista> I thought that in -dev would be only the .h pkgs
2018-02-13 11:00:30 <skarnet> the .h, the .a, and the .so symlink
2018-02-13 15:31:02 <przemoc> kaniini: oh, I didn't have latest apk-tools checkouted, so didn't know that list is already pushed in (I think I saw some of your pastes with drafts in the past).  I presume you'll be further extending the list applet.
2018-02-13 15:47:44 <kaniini> przemoc: yes, it is part of the "apk 3" redesign that we're doing
2018-02-13 15:54:16 <przemoc> is there any rough estimate about fulfilling most of apk 3 requirements?  is there any kind of roadmap available?  it's possibly not 3.8 material, rather 3.9 or later, right?  AFAIR apk's db was meant to be changed to binary format.  AL4 seems like a nice release for such bigger changes, and I guess this apk 3 could actually become apk 4 in the end to nicely match it. :)
2018-02-13 15:54:57 <kaniini> apk 3 will happen when legacy support is dropped
2018-02-13 15:55:06 <kaniini> i don't know if binary database will actually happen
2018-02-13 15:55:14 <kaniini> there are advantages/disadvantages, but it's also challenging
2018-02-13 16:40:17 <Shiz> #define legacy support?
2018-02-13 16:41:27 <kaniini> whatever we choose to deprecate
2018-02-13 16:44:38 <Xe> why make your own database format in general?
2018-02-13 16:45:06 <skarnet> who said anything about that
2018-02-13 16:45:16 <skarnet> the filesystem is a perfectly good database :P
2018-02-13 16:45:58 <skarnet> (a key-value store, more precisely. It becomes less practical the more relations you want between records.)
2018-02-13 18:20:25 <ag> Is there any interest in an autoconf-git package, given that a release 2.70 still seems out of sight after 6 years? Some packages require configure support for --runstatedir to autoreconf, which isn't available in 2.69
2018-02-13 18:22:29 <ncopa> ag: i would prefer not
2018-02-13 18:22:43 <ncopa> maybe ask upstream how the 2.70 release is going?
2018-02-13 18:22:50 <ncopa> we could ask upstream to do a _pre release too
2018-02-13 18:25:34 <HRio> @ncopa: have you seen https://github.com/alpinelinux/aports/pull/3263? upgrade from alpine v3.6 -> v3.7 does not work for roundcube
2018-02-13 18:27:03 <HRio> due to the missing .js files
2018-02-13 18:27:47 <_ikke_> HRio: Is that because 3.7 has a newer version of roundcube?
2018-02-13 18:27:58 <HRio> yes
2018-02-13 18:28:05 <HRio> 1.3.x does not ship js files
2018-02-13 18:28:54 <_ikke_> hmm, php7 ... *.sh?
2018-02-13 18:29:10 <HRio> yes :-)
2018-02-13 18:29:14 <_ikke_> lol
2018-02-13 18:31:42 <HRio> its a bit strange that our php7 packaging forces adding include_path to work for "php scripts"
2018-02-13 18:32:49 <_ikke_> why's that
2018-02-13 18:32:50 <_ikke_> ?
2018-02-13 18:32:51 <HRio> I have to do the same in /etc/php7/php.ini for the web application to work
2018-02-13 18:33:34 <HRio> possibly it looks for libs in /usr/share/php but we have the libs in /usr/share/php7
2018-02-13 18:34:39 <_ikke_> So not properly 'namespaced'
2018-02-13 18:35:08 <HRio> perhaps, I guess jirutka would know for sure
2018-02-13 18:35:51 <_ikke_> It is set for /usr/lib/php7, still looking for /usr/share/php*
2018-02-13 18:36:40 <_ikke_> --datadir and --with-pear are set for /usr/share/$pkgname, so that should be right
2018-02-13 18:36:59 <_ikke_> which version do you have?
2018-02-13 18:37:02 <_ikke_> of the package
2018-02-13 18:38:51 <HRio> in edge 7.1.14-r0 (where I prepared the PR)
2018-02-13 18:39:07 <_ikke_> right
2018-02-13 18:39:37 <HRio> 7.1.14-r0 in v3.7 as well it seems
2018-02-13 18:40:07 <_ikke_> php7 -i does show '--datadir=/usr/share/php7'
2018-02-13 18:42:16 <HRio> yes '--datadir=/usr/share/php7'
2018-02-13 18:42:39 <_ikke_> I think this is your issue: "include_path => .: => .:
2018-02-13 18:42:50 <_ikke_> It only looks in the current dir by default
2018-02-13 18:49:02 <BernhardG> Hi, am I allowed to ask a question about a package I miss (it is a backup software called burp - burp.grke.org)? I think I am able to package it myself. But I did not do this before (at least for alpine).
2018-02-13 18:49:33 <_ikke_> sure, feel free to ask questions
2018-02-13 18:51:15 <BernhardG> Ok, question is quite simple I think: I am able to build for my own architecture (x86_64) already. But I would like to make the package ready for "all" architectures.
2018-02-13 18:51:26 <_ikke_> HRio: I'm not getting the feeling that /usr/share/php* is included by default
2018-02-13 18:52:14 <_ikke_> HRio: on archlinux, it's only /usr/share/pear
2018-02-13 18:52:34 <BernhardG> Therefore I set the "--build=$CBUILD" parameter of configure but the output now is "Invalid configuration `x86_64-alpine-linux-musl': machine `x86_64-alpine-linux' not recognized". What can I do there?
2018-02-13 18:53:26 <_ikke_> BernhardG: each package is built on native hardware
2018-02-13 18:55:05 <BernhardG> Ok, fine. So no cross compiling? But still even my build on x86_64 does not work if I set the build parameter. But that is not a problem as I don't need it for a direct architecture build.
2018-02-13 18:55:18 <BernhardG> _ikke_: thank you for solving the knot in my head.
2018-02-13 18:55:28 <_ikke_> right, there is no cross-compiling
2018-02-13 18:56:24 <HRio> _ikke_: OK, so its needed then, the way I do it at build time.
2018-02-13 18:57:42 <BernhardG> _ikke_: is there an existing variable that just outputs "x86_64" instead of "x86_64-alpine-linux"? I think it would be good to have that specified.
2018-02-13 18:57:55 <_ikke_> HRio: does roundcube put stuff in /usr/share/php7?
2018-02-13 18:58:29 <HRio> /usr/share/webapps/roundcube/
2018-02-13 18:59:05 <_ikke_> why do you need to add /usr/share/php7 to the include_path?
2018-02-13 18:59:06 <HRio> but the php script needs php-pear, and so does the webapp
2018-02-13 19:00:07 <_ikke_> BernhardG: CARCH possibly
2018-02-13 19:01:22 <Fusl> anyone available to help debug why `motion` crashes although i have a binary running that has the following patches applied? https://github.com/alpinelinux/aports/compare/master...Fusl:testing_motion_4.1.1_1
2018-02-13 19:01:42 <BernhardG> _ikke_: thanks. that works. Unfortunately those variables were not explained in https://wiki.alpinelinux.org/wiki/APKBUILD_Reference
2018-02-13 19:02:15 <_ikke_> probably because you'd normally not use them
2018-02-13 19:02:16 <Fusl> the error messages i get are here: http://xor.meo.ws/wRqE4yvPGvsY69vxCgVA1S6VQUCBVO23.txt, mainly "grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/bin/motion"
2018-02-13 19:02:43 <BernhardG> whoops - found but not in the variables section.
2018-02-13 19:02:49 <HRio> ikke: thanks.
2018-02-13 19:03:13 <BernhardG> Why don't you use cross compilation that could make builds way faster.
2018-02-13 19:06:27 <skarnet> BernhardG: the number of packages that are known to cross-compile correctly is incredibly small. Cross-compilation is dangerous because most build systems do not get it right, and hidden errors can lurk in the binaries for a long time.
2018-02-13 19:06:47 <skarnet> Combine this with the fact that qemu will often run a binary that won't work on a real machine.
2018-02-13 19:07:12 <skarnet> so, in order to be able to deliver packages that really work, cross-compilation is not an option.
2018-02-13 19:08:13 <BernhardG> Ok, that sounds true. I did not have much problems (compiling x86 and arm on x86_64) up to now.
2018-02-13 19:09:43 <skarnet> x86 will probably mostly work. arm is another story. ^^
2018-02-13 19:22:07 <ag> @ncopa there is a discussion on the ML from 2016 and nobody seems to be able to make headway. Debian backported the patch for runstatedir. Could we consider this?
2018-02-13 19:22:16 <ag> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759647
2018-02-13 19:24:50 <BernhardG> Ok, one more packaging question: I think I should package burp into multiple packages (burp, burp-server and burp-doc). Reason for this: server needs bash for its scripts. Is there a way to specify this (different dependencies) in one APKBUILD?
2018-02-13 19:25:41 <_ikke_> BernhardG: yes
2018-02-13 19:26:19 <ag> BernhardG: https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#subpackages
2018-02-13 19:27:05 <ag> https://wiki.alpinelinux.org/wiki/APKBUILD_examples:Multiple_Subpackages
2018-02-13 19:27:46 <_ikke_> you can specify depends in the split function as well
2018-02-13 19:27:53 <ag> ^
2018-02-13 19:28:18 <BernhardG> ag: this is the subpackage feature I already know. So if I understand the example right I have to specify the depends variable inside the burp_server() function.
2018-02-13 19:28:28 <ag> just server()
2018-02-13 19:28:36 <BernhardG> oh - yes
2018-02-13 19:28:57 <ag> it will split the subpackage name on the last hyphen and use the last part as the function name
2018-02-13 19:29:17 <ag> if you need to specify the function for some reason, you can use my-subpkg-name:the_function
2018-02-13 19:29:46 <_ikke_> usually you do just $pkgname-<functionname>
2018-02-13 19:30:02 <BernhardG> This is quite nice. And its all written in ash, right?
2018-02-13 19:30:21 <_ikke_> in posix shell
2018-02-13 19:30:35 <BernhardG> The build system is much more flexible than I thought at first sight.
2018-02-13 19:31:30 <ag> BTW, you shouldn't need to specify a -doc function, as it has a default. If you need to specify extra commands after the default, call `default_doc` at the top of your doc() function
2018-02-13 19:32:37 <BernhardG> ag: yeah - the splitting of main and doc already works. But I added some additional files to it.
2018-02-13 19:33:42 <BernhardG> ag: default_doc is very helpful - that was missing up to now.
2018-02-13 19:33:47 <_ikke_> usually you can just copy files during package(), and the split function will do it's work (if you added files in default locations)
2018-02-13 19:34:51 <BernhardG> _ikke_: yeah - it worked quite good out of the box. that was fascinating.
2018-02-13 19:35:32 <ag> BernhardG: you should read the source for abuild https://git.alpinelinux.org/cgit/abuild/tree/abuild.in
2018-02-13 19:36:29 <BernhardG> ag. I just looked into it on my virtual maschine. There I found some infos about cross compiling and that was the reason why I tought I have to specify CBUILD and CHOST.
2018-02-13 19:36:34 <ag> Or at least use it for a reference, especially for the default_* functions
2018-02-13 19:36:53 <BernhardG> But now I have a much better understanding.
2018-02-13 19:38:41 <BernhardG> Thank you for your help on this point. Your community seems to be quite small but you help newcomers and this is special.
2018-02-13 19:40:24 <ag> I'm a newcomer too :)
2018-02-13 19:40:40 <BernhardG> I now use Linux distributions since 1994 and have worked with a lot of systems and were in contact with a large amount of different developers. But your community is the niciest so far.
2018-02-13 19:41:29 <ag> I've been hacking on the Alpine build system and aports for just a few weeks now, but have found it really nice to work with and quick to grasp
2018-02-13 19:41:48 <ag> Seems like you're having a similar experience
2018-02-13 19:41:53 <BernhardG> ag, yes that is true. I've started last friday.
2018-02-13 19:42:09 <ag> :)
2018-02-13 19:42:42 <BernhardG> My goal is to create a VM template for opennebula that contains our tools and works as a preconfigured docker host os.
2018-02-13 19:43:20 <ag> Sounds like fun
2018-02-13 19:43:36 <ag> I'm working on something similar
2018-02-13 19:43:45 <BernhardG> If this works good (it already works stable) I can imagine that I also switch our virtualization hosts (the opennebula hosts) to alpine (from CentOS 7)
2018-02-13 19:45:52 <BernhardG> To get this done too I have to either use Ceph inside Docker or create Ceph packages for Alpine. There are some in testing but they seem unmaintained.
2018-02-13 19:46:35 <ag> Containerize all the things :)
2018-02-13 19:47:45 <BernhardG> ag: then you should look into RancherOS. That is the system I've started with beginning of the last week. But I were not happy with it (and its community).
2018-02-13 19:48:34 <ag> I'm running Rancher also
2018-02-13 19:48:50 <BernhardG> I also don't think that it is wise to containerize something (like Ceph) that is the base of our persitent data.
2018-02-13 19:49:33 <BernhardG> If Ceph crashes somehow we could lose data.
2018-02-13 19:49:48 <ag> How so?
2018-02-13 19:51:13 <BernhardG> Docker is IMHO really good for stateless things. But data is a state. I fear that some command could easily kill an ceph osd and therefore bring big problems.
2018-02-13 19:51:33 <ag> But you can just bind mount host directories into a container?
2018-02-13 19:51:34 <_ikke_> My opinion is to also keep data outside of docker
2018-02-13 19:52:04 <ag> The data is not within Docker
2018-02-13 19:52:30 <_ikke_> nod
2018-02-13 19:52:49 <BernhardG> This is true. You can bind mount. But that does not work for Ceph that way. For the newer Ceph bluestore you need direct device access AFAIK.
2018-02-13 19:53:15 <ag> Then you just bind mount the /dev/{block-dev} special file into the container
2018-02-13 19:54:07 <ag> I'm just not seeing how what is essentially just a chroot jail makes any of this more fragile
2018-02-13 19:54:40 <BernhardG> Anyway I am not sure how far I can go. Main problem is: I am shareholder of the company and I have some deep knowledge about many things. But I fear that our administrators are not able to follow my way if I am going too fast.
2018-02-13 19:54:51 <ag> Yeah, been there
2018-02-13 19:55:36 <BernhardG> ag, you are right. It is not much different from a chroot. But debugging can be so much harder.
2018-02-13 19:57:05 <BernhardG> One reason why I relly like alpine linux is that it does not have too much comfort functions. This way it it is much easier to understand - at least I hope so.
2018-02-13 19:59:14 <ag> Yeah, I love the simplicity of Alpine and that it comes with a grsec kernel (especially now that even test builds of the patches are non-public)
2018-02-13 19:59:33 <BernhardG> In the last two years I've gone through the following technologies and changes: Ubuntu 14.04 with OpenStack, CentOS 7 with OpenStack, CentOS 7 with OpenNebula, CentOS 7 with Ceph and OpenNebula, auto provisioning, salt integration, zabbix auto discovery, zabbix auto registration, ...
2018-02-13 20:00:33 <ag> Wait, is Alpine now on linux-hardened instead of grsec?
2018-02-13 20:00:42 <BernhardG> Now I finally had time to get Docker started in our Data center. This is too much for many administrators unfortunately.
2018-02-13 20:00:42 <ag> That's a lot
2018-02-13 20:00:44 <_ikke_> ag: it was renamed
2018-02-13 20:00:54 <ag> What was renamed?
2018-02-13 20:01:00 <_ikke_> ag: and fun fact, unless something changes, hardened will be phased out as well
2018-02-13 20:01:09 <_ikke_> grsec -> hardened
2018-02-13 20:01:25 <ag> The grsec project has merged with linux-hardened?
2018-02-13 20:01:31 <_ikke_> no
2018-02-13 20:01:48 <BernhardG> it already seems it *is* phased out. 4.14.18 kernel is in edge and there is only virt and vanilla.
2018-02-13 20:01:56 <_ikke_> alpine renamed the package / flavour from grsec to hardened
2018-02-13 20:02:03 <_ikke_> BernhardG: right
2018-02-13 20:02:23 <ag> I can see that in testing?
2018-02-13 20:02:31 <BernhardG> There is also a bug in virt as it depends on linux-firmware. I've already reported that bug.
2018-02-13 20:02:43 <_ikke_> They could not get the ktpi patches in the grsec kernels
2018-02-13 20:02:57 <BernhardG> ag yes - you could upgrade your system to edge completely or doing a cherry pick.
2018-02-13 20:03:28 <ag> kpti you mean?
2018-02-13 20:03:47 <BernhardG> http://lists.alpinelinux.org/alpine-devel/6022.html
2018-02-13 20:03:59 <BernhardG> This is the mailing list link to that announcement
2018-02-13 20:04:03 <_ikke_> ag: sorry, yes
2018-02-13 20:05:13 <ag> I see, so we're just defaulting to vanilla as kpti is more important and those patches break hardened and grsec
2018-02-13 20:05:21 <BernhardG> I think I now switch to my mobile. I am at work since 07:00 (Germany) and we now have 21:00.
2018-02-13 20:05:45 <BernhardG> Many thanks for your help about packaging.
2018-02-13 20:05:47 <ag> Guten Abend :)
2018-02-13 20:06:07 <BernhardG> ag, your're from germany too?
2018-02-13 20:06:16 <_ikke_> ag: yes, alpine was not comfortable distributing kernels that were vulnerable to meltdown and spectre
2018-02-13 20:06:20 <ag> Schweizer, but in the US
2018-02-13 20:06:44 <ag> _ikke_, makes sense thanks for the explanation
2018-02-13 20:09:03 <BernhardG> so now on mobile
2018-02-13 20:09:19 <_ikke_> wb
2018-02-13 20:14:13 <BernhardG> do you use some form of configuration Management with alpine?
2018-02-13 20:14:46 <BernhardG> at the moment I use salt. but it is quite big
2018-02-13 20:15:23 <_ikke_> I haven't yet on alpine
2018-02-13 20:16:25 <BernhardG> ansible and chef seem way too big
2018-02-13 20:17:31 <_ikke_> I don't think there is anyhting that is 'small'
2018-02-13 20:18:11 <BernhardG> cfengine seems smaller and is written in C
2018-02-13 20:21:18 <BernhardG> but I never tested it
2018-02-13 20:21:27 <_ikke_> me neither
2018-02-13 20:23:35 <ncopa> i have never used cfengine but I have met some of the developers
2018-02-13 20:24:06 <ncopa> i applied for work for them once
2018-02-13 20:25:21 <BernhardG> it seems to me more like a programming language than salt.
2018-02-13 20:25:37 <ncopa> got reply 1+ year later :)
2018-02-13 20:25:47 <ncopa> the project has been around for a long time
2018-02-13 20:25:58 <ncopa> i have general good impression of it
2018-02-13 20:26:03 <_ikke_> salt user mostly yaml, most others use a dsl of some inds
2018-02-13 20:26:05 <_ikke_> kind
2018-02-13 20:26:12 <ncopa> i think the biggest problem with it is that it has high learning curve
2018-02-13 20:26:13 <ncopa> it seems difficult to get started
2018-02-13 20:27:22 <przemoc> one year to get a response?  it must have been some really long mail.  or super busy company.
2018-02-13 20:27:28 <BernhardG> I only need it to transfer SSH keys as a first step.
2018-02-13 20:27:43 <_ikke_> przemoc: or it got lost in some pile and someone later found it again
2018-02-13 20:28:41 <ncopa> nah, i think they had some new project that included embedded or similar and looked over old applicants and find mine
2018-02-13 20:30:17 <przemoc> usually it is a good etiquette to at least reply "we're no longer looking for candidates" or something.
2018-02-13 20:33:30 <ncopa> they had an opening annouced which i applied to
2018-02-13 20:33:31 <ncopa> I applied and the I asked if it was ok that I went there to look how the offices looked like
2018-02-13 20:33:32 <ncopa> and went there and shaked hands with everyone
2018-02-13 20:33:32 <ncopa> i did that so the would remember me when they looked at the pile :)
2018-02-13 20:34:15 <BernhardG> not bad
2018-02-13 20:34:26 <_ikke_> :D
2018-02-13 20:34:35 <BernhardG> ncopa, you are now working for Docker, right?
2018-02-13 20:37:43 <przemoc> ok, then it didn't look that bad on their side.  smart move BTW
2018-02-13 20:38:55 <przemoc> I read it before as they haven't communicated with you at all since you sent them your mail
2018-02-13 20:42:50 <_ikke_> Trying to compile something that fails on missing sigset_t, but I do see signal.h is being included. Any idea why it fails?
2018-02-13 20:45:33 <ncopa> do you have exact error message? make 2>&1 | tpaste
2018-02-13 20:46:36 <przemoc> maybe lack of _XOPEN_SOURCE 500 or similar def
2018-02-13 20:47:16 <ncopa> _GNU_SOURCE
2018-02-13 20:47:47 <_ikke_> http://tpaste.us/kW61
2018-02-13 20:48:02 <przemoc> I always avoid _GNU_SOURCE unless really necessary
2018-02-13 20:48:47 <_ikke_> _POSIX_SOURCE?
2018-02-13 20:49:47 <ncopa> runtime.h:173:8: error: unknown type name 'sigset_t'
2018-02-13 20:49:58 <ncopa> is #include <signal.h> in runtime.h, before line 173?
2018-02-13 20:50:34 <_ikke_> it's on line 21
2018-02-13 20:50:56 <ncopa> i dont think any *_SOURCE should be needed: http://pubs.opengroup.org/onlinepubs/7908799/xsh/signal.h.html
2018-02-13 20:51:09 <ncopa> also verify that the #include <signal.h> is not withing some #ifdef or simlar
2018-02-13 20:51:21 <ncopa> verify that #include <signal.h> is actually included
2018-02-13 20:51:34 <_ikke_> It's in an ifdef, but in the else part of something that checks for windows
2018-02-13 20:52:02 <_ikke_> #if defined(LISP_FEATURE_WIN32) && defined(LISP_FEATURE_SB_THREAD)
2018-02-13 20:53:02 <ncopa> you can add a temporary "#error foobar" over the #include <signal.h>
2018-02-13 20:53:05 <ncopa> and run make
2018-02-13 20:53:13 <ncopa> to verify that it fails with error: foobar
2018-02-13 20:53:32 <przemoc> ncopa: it's SUS2, what you showed, which means _XOPEN_SOURCE 500 (or greater) isn't out of question
2018-02-13 20:54:21 <przemoc> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html
2018-02-13 20:54:26 <przemoc> "Some of the functionality described on this reference page extends the ISO C standard. Applications shall define the appropriate feature test macro (see XSH The Compilation Environment ) to enable the visibility of these symbols in this header"
2018-02-13 20:55:16 <ncopa> ok
2018-02-13 20:55:24 <przemoc> in practice it's rarely useful to go below _XOPEN_SOURCE 600 or 700
2018-02-13 20:56:56 <_ikke_> I do see #ifdef guards around the parts that include bits/alltypes.h, but is that because it might be defined elsewhere already?
2018-02-13 20:57:13 <_ikke_> (that's in /usr/include/signal.h)
2018-02-13 20:57:48 <przemoc> no, not everything is exposed by default, that's why you define what level of support you want or need in your code
2018-02-13 20:58:14 <_ikke_> ncopa: I do see the error
2018-02-13 21:07:15 <AWilcox[m]> I am very happy that our changes from Adelie are being merged in to Alpine now :)
2018-02-13 21:09:50 <_ikke_> Would I break a lot if I would do something like #define _POSIX_SOURCE\n#include <signal.h>\n#undefine _POSIX_SOURCE?
2018-02-13 21:11:43 <AWilcox[m]> That depends wildly on a number of factors
2018-02-13 21:11:46 <AWilcox[m]> You could
2018-02-13 21:12:03 <_ikke_> trying to find out why sigset_t is not defined
2018-02-13 21:12:38 <przemoc> IAMB3NW: it's wrong what you showed.  if you define that way, you should define with 1 at least, not empty, and rather not undefine later.  and 1 is rather not enough here I presume, because 1 reference to ancient version.
2018-02-13 21:12:46 <ncopa> i dont think you can #undefine it
2018-02-13 21:13:11 <przemoc> IAMB3NW: sorry, wrong tag ;)
2018-02-13 21:13:30 <AWilcox[m]> #undef
2018-02-13 21:14:23 <_ikke_> ncopa: I do see things like that for _BSD_SOURCE in the project
2018-02-13 21:14:29 <przemoc> the thing is undefining is conceptually wrong, as code is written for POSIX (or other standard) or it's not written for it, not half for POSIX and half not...
2018-02-13 21:14:34 <przemoc> _ikke_: try building with -D_XOPEN_SOURCE=700
2018-02-13 21:16:07 <_ikke_> They seem to use shell scripts (make.sh)
2018-02-13 21:53:43 <andypost> Any idea what's up with "ERROR: mpfr3-3.1.5-r1: BAD archive" in https://travis-ci.org/alpinelinux/aports/jobs/341156958
2018-02-13 21:54:54 <przemoc> corrupted file perhaps?
2018-02-13 21:59:49 <andypost> przemoc, but there's no data about is cdn used or something local to travis
2018-02-13 22:03:55 <andypost> it is broken on NL mirror apk -X http://nl.alpinelinux.org/alpine/edge/main add mpfr3
2018-02-13 22:06:21 <przemoc> yeah, it is invalid apk indeed on nl.a.o.  gzip spits: invalid compressed data--crc error, invalid compressed data--length error
2018-02-13 22:12:47 <kaniini> clandmeter ^^^ is there a problem with nl.* storage ?
2018-02-13 22:14:18 <clandmeter> Afk atm
2018-02-13 22:14:55 <clandmeter> cz has no issues?
2018-02-13 22:16:20 <przemoc> only 1 byte differs
2018-02-13 22:16:48 <kaniini> wtffffffff
2018-02-13 22:16:50 <przemoc> you should investigate storage status
2018-02-13 22:17:12 <kaniini> agreed
2018-02-13 22:20:28 <przemoc> I also recently had storage issue (and possibly still have one).  possibly my usb flash drive is not well suited for continuous work.  finding errors like corrupted net config with some subtle ip changes, letter case changes, etc.  had to apk fix -r many packages, but it's hard to catch that kind of stuff if you haven't checksummed everything earlier
2018-02-13 22:22:32 <przemoc> I have proposition to extend apk to store checksums of files included in it, to make easy compare on-disk state with original package state (it's ok if config differs, of course, because they're often changes)
2018-02-13 22:22:58 <przemoc> s/changes/changed/
2018-02-13 22:24:25 <przemoc> initially I suspected memory problems, as I've noticed other problems earlier, but then files that haven't been touched for a long time (like /etc/network/interfaces) wouldn't be corrupted.
2018-02-13 22:24:40 <BernhardG> could also be used for something like tripwire gets used for normally
2018-02-13 22:36:47 <kaniini> przemoc: apk can already do that.  `apk audit` :)
2018-02-13 22:37:47 <przemoc> how I could overlooked that?!
2018-02-13 22:40:44 <BernhardG> what?! nice
2018-02-13 22:40:47 <przemoc> it lacks any info in --help how results should be interpreted, though
2018-02-13 22:43:35 <przemoc> at least I can detect more broken stuff on my storage
2018-02-13 22:43:40 <przemoc> thanks, kaniini!
2018-02-13 23:09:29 <przemoc> already fixed several stuff.  U /lib/modules/*/modules.* seem kind of ok, I guess, as they're regenerated, but I'm wondering about  X usr/share/fonts/encodings/encodings.dir  as I already apk fix -r encodings, but encodings.dir is still not there.  I verified with tar -tf that this dir is indeed present in .apk, so it's really strange
2018-02-13 23:13:30 <BernhardG> bye
2018-02-13 23:23:45 <przemoc> one correction: encodings.dir is not a dir, it's a file
2018-02-13 23:34:37 <przemoc> it looks like mkfontscale trigger (or actually mkfontscale binary, that is run by the trigger) unlinks this file for some reason.
2018-02-13 23:35:02 <przemoc> so it's a non-issue and not a bug in apk (which I feared for a moment)
2018-02-13 23:41:42 <ag> my Travis build on a PR just failed with "ERROR: mpfr3-3.1.5-r1: BAD archive", what do?
2018-02-13 23:41:51 <ag> (during deps)
2018-02-13 23:42:43 <przemoc> known problem, someone will have to investigate nl.a.o storage, because that's where the bad package is
2018-02-13 23:42:59 <ag> d'oh
2018-02-13 23:43:59 <ag> how long has that been an issue? any idea?
2018-02-13 23:46:02 <przemoc> it was reported ~2h ago on this channel, and there are apparently no AL devs with access to it available atm
2018-02-13 23:46:17 <ag> oh ok, so not very long
2018-02-13 23:46:21 <ag> thanks for the info
2018-02-13 23:47:10 <przemoc> it may take some time, I guess, because it has to be investigated, why this corruption happened in the first place
2018-02-13 23:48:11 <ag> yeah, that's odd. I assume it's happening to more than one package?
2018-02-13 23:48:23 <przemoc> so far only one was reported
2018-02-13 23:48:48 <ag> maybe just a bit flip in RAM somewhere :P
2018-02-13 23:50:18 <przemoc> the file is corrupted in one byte exactly, so it looks like some corruption happened during writing the package on disk, or it happened later on-disk so all reads are now with this wrong byte
2018-02-13 23:51:56 <przemoc> if there were more reports of broken packages, it would mean disk there may be failing, but single accident doesn't necessarily mean that storage there is screwed, yet such errors shouldn't be ever taken lightly
2018-02-13 23:52:47 <ag> definitely not. could be controller starting to fail or who knows what
2018-02-14 00:00:40 <przemoc> just for the record, this one byte difference is actually one bit difference.  forgot to mention it earlier
2018-02-14 00:01:58 <przemoc> $ cmp -bl mpfr*
2018-02-14 00:01:58 <przemoc> 119524 214 M-^L 254 M-,
2018-02-14 00:04:24 <mksully221> looks like a bunch of PRs failed with the same mpfr3* BAD archive error...will those pull requests be automatically retried when the mpfr3* issue has been corrected? or will the PRs have to be submitted again?
2018-02-14 00:08:01 <przemoc> I'm not sure if travis allows to retrigger PR build.  you can surely retrigger normal builds if you have write access to the repo, but no idea about PRs
2018-02-14 00:56:16 <przemoc> yeah, I kind of like this hyperkitty UX from what I see after clicking a bit there.  it has some stuff that would need tuning (e.g. too few entries showed by default, requiring to click ellipsis, too bloated UI taking too much screen estate), but it seems usable and thought-out.
2018-02-14 00:56:46 <przemoc> wrong window, damn
2018-02-14 05:55:16 <_ikke_> przemoc: defining -D_XOPEN_SOURCE=700 at the right place seem to have solved that particular issue
2018-02-14 05:57:42 <_ikke_> przemoc: next issue is NSIG, and it appears that I *do* require _GNU_SOURCE there
2018-02-14 09:36:44 <_ikke_> przemoc: with _GNU_SOURCE it compiled. Is there a better alternative?
2018-02-14 09:37:20 <przemoc> _BSD_SOURCE should be good enough too
2018-02-14 09:37:50 <_ikke_> Alright. Is there a reason why _BSD_SOURCE is better than _GNU_SOURCE?
2018-02-14 09:41:54 <przemoc> it's about expressing the intent.  I think using _GNU_SOURCE should be avoided unless it's really needed to expose GNU-only stuff.  possibly not everyone will agree with me on that.
2018-02-14 09:42:15 <_ikke_> ok
2018-02-14 09:43:11 <_ikke_> but _BSD_SOURCE seems kind of arbitrary as well to me
2018-02-14 09:43:46 <przemoc> NSIG _is_ visible on BSDs.
2018-02-14 09:45:35 <kaniini> NSIG is exposed with _XOPEN_SOURCE too AFAIK
2018-02-14 09:45:39 <kaniini> give it a go :)
2018-02-14 09:45:43 <_ikke_> I did
2018-02-14 09:45:53 <przemoc> in glibc headers it's exposed regardless of feature macros present if I'm not mistaken.  musl is simply much more strict, which is a good thing.
2018-02-14 09:46:08 <_ikke_> it failed to compile with -D_XOPEN_SOURCE+700
2018-02-14 09:46:11 <_ikke_> it failed to compile with -D_XOPEN_SOURCE=700
2018-02-14 09:46:11 <przemoc> kaniini: it's not a POSIX thing
2018-02-14 09:46:22 <przemoc> so _XOPEN_SOURCE is not good enough
2018-02-14 09:46:28 <przemoc> for NSIG
2018-02-14 09:49:27 <kaniini> hmm
2018-02-14 09:54:19 <przemoc> kaniini: I suspect you are possibly confused by musl default behavior (which is sane) that it defaults to -D_BSD_SOURCE=1 -D_XOPEN_SOURCE=700, but it only happens if no *_SOURCE is already defined
2018-02-14 10:04:15 <kaniini> it is possible =)
2018-02-14 10:06:52 <przemoc> _ikke_: application/library developer should be mindful about what featureset she/he wants/needs and express it by either  defining proper _*_SOURCE at the very top of the source file (before including headers)  or  build all source files with appropriate D_*_SOURCE (but if applying same _*_SOURCE stuff to all files cannot give proper results, then it's generally better to go with defining them
2018-02-14 10:06:58 <przemoc> appropriately in-source at file level).  lack of any of this is a issue that limits portability and can/should be reported upstream.
2018-02-14 10:07:58 <przemoc> lack  or  wrong use
2018-02-14 10:08:01 <przemoc> of course
2018-02-14 10:08:50 <_ikke_> przemoc: The source does it at some places, but in a #define..; do something #undef fashion
2018-02-14 10:11:01 <_ikke_> przemoc: the XOPEN_SOURCE=x derictive makes sense, I expect up until this level
2018-02-14 10:11:56 <_ikke_> but defining _BSD_SOURCE on a non BSD system (and same for _GNU_SOURCE on a non-GNU system) is kind of arbitrary
2018-02-14 10:12:46 <_ikke_> _GNU_SOURCE kinda does make sense if people expect to be in a GNU like environment though
2018-02-14 10:13:15 <_ikke_> But that's just from an outside perspective :-)
2018-02-14 10:14:57 <przemoc> it's not really arbitrary.  if you use features originating on BSD systems (or some older unices), you should state that.  by going with _GNU_SOURCE in that situations your code will be less portable, because other envs can implement BSD features and not-necessarily support any GNU compat stuff.
2018-02-14 10:17:47 <przemoc> in that regard GNU is like cancer, because many people using GNU solutions (be it libs, tools, whatever) expect that whole worlds uses it, which is not true.
2018-02-14 10:18:23 <_ikke_> Right, but in that case you have little choice as a packager, right?
2018-02-14 10:18:29 <_ikke_> Except not packaging it
2018-02-14 10:19:01 <_ikke_> But the the source of the features makes sense
2018-02-14 10:19:10 <przemoc> you can contact upstream and try to convince them to do better job
2018-02-14 10:19:58 <przemoc> and until they'll do it, yes, you have to patch it in the distro, if you want to have that package
2018-02-14 10:26:45 <przemoc> and #undefing _*_SOURCE really makes no sense, it's on the verge of being broken.  you define _*_SOURCE for given compilation unit and these defines usually define bunch of other internal defines in system headers, that you're not necessarily aware of or should be.  #undefing it between various headers leads you to some undefined state in regards to what features will be really exposed, most likely
2018-02-14 10:26:51 <przemoc> different from what man writing such #undef believed to achieve.
2018-02-14 10:31:10 <przemoc> BTW kaniini: congrats on achieving first milestone with libucontext
2018-02-14 10:31:59 <detha> przemoc: what is the preferred solution? Have one header file with _*_SOURCE defines, and let autoconf figure out which ones are needed in the current platform?
2018-02-14 10:43:52 <przemoc> I avoid autoconf, so cannot talk about it in particular.  in great majority of cases you don't need varying feature set between source files, so building everything with same _*_SOURCE defines mindfully picked by developer according to her/his needs should be really good enough.  such defines should be treated mostly the same on various platforms (unless they're broken).  and if you're dealing with
2018-02-14 10:43:58 <przemoc> some broken platforms, then having separate file header dealing with it instead of -D... during compilation seems fine (header that is included by all your source files at the top, of course, unless that brings some conflicts too on your platform, then you have to go at file level)
2018-02-14 10:50:22 <przemoc> sometimes there can be additional defines needed by some platforms (like _DEFAULT_SOURCE for glibc to avoid warnings), but they should not cause any problems on other platforms (usually), so it's better to define all than trying to be overly smart (oh, we're on some BSD? then maybe I can omit _BSD_SOURCE, right, it's BSD after all, so no need to specify that...)
2018-02-14 12:59:20 <detha> Makes sense. Most problems are probably with platforms that the developers don't have access to, or rarely test on, so sometimes they assume 'feature X will always be there', and don't include the _xx_SOURCE
2018-02-14 15:48:41 <mps> setup-disk -m sys /mnt does not work on the f2fs filesystem. Is this bug or is there reason for this?
2018-02-14 16:24:55 <adrolter> If the mpfr3 package is fixed in nl could someone please restart the CI build for #3304? Thanks!
2018-02-14 16:25:06 <adrolter> (PR 3304)
2018-02-14 18:33:08 <fcolista> uff gns3 break again due to aiohttp upgrade
2018-02-14 19:22:58 <fabled> kaniini, re: libucontext on x86: makecontext clobbers EBX which is supposed to be the PLT/GOT pointer. so when __start_context calls __setcontext via PLT it blows up
2018-02-14 19:23:50 <fabled> kaniini, maybe reload GOT pointer to EBX in __start_context ?
2018-02-14 19:34:52 <fabled> kaniini, http://tpaste.us/PLE7 seems to fix it for me
2018-02-14 19:39:47 <fabled> oh, ebx needs to be loaded before jump to hosed, or also for the exit() call
2018-02-14 23:34:20 <Ganwell> that pkg doesn't run checks although check() is defined: http://build.alpinelinux.org/buildlogs/build-edge-x86_64/testing/nim/nim-0.17.2-r1.log
2018-02-14 23:35:17 <Ganwell> why?
2018-02-15 00:13:50 <koldbrutality> do you run armhf?
2018-02-15 04:26:33 <kaniini> aha
2018-02-15 12:56:39 <Ganwell> koldbrutality: no, x86_64
2018-02-15 12:57:44 <Ganwell> build-edge-x86_64
2018-02-15 12:58:44 <bulld00zer> Greetings, any chance a spectre safe kernel is getting to 3.7? Also wondering if its decided 100% to go with vanilla instead of hardened? The version from copperhead seems promising.. https://github.com/copperhead/linux-hardened
2018-02-15 13:04:12 <BernhardG> Before I submit a pull request for a new aport (my first one) I've made. I would like to have some feedback. Could someone please help me?
2018-02-15 13:05:46 <danieli> clandmeter or ncopa: kill #8488
2018-02-15 13:06:43 <BernhardG> This is the aport I've created (burp is a network backup and restore program): https://github.com/BernhardGruen/aports/tree/burp/testing/burp
2018-02-15 13:08:38 <kaniini> danieli: i neutralized it
2018-02-15 13:08:55 <danieli> kaniini: thank you sergeant
2018-02-15 13:08:57 <danieli> good work
2018-02-15 13:10:50 <kaniini> but you don't want to download game killer apk ?!
2018-02-15 13:10:58 <danieli> no thank you, i got frida <3
2018-02-15 13:11:43 <kaniini> bulld00zer: there is not really much difference between strcat's linux-hardened tree and vanilla
2018-02-15 13:12:03 <kaniini> (as in what we ship as vanilla)
2018-02-15 13:12:18 <kaniini> neither are comparable or equivalent to grsecurity, unfortunately
2018-02-15 13:15:03 <bulld00zer> kaniini: that's what I figured, too bad Brad and the gang did not get some more funding from the big corps "borrowing" their code.
2018-02-15 13:15:28 <bulld00zer> kaniini: Do you know if the new kernel will find it's way down to 3.7 or will it be in edge only until the next release?
2018-02-15 13:17:45 <kaniini> yes, we intend to have linux-vanilla 4.14 in 3.7
2018-02-15 13:18:08 <kaniini> we are still deciding what to do about the migration of linux-hardened packages though
2018-02-15 13:22:47 <BernhardG> Wouldn't it be the best for everyone if there would at least be a new kernel available in 3.7? Even if the newer hardened version is not as good as it could be. It is still better from a security aspect than the one currently provided with 3.7
2018-02-15 13:23:51 <ncopa> yes
2018-02-15 13:23:53 <ncopa> i think we should start with upgrading the linux-vanilla kernel to 4.14
2018-02-15 13:23:57 <BernhardG> From my personal view I would prefer having a transition package from linux-virthardened to linux-virt.
2018-02-15 13:24:16 <hs3dUBwdmCjy> may i ask why all the grsecurity mitigations are less important than two half-assed mitigations against two new bugs? this is a honest question, no fanboiing or anything...
2018-02-15 13:25:11 <ncopa> because grsecurity does not solve spectre and meltdown
2018-02-15 13:25:25 <hs3dUBwdmCjy> yes, but it solves a lot of other unsolved issues
2018-02-15 13:25:32 <BernhardG> hs3dUBwdmCjy, I don't think they are less important. The ideal situation would be a kernel that contains all mitigations.
2018-02-15 13:25:40 <ncopa> and the fixes for those are so intrusive that we can no longer maintain the unofficial fork
2018-02-15 13:25:57 <ncopa> part of the problem is that grsecurity is not free
2018-02-15 13:26:18 <BernhardG> But if I understand it right, the Alpine Linux team does not have enough power to provide that. And I can understand that fully.
2018-02-15 13:26:20 <ncopa> i'd love continue with it, but we cannot
2018-02-15 13:26:23 <hs3dUBwdmCjy> i understand the the fork/grsecurity issues
2018-02-15 13:26:41 <hs3dUBwdmCjy> what i don't understand is the measuring which of the mitigations are more important
2018-02-15 13:26:43 <ncopa> we can chose between stay on 4.9.72 kernel for ever or switch to vanilla kernel
2018-02-15 13:27:17 <hs3dUBwdmCjy> we have a bunch of mature mitigations in grsec, and we have 2 kinda halfassed mitigations for the intel bugs.
2018-02-15 13:27:43 <kaniini> jirutka: what is your opinion on https://code.foxkit.us/adelie/aports/commit/53c43166
2018-02-15 13:27:53 <ncopa> its not only about those 2 intel bugs
2018-02-15 13:28:00 <ncopa> its about all other bugs too
2018-02-15 13:28:10 <BernhardG> Is there a team that currently maintains the forked grsecurity -> hardened patches?
2018-02-15 13:28:43 <hs3dUBwdmCjy> but 4.9 is still lts and gets bugfixes backported no?
2018-02-15 13:29:01 <ncopa> BernhardG: not anymore
2018-02-15 13:29:39 <ncopa> hs3dUBwdmCjy: yes, but we cannot backport them anymore
2018-02-15 13:29:50 <ncopa> that is the problem
2018-02-15 13:30:04 <hs3dUBwdmCjy> did we backport or did gk-h backport the bugfixes?
2018-02-15 13:30:17 <hs3dUBwdmCjy> i thought gk-h is the maintainer of lts? what do i misunderstand?
2018-02-15 13:30:21 <ncopa> gk-h
2018-02-15 13:30:35 <ncopa> but he only backports for vanilla kernel
2018-02-15 13:30:38 <BernhardG> Yes, right, hs3dUBwdmCjy. I don't think it would be a problem to have 4.9 instead of 4.14 in Alpine 3.7. But it is not possible to merge it with grsecurity patches if I understand right.
2018-02-15 13:30:51 <ncopa> those backports no longer apply to the grsec kernel
2018-02-15 13:31:12 <hs3dUBwdmCjy> ah. i see.
2018-02-15 13:31:15 <ncopa> the fixes for intel issues are not comaptible with grsecurity
2018-02-15 13:31:16 <BernhardG> If I read it right 4.9 uses KAISER but 4.14 uses KPTI
2018-02-15 13:31:25 <ncopa> that too
2018-02-15 13:31:34 <hs3dUBwdmCjy> ah, but the intel bugfixes for 4.9 suck donkeyballs anyway
2018-02-15 13:31:39 <ncopa> the fixes for 4.9 is broken from what i read
2018-02-15 13:31:43 <ncopa> exactly
2018-02-15 13:32:49 <BernhardG> IMHO (and I don't know the Alpine community as I only use it since 6 days) the most robust solution will be to switch to 4.14 (vanilla) for now.
2018-02-15 13:33:11 <ncopa> that is the current plan
2018-02-15 13:33:36 <BernhardG> If someone again maintains the hardened patches the could get integrated again (for 4.14).
2018-02-15 13:33:55 <ncopa> only spender and pipacs can do that
2018-02-15 13:34:17 <ncopa> and they dont release their work for public
2018-02-15 13:35:03 <ncopa> i asked spender for a (test) 4.14 patch, but got a clear no
2018-02-15 13:35:23 <ncopa> that was before intel bugs
2018-02-15 13:35:30 <ncopa> (i think)
2018-02-15 13:35:57 <ncopa> basically, if you want grsecurity you need to buy it and build it yourself
2018-02-15 13:36:28 <BernhardG> Doesn't gentoo still provide grsecurity/hardened patches?
2018-02-15 13:36:38 <BernhardG> If so - where are they from?
2018-02-15 13:36:48 <hs3dUBwdmCjy> the past
2018-02-15 13:37:51 <ncopa> no
2018-02-15 13:37:51 <ncopa> are there any recent patches for gentoo?
2018-02-15 13:38:17 <ncopa> also upstream kernel developers tries to port parts of grsecurity and gets it wrong
2018-02-15 13:38:47 <ncopa> we did the unofficial fork as long as it was possible
2018-02-15 13:38:58 <ncopa> and used minipli's fork after that
2018-02-15 13:39:11 <danieli> grsec likes reminding everyone that people do bad work at porting / implementing their patches
2018-02-15 13:39:19 <kaniini> jirutka: we intend to actually use dash as /bin/sh, not bash.  but it needs to be fixed.  i may just isolate busybox's version of dash and use that instead.
2018-02-15 13:39:19 <danieli> :'}
2018-02-15 13:40:07 <kaniini> jirutka: as for busybox doing more, it is true, but most of the implementations are not sufficiently robust.  coreutils suite, by far, is the main thing consumers of busybox are using.
2018-02-15 13:41:51 <bulld00zer> just curious, have anyone in the alpine project reached out to Spender and asked?
2018-02-15 13:42:15 <ncopa> yes
2018-02-15 13:42:34 <danieli> bulld00zer: <ncopa> i asked spender for a (test) 4.14 patch, but got a clear no
2018-02-15 13:42:51 <bulld00zer> I see, guess they are really mad which I understand
2018-02-15 13:43:06 <bulld00zer> Not ideal for linux though
2018-02-15 13:43:12 <kaniini> it's not mad, per se
2018-02-15 13:43:14 <BernhardG> And I don't know why he (spender) should to an exception for Alpine.
2018-02-15 13:43:19 <kaniini> it's concentrating on supporting their customers
2018-02-15 13:43:26 <ncopa> yeah, its business
2018-02-15 13:43:41 <kaniini> if you give stuff away for free and it just gets you drama
2018-02-15 13:43:42 <kaniini> why bother
2018-02-15 13:44:14 <BernhardG> Gentoo seems to have stopped grsec too. https://www.gentoo.org/support/news-items/2017-08-19-hardened-sources-removal.html
2018-02-15 13:44:29 <bulld00zer> What I meant was pissed of because no big entities gave  money back... Like Cisco is not doing with openssh
2018-02-15 13:45:33 <ncopa> thats also business
2018-02-15 13:45:35 <ncopa> rip someone off til they get enough, then find someone else to rip off
2018-02-15 13:45:57 <danieli> yep
2018-02-15 13:45:57 <kaniini> anyway
2018-02-15 13:46:11 <danieli> capitalism in a nutshell (cough -offtopic cough)
2018-02-15 13:46:12 <kaniini> apk alternatives is on my todo list some time after 3.8
2018-02-15 13:46:12 <BernhardG> How many people (including me) are using Alpine for their business for free?
2018-02-15 13:46:20 <kaniini> adelie linux 2 will be 3.10/4.0/whatever
2018-02-15 13:46:52 <kaniini> well
2018-02-15 13:46:53 <kaniini> that's fine
2018-02-15 13:46:59 <kaniini> you don't expect an SLA
2018-02-15 13:47:11 <ncopa> its perfectly fine to use it for free
2018-02-15 13:47:14 <kaniini> the people who were using the 'free' grsecurity patches honestly
2018-02-15 13:47:23 <kaniini> some of them were pretty nasty people
2018-02-15 13:47:35 <kaniini> and demanded a lot of shit from spender
2018-02-15 13:47:42 <kaniini> so between that and the KSPP
2018-02-15 13:47:49 <bulld00zer> yes
2018-02-15 13:47:50 <kaniini> i can understand why he decided to call it quit
2018-02-15 13:48:02 <kaniini> they wanted SLAs and other nonsense on the testing patch
2018-02-15 13:48:12 <bulld00zer> funny with people that dont pay AND come with demands :P
2018-02-15 13:48:14 <skarnet> I don't think anybody disputed that spender was perfectly justified in doing what he did
2018-02-15 13:48:21 <kaniini> if you saw on twitter, people ripped on them for problems in the testing patches, really nasty stuff
2018-02-15 13:48:35 <skarnet> what most people (me included) disagree with is the attitude he had, and still has :P
2018-02-15 13:49:12 <kaniini> i think a lot of that has to do with the vocal minority who surrounded grsec
2018-02-15 13:49:25 <BernhardG> I think the Mr bad-behavior does not just sit on one side of the table. ;)
2018-02-15 13:49:25 <kaniini> we dealt with a lot of those guys when grsec went private
2018-02-15 13:49:29 <kaniini> they came here demanding we fork it
2018-02-15 13:50:07 <kaniini> i'm not saying spender hasn't made an ass of himself on multiple occasions
2018-02-15 13:50:10 <kaniini> but i can understand his frustrations
2018-02-15 13:50:16 <skarnet> totally
2018-02-15 13:50:26 <kaniini> if you're getting hit with crap on one side (toxic community) and then also another side (KSPP)
2018-02-15 13:50:33 <kaniini> you're probably going to be pretty grouchy
2018-02-15 13:50:58 <skarnet> definitely, but then there's the public image aspect
2018-02-15 13:51:11 <BernhardG> I also fully understand his frustration. But I fear he also has annoyed some possible customers with his words.
2018-02-15 13:51:12 <skarnet> if you're enough of an ass in public, that certainly doesn't help your situation :P
2018-02-15 13:51:17 <kaniini> spender does not strike me as somebody who cares about that (:
2018-02-15 13:52:09 <kaniini> BernhardG: yes, i suspect that may be part of why KSPP is a thing to begin with
2018-02-15 13:52:13 <kaniini> but this horse has been beaten so many times here
2018-02-15 13:52:17 <kaniini> so lets move onto something else
2018-02-15 13:52:27 <ncopa> i dont think they want or need many customers
2018-02-15 13:52:35 <BernhardG> Another thing I asked me already some years ago: why there is noone else that programs similar patches if there is so much demand.
2018-02-15 13:53:07 <BernhardG> s/me/myself
2018-02-15 13:53:13 <kaniini> because it's hard
2018-02-15 13:53:14 <ncopa> because its hard
2018-02-15 13:53:21 <skarnet> because it's hard
2018-02-15 13:53:38 <skarnet> (nobody else?)
2018-02-15 13:53:43 <kaniini> meanwhile at adelie
2018-02-15 13:53:47 <kaniini> coreutils-8.29-r1 installed size: 1105920
2018-02-15 13:53:52 <kaniini> maybe i should upstream this
2018-02-15 13:54:04 <kaniini> because on alpine
2018-02-15 13:54:15 <kaniini> coreutils-8.29-r0 installed size: 5394432
2018-02-15 13:54:19 <skarnet> wat
2018-02-15 13:54:26 <ncopa> whats the diff?
2018-02-15 13:54:35 <kaniini> --enable-single-binary=symlinks
2018-02-15 13:54:44 <skarnet> ew
2018-02-15 13:55:11 <BernhardG> Ok, but who knows if spender is really able to write those patches?
2018-02-15 13:55:22 <kaniini> in other words, coreutils is like busybox now ;)
2018-02-15 13:55:31 <clandmeter> BernhardG: just submit your PR, it makes no sense to review it twice.
2018-02-15 13:55:44 <BernhardG> clandmeter, fine. Thank you
2018-02-15 13:55:45 <skarnet> yeah, well, I can understand how it's justified for busybox
2018-02-15 13:55:54 <skarnet> but for GNU stuff, wtf
2018-02-15 13:56:15 <kaniini> skarnet: well, basically, it means coreutils becomes essentially a static PIE that is still linked against libc
2018-02-15 13:56:27 <kaniini> so that is how you cut 4MiB off ;)
2018-02-15 13:56:34 <skarnet> it's disk
2018-02-15 13:56:44 <skarnet> only people like ncopa care about disk :P
2018-02-15 13:56:53 <kaniini> i care about disk
2018-02-15 13:56:54 <ncopa> and docker apparently
2018-02-15 13:57:15 <skarnet> I care about disk when there's no tradeoff with ram and cpu
2018-02-15 13:57:16 <kaniini> not for adelie desktop, but for adelie core we care about disk
2018-02-15 13:57:26 <skarnet> and single-binary does have those tradeoffs
2018-02-15 13:58:04 <skarnet> adelie-core should use sbase then, not coreutils ;)
2018-02-15 13:58:23 <kaniini> we have not audited sbase yet
2018-02-15 13:58:34 <skarnet> I should do it sometime
2018-02-15 13:58:44 <kaniini> and in general, i doubt there is philosophical alignment with us and suckless.org
2018-02-15 13:58:55 <skarnet> what are the disagreements?
2018-02-15 13:59:16 <kaniini> for example, we like long options, and from what i have seen of suckless.org tools, they don't
2018-02-15 13:59:28 <skarnet> indeed
2018-02-15 14:00:48 <kaniini> skarnet: also, overall, the single-binary overhead is minimal, since there's only one copy of it in RAM at any time
2018-02-15 14:00:53 <kaniini> (in this case)
2018-02-15 14:01:24 <skarnet> that's actually the worst case
2018-02-15 14:01:35 <skarnet> when you have several copies, the text and rodata are shared
2018-02-15 14:04:28 <kaniini> anyway
2018-02-15 14:04:30 <kaniini> ncopa: http://tpaste.us/m5gE
2018-02-15 14:04:34 <kaniini> ncopa: your thoughts?
2018-02-15 14:07:40 <kaniini> skarnet: well, that is basically the same scenario as building your software as static PIE ;)
2018-02-15 14:08:19 <skarnet> yeah, I don't like static pie, it's not really static :/
2018-02-15 14:11:58 <kaniini> most likely the future is to write new busybox type thing from ground up using modern, secure C programming practices
2018-02-15 14:12:05 <kaniini> but that's not where we are today
2018-02-15 14:12:28 <kaniini> so shaving 4MiB off coreutils is not too shabby
2018-02-15 14:20:08 <Shiz> sbase is not really viable from my experience
2018-02-15 14:20:33 <Shiz> skarnet: how is it not static?
2018-02-15 14:20:56 <skarnet> try ldd'ing a static pie binary
2018-02-15 14:21:50 <skarnet> it's actually a shared ELF like a .so
2018-02-15 14:22:12 <kaniini> correct
2018-02-15 14:22:44 <TBB> Shiz: can you elaborate on that experience a bit?
2018-02-15 14:23:19 <Shiz> it's missing a LOOOOT
2018-02-15 14:23:24 <Shiz> skarnet: that is true, but it's still static
2018-02-15 14:24:04 <Shiz> that's more a quirk of the ELF format than anything else
2018-02-15 14:24:08 <Shiz> it has no real implications otherwise
2018-02-15 14:24:18 <skarnet> well I don't like when objdump lies to me
2018-02-15 14:27:20 <przemoc> skarnet: why you bother about semantics in this case?  as long as static pie bin serves its purpose, why it is a problem that it's actually shared ELF under the hood?
2018-02-15 14:28:32 <skarnet> because I like to verify I've correctly built my static binaries, and when ldd/objdump don't give me what I instinctively expect, it stresses me out
2018-02-15 14:28:46 <skarnet> and I waste time verifying further
2018-02-15 14:29:51 <kaniini> :D
2018-02-15 14:30:11 <przemoc> you need new tool: s6-is-bin-static-pie!
2018-02-15 14:30:38 <skarnet> you jest, but you don't know how much hair I've torn out fighting with libtool
2018-02-15 14:31:20 <kaniini> well this coreutils change seems to be working pretty decent
2018-02-15 14:31:22 <skarnet> and GNU projects that need separate flags in configure and in make so that libtool links statically and binaries that don't use libtool also link statically
2018-02-15 14:32:05 <Shiz> skarnet: should use file(1) :P
2018-02-15 14:32:12 <Shiz> kaniini: as long as we don'tm ake coreutils default
2018-02-15 14:32:49 <kaniini> shiz: coreutils is default in adelie already
2018-02-15 14:32:59 <kaniini> i have no interest in making it default in alpine
2018-02-15 14:33:08 <ncopa> kaniini: we have a few tools in separate packages
2018-02-15 14:33:19 <ncopa> like sfdisk
2018-02-15 14:33:36 <kaniini> yes, but coreutils does not have any splits
2018-02-15 14:33:48 <ncopa> oh, its maybe util-linux
2018-02-15 14:33:51 <kaniini> (other than the manpages)
2018-02-15 14:34:12 <ncopa> then it should work
2018-02-15 14:34:52 <TBB> could it be treated that way without too much effort tho? preferably with a meta package to pull all of them if one's so inclined
2018-02-15 14:36:16 <ncopa> kaniini: im ok to push it to edge
2018-02-15 14:46:00 <kaniini> done
2018-02-15 14:46:33 <kaniini> we have cross-compile patch, but i suspect it is obsolete with this single-binary work
2018-02-15 14:46:40 <kaniini> i should look into that :)
2018-02-15 14:58:46 <clandmeter> what is the current status of enforcing licensing format?
2018-02-15 14:59:31 <kaniini> the current status is no
2018-02-15 14:59:52 <clandmeter> keep as is?
2018-02-15 15:00:16 <kaniini> need to revisit in 3.9
2018-02-15 15:00:23 <kaniini> we have found many licenses that SPDX did not have awareness of
2018-02-15 15:00:34 <clandmeter> i mean for new apkbuilds it would make sense to follow something?
2018-02-15 15:01:00 <kaniini> for new apkbuilds, please follow SPDX 3 with the quirk that "GPL-2.0-or-later" can be "GPL-2.0+"
2018-02-15 15:01:09 <kaniini> but enforcing it with code is presently no
2018-02-15 15:01:30 <clandmeter> right, no i mean mostly for reviewing.
2018-02-15 15:01:53 <kaniini> maybe with 3.9 we can enforce in code, but it won't make the 3.8 release cycle for sure
2018-02-15 15:39:25 <przemoc> kaniini: I had access to ppc64 (not le, though) very briefly last year, so no longer remember stuff, but aren't older ppc arch defines exposed by gcc on them too perhaps?  IOW aren't you perhaps forcing BE on ppc64le in case of lcms pkg?
2018-02-15 15:47:13 <kaniini> ...
2018-02-15 15:47:17 <kaniini> i'm not doing anything
2018-02-15 15:47:29 <kaniini> the problem is lcms build system is fucking stupid ;)
2018-02-15 15:49:04 <kaniini> their build system goes
2018-02-15 15:49:09 <kaniini> LOL POWERPC MUST BE BIG ENDIAN YEP
2018-02-15 15:49:19 <kaniini> i just didn't kill all of the nonsense
2018-02-15 15:49:26 <kaniini> and it's all nonsense too
2018-02-15 15:49:39 <kaniini> because autoconf determines it on it's own
2018-02-15 15:50:09 <przemoc> ok, I was referring to ppc64le.patch that you added
2018-02-15 15:50:26 <kaniini> yes
2018-02-15 15:50:31 <Shiz> kaniini: can't we just convert everything with a nonconforming license to something like misc:<license> and revisit later?
2018-02-15 15:50:34 <Shiz> in that case
2018-02-15 15:50:36 <kaniini> my patch is removing that nonsense
2018-02-15 15:50:36 <kaniini> not adding it
2018-02-15 15:50:39 <Shiz> so we at least have the other bulk converted
2018-02-15 15:50:54 <kaniini> Shiz: yes, that is not what i am talking about though
2018-02-15 15:50:55 <przemoc> I already suggested notation for non-SPDX licenses
2018-02-15 15:51:10 <przemoc> so it could be used with other SPDX licenses
2018-02-15 15:51:11 <kaniini> Shiz: what i am talking about is "enforcing it in abuild"
2018-02-15 15:51:17 <Shiz> ah rgr
2018-02-15 15:51:54 <kaniini> we have completed a license audit and SPDX conversion on the entire adelie supported package set btw
2018-02-15 15:52:09 <kaniini> that has been trickling into alpine over past week or so
2018-02-15 15:56:54 <kaniini> przemoc: ok i defanged it this time
2018-02-15 15:57:38 <kaniini> przemoc: so many __powerpc__ #ifdefs ;/
2018-02-15 16:00:58 <kaniini> seems at some point there was an ABI change on armhf, and boost was not rebuild
2018-02-15 16:01:26 <przemoc> indeed (regarding ppc)
2018-02-15 16:22:20 <koldbrutality> is isinff defined in musl?
2018-02-15 16:22:56 <koldbrutality> i see isinf
2018-02-15 16:27:38 <koldbrutality> i think I give up on electron.  i will pass it on to someone else who wants to finish it.  i got it to run the --help but it just segfaults.
2018-02-15 16:29:13 <koldbrutality> its a nightmare because it uses chromium and node as internal dependencies... takes too long to compile
2018-02-15 16:30:05 <koldbrutality> cannot port atom editor or vscode without electron
2018-02-15 16:34:47 <danieli> a huge amount of things are based on electron and CEF
2018-02-15 16:39:33 <koldbrutality> I upload it to https://github.com/orsonteodoro/electronapkbuild
2018-02-15 16:39:41 <koldbrutality> you guys can finish it
2018-02-15 16:49:03 <koldbrutality> i working on creating lmms package now.  music creation software
2018-02-15 21:40:35 <AWilcox[m]> jirutka: I have seen this weird makedepends error before.  What caused it on Adelie builders was outdated musl package conflicting with newer musl-dev package.  So it seems that a package installed on all builders is older version and ruby-rugged is pulling in -dev package that conflicts.
2018-02-15 21:40:54 <AWilcox[m]> That could be libgit2, ruby, rake
2018-02-15 21:41:17 <AWilcox[m]> The solution is to apk upgrade the builders
2018-02-15 21:42:27 <AWilcox[m]> It is probably the libgit2 though.
2018-02-15 22:53:44 <koldbrutality> got lmms to show gui with paxmark... going to recompile with qt5
2018-02-15 23:50:26 <koldbrutality> anyone know anything about packaging creative commons?
2018-02-15 23:50:53 <koldbrutality> there are some audio plugins released under creative commons but didn't specified the version number
2018-02-15 23:51:21 <koldbrutality> how should that be handled?  they were released as cc-by or cc-by-nc
2018-02-15 23:51:41 <koldbrutality> i mean demos
2018-02-16 00:02:18 <koldbrutality> i think i will just release it without cc demos
2018-02-16 07:24:14 <koldbrutality> hum... i could get stepmania working on software rendering but not on my ati / hw accelerated opengl
2018-02-16 10:55:25 <przemoc> koldbrutality: not sure what audio plugins you meant (or demos?), but you could try contacting upstream and ask them to clarify which version of CC BY or CC BY-NC they meant if they didn't specify that explicitly within released tarballs.  if you were actually talking about demos being some audio files (mp3, etc.), then I don't think that kind od static assets should be in AL repos, but others may
2018-02-16 10:55:31 <przemoc> disagree perhaps.
2018-02-16 13:27:25 <mps> how to request rebuild some package in testing (in this case https://bugs.alpinelinux.org/issues/8483)
2018-02-16 14:00:52 <clandmeter> mps: ok now?
2018-02-16 14:11:43 <mps> clandmeter: don't understand what you mean by "ok now?"
2018-02-16 14:15:17 <clandmeter> mps: i problably didnt get the point. sorry.
2018-02-16 14:17:10 <mps> clandmeter: no problem. there is patch on bug report for tcsh which fixes crash
2018-02-16 14:18:03 <mps> clandmeter: so, I asked could be somehow tcsh rebuilt
2018-02-16 14:19:12 <clandmeter> there is a PR for that issue
2018-02-16 14:19:21 <clandmeter> and it has an issue to build, which i just fixed.
2018-02-16 14:19:50 <clandmeter> just need somebody to look at that patch.
2018-02-16 14:21:02 <mps> I'm patched tcsh about two months ago with patch and now it works on armhf, aarch64 and x86 without problem
2018-02-16 14:21:22 <mps> I didn't tried other arch's
2018-02-16 14:29:25 <Shiz> ncopa: ping
2018-02-16 14:29:29 <Shiz> https://git.alpinelinux.org/cgit/aports/commit/main/procps/APKBUILD?id=d37343ea71ef531a6c40389307fd1cda6e5ea3fa
2018-02-16 14:29:36 <Shiz> why did you make this change? why can't procps live in /usr?
2018-02-16 14:29:46 <Shiz> as it stands it will cause busybox symlinks to take prio over procps tools
2018-02-16 14:33:33 <ncopa> 2013
2018-02-16 14:34:00 <Shiz> ok if i make it live in /usr then?
2018-02-16 14:36:01 <ncopa> i think the idea back then was that it sould be possible to have /usr on separate partition
2018-02-16 14:36:02 <ncopa> i dunno why anybody would want that today though
2018-02-16 14:36:54 <ncopa> Shiz: i dont mind you move it back to /usr, but please verify the busybox location for the tools
2018-02-16 14:36:55 <ncopa> and make them correspond
2018-02-16 14:37:39 <Shiz> of course
2018-02-16 14:37:47 <Shiz> that's the intention of my patch :)
2018-02-16 14:38:12 <ncopa> i dunno how much we care about supporting /usr on separate partition
2018-02-16 14:38:24 <BernhardG> At the moment they do not correspond btw.
2018-02-16 14:38:45 <ncopa> yeah so it should be fixed
2018-02-16 14:39:52 <Shiz> in my opinion separate partition /usr is deprecated by mkinitfs
2018-02-16 14:40:08 <Shiz> initramfs's should proivide all the tools needed for booting a system
2018-02-16 14:40:20 <skarnet> ...
2018-02-16 14:40:56 <skarnet> sure, why have a reliable, small, easily buildable rootfs when you can instead have an initramfs that's much harder to make and edit
2018-02-16 14:41:01 <skarnet> it's so much more fun
2018-02-16 14:41:11 <Shiz> it's not though
2018-02-16 14:41:31 <skarnet> are you seriously arguing that an initramfs is as transparent as a rootfs
2018-02-16 14:42:24 <duncan^> back in the day we didn't have this initramfs funny business
2018-02-16 14:42:34 <skarnet> exactly
2018-02-16 14:43:24 <skarnet> initramfs is only useful in specific circumstances (your rootfs is on a funky device you don't want to have the module for baked in your generic kernel)
2018-02-16 14:46:08 <ncopa> basically every rootfs is on a funky device nowdays
2018-02-16 14:47:12 <ncopa> ssd device, scsi, sata, nvme
2018-02-16 14:47:22 <ncopa> we dont want all those baked in the kernel
2018-02-16 14:48:09 <skarnet> then yes, use an initramfs, but between that and putting a whole environment in the initramfs, there's a gap
2018-02-16 14:48:09 <ncopa> we dont even want the filesystem driver baked in the kernel, some want zfs, some want ext4 some want xfs etc
2018-02-16 14:49:12 <skarnet> my main point is that it's easy to see what's on a rootfs and modify it, whereas visualizing and editing an initramfs is impractical
2018-02-16 14:49:36 <skarnet> initramfs feels like magic to the user, and magic is bad
2018-02-16 14:50:42 <ncopa> i dont argue against that
2018-02-16 14:50:46 <ncopa> but you will almost always still need initramfs
2018-02-16 14:50:56 <ncopa> has anyone tested to have /usr on separate partition?
2018-02-16 14:51:05 <ncopa> it may work
2018-02-16 14:51:23 <skarnet> it should
2018-02-16 14:51:36 <skarnet> if it doesn't, it must be fixed
2018-02-16 14:55:01 <BernhardG> What reasons could one have to separate out /usr? At least for virtual environments I can't imagine a useful scenario. And on physical hardware I personally would use LVM to have the possibility to grow with the (disk space) needs.
2018-02-16 14:56:30 <Shiz> an initramfs is just a tarchive
2018-02-16 14:56:33 <Shiz> don't see how it's especially more magic
2018-02-16 14:57:05 <Shiz> however you wanna split out boot-specific parts, /usr is not the solution imo
2018-02-16 14:58:54 <BernhardG> (Shiz, well you can't just "ls" the contents of a tar archive. So it at least needs some extra commands.)
2018-02-16 14:59:10 <Shiz> tar -tf
2018-02-16 15:00:11 <ncopa> its cpio archive, not tar
2018-02-16 15:01:12 <ncopa> there are some interesting setups where separate /usr may make sense
2018-02-16 15:01:38 <ncopa> lets say if you have a bunch of machines in a LAN where you mount /usr on nfs
2018-02-16 15:02:01 <ncopa> you install the app one place and everyone has access to it
2018-02-16 15:02:46 <grharry> I've installed apline 3.7 XEN on flashcard as Dom0,  after going thru https://wiki.alpinelinux.org/wiki/Create_Alpine_Linux_PV_DomU, xl create breaks with libxl: error: libxl_mem.c:202:libxl_set_memory_target: unable to retrieve domain configuration: No such file or directory ! :(
2018-02-16 15:03:21 <BernhardG> Ok, ncopa that surely makes sense. But this does not fully work because the appindex / world is not updated for all machines.
2018-02-16 15:04:23 <ncopa> i dont think anybody use such setup or would use setup
2018-02-16 15:04:26 <ncopa> but its still "interesting" :)
2018-02-16 15:04:38 <darkfader> grharry: try an strace to see what it tries to open
2018-02-16 15:04:52 <darkfader> and check if you're really running in a xen kernel
2018-02-16 15:04:55 <darkfader> does xl list work
2018-02-16 15:05:12 <darkfader> or xl dmesg even
2018-02-16 15:05:21 <grharry> yes xl works
2018-02-16 15:05:23 <grharry> Domain-0                                     0 15990    12     r-----      25.5
2018-02-16 15:05:24 <darkfader> ok
2018-02-16 15:05:38 <darkfader> then it must be some thing like the domubuilder that's missing
2018-02-16 15:05:48 <darkfader> there  could be some log entry in /var/log/xen/...
2018-02-16 15:06:19 <grharry> /var/log/xen is empty
2018-02-16 15:06:40 <darkfader> ok then i go back to saying something about strace :)))
2018-02-16 15:07:07 <grharry> hm ...
2018-02-16 15:08:21 <grharry> open("/etc/ld-musl-x86_64.path", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
2018-02-16 15:08:25 <grharry> is this normal ?
2018-02-16 15:11:28 <ncopa> i think so
2018-02-16 15:11:51 <skarnet> historically /usr on NFS is exactly how big installations worked
2018-02-16 15:11:59 <skarnet> there are still places where it works like that
2018-02-16 15:13:31 <ncopa> i doubt alpine users are interested in that sort of setup
2018-02-16 15:13:59 <skarnet> sure, but my point is, having a minimal working system in / is a good idea
2018-02-16 15:14:30 <BernhardG> skarnet: do you think those installations could use Alpine Linux? I once had a PXE type setup and the client had the requirement to use an "enterprise linux" system (instead of my suggestion to use centos (5)).
2018-02-16 15:14:52 <ncopa> but yeah, that would be a valid reason to support /usr on separate partion
2018-02-16 15:15:21 <ncopa> his point is that it is a generally good idea to minimal working system in /
2018-02-16 15:15:22 <grharry> Hey ncopa !!!
2018-02-16 15:15:30 <skarnet> maybe? honestly if people are woke enough to use Alpine I expect them to be woke enough to ditch NFS
2018-02-16 15:15:31 <grharry> how you 've been !
2018-02-16 15:15:42 <grharry> long time !
2018-02-16 15:15:51 <grharry> https://pastebin.com/yG8F1WjU
2018-02-16 15:16:02 <grharry> care to have a glance ?
2018-02-16 15:16:11 <BernhardG> but either way, I think Shiz' idea was to have busybox and procps working together.
2018-02-16 15:16:13 <ncopa> hi grharry!
2018-02-16 15:16:22 <skarnet> and it's perfectly possible
2018-02-16 15:16:24 <ncopa> grharry: good thanks! how are you?
2018-02-16 15:16:35 <skarnet> just let busybox have its files in /bin and procps in /usr/bin
2018-02-16 15:16:49 <grharry> bbbbbbbusy !!
2018-02-16 15:17:16 <Shiz> ncopa: I don't see why that couldn't be something not-/usr then
2018-02-16 15:17:20 <Shiz> but ah well
2018-02-16 15:17:24 <BernhardG> skarnet: yeah - sure. but then you can't comfortably call things like top (the procps version) without calling /bin/top
2018-02-16 15:17:38 <skarnet> you mean /usr/bin/top ?
2018-02-16 15:17:42 <Shiz> skarnet: the point of busybox syms is that we don't make them if alternative tools are already there
2018-02-16 15:17:50 <ncopa> indeed
2018-02-16 15:17:53 <skarnet> wat
2018-02-16 15:17:55 <BernhardG> skarnet, no busybox is in /usr/bin/top - procps is in /bin/top
2018-02-16 15:18:00 <skarnet> ...
2018-02-16 15:18:03 <skarnet> WHY
2018-02-16 15:18:13 <Shiz> because that's where busybox decided to place top
2018-02-16 15:18:20 <skarnet> always have the minimal tool in /bin and the complete one in /usr/bin
2018-02-16 15:18:22 <Shiz> ask denys
2018-02-16 15:18:40 <skarnet> is Denys responsible for how bb is packaged in Alpine?
2018-02-16 15:18:44 <skarnet> last time I checked he wasn't
2018-02-16 15:18:59 <skarnet> when you build bb there's an option "don't use /usr"
2018-02-16 15:19:04 <skarnet> -> that's what you want to tick
2018-02-16 15:19:31 <skarnet> since PATH has /usr/bin before /bin, if there's a complete version of foobar, "foobar" will call the complete version in /usr/bin/foobar
2018-02-16 15:19:46 <skarnet> and if /usr/bin/foobar doesn't exist, it will exec /bin/foobar, the minimal (bb) version
2018-02-16 15:20:01 <Shiz> relocating all of busybox now would likely be a very bad idea
2018-02-16 15:20:25 <skarnet> ¯\_(ツ)_/¯ never too late to do the right thing
2018-02-16 15:20:31 <skarnet> or is it?
2018-02-16 15:20:46 <Shiz> well i can trivially imagine it breaking user scripts
2018-02-16 15:20:50 <BernhardG> skarnet: your solution to have busybox symlinks in /bin and the other tools ones in /usr/bin sounds like a good solution to me. but I fear that this relocation could destroy several installations.
2018-02-16 15:20:53 <Shiz> that hardcode the location to bb to get the 'correct'
2018-02-16 15:20:57 <Shiz> tool
2018-02-16 15:21:18 <grharry> open("/var/lib/xen/userdata-d.0.00000000-0000-0000-0000-000000000000.libxl-json", O_RDONLY) = -1 ENOENT (No such file or directory)
2018-02-16 15:21:21 <grharry> ?
2018-02-16 15:21:22 <skarnet> that's the very POINT of FHS, if there ever was one
2018-02-16 15:22:11 <grharry> is it  a "NON started" service ?
2018-02-16 15:26:16 <BernhardG> I think there is a possible workaround against a possible breakage... make even more symlinks (from /usr/bin to the new location in /bin)
2018-02-16 15:27:55 <skarnet> no matter what workaround you concoct, replacing an implementation of a tool with another _will_ break some user scripts
2018-02-16 15:28:13 <skarnet> the only way to perform a change is to announce it well in advance
2018-02-16 15:28:35 <skarnet> give people a year or so to change their scripts
2018-02-16 15:28:44 <BernhardG> skarnet: it is still the same tool (busybox). I don't speak for systems that already use the procps package.
2018-02-16 15:30:19 <skarnet> oh, you mean for changing /usr/bin/top to /bin/top? same thing, announce it in advance. Then yes, you can make a /usr/bin/foobar -> ../../bin/foobar symlink. And some time later, when you release a major version, you remove the symlink. If stuff breaks, people have been warned.
2018-02-16 15:34:16 <Shiz> ncopa: I think we should have retpoline in our gcc, if only for the kernel, no?
2018-02-16 15:38:27 <hs3dUBwdmCjy> ncopa: i run /usr on a seperate partition.
2018-02-16 15:42:12 <BernhardG> hs3dUBwdmCjy: what are your main reasons for having /usr split from /, if I am allowed to ask?
2018-02-16 15:49:14 <hs3dUBwdmCjy> mostly historical reasons. but the compartmentalization is still is nice  if any of the partitions fill up, that does have less impact than if it would be shared.
2018-02-16 16:01:31 <danieli> to be fair, people who need to avoid partitions filling up already have monitoring in place
2018-02-16 16:04:22 <skarnet> ornot
2018-02-16 16:06:23 <danieli> /shrug
2018-02-16 16:33:21 <kaniini> danieli: have you all made any progress with the mips64 port?  i would like to bring up a mips64 machine so i can add support to libucontext :D
2018-02-16 16:33:40 <kaniini> Lochnair ^
2018-02-16 16:33:52 <danieli> i have not had time, sorry
2018-02-16 16:34:20 <danieli> i haven't had enough time to make much progress at all, it hardly went out of the planning phase on my side, and people didn't seem very interested in alpine on mips
2018-02-16 16:34:43 <danieli> i was going to contact an english company who are known to help out with cross-compilation toolchains and providing build hardware to open source projects
2018-02-16 16:34:55 <kaniini> i'm interested and there is a working port (Lochnair did it)
2018-02-16 16:34:57 <kaniini> so dunno
2018-02-16 16:35:08 <kaniini> maybe we can get it done for 3.9
2018-02-16 16:35:12 <kaniini> i have a decent mips64 build machine sitting idle
2018-02-16 16:35:25 <kaniini> 1.2ghz octeon
2018-02-16 16:35:52 <kaniini> not the greatest but it should be able to keep up decently
2018-02-16 16:36:01 <danieli> you do you, locnair is probably interested in joining you in working on that
2018-02-16 16:50:05 <koldbrutality> there is no qtwebengine package?
2018-02-16 16:50:23 <koldbrutality> trying to create the qutebrowser package
2018-02-16 17:02:50 <hs3dUBwdmCjy> koldbrutality: ping jomat re qutebrowser
2018-02-16 17:02:56 <Shiz> kaniini: do we have a 7.3 gcc port?
2018-02-16 17:22:17 <kaniini> shiz: not yet
2018-02-16 17:22:22 <kaniini> we need to solve gcc6/gcc7/gcc8 being installed in parallel
2018-02-16 17:22:27 <Shiz> why?
2018-02-16 17:22:29 <kaniini> because we need gcc6 for java
2018-02-16 17:22:59 <kaniini> gcc6 is the last gcc version to include GCJ
2018-02-16 17:23:07 <Shiz> and there's --program-suffix= is there not
2018-02-16 17:23:21 <danieli> if only portola was easier to keep up with
2018-02-16 17:23:28 <ncopa> we need gcc6's gcc-java to build opendjk7 so we can build openjdk8
2018-02-16 17:23:38 <danieli> what a mess
2018-02-16 17:23:38 <kaniini> Shiz: yes, there is
2018-02-16 17:23:53 <kaniini> Shiz: someone just needs to do the work (someone who cares about gcc7)
2018-02-16 17:24:04 <kaniini> i do not care to compile my kernel with even more patches that will slow it down =)
2018-02-16 17:24:10 <ncopa> i wonder if we can skip gcc7 and just jump to gcc8
2018-02-16 17:24:17 <Shiz> that's a boldly ignorant statement
2018-02-16 17:24:19 <kaniini> danger
2018-02-16 17:24:24 <kaniini> gcc8 has a lot of bugs
2018-02-16 17:24:27 <kaniini> we looked at that for adelie
2018-02-16 17:24:36 <Shiz> I'm compiling a 7.3 port right now
2018-02-16 17:24:51 <Shiz> taking forever because 2 cores though
2018-02-16 17:25:29 <Shiz> ncopa: I don't think it wise to continue to rely on deprecated gcj
2018-02-16 17:25:57 <ncopa> i think we could cp -r main/gcc main/gcc6 and change pkgname to gcc6
2018-02-16 17:26:18 <kaniini> Shiz: we don't rely on gcj
2018-02-16 17:26:27 <kaniini> Shiz: we just need gcj to bootstrap java
2018-02-16 17:26:34 <Shiz> so we do rely on gcj
2018-02-16 17:26:46 <kaniini> Shiz: when something else than gcj comes along we will be sure to switch :P
2018-02-16 17:27:16 <BernhardG> this sounds strange - why is there a dependency between gcj and openjdk?
2018-02-16 17:27:22 <kaniini> you see all these programming languages depend on themselves to bootstrap
2018-02-16 17:27:24 <kaniini> it is really great
2018-02-16 17:27:51 <BernhardG> But you could just download a compiled version of openjdk to build openjdk on alpine.
2018-02-16 17:28:19 <BernhardG> It seems openjdk9 is integrated like that into the alpine docker container
2018-02-16 17:28:24 <ncopa> yes, we rely on gcj to bootstrap java
2018-02-16 17:28:56 <ncopa> nope
2018-02-16 17:28:57 <kaniini> that is a policy violation
2018-02-16 17:29:00 <kaniini> see also: reflections on trusting trust
2018-02-16 17:29:06 <ncopa> the precompiled openjdk does not just run on alpine
2018-02-16 17:29:09 <kaniini> openjdk9 is a different creature
2018-02-16 17:29:16 <kaniini> in openjdk9 case, we use openjdk8, which uses openjdk7
2018-02-16 17:29:21 <kaniini> look java is a nightmare
2018-02-16 17:29:49 <skarnet> more news at 11
2018-02-16 17:29:50 <kaniini> go complain to these java people about bootstrapping :D
2018-02-16 17:29:51 <ncopa> we have similar problem with rust
2018-02-16 17:29:54 <kaniini> in meantime we will have to deal with what we have to deal with
2018-02-16 17:30:57 <kaniini> anyway gcc8 is not stable yet
2018-02-16 17:30:58 <skarnet> making a language easy to boostrap is so 1980
2018-02-16 17:32:22 <kaniini> so i strongly suggest to use gcc 7.3 instead
2018-02-16 17:32:52 <kaniini> but i prefer to keep gcc6 as system compiler still, because even gcc 7 has regressions
2018-02-16 17:42:13 <Shiz> I don't
2018-02-16 17:42:30 <Shiz> unless we backport the retpoline patches
2018-02-16 17:44:26 <kaniini> you can compile your kernel with gcc7
2018-02-16 17:44:48 <kaniini> (actually i would like to see performance hit of retpoline before we just go whole hog on this stuff)
2018-02-16 17:44:59 <kaniini> (because KPTI was pretty brutal)
2018-02-16 17:45:15 <kaniini> notably, if the performance hit is bad, i would like to be able to turn retpoline off at runtime
2018-02-16 17:45:25 <kaniini> because not all workloads require KPTI or retpoline mitigations
2018-02-16 17:45:35 <Shiz> it's not just my kernel, but alpine's
2018-02-16 17:45:50 <Shiz> retpoline's impact is fairly minimal iirc
2018-02-16 17:45:58 <Shiz> not nearly as bad as initial kpti
2018-02-16 17:46:07 <kaniini> well, show us the numbers
2018-02-16 17:46:09 <Shiz> they also do some funky stuff with stack depth tracing to minimize impact further
2018-02-16 17:46:09 <kaniini> because KPTI is brutal
2018-02-16 17:46:20 <Shiz> well, performance is not my argument to make
2018-02-16 17:46:26 <Shiz> I'd even take KPTI if it was needed
2018-02-16 17:46:31 <Shiz> security > moar corez
2018-02-16 17:47:23 <kaniini> *you* would, but some of us actually owuld like git to not take 3x as long to do things in the aports.git tree
2018-02-16 17:47:35 <kaniini> :)
2018-02-16 17:47:46 <kaniini> at least with PTI you can turn it off
2018-02-16 17:49:01 <Shiz> well, that seems like a clear misalignment of project goals then :)
2018-02-16 17:49:15 <kaniini> lets also remember that the 4.9 "KPTI" was a rushed KAISER-derived hack job
2018-02-16 17:49:24 <kaniini> so i mean, realistically, i think we need to do a lot of load testing on these patches
2018-02-16 17:49:27 <kaniini> before we just push them out
2018-02-16 17:49:41 <Shiz> well nobody ever said 4.9 kpti was sufficient or capable
2018-02-16 17:49:44 <Shiz> the focus was always on 4.14 and 4.15
2018-02-16 17:49:50 <kaniini> a mitigation that makes a system completely unreliable is worse than having no mitigation
2018-02-16 17:49:56 <Shiz> 4.9 is a half-done hackjob
2018-02-16 17:50:01 <Shiz> even torvalds said so
2018-02-16 17:51:09 <BernhardG> I just try to compile opendjk7 (on archlinux) with gcc 7.2.1. But it seems to use "itself" (openjdk) to compile.
2018-02-16 17:51:15 <kaniini> does this mean that your goal is to push patches that make systems unreliable ?
2018-02-16 17:51:33 <kaniini> i mean, you agree that reliability is as important as security right
2018-02-16 17:51:59 <Shiz> I'm not sure what would possibly would get you to make that inference but I suggest you stop ding it
2018-02-16 17:52:15 <Shiz> no need to make unbased accusations
2018-02-16 17:52:17 <danieli> are you guys all right? you're bickering like an old married couple
2018-02-16 17:52:42 <kaniini> ideally we want both
2018-02-16 17:52:48 <kaniini> and i think we should prove that these very intrusive changes do not have reliability impact
2018-02-16 17:52:53 <kaniini> because the reliability impact is why we are backporting 4.14 to old releases
2018-02-16 17:52:59 <danieli> we're lucky "spectre" and "meltdown" haven't been weaponized (a lot) yet
2018-02-16 17:53:01 <Shiz> we had more than a month to do it
2018-02-16 17:53:04 <kaniini> BernhardG: yes, and if "itself" is not available yet, you have to use gcj
2018-02-16 17:53:05 <Shiz> where are the numbers?
2018-02-16 17:53:09 <kaniini> and since alpine bootstraps itself from scratch for every release
2018-02-16 17:53:13 <kaniini> this means there is a point in the release where gcj is not yet available
2018-02-16 17:53:44 <BernhardG> kaniini: but this is not solvable in the future (as gcj is almost dead)
2018-02-16 17:53:47 <Shiz> kaniini: btw I t hink we should backport 4.15 rather than 4.14
2018-02-16 17:53:55 <Shiz> it has a more complete mitigation
2018-02-16 17:54:26 <Shiz> either way the 4.9 backport (what you refer to as KPTI) is not really at all related to 4.14 and 4.15
2018-02-16 17:54:29 <BernhardG> 4.14 is LTS, 4.15 is not. does that make a difference for Alpine?
2018-02-16 17:54:49 <Shiz> it was a hackjob done out of necessity for some vendors, doesn't carry at all the same codebase as the 4.14/4.15 mitigation
2018-02-16 17:54:54 <kaniini> Shiz: 4.15 hasn't gone 'stable' yet has it
2018-02-16 17:54:57 <kaniini> we want the tree that is most likely to gain LTS
2018-02-16 17:54:59 <Shiz> yes it has
2018-02-16 17:55:11 <Shiz> 4.15.3 is stable on kernel.org
2018-02-16 17:55:14 <danieli> 4.15.3 is current stable
2018-02-16 17:55:21 <danieli> latest lts is 4.14.19
2018-02-16 17:55:23 <Shiz> but yeah 4.15 won't be LTS, 4.14 will be
2018-02-16 17:55:26 <Shiz> or is, rather
2018-02-16 17:55:31 <kaniini> yes, it makes a difference
2018-02-16 17:55:32 <Shiz> next LTS is like 4.19 or thereabouts
2018-02-16 17:56:06 <kaniini> the [people who maintain alpine kernels] prefer to use LTS tree
2018-02-16 17:56:17 <kaniini> but 4.14 has gone LTS
2018-02-16 17:56:24 <Shiz> afaik only 4.15 has the retpoline mitigtation which helps perf greatly
2018-02-16 17:56:28 <Shiz> yeah i understand
2018-02-16 17:56:57 <kaniini> anyway, i am fine with retpoline but i want to load test it before we even consider backporting it
2018-02-16 17:57:08 <kaniini> the 4.9 "KPTI" left a bad taste
2018-02-16 17:57:21 <kaniini> i mean, i think we both agree that a secure kernel that is unstable under load is not very useful
2018-02-16 17:57:33 <kaniini> i would hope so anyway
2018-02-16 17:58:13 <kaniini> but this raises the question of 4.14 vs 4.15
2018-02-16 17:58:28 <Shiz> yes
2018-02-16 17:58:53 <kaniini> will 4.15 be around a year from now ?
2018-02-16 17:59:04 <Shiz> # gcc --version
2018-02-16 17:59:05 <Shiz> gcc (Alpine 7.3.0) 7.3.0
2018-02-16 17:59:07 <Shiz> :)
2018-02-16 17:59:08 <kaniini> are we sure about that
2018-02-16 17:59:13 <Shiz> kaniini: I can prepare you a retpolined kernel for load testing
2018-02-16 17:59:15 <Shiz> if you desire
2018-02-16 17:59:36 <kaniini> Shiz: there's another reason why we want to keep gcc6 as main compiler
2018-02-16 17:59:56 <kaniini> gcc7 in our testing (in adelie) used 2x the ram
2018-02-16 18:00:00 <kaniini> like the ram increase is brutal
2018-02-16 18:00:06 <kaniini> i'm not sure what they did but it is using a lot more ram now
2018-02-16 18:00:42 <kaniini> so that makes me really nervous about armhf for example
2018-02-16 18:00:46 <kaniini> where we have like 4GB ram max
2018-02-16 18:00:58 <Shiz> mhm
2018-02-16 18:01:01 <Shiz> is that actual ram or virt
2018-02-16 18:01:35 <Shiz> i realise it doesn't make a diff for a 32-bit addr space
2018-02-16 18:01:37 <Shiz> but just curiosity
2018-02-16 18:03:00 <kaniini> need to check again
2018-02-16 18:03:02 <kaniini> maybe next week
2018-02-16 18:03:36 <Shiz> compiling a retpolined 4.15.3 with copperhead -hardened patches right now
2018-02-16 18:07:02 <kaniini> note we still need to sort gcc6 for java
2018-02-16 18:07:23 <kaniini> gcc 7.3 is probably ok to go to for system compiler if we really must
2018-02-16 18:07:37 <kaniini> jumping to gcc 8 is something i am definitely not in favor of right now
2018-02-16 18:07:50 <kaniini> note adelie will have upstream-freeze soon, so would prefer to sort gcc prior to that
2018-02-16 18:09:01 <AWilcox[m]> Shiz, actual RAM
2018-02-16 18:09:23 <AWilcox[m]> ARM will never have KDE if gcc7 is used for system compiler.  gcc6 needs 3.3 GB to compile required geometry_parser module
2018-02-16 18:09:36 <AWilcox[m]> Neither will x86 or any other 32-bit platform
2018-02-16 18:10:31 <Shiz> I agree with not going for gcc8
2018-02-16 18:10:33 <kaniini> yes, will literally run out of address space
2018-02-16 18:10:54 <Shiz> ...swap?
2018-02-16 18:11:03 <AWilcox[m]> https://bts.adelielinux.org/show_bug.cgi?id=47
2018-02-16 18:11:04 <Shiz> oh yeah, address space
2018-02-16 18:11:13 <AWilcox[m]> Shiz, swap doesn't get around the limits of 32-bit address space
2018-02-16 18:11:13 <kaniini> the problem isn't physical ram, it's running out of address space
2018-02-16 18:11:14 <kaniini> that concerns us
2018-02-16 18:11:41 <Shiz> fwiw bts.adelie is not loading
2018-02-16 18:11:45 <AWilcox[m]> Shiz, I'm already having to do terrible hacks just to get llvm to build on x86 because of the address space limitation.  gcc7 would be the end of it
2018-02-16 18:12:29 <Shiz> well you can't be stuck on 6 forever either way :/
2018-02-16 18:12:58 <AWilcox[m]> kaniini, is there a reason bts. and wiki. are only accessible in US?  Haha
2018-02-16 18:13:15 <kaniini> in adelie, we plan to keep gcc6 regardless just for KDE
2018-02-16 18:13:21 <Shiz> ah bts loaded
2018-02-16 18:13:27 <Shiz> it just took... a long time
2018-02-16 18:13:45 <kaniini> and use gcc7 for everything else
2018-02-16 18:13:51 <kaniini> but
2018-02-16 18:15:02 <AWilcox[m]> https://phabricator.kde.org/D10118
2018-02-16 18:15:13 <AWilcox[m]> kaniini, and llvm?  and boost?  and...
2018-02-16 18:15:31 <kaniini> yes, it's a mess
2018-02-16 18:15:36 <AWilcox[m]> No, our plan is to keep 6 until GCC fixes this bug of using so much RAM (apparently on glibc systems it uses > 16 GB!  We're lucky we use musl and it is only 4.) or until clang is suitable as system compiler
2018-02-16 18:16:07 <kaniini> yes i agree
2018-02-16 18:16:07 <AWilcox[m]> Since 8 has so many bugs I haven't really profiled it to see if it fixes this RAM stuff
2018-02-16 18:16:10 <Shiz> # # the default maximum template expansion depth (256) is not enough
2018-02-16 18:16:11 <kaniini> i would prefer to see clang as default cmpiler
2018-02-16 18:16:12 <Shiz> # set_property(SOURCE preview/geometry_parser.cpp APPEND_STRING PROPERTY COMPILE_FLAGS " -ftemplate-depth=512")
2018-02-16 18:16:14 <Shiz> \kde/
2018-02-16 18:16:20 <AWilcox[m]> Hopefully they fix more of the bugs
2018-02-16 18:16:30 <kaniini> compiler*
2018-02-16 18:17:03 <AWilcox[m]> Shiz, it's Boost::Qi
2018-02-16 18:17:07 <AWilcox[m]> That's how Boost::Qi works
2018-02-16 18:17:34 <kaniini> anyway we are stuck with gcc6 on adelie for now.  i guess clang will come later, and maybe gcc7 for kernel only.
2018-02-16 18:17:50 <kaniini> (what the fuck is 'keyboard geometry' anyway)
2018-02-16 18:17:59 <AWilcox[m]> https://cgit.kde.org/plasma-desktop.git/tree/kcms/keyboard/preview/geometry_parser.cpp#n52
2018-02-16 18:18:28 <AWilcox[m]> kaniini, as you change keyboard layouts in the KDE Keyboard control panel, it shows you what every key on a keyboard will do
2018-02-16 18:19:34 <AWilcox[m]> i.e. switching between $ and Euro symbol for shift+4
2018-02-16 18:19:35 <AWilcox[m]> It's virtual key caps
2018-02-16 18:20:41 <kaniini> ... why does this need Boost::Qi
2018-02-16 18:21:04 <AWilcox[m]> https://i.imgur.com/xvjCCwe.png
2018-02-16 18:21:37 <AWilcox[m]> It doesn't, they're rewriting it without Boost::Qi for some future version.
2018-02-16 18:22:00 <kaniini> :D
2018-02-16 18:23:09 <Shiz> time t o reboot for anew kernel
2018-02-16 18:25:05 <BernhardG> I always read about adelie - what it that?
2018-02-16 18:27:18 <AWilcox[m]> BernhardG: a fork of Alpine focused on desktop usage and POSIX conformance
2018-02-16 18:28:30 <BernhardG> sounds quite nice. But it also sounds hard to get some applications ported to musl.
2018-02-16 18:31:44 <Shiz> back on 4.15.3 :)
2018-02-16 18:32:36 <AWilcox[m]> Before Adélie I was a FreeBSD developer, and before that I was a Fedora "documentation engineer" (fancy term for technical writer), and before that I was doing my own kernel
2018-02-16 18:32:37 <AWilcox[m]> This is nothing to me haha
2018-02-16 18:33:01 <AWilcox[m]> Also, because of all the work I did in the past, I'm familiar with the fact that different communities have different needs for contributions, so I'm able to get stuff upstreamed easier because that's just what I've always done
2018-02-16 18:33:51 <Shiz> https://up.shiz.me/NTNkNDll.png
2018-02-16 18:34:04 <AWilcox[m]> The hardest part was KDE, and that was only 8 or 9 patches for the entire framework set and desktop packages.
2018-02-16 18:34:33 <BernhardG> AWilcox[m]: so you are the man if one needs to package a (complex) package for alpine? It might happen that I need ceph. My plan was to use it as docker container but I fear I still need the client libraries.
2018-02-16 18:37:25 <danieli> would probably be a better idea to make a b.a.o issue for it
2018-02-16 18:38:46 <BernhardG> danieli: the package exists already in testing - for an old version. I already have started with a new version but I am not a C developer and therefore I might not be able to finish this.
2018-02-16 18:42:03 <AWilcox[m]> I'm actually not a man
2018-02-16 18:42:20 <AWilcox[m]> And I don't really have time right now to deal with that, there's a Plasma version bump which means there's about 130 packages for meto update...
2018-02-16 18:42:45 <AWilcox[m]> For me to update*
2018-02-16 18:46:05 <BernhardG> AWilcox[m]: for sure. have a lot of fun.
2018-02-16 19:05:48 <Shiz> looks like 4.14.14 may do retpoline
2018-02-16 19:43:39 <Lochnair> kaniini: little late to the party, but yeah it's close. iirc we're only missing the libffi patch and linux-vanilla for octeon before it's bootstrappable
2018-02-16 19:44:55 <Lochnair> kernel configs aren't exactly my forté, so I never got around to making a linux-vanilla config for octeon
2018-02-16 19:45:54 <Lochnair> I've simply copied the config from xypron's repo and used that in my builds
2018-02-16 19:59:31 <tmh1999> late response, I think ncopa's suggestion cp -r main/gcc main/gcc6 is a good idea.
2018-02-16 20:12:04 <tmh1999> until there's another way to bootstrap openjdk, we still need gcc6 in the corner.
2018-02-16 20:13:19 <tmh1999> well we just keep gcc6 there, just for the sake of bootstrapping openjdk, nothing else. other work are for gcc7+.
2018-02-16 20:21:24 <koldbrutality> what is up with: ERROR: libpthread-stubs-0.3-r5: package mentioned in index not found (try 'apk update') ?
2018-02-16 20:29:40 <mmlb> can someone tell me what the `A-Improve` label in aports means?
2018-02-16 20:30:38 <_ikke_> mmlb: it means that something in the PR needs to be improved
2018-02-16 20:47:56 <koldbrutality> my chroot program seems broken
2018-02-16 20:48:25 <koldbrutality> the symlink that is
2018-02-16 20:48:51 <koldbrutality> i have to manually type /usr/bin/coreutils --coreutils-prog=chroot to get it to work
2018-02-16 20:49:35 <BernhardG> Did you try something like this (inside chroot): "export PATH=/usr/bin:$PATH"
2018-02-16 20:56:15 <mmlb> thanks _ikke_ I don't have any further feedback though
2018-02-16 20:56:26 <mmlb> https://github.com/alpinelinux/aports/pull/3252 is the pr
2018-02-16 20:57:20 <mmlb> re-enabling NFP driver that was probably mistakenly dropped from config
2018-02-16 21:00:50 <BernhardG> mmlb: I only know travis from own projects. But for this case (starvation, cancellation, ...) my developers always push 1 byte changes to work around the problem.
2018-02-16 21:01:25 <mmlb> I don't seems like all the kernel builds are timing out though
2018-02-16 21:01:52 <mmlb> I've pushed a commit since first bumping the rev to r1 and same deal... :(
2018-02-16 21:05:15 <koldbrutality> i fixed my libpthread-stubs problem but the chroot thing still bugs me
2018-02-16 21:05:27 <koldbrutality> it was slow mirror server.
2018-02-16 21:06:49 <koldbrutality> i did the export thing and it doesn't work
2018-02-16 21:08:24 <BernhardG> let me check that for you. So you run a alpine host and have an alpine chroot (http://dl-cdn.alpinelinux.org/alpine/v3.7/releases/x86_64/alpine-minirootfs-3.7.0-x86_64.tar.gz) in it?
2018-02-16 21:12:44 <BernhardG> @koldbrutality: on my system the symlink to chroot is wrong (dangling) in /usr/sbin/chroot -> ../usr/bin/coreutils (but it must be ../bin/coreutils)
2018-02-16 21:13:01 <koldbrutality> i have alpine host but gentoo chroot but the alpine host has the broken chroot cmd
2018-02-16 21:13:10 <_ikke_> BernhardG: You know you can just amend the last commit to push again, right?
2018-02-16 21:13:31 <BernhardG> koldbrutality: seems to be a bug in coreutils then
2018-02-16 21:14:25 <BernhardG> _ikke_: but that does not change a actual file.
2018-02-16 21:15:05 <_ikke_> BernhardG: but travis is triggered again
2018-02-16 21:15:12 <koldbrutality> ls /usr/sbin/chroot -al reported: /usr/sbin/chroot -> ../usr/bin/coreutils
2018-02-16 21:15:40 <BernhardG> yeah - that wrong - it must be ../bin/coreutils
2018-02-16 21:15:48 <BernhardG> I will generate a bug report for it.
2018-02-16 21:16:10 <mmlb> amend is what I just did, waiting on build now
2018-02-16 21:18:39 <BernhardG> koldbrutality: #8495 is the issue about that
2018-02-16 21:19:53 <mmlb> has anyone discussed a different ci system in addition to / replacement of travis? I might be able to get work to supply a baremetal_0 and maybe a 2a too @ packet.net
2018-02-16 21:21:30 <kaniini> i fixed it
2018-02-16 21:22:18 <kaniini> sorry about that :)
2018-02-16 21:23:08 <kaniini> mmlb: it will be incorporated into next kernel
2018-02-16 21:23:30 <_ikke_> nmeum: would you be able to provide feedback on https://github.com/alpinelinux/aports/pull/3252 why you added the improve label?
2018-02-16 21:24:10 <mmlb> kaniini?
2018-02-16 21:25:31 <kaniini> mmlb: the netronome config change will be incorporated into next kernel package release
2018-02-16 21:25:52 <mmlb> do you mean upcoming 4.15?
2018-02-16 21:26:01 <mmlb> oh but then why hasn't the PR been merged?
2018-02-16 21:28:40 <kaniini> it will be when next kernel package is done
2018-02-16 21:29:27 <BernhardG> koldbrutality: you can btw. fix that chroot thing by yourself with "ln -sf ../bin/coreutils /usr/sbin/chroot"
2018-02-16 21:29:37 <mmlb> kaniini also is there an ETA on that? I've got other things that depend on it and it'd be nice if I can just make use of the package and not have to build / store myself.
2018-02-16 21:31:13 <koldbrutality> it works thx
2018-02-16 21:31:49 <kaniini> or
2018-02-16 21:31:52 <kaniini> you could just upgrade
2018-02-16 21:31:53 <kaniini> to coreutils 8.29-r2
2018-02-16 21:32:12 <BernhardG> kaniini: it is not yet present on (at least mine) mirror.
2018-02-16 21:32:32 <kaniini> dl-cdn has it
2018-02-16 21:32:33 <kaniini> =)
2018-02-16 21:32:43 <BernhardG> kaniini: many thanks for your really fast fix.
2018-02-17 00:05:59 <nmeum> _ikke_: didn't look at it yet as I am currently on my phone but it might be the case that I added the label by accident as I mostly add labels in bulk
2018-02-17 00:07:41 <nmeum> so if the label is wrong just go ahead and change it ;)
2018-02-17 01:34:17 <koldbrutality> screenfetch seems like it doesn't work
2018-02-17 01:35:10 <koldbrutality> nm
2018-02-17 01:35:36 <koldbrutality> it does wierd stuff.
2018-02-17 01:36:49 <koldbrutality> as in spam pgrep: unrecognized option: U
2018-02-17 01:54:17 <AWilcox[m]> koldbrutality: apk add procps
2018-02-17 01:54:27 <AWilcox[m]> BusyBox pgrep doesn't support -U, procps pgrep does
2018-02-17 07:58:46 <_ikke_> nmeum: I don't have the rights to do that
2018-02-17 16:39:14 <nmeum> _ikke_: which label would you want to use? A-fix?
2018-02-17 16:52:25 <_ikke_> nmeum: You added it because of the failing travis build?
2018-02-17 17:07:26 <koldbrutality> is there a way to find all packages that depend on another package even those not installed?
2018-02-17 17:08:03 <nmeum> _ikke_: huh? no, I added the A-improve label to indicate that this GitHub PR improves the main/linux-vanilla aport
2018-02-17 17:08:24 <Lochnair> koldbrutality: look on pkgs.a.o? pretty sure it's listed there
2018-02-17 17:09:07 <koldbrutality> where is that?
2018-02-17 17:12:10 <Lochnair> e.g. https://pkgs.alpinelinux.org/package/edge/main/x86_64/flac
2018-02-17 17:12:19 <Lochnair> dependents listed under 'required by'
2018-02-17 17:14:08 <koldbrutality> ahh thx
2018-02-17 17:14:34 <Lochnair> np
2018-02-17 17:52:45 <danieli> clandmeter: ncopa: kill that issue ^
2018-02-17 17:54:20 <clandmeter> done thx.
2018-02-17 20:37:14 <_ikke_> nmeum: I had the idea that label meant soemthing else
2018-02-17 21:30:58 <koldbrutality> oh yeah... got qt5-webengine working and qutebrowser working
2018-02-17 21:32:26 <koldbrutality> i will make a pull request but still need to sort out the py3-qt5 subpackage problem because it will pull qt5-webkit and qt5-webengine.  last two should be optional dependencies.
2018-02-18 01:14:41 <koldbrutality> anyone here using older ATI?
2018-02-18 01:19:33 <tmh1999> Lochnair: I've been to those pages millions of time and never looked on the right at "Required by" and such. Thanks!
2018-02-18 01:57:12 <koldbrutality> I don't understand why CI test failed.  Can someone see the log?  https://github.com/alpinelinux/aports/pull/3338
2018-02-18 02:04:15 <danieli> first thing i see is a broken repo
2018-02-18 02:04:22 <danieli> but they're just warnings
2018-02-18 02:04:39 <danieli> oh uh, it might depend on a package that isn't yet in aports?
2018-02-18 02:05:57 <danieli> looks like the version of qt5-qtwebchannel-dev in edge is 5.9.3-r0
2018-02-18 02:07:22 <danieli> i wish apk was more verbose in terms of broken dependencies in virtual packages
2018-02-18 02:13:50 <koldbrutality> ahh
2018-02-18 02:16:32 <koldbrutality> right... i was updating that
2018-02-18 02:56:32 <AWilcox[m]> Define "older ATI"
2018-02-18 02:56:58 <AWilcox[m]> I have a Radeon 9600XT in a PowerBook G4, and a 5750HD in a dual-core workstation.
2018-02-18 03:07:22 <koldbrutality> pre amdgpu driver
2018-02-18 03:08:18 <koldbrutality> or the one that uses xf86-video-ati
2018-02-18 03:08:43 <AWilcox[m]> Both of those match that.
2018-02-18 03:58:23 <koldbrutality> i'm getting a segfault: cool-retro-term[28479]: segfault at 7ff9c64577f8 ip 00007ff9c9d25b48 sp 00007ff9c64577f0 error 7 in r600_dri.so[7ff9c9a9d000+a48000]
2018-02-18 03:58:46 <koldbrutality> i should just release this with software rendering enabled by default
2018-02-18 18:53:41 <koldbrutality> where can i find the source code for default_doc and default_dev ?
2018-02-18 18:54:15 <_ikke_> 1https://git.alpinelinux.org/cgit/abuild/tree/abuild.in#n1547
2018-02-18 18:54:22 <_ikke_> https://git.alpinelinux.org/cgit/abuild/tree/abuild.in#n1633
2018-02-19 01:29:37 <koldbrutality> there is no recursive install option?
2018-02-19 01:29:55 <koldbrutality> for the install cmd?
2018-02-19 05:32:08 <_ikke_> koldbrutality: you mean busybox install?
2018-02-19 05:32:19 <koldbrutality> yeah
2018-02-19 05:33:18 <_ikke_> What recursive option?
2018-02-19 05:34:10 <koldbrutality> yeah
2018-02-19 05:34:33 <_ikke_> ?
2018-02-19 05:34:50 <koldbrutality> instead of: mv html dest
2018-02-19 05:35:53 <koldbrutality> html is a directory tree
2018-02-19 05:36:00 <koldbrutality> with subfolders
2018-02-19 05:37:28 <_ikke_> No, I don't think so
2018-02-19 05:37:36 <_ikke_> install works on files, not complete directories
2018-02-19 05:42:40 <koldbrutality> i tried to use find but it moved everything into only one folder
2018-02-19 05:43:05 <_ikke_> why not cp -r?
2018-02-19 05:43:29 <koldbrutality> i just want to use install command only... nm
2018-02-19 05:43:55 <_ikke_> then you have to be very explicit
2018-02-19 05:44:06 <_ikke_> create each dir, install files into that dr
2018-02-19 05:44:08 <_ikke_> dir
2018-02-19 10:02:14 <koldbrutality> why does subpackage="$pkgname-dev" need to be explicitly called?
2018-02-19 10:03:33 <liwakura> would break packages that are headers-only i guess
2018-02-19 12:54:59 <clandmeter> Natanael Copa: what do you think about adding netboot to official repos?
2018-02-19 13:04:28 <ncopa> sounds like something we should have done ages ago
2018-02-19 13:07:45 <clandmeter> story of our lives :)
2018-02-19 13:08:22 <fcolista> :)
2018-02-19 13:08:58 <clandmeter> i wonder how we should add them
2018-02-19 13:09:11 <clandmeter> should we only include the latest release?
2018-02-19 15:50:11 <clandmeter> is there a specific reason we are still using gzip compression on initramfs?
2018-02-19 15:51:16 <clandmeter> fabled: ^
2018-02-19 16:20:59 <fabled> clandmeter, dunno. i think it's just how it was setup and no one has seen reasons to change it
2018-02-19 16:21:10 <fabled> i know xz etc are slower/more ram consuming
2018-02-19 16:21:20 <fabled> i remember we did have some discussion about it earlier
2018-02-19 16:21:45 <clandmeter> yes, but for network boot xz could be interesting.
2018-02-19 16:22:40 <clandmeter> so i think adding this option to mkinitfs could be interesting.
2018-02-19 16:22:43 <fabled> i think we have several options enabled so other compression methods could be used
2018-02-19 16:22:53 <fabled> yeah, 1st step would be to add an option to change it
2018-02-19 19:05:29 <teiresias> I think the /boot/boot symlink created by mkinitfs needs to point at ".", not "/".  Otherwise it is incorrect in the case of no separate boot partition.
2018-02-19 19:06:21 <liwakura> teiresias: i think i saw a patch on the mailing list yesterday
2018-02-19 19:06:26 <liwakura> for exactly that issue
2018-02-19 19:06:55 <teiresias> Yeah that was me, to alpine-aports.
2018-02-19 19:07:23 <teiresias> I apparently flubbed the committer info; wonder if I shouldn't resend that.
2018-02-19 20:28:41 <andypost> can anyone check/accept that https://github.com/alpinelinux/aports/pull/3359
2018-02-19 20:58:46 <nmeum> andypost: looks gode, merged
2018-02-19 20:58:47 <nmeum> thanks!
2018-02-19 21:23:13 <BernhardG> hi, I use the alpine-make-vm-image script from https://github.com/alpinelinux/aports/pull/3322 and I think I have found a bug. the script itself supports ext4, xfs and btrfs. In my own tests I've found out that an xfs image does not boot.
2018-02-19 21:24:45 <BernhardG> I've now changed the script in a way that it creates a partition table and one large partition. after that change xfs boots. do you think this is indeed needed and should I file a bug?
2018-02-19 21:25:01 <BernhardG> correct link https://github.com/alpinelinux/alpine-make-vm-image
2018-02-19 21:25:47 <_ikke_> You can always file a bug if it does not work
2018-02-19 21:28:03 <BernhardG> I will file a bug for it.
2018-02-19 21:33:42 <BernhardG> done. it took a while to understand that xfs can't boot if there is no partition table.
2018-02-19 22:54:58 <koldbrutality> have to explicitly call $pkgname-doc to package documents :'(
2018-02-19 22:57:18 <liwakura> koldbrutality: if you have several hundred instances of the same alpine image running, you will be happy about the fact that you can install stuff without manpages on alpine ^
2018-02-19 22:57:57 <koldbrutality> the other package manager does stuff automatically
2018-02-19 22:58:14 <koldbrutality> i'm trying to learn this one but has different personality
2018-02-19 22:59:50 <koldbrutality> when you say default to me it implies automatically done but it doesn't do it in this system
2018-02-19 23:37:33 <mps_> last night I talked about booting to f2fs root partition, which didn't worked making initramfs
2018-02-19 23:38:26 <mps_> solved by adding fscryto module in /etc/mkinitfs/features.d/f2fs.modules
2018-02-19 23:39:10 <mps_> i.e. adding line 'kernel/fs/crypto/fscrypto' in that file
2018-02-19 23:40:12 <mps_> looking into /etc/mkinitfs/features.d/ext4.modules I see there are crc32 modules
2018-02-19 23:41:28 <mps_> question is: should these crc32 modules be added also to the /etc/mkinitfs/features.d/f2fs.modules
2018-02-19 23:43:14 <mps_> another question: shouldn't /etc/mkinitfs/features.d/f2fs.modules be fixed because this looks like a bug, for me at least
2018-02-19 23:45:47 <dehoptu[m]> File a bug if it won't boot without your addition. I did the same for crc32 in ext4 which was fixed
2018-02-19 23:45:53 <dehoptu[m]> or file a PR that makes the change directly
2018-02-19 23:47:39 <mps_> dehoptu[m]: I'm not sure how to file a bug (yet) in Alpine and I don't have github account
2018-02-19 23:49:25 <mps_> dehoptu[m]: but, maybe I can look tomorow to bugs.a.o to see how to fil a bug
2018-02-20 00:36:32 <Shiz> hmm
2018-02-20 00:36:34 <Shiz> on v3.7:
2018-02-20 00:36:36 <Shiz> immunity:~# clang++
2018-02-20 00:36:38 <Shiz> Error relocating /usr/bin/clang++: _ZSt11__once_call: symbol not found
2018-02-20 00:36:40 <Shiz> Error relocating /usr/bin/clang++: _ZSt15__once_callable: symbol not found
2018-02-20 00:36:42 <Shiz> this seems wrong
2018-02-20 02:06:06 <koldbrutality> anyone know about running tests in emacs?
2018-02-20 02:08:40 <koldbrutality> nm the package has a Makefile rule
2018-02-20 02:25:13 <koldbrutality> this is lame... too many check dependencies
2018-02-20 02:25:41 <koldbrutality> i want to work on creating new packages not testing them
2018-02-20 13:49:47 <tmh1999> Currently we call the bootloader before install necessary packages : https://git.alpinelinux.org/cgit/alpine-conf/tree/setup-disk.in#n459 and #n485. But for s390x, I need to install the kernel in the target device before running the bootloader, as it requires that way. Is it strange or wrong to do so ?
2018-02-20 13:50:02 <tmh1999> apparently it works without a problem, but I just want to make sure.
2018-02-20 14:36:09 <ncopa> tmh1999: i think the idea of running setup_syslinux before installing packagages is that we set up the update-syslinux.conf before we install the packages
2018-02-20 14:36:41 <ncopa> that way the trigger script for syslinux will create the boot config properly
2018-02-20 14:36:57 <ncopa> im not sure we have a trigger script for grub
2018-02-20 14:37:24 <tmh1999> ncopa: agreed. setup_syslinux only install the config files. but for the case of s390x, the bootloader requires the kernel to be present on /mnt/boot (aka target device'a /boot)
2018-02-20 14:37:43 <ncopa> do you need re-run the bootloader every time kernel is updated?
2018-02-20 14:37:44 <tmh1999> I am thinking about shipping vmlinuz and initramfs inside the iso
2018-02-20 14:38:05 <tmh1999> I have not checked that.
2018-02-20 14:38:10 <ncopa> can s390x boot from iso images?
2018-02-20 14:38:23 <liwakura> tmh1999: just for clarification, i though the kernel is always installed first and then triggers the extlinux install?
2018-02-20 14:38:24 <tmh1999> other distro can
2018-02-20 14:38:31 <liwakura> *thought
2018-02-20 14:39:05 <ncopa> liwakura: that is correct
2018-02-20 14:39:12 <tmh1999> ncopa : some setup just uses the kenrel + initramfs . some use the iso( which also contains the kernel + initramfs)
2018-02-20 14:39:51 <ncopa> tmh1999: i think we need to run bootloader install from triggerscript
2018-02-20 14:40:21 <tmh1999> what triggerscript ?
2018-02-20 14:40:25 <tmh1999> ncopa: ^
2018-02-20 14:40:25 <ncopa> lets say we have 2 different kernels, linux-hardened and linux-vanilla, that both works on s390x
2018-02-20 14:40:32 <ncopa> and a user want replace linux-vanilla with linux-hardened
2018-02-20 14:40:53 <ncopa> then we need to re-run the bootloader install, right?
2018-02-20 14:41:11 <tmh1999> probably yes, I haven't checked.
2018-02-20 14:41:18 <tmh1999> oh right
2018-02-20 14:41:21 <ncopa> the update-extlinux script is run when any package modifies /boot/*
2018-02-20 14:41:37 <tmh1999> trigger in the kernel's after-install / after upgrade script ?
2018-02-20 14:41:44 <tmh1999> okay
2018-02-20 14:41:57 <tmh1999> I think I understand
2018-02-20 14:42:03 <ncopa> https://git.alpinelinux.org/cgit/aports/tree/main/syslinux/syslinux.trigger
2018-02-20 14:42:08 <tmh1999> yes
2018-02-20 14:42:36 <liwakura> ncopa: where is that called from? hardcoded into apk?
2018-02-20 14:42:46 <tmh1999> okay cool thanks ncopa. I have been litterally waiting for 3 months for politics to settle down how I can get a test server ...
2018-02-20 14:42:47 <ncopa> and this: https://git.alpinelinux.org/cgit/aports/tree/main/syslinux/APKBUILD#n12
2018-02-20 14:42:59 <liwakura> ah i see
2018-02-20 14:43:18 <ncopa> ouch...
2018-02-20 14:44:02 <liwakura> i wish i had access to an IBM zSeries
2018-02-20 14:44:17 <ncopa> tmh1999: i wonder if you could report the fftw issue upstream
2018-02-20 14:44:21 <ncopa> there are more packages that fails now due to lacking fftw
2018-02-20 14:44:32 <tmh1999> ncopa: also re: main/liboil, I reported upstream, but they are kind of inactive. main/audit and main/fftw : sometimes I build good, sometimes it fails, either container or KVM. So I guess we !check for these 2. I didn't know fftw so I disabled it all they way ...
2018-02-20 14:45:09 <tmh1999> ncopa: it's all unstable between containers env... this is  what we've been having for a while. I should've just !check
2018-02-20 14:45:16 <ncopa> liwakura: https://developer.ibm.com/linuxone/resources/faq/
2018-02-20 14:45:38 <tmh1999> liwakura : if you need Linux env, checkout LinuxONE Community Cloud. they're giving for free.
2018-02-20 14:46:14 <tmh1999> liwakura: If you need lower than Linux, it's expensive. kaniini once wanted to buy one but they quoted him too much. \o/
2018-02-20 14:46:16 <ncopa> i think its free for 120 days or so
2018-02-20 14:46:23 <tmh1999> ncopa: !check works for you ?
2018-02-20 14:46:25 <liwakura> interesting
2018-02-20 14:47:00 <ncopa> tmh1999: i assume !check works for me, but i think those may be real bugs
2018-02-20 14:47:34 <ncopa> i'd like to investigate if it is real bug or not
2018-02-20 14:47:35 <ncopa> i had a look at audit
2018-02-20 14:47:47 <tmh1999> ncopa : I totally agree. but testing in real env is better than dangling in container, right ? I am so behind the schedule of not having a server since November...
2018-02-20 14:47:57 <ncopa> and it looks to me like there is a real bug there if /tmp filesystem does not support fallocate(2)
2018-02-20 14:48:07 <tmh1999> okay
2018-02-20 14:48:47 <ncopa> i suspect that glibc workarounds fallocate(2) and simlates it
2018-02-20 14:49:27 <ncopa> tmh1999: let me see if i can give you a lxc here
2018-02-20 14:49:45 <tmh1999> ncopa : that's even better. my dev env is way different from yours.
2018-02-20 15:02:38 <ncopa> tmh1999: this is your ssh keys? https://github.com/tmh1999.keys
2018-02-20 15:03:33 <tmh1999> ncopa: just the first one, ignore the 2nd
2018-02-20 15:04:27 <ncopa> tmh1999: i sent you a PM
2018-02-20 15:04:40 <ncopa> not sure if matrix will allow me to PM you unless you have a registered nick
2018-02-20 15:04:59 <tmh1999> ncopa : aw I don't have matrix account.
2018-02-20 15:05:20 <tmh1999> nope I can't talk to you nor receiving any pm
2018-02-20 15:05:39 <tmh1999> how about drop me an email ?
2018-02-20 15:06:00 <tmh1999> I thought matrix.alpinelinux.org are for core/main dev
2018-02-20 15:07:00 <tmh1999> ncopa : gotcha
2018-02-20 15:09:13 <ncopa> thats what i told you in PM :)
2018-02-20 15:09:19 <ncopa> i have sent an email to you
2018-02-20 15:09:29 <ncopa> tmh1999: i think it would be good for you to register your nick
2018-02-20 15:09:38 <ncopa> https://freenode.net/kb/answer/registration
2018-02-20 15:09:43 <ncopa> we have a bridge to IRC
2018-02-20 15:10:15 <tmh1999> i am resgisterd on freenode/irc, but not matrix
2018-02-20 15:22:14 <tmh1999> ah ok
2018-02-20 15:23:00 <koldbrutality> if a package uses multiple implementations of ruby or python, do we need to run test for check() on each implementation?  if a test suite only works on a particular version of python but the library can be used in multiple implementations, do we need to make a note of it not tested on other implemementations?
2018-02-20 15:23:40 <danieli> define implementation
2018-02-20 15:24:34 <koldbrutality> i am talking about different syntax
2018-02-20 15:25:04 <koldbrutality> python2 is slightly different than python3
2018-02-20 15:27:14 <koldbrutality> or the function signatures/API calls differ on each version of those releases
2018-02-20 15:29:34 <ncopa> koldbrutality: i am ok if you only check on python3, but dont mind if you also test python2
2018-02-20 15:29:49 <ncopa> the other devs may have different opinion
2018-02-20 15:30:23 <danieli> bah, lots of CVEs to handle
2018-02-20 15:30:29 <danieli> we really need that security WG up
2018-02-20 15:31:26 <ncopa> its not more than its always been. we are just more visible about it with the redmine->irc
2018-02-20 15:31:33 <ncopa> but yeah...
2018-02-20 15:31:34 <_ikke_> 2 CVE's against several releases
2018-02-20 15:32:55 <ncopa> yes
2018-02-20 15:33:08 <ncopa> we need to fix it in every relevant git branch
2018-02-20 15:33:37 <ncopa> and we should not forget any branch
2018-02-20 15:35:28 <ncopa> a killer feature for a bugtracker: make it possible to mark which git branches the issue/bug affects
2018-02-20 15:35:55 <ncopa> when you git push a commit with "fixes #<theissue>" in commit message, it should mark that the issue is fixed for that specific git branch
2018-02-20 15:35:58 <ncopa> when all git branches are fixed, the issue is closed
2018-02-20 15:39:38 <danieli> it really isn't more, but it's still something that has to be done
2018-02-20 15:39:49 <danieli> ncopa: shouldn't be too hard
2018-02-20 15:40:08 <_ikke_> ncopa: redmine allows custom fields
2018-02-20 15:40:49 <_ikke_> The latter part is more difficult though (requires support from the scm plugin)
2018-02-20 15:46:53 <tmh1999[m]> hello from matrix
2018-02-20 15:47:28 <tmh1999> sorry for the noise
2018-02-20 17:12:00 <koldbrutality> lol spelling mistake: ERROR: py-ycmd: Missding repository url in APKBUILD!
2018-02-20 17:12:15 <koldbrutality> what is this missding? lol
2018-02-20 18:01:31 <kaniini> it's a typo
2018-02-20 18:01:35 <kaniini> s and d are next to each other on most keyboards
2018-02-20 18:02:59 <ncopa> pushed fix
2018-02-20 18:03:07 <ncopa> thanks
2018-02-20 18:23:52 <kaniini> jirutka: i just switched pkgconf travis to using alpine :)
2018-02-20 18:27:02 <ncopa> congrats!
2018-02-20 18:44:50 <marketzero> hey alpine dev team, I am just starting to learn how to package software and was wondering if I wanted to include multiple files to my source variable in APKBUILD i.e. source="path/to/source/*" would that be sufficient?
2018-02-20 18:46:14 <ncopa> marketzero: no i dont think that will work
2018-02-20 18:47:15 <marketzero> if I point `source` to a directory would it build everything in the directory?
2018-02-20 18:47:33 <kaniini> it won't
2018-02-20 18:47:56 <kaniini> no
2018-02-20 18:49:58 <marketzero> how do you add multiple files to the source variable then?
2018-02-20 18:51:16 <AWilcox[m]> Typically source= is a link to a URL to download a tarball.  If you have multiple patches you have to declare each one.
2018-02-20 18:53:21 <marketzero> I was under the assumption that APKBUILD is a set of directives to build a tarball that will become the package I am creating
2018-02-20 18:54:54 <_ikke_> yes, so the source typically contains the reference to the tarball
2018-02-20 18:55:22 <_ikke_> and eventual other relevant files (like patches and init scripts) that aren't part of the tarbal
2018-02-20 18:58:02 <marketzero> I guess builddir is meant for the binaries I will provide, and source is a reference to the output of the packager `abuild`
2018-02-20 18:59:21 <_ikke_> builddir is where the source is placed so that you can build
2018-02-20 18:59:27 <marketzero> I am new to packaging, so thank you for guiding me
2018-02-20 18:59:44 <_ikke_> pkgdir is where you place the build binaries and other files that will be part of the package
2018-02-20 19:32:33 <ncopa> I wonder if we should rebuild armhf for armv7? and drop armv6 support?
2018-02-20 19:32:45 <ncopa> it means we lose support for RPI 1
2018-02-20 19:33:34 <xentec> probably more armv6 devices then that
2018-02-20 20:17:55 <PureTryOut[m]> (we'll also lose some phones on the postmarketOS side)
2018-02-20 20:17:55 <PureTryOut[m]> that said, we would like to have a dedicated armv7 branch...
2018-02-20 20:18:59 <xentec> ncopa: Since I've seen some mistakes in kernel module packages (e.g. missing flavors), I'd like to streamline all of them and am about to do so. Is this format ok to you? https://gist.github.com/xentec/8165ef1f018717a5c77bca7b58b915e4
2018-02-20 21:02:08 <ollieparanoid[m]> ncopa: as PureTryOut writes, having armv7 side by side with armv6 would be ideal (from pmOS perspective)
2018-02-20 21:06:48 <AWilcox[m]> mepholic: didn't you do some work with ARMv7?  Maybe talk about it now
2018-02-20 21:07:41 <AWilcox[m]> For me personally, I only have ARMv6 in 32-bit ARM devices.  I would no longer be able to test or contribute to Alpine/ARM if ARMv6 is gone.
2018-02-20 21:08:17 <mitchty> on arm specifically, could we also deal with stuff like the builders having neon and that means certain libraries/executables crash as they do compile time detection of what to build
2018-02-20 21:08:21 <AWilcox[m]> That's not really a big loss for me as I really do not like dealing with maintaining ARM build architecture, haha
2018-02-20 21:09:02 <mitchty> arm in general is... annoying
2018-02-20 21:09:02 <AWilcox[m]> Should be able to disable NEON and such using CFLAGS
2018-02-20 21:09:10 <AWilcox[m]> Not a lot you can do about assembler I guess
2018-02-20 21:09:23 <AWilcox[m]> I don't know if as(1) has flags that can disable stuff
2018-02-20 21:09:48 <mitchty> yeah but the builders have it and a lot of encryption libraries do work better with neon if available
2018-02-20 21:10:02 <mitchty> just another fun arm wrinkle
2018-02-20 21:11:35 <AWilcox[m]> It should use runtime detection to be quite fiar
2018-02-20 21:11:36 <AWilcox[m]> Fair*
2018-02-20 21:14:32 <mitchty> nettle as an example doesn't do that https://www.lysator.liu.se/~nisse/nettle/
2018-02-20 21:45:44 <tmh1999_> anyone knows where are all the .trigger scripts are stored ? mkinitfs.trigger, busybox.trigger, etc.
2018-02-20 21:46:14 <tmh1999> they are taken care by apk-tools, aren't they ?
2018-02-20 21:46:23 <tmh1999> I wonder if apk-tools rename them or something.
2018-02-20 21:52:03 <przemoc> tmh1999: /lib/apk/db/scripts.tar
2018-02-20 21:52:16 <przemoc> tmh1999: /lib/apk/db/triggers
2018-02-20 21:53:26 <tmh1999> przemoc : okay cool. wow I thought they are in text. interesting. thank you !
2018-02-20 21:54:20 <przemoc> they are in text, but tarred in one file. ;)
2018-02-20 21:55:19 <tmh1999> agreed.
2018-02-20 21:56:19 <tmh1999> I didn't expect they are in any other form thatn /path/busybox/my.trigger /path/mkinitfs/my.trigger, so couldn't find out before
2018-02-20 21:56:25 <tmh1999> *than
2018-02-20 22:05:38 <przemoc> actually I never researched what was the rationale behind keeping these scripts in tar instead of simply in directory.  I may have some ideas, but would prefer to know the original ones.
2018-02-20 22:06:30 <przemoc> fabled is not here, so maybe ncopa or kaniini can shed some light on this matter
2018-02-20 23:06:46 <kaniini> przemoc: resource efficiency on tmpfs
2018-02-20 23:06:49 <kaniini> making them separate = more inodes used
2018-02-20 23:06:54 <kaniini> that's why apk stuffs things in tarballs
2018-02-20 23:08:36 <skarnet> honestly if # of inodes used on a tmpfs becomes a limiting factor it's time to look at the bigger picture :P
2018-02-20 23:09:55 <kaniini> when you are running an entire OS from RAM on a system that has maybe 64-128MiB of RAM, it matters
2018-02-20 23:10:17 <kaniini> on modern hardware, it probably doesn't matter much, but on your 486 it does
2018-02-20 23:10:46 <kaniini> (if you're running from RAM anyway)
2018-02-20 23:11:33 <skarnet> I've run entire systems from RAM on a 486 with 32 MB of RAM, but granted, it wasn't Alpine :P
2018-02-20 23:15:53 <AWilcox[m]> It's silly to say that's not an issue on modern hardware.  Plenty of phones only have 256 MB RAM, and some of the SoCs and IoT crap have much less.
2018-02-20 23:16:23 <AWilcox[m]> Resource constraints are always going to be a thing, and if you always have them in mind, it's just that much better performing on modern hardware as well (thinking primarily of the POWER9 that has an L2 cache the size of 1990s hard disks...)
2018-02-20 23:16:29 <skarnet> again, the limiting factor is the RAM, *not* the number of inodes
2018-02-20 23:17:05 <skarnet> I am *not* disputing the need to save resources
2018-02-20 23:18:03 <AWilcox[m]> Well, inodes on a tmpfs = RAM usage
2018-02-20 23:18:28 <AWilcox[m]> I believe the minimum dirent size is 4K
2018-02-20 23:18:56 <AWilcox[m]> 200 package scripts = half a megabyte wasted
2018-02-20 23:19:31 <AWilcox[m]> That doesn't even count bookkeeping of the inode trees themselves
2018-02-20 23:20:52 <xentec> is it decided to drop -hardened next release? I'm cleaning up kernel module packages and wonder if I should continue with *-hardened variants
2018-02-20 23:24:30 <przemoc> kaniini: thanks for explanation.  I think it would start matter noticeably rather at bigger scale only, i.e. if there were thousands (or more) of trigger scripts (like each package having its own trigger kind of world).  I doubt there is a need to have more than dozens triggers at most in any sane scenario, so I'm wondering if this additional complexity is that well justified.  it's already
2018-02-20 23:24:36 <przemoc> available, so it's kind of non-issue perhaps, but it's always nice to keep systems/solutions as simple as possible.
2018-02-20 23:25:12 <mepholic> @ AWilcox[m] PureTryOut[m]
2018-02-20 23:25:17 <kaniini> xentec: -hardened is dead
2018-02-20 23:25:26 <mepholic> I have an armv7a "branch"
2018-02-20 23:25:31 <mepholic> most things seem to build without issue
2018-02-20 23:25:47 <mepholic> I'm running into an issue with lack of ram to build larger packages natively
2018-02-20 23:25:58 <mepholic> like gcc and llvm5
2018-02-20 23:26:10 <mepholic> i think boost is another
2018-02-20 23:26:18 <mepholic> been building on a beaglebone black
2018-02-20 23:26:22 <mepholic> I have a booting image
2018-02-20 23:26:25 <xentec> kaniini: ok. btw is someone working on simplifying kernel module packages?
2018-02-20 23:27:30 <mepholic> @ mitchty ^ as well
2018-02-20 23:31:19 <kaniini> ncopa: i prefer to have separate armv7 sub-arch for armv7
2018-02-20 23:32:03 <kaniini> there is value in keeping armv6 hardware in the field working
2018-02-20 23:32:36 <kaniini> xentec: no
2018-02-20 23:51:42 <mitchty> mepholic: armv7a being armhf+neon essentially? with armhf being armv7 without neon?
2018-02-20 23:52:04 <mepholic> mitchty: yes, with neon
2018-02-20 23:52:36 <mepholic> i used optimization flags specific to the armv7a in the beaglebone black
2018-02-20 23:52:45 <mepholic> it's been a few months since I've worked on that project
2018-02-20 23:52:51 <mitchty> gotcha, i'd be all for it, as well as an armv6 but that's just me :)
2018-02-20 23:53:25 <mitchty> but need to get back to my cross compile stuff again, i keep hitting fun bugs getting to ghc built
2018-02-20 23:54:41 <mitchty> i only noticed as i ran a binary i built on a neon box and had a arm soc that had no neon support, led me down to discover feature detection isn't very common in the arm space
2018-02-20 23:55:23 <mitchty> i'm used to stuff like openmpi detection of cpu features etc...
2018-02-21 00:07:13 <xentec> if anyone from dev team has time, please review: https://github.com/alpinelinux/aports/pull/3365
2018-02-21 04:13:48 <koldbrutality> i have a circular dependency for check() py-wsgiproxy2 is a test dependency for py-webtest.  py-webtest depends on py-wsgiproxy2 for testing.
2018-02-21 04:17:03 <AWilcox[m]> Well, I've managed to document the changes we're still discussing on our side.  https://wiki.adelielinux.org/wiki/Project:Harmony/Current_merge_list
2018-02-21 04:19:05 <Aerdan[m]> koldbrutality: the only way to really work around that is options="!check" for one of them.
2018-02-21 04:22:45 <koldbrutality> nm py-webtest test scripts are pulling the dependencies
2018-02-21 04:23:48 <AWilcox[m]> Yeah, Tox should be instructed to not do that
2018-02-21 04:24:18 <AWilcox[m]> That's against Alpine packaging rules, and a PR will be rejected if it does that; see jirutka's comments on some testing/ packages
2018-02-21 04:24:56 <koldbrutality> how am i going to fix this circular dependency then?
2018-02-21 04:25:04 <koldbrutality> have a seperate package?
2018-02-21 04:27:19 <AWilcox[m]> There is no workaround.  One of the upstreams will need to change their testing to break the circular dependency.
2018-02-21 08:23:56 <_ikke_> ^ deleted
2018-02-21 10:42:19 <ncopa> _ikke_: did you also delete the user?
2018-02-21 10:43:55 <_ikke_> ncopa: ah, no, I didn't
2018-02-21 10:45:13 <_ikke_> gamesapps and noroothack, latest users created with the same e-mail address
2018-02-21 11:10:13 <danieli> _ikke_: that exact same thing has been spammed before
2018-02-21 11:10:18 <danieli> i'm tempted to reverse engineer their app and fuck them over
2018-02-21 11:15:31 <liwakura> hah
2018-02-21 11:15:36 <liwakura> >APK
2018-02-21 11:16:06 <liwakura> i see why they come to AL
2018-02-21 11:16:50 <danieli> not android package
2018-02-21 11:16:52 <danieli> :@
2018-02-21 11:17:45 <ncopa> hum
2018-02-21 11:17:59 <ncopa> seems like 4.14.20 killed my workstation
2018-02-21 11:18:16 <ncopa> either the driver for samsung evo ssd is broke
2018-02-21 11:18:16 <danieli> what happened?
2018-02-21 11:18:24 <danieli> i see, completely dead
2018-02-21 11:18:33 <ncopa> rebooted
2018-02-21 11:18:38 <ncopa> i logged in to x11
2018-02-21 11:18:40 <ncopa> and it hang
2018-02-21 11:18:44 <ncopa> so i opened a console
2018-02-21 11:19:07 <ncopa> i ran dmesg and it hang before it printed anything
2018-02-21 11:19:25 <ncopa> the HDD led light was full on
2018-02-21 11:19:32 <ncopa> eg no blink, full shine
2018-02-21 11:19:33 <danieli> hmm wtf
2018-02-21 11:19:49 <ncopa> i opened a file with vim
2018-02-21 11:19:55 <ncopa> and it hanged on :q
2018-02-21 11:20:04 <ncopa> i think its my /home partition that is broke
2018-02-21 11:20:10 <danieli> I haven't kept up to date with linux development lately so I'm not entirely sure what changed
2018-02-21 11:20:16 <ncopa> i powreed it off hard
2018-02-21 11:20:27 <ncopa> and started up to boot the old, hardened kernel
2018-02-21 11:20:59 <ncopa> i forgot to plug the usb cable and bios does not support bluetooth
2018-02-21 11:21:13 <ncopa> so it booted the vanilla 4.14.20 again
2018-02-21 11:21:27 <ncopa> and this time it found bad things with fsck
2018-02-21 11:21:30 <ncopa> and it hang there
2018-02-21 11:21:31 <ncopa> recovering journal or similar
2018-02-21 11:21:32 <ncopa> and hang there
2018-02-21 11:21:46 <ncopa> i powered off again, hard
2018-02-21 11:22:02 <ncopa> manged to boot the old 4.9.y-hardened kernel
2018-02-21 11:22:04 <ncopa> and it booted up
2018-02-21 11:22:13 <danieli> was it orphaned inodes or something in fsck?
2018-02-21 11:22:30 <ncopa> had lots of warninges o fsck and asked me to run it manually
2018-02-21 11:22:35 <danieli> hmm
2018-02-21 11:23:06 <ncopa> Free blocks count wrong for group #251 (32768, counted=0).
2018-02-21 11:23:14 <ncopa> Fix<y>?
2018-02-21 11:23:34 <ncopa> same for group 252
2018-02-21 11:23:35 <ncopa> 253
2018-02-21 11:23:35 <ncopa> 254
2018-02-21 11:23:36 <ncopa> 255
2018-02-21 11:23:37 <ncopa> 256
2018-02-21 11:23:38 <ncopa> etc
2018-02-21 11:23:39 <ncopa> everything
2018-02-21 11:24:06 <danieli> what exactly was your version bump?
2018-02-21 11:24:20 <ncopa> so this is on LVM
2018-02-21 11:24:30 <danieli> i.e. what was your previous kernel?
2018-02-21 11:24:31 <ncopa> 4.14.19 to 4.14.20
2018-02-21 11:24:36 <danieli> i see
2018-02-21 11:24:41 <ncopa> 4.14.19
2018-02-21 11:24:47 <ncopa> i will look at the kernel changes in a bit
2018-02-21 11:24:59 <ncopa> so the setup here is
2018-02-21 11:25:15 <danieli> to save you some clicks https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.20
2018-02-21 11:25:15 <ncopa> 3x samsung evo SSD
2018-02-21 11:25:45 <ncopa> in mdadm raid10
2018-02-21 11:25:48 <ncopa> that md device is a pv for lvm
2018-02-21 11:25:52 <ncopa> added to a volume group named vg1
2018-02-21 11:26:23 <ncopa> and there i have a lv called /dev/mapper/vg1-lv_home
2018-02-21 11:26:29 <ncopa> with ext4
2018-02-21 11:28:03 <ncopa> looks like i lost all data
2018-02-21 11:28:03 <Aerdan[m]> _ikke_: you might want to go through the issues cos that 'games apps' account has posted a bunch of spam comments on e.g. #8499
2018-02-21 11:28:04 <ncopa> oh well
2018-02-21 11:28:23 <danieli> it's some shitty bot lol
2018-02-21 11:28:36 <_ikke_> Aerdan[m]: right
2018-02-21 11:28:41 <danieli> and this algitbot security spam is really annoying, only a few people (selected randomly?) have access
2018-02-21 11:29:49 <Aerdan[m]> huh. looks like it only got 8499 and 8493.
2018-02-21 11:32:21 <_ikke_> Aerdan[m]: removed the spam, thanks
2018-02-21 11:32:40 <Aerdan[m]> you're welcome.
2018-02-21 11:38:25 <clandmeter> ikke if you remove the content of a comment it will be deleted
2018-02-21 11:38:41 <_ikke_> clandmeter: ah, didn't know that
2018-02-21 11:39:06 <clandmeter> its stupid
2018-02-21 11:39:09 <clandmeter> i know...
2018-02-21 11:39:12 <clandmeter> new release should have a delelete button
2018-02-21 11:39:20 <_ikke_> ok
2018-02-21 11:39:57 <skarnet> +1 for delelete button
2018-02-21 11:40:19 <danieli> clalalalandmeter
2018-02-21 11:40:56 <clandmeter> shututututuup
2018-02-21 11:41:15 <clandmeter> :p
2018-02-21 11:47:00 <ncopa> ok, i commented out /home in fstab
2018-02-21 11:47:02 <ncopa> it now boots
2018-02-21 11:47:03 <ncopa> without /home ofc
2018-02-21 11:47:04 <ncopa> the mdadm seems to be ok
2018-02-21 11:47:08 <ncopa> http://tpaste.us/PLQ7
2018-02-21 11:47:29 <_ikke_> ncopa: do you have other partitions?
2018-02-21 11:47:44 <ncopa> yes
2018-02-21 11:47:52 <ncopa> i have / on nvme
2018-02-21 11:47:52 <_ikke_> also ext4?
2018-02-21 11:47:56 <_ikke_> ok
2018-02-21 11:48:08 <ncopa> yes
2018-02-21 11:48:51 <_ikke_> but only /home is on the raid array?
2018-02-21 11:48:59 <ncopa> yes
2018-02-21 11:49:26 <ncopa> and ssd disks are only used for this
2018-02-21 11:52:19 <ncopa> i wonder if i should reboot to windows and run some firmware update for the disks
2018-02-21 12:05:03 <ncopa> heh
2018-02-21 12:05:48 <_ikke_> ?
2018-02-21 12:12:38 <ncopa> ok there is a "samsung magician" windows tool that can do it too
2018-02-21 12:12:40 <ncopa> the latest firmware is installed
2018-02-21 12:12:59 <przemoc> firmware update on ssd is not guaranteed to be safe, at least on most consumer/prosumer devices, so you can actually lost your data during the process and you cannot complain about it later.  usually it is painless, but if you're already dealing with some problems, I would be extremely cautious and proceed with such upgrade only if changelog suggests that new version fixes some serious stuff that
2018-02-21 12:13:05 <przemoc> may be hitting you.
2018-02-21 12:14:11 <ncopa> i just did a fw upgrade for the nvme, samsung 960
2018-02-21 12:14:41 <ncopa> lets see what happens...
2018-02-21 12:16:54 <ncopa> windows booted
2018-02-21 12:33:26 <jirutka> koldbrutality: AWilcox[m]: if adding checkdepends would cause circular dependency, then you have to unfortunately disable check, there’s currently not any workaround :( we should address it in abuild to handle circular deps in checkdepends
2018-02-21 12:35:36 <jirutka> koldbrutality: AWilcox[m]: disabling check is against policy if it’s not reasoned; this is unfortunately quite common that contributor disables check without bothering to look if the project has some tests and/or adding comment why the heck (s)he disable it
2018-02-21 12:53:40 <ncopa> i was able to complete the fsck
2018-02-21 12:53:42 <ncopa> and was able to mount /home
2018-02-21 12:53:44 <ncopa> after reboot and login, same thing happened again
2018-02-21 12:53:45 <ncopa> something is seriously wrong with 4.14.20
2018-02-21 12:54:26 <_ikke_> :(
2018-02-21 12:55:29 <ncopa> i have a dmesg: look at the end. http://tpaste.us/Rjo4
2018-02-21 12:55:44 <clandmeter> why am i missing openssl cms?
2018-02-21 13:00:56 <ncopa> cms?
2018-02-21 13:02:23 <clandmeter> https://linux.die.net/man/1/cms
2018-02-21 13:03:59 <ncopa> i have no clue what to do with the kernel issue :-(
2018-02-21 13:06:45 <danieli> ncopa: have you narrowed it down?
2018-02-21 13:06:55 <clandmeter> kaniini: is cms part of libressl?
2018-02-21 13:07:09 <przemoc> ncopa: it's strange, because I think I've seen  "exception Emask 0x10 SAct 0x10000 SErr 0x400101 action 0x6 frozen" kind of errors with bad sata cables, and it's apparently not your case, because if you're in older kernel you don't see it, right?
2018-02-21 13:07:54 <ncopa> correct
2018-02-21 13:07:55 <danieli> clandmeter: well, there's https://github.com/libressl/libressl/tree/master/src/crypto/cms
2018-02-21 13:07:59 <ncopa> it didnt happen with 4.14.19
2018-02-21 13:08:27 <danieli> ncopa: haven't narrowed it down any further, have you?
2018-02-21 13:08:55 <ncopa> nope
2018-02-21 13:09:09 <ncopa> only that it seems to be a kernel oops with RCU something
2018-02-21 13:09:41 <danieli> there are relevant results in the changelog
2018-02-21 13:10:02 <danieli> changelog, line 83
2018-02-21 13:10:48 <ncopa> you mean this? https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?h=v4.14.20&id=ce6faf10fd6544febcf5c3efe453193def873c60
2018-02-21 13:10:57 <ncopa> i dont think so, it just exports the symbols
2018-02-21 13:11:09 <clandmeter> danieli: what you linked is old.
2018-02-21 13:11:16 <danieli> that's the only change I see that's relevant to rcu
2018-02-21 13:11:24 <danieli> clandmeter: haven't really kept up with it, lemme look once more
2018-02-21 13:11:56 <clandmeter> https://github.com/libressl-portable/portable
2018-02-21 13:12:09 <danieli> yeah
2018-02-21 13:12:22 <ncopa> could be this one: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?h=v4.14.20&id=c561093ed6843684690436dea034af53b462cfe5
2018-02-21 13:12:23 <danieli> yeah, no, there's no CMS
2018-02-21 13:12:30 <danieli> it was explicitly removed
2018-02-21 13:12:43 <clandmeter>  Removed unused Cryptographic Message Support (CMS)
2018-02-21 13:12:53 <danieli> clandmeter: yep
2018-02-21 13:13:49 <przemoc> ncopa: yeah, looks a bit plausible.
2018-02-21 13:13:54 <danieli> ^
2018-02-21 13:18:52 <przemoc> ncopa: could you tpaste dmesg with 4.14.19?  maybe more differences could be spotted during boot and leading more clues?
2018-02-21 13:19:01 <przemoc> 
ACTION has to vanish for some time, though

2018-02-21 13:21:19 <ncopa> i dont have 4.14.19 handy available :-/
2018-02-21 14:07:58 <ncopa> ok, 4.14.19 seems to work flawlessly
2018-02-21 14:44:29 <ncopa> yup
2018-02-21 14:44:51 <ncopa> reverting this make things work again: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-4.14.y&id=c561093ed6843684690436dea034af53b462cfe5
2018-02-21 14:53:57 <_ikke_> wow, you found it
2018-02-21 14:55:27 <ncopa> i think there is needed to be errors to be able to trigg the bug
2018-02-21 14:55:34 <ncopa> i have this: http://tpaste.us/9KXP
2018-02-21 14:55:35 <ncopa> at the end
2018-02-21 14:55:49 <ncopa> and i have always seen those for as long i can remember
2018-02-21 14:57:02 <przemoc> oh, so you lied to me earlier. :)  you did have ata errors in 4.14.19 too
2018-02-21 14:57:31 <przemoc> you sure you have good sata cables?
2018-02-21 14:57:50 <ncopa> relatively sure
2018-02-21 14:58:42 <ncopa> im gonna test disable ncq whatever that is
2018-02-21 14:58:44 <ncopa> in any case
2018-02-21 14:59:02 <ncopa> kernel should not go boom in case of ata errors
2018-02-21 14:59:13 <przemoc> agreed
2018-02-21 14:59:59 <przemoc> ncq - native command queueing - improves performance
2018-02-21 15:03:02 <ncopa> https://bbs.archlinux.org/viewtopic.php?id=208087
2018-02-21 15:04:23 <kaniini> it is probably actually advanced link power management
2018-02-21 15:04:27 <kaniini> that is the problem
2018-02-21 15:04:35 <kaniini> not NCQ
2018-02-21 15:05:06 <ncopa> ok?
2018-02-21 15:05:27 <kaniini> ALPM was added in 4.14
2018-02-21 15:05:31 <kaniini> there is a big thread on fedora-devel about people's drives messing up under it
2018-02-21 15:05:40 <ncopa> link?
2018-02-21 15:06:59 <kaniini> https://www.spinics.net/linux/fedora/fedora-users/msg481102.html
2018-02-21 15:07:32 <ncopa> i think dmesg reported those errors in 4.9 kernel too
2018-02-21 15:08:09 <ncopa> libata.force=noncq didnt make any diff
2018-02-21 15:11:59 <kaniini> the solution is to set max_performance on some sysfs node to disable it
2018-02-21 15:11:59 <kaniini> i guess also it could be disabled in kernel
2018-02-21 15:17:23 <ncopa> # find /sys/devices  -name link_power_management_policy | xargs cat | tpaste
2018-02-21 15:17:24 <ncopa> http://tpaste.us/nqNV
2018-02-21 15:17:29 <ncopa> i dont think that was my issue
2018-02-21 15:22:30 <kaniini> hmm, dunno then
2018-02-21 15:44:19 <ncopa> reported here: https://bugzilla.kernel.org/show_bug.cgi?id=198861
2018-02-21 18:25:08 <tmh1999> When we boot from the ISO (aka live cd), then run alpine-conf scripts to install on a disk, what filesystem we are using ? initramfs's filesystem ?
2018-02-21 18:25:48 <tmh1999> there must be one providing a filesystem layout
2018-02-21 18:27:45 <kaniini> we install new image into the target
2018-02-21 18:27:50 <kaniini> and then use apk audit to copy things
2018-02-21 18:27:53 <kaniini> iirc
2018-02-21 18:33:07 <tmh1999> kaniini: what I am asking is before that, before "install new image". we need a filesystem to be running on to install new image
2018-02-21 18:35:34 <liwakura> afaik thats not the initramfs, but an newly created tmpfs
2018-02-21 18:36:11 <liwakura> (initramfs shows up as "rootfs" in mount table)
2018-02-21 18:37:04 <tmh1999> liwakura : I also suspect it's not initramfs's. still trying to figure it out how.
2018-02-21 18:38:01 <liwakura> the initial initramfs creates an tmpfs, setups some apkovl + base system there and then switch_root's there
2018-02-21 18:39:41 <liwakura> you can read that behavior from /usr/share/mkinitfs/initramfs-init
2018-02-21 18:41:39 <tmh1999> liwakura : that's it !
2018-02-21 18:42:05 <tmh1999> thanks
2018-02-21 19:43:59 <AWilcox[m]> I hope that I am not overstepping by reviewing some PRs on GitHub.  I know I am just contributor, not developer yet.
2018-02-21 19:47:23 <przemoc> if someone wrote more than a few APKBUILDs, can pinpoint some mistakes and gives helpful tips to others regarding packaging, I have no idea how their reviews could be seen as harmful.
2018-02-21 19:48:14 <kaniini> awilfox: technically maintainers can sponsor things into testing
2018-02-21 19:48:43 <kaniini> and community
2018-02-21 20:01:38 <BernhardG> I have a technical question about the Alpine build servers. How many space do they have? I currently package lizardfs (for internal usage at the moment) but I intend to publish it at some time and if and only if everything runs on my site. The test suite itself needs at least 60GB for all tests.
2018-02-21 20:02:35 <_ikke_> THat seems a bit excessive
2018-02-21 20:04:50 <AWilcox[m]> The libwebp test downloads 45 GB of video from YouTube for its test suite... that is the main reason I marked it !check :P
2018-02-21 20:05:17 <BernhardG> I also found that it is already (for an old version) in aports/testing.
2018-02-21 20:05:44 <BernhardG> But I did not find that package when I searched for it on pkgs.alpinelinux.org
2018-02-21 20:05:52 <AWilcox[m]> Also I opened https://github.com/alpinelinux/aports/pull/3372 to try and fix #7737
2018-02-21 20:05:54 <_ikke_> BernhardG: But this is ephemeral data?
2018-02-21 20:06:52 <BernhardG> _ikke_: lizardfs is a filesystem and this space is needed to test its functionality. It is created on the fly - so it is not needed after the build.
2018-02-21 20:07:28 <ncopa> does anybody here have a glibc system handy available for ppc64le?
2018-02-21 20:07:30 <ncopa> with gcc
2018-02-21 20:07:58 <ncopa> i just need compile a simple  test
2018-02-21 20:09:09 <kaniini> does it need to be ppc64le explicitly ?
2018-02-21 20:09:22 <kaniini> would ppc64be work
2018-02-21 20:12:46 <kaniini> ncopa: what are you trying to test :)
2018-02-21 20:39:01 <marketzero> Hey dev team, if I do the command `abuild checksum` and it returns error symbolic link loop what am I doing wrong?
2018-02-21 20:39:10 <clandmeter> Natanael Copa: dup.pw does not resolve?
2018-02-21 20:40:22 <marketzero> I have two already compiled binaries inside my `src/` folder
2018-02-21 20:41:56 <_ikke_> marketzero: how does your APKBUILD look like?
2018-02-21 20:42:55 <marketzero> source="src/app_render src/app_control"
2018-02-21 20:43:31 <_ikke_> marketzero: You should not point to src
2018-02-21 20:43:42 <marketzero> package(){ cd "$srcdir" \ make DESTDIR="pkgdir" install }
2018-02-21 20:43:50 <_ikke_> the source files should be in the root of the package dir
2018-02-21 20:44:04 <marketzero> then what is src/ folder for?
2018-02-21 20:44:06 <_ikke_> DESTDIR="$pkgdir"
2018-02-21 20:44:19 <_ikke_> marketzero: abuild symlinks / extracts the files in there
2018-02-21 20:44:21 <liwakura> marketzero: for downloaded sources
2018-02-21 20:44:46 <_ikke_> marketzero: note that offical apkbuilds should not contain any binary files
2018-02-21 20:45:40 <marketzero> since I have no downloaded sources, then `src/` should be empty?
2018-02-21 20:46:11 <_ikke_> yes
2018-02-21 20:46:11 <liwakura> marketzero: not exist in the repo
2018-02-21 20:46:29 <marketzero> _ikke_: thanks
2018-02-21 20:49:01 <marketzero> what should package() look like? All the guides and other APKBUILD files have you cd into a builddir, since I am not building then what should it look like?
2018-02-21 20:50:10 <_ikke_> marketzero: what *are* you packaging?
2018-02-21 20:50:32 <marketzero> and application for internal development
2018-02-21 20:50:50 <Aerdan[m]> does the application have a buildsystem?
2018-02-21 20:51:08 <marketzero> yes, fully integrated, uses a CI
2018-02-21 20:51:41 <marketzero> I am pulling down binaries and wrapping them up in a package for deployment to other machines we are creating
2018-02-21 20:52:02 <Aerdan[m]> well, then, you should be doing sources="sometarball.tar.gz" and invoking the buildsystem instead of packaging binaries directly.
2018-02-21 20:53:32 <marketzero> I can't access a tarball of the app, only the binaries. Do I wrap them in a tarball?
2018-02-21 20:53:43 <mepholic> lol
2018-02-21 20:53:59 <mepholic> that still won't be accepted to the official repos
2018-02-21 20:54:12 <marketzero> it's not going in the official repos
2018-02-21 20:54:23 <mepholic> then it doesn't particularly matter
2018-02-21 20:54:26 <Aerdan[m]> mepholic: internal use, so they presumably don't give a shit.
2018-02-21 20:55:52 <mepholic> however it'd probably be a better idea in the long term to build your packages from an apkbuild
2018-02-21 20:56:12 <marketzero> Presumably sources should be null, and package() should cd to what directory?
2018-02-21 20:56:19 <kaniini> marketzero: put the binaries themselves in $sources
2018-02-21 20:57:00 <mepholic> marketzero: yeah, if you use the binaries themselves as sources, and then literally just copy them into $pkgdir in the package() step
2018-02-21 20:57:03 <mepholic> it should work fine
2018-02-21 20:57:16 <mepholic> $pkgdir is laid out like the filesystem
2018-02-21 20:57:39 <clandmeter> kaniini: is apk search the only way to get a pkg version number?
2018-02-21 20:57:45 <mepholic> so if you want a bin to be in /usr/bin after you install the package, put the bin in $pkgdir/usr/bin in the package() step
2018-02-21 21:02:50 <kaniini> clandmeter: apk info can do it, but the output format of apk info is really not so great
2018-02-21 21:02:54 <clandmeter> right
2018-02-21 21:03:05 <clandmeter> apk info --version perhaps?
2018-02-21 21:03:10 <kaniini> clandmeter: i am designing a replacement (apk show) which is meant to be both human and computer friendly
2018-02-21 21:03:15 <kaniini> much as i did with apk list
2018-02-21 21:03:48 <kaniini> no, just apk info
2018-02-21 21:04:12 <clandmeter> yes i know, i mean as suggestion.
2018-02-21 21:04:36 <clandmeter> --version show the latest version in repository
2018-02-21 21:05:01 <kaniini> you can do that with apk-tools 2.10: apk list --latest [packages]
2018-02-21 21:05:24 <clandmeter> ok
2018-02-21 21:05:25 <kaniini> i intend to set up a repo with apk-tools nightlies soon
2018-02-21 21:05:54 <kaniini> so you can just upgrade your apk tools that way
2018-02-21 21:06:56 <kaniini> apk list should be able to do anything apk search can do at this point, but it does operate on the "names database" instead of specific repositories
2018-02-21 21:07:07 <kaniini> and there's a couple of items on my todo list still for it
2018-02-21 21:07:10 <kaniini> like listing @tags
2018-02-21 21:08:48 <kaniini> apk show and apk query will be a cleaned up form of apk info that has more usable output
2018-02-21 21:09:27 <kaniini> apk info does a bunch of unrelated stuff right now
2018-02-21 21:11:21 <_ikke_> github says this license is BSD-2-Clause, but the file starts with ISC: https://github.com/jedisct1/piknik/blob/master/LICENSE
2018-02-21 21:13:30 <_ikke_> Any idea what license I should pick?
2018-02-21 21:13:31 <przemoc> _ikke_: the text is BSD-2-Clause, but for unknown reasons someone put "ISC LICENSE." on top of the file
2018-02-21 21:14:41 <przemoc> (haven't checked what's in the source files, commenting only on what I'm seeing in the LICENSE file you linked.)
2018-02-21 21:14:53 <_ikke_> right
2018-02-21 21:15:11 <_ikke_> source files don't contain a license header
2018-02-21 21:18:50 <clandmeter> kaniini: i want to get the version of the current linux-vanilla from v3.7
2018-02-21 21:18:59 <clandmeter> so im doing: apk --verbose --no-cache --repositories-file /dev/null --repository http://dl-4.alpinelinux.org/alpine/v3.7/main search -x linux-vanilla
2018-02-21 21:19:55 <clandmeter> but that includes the fetch info...
2018-02-21 21:20:30 <clandmeter> adding --quiet removes it but also the version :|
2018-02-21 21:22:42 <clandmeter> i think apk info will show information about all versions in the repo its not preferable.
2018-02-21 21:29:07 <_ikke_> Should the check function be added to the default template for new packages (newapkbuild)?
2018-02-21 21:34:08 <BernhardG> _ikke_ I, as a beginner in packaging, would prefer that. Also the checkdepends variable would be useful (I did not know about it before a comment from clandmeter)
2018-02-21 21:34:30 <_ikke_> right
2018-02-21 21:36:08 <AWilcox[m]> It'd be nice.  CMake has CTest, which needs a different invocation than autotools, which always uses `make check` whereas most custom build systems use `make test`.
2018-02-21 21:36:19 <AWilcox[m]> And all Perl packages use the same test invocation.
2018-02-21 21:36:22 <AWilcox[m]> So perhaps it should be in the build system parts, like build() is.
2018-02-21 21:36:57 <clandmeter> checkdepends needs to be added to wiki
2018-02-21 21:36:57 <clandmeter> its not iirc
2018-02-21 21:37:19 <clandmeter> we need to notify the documentation team  (:
2018-02-21 21:37:23 <_ikke_> It does not need to have an implementation, just like package is empty by default
2018-02-21 21:38:26 <AWilcox[m]> https://github.com/alpinelinux/abuild/pull/33/commits/78a0333cf38cc9020658caa687613bb282c8429f
2018-02-21 21:38:29 <AWilcox[m]> I'm on it clandmeter!
2018-02-21 21:38:29 <BernhardG> btw. clandmeter, thank you for your bug report to the GitHub of burp.
2018-02-21 21:39:41 <_ikke_> anyone familiar with the go build / dependency system?
2018-02-21 21:39:48 <clandmeter> A. Wilcox:  :)
2018-02-21 21:40:18 <clandmeter> a little
2018-02-21 21:40:56 <_ikke_> trying to run a test script (shell), which runs go build
2018-02-21 21:41:05 <_ikke_> it complains about dependencies
2018-02-21 21:41:23 <_ikke_> which as far as I can tell are present in the vendor dir
2018-02-21 21:42:42 <_ikke_> piknik.go:13:2: cannot find package "github.com/BurntSushi/toml" in any of:
2018-02-21 21:45:39 <nmeum> did you set the GOPATH environment variable correctly?
2018-02-21 21:46:11 <_ikke_> export GOPATH=$PWD
2018-02-21 21:47:14 <_ikke_> (where PWD is the source dir)
2018-02-21 21:47:31 <_ikke_> $builddir
2018-02-21 21:48:11 <_ikke_> does go get github.com/jedisct1/piknik actual build the project?
2018-02-21 21:50:13 <clandmeter> it should fetch and build.
2018-02-21 21:50:48 <clandmeter> iirc, its been a while since i touched go...
2018-02-21 21:50:49 <_ikke_> That seems to work
2018-02-21 21:51:02 <_ikke_> but the test.sh then does a go build, which then fails
2018-02-21 21:51:04 <clandmeter> i have slept much better since.
2018-02-21 21:51:29 <_ikke_> haha
2018-02-21 21:56:28 <clandmeter> _ikke_: is that a pr or are you trying to pkg it yourself?
2018-02-21 21:56:51 <_ikke_> clandmeter: Will be a PR eventually
2018-02-21 21:58:17 <clandmeter> i think gitea is one of the pkgs i did.
2018-02-21 21:58:46 <_ikke_> I did do a fix for docker for a similar issue
2018-02-21 21:58:59 <_ikke_> but there I basically just did mv vendor src
2018-02-21 22:01:54 <clandmeter> vendor dir should be automatically picked up if you set the gopath correctly iirc.
2018-02-21 22:02:22 <_ikke_> aparently it isn't4
2018-02-21 22:02:45 <_ikke_> It looks /home/build/aports/testing/piknik/src/piknik-0.9.1/gohome/src/github.com/minio/blake2b-simd
2018-02-21 22:03:05 <_ikke_> (gohome is just an experiment)
2018-02-21 22:22:43 <clandmeter> _ikke_: this works http://tpaste.us/ykBl
2018-02-21 22:26:54 <_ikke_> You disabled the check part :D
2018-02-21 22:27:20 <_ikke_> but this will help, thanks
2018-02-21 22:29:48 <clandmeter> yes i wanted to clear the clutter. i have some local changes to abuild that are rather verbose.
2018-02-22 00:14:06 <marketzero> almost there guys, I can't for the life of me understand why a simple cp command fails. Inside package() I have followed mepholic's advice and coping two binaries into $pkgdir and I am entering fakeroot and then cp: can't create `...app_control`: no such file or directory
2018-02-22 00:22:36 <mepholic> marketzero: you might want to specifically do something like
2018-02-22 00:23:02 <mepholic> cp $srcdir/filename... $pkgdir/usr/bin/filename...
2018-02-22 00:23:16 <mepholic> make sure you mkdir -p $pkgdir/usr/bin first
2018-02-22 00:23:22 <marketzero> okay I'll try that
2018-02-22 00:23:25 <mepholic> in the package() section
2018-02-22 00:40:19 <marketzero> mepholic: Thank you sir, that did it
2018-02-22 00:55:21 <mepholic> no problem
2018-02-22 13:16:16 <_ikke_> Oh, fun one
2018-02-22 13:20:44 <Tsutsukakushi> really love how compilers are used as code downloaders, build systems, test frameworks, package managers etc. these days
2018-02-22 13:21:06 <Tsutsukakushi> soon compilers will do pretty much everything except the compilation part
2018-02-22 13:28:39 <_ikke_> I think the next logical feature will be a mail client
2018-02-22 13:31:55 <Tsutsukakushi> idk
2018-02-22 13:32:00 <Tsutsukakushi> a web browser would make more sense
2018-02-22 13:32:11 <Tsutsukakushi> need that to browse the docs and to access the bug tracker
2018-02-22 13:32:59 <kaniini> i should point out using `go get` in APKBUILD is a policy violation
2018-02-22 13:33:05 <kaniini> use glide instead
2018-02-22 13:33:37 <Tsutsukakushi> why glide and not wget
2018-02-22 13:34:00 <Tsutsukakushi> why does go need a package manager written in go_
2018-02-22 13:34:05 <Tsutsukakushi> what's wrong with apk
2018-02-22 13:34:06 <kaniini> go get doesn't just download packages, it handles dependency resolution
2018-02-22 13:34:07 <kaniini> glide does as well, but ahead of time
2018-02-22 13:34:37 <kaniini> different go packages require different artifacts
2018-02-22 13:34:47 <Tsutsukakushi> why is a package manager using another package manager to download shit?
2018-02-22 13:34:47 <kaniini> so you wind up packaging every version of every artifact
2018-02-22 13:34:56 <kaniini> abuild isn't a package manager
2018-02-22 13:35:07 <Tsutsukakushi> it builds packages for apk
2018-02-22 13:35:22 <_ikke_> Tsutsukakushi: you end up having to package many versions per package
2018-02-22 13:35:31 <kaniini> it's too early to log into irc to ban you, so please just shut up
2018-02-22 13:35:43 <Tsutsukakushi> why?
2018-02-22 13:35:50 <Tsutsukakushi> why would you need many versions of the packages
2018-02-22 13:35:57 <kaniini> ok doing it anyway
2018-02-22 13:36:02 <Tsutsukakushi> lol
2018-02-22 13:36:13 <Tsutsukakushi> >i ban you because i disagree with you
2018-02-22 13:36:17 <Tsutsukakushi> how mature kaniini
2018-02-22 13:36:56 <kaniini> your questions are legitimate, but you should go ask the people who write programs in go why this is
2018-02-22 13:37:17 <Tsutsukakushi> lol
2018-02-22 13:37:48 <Tsutsukakushi> they have no interest in making alpine good
2018-02-22 13:37:55 <kaniini> either way, if we did it as you propose it would result in us having to package, individually, every version of every go library
2018-02-22 13:38:08 <kaniini> debian does it this way and it's a mess
2018-02-22 13:38:09 <Tsutsukakushi> as it should be
2018-02-22 13:38:12 <kaniini> and since go programs are staticly linked
2018-02-22 13:38:15 <kaniini> we just say fuck it
2018-02-22 13:38:17 <kaniini> not worth it
2018-02-22 13:38:19 <Tsutsukakushi> you don't need all go libaries
2018-02-22 13:38:22 <kaniini> and use glide inside the APKBUILD
2018-02-22 13:38:24 <Tsutsukakushi> you only need specific ones
2018-02-22 13:38:26 <kaniini> ok
2018-02-22 13:38:31 <Tsutsukakushi> not all libraries are worth packaging
2018-02-22 13:38:36 <kaniini> yeah
2018-02-22 13:38:37 <Tsutsukakushi> most software is either useless or garbage
2018-02-22 13:38:37 <kaniini> ok
2018-02-22 13:38:58 <kaniini> again
2018-02-22 13:39:06 <kaniini> for the go software we already package
2018-02-22 13:39:25 <kaniini> if we did not use glide
2018-02-22 13:39:30 <kaniini> there would literally be 1000+ apks already
2018-02-22 13:39:46 <kaniini> you don't understand
2018-02-22 13:40:30 <kaniini> it's basically as bad of a mess as the node.js ecosystem
2018-02-22 13:40:34 <kaniini> people have go packages which are like 6 lines of code
2018-02-22 13:40:42 <Tsutsukakushi> yeah
2018-02-22 13:40:45 <Tsutsukakushi> don't include those
2018-02-22 13:40:47 <Tsutsukakushi> just leave them out
2018-02-22 13:40:48 <kaniini> so, since it's staticly linked anyway
2018-02-22 13:40:50 <kaniini> its better to just let glide handle it
2018-02-22 13:40:50 <Tsutsukakushi> they have no value anyways
2018-02-22 13:41:14 <_ikke_> Tsutsukakushi: They don't?
2018-02-22 13:41:19 <Tsutsukakushi> not all libraries deserve to be packaged for operating systems
2018-02-22 13:41:36 <_ikke_> Sure, but if programs rely on them
2018-02-22 13:41:40 <_ikke_> usefull programs
2018-02-22 13:41:44 <Tsutsukakushi> those programs should be fixed
2018-02-22 13:41:51 <fcolista_> ?
2018-02-22 13:42:08 <Tsutsukakushi> if a program depends on a 6 line library that should be enough reason to disqualify it
2018-02-22 13:42:09 <fcolista_> How would you fix a program that rely on a library that is not packaged?
2018-02-22 13:42:22 <kaniini> now, you are just trolling
2018-02-22 13:42:26 <fcolista_> Tsutsukakushi, what is your point here?
2018-02-22 13:42:27 <_ikke_> Tsutsukakushi: should each program reinvent the wheel everytime?
2018-02-22 13:42:30 <kaniini> please go troll somewhere else
2018-02-22 13:42:35 <fcolista_> +1
2018-02-22 13:42:42 <Tsutsukakushi> _ikke_: it's barely a function
2018-02-22 13:42:57 <Tsutsukakushi> _ikke_: it's far from reinventing a wheel
2018-02-22 13:43:09 <kaniini> while that may be true, this isn't the appropriate venue to complain about (lack of) Go software engineering practices
2018-02-22 13:43:15 <Tsutsukakushi> it's less lines than you'd have to type for error handline for a 3 line program
2018-02-22 13:43:29 <kaniini> i suggest to talk to Go developers about their sins
2018-02-22 13:43:45 <Tsutsukakushi> it's an appropriate venue to complain about the bad requirements for apk packaging
2018-02-22 13:43:47 <_ikke_> Tsutsukakushi: So you want big libraries that would only make the binary larger?
2018-02-22 13:43:55 <kaniini> to which they will probably tell you they don't want their software packaged anyway
2018-02-22 13:43:59 <kaniini> since go itself has a package manager (go get) ;)
2018-02-22 13:44:01 <_ikke_> and then complain about bloated software
2018-02-22 13:44:10 <Tsutsukakushi> _ikke_: i want useful libraries
2018-02-22 13:44:22 <Tsutsukakushi> _ikke_: 6 line library does nothing that couldn't be just thrown in the source as is
2018-02-22 13:45:14 <kaniini> the requirement for APK packaging is a maintainer who wants to package the software
2018-02-22 13:45:15 <Tsutsukakushi> it's trivial, it's not even enough to be copyrightable
2018-02-22 13:45:22 <kaniini> ok
2018-02-22 13:45:49 <fcolista> Tsutsukakushi, if you are willing to maintain software by fixing libs, you're very welcome
2018-02-22 13:46:06 <fcolista> then you'll end up in understanding that is not doable.
2018-02-22 13:46:48 <kaniini_> this conversation has moved past it's usefulness
2018-02-22 13:46:54 <fcolista> Going in $Software and trying to "fix it" with the "6 line of codes that can be implemented in the source code rather than in an external library"
2018-02-22 13:46:56 <kaniini_> lets talk about something else now
2018-02-22 13:47:05 <Tsutsukakushi> kaniini_: yeah, better pull out the banhammer, right?
2018-02-22 13:47:53 <kaniini_> 
ACTION shrugs

2018-02-22 13:48:07 <kaniini_> i'm asking nicely that we discuss something else now
2018-02-22 13:48:42 <fcolista> There's something I want to discuss actually
2018-02-22 13:48:52 <fcolista> which happens from time to time
2018-02-22 13:49:12 <fcolista> when a $package relies on a python library of a specific version
2018-02-22 13:49:21 <fcolista> in edge we have almost the latest one
2018-02-22 13:49:31 <kaniini> yes, that's a mess too
2018-02-22 13:49:37 <fcolista> but with python, you have  specific range of accepted versions
2018-02-22 13:49:43 <fcolista> my case? GNS3
2018-02-22 13:49:55 <fcolista> aiohttp is upgraded once a week..
2018-02-22 13:50:04 <fcolista> and GNS3 breaks each time
2018-02-22 13:50:07 <fcolista> for two reason:
2018-02-22 13:50:13 <fcolista> 1. different version (of course)
2018-02-22 13:50:23 <kaniini> aiohttp is one of the larger offenders imo
2018-02-22 13:50:26 <kaniini> because they keep changing APIs
2018-02-22 13:50:31 <kaniini> in minor releases
2018-02-22 13:50:45 <fcolista> 2. abump $newpackage-$version is not enough, since might have new dependencies
2018-02-22 13:50:48 <fcolista> kaniini, yes
2018-02-22 13:50:51 <fcolista> absolutely true
2018-02-22 13:50:51 <fcolista> so
2018-02-22 13:50:59 <fcolista> how to handle these cases?
2018-02-22 13:51:28 <kaniini> what i have in mind is a new apk applet called `apk import`
2018-02-22 13:51:30 <fcolista> I don't see a solution actually...just I can have a stable version
2018-02-22 13:51:31 <kaniini> then you just use pip instead
2018-02-22 13:51:49 <fcolista> a wrapper for pip?
2018-02-22 13:52:04 <kaniini> (apk import registers a list of files with apk and associates them with a virtual package)
2018-02-22 13:52:19 <fcolista> umh
2018-02-22 13:52:22 <fcolista> interesting
2018-02-22 13:52:34 <fcolista> But still you need to install build-base, python$ver-dev  etc
2018-02-22 13:52:47 <kaniini> yes
2018-02-22 13:53:45 <fcolista> how would you handle the virtual package name?
2018-02-22 13:53:49 <fcolista> Might be overlapping
2018-02-22 13:53:54 <kaniini> py:..whatever
2018-02-22 13:54:01 <kaniini> note the use of a namespace
2018-02-22 13:54:21 <fcolista> ok
2018-02-22 13:54:47 <fcolista> interesting
2018-02-22 13:55:02 <kaniini> but it doesn't really solve the problem
2018-02-22 13:55:07 <kaniini> on it's own
2018-02-22 13:55:29 <kaniini> which is why there is stuff like snaps and appimages
2018-02-22 13:55:55 <kaniini> what i really envision happening is adding the ability to apk to manage subroots
2018-02-22 13:56:47 <kaniini> if we have that, then it's possible to have multiple environments
2018-02-22 13:57:05 <kaniini> something like virtualenv for an entire filesystem :)
2018-02-22 13:57:23 <fcolista> heh
2018-02-22 13:57:28 <kaniini> this isn't likely to happen in 3.8 though
2018-02-22 13:57:50 <kaniini> but such modularity is on the roadmap for adelie linux 2
2018-02-22 14:02:23 <kaniini> so possibly 3.9 or 3.10
2018-02-22 14:22:46 <liwakura> >virtualenv for an entire filesystem
2018-02-22 14:23:05 <liwakura> i see that software is crappy enough that we even need this
2018-02-22 14:23:22 <liwakura> its still something i dont want ever to deal with
2018-02-22 15:05:21 <duncan_> Some people would find this functionality useful though
2018-02-22 16:08:30 <grharry> I have a 10Giga  Eth card Broadcom NetXtreme II BCM57810,  installed on my alpine server ( xen 3.7 ), anybody with similar network card?
2018-02-22 16:08:37 <grharry> any problems?
2018-02-22 18:31:36 <tmh1999> liwakura: re: the mkinitfs stuff we talked yesterday. It looks like when we boot from iso image, after the kernel is loaded, it looks for "init" program in initramfs-vanilla image. then *this* init script will create a (tmpfs) sysroot, then switch_root to it.
2018-02-22 18:34:05 <tmh1999> at first I thought it will switch_root to modloop-vanilla squashfs filesystem, but this squashfs just contains kernel modules.
2018-02-22 18:39:35 <liwakura> ye
2018-02-22 18:41:07 <AWilcox[m]> For what it's worth, liwakura, I agree that I don't ever want to deal with it either.  I would never personally use such feature (and would avoid software that would need it), but I know some people don't have a choice.
2018-02-22 19:12:59 <fabled> pushing new musl in a minute
2018-02-22 19:13:27 <ncopa> i was about to do it *now* :)
2018-02-22 19:13:52 <liwakura> oh, 1.19 out
2018-02-22 19:14:01 <fabled> ncopa, well, if you have it ready, go ahead
2018-02-22 19:14:07 <fabled> i was going through still the change logs
2018-02-22 19:14:27 <liwakura> security release or just regular?
2018-02-22 19:14:32 <fabled> feature release
2018-02-22 19:14:38 <fabled> bunch of bug fixes too
2018-02-22 19:16:14 <ncopa> i dont have it ready
2018-02-22 19:16:19 <ncopa> if you have it, push it
2018-02-22 19:16:31 <ncopa> all patches are to be removed?
2018-02-22 19:17:29 <fabled> not all
2018-02-22 19:17:35 <fabled> that's why it's taking time :)
2018-02-22 19:18:43 <ncopa> 2000-pthread-internals-increase-DEFAULT_GUARD_SIZE-to-2-p.patch and handle-aux-at_base.patch are not upstream
2018-02-22 19:19:35 <fabled> i think i got it ready
2018-02-22 19:19:43 <fabled> yeah, same conclusion
2018-02-22 19:19:48 <fabled> test built and seems to work
2018-02-22 19:19:51 <fabled> on x86_64
2018-02-22 19:20:49 <fabled> done
2018-02-22 19:22:39 <ncopa> i did on x86
2018-02-22 19:22:41 <ncopa> push it
2018-02-22 19:22:42 <ncopa> seems to work yes
2018-02-22 19:24:23 <ncopa> fabled: i have been looking at a somewhat interesting bug
2018-02-22 19:24:42 <ncopa> apparently getaddrinfo(3) from glibc does not work in user qemu-ppc64le built with musl
2018-02-22 19:24:45 <ncopa> but debian qemu works
2018-02-22 19:24:52 <ncopa> that is, it does not resolve anything when AF_UNSPEC is used
2018-02-22 19:24:56 <ncopa> when using AF_INET or AF_INET6 it works
2018-02-22 19:25:42 <fabled> oh?
2018-02-22 19:27:36 <ncopa> AF_UNSPEC works under debian's qemu-ppc64le
2018-02-22 19:27:36 <ncopa> #8131
2018-02-22 19:27:37 <ncopa> algitbot: hi
2018-02-22 19:27:38 <ncopa> https://bugs.alpinelinux.org/issues/8131
2018-02-22 19:27:39 <ncopa> i looked at the debian patches for qemu and it does not look like they have anything relevant
2018-02-22 19:28:11 <ncopa> algitbot: sorry if i woke you up from your sleep
2018-02-22 19:29:13 <ncopa> next plan is to build a static ppc64le strace and a C app that only calls getaddrinfo.
2018-02-22 19:29:14 <ncopa> i have only had access to python's socket.getaddrinfo
2018-02-22 19:29:49 <ncopa> its just weird...
2018-02-22 20:41:13 <kaniini> ncopa: the latter patch is from dalias
2018-02-22 20:41:18 <kaniini> ncopa: he intends to commit a more complete patch to musl
2018-02-22 20:42:09 <kaniini> ncopa: the former is a mitigation against stack jumping that dalias didn't want
2018-02-23 00:16:16 <mksully221> I'm trying to reproduce the build error http://build.alpinelinux.org/buildlogs/build-3-7-ppc64le/community/go/go-1.9.4-r0.log. My ppc64le box is installed with Ubuntu 16.04 and I'm starting an Alpine:3.7 container. In the container I
2018-02-23 00:16:16 <mksully221> apk update, apk upgrade, and apk add alpine-sdk, clone aports and git checkout the 3.7-stable branch. With this config I'm abuild'ing the community/go package and am not seeing any errors. Are there some other items I should be installing
2018-02-23 00:16:16 <mksully221> to more closely mimic the real ppc64le build machine environment in hopes of reproducing the error?
2018-02-23 01:22:07 <kaniini> humm that should really be close enough
2018-02-23 02:49:14 <koldbrutality> tox with python3 is broken huh?
2018-02-23 04:39:21 <BernhardG> mksully221: could that be a special case of the different kernel (hardened vs. Ubuntu kernel)?
2018-02-23 04:44:43 <mksully221> i though the hardened kernel was just x86? Is there a ppc64le version too?
2018-02-23 04:46:05 <andypost> please review/commit https://github.com/alpinelinux/aports/pull/3386
2018-02-23 05:00:48 <BernhardG> mksully221 my assumption was because it writes the reopening fails. that suggest that the file was there/accessible even if there are warn messages before that say it was not found
2018-02-23 05:01:31 <BernhardG> I don't know the exact build environment.
2018-02-23 05:03:38 <BernhardG> mksully221: could there also be a simple limit of max opened files? I don't know the exact error message for that case.
2018-02-23 05:13:42 <mksully221> thanks i'll look at that
2018-02-23 09:05:43 <ncopa> mksully221: i am rebooting the ppc64le machine. it had some OOPS and was very slow
2018-02-23 09:18:20 <koldbrutality> lol these checkdependencies are growing expodentially
2018-02-23 09:18:31 <koldbrutality> i'm about to give up on this
2018-02-23 09:18:39 <koldbrutality> just insanity
2018-02-23 09:19:33 <liwakura> koldbrutality: what are you trying to do?
2018-02-23 09:19:53 <koldbrutality> i am trying to fix all these check()
2018-02-23 11:22:28 <ncopa> the ppc64le machine nevver came back :-/
2018-02-23 11:31:12 <_ikke_> ncopa: :(
2018-02-23 12:38:02 <danieli> ncopa: check email
2018-02-23 12:38:12 <danieli> ibm is having a look at ppc64le
2018-02-23 12:48:25 <ncopa> thanks
2018-02-23 14:36:58 <clandmeter> kaniini: is your new apk tools version going to have a way to generate a dependency graph?
2018-02-23 14:41:22 <kaniini> apk dot already does that
2018-02-23 15:08:51 <clandmeter> kaniini: i think i mean runtime dependency tree. so i can get a list of what alpine-base pulls in.
2018-02-23 15:09:51 <ncopa> it sort of does that, just presents it as a graphical graph :)
2018-02-23 15:09:55 <ncopa> clandmeter: i pushed mqtt-exec with crypto support
2018-02-23 15:09:58 <clandmeter> ah yes thx
2018-02-23 15:09:58 <ncopa> it was all ok, right?
2018-02-23 15:09:59 <clandmeter> i wanted to ask you :)
2018-02-23 15:10:02 <ncopa> except the help text typo
2018-02-23 15:10:05 <ncopa> i want to tag new release
2018-02-23 15:10:06 <clandmeter> i didnt test the keys
2018-02-23 15:10:08 <clandmeter> but cert base yes
2018-02-23 15:10:21 <ncopa> the psk?
2018-02-23 15:10:26 <clandmeter> yep
2018-02-23 15:10:32 <ncopa> do you think you could give it a testrun?
2018-02-23 15:10:38 <clandmeter> i never used it so i need to check it.
2018-02-23 15:10:53 <ncopa> i think you set a pre shared "password"
2018-02-23 15:11:07 <clandmeter> its user:key if im right
2018-02-23 15:11:43 <clandmeter> where user can be used as auth
2018-02-23 17:10:38 <andypost> what's left here https://github.com/alpinelinux/aports/pull/3303 to be accepted?
2018-02-23 17:11:33 <_ikke_> Might take some time before things are merged
2018-02-23 17:38:53 <tmh1999> I am an awk programmer, but I have a hang at : https://git.alpinelinux.org/cgit/aports/tree/main/openrc/networking.initd#n26
2018-02-23 17:39:03 <tmh1999> with this : for i in $(grep auto $ifconf ); do [ "$i" == "auto" ] && continue; printf "%s " $i; done
2018-02-23 17:39:06 <tmh1999> I made it work
2018-02-23 17:39:14 <tmh1999> is it okay to make this change ?
2018-02-23 17:40:28 <tmh1999> * I am not an awk programmer
2018-02-23 17:40:38 <tmh1999> :(
2018-02-23 17:40:48 <tmh1999> this line works out for me for a while now.
2018-02-23 18:00:28 <koldbrutality> what is the standard java on this distro?
2018-02-23 18:03:04 <koldbrutality> nm i think i found it
2018-02-23 18:07:11 <przemoc> tmh1999: it should rather not hang.  the only easy way I see it hanging is if ifconf is empty, but it should be not.  your workaround is not good enough.  it disregards commented out lines and uses bashism (== instead of =)
2018-02-23 18:08:18 <tmh1999> przemoc : == should be = just fine. yeah I agree with comments.
2018-02-23 18:08:30 <przemoc> you can replace  grep auto $ifconf  with  sed '/^[^#]*auto[ \t][ \t]*/!d;s,,,;' "$ifconf"  and then you can also remove short-circuit on "auto"
2018-02-23 18:09:07 <liwakura> przemoc: why the empty substitution?
2018-02-23 18:09:46 <przemoc> reusing pattern from the search
2018-02-23 18:09:47 <tmh1999> przemoc : afaik, find_ifaces() takes no argument, correct ? the only place calls it is : https://git.alpinelinux.org/cgit/aports/tree/main/openrc/networking.initd#n43
2018-02-23 18:11:50 <przemoc> yeah, it takes no args
2018-02-23 18:15:57 <przemoc> tmh1999: are you fighting with some s390x perhaps still?  maybe your awk misbehaves there.
2018-02-23 18:16:11 <tmh1999> yeah
2018-02-23 18:17:52 <tmh1999> przemoc : funny thing, I have this tweak a while ago. Now I am revisiting it, # /etc/init.d/networking restart works ok. but if I take the function out and run it alone, it hangs. Not really sure if I should be concerned about this anymore.
2018-02-23 18:18:59 <przemoc> yeah, it won't work alone, because ifconf is not defined then, so awk expect data on stdin
2018-02-23 18:19:09 <przemoc> s/expect/&s/
2018-02-23 18:19:22 <tmh1999> hah
2018-02-23 18:19:24 <tmh1999> interesting
2018-02-23 18:19:29 <tmh1999> thanks !
2018-02-23 18:19:42 <tmh1999> right I forgot $ifconf
2018-02-23 18:20:09 <tmh1999> since no arg is passed, $1 = 'auto' kind of strange to me
2018-02-23 18:20:39 <przemoc> $1 means the first field in awk
2018-02-23 18:21:56 <tmh1999> I should take a crash course in awk
2018-02-23 18:22:09 <tmh1999> that's interesting though
2018-02-23 18:22:45 <przemoc> awk is quite nice, at least it's readable compared to more complex sed scripts
2018-02-23 18:36:36 <tmh1999> przemoc : while you're here, may I ask you one more thing ? would kernel parm console=/dev/console  override those ttyX in /etc/inittab ?
2018-02-23 18:37:15 <tmh1999> only /dev/console works out for me on s390x, and passing that kernel parm wouldn't help. I have to hard code in /etc/inittab
2018-02-23 18:37:46 <tmh1999> like : console::respawn:/sbin/getty 38400 /dev/console
2018-02-23 18:42:29 <tmh1999> I think I will submit a patch for alpine-baselayout for this
2018-02-23 18:44:24 <tmh1999> maybe console=console work
2018-02-23 18:45:06 <przemoc> tmh1999: no, console=... passed to kernel not influences inittab.
2018-02-23 18:45:49 <przemoc> and kernel does not take console as /dev/...
2018-02-23 18:47:44 <przemoc> so your console parameter passed to kernel is possibly bogus
2018-02-23 19:00:23 <przemoc> tmh1999: I could be misunderstood, so let me clarify.  while inittab is not influenced per se, if you use /dev/console there, it will be influenced by console= kernel parameter.  also openrc's init does use /dev/console early, so if console=... is correct but not pointing to anything you can see, you won't see openrc's output.
2018-02-23 19:03:16 <tmh1999> przemoc : understood
2018-02-23 19:24:26 <BernhardG> I've managed to package the current version of LizardFS (3.12.0) - which also needs some other libraries not available in egde currently. There is also an older version of LizardFS (2.6.0) in testing but it is not listed on pkgs.alpinelinux.org. How does a PR work in that case?
2018-02-23 19:29:08 <tmh1999> BernhardG: It's currently disabled by arch="". Looks like unmaintained to me. If you want to take a maintainership/ bump to new ver, just submit a pr.
2018-02-23 19:36:48 <BernhardG> tmh1999, thank you for your answer. I consider doing so because we are using LizardFS anyway in some context and these systems get migrated to alpine in the near future.
2018-02-23 19:41:48 <HRio> hi any news on backporting the gcc changes for "indirect thunk" to Alpine?
2018-02-23 20:36:19 <koldbrutality> chromium crashed for selenium with chromedriver: https://pastebin.com/C5R3MgFa
2018-02-23 20:39:37 <koldbrutality> i ran chromedriver with --help it seems to not crash
2018-02-23 20:55:30 <koldbrutality> trying no-sandbox
2018-02-23 20:59:10 <AWilcox[m]> Would it be acceptable to enable S/MIME in the main/mutt package?
2018-02-23 21:00:11 <AWilcox[m]> Looks like it adds about 100 kB to the size of the package.
2018-02-23 21:10:23 <koldbrutality> lol it works.... it opened the web browser and did the tests
2018-02-23 21:14:34 <koldbrutality> what app would benefit?
2018-02-23 21:14:51 <koldbrutality> i just read email that is all no fancy stuff
2018-02-23 21:15:37 <koldbrutality> probably an external framebuffer viewer
2018-02-23 21:15:45 <koldbrutality> might be a good idead
2018-02-24 01:07:17 <koldbrutality> i have to build entire testing/firefox for small a geckodriver :'(
2018-02-24 14:59:57 <koldbrutality> the mesa package has no test suite
2018-02-24 15:00:10 <koldbrutality> not run but on gentoo it does
2018-02-24 20:16:30 <bleb> hey i was wondering how stuff gets moved from testing to community?
2018-02-24 20:17:08 <_ikke_> bleb: the maintainer usually requests the move
2018-02-24 20:17:54 <bleb> nvi has been in testing for a couple years now
2018-02-24 20:18:56 <_ikke_> you can ask Sören Tempel if it can be moved to community
2018-02-24 20:20:10 <bleb> ok will do, thanks
2018-02-24 21:35:02 <nmeum_> bleb: I am the nvi maintainer, I just send you a response to your mail ;)
2018-02-25 07:25:51 <HRio> nmeum: I guess its due to that nvi is not maintained upstream (that it will never leave testing). Debian ships i vim-tiny for base installs, that would be a nice option to the busybox version vi on Alpine, instead of nvi.
2018-02-25 12:11:13 <skarnet> Hey alpinists...
2018-02-25 12:11:29 <skarnet> Is there a known interaction between globbing and fakeroot?
2018-02-25 12:12:17 <skarnet> because I have a line in an APKBUILD's package() function doing: cp -f "$builddir/inc/*" "$pkgdir/usr/include/"
2018-02-25 12:12:35 <skarnet> and it fails, saying it can't stat $builddir/inc/* (builddir is expanded)
2018-02-25 12:12:44 <skarnet> because ENOENT
2018-02-25 12:12:58 <skarnet> but I know for a fact there are files there, and doing the cp manually works
2018-02-25 12:13:14 <skarnet> so the only explanation I have is that fakeroot messes up the globbing somehow
2018-02-25 12:13:21 <skarnet> is it something well-known?
2018-02-25 12:15:11 <skarnet> ok, forget it
2018-02-25 12:15:34 <skarnet> sorry for the noise.
2018-02-25 12:16:51 <skarnet> (the only difference between single and double quotes is $ expansion, so globbing doesn't happen inside double quotes. sigh.)
2018-02-25 16:28:48 <tdtrask[m]> Test from Matrix
2018-02-25 16:52:50 <koldbrutality> too many messed up python packages
2018-02-25 16:53:11 <koldbrutality> i will make a lot of pull requests because of this
2018-02-25 16:56:58 <koldbrutality> everything that sits on top of them will have to be updated
2018-02-25 18:41:15 <PureTryOut[m]> I wonder how libcanberra-gtk2 can exist with the current APKBUILD... for me it just complains GTK can not be found, so it seems to lack some dependencies.
2018-02-25 18:41:33 <PureTryOut[m]> the build log gives a 404... http://build.alpinelinux.org/buildlogs/build-edge-aarch64/main/libcanberra-gtk2/libcanberra-gtk2-0.30-r2.log
2018-02-25 18:42:01 <PureTryOut[m]> is it maybe an idea to drop libcanberra-gtk2? it seems there are no packages depending on it other than libcanberra itself, and gtk2 is old anyway
2018-02-25 21:13:51 <_ikke_> clandmeter: thanks for merging piknik :)
2018-02-25 23:05:21 <lorddaedra> Hello) looks like Flag button do not work, I tried to flag https://pkgs.alpinelinux.org/package/v3.7/main/x86_64/haproxy# as outdated.. 1.7.9 vs. 1.8.4..
2018-02-25 23:05:46 <_ikke_> clandmeter: ^
2018-02-25 23:05:50 <_ikke_> returns 404 not found
2018-02-25 23:06:12 <clandmeter> thats correct
2018-02-25 23:06:29 <clandmeter> you cannot flag stable branches
2018-02-25 23:06:47 <clandmeter> ha
2018-02-25 23:06:57 <clandmeter> i need to remove the button
2018-02-25 23:07:53 <clandmeter> lorddaedra: you can only flag on edge branch
2018-02-25 23:07:56 <lorddaedra> I try to flag https://pkgs.alpinelinux.org/package/edge/main/x86_64/haproxy# but do not see any output after button click
2018-02-25 23:08:13 <lorddaedra> Tried in Chromium and FF
2018-02-25 23:08:29 <clandmeter> its already flagged
2018-02-25 23:08:58 <clandmeter> https://pkgs.alpinelinux.org/flagged?origin=haproxy
2018-02-26 00:39:48 <lorddaedra> just as idea: add votes for packages to sort their update priority order
2018-02-26 00:40:13 <lorddaedra> it will allow to see which packages are "most wanted"
2018-02-26 11:13:50 <BernhardG> Is it considered as a bug that there is a /etc/conf.d/hostname file which is never used? It seems /etc/hostname gets used. Or is there any other reason behind having this file in openrc?
2018-02-26 11:17:29 <_ikke_> BernhardG: what does apk info -W /etc/conf.d/hostname return?
2018-02-26 11:18:00 <_ikke_> ah, openrc
2018-02-26 11:19:20 <_ikke_> BernhardG: So it's just automatically added for every *.initd file
2018-02-26 11:20:30 <BernhardG> _ikke_, ok. But the description in it is misleading "Set to the hostname of this machine". It seems it does not change anything.
2018-02-26 11:21:43 <_ikke_> Hm, I think that file comes from openrc itself
2018-02-26 11:22:11 <_ikke_> https://github.com/OpenRC/openrc/blob/master/conf.d/hostname
2018-02-26 11:23:24 <_ikke_> https://github.com/OpenRC/openrc/blob/master/init.d/hostname.in
2018-02-26 11:23:27 <BernhardG> _ikke_, seems so. Those scripts also don't use that file. So this could be an upstream problem.
2018-02-26 11:24:09 <_ikke_> BernhardG: the hostname.in script does use it (it's automatically loaded by openrc)
2018-02-26 11:25:52 <BernhardG> _ikke_, thank you.
2018-02-26 11:25:54 <_ikke_> BernhardG: So the default initd script does seem to use it, but it's overridden in alpine
2018-02-26 20:10:57 <tmh1999> gerrit seems to be cool, could replace/merge github + bugs.a.o + alpine-aports ml, into 1 place.
2018-02-26 20:11:24 <tmh1999> not sure if it was brought here or not, just want to speak out
2018-02-26 20:13:36 <tmh1999> it seems also play nicely with cgit
2018-02-26 21:06:57 <kaniini> fabled: do you have any thoughts on apk rollbacks
2018-02-26 21:26:17 <HRio> kaniini: https://github.com/alpinelinux/aports/pull/3026#issuecomment-368656010
2018-02-26 21:26:48 <fabled> kaniini, i have had them on my todo
2018-02-26 21:27:16 <fabled> kaniini, initial thought is to keep track of pkg=id records somewhere for rollback
2018-02-26 21:35:55 <HRio> fabled: do you know if somebody is working on "indirect thunk" for gcc shipped with Alpine?
2018-02-26 21:36:33 <fabled> HRio, what's that?
2018-02-26 21:36:43 <HRio> needed for SP2 mitigations
2018-02-26 21:37:09 <HRio> can not prepare the XEN SP2 mitigations without that support in gcc
2018-02-26 21:38:02 <fabled> oh that one
2018-02-26 21:38:11 <fabled> the new switch to emit those
2018-02-26 21:38:35 <fabled> not sure.
2018-02-26 21:39:28 <HRio> I guess its needed for linux retpoline as well, but not sure
2018-02-26 21:45:57 <HRio> https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01043.html
2018-02-26 21:47:28 <fabled> HRio, i think yeah, i remember the retpoline name only
2018-02-26 21:49:32 <fabled> we should probably cherrypick the commits unless they do release soon
2018-02-26 21:50:49 <HRio> debian released an updated 6.3 version of gcc the other day, could be a start to see what patches the picked
2018-02-26 21:50:59 <HRio> s/the/they/
2018-02-26 21:52:56 <fabled> would be good reference, yes
2018-02-26 21:58:06 <HRio> seems to be patches by "H.J. Lu" <hjl.tools@gmail.com> seems to be 8 patches in total, the first three have hjl <hjl@138bc75d-0d04-0410-961f-82ee72b054a4> and the last "H.J. Lu" <hjl.tools@gmail.com>
2018-02-26 21:58:37 <HRio> can not find where Debian maintain gcc for stable at the moment
2018-02-26 21:58:47 <HRio> so just downloaded the source package
2018-02-26 22:10:36 <HRio> First patch in series: Subject: [PATCH] i386: Move struct ix86_frame to machine_function
2018-02-26 22:11:17 <HRio> last: [PATCH] x86: Disallow -mindirect-branch=/-mfunction-return= with -mcmodel=large
2018-02-27 02:25:06 <mepholic> what the fuck
2018-02-27 02:25:13 <mepholic> the lynx package has no https support
2018-02-27 02:46:20 <Aerdan[m]> adelie's does!
2018-02-27 02:46:46 <Aerdan[m]> mepholic: lynx is slated to get adelie's changes at some point, ISTR.
2018-02-27 02:47:12 <mepholic> good, glad to hear it
2018-02-27 02:55:40 <koldbrutality> lol
2018-02-27 07:38:19 <xentec> ncopa, et al: if you're going to update the kernel or its modules, please consider merging this pr first: https://github.com/alpinelinux/aports/pull/3365
2018-02-27 10:07:03 <ncopa> xentec: thanks for the reminder
2018-02-27 10:45:08 <ncopa> jirutka/Shiz: what is the status of porting rust to the remining arches?
2018-02-27 10:45:19 <ncopa> i'd love to have rust on every arch for the v3.8 release
2018-02-27 12:20:21 <jirutka> ncopa: well, I’ve tried to use mrustc to bootstrap rustc and cargo for x86_64 from sources and eventually use it even for other arches
2018-02-27 12:20:51 <jirutka> ncopa: but there are still some problems, cargo compiled by rustc compiled by mrustc segfaults
2018-02-27 12:22:57 <jirutka> ncopa: I didn’t try to cross-compile rustc from x86_64 to other arches yet, tbh I currently don’t have so strong interest in it to invest the time, b/c I have very limited experience with cross-compiling, so it would take me quite long to figure out how to actually do that for rustc
2018-02-27 12:24:50 <jirutka> ncopa: and I’m still balancing between “I want to support the Rust language” and “I don’t wanna maintain this crap and deal with ignorance/stupidity/immaturity of people behind Cargo”
2018-02-27 12:28:04 <jirutka> talking about cargo, there are still some pending issues :(
2018-02-27 13:21:53 <terra> Guys, I'm working on a new copy of aports git repo. Git hooks seem not working. Is there something to configure?
2018-02-27 13:22:10 <_ikke_> terra: what hooks do you expect to run?
2018-02-27 13:22:25 <terra> new aport:
2018-02-27 13:22:53 <_ikke_> You need to manually place those hooks
2018-02-27 13:23:10 <_ikke_> (I'm not aware of any aports git hooks, but they will never be automatically installed after clone)
2018-02-27 13:23:38 <terra> hmm.. I fotgot how I enabled previous oneç
2018-02-27 13:26:50 <terra> It seems I have to copy .githooks/* to .git/hooks
2018-02-27 13:26:59 <_ikke_> right
2018-02-27 13:27:10 <_ikke_> make sure they're executable as well
2018-02-27 13:27:22 <terra> yep.. thanks.
2018-02-27 15:28:08 <jirutka> I’d like to know why I have quite often problem with Alpine not booting after upgrade, this time syslinux cannot find configuration file… I’ve been using syslinux even on Gentoo for 5 years and never had such problem
2018-02-27 16:06:15 <ncopa> difficult to know based on the above info
2018-02-27 16:06:35 <ncopa> why didn't syslinux find the config?
2018-02-27 16:07:49 <jirutka> I don’t know, i can’t figure it out
2018-02-27 16:07:58 <jirutka> I can boot it when i manually enter the kernel line
2018-02-27 16:08:08 <jirutka> so it can find vmlinuz and initrd
2018-02-27 16:08:30 <jirutka> it may be also caused by that shitty OpenNebula :(
2018-02-27 16:11:12 <ncopa> vanilla kernel?
2018-02-27 16:11:32 <ncopa> i had issue with the vmlinuz -> vmlinuz-vanilla rename in my boot loader
2018-02-27 16:15:19 <kaniini> did you?  i'm sorry if so
2018-02-27 16:16:45 <ncopa> not sure it was your fault
2018-02-27 16:16:46 <ncopa> i use gummiboot
2018-02-27 16:16:48 <ncopa> and the config is not generated
2018-02-27 16:16:49 <ncopa> i dont think we have trigger script for it
2018-02-27 16:17:03 <ncopa> and i dont think its worth implement either because gummiboot is sort of dead upstream
2018-02-27 16:17:22 <ncopa> i tried to "fix" that issue by create a vmlinuz symlink
2018-02-27 16:17:31 <ncopa> but that does not work if your /boot is on FAT
2018-02-27 16:17:31 <ncopa> eg UEFI
2018-02-27 16:17:41 <ncopa> so i reverted that
2018-02-27 16:18:23 <kaniini> ah i switched to grub2 a while ago
2018-02-27 16:19:08 <ncopa> i suppose i should too
2018-02-27 16:19:20 <TBB> kind of wish someone picks it up, it's just so much cleaner than the monstrosity that is grub2
2018-02-27 16:20:55 <fabled> gummi was sucked into systemd iirc
2018-02-27 16:21:30 <ncopa> thats what i meant with "sort of"
2018-02-27 16:23:51 <TBB> that's what happened, yes
2018-02-27 16:25:12 <bernhardgruen[m]> jirutka: I did not have any boot problems with Alpine and Opennebula so far.
2018-02-27 16:26:47 <bernhardgruen[m]> jirutka: are you sure the problem is not related to your way you are using the whole /dev/sda without a partition table?
2018-02-27 16:29:03 <jirutka> bernhardgruen[m]: I don’t think so
2018-02-27 16:29:34 <jirutka> bernhardgruen[m]: I really think this case is really caused by some issue in our infra, b/c, well, we curently have many issues…
2018-02-27 16:29:41 <jirutka> with storage
2018-02-27 16:31:50 <bernhardgruen[m]> Maybe I can help. I am using Alpine and I need working systems. I also use opennebula and so I may be able to find a test case to debug it.
2018-02-27 16:33:06 <jirutka> but this does not happen on all VMs
2018-02-27 16:35:45 <bernhardgruen[m]> Does it happen for a newly generated VM already?
2018-02-27 16:36:04 <bernhardgruen[m]> Or does it only happen with edge kernel?
2018-02-27 16:37:01 <jirutka> no, for old VMs
2018-02-27 16:37:14 <jirutka> as I said, when upgrading from older version (to stable, not edge)
2018-02-27 16:39:14 <ncopa> any objection to add nghttp2 support to curl?
2018-02-27 16:39:24 <bernhardgruen[m]> I could easily test 3.6 to 3.7 (virthardened kernel)
2018-02-27 16:43:47 <jirutka> bernhardgruen[m]: thanks for interest, but I think that it’s not worth the effort, this is some old VM installed manually (not by alpine-make-vm-image), cloned from another VM, and we have serious problems with Ceph now
2018-02-27 16:45:20 <jirutka> bernhardgruen[m]: when I wrote my complain it was right after it didn’t boot, but now when I checked that all configs are okay, manually running syslinux --install didn’t fix it etc. so it’s for 99 % not Alpine’s fault
2018-02-27 16:51:52 <bernhardgruen[m]> Ok. Did you have some read timeouts in ceph?, Jirutka?
2018-02-27 16:52:22 <jirutka> bernhardgruen[m]: I don’t operate the Ceph cluster, so can’t say
2018-02-27 16:52:47 <jirutka> bernhardgruen[m]: and really, this infra is currently in almost critical state and we’re currently building new one and preparing rebuild of this
2018-02-27 16:56:50 <bernhardgruen[m]> Oh, that does not sound that good. At the moment I am running a LizardFS Cluster as an alternative to Ceph. Maybe that's a solution for you too. I already packaged it for Alpine. ;)
2018-02-27 16:58:20 <kaniini> by the way, if you guys are interested in playing with apk-tools 2.10
2018-02-27 16:58:39 <kaniini> http://raccoon.dereferenced.org/repos/
2018-02-27 16:58:52 <kaniini> if the apk offered here blows up your system, tough shit
2018-02-27 16:59:07 <kaniini> in other words, do not use these packages in production
2018-02-27 16:59:33 <kaniini> i have gone out of my way to ensure that using these packages in production is undesirable, such as hosting the repo out of my garage
2018-02-27 17:00:02 <kaniini> and while i do have a metro ethernet circuit to my house, if some idiot blows the breaker while doing laundry, the server hosting said repo may be down for a while
2018-02-27 17:03:22 <jirutka> kaniini: binaries are cheap. show me the code
2018-02-27 17:04:24 <kaniini> what about code
2018-02-27 17:04:34 <ncopa> https://git.alpinelinux.org/cgit/apk-tools/
2018-02-27 17:04:35 <kaniini> it is just the normal apk-tools APKBUILD with a custom unpack
2018-02-27 17:07:17 <kaniini> http://raccoon.dereferenced.org/repos/APKBUILD.txt
2018-02-27 17:09:41 <bernhardgruen[m]> kaniini: how does that work with the ${COMMIT} variable? in pkgver?
2018-02-27 17:10:45 <kaniini> i just run
2018-02-27 17:10:49 <bernhardgruen[m]> kaniini: this does only work for git, right? (i.e. not for bazaar or mercurial)
2018-02-27 17:10:58 <kaniini> env COMMIT=... PKGREL=... abuild -r
2018-02-27 17:10:59 <jirutka> so the code is in upstream apk-tools code and i can build it myself…?
2018-02-27 17:11:06 <kaniini> you can do whatever you want in unpack()
2018-02-27 17:11:09 <kaniini> but it's horrible
2018-02-27 17:11:30 <kaniini> jirutka: code for what
2018-02-27 17:11:33 <kaniini> there is no subtrees code yet
2018-02-27 17:11:39 <jirutka> "by the way, if you guys are interested in playing with apk-tools 2.10"
2018-02-27 17:11:52 <kaniini> oh
2018-02-27 17:11:58 <kaniini> yes
2018-02-27 17:12:03 <bernhardgruen[m]> ok - thanks, kaniini  This makes some of my packaging work easier.
2018-02-27 17:12:10 <kaniini> what is presently in git will become apk-tools 2.10
2018-02-27 17:12:16 <kaniini> after more stuff is added
2018-02-27 17:13:22 <kaniini> i made the repo because a few people wanted to try out apk list and see if it did better for their needs than apk search
2018-02-27 17:13:30 <jirutka> aha
2018-02-27 17:17:46 <kaniini> bernhardgruen: note that overriding unpack() is technically a policy violation
2018-02-27 17:18:31 <bernhardgruen[m]> kaniini: I thought so. But I need to package some (internal) legacy stuff.
2018-02-27 17:19:40 <bernhardgruen[m]> I really hope most of that (java) code dies before we use it in practice on alpine linux.
2018-02-27 17:26:17 <koldbrutality> what you guys think.  about this situation.  in order to run the test suite i need to compile the build as scons debug=1 but i want the release build also.  suggestions?  you think i need to change the code to build the tests for release or recompile the code in debug in check()?
2018-02-27 17:27:08 <koldbrutality> or just ship the debug build?
2018-02-27 17:28:03 <ncopa> koldbrutality: i dont like idea of rebuilding it in check
2018-02-27 17:28:38 <ncopa> can you do both builds in build() in different build trees?
2018-02-27 17:28:47 <koldbrutality> i was thinking about that
2018-02-27 17:28:50 <ncopa> does it support out-of-tree build?
2018-02-27 17:29:02 <bernhardgruen[m]> Is there a reason for not having the ZFS module on the virt and virthardened kernels? Also the new virt kernel depends on linux-firmware-* as it seems.
2018-02-27 17:29:17 <koldbrutality> i don't know... i can just duplicate both
2018-02-27 17:30:46 <bernhardgruen[m]> Natanael Copa: koldbrutality This in fact does not test the same code but only the version with debug code. This can be a difference. But I assume this will be no real issue for normal programs.
2018-02-27 17:31:05 <kaniini> imo don't bother with running tests if the testsuite binary is going to be different than the real one
2018-02-27 17:31:05 <ncopa> koldbrutality: but otoh, you'd be testing a different build than what the user ends up with
2018-02-27 17:31:23 <kaniini> what we are trying to do with check() is verify the real binary
2018-02-27 17:31:27 <koldbrutality> i just ship the debug then
2018-02-27 17:31:45 <koldbrutality> this is a game engine
2018-02-27 17:31:49 <kaniini> and no, do not just run $binary --version
2018-02-27 19:23:07 <_ikke_> We are doing an upgrade on bugs.alpinelinux.org, it will be offline for a few minutes
2018-02-27 21:50:11 <kaniini> koldbrutality: hi i am reviewing your stuff, are you around
2018-02-27 21:50:59 <koldbrutality> yeah but busy trying to fix godot's check() function.  I can't switch git branch.
2018-02-27 21:52:24 <kaniini> ok
2018-02-27 21:52:51 <kaniini> koldbrutality: i can fix bear for you, i just wanted you to be aware of the review i left for future reference
2018-02-27 22:22:34 <jirutka> kaniini: this is not okay https://github.com/alpinelinux/aports/commit/14d028ef5e2f505291dbd744eb71b81cfc11d736#diff-750eb93fe928340442b0d9ea4b69e7cbR13
2018-02-27 22:22:43 <jirutka> good luck with bumping this
2018-02-27 22:23:51 <jirutka> kaniini: https://wiki.alpinelinux.org/wiki/APKBUILD_examples:Python#source
2018-02-27 22:25:01 <kaniini> i already fixed it
2018-02-27 22:26:03 <jirutka> it’s imo better to fix it right before merging
2018-02-27 22:26:32 <kaniini> and the !archcheck thing
2018-02-27 22:26:37 <jirutka> this is also bad https://github.com/alpinelinux/aports/commit/be409dcb9b03d61234bf59a9e264a622b376b5ef#diff-979a30223dd769bfb70838221be21dd0R17
2018-02-27 22:26:38 <kaniini> just didnt push yet
2018-02-27 22:26:39 <kaniini> because was trying to fix patchwork
2018-02-27 22:26:40 <kaniini> because patchwork sucks
2018-02-27 22:27:29 <kaniini> really
2018-02-27 22:27:38 <jirutka> I’m talking it qutie a long time that patchwork is unusable crap :P
2018-02-27 22:27:55 <kaniini> that is on the maintainer to deal with
2018-02-27 22:28:10 <jirutka> what?
2018-02-27 22:28:47 <jirutka> this is how to deal with hash in dirname https://github.com/alpinelinux/aports/blob/master/main/graphviz/APKBUILD#L30
2018-02-27 22:29:33 <kaniini> sure
2018-02-27 22:29:47 <jirutka> kaniini: sigh
2018-02-27 22:29:48 <jirutka> omfg
2018-02-27 22:29:51 <jirutka> what is this https://github.com/alpinelinux/aports/commit/6f33fb4651d968f69abbdd4303ff7a425e296316?
2018-02-27 22:30:01 <jirutka> testing/rakudo: new aport  … and what is there…?
2018-02-27 22:30:12 <jirutka> totally unrealted changes in two other pkgs
2018-02-27 22:30:29 <jirutka> i’m rather gonna close it and go sleep
2018-02-27 22:31:14 <kaniini> that sounds like a good productive use of your time
2018-02-27 22:31:20 <kaniini> the PR was a mess, i had to clean it up somehow
2018-02-27 22:32:38 <jirutka> what about archcheck thing, why is it used?
2018-02-27 22:37:45 <kaniini> i didn't notice it on that one, but i fixed that too
2018-02-27 23:07:51 <mepholic> 11:39:14 <ncopa> any objection to add nghttp2 support to curl?
2018-02-27 23:07:53 <mepholic> no none
2018-02-27 23:09:09 <jirutka> nghttp2 is support for HTTP2, right?
2018-02-27 23:09:22 <jirutka> if yes, then no objection
2018-02-27 23:09:33 <jirutka> (from me)
2018-02-27 23:09:38 <Aerdan[m]> yes
2018-02-27 23:11:41 <mepholic> yeah it is
2018-02-27 23:12:28 <mepholic> actually sort of surprised that wasn't in the adelie merge
2018-02-28 06:58:57 <mepholic> ncopa: THANK YOU FOR FIREFOX 58
2018-02-28 06:59:06 <mepholic> currently testing for you
2018-02-28 06:59:58 <mepholic> i'm also testing kaniini's apk 2.10
2018-02-28 10:15:45 <ncopa> mepholic: yw
2018-02-28 13:36:55 <clandmeter> kaniini: do you have a solution for libressl missing cms function?
2018-02-28 13:42:57 <skarnet> what needs cms?
2018-02-28 13:43:46 <clandmeter> ipxe
2018-02-28 13:43:52 <clandmeter> to sign the images
2018-02-28 13:43:56 <skarnet> (somehow I can kinda tell kaniini's solution would be "use openssl")
2018-02-28 13:44:18 <clandmeter> probably
2018-02-28 13:44:19 <skarnet> hmm
2018-02-28 13:44:26 <clandmeter> but our openssl lacks it
2018-02-28 13:44:35 <skarnet> oh?
2018-02-28 13:44:46 <skarnet> how so?
2018-02-28 13:44:58 <clandmeter> i dont think it has the openssl cmd at all
2018-02-28 13:45:03 <clandmeter> because of limited config
2018-02-28 13:45:53 <skarnet> you mean iPXE needs an "openssl cms" command oslt, instead of a C API to use CMS?
2018-02-28 13:47:45 <clandmeter> http://ipxe.org/crypto
2018-02-28 13:48:09 <clandmeter> maybe there is another way, thats why im asking.
2018-02-28 13:50:17 <skarnet> oh, this is not a hard dependency, just an operational need to sign a binary?
2018-02-28 13:50:47 <skarnet> probably would be worth it to have an openssl-bin package with the openssl binary
2018-02-28 13:51:02 <skarnet> with cms support and everything you want to throw into it
2018-02-28 13:51:13 <skarnet> and have openssl-bin in ipxe's makedepends
2018-02-28 13:51:21 <skarnet> or wherever it's needed
2018-02-28 13:54:30 <clandmeter> thats what i was expecting.
2018-02-28 14:22:20 <clandmeter> so openssl does ship the openssl binary, but libressl replaces openssl so openssl does not provide it if you have libressl installed.
2018-02-28 14:22:51 <Aerdan[m]> libressl provides its own openssl binary?
2018-02-28 14:22:53 <clandmeter> and i cannot remove libressl because its needed by something else...
2018-02-28 14:23:14 <clandmeter> yes, libressl has an openssl binary of course.
2018-02-28 14:26:28 <clandmeter> the only way would be to have a compat(or similar) subpkg with the openssl version of openssl binary and rename it to something different (openssl-compat/real or whatever)
2018-02-28 14:26:50 <Aerdan[m]> should probably rename that to libressl and provide a symlink that openssl can override.
2018-02-28 14:28:48 <skarnet> "provides: openssl-bin"
2018-02-28 14:29:15 <skarnet> or separate libressl's openssl binary into a libressl-bin package, conflicting with openssl-bin
2018-02-28 14:29:37 <skarnet> so you can have both the libressl and openssl libraries installed, but only one implementation of the openssl binary
2018-02-28 14:39:16 <przemoc> I think it would be better to have libressl-openssl (just like there are various libressl-lib* pkgs), where openssl binary would be provided with libressl- prefix, and libressl-openssl-compat, where this binary would be symlinked from mere openssl.  such compat pkg would be the only one conflicting package.  anyone installing libressl would get both (from depends), but those caring about more
2018-02-28 14:39:22 <przemoc> options and wanting original openssl (but maybe libressl's too for some reason), could be specific and go with libressl-openssl instead of libressl, so installing openssl wouldn't be a problem.
2018-02-28 14:48:41 <bernhardgruen[m]> What is the current reason to use libressl over openssl? I know that it is not possible to switch and recompile all packages in just one day.
2018-02-28 14:50:58 <Aerdan[m]> There isn't really one unless you specifically want the libtls API, which IIRC isn't available outside of libressl at the moment (aside from bearssl, maybe?)
2018-02-28 14:51:28 <Aerdan[m]> tbh both openssl and libressl need to die in a fire, since they're both awful.
2018-02-28 14:52:34 <bernhardgruen[m]> But openssl seems to be used more often in the wild, right?
2018-02-28 15:27:22 <skarnet> bernhardgruen[m]: there's a discussion thread about it on the alpine-devel mailing-list
2018-02-28 15:27:59 <skarnet> tl;dr: Alpine switched to libressl at a time when it made sense, but today those reasons are less valid
2018-02-28 15:28:31 <skarnet> Aerdan[m]: no, bearssl doesn't have a libtls API, but I plan to write a wrapper at some time
2018-02-28 15:59:39 <nmeum> ncopa: am I missing something or did you forget to push the patch https://git.alpinelinux.org/cgit/aports/tree/main/alpine-conf/0001-update-kernel-handle-vanilla-suffix-in-System.map-co.patch to the alpine-conf repository?
2018-02-28 16:07:28 <Aerdan[m]> oh, maybe I misremembered who else had one (or recalled wrongly /that/ there was another impl).
2018-02-28 16:16:04 <skarnet> maybe there's another impl, but I don't know about it, and it's certainly not over bearssl.
2018-02-28 17:10:35 <bernhardgruen[m]> skarnet: I just read the mail archive. From my point of view an open policy (i.e. using both libraries for community builds) could make a possible switch easier. That way only the rather small part of main packages need a forced rebuild to openssl.
2018-02-28 17:17:07 <tmh1999> ncopa: Have we considered before making the initramfs, that allows installing a SSH server, instead of searching for a boot media (ISO), then user can ssh into that and run #setup-alpine? Because I am going to do that and wonder if it was considered before.
2018-02-28 17:21:57 <tmh1999> probably for some installation where direct user's input is prohibited/limited.
2018-02-28 17:54:19 <kaniini> bernhardgruen: there is already an open policy
2018-02-28 17:54:38 <kaniini> by default, most maintainers use libressl because they don't want to pull in openssl
2018-02-28 20:08:58 <AWilcox[m]> I don't know the exact process for moving packages from testing to community, but Adélie would greatly appreciate these being moved: https://bpaste.net/raw/5599f4e88670
2018-02-28 20:12:36 <mksully222> ncopa can you please restart the ppc64le builders
2018-02-28 20:42:08 <kaniini> mksully222: ask in #alpine-infra
2018-02-28 20:42:20 <kaniini> leitao should be able to start the ppc64le builder too
2018-02-28 20:52:15 <HRio> kaniini: https://github.com/alpinelinux/aports/pull/3026#issuecomment-368656010 can not see the original series before flattening, but are we sure all hunks in musl-support.patch are unneded?
2018-02-28 20:52:55 <HRio> if not I have rebased musl-support.patch to 4.10 and can push it
2018-02-28 20:57:45 <mepholic> AWilcox[m]: contact the maintainer of each package
2018-02-28 20:59:39 <kaniini> i can move them
2018-02-28 21:00:23 <HRio> AWilcox[m]: regardning texlive https://github.com/alpinelinux/aports/pull/3004
2018-02-28 21:00:43 <clandmeter> kaniini: did you testbuild firefox-esr?
2018-02-28 21:01:17 <clandmeter> looks like its blocking the builder
2018-02-28 21:01:32 <kaniini> probably because of gconf3 transition
2018-02-28 21:04:22 <kaniini> let me check on what we can do there
2018-02-28 21:06:26 <AWilcox[m]> Ah okay thanks HRio.
2018-02-28 21:08:24 <kaniini> checking MOZ_GCONF_CFLAGS... Package ORBit-2.0 was not found in the pkg-config search path.
2018-02-28 21:08:27 <kaniini> i see
2018-02-28 21:08:51 <kaniini> an unannounced transition broke it
2018-02-28 21:09:22 <kaniini> i think we need to generate better pc: dependencies in abuild to prevent this in future
2018-02-28 21:09:42 <kaniini> --print-depends in pkgconf can be used in combination with scanning the .pc files
2018-02-28 21:09:56 <kaniini> we need fix gconf package to pull in orbit2-dev package
2018-02-28 21:10:47 <AWilcox[m]> So I guess https://github.com/alpinelinux/aports/pull/3434 was somewhat accurate then
2018-02-28 21:11:44 <AWilcox[m]> But I think yes, orbit2-dev in depends_dev
2018-02-28 21:12:49 <kaniini> i fixed it
2018-02-28 21:12:57 <kaniini> but the pc: dependency topology needs to be better
2018-02-28 21:19:10 <HRio> bump https://github.com/alpinelinux/aports/pull/3052? (tagged: A-move + A-fix)
2018-02-28 21:39:27 <PureTryOut[m]> A. Wilcox: it was sort-of accurate yes