<     May 2017     >
Su Mo Tu We Th Fr Sa  
    1  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 _2_7  
28 29 30 31
00:22 blueness joined
00:32 blueness joined
00:52 blueness joined
01:49 blueness joined
01:50 s33se_ joined
02:10 farosas joined
02:16 blueness joined
02:27 duncaen joined
02:38 duncaen joined
02:42 farosas joined
03:37 xsteadfastx joined
04:35 NightKhaos_ joined
05:15 fabled joined
05:32 D630 joined
07:13 t0mmy joined
07:14 royger joined
07:21 fekepp joined
07:59 vakartel joined
08:06 <tru_tru> fcolista: sorry typo for perl-number-format version -> should be 1.75 not 1.74
08:09 <fcolista> tru_tru, :
08:09 <fcolista> aports:master |Francesco Colista| testing/perl-number-format: upgrade to 1.75 | http://dup.pw/aports/3fb895dd
08:47 blueness joined
09:01 FilippAndronov joined
09:08 t0mmy joined
09:17 <tru_tru> fcolista: thx
09:18 <tru_tru> fcolista: the make test is disabled on purpose?
09:18 <fcolista> tru_tru, yes
09:19 <tru_tru> can we try to fix the failure during "make test"?
09:20 <tru_tru> or it is a locale/glibc issue ?
09:20 <fcolista> tru_tru, what's the reason ?
09:21 <fcolista> does it not work?
09:21 <tru_tru> https://gist.github.com/truatpasteurdotfr/e20019cd06027775284e19779ed79d67
09:22 <tru_tru> Failed test 'euros' and Failed test 'rubles'
09:22 <fcolista> tru_tru, i mean: what's the aim of fixing the make test?
09:22 <fcolista> It might be related to locale, yes
09:22 <fcolista> I didn't checked that
09:23 <tru_tru> Number::Format is a requirement for circos cf http://circos.ca
09:24 <tru_tru> if someone happen to use euros/rubles I would rather have it properly working
09:25 <fcolista> makes sense
09:27 hanez joined
09:31 <tru_tru> https://github.com/gliderlabs/docker-alpine/issues/144 and https://github.com/rilian-la-te/musl-locales ? that way off my league!
09:33 consus joined
10:01 leo-unglaub joined
10:18 blueness joined
10:29 scadu joined
11:08 mmlb joined
11:38 vakartel joined
11:48 tty` joined
12:15 leitao_ joined
12:23 gromero joined
12:34 gromero joined
12:43 minimalism joined
12:50 farosas joined
13:15 vakartel1 joined
13:40 vakartel1 joined
13:48 vakartel1 joined
13:56 s33se joined
14:08 duncaen joined
14:13 fabled joined
14:18 vakartel1 joined
14:31 czart joined
14:44 tmh1999 joined
15:04 xsteadfastx joined
15:09 consus__ joined
15:12 czart_ joined
15:22 blueness joined
15:48 elegast joined
15:49 <elegast> Is there any need for aports/abuild keys to be of type RSA, can i just use ECDSA instead without side effects?
15:55 <elegast> I'll just try and see if anything sets fire
16:42 <kaniini> hi
16:42 <ncopa> hi
16:42 <ncopa> i think i will build openssh with pam support
16:43 k63ZXXguczqE joined
16:43 <ncopa> for two factor auth
16:43 <kaniini> xentec: i am going to try to debug your 0-byte package thing in a bit
16:43 <xentec> thx. you need to work on a tmpfs to make it work
16:43 <kaniini> xentec: yes
16:44 <kaniini> ideally, we would build packages in a chroot using fakechroot
16:44 <kaniini> that's something i want to work on in future
16:44 <kaniini> elegast: apk-tools does not recognize ECDSA keys
16:45 <kaniini> elegast: only RSA and DSA, and we're probably dropping DSA soon :)
16:45 <kaniini> elegast: apk-tools 3 will support ED25519 keys
16:45 <kaniini> maybe
16:45 <kaniini> we're mulling over it
16:45 <kaniini> NSA has quit using ECC crypto, which is eyebrow-raising
16:45 fekepp joined
16:46 <xentec> kaniini: I've just remebered that I already have looked deeper I this issue.
16:46 <xentec> apk-tools/src/database.c:519
16:46 <kaniini> yes, that is what i was suspecting
16:46 <xentec> If pkg size is 0, apk assumes it's a virtual package
16:46 <kaniini> yes
16:47 <kaniini> we likely need to add a flag for it
16:47 <kaniini> it's no problem :)
17:09 <ncopa> any comment on this: http://tpaste.us/9yn0
17:09 <ncopa> it will break things for current PAM users
17:10 <ncopa> unless thye have explicitly apk add linux-pam
17:13 <elegast> Oh, yes I missed thepart about apk not recognizing ECDSA keys
17:18 <Shiz> nooo not pam
17:18 <ncopa> Shiz other option to provide two factor auth to sshd?
17:19 <Shiz> sadly not
17:19 <ncopa> the idea here is
17:19 <ncopa> most people will (hopefully) not use pam
17:19 <ncopa> but we may want provide support for it for those who needs it
17:19 <ncopa> so we split out libpam, which is only 60k or so
17:20 <ncopa> this is the only lib openssh links to
17:20 <ncopa> which means we add only 60k bloat
17:20 <ncopa> if you actually want use it you will have to install the rest of pam with apk add linux-pam
17:21 <ncopa> which is 1MB
17:21 <elegast> theres no pam-wheel though?
17:21 <Shiz> tbh i\d rather have a separate openssh-pam (sub)pkg if we want to do that
17:21 <Shiz> because i want nothing related to pam on my system
17:21 <ncopa> ok
17:22 <ncopa> thats the other option
17:22 <ncopa> build sshd twice
17:22 <ncopa> one with pam and one without
17:22 <ncopa> thats probably a better idea
17:22 <Shiz> :) that's one i can live with
17:22 <ncopa> so you'll need to apk add openssh-server-pam or so
17:22 <Shiz> *nod
17:23 <ncopa> that also prevents full breakage for current pam users
17:37 <elegast> kaniini: are you sure ecdsa is not already supported? I just built grub from aports/testing and the process signed with my key successfully, then it installed successfully using apk add?
17:38 <elegast> Did it just silently ignore anything? If it didn't recognize my ecdsa key, should it not at the very least complain very loud during install?
17:41 <elegast> kaniini: about ECC crypto though, you're not trusting ECDSA becuase of potential NIST/NSA colaboration, which I understand, but then you *would* trust RSA?
17:42 <kaniini> elegast: worse: it probably didn't verify anything at all
17:42 <elegast> oh. The install process doesn't verify out of the box?
17:44 <kaniini> elegast: it should be. and it should have errored, but it didn't.
17:44 <kaniini> elegast: https://git.alpinelinux.org/cgit/apk-tools/tree/src/package.c#n521
17:44 <elegast> heh. would you look at that
17:44 <Shiz> RSA is more trustworthy than ECDSA
17:44 <elegast> sha512 it is
17:44 <Shiz> imo
17:45 <Shiz> that's not sha512, but rsa512
17:45 <Shiz> :D
17:45 <elegast> err, yes
17:45 <elegast> ofcourse
17:46 <Shiz> anyway, the nistp curves are sketchy because of the incomplete docs behind their generation and shown weaker security properties
17:46 <elegast> Well I would trust RSA over ECDSA for the sake of it being older, and thus proven. But as for the sake of NSA involvement, if you don't trust ECDSA for that reason, then you sure as heck can't trust RSA.
17:46 <Shiz> combined with that the sudden move of NSA away from EC entirely...
17:46 <kaniini> elegast: RSA seems fine at >2048 key lengths at present time, apk defaults to 4096 already
17:46 <elegast> Are they moving away? Or is that just to get everyone else to move away from it?
17:46 <Shiz> elegast: why?
17:46 <kaniini> elegast: to duplicate a key, many signatures would have to be factorized, which is too expensive for a 2048 bit key
17:47 <Shiz> NSA wasn't involved in RSA, the NIST was provably involved in nistp curves
17:47 <Shiz> ;p
17:47 <elegast> Well there's been many rumers about RSA/De Raadt/NSA collaboration
17:47 <kaniini> elegast: yes. ECC is forbidden for top secret level classified documents
17:47 <Shiz> see also: NSA suite 2
17:47 <* Shiz> envisions a future for apk with ed25519 though
17:47 <Shiz> ;)
17:47 <kaniini> elegast: yes, on IPsec products
17:48 <Shiz> elegast: also note that RSA the corporation has nothing to do with RSA the algorithm
17:48 <kaniini> elegast: which is different than RSA itself which predates de raadt being relevant at all
17:48 <Shiz> the corporation was formed afterwards and does weird broken security products
17:48 <Shiz> :P
17:48 <elegast> awk, I assumed rsa/ras inc/van dyke to be closely related
17:48 <kaniini> have we now gotten to the part in the security troll where you discuss how great grsec is and how we're screwed now that grsec no longer exists?
17:48 <kaniini> ;)
17:49 <elegast> lol no, im not trolling, my info is outdated more likely
17:50 <kaniini> Shiz: yes, ed25519 likely
17:51 <elegast> I disagree that you can deduce facts about security by looking at what NSA publicly does, says or mandates in any way shape or form though.
17:53 <elegast> Anyway, the problem at hand is my build supposedly being signed when it's not and/or my apk install not veryfing at all or ignoring invalid signatures
17:53 <elegast> so I gotta get back to work, thanks for the info though, guys!
18:06 <kaniini> or your key isnt what you think it is.
18:17 <elegast> ghehe
18:17 <elegast> im pretty sure
18:17 <elegast> so is openssl
18:17 <elegast> Enter PEM pass phrase:
18:17 <elegast> Private-Key: (521 bit)
18:17 <elegast> priv:
18:17 <elegast> XX: ...
18:17 <elegast> pub:
18:17 <elegast> XX: ...
18:17 <elegast> ASN1 OID: secp521r1
18:17 <elegast> NIST CURVE: P-521
18:18 t0mmy joined
18:31 <elegast> oh wow, this makes up for all the trouble though, ^C during the build process removes any installed dependencies that occurred during the build process :D
18:33 <elegast> I did a random "abuild -r" to test, and it started pulling in and isntalling two screens worth of dependencies .. so my first instinct was "sigh ... I should've chrooted this" but all is welll
18:34 <_ikke_> righ
18:34 <_ikke_> abuild -r removes the installeded dependencies again
18:35 <elegast> Ah. -.- ofcourse. I thought it stood for recursive
18:36 <_ikke_> it just means install dependencies, but it also uninstalls them again after build
18:36 <elegast> mhm, yeah I'm happily surprised by the cleanup
18:46 <elegast> only after the build process has started though, not if its interrupted during the install phase of dependencies
18:50 <elegast> ok so, more on the key issue
18:50 <elegast> I have thusfar, made rsa keys instead of ecdsa, built another package, and it reported: >>> imapproxy: Signing the index...
18:51 <elegast> then I removed the pubkey from /etc/apk/keys
18:51 <elegast> apk complained about the signature
18:51 <elegast> as expected
18:53 <elegast> This means that if you sign packages with an ecdsa key (presumably any other key that isn't handled by apk, but a valid key none the less) you can get people to install the package without verification error
18:53 <elegast> Seeing how *none* of the repositories are serving on https by default, this is a pretty major security risk
18:54 <elegast> What's to keep me from intercepting the packages and feeding you my own, compromised version?
18:54 <elegast> All i have to do is sign them with a random key that openssl considers valid, but apk doesn't handle
18:59 <elegast> Or am I confused and is it not the package that is signed, but the repository index?
19:05 <elegast> kaniini: No, I think you are indeed mistaken, ecdsa is infact supported: Without my ecdsa key in the keystore, apk reports: WARNING: Ignoring /home/elegast/packages/testing/x86_64/APKINDEX.tar.gz: UNTRUSTED signature
19:06 <elegast> atleast as far as the signed index goes.
19:06 <kaniini> or again your ecdsa key isn't an ecdsa key
19:06 <elegast> Openssl clearly says it is?
19:07 <kaniini> look i'm not going to waste my time arguing with you about this
19:07 <kaniini> enjoy your broken security
19:07 <elegast> ahem.
19:07 <elegast> Its YOUR broken security im enjoying.
19:09 <elegast> But if you find it a waste to discuss something that appears to be a security risk on this platform, on a vanilla install, that's fine
19:09 <fabled> elegast, currently apk verifies index's signature, if it is valid the packages are trusted as long as their index hash matches the package hash
19:09 <fabled> that is package signature is not verified if index says it's good
19:10 <elegast> Ok that makes sense. Thank you fabled
19:11 <fabled> that's something we probably change in long term
19:11 BitL0G1c joined
19:11 <fabled> but that's the current behaviour
19:23 elegast left
19:25 <xentec> Shiz: care to explain the pam hate? or place a link to something which does?
19:26 <Shiz> I don't have a link straight-up handy, but the gist of it comes down to two things for me
19:26 <Shiz> 1) pam configuration is weird and unwieldy
19:27 <Shiz> 2) authentication by loading 3rdparty shared libraries in your address space is a ~very bad idea~
19:27 <Shiz> no matter what role you give to the shared library, it can just manipulate its way into breaking your auth completely
19:27 <Shiz> even if you tell pam to use it only for logging, or treat its return value as nonauthorative, etc
19:28 <Shiz> (and it won't work for static binaries, for obvious reasons)
19:30 <Shiz> something like bsdauth is a way better idea since it performs process and privilege isolation
19:34 <xentec> I see. And while bsdauth is, as you say, better, the linux world is locked on pam right now, I guess?
19:35 <Shiz> yeap.
19:40 <kaniini> fabled: yes, but ECDSA is not supported for indexes
19:41 <kaniini> elegast: what method did you use to generate the ECDSA key?
19:42 <Shiz> kaniini: side-note: do you have the source code for that W^X LSM of yours anywhere?
19:43 <kaniini> Shiz: not right now, i will have to dig out an old machine
19:43 <Shiz> right
19:43 <kaniini> anyway
19:43 <kaniini> sig=".SIGN.RSA.$keyname"
19:44 <kaniini> is in the abuild-sign
19:44 <kaniini> hmm
19:44 <kaniini> that's concerning
19:44 <Shiz> lol
19:44 <kaniini> elegast: i think it works by side effect
19:52 <kaniini> i mean, i guess
19:52 <kaniini> maybe we should add ecdsa support to abuild-keygen
20:09 <ncopa> re pam, since its a lib, you may need run your big app as root to access /etc/shadow
20:09 <ncopa> with bsdauth, you do that with a separate process
20:09 <ncopa> eg proper priv sep
20:10 <Shiz> yep
20:10 <ncopa> so yes, i agree re pam. want avoid if possible
20:10 <ncopa> unfortunally there are not many alternatives on linux
20:11 <ncopa> we should tag rc1
20:22 ncopa joined
20:31 FilippAndronov joined
20:45 <Shiz> wee
20:46 <arch3y_> ncopa: Shiz thanks for pulling my pr for flex
20:46 <arch3y_> I have a few others that would be nice if they got merged and Id start contributing more lol
20:47 <Shiz> if you link em i can at least check em
20:51 <arch3y_> sure will do
20:53 <arch3y_> Shiz: https://github.com/alpinelinux/aports/pull/1315 https://github.com/alpinelinux/aports/pull/1311 https://github.com/alpinelinux/aports/pull/1310 https://github.com/alpinelinux/aports/pull/1308 https://github.com/alpinelinux/aports/pull/1307
20:53 <arch3y_> lots to look at
21:02 <arch3y_> question if I need to disable fortify_source on a pkg to get it to compile will that be an issue in getting it merged
21:02 <kaniini> yes
21:02 <arch3y_> k thought so
21:02 <arch3y_> so unless the devs want to work on the hardening aspect or I do then its not gonna work
21:02 <arch3y_> got it thanks
21:02 <kaniini> ncopa: i am down for bringing in BSD auth
21:06 <Shiz> same but i don't think there's an existing port to linux for it
21:15 blueness joined
21:42 <Shiz> useful git alias for merging github PRs:
21:42 <Shiz> git config --global alias.merge-pr '!git checkout origin/pr/$1 && git rebase ${2:-master} && rev=$(git rev-parse HEAD) && git checkout ${2:-master} && git merge --ff-only $rev && echo "pr merged:"'
21:42 <Shiz> and the relevant .git/config for the aports repo to go with it: https://txt.shiz.me/YmIxMzA3Zj
21:45 dsabogal joined
21:57 <clandmeter> Shiz, what about something like http://tpaste.us/XE9l
21:58 <* Shiz> snorts
21:58 <Shiz> :P
21:58 <Shiz> yeah that also works
21:58 <clandmeter> :)
22:01 <clandmeter> i think we could add something similar to abuild
22:01 <clandmeter> not to abuild itself but the pkg
22:01 <clandmeter> like we did with abump
22:02 <Shiz> arch3y_: i *think* i reviewed them all
22:02 <Shiz> :P
22:02 <arch3y_> Shiz: sure no worries thanks
22:03 <przemoc> clandmeter: re your script: first quoting is superfluous (PR=$1 is good enough, even if there are spaces in $1), yet you forgot to quote $PR in curl line, so it wouldn't work with arg having space. not that it truly matters in this case, because there is almost no chance that arg having space will be provided here, but just a friendly reminder to be careful with variables in shell
22:03 <clandmeter> i bet ncopa has a lot of useful stuff in his /usr/local/bin :)
22:03 <clandmeter> przemoc, yes im aware
22:03 <Shiz> arch3y_: also a general remark: except the one where you added options="!check", please add a check() or an options="!check" (with a comment explaining why)
22:04 <clandmeter> przemoc, pr
22:04 <clandmeter> grr
22:04 <Shiz> (for binaries, even if upstream has no test suite, a simple smoke test in check() { } that verifies if the binaries run is better than nothing)
22:04 <clandmeter> keyboard...
22:04 <przemoc> life...
22:04 <przemoc> I know
22:04 <Shiz> (thanks for contributing! hope i wasn't too hard on ya ;p)
22:07 <Shiz> arch3y_: could you tell me your abuild version?
22:07 <Shiz> it shouldn't be generating md5sum/sha256sums anymore
22:07 <przemoc> possibly straight from 3.5 one
22:12 <przemoc> re checksums: it would be so much nicer if they were always starting in new line (the one with =" would simply have \ at the end), it's aesthetically killing me whenever I see first line of checksums not lining with the rest. diffs would be much nicer then too
22:16 <przemoc> maybe we could introduce such change in next abuild? not sure what others think.
22:17 <przemoc> anyway, it was very short visit, so short that I haven't changed my away status, and it's sleep time, so gn everyone (at least those relatively close to UTC)
22:20 <arch3y_> Shiz: sure can do Im building from edge I think at first I wasnt
22:20 <arch3y_> so that might be why one moment
22:21 <arch3y_> if abuild is part of apk-tools Im on 2.7.1
22:21 <arch3y_> Ill go back and sqaush my commits as well
22:22 <Shiz> it's its own package :P
22:22 <Shiz> but edge vs 3.5 will probably do it
22:22 <arch3y_> yeah I started out on 3.5
22:23 <arch3y_> then I realized I should be on edge
22:23 <arch3y_> so that was my bad
22:23 <arch3y_> got any tips on a good way to sqaush my commits Ive never done that before having to research it
22:27 <Shiz> sure
22:27 <Shiz> sorry, i was reviewing some stuff
22:27 <Shiz> arch3y_: # git rebase -i HEAD~<num of commits to squash>
22:27 <arch3y_> no worries
22:27 <Shiz> then just change the `pick` into `squash` for all commits aexcept the last
22:28 <Shiz> and possibly change `pick` to `reword` for the last if it's needed
22:28 <arch3y_> hmm k Ill give it a shot
22:28 <Shiz> and finally, you need to `git push --force` after that's all done, since you're rewriting history :)
22:28 <Shiz> (which is okay for PRs)
22:28 tmh1999 joined
22:28 <arch3y_> yeah I hate force lol
22:29 <arch3y_> but if you say its ok then its ok
22:29 <Shiz> for PRs it's fine, for actual branches people clone from/use, it's not
22:29 <Shiz> :P
22:34 <arch3y_> yeah make sense it would make ppl fairly upset
22:35 <arch3y_> anything I can do to help my prs go in faster
22:35 blueness joined
22:36 <Shiz> not specifically, we got a bit of a pr backlog
22:36 <Shiz> i'm trying to go through them to at least review stuff
22:36 <arch3y_> gotcha I figured it be bad to just have a bunch of prs in there and have more and more added
22:36 <arch3y_> so I slowed down to keep the log lower then normal
22:39 <Shiz> nah it's fine
22:39 <Shiz> do keep adding things :P
22:40 <arch3y_> ok will do cause I plan on working to get unmaintained cleaned up
22:40 <arch3y_> there is a few things that could be added that could be useful
22:40 <Shiz> :)
22:40 <Shiz> as mentioned in the PRs, be sure to be willing to actually maintain them too :)
22:41 <arch3y_> true thats the goal some of them I did skimp on a bit
22:42 <ncopa> can we wait with adding more stuff til after 3.6 release?
22:43 <arch3y_> yes Im just gonna fix up my prs you dont have to add them
22:43 <Shiz> fine by me, I just reviewed the PRs
22:43 <Shiz> :)
22:43 <Shiz> didn't merge any ones that added stuff
22:43 <ncopa> we can purge stuff thats older than 6months in unmaintained
22:43 <ncopa> im ok with adding stuf that is high prio, critical or that we really want in 3.6 release
22:44 <Shiz> yeah we're in the release cycle now so it's best to wait a bit with adding random things
22:44 <arch3y_> and the stuff Im working on are most certainly random
22:44 <Shiz> but i figure we could at least provide feedback on the PR backlog heh
22:44 <ncopa> what we should do is look over the bugs on bugs.a.o
22:44 <arch3y_> Im just looking for ways to help out anyway I can
22:44 <arch3y_> that is useful it helps keep ppl committing
22:45 <Shiz> ncopa: btw what's the best approach for a PR that affects an arch i can't personally test on?
22:45 <Shiz> (ppc64le)
22:45 <ncopa> probably talk with arch maintainer, for ppc64le its leitao
22:45 <Shiz> i should probably get a b.a.o account
22:45 <ncopa> but
22:45 <algitbot> https://bugs.alpinelinux.org
22:45 <ncopa> yes you should
22:46 <Shiz> wew 911 bugs open
22:46 <ncopa> might be we can get you a container with ppc64le
22:47 <Shiz> it has no super high prio, just a PR i was looking at and wondering to approach
22:47 <Shiz> i'll poke leitao_ to check it next time i see them :p
22:47 <ncopa> there was a bug about installer, that the setup-wifi does not support spaces in ssid
22:47 <ncopa> i was thinking
22:47 <ncopa> what if we could make a prompt with history and tab-completion support?
22:48 <ncopa> using linenoise
22:48 <Shiz> sounds fancy
22:48 <Shiz> i didn't even know we had setup-wifi
22:48 <Shiz> is it new?
22:49 <Shiz> (account made)
22:49 <ncopa> a couple of years old i think
22:49 <Shiz> huh
22:49 <Shiz> well i can't claim to have ever installed alpine on a wifi box :p
22:50 <ncopa> thats why you havent seen it :)
22:50 <ncopa> im happy the installer works as supposed
22:50 <Shiz> i'm not sure if history is needed for SSIDs though
22:50 <ncopa> no, but tab-completion would be nice
22:52 <Shiz> yeah
22:52 <Shiz> especially with my SSID
22:52 <Shiz> https://up.shiz.me/ZDEwMTY1.png
22:52 <Shiz> :p
22:53 <ncopa> lol
22:54 <ncopa> i like the ssid "Connecting..."
22:55 <ncopa> but the idea with tab-completion could also be used for the other questions
22:55 <ncopa> like network interface, eth0... etc
22:55 <ncopa> i was also thinking of chaning the prompt to always be on a new line
22:56 <ncopa> Select which blabla [default]:
22:56 <ncopa> >
22:56 <ncopa> so i was thinking of a general purpose tool for promting for questions
22:57 <nidan_> Is there a way to ask apk for where an installed package came from? Repo or which key has signed it?
22:57 <ncopa> apk policy
22:57 <ncopa> hmm, re xorg
22:58 <ncopa> as i understand the xf86-video-vesa is out nowdays
22:58 <ncopa> better to use xf86-video-modesetting as general purpose driver?
22:58 <ncopa> the xf86-video-input-keyboard and xf86-input-mouse are replaced with xf86-input-evdev
22:58 <nidan_> ncopa: Ok. Hehe, well, I've compiled gcc but didn't rename the package to something other than gcc, so now, after apk fix gcc, I'm not really 100% sure if it's the official alpine package I've got or if it's my own.
22:58 <ncopa> which seems to be replaced with xf86-input-libinput?
22:59 <nidan_> And I'd like to test something before rebuilding the package, it takes a while.
22:59 <ncopa> this should answer your q: apk policy gcc
23:00 <ncopa> so i wonder, what would be the best, general purpose xorg install?
23:00 <Shiz> ncopa: big thing there
23:00 <ncopa> install all of the drivers?
23:00 <Shiz> -evdev NEEDS udev
23:00 <Shiz> -libinput as well right now, i think
23:00 <nidan_> ncopa: I did that, the output is a bit ambigous to me.
23:00 <Shiz> nidan_: could you paste it?
23:01 <ncopa> i think we pull in udev anyway
23:01 <nidan_> Shiz: I can retype it. =)
23:01 <Shiz> ncopa: also re #7271 im thinking of just adding su-exec to depends= and using that
23:01 <algitbot> Bug #7271: Problem with php7-fpm init.d script - Alpine Linux - Alpine Linux Development: http://bugs.alpinelinux.org/issues/7271
23:01 <Shiz> su - is very flaky anyway...
23:01 <ncopa> i mean, we need udev for xorg to have hotplugging work
23:02 <ncopa> otherwise you cannot plug an usb mouse without restarting xorg
23:02 <ncopa> so i think the simple xorg setup should depend on udev
23:02 <ncopa> people who wants set up xorg without will have to do it manually
23:02 <Shiz> ah, you're talking about setup-xorg?
23:02 <ncopa> yes
23:03 <Shiz> right
23:03 <Shiz> yeah then probably
23:03 <Shiz> i think libinput is newer/fancier
23:03 <Shiz> i wouldnt install all video drivers though
23:03 <Shiz> thats a lot of them
23:03 <ncopa> so which should be installed?
23:03 <ncopa> is it enough to install modesetting?
23:03 <Shiz> how about prompting the user after making an initial guess for some common ones?
23:03 <ncopa> i want avoid promting
23:03 <nidan_> Shiz:
23:03 <nidan_> gcc policy:
23:03 <nidan_> 6.3.0-r4:
23:03 <nidan_> lib/apk/db/installed
23:03 <nidan_> /m2/alpine/edge/main
23:03 <Shiz> right
23:03 <nidan_> 6.3.0-r4:
23:04 <nidan_> /home/user/packages/smurf
23:04 <ncopa> nidan_: installed
23:04 <Shiz> nidan_: then it's using the one from your edge repo
23:04 <Shiz> assuming /m2/alpine/edge is like, the alpine repo
23:04 <ncopa> comes from /m2/alpine/edge/main
23:04 <Shiz> the entry that has lib/apk/db/installed is the one that is installed
23:05 <Shiz> s/your/alpine's/g
23:05 <ncopa> the setup-xorg is for like, have a livecd that boots directly into xorg
23:05 <Shiz> i see you have expansion plans? :P
23:05 <nidan_> So, considering that the repos are listed with the smurf repo first in the /etc/apk/repos file - if what you said Shiz is correct, how do I get apk fix to get gcc from the smurf repo?
23:05 <Shiz> nidan_: two options
23:05 <nidan_> Or do I have to apk del gcc ; apk add gcc?
23:05 <Shiz> first, bump your pkgrel in packages you make yourself
23:05 <Shiz> that is the proper option
23:06 <ncopa> apk will pick the newest
23:06 <Shiz> ^
23:06 <ncopa> if they have same version apk will think its same thing
23:06 <Shiz> if you make changes from alpine packages that affect the outcome package, you should bump pkgrel
23:06 <Shiz> pkgrel is how apk differentiates different packages with the same upstream version
23:06 <nidan_> Shiz: ncopa: Yeah, I know, I forgot, rebuilding takes a while and I want to test that compiler sort of now. =)
23:06 <Shiz> nidan_: what you can also do (I think)
23:06 <Shiz> is add a tag to your repos in /etc/apk/repositories
23:06 <Shiz> and do
23:07 <Shiz> apk del gcc && apk add gcc@myrepotag
23:07 <ncopa> alternatively you can add a pinned repo and do apk add gcc@myrepo
23:07 <Shiz> (tag format is just tag http://myrepo instead of http://myrepo)
23:07 <ncopa> :)
23:07 <Shiz> :p
23:07 <nidan_> Ok, I'll test that.
23:07 <ncopa> https://git.alpinelinux.org/cgit/alpine-conf/tree/setup-xorg-base.in
23:07 <nidan_> Thanks a lot, hopefully you've saved me from looking at my scrolling screen for 20 minutes. =)
23:08 <ncopa> i wonder what to install as base packages
23:08 <ncopa> users can always add extra drivers if they want
23:09 <Shiz> i don't think there's a single base package that actually works for most drivers even decently
23:09 <ncopa> modesetting?
23:10 <ncopa> im ok if it works with the 5 most common hw setups
23:10 <ncopa> eg qemu vmware virtualbox intel nvidia amd
23:10 <Shiz> right
23:10 <ncopa> but, as i understand, vesa is no good fallback anymore?
23:11 <ncopa> modesetting worked on my macboot at least
23:11 <ncopa> (i think it maybe made wifi go nuts though)
23:11 <Shiz> lol wat
23:11 <ncopa> i suspect it did
23:11 <Shiz> modesetting is a better fallback IF the gpu supports DRM
23:11 <Shiz> vesa is more generic
23:12 <Shiz> is it possible to prio driver loads?
23:12 <Shiz> if so i'd add both but prio modesetting over vesa
23:12 <ncopa> https://git.alpinelinux.org/cgit/alpine-conf/tree/setup-xorg-base.inv
23:12 <ncopa> its s stupid shells cript
23:12 <Shiz> i mean in xorg itself, rather
23:12 <ncopa> we could look for /dev/dri/card*
23:13 <Shiz> that's a good idea
23:13 <Shiz> is the ps mouse stuff needed?
23:13 <ncopa> that is my question
23:13 <Shiz> or more accurately, do people still use ps mice :p
23:13 <ncopa> i dont think it is
23:14 <ncopa> i think libinput or evdev should be enough?
23:14 <ncopa> i dont know how xorg prio if both are there
23:14 <Shiz> yes
23:14 <Shiz> libinput/evdev should support ps2 stuff
23:14 <nidan_> Shiz: ncopa: Isn't the synaptics touchpads on laptops ps/2?
23:14 <Shiz> the in-kernel mouse stuff is a bit dreadful
23:14 <Shiz> nidan_: no, that's xf86-input-synaptics
23:14 <Shiz> :)
23:14 <nidan_> Sorry, I knew that. =P
23:15 <ncopa> i think libinput replaces synaptics too
23:15 <nidan_> But it's not USB, iirc, it uses the same bus etc, i.e, ps/2. But its own driver, right?
23:15 <ncopa> i replaced synaptics with libinput on my macbook recently to get reverse scrill working
23:15 <ncopa> scroll*
23:16 <ncopa> in not sure
23:19 <Shiz> ah
23:19 <Shiz> yeah i guess libinput is universal
23:19 <Shiz> nidan_: depends on your specific laptop i think
23:19 <Shiz> but i'm sure its ps/2 on some stuff
23:19 <Shiz> but it is its own driver, yeah
23:20 <nidan_> Yay! Glibc compiles with the new gcc. =)
23:20 <Shiz> what did you change?
23:20 <Shiz> ncopa: might be that -synaptics is still needed on older computers
23:21 <Shiz> ncopa: oh:
23:21 <Shiz> "the xf86-input-libinput package, which is "a thin wrapper around libinput and allows for libinput to be used for input devices in X. This driver can be used as as drop-in replacement for evdev and synaptics.""
23:21 <Shiz> seems like all we need is libinput
23:23 <nidan_> Shiz: Disabled a few patches, removed unwanted languages. Removing the unwanted languages was just to save compilation time right now, and I have disabled 5 patches. I'll dig down until I find which one is bugging me (I have my suspicions) and then determine what to do.
23:23 <Shiz> :)
23:27 <Shiz> ugh libinput is balls-deep integrated with udev
23:27 <Shiz> :(
23:31 <nidan_> Why?
23:32 <nidan_> I mean, why integrate them? udev is overengineered as it is with its own rule-parsing syntax etc etc. And all it's supposed to to is run something when the kernel sends hotplug events..
23:32 <nidan_> Why integrate libinput with that?
23:33 <ncopa> libinput probably wants get notified when you plug new device
23:33 <ncopa> eg new usb mouse
23:33 <ncopa> ok, i'll use libinput only for now
23:33 <ncopa> what to do if there are no /dev/dri/card*?
23:33 <ncopa> xf86-video-vesa?
23:34 <nidan_> So, why doesn't libinput just listen to a socket? And udev can write a message there? Or listen to the kernel directly, it's probably easier than interfacing against udev..
23:34 <ncopa> wild guess: so you dont need set up netlink socket yourself
23:34 <nidan_> I'll stop arguing, it's not my code, there are other things to fix. First.
23:34 <ncopa> +1
23:35 <nidan_> =)
23:35 <ncopa> im not saying its a good idea or good design... and tbh, i dont care that much as long as it works :)
23:36 <Shiz> ncopa: yeah vesa
23:36 <Shiz> i'd also add -video-nouvea, -video-amd-gpu and -video-intel
23:36 <Shiz> :)
23:36 <nidan_> I care for one simple reason; code complexity is inverse proportional (probably inverse exponentially proportional) to security. =)
23:36 <ncopa> maybe parse lspci first?
23:36 <Shiz> amdgpu*
23:37 <Shiz> ncopa: i don't think busybox lspci has device names :(
23:37 <ncopa> apk add pciutils
23:37 <nidan_> But I just said I should stop arguing, as I probably just waste your time atm, sorry about that. =)
23:37 <Shiz> ah
23:38 <ncopa> i wonder if its enough to install hwdata-*
23:38 <Shiz> busybox lspci doesn't parse hwdata
23:38 <ncopa> nope
23:39 <ncopa> ok, i think we can apk add pciutils, you proabaly want that on a desktop anyways
23:39 <Shiz> hehe
23:39 <Shiz> i think hwdata-pci is enough on its own
23:39 <Shiz> and that's already a dep of pciutils
23:39 <Shiz> :)
23:40 <Shiz> gotta be careful with detecting intel for obvious reasons...
23:40 blueness joined
23:41 <Shiz> ncopa: lshw might be useful
23:42 <ncopa> *shrug* i dont have it installed on my desktop currently
23:42 <Shiz> or maybe just grepping for VGA output in lspci is enough
23:42 <ncopa> there might be alot of tools that might be useful
23:42 <ncopa> yes, thats what im thinking
23:44 <ncopa> if /dev/dri/card* exists, should we bother look for intel/nvidia/amd?
23:44 <Shiz> yes
23:45 <Shiz> the specific drivers are better than modesetting
23:45 <ncopa> so we add the driver in addition to modesetting?
23:45 <Shiz> modesetting should just be the first fallback after specific drivers
23:45 <ncopa> ok
23:45 <Shiz> imo it would be:
23:45 <Shiz> # specific driver detection
23:46 <Shiz> if test -f /dev/dri/card* ; then fallback=xf86-video-modesetting else fallback=xf86-video-vesa ; fi
23:46 <Shiz> apk add $specific $fallback
23:46 <Shiz> :P
23:47 <ncopa> anyone has nvidia and can give me the `lspci | grep -w VGA` output?
23:48 <ncopa> i also wonder if we should try detect older AMD like r128 etc
23:48 <Shiz> 04:00.0 VGA compatible controller: NVIDIA Corporation G94 [Quadro FX 1800] (rev a1)
23:48 <Shiz> from a random google
23:48 <Shiz> ;)
23:48 <ncopa> ha
23:48 <ncopa> im glad we have smart ppl on the chan :)
23:48 <Shiz> grep -i nvidia should work just fine i think
23:49 <ncopa> its a case "$vgaline" in...
23:49 <Shiz> also keep in mind the following: specific drivers should be able to be multiple ones
23:49 <Shiz> cause there can be multiple vga lines
23:49 <Shiz> (multiple GPUs)
23:51 <ncopa> yup
23:51 <ncopa> and multiple /dev/dri/card*
23:53 <nidan_> Gah! "... must not put anything under ... or /opt" <- What's the rationale?
23:53 <ncopa> http://tpaste.us/ZVm9
23:54 <Shiz> nidan_: /opt is not for distro packages
23:54 <Shiz> thus, abuild packages should not put anything there
23:54 <ncopa> http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s13.html
23:54 <ncopa> apk should not install anything there
23:55 <Klowner> irritating, I had my ram-only install working fine and now it doesn't seem to reinstall any packages on boot :{
23:55 <nidan_> It's the law. =)
23:55 <nidan_> =)
23:55 <Shiz> Klowner: do you have an apkovl?
23:57 <nidan_> if ! options_has "!fhs"; then <- Thank yoooouuu... =D
23:58 <ncopa> ;)
23:58 <ncopa> Klowner might need an apk cache sync