<    April 2017    >
Su Mo Tu We Th Fr Sa  
 2  3  4  5  6  7  8  
 9 10 11 12 13 14 15  
16 17 18 19 20 21 22  
23 24 25 26 27 28 _2_9  
00:01 <Shiz> whats the difference between category and type?
00:04 <jirutka> Shiz: category is something like type of aport, currently based on language: lua, ruby, python, c, …
00:04 <Shiz> weird
00:04 <jirutka> Shiz: type is type of the changed: adding new aport, upgrading aport, …
00:04 <jirutka> Shiz: maybe it’d be better to rename type to action, not sure
00:05 <Shiz> seems better
00:05 <Shiz> i'd reuse category for main/testing/community personally
00:05 <Shiz> the language seems soemwhat... irrelevant
00:05 <jirutka> it’s not irrelevant for reviewers
00:06 <jirutka> we have ppl with higher experience wirth some langs/platforms and ppl with averse towards some langs/platforms
00:08 <jirutka> this can be used even to auto-suggest reviewer in future; currently we do this manually, for example when I see some Go stuff, I just cc ^7heo
00:08 <jirutka> for php I usually cc Andy
00:09 <jirutka> for haskell mitchty
00:09 <jirutka> and so on
00:10 <^7heo> funny thing is I actually dislike Go
00:10 <^7heo> :p
00:10 <jirutka> about repositories, currently it’s not important if it’s main or community, but it’s quite important if it’s main/community or testing
00:11 <jirutka> ^7heo: well, but you are/were willing to deal with this sort of crap :) it’s kinda sacrifice :) I dislike Java stuff, but have a lot of experience with it, so I deal with java aports
00:13 <^7heo> yeah
00:13 <jirutka> Shiz: basically all C, R and most of T tags will be autoassigned by a bot
00:13 <^7heo> I take go over java any day
00:14 <jirutka> Shiz: hmm, that’s another indication that T-security is probably in wrong category, b/c I don’t know how to auto-detect that :/
00:15 <jirutka> ^7heo: well, I prefer even Java to Go…
00:15 <Shiz> :p
00:15 <jirutka> ^7heo: I see probaly only one lang+ecosystem+culture worse than Go, PHP :P
00:15 <^7heo> jirutka: I guess that's what we got our auyo-assignments from
00:16 <^7heo> jirutka: man, no, c++ is MUCH worse than go
00:17 <^7heo> at least go has problems that can be solved in a relatively ok time
00:17 <Shiz> jirutka: responded to changes for opensmtpd bump :)
00:17 <jirutka> ^7heo: well, that’s true, but build system and packaging is quite mature in C++… it’s insane and bad, but when I need to package some C++ project, I’m usually able to deal with that
00:17 <^7heo> yes
00:17 <^7heo> with horrible tools
00:17 <^7heo> go is actually in its infancy
00:18 <^7heo> and ahead of natural selection
00:18 <^7heo> so people are just being stupid with it
00:18 <^7heo> and the less bad designs will prevail over time
00:18 <jirutka> Shiz: I assume that you’ve verified that the init script really works properly?
00:18 <Shiz> yep
00:18 <jirutka> okay
00:19 <^7heo> for example, small programs in go are actually ok
00:19 <jirutka> ^7heo: yeah, just have 5 MiB instead of few kiB in C, but… XD
00:19 <^7heo> long story short, go just tries to be accessible; but one cannot make up for experience in good practices with a simple toolchain
00:20 <jirutka> ^7heo: wait for my toolchain for building static binaries for Lua scripts :P
00:20 <^7heo> jirutka: I'm quite ok with that if it works well
00:21 <^7heo> the problem isn't the size
00:21 <jirutka> I need to go sleep
00:21 <^7heo> the problem is that it *doesn't* work well
00:21 <jirutka> not just to avoid discussion about go…
00:21 <^7heo> same
00:21 <^7heo> :p
00:21 <jirutka> it’s quite late already
00:21 <^7heo> yeh
00:21 <^7heo> also, LUA <3
00:22 <jirutka> Shiz: so you think that Action would be better name than Type…?
00:22 <Shiz> yeah
00:22 <Shiz> jirutka: https://github.com/alpinelinux/aports/pull/1206#discussion_r109801674
00:22 <Shiz> what do you mean here?
00:22 <Shiz> specifically the install_if line?
00:23 <jirutka> 1st install_if is usually used with two items
00:24 <jirutka> 2nd I don’t understand what it should do; install subpkg when pkg opensmtpd-extras is installed?
00:24 <Shiz> yep
00:24 <jirutka> why?
00:25 <Shiz> because someone might want to just install all extras in the repo?
00:25 <jirutka> hm, then you can just add all subpkgs to origin pkg depends
00:25 <jirutka> I’m not sure what is better
00:25 <Shiz> i'll just do that
00:26 <jirutka> depends is more transparent for users, e.g. you see the package dependencies on pkgs.a.o
00:26 <jirutka> install_if is currently kinda “hidden”
00:27 <jirutka> but the idea about installing all subpkgs when origin pkg is installed actually makes sense in this case
00:28 <Shiz> right
00:28 <jirutka> Shiz: gaa, you forgot to update checksum, the build fails
00:28 <Shiz> fug
00:28 <jirutka> Shiz: but why the hack it didn’t fail on Travis, there’s something wrong
00:28 <jirutka> Shiz: http://build.alpinelinux.org/buildlogs/build-edge-armhf/main/opensmtpd/opensmtpd-6.0.2p1-r0.log
00:30 <jirutka> I’ve fixed it now
00:30 <jirutka> I mean checksum
00:30 <jirutka> not sure what’s the problem with the script for travis that it haven’t failed
00:30 <jirutka> good night
00:31 <Shiz> oh
00:31 <Shiz> thanks for the review+fix :)
00:31 <Shiz> good night
00:58 blueness joined
01:33 s33se_ joined
02:12 gromero joined
02:12 minimalism joined
02:14 blueness joined
02:14 ostera joined
02:20 doppo joined
02:22 alacerda joined
02:26 scadu joined
02:32 <tmh1999> I am wondering if anyone having this bug : http://tpaste.us/YnYe. I tested on x86_64. gtkmm-2.24.4 or gtkmm-2.24.5 also suffers it.
02:32 <tmh1999> looks like /usr/lib/atkmm-1.6/proc/m4 should have been on the above line, assigned to GMMPROC_EXTRA_M4_DIR
02:33 <tmh1999> this also happens to tools/Makefile and gdk/gdkmm/Makefile
02:38 blueness joined
02:40 <tmh1999> looks like in configure, $PKG_CONFIG --variable=gmmprocm4dir pangomm-1.4 atkmm-1.6 returns into 2 separate line
02:41 <tmh1999> this only happens in alpine
02:41 <tmh1999> *my alpine
02:47 <tmh1999> I got it
02:55 ostera joined
03:06 <kaniini> tmh1999: pkgconf 1.3.4-r1 and 1.3.5-r0 have a workaround
03:07 <kaniini> tmh1999: basically somebody did something stupid with pkg-config because they did not understand that it was not intended behaviour
03:09 <tmh1999> kaniini : I just made a patch ...
03:09 <tmh1999> thanks :))
03:16 <tmh1999> kaniini : do you mind report upstream ?
03:16 <kaniini> tmh1999: i already fixed it in pkgconf
03:17 <tmh1999> Yeah I got your patch alright. I mean it looks like upstream screws this up
03:17 <tmh1999> so better report to them ? kaniini
03:18 <kaniini> it can go either way. this is more one of those cases imo where the bug became a feature
03:19 <tmh1999> I see. Thank you
03:22 ostera joined
03:23 <kaniini> but yes, in general, --variable was not meant to be used in that way (as gtkmm is the only package that breaks in that way ;))
03:44 ostera joined
04:11 ostera joined
04:38 ostera joined
05:32 ostera joined
05:58 <TemptorSent> Is there a particular reason the armhf sigs come up as untrusted when trying to fetch the repos using apk from a x86_64 host.
05:59 <TemptorSent> Once I installed the keys in the new root using --allow-untrusted, it works fine, but that's a bit disconcerting.
05:59 <TemptorSent> Are all the arch keys not signed by the alpine main keys for some reason?
06:00 ostera joined
06:00 <TemptorSent> I'm trying to finish up the kernel staging tool, but this appears to break cross-platform builds.
06:06 ostera joined
06:10 vakartel joined
06:19 ostera joined
06:26 ncopa joined
06:27 <TemptorSent> Also, how difficult would it be to allow "apk --arch armhf fetch linux-grsec" to work on x86_64 without setting up an entirely new root?
06:30 <TemptorSent> IOOW, can the apk database handle multiple archs or does it need a db-per-arch, along with downloading of keys and bootstrapping for each?
06:56 royger joined
07:08 <^7heo> moin ncopa
07:09 <TemptorSent> 'morning ^7heo, ncopa.
07:09 <^7heo> moin TemptorSent
07:10 <TemptorSent> I'm actually going to call it an early night.
07:11 <TemptorSent> I'm most of the way done with the kerneltool I'm working on, but have places to be tomorrow, so I can't burn too much midnight oil.
07:11 <^7heo> ok
07:11 <^7heo> take care then :p
07:12 <TemptorSent> Not gone yet, just not going to be at it long.
07:12 <^7heo> ah yeah
07:14 ostera joined
07:16 <TemptorSent> Anyway, you give the tool a staging dir, a (optionally preceeded by arch) kernel .apk/build dir/package name/version and a set of additional .apks/build dirs/package names containing modules/firmware/dtbs, and it dumps it all into a staging directory ready for installation or use by mkinitfs.
07:17 cyteen_ joined
07:18 <TemptorSent> mkinitfs is going to learn to handle staging it's own userspace files so the PITA in update kernel can go away.
07:18 <TemptorSent> Rather than silently fail.
07:27 ostera joined
07:37 <ncopa> morning
07:41 ostera1 joined
07:45 <^7heo> ncopa: any chance you get to peek at my patch soonish? :)
07:47 <ncopa> ^7heo: can you please ping me about that in an hour or so?
07:49 <^7heo> You got it.
07:54 ostera1 joined
08:04 tty` joined
08:07 ncopa joined
08:07 ncopa joined
08:08 ostera1 joined
08:22 ostera1 joined
08:35 ostera1 joined
08:41 stwa joined
08:49 ostera1 joined
09:02 ostera1 joined
09:07 <^7heo> ncopa: ping
09:10 <ncopa> ^7heo: hi
09:10 <ncopa> thanks
09:10 <ncopa> the url?
09:10 <^7heo> ncopa: you're welcome ;)
09:10 <^7heo> One sec'
09:10 <^7heo> Network is VERY slow over here.
09:11 <^7heo> https://github.com/alpinelinux/mkinitfs/pull/11
09:11 <^7heo> Here.
09:11 <^7heo> ncopa: ^
09:16 ostera1 joined
09:30 ostera1 joined
09:30 <ncopa> ^7heo: can you please elaborate the // XXX: unsafe memset, because of mutexes; according to skarnet
09:30 <^7heo> ncopa: in the code or here?
09:31 <ncopa> here
09:32 <^7heo> Ok. So if I remember correctly (if I don't it's likely that skarnet will read that - since we're highlighting him - and will correct me), the point is that mutexes are an opaque type, and shouldn't be initialized with null bytes.
09:34 <^7heo> but now that I read the code below, I can see that the mutexes are now initialized properly.
09:34 <^7heo> It most likely wasn't the case when I first wrote that comment.
09:34 <ncopa> thats why i asked about it
09:34 <^7heo> or I overlooked them for X reason.
09:34 <ncopa> maybe rebase and remove the comment?
09:34 <^7heo> yes it is a valid question ;)
09:34 <^7heo> I can do it if you want.
09:35 <^7heo> I mean, it literally is a few seconds to me.
09:35 <^7heo> If you're already doing it, go ahead.
09:36 <ncopa> im not
09:36 <^7heo> Ok so I'll push in a minute.
09:37 <^7heo> pushed.
09:40 <ncopa> thanks
09:40 <ncopa> https://github.com/alpinelinux/mkinitfs/pull/11/commits/8406659b1f518f5397c43b845771422fbf53adfe
09:40 <ncopa> i dont think we need that in separate commit
09:40 <ncopa> can you merge that with the first commit?
09:40 <^7heo> yes.
09:40 <ncopa> how you do it:
09:40 <ncopa> git rebase -i
09:40 <skarnet> I don't remember saying that, but it's true nonetheless (i.e. don't memset() opaque types)
09:40 <ncopa> move the commit up so its under the first
09:40 <^7heo> yeah and then squash
09:40 <^7heo> yeah I know
09:41 <^7heo> I use git a *lot*
09:41 <ncopa> fixup in this case
09:41 <ncopa> good :)
09:41 <^7heo> nah I wanna keep the commit.
09:41 <^7heo> s/commit/message/
09:42 <skarnet> an opaque type will have an init function or an opaque initializer, you should never need to memset() it
09:42 <skarnet> for a mutex: pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER;
09:42 <skarnet> and that's all you need
09:42 <^7heo> yeah, the code is actually calling a function.
09:42 <^7heo> which does exactly that I would say.
09:42 <skarnet> pthread_mutex_init(&m, &attr)
09:42 <skarnet> works too
09:42 <^7heo> that is what is called.
09:43 <^7heo> with NULL for &attr
09:43 <skarnet> yeah, that works
09:43 ostera1 joined
09:43 <^7heo> ncopa: by "first commit" you meant 86b3ddb right?
09:44 <ncopa> yes
09:44 <^7heo> doing it now.
09:44 <ncopa> i want to hide the fact that there was ever an (size_t)atoi() there
09:44 <ncopa> as if it was done correctly in the first commit
09:45 <^7heo> I see. ;)
09:45 <^7heo> Makes sense.
09:45 <^7heo> I have a diff conflict, I'll solve it and push.
09:46 <^7heo> (because we changed the expression for the conf.crypt_payload_offset)
09:46 <ncopa> ah, ok
09:46 <ncopa> skarnet: thanks for you input wrt pthread_mutex
09:47 <skarnet> np, http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_init.html is where it's at ;)
09:57 ostera1 joined
09:58 <^7heo> ncopa: I'm actually wondering if we're doing the sscanf if right.
09:58 <^7heo> sscanf MUST return 1, not 1+
09:59 <^7heo> so we should throw an error if it returns ANYTHING else than 1, including 2.
09:59 <^7heo> what do you think?
09:59 <skarnet> sscanf is really, really hard to get right. I don't know what you're trying to do, but sscanf is dangerous to handle.
10:00 <^7heo> skarnet: if(sscanf(EARGF(usage(1)), "%zu", &conf.crypt.payload_offset) < 1) err(1, "sscanf") ;
10:00 <^7heo> skarnet: IMHO < should be ==
10:00 <^7heo> != sorry
10:00 <skarnet> ew, more 9p macros
10:00 <^7heo> yep
10:00 <^7heo> (not for the ew, I kinda like them)
10:01 <^7heo> (because I don't see why not; but feel free to explain :P)
10:01 <skarnet> because there's a posix API to do the exact same thing which is more portable and more readable?
10:02 <^7heo> skarnet: but isn't that POSIX API orders of magnitude bigger?
10:02 <^7heo> and more complex?
10:02 <^7heo> (I really don't know - I only assume that you can't get much more barebones than the 9p macros)
10:03 <skarnet> getopt() is likely a bit more complex than ARGBEGIN/ARGEND, yes
10:03 <skarnet> but that's because the magic is less hidden
10:03 <^7heo> My opinion is that the shorter the code I read, the less hidden it is.
10:04 <^7heo> but maybe that's not a widespread opinion.
10:04 <^7heo> of course, intentional obfuscation aside.
10:04 <skarnet> well, generally the shorter the better, yes, but ARGBEGIN/ARGEND make things shorter by magic.
10:05 <skarnet> you don't want that anywhere near things you care about.
10:05 <^7heo> What I don't get is how this is more magic than the POSIX api,
10:05 <^7heo> is it because it's unspecified?
10:05 <^7heo> s/un/not /
10:06 <skarnet> because that's a set of macros extending the C language: https://swtch.com/plan9port/man/man3/arg.html
10:07 <skarnet> getopt() is pure C, it doesn't need to hide constructs
10:07 <^7heo> Ah, I think I start to get what you mean.
10:07 <ncopa> i tend to agree with skarnet
10:08 <ncopa> i think this comes from some suckless project originally
10:08 <^7heo> it obviously does yes.
10:08 <skarnet> yes, and suckless loves 9p
10:08 <^7heo> yes they do.
10:08 <ncopa> i never bothered to clean that up
10:08 <ncopa> as it kinda works
10:08 <^7heo> yeah it works for me.
10:08 <^7heo> I won't complain.
10:09 <^7heo> I use that code in many software I use daily.
10:09 <skarnet> I can totally understand why they love 9p, but for a Unix OS I prefer using idiomatic constructs
10:09 <ncopa> ^7heo: have you tested if it actually works?
10:09 <^7heo> ncopa: the ARGBEGIN/ARGEND?
10:09 <^7heo> ncopa: it obviously does ;)
10:09 <ncopa> the detached header
10:09 <^7heo> ah
10:09 <^7heo> Well, there's a test for that.
10:09 <^7heo> in the ./test.sh
10:10 <ncopa> ok
10:10 <^7heo> and it passes, by grabbing the same dynamically-generated timestamp.
10:10 <ncopa> i'd say we just push it then?
10:10 <^7heo> yeah but give me one minute please.
10:10 <ncopa> ok
10:10 <^7heo> I am still pondering if I should replace < by !=
10:10 <^7heo> in `if(sscanf(EARGF(usage(1)), "%zu", &conf.crypt.payload_offset) < 1) err(1, "sscanf") ;`
10:11 ostera1 joined
10:11 <^7heo> I mean, in our case, sscanf MUST return 1.
10:11 <^7heo> must it not?
10:13 <ncopa> yeah, i think so
10:14 <^7heo> ok
10:14 <^7heo> So I'll push that.
10:14 <^7heo> One minute, reviewing before pushing one last time.
10:15 <^7heo> Note: the offset function is untested as of now, since I do not know how to test it properly.
10:15 <ncopa> fair enough
10:15 <^7heo> I will write a test for it as soon as I can; but I first need to experiment with the deported header.
10:15 <^7heo> To actually get hands on with it.
10:15 <ncopa> once we have pushed it, maybe you can test it in a vm
10:15 <^7heo> I actually have a machine I want to test it with.
10:16 <^7heo> So it's fine, I have enough machines to setup.
10:16 <^7heo> What I'm short on are power supplies ;)
10:16 <^7heo> Pushed one last time.
10:17 <^7heo> ncopa: as soon as this is in the repos
10:17 <^7heo> ncopa: I'll setup a machine with it
10:17 <^7heo> (and write some doc' on how to use the deported header with LUKS + ZFS)
10:18 <^7heo> next step for me is to have Alpine boot on the USB armory.
10:20 <^7heo> ncopa: I think we can push now.
10:24 ostera1 joined
10:29 <xsteadfastx> i want to build a package for snapcast. they only have a archive from github that doesnt include alot of submodule code. whats the best way to do it? should i get the archive or clone the repo and do a git submodule update in it? but whats with the checksums then? https://github.com/badaix/snapcast
10:31 <clandmeter> heh, i just looked into snapcast the other day.
10:32 <xsteadfastx> its a great piece of software... i use it with mopidy alot
10:32 <clandmeter> didnt we have issues with mopidy on alpine?
10:32 <xsteadfastx> ye
10:32 <xsteadfastx> s
10:32 <clandmeter> i remember it has been some time.
10:32 <xsteadfastx> i cant get python bindings for gstreamer up and running
10:33 <xsteadfastx> they compile fine but throw a error
10:33 <xsteadfastx> when mopidy imports the module
10:33 <clandmeter> i think i fixed it ones local, but its so long ago.
10:33 <xsteadfastx> thats why i use mopidy within a debian docker container... and for the snapcast client i want to use alpine soon :)
10:34 <clandmeter> i think we can fix mopidy
10:34 <xsteadfastx> really?
10:34 <xsteadfastx> that would be perfect
10:34 <clandmeter> if others can we can also :)
10:34 <xsteadfastx> there is some error about pbutils cant be imported
10:35 <clandmeter> whats this about snapcast?
10:35 <clandmeter> about submodules?
10:35 <xsteadfastx> i can pastebin my APKBUILD for py-gst1
10:35 <xsteadfastx> snapcast needs some submodules to compile...
10:36 <clandmeter> ah inside externals
10:36 <xsteadfastx> and i dont know if i should create for everyne a package or just use the submodule in the package creation process
10:37 <clandmeter> its links all those libs statically?
10:37 ostera1 joined
10:37 blueness joined
10:39 <xsteadfastx> for py-gst1: https://gist.github.com/xsteadfastx/1e4196b71c4f99d3815117dd3c3dbfa9
10:39 <xsteadfastx> building that... and installing mopidy with "pip install mopidy" and try to start it
10:40 <clandmeter> we dont have mopidy in aports?
10:41 <xsteadfastx> i dont know about the static linking. but i guess yes. some are libs for flac or ogg... but other things are libs i think he coded for snapcast itself
10:41 <xsteadfastx> clandmeter: not anymore
10:41 <xsteadfastx> i think its because gstreamer1 is needed
10:41 <xsteadfastx> and its python bindings
10:51 scadu joined
10:51 ostera1 joined
10:54 <jirutka> ncopa: clandmeter: fabled: what do you think about (a) removing php5 completely and keeping just php7 (before branching v3.6), or (b) updating all pkgs that depends on php to use only php7, if it’s supported, or only php5 if it’s not ? context: https://github.com/alpinelinux/aports/pull/1061#issuecomment-291824607
10:54 <^7heo> ncopa: can you pull the PR?
10:54 <^7heo> ncopa: so other PRs can be rebased on it
10:55 <^7heo> ncopa: also https://github.com/alpinelinux/mkinitfs/pull/8/files
11:00 <ncopa> jirutka: im in favor of getting rid of php5
11:00 <ncopa> are there any apps of significance that does not support php7?
11:00 <jirutka> ncopa: I don’t know, I’ve asked Andy and Valery about that, they will probably know
11:01 <^7heo> ncopa: we should have an "LTS" repo for such cases.
11:01 <ncopa> main = LTS
11:01 <^7heo> ncopa: or aren't them frequent enough to justify another repo?
11:01 <^7heo> ok LTS is the wrong term
11:01 <^7heo> deprecated
11:01 <^7heo> is what I meant.
11:02 <jirutka> main = 2 years support, community = 6 months support, testing = no support
11:02 <jirutka> we have enough repos now IMO
11:02 <^7heo> jirutka: I think it'd be fine with moving php5 to unmaintained
11:02 <ncopa> +1
11:02 <ncopa> https://docs.google.com/spreadsheets/d/10nGKgwym2j7rle85pHj72I_2hEQ_VpLCd2CVKLGL_BE/edit#gid=0
11:02 <^7heo> jirutka: *if* unmaintained was built
11:02 <ncopa> looks like we can drop php5
11:03 <jirutka> ncopa: these are only php-* pkgs, but not php apps like nextcloud, roundcube etc.
11:03 <^7heo> yeah
11:03 <ncopa> ok
11:03 <^7heo> just for the sake of carefulness
11:03 <^7heo> can't we have it stay in the repos but outside of main?
11:04 <^7heo> as I said, @deprecated would fit
11:04 <jirutka> I remember that I’ve moved roundcube, nextcloud and zabbix from main to community when moving php5 out of main; don’t know about pkgs in community now
11:05 <^7heo> the cycle goes like: testing -> community -> main
11:05 <jirutka> ^7heo: I don’t see any benefit from that, many users are already confused from three repos, adding fourth with different rules will just add another confusion :/
11:05 ostera1 joined
11:05 <^7heo> with that cycle we're assuming that software will always transition correctly between versions
11:05 <^7heo> obviously that assumption is flawed.
11:05 <^7heo> what I'm proposing here is to add an exit after main
11:05 <^7heo> testing -> community -> main -> deprecated
11:05 <jirutka> ^7heo: if someone really wants to use deprecated software, then (s)he can always build it themself
11:06 <^7heo> jirutka: and that's the purpose of unmaintained.
11:06 <^7heo> jirutka: but we're talking about php users here...
11:06 <jirutka> ^7heo: yeah, I know!
11:06 <^7heo> It's a bit of an edge case, I have to admit.
11:06 <jirutka> ^7heo: let’s move to up-to-date version of your crappy lang or gtfo :)
11:07 <^7heo> creating a repo for an edge case is far removed from ideal.
11:07 <ncopa> i dont think its worth fixing php5 and php7 to be installed in parallel
11:07 <ncopa> im ok with having a conflict there
11:07 <ncopa> then i think we should delete as many of php5-* apkbuilds as possible
11:07 <ncopa> so we dont need maintain those
11:07 <^7heo> wait, are we talking about having php5 still available BUT uncompatible with php7?
11:08 <^7heo> or are we talking about dropping php5 entirely?
11:08 <ncopa> both
11:08 <ncopa> however
11:08 <jirutka> ncopa: if we decide to keep php5/php7, but use php5 only for pkgs that do not support php7, so remove this insane duplication of apkbuilds, then it may be okish to declare them as conflicting
11:08 <^7heo> How can we drop php5 entirely but still have it available?
11:08 <ncopa> jirutka: that is what i'd want
11:08 <jirutka> ^7heo: we have multiple options how to solve this mess
11:09 <ncopa> like phpldapadmin
11:09 <^7heo> jirutka: yeah I get that; but we can't have php5 AND not have php5. That's kinda antilogic.
11:09 <ncopa> make it depend on php5
11:09 <ncopa> but i dont think it needs any of the php5-* packages?
11:09 <jirutka> ^7heo: one of them is to remove php5 completely, another one is to keep it, but support it only for pkgs that does not support php7, so removing most of the multiversion abuilds that are currently split in separete apkbuilds
11:10 <^7heo> I would be for that latter option personally.
11:10 <ncopa> support it only for pkgs that does not support php7
11:10 <ncopa> is what i'd prefer
11:10 <^7heo> same.
11:10 <ncopa> and kill most php5-*
11:10 <ncopa> if not all
11:10 <ncopa> however
11:10 <jirutka> ncopa: ad phpldapadmin: https://github.com/leenooks/phpLDAPadmin/issues/43
11:11 <ncopa> do we know how many and which php apps does not support php7?
11:11 <ncopa> postfixadmin? roudcube? nextcloud?
11:11 <^7heo> ncopa: it's often "documented" by bug reports in a per-app basis.
11:11 rdutra joined
11:11 <^7heo> (in the case of drupal for example)
11:12 <jirutka> ncopa: I personally prefer to kill php5 with fire :) but I don’t have anything against keeping php5 as we described now, only for pkgs that do not support php7
11:12 <ncopa> could we try make a report of which apps are php5 only?
11:12 <ncopa> yes
11:12 <ncopa> we will not push new things for php5
11:12 <jirutka> ncopa: as I said, don’t now currently, I’ve asked Andy and Valery in the PR on GH, they will probably know that
11:12 <ncopa> so thats an action point
11:12 <jirutka> yeah! we have action points now! :)
11:13 <^7heo> Oh cool management talk!
11:13 <ncopa> :)
11:13 <^7heo> When do we get to have standups? :D
11:13 <ncopa> im trying to learn all those cool words
11:13 <^7heo> Or should we all stand up in front of IRC to make this discussion shorter? :D
11:13 <jirutka> ^7heo: LOL +1
11:14 <^7heo> in my experience, standups are only useful with people who have personal issues.
11:14 <^7heo> self-concious people, short attention span people, etc.
11:14 <ncopa> so we should have standups in #alpine-offtopic then :)
11:14 <^7heo> yeah I disgress.
11:14 <^7heo> sorry.
11:17 <^7heo> ncopa: do you need more time to decide what to do with mkinitfs?
11:17 <^7heo> ncopa: or can we get that in so I can test it asap?
11:17 <ncopa> im blue sky thinking about it
11:17 <ncopa> i think i need to think outside the box
11:18 <^7heo> ncopa: you're 50% of the way to dilbert.
11:18 <ncopa> maybe we should touch base offline before close of play
11:18 ostera1 joined
11:18 <^7heo> it's funny to be blue-sky thinking in a country where in the vast majority of the time, the sky isn't blue.
11:18 <ncopa> going forward we need action that no brainer drill down
11:19 <ncopa> i think i need a though shower
11:19 <^7heo> it's tempting to derail that discussion with silly remarks
11:19 <^7heo> but I will resist.
11:19 <ncopa> :)
11:19 <ncopa> im practicing my manager talk :)
11:20 <^7heo> it was quite noticable ;)
11:22 <^7heo> ncopa: http://dilbert.com/strip/2010-10-25
11:22 leo-unglaub joined
11:22 <jirutka> ncopa: I’ve summarized your position in https://github.com/alpinelinux/aports/pull/1061#issuecomment-291831195
11:26 <^7heo> ncopa: are we gonna make a release of mkinitfs before 3.6?
11:27 <jirutka> ncopa: btw not sure if you’ve seen that: https://github.com/jirutka/emscripten-travis-example; it’s a practical example of using Alpine in chroot on Travis (or any other CI) that leads to much faster builds then using “official” approach (emscripten sdk) :)
11:27 <^7heo> s/then/than/
11:29 <^7heo> ncopa: also it would be very cool to apply main/mkinitfs/0001-init-pull-in-libressl-instead-of-openssl-for-encrypt.patch to mkinitfs.
11:29 <jirutka> ncopa: also based on my quick research, we now provides the best user experience for emscripten among major distros :) (most likely b/c emscripten is huge pile of crappy code unfriendly with distributions) :)
11:30 <^7heo> jirutka: dude, we're really writing to ncopa almost in sync, with the same volume.
11:30 <^7heo> jirutka: we should take turns, who goes first? ;)
11:30 <ncopa> "create a list of packages in main/community that do not support php5 (and maybe subset of them that can be easily patched for php7)."
11:30 <ncopa> jirutka i think you mean list of packages that requires php5
11:30 <jirutka> ^7heo: it seems that we’re in sync XD good that we’re not woman, periods in sync…
11:31 <^7heo> jirutka: that's actually a thing.
11:31 <^7heo> ncopa: do you want me to come back at a later time for mkinitfs?
11:31 <jirutka> ncopa: fixed
11:31 <^7heo> (I could make a todolist with a few action points to do before 3.6 if you want)
11:32 <^7heo> (for mkinitfs, not for *)
11:32 ostera1 joined
11:35 xsteadfastx joined
11:37 <xsteadfastx> clandmeter: sorry i misocnfigured my weechat and it removed history. did you answer me?
11:37 <clandmeter> xsteadfastxd: did you ask me something?
11:38 <xsteadfastx> because mopidy... you asked if there is no aport... and i answered... and thought you were checking something :) sorry
11:38 <clandmeter> no i didnt check it
11:38 <clandmeter> i did look a bit into snapcast
11:39 <clandmeter> looks like that dev is not really into packaging his stuff correctly
11:41 <xsteadfastx> yes. so i wonder if i need to package all this deps into seperated packages. that would be the best or?
11:41 <clandmeter> good luck with that...
11:41 <clandmeter> cause few of them are also from the same dev
11:44 <ncopa> ^7heo: mkinitfs pushed
11:45 <^7heo> ncopa: how about you also push your patch in the aports?
11:45 <^7heo> ncopa: main/mkinitfs/0001-init-pull-in-libressl-instead-of-openssl-for-encrypt.patch
11:45 ostera1 joined
11:46 <ncopa> i think it already is?
11:47 leo-unglaub joined
11:48 <^7heo> ncopa: there's a PR open about it, and it is marked as "no[t] conflict[ing] with the base branch"
11:48 <^7heo> so I think not.
11:48 <^7heo> ncopa: https://github.com/alpinelinux/mkinitfs/pull/8
11:49 <scadu> clandmeter: xsteadfastx what about mopidy?
11:49 <xsteadfastx> scadu: a new version cant be installed because lacking of py-gst1
11:49 <^7heo> ncopa: after it is done, I'd advise to make a release, so I can abump the APKBUILD.
11:49 <jirutka> leo-unglaub: hi!
11:50 <^7heo> (and remove the patch(
11:50 <^7heo> s/($/)/
11:50 <xsteadfastx> scadu: i tried to build it... mopidy could be installed via pip but throws an gstreamer error
11:51 <xsteadfastx> scadu: ah its your logs i found through googling around with that problem
11:52 <ncopa> ^7heo: i dont really care what github PR's says about merge conflicts: https://git.alpinelinux.org/cgit/mkinitfs/commit/?id=c3c4721f2e9c00ae8dd8d1f7bb4061873c1e915a
11:52 <^7heo> ncopa: about the release, I don't know if it should be 3.0.10 or 3.1.0, maybe the latter since we changed quite a few things (esp for crypto)
11:54 <^7heo> ncopa: then someone should close that PR
11:54 stwa joined
11:54 <^7heo> oh, it has been done.
11:56 <scadu> clandmeter: mopidy has been moved to unmaintained
11:56 <scadu> clandmeter: confirmed with ncopa
11:56 <clandmeter> for what reason?
11:56 <clandmeter> i guess in favor of pip?
11:57 <xsteadfastx> there is no py-gst1
11:57 <xsteadfastx> and its needed by newer mopidy version
11:58 ferseiti joined
11:58 <scadu> clandmeter: py-gst1 and some other issues I wasn't able to solve at the time or had no time for this.
11:59 ostera1 joined
12:00 rdutra joined
12:03 <^7heo> pickfire: in case you didn't get the github mail, your PR needs a rebase.
12:04 <xsteadfastx> scadu: clandmeter: i could not getting it working too
12:04 <scadu> 13:41 <@clandmeter> cause few of them are also from the same dev
12:04 <scadu> clandmeter: what packages?
12:04 <clandmeter> snapcast
12:04 <xsteadfastx> scadu: that was about snapcast
12:13 ostera1 joined
12:14 leitao joined
12:17 farosas joined
12:17 gromero joined
12:26 ostera1 joined
12:29 <^7heo> ncopa: also I would say that https://github.com/alpinelinux/mkinitfs/pull/10 can safely go in.
12:32 blueness joined
12:40 ostera1 joined
12:50 <jirutka> ^7heo: if you’ve changed some behaviour (and it’s not a bugfix) or added new feature, then 3.1.0
12:52 <^7heo> jirutka: clearly.
12:52 <clandmeter> xsteadfastx: i think i have an apkbuild for snapcast
12:52 <^7heo> (clearly did so(
12:52 <^7heo> s/($/)/
12:52 <xsteadfastx> clandmeter: oh cool. can i see it?
12:53 ostera1 joined
12:54 <clandmeter> im going to push it to testing.
12:55 <xsteadfastx> yeah. cant wait to see it
13:07 ostera1 joined
13:08 <clandmeter> xsteadfastx: im a bit too late :)
13:08 <clandmeter> ncopa just pushed gcc
13:09 <Shiz> jirutka: i'm unsure how the dependency tracing works, could you enlighten?
13:10 <Shiz> as I understand it, right now it will see the libpq.so (e.g.) from postgresql-dev and recommend that
13:10 <Shiz> but I want it to use the one from the libpq package
13:10 <jirutka> Shiz: do you know tool ldd?
13:10 <Shiz> i know that part
13:10 <Shiz> just how it matches it to packages
13:10 <xsteadfastx> clandmeter: i think it needs the avahi deamon and dependencie
13:10 <clandmeter> depends what a package provides
13:11 <clandmeter> xsteadfastx, yes its not finished yet
13:11 <clandmeter> i think it needs to split the server client and add initd for server.
13:11 <Shiz> ah, wait
13:11 <clandmeter> and probably add a test.
13:11 <Shiz> the -dev provides the bare .so and libpq provides the versioned... version
13:11 <jirutka> Shiz: the tracked dependencies are added as `provides` to APKINDEX
13:12 <jirutka> Shiz: this `so:libpq.so.x.y` is in `provides` of pkg libpq
13:12 <clandmeter> xsteadfastx, but this is a start, if you want you can add a PR to add the missing parts.
13:12 <Shiz> right
13:12 <clandmeter> then we could move it to community if it really works.
13:13 <xsteadfastx> clandmeter: yeah i will build it and check it out. nerved added initd files to my few alpine packages before
13:13 <clandmeter> the apkbuild isnt pretty, but atleast it works like this.
13:13 <clandmeter> xsteadfastx, its very easy
13:13 <clandmeter> openrc has a man page about it
13:13 <xsteadfastx> or split a package or something... but the wiki docs are really great
13:14 <clandmeter> normally what we do is split it by adding a server() and client() subpkg and and have main pkg as metapkg which pulls in both client and server.
13:15 <xsteadfastx> its make client and make server i think... so should i need to find out how i can build two packages within one APKBUILD
13:15 <xsteadfastx> ah ok
13:15 <clandmeter> you dont have to build it independent
13:15 <clandmeter> the subpkgs should just copy the files to subpkgsdir
13:15 <xsteadfastx> i found the subpackage example in the wiki
13:16 <clandmeter> in this case just a single file
13:16 <jirutka> Shiz: I’ve renamed T to A as you suggested, so now we have: A-add, A-fix, A-improve, A-move, A-upgrade; but don’t know what to do with T-security, it does not fit to any existing category; maybe this is the only one that really belongs to T (type)?
13:16 <xsteadfastx> clandmeter: i will look into it tomorrow :)
13:17 gromero joined
13:17 <Shiz> jirutka: I think T-security is just a high-prio A-fix, no?
13:17 <Shiz> :p
13:17 <Shiz> but yeah, it's more of a misc label
13:17 <jirutka> Shiz: also I don’t like A-add, but can’t figure out a better word; it used to be named T-new, but all A are now verbs
13:17 <clandmeter> jirutka, i would like if the labels were more clear.
13:17 <Shiz> A-create?
13:17 <clandmeter> no abbreviations
13:17 stwa joined
13:18 <jirutka> clandmeter: we have just 5 single letter abbreviations… it’s very unpractical to use full name, then it may not even fit on single line when you combine multiple labels on single PR
13:19 <clandmeter> well, i prefer a clear label instead of asking or looking it up (if its even documented).
13:19 <jirutka> clandmeter: what label do you consider unclear?
13:20 ostera1 joined
13:21 <clandmeter> all of the single letters prefixes
13:21 <jirutka> clandmeter: there are just to group labels; I hope that all labels works even without the prefix
13:22 <jirutka> clandmeter: I mean that they make sense even when you omit the prefix
13:22 <clandmeter> if it was clear, i would be asking would i? :)
13:23 <clandmeter> and i think more users would ask, but maybe im more stupid then most of them :)
13:23 <jirutka> clandmeter: users don’t set labels, only we do
13:23 <jirutka> clandmeter: these labels are mainly for reviewers and maintainers, not for contributors
13:23 <clandmeter> i know
13:23 <clandmeter> but users also see them
13:24 <jirutka> clandmeter: and if they should be perfectly clear and unambiguous, then we would need to use sentences instead of short code… ;)
13:24 <pickfire> I didn't saw the last bump, who messaged me?
13:24 <pickfire> ^7heo: Github workflow so problematic. :(
13:24 <^7heo> pickfire: github isn't different from git.
13:25 <^7heo> pickfire: me I think
13:25 <pickfire> ^7heo: I made changes straight on github, without going to git.
13:25 <pickfire> And now need to pull and rebase
13:25 <^7heo> pickfire: yeah you need to pull your changes with git.
13:25 <jirutka> clandmeter: imagine that you have for example: “Action: upgrade”, “Status: change-requested”, “Repository: main”, “Category: python” on one PR… this would not even fit on single line on PRs list
13:25 <^7heo> pickfire: github is okay as an interface to git.
13:25 <pickfire> Can't just merge and squash?
13:25 <^7heo> pickfire: it isn't ok as a tool
13:25 <jirutka> pickfire: it’s not problematic at all, if you really know basis of git…
13:26 <jirutka> pickfire: your problem is not in GH at all, but in git
13:26 <pickfire> Then I say I don't know how to use git.
13:26 <pickfire> How?
13:26 <pickfire> Haha
13:26 <pickfire> I only know what is git - the stupid content tracker.
13:27 <pickfire> I know nothing else.
13:27 <pickfire> Hehe ^^
13:27 <^7heo> omg fucking web...
13:27 <^7heo> it's *SO* slow.
13:27 <pickfire> ^7heo: Here's even slow.
13:27 <pickfire> Let's compare our speed.
13:27 <jirutka> pickfire: btw I personally never edit files directly via Git interface, but it’s principally the same as working with two git repos
13:27 <^7heo> I have a quite decent machine
13:27 <clandmeter> github is slow recently....
13:27 <clandmeter> the webif that is
13:27 <^7heo> clandmeter: I mean the UI
13:27 <^7heo> clandmeter: ah yeah
13:27 <jirutka> clandmeter: yeah, it really is, don’t know why :/
13:27 <pickfire> jirutka: But why can't just merge into one repo?
13:28 <^7heo> so maybe it's not me.
13:28 <^7heo> because it's a half assed UI in ruby?
13:28 <^7heo> anyway
13:28 <pickfire> ^7heo: Here's 5 mbps.
13:28 <^7heo> pickfire: I'll explain how to do that in /query, as it's not some information that is interesting for most people here ;)
13:28 <pickfire> What about yours?
13:28 <jirutka> clandmeter: I’ve started thinking about finding some CLI tool for working with PRs (not just just pull PR, but manage them, comment etc.), b/c web interface is slow
13:28 <^7heo> pickfire: the webapp is slow, the connection speed is ok.
13:28 <pickfire> Ah
13:29 <^7heo> jirutka: that's my goal, I planned to do a python tool for that.
13:29 <^7heo> jirutka: but maybe LUA would fit.
13:29 <pickfire> You mean alpinelinux.org is slow?
13:29 <^7heo> no, github.
13:29 <^7heo> you're aware that github is an app on top of git, right?
13:29 <pickfire> alpinelinux.org is even slow.
13:29 <jirutka> clandmeter: but still better than GitLab, at least GitHub always load the page and never lost data, lol :)
13:29 <^7heo> github is slow, git is fine.
13:29 <clandmeter> clean your mouth, alpinelinux.org is tha best!
13:29 <pickfire> I won't be surprised even if you say it is slow.
13:29 <jirutka> pickfire: no, I mean GitHub web interface
13:30 <pickfire> clandmeter: alpine linux is the best, not alpinelinux.org
13:30 <jirutka> pickfire: alpinelinux.org is faster than light!
13:30 <pickfire> jirutka: github isfat
13:30 <pickfire> FAT
13:30 <^7heo> gitlube.
13:30 <pickfire> Network hogger
13:30 <jirutka> pickfire: FAT? Like File Allocation Table?
13:30 <pickfire> each page is 700 MB uncompressed.
13:30 <jirutka> pickfire: wtf?
13:31 <pickfire> I don't know what can I do for this http://patchwork.alpinelinux.org/patch/3184/
13:31 <clandmeter> jirutka, if you hook that interface on github's api, you think it will be faster?
13:31 <pickfire> jirutka: Sorry, 700 KB
13:32 <clandmeter> or you mean a complete independent one?
13:33 <clandmeter> ncopa, is that ppc builder still doing its first world cycle?
13:34 <jirutka> clandmeter: yes, definitely
13:34 ostera1 joined
13:35 <ncopa> we maybe should have it halt on errors now
13:35 <jirutka> clandmeter: did you got my point about short label names?
13:36 <jirutka> clandmeter: the scheme I used is inspired from https://github.com/rust-lang/rust/issues
13:36 <clandmeter> phone...
13:37 <jirutka> clandmeter: I’ve also considered another schemes like “Category: Python” etc. and it’s just unnecessary verbose and impractical, it would clutter the list of PRs a lot
13:38 <jirutka> clandmeter: also we can get rid of prefix and use just colour to distinguish various “types” of labels, but that wouldn’t help you with selecting them using autosuggestions
13:47 <clandmeter> back
13:47 <clandmeter> jirutka, like i mentioned, its not only for me but i think its also nice for contributors to know what it means.
13:48 <clandmeter> alternative is to have it documented?
13:48 ostera1 joined
13:51 <jirutka> clandmeter: yes, we can document it; however, I hope that e.g. S-changes requested is clear enough even without knowledge what S stands for… this is really just a helper for us to quickly select the proper label
13:54 <jirutka> clandmeter: the current state is basically first draft to see how it will work for us
13:56 <clandmeter> ncopa, yes please cause commits channel is pretty difficult to follow now.
13:57 <clandmeter> are we going to finish ppc world before 3.6?
13:57 <jirutka> clandmeter: the next step for me is to write a “classification algorithm” that would eat patch file and produce set of tags (mainly A, C, R)
13:57 <ncopa> i think so
13:57 <clandmeter> sounds fun
13:57 <jirutka> clandmeter: ncopa: yes, #alpine-commits is very cluttered these days
13:58 <ncopa> seems like main built all except compiler-rt and ncftpd
13:58 <jirutka> clandmeter: yeah, it is :) and that’s the problem, I haven’t finished many projects yet and heeey, another exciting one! :/
13:58 <clandmeter> jirutka, i was refering to building world :)
13:58 <jirutka> clandmeter: aha :)
13:59 <clandmeter> always much fun
13:59 <clandmeter> and i dont have access to ppc hw, so i cant help.
13:59 <jirutka> clandmeter: I guess that we can ask leitao to give us some VM :)
13:59 <clandmeter> or just let ncopa fix it ;-)
14:00 <jirutka> clandmeter: they have even a website where you can register to get access to some ppc64le, but I don’t remember the address
14:00 <jirutka> okay, coffee break now and then I must really do a work I’m actually paid for :)
14:01 <ncopa> its actually leitao gromero and rdutra that have been fixing ppc64le
14:01 <clandmeter> yes i know
14:01 <clandmeter> but will they finish on that pace?
14:01 ostera1 joined
14:01 <clandmeter> on time..
14:01 <ncopa> yes
14:02 <clandmeter> ok
14:03 <pickfire> ^7heo: I have updated it.
14:05 leo-unglaub joined
14:06 <pickfire> I need help with %3184
14:06 <algitbot> [alpine-aports] testing/pass: upgrade to 1.7 - Patchwork: http://patchwork.alpinelinux.org/patch/3184/
14:07 <pickfire> I don't know how should I get the file name, should I do find $pkgname-*?
14:07 <pickfire> ls doen't glob.
14:08 tmh1999 joined
14:10 gromero joined
14:12 <^7heo> pickfire: I've got the mail
14:13 <pickfire> What mail?
14:13 <pickfire> I haven't checked yet.
14:14 blueness joined
14:15 ostera1 joined
14:20 <clandmeter> scadu, whats the reason we dont have gst py?
14:20 fabled joined
14:22 <scadu> clandmeter: frankly, I don't remember.
14:25 <scadu> clandmeter: it is 7 or 8 months when mopidy has been moved to unmaintained
14:28 ostera1 joined
14:35 <leitao> clandmeter, would you like a ppc64le vm?
14:36 <clandmeter> leitao, ok, not sure if i can help right away though.
14:37 <clandmeter> but could come in handy with failures
14:38 <leitao> clandmeter, sure. If you need them, just start one at http://openpower.ic.unicamp.br/minicloud/
14:39 <leitao> request one machine first, then you have access to a openstack instance, where you can fire up Vms
14:40 <clandmeter> done
14:42 ostera1 joined
14:44 fabled_ joined
14:46 <jirutka> leitao: I’ve also submitted request for access, I got an idea: try to run GitLab CI runner on ppc64le :)
14:47 <leitao> jirutka, that is a good idea.
14:56 ostera1 joined
14:56 blueness joined
15:00 <leitao> ncopa, it seems that all the packages on 'main' are now compiled for ppc64le.
15:00 <scadu> clandmeter: might by that I have packaged py-gst1, but encountered another issue
15:00 <leitao> Should we move the target to 'community' now?
15:01 <ncopa> yup
15:01 <scadu> clandmeter: yeah, probably I showed you and/or ncopa APKBUILDs for new mopidy and py-gst1 including the logs
15:02 <clandmeter> could be
15:02 <leitao> ncopa, ack
15:03 ppisati joined
15:03 <ncopa> leitao: i changed the build server config so it will halt on first error
15:04 <leitao> ncopa, right, it should clean up the messages on #alpine-commits now.
15:04 <ncopa> because it spammed the #alpine-commits channel
15:04 <leitao> ncopa, should we look at the scripts to build the images?
15:05 <ncopa> you mean to build a rootfs image for docker?
15:05 <ncopa> or release images?
15:05 <ncopa> i am not sure what makes sense as release image for ppc64lw
15:05 <ncopa> le*
15:06 <leitao> ncopa, at the moment, the only one that does not make sense is ISO, since grub is still not "built"
15:06 <leitao> so, docker and rootfs makes sense
15:09 ostera1 joined
15:09 <ncopa> the idea with rootfs is that should be the base for docker image
15:10 <ncopa> currently the docker image is built separately
15:23 ostera1 joined
15:33 <scadu> xsteadfastx: clandmeter maybe you will find it useful: http://tpaste.us/Oz86 that's everything I got regarding mopidy. maybe it was a temporary issue with this moddule -- I didn't check later
15:36 ostera1 joined
15:50 ostera1 joined
15:56 leitao joined
16:03 ostera1 joined
16:15 minimalism joined
16:18 ostera1 joined
16:19 ostera joined
16:48 atmoz joined
17:00 blueness joined
17:01 tmh1999 joined
17:01 leo-unglaub joined
17:10 94KAAOKYC joined
17:10 faffolter joined
17:10 faffolter joined
17:11 faffolter joined
17:11 faffolter joined
17:15 leitao joined
17:48 <mitchty> also as a note, i'll probably get agda building as well in alpine linux and get a PR out for that, I ported ghc for more reasons than just itself, but alpine linux needs more dependently typed programming languages
17:48 <mitchty> how are things like emacs mode files generally handled?
17:49 MH0815 joined
17:52 leo-unglaub joined
17:56 <leo-unglaub> hey :)
17:57 alacerda joined
17:57 <leo-unglaub> what did i read on the ML, grsec will be removed from the kernel?
17:58 MH0815 joined
18:10 ostera joined
18:16 <_ikke_> leo-unglaub: grsec is going dark entirely
18:17 <leo-unglaub> hehe, nice. so that project is dead ... because no one is going to pay for security in an os
18:17 <leo-unglaub> its not shiney enought for people to pay for it
18:18 <_ikke_> I believe intel is paying
18:18 <leo-unglaub> intel? are they not the company that fucked them over in the first place?
18:18 <_ikke_> Yeah, and they have to pay now
18:20 <leo-unglaub> hahaha
18:20 <scadu> _ikke_: why is that?
18:20 <leo-unglaub> and whats alpines plan for new releases?
18:21 <_ikke_> I heard something about apparmor
18:21 <_ikke_> scadu: If they want to use grsec, they have to pay
18:21 <leo-unglaub> hmm, appamor is not the same as what grsecurity did
18:21 <scadu> _ikke_: I know, I know. I have to read about the details regarding Intel and grsec then ;f
18:22 <skarnet> ask kaniini for the details
18:23 <skarnet> roughly, apparmor+PaX offers the same functionality as what alpine was using in grsecurity
18:23 <kaniini> PaX not portable
18:23 <kaniini> sorry
18:23 <kaniini> looked into it
18:23 <kaniini> it's a mess
18:24 <scadu> kaniini: may I pm you?
18:26 <kaniini> sure
18:26 <kaniini> leo-unglaub: oh, grsec isn't going "dark", but they clearly like money and would prefer to just deal with people who pay money.
18:32 <leo-unglaub> i have no problem with them making some money, but i am pretty sure no one is buying it
18:32 <leo-unglaub> way to much alternatives out there
18:33 <* kaniini> shrugs
18:45 <mitchty> also first rc for 8.2 got released yesterday, will work on getting that building
18:45 <mitchty> http://downloads.haskell.org/~ghc/8.2.1-rc1/
18:46 blueness joined
19:40 cyteen joined
19:42 <clandmeter> ncopa, any reason we are holding back on gstreamer1?
19:44 blueness joined
19:49 <ncopa> clandmeter: sorry, i have not noticed that?
19:49 <ncopa> clandmeter: ping me tm about it please
19:49 <clandmeter> ok
19:52 <ncopa> kaniini: sorry for not responding on that grsecurity email
19:52 <ncopa> i think we will keep grsecurity for now and see what happens
19:53 <ncopa> im hoping they will realize that killing the grsecurity "community" and the ecosystem with it will hurt themselves
19:54 <ncopa> it seems like they might realize its not a good idea, but at the same time they will prevent kspp ripping of their work
19:55 <ncopa> if they kill the ecosystem, then their customers will have to build userspace themselves
19:55 <Shiz> i couldn't reply to the mailing list because of a broken mail server, but i agree
19:56 <kaniini> that is true, if we drop grsec
19:56 <kaniini> we probably will stop caring about paxmarking things
19:56 <Shiz> i'd rather that didn't happen as i'll likely still built my own grsec kernels :p
19:57 <kaniini> i guess we keep it for 3.6 then
19:57 <kaniini> and see how this plays out
19:58 <kaniini> ncopa: http://build.alpinelinux.org/buildlogs/build-edge-ppc64le/main/ca-certificates/ca-certificates-20161130-r1.log
19:58 <kaniini> ncopa: something is really broken here
20:09 <ncopa> huh
20:09 <ncopa> leitao: ^^^ looks like somethign broke pretty bad
20:09 <ncopa> i will check it tm
20:11 <leitao> ncopa, hmm
20:11 <leitao> ncopa, how do I restart this build?
20:22 <leitao> ncopa, it seems something happened on the kernel. "BUG: soft lockup - CPU#6 stuck for 27s!"
20:37 cyteen_ joined
20:41 czart_ joined
20:49 ostera joined
20:49 gromero joined
20:53 gromero joined
21:02 gromero joined
21:14 <kaniini> you have fs corruption
21:14 <kaniini> probably need to fix that first
21:14 <kaniini> then service aports-build start
21:14 <kaniini> should in theory do it
21:15 <kaniini> the soft lockup is likely due to an interrupt storm caused by the storage infrastructure (local SAS controller?) reporting errors to the supervisor domain (i do not know the specifics to how this would be on POWER), which means that you probably have a bad disk or your SAN failed
21:19 <kaniini> leitao: ^
21:30 <kaniini> leitao: it is very important to stop the VM and fsck the disk image from the supervisory domain before starting it again
21:30 <leitao> kaniini, ok
21:30 <leitao> let me try that
21:30 <kaniini> if you try to fsck it live, you will make the corruption worse probably
21:37 blueness joined
21:41 <leitao> kaniini, I am not sure this is a file system issue
21:41 <leitao> I am wondering if a process is stuck in a processor for a long term
21:41 <leitao> [1131748.030647] NMI watchdog: BUG: soft lockup - CPU#5 stuck for 21s! [cc1plus:15218]
21:41 <leitao> it always show cc1plus in those CPU stuck
21:50 <kaniini> humm
21:50 <kaniini> leitao: is this dedicated to building alpine packages or?
21:50 <kaniini> leitao: because the other possibility is that the CPU is overcommitted if it is shared
21:51 <leitao> kaniini, this is a VM on a big machine.
21:51 <leitao> So, the CPUs are being shared.
21:51 <leitao> kaniini, so, it might be the case.
21:51 <leitao> how do I check if it is still finding problem?
21:52 <leitao> service 'aports-build' does not seem to exist
21:53 <tmh1999> kaniini : random stuff. I am booting a kernel + initramfs in kvm. got to the point OpenRC is loaded. then the tty* error : http://tpaste.us/P7Ey. More info is at the end of the paste
21:53 <tmh1999> kaniini : would you mind have a look ?
21:59 <tmh1999> in the rootfs (example.img), I manually created /dev/tty*
22:11 <kaniini> what filesystem is example.img
22:11 <kaniini> because it sounds to me like ext4 support is not really available
22:12 ostera joined
22:12 <kaniini> or actually
22:12 <kaniini> i think actually
22:12 <kaniini> you dont have services you need enabled
22:12 <kaniini> if you chroot into example.img
22:12 <kaniini> what does rc-update say
22:13 <kaniini> because it should be starting mdev very early
22:13 <kaniini> tmh1999: ^
22:13 <tmh1999> example.img is ext4 as described in the paste
22:14 <tmh1999> rc-update returns nothing kaniini
22:14 <kaniini> oh dear
22:14 <kaniini> tmh1999: you need to do
22:14 <kaniini> tmh1999: rc-update add bootmisc boot
22:15 <kaniini> tmh1999: and the same for hostname, hwclock, modules, networking, sysctl, syslog
22:15 <kaniini> tmh1999: rc-update add devfs sysinit
22:15 <kaniini> tmh1999: same for dmesg, hwdrivers, mdev
22:15 <kaniini> tmh1999: killprocs/mount-ro/savecache for shutdown
22:16 <kaniini> tmh1999: after you do that you should be able to boot
22:16 blueness joined
22:16 <tmh1999> kaniini : damn I haven't ack about this
22:16 <tmh1999> I am trying them
22:19 <xsteadfastx> scadu: that's exactly what I found out. The module is in site-packages/gi but throw a error when importing. I also tried to build a newer version of gstreamer1 with same results
22:20 <jirutka> xsteadfastx: scadu: I’ve tried that on Fedora and it failed in the same way until I installed pkg gstreamer1-plugins-good, after that import works and mopidy as well
22:23 <tmh1999> kaniiini : I did as you said and a bunch of service started. but the tty* error still there
22:24 <xsteadfastx> So you think it's a problem with gstreamer1-plugins-good in Alpine?
22:24 <tmh1999> kaniini : ^
22:24 <tmh1999> kaniini : should we avoid checking tty[1-6] ?
22:24 <tmh1999> *how
22:31 minimalism joined
22:31 <Shiz> jirutka: thanks for the extensive review btw :)
22:31 <jirutka> Shiz: you’re welcome :)
22:32 <Shiz> gonna delay that last edit until i get table-sqlite personally working on my machine, i seem to be running into an obscure issue
22:32 <Shiz> :p
22:32 <Shiz> any opinions on that other opensmtpd PR I made?
22:32 <jirutka> Shiz: this one? https://github.com/alpinelinux/aports/pull/1208
22:33 <Shiz> correct
22:33 <jirutka> Shiz: I like changing runscript from smtpd to opensmtpd
22:34 <jirutka> Shiz: but not sure how to provide seamless upgrade path for existing users
22:34 <Shiz> right.
22:34 <Shiz> i guess one easy way could be a post-install/upgrade script
22:34 <jirutka> post-upgrade
22:35 <Shiz> something like
22:35 <jirutka> but I’m not fan of changing some configs in post-upgrade scripts on behalf of user
22:35 <jirutka> maybe just add post-upgrade message warning about this change
22:35 <Shiz> right
22:35 <jirutka> Shiz: like in https://github.com/alpinelinux/aports/blob/master/main/nginx/nginx.post-upgrade#L6
22:36 <Shiz> i can agree that preferably you don't want to dab around too much
22:36 <Shiz> although if /etc/smtpd exists and /etc/opensmtpd doesn't it would be a fairly clean case
22:37 laj joined
22:40 tmh1999 joined
22:54 <kaniini> tmh1999: hmm
22:55 <kaniini> tmh1999: are you mounting devtmpfs
22:55 <kaniini> tmh1999: because devtmpfs is needed
22:55 <tmh1999> kaniini : I guess I didn't. How so ?
22:55 <kaniini> tmh1999: can you give me latest log
22:56 <kaniini> ahh
22:56 <kaniini> tmh1999: in your kernel,
22:56 <kaniini> tmh1999: you have CONFIG_DEVTMPFS_MOUNT disabled
22:56 <kaniini> tmh1999: but in the other kernels, it is enabled.
22:56 <tmh1999> http://tpaste.us/6XM8
22:56 <tmh1999> hah
22:56 <tmh1999> I see
22:56 <tmh1999> I will recompile
22:58 <kaniini> also
22:58 <kaniini> it may be that on s390x
22:58 <kaniini> /dev/tty0 is the only tty you need
22:58 <kaniini> so try messing with /etc/inittab
22:59 <tmh1999> kaniini : thanks. let me try and get back
23:01 <Shiz> kaniini: in the apk-tools rewrite, do we plan on upgrading to non-sha1 hashes too?
23:01 <Shiz> :p
23:02 <kaniini> Shiz: yes we are upgrading to md2 hashes
23:02 <kaniini> Shiz: what do you think
23:02 <Shiz> i don't think anything
23:02 <kaniini> Shiz: a whole 128 bits of security. bank level.
23:03 <kaniini> Shiz: but in all seriousness, sha2-512 is likely what will be used
23:03 <kaniini> Shiz: as in apkbuild
23:03 <Shiz> right, i'm thinking of the .SIGN.RSA.* stuff
23:03 <Shiz> fwiw
23:04 <Shiz> also something something eddsa keys would be nice ;P
23:06 <kaniini> yes, that too
23:06 <kaniini> we are probably going to use Ed25519
23:07 <kaniini> but maybe not
23:07 <kaniini> because NSA quit using ECC
23:07 <kaniini> so maybe they know something
23:07 <kaniini> that we do not
23:07 <kaniini> its hard to say either way
23:07 <Shiz> post quantum post quantum post quantum
23:07 <kaniini> i think most likely if they know something, it is a way to linearly attack ECC, i.e. not quantum
23:08 <Shiz> yeah was foolin'
23:10 <skarnet> post quantum ergo proper quantum
23:11 <Shiz> then again, suite B never used RSA in the first place
23:11 <Shiz> so it's hard to correlate with 'just' ECC being dropped