2019-06-01 01:05:17 <awilfox> this has been a long, twisty road - but I think I may see why apk's solver is failing to do the right thing
2019-06-01 01:05:55 <awilfox> we've just released Adélie 1.0-BETA3, and due to that, we have lots of people upgrading their computers... we've had at least three cases so far today where there's been the same error
2019-06-01 01:06:21 <awilfox>   harfbuzz-icu-1.8.8-r1:
2019-06-01 01:06:21 <awilfox>     breaks: harfbuzz-dev-2.4.0-r0[harfbuzz-icu=2.4.0-r0]
2019-06-01 01:06:21 <awilfox>     breaks: pcre-dev-8.43-r0[libpcrecpp=8.43-r0]
2019-06-01 01:06:21 <awilfox>   libpcrecpp-8.42-r1:
2019-06-01 01:06:54 <awilfox> this includes our primary web server, which has just adelie-base apache and qt5-qtbase-dev installed.  we figured it was probably a -dev package, but it's nice that it was so easily reproducable :)
2019-06-01 01:07:11 <awilfox> so, I enabled DEBUG_PRINT and tried again.  I got this 1.33 MB log file: https://www.adelielinux.org/apk-error.log
2019-06-01 01:07:41 <awilfox> in the middle you find this chunk: https://bpaste.net/raw/917e3812e513
2019-06-01 01:08:07 <awilfox> this seems to be a small issue in the solver: https://git.alpinelinux.org/apk-tools/tree/src/solver.c#n514
2019-06-01 01:08:21 <awilfox> it "Prefer[s] existing package[s]", even during a system upgrade
2019-06-01 01:08:38 <awilfox> anything in world is considered for upgrade, but *dependencies* of world are only considered for upgrade if the existing package versions are no longer present/available
2019-06-01 01:09:30 <awilfox> I'm aware that the Alpine policy is to run the equivalent of cleanoldpkg on every build, but it isn't our policy at Adélie - once a package is published to our mirrors, it is never removed for any reason other than if there is a license error
2019-06-01 01:09:54 <awilfox> so it would appear that's the issue.  I should probably be writing all this to the ML instead, actually.  sorry.
2019-06-01 01:10:10 <SpaceToast> awilfox: I'd also open a bug on bugs.a.o and link to it in the ML post
2019-06-01 01:10:12 <awilfox> my opinion is that there should perhaps be another flag to upgrade, -d for deep, which will upgrade *every* package, not just world
2019-06-01 01:10:19 <SpaceToast> still, great job on figuring that out :)
2019-06-01 01:10:48 <awilfox> SpaceToast: yeah, I will do that too
2019-06-01 01:10:49 <awilfox> thanks :)
2019-06-01 01:10:52 <SpaceToast> I'm personally biased towards rolling releases, so I would prefer always selecting the latest package, but ultimately, the apk dev(s?) will need to make the call
2019-06-01 01:11:06 <awilfox> well adding option makes it so users can decide
2019-06-01 01:11:15 <SpaceToast> well I mean for the defaults
2019-06-01 01:11:32 <SpaceToast> since alpine's policy is to always cleanoldpkg, it shouldn't have an effect on us, and you guys seem to prefer all-latest
2019-06-01 01:11:35 <awilfox> perhaps it can be introduced as an option --deep or --no-deep, then --deep becomes default after a release cycle, or something
2019-06-01 01:11:40 <mps> last time when I upgrade from armhf to armv7 'apk upgrade -a -l' worked fine
2019-06-01 01:11:44 <awilfox> it will be up to apk devs you are right
2019-06-01 01:11:53 <SpaceToast> what I'd like to avoid is a `apt-get --dist-upgrade` situation
2019-06-01 01:11:54 <jwh> I was going to say, flags already exist that should solve it
2019-06-01 01:12:08 <awilfox> this is output of apk upgrade -al
2019-06-01 01:12:50 <mps> hmm, in my case it worked, only skipped pinned packages
2019-06-01 01:13:49 <mps> also '-U' can help
2019-06-01 01:14:39 <SpaceToast> mps: was this on alpine?
2019-06-01 01:14:46 <SpaceToast> Because there's a marked difference that was mentioned
2019-06-01 01:14:58 <mps> awilfox: I don't want to tell that you are wrong, just what I had
2019-06-01 01:15:23 <jwh> SpaceToast: adelie
2019-06-01 01:15:26 <mps> SpaceToast: yes, on alpine
2019-06-01 01:15:32 <jwh> o
2019-06-01 01:15:36 <SpaceToast> jwh: mind who I was asking ;)
2019-06-01 01:15:37 <jwh> missed the nick
2019-06-01 01:15:52 <jwh> I'm really struggling without my proper irssi config
2019-06-01 01:16:02 <jwh> also I have weird terminal corruption (on alpine)
2019-06-01 01:16:05 <SpaceToast> Try weechat :D
2019-06-01 01:16:18 <jwh> sometimes it doesn't render all of the text until I refresh
2019-06-01 01:16:28 <awilfox> make sure you have ncurses-terminfo installed
2019-06-01 01:16:39 <jwh> ah good shout actually
2019-06-01 01:17:09 <jwh> yeah is installed, I think thats a dep anyway
2019-06-01 01:17:17 <jwh> probably broken $LANG
2019-06-01 01:18:03 <awilfox> ahh
2019-06-01 01:18:29 <SpaceToast> Only C.UTF-8 was *really* supported, last I checked
2019-06-01 01:18:32 <SpaceToast> By musl, that is
2019-06-01 01:18:58 <jwh> *cough* UTF-8 as default pls
2019-06-01 01:19:21 <mps> yes, only C.UTF-8, but I don't have big issues if I set some other
2019-06-01 01:19:25 <awilfox> it is, but you may need to export LANG and/or LC_ALL
2019-06-01 01:19:35 <awilfox> irssi may not realise it can do utf-8
2019-06-01 01:19:40 <jwh> yeah
2019-06-01 01:19:41 <awilfox> also, I think irssi has a specific setting for unicode output
2019-06-01 01:19:54 <awilfox> but it's been... 8 years since I touched it, so it might be enabled by default by now
2019-06-01 01:19:55 <jwh> there used to be a force term option but it looks like thats gone in recent versions
2019-06-01 01:20:16 <jwh> meh it can wait, faff to rejoin everywhere
2019-06-01 01:21:07 <mps> in my irssi setup 'term_charset = "UTF-8";' is enough
2019-06-01 01:21:35 <jwh> yeah I expected it would be
2019-06-01 01:21:39 <jwh> it could be screen of course
2019-06-01 01:21:55 <SpaceToast> Geez you're on the old stack, huh?
2019-06-01 01:22:01 <jwh> if it ain't broke etc
2019-06-01 01:22:06 <mps> jwh: tmux?
2019-06-01 01:22:12 <SpaceToast> I thoroughly disagree with that philosophy
2019-06-01 01:22:19 <jwh> 
ACTION hammers the downvote button

2019-06-01 01:22:29 <SpaceToast> Not fixing what isn't broken isn't how we arrived to where we are now ;)
2019-06-01 01:22:50 <jwh> when it comes to things that need to just work like my terminal/irc client, that stays :P
2019-06-01 01:22:51 <TBB> and are we happy with where we are now?...
2019-06-01 01:22:57 <jwh> no, tmux sucks
2019-06-01 01:26:58 <awilfox> tmux and screen both have pluses and minuses
2019-06-01 01:29:07 <mps> yes, I use both for appropriate use cases. nothing is perfect
2019-06-01 01:37:55 <north1> #10504 can be set to resolved
2019-06-01 01:41:42 <danieli> north1: +1, done
2019-06-01 01:43:06 <danieli> the author had "closes <full issue url>" instead of "closes #<issue id>"
2019-06-01 02:29:53 <awilfox> I've just authored a small patch to add a --deep option to the upgrade applet, and confirm it does fix the issue
2019-06-01 02:30:29 <awilfox> https://www.adelielinux.org/deep.diff is the difference of the original apk-error.log vs apk-error2.log which is with my patch applied
2019-06-01 02:32:36 <awilfox> https://code.foxkit.us/adelie/apk-tools/commit/e61635ada7901763919caeaa01fa62ead3f6e97f
2019-06-01 02:32:54 <awilfox> I suppose I will mail this patch to alpine-devel@ with discussion, and we can see if it is suitable for apk-tools
2019-06-01 04:38:04 <awilfox> https://bpaste.net/raw/767bed130622 it works :)
2019-06-01 08:25:44 <kpcyrd> was there a change in the "no rust" policy? I noticed there are some rust packages now
2019-06-01 09:23:52 <tcely> kpcyrd: rust is available for x86_64 only currently. there is work to expand to other architectures in progress.
2019-06-01 09:28:15 <Cogitri> Why would that be a policy?
2019-06-01 09:31:33 <mps> kpcyrd: it is not policy, rust doesn't work on all arch's, yet
2019-06-01 09:32:00 <eu> what about cargo vs unbundling deps?
2019-06-01 09:34:01 <mps> yes, these new languages bundling starting to irritate me :)
2019-06-01 09:35:03 <tcely> eu: please explain what you are asking about
2019-06-01 09:36:19 <eu> is rust/go allowed to use cargo/go get to fetch dependencies over the network during build vs creating actual apkbuilds for each dep?
2019-06-01 09:36:48 <eu> arch vs debian way of doing things
2019-06-01 09:37:56 <mps> eu: in my memory, yes, download is allowed
2019-06-01 09:38:19 <Cogitri> Well, I think at least Fedora does shared linking now with cargo
2019-06-01 09:38:46 <Cogitri> Yup
2019-06-01 09:39:06 <Cogitri> Making APKBUILDs for ~250 deps for each crate sounds super annoying
2019-06-01 09:39:26 <Cogitri> And due to Cargo being super easy to use Rust devs don't really have API compatibility at heart
2019-06-01 09:39:58 <eu> it's also a pain to package 100s of py/perl deps, but we do it
2019-06-01 09:40:12 <mps> Cogitri: webkit2gtk PR didn't pass on armv7, stuck for few hours. I killed it before go to bed
2019-06-01 09:40:15 <eu> is npm bundling also allowed then?
2019-06-01 09:40:23 <Cogitri> First, let's get LLVM8 and Rust on all arches, then we can try and mess around with shared linking for Rust.
2019-06-01 09:40:32 <Cogitri> <mps "cogitri: webkit2gtk PR didn't pa"> Aw, dang. Thanks for testing though
2019-06-01 09:41:22 <mps> np, when you have new version just tell me, I will do again
2019-06-01 09:41:32 <Cogitri> <eu "it's also a pain to package 100s"> Well, I guess I can work on extending tmplgen (a small tool to generate ruby gems/Rust crates/metacpan packages and reverse deps) to Alpine then
2019-06-01 09:41:49 <Cogitri> But we'll have to do _a lot_ of versioned packages then
2019-06-01 09:42:48 <eu> I'm just saying that go/rust/npm makes packaging a mess
2019-06-01 09:42:49 <mps> a lot of versioned deps is sign of bad design, imo
2019-06-01 09:43:03 <tcely> eu: for rust we tend to use Cargo.lock to not download randome versions during build process. For go, I think go mod now operates similarly and projects vendor the things they use.
2019-06-01 09:43:15 <eu> some project even dep on HEAD, good luck with reproducible builds
2019-06-01 09:43:34 <Cogitri> eu: No, Cargo.lock takes care of that
2019-06-01 09:43:43 <eu> not for go
2019-06-01 09:43:53 <eu> at least not all cases
2019-06-01 09:43:59 <Cogitri> Go modules are versioned too
2019-06-01 09:44:10 <eu> can be versioned
2019-06-01 09:44:42 <Cogitri> <mps "a lot of versioned deps is sign "> Well, it's just a design that doesn't fit well with what we do. Rust's design is great for development, but not so great for distro packaging, unless you slam everything into one big binary
2019-06-01 09:45:49 <tcely> Does npm offer a way to freeze dependencies without stuffing all the modules into the source?
2019-06-01 09:46:40 <mps> Cogitri: it is not only rust, most modern popular lang love bundles
2019-06-01 09:47:05 <Cogitri> Because it's super nice for development
2019-06-01 09:47:34 <Cogitri> Compared to Cargo C(++)'s way of installing deps seems a bit like the "dark ages"
2019-06-01 09:47:51 <mps> I'm not sure it is super nice
2019-06-01 09:47:56 <alyx> C's dep handling is "nonexistent" :P
2019-06-01 09:49:21 <mps> I followed go lang ML few years, and remember how much harsh words are written there about that subject
2019-06-01 09:49:54 <Cogitri> Well, because there are so many different ways of managing deps
2019-06-01 09:50:29 <Cogitri> I don't really follow Go, but they had a per-se standard (dep) but the Go core devs just killed it with their own approach (Go modules) AFAIU
2019-06-01 09:50:52 <Cogitri> alyx: Yes, that's the problem :P
2019-06-01 09:52:41 <alyx> you mean you don't like writing a configure.ac script the size of a postdoc thesis to see if you can figure out if ncurses exists?
2019-06-01 09:52:46 <mps> eu: at the end, I prefer debian way
2019-06-01 09:52:51 <alyx> weird, it's my favorite hobby
2019-06-01 09:53:32 <mps> for distro's, I mean
2019-06-01 09:53:54 <tcely> Cogitri: https://blog.golang.org/using-go-modules I'm not missing go dep at all.
2019-06-01 09:54:25 <Cogitri> alyx: lol
2019-06-01 09:54:40 <Cogitri> It has gotten a lot better with stuff like meson, but it's still a pain in the neck
2019-06-01 09:56:48 <mps> cristal shards looks (well) 'acceptable'
2019-06-01 09:58:17 <alyx> it definitely makes one realize that, for all their faults, these modern "use our package management suite" languages have some very nice ease-of-use benefits
2019-06-01 09:59:05 <eu> but awful for security from a distro pow
2019-06-01 09:59:07 <mps> alyx: perl have cpan bundles for years
2019-06-01 09:59:42 <TBB> distro packaging the traiditonal way is coming to its end
2019-06-01 09:59:47 <eu> if rust becomes popular and lots of projects share deps with CVEs it will be a royal pain to manage
2019-06-01 09:59:55 <mps> bundles are not new thingie
2019-06-01 10:00:29 <eu> TBB: we should just statically link all c/c++ code also then by that logic
2019-06-01 10:02:45 <alyx> yeah, CPAN's been around since roughly the same time as man discovered the wheel
2019-06-01 10:02:52 <tcely> eu: I fail to see how packaging individual modules / crates makes updating for security issues less painful.
2019-06-01 10:04:07 <clandmeter> We are working towards reproducible builds
2019-06-01 10:04:21 <clandmeter> It's not so easy to implement
2019-06-01 10:05:34 <PureTryOut[m]> pr8256 has been approved by the maintainer, could it be merged?
2019-06-01 10:06:48 <TBB> eu: not that I was trying to make a statement towards that end, it just seems that there's a limited amount of packagers to share between distros, and at the same time some new software is getting increasingly complex to package
2019-06-01 10:06:57 <eu> tcely: if rust had a stable abi one could dynlink to the crates, and just bump openrustssl in stead of going through all rust projects, download their source, examine the toml file for existence of an outdated openrustssl
2019-06-01 10:08:13 <tcely> eu: Heh. When is the last time upgrading just the openssl shared objects was enough even with C programs?
2019-06-01 10:10:52 <mps> tcely: I can't remember for alpine, but for debian it is normal to just upgrade openssl in case of security flaw
2019-06-01 10:12:48 <PureTryOut[m]> tcely: that " on a new line, is that a standard or something? I dislike it with a passion lol
2019-06-01 10:13:23 <Cogitri> It does make for prettier diffs
2019-06-01 10:13:47 <PureTryOut[m]> but it looks so ugly 😭
2019-06-01 10:14:01 <PureTryOut[m]> Well, I've changed it anyway
2019-06-01 10:16:19 <tcely> PureTryOut[m]: thanks.
2019-06-01 10:17:16 <tcely> TravisCI is so slow compared to Drone I'm spoiled now for waiting on CI builds.
2019-06-01 10:19:34 <tcely> PureTryOut[m]: Since the makedepends list appears to be sorted, I would have changed to: makedepends=" then put your new dependency on the next line
2019-06-01 10:19:52 <eu> tcely: updating the shlib and restarting any long lived processes is enough
2019-06-01 10:20:14 <eu> add needrestart and it's handleed automatically
2019-06-01 10:20:26 <tcely> eu: sometimes that is enough
2019-06-01 10:20:45 <eu> tcely: when is it not?
2019-06-01 10:20:57 <tcely> any time the versions change is a prime example
2019-06-01 10:21:12 <tcely> backporting is popular to make that work
2019-06-01 10:21:48 <PureTryOut[m]> tcely: changed it
2019-06-01 10:23:08 <tcely> PureTryOut[m]: great! no my brain doesn't scream "unsorted!" when looking at that list. ;-)
2019-06-01 10:23:17 <tcely> s/no/now/
2019-06-01 10:23:17 <alpine-meetbot> tcely meant to say: PureTryOut[m]: great! now my brain doesn't scream "unsorted!" when looking at that list. ;-)
2019-06-01 10:23:19 <PureTryOut[m]> Lol
2019-06-01 10:24:45 <eu> tcely: so, you rebuild all revdeps. The way to find those is codified in the pkg metadata. When bundling you're relying on upstream to update their package data and issuing a new release
2019-06-01 10:26:10 <eu> or patch upstream releases with updated Cargo.toml
2019-06-01 10:26:58 <tcely> eu: relying on upstream to fix their stuff and release doesn't seem like a horrible thing to me. I'm much more against every downstream having to patch for the fix individually
2019-06-01 10:27:39 <eu> tcely: depending on upstream they could be very slow to react
2019-06-01 10:28:07 <Cogitri> I do tend to agree that there has to at least be an easier way to patch stuff with Cargo
2019-06-01 10:28:35 <eu> but since we're talking about the oh so great rust which can never have sec issues...
2019-06-01 10:28:42 <tcely> Cogitri: the way to patch with cargo seems fairly flexible if I am remembering correctly
2019-06-01 10:29:46 <tcely> https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#overriding-dependencies
2019-06-01 10:30:17 <Cogitri> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/v1/download/matrix.org/BYDUFCkcQiUWIjGKIOLPCvmB >

2019-06-01 10:30:37 <eu> still need a way to get at the Cargo.toml from the distro
2019-06-01 10:31:13 <Cogitri> `sed`?
2019-06-01 10:31:15 <eu> so that you don't to download every rust projects source
2019-06-01 10:33:38 <tcely> as I understand it the top level Cargo.toml is all you need to change
2019-06-01 10:33:55 <tcely> We have solutions for that kind of thing already.
2019-06-01 10:36:04 <eu> tcely: still, you need an efficient way of finding all rust packages which have a crate with a known sec vulnerability in the abuild tree
2019-06-01 10:37:28 <tcely> Well, if we have Cargo.lock in $startdir then git grep would do it.
2019-06-01 10:38:38 <eu> "efficient" and downloading sources for all packages does not compute fore me
2019-06-01 10:38:42 <eu> s/fore/for/
2019-06-01 10:38:42 <alpine-meetbot> eu meant to say: "efficient" and downloading sources for all packages does not compute for me
2019-06-01 10:42:23 <eu> I also see that apart from testing/, only firefox-esr is using cargo. And it's vendoring all needed crates afaik
2019-06-01 10:57:34 <Cogitri> Most other crates that are meant for distribution to do (like fractal&gxi)
2019-06-01 10:58:00 <Cogitri> BTW, has there been a discussion about the usr merge for Alpine already? I can't seem to find anything
2019-06-01 11:00:05 <_ikke_> Not sure what you are referring to, but getting 3.10 out has the current priority
2019-06-01 11:00:57 <Cogitri> https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ just asking because a few broken configure scripts have been annoying me with this
2019-06-01 11:01:15 <Cogitri> But yeah, it's nothing that has to be discussed right now, I'm just curious :)
2019-06-01 11:04:36 <p4Wv1qn095FW> none of these arguments make any sense: https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/#compatibility:thegistofit
2019-06-01 11:08:12 <_ikke_> Is there a practical reason to keep them separate?
2019-06-01 11:08:38 <p4Wv1qn095FW> seperate root partitions?
2019-06-01 11:08:54 <p4Wv1qn095FW> s/ions/ion/
2019-06-01 11:08:54 <alpine-meetbot> p4Wv1qn095FW meant to say: seperate root partition?
2019-06-01 11:11:04 <p4Wv1qn095FW> the document says "compatibility" from my experience there is a lot of disks out there that have seperate partitions for / /usr /var /home /boot
2019-06-01 11:13:07 <p4Wv1qn095FW> such a change might mean the need to repartition hosts, no?
2019-06-01 11:14:47 <eu> if initramfs can mount /usr, no need to repartition
2019-06-01 11:15:30 <p4Wv1qn095FW> true
2019-06-01 11:15:47 <_ikke_> Archlinux already has this for quite a long time
2019-06-01 11:16:09 <_ikke_> but they event went further
2019-06-01 11:18:28 <eu> I recently patched a package with #!/usr/bin/sh
2019-06-01 11:19:00 <eu> one could argue that usrmerge has made it easier for stupid people to do stupid things
2019-06-01 11:22:12 <mps> eu: :D
2019-06-01 11:24:04 <north1> _ikke_: Void Linux also goes all the way
2019-06-01 11:25:21 <mps> I don't think that the usrmerge is worth anything
2019-06-01 11:28:46 <p4Wv1qn095FW> the arguments in the link seem bullshit to me. who cares what oracle does? seriously? and setting the PATH=/bin:/usr/bin is also unheard of?
2019-06-01 11:31:50 <Cogitri> Compatibility does seem like a valid argument to me, some stuff just assumes that /usr/bin/sh is a thing
2019-06-01 11:32:20 <Cogitri> Patching that isn't terribly difficult, but I'm not exactly sure what the advantages of _not_ usrmerging are
2019-06-01 11:32:22 <p4Wv1qn095FW> yeah but the url reverses that logic, they argue the merge is for compat, while actually it is against.
2019-06-01 11:34:04 <p4Wv1qn095FW> but maybe the whole split is anachronistic and makes little sense today. but the arguments listed in that page are bullshit. and sound like eastern european dictatorships reasonings why they gut democracy, by pointing at other eastern european democracies having done that before and this being the new standard which they also have to follow.
2019-06-01 11:34:34 <p4Wv1qn095FW> like the polish copying orban viktors stuff
2019-06-01 11:37:01 <mps> p4Wv1qn095FW: please, without politics
2019-06-01 11:38:14 <_ikke_> p4Wv1qn095FW: so you're necessarily against their idea, just the arguments they used
2019-06-01 11:44:04 <p4Wv1qn095FW> well, i can see how this is a simplification, and thus good.
2019-06-01 11:44:13 <mps> _ikke_: disruptive change
2019-06-01 11:44:53 <_ikke_> mps: I didn't find it disruptive in Archlinux when it happened
2019-06-01 11:45:11 <Cogitri> At least on Exherbo and Gentoo it went pretty smoothly too
2019-06-01 11:45:14 <p4Wv1qn095FW> but i also remember back in the days being glad to have all tools necessary to recover my system on a read-only mounted root partition, while all the other crap like texlive, qt[45] etc is on a separate partion still not mounted because of problems.
2019-06-01 11:45:19 <_ikke_> I just upgraded my system and went on with my life
2019-06-01 11:45:29 <Cogitri> And backwards compatibility is just fine
2019-06-01 11:46:07 <p4Wv1qn095FW> but i realize not even alpine does that all tools for recovery on read-only root.
2019-06-01 11:46:12 <mps> I follow debian-devel for some years discussion about  usrmerge and after few years (can't remember exact number) it looks it is still long ahead
2019-06-01 11:46:39 <p4Wv1qn095FW> but i also realize an alpine boot stick can recover my stuff.
2019-06-01 11:47:36 <p4Wv1qn095FW> as long as i'm physically present, for remote recoveries the recovery tools on ro / are still a good thing
2019-06-01 11:51:31 <north1> Need someone to look at pr8349 to fix pytest
2019-06-01 11:55:43 <hjaekel> great, I was already wondering why I had to explicitly give wcwidth as a dependency when I want to use pytest
2019-06-01 13:55:08 <tcely> is yelp-tools missing a shell or something?
2019-06-01 13:57:53 <mps> north1: you are too fast :) I worked on cleaning sigrok-cli and now see that you already done it
2019-06-01 14:00:22 <north1> mps: the changes are trivial to catch with apkbuild-lint
2019-06-01 14:01:02 <tcely> ok. I called that one. #!/usr/bin/sh
2019-06-01 14:01:04 <mps> I see, nice work
2019-06-01 14:01:41 <_ikke_> (apkbuild-lint is available in aports as atools)
2019-06-01 14:03:07 <mps> what does aports-lint
2019-06-01 14:03:37 <north1> mps: checks an apkbuild for violations relating to sports as a whole
2019-06-01 14:03:54 <north1> Things like defining dependencies twice, depending on an upper repo
2019-06-01 14:04:24 <north1> Having a dirname that does not match the pkgname
2019-06-01 14:04:30 <mps> how to invoke it
2019-06-01 14:05:54 <north1> See aports-lint.1
2019-06-01 14:06:05 <mps> find -name APKBUILD | xargs aports-lint
2019-06-01 14:06:07 <north1> alint.5 shows all the violations
2019-06-01 14:07:44 <PureTryOut[m]> When someone has time, I'd like pr8328 to be reviewed and pr8256 to be merged
2019-06-01 14:41:23 <_ikke_> PureTryOut[m]: I've been following wlroots
2019-06-01 14:45:21 <PureTryOut[m]> Ah, and?
2019-06-01 14:46:04 <_ikke_> will apply it soon
2019-06-01 14:46:10 <PureTryOut[m]> Cool thanks
2019-06-01 14:46:13 <kpcyrd> tcely, Cogitri, mps: I submitted rust packages last year and it got reverted since it wasn't clear yet how alpine was going to handle rust. If that changed I would resubmit them now
2019-06-01 14:47:00 <tcely> kpcyrd: please do.
2019-06-01 14:47:15 <mps> kpcyrd: for all arch's or x86_64 only
2019-06-01 14:48:17 <_ikke_> rust is currently only available for x86_64...
2019-06-01 14:49:16 <tcely> pr8359
2019-06-01 14:49:19 <mps> _ikke_: I know, I'm asking kpcyrd if his patch is for other arch's
2019-06-01 14:50:31 <kpcyrd> I would submit it as x86_64 only until more archs are available
2019-06-01 14:51:22 <mps> tcely: applied
2019-06-01 14:51:28 <tcely> mps: thanks
2019-06-01 14:51:39 <mps> tcely: yaw
2019-06-01 14:52:24 <_ikke_> Can someone check https://tpaste.us/yPJn ?
2019-06-01 14:52:28 <mps> kpcyrd: rust for x86_64 is in alpine
2019-06-01 14:52:31 <_ikke_> font-bakoma-ttf now depends on itself
2019-06-01 14:52:35 <_ikke_> want to apply this as fix
2019-06-01 14:53:50 <mps> _ikke_: looks fine
2019-06-01 14:54:03 <tcely> _ikke_: it changes font-bakoma depends
2019-06-01 14:54:17 <_ikke_> yes
2019-06-01 14:55:06 <mps> and added depend="fontconfig", which is right thing, ime
2019-06-01 14:55:14 <tcely> ah, I see you pushed that further down the resolved chain
2019-06-01 14:55:15 <tcely> ok
2019-06-01 14:56:03 <_ikke_> I could've made another variable holding subpackage deps, but with just one dep I thought this was easier
2019-06-01 14:56:42 <_ikke_> pushed
2019-06-01 14:56:44 <_ikke_> thanks
2019-06-01 14:58:55 <tcely> Cogitri: what does "Uh?" mean?
2019-06-01 14:59:02 <tcely> pr 8351
2019-06-01 15:00:15 <tcely> Is prspkt ever on IRC ?
2019-06-01 15:00:17 <Cogitri> I was unsure what you tried to tell me with your review comment
2019-06-01 15:00:35 <tcely> The one about the commit message?
2019-06-01 15:01:02 <tcely> dir: new aport < has message body with url and description in it according to the wiki template
2019-06-01 15:01:05 <Cogitri> Yup. Now that you've added the link I understand it though
2019-06-01 15:01:17 <Cogitri> Thanks for the pointer
2019-06-01 15:01:21 <tcely> yaw
2019-06-01 15:03:03 <_ikke_> tcely: I've not seen prspkt here
2019-06-01 15:03:44 <tcely> I've seen a couple commits from that person that I want to ask about.
2019-06-01 15:04:10 <tcely> I didn't see PW or PR for yelp-tools and the breakage should really have been caught by CI.
2019-06-01 15:04:49 <mps> PureTryOut[m]: you have experience with wayland experience, there are two patch on pw.a.o I'm looking to apply. https://patchwork.alpinelinux.org/patch/4878/ and https://patchwork.alpinelinux.org/patch/4879/
2019-06-01 15:05:27 <mps> what do you think, are they ok
2019-06-01 15:05:45 <PureTryOut[m]> Well, you can remove some `cd`'s first of all 😛
2019-06-01 15:05:58 <PureTryOut[m]> I didn't know that tool, it seems handy
2019-06-01 15:06:21 <mps> heh, yes, but after commit
2019-06-01 15:06:34 <PureTryOut[m]> Licenses should be GPL-3.0-or-later
2019-06-01 15:06:43 <mps> ok, I will check them
2019-06-01 15:07:49 <PureTryOut[m]> `$builddir` can be removed if it's the same value as the default. Otherwise it seems alright, but you only know when testing it
2019-06-01 15:08:49 <mps> PureTryOut[m]: yes, I know. And north1 is fast to fix that :)
2019-06-01 15:10:52 <north1> i'm back
2019-06-01 15:10:59 <PureTryOut[m]> Wb
2019-06-01 15:14:58 <mps> PureTryOut[m]: how you know that license for these pkgs should be GPL-3.0-or-later and not GPL-3.0-only? I don't want to say that you are wrong just want to be sure
2019-06-01 15:15:27 <_ikke_> mps: the header on the source files will tell it
2019-06-01 15:15:45 <PureTryOut[m]> https://github.com/brunelli/wl-clipboard-x11/blob/master/COPYING#L640
2019-06-01 15:15:57 <PureTryOut[m]> https://github.com/brunelli/wl-clipboard-x11/blob/master/src/wl-clipboard-x11#L7
2019-06-01 15:16:28 <PureTryOut[m]> https://github.com/bugaevc/wl-clipboard/blob/master/COPYING#L640
2019-06-01 15:16:39 <PureTryOut[m]> https://github.com/bugaevc/wl-clipboard/blob/master/src/boilerplate.c#L8
2019-06-01 15:16:54 <mps> PureTryOut[m]: I looked license there but was not sure. thanks
2019-06-01 15:17:40 <Cogitri> Yeah, the license doesn't tell you that
2019-06-01 15:17:59 <Cogitri> Grep'ing the source for `or at your option` usually does
2019-06-01 15:18:12 <Cogitri> (or using something like `licensechecker`, but it's pretty slow in my experience)
2019-06-01 15:18:31 <PureTryOut[m]> Yeah I search for "at your option"
2019-06-01 15:20:08 <north1> cogitri: licensechecker is annoying when dealing with lots of files
2019-06-01 15:20:29 <north1> i use it only to check licenses that look like MIT or BSD-[1234]-Clause that look kinda off
2019-06-01 15:20:47 <north1> more often than not it is some weird variant
2019-06-01 15:21:17 <north1> licensechecker also likes to call any license that begins with copyright as Sleepcat
2019-06-01 15:21:18 <north1> Sleepycat*
2019-06-01 15:35:53 <north1> can we get pr8349 in ? fixes pytest usage
2019-06-01 15:47:47 <PureTryOut[m]> mps: this line could've been removed https://github.com/alpinelinux/aports/commit/99eccb233f256283213194b15945bd09729b4d3b#diff-d104826627ede692729bdfb2512f6943R14
2019-06-01 15:48:29 <north1> pr8636
2019-06-01 15:48:36 <north1> pr8363 oops
2019-06-01 15:49:19 <PureTryOut[m]> Ah good 👍️
2019-06-01 15:53:52 <tcely> pr8365 should correct greenbone-security-assistant build failure
2019-06-01 15:54:13 <tcely> now we just need someone with main access to push it
2019-06-01 15:55:12 <mps> PureTryOut[m]: I told you, we do not need to worry about such thing, north1 will do all that :)
2019-06-01 15:55:33 <PureTryOut[m]> Ah sorry misunderstood lol
2019-06-01 15:56:09 <mps> tcely: yes, I told ncopa yesterday about fix hiredis build but he probably forgot it
2019-06-01 15:56:42 <PureTryOut[m]> I hope pr8328 can be merged soon, I have quite a lot of stuff depending on it lol
2019-06-01 16:17:50 <kpcyrd> is `install -Dm644 "$startdir/$pkgname.conf" "$pkgdir/etc/$pkgname.conf"` a good way to install a config file that is part of the aports repo?
2019-06-01 16:18:14 <kpcyrd> couldn't find that many references to $startdir in the aports repo
2019-06-01 16:19:48 <PureTryOut[m]> not `$srcdir`?
2019-06-01 16:20:24 <kpcyrd> $srcdir is $startdir/src, right?
2019-06-01 16:21:40 <SpaceToast> kpcyrd: srcdir can be overriden
2019-06-01 16:21:51 <SpaceToast> if you have something in the same directory as the APKBUILD that should go into the package
2019-06-01 16:21:54 <SpaceToast> add it to sources
2019-06-01 16:21:56 <SpaceToast> and it'll be in srcdir
2019-06-01 16:23:51 <kpcyrd> ah, found a similar package and they prefix everything with "$builddir/" instead of `cd "$builddir"`, so that explains why they don't need $startdir
2019-06-01 16:24:08 <SpaceToast> you don't need $startdir at all
2019-06-01 16:24:15 <SpaceToast> $startdir is effectively an internal thing
2019-06-01 16:24:18 <SpaceToast> you shouldn't be using it
2019-06-01 16:26:14 <kpcyrd> oh, adding it to $source makes sense
2019-06-01 17:42:14 <_ikke_> PureTryOut[m]: tier 3 pushed :-)
2019-06-01 17:42:23 <PureTryOut[m]> Oh awesome thanks!
2019-06-01 17:50:06 <_ikke_> PureTryOut[m]: kwallet test is failing on s390x: https://build.alpinelinux.org/buildlogs/build-edge-s390x/testing/kwallet/kwallet-5.58.0-r0.log
2019-06-01 17:50:30 <PureTryOut[m]> Of course it is
2019-06-01 17:50:37 <_ikke_> heh
2019-06-01 17:51:05 <PureTryOut[m]> I'd skip it for now just on that arch. I'll be reporting all those test failures to upstream
2019-06-01 17:51:10 <_ikke_> ok
2019-06-01 17:53:17 <mps> uh, I posted ifupdown upgrade patch but forgot to mention in annotation that it should be reviewed before applying because there are some important changes
2019-06-01 17:53:26 <mps> patch is here https://patchwork.alpinelinux.org/patch/4898/
2019-06-01 17:55:26 <mps> PureTryOut[m]: is it possible to use pmOS bootloader but install Alpine instead of pmOS repo
2019-06-01 17:56:31 <PureTryOut[m]> We don't use any special bootloader really, although it depends on the device
2019-06-01 17:57:20 <mps> hmm, pmbootstrap is installer only?
2019-06-01 17:57:38 <PureTryOut[m]> But the point of pmOS is to run Alpine on mobile, just with extra packaged required for mobile functionality. Why would you not want our repo on a phone?
2019-06-01 17:57:53 <PureTryOut[m]> No we're Alpine Linux + repo on top with an installer
2019-06-01 17:58:33 <mps> I would like to have minimal installation, text console only
2019-06-01 17:58:52 <PureTryOut[m]> You can do that, choose UI none in the installer
2019-06-01 17:59:07 <mps> nice
2019-06-01 17:59:20 <mps> didn't know that
2019-06-01 18:07:25 <_ikke_> PureTryOut[m]: http://tpaste.us/5wd9
2019-06-01 18:07:43 <PureTryOut[m]> Seems good!
2019-06-01 18:07:59 <_ikke_> pushed
2019-06-01 18:08:08 <PureTryOut[m]> 👍️
2019-06-01 18:09:58 <_ikke_> ppc64le finished first
2019-06-01 18:10:13 <_ikke_> x86 second :P
2019-06-01 18:10:36 <PureTryOut[m]> ppc64le first? That's a first (pun intended)
2019-06-01 18:10:52 <PureTryOut[m]> On CI x86 and x86_64 always finish first
2019-06-01 18:11:03 <_ikke_> Yeah, I was surprised as well
2019-06-01 18:11:27 <PureTryOut[m]> 
ACTION starts making Plasma packages ready

2019-06-01 19:03:47 <SpaceToast> project-bot seems to miss things sometimes
2019-06-01 19:05:52 <_ikke_> SpaceToast: I assume the comment from misery indicates he does not object to the upgrade of ripgrep?
2019-06-01 19:06:05 <SpaceToast> _ikke_: I have no idea :/
2019-06-01 19:06:22 <SpaceToast> it read like a "I'm too busy to comment on this 6-line change, but don't take it from me" to me
2019-06-01 19:06:51 <SpaceToast> I'd imagine "LGTM" isn't that hard to type either
2019-06-01 19:06:51 <_ikke_> I will just apply it, I don't think this upgrade is very controversial or breaking things?
2019-06-01 19:07:02 <SpaceToast> no, it's just a version bump, and removal of `cd $builddir`
2019-06-01 19:07:05 <SpaceToast> perhaps they didn't realize it was a PR?
2019-06-01 19:07:15 <_ikke_> I mean the upgrade itself as well
2019-06-01 19:07:18 <SpaceToast> (the response makes a lot more sense if you assume it's a request for a version bump)
2019-06-01 19:07:23 <SpaceToast> the upgrade needs rust 1.34
2019-06-01 19:07:25 <SpaceToast> but we have that now!
2019-06-01 19:07:29 <_ikke_> 0.10 -> 11.0
2019-06-01 19:07:31 <SpaceToast> that's the biggest change, really
2019-06-01 19:07:36 <SpaceToast> yeah, that's why the scheme changed, requiring 1.34
2019-06-01 19:07:43 <SpaceToast> + stabilization
2019-06-01 19:07:46 <_ikke_> right
2019-06-01 19:08:29 <SpaceToast> it passes tests and all
2019-06-01 19:08:39 <SpaceToast> and if you want I can spin up a container to run by-hand tests but it really shouldn't be necessary
2019-06-01 19:09:08 <SpaceToast> re: project-bot missing, I mean pr8370
2019-06-01 19:09:15 <_ikke_> No, I don't think either
2019-06-01 19:09:43 <_ikke_> Added it to the project
2019-06-01 19:10:02 <_ikke_> I'm not using it atm as it has been crashing for me quite a few times
2019-06-01 19:10:11 <SpaceToast> tyty :)
2019-06-01 19:10:19 <SpaceToast> hopefully if/when we move to gitlab their interface works better
2019-06-01 19:10:26 <SpaceToast> (it should, since it wouldn't be competing with, well, all of GH)
2019-06-01 19:10:43 <SpaceToast> (who have been having performance issues anyways, lately)
2019-06-01 19:10:51 <_ikke_> The only thing I would miss from gitlab is submitting a review in one go
2019-06-01 19:11:03 <_ikke_> I mean, on gitlab
2019-06-01 19:11:20 <_ikke_> gitlab only supports individual comments
2019-06-01 19:11:57 <SpaceToast> gitlab has "approvals"
2019-06-01 19:12:06 <SpaceToast> let me try and see if maybe the docs are just buried
2019-06-01 19:12:56 <_ikke_> Haven't noticed that myself
2019-06-01 19:13:18 <PureTryOut[m]> You can submit a review in one go?
2019-06-01 19:13:24 <PureTryOut[m]> Basically you "start" a review on a MR, comment everything you need to on the different files that have been changed, then "finish" the review. It'll all end up in the same review
2019-06-01 19:13:24 <_ikke_> in gitlab?
2019-06-01 19:13:24 <SpaceToast> https://docs.gitlab.com/ee/user/discussions/index.html#discussions
2019-06-01 19:13:29 <SpaceToast> _ikke_: ^
2019-06-01 19:13:29 <PureTryOut[m]> I'm using it all the time at postmarketOS
2019-06-01 19:13:32 <SpaceToast> it's not "bundled" under a single review
2019-06-01 19:13:33 <PureTryOut[m]> Yes
2019-06-01 19:13:44 <SpaceToast> and is rather a set of "discussions" inline
2019-06-01 19:14:12 <SpaceToast> oh, hold on, 11.4 added reviews
2019-06-01 19:14:16 <SpaceToast> https://docs.gitlab.com/ee/user/discussions/index.html#merge-request-reviews-premium
2019-06-01 19:14:24 <PureTryOut[m]> As example, https://gitlab.com/postmarketOS/pmaports/merge_requests/384#note_174612672
2019-06-01 19:14:25 <SpaceToast> so yeah, looks like they reached parity :)
2019-06-01 19:14:33 <PureTryOut[m]> GitLab is awesome
2019-06-01 19:14:35 <_ikke_> I wanted to say, I haven't seen that at all yet
2019-06-01 19:15:06 <_ikke_> We seem to be running 11.10
2019-06-01 19:15:45 <SpaceToast> 11.11 came out a week and a half ago, but that's reasonably new
2019-06-01 19:16:37 <SpaceToast> MR Reviews are premium, but as was discussed before, once we're ready to move we can get a key by waving and saying "hey guys, we're open source"
2019-06-01 19:16:39 <PureTryOut[m]> _ikke_: "we"? Is Alpine running an instance somewhere?
2019-06-01 19:16:50 <_ikke_> I mean at $work
2019-06-01 19:17:00 <PureTryOut[m]> Ah ok
2019-06-01 19:17:15 <danieli> GL for AL is still WIP, see https://github.com/clandmeter/alpine-docker-gitlab
2019-06-01 19:17:18 <_ikke_> I don't see an option to start a review
2019-06-01 19:18:06 <SpaceToast> _ikke_: it's premium only, do you have an active license at work?
2019-06-01 19:18:14 <_ikke_> No, probably just ce
2019-06-01 19:18:18 <SpaceToast> that'd be it, then
2019-06-01 19:18:21 <_ikke_> right
2019-06-01 19:18:25 <SpaceToast> as open source we'd just get a license for free
2019-06-01 19:18:29 <PureTryOut[m]> Go to a MR, click on "Changes", click on the little comment icon that appears on the left when hovering over a line
2019-06-01 19:18:37 <PureTryOut[m]> Oh and yeah the enterprise thing
2019-06-01 19:18:44 <_ikke_> PureTryOut[m]: Yes, I know you can do inline comments
2019-06-01 19:19:04 <SpaceToast> PureTryOut[m]: _ikke_'s complaint was that the inline comments can't be "bundled" under a single namespace
2019-06-01 19:19:19 <PureTryOut[m]> Why would that be needed?
2019-06-01 19:19:23 <SpaceToast> it's convenient ¯\_(ツ)_/¯
2019-06-01 19:19:30 <SpaceToast> but you can do that with ee
2019-06-01 19:19:35 <_ikke_> Just submit everythign in one go
2019-06-01 19:19:45 <PureTryOut[m]> You can still do that with Gitlab
2019-06-01 19:19:49 <_ikke_> Otherwise people get notified on every single comment
2019-06-01 19:19:54 <PureTryOut[m]> They just appear as multiple comments
2019-06-01 19:19:58 <PureTryOut[m]> Oh that's not the case with Gitlab
2019-06-01 19:20:50 <PureTryOut[m]> 
ACTION uploaded an image: Screenshot_20190601_212039.png (77KB) < https://matrix.org/_matrix/media/v1/download/fam-ribbers.com/cFroocqQfKtpLtvsZYCLxzFj >

2019-06-01 19:20:56 <PureTryOut[m]> Ignore the colors, I'm using a bit broken custom CSS theme
2019-06-01 19:21:13 <PureTryOut[m]> But that screenshot should show you can submit a review on multiple things all in 1 go
2019-06-01 19:21:24 <PureTryOut[m]> The author of the MR will get just 1 notification
2019-06-01 19:21:36 <_ikke_> gitlab CE does not seem to support that
2019-06-01 19:21:47 <SpaceToast> yes, but we get free EE because we're open source
2019-06-01 19:21:47 <PureTryOut[m]> No I guess you need a license for that as SpaceToast said
2019-06-01 19:21:55 <SpaceToast> 
ACTION feels like it's been mentioned at least 5 times in a row now

2019-06-01 19:22:00 <PureTryOut[m]> Haha yes
2019-06-01 19:22:09 <_ikke_> I think we initially wanted to go for CE
2019-06-01 19:23:21 <Cogitri> Can I tweak GL's notification system so that it notifies me like GH does? During the time I used GL at Exherbo I only got notifications when someone explicitly pinged me :c
2019-06-01 19:23:49 <SpaceToast> Cogitri: iirc, GH works the same way, except it automatically subscribes you to anything you touch
2019-06-01 19:23:50 <_ikke_> Instead of when?
2019-06-01 19:23:51 <SpaceToast> you can just press the button
2019-06-01 19:24:18 <Cogitri> Ah, alrighty then
2019-06-01 19:24:37 <PureTryOut[m]> Yeah it's optional
2019-06-01 19:24:56 <Cogitri> Yeah, I think I prefer GH's approach a bit, but pressing the button works for me too
2019-06-01 19:25:04 <Cogitri> Handy for the GNOME gl too, thanks :)
2019-06-01 19:25:34 <PureTryOut[m]> I actually prefer the GL way 😜
2019-06-01 19:25:46 <SpaceToast> ideally, it'd be a per-account setting
2019-06-01 19:25:53 <SpaceToast> but that might just be the case, haven't looked into it :)
2019-06-01 19:32:04 <Cogitri> <PureTryOut[m] "I actually prefer the GL way 😜"> I always feel a bit nervous if I missed something :/
2019-06-01 19:57:33 <ollieparanoid[m]> oh, it is still not possible for users to edit the issues they just created. it would be nice if somebody could activate that in redmine
2019-06-01 20:05:48 <_ikke_> ollieparanoid[m]: From what I can see, you should be able to
2019-06-01 20:06:55 <ollieparanoid[m]> ikke: I'm not sure how it is named in redmine settings - but I can not edit the description of the issue I just created
2019-06-01 20:07:19 <ollieparanoid[m]> there is an edit button, and it allows to attach a new comment, and change various proprieties (project, tracker, title, ...)
2019-06-01 20:07:40 <_ikke_> Is there an edit link with a pencil?
2019-06-01 20:07:55 <_ikke_> Description [edit] (pencil)
2019-06-01 20:08:04 <_ikke_> Description (pencil) [edit]
2019-06-01 20:08:10 <ollieparanoid[m]> _ikke_: ooh, yes you are right
2019-06-01 20:08:32 <ollieparanoid[m]> okay, I was confused because I know another redmine instance, and there is a second edit link that directly allows to edit the description, without that intermediate step
2019-06-01 20:08:44 <ollieparanoid[m]> thanks!
2019-06-01 20:09:36 <_ikke_> Probably some kind of plugin
2019-06-01 20:40:22 <mps> are we resolved bug 10490
2019-06-01 20:40:36 <_ikke_> #10490
2019-06-01 20:41:10 <_ikke_> It has been marked resolved.
2019-06-01 20:41:28 <mps> yes, I see. should I mark it Closed?
2019-06-01 20:41:34 <SpaceToast> _ikke_: anything re: pr8280 and pr8369 ?
2019-06-01 20:41:46 <SpaceToast> both inoffensive version bumps, and I'm the maintainer
2019-06-01 20:41:51 <_ikke_> SpaceToast: I'm just looking at skim
2019-06-01 20:41:56 <SpaceToast> ah, nice, ty :)
2019-06-01 20:43:04 <mps> _ikke_: you have more experience than me about bug closing. what you think about my question: to Close it?
2019-06-01 20:44:52 <_ikke_> I think so, it's not tied to an alpine release
2019-06-01 20:45:17 <mps> ok, thanks
2019-06-01 20:46:36 <_ikke_> SpaceToast: Hmm, just ran into an issue with cleanup_srcdir for minio-client
2019-06-01 20:47:09 <_ikke_> I ran abuild clean because there was still a srcdir left, and it failed because go was not available
2019-06-01 20:47:18 <mps> this bug is from north1, maybe he could decide better than me
2019-06-01 20:47:29 <SpaceToast> _ikke_: that's expected, srcdir cleanup is usually done by `abuild -r`
2019-06-01 20:47:34 <_ikke_> I know
2019-06-01 20:47:35 <SpaceToast> I think the question is why srcdir was left
2019-06-01 20:47:45 <_ikke_> All sorts of reasons
2019-06-01 20:48:39 <SpaceToast> but under normal circumstances (including failed builds) srcdir cleanup is done with deps installed
2019-06-01 20:49:10 <_ikke_> find . -name src -maxdepth 3 | wc -l -> 52
2019-06-01 20:49:29 <SpaceToast> if the build fails, it staying there is normal
2019-06-01 20:49:35 <SpaceToast> and just gets removed afterwards
2019-06-01 20:49:45 <SpaceToast> but on my environment that doesn't ever cause any problems
2019-06-01 20:50:01 <SpaceToast> (i.e I just interrupted a build, and re-ran `abuild -r`, and it's about to finish successfully)
2019-06-01 20:50:14 <_ikke_> yes, it's not causing issues, I just wanted to clean it up
2019-06-01 20:50:17 <_ikke_> without building it
2019-06-01 20:50:24 <SpaceToast> just `abuild deps && abuild clean && abuild undeps`
2019-06-01 20:50:31 <_ikke_> Yes, I know I can do that
2019-06-01 20:50:44 <SpaceToast> I think it's the same category of problem as trying to run `abuild clean` without fetching deps
2019-06-01 20:51:09 <_ikke_> sorry, that's exactly the same?
2019-06-01 20:51:32 <_ikke_> SpaceToast: btw, you can also do abuild deps clean undeps
2019-06-01 20:51:39 <SpaceToast> oh, good to know, thanks
2019-06-01 20:51:49 <SpaceToast> (I think I was aware of that but half-forgot for whatever reason)
2019-06-01 20:52:03 <PureTryOut[m]> _ikke_: could you restart the CI of pr8334?
2019-06-01 20:52:05 <SpaceToast> and yes, as mentioned, I think it's the same category of problem
2019-06-01 20:52:15 <SpaceToast> basically I'm not sure what resolution/conversation you're trying to work towards :)
2019-06-01 20:52:31 <_ikke_> PureTryOut[m]: thanks, yes, I was waiting for the packages to be uploaded and forgot about it
2019-06-01 20:52:40 <PureTryOut[m]> No problem!
2019-06-01 20:52:46 <_ikke_> Done
2019-06-01 20:52:56 <PureTryOut[m]> Thanks!
2019-06-01 20:53:08 <PureTryOut[m]> The PR I'm preparing atm depends on it 😅
2019-06-01 20:54:47 <Cogitri> FWIW, you can restart the CI by closing/opening or `git commit --amend` and force pushing after that too
2019-06-01 20:55:25 <_ikke_> Just restarting CI is 'cleaner' though :)
2019-06-01 20:55:31 <asriel[m]> It's good to see that PureTryOut pushing KDE stuffs to Alpine. :)
2019-06-01 20:55:51 <PureTryOut[m]> _ikke_: exactly
2019-06-01 20:56:31 <PureTryOut[m]> Shit the CI failed 😭
2019-06-01 20:58:49 <mps> is it ok to have 'custom:chromiumos' license in aports
2019-06-01 20:59:23 <SpaceToast> usually, you write "custom" and copy the license in the -doc subpackage
2019-06-01 20:59:46 <Cogitri> BTW, can I get a CI-malfunction on pr8028& prpr7601?
2019-06-01 21:00:04 <Cogitri> Oh and pr7481
2019-06-01 21:00:21 <Cogitri> Abuild being unable to pull in stuff from different repos is becoming pretty annoying
2019-06-01 21:00:26 <mps> SpaceToast: thanks
2019-06-01 21:01:09 <_ikke_> Cogitri: Why is it only an issue for aarch64 regarding gnome-builder?
2019-06-01 21:01:54 <Cogitri> Because I enabled flatpak{,-builder} on aarch64 in the same Pr
2019-06-01 21:01:55 <Cogitri> They were disabled before
2019-06-01 21:02:36 <_ikke_> ah ok
2019-06-01 21:03:25 <Cogitri> Oh, pr8366 too I suppose
2019-06-01 21:25:43 <PureTryOut[m]> Great, just lost a ton of work in Git... Switched branches, and now the branch I came from doesn't exist anymore. Wtf
2019-06-01 21:26:16 <_ikke_> PureTryOut[m]: In any case, the reflog should still have you covered
2019-06-01 21:26:19 <_ikke_> PureTryOut[m]: What happened?
2019-06-01 21:26:27 <_ikke_> PureTryOut[m]: Any terminal output?
2019-06-01 21:26:52 <PureTryOut[m]> Oh, wtf I found it again. The branch was named differently than my shell history was suggesting
2019-06-01 21:29:25 <PureTryOut[m]> How strange, this branch name is nowhere to be found in my shell history
2019-06-01 21:32:33 <_ikke_> PureTryOut[m]: perhaps `git reflog` helps?
2019-06-01 22:00:31 <SpaceToast> -static seems to be coming up against some problems :/
2019-06-01 22:00:46 <SpaceToast> how do you differentiate between static binaries and static libraries? (ldd x -> not a static binary; vs .a)
2019-06-01 22:01:08 <SpaceToast> right now looks like they both use -static, but packages like curl seem to cause confusion like that on occasion
2019-06-01 22:01:30 <SpaceToast> (e.g I recall someone compiling the binary as static into -static, but everyone was assuming it was about archives)
2019-06-01 22:02:14 <mps> I think -static should be used for libs
2019-06-01 22:06:12 <SpaceToast> I think so too, but what do we do about busybox-static and apk-tools-static
2019-06-01 22:07:13 <mps> well, yes, right question
2019-06-01 22:09:00 <Cogitri> Hm
2019-06-01 22:09:31 <SpaceToast> oh, I just realized main/nodejs is LTS and community/nodejs-current is.. well... current
2019-06-01 22:09:35 <SpaceToast> so we *do* have 12! nice
2019-06-02 04:18:24 <north1> oh cool
2019-06-02 04:18:33 <north1> Some python projects adopted pyproject.toml instead of setup.py
2019-06-02 05:09:07 <_ikke_> https://xkcd.com/927/
2019-06-02 05:09:08 <alpine-meetbot> https://xkcd.com/927 | Standards | Alt-text: Fortunately, the charging one has been solved now that we've all standardized on mini-USB. Or is it micro-USB? Shit.
2019-06-02 05:09:59 <north1> _ikke_: At least the setup.py standard is in python3 itself and py-setuptools py3-setuptools depend on nothing but python itself
2019-06-02 05:10:18 <north1> poetry which is the buildsystem for pyproject.toml depends on at least cleo for our usecase (building stuff)
2019-06-02 05:10:25 <north1> and cleo itself depends on some other unpackaged stuff
2019-06-02 05:17:09 <north1> poetry -> cleo -> {paste,pylev}
2019-06-02 05:18:18 <SpaceToast> poetry is only one of the build systems pyproject.toml can utilize
2019-06-02 05:18:47 <SpaceToast> pep518 has quite a few funny consequences
2019-06-02 05:21:49 <north1> Any that depends only on python itself ?
2019-06-02 05:23:07 <SpaceToast> not that I can think of, they all use things like requests to make their own jobs simpler
2019-06-02 05:23:30 <SpaceToast> but that doesn't really matter because the point of pyproject.toml is to document (and sometimes configure) the choice of buildsystem that the project makes
2019-06-02 05:23:49 <SpaceToast> i.e even if we wanted to use, say, flit, if the project has chosen poetry, poetry we must have
2019-06-02 05:24:03 <SpaceToast> (unless we just use pip to resolve things automagically)
2019-06-02 05:24:42 <SpaceToast> still, it'd be nice to have poetry packaged; I predict it'll become the preferred build system of choice (given that it actually handles the entire workflow, and works with tox)
2019-06-02 05:25:03 <north1> I am working on getting it sorta of packaged
2019-06-02 05:25:09 <north1> pr8381
2019-06-02 05:27:17 <SpaceToast> pretty strange, but I'm too tired right now to look into it any deeper than that :)
2019-06-02 05:30:09 <north1> Speaking of sleepy i wrote archs="noarch py3-pastel py3-pylev"
2019-06-02 05:30:16 <_ikke_> lol
2019-06-02 05:35:06 <SpaceToast> also morning _ikke_ :)
2019-06-02 05:36:04 <_ikke_> Hello
2019-06-02 06:26:35 <_ikke_> A disadvantage of building rust projects atm is that you are constantly building all dependencies as well
2019-06-02 06:28:57 <SpaceToast> rust binaries don't necessarily depend on the latest version of a given dependency
2019-06-02 06:29:05 <SpaceToast> in fact, you can specify basically any version constraint yo wish
2019-06-02 06:29:23 <SpaceToast> so it's quite impractical to even attempt to handle that within a typical distro package manager
2019-06-02 06:29:41 <SpaceToast> anyway I'm off to bed
2019-06-02 06:29:47 <_ikke_> night
2019-06-02 06:53:19 <north1> well i got poetry to run
2019-06-02 06:53:20 <north1> finally
2019-06-02 07:05:00 <north1> can someone merge pytest fix ?
2019-06-02 07:05:19 <north1> pr8349
2019-06-02 07:09:22 <_ikke_> why does that PR supersede the one from otlabs?
2019-06-02 07:09:39 <north1> It works
2019-06-02 07:29:43 <north1> got poetry to install
2019-06-02 07:29:58 <north1> so basically another step for a normal (read setup.py) install
2019-06-02 08:49:28 <north1> pr8384 needs CI-reset
2019-06-02 10:22:49 <_ikke_> north1: restarted
2019-06-02 10:30:08 <north1> _ikke_: ty
2019-06-02 10:30:23 <north1> Converting what i can from kde to use xvfb-run when X11 is needed
2019-06-02 10:31:05 <_ikke_> Nice solution
2019-06-02 10:31:21 <north1> yes
2019-06-02 11:16:46 <_ikke_> north1: one kdeclarative test is failing
2019-06-02 11:17:17 <north1> I am aware
2019-06-02 11:17:32 <north1> At supermarket currently
2019-06-02 11:19:04 <north1> If anything I'll just re-assign as making progress with running testsuite and declare it good to go
2019-06-02 11:19:13 <_ikke_> right
2019-06-02 11:19:30 <_ikke_> I noticed the option="!check" was just commendet out
2019-06-02 11:19:32 <_ikke_> commented*
2019-06-02 11:19:44 <north1> Yeah if it is good to go I remove it
2019-06-02 11:20:59 <_ikke_> I tried to push all of them at the same time, but I will skipp kdeclarative
2019-06-02 11:22:37 <PureTryOut[m]> Huh, can't get docker-abuild working on my laptop. It keeps complaining that it doesn't have permissions to create `/home/builder/.abuild/*.rsa`
2019-06-02 11:23:10 <_ikke_> strange
2019-06-02 11:23:19 <PureTryOut[m]> maxice8: oh you have a way to run X11 tests? Nice!
2019-06-02 11:24:36 <north1> PureTryOut: I think tbk told me about xvfb-run
2019-06-02 11:27:19 <PureTryOut[m]> I remember I had this docker-abuild problem on my desktop as well, but somehow fixed it
2019-06-02 11:27:45 <PureTryOut[m]> Ah, manually creating `~/.abuild`
2019-06-02 11:42:31 <north1> I rewrote the apkbuild reference a little to refer to xvfb-run
2019-06-02 11:42:34 <north1> for running tests on X11
2019-06-02 11:45:45 <mps> iirc, few days ago I moved xvfb-run to community. it is useful for testing X apps
2019-06-02 11:46:02 <north1> so it was you then
2019-06-02 11:46:24 <mps> does it work
2019-06-02 11:46:40 <north1> Yes it does
2019-06-02 11:46:59 <mps> good, then. see you later :)
2019-06-02 11:59:39 <north1> pr8392 needs a CI reset
2019-06-02 11:59:57 <north1> pr8391 needs a CI reset as well
2019-06-02 12:00:33 <_ikke_> done
2019-06-02 12:00:39 <north1> ty
2019-06-02 12:05:41 <north1> pr8388 also needs CI reset
2019-06-02 12:05:56 <north1> These framework thingies are so easy to fail to fetch
2019-06-02 12:06:39 <_ikke_> Upstream unstable?
2019-06-02 12:06:46 <north1> no clue
2019-06-02 12:07:04 <_ikke_> There were no issues building them initially
2019-06-02 13:33:47 <bratkartoffel> _ikke_: Any chance to get pr7808 merged and moved to community before 3.10 release?
2019-06-02 13:34:05 <_ikke_> I think so
2019-06-02 13:35:08 <bratkartoffel> That would be awesome news, thanks. Just saw that the first RC for 3.10 was tagged a few days ago
2019-06-02 13:57:58 <PureTryOut[m]> So, in my mind it doesn't make sense to have qt5-qtbase be built with desktop OpenGL on arm platforms. On those platforms OpenGL GLESv2 is used instead, so wouldn't it be logical to build qt5-qtbase with that instead on arm? Would anyone be against me making that change?
2019-06-02 13:59:11 <Cogitri> Didn't we discuss that a few days ago already? Not sure what the result of that discussion was though
2019-06-02 14:00:43 <PureTryOut[m]> I mentioned it, but I don't believe there was an answer
2019-06-02 14:00:52 <PureTryOut[m]> 
ACTION searches through chat log

2019-06-02 14:03:26 <PureTryOut[m]> Ah there was a discussion about it recently, ollieparanoid brought it up. Conclusion was not making the change it seems. Details why https://gitlab.com/postmarketOS/pmaports/issues/232#note_176406830
2019-06-02 14:18:12 <_ikke_> Hmm, does patch remove the executable bit of a file that is patched?
2019-06-02 14:18:16 <_ikke_> seems like it does
2019-06-02 15:58:48 <kpcyrd> I couldn't find any replies in the archive, is there any way to help with https://lists.alpinelinux.org/alpine-devel/6664.html?
2019-06-02 15:59:26 <kpcyrd> s/any way/a way/ I guess
2019-06-02 15:59:26 <alpine-meetbot> kpcyrd meant to say: I couldn't find any replies in the archive, is there a way to help with https://lists.alpinelinux.org/alpine-devel/6664.html?
2019-06-02 16:00:18 <_ikke_> I think it will have to wait until 3.10 has been released
2019-06-02 16:00:37 <_ikke_> You can test it yourself perhaps to see if it works
2019-06-02 16:05:53 <_ikke_> north1: ping
2019-06-02 16:12:57 <Cogitri> He's sleeping right now
2019-06-02 16:13:34 <_ikke_> k
2019-06-02 16:43:49 <PureTryOut[m]> `export JOBS=<anything>` in abuild.conf doesn't seem to do much with docker-abuild...
2019-06-02 16:47:40 <Cogitri> wfm
2019-06-02 16:48:02 <Cogitri> Do note that it uses $HOME/.abuild/abuild.conf and not /etc/abuild/abuild.conf by default
2019-06-02 16:48:38 <PureTryOut[m]> I realize that
2019-06-02 16:55:42 <mps> PureTryOut[m]: maybe limited by docker
2019-06-02 18:37:05 <bratkartoffel> _ikke_: Just saw that openjdk11 fails on ppc64le
2019-06-02 18:37:13 <bratkartoffel> I'll take a look
2019-06-02 18:37:32 <_ikke_> Yes, indeed
2019-06-02 18:58:50 <bratkartoffel> _ikke_: pr8407 should fix this build issue
2019-06-02 18:59:23 <bratkartoffel> waiting for local crosscompile to finish, but looks promising
2019-06-02 19:00:44 <_ikke_> bratkartoffel: ok, keeping an eye on it
2019-06-02 19:03:46 <bratkartoffel> i'm unsure about the warning from config.guess
2019-06-02 19:04:40 <bratkartoffel> only occurs on the builder, not my local system. Is it safe to patch that file unconditionally?
2019-06-02 19:06:52 <_ikke_> bratkartoffel: You can call update_config_guess in prepare()
2019-06-02 19:07:05 <mps> bratkartoffel: what build log say on builder
2019-06-02 19:07:07 <_ikke_> https://git.alpinelinux.org/abuild/tree/abuild.in#n591
2019-06-02 19:07:23 <_ikke_> config.guess: unable to guess system type
2019-06-02 19:07:26 <mps> bratkartoffel: nvm, found it
2019-06-02 19:08:43 <bratkartoffel> _ikke_: thanks. So instead of downloading + patching config.guess / config.sub "by hand", i could use the two functions?
2019-06-02 19:08:57 <_ikke_> yes
2019-06-02 19:25:11 <blueyed> Since Alpine 3.9 "apk add --virtual foo make; apk add --virtual foo hello" will not add "hello" anymore to "foo".
2019-06-02 19:25:47 <blueyed> (I've worked around this by not using --virtual anymore, but tracking build deps manually, but that makes it harder to keep previously installed build deps then)
2019-06-02 19:28:37 <blueyed> Reported already in https://bugs.alpinelinux.org/issues/9651
2019-06-02 19:29:06 <blueyed> I've asked about this before, and it would at least be good to know if this is intentional, or a (serious) bug after all.
2019-06-02 19:33:22 <_ikke_> It's more like a design issue
2019-06-02 19:33:31 <_ikke_> blueyed: ^
2019-06-02 19:33:57 <blueyed> _ikke_: ok.  is there a workaround?
2019-06-02 19:34:06 <_ikke_> Not yet atm
2019-06-02 19:34:46 <blueyed> hmm, too bad.. can you comment at the ticket, or should I?
2019-06-02 19:36:42 <_ikke_> I already commented on a similar issue
2019-06-02 19:39:05 <_ikke_> bratkartoffel: Were you still working on the openjdk11 PR?
2019-06-02 19:39:28 <bratkartoffel> Yes, I'm still waiting for my crosscompile build for ppc64le
2019-06-02 19:39:42 <bratkartoffel> slow machine here and qemu is not as fast as I'd like it to be
2019-06-02 19:41:05 <_ikke_> no problem
2019-06-02 19:41:12 <_ikke_> Was just wondering if I still had to wait
2019-06-02 19:41:34 <bratkartoffel> should be done in a few minutes
2019-06-02 19:44:42 <bratkartoffel> _ikke_ build succeeded, pr8407 may be merged
2019-06-02 19:47:28 <mps> depends="!pkgname" is the same as conflicts in some other distro? writing response to pw.a.o post and want to be sure
2019-06-02 19:47:38 <_ikke_> yes
2019-06-02 19:48:00 <mps> _ikke_: thanks. you are awesome :)
2019-06-02 19:48:11 <jwh> hm, how does that work, conflicts with itself?
2019-06-02 19:48:14 <jwh> or is it for meta paackages
2019-06-02 19:48:17 <jwh> packages*
2019-06-02 19:48:32 <jwh> where provides exists
2019-06-02 19:50:21 <_ikke_> jwh: it would not be the current package name, but another package
2019-06-02 19:50:30 <mps> jwh: provides is special kind of things
2019-06-02 19:51:40 <jwh> yeah but that makes no sense either, does it literally conflict with every package but itself?
2019-06-02 19:51:55 <_ikke_> no
2019-06-02 19:52:00 <_ikke_> with the package your specify
2019-06-02 19:52:04 <jwh> ohhh
2019-06-02 19:52:11 <jwh> I was taking pkgname as $pkgname
2019-06-02 19:52:38 <_ikke_> bratkartoffel: pushed
2019-06-02 19:52:58 <mps> s/$/!/
2019-06-02 21:38:54 <north1> s390x failed testing/gnome-maps
2019-06-02 21:44:37 <_ikke_> gjs missing
2019-06-02 21:44:52 <_ikke_> shall I disable it for now?
2019-06-02 21:45:01 <north1> i guess yes
2019-06-02 21:46:19 <_ikke_> done'
2019-06-02 23:21:05 <north1> @TBK:matrix.org: ping, is it possible to move xvfb-run to main dbus/ and tk/ require X11 and are in main/
2019-06-02 23:23:55 <mps> north1: does dbus require xvfb-run for test
2019-06-02 23:24:19 <north1> mps: dbus requires a running X11 server according to the comment on options="!check"
2019-06-02 23:24:44 <mps> could be, although sounds strange to me
2019-06-02 23:38:23 <north1> mps: https://github.com/alpinelinux/aports/pull/8426
2019-06-02 23:39:14 <north1> ignore CI, it is a common annoying problem
2019-06-02 23:40:56 <mps> north1: I don't have access to main
2019-06-02 23:42:18 <north1> mps: no worries, just look
2019-06-02 23:42:33 <north1> need TBK and ncopa to give it ok first anyways
2019-06-02 23:42:59 <mps> aha, first one is ok
2019-06-02 23:44:31 <mps> second, why you didn't simply remove 'options="!check"`
2019-06-02 23:45:27 <mps> and you left 'cd $buildir' for second patch :)
2019-06-02 23:45:41 <mps> but, looks good
2019-06-02 23:45:58 <north1> mps: which package ?
2019-06-02 23:46:46 <mps> https://github.com/alpinelinux/aports/pull/8426
2019-06-02 23:47:01 <mps> second patch
2019-06-02 23:47:01 <north1> dbus ?
2019-06-02 23:47:10 <mps> yes
2019-06-02 23:47:17 <north1> it is in main/
2019-06-02 23:47:20 <north1> cd "$builddir" doesn't apply on main
2019-06-02 23:47:46 <north1> because it can be backported to a version of Alpine that has abuild old enough to not be above 3.3.0 which introduced automatic switching to $builddir
2019-06-02 23:48:21 <north1> apkbuild-lint won't perform those checks on packages in main/
2019-06-02 23:48:24 <mps> how? uh, I need to fix some patch then
2019-06-02 23:49:00 <mps> s/patch/patches/
2019-06-02 23:49:00 <alpine-meetbot> mps meant to say: how? uh, I need to fix some patches then
2019-06-02 23:49:40 <north1> https://github.com/maxice8/atools/blob/master/apkbuild-lint#L245
2019-06-02 23:50:01 <north1> i need to find a better way to indicate the repo a package comes from
2019-06-02 23:50:27 <north1> this currently works solely on my workflow that works from the root of aports instead of the directory where the APKBUILD is
2019-06-02 23:51:08 <mps> aha, good to know. thanks for info
2019-06-02 23:52:23 <north1> I use it in my git hook which passes <repo>/<pkgname>/APKBUILD so it can perform that check.
2019-06-02 23:53:35 <mps> I run once alint on all, with find
2019-06-02 23:54:11 <mps> and noticed that we a lot of things to fix
2019-06-02 23:59:55 <mps> hmm, I have to fix ifupdown patch on pw.a.o because removed 'cd $builddir'
2019-06-03 02:49:41 <north1> Can someone fetch the source code for gst-plugins-bad to confirm their end is slow and not my internet ?
2019-06-03 03:08:53 <mps> north1: url?
2019-06-03 03:09:34 <north1> mps: https://gstreamer.freedesktop.org/src/gst-plugins-bad/gst-plugins-bad-1.16.0.tar.xz
2019-06-03 03:11:21 <mps> doesn't look too slow
2019-06-03 03:14:17 <mps> busybox wget is not best measurement tool
2019-06-03 03:15:29 <north1> alright ty
2019-06-03 06:13:26 <ncopa> morning
2019-06-03 06:13:35 <north1> morning
2019-06-03 06:13:42 <_ikke_> o/
2019-06-03 06:13:46 <ncopa> did anyone test the rc1?
2019-06-03 06:14:52 <north1> no
2019-06-03 06:18:11 <Cogitri> Morning
2019-06-03 06:18:20 <Cogitri> Am on Edge too
2019-06-03 06:31:55 <tcely> pr8437 is ready to merge
2019-06-03 06:34:04 <ncopa> now that rc1 is out, i would like to try fix as many bugs as possible
2019-06-03 06:34:49 <_ikke_> Any known bugs?
2019-06-03 06:35:23 <ncopa> https://bugs.alpinelinux.org/projects/alpine/issues?fixed_version_id=144&set_filter=1&status_id=o
2019-06-03 06:35:57 <ncopa> https://bugs.alpinelinux.org/projects/alpine/issues?fixed_version_id=133&set_filter=1&status_id=o
2019-06-03 06:38:00 <north1> ncopa: #10043 needs ceph in community which it is currently
2019-06-03 06:47:03 <north1> can't reproduce #10451 though
2019-06-03 07:55:46 <tcely> _ikke_: most bots are just programs that respond to web hook events
2019-06-03 08:01:55 <_ikke_> tcely: I understand
2019-06-03 08:02:31 <_ikke_> It's more to say that it seems to be a wider issue, not just algitbot
2019-06-03 08:03:46 <fabled> _ikke_, the github-pr-closer webhook. see: https://github.com/organizations/alpinelinux/settings/hooks/9637400
2019-06-03 08:04:40 <_ikke_> Oh, apparently I don't have access to there
2019-06-03 08:04:45 <tcely> fabled: people who are not admins can't view that
2019-06-03 08:04:58 <fabled> tcely, yes. _ikke_ is one.
2019-06-03 08:05:06 <_ikke_> Not on the org
2019-06-03 08:05:55 <fabled> oh
2019-06-03 08:06:14 <_ikke_> I'm just a member, not owner
2019-06-03 08:08:16 <fabled> was mistakenly looking at aports for permission.
2019-06-03 08:09:04 <fabled> maybe i move this discussion to infra channel
2019-06-03 08:48:02 <tcely> ncopa: pr8339 should eliminate circular dependency
2019-06-03 08:52:38 <_ikke_> now hiredis is failing on armhf
2019-06-03 08:58:46 <tcely> _ikke_: how can I tell when that build was last tried?
2019-06-03 08:59:53 <_ikke_> I usually look in #alpine-commits
2019-06-03 09:09:52 <ncopa> tcely: im not sure i like the dhcp stuff
2019-06-03 09:10:30 <ncopa> how is it supposed to work?
2019-06-03 09:11:00 <ncopa> i think i know why hiredis fails
2019-06-03 09:11:24 <tcely> apk add dhcp gets the vanilla server. apk add dhcp-server-ldap removes vanilla and installs ldap. removing ldap causes vanilla to be installed again.
2019-06-03 09:12:23 <ncopa> ok
2019-06-03 09:12:31 <ncopa> i guess that how we want it to work
2019-06-03 09:12:58 <ncopa> let me finish up hiredis first
2019-06-03 09:33:57 <ncopa> tcely: i think im gonna add this to dhcp: http://tpaste.us/jXKl
2019-06-03 09:35:14 <tcely> as long as the behavior doesn't change that's fine with me. I'm not so clear on how adding a specific version affects the resolver
2019-06-03 09:37:14 <PureTryOut[m]> Plasma requires the Qt5 binaries without the `-qt5` suffix, which Alpine doesn't have. What is the recommend approach to resolve this? I could add the qtchooser package which allows the user to choose between Qt versions installed at the same time by symlinking all binaries in `/usr/lib/qt*/bin` to `/usr/bin`, or I could just modify qt5-qtbase to symlink it's own binaries to there
2019-06-03 09:37:59 <tcely> does there mean /usr/bin in this case?
2019-06-03 09:38:12 <north1> qtchooser
2019-06-03 09:39:06 <north1> https://github.com/void-linux/void-packages/blob/master/srcpkgs/qtchooser/template
2019-06-03 09:39:09 <north1> qt5 depends= on it
2019-06-03 09:39:14 <PureTryOut[m]> Yeah thought so
2019-06-03 09:39:16 <PureTryOut[m]> Will add
2019-06-03 09:39:28 <PureTryOut[m]> Should I make qt4 depend on it as well?
2019-06-03 09:39:38 <PureTryOut[m]> Although it be preferable to get rid of Qt4 entirely of course lol
2019-06-03 09:44:13 <north1> There is no point in investing time in Qt4 if it isn't for burying it
2019-06-03 09:44:38 <PureTryOut[m]> Agreed, will just add support for Qt5 then
2019-06-03 09:56:18 <TBB> that means you'll be spending some time porting Qt4 software for Qt5 (yes, it exists)
2019-06-03 09:56:32 <TBB> in general of course getting rid of Qt4 would be the right choice
2019-06-03 10:06:01 <PureTryOut[m]> So I found a bug in Qt 5.12.3 which causes SDDM to crash when the Breeze theme is used (matters for packaging Plasma). I can either patch Qt 5.12.3 for now or use a Plasma workaround (has to be applied as patch), what would be the preferred solution?
2019-06-03 10:06:16 <PureTryOut[m]> It's fixed in Qt 5.12.4 btw
2019-06-03 10:08:14 <tcely> patching Qt until it is upgraded and fixed would be my preference
2019-06-03 10:11:17 <PureTryOut[m]> Yeah thought so, will do then
2019-06-03 10:25:49 <north1> Ok i need 2 -dev subpackages
2019-06-03 10:26:01 <_ikke_> why 2?
2019-06-03 10:29:02 <north1> actually 3 lol
2019-06-03 10:31:43 <north1> wxgtk has a wxgtk3 variant so you need wxgtk2-dev wxgtk3-dev and wxgtk-base-dev
2019-06-03 10:59:47 <TBB> https://www.openwall.com/presentations/Owl/mgp00020.html - would this make any sense to add to Alpine?
2019-06-03 11:17:43 <Cogitri> TBB: Why not migrate more stuff to PAM like other distros?
2019-06-03 11:19:06 <mps> Cogitri: and then to systemd?
2019-06-03 11:19:25 <mps> like other distros :)
2019-06-03 11:20:32 <Cogitri> Uhh, that's one way to take it I suppose
2019-06-03 11:21:02 <north1> Slippery slope at supersonic speeds
2019-06-03 11:21:47 <Cogitri> I don't think we have to do everything other distros do, but PAM certainly is one area where it makes sense
2019-06-03 11:22:08 <mps> I disagree
2019-06-03 11:36:52 <tcely> I'd appreciate some more eyes on pr7504 and pr7533
2019-06-03 11:44:08 <Cogitri> Do we have some policy on building with CLang? The latest webkit2gtk is so big that it apparently doesn't like to build on 32-bit platforms with our settings and upstream has suggested giving it a shot with CLang
2019-06-03 12:05:10 <PureTryOut[m]> I have some library complaining about mixed Qt versions (0x50c01 vs 0x50c03, so I guess Qt 5.12.1 vs Qt 5.12.3), but I can't figure out which one
2019-06-03 12:05:23 <PureTryOut[m]> Does anyone know how to check this?
2019-06-03 13:02:04 <PureTryOut[m]> Since all my custom packages are built against Qt 5.12.3, I'm guessing some package currently in the repos is causing this
2019-06-03 13:03:27 <Cogitri> Ah yes, private Qt api is fun
2019-06-03 13:17:00 <PureTryOut[m]> Yeah... How would I debug this? 😛 The error messages only talk about "this library", but don't actually tell me which library that is...
2019-06-03 13:18:34 <Cogitri> Let me ask a KDE dev
2019-06-03 13:19:51 <Cogitri> Mind giving me the actual error msg?
2019-06-03 13:21:18 <PureTryOut[m]> "Cannot mix incompatible Qt library (version 0x50c01) with this library (version 0x50c03)"
2019-06-03 13:21:26 <PureTryOut[m]> So seems to suggest something is linked against Qt 5.12.1 still
2019-06-03 13:22:58 <Cogitri> Not linked, but compiled against private Qt ABI
2019-06-03 13:24:38 <PureTryOut[m]> Oh. Still, something needs recompiling lol
2019-06-03 13:25:19 <Cogitri> Yup, the error message really is shitty
2019-06-03 13:32:52 <PureTryOut[m]> Who are you asking and where actually?
2019-06-03 13:41:22 <Cogitri> So, the answer is `maybe grep for 0x050C01 in /usr/include/qt5`
2019-06-03 13:41:37 <Cogitri> Or strace and see where everything breaks
2019-06-03 13:42:00 <Cogitri> Or rebuild all of Qt
2019-06-03 13:42:26 <PureTryOut[m]> The latter I prefer to not have to do lol
2019-06-03 13:42:39 <Cogitri> Figured so :P
2019-06-03 13:42:42 <PureTryOut[m]> I was already grepping, not particularly in `/usr/include/qt5` though
2019-06-03 13:43:07 <Cogitri> <PureTryOut[m] "Who are you asking and where act"> I asked a KDE core dev I know from my time at Exherbo
2019-06-03 13:43:51 <PureTryOut[m]> Actually that directory doesn't exist on Alpine
2019-06-03 13:44:12 <PureTryOut[m]> <Cogitri "I asked a KDE core dev I know fr"> Ah cool!
2019-06-03 13:45:31 <Cogitri> <PureTryOut[m] "Actually that directory doesn't "> You've installed the qt5-dev packages, yes?
2019-06-03 13:45:33 <PureTryOut[m]> I have not actually, I'll do that
2019-06-03 13:47:29 <PureTryOut[m]> That directory still doesn't exist. `/usr/include/Qt*` does, but grepping in there doesn't give me any results
2019-06-03 13:52:42 <Cogitri> Huh, strace it is then I guess
2019-06-03 13:54:20 <mps> or ltrace
2019-06-03 14:02:15 <PureTryOut[m]> ltrace?
2019-06-03 14:03:32 <mps> apk search ltrace, Tracks runtime library calls in dynamically linked programs
2019-06-03 14:04:46 <mps> ipk info, sorry
2019-06-03 14:07:09 <PureTryOut[m]> Well, strace doesn't tell me much either...
2019-06-03 14:07:19 <danieli> ltrace is basically strace for library calls instead of system calls
2019-06-03 14:07:32 <danieli> pretty darn similar
2019-06-03 14:08:04 <PureTryOut[m]> ```
2019-06-03 14:08:05 <PureTryOut[m]> writev(2, [{iov_base="", iov_len=0}, {iov_base="Cannot mix incompatible Qt libra"..., iov_len=88}], 2Cannot mix incompatible Qt library (version 0x50c01) with this library (version 0x50c03)) = 88
2019-06-03 14:08:06 <PureTryOut[m]> ```
2019-06-03 14:09:49 <danieli> everything in edge seems to be 5.12.3-r0 except qt5-qt{keychain,script,webkit}
2019-06-03 14:10:28 <PureTryOut[m]> qt5-qtscript is 5.12.3 according to `apk info`
2019-06-03 14:10:48 <PureTryOut[m]> Oh, it's -r2 though, sorry
2019-06-03 14:11:47 <PureTryOut[m]> Although it seems that we just forgot to reset `$pkgrel` there when upgrading from 5.12.0
2019-06-03 14:12:11 <danieli> what do you mean?
2019-06-03 14:12:36 <PureTryOut[m]> Checking the git log for qt5-qtscript, it got updated from 5.12.0 to 5.12.1 and then 5.12.3 without resetting `$pkgrel` back to 0
2019-06-03 14:13:04 <danieli> just checked - that should be no big deal then
2019-06-03 14:13:28 <PureTryOut[m]> Yeah
2019-06-03 14:13:38 <danieli> able to write some quick instructions so i can reproduce in a docker container?
2019-06-03 14:14:08 <PureTryOut[m]> I wouldn't mind recompiling all Qt packages if I could make docker-abuild use more than 2 cores...
2019-06-03 14:14:17 <PureTryOut[m]> danieli: sure
2019-06-03 14:14:18 <danieli> (e.g. the apkbuild for the library that fails?)
2019-06-03 14:14:45 <PureTryOut[m]> The problem is that I don't know which library fails...
2019-06-03 14:15:18 <PureTryOut[m]> I'm trying to package Plasma, and launching it creates that error in the log. All packages are freshly built against Qt 5.12.3 though, so can't be in KDE or Plasma itself
2019-06-03 14:15:41 <danieli> ah, i see
2019-06-03 14:15:50 <danieli> which qt5-* packages does it depend on?
2019-06-03 14:15:59 <PureTryOut[m]> To test I have just built the packages locally, put them online in a personal repo, install them to my system and run `xinit` with `startkde` in the `~/.xinitrc`
2019-06-03 14:16:06 <Cogitri> Yup, that has to be Qt because that error only occurs when using private ABI
2019-06-03 14:16:21 <danieli> Cogitri: yeah, that's my thinking too
2019-06-03 14:16:25 <PureTryOut[m]> qt5-qtbase, qt5-qtdeclarative-dev, qt5-qtx11extras, qt5-qtsvg, hopefully I haven't missed any here...
2019-06-03 14:16:58 <Cogitri> qt5-qtdeclarative always did this for me when I hit this error on Exherbo
2019-06-03 14:17:09 <Cogitri> So yeah
2019-06-03 14:17:37 <PureTryOut[m]> I already tried rebuilding qt5-qtdeclarative, didn't help sadly
2019-06-03 14:18:31 <PureTryOut[m]> Oh some of the packages also depend on qt5-qttools and qt5-qtscript
2019-06-03 14:18:58 <PureTryOut[m]> and qt5-qtquickcontrols and qt5-qtquickcontrols2
2019-06-03 14:19:30 <PureTryOut[m]> Well, basically the entirety of qt5 😂
2019-06-03 14:19:45 <Cogitri> Oof
2019-06-03 14:19:59 <danieli> kinda figured when apk added half the packages in existence
2019-06-03 14:20:26 <PureTryOut[m]> it's mostly makedepends only though
2019-06-03 14:20:35 <danieli> they shouldn't install when i `apk add` though
2019-06-03 14:20:48 <danieli> i'm installing them, not building them
2019-06-03 14:20:48 <Cogitri> About docker-abuild: Just change the script to bind mount whatever abuild.conf you use I guess
2019-06-03 14:21:21 <PureTryOut[m]> It only installs ~150 packages for me when I install plasma-desktop. When building it installs over 500, so it definitely doesn't install everything
2019-06-03 14:21:51 <PureTryOut[m]> <Cogitri "About docker-abuild: Just change"> but shouldn't `~/.abuild/abuild.conf` take priority?
2019-06-03 14:22:02 <danieli> right, yeah, installed about 150 for me, but most seems to make sense
2019-06-03 14:22:13 <Cogitri> <PureTryOut[m] "but shouldn't `~/.abuild/abuild."> The installing thing also happens on a clean system?
2019-06-03 14:22:20 <PureTryOut[m]> <Cogitri "The installing thing also happen"> Yes
2019-06-03 14:22:48 <PureTryOut[m]> danieli: what package are you installing actually?
2019-06-03 14:22:48 <Cogitri> <PureTryOut[m] "but shouldn't `~/.abuild/abuild."> Yup. Maybe just add cat /etc/abuild.conf to the docker script to see if that actually worked
2019-06-03 14:23:08 <danieli> PureTryOut[m]: all the ones you listed, i'm gonna have a quick look at them
2019-06-03 14:23:42 <PureTryOut[m]> Ah ok
2019-06-03 14:23:54 <PureTryOut[m]> Probably just install qt5-qt* to be sure
2019-06-03 14:25:35 <danieli> apk search qt5-* | grep -E "^qt5-" | grep -Eo "^(qt5-qt[^-]+)" | xargs apk add
2019-06-03 14:25:36 <danieli> lol
2019-06-03 14:26:10 <PureTryOut[m]> That would work haha
2019-06-03 14:26:20 <danieli> better hope so :')
2019-06-03 15:22:46 <Cogitri> PureTryOut: https://bugs.alpinelinux.org/issues/10535
2019-06-03 15:22:49 <Cogitri> Seems others hit it too
2019-06-03 15:23:33 <PureTryOut[m]> Yeah was bound to happen
2019-06-03 15:23:47 <PureTryOut[m]> All Qt programs using the broken library will be broken
2019-06-03 15:24:29 <_ikke_> Do we already know what lib is broken?
2019-06-03 15:26:00 <PureTryOut[m]> No
2019-06-03 15:42:09 <danieli> PureTryOut[m]: /usr/lib/libQt5WebKit.so.5 -> libQt5WebKit.so.5.9.1
2019-06-03 15:42:14 <danieli> /usr/lib/libQt5WebKitWidgets.so.5 -> libQt5WebKitWidgets.so.5.9.1
2019-06-03 15:42:22 <danieli> is this intentional?
2019-06-03 15:43:14 <Cogitri> Eh?
2019-06-03 15:43:26 <danieli> are they supposed to have different versions than the rest?
2019-06-03 15:43:43 <Cogitri> Well, QtWebKit isn't maintained anymore, so I guess there isn't something we can do about that
2019-06-03 15:43:58 <Cogitri> (And we should try dropping it from as much as possible as dep, it's super insecure by now)
2019-06-03 15:44:06 <Cogitri> Use QtWebEngine instead
2019-06-03 15:44:07 <danieli> ah, okay
2019-06-03 15:44:20 <danieli> no, i was just digging a bit
2019-06-03 15:44:22 <PureTryOut[m]> Yeah QtWebKit is kind of dead
2019-06-03 15:44:48 <Cogitri> Even so, QtWebKit doesn't cause the problem PureTryOut hits, because that complains about mixing 5.12 and 5.13
2019-06-03 15:45:23 <SpaceToast> didn't annulen make a new qtwebkit port
2019-06-03 15:45:28 <SpaceToast> I think it even got into the main repos
2019-06-03 15:45:42 <danieli> Cogitri: yeah, i am aware, but it stuck out like a sore thumb so i thought i'd ask about it
2019-06-03 15:46:08 <danieli> i haven't been very into the qt ecosystem for a number of years
2019-06-03 15:46:19 <Cogitri> Ah, alright
2019-06-03 15:46:32 <Cogitri> SpaceToast: Yes, but that thing is also dead since Juli 2017
2019-06-03 15:46:46 <SpaceToast> it's on the qt git, did he say he was dropping it?
2019-06-03 15:46:51 <SpaceToast> or maybe it's just "stable" atm?
2019-06-03 15:47:13 <[[sroracle]]> annulen is working on it again
2019-06-03 15:47:13 <Cogitri> I don't think a browser (engine) can be stable :)
2019-06-03 15:47:15 <[[sroracle]]> https://github.com/annulen/webkit/commits/qtwebkit-stable
2019-06-03 15:47:33 <SpaceToast> [[sroracle]]++ :)
2019-06-03 15:48:15 <Cogitri> Oh,  https://code.qt.io/cgit/qt/qtwebkit.git/log seemed dead to me
2019-06-03 15:48:42 <Cogitri> And his GH repo was stalled for some time too
2019-06-03 15:49:27 <SpaceToast> I'm not sure if his repo's the one we use though...
2019-06-03 15:49:34 <Cogitri> Migrating to QtWebengine doesn't seem like a bad idea though, even if it's only for upstream support
2019-06-03 15:49:51 <SpaceToast> https://git.alpinelinux.org/aports/tree/community/qt5-qtwebkit/APKBUILD
2019-06-03 15:49:57 <SpaceToast> looks like we use the old links
2019-06-03 15:50:14 <SpaceToast> so maybe a bugs.a.o entry to migrate to annulen's repo
2019-06-03 16:11:04 <PureTryOut[m]> Ah got it, qt5-qtscript still refers to Qt 5.12.1
2019-06-03 16:12:35 <Cogitri> 👍
2019-06-03 16:13:04 <PureTryOut[m]> Going to try rebuilding it and see if it helps
2019-06-03 16:44:09 <ncopa> did anyone try to boot the 3.10 rc1?
2019-06-03 16:44:17 <ncopa> it does not seem to boot at all
2019-06-03 16:44:54 <Cogitri> mps: Could you try building webkit2gtk on armhf again?
2019-06-03 16:45:19 <Cogitri> ncopa: "the 3.10rc1" means some live medium?
2019-06-03 16:47:56 <danieli> i'll test
2019-06-03 16:49:16 <danieli> ncopa: boots fine in a VM
2019-06-03 16:49:22 <danieli> standard x86_64
2019-06-03 16:49:46 <danieli> (I used the iso)
2019-06-03 16:53:51 <ncopa> standard and virt seems to boot
2019-06-03 16:53:56 <ncopa> but extended not
2019-06-03 16:55:50 <ncopa> huh
2019-06-03 16:56:01 <ncopa> so its only in libvirt?
2019-06-03 16:56:05 <ncopa> muset have done something wrong
2019-06-03 16:57:11 <danieli> yup, extended boots too
2019-06-03 16:57:31 <ncopa> what about with uefi?
2019-06-03 16:57:39 <danieli> didn't test, it's always been a pain on alpine for me
2019-06-03 16:58:06 <ncopa> I just add -bios /usr/share/ovmf/bios.bin
2019-06-03 16:58:38 <danieli> yup, boots with grub
2019-06-03 16:58:45 <danieli> det fungerer
2019-06-03 16:59:10 <ncopa> the extended does not boot for me
2019-06-03 16:59:26 <danieli> x86_64 extended 3.10_rc1 boots fine both with and without efi for me
2019-06-03 16:59:31 <ncopa> hum
2019-06-03 16:59:32 <ncopa> ok
2019-06-03 17:00:46 <mps> Cogitri: armv7 or armhf?
2019-06-03 17:01:12 <Cogitri> armhf
2019-06-03 17:01:28 <Cogitri> Or did armv7 get stuck?
2019-06-03 17:03:02 <mps> armv7
2019-06-03 17:04:30 <ncopa> uefi with grub + lvm root gives warning/error messages
2019-06-03 17:04:32 <ncopa> but seems to work
2019-06-03 17:04:54 <danieli> i didn't install, i just booted the install medium
2019-06-03 17:06:12 <mps> Cogitri: right now have to go out, will try later at night
2019-06-03 17:16:21 <Cogitri> Thank you. Please build armv7 then :)
2019-06-03 17:21:41 <_ikke_> clandmeter: extended iso boots for me under qemu
2019-06-03 17:21:44 <_ikke_> ncopa: *
2019-06-03 17:29:22 <_ikke_> setup-alpine could not get a list of mirrors
2019-06-03 17:32:38 <_ikke_> temporary issue apparently
2019-06-03 17:44:30 <_ikke_> What should I do if xorg cannot find any screens under qemu?
2019-06-03 17:49:11 <Cogitri> Add a graphics card and install the respective xf86-video-* I guess
2019-06-03 17:55:01 <PureTryOut[m]> pr8447 should fix the Qt issue
2019-06-03 18:30:16 <_ikke_> Cogitri: I did add a graphics card, but it's still missing (-vga std)
2019-06-03 18:31:09 <_ikke_> Let me look at another example I hafve
2019-06-03 18:31:11 <_ikke_> have
2019-06-03 21:35:53 <mps> Cogitri: please tell me patch number of webkit2gtk
2019-06-03 21:37:14 <Cogitri> 8257
2019-06-03 21:38:26 <mps> ok
2019-06-03 21:43:43 <mps> let's see
2019-06-03 22:02:37 <mps> Cogitri: build failed. do you know where I can uplaod  3.4M log build file
2019-06-03 22:04:53 <mps> so removing 'cd $builddir' for APKBUILD's in community and testing is ok, but not in main?
2019-06-03 22:05:47 <SpaceToast> main has to be supported (and thus potentially have backports) for 2 years
2019-06-03 22:06:14 <SpaceToast> automatic cd $builddir was added last fall (or so?), so it'll be ok to do to main/ around the release of 3.13
2019-06-03 22:08:37 <mps> so, when we move packages from main or to it we have to add/remove these? Does that make sense?
2019-06-03 22:09:10 <SpaceToast> yeah, I think that's reasonable
2019-06-03 22:10:00 <mps> but it doesn't hurt to keep these lines for pkg's in community and testing?
2019-06-03 22:10:31 <mps> except alint will complain
2019-06-03 22:20:51 <Cogitri> Yup, it doesn't hurt
2019-06-03 22:20:57 <Cogitri> It's just unnecessary
2019-06-03 22:21:06 <Cogitri> <mps "cogitri: build failed. do you kn"> Github gists I guess
2019-06-03 22:23:01 <mps> uhm, I don't have GH account
2019-06-03 22:27:37 <Cogitri> Pack it in a tar and upload it at your favourite tempfile hostet then
2019-06-03 22:27:38 <mps> Cogitri: http://arvanta.net/mps/webkit2gtk-build.log.gz
2019-06-03 22:27:43 <Cogitri> Thank you
2019-06-03 22:27:59 <mps> np, thank you for hard work
2019-06-04 05:53:35 <north1> Can someone merge pr8349 so pytest is fixed ?
2019-06-04 08:35:25 <tru_tru> I am trying to use abuild inside a non privilege container (no suid allowed) and it fails because /usr/bin/abuild-apk -> abuild-sudo, and '---s--x--x    1 root     root         14040 Mar  5 11:52 /usr/bin/abuild-sudo'
2019-06-04 08:36:00 <tru_tru> is there any hope to work around this?
2019-06-04 08:39:13 <TBB_> I did some experiments on that some time ago, let me have a look if I can find my notes on the topic
2019-06-04 08:40:29 <tru_tru> abuild-apk add --wait 30 --repository /home/tru/packages/singularity-build --virtual .makedepends-singularity build-base -> Waiting for repository lock ERROR: Unable to lock database: Bad file descriptor
2019-06-04 08:40:44 <tru_tru> adding fakeroot does not help
2019-06-04 08:41:58 <TBB_> I wrote a tool for managing package builds and isolated roots and one of the last things I worked on was switching to user mode containers, but I remember running to a similar problem
2019-06-04 08:51:46 <tru_tru> the other packing system I am using rpm/apt do not require this feature, I am probably missing the reason of the suid setup.
2019-06-04 08:54:27 <TBB_> I don't know whether rpm does this but at least apt uses fakeroot doesn't it
2019-06-04 08:57:31 <tru_tru> fakeroot works fine in the container
2019-06-04 08:58:05 <tru_tru> Singularity> id
2019-06-04 08:58:05 <tru_tru> uid=2765(tru) gid=2765(Bis) groups=10(wheel),100,300(abuild),982,983,2765(Bis)
2019-06-04 08:58:09 <tru_tru> Singularity> fakeroot id
2019-06-04 08:58:11 <tru_tru> uid=0(root) gid=0(root) groups=10(wheel),100,300(abuild),982,983,2765(Bis)
2019-06-04 10:49:22 <_ikke_> Anything preventing https://github.com/alpinelinux/aports/pull/4843 from being applied?
2019-06-04 11:41:53 <tcely> _ikke_: there was a question to ncopa about pr4843 but it looks ready other than that.
2019-06-04 11:46:15 <andypost[m]> tcely it lacks if latest cves
2019-06-04 11:46:21 <TBB_> tru_tru: if I remember correctly I managed to build packages in usermode containers, but if the package built contained suid binaries, that caused problems
2019-06-04 11:47:51 <andypost[m]> Also php mongodb & couchbase needs upgrade
2019-06-04 11:51:18 <ncopa> hi
2019-06-04 11:53:25 <ncopa> _ikke_: i think you need to add -vga virtio to qemu
2019-06-04 11:54:31 <_ikke_> ncopa: At least removing nomodeset fixed it
2019-06-04 11:55:25 <tcely> hi ncopa & andypost[m]: is php7 backport ready or are we waiting for more patches / testing?
2019-06-04 12:16:47 <ncopa> pr4843 is for v3.7 right?
2019-06-04 12:17:08 <ncopa> we should probably move it to main if we intend to maintain older stable
2019-06-04 12:20:41 <andypost[m]> ncopa: php iterating fast on releases now (after php5 era), so not sure how to align it with Alpine releasses https://www.php.net/supported-versions.php
2019-06-04 12:23:45 <ncopa> andypost[m]: i guess the simplest is to keep it in community
2019-06-04 12:24:03 <andypost[m]> IMO it fits into community the best as well)
2019-06-04 12:24:59 <andypost[m]> basically because mostly 70% of monthly releases are security related
2019-06-04 12:27:46 <tru_tru> TBB_: that's also my conclusion, I was expecting a workaround :)_
2019-06-04 12:42:56 <PureTryOut[m]> _ikke_: when using `-vga virtio`, what graphics driver do you use?
2019-06-04 12:50:12 <_ikke_> PureTryOut[m]: I didn't use virtio yet
2019-06-04 12:50:41 <_ikke_> In the 3.8 vm, I didn't specify any graphics card at all and it worked
2019-06-04 12:52:55 <_ikke_> I installed xf86-video-modesetting and xf68-video-qxl
2019-06-04 12:55:31 <PureTryOut[m]> Oh. Qxl is completely broken for me
2019-06-04 12:55:48 <north1> thanks ncopa  for merging the pytest fix
2019-06-04 13:06:24 <PureTryOut[m]> 
ACTION uploaded an image: Screenshot_20190604_150538.png (20KB) < https://matrix.org/_matrix/media/v1/download/fam-ribbers.com/EfDUamqreDPuZpQHmDoYsjjm >

2019-06-04 13:06:25 <PureTryOut[m]> That is Qemu/KVM with the QXL driver...
2019-06-04 13:06:26 <north1> modern art driver
2019-06-04 13:06:27 <PureTryOut[m]> I guess. I don't think LightDM is supposed to look like this though
2019-06-04 13:06:48 <_ikke_> Hmm, something doesn't look right, no
2019-06-04 13:07:26 <PureTryOut[m]> I can't get Virtio to work at all, I have no clue which driver to use for that
2019-06-04 13:08:45 <_ikke_> let me try what I get
2019-06-04 13:12:35 <_ikke_> seems to work for me with -vga virtio
2019-06-04 13:12:40 <_ikke_> with lxdm / xfce4
2019-06-04 13:12:55 <PureTryOut[m]> What xf86-video package do you use?
2019-06-04 13:13:05 <_ikke_> qxl
2019-06-04 13:14:34 <PureTryOut[m]> With virtio? Well that one definitely isn't in use. I guess modesetting is doing the job there
2019-06-04 13:14:59 <_ikke_> trying to confirm
2019-06-04 13:16:10 <_ikke_> Seems to indeed use modesetting
2019-06-04 13:16:35 <PureTryOut[m]> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/v1/download/matrix.org/pFWbGZjawWVDlbpYoZILRlwy >

2019-06-04 13:16:43 <PureTryOut[m]> Xorg log with `-vga virtio` ☝️
2019-06-04 13:17:04 <_ikke_>  /dev/dri/card0:
2019-06-04 13:17:13 <_ikke_> open /dev/dri/card0: No such file or directory
2019-06-04 13:17:17 <_ikke_> That's what I had yesterday
2019-06-04 13:17:29 <_ikke_> That was fixed when I removed nomodesetting from the kernel parameters
2019-06-04 13:18:20 <_ikke_> But I guess that causes the modesetting driver to be used
2019-06-04 13:18:31 <PureTryOut[m]> I'm not yet sure how to do something like that on Alpine. Is Grub used?
2019-06-04 13:18:42 <_ikke_> extlinux
2019-06-04 13:19:01 <_ikke_> /etc/update-extlinux.conf
2019-06-04 13:19:05 <_ikke_> and then update-extlinux
2019-06-04 13:20:22 <PureTryOut[m]> Thanks
2019-06-04 13:21:26 <PureTryOut[m]> I don't see nomodesetting in that file?
2019-06-04 13:22:15 <_ikke_> It was in the default_kernel_opts for me
2019-06-04 13:22:47 <PureTryOut[m]> There is no such variable for me
2019-06-04 13:25:16 <TBB> tru_tru, if I come up with anything I'll let you know :)
2019-06-04 13:30:42 <_ikke_> PureTryOut[m]: hmm, strange
2019-06-04 14:03:48 <asriel[m]> Howdy everyone, just a question to ask.
2019-06-04 14:04:33 <asriel[m]> I want to upstream a package from Alpine, but someone already submitted the package, however the package in the currently opened PR seems to be broken on compile.
2019-06-04 14:04:59 <asriel[m]> Is it a good thing to make another PR in respond to that? Or just wait for the maintainer?
2019-06-04 14:06:03 <asriel[m]> (or just suggest and help the maintainer)
2019-06-04 14:14:05 <ncopa> asriel[m]: good question. i would probably recommend try suggestions and help the maintainer
2019-06-04 14:14:24 <ncopa> and if you dont get any response within reasonable time, you create a new PR
2019-06-04 14:17:20 <asriel[m]> ncopa: How that would be "reasonable time"?
2019-06-04 14:17:28 <asriel[m]> Maybe a few days or just weeks?
2019-06-04 14:20:22 <ncopa> a few days to a week i'd guess
2019-06-04 14:22:26 <mps> I post mail and wait at least week for anything not urgent
2019-06-04 14:24:08 <mps> last night I asked about removing 'cd $builddir' in APKBUILD for pkg's in community and testing, and keep it for pkg's in main
2019-06-04 14:25:52 <mps> I'm not sure this is good idea because we then have add these lines when moving packages to main and remove them when moving from main
2019-06-04 14:27:03 <mps> imo, it is better to keep them till the main ready for change
2019-06-04 14:27:53 <PureTryOut[m]> It's not like moving packages between that repos happens that often
2019-06-04 14:27:54 <PureTryOut[m]> *between those repos
2019-06-04 14:28:32 <mps> but it happens
2019-06-04 14:29:32 <PureTryOut[m]> Sure, but they're going to be removed eventually. It's not that much work to add or remove them depending on what repo they're moved too, so let's just do it now
2019-06-04 14:33:47 <mps> this 'eventually' are two years in future at least, and till then some number of packages will be moved to main. and every one will need these lines to be added three times, prepare, build and package at least
2019-06-04 14:35:10 <PureTryOut[m]> I still don't think it's a lot tbh
2019-06-04 14:35:54 <ncopa> mps: i tend to agree with you
2019-06-04 14:36:10 <ncopa> keeping cd "$buildir" does not hurt
2019-06-04 14:37:18 <mps> PureTryOut[m]: small changes are always better, especially those which are not needed
2019-06-04 14:38:29 <PureTryOut[m]> I'm fine either way btw, I just don't really agree with the argument 😉
2019-06-04 14:38:53 <mps> ncopa: also I see it as such, if it doesn't hurt and saves us from some confusion (however it small) we should keep them
2019-06-04 14:39:40 <_ikke_> For new packages it should in any case be safe to not add them in the first place
2019-06-04 14:41:27 <ncopa> mps: but i dont have strong opinion about it either. some people have been eager to remove them. i asked to keep them for "main" to reduce friction when backporting
2019-06-04 14:42:30 <ncopa> i dont want create a flamewar about it :)
2019-06-04 14:43:11 <mps> I don't think we will have flamewar about it
2019-06-04 14:43:52 <mps> at the end it will be on maintainer to decide what to do
2019-06-04 14:43:56 <_ikke_> I think the reason that people are eager to remove it (at least counts for me) is that it removes boilerplate and allows you to focus on things that matter
2019-06-04 14:44:10 <_ikke_> (makes it a bit easier to review)
2019-06-04 14:45:24 <mps> well, understand, but if maintainer want to keep these lines and someone else deletes them I fear that some maintainers will feel 'offended' by this
2019-06-04 14:46:06 <PureTryOut[m]> Offended by having `cd "$builddir"` removed? Really?
2019-06-04 14:46:26 <mps> we had something similar some time ago when someone changes something without asking maintainer
2019-06-04 14:46:33 <ncopa> bikeschedding syndrome
2019-06-04 14:47:34 <mps> PureTryOut[m]: some people feel offended and that's the fact, even for more benign things
2019-06-04 14:48:11 <mps> personally I don't care, to me all is ok
2019-06-04 14:48:13 <ncopa> more people will have opinion because more people feel they have competence about it, and they want help
2019-06-04 14:49:39 <mps> some simple rule of 'best practice' note will be enough, imo
2019-06-04 14:49:53 <mps> s/of /or /
2019-06-04 14:49:53 <alpine-meetbot> mps meant to say: some simple rule or 'best practice' note will be enough, imo
2019-06-04 14:49:57 <ncopa> personally i think commenting it during PR "add it" or "remove it" takes more time than just deal with it when doing backport
2019-06-04 14:50:04 <ncopa> yes, i think thats my conclusion as well
2019-06-04 14:50:08 <ncopa> document how we want it
2019-06-04 14:50:27 <north1> please^
2019-06-04 14:50:39 <ncopa> where we doc it?
2019-06-04 14:51:08 <ncopa> should we create a developer FAQ?
2019-06-04 14:51:09 <SpaceToast> developer-handbook is likely a good place for that, though I haven't started on it yet
2019-06-04 14:51:12 <SpaceToast> a general "Best Practices" thing?
2019-06-04 14:51:26 <north1> docs.alpinelinux.org or somewhere official sounding ? as long as i can read it and adjust atools according i don't really mind
2019-06-04 14:51:28 <mps> SpaceToast: that sounds fine
2019-06-04 14:51:38 <north1> s/according/accordingly/
2019-06-04 14:51:38 <alpine-meetbot> north1 meant to say: docs.alpinelinux.org or somewhere official sounding ? as long as i can read it and adjust atools accordingly i don't really mind
2019-06-04 14:51:45 <SpaceToast> I'll try and get that bootstrapped today
2019-06-04 14:51:54 <SpaceToast> "Best Practices" sounds like a good starting point, even if it gets moved around later :)
2019-06-04 14:51:57 <ncopa> meanwhile, is https://wiki.alpinelinux.org/wiki/Package_policies ok?
2019-06-04 14:52:13 <mps> ncopa: I agree
2019-06-04 14:52:30 <SpaceToast> speaking of...
2019-06-04 14:52:33 <SpaceToast> ncopa: how do we handle -static?
2019-06-04 14:52:42 <SpaceToast> because there are static libraries and static applications
2019-06-04 14:52:50 <SpaceToast> and in some cases it can be both (e.g curl)
2019-06-04 14:53:12 <ncopa> in general, we build everything dynamic, whenever possible
2019-06-04 14:53:20 <ncopa> we add -static on request
2019-06-04 14:53:24 <ncopa> or when needed
2019-06-04 14:53:39 <SpaceToast> I'd prefer at least libraries have -static variants in general, but that's not really what I'm asking
2019-06-04 14:53:52 <SpaceToast> let's say we get a request for a statically linked curl (binary) and libcurl.a
2019-06-04 14:53:57 <SpaceToast> which one gets to be curl-static?
2019-06-04 14:54:08 <ncopa> oh, i see
2019-06-04 14:54:11 <ncopa> good question
2019-06-04 14:54:18 <SpaceToast> it's the same namespace, and it's caused confusion in the past
2019-06-04 14:54:35 <SpaceToast> (I name curl specifically, because there was a PR that built curl statically, but everyone seemed to think it was about adding .a)
2019-06-04 14:54:38 <ncopa> i guess we coudl do: curl + curl-libs + curl-libs-static
2019-06-04 14:54:52 <Cogitri> Sounds good to me
2019-06-04 14:54:54 <ncopa> and curl-static
2019-06-04 14:55:04 <SpaceToast> okay, two parts with that solution:
2019-06-04 14:55:14 <SpaceToast> 1. my understanding is we currently don't want sub-sub-packages; is this an exception?
2019-06-04 14:55:28 <SpaceToast> 2. would $bin-libs be a generic thing for non-library-package-library-subpackage stuff?
2019-06-04 14:56:19 <ncopa> 1. I consider "libs-static" a subpackage and not a sub-sub package
2019-06-04 14:56:48 <ncopa> 2. ?
2019-06-04 14:57:03 <artok> libs-static are dev files
2019-06-04 14:57:09 <SpaceToast> specification on 2:
2019-06-04 14:57:13 <artok> kind of
2019-06-04 14:57:18 <ncopa> artok: correct
2019-06-04 14:57:23 <SpaceToast> there are two general types of "primary packages" - library-only and binary-only
2019-06-04 14:57:29 <SpaceToast> in library-only packages, we name them libsomething
2019-06-04 14:57:47 <SpaceToast> if binary-only packages have libraries as well, do we then standardize putting those libraries into $bin-libs?
2019-06-04 14:57:53 <SpaceToast> (rather than lib$bin)
2019-06-04 14:57:57 <SpaceToast> i.e curl-libs vs libcurl
2019-06-04 14:58:02 <ncopa> yes
2019-06-04 14:58:04 <SpaceToast> ok
2019-06-04 14:58:16 <ncopa> but it depends a bit on upstream
2019-06-04 14:58:20 <SpaceToast> would it make sense to also have default functions for $bin-libs and $bin-libs-static?
2019-06-04 14:58:37 <ncopa> we try keep $pkgname same as upstream name
2019-06-04 14:58:45 <ncopa> so for example libxml2
2019-06-04 14:58:58 <ncopa> it does not make any sense to do libxml2-libs
2019-06-04 14:59:05 <SpaceToast> ah ok, so of upstream calls themselves "xml" and there's a library for it, it's "xml-libs"
2019-06-04 14:59:13 <SpaceToast> if upstream calls themselves "libxml", we call it "libxml"
2019-06-04 14:59:27 <SpaceToast> thanks, that clears that up :)
2019-06-04 14:59:29 <ncopa> instead we have libxml2 with the libs, and ship the binaries as libxml2-tools
2019-06-04 14:59:49 <ncopa> but to be honest, i often follow what fedora does
2019-06-04 15:00:14 <ncopa> and it appears that fedora often -libs a subpackage
2019-06-04 15:00:39 <ncopa> while debian tend to do lib$pkgname$major or similar
2019-06-04 15:01:46 <ncopa> in the early days i did lib$pkgname similar to debian, but later switched to do $pkgname-libs
2019-06-04 15:02:20 <ncopa> its sort of nice to do things like `cp $pkgname-*`
2019-06-04 15:02:28 <SpaceToast> okay, so to summarize
2019-06-04 15:02:45 <ncopa> i never bothered to change the old, previous lib$pkgname
2019-06-04 15:02:47 <SpaceToast> for library-primary packages, lib$lib + lib$lib-tools if there are binaries
2019-06-04 15:02:58 <SpaceToast> for binary-primary packages, $bin + $bin-libs if there are libraries
2019-06-04 15:03:14 <ncopa> i'd rather say it depends on upstream
2019-06-04 15:03:30 <SpaceToast> well if upstream calls themselves "libx" it's probably fair to say they're library-primary
2019-06-04 15:03:39 <SpaceToast> and that seems to be the main thing that you're mentioning
2019-06-04 15:03:40 <ncopa> if upstream is named lib* then we go for libraryp
2019-06-04 15:03:46 <ncopa> library-primary
2019-06-04 15:03:51 <SpaceToast> yeah :)
2019-06-04 15:04:10 <SpaceToast> lib$lib-static for static libs, lib$lib-tools-static for lib-primary static binaries; vs $bin-static for static bins, $bin-libs-static for static libs
2019-06-04 15:04:17 <SpaceToast> that seems nice and consistent
2019-06-04 15:04:31 <ncopa> yeah
2019-06-04 15:06:41 <ncopa> this said, i dont think we should start ask contributors to change naming to the above while they are doing completely unrelated changes
2019-06-04 15:06:49 <ncopa> for example version upgrade
2019-06-04 15:06:55 <SpaceToast> I agree, I find that kind of request distracting
2019-06-04 15:07:00 <SpaceToast> I already spoke to north1 about it
2019-06-04 15:07:32 <SpaceToast> that's actually why I made pr8197 - just get it done with and stop worrying :)
2019-06-04 15:07:45 <ncopa> i think the same applies to `cd $builddir` but i dont want make a big deal of it
2019-06-04 15:07:54 <SpaceToast> yeah
2019-06-04 15:08:03 <SpaceToast> it should just be a best-practice and primarily applied to new packages
2019-06-04 15:08:12 <SpaceToast> older packages can be bulk-processed at some point between releases
2019-06-04 15:08:41 <HRio> are PRs pr7474 & pr8221 too late as we are already at rc1?
2019-06-04 15:08:54 <ncopa> HRio: no
2019-06-04 15:08:58 <ncopa> thanks for the reminder
2019-06-04 15:09:01 <HRio> OK thanks
2019-06-04 15:09:20 <ncopa> well maybe pr8221 is
2019-06-04 15:09:34 <HRio> k
2019-06-04 15:09:39 <ncopa> i mean, i tend to downprioritize anything testing/* at this point
2019-06-04 15:10:00 <ncopa> but if there is a good reason to why we may want include it in 3.10 release, then np
2019-06-04 15:10:03 <HRio> would be nice to have the kernel part in, so I can test on more fancy HW
2019-06-04 15:10:17 <ncopa> specially if you have a clear plan for it and intend to follow up
2019-06-04 15:17:09 <HRio> yes need rasdaemon on the systems I am running Alpine bare metal on. Migrating from Debian (and mcelog) to Alpine also on metal.
2019-06-04 15:18:04 <mps> oh, is to late to change some kernel config options? I narrowed problem with some ARM boards which needs some options enable in armhf/armv7 kernel
2019-06-04 15:19:04 <HRio> simply too much races during boot with systemd in debian stable, you never know if shutdown or boot will succeed
2019-06-04 15:20:07 <mps> and, did anyone reviewed ifupdown patch https://patchwork.alpinelinux.org/patch/4898/
2019-06-04 15:20:54 <mps> (except for 'cd $builddir' removal, I need to fix this)
2019-06-04 15:21:19 <SpaceToast> mps: have you tested it built?
2019-06-04 15:21:27 <SpaceToast> I've never had ifupdown (as it is now) actually work for me
2019-06-04 15:21:37 <SpaceToast> if it actually starts to function, I'm all for it :)
2019-06-04 15:21:40 <mps> SpaceToast: ifupdown? yes
2019-06-04 15:22:09 <SpaceToast> alright :)
2019-06-04 15:22:10 <mps> but not sure with or without 'cd $builddir'
2019-06-04 15:22:24 <SpaceToast> it primarily seems to misbehave because of dhcpd detection iirc
2019-06-04 15:22:35 <mps> I was concentrated on patches to upstream
2019-06-04 15:23:57 <mps> someone marked it as "Under review" so I didn't posted fix for 'cd $builddir' expecting comments
2019-06-04 16:18:50 <PureTryOut[m]> Could somebody review this pr https://github.com/alpinelinux/aports/pull/8467?
2019-06-04 16:18:58 <PureTryOut[m]> It's a new aport in community, but since qt5-qtbase has to depend on it that's the only way to do it
2019-06-04 16:19:25 <PureTryOut[m]> CI is still going through but x86* succeeded and arm* will most definitely too
2019-06-04 16:19:37 <SpaceToast> PureTryOut[m]: what does upstream think?
2019-06-04 16:19:45 <SpaceToast> qt4 in general is supposed to be phased out in general
2019-06-04 16:20:03 <PureTryOut[m]> Yeah I don't care about qt4
2019-06-04 16:20:05 <PureTryOut[m]> that PR doesn't touch it
2019-06-04 16:20:14 <PureTryOut[m]> what do you mean with upstream in this case?
2019-06-04 16:20:18 <SpaceToast> plasma and qt
2019-06-04 16:20:30 <SpaceToast> plasma expects qt without suffix, qt defaults to including the suffix
2019-06-04 16:20:34 <PureTryOut[m]> well it's an official Qt tool for one
2019-06-04 16:20:41 <SpaceToast> yes, is it still maintained?
2019-06-04 16:20:53 <PureTryOut[m]> As far as I know, I'll check to be sure
2019-06-04 16:20:56 <SpaceToast> the url= is a 404
2019-06-04 16:21:05 <SpaceToast> https://code.qt.io/cgit/qt/qtchooser.git
2019-06-04 16:21:10 <SpaceToast> "No repositories found"
2019-06-04 16:22:05 <SpaceToast> looks like it's moved to https://code.qt.io/cgit/qtsdk/qtchooser.git/
2019-06-04 16:22:08 <PureTryOut[m]> Also the -qt5 suffix is done by our package, not by Qt
2019-06-04 16:22:09 <danieli> qtchooser is called qtchooser on other distros too
2019-06-04 16:22:19 <SpaceToast> last commit is from about a year ago
2019-06-04 16:22:33 <SpaceToast> ah, I see
2019-06-04 16:23:42 <PureTryOut[m]> Tbh since we don't really want Qt4 anymore anyway, I don't mind just stopping symlinking Qt binaries to the -qt5 suffix instead. This tool is useful however if you want to use a locally compiled version or a pre-release
2019-06-04 16:23:43 <SpaceToast> personally, I would prefer to change the packages to not use -qt5, then, but that might not be politically feasible
2019-06-04 16:23:56 <SpaceToast> also, there's no telling what happens if/when qt6 comes around
2019-06-04 16:24:27 <PureTryOut[m]> qtchooser is useful for when qt6 is released 😉
2019-06-04 16:24:41 <SpaceToast> well I don't mind adding qtchooser, obviously
2019-06-04 16:24:52 <SpaceToast> what I find questionable is making qt5-qtbase depend on it
2019-06-04 16:25:17 <SpaceToast> I understand it's done to make plasma5 work, but it just feels icky, esp. given the above circumstances
2019-06-04 16:25:18 <PureTryOut[m]> I updated the website url btw
2019-06-04 16:25:39 <PureTryOut[m]> Not just Plasma, but that's the most obvious one atm
2019-06-04 16:26:15 <PureTryOut[m]> I guess it could be an optional dependency. All packages that require it should then depend on qt5-qtbase and qtchooser I guess?
2019-06-04 16:27:06 <SpaceToast> with a comment saying why qtchooser is in there
2019-06-04 16:27:09 <SpaceToast> that might be more sane, imo
2019-06-04 16:27:22 <SpaceToast> but I'd recommend asking ncopa specifically (and potentially waiting for 3.10's release)
2019-06-04 16:28:12 <SpaceToast> besides that LGTM
2019-06-04 16:29:03 <PureTryOut[m]> Well, ncopa what do you think (if you read our short conversation here)? I'm fine either way tbh, although I prefer not having packages (except for Qt5) depend on qtchooser directly
2019-06-04 16:46:05 <_ikke_> Is there any reason to *have* nomodesetting?
2019-06-04 16:46:10 <tcely> PureTryOut[m]: what do you think of having qtX-qtbase all provide qtbase then using install_if="qtbase" for qtchooser?
2019-06-04 16:46:34 <SpaceToast> _ikke_: nomodesetting can be nice if you have no idea what kind of environment you'll be booting in
2019-06-04 16:47:06 <_ikke_> right
2019-06-04 16:47:15 <_ikke_> But in general it's fine to do without
2019-06-04 16:47:15 <PureTryOut[m]> tcely: all subpackages of qt5-qtbase provide qtbase? Yeah that sounds ok to me
2019-06-04 16:47:20 <SpaceToast> modeset is the kernel's ability to utilize in-kernel graphics drivers to provide full-resolution tty and such
2019-06-04 16:47:20 <_ikke_> (ie, enable modesetting)
2019-06-04 16:47:30 <SpaceToast> (even without X and co)
2019-06-04 16:47:38 <tcely> PureTryOut[m]: I was thinking all versions of qt having qtbase probide qtbase
2019-06-04 16:47:39 <SpaceToast> but some devices are... special, and some are straight up headless
2019-06-04 16:47:43 <tcely> provide
2019-06-04 16:47:56 <SpaceToast> if you're able to remove `nomodeset` while booting, it's probably fine for you to do :)
2019-06-04 16:48:35 <PureTryOut[m]> tcely: you mean qt4 too?
2019-06-04 16:48:36 <PureTryOut[m]> or do you mean stuff like qt5-qtdeclarative too?
2019-06-04 16:49:05 <tcely> PureTryOut[m]: qt4-qtbase, qt5-qtbase, qt6-qtbase should each provide qtbase
2019-06-04 16:49:23 <PureTryOut[m]> Ah yeah ok
2019-06-04 16:49:25 <PureTryOut[m]> Sounds sane to me
2019-06-04 16:49:42 <PureTryOut[m]> Although then you can still not install any of them together. Not that anybody wants that probably
2019-06-04 16:49:47 <north1> what is the big whoop for not just adding qtchooser to depends= of them
2019-06-04 16:49:49 <_ikke_> I just wonder why for my 3.8 vm, where nomodeset is active, it still manages to switch to a higher resolution and have a graphics card available (in qemu)
2019-06-04 16:50:26 <_ikke_> while in 3.10, I need to remove nomodeset
2019-06-04 16:51:13 <SpaceToast> are you sure nomodeset is active in your 3.8 vm?
2019-06-04 16:51:16 <SpaceToast> check /proc/cmdline
2019-06-04 16:52:05 <_ikke_> nomodeset is in there
2019-06-04 16:52:44 <tcely> PureTryOut[m]: why would you not be able to install qt4-qtbase and qt5-qtbase with them both providing something?
2019-06-04 16:53:06 <PureTryOut[m]> Oh, I thought that would conflict
2019-06-04 16:53:06 <PureTryOut[m]> Maybe not
2019-06-04 16:53:13 <SpaceToast> that's indeed very strange
2019-06-04 16:53:14 <PureTryOut[m]> maxice8: you'll have to ask SpaceToast
2019-06-04 16:53:32 <tcely> There would be an issue if I tried to add qtbase (which to choose?) but I don't see why they would conflict
2019-06-04 16:53:57 <SpaceToast> _ikke_: does your 3.8 vm use X?
2019-06-04 16:54:10 <north1> PureTryOut: They won't, they can be installed in parallel
2019-06-04 16:54:11 <_ikke_> It has X installed
2019-06-04 16:54:19 <PureTryOut[m]> Ah good
2019-06-04 16:54:19 <SpaceToast> and if so, if you disable starting X (your DM, etc), do you still get high resolution?
2019-06-04 16:54:20 <_ikke_> but my 3.10 vm as well
2019-06-04 16:54:27 <PureTryOut[m]> I like the install_if approach then
2019-06-04 16:54:32 <_ikke_> it doesn't start by default
2019-06-04 16:54:34 <SpaceToast> nomodeset only really has an effect up until X is started
2019-06-04 16:54:38 <SpaceToast> wow, that's really strange
2019-06-04 16:54:43 <SpaceToast> it suggests the kernel's ignoring the line
2019-06-04 16:54:56 <SpaceToast> maybe a bug that was fixed? I don't keep up with details within the kernel
2019-06-04 16:55:17 <_ikke_> One difference I see is that in the 3.8 vm, the resolution changes right before it mentions loading modules
2019-06-04 16:55:27 <_ikke_> I don't see that line in my 3.10 vm
2019-06-04 16:56:07 <SpaceToast> that's very strange
2019-06-04 16:56:09 <PureTryOut[m]> Does `install_if` work outside of `package()` btw? I've only used it in that function really
2019-06-04 16:57:14 <tcely> install_if works in all split functions
2019-06-04 16:57:28 <_ikke_> SpaceToast: Oh, it does mention loading modules
2019-06-04 16:57:29 <tcely> you can assign it globally for package() to use
2019-06-04 16:58:14 <_ikke_> SpaceToast: when I have nomodeset active, in my 3.10 vm /dev/dri/card0 is not available (and X cannot start)
2019-06-04 16:58:19 <PureTryOut[m]> So I still have to specify it in `package()` then?
2019-06-04 16:58:31 <SpaceToast> _ikke_: to be honest, I could try and find the actual code for nomodeset and know for sure (how it's supposed to go and whether it was changed or not)
2019-06-04 16:58:39 <SpaceToast> but that sounds like a lot of effort ^^;;
2019-06-04 16:58:48 <_ikke_> Yup
2019-06-04 16:58:50 <SpaceToast> what I think would be reasonable is removing nomodeset from the extended iso
2019-06-04 16:59:04 <SpaceToast> nomodeset is useful for very specific old and/or embedded devices
2019-06-04 16:59:09 <SpaceToast> that I don't think would be using extended
2019-06-04 16:59:14 <_ikke_> Was just curious to find where the difference comes from
2019-06-04 16:59:31 <SpaceToast> I suspect either a bug getting fixed, a bug getting introduced, or just a change in behavior
2019-06-04 16:59:39 <tcely> PureTryOut[m]: you can specify in package or at the top of the file it doesn't matter, the variable is reset for every split function other than package though
2019-06-04 16:59:46 <SpaceToast> wait, actually...
2019-06-04 16:59:55 <SpaceToast> _ikke_: do you force-load any modules in either vm?
2019-06-04 17:00:01 <PureTryOut[m]> ah ok
2019-06-04 17:00:06 <_ikke_> SpaceToast: I checked, I could not find anything
2019-06-04 17:00:18 <SpaceToast> oh!!!
2019-06-04 17:00:22 <_ikke_> /etc/modules and /etc/modules.load.d
2019-06-04 17:00:39 <PureTryOut[m]> Should I still care about qt4? Or is just qt5 enough for now?
2019-06-04 17:00:48 <SpaceToast> _ikke_: it's also modules= on the command line and /etc/modprobe.d
2019-06-04 17:00:59 <SpaceToast> I just noticed /etc/modprobe.d/kms.conf
2019-06-04 17:01:00 <north1> PureTryOut: IMO just Qt5
2019-06-04 17:01:09 <tcely> what does care about mean in this context?
2019-06-04 17:01:10 <SpaceToast> which enables modesetting for radeon, i915 and nouveau
2019-06-04 17:01:18 <SpaceToast> does your 3.10 vm have that?
2019-06-04 17:01:30 <PureTryOut[m]> Ok
2019-06-04 17:01:34 <SpaceToast> and what's the `modules=` line in /proc/cmdline?
2019-06-04 17:01:39 <PureTryOut[m]> Benefit of install_if is that qtchooser can start in testing for now
2019-06-04 17:02:05 <_ikke_> sd-mod,usb-storage,ext4
2019-06-04 17:02:20 <SpaceToast> (and those of 3.8, please :) )
2019-06-04 17:02:21 <_ikke_> same in both cases
2019-06-04 17:02:31 <SpaceToast> ok, how about /etc/modprobe.d/kms.conf?
2019-06-04 17:02:35 <_ikke_> checking
2019-06-04 17:03:12 <north1> Speaking of Qt4
2019-06-04 17:03:13 <north1> https://github.com/alpinelinux/aports/pull/7712
2019-06-04 17:03:14 <_ikke_> only difference is one addition line of nouveau
2019-06-04 17:03:18 <north1> ^ qt-creator upgrade to move it to Qt5
2019-06-04 17:03:20 <_ikke_> don't think that's the difference
2019-06-04 17:03:22 <SpaceToast> hmm
2019-06-04 17:03:43 <SpaceToast> either way, what I think is happening is that your 3.8 vm ultimately gets modesetting enabled, somehow
2019-06-04 17:03:59 <_ikke_> wondering if there is a way to verify
2019-06-04 17:06:03 <PureTryOut[m]> I updated pr8467 to make qtchooser use `install_if` and have qt5-qtbase provide `qtbase` rather than having qt5-qtbase depend directly on qtchooser
2019-06-04 17:06:14 <_ikke_> vt8623fb has been added in /etc/modprobe.d/blacklist.conf
2019-06-04 17:06:55 <MY_R> SpaceToast "/etc/mkinitfs/mkinitfs.conf" got kms there?
2019-06-04 17:07:27 <MY_R> sorry, _ikke_ ^
2019-06-04 17:08:34 <_ikke_> let me check
2019-06-04 17:09:07 <_ikke_> both are equal
2019-06-04 17:09:19 <tcely> PureTryOut[m]: Please add the provide for qt4-qtbase too
2019-06-04 17:09:20 <_ikke_> dmesg 3.10: http://tpaste.us/eeyW
2019-06-04 17:09:53 <PureTryOut[m]> Do we care about qt4?
2019-06-04 17:09:54 <_ikke_> dmesg 3.8: http://tpaste.us/kZo4
2019-06-04 17:11:26 <tcely> I'd prefer the consistency. It doesn't make sense to put in the effort to have qtchooser if I can't choose qt4, that feels broken to me.
2019-06-04 17:11:33 <PureTryOut[m]> Sure
2019-06-04 17:11:59 <_ikke_> why do you want to choose one over the other?
2019-06-04 17:13:05 <PureTryOut[m]> Let me see if I can fix the licenses as well
2019-06-04 17:14:08 <tcely> _ikke_: I see it much like having a pychooser or select-editor tool. I'd be upset by not being able to choose python2 or vi in either of those too.
2019-06-04 17:14:11 <north1> PureTryOut: Hopefully not
2019-06-04 17:14:15 <PureTryOut[m]> What do you mean?
2019-06-04 17:14:27 <north1> PureTryOut: Hopefully we do not care about keeping Qt4 on life support
2019-06-04 17:14:32 <PureTryOut[m]> Oh you're talking about having to care about Qt4
2019-06-04 17:14:39 <north1> PureTryOut: yes, sorry i wasn't clear
2019-06-04 17:16:52 <PureTryOut[m]> You'll have to fight with tcely about that 😛
2019-06-04 17:17:07 <MY_R> _ikke_, did you try regenerate kernel ramdisk? "mkinitfs" maybe modules sit still there?
2019-06-04 17:18:02 <_ikke_> MY_R: let me try
2019-06-04 17:21:55 <_ikke_> still the same after mkinitfs on the 3.8 vm
2019-06-04 17:23:05 <_ikke_> hmm, my 3.8 vm has fbcon as module loaded
2019-06-04 17:23:17 <MY_R> btw anyone know why "initramfs-vanilla" in boot is readable by everyone? :\
2019-06-04 17:24:05 <Cogitri> Why wouldn't it be?
2019-06-04 17:25:01 <MY_R> Cogitri, people cna hold there luks keys...
2019-06-04 17:25:15 <MY_R> and alpine support that officialy by: /etc/mkinitfs/features.d/cryptkey.files
2019-06-04 17:30:53 <PureTryOut[m]> Ha, ain't this fun. The Qt4 APKBUILD installs it's binaries directly to `/usr/bin` without the suffix. To make it work with qtchooser, I have to change that directory
2019-06-04 17:31:05 <_ikke_> SpaceToast: confirmed, it's fbcon that's doing it (which is no longer available)
2019-06-04 17:31:07 <Cogitri> <MY_R "cogitri, people cna hold there l"> Oh, didn't know that
2019-06-04 17:31:12 <PureTryOut[m]> To stay compatible with current applications depending on Qt4 it'll have to depend qtchooser
2019-06-04 17:31:26 <PureTryOut[m]> And not even that, Qt4 has to be configured as the default
2019-06-04 17:31:34 <north1> lol
2019-06-04 17:31:53 <SpaceToast> _ikke_: nice on finding that out :)
2019-06-04 17:32:29 <_ikke_> funny thing, without fbcon, I only get a blinking cursor, I don't see anything rendered
2019-06-04 17:32:41 <_ikke_> only after modprobe fbcon, I see text again
2019-06-04 17:33:11 <tcely> PureTryOut[m]: ok. Rewriting qt is not worth the effort if it's going away.
2019-06-04 17:33:21 <PureTryOut[m]> tcely: so we can't really make qtchooser work with Qt4 without having to update all the packages depending on Qt4...
2019-06-04 17:33:28 <PureTryOut[m]> Ah you're reading along, sorry
2019-06-04 17:34:57 <tcely> no problem, a few more notifications won't make a bit of difference ;-)
2019-06-04 17:36:13 <PureTryOut[m]> I'll just do Qt5 then, and it'll be useful once Qt6 hits
2019-06-04 17:37:54 <PureTryOut[m]> Should be good now, once CI goes through
2019-06-04 17:38:16 <PureTryOut[m]> And let's slowly look into getting rid of Qt4 stuff
2019-06-04 17:38:17 <tcely> when is qt4 EOL ?
2019-06-04 17:39:11 <Cogitri> March 15 2019
2019-06-04 17:39:26 <Cogitri> https://reviews.freebsd.org/D17741
2019-06-04 17:39:38 <PureTryOut[m]> I can update a package from Qt4 to Qt5, but it requires switching to the latest git master rather than a release...
2019-06-04 17:39:59 <PureTryOut[m]> Qt4 itself is EOL since 2015
2019-06-04 17:40:11 <Cogitri> Has been dead upstream since 2015: https://www.phoronix.com/scan.php?page=news_item&px=qt-4.8.7-qt4-update-released
2019-06-04 17:40:18 <Cogitri> <PureTryOut[m] "Qt4 itself is EOL since 2015"> Ah, faster than me :P
2019-06-04 17:40:43 <PureTryOut[m]> Is updating stuff to unreleased versions good if it ensures Qt5 support? In this case I'm talking about a package in testing, so it might be dropped instead?
2019-06-04 17:41:06 <tcely> Does it have a maintainer?
2019-06-04 17:41:27 <PureTryOut[m]> Yes
2019-06-04 17:41:27 <north1> PureTryOut: i'm doing it right now
2019-06-04 17:42:05 <PureTryOut[m]> I guess I'll just notify the maintainer in the PR
2019-06-04 17:43:49 <_ikke_> Hmm, my mouse seems very jumpy / irregular when I start x (lxdm / xfce4)
2019-06-04 17:57:44 <_ikke_> ok, adding a usb tablet device fixed it for me
2019-06-04 18:06:13 <tcely> ugh. #! /bin/sh <- I'm going to guess the space is a problem.
2019-06-04 18:06:33 <_ikke_> hmmmm
2019-06-04 18:06:39 <_ikke_> '_'
2019-06-04 18:08:05 <tcely> a quick test says I'm wrong
2019-06-04 18:08:07 <tcely> hmm.
2019-06-04 18:26:37 <tcely> Is GH @J0WI here?
2019-06-04 19:20:27 <PureTryOut[m]> Is there some way to run `default_doc` on subpackages?
2019-06-04 19:20:56 <north1> shouldn't it just be a matter of calling it ?
2019-06-04 19:21:04 <north1> or you want to run multiple times ?
2019-06-04 19:21:12 <_ikke_> default_doc takes from $pkgdir
2019-06-04 19:21:19 <PureTryOut[m]> I run it atm, but it complains that the doc directory of the main package isn't empty
2019-06-04 19:21:36 <PureTryOut[m]> it should use $subpkgdir instead
2019-06-04 19:21:45 <_ikke_> It's hardcoded to use $pkgdir
2019-06-04 19:21:57 <SpaceToast> PureTryOut[m]: is this urgent?
2019-06-04 19:22:11 <SpaceToast> you might consider waiting until after 3.10 (at which point I'm opening the amove PR)
2019-06-04 19:22:20 <PureTryOut[m]> yeah I get that 😛 so how to use it on subpackages?
2019-06-04 19:22:21 <PureTryOut[m]> SpaceToast: not really
2019-06-04 19:22:23 <PureTryOut[m]> trying to get Mumble off of qt4
2019-06-04 19:22:37 <PureTryOut[m]> amove?
2019-06-04 19:22:51 <SpaceToast> convenience function for moving stuff into subdirs
2019-06-04 19:22:53 <_ikke_> PureTryOut[m]: helper function to move things between (sub)packages
2019-06-04 19:22:54 <north1> PureTryOut: sorta vmove from Void Linux for alpine
2019-06-04 19:23:09 <PureTryOut[m]> ah
2019-06-04 19:23:42 <SpaceToast> though right now amove is hardcoded to use pkgdir, might change that (to use `.`, so you can just `cd` into whatever)
2019-06-04 19:23:57 <SpaceToast> then again, I'm not sure how you'd do that...
2019-06-04 19:24:10 <SpaceToast> let's say you have pkg-subpkg and pkg-subpkg-doc
2019-06-04 19:24:18 <SpaceToast> inside pkg-subpkg-doc, how do you get $subpkgdir for pkg-subpkg?
2019-06-04 19:24:28 <SpaceToast> (I suspect this is why we usually don't want/like sub-sub-packages)
2019-06-04 19:29:40 <PureTryOut[m]> Basically I'm trying to make Mumble use Qt5. The old package splits the server and client part. Makes sense to me, but both have -doc subpackages
2019-06-04 19:31:19 <PureTryOut[m]> Currently it complains that the man pages are uncompressed
2019-06-04 19:31:30 <PureTryOut[m]> So, how do I compress them 😛
2019-06-04 19:31:34 <SpaceToast> gzip :)
2019-06-04 19:32:16 <PureTryOut[m]> Just run gzip without flags on it?
2019-06-04 19:32:42 <SpaceToast> that should work, yeah, though default_doc does some *weird* things
2019-06-04 19:32:54 <SpaceToast> alternatively, consider just having mumble-doc
2019-06-04 19:32:58 <PureTryOut[m]> I'm just removing that part
2019-06-04 19:32:58 <SpaceToast> (with both of them)
2019-06-04 19:33:01 <SpaceToast> I doubt they're that big
2019-06-04 19:33:04 <PureTryOut[m]> It seems it used to work but not anymore
2019-06-04 19:33:29 <PureTryOut[m]> Probably not but I think gzip is the last bit I need
2019-06-04 19:36:18 <PureTryOut[m]> Yup, got it
2019-06-04 19:36:30 <SpaceToast> do make sure it opens with `man sect name`
2019-06-04 19:36:37 <SpaceToast> just in case I misremembered
2019-06-04 19:37:19 <PureTryOut[m]> sect name?
2019-06-04 19:37:52 <north1> i.e: man 5 alint
2019-06-04 19:38:07 <PureTryOut[m]> Ah of course
2019-06-04 20:00:19 <tcely> PureTryOut[m]: why did you remove default_doc ?
2019-06-04 20:05:26 <PureTryOut[m]> Because it did not work, like I told above in this channel
2019-06-04 20:05:51 <PureTryOut[m]> The man pages are installed properly though, I checked, `man 1 murmurd` opened them
2019-06-04 20:06:46 <SpaceToast> nice :)
2019-06-04 20:07:26 <PureTryOut[m]> Taking a shot at updating and moving Octave to Qt5 now
2019-06-04 20:07:47 <tcely> PureTryOut[m]: how does it not work?
2019-06-04 20:08:15 <SpaceToast> tcely: they want sub-sub-packages
2019-06-04 20:08:33 <SpaceToast> and default_doc makes $pkgname-doc out of $pkgdir
2019-06-04 20:09:14 <tcely> SpaceToast: that's not what I'm seeing in pr8472
2019-06-04 20:09:52 <PureTryOut[m]> That is what you should be seeing though
2019-06-04 20:10:09 <PureTryOut[m]> murmur is a subpackage of mumble, and I want murmur-doc
2019-06-04 20:10:58 <tcely> that's what mumur_doc is giving you with default_doc
2019-06-04 20:11:17 <PureTryOut[m]> It is not
2019-06-04 20:11:26 <tcely> why do you think that?
2019-06-04 20:11:32 <PureTryOut[m]> It is complaining that the doc directory of mumble isn't empty
2019-06-04 20:11:50 <PureTryOut[m]> Because I tested it and it did that lol
2019-06-04 20:12:29 <SpaceToast> tcely: default_doc is hardcoded to run against $pkgdir
2019-06-04 20:12:47 <tcely> it's not actually
2019-06-04 20:12:50 <SpaceToast> abuild.in::1651
2019-06-04 20:12:52 <SpaceToast> it is.
2019-06-04 20:13:02 <tcely> local mandir="$subpkgdir"/usr/share/man
2019-06-04 20:13:16 <SpaceToast> um...
2019-06-04 20:13:21 <SpaceToast> that's after the copying step
2019-06-04 20:13:24 <SpaceToast> well, moving
2019-06-04 20:13:33 <SpaceToast> that's for *compressing* the already-present manpages
2019-06-04 20:13:42 <SpaceToast> that got there on line 1653
2019-06-04 20:13:44 <SpaceToast> i.e it is
2019-06-04 20:13:46 <tcely> yes, which is what was added in the pr the gzip
2019-06-04 20:14:03 <SpaceToast> there's no reason to iterate all over $pkgdir again though
2019-06-04 20:14:45 <tcely> we're discussing the deletion of default_doc in favor of a direct gzip. I don't see the advantage to that
2019-06-04 20:15:16 <SpaceToast> we were discussing not "just using default_doc"
2019-06-04 20:15:36 <SpaceToast> the conversation started about an hour ago :)
2019-06-04 20:15:50 <tcely> the previous one maybe, this is about the pr I'm reviewing
2019-06-04 20:16:11 <tcely> default_doc looks to be the correct thing here
2019-06-04 20:16:21 <PureTryOut[m]> the conversation started because of that PR
2019-06-04 20:16:47 <PureTryOut[m]> But it doesn't work
2019-06-04 20:17:05 <tcely> it worked for the previous build
2019-06-04 20:17:09 <PureTryOut[m]> I started the conversation because it doesn't
2019-06-04 20:17:32 <tcely> https://pkgs.alpinelinux.org/contents?branch=edge&name=murmur-doc&arch=x86_64&repo=community
2019-06-04 20:17:48 <PureTryOut[m]> I know, guess stuff changed
2019-06-04 20:18:09 <tcely> you can see the compressed file and that function did what it was supposed to, so I'm not sure why you are saying it doesn't work
2019-06-04 20:18:33 <PureTryOut[m]> Because it literally didn't lol
2019-06-04 20:18:34 <PureTryOut[m]> I tried it
2019-06-04 20:18:56 <tcely> ok. what did you see that made you think it didn't work then?
2019-06-04 20:19:32 <PureTryOut[m]> the prepare function failing
2019-06-04 20:19:33 <PureTryOut[m]> I'm not sure why you're doubting me
2019-06-04 20:20:15 <tcely> the prepare function is not related to murmur_doc though
2019-06-04 20:21:02 <PureTryOut[m]> sorry, replace prepare function with doc function
2019-06-04 20:21:16 <PureTryOut[m]> I misspoke
2019-06-04 20:21:46 <PureTryOut[m]> murmur_doc was failing because of calling default_doc. I'm not sure what else to tell you
2019-06-04 20:24:53 <SpaceToast> looks like it's fine after all :)
2019-06-04 20:25:25 <tcely> yeah, a reason why you think default_doc is causing whatever error you saw would be what I'm asking you to tell me.
2019-06-04 20:25:47 <SpaceToast> tcely: they just reversed the change and it looks like everything's ok; would be interesting to hear the reasoning though
2019-06-04 20:26:26 <tcely> PureTryOut[m]: is the removal of usr/lib/mumble/libmanual.so intended ?
2019-06-04 20:26:46 <PureTryOut[m]> Yeah it doesn't exist anymore
2019-06-04 20:27:08 <tcely> ok
2019-06-04 20:27:18 <PureTryOut[m]> But like I said, my reason for removing is because it didn't work for me. I guess I did something wrong if it works for SpaceToast so I'll try again, but I can't give you any other reason than it literally not working
2019-06-04 20:27:38 <SpaceToast> PureTryOut[m]: I mean, you did just try again
2019-06-04 20:27:45 <SpaceToast> (your latest force push reverted to using default_doc)
2019-06-04 20:27:47 <SpaceToast> and CI passed
2019-06-04 20:28:58 <PureTryOut[m]> SpaceToast: not at all, tcely did that
2019-06-04 20:29:00 <PureTryOut[m]> Still, it didn't work for me before. I can't tell you why it did not, and I can't give you any other reason
2019-06-04 20:29:06 <SpaceToast> oh, I see
2019-06-04 20:29:35 <PureTryOut[m]> tcely: those secfixes aren't present anymore (they're upstreamed), why re-add the comment?
2019-06-04 20:29:56 <tcely> PureTryOut[m]: secfixes are a historical list
2019-06-04 20:30:26 <PureTryOut[m]> and pkgver=1.3.0 is wrong, as 1.3.0 isn't released yet
2019-06-04 20:31:15 <tcely> 1.3.0 and 1.3.0_rcX won't compare any better. Just bump pkgrel when a new rc / final is released.
2019-06-04 20:31:38 <PureTryOut[m]> Oh yeah good call, that's true
2019-06-04 20:32:31 <PureTryOut[m]> Well in that case I guess it's ok now. I still don't know why default_doc failed for me
2019-06-04 20:41:48 <MY_R> PureTryOut[m], oh ye thanks for mumble, 1.2.x not working well (freezing randomy when open options, or is muted) and didnt include /usr/lib/mumble/lib/ with plugins and celt etc etc
2019-06-04 20:42:41 <PureTryOut[m]> Well, I only made sure it compiled. Please test it
2019-06-04 20:45:51 <_ikke_> yhttps://github.com/numirias/security/blob/master/doc/2019-06-04_ace-vim-neovim.md
2019-06-04 20:46:06 <_ikke_> vim modeline vulnerability
2019-06-04 20:46:35 <MY_R> PureTryOut[m], yep I will do it soon or tomorrow
2019-06-04 20:48:59 <SpaceToast> _ikke_: as a sidenote, this is why both of those ignore modelines when ran as root
2019-06-04 20:49:17 <SpaceToast> (not this rce specifically, but the ability to run stuff via them in general)
2019-06-04 20:49:49 <_ikke_> Yes, I'm aware
2019-06-04 20:51:05 <_ikke_> Vim seems to release every commit as patch release
2019-06-04 20:51:14 <SpaceToast> roughly, yes
2019-06-04 20:51:16 <SpaceToast> neovim's a bit more sane
2019-06-04 20:52:20 <mps> similar to ncurses
2019-06-04 20:56:25 <PureTryOut[m]> Well, ophcrack doesn't like to be moved to Qt5. `make[3]: *** No rule to make target 'QtCharts/QChartView', needed by 'ui_graphdialog.h'.  Stop.` qt5-qtcharts-dev is installed however
2019-06-04 21:00:08 <tcely> umm. why is dbus being built before xvfb-run ?? https://cloud.drone.io/alpinelinux/aports/6349
2019-06-04 21:02:44 <mps> thinking to move simpe-mtpfs from testing to community. we don't have CLI mtpfs tool (afaik). any objection?
2019-06-04 21:12:23 <PureTryOut[m]> Oh ophcrack is being moved to unmaintained, that is even better
2019-06-04 21:29:14 <danieli> ophcrack is pretty old software by now, hasn't gotten too much love upstream either
2019-06-04 21:49:31 <PureTryOut[m]> Could somebody retrigger Travis in pr8473? There was some connection error when fetching the package source
2019-06-04 22:18:12 <PureTryOut[m]> Only have 1 package to move from Qt4 and then we can get rid of it
2019-06-04 22:18:31 <PureTryOut[m]> However, that last one (ostinato-{drone,gui}) refuses to compile 😭
2019-06-04 22:18:40 <PureTryOut[m]> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/v1/download/matrix.org/UIDkqpGpCPDVLlbIgLPkFHIi >

2019-06-04 22:22:12 <SpaceToast> PureTryOut[m]: add musl-dev to devdepends
2019-06-04 22:22:54 <PureTryOut[m]> Yeah no luck, tried that before
2019-06-04 22:22:57 <PureTryOut[m]> Problem is the fortify thing
2019-06-04 22:23:28 <SpaceToast> the fortify thing is trying to include an stdlib.h in the standard include path
2019-06-04 22:23:35 <SpaceToast> the traditional stdlib.h is in /usr/include/
2019-06-04 22:23:51 <SpaceToast> if you don't have /usr/include in your include path, I dare say you've some bigger problems ;)
2019-06-04 22:25:17 <PureTryOut[m]> Well it's trying, but failing
2019-06-04 22:25:31 <PureTryOut[m]> It's just docker-abuild, I don't have installation problems lol
2019-06-04 22:25:55 <SpaceToast> can you send me the apkbuild?
2019-06-04 22:26:01 <SpaceToast> (and co.)
2019-06-04 22:26:37 <SpaceToast> tarball of $pkgbasedir preferred
2019-06-04 22:28:51 <PureTryOut[m]> No extra files, there is just an APKBUILD 😉
2019-06-04 22:29:03 <PureTryOut[m]> 
ACTION posted a file: APKBUILD (1KB) < https://matrix.org/_matrix/media/v1/download/fam-ribbers.com/efhXMSbqRdhOInecjSiCNtdO >

2019-06-04 22:36:03 <SpaceToast> the problem is with include_next and parsing order
2019-06-04 22:36:11 <SpaceToast> let me see if I can patch their mistake out :)
2019-06-04 22:40:17 <PureTryOut[m]> I never heard of include_next tbh
2019-06-04 22:40:28 <SpaceToast> it's a C thing
2019-06-04 22:40:32 <SpaceToast> anyway
2019-06-04 22:40:38 <SpaceToast> qmake-qt5 seems to be misbehaving
2019-06-04 22:40:41 <PureTryOut[m]> Anyway once that package is moved to Qt5 and all the PRs are merged, Qt4 can be removed 🎉
2019-06-04 22:40:48 <SpaceToast> it's forcefully inserting `-isystem /usr/include` into CXXFLAGS
2019-06-04 22:40:53 <SpaceToast> and that's what breaks everything
2019-06-04 22:41:09 <SpaceToast> (it needs to be `-idirafter`, in the order they're putting it in, or just straight up missing, if possible)
2019-06-04 22:41:11 <PureTryOut[m]> Nice...
2019-06-04 22:44:02 <SpaceToast> I'm really not sure why it's doing it either...
2019-06-04 22:44:09 <SpaceToast> it seems to be "smartly" autodetecting that we need it
2019-06-04 22:44:15 <SpaceToast> but overriding CXXFLAGS seems to help
2019-06-04 22:44:37 <SpaceToast> let's see if it builds like that
2019-06-04 22:44:43 <SpaceToast> it'll definitely need a comment though
2019-06-04 22:46:10 <PureTryOut[m]> I'm off to bed, good night!
2019-06-04 22:46:19 <SpaceToast> PureTryOut[m]: mind if I PM you what I end up with, then?
2019-06-04 22:46:54 <PureTryOut[m]> Sure, that's fine
2019-06-04 22:47:27 <SpaceToast> alright, sleep well \o
2019-06-04 22:58:10 <SpaceToast> ah great, they have a different regression on top of that
2019-06-05 01:36:41 <north1> PureTryOut: I have a PR for ostinato
2019-06-05 01:36:57 <north1> Override CXXFLAGS to have -O2
2019-06-05 01:37:28 <SpaceToast> north1: quite a bit done already, there are more problems than just that :/
2019-06-05 01:37:41 <SpaceToast> well actually I've been finished for hours now, sent all details to them in PM
2019-06-05 01:37:51 <SpaceToast> encourage you to do the same, more resources more better :)
2019-06-05 01:39:51 <north1> SpaceToast: I know, i reached those problems when i worked on it.
2019-06-05 01:39:58 <north1> pr8470
2019-06-05 01:40:27 <SpaceToast> do you want the setup I arrived to?
2019-06-05 01:40:31 <SpaceToast> I have it building just fine
2019-06-05 01:40:56 <north1> PR it then
2019-06-05 01:41:14 <SpaceToast> I don't want to manage some weird qt PR
2019-06-05 01:41:20 <SpaceToast> I sent it to the person actively working on it
2019-06-05 01:41:22 <SpaceToast> (i.e PureTryOut[m])
2019-06-05 01:46:14 <north1> alright
2019-06-05 01:46:40 <SpaceToast> to clarify (since you're not a mind-reader)
2019-06-05 01:47:04 <SpaceToast> poking around some code and solving problems has a relatively low barrier of entry - it's stuff I like to do anyways, unless the codebase is really crazy
2019-06-05 01:47:25 <SpaceToast> submitting/maintaining/responding-to a PR is a very different (more political) process, which is a much bigger chore
2019-06-05 01:47:55 <SpaceToast> I don't mind helping poking into the thing because, well, why not, but I don't care about it at all, certainly not enough to deal with things like "waiting for review" etc
2019-06-05 06:15:00 <north1> prepare() { default_prepare ; ) on apg
2019-06-05 06:15:01 <north1> nice
2019-06-05 06:20:32 <north1> Someone please throw a big purple MAINTAINER WANTED for pr8499
2019-06-05 06:20:46 <north1> package in main
2019-06-05 06:24:45 <fcolista> ibmg50
2019-06-05 06:25:40 <fcolista> wrong channel, sorry
2019-06-05 06:25:54 <north1> sounds like the name of a gun
2019-06-05 06:26:05 <north1> IBMG-50
2019-06-05 06:28:38 <_ikke_> north1: done
2019-06-05 06:28:40 <fcolista> no :)
2019-06-05 06:28:47 <fcolista> it was an old 15" CRT monitor
2019-06-05 06:28:52 <north1> _ikke_: thank you
2019-06-05 06:29:02 <fcolista> https://www.cnet.com/products/ibm-g50-crt-monitor-15-series/
2019-06-05 06:29:04 <north1> fcolista: If you try hard enough you can use a 15" CRT monitor as an weapon
2019-06-05 06:29:15 <fcolista> LOL :)
2019-06-05 06:37:53 <north1> pkgdesc="Obsolete package that can be removed"
2019-06-05 06:37:54 <north1> ok then
2019-06-05 06:38:41 <north1> pr8507
2019-06-05 08:18:49 <PureTryOut[m]> SpaceToast: maxice8 pr8514
2019-06-05 08:30:34 <PureTryOut[m]> And the final PR to actually remove qt from the repos: pr8515
2019-06-05 08:30:44 <PureTryOut[m]> *qt4 that is
2019-06-05 08:31:03 <Cogitri> Why not move it to unmaintained first?
2019-06-05 08:31:30 <PureTryOut[m]> Because it's been EOL since 2015. What's the point in moving to unmaintained if no one ever wants to bring it back?
2019-06-05 08:32:06 <Cogitri> I just thought it's common etiquette in Alpine to first move it to unmaintained, make sure nothing broke and then delete the thing
2019-06-05 08:32:30 <PureTryOut[m]> Well everything depending on it is already being moved away from it, so it can't break anything
2019-06-05 08:33:03 <PureTryOut[m]> I say that, I forgot to remove testing/qt-creator
2019-06-05 08:33:18 <Cogitri> <PureTryOut[m] "I say that, I forgot to remove t"> Why remove it?
2019-06-05 08:33:24 <Cogitri> The latest version works with Qt5 IIRC
2019-06-05 08:33:51 <PureTryOut[m]> Because for a second I assumed it was Qt4 only
2019-06-05 08:33:52 <PureTryOut[m]> But you're right
2019-06-05 08:33:55 <PureTryOut[m]> I'll make a PR for it
2019-06-05 08:34:28 <Cogitri> 👍
2019-06-05 08:43:42 <PureTryOut[m]> Actually, already is a PR for, pr7712
2019-06-05 09:42:21 <north1> yes there is
2019-06-05 09:42:50 <north1> i asked a few times for people that develop on Qt5 to test it since i only did basic testing that someone that doesn't develop on Qt5 can do.
2019-06-05 09:43:06 <north1> nobody answered so i'll assume it is good2go
2019-06-05 09:44:26 <PureTryOut[m]> Seems reasonable
2019-06-05 09:45:30 <north1> Nothing much i can do
2019-06-05 11:17:20 <mps> ncopa: I worked about week on fixing boot on some ARM32 boards and found that some additional kernel options (drivers) should enabled for such boards
2019-06-05 11:18:52 <mps> now I have only allwinner/sunxi boards and can tell for them, but probably there are more of them which would need enabling drivers
2019-06-05 11:21:21 <mps> I looked in Arch linux alarm (arch on arm) and found how they did that, they enable most drivers. Kernel image and initramfs are somewhat bigger but not much
2019-06-05 11:22:26 <mps> (btw, Arch alarm is one of the best linux distro for arm imo)
2019-06-05 11:24:12 <SpaceToast> PureTryOut[m]: re: pr8514, you need to regenerate checksums if you edit files in source=
2019-06-05 11:24:42 <PureTryOut[m]> Oh I thought I did so, woops
2019-06-05 11:25:41 <PureTryOut[m]> Fixed
2019-06-05 12:03:25 <ncopa> mps: i'm open to enable kernel configs for boards you have
2019-06-05 12:06:49 <MY_R> PureTryOut[m], pr8472 working fine in general but need this in qmake-qt5 line: DEFINES+="PLUGIN_PATH=/usr/lib/mumble"
2019-06-05 12:07:18 <ncopa> what is left for removing qt4?
2019-06-05 12:07:52 <PureTryOut[m]> ncopa: pr8515 has depends on all leftovers
2019-06-05 12:07:55 <PureTryOut[m]> MY_R: thanks, will add
2019-06-05 12:08:18 <MY_R> thank you! :)
2019-06-05 12:10:23 <mps> ncopa: ok, will prepare patch and post it later when I make some more tests. thanks
2019-06-05 12:11:56 <maxice8> Opinions on bzip2 being in the hands of someone that wants to rustify it  https://people.gnome.org/~federico/blog/maintaining-bzip2.html ?
2019-06-05 12:12:19 <mps> btw, any guide or hints how can I make alpine-uboot-$ver-$arch.tar.gz using locally built kernel
2019-06-05 12:13:22 <ncopa> PureTryOut[m]: great thanks!
2019-06-05 12:13:26 <PureTryOut[m]> MY_R: updated the PR, thanks for mentioning it
2019-06-05 12:15:07 <Cogitri> <maxice8 "Opinions on bzip2 being in the h"> Very nice
2019-06-05 12:15:44 <maxice8> cogitri: You do understand that that will make most packages unavailable on anything but x86_64 for Alpine Linux
2019-06-05 12:16:08 <MY_R> PureTryOut[m], great :)
2019-06-05 12:16:27 <PureTryOut[m]> maxice8: only once packages actually start requiring newer versions
2019-06-05 12:16:42 <Cogitri> <maxice8 "cogitri: You do understand that "> We'll have cross-platform Rust once LLVM8 is merged and even if so we can use old bzip2 on other arches
2019-06-05 12:16:42 <PureTryOut[m]> Which might take a while, in the meantime Alpine might have updated the Rust support
2019-06-05 12:17:04 <_ikke_> And requiring a new rust compiler version every new release ...
2019-06-05 12:17:40 <maxice8> PureTryOut: Yes except for the security patching required which will only increase
2019-06-05 12:18:48 <Cogitri> <_ikke_ "And requiring a new rust compile"> Yeah, the bootstrapping situation is pretty bad for someone like us which does custom triplets
2019-06-05 12:19:20 <Cogitri> (Although downloading a tarball from upstream to mitigate that isn't necessarily sane either)
2019-06-05 12:19:53 <TBB> yeah, I saw that blog post by the guy who wants to rustify bz2. it's bs it is.
2019-06-05 12:20:22 <_ikke_> Probably introduce new subtle bugs (rust != bugfree)
2019-06-05 12:21:29 <Cogitri> Yup, rewrites usually introduce new bugs
2019-06-05 12:21:35 <Cogitri> But it's way easier to avoid bugs in Rust :)
2019-06-05 12:21:45 <_ikke_> certain kinds of bugs
2019-06-05 12:22:07 <TBB> in software made in Rust, not necessarily in Rust itself...
2019-06-05 13:09:22 <ncopa> qt4 is gone
2019-06-05 13:09:27 <ncopa> thanks!
2019-06-05 13:10:21 <mps> so I have to try rebuild two my local pkg's with qt5
2019-06-05 13:11:06 <TBB> good luck. I've only had to go through that once, and ended up bugging fabled about it
2019-06-05 13:11:21 <PureTryOut[m]> ncopa: awesome!
2019-06-05 13:11:58 <mps> oh, just one. I already rebuilt one but forgot :)
2019-06-05 13:14:38 <maxice8> ncopa: nice
2019-06-05 13:52:17 <nmeum_> fabled: updated the apk humanize patch again, it now uses off_t for size_diff and llabs now
2019-06-05 13:52:28 <nmeum_> using llabs on a off_t is probably not too portable though
2019-06-05 13:56:07 <fabled> nmeum, yeah. it got a bit more tricky than expected.
2019-06-05 13:57:21 <nmeum> yeah, that's why I didn't want to touch that code piece originally ;)
2019-06-05 14:10:17 <fabled> i see...
2019-06-05 14:10:18 <fabled> :)
2019-06-05 14:14:35 <nmeum> works as is though but if you want me to change it let me know
2019-06-05 14:14:58 <nmeum> alternatively you could just cherry pick the first commit and we can discuss the other one separately
2019-06-05 14:15:06 <nmeum> idk
2019-06-05 15:03:05 <Cogitri> mps: Could you try webkit2gtk again? (i really, really have to setup a VM soon)
2019-06-05 15:03:49 <mps> Cogitri: 8257 PR
2019-06-05 15:05:43 <Cogitri> Yup
2019-06-05 15:06:26 <mps> ok
2019-06-05 15:06:32 <Cogitri> BTW, does CI automatically fail if the maximum output is reached?
2019-06-05 15:07:27 <mps> Cogitri: is date correct? Date:   Mon Jun 3 17:42:43 2019 +0200
2019-06-05 15:07:40 <mps> commit is 29c2e651167213bdf1dfe333fbad6401c8254599
2019-06-05 15:08:07 <mps> no. sorry
2019-06-05 15:11:14 <mps> building...
2019-06-05 15:27:45 <Cogitri> Thank you :)
2019-06-05 15:29:57 <mps> Cogitri: failed again. here is build log http://arvanta.net/mps/webkit2gtk-build.log.gz
2019-06-05 15:31:15 <Cogitri> BTW, not relevant for this, but I'm curious: How important is 32-bit stuff in the ARM world still?
2019-06-05 15:36:08 <mps> armhf and armv7 are 32bit
2019-06-05 15:38:40 <Cogitri> Yup, are there still new boards coming out with those arches or is it all Aarch64 now?
2019-06-05 15:39:55 <danieli> for what it's worth, a significant amount of ARM devices are 32-bit
2019-06-05 15:40:16 <danieli> armv{2,3,4,5,6} are considered legacy iirc
2019-06-05 15:40:57 <Cogitri> mps: Also, are you really sure you're building from the latest commit (4180d3b)
2019-06-05 15:41:15 <danieli> i believe armv7 and some of the 32-bit armv8 architectures are still alive
2019-06-05 15:41:32 <Cogitri> Alright, thanks for the info! :)
2019-06-05 15:42:23 <danieli> armhf is essentially armv7 abi with some extra extensions
2019-06-05 15:43:23 <mps> arm32 are low power and very efficient, and new devices/board still appears on market, so I think it will stay for long time
2019-06-05 15:43:37 <danieli> indeed, it's pretty darn widespread, so i doubt it's dying any time soon
2019-06-05 15:44:05 <mps> Cogitri: yes, downloaded it just before applying
2019-06-05 15:44:51 <danieli> mips is still in use too, but less so than it used to - perhaps they'll gain some popularity if efforts to compete with riscv increase
2019-06-05 15:45:00 <danieli> but oh well, i digress
2019-06-05 15:46:10 <Cogitri> <mps "cogitri: yes, downloaded it just"> Huh, weird, are you really sure? Then our CLang is borderline broken :c
2019-06-05 15:47:25 <Cogitri> Do we have something like carch but for bitness? Or should I just use uname for that?
2019-06-05 15:47:40 <Cogitri> s/carch/$CARCH/
2019-06-05 15:47:40 <alpine-meetbot> Cogitri meant to say: Do we have something like $CARCH but for bitness? Or should I just use uname for that?
2019-06-05 15:48:56 <danieli> you could switch $CARCH and set bitness going from that
2019-06-05 15:52:24 <Cogitri> Alright, will do that then
2019-06-05 15:53:03 <mps> Cogitri: here is top of 'git log' where I tried build http://tpaste.us/wjO5
2019-06-05 15:58:23 <Cogitri> Please fetch again, the HEAD should be 4180d3b196c41d601b39e740558891c04c53e255
2019-06-05 15:59:39 <mps> I did already, and started again, but go out :-Q
2019-06-05 16:07:25 <Cogitri> Okie. Thanks :)
2019-06-05 16:15:13 <mps> Cogitri: it failed with same error on the same 'place'. I think sending log is useless but I can if you want it
2019-06-05 16:16:17 <Cogitri> Huh, that's weird, clang-dev which is installed with that commit definitely contains the missing header it's complaining about
2019-06-05 16:16:28 <mps> llvm7 (and batteries) are broken ime, so clang also
2019-06-05 16:17:14 <Cogitri> Yup :c
2019-06-05 16:17:37 <mps> I'm losing patience with it :(
2019-06-05 16:18:09 <mps> imo, we should revert to llvm6 or upgrade llvm8 ASAP
2019-06-05 16:19:35 <Cogitri> Well, LLVM8 just needs someone pressing the button, so I'd rather not downgrade to llvm6
2019-06-05 16:20:10 <mps> I can if BDFL agree :)
2019-06-05 16:27:49 <danieli> ncopa: ^ ? :)
2019-06-05 16:43:21 <ncopa> url?
2019-06-05 16:43:53 <ncopa> i would prefer to go for llvm8
2019-06-05 16:44:11 <mps> Cogitri: ^^
2019-06-05 16:44:15 <ncopa> so, i havent looked at it, but as i understand, llvm7 and clang is broken?
2019-06-05 16:44:40 <ncopa> so "pushing the button" will not make anything worse than it is?
2019-06-05 16:45:06 <mps> I built Cogitri's llvm8 on x86_64, aarch64 and armv7
2019-06-05 16:45:07 <danieli> imo upgrading is also preferable to downgrading
2019-06-05 16:45:10 <Cogitri> llvm8 is a seperate aport, so no
2019-06-05 16:45:44 <mps> also, tested some programs with it
2019-06-05 16:46:32 <mps> not sure if it is bug free, to be fair because didn't tested it extensively
2019-06-05 16:48:48 <danieli> quite a few things have very little testing
2019-06-05 16:49:11 <_ikke_> Is anything bugfree?
2019-06-05 16:50:20 <mps> _ikke_: I presume this is rhetorical question ;)
2019-06-05 16:50:23 <_ikke_> yes
2019-06-05 17:07:52 <_ikke_> ncopa: the vim vulnerability has now been assigned a CVE, should I update the APKBUILD to include it?
2019-06-05 17:10:14 <mps> _ikke_: also, shouldn't that fix be backported
2019-06-05 17:10:29 <_ikke_> Yes, probably
2019-06-05 17:12:15 <ncopa> _ikke_: yes i think so
2019-06-05 17:12:27 <_ikke_> ok
2019-06-05 17:12:41 <ncopa> thanks for taking care of it
2019-06-05 17:13:15 <_ikke_> Should I just backport the specific patch that fixes it?
2019-06-05 17:14:22 <_ikke_> https://github.com/vim/vim/commit/53575521406739cf20bbe4e384d88e7dca11f040
2019-06-05 17:16:59 <ncopa> we can probably upgrade it
2019-06-05 17:17:07 <_ikke_> ok
2019-06-05 17:19:01 <_ikke_> fix is 8.1.1365, 3.9 has 8.1.0630, 3.8 has 8.1.0630, 3.7 has  8.0.1359
2019-06-05 17:19:38 <_ikke_> so 3.7 seem so to be a minor version behind
2019-06-05 17:20:52 <danieli> _ikke_: it applies to neovim as well
2019-06-05 17:20:57 <_ikke_> true
2019-06-05 17:24:46 <ncopa> _ikke_: i'd add the patch for 3.7 and upgrade the others
2019-06-05 17:28:54 <ncopa> does anyone dare to fix samba circular deps?
2019-06-05 17:41:34 <_ikke_> ncopa: Will do that
2019-06-05 18:03:22 <ncopa> i warn you, its non-trivial
2019-06-05 18:03:58 <_ikke_> I was referring to vim, not samba
2019-06-05 18:04:02 <ncopa> lol
2019-06-05 18:04:06 <ncopa> :)
2019-06-05 18:05:43 <mps> main/libgphoto2 build on aarch64 lxc container, but not on builders
2019-06-05 18:07:50 <mps> ncopa: you are making arm tarballs with mkimage.sh. I posted my issue with it to alpine-devel ML
2019-06-05 18:08:45 <mps> I'd like to make these tarballs for testing arm changes I made but cannot make tarball
2019-06-05 18:10:33 <ncopa> mps: what was the subject?
2019-06-05 18:10:36 <ncopa> i need to search
2019-06-05 18:11:18 <mps> Building alpine linux from source code
2019-06-05 18:11:39 <mps> my response to tmhoang
2019-06-05 18:14:14 <mps> also, I read (carefully, I think) https://wiki.alpinelinux.org/wiki/How_to_make_a_custom_ISO_image_with_mkimage
2019-06-05 18:27:38 <danieli> samba will indeed be non-trivial
2019-06-05 18:27:43 <danieli> i saw that hellscape of a dep tree
2019-06-05 18:33:50 <_ikke_> Output from a while ago: http://ikke.info/d/alpine-dep-errors.pdf
2019-06-05 18:37:09 <_ikke_> the push contention is real :D
2019-06-05 18:38:02 <_ikke_> Cogitri: ping
2019-06-05 18:39:49 <_ikke_> colord is failing to build on ppc64le due to sane missing there
2019-06-05 18:44:44 <Cogitri> Ah, thanks for the ping, will look into that
2019-06-05 18:45:53 <ncopa> Cogitri: i just enabled sane on ooc64le
2019-06-05 18:46:00 <ncopa> ppc64le
2019-06-05 18:46:03 <ncopa> and s390x
2019-06-05 18:46:07 <ncopa> seems to build
2019-06-05 18:46:14 <mksully22> is there any reason "sane" can't be built on ppc64le? It seems to build ok on my ppc64le setup...
2019-06-05 18:46:28 <_ikke_> I don't know why, but it was just not enabled for those
2019-06-05 18:46:37 <ncopa> mksully22: no reason afaik. i just enabled it
2019-06-05 18:46:42 <_ikke_> was only explicitly enabled for x86* and arm&
2019-06-05 18:46:52 <mksully22> sounds good thx
2019-06-05 18:48:05 <_ikke_> undefined reference to `libintl_bindtextdomain'
2019-06-05 18:48:15 <_ikke_> and some others for libgphoto
2019-06-05 18:49:40 <mps> _ikke_: it works in my lxc
2019-06-05 18:49:54 <mps> aarch64, I mean
2019-06-05 19:01:44 <_ikke_> mps: missing deps?
2019-06-05 19:02:05 <_ikke_> ie, do you have deps in your local container that are not on the builder?
2019-06-05 19:03:55 <mps> I think so, but don't know what is in builders
2019-06-05 19:04:10 <_ikke_> Very little
2019-06-05 19:04:38 <mps> ok, will look deeply later, now I'm going out
2019-06-05 19:04:59 <_ikke_> do you have gettext installed?
2019-06-05 19:05:03 <Cogitri> <_ikke_ "undefined reference to `libintl_"> Seems like gettext generally is a bit weird on Alpine
2019-06-05 19:05:07 <_ikke_> right
2019-06-05 19:06:38 <_ikke_> danieli: I think neovim has been updated already
2019-06-05 19:09:05 <_ikke_> yes, has been fixed in 0.3.6, and we already have 0.3.7
2019-06-05 19:18:10 <ncopa> im fixing ldd
2019-06-05 19:18:49 <_ikke_> re libintl?
2019-06-05 19:19:10 <ncopa> no, some other build errors
2019-06-05 19:20:14 <ncopa> colord dev
2019-06-05 19:21:48 <_ikke_> ah ok
2019-06-05 19:26:05 <_ikke_> gnome-tweaks failes because mutter is missig on ppc64le
2019-06-05 19:26:12 <_ikke_> s/failes/fails/
2019-06-05 19:26:12 <alpine-meetbot> _ikke_ meant to say: gnome-tweaks fails because mutter is missig on ppc64le
2019-06-05 19:28:07 <_ikke_> Should this be moved to the apk project? https://bugs.alpinelinux.org/issues/10201
2019-06-05 19:30:59 <Cogitri> It's really a big annoying that we don't have CI for those arches :c
2019-06-05 19:44:41 <fabled> Cogitri, seems at-spi2-* upgrade made the daemon not work. and i'm getting annoying 25 second timeouts
2019-06-05 19:45:16 <Cogitri> Hm, wfm :o
2019-06-05 19:45:24 <Cogitri> Mind spinning me a log?
2019-06-05 19:45:35 <fabled> Cogitri, http://sprunge.us/R1U7Zu
2019-06-05 19:46:28 <Cogitri> Thanks
2019-06-05 19:49:23 <fabled> config seems to be in usr/share/defaults/at-spi2/accessibility.conf
2019-06-05 19:50:43 <Cogitri> Hmm...it still launches just fine for me - maybe GNOME does some dbus magic to make it work without that config?
2019-06-05 19:50:54 <fabled> symlinking to that config file did not help
2019-06-05 19:51:09 <fabled> so probably not needed. i wonder why the assert fails
2019-06-05 19:52:27 <ncopa> i have some fuzzy memory about someone providing a custom patch to disable at-spi2 by default and only enable with a magic env var
2019-06-05 19:52:41 <ncopa> i dont think we ever applied it
2019-06-05 19:52:55 <ncopa> but maybe there is a magic env var to disable at spi?
2019-06-05 19:54:15 <Cogitri> I don't think that's really a proper solution for this?
2019-06-05 19:55:13 <Cogitri> I mean at-spi2-core should just work, but I'm having a hard time debugging that when GNOME already starts it just fine :/
2019-06-05 19:58:41 <Cogitri> Huh https://github.com/GNOME/at-spi2-core/blob/6e0e94d0f3e257f87d89e7b23ee7be5e1f0a87c6/bus/at-spi-bus-launcher.c#L447
2019-06-05 20:03:00 <ncopa> i doubt the missing conf file is the problem
2019-06-05 20:03:05 <_ikke_> Anyone knows what should provide things like 'struct tcphdr' and TH_ACK?
2019-06-05 20:04:04 <ncopa> maybe tcp.h from linux-headers?
2019-06-05 20:04:07 <fabled> yeah, somehow it fails to start dbus or something
2019-06-05 20:04:07 <TBB> tcp.h indeed
2019-06-05 20:04:22 <_ikke_> linux-headers is added as dep, but the build is failing
2019-06-05 20:04:33 <_ikke_> error: invalid application of 'sizeof' to incomplete type 'struct tcphdr'
2019-06-05 20:04:38 <Cogitri> <ncopa "i doubt the missing conf file is"> Possibly, but `error_message != NULL` doesn't really provide any meaningful way to debug it
2019-06-05 20:04:59 <Cogitri> And IIRC dbus redirects stderr of applications to /dev/null
2019-06-05 20:05:18 <_ikke_> Probably need to add the header
2019-06-05 20:05:21 <Cogitri> <_ikke_ "error: invalid application of 's"> Maybe the header order is wrong or it doesn't use Linux/tcp.h but some other tcp.h?
2019-06-05 20:05:37 <ncopa> i dont have experience with debugging dbus stuff
2019-06-05 20:05:41 <_ikke_> #include <netinet/tcp.h>
2019-06-05 20:07:19 <Cogitri> fabled: Could you try getting the actual error msg like described here: https://wiki.ubuntu.com/DebuggingDBus
2019-06-05 20:07:32 <Cogitri> Under 'filtering out the noise'
2019-06-05 20:07:47 <_ikke_> Cogitri: Do you think I should swap netinet/tcp.h for linux/tcp.h?
2019-06-05 20:07:51 <ncopa> maybe running some of the daemons in the foreground? https://www.freedesktop.org/wiki/Accessibility/AT-SPI2/
2019-06-05 20:08:01 <ncopa> _ikke_: try add linux/tcp.h
2019-06-05 20:08:12 <ncopa> after the others
2019-06-05 20:08:54 <Cogitri> <ncopa "maybe running some of the daemon"> If they aren't launched already by dbus, sure (because they'll fail if they have been already)
2019-06-05 20:09:43 <_ikke_> linux/tcp.h does not define TH_ACK, it does define tcphdr, but so does netinet/tcp.h
2019-06-05 20:10:11 <_ikke_> #if defined(_GNU_SOURCE) || defined(_BSD_SOURCE)
2019-06-05 20:10:18 <_ikke_> There is a guard in netinet/tcp.h
2019-06-05 20:10:54 <ncopa> try add CFLAGS="$CFLAGS -D_GNU_SOURCE"
2019-06-05 20:11:22 <_ikke_> It uses features.h
2019-06-05 20:11:36 <_ikke_> so _ALL_SOURCE would work as well
2019-06-05 20:13:45 <fabled> Cogitri, https://build.alpinelinux.org/buildlogs/build-edge-x86_64/main/at-spi2-core/at-spi2-core-2.32.0-r0.log
2019-06-05 20:13:56 <fabled> it does not find dbus-broker or dbus-daemon
2019-06-05 20:14:04 <fabled> so it build launcher that launcher nothing
2019-06-05 20:15:05 <fabled> you need to keep 'dbus' in makedepends i think
2019-06-05 20:15:26 <fabled> it's needed for configury to pick it up, so it gets used
2019-06-05 20:16:06 <fabled> see https://github.com/GNOME/at-spi2-core/blob/6e0e94d0f3e257f87d89e7b23ee7be5e1f0a87c6/bus/meson.build#L39
2019-06-05 20:16:24 <_ikke_> ncopa: It does '#undef _GNU_SOURCE
2019-06-05 20:16:25 <_ikke_> '
2019-06-05 20:16:27 <_ikke_> :-/
2019-06-05 20:16:28 <fabled> well, lines 39-62
2019-06-05 20:17:10 <fabled> ok. so adding that dbus back to makedepends should fix it. but i need to go sleep now. hope it's fixed when i wake up ;)
2019-06-05 20:17:31 <Cogitri> Oh, thought it'd use some sane default then, sorry for the breakage :)
2019-06-05 20:18:25 <_ikke_> -D_BSD_SOURCE works
2019-06-05 20:32:48 <_ikke_> Would it make sense to define _BSD_SOURCE?
2019-06-05 20:35:51 <ncopa> _ikke_: i'd report it upstream
2019-06-05 20:36:21 <_ikke_> ncopa: Right, I think to patch out the #undef _GNU_SOURCE
2019-06-05 20:36:30 <_ikke_> I'm thinking to*
2019-06-05 20:36:41 <ncopa> im thinking ot go to bed :)
2019-06-05 20:36:52 <_ikke_> Good idea
2019-06-05 20:37:19 <ncopa> Cogitri: do you have a patch for at spi?
2019-06-05 20:37:24 <SpaceToast> it's "I'm thinking of X-ing", in this case "I'm thinking of patching out" :)
2019-06-05 20:37:33 <SpaceToast> good night ncopa ^^
2019-06-05 20:37:39 <ncopa> gnight
2019-06-05 20:37:55 <_ikke_> SpaceToast: thanks, as you notice it's getting late here :P
2019-06-05 20:37:56 <Cogitri> ncopa: Ah, I can make one right now, or I'll open a PR later
2019-06-05 20:38:39 <SpaceToast> you could also use "I will" (I'll) in place of the "to", as an alternate form, but it has other side-effects (sentence-structure wise)
2019-06-05 20:59:03 <tmh1999> _ikke_ : do you know what is apk magic to check if a package is from main/community/testing ?
2019-06-05 20:59:41 <SpaceToast> tmh1999: `apk policy $pkgname` will show you what url it got installed from
2019-06-05 20:59:42 <_ikke_> I can only think of apk policy <pkg>
2019-06-05 20:59:45 <_ikke_> right
2019-06-05 20:59:58 <tmh1999> beautiful
2019-06-05 20:59:59 <_ikke_> apk info <pkg> as well
2019-06-05 20:59:59 <tmh1999> thanks mate
2019-06-05 21:00:12 <_ikke_> sorry, n/m the last one
2019-06-05 21:00:13 <tmh1999> apk info does not show
2019-06-05 21:07:40 <revolutionary> Hi all. We are trying to build postmarketOS for my device but we are getting error about colord-dev package. I checked from packages website of you but i couldn't see armv7 build for that package. May i ask is there any ETA for building armv7? Thanks in advance.
2019-06-05 21:08:02 <revolutionary> we stuck at this step
2019-06-05 21:08:27 <Cogitri> I think asking that in one channel would do
2019-06-05 21:08:29 <_ikke_> revolutionary: usually there is some kind of reason it cannot be built for a specific arch if it's missing
2019-06-05 21:08:36 <Cogitri> I can look into that now.
2019-06-05 21:09:29 <_ikke_> Cogitri: feel free to take over maintainership of colord if you want, I adopted it mostly for darktable
2019-06-05 21:09:29 <revolutionary> _ikke_ i am not familiar with dev stuff and i couldn't understand that. One more thing we could built without any error 1 hour ago. But i don't know what happened in 1 hour on your side.
2019-06-05 21:09:53 <revolutionary> cogitri thanks for your effort
2019-06-05 21:09:56 <Cogitri> <_ikke_ "cogitri: feel free to take over "> Alright, will do
2019-06-05 21:10:54 <revolutionary> could you please tell me what happened in 1 hour on your side?
2019-06-05 21:10:58 <_ikke_> revolutionary: changes were pushed to colord and there were build failures
2019-06-05 21:10:59 <revolutionary> i am just curious
2019-06-05 21:11:05 <revolutionary> i see
2019-06-05 21:11:07 <_ikke_> https://build.alpinelinux.org/buildlogs/build-edge-armv7/community/colord/colord-1.4.4-r3.log
2019-06-05 21:11:31 <revolutionary> you mean we won't build postmarketOS anymore
2019-06-05 21:12:04 <SpaceToast> I don't think that's a reasonable assumption
2019-06-05 21:12:07 <_ikke_> I would not expect the package to disappear
2019-06-05 21:12:10 <SpaceToast> certainly, the package will get fixed at some point
2019-06-05 21:12:13 <_ikke_> when build failures happen
2019-06-05 21:13:34 <Cogitri> My plan was to get the GNOME metapackage merged (pr8332), then setup a Qemu image with aarch64 and armv7 and then try to get GNOME running on those arches
2019-06-05 21:13:43 <Cogitri> Sadly the Qemu part is a PITA
2019-06-05 21:15:23 <Cogitri> BTW, for something different, what license would you classify "Distributed in the public domain"? (that's the only thing in the binary, there's no license file in the package)
2019-06-05 21:15:44 <SpaceToast> "public domain" is a legal concept in licensing
2019-06-05 21:16:34 <SpaceToast> if you really need it to fit under something, you can always fork and license it under CC0 or something :)
2019-06-05 21:17:06 <SpaceToast> but yeah SPDX doesn't have an identifier for that: https://wiki.spdx.org/view/Legal_Team/Decisions/Dealing_with_Public_Domain_within_SPDX_Files
2019-06-05 21:17:10 <danieli> indeed
2019-06-05 21:17:16 <Cogitri> Yup :c
2019-06-05 21:17:29 <SpaceToast> so if you're really worried, fork and CC0/Unlicense/whatever :)
2019-06-05 21:17:55 <danieli> would be nice if upstream could use a proper public domain license like CC-0 or unlicense (preferably the former)
2019-06-05 21:17:55 <danieli> yes
2019-06-05 21:19:12 <_ikke_> anyone an idea why the colord package disappeared for armv7?
2019-06-05 21:19:28 <SpaceToast> no clue :/
2019-06-05 21:20:02 <_ikke_> 3.9 has it, but for edge they're gone
2019-06-05 21:20:38 <revolutionary> i guess some dark powers are playing with me because this happened in 1 hour and we could build without any error 1 hour ago and we deleted those files for clean re-build and we encountered with this :/
2019-06-05 21:21:03 <_ikke_> normally packages should not disappear
2019-06-05 21:21:05 <danieli> ninja: build stopped: subcommand failed.
2019-06-05 21:21:05 <danieli> >>> ERROR: colord: build failed
2019-06-05 21:21:14 <danieli> edge armv7
2019-06-05 21:21:24 <_ikke_> Yes, but even in that case, the existing package should remain
2019-06-05 21:21:34 <danieli> true - wonder why it's gone
2019-06-05 21:21:54 <danieli> must be a bug somewhere
2019-06-05 21:25:47 <_ikke_> now all kinds of gnome things fail to build due to colord missing
2019-06-05 21:26:41 <revolutionary> Does this (https://www.freedesktop.org/software/colord/) and this (https://github.com/hughsie/colord) works?
2019-06-05 21:27:01 <danieli> we use freedesktop as upstream source
2019-06-05 21:27:16 <_ikke_> revolutionary: the package is there, it's just a temporary build failure
2019-06-05 21:27:36 <danieli> looks like the github one is a(n older?) mirror of the freedesktop one
2019-06-05 21:27:54 <danieli> but yes, what _ikke_ said, we haven't removed the package for armv7
2019-06-05 21:27:58 <revolutionary> _ikke_ then we should wait?
2019-06-05 21:28:02 <_ikke_> yesz
2019-06-05 21:28:04 <_ikke_> yes
2019-06-05 21:28:07 <danieli> good night
2019-06-05 21:28:35 <revolutionary> should i exit now?
2019-06-05 21:29:05 <_ikke_> feel free to hang around
2019-06-05 21:29:46 <_ikke_> Did the same thing happen with hiredis?
2019-06-05 21:30:29 <revolutionary> are you asking to me?
2019-06-05 21:30:32 <_ikke_> no
2019-06-05 21:30:35 <revolutionary> ok
2019-06-05 21:33:57 <Cogitri> ikke: Ping me if the build fails again on armv7
2019-06-05 21:34:07 <_ikke_> right
2019-06-05 21:35:41 <_ikke_> revolutionary: colord-dev should be back in about 15 minutes
2019-06-05 21:55:17 <revolutionary> _ikke_ thanks for your effort, appreciate.
2019-06-05 22:09:17 <revolutionary> _ikke_ i am still getting this ([01:08:29] ERROR: Package 'colord-dev': Could not find aport, and could not find this package in any APKINDEX!) error. Is this normal?
2019-06-05 22:10:59 <mps> revolutionary: did you run 'apk update'
2019-06-05 22:11:10 <revolutionary> no.
2019-06-05 22:11:27 <mps> try this and then search
2019-06-05 22:14:19 <Cogitri> Yup, the build was successful, so it should show up now: https://build.alpinelinux.org/buildlogs/build-edge-armv7/community/colord/colord-1.4.4-r4.log
2019-06-05 22:16:34 <mps> it is 'apk search' => colord-dev-1.4.4-r4
2019-06-05 22:17:04 <revolutionary> mps i don't have pmOS yet. i am trying to build installation
2019-06-05 22:17:33 <mps> on what OS you are trying
2019-06-05 22:17:40 <revolutionary> ubuntu
2019-06-05 22:18:20 <mps> hmm, I don't know how the building of pmOS works
2019-06-05 22:18:28 <revolutionary> ok thanks
2019-06-05 22:18:51 <mps> but colord-dev-1.4.4-r4 is available on armv7 now
2019-06-05 22:19:12 <mps> in Alpine edge repo, I mean
2019-06-05 22:19:13 <revolutionary> i saw.
2019-06-05 22:19:18 <Cogitri> Yup. Might be better to ask in pmOS's channel then
2019-06-05 22:19:58 <Cogitri> I guess I should join too, am a bit curious how they're planning to handle PureOS
2019-06-05 22:52:35 <danieli> i know they have pmbootstrap and some other funky stuf
2019-06-05 22:52:36 <danieli> f
2019-06-05 23:14:48 <jnt> If I need to build a piece of software with two different build configurations, should I do it in two different apkbuilds or is there a way to have a different build function for each subpackage?
2019-06-05 23:19:12 <mps> jnt: you can look at main/vim/APKBUILD maybe it could help you
2019-06-05 23:25:28 <jnt> mps: thanks, that is exactly what i was looking for.
2019-06-06 05:03:24 <_ikke_> bratkartoffel: openjdk9 is failing on armv7
2019-06-06 05:03:39 <_ikke_> https://build.alpinelinux.org/buildlogs/build-3-10-armv7/community/openjdk9/openjdk9-9.0.4_p12-r1.log
2019-06-06 05:18:25 <fabled> Cogitri, thanks for the at-spi2-core fix. all works now again (without the timeouts)
2019-06-06 07:52:00 <Cogitri> Nice, thanks for notifying me and sorry for the breakage :)
2019-06-06 08:07:39 <fabled> Cogitri, no problem. that happens at times...
2019-06-06 11:15:59 <PureTryOut[m]> mps: so what to do with pr7899? Can I just rebase it, add arm-trusted-firmware package, and be done with it?
2019-06-06 11:19:08 <mps> I don't think this approach is good for Alpine
2019-06-06 11:20:07 <mps> I think arm-trusted-firmware should be pushed first, and I have it ready. Are you in a hurry?
2019-06-06 11:20:35 <PureTryOut[m]> Not really, but I was asked to rebased the PR
2019-06-06 11:21:03 <PureTryOut[m]> I'm fine with adding arm-trusted-firmware in a separate commit
2019-06-06 11:21:40 <mps> well, sorry, these days I'm busy with fixing kernel for allwinner/sunxi, new crystal and some important pkg's for new release
2019-06-06 11:22:22 <mps> although I can push first version of the arm-trusted-firmware
2019-06-06 11:22:50 <mps> let me finish breakfast and coffee, and then I will push it
2019-06-06 11:25:13 <PureTryOut[m]> Thanks
2019-06-06 11:25:23 <mps> np
2019-06-06 12:21:30 <mps> how to make pkg to depends on all it's subpkgs
2019-06-06 12:22:04 <maxice8> depends="$subpackages" ?
2019-06-06 12:23:40 <mps> maxice8: list of all subpkackages?
2019-06-06 12:24:19 <maxice8> subpackages= is the variable that holds what subpackages a pkg has
2019-06-06 12:25:18 <mps> looking in linux-firmware, there is a for loop which add deps
2019-06-06 12:33:17 <mps> PureTryOut[m]: ready to push arm-trusted-firmware (ATF, from now) would you like to add you as maintainer/contributor
2019-06-06 12:34:29 <PureTryOut[m]> yeah sure
2019-06-06 12:35:13 <mps> what are your 'proper' mail address
2019-06-06 12:35:20 <mps> s/are/is/
2019-06-06 12:35:20 <alpine-meetbot> mps meant to say: what is your 'proper' mail address
2019-06-06 12:35:59 <PureTryOut[m]> bribbers@disroot.org, I use it on all packages
2019-06-06 12:36:55 <mps> without real name before? I mean full mail address
2019-06-06 12:37:15 <mps> with name as most are in aports
2019-06-06 12:37:44 <PureTryOut[m]> Oh sorry. "Bart Ribbers <bribbers@disroot.org>"
2019-06-06 12:37:57 <PureTryOut[m]> Uhm, "Bart Ribbers <bribbers@disroot.org>"
2019-06-06 12:38:46 <mps> nice, thanks. :) in what field? maintainer or contributor
2019-06-06 12:39:11 <_ikke_> mps: you need to watch out that subpackages don't start to depend on themselfs
2019-06-06 12:39:16 <PureTryOut[m]> I guess you're the contributor
2019-06-06 12:39:33 <PureTryOut[m]> I'm fine with maintaining it
2019-06-06 12:39:40 <_ikke_> mps: which would happen if you don't override the depends in the subpackages
2019-06-06 12:39:46 <mps> there could be more maintainers/contributors
2019-06-06 12:40:30 <PureTryOut[m]> More maintainers even?
2019-06-06 12:40:46 <PureTryOut[m]> Well, I'm fine with it either way, you decide 😛
2019-06-06 12:40:47 <mps> _ikke_: yes, but for now I decided to not make it complicated because ATF is needed just for one board
2019-06-06 12:40:48 <_ikke_> afaik there is only one maintainer
2019-06-06 12:40:57 <kpcyrd> is there a good way to list all packages in alpine with with their name, repository, version and possibly also which parent package they belong to (in case of a sub package)?
2019-06-06 12:41:40 <mps> _ikke_: really one? I think I have seen pkg's with more than one maintainer
2019-06-06 12:42:01 <_ikke_> kpcyrd: look at aports-lua
2019-06-06 12:55:12 <mps> PureTryOut[m]: applied testing/arm-trusted-firmware, only for aarch64, other doesn't make sense for now
2019-06-06 12:58:41 <PureTryOut[m]> Agreed
2019-06-06 12:59:29 <mps> you are maintainer so care about it, I will help whenever and where I can
2019-06-06 12:59:44 <PureTryOut[m]> Haha sure
2019-06-06 13:00:19 <PureTryOut[m]> My future phone will be using that 😉
2019-06-06 13:00:31 <mps> but, I don't think we should force push of u-boot for now
2019-06-06 13:01:19 <mps> hehe, I hope my current will also. I have to change CPU though :)
2019-06-06 13:02:05 <PureTryOut[m]> force push?
2019-06-06 13:02:28 <mps> forcing change to u-boot to be pushed right now
2019-06-06 13:02:41 <mps> although I made it
2019-06-06 13:04:41 <mps> and, probably will have today another patch for u-boot, i.e. add one or two sunxi boards
2019-06-06 13:05:23 <PureTryOut[m]> merged to master you mean? We can push it to my PR fine
2019-06-06 13:06:22 <mps> no, I wrote it differently, use ATF in makedepends and something else, I forgot
2019-06-06 13:06:36 <mps> but I want these sunxi first
2019-06-06 13:07:43 <mps> (you didn't noticed that I dislike GH)
2019-06-06 13:13:45 <mps> PureTryOut[m]: forgot to tell, you have to start advocating move ATF to main because u-boot will makedepend on it
2019-06-06 13:15:07 <mps> and OT, can pmOS be installed on yotaphone, even unofficially
2019-06-06 13:19:19 <PureTryOut[m]> Where did you push arm-trusted-firmware?
2019-06-06 13:20:31 <asriel[m]> <mps "and OT, can pmOS be installed on"> E-ink on postmarketOS sounds like a fun challenge
2019-06-06 13:20:32 <mps> previous msg: PureTryOut[m]: applied testing/arm-trusted-firmware, only for aarch64, other doesn't make sense for now
2019-06-06 13:21:09 <mps> asriel[m]: I had a hope :)
2019-06-06 13:21:45 <PureTryOut[m]> mps: we might not have a port for the Yotaphone yet, but if there are Linux kernel sources available then you can port it yourself
2019-06-06 13:22:39 <mps> making boot for android devices is out of my knowledge for now
2019-06-06 13:23:30 <mps> and interest before all, to be fair
2019-06-06 13:26:14 <mps> I had a hope that we will have free phone, and was one of the first who bought openmoko, but years passed and we still far from free phone
2019-06-06 13:29:07 <asriel[m]> https://github.com/SteadyQuad/android_kernel_yotaphone2/tree/lollipop5.0_20160921
2019-06-06 13:31:29 <mps> ah, didn't know. thanks. will note this and if found some time will look. for me boot loaders are issue
2019-06-06 13:48:06 <PureTryOut[m]> mps: get either a Librem 5 or a PinePhone (I recommend the latter) if you want a free phone
2019-06-06 13:48:31 <PureTryOut[m]> mps: also, I didn't realize you already pushed arm-trusted-firmware to the repos, sorry
2019-06-06 13:49:11 <Cogitri> PureTryOut: How come you recommend the PinePhone?
2019-06-06 13:49:25 <PureTryOut[m]> Over the Librem 5 you mean?
2019-06-06 13:49:37 <Cogitri> Yup
2019-06-06 13:49:53 <PureTryOut[m]> Well for one, you can buy 4 PinePhone's for the price of one Librem 5
2019-06-06 13:50:07 <PureTryOut[m]> Secondly, I like the company behind the device more, their community interaction is better
2019-06-06 13:50:24 <PureTryOut[m]> Also, I'm biased, as at postmarketOS we got devkits from them but haven't gotten Librem 5 devkits
2019-06-06 13:50:27 <danieli> how do the devices measure up towards each other?
2019-06-06 13:51:32 <SpaceToast> librem 5 is an MX8M, pinephone is an A64
2019-06-06 13:53:19 <Cogitri> Ah, alrighty. Well, I guess I'll have to take a closer look at the PinePhone then, considered buying a Librem 5 soon-ish (well, once it's out)
2019-06-06 13:53:22 <SpaceToast> mx8m is cortex-a53 + cortex-m4f, a64 is just cortex-a53 iirc
2019-06-06 13:54:51 <PureTryOut[m]> I cancelled my Librem 5 pre-order last week 😛
2019-06-06 13:54:54 <SpaceToast> also more ram
2019-06-06 13:55:05 <SpaceToast> librem 5 will definitely perform better, but I'm not sure about "4 times better"
2019-06-06 13:55:23 <PureTryOut[m]> Part of the price of the phone goes to GNOME mobile (Phosh) development, which I don't care for at all and am not going to use, and I'll be getting a PinePhone anyway so it only made sense to me
2019-06-06 13:55:56 <SpaceToast> not judging or anything, just trying to get out any and all relevant information I have, since danieli asked :)
2019-06-06 13:56:52 <danieli> yeah, no ulterior motives from my side, I'm just curious - and not a potential customer (for now at least?)
2019-06-06 13:56:55 <danieli> thanks SpaceToast
2019-06-06 13:57:20 <SpaceToast> I think a53 is faster than m4f, but m4f has some features people wanted
2019-06-06 13:57:24 <SpaceToast> no clue what they are though
2019-06-06 14:14:44 <danieli> right, so A is more general purpose embedded, M is more microcontroller oriented (usually not a lot of memory either)
2019-06-06 14:16:08 <danieli> a53 *should* be better for multimedia and streaming stuff
2019-06-06 14:17:05 <SpaceToast> well a53 + m4f is faster than just a53, I'd imagine
2019-06-06 14:17:11 <SpaceToast> but probably not 4x faster, as the prices would suggest
2019-06-06 14:17:34 <p4Wv1qn095FW> m4f is a coprocessor for some hw controlling, like dedicated usb, display, etc.
2019-06-06 14:17:58 <SpaceToast> aha
2019-06-06 14:18:21 <p4Wv1qn095FW> spi/i2c, stuff like this
2019-06-06 14:18:34 <p4Wv1qn095FW> but nothing really that an a53 should not support itself.
2019-06-06 14:20:41 <danieli> right, offloading should still be helpful, but how much of an improvement it'll give will probably depend on how demanding driving the hardware is
2019-06-06 14:21:41 <p4Wv1qn095FW> it can do usb, and eth, but not usb3 or gbeth
2019-06-06 14:21:49 <p4Wv1qn095FW> so it's not really useful
2019-06-06 14:22:04 <SpaceToast> owch
2019-06-06 14:22:06 <p4Wv1qn095FW> i deal with m-series cortex stuff on a daily basis
2019-06-06 14:22:20 <SpaceToast> I'm already looking forward to usb4, not even usb3 on a phone that isn't out yet isn't acceptable
2019-06-06 14:22:30 <SpaceToast> esp. at that price point
2019-06-06 14:23:21 <p4Wv1qn095FW> anyway, perhaps all this is more suited for #offtopic?
2019-06-06 14:23:21 <danieli> it's been some years since i was 'in the loop' when it comes to hardware, i just keep an eye out now
2019-06-06 14:23:24 <danieli> mm, true
2019-06-06 14:23:26 <danieli> good point
2019-06-06 14:28:11 <maxice8> ping @TBK:matrix.org
2019-06-06 14:32:57 <PureTryOut[m]> Yeah Librem 5 will perform better, but the price is too much for just the hardware. However, you're paying for Phosh and stuff too
2019-06-06 14:50:51 <p4Wv1qn095FW> i don't thinkt he m4f will considerably add to better performance, but maybe might add to better batter life.
2019-06-06 14:51:00 <p4Wv1qn095FW> *battery
2019-06-06 14:51:38 <p4Wv1qn095FW> the m4f could be like the intel ME is for intel x86 hosts
2019-06-06 14:59:58 <bratkartoffel> _ikke_: yes, openjdk does not build on armv7 (all 32 bit arches at the moment). I don't know exactly why, crosscompiling works
2019-06-06 15:00:34 <_ikke_> I wonder who enabled it then
2019-06-06 15:00:39 <bratkartoffel> The package should be disabled on armv7 anyways
2019-06-06 15:00:46 <bratkartoffel> as openjdk10 or 11 are
2019-06-06 15:21:15 <maxice8> pr6388 can be closed, pkg is already in the repos
2019-06-06 15:21:41 <maxice8> _ikke_: pr7444 needs update on the labels
2019-06-06 15:26:56 <kpcyrd> does alpine have epochs?
2019-06-06 15:27:10 <danieli> define epochs?
2019-06-06 15:27:34 <_ikke_> I guess like Archlinux in PKGBUILDs
2019-06-06 15:28:05 <danieli> right - but its use is discouraged unless you have to
2019-06-06 15:28:14 <danieli> alpine doesn't have it to my knowledge
2019-06-06 15:28:29 <_ikke_> nope
2019-06-06 15:29:40 <kpcyrd> ok, thanks
2019-06-06 15:30:30 <danieli> say you have a programming language package called "mylang" that depends on llvm 6, but current llvm release is llvm 8 - what we usually do in situations like those is we keep 'llvm6' around as a separate package
2019-06-06 15:31:56 <_ikke_> But I don't think epoch is used for that, is it?
2019-06-06 15:33:13 <SpaceToast> iirc epoch is more about version system changes
2019-06-06 15:33:28 <danieli> mm, sometimes when version schemes change pacman thinks it's a downgrade
2019-06-06 15:33:35 <_ikke_> yes
2019-06-06 15:33:37 <SpaceToast> e.g if salt/minio (which currently use YYYY.MM[.DD]) eventually swapped over to semver
2019-06-06 15:33:45 <_ikke_> correct
2019-06-06 15:34:04 <SpaceToast> what we do is just prefix with 0. (e.g minio is at 0.20190604(?) right now)
2019-06-06 15:34:15 <SpaceToast> though repology is very unhappy about it
2019-06-06 15:34:40 <_ikke_> right, because it does not match the upstream version
2019-06-06 15:35:06 <kpcyrd> let me know if that changes :)
2019-06-06 15:35:23 <_ikke_> kpcyrd: you mean epoch?
2019-06-06 15:35:24 <mps> danieli: yes, we keep llvm's, 3.9 and 5 are still in aports because they are needed for some pkg's
2019-06-06 15:35:31 <kpcyrd> _ikke_: yes
2019-06-06 15:36:26 <_ikke_> kpcyrd: would be good to open an issue about it on bugs.a.o
2019-06-06 15:36:46 <_ikke_> Together with your usecase
2019-06-06 15:37:08 <_ikke_> https://bugs.alpinelinux.org/issues/10533
2019-06-06 15:37:11 <_ikke_> already is one
2019-06-06 15:39:19 <kpcyrd> is /etc/abuild.conf the right place to set MAKEFLAGS= ?
2019-06-06 15:39:37 <_ikke_> What kind of makeflags?
2019-06-06 15:39:58 <_ikke_> It is already used to set -j for example
2019-06-06 15:40:36 <kpcyrd> oh right, I somehow missed that
2019-06-06 15:52:41 <_ikke_> ncopa: I think I've seen already 3 packages that suddently went missing (I think all 3 on armv7)
2019-06-06 15:57:19 <kpcyrd> is there a way to override REPODEST= for a specific abuild call?
2019-06-06 15:57:37 <kpcyrd> -P, never mind m(
2019-06-06 16:25:34 <kpcyrd> thanks for all the help :)
2019-06-06 16:35:03 <Cogitri> <SpaceToast "but probably not 4x faster, as t"> A price to performance ratio of 1.0 is rather rare though :P
2019-06-06 16:36:33 <SpaceToast> oh certainly, but someone brought up that they could get 4 pinephones, which suggests that price/performance ratio is a big deal to them
2019-06-06 16:41:46 <tmhoang> SpaceToast: Am I correct you are the new mkinitfs dev/maintainer ?
2019-06-06 16:41:54 <SpaceToast> no
2019-06-06 16:42:10 <SpaceToast> are you looking for someone to talk to about it?
2019-06-06 16:42:19 <SpaceToast> iirc jwh was working on it recently
2019-06-06 16:42:39 <tmhoang> Ah now I remember it was Nero
2019-06-06 16:42:48 <tmhoang> need to find his IRC name agagin
2019-06-06 16:43:01 <mps> tmhoang: he left
2019-06-06 16:43:16 <tmhoang> mps : do you know what happened ?
2019-06-06 16:43:51 <SpaceToast> during the reorg stuff, ncopa figured the general goals of the project should be reaffirmed (from the /about page)
2019-06-06 16:43:53 <mps> not sure, but iirc he was irritated by proposed organization changes
2019-06-06 16:44:04 <SpaceToast> Nero strongly disagreed with alpine being a general-purpose distribution
2019-06-06 16:44:28 <SpaceToast> saying that they (and their organization) think of Alpine as an IoT thing or something, because of the good os-to-application ratio
2019-06-06 16:44:42 <SpaceToast> some self-contradictions later they just left
2019-06-06 16:45:03 <tmhoang> oops sorry
2019-06-06 16:45:25 <SpaceToast> what for?
2019-06-06 16:46:13 <mps> tmhoang: his nick was AinNero
2019-06-06 16:46:22 <tmhoang> mps : thanks mate
2019-06-06 16:46:53 <mps> and he is not only one who left :(
2019-06-06 16:50:32 <tmhoang> we survive
2019-06-06 16:51:00 <mps> we will, I hope :)
2019-06-06 16:52:55 <maxice8> Glad you woke up algitbot
2019-06-06 16:52:58 <SpaceToast> I do find the whole situation quite strange, but hopefully the WG comes up with something that everyone can live with, while actually improving the situation at hand
2019-06-06 16:56:56 <danieli> quite a few people have distanced themselves already
2019-06-06 16:58:47 <SpaceToast> well, what I find confusing is the way this has effectively went about
2019-06-06 16:59:00 <SpaceToast> I'm here because I think Alpine is great, and want to make it even better
2019-06-06 16:59:12 <SpaceToast> so if I see something I strongly disagree with, I... say that I strongly disagree with it, and explain why
2019-06-06 16:59:38 <SpaceToast> but for some reason this seems not to happen a lot of the time, with simply leaving (or any other non-communicative reaction) being the default approach
2019-06-06 17:08:19 <danieli> sometimes people lose pretty much all hope for $thing, or don't want to spend more effort on $thing
2019-06-06 17:13:35 <SpaceToast> hm... I'd argue that the former would have had to be in a long series of events, then; while the latter has some interesting logical consequences
2019-06-06 17:13:47 <SpaceToast> but if you wanna continue this poke me in #alpine-offtopic, I don't think this is the place for that discussion :)
2019-06-06 17:22:44 <danieli> agreed
2019-06-06 17:36:41 <mps> well, people are different, some are vocal and some quiet and we cannot expect all will behave as we think
2019-06-06 18:11:05 <mps> will pkg be rebuilt if the only change is add something to makedepends
2019-06-06 18:12:36 <danieli> not unless you bump pkgver or pkgrel
2019-06-06 18:12:57 <mps> nice, expected that. thanks
2019-06-06 18:16:28 <mps> tmhoang: still around?
2019-06-06 18:16:38 <tmhoang> mps: yes
2019-06-06 18:17:20 <mps> nice, have you seen my question about mkimage.sh in alpine-devel ML
2019-06-06 18:18:03 <tmhoang> which day ?
2019-06-06 18:18:14 <mps> yesterday, iirc
2019-06-06 18:18:45 <tmhoang> the name of the email thread ? sorry
2019-06-06 18:18:47 <mps> it is answer/question to your reply
2019-06-06 18:19:26 <mps> subject is: Building alpine linux from source code
2019-06-06 18:20:53 <tmhoang> Ahh. I assume your host and target are all armv7. My to-go is to put -x into update-kernel scripts and mkinitfs and so on
2019-06-06 18:21:56 <prspkt> algitbot: retry master
2019-06-06 18:22:34 <mps> yes, I run it on armv7 and target is also armv7. expected it should work 'out of box'
2019-06-06 18:22:45 <tmhoang> tried on stable branch ?
2019-06-06 18:22:54 <mps> no, on edge
2019-06-06 18:24:11 <mps> must I have all packages locally in apk files
2019-06-06 18:24:14 <tmhoang> build_uboot() seems to have FIXME :)
2019-06-06 18:24:33 <mps> ahm, will look
2019-06-06 18:25:52 <mps> I see. anyone have fix?
2019-06-06 18:26:51 <tmhoang> last 4-5 commits from clandmeter. So blame him :P
2019-06-06 18:27:22 <tmhoang> or fabled :D
2019-06-06 18:27:58 <tmhoang> looks like it tries to get all u-boot-all rdeps. so if you have a list, try to put it into $pkgs
2019-06-06 18:28:07 <mps> I will not dare, especially clandmeter, he work hard to get gitlab working :)
2019-06-06 18:29:28 <mps> now I know that I'm not invoking it wrong way, will look later if can find solution. thanks for help
2019-06-06 19:16:31 <ollieparanoid[m]> ncopa or other abuild maintainers: if you have time, could you take a look at this simple fix? https://github.com/alpinelinux/abuild/pull/75 somebody just ran into it, and we have a pmbootstrap test case that had to be disabled because of this bug
2019-06-06 19:41:28 <_ikke_> ollieparanoid[m]: I think most focus atm is in releasing 3.10
2019-06-06 19:42:02 <_ikke_> sorry about that one btw, that was my fault
2019-06-06 19:42:50 <SpaceToast> it's a pretty common issue - ran into it when I made the other pr thing
2019-06-06 19:42:59 <SpaceToast> I do agree with Cogitri that you should use : over true
2019-06-06 19:43:09 <ollieparanoid[m]> ikke: I see. but since that fixes a regression, it is probably worth looking at
2019-06-06 19:45:23 <ollieparanoid[m]> SpaceToast: fine with me, I'll push an update
2019-06-06 20:04:59 <ollieparanoid[m]> updated
2019-06-06 20:05:25 <ollieparanoid[m]> _ikke_: no worries, mistakes happen :) let's just make sure that it gets fixed too
2019-06-06 20:05:33 <_ikke_> yup, I agree
2019-06-06 20:06:09 <SpaceToast> +1
2019-06-06 20:46:16 <_ikke_> mps: synchronizesFailed to raise an exception: END_OF_STACK :(
2019-06-06 20:48:06 <mps> out of memory?
2019-06-06 20:49:17 <_ikke_> I doubt it
2019-06-06 20:49:39 <mps> which version you build?
2019-06-06 20:49:50 <mps> 0.28.0?
2019-06-06 20:50:01 <_ikke_> yes
2019-06-06 20:50:26 <mps> hmm, I didn't had this issue
2019-06-06 20:50:43 <_ikke_> I installed crystal and removed the PATH statement of the build command
2019-06-06 20:51:10 <mps> installed crystal from apk?
2019-06-06 20:52:03 <_ikke_> yes
2019-06-06 20:52:27 <mps> I'm not sure it will work
2019-06-06 20:52:59 <mps> I think it needs static version to build
2019-06-06 20:53:14 <_ikke_> sad
2019-06-06 20:53:51 <mps> also I'm, but that life is with these new languages
2019-06-06 20:54:08 <_ikke_> I wonder why that would be?
2019-06-06 20:54:53 <mps> I have no idea, but remember that once I tried same as you and only remember it didn't worked
2019-06-06 21:25:13 <mps> what tool makes modloo-vanilla
2019-06-06 21:25:32 <mps> s/modloo-vanilla/modloop-vanilla/
2019-06-06 21:25:32 <alpine-meetbot> mps meant to say: what tool makes modloop-vanilla
2019-06-06 21:30:28 <mps> ah, update-kernel
2019-06-06 21:43:41 <_ikke_> mps: with the original apkbuild and crystal removed, i get 2 test failures
2019-06-06 21:49:01 <mps> _ikke_: on edge?
2019-06-06 21:51:50 <mps> I've rebuilt it today without problem on aarch64 for test before pushed to aports
2019-06-06 21:52:29 <mps> and built static tarball on both, x86_64 and aarch64 cleanly
2019-06-06 22:48:04 <revolutionary> hi all. when i tried to install postmarketos-ui-xfce4 i am getting these logs. Is this relevant with alpinelinux repos or just with me? https://bpaste.net/show/f68a33158c3a
2019-06-06 22:53:40 <danieli> revolutionary: kinda looks like it pulled some package of the wrong architecture?
2019-06-06 22:54:24 <revolutionary> danieli: my device is armv7
2019-06-06 22:54:36 <danieli> hm, it's libgio-2.0.so
2019-06-06 22:54:45 <revolutionary> yes
2019-06-06 22:54:46 <danieli> from glib-dev
2019-06-06 22:55:12 <revolutionary> i am not familiar with dev stuff and i don't know how can i fix this.
2019-06-06 22:55:28 <revolutionary> pmOS folks are helping me to port my device.
2019-06-06 22:55:39 <danieli> #alpine-linux (or perhaps even #postmarketos) would probably be more appropriate, but it's quiet here, so whatever
2019-06-06 22:55:47 <danieli> i wonder why that would happen, have you mixed repositories or done anything else out of the ordinary?
2019-06-06 22:56:10 <revolutionary> i know those chans. I just wondered is this problem relevant with alpine linux or with me
2019-06-06 22:56:18 <revolutionary> no i didn't.
2019-06-06 22:57:39 <danieli> hm, i can't really tell without more info, perhaps someone else can
2019-06-06 22:58:20 <revolutionary> just want and i can provide more info. and thanks for your interest.
2019-06-06 22:58:40 <jnt> can you run file on libgio-2.0.so.0 ? It's probably in /usr/lib/
2019-06-06 22:58:50 <revolutionary> btw i don't prefer to talk on 2 chans about same issue. people doesn't like that.
2019-06-06 23:28:24 <LucasRamage[m]> Greetings, any progress on my bash-completion patch? https://patchwork.alpinelinux.org/patch/4849/
2019-06-07 00:01:20 <tcely> pr7873
2019-06-07 00:16:40 <LucasRamage[m]> algitbot: I saw that. My github username is oxr463, I made several comments on that PR; there are some conflicts between that and mine.
2019-06-07 01:07:40 <maxice8> Someone please close pr8450 , algitbot didn't close that automatically
2019-06-07 01:12:45 <maxice8> pr7790 can be closed
2019-06-07 01:14:49 <maxice8> tcely thank you
2019-06-07 01:15:22 <tcely> maxice8: you're welcome
2019-06-07 03:39:33 <maxice8> ping mps
2019-06-07 03:39:52 <maxice8> ok to push pr8078 ?
2019-06-07 04:34:30 <_ikke_> mps: http://tpaste.us/65dZ
2019-06-07 04:34:48 <maxice8> _ikke_: morning
2019-06-07 04:35:43 <Danct12_> heyy!
2019-06-07 04:36:06 <_ikke_> maxice8: morning
2019-06-07 04:36:41 <maxice8> :D i updated a few old PRs that you asked for changes
2019-06-07 04:54:08 <maxice8> need pr8560 to have its CI restarted
2019-06-07 04:55:23 <_ikke_> done
2019-06-07 04:56:58 <maxice8> ty
2019-06-07 04:59:56 <_ikke_> the armv7 builder seems to be in some kind of broken state
2019-06-07 05:35:15 <maxice8> What is the preferred way to follow build.a.o ?
2019-06-07 06:36:15 <_ikke_> I hang around in #alpine-commits
2019-06-07 06:36:34 <_ikke_> There you see what is comitted, and build failures
2019-06-07 06:36:48 <_ikke_> maxice8: ^
2019-06-07 06:40:27 <Danct12_> that channel has chatting disabled, am i right?
2019-06-07 06:40:48 <Danct12_> was bored so i decided to go there and try to type something to see if anyone notice that..
2019-06-07 06:41:44 <_ikke_> You probable need to be registered
2019-06-07 06:57:49 <Danct12_> I already have a identified account?
2019-06-07 06:58:05 <Danct12_> Don't know about "registered" accounts
2019-06-07 06:58:08 <Danct12_> I thought that those are the same thing
2019-06-07 06:58:16 <Danct12_> (or did I missed anything?)
2019-06-07 06:59:18 <_ikke_> No, should be the same
2019-06-07 06:59:44 <Danct12_> don't know why I keep redirected to #archlinux-unregistered for some reason
2019-06-07 06:59:59 <_ikke_> Apparently you haven' identified
2019-06-07 07:00:53 <Danct12_> so.. what is the /identify command then? I already ran that just to be able to send messages in some channels
2019-06-07 08:57:28 <maxice8> gnome-builder is merged
2019-06-07 08:58:11 <_ikke_> ok, nice
2019-06-07 08:58:27 <maxice8> nice indeed
2019-06-07 08:59:34 <_ikke_> Noticed that you got push access btw, nice as well
2019-06-07 08:59:48 <maxice8> yes, super nice :D
2019-06-07 09:00:37 <_ikke_> I still need to update some documentation for that
2019-06-07 09:37:44 <mps> _ikke_: good morning, what APKBUILD you used when you got errors you posted to tpaste
2019-06-07 09:38:13 <maxice8> @mps can you review pr8078 ?
2019-06-07 09:40:02 <mps> maxice8: will look, already noticed that you changed it and thought you already pushed it
2019-06-07 09:40:24 <maxice8> am waiting for approval from maintainer
2019-06-07 09:41:16 <mps> aha, you are so nice :) will do soon
2019-06-07 09:50:13 <_ikke_> mps: fcf7f54d08f79e264fa6a6453fda503c1f4af0a4
2019-06-07 09:51:06 <maxice8> armv7 seems to be super broken
2019-06-07 09:51:20 <_ikke_> maxice8: yes, I noticed as well
2019-06-07 09:51:28 <mps> _ikke_: hmm, strange, it worked in my tests
2019-06-07 09:51:42 <maxice8> Yes i noticed you notie as well as well
2019-06-07 09:51:43 <maxice8> s/notie/noticed/g
2019-06-07 09:51:43 <alpine-meetbot> maxice8 meant to say: Yes i noticed you noticed as well as well
2019-06-07 09:51:59 <_ikke_> So we noticed that we noticed that armv7 is broken :P
2019-06-07 09:52:02 <maxice8> It is just now it is also failing to build evolution
2019-06-07 09:52:16 <mps> maybe some issue with builder
2019-06-07 09:52:18 <maxice8> because somehow libgweather is not getting built and registered even though you bumped it up for rebuild
2019-06-07 09:52:34 <mps> usually it works in my lxc
2019-06-07 09:52:49 <maxice8> it keeps failing gnome-disk-utility and gnome-tweaks because of libgweather.so.15 missing
2019-06-07 09:53:24 <_ikke_> It might be an issue in the dependency resolution order
2019-06-07 09:54:51 <maxice8> is there an equivalent to Void Linux's xbps-src's broken= ?
2019-06-07 09:55:13 <maxice8> We (Void) set it when a package fails to compile, we also used it to break poor dependency resolution
2019-06-07 09:56:25 <_ikke_> What does that option do?
2019-06-07 09:56:29 <_ikke_> or what do you give to it?
2019-06-07 09:56:35 <_ikke_> We usually empty arch to disable it
2019-06-07 09:57:28 <maxice8> it makes the builders ignore it without failing, so it continues building the next dependencies and when someone tries to build it, xbps-src prints the content of the variable
2019-06-07 09:57:30 <maxice8> so you can
2019-06-07 09:57:38 <maxice8> broken="Requires version of dependency foo that is no longer in the repos"
2019-06-07 09:58:21 <_ikke_> There is no equivalent
2019-06-07 10:02:27 <maxice8> well, as long as there is a way to solve this deadlock
2019-06-07 10:14:10 <mps> maxice8: pr8078 (vifm fixes) looks fine to me
2019-06-07 10:14:50 <maxice8> pushed
2019-06-07 10:15:07 <mps> I see, thanks :)
2019-06-07 10:15:37 <maxice8> deluge is soon to update to 2.0.0
2019-06-07 10:15:45 <maxice8> got a PR already in pre-release for it
2019-06-07 10:28:37 <_ikke_> maxice8: You can try to disable the failing packages and see if it builds libgweather then
2019-06-07 10:28:56 <maxice8> how to disable ?
2019-06-07 10:29:10 <_ikke_> by adjusting arch
2019-06-07 10:29:18 <maxice8> just !armv7 ?
2019-06-07 10:29:20 <_ikke_> adding !armv7 for example
2019-06-07 10:29:22 <Cogitri> Remove the arch, the it won't be built
2019-06-07 10:29:22 <_ikke_> yeah
2019-06-07 10:31:25 <_ikke_> mps: Just tried to build again, same issue
2019-06-07 10:32:06 <mps> _ikke_: in lxc container and on x86_64, I presume ?
2019-06-07 10:32:27 <_ikke_> yes
2019-06-07 10:32:44 <mps> ok, I will try again
2019-06-07 10:34:24 <maxice8> edge/testing/armv7: uploaded
2019-06-07 10:35:08 <maxice8> http://dl-cdn.alpinelinux.org/alpine/edge/testing/armv7/ shows no libgweather, maybe do a pkgrel bump ?
2019-06-07 10:35:55 <_ikke_> maxice8: You need to look at master.a.o
2019-06-07 10:36:20 <_ikke_> The rest is synced every 15 minutes
2019-06-07 10:36:29 <maxice8> i see
2019-06-07 10:36:32 <maxice8> not there as well
2019-06-07 10:39:27 <maxice8> Also, s390x seems very eager to keep building minio
2019-06-07 10:40:03 <_ikke_> yup
2019-06-07 10:47:38 <PureTryOut[m]> maxice8: ok I really can't reproduce that error (testing/weston), and neither can CI. Might it be a machine specific problem?
2019-06-07 10:47:48 <maxice8> Yeah i'll ignore it and move on
2019-06-07 10:47:52 <maxice8> looking at sddm rn
2019-06-07 10:48:32 <PureTryOut[m]> Cool
2019-06-07 11:00:17 <maxice8> _ikke_: anything i need to do for libgweather ?
2019-06-07 11:14:52 <maxice8> PureTryOut: Pushed weston
2019-06-07 11:14:53 <PureTryOut[m]> Thanks!
2019-06-07 11:17:31 <maxice8> pr8068 can be closed
2019-06-07 11:35:51 <_ikke_> maxice8: not sure, but I think it would be good to verify what's actually going on
2019-06-07 11:36:04 <_ikke_> I'l try to take a look this evening
2019-06-07 11:36:16 <maxice8> alright
2019-06-07 11:36:43 <maxice8> I'll need to add notes to remember to remove the armv7 from the packages
2019-06-07 11:38:42 <maxice8> builder doesn't even try to build libgweather on armv7
2019-06-07 11:51:36 <mps> _ikke_: 'abuild -r' passed on edge without problem in my x86_64 lxc
2019-06-07 11:52:20 <_ikke_> strange
2019-06-07 11:52:38 <mps> I have libevent installed
2019-06-07 11:52:56 <mps> but it passed on builders earlier
2019-06-07 11:56:06 <mps> for now I don't have much time to devote to build crystal-static, we can continue after stable released
2019-06-07 11:56:42 <mps> ofc, this doesn't stop you :)
2019-06-07 11:57:29 <_ikke_> Nope, I'll see if I can find something, and else will leave it be for now
2019-06-07 12:17:09 <ncopa> I’ll tag 3.10 rc2 today. What are the things we need to fix before that?
2019-06-07 12:17:55 <ncopa> I saw some PRs for mkinitfs for s390x
2019-06-07 12:18:20 <maxice8> There are some PRs on github with tagged goal of 3.10.0
2019-06-07 12:30:50 <fabled> Cogitri, any comments for pushing http://sprunge.us/yG1k58 ?
2019-06-07 12:31:11 <fabled> without that, i get: (fwupdmgr:10402): GLib-GIO-ERROR **: 15:31:03.634: Settings schema 'org.gnome.system.proxy' is not installed
2019-06-07 12:31:24 <fabled> fwupdmgr is using soup, which is accessing that proxy info
2019-06-07 12:31:33 <fabled> and that is fatal
2019-06-07 12:33:01 <mps> ncopa: I'm trying to upgrade crystal to 0.29.0 but not sure if I will make it on time for release
2019-06-07 12:33:36 <mps> have you seen my yesterday msg on infra about dev.a.o
2019-06-07 12:34:36 <mps> would like to put there current alpine version crystal static tarball for building next upstream release
2019-06-07 12:36:28 <mps> and, I presume it is to late for change kernel for some arm boards
2019-06-07 12:44:38 <ncopa> mps: I can merge if you have patches that are ready
2019-06-07 12:48:22 <mps> I have working files only, could make patch later this day. I'm out right now
2019-06-07 12:49:02 <mps> but u-boot patch is ready, https://patchwork.alpinelinux.org/patch/4908/
2019-06-07 12:50:05 <mps> and I hope that I will have crystal 0.29.0 ready tomorrow, have to fix some tests
2019-06-07 12:52:19 <andypost[m]> ncopa which branches makes sense to backport pr8576 ?
2019-06-07 12:53:42 <danieli> #10542 sounds like either a busybox or a musl issue?
2019-06-07 12:55:05 <mps> danieli: looks like it is busybox
2019-06-07 12:57:00 <Cogitri> fabled: Ah, sure, feel free to push that
2019-06-07 12:57:33 <danieli> doesn't look like it's related to our bbox config
2019-06-07 12:59:34 <tmhoang> ncopa: would be nice if you have a look at those mkinitfs pr :D
2019-06-07 12:59:41 <tmhoang> I would love to test rc2 with them
2019-06-07 13:01:44 <tmhoang> I tried to make them not "break" too much
2019-06-07 13:02:06 <tmhoang> still booting from LPAR seems not so possible, unless I have to make more "break" in mkinitfs ...
2019-06-07 13:02:29 <mps> will someone fix scripts/mkimage.sh uboot target
2019-06-07 13:02:58 <tmhoang> I mean possible with user customer change as I'm doing, but out-of-the-box exp by pulling from dl-cdn.a.o seems harder
2019-06-07 13:09:14 <tmhoang> maxice8: I dont think there is any support for s390x on minio
2019-06-07 13:13:16 <maxice8> tmhoang: well, it has arch="all"
2019-06-07 13:15:23 <SpaceToast> minio is a golang package
2019-06-07 13:15:30 <SpaceToast> And it built successfully before
2019-06-07 13:15:33 <Cogitri> Hey, could we have patch headers?
2019-06-07 13:15:47 <Cogitri> <Cogitri "Hey, could we have patch headers"> Like https://exherbo.org/docs/eapi/exheres-for-smarties.html#applying_patches
2019-06-07 13:15:52 <SpaceToast> Can someone with access to the builder check what's happening? (I'm at work and won't be able to do much until I'm back)
2019-06-07 13:16:08 <tmhoang> SpaceToast: what's happening ?
2019-06-07 13:16:21 <SpaceToast> tmhoang: maxice8 is complaining that it isn't getting built
2019-06-07 13:16:29 <tmhoang> it's built I think
2019-06-07 13:16:31 <maxice8> tmhoang: Every git push causes s390x to try and build minio again
2019-06-07 13:16:36 <SpaceToast> And the latest version on pkgs.a.o is the last one (from June 1)
2019-06-07 13:16:54 <SpaceToast> Oh, I see, we had that with some other package at some other point, haven't we?
2019-06-07 13:16:59 <_ikke_> yes
2019-06-07 13:17:01 <Cogitri> That makes it so much easier to work on packages, otherwise I first have to figure out what a patch is supposed to do whcih is pretty frustrating at times
2019-06-07 13:17:01 <maxice8> whether it builds or not idk
2019-06-07 13:17:21 <tmhoang> maxice8 : >>> minio: Building testing/minio 0.20190601-r0 (using abuild 3.4.0_rc4-r0) started Sat, 01 Jun 2019 19:29:22 +0000
2019-06-07 13:17:27 <SpaceToast> Cogitri: could you send that link into #alpine-docs?
2019-06-07 13:17:55 <SpaceToast> tmhoang: that's definitely weird, latest version is 2019.06.04
2019-06-07 13:18:14 <jwh> o/
2019-06-07 13:18:16 <SpaceToast> (or, 0.20190604 in our packaging)
2019-06-07 13:18:19 <SpaceToast> Heya jwh :)
2019-06-07 13:18:25 <jwh> whats up
2019-06-07 13:19:01 <SpaceToast> Weird stuff, apparently, also going to work
2019-06-07 13:19:01 <tmhoang> maxice8 : how do you know that minio has been built again and again after each git push ?
2019-06-07 13:19:03 <Cogitri> <SpaceToast "cogitri: could you send that lin"> Sure
2019-06-07 13:19:10 <jwh> weird stuff huh
2019-06-07 13:20:15 <tmhoang> it seems it is not built, really
2019-06-07 13:20:17 <maxice8> tmhoang: build.a.o
2019-06-07 13:20:22 <tmhoang> thanks
2019-06-07 13:20:24 <tmhoang> hmm
2019-06-07 13:22:27 <ncopa> mps: https://patchwork.alpinelinux.org/patch/4908/ merged thanks
2019-06-07 13:24:48 <Cogitri> Someone up for taking a look at pr7500?
2019-06-07 13:25:26 <Cogitri> It only goes to testing/ for checking it it builds on all arches, will move it to main/ if it works and them submit PRs for all the other LLVM8 related stuff which has been blocking on this for some time
2019-06-07 13:33:36 <mps> ncopa: I've seen on #alpine-commits. thanks
2019-06-07 13:44:57 <ncopa> Cogitri: is it ready to pull?
2019-06-07 13:45:26 <ncopa> seems so
2019-06-07 13:46:10 <Cogitri> I suppose so. Yes
2019-06-07 13:49:35 <mps> finally, let's see
2019-06-07 13:50:53 <Cogitri> Thank you :)
2019-06-07 13:54:20 <Cogitri> Can I see buildfailures on build.alpinelinux.org, or do I have to manually check logs?
2019-06-07 13:55:20 <ncopa> you should be able to see build failures on build.a.o, with link to build log
2019-06-07 13:59:16 <_ikke_> yes, it links to the log
2019-06-07 13:59:25 <_ikke_> You can click on the package names
2019-06-07 13:59:33 <Cogitri> Ah right, just noticed the "last error" column
2019-06-07 14:00:28 <Cogitri> Alright, thanks for the info
2019-06-07 14:07:47 <Cogitri> Seems like it built successfully on all arches, hooray
2019-06-07 14:08:48 <mps> I told you two months ago, iirc :)
2019-06-07 14:13:37 <Cogitri> Yup, but not for s390x and ppc64le :)
2019-06-07 14:13:39 <Cogitri> Thanks for testing aarch64 and armv7
2019-06-07 14:14:51 <mps> eh, I don't have these two, and I don't know anything about them
2019-06-07 14:17:25 <Cogitri> That's what I meant :)
2019-06-07 14:19:01 <tcely> It'd be great to have s390x qemu setup on TravisCI
2019-06-07 14:19:32 <tcely> I keep meaning to look into docker multiarch for this
2019-06-07 14:21:30 <Cogitri> Yup, that'd be very nice
2019-06-07 17:19:45 <tmhoang> very cool when your remote mirror is not local, but public : https://blog.haschek.at/2019/build-your-own-datacenter-with-pxe-and-alpine.html
2019-06-07 17:20:59 <tmhoang> <tcely> It'd be great to have s390x qemu setup on TravisCI : soon, hopefully qemu 4.1
2019-06-07 17:21:07 <tmhoang> <tcely> It'd be great to have s390x qemu setup on TravisCI : soon, hopefully when qemu 4.1 is out
2019-06-07 17:23:41 <ncopa> tmhoang: i dont really understand https://github.com/alpinelinux/mkinitfs/pull/52
2019-06-07 17:24:51 <ncopa> as i understand the setup_inittab_console, it will resolve what ever console=foobar was specified ad boot option, and make sure that this tty is listed in inittab
2019-06-07 17:41:16 <_ikke_> ncopa: this is what buildrepo -n community returns on the armv7 builder: http://tpaste.us/RgJr
2019-06-07 17:42:23 <ncopa> will check it in a second
2019-06-07 17:42:48 <ncopa> i wonder if we should replace the .iso image with an ext2 .img
2019-06-07 17:43:29 <_ikke_> I don't think a lot of people burn cd's / dvd's anymore
2019-06-07 17:43:37 <ncopa> thats what i mean
2019-06-07 17:44:07 <ncopa> and an ext2 image is writable, while iso is readonly
2019-06-07 17:44:15 <_ikke_> I'd be in favor, just being able to dd the image to a usb is a win
2019-06-07 17:44:18 <ncopa> in case you want modify boot option
2019-06-07 17:44:19 <_ikke_> with it being writable
2019-06-07 17:44:35 <ncopa> and you can boot it directly from qemu
2019-06-07 17:44:59 <_ikke_> Hmm, I can boot the iso also directly via qemu
2019-06-07 17:45:16 <ncopa> but its not writable
2019-06-07 17:45:19 <_ikke_> nope
2019-06-07 17:45:21 <_ikke_> true
2019-06-07 17:45:24 <ncopa> its isohybrid
2019-06-07 17:45:33 <ncopa> so you can actually dd it directly to usb
2019-06-07 17:45:45 <_ikke_> yes, that's a big advantage
2019-06-07 17:47:05 <ncopa> i suspect that the read-only problem is the underlying problem that https://github.com/alpinelinux/mkinitfs/pull/52 tries to work around
2019-06-07 17:52:01 <mps> I'm also for ext2/3/4, whatever
2019-06-07 17:54:20 <mps> also thinking to make .img for some of my arm boards which can be dd-ed to sd card and boot
2019-06-07 17:54:45 <Cogitri> Making the isos writeable would be very nice indeed
2019-06-07 17:55:04 <Cogitri> Would make it a lot easier to make VMs to test stuff on, hopefully
2019-06-07 17:56:05 <mps> ncopa: If you have time please PM me, about uploading crystal static tarballs to dev.a.o
2019-06-07 18:03:45 <ncopa> _ikke_: armv7 builder will have to wait til monday
2019-06-07 18:03:54 <ncopa> im gonna tag rc2 now
2019-06-07 18:07:19 <_ikke_> Any way I can debug it myself?
2019-06-07 18:07:26 <_ikke_> I can try to manually run the build script?
2019-06-07 18:37:04 <_ikke_> I think I found out what's going on
2019-06-07 18:37:37 <_ikke_> Something installed a bunch of hooks in the aports repo again (husky?)
2019-06-07 18:39:39 <mps> meh, who uses JS deserves JS ;)
2019-06-07 18:40:23 <mps> sorry for joking around
2019-06-07 18:40:25 <danieli> is fabled around?
2019-06-07 18:41:03 <danieli> i was going to ask if there is a reason there's no gtk3 build of alpine's emacs, and if i can create it
2019-06-07 18:53:57 <Cogitri> Now that LLVM8 has built successfully I've opened a PR to move it to main: pr8620
2019-06-07 18:54:19 <danieli> wonderful!
2019-06-07 18:56:55 <mps> Cogitri: did you tried to build clang with it
2019-06-07 19:12:06 <Cogitri> mps: Yup, I already built everything LLVM related with it
2019-06-07 19:12:34 <Cogitri> See pr8585 and pr8584
2019-06-07 19:12:57 <_ikke_> So I do think that the armv7 builder is now unstuck again, but it does not build the package that need to be built yet
2019-06-07 19:13:08 <_ikke_> It might just require one package to be pushed
2019-06-07 19:14:00 <danieli> I'll pay attention to the raw MQTT messages and see what it has to say for itself
2019-06-07 19:14:47 <_ikke_> right now it would just say nothign to build
2019-06-07 19:14:51 <Cogitri> mps: Only for x86_64 of course, so yeah :)
2019-06-07 19:15:11 <_ikke_> but if I use buildrepo -n community, it does list an amount of packages to build
2019-06-07 19:15:49 <danieli> build/build-3-10-armv7 idle
2019-06-07 19:16:04 <danieli> two 3.8 builders (ppc, armhf) apparently don't like the package hylafaxplus
2019-06-07 19:19:17 <_ikke_> We might want to set GIT_CEILING_DIRECTORIES="$srcdir" in abuild somewhere to prevent packages from clobbering the aports repo
2019-06-07 19:19:33 <_ikke_> either $srcdir or $startdir
2019-06-07 19:37:22 <tcely> I vote for $startdir
2019-06-07 19:54:25 <tcely> Please merge pr8625 to fix the comment stale adds
2019-06-07 20:17:48 <danieli> we don't seem to have a package for https://github.com/tj/git-extras, do we?
2019-06-07 20:19:55 <_ikke_> Don't think so
2019-06-07 20:20:08 <danieli> i'll put it in my todo, it's full of handy tools
2019-06-07 20:20:16 <danieli> and it's just a 'make install' away
2019-06-07 20:20:19 <_ikke_> Just looking through it
2019-06-07 20:21:00 <danieli> shame it seems to rely on bashj
2019-06-07 20:21:03 <danieli> s/j//
2019-06-07 20:21:03 <alpine-meetbot> danieli meant to say: shame it seems to rely on bash
2019-06-07 20:22:13 <tcely> I'm a bit surprised git itself doesn't depend on bash
2019-06-07 20:22:45 <danieli> it's over 30% sh so same here
2019-06-07 20:24:33 <_ikke_> amound of shell scritping is decreasing as more and more is being ported to c
2019-06-07 20:36:34 <tcely> Heh. git aliases is one of the first aliases I added after discovering git had an alias feature.
2019-06-07 20:36:59 <tcely> git-extras has git alias pretty well defined
2019-06-07 20:38:36 <tcely> ooh. I like git guilt too
2019-06-07 20:38:40 <danieli> i found about git aliases fairly soon after i started using git, and it's great
2019-06-07 20:39:43 <Cogitri> 
ACTION notices that he really doesn't use his CLI's power at all

2019-06-07 20:40:15 <danieli> i'm considering going back to using zsh, it's good looking and ergonomic
2019-06-07 20:40:28 <danieli> otoh i'm considering using emacs for everything
2019-06-07 20:41:22 <Cogitri> I'm using FISH right now, it's pretty nice
2019-06-07 20:49:23 <tcely> oh, nice. (git pr 226 upstream) I still prefer my git req 226 that finds my local branch from the pr number though.
2019-06-07 20:51:15 <tcely> git rebase-patch looks very handy too
2019-06-07 20:51:36 <tcely> I'd have to disable git clear, that's just too dangerous
2019-06-07 20:52:43 <danieli> git-rebase-patch is great
2019-06-07 20:52:48 <danieli> when it works, that is
2019-06-07 20:55:06 <danieli> mps: i'm submitting erlang/elixir patches to github instead of patchwork, hopefully they'll get applied within a reasonable time frame
2019-06-07 20:55:22 <danieli> (i also fixed the thing that broke last time)
2019-06-07 20:55:46 <mps> danieli: ok, I will test when you post it
2019-06-07 20:56:36 <danieli> dlsym: Resource temporarily unavailable
2019-06-07 20:56:37 <danieli> ouch
2019-06-07 21:00:16 <danieli> it does not like llvm's profiling
2019-06-07 21:00:44 <mps> which llvm version
2019-06-07 21:02:08 <danieli> i said that because i saw stuff referencing LLVM_PROFILE_FILE, but i'm gonna test some things and see if i can monkey patch it
2019-06-07 21:04:20 <danieli> fixed it, it needed perl
2019-06-07 21:04:39 <danieli> oop, nevermind, it was just slow
2019-06-07 21:09:08 <Cogitri> So I'm currently on my quest of removing old LLVMs
2019-06-07 21:09:16 <Cogitri> Does someone happen to know ghc a bit and feels like looking into making it work with newer LLVMs?
2019-06-07 21:09:47 <danieli> I know haskell and I'm vaguely familiar with ghc, so I might be able to find a fix through trial-and-error
2019-06-07 21:10:09 <tmhoang> <ncopa> tmhoang: i dont really understand https://github.com/alpinelinux/mkinitfs/pull/52 : the first change is to use sclp_line0 instead of ttyS0. ttyS0 is reported as active in /sys/class/tty/console/active but in fact /sys/class/tty/ttS0 does not exist. Instead, sclp_line0 exists.
2019-06-07 21:11:31 <tmhoang> ncopa: for the later for loop, the logic is the same as systemd : https://github.com/systemd/systemd/blob/master/src/getty-generator/getty-generator.c#L185
2019-06-07 21:12:52 <tmhoang> to rephrase, when sclp_line0 is active, ttyS0 should be not available (as /sys/class/tty/ttyS0 does not exist) but somehow (idk why) /sys/class/tty/console/active reports ttyS0 exists.
2019-06-07 21:14:24 <tmhoang> my intention is to try to not break setup_inittab_console() recursive/recursitivity as much as possible.
2019-06-07 21:16:47 <tmhoang>  <ncopa> i suspect that the read-only problem is the underlying problem that https://github.com/alpinelinux/mkinitfs/pull/52 tries to work around : might be related but I can't tell for sure. even when I use console=sclp_line0, ttyS0 still got reported in /sys/class/tty/console/active while /sys/class/tty/ttyS0 does not exist
2019-06-07 21:19:02 <tmhoang> so to give you a little bit of back ground : LPAR is the most 'bare-metal' s390x can get, even though it's still a 'logical' hardware. Imagine you can logically partition your 4-core laptop  into 2 machines 2-core each, and they can run Alpine and Ubuntu at the same time. That's what LPAR is on a mainframe machine.
2019-06-07 21:20:02 <tmhoang> to boot from a LPAR, you have a couple of option. 1 is to use FTP (kind of PXE) which I find the easiest for Alpine atm. It uses a file like this : http://ports.ubuntu.com/ubuntu-ports/dists/bionic-updates/main/installer-s390x/current/images/generic/ubuntu.ins
2019-06-07 21:21:00 <tmhoang> it tells the lpar loader the kernel + initrd in the same ftp server directory, along with a .parm file.
2019-06-07 21:21:15 <tmhoang> basically the same stuff we boot in KVM and z/VM
2019-06-07 21:22:05 <tmhoang> now the problem I'm thinking is how to publish a .parm file on dl-cdn.a.o/netboot/ so that user can fetch directly .ins and use that .parm
2019-06-07 21:22:30 <tmhoang> but it's not possible because users needs to  modify the .parm for his needs (ip=, dasd=, modloop=, alpine_repo=)
2019-06-07 21:23:26 <tmhoang> Debian/Ubuntu they can make an empty .parm file because : their initrd allows users to answer a couple of questions at first so they can get ip=, modloop=, alpine_repo=, etc.
2019-06-07 21:24:03 <tmhoang> If I go that way (I could make it though), it would make a lot of change for Alpine initramfs, for which I'm afraid it would cost you many headache :)
2019-06-07 21:24:20 <tmhoang> or, we could have a separate initramfs-init for that purpose.
2019-06-07 21:27:02 <tmhoang> hope this helps : https://wiki.ubuntu.com/S390X/Installation%20In%20LPAR
2019-06-07 21:28:54 <tmhoang> same on z/VM where they make users to answer bunch of questions (which we solved by letting users using their custom .parm file) https://wiki.ubuntu.com/S390X/Installation%20In%20zVM
2019-06-07 21:29:38 <tmhoang> one place  Alpine was behind, another Alpine is much more convenient :)
2019-06-07 21:35:40 <mps> eh, nice, just read that the " A compatible C version is going to be available by default." of bzip2
2019-06-07 21:37:43 <Cogitri> danieli: that'd be amazing! Sadly I don't know any haskell, so I don't think I can be of help :c
2019-06-07 21:38:26 <danieli> it's not super easy to get into if you're used to conventional languages, but it's beautiful
2019-06-07 21:39:14 <mps> is haskel some dialect of erlang or modeled after erlang
2019-06-07 21:39:25 <_ikke_> I don't think so
2019-06-07 21:39:53 <danieli> it is not
2019-06-07 21:40:07 <danieli> it's an entirely separate language
2019-06-07 21:40:15 <mps> long time ago I read about erlang and it looked quite good language but I never had use case for it
2019-06-07 21:41:03 <Cogitri> Yeah, I think I'm happy with Rust for now :)
2019-06-07 21:41:10 <mps> but didn't looked to haskel, maybe sometimes skimmed over some texts about it
2019-06-07 21:41:19 <danieli> some language are especially optimized for their niche, but you can still use them for other things
2019-06-07 21:54:56 <_ikke_> abuild does interact with git though, so we cannot just globally set GIT_CEILING_DIRECTORIES
2019-06-07 21:56:46 <danieli> would it be possible to set it only for certain abuild subcommands (ones that don't modify git)?
2019-06-07 21:57:01 <_ikke_> yes¸ was thinking about that
2019-06-07 22:15:26 <SpaceToast> Erlang is ok, but it's really all about OTP
2019-06-07 22:15:43 <SpaceToast> Would be nice if someone picked up Erlang, by the way
2019-06-07 22:16:09 <SpaceToast> I'm only even barely a consumer of OTP, but I would consider packaging funny things like couchdb
2019-06-07 22:19:07 <danieli> i was planning to, but patches take ages to go through
2019-06-07 22:19:23 <danieli> there are people using both elixir and erlang on alpine fwiw
2019-06-07 23:30:40 <danieli> does the check() function automatically cd to $builddir now too?
2019-06-07 23:31:17 <mps> it does, afaik
2019-06-07 23:39:01 <SpaceToast> Yes, it's prepare, build, check and package
2019-06-07 23:39:05 <SpaceToast> From what I recall
2019-06-08 01:36:21 <danieli> mps: not quite sure how aports is set up on github, but can I push erlang upgrade and then a handful of commits to rebuild packages in the same PR?
2019-06-08 01:36:47 <danieli> er
2019-06-08 01:36:54 <danieli> you might be the wrong person to ask, now that i think about it
2019-06-08 01:36:59 <danieli> my bad :)
2019-06-08 01:36:59 <SpaceToast> danieli: yes
2019-06-08 01:37:09 <SpaceToast> PRs can have multiple commits
2019-06-08 01:37:09 <danieli> ok thanks
2019-06-08 01:37:13 <SpaceToast> not sure how CI will deal with it, though
2019-06-08 01:37:18 <SpaceToast> since CI's done through some weird script
2019-06-08 01:37:18 <danieli> yes, but the order matters
2019-06-08 01:37:26 <jwh> it should trigger a rebuild for each one in order
2019-06-08 01:37:29 <SpaceToast> yeah, order will be preserved :)
2019-06-08 01:37:30 <jwh> (queued)
2019-06-08 01:37:37 <danieli> okay, great
2019-06-08 01:37:42 <SpaceToast> welcome back, by the way, danieli :)
2019-06-08 01:56:05 <danieli> 7 commits in pr8629
2019-06-08 01:56:38 <SpaceToast> nice :)
2019-06-08 01:56:41 <danieli> CI *might* fail because I changed a few things to speed it up, but hopefully it won't choke
2019-06-08 02:19:45 <danieli> right, no openjdk >9 on x86, i'll rebuild erlang's jinterface with openjdk9
2019-06-08 02:29:29 <SpaceToast> danieli: if you want to make CI happy, you'll need to git rebase -i and change the first commit
2019-06-08 02:29:37 <SpaceToast> (it'll bail on the first error, instead of retrying later)
2019-06-08 02:29:47 <danieli> god damn it, i just pushed a commit to fix the first one
2019-06-08 02:30:01 <SpaceToast> that's why I mentioned it
2019-06-08 02:30:10 <SpaceToast> I'm keeping an eye on the pr, since I'm interested
2019-06-08 02:32:54 <danieli> man, i'm getting rusty at the gh workflow
2019-06-08 02:35:08 <danieli> SpaceToast: all right, I just edit the commit without changing the message and then push that? do I need to undo the last (separate) commit to explicitly use jdk9?
2019-06-08 02:35:49 <SpaceToast> you do `git rebase -i`, you want to drop that last one, and edit the one with erlang
2019-06-08 02:35:59 <danieli> fair enough, gotcha
2019-06-08 02:36:01 <SpaceToast> then you make your change, and do the rebase thing
2019-06-08 02:36:06 <SpaceToast> then you push force
2019-06-08 02:36:21 <SpaceToast> sorry for lack of details, I'm really tired after work today :/
2019-06-08 02:37:50 <danieli> all right, done
2019-06-08 02:38:08 <danieli> argh
2019-06-08 02:38:44 <danieli> do i force push that then?
2019-06-08 02:38:48 <SpaceToast> yeah
2019-06-08 02:38:56 <SpaceToast> since you're rewriting history (i.e past commits)
2019-06-08 02:38:59 <danieli> true
2019-06-08 02:39:01 <danieli> thanks
2019-06-08 02:39:07 <SpaceToast> no worries
2019-06-08 02:39:17 <danieli> there, great
2019-06-08 02:40:01 <SpaceToast> there we are :D
2019-06-08 02:41:57 <danieli> thank you <3
2019-06-08 02:42:22 <danieli> ii really need to make a couple repos and play around with GH, it's been a while since i used it regularly
2019-06-08 02:42:53 <SpaceToast> if you want/need any help, I'm willing to try :)
2019-06-08 02:44:10 <danieli> don't get me wrong, I'm at least 'adept' at git, I just don't remember too much of the github (and GH CI) intrinsics
2019-06-08 02:44:14 <danieli> it's been too much azure devops, gitolite, and gitlab for me :(
2019-06-08 02:44:42 <SpaceToast> oh I'm not saying that in a diminutive way, I'm just offering any help I can provide
2019-06-08 02:44:45 <SpaceToast> because... I can!
2019-06-08 02:45:05 <SpaceToast> and you're not the sort of person to pull specific things that annoy me (in that regard), so there's no serious downside
2019-06-08 02:45:18 <SpaceToast> everyone getting a little bit better (or less rusty) is good for everyone
2019-06-08 03:03:45 <danieli> seriously? openjdk9 isn't built for x86 either?
2019-06-08 03:04:04 <danieli> the comment i looked at said openjdk 10 isn't available for 32-bit
2019-06-08 03:04:14 <danieli> guess i'll have to use openjdk8.. ugh
2019-06-08 03:06:10 <SpaceToast> at that point I wonder if you should have different deps based on arch
2019-06-08 03:06:14 <SpaceToast> 8 is just really old
2019-06-08 03:08:06 <danieli> true, but so is erlang and its jinterface. sounds like java 8 will die within the end of 2020
2019-06-08 03:08:44 <SpaceToast> does anything use the jinterface anyway?
2019-06-08 03:08:49 <danieli> practically nothing
2019-06-08 03:08:52 <danieli> well
2019-06-08 03:09:03 <danieli> it's probably in use in some company somewhere, i can almost guarantee it
2019-06-08 03:09:38 <danieli> most popular/old/well-known software projects have non-vocal users
2019-06-08 03:10:12 <danieli> sometimes when alpine removes stuff, people we've never seen before go "hey, we were using <obscure feature>!"
2019-06-08 03:36:38 <danieli> god damn it
2019-06-08 03:36:40 <danieli> configure: WARNING: Could not find any usable java compiler, will skip: jinterface
2019-06-08 03:36:40 <danieli> ./configure: line 22150: can't create /home/buildozer/aports/community/erlang/src/otp-OTP-22.0.2/lib/ic/java_src/SKIP: nonexistent directory
2019-06-08 03:39:49 <danieli> ... crap, it's hardcoded
2019-06-08 11:09:10 <mps> how we handle pkg's with -rcX releases? bumping pkgrel every time and again when final pkg without -rc is released
2019-06-08 11:11:58 <_ikke_> Do we even want to package the rc releases?
2019-06-08 11:14:29 <mps> well, sometimes we have no choice.
2019-06-08 11:15:36 <mps> latest stable of http://www.linux-ax25.org/pub/libax25/ is 0.0.11 from 2003-03-16
2019-06-08 11:16:48 <mps> and 0.0.12 is now actively develped, current is libax25-0.0.12-rc5 019-04-02
2019-06-08 11:17:32 <mps> and yesterday we see v3.10-rc2 :)
2019-06-08 11:17:48 <mps> s/see/see Alpine/
2019-06-08 11:17:48 <alpine-meetbot> mps meant to say: and yesterday we see Alpine v3.10-rc2 :)
2019-06-08 11:28:55 <tmhoang> their rcX have been spanning for the last decade so I guess their rcX must be acting like a normal release ...
2019-06-08 11:30:03 <tmhoang> feels a lot like quit smoking
2019-06-08 11:33:54 <_ikke_> mps: 0.0.12-rc5 is a valid version
2019-06-08 11:34:49 <_ikke_> So not sure why you need to bump pkgre
2019-06-08 11:34:53 <_ikke_> pkgrel
2019-06-08 11:45:13 <mps> tmhoang: why anyone want to quit smoking :/
2019-06-08 11:45:48 <tmhoang> mps: people do things for different purpose because of different reasons
2019-06-08 11:46:03 <mps> _ikke_: ok, will try then with pkgver="0.0.12-rc5"
2019-06-08 11:46:36 <maxice8> alint warns on pkgver having -r or _r
2019-06-08 11:47:04 <mps> maxice8: I thought so, because that I wrote 'will try'
2019-06-08 11:50:22 <_ikke_> maxice8: well -rc *is* valid
2019-06-08 11:50:25 <_ikke_> not -r
2019-06-08 11:58:06 <mps> yes, '-r' is not valid, I remember when upgrading android-tools, and because that android-tools have '-p'
2019-06-08 12:09:11 <mps> my main doubt about this is when (and if) the stable released it will be 0.0.12. so I think apk will not know that it needs to be upgraded
2019-06-08 12:11:38 <_ikke_> it does
2019-06-08 12:12:10 <_ikke_> apk version -t 0.0.11-rc5 0.0.12
2019-06-08 12:12:13 <_ikke_> <
2019-06-08 12:12:42 <_ikke_> oh, 0.0.12-rc5
2019-06-08 12:13:01 <_ikke_> >
2019-06-08 12:14:06 <_ikke_> rc is considered a pre suffic.., strange
2019-06-08 12:16:03 <mps> _ikke_: did you mean ' apk version -t 0.0.12-rc5 0.0.12'  instead of 0.0.11-rc5
2019-06-08 12:16:28 <mps> ah, sorry
2019-06-08 12:16:45 <mps> I should read with more care
2019-06-08 12:22:18 <mps> hmm, pkgname community/perl-crypt-rc4
2019-06-08 13:41:04 <kpcyrd> is there a binary I can use to compare versions the same way apk does it? sort of like vercmp in the pacman package
2019-06-08 13:41:47 <_ikke_> kpcyrd: apk version -t <v1> <v2>
2019-06-08 13:42:27 <kpcyrd> _ikke_: thanks!
2019-06-08 13:42:46 <Danct12> `install -m 0755 src/egl/opengl/{eglgears_x11,eglinfo,eglkms,egltri_x11,peglgears,xeglgears,xeglthreads} "${pkgdir}/usr/bin/"`
2019-06-08 13:42:48 <Danct12> how can I do this with abuild?
2019-06-08 13:42:52 <Danct12> because when i do that all i get is `install: can't stat 'src/egl/opengl/{eglgears_x11,eglinfo,eglkms,egltri_x11,peglgears,xeglgears,xeglthreads}': No such file or directory`
2019-06-08 13:44:51 <Danct12> the thing i want here is to copy all of those files
2019-06-08 13:45:03 <danieli> because that's a bash-specific feature
2019-06-08 13:46:03 <_ikke_> posix sh does not have brace expansion
2019-06-08 13:46:09 <danieli> yes
2019-06-08 13:46:13 <Danct12> hmm, then what is on ash shell?
2019-06-08 13:46:18 <danieli> you can do `for something in eglgears_x11 eglinfo eglkms egltri_x11 peglgears xeglgears xeglthreads; do install -m0755 src/egl/opengl/"$something" "$pkgdir"/usr/bin/; done
2019-06-08 13:46:26 <danieli> you get the idea
2019-06-08 13:46:39 <_ikke_> probably -Dm0755 so leading paths get automatically created
2019-06-08 13:46:42 <danieli> yes
2019-06-08 13:46:45 <danieli> good point
2019-06-08 13:47:10 <Danct12> right, thanks!
2019-06-08 14:52:54 <danieli> _ikke_: fixed it
2019-06-08 14:58:52 <_ikke_> thanks, saw CI running
2019-06-08 15:03:04 <SpaceToast> ping maxice8 - hyperfine 1.6 is out :D
2019-06-08 15:06:22 <danieli> i re-enabled all the test suites that were disabled and changed concurrency during build a bit, so it might take a while
2019-06-08 15:10:08 <maxice8> SpaceToast: thank you Early Warning System
2019-06-08 15:10:29 <maxice8> I'm out buying food so will update later
2019-06-08 15:10:34 <SpaceToast> :) nw
2019-06-08 15:11:09 <SpaceToast> I just found out you actually packaged it up (was on my todo list), and I got my own EWS (sharkdp pinged me about it because apparently my PR made it into that release)
2019-06-08 15:11:31 <SpaceToast> so I got a bit excited immediately after waking up; sorry if it was a bother :)
2019-06-08 15:18:20 <maxice8> Nw am waiting for lift home
2019-06-08 15:27:03 <_ikke_> mps:
2019-06-08 15:27:05 <_ikke_> ping
2019-06-08 15:31:26 <maxice8> SpaceToast: I also use newsboat with releases.atom of all packages i maintain (i hope i didn't miss any)
2019-06-08 15:31:44 <maxice8> only works for github projects but i mostly are or i find a mirror of it
2019-06-08 15:31:53 <SpaceToast> I use github's new "watch releases" feature
2019-06-08 15:32:13 <SpaceToast> for non-github stuff I subscribe to the ML and cry (though I don't actually maintain any of those quite yet (?))
2019-06-08 15:32:38 <_ikke_> Yeah, I like that gh feature
2019-06-08 15:32:47 <maxice8> i have my repology feed as well
2019-06-08 15:33:29 <SpaceToast> repology is pretty cool
2019-06-08 15:33:36 <maxice8> https://repology.org/maintainer/thinkabit.ukim%40gmail.com/feed-for-repo/alpine_edge
2019-06-08 15:33:41 <SpaceToast> unfortunately this is one area gitlab's quite behind on (they only recently got releases in general)
2019-06-08 15:33:53 <maxice8> lol i got 65 outdated packages on VL
2019-06-08 15:35:07 <Cogitri> <SpaceToast "unfortunately this is one area g"> Yeah, before they only had RSS which also included issues which was duper annoying
2019-06-08 15:35:22 <danieli> shouldn't be awfully hard for us to implement package version tracking in gitlab
2019-06-08 15:35:25 <SpaceToast> well even now, the whole "release" ecosystem is pretty far behind GH
2019-06-08 15:35:26 <danieli> given some effort anyway
2019-06-08 15:38:13 <kpcyrd> ncopa: https://tests.reproducible-builds.org/alpine/main/libao/libao-1.2.2-r0.apk.html \o/
2019-06-08 15:38:36 <kpcyrd> there are still some things to do, but we're building packages and running diffoscope now
2019-06-08 15:38:55 <danieli> yeah, i started writing an emacs package to parse apk stuff and do cool things
2019-06-08 15:39:04 <danieli> also going to continue working on some py bindings
2019-06-08 15:44:23 <danieli> re #10546: think we should apply debian's patch until upstream has fixed it?
2019-06-08 15:45:11 <SpaceToast> assuming it fixes it, looks like a nice and concrete patch to me
2019-06-08 15:45:49 <danieli> lgtm
2019-06-08 15:45:57 <danieli> i can PR it right away
2019-06-08 15:46:01 <SpaceToast> not sure about __attribute__ stuff, but as long as builders use latest-ish gcc it should be fine
2019-06-08 15:46:09 <SpaceToast> sounds good, I'll review if you'll link
2019-06-08 15:46:19 <danieli> I'll just apply the patch and not touch anything else, but sure
2019-06-08 15:46:53 <SpaceToast> reviews aren't necessarily just about catching mistakes :)
2019-06-08 15:46:58 <danieli> and well, the optimize("O0") is probably to unbreak whatever GCC 8.2.0 broke
2019-06-08 15:47:04 <danieli> m
2019-06-08 15:47:06 <danieli> mm*
2019-06-08 15:47:21 <SpaceToast> they're also about signaling to people with push access that "hey, this might not actually be insane"
2019-06-08 15:47:26 <SpaceToast> (though, primarily about catching mistakes)
2019-06-08 15:47:44 <SpaceToast> in scenarios where relatively few people actually have push this kind of tiered signaling system is particularly important
2019-06-08 15:50:10 <danieli> hm, all of a sudden an elixir test failed
2019-06-08 15:50:12 <danieli> what the hek
2019-06-08 15:50:55 <SpaceToast> you re-enabled a bunch of tests, right?
2019-06-08 15:51:03 <SpaceToast> maybe some (?) of them were in fact still broken
2019-06-08 15:51:24 <SpaceToast> or, since travis passed, it might be a container thing (neither drone nor the builders run lxcfs)
2019-06-08 15:51:27 <danieli> i *believe* the elixir ones were good, and it compiled on my box
2019-06-08 15:51:29 <mps> _ikke_: I'm here now
2019-06-08 15:51:44 <danieli> it's just such an obscure error, a seemingly random test failed
2019-06-08 15:52:01 <danieli> it started an application when it was meant not to (it was given the --no-start flag)
2019-06-08 15:52:06 <_ikke_> mps: so I found out, 0.0.12_rc5 is considered older than 0.0.12
2019-06-08 15:52:15 <_ikke_> so with an _, not a -
2019-06-08 15:52:19 <SpaceToast> ah, sounds like an upstream thing, then
2019-06-08 15:52:42 <mps> so, I have to rewrite it
2019-06-08 15:54:15 <mps> I looked in community/ftgl/APKBUILD, it have pkgver=2.1.3_rc5 and _pkgver=2.1.3-rc5
2019-06-08 15:56:19 <mps> and main/syslinux have something similar
2019-06-08 15:57:28 <_ikke_> Choice of the maintainer I guess
2019-06-08 15:57:35 <_ikke_> It means you need to make sure both are updated at the same time
2019-06-08 15:58:17 <mps> yes, I think so, care is needed for such cases.
2019-06-08 15:59:16 <SpaceToast> fyi, the actual policy says "similar to gentoo"
2019-06-08 15:59:17 <mps> btw, I noticed that libax25 (which I'm preparing) doesn't build shared libs, just static. Will contact upstream and ask
2019-06-08 15:59:19 <SpaceToast> this is the gentoo doc: https://wiki.gentoo.org/wiki/Version_specifier
2019-06-08 16:00:02 <mps> SpaceToast: thanks
2019-06-08 16:00:09 <SpaceToast> funny enough, no rc examples; but in the practical examples, they use _rc5
2019-06-08 16:00:10 <_ikke_> SpaceToast: I was looking at what apk version considers an older version
2019-06-08 16:00:13 <SpaceToast> (example: https://packages.gentoo.org/packages/media-libs/ftgl )
2019-06-08 16:00:16 <_ikke_> yes
2019-06-08 16:00:31 <_ikke_> 0.0.12-rc5 is considered newer than 0.0.12
2019-06-08 16:00:31 <mps> _ikke_: thank you for help
2019-06-08 16:00:43 <_ikke_> but 0.0.12_rc5 is considered older, which is what you want
2019-06-08 16:00:52 <_ikke_> mps: no worry
2019-06-08 16:00:59 <SpaceToast> so _rc5 should be preferred, then :)
2019-06-08 16:01:28 <_ikke_> same with git
2019-06-08 16:01:31 <_ikke_> 0_git123456
2019-06-08 16:01:36 <_ikke_> the _ is the separater
2019-06-08 16:01:52 <alpine-meetbot> _ikke_ meant to say: the _ is the separator
2019-06-08 16:01:52 <_ikke_> s/ter/tor/
2019-06-08 16:04:34 <_ikke_> SpaceToast: I got pinged about salt as well, it also has a new version
2019-06-08 16:04:43 <_ikke_> At least, according to someone
2019-06-08 16:04:44 <SpaceToast> _ikke_: it's not a real release (yet)
2019-06-08 16:04:49 <SpaceToast> it's just a branch-off
2019-06-08 16:04:52 <SpaceToast> full release will be in august
2019-06-08 16:04:54 <_ikke_> ah ok
2019-06-08 16:05:03 <SpaceToast> otherwise I woulda pinged you ^^
2019-06-08 16:05:16 <_ikke_> hehe, I would not expect anything else
2019-06-08 16:05:19 <SpaceToast> :)
2019-06-08 16:05:54 <_ikke_> ah, it came from anitya
2019-06-08 16:06:04 <_ikke_> Wonder why it thinks there is a new version already
2019-06-08 16:06:13 <SpaceToast> because they tagged the branch-off
2019-06-08 16:06:15 <SpaceToast> no idea why they did that
2019-06-08 16:06:25 <_ikke_> ah, great
2019-06-08 16:06:30 <SpaceToast> shows up over at https://github.com/saltstack/salt/releases too
2019-06-08 16:06:39 <SpaceToast> but I'm willing to bet we're not 2019.8 yet
2019-06-08 16:06:47 <SpaceToast> and the comment is "Branch point for the 2019.8 release"
2019-06-08 16:06:58 <_ikke_> 2019.2.0 is showing as the latest elease
2019-06-08 16:07:20 <SpaceToast> yeah, that's the one we got now
2019-06-08 16:07:32 <SpaceToast> there's just a non-release tag for 2019.8
2019-06-08 16:07:51 <_ikke_> they did that for 20192.2 as well
2019-06-08 16:07:57 <_ikke_> s/2.2/2
2019-06-08 16:07:57 <alpine-meetbot> _ikke_ meant to say: they did that for 20192 as well
2019-06-08 16:07:57 <SpaceToast> oh, hadn't noticed
2019-06-08 16:08:01 <SpaceToast> still pretty weird
2019-06-08 16:08:08 <_ikke_> it is
2019-06-08 16:08:13 <maxice8> SpaceToast: hyperfine is updated
2019-06-08 16:08:52 <SpaceToast> nice :)
2019-06-08 16:10:16 <_ikke_> Nice thing of managing packages is that you learn about a lot of tools :)
2019-06-08 16:11:38 <danieli> _ikke_: SpaceToast: pr8674
2019-06-08 16:13:42 <_ikke_> "prevent pow optmization" :D
2019-06-08 16:15:38 <_ikke_> maxice8: mplayer fails to build
2019-06-08 16:15:43 <_ikke_> https://build.alpinelinux.org/buildlogs/build-3-10-x86_64/community/mplayer/mplayer-1.4.0-r0.log
2019-06-08 16:15:44 <mps> I tried upgrade syslinux two months ago, but still didn't worked, maybe now it will
2019-06-08 16:15:46 <maxice8> yes
2019-06-08 16:15:49 <maxice8> i was asking myself
2019-06-08 16:16:05 <maxice8> "huh, he merged it, wasn't it failing drone-ci ?"
2019-06-08 16:16:10 <maxice8> guess the question my internal self was making was answered :D
2019-06-08 16:16:26 <_ikke_> I thought it was green :-/
2019-06-08 16:16:46 <maxice8> maybe you confused with appstream-glib that was red but i said i disabled the tests so it "should" be green now
2019-06-08 16:19:35 <mps> danieli: I think you need add pkgrel bump in 8674
2019-06-08 16:19:41 <danieli> mps: oops, forgot that
2019-06-08 16:19:44 <danieli> thanks! :)
2019-06-08 16:20:05 <mps> np
2019-06-08 16:20:33 <_ikke_> mps: this fixes it: http://tpaste.us/ZgN4
2019-06-08 16:20:38 <_ikke_> maxice8: *
2019-06-08 16:22:00 <maxice8> no need
2019-06-08 16:22:02 <_ikke_> maxice8: Not sure what the ${_ver/_/} is supposed to do
2019-06-08 16:22:03 <maxice8> just remove _ver altogether and use the substitution on builddir like it is done on source=
2019-06-08 16:22:05 <maxice8> made a PR and tagged you
2019-06-08 16:22:08 <_ikke_> ok
2019-06-08 16:22:57 <maxice8> Can you merge pr8650 while we're at it ? :D some gnome stuff need new vte3
2019-06-08 16:22:58 <_ikke_> maxice8: you tagged ncopa :)
2019-06-08 16:23:13 <maxice8> _ikke_: force of habit
2019-06-08 16:23:16 <maxice8> my bad
2019-06-08 16:24:16 <danieli> sorted the pkgrel
2019-06-08 16:25:39 <mps> _ikke_: don't understand, I didn't worked on mplayer
2019-06-08 16:25:54 <danieli> also, travis reports Successfully built packages: community/erlang community/cloudi community/elixir testing/ejabberd testing/rabbitmq-server testing/rebar3 testing/tsung
2019-06-08 16:25:58 <danieli> i wonder why the heck it fails on drone?
2019-06-08 16:26:09 <SpaceToast> might be the container stuff
2019-06-08 16:26:20 <SpaceToast> containers have a few minor differences from "real" machines, mostly in terms of hardware detection
2019-06-08 16:26:29 <danieli> well yeah, but the test in question didn't do any hardware detection
2019-06-08 16:26:38 <danieli> it's curious because it's such a random test to fail, it just doesn't make sense to me
2019-06-08 16:26:43 <_ikke_> mps: tab autocomplete mistake
2019-06-08 16:26:45 <SpaceToast> do you have a link to the source of the test? I'll take a look
2019-06-08 16:26:55 <danieli> i'll find it in a sec
2019-06-08 16:27:20 <mps> _ikke_: ok, np :)
2019-06-08 16:29:36 <danieli> SpaceToast: https://github.com/elixir-lang/elixir/blob/v1.8.2/lib/mix/test/mix/tasks/run_test.exs#L39
2019-06-08 16:29:43 <SpaceToast> danieli: thanks
2019-06-08 16:30:14 <danieli> code: refute List.keyfind(apps, :sample, 0)
2019-06-08 16:30:14 <danieli> Expected false or nil, got {:sample, 'sample', '0.1.0'}
2019-06-08 16:30:16 <SpaceToast> oh, it's a mix test, interesting
2019-06-08 16:31:22 <danieli> mix is used for everything in the elixir world, it's using ex_unit under the hood
2019-06-08 16:32:23 <SpaceToast> yeah, I just thought it was erlang that was failing, not elixir, for whatever reason
2019-06-08 16:33:31 <maxice8> _ikke_: travis-ci for mplayer failed because of log length
2019-06-08 16:33:36 <maxice8> drone-ci passed though
2019-06-08 16:34:26 <danieli> ah, no, erlang is fine, it just needed some minor changes to edit a patch, change some subpackages, and add the proper test suite
2019-06-08 16:34:58 <SpaceToast> looking at it, the only thing I can think of is ordering
2019-06-08 16:35:21 <SpaceToast> e.g a different test actually starts the application, doesn't clean up, and some state makes it through
2019-06-08 16:35:25 <SpaceToast> but that would be really weird
2019-06-08 16:44:25 <_ikke_> Cogitri: sysprof has some test failures on s390x
2019-06-08 16:45:14 <Cogitri> Yup, maxice8 already notified me
2019-06-08 16:45:33 <SpaceToast> maxice8: if I open an issue/pr re: hyperfine (and other packages, I just make the occasional pass) to notify them that official alpine packages are available; should I ping you (if I'm not the maintainer, but you are)?
2019-06-08 16:45:45 <SpaceToast> ultimately down to your comfort
2019-06-08 16:45:59 <Cogitri> Opened an issue upstream, but he's having a hard time debugging it without a s390x machine. I guess I'll just disable it on s390x since I doubt anyone is going to use GNOME stuff on those anyway
2019-06-08 16:46:04 <maxice8> SpaceToast: sure
2019-06-08 16:46:09 <SpaceToast> ok, ty
2019-06-08 16:53:27 <danieli> who was it that had issues with ghc?
2019-06-08 16:54:09 <Cogitri> I was
2019-06-08 19:21:10 <_ikke_> great, we lost curl on armv7 as well :-/
2019-06-08 19:21:48 <Cogitri> :/
2019-06-08 19:22:00 <_ikke_> Not sure what's going on
2019-06-08 19:31:20 <danieli> they just disappear?
2019-06-08 19:31:37 <danieli> oh - failed tests
2019-06-08 19:31:45 <mps> _ikke_: looks like dict server issue again
2019-06-08 19:32:00 <_ikke_> mps: dict server?
2019-06-08 19:32:19 <_ikke_> danieli: But even with failed tests, it should not remove the old package
2019-06-08 19:32:29 <danieli> true
2019-06-08 19:32:56 <mps> I forgot exactly what, but it appeared last year when I'm fixing something in curl
2019-06-08 19:33:38 <mps> let me try in lxc again
2019-06-08 19:34:01 <_ikke_> It appears to be that even when the build fails, it still does the synchronization
2019-06-08 19:34:51 <mps> network issue, I presume
2019-06-08 19:35:18 <_ikke_> It only happens when packages failed to build
2019-06-08 19:36:10 <mps> can't remember what was exactly last time :(
2019-06-08 19:37:20 <_ikke_> I don't see anything suspicious running on the builder
2019-06-08 19:38:53 <mps> env: can't execute 'python': No such file or directory
2019-06-08 19:39:34 <mps> could it be this ^
2019-06-08 19:40:16 <_ikke_> The logs show that a test failed due to not being able to bind to a port
2019-06-08 19:42:29 <mps> it pass in lxc armv7
2019-06-08 19:42:36 <mps> without problem
2019-06-08 19:42:47 <mps> apk is built
2019-06-08 19:43:20 <mps> ls -l: 103774 Jun  8 19:41 curl-7.65.1-r0.apk
2019-06-08 19:43:37 <_ikke_> Might have been a intermittent issue
2019-06-08 19:43:50 <mps> I think so
2019-06-08 19:44:17 <mps> ask algitbot to try again
2019-06-08 19:46:41 <_ikke_> It does not do anything
2019-06-08 19:47:23 <_ikke_> https://git.alpinelinux.org/aports/tree/main/aports-build/aports-build
2019-06-08 19:47:27 <_ikke_> This is the build script
2019-06-08 19:50:30 <mps> last night I had segfault on aarch64 builder, and asked algitbot. in second try all went well
2019-06-08 19:50:42 <_ikke_> yes
2019-06-08 19:50:44 <_ikke_> usually it does
2019-06-08 19:50:52 <_ikke_> But this is some kind of edge case
2019-06-08 19:50:59 <_ikke_> Only observer on armv7 so far
2019-06-08 19:51:08 <_ikke_> s/er/ed/
2019-06-08 19:51:08 <alpine-meetbot> _ikke_ meant to say: Only obsedver on armv7 so far
2019-06-08 19:51:29 <mps> I just tried in armv7 and it is done in first try with 'abuild -r'
2019-06-08 19:52:35 <mps> builders are also lxc's
2019-06-08 19:52:53 <_ikke_> yes
2019-06-08 19:54:09 <_ikke_> aha: WARNING: curl: Skipped due to previous build failure
2019-06-08 19:54:43 <mps> where you see this messages
2019-06-08 19:54:59 <_ikke_> on the builder
2019-06-08 19:55:12 <mps> you have access there?
2019-06-08 19:55:24 <_ikke_> to some of them, yes
2019-06-08 19:55:39 <mps> aha, ok
2019-06-08 20:04:12 <kpcyrd> is targz() in abuild used for anything?
2019-06-08 20:05:45 <_ikke_> mps: progress
2019-06-08 20:06:16 <mps> I see
2019-06-08 20:06:30 <SpaceToast> kpcyrd: naive grep through abuild and aports suggests not
2019-06-08 20:13:18 <mps> _ikke_: looks like curl is uploaded on armv7
2019-06-08 20:16:44 <_ikke_> yes
2019-06-08 20:31:38 <tmhoang> can we build regulatory.bin file in wireless-regdb ourselves instead copying the binary from source tar file ?
2019-06-08 20:34:00 <tmhoang> and for seriously xxx reasons, why they have to ship a binary. I'm trying to bypass this crda + wireless-regdb fuckshit
2019-06-08 20:35:50 <tmhoang> okay looks like this binary can be regenerated on user's hands
2019-06-08 20:36:14 <danieli> https://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git
2019-06-08 20:38:19 <danieli> kernel devs even sign it to make sure it hasn't been tampered with
2019-06-08 20:38:25 <kpcyrd> does somebody feel like reviewing my abuild patch? https://gitlab.com/kpcyrd/abuild/commit/d49d353a6b4ca71ae2cf72baf4e9252a660363ad.patch
2019-06-08 20:38:52 <danieli> alpine isn't on gitlab?
2019-06-08 20:38:59 <kpcyrd> that's my fork
2019-06-08 20:39:35 <kpcyrd> currently don't have access to my github account
2019-06-08 20:41:36 <kpcyrd> more info on SOURCE_DATE_EPOCH can be found here: https://reproducible-builds.org/docs/source-date-epoch/
2019-06-08 20:42:22 <danieli> looks fairly trivial, so lgtm 👍
2019-06-08 20:42:30 <kpcyrd> this patch makes abuild output _almost_ deterministic, the only thing left is the content of .SIGN.RSA.*.pub
2019-06-08 20:44:00 <tmhoang> danieli : I have been on edge but looks like my edge is behind 3.10 and current edge (3.10 alpine 20190228). Is it 'okay' if I changed my /etc/apk/repositories to 3.10 and just upgrade, and roll with it, since I want to switch to stable now.
2019-06-08 20:44:18 <danieli> kpcyrd: how come you removed the UTC flag from SOURCE_DATE_EPOCH=$(date +%s)?
2019-06-08 20:44:55 <danieli> tmhoang: well, some things may be missing, so if i were you, i'd check if the stuff installed on your system is on the apkindexes for 3.10 (for your arch)
2019-06-08 20:45:23 <kpcyrd> danieli: good catch, thanks
2019-06-08 20:45:46 <danieli> you could probably do some magic with apk info | xargs
2019-06-08 20:47:30 <danieli> kpcyrd: appreciate the effort btw, reproducible builds for alpine packages would be awesome
2019-06-08 20:47:58 <danieli> problem is that many of the regulars here are swamped in work already - dayjobs and maintenance
2019-06-08 20:48:19 <kpcyrd> (I'd love to show you the status website, but the guy who's supposed to deploy it is currently getting drunk)
2019-06-08 20:48:50 <jwh> good idea
2019-06-08 20:48:54 <kpcyrd> danieli: sure, no worries. I promised ncopa to set it up in December and I got around to do it now.
2019-06-08 20:49:17 <danieli> :) it is saturday afterall
2019-06-08 20:49:29 <danieli> I didn't sleep last night and I'm still being productive, somehow
2019-06-08 20:53:56 <_ikke_> building all community packages now which disappeared
2019-06-08 20:56:37 <[[sroracle]]> kpcyrd: awesome!
2019-06-08 20:57:35 <danieli> _ikke_: think there's any good way to monitor the box and check why it disappears?
2019-06-08 20:57:43 <kpcyrd> btw, there's #alpine-reproducible if anybody is interested
2019-06-08 20:57:54 <kpcyrd> I'd also like to transfer ownership of that channel eventually
2019-06-08 20:58:09 <danieli> i did not know that existed
2019-06-08 20:58:10 <_ikke_> danieli: my theory is: the option passed to buildrepo are -s -k -p -l
2019-06-08 20:58:15 <_ikke_> (on armv7)
2019-06-08 20:58:23 <_ikke_> -s means skip failed builds
2019-06-08 20:58:27 <_ikke_> -k means keep going
2019-06-08 20:58:30 <kpcyrd> danieli: it didn't until yesterday
2019-06-08 20:58:32 <_ikke_> -p means purge packages
2019-06-08 20:59:18 <danieli> _ikke_: hmm.. that sounds a bit self contradictory?
2019-06-08 21:00:05 <mps> kpcyrd: I don't know how reproducible build works but think it will good to have that
2019-06-08 21:00:45 <_ikke_> I think the combination of those options mean that if a package failes, it consequently gets removed due to -p
2019-06-08 21:01:16 <_ikke_> ok, that was community
2019-06-08 21:01:55 <kpcyrd> mps: the eventual goal is being able to rebuild any alpine package to verify I get the same binary
2019-06-08 21:02:01 <_ikke_> Cogitri: libgweather should be back
2019-06-08 21:02:13 <Cogitri> Great!
2019-06-08 21:02:53 <_ikke_> give it 15 minutes to sync to the repos
2019-06-08 21:03:01 <_ikke_> mirrors I mean
2019-06-08 21:03:40 <mps> kpcyrd: that's what I thought. this means we could rebuild complete previous stable release and got all binaries (and other things) in bit-by-bit same
2019-06-08 21:04:07 <mps> that will be very nice to have
2019-06-08 21:04:13 <kpcyrd> :)
2019-06-08 21:21:12 <p4Wv1qn095FW> kudos kpcyrd
2019-06-08 21:38:37 <SpaceToast> ping _ikke_ - could you take a look at pr8678? Ideally I'd like to do my regular "inform projects that alpine has official packages for them" pass today :)
2019-06-08 21:44:24 <_ikke_> checking
2019-06-08 21:45:01 <_ikke_> SpaceToast: is the description correct?
2019-06-08 21:45:29 <SpaceToast> as far as I know, yes; why?
2019-06-08 21:45:36 <_ikke_> a bat(1) clone?
2019-06-08 21:45:42 <_ikke_> bat: a bat(1) clone?
2019-06-08 21:45:47 <danieli> nananana batman
2019-06-08 21:45:57 <SpaceToast> oh wow
2019-06-08 21:46:00 <SpaceToast> how did that happen
2019-06-08 21:46:34 <SpaceToast> forcepush done
2019-06-08 21:46:38 <SpaceToast> thanks for catching that
2019-06-08 21:46:41 <danieli> welcome to the club :)
2019-06-08 21:46:47 <_ikke_> :)
2019-06-08 21:46:58 <danieli> i'm gonna do some work on getting ada stuff into alpine before i go sleep
2019-06-08 21:47:10 <danieli> oh f..., it's almost 12 am already
2019-06-08 21:47:12 <SpaceToast> attention span / 10
2019-06-08 21:47:20 <danieli> > cat
2019-06-08 21:47:45 <danieli> one glance and they've forgotten your existence
2019-06-08 21:48:06 <SpaceToast> it is definitely the package's fault :)
2019-06-08 21:48:40 <_ikke_> pushed
2019-06-08 21:49:24 <SpaceToast> thanks :)
2019-06-08 21:50:20 <SpaceToast> Cogitri: re: your comment; that line's from a general recommendation from one of my packages, so it's just part of my template for rust packages
2019-06-08 21:51:11 <SpaceToast> https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md
2019-06-08 21:51:24 <SpaceToast> crt-static is on by default on musl
2019-06-08 21:51:56 <Cogitri> <SpaceToast "crt-static is on by default on m"> Yeah, but I'm somewhat sure that we patch it out of our config
2019-06-08 21:51:58 <SpaceToast> and binary distributions typically prefer to be dynamic by default
2019-06-08 21:52:04 <Cogitri> We use a custom triplet anyway
2019-06-08 21:52:17 <Cogitri> And we want -crt-static every time anyway
2019-06-08 21:52:34 <Cogitri> (I even use it for my dev stuff because crt-static doesn't work with a lot of crates)
2019-06-08 21:52:45 <SpaceToast> let me check...
2019-06-08 21:53:30 <SpaceToast> I don't see us patching it anywhere, but that's just from a naive grep
2019-06-08 21:53:57 <Cogitri> The patches for Rust at least contain `base.crt_static_default = false`
2019-06-08 21:54:03 <SpaceToast> I personally prefer +crt-static for dev stuff but it can be a pain, yeah
2019-06-08 21:54:09 <Cogitri> See alpine-target.patch of rust
2019-06-08 21:54:11 <SpaceToast> aha, I was searching with a '-'
2019-06-08 21:54:32 <Cogitri> So I guess that export thingie in bat is superfluous
2019-06-08 21:54:33 <danieli> our gcc 8 has gnat support, right?
2019-06-08 21:55:28 <SpaceToast> well more than just bat
2019-06-08 21:55:44 <SpaceToast> Cogitri: ok, so I'll try and remember to remove that export from future package updates
2019-06-08 21:56:00 <SpaceToast> (at least for testing, maybe I'll catch a bug in our patches :) )
2019-06-08 21:57:19 <Cogitri> Yup, thanks :)
2019-06-08 21:58:41 <SpaceToast> speaking of patches, one thing that annoys me is how commits are marked as "unmerged" (because of how merging PRs works currently), and we also ultimately need algitbot
2019-06-08 21:58:47 <SpaceToast> gitlab will (probably?) also fix that? :D
2019-06-08 21:59:29 <Cogitri> If Gitlab isn't a RO mirror, sure
2019-06-08 22:00:15 <SpaceToast> my understanding is that the goal of gitlab is to try to unify workflows to some degree
2019-06-08 22:00:22 <SpaceToast> so I'd be very surprised if it ended up being an ro mirror
2019-06-08 22:00:45 <danieli> to answer my question: yes, our gcc supports gnat through gcc-gnat, it's even explicitly patched to support it \o/
2019-06-08 22:00:48 <danieli> that'll make my life just a tiny bit easier
2019-06-08 22:00:58 <SpaceToast> nice :)
2019-06-08 23:22:15 <kpcyrd> are there archives of old alpine packages somewhere?
2019-06-08 23:22:55 <danieli> WIP
2019-06-08 23:22:57 <danieli> but no
2019-06-08 23:23:11 <danieli> well.. that's half a truth
2019-06-08 23:23:12 <danieli> http://snapshot.alpinelinux.org/
2019-06-08 23:50:03 <jordandoyle> hey jwh did you ever manage to sort the `Failed to run: /memfd:liblxc (deleted)` thing?
2019-06-08 23:50:56 <jwh> it was fixed in the release after
2019-06-08 23:51:12 <jwh> may have broken it since though :D
2019-06-08 23:51:19 <jordandoyle> hmph
2019-06-08 23:51:22 <jordandoyle> thats fun
2019-06-08 23:51:33 <jwh> but I haven't got an alpine lxd box atm
2019-06-08 23:51:51 <jordandoyle> i'm on a fresh box installing from edge guess its goosed again
2019-06-08 23:52:02 <SpaceToast> I'm talking to you through an lxd install on edge
2019-06-08 23:52:09 <SpaceToast> right now! :D
2019-06-08 23:52:15 <jwh> its actually a bit of a misnomer as the result is the same for a number of problems
2019-06-08 23:52:29 <SpaceToast> you may want a custom-patched lxc-libs though
2019-06-08 23:53:05 <jwh> yeah SpaceToast knows whats going on
2019-06-08 23:53:36 <jordandoyle> what kind of patches?
2019-06-08 23:53:45 <SpaceToast> I don't remember what they fixed at this point
2019-06-08 23:53:46 <jordandoyle> as in to sort this or are there bigger isseus with lxc?
2019-06-08 23:53:48 <SpaceToast> but there was some serious failure
2019-06-08 23:54:02 <SpaceToast> and I'm still using the custom patched version since a newer one with the fix hasn't come out yet
2019-06-08 23:54:24 <jordandoyle> sweet heh
2019-06-08 23:54:29 <SpaceToast> https://minio.toastin.space/shared/lxc-libs-3.1.0-r3.apk - I keep it around for my own use, but feel free to try and see if it helps
2019-06-08 23:54:37 <jwh> SpaceToast: is that the one I opened a PR for?
2019-06-08 23:54:43 <SpaceToast> I have absolutely no idea
2019-06-08 23:54:48 <SpaceToast> as mentioned, don't remember that far back
2019-06-08 23:54:48 <jordandoyle> i keep crashing my hypervisor when i put load on one of my vms thought i'd make the jump to containers
2019-06-08 23:54:57 <SpaceToast> I use lxd basically everywhere
2019-06-08 23:55:07 <SpaceToast> it's just good :tm: (when it works)
2019-06-08 23:55:10 <SpaceToast> kind of like salt!
2019-06-08 23:55:10 <jwh> r3 looks like the one I did
2019-06-08 23:55:21 <SpaceToast> let me check which one I actually have installed,then
2019-06-08 23:55:27 <jwh> I think I opened a PR but not 100%
2019-06-08 23:55:54 <SpaceToast> ugh, /etc/apk/world just has some hash thing
2019-06-08 23:55:58 <SpaceToast> but it LOOKS like I have -r3
2019-06-08 23:55:58 <jwh> lol
2019-06-08 23:56:17 <SpaceToast> not sure who/what built it either, at this point
2019-06-08 23:56:20 <SpaceToast> I mean PROBABLY me, right?
2019-06-08 23:56:28 <SpaceToast> in case you need my sign key: https://build.toastin.space/toast@toastin.space.rsa.pub
2019-06-08 23:56:28 <jwh> I'd have to unpack a 400G tar to find my original patches
2019-06-08 23:56:29 <jordandoyle> installing random bins on hypervisors is how to live your life on the real @edge
2019-06-08 23:56:33 <SpaceToast> (note: do NOT use build.toastin.space as a repo)
2019-06-08 23:56:46 <SpaceToast> (it's just there for transparency and debugging, since that's my builder :) )
2019-06-08 23:56:59 <jordandoyle> hehe thanks
2019-06-08 23:57:49 <SpaceToast> gotta shill my favorite container tech ;)
2019-06-08 23:58:36 <jwh> do you have the apkbuild for it?
2019-06-08 23:58:54 <jwh> looks like my last backup was before I uploaded lxc fixes
2019-06-08 23:59:04 <SpaceToast> lol no
2019-06-08 23:59:11 <SpaceToast> I was just dropping a .patch into the apkbuild
2019-06-08 23:59:12 <SpaceToast> at the time
2019-06-08 23:59:13 <jwh> o
2019-06-08 23:59:57 <jwh> https://github.com/alpinelinux/aports/pull/6337
2019-06-09 00:00:38 <SpaceToast> I think my -r3 is that patch plus some other one
2019-06-09 00:00:53 <SpaceToast> (my -r2 is the other patch, without this one)
2019-06-09 00:00:58 <jwh> yeah I remember talking to you about it but I don't have any of my patches
2019-06-09 00:01:00 <SpaceToast> but yeah hard to remember this
2019-06-09 00:01:09 <SpaceToast> either way, do tell us if it helps, jordandoyle :)
2019-06-09 00:01:16 <jordandoyle> oh wait you're on r3?
2019-06-09 00:01:29 <SpaceToast> yes, did you not see the link?
2019-06-09 00:01:33 <jordandoyle> i'm on r1 for some reason
2019-06-09 00:01:39 <SpaceToast> because that's what's in the repository
2019-06-09 00:01:49 <jordandoyle> ahhhh okay okay
2019-06-09 00:01:50 <jwh> iirc that PR fixed it all for me
2019-06-09 00:01:53 <jordandoyle> i'll give that a shot ta
2019-06-09 00:02:11 <SpaceToast> I just never PRd it because, well, they claimed a release would happen soon
2019-06-09 00:02:13 <SpaceToast> (we're still waiting)
2019-06-09 00:02:28 <jwh> lol yup
2019-06-09 00:02:47 <jordandoyle> noticed that :P december 2018 was the last release? :(
2019-06-09 00:02:54 <jordandoyle> even virt-manager has been updated since then
2019-06-09 00:03:10 <jwh> musl is of no real concern for them, so theres no urgency
2019-06-09 00:03:13 <SpaceToast> ^
2019-06-09 00:03:18 <SpaceToast> that's the unfortunate part, really
2019-06-09 00:05:19 <jordandoyle> thats canonical :)
2019-06-09 00:05:30 <SpaceToast> it can always get worse!
2019-06-09 00:05:30 <jordandoyle> open source software available to people everywhere
2019-06-09 00:05:40 <jordandoyle> suppose so
2019-06-09 00:05:52 <SpaceToast> anyway, for general discourse, we have #alpine-offtopic :)
2019-06-09 00:06:03 <SpaceToast> and if you run into further issues with -r3 feel free to poke me
2019-06-09 00:06:37 <jordandoyle> i'll make my way over there & i'm sure you'll hear from me :)
2019-06-09 00:06:40 <jordandoyle> cheers mate
2019-06-09 00:08:45 <jwh> heh
2019-06-09 10:11:32 <maxice8> can i get pr8650 in ? it is blocking 2 gnome packages
2019-06-09 10:33:28 <clandmeter> kpcyrd: do we really need another channel for repro?
2019-06-09 10:36:42 <kpcyrd> clandmeter: we can point the bots into this channel but I figured people wouldn't like that
2019-06-09 10:38:09 <clandmeter> Bots?
2019-06-09 10:39:22 <kpcyrd> the jobs at https://jenkins.debian.net/view/reproducible/view/Alpine/ log into that channel occasionally
2019-06-09 10:40:29 <clandmeter> We have commits channel
2019-06-09 10:40:42 <clandmeter> Maybe use that?
2019-06-09 10:41:51 <kpcyrd> sure, how's it called?
2019-06-09 10:46:10 <SpaceToast> #alpine-commits iirc
2019-06-09 11:04:57 <fabled> hey. i'm building fwupd (fwupd.org) aport currently. almost done there. but the test suite requires /etc/machine-id which is apparently generated by system dbus on first start. but builders (or rootbld environment) do no have that. wondering how to workaround this
2019-06-09 11:06:03 <maxice8> I did that on Void Linux by just echoing to the root fs
2019-06-09 11:06:05 <maxice8> not clean
2019-06-09 11:06:23 <SpaceToast> from the spec: "The machine ID is usually generated from a random source during system installation or first boot and stays constant for all subsequent boots. Optionally, for stateless systems, it is generated during runtime during early boot if necessary. "
2019-06-09 11:06:33 <SpaceToast> I would consider rootbld to be a stateless system
2019-06-09 11:06:44 <maxice8> https://github.com/void-linux/void-packages/blob/5c978f7aab7f3c6c7af1e0d61ea63b5de92aa8e7/srcpkgs/elogind/template#L23
2019-06-09 11:08:02 <SpaceToast> looks like v4 UUID is ok
2019-06-09 11:09:25 <fabled> in fwupd the content can be anything -- as long as there is something. so just creating it is ok. but in rootbld environment /etc is likely read-only
2019-06-09 11:10:07 <maxice8> well, can't we make a check-etc-machine package that just installs a /etc/machine-id ?
2019-06-09 11:10:47 <fabled> was hoping to avoid that... but that's probably the cleanest option
2019-06-09 11:12:09 <fabled> oh, it is in dbus post-install
2019-06-09 11:12:43 <fabled> but alas, only for /var/lib/dbus/machine-id
2019-06-09 11:12:56 <fabled> dbus init.d does /etc/machine-id
2019-06-09 11:14:12 <clandmeter> we can generate one from busybox?
2019-06-09 11:14:24 <maxice8> we can just echo > /etc/machine-id
2019-06-09 11:15:00 <clandmeter> it doesnt have to be unique?
2019-06-09 11:15:06 <fabled> for testing, no
2019-06-09 11:15:13 <clandmeter> sure for t esting
2019-06-09 11:15:28 <SpaceToast> clandmeter: busybox cat + procfs is sufficient
2019-06-09 11:15:33 <fabled> but we can't do that in APKBUILD for running system. since in "abuild rootbld" /etc will be read-only
2019-06-09 11:15:44 <clandmeter> i mean in general
2019-06-09 11:15:49 <SpaceToast> cat /proc/sys/kernel/random/uuid > /etc/machine-id
2019-06-09 11:15:57 <fabled> so i'm thinking to amend dbus post install script
2019-06-09 11:16:19 <clandmeter> so we only need it when dbus is used?
2019-06-09 11:16:21 <SpaceToast> according to the spec machine-id *should* be compatible with IEEE UUID v4
2019-06-09 11:16:42 <fabled> clandmeter, dbus init.d already creates it
2019-06-09 11:17:55 <clandmeter> what is the actual use case?
2019-06-09 11:18:29 <SpaceToast> making poettering happy :D
2019-06-09 11:18:33 <SpaceToast> (well, freedesktop in general)
2019-06-09 11:18:39 <maxice8> clandmeter: "some systemd thing"
2019-06-09 11:19:00 <fabled> it seems systemd related yes. but also non-systemd stuff seems to want to use it
2019-06-09 11:19:03 <clandmeter> well that means others will  start using it and break stuff.
2019-06-09 11:19:11 <fabled> i'm packaging fwupd
2019-06-09 11:19:19 <fabled> and it fails without it
2019-06-09 11:19:27 <maxice8> fabled: i think chromium likes having it, not obligatory but it uses it when available
2019-06-09 11:19:30 <maxice8> ^ don't quote me on that
2019-06-09 11:19:35 <clandmeter> so it would make sense to generate it post baselayout or similar?
2019-06-09 11:19:59 <SpaceToast> I think it should be an init feature
2019-06-09 11:20:03 <SpaceToast> maybe on by default
2019-06-09 11:20:09 <SpaceToast> at least that's what the spec recommends
2019-06-09 11:20:21 <fabled> so currently dbus.initd will generate it
2019-06-09 11:20:27 <SpaceToast> well, not recommends, it's actually required to some degree, since you must be able to specify a custom one
2019-06-09 11:20:35 <fabled> but that's not started on builders or abuild rootbld environment
2019-06-09 11:20:54 <SpaceToast> actually, it could be added to firstboot?
2019-06-09 11:21:06 <maxice8> I stand by creating check-etc-machine-id that can be added to checkmakedepends when required, also helps on elogind
2019-06-09 11:21:26 <fabled> dbus.post-install creates already the dbus machine-id
2019-06-09 11:21:32 <fabled> so i'm thinking just adding that there
2019-06-09 11:21:41 <fabled> since dbus seems to be "owning" both machine-id's
2019-06-09 11:21:45 <SpaceToast> well machine-id is inspired by dbus machine-id but they're not the same thing
2019-06-09 11:21:59 <fabled> yes
2019-06-09 11:22:09 <SpaceToast> and dbus machine-id is allowed to be a symlink to the global machine-id (but not vice versa)
2019-06-09 11:22:10 <fabled> but our dbus package creates both. just in different places
2019-06-09 11:22:50 <SpaceToast> sure, I'm just not sure that's the correct approach (at least spec-wise)
2019-06-09 11:22:55 <fabled> The simple configuration file format of /etc/machine-id originates in the /var/lib/dbus/machine-id file introduced by D-Bus. In fact, this latter file might be a symlink to /etc/machine-id
2019-06-09 11:23:00 <fabled> maybe do that?
2019-06-09 11:23:32 <fabled> since /etc/machine-id seems to be basically systemd thing
2019-06-09 11:24:16 <SpaceToast> well, notice the ordering
2019-06-09 11:24:23 <SpaceToast> dbus' machine-id can be a symlink to the global one
2019-06-09 11:24:25 <SpaceToast> not vice versa
2019-06-09 11:24:33 <fabled> yes
2019-06-09 11:24:35 <SpaceToast> latter file is /var/lib/dbus/machine-id
2019-06-09 11:24:42 <SpaceToast> so I'm not sure dbus should/needs to generate anything
2019-06-09 11:24:59 <fabled> on systemd systems, it's systemd firstboot script
2019-06-09 11:25:01 <SpaceToast> (assuming we support /etc/machine-id properly)
2019-06-09 11:25:12 <SpaceToast> well, virtual systemd systems
2019-06-09 11:25:17 <fabled> but since we don't do that. and it's dbus tools that are used to create it. it makes sense to put it in dbus
2019-06-09 11:25:25 <SpaceToast> we do have a firstboot rc script
2019-06-09 11:25:32 <SpaceToast> so it could be added to that
2019-06-09 11:25:39 <clandmeter> it would if we would only need it when dbus is used.
2019-06-09 11:25:46 <SpaceToast> but what about systems that are already set up, and/or containers?
2019-06-09 11:25:56 <clandmeter> i also wonder about containers
2019-06-09 11:26:01 <SpaceToast> clandmeter: the dbus machine-id, sure; but the global one seems to be used in other contexts
2019-06-09 11:27:39 <fabled> so current situation is:
2019-06-09 11:27:53 <fabled> 1) dbus.post-install: generate new /var/lib/dbus/machine-id
2019-06-09 11:28:02 <fabled> 2) dbus.initd: generate new /etc/machine-id
2019-06-09 11:28:13 <fabled> so they both get generated independently
2019-06-09 11:28:22 <fabled> at different stages of dbus install or startup
2019-06-09 11:28:24 <clandmeter> yeah
2019-06-09 11:31:30 <fabled> do we want something like http://sprunge.us/pve0pZ or to just add the /etc/machine-id generation and keep the ids separate
2019-06-09 11:32:31 <SpaceToast> I think machine-id and dbus-machine-id should be separate
2019-06-09 11:32:45 <SpaceToast> since they may be desired under different circumstances
2019-06-09 11:32:48 <fabled> probably makes sence
2019-06-09 11:32:51 <SpaceToast> one might want machine-id without necessarily involving dbus
2019-06-09 11:32:53 <fabled> and has different meaning
2019-06-09 11:32:57 <SpaceToast> and one may want dbus without caring about machine-id
2019-06-09 11:33:02 <SpaceToast> yeah
2019-06-09 11:33:45 <fabled> so i do http://sprunge.us/Rs0fBa for now
2019-06-09 11:34:04 <fabled> we can separate machine-id generation elsewhere later if needed, but that involves likely patching dbus more
2019-06-09 11:35:12 <fabled>   Running dbus-uuidgen --ensure, which should be done after installing dbus,
2019-06-09 11:35:13 <fabled>   continues to copy /etc/machine-id to /var/lib/dbus/machine-id if the
2019-06-09 11:35:13 <fabled>   former exists and the latter does not.
2019-06-09 11:35:40 <fabled> so creating /etc/machine-id first will copy the content to dbus-machine-id. interesting
2019-06-09 11:36:37 <SpaceToast> what I think needs to happen:
2019-06-09 11:36:48 <SpaceToast> 1. add machine-id generation (with KOPT_machine_id) to /etc/init.d/firstboot
2019-06-09 11:37:09 <SpaceToast> 2. change docker setup to enable firstboot (it'll disable itself after running)
2019-06-09 11:37:19 <SpaceToast> 3. change lxc images (not under our control iirc) to enable firstboot
2019-06-09 11:37:35 <SpaceToast> 4. advise people with existing installs that want it to run `service firstboot start` once
2019-06-09 11:38:31 <Cogitri> -1 on manual intervention
2019-06-09 11:38:32 <SpaceToast> since, supposedly, it's UUID v4 compatible, we can just use procfs to generate it
2019-06-09 11:38:43 <SpaceToast> Cogitri: existing installs only
2019-06-09 11:38:50 <Cogitri> I'd like 4 to be automagic if possible
2019-06-09 11:39:04 <SpaceToast> I just don't think a "unique system identifier" should be tied to a package, basically
2019-06-09 11:39:15 <SpaceToast> which rules out post-install
2019-06-09 11:39:24 <SpaceToast> (especially in container and iso scenarios)
2019-06-09 11:39:37 <Cogitri> Hm, but does anything but dbus dependent stuff need it?
2019-06-09 11:39:52 <SpaceToast> machine-id and dbus-machine-id are separate things
2019-06-09 11:39:55 <SpaceToast> with different meanings
2019-06-09 11:39:57 <SpaceToast> so yes
2019-06-09 11:39:59 <clandmeter> Cogitri: see intial issue
2019-06-09 11:40:21 <Cogitri> Ah, alright, my bad. Thought only elogind and dbus needed it
2019-06-09 11:40:22 <SpaceToast> dbus-machine-id I have no problem with remaining as it is now
2019-06-09 11:40:24 <fabled> seems new dbus does the initialization itself already
2019-06-09 11:40:40 <fabled> so if dbus-machine-id is not there, it'll prefer to copy machine-id
2019-06-09 11:41:01 <fabled> since originally we used to have dbus-machine-id gen in init.d *and* post-install
2019-06-09 11:41:12 <fabled> but only init.d was changed to machine-id
2019-06-09 11:41:21 <mps> (machine-id, what a horrible idea)
2019-06-09 11:41:21 <fabled> i think we can just change post-install to also generate machine-id
2019-06-09 11:41:35 <fabled> it's also done in init.d if doing "first start"
2019-06-09 11:41:49 <SpaceToast> well we're still tying a "system" thing to an unrelated package, if we do that
2019-06-09 11:42:14 <fabled> it is already done
2019-06-09 11:42:18 <SpaceToast> I don't like it, and I think I've made my case; though ultimately it's not up to me :)
2019-06-09 11:42:34 <fabled> it's a freedesktop thing
2019-06-09 11:42:39 <fabled> mostly systemd thing
2019-06-09 11:42:55 <fabled> but also very involved with dbus. and normally it's generated with dbus commands
2019-06-09 11:42:58 <SpaceToast> sure, but when adding support for $spec, I think one should attempt to follow $spec
2019-06-09 11:43:09 <fabled> we are not adding systemd
2019-06-09 11:43:15 <SpaceToast> systemd is not the spec in question
2019-06-09 11:43:29 <fabled> systemd is the spec defining etc/machine-id
2019-06-09 11:43:42 <SpaceToast> systemd is an implementation of the /etc/machine-id spec
2019-06-09 11:43:45 <SpaceToast> from my perspective
2019-06-09 11:43:45 <mps> I'm trying to get rid of dbus on my workstation and I'm nearly done
2019-06-09 11:43:58 <fabled> SpaceToast, please point me to machine-id spec that is not freedesktop/systemd?
2019-06-09 11:44:14 <mps> on my servers there is no dbus
2019-06-09 11:44:21 <fabled> also
2019-06-09 11:44:22 <fabled> For normal operating system installations, where a custom image is created for a specific machine, /etc/machine-id should be populated during installation.
2019-06-09 11:44:24 <SpaceToast> it is defined by the same people, but last I checked fwupd != systemd
2019-06-09 11:44:41 <fabled> so post-install is right place
2019-06-09 11:44:43 <SpaceToast> yes, not dbus-installation, system/image installation
2019-06-09 11:44:58 <SpaceToast> we could add it to setup-alpine, but then containers fail
2019-06-09 11:45:10 <fabled> well
2019-06-09 11:45:11 <SpaceToast> also note "where a custom image is created for *a specific machine*"
2019-06-09 11:45:14 <fabled> we can generalize it there
2019-06-09 11:45:20 <fabled> but since dbus heavily relies on it
2019-06-09 11:45:27 <fabled> it makes sense to have it in dbus.post-install
2019-06-09 11:45:35 <SpaceToast> regarding machine-id being systemd, consider os-release(5)
2019-06-09 11:45:39 <fabled> but if we want to have it present even without dbus, then setup-alpine makes sense
2019-06-09 11:45:46 <SpaceToast> we support that spec, afaik properly, but we don't support systemd
2019-06-09 11:45:51 <SpaceToast> I don't see why machine-id can't be the same way
2019-06-09 11:46:09 <SpaceToast> setup-alpine will miss containers
2019-06-09 11:46:15 <SpaceToast> which is why I think firstboot is appropriate
2019-06-09 11:46:16 <mps> what if machine is cloned for VM, and have dhcp and dhcpc send machine-id instead of mac address
2019-06-09 11:47:00 <SpaceToast> mps: "For operating system images which are created once and used on multiple machines, for example for containers or in the cloud, /etc/machine-id should be an empty file in the generic file system image."
2019-06-09 11:47:11 <SpaceToast> "An ID will be generated during boot and saved to this file if possible."
2019-06-09 11:47:26 <SpaceToast> if you clone your vm, you should just rerun firstboot, imo
2019-06-09 11:48:23 <mps> then why not recreate machine-id on every boot
2019-06-09 11:48:30 <maxice8> can i get pr8650 in ? it is blocking 2 gnome packages
2019-06-09 11:48:51 <SpaceToast> because it's not supposed to change under normal circumstances
2019-06-09 11:49:15 <SpaceToast> "The machine ID does not change based on local or network configuration or when hardware is replaced."
2019-06-09 11:49:24 <SpaceToast> it's meant to be a more robust gethostid(3)
2019-06-09 11:50:18 <fabled> well. i understand both sides. if we want more generic support for it, it's a bit bigger job. at this time i just want my package to build. so i'll likely just change dbus.post-install to generate /etc/machine-id instead of dbus-machine-id.
2019-06-09 11:50:21 <mps> SpaceToast: who decided this, and what are normal circumstances. No need to answer, it is grumpy rhetorical question
2019-06-09 11:50:24 <fabled> since that's improvement
2019-06-09 11:50:32 <fabled> and generate means "generate if not already existing"
2019-06-09 11:50:47 <SpaceToast> fabled: I'm just here to give my idealistic opinion, and improve the state of discourse :)
2019-06-09 11:50:56 <SpaceToast> feel free to ignore everything I say and do whatever you wish
2019-06-09 11:51:06 <SpaceToast> me not liking it doesn't mean it's suddenly not ok to do
2019-06-09 11:51:15 <mps> maxice8: PR looks good, but someone with main access have to push it
2019-06-09 11:51:18 <SpaceToast> mps: the people that wrote the spec :D
2019-06-09 11:51:22 <fabled> understand. and i think that's the right goal to go. but it's a bit more intrusive / longer goal
2019-06-09 11:51:49 <maxice8> mps: yes, i can only push to community and testing
2019-06-09 11:51:51 <maxice8> otherwise i would have pushed already
2019-06-09 11:52:02 <maxice8> well i'm off to buy stuff at the supermarkt
2019-06-09 11:52:10 <fabled> so i'll likely just push http://sprunge.us/g94XDd
2019-06-09 11:52:37 <mps> maxice8: is your name Mike
2019-06-09 11:53:05 <maxice8> No
2019-06-09 11:53:16 <mps> oh, sorry
2019-06-09 11:53:22 <fabled> in fact, that's good enough for dbus since it'll fallback to /etc/machine-id
2019-06-09 11:56:22 <fabled> hum. or maybe still create both.
2019-06-09 12:44:04 <mps> fabled: are we meet about then years ago on ipsec-tools-devel ML
2019-06-09 12:44:29 <fabled> mps, perhaps. i was back then active there
2019-06-09 12:45:35 <mps> eh, yes. nice to meet you again here :)
2019-06-09 15:01:30 <maxice8> _ikke_:  new atools is out
2019-06-09 15:01:41 <maxice8> releases are slower because i have no idea of what else to link, i am working on a fixer for the issues though
2019-06-09 15:01:42 <maxice8> apkbuild-fixer
2019-06-09 15:02:15 <maxice8> https://github.com/maxice8/meltryllis/blob/master/bin/apkbuild-fixer
2019-06-09 15:08:36 <_ikke_> maxice8: Sure, I don't expect constant development :)
2019-06-09 15:08:57 <maxice8> I mean i would develop it faster but i have no idea of what to lint next
2019-06-09 15:09:07 <_ikke_> Just add things as they come in
2019-06-09 15:09:58 <_ikke_> That's usually how these things work
2019-06-09 15:29:13 <maxice8> _ikke_: can you remove the broken label from pr8630 ?
2019-06-09 15:29:47 <_ikke_> done
2019-06-09 15:29:55 <maxice8> ty
2019-06-09 16:16:39 <maxice8> does arch restriction works after setting noarch ?
2019-06-09 16:16:48 <_ikke_> yes
2019-06-09 16:17:09 <maxice8> ah good
2019-06-09 16:17:11 <maxice8> py3-dill is failing on s390x
2019-06-09 16:18:01 <_ikke_> http://tpaste.us/qK85
2019-06-09 16:27:33 <maxice8> Someone that can mark patchwork stuff as obsolete ?
2019-06-09 16:27:41 <_ikke_> I can
2019-06-09 16:28:15 <maxice8> ah nice
2019-06-09 16:28:21 <_ikke_> mps as well
2019-06-09 16:28:23 <maxice8> i send you the numbers you close them ? :D
2019-06-09 16:28:32 <_ikke_> sure
2019-06-09 16:28:51 <maxice8> https://patchwork.alpinelinux.org/patch/4900/ https://patchwork.alpinelinux.org/patch/4899/
2019-06-09 16:29:07 <maxice8> https://patchwork.alpinelinux.org/patch/4850/
2019-06-09 16:29:41 <_ikke_> are they superseded?
2019-06-09 16:29:48 <maxice8> https://patchwork.alpinelinux.org/patch/4848/
2019-06-09 16:29:51 <maxice8> https://patchwork.alpinelinux.org/patch/4847/
2019-06-09 16:29:52 <maxice8> https://patchwork.alpinelinux.org/patch/4833/
2019-06-09 16:29:54 <_ikke_> i see commits from Robert Sacks
2019-06-09 16:30:11 <_ikke_> Are they accepted?
2019-06-09 16:30:37 <maxice8> for wl-clipboard ? yes
2019-06-09 16:30:47 <maxice8> i merged the v2 one but it didn't close it and the v1
2019-06-09 16:34:13 <_ikke_> what about py-ptyprocess?
2019-06-09 16:34:16 <_ikke_> 4848
2019-06-09 16:34:19 <mps> yes, I noticed that some patches (for some I posted mail to authors but didn't received answers) from pw.a.o applied
2019-06-09 16:34:45 <maxice8> both ptyprocess and pepexct were actually made because the author didn't notice that there is already a py3- version available in community/
2019-06-09 16:34:51 <maxice8> so he is basically adding a python3 version to testing/
2019-06-09 16:34:54 <mps> but, I'm outside now, thought to look states when I'm back at home
2019-06-09 16:35:19 <_ikke_> for ptyprocess they even added it directly to main
2019-06-09 16:35:27 <_ikke_> a/main/py-ptyprocess/APKBUILD
2019-06-09 16:35:43 <maxice8> oh, didn't even catch it
2019-06-09 16:35:43 <maxice8> oh lol
2019-06-09 16:36:01 <mps> and I'm little conservative when pushing patches, like to review and test it better
2019-06-09 16:36:12 <maxice8> https://patchwork.alpinelinux.org/patch/4802/
2019-06-09 16:36:23 <maxice8> https://patchwork.alpinelinux.org/patch/4803/
2019-06-09 16:37:00 <maxice8> these will be obsolete with pr8572
2019-06-09 16:37:11 <mps> these have 'make || return 1', which is unneeded imo
2019-06-09 16:37:30 <_ikke_> what about qtstyleplugins?
2019-06-09 16:37:45 <maxice8> mps: i don't know how to send an email to them to fix it so i just don't merge it
2019-06-09 16:37:45 <_ikke_> mps: correct, they are no longer required
2019-06-09 16:38:02 <_ikke_> Honestly, if they are just simple fixes, I just fix it when applying
2019-06-09 16:38:19 <maxice8> _ikke_: Ah, don't close that, get someone qualified to send mails (not me) and ask the author to not use `master` on source
2019-06-09 16:38:52 <_ikke_> maxice8: right
2019-06-09 16:38:57 <mps> _ikke_: sometimes I do just that, but sometimes I have some kind of ambiguous feeling
2019-06-09 16:39:31 <maxice8> https://patchwork.alpinelinux.org/patch/4791/ img too, already applied
2019-06-09 16:39:55 <mps> maxice8: when I come back later I will look at your PR, ofc if _ikke_ didn't do that before :)
2019-06-09 16:39:58 <maxice8> should i --amend when doing fixes or do a follow-up commit ?
2019-06-09 16:40:26 <mps> yes, there are llvm8 also, which need to be marked as Superseded
2019-06-09 16:41:19 <maxice8> https://patchwork.alpinelinux.org/patch/4736/ can be closed, applied
2019-06-09 16:41:44 <mps> I don't use --ammend even for small changes. only use that if I not change commit msg
2019-06-09 16:42:57 <mps> it is not advice, ofc. you decide what is appropriate in particular case
2019-06-09 16:44:09 <mps> maxice8: you can subscribe to aports@alpinelinux.org ML and you will receive all patches and replies there
2019-06-09 16:44:38 <mps> alpine-aports@lists.alpinelinux.org
2019-06-09 16:45:34 <mps> or, you can download particular patch as mbox file and open it in your mail client, as I do for some older patches
2019-06-09 16:48:57 <SpaceToast> pr8660 needs ci malfunction tag
2019-06-09 16:49:42 <SpaceToast> thanks _ikke_ :)
2019-06-09 16:49:42 <_ikke_> done
2019-06-09 16:53:12 <maxice8> https://patchwork.alpinelinux.org/patch/4746/ can be closed, applies with follow-up fix
2019-06-09 16:53:32 <_ikke_> what do you mean with the last part?
2019-06-09 16:54:18 <SpaceToast> _ikke_: pr8620 too, same problem with travis timeout
2019-06-09 16:54:44 <_ikke_> maxice8: py3-weasyprint: fails on some arches
2019-06-09 16:56:07 <maxice8> oops
2019-06-09 16:56:11 <maxice8> i'm still learning how to use patchwork
2019-06-09 16:57:05 <_ikke_> maxice8: http://tpaste.us/NKeZ this is what I use to apply patches from both github as patchwork
2019-06-09 16:57:18 <_ikke_> (i aliased git pr / git pw to call that script)
2019-06-09 16:58:25 <_ikke_> The challenge with patchwork is that it has no ci
2019-06-09 17:00:12 <_ikke_> maxice8: will you fix py3-weasyprint?
2019-06-09 17:00:23 <maxice8> working on it
2019-06-09 17:00:27 <_ikke_> right
2019-06-09 17:00:29 <_ikke_> brb
2019-06-09 17:00:35 <_ikke_> Im afk for a bit
2019-06-09 17:00:47 <maxice8> hopefully done
2019-06-09 17:08:14 <maxice8> https://patchwork.alpinelinux.org/patch/4742/
2019-06-09 17:08:15 <maxice8> https://patchwork.alpinelinux.org/patch/4743/
2019-06-09 17:08:16 <maxice8> https://patchwork.alpinelinux.org/patch/4746/ can be closed
2019-06-09 17:23:23 <maxice8> https://patchwork.alpinelinux.org/patch/3786/ can be closed, completely broken
2019-06-09 17:24:40 <maxice8> https://patchwork.alpinelinux.org/patch/4093/ can be closed, broken
2019-06-09 17:25:32 <maxice8> https://patchwork.alpinelinux.org/patch/3784/ can be closed, conflicts with singularity already present
2019-06-09 17:28:48 <maxice8> https://patchwork.alpinelinux.org/patch/4789/ can be closed, accepted
2019-06-09 17:37:19 <maxice8> armv7 is starting to fail some weird packages like libxml++
2019-06-09 17:46:11 <maxice8> ddevault: https://patchwork.alpinelinux.org/patch/4856/ updates but doesn't change checksum, can you send a new patch for it ?
2019-06-09 17:46:29 <ddevault> sure
2019-06-09 17:47:10 <maxice8> thank you
2019-06-09 17:58:16 <_ikke_> maxice8: what's with those first 2?
2019-06-09 18:01:46 <maxice8> those first 2 ?
2019-06-09 18:03:10 <_ikke_> 4742 4743
2019-06-09 18:03:42 <maxice8> already merged, accepted
2019-06-09 18:18:10 <maxice8> https://patchwork.alpinelinux.org/patch/4855/
2019-06-09 18:18:11 <maxice8> https://patchwork.alpinelinux.org/patch/4856/ can be closed, obsolete
2019-06-09 18:45:19 <Cogitri> _ikke_: Seems like more stuff went missing on armv7 https://cloud.drone.io/alpinelinux/aports/6909/5/1
2019-06-09 18:51:17 <danieli> pr8674 to unbreak syslinux
2019-06-09 18:51:28 <_ikke_> Cogitri: yes, testing was / is not fixed yet
2019-06-09 18:51:34 <maxice8> https://patchwork.alpinelinux.org/patch/4833/ can be closed, is broken
2019-06-09 18:51:48 <Cogitri> Ah, alright
2019-06-09 18:52:01 <_ikke_> It's building, but build failures are holding it upo
2019-06-09 18:52:16 <_ikke_> handlebars is currently failing
2019-06-09 19:15:45 <maxice8> https://patchwork.alpinelinux.org/patch/3786/ can be closed, says it introduces package X but actually introduces package Y that depends on apckage X
2019-06-09 19:17:07 <maxice8> https://patchwork.alpinelinux.org/patch/4093/ can be closed, checkdepends on a package that doesn't exist
2019-06-09 19:18:15 <danieli> maxice8: it's part of a series, py-sh is the previous one
2019-06-09 19:18:27 <danieli> 409{2,3,4}
2019-06-09 19:18:48 <maxice8> Doesn't appear as part of a series here
2019-06-09 19:19:01 <danieli> [alpine-aports,2/3] New aport: testing/py-dotenv
2019-06-09 19:19:08 <danieli> 2/3
2019-06-09 19:19:24 <maxice8> 4092 has changes requested
2019-06-09 19:19:51 <maxice8> danieli: i mean the patchwork.a.o interface doesn't show them as part of a series
2019-06-09 19:20:00 <maxice8> it has patch but the series row is empty for it
2019-06-09 19:26:52 <mps> maxice8: when rejecting patches from pw.a.o it is customary to send mail to author and tell why the package is broken and if author can fix it and send update.
2019-06-09 19:27:57 <maxice8> mps: a freeform email with no context ?
2019-06-09 19:28:04 <mps> we shouldn't quietly just reject them
2019-06-09 19:28:37 <mps> that depends, we have to be creative in these situations
2019-06-09 19:29:03 <maxice8> aren't people notified when the status of a patch they made change ?
2019-06-09 19:29:28 <mps> yes, notification is sent, but without explanation
2019-06-09 19:29:34 <danieli> ^
2019-06-09 19:30:21 <maxice8> No worries then, the wiki tells you can go to #alpine-devel to ask why it was rejected
2019-06-09 19:31:46 <mps> not all contributors use irc
2019-06-09 19:31:54 <danieli> it's still customary to reply to the email
2019-06-09 19:31:57 <mps> some don't like to use irc
2019-06-09 19:32:33 <mps> we are trying to be nice with all contributors
2019-06-09 19:33:49 <mps> btw, testing/wl-clipboard-x11 have provides field, which is wrong, imo
2019-06-09 19:34:26 <maxice8> it is
2019-06-09 19:34:35 <mps> I asked author to use depends with negation but didn't got answer correct answer
2019-06-09 19:35:52 <mps> wl-clipboard-x11 doesn't provide xclip and xsel
2019-06-09 19:35:55 <maxice8> mps: danieli yeah sorry i can't conjure the effort to do that, i'll just let the patchs rot there
2019-06-09 19:36:06 <danieli> that's pretty much what everyone else do too
2019-06-09 19:36:30 <mps> nvm, it is wrong ever if BDFL do this
2019-06-09 19:36:59 <mps> s/ever/even/
2019-06-09 19:36:59 <alpine-meetbot> mps meant to say: nvm, it is wrong even if BDFL do this
2019-06-09 19:38:01 <mps> we strive to have high quality distro
2019-06-09 19:38:32 <mps> (although I'm not sure nowadays)
2019-06-09 19:39:22 <Cogitri> mps: How come?
2019-06-09 19:39:43 <mps> Cogitri: what? first or (...)
2019-06-09 19:40:06 <Cogitri> <mps "(although I'm not sure nowadays)"> ^
2019-06-09 19:40:35 <mps> well, that becoming my impression these days
2019-06-09 19:41:02 <_ikke_> handlebars has 2 tests that fail on armv7
2019-06-09 19:41:15 <_ikke_> mps: what makes you say that
2019-06-09 19:41:17 <_ikke_> ?
2019-06-09 19:41:47 <mps> _ikke_: that is my *impression*
2019-06-09 19:42:19 <_ikke_> Ok, what gives you that impression :)
2019-06-09 19:42:30 <mps> to much new packages and to much upgrades without good testing.
2019-06-09 19:42:45 <mps> s/to/too/
2019-06-09 19:42:45 <alpine-meetbot> mps meant to say: too much new packages and to much upgrades without good testing.
2019-06-09 19:43:29 <mps> maybe I'm just too much conservative or even just grumpy
2019-06-09 19:43:35 <_ikke_> Yes, that's certainly an issue, mostly due to the sudden increase in contributors
2019-06-09 19:43:52 <SpaceToast> well, that's what reviews are for, right? :)
2019-06-09 19:44:13 <_ikke_> reviews miss a lot
2019-06-09 19:44:21 <mps> SpaceToast: right, but we don't have enough reviewers
2019-06-09 19:44:35 <SpaceToast> ideally you want multiple reviewers per thing, yeah
2019-06-09 19:44:47 <_ikke_> hard to scale
2019-06-09 19:44:48 <SpaceToast> and that's why I've been trying to scroll through on occasion as well
2019-06-09 19:44:53 <_ikke_> then it would take ages for things to get accepted
2019-06-09 19:44:59 <Cogitri> <SpaceToast "ideally you want multiple review"> Yeah I don't think that's possible rn to be home
2019-06-09 19:45:06 <mps> it is not rewarding job. by reviewing someone's pkg you don't get credit of 'important person'
2019-06-09 19:45:16 <SpaceToast> well, if you make it easier for people to be in a position where they can do it...
2019-06-09 19:45:27 <_ikke_> I can say, I certainly appreciate any review that is done
2019-06-09 19:45:27 <SpaceToast> mps: is that the purpose of contributing?
2019-06-09 19:45:44 <mps> for some obviously
2019-06-09 19:45:48 <_ikke_> But the review is mostly about the APKBUILD
2019-06-09 19:46:00 <_ikke_> There is a lot that is not covered by reviews
2019-06-09 19:46:19 <_ikke_> There is a QA step missing (which would take even more time)
2019-06-09 19:46:38 <SpaceToast> QA is kind of complicated without signed artifacts
2019-06-09 19:46:40 <mps> _ikke_: not just APKBUILD, when reviewing we have to test if it builds at least
2019-06-09 19:46:54 <SpaceToast> right now if you want to QA test a new package
2019-06-09 19:47:02 <SpaceToast> you have to build it yourself, sign it yourself, install it, and THEN do stuff
2019-06-09 19:47:05 <Cogitri> Well, isn't Edge a sort of replacement of the QA zone?
2019-06-09 19:47:09 <SpaceToast> it'd be nice if you could just download a built version
2019-06-09 19:47:14 <Cogitri> <mps "_ikke_: not just APKBUILD, when "> CI does that on GH
2019-06-09 19:47:15 <_ikke_> SpaceToast: abuild -r does all of that
2019-06-09 19:47:15 <mps> ideally we should run it after build, especially new pkg's
2019-06-09 19:47:27 <_ikke_> I mean more like the software that is built
2019-06-09 19:47:28 <SpaceToast> _ikke_: sure, but it's still a pain :)
2019-06-09 19:47:31 <_ikke_> not the building itself
2019-06-09 19:47:37 <SpaceToast> I know that's the "install it and THEN do stuff"
2019-06-09 19:47:44 <_ikke_> A package can build fine, but still be horribly broken
2019-06-09 19:47:46 <SpaceToast> I was describing the setup
2019-06-09 19:47:52 <SpaceToast> before you can even start QA
2019-06-09 19:48:00 <SpaceToast> Cogitri: yes and no; technically speaking it's just rolling release
2019-06-09 19:48:09 <SpaceToast> testing/ is the QA zone replacement
2019-06-09 19:48:18 <_ikke_> Only temporary
2019-06-09 19:48:20 <SpaceToast> and I would prefer if edge was functional, since I don't care much for releases
2019-06-09 19:48:44 <SpaceToast> (also why I haven't bothered moving my packages to community/, I don't really care if it's included in a release or not)
2019-06-09 19:48:56 <Cogitri> Yup, I only use Edge too
2019-06-09 19:49:28 <_ikke_> For my build pipelines I prefer to have releases though
2019-06-09 19:49:38 <_ikke_> it's anoying to have them randomly fail due to something changing
2019-06-09 19:49:46 <SpaceToast> I'm not arguing that releases should be removed
2019-06-09 19:49:56 <SpaceToast> just that edge shouldn't be a "let's break everything" spot
2019-06-09 19:50:14 <_ikke_> The problem is that there is no opportunity in between
2019-06-09 19:50:15 <mps> a lot of people depends on releases
2019-06-09 19:50:18 <SpaceToast> QA would be much easier if CI exposed built (and signed) packages you could just wget
2019-06-09 19:50:51 <_ikke_> SpaceToast: gitlab ci would allow that
2019-06-09 19:51:06 <SpaceToast> yup
2019-06-09 19:51:07 <_ikke_> I guess they would use dedicated signing keys though
2019-06-09 19:51:11 <SpaceToast> another reason I like the fact that we're moving
2019-06-09 19:51:17 <danieli> mps: honestly, i kind of agree - there (still) are far too developers to keep up with everything
2019-06-09 19:51:18 <_ikke_> not sure if we want them to sign with the official keys
2019-06-09 19:51:22 <danieli> but we keep our heads above water at least
2019-06-09 19:51:46 <mps> danieli: well, agree :)
2019-06-09 19:51:49 <_ikke_> It would be a very bad idea to have CI use the official building keys
2019-06-09 20:25:10 <mps> _ikke_: I'm looking at your script for applying pw's and pr's.
2019-06-09 20:25:58 <_ikke_> mps: put it in your PATH.
2019-06-09 20:26:03 <_ikke_> then create aliases
2019-06-09 20:26:10 <mps> think I could use it. do you use it in repo from which you push to git.a.o
2019-06-09 20:26:16 <_ikke_> alias.pr !git-patches pr
2019-06-09 20:26:18 <_ikke_> alias.pw !git-patches pw
2019-06-09 20:26:23 <_ikke_> mps: yes
2019-06-09 20:26:35 <_ikke_> then git pw <number>
2019-06-09 20:26:49 <_ikke_> or git pw <number> -b <subject>
2019-06-09 20:27:04 <mps> your script is good (although didn't tried yet)
2019-06-09 20:27:09 <_ikke_> the latter would create a branch pw/<number>-<subject>-v1
2019-06-09 20:27:26 <mps> I see syntax and it is clear how to use it
2019-06-09 20:28:17 <mps> what I don't know and want to ask you is, do you merge these new branches to master before push
2019-06-09 20:28:33 <_ikke_> I fast-forward them
2019-06-09 20:28:33 <mps> which is must be done, imo
2019-06-09 20:28:52 <_ikke_> At least how it's now, we don't merge anything
2019-06-09 20:29:04 <_ikke_> git checkout master; git merge --ff-only @{-1}
2019-06-09 20:29:10 <mps> right, that was main fear to use branches
2019-06-09 20:29:35 <_ikke_> I have a alias ff='merge --ff-only'
2019-06-09 20:29:41 <_ikke_> (git alias)
2019-06-09 20:29:51 <mps> yes, understand
2019-06-09 20:30:04 <_ikke_> so I usually do git checkout master; git ff -
2019-06-09 20:30:22 <mps> I'm using git from just one year after it is released
2019-06-09 20:30:34 <_ikke_> Heh, that's quite long
2019-06-09 20:30:51 <_ikke_> I started around 1.7 I think
2019-06-09 20:30:51 <mps> although not extensively to be honest
2019-06-09 20:31:33 <mps> story time: I imported my previous works from RCS directly to git ;)
2019-06-09 20:31:53 <_ikke_> I only used svn briefly before switching to git
2019-06-09 20:32:00 <_ikke_> mps: how did you manage? :P
2019-06-09 20:32:34 <mps> maybe I have still somewhere sripts
2019-06-09 20:34:21 <mps> anyway, if I forgot ff and run 'git push' do I risk to make a mess on git.a.o
2019-06-09 20:34:37 <_ikke_> if you set push.default to something sane, it will complain
2019-06-09 20:34:52 <_ikke_> I have it set to upstream
2019-06-09 20:35:06 <_ikke_> so when I create a branch without upstream and try to push it, git asks you to specify where to push it to
2019-06-09 20:35:07 <mps> so gitolite is setup to not allow pushing branches
2019-06-09 20:35:20 <_ikke_> No, it does not care
2019-06-09 20:35:26 <_ikke_> afaik
2019-06-09 20:36:35 <mps> good, you gave me idea. your script is clearly written. thank you
2019-06-09 20:36:58 <_ikke_> thanks
2019-06-09 20:37:40 <_ikke_> mps: oh, you can use pws to apply a patchwork series (different number)
2019-06-09 20:37:45 <_ikke_> instead of individual patches
2019-06-09 20:39:03 <mps> yes, I've seen it. really nicely written script. this is example where code is best documentation
2019-06-09 20:39:40 <mps> and, I'm not much versed in shell scripting
2019-06-09 20:42:49 <PureTryOut[m]> Did adwaita-gtk2-theme get removed from the edge repos recently?
2019-06-09 20:43:27 <_ikke_> hmm, not sure, let me check
2019-06-09 20:44:22 <Cogitri> <PureTryOut[m] "Did adwaita-gtk2-theme get remov"> No,I messed the rename up
2019-06-09 20:44:28 <Cogitri> Turns out noarch packages can't have arch specific subpackages
2019-06-09 20:44:37 <_ikke_> right, :-/
2019-06-09 20:44:55 <Cogitri> Oddly enough I was able to build and install it just fine on my laptop
2019-06-09 20:45:15 <Cogitri> See pr8710
2019-06-09 20:45:24 <PureTryOut[m]> Ah, are you working on a fix? It kinda breaks Mate atm in postmarketOS 😉
2019-06-09 20:46:14 <_ikke_> pushed
2019-06-09 20:47:26 <Cogitri> Thanks
2019-06-09 20:53:46 <mps> anyone know why main/zfs is dissabled on armv7 and armhf
2019-06-09 20:54:58 <clandmeter> i think you need 64bit os?
2019-06-09 20:55:05 <mps> I just run 'abuild -r' on armv7 and it builds without problem
2019-06-09 20:55:42 <jwh> zfs is pretty horrific on 32bit
2019-06-09 20:55:51 <mps> why then is not disabled on x86
2019-06-09 20:56:04 <clandmeter> https://github.com/zfsonlinux/zfs/wiki/FAQ#32-bit-vs-64-bit-systems
2019-06-09 20:57:05 <jwh> might be on x86-32 that due to PAE, decent amount of memory is also available
2019-06-09 20:57:09 <jwh> whereas not so on armv7
2019-06-09 20:58:34 <mps> jwh: decent memory is also available on arm32 nowadays
2019-06-09 20:58:50 <mps> with never kernels
2019-06-09 20:59:05 <jwh> how do you define decent?
2019-06-09 20:59:33 <mps> enough to run
2019-06-09 20:59:57 <mps> tbh, I didn't tested zfs on armv7
2019-06-09 21:01:03 <jwh> it'd probably be fine for small datasets with low i/o
2019-06-09 21:01:13 <jwh> arc is pretty aggressive though
2019-06-09 21:01:32 <mps> just looking to main pkg's which are not enabled to all arch's trying to test why are they disabled
2019-06-09 21:02:16 <mps> I don't have plan to use zfs on arm32
2019-06-09 21:02:33 <jwh> need to test it reall
2019-06-09 21:02:35 <jwh> really*
2019-06-09 21:02:52 <clandmeter> if it builds we could enable it.
2019-06-09 21:02:53 <mps> jwh: not I ;)
2019-06-09 21:04:00 <mps> also main/numactl is disabled on both arm32 and that's probably ok
2019-06-09 21:04:46 <jwh> yes
2019-06-09 21:05:13 <mps> and main/hexchat is only left to test
2019-06-09 21:06:27 <mps> for zfs, I'm not sure if it should or shouldn't be enabled on arm32, just wanted to say I tested it and it builds without problem
2019-06-09 21:07:19 <jwh> I'd test it well before enabling it, since if its enabled it should work properly
2019-06-09 21:07:40 <mps> btw, why hexchat is in main
2019-06-09 21:08:41 <mps> jwh: agree with you
2019-06-09 21:09:19 <jwh> but theres a reason the zfs experts who originally ported it said don't run it on 32bit
2019-06-09 21:09:20 <mps> someone who need it on arm32 should tell us
2019-06-09 21:09:22 <jwh> :)
2019-06-09 21:10:21 <mps> also main/hexchat passed 'abuild -r' on armv7
2019-06-09 21:11:11 <mps> although have to repeat myself, doesn't it belong to community better
2019-06-09 21:12:25 <mps> clandmeter: jwh: if zfs is not usable on arm32 maybe note about that should be added to APKBUILD
2019-06-09 21:14:38 <jwh> the same caveats likely apply (or maybe it's worse, I'm not that intimately familiar with arm32) - it requires a lot of tuning and delicate use
2019-06-09 21:14:47 <jwh> same caveats as x86-32 that is
2019-06-09 21:15:03 <jwh> and even then it'll probably still break
2019-06-09 21:17:29 <mps> jwh: yes, most people write software with 64bit arches in mind
2019-06-09 21:18:04 <jwh> well its just the way solaris was designed that causes the problems on other OSes
2019-06-09 21:18:12 <jwh> but they did it that way for a reason
2019-06-09 21:18:31 <Cogitri> Well, 32-bit dies on most platforms so its not a u reasonable assumption
2019-06-09 21:18:59 <jwh> it isn't really that its designed for 64bit, just that it wants a lot of memory to play with
2019-06-09 21:19:03 <jwh> which 32bit cannot provide
2019-06-09 21:19:41 <mps> Cogitri: number of manufactured of 32bit CPU's is a lot more than 64bit even today
2019-06-09 21:20:22 <Cogitri> Not for desktop though
2019-06-09 21:20:29 <Cogitri> For embedded stuff that's most likely true, yes
2019-06-09 21:20:45 <Cogitri> But most devs are on desktop/server stuff which more than not is 64-bit
2019-06-09 21:21:08 <mps> right, if you don't count your keyboard as desktop device ;) but we are OT now. sorry
2019-06-09 21:21:11 <jwh> you can't even buy 32bit only general purpose CPUs anymore, so that probably contributes :D
2019-06-09 21:21:35 <jwh> mps: you have an armv7 device right?
2019-06-09 21:21:37 <Cogitri> Yup
2019-06-09 21:22:34 <Cogitri> I have a RPi1 as printer server, that's enough 32-bitness for me :P
2019-06-09 21:22:44 <mps> jwh: yes, exynos 8cpu's 4GB ram 1920x1080 display in compact note/chromebook
2019-06-09 21:22:58 <jwh> you should be able to test zfs easily on that
2019-06-09 21:23:09 <jwh> 4G ram is quite a lot though, so you probably won't encounter any real issues
2019-06-09 21:23:20 <mps> and a few SBC's for different things and very good ones
2019-06-09 21:23:51 <mps> jwh: I don't use zfs, so are no eager to test it
2019-06-09 21:24:02 <jwh> well its easy enough to test if you want to enable it
2019-06-09 21:24:13 <jwh> fallocate;losetup -P
2019-06-09 21:24:34 <mps> just wanted to note that that we have pkg's in main which are disabled for some arches
2019-06-09 21:24:42 <danieli> i have 32G memory in this box and it's not enough
2019-06-09 21:24:55 <jwh> for zfs?
2019-06-09 21:25:06 <danieli> not zfs, just in general
2019-06-09 21:25:09 <jwh> oh
2019-06-09 21:25:10 <jwh> lol
2019-06-09 21:25:14 <danieli> re: '4G is quite a lot (...)'
2019-06-09 21:25:14 <mps> 32GB is not enough? huh, what to say
2019-06-09 21:25:17 <danieli> :)
2019-06-09 21:25:19 <Cogitri> I run ZFS on my notebook with 16 gigs
2019-06-09 21:25:25 <jwh> danieli: well it is for a limited platform
2019-06-09 21:27:40 <danieli> i haven't measured but i know ZOL eats *some* of my memory
2019-06-09 21:27:54 <jwh> its pretty greedy
2019-06-09 21:28:07 <jwh> it'll have all of your 32G if it feels like it
2019-06-09 21:28:36 <danieli> it can't because most is taken most of the time
2019-06-09 21:28:50 <SpaceToast> I just run btrfs
2019-06-09 21:28:58 <Cogitri> It wdoes the actually stop you from using your RAM thp
2019-06-09 21:29:09 <Cogitri> It frees it once smth requests mor RAM
2019-06-09 21:29:20 <Cogitri> Yeaaah, BTRFS has eaten my data twice, so no
2019-06-09 21:29:23 <danieli> i had to make oomkiller a bit more active to let my computer remain interactive when i use a little too much memory
2019-06-09 21:29:33 <SpaceToast> ¯\_(ツ)_/¯
2019-06-09 21:29:38 <maxice8> SpaceToast: we got exa now
2019-06-09 21:29:45 <danieli> btrfs has eaten my data once, but that was because of a mistake i made
2019-06-09 21:29:51 <SpaceToast> I've been running btrfs on 20+ hosts for like 3 years
2019-06-09 21:30:00 <SpaceToast> it's never eaten my data without it being my fault
2019-06-09 21:30:01 <danieli> red hat has dropped it but suse is going all in
2019-06-09 21:30:04 <SpaceToast> (with it being my fault too, but still)
2019-06-09 21:30:16 <SpaceToast> maxice8: it has a timezone-related bug, if you use $TZ
2019-06-09 21:30:23 <SpaceToast> which is why I didn't bother submitting it yet
2019-06-09 21:30:30 <SpaceToast> but it should be ok if it's in testing/ anyway
2019-06-09 21:30:40 <Cogitri> For me it died twice after hard resets due to KVM
2019-06-09 21:33:30 <jwh> is exa actually bootable yet?
2019-06-09 21:33:51 <jwh> or exo
2019-06-09 21:33:52 <maxice8> uhh
2019-06-09 21:33:52 <jwh> or w/e it was
2019-06-09 21:34:06 <jwh> what was that new one
2019-06-09 21:34:12 <SpaceToast> jwh: exa is an ls-like
2019-06-09 21:34:18 <maxice8> i mean exa the ls but rewritten in rust
2019-06-09 21:34:20 <SpaceToast> with nicer colors an a few extra features
2019-06-09 21:34:21 <jwh> o
2019-06-09 21:34:22 <Cogitri> exa is a ls replacement written in rust
2019-06-09 21:34:25 <jwh> I thought you meant the fs lol
2019-06-09 21:34:31 <jwh> maybe it was abandoned
2019-06-09 21:34:49 <SpaceToast> bcachefs?
2019-06-09 21:35:00 <jwh> hm maybe
2019-06-09 22:08:37 <tmhoang> sunday seems to be hot again
2019-06-09 22:09:47 <SpaceToast> very
2019-06-09 22:26:12 <danieli> hm
2019-06-09 22:26:30 <danieli> pwd in build() is not what i set $builddir t
2019-06-09 22:26:32 <danieli> to*
2019-06-09 22:27:00 <danieli> abuild-3.4.0_rc4-r0
2019-06-09 22:27:22 <danieli> ah, i screwed something up, nevermind
2019-06-09 22:29:33 <jwh> lol
2019-06-09 22:30:04 <danieli> i realized it would be 10x easier to do the bootstrapping through a separate package, so i did that, but i used $pkgname in $builddir
2019-06-09 23:13:13 <danieli> does busybox `cp' not have an option to do -a (-dpR) but ignore certain attributes?
2019-06-09 23:14:14 <mps> it should have
2019-06-09 23:14:27 <danieli> it seems extremely limited to me
2019-06-09 23:14:44 <danieli> ah, okay, the man page has everything, --help does not
2019-06-09 23:14:53 <mps> maybe -p
2019-06-09 23:15:26 <danieli> -p included in -a, but i want to preserve all attributes except one (owner)
2019-06-09 23:15:36 <mps> ehm, yes, sorry
2019-06-09 23:16:03 <mps> aha, not sure bb cp support this
2019-06-09 23:21:55 <danieli> i guess i could do `find (...) -exec install (...) \;'
2019-06-09 23:22:04 <danieli> if it's even necessary, time will show
2019-06-10 00:05:37 <danieli> mps: you don't happen to remember how to make a package depend on package A *or* package B?
2019-06-10 00:06:09 <danieli> nevermind, it doesn't look like it'll be necessary, nice
2019-06-10 03:40:28 <SpaceToast> ping ncopa for when you wake up - it would be good to get pr8712 into 3.10; purely a bugfix, from upstream
2019-06-10 06:46:00 <_ikke_> morning all
2019-06-10 06:46:29 <Danct12> 1:46 PM
2019-06-10 06:46:33 <_ikke_> heh
2019-06-10 06:46:37 <_ikke_> ($dayoftime)
2019-06-10 06:46:50 <maxice8> https://patchwork.alpinelinux.org/patch/4888/ can be closed as py3-cairocffi is already built for python3.7
2019-06-10 06:47:56 <_ikke_> Done
2019-06-10 06:48:43 <_ikke_> But someone should reply as well to the mails
2019-06-10 06:48:55 <maxice8> Good luck
2019-06-10 06:50:47 <_ikke_> done
2019-06-10 06:50:57 <maxice8> nice
2019-06-10 06:51:46 <_ikke_> otherwise it looks like these are just ignored
2019-06-10 07:00:42 <maxice8> yes
2019-06-10 08:07:13 <mps> danieli: good morning. I tried to look for alternate dependencies and played with provides and negated depends but nothing worked, so I gave up to this
2019-06-10 08:35:03 <maxice8> uhhhh
2019-06-10 08:35:19 <maxice8> moving py to py3-pyldap broke wok which broke kimchi
2019-06-10 08:39:02 <_ikke_> We need to be careful changing these kinds of things
2019-06-10 08:39:12 <ncopa> morning
2019-06-10 08:39:23 <ncopa> we should get the 3.10.0 out this week
2019-06-10 08:39:29 <maxice8> ncopa: morning
2019-06-10 08:39:33 <_ikke_> ncopa: right
2019-06-10 08:39:38 <_ikke_> ncopa: in pressing matters?
2019-06-10 08:39:42 <maxice8> _ikke_: what to do now ? kimchi fails to build on armv7 ?
2019-06-10 08:39:48 <maxice8> disable kimchi on all arches ?
2019-06-10 08:40:07 <_ikke_> maxice8: can we revert the py3-pyldap change?
2019-06-10 08:40:34 <maxice8> yes
2019-06-10 08:40:56 <maxice8> _ikke_: http://tpaste.us/xpNr
2019-06-10 08:41:04 <_ikke_> I would go for that then (don't forget to bump pkgrel in that case)
2019-06-10 08:41:27 <ncopa> something needs py2-pyldap?
2019-06-10 08:41:40 <maxice8> ncopa: wok and by extension kimchi
2019-06-10 08:41:47 <maxice8> wok needs it and there is ginger and gingertest
2019-06-10 08:42:06 <maxice8> so converting to python3 only entails moving 3 packages at least
2019-06-10 08:42:15 <_ikke_> wok doesn't have it in its dependencies
2019-06-10 08:42:36 <maxice8> py2-pyldap is in depends=
2019-06-10 08:42:59 <_ikke_> pkgs.a.o doesn't list it?
2019-06-10 08:43:19 <ncopa> hm
2019-06-10 08:43:19 <_ikke_> I see it in the APKBUILD
2019-06-10 08:43:21 <maxice8> i'm looking at the APKBUILDs
2019-06-10 08:43:27 <ncopa> kimchi is in testing
2019-06-10 08:43:37 <ncopa> and seems to have python3 support in latest git
2019-06-10 08:43:59 <ncopa> i suppose the quickest fix is to revert
2019-06-10 08:49:29 <mps> in a last few days number of failed builds on armv7 is increased. anyone have idea what is the culprit?
2019-06-10 09:08:27 <ncopa> no clue
2019-06-10 09:08:37 <ncopa> seems like pg_cron fails on other arches as well
2019-06-10 09:08:43 <ncopa> s390x and ppc64le
2019-06-10 09:09:25 <maxice8> looking at it
2019-06-10 09:09:27 <maxice8> it fails on all arches
2019-06-10 09:14:17 <_ikke_> ncopa: I fixed at least one issue with the armv7 builder
2019-06-10 09:27:54 <maxice8> ncopa: fixed pg_cron
2019-06-10 09:27:58 <maxice8> the problem was that the version was too old for our recent `acl` package
2019-06-10 09:28:29 <mps> ncopa: we talked last week about enabling some drivers for armhf/armv7 in linux-vanilla, serial console at least. I have split minds about this and not sure if it worth in this point
2019-06-10 09:29:40 <mps> it will enable seeing kernel boot messages and rest but will not solve all problems on some of SOC's
2019-06-10 09:31:12 <mps> here is the patch http://tpaste.us/yPxn you decide if it is worth to apply it
2019-06-10 09:39:46 <ncopa> mps: will apply
2019-06-10 09:39:48 <ncopa> if it builds
2019-06-10 09:40:16 <mps> tested it, it builds
2019-06-10 09:40:31 <mps> only forgot to add pkgrel bump, I see now
2019-06-10 09:41:25 <mps> and tested on real hardware that serial console works
2019-06-10 09:42:45 <mps> but I don't want to say that you shouldn't test build. more tests with more people are always good
2019-06-10 09:42:46 <ncopa> no need for bump in this case as i am about to upgrade version at the same time
2019-06-10 09:43:01 <ncopa> i am building it as we spead
2019-06-10 09:43:11 <mps> good
2019-06-10 09:44:21 <mps> to repeat, it is not final solution to install Alpine on these boards but at least users will have chance to see boot process and error messages
2019-06-10 09:44:51 <mps> we have to work on real solution in (near) future
2019-06-10 09:45:40 <ncopa> ok
2019-06-10 09:45:44 <ncopa> but its a step forward
2019-06-10 09:46:08 <_ikke_> ncopa: I assume it's not standard for builders to pass -s and -k to buildrepo
2019-06-10 09:46:58 <ncopa> correct
2019-06-10 09:47:06 <_ikke_> that was the case for armv7
2019-06-10 09:47:16 <ncopa> ok
2019-06-10 09:47:34 <ncopa> did you change it back?
2019-06-10 09:47:36 <_ikke_> yes
2019-06-10 09:47:39 <danieli> should have a look at pr8629 for 3.10
2019-06-10 09:47:51 <_ikke_> danieli: right, I still have that in my 'queue'
2019-06-10 09:47:58 <danieli> i can test build it over again just to make sure
2019-06-10 09:48:05 <danieli> travis succeeded but not drone
2019-06-10 09:48:11 <_ikke_> Due to time?
2019-06-10 09:48:43 <ncopa> is it ready to push?
2019-06-10 09:49:00 <danieli> a seemingly random test failed in drone
2019-06-10 09:49:33 <ncopa> oh what arch?
2019-06-10 09:49:34 <mps> danieli: on which arch it failed
2019-06-10 09:49:37 <ncopa> on*
2019-06-10 09:49:42 <danieli> all of them on drone
2019-06-10 09:49:59 <mps> aha, will try now on lxc
2019-06-10 09:50:14 <danieli> entire thing ran for 40 mins according to travis
2019-06-10 09:51:03 <mps> good, will have enough time for coffee ;)
2019-06-10 09:51:40 <danieli> i got some tea, so i'm happy
2019-06-10 09:52:26 <mps> oh, yes. better will be tea, thanks for remind me
2019-06-10 09:55:25 <mps> yesterday I noticed that hexchat is in main. should it be moved to community
2019-06-10 09:55:50 <_ikke_> probably, same I guess for weechat
2019-06-10 09:56:24 <_ikke_> A lot of these are still in main from the time that community did not exist
2019-06-10 09:56:52 <mps> and disabled for armhf/armv7, I tested build on armv7 of hexchat and it pass without error
2019-06-10 10:04:52 <mps> danieli: erlang pass build on armv7 in lxc
2019-06-10 10:05:02 <danieli> mps: elixir was the one that failed
2019-06-10 10:05:16 <mps> aha,ok
2019-06-10 10:05:31 <mps> does elixir need erlang to build
2019-06-10 10:05:36 <danieli> yes
2019-06-10 10:05:54 <danieli> all of the other packages that were modified in the PR are packages that need to be rebuilt against newer erlang
2019-06-10 10:06:30 <mps> so, we should push erlang first and when uploaded then continue with elixir?
2019-06-10 10:09:40 <danieli> correct
2019-06-10 10:09:49 <danieli> apparently github PRs process them in order
2019-06-10 10:10:13 <mps> building elixir now
2019-06-10 10:11:57 <mps> linux-vanilla failed on aarch64. I think I didn't touched aarch64 config
2019-06-10 10:14:26 <mps> danieli: ls excerpt: -rw-r--r-- 1 mps mps  4039233 Jun 10 10:12 elixir-1.8.2-r0.apk
2019-06-10 10:14:31 <mps> on armv7
2019-06-10 10:14:47 <mps> date is UTC
2019-06-10 10:14:55 <danieli> i'm rebuilding on a pretty clean x86_64 system to double chek
2019-06-10 10:14:59 <danieli> check*
2019-06-10 10:15:00 <mps> it passed
2019-06-10 10:15:21 <danieli> i'm working on getting ada ide (gnat prog. studio / gps) into alpine
2019-06-10 10:16:12 <mps> ada? hmm.......
2019-06-10 10:18:32 <danieli> elixir builds fine
2019-06-10 10:20:05 <mps> also here, nice
2019-06-10 10:20:53 <danieli> armv7?
2019-06-10 10:21:37 <mps> ncopa: 'abuild -r' linux-vanilla on aarch64 stops asking some question for enabling some thins
2019-06-10 10:21:42 <mps> 'Cortex-A76: Software Step might prevent interrupt recognition (ARM64_ERRATUM_1463225) [Y/n/?] (NEW)'
2019-06-10 10:21:50 <mps> danieli: yes, armv7
2019-06-10 10:21:59 <ncopa> mps: ok. will fix that
2019-06-10 10:22:10 <mps> good
2019-06-10 10:25:23 <danieli> hm
2019-06-10 10:25:33 <danieli> something isn't right with cloudi (as it is now)
2019-06-10 10:25:39 <danieli> >>> cloudi: Analyzing dependencies...
2019-06-10 10:25:39 <danieli> ERROR: unsatisfiable constraints:
2019-06-10 10:25:39 <danieli>     required by: ocaml-4.07.1-r0[so:libbfd-2.31.1.so]
2019-06-10 10:25:39 <danieli>   so:libbfd-2.31.1.so (missing):
2019-06-10 10:27:50 <danieli> libbfd-2.32.so is provided by binutils
2019-06-10 10:28:01 <danieli> so ocaml has to be rebuilt against it
2019-06-10 10:30:10 <mps> ocam lang is useful of other CPUs except transputers? interesting, didn't looked at for long time
2019-06-10 10:30:22 <danieli> ocaml is pretty cool
2019-06-10 10:31:10 <mps> right, I learned some 'net' processing concepts from it and transputers
2019-06-10 10:31:35 <danieli> F# began a an implementation of the ocaml core
2019-06-10 10:31:37 <danieli> as*
2019-06-10 10:48:15 <ncopa> im rebuilding ocaml and cloudi
2019-06-10 10:48:55 <hjaekel> is pr8335 ready to merge, or does it need additional review by ncopa as a maintainer?
2019-06-10 10:50:57 <mps> hjaekel: didn't you renamed proj4 to proj earlier
2019-06-10 10:52:17 <hjaekel> yes I did. But I wanted to split the huge pr into smaller ones. This is the first one and I am waiting to submit the other ones
2019-06-10 10:53:36 <mps> good, will look at it if ncopa doesn't have time
2019-06-10 10:55:00 <hjaekel> thanks
2019-06-10 10:55:19 <danieli> git worktree is wonderful
2019-06-10 10:55:28 <mps> np
2019-06-10 10:56:15 <danieli> i'm testing it atm
2019-06-10 11:00:30 <danieli> >>> WARNING: proj4-dev*: Found static archive on usr/lib/libproj.a but name doesn't end with -static
2019-06-10 11:00:33 <danieli> this the only remark from me
2019-06-10 11:03:02 <hjaekel> danieli, should I just delete libproj.a?
2019-06-10 11:03:27 <danieli> you can leave it for now if it was already like that
2019-06-10 11:04:00 <danieli> what i'm thinking is to add $pkgname-static as a subpackage, it should automatically extract the .a file into it, but i can sort that after yours is merged
2019-06-10 11:04:08 <danieli> and it's merged
2019-06-10 11:04:35 <maxice8> If you add a static subpackage please define a function for it
2019-06-10 11:05:02 <maxice8> Stable releases still don't have abuild with default_static
2019-06-10 11:05:14 <danieli> ah, okay
2019-06-10 11:05:29 <maxice8> If it is in testing it is OK I guess
2019-06-10 11:05:31 <hjaekel> danieli, thank you. can you let me create the -static subpackage, I already prepared some more pr, just to avoid merge conflicts
2019-06-10 11:05:35 <maxice8> Since testing is only on edge
2019-06-10 11:05:44 <danieli> hjaekel: you can do it if you'd like :)
2019-06-10 11:05:47 <mps> if the -static is needed for this pkg, for now it could be ignored, afaik
2019-06-10 11:05:55 <maxice8> Also define it in the subpackages variable before -dev
2019-06-10 11:06:25 <mps> maxice8: good catch
2019-06-10 11:06:26 <maxice8> Since the default_dev still globbles it up even if static is defined
2019-06-10 11:06:30 <danieli> indee
2019-06-10 11:06:31 <danieli> d
2019-06-10 11:06:52 <maxice8> Easy to know when you're the one that introduced the fuck up in the first place :^)
2019-06-10 11:07:50 <mps> I had a hope that this channel will be free of bad words
2019-06-10 11:08:05 <danieli> i started working on a apk reimpl and a partial abuild reimpl in C
2019-06-10 11:08:39 <danieli> mps: https://www.vidarholen.net/contents/wordcount/
2019-06-10 11:11:47 <mps> ah, ok, proj4 already pushed
2019-06-10 11:30:44 <mps> these perl-dbix-* pkg's needs perl-sql-abstract to be built on builders
2019-06-10 11:31:19 <mps> anyone can trigger build of it
2019-06-10 11:43:55 <danieli> so i have this lib<package> that provides a .so file, but abuild says >>> ERROR: <pkgname>*: <libfile>.so: path not found
2019-06-10 11:44:07 <danieli> i tried to add provides="so:<libfile>.so" but that did not work
2019-06-10 11:44:31 <danieli> it clearly symlinks /usr/lib/<libfile>.so to the real .so file on disk
2019-06-10 11:45:27 <ncopa> normally the /usr/lib/libfoo.so is a symlink to a versioned library
2019-06-10 11:45:31 <danieli> yes
2019-06-10 11:45:32 <ncopa> like libfoo.so.1
2019-06-10 11:45:41 <danieli> it's /usr/lib/<libfile>.so.2019 -> real path
2019-06-10 11:45:55 <danieli> (version is simply "2019")
2019-06-10 11:55:07 <mps> maxice8: you asked about https://patchwork.alpinelinux.org/patch/4803/ pkg, testing/shadowsocks-libev
2019-06-10 11:55:29 <mps> did you made PR for it or did something else
2019-06-10 11:55:53 <maxice8> I have a PR for it
2019-06-10 11:56:23 <mps> ok, what to do with these two patches on pw.a.o
2019-06-10 11:56:39 <mps> to reject them or ?
2019-06-10 11:57:49 <maxice8> Not sure they even work since it doesn't add libcorkipset and libbloom to the dependencies
2019-06-10 11:58:38 <mps> yes, but one polite mail should be sent to author
2019-06-10 11:58:43 <danieli> https://hastebin.com/raw/yonegutaqo perhaps it's failing because of how it symlinks?
2019-06-10 12:00:43 <mps> maxice8: could you write short message about this
2019-06-10 12:01:15 <maxice8> Later am waiting someone at Bus station
2019-06-10 12:02:42 <mps> np, we are not in hurry. :)
2019-06-10 12:14:14 <hjaekel> pr8719 is my next pr for proj4. It adds -static and -utils subpackages. Subsequent pr's will add the datumgrid subpackage and the final rename
2019-06-10 12:17:50 <mps> hjaekel: did you test build?
2019-06-10 12:18:49 <hjaekel> yes, but only on x86_64
2019-06-10 12:19:55 <mps> that's fine. I don't see static() and because that ask
2019-06-10 12:21:46 <danieli> as maxice8 said, you need to define static() because of some brokenness with default_static()
2019-06-10 12:22:03 <hjaekel> edge already has default_static
2019-06-10 12:22:10 <danieli> apparently stable doe snot
2019-06-10 12:22:12 <danieli> does not*
2019-06-10 13:12:46 <danieli> wtf, my build box went downwut
2019-06-10 13:12:54 <danieli> oops, forgot to remove the old message in the input field :)
2019-06-10 13:13:12 <danieli> anyway - wut - #alpine-commits reports a build error for kitty-0.14.2-r0 on x86, but it successfully built
2019-06-10 13:16:59 <opal> wheres your build box located
2019-06-10 13:17:05 <opal> my dedi shat itself
2019-06-10 13:17:09 <opal> networking issue
2019-06-10 13:22:19 <danieli> Packet.net AMS according to our netbox
2019-06-10 13:22:25 <danieli> (netbox went down too, but it's back)
2019-06-10 13:22:35 <danieli> anyway, it most likely wasn't the build box that went down, it was the VPN link
2019-06-10 13:26:54 <opal> hm
2019-06-10 14:03:25 <ncopa> danieli: elixir fails to build for me
2019-06-10 14:03:37 <danieli> ncopa: interesting, what fails_
2019-06-10 14:03:38 <danieli> ?
2019-06-10 14:03:41 <danieli> the same test as drone ci?
2019-06-10 14:04:00 <ncopa>   1) test does not start applications on --no-start (Mix.Tasks.RunTest)
2019-06-10 14:04:00 <ncopa>      test/mix/tasks/run_test.exs:39
2019-06-10 14:04:00 <ncopa>      Expected false or nil, got {:sample, 'sample', '0.1.0'}
2019-06-10 14:04:00 <ncopa>      code: refute List.keyfind(apps, :sample, 0)
2019-06-10 14:04:00 <ncopa>      arguments:
2019-06-10 14:04:14 <danieli> that's so strange, same thing happens in drone ci
2019-06-10 14:04:14 <ncopa> ...
2019-06-10 14:04:18 <danieli> but it builds fine for me *and* in travis
2019-06-10 14:04:23 <ncopa>      stacktrace:
2019-06-10 14:04:23 <ncopa>        test/mix/tasks/run_test.exs:45: anonymous fn/0 in Mix.Tasks.RunTest."test does not start applications on --no-start"/1
2019-06-10 14:04:23 <ncopa>        (elixir) lib/file.ex:1506: File.cd!/2
2019-06-10 14:04:23 <ncopa>        test/mix/tasks/run_test.exs:40: (test)
2019-06-10 14:04:28 <ncopa> this is on armv7
2019-06-10 14:04:48 <danieli> does the elixir package predate armv7 as a supported arch?
2019-06-10 14:04:50 <danieli> aarch64) options="!check" ;; # FIXME
2019-06-10 14:05:46 <mps> it builds for me on armv7
2019-06-10 14:06:10 <ncopa> maybe its a bug in thte testsuite?
2019-06-10 14:06:46 <mps> I could try on aarch64, if you mind
2019-06-10 14:07:23 <danieli> i've asked in #elixir-lang and if i don't figure it out, i will create an issue if there is none
2019-06-10 14:30:50 <mps> danieli: ncopa: I enabled check on current elixir on aarch64 and it passed 'abuild -r' without error
2019-06-10 14:31:11 <mps> current in aports, I mean
2019-06-10 14:32:10 <danieli> heisenbug?
2019-06-10 15:27:00 <ncopa> i think im gonna tag rc3 now
2019-06-10 15:27:31 <_ikke_> Something specific that still needs to be tested?
2019-06-10 15:27:56 <ncopa> the installer with different variations
2019-06-10 15:28:02 <ncopa> like tmpfs install
2019-06-10 15:28:07 <ncopa> with encrypted apkovl etc
2019-06-10 15:28:34 <ncopa> rc3 is tagged
2019-06-10 15:28:44 <ncopa> then we only need make a release notes i think
2019-06-10 15:29:41 <_ikke_> I think I can test on a raspberry pi 1b and 2
2019-06-10 15:30:17 <mps> testing/fgt fails on builder armv7 saying that 'sha512sum: WARNING: 1 of 1 computed checksums did NOT match'
2019-06-10 15:30:20 <danieli> i can test on 3 if i'm told exactly what to test
2019-06-10 15:31:01 <danieli> i have at least one of absolutely all the rpi models
2019-06-10 15:31:08 <_ikke_> nicwe
2019-06-10 15:31:21 <ncopa> test install it from scratch
2019-06-10 15:31:21 <mps> but it builds fine on armv7 lxc, without this error
2019-06-10 15:32:26 <ncopa> mps: i removed the file from distfiles
2019-06-10 15:32:34 <danieli> 1b, 1a, 1b+, 1a+, 1b, zero, zero w, 3b, 3a+, 3b+
2019-06-10 15:32:52 <ncopa> we could check which of those we want to merge https://github.com/alpinelinux/aports/pulls?q=is%3Aopen+is%3Apr+milestone%3A%223.10+release%22
2019-06-10 15:33:16 <mps> ok, it should build on next pass then
2019-06-10 15:33:37 <ncopa> we should also try to fix as many of those as possible: https://bugs.alpinelinux.org/projects/alpine/issues?fixed_version_id=144&set_filter=1&status_id=o
2019-06-10 15:33:51 <danieli> beware of exim and vlc vulns
2019-06-10 15:34:04 <_ikke_> I pushed the vlc update already
2019-06-10 15:34:14 <danieli> i see the exim one on the tracker
2019-06-10 15:34:22 <danieli> it's been exploited in the wild
2019-06-10 15:34:25 <_ikke_> What tracked?
2019-06-10 15:34:27 <_ikke_> tracker
2019-06-10 15:34:32 <danieli> alpine sec
2019-06-10 15:36:49 <danieli> it's patched in edge but not any other branch
2019-06-10 15:37:05 <_ikke_> ah ok
2019-06-10 15:37:50 <_ikke_> It's in community though
2019-06-10 15:38:14 <ncopa> im fixing int now
2019-06-10 15:38:49 <ncopa> there are some report saying some rpi is broken
2019-06-10 15:38:53 <ncopa> i think we pished fix
2019-06-10 15:38:56 <danieli> which model(s)?
2019-06-10 15:38:56 <ncopa> pushed
2019-06-10 15:38:57 <danieli> i can test
2019-06-10 15:39:10 <danieli> hm, i should set up a vlan for netbooting rpis
2019-06-10 15:39:18 <ncopa> https://bugs.alpinelinux.org/issues/10155
2019-06-10 15:39:56 <danieli> ah
2019-06-10 15:40:00 <_ikke_> ncopa: so you are handling exim?
2019-06-10 15:50:24 <_ikke_> This is the patch: https://github.com/Exim/exim/commit/d740d2111f189760593a303124ff6b9b1f83453d.patch
2019-06-10 15:50:46 <danieli> iirc it's patched in 1.91
2019-06-10 15:50:59 <_ikke_> the patch applies until 1.87 they say
2019-06-10 15:51:08 <danieli> mm, might as well just backport the patch
2019-06-10 15:51:38 <_ikke_> If it hadn't leaked, the patch would only be released tomorrow
2019-06-10 15:53:02 <_ikke_> ncopa: upgraded exim to 1.92 on 3.9
2019-06-10 15:53:21 <_ikke_> oh, mksully22 did
2019-06-10 16:49:18 <ncopa> i cherry-picked commit for exim
2019-06-10 17:39:43 <_ikke_> ncopa: you applied this PR https://github.com/alpinelinux/aports/pull/8705, which removes the option="!check" without reason
2019-06-10 17:39:51 <_ikke_> and the PR isn't closed
2019-06-10 18:44:23 <ddevault> has anyone had a chance to check out that FDE patch I sent for setup-disks
2019-06-10 18:59:45 <kpcyrd> ddevault: briefly, I'd really like to have it. I pinged the channel a while ago and the reply I got was that everybody is busy with the release.
2019-06-10 18:59:53 <ddevault> fair enough
2019-06-10 20:17:27 <danieli> i have a package requiring libgpr.so, which is provided by one of its subpackages (libgpr) - it reports >>> ERROR: gprbuild*: libgpr.so: path not found
2019-06-10 20:17:29 <danieli> how do I solve that?
2019-06-10 20:18:04 <_ikke_> When do you get that message?
2019-06-10 20:18:22 <danieli> tracing dependencies for the parent package
2019-06-10 20:18:28 <[[sroracle]]> you might have to specify ldpath= in APKBUILD
2019-06-10 20:18:41 <[[sroracle]]> if the .so is not in a standard location
2019-06-10 20:19:12 <danieli> lrwxrwxrwx root/root         0 2019-06-10 20:15 lib/libgpr.so -> ../lib//gpr/relocatable/gpr/libgpr.so
2019-06-10 20:19:12 <danieli> -rwxr-xr-x root/root   5313216 2019-06-10 20:15 lib/gpr/relocatable/gpr/libgpr.so
2019-06-10 20:19:26 <danieli> hm, that doesn't look right, it installs in /lib and not /usr/lib
2019-06-10 20:20:32 <[[sroracle]]> in that case you can try options=ldpath-recursive. but yeah i agree it should probably be in /usr/lib
2019-06-10 20:20:35 <danieli> it was `"$subpkgdir"' and not `"$subpkgdir"/usr', let's see if it works now
2019-06-10 20:20:51 <danieli> it was meant to, i made a mistake, but i'll see in a second if that fixes it
2019-06-10 20:21:49 <danieli> darn it, still path not found for the .so, even if it's set to depend on the subpackage containing it
2019-06-10 20:23:21 <danieli> daniel@disaksen-edge-x86_64 [~/aports/testing/gprbuild]$ tar -tvf ~/packages/testing/x86_64/libgpr-2019-r0.apk | grep "\.so"
2019-06-10 20:23:22 <danieli> lrwxrwxrwx root/root         0 2019-06-10 20:21 usr/lib/libgpr.so -> ../lib//gpr/relocatable/gpr/libgpr.so
2019-06-10 20:23:22 <danieli> -rwxr-xr-x root/root   5313216 2019-06-10 20:21 usr/lib/gpr/relocatable/gpr/libgpr.so
2019-06-10 20:23:32 <danieli> oops, pasted one line too much - whatever
2019-06-11 03:20:08 <E-werd> what does it take to move a package out of testing and into main?
2019-06-11 03:20:37 <E-werd> hiawatha has been running great for me, literally no issues in all my tinkering but I still need to have edge enabled to use it
2019-06-11 03:22:00 <danieli> why main? why not community?
2019-06-11 03:22:21 <danieli> getting packages from testing to community (i.e. into the next stable release too) just takes an active maintainer and some testing of the package so it's verified to work
2019-06-11 03:34:29 <E-werd> well, whatever the case... just out of edge/testing
2019-06-11 03:34:45 <E-werd> I'm not super familiar with the categorization
2019-06-11 03:35:05 <E-werd> but ok, understood
2019-06-11 03:36:36 <danieli> there's main that's "super important software", community is the rest
2019-06-11 03:36:44 <danieli> testing is fairly self explanatory, and is only built for edge
2019-06-11 03:37:18 <danieli> well, main is guaranteed to be supported for a good while
2019-06-11 06:22:19 <danieli> ncopa: sorry about the spam
2019-06-11 09:25:06 <ncopa> _ikke_: re pr8705 it passed the CI so I assume upstream have fixed the tests?
2019-06-11 09:32:33 <_ikke_> ncopa: No, there is no check() function defined
2019-06-11 09:32:42 <_ikke_> so abuild complains no test are run
2019-06-11 09:33:06 <_ikke_> There are still some musl incompatibilities I'm trying to fix one day
2019-06-11 09:53:50 <mps> ncopa: yesterday patch to linux-vanilla for armhf/armv7 is even better than I expected
2019-06-11 09:54:26 <mps> I'm testing it on two boards now alpine is better on them
2019-06-11 09:57:25 <maxice8> found out why icmake-comp doesn't appear and thus makes yodl fail to build
2019-06-11 09:57:34 <maxice8> it fails to link with undefined references
2019-06-11 09:58:36 <_ikke_> ah, ok
2019-06-11 09:58:43 <_ikke_> why doesn't abuild catch that?
2019-06-11 09:58:51 <maxice8> because the build system decides
2019-06-11 09:58:55 <maxice8> "nah it is fine, keep going"
2019-06-11 09:58:58 <_ikke_> right
2019-06-11 09:59:42 <maxice8> so you just have a huge undefined reference error
2019-06-11 09:59:58 <maxice8> and the build continues and gets packaged because the other components built.
2019-06-11 10:05:29 <maxice8> having -Os makes it fail
2019-06-11 10:05:29 <maxice8> -O2 works
2019-06-11 10:34:36 <maxice8> I get some packages that fail with undefined reference while linking on Os but works on O2
2019-06-11 10:35:21 <ncopa> sounds like optimizer optimizes away a bit too much
2019-06-11 10:35:58 <ncopa> question about llvm
2019-06-11 10:36:07 <ncopa> at this point, do we dare upgrade to llvm8?
2019-06-11 10:36:16 <ncopa> or du we upgrade to llvm 7.1?
2019-06-11 10:36:32 <ncopa> we want the 3.10 release out this week
2019-06-11 10:37:04 <maxice8> Hmmmm
2019-06-11 10:37:17 <maxice8> The new release does make it hard I'd normally push for 8
2019-06-11 10:39:14 <ncopa> its not ABI compatible either
2019-06-11 10:39:38 <maxice8> Yes that part im aware
2019-06-11 10:40:01 <maxice8> One of the best (sarcasm here) parts of VL is doing LLVM bumps
2019-06-11 10:42:20 <_ikke_> http://tpaste.us/vbmO
2019-06-11 10:42:27 <_ikke_> these packages seem to (make)depend on llvm
2019-06-11 10:42:47 <_ikke_> What does VL mean?
2019-06-11 10:43:00 <maxice8> Void Linux
2019-06-11 10:43:02 <_ikke_> ah
2019-06-11 10:43:52 <_ikke_> So rebuilding those would not be insurmountable
2019-06-11 10:44:56 <maxice8> The worst candidate is rust but I think Cogitri is working on it
2019-06-11 10:47:18 <mps> crystal cannot be built with llvm higher than 6
2019-06-11 10:47:53 <mps> also, ponyc afaik
2019-06-11 10:48:11 <_ikke_> llvm6 will still exist
2019-06-11 10:49:50 <mps> also, not sure that the ghc can be built with llvm8
2019-06-11 10:50:56 <mps> only rust 1.34 need llvm8, I think
2019-06-11 10:51:59 <mps> but I stopped to test these pkg because Cogitri promised he will work on them
2019-06-11 10:52:38 <mps> I'm diverting my interested back to arm boards
2019-06-11 11:04:10 <ncopa> Failing Tests (6):
2019-06-11 11:04:11 <ncopa>     LLVM :: DebugInfo/X86/debug_addr.ll
2019-06-11 11:04:11 <ncopa>     LLVM :: tools/llvm-dwarfdump/X86/debug_addr_address_size_mismatch.s
2019-06-11 11:04:11 <ncopa>     LLVM :: tools/llvm-dwarfdump/X86/debug_addr_dwarf4.s
2019-06-11 11:04:11 <ncopa>     LLVM :: tools/llvm-dwarfdump/X86/debug_addr.s
2019-06-11 11:04:11 <ncopa>     LLVM :: tools/llvm-dwarfdump/X86/debug_addr_unsupported_version.s
2019-06-11 11:04:11 <ncopa>     LLVM :: tools/llvm-dwarfdump/X86/debug_addr_version_mismatch.s
2019-06-11 11:04:18 <ncopa> thats on armv7
2019-06-11 11:04:57 <mps> which version
2019-06-11 11:05:08 <ncopa> llvm 7.1
2019-06-11 11:05:17 <mps> ah, yes
2019-06-11 11:05:25 <ncopa> this one https://github.com/alpinelinux/aports/pull/8699
2019-06-11 11:06:10 <mps> <my grumpy hat on> I told earlier that llvm7 is problematic </hat off> :)
2019-06-11 11:06:39 <ncopa> from my understanding the 7.1 woudl fix things?
2019-06-11 11:06:44 <mps> and I wrote that we should not add llvm7 at all
2019-06-11 11:07:12 <mps> they promised 7.1 but still didn't released it
2019-06-11 11:07:56 <mps> they promised they will release it in the end of february
2019-06-11 11:08:15 <mps> looks like they lost interest for this version
2019-06-11 11:09:14 <mps> but of course, this is my guess, I don't know for sure
2019-06-11 11:17:31 <Cogitri> Just move on from LLVM7 and use LLVM8 :)
2019-06-11 11:18:08 <Cogitri> On that note, pr8620
2019-06-11 11:19:10 <Cogitri> About ponyc: pr8626
2019-06-11 11:19:23 <Cogitri> But it's currently broken due to Gold being broken, working on it with upstream
2019-06-11 11:20:41 <Cogitri> I can work on Rust once the LLVM8 PR has been merged and pr8628
2019-06-11 11:21:00 <Cogitri> Right now everything is kind of stalling for people with access to main/ :)
2019-06-11 11:22:08 <Cogitri> <Cogitri "I can work on Rust once the LLVM"> I mean Rust on other arches
2019-06-11 11:23:45 <Cogitri> IMO we should just use LLVM8 where possible and LLVM6 elsewhere
2019-06-11 11:23:47 <mps> I think we should move llvm8 to community
2019-06-11 11:23:53 <mps> if not to main
2019-06-11 11:24:11 <mps> Cogitri: agree
2019-06-11 11:24:29 <Cogitri> <mps "I think we should move llvm8 to "> Then I'll have to do some more moving later on for ponyc and stuff, so that seems supoptimal to me
2019-06-11 11:24:36 <Cogitri> I'd prefer LLVM8 being in main
2019-06-11 11:25:55 <mps> you must have hard and convincing reasons to move from testing to main
2019-06-11 11:26:29 <_ikke_> One criteria is upstream support
2019-06-11 11:26:37 <mps> although I think your llvm8 should go directly to community and not to testing in first push
2019-06-11 11:26:39 <_ikke_> Will upstream support llvm8 for 2 years?
2019-06-11 11:26:42 <Cogitri> Well, it's only in testing to check if it builds on all arches
2019-06-11 11:27:01 <_ikke_> but llvm7 is in main as well
2019-06-11 11:27:31 <mps> I have big urge to move it to community after I tested it when you psoted your PR
2019-06-11 11:27:46 <Cogitri> <_ikke_ "but llvm7 is in main as well"> Yup
2019-06-11 11:27:59 <Cogitri> And no llvm8 in main means no clang in main
2019-06-11 11:28:00 <Cogitri> Which sounds super bad to me tbh
2019-06-11 11:28:01 <mps> but don't dare because I'm not still experienced in these actions on alpine
2019-06-11 11:28:16 <mps> there is clang6
2019-06-11 11:43:48 <Cogitri> Which should be removed some time down the line too
2019-06-11 11:50:34 <ncopa> i dont think we can move llvm to community
2019-06-11 11:50:38 <ncopa> due to mesa
2019-06-11 11:51:21 <_ikke_> does mesa need to be in main?
2019-06-11 11:51:29 <ncopa> due to xorg
2019-06-11 11:51:51 <ncopa> there is a lots of packages depending on mesa
2019-06-11 11:51:56 <ncopa> so we would need look over those
2019-06-11 11:52:00 <ncopa> and move them one by one
2019-06-11 11:52:07 <_ikke_> No direct dependencies?
2019-06-11 11:52:19 <_ikke_> I only see mesa-* on pkgs.a.o
2019-06-11 11:52:32 <ncopa> but i suspect it will be difficult
2019-06-11 11:52:35 <_ikke_> ah, dependend on the subpackages
2019-06-11 11:52:41 <_ikke_> ok n/m then
2019-06-11 11:52:43 <ncopa> its some of the subpackages to mesa
2019-06-11 11:53:24 <ncopa> im tno saying its impossible
2019-06-11 11:53:46 <ncopa> everything is possible. the impossible just takes longer time
2019-06-11 11:53:47 <_ikke_> At least oo much for 3.10 :0
2019-06-11 11:58:02 <Cogitri> Well, I personally don't see the problem with having llvm8 in main, Upstream usually makes a .1 if there are bigger problems with the release
2019-06-11 11:59:08 <ncopa> problem is that we have llvm 5,6,7,8
2019-06-11 11:59:11 <_ikke_> They apparently haven't done that for 7.0 yet
2019-06-11 11:59:19 <ncopa> they just did 7.1
2019-06-11 11:59:23 <_ikke_> ah ok
2019-06-11 11:59:34 <ncopa> but it breaks ABI so everything needs to be rebuilt...
2019-06-11 11:59:37 <_ikke_> mps mentioned they didn't release it yet
2019-06-11 12:04:10 <Cogitri> They released it and then reverted the release
2019-06-11 12:04:14 <Cogitri> Dunno what's up with that
2019-06-11 12:04:31 <Cogitri> <ncopa "but it breaks ABI so everything "> Yeah, LLVM doesn't care much about backwards compatibility
2019-06-11 12:07:04 <_ikke_> Few projects seem to care about that nowadays
2019-06-11 12:10:20 <Cogitri> Well, yes, but most projects don't release an API breaking major release every year
2019-06-11 12:18:24 <ncopa> i suppose we should upgrade clang, compiler-rt lldb etc if we push llvm8?
2019-06-11 12:18:40 <mps> I think we should not upgrade llvm now, but after release of 3.10
2019-06-11 12:18:50 <ncopa> but llvm7 is broken?
2019-06-11 12:19:03 <mps> hmmm. right
2019-06-11 12:19:20 <ncopa> what is currently using llvm7?
2019-06-11 12:19:44 <Cogitri> <ncopa "i suppose we should upgrade clan"> I have a PR open for those as well.
2019-06-11 12:19:48 <mps> bcc
2019-06-11 12:20:05 <Cogitri> ncopa: Rust, which is super broken, Mesa which works apparently, Clang
2019-06-11 12:20:09 <mps> bpftrace
2019-06-11 12:20:28 <ncopa> Cogitri: wher eis the PR for clang?
2019-06-11 12:20:45 <ncopa> im looking at a PR which only move llvm8 to main and makes it default
2019-06-11 12:22:05 <_ikke_> (fyi: https://github.com/alpinelinux/aports/pull/8620)
2019-06-11 12:22:33 <mps> if you are ready to postpone release some days than trying llvm8 sounds reasonable
2019-06-11 12:23:28 <Cogitri> pr8584 is for the other LLVM stuff
2019-06-11 12:23:40 <Cogitri> I need to add llvm-libunwind to that too
2019-06-11 12:24:01 <Cogitri> And split it up to let CI run over it once LLVM8 to main has been merged
2019-06-11 12:24:38 <mps> Cogitri: I don't expect problems with llvm8
2019-06-11 12:25:40 <Cogitri> Same
2019-06-11 12:29:40 <mps> In a hour or two I will try to build all from your PR on armv7, but now I will be afk for some time
2019-06-11 12:56:38 <ncopa> i think we also need to rebuild afl, beanstalkd, firefox-esr, greenbone-security-assistant, gvm-libs, gvmd, and openvas-scanner
2019-06-11 12:56:45 <ncopa> which seems to use clang
2019-06-11 12:57:07 <Cogitri> Yup
2019-06-11 13:31:35 <ncopa> im building llvm8 + friends
2019-06-11 13:31:38 <ncopa> seems to be ok
2019-06-11 13:31:48 <ncopa> merging mesa while at it, and rebuild it against llvm8
2019-06-11 13:32:10 <Cogitri> Okie
2019-06-11 13:32:29 <mps> uhm, 'load average: 311.65, 294.32, 297.99', do we build on same machine
2019-06-11 13:32:33 <ncopa> i guess we can do the rebuilds with clang after thats
2019-06-11 13:32:38 <ncopa> mps i think we may do :)
2019-06-11 13:32:49 <mps> should I stop then
2019-06-11 13:33:01 <ncopa> are you working on llvm8?
2019-06-11 13:33:16 <ncopa> i think im almost done
2019-06-11 13:33:20 <mps> yes, right now building clang
2019-06-11 13:33:21 <ncopa> and ready to push
2019-06-11 13:33:28 <ncopa> i've built it all now
2019-06-11 13:33:41 <ncopa> i also enabled lldb for armv7
2019-06-11 13:33:48 <mps> I'm buildind on armv7 lxc
2019-06-11 13:33:53 <ncopa> same
2019-06-11 13:33:56 <ncopa> i think you can halt it
2019-06-11 13:34:01 <mps> ok
2019-06-11 13:34:01 <ncopa> im gonna push it in a sec
2019-06-11 13:34:15 <ncopa> mesa rebuild is done
2019-06-11 13:34:23 <mps> stopped
2019-06-11 13:34:25 <ncopa> i also upgraded llvm-libunwind
2019-06-11 13:35:13 <ncopa> ok. im pushing
2019-06-11 13:36:29 <Cogitri> Thank you!
2019-06-11 13:39:18 <ncopa> im rebuilding the stuff using clang
2019-06-11 13:39:25 <ncopa> in community
2019-06-11 13:39:38 <ncopa> so, can we fix rust now?
2019-06-11 13:41:26 <Cogitri> Yup. Once LLVM8 is built I'll push to the 1.35.0 PR again
2019-06-11 13:42:12 <Cogitri> My plan would be to merge 1.35.0 for x86_64, then I'll cross build tarballs for the other arches, upload them somewhere so they can be mirrored on Alpine infra and then enable the other arches in the APKBUILD
2019-06-11 13:45:01 <Cogitri> Actually, I think I need someone to build the tarballs for me because Alpine doesn't really support cross compiling
2019-06-11 13:53:48 <Cogitri> Will set up a Void Linux install for crosscompiling tomorrow I guess
2019-06-11 13:55:25 <mps> Cogitri: that is what I thought to do, but don't have any experience with void building tools
2019-06-11 13:57:17 <Cogitri> Ah, I still have a VPS running with Void and contributed to it for about a year I think, so that should be OK :P
2019-06-11 15:14:35 <ncopa> clang test suite fails on armhf and s390x
2019-06-11 15:15:00 <ncopa> tmhoang: can you please have a look at clang8 for s390x? https://build.alpinelinux.org/buildlogs/build-3-10-s390x/main/llvm8/llvm8-8.0.0-r0.log
2019-06-11 15:15:02 <_ikke_> llvm8 fails on s390x as well
2019-06-11 15:16:06 <ncopa> oh, its llvm8, not clang
2019-06-11 15:19:21 <Cogitri> Huh, it passed when I put it in testing, didn't it?
2019-06-11 15:19:46 <tmhoang> ncopa: yeah I saw this morning, busy day and this week too. I will try to work on it tonight
2019-06-11 15:19:53 <Cogitri> So maybe that's just a wonky test?
2019-06-11 15:20:42 <tmhoang> is that an x86 test ?
2019-06-11 15:20:48 <tmhoang>     LLVM :: ThinLTO/X86/cfi-devirt.ll
2019-06-11 15:22:41 <tmhoang> ppc64le + armv7 dont have that test
2019-06-11 15:22:57 <ncopa> i have no idea
2019-06-11 15:23:10 <tmhoang> should be simple fix
2019-06-11 15:23:15 <tmhoang> by a simple check
2019-06-11 15:23:17 <ncopa> the failing armhf test on clang was for sytemz too
2019-06-11 15:23:32 <ncopa> it could be cross compile problem
2019-06-11 15:23:40 <tmhoang> build log for armhf dont exist
2019-06-11 15:23:45 <tmhoang> https://build.alpinelinux.org/buildlogs/build-3-10-armhf/main/llvm8/llvm8-8.0.0-r0.log
2019-06-11 15:24:10 <ncopa> its clang's tests that fails for armhf https://build.alpinelinux.org/buildlogs/build-3-10-armhf/main/clang/clang-8.0.0-r0.log
2019-06-11 15:24:19 <Cogitri> <tmhoang "is that an x86 test ?"> Yes, because LLVM also targets other arches
2019-06-11 15:24:21 <tmhoang> Cogitri> Huh, it passed when I put it in testing, didn't it? : how do you mean ?
2019-06-11 15:24:36 <ncopa> Failing Tests (2):
2019-06-11 15:24:36 <ncopa>     Clang :: CodeGen/builtins-systemz-zvector2.c
2019-06-11 15:24:36 <ncopa>     Clang :: CodeGen/builtins-systemz-zvector.c
2019-06-11 15:25:01 <ncopa> you can use clang/llvm on a s390x machine to generate code to x86
2019-06-11 15:25:48 <Cogitri> tmhoang: I made llvm8 a new aport in testing/ where it passed on all arches, the current failure is from moving llvm8 from testing to main
2019-06-11 15:26:01 <Cogitri> So I'm irritated that suddenly one of the tests fails
2019-06-11 15:33:22 <tmhoang> okay I need to run, I will  work on it tonight
2019-06-11 15:33:27 <tmhoang> thanks
2019-06-11 15:34:26 <PureTryOut[m]> So Hunspell got updated, and now packages that have it in `$makedepends` can't be installed anymore (like qt5-qtvirtualkeyboard and sonnet) due to soname missing. Do stuff like that not automatically get a pkgrel bump to rebuild?
2019-06-11 15:34:47 <maxice8> I pkgrel bumped themr
2019-06-11 15:34:47 <maxice8> In the PR
2019-06-11 15:34:59 <PureTryOut[m]> Oh, they're still being rebuilt I see
2019-06-11 15:35:39 <maxice8> I even coerced Cogitri into lending me cpu time to build libreoffice
2019-06-11 15:35:54 <PureTryOut[m]> They're just still missing for the architecture I was targeting. Never mind then 😃
2019-06-11 15:37:27 <_ikke_> PureTryOut[m]: fyi, that can't be done automatically, because those changes need to be recorded in git
2019-06-11 15:37:49 <Cogitri> Heh
2019-06-11 15:38:11 <_ikke_> We could ofcourse have something that traces dependencies and bumps it in your local tree
2019-06-11 15:42:31 <PureTryOut[m]> Yeah that'd be nice
2019-06-11 17:09:57 <tcely> does anyone know of a link explaining the travis-ci irc bot?
2019-06-11 18:20:47 <PureTryOut[m]> Could anybody explain me why the CI in pr8717 can't find a just built package?
2019-06-11 18:21:33 <_ikke_> PureTryOut[m]: abuild doesn't look for upstream packages in REPODEST
2019-06-11 18:21:49 <_ikke_> or downstream, I forgot which one
2019-06-11 18:22:05 <_ikke_> downstream would make more sense
2019-06-11 18:22:28 <_ikke_> if you are building a package in main, abuild only looks for packages in $REPODEST/main
2019-06-11 18:22:46 <_ikke_> if you are building a package in community, it will look in $REPODEST/main and $REPODEST/community
2019-06-11 18:23:40 <_ikke_> ... but that's not what's causing the issue
2019-06-11 18:24:42 <_ikke_> PureTryOut[m]: Maybe I should just link to the PR: https://github.com/alpinelinux/abuild/pull/53/files
2019-06-11 18:26:37 <PureTryOut[m]> But building a package in testing it will not look in $REPODEST/community?
2019-06-11 18:27:53 <_ikke_> I think that's the case, yes
2019-06-11 18:28:10 <_ikke_> But that should break a lot more, so I'm a bit confused
2019-06-11 18:28:31 <_ikke_> ah, right, the missing piece
2019-06-11 18:28:46 <_ikke_> the builders have repodest added to /etc/apk/repositories
2019-06-11 18:28:47 <PureTryOut[m]> It doesn't make sense to me. Community not looking in testing I understand, but not the other way around
2019-06-11 18:28:58 <_ikke_> So there are 2 mechanisms
2019-06-11 18:29:06 <PureTryOut[m]> I mean, I can move all the KDE Frameworks packages to community as well, I know they work as we use them like that in postmarketOS
2019-06-11 18:29:19 <_ikke_> This is purely an issue with how our CI is setup
2019-06-11 18:29:42 <_ikke_> in our CI, /etc/apk/repositories only contains mirror repositories
2019-06-11 18:29:47 <_ikke_> (dl-cdn.a.o/*)
2019-06-11 18:30:29 <_ikke_> I think the simple fix would be to add the $REPODEST repo's to /etc/apk/repositories in our CI as well
2019-06-11 18:30:46 <PureTryOut[m]> Interesting
2019-06-11 18:31:17 <PureTryOut[m]> If the builders work like that, then that makes sense to me
2019-06-11 18:31:18 <_ikke_> The downside to that is that CI does not catch when you try to build something in main which depends on community
2019-06-11 18:31:38 <_ikke_> But I might still be missing some detail
2019-06-11 18:32:25 <PureTryOut[m]> So what can I do right now to get this PR merged?
2019-06-11 18:33:04 <_ikke_> If it's *just* a move, I would not worry about it too much
2019-06-11 18:33:34 <_ikke_> someone has to build it to verify it, but I would not expect lots of things breaking suddenly
2019-06-11 18:33:45 <_ikke_> though, apparently with llvm8 it did happen
2019-06-11 18:33:49 <jwh> hm
2019-06-11 18:33:50 <jwh> # content of this file will override /etc/sysctl.d/*
2019-06-11 18:34:00 <jwh> sort of...
2019-06-11 18:34:10 <PureTryOut[m]> Luckily this doesn't use LLVM8 lol
2019-06-11 18:34:25 <_ikke_> PureTryOut[m]: I've added the ci-malfunction label to the PR
2019-06-11 18:34:34 <PureTryOut[m]> Thanks
2019-06-11 18:43:29 <tcely> _ikke_: if you are building a package in community, it will look in $REPODEST/community and not in $REPODEST/main
2019-06-11 18:43:47 <tcely> also, not in $REPODEST/testing, but that is intended
2019-06-11 18:44:29 <_ikke_> right, I was confused how it was working on the builders, but there the $REPODEST directories are present in /etc/apk/repositories\
2019-06-11 18:45:56 <tcely> from what I understand, the builders just have all the local repos enabled all the time. on the other hand, CI resets the repositories file for the repo it is building.
2019-06-11 18:46:32 <_ikke_> only main and community are enabled
2019-06-11 18:46:35 <_ikke_> on the builders
2019-06-11 18:46:59 <_ikke_> so you could afaik build a package in main which depends on community
2019-06-11 18:47:14 <tcely> ahh. ok. so with those two and when building in testing, all three end up active
2019-06-11 18:47:51 <_ikke_> yes, correct
2019-06-11 18:48:01 <_ikke_> You have 2 mechanisms
2019-06-11 18:48:25 <_ikke_> The repositories available in /etc/apk/repositories, which are always available
2019-06-11 18:48:37 <_ikke_> and abuild adding the $REPODEST repo for the current repository
2019-06-11 18:49:01 <_ikke_> on the builders, it's always coming from $REPODEST, they don't rely on the mirrors
2019-06-11 18:49:39 <_ikke_> on CI, /etc/apk/repositories only contain mirrors
2019-06-11 18:49:42 <tcely> that explains why the builders don't have any mirror sync problems.
2019-06-11 18:50:07 <_ikke_> nope, they are the source of the packages anyway
2019-06-11 18:51:34 <_ikke_> so on CI, it has the current repo available from repodest, so any packages in the current repo that are just built, are available
2019-06-11 18:51:53 <_ikke_> but if they are in any other repo, they won't be available, only what's available on the mirrors
2019-06-11 20:45:29 <tcely> mps: are you on GH at alll?
2019-06-11 20:51:07 <mps> tcely: no
2019-06-11 20:52:03 <mps> but I look at PR's there and test them, and apply them if they pass 'my' tests
2019-06-11 20:52:13 <mps> how can I help?
2019-06-11 20:52:38 <tcely> I saw @mps in a PR and wondered is all
2019-06-11 20:53:51 <mps> maybe someone mention me in PR, I know for some such mentions and not only for alpine
2019-06-11 20:54:55 <tcely> pr8078 if you're curious
2019-06-11 20:56:38 <mps> ah, yes, maxice8 did this, but he was so kind to ask me if I agree before he applied it
2019-06-11 20:57:55 <mps> but I'm not this @mps in the PR, i.e. https://github.com/mps I'm someone else
2019-06-11 20:58:53 <maxice8> I didn't knew at the time that mps wasn't on GitHub
2019-06-11 20:59:14 <mps> maxice8: np :)
2019-06-11 21:00:30 <mps> I don't hide my identity, because this all my mails and git commits are with my full name and e-mail address
2019-06-11 21:30:58 <revolutionary> hi all. may i ask is there any working on progress about errors on build.alpinelinux.org? Thanks
2019-06-11 21:31:13 <_ikke_> revolutionary: anything specific?
2019-06-11 21:31:29 <revolutionary> build-edge-armv7
2019-06-11 21:31:32 <revolutionary> failed
2019-06-11 21:33:32 <_ikke_> Someone will probably fix that soon
2019-06-11 21:33:44 <revolutionary> Thank you so much _ikke_
2019-06-11 21:33:51 <_ikke_> (but I don't know if it will happen today)
2019-06-11 21:34:03 <_ikke_> it's quite late already
2019-06-11 21:34:20 <revolutionary> no worries
2019-06-11 21:37:15 <danieli> it's currently 11.37 pm in central europe
2019-06-11 21:37:23 <danieli> >>> py-bottle-hotqueue: Analyzing dependencies...
2019-06-11 21:37:23 <danieli> ERROR: unsatisfiable constraints:
2019-06-11 21:37:23 <danieli>   py-hotqueue (missing):
2019-06-11 21:37:23 <danieli>     required by: .makedepends-py-bottle-hotqueue-20190611.172740[py-hotqueue]
2019-06-11 21:37:33 <jwh> yes it is, past my bedtime :(
2019-06-11 21:38:29 <_ikke_> py-hotqueue is disabled on armv7, so this one should as well
2019-06-11 21:39:40 <mps> I will look if it builds on armv7
2019-06-11 21:40:12 <_ikke_> pushed
2019-06-11 21:40:14 <_ikke_> oh
2019-06-11 21:40:53 <mps> np
2019-06-11 21:41:00 <_ikke_> mps: it has been disabled yesterday
2019-06-11 21:41:09 <_ikke_> +arch="noarch !armv7" # urllib2.HTTPError: HTTP Error 403: SSL is required
2019-06-11 21:41:50 <mps> why only on armv7
2019-06-11 21:42:14 <_ikke_> no clue
2019-06-11 21:42:15 <mps> ok, will test it a few minutes, before bed
2019-06-11 21:42:25 <_ikke_> The commit is remarkably void of context
2019-06-11 21:42:45 <mps> s/it a/it in a/
2019-06-11 21:42:45 <alpine-meetbot> mps meant to say: ok, will test it in a few minutes, before bed
2019-06-11 21:46:34 <mps> here is the error http://tpaste.us/pWJg anyone with knowledge of python
2019-06-11 21:51:00 <danieli> mps: is python missing the ssl bindings?
2019-06-11 21:51:39 <SpaceToast> looks like missing setuptools to me
2019-06-11 21:51:55 <SpaceToast> note https://github.com/richardhenry/hotqueue/blob/master/setup.py - if missing, it'll try to use distribute_setup
2019-06-11 21:51:59 <mps> I don't know much about python
2019-06-11 21:52:01 <SpaceToast> which is https://github.com/richardhenry/hotqueue/blob/master/distribute_setup.py
2019-06-11 21:52:33 <SpaceToast> latest release is 2012, but there's an https patch in 2017
2019-06-11 21:52:48 <SpaceToast> mps: try apply this patch https://github.com/richardhenry/hotqueue/commit/ddeaef003477815b7bd99752fd3677bc4327224c.patch
2019-06-11 21:52:56 <SpaceToast> alternatively, make sure setuptools is in makedepends
2019-06-11 21:53:02 <_ikke_> Why is it only failing on armv7?
2019-06-11 21:53:12 <SpaceToast> perhaps setuptools is broken on armv7
2019-06-11 21:53:14 <SpaceToast> for whatever reason
2019-06-11 21:53:18 <_ikke_> ah, not only on armv7
2019-06-11 21:53:25 <_ikke_> broken for me as well
2019-06-11 21:53:34 <_ikke_> probably because upstream flipped a switch I guess
2019-06-11 21:53:56 <SpaceToast> :)
2019-06-11 21:53:56 <_ikke_> pypi now requires ssl
2019-06-11 21:54:03 <SpaceToast> just like the error says, eh?
2019-06-11 21:54:09 <_ikke_> yes, exactly
2019-06-11 21:54:28 <SpaceToast> anyway, make sure setuptools is in makedepends and/or use the patch \o/
2019-06-11 21:54:34 <_ikke_> But the comment in the APKBUILD didn't give any context
2019-06-11 21:54:42 <_ikke_> setuptools makes sense
2019-06-11 21:55:02 <_ikke_> But it's too late for me now, more tomorrow
2019-06-11 21:55:05 <SpaceToast> I'm not sure the person writing the comment had figured it out either
2019-06-11 21:55:08 <tmhoang> anyone knows what happened with llvm8 build on s390x ? Few hours ago it still failed.
2019-06-11 21:55:22 <SpaceToast> but notice this in particular: from distribute_setup import use_setuptools; use_setuptools() (in the error log)
2019-06-11 21:55:27 <mps> py-setuptools is in makedepends already
2019-06-11 21:55:28 <SpaceToast> this only happens when setuptools is missing to begin with
2019-06-11 21:56:01 <_ikke_> (3/4) Installing py-setuptools (40.8.0-r1)
2019-06-11 21:56:34 <SpaceToast> so it's either broken, or py-setuptools refers to the py3 variant (seeing as the error log is from py2)
2019-06-11 21:57:03 <_ikke_> nope, it's py2.7
2019-06-11 21:57:39 <SpaceToast> ok, so for whatever reason hotqueue is erroring out when trying to import `setuptools`
2019-06-11 21:57:49 <mps> SpaceToast: patch helped
2019-06-11 21:57:54 <SpaceToast> good :)
2019-06-11 21:58:09 <mps> but had to remove docs from it
2019-06-11 21:58:22 <SpaceToast> makes sense
2019-06-11 21:58:50 <SpaceToast> looks like there's no github release
2019-06-11 21:58:53 <SpaceToast> even though it's 0.2.8 on pypi
2019-06-11 21:59:00 <_ikke_> emscripten: ERROR:root:Emscripten, llvm and clang repo versions do not match, this is dangerous (1.37.9, 1.37.10, 1.37.10)
2019-06-11 21:59:24 <danieli> _ikke_: where is that from?
2019-06-11 21:59:36 <_ikke_> armv7 builder
2019-06-11 21:59:38 <SpaceToast> yup, looks like author forgot to tag it
2019-06-11 21:59:40 <_ikke_> https://build.alpinelinux.org/buildlogs/build-edge-armv7/testing/emscripten/emscripten-1.37.9-r3.log
2019-06-11 21:59:46 <SpaceToast> could use snapshot?
2019-06-11 22:00:21 <_ikke_> snapshot is anoying
2019-06-11 22:02:00 <SpaceToast> sure, but someone's been asking the author to tag the latest release since october of last year :/
2019-06-11 22:02:08 <SpaceToast> https://github.com/richardhenry/hotqueue/issues/26
2019-06-11 22:02:20 <SpaceToast> with the actual release being from november 2017
2019-06-11 22:02:36 <SpaceToast> so it seems unlikely anything will happen of that sort
2019-06-11 22:04:52 <tmhoang> _ikke_ : if you have a minute, would you mind helping me to disable testing/py3-piexif on s390x due to test failures. It probably relates to Pillow on s390x test failure which upstream has not created a solution for it yet. Also I'm quite busy this week, amybe I can have a closer look next week ...
2019-06-11 22:05:26 <_ikke_> SpaceToast: https://github.com/richardhenry/hotqueue/archive/0364d62840c575099bff25d50bfc4312a50c0cff.tar.gz
2019-06-11 22:05:43 <_ikke_> tmhoang: will disable it
2019-06-11 22:05:48 <tmhoang> thanks
2019-06-11 22:05:58 <mps> SpaceToast: would you mind to make patch, I can test it tomorrow and push
2019-06-11 22:06:15 <mps> ofc, if you have free time
2019-06-11 22:06:20 <SpaceToast> mps: I think _ikke_ has the proper solution
2019-06-11 22:06:33 <mps> ah, ok then. better :)
2019-06-11 22:06:43 <SpaceToast> kind of surprised you can make tarballs from any commit, gj github
2019-06-11 22:06:48 <_ikke_> (we still need to verify the correct commit hash)
2019-06-11 22:07:07 <_ikke_> it's basically just a web interface on top of git archive
2019-06-11 22:07:13 <SpaceToast> I think the latest is correct
2019-06-11 22:07:21 <mps> I think I'm going to bed. good night to all :)
2019-06-11 22:07:23 <SpaceToast> since the latest commit is nov 30 2017
2019-06-11 22:07:29 <SpaceToast> which is the exact date of the latest release
2019-06-11 22:09:17 <_ikke_> I'm heading to bed as well
2019-06-11 22:09:37 <_ikke_> night (good afternoon)
2019-06-11 22:09:38 <SpaceToast> good night :)
2019-06-12 08:05:31 <kr0k0> Good Morning!
2019-06-12 08:06:08 <kr0k0> A bit late I know ^^
2019-06-12 08:33:13 <ncopa> hi
2019-06-12 08:33:25 <_ikke_> ncopa: morning
2019-06-12 08:33:33 <ncopa> i have tested alpine-virt 3.10 rc3 on virtualbox with EFI
2019-06-12 08:33:35 <ncopa> works
2019-06-12 08:33:46 <ncopa> did sys install
2019-06-12 08:35:33 <Cogitri> Morning
2019-06-12 08:40:06 <_ikke_> ncopa: ok nice
2019-06-12 09:34:47 <mps> kr0k0: it is never late to say 'good morning' ;)
2019-06-12 09:36:04 <mps> rc3 looks a lot better on three arm SBC's
2019-06-12 09:37:17 <mps> do we have list of things which need to be fixed for release
2019-06-12 09:39:44 <clandmeter> check bugs
2019-06-12 09:40:53 <mps> clandmeter: I did but nothing is release critical, imo. or i didn't found release critical bug there
2019-06-12 10:10:48 <ncopa> im updating kernel
2019-06-12 10:11:01 <ncopa> and will do new release candidate after that
2019-06-12 10:11:11 <ncopa> we need test that diskless installs etc works
2019-06-12 10:11:31 <ncopa> have anyone tested ppc64le or s390x?
2019-06-12 10:11:38 <ncopa> does arm work?
2019-06-12 10:11:47 <ncopa> what about aarch64 and uefi?
2019-06-12 10:12:32 <ncopa> does it work to install on nmve?
2019-06-12 10:13:17 <ncopa> mps: is this solved? https://bugs.alpinelinux.org/issues/10155
2019-06-12 10:14:21 <mps> ncopa: I tested armv7 boot on three boards. It boots to root prompt. I didn't tried install to the end but setup-scripts works
2019-06-12 10:14:59 <mps> ncopa: I don't have RPi, so can't test this bug
2019-06-12 10:15:02 <ncopa> ok
2019-06-12 10:15:31 <ncopa> i think it would be nice to have a place where we could doc what is tested
2019-06-12 10:15:37 <ncopa> a wiki like thing
2019-06-12 10:15:50 <ncopa> so we could hook off what is tested
2019-06-12 10:15:55 <mps> maybe we can ask on #alpine-linux if someone with this boards can test
2019-06-12 10:16:08 <ncopa> i have an rpi3
2019-06-12 10:16:19 <ncopa> but this is something we could ask help for
2019-06-12 10:16:24 <ncopa> good idea
2019-06-12 10:19:48 <mps> another note, few days ago we talked here about moving hexchat and weechat from main to community
2019-06-12 10:20:55 <_ikke_> danieli said he has all kinds of rpi's
2019-06-12 10:22:49 <ncopa> mps: i think that makes sense
2019-06-12 10:23:41 <ncopa> what does rnalrd say about movin weechat?
2019-06-12 10:24:07 <mps> yes, then they will not need backports to LTS stable in case of security issues
2019-06-12 10:24:47 <mps> iirc, he was not active in discussion
2019-06-12 10:25:40 <mps> and, maybe even irssi could be moved from main
2019-06-12 10:32:43 <rnalrd> ncopa, fine with me
2019-06-12 10:34:59 <revolutionary> Greetings!
2019-06-12 10:36:23 <ncopa> rnalrd: thanks!
2019-06-12 10:36:35 <ncopa> hi revolutionary
2019-06-12 10:37:13 <_ikke_> emscripten has test failures on all arches
2019-06-12 10:38:08 <_ikke_> doesn't really look maintained
2019-06-12 10:39:11 <revolutionary> how is it going? how is your day?
2019-06-12 10:46:20 <ncopa> revolutionary: good thanks. trying to get 3.10 out
2019-06-12 10:47:07 <revolutionary> ncopa: it's good to hear that.
2019-06-12 11:07:10 <mps> these perl-dbix-* modules are not in good shape
2019-06-12 11:08:25 <mps> superficially looking them it seems they are missing build deps, mostly
2019-06-12 11:39:03 <mps> testing/sdfat failed because _kver=4.19.49 should be bumped to 4.19.50
2019-06-12 11:40:21 <mps> how to handle this with every kernel upgrade, by hand or we have something semi/full automatic for such cases
2019-06-12 11:50:24 <ncopa> i have a script
2019-06-12 11:50:43 <ncopa> but it will only look for */*-$flavor
2019-06-12 11:50:55 <ncopa> so it woudl have found testing/sdfat-vanilla
2019-06-12 11:51:21 <mps> oh, prspkt just upgraded it. But script will be useful for such cases
2019-06-12 11:51:22 <ncopa> now i need to make it search through all packages
2019-06-12 11:51:54 <ncopa> yeah, i have fixed my script
2019-06-12 11:52:25 <mps> nice, we see it at work on next kernel upgrade
2019-06-12 11:52:29 <ncopa> we should do the version group thing
2019-06-12 11:52:46 <mps> s/we /we will/
2019-06-12 11:52:46 <alpine-meetbot> mps meant to say: nice, we willsee it at work on next kernel upgrade
2019-06-12 11:52:57 <ncopa> im rebuilding rust with llvm8 now
2019-06-12 11:53:34 <ncopa> then we could in theory get rid of llvm7
2019-06-12 11:53:51 <ncopa> or is it other things that uses llvm7?
2019-06-12 11:54:17 <ncopa> testing/bcc/APKBUILD:makedepends="tar git llvm7-dev llvm7-static clang-dev clang-static cmake flex-dev
2019-06-12 11:54:18 <ncopa> testing/bpftrace/APKBUILD:makedepends="cmake llvm7-dev llvm7-static clang-dev clang-static
2019-06-12 11:54:53 <mps> i see bcc and bpftrace have explicit llvm7 in makedepends
2019-06-12 11:55:06 <mps> ohm, you are faster
2019-06-12 11:55:18 <clandmeter> [[sroracle]]: around?
2019-06-12 11:55:58 <TBB> mps: benefits of paste vs writing a sentence
2019-06-12 11:56:08 <ncopa> :)
2019-06-12 11:56:46 <mps> lets see if bcc builds with llvm8
2019-06-12 11:56:52 <tmhoang> I can test s390x rc3 images later today
2019-06-12 11:57:00 <ncopa> tmhoang: that would be great
2019-06-12 11:57:00 <tmhoang> possibly ppc64le (on emulation)
2019-06-12 11:57:07 <tmhoang> sorry so busy this week .
2019-06-12 11:57:13 <ncopa> or rc4 if we get it out today
2019-06-12 11:57:18 <tmhoang> o/
2019-06-12 11:57:27 <ncopa> tmhoang: no worries
2019-06-12 11:57:40 <_ikke_> /o
2019-06-12 11:57:42 <_ikke_> \o
2019-06-12 11:58:05 <clandmeter>  /o\
2019-06-12 11:58:36 <ncopa> mps: bcc builds
2019-06-12 11:58:47 <ncopa> im testing bpftrace now
2019-06-12 11:59:14 <mps> also here, on aarch64
2019-06-12 11:59:47 <mps> bpftrace is x86_64 only.
2019-06-12 12:01:03 <mps> I think we can use llvm8 for bcc
2019-06-12 12:03:14 <ncopa> bpftrace failed
2019-06-12 12:05:19 <ncopa> ok, i guess we cannot get rid of llvm7
2019-06-12 12:05:23 <mps> it is only for x86_64
2019-06-12 12:08:13 <mps> maybe it could be built with llvm6
2019-06-12 12:18:06 <ncopa> nah, but we could move llvm7 to community and upgrade it to 7.1
2019-06-12 12:23:52 <mps> maybe I'm blind because I can't see 7.1 anywhere
2019-06-12 12:31:25 <ncopa> https://github.com/alpinelinux/aports/pull/8699
2019-06-12 12:34:11 <mps> ah, I see, looks like they put it on download page without announce
2019-06-12 12:36:10 <mps> moving to community (or testing, nothing in community depend on it?) and upgrade makes sense
2019-06-12 12:36:41 <mps> btw, you skipped rc4. by intention?
2019-06-12 12:37:18 <mps> no, I'm really blind, sorry, rc5 is for old 3.4
2019-06-12 12:52:10 <ncopa> anyone here uses virt-manager? i wonder if someone could help me add alpine 3.9 and 3.10 to osinfo-db
2019-06-12 12:53:03 <ncopa> I have 2 patches but I could not get them to work http://tpaste.us/W1VL
2019-06-12 12:53:17 <PureTryOut[m]> I do, but I have no clue how to do that sorry
2019-06-12 12:54:06 <ncopa> ok, im gonna push it anyway
2019-06-12 12:54:12 <ncopa> lets see what happens
2019-06-12 13:21:27 <mps> ncopa: tried llvm 7.1.0 on armv7, failed on 6 tests, http://tpaste.us/gM7r
2019-06-12 13:22:27 <mps> maybe we keep check disabled on arm*
2019-06-12 13:56:06 <PureTryOut[m]> cogitri: what was the reason for having gnome-session and gnome-shell blocked on arm* again?
2019-06-12 13:57:21 <maxice8> Probably libgweather missing
2019-06-12 13:58:36 <Cogitri> Yup, I'll bring it back in a bit
2019-06-12 13:58:43 <Cogitri> The armv7 builder went a bit mayhem
2019-06-12 13:59:13 <Cogitri> Didn't bother working on armhf for it since I figured that hardware is too slow to run it anyway
2019-06-12 13:59:58 <PureTryOut[m]> yeah don't care much about armhf personally either. Just armv7 and aarch64
2019-06-12 14:01:46 <Cogitri> Yup
2019-06-12 14:09:50 <prspkt> we will need to revert https://git.alpinelinux.org/aports/commit/?id=1b6e71f7878112a0061e9c8d409fb0d9d3c65412
2019-06-12 14:10:49 <prspkt> it introduces dependencies which have not packaged.
2019-06-12 14:16:09 <mksully22> ncopa: I've done a ppc64le netboot install of 3.10rc3 on my power8 box
2019-06-12 14:34:18 <ncopa> mksully22: great!
2019-06-12 14:34:25 <ncopa> mksully22: any issues?
2019-06-12 14:35:10 <ncopa> prspkt: what dependency?
2019-06-12 14:35:14 <ncopa> im reverting it now
2019-06-12 14:37:32 <ncopa> prspkt: do you know exactly which dependency it is? so i can mention it in commit message
2019-06-12 14:38:31 <prspkt> ncopa: importlib-metadata, pluggy>=12, zipp
2019-06-12 14:38:37 <prspkt> https://github.com/pytest-dev/pytest/blob/master/setup.py
2019-06-12 14:41:00 <ncopa> why was that not catched by check() ?
2019-06-12 14:41:01 <mksully22> ncopa: I ran into no issues
2019-06-12 14:46:18 <_ikke_> ncopa: because the way setuptools works
2019-06-12 14:46:26 <prspkt> i found out because of this: https://travis-ci.org/alpinelinux/aports/builds/544733055#L636
2019-06-12 14:47:11 <prspkt> py-pyphen tested fine on CI this morning (before the pytest 4.6.3 merge)
2019-06-12 16:06:54 <[[sroracle]]> clandmeter?
2019-06-12 16:08:01 <JjOtt> I'm doing some stuff that I think would be good to put into the Wiki - is there anyone I should be checking with first?
2019-06-12 16:22:37 <ncopa> i wonder ho the CI could give green light on this https://github.com/alpinelinux/aports/pull/7899
2019-06-12 16:22:53 <ncopa> shell cannot even parse the APKBUILD
2019-06-12 16:22:53 <_ikke_> Is it failing on the builders?
2019-06-12 16:23:04 <_ikke_> ..
2019-06-12 16:23:05 <ncopa> it breaks the builders
2019-06-12 16:23:09 <ncopa> there is a missing "
2019-06-12 16:23:15 <ncopa> so its invalid shell
2019-06-12 16:23:40 <_ikke_> >>> No packages found to be built.
2019-06-12 16:23:47 <_ikke_> I guess that's the issue
2019-06-12 16:24:10 <ncopa> it should fail with error if it fails to parse the APKBUILDs
2019-06-12 16:25:21 <danieli> i'm not sure why pr8629 fails for some people but not other - i think i'll have to submit it upstream?
2019-06-12 16:40:03 <PureTryOut[m]> I was wondering why it didn't find any packages to be built...
2019-06-12 16:41:04 <PureTryOut[m]> Fixed it, let's see CI do it properly now
2019-06-12 16:41:17 <PureTryOut[m]> Can the PR be reopened?
2019-06-12 16:41:44 <_ikke_> 7899>
2019-06-12 16:41:51 <_ikke_> s/>/?
2019-06-12 16:41:51 <alpine-meetbot> _ikke_ meant to say: 7899?
2019-06-12 16:42:50 <_ikke_> It can't be reopened because the branch is gone
2019-06-12 16:42:50 <PureTryOut[m]> Yes
2019-06-12 16:43:06 <PureTryOut[m]> Huh? Not at all true
2019-06-12 16:43:25 <PureTryOut[m]> I literally just force pushed it
2019-06-12 16:43:33 <_ikke_> Hmm, ok, then for some other reason I cannot reopen it
2019-06-12 16:43:39 <PureTryOut[m]> https://github.com/PureTryOut/aports/tree/u-boot-pine64
2019-06-12 16:43:46 <PureTryOut[m]> I guess I'll open a new PR then
2019-06-12 16:44:01 <_ikke_> It says: "The branch was force pushed or recreated"
2019-06-12 16:44:24 <PureTryOut[m]> Well that is true
2019-06-12 16:45:14 <PureTryOut[m]> Made a new PR, #8757
2019-06-12 16:50:23 <PureTryOut[m]> Drone prints out "error: could not build fake ancestor", what does that mean?
2019-06-12 16:51:01 <_ikke_> pr8757
2019-06-12 16:53:39 <mps> PureTryOut[m]: your changes to u-boot are pushed and went ok
2019-06-12 16:56:16 <PureTryOut[m]> Uhm, no? They were pushed, but were broken and reverted. Just made a new PR which fixes the brokeness of earlier
2019-06-12 16:56:55 <PureTryOut[m]> Well I guess arm-trusted-firmware did get moved
2019-06-12 16:57:40 <mps> ATF is moved to main
2019-06-12 17:05:13 <PureTryOut[m]> PR went through good now for all architectures
2019-06-12 17:07:42 <mps> all or only arm
2019-06-12 17:07:51 <mps> arm ones
2019-06-12 17:08:55 <PureTryOut[m]> The package is only for arm
2019-06-12 17:09:20 <PureTryOut[m]> But yeah all arm's succeedded
2019-06-12 17:13:26 <ncopa> its merged
2019-06-12 17:13:33 <ncopa> im gonna tag rc5 now
2019-06-12 17:13:46 <ncopa> rc4
2019-06-12 17:13:54 <danieli> ncopa: think I should submit that Elixir issue upstream?
2019-06-12 17:14:04 <danieli> it just seems like a flaky test to me
2019-06-12 17:14:26 <PureTryOut[m]> thanks!
2019-06-12 17:14:49 <ncopa> danieli: yes, i think you should
2019-06-12 17:16:10 <mps> anyone have time to look at https://bugs.alpinelinux.org/issues/10543
2019-06-12 17:16:13 <ncopa> PureTryOut[m]: can you try if 3.10.0_rc4 works on that new uboot thing?
2019-06-12 17:17:21 <ncopa> mps: do you do that from an armv7 machine or from x86*?
2019-06-12 17:17:23 <p4Wv1qn095FW> PureTryOut[m]: how can use atf and this u-boot-pine64 thing together? do i need to do anything besides using alpine-arm64 image? i'm quite interested in this, as i have a never used pine64 and atf also sounds coool to play with.
2019-06-12 17:17:30 <mps> armv7
2019-06-12 17:17:39 <PureTryOut[m]> Hmm, I guess, not sure how. I know how to test the package on postmarketOS though, if that counts? We use Alpine's repos
2019-06-12 17:18:03 <mps> PureTryOut[m]: I think I have APKBUILD for this
2019-06-12 17:18:20 <PureTryOut[m]> p4Wv1qn095FW: atf is only needed at compile time for u-boot-pine64. Just use the u-boot image like any other
2019-06-12 17:19:20 <PureTryOut[m]> Can I build a 3.10.0_rc4 image with u-boot-pine64 which I can just write to an sdcard or eMMC?
2019-06-12 17:20:21 <mps> ncopa: on what arch you run mkimage.sh when building uboot tar.gz profiles
2019-06-12 17:22:15 <mps> I tried also from x86_64 but it told me 'ERROR: http://dl-cdn.alpinelinux.org/alpine/edge/main: UNTRUSTED signature'
2019-06-12 17:22:41 <p4Wv1qn095FW> PureTryOut[m]: thx! will have a go at it.
2019-06-12 17:22:43 <mps> PureTryOut[m]: yes, if mkimage.sh works
2019-06-12 17:23:56 <PureTryOut[m]> Ah, https://wiki.alpinelinux.org/wiki/How_to_make_a_custom_ISO_image_with_mkimage
2019-06-12 17:23:56 <PureTryOut[m]> Thanks
2019-06-12 17:24:32 <mps> yes, but it doesn't work for me :(
2019-06-12 17:29:46 <mps> if you manage to build img please tell me how you achieved it
2019-06-12 17:36:46 <ncopa> i just tagged rc4
2019-06-12 17:37:21 <ncopa> so you should be able to download it from http://dl-cdn.alpinelinux.org/alpine/v3.10/releases/aarch64/ in few minutes
2019-06-12 17:38:00 <ncopa> they are here now http://dl-master.alpinelinux.org/alpine/v3.10/releases/aarch64/
2019-06-12 17:38:33 <mps> and you build also armv7 uboot tar.gz
2019-06-12 17:38:45 <ncopa> are there anything we need to fix before 3.10.0 now?
2019-06-12 17:38:58 <ncopa> we should probably try write the release notes tomorrow
2019-06-12 17:39:26 <mps> I'm working on llvm7.1
2019-06-12 17:39:51 <ncopa> i think the -libs package split is broken too
2019-06-12 17:40:06 <mps> yes, this is where I reached
2019-06-12 17:40:08 <ncopa> hum
2019-06-12 17:40:12 <ncopa> new version of go
2019-06-12 17:40:16 <ncopa> 1.12.6
2019-06-12 17:44:15 <PureTryOut[m]> ncopa: `alpine-uboot-3.10.0_rc4-aarch64.tar.gz` doesn't seem to include the Pine64 image
2019-06-12 17:46:50 <PureTryOut[m]> 
ACTION uploaded an image: Screenshot_20190612_194631.png (88KB) < https://matrix.org/_matrix/media/v1/download/fam-ribbers.com/TvTkwWrMxISxWdxucRBPdOXu >

2019-06-12 17:46:51 <PureTryOut[m]> *the Pine64 u-boot
2019-06-12 18:03:42 <PureTryOut[m]> mps: I have the same untrusted signature error when trying to build an u-boot image
2019-06-12 18:05:12 <mps> do you try from aarch64 or other arch machine
2019-06-12 18:07:02 <PureTryOut[m]> x86_64
2019-06-12 18:07:09 <PureTryOut[m]> I don't actually have an aarch64 machine except for a Pinephone devkit
2019-06-12 18:07:57 <mps> I have a guide and script to install aarch64 under qemu, if you are interested I can post it
2019-06-12 18:08:09 <PureTryOut[m]> I guess I can do it in a aarch64 pmOS vm...
2019-06-12 18:08:17 <PureTryOut[m]> The latest _rc4 image should include it though
2019-06-12 18:08:37 <mps> no, it doesn't have it, just looked
2019-06-12 18:08:40 <PureTryOut[m]> mps: I'm not personally, but it's always good to put that stuff on the wiki
2019-06-12 18:09:11 <PureTryOut[m]> I know, but it should 😛
2019-06-12 18:09:28 <mps> if I know wiki syntax I will ;)
2019-06-12 18:13:32 <PureTryOut[m]> ncopa: the aarch64 u-boot image doesn't include the Pine64 u-boot for some reason
2019-06-12 18:22:10 <mps> ncopa: here is patch to upgrade llvm7 to 7.1.0 http://tpaste.us/wjR5
2019-06-12 18:22:28 <mps> it pass 'abuild -r' on armv7
2019-06-12 18:23:11 <mps> it is hack, to be fair but worked
2019-06-12 18:59:04 <maxice8> abuild is failing to upgrade on docker-abuild
2019-06-12 19:27:28 <_ikke_> I try to build something against llvm6, but it's looking for a binary called llvm-config, which is named llvm6-config for llvm6, any idea how to fix that?
2019-06-12 19:30:03 <p4Wv1qn095FW> if it is cmake based, you can do something like `cmake -DLLVM_CONFIG=/usr/bin/llvm6-config ..`
2019-06-12 19:30:19 <maxice8> Isn't there an env var that can be used to override the name/path to the binary
2019-06-12 19:30:19 <maxice8> when dealing with wxgtk there is WX_CONFIG=
2019-06-12 19:30:45 <_ikke_> p4Wv1qn095FW: it is indeed
2019-06-12 19:31:48 <p4Wv1qn095FW> might indeed also work as an env var i remember that vaguely
2019-06-12 19:32:31 <maxice8> if using cmake it is better to use your tip, my tip mostly applies to autoconf
2019-06-12 19:33:35 <_ikke_> fg
2019-06-12 19:33:51 <maxice8> no u
2019-06-12 19:33:59 <_ikke_> Hmm, oh, apkbuild seems to just use autoconf
2019-06-12 19:36:53 <_ikke_> export LLVM_CONFIG=path worked
2019-06-12 19:37:07 <p4Wv1qn095FW> \o/
2019-06-12 19:37:22 <_ikke_> trying to fix creduce, which needs llvm6
2019-06-12 19:37:58 <maxice8> \o/
2019-06-12 19:38:04 <p4Wv1qn095FW> \o/
2019-06-12 19:38:47 <_ikke_> Now a linker error remains :(
2019-06-12 19:39:13 <_ikke_> undefined reference to `llvm::WritableMemoryBuffer::getNewMemBuffer(unsigned long, llvm::Twine const&)'
2019-06-12 21:00:57 <tmhoang> clandmeter : what do you think if I suggest creating a boot image beside netboot that have essential .apk installed inside the initramfs ?
2019-06-12 21:01:42 <tmhoang> looks like netboot but instead of fetching .apk from remote via network (using network config in kernel parm), it got all the .apk pre-installed inside initramfs ?
2019-06-12 21:01:57 <tmhoang> the initramfs size should be a little bit larger
2019-06-12 21:03:10 <clandmeter> so no more switch_root?
2019-06-12 21:04:48 <[[sroracle]]> [07:55] <@clandmeter> [[sroracle]]: around?
2019-06-12 21:04:49 <[[sroracle]]> ?
2019-06-12 21:05:01 <clandmeter> hi
2019-06-12 21:05:22 <clandmeter> [[sroracle]]: you guys use gitlab right?
2019-06-12 21:05:51 <[[sroracle]]> clandmeter: yeah, we're in the middle of trying to upgrade from 8.0 to latest. real hassle since you have to upgrade through all the minor versions between
2019-06-12 21:06:09 <clandmeter> 8? :)
2019-06-12 21:06:20 <[[sroracle]]> haha yup. ancient stuff
2019-06-12 21:06:31 <clandmeter> my question is, do you have path based permissions?
2019-06-12 21:06:45 <clandmeter> like we have differrence between main and community/testing
2019-06-12 21:06:51 <[[sroracle]]> path-based? like in the git repos?
2019-06-12 21:06:55 <clandmeter> yes
2019-06-12 21:06:59 <[[sroracle]]> ah. not right now no
2019-06-12 21:07:09 <clandmeter> ok so git access is full access
2019-06-12 21:07:09 <[[sroracle]]> something that we would probably want in the future though
2019-06-12 21:07:12 <[[sroracle]]> yeah
2019-06-12 21:07:23 <tmhoang> clandmeter: $sysroot should contain all installed contents from .apk. Or, we can make a local repo inside initramfs :) Now it sounds like iso image :)
2019-06-12 21:07:41 <clandmeter> do you know if there is such feature?
2019-06-12 21:07:42 <tmhoang> which the other day, ncopa mentioned about creating an alternative image instead of iso
2019-06-12 21:09:08 <clandmeter> tmhoang: im not really following
2019-06-12 21:09:34 <[[sroracle]]> clandmeter: it doesn't seem like gitlab itself supports this, but you can probably write a pre-receive hook for it
2019-06-12 21:09:48 <danieli> clandmeter: impossible to my knowledge
2019-06-12 21:09:48 <clandmeter> right
2019-06-12 21:09:58 <[[sroracle]]> gitlab itself only seems to support branch / git repo permission granularity
2019-06-12 21:10:00 <clandmeter> but then how to define acl
2019-06-12 21:10:19 <clandmeter> its not something you can manage inside gitlab
2019-06-12 21:11:10 <danieli> the best idea would probably be to split main, community, and testing into separate repos
2019-06-12 21:11:12 <clandmeter> danieli: nothing is impossible ;-)
2019-06-12 21:11:22 <danieli> s/impossible/not feasible/
2019-06-12 21:11:22 <alpine-meetbot> danieli meant to say: clandmeter: not feasible to my knowledge
2019-06-12 21:11:23 <clandmeter> just takes more time
2019-06-12 21:11:41 <clandmeter> but yes, im not really looking into hacking ruby
2019-06-12 21:11:58 <clandmeter> but on the other hand, it could be an option for later.
2019-06-12 21:12:24 <clandmeter> yes we could split them
2019-06-12 21:12:46 <clandmeter> but it will also create a lot of troubles.
2019-06-12 21:13:13 <[[sroracle]]> https://git-scm.com/book/pl/v2/Customizing-Git-An-Example-Git-Enforced-Policy#_enforcing_a_user_based_acl_system
2019-06-12 21:13:32 <tcely> I'm dreading a boost like situation for aports
2019-06-12 21:13:37 <[[sroracle]]> really hacky would be to follow that example and have the acl file not reside in the bare git repo, but in some other git repo.
2019-06-12 21:15:21 <clandmeter> i guess we could technically create some plugin to do it.
2019-06-12 21:16:27 <clandmeter> but i have not looked into gitlabs plugin system
2019-06-12 21:23:37 <revolutionary> greetings!
2019-06-12 21:24:20 <clandmeter> hello
2019-06-12 21:24:28 <Cogitri> Hello there
2019-06-12 21:24:36 <revolutionary> how is your life?
2019-06-12 21:26:12 <clandmeter> fine, but not sure this is place to discus social.
2019-06-12 21:27:30 <revolutionary> we are not in parliament man, just asked, that's all.
2019-06-12 21:28:35 <revolutionary> anyway, have a good day!
2019-06-12 21:28:45 <danieli> that was.. something?
2019-06-12 21:28:57 <clandmeter> a revolution
2019-06-12 21:29:05 <danieli> lol :)
2019-06-12 21:29:32 <clandmeter> i didnt want to sound like a dick, but it just felt a bit weird.
2019-06-12 21:29:42 <danieli> nah, no worries
2019-06-12 21:35:05 <Cogitri> PureTryOut: I think the link for the offtopic channel on the pmOS wiki is wrong, redirects me to a dead channel
2019-06-12 21:35:58 <PureTryOut[m]> Well, not wrong, just outdated
2019-06-12 21:35:59 <PureTryOut[m]> Room upgrade didn't move over the aliasses
2019-06-12 21:36:00 <PureTryOut[m]> Waiting for ollieparanoid to switch it
2019-06-12 21:36:07 <PureTryOut[m]> Use the one in the screenshot I just send
2019-06-12 21:37:22 <Cogitri> Okie
2019-06-13 01:09:23 <danieli> someone were working on proj/proj4/whatever the other day, can that person verify that postgis was rebuilt against it?
2019-06-13 01:09:39 <danieli> 03:03:22 <oninoshio> Anyone know how to resolve so:libproj.so.13 as an unresolvable constraint of the postgis in edge? searching the packages I only seem to find libproj.so.15
2019-06-13 02:16:11 <revolutionary> Hi All! If possible could someone compile obfs4proxy for edge armv7?
2019-06-13 02:16:36 <revolutionary> I checked from the website and i guess Katie Holly is working on it.
2019-06-13 02:26:02 <danieli> which website?
2019-06-13 02:29:22 <revolutionary> danieli https://pkgs.alpinelinux.org/packages?name=obfs*&branch=edge
2019-06-13 02:29:38 <danieli> there haven't been any commits to it for a few months
2019-06-13 02:29:55 <revolutionary> i see
2019-06-13 02:30:18 <revolutionary> can someone compile that for edge armv7 if it is not hard
2019-06-13 02:30:45 <danieli> my guess is that it broke for architectures other than x86/x86_64 and the maintainer didn't care to waste the effort on compiling it for an arch they don't use
2019-06-13 02:31:03 <danieli> you're free to commit changes to it
2019-06-13 02:31:22 <revolutionary> i am not contributor, maintainer or dev
2019-06-13 02:31:30 <revolutionary> i just wanted to ask
2019-06-13 02:31:37 <danieli> all right
2019-06-13 08:54:46 <ncopa> revolutionary: i enabled it for armv7
2019-06-13 09:22:54 <revolutionary> ncopa: thank you so much! i will be waiting packages for armv7 because i am seeing armv7 packages are failing too often :|
2019-06-13 09:43:03 <ncopa> im trying to clean up armv7
2019-06-13 10:24:21 <_ikke_> kimchi is also still failing
2019-06-13 10:30:21 <_ikke_> So release notes
2019-06-13 10:32:04 <_ikke_> Obviously python3.7
2019-06-13 10:32:35 <_ikke_> Perl 5.28
2019-06-13 10:33:46 <_ikke_> gcc 8.3.0
2019-06-13 10:33:48 <_ikke_> llvm 8
2019-06-13 10:35:05 <_ikke_> Linux 4.19.50
2019-06-13 10:35:15 <PureTryOut[m]> In theory Pine64 support. u-boot support is in, but for some reason the _rc4 aarch64 image doesn't include it yet
2019-06-13 10:35:27 <PureTryOut[m]> *Pine64-LTS
2019-06-13 10:39:08 <_ikke_> PureTryOut[m]: What does that image not include yet?
2019-06-13 10:40:53 <Cogitri> Ikke is new Rust also noteworthy, or do we also update that in stable releases?
2019-06-13 10:41:26 <_ikke_> We can mention it
2019-06-13 10:42:05 <PureTryOut[m]> _ikke_: the u-boot for Pine64-LTS, although the aport for it got merged just before
2019-06-13 10:42:33 <_ikke_> maybe a race condition
2019-06-13 10:42:38 <_ikke_> that it wasn't built yet
2019-06-13 10:44:02 <PureTryOut[m]> I guess. I'd like to test it but can't really now lol
2019-06-13 10:44:28 <Cogitri> But maybe we can get Rust 1.35 with LLVM8 merged for 3.10? :)
2019-06-13 10:46:43 <_ikke_> Any other significant updates or new features?
2019-06-13 10:52:08 <_ikke_> Should mariadb be updated? it's now 10.3.x, 10.4.x is out
2019-06-13 10:56:37 <_ikke_> ncopa: I pushed branch release/3.10 to alpine-mksite
2019-06-13 11:00:00 <danieli> I'd love Erlang/OTP 22.0.x in 3.10, but if the CI malfunction(?) is blocking that, I'm going to see if I can get it fixed fairly quickly.
2019-06-13 11:00:46 <_ikke_> If it's just a CI malfunction, it should not be blocking
2019-06-13 11:01:47 <danieli> It failed for ncopa too iirc
2019-06-13 11:02:09 <danieli> And all the Drone builds failed - but it succeeds for most (some?) devs and for Travis
2019-06-13 11:57:49 <danieli> _ikke_: it was an upstream bug and it was instantly fixed by the creator :)
2019-06-13 12:02:15 <_ikke_> Nice!!
2019-06-13 12:03:33 <danieli> unfortunately it won't land in a release until the (soon!) upcoming 1.9.0 release, currently at rc0
2019-06-13 12:08:44 <mps> _ikke_: I think iwd should be in release notes
2019-06-13 12:09:28 <mps> not because i'm maintainer but it deserves to be noted
2019-06-13 12:10:21 <mps> maybe mention some new arm boards better support
2019-06-13 12:11:53 <mps> and, gnome and kde, obviously
2019-06-13 12:12:37 <mps> llvm8 and batteries
2019-06-13 12:17:51 <PureTryOut[m]> KDE isn't in 3.10.0, as it's only in edge currently
2019-06-13 12:18:47 <PureTryOut[m]> I'm waiting for Qt 5.12.4 which should fix a bug in plasma-workspace, then I'll PR Plasma 5.16.0
2019-06-13 12:19:08 <PureTryOut[m]> Once that's in and I've tested it to work, I'll move KDE Frameworks first to community, and then Plasma
2019-06-13 12:19:22 <PureTryOut[m]> So hopefully Plasma will be in Alpine 3.11
2019-06-13 12:19:40 <danieli> I'm looking forward to 3.14.. hehehehe
2019-06-13 12:19:43 <PureTryOut[m]> s/bug/crash
2019-06-13 12:19:43 <alpine-meetbot> PureTryOut[m] meant to say: I'm waiting for Qt 5.12.4 which should fix a crash in plasma-workspace, then I'll PR Plasma 5.16.0
2019-06-13 12:19:51 <danieli> wait no, that gives me flashbacks to gnome 3.14
2019-06-13 12:22:17 <PureTryOut[m]> When an upstream library is called "<something>-dev", what should it's package name in Alpine be? The same or something like "<something>-headers"?
2019-06-13 12:29:16 <_ikke_> tricky
2019-06-13 12:29:38 <_ikke_> The same issue we have with <pkgname>-static (binary) and <pkgname>-static (libraries)
2019-06-13 12:33:57 <ncopa> danieli: do you have a patch for it?
2019-06-13 12:34:42 <danieli> ncopa: this was done in master, not sure it'll apply cleanly to that chunk of code https://github.com/elixir-lang/elixir/commit/2548965a1ee3cb92a10fbd77fb0e951e455f3249.patch
2019-06-13 12:36:15 <ncopa> _ikke_: very nice
2019-06-13 13:37:27 <tmhoang> ncopa: do you want to make s390x bootable on LPAR in 3.10 :D
2019-06-13 13:37:44 <tmhoang> fancy question for fancy feature :D
2019-06-13 13:40:01 <tmhoang> don't know if anybody actually uses that feature but it would be super cool
2019-06-13 13:44:09 <otlabs> hi ppl
2019-06-13 13:45:54 <Cogitri> Hello, otlabs
2019-06-13 13:46:15 <otlabs> Cogitri: greetings!
2019-06-13 13:46:16 <danieli> hiya otlabs
2019-06-13 13:46:22 <danieli> nice to see you around again
2019-06-13 13:46:26 <otlabs> danieli: yo!
2019-06-13 13:46:30 <otlabs> it mutual
2019-06-13 13:46:51 <otlabs> sorry, I am some kind of busy for now
2019-06-13 13:46:56 <danieli> no worries :)
2019-06-13 13:47:10 <otlabs> so had no possibility to hang out here
2019-06-13 13:47:23 <otlabs> hope things will change for better
2019-06-13 13:47:57 <otlabs> I got an impressio that armv7 builder is failing right now
2019-06-13 13:48:10 <otlabs> Could someone please take a look at armv7 builder? At least the package for xmrig-proxy was build for all architectures except armv7
2019-06-13 13:48:12 <_ikke_> otlabs: it has been behind a bit
2019-06-13 13:48:34 <otlabs> _ikke_: glad to see you!
2019-06-13 13:48:42 <otlabs> oh, ok, so no worries
2019-06-13 13:49:44 <otlabs> SpaceToast: I have all tasks you have assigned to me in standby mode, will report about progress as soon as I get something
2019-06-13 13:51:23 <Cogitri> ikke: Could you ping me once testing/ is consistent on armv7 again? :)
2019-06-13 13:55:54 <revolutionary> Cogitri armv7 is a build monster :)
2019-06-13 14:54:55 <SpaceToast> hey otlabs, not to worry :)
2019-06-13 14:55:00 <SpaceToast> k3s can be fixed whenever
2019-06-13 14:55:11 <otlabs> thanks
2019-06-13 14:55:21 <otlabs> and that will be done :)
2019-06-13 15:04:43 <oninoshio> Any word on getting PostGIS rebuilt to work with the updated Proj4? (normally wouldn't ask so soon, but my IRC session was closed)
2019-06-13 15:06:16 <maxice8> Is it in community/ or testing /?
2019-06-13 15:06:39 <oninoshio> sorry, Edge/testing
2019-06-13 15:30:34 <_ikke_> Any new features or significant updates that should be included in the release notes for 3.10?
2019-06-13 15:30:52 <_ikke_> http://tpaste.us/rorz
2019-06-13 15:30:56 <_ikke_> this is what I have already
2019-06-13 15:32:05 <_ikke_> Is iwd a replacement for wpa_supplicant?
2019-06-13 15:32:08 <_ikke_> /alternative
2019-06-13 15:32:14 <_ikke_> mps: ^
2019-06-13 15:32:55 <mps> _ikke_: you didn't read backlog of channel?
2019-06-13 15:33:13 <mps> _ikke_: I think iwd should be in release notes
2019-06-13 15:33:14 <_ikke_> I did, that's why I'm asking about iwd
2019-06-13 15:33:40 <ncopa> tmhoang: i dont maind make LPAR bootable is its a low haning fruit
2019-06-13 15:33:52 <ncopa> the patches i have seen seems a bit weird though
2019-06-13 15:34:08 <ncopa> can't you set console=... when you boot LPAR?
2019-06-13 15:34:13 <mps> I mentioned also some sunxi/allwinner arm boards
2019-06-13 15:34:46 <mps> iwd is modern alternative to wpa_sp
2019-06-13 15:34:51 <_ikke_> gnome / kde are still in testing
2019-06-13 15:34:59 <_ikke_> so not part of the 3.10 release
2019-06-13 15:35:12 <mps> yes, PureTryOut[m] told
2019-06-13 15:36:08 <mps> I can look 'git short log' later to remind self is something important I forgot
2019-06-13 15:36:09 <_ikke_> any specifics on the support for new arm boards?
2019-06-13 15:36:18 <_ikke_> Yes. I've been looking at the commit logs as well
2019-06-13 15:36:18 <tmhoang> ncopa: that patch is one thing, I can change if I could. The another bigger problem is, we might need to inject necessary .apks inthe initramfs for LPAR image (other distros do so btw) -> now this looks like iso image but LPAR cannot boot from ISO via FTP (putting ISO in local machine to let LPAR boot it is ok). Or we have to create a custom initramfs-init for LPAR.
2019-06-13 15:36:44 <tmhoang> iirc console= wont work for s390x
2019-06-13 15:36:50 <ncopa> ok. sounds like it won't cut it for 3.10
2019-06-13 15:36:55 <tmhoang> :D
2019-06-13 15:37:06 <tmhoang> good I'll let it go now
2019-06-13 15:37:16 <mps> for arm boards we addded u-boot, serial console and ethernet drivers
2019-06-13 15:38:38 <tmhoang> ncopa: fyi, LPAR boot via FTP using .ins file : http://ports.ubuntu.com/ubuntu-ports/dists/bionic-updates/main/installer-s390x/current/images/generic/ubuntu.ins. We can do that with netboot image just fine. But we have to ask user to download initramfs + kernel and custom .parm file and host those 3 + .ins file in there local FTP server.
2019-06-13 15:38:43 <mps> and, not sure if crystal upgrade to 0.29.0 should be mentioned or not, you decide however you think
2019-06-13 15:38:45 <tmhoang> if that works for you, then I'm good
2019-06-13 15:40:01 <mps> ehm, don't forget wireguard is moved to community. It is 'thing' that a lot of people asked for
2019-06-13 15:40:03 <tmhoang> this could cut in 3.10 easily
2019-06-13 15:40:43 <tmhoang> with current initramfs-init patch merged, I could create a wiki page explain procedures for users to boot form LPAR/FTP
2019-06-13 15:40:52 <_ikke_> mps: wireguard is a good one
2019-06-13 15:42:04 <_ikke_> are these specific arm boards, or just arm boards in general (That are supported)
2019-06-13 15:42:16 <danieli> have a look at that elixir commit josé valim made earlier in response to the issue i opened, you might just be able to apply it without too much work
2019-06-13 15:42:27 <tmhoang> o/
2019-06-13 15:42:39 <mps> maybe also note that the NM now works with wpa_sp and iwd, should work with wireguard although don't know if someone tested it thoroughly
2019-06-13 15:43:20 <mps> these arm boards are those for which users asked better support
2019-06-13 15:43:59 <mps> example, PureTryOut[m] asked for Pine64
2019-06-13 15:44:48 <danieli> the 22.x release of erlang is a new major release, and it happens approx once a year
2019-06-13 15:45:06 <_ikke_> danieli: has that been merged in?
2019-06-13 15:45:10 <_ikke_> mps: I've added pine64 alredy
2019-06-13 15:45:13 <_ikke_> already
2019-06-13 15:45:22 <danieli> _ikke_: into elixir-lang/elixir master, yes, not my PR
2019-06-13 15:45:37 <mps> yes, I've seen it, because that I mentioned it
2019-06-13 15:45:56 <danieli> i was about to finish some extremely tedious work on a compiler and head to sleep
2019-06-13 15:46:43 <danieli> well.. for a nap anyway
2019-06-13 15:47:16 <mps> _ikke_: I'm out now, and behind not comfortable keyboard. will be at home in about 45 minutes I think, then will look if we forgot something else
2019-06-13 15:48:43 <_ikke_> mps: thanks
2019-06-13 15:49:03 <PureTryOut[m]> Pine64 isn't in 3.10.0_rc4 though, even though it should be. So it has been untested
2019-06-13 15:49:15 <mps> np, see you later
2019-06-13 15:49:39 <mps> PureTryOut[m]: I think it will be in next tarball
2019-06-13 15:50:23 <PureTryOut[m]> Hopefully
2019-06-13 15:50:50 <mps> (if the ncopa explain to me how he uses mkimage.sh I could test these issues) :)
2019-06-13 15:51:06 <mps> but again, see you all later
2019-06-13 19:50:54 <_ikke_> maxice8: You pushed a broken aport
2019-06-13 19:51:17 <_ikke_> A conflict marker is left behind
2019-06-13 19:51:18 <maxice8> which one ?
2019-06-13 19:51:24 <_ikke_> agg
2019-06-13 19:51:34 <_ikke_> The builders choke on it
2019-06-13 19:52:09 <maxice8> ok
2019-06-13 19:52:11 <maxice8> thanks for noticing
2019-06-13 19:52:35 <_ikke_> Someone noticed the armv7 builder doing nothing
2019-06-13 19:52:51 <_ikke_> When I inspected, I noticed buildrepo was giving an error
2019-06-13 19:53:15 <kr0k0> Hi guys
2019-06-13 19:53:44 <revolutionary> hi
2019-06-13 19:55:02 <_ikke_> andypost[m]: pgcli seems broken, 2 tests are failing
2019-06-13 19:55:30 <kr0k0> What's about pr5863? Would be nice to have PHP 7.3 in Alpine 3.10, because it's supported until Dec 2021.
2019-06-13 20:04:38 <mps> _ikke_: I looked at 'git log' but have no idea what should be in release notes as important things, besides those you already wrote and those about we talked today
2019-06-13 20:05:07 <mps> maybe elogind introduction
2019-06-13 20:05:21 <_ikke_> right, we don't want every little detail, just things that stand out
2019-06-13 20:05:43 <Cogitri> <mps "maybe elogind introduction"> That's in testing still, isn't it?
2019-06-13 20:06:18 <_ikke_> No, apparently in community
2019-06-13 20:06:18 <mps> Cogitri: oh, yes, why I thought it is in main
2019-06-13 20:06:31 <_ikke_> https://pkgs.alpinelinux.org/packages?name=elogind&branch=edge
2019-06-13 20:06:48 <mps> yes, it is moved to community
2019-06-13 20:07:21 <mps> well, git log is not short and probably I misread some things
2019-06-13 20:07:39 <_ikke_> I also skimmed through git log, with various filters
2019-06-13 20:08:02 <_ikke_> git log --diff-filter=A --oneline 3.9-stable..HEAD 'main/*/APKBUILD' 'community/*/APKBUILD'
2019-06-13 20:09:17 <mps> I have git 'slog' alias, but more general than this
2019-06-13 20:10:57 <mps> anyway, maybe to mention cyrstal upgrade from 0.27.0 to 0.29.0, crystal developers and core uses Alpine first to test build and Alpine is important to them
2019-06-13 20:11:26 <_ikke_> Yes, I mentioned that in the latest version
2019-06-13 20:11:50 <_ikke_> http://tpaste.us/65rZ
2019-06-13 20:11:59 <mps> nice, I have no idea what else to add
2019-06-13 20:13:12 <MY_R> maybe dropped qt4? :D
2019-06-13 20:13:24 <_ikke_> it's in there
2019-06-13 20:13:28 <mps> anyway, I think there will be 'git log' added somewhere for those who want to see more details about release
2019-06-13 20:13:33 <MY_R> oh, ok
2019-06-13 20:13:37 <_ikke_> yes
2019-06-13 20:13:57 <_ikke_> well, not a complete log
2019-06-13 20:15:26 <mps> understand, also I don't mean 'full' log. Full log is on git.a.o
2019-06-13 20:30:07 <_ikke_> And you as a user have a large impact on that as well
2019-06-13 20:30:30 <_ikke_> The more things you install or more complex things you install, the less secure your system is going to be
2019-06-13 20:30:41 <_ikke_> sorry, wrong channel
2019-06-13 20:31:59 <andypost[m]> ikke will check on other machine later tonight
2019-06-13 21:59:28 <otlabs> time to go, see you later, bye
2019-06-13 22:00:34 <revolutionary> bye
2019-06-13 23:31:51 <maxice8> To fix the netbox build on armv7 pr8788 can be merged
2019-06-13 23:43:10 <SpaceToast> noticed we didn't have fsharp. took a look at it. ... wow .net core is a mess
2019-06-13 23:44:26 <ddevault> bump https://patchwork.alpinelinux.org/patch/4542/
2019-06-13 23:45:43 <Cogitri> SpaceToast: Yes, it's terrible
2019-06-13 23:45:43 <maxice8> ddevault: is it urgent?
2019-06-13 23:46:02 <SpaceToast> it could be useful for plasma5
2019-06-13 23:46:04 <ddevault> no, but I just set up a new laptop and was annoyed by its absence
2019-06-13 23:46:08 <SpaceToast> I'm not sure if we want that out before 3.10
2019-06-13 23:46:47 <maxice8> I can merge tomorrow morning, currently too comfortable in bed to get out unless it is urgent
2019-06-13 23:46:51 <ddevault> np, thanks
2019-06-14 05:08:08 <danieli>  SpaceToast i've already looked at it for the sake of F# and PowerShell
2019-06-14 05:08:23 <SpaceToast> yeah, F# is why I was looking at it
2019-06-14 05:08:28 <danieli> it is unfortunately non-trivial, in the worst meaning of that term
2019-06-14 05:08:30 <SpaceToast> looks absolutely awful though
2019-06-14 05:08:56 <danieli> i already have a couple of apkbuilds in the works
2019-06-14 05:09:05 <SpaceToast> if I had (significantly) more motivation I'd probably do it anyway
2019-06-14 05:09:25 <SpaceToast> but my interest in F# is purely academic - I have nothing production-worthy made in it, nothing planned, and use nothing made in it
2019-06-14 05:09:36 <danieli> i see
2019-06-14 05:09:47 <danieli> i know a ~handful of people who have the same reason to be interested in F#
2019-06-14 05:09:52 <danieli> i just like it
2019-06-14 05:09:58 <SpaceToast> yeah, it's just a good language
2019-06-14 05:10:04 <SpaceToast> really too bad about the ecosystem
2019-06-14 05:10:21 <danieli> ha, yeah
2019-06-14 05:10:39 <danieli> i said the same thing about scala, shame about the ecosystem
2019-06-14 05:10:43 <danieli> looking forward to scala native
2019-06-14 05:11:26 <SpaceToast> oh cool, someone made scala but in llvm; good idea
2019-06-14 05:13:15 <danieli> they're planning to do erlang with JIT through LLVM too
2019-06-14 05:13:23 <danieli> but it's just a research project at the moment
2019-06-14 05:13:50 <SpaceToast> well erlang isn't escaping a weird environment
2019-06-14 05:14:05 <SpaceToast> I'd argue that it's much more important for the likes of scala and F#
2019-06-14 05:14:22 <danieli> it sort of is
2019-06-14 05:14:33 <danieli> but it's not nearly as bad as escaping JVM or .NET
2019-06-14 05:14:58 <SpaceToast> I think OTP's mostly fine, but if they can get it running on LLVM that's fine too :)
2019-06-14 05:15:07 <SpaceToast> (well, BEAM, whatever)
2019-06-14 05:15:40 <[[sroracle]]> light security vuln in abuild-sudo https://github.com/alpinelinux/abuild/pull/91
2019-06-14 05:16:52 <danieli> [[sroracle]]: ouch, that's not good
2019-06-14 06:02:10 <danieli> ncopa: due to yesterday's change to testing/rebar3, one of the commits in pr8629 no longer applies
2019-06-14 06:02:19 <danieli> i tried to force push a rebase to remove that commit but it didn't seem to like that
2019-06-14 06:06:04 <danieli> cherry-pick all the commits except 0900d5f20968aa104d8c080b03509932d9baf445 it should be fine
2019-06-14 07:57:00 <ncopa> danieli: can you rebase?
2019-06-14 07:59:01 <maxice8> pr8790 can be merged to fix netbox building on armv7
2019-06-14 07:59:21 <maxice8> oops, meant pr8788
2019-06-14 09:19:36 <tmhoang> clandmeter : may I have a gitlab.a.o account ?
2019-06-14 09:19:53 <clandmeter> you have
2019-06-14 09:20:01 <clandmeter> i just need to reset pw
2019-06-14 09:20:08 <danieli> i can fix it if you're busy
2019-06-14 09:20:12 <clandmeter> please do
2019-06-14 09:20:41 <danieli> tmhoang: PM
2019-06-14 09:27:21 <tmhoang> beautiful
2019-06-14 09:36:31 <PureTryOut[m]> Uhm, is CI (Drone) broken? For pr8792 it says the packages are disabled for all architectures, which is not true at all
2019-06-14 09:47:16 <clandmeter> PureTryOut[m]: if you break it you pay it
2019-06-14 09:48:54 <PureTryOut[m]> I don't understand why it's broken though lol
2019-06-14 09:50:48 <clandmeter> me neither
2019-06-14 09:50:50 <danieli> that's weird, arch is obviously set to "all"
2019-06-14 09:51:10 <PureTryOut[m]> Exactly
2019-06-14 09:51:17 <clandmeter> did we have an abuild update?
2019-06-14 09:51:41 <clandmeter> looks like it
2019-06-14 09:51:45 <clandmeter> 41 hours ago
2019-06-14 09:52:14 <clandmeter> interesting, other aports build fine.
2019-06-14 09:55:29 <clandmeter> ah i see it
2019-06-14 09:56:05 <clandmeter> 
ACTION slaps PureTryOut[m] with faulty $pkgver

2019-06-14 09:56:13 <PureTryOut[m]> Wut
2019-06-14 09:56:24 <PureTryOut[m]> Oh, forgot the = lol
2019-06-14 09:56:33 <_ikke_> :D
2019-06-14 09:57:02 <clandmeter> amateur :p
2019-06-14 09:57:43 <clandmeter> it was hard though to catch it.
2019-06-14 09:57:47 <PureTryOut[m]> Faulty sed, classic
2019-06-14 09:58:07 <PureTryOut[m]> Haha yeah, fixed it. Thanks!
2019-06-14 09:58:35 <PureTryOut[m]> This Qt upgrade is needed for Plasma 😛
2019-06-14 10:02:36 <danieli> what would the best way for someone to contact a package maintainer be? (see #alpine-linux - the openjdk8 maintainer is fabled)
2019-06-14 10:03:51 <ncopa> just testing the algitbot 0900d5f20968aa104d8c080b03509932d9baf445
2019-06-14 10:04:07 <danieli> 63f5e7d295659a855709901ce22a3e5f40fce455
2019-06-14 10:04:14 <danieli> perfect
2019-06-14 10:04:22 <danieli> that exact commit would cause it to flood the channel for a couple minutes or so
2019-06-14 10:04:51 <ncopa> this did the trick: local subject = string.gsub(res.commit.message, "\n.*", "")
2019-06-14 10:05:43 <clandmeter> right, i thought i could select the text before the first newline
2019-06-14 10:05:53 <clandmeter> but i wasnt succesful :)
2019-06-14 10:06:16 <danieli> i messed with string.gsub in my local lua repl but it didn't work right off the bat with the regex i tried
2019-06-14 10:06:22 <danieli> KISS, i guess, lol
2019-06-14 10:13:37 <maxice8> http://dup.pw/aports/63f5e7d2 very unfortunate
2019-06-14 10:14:07 <maxice8> was commited the same day a new SPDX version was released (3.0) that made most of it changes obsolete by marking GPL-X.X deprecated in favour of adding -or-later or -only suffix
2019-06-14 10:16:26 <danieli> i remember that
2019-06-14 10:16:26 <ncopa> haha
2019-06-14 10:17:56 <ncopa> can someone test if newapkbuild is okish now?
2019-06-14 10:18:22 <ncopa> i have merged various PRs
2019-06-14 10:18:25 <danieli> it was semi-broken for me because it tried to source(?) the APKBUILD and errored at the functions without a body
2019-06-14 10:18:35 <ncopa> can you check if that is solved now?
2019-06-14 10:18:53 <maxice8> works now
2019-06-14 10:19:12 <maxice8> https://i.imgur.com/l5H4wXs.png
2019-06-14 10:47:00 <_ikke_> ncopa: people would like php7.3 to be included in Alpine 3.10 (due to 7.2 reaching eol soon). Can it still be included?
2019-06-14 10:47:08 <ncopa> oh
2019-06-14 10:47:12 <ncopa> that sounds like a good idea
2019-06-14 10:47:13 <_ikke_> https://github.com/alpinelinux/aports/pull/5863
2019-06-14 10:47:26 <_ikke_> I'll work on getting it in then
2019-06-14 10:50:00 <ncopa> if we upgrade php, do we need to rebuild the php7-* packages too then?
2019-06-14 10:50:44 <_ikke_> Let me check
2019-06-14 10:51:11 <_ikke_> Probably yes for the binary extension
2019-06-14 10:51:43 <_ikke_> But most are subpackages of php7
2019-06-14 10:52:33 <danieli> right, rebase, i'll do it in a bit after a meeting
2019-06-14 10:52:37 <ncopa> http://tpaste.us/Va6N
2019-06-14 10:53:27 <_ikke_> ncopa: how did you get that list?
2019-06-14 10:53:48 <ncopa> ls -d php7-*
2019-06-14 10:53:58 <_ikke_> right
2019-06-14 10:54:42 <danieli> $ apk list | grep "^php7-" | wc -l
2019-06-14 10:54:42 <danieli> 124
2019-06-14 10:54:57 <_ikke_> most are subpackages of php7
2019-06-14 10:55:01 <danieli> yeah, figured as much
2019-06-14 10:55:42 <ncopa> but we dont need to rebuild the noarch?
2019-06-14 10:55:51 <_ikke_> as far as I know, no
2019-06-14 10:56:33 <_ikke_> they are not in a versioned directory
2019-06-14 10:56:39 <_ikke_> like python packages
2019-06-14 10:56:45 <ncopa> unit/APKBUILD:makedepends="perl-dev php$_phpver-dev php$_phpver-embed python3-dev ruby-dev"
2019-06-14 10:56:45 <ncopa> xapian-bindings/APKBUILD:_php_makedepends="php7-dev"
2019-06-14 10:56:55 <ncopa> those two as well i guess
2019-06-14 10:57:03 <bratkartoffel> i think you have to rebuild the php7 packages as the api version changes
2019-06-14 10:57:26 <_ikke_> bratkartoffel: the extensions, but not the noarch projects
2019-06-14 10:57:46 <_ikke_> ncopa: can I use ap somehow to get the build order for a list of packages?
2019-06-14 10:58:06 <ncopa> ab builddirs PKGS...
2019-06-14 10:58:27 <ncopa> ls -d php7-* | xargs ap builddirs
2019-06-14 10:58:59 <_ikke_> thanks
2019-06-14 11:00:57 <ncopa> tested php7-pear-mail_mime
2019-06-14 11:01:03 <ncopa> a rebuild changes nothing
2019-06-14 11:01:53 <ncopa> so noarch should not need to rebuild
2019-06-14 11:03:58 <ncopa> ncopa-edge-x86_64:~/aports/community$ for i in php7-*; do (cd $i && . ./APKBUILD; [ "$arch" != "noarch" ] && echo $pkgname); done | tpaste
2019-06-14 11:03:58 <ncopa> http://tpaste.us/mZ1d
2019-06-14 11:05:11 <_ikke_> Thanks
2019-06-14 11:05:45 <ncopa> im on it
2019-06-14 11:07:40 <_ikke_> There are two PRs that should be merged first according to bratkartoffel
2019-06-14 11:07:50 <ncopa> i have them covered already
2019-06-14 11:07:55 <_ikke_> good
2019-06-14 11:07:58 <ncopa> i merge them in the same rebuild process
2019-06-14 11:08:40 <ncopa> this too https://github.com/alpinelinux/aports/pull/5901
2019-06-14 11:08:44 <maxice8> cpd is failing on armv7 due to checksum mismatch https://build.alpinelinux.org/buildlogs/build-edge-armv7/testing/cpd/cpd-0.5.1-r0.log
2019-06-14 11:08:47 <maxice8> works on my machine
2019-06-14 11:09:56 <maxice8> lxd is failing on aarch64 (https://build.alpinelinux.org/buildlogs/build-edge-aarch64/testing/lxd/lxd-3.14-r0.log) __NR_mknod undeclared
2019-06-14 11:10:04 <maxice8> maybe aarch64 is missing a specific #define ?
2019-06-14 11:13:01 <maxice8> https://github.com/lxc/lxd/pull/5848 yep
2019-06-14 11:13:10 <PureTryOut[m]> Of course pr8792 exceeded the maximum output...
2019-06-14 11:13:52 <ncopa> php7-pecl-msgpack tests fails
2019-06-14 11:27:45 <bratkartoffel> ncopa: saw yor comment about depends_dev. i'll change this and rebase the commit
2019-06-14 11:38:03 <ncopa> dont bother
2019-06-14 11:38:10 <ncopa> i already fixed the commit
2019-06-14 11:38:45 <ncopa> and i am ready to push
2019-06-14 11:38:51 <ncopa> we may need rebuild some things in testing as well
2019-06-14 11:39:11 <ncopa> php 7.3 is pushed
2019-06-14 11:39:17 <ncopa> please test it once builders are done
2019-06-14 11:39:42 <bratkartoffel> php7-pecl-msgpack works for me: http://tpaste.us/9grK
2019-06-14 11:40:19 <ncopa> it failed due to pcre2-dev was missing in depends_dev to php7
2019-06-14 11:40:36 <ncopa> it works if you have pcre2-dev installed
2019-06-14 11:41:14 <ncopa> sorry
2019-06-14 11:41:18 <ncopa> im mixing
2019-06-14 11:41:25 <ncopa> i mixed other package
2019-06-14 11:41:43 <ncopa> i reported php7-pecl-msgpack upstream
2019-06-14 11:42:03 <ncopa> https://github.com/msgpack/msgpack-php/issues/136
2019-06-14 11:42:36 <bratkartoffel> "invalid random data" ouch...
2019-06-14 11:42:53 <bratkartoffel> it happens reproducible?
2019-06-14 11:44:02 <ncopa> dunno
2019-06-14 11:47:19 <ncopa> ok im gonna push rebuilds for testing too in a sec
2019-06-14 11:47:32 <ncopa> i also forgot to rebuild unit and xapian-bindings
2019-06-14 11:47:48 <ncopa> currently building xapian-bindings
2019-06-14 11:48:04 <ncopa> lets hope nothings breaks
2019-06-14 11:48:07 <_ikke_> php7-pecl-oauth failed
2019-06-14 11:48:08 <danieli> when is 3.10 getting tagged?
2019-06-14 11:48:13 <_ikke_> soon (tm)
2019-06-14 11:48:18 <ncopa> was supposed to happend today
2019-06-14 11:48:26 <ncopa> but we squeezed in php 7.3 now
2019-06-14 11:48:35 <danieli> guess i should do that rebase now then
2019-06-14 11:48:37 <danieli> just had a meeting
2019-06-14 11:48:40 <ncopa> so i'd say early next week
2019-06-14 11:48:52 <ncopa> i think there will be new rc today
2019-06-14 11:48:57 <ncopa> hopefully the last
2019-06-14 11:49:12 <danieli> few things depend on erlang, so it should be fairly painless
2019-06-14 11:49:20 <danieli> otoh there are a fair amount of erlang users on alpine
2019-06-14 11:49:22 <_ikke_> ncopa: Updated the relnotes
2019-06-14 11:50:15 <bratkartoffel> _ikke_ php7-pecl-oauth needs pcre-dev, not just pcre2-dev (from php7-dev)
2019-06-14 11:52:59 <bratkartoffel> rebase pr5905
2019-06-14 11:53:09 <ncopa> bratkartoffel: i think that is a bug in pecl oauth
2019-06-14 11:53:27 <ncopa> i think they actually use pcre.h
2019-06-14 11:54:31 <ncopa> s/i think/i dont think/
2019-06-14 11:54:31 <alpine-meetbot> ncopa meant to say: i dont think they actually use pcre.h
2019-06-14 11:54:48 <ncopa> yup, its a bug in php7-pecl-oauth
2019-06-14 11:55:36 <bratkartoffel> i could try to patch it quick and dirty
2019-06-14 11:55:44 <bratkartoffel> to use pcre2
2019-06-14 11:56:16 <ncopa> i dont think they should use either
2019-06-14 11:56:38 <ncopa> $ tpaste < pcre.patch
2019-06-14 11:56:38 <ncopa> http://tpaste.us/nMpM
2019-06-14 11:57:28 <ncopa> i htink i'll just do that ^^^
2019-06-14 11:59:19 <ncopa> we could check for "ext/pcre/php_pcre.h"
2019-06-14 12:08:43 <maxice8> We are under 200
2019-06-14 12:09:27 <Cogitri> Nice
2019-06-14 12:12:09 <ncopa> super nice!
2019-06-14 12:14:43 <danieli> hey ho, 194 PRs
2019-06-14 12:15:15 <danieli> 61 in patchwork, going back all the way to 2016
2019-06-14 12:15:29 <_ikke_> The older ones in PW can probably just be archived
2019-06-14 12:16:18 <danieli> agreed
2019-06-14 12:26:56 <ncopa> wow
2019-06-14 12:27:06 <ncopa> you ppl are awesome
2019-06-14 12:29:54 <maxice8> ncopa: no u
2019-06-14 12:32:36 <danieli> god damn it, i screwed over the erlang PR by forgetting to make a new branch for the changes, i did it directly on master in the fork - i meant to make it a disposable fork
2019-06-14 12:35:38 <danieli> fixed it.
2019-06-14 12:35:43 <danieli> i'm just tired and made a silly mistake
2019-06-14 12:39:53 <danieli> i wonder why rebar3 failed on arm7 in the first place, it didn't error, it just printed some harmless warnings
2019-06-14 12:42:51 <kr0k0> Hi guys
2019-06-14 12:43:09 <kr0k0> bratkartoffel: What's about you pr5863? Is there something missing?
2019-06-14 12:43:26 <kr0k0> s/you/your
2019-06-14 12:43:26 <alpine-meetbot> kr0k0 meant to say: bratkartoffel: What's about your pr5863? Is there something missing?
2019-06-14 12:44:01 <bratkartoffel> kr0k0: it's already merged in master
2019-06-14 12:47:42 <kr0k0> bratkartoffel: Sorry, forgt to refresh site in my browser ^^
2019-06-14 12:48:32 <kr0k0> bratkartoffel: Thanks for your effort!
2019-06-14 13:22:59 <danieli> ffs.. my change to pr8629 (rebase on top of a commit by ncopa) did not include the upstream fix. I should get out of friday mode :P
2019-06-14 13:33:35 <ncopa> maxice8 or Cogitri: can one of you help me upgrade glib to 2.60.4 and meson?
2019-06-14 13:33:46 <ncopa> you have experience with meson switch
2019-06-14 13:34:20 <maxice8> It is currently missing static libraries
2019-06-14 13:34:46 <maxice8> So we will need a glib-static that builds only the static library
2019-06-14 13:34:59 <maxice8> I'm getting my car at the garage atm can't help
2019-06-14 13:35:21 <maxice8> Cogitri did the glib updates on VL so he is a better shot
2019-06-14 13:40:15 <Cogitri> Yup, I can do that, but then we'll have glib (nonstatic) v2.60.x and glib-static 2.58
2019-06-14 13:40:33 <Cogitri> Because meson is a bit broken in that regard right noe
2019-06-14 13:44:17 <ncopa> what do we need glib-static for?
2019-06-14 13:44:26 <Cogitri> Gonna do it later today I guess :)
2019-06-14 13:45:40 <maxice8> QEMU
2019-06-14 13:45:48 <ncopa> oh
2019-06-14 13:46:58 <Cogitri> I think I saw some other stuff wanting it in aports, but not 100% positive on that rn
2019-06-14 13:47:16 <ncopa> i think upstream  glib does not support static
2019-06-14 13:47:36 <ncopa> and i think quarks or what they are called depends on dynamic linker constructor to work
2019-06-14 13:49:12 <Cogitri> They do, they just didn't care about it enough to not drop Autotools (which supports static libs better)
2019-06-14 13:52:29 <ncopa> next question is why qemu needs static glib
2019-06-14 13:52:49 <ncopa> iirc it was due to lack of ucontext
2019-06-14 13:55:51 <ncopa> :-(
2019-06-14 13:55:53 <ncopa> ok
2019-06-14 13:55:55 <ncopa> we cannot upgrade
2019-06-14 13:56:09 <ncopa> unless we can build glib with static and meson
2019-06-14 13:56:28 <maxice8> We can if you're willing to keep a glib-static around just for it
2019-06-14 13:56:48 <maxice8> Apparently QEMU isn't particularly important for glib
2019-06-14 13:57:20 <ncopa> how do you mean keep glib-static
2019-06-14 13:57:36 <ncopa> like add a glib2.58-static package?
2019-06-14 13:58:02 <ncopa> i dont think that will fly either, because qemu needs gtk witch also needs glib
2019-06-14 13:58:07 <ncopa> so there will be conflict
2019-06-14 14:00:30 <ncopa> hum
2019-06-14 14:00:38 <ncopa> looks like fedora has glib2-static
2019-06-14 14:00:43 <ncopa> should not be any problem?
2019-06-14 14:00:55 <ncopa> https://src.fedoraproject.org/rpms/glib2/blob/master/f/glib2.spec#_92
2019-06-14 14:05:56 <Cogitri> Yup, Void has that too
2019-06-14 14:21:31 <ncopa> this may be needed to enforce use of gnu gettext http://tpaste.us/zBVa
2019-06-14 14:22:18 <ncopa> im going out for a walk
2019-06-14 14:22:27 <ncopa> this is my wip: http://tpaste.us/Xnr1
2019-06-14 14:22:33 <revolutionary> hi
2019-06-14 14:23:50 <ncopa> it still fails on -doc subpackage
2019-06-14 14:50:54 <maxice8> Failure on aarch64 https://build.alpinelinux.org/buildlogs/build-edge-aarch64/testing/php7-libvirt-php/php7-libvirt-php-0.5.4-r1.log
2019-06-14 15:03:10 <maxice8> I cleaned up some old PRs https://bugs.alpinelinux.org/issues/10534
2019-06-14 17:24:07 <revolutionary> drebrez what i am doing wrong?
2019-06-14 17:24:12 <revolutionary> wrong chan
2019-06-14 17:43:51 <danieli> _ikke_: pr8629 is ready for a merge, the CI error is apparently "Cancelled", perhaps because it took too long time or something
2019-06-14 17:54:54 <andypost> ncopa, please backport pr8797
2019-06-14 17:58:07 <ncopa> andypost: im on it
2019-06-14 17:58:41 <_ikke_> evening
2019-06-14 18:01:55 <andypost> hi _ikke_ are you ok to commit pr8786 with 2 related same time, they are dependent
2019-06-14 18:02:32 <_ikke_> andypost: I'll look at it in a moment
2019-06-14 18:17:30 <ncopa> ok, i have a problem with glib and meson
2019-06-14 18:17:44 <ncopa> the generated glib-2.0.pc has Libs: -lintl ...
2019-06-14 18:18:03 <ncopa> but the -lintl needs to be added at the end, not in the beginning
2019-06-14 18:18:14 <ncopa> how and where is the glib-2.0.pc generated?
2019-06-14 18:34:32 <_ikke_> not really clear from meson.build
2019-06-14 18:34:53 <revolutionary> hi all
2019-06-14 18:35:28 <_ikke_> hi
2019-06-14 20:05:26 <danieli> _ikke_: apologies on not cleaning up cloudi, i am not too familiar with it and changed it purely to rebuild against newer erlang
2019-06-14 20:21:22 <_ikke_> right, I thought I would just fix it on the go
2019-06-14 20:52:33 <danieli> no worries, i was just excusing my inaction
2019-06-14 21:09:14 <maxice8> https://patchwork.alpinelinux.org/patch/4872/ can be closed: merged
2019-06-14 21:19:13 <danieli> ncopa: ouchie ^
2019-06-14 21:19:37 <revolutionary> when i heard ouchie i remember Charlie
2019-06-14 21:19:51 <danieli> that's.. a bit off topic?
2019-06-14 21:20:10 <revolutionary> not a bit. completely offtopic
2019-06-14 21:59:07 <mps> are we at risk: CVE-2019-12749 - dbus before 1.10.28, 1.12.x before 1.12.16, and 1.13.x before 1.13.12, as used in DBusServer in Canonical Upstart in Ubuntu 14.04 (and in some, less common, uses of dbus-daemon), ....
2019-06-14 21:59:21 <mps> https://www.secnews24.com/2019/06/11/cve-2019-12749/
2019-06-15 07:50:50 <danieli> am i blind? for some reason i am not finding the definition for `apk_string_array_init', neither is gtags
2019-06-15 07:51:39 <danieli> mps: yes
2019-06-15 07:54:47 <danieli> all the way back to 3.7 i believe
2019-06-15 08:08:46 <[[sroracle]]> danieli: https://git.alpinelinux.org/apk-tools/tree/src/apk_defines.h#n189
2019-06-15 08:09:10 <danieli> ah okay, now i see
2019-06-15 08:09:17 <danieli> i completely missed that, thanks [[sroracle]] :)
2019-06-15 08:09:21 <[[sroracle]]> np
2019-06-15 08:14:31 <mps> danieli: I wasn't sure about this dbus 'secissue', they mention ubuntu with upstart and 'less common uses of dbus'
2019-06-15 08:14:49 <danieli> mps: right, i'll check the details of the vuln and see if it's applicable to alpine
2019-06-15 08:16:16 <mps> anyway, wouldn't hurt if we upgrade
2019-06-15 08:18:17 <cim209> what is the alpine equivalent of /dev/disk/by-id? i have mutiple virtual partitions attached to the server, the control panel shows its IDs, so i need to see which is which in alpine
2019-06-15 08:19:12 <danieli> wasn't this asked in #alpine-linux just a moment ago?
2019-06-15 08:19:21 <danieli> this is the development channel
2019-06-15 08:20:05 <cim209> sorry thought this was also a help channel
2019-06-15 08:20:23 <danieli> mps: i'll make a pr to upgrade it anyway, it could be backported
2019-06-15 08:23:41 <mps> ok, I thought to do this last night but didn't because not sure if it needed in time when we are expecting releas
2019-06-15 08:23:59 <danieli> doesn't really matter much imo, might as well make a pr/patch
2019-06-15 08:24:14 <danieli> i'm not so sure we're affected though, we don't have a dbus server binary, only some libraries for it
2019-06-15 08:24:27 <danieli> but i don't have an authoritative answer
2019-06-15 08:24:29 <mps> danieli: do it!
2019-06-15 08:25:08 <mps> :D
2019-06-15 08:26:45 <mps> we will see if sec team thinks it should be backported or not
2019-06-15 08:28:57 <mps> yesterday I had a hard day, today I will look if I can fix some failed build on armv7 in main and community
2019-06-15 08:31:04 <danieli> there's an issue for it in the alpine security redmine project
2019-06-15 08:31:13 <danieli> but that doesn't necessarily mean we're affected
2019-06-15 08:31:26 <danieli> judging by 'dbus' and the affected version numbers though, we are
2019-06-15 08:33:17 <mps> by versions yes, but descriptions on not only one sec site/list suggest we are not, expect this unclear 'some, less common, uses of dbus-daemon' sentence
2019-06-15 08:34:26 <danieli> exactly
2019-06-15 08:36:17 <mps> when you make PR, post it here, I will try rebuild on few arches to check it. are you ok with this?
2019-06-15 08:37:03 <danieli> of course
2019-06-15 08:49:46 <danieli> man, so much stuff will have to be rebuilt when dbus is bumped
2019-06-15 08:50:00 <danieli> i'm not sure i want to mess with that, i'm not familiar with how it's structured in alpine
2019-06-15 08:52:11 <mps> yes, that was reason I first asked here, especially to not impede release of 3.10. I thought to make patch last night but ceased
2019-06-15 09:04:33 <Cogitri> Oh, are minor dbus releases ABI incompatible?
2019-06-15 09:05:42 <mps> shouldn't be
2019-06-15 09:05:51 <danieli> they probably are, but i'm not too familiar with dbus
2019-06-15 09:05:55 <danieli> er
2019-06-15 09:05:58 <danieli> they probably aren't* my bad
2019-06-15 09:15:08 <Cogitri> Why do we need to "rebuild so much stuff when dbus is bumped" then? :o
2019-06-15 09:16:37 <danieli> yeah nevermind that if the abi is the same
2019-06-15 09:53:06 <Cogitri> Alright then :)
2019-06-15 12:17:32 <maxice8> need some checks on pr8806 and pr8807
2019-06-15 12:25:12 <mps> maxice8: you just upgraded amule and it has wxgtk2.8-dev in makedepends. could amule be built with current wxgtk in community?
2019-06-15 12:29:33 <mps> looks like if amule could be built with new wxgtk 3 boot PR's are good
2019-06-15 12:30:16 <maxice8> mps: it uses wxgtk not wxgtk2.8
2019-06-15 12:31:49 <mps> right, you already upgraded it
2019-06-15 12:32:13 <mps> I forgot 'git pull' after seeing your upgrade
2019-06-15 12:32:50 <mps> funny thing is that I also worked on amule upgrade, and you did it before me
2019-06-15 12:33:22 <maxice8> Happens
2019-06-15 12:33:31 <mps> so again, your both PR's looks fine
2019-06-15 12:34:23 <mps> double (or multiple work) are not uncommon in free/open source, which is good imo
2019-06-15 12:35:04 <mps> I think you can push them
2019-06-15 13:39:31 <mps> maybe this main/mpfr3 should be renamed to main/mpfr (without version) because it have subpackage named mpfr-dev
2019-06-15 13:40:03 <mps> and, 4.0.2 builds cleanly
2019-06-15 13:48:47 <andypost[m]> Sounds like 3 makes no sense, but new package better to add provides/replaces for BC
2019-06-15 13:54:30 <mps> this ^, or rename (mv). and it have replaces=mpfr. git log shows 'Wed Jun 23 11:43:11 2010 +0000 main/mpfr3: renamed for upgrade new abi version'
2019-06-15 13:58:04 <mps> some API is changed from 3.1.x
2019-06-15 15:34:11 <mps> maxice8: we have https://patchwork.alpinelinux.org/patch/4897/ - main/libgit2: update to 0.28.2
2019-06-15 15:35:22 <maxice8> Yes
2019-06-15 15:35:34 <maxice8> What should I do about it?
2019-06-15 15:35:44 <mps> I see that you already upgraded it. What we should do with it on pw.a.o ? mark as Superseded and write short note to author
2019-06-15 15:36:25 <mps> If you have had objections to the patch on pw.a.o we should write comment to author
2019-06-15 15:36:54 <maxice8> Nothing to object I just didn't follow pw at the time I updated it
2019-06-15 15:37:23 <mps> If you didn't know for this patch when you made upgrade than just note that, with nice excuse words :)
2019-06-15 15:38:09 <mps> aha, ok. I will write reply and mark it Superseded. no worries
2019-06-15 15:45:09 <mps> maxice8: same question for testing/shadowsocks-libev: upgrade to 3.2.5
2019-06-15 15:46:03 <mps> sorry if I'm annoying you too much, but I would like to 'close' some patches on pw.a.o
2019-06-15 15:46:38 <maxice8> No worries I sent a bunch of pw links to close but people insisted someone write a nice reply
2019-06-15 15:46:57 <maxice8> Which I can't summon the effort to so it is good someone is doing it
2019-06-15 15:47:10 <maxice8> That patch was missing libcorkipset and libbloom in the dependencies
2019-06-15 15:47:26 <mps> well, we have to be nice and handsome :)
2019-06-15 15:48:06 <mps> aha, ok. will write then that the more complete patch is applied. thanks for info
2019-06-15 15:49:04 <maxice8> Ty
2019-06-15 15:49:18 <mps> np
2019-06-15 15:53:46 <maxice8> I'm out of the comfortable black hole that is my bed, anything that needs to be done ?
2019-06-15 15:56:10 <mps> maxice8: nothing special. I just looking if I can close some of the old patches on pw.a.o to have less when we move to gitlab
2019-06-15 15:56:29 <maxice8> Speaking of lab
2019-06-15 15:56:42 <maxice8> will it be complete or will github and pw remain as possible ways to contribute ?
2019-06-15 15:57:50 <mps> some of us testing it, and I hope we will not wait too long for it.
2019-06-15 15:58:34 <mps> I hope we will not need pw.a.o because gitlab could accept merge request (PR on GH) by mail
2019-06-15 16:00:13 <mps> and yes, idea is to be 'free' of possible lock-in by github
2019-06-15 16:01:39 <mps> although git.a.o will stay as is for some time
2019-06-15 16:02:55 <mps> people who works on moving to gitlab works hard for us to have integration of bugs, patches, pull requests etc.
2019-06-15 16:08:58 <mps> https://patchwork.alpinelinux.org/patch/4542/ - community/font-noto-cjk: new APKBUILD
2019-06-15 16:09:31 <maxice8> Ah yes ddevault asked for that to be merged
2019-06-15 16:09:32 <mps> do we really need/want this in Alpine, it is big imo
2019-06-15 16:09:51 <SpaceToast> I don't think anyone's asking for it to be included on the disk
2019-06-15 16:10:20 <SpaceToast> but I'm sure some people may want to type in zh or jp while in x/wayland
2019-06-15 16:11:18 <mps> understand, but our archives will be filled with it
2019-06-15 16:12:33 <mps> could this package be somehow split to some number of important fonts? I don't know really just asking
2019-06-15 16:13:11 <SpaceToast> this is post-split
2019-06-15 16:13:31 <SpaceToast> noto fonts are split into noto-fonts, noto-fonts-emoji, noto-fonts-cjk and noto-fonts-extra
2019-06-15 16:13:41 <SpaceToast> which are the general components
2019-06-15 16:14:33 <mps> yes, we have already some number of font-noto-* pkg's
2019-06-15 16:15:10 <SpaceToast> cjk stands for Chinese, Japanese, Korean
2019-06-15 16:15:24 <mps> yes, I know
2019-06-15 16:15:29 <SpaceToast> I don't know about Korean, but it makes sense to bundle the first two, since a lot of the glyphs are shared (through the latter's kanji)
2019-06-15 16:15:43 <SpaceToast> trying to split them up would make the sum of the results bigger than the package in question
2019-06-15 16:15:45 <mps> but don't know what to do with this patch
2019-06-15 16:16:07 <SpaceToast> well, your worry seems to be that it'll "gunk up" the storage somehow
2019-06-15 16:16:15 <mps> right
2019-06-15 16:16:19 <SpaceToast> if you're very seriously worried about it, perhaps ask the people handling the storage? :)
2019-06-15 16:16:40 <mps> SpaceToast: good idea, thanks
2019-06-15 16:17:19 <SpaceToast> general storage space is something like 300mb unpacked (roughly?), so I don't think it'd be that big a deal relative to everything else we store; but getting you your peace of mind shouldn't be a big problem
2019-06-15 16:19:40 <ddevault> there are no cjk fonts availble on Alpine
2019-06-15 16:19:52 <SpaceToast> I've mentioned that, yeah
2019-06-15 16:20:11 <mps> yes, and would be nice to have them
2019-06-15 16:20:50 <ddevault> that leaves 20% of the world's population unable to use Alpine
2019-06-15 16:21:58 <ddevault> in terms of splitting the languages up
2019-06-15 16:22:05 <ddevault> it's not really practical
2019-06-15 16:22:19 <ddevault> han unification means that chinese and japanese share most of the same characters, which makes up the bulk of the font
2019-06-15 16:22:27 <ddevault> the remaining japanese and korean characters number less than 100
2019-06-15 16:22:34 <mps> fonts-noto-cjk in Debian is Uncompressed Size: 126 M
2019-06-15 16:23:39 <mps> download from GH (right now) is: 1.8G Jun 15 16:21 NotoSansV2.001.tar.gz
2019-06-15 16:24:26 <MY_R> anyone else tested noto fonts? I installed it once but in firefox ui bottom parts of fonts were just cut off
2019-06-15 16:24:45 <ddevault> I use the cjk package on the daily and it seems fine
2019-06-15 16:24:47 <ddevault> haven't tested the others
2019-06-15 16:25:20 <mps> MY_R: I did, but deleted and left only font-noto-emoji
2019-06-15 16:25:30 <MY_R> letters like "jgq" etc didnt show correctly
2019-06-15 18:07:58 <wozencroft> I suppose those instructions in the wiki for wireguard do not lead to a working configuration.
2019-06-15 18:08:26 <wozencroft> I mean the interface is up and looks ok at the first glance, but the traffic is not over the vpn
2019-06-15 18:09:24 <wozencroft> And using wg-quick does not connect to the net
2019-06-15 18:24:15 <mps> wozencroft: did you mean these wiki https://wiki.alpinelinux.org/wiki/Configure_a_Wireguard_interface_(wg)
2019-06-15 18:26:04 <wozencroft> mps: Exactly. I just realized it automatically uses "/24" when giving an address in the interfaces file and I'm trying to use a setup with x.x.x.x/32 - not sure if this is the culprit
2019-06-15 18:27:54 <wozencroft> Strange thing is that "ip a" shows the same output for wg0 as with a working connection
2019-06-15 18:29:33 <mps> it works for me out of the box, and to start connection I send one icmp/ping packet
2019-06-15 18:30:15 <wozencroft> mps: You mean wg-quick - does it work for you out of the box?
2019-06-15 18:30:41 <mps> no, don't use wg-quick
2019-06-15 18:31:14 <mps> auto wg0 is enough to bring it up on boot
2019-06-15 18:31:33 <wozencroft> Ok, I see.
2019-06-15 18:31:46 <mps> if you didn't rebooted machine then you have to 'ifup wg0'
2019-06-15 18:32:13 <wozencroft> Indeed, that's the command I tried but also rebooted after install
2019-06-15 18:32:32 <mps> if you change something then 'ifdown wg0' and again 'ifup wg0'
2019-06-15 18:32:57 <wozencroft> And ifup brings up the interface wg0, but the traffic is not over the vpn
2019-06-15 18:33:23 <mps> 'ip route' is correct?
2019-06-15 18:33:51 <mps> also checl keys on peers
2019-06-15 18:34:02 <mps> s/checl/check/
2019-06-15 18:34:02 <alpine-meetbot> mps meant to say: also check keys on peers
2019-06-15 18:37:56 <wozencroft> mps: I have for ip route as the third line: x.x.x.x (server address) dev wg0 scope link
2019-06-15 18:40:26 <wozencroft> But I suppose there is the culprit indeed: x.x.x.0/24 dev wg0 proto kernel scope link src x.x.x.x - it should be /32
2019-06-15 18:40:48 <wozencroft> (second line in the output)
2019-06-15 18:42:09 <mps> wozencroft: what is your netmask
2019-06-15 18:44:54 <wozencroft> mps: Same as on the wiki page
2019-06-15 18:45:16 <wozencroft> 255.255.255.0
2019-06-15 18:50:15 <wozencroft> In the interfaces file I have: post-up ip route add x.x.x.x/32 dev wg0 - that address works on other distros
2019-06-15 18:51:38 <mps> if you wan't ip address to be x.x.x.x/32 you have to set netmask to 255.255.255.255
2019-06-15 18:56:57 <wozencroft> mps: Oh, thank you for the hint! Maybe that was it, testing it now.
2019-06-15 18:58:46 <mps> np, I will be afk some time now
2019-06-15 19:00:43 <wozencroft> Ok, thank you for having a look at it
2019-06-15 19:33:10 <wozencroft> I tested it with 255.255.255.255 (indeed, this netmask is shown on other distros too), but the traffic is not over wg0. Everything seems to work (bringing up interface, ip a output like on other distros), but the traffic is not over the vpn.
2019-06-15 20:54:25 <danieli> elooks like kernel.org now mirrors alpine linux
2019-06-15 20:54:31 <danieli> s/elooks/looks/
2019-06-15 20:54:31 <alpine-meetbot> danieli meant to say: looks like kernel.org now mirrors alpine linux
2019-06-15 20:55:45 <PureTryOut[m]> Could someone take a look at pr8792?
2019-06-15 20:58:09 <mps> danieli: so we are now one of important distros
2019-06-15 20:58:23 <danieli> mps: :)
2019-06-15 21:31:28 <jwh> /dev/null/utmp: Not a directory
2019-06-15 21:31:29 <jwh> lol java
2019-06-15 21:33:05 <danieli> yeah, {u,w,b}tmp{,x} is not available on alpine
2019-06-15 21:33:09 <mps> jwh: screen also
2019-06-15 21:33:19 <jwh> danieli: the path :P
2019-06-15 21:33:28 <danieli> lol.
2019-06-15 21:33:29 <jwh> mps: screen works ok for me
2019-06-15 21:33:32 <danieli> what the
2019-06-15 21:33:45 <jwh> ikr
2019-06-15 21:33:47 <mps> screen works but show this msg
2019-06-15 21:33:48 <danieli> echo "AAAAAAAAAAAAAAAAAAA" > /dev/null
2019-06-15 21:33:51 <danieli> screaming into the void
2019-06-15 21:34:06 <jwh> it's not in the application I'm running... so it must be in jre
2019-06-15 21:35:36 <mps> I thought to patch screen, but because this msg is harmless I concluded it is not important
2019-06-15 21:36:06 <jwh> what message does screen emit?
2019-06-15 21:36:21 <jwh> same one?
2019-06-15 21:36:45 <jwh> if so, why are they picking that path, is it a build time option?
2019-06-15 21:36:45 <mps> this: /dev/null/utmp: Not a directory
2019-06-15 21:37:23 <danieli> i wonder if some autoconfiguration during build failed and causes that
2019-06-15 21:38:07 <danieli> gcc -c -I. -I.  -Os -fomit-frame-pointer -DETCSCREENRC='"/usr/etc/screenrc"' -DSCREENENCODINGS='"/usr/share/screen/utf8encodings"' -DHAVE_CONFIG_H -DGIT_REV=\"\" \
2019-06-15 21:38:07 <danieli>      -Os -fomit-frame-pointer -D_GNU_SOURCE utmp.c
2019-06-15 21:38:09 <danieli> doesn't seem relevant
2019-06-15 21:38:21 <jwh> perhaps a musl stub
2019-06-15 21:38:24 <jwh> or something
2019-06-15 21:38:34 <danieli> ceckung
2019-06-15 21:38:36 <danieli> checking
2019-06-15 21:38:50 <danieli> gcc -c -I. -I.  -Os -fomit-frame-pointer -DETCSCREENRC='"/usr/etc/screenrc"' -DSCREENENCODINGS='"/usr/share/screen/utf8encodings"' -DHAVE_CONFIG_H -DGIT_REV=\"\" \
2019-06-15 21:38:50 <danieli>      -Os -fomit-frame-pointer -D_GNU_SOURCE utmp.c
2019-06-15 21:38:53 <danieli> god damn it
2019-06-15 21:38:56 <danieli> include/paths.h:#define _PATH_UTMP      "/dev/null/utmp"
2019-06-15 21:38:56 <danieli> include/paths.h:#define _PATH_WTMP      "/dev/null/wtmp"
2019-06-15 21:38:56 <danieli> include/utmp.h:#define _PATH_UTMP "/dev/null/utmp"
2019-06-15 21:38:56 <danieli> include/utmp.h:#define _PATH_WTMP "/dev/null/wtmp"
2019-06-15 21:39:01 <jwh> lol
2019-06-15 21:39:13 <danieli> i didn't hit the copy keybind aggressively enough
2019-06-15 21:39:22 <jwh> really applications should just not build in utmp/wtmp support but alas
2019-06-15 21:39:24 <jwh> thats hard
2019-06-15 21:39:26 <jwh> lol
2019-06-15 21:39:51 <danieli> daniel@lexapro.duniel.no [~/projects/musl]$ grep -r "/dev/null"
2019-06-15 21:40:03 <danieli> ignore the hostname ;) but that's what i did, i got a fair amount of matches
2019-06-15 21:40:27 <danieli> doesn't seem like anything else relates to utmp/wtmp though
2019-06-15 21:41:21 <mps> it is harmless at the end
2019-06-15 21:41:33 <mps> screen works quite nice
2019-06-15 21:42:04 <danieli> #ifdef ENABLE_UTMP
2019-06-15 21:42:07 <danieli> it can be disabled in screen
2019-06-15 21:43:20 <jwh> java is so horrible
2019-06-15 21:48:01 <mps> jwh: OT, I'm repeating this 20 years
2019-06-15 23:57:01 <oninoshio> So, I've figured out what's up with PostGIS. It needs a version bump.
2019-06-15 23:57:53 <oninoshio> I submitted a pull request for it, which seems to be working for me, but it seems to fail on drone/pr, it seems to pass on travis-ci/pr
2019-06-15 23:58:37 <maxice8> Travis only tests x86_64
2019-06-15 23:58:46 <maxice8> Drone is probably failing on another arch
2019-06-15 23:59:32 <oninoshio> okay, maybe proj4 doesn't exist properly on x86
2019-06-15 23:59:48 <revolutionary> ncopa: thank you so much for obfs4proxy package for armv7! I will test now. Appreciate
2019-06-16 00:01:06 <oninoshio> yep! that's it! I'll remove x68 from the APKBUILD then!
2019-06-16 00:12:59 <oninoshio> Is there anything I need to do other then issuing a pull request?
2019-06-16 00:16:07 <maxice8> Wait until a reviewer reviews it and do the proposed changes
2019-06-16 00:16:12 <maxice8> Is it urgent?
2019-06-16 00:18:32 <oninoshio> well, I'd like to get it done so I can install it on my dev enviroment. But the world isn't going to end or anything if it doesn't happen right now :p
2019-06-16 00:20:17 <maxice8> Ok
2019-06-16 00:20:20 <oninoshio> I was just asking because I've not contributed to Alpine before, so I'm not super-confident on the proceedure
2019-06-16 00:22:58 <revolutionary> ncopa: if possible could please enable armv7 for firefox-esr package? Thanks.
2019-06-16 00:23:22 <revolutionary> i need this package for testing obfs4proxy
2019-06-16 00:27:04 <revolutionary> obfs4proxy is working good!
2019-06-16 00:28:27 <revolutionary> ahh, failed. i need firefox-esr :/
2019-06-16 00:33:12 <danieli> i don't think rust is built for anything except x86_64 yet, so any firefox version depending on rust for servo will not land on arm just yet
2019-06-16 00:38:46 <revolutionary> maybe works
2019-06-16 00:41:47 <danieli> rust has been broken for some time, but some work has been done on it recently
2019-06-16 00:42:16 <revolutionary> i see
2019-06-16 10:35:23 <mps> is Paul Bredbury here, maybe
2019-06-16 10:36:27 <mps> just have seen some mate pkg's upgrades, looks good and would be good to have it in 3.10
2019-06-16 11:43:39 <PureTryOut[m]> Could someone review pr8792?
2019-06-16 11:44:08 <PureTryOut[m]> Plasma Mobile on postmarketOS is currently broken and the upgrade should fix it. It's also a requirement for Plasma Desktop (which I want to package for Alpine Linux)
2019-06-16 11:47:43 <mps> PureTryOut[m]: this is just minor version upgrade as I see. did you tested on CI
2019-06-16 11:47:56 <mps> I mean, does it builds
2019-06-16 11:48:12 <PureTryOut[m]> Till it exceeds maximum output, yes
2019-06-16 11:48:33 <PureTryOut[m]> It builds locally anyway, but I can not test architectures like s390x
2019-06-16 11:49:07 <mps> hmm, I can try on armv7
2019-06-16 12:27:12 <mps> PureTryOut[m]: tried some (not all) and they build without problem
2019-06-16 12:28:04 <PureTryOut[m]> Good
2019-06-16 15:43:37 <_ikke_> Good $timeofday
2019-06-16 15:44:00 <Cogitri> Hello there, ikke
2019-06-16 15:44:23 <maxice8> _ikke_: hi
2019-06-16 16:59:12 <maxice8> thread 'main' panicked at 'Unable to find build dependency python3: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/libcore/result.rs:997:5
2019-06-16 16:59:14 <maxice8> alacritty
2019-06-16 16:59:29 <_ikke_> maxice8: Right, just replied to ddevault about it
2019-06-16 16:59:40 <_ikke_> It built fine locally
2019-06-16 16:59:48 <_ikke_> and even on 3.10/x86_64
2019-06-16 17:00:18 <maxice8> weird
2019-06-16 17:00:22 <maxice8> well i'm going to go eat
2019-06-16 17:00:40 <_ikke_> Oh, right, it's not built for 3.10, silly me
2019-06-16 17:00:42 <_ikke_> (testing)
2019-06-16 17:06:36 <_ikke_> So it requires python3 on x86_64
2019-06-16 17:08:20 <ddevault> working on it
2019-06-16 17:08:28 <ddevault> this patch sucks anyway, I'll get it fixed up proper this time
2019-06-16 17:09:03 <_ikke_> I had python3 still installed on my build system, so there it was not caught
2019-06-16 17:09:07 <ddevault> aye
2019-06-16 18:29:52 <_ikke_> ddevault: I had already pushed the upgrade to 0.3.3, so this will be just a fix commit
2019-06-16 18:30:03 <ddevault> _ikke_: okay, should I let you handle that or do you want me to rebase
2019-06-16 18:30:09 <_ikke_> I can handle it
2019-06-16 18:30:12 <ddevault> cheers
2019-06-16 18:30:16 <ddevault> thanks for your patience
2019-06-16 18:35:01 <_ikke_> Waiting for the build to finish
2019-06-16 18:35:11 <ddevault> it's rust, so don't hold your breath
2019-06-16 18:35:57 <_ikke_> No, I won't :)
2019-06-16 18:42:59 <_ikke_> ddevault: does this look reasonable? http://tpaste.us/M57D
2019-06-16 18:43:23 <ddevault> yes
2019-06-16 18:43:33 <_ikke_> nice
2019-06-16 18:44:13 <ddevault> thanks!
2019-06-16 19:07:44 <_ikke_> It now passed
2019-06-16 19:49:21 <jwh> hmph
2019-06-16 19:49:31 <jwh> anyone familiar with the bootstrap script?
2019-06-16 19:49:56 <jwh> just cannot convince it to produce a toolchain that runs on mips64r2
2019-06-16 19:51:31 <jwh> or anything, really
2019-06-16 21:32:22 <jwh> ah hm
2019-06-16 21:33:18 <SpaceToast> jwh: ddevault bootstrapped risc-v and I think this is the blog post about it: https://drewdevault.com/2018/12/20/Porting-Alpine-Linux-to-RISC-V.html
2019-06-16 21:33:46 <ddevault> it doesn't work without a significant amount of munging in my experience
2019-06-16 21:34:04 <ddevault> but it is helpful for getting close
2019-06-16 21:34:19 <jwh> the problem in this case is its producing nonsense defaults
2019-06-16 21:34:31 <jwh> (mips3 target when it should be mips64 isa)
2019-06-16 21:34:42 <jwh> which rules out like 99% of available platforms
2019-06-16 21:34:57 <jwh> fixed, but it's gonna take some time :(
2019-06-16 21:34:59 <ddevault> bootstrapping a new architecture is not a turnkey process
2019-06-16 21:35:01 <jwh> qemu will emulate it
2019-06-16 21:35:16 <jwh> so I'm gonna have to rebuild on x86 with binfmt
2019-06-16 21:35:19 <ddevault> it took me more than a month to get a self-hosting alpine install on riscv64 from scratch
2019-06-16 21:35:25 <jwh> yeah
2019-06-16 21:35:30 <jwh> most of the work is done
2019-06-16 21:35:32 <jwh> it's just not correct
2019-06-16 21:35:46 <jwh> easy fix, *long* time to rebuild as I don't have any really fast hardware
2019-06-16 21:36:01 <ddevault> are you not cross-compiling during the bootstrap?
2019-06-16 21:36:33 <jwh> I have a working sysroot
2019-06-16 21:36:56 <jwh> it takes some time
2019-06-16 21:37:14 <jwh> I really need a faster machine
2019-06-16 21:37:28 <ddevault> I might be able to hook you up with something to build on
2019-06-16 21:37:36 <ddevault> what's the /proc/cpuinfo for the builder you're using now?
2019-06-16 21:38:08 <jwh> model name      : Intel(R) Atom(TM) CPU  Z3735F @ 1.33GHz
2019-06-16 21:38:08 <jwh> :D
2019-06-16 21:38:14 <jwh> 2c 2t
2019-06-16 21:39:09 <jwh> i think it's mostly done though, so once I have a minirootfs built now that I've fixed target isa, I can get it running natively on mips64 hardware
2019-06-16 21:39:40 <jwh> saved an incredible amount of time just by not building go
2019-06-16 21:39:41 <jwh> heh
2019-06-16 21:39:43 <ddevault> haha
2019-06-16 21:39:44 <Cogitri> Oh wew, that's slow indeed
2019-06-16 21:40:07 <ddevault> well, if you want, I can get you 8 cores of AMD EPYC
2019-06-16 21:40:13 <jwh> yeah, it's not so bad for native building, but as qemu is emulating another archiecture it's pretty bad
2019-06-16 21:40:31 <ddevault> but I agree that getting to native builds ASAP is generally the nicest route
2019-06-16 21:40:41 <jwh> that would be pretty cool
2019-06-16 21:40:52 <jwh> yeah, I've got a bunch of octeons I can build natively on
2019-06-16 21:41:35 <jwh> need to figure out why stripping is hanging during abuild now
2019-06-16 21:43:32 <ddevault> shoot me your SSH pubkey and I'll rig up a box for you
2019-06-16 22:05:38 <ddevault> jwh: you should be ready to go at jwh@173.195.146.153
2019-06-16 22:05:42 <ddevault> become root with doas
2019-06-16 22:05:47 <ddevault> alpine-sdk is installed and you're in the abuild group
2019-06-16 22:05:51 <ddevault> glhf, be good
2019-06-16 22:05:56 <jwh> awesome, thanks
2019-06-16 22:06:12 <ddevault> remind me when you're done with it to tear down the VM, please
2019-06-16 22:06:22 <jwh> will do, hopefully won't be too long
2019-06-16 22:16:01 <jwh> much faster, lol
2019-06-16 22:20:16 <ddevault> 4x the cores on a top-of-the-line CPU tends to be ;)
2019-06-16 22:21:13 <jwh> I ditched all my big boxes and replaced them with a bunch of small ones... nice and quiet but not at all useful for compiling
2019-06-16 22:21:49 <ddevault> this host is extremely loud, and sitting in a rack with 6 other extremely loud hosts, in a datacenter several miles away where I cannot hear it
2019-06-16 22:21:57 <jwh> hehe
2019-06-16 22:22:59 <PureTryOut[m]> ddevault: you did the RISC-V port of Alpine right? Any plan of upstreaming to Alpine in the future? 😃
2019-06-16 22:23:19 <ddevault> currently upstreaming the musl port, which should land in the next release
2019-06-16 22:23:31 <ddevault> the alpine port isn't entirely ready, though much of it is working
2019-06-16 22:23:50 <ddevault> also, my riscv box is tied up, the go team is using it to test their port
2019-06-16 22:23:59 <PureTryOut[m]> Awesome
2019-06-16 22:24:18 <ddevault> I'll get back to it soon, though, want to mess around with better booting solutions
2019-06-16 22:24:29 <ddevault> if you feel like debugging textrel issues though please tell me so
2019-06-16 22:25:42 <PureTryOut[m]> I don't have RISC-V hardware sorry, just interested in the status of it
2019-06-16 22:25:50 <ddevault> I would give you a shell account if you are
2019-06-16 22:26:46 <PureTryOut[m]> I'm probably not the right person for the job sorry 😉
2019-06-16 22:26:49 <ddevault> okay :)
2019-06-16 22:28:47 <PureTryOut[m]> Just thank you for the work you're putting into it. Well, and all the other awesome work you do. It was good meeting you at FOSDEM :D
2019-06-16 22:29:46 <ddevault> thanks, it's a team effort on all counts
2019-06-16 22:50:00 <jwh> hmph
2019-06-16 23:42:11 <SpaceToast> danieli: hey, noticed the erlang 22 stuff got through; congrats and thanks! :D
2019-06-16 23:42:23 <jwh> are the builders in a git repo somewhere? or is there something else that can rebuild packages and dependencies when aports.git is updated?
2019-06-17 00:01:29 <danieli> SpaceToast: :)
2019-06-17 01:37:14 <jwh> dum de dum
2019-06-17 01:37:23 <jwh> maybe sometimes this week I'll get alpine on my mips64 boxes :D
2019-06-17 01:38:01 <jwh> need to build a kernel first anyway, sigh
2019-06-17 03:48:49 <oninoshiko__> how close is that testing/proj4 rename to testing/proj to being ready?
2019-06-17 04:17:51 <danieli> i'd assume it's further down the list of priorities than things like releasing 3.10
2019-06-17 04:49:18 <_ikke_> 3.10 release is planned today
2019-06-17 06:35:40 <hjaekel> oninoshiko, proj4 -> proj rename is ready, at least I resolved all issues from the review
2019-06-17 07:13:56 <mps> main/haproxy version 2.0.0 is released, it will be their LTS
2019-06-17 07:14:15 <ncopa> morning
2019-06-17 07:14:33 <mps> good morning
2019-06-17 07:14:40 <ncopa> do we dare to upgrade haproxy?
2019-06-17 07:15:26 <mps> not sure, I built it last night on x86_64, armv7 and aarch64
2019-06-17 07:15:43 <ncopa> can you also give it a teset spin?
2019-06-17 07:15:46 <ncopa> test*
2019-06-17 07:15:54 <ncopa> just to make sure its not ocmpletely broken
2019-06-17 07:16:02 <ncopa> is it backwards compat?
2019-06-17 07:16:05 <ncopa> if people upgrade
2019-06-17 07:16:06 <ncopa> etc
2019-06-17 07:16:30 <ncopa> what we want to avoid is that it breaks for half of users
2019-06-17 07:16:33 <ncopa> and works for half
2019-06-17 07:16:33 <mps> main change is target linux2628 is deprecated
2019-06-17 07:16:58 <ncopa> so we end up in a situation where we cannot revert back to 1.9 without breaking for the other half
2019-06-17 07:17:04 <mps> I can try in real server if it work
2019-06-17 07:17:41 <danieli> morning
2019-06-17 07:18:27 <mps> main change for building, I mean
2019-06-17 07:22:06 <_ikke_> morning
2019-06-17 07:33:34 <mps> ncopa: have you looked to llvm7.1 upgrade I posted few days ago to tpaste
2019-06-17 07:45:50 <ncopa> mps: no, i dont think so
2019-06-17 07:48:02 <mps> we talked about upgrade and move to community, iirc. I tested build on armv7 (our current problematic arch :) ) and it passed. But you know better should we move it in this time
2019-06-17 07:48:15 <mps> if you want I can post patch again
2019-06-17 07:48:29 <ncopa> iirc i did test build it
2019-06-17 07:48:36 <ncopa> but i dont remember the result
2019-06-17 07:49:01 <mps> problem with changing to not be default, iirc
2019-06-17 07:49:12 <Cogitri> What do we need 7.x for?
2019-06-17 07:49:19 <ncopa> rust?
2019-06-17 07:49:29 <_ikke_> Doesn
2019-06-17 07:49:33 <_ikke_> Doesn't that use llvm8?
2019-06-17 07:49:43 <ncopa> :)
2019-06-17 07:49:49 <ncopa> full confusion iow
2019-06-17 07:49:52 <mps> no, ponyc I think
2019-06-17 07:50:17 <Cogitri> mps: No, that uses llvm6 right now
2019-06-17 07:50:26 <ncopa> testing/bpftrace/APKBUILD:makedepends="cmake llvm7-dev llvm7-static clang-dev clang-static
2019-06-17 07:50:29 <mps> bpftrace
2019-06-17 07:50:38 <ncopa> is the only afaics
2019-06-17 07:50:50 <mps> yes, bcc maybe also
2019-06-17 07:50:51 <Cogitri> Ah, alrighty
2019-06-17 07:50:59 <ncopa> bcc uses llvm8 now i think
2019-06-17 07:51:12 <mps> aha, then is better
2019-06-17 07:51:23 <ncopa> i think there was some problem with llvm 7.1
2019-06-17 07:51:26 <ncopa> some test that failed
2019-06-17 07:51:34 <ncopa> not sure which arch or what it was
2019-06-17 07:51:44 <ncopa> but for some reason i didnt bother mess with it
2019-06-17 07:51:48 <mps> maybe we could build bpftrace with llvm8 and remove llvm7
2019-06-17 07:51:57 <ncopa> i tried. it fails
2019-06-17 07:52:00 <_ikke_> aarch64
2019-06-17 07:52:32 <Cogitri> mps: No, LLVM isn't backwards compatible
2019-06-17 07:52:34 <ncopa> mps: do you ahve that llvm7.1 patch again?
2019-06-17 07:52:53 <ncopa> I'll give it another go
2019-06-17 07:53:04 <ncopa> we should also move it to community while at it
2019-06-17 07:53:09 <mps> ncopa: give me few minutes
2019-06-17 07:53:31 <ncopa> Cogitri: i have glib 2.60 upgrade ready now
2019-06-17 07:54:14 <Cogitri> Alright :)
2019-06-17 07:54:19 <mps> ncopa: here it is http://tpaste.us/wjR5
2019-06-17 07:54:22 <ncopa> there are two problems: meson script fails to add -lintl and meson fails to have correct order of flags in pkgconfig
2019-06-17 07:55:06 <ncopa> mps: ah! maybe it was that soname thing
2019-06-17 07:56:09 <Cogitri> ncopa: Sure that it's on meson? I think our gettext is just messed up
2019-06-17 07:56:26 <mps> I think so
2019-06-17 07:56:27 <ncopa> yes and yes
2019-06-17 07:56:27 <Cogitri> It worked just fine on all other distros I tried this on and we disable nls for lots of stuff because everything explodes otherwise
2019-06-17 07:56:55 <mps> just started build on aarch64 to see result
2019-06-17 07:57:08 <ncopa> the problem is that musl provides gettext, but on alpine we override it and force use gnu gettext (for now)
2019-06-17 07:57:44 <ncopa> meson script will use the gettext headers, but not add -lintl due to meson script not think its needed
2019-06-17 07:58:05 <ncopa> there is a comment saying that it should search for "broken" gettext implementations
2019-06-17 07:58:26 <ncopa> i can comment that out to force add -lintl
2019-06-17 07:58:45 <ncopa> but when guild with static qemu it fails with same missing symbol error
2019-06-17 07:58:58 <Cogitri> Huh, alright
2019-06-17 07:59:17 <ncopa> and re-ordering the Libs: in pkg-config solves it
2019-06-17 07:59:19 <Cogitri> <ncopa "but when guild with static qemu "> That won't work anyway due to meson not working with internal static libs
2019-06-17 07:59:38 <Cogitri> BTW, can we solve https://bugs.alpinelinux.org/issues/7374 for 3.10?
2019-06-17 07:59:58 <ncopa> i think that the problem was that we use --as-needed
2019-06-17 08:00:17 <ncopa> so the linker will remove our -lintl because it cannot find anything using it
2019-06-17 08:00:25 <ncopa> thats my theory at least
2019-06-17 08:00:37 <ncopa> moving -lintl to the end makes it work
2019-06-17 08:00:47 <Cogitri> <Cogitri "BTW, can we solve https://bugs.a"> Some software (*shakes fist at gnome-terminal*) doesn't understand that we actually _do_ support UTF-8 otherwise and just flat out refuse to start
2019-06-17 08:01:25 <Cogitri> Hm, I can give it a look
2019-06-17 08:01:34 <ncopa> i am pushing the workarounds
2019-06-17 08:01:41 <ncopa> and i got it working
2019-06-17 08:01:47 <ncopa> but it should be reported upstream
2019-06-17 08:01:58 <ncopa> i would appreciate if you could help me with that
2019-06-17 08:02:30 <Cogitri> Sure thing, I can do that
2019-06-17 08:03:27 <ncopa> pushed glib now
2019-06-17 08:03:35 <mps> Cogitri: my LANG is en_US.UTF-8 for long time, even forgot about this
2019-06-17 08:03:59 <Cogitri> Yup, most people just set it themselves, but it's broken by default
2019-06-17 08:04:00 <Cogitri> Which sucks
2019-06-17 08:04:30 <mps> true, could be changed to C.UTF-8 by default
2019-06-17 08:05:13 <ncopa> Cogitri: patch is welcome for that. its in main/alpine-baselayout/profile
2019-06-17 08:05:44 <ncopa> as i unsderstand we need to replace CHARSET=UTF-8 with LANG=C.UTF-8?
2019-06-17 08:05:58 <ncopa> isnt LANG=C.UTF-8 the default?
2019-06-17 08:06:01 <Cogitri> Not sure about replacing
2019-06-17 08:06:10 <Cogitri> But it certainly needs to be added
2019-06-17 08:06:11 <mps> iirc, dalias told that the C.UTF-8 proper one
2019-06-17 08:06:34 <ncopa> so we need to add LANG=C.UTF-8?
2019-06-17 08:06:37 <Cogitri> <ncopa "isnt LANG=C.UTF-8 the default?"> It implicitly is the default, but some applications don't check if UTF-8 works and instead just check for $LANG
2019-06-17 08:06:40 <Cogitri> <ncopa "so we need to add LANG=C.UTF-8?"> Exactly
2019-06-17 08:07:43 <ncopa> another issue i have is gtk's first weekday
2019-06-17 08:07:55 <ncopa> i want to set it that monday is first weekday
2019-06-17 08:08:14 <ncopa> but according sources, that needs to come from locale (libc) or translation
2019-06-17 08:08:42 <ncopa> but i want use english
2019-06-17 08:09:06 <danieli> iirc there's LC_TIME
2019-06-17 08:09:59 <ncopa> export LC_TIME=en_GB.UTF-8
2019-06-17 08:10:03 <ncopa> is what i use
2019-06-17 08:10:16 <ncopa> maybe sunday is first day in week in GB too?
2019-06-17 08:10:31 <danieli> i believe it only differs in US, CA, JP
2019-06-17 08:11:00 <danieli> but yeah, i'm not sure how any of this would work in alpine/on musl
2019-06-17 08:11:18 <ncopa> mps: i got this when trying to build llvm 7.1:
2019-06-17 08:11:21 <ncopa> Traceback (most recent call last):
2019-06-17 08:11:21 <ncopa>   File "../utils/lit/setup.py", line 4, in <module>
2019-06-17 08:11:21 <ncopa>     from setuptools import setup, find_packages
2019-06-17 08:11:21 <ncopa> ImportError: cannot import name 'setup' from 'setuptools' (unknown location)
2019-06-17 08:11:33 <mps> on aarch64?
2019-06-17 08:13:02 <ncopa> armv7
2019-06-17 08:13:06 <mps> it is still building on 'my' aarch64 lxc
2019-06-17 08:13:53 <mps> I will wait if it finish on aarch64 and then again run build on armv7 to see
2019-06-17 08:15:37 <mps> although I have it in armv7 lxc: ls -l ~/packages/main/armv7/llvm7-7.1.0-r0.apk => -rw-r--r-- 1 mps mps 2563875 Jun 12 18:19 /home/mps/packages/main/armv7/llvm7-7.1.0-r0.apk
2019-06-17 08:16:07 <ncopa> im building it on x86, ppc64le and s390x now
2019-06-17 08:16:16 <ncopa> and x86_64
2019-06-17 08:17:27 <mps> I'm waiting for aarch64 to finish
2019-06-17 08:18:27 <mps> haproxy 2.0.0 works. tested it in our (my company) development machine
2019-06-17 08:19:32 <mps> although it is not much complicated setup, SSL and some public and some private CA certificates
2019-06-17 08:28:01 <mps> ncopa: llvm7.1 pass build on aarch64 lxc, now running it again on armv7
2019-06-17 08:36:26 <ncopa> build passes on x86_64 and ppc64le too
2019-06-17 08:36:43 <ncopa> and x86
2019-06-17 08:37:17 <mps> we cannot test s390x?
2019-06-17 08:37:24 <ncopa> its still building
2019-06-17 08:38:02 <mps> aha, nice. you have s390x 'box'?
2019-06-17 08:38:21 <Cogitri> ncopa: pr8827 sets LANG=C.UTF-8
2019-06-17 08:44:06 <mps> terror: did you tested haproxy 2.0.0 (alpine pkg) on alpine ? if yes, which arch and does it installs and works
2019-06-17 08:45:08 <ncopa> mps: do you have a patch for haproxy upgrade?
2019-06-17 08:45:42 <mps> will have in few minutes
2019-06-17 08:45:51 <mps> just working on it
2019-06-17 08:48:56 <Cogitri> Well, back to messing with webkit2gtk on 32-bit arches :^)
2019-06-17 08:49:27 <ncopa> I've been thinking of a setup-desktop script
2019-06-17 08:49:38 <mps> ncopa: llvm7.1 just passed 'abuild -r' again on armv7
2019-06-17 08:49:41 <ncopa> where you can pick either xfce or mate (currently
2019-06-17 08:50:00 <ncopa> or maybe just xfce4 for now
2019-06-17 08:50:27 <ncopa> it would set up a user account, sudo, and install the xfce desktop env
2019-06-17 08:53:54 <Cogitri> Hm, although I like the setup-* scripts I feel like we shouldn't overdo it
2019-06-17 08:54:07 <Cogitri> I mean what you describe are 3 commands basically
2019-06-17 08:55:51 <ncopa> i think you could set it up with 3 long commands...
2019-06-17 08:56:36 <Cogitri> `adduser`, `visudo` and `apk add xfce`, no?
2019-06-17 08:58:30 <ncopa> adduser ... -arg-for-fullname; addgroup $user wheel; visudo; setup-xorg-base xfce4 xfce-polkit xfce4-screensaver xfce4-terminal consolekit2 lightdm-gtk-greeter $browser $some-nice-icons
2019-06-17 08:59:16 <ncopa> idea is to have a nice default desktop setup
2019-06-17 09:00:01 <Cogitri> Oh, I'd personally opt for a xfce metapackage that includes these packages then though
2019-06-17 09:00:56 <Cogitri> I mean I don't want to block on this, but IMHO a metapackage which gives you a "nice default desktop" would be nice (which can them be installed by a setup-* script of course :)
2019-06-17 09:01:27 <ncopa> the problem with using depends for that is that it makes it harder to replace components
2019-06-17 09:01:44 <ncopa> you cannot remove components if its a hard dep
2019-06-17 09:02:34 <Cogitri> Oh, true that
2019-06-17 09:02:59 <Cogitri> Well, I guess I got a bit too used to GNOME where replacing components isn't a thing :)
2019-06-17 09:04:00 <ncopa> :)
2019-06-17 09:04:16 <mps> ncopa: haproxy patch is here http://tpaste.us/aRyE - tested build on x86, x86_64, aarch64 and armv7
2019-06-17 09:05:04 <ncopa> also the idea was to have a question like: "which desktop env would you like? (xfce,i3,mate,gnome) [xfce]: "
2019-06-17 09:05:31 <mps> 
ACTION prefer awesome WM

2019-06-17 09:05:46 <danieli> preferences are like butts, everyone has one
2019-06-17 09:05:54 <Cogitri> Yup, that'd be nice, ncopa
2019-06-17 09:05:55 <ncopa> *shrug* the idea was that it gives you a few options
2019-06-17 09:06:06 <ncopa> but we need to start some place
2019-06-17 09:06:07 <Cogitri> danieli: lol
2019-06-17 09:06:10 <_ikke_> mps: me too :)
2019-06-17 09:06:14 <mps> danieli: right, and no one see it's :)
2019-06-17 09:06:29 <Cogitri> Yeah, WMs aren't my cup of tea I guess :)
2019-06-17 09:06:48 <danieli> +1, suggesting desktop environments/window managers and setting them up for the user would be nice, things break once in a while
2019-06-17 09:06:54 <danieli> Cogitri: everyone uses one though :P
2019-06-17 09:07:27 <Cogitri> Well, yes, but bare WMs then :)
2019-06-17 09:11:26 <terror> mps just had a quick chat with haproxy upstream. They recommend to use TARGET=Alpine and define all the USE_* that we might want. We could use all the ones linux-glibc enables by default but make it explicit.
2019-06-17 09:12:53 <mps> terror: I just posted patch to http://tpaste.us/aRyE
2019-06-17 09:13:35 <mps> there I put TARGET=linux-glibc
2019-06-17 09:13:54 <terror> cool!
2019-06-17 09:14:23 <mps> it builds on few arch's and I'm testing it on one of our company development box
2019-06-17 09:14:37 <mps> till now, didn't noticed any problem
2019-06-17 09:16:45 <mps> maybe we can go with this target (linux-glibc) and later with your help, get proper musl support upstream
2019-06-17 09:17:15 <ncopa> mps: that sounds like a good plan
2019-06-17 09:17:50 <ncopa> terror: would be great if you could help us get proper upstream support
2019-06-17 09:18:32 <terror> I asked, they say "if musl becomes more popular" which doesn't sound too promising
2019-06-17 09:18:40 <ncopa> er....
2019-06-17 09:18:55 <ncopa> there are like 10M+ docker pulls
2019-06-17 09:19:22 <terror> Hey, you are preaching to the choir. I've been using alpine since 2014
2019-06-17 09:19:36 <ncopa> what they consider "popular"?
2019-06-17 09:19:46 <ncopa> 100+ million downloads?
2019-06-17 09:20:36 <mps> we can also add fake dl counter somewhere :D
2019-06-17 09:23:10 <ncopa> terror: tell them that on docker hub alpine is more popular than haproxy
2019-06-17 09:23:50 <ncopa> haproxy has 1.2K stars. alpine has 5.4K. Alpine is 4.5 times more popular than haproxy
2019-06-17 09:24:08 <Cogitri> mps: Is there a reason for xvfb-run to not be in main/ ?
2019-06-17 09:24:39 <ncopa> Cogitri: i dont think there are any good reason
2019-06-17 09:24:48 <terror> ncopa I guess at the end of the day it's just a convenience, since all the knobs are exposed anyway.
2019-06-17 09:24:54 <mps> Cogitri: I cannot move it there, that is :)
2019-06-17 09:25:01 <Cogitri> Oh :)
2019-06-17 09:25:23 <Cogitri> I guess I'll make a PR for the move then, would be nice to enable more tests in main/ too :P
2019-06-17 09:25:35 <mps> agree
2019-06-17 09:25:36 <ncopa> Cogitri: just be careful of introducing circular deps
2019-06-17 09:26:07 <Cogitri> Yup
2019-06-17 09:29:04 <mps> I have to prepare for afternoon exam, but will be around in case I can help something
2019-06-17 09:30:22 <Cogitri> Good luck :)
2019-06-17 09:30:45 <mps> Cogitri: heh, I'm examiner ;)
2019-06-17 09:31:21 <Cogitri> Oh hehe
2019-06-17 09:31:46 <_ikke_> I gather mps quite of age
2019-06-17 09:31:56 <_ikke_> s/mps/mps is/
2019-06-17 09:31:56 <alpine-meetbot> _ikke_ meant to say: I gather mps is quite of age
2019-06-17 09:36:36 <mps> _ikke_: true, but not feel as such
2019-06-17 09:36:50 <_ikke_> hehe :)
2019-06-17 09:59:59 <PureTryOut[m]> Could somebody merge pr8792? CI fails because time limit and maximum output reached, not because of build failures. We really need it at postmarketOS and is also a requirement for Plasma Desktop on Alpine...
2019-06-17 10:04:00 <mps> and there is a series of patches on pw.a.o which upgrades mate to 1.22.1 https://patchwork.alpinelinux.org/project/aports/list/?series=508
2019-06-17 10:24:28 <ncopa> mps: do you know how I can `curl $patchworksomthing | git am` got merge a patch series from patchwork?
2019-06-17 10:25:43 <mps> ncopa: _ikke_ posted good looking script few days ago
2019-06-17 10:25:55 <_ikke_> hold on
2019-06-17 10:26:09 <_ikke_> http://tpaste.us/qKe5
2019-06-17 10:26:19 <mps> I didn't tried it yet for patch series
2019-06-17 10:27:40 <ncopa> i think thats for single patches only
2019-06-17 10:28:10 <mps> _ikke_: ^ ?
2019-06-17 10:28:17 <_ikke_> for series as well
2019-06-17 10:28:23 <_ikke_> It just uses a different id
2019-06-17 10:28:27 <_ikke_> (pws function)
2019-06-17 10:29:15 <ncopa> oh, ok
2019-06-17 10:29:25 <ncopa> i figured i can create a bundle
2019-06-17 10:29:30 <ncopa> and download it as a file
2019-06-17 10:29:40 <_ikke_> yes, also possible
2019-06-17 10:30:13 <ncopa> PureTryOut[m]: did you add fix for qtwebengine?
2019-06-17 10:30:22 <ncopa> for the sandbox problem?
2019-06-17 10:30:36 <PureTryOut[m]> I don't have a fix for that, so no
2019-06-17 10:30:42 <ncopa> ok
2019-06-17 10:32:02 <mps> _ikke_: if it has '#!/bin/sh' instead of '#!/bin/bash', but it's nice anyway
2019-06-17 10:33:53 <_ikke_> I think it can be just /bin/sh
2019-06-17 10:34:04 <_ikke_> There are no bashisms afaik
2019-06-17 10:35:02 <mps> for the test I just tried sh, and it looks like it works
2019-06-17 10:38:48 <mps> _ikke_: yes, it works. although doesn't have anything to push to test it to the end
2019-06-17 10:45:58 <ncopa> oki thinnk afer qt5 upgrade and vala i'll tag new rc
2019-06-17 10:46:31 <ncopa> might be good to fix the sec issues https://bugs.alpinelinux.org/projects/alpine/issues?fixed_version_id=133&set_filter=1&status_id=o
2019-06-17 10:46:44 <danieli> ncopa: +1
2019-06-17 10:47:28 <danieli> hm, it shows tickets marked as 'resolved' when the Status: open filter is applied
2019-06-17 10:48:17 <mps> 
ACTION tempted to risk mate upgrade to 1.22.1

2019-06-17 10:48:33 <ncopa> danieli: because they are not closed
2019-06-17 10:49:09 <danieli> at first i thought 'resolved' implies closed, but i found out it does not
2019-06-17 10:50:02 <ncopa> configure: error: could not locate rsvg-convert
2019-06-17 10:50:02 <ncopa> >>> ERROR: mate-desktop: build failed
2019-06-17 10:50:08 <ncopa> mps: ^^
2019-06-17 10:50:53 <danieli> that's interesting, i'm not seeing rsvg-convert even mentioned anywhere in aports
2019-06-17 10:51:39 <ncopa> librsvg
2019-06-17 10:51:49 <ncopa> but is it a runtime dep or buildtime dep?
2019-06-17 10:53:00 <mps> runtime, I think, but should be added to makedeps
2019-06-17 10:53:14 <danieli> why makedeps if it's a runtime dep?
2019-06-17 10:53:18 <ncopa> :)
2019-06-17 10:53:32 <ncopa> the question is basically should it be in depends on makedepends
2019-06-17 10:53:44 <mps> danieli: I mean, makedepends
2019-06-17 10:53:46 <ncopa> depends = runtime dep, makedepends = build time dep :)
2019-06-17 10:54:20 <ncopa> FAIL: check-eel
2019-06-17 10:54:30 <ncopa> caja checkdepends fails
2019-06-17 10:54:31 <ncopa> ok
2019-06-17 10:54:36 <ncopa> i dont have time to fix those
2019-06-17 10:55:10 <mps> ok, it is not worth because of this to wait for release
2019-06-17 10:56:55 <mps> mate is in good enough shape now, actually to be more precise, it was I tested it some time ago
2019-06-17 10:56:55 <Cogitri> I think we should have the new webkit2gtk in 3.10, but I can backport that, it doesn't build on 32-bit arches yet.
2019-06-17 11:52:21 <ncopa> would be nice to have mate updated and included
2019-06-17 12:01:17 <ncopa> this one too https://bugs.alpinelinux.org/issues/9555
2019-06-17 12:02:57 <mps> when you think you will make release? I could try to fix mate if you are not in hurry
2019-06-17 12:07:11 <ncopa> the idea was to make release today
2019-06-17 12:07:17 <ncopa> but i need to do new rc first
2019-06-17 12:07:30 <PureTryOut[m]> ncopa: thanks for merging Qt 5.12.4!
2019-06-17 12:07:49 <ncopa> PureTryOut[m]: yw
2019-06-17 12:08:43 <Cogitri> mps: Do you happen to have some spare CPU to test compile webkit2gtk for me? Otherwise I'll just backport it later on.
2019-06-17 12:09:22 <mps> Cogitri: will find, you mean armv7?
2019-06-17 12:09:52 <ncopa> (check-program:302): Gtk-WARNING **: 12:09:20.311: cannot open display:
2019-06-17 12:09:52 <ncopa> FAIL check-eel (exit status: 133)
2019-06-17 12:09:52 <ncopa> Trace/breakpoint trap
2019-06-17 12:10:01 <Cogitri> Yup. Gonna put the patch up in a dew minutes
2019-06-17 12:10:12 <Cogitri> ncopa: xvfb-run it is, I guess
2019-06-17 12:10:22 <mps> no need to hurry, just trying mate on it
2019-06-17 12:11:14 <_ikke_> Cogitri: sounds like xvfb-run
2019-06-17 12:11:28 <Cogitri> Okie, thanks
2019-06-17 12:11:37 <ncopa> indeed
2019-06-17 12:11:44 <ncopa> xfvb-run solved it
2019-06-17 12:11:49 <ncopa> no
2019-06-17 12:11:51 <ncopa> wait
2019-06-17 12:14:19 <ncopa> fails with (caja:744): GLib-GIO-ERROR **: 12:12:20.291: Settings schema 'org.mate.caja.preferences' is not installed
2019-06-17 12:14:33 <ncopa> i dont think tests work without caja first being installed
2019-06-17 12:14:59 <ncopa> lets skip tests for caja
2019-06-17 12:15:07 <ncopa> then i think i have mate done
2019-06-17 12:15:08 <mps> so, caja need to be built first and added to makedepends
2019-06-17 12:15:34 <mps> ah, you are working on it?
2019-06-17 12:15:41 <ncopa> im simply disabling the tests
2019-06-17 12:24:51 <mps> ok, I see you pushed mate, so I stopped
2019-06-17 12:25:11 <mps> Cogitri: when you prepare PR please inform me
2019-06-17 12:27:33 <mps> (would be nice if I can make uboot profile with mkimage.sh to test pine64 and some sunxi boards)
2019-06-17 12:28:06 <mps> i.e. https://bugs.alpinelinux.org/issues/10543
2019-06-17 12:28:49 <Cogitri> mps: pr8257 should be test-able now
2019-06-17 12:31:01 <mps> ok
2019-06-17 13:34:25 <mps> Cogitri: looks like webkit2gtk is stuck on armv7 http://tpaste.us/NK1Z
2019-06-17 13:39:53 <Cogitri> Argh, it gets stuck even with j1
2019-06-17 13:40:56 <mps> yes, make have -j1
2019-06-17 13:42:21 <mps> here is 'ps af' http://tpaste.us/xpqr
2019-06-17 13:43:48 <danieli> add `ww' to that?
2019-06-17 13:43:49 <mps> that is where it stuck, [ 45%] Building CXX object Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/llint/LowLevelInterpreter.cpp.o
2019-06-17 13:44:08 <mps> danieli: I sent full line to him already
2019-06-17 13:44:13 <danieli> oh okay
2019-06-17 13:50:46 <Cogitri> Hm, that's a different file than the one it was stuck at before though
2019-06-17 13:53:10 <[[sroracle]]> ncopa: would be nice to pull https://github.com/alpinelinux/abuild/pull/91, technically a security issue
2019-06-17 14:04:22 <mps> Cogitri: I think I should kill it, looks like it is still stuck
2019-06-17 14:05:28 <mps> community/qt5-qtwebengine pass 'abuild -r' in aarch64 lxc
2019-06-17 14:06:32 <Cogitri> mps: Hm. Alright, thanks for trying
2019-06-17 14:07:03 <mps> np, when you have something else just ping
2019-06-17 14:48:28 <Cogitri> Soo...I just talked so upstream about webkit again and their official stand is that 4gigs isn't enough to compile the thing, so we should crosscompile...but that's not exactly something we can do, can we?
2019-06-17 14:55:32 <danieli> our builders are pretty powerful
2019-06-17 14:56:13 <mps> Cogitri: lxc where I tried: 'free -m' => Mem:         128672        1894       93302           1       33475      125484
2019-06-17 14:56:16 <danieli> our x86_64 dev containers are on a box with 256G memory and 48 cores
2019-06-17 14:56:43 <danieli> the ppc64, arm, and s390x builders are pretty juicy too
2019-06-17 14:57:12 <_ikke_> armv7 builder: Mem:         128672        6055       94150           1       28466      125593
2019-06-17 14:57:17 <danieli> it will however be a showstopper for some people who wants to test the build
2019-06-17 14:58:24 <mps> well, I managed build rust on 4GB few months ago, with the help of zram swap
2019-06-17 15:00:39 <oninoshiko> hjaekel, I'm showing testing/proj(4) as not passing travis-ci/pr Looks like the build is timeing out.
2019-06-17 15:01:59 <oninoshiko> Only reasons I'm pushing on this, is because I'll probibly have to update testing/postgis for it.
2019-06-17 15:02:02 <Cogitri> danieli: Oh, thought the 32-bitness would induce a limit on that
2019-06-17 15:29:56 <maxice8> ImageMagick is failing on s390x and x86, 1 tests in each
2019-06-17 17:07:04 <hjaekel> oninoshiko, yes, travis times out after 50 mins but drone builds successfully. Also on my local machine (x86_64) it builds.
2019-06-17 17:11:42 <oninoshiko> Looks like your update actually does what mine did anyway.
2019-06-17 17:23:49 <oninoshiko> I commented on mine that we should just accept your's
2019-06-17 17:32:59 <hjaekel> you mean pr8808? I did not see that, sorry. Is there anything from your pr that I could include in my pr?
2019-06-17 17:33:29 <oninoshiko> nope, you already are doing everything pr8808 does
2019-06-17 17:34:45 <oninoshiko> I just want a working package, don't really much care who's name's on the change :)
2019-06-17 18:14:34 <ncopa> i have a workaround for imagemagick test
2019-06-17 18:14:43 <ncopa> it seems like it is due to rounding error
2019-06-17 18:14:58 <ncopa> so i think we simply drop the test
2019-06-17 18:24:17 <hjaekel> ncopa, have you tried -ffp-contract=off?
2019-06-17 19:00:47 <Cogitri> I'm somewhat inclined to just disable webkit2gtk on armv7, armhf and x86 for now and wait for 2.26 which should (hopefully) fix this by allowing non-unified builds
2019-06-17 19:52:39 <_ikke_> sanitycheck, https://bugs.alpinelinux.org/issues/10584 mentions that qutebrowser requires py3-qtwebengine. Qutebrowser depends on qt5-qtwebengine. Would it make more sense to add the dependency to qt5-qtwebengine?
2019-06-17 19:55:06 <Cogitri> No
2019-06-17 19:55:07 <Cogitri> Why would that make sense?
2019-06-17 19:55:24 <Cogitri> Not everything that requires qt5-qtwebengine is written in python
2019-06-17 19:55:36 <Cogitri> (see e.g. MellowPlayer)
2019-06-17 19:56:18 <Cogitri> I had opened a PR for that, but maxice8 already had a PR to bump qutebrowser (but it's broken in runtime anyway because QtWebengine is broken on musl >=1.22 it seems)
2019-06-17 19:56:31 <_ikke_> Ah ok, I thought it was qt5-webengine that required it
2019-06-17 19:56:37 <_ikke_> Hence me asking to confirm
2019-06-17 19:56:38 <Cogitri> So I closed mine
2019-06-17 19:57:03 <_ikke_> hmm, ok
2019-06-17 19:57:20 <_ikke_> That ticket seems to infer it is working with py3-qtwebengine
2019-06-17 19:57:46 <Cogitri> Hm, maybe that's on 3.9 then?
2019-06-17 19:57:54 <_ikke_> edge
2019-06-17 19:58:05 <_ikke_> Oh, I'm on edge, but didn't confirm it working yet with that dep
2019-06-17 19:58:13 <Cogitri> Huh, multiple people confirmed QtWebengine being broken on edge :o
2019-06-17 19:58:30 <Cogitri> Try running MellowPlayer or Nextcloudclient and see if it actually loads a page
2019-06-17 19:58:42 <Cogitri> For me (and others apparently) it crashes as soon as it finishes loading the page
2019-06-17 19:58:50 <_ikke_> ok
2019-06-17 19:59:44 <Cogitri> And it appears that QtWebengine is broken for Void too on musl
2019-06-17 20:06:28 <_ikke_> "Renderer process crashed
2019-06-17 20:06:29 <_ikke_> "
2019-06-17 20:06:33 <_ikke_> on edge
2019-06-17 20:08:28 <_ikke_> https://github.com/alpinelinux/aports/pull/8374
2019-06-17 20:09:03 <ncopa> hjaekel: no i have not tried -ffp-contract=off
2019-06-17 20:30:14 <ncopa> PR queue is going down
2019-06-17 20:30:22 <ncopa> good work everyone!
2019-06-17 20:43:40 <_ikke_> \o/
2019-06-17 20:44:13 <clandmeter> sorry, i didnt take part of the pr party.
2019-06-17 20:44:42 <clandmeter> actually i did, but thats another PR thing.
2019-06-17 21:51:08 <jwh> hey did anyone know that abuild breaks if gawk is installed?
2019-06-17 21:52:43 <jwh> hm
2019-06-17 21:53:52 <jwh> what the hell
2019-06-17 21:59:43 <jwh> well thats cute
2019-06-17 22:30:34 <ddevault> are we on top of the kernel security advisory
2019-06-17 22:30:41 <ddevault> https://www.openwall.com/lists/oss-security/2019/06/17/5
2019-06-17 22:30:53 <ddevault> cc ncopa clandmeter _ikke_
2019-06-17 23:23:44 <ddevault> I have patches for edge and 3.9 fwiw
2019-06-17 23:34:29 <PureTryOut[m]> The 3.10.0_rc5 release still doesn't include u-boot for the pine64 for some reason... Why is it not being built?
2019-06-17 23:46:23 <ddevault>  /b stew
2019-06-17 23:46:26 <ddevault> disregard
2019-06-18 04:46:55 <c705> Hello - when could one expect linux 4.19.52 in aports?
2019-06-18 04:48:55 <_ikke_> I would not expect it to take too long
2019-06-18 04:49:43 <c705> Ok thanks, CVE-2019-11477 looks nasty
2019-06-18 04:51:08 <_ikke_> remote kernel panick
2019-06-18 04:52:08 <c705> Haven't heard of anything in the wild yet but I expect to soon
2019-06-18 05:02:20 <danieli> i've heard some chatter about it from friends in high places, but haven't seen it in the wild myself yetr
2019-06-18 05:02:21 <danieli> yet*
2019-06-18 05:03:45 <c705> sudo sh -c ' echo "0" > /proc/sys/net/ipv4/tcp_sack' # if you're paranoid :-)
2019-06-18 05:04:24 <SpaceToast> or better yet, `echo 0 | sudo tee /proc/sys/net/ipv4/tcp_sack` :)
2019-06-18 05:04:33 <danieli> ^ this
2019-06-18 05:04:33 <SpaceToast> no subshell!
2019-06-18 05:04:38 <danieli> already did that on a couple of hosts
2019-06-18 05:04:57 <c705> But I like subshells ):
2019-06-18 05:06:04 <c705> I'd rather run sh as root than tee, both being very low risks of any nasty business
2019-06-18 05:14:23 <_ikke_> I'd rather run tee as root then sh..
2019-06-18 05:15:03 <c705> On second thought, I agree
2019-06-18 05:15:42 <danieli> `sh' is way more powerful/dangerous/versatile than `tee'
2019-06-18 05:55:30 <ncopa> morning
2019-06-18 05:56:26 <ncopa> I suppose I need to spend the day on backporting kernel fixes?
2019-06-18 06:17:24 <danieli> morning
2019-06-18 06:25:37 <terror> ncopa it sounds like you are right
2019-06-18 07:40:22 <_ikke_> ncopa: ddevault says he already has some patches
2019-06-18 07:41:22 <_ikke_> gregkh has also released patched versions of supported kernels
2019-06-18 07:42:39 <_ikke_> ncopa: https://www.openwall.com/lists/oss-security/2019/06/17/6
2019-06-18 07:44:31 <_ikke_> 3.9: 4.19.41 -> 4.19-52
2019-06-18 07:44:52 <_ikke_> 3.8: 4.14.104 -> 4.14.127
2019-06-18 07:45:29 <_ikke_> 3.7: 4.9.161 -> 4.9.182
2019-06-18 08:53:45 <mps> PureTryOut[m]: yes, pine64 u-boot missing also in rc5
2019-06-18 08:54:35 <mps> did you tried to build tarball locally on some of your boxes
2019-06-18 08:55:28 <mps> mkimage.sh for me still doesn't work, or I don't know how to use it
2019-06-18 09:16:08 <PureTryOut[m]> I don't know how to use that script tbh
2019-06-18 09:43:30 <mps> ncopa: do you have some time to tell me in few words how do you use mkimage.sh to build uboot profiles. do you have something special in your environment or you use plaid edge?
2019-06-18 09:54:42 <Cogitri> Are our x86 builders actually x86 machines or x86_64 ones which run a 32-bit userland?
2019-06-18 09:54:51 <_ikke_> the latter
2019-06-18 09:55:21 <Cogitri> Good
2019-06-18 09:55:29 <Cogitri> Thanks for the info :)
2019-06-18 09:55:35 <_ikke_> The host is running x86_64
2019-06-18 12:05:50 <tmhoang> anyone knows if Sasha Gerrand (github.com/sgerrand) is active in any Alpine channel ?
2019-06-18 12:35:28 <E-werd> good to see someone posted about the TCP issue.  here's another link: https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md
2019-06-18 12:35:42 <E-werd> some mitigations as well
2019-06-18 13:20:54 <ddevault> I do have a couple of patches if you need them, ncopa
2019-06-18 13:20:58 <ddevault> morning
2019-06-18 13:21:17 <ncopa> hi
2019-06-18 13:21:38 <ncopa> patches for?
2019-06-18 13:21:43 <ddevault> linux-vanilla
2019-06-18 13:22:03 <ncopa> what git branch and arch?
2019-06-18 13:22:03 <ddevault> 3.9 and edge
2019-06-18 13:22:11 <ncopa> i already pushed those
2019-06-18 13:22:20 <ddevault> mk
2019-06-18 13:22:56 <ncopa> thanks though
2019-06-18 13:45:51 <tmhoang> do we want another rc ?
2019-06-18 13:57:42 <PureTryOut[m]> If that one will include the Pine64 u-boot image, then yes
2019-06-18 14:06:57 <_ikke_> We first need to figure out why it's missing in the first place
2019-06-18 14:17:06 <mps> suspect is  mkimg.arm.sh, look line 127 note #FIXME
2019-06-18 16:05:08 <_ikke_> ^ Just something that's left commented in the conifig
2019-06-18 16:05:10 <_ikke_> config*
2019-06-18 16:18:00 <gtbuchanan> I've been messing around with using minirootfs as a base for lxc with s6. However, IPv4 connectivity doesn't seem to work by default (not setting IP on interface). I was able to get it working by copying /usr/share/udhcpc/default.script from the main alpine lxc image. Is there a reason this default config isn't included in this version?
2019-06-18 16:38:27 <ncopa> gtbuchanan: the minirootfs has mostly been used for docker images and chroots, which neither needs dhcp
2019-06-18 16:39:02 <ncopa> and /usr/share/udhcpc/default.script is owned by busybox-initscripts-3.1-r4
2019-06-18 16:39:11 <ncopa> hm
2019-06-18 16:39:31 <ncopa> i think it may make sense to have that file in main busybox package rather than the busybox-initscripts
2019-06-18 16:40:48 <gtbuchanan> I had a feeling it was mostly used for Docker. I was just seeing if I could get a similar setup in lxc with s6-overlay in Proxmox like people have started doing with Docker. The default lxc alpine image includes openrc which isn't really necessary with s6.
2019-06-18 16:42:11 <gtbuchanan> I just found it busybox-initscripts right when you said that lol I was just going to wget it in my image build process, but it would be great if it could be included in the base image
2019-06-18 16:43:46 <gtbuchanan> Just wanted to check if it was something you were willing to do before I created a ticket
2019-06-18 16:44:36 <oninoshiko> Thanks for getting pr8814 in. It's resloved my postgis issue!
2019-06-18 17:57:58 <_ikke_> maxice8: I see a lot of red :P
2019-06-18 17:59:22 <_ikke_> pytest-cov is failing
2019-06-18 18:53:55 <ncopa> i know why pine u-boot does not work 21aad5d3185cd9b8509fb3190650d5dd90d38483
2019-06-18 18:54:13 <ncopa> there was no pkgrel bump
2019-06-18 18:54:39 <_ikke_> ah, that explains
2019-06-18 18:54:52 <ncopa> the reviewer did a lousy job
2019-06-18 18:54:56 <ncopa> me :)
2019-06-18 18:55:02 <_ikke_> :D
2019-06-18 18:58:02 <_ikke_> glad that's resolved, would've been a shame to miss that
2019-06-18 18:58:11 <ncopa> im gonna tag rc6
2019-06-18 18:58:23 <ncopa> and if everything is ok i'll do 3.10 tomorrow
2019-06-18 18:58:37 <_ikke_> I'll update the release notes
2019-06-18 18:58:53 <_ikke_> anything else than the linux kernel upgrade to mention?
2019-06-18 19:00:20 <ncopa> i dont think so
2019-06-18 19:00:29 <_ikke_> k
2019-06-18 19:00:38 <ncopa> the only diff from rc5 to rc6 is kernel and pine64 support
2019-06-18 19:01:05 <_ikke_> http://tpaste.us/Q1gQ
2019-06-18 19:01:15 <tcely> Did php and other languages get mentioned?
2019-06-18 19:01:24 <_ikke_> yes
2019-06-18 19:01:25 <_ikke_> see ^
2019-06-18 19:01:43 <tcely> Yes. I saw the link after. Thanks.
2019-06-18 19:01:49 <_ikke_> ncopa: Should I push this already to www-test?
2019-06-18 19:02:35 <ncopa> _ikke_: yeah, i think thats a good idea
2019-06-18 19:02:57 <ncopa> did we test the pine64 support?
2019-06-18 19:03:00 <ncopa> i havent tested it
2019-06-18 19:03:02 <ncopa> nor ceph
2019-06-18 19:03:18 <ncopa> nor iwd
2019-06-18 19:03:29 <_ikke_> ncopa: Not yet, PureTryOut[m] wanted to test pine64 but couldn't yet
2019-06-18 19:04:00 <_ikke_> mps: did you test iwd?
2019-06-18 19:04:58 <hjaekel> _ikke_, should reference [8] and [9] be updated in your release notes?
2019-06-18 19:05:19 <ncopa> rc6 is out
2019-06-18 19:05:45 <_ikke_> hjaekel: yes, you are right, forgot that
2019-06-18 19:05:49 <_ikke_> hjaekel: thanks
2019-06-18 19:07:08 <PureTryOut[m]> oh is _rc6 out?
2019-06-18 19:07:09 <PureTryOut[m]> Ah, it's not on http://dl-cdn.alpinelinux.org/alpine/v3.10/releases/aarch64/ yet though
2019-06-18 19:07:21 <_ikke_> It's *just* tagged
2019-06-18 19:07:25 <_ikke_> so still building
2019-06-18 19:08:10 <tcely> PureTryOut[m]: that mirror has 15m delay also
2019-06-18 19:08:10 <_ikke_> ncopa: you will do the shortlog, right?
2019-06-18 19:08:37 <_ikke_> It's not even on master yet
2019-06-18 19:11:21 <PureTryOut[m]> Ah ok
2019-06-18 19:11:26 <_ikke_> Now it's on master
2019-06-18 19:11:37 <_ikke_> so should appear on the mirrors soon
2019-06-18 19:13:04 <tcely> Is this link supposed to work? http://dup.pw/alpine-mksite/fcb0c82c
2019-06-18 19:14:04 <_ikke_> I think alpine-mksite is not exported
2019-06-18 19:14:12 <_ikke_> not sure if on purpose or not
2019-06-18 19:18:48 <danieli> correct, it's a secret repo afaik
2019-06-18 19:19:03 <danieli> or uh, only certain users have access to it
2019-06-18 19:20:04 <maxice8> Need eyes on pr8539 pr8545 pr8547 pr8548 pr8615
2019-06-18 19:20:37 <_ikke_> danieli: funny thing is that ncopa's clone of it *is* visible
2019-06-18 19:29:32 <PureTryOut[m]> So CI is broken and can't finish pr8717, what can I do to get it merged?
2019-06-18 19:30:17 <ddevault> send a patch to the mailing list instead ;)
2019-06-18 19:30:41 <maxice8> ddevault: can't fail CI if there is none *taps head*
2019-06-18 19:31:05 <ddevault> I will have CI for mailing list patches working within a week or two, by the way
2019-06-18 19:31:08 <_ikke_> PureTryOut[m]: the 3.10 release has a bit more focus now
2019-06-18 19:31:12 <ddevault> let's get that ml migration done soon, eh
2019-06-18 19:31:52 <_ikke_> ddevault: that would be nice
2019-06-18 19:34:24 <_ikke_> PureTryOut[m]: would be nice if you could test the pine64 support
2019-06-18 19:34:42 <ddevault> I have alpine edge running on a pine64
2019-06-18 19:34:46 <ddevault> a pinebook, to be specific
2019-06-18 19:36:26 <ddevault> actually I suppose I am running it with some custom packages for mesa and such
2019-06-18 19:36:57 <_ikke_> We want to test the 3.10 release though
2019-06-18 19:43:07 <jwh> ddevault: hey, think I'm all good now you can tear that vm down :D
2019-06-18 19:46:02 <PureTryOut[m]> _ikke_: yeah planning to test pine64 support
2019-06-18 20:01:03 <mps> _ikke_: yes, I tested iwd, and iirc Cogitri tested it with networkmanager. And few people on #alpine-linux reported it works fine
2019-06-18 20:02:05 <mps> also, someone (or two people, can't remember) on #iwd channel told me that they use it on Alpine
2019-06-18 20:02:34 <mps> and one on the private mail
2019-06-18 20:04:45 <PureTryOut[m]> iwd doesn't work out of the box with networks like eduroam btw
2019-06-18 20:04:58 <PureTryOut[m]> Networks using 802.1x protection iirc
2019-06-18 20:05:22 <PureTryOut[m]> Where with networkmanager and wpa_supplicant you can just enter your username, password, any certificate you might need etc, with iwd you manually have to make a config file somewhere
2019-06-18 20:05:30 <PureTryOut[m]> It made me move back to wpa_supplicant on my current Gentoo laptop
2019-06-18 20:06:03 <mps> PureTryOut[m]: you mean EAP?
2019-06-18 20:06:17 <PureTryOut[m]> Yes
2019-06-18 20:06:40 <jwh> correct, no .1x
2019-06-18 20:06:56 <mps> current Alpine kernel doesn't support pkcs8, so eap not enabled to not make confusion for users
2019-06-18 20:07:18 <mps> and, iwd need kernel support for this
2019-06-18 20:07:46 <PureTryOut[m]> Wait, so I wouldn't be able to connect to eduroam (the network used by every university and high school in the world) with Alpine Linux currently?
2019-06-18 20:08:24 <jwh> wpa_supplicant doesn't need any kernel support afaik
2019-06-18 20:08:39 <mps> I searched pkcs8 patch for 4.19.x kernel but didn't found anything which could be used
2019-06-18 20:10:19 <jwh> if iwd relies on kernel functionlity thats just stupid, but I am not surprised at all that anything that group of people creates sucks
2019-06-18 20:10:25 <jwh> see: bluez
2019-06-18 20:12:20 <mps> yes, "if the people creates something how I don't like it sucks" :)
2019-06-18 20:12:46 <jwh> no, it actually sucks
2019-06-18 20:13:43 <jwh> deprecating functionality that is still used without replacing it with something else, completely following the standard wrong, totally breaking existing APIs without replacements
2019-06-18 20:13:47 <jwh> etc
2019-06-18 20:14:17 <jwh> I don't expect iwd to be any less terrible, they've only done the easy stuff so far
2019-06-18 20:14:30 <danieli> come on, be civil
2019-06-18 20:14:44 <danieli> if people want to use software you think is bad, let them shoot themselves in the foot
2019-06-18 20:14:51 <jwh> that and the guy that creates it is just nuts
2019-06-18 20:15:03 <jwh> all sorts of grandiose claims that have no hint of truth in them
2019-06-18 20:15:05 <danieli> everything you've said can be said about a lot of different things
2019-06-18 20:15:17 <jwh> sure, but that doesn't excuse it
2019-06-18 20:15:59 <jwh> making mistakes is fine
2019-06-18 20:17:48 <jwh> also I'm being incredibly civil :D
2019-06-18 20:34:44 <ddevault> jwh: cool
2019-06-18 20:34:52 <jwh> o/
2019-06-18 20:34:53 <jwh> thanks
2019-06-18 20:35:11 <ddevault> happy to help
2019-06-18 20:52:19 <terror> jwh: what do you think of systemd?
2019-06-18 20:52:22 <terror> JK!!!
2019-06-18 20:55:23 <jwh> love it!
2019-06-18 21:07:28 <terror> :D
2019-06-18 21:10:52 <PureTryOut[m]> hard-wrap at 80 colums for APKBUILDs is a requirement?
2019-06-18 21:11:07 <maxice8> See the hyperlinked comment by ikke
2019-06-18 21:13:46 <PureTryOut[m]> Oh it's a link
2019-06-18 21:14:01 <PureTryOut[m]> Ok fair, although I prefer not to lol
2019-06-18 22:19:19 <TBK[m]> Regarding the release note, should be mention that we are in the process of removing py2?
2019-06-18 22:20:07 <maxice8> That would be nice
2019-06-18 22:20:09 <PureTryOut[m]> Oh yes please
2019-06-18 22:24:40 <danieli> erlang 22 is a major change as well, not sure if it warrants a honorable mention though
2019-06-18 22:25:17 <SpaceToast> I think all language runtime/sdk major version bumps should probably be mentioned
2019-06-18 22:25:26 <SpaceToast> it's very important information for developers
2019-06-18 22:26:24 <TBK[m]> In my opinion all language upgrades should be mentioned by default.
2019-06-18 22:26:40 <SpaceToast> well I don't think a bump from py3.7.0 to 3.7.1 is too important
2019-06-18 22:26:50 <SpaceToast> but 3.6 to 3.7 probably should
2019-06-18 22:26:55 <SpaceToast> (semver! it's useful :) )
2019-06-18 22:30:08 <danieli> not a valid comparison by some standards, but point taken
2019-06-18 22:32:27 <TBK[m]> do we have a list of the langs we currently support?
2019-06-18 22:36:58 <danieli> define 'we'
2019-06-18 22:37:03 <danieli> and define 'support'
2019-06-18 22:38:02 <TBK[m]> programming languages that are packaged. we = community, support = packaged
2019-06-18 22:38:34 <danieli> we don't really categorize packages very well @ pkgs.a.o or in package metadata, so i'm not so sure we have a list
2019-06-18 22:38:38 <danieli> i can compose one tomorrow
2019-06-18 22:43:04 <mps> danieli: if the big numbers are good for Alpine I can move gforth to community :)
2019-06-18 22:51:18 <TBK[m]> danieli: thanks
2019-06-18 23:32:16 <PureTryOut[m]> maxice8: I left a question in the comments of pr8871, did you read it?
2019-06-18 23:32:23 <PureTryOut[m]> s/comments/description/g
2019-06-18 23:32:23 <alpine-meetbot> PureTryOut[m] meant to say: maxice8: I left a question in the description of pr8871, did you read it?
2019-06-18 23:33:19 <maxice8> Yes
2019-06-18 23:33:51 <PureTryOut[m]> Well, do you have an answer? 😛
2019-06-18 23:36:52 <maxice8> Yes, i decided to keep as is
2019-06-18 23:37:24 <PureTryOut[m]> Oh, ok I guess
2019-06-18 23:38:18 <SpaceToast> PureTryOut[m]: it would be nice to have a list of supported backends/frontends
2019-06-18 23:39:08 <PureTryOut[m]> For Ark? Well the supported backends are all in `$depends` atm
2019-06-18 23:39:51 <SpaceToast> so tar support (for example) is just built-in?
2019-06-18 23:40:11 <SpaceToast> how about gzip, lzip, xz?
2019-06-18 23:40:33 <PureTryOut[m]> All built-in, by libarchive-dev, xz-dev, etc
2019-06-18 23:40:41 <SpaceToast> ah, ok
2019-06-18 23:40:45 <PureTryOut[m]> The depends stuff is just runtime dependencies, it needs their executables
2019-06-18 23:41:32 <mps> I had a hope that Alpine shouldn't follow so called 'dependency hell' of some other distro's
2019-06-18 23:50:46 <PureTryOut[m]> I'm not sure what you mean?
2019-06-18 23:52:15 <maxice8> PureTryOut: Are there any PRs that don't depend on the one that has a few broken packages (pr8860) ?
2019-06-18 23:53:40 <PureTryOut[m]> pr8868, pr8880
2019-06-18 23:54:51 <PureTryOut[m]> Also, pr8860 should just need a restart of the CI
2019-06-18 23:55:04 <PureTryOut[m]> the CI was going midway through the KDE Frameworks update which seem to have messed it up
2019-06-19 03:54:48 <Geod24_> Hi there. I was wondering whether there was either a plan or a blocker to update the gcc package to GCC-9 ? Wanted to add some D packages but there is no D compiler, and GCC-9 includes GDC so that saves quite a bit of bootstrapping work.
2019-06-19 03:55:25 <SpaceToast> it was decided to wait until 3.10 is out to start work on upgrading gcc to 9
2019-06-19 03:55:36 <SpaceToast> if everything goes well, 3.10 should get released today (from rc6)
2019-06-19 03:57:01 <Geod24_> Lucky me :) So GCC-9 would come in 3.11 earliest, which IIUC will be released 6 months after 3.10 ?
2019-06-19 03:57:41 <SpaceToast> yup, more or less
2019-06-19 03:57:49 <SpaceToast> you can always be like me and run edge, but do expect things to brak
2019-06-19 04:00:31 <Geod24_> Sounds like the good option. apk package index is just a bunch of text file, right ? So if I were to use the day tag on Docker (e.g. 20190619) could I expect some stability ?
2019-06-19 04:01:31 <SpaceToast> can't really say much on that front, sorry
2019-06-19 04:01:37 <SpaceToast> I base my personal images off of :edge though
2019-06-19 04:05:33 <Geod24_> Thanks for the info. The plans for GCC was my main concern. I'll just wait for the update then, and will try to figure out a way to make it stable-ish.
2019-06-19 06:36:20 <_ikke_> morning
2019-06-19 06:38:29 <clandmeter> Morning
2019-06-19 07:17:52 <ncopa> morning
2019-06-19 07:19:47 <_ikke_> Are we ready for 3.10?
2019-06-19 07:28:30 <ncopa> i think so
2019-06-19 07:29:45 <ncopa> https://www.mozilla.org/en-US/security/advisories/mfsa2019-18/
2019-06-19 07:29:50 <ncopa> should probably fix that first
2019-06-19 07:29:52 <_ikke_> Yes, read about it
2019-06-19 07:30:33 <_ikke_> firefox-esr -> 60.7.1
2019-06-19 07:30:54 <fcolista> firefox-esr does not work in 3.10
2019-06-19 07:31:23 <_ikke_> firefox -> 67.0.3
2019-06-19 07:32:11 <fcolista> I'm using 3.10 repo
2019-06-19 07:32:12 <ncopa> fcolista: whats the problem?
2019-06-19 07:32:21 <fcolista> it's remains as a zombie
2019-06-19 07:32:33 <fcolista> firefox and firefox-esr
2019-06-19 07:32:38 <fcolista> got this error:
2019-06-19 07:32:38 <fcolista> [  183.051065] gcr-prompter[4827]: segfault at 8 ip 00007f3467fe7323 sp 00007ffe5b473110 error 4 in libgcr-base-3.so.1.0.0[7f3467fcf000+3d000]
2019-06-19 07:32:39 <fcolista> [  183.051076] Code: e8 32 9e fe ff 48 8b 43 18 48 8b 74 24 08 48 8d 4c 24 10 48 8d 54 24 08 48 8b 78 20 e8 16 ab fe ff 48 8b 74 24 08 85 c0 75 24 <4c> 8b 46 08 48 8b 0e 48 8d 15 24 ac 02 00 be 80 00 00 00 48 8d 3d
2019-06-19 07:32:45 <ncopa> which arch?
2019-06-19 07:32:48 <ncopa> x86_64?
2019-06-19 07:32:51 <fcolista> yes
2019-06-19 07:35:48 <_ikke_> firefox seems to work for me under qemu
2019-06-19 07:37:56 <_ikke_> firefox-esr even
2019-06-19 07:38:58 <_ikke_> https://imgur.com/a/o9gYibG
2019-06-19 07:41:25 <_ikke_> Perhaps only under gnome?
2019-06-19 07:48:51 <ncopa> i installed rc6 in a qemu
2019-06-19 07:48:59 <ncopa> and firefox-esr works for me
2019-06-19 07:49:41 <_ikke_> Yes, for me as well
2019-06-19 07:49:55 <_ikke_> but it refers to gcr-prompter, which seems to be gnome related?
2019-06-19 08:14:47 <fcolista> I'm using mate
2019-06-19 08:29:25 <fcolista> connect(7, {sa_family=AF_UNIX, sun_path=@"/tmp/.ICE-unix/4162"}, 22) = 0
2019-06-19 08:29:25 <fcolista> fcntl(7, F_SETFD, FD_CLOEXEC)           = 0
2019-06-19 08:29:25 <fcolista> read(7, 0x55a0186dbac0, 8)              = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
2019-06-19 08:29:25 <fcolista> write(7, "\0\1\0\0\0\0\0\0", 8)         = 8
2019-06-19 08:29:25 <fcolista> --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=21338, si_uid=1002, si_status=0, si_utime=6, si_stime=1} ---
2019-06-19 08:29:26 <fcolista> read(7,
2019-06-19 08:29:35 <fcolista> this is where firefox get stucked
2019-06-19 08:29:59 <fcolista> fcolista 12833  0.0  0.2 158320 34980 tty2     S    09:32   0:00 /usr/lib/firefox/firefox http://libgcr-base-3.so
2019-06-19 08:29:59 <fcolista> fcolista 12839  0.0  0.0      0     0 tty2     Z    09:32   0:00 [firefox] <defunct>
2019-06-19 08:37:57 <ncopa> i have tested install alpine on nvme (in qemu)
2019-06-19 08:38:01 <ncopa> works
2019-06-19 08:38:19 <ncopa> root
2019-06-19 08:38:40 <_ikke_> With mate?
2019-06-19 08:38:49 <ncopa> no, just normal sys install
2019-06-19 08:38:52 <_ikke_> right
2019-06-19 08:38:55 <ncopa> i havent configured mate yet
2019-06-19 08:39:14 <ncopa> this looks weird /usr/lib/firefox/firefox http://libgcr-base-3.so
2019-06-19 08:39:23 <ncopa> looks like it tries to open a shared lib as http?
2019-06-19 08:43:54 <PureTryOut[m]> _rc6 uboot image still doesn't include Pine64 for some reason...
2019-06-19 08:44:03 <_ikke_> what...
2019-06-19 08:44:33 <_ikke_> Do you mean as package included in the iso?
2019-06-19 08:45:08 <mps> _ikke_: I presume PureTryOut[m] mean in uboot tarball
2019-06-19 08:45:26 <_ikke_> uh, yes, I meant the tarbal
2019-06-19 08:46:09 <PureTryOut[m]> I do yes
2019-06-19 08:46:36 <PureTryOut[m]> The tarball includes an u-boot folder, but that folder doesn't include Pine64
2019-06-19 08:47:27 <mps> PureTryOut[m]: ncopa told yesterday that he fixed it, but I didn't had time to look at it
2019-06-19 08:47:51 <_ikke_> What should cause that to be included?
2019-06-19 08:47:53 <ncopa> e39d6315c99bc1b21c901d7bd6ade668bdb68193
2019-06-19 08:48:11 <_ikke_> I don't see a uboot profile for mkimage
2019-06-19 08:48:17 <ncopa> i dont have resources for testing in detail that patches sent actually work
2019-06-19 08:48:51 <ncopa> i need to be able to trust that when people send patch, they have actually tested that it works
2019-06-19 08:49:25 <ncopa> PureTryOut[m]: can you verify that the pine64-lts is included in the package as intended?
2019-06-19 08:49:46 <mps> ncopa: this should be very important especially for important packages
2019-06-19 08:49:55 <ncopa> i assume that the file it needs is export BL31="/usr/share/arm-trusted-firmware-sun50i/bl31.bin"
2019-06-19 08:50:15 <ncopa> but i dont really have time to investigate exactly which files are needed for pine64
2019-06-19 08:50:21 <ncopa> and i dont have the board to test
2019-06-19 08:50:30 <_ikke_> How is the uboot image generated?
2019-06-19 08:50:34 <_ikke_> (tarball)
2019-06-19 08:50:37 <PureTryOut[m]> https://pkgs.alpinelinux.org/contents?branch=edge&name=u-boot-pine64&arch=aarch64&repo=main
2019-06-19 08:50:46 <PureTryOut[m]> I guess the image is named differently and that's why it isn't included?
2019-06-19 08:50:57 <ncopa> so it is a subpackage
2019-06-19 08:50:58 <mps> _ikke_: https://bugs.alpinelinux.org/issues/10543
2019-06-19 08:51:43 <PureTryOut[m]> Yes, like the other u-boot packages
2019-06-19 08:51:44 <mps> this bug is what impedes me to test different u-boot tarbalss
2019-06-19 08:55:07 <mps> PureTryOut[m]: you can download pine64 u-boot apk and uboot tarball, to  test board. But I presume you know this
2019-06-19 08:55:39 <ncopa> mps: https://bugs.alpinelinux.org/issues/10543#note-3
2019-06-19 08:55:44 <PureTryOut[m]> Yeah I can, but I want to test if it works out of the box with the image for the actual release
2019-06-19 08:56:06 <ncopa> problem is that the scripts will cd $something ... cd $workdir
2019-06-19 08:56:14 <ncopa> so you need to set absolute workdir
2019-06-19 08:56:37 <mps> aha, will try now.
2019-06-19 09:02:05 <mps> now it pass without error
2019-06-19 09:03:04 <mps> but I have '/sbin/update-kernel: line 320: mkinitfs: not found' so it should be installed by hand
2019-06-19 09:04:07 <mps> but now I have morning blindness and have to go out and far from screen
2019-06-19 09:07:11 <ncopa> PureTryOut[m]: i think your patch works. problem is in a sed expression in mkimg.arm.sh
2019-06-19 09:07:39 <ncopa> apk fetch  --simulate --recursive u-boot-all | sed -ne "s/^Downloading \([^0-9.]*\)\-.*$/\1/p"
2019-06-19 09:07:57 <ncopa> PureTryOut[m]: sorry for insinuate that you sent untested/broken patch
2019-06-19 09:08:05 <PureTryOut[m]> Haha no problem
2019-06-19 09:08:18 <PureTryOut[m]> I know it wasn't broken, we use that exact package on postmarketOS to boot the Pinephone devkits
2019-06-19 09:09:36 <ncopa> https://git.alpinelinux.org/aports/tree/scripts/mkimg.arm.sh#n99
2019-06-19 09:10:09 <ncopa> ncopa-edge-aarch64:~/aports/scripts$ apk fetch  --simulate --recursive u-boot-all | tpaste #| sed -ne "s/^Downloading \(
2019-06-19 09:10:09 <ncopa> [^0-9.]*\)\-.*$/\1/p"
2019-06-19 09:10:09 <ncopa> http://tpaste.us/DL5R
2019-06-19 09:10:19 <ncopa> as you see the pine64 is there
2019-06-19 09:10:30 <ncopa> when excluding the sed
2019-06-19 09:10:37 <ncopa> but with the sed enabled
2019-06-19 09:10:52 <ncopa> it is supposed to list u-boot-pine64
2019-06-19 09:11:27 <ncopa> ncopa-edge-aarch64:~/aports/scripts$ apk fetch  --simulate --recursive u-boot-all | sed -ne "s/^Downloading \([^0-9.]*\)
2019-06-19 09:11:27 <ncopa> \-.*$/\1/p" | tpaste
2019-06-19 09:11:27 <ncopa> http://tpaste.us/NK16
2019-06-19 09:11:48 <ncopa> but as you see, it wrongly strips the pine64 part
2019-06-19 09:11:54 <ncopa> together with the version
2019-06-19 09:14:05 <ncopa> this works: sed -ne "s/^Downloading \(.*\)\-[0-9].*$/\1/p"
2019-06-19 09:42:07 <mps> ncopa: by installing some additional apk's finally got mkimage.sh working. key was absolute paths. thanks
2019-06-19 10:37:44 <ncopa> im almost ready to tag release
2019-06-19 10:37:59 <ncopa> but we went out of disk space on aarch64 and s390x builders
2019-06-19 10:39:58 <_ikke_> How can we reclaim disk space?
2019-06-19 10:40:05 <_ikke_> remove old distfiles?
2019-06-19 10:40:10 <titwinkle> rm -rf /
2019-06-19 10:42:42 <mps> titwinkle: you forgot to prepend 'sudo'
2019-06-19 10:43:02 <_ikke_> and --no-preserve-root
2019-06-19 10:43:11 <mps> ;-)
2019-06-19 10:43:39 <titwinkle> <3
2019-06-19 10:49:05 <ncopa> can someone help me look over those: https://bugs.alpinelinux.org/projects/alpine/issues?fixed_version_id=133&per_page=100&set_filter=1&sort=status%2Cid%3Adesc&status_id=o
2019-06-19 10:49:17 <ncopa> those that are 'resolved'
2019-06-19 10:49:28 <ncopa> and close those that really are done
2019-06-19 10:49:38 <ncopa> except the security issues
2019-06-19 10:50:26 <_ikke_> What do you considered 'really done'?
2019-06-19 10:50:36 <Cogitri> Sure, can do after lunch
2019-06-19 10:50:58 <danieli> ncopa: I'll look at the security ones
2019-06-19 10:51:27 <danieli> changing the status filter to "Status is Resolved" should be better, right?
2019-06-19 10:51:40 <_ikke_> https://bugs.alpinelinux.org/projects/alpine/issues?utf8=%E2%9C%93&set_filter=1&sort=status%2Cid%3Adesc&f%5B%5D=status_id&op%5Bstatus_id%5D=%3D&v%5Bstatus_id%5D%5B%5D=3&f%5B%5D=fixed_version_id&op%5Bfixed_version_id%5D=%3D&v%5Bfixed_version_id%5D%5B%5D=133&f%5B%5D=&c%5B%5D=project&c%5B%5D=tracker&c%5B%5D=status&c%5B%5D=priority&c%5B%5D=subject&c%5B%5D=assigned_to&c%5B%5D=updated_on&group_by=&t%5B%5D=
2019-06-19 10:53:02 <ncopa> yup
2019-06-19 10:53:34 <ncopa> really done is if it was claimed fixed some time ago and nobody claims otherwise
2019-06-19 10:53:56 <ncopa> or if you have verified that the issue is actually fixed
2019-06-19 10:54:09 <ncopa> so we dont have situation like the pine64 thing we just had
2019-06-19 10:55:43 <ncopa> for example this: https://bugs.alpinelinux.org/issues/10461
2019-06-19 10:55:47 <ncopa> 23 days ago
2019-06-19 10:55:58 <ncopa> and nobody claims its still an issue
2019-06-19 10:56:15 <ncopa> i'd say if its more than a week and nobody protests, then just close it
2019-06-19 10:58:11 <ncopa> we also need to go over all the other issues
2019-06-19 10:58:23 <ncopa> and either set target 3.10.1 or 3.11
2019-06-19 11:01:44 <mps> I don't think that any of these still 'New' should block release
2019-06-19 11:10:09 <ncopa> agree, but we need to decide if we want fix them for either 3.10.1 (or 3.10.x)  or 3.11
2019-06-19 11:10:26 <ncopa> so we need to set target to either 3.10.1 or 3.11
2019-06-19 11:16:43 <PureTryOut[m]> Qt 5.13 has been released https://blog.qt.io/blog/2019/06/19/qt-5-13-released/
2019-06-19 11:19:23 <Cogitri> Neat
2019-06-19 11:19:37 <Cogitri> Does Qt also do something like GNOME with its versioning? (uneven numbers are unstable)
2019-06-19 11:19:53 <Cogitri> ncopa: Going through bugs now
2019-06-19 11:20:22 <PureTryOut[m]> Don't think so. Think the latest stable version was Qt 5.9
2019-06-19 11:21:21 <Cogitri> Alrighty
2019-06-19 11:28:48 <ncopa> 8 years old bug is fixed
2019-06-19 11:28:52 <ncopa> feels good to close it
2019-06-19 11:29:08 <ncopa> #593
2019-06-19 11:30:33 <_ikke_> :D
2019-06-19 11:31:03 <_ikke_> ncopa: For me, if I select default session, it does not work though, I have to explitly select xfce
2019-06-19 11:31:58 <ncopa> but if i select openbox it will use openbox
2019-06-19 11:32:12 <ncopa> _ikke_: sounds like a new/different issue
2019-06-19 11:32:40 <_ikke_> Probably different, I had that for a long time already
2019-06-19 12:02:49 <tmhoang> <ncopa> but we went out of disk space on aarch64 and s390x builders : anything I can help ?
2019-06-19 12:17:28 <mps> _ikke_: sorry for annoying you. do you have release notes url
2019-06-19 12:20:47 <TBK[m]> mps: https://tpaste.us/Q1gQ
2019-06-19 12:22:11 <mps> TBK[m]: thanks
2019-06-19 12:22:19 <_ikke_> https://wwwtest.alpinelinux.org/posts/Alpine-3.10.0-released.html
2019-06-19 12:23:18 <tmhoang> ceph is hot
2019-06-19 12:23:22 <PureTryOut[m]> Isn't the Pine64LTS support a bit of a lie when the release package doesn't include the u-boot for it? I mean, it can be installed if you add u-boot manually, but it won't work with the generic ARM image atm
2019-06-19 12:23:38 <TBK[m]> _ikke_: I think we should mention py2 is in the process of being removed
2019-06-19 12:24:15 <_ikke_> ncopa: ^ ?
2019-06-19 12:25:22 <mps> PureTryOut[m]: we have pine64-lts u-boot pkg, so it is not lie
2019-06-19 12:25:37 <PureTryOut[m]> Well no, but it isn't really fair either lol
2019-06-19 12:25:59 <mps> did you tested it? does it work?
2019-06-19 12:26:48 <TBK[m]> _ikke_: danieli also mentioned that erlang got a significant update (21.2.1 -> 22.0.2)
2019-06-19 12:27:09 <danieli> yes, major releases are made approx once a year
2019-06-19 12:27:43 <_ikke_> Right, will add that
2019-06-19 12:28:04 <danieli> wwwtest?
2019-06-19 12:28:13 <PureTryOut[m]> mps: as I have no clue how to add the package myself if not included in the release, nope
2019-06-19 12:28:21 <ncopa> I tend to agree with PureTryOut[m]
2019-06-19 12:28:31 <ncopa> re pure64
2019-06-19 12:28:38 <ncopa> we dont really know if it works :)
2019-06-19 12:28:41 <PureTryOut[m]> The u-boot-pine64 package itself works though, as we use it to boot the Pinephone devkit on postmarketOS
2019-06-19 12:28:50 <ncopa> same with iwd
2019-06-19 12:29:15 <mps> PureTryOut[m]: so, uboot works, then
2019-06-19 12:29:20 <ncopa> PureTryOut[m]: if i tag rc7 right now, will you be able to test it?
2019-06-19 12:29:33 <ncopa> i'd like to make 3.10.0 later today
2019-06-19 12:29:48 <PureTryOut[m]> ncopa: _if_ it includes the Pine64 u-boot image yes, otherwise no
2019-06-19 12:29:51 <mps> ncopa: iwd works, why do you think it doesn't work
2019-06-19 12:30:08 <ncopa> or let me put it this way: how fast can you test it
2019-06-19 12:30:13 <PureTryOut[m]> mps: u-boot does, but the ARM64 image doesn't
2019-06-19 12:30:26 <PureTryOut[m]> ncopa: I can test it the moment I have an image with the proper u-boot included
2019-06-19 12:30:29 <ncopa> mps: i heard that there was some kernel feature missing?
2019-06-19 12:30:41 <ncopa> PureTryOut[m]: ok, let me tag rc7 then
2019-06-19 12:30:56 <mps> PureTryOut[m]: ah, then it is something other. sorry for misunderstanding you
2019-06-19 12:31:34 <PureTryOut[m]> Np
2019-06-19 12:31:37 <TBK[m]> there was something with kernel features and iwd support for eap
2019-06-19 12:31:46 <mps> ncopa: EAP doesn't work, that's true. kernel 4.19.x missing pkcs8 support which is needed for EAP
2019-06-19 12:33:21 <ncopa> PureTryOut[m]: rc7 will be available in 10-15 mins here: http://dl-cdn.alpinelinux.org/alpine/v3.10/releases/aarch64/
2019-06-19 12:33:29 <PureTryOut[m]> 👍️
2019-06-19 12:33:34 <mps> on kernels 4.20.x and up it works
2019-06-19 12:34:22 <ncopa> mps: understood. i wonder if we want see "alpine with iwd" as headlines in media
2019-06-19 12:35:02 <ncopa> i havent personally tested it, so i dont know how well it works
2019-06-19 12:35:24 <ncopa> so i would feel safer if we don't mention it
2019-06-19 12:35:35 <_ikke_> danieli: wwwtest is the 'staging' version for the site
2019-06-19 12:35:49 <ncopa> mps: however, if you say that it works, and is worth mentioning, then im ok to keep it
2019-06-19 12:35:52 <mps> ahm, no. But I told from the beginning when introduced iwd that this feature will not work till we have 4.19.x kernel
2019-06-19 12:35:52 <danieli> yes, but is the note being written there?
2019-06-19 12:35:54 <danieli> i want a sneak pea
2019-06-19 12:35:55 <danieli> k
2019-06-19 12:36:05 <danieli> sneak peek*
2019-06-19 12:36:07 <_ikke_> I just linked to it
2019-06-19 12:36:16 <_ikke_> or do you mean about erlang?
2019-06-19 12:36:22 <danieli> ah, i missed it, sorry
2019-06-19 12:36:22 <PureTryOut[m]> I guess linux-vanilla will always stay at the latest longterm kernel?
2019-06-19 12:36:54 <_ikke_> I think that's the goal
2019-06-19 12:37:04 <ncopa> PureTryOut[m]: yes, thats what we try to do
2019-06-19 12:37:11 <mps> iwd is interesting to mention because most of those who tried it are satisfied with it more than wpa_sp
2019-06-19 12:37:13 <PureTryOut[m]> ok
2019-06-19 12:37:15 <ncopa> we could in theory rename it to linux-lts
2019-06-19 12:37:37 <ncopa> mps: ok. all good then
2019-06-19 12:37:44 <PureTryOut[m]> Would it be ok to have a linux-stable be added?
2019-06-19 12:37:55 <ncopa> PureTryOut[m]: i would prefer not
2019-06-19 12:37:58 <PureTryOut[m]> So that would be 5.1.12 atm
2019-06-19 12:37:58 <mps> and adding note that the EAP is doesnt't work will be good
2019-06-19 12:38:13 <ncopa> kernels takes significant time to maintain
2019-06-19 12:38:15 <PureTryOut[m]> Not as a different package which can be installed optionally for the people that want it?
2019-06-19 12:38:28 <ncopa> we already have linux-vanilla, linux-virt linux-rpi and linux-rpi2
2019-06-19 12:38:35 <mps> if someone upgrade kernel then it work with EAP
2019-06-19 12:38:57 <mps> I think 5.2 will be next LTS linux
2019-06-19 12:39:12 <PureTryOut[m]> That'd be nice...
2019-06-19 12:39:36 <ncopa> if there is a critical security issue in kernel it needs to be fixed in 2 * 4 places
2019-06-19 12:39:52 <ncopa> if we add another kernel it will be 3 * 4 = 12 places
2019-06-19 12:40:00 <ncopa> and in addition all 3rd party modules needs to be rebuilt
2019-06-19 12:40:21 <ncopa> i originally only wanted 3rd party modules for linux-vanilla
2019-06-19 12:40:23 <_ikke_> https://tpaste.us/Q1gl
2019-06-19 12:40:27 <PureTryOut[m]> 2 * 4? 🤔
2019-06-19 12:40:37 <ncopa> linux-vanilla and linux-rpi
2019-06-19 12:40:44 <ncopa> its actually 2 * 5
2019-06-19 12:40:57 <mps> _ikke_: "USB, serial and ethernet support for arm boards", I'm not sure of "USB", no one tested that afaik
2019-06-19 12:41:05 <ncopa> linux-vanilla linux-rpi in git master, 3.9-stable, 3.8-stable ....
2019-06-19 12:41:06 <_ikke_> mps: ok
2019-06-19 12:41:13 <PureTryOut[m]> What do you mean with the 2 and 5? There are 4 kernels atm right?
2019-06-19 12:41:21 <PureTryOut[m]> Oh stable..
2019-06-19 12:41:37 <PureTryOut[m]> I guess linux-stable could be in community only?
2019-06-19 12:41:48 <mps> serial and ethernet are ok
2019-06-19 12:41:52 <_ikke_> https://tpaste.us/KgBY
2019-06-19 12:41:57 <ncopa> the 2 kernels are linux-vanilla (incl linux-virt) and linux-rpi (incl linux-rpi2)
2019-06-19 12:42:13 <ncopa> PureTryOut[m]: yes
2019-06-19 12:42:30 <mps> _ikke_: looks ok
2019-06-19 12:42:32 <PureTryOut[m]> Oh nvm community is also in stable
2019-06-19 12:42:47 <ncopa> if we add it it would need to be in community
2019-06-19 12:43:02 <PureTryOut[m]> Hmm, I understand your point, it's just a shame that -lts is so old. It's always lacking a lot of new hardware support
2019-06-19 12:43:02 <ncopa> but people will start ask for 3rd party modules
2019-06-19 12:43:20 <ncopa> zfs, wireguard, virtualbox additions, xtables addons, etc
2019-06-19 12:44:48 <ncopa> kernel is also extra tricky when it comes to config management
2019-06-19 12:45:21 <ncopa> the point is that adding a kernel comes with a maintenance cost
2019-06-19 12:45:42 <ncopa> but, yeah, i thought about it the other day
2019-06-19 12:45:50 <ncopa> it would be nice with a linux-stable
2019-06-19 12:46:16 <ncopa> im just afraid it will suck my energy
2019-06-19 12:46:33 <PureTryOut[m]> I understand
2019-06-19 12:46:34 <ncopa> so if someone else wants maintain it, then sure..
2019-06-19 12:47:02 <PureTryOut[m]> What about DKMS? https://wiki.archlinux.org/index.php/Dkms
2019-06-19 12:47:13 <ncopa> another thing i though about was a linux-kvm flavor
2019-06-19 12:47:24 <Cogitri> Means a lot of bloat for the user, PureTryOut
2019-06-19 12:47:25 <ncopa> with no module support
2019-06-19 12:47:35 <PureTryOut[m]> DKMS is bloat now?
2019-06-19 12:48:00 <Cogitri> Well, a fully functional C(++) toolchain is blowing for most users
2019-06-19 12:48:14 <Cogitri> s/blowing/bloat/
2019-06-19 12:48:14 <alpine-meetbot> Cogitri meant to say: Well, a fully functional C(++) toolchain is bloat for most users
2019-06-19 12:48:27 <Cogitri> 
ACTION shakes fist at autocorrect

2019-06-19 12:48:35 <PureTryOut[m]> I guess, but maybe it could be used for linux-stable only?
2019-06-19 12:49:48 <PureTryOut[m]> I'm just thinking aloud here
2019-06-19 12:50:05 <Cogitri> Hm, what about people who want to use linux-stable but want a minimal install nontheless?
2019-06-19 12:50:12 <Cogitri> And maintaining two different approaches sounds annoying
2019-06-19 12:50:16 <mps> most alpine users are 'hackers' so I don't think it is big issue to install C and toolchains for them
2019-06-19 12:51:06 <Cogitri> mps: The problem is how much space that takes up
2019-06-19 12:51:07 <PureTryOut[m]> And generic desktop users won't care about the toolchain, they won't even realize it's installed or what it does
2019-06-19 12:51:12 <mps> although, I'm not proposing DKMS
2019-06-19 12:51:30 <Cogitri> <mps "most alpine users are 'hackers' "> You're fine installing multiple hundreds of MB of toolchain when a icon theme that weighs in at a few MB is bloat for you? :p
2019-06-19 12:52:13 <Cogitri> I mean I'd be all for DKMS since it'd lessen the workload on us, but I've seen some pretty strong opinions about Alpine needing to be small and minimal
2019-06-19 12:52:14 <mps> meh, I see bloating on horizon anyway ;)
2019-06-19 12:53:07 <mps> Cogitri: yes, I'm strongly for Small, Simple, Secure
2019-06-19 12:53:08 <maxice8> pr8865 can be closed
2019-06-19 12:54:10 <maxice8> What is the hardware on drone-ci ?
2019-06-19 12:54:23 <maxice8> ty ncopa
2019-06-19 12:54:45 <ncopa> drone-ci hardware is from packet.net
2019-06-19 12:54:58 <ncopa> which i think is fairly similar to our builders
2019-06-19 12:55:50 <Cogitri> mps: Yup, and GCC weighs in at about 150MB already :/
2019-06-19 12:56:13 <Cogitri> But if you do decide in favour of DKMS I wouldn't mind helping with that
2019-06-19 12:56:45 <mps> no, just told I'm not proposing DKMS few minutes ago
2019-06-19 12:57:24 <mps> although I contemplated about it few months ago, TBH
2019-06-19 12:59:53 <Cogitri> Alright
2019-06-19 13:00:24 <Cogitri> mps: How much RAM did your armv7 lxc have again? Trying to dig deeper into the webkit2gtk stuff :/
2019-06-19 13:01:14 <mps> Cogitri: Enough :) more than 64GB
2019-06-19 13:06:09 <Cogitri> Alright, thanks for the info
2019-06-19 13:06:41 <mps> when you prepare something just ping
2019-06-19 13:10:50 <wozencroft> mps: Hi! Can you maybe see from the outputs here: https://hatebin.com/yfcebqgedl  why the wg interface is not in use (using the wireguard guide steps from the wiki)?
2019-06-19 13:13:17 <danieli> wozencroft: sounds like a matter for #alpine-linux, this is the development channel
2019-06-19 13:15:46 <wozencroft> danieli: Ok, sorry, thanks.
2019-06-19 13:15:58 <Cogitri> mps: Well, I guess you could try pr8257 again, latest commit hash is d9ab694380a
2019-06-19 13:16:39 <mps> Ok, in 20 minutes, I'm out now
2019-06-19 13:17:20 <Cogitri> mps: If it gets stuck please send me the VMSize of the stuck process
2019-06-19 13:17:22 <Cogitri> Alright, no hurry :)
2019-06-19 13:17:37 <mps> ok, will do
2019-06-19 13:19:42 <TBK[m]> somebody with GH perms please close pr8852
2019-06-19 13:23:48 <_ikke_> Latest version of the 3.10 release post: https://wwwtest.alpinelinux.org/posts/Alpine-3.10.0-released.html
2019-06-19 13:24:53 <danieli> erlang isn't there
2019-06-19 13:25:27 <danieli> also, i'm not sure algitbot needs to publish commits for alpine-mksite to #alpine-commits like with infra/ repos
2019-06-19 13:26:04 <_ikke_> danieli: erlang *is* included
2019-06-19 13:26:13 <danieli> not in that release note
2019-06-19 13:26:21 <danieli> oh
2019-06-19 13:26:23 <danieli> cache,.
2019-06-19 13:26:28 <danieli> s/,//
2019-06-19 13:26:28 <alpine-meetbot> danieli meant to say: cache.
2019-06-19 13:26:52 <_ikke_> :)
2019-06-19 13:28:13 <PureTryOut[m]> Could, the latest rc has Pine64 u-boot in it. Now I do wonder, how is the u-boot image normally installed for other u-boot devices?
2019-06-19 13:29:39 <mps> PureTryOut[m]: download, unpack, and 'dd' right file
2019-06-19 13:30:43 <PureTryOut[m]> And the right file is which one exactly?
2019-06-19 13:31:38 <PureTryOut[m]> Oh actually I might have it already, give me a sec
2019-06-19 13:31:45 <mps> not sure for Pine64, but usually 'u-boot.something.bin', something is usually name of board
2019-06-19 13:32:09 <mps> or familly of boards
2019-06-19 13:32:34 <Cogitri> ikke: Looks good to me 👍
2019-06-19 13:36:53 <ncopa> was texlive removed?
2019-06-19 13:36:59 <ncopa> seems to be in community
2019-06-19 13:37:06 <_ikke_> hmm, did someone add it again?
2019-06-19 13:37:14 <_ikke_> it was unmaintained
2019-06-19 13:37:18 <mps> I think I pushed it
2019-06-19 13:37:30 <ncopa> 432a459dc6e58a9040897a6fb4341c8292f6ff33
2019-06-19 13:37:39 <_ikke_> ah ok
2019-06-19 13:37:47 <_ikke_> Then I'll remove that from the release notes again
2019-06-19 13:38:22 <mps> from pw.a.o, Marian Buschsieweke took maintainership
2019-06-19 13:38:55 <_ikke_> right
2019-06-19 13:39:23 <_ikke_> updated
2019-06-19 13:39:52 <mps> oh no, I was moved something else from him, iirc
2019-06-19 13:40:11 <_ikke_> ncopa: someone said we should mention somehting about the depraction of python2?
2019-06-19 13:40:27 <_ikke_> That name sounds like a her
2019-06-19 13:40:46 <mps> sorry for confusion
2019-06-19 13:41:20 <danieli> might as well go with 'them' if you don't know
2019-06-19 13:42:05 <danieli> for what it's worth, i assume they're male, judging by the accounts i can see online
2019-06-19 13:47:29 <ncopa> _ikke_: i think xen 4.12 is a noteworthy update
2019-06-19 13:47:40 <ncopa> maybe qemu 4.0 too
2019-06-19 13:47:52 <_ikke_> Ok, will add it
2019-06-19 13:51:37 <ncopa> was samba updated?
2019-06-19 13:51:38 <ncopa> oh
2019-06-19 13:51:43 <ncopa> what about circular deps?
2019-06-19 13:51:52 <ncopa> whats the status there
2019-06-19 13:55:19 <_ikke_> ncopa: apparently still there
2019-06-19 13:57:48 <PureTryOut[m]> Well, it boots u-boot, but it seems it can't find the root filesystem
2019-06-19 13:58:22 <ncopa> do you get a emergency shell?
2019-06-19 13:58:48 <ncopa> it sounds like the driver for the blockdevice is missing in initramfs
2019-06-19 13:58:54 <PureTryOut[m]> Atm my sdcard contains `/boot` and `/apks` from the ARM image. Does it need anything else?
2019-06-19 13:59:10 <ncopa> no, but what blockdevice is it?
2019-06-19 13:59:24 <ncopa> is the needed driver to find /apks included in initramfs?
2019-06-19 13:59:38 <PureTryOut[m]> You mean what filesystem? ext4
2019-06-19 13:59:44 <PureTryOut[m]> Which this u-boot should support afaik
2019-06-19 14:00:05 <_ikke_> PureTryOut[m]: block device is /dev/*
2019-06-19 14:00:15 <ncopa> u-boot finds the kernel i guess, but kernel lacks the driver for sdcard in initramfs
2019-06-19 14:00:35 <ncopa> do you know what driver it needs for sdcard?
2019-06-19 14:00:46 <PureTryOut[m]> No
2019-06-19 14:01:48 <PureTryOut[m]> Boot log https://bpaste.net/show/7de831479ca1
2019-06-19 14:02:24 <PureTryOut[m]> I guess the kernel being at 4.19 still might be an issue too
2019-06-19 14:02:27 <_ikke_> "card did not respond to voltage select"
2019-06-19 14:02:52 <PureTryOut[m]> Note, this isn't an sdcard, it's an eMMC storage
2019-06-19 14:03:48 <mps> PureTryOut[m]: try to add 'sunxi-mmc' in extlinux.conf (and remove quiet)
2019-06-19 14:05:03 <PureTryOut[m]> Wait, where is extlinux.conf supposed to go?
2019-06-19 14:05:17 <PureTryOut[m]> Oh just in `/extlinux` it seems
2019-06-19 14:05:34 <mps> my line looks like "APPEND modules=loop,squashfs,sd-mod,usb-storage,ext4,sunxi-mmc  console=${console}"
2019-06-19 14:05:42 <PureTryOut[m]> https://bpaste.net/show/6b1c99e76261
2019-06-19 14:05:57 <mps> /extlinux/extlinux.conf
2019-06-19 14:06:32 <PureTryOut[m]> I need to get the dtb file from somewhere it seems
2019-06-19 14:07:04 <mps> I it loaded, according to log you just posted
2019-06-19 14:07:41 <mps> Retrieving file: /boot/dtbs/allwinner/sun50i-a64-pine64-lts.dtb
2019-06-19 14:08:32 <mps> (these people should send one of their boxes to me, it seems ;) )
2019-06-19 14:08:54 <PureTryOut[m]> Hmm
2019-06-19 14:09:03 <PureTryOut[m]> > Skipping vanilla for failure retrieving fdt
2019-06-19 14:09:04 <PureTryOut[m]> I guess that's the problem?
2019-06-19 14:09:36 <mps> uh, yes
2019-06-19 14:10:12 <mps> let me finnish coffee, I will look content of tarball then
2019-06-19 14:10:19 <PureTryOut[m]> Also, that dtb file isn't actually on the sdcard
2019-06-19 14:10:51 <mps> is it in tarball
2019-06-19 14:11:30 <PureTryOut[m]> No, the `/boot/dtbs` directory doesn't exist in the tarball
2019-06-19 14:12:33 <mps> ohm, right, there are not dtbs at all
2019-06-19 14:12:58 <mps> to late to fix for this release, I fear
2019-06-19 14:15:18 <ncopa> _ikke_: do you think we can close 10469?
2019-06-19 14:15:26 <ncopa> #10469
2019-06-19 14:15:59 <PureTryOut[m]> I guess the Linux kernel is still too old
2019-06-19 14:16:47 <PureTryOut[m]> Mainline Linux has the Pine64 DTS
2019-06-19 14:17:01 <PureTryOut[m]> I guess we'll have to wait for a stable release with a new Linux version
2019-06-19 14:18:50 <ncopa> sweet! bugs.a.o is cleaned up for 3.10 now
2019-06-19 14:19:34 <PureTryOut[m]> Anyway let me write down on the wiki what I got so far
2019-06-19 14:19:35 <ncopa> so we should probably not mention pine64 in release notes
2019-06-19 14:20:33 <mps> I think we don't build dtb's for aarch64? not sure though
2019-06-19 14:21:09 <ncopa> im ready to tag ... oh no
2019-06-19 14:21:15 <_ikke_> ncopa: I think the fix is straightforward, so I say yes, but I did not test it myself
2019-06-19 14:21:30 <ncopa> i closed it
2019-06-19 14:21:31 <ncopa> but
2019-06-19 14:21:32 <mps> yes, dtb's are built only for arm*
2019-06-19 14:21:43 <ncopa> 4.19.53 is out
2019-06-19 14:21:52 <ncopa> we should upgrade
2019-06-19 14:22:34 <PureTryOut[m]> ncopa: yeah don't mention pine64 in the release notes
2019-06-19 14:22:45 <PureTryOut[m]> We'll try again once Linux updates to > 5.1
2019-06-19 14:23:01 <ncopa> speaking about kernels
2019-06-19 14:23:11 <ncopa> i havent yet fixed the oldest rpi kernel
2019-06-19 14:23:15 <ncopa> which is still vulnerable
2019-06-19 14:23:24 <mps> PureTryOut[m]: Arch Alarm support pine64 for some time
2019-06-19 14:23:37 <ncopa> i need to rebase the rpi patch and there was a handful merge conflicts
2019-06-19 14:23:47 <ncopa> seems like the patches was applied upstream
2019-06-19 14:23:57 <ncopa> but the rpi tree had slightly different patches
2019-06-19 14:24:02 <ncopa> so it needs to work to rebase
2019-06-19 14:24:19 <PureTryOut[m]> I mean, at postmarketOS we support Pine64, but I'd like Alpine itself to support i too eventually
2019-06-19 14:24:23 <PureTryOut[m]> but we use newer kernels
2019-06-19 14:25:41 <mps> looks like we should build dtb's also for aarch64
2019-06-19 14:26:24 <mps> will try later if I can update linux-vanilla to build them
2019-06-19 14:26:59 <mps> (I thought we do already)
2019-06-19 14:32:28 <ncopa> ok, im building 4.19.53 kernels
2019-06-19 14:32:41 <ncopa> good that we have fast builders
2019-06-19 14:35:56 <PureTryOut[m]> mps: thatnks that would be nice
2019-06-19 14:39:22 <mps> PureTryOut[m]: np, it would be good to have alpine running on these machines, although I don't have them
2019-06-19 14:39:43 <mps> for now, I'm fine with arm chromebooks
2019-06-19 14:40:03 <PureTryOut[m]> The more devices Alpine boots on the better 😉
2019-06-19 14:40:43 <mps> agree, but arm 'ecosystem' is like a jungle ;)
2019-06-19 14:41:13 <danieli> welcome to the jungle, we've got fun and games
2019-06-19 14:41:23 <ncopa> can we please hold git pushes to testing packages til after 3.10 is done?
2019-06-19 14:41:38 <ncopa> i have only kernels and we are ready
2019-06-19 14:41:52 <ncopa> dont want hold the builders busy with anything else
2019-06-19 14:42:17 <ncopa> minor, safe, pushes are ok (patch version bumps for example)
2019-06-19 14:42:21 <ncopa> for small packages
2019-06-19 14:54:36 <PureTryOut[m]> cogitri: GNOME Software uses PackageKit on the backend right? What are your plans for it on Alpine?
2019-06-19 14:56:34 <ncopa> its their own package manager, right?
2019-06-19 14:56:48 <PureTryOut[m]> No
2019-06-19 14:57:03 <PureTryOut[m]> PackageKit abstracts over multiple package managers
2019-06-19 14:57:09 <ncopa> ah!
2019-06-19 14:57:11 <tmhoang> ethernet@1c30000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! : looks like networking issue more than block device driver not found
2019-06-19 14:57:12 <ncopa> i remember that one
2019-06-19 14:57:28 <PureTryOut[m]> And then applications like GNOME Software and KDE Discover implement a PackageKit backend so it works on multiple distros
2019-06-19 14:57:32 <Cogitri> PureTryOut: I don't think apk has support for that, does it?
2019-06-19 14:57:42 <PureTryOut[m]> It does not
2019-06-19 14:57:43 <PureTryOut[m]> That's why I'm asking 😉
2019-06-19 14:57:55 <ncopa> i actually looked at implementing apk backend as some point
2019-06-19 14:58:07 <ncopa> i dont think its too difficult
2019-06-19 14:58:32 <danieli> shouldn't be too hard
2019-06-19 14:58:34 <mps> Cogitri: webkit is stuck again. what you want to send you?
2019-06-19 14:58:48 <ncopa> it is possible to pass a filedescriptor with progress from apk
2019-06-19 14:59:02 <ncopa> there is gapk which is a simple gtk wrapper
2019-06-19 14:59:15 <danieli> iirc that wraps `apk' in the command line
2019-06-19 14:59:20 <Cogitri> <PureTryOut[m] "That's why I'm asking 😉"> Well, I don't have interest working on C software, so I won't do the work in apk, but I can help with other stuff if I can
2019-06-19 14:59:47 <ncopa> i guess first step is to add a feature request to packagekit
2019-06-19 14:59:47 <danieli> speaking of apk, i should really quit procrastinate and work on those python bindings i mentioned working on
2019-06-19 15:00:23 <ncopa> not sure if its worth it before apk3
2019-06-19 15:00:32 <danieli> has any work been done on apk3?
2019-06-19 15:00:38 <danieli> and was there ever an apk2?
2019-06-19 15:00:46 <PureTryOut[m]> Yeah I heard talk about a rewrite of apk before
2019-06-19 15:00:48 <danieli> i suppose current apk is apk2 if the shell apk was apk 1
2019-06-19 15:00:50 <PureTryOut[m]> I guess that's apk3 then?
2019-06-19 15:00:54 <_ikke_> danieli: the current version is apk2
2019-06-19 15:00:58 <_ikke_> version 1 was shell scripts
2019-06-19 15:01:15 <danieli> anyway, where's the apk3 repo?
2019-06-19 15:01:17 <ncopa> yes, there has been some  apk3 work done by fabled
2019-06-19 15:01:21 <ncopa> its not open yet
2019-06-19 15:01:37 <danieli> is it not open source?
2019-06-19 15:01:41 <ncopa> not enough code to publish it
2019-06-19 15:01:45 <ncopa> as in understodd
2019-06-19 15:01:56 <ncopa> the work done is planning and testing of the new file format
2019-06-19 15:01:57 <danieli> fair enough
2019-06-19 15:02:05 <danieli> i started a new C apk too, but i just finished the boilerplate
2019-06-19 15:02:22 <ncopa> what i think we could work on meanwhile though
2019-06-19 15:02:28 <ncopa> is how we want the cli to be
2019-06-19 15:02:57 <ncopa> im thinking of keeping the most common, `apk add` and `apk del`
2019-06-19 15:03:03 <ncopa> but then redo the rest
2019-06-19 15:03:06 <danieli> yeah, that stuff is in muscle memory now
2019-06-19 15:03:22 <danieli> but most of the other things are a bit.. unintuitive
2019-06-19 15:03:24 <ncopa> we could have like: apk query
2019-06-19 15:03:34 <ncopa> and similar
2019-06-19 15:03:38 <danieli> all i want is better documentation and man pages
2019-06-19 15:03:48 <ncopa> we can start writing those
2019-06-19 15:03:48 <danieli> that'll make apk so much easier to work with
2019-06-19 15:03:54 <ncopa> how we want it to work :)
2019-06-19 15:04:05 <ncopa> for example
2019-06-19 15:04:11 <danieli> yeah, suppose a spec could be written
2019-06-19 15:04:27 <ncopa> the output is currently a mix of user friendly and script friendly
2019-06-19 15:04:27 <Cogitri> Well, ping me if you decide making the thing in Rust :P
2019-06-19 15:04:50 <ncopa> ok here comes kernel
2019-06-19 15:05:24 <danieli> last time i checked, rust executables used more memory and were pretty large
2019-06-19 15:05:28 <ncopa> builds should be done in 40-45 mins i guess
2019-06-19 15:05:34 <mps> Cogitri: please don't such important thing in rust :P
2019-06-19 15:05:36 <danieli> i mean, could write it in ada for all i care
2019-06-19 15:05:39 <tmhoang> speaking of apk, i would love to hear about more features rather than changing and/or removing current features.
2019-06-19 15:06:03 <ncopa> i'd like it to be more consistent
2019-06-19 15:06:07 <ncopa> the cli
2019-06-19 15:06:17 <ncopa> and more script firendly
2019-06-19 15:06:17 <tmhoang> yeah that's what I meant
2019-06-19 15:06:17 <danieli> tmhoang: would have to implement and tweak the current functionality before adding lots of new functionality
2019-06-19 15:06:26 <danieli> +1 to configurable
2019-06-19 15:06:39 <ncopa> so it prints: $pkgname $pkgver
2019-06-19 15:06:48 <ncopa> with space separation
2019-06-19 15:06:52 <ncopa> so its more useful for script
2019-06-19 15:07:02 <danieli> output in different formats, support for fancy terminals with fallbacks
2019-06-19 15:07:12 <danieli> proper bindings to a couple of the more popular language
2019-06-19 15:07:12 <danieli> s
2019-06-19 15:07:24 <ncopa> yes, a proper libapk
2019-06-19 15:07:26 <danieli> proper libapk
2019-06-19 15:07:27 <danieli> yes
2019-06-19 15:07:32 <ncopa> so its possible to do bindings
2019-06-19 15:07:44 <ncopa> thats one of the things i'd like
2019-06-19 15:08:04 <danieli> i already have a modified/refactored version of apk2 locally that builds a libapk and apk executable linked to it
2019-06-19 15:08:14 <danieli> and python bindings built against it
2019-06-19 15:08:35 <ncopa> i did libapk in current apk sources
2019-06-19 15:08:37 <PureTryOut[m]> This all sounds great 😃
2019-06-19 15:08:47 <ncopa> so it can build a shared libapk
2019-06-19 15:08:59 <ncopa> but its not really designed for it
2019-06-19 15:09:04 <ncopa> and the API is not stable
2019-06-19 15:09:08 <danieli> no offense, but it felt a bit screwy
2019-06-19 15:09:17 <ncopa> its because its not designed for it
2019-06-19 15:09:23 <tmhoang> re pine64, should we ask some sponsors on twitter, etc. to provide Alpine dev more hardware ?
2019-06-19 15:09:26 <Cogitri> mps: Hehe, sorry, had to do that :P
2019-06-19 15:09:38 <Cogitri> danieli: Yup, due to static linking they're pretty huge
2019-06-19 15:10:08 <mps> np, I thought to propose crystal ;)
2019-06-19 15:10:24 <tmhoang> <PureTryOut[m]> : quick question, pine64 requires any blob ?
2019-06-19 15:10:27 <ncopa> one of the things that it has been working on is the index format
2019-06-19 15:10:41 <danieli> that has to be standardized in a stable fashion
2019-06-19 15:10:45 <ncopa> which will be in a binary format
2019-06-19 15:11:03 <PureTryOut[m]> tmhoang: not afaik
2019-06-19 15:11:06 <mps> tmhoang: you need one postal address :)
2019-06-19 15:11:14 <PureTryOut[m]> Not to boot anyway
2019-06-19 15:11:16 <danieli> hopefully not just a struct written to a file
2019-06-19 15:11:23 <tmhoang> mps: ship hardware to clandmeter :P
2019-06-19 15:11:23 <ncopa> the binary format is supposed to be in a memory layout fashion
2019-06-19 15:11:42 <ncopa> so you can simply mmap it, and you're done opening it :)
2019-06-19 15:12:00 <danieli> designing a nice format that's easy to interact with shouldn't be terribly hard
2019-06-19 15:12:12 <ncopa> so we dont need to memcpy the strings and data
2019-06-19 15:12:26 <ncopa> or allocate more memory for a copy of the strings
2019-06-19 15:14:02 <ncopa> the cached index will take more space (approx double size if i understood correctly)
2019-06-19 15:14:13 <ncopa> but will be significantly faster :)
2019-06-19 15:14:15 <mps> Cogitri: to repeat, webkit is stuck again. what you want to send you?
2019-06-19 15:17:38 <ncopa> humm...
2019-06-19 15:17:48 <ncopa> i need to go out for an hour or so
2019-06-19 15:17:50 <Cogitri> mps: The output of `/proc/<pid of stuck gcc>/statm` please
2019-06-19 15:18:04 <Cogitri> Sorry, didn't see your previous message
2019-06-19 15:18:15 <mps> I thought so, np
2019-06-19 15:18:53 <mps> cat /proc/27313/statm => http://tpaste.us/DL5d
2019-06-19 15:19:27 <mps> cat /proc/27313/status => http://tpaste.us/Boyb
2019-06-19 15:20:00 <mps>  cat /proc/27313/cmdline > http://tpaste.us/baYW
2019-06-19 15:20:08 <mps> anything else?
2019-06-19 15:22:44 <ncopa> gcc crashes on aarch64 once in a while
2019-06-19 15:23:04 <ncopa> i wonder if its a problem in gcc or in hardware
2019-06-19 15:23:07 <ncopa> appears random
2019-06-19 15:24:02 <mps> hmm, I didn't noticed that
2019-06-19 15:24:43 <mps> specific machine, or in general?
2019-06-19 15:30:30 <ncopa> its on the thunderx
2019-06-19 15:32:01 <mps> on usa4 I didn't noticed crashes of gcc, and also not on my rk3399 box
2019-06-19 15:33:02 <Cogitri> mps: Contacted upstream, thank you. I don't think I need something other than that
2019-06-19 15:33:26 <ncopa> i've only seen it on usa1
2019-06-19 15:33:29 <mps> Cogitri: ok, will kill stuck build now
2019-06-19 15:35:04 <mps> ncopa: maybe hardware and gcc combo
2019-06-19 15:35:51 <ncopa> maybe it only happen under load
2019-06-19 15:36:22 <ncopa> ive seen it when kernel was built
2019-06-19 15:36:24 <ncopa> and libreoffice iirc
2019-06-19 15:36:46 <mps> I just built kernel with dtbs on usa4, worked fine
2019-06-19 15:37:21 <mps> and usa4 is huawei box, iirc
2019-06-19 15:39:03 <ncopa> ive seen it when there are 2 kernels builds, or 2 libreoffice builds at same time
2019-06-19 15:39:10 <ncopa> eg on edge and 3.10 at same time
2019-06-19 15:39:13 <ncopa> on same machine
2019-06-19 15:39:23 <ncopa> thats why i think it may be related to load
2019-06-19 15:39:30 <ncopa> and it appears that one fails
2019-06-19 15:39:36 <ncopa> the other succeeds
2019-06-19 15:39:49 <ncopa> and next run the other succeeds too
2019-06-19 15:40:14 <ncopa> ok i need to go out now
2019-06-19 15:40:24 <mps> could be, I seldom see such big loads
2019-06-19 15:40:31 <mps> ok, see you
2019-06-19 15:40:44 <ncopa> will tag 3.10 when i come back
2019-06-19 15:44:30 <Cogitri> mps: Do you happen to know if that stuck gcc process still had CPU usage?
2019-06-19 15:45:44 <mps> yes, cpu time is continue to grow
2019-06-19 15:46:45 <mps> killed it few minutes ago, but 'ps' show something  like 'R+  89:xx' last time I looked
2019-06-19 15:47:06 <mps> i.e. Running and 89 minutes+
2019-06-19 15:47:31 <_ikke_> ncopa: do we still need to fix the samba dep cycle?
2019-06-19 15:50:51 <Cogitri> mps: Ah, how much % did it take?
2019-06-19 15:52:19 <mps> it is on shared box with more lxc container so load in % is not useful
2019-06-19 15:52:49 <mps> you mean, uptime %?
2019-06-19 15:52:59 <_ikke_> single process %
2019-06-19 15:53:14 <Cogitri> Exactly
2019-06-19 15:53:22 <mps> don't remember now
2019-06-19 15:54:02 <mps> I will have to run it again to reach there and see
2019-06-19 15:56:07 <Cogitri> Okie, thanks
2019-06-19 16:02:07 <Cogitri> Basically, make sure that it doesn't consume CPU anymore, the unified sources can take a long time to finish building apparently
2019-06-19 16:29:09 <PureTryOut[m]> Uh, is Firefox still hard to update? It has a critical, actively being misused, security issue only fixed in 67.0.3 and the lateest -esr
2019-06-19 16:29:32 <PureTryOut[m]> https://www.mozilla.org/en-US/security/advisories/mfsa2019-18/
2019-06-19 16:35:53 <mps> Cogitri: 'ps au' => mps      33147 99.7  1.0 1350764 1341300 pts/6 R+   16:11  23:50 /usr/libexec/gcc/armv7-alpine-linux-musleabihf/8.3.0/cc1plus -quiet -I /home/mps/aports/commu
2019-06-19 16:36:39 <Cogitri> Not 100% sure which column equals to what 😅
2019-06-19 16:37:16 <Cogitri> PureTryOut: I think there's a PR for that. I can look into it tomorrow though, going out now
2019-06-19 16:37:25 <mps> USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAN
2019-06-19 16:38:40 <mps> here is more complete: http://tpaste.us/7vJ9
2019-06-19 16:39:40 <mps> I have to kill it again, trying to build aarch64 uboot tarball with dtb's for PureTryOut[m]
2019-06-19 16:40:10 <PureTryOut[m]> Seems quite severe (remote code execution even I believe), so should probably be in 3.10
2019-06-19 16:40:55 <mps> PureTryOut[m]: right, this morning I looked at this
2019-06-19 16:45:49 <ncopa> _ikke_: i dont think we bother to do anything with samba, unless it is clearly broken
2019-06-19 16:46:06 <ncopa> whee! builders are idle
2019-06-19 16:52:41 <danieli> PureTryOut[m]: yeah, i posted a link about it in -offtopic a little earlier, people have been freaking out about it today
2019-06-19 16:59:37 <_ikke_> ncopa: nod
2019-06-19 17:01:21 <Cogitri> mps: Alright, so I guess it's not stuck but busy compiling then?
2019-06-19 17:02:31 <mps> more than a hour?
2019-06-19 17:03:16 <Cogitri> The unified sources are super massive
2019-06-19 17:04:21 <mps> ok, I will run it again later and left overnight, we will see then if it can finnish
2019-06-19 17:04:55 <Cogitri> Thank you!
2019-06-19 17:05:48 <mps> np, and sorry for impatience, i.e. killing it to early
2019-06-19 17:06:18 <mps> never will learn 'to' and 'too' diffs
2019-06-19 17:06:28 <Cogitri> No worries
2019-06-19 17:12:04 <ncopa> im pushing tags
2019-06-19 17:12:14 <_ikke_> 
ACTION braces

2019-06-19 17:12:21 <ncopa> can we hold git pushes for a few mins
2019-06-19 17:12:50 <TBK[m]> I feel like we need a GH travis specific label - no-issue-travis-is-a-snail
2019-06-19 17:12:58 <_ikke_> TBK[m]: :D
2019-06-19 17:13:43 <TBK[m]> :P
2019-06-19 17:14:52 <TBK[m]> ehhh https://github.com/alpinelinux/aports/pull/8904
2019-06-19 17:15:06 <_ikke_> uh oh
2019-06-19 17:15:20 <_ikke_> ncopa: ^
2019-06-19 17:15:37 <_ikke_> crash and denial of service
2019-06-19 17:15:49 <ncopa> Can't find node in PATH, trying to find a node binary on your system
2019-06-19 17:15:49 <ncopa> Can't find Husky, skipping post-checkout hook
2019-06-19 17:15:49 <ncopa> You can reinstall it using 'npm install husky --save-dev' or delete this hook
2019-06-19 17:16:01 <_ikke_> ugh
2019-06-19 17:16:03 <_ikke_> sigh
2019-06-19 17:16:14 <_ikke_> Another package that does that?
2019-06-19 17:16:16 <danieli> typical node.js
2019-06-19 17:16:29 <ncopa> something installed itself in git hooks of the builders
2019-06-19 17:16:34 <ncopa> some time ago
2019-06-19 17:16:37 <ncopa> i havent cleaned it up yet
2019-06-19 17:16:40 <_ikke_> I was suggesting adding GIT_CEILING_DIRECTORIES="$srcdir" on the builders
2019-06-19 17:16:42 <_ikke_> (in abuild
2019-06-19 17:16:44 <TBK[m]> time for deno ;D
2019-06-19 17:16:44 <danieli> why is software evil enough to do that?
2019-06-19 17:16:51 <danieli> i mean, in the first place
2019-06-19 17:17:00 <_ikke_> "for convenience"
2019-06-19 17:17:01 <ncopa> but i need to do the 3.10 branches on builders first
2019-06-19 17:17:22 <_ikke_> just run one command and we totaly rewire your system like we want it to be
2019-06-19 17:17:44 <danieli> nb: it might break if it's non-standard at all
2019-06-19 17:17:57 <_ikke_> If what is non-standard
2019-06-19 17:17:59 <_ikke_> ?
2019-06-19 17:18:14 <danieli> the git repo settings/hooks/etc
2019-06-19 17:18:28 <danieli> some software has working assumptions
2019-06-19 17:19:25 <_ikke_> Then that software should be fixed
2019-06-19 17:23:50 <mps> for mkimage.sh, if we use --extra-repository and have there newer pkg then in --repository will this newer package be used instead of one in --repository
2019-06-19 17:24:26 <_ikke_> I would assume so
2019-06-19 17:25:50 <ncopa> ok, i think the builders are properly switched to 3.10 gitbranch now
2019-06-19 17:25:58 <ncopa> which means it should be ok to push again
2019-06-19 17:26:06 <mps> I have linux-vanilla-4.19.53-r1 in local repo and looks like it is not taken
2019-06-19 17:26:45 <ncopa> the --extra-repository flag is somewhat non-intuitive
2019-06-19 17:26:50 <ncopa> i dont remember the details
2019-06-19 17:26:52 <_ikke_> maxice8: not sure about the 80 column warning. Almost every package breaks that rule, just due to hashes alone
2019-06-19 17:27:26 <mps> hmm, ok. will see later
2019-06-19 17:27:37 <maxice8> _ikke_: Yes it was done with too much haste, i'll disable it by default for now and work on fixing it
2019-06-19 17:28:00 <_ikke_> 5330 packages break that rule
2019-06-19 17:28:09 <mps> maxice8: _ikke_: I'd prefer 80 for most part
2019-06-19 17:28:11 <maxice8> 100% do
2019-06-19 17:28:18 <maxice8> because of sha512sums=
2019-06-19 17:28:30 <maxice8> if you don't break that rule your package is problably broken
2019-06-19 17:29:00 <_ikke_> mps: yes, me too, but we cannot enforce it on every line
2019-06-19 17:29:02 <mps> sha512sum should be in separate file anyway
2019-06-19 17:29:26 <_ikke_> why?
2019-06-19 17:29:43 <_ikke_> we would double the amount of files in aports
2019-06-19 17:30:03 <_ikke_> 10.5k -> 21K
2019-06-19 17:30:29 <mps> _ikke_: I'm not strict about this, but would be good to have expection for 80 columns only where this is needed
2019-06-19 17:30:30 <bratkartoffel> _ikke_: not quite right, we would have +1 file per aport (not per file)
2019-06-19 17:30:48 <ncopa> i dont think we need to worry too much about 80 columns
2019-06-19 17:30:55 <ncopa> i cared more about it 10 years ago
2019-06-19 17:30:58 <_ikke_> bratkartoffel: the amount of non-aport files is neglibile
2019-06-19 17:31:08 <ncopa> today people have hires screens
2019-06-19 17:31:17 <ncopa> and wide terminal windows
2019-06-19 17:31:26 <_ikke_> I still like to be able to split screen though
2019-06-19 17:32:05 <ncopa> i think its generally a good idea to split lines above 80
2019-06-19 17:32:08 <mps> I have such screens for long time, but still prefer not too wide 'window'
2019-06-19 17:32:21 <_ikke_> ncopa: I see it more as a soft-rule then a hard-rule
2019-06-19 17:32:27 <ncopa> yeah
2019-06-19 17:32:44 <mps> _ikke_: yes, also I see it as such
2019-06-19 17:32:55 <ncopa> i mean, there are valid exceptions
2019-06-19 17:32:59 <ncopa> like long urls
2019-06-19 17:33:01 <_ikke_> yes
2019-06-19 17:33:03 <_ikke_> indeed
2019-06-19 17:33:04 <mps> ofc
2019-06-19 17:33:06 <_ikke_> you don't want to split them up
2019-06-19 17:33:24 <ncopa> there are probably some valid exceptions in code too
2019-06-19 17:33:37 <ncopa> where it is more readable to have an 82 long line
2019-06-19 17:34:09 <mps> sure, I would call it do what is reasonable and not strictly follow
2019-06-19 17:35:15 <maxice8> ikke 17.0 tagged
2019-06-19 17:36:10 <_ikke_> maxice8: hmm, I don't see any new commits?
2019-06-19 17:36:30 <_ikke_> ah, sorry
2019-06-19 17:36:33 <mps> long ago I read long article about screen wideness and there described long lasting study of human possibilities about keeping attention in regards of moving eyes and head
2019-06-19 17:37:32 <ncopa> someone want to help me with adding 3.10 on this page? https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases
2019-06-19 17:37:57 <mps> according to article and my over 30 years experience I think that the wide screen is good to split them in tmux
2019-06-19 17:38:00 <_ikke_> maxice8: do we want to include apkbuild-fixer in the installation?
2019-06-19 17:38:25 <_ikke_> ncopa: I can do it if no one else would like to do it
2019-06-19 17:38:34 <maxice8> doesn't hurt to add
2019-06-19 17:38:38 <maxice8> it is just a shellscript like everything else
2019-06-19 17:38:47 <_ikke_> maxice8: it would need to be added to the conf file
2019-06-19 17:38:57 <_ikke_> https://github.com/maxice8/atools/blob/master/conf
2019-06-19 17:39:05 <_ikke_> Then it gets installed automatically
2019-06-19 17:39:12 <maxice8> ah
2019-06-19 17:39:17 <maxice8> yes, sorry i have no clue how redo works
2019-06-19 17:39:21 <_ikke_> No problem
2019-06-19 17:39:37 <_ikke_> It's mostly just shell scripts
2019-06-19 17:39:38 <mps> something other: I was right that the linux-vanilla builds dtb's for aarch64 but rootpkg skips them when making apk
2019-06-19 17:40:07 <_ikke_> maxice8: It just sources that conf file, and then iterates that array: https://github.com/maxice8/atools/blob/master/install.do#L25
2019-06-19 17:40:25 <ncopa> _ikke_: thanks alot for writing the release notes
2019-06-19 17:40:34 <mps> PureTryOut[m]: if you want to play with pine64 I can make tarball of dtb's and put somewhere for you
2019-06-19 17:40:40 <_ikke_> ncopa: You're welcome
2019-06-19 17:41:30 <mps> so, 3.10 is released officially?
2019-06-19 17:42:21 <_ikke_> it's tagged, so I would say, yes
2019-06-19 17:42:40 <mps> nice :)
2019-06-19 17:42:48 <mps> not to much late
2019-06-19 17:43:06 <ncopa> its a month too late
2019-06-19 17:43:18 <ncopa> i think we need get started earlier in october
2019-06-19 17:43:23 <ncopa> and have feature freeze earlier
2019-06-19 17:43:30 <ncopa> and maybe have stricter feature freeze
2019-06-19 17:43:34 <_ikke_> ncopa: Yes, that would make sense
2019-06-19 17:43:48 <ncopa> lots of updates we added late
2019-06-19 17:44:01 <mps> agree
2019-06-19 17:44:31 <SpaceToast> maybe also follow more standard branching practice? (i.e branch at feature freeze and cherry pick any needed commits, rather than branch at release)
2019-06-19 17:44:37 <_ikke_> maybe announce the feature freeze so that people can still suggest things that need to get in
2019-06-19 17:47:00 <_ikke_> ncopa: when does a version switch from 'bug fixes' to 'security fixes only'?
2019-06-19 17:47:34 <maxice8> ikke: tagged 17.1 of atools should have redo changes
2019-06-19 17:47:45 <_ikke_> maxice8: thanks
2019-06-19 17:48:42 <_ikke_> ncopa: does 3.7 still receive bug fixes or security fixes only?
2019-06-19 17:49:30 <ncopa> we only do bugfixes for latest stable
2019-06-19 17:49:36 <ncopa> after that its sec fixes only
2019-06-19 17:50:01 <_ikke_> ncopa: there seem to be 3 states: 'bug fixes', 'security fixes', 'on request only'
2019-06-19 17:50:29 <_ikke_> 3.6 is currently marked as 'security fixes'
2019-06-19 17:50:30 <ncopa> yeah
2019-06-19 17:50:39 <ncopa> thats wrong now
2019-06-19 17:50:41 <_ikke_> I assume it will now go to 'on request only'
2019-06-19 17:50:45 <ncopa> its 'on request only'
2019-06-19 17:50:45 <_ikke_> yes, I updated that
2019-06-19 17:50:48 <ncopa> good, thanks
2019-06-19 17:50:50 <_ikke_> and 3.7?
2019-06-19 17:50:57 <ncopa> bug fixes only
2019-06-19 17:51:03 <ncopa> 3.8 is bugfixes only
2019-06-19 17:51:09 <ncopa> bah
2019-06-19 17:51:12 <ncopa> i mean sec fixes only
2019-06-19 17:51:14 <_ikke_> ok
2019-06-19 17:51:21 <ncopa> 3.9, 3.8 and 3.7 is secfixes only
2019-06-19 17:51:23 <_ikke_> ok
2019-06-19 17:51:25 <ncopa> 3.10 is bugfixes
2019-06-19 17:52:02 <ncopa> im pushing this to prod now: https://wwwtest.alpinelinux.org/posts/Alpine-3.10.0-released.html
2019-06-19 17:52:12 <ncopa> with git commit stats
2019-06-19 17:53:00 <_ikke_> ncopa: https://imgur.com/a/kFOKGej
2019-06-19 17:53:48 <_ikke_> Doing one final check
2019-06-19 17:54:01 <ncopa> set EOL to may 1
2019-06-19 17:54:10 <_ikke_> for 3.10?
2019-06-19 17:54:13 <ncopa> yes
2019-06-19 17:54:19 <_ikke_> ok
2019-06-19 17:54:26 <ncopa> otherwise good
2019-06-19 17:55:35 <_ikke_> ncopa: ok, release notes look good
2019-06-19 17:55:48 <_ikke_> oh
2019-06-19 17:55:58 <_ikke_> linux 4.19.53, right?
2019-06-19 17:56:09 <_ikke_> yes
2019-06-19 17:57:11 <_ikke_> maxice8: the k3s build is failing
2019-06-19 18:00:06 <_ikke_> ncopa: I pushed one last update for the release notes
2019-06-19 18:01:22 <_ikke_> wiki updated
2019-06-19 18:03:09 <mps> _ikke_: I don't think number of commits is nice thing to have, looks like some sport results. however do what you prefer, this is just my personal view
2019-06-19 18:03:50 <_ikke_> mps: It has always been part of the release nots (and ncopa added it :-) )
2019-06-19 18:04:28 <mps> not on v3.9 release
2019-06-19 18:04:54 <_ikke_> mps: https://wwwtest.alpinelinux.org/posts/Alpine-3.9.0-released.html
2019-06-19 18:04:55 <mps> but, I don't mind
2019-06-19 18:05:27 <_ikke_> mps: ncopa did switch from commit order to alphabetical order to make it less about who commited how much
2019-06-19 18:05:36 <mps> hmm, someone rewrote history :)
2019-06-19 18:05:50 <_ikke_> Not that I'm aware of :)
2019-06-19 18:05:51 <SpaceToast> ++ on alphabetical order, btw :)
2019-06-19 18:06:10 <_ikke_> mps: I was involved with the 3.9.0 release notes as well
2019-06-19 18:06:32 <mps> SpaceToast: on what 'alphabet' order ;)
2019-06-19 18:06:40 <_ikke_> of the commit statistics
2019-06-19 18:06:41 <maxice8> @ncopa: https://www.reddit.com/r/linux/comments/c2kf7m/alpine_linux_3100_released/?st=jx3jroh8&sh=844e8386
2019-06-19 18:06:42 <alpine-meetbot> [REDDIT] Alpine Linux 3.10.0 released (https://alpinelinux.org/posts/Alpine-3.10.0-released.html) to r/linux | 1 points (100.0%) | 0 comments | Posted by maxice8 | Created at 2019-06-19 - 18:05:36UTC
2019-06-19 18:07:45 <_ikke_> https://news.ycombinator.com/item?id=20225588
2019-06-19 18:07:49 <mps> hmm, probably i didn't cared much about this and have wrong memory
2019-06-19 18:08:30 <mps> anyway, I don't like this numbers, but again do whatever you think is nice/good
2019-06-19 18:09:10 <mps> I'm going to drink some good red wine now. Cheers!
2019-06-19 18:09:15 <_ikke_> enjoy
2019-06-19 18:09:21 <ncopa> wow, it hit reddit before i reached to send the annoucement to alpine-announce list :)
2019-06-19 18:10:01 <_ikke_> heh :D
2019-06-19 18:11:23 <danieli> lol, straigh tto r/linux
2019-06-19 18:11:41 <ncopa> mps: do you have better suggestions on what we can include as git commit statistics?
2019-06-19 18:11:41 <danieli> u haz upvote
2019-06-19 18:12:10 <danieli> ncopa: i think what mps means is that some could consider it a popularity contest of sorts
2019-06-19 18:12:20 <_ikke_> Maybe just the names?
2019-06-19 18:12:21 <danieli> popularity is the wrong word, you know what i mean
2019-06-19 18:12:31 <ncopa> yeah
2019-06-19 18:12:35 <danieli> perhaps the % of total commits since previous tag?
2019-06-19 18:12:45 <danieli> hm, same problem with that
2019-06-19 18:13:01 <ncopa> maybe we make it a list of contributors only
2019-06-19 18:13:04 <ncopa> next time
2019-06-19 18:13:06 <danieli> otoh it would be less specific (precision would be lost)
2019-06-19 18:13:07 <ncopa> no numbers
2019-06-19 18:13:11 <danieli> yes, that's what many projects seem to do
2019-06-19 18:13:17 <danieli> alphabetically list contributors
2019-06-19 18:13:50 <ncopa> i'll do that next time
2019-06-19 18:14:38 <ncopa> now i only have 2 things left on my release checklist
2019-06-19 18:14:45 <ncopa> 3 things
2019-06-19 18:14:51 <_ikke_> Is opening a beer one of them?
2019-06-19 18:14:58 <ncopa> send announce email, make a tweet
2019-06-19 18:15:02 <ncopa> and celebrate :)
2019-06-19 18:15:02 <danieli> _ikke_: hahaha
2019-06-19 18:15:09 <ncopa> so, yeah
2019-06-19 18:15:10 <danieli> 99 bottles of beer on the wall
2019-06-19 18:15:14 <danieli> 99 bottles of beer
2019-06-19 18:15:20 <ncopa> lol
2019-06-19 18:15:26 <danieli> take down, pass it around, 98 bottles of beer on the wall
2019-06-19 18:15:47 <danieli> take one down*
2019-06-19 18:15:52 <ncopa> im super happy with this release
2019-06-19 18:15:55 <ncopa> it was a bit late
2019-06-19 18:16:02 <danieli> quality over quantity
2019-06-19 18:16:05 <_ikke_> danieli: No more beers for you, too much spelling errors :P
2019-06-19 18:16:07 <ncopa> but i think this has been super smooth
2019-06-19 18:16:22 <danieli> _ikke_: that's not even due to intoxication, I'm just a really crappy typist when I'm tired
2019-06-19 18:16:51 <ncopa> and i had lots of help
2019-06-19 18:16:52 <danieli> ncopa: even though i've mostly just watched from the sidelines, i'm impressed with all the effort everyone put into it
2019-06-19 18:16:59 <ncopa> same
2019-06-19 18:17:16 <_ikke_> Lots of work got done
2019-06-19 18:17:36 <ncopa> and it feels so incredible good to not do it alone
2019-06-19 18:25:09 <ncopa> many thanks to everyone who has contributed
2019-06-19 18:25:20 <ncopa> one way or the other
2019-06-19 18:28:16 <ncopa> \o/
2019-06-19 18:28:25 <mps> also I have feeling that Alpine quality is now better
2019-06-19 18:28:44 <ncopa> i think its improving yes
2019-06-19 18:28:56 <ncopa> and its not due to me :)
2019-06-19 18:29:41 <mps> I'm little angry to myself because I didn't made rust for some other arch'es
2019-06-19 18:30:02 <ncopa> mps: but you did *alot* other things
2019-06-19 18:30:45 <ncopa> im gonna have that beer now and rest til tomorrow
2019-06-19 18:30:50 <_ikke_> mps: We did manage to get rust 1.34 in though
2019-06-19 18:30:54 <mps> most important for me is that I learned a lot of about packaging and cleaning aports
2019-06-19 18:31:00 <ncopa> yup!
2019-06-19 18:31:02 <_ikke_> Getting it in for more arches is a nice target for 3.11 / 4.0
2019-06-19 18:31:52 <ncopa> have a good evening everyone!
2019-06-19 18:31:53 <mps> well, I had a hope that someone with a bigger interest in rust do the job
2019-06-19 18:31:56 <ncopa> and again thanks!
2019-06-19 18:32:07 <_ikke_> ncopa: Enjoy your evening
2019-06-19 18:32:26 <mps> but, ok, earth is still moving :)
2019-06-19 18:32:30 <maxice8> objections to pr8467 ?
2019-06-19 18:36:58 <_ikke_> maxice8: pushed atools-17.1
2019-06-19 18:37:17 <maxice8> nice
2019-06-19 19:20:07 <PureTryOut[m]> The release notes for 3.10 still talk about Pine64 support which is not true...
2019-06-19 19:21:51 <_ikke_> hmpf
2019-06-19 19:31:12 <ddevault> gz on the release
2019-06-19 19:32:25 <danieli> gz on contributing to making it a good one
2019-06-19 21:49:40 <mps> maxice8: your comment on reddit about not enabled kernel option is not correct. kernel 4.19.x doesn't have required option (pkcs8)
2019-06-19 22:21:47 <maxice8> mps: oh
2019-06-19 22:21:47 <maxice8> i'll fix it
2019-06-19 22:23:03 <mps> np, it's nice that you post announcement there
2019-06-19 22:28:11 <TBK[m]> for ref: https://www.reddit.com/r/linux/comments/c2kf7m/alpine_linux_3100_released/
2019-06-19 22:28:11 <alpine-meetbot> [REDDIT] Alpine Linux 3.10.0 released (https://alpinelinux.org/posts/Alpine-3.10.0-released.html) to r/linux | 35 points (84.0%) | 7 comments | Posted by maxice8 | Created at 2019-06-19 - 18:05:36UTC
2019-06-19 23:15:15 <SpaceToast> tried to look at iproute2's check() situation
2019-06-19 23:15:18 <SpaceToast> wow that's bad
2019-06-19 23:15:35 <SpaceToast> it might be possible to do some bwrap magic, but a lot of the stuff is required to get anywhere :/
2019-06-19 23:59:14 <SpaceToast> maxice8: sorry it took a while to review apkbuild-fixer stuff, but I wanted to make sure I got through all the anomalies :)
2019-06-20 00:00:19 <maxice8> No worries and thanks for reviewing it
2019-06-20 00:00:48 <maxice8> I am not in a particular hurry to get that merged
2019-06-20 00:01:02 <SpaceToast> ok
2019-06-20 00:01:13 <SpaceToast> I didn't find anything besides that one issue though
2019-06-20 00:09:38 <maxice8> yes that means i did a decent job on apkbuild-fixer
2019-06-20 00:09:41 <maxice8> :D
2019-06-20 00:10:02 <SpaceToast> yup :)
2019-06-20 00:19:10 <maxice8> fixed vboot-utils
2019-06-20 00:39:56 <maxice8> PureTryOut: libksysguard failed on ppc64le due to qt5-qtwebengine not being available there
2019-06-20 03:18:30 <kpcyrd> awesome work on 3.10.0 :)
2019-06-20 06:22:35 <mps> announcement/news with headline "Alpine Linux 3.10.0 released" is on lwn.net
2019-06-20 06:45:13 <tmhoang> mps: link sir
2019-06-20 06:47:53 <mps> tmhoang: http://lwn.net
2019-06-20 06:48:52 <tmhoang> I don't have subscription zzz
2019-06-20 06:48:58 <tmhoang> life is hard
2019-06-20 06:49:09 <SpaceToast> https://lwn.net/Articles/791508/ :)
2019-06-20 06:50:21 <SpaceToast> also https://www.phoronix.com/scan.php?page=news_item&px=Alpine-Linux-3.10
2019-06-20 07:42:42 <mps> maxice8: you wrote that you fixed vboot-utils, can I push it?
2019-06-20 07:47:01 <mps> uhmm, there is a lot of things in GH pr 8913
2019-06-20 08:07:38 <ncopa> morning
2019-06-20 08:29:23 <danieli> morning
2019-06-20 08:44:40 <mps> danieli: good morning :)
2019-06-20 08:45:01 <ncopa> already 74 commits since 3.10 release :)
2019-06-20 08:47:10 <mps> people waited for release and didn't wanted to impede process, probably
2019-06-20 08:48:53 <mps> I wanted to enable some drivers for armhf/armv7 but didn't because didn't wanted to possibly break something
2019-06-20 08:49:02 <ncopa> yeah
2019-06-20 08:49:11 <ncopa> lets break things now :)
2019-06-20 08:49:35 <ncopa> we should set goals for 3.11
2019-06-20 08:49:49 <ncopa> i think migrate to gitlab is one of them
2019-06-20 08:49:50 <terror> mawk in community :)
2019-06-20 08:50:12 <ncopa> and have docs.a.o officially online
2019-06-20 08:50:26 <mps> when we at break things, https://patchwork.alpinelinux.org/patch/4902/ ifupdown wait for review
2019-06-20 08:50:53 <terror> Maybe archive some of the old docs and guides that are not applicable anymore?
2019-06-20 08:51:11 <danieli> i have some personal goals for 3.11 too
2019-06-20 08:51:23 <danieli> ALPINE/DOS 3.11 lmao
2019-06-20 08:51:38 <mps> terror: we have three awk pkg's, gawk nawk and mawk
2019-06-20 08:52:18 <mps> and busybox applet
2019-06-20 08:52:58 <hjaekel> my goal for 3.11 is: bring the core GIS libraries GDAL, Geos, Proj and PostGIS and their dependencies to community
2019-06-20 08:53:22 <terror> Yup mps, I contributed mawk. It's on testing though.
2019-06-20 08:53:28 <mps> would be nice to elaborate about them, i.e. pros and cons to see which of them should be moved where
2019-06-20 08:53:35 <terror> It's been on testing since 3.7 probs.
2019-06-20 08:53:52 <terror> In some specific scenarios, mawk is orders of magnitude faster
2019-06-20 08:53:58 <PureTryOut[m]> My goal for 3.11 is to get as much of KDE to community as possible
2019-06-20 08:55:07 <terror> Shameless plug for https://github.com/mterron/swuniq
2019-06-20 08:55:49 <terror> I'm the only user in the world, can't believe it didn't exist till I hacked it together
2019-06-20 08:55:57 <mps> I don't have specific goal except improving quality and stability
2019-06-20 08:56:30 <terror> Alpine has been rock solid for me since 3.0 probably. I've had luck with hardware I guess
2019-06-20 08:56:51 <ncopa> i think we should try get at least one more arch for rust
2019-06-20 08:57:59 <mps> hope that the Cogitri will do what he promised about rust. I will help him where I can
2019-06-20 08:59:04 <mps> I plan to work more on arm, u-boot, kernel and tools
2019-06-20 08:59:27 <ncopa> i have some thoughts on abuild
2019-06-20 09:00:02 <ncopa> i think we should start abuild as root, it installs the deps as root, but run the build as non-root
2019-06-20 09:00:19 <ncopa> so it drops privs instead of elevate them
2019-06-20 09:00:34 <ncopa> i also would like to move the working dirs
2019-06-20 09:00:40 <mps> how this is safe
2019-06-20 09:01:00 <ncopa> to /var/lib/abuild and /var/tmp/abuild
2019-06-20 09:01:23 <ncopa> so the build does not happen under aports git checkout
2019-06-20 09:03:02 <mps> what about src and pkg dirs setting to somewhere else instead in aport dir
2019-06-20 09:08:10 <mps> we should upgrade kernel to 5.2 at least (when it released). it have gpu drivers for MALI (arm) gpu's
2019-06-20 09:08:51 <mps> and it will be next LTS, I think
2019-06-20 09:10:46 <Cogitri> mps: Yup, once the Rust 1.35 PR has been merged and webkit2gtk works on armv7 (since that kind of has priority, the CVEs are kinda bad). Did the compilation over night work?
2019-06-20 09:11:16 <Cogitri> If it didn't, can we disable webkit2gtk 2.24.2 on armhf/armv7 and the builders will keep 2.22.2 for these arches?
2019-06-20 09:11:56 <Cogitri> I mean that certainly isn't a good way but I'd prefer having it patched on a few arches at least instead of blocking on this for much longer
2019-06-20 09:12:02 <mps> Cogitri: sorry, I forgot to run it last night. It is running now for some time
2019-06-20 09:12:15 <Cogitri> Alright, thanks :)
2019-06-20 09:12:52 <ncopa> mps: thats what i mean, src and pkg dirs should be under /var/tmp/abuild
2019-06-20 09:13:07 <mps> nice :)
2019-06-20 09:13:28 <ncopa> and PKGDEST should be /var/lib/ or similar
2019-06-20 09:13:51 <mps> also, nice
2019-06-20 09:37:35 <PureTryOut[m]> maxice8: I've fixed the url of the plasma meta package
2019-06-20 09:48:04 <mpmc> Plasma/KDE on alpine O.O
2019-06-20 09:55:20 <PureTryOut[m]> Yeah, great isn't it? 😃
2019-06-20 09:57:53 <Cogitri> We also have GNOME now, things are starting to shape up in that department, mpmc :P
2019-06-20 10:32:13 <SpaceToast> latest-stable still points to 3.9 on mirrors
2019-06-20 10:35:49 <ncopa> oh yes
2019-06-20 10:35:53 <ncopa> that needs to be fixed
2019-06-20 10:38:38 <ncopa> done
2019-06-20 11:13:59 <PureTryOut[m]> cogitri: you should probably update https://wiki.alpinelinux.org/wiki/Gnome_Setup btw
2019-06-20 11:14:30 <Cogitri> Oh, true. Thanks for the reminder
2019-06-20 11:15:32 <PureTryOut[m]> Np!
2019-06-20 11:26:30 <maxice8> PureTryOut: merged
2019-06-20 11:26:54 <PureTryOut[m]> Thanks!
2019-06-20 11:31:17 <ncopa> fun fact: totally 28577 packages did not change from v3.9 to v3.10
2019-06-20 11:33:09 <_ikke_> quite a lot
2019-06-20 11:34:00 <PureTryOut[m]> Damn
2019-06-20 11:34:39 <Cogitri> ncopa: That includes subpackages, I assume?
2019-06-20 11:35:55 <_ikke_> Cogitri: most likely, yes
2019-06-20 11:36:40 <maxice8> yes, there are 5324 packages reading into aports
2019-06-20 11:49:58 <ncopa> that is apk files
2019-06-20 11:50:08 <ncopa> so subpackages * number of arches
2019-06-20 11:52:34 <ncopa> ubuntu will drop i386 support
2019-06-20 11:52:41 <danieli> i heard
2019-06-20 11:52:51 <danieli> according to popularity contest, a fair amount of people still use it
2019-06-20 11:55:16 <ncopa> will probably lead to more bugs in 32 bit apps from upstream
2019-06-20 11:55:31 <ncopa> which will affect our armv7 and x86
2019-06-20 11:56:32 <PureTryOut[m]> The problem isn't really dropping 32-bit support, the problem is dropping multilib support
2019-06-20 12:28:12 <danieli> i really hate qt sometimes
2019-06-20 13:02:01 <maxice8> pr7606 can be closed
2019-06-20 13:41:05 <maxice8> pr7630 and pr7606 can be closed
2019-06-20 16:05:12 <mps> Cogitri: webkit2gtk finished with this error: cc1plus: out of memory allocating 65536 bytes after a total of 3499016192 bytes
2019-06-20 16:30:30 <Cogitri> Hm, so I guess your RAM has filled up?
2019-06-20 16:30:52 <Cogitri> Or is that the limit what 32-bit applications can allocate?
2019-06-20 16:31:04 <jwh> looks close e
2019-06-20 16:31:04 <jwh> h
2019-06-20 16:33:23 <mps> Cogitri: looks like 32-bit limit, build box have a lot more RAM
2019-06-20 16:34:39 <Cogitri> Hm, alright, thanks
2019-06-20 16:34:41 <mps> 
ACTION wonder how he manage to build rust, mesa and what not on this box

2019-06-20 16:34:52 <Cogitri> I guess I'll disable webkit2gtk for armhf and armv7 then
2019-06-20 16:35:26 <mps> iirc, you talked with upstream. what they say
2019-06-20 16:35:31 <Cogitri> mps: Those do not make unified compilation units which take up a ton of RAM
2019-06-20 16:36:09 <Cogitri> Webkit2gtk 2.26 should have an option to disable that though, so maybe I can re-enable those arches then
2019-06-20 16:36:42 <Cogitri> Upstream said that they don't support compilation on 32-bit arches and suggested either waiting for 2.26 or crosscompile
2019-06-20 16:36:49 <mps> aha, good to remember
2019-06-20 16:37:05 <Cogitri> Since we can't crosscompile we'll have to wait for 2.26 and disable on armhf/armv7 until then
2019-06-20 16:37:20 <Cogitri> One thing though: Will webkit2gtk 2.22.x remain in the repos for the disabled arches?
2019-06-20 16:38:44 <mps> I think so
2019-06-20 16:39:35 <jwh> hm
2019-06-20 16:39:39 <jwh> does rpm5.org work for you guys?
2019-06-20 16:39:51 <Cogitri> Good
2019-06-20 16:40:26 <Cogitri> Nop
2019-06-20 16:40:32 <jwh> ah good
2019-06-20 16:40:45 <jwh> ok, anyone have popt-1.16.tar.gz?
2019-06-20 16:42:06 <maxice8> pr6661 can be closed, merged with modifications
2019-06-20 16:43:15 <jwh> nm, go tit
2019-06-20 16:43:18 <jwh> got it*
2019-06-20 17:08:25 <Cogitri> tmhoang: Could ypu test pr8257 on s390x?
2019-06-20 17:12:44 <tmhoang> <Cogitri>: Thanks, I'm checking
2019-06-20 17:13:05 <revolutionary> hi comrades!
2019-06-20 17:15:34 <danieli> hello
2019-06-20 17:16:10 <Cogitri> tmhoang: I have to thank for testing :)
2019-06-20 17:28:53 <maxice8> uhhh
2019-06-20 17:28:59 <maxice8> libtorrent-rasterbar on https://build.alpinelinux.org/buildlogs/build-edge-x86_64/testing/libtorrent-rasterbar/libtorrent-rasterbar-1.2.1-r0.log
2019-06-20 17:29:06 <maxice8> is still going after a very long while
2019-06-20 17:29:19 <maxice8> i think it is stuck on tests
2019-06-20 17:31:15 <maxice8> Can someone kick the edge builders ?
2019-06-20 17:31:59 <danieli> only a handful of people can, they'll probably be around soon
2019-06-20 17:48:00 <jwh> umm
2019-06-20 18:01:38 <tmhoang> Cogitri: not sure if it hangs or building at : [100%] Building CXX object Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/__/__/DerivedSources/JavaScriptCore/unified-sources/UnifiedSource-6cbc989f-2.cpp.o
2019-06-20 18:01:46 <tmhoang> my x86 box is upgrading ...
2019-06-20 18:01:54 <tmhoang> will let you know tmr morning
2019-06-20 18:02:15 <SpaceToast> Unified sources can take a very long time to build
2019-06-20 18:02:20 <tmhoang> ok cool
2019-06-20 18:02:24 <Cogitri> UnifiedSources can take a rather long time to compile, so give it a bit I guess :)
2019-06-20 18:02:29 <SpaceToast> But it might be additionally slowed by a low FD limit
2019-06-20 18:02:47 <tmhoang> by FD you mean fd ? :D
2019-06-20 18:02:57 <SpaceToast> Yeah, I'm on my phone :)
2019-06-20 18:03:10 <SpaceToast> I recommend setting it to something reasonable like 2^32
2019-06-20 18:03:50 <SpaceToast> It used to be quite the trouble causer over at Gentoo with Firefox, since, well, every user has to effectively run a builder
2019-06-20 18:04:33 <SpaceToast> If ld runs out of fds, it runs a very expensive garbage collection procedure, which can happen over and over again and thus take forever
2019-06-20 18:04:56 <SpaceToast> In extreme circumstances it might even fail the build if the gc doesn't find anything it can free up
2019-06-20 18:05:02 <maxice8> Need someone to kick the builders
2019-06-20 18:05:22 <PureTryOut[m]> _ikke_: could you restart the CI of pr8936?
2019-06-20 18:05:37 <danieli> could force push
2019-06-20 18:05:39 <PureTryOut[m]> (or anyone else with access to Drone tbh)
2019-06-20 18:06:18 <PureTryOut[m]> Damn do I miss Gitlab's feature where the MR author can restart the pipelines him/herself
2019-06-20 18:06:20 <PureTryOut[m]> I prefer not to really
2019-06-20 18:06:34 <Cogitri> But why?
2019-06-20 18:09:17 <PureTryOut[m]> Not as clean really, but I guess I'll do it. Doesn't work if there is nothing to force push though 😉
2019-06-20 18:20:00 <maxice8> Need builders to be reset
2019-06-20 18:26:17 <mps> maxice8: reset or restart builds
2019-06-20 18:27:21 <Cogitri> PureTryOut: Well, I don't see what's unclean about that, but it's certainly easier for everyone :)
2019-06-20 18:27:46 <maxice8> mps: restart builds
2019-06-20 18:27:55 <maxice8> i commited libtorrest-rasterbar upgrade and the check() hang
2019-06-20 18:28:01 <maxice8> i pushed a commit to disable check
2019-06-20 18:28:24 <mps> let's see if it work
2019-06-20 18:28:59 <maxice8> Should be only the edge builders
2019-06-20 18:29:27 <mps> I think now it do only edge
2019-06-20 18:30:06 <mps> looks like they work now
2019-06-20 18:30:19 <maxice8> yes, libtorrent-rasterbar is only on testing/ so only edge builders are stuck
2019-06-20 18:31:20 <mps> https://build.alpinelinux.org/ shows that they are working, but yes, they could be stuck
2019-06-20 18:31:47 <maxice8> Yes it appears they are working
2019-06-20 18:32:18 <maxice8> but they are hanged in the check stage of libtorrent-rasterbar
2019-06-20 18:32:35 <maxice8> https://build.alpinelinux.org/buildlogs/build-edge-x86_64/testing/libtorrent-rasterbar/libtorrent-rasterbar-1.2.1-r0.log the test after test_privacy is making them hang
2019-06-20 18:33:23 <mps> aha, I think I don't have rights to fully restart builders, only retry
2019-06-20 18:34:29 <maxice8> oh
2019-06-20 18:34:31 <maxice8> well, we will have to wait then :D
2019-06-20 18:35:23 <mps> yes, till someone with rights see your message
2019-06-20 19:12:41 <PureTryOut[m]> So I want to restart the Drone CI for a PR of mine, but I have nothing to force push it with. What to do? 😛
2019-06-20 19:14:46 <Cogitri> git commit --amend
2019-06-20 19:16:04 <PureTryOut[m]> Oh that works without changes, interesting
2019-06-20 19:16:10 <PureTryOut[m]> Thanks!
2019-06-20 19:17:28 <_ikke_> pong
2019-06-20 19:18:01 <maxice8> _ikke_: can you restart the edge builders ?
2019-06-20 19:18:12 <_ikke_> Some of them
2019-06-20 19:18:39 <maxice8> well any other than armv7 needs to be restarted
2019-06-20 19:18:39 <_ikke_> most notably, not ppc64le and s390x
2019-06-20 19:21:41 <maxice8> ah, those can be dealt with later
2019-06-20 19:21:51 <maxice8> :D please restart any edge builders you can they are deadlocked
2019-06-20 19:27:36 <_ikke_> ok, most should be fixed now
2019-06-20 19:27:56 <maxice8> thanks
2019-06-20 19:32:09 <maxice8> wtf ?
2019-06-20 19:32:22 <_ikke_> .?
2019-06-20 19:32:29 <maxice8> i passed options="!check" to libtorrent-rasterbar and they still run the testsuite
2019-06-20 19:32:55 <_ikke_> Not sure, but it might be that they are still building an older version
2019-06-20 19:33:22 <maxice8> I pushed something new, shouldn't they fetch the latest from git ?
2019-06-20 19:34:32 <maxice8> well at least i found out which test hangs
2019-06-20 19:34:34 <maxice8> test_ssl
2019-06-20 19:34:40 <_ikke_> yes, I could've told you
2019-06-20 19:34:56 <maxice8> which this time failed on armhf and aarch64
2019-06-20 19:34:59 <_ikke_> I basically just killed that process that hanged
2019-06-20 19:35:11 <maxice8> but is now hanging x86_64 again
2019-06-20 19:35:30 <maxice8> oh
2019-06-20 19:36:07 <_ikke_> x86_64 is not hanging from what I can see
2019-06-20 19:36:28 <maxice8> yes
2019-06-20 19:36:39 <maxice8> very confusing
2019-06-20 19:36:39 <_ikke_> it's building qbittorrent-nox now
2019-06-20 19:37:02 <_ikke_> and that failed now
2019-06-20 19:38:16 <clandmeter> hmm
2019-06-20 19:38:28 <_ikke_> ?
2019-06-20 19:38:31 <clandmeter> did we change ruby in 3.10?
2019-06-20 19:38:47 <maxice8> clandmeter: Not as far as i remember
2019-06-20 19:38:56 <maxice8> there is a 2.6.3 upgrade PR open rotting away
2019-06-20 19:40:21 <clandmeter> my docker container cannot find bundler with 3.10
2019-06-20 19:41:56 <clandmeter> ah its bundler which is updated
2019-06-21 00:57:52 <jwh> hm
2019-06-21 00:57:58 <jwh> zerotier busted in edge?
2019-06-21 00:59:25 <jwh> oh nm
2019-06-21 09:01:27 <terror> Is anyone having problems with perl-error on 3.10.0?
2019-06-21 09:01:52 <terror> # apk fix
2019-06-21 09:01:52 <terror> (1/1) Installing perl-error (0.17027-r0)
2019-06-21 09:01:52 <terror> ERROR: perl-error-0.17027-r0: BAD signature
2019-06-21 09:01:52 <terror> 1 error; 1623 MiB in 364 packages
2019-06-21 09:03:07 <_ikke_> let me check
2019-06-21 09:03:30 <danieli> terror: which mirror?
2019-06-21 09:03:51 <terror> http://dl-cdn.alpinelinux.org
2019-06-21 09:04:04 <danieli> which architecture?
2019-06-21 09:04:10 <terror> x86_64
2019-06-21 09:04:26 <_ikke_> no issue for me
2019-06-21 09:04:33 <_ikke_> try apk update first
2019-06-21 09:04:44 <terror> That's what I did actualy
2019-06-21 09:04:51 <terror> apk update and then apk fi
2019-06-21 09:04:53 <terror> x
2019-06-21 09:07:08 <terror> --force-refresh didn't help either
2019-06-21 09:07:32 <danieli> i purged it on fastly
2019-06-21 09:07:35 <danieli> full URL is http://dl-cdn.alpinelinux.org/alpine/v3.10/main/x86_64/perl-error-0.17027-r0.apk
2019-06-21 09:08:36 <terror> Manually installing the .apk worked
2019-06-21 09:09:11 <terror> Not sure why it didn't like the package. Maybe because I was pulling from latest-stable instead of v3.10?
2019-06-21 09:22:39 <jwh> can uh
2019-06-21 09:22:45 <jwh> can someone update popt with a new url?
2019-06-21 09:35:18 <Cogitri> I think pr8257 is now good to go, gonna backport it to 3.10 now
2019-06-21 10:04:53 <Cogitri> Hm, should I upgrade webkit2gtk on 3.7 and 3.8 too?
2019-06-21 10:07:59 <mps> is it security fix?
2019-06-21 10:08:41 <mps> or 'important' bugfix
2019-06-21 10:10:26 <Cogitri> More than 20 CVEs would be fixed
2019-06-21 10:10:39 <Cogitri> For a webfacing component, so I'd say it's a rather important security fix
2019-06-21 10:10:55 <mps> then yes
2019-06-21 10:11:22 <Cogitri> Okie, thanks
2019-06-21 10:16:23 <mps> would be good to ask someone from security team
2019-06-21 10:21:11 <ncopa> webkit2gtk is in community?
2019-06-21 10:21:55 <Cogitri> Yup
2019-06-21 10:21:59 <ncopa> it is in community so we don't need spend time on fixing it in old stable branches, like 3.7 and 3.8
2019-06-21 10:24:00 <Cogitri> Alright, I guess I'm not too used to this branching thing yet. Thanks for the info
2019-06-21 10:24:05 <Cogitri> Building on 3.9 now
2019-06-21 10:24:14 <mps> oh, yes, forgot it is in community. community is supported till next stable release, I think
2019-06-21 10:26:13 <ncopa> i dont think we need worry about 3.9 even
2019-06-21 10:26:19 <ncopa> since 3.10 is out
2019-06-21 10:27:04 <Cogitri> Hm, it's not too much effort and 3.10 just got out, so I wouldn't mind backporting it
2019-06-21 10:27:18 <Cogitri> Already applied it, compiling now
2019-06-21 10:27:24 <ncopa> ok
2019-06-21 10:28:23 <mps> we could add on every main release note something like 'upgrade ASAP'
2019-06-21 10:29:18 <ncopa> we need proper security advisory program
2019-06-21 10:30:54 <danieli> i think your idea about using redmine tickets as the underlying data source would be decent
2019-06-21 10:31:43 <ncopa> gitlab tickets in the future
2019-06-21 10:32:09 <danieli> well yeah
2019-06-21 10:32:16 <danieli> i forgot about that for a sec :)
2019-06-21 10:34:44 <_ikke_> jwh: update popt with a new url?
2019-06-21 10:35:20 <jwh> rpm5.org disappeared a few days ago
2019-06-21 10:35:34 <mps> is it too early to upgrade mesa to 19.1.0, which is marked as dev release and noted that the 19.1.1 will stable
2019-06-21 10:36:03 <mps> I tested build and it works.
2019-06-21 10:36:37 <mps> would like to add panfrost and lima dri drivers in mesa
2019-06-21 10:38:42 <_ikke_> jwh: Do you know the new url?
2019-06-21 10:38:58 <Cogitri> Pretty sure we agreed in the PR for that to wait for 19.1.1
2019-06-21 10:39:01 <ncopa> mps: will mesa 19.1.1 be the next stable?
2019-06-21 10:39:28 <mps> they announced right this, i.e. it will be next stable
2019-06-21 10:39:36 <ncopa> ok
2019-06-21 10:39:43 <ncopa> then i dont mind to push it now
2019-06-21 10:39:49 <mps> so, I can post patch
2019-06-21 10:40:00 <mps> oh, or you will do
2019-06-21 10:40:16 <ncopa> i can apply a patch for you
2019-06-21 10:40:36 <Cogitri> pr8762 ?
2019-06-21 10:40:36 <ncopa> i was thinkging that 19.0.x was stable 19.1.x was dev and 19.2.x would be next stable
2019-06-21 10:40:40 <ncopa> similar to gtk/glib
2019-06-21 10:40:48 <mps> aha, will post to pw.a.o in few minutes. need to clean aports tree a little
2019-06-21 10:40:59 <ncopa> we have a pr as Cogitri mentions
2019-06-21 10:41:09 <ncopa> lets use that
2019-06-21 10:41:21 <mps> I see let me see if it correct
2019-06-21 10:41:28 <PureTryOut[m]> Yeah it was agreed upon to wait for the next stable release
2019-06-21 10:41:40 <ncopa> we by mistake pushed mate 1.21.x to v3.9 iirc
2019-06-21 10:41:41 <mps> Cogitri: did you tested build
2019-06-21 10:41:51 <ncopa> where 1.21.x was dev branch
2019-06-21 10:42:26 <ncopa> i dont mind to have a dev branch in edge, but we should be confident that it gets stable before next stable alpine release
2019-06-21 10:42:33 <Cogitri> mps: Of?
2019-06-21 10:42:55 <mps> I think 19.1.0 is stable prerelease
2019-06-21 10:43:10 <Cogitri> If you mean mesa, then no, I just happened to see the PR :)
2019-06-21 10:43:17 <mps> Cogitri: yes
2019-06-21 10:43:35 <Cogitri> Yup, mesa's x.x.0 releases are preleases
2019-06-21 10:44:00 <mps> I tested build on aarch64 and x86_64
2019-06-21 10:44:09 <mps> went ok
2019-06-21 10:44:30 <mps>                          https://github.com/alpinelinux/aports/pull/8762
2019-06-21 10:44:43 <jwh>      if( db->mallocF� �d ) goto select_end;
2019-06-21 10:44:46 <jwh> thats cute
2019-06-21 10:44:51 <mps> sorry, libinput is not good after upgrade
2019-06-21 10:47:41 <mps> mesa GH PR 8762 is ok, as I see
2019-06-21 10:49:01 <Cogitri> I'd still opt for waiting for 19.1.1, even on edge. It shouldn't take too long until it's released now, maybe a few days now
2019-06-21 10:50:58 <mps> I expect it in a week or two
2019-06-21 11:11:10 <Cogitri> PureTryOut: Have you been working on the xdg-desktop-portal stuff already? If not I'm gonna do it now and ping you to test xdg-desktop-portal-kde :)
2019-06-21 11:14:01 <PureTryOut[m]> I have not no
2019-06-21 11:31:03 <ncopa> Cogitri and maxice8: you should be able to see security issues on bugs.a.o now
2019-06-21 11:37:01 <danieli> ncopa: it looks correct, they're in the assignee list on issues in the alpine security project
2019-06-21 11:42:44 <Cogitri> ncopa: Thanks :)
2019-06-21 12:32:12 <ncopa> Cogitri: so for pr8951 you can add a line in commit message: "fixes #10599"
2019-06-21 12:40:03 <mps> iproute2 is updated to 5.1.x, does that mean we can upgrade kernel also
2019-06-21 12:40:41 <ncopa> i want wait with kernel til new lts is out
2019-06-21 12:40:51 <Cogitri> ncopa: Oh, will add
2019-06-21 12:43:35 <_ikke_> Not sure if it matters, but due to the amount of PRs created, we soon will overlap with the redmine issue numbers
2019-06-21 12:43:47 <_ikke_> or at least, in the same ficinity
2019-06-21 12:45:18 <Cogitri> http://dpaste.com/2S08PQN <- seems like our qt5-qtbase is missing a dep on cups?
2019-06-21 12:45:21 <_ikke_> If we add fixes #8123 to the commit message, it might close a PR in that case
2019-06-21 12:45:30 <Cogitri> s/cups/cups-dev/
2019-06-21 12:45:30 <alpine-meetbot> Cogitri meant to say: http://dpaste.com/2S08PQN <- seems like our qt5-qtbase is missing a dep on cups-dev?
2019-06-21 12:49:32 <mps> I'm kidding a little. ofc, we should wait for LTS kernel
2019-06-21 12:59:34 <Cogitri> ncopa: Should I fix both #10597 and #10598 with the webkit2gtk bump on edge?
2019-06-21 13:33:13 <ncopa> Cogitri: no, only #10598
2019-06-21 13:33:41 <Cogitri> Alright
2019-06-21 13:33:57 <ncopa> the #10597 is a "tracker" issue which is marked 100% done when all the subissues are resolved
2019-06-21 13:34:16 <ncopa> i think we want to do that differently with gitlab
2019-06-21 13:34:22 <Cogitri> Ahh, got it!
2019-06-21 13:34:34 <Cogitri> Pushed to the PRs now
2019-06-21 13:35:13 <ncopa> is this one for edge? https://github.com/alpinelinux/aports/pull/8951
2019-06-21 13:35:25 <ncopa> there is [3.10] and [3.9]
2019-06-21 13:35:38 <ncopa> edge is [3.11] now since the 3.10 release is out
2019-06-21 13:35:46 <ncopa> and 3.10-stable is branched
2019-06-21 13:36:42 <Cogitri> pr8257 is for edge
2019-06-21 13:38:14 <ncopa> ok
2019-06-21 13:38:28 <ncopa> "Disable armv7/armhf" is problematic for stable branches
2019-06-21 13:38:53 <ncopa> it means that the package will disapear
2019-06-21 13:40:44 <Cogitri> Oh, I have asked previously and someone told me that the old package will stay
2019-06-21 13:41:54 <Cogitri> Hm, that's a problem then
2019-06-21 13:42:20 <ncopa> im testing it in my armv7 lxc
2019-06-21 13:42:24 <Cogitri> I guess I'll have to try CLang on armhf/armv7 then, but that seems kinda broken too.
2019-06-21 13:42:46 <Cogitri> ncopa: mps already did, it runs out of RAM on 32-bit machines
2019-06-21 13:43:03 <ncopa> the builder is running on 64 bit kernel with 32 bit personality container
2019-06-21 13:43:07 <Cogitri> Because a single cc1plus process can't allocate enough memory for the massive unified sources
2019-06-21 13:43:16 <ncopa> oh?
2019-06-21 13:43:20 <Cogitri> Oh, that changes thing up!
2019-06-21 13:43:33 <Cogitri> If it runs on a 64-bit kernel it should work :)
2019-06-21 13:43:41 <ncopa> may still run out of address space
2019-06-21 13:44:27 <ncopa> its cmake
2019-06-21 13:44:43 <ncopa> i wonder if it would help to use ninja backend
2019-06-21 13:45:10 <Cogitri> I don't see how that could have any impact on that
2019-06-21 13:45:22 <ncopa> i have had problems before with packages that compile fine, but get problem during linking
2019-06-21 13:45:34 <ncopa> the linking takes lots of memory
2019-06-21 13:45:43 <ncopa> specially if LTO is used
2019-06-21 13:46:12 <ncopa> building it with make -j1 makes it work, but gets dog slow on aarch64 (95 cores on idle)
2019-06-21 13:46:19 <Cogitri> Seeing that it fails on g++ and not with ldd I'm somewhat confident that it fails before linking
2019-06-21 13:46:19 <ncopa> which is painful
2019-06-21 13:46:22 <Cogitri> s/ldd/ld/ of course
2019-06-21 13:46:22 <alpine-meetbot> Cogitri meant to say: Seeing that it fails on g++ and not with ld I'm somewhat confident that it fails before linking
2019-06-21 13:46:47 <Cogitri> I also don't think -j1 changes something since it's a single process being unable to allocate enough memory
2019-06-21 13:47:21 <ncopa> with ninja you can have different parallel setting for linking
2019-06-21 13:47:36 <ncopa> so you can do -j96 for compile time, but much lower setting for linking
2019-06-21 13:48:09 <Cogitri> Ah, but the amount of make jobs doesn't change the outcome 😅
2019-06-21 13:48:17 <mps> Cogitri: regarding disappearing disabled pkg's. I told you that, having in mind it will not disappear right 'now' when it is disabled. sorry for confusion
2019-06-21 13:48:53 <Cogitri> Ah, alright then mps, guess I didn't get that correctly :)
2019-06-21 13:49:29 <mps> nor I answered clearly :)
2019-06-21 13:49:53 <Cogitri> Well, I guess it should work on 64-bit kernels with 32-bit userland seeing that it works on x86 with a x86_64 kernel too, @ncopa
2019-06-21 13:55:23 <ncopa> Cogitri: you are right. its a single cc1plus process
2019-06-21 13:55:33 <ncopa> currently up in use of 545M
2019-06-21 13:56:00 <ncopa> oh...  1318m
2019-06-21 13:56:54 <Cogitri> It'll go up to more than 3.5G later on :)
2019-06-21 14:26:02 <mps> maxice8: I'm not versed in English but shouldn't be word 'limit' (limit on arch name) replaced by 'disabled'?
2019-06-21 14:26:16 <mps> in commits, I mean
2019-06-21 14:26:29 <maxice8> limit or disable both work
2019-06-21 14:29:25 <mps> as I wrote I'm not native speaker, but to me limit have somewhat different semantic. sorry if I'm wrong
2019-06-21 15:26:56 <ncopa> the armv7 builder is still chewing on webkit2gtk
2019-06-21 15:27:23 <ncopa> so they switched to unified sources for performance reasons
2019-06-21 15:27:33 <_ikke_> What is unified sources
2019-06-21 15:27:34 <ncopa> on x86_64 i assume
2019-06-21 15:27:35 <_ikke_> ?
2019-06-21 15:27:50 <ncopa> https://blogs.gnome.org/mcatanzaro/2018/02/17/on-compiling-webkit-now-twice-as-fast/
2019-06-21 15:28:25 <ncopa> baiscally they concatenate all c++ files, so the headers only needs to be parsed once
2019-06-21 15:29:06 <ncopa> but it kills parallelism, as its only a single process building it all
2019-06-21 15:31:19 <danieli> yeah, it's a double-edged sword
2019-06-21 15:39:39 <m-a-p> Hello, is there a way of creating an iso from an Alpine chroot?
2019-06-21 15:54:12 <ncopa> genisofs?
2019-06-21 15:58:53 <m-a-p> Thanks ncopa, I'm trying to create a chroot, add apks to it and then recreate an iso which I can then burn on a USB to boot with my added packages.
2019-06-21 15:59:25 <_ikke_> m-a-p: also take a look at https://wiki.alpinelinux.org/wiki/How_to_make_a_custom_ISO_image_with_mkimage
2019-06-21 16:05:45 <mps> PureTryOut[m]: and other pmOS people: do you know if any x86 based device have MALI gpu? I can't find anyone
2019-06-21 16:06:35 <mps> asking because want to limit MALI mesa drivers only to arm alpine arch'es
2019-06-21 16:07:15 <Danct12> I don't think those exists
2019-06-21 16:07:23 <PureTryOut[m]> Not that I know
2019-06-21 16:07:37 <PureTryOut[m]> Mali mesa drivers as in Lima? Not that I already have a PR open for it
2019-06-21 16:07:43 <Danct12> usually those would have PowerVR (oh god no) or just IGD
2019-06-21 16:07:52 <mps> ok, thanks. I think it is safe to limit it only to arm
2019-06-21 16:08:24 <mps> I build mesa with enabled lima and panfrost already
2019-06-21 16:09:24 <mps> Danct12: looks like PoverVR is not available anywhere
2019-06-21 16:10:16 <Danct12> well, i don't think intel manufactures SoC's with powervr anymore
2019-06-21 17:19:40 <Cogitri> ncopa: That means the build hasn't failed yet?
2019-06-21 18:00:19 <PureTryOut[m]> mps: not sure if you read it, but I already have a PR open for Lima support in Mesa
2019-06-21 18:00:25 <PureTryOut[m]> Requires a newer Mesa than we currently have though
2019-06-21 18:05:33 <mps> PureTryOut[m]: no, not seen it.
2019-06-21 18:06:09 <mps> I have also panfrost besides lima
2019-06-21 18:06:31 <mps> and I'm using it right now ;)
2019-06-21 18:07:07 <mps> with kernel 5.2-rc5
2019-06-21 18:08:05 <mps> works really good on aarch64 chromebook with alpine 3.10 :)
2019-06-21 18:09:48 <mps> but now I'm struggling with rust on arm
2019-06-21 18:11:53 <Cogitri> Working on that right now
2019-06-21 18:13:13 <mps> PureTryOut[m]: I've only seen your patch to upgrade mesa
2019-06-21 18:13:44 <mps> i.e. pkgver change
2019-06-21 18:13:54 <PureTryOut[m]> pr8764
2019-06-21 18:16:35 <mps> aha, I see, I made something similar and with panfrost. But I think lima and panfrost should be only for arm's
2019-06-21 18:17:56 <mps> but, as ncopa told we should wait for mesa stable
2019-06-21 18:18:16 <mps> and I desperately need rust on arm
2019-06-21 18:18:33 <PureTryOut[m]> Yeah Lima and Panfrost are only ARM
2019-06-21 18:18:45 <PureTryOut[m]> I'm going to eventually enable Freedreno too, which is also only ARM
2019-06-21 18:19:34 <mps> yes, good idea
2019-06-21 18:21:21 <Cogitri> Got the base tarballs now for Rust on armhf/armv6, now to crosscompile to our arches
2019-06-21 18:21:31 <mps> (for years trying to avoid gentoo and now I feel I'm in' centre' of it)
2019-06-21 18:22:24 <mps> (compiling, tweaking, patching)
2019-06-21 18:51:40 <tcely> clandmeter: how are you compiling jsonnet to yml? The drone/cli image doesn't work for me.
2019-06-21 19:14:38 <PureTryOut[m]> cogitri: should I take over maintainment of xdg-desktop-portal-kde? Seeing it's a Plasma package
2019-06-21 19:15:59 <Cogitri> If you want to, sure :)
2019-06-21 19:23:34 <PureTryOut[m]> Thanks, would be nice :D
2019-06-21 19:58:45 <mps> PureTryOut[m]: would you mind to integrate panfrost to your mali drivers PR? I can send you patch I made
2019-06-21 20:08:50 <PureTryOut[m]> Sure, will do tomorrow
2019-06-21 20:33:24 <clandmeter> tcely: you need to add an option
2019-06-21 20:33:33 <clandmeter> --stream
2019-06-21 20:33:37 <clandmeter> I think
2019-06-21 20:40:05 <mps> PureTryOut[m]: here it is http://tpaste.us/kZLZ  thanks
2019-06-21 21:26:42 <TBK[m]> tcely: clandmeter: drone --stream --stdout || jsonnet -y .drone.jsonnet
2019-06-21 21:57:45 <clandmeter> TBK[m]: there should be no need to use stdout
2019-06-21 21:58:03 <clandmeter> drone cli has build in support for jsonnet
2019-06-21 21:59:56 <TBK[m]> it is need if you want it to output a file
2019-06-21 22:00:36 <TBK[m]> I have two options, one for drone cli and one for the official jsonnet tool
2019-06-21 22:00:56 <TBK[m]> s/have/gave/
2019-06-21 22:00:56 <alpine-meetbot> TBK[m] meant to say: I gave two options, one for drone cli and one for the official jsonnet tool
2019-06-21 22:02:16 <TBK[m]> *it is need if you do not want it to output a file
2019-06-21 22:52:49 <tcely> This seems to work: docker run --rm -i drone/cli jsonnet --format --stream --source /dev/stdin --stdout < .drone.jsonnet > .drone.yml
2019-06-21 23:53:30 <tmhoang> Cogitri: webkitgtk2 built using even more than 8G on s390x. I have to add swap to make things go well.
2019-06-21 23:53:57 <tmhoang> my builder only has 8G memory while official builder has 32G
2019-06-21 23:54:22 <tmhoang> we even have better specs than Debian s390x builder :)
2019-06-21 23:59:42 <Cogitri> tmhoang: Yeah, I think that's to be expected, it'll take ~2-4GB per build job
2019-06-22 00:02:31 <tmhoang> powerful stuff
2019-06-22 00:05:51 <Cogitri> Certainly a powerful s390x builder :P
2019-06-22 00:06:26 <tmhoang> if not shared with other people :)
2019-06-22 01:08:20 <maxice8> pr4297 has 1 month without interaction
2019-06-22 01:08:31 <maxice8> pr4949 has 256 days without interaction
2019-06-22 01:09:11 <jwh> ohhh
2019-06-22 01:09:21 <jwh> I was gonna start packing toxic
2019-06-22 01:09:30 <jwh> packaging*
2019-06-22 01:10:46 <jwh> $builddir/build && cmake .. on that pr perhaps
2019-06-22 01:14:04 <SpaceToast> jwh: that pr hasn't been touched in like a month now, and it's kind of a mess
2019-06-22 01:14:12 <SpaceToast> I'd just write my own and link to the old one
2019-06-22 01:14:12 <jwh> yeah
2019-06-22 01:31:57 <jwh> tbh
2019-06-22 01:32:01 <jwh> it only needs a quick tidy
2019-06-22 01:32:45 <jwh> apart from 2 aports in one pr
2019-06-22 01:36:06 <SpaceToast> "a quick tidy" is how I'd describe most apkbuilds without 50 patches :D
2019-06-22 01:36:36 <jwh> lol
2019-06-22 01:37:11 <jwh> if that PR is a no-go (I wouldn't touch it :D), I can do it later
2019-06-22 01:44:05 <SpaceToast> it's been a month since the submitter touched it, they could come back but it's probably faster to just do the thing
2019-06-22 01:44:22 <jwh> good timing since I've been playing with it D:
2019-06-22 01:45:15 <SpaceToast> nah, good timing would be if couchdb fixed their build system 5 minutes ago
2019-06-22 01:45:19 <SpaceToast> ...
2019-06-22 01:45:20 <jwh> lol
2019-06-22 01:45:21 <SpaceToast> 
ACTION checks

2019-06-22 01:45:39 <SpaceToast> that's a nope
2019-06-22 01:47:05 <jwh> heh
2019-06-22 09:01:50 <jwh> so whats the reasoning behind libtool not being a depend of alpine-sdk (or build-base?) or something?
2019-06-22 09:20:13 <clandmeter> tcely: why dont you just run drone jsonnet --stream?
2019-06-22 12:47:43 <tcely> clandmeter: I don't have drone installed and adding a new dependency is not needed. We already are depending on docker anyway.
2019-06-22 12:48:37 <tcely> clandmeter: why did you force push master overwriting the latest commits? Please fix.
2019-06-22 13:43:31 <clandmeter> Force push what?
2019-06-22 13:49:45 <clandmeter> tcely: you don't want to install drone cli but you do want to pull a container consuming it?
2019-06-22 13:50:00 <clandmeter> Containing...
2019-06-22 13:51:14 <tcely> algitbot force-pushed the alpinelinux:master  branch from a29ce5e to edb4126 4 hours ago
2019-06-22 13:51:53 <clandmeter> Where do you see that?
2019-06-22 13:52:26 <clandmeter> I think the bot does it?
2019-06-22 13:53:01 <tcely> It appears the commit from https://github.com/alpinelinux/docker-abuild/pull/28 was lost when you added 3.10
2019-06-22 13:54:00 <tcely> I see it in my pull request because my change was based on the tip of master before it was rewritten.
2019-06-22 13:54:21 <clandmeter> It means mort pushed to GitHub
2019-06-22 13:54:35 <tcely> Ahh.
2019-06-22 13:54:35 <clandmeter> That should not happen
2019-06-22 13:55:02 <clandmeter> Or did it via webif
2019-06-22 15:15:04 <PureTryOut[m]> I'm currently packaging something which has `/home/` in the rpath, and abuild doesn't like that. Does anyone know how I can get rid of it?
2019-06-22 15:19:27 <maxice8> I think there is chrpath
2019-06-22 15:19:31 <maxice8> Or some utility from NixOS that removes those wrong rpaths
2019-06-22 15:19:54 <maxice8> Also your build system might support skipping setting rpaths
2019-06-22 15:38:48 <_ikke_> there is a dedicated package for chrpath
2019-06-22 15:39:19 <_ikke_> chrpath -d $bin
2019-06-22 15:40:13 <PureTryOut[m]> Thanks!
2019-06-22 16:19:06 <PureTryOut[m]> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/v1/download/matrix.org/yZmrhtnlVKahePSxlAZHcycC >

2019-06-22 16:19:21 <PureTryOut[m]> Huh? ☝️ Package has a -doc package already, but now it complains that the -dev packages also has docs?
2019-06-22 16:19:50 <maxice8> please use a paste service
2019-06-22 16:19:52 <SpaceToast> iirc, -dev is older than both -doc and -static
2019-06-22 16:20:00 <SpaceToast> and it used to serve both purposes
2019-06-22 16:20:10 <PureTryOut[m]> maxice8: why? This works in any Matrix client, and IRC users will get a link just like with paste services
2019-06-22 16:20:12 <SpaceToast> put your -doc (and -static) before -dev in the subpackage list
2019-06-22 16:20:28 <SpaceToast> (I think that works? I forget, still waking up)
2019-06-22 16:20:35 <maxice8> PureTryOut: oh, didn't knew it was some pre-formatted magic
2019-06-22 16:20:35 <_ikke_> yes, that should work
2019-06-22 16:20:47 <PureTryOut[m]> SpaceToast: thanks will try
2019-06-22 16:20:48 <PureTryOut[m]> Seems like that could use a fix then though
2019-06-22 16:21:11 <tcely> There is a fix for -static pending
2019-06-22 16:21:18 <maxice8> Yes
2019-06-22 16:21:27 <maxice8> https://github.com/alpinelinux/abuild/pull/72
2019-06-22 16:21:47 <PureTryOut[m]> maxice8: yeah server formats the message, so that can just be shown to anything really. The bridge translates it into an url
2019-06-22 16:22:12 <maxice8> I was suprised it didn't make it when a few PRs were merged
2019-06-22 16:22:16 <maxice8> should let it know harder
2019-06-22 16:22:21 <maxice8> PureTryOut: Good to know, thanks.
2019-06-22 16:22:26 <PureTryOut[m]> maxice8: ah thanks for that PR!
2019-06-22 16:22:40 <_ikke_> maxice8: I think ncopa wanted to only apply low-risc PRs
2019-06-22 16:22:42 <_ikke_> for 3.10
2019-06-22 16:22:43 <PureTryOut[m]> (also I was wrong, it's not the server that formats it but the client)
2019-06-22 16:23:08 <maxice8> _ikke_: well that risk aversion keeps -static and -dev interaction broken :D
2019-06-22 16:23:18 <danieli> IRC sends one message per line, so yeah
2019-06-22 16:23:46 <_ikke_> maxice8: then abuild complains and you reverse the order
2019-06-22 16:27:42 <maxice8> _ikke_: abuild fails and then you try to find it out and come here and someone tell you about it and how there is a PR for it and then the person in question fixes it.
2019-06-22 16:27:49 <maxice8> just like now
2019-06-22 16:28:06 <_ikke_> maxice8: telling them there is a PR for it doesn't help it
2019-06-22 16:28:15 <_ikke_> telling them they just need to reverse the order does help them
2019-06-22 16:28:38 <maxice8> it is what happens i'm just telling lore and fate
2019-06-22 16:29:21 <_ikke_> The PR is a nice to have so that the order doesn't matter, but it's not plain broken
2019-06-22 16:29:43 <_ikke_> so I can understand that ncopa waits before applying it, when 3.10 was already in the pipeline
2019-06-22 18:35:17 <Cogitri> About https://github.com/alpinelinux/aports/pull/8976#issuecomment-504688567: What's our policy on adding -dbg packages?
2019-06-22 21:38:57 <tcely> Cogitri: the binaries did get stripped correct?
2019-06-22 21:41:54 <tcely> there is !strip for options if you want to use unstripped binaries. Or adding -dbg packages looks to save symbols in detached files for everything left in $pkgdir
2019-06-22 21:49:21 <Cogitri> Yup, -dbg packages are the way to go, but I'm wondering when we should add those
2019-06-22 21:49:31 <Cogitri> Just when the maintainer feels like it?
2019-06-22 21:51:30 <tcely> Cogitri: they are typically only useful when you want to use a debugger
2019-06-22 21:52:01 <Cogitri> Users may want to use a debugger too when stuff goes south
2019-06-22 21:52:22 <Cogitri> Void Linux just always provided -dbg packages, that was rather handy at times to debug crashes
2019-06-22 21:53:24 <tcely> the main cost is going to be storage space. users won't typically have those installed from what I understand, but it would be easier to install then debug than to have to rebuild then debug.
2019-06-22 21:55:10 <tcely> I only see 85 packages using -dbg
2019-06-22 21:57:26 <mps> I don't think we need -dbg for all pkg's.
2019-06-22 21:58:04 <_ikke_> Nope, we sure don't
2019-06-22 22:01:49 <Cogitri> So we're going to opt for -dbg for only cote pkgs?
2019-06-22 22:01:56 <Cogitri> s/cote/core/
2019-06-22 22:01:56 <alpine-meetbot> Cogitri meant to say: So we're going to opt for -dbg for only core pkgs?
2019-06-22 22:02:39 <Cogitri> PureTryOut: I guess no need for RelWithDebInfo hen, it's stripped anyway
2019-06-22 22:02:50 <_ikke_>  @ncopa  the -dbg are seldomly needed, but they may significantly increase disk usage
2019-06-22 22:02:59 <_ikke_> was a quote from him
2019-06-22 22:03:14 <mps> for some important pkg's
2019-06-22 22:03:16 <Cogitri> For the mirrors, yes. Wasn't sure if disk space is a limitation on the mirrors
2019-06-22 22:03:40 <Cogitri> But without -dbg packages debugging something can be quite nightmare-ish
2019-06-22 22:03:43 <mps> snapshot archives?
2019-06-22 22:05:06 <mps> if someone use -dbg then s/he usually easy to build it locally
2019-06-22 22:05:27 <tcely> musl-dbg is almost 3x the size of musl for example. Multiply that by number of packages and I'm sure it adds up quickly
2019-06-22 22:06:09 <Cogitri> <mps "if someone use -dbg then s/he us"> The problem is that you not only need the -dbg package for that specific package but for all deps to have an useful stacktrace
2019-06-22 22:06:32 <Cogitri> Which can mean about 400 packages you have to modify and build yourself to debug e.g. gnome-shell
2019-06-22 22:07:45 <Cogitri> <tcely "musl-dbg is almost 3x the size o"> Yup, I have a Void Linux mirror for ppc, I can check in a bit how much the dbg packages take up
2019-06-22 22:07:48 <mps> isn't this some kind of exaggeration
2019-06-22 22:08:37 <Cogitri> No, why would it be?
2019-06-22 22:09:10 <Cogitri> GNOME-shell depends on about 400 packages (mind you, those are recursive deps, so deps of deps of deps also count into this)
2019-06-22 22:09:43 <_ikke_> But you are probably not debugging them all at the same time
2019-06-22 22:10:48 <Cogitri> Uhh
2019-06-22 22:11:05 <Cogitri> I do when I debug gnome-shell
2019-06-22 22:11:22 <Cogitri> Because the stack trace may reach deep into the dep tree
2019-06-22 22:11:26 <mps> I admit that I don't have experience with such pkg's (a lot of recursive deps) but I usually build pkg which I debug and no one of it's deps
2019-06-22 22:11:57 <Cogitri> E.g. mozjs60 crashes, so polkit crashes, so gjs crashes, so gnome-shell crashes (so I need -dbg packages for all of these for a proper stacktrace)
2019-06-22 22:12:16 <Cogitri> The stacktrace would be std->gnome-shell->gjs->polkit->mozjs60
2019-06-22 22:12:59 <Cogitri> And without debugging symbols (or only for gnome-shell) it'd be std->gnome-shell->?->?->? which isn't exactly helpful
2019-06-22 22:13:28 <mps> understand. I think this deserves bug report for further discussion
2019-06-22 22:13:57 <Cogitri> I mean if disk space really is such a blocker for our mirrors then I can live with not having -dbg packages or only for core packages, I guess I just want a policy for this so I don't have to guess :)
2019-06-22 22:14:15 <Cogitri> I guess I'll bring this over to #alpine-docs
2019-06-22 22:15:13 <mps> I still think you should fill issue on bugs.a.o for broader audience, not all dev's on irc
2019-06-22 22:15:53 <mps> or send mail to alpine-devel ML
2019-06-22 22:15:58 <danieli> +1 to ML
2019-06-22 22:16:17 <danieli> i think it would fit in bugs but it's a fairly big problem
2019-06-22 22:16:53 <Cogitri> Yeaaah, I'll open a bugreport then
2019-06-22 22:17:14 <mps> danieli: agree, but I don't see much of us answering questions on ML
2019-06-22 22:17:40 <Cogitri> Yup, ML is pretty dead (which I don't necessarily dislike)
2019-06-22 22:17:54 <danieli> i usually keep an eye out for stuff on the ML, but mails there are filtered to different folders in my mailbox
2019-06-22 22:17:56 <mps> ofc, alpine-devel ML is the best place, imo
2019-06-22 22:18:21 <danieli> it's a shame both the ML and patchwork are fairly deserted
2019-06-22 22:18:22 <Cogitri> I am subscribed to alpine-devel, but if I don't absolutely have to I won't use it
2019-06-22 22:19:08 <danieli> how come?
2019-06-22 22:19:11 <Cogitri> Let's not get into a discussion which will leave everyone dissatisfied, eh?
2019-06-22 22:19:18 <mps> Cogitri: alpine-devel is official devel communication channel
2019-06-22 22:19:41 <danieli> yeah, but the de-facto standard is pretty much this IRC channel
2019-06-22 22:20:14 <Cogitri> shrug if you want to reach me use GitHub (soon Gitlab?), IRC/Matrix or if you absolutely have to write me an email
2019-06-22 22:21:07 <mps> danieli: true :(
2019-06-22 22:21:18 <Cogitri> But MLs have no way for me to know if you received the message, they are a mess to read if more than a few people participate, clunky to use, tracking the process of patches is very meh and reviewing them sort of a nightmare
2019-06-22 22:21:54 <danieli> very good (and entirely valid) points
2019-06-22 22:21:58 <Cogitri> Let's just settle with everyone prefers something else, and I __heavily__ prefer GitHub/Gitlab's web-UI thingie
2019-06-22 22:22:00 <mps> Cogitri: that is your view, my is quite opposite
2019-06-22 22:22:43 <danieli> let's not get into a holy war :)
2019-06-22 22:22:50 <Cogitri> I guess MLs can be quite efficient, there are many different clients you can tweak to your liking and stuff, but I just super dislike the mail workflow
2019-06-22 22:22:54 <Cogitri> <danieli "let's not get into a holy war :)"> Yup :)
2019-06-22 22:23:49 <mps> ofc, I will not go to any holy war with you all, especially not with Cogitri :)
2019-06-22 22:24:15 <Cogitri> 
ACTION isn't sure if that's a good or bad thing

2019-06-22 22:24:16 <Cogitri> :P
2019-06-22 22:24:16 <danieli> it's entirely subjective either way
2019-06-22 22:24:50 <Cogitri> Yup
2019-06-23 05:31:14 <kaniini> hey can someone do a rebuild of erlang + elixir in alpine 3.10?  our testing shows that OTP releases are completely broken on 3.10
2019-06-23 05:38:37 <_ikke_> kaniini: and a rebuild is going to fix that?
2019-06-23 05:39:06 <kaniini> yes, erlang makes use of internal musl things (yes, it really shouldn't)
2019-06-23 05:39:26 <kaniini> everytime musl is updated, erlang will probably need to be rebuilt
2019-06-23 05:40:02 <_ikke_> kaniini: is there an easy way for me to check if it's fixed once rebuilt (first trying it locally)
2019-06-23 05:40:35 <kaniini> https://git.pleroma.social/pleroma/pleroma/merge_requests/1315/diffs#d481ea3b4a7395c92beb53530fc810e467ea0792_0_36 is the relevant information i guess
2019-06-23 05:43:33 <_ikke_> Hmm, erlang was upgraded after the last change to musl
2019-06-23 05:45:56 <_ikke_> kaniini: not seeing how that is relevant?
2019-06-23 05:46:13 <_ikke_> ah, sorry, the relevant diff was collapsed
2019-06-23 05:47:09 <_ikke_> "The problem is that we bundle erts/erlang/elixir from the host system. And the elixir docker image was built with Alpine 3.9. I will try rebuilding it with 3.10 and if it works on both 3.10 and versions below, we can remove this"
2019-06-23 10:17:16 <danieli> kaniini: thanks for the heads up, i'll sort it right now
2019-06-23 10:17:32 <danieli> a pkgrel bump for erlang and elixir should be fine
2019-06-23 10:19:13 <danieli> _ikke_: or did you sort it perhaps?
2019-06-23 10:25:07 <_ikke_> danieli: I didn't do anything yet
2019-06-23 10:30:35 <mps> can someone tell me how to upgrade pkg to same version on edge and stable? in one commit or separate?
2019-06-23 10:31:16 <Cogitri> I did it in seperate commits
2019-06-23 10:31:52 <_ikke_> Yes, separate commits, because they are in separate branches
2019-06-23 10:32:03 <_ikke_> so it can never be the same commit
2019-06-23 10:32:33 <mps> thought so, thanks both
2019-06-23 10:33:36 <mps> how can I checkout stable branch in my local aports
2019-06-23 10:34:32 <_ikke_> git checkout -t stable-3.10 origin/stable-3.10
2019-06-23 10:35:18 <mps> _ikke_: thanks
2019-06-23 10:36:49 <mps> another one: commit subject (first line)  "community/mutt: bugfix upgrade to 1.12.1" or just "community/mutt: upgrade to 1.12.1", without 'bugfix'
2019-06-23 10:37:27 <Cogitri> I'd opt for the former
2019-06-23 10:37:36 <Cogitri> Err..latter I mean
2019-06-23 10:37:38 <Cogitri> I need more sleep :P
2019-06-23 10:39:13 <Cogitri> The patch version bump already signifies that
2019-06-23 10:39:34 <Cogitri> So adding "bugfix" is kind of a repetition
2019-06-23 10:40:48 <mps> there are mixed variations in 'git log', I would like to follow 'best practice' but not sure do we have codified 'best practice' somewhere
2019-06-23 10:43:00 <_ikke_> You could also add it to the body (where you specify what bug is fixed)
2019-06-23 10:43:08 <_ikke_> Sadly I see that too little happening in aports
2019-06-23 10:43:24 <mps> yes, already added to body more descriptive message
2019-06-23 10:43:43 <_ikke_> Then just upgrade to x.y.z is enough
2019-06-23 10:44:22 <mps> I did, following your and Cogitri's advices, just pushed it to edge
2019-06-23 10:44:37 <Cogitri> <_ikke_ "Sadly I see that too little happ"> Hm, doing that for every package is a lot of work though and one may always consult upstream's changelog
2019-06-23 10:46:08 <mps> another question: (sorry) how can I clone branches from git.a.o to local aports
2019-06-23 10:47:09 <mps> I don't have any branch (except master) on my local clone
2019-06-23 10:50:27 <Cogitri> git fetch origin <branch>
2019-06-23 10:50:59 <Cogitri> (or replace origin with another remote, I personally have `origin` pointing to my fork and `upstream` for the upstream repo)
2019-06-23 10:51:27 <_ikke_> Cogitri: You don't need to specify every change in every commit
2019-06-23 10:51:37 <_ikke_> Just when it has some significance
2019-06-23 10:51:50 <_ikke_> Just regular upgrades and new aports are trivial
2019-06-23 10:52:26 <Cogitri> <_ikke_ "Just when it has some significan"> Ah, alrighty
2019-06-23 11:09:55 <mps> _ikke_: did you mean to write '-b' instead of '-t' in your previous msg 'git checkout -t stable-3.10 origin/stable-3.10'?
2019-06-23 11:11:31 <_ikke_> git checkout -t origin/stable-3.10
2019-06-23 11:12:42 <mps> ah, I see
2019-06-23 11:14:43 <mps> _ikke_: It works
2019-06-23 11:16:21 <mps> I posted mutt upgrade to 1.12.1 'few' minutes ago. It fixes some issue (described in commit msg)
2019-06-23 11:17:24 <mps> what we should do with this for stable, push it right now or wait for some triage of core devs
2019-06-23 11:22:35 <_ikke_> If the upgrade is within the same minor version, I think you could just push it
2019-06-23 11:23:27 <mps> yes, minor version upgrade, contains few bugfixes and one new feature
2019-06-23 11:23:52 <_ikke_> If it's a minor version upgrade, it's not within the same minor version
2019-06-23 11:24:33 <_ikke_> 1.12.0 -> 1.12.1 should be trivial, 1.11.x -> 1.12.x should probably be discussed
2019-06-23 11:24:56 <mps> sorry, of course, minor version bump
2019-06-23 11:25:27 <_ikke_> Not all projects follow semver though, so it's hard to tell for sure
2019-06-23 11:26:12 <mps> right, but luckily mutt follows
2019-06-23 11:26:52 <mps> ok, will try to push it now to stable, in hope that will not make any mess there
2019-06-23 11:28:46 <mps> _ikke_: sorry for annoying you again, but would you mind to look at latest push to aports:3.10-stable, is it ok
2019-06-23 11:47:04 <_ikke_> mps: looks goodf
2019-06-23 11:49:02 <mps> thanks again for your help. (this is my first push to stable)
2019-06-23 11:49:42 <_ikke_> I haven't done too many of those myself
2019-06-23 12:39:57 <danieli> _ikke_: pr8996
2019-06-23 12:40:10 <danieli> might as well bump erlang to the new patch version instead of just relbumping
2019-06-23 12:41:46 <_ikke_> did you verify that the bump is needed for 3.10?
2019-06-23 12:42:03 <_ikke_> (separate from the version increase)
2019-06-23 12:42:15 <danieli> oops, i forgot it's about stable and not just edge :P
2019-06-23 12:42:25 <danieli> guess i can make another PR for 3.10?
2019-06-23 12:42:39 <_ikke_> yes
2019-06-23 12:42:49 <danieli> nice, would be easier not to have to close that pr
2019-06-23 12:42:51 <_ikke_> make sure to prefix [3.10]
2019-06-23 12:42:56 <danieli> will do, thanks
2019-06-23 12:43:09 <danieli> you can push that pr to master once it's built by CI
2019-06-23 12:43:13 <_ikke_> danieli: k
2019-06-23 12:43:19 <danieli> i'll fix a 3.10 pr in a little moment
2019-06-23 12:43:27 <_ikke_> But is erlang broken atm in 3.10?
2019-06-23 12:43:31 <_ikke_> (elixir)
2019-06-23 12:45:00 <danieli> all tests passed, i did run the test suites - but according to kaniini and as far as i can understand, yes
2019-06-23 12:45:10 <danieli> 3.10 was tagged not long ago
2019-06-23 12:46:08 <danieli> correct me if i'm wrong here
2019-06-23 12:46:32 <_ikke_> I'm just wondering about this comment: https://git.pleroma.social/pleroma/pleroma/merge_requests/1315/diffs#note_32179
2019-06-23 12:47:01 <danieli> right, so it's broken in 3.9 and not 3.10 or edge?
2019-06-23 12:49:31 <danieli> argh
2019-06-23 12:50:52 <danieli> did a force push to fix the checksum
2019-06-23 12:55:49 <PureTryOut[m]> mps: do you have a link to your Panfrost changes for Mesa? I could also just take our changes from pmOS for Panfrost though
2019-06-23 12:59:48 <mps> PureTryOut[m]: I posted you tpaste.us link at Friday, iirc
2019-06-23 13:00:49 <mps> here is new url (not patch) http://tpaste.us/M5rm
2019-06-23 13:01:41 <mps> I tested it a little more, hmm ... it is not stable in some more rigorous tests
2019-06-23 13:02:19 <mps> or maybe issue with kernel 5.2-rc5. not sure what causes some instabilities
2019-06-23 13:03:14 <PureTryOut[m]> Ah yeah that's same changes as we had, I'll add them
2019-06-23 13:04:33 <mps> we will probably need to make it better, but after 'stable' release I think
2019-06-23 13:04:57 <mps> better APKBUILD, I mean
2019-06-23 13:07:11 <PureTryOut[m]> Updated my PR https://github.com/alpinelinux/aports/pull/8764/files
2019-06-23 13:07:16 <PureTryOut[m]> But yeah we need to wait for next Mesa stable release
2019-06-23 13:08:31 <mps> and, I plan vacation for july
2019-06-23 13:12:26 <Cogitri> Same, vacation is good
2019-06-23 13:13:29 <_ikke_> Me 3
2019-06-23 13:14:09 <mps> Cogitri: ehh, I had a hope that you will work on rust instead of wasting your precious time :D
2019-06-23 13:14:41 <mps> ofc, I'm kidding. All you deserve good and long vacations
2019-06-23 13:15:22 <Cogitri> lol
2019-06-23 13:16:23 <Cogitri> I shall get right to it! :P
2019-06-23 13:17:15 <mps> no, we are not in a hurry, easy ;)
2019-06-23 13:19:25 <ollieparanoid[m]> this is a strange bug ^
2019-06-23 13:19:46 <ollieparanoid[m]> I don't have time to look more into it right now, so I'm just leaving this report.
2019-06-23 13:21:27 <mps> ollieparanoid[m]: I noticed that about week or two ago, but make quick hack for apk on which worked and forgot it
2019-06-23 14:10:31 <mps> it was firefox-esr version old about 5 month
2019-06-23 14:13:53 <mps> wrong channel, sorry
2019-06-23 14:14:18 <_ikke_> :)
2019-06-23 19:35:27 <Cogitri> mps: Uhh...could you give me the link to your guide for the Qemu images again? 😅
2019-06-23 19:38:05 <Cogitri> Nevermind, digged it out
2019-06-23 19:59:34 <tcely> Cogitri: congrats on rust 1.35. btw, "dug it out" I believe
2019-06-23 20:02:57 <Cogitri> Oh, right
2019-06-23 20:12:26 <maxice8> lots of PRs for main/ in GH :D
2019-06-23 20:13:12 <_ikke_> I'll look at them
2019-06-23 20:13:48 <maxice8> Thanks
2019-06-23 20:22:53 <maxice8> Wanted to get under 150 PRs but lots of stuff that can get merged are in main/
2019-06-23 20:26:13 <mps> maxice8: right, access to main is 'problem' for me also. Have to patch and wait... and annoy someone and again wait...
2019-06-23 20:26:40 <mps> Cogitri: I was AFK, you found 'guide'?
2019-06-23 20:30:54 <Cogitri> Yup, currently booting the thing
2019-06-23 20:31:20 <mps> aha, nice
2019-06-23 20:31:30 <Cogitri> Hm, either the booting takes a but or the thing is reaaaally slow
2019-06-23 20:32:32 <mps> it is not fast as real hardware :(
2019-06-23 20:33:16 <Cogitri> Well, that I expect, but it has been busy booting for the last 3 minutes
2019-06-23 20:33:52 <mps> that's too much, in my tests it boots in about 20-30 seconds
2019-06-23 20:34:10 <Cogitri> Currently stuck at `random: crng init done`, I guess VMs don't have a lot of entropy?
2019-06-23 20:35:09 <Cogitri> Ah, booted now, so that's quite something at the very least
2019-06-23 20:36:33 <Cogitri> Oh wow, network just works :o
2019-06-23 20:37:42 <mps> I didn't tried this on v3.10 yet, with new qemu 4.0
2019-06-23 20:38:45 <mps> did you downloaded new version of tarball, 3.10 or old 3.9
2019-06-23 20:48:15 <Cogitri> I downloaded 3.9, with u-boot-qemu-2019.0.4-r2
2019-06-23 20:50:02 <mps> 3.10 tarball contains qemu u-boot. I should update 'guide' and script
2019-06-23 20:50:21 <Cogitri> Oh, okie
2019-06-23 20:51:51 <mps> when you untar 3.10 uboot.tar.gz there is dir 'u-boot/qemu' (or something like that) with file qemu-uboot.bin (or something like that)
2019-06-23 20:52:16 <mps> I will look in 20-30 minutes details, now I'm out
2019-06-23 20:53:12 <_ikke_> How does it work with soname dependencies, are consumers of a library depending on the mayor version of the library? ie. libfoo.so.X
2019-06-23 20:53:13 <mps> u-boot/qemu_arm64/u-boot.bin
2019-06-23 21:00:08 <Cogitri> _ikke_: Well, that's different from lib to lib, but usually it's like this: libfoo.so.0.0.1 is the actual file and then there are two symlinks, libfoo.so.0 (stuff is linked against this) and libfoo.so (for the linker during build)
2019-06-23 21:00:43 <Cogitri> So stuff 'depends" on libfoo.so.X, yes, otherwise you'd have to rebuild for every minor bump and not just for ABI/API changes
2019-06-23 21:01:11 <_ikke_> yeah, that's what I understood, wanted to confirm
2019-06-23 21:19:58 <SpaceToast> Major version bumps generally mean compatibility is broken
2019-06-23 21:20:07 <SpaceToast> So yes, major version is what you generally target
2019-06-23 21:21:31 <_ikke_> I also checked abi-lab to be sure
2019-06-23 21:29:47 <Cogitri> mps: my aarch64-work image doesn't seem to work: https://gist.github.com/d5665fe40fdda0fefeeb4c83c2e00e2b :c
2019-06-23 21:36:39 <mps> Cogitri: is this on v3.10
2019-06-23 21:36:57 <Cogitri> No, 3.9
2019-06-23 21:37:08 <Cogitri> But maybe I just messed the setup up
2019-06-23 21:37:26 <Cogitri> My -install image worked fine
2019-06-23 21:38:23 <mps> and what tarball version you used to install, 3.9 or 3.10
2019-06-23 21:38:33 <Cogitri> 3.9, as noted in the guide
2019-06-23 21:39:05 <mps> hmm, I tested it few times under 3.9 and it worked allways
2019-06-23 21:40:02 <Cogitri> Hm, are you going to make a new 3.10 image in a bit? Maybe you could make a ready to use image (although that's a lot to ask ><)
2019-06-23 21:41:16 <mps> I'm started to adapt script to 3.10
2019-06-23 21:55:01 <mps> Cogitri: you are right, now it needs more time to boot, don't know why, maybe kernel
2019-06-23 21:59:12 <mps> boot msg: [   19.102127] random: fast init done
2019-06-23 21:59:16 <mps> and waiting
2019-06-23 22:00:08 <mps> this time not to much. [   63.651222] uart-pl011 9000000.pl011: no DMA platform data
2019-06-23 22:00:13 <mps> and login prompt
2019-06-23 22:05:10 <Cogitri> Hm, alright. The boottime of the install image isn't much of a problem though, the work image not booting at all is :/
2019-06-23 22:06:21 <mps> aha, I will try to install it now
2019-06-23 22:06:34 <mps> (if i remember all steps)
2019-06-23 22:26:53 <Cogitri> mps/PureTryOut: https://www.phoronix.com/scan.php?page=news_item&px=Mesa-19.1.1-Release-Candidate
2019-06-23 22:29:51 <mps> Cogitri: thanks, so I was right few days ago when wrote that I expect it in week or two
2019-06-23 22:30:18 <Cogitri> Yup, good estimate
2019-06-23 22:30:37 <mps> I should earn my money by offering providence service :)
2019-06-23 22:30:51 <maxice8> Release-monitoring but in the future
2019-06-23 22:31:29 <mps> Cogitri: in my case aarch64 boots
2019-06-23 22:31:50 <SpaceToast> I bet one could just plug issue # and milestone data + added/removed git lines (to estimate # of bugs) into a bayesian filter
2019-06-23 22:31:54 <SpaceToast> easy money! ;)
2019-06-23 22:32:17 <Cogitri> mps: Hm. Could you maybe upload that image somewhere?
2019-06-23 22:32:23 <mps> I adapted script to install 3.10, '(none):~# cat /etc/os-release' => PRETTY_NAME="Alpine Linux v3.10"
2019-06-23 22:33:55 <mps> uhm, uploading 1GB over 1Mbit ADSL is not promising
2019-06-23 22:34:14 <Cogitri> Oh, it's that big :o
2019-06-23 22:34:18 <mps> although I would like
2019-06-23 22:34:26 <Cogitri> Thought it'd weigh in at <100MB
2019-06-23 22:34:57 <mps> I wanted big 'disk' for development
2019-06-23 22:35:46 <mps> If it is not too late for you I will prepare smaller one but tomorrow, I'm tired now
2019-06-23 22:35:47 <Cogitri> Ah, I think you scan slim the thing down to the size of the actual contents of the image
2019-06-23 22:36:04 <Cogitri> Ah, no worries, I'm in bed already :)
2019-06-23 22:36:29 <mps> or better, I will send you updated script and 'guide' so you can do it and adapt to your wishes
2019-06-23 22:36:58 <Cogitri> Sure, that'd be nice too! :)
2019-06-23 22:37:09 <mps> aham, gzip will show, thanks for reminding
2019-06-23 22:42:17 <mps> gziped aarch64-work.img.gz is 249M
2019-06-23 22:42:57 <mps> still to much for 1Mbit link
2019-06-23 22:42:58 <Cogitri> Phew, still not fun to upload with a 1MBit connection
2019-06-23 22:43:06 <Cogitri> Thanks for trying :)
2019-06-23 22:44:00 <mps> yes, see you tomorrow, good night and sleep well
2019-06-23 22:44:20 <Cogitri> Good night :)
2019-06-23 22:46:51 <tcely> Does zstd do better with compression on that image?
2019-06-23 22:47:14 <Cogitri> I guess xz should provide the best compression ratio
2019-06-23 23:42:11 <SpaceToast> bzip2 tends to have better ratios than xz
2019-06-24 00:09:41 <SpaceToast> re: https://bugs.alpinelinux.org/issues/10605 - openssl having `replaces=libressl` is kind of a problem
2019-06-24 00:10:03 <SpaceToast> I can disable autodeps and depend explicitly on `pc:libressl:libssl` or similar, which will install the correct package, but as of right now they conflict
2019-06-24 00:11:31 <SpaceToast> (literally installing the same files)
2019-06-24 00:11:51 <SpaceToast> libressl could probably be modified to install into a subdirectory, with some CFLAG shenanigans to get opensmtpd to pick it up
2019-06-24 00:12:11 <SpaceToast> but that'd definitively rule out autodeps, and would require openssl to no longer have `replaces` clauses
2019-06-24 01:27:52 <terror> Hi team, seems http://dl-cdn.alpinelinux.org/alpine/latest-stable/ (x86_64) is borked somehow. Keep getting BAD signature for packages.
2019-06-24 01:28:02 <terror> Switching to http://dl-cdn.alpinelinux.org/alpine/v3.10/ fixes everything
2019-06-24 01:28:47 <SpaceToast> they should just be symlinks to one another
2019-06-24 01:33:28 <terror> They should, but somehow it doesn't work for me
2019-06-24 01:33:44 <SpaceToast> let me make a test container real quick
2019-06-24 01:34:36 <SpaceToast> can't reproduce
2019-06-24 01:34:56 <terror> $ sudo apk fix
2019-06-24 01:34:57 <terror> (1/2) Installing make (4.2.1-r2)
2019-06-24 01:34:59 <terror> ERROR: make-4.2.1-r2: BAD signature
2019-06-24 01:35:01 <terror> (2/2) Installing xz-libs (5.2.4-r0)
2019-06-24 01:35:03 <terror> ERROR: xz-libs-5.2.4-r0: BAD signature
2019-06-24 01:35:05 <terror> 2 errors; 657 MiB in 109 packages
2019-06-24 01:35:07 <SpaceToast> I do see that with make
2019-06-24 01:35:07 <terror> $ sudo nano /etc/apk/repositories
2019-06-24 01:35:09 <terror> $ sudo apk update
2019-06-24 01:35:11 <terror> fetch http://dl-cdn.alpinelinux.org/alpine/v3.10/main/x86_64/APKINDEX.tar.gz
2019-06-24 01:35:13 <terror> fetch http://dl-cdn.alpinelinux.org/alpine/v3.10/community/x86_64/APKINDEX.tar.gz
2019-06-24 01:35:15 <terror> v3.10.0-4-g2174faf01b [http://dl-cdn.alpinelinux.org/alpine/v3.10/main]
2019-06-24 01:35:17 <SpaceToast> but not with most packages
2019-06-24 01:35:17 <terror> v3.10.0-3-g43ac83e8aa [http://dl-cdn.alpinelinux.org/alpine/v3.10/community]
2019-06-24 01:35:19 <terror> OK: 10368 distinct packages available
2019-06-24 01:35:21 <terror> $ sudo apk fix
2019-06-24 01:35:23 <terror> (1/2) Installing make (4.2.1-r2)
2019-06-24 01:35:25 <terror> (2/2) Installing xz-libs (5.2.4-r0)
2019-06-24 01:35:27 <terror> Executing busybox-1.30.1-r2.trigger
2019-06-24 01:35:28 <SpaceToast> ... pastebins do exist, fyi
2019-06-24 01:35:29 <terror> OK: 658 MiB in 111 packages
2019-06-24 01:35:51 <terror> sorry!
2019-06-24 01:35:59 <SpaceToast> ok, I'm getting lots of BAD signatures, but not with *all* packages
2019-06-24 01:36:04 <SpaceToast> only some of them, which is quite strange
2019-06-24 01:36:12 <SpaceToast> maybe *a* builder is broken, or something like that?
2019-06-24 01:36:59 <SpaceToast> ok, let me diff the index
2019-06-24 01:38:05 <SpaceToast> ok, the index is the same...
2019-06-24 01:38:07 <terror> That's what I meant by 'borked somehow'
2019-06-24 01:38:22 <SpaceToast> well, usually, giving a way to reproduce helps ;)
2019-06-24 01:38:34 <SpaceToast> your original query suggested that it happened to all packages consistently
2019-06-24 01:39:36 <terror> ^ then it would've been 'definitely borked' not 'borked somehow'.
2019-06-24 01:39:37 <SpaceToast> not seeing anything weird in the APKINDEX thing for xz-libs...
2019-06-24 01:39:44 <terror> I'm using standard IT language here :P
2019-06-24 01:40:02 <SpaceToast> standard IT language would be "FUBAR" for the above case ;)
2019-06-24 01:40:17 <SpaceToast> "somehow" talks about the "how" (i.e reason) rather than consistency!
2019-06-24 01:40:22 <SpaceToast> "borked sometimes" perhaps :D
2019-06-24 01:40:38 <SpaceToast> alright, time to torture poor fastly
2019-06-24 01:40:48 <terror> Maybe some CDN edge nodes have old files? That'll explain why we see different things
2019-06-24 01:41:20 <SpaceToast> that shouldn't cause "bad sig" tho :
2019-06-24 01:44:08 <SpaceToast> well I guess this'll let me find out if I could run a mirror...
2019-06-24 02:50:37 <SpaceToast> oh MY
2019-06-24 02:50:44 <SpaceToast> terror: can confirm, the files differ
2019-06-24 02:50:51 <SpaceToast> something is very seriously wrong...
2019-06-24 02:53:18 <SpaceToast> list of packages that should be broken: https://brpaste.xyz/nz7eRQ
2019-06-24 02:53:59 <SpaceToast> (a total of 338)
2019-06-24 04:32:28 <_ikke_> terror: I've purged make on latest-stable, it should be fixed now
2019-06-24 04:33:05 <SpaceToast> _ikke_: it wasn't just `make`
2019-06-24 04:33:13 <SpaceToast> should I re-run check?
2019-06-24 04:33:35 <_ikke_> hmm
2019-06-24 04:33:40 <SpaceToast> it was 338 packages :/
2019-06-24 04:34:25 <_ikke_> There is this issue when we have to switch the symlink for latest-stable
2019-06-24 04:34:43 <_ikke_> but ncopa purged all those packages already
2019-06-24 04:34:54 <SpaceToast> how does it even end up happening?
2019-06-24 04:35:17 <SpaceToast> do the mirrors update over non-rsync and thus end up following the symlink or something?
2019-06-24 04:35:34 <_ikke_> SpaceToast: no, fastly caching packages
2019-06-24 04:36:11 <_ikke_> reproducible builds should fix this issue I guess
2019-06-24 04:36:37 <_ikke_> the packages for 3.10 got rebuilt, so now have different signatures.
2019-06-24 04:36:45 <_ikke_> which are recorded in the APKINDEX
2019-06-24 04:37:22 <_ikke_> when we repoint the symlink, all packages that have the same name as in 3.9, will not use the version in 3.10 but still the cached version
2019-06-24 04:37:36 <SpaceToast> aha
2019-06-24 04:39:04 <_ikke_> so that's why switching to a different mirror helps, those do not cache the packages
2019-06-24 04:40:24 <SpaceToast> well, the list of all the non-matching packages (at least for x86_64) is above :)
2019-06-24 04:41:23 <_ikke_> can I get raw output in brpaste?
2019-06-24 04:41:52 <SpaceToast> just add /raw/ between xyz and the hash
2019-06-24 04:41:58 <SpaceToast> https://brpaste.xyz/raw/nz7eRQ
2019-06-24 04:42:20 <SpaceToast> (sorry if it lags, I'm saturating the cpu right now trying to figure something else out)
2019-06-24 04:42:22 <_ikke_> expected like that
2019-06-24 04:42:33 <_ikke_> thanks
2019-06-24 04:45:21 <_ikke_> oh, the directory is not part of that output
2019-06-24 04:45:31 <SpaceToast> that's all main/x86_64
2019-06-24 04:45:37 <_ikke_> ok
2019-06-24 04:45:38 <SpaceToast> I didn't check the other ones
2019-06-24 04:46:01 <SpaceToast> (the checking process was literally to wget -m both sides, run diff -qr a b and put it through sed)
2019-06-24 04:46:46 <_ikke_> purged all of those
2019-06-24 04:47:12 <SpaceToast> ok, might make sense to check community later, but I feel kind of bad pulling gigabytes off the poor host
2019-06-24 04:48:22 <SpaceToast> (also other arches)
2019-06-24 04:53:26 <SpaceToast> meanwhile... uh oh; I can build a package and run its tests by hand, but if I do it through abuild I get a segfault (whether it's done normally, through rootbld, or even by hand `apkbuild check`) - any idea on what it could be?
2019-06-24 04:56:23 <_ikke_> SpaceToast: no, not really
2019-06-24 06:17:01 <PureTryOut[m]> <Cogitri "mps/PureTryOut: https://www.phor"> Ah nice
2019-06-24 06:50:56 <terror> Sorry to give you unexpected work!
2019-06-24 07:49:37 <clandmeter> _ikke_: i think we can add a 301 header on fastly?
2019-06-24 07:50:34 <clandmeter> so instead of having a symlink it would redirect to the proper repo
2019-06-24 07:52:13 <clandmeter> https://docs.fastly.com/guides/performance-tuning/generating-http-redirects-at-the-edge
2019-06-24 07:52:34 <clandmeter> and add it to the release notes that we need to update it on each release.
2019-06-24 07:53:27 <danieli> for latest-stable?
2019-06-24 07:53:34 <clandmeter> yes
2019-06-24 09:03:33 <_ikke_> clandmeter: I think that makes sense
2019-06-24 09:43:12 <PureTryOut[m]> I'd like to package an application that hasn't seen a release since 2016, but it's still being developed and has a commit as recent as yesterday. Would Alpine be willing to accept a package that uses the latest git master at the time of packaging? I see for example font-noto does this in Alpine
2019-06-24 09:45:41 <clandmeter> we can accept it
2019-06-24 09:46:19 <clandmeter> something like $basever_git$date iirc
2019-06-24 09:48:55 <mps> community/mtd-utils/APKBUILD is one of examples
2019-06-24 09:49:11 <mps> based on githash
2019-06-24 09:49:22 <mps> i.e. commit hash
2019-06-24 09:49:30 <PureTryOut[m]> Yeah I have a pkgver format
2019-06-24 09:49:35 <PureTryOut[m]> Thanks
2019-06-24 09:51:10 <mps> you can combine pkgver and commit hash, where pkgver could be (well) reasonable and download particular hash
2019-06-24 09:53:30 <PureTryOut[m]> I use $basever_git$date
2019-06-24 09:53:41 <PureTryOut[m]> https://github.com/alpinelinux/aports/pull/9039/files#diff-b59ba50f7ac4d26f404db7b15991c1feR4
2019-06-24 09:54:55 <mps> looks ok to me
2019-06-24 09:57:27 <danieli> i wonder why they don't make proper releases?
2019-06-24 09:59:01 <PureTryOut[m]> ¯\_(ツ)_/¯
2019-06-24 10:00:39 <mps> danieli: if I want to have always new and shiny software and don't care about bugfixes and security of previous sta(b)le release I will not make any release
2019-06-24 10:08:19 <Cogitri> PureTryOut: I'd recommend first asking them about a proper release
2019-06-24 10:08:26 <Cogitri> That's always better than us picking some random commit
2019-06-24 10:17:48 <clandmeter> Cogitri: +1
2019-06-24 10:18:26 <danieli> +1
2019-06-24 10:19:41 <PureTryOut[m]> I've done that of course 😉 But I don't expect "oh yeah good call, let's make a release right now" as an answer sadly
2019-06-24 10:20:48 <danieli> yeah, but it could tell them that people actually are interested in proper releases
2019-06-24 10:23:36 <PureTryOut[m]> Of course. That's why I did ask, but I didn't get an answer yet
2019-06-24 10:24:15 <Cogitri> I'd wait for a bit them, sounds like they're still active, so hopefully they'll reply soon
2019-06-24 10:25:35 <mps> I waited about month for tcsh when mepholic asked upstream to make release. Sometimes I wait even longer
2019-06-24 10:27:37 <_ikke_> clandmeter: I think a 302 or similar would make more sense
2019-06-24 10:32:21 <clandmeter> yes
2019-06-24 13:28:08 <PureTryOut[m]> So the reason for not making a release of Trojita is ENOTIME. The dev just recommended me to go with the latest Git master
2019-06-24 14:47:46 <SpaceToast> ^ can already be closed, most likely
2019-06-24 14:50:23 <tmhoang> ncopa: fedora decided to get patches/fixes from https://github.com/siddhesh/LuaJIT.git for luajit since 04.2019
2019-06-24 14:50:32 <tmhoang> that includes s390x support
2019-06-24 14:50:54 <tmhoang> looking at their tree, there are whole lot of fixes for all arches
2019-06-24 15:02:22 <tmhoang> https://dl.fedoraproject.org/pub/fedora-secondary/development/rawhide/Everything/s390x/os/Packages/l/luajit-2.1.0-0.11beta3.fc31.s390x.rpm
2019-06-24 15:02:29 <tmhoang> funny thing they addedsupport for ppc after s390x
2019-06-24 15:13:05 <tmhoang> same to SUSE : https://build.opensuse.org/package/view_file/openSUSE:Factory:zSystems/lua51-luajit/lua51-luajit.spec
2019-06-24 15:13:26 <tmhoang> have no idea how to pull in Ubuntu edge bin/source tree
2019-06-24 15:13:47 <PureTryOut[m]> This page seems incredibly old (talking about Alpine being based on Gentoo), can it be removed? https://wiki.alpinelinux.org/wiki/Comparison_with_other_distros
2019-06-24 15:14:04 <PureTryOut[m]> Or at least updated I guess?
2019-06-24 15:14:08 <tmhoang> so the question is could we do the same for lua jit ?
2019-06-24 15:14:45 <Cogitri> PureTryOut: I can update it in a few days
2019-06-24 15:14:47 <Cogitri> 
ACTION makes a note

2019-06-24 15:15:38 <PureTryOut[m]> cogitri: Awesome!
2019-06-24 17:14:59 <mps> Cogitri: did you made aarch64 qemu VM
2019-06-24 17:21:15 <Cogitri> Nop, didn't continue working on that yesterday and I'm pretty busy today and tomorrow :/
2019-06-24 17:21:59 <artok> mps are your docs cleaned, updated and sent so somewhere? =)
2019-06-24 17:22:06 <artok> som url ? =)
2019-06-24 17:22:11 <artok> permanent, that is
2019-06-24 17:23:22 <mps> artok: I suspect it ever been clean, but it is ok (imo) for 'hackers'
2019-06-24 17:23:55 <artok> yah
2019-06-24 17:24:11 <mps> today I worked on script for installing aarch64 v3.10
2019-06-24 17:24:44 <mps> had a issue with root FS mounted 'ro' on boot
2019-06-24 17:25:15 <mps> wrote about it on #alpine-linux about hour ago
2019-06-24 17:25:57 <mps> but, yes, I will put 'guide' and script on my personal page
2019-06-24 17:32:59 <Cogitri> mps: Thanks!
2019-06-24 17:37:04 <mps> I will finish all fixes (I hope in a hour or two) and put script for you to download it
2019-06-24 17:41:10 <mps> looks like everything is fixed, just need to clean script and upload it
2019-06-24 18:33:53 <mps> Cogitri: here is the new script to install aarch64 qemu VM http://arvanta.net/mps/install-aarch64-under-qemu.sh
2019-06-24 18:34:18 <mps> and here is incomplete guide http://arvanta.net/mps/install-aarch64-under-qemu.txt
2019-06-24 18:35:17 <mps> if anyone have comments, ideas or bug please post it here or to me by mail, or even on alpine-devel ML
2019-06-24 18:39:29 <clandmeter> So we have a working clang now on arm?
2019-06-24 18:39:38 <clandmeter> Do..
2019-06-24 18:49:22 <clandmeter> mps: ^
2019-06-24 18:56:29 <mps> clandmeter: hmm, I didn't tested latest clang much, so not sure if it is 'working'
2019-06-24 18:56:48 <mps> yes, it is there and some things works
2019-06-24 18:57:36 <Cogitri> mps: Thanks
2019-06-24 18:57:37 <mps> latest which I tested with big pkg's was clang6
2019-06-24 18:58:24 <Cogitri> clandmeter: I believe some imports weren't working when we tried clang-7 w/ webkit2gtk, I can try again with clang8 once I have a bit more time again :)
2019-06-24 18:59:03 <mps> and, I'm sure that clang7 and other things from llvm7 are broken, maybe latest 7.1 is ok but it is not used much
2019-06-24 19:00:28 <mps> I'm speaking about armv7/armhf and aarch64
2019-06-24 19:02:36 <mps> Cogitri: do you have something of rust on arm which could be tested, PR I mean
2019-06-24 19:05:05 <Cogitri> No, I have the base tars now, I have to make ot into an APKBUILD
2019-06-24 19:05:20 <mps> aha, ok
2019-06-24 19:07:05 <Cogitri> Wanted to have my VM before I do that so I don't have to annoy you too much with that
2019-06-24 19:09:25 <mps> ok, np. I'm ready to test when you made something
2019-06-24 19:11:06 <Cogitri> Thank you :)
2019-06-24 19:12:50 <mps> pleasure is mine :)
2019-06-24 19:39:38 <mps> clandmeter: I tried to build some pkg's on armv7 which makedepends on clang and they passed 'abuild -r'. clang8 is used
2019-06-24 19:53:01 <clandmeter> mps, thx
2019-06-24 19:55:50 <mps> np, happy to help
2019-06-24 20:01:52 <maxice8> pr9063 is looking for a maintainer
2019-06-24 22:24:27 <SpaceToast> ping _ikke_
2019-06-25 00:25:50 <SpaceToast> maxice8: re: pr9018, looks like merging mine first and (maybe) adding the gpg stuff later is the way we want to go
2019-06-25 00:26:28 <maxice8> Ok, i'm working on xbps and merging a few others and will look on it, thanks for working it out
2019-06-25 00:27:27 <SpaceToast> I suspect the situation proper is a bit more complex than that, and would recommend reading the entirety of the conversation in the other PR; but at the end of the day the result is the result
2019-06-25 01:36:03 <maxice8> pr7916 pr7961 can be closed as elixir has been updated outside those PRs
2019-06-25 01:58:45 <maxice8> I need something mirrored in Alpine
2019-06-25 01:58:53 <maxice8> popt's host website disappeared
2019-06-25 01:59:00 <maxice8> #10608
2019-06-25 02:20:07 <ddevault> font-noto-cjk bump
2019-06-25 04:25:44 <_ikke_> SpaceToast: pong
2019-06-25 04:26:42 <SpaceToast> _ikke_: someone has _pkgname=x; pkgname=$_pkgname and then uses $_pkgname everywhere, and claims that they're doing so based on your advice
2019-06-25 04:26:57 <SpaceToast> can you please explain why that's preferable?
2019-06-25 04:28:47 <_ikke_> The only thing I advised against is using $pkgname in places that we don't control
2019-06-25 04:29:27 <SpaceToast> hm, like what?
2019-06-25 04:29:43 <SpaceToast> for reference, I'm referring to https://github.com/alpinelinux/aports/pull/8248#discussion_r296507069
2019-06-25 04:30:38 <_ikke_> SpaceToast: Let me put it another way: if we for some reason decide to rename the package (or someone wants to create a dedicated package), the APKBUILD should not break
2019-06-25 04:31:19 <_ikke_> so the upstream project name and the package name are two separate things, which can change for separate reasons
2019-06-25 04:32:08 <_ikke_> some people want to use $pkgname everywhere they see a reference to the project name
2019-06-25 04:32:08 <SpaceToast> ok, so it's just about having the source= listing not use $pkgname in it
2019-06-25 04:32:10 <SpaceToast> gotcha
2019-06-25 04:32:17 <SpaceToast> that makes sense...
2019-06-25 04:32:24 <SpaceToast> but sounds like they misunderstood you, then :(
2019-06-25 04:32:35 <_ikke_> SpaceToast: well, the archive name can have the pkgname in it
2019-06-25 04:32:48 <_ikke_> $pkgname-$pkgver.tar.gz::http://...
2019-06-25 04:33:33 <SpaceToast> yeah, I get it, I think
2019-06-25 04:33:43 <SpaceToast> the case in point definitely seems like it misunderstands the point though :/
2019-06-25 04:34:06 <_ikke_> yes, I see indeed
2019-06-25 09:34:37 <danieli> if they did that, then yeah, it definitely has to be a misunderstanding
2019-06-25 09:44:27 <mps> do we have some kind of resolution in regard to this
2019-06-25 09:50:08 <danieli> in regards to what?
2019-06-25 09:53:31 <mps> in regard PR 8248 and veify()
2019-06-25 14:56:04 <tmhoang> APKBUILD masters, how do I disable building doc ? aka do not running make in subdir po/, man/ etc.
2019-06-25 14:56:24 <tmhoang> overriding default doc() with empty doc() in APKBUILD ?
2019-06-25 14:56:40 <danieli> is $pkgname-doc in $subpackages?
2019-06-25 14:57:22 <tmhoang> tried both, with and without, no effect
2019-06-25 14:57:29 <danieli> I was going to suggest removing it
2019-06-25 14:59:32 <SpaceToast> doc() just copies the build docs from pkgdir to subpkgdir
2019-06-25 14:59:45 <SpaceToast> if you don't want your build system to build the docs, you have to figure out the project's build system
2019-06-25 14:59:58 <SpaceToast> if it's cmake, it might have an option for that, and there's always patching
2019-06-25 15:00:14 <SpaceToast> built docs*
2019-06-25 15:03:23 <tmhoang> SpaceToast: just read abuild and figured that. Thanks
2019-06-25 15:39:12 <tmhoang> pulseaudio doc + translation is pita : https://github.com/alpinelinux/aports/pull/9098
2019-06-25 15:39:58 <_ikke_> I think it's not uncommmon to disable translations on alpine
2019-06-25 15:57:35 <Cogitri> Our gettext is a bit broken, yes :c
2019-06-25 15:57:50 <Cogitri> <_ikke_ "I think it's not uncommmon to di"> Something we should change IMHO
2019-06-25 17:24:45 <ddevault> are we splitting static libs out into -static now? I like them in -dev
2019-06-25 17:25:23 <maxice8> ddevault: quite some time ago
2019-06-25 17:25:26 <maxice8> And yes
2019-06-25 17:26:11 <ddevault> an obsolete policy, then?
2019-06-25 17:26:38 <maxice8> Obsolete?
2019-06-25 17:26:39 <_ikke_> It's something new, so it's not obsolete
2019-06-25 17:26:48 <ddevault> oh, I misunderstood
2019-06-25 17:26:50 <ddevault> well, -1
2019-06-25 17:27:46 <_ikke_> https://bugs.alpinelinux.org/issues/10353
2019-06-25 17:28:11 <_ikke_> The bug does not mention why it's considered not optimal
2019-06-25 17:28:22 <ddevault> >we don't want to accidentally link to static libs in our packages
2019-06-25 17:28:24 <maxice8> Anyways I did the changes on abuild for it to happen and ncopa asked me, there is a pull request with his reasoning but I can't find it right now
2019-06-25 17:28:25 <ddevault> via ncopa on github
2019-06-25 17:28:34 <ddevault> doesn't -dev depend on !-dev?
2019-06-25 17:28:40 <maxice8> That should be it I think
2019-06-25 17:28:57 <_ikke_> https://github.com/alpinelinux/aports/pull/7300#issuecomment-486952274
2019-06-25 17:30:40 <ddevault> registered my thoughts on the bugs.a.o ticket
2019-06-25 17:30:41 <ddevault> thanks
2019-06-25 21:35:55 <maxice8> PureTryOut: plasma-pa seems to be failing lots
2019-06-25 21:38:01 <PureTryOut[m]> Failing how?
2019-06-25 21:40:00 <mps> PureTryOut[m]: https://build.alpinelinux.org/buildlogs/build-edge-aarch64/testing/plasma-pa/plasma-pa-5.16.2-r0.log
2019-06-25 21:43:28 <PureTryOut[m]> Ah... That's fun.. It's unrelated to the Plasma update, but because of https://github.com/alpinelinux/aports/pull/9037
2019-06-25 21:44:26 <PureTryOut[m]> Basically, Plasma needs to use polkit-elogind to allow running applications with elevated permissions when required, like shutting down your system, connecting to the network with networkmanager, etc. However, networkmanager depends on polkit, without elogind
2019-06-25 21:44:47 <PureTryOut[m]> Not entirely sure how to resolve this... Except for moving networkmanager to polkit-elogind entirely
2019-06-25 21:46:19 <PureTryOut[m]> Is there a valid case still for wanting networkmanager but not elogind? I mean, some people might want ConsoleKit2, but it's unmaintained upstream and hasn't seen a commit since 2017
2019-06-25 21:50:58 <terror> PureTryOut[m]: is there any open issues or bugs for ConsoleKit2? If it is feature complete and stable, there's no need to keep adding 'stuff' to it.
2019-06-25 21:51:38 <terror> Asking out of curiosity, I see the "there's been no commits since xxxx" comments a lot these days.
2019-06-25 21:51:45 <PureTryOut[m]> 17 open issues, 7 pull requests open, last one being march 4 last year
2019-06-25 21:51:58 <terror> (Y)
2019-06-25 21:52:46 <PureTryOut[m]> Also, a bug report by an Adélie dev about random segfaults, open since last january
2019-06-25 21:52:59 <PureTryOut[m]> (Adélie dev meaning also a musl environment)
2019-06-25 21:53:23 <terror> Yes, I've heard of Adelie
2019-06-25 21:54:38 <PureTryOut[m]> So yes I'd call it fairly dead. Also no comment from the dev to any of that
2019-06-25 22:17:29 <PureTryOut[m]> maxice8: do note that your last commit basically made `plasma` (the meta package) uninstallable. Please also remove it from there if this is the temporary workaround
2019-06-25 22:17:43 <maxice8> ok will do that
2019-06-25 22:17:46 <PureTryOut[m]> Still, I think a choice should be made here what to do with polkit
2019-06-25 22:18:01 <PureTryOut[m]> (I meant remove plasma-pa from depends of `plasma` btw, not disable the arch)
2019-06-25 22:18:22 <maxice8> It can be done but i need the builders available to do other stuff so while we deliberate whether to do which will take loads of time and require input from other devs i can keep the builders not stuck
2019-06-25 22:18:36 <PureTryOut[m]> Personally I'd get rid of polkit without elogind
2019-06-25 22:18:47 <PureTryOut[m]> Yeah of course
2019-06-25 22:20:46 <maxice8> I'll take a look at Void Linux they have all 3 of those, polkit, polkit-consolekit and polkit-elogind
2019-06-25 22:22:36 <PureTryOut[m]> Hmm
2019-06-25 22:27:25 <PureTryOut[m]> They have some if statement in their build script https://github.com/void-linux/void-packages/blob/master/srcpkgs/NetworkManager/template#L16
2019-06-25 22:27:30 <PureTryOut[m]> Not sure what the resulting package is though
2019-06-25 22:28:09 <maxice8> It is disabled by default, that asks if the elogind option is on and it is not in build_options_default=
2019-06-25 22:28:23 <maxice8> so the resulting package has it disabled, but polkit-elogind has replaces= and provides= for polkit
2019-06-25 22:29:03 <PureTryOut[m]> Ah, so 2 packages in the end still.
2019-06-25 22:29:20 <maxice8> 2 packages ?
2019-06-25 22:29:32 <PureTryOut[m]> polkit and polkit-elogind. Both the same, one just with elogind enabled
2019-06-25 22:29:41 <PureTryOut[m]> The elogind one having the proper replaces and provides
2019-06-25 22:29:41 <maxice8> yes
2019-06-25 22:29:46 <PureTryOut[m]> In theory that could work for us too then
2019-06-25 22:30:07 <PureTryOut[m]> networkmanager would still be built against regular polkit, but it would be fine with having polkit-elogind running instead?
2019-06-25 22:30:26 <maxice8> to be honest
2019-06-25 22:30:55 <maxice8> i never touched NetworkManager, you will have to ask cogitri
2019-06-25 22:43:28 <PureTryOut[m]> I doubt he is online anymore, it'll have to wait till tomorrow
2019-06-25 22:44:23 <maxice8> Yes he is in CEST timezone, he should be awake in 6 to 7 hours
2019-06-25 22:46:24 <PureTryOut[m]> So am I, I'm just always awake too late
2019-06-25 22:46:32 <PureTryOut[m]> Mainly because it's impossible to sleep with these temperatures...
2019-06-25 22:46:53 <maxice8> i think this is more fit in -offtopic
2019-06-25 22:50:17 <PureTryOut[m]> Agreed lol
2019-06-25 23:00:07 <kaniini> ncopa: ping
2019-06-26 00:20:14 <maxice8> PureTryOut: Kitinerary is failing https://build.alpinelinux.org/buildlogs/build-edge-x86_64/testing/kitinerary/kitinerary-19.04.2-r0.log
2019-06-26 01:10:09 <Cogitri> <PureTryOut[m] "Personally I'd get rid of polkit"> Won't fly, lots of people don't want to pull in elogind
2019-06-26 01:10:31 <Cogitri> polkit-elogind has provides=, so it should work just fine on runtime
2019-06-26 01:10:59 <Cogitri> I didn't add provides to the -dev package od polkit-elogind though, since the builders don't need that - maybe I should so that
2019-06-26 01:20:44 <Cogitri> Also, ck2 is dead but well, it works
2019-06-26 07:17:20 <PureTryOut[m]> <Cogitri "Won't fly, lots of people don't "> Yeah I know, which is why I said "personally" :p
2019-06-26 07:19:45 <PureTryOut[m]> Maybe polkit-qt can be built with regular polkit, and polkit-agent-1 can still work with polkit-elogind instead. I'll experiment
2019-06-26 07:36:25 <Cogitri> Yup, that should workfine
2019-06-26 08:24:12 <ncopa> kaniini: pong
2019-06-26 08:30:38 <PureTryOut[m]> cogitri: no it doesn't like that...
2019-06-26 08:30:54 <PureTryOut[m]> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/v1/download/matrix.org/vBSCWJnJuJDwICXyazySghJq >

2019-06-26 08:33:39 <Cogitri> That's on a clean container?
2019-06-26 08:33:54 <Cogitri> <Cogitri "I didn't add provides to the -de"> ^
2019-06-26 08:34:19 <Cogitri> That causes stuff to break if you have polkit-elogind installed on the system and it tries to pull in polkit-dev
2019-06-26 08:34:42 <PureTryOut[m]> docker-abuild, so yes clean container
2019-06-26 08:34:48 <Cogitri> Didn't hit that because I only build in clean containers (like the builders do)
2019-06-26 08:34:58 <PureTryOut[m]> Yeah I'm trying to add the provides to the -dev package atm
2019-06-26 08:35:05 <Cogitri> Huh, wfm, I guess something else pulls in polkit-elogind then?
2019-06-26 08:36:01 <Cogitri> Good 👍
2019-06-26 08:43:42 <PureTryOut[m]> Yeah adding provides to the -dev package works
2019-06-26 09:08:16 <PureTryOut[m]> pr9124 will fix the issue
2019-06-26 09:11:46 <PureTryOut[m]> <maxice8 "PureTryOut: Kitinerary is failin"> That doesn't make sense. It's failing to link to libphonenumber it seems. Which arch is this? It built fine locally
2019-06-26 10:18:20 <clandmeter> PureTryOut[m]: do you know our commits channel?
2019-06-26 10:32:14 <PureTryOut[m]> I do not?
2019-06-26 10:37:11 <mps> PureTryOut[m]: IRC on freenode  #alpine-commits
2019-06-26 10:37:29 <PureTryOut[m]> What is the channel about though?
2019-06-26 10:39:03 <mps> aports commits and failed  builds
2019-06-26 10:39:41 <mps> and successful uploads
2019-06-26 10:39:46 <clandmeter> PureTryOut[m]: i see some of your commits fail, thats why its good to join.
2019-06-26 10:40:25 <PureTryOut[m]> Seems like a lot of spam, but sure
2019-06-26 10:40:41 <clandmeter> spam?
2019-06-26 10:40:58 <mps> it can sometimes be quite annoying but at the end it is very useful for dev's
2019-06-26 10:41:10 <clandmeter> focus on it when you commit stuff
2019-06-26 10:41:27 <clandmeter> your name will be in the announcement, you should trigger on it
2019-06-26 10:43:00 <PureTryOut[m]> Ah yeah that'll notify me
2019-06-26 10:46:11 <Cogitri> Oh neat, didnt know about that
2019-06-26 11:14:00 <tmhoang> <clandmeter> your name will be in the announcement, you should trigger on it ---> How so with Hexchat ? my user name is tmhoang, real name is Tuan Hoang.
2019-06-26 11:14:25 <tmhoang> ok dummy question
2019-06-26 12:03:46 <clandmeter> tmhoang: should be an option in settings
2019-06-26 12:03:50 <clandmeter> highlight whatever
2019-06-26 12:03:56 <clandmeter> i dont use hexchat
2019-06-26 12:07:30 <clandmeter> maxice8: can you join #alpine-infra ?
2019-06-26 12:08:27 <maxice8> Yes
2019-06-26 12:13:12 <clandmeter> tmhoang: its in settings -> Chatting -> Alerts -> highlight...
2019-06-26 12:13:42 <tmhoang> im in love
2019-06-26 12:14:06 <clandmeter> you are in the wrong channel for love
2019-06-26 12:14:21 <clandmeter> except if y ou love developement
2019-06-26 12:14:44 <maxice8> Who doesn't love AL?
2019-06-26 12:15:13 <_ikke_> 
ACTION hears chirping

2019-06-26 12:15:35 <tmhoang> clandmeter: how thelounge with Alpine infra ?
2019-06-26 12:15:35 <clandmeter> loving alpine goes to #alpine-love
2019-06-26 12:16:04 <clandmeter> or send postcards to ncopa ;-)
2019-06-26 12:16:04 <maxice8> _ikke_: it was a rethorical question I already picked your answers
2019-06-26 12:16:30 <clandmeter> tmhoang: ?
2019-06-26 12:17:20 <clandmeter> we have an thelounge instance on alpine infra. developers/members can request an account.
2019-06-26 12:19:25 <tmhoang> clandmeter: can i have one or is there a url to register?
2019-06-26 12:19:40 <clandmeter> no i need to do that manually
2019-06-26 12:20:21 <tmhoang> help me please
2019-06-26 12:22:04 <PureTryOut[m]> So I'm not sure why Kitinerary fails building. It only fails on x86_64, but I can compile it fine locally on that architecture. Maybe it just needs a build retrigger?
2019-06-26 12:22:33 <PureTryOut[m]> Maybe it builds Kitinerary before libphonenumber? As the latter isn't yet in the x86_64 repos
2019-06-26 12:22:34 <clandmeter> probably not
2019-06-26 12:22:41 <clandmeter> but you can ask algitbot to retry
2019-06-26 12:22:49 <clandmeter> algitbot: retry master
2019-06-26 12:22:52 <PureTryOut[m]> How would I do that?
2019-06-26 12:23:21 <PureTryOut[m]> Can I somehow see if it tried building libphonenumber?
2019-06-26 12:23:42 <clandmeter> you can find that also yourself
2019-06-26 12:23:51 <clandmeter> check the commits channel
2019-06-26 12:24:00 <clandmeter> you can also find the buildlog
2019-06-26 12:24:18 <clandmeter> if its build you can also see it in pkgs.a.o
2019-06-26 12:25:27 <PureTryOut[m]> The commits channel doens't have enough scrollback yet
2019-06-26 12:25:37 <PureTryOut[m]> But I guess it skipped that build for some reason
2019-06-26 12:27:02 <PureTryOut[m]> Ok so it seems uploading the packages has gone wrong or something. libphonenumber is fact built correctly for x86_64
2019-06-26 12:27:03 <PureTryOut[m]> Actually, it's even installed for Kitinerary...
2019-06-26 12:27:37 <clandmeter> if you think it failed you can reconstruct the buildlog
2019-06-26 12:27:44 <clandmeter> see whats wrong
2019-06-26 12:30:29 <PureTryOut[m]> Yeah I'm not sure at all why it's failing, going to ask the KDE devs for help
2019-06-26 12:31:52 <clandmeter> PureTryOut[m]: how do you build pkgs locally?
2019-06-26 12:31:55 <clandmeter> abuild -r?
2019-06-26 12:32:45 <clandmeter> have you tried using rootbld?
2019-06-26 12:33:17 <PureTryOut[m]> `dabuild -r`
2019-06-26 12:33:19 <_ikke_> clandmeter: any idea how we do rootbld in lxc containers?
2019-06-26 12:33:35 <clandmeter> _ikke_: it does not work?
2019-06-26 12:33:42 <clandmeter> i think i used it before
2019-06-26 12:33:54 <_ikke_> Not when I last tried it a couple of weeks before
2019-06-26 12:34:10 <clandmeter> maybe its a lxc config option
2019-06-26 12:34:19 <_ikke_> I suspect so
2019-06-26 12:34:22 <clandmeter> check my config
2019-06-26 12:34:40 <clandmeter> x86_64 clandmeter
2019-06-26 12:34:45 <clandmeter> edge
2019-06-26 12:34:50 <clandmeter> not sure the right format :)
2019-06-26 12:35:20 <clandmeter> PureTryOut[m]: dabuild -r should be similar to rootbld with some exceptions
2019-06-26 12:35:37 <PureTryOut[m]> You'd think so
2019-06-26 12:35:57 <clandmeter> so you are not getting those linker issues when running in dabuild?
2019-06-26 12:36:10 <PureTryOut[m]> Nope
2019-06-26 12:36:19 <_ikke_> clandmeter: bwrap: capset failed: Operation not permitted
2019-06-26 12:36:22 <_ikke_> ok, will do
2019-06-26 12:36:38 <clandmeter> yeah i think thats lxc config option
2019-06-26 12:36:42 <clandmeter> to restrictive
2019-06-26 12:37:07 <_ikke_> Yeah, I can imagine
2019-06-26 12:38:23 <clandmeter> _ikke_: found it
2019-06-26 12:38:26 <clandmeter> # commented to make abuild rootbld work
2019-06-26 12:38:26 <clandmeter> #lxc.cap.drop = sys_admin
2019-06-26 12:39:22 <_ikke_> alright, thanks
2019-06-26 14:00:25 <danieli> (10/233) Installing openssl-dev (1.1.1c-r0)
2019-06-26 14:00:25 <danieli> ERROR: Failed to create usr/lib/libssl.a: I/O error
2019-06-26 14:00:25 <danieli> ERROR: openssl-dev-1.1.1c-r0: IO ERROR
2019-06-26 14:00:28 <danieli> wtf, i just saw this on drone ci
2019-06-26 14:01:20 <danieli> add ci-malfunction to pr9132
2019-06-26 14:02:08 <ncopa> may be network error
2019-06-26 14:02:31 <danieli> i suspect it either has the package cached or downloaded it, and encountered some temporary error while extracting it onto the filesystem
2019-06-26 14:05:17 <Cogitri> Just restart the CI?
2019-06-26 14:05:33 <Cogitri> That happens to me from time to time too
2019-06-26 14:06:27 <danieli> bah, i'll have to force push later then
2019-06-26 14:06:47 <PureTryOut[m]> I have that error happen multiple times on several PR's I made
2019-06-26 14:06:53 <PureTryOut[m]> Also happens for different packages, seems random
2019-06-26 14:06:55 <danieli> interesting
2019-06-26 14:08:11 <danieli> okay, that did not work, i hate force pushing
2019-06-26 14:08:37 <danieli> i usually avoid it at all costs, and it's a bit wonky since i'm not super used to the CI workflow on github
2019-06-26 14:19:16 <danieli> (141/233) Installing icu-libs (64.2-r0)
2019-06-26 14:19:16 <danieli> ERROR: Failed to create usr/lib/libicudata.so.64.2: I/O error
2019-06-26 14:19:16 <danieli> ERROR: icu-libs-64.2-r0: IO ERROR
2019-06-26 14:19:22 <danieli> is it really this bad?
2019-06-26 14:19:30 <danieli> twice in a row
2019-06-26 14:19:57 <PureTryOut[m]> Just restart the CI till it works
2019-06-26 14:19:57 <PureTryOut[m]> Yes it is really that bad
2019-06-26 14:38:15 <Cogitri> <danieli "okay, that did not work, i hate "> Why?
2019-06-26 14:38:51 <danieli> I justified what I said in the next message 😛
2019-06-26 14:43:35 <Cogitri> Ah, missed the "super used to the CI workflow and Github somehow", my bad
2019-06-26 14:45:32 <Cogitri> Also, would be welcomed if more people commented on #10603, I'd like to start working on this before I'm off to holidays
2019-06-26 14:45:59 <Cogitri> Without -dbg packages bugs like #10612 are hard/impossible to properly debug
2019-06-26 14:46:35 <Cogitri> Err..I mean #10591
2019-06-26 14:51:29 <clandmeter> Cogitri: it has been discussed yes, but its not a simple task to replace the init system.
2019-06-26 14:55:27 <Cogitri> I switched Exherbo over from openrc to s6-rc, the real work was rewriting all the services, yes :/
2019-06-26 15:01:10 <PureTryOut[m]> Wait, replace init system? Why? To what?
2019-06-26 15:01:10 <Cogitri> s6-rc or 66 because OpenRC isn't that nice (see: https://skarnet.org/software/s6-rc/why.html)
2019-06-26 15:01:36 <Cogitri> I mean openRC does work, but I was curious if this has been discussed already :)
2019-06-26 15:08:48 <SpaceToast> openrc just needs some work done :)
2019-06-26 15:09:16 <SpaceToast> s6 is alright though; I'm more familiar with runit but it seems to be in the same family, but with ways to deal with doublefork
2019-06-26 15:10:24 <PureTryOut[m]> Interesting
2019-06-26 15:18:48 <mps> Cogitri: it is discussed few times, systemd is no-no
2019-06-26 15:19:51 <mps> runit or s6 are better options
2019-06-26 15:20:46 <mps> openrc is still fine, imo
2019-06-26 15:20:56 <PureTryOut[m]> pr9133 should in theory fix the Kitinerary build error happening on the x86_64 builder
2019-06-26 15:21:03 <PureTryOut[m]> I only know once it's merged though...
2019-06-26 15:22:07 <Cogitri> mps: Expected that, upstream systemd doesn't work on musl
2019-06-26 15:23:10 <mps> and, SpaceToast just told that she is ready to take over openrc because current upstream lose interest in it
2019-06-26 15:23:45 <SpaceToast> don't quite have the time, but my PoV is that even if I touch it for 1h every other Friday, that'll still be better than the current state of things
2019-06-26 15:24:43 <PureTryOut[m]> Current upstream loses interest in OpenRC? Upstream is Gentoo right? What are they planning on using instead then?
2019-06-26 15:24:50 <SpaceToast> no, upstream is openrc
2019-06-26 15:25:06 <SpaceToast> William Hubbs (williamh) insisted that OpenRC should be independent of Gentoo (good idea!) after he took over maintainership
2019-06-26 15:25:20 <SpaceToast> ... then he got more interested in systemd and mostly stopped doing things
2019-06-26 15:25:42 <SpaceToast> last commit is from months ago (simple bugfix, no release with it still), and lots of PRs/bugs are just ignored
2019-06-26 15:25:48 <SpaceToast> well, lots -> basically all
2019-06-26 15:27:08 <PureTryOut[m]> Ugh...
2019-06-26 15:27:43 <danieli> i wish s6 had better docs and didn't strive so hard to be different in every way
2019-06-26 15:28:26 <Cogitri> IMO s6 isn't really meant to be used by a distro but just by individuals, the compiling and stuff is super annoying to implement properly for a distro
2019-06-26 15:28:40 <Cogitri> 66 is way nicer in this regard but still in beta
2019-06-26 15:29:31 <Cogitri> Regarding #10591 : do we still do grsec stuff?
2019-06-26 15:30:55 <danieli> pr9132 is waiting for a reply from upstream about a bug with armv7 and aarch64, so put the hold tag on it or something
2019-06-26 15:31:08 <danieli> https://github.com/elixir-lang/elixir/issues/9167
2019-06-26 15:52:45 <Cogitri> <Cogitri "Regarding #10591 : do we still d"> Do I close it as rejected?
2019-06-26 15:53:40 <_ikke_> danieli: done
2019-06-26 15:54:06 <danieli> ./hat tip
2019-06-26 15:56:02 <_ikke_> Cogitri: I guess just close it
2019-06-26 15:56:43 <Cogitri> Alright, done
2019-06-26 18:58:24 <PureTryOut[m]> Could someone merge pr9133? It should hopefully fix the stuck x86_64 builder
2019-06-26 19:05:23 <mps> PureTryOut[m]: let's see
2019-06-26 19:05:35 <PureTryOut[m]> 
ACTION crosses his fingers

2019-06-26 19:05:46 <mps> you are on #alpine-commits?
2019-06-26 19:07:37 <mps> hmm, it failed on x86_64
2019-06-26 19:11:04 <mps> PureTryOut[m]: looks like libphonenumber is not built or uploaded
2019-06-26 19:11:31 <PureTryOut[m]> Not uploaded, log showed it built correctly
2019-06-26 19:11:31 <clandmeter> Don't bump pkgrel
2019-06-26 19:11:49 <PureTryOut[m]> I am on #alpine-commits yes
2019-06-26 19:12:04 <clandmeter> And that commit msg is useless
2019-06-26 19:12:22 <PureTryOut[m]> Also libphonenumber is actually installed while building kitinerary
2019-06-26 19:12:47 <clandmeter> mps: ^
2019-06-26 19:13:10 <PureTryOut[m]> Actually, maybe removing libphnenumber from deps entirely is a better approach for now. Seems to be an optional dependency
2019-06-26 19:13:17 <mps> clandmeter: sorry, just pushed PureTryOut[m] PR, didn't looked carefully
2019-06-26 19:13:40 <mps> my bad
2019-06-26 19:15:18 <mps> 'apk search libphonenumber' gives nothing
2019-06-26 19:16:36 <PureTryOut[m]> Yeah it's not uploaded for whatever reason
2019-06-26 19:17:24 <mps> can we trigger upload somehow
2019-06-26 19:17:27 <clandmeter> It's normal
2019-06-26 19:17:37 <clandmeter> It's on the host
2019-06-26 19:17:47 <clandmeter> Waiting for world to finish
2019-06-26 19:18:23 <PureTryOut[m]> Just remove libphonenumber from the kitinerary deps for now
2019-06-26 19:19:05 <PureTryOut[m]> Preferably just on x86_64 really
2019-06-26 19:19:34 <mps> imo, we should wait it's upload
2019-06-26 19:20:03 <mps> why to have different deps if that is not needed
2019-06-26 19:20:37 <clandmeter> It will not upload...
2019-06-26 19:21:01 <clandmeter> Or disable the failing aport and it will
2019-06-26 19:21:17 <clandmeter> It needs to finish the queue
2019-06-26 19:21:20 <clandmeter> To
2019-06-26 19:22:13 <mps> can we then bump pkgrel of libphonenumber to trigger build and upload
2019-06-26 19:25:27 <PureTryOut[m]> Just disable libphonenumber on x86_64 for Kitinerary and trigger a rebuild
2019-06-26 19:25:35 <PureTryOut[m]> That should do it, as libphonenumber is an optional dependency
2019-06-26 19:27:16 <clandmeter> You don't need it to upload, the builder has it
2019-06-26 19:27:16 <mps> PureTryOut[m]: you are maintainer of both pkg's, so please do what you think is right
2019-06-26 19:27:40 <clandmeter> It will upload when queue is finished
2019-06-26 19:27:47 <clandmeter> I hope it's clear now
2019-06-26 19:27:54 <mps> patience, then ;)
2019-06-26 19:28:17 <clandmeter> No, you need to fix that aport
2019-06-26 19:28:31 <clandmeter> Then queue continues
2019-06-26 19:28:42 <clandmeter> At the end it upload
2019-06-26 19:28:50 <PureTryOut[m]> mps: sure
2019-06-26 19:28:52 <mps> clandmeter: me, or PureTryOut[m] have to fix it
2019-06-26 19:28:55 <clandmeter> That's the process
2019-06-26 19:32:18 <clandmeter> Make sure ci passed before pushing to aports
2019-06-26 19:33:22 <PureTryOut[m]> That will be impossible
2019-06-26 19:33:44 <clandmeter> Tell me why
2019-06-26 19:33:45 <PureTryOut[m]> As it will be searching for dependencies that are in the aports tree, but not in the binary repos yet
2019-06-26 19:33:56 <PureTryOut[m]> Can commits be reverted btw? 35ee7505c6f44c55d2098b1dcc1712ca7a7c8404 should if so
2019-06-26 19:34:07 <clandmeter> Then add them to the pr
2019-06-26 19:34:13 <clandmeter> That's how it works
2019-06-26 19:34:27 <PureTryOut[m]> But they are already in the tree...
2019-06-26 19:34:34 <PureTryOut[m]> How can I add them if they're already there?
2019-06-26 19:35:37 <PureTryOut[m]> I mean, I can add a commit that removes and re-adds them, but that seems wrong
2019-06-26 19:36:59 <clandmeter> So it's done wrong from the start
2019-06-26 19:37:14 <PureTryOut[m]> I'm not surewhat you mean?
2019-06-26 19:38:22 <PureTryOut[m]> They were added in the PR that needs them. They are built succesfully, just not uploaded to the repos as world isn't finished. CI in a new PR won't find them because of them not being in the repos, and it won't rebuild them as they're not new from that PR
2019-06-26 19:39:41 <clandmeter> if it was build succesfully it should have uploaded
2019-06-26 19:40:36 <clandmeter> what was the original PR?
2019-06-26 19:40:49 <PureTryOut[m]> Well no, as not everything in that PR built succesfully. Like you said, they aren't uplaoded because world isn't done
2019-06-26 19:41:30 <PureTryOut[m]> pr9107 is the original
2019-06-26 19:42:48 <clandmeter> https://cloud.drone.io/alpinelinux/aports/7847
2019-06-26 19:43:20 <clandmeter> somebody pushed while ci didnt pass
2019-06-26 19:44:45 <PureTryOut[m]> Yeah, that was a mistake
2019-06-26 19:44:47 <PureTryOut[m]> However, it failed onx86
2019-06-26 19:44:50 <PureTryOut[m]> While the builders fail on x86_64
2019-06-26 19:45:28 <PureTryOut[m]> Also, on x86 in the CI it failed on libphonenumbers itself, but on the Alpine builders x86_64 fails on Kitinerary
2019-06-26 19:45:34 <clandmeter> does that issue also happen on your local machine?
2019-06-26 19:45:35 <PureTryOut[m]> Honestly, it makes no sense at all
2019-06-26 19:46:05 <clandmeter> can you reproduce it
2019-06-26 19:46:15 <PureTryOut[m]> I can not
2019-06-26 19:46:16 <PureTryOut[m]> Otherwise I wouldn't have pushed it
2019-06-26 19:46:24 <PureTryOut[m]> And CI clearly couldn't reproduce it either
2019-06-26 19:46:39 <clandmeter> but you disabled tests?
2019-06-26 19:47:37 <PureTryOut[m]> Right now in a new PR I did yes
2019-06-26 19:47:45 <PureTryOut[m]> Uhm, sorry, my last PR to that package
2019-06-26 19:47:53 <PureTryOut[m]> As the errors come from building the tests
2019-06-26 19:48:00 <PureTryOut[m]> So I thought, "let's disable building the tests altogether"
2019-06-26 19:48:10 <clandmeter> but that didnt fix it?
2019-06-26 19:48:54 <PureTryOut[m]> No, as there is still an error left in the package itself, outside of the tests
2019-06-26 19:49:03 <PureTryOut[m]> So now my solution is just removing that optional dep entirely
2019-06-26 19:49:11 <PureTryOut[m]> This is the last failure https://build.alpinelinux.org/buildlogs/build-edge-x86_64/testing/kitinerary/kitinerary-19.04.2-r1.log
2019-06-26 19:49:22 <PureTryOut[m]> Less errors, that's for sure, but still there
2019-06-26 19:49:37 <clandmeter> doesnt that look like the same issue as beofre?
2019-06-26 19:49:54 <PureTryOut[m]> It is the same issue, but it occurs less
2019-06-26 19:50:10 <PureTryOut[m]> This same "undefined reference" happened in multiple places
2019-06-26 19:50:14 <PureTryOut[m]> Mainly in the unit tests
2019-06-26 19:50:17 <PureTryOut[m]> So I disabled those
2019-06-26 19:50:41 <PureTryOut[m]> However, it seems they're also in the actual package itself. So just disabling the tests isn't enough
2019-06-26 19:50:50 <PureTryOut[m]> Actually, tests will probably work with this optional dep removed
2019-06-26 19:52:15 <PureTryOut[m]> so pr9140 removes the dep entirely
2019-06-26 19:53:16 <clandmeter> looks like your tree is broken, it cant merge your patch
2019-06-26 19:54:14 <PureTryOut[m]> Oh probs just need a rebase, hold on
2019-06-26 19:54:31 <PureTryOut[m]> Try again?
2019-06-26 19:55:09 <mps> tried build of libphonenumber on x86_64 in my local lxc, it worked cleanly
2019-06-26 19:56:01 <_ikke_> mps: I see kitinerary failing on x86_64 atm, isn't that blocking the upload?
2019-06-26 19:56:32 <mps> I think so
2019-06-26 19:56:40 <PureTryOut[m]> Yeah the issue isn't libphonenumber
2019-06-26 19:57:17 <_ikke_> mps: the build script will only upload after every package in the queue succesfully built
2019-06-26 19:57:21 <mps> maybe disable kitinerary on x86_64 temporary
2019-06-26 19:57:45 <_ikke_> Yes, I guess that makes sense
2019-06-26 19:57:52 <_ikke_> It's still in testing
2019-06-26 19:57:59 <PureTryOut[m]> No guys read the chat
2019-06-26 19:58:10 <PureTryOut[m]> pr9140 fixes the problem
2019-06-26 19:58:15 <PureTryOut[m]> I just explained it all lol
2019-06-26 19:58:22 <_ikke_> sorry
2019-06-26 19:58:56 <mps> PureTryOut[m]: but you will have to enable (add) it again
2019-06-26 19:59:20 <PureTryOut[m]> Eventually hopefully
2019-06-26 19:59:26 <PureTryOut[m]> But at least it'll unstuck the builders for now
2019-06-26 19:59:27 <PureTryOut[m]> *builder
2019-06-26 19:59:40 <PureTryOut[m]> I'll have to find how to reproduce the issue in the meantime
2019-06-26 19:59:44 <mps> simplest it to disable build on specific arch
2019-06-26 19:59:51 <_ikke_> Sadly the commit message doesn't explain why
2019-06-26 20:00:19 <PureTryOut[m]> Ugh, I'll reword it
2019-06-26 20:00:28 <clandmeter> as mentioned before, the commit messages are useless.
2019-06-26 20:01:07 <clandmeter> sorry im grumpy
2019-06-26 20:01:38 <PureTryOut[m]> It literally says what it does. The reason the dep is removed is explained in the APKBUILD itself
2019-06-26 20:01:51 <PureTryOut[m]> But, I'll add an explanation in the commit message too
2019-06-26 20:02:25 <_ikke_> I almost always start with the commit message to get an idea of what is being achieved
2019-06-26 20:02:26 <PureTryOut[m]> Changed it
2019-06-26 20:08:28 <clandmeter> PureTryOut[m]: can you try to wrap lines at 80chars?
2019-06-26 20:08:58 <clandmeter> also when you have a long list, its more git diff friendly to do them line by line.
2019-06-26 20:09:08 <PureTryOut[m]> Sure
2019-06-26 20:09:22 <PureTryOut[m]> Exactly 80 or is say 83 fine too?
2019-06-26 20:09:39 <clandmeter> try to keep it lower than 80
2019-06-26 20:09:49 <clandmeter> but like for makedepends do them line by line
2019-06-26 20:10:01 <clandmeter> you have a gaziilion of htem in kitternary
2019-06-26 20:10:21 <PureTryOut[m]> Wrapped
2019-06-26 20:10:22 <clandmeter> if you modify one of them, the diff gets kind of useless for humans
2019-06-26 20:10:36 <clandmeter> get my point?
2019-06-26 20:10:42 <PureTryOut[m]> That's a gazillion? 😂
2019-06-26 20:11:20 <PureTryOut[m]> I get it, but I personally prefer it different
2019-06-26 20:11:26 <PureTryOut[m]> I'm changing it atm though
2019-06-26 20:11:38 <mps> uhm, just after last msg interrupted link to freenode
2019-06-26 20:11:54 <PureTryOut[m]> Done
2019-06-26 20:12:20 <PureTryOut[m]> Hmm?
2019-06-26 20:13:40 <clandmeter> your comment is still over 80 chars
2019-06-26 20:14:00 <_ikke_> I'll fix that when applying..
2019-06-26 20:14:02 <clandmeter> im nitpicking now, but i hope you get the point
2019-06-26 20:14:19 <PureTryOut[m]> Oh you were talking about the comment?
2019-06-26 20:14:27 <clandmeter> about all lines
2019-06-26 20:14:30 <clandmeter> where possible
2019-06-26 20:14:34 <PureTryOut[m]> I thought you were just complaining about `$makedepends`?
2019-06-26 20:15:07 <clandmeter> PureTryOut[m]: can you try to wrap lines at 80chars?
2019-06-26 20:15:17 <clandmeter> ;-)
2019-06-26 20:15:18 <_ikke_> (Where it makes sense to do so)
2019-06-26 20:15:56 <clandmeter> and for lists i prefer one on each line
2019-06-26 20:16:06 <clandmeter> i dont think its a hard style req
2019-06-26 20:16:11 <PureTryOut[m]> clandmeter: yeah I get it now
2019-06-26 20:16:16 <clandmeter> but it makes diffs much easier to read
2019-06-26 20:16:51 <PureTryOut[m]> I'm not sure if ctest likes it exception list being broken in multiple lines...
2019-06-26 20:16:52 <_ikke_> http://tpaste.us/5wNN
2019-06-26 20:20:38 <clandmeter> i wonder if it makes sense to first disable it and let the builder finish
2019-06-26 20:20:54 <clandmeter> i cant reproduce locally cause of missing deps
2019-06-26 20:21:27 <clandmeter> or i can just build them all locally
2019-06-26 20:21:39 <PureTryOut[m]> Even with the deps I don't think most people can reproduce it, but I'm fine with disabling for now as long as it's re-enabled afterwards
2019-06-26 20:21:54 <clandmeter> ill build them locally
2019-06-26 20:22:26 <clandmeter> i wonder what causes the linker issue
2019-06-26 20:23:01 <PureTryOut[m]> If only I knew...
2019-06-26 20:23:34 <PureTryOut[m]> If only it was reproducable locally... But on the builders it works fine on every arch except x86_64, and locally it builds fine on the failing architecture
2019-06-26 20:34:14 <_ikke_> I built both libphonenumber and kitinary again on the x86_64 builder and now it went through
2019-06-26 20:34:22 <clandmeter> :)
2019-06-26 20:34:44 <clandmeter> im triggering builder now
2019-06-26 20:38:58 <PureTryOut[m]> Wait, that's kitinerary without libphonenumber right?
2019-06-26 20:39:09 <clandmeter> no
2019-06-26 20:39:23 <clandmeter> thats mykitty with phonenumber
2019-06-26 20:40:13 <_ikke_> that's plain silly
2019-06-26 20:40:45 <PureTryOut[m]> mykitty...?
2019-06-26 20:41:38 <clandmeter> oh it was hello kitty
2019-06-26 20:41:56 <clandmeter> PureTryOut[m]: your pr is not pushed yet
2019-06-26 20:42:05 <clandmeter> _ikke_ fixed the builder
2019-06-26 20:42:14 <_ikke_> And might not even be necessary indeed
2019-06-26 20:42:37 <_ikke_> Yup, everythign is green now
2019-06-26 20:43:06 <clandmeter> nice
2019-06-26 20:43:10 <PureTryOut[m]> <_ikke_> I built both libphonenumber and kitinary again on the x86_64 builder and now it went through
2019-06-26 20:43:16 <PureTryOut[m]> Then how did this happen? ^
2019-06-26 20:43:26 <_ikke_> I have direct access to the build containers
2019-06-26 20:43:54 <PureTryOut[m]> Ok. Then how the hell did it go through now?
2019-06-26 20:44:03 <_ikke_> No clue :-)
2019-06-26 20:44:04 <PureTryOut[m]> It failed multiple times before
2019-06-26 20:44:22 <_ikke_> libphonenumber as well>
2019-06-26 20:44:24 <_ikke_> ?
2019-06-26 20:44:40 <PureTryOut[m]> No just kitinerary
2019-06-26 20:44:56 <_ikke_> So I force rebuilt libphonenumber
2019-06-26 20:45:08 <_ikke_> So that might have fixed it
2019-06-26 20:45:27 <PureTryOut[m]> Hmm. Well, whatever fixed it, thanks :D
2019-06-26 20:45:29 <clandmeter> i think what happened was some race condition and it build scripts failed to link libphone to icu or similar
2019-06-26 20:45:59 <PureTryOut[m]> In that case my last PR for it can be ignored
2019-06-26 20:46:08 <PureTryOut[m]> And my last commit reverted (if that's possible)
2019-06-26 20:46:16 <clandmeter> so rebuilding libphone fixed that so kititsomething could build correctly
2019-06-26 20:47:35 <_ikke_> PureTryOut[m]: which one needs to be reverted?
2019-06-26 20:47:52 <clandmeter> disable of test wss
2019-06-26 20:47:54 <PureTryOut[m]> 35ee7505c6f44c55d2098b1dcc1712ca7a7c8404
2019-06-26 20:48:04 <clandmeter> and push the style fix also
2019-06-26 20:48:09 <clandmeter> 2 in one clap
2019-06-26 20:48:48 <_ikke_> The dutch is strong in this one
2019-06-26 20:48:56 <PureTryOut[m]> Lol
2019-06-26 20:49:04 <PureTryOut[m]> Now comes the monkey out of the sleeve
2019-06-26 20:49:22 <_ikke_> oh well, we got to row with the belts that we have
2019-06-26 20:49:58 <PureTryOut[m]> Never look a given horse in the mouth
2019-06-26 20:50:04 <PureTryOut[m]> So, lots of Dutchies here then I assume?
2019-06-26 20:50:16 <_ikke_> at least 4
2019-06-26 20:50:45 <danieli> lol
2019-06-26 20:50:49 <PureTryOut[m]> Well then, greetings fellow Dutchies
2019-06-26 20:50:55 <clandmeter> 4.5 if you count danieli
2019-06-26 20:51:02 <danieli> hahaha
2019-06-26 20:51:08 <PureTryOut[m]> Flamish?
2019-06-26 20:51:11 <danieli> we say "two flies with one smack" in norwegian
2019-06-26 20:51:12 <_ikke_> lol
2019-06-26 20:51:16 <danieli> no
2019-06-26 20:51:26 <danieli> i'm just somewhat adept at dutch
2019-06-26 20:51:30 <_ikke_> danieli: We have the same expression
2019-06-26 20:51:49 <PureTryOut[m]> Ah Norwegian. Jeg snakker ikke Norsk :/
2019-06-26 20:52:03 <danieli> we have #alpine-norwegian, you should make #alpine-dutch
2019-06-26 20:52:43 <clandmeter> my english is better than my dutch, so now you know how much my dutch sucks.
2019-06-26 20:55:13 <mps> is it possible/allowed to push revert to aports
2019-06-26 20:55:47 <_ikke_> yes, it is
2019-06-26 20:56:22 <_ikke_> but for dl-cdn it's best if you make sure that it's still a unique pkgrel-pkver combo
2019-06-26 20:56:41 <mps> I mean, 'git reset --hard commit-hash' && 'git push'
2019-06-26 20:58:24 <clandmeter> no
2019-06-26 20:58:28 <clandmeter> thats not allowed
2019-06-26 20:58:34 <clandmeter> never change history
2019-06-26 20:59:05 <mps>  good, just want to be sure.
2019-06-26 20:59:24 <clandmeter> you can only change history in the future :)
2019-06-26 20:59:49 <mps> imagine someone by mistake resets aports to few years ago
2019-06-26 21:01:44 <PureTryOut[m]> So the x86_64 builder is idle now but not everything has been uploaded to the repos yet
2019-06-26 21:02:01 <PureTryOut[m]> Wait nvm, I just have to be patient for the mirrors to catch up
2019-06-26 21:02:43 <clandmeter> patience is a clean business
2019-06-26 21:26:20 <PureTryOut[m]> so when installing pciutils it has a conflict with it's dependency hwids-pci on the file `/usr/share/hwdata/pci.ids`
2019-06-26 21:26:29 <PureTryOut[m]> Does anyone have an idea how to resolve this?
2019-06-26 21:29:06 <mps> PureTryOut[m]: I think someone talked about this and how to fix, but forgot who actually
2019-06-26 21:29:36 <PureTryOut[m]> That's... useful 😂
2019-06-26 21:30:22 <mps> well, yes :(
2019-06-26 21:32:53 <clandmeter> maybe its caused by an install_if?
2019-06-26 21:33:21 <PureTryOut[m]> No, hwids-pci is listed as a runtime dependency of pciutils
2019-06-26 21:33:27 <PureTryOut[m]> They just both provide the same file
2019-06-26 21:35:01 <mps> just looking at them, I think pci.ids should be removed from hwadata
2019-06-26 21:39:57 <mps> pciutils have /usr/sbin/update-pciids which can update data
2019-06-26 21:41:15 <mps> while hwdata-pci have just data file
2019-06-26 21:43:06 <mps> ohm, looking more carefully looks like they are ok, file /usr/share/hwdata/pci.ids is only in hwdata-pci not in pciutils
2019-06-26 21:53:06 <clandmeter> pciutils(main) depends on something in testing?
2019-06-26 21:53:34 <mps> no, hwdata are in main
2019-06-26 21:54:31 <clandmeter> hwids-pci is in testing
2019-06-26 21:54:50 <PureTryOut[m]> mps: nope, pciutils most definitely tries to provide pci.ids
2019-06-26 21:54:52 <PureTryOut[m]> run `apk add pciutils` and see for yourself
2019-06-26 21:55:48 <mps> I have it installed and didn't have seen that
2019-06-26 21:55:49 <PureTryOut[m]> hwdata-pci isn't though, which is the conflicting package
2019-06-26 21:56:40 <mps> I have both installed
2019-06-26 21:57:48 <PureTryOut[m]> Delete the packages and re-add them
2019-06-26 21:58:37 <mps> which, hwids?
2019-06-26 21:59:07 <PureTryOut[m]> Delete `pciutils` and `hwdata-pci`, and then install just `pciutils`. It'll pull in `hwdata-pci` and complain about the conflict
2019-06-26 22:01:11 <PureTryOut[m]> Also, `shadow` has a conflict with `openssl-doc`....
2019-06-26 22:01:18 <PureTryOut[m]> *`shadow-doc`
2019-06-26 22:01:20 <mps> http://tpaste.us/vbxQ
2019-06-26 22:01:33 <PureTryOut[m]> mps: are you on the edge repos?
2019-06-26 22:01:54 <mps> hmm, ah no
2019-06-26 22:02:00 <mps> will try now
2019-06-26 22:03:25 <mps> you are right. why it depends from pkg in testing
2019-06-26 22:06:01 <mps> maybe hwdata is outdated and could be replaced by hwids
2019-06-26 22:08:03 <PureTryOut[m]> https://git.alpinelinux.org/aports/tree/testing/hwids/APKBUILD#n47
2019-06-26 22:08:19 <mps> hmm hwids even have replaces="hwdata-pci"
2019-06-26 22:09:00 <mps> yes, we are looking same line
2019-06-26 22:09:32 <mps> iirc, ncopa talked about moving hwids to main
2019-06-26 22:10:54 <PureTryOut[m]> Seems to be a replacement of hwdata, so it makes sense
2019-06-26 22:10:59 <PureTryOut[m]> Let's wait for his answer
2019-06-26 22:20:47 <PureTryOut[m]> So since we're slowly getting rid of python2 anyway, is it an idea to make `/usr/bin/python` link to python3 rather than python2?
2019-06-26 22:24:03 <danieli> I'd wait until we've removed py2
2019-06-26 22:26:52 <PureTryOut[m]> Entirely?
2019-06-26 22:30:16 <danieli> well.. close to it?
2019-06-26 22:42:55 <PureTryOut[m]> Hmm ok
2019-06-26 22:50:27 <terror> Hi, I tried to package an application today and run into this error: Packages must not put anything under /srv, /usr/local or /opt
2019-06-26 22:51:19 <terror> Where should I drop my binary then?
2019-06-26 22:51:41 <SpaceToast> ... /usr/bin?
2019-06-26 22:51:45 <PureTryOut[m]> `/usr/bin` probably
2019-06-26 22:51:56 <danieli>  yup
2019-06-26 22:52:20 <PureTryOut[m]> You can probably just use `DESTDIR="$pkgdir" make install`
2019-06-26 23:00:31 <terror> I did that ^
2019-06-26 23:00:52 <terror> OK, let me try /usr/bin
2019-06-26 23:02:21 <PureTryOut[m]> If it's a Cmake using application, you can set `CMAKE_INSTALL_PREFIX=/usr`. In case of qmake it's `PREFIX=/usr`, and with configure it's `--prefix=/usr`
2019-06-26 23:22:14 <terror> This is just a VERY basic Makefile
2019-06-26 23:23:01 <terror> make install does: install -D bin/$(BIN_NAME) $(DESTDIR)/usr/local/bin/$(BIN_NAME)
2019-06-26 23:39:03 <terror> I guess I can just override that with a simple cp bin/binary $pkgdir/bin/binary and be done with it right?
2019-06-26 23:43:36 <mps> you can patch makefile to do proper install
2019-06-26 23:48:33 <p4Wv1qn095FW> what PureTryOut[m] said: > You can probably just use `DESTDIR="$pkgdir" make install`
2019-06-26 23:49:01 <p4Wv1qn095FW> and remove the local from the path
2019-06-26 23:49:46 <p4Wv1qn095FW> actually that is stupid, the path should be $(DESTDIR)/bin/$(BIN_NAME) - the part `/usr/local/` should not be specified explicitly
2019-06-26 23:51:36 <mps> it depends what is in upstream makefile. if it 'normal' then yes
2019-06-26 23:54:28 <p4Wv1qn095FW> according to terror: >  install -D bin/$(BIN_NAME) $(DESTDIR)/usr/local/bin/$(BIN_NAME)
2019-06-26 23:55:55 <mps> yes, this doesn't look good
2019-06-27 00:22:19 <jnt> I am trying to create a new package for qbittorrent that also builds the GUI version, should there be separate -doc packages for the gui and headless versions? they ship two different manpages, depending on which version you build.
2019-06-27 00:29:09 <danieli> I'd keep both the manpages in one -doc package
2019-06-27 00:29:49 <jnt> okay, thanks.
2019-06-27 05:18:20 <_ikke_> maxice8: parole fails to build on 32-bits systems due to missing webkit2gtk
2019-06-27 05:19:20 <danieli> morning _ikke_
2019-06-27 05:53:09 <ncopa> morning
2019-06-27 05:53:52 <ncopa> `install -D bin/$(BIN_NAME) $(DESTDIR)/usr/local/bin/$(BIN_NAME)` should be: `install -D bin/$(BIN_NAME) $(DESTDIR)$(prefix)/$(BIN_NAME)`
2019-06-27 05:54:18 <ncopa> and: `prefix ?= /usr`
2019-06-27 09:23:41 <mps> ncopa: I posted two patches at pw.a.o for haproxy upgrade. https://patchwork.alpinelinux.org/patch/4946/ for edge and https://patchwork.alpinelinux.org/patch/4947/ for 3.10-stable
2019-06-27 09:24:35 <mps> bug fixes mostly. After sent it I thought maybe one patch would be enough
2019-06-27 09:35:11 <mps> PureTryOut[m]: mesa 19.1.1 bugfix released
2019-06-27 09:38:22 <PureTryOut[m]> Awesome!
2019-06-27 09:40:26 <PureTryOut[m]> Rebased my branch and force pushed to trigger a CI rebuild
2019-06-27 09:40:38 <PureTryOut[m]> *of my Mesa Lima and Panfrost branch
2019-06-27 09:44:03 <mps> I'm really surprised how I'm sometimes good at predictions ;)
2019-06-27 11:10:46 <Cogitri> mps: Heh
2019-06-27 11:24:41 <PureTryOut[m]> mps: pr9153
2019-06-27 11:26:32 <mps> PureTryOut[m]: this is just bump of pkgver or I'm blind
2019-06-27 11:27:40 <PureTryOut[m]> No that's correct. Lima and Panfrost is in a separate PR
2019-06-27 11:28:01 <mps> to me this GH is really not *intuitive*
2019-06-27 11:28:01 <PureTryOut[m]> pr8764, which I made earlier
2019-06-27 11:28:19 <mps> you should combine all them in one
2019-06-27 11:28:51 <mps> no need to ask someone to push three commits
2019-06-27 11:28:55 <PureTryOut[m]> Why...?
2019-06-27 11:29:30 <mps> why not?
2019-06-27 11:29:47 <PureTryOut[m]> Because I already had it in a separate PR
2019-06-27 11:30:08 <PureTryOut[m]> What's wrong with having it in a separate PR? Makes sense to me really
2019-06-27 11:30:19 <mps> and it is impossible to merge them in one?
2019-06-27 11:30:50 <tmhoang> I was told that it is okay to have multiple commits (if they needed to be) in 1 single PR
2019-06-27 11:31:01 <mps> we have to ask someone to push it in main
2019-06-27 11:31:35 <mps> imo, it is then better to have one commit
2019-06-27 11:32:37 <mps> that 'someone' who have to push it will have less work, and we have to be nice with these people ;)
2019-06-27 11:32:46 <tmhoang> I have no opinion in this, both are fine to me. _ikke_ told me it was better for committers if the number of PR stays low
2019-06-27 11:34:06 <mps> tmhoang: right, when I have to push something I have some aversion to commit with unneeded multiple PR/patches
2019-06-27 11:35:15 <mps> in this case I cannot push because I have no access to main, so for me it is irrelevant, but trying to explain my experience
2019-06-27 11:35:55 <tmhoang> o/
2019-06-27 11:39:07 <PureTryOut[m]> I'm not sure what you can have against multiple PR's...
2019-06-27 11:39:22 <PureTryOut[m]> Less work? It's only like 2 commands lol
2019-06-27 11:43:07 <mps> I will now work less ;)
2019-06-27 12:57:15 <mps> postgresql 11.4 is released with security and bug fixes, and some previous versions also
2019-06-27 14:13:39 <ncopa> mps: merged the haproxy. thanks!
2019-06-27 14:15:26 <ncopa> if PRs are related to each other and/or depend on each other, its more convenient to have them in a single PR.
2019-06-27 14:16:32 <ncopa> if one of the commits may be rejected for whatever reason or is questionable, and the other commit is unrelated, then it may make sense to separate them
2019-06-27 14:16:46 <ncopa> specially if one is in more hurry than the other
2019-06-27 14:16:52 <ncopa> security fixes for example
2019-06-27 14:17:12 <ncopa> so security fix is not delayed by some other unrelated changes in same PR
2019-06-27 14:18:48 <PureTryOut[m]> still, the other PR already existed. I don't really want to close it just to move commits to some other PR
2019-06-27 14:20:53 <ncopa> now you have to wait til mesa 19.1.1 is built and uploaded and mirrors synced and then you'll have to rebase the lima and panfrost PR so CI rebuilds it
2019-06-27 14:22:49 <PureTryOut[m]> I understand, I don't find that a problem lol
2019-06-27 15:27:30 <PureTryOut[m]> pr8764 now succeeded and is ready for merging
2019-06-27 15:27:54 <PureTryOut[m]> Well, it succeeded Drone. Travis is too slow for me to care lol
2019-06-27 15:45:18 <M0x32_t[m]11> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/v1/download/matrix.org/QsBjWSCoYeQwbMfVFJvomHka >

2019-06-27 15:45:34 <M0x32_t[m]11> s/glibc/gcc
2019-06-27 15:47:26 <M0x32_t[m]11> Can I use clang with llvm linker by default? Why is that gcc providing these libs where they are part of compiler-crt in BSDs?
2019-06-27 16:10:05 <M0x32_t[m]11> Please look into this matter: http://0x0.st/z2kY.txt
2019-06-27 16:11:00 <M0x32_t[m]11> Sorry: http://0x0.st/z2k6.txt
2019-06-27 16:11:23 <M0x32_t[m]11> It requires me to install gcc on top of using clang
2019-06-27 16:11:33 <M0x32_t[m]11> I am failed to undersand why?
2019-06-27 16:14:07 <M0x32_t[m]11> I am failing to undersand why?
2019-06-27 18:09:56 <wener> @ncopa If I upgrade a package maintained by you, should I change the maintainer ?
2019-06-27 18:10:45 <_ikke_> wener: not per definition
2019-06-27 18:11:28 <_ikke_> wener: but because ncopa maintains a lot of packages, he probably be happy to transfer some packages to someone who wants to maintain them
2019-06-27 18:11:45 <wener> @_ikke_ If I want to move a package to community and upgrade, should I make tow pr or one ?
2019-06-27 18:11:59 <_ikke_> wener: one PR should be fine
2019-06-27 18:12:08 <_ikke_> It can have multiple commits
2019-06-27 18:13:30 <wener> But I remember the pr only accept one commit, need to squash.
2019-06-27 18:14:31 <_ikke_> Nope, that's not the case
2019-06-27 18:14:45 <_ikke_> It can have as much commits as you like
2019-06-27 18:14:49 <wener> And one more question, the tinc-pre is under community, but no in 3.10 repository ? https://pkgs.alpinelinux.org/packages?name=tinc-pre&branch=v3.10
2019-06-27 18:15:26 <_ikke_> (but the commits *do* need to make sense, if it's just a simple fix of a previous commit, *then* we want you to squash it
2019-06-27 18:17:11 <wener> 👌
2019-06-27 19:50:59 <PureTryOut[m]> mps: pr8764 can be merged. For some reason Github still thinks CI is running, but both Drone and Travis succeeded
2019-06-27 19:57:03 <iggy> What triggers a rebuild of the alpine:edge docker container? It looks like it's getting a little aged (it's from 20190508)
2019-06-27 19:57:37 <maxice8> I had to start rebuilding it myself periodically, people using the current one from docker will hit a failure to update on apk-tools (at least that is waht i hit)
2019-06-27 20:02:59 <mps> PureTryOut[m]: good, now we have to please someone to push them
2019-06-27 20:03:21 <_ikke_> iggy: ncopa needs to do edge snapshots
2019-06-27 20:05:32 <mps> PureTryOut[m]: I can tell that I successfully build both (lima and panfrost) for 19.1.0 version and tested panfrost a little
2019-06-27 20:07:29 <PureTryOut[m]> At postmarketOS we use Lima for the PinePhone devkit already on 19.1.0
2019-06-27 20:07:47 <PureTryOut[m]> Still early days clearly, but it's getting there
2019-06-27 20:10:27 <mps> very nice to hear, hope soon we will have 'first class' video on arm's
2019-06-27 20:10:41 <mps> which kernel you test, btw
2019-06-27 20:11:03 <PureTryOut[m]> Not an Alpine one 😛
2019-06-27 20:11:09 <PureTryOut[m]> Hold on I'll link it
2019-06-27 20:11:19 <mps> yes, I know
2019-06-27 20:11:32 <PureTryOut[m]> https://gitlab.com/postmarketOS/pmaports/blob/master/main/linux-postmarketos-allwinner/APKBUILD
2019-06-27 20:11:45 <mps> Alpine kernels doesn't have support for these drivers yet
2019-06-27 20:11:45 <PureTryOut[m]> It's a tree from Pine64
2019-06-27 20:12:32 <mps> I'm testing with 5.2-rc6
2019-06-27 20:13:28 <mps> (and for gitlab I have to allow JS :( )
2019-06-27 20:14:04 <mps> your kernel is outdated, I have to note ;)
2019-06-27 20:15:41 <PureTryOut[m]> I know
2019-06-27 20:15:41 <PureTryOut[m]> Patches have to be rebased
2019-06-27 20:16:00 <PureTryOut[m]> mps: for Alpine we need the next LTS kernel probably
2019-06-27 20:17:06 <mps> yes, we hope that the 5.2 will be next LTS
2019-06-27 20:18:31 <mps> it will have 'full' support for MALI and full support for iwd
2019-06-27 20:20:16 <PureTryOut[m]> Yeah
2019-06-27 20:23:31 <maxice8> Anyone up for testing Vulkan on MPV please take a look at pr9162
2019-06-27 20:26:41 <PureTryOut[m]> Oh, I can tomorrow
2019-06-27 20:26:49 <maxice8> Also GitHub is being special
2019-06-27 20:27:11 <PureTryOut[m]> That is a quick move to community for Vulkanl ol
2019-06-27 20:27:12 <_ikke_> quite a eufenism I guess
2019-06-27 20:27:16 <PureTryOut[m]> *Vulkan lol
2019-06-27 20:27:22 <maxice8> It is required for mpv
2019-06-27 20:27:32 <maxice8> _ikke_: It merged my PR for fixes for license and url in packages in main/
2019-06-27 20:27:38 <maxice8> although i have no permissions to do that
2019-06-27 20:27:56 <_ikke_> PureTryOut[m]: There is no time requirement for testing, just a reasonable confirmation that the package is not utterly broken and meets basic requirements
2019-06-27 20:28:19 <maxice8> Well i watched one episode of Initial D with vulkan on Intel
2019-06-27 20:28:26 <_ikke_> maxice8: right, on github we have no way to restrict path access
2019-06-27 20:28:30 <_ikke_> but algitbot should revert that again
2019-06-27 20:29:00 <PureTryOut[m]> _ikke_: I understand 😉
2019-06-27 20:29:14 <PureTryOut[m]> I want to move KDE Frameworks to community once 5.60 hits
2019-06-27 20:29:23 <maxice8> _ikke_: Just saw that ncopa did
2019-06-27 20:29:25 <_ikke_> alright
2019-06-27 20:29:25 <maxice8> worried for nothing shrug
2019-06-27 20:30:51 <PureTryOut[m]> Github never automatically merges stuff without user intervention lol
2019-06-27 20:30:53 <maxice8> PureTryOut: I know that but i was merging all my branches at the same time it was merged
2019-06-27 20:31:06 <PureTryOut[m]> Could someone merge/take a look at pr8736?
2019-06-27 21:00:00 <mps> anyone can tell me how to add source from bitbucket.org to APKBUILD
2019-06-27 21:07:32 <shizonic> mps: add ?
2019-06-27 21:08:19 <terror> Hi team, what's the criteria for including a package?
2019-06-27 21:08:59 <terror> I've created a "scratch your own itch" application that I use all the time and could easily package it to have it one apk add away
2019-06-27 21:09:14 <terror> Not sure if anyone else would need it though
2019-06-27 21:10:20 <mps> shizonic: 'source' field in APKBUILD. need to download package from bitbucket but can't see tarball or zip or anything like release
2019-06-27 21:11:29 <shizonic> guess best is to ask upstream for a release
2019-06-27 21:12:27 <shizonic> otherwise you should be able to append *.tar.gz to the brancht/commit hash in the url
2019-06-27 21:12:31 <mps> eh, found zip with hash in name. will try now
2019-06-27 21:14:16 <shizonic> mps: https://stackoverflow.com/questions/14528344/how-to-access-full-source-of-old-commit-in-bitbucket/16930983#16930983
2019-06-27 21:15:26 <shizonic> mps: "https://stackoverflow.com/questions/14528344/how-to-access-full-source-of-old-commit-in-bitbucket/16930983#16930983"
2019-06-27 21:15:37 <mps> shizonic: thanks, will note it
2019-06-27 21:16:43 <shizonic> np
2019-06-28 02:20:20 <Shiz> PureTryOut[m]: see update on dolphin bugtracker :)
2019-06-28 02:21:24 <PureTryOut[m]> Shiz: dolphin-emu you mean?
2019-06-28 02:21:31 <Shiz> yes
2019-06-28 02:28:11 <PureTryOut[m]> Sorry, I'm a bit drunk atm, will look tomorrow xD
2019-06-28 04:57:13 <tmhoang1> ncopa: the kernel 4.14.131 release with 1 commit might be related to TCP SACK panic vuls
2019-06-28 06:27:58 <mps> tmhoang1: very probably because this is one line change related to sendbuff worth new release and kernel upgrade
2019-06-28 10:32:16 <tmhoang> If I mount a sysroot at /mnt, and I want to # chroot /mnt /bin/sh . But the shell of the sysroot is at a custom location like /usr/lib/sh for example. How do I change root ? I tried # chroot /mnt /usr/lib/sh but didnt work
2019-06-28 10:45:05 <Cogitri> Hm, is that shell in /mnt/etc/shells (I think that's the file, not quite sure)
2019-06-28 11:17:32 <MY_R> order of columns on mirror.a.o little suck now :D "v3.1  v3.10  v3.2"
2019-06-28 11:18:03 <MY_R> s/mirror.a.o/mirrors.a.o
2019-06-28 11:18:03 <alpine-meetbot> MY_R meant to say: order of columns on mirrors.a.o little suck now :D "v3.1  v3.10  v3.2"
2019-06-28 11:19:54 <danieli> lol
2019-06-28 11:21:59 <ncopa> tmhoang: i think you do: chroot /mnt /usr/lib/sh
2019-06-28 11:29:00 <tmhoang> yeah it doesnt work
2019-06-28 11:42:42 <tmhoang> ive must have screwed up somewhere ellse
2019-06-28 11:43:49 <jwh> yeah thats enough for a shell, missing libs or omething?
2019-06-28 11:45:31 <Cogitri> Or maybe something else preventing it to run on your system? Does `/mnt/usr/lib/sh` work?
2019-06-28 11:49:44 <tmhoang> must be missing lib, libs not found
2019-06-28 12:05:32 <Cogitri> <Cogitri "Or maybe something else preventi"> You did set LD_LIBRARY_PATH if you followed that, right?
2019-06-28 12:15:31 <Cogitri> mps: Could you try pr9134 on armv7? It throws `SIGBUS: invalid memory address` on aarch64 and I'm not sure if that also affects other arches
2019-06-28 12:16:51 <mps> Cogitri: in a hour or two, right now I'm working on sec fixes for one of our pkg's
2019-06-28 12:20:02 <Cogitri> Alright, I'm out now anyway
2019-06-28 13:18:40 <mps> ncopa: again, sorry, secfix patches for postgresq: https://patchwork.alpinelinux.org/patch/4948/ for edge and https://patchwork.alpinelinux.org/patch/4949/ for 3.10-stable
2019-06-28 13:20:06 <mps> Cogitri: http://tpaste.us/KgJY on armv7
2019-06-28 13:45:49 <Cogitri> Ah, thanks for testing. Forgot to set an env variable, could you please set `RUSTFLAGS= -C target-feature=-crt-static`
2019-06-28 13:48:39 <mps> Cogitri: where, as ./configure parameter?
2019-06-28 13:49:53 <Cogitri> As env variable
2019-06-28 13:50:04 <Cogitri> Just export it in build()
2019-06-28 13:50:19 <mps> yes, I missed quotes in first try ;)
2019-06-28 13:50:47 <Cogitri> Oh hehe, that happened to me to
2019-06-28 13:50:49 <Cogitri> Thanks for testing :)
2019-06-28 13:50:57 <mps> it building, I'm going out :-Q
2019-06-28 14:08:03 <SpaceToast> Cogitri: I thought you said it shouldn't do anything on musl?
2019-06-28 14:11:03 <_ikke_> MY_R: lexicographical sort :-/
2019-06-28 14:11:47 <danieli> _ikke_: could probably extract the numbers and sort the table by them
2019-06-28 14:12:05 <MY_R> _ikke_, ye :P
2019-06-28 14:12:45 <MY_R> or next time Alpine version 4.01 :D
2019-06-28 14:14:51 <Cogitri> SpaceToast: We disable it in our triplets
2019-06-28 14:15:00 <Cogitri> But we first have to build against upstream triplets
2019-06-28 14:15:56 <SpaceToast> Aha
2019-06-28 14:23:54 <Cogitri> We first have to build our downstream triplets into Rust, then build for them
2019-06-28 14:24:04 <Cogitri> Because Upstream tarballs don't know our triplets
2019-06-28 14:44:17 <mps> Cogitri: here is result http://tpaste.us/jXZm with 'RUSTFLAGS="-C target-feature=-crt-static"'  line above './configure \'
2019-06-28 14:44:52 <mps> do I need to put explicit 'export'
2019-06-28 14:45:27 <mps> i.e. 'export RUSTFLAGS="-C target-feature=-crt-static"'
2019-06-28 15:38:18 <Cogitri> mps: Yup
2019-06-28 15:40:04 <mps> failed again with 'export RUSTFLAGS="-C target-feature=-crt-static"' http://tpaste.us/DLpd
2019-06-28 15:40:45 <mps> that is like somewhere I reached a week or two ago
2019-06-28 15:45:40 <Cogitri> Gonna make a patch once I'm home
2019-06-28 19:03:42 <mps> I noticed that last patch for postresql also should be applied to v3.9, there is postgresql version 11.3
2019-06-28 19:04:12 <mps> could be patch for v3.10 applied or we need new patch?
2019-06-28 19:40:52 <danieli> have anyone looked into why emacs fails on aarch64?
2019-06-28 19:47:20 <Shiz> PureTryOut[m]: responded
2019-06-28 19:51:07 <PureTryOut[m]> I know, I'm getting the emails 😉
2019-06-28 19:57:05 <danieli> that's odd, emacs built fine for me on aarch64, i guess i can enable it on aarch64 again
2019-06-28 20:01:30 <mps> danieli: on edge?
2019-06-28 20:01:38 <danieli> yes
2019-06-28 20:02:22 <danieli> i also wonder why it's not built with gtk3 (we only build gtk2)
2019-06-28 20:02:23 <mps> why it depends on subpackage emacs-nox? not question for you but in general
2019-06-28 20:02:32 <Shiz> PureTryOut[m]: ah okay, it didn't me any so figured I'd say so
2019-06-28 20:02:39 <danieli> probably because when people are looking for emacs, they often want emacs-nox
2019-06-28 20:02:41 <danieli> it's the non-gui one
2019-06-28 20:03:43 <mps> good, we should ask maintainer (Timo) before enabling it on aarch64
2019-06-28 20:04:34 <mps> I will also build it to check if it works
2019-06-28 20:05:03 <danieli> agreed, fabled does not seem to be here though
2019-06-28 20:05:09 <danieli> and i don't believe i've seen him for a while
2019-06-28 20:05:51 <mps> I exchanged few words with two weeks ago, iirc
2019-06-28 20:06:06 <mps> s/with/with him/
2019-06-28 20:06:06 <alpine-meetbot> mps meant to say: I exchanged few words with him two weeks ago, iirc
2019-06-28 20:07:21 <mps> yes, 2019-06-09
2019-06-28 20:07:24 <danieli> emacs works flawlessly
2019-06-28 20:07:29 <danieli> gonna test gtk in a sec
2019-06-28 20:09:38 <mps> hmm, it's built with gtk2 as I see on build
2019-06-28 20:11:01 <mps> danieli: would you look at commit eb89c00dbeb08e62cc56e1deb5d20862aa36d30e in aports
2019-06-28 20:11:13 <Cogitri> danieli: I'm somewhat confident that I saw them join one of the alpine related IRC channels yesterday or so
2019-06-28 20:11:15 <danieli> mps: i saw that commit
2019-06-28 20:11:18 <danieli> i did not encounter that issue
2019-06-28 20:11:25 <danieli> mps / Cogitri: good to know, thanks
2019-06-28 20:11:37 <p4Wv1qn095FW> danieli: because i hate gtk3 the scrollbars are so fucked up, but if you want you can add a gtk3 variant
2019-06-28 20:11:58 <danieli> rms himself doesn't use GUI at all :)
2019-06-28 20:12:17 <p4Wv1qn095FW> huh, i thought i was the maintainer for emacs
2019-06-28 20:12:20 <p4Wv1qn095FW> not timo
2019-06-28 20:12:24 <danieli> you are apparently not
2019-06-28 20:12:54 <p4Wv1qn095FW> indeed, i am the maintainer
2019-06-28 20:13:03 <p4Wv1qn095FW> timo is only contributor
2019-06-28 20:13:55 <danieli> oh, i think i must've misread
2019-06-28 20:13:57 <mps> p4Wv1qn095FW: ah, I see, fields are perturbed, usually maintainer is bottom
2019-06-28 20:14:24 <danieli> ^
2019-06-28 20:14:52 <p4Wv1qn095FW> so anyway, if you want a gtk3 variant, feel free to add it
2019-06-28 20:15:38 <mps> as you are maintainer you have to say what is best option, I'm for gtk2
2019-06-28 20:15:59 <p4Wv1qn095FW> i think gtk3 in general is a fuckup. for anything.
2019-06-28 20:16:05 <danieli> mps: it's not about changing it at all, just adding a variant
2019-06-28 20:16:25 <mps> and, tell me how to exit emacs, started it again firts time after 25 years
2019-06-28 20:16:36 <p4Wv1qn095FW> ctrl-x c
2019-06-28 20:17:08 <mps> ctrl-x ctrl-c maybe
2019-06-28 20:17:36 <p4Wv1qn095FW> ah, indeed
2019-06-28 20:17:45 <p4Wv1qn095FW> musclememory translates badly to irc sorry
2019-06-28 20:17:48 <mps> p4Wv1qn095FW: I share your feeling about gtk3 ;)
2019-06-28 20:18:12 <danieli> C-x C-c yes
2019-06-28 20:18:19 <mps> yes, can confirm it builds and works on aarch64
2019-06-28 20:18:23 <p4Wv1qn095FW> \o/
2019-06-28 20:19:01 <danieli> that's save buffers, kill emacs / die
2019-06-28 20:19:13 <mps> will you send patch to enable it or will I simply remove !aarch64 and push
2019-06-28 20:19:27 <p4Wv1qn095FW> please do so
2019-06-28 20:19:39 <mps> or someone else, it is not important who will
2019-06-28 20:20:58 <mps> ah, ok, I see
2019-06-28 20:21:14 <danieli> i can do it
2019-06-28 20:21:19 <danieli> i already have it ready
2019-06-28 20:21:20 <danieli> @ mps
2019-06-28 20:21:30 <PureTryOut[m]> Shiz: awesome, it compiles now! Thanks for your help!
2019-06-28 20:21:40 <Shiz> np
2019-06-28 20:21:48 <Shiz> these are changes that *should* be upstreamed, probabl
2019-06-28 20:21:50 <mps> danieli: sorry, pushed
2019-06-28 20:21:52 <danieli> it's okay :)
2019-06-28 20:22:07 <danieli> wait, you have push access to aports?
2019-06-28 20:22:17 <danieli> i think i missed that
2019-06-28 20:22:25 <PureTryOut[m]> Shiz: probably. Since you came up with them, and have a better idea of what is going on, could you make a PR for it?
2019-06-28 20:22:26 <p4Wv1qn095FW> thanks. good to have emacs also for aarch64.
2019-06-28 20:22:39 <danieli> yes, i have arm64 devices i want to run emacs on
2019-06-28 20:22:51 <danieli> without emacs, i am nothing
2019-06-28 20:23:09 <p4Wv1qn095FW> like me ;)
2019-06-28 20:23:25 <p4Wv1qn095FW> but i havent gotten around to put alpine on my arm devices
2019-06-28 20:23:56 <mps> I hope it will on mirrors soon
2019-06-28 20:24:18 <danieli> i built it on my aarch64 dev builder and rsynced it to my arm device
2019-06-28 20:24:20 <mps> s/will/will be/
2019-06-28 20:24:20 <alpine-meetbot> mps meant to say: I hope it will be on mirrors soon
2019-06-28 20:25:00 <mps> hmm, looks like evolution-data-server blocks builders
2019-06-28 20:25:58 <mps> but emacs is on aarch64 builder
2019-06-28 20:26:00 <mps> nice
2019-06-28 20:32:57 <mps> emacs on aarch64 is finished, in about 15 minutes it should be on mirrors
2019-06-28 20:33:25 <_ikke_> cool
2019-06-28 20:36:10 <mps> I noticed there are more package disabled on aarch64 and I doubt that all these are justified
2019-06-28 20:36:19 <danieli> or they're fixed upstream by now
2019-06-28 20:36:34 <danieli> i am currently working on elixir 1.9.0
2019-06-28 20:37:45 <mps> btw, anyone have seen my msg/question about postgresql secfix for v3.9
2019-06-28 20:38:13 <mps> to repeat it: I noticed that last patch for postresql also should be applied to v3.9, there is postgresql version 11.3
2019-06-28 20:38:49 <mps> could be patch for v3.10 applied or we need new patch?
2019-06-28 20:39:46 <_ikke_> checking
2019-06-28 20:41:33 <mps> _ikke_: if you missed it I posted patch for edge and v3.10 today and they are applied
2019-06-28 20:43:33 <_ikke_> hmm, so from 11.3 to 11.4?
2019-06-28 20:43:56 <mps> yes, cve fix
2019-06-28 20:46:00 <mps> simple pkgver bump and reset pkgrel
2019-06-28 20:46:32 <mps> and note about cve
2019-06-28 20:47:01 <_ikke_> yes
2019-06-28 20:48:39 <mps> here is the patch http://tpaste.us/7vy9
2019-06-28 20:49:35 <_ikke_> I'm just wondering if we should do the upgrade from 11.3 to 11.4 on 3.9
2019-06-28 20:50:19 <mps> I think so, v3.9 is supported for two years, afaik
2019-06-28 20:50:49 <danieli> worst case, we backport a specific fix for the CVE as a patch
2019-06-28 20:50:53 <mps> secfix and serious bugs should be applied or even backported
2019-06-28 20:50:53 <_ikke_> yes, mainly security updates
2019-06-28 20:51:36 <_ikke_> but ncopa did the same upgrade for 3.10, so I guess it should be okay
2019-06-28 20:53:49 <_ikke_> Just backporting secfixes does not always seem to be the best security practice
2019-06-28 20:54:26 <danieli> indeed, but it really depends on how broad the update is, and how much they had to change to fix the issue
2019-06-28 20:54:36 <_ikke_> indeed
2019-06-28 20:55:46 <danieli> sometimes it's a one-liner, other times it's a comprehensive refactor of major parts of the project
2019-06-28 21:07:19 <mps> in this case, it is already done for edge and v3.10 without problem, so I think it would not make problem on v3.9
2019-06-28 21:10:16 <Cogitri> mps: Could you try rust again?
2019-06-28 21:12:19 <Cogitri> Also, who was the one who happened to have a ppc64le VM? :)
2019-06-28 21:12:48 <danieli> wtf
2019-06-28 21:13:13 <danieli> i think it might be ci malfunction or something on pr9132
2019-06-28 21:13:24 <danieli> or another flaky test
2019-06-28 21:22:32 <danieli> nmeum: you don't happen to remember why elixir failed on aarch64?
2019-06-28 21:29:39 <mps> Cogitri: do you have patch/PR, I can try
2019-06-28 21:30:34 <Cogitri> pr9134
2019-06-28 21:30:59 <mps> ok, will do
2019-06-28 21:31:53 <mps> what would you prefer, armv7 or aarch64
2019-06-28 21:32:10 <Cogitri> armv7
2019-06-28 21:32:36 <Cogitri> I have an aarch64 container myself now, rustc explodes almost immediately on aarch64
2019-06-28 21:32:52 <Cogitri> So I guess we'll have to settle with armv7/armhf, ppc64le and x86 for now :)
2019-06-28 21:33:28 <mps> aha, ok
2019-06-28 21:34:48 <mps> you forgot checksum
2019-06-28 21:35:02 <mps> >>> ERROR: rust: rust-ppc64le-1.35.0.tar.xz is missing in checksums
2019-06-28 21:35:34 <mps> I did it local, just to remind you to do it for next patch update
2019-06-28 21:36:16 <Cogitri> Oh, oops
2019-06-28 21:36:20 <Cogitri> Confusing to work on 3 different machines at once :P
2019-06-28 21:36:21 <Cogitri> mps: Yup, thanks :)
2019-06-28 21:36:22 <Cogitri> Compiling for x86 now
2019-06-28 21:36:22 <mps> see you later, when it finish
2019-06-28 21:46:08 <nmeum> danieli: nope, sorry. should have used a more detailed commit message
2019-06-28 21:46:18 <danieli> yeah, it was a oneliner commit message
2019-06-28 21:46:21 <danieli> i suspect it is a flaky test
2019-06-29 00:28:01 <maxice8> Need testers for pr9169
2019-06-29 00:34:35 <Shiz> PureTryOut[m]: https://github.com/dolphin-emu/dolphin/pull/8220 https://github.com/dolphin-emu/dolphin/pull/8221
2019-06-29 02:15:07 <danieli> it feels like installing texmf is building the whole freaking thing on post-install
2019-06-29 02:22:45 <danieli> it's so bad
2019-06-29 02:25:50 <danieli> and somehow it's chewing up nearly 3G while installed size for texmf-dist shows as almost 500M
2019-06-29 02:26:04 <kaniini> welcome to tex :D
2019-06-29 02:26:20 <danieli> yeah, it's usually terrible, but it just stepped it up a notch
2019-06-29 07:50:04 <mps> Cogitri: good news: rust compiles on armv7. bad news: fails in check. overall: good progress
2019-06-29 08:02:36 <Cogitri> Yay!
2019-06-29 08:02:55 <Cogitri> Well, could you send me the log please? :)
2019-06-29 08:03:46 <mps> will do in few minutes, I'm out for short morning walk
2019-06-29 08:10:14 <mps> http://tpaste.us/pWdj
2019-06-29 08:11:51 <mps> line:1137 'Build completed successfully in 1:31:47'
2019-06-29 08:40:44 <PureTryOut[m]> Shiz: awesome! Just a few more fixes left!
2019-06-29 08:45:09 <Cogitri> mps: I guess I'll just disable tests for now, we build against different triplets anyway so I'm sure there's some minor breakage in the tests that will magically fix itself once we compile against our triplets
2019-06-29 08:45:11 <Cogitri> Could you try with armhf?
2019-06-29 08:47:55 <mps> Cogitri: my armhf is slow, 4GB RAM and FS is on microSD
2019-06-29 08:55:40 <Cogitri> Hm, alright
2019-06-29 10:03:27 <PureTryOut[m]> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/v1/download/matrix.org/FYlCTlAhttdyLcDWkLshzanK >

2019-06-29 10:03:35 <PureTryOut[m]> Uh, what? `vulkan-headers` is in the binary repos and in the same source tree...
2019-06-29 10:14:36 <Cogitri> Maybe the mirror hasn't catched up yet?
2019-06-29 10:15:16 <PureTryOut[m]> That would be one slow mirror then, this was the same yesterday
2019-06-29 10:15:49 <PureTryOut[m]> After running `dabuild -R` once, deleting all the packages it compiled (vulkan-headers wasn't in there!), and then running `dabuild -r`, it now finds it again? Wtf
2019-06-29 10:24:23 <wozencroft> @awilfox: Hi! Can I also install KDE on top of Alpine?
2019-06-29 10:25:02 <wozencroft> ops, sorry, wrong channel
2019-06-29 10:37:15 <PureTryOut[m]> wozencroft: you can though 😉
2019-06-29 10:37:22 <PureTryOut[m]> https://wiki.alpinelinux.org/wiki/KDE
2019-06-29 10:39:42 <wozencroft> PureTryOut[m] Ok, thank you. Just read that Adelie KDE apps won't be usable on Alpine because they use a different libstdc++ (to make i18n work).
2019-06-29 10:40:17 <PureTryOut[m]> Oh you probably can't just use their packages on Alpine no. But I have recently packaged KDE for Alpine, so you can just use the normal repos
2019-06-29 10:40:27 <PureTryOut[m]> Limited to the testing repo on edge atm though
2019-06-29 10:41:53 <wozencroft> I see, thank you for the hints
2019-06-29 13:24:23 <wener> Dose anyone know how to delay the mount sysroot ?
2019-06-29 13:24:24 <wener> https://stackoverflow.com/questions/56717767
2019-06-29 13:25:23 <wener> Should I modified something in the /usr/share/mkinitfs/initramfs-init ?
2019-06-29 14:31:19 <danieli> wener: your stackoverflow question got closed
2019-06-29 14:31:35 <danieli> also: #alpine-linux might be a better fit
2019-06-29 14:31:37 <_ikke_> yes, it's not really ontopic for stackoverflow
2019-06-29 14:31:49 <wener> @danieli I solved this, this is related to alpine only
2019-06-29 14:32:20 <wener> please add some loop to detect the mount device https://github.com/alpinelinux/mkinitfs/blob/master/initramfs-init.in#L487
2019-06-29 14:32:54 <wener> this may occur when using alpine as main os and installed in a usb
2019-06-29 14:34:09 <wener> Like rootwait https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/kernel-parameters.txt#L4172
2019-06-29 14:34:21 <wener> devices that are detected asynchronously (e.g. USB and MMC devices).
2019-06-29 14:35:50 <_ikke_> alpine is run from usb drives quite often
2019-06-29 14:36:07 <_ikke_> so I don't think this is a generic issue with booting from usb
2019-06-29 14:36:45 <wener> @_ikke_ yes, ok for pc, but not for server
2019-06-29 14:37:03 <_ikke_> even for servers
2019-06-29 14:37:36 <wener> I use alpine for all our servers. fine with dell, but we got several huawei server, always run in to this problem, no matter 1U or 2U server
2019-06-29 14:37:48 <_ikke_> but feel free to open an issue at bugs.a.o
2019-06-29 18:24:13 <PureTryOut[m]> maxice8: I see you disabled armv7 for libkscreen recently https://git.alpinelinux.org/aports/commit/testing/libkscreen?id=f465e34bc876e39550bda3aee77cb48ecbd09078
2019-06-29 18:24:19 <PureTryOut[m]> Next time, could you me notify for such a thing?
2019-06-29 18:24:29 <PureTryOut[m]> I missed this, and we need likbscreen on armv7 for devices like the Nexus 5
2019-06-29 18:28:24 <PureTryOut[m]> Also, do you have an error log?
2019-06-29 18:31:00 <PureTryOut[m]> It compiles fine for me on armv7
2019-06-29 18:33:40 <PureTryOut[m]> It's even available in the binary repos, how did it fail for you ever if even the Alpine builders can compile it fine>
2019-06-29 18:35:08 <mps> PureTryOut[m]: I will check it on lxc armv7 to see if there are issues
2019-06-29 18:36:23 <PureTryOut[m]> There are none lol. Alpine builders build it fine, CI builds it fine, I built it locally (cross-compiling though) and it went fine
2019-06-29 18:36:33 <PureTryOut[m]> Why would something get disabled if it's already available in the repos?
2019-06-29 18:37:08 <mps> let me check first
2019-06-29 18:40:24 <mps> PureTryOut[m]: you are right, it is ok
2019-06-29 18:41:40 <mps> do you have a patch or should I just enable it?
2019-06-29 18:43:13 <mps> you already make it I see (aports-ghpr is useful tool)
2019-06-29 18:45:09 <PureTryOut[m]> Yeah already made the PR, it can just be re-enabled
2019-06-29 18:45:15 <PureTryOut[m]> I really want to know why it was disabed lol
2019-06-29 18:45:18 <PureTryOut[m]> *disabled
2019-06-29 18:47:13 <mps> I don't know why it is disabled, doesn't have any comment in commit msg. ok, time to test _ikke_'s script with PR
2019-06-29 18:48:02 <mps> PureTryOut[m]: pushed
2019-06-29 18:48:12 <PureTryOut[m]> Thanks
2019-06-29 18:48:29 <maxice8> A  moment faster
2019-06-29 18:48:52 <maxice8> https://i.imgur.com/SIU2mQt.png
2019-06-29 18:49:41 <PureTryOut[m]> maxice8: why did you disable it?
2019-06-29 18:51:56 <maxice8> don't remember now
2019-06-29 18:52:21 <PureTryOut[m]> It's really strange as it was already in the repos when you disabled it
2019-06-29 19:27:03 <_ikke_> That's why you should add such details in the commit message (imho)
2019-06-29 19:34:00 <mps> _ikke_: agree, short note for such things are useful for everyone who want to fix issues later
2019-06-30 11:04:21 <mps> nice synday here :) managed to build firefox-esr for aarch64 on v3.10 and testing it now
2019-06-30 11:26:32 <Cogitri> Oh, doesn't that need Rust on aarch64? :o
2019-06-30 11:26:41 <Cogitri> Or did you get that running?
2019-06-30 11:29:58 <mps> Cogitri: yes, I took rust tarballs from adelie linux and put it under /usr/local
2019-06-30 11:30:23 <mps> 'them' instead of 'it'
2019-06-30 11:30:27 <Cogitri> Oh, alright
2019-06-30 11:31:02 <mps> then hacked firefox-esr APKBUILD little and fixed one patch in repo
2019-06-30 11:31:15 <mps> that was all, not much work
2019-06-30 11:32:17 <mps> this time I will write notes what I did, and not as I done previously and forgot most of thing I did ;)
2019-06-30 19:23:03 <ddevault> py3-beautifulsoup4 in 3.10 community needs to be rebuilt for python 3.7
2019-06-30 19:24:16 <ddevault> err, no it doesn
2019-06-30 19:24:19 <ddevault> 't
2019-06-30 19:55:17 <jwh> second that motion
2019-06-30 23:04:25 <Cogitri> mps: Could you give pr9218 a shot on armv7?
2019-06-30 23:42:13 <ddevault> how would we feel about making linux-virt non-modular
2019-06-30 23:42:49 <ddevault> or at least making many of the options configured as modules now baked in
2019-06-30 23:44:29 <ddevault> actually as I read through this config, it makes sense for a majority of these to be modules
2019-06-30 23:44:31 <ddevault> nevermind
2019-06-30 23:44:47 <ddevault> let's see how many more times I can suggest something and withdraw it moments later before the night's out
2019-06-30 23:44:56 <jwh> lol
2019-06-30 23:45:48 <ddevault> fat kernels really bug me
2019-06-30 23:45:55 <ddevault> I don't use 90%+ of my kernel
2019-06-30 23:59:36 <v> I'm guessing at least 16 more times. Give or take about 3