<     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:06 <jirutka> ^7heo: surprisingly only 7 tests on armhf http://build.alpinelinux.org/buildlogs/build-edge-armhf/community/php7/php7-7.1.4-r0.log
00:06 <jirutka> ^7heo: two on ppc64le
00:18 ppisati joined
00:26 <^7heo> jirutka: hmm
00:27 <^7heo> (sleep now)
00:31 <jirutka> 4 on aarch64… it seems to be totally random, I have no clue how the heck these tests can behave differently on another arch
00:33 breno__ joined
00:59 LouisA joined
01:00 <jirutka> omg I’ve started closing php bugs on bugs.a.o… there are so many! vakartel really screwed it :(
01:01 s33se joined
01:59 s33se_ joined
03:57 tmh1999 joined
03:59 TemptorSent joined
04:04 czart_ joined
04:48 tmh1999 joined
05:18 tmh1999 joined
05:23 TemptorSent joined
05:37 tmh1999 joined
05:37 mradi_ joined
05:38 <mradi_> Hi guys, I am trying to get libvirt working with xen, and qemu for a HVM machine.
05:38 <mradi_> I am kinda new to XEN, so trying to use libvirt. But I cannot find the qemu package for xen on the alpine, xen iso or the apk repo's
05:39 <mradi_> can you help me configure libvirt and install qemu for xen
06:07 scadu[m] joined
06:12 scadu[m] left
06:35 cyteen joined
06:43 Stranger joined
06:49 <Shiz> the package names for xen are xen and xen-hypervisor
06:49 <Shiz> http://pkgs.alpinelinux.org/packages?name=xen*&branch=v3.5&repo=&arch=x86_64&maintainer=
06:49 <Shiz> likewise there is the libvirt-xen package: http://pkgs.alpinelinux.org/packages?name=*libvirt*&branch=v3.5&repo=&arch=x86_64&maintainer=
06:55 scadu joined
07:24 xsteadfastx joined
07:45 t0mmy joined
07:46 _0xAX joined
07:58 muh joined
08:02 <fabled> ok
08:02 <fabled> i think gcj/openjdk on 3.6 builders got fixed
08:03 <scadu> fabled: what was the issue?
08:03 <fabled> gcc upgraded/started using libffi, and it needed a patch
08:03 <fabled> the same one we carry already in main/libffi
08:03 <scadu> oh
08:04 <fabled> i think we also have an idea of why Go1.8 failed, need to just figure out how to build it right
08:06 <clandmeter> LuaJIT-2.1.0-beta3 just got released. do we want that in 3.6?
08:06 <scadu> >beta
08:06 <fabled> i think not unless it has some major bug fixes
08:07 <clandmeter> a higher beta is preferable :p
08:07 <fabled> oh, we are at beta already?
08:07 <fabled> then i guess it's possible
08:08 <clandmeter> yes
08:08 <clandmeter> i think because of arch support
08:09 <clandmeter> seems the ppc64 patch needs work to support it.
08:09 __0xAX joined
08:15 blueness joined
08:20 __0xAX joined
08:49 consus joined
09:01 __0xAX joined
09:03 __0xAX joined
09:05 __0xAX joined
09:10 czart joined
09:12 __0xAX joined
09:16 __0xAX joined
09:50 ryanlelek joined
09:54 asonge joined
09:54 starefossen joined
09:54 justincormack_ joined
09:56 flyinprogrammer joined
10:05 LouisA joined
10:14 victorbjelkholm joined
10:14 zoidbergwill joined
10:57 blueness joined
11:11 andypost joined
11:19 leo-unglaub joined
11:34 ralphs_ joined
11:39 fekepp joined
11:46 kaniini1 joined
11:46 <kaniini1> well, that is good.
11:46 <kaniini1> or not.
12:10 <arch3y_> jirutka: do you have a moment?
12:13 farosas joined
12:17 <jirutka> arch3y_: yes
12:20 <arch3y_> jirutka: so from what Im reading on the flex issue
12:20 <arch3y_> is that we might as well build from git master for flex
12:20 <arch3y_> Im not sure if we want to do that or just hold off until the dev releases 2.6.4
12:20 <arch3y_> as so far it hasnt seemed to affect any other compliations
12:21 <jirutka> arch3y_: I didn’t go into detail, what exactly they fixed in master? is it simple fix that we can backport or somethinf more complicated?
12:22 <arch3y_> jirutka: yeah it seems most ppl are building flex from git master to fix it
12:22 <arch3y_> Im not sure thats ideal
12:22 <arch3y_> so my thought is we just wait on that pr until 2.6.4 is released
12:22 <arch3y_> unless you guys have another opinion
12:23 <arch3y_> per the dev this "should" fix it https://github.com/westes/flex/commit/f5d87f1a26f4a5c3402497008ae10e9a1345d327
12:23 <arch3y_> but everyone else has just built flex from git master
12:23 <^7heo> either it does or it does not.
12:23 __0xAX joined
12:23 <^7heo> We do not apply patches that "should"
12:23 <arch3y_> well thats the problem is no one has said specifically what hte fix is
12:24 <arch3y_> I agree
12:24 <arch3y_> 100%
12:24 <^7heo> Yeah then someone has to dig the issue.
12:24 <arch3y_> thats why I think we should hold off
12:24 <^7heo> ^
12:24 <^7heo> that.
12:24 <arch3y_> yeah and there is a big thread on it on the flex devs github
12:24 <arch3y_> but most ppl are waiting for him to release 2.6.4
12:24 <^7heo> yeah because it's easier to have an opinion than to dig what's wrong.
12:24 <arch3y_> true
12:24 <^7heo> whatever, I should fix my SQL atm.
12:24 <^7heo> laters.
12:25 <arch3y_> sure have fun not trying to cause conflict lol
12:25 <^7heo> Well, it's not always fun to write SQL Queries.
12:26 gromero joined
12:26 <arch3y_> that is true
12:32 leitao joined
12:45 <jirutka> arch3y_: well, it says that it fixes regression introduced in 2.6.3, so I think we should apply it anyway and then you can try if it fixed even that soft (don’t remember name)
13:04 BitL0G1c joined
13:07 leo-unglaub joined
13:21 <arch3y_> jirutka: unbound Ill test it
13:59 <^7heo> Also guys
13:59 <^7heo> To keep you posted
13:59 <^7heo> I will probably try to run Alpine on a couple of phones
13:59 <^7heo> by the end of this calendar year.
14:00 <^7heo> It's not 100% certain for now; but the idea is to make a community maintained OS for phones, quite like Sailfish, but without all the crap that is in Sailfish.
14:00 <arch3y_> jirutka: it looks like we are already running the patch for flex on our version of 2.6.3 https://github.com/alpinelinux/aports/commit/cd450195ef3ab3a24d0e005b70d51304e9e18729
14:01 <arch3y_> so yeah hmm I guess we just wait on this push for unbound until 2.6.4 is built
14:01 <arch3y_> cause Im not sure what other pieces need to be patched for flex to work
14:01 <jirutka> ^7heo: phones? that’s awesome!
14:01 <jirutka> ^7heo: please let me know about every progress, I’m very interested in this!
14:08 <consus> Guys
14:08 <consus> Do you have any plans on this http://bugs.alpinelinux.org/issues/6373
14:08 <consus> ?
14:15 <soldF5Nsd1eF> consus: have you considered packaging it yourself?
14:15 <consus> Already
14:16 <soldF5Nsd1eF> and what was the outcome of the consideration?
14:16 <consus> Err
14:16 <consus> I packaged myself one
14:18 <consus> But I have a couple of folks around who are doing the very same thing and there is a bug in the bug queue so it would be nice to have a stock version
14:19 <^7heo> jirutka: well for now it's gonna support a couple of phones
14:20 <consus> ^7heo: Which ones exactly?
14:20 <asie> ^7heo: will musl work well with the bunch of propiertary drivers necessary, though?
14:20 <^7heo> jirutka: namely the fairphone 1 and 2 (1 being a "maybe" since I don't have one), the jolla (the original one, couldn't find a jolla C), and maybe the new sony xperia.
14:20 <^7heo> asie: that's gonna be the fun part.
14:20 <asie> wish i could afford a fairphone
14:20 <asie> right now i'm running on some terrible, terrible huawei
14:20 <^7heo> Well
14:20 <^7heo> it's out of stock atm.
14:20 <^7heo> I ordered one on feb
14:20 <asie> yeah, i know
14:20 <^7heo> I'll get it in setp.
14:20 <^7heo> sept*
14:21 <^7heo> fortunately I'll pay on delivery
14:21 <^7heo> so... for now, no cash out.
14:21 <consus> asie: Heh, I have a huawei on my hands. It's not that terrible =/
14:21 <asie> consus: i tried to get cyanogenmod running on it
14:21 <asie> ahahahahahahahahahaha
14:21 <consus> Oh
14:21 <^7heo> asie: also, the main problem with the current smartphones isn't the hardware...
14:21 <^7heo> asie: it's the software.
14:21 <consus> Nah, I'm fine with the default one
14:21 <^7heo> asie: as you just said.
14:21 <asie> i asked the previous maintainer for huawei on cyanogenmod what is the problem
14:21 <asie> and he kindly explained to me that he refuses to deal with huawei phones ever agian
14:22 <^7heo> fair
14:22 <asie> it's fair and i realized just how big the mess is
14:22 <^7heo> I don't think Huawei would be either doing things right or caring about small time devs
14:22 <asie> but someone got it to run
14:22 <asie> and they also fixed huawei's messed up gps code!?
14:23 <^7heo> yeah well
14:23 <^7heo> the thing with the models we selected is that there are drivers for the devices
14:23 <asie> yeah
14:23 <^7heo> and they are available quite handily.
14:23 <asie> the primary problem is the GPU, no?
14:23 <^7heo> I do hope they work on fairly generic versions of the kernels
14:23 <^7heo> not on very precise versions.
14:23 <asie> yeah... generic version of the kernel and huawei.
14:24 <^7heo> and let's see about "grsec" or whatever it's called by the end of the year.
14:24 <asie> huawei's kernel fork is interesting
14:24 <^7heo> also I'll try to run it on the asus KL 550 ZC
14:24 <^7heo> because they provide the sources for ASOP
14:24 <^7heo> should be possible to at least try something.
14:24 <asie> i suppose the cyanogenmod/lineage ports are userland-only
14:25 <^7heo> sorry, ZC550KL
14:25 <asie> that is, the android libs and kernel are all huawei
14:25 <asie> and only the apks got replaced
14:25 fabled joined
14:25 <^7heo> yeah it's fair to assume that.
14:25 <^7heo> That's why I would like to try stuff on the ZC550KL
14:25 <^7heo> (and because I own one)
14:26 <^7heo> But aside from the GPU, there's a couple of things to manage...
14:26 <^7heo> especially the phone capabilities.
14:26 <^7heo> (because it'd suck to have a phone that can't phone)
14:27 <asie> oh of course it is
14:27 <asie> not as bad as i expected, but it's still a crazy glued together thing
14:28 <clandmeter> good luck with the RIL
14:28 <^7heo> clandmeter: it's more or less "good luck with everything" at this point.
14:29 <^7heo> clandmeter: but I'm not alone on this; there's a dude who ported NetBSD to the N900 that is interested in participating AFAICT
14:29 <clandmeter> ril camera and sensors will be a giant headache from what i read about it.
14:30 <^7heo> clandmeter: and also, we can always ask questions on jolla/sailfish IRC channels.
14:30 HEROnymous joined
14:31 <HEROnymous> hey guys, we're trying to install alpine under hyper-v. vanilla worked, but it's running in ram, how do we get it to install to the disk instead of just running live ?
14:31 <^7heo> clandmeter: but yeah you're right; I do not expect RIL, and phone to be a walk in the park.
14:31 <^7heo> moin HEROnymous
14:31 <clandmeter> setup-alpine
14:31 <^7heo> I wonder why Hyper-V can't work grsec...
14:31 <HEROnymous> thanks :)
14:31 <^7heo> s/work/run/
14:32 <HEROnymous> I'm not sure, I tried getting the vm and std images to boot, bart got the vanilla one to boot
14:32 <^7heo> well, that's at least something.
14:32 <^7heo> We can work with the vanilla ;)
14:32 <^7heo> it's not ideal but with the grsec batonning coming up...
14:32 <^7heo> I guess it's not such an issue anyway.
14:32 <clandmeter> i remember there is some information on the grsec forums about hyperv
14:33 <HEROnymous> yeah if you guys wanna try and get stuff rolling on hyper-v I am down to help some time getting it to boot. are you sure it's a grsec issue ?
14:33 <clandmeter> it just weird the virt kernel doesnt work
14:33 <clandmeter> 90% sure :)
14:33 <HEROnymous> yeah, I tried it on my personal box too, same results as on the production machine, so it's not something specific to one host
14:34 <^7heo> HEROnymous: your personal box runs on HyperV?
14:35 <HEROnymous> yeah... well, I have a lot of personal stuff, lol
14:35 <clandmeter> something must be missing in the virt kernel, i didnt have time yet to try it.
14:36 <HEROnymous> ^7heo, that's out at one of our data centers, I also have quite a bit of stuff here at my house too, hahah
14:36 <HEROnymous> clandmeter, lemme know if I can be of assistance
14:37 <clandmeter> which version of hyper-v are you running?
14:37 <HEROnymous> 2016
14:37 <clandmeter> is that the same core as recent win10?
14:38 <HEROnymous> not sure, I don't really know much about windows desktop systems, but I would suspect so?
14:38 <HEROnymous> same release timeframe and stuff
14:38 <clandmeter> so linux on desktop and windows on servers?
14:38 <^7heo> HEROnymous: I wouldn't run HyperV. My experience with Xen was really great.
14:38 <^7heo> HEROnymous: and also, if not Xen, I'd look at intel Nova.
14:38 <TBB> finally, the year of linux on the desktop!
14:39 <clandmeter> :)
14:39 <^7heo> TBB: ?
14:39 <HEROnymous> clandmeter, personally, I run linux on my desktop and most of my servers, cept for windows server 2016 with hyper-v as a virt stack ;)
14:39 <^7heo> Ah ok I finally catched up with the log.
14:39 <^7heo> sorry TBB, my bad.
14:40 <TBB> no worries; you might have also noticed that the "linux sucks" guy also stopped doing his annual "linux sucks" videos and talks
14:40 <TBB> so we must be getting close :D
14:40 <^7heo> What guy?
14:40 <HEROnymous> ^7heo, we tried xenserver, ran into some annoying storage issues. hyper-v is actually pretty awesome in terms of ease of configurability and stuff too, there's a lot of basic stuff that's very simple vs. very complicated with xen or kvm, and powershell is pretty slick too
14:40 <^7heo> He sucks if he says "Linux sucks" and not "GNU/Linux sucks"
14:40 <^7heo> unless he ACTUALLY criticizes the kernel ONLY.
14:40 <HEROnymous> TBB, I've been running linux as my main workstation since 2007... and before that, it was Solaris on Sun hw. ;)
14:40 <^7heo> HEROnymous: I dunno, I'm microsoft allergic.
14:41 <TBB> ^7heo: can't remember his name but he's done an annual talk on the subject since the late 2008's
14:41 <^7heo> HEROnymous: aside from gaming, but that's a different machine.
14:41 <HEROnymous> ^7heo, eh, I was when they mostly sucked. they actually have some good tech nowadays.
14:42 <HEROnymous> microsoft has actually done a few really good things in the past few years - hyper-v, powershell, and C# are all pretty good, they've dramatically improved some of the areas (like security fixes) that they were notoriously terrible about prior to the 2008 era, etc etc.
14:42 <TBB> Bryan Lunduke
14:42 <^7heo> HEROnymous: I do not agree. They rely way too much on people blindly adopting their tech without any understanding; and not checking what else exists and how better it may be.
14:42 <^7heo> HEROnymous: in short, they rely way too much on their monopole.
14:42 <HEROnymous> ^7heo, ehhh, you can't blame microsoft for their customers being educated or not. :)
14:42 <^7heo> Yes you can.
14:42 <fcolista> we have a regression bug for python3
14:43 <fcolista> https://github.com/GNS3/gns3-gui/issues/1392
14:43 <^7heo> fcolista: ?
14:43 <HEROnymous> nahhh not me :)
14:43 <^7heo> HEROnymous: handholding *is* harmful.
14:43 <^7heo> HEROnymous: and to add insult to injury, lack of proper readable documentation, and artificial difficulty of interoperability is not helping people to educate themselves.
14:44 <HEROnymous> ^7heo, I mean, if you've run windows servers in any serious capacity, I don't think you'd say there's hand holding really. you basically need to know the (powershell) cmdline as much for windows administration these days as you do for linux administration
14:44 <^7heo> HEROnymous: there is.
14:44 <^7heo> HEROnymous: take their DNS for instance.
14:44 <^7heo> HEROnymous: there is NO way to actually know how the stuff works
14:44 <^7heo> HEROnymous: and what upstream server it is going to take as source.
14:44 sigtrm joined
14:45 <^7heo> HEROnymous: you can disble round robin, but even then it still behaves randomly at times.
14:45 <^7heo> and that's just one example.
14:45 <^7heo> even Bind9, which is quite bloated and sucky, behaves orders of magnitude more reliably.
14:45 <^7heo> several orders of magnitude.
14:45 <^7heo> several dozen orders of magnitude even.
14:45 <HEROnymous> not sure on that, I've never used windows for dns
14:46 <^7heo> Well we do here, and it's a freaking mess.
14:46 ryanlelek joined
14:46 nlf joined
14:46 <^7heo> HEROnymous: long story short, DNS is randomly working.
14:46 poptart joined
14:46 <^7heo> HEROnymous: word is: when it doesn't work, take a coffee break.
14:46 <TBB> HEROnymous: I've been actively on Linux since 2001 I think, but while I've managed just fine, Lunduke does have some good points, points that mainly rise from lack of co-ordination, etc. Linux is not perfect for the desktop but I'll still rather choose it over the competition
14:46 <HEROnymous> honestly, I once looked through every dns server out there and decided if I wanted something that worked the way I wanted, I'd have to write it myself, and that's a crazy undertaking.
14:46 <^7heo> TBB: depends what competition.
14:47 <skarnet> someone didn't check djbdns
14:47 <^7heo> TBB: unless explicitely needed, I would rather use a BSD
14:47 <HEROnymous> TBB, I think my first linux kernel was... just before 2.0.32 went live... but I was doing other unix stuff before I touched linux.
14:47 <^7heo> skarnet: what do you mean?
14:47 asonge joined
14:47 <skarnet> "every dns server out there"
14:47 <^7heo> ah that.
14:47 <^7heo> yeah,
14:47 <skarnet> I'm noping that./
14:47 <HEROnymous> TBB, but be careful what you wish for - Redhat saw "lack of cooperation" and declared themselves final arbiter of everything. ;)
14:47 <fcolista> ^7heo:
14:47 <fcolista> python3
14:47 <fcolista> Python 3.6.1 (default, Apr 18 2017, 22:11:55)
14:47 <fcolista> [GCC 6.3.0] on linux
14:47 <fcolista> Type "help", "copyright", "credits" or "license" for more information.
14:47 <fcolista> >>> import os
14:47 <fcolista> >>> os.listxattr
14:47 zoidbergwill joined
14:47 <fcolista> Traceback (most recent call last):
14:47 <fcolista> File "<stdin>", line 1, in <module>
14:47 <fcolista> AttributeError: module 'os' has no attribute 'listxattr'
14:47 <fcolista> >>>
14:47 <fcolista> listxattrs is glibc-only
14:48 <^7heo> fcolista: we should try to pastebin whenever possible.
14:48 <TBB> HEROnymous: yeh, we all know how that Red Hat decision went for all of us :D
14:48 <HEROnymous> skarnet, what about djbdns? I've certainly read up on it.
14:48 <^7heo> fcolista: or is that the service powering tpaste.us? :D
14:48 <skarnet> so it's not working the way you want it to? ok.
14:48 <TBB> I used to be a FreeBSD user before switching to Linux tho
14:48 <HEROnymous> TBB, FreeBSD is great, they just don't have the man power to keep up as a mainstream workstation system :(
14:48 <^7heo> fcolista: and also that is weird.
14:48 <^7heo> fcolista: lemme upgrade my python3
14:49 <HEROnymous> but it occupies a niche now, very successfully, as a base for things like pfsense and freenas as well, which works well
14:49 <^7heo> And netflix.
14:49 <^7heo> (just saying)
14:49 <^7heo> (and parts of MacOS X)
14:50 jlyo joined
14:50 starefossen joined
14:50 flyinprogrammer joined
14:51 <^7heo> freaking debian.
14:51 <fcolista> ^7heo, correct
14:51 <^7heo> it uses python2 by default.
14:51 <fcolista> MacOS x
14:51 <HEROnymous> ^7heo, my experiences with debian have always been pretty meh, tbh
14:51 <^7heo> Anyhow, fcolista, do you know when it regressed?
14:52 <^7heo> HEROnymous: I had a love hate relationship with debian for about 10 years.
14:52 <^7heo> HEROnymous: then they decided to use systemd by default.
14:52 <fcolista> ^7heo, i bet when we upgraded python3 from 3.5 to 3.6
14:52 <^7heo> fcolista: that's a safe bet to go for ;)
14:53 <fcolista> ncopa: http://sprunge.us/hgdB
14:53 <fcolista> what to you think?
14:53 <HEROnymous> ^7heo, my biggest issue with debian the last time I tried it was that their openssl used a slimmed-down set of ciphers, and getting a replacement up and running was a huge hassle for some reason.
14:53 <^7heo> yeah well that's *one* of the problems with debian.
14:53 <^7heo> mostly that they are the textbook case of what's wrong with communities.
14:53 <HEROnymous> I don't have anything against systemd in and of itself, but the whole "redhat as god and overlord" thing may not be the best idea overall.
14:54 <^7heo> if there's ONE term I'd use to describe debian it's: vogon-influenced-waterfall-designed-administrative-OS
14:55 <^7heo> fcolista: duckduckgo fails to return a proper documentation for listxattrs
14:55 <^7heo> fcolista: any link?
14:55 <fcolista> the link I've sent before ^7heo
14:55 <clandmeter> fcolista, didnt we discuss this issue before?
14:55 <fcolista> clandmeter, yeah
14:55 <fcolista> that was your finding
14:56 <^7heo> fcolista: got it
14:56 <fcolista> we applied a patch for that
14:56 <clandmeter> ah ok
14:56 <clandmeter> i dont remember anymore
14:56 <fcolista> that i think it *gone* when we upgraded python3
14:56 <clandmeter> somebody didnt take the patch from 3.5?
14:57 <fcolista> git show c7c2150bfaf547c391ac623bb188fca98faff87e
14:57 <^7heo> fcolista: it's a buildtime regression
14:57 <^7heo> fcolista: not a runtime regression
14:57 <^7heo> fcolista: should be fairly easy to fix, especially since we already have a fix.
14:58 <fcolista> ^7heo: <fcolista> ncopa: http://sprunge.us/hgdB
14:58 <^7heo> yeah scadu broke it.
14:58 <^7heo> :D
14:58 <clandmeter> fcolista, ncopa is not around atm
14:58 <fcolista> if you agree, i'll push the patch
14:58 victorbjelkholm joined
14:58 <^7heo> fcolista: does that fix it?
14:58 <fcolista> we're close to AL 3.6
14:59 <fcolista> but i want this fixed before the 3.6 release
14:59 <^7heo> fcolista: 1. does it fix it?
14:59 <^7heo> fcolista: 2. is fix-xattrs-glibc.patch the same patch as issue-27955.patch previously?
15:00 <clandmeter> yes please show that patch
15:00 <clandmeter> i didnt see any ref to xattrs
15:01 <fcolista> clandmeter, no it's not
15:01 <fcolista> that patch is related to py-random
15:01 <fcolista> patch i sent fixes the issue though
15:01 <^7heo> wait how?
15:01 <consus> Folks
15:01 <clandmeter> fcolista, you didnt paste it
15:01 <consus> I want to add mentions of the 'docs' package to the wiki
15:01 <^7heo> clandmeter: I think he means the patch to APKBUILD.
15:01 <fcolista> clandmeter, I pasted two times :)
15:01 <consus> In the FAQ section
15:01 <fcolista> fcolista> ^7heo: <fcolista> ncopa: http://sprunge.us/hgdB
15:02 <fcolista> clandmeter, ^
15:02 <^7heo> yeah that one.
15:02 <clandmeter> fcolista no you didnt
15:02 <^7heo> How can it even fix the issue?
15:02 <clandmeter> :p
15:02 <^7heo> clandmeter: yeah he did ;)
15:02 <consus> Should I leave the whole 'apk add man, apk add mdocml' or screw that and apk add docs?
15:02 <fcolista> clandmeter, you're right
15:02 <clandmeter> it doesnt have the patch
15:02 <fcolista> http://sprunge.us/abNd
15:02 <clandmeter> stop telling me my glasses are broken!
15:02 <^7heo> ah thanks
15:02 <clandmeter> :p
15:02 <^7heo> Now I can see how it fixes it.
15:02 <fcolista> I didn't added the patch
15:03 <clandmeter> ah that one
15:03 <fcolista> yes
15:03 <clandmeter> yes thats sane
15:03 <^7heo> how come upstream isn't already doing that?
15:03 <scadu> fffuu
15:03 <fcolista> heh
15:03 <^7heo> scadu: mmmmmyes?
15:04 <fcolista> ppl thinks that linux == glibc and systemd nowadays
15:04 <^7heo> yeah I know.
15:04 <^7heo> makes me wanna nuke the planet.
15:04 <fcolista> anyway
15:04 <fcolista> if you agree i'll push the change
15:04 <fcolista> *patch
15:04 <clandmeter> go ahead
15:04 <^7heo> fcolista: so I take that http://sprunge.us/abNd is fix-xattrs-glibc.patch ?
15:04 <^7heo> wait, fcolista, can you please NOT change the || return 1 ?
15:04 <HEROnymous> fcolista, hey let's of people think linux is gnome too ;>
15:05 <^7heo> we should really limit the changes to the strict minimum
15:05 <HEROnymous> err lots
15:05 <fcolista> ^7heo, yes that's the patch
15:05 <^7heo> HEROnymous: or rather fd.o
15:05 <fcolista> why don't remove the || return 1?
15:05 <scadu> doh, why I have removed this patch :x
15:05 <^7heo> to keep the changes minimal.
15:05 <^7heo> scadu: because it was named after a gh issue and not about what it was doing.
15:05 <^7heo> scadu: so you wanted to clean up.
15:05 <^7heo> scadu: understandably.
15:05 <^7heo> fcolista: we're close to release, it would be great to keep the diffs very short.
15:06 <^7heo> fcolista: just in case we have to grep through `git log -p $SHA..`
15:06 <fcolista> ^7heo, we have several pacakges with || return 1 removed...but if this makes you happier..
15:06 <scadu> ^7heo: yeah, well, it looked useless at the some, but now turned out it's not :s
15:07 <^7heo> fcolista: I know, and it is best to remove them; but after we get 3.6 out.
15:07 <^7heo> fcolista: at least IMHO.
15:07 <fcolista> I don't think, since 3.6 already implement "set -e"
15:07 <fcolista> and that's why we are removing it
15:07 <^7heo> I know
15:07 <^7heo> I know.
15:07 <fcolista> so?
15:07 <^7heo> that's not the reason why I'm telling not to change anything.
15:07 <^7heo> the reason is: keep the diff minimal.
15:08 <clandmeter> i think ncopa also asked to keep the return 1 untill after 3.6
15:08 <^7heo> at the moment we should really only change only what's really really critical.
15:08 <^7heo> like a regression.
15:08 <^7heo> (nice spotting btw)
15:08 <clandmeter> but its just mine things, not enough to discuss 5 minutes.
15:08 <clandmeter> minor..
15:08 <^7heo> yeah
15:08 <^7heo> however, still IMHO, keeping the diff minimal is worth discussing 5 minutes.
15:09 <^7heo> we might have to end up grepping the tree for crap very close to release.
15:09 <^7heo> or read the diffs without knowing exactly what we are searching for
15:09 <^7heo> in worst case scenario
15:09 <fcolista> guys, no problem for me
15:09 <^7heo> and that's orders of magnitude longer than 5 minutes.
15:09 <^7heo> (or even 10)
15:09 <^7heo> fcolista: long story short, I'd advise keeping it in a branch for now; and comitting the day 3.6 gets out
15:10 <^7heo> Just to keep things safe before push to prod.
15:10 <fcolista> ^7heo, so:
15:10 <fcolista> i just add the patch
15:10 <fcolista> and bump pkgrel
15:10 <fcolista> nothing more
15:10 <^7heo> yeah please, I'd love to get that fixed.
15:10 <fcolista> sounds ok?
15:10 <^7heo> yeah.
15:11 <clandmeter> crap, have to reboot to be able to use hyperv...
15:11 <^7heo> sounds perfect.
15:11 <fcolista> ok good
15:11 <^7heo> (not for you clandmeter)
15:11 <fcolista> and i've alos upgraded gns3 to version 2 :-)
15:11 <clandmeter> i have no idea what it is :)
15:12 <^7heo> fcolista: it's in community, and it won't be cooked in the images, will it?
15:13 <^7heo> (I mean I don't think we have a single image that contains a full featured network sim)
15:13 <^7heo> clandmeter: it's a network sim.
15:13 <^7heo> clandmeter: it's pretty neat.
15:14 <fcolista> ^7heo, right
15:14 <^7heo> fcolista: yeah so if it's broken on release day, it's gonna be fast to fix.
15:14 <^7heo> fcolista: so it's not THAT critical.
15:15 <fcolista> https://hg.python.org/cpython/rev/33f7044b5682
15:15 <^7heo> (plus it won't prevent 3.6 from being installed anywhere)
15:15 <fcolista> it's from 2011
15:15 <fcolista> it's a regression
15:15 <^7heo> ah
15:16 <^7heo> "use glibc instead of a small separate lib" sounds a bit like "let's stuff systemd with all the things"
15:18 <fcolista> something like...
15:18 <fcolista> :D
15:20 <consus> Dammit
15:20 <consus> I just edited the wiki page
15:20 <consus> >
15:20 <consus> > Your username or IP address has been blocked.
15:20 <consus> Why? :(
15:20 <consus> > Automatically blocked by abuse filter. Description of matched rule: New users are not allowed to add ip addresses and phone numbers.
15:20 <consus> I did not!
15:21 trn joined
15:22 <consus> Page: https://wiki.alpinelinux.org/wiki/Alpine_Linux:FAQ#Why_don.27t_I_have_man_pages_or_where_is_the_.27man.27_command.3F
15:22 <consus> Changes: https://paste.pound-python.org/show/TSQocqhTLd6yLUmXUWBc/
15:23 <HEROnymous> brutal
15:23 <consus> Well I do remember the gentoo experience
15:24 <consus> But that's even more funnier :D
15:24 <clandmeter> isnt the {{pkg| an alias to an url
15:24 <consus> Yes, I guess so
15:24 <clandmeter> see
15:24 <consus> Err
15:24 <clandmeter> its outsmarting you
15:24 <consus> It says ip addresses
15:25 <clandmeter> consus, did you create your acc just recently?
15:25 <consus> Yes
15:25 <consus> Several minutes ago
15:25 <clandmeter> thats the issue
15:25 <clandmeter> the limit is for a few hours i believe
15:25 scadu left
15:25 <consus> Uhm
15:25 <consus> Can we state this somewhere?
15:25 <^7heo> clandmeter: good move to tell unknown people how long they have to wait to bypass the securities.
15:25 <clandmeter> thats the reason its not added
15:26 <consus> Err
15:26 <^7heo> clandmeter: especially in a logged channel
15:26 <^7heo> clandmeter: now it is.
15:26 <consus> Well
15:26 <^7heo> clandmeter: this is logged and indexed by search engines...
15:26 scadu joined
15:26 <^7heo> gg...
15:26 <clandmeter> lol
15:26 <consus> This is weird you know
15:26 <consus> I've registered to fix the wiki
15:26 <consus> And now I'm banned for it
15:26 <consus> That's a major drawback for the contributors, nah?
15:26 <clandmeter> consus, i know.
15:26 <clandmeter> and i would change it if i can.
15:26 <^7heo> THe wiki is a major drawback anyway.
15:27 <^7heo> we need something markdown based.
15:27 <consus> Okay, could you at least unlock my account?
15:27 <^7heo> and there's something in the works so...
15:27 <clandmeter> what is your acc?
15:27 <clandmeter> i can unlock it
15:27 <consus> consus
15:27 scadu joined
15:27 <clandmeter> i think
15:27 <consus> :D
15:27 <clandmeter> cause the interface is crap
15:27 <HEROnymous> ^7heo, let us know if you need hosting for stuff
15:27 <^7heo> HEROnymous: thanks; but atm we have all we need in terms of hosting for the doc
15:27 <^7heo> HEROnymous: we need better *software* tho ;)
15:28 <consus> Hm
15:28 <consus> Is wiki even alive?
15:28 <HEROnymous> don't we all...
15:28 <^7heo> Indeed.
15:28 <HEROnymous> web software is... an area that gets a lot of attention, but not a lot of competent attention :P
15:28 <^7heo> s/web //
15:29 <consus> So there will be md-based documentation soon?
15:29 <clandmeter> sigh
15:29 <^7heo> consus: https://github.com/adocs/adocs
15:29 <clandmeter> i think it worked
15:29 <clandmeter> try it
15:29 scadu joined
15:29 <HEROnymous> ehh, I feel like there's a lot of pretty good open source software out there. and the quality level is generally much higher overall than web software overall.
15:29 <^7heo> consus: still missing an automatic replication from the wiki atm.
15:29 <^7heo> consus: if you feel like writing somthing useful.
15:30 <^7heo> (and that's not md, it's asciidoc, but it's close enough; and some of us prefer that)
15:30 <consus> So you want to host the docs at gheyhub?
15:30 <^7heo> There's no long term plan of hosting the docs on github.
15:30 <clandmeter> i made some steps on docs
15:30 <^7heo> We just need something that knows how to convert md/adoc to html.
15:30 <clandmeter> not sure its ok
15:30 <^7heo> and gh does it for now.
15:30 <clandmeter> did you try it ^7heo?
15:31 <^7heo> clandmeter: try what?
15:31 <consus> Okay
15:31 <clandmeter> the uri i gave you last time
15:31 <^7heo> yeah I tried
15:31 <clandmeter> its git based
15:31 <^7heo> it seemed to work.
15:31 <consus> clandmeter: Do you have a link to it?
15:31 <clandmeter> same as https://wiki.somasis.com/Home
15:32 <clandmeter> consus, its currently open for modifications
15:32 <^7heo> clandmeter: yeah but can it be modified via the web interface?
15:32 <clandmeter> i need to disable that and sync it to a public repo
15:32 <^7heo> clandmeter: because that was the main issue.
15:32 <consus> The font is goddamn large
15:32 <^7heo> clandmeter: that's why we're using github atm for adocs/adocs
15:32 <^7heo> clandmeter: because it's allowing for web based edits too.
15:32 <clandmeter> you can use github
15:32 <clandmeter> it can edit
15:32 <^7heo> Yeah I see.
15:33 <^7heo> so basically that solution would be to host it ourselves
15:33 <^7heo> and use github mostly for the web edits
15:33 <^7heo> and PRs
15:33 <^7heo> like we do with aports?
15:33 <clandmeter> yes
15:33 <^7heo> works for me ;)
15:33 <^7heo> I like the idea.
15:33 <consus> clandmeter: Could you make the font smaller? It's *huge*.
15:33 <clandmeter> which?
15:33 <consus> The headers
15:33 <clandmeter> thats not my site
15:34 <consus> Oh
15:34 <consus> Okay
15:34 <consus> It's like reading the docs in Confluence
15:34 <clandmeter> but yes, its the same on my instance
15:35 <^7heo> clandmeter: it's not that huge; and one can easily unzoom.
15:35 <^7heo> clandmeter: also, on your instance, there is an edit function
15:35 <^7heo> clandmeter: that would work for web edit, wouldn't it?
15:35 <clandmeter> maybe
15:35 <clandmeter> but you need to add auth
15:35 <^7heo> I could do that.
15:36 <^7heo> what language is it in?
15:37 <clandmeter> https://github.com/gollum/gollum
15:41 <^7heo> thanks.
15:52 <jirutka> ^7heo: once again here, Markdown is really not sufficient for our documentation, b/c it’s very limited and not extendable, we definitely should use semantic markup, e.g. have macro for commands, so we can easily find where is particular command used to update relevant places when there’s some change; this can be very easily done in AsciiDoc (with Asciidoctor)
16:01 TemptorSent joined
16:02 Mr_H joined
16:03 <^7heo> jirutka: the current gh adoc is using adoc format.
16:03 <jirutka> +1
16:03 <^7heo> jirutka: adoc/adoc == alpine docs / asciidoc
16:04 <^7heo> jirutka: I've invited you there.
16:04 <scadu> ^7heo: lul, I got confused. I wouldn't understand if I didn't know that gh uses asciidoc :P
16:04 <^7heo> scadu: I know, it's a little punny.
16:04 <^7heo> and puny to.
16:04 <^7heo> too*
16:05 <pickfire> I prefer cmark
16:05 <^7heo> I came up with my own document description language
16:05 <jirutka> CommonMark?
16:05 <^7heo> the pdoc
16:05 <jirutka> pickfire: ^
16:05 <pickfire> jirutka: Yes
16:06 <jirutka> pickfire: it’s Markdown, just sensible standardized, so the same problem
16:06 <pickfire> jirutka: What do you need?
16:06 <^7heo> jirutka: +1
16:06 <jirutka> I’ve already written that
16:06 <^7heo> jirutka: I like markdown for it's bare syntax
16:06 <pickfire> Then latex?
16:06 <jirutka> no
16:06 <^7heo> no please no.
16:07 <^7heo> We need to have doc, not one page of doc in 3 years.
16:07 <pickfire> asciidoc is fat, as well as latex
16:07 <jirutka> wtf? XD
16:07 <pickfire> But latex is more suited to fat document
16:07 <jirutka> AsciiDoc and LaTeX have almost nothing in common XD
16:07 <^7heo> pickfire: you're comparing apples and High Fructose Corn Syrup respectively.
16:07 <jirutka> exactly
16:07 <^7heo> jirutka: wrong, they support UTF-8
16:07 <pickfire> Night, need to sleep, going out early in the morning.
16:07 <pickfire> Lol
16:07 <^7heo> jirutka: also they use ascii as a base.
16:08 <jirutka> right :)
16:08 <pickfire> > High Fructose Corn Syrup
16:08 <^7heo> pickfire: o/
16:08 <jirutka> I don’t have time for this discussion atm, need to work :)
16:08 <^7heo> same.
16:08 <^7heo> But adoc == sensible choice.
16:08 <^7heo> also jirutka please check your mails quickly, you've got two invites.
16:09 <^7heo> jirutka: great ;)
16:16 TemptorSent joined
16:17 <^7heo> moin TemptorSent
16:18 <TemptorSent> 'morning -- network just came back up briefly, probably won't stay that way long.
16:21 blueness joined
17:04 <ncopa> was there a discussion about /var/mail the other day?
17:04 <ncopa> what was the conclusion?
17:06 <skarnet> what do you think? the conclusion was that FHS sucks
17:06 <^7heo> :D
17:09 <TemptorSent> Exactly skarnet.
17:11 <TemptorSent> ncopa: The conclusion was that /var/mail can not be properly secured and work with mailers running with reduced privs at the same time.
17:12 <skarnet> ^
17:12 <jirutka> ncopa: we know that at least Gentoo and CentOS symlinks /var/mail → /var/spool/mail
17:12 <jirutka> ncopa: the discussion was quite long and after first flame there were good technical arguments, so I’d recommend to read it and make a decision based on it ;)
17:12 <skarnet> actionable item: check all the MDAs packaged by Alpine and make them deliver mail into users' homedir, for /etc/passwd users
17:13 <skarnet> for virtual users, nobody gives a sh*t where the database is stored
17:13 <skarnet> and /var/mail works as well as anything else (but not /var/spool/mail)
17:13 <TemptorSent> And personally, I dislike the symlink as there is somewhat of a semantic distinction between the delivery spool and the user mailboxes, but it's not really enforced by most MTA/MDAs it seems these days.
17:13 <jirutka> skarnet: I don’t remember details, but IIRC this was not the result of the discussion…
17:13 <skarnet> I recommend /var/lib/$MDA/something though, since the virtual user database is MDA-specific
17:14 <jirutka> skarnet: that it *cannot* be reasonably secured
17:14 <skarnet> jirutka: read it again
17:14 <jirutka> skarnet: donjt have time right now
17:14 <skarnet> then you don't have time to contradict me either
17:14 <jirutka> skarnet: and also this is IMO up to ncopa to decide, b/c there’s no clear winner
17:15 <skarnet> of course it's up to ncopa to decide, but there's a clear winner and it's not anything in /var
17:15 <TemptorSent> skarnet: I would agree that it should be handled per MDA (or at least per mailbox format), as having mixed content in /var/mail could lead to a real mess.
17:15 <jirutka> skarnet: there’s big IF you can configure all mailing clients in aports to adhere to your scheme
17:16 <skarnet> that's not my scheme
17:16 <skarnet> that's a scheme implemented by reasonable MUAs and MDAs since the 90s
17:18 <skarnet> but you're right, a pass on MUAs would also be necessary
17:18 <TemptorSent> If a secure configuration is impossible with a given agent, I'd suggest it be dropped to unmaintained or patched, as proper security is what Alpine hangs it's hat on.
17:19 <skarnet> I was going to suggest that, but the question becomes "and who's going to do the patching?" and I can already see fingers pointing at me
17:20 <TemptorSent> skarnet: If someone is attached to a piece of software with crappy semantics, let them fix it or put up a bounty.
17:20 <skarnet> that's not Alpine ethics
17:20 <^7heo> not?
17:21 <^7heo> (I'm naively asking, not trolling)
17:21 <^7heo> I would expect it to be.
17:21 <TemptorSent> Hmm, it's a conflict of Alpine ethics it seems -- Security on one hand and not breaking existing on the other.
17:21 <jirutka> if we remove all shitty software from aports, then we would end up with quite few packages and I’d suggest to remove PHP and Go first :P
17:21 <^7heo> TemptorSent: careful, you start sounding like OpenBSD, you're gonna trigger skarnet
17:21 <* ^7heo> hides
17:21 <TemptorSent> *LOL*
17:22 <^7heo> (sorry skarnet)
17:22 <TemptorSent> jirutka: I'm all for it ;)
17:22 <jirutka> I’m just trying to say that skarnet’s hardline approach is not helping here very much :/
17:22 <TemptorSent> They can live in the 'insecure' repo!
17:22 <skarnet> hey, OpenBSD's controlfreakiness actually found a bug in my code
17:22 <skarnet> so it's not *all* bad
17:22 <^7heo> huhu
17:22 <skarnet> (just most of it)
17:23 <jirutka> and I found serious security bug in OpenBSD’s code and I’m not security expert at all… so?
17:23 <^7heo> jirutka: where?
17:23 <skarnet> so it was just a normal day where hell didn't freeze over
17:24 <jirutka> since that I don’t trust OpenBSD as before… that fact that they pushed such breaking change without any warning and released it and even after report they were quite calm…
17:24 <jirutka> ^7heo: LibreSSL
17:24 <skarnet> jirutka: honestly if I could devote the time to making a pass on the MDAs and MUAs myself, and patching what needs to be patched, I would
17:24 <TemptorSent> Anyway, my thought is that packages which CAN NOT be utilized in a secure way should go somewhere you explicitly have to opt-into.
17:25 <jirutka> you have to opt-in every package, Alpine is not Debian to ship hundreds of packages in default installation ;) you must explicitly install all possibly bad software, that’s opt-in
17:25 <TemptorSent> jirutka: Not true -- deps :)
17:25 <jirutka> we’re talking about mailing *clients*, not libs, right?
17:25 <skarnet> jirutka: but there's also good software that's not in the default installation, how can you tell the difference
17:25 <skarnet> we're talking about anything that can access a user's mailbox
17:26 <skarnet> or maildirs
17:26 <TemptorSent> jirutka: MUAs/MDAs (and in some cases MTAs)
17:26 <TemptorSent> I actually still use UUCP in some cases, so the /var/spool/mail thing does come into play.
17:26 <^7heo> jirutka: ah right.
17:27 <skarnet> TemptorSent: yeah, but that's just you. ;)
17:27 <TemptorSent> skarnet: Yeah, I know - I'm an antique.
17:27 <TemptorSent> Still works great for devices with occasional connectivity and low data volumes.
17:28 <skarnet> *cough* serialmail *cough*
17:29 <jirutka> I even don’t know what UUCP is o.O
17:29 <TemptorSent> Hmm, serialmail looks pretty cool for the mail part.
17:30 <TemptorSent> Unix-to-Unix-CoPy (or Copy Protocol or Copy Program, depending on who you ask an the phase of the moon.)
17:31 <TemptorSent> I use UUCP for both copying configuration/updates and for passing mail.
17:32 <^7heo> I don't use UUCP
17:32 <^7heo> for anything.
17:32 <^7heo> for configuration management I tend to do git repositories (so I have versionning)
17:32 <^7heo> for mail I use imap/smtp.
17:32 <^7heo> (over SSL)
17:32 <jirutka> same for me
17:33 <TemptorSent> ^7heo: Not configuration management, pushing config updates to embedded devices and retrieving their logs/messages
17:34 <^7heo> TemptorSent: I tend to do that via scp/rsync.
17:34 <jirutka> mpv broken after commit by pickfire… http://bugs.alpinelinux.org/issues/7262
17:35 <TemptorSent> ^7heo: Yeah, great for hosts that you have IP connectivity to, not so great over serial
17:35 <^7heo> jirutka: pickfire doesn't have commit rights.
17:35 <^7heo> jirutka: so technically, mpv broke after a commit by fabled
17:35 <jirutka> ^7heo: yes, they are both responsible :)
17:36 <^7heo> TemptorSent: I do not often have only a serial connectivity.
17:36 <TemptorSent> ^7heo: Welcome to the world of embedded computing.
17:36 <^7heo> nah not anymore.
17:36 <^7heo> a lot of "embedded" has IP support nowadays.
17:36 <^7heo> most of it has.
17:37 <TemptorSent> Networking is not required nor desired.
17:37 <TemptorSent> Think PLCs
17:37 <^7heo> tell that to the folks who did the ethernet shield for the arduino.
17:38 <TemptorSent> You may want network MODULES, but the core hardware is by design not connected to the outside world in any way without physical access
17:38 <^7heo> TemptorSent: what I'm saying here, is that it's not often that I see systems that do have a filesystem but no network.
17:38 <^7heo> TemptorSent: if it has no filesystem, I have to reprogram the chip anyway.
17:38 <^7heo> TemptorSent: if it has a filesystem, and network, I use ssh/rsync
17:39 <TemptorSent> ^7heo: Hmm, much of my stuff ends up being flashed over serial using a bootloader or has a sd card.
17:39 <^7heo> most of my stuff is flashed using a dedicated programmer.
17:39 <^7heo> which is connected via USB-encapsulated serial.
17:39 <TemptorSent> ^7heo: Running the network is far too much power usage.
17:40 <TemptorSent> JTAG handles the bricked bootloaders.
17:41 <TemptorSent> The only time it actually gets connected is for diagnostics or telemetry.
17:43 <^7heo> jirutka: why was xrandr and xss removed from the build options btw?
17:43 <TemptorSent> Much of this stuff is using low-speed serial-connected radio-modems where communications is required, 75-9600bps is common.
17:43 <^7heo> jirutka: oh nevermind, it's in the message.
17:48 <TemptorSent> ^7heo: Besides, the BOM and engineering overhead for adding the magnetics/PHY for ethernet or radio, transmission lines, and antenna for wireless is horrible for applications that don't need it.
17:50 <jirutka> ^7heo: hm, he’s right, these options has been removed and so the functionality is enabled by default now
17:50 <jirutka> ^7heo: so it must be some regression in the project
17:57 __0xAX joined
17:59 <^7heo> jirutka: is the commit in the release?
17:59 <jirutka> ^7heo: yes, I’ve checked that
18:00 <fabled> jirutka, ^7heo : mpv sounds like upstream issue, should probably revert it
18:01 <jirutka> fabled: yeah, exactly
18:01 <fabled> pickfire, any thoughts on reverting mpv upgrade?
18:01 <^7heo> fabled: he's sleeping atm.
18:02 <jirutka> ^7heo: how do you know? :)
18:06 <fabled> it potentially depends on ffmpeg3.3 since in mpv git ffmpeg3.2 support is removed soon after the release tag
18:06 <fabled> i'll revert it
18:30 <clandmeter> Shiz jirutk
18:31 <clandmeter> Keyboard....
18:31 <clandmeter> Jirutka, rust and other Arch's, what is the status?
18:33 <jirutka> clandmeter: we have some info from fabled how to do that, just need to find some time to actually do that :)
18:33 <jirutka> clandmeter: I don’t know if Shiz made more progress…?
18:37 <jirutka> clandmeter: but I’ve already moved rust (not cargo yet) to community, ’cause fabled said that it’s not needed to have rust-bootstrap for bootstrapping from upstream’s binary and I was afraid that someone may decide to already branch v3.6 :)
18:38 <clandmeter> right. so you want to make it for 3.6?
18:39 <jirutka> definitely!
18:42 __0xAX_ joined
18:43 __0xAX joined
18:48 <ncopa> i ws thinking of setting 1777 permissions on /var/mail
18:48 <ncopa> and symlink /var/spool/mail
18:49 <ncopa> something created /var/spool/mail with group permissions to 'buildozer' on the build server
18:49 <ncopa> anyone have a clue what might have done that?
18:51 <nmeum> mmh might have done that
18:52 <nmeum> might also explain the strange mmh build failure on the armhf builder
18:53 <TemptorSent> ncopa 1777 still allows for a class of exploits based on creating an intentional name collistion and deliving mail to the attacker's file.
18:55 <TemptorSent> touch /var/mail/$victim; chmod 666 /var/mail/$victim
18:55 <jirutka> yeah, that’s true, it’s very vulnerable
18:56 <TemptorSent> Or worse ln /var/mail/$attacker /var/mail/$victim
18:57 <TemptorSent> Which will bypass many 'security' measures in the MDA such as fixing perms or changing ownership.
18:58 <ncopa> but attacker needs to do it before first delivered mailbox
18:59 <ncopa> but yes, valid point
18:59 <TemptorSent> Not exactly a hard race to win ;)
18:59 <ncopa> what about the debian style, with 750 permissions?
18:59 <ncopa> and give a specific group write perms
19:00 <TemptorSent> Still potentially vulnerable, but DoS is much easier than mail theft in that case.
19:00 <ncopa> i mean 770
19:00 tkharju joined
19:01 <TemptorSent> Group perms will allow theft in that case.
19:02 <ncopa> yes you need to be in the group to be able to steal mail
19:02 <ncopa> how does other distros solve it?
19:02 <TemptorSent> 750 and pre-create (renaming any existing) the mailboxes at time of user createion gives you reasonably security
19:02 <TemptorSent> Poorly.
19:03 <ncopa> i suppose people use maildir nowdays
19:03 <TemptorSent> Mail for local users should be delivered to the users's home directory, while virtual users probably should use a MDA specific directory to avoid problems when using multiple MDAs
19:04 <ncopa> nmeum mmh's configure script will check permissions on /var/spool/mail
19:05 <TemptorSent> It's one of those cases that the only sane solution to put it in /var/mail is to use a suid binary running as root that explicitly excludes users from writing the directoy.
19:05 <jirutka> tbh I think that locally delivered mails are mostly history…
19:05 <ncopa> and try install the binary with the given setgid
19:06 <ncopa> yes
19:06 <ncopa> i dont think we care that much
19:06 <ncopa> but we need fix mmh to do something consistent
19:06 <TemptorSent> 755 mail:mail, with suid:root:mail for the MDA
19:07 <TemptorSent> That allows mail be used to write non-local users, and the appropriate userid set for all local users.
19:07 <TemptorSent> That's as close to sane as you can really get with it I'm afraid.
19:08 <TemptorSent> setgid doesn't fix the problem.
19:08 <ncopa> imho suid root is worse
19:08 <TemptorSent> Here is one of those good candiates for namespaces.
19:09 <TemptorSent> only suid actually functions properly, because with setgid only, you can still force collisiosns. You need to map the files to users one to one, and only root can do that.
19:10 <TemptorSent> There is no simple, secure means of delivering mail to a common mail directory with existing semantics.
19:10 <ncopa> bug in that application will not only give you permissions to other users mail
19:11 <ncopa> will give you access to everything
19:11 <TemptorSent> Having a maildir in the homedir writtable by a group works, because you don't need the user to have that group memebership.
19:12 <TemptorSent> But if you have mail for all users in a single directory owned by a single user and group, the ONLY way to secure the mail directories is to set their ownership to the user and their group to something that doesn't contain any users.
19:13 <TemptorSent> Which requires a suid:root MDA.
19:13 <TemptorSent> Which is not secure, QED - /var/mail is not a secure place for MDAs to deliver mail for local users.
19:14 <TemptorSent> Just say no to shared mail directories for local users.
19:15 <TemptorSent> Solving it securely requires something like selinux caps or namespaces.
19:17 <TemptorSent> if you want to, I suppose you could abuse the /var/mail directory and create /var/mail/$user at user creation time with perms $user:mail 770
19:17 <jirutka> TemptorSent: POSIX ACLs wouldn’t help here, right?
19:18 <TemptorSent> They could, but you'd still have to get the MDA to understand them I think, which would be better solved by just fixing the damn thing to deliver to user-owned directories.
19:19 <TemptorSent> SELinux would let you restrict the scope of the MDA binary without modifying it I believe
19:19 <skarnet> how hard is it to find the discussion in the chat logs instead of recreating it
19:19 <TemptorSent> But POSIX ACLs + some scripting would work, and would actually be portable.
19:20 <TemptorSent> skarnet: Ask ncopa? *ducks*
19:20 <skarnet> I'm asking him as much as anyone else :P
19:21 <ncopa> so the conclusion is that there is no sane way to set up a shared /var/mail
19:21 <TemptorSent> Yes.
19:21 <ncopa> unless you create the users mailbox at user creation time?
19:21 <skarnet> exactly
19:22 <TemptorSent> And if you do that, the user can still break it by unlinking it.
19:22 <ncopa> and if you create the mailbox at user creation time, then you could use 1777
19:22 <ncopa> yes
19:22 <TemptorSent> Nope, 1777 is never going to be secure.
19:22 <skarnet> and users with a smart MUA and a programmable MDA who want several mailboxes still need to create them in their homedirs
19:23 <skarnet> so why not cut to the chase and deliver in the homedir in the first place
19:23 <TemptorSent> I fully concur.
19:24 <skarnet> and for virtual users, the virtual user database is MDA-dependent, so /var/lib/$MDA/foobar makes more sense than /var/mail.
19:24 <ncopa> yes ofc
19:24 <TemptorSent> Or, if you really must have mail on a different filesystem, create a user directory in that location.
19:24 <ncopa> ok let me rephrase it
19:24 <jirutka> afk
19:25 <ncopa> should the 'inc' program from mmh be setgid or should it not?
19:25 <skarnet> what is mmh?
19:25 <TemptorSent> For store-and-forward delivery-only virtual users, /var/spool/mail MAY be appropriate, but otherwise should NOT be used.
19:25 <TemptorSent> my mail handler?
19:26 <ncopa> https://git.alpinelinux.org/cgit/aports/tree/community/mmh/APKBUILD
19:26 <ncopa> that package is breaking builders
19:26 <TemptorSent> Oh, meillo's
19:27 <ncopa> configure script does some magic depending on if /var/mail is world writeable or not - on the building system
19:27 <skarnet> -> trash
19:28 <TemptorSent> He wrote it as his master's theisis?!?
19:28 <skarnet> or, more constructively: do whatever it takes to make it build, it doesn't matter, it will be insecure anyway :P
19:28 <skarnet> unless it can be configured to read mail from the user's homedir
19:28 <TemptorSent> Oh, 'Modern Mail Handler' now? Make up your mind!
19:30 <ncopa> skarnet: exactly, it doesnt matter really because its not possible to do it right
19:31 <ncopa> so im thinking of drop setgid
19:31 <TemptorSent> I'm reading his thesis real quick...
19:32 <skarnet> the least worst way of handling /var/mail is to have it -drwsrws--- root:mail and to keep the setgid mail for programs that need to access it
19:33 <TemptorSent> Agreed, and print a big, fat warning that it may be insecure.
19:33 <skarnet> (but the real fix is to make it read from another default mailbox, if possible)
19:33 <TemptorSent> I'm not seeing anything in the design that should make it impossilbe.
19:35 <TemptorSent> Hmm, mmh is one of those programs that can be used in a couple different ways -- one of which is with slocal, in which case reading from /var/spool/mail and deliving to local folders is actually the proper operation.
19:36 <TemptorSent> But configuration is required to make it work right in that mode.
19:36 <skarnet> 1990 called, they want you back
19:36 <TemptorSent> *lol* Well, this is MH :)
19:42 <TemptorSent> So it looks like this is the odd exception that actually should use /var/spool/mail, since it's mode of operation is to create a folder structure in the home directory and despool them to that.
19:42 <ncopa> so we should setgid the 'inc' program? since world writable /var/mail is always bad?
19:43 <TemptorSent> What is inc actually reading/writing?
19:43 <skarnet> ncopa: yes, I guess. With a big fat warning.
19:43 <TemptorSent> Can you strace it if it's not clear?
19:44 <ncopa> im not running it, im just modifying the build
19:44 <ncopa> to unblock the 3.6 builders
19:45 <ncopa> nmeum: ok that we make 'inc' setgid 'mail'?
19:48 consus joined
19:50 <TemptorSent> ncopa: spool dir should be /var/spool/mail, as inc truncates the spoolfile on each successful read and does not treat it as a mailbox.
19:52 <TemptorSent> The env variable it uses is actually 'MAILDROP', which may provide a more secure way of handling it by simply making the user set that!
19:53 <TemptorSent> No SGID needed if the system mailer can deliver to the users maildir.
19:53 <ncopa> ok good
19:53 <TemptorSent> So install it with no set anything.
19:54 <ncopa> thats what i wanted to hear
19:54 <ncopa> thanks
19:54 <ncopa> now next question is, can anyboy help me figure out what created the /var/spool/mail directory?
19:54 <TemptorSent> You can even feed mail to it via stdin, so you could spawn it as the user.
19:54 <consus> Oh
19:55 <consus> The right time :D
19:55 <ncopa> is there any pre-install script or similar that created it?
19:55 <skarnet> possibly baselayout, since it is in fkn FHS
19:55 <TemptorSent> /var/spool/mail is actually valid for MH, since it is explicitly used for spooling messages pending final delivery only.
19:56 <skarnet> TemptorSent: please stop mentioning /var/spool/mail EVER
19:56 <ncopa> skarnet is not owned by any package
19:56 <skarnet> thank God
19:56 <TemptorSent> But I suggest we bypass that entirely and deliver directly to the user.
19:56 <ncopa> *it is not owned by any package
19:56 <skarnet> ^
19:56 <ncopa> :)
19:56 <consus> You are discussing the /var/mail and /var/spool/mail thing, right?
19:56 <ncopa> nope
19:56 <consus> :(
19:56 <ncopa> we are definitively not
19:56 <consus> That's a shame
19:57 <consus> I was hoping for the final resolution any time soon
19:57 <TemptorSent> skarnet: You REALLY hate /var/spool/mail for some reason, even when it's semantically correct...
19:57 <skarnet> look up "obsolete"
19:57 <TemptorSent> consus: Resolution is avoid if at all possible.
19:57 <skarnet> and "bad design"
19:57 <TemptorSent> skarnet Agreed, I'm just speaking in terms of WHICH insecure, poorly designed directory to use for what :)
19:58 blueness joined
19:58 <skarnet> I'm not even talking about insecure
19:58 <skarnet> I'm talking about nonsensical
19:58 <skarnet> Please get it into your head that a spool for incoming mail is 100% nonsense
19:58 <skarnet> in 2017
19:58 <consus> FHS states /var/mail
19:58 <skarnet> (and it also was nonsense in 1996)
19:59 <skarnet> consus: we've been through this
19:59 <TemptorSent> Well, the spool makes sense in certain cases still (weird ones where networks don't work reliably and devices poll)
19:59 <consus> skarnet: Hm?
19:59 <skarnet> TemptorSent: no. If you still have doubts, please read this line again.
19:59 <ncopa> woudl probably make more sense to have a /var/spool/mmh for mmh
19:59 <skarnet> ncopa: no, a spool only makes sense for OUTGOING mail
19:59 <skarnet> never incoming
19:59 <skarnet> and outgoing mail is for the MTA to handle.
20:00 <TemptorSent> skarnet: What is the input to filtering then?
20:00 <consus> AFAIR every smtp server already has it's own directory in /var/spool
20:00 <consus> So /var/spool/mail is purely for mailboxes
20:00 <skarnet> mailboxes have no place in /var/spool
20:00 <consus> Really?
20:00 <consus> $ ls -ld /var/mail
20:00 <consus> lrwxrwxrwx 1 root root 15 Jan 4 2016 /var/mail -> /var/spool/mail
20:00 <skarnet> Really. Again, we've been through this.
20:01 <consus> Well
20:01 <consus> Now it's all over the place
20:01 <skarnet> yes, there is such a link, and it's a mistake.
20:01 <TemptorSent> consus: No, /var/spool/mail is NEVER for user mailboxes, it MAY be used explicitly as a SPOOL, meaning it is cleared upon successful read.
20:01 <TemptorSent> The link is evil.
20:01 <consus> TemptorSent: In every major distro it is
20:01 <consus> TemptorSent: Deal with it already
20:01 <skarnet> that's proof that every major distro just doesn't think
20:01 <TemptorSent> Yeah, it's been broken since the 90s.
20:01 <consus> Perhaps
20:01 <consus> Still things the way they are
20:02 <skarnet> do you know the metaphor with chimpanzees getting an electric shock every time they climb a ladder?
20:02 <skarnet> that's mainstream distros for you
20:02 <ncopa> hey, if anybody wanst setup /var/spool/mail as a symlink, we should let them
20:02 <TemptorSent> When semantics were still in use, it at least made some sense, but now it's just a giant cluster.
20:02 <consus> ncopa: For now opensmtpd is broken with the default config
20:02 <consus> ncopa: Because no package creates this symlink
20:02 <TemptorSent> Then fix where it writes!
20:02 <consus> Then fix mailx
20:02 <ncopa> is there a bug for it?
20:02 <skarnet> consus: would you kindly let us work?
20:03 <ncopa> on bugs.a.o?
20:03 <consus> ncopa: yes
20:03 <ncopa> consus can you please file the details on bugs.a.o
20:03 <consus> ncopa: ok
20:04 <ncopa> the more urgent issue at hand is that builder chokes due to something created /var/spool/mail with wrong permissions
20:04 <ncopa> and i have no clue what it was
20:04 <ncopa> drwxr-xr-x 2 root buildoze 4096 Mar 28 22:32 /var/spool/mail/
20:04 <skarnet> likely 2770 root:mail
20:04 <skarnet> ugh
20:04 <skarnet> buildoze?
20:05 <TemptorSent> Anyway, back to mmh -- I suggest you strip it of any elevated privs and tell the users to set the env variable to say ~/.mail/incoming
20:05 <ncopa> buildozer is the user that builds are running as
20:05 <ncopa> TemptorSent: yes that makes sense
20:06 <TemptorSent> If someone wants to fix it to do that automatically, that would be cool, but for now, let the user decide
20:06 <awilfox> how is this argument still happening
20:06 <TemptorSent> And they can link that to wherever they have their mail delivered :)
20:06 <TemptorSent> Because mail is a mess
20:06 <awilfox> only if you /make/ it a mess
20:07 <skarnet> ncopa: somehow I remember saying exactly this for 2 days straight, doesn't it make sense when I'm the one saying it?
20:07 <awilfox> if opensmtpd relies on brokenness I suggest dropping the package.
20:07 <TemptorSent> You mean trying to use anything of the shelf?
20:07 <TemptorSent> Yeah, I suggested dropping the broken packages above :)
20:07 <TemptorSent> Unfortunately, that's most of them :/
20:07 <awilfox> well I do not want to read the 806 lines of backlog that this discussion has spawned
20:08 <ncopa> awilfox not worth reading backlog
20:08 <awilfox> in fact, maybe it is time to just disconnect freenodee
20:08 <TemptorSent> For the most part, proper configuration and possibly minor wrapping would mitigate if not fix them I suspect.
20:08 <awilfox> TemptorSent, I mean relying on brokenness.
20:08 <ncopa> the issue is supposed to be reported on bugs.a.o and we take it from there
20:08 <awilfox> TemptorSent, some brokenness cna be fixed
20:08 <TemptorSent> awilfox: Yeah, they rely on bad assumptions about privs, which breaks them.
20:08 <skarnet> awilfox: or just to /leave #alpine-devel, which would save me a huge amount of time
20:08 <awilfox> like kde brokenness, I spent most weekends fixing it, and it mostly is fully working now
20:09 <awilfox> no more mem leaks or tearing or musl crashes
20:09 <TemptorSent> Wow, great work!
20:09 <ncopa> kde works with musl now?
20:09 <ncopa> thats awesome!
20:09 <awilfox> yep, most of my patches are upstreamed
20:09 <awilfox> a few still in queue
20:09 <ncopa> even better
20:09 <skarnet> ok, I got the message.
20:09 skarnet left
20:10 <awilfox> I'm using it daily via adelie, but void is using the patches too so they are testing it more
20:10 <awilfox> should be easy to bring to alpine at the next KDE LTS
20:10 <awilfox> which Inthink is 17.12 (so December)
20:11 minimalism joined
20:13 <awilfox> didn't think KDE would make him leave heh
20:13 <TemptorSent> ncopa: /var/mail is so insecure, I'd almost suggest creating it 500 with a warning note inside.
20:15 <ncopa> awilfox i dont think it was KDE. i think i was not good enough telling that i actually do listen to him
20:16 <TemptorSent> I think the fact we've had this same conversation almost verbatim three times in the past week is probably the reason.
20:17 <TemptorSent> The conclusion remains the same, local user mail for final delivery belongs in user-owned directories, prefereably in their home directories.
20:19 <scadu> amen.
20:19 <TemptorSent> Anything else is too broken to contemplate supporting.
20:21 <TemptorSent> skarnet and I disagree on the need at times for an intermediary spool directory for incomming mail, which I have used in the past to handle filtering before handing to the final delivery agent.
20:22 <TemptorSent> But anthing of that nature should NOT be user-writable anyway.
20:23 scadu joined
20:24 <consus> Actually, it is possible to tell smtpd to deliver to user mail dir. Where to submit patches to the config?
20:24 <consus> *home dir
20:24 <TemptorSent> In fact, good general policy is that anything that writes to a user-owned file should only do so in a directory owned by that user unless the file is explicitly unlinked and created each time.
20:24 <consus> Sorry
20:25 <consus> Though it would change the format from mbox to maildir
20:25 <consus> Don't know if that's okay
20:25 <nmeum> ncopa: sure, should I update the mmh aport accordingly?
20:25 <TemptorSent> consus: I'd guess either a PR or add to the bug.
20:26 <TemptorSent> nmeum: If you can figure out how to get it to default to user maildir, that would be ideal.
20:27 <nmeum> user maildir? do you mean use maildirs?
20:27 <TemptorSent> consus: IIRC there's a way of forcing it to deliver all new mail to a single file in the user maildir?
20:27 <nmeum> ah
20:27 <consus> Accordingly to smtpd.conf -- no
20:27 <consus> deliver to maildir [path]
20:27 <consus> deliver to mbox
20:27 <TemptorSent> nmeum: Yes, if possible, supporting standard maildir would be ideal.
20:27 <consus> So mbox delivery method assumes /var/mail
20:28 <nmeum> TemptorSent: mmh doesn't support maildirs
20:28 <TemptorSent> bloody stupid POS.
20:28 <ncopa> nmeum: i think the conclusion was, no elevated privs
20:28 <consus> I can write a patch for this of course
20:28 <TemptorSent> Okay, yeah - delivering to a path in mbox format would be ideal consus.
20:29 <consus> Why not maildir?
20:29 <consus> And what is mmh
20:29 <TemptorSent> Getting mbox clients to support maildir is likely a lot more work.
20:29 <ncopa> nmeum: i think we need to make mmh *not* setgid inc, regardless of what the /var/spool/mail is
20:29 <consus> mailx supports maildir
20:29 <consus> mutt too
20:30 <consus> What clients are we talking about?
20:30 <ncopa> nmeum: can you help me with that? the currencte configure script will check the permissions on the buildserver
20:30 <ncopa> i'll disable mmh for now so it does not block the builders
20:30 <nmeum> you can hardcode the group it should use for the setgid binary using an environment variable
20:30 <TemptorSent> mailhandler flavor agents
20:30 <nmeum> but I don't think you can make inc a non-setgid binary
20:31 <consus> TemptorSent: Can you please point me to the exact package in a tree?
20:31 <ncopa> nmeum then maybe i misread the configure script
20:31 <consus> I'm not familiar with mailhandler
20:31 <nmeum> I mean you can obviously patch the makefile but I don't think that this is 'supported'
20:32 <TemptorSent> see 'nmh' and 'mmh'
20:32 <jirutka> patching makefile is never “supported” by upstream, yet we need to do it sometimes :)
20:32 <nmeum> ncopa: if you just want me to the change the setgid binary group to 'mail' I can do that right away otherwise it would probably be a good idea to disable the aport for now
20:34 <TemptorSent> consus: Things such as fetchmail also don't speak maildir
20:34 <consus> Hm
20:35 <consus> I used fetchmail + procmail
20:35 <consus> Worked fine
20:35 <consus> Anybody uses fetchmail without anything? P_P
20:35 blueness joined
20:35 <TemptorSent> Depends on if you do it in a single step or not.
20:35 <consus> Okay
20:35 <TemptorSent> I used to fetch to spool, then proc
20:35 <consus> The patch should be trivial
20:36 <consus> I'll work on it and propose it to the upstream
20:36 <TemptorSent> But generally it's much nicer to parse a single file to spool new files than traverse a directory hierarchy.
20:36 <consus> Of course
20:36 <consus> But it's easier to work with individual mails
20:36 <consus> Instead of one HUGE file
20:37 <HEROnymous> hey guys, moving along this install - I've got an issue now, not sure why, it's erroring during setup-alpine with unsatisfiable constraints regarding .setup-apkrepos
20:37 <TemptorSent> So anything that is used programatically will want a single input file.
20:37 <TemptorSent> consus: The spool files should never get huge, they should only contain NEW mail.
20:38 <consus> Aha
20:38 <consus> So then mail saves them to ~/mbox
20:38 <consus> By default
20:38 <TemptorSent> Otherwise it's not a spool.
20:38 <consus> And then they got huge
20:38 <ncopa> nmeum: $ curl --silent http://nl.alpinelinux.org/alpine/edge/community/x86_64/mmh-0.3-r0.apk | tar -ztv usr/bin/inc
20:38 <ncopa> -rwxr-xr-x root/root 102504 2016-08-28 23:46 usr/bin/inc
20:38 <TemptorSent> Yeah, the agent should be cleaning that out.
20:39 <TemptorSent> read from ~/mbox and write to ~/Mail/...
20:39 <ncopa> nmeum: apparently its currently set without any setgid permissions. i think that happens if /var/spool/mail is missing during build
20:39 <ncopa> nmeum: we need patch the configure script so that we can force that behaviour with a configure option of some sort
20:39 <ncopa> --disable-setgid or similar
20:40 <nmeum> ncopa: the configure.ac also defines a SETGID_MAIL variable maybe we just want to set it to zero?
20:40 <nmeum> that should work
20:40 <TemptorSent> What we really should do is develop a consistent mail policy and configure everthing we package to conform.
20:40 <nmeum> yeah
20:41 <TemptorSent> FHS be damned, SELF consistency is what's important.
20:42 <consus> :D
20:42 <consus> Documentation
20:42 <TemptorSent> And the reason for each design decision should be documented so we don't keep having the same arguments ;)
20:42 <consus> Goddamit
20:42 <consus> We need documentation for that
20:43 <consus> Because people expect something familiar
20:43 <TemptorSent> Yes, exactly. Document the expected behavior, then make it actually happen.
20:43 <consus> Without the docs
20:43 <consus> :D
20:43 <TemptorSent> Yeah, the problem is the docs we currently have are more often than not incomplete or just plain wrong.
20:44 <consus> :)
20:45 <TemptorSent> I started stubbing out architecture on the wiki, but we really need to get down to the design-doc stage.
20:46 <TemptorSent> Question - how do I add a category to the Wiki?
20:46 <nmeum> ncopa: ok? http://sprunge.us/SEPG
20:47 <consus> xD
20:47 <consus> I got banned for editing wiki
20:47 <TemptorSent> Wow, how'd you manage that?
20:48 <consus> Pushed the 'Save' button
20:48 <TemptorSent> On?
20:48 <consus> Apparently, there is a grace period
20:48 <ncopa> nmeum does it work? it looks ok to me, but i havent verified that it does what it should
20:48 <consus> Between you've registered
20:49 <consus> And first commit
20:49 <consus> To the wiki
20:49 <consus> If you violate this period, YOU'RE BANNED
20:49 <TemptorSent> Oh, more like mediawiki is broken.
20:49 <consus> :D
20:49 <ncopa> consus first commit with a link to external site
20:49 <ncopa> its anti spam feature
20:49 <nmeum> ncopa: $ tar -ztvf mmh-0.3-r1.apk | grep inc
20:49 <consus> ncopa: Not true
20:49 <nmeum> -rwxr-xr-x root/root 102784 2017-05-02 22:36 usr/bin/inc
20:49 <consus> Ah
20:49 <consus> True
20:49 <consus> A link to pkgs.a.o =/
20:49 <ncopa> nmeum push it. thanks!
20:49 <TemptorSent> Yeah, that'd do it.
20:49 <consus> Btw
20:50 <consus> Gotta update it now
20:50 <consus> Since the grace period is off
20:50 <consus> I gues
20:52 <TemptorSent> Holy crap there are a lot of blocked by abuse filter.
20:52 <consus> > This action has been automatically identified as harmful, and you have been prevented from executing it. In addition, to protect Alpine Linux, your user account and all associated IP addresses have been blocked from editing. If this has occurred in error, please contact an administrator. A brief description of the abuse rule which your action matched is: New users are not allowed to add ip
20:52 <consus> addresses and phone numbers
20:52 <consus> Ah for god's sake %)
20:52 <consus> Okay
20:53 <ncopa> sounds like its broken
20:53 <consus> Could somebody please post this https://paste.pound-python.org/show/TSQocqhTLd6yLUmXUWBc/
20:53 <consus> To the wiki?
20:53 <consus> I really want to document this 'docs' package feature
20:53 <consus> It's cool and helpfull
20:53 <consus> But I cannot edit the wiki
20:53 <TemptorSent> consus What was the account name you got blocked with, ncopa should be able to toggle that.
20:53 <consus> consus
20:53 <consus> It was consus
20:53 <consus> It's unlbocked now
20:54 <clandmeter> HEROnymous, did you try apk del .setup-apkrepos ?
20:54 <consus> By another guy
20:54 <ncopa> but you got blocked again?
20:54 <consus> But seems like grace period is not off =/
20:54 <consus> I don't know how long to wait
20:54 <consus> Nobody told me
20:54 <nmeum> speaking of MDA and setgid binaries is there still a reason why the mutt aports needs to have the suid option set? https://git.alpinelinux.org/cgit/aports/tree/main/mutt/APKBUILD#n13
20:54 <TemptorSent> So, what do we have to do to disable that 'feature'
20:54 <consus> So I tried to modify the very same page
20:54 <nmeum> the option was introduced with this commit https://git.alpinelinux.org/cgit/aports/commit/main/mutt/APKBUILD?id=c172eceed77bc0330347b09a284d86d99da6146f
20:54 <nmeum> but the mutt package doesn't seem to ship mutt_dotlock currently
20:54 <HEROnymous> clandmeter, no, should I ?
20:55 <HEROnymous> clandmeter, all I've done was some ifconfig and route commands and setup-alpine
20:55 <clandmeter> can you ping?
20:55 <clandmeter> sounds like network issue
20:55 <HEROnymous> nah network's good. it was able to detect best mirror and stuff during the run.
20:55 <TemptorSent> nmeum: Audit it and if it doesn't absolutely need it, kill it's sgid bit.
20:56 <clandmeter> then apk del it
20:56 <clandmeter> and apk update
20:56 <TemptorSent> Well, I see you in the abuse log consus, but I don't have admin rights or anything to fix it :(
20:57 <clandmeter> from what i know it takes 5h
20:57 <clandmeter> last time i checked
20:57 <TemptorSent> Can that be bypassed by setting a flag?
20:58 <clandmeter> i have no idea
20:58 <clandmeter> this mediawiki drives me mad
20:59 <consus> So any help on that wiki issue? xD
20:59 <^7heo> I told you it's shit
20:59 <ncopa> consus: i've unblocked you
20:59 <^7heo> consus: open a pr against adoc/adoc
20:59 <TemptorSent> Okay, it seems the the single biggest barrier of entry to getting decent docs going is mediawiki.
20:59 <consus> This first time I'll agree with ^7heo
20:59 <^7heo> consus: we'll merge your doc there
21:00 <consus> ^7heo: Will anybody *read* it?
21:00 <clandmeter> why cant it just have a normal user interface
21:00 <consus> I see no links at the main page to your docs
21:00 <^7heo> clandmeter: because people write shit
21:00 <TemptorSent> clandmeter: Because it's a steaming pile of mismatched crap.
21:00 <consus> So what now?
21:00 <consus> Should I wait?
21:00 <consus> Should I press 'Save page'?
21:01 <^7heo> TemptorSent: of course it is the single barrier of entry
21:01 <^7heo> TemptorSent: but apparently it's more important tohave a feature to input docs via the web than to have docs at all
21:01 <TemptorSent> Okay, so what's a BETTER solution, since we all seem to agree that mediawiki isn't worth the electrons it's written on for our purposes.
21:01 <^7heo> gh is a working solution today
21:01 <^7heo> we also have the org, project
21:02 <^7heo> and we can convert doc over
21:02 <^7heo> using pandoc or whatnot
21:02 <TemptorSent> Asciidoc/md?
21:02 <^7heo> adoc
21:03 <consus> asciidoctor xD
21:03 <^7heo> https://github.com/adoc/adoc
21:03 <consus> Link is dead
21:03 <^7heo> https://github.com/adocs/adocs
21:03 <^7heo> sorry, missed the s
21:03 <^7heo> I'm tired
21:04 <mitchty> if you want to know how to get pandoc built on alpine linux this is what i do https://github.com/mitchty/alpine-static-tmux/blob/master/Dockerfile#L90 (note this is used to just build a static pandoc)
21:04 <consus> Hm
21:04 <TemptorSent> Ahh, cool!
21:04 <consus> So how we edit this on web?
21:04 <consus> E.g. I want a nice preview button
21:04 <^7heo> thanks mitchty
21:04 <consus> To make sure my docs do not look like shit
21:05 <mitchty> ^7heo: np, pandoc and idris are most of the reasons for ghc on alpine linux :)
21:05 <TemptorSent> asciidoctor?
21:06 <TemptorSent> Not a perfect rendering, but seems good enough
21:06 <TemptorSent> Actually asciidoctor rendering looks better :)
21:07 <Shiz> actually
21:07 <Shiz> https://github.com/somasis/musl-wiki
21:08 <Shiz> i really liked this too
21:08 <Shiz> (hosted on http://wiki.somasis.org)
21:09 <Shiz> it uses https://github.com/gollum/gollum
21:09 blueness joined
21:10 <^7heo> Shiz: afsik that is an option for us too
21:10 <^7heo> afaik*
21:12 <ncopa> clandmeter was testing some documentation engine with git as backend too
21:12 <ncopa> i dont remember which though
21:12 <clandmeter> its the same
21:12 <^7heo> ncopa: that one
21:12 <^7heo> gosh that network lags
21:13 <clandmeter> I think i can open it up and put the repo on github
21:13 <clandmeter> ppl can take a look at it .
21:14 <^7heo> yeah
21:16 FilippAndronov joined
21:20 <Shiz> i think i brought itu p before
21:20 <Shiz> :P
21:21 breno_ joined
21:30 <jirutka> clandmeter: but maybe not under alpinelinux org, to not confuse ppl where the documentation is, until we actually move it
21:30 <clandmeter> its a wiki, add a note :p
21:32 <ncopa> nmeum you beat me on soundtouch :)
21:32 <ncopa> with a second or so
21:32 <nmeum> :D
21:33 <nmeum> I am now working on afl
21:39 <leitao> ncopa, I just fixed the gns3-server in a better way I think
21:39 <leitao> it just copy /bin/busybox to the source package in prepare(0
21:39 <leitao> prepare()
21:39 <leitao> do you mind if I push it?
21:39 <ncopa> ok? where does it get busybox from otherwise?
21:40 <ncopa> i think it fetches busybox from some place and i think it might need static busybox
21:40 <leitao> /bin/busybox.static.
21:40 <jirutka> leitao: there’s new release of LuaJIT, 2.1.0_beta3, and someone mentioned that patch for ppc64le support needs to be updated – can you please do that?
21:40 <ncopa> ah
21:40 <leitao> jirutka, yes. We are still debugging why the PIE is causing trouble.
21:40 <leitao> and gns3-server depends on busybox.
21:40 <jirutka> leitao: okay, thanks! :)
21:41 <ncopa> leitao i think it might need static busybox?
21:41 <leitao> ncopa, yes
21:41 <leitao> /bin/busybox.static
21:41 <ncopa> then i dont understand what you porpose
21:41 <ncopa> propose
21:41 <leitao> on prepare(), I run something like:
21:42 <leitao> if [ "$CARCH" != "x86_64" ] ; then
21:42 <leitao> busybox_bin=$(find . -name busybox -type f)
21:42 <leitao> cp /bin/busybox.static $busybox_bin
21:43 <ncopa> should it not depends on busybox.static then?
21:43 <ncopa> busybox-static package
21:44 <leitao> yes. I though that busybox ships both static and dynamic binaries, but you are correct.
21:44 <ncopa> oh they have bundled a static busybox
21:44 <ncopa> in the source package
21:44 <ncopa> yes, thats wrong on all archs except x86_64
21:44 <ncopa> :)
21:45 <ncopa> leitao please push
21:45 <leitao> ncopa, ok, thanks!
21:45 <leitao> ncopa, we love upstream, don't we?
21:45 <ncopa> and write a comment like "# we cannot use precompiled x86_64 busybox on all archs..."
21:45 <ncopa> yes we do :)
21:45 <ncopa> upstream we love :)
21:46 <ncopa> i have to go
21:46 <ncopa> tmh1999 looks like spl-vanilla has some issue? is it our gcc or the linux-vanilla-dev that is broken?
21:46 <ncopa> tmh1999 could you try figure out why it cannot build 3rd party modules?
21:47 <ncopa> no i have to run
21:47 <ncopa> see u
21:47 <Shiz> can anyone look at my kernel upgrade :p
21:47 <ncopa> Shiz ping me tm
21:47 <Shiz> alright
22:02 poptart joined
22:09 Mr_H joined
22:12 Mr_H joined
22:22 poptart joined
22:35 Mr_H joined
22:37 Mr_H joined
22:39 Mr_H joined
22:46 <jirutka> Shiz: what is this? `setfattr -n user.upaste.language -v python3 upaste/upaste.py`
22:46 <Shiz> it makes txt.shiz.me/self have highlighting :P
22:46 <Shiz> something which is broken on my own install since migration
22:47 <Shiz> (upaste uses xattrs to store metadata about a paste)
22:47 <jirutka> interesting
23:59 StarWarsFan|afk joined