<     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 27  
28 29 30 31
00:08 <parazyd> what's up?
00:10 <parazyd> ncopa: ^^
00:10 <ncopa> parazyd: i want test this: http://tpaste.us/djgx
00:11 <ncopa> boot a clean 3.5 iso in a vm, setup without disk (or install to disk)
00:11 <ncopa> then upgrade to edge
00:11 <parazyd> grsec or vanilla?
00:11 <ncopa> doesnt matter
00:12 <parazyd> ack, will do vanilla since i have that iso on hand
00:12 <ncopa> then: curl http://tpaste.us/djgx | patch /sbin/setup-xorg-base
00:12 <ncopa> and run setup-xorg-base
00:12 <parazyd> ok
00:12 <ncopa> you may need install some window manager and fonts in addition
00:12 <parazyd> sure
00:13 <ncopa> and verify that xorg starts properly
00:13 <Shiz> does setup-udev also start udev?
00:13 <ncopa> yes
00:15 <parazyd> gosh my network is lame
00:15 <ncopa> sorry about that :-(
00:16 <ncopa> im currently on a lame net too
00:17 <parazyd> ncopa: your script won't pick up qemu btw, if that's of any matter
00:17 <ncopa> what does qemu need?
00:17 <ncopa> yes we want support qemu
00:17 <parazyd> i don't know if it needs anything
00:18 <parazyd> but it can emulate vmware with a command flag iirc
00:18 <ncopa> i think it should work with xf86-video-modesetting
00:18 <parazyd> supposedly everything works with modesetting these days
00:18 <ncopa> yes, would be nice to test it with the different qemu vga flags
00:18 <parazyd> (i've had trouble getting it to work with grsec though)
00:18 <avih> Shiz: btw, tcc actually works better than i initially thought. the va_list issue, which i noticed while testing st, was that its config.mk was adding a -I /usr/include which overridden tcc's built in includes, which have stdarg.h . so if i remove this from st's config.mk, then tcc builds st fine, and it runs fine too
00:19 <Shiz> qemu works with modesetting
00:19 <parazyd> ncopa: -vga [std|cirrus|vmware|qxl|xenfb|tcx|cg3|virtio|none]
00:19 <Shiz> i think
00:19 <Shiz> we do detect the emulated vmware card :P
00:20 <ncopa> would be nice to test them all
00:20 <avih> there's still an issue if stdio.h is included before stdarg.h though, but st doesn't do that anyway.
00:20 <parazyd> i can do that while waiting for the apks to dl
00:27 <ncopa> parazyd im also interested in one or two default font packages
00:27 <ncopa> freefont might be one option
00:27 <parazyd> that liberation is pretty good
00:27 <parazyd> https://fedorahosted.org/liberation-fonts (liberation-fonts in portage)
00:28 <ncopa> its smaller than freefont too
00:28 <ncopa> im looking for a minimal font that makes minimal usable xorg
00:28 <avih> i like noto a lot. especially its sans
00:29 <ncopa> noto is 16mb
00:29 <parazyd> liberation gets pulled in by default in gentoo i believe
00:30 <avih> get just western. the full noto covers the full unicode
00:30 <avih> (that's their thing - to cover all the possible glyphs)
00:31 <avih> i find the western noto sans very pleasing as default
00:31 <ncopa> avih you are not the only one wanting noto as default
00:32 <avih> i didn't say i want it :) you wanted something, i thought for yourself. but i did set it as my default.
00:34 <avih> (now i'm trying to figure out why mpv's build (waf) doesn't like tcc as a compiler)
00:35 <parazyd> ncopa: qemus: http://sprunge.us/fNKT
00:35 <parazyd> (upgrading to edge now)
00:37 <parazyd> ncopa: patch fails?
00:37 <ncopa> hum
00:38 <parazyd> this is what i got: http://sprunge.us/bMCG
00:38 <parazyd> Hunk 1 FAILED 3/3.
00:38 <ncopa> wget https://dev.alpinelinux.org/~ncopa/setup-xorg-base
00:39 <parazyd> heh
00:40 <parazyd> running...
00:40 <ncopa> i think we maybe should install modesetting regardless if there is /dev/dri/card*
00:40 <avih> ncopa: note, however, that some gnu apps don't play nice with noto mono. for some reason then render bold wider a bit, which accumulates and makes mono not really mono at the end of the day. liberation and many others don't have this issue. i think it's a gnu bug, but that probably doesn'tt matter much where the bug is
00:40 <avih> s/gnu/gtk/
00:40 <ncopa> avih: im looking for minimal font that is usable
00:40 <ncopa> noto is too big
00:41 <avih> k
00:41 <ncopa> noto is like 16-17MB
00:41 <ncopa> liberation is 4-5MB
00:41 <avih> and you want it to cover the whole unicode?
00:41 <ncopa> not necesarily
00:41 <ncopa> something thats usable for most common setups
00:42 <avih> so 16M is just the thing which alpine installs. it could, if you wanted, split it to sub packages
00:42 <avih> i think the western is les than 1M
00:42 <ncopa> is it usable?
00:42 <ncopa> there is some font-misc something too
00:43 <ncopa> but so ugly that is more or less useless
00:43 <parazyd> ncopa: https://pub.parazyd.cf/tmp/screenshots/screenshot22.png
00:43 <parazyd> i can't input or move the mouse
00:43 <parazyd> (setup-xorg-base went well i'd say)
00:45 <ncopa> no mouse?
00:45 <avih> ncopa: how soon do you need/want to decide? i can do some test on what works minimally, but not this week
00:45 <parazyd> ncopa: nope
00:45 <ncopa> avhi a week or so
00:45 <ncopa> parazyd: does it help if you install xf86-input-evdev?
00:45 tmh1999 joined
00:45 <parazyd> can't even switch to a tty
00:45 <ncopa> so keyboard does not work either?
00:45 <Shiz> parazyd: try sysrq-r
00:45 <Shiz> then switch to a tty
00:46 <parazyd> Shiz: it's a vm
00:46 <avih> ncopa: k, i'll let you know how far i got before next week
00:46 <ncopa> avih: thanks!
00:46 <ncopa> parazyd this is exactly what i wanted to test
00:46 <parazyd> :)
00:46 <avih> i prefer it after/if i get results, but.. well.. free appreciation, i'll take it ;)
00:47 <parazyd> i believe evdev _would_ help
00:47 <ncopa> so xf86-input-libinput wasnt enough
00:47 <parazyd> at least on gentoo i don't have xf86-input-{keyboard,mouse}
00:47 <parazyd> evdev works
00:47 <parazyd> (musl based gentoo)
00:48 <parazyd> ok i'll redo with -vga vmware and try to patch in evdev
00:48 <Shiz> :)
00:48 <avih> ncopa: but liberation would be a good falllback/default regardless
00:49 <avih> (i'll still check it during the weekend though and let you know)
00:50 mbentley joined
00:53 <ncopa> avih yes, i think liberation is the best fallback/default so far
00:53 <ncopa> parazyd i wonder why libinput didnt work?
00:53 <parazyd> no idea
00:54 <ncopa> i kinda expected it to work on "everything"
00:54 <parazyd> that's what you expect out of evdev usually
00:54 <parazyd> (i also have no libinput on gentoo)
00:55 <ncopa> i thought libinput was next gen, evdev replacement
00:55 <ncopa> but i might be wrong
00:55 <ncopa> i suppose its a good idea to always install evdev as fallback
00:55 <parazyd> avoid freedesktop like the plague
00:56 <ncopa> :)
00:57 <ncopa> i cannot help it but i love this community :)
00:57 <parazyd> <3
00:57 <parazyd> it's 3AM and i'm just sitting here, installing xorgs
00:57 <parazyd> what can you say :D
00:59 <ncopa> sorry about that, feel free to continue tm
00:59 <ncopa> i think we have to add evdev unconditionally
01:00 <parazyd> nah i'll try eudev
01:00 <parazyd> currently apk decided to download the latest firmware
01:00 <parazyd> so that's keeping me
01:01 <ncopa> try enable apk cache
01:01 <ncopa> ln -s /var/cache/apk /etc/apk/cache
01:01 <parazyd> it's nearly done
01:01 <ncopa> should speed up things on re-installs
01:01 <parazyd> but yeah
01:01 <parazyd> should've done that
01:02 <ncopa> other option is a caching reverse proxy in your lan that you use as your repo
01:04 <ncopa> so modesetting video driver should work with most cards?
01:04 <ncopa> can we drop the -vesa driver then?
01:04 <parazyd> i don't think the pi1 is going to like it :D maybe when i get a new lime2 (which i'm planning to use for a DIY NAS)
01:05 <parazyd> yep, modesetting is supposed to work
01:05 <parazyd> although on grsec it didn't give me permissions for /dev/dri
01:05 <parazyd> going back to intel solved it
01:05 <parazyd> in your case, i guess modesetting is fine
01:05 <ncopa> you need to be in the "video" group
01:05 <parazyd> i was, it's a deeper problem
01:06 <ncopa> ok
01:06 <ncopa> it might be that it needs access /sys something?
01:07 <ncopa> we have sysfs restrictions enabled in our hardened (aka grsec/unofficial) kernel
01:07 <parazyd> who knows... i might have some time to try it again tomorrow
01:07 <parazyd> could give it a shot; i also have /sys restrictions
01:09 <parazyd> ncopa: are you planning to use minipli's 4.9 backports?
01:10 <ncopa> i sort of am using it already
01:10 <parazyd> ah cool
01:10 <ncopa> in fact, i did the merge myself
01:10 <ncopa> then did a diff with minipli
01:10 <parazyd> he's doing a good job
01:10 <ncopa> apparently
01:10 <ncopa> he did slightly better than me
01:11 <ncopa> so i cierripucked 2 of his commits
01:11 <ncopa> cherry-picked*
01:11 <ncopa> there is a logo bitmap included in the patch
01:12 <ncopa> grsec patch has a different logo
01:12 <ncopa> which we cannot use
01:12 <parazyd> yes
01:12 <ncopa> i dont think we have it enable din our kernel config
01:12 <ncopa> but its good to clean that up regardles
01:12 <ncopa> same with localversion
01:13 <ncopa> other than that, there was no diff
01:13 <parazyd> damn still no mouse in qemu
01:13 <parazyd> or keyboard
01:13 <ncopa> with evdev?
01:13 <parazyd> yeah
01:13 <parazyd> i can try it tomorrow on bare metal
01:13 <parazyd> nothing at hand now
01:13 <parazyd> don't want to turn this laptop off :D
01:13 ifbizo joined
01:14 <ncopa> ok
01:14 <ncopa> thank you very much so far for you help
01:14 <ncopa> appreciate
01:14 <parazyd> np
01:14 <parazyd> hmm you don't create a Xorg.log?
01:15 <parazyd> ok
01:15 <parazyd> weird
01:15 <parazyd> i restarted the vm
01:15 <parazyd> it works now :D
01:15 <ncopa> oh
01:15 <ncopa> might be the udev thingy
01:15 <ncopa> interesting
01:16 <ncopa> we should probably make it re-trigger the uevents
01:16 <parazyd> https://pub.parazyd.cf/tmp/screenshots/screenshot23.png
01:16 <parazyd> could be
01:16 <ncopa> nice!
01:16 <ncopa> that might also be the reason why libinput didnt work
01:17 <parazyd> let's check!
01:17 <parazyd> hmm
01:18 <ncopa> rc-service udev-trigger start
01:18 <ncopa> and rc-service udev-postmount
01:18 <parazyd> i apk del'd xf86-input-evdev, and apk add xf86-input-libinput: it works; reboot: works
01:18 <ncopa> ok
01:19 <ncopa> its likely the udev-trigger thats needed
01:19 <parazyd> eudev might indeed be the reason
01:19 <parazyd> yup
01:19 <ncopa> so we try without evdev then
01:19 <parazyd> do look into why there are no xorg logs
01:19 <ncopa> in the default setup
01:20 <parazyd> yep
01:20 <parazyd> http://sprunge.us/bMCG
01:20 <parazyd> see if this is helpful, probably not
01:20 <parazyd> oh wait
01:20 <parazyd> no
01:20 <parazyd> this: http://sprunge.us/fNKT
01:20 <ncopa> its handled in setup-udev nowdays
01:21 <ncopa> this is why i started with the setup-xorg-base today in the first place
01:21 <parazyd> i see
01:21 <parazyd> cool! glad it worked out
01:23 <ncopa> http://tpaste.us/40rJ
01:24 <parazyd> :)
01:25 <ncopa> need verify the order
01:25 <ncopa> might also need start udev-settle
01:25 <ncopa> to wait for the events to finish
01:27 <parazyd> hah now you made me fiddle again
01:28 <parazyd> going to try libinput on gentoo :p
01:28 <ncopa> :)
01:34 <ncopa> how do you start dwm?
01:36 <parazyd> printf -- "#!/bin/sh\nst&\nexec dwm" > ~/.xinirc ; chmod +x ~/.xinitrc; startx
01:36 <ncopa> nice! thanks!
01:36 grayhemp_ joined
01:37 <parazyd> heh libinput works!
01:37 <ncopa> thats a surprise :)
01:38 <ncopa> i need libinput on my macbook to get reverse scrolling working in xfce
01:39 <parazyd> understandable
01:49 s33se_ joined
01:50 <ncopa> gonna sleep. thank you parazyd
01:50 <parazyd> yw, good night ;)
01:53 emacsomancer joined
02:03 ogres joined
02:29 cyteen joined
02:40 cyborg-one joined
03:27 blueness joined
03:32 ifbizo joined
03:35 mdillon joined
03:54 k0nsl joined
03:54 k0nsl joined
04:06 Nycatelos joined
04:32 blueness joined
04:33 vaelen joined
04:41 cartwright joined
05:09 fabled joined
05:19 Dick_Hammer joined
05:32 arnotixe joined
05:40 ryonaloli joined
05:40 ryonaloli joined
06:24 <dikaio> ping
06:25 <ryonaloli> pong
06:25 <dikaio> :)
06:46 aw1 joined
06:48 gogoprog joined
06:51 rollniak joined
07:02 grayhemp joined
07:08 t0mmy joined
07:10 Bun joined
07:11 <Bun> there was an update to vte recently on arch which supposedly fixes some bracketed paste mode issue, and now I can no longer paste in an alpine tmux instance; anyone any ideas?
07:15 <Bun> nevermind, it's an arch related issue it seems
07:15 <Bun> then a second question, does alpine's screen not do 256 colors or am I doing something wrong?
07:35 aw1 joined
08:03 Dick_Hammer joined
08:09 royger joined
08:13 MuffinMedic joined
08:36 alias__ joined
08:53 <alias__> I'm having issues debugging wkhtmltopdf segfaulting
08:53 <alias__> https://pastebin.com/RVGKDvL3
08:54 <alias__> Does anyone have a clue what I could try more? I'm using an ancient version of wkhtmltopdf (updating to a newer version is not an option)
08:55 <alias__> https://downloads.wkhtmltopdf.org/obsolete/linux/wkhtmltopdf-0.10.0_rc2-static-amd64.tar.bz2
08:55 <Shiz> you can't trust glibc statically linked binaries
08:56 <Shiz> considering it's accessing the web, it likely tried to load a dynamic NSS library
08:56 <Shiz> because glibc static linked binaries tend to do that
08:56 <Shiz> upon failure, it likely crashed
08:57 <Shiz> best advice i can give you is to compile it yourself
08:58 <alias__> just checked
08:58 <alias__> when just running -V it also segfaults
08:58 <alias__> I'll try to compile it myself idd
08:58 <alias__> tnx!
08:59 <Shiz> https://github.com/wkhtmltopdf/wkhtmltopdf/archive/0.10.0_rc2.tar.gz
08:59 <Shiz> i think this is the specific version you're looking for
08:59 <Shiz> (be aware that it apparently has multiple security issues...)
09:00 <alias__> yeah security wise it's a nightmare
09:04 grayhemp joined
09:31 lesion joined
09:46 fekepp joined
09:53 danci1973 joined
09:53 <danci1973> Hello...
09:58 <kahiru> hello danci1973
10:01 <danci1973> Can I 'apk upgrade' a single package?
10:03 <danci1973> Apparently libreswan 3.18 that's in v3.5/community repo has a bug regarding stopping pluto daemon, so I'd like to try the 3.20 version from 'edge/community'...
10:07 <k63ZXXguczqE> apk add -u <pkg name>
10:08 <Shiz> don't do it like that
10:09 <Shiz> add the edge repo with a tag in /etc/apk/repositories and do apk add libreswan@mytag
10:09 <Shiz> but mixing 3.5 and edge is not the best idea
10:13 <clandmeter> danci1973, bug in stopping, does that mean rc script?
10:15 <danci1973> clandmeter: Pluto should exit / terminate after receiving signal 15 - while it does clean-up connections, the process doesn't exit properly and just hangs there.
10:15 <danci1973> clandmeter: This happens with rc script and with 'kill -15 PID' ...
10:15 <clandmeter> ah ok, so its really a daemon error.
10:16 <danci1973> And over in #swan I was told that this is a ug that has been fixed in later versions...
10:17 <clandmeter> as Shiz suggested, its not good to mix repos, but you can try to pin it and try.
10:18 <Shiz> danci1973: if you can point me to a commit that fixes i can see if i can backport it to 3.5
10:18 <clandmeter> that would be even beter.
10:19 <danci1973> Shiz: I'll try.
10:19 <clandmeter> danci1973, or use the 3.6 repo's already :)
10:20 <danci1973> I didn't know there is 3.6 already.. :) https://alpinelinux.org/ doesn't mention it...
10:21 <Shiz> we're in the middle of getting it ready for release
10:21 <danci1973> If I change 3.5 to 3.6 in my 'repositories' and then run 'apk upgrade' - should I be fine?
10:23 <clandmeter> you need to add --available
10:24 <parazyd> http://www.openwall.com/lists/kernel-hardening/2017/05/11/2
10:25 <clandmeter> danci1973, we are currently on rc1 i believe. so it should be fairly safe (no promises).
10:25 <danci1973> Since this is a RAM based install, anything else I need to do after that? Kernel / modloop ?
10:27 <Shiz> is rc1 released yet?
10:29 <clandmeter> no not yet, but i remember ncopa said he wants to tag it or get it out.
10:33 joshwget joined
10:56 Unode_ joined
11:12 frew joined
11:19 TemptorSent joined
11:25 grayhemp joined
11:26 arnotixe joined
11:49 aw1 joined
11:53 gromero joined
11:58 t0mmy joined
12:05 t0mmy_ joined
12:18 farosas joined
12:23 fekepp joined
12:34 InAnimaTe joined
12:41 <ncopa> rc1 is not out yes
12:41 <ncopa> seems like there are more s390x packages that needs fixing
12:43 <ncopa> alias__ i think we might have a wkhtmltopdf package
12:43 <Shiz> we do, but they specifically need an old version for some reason
12:43 <ncopa> ok
12:44 gromero joined
12:49 grayhemp joined
12:54 Dick_Hammer joined
12:56 ncl joined
13:05 alex88 joined
13:05 <alex88> Hi there, is there a workaround on this? https://bugs.alpinelinux.org/issues/7273
13:05 <alex88> I've tried --allow-untrusted but it doens't work
13:05 <parazyd> ncopa: is xorg running as root intentional in alpine?
13:06 <Shiz> alex88: one of the mirrors is having issues
13:06 <Shiz> please do not use --allow-untrusted as a workaround :P
13:06 <Shiz> alex88: try changing your mirror to nl.alpinelinux.org
13:06 <alex88> Shiz: thank you :) will try that
13:06 <Shiz> with docker, something like sed -i 's/dl-cdn/nl/g' /etc/apk/repositories will work
13:08 <alex88> I was going to do a cat << EOF > /etc/apk/repositories
13:08 <alex88> but thank you for giving the oneliner :D anyway, that works, thank a lot!
13:11 ogres joined
13:12 czart__ joined
13:13 <avih> dalias: so tcc now works with musl. i still have an issue though if stdio.h (possibly others too) come before stdarg.h in the program. tcc has its own prioritized include dirs with stdarg.h. i'm trying to figure out musl's expectations with regards to this. i'm looking at bits/alltypes.h, does musl expects the compiler to have an intrinistic define of __DEFINED_va_list or __DEFINED___isoc_va_list ?
13:14 <avih> (if stdarg.h is included first then va_list et al work fine with tcc+musl)
13:15 <dalias> musl does not support compiler-provided std headers
13:15 <Shiz> dalias: even stdarg?
13:15 <dalias> the libc headers must come first in include path
13:15 <Shiz> or stdint?
13:15 <Shiz> :p
13:15 <dalias> yes
13:15 <avih> what's the relation between the compiler's va_list and musl?
13:15 <Shiz> i thought some stuff came from the compiler
13:15 <dalias> no, that's a glibcism
13:15 <dalias> bsd doesn't work that way and musl doesn't either
13:16 <avih> dalias: so how should the compiler expose it such that it can be used correctly?
13:16 <Shiz> it should provide the right primitives
13:16 <dalias> by providing the intrinsics (__builtin_va*)
13:16 <Shiz> musl relies on __builtin_va_list and the likes
13:17 <avih> gotcha.
13:17 <dalias> or you could use a silently pre-included header to define them as macros
13:17 <Shiz> parazyd: right now, i believe so
13:17 <dalias> but that's a hack
13:17 <Shiz> since there has simply not been resources/work on making it run not as root
13:17 <dalias> the compiler itself could just predefine them as macros if it doesn't want real intrinsics
13:17 <Shiz> but (at least I would) very much welcome efforts towards this
13:17 <Shiz> :)
13:17 <avih> dalias: you mean instead of using stdarg.h in a prioritized dir?
13:17 <dalias> yes
13:17 <avih> k, thx
13:20 t0mmy joined
14:03 aw1 joined
14:10 tkharju joined
14:11 <ncopa> parazyd: xorg as root is sort of intentional. I havent get to fixing it to work as non-root yet
14:13 dave0x6d joined
14:14 <Bun> does screen on alpine support 256 colors?
14:19 <ncopa> Bun i would believe so. what is required for 256 color support?
14:20 <ncopa> how can i test it?
14:22 fabled joined
14:22 <Bun> with term screen-256color in my .screenrc and this script: https://askubuntu.com/questions/821157/print-a-256-color-test-pattern-in-the-terminal it does not work
14:24 grayhemp joined
14:25 <Bun> there's a config option --enable-colors256 which the APKBUILD does not use
14:25 <Bun> I don't know if this implies any additional dependencies
14:27 <ncopa> Bun looks like you are right
14:27 <ncopa> tmux has 256 color support
14:27 <ncopa> i'll fix it
14:27 <Bun> great, thanks
14:28 <Shiz> yep it's not autodetected
14:28 <Shiz> also
14:28 <Shiz> AC_ARG_ENABLE(telnet, [ --enable-telnet enable builtin telnet])
14:28 <Shiz> what the fuck
14:28 <ncopa> ha
14:29 <Bun> wow that's actually a thing
14:29 <Shiz> it also apparently has PAM support
14:29 <Shiz> don't even want to know
14:29 <Bun> locking maybe?
14:30 cyteen joined
14:30 <Shiz> i lied, i do want to know
14:30 <Shiz> it's locking, yeah
14:30 <Shiz> /* -- original copyright by Luigi Cannelloni 1985 (luigi@faui70.UUCP) -- */
14:30 <Shiz> hot damn that email
14:31 mattaitchison joined
14:39 <avih> dalias: i'm seeing a warning when using tcc which does not show when using gcc, and i'm not sure who's at fault. the files which i'm building don't define/refer to this symbol directly (minor spam):
14:39 <avih> In file included from audio/out/ao_oss.c:46:
14:39 <avih> In file included from /usr/include/sys/soundcard.h:1:
14:39 <avih> In file included from /usr/include/linux/soundcard.h:40:
14:39 <avih> In file included from /usr/include/linux/ioctl.h:4:
14:39 <avih> In file included from /usr/include/asm/ioctl.h:1:
14:39 <avih> /usr/include/asm-generic/ioctl.h:77: warning: _IOWR redefined
14:40 <avih> the same warning happens for _IOC, _IO, _IOR, _IOW and _IOWR
14:42 <avih> /usr/include/sys/soundcard.h is a single line: #include <linux/soundcard.h>
14:48 <avih> dalias: maybe imcompatible guards somehow? linux/ioctl.h guards with _LINUX_IOCTL_H . i couldn't figure out yet where the prior definition comes from
14:49 <Shiz> (please use a pastebin)
14:49 <avih> yeah, in general i should, possibly here too, though i'm done with those :)
14:49 <Shiz> where does it mention the previous definition being?
14:50 <avih> Shiz: it doesn't say
14:50 <Shiz> right, then it's the same file
14:50 <avih> and it also doesn't happen with gcc
14:50 <Shiz> try just preprocessing the file
14:50 <Shiz> if tcc has an option for that
14:51 <Shiz> and paste the output of that somewhere
14:51 <avih> it does have -E, but i'm not there yet :)
14:51 <avih> (i need to figure out the exact invocation of the compile for that)
14:52 Tritlo joined
14:52 <avih> fwiw, mpv builds fully with tcc, after very(!) little tinkering with mpv. and it also works fine. audio and opengl and all.
14:53 <avih> on alpine, that is.
14:53 <avih> these _IO* warnings are the only issue left
14:54 cyborg-one joined
14:58 ZucZero joined
15:04 <avih> (though mpv doesn'tt built with its own build system - waf - which doesn't support tcc. i used unofficial configure and Makefile which mpv's maintainer still uses himself)
15:16 help-im-stuck joined
15:16 aw1 joined
15:17 <Unode> Hi guys, I'm getting "BAD signature" errors on a couple of packages. ERROR: libuuid-2.28.2-r1, libblkid-2.28.2-r1: BAD signature
15:18 <Unode> this started sometime early today.
15:19 <Unode> This is on alpine:edge with "@testing http://dl-cdn.alpinelinux.org/alpine/edge/testing"
15:19 <clandmeter> hi
15:19 <clandmeter> did you report that also earlier?
15:20 <Unode> no. Someone else perhaps.
15:20 aw1 joined
15:21 <clandmeter> Unode, which arch?
15:21 <Unode> This is using docker with the alpine:edge image.
15:21 <Unode> x86_64
15:22 <Unode> clandmeter: http://dpaste.com/2A8W590
15:22 <Unode> if it helps
15:22 <Unode> those were the revisions that failed by the way.
15:25 <clandmeter> Unode, what if you use another mirror?
15:26 <Unode> Shouldn't they all be equivalent?
15:27 <clandmeter> in principle yes
15:27 <clandmeter> but its a cdn
15:27 <clandmeter> it does caching
15:28 <Unode> so what you are saying is that it's likely fixed already but the bad version is still cached?
15:29 grayhemp joined
15:29 <clandmeter> i fisrst would need to know if another mirror works for you
15:29 Zucca joined
15:30 <Unode> any suggestion?
15:32 <clandmeter> try cz.alpinelinux.org
15:33 <Unode> that worked
15:34 <Unode> it's actually the main channel that has issues.
15:36 <Unode> and interesting. They are both v3.5.0-4813-g5fafd50b76 but http://dl-cdn.alpinelinux.org/alpine/edge/main fails
15:39 Skele joined
15:40 grayhemp joined
15:46 grayhemp joined
15:59 <Shiz> dl-cdn is still having issues yes :(
16:05 <ncopa> which package?
16:05 <ncopa> which arch
16:06 <Unode> ncopa: mines are mentioned above
16:06 <ncopa> libuuid
16:07 lesion joined
16:07 <ncopa> # apk verify libuuid-2.28.2-r1.apk
16:07 <ncopa> libuuid-2.28.2-r1.apk: 0 - OK
16:10 <clandmeter> ncopa, how do you know you are using the same cache?
16:11 <Unode> libuuid is no longer failing. libblkid still fails
16:12 <Unode> whatever you did, it helped.
16:23 <ncopa> i can not be sure i am using the same cache
16:24 <ncopa> i checked the package on dl-4.a.o
16:24 <ncopa> which is the backend for dl-cdn
16:29 <Unode> Thanks ncopa, purging the dl-cdn worked once I had the correct URL
16:30 <Unode> with: curl -X PURGE http://dl-cdn.alpinelinux.org/alpine/edge/main/x86_64/libblkid-2.28.2-r1.apk
16:31 <Shiz> that seems odd
16:35 dave0x6d joined
16:36 <ncopa> sounds like corrupt cache
16:45 grayhemp joined
16:47 jid joined
16:50 <jid> Hi. If I had an idea to use alpine as Xen-dom0 on my laptop using X forwarding over ssh to test different DomUs. Will it be a security risk? Is there any support for cpu scaling and/or S3 suspend in the host?
16:52 Sadale joined
16:56 sergey_ joined
17:01 <Xe> ncopa: i'm seeing dl-cdn error for apk updates: https://travis-ci.org/PonyvilleFM/aura#L419
17:01 <ncopa> Xe yes, i have seen it too
17:02 <Xe> +1 just making sure
17:02 <ncopa> i get full panic messages from everywhere atm
17:02 <ncopa> :-/
17:05 <kaniini> we could set up an anycast mirror @ work to replace dl-cdn if interested
17:08 <Xe> ncopa: if there's anything I can do on my end to help, lemme know
17:08 <Xe> no panic over here
17:11 <Diftraku> kaniini: did you mean bunnycast mirror :3
17:11 jmmarron joined
17:13 <jmmarron> hello
17:14 <Xe> hi jmmarron
17:14 <jmmarron> is the alpine cdn down?
17:15 <Xe> yeah there's known issues with it, if you need to install stuff use another mirror of the time being, they're trying to restore it
17:15 <jmmarron> any estimation on when this will be solved?
17:15 <Xe> when it's fixed and no sooner
17:16 <Xe> jmmarron: http://dl-3.alpinelinux.org/alpine/v3.5/main works in the time being
17:16 <xentec> or # setup-apkrepos
17:17 <jmmarron> thanks
17:17 <Xe> no problem
17:19 tree6014 joined
17:21 kaniini_ joined
17:21 Topic for
17:21 jhyelton joined
17:23 flazz joined
17:24 <flazz> in alpine 3.4, i have a ruby script complaining that it cannot verify a server's ssl cert, but openssl seems to verify fine. are they using different certificates?
17:27 <Xe> flazz: paste error messages?
17:28 blackwind_123 joined
17:29 atlad003 joined
17:29 bwagner_ joined
17:30 <flazz> Xe: https://pastebin.com/cRq54kUD
17:30 <bwagner_> hello! I am getting timeouts (503) when trying to fetch the APKINDEX from (http://dl-cdn.alpinelinux.org/alpine/v3.4/community)
17:31 <Xe> flazz: did you install `ca-certificates`?
17:31 atlad003 joined
17:31 <Xe> bwagner_: Alpine CDN is down, known issue, no ETA for fix, use alternate mirrors in the meantime
17:31 <bwagner_> is this a known issue and are there any official mirrors I can use? (I couldn't find any on the wiki or the site)
17:31 <flazz> Xe: yes
17:31 <Xe> http://dl-3.alpinelinux.org/alpine/v<numerical version>/<repo>
17:32 <bwagner_> Xe: thank you!
17:32 <flazz> how does one change from dl-cdn to dl-3 ?
17:32 <Xe> flazz: /etc/apk/repositories
17:34 <felixsanz> i installed rxvt-unicode-patched and looks so much worse than the rxvr-unicode package, why?
17:34 <felixsanz> wrong channel sorry xD
17:35 <Xe> is it the font letter spacing issue?
17:35 aemadrid joined
17:35 <Xe> you need something like https://github.com/Xe/dotfiles/blob/master/.Xdefaults#L20 to fix that fwiw felixsanz
17:37 <xentec> Xe, if you redirect everyone to dl-3 it'll be down too ;)
17:37 <Xe> xentec: the mirror was chosen by fair dice roll
17:38 <bwagner_> Xe: xentec: that mirror is unavailable too and now the wiki is down :o
17:39 <Xe> bwagner_: acquire more alcohol, it's gonna be a long day
17:39 <xentec> Xe: Told you so! :D
17:39 iadknet joined
17:40 grayhemp_ joined
17:40 <bwagner_> Xe: yes, hanging on tightly :)
17:41 grayhemp_ joined
17:41 <bwagner_> Xe: got my cachaca ready
17:41 <Unode> the heck guys. today the mirrors are having a lot of issues. http://dl-cdn.alpinelinux.org/alpine/edge/main/x86_64/APKINDEX.tar.gz is now 503 timeout and then 503 Backend is unhealthy
17:42 gopar joined
17:42 <Xe> Unode: Alpine CDN is down, known issue, no ETA for fix, use alternate mirrors in the meantime
17:42 <Unode> and now seems back to normal again.
17:43 <Xe> computers break, patience
17:43 kaniini_ joined
17:44 <Unode> Xe: yes not complaining. Just hinting that there might be some hardware issue behind it. Thanks for looking into it.
17:44 <felixsanz> Xe: but thats for the patched version?
17:44 <kaniini> it's a fastly issue
17:44 <felixsanz> mm, it looks even worse
17:44 <bwagner_> for whoever is having trouble, I managed to make it work with this mirror (from a brazilian university): http://ns2.c3sl.ufpr.br/latest-stable/main/
17:44 <Unode> Is there any way to configure apk to automatically fallback to another mirror if one fails for some reason?
17:44 orbiter joined
17:45 <kaniini_> Unode: unfortunately not, but i will work on it
17:46 <Unode> kaniini_: that would be great and improve reliability. Like possibly many users out there I use alpine for continuous integration and today was a sad day with a lot of red :)
17:47 <kaniini_> Unode: we are probably going to drop fastly for the CDN mirror. i can set up an anycast mirror to replace it.
17:47 <* kaniini_> literally has people working on the specifics of that right now
17:47 <Unode> thanks!
17:47 <Xe> kaniini_: can you make it use HTTPS too?
17:48 <kaniini_> fuck no
17:48 <Unode> :D
17:48 <kaniini_> go burn somebody else's CPU
17:48 <kaniini_> everything is signed, there is literally no point in using TLS on top of that except to encrypt it
17:48 <Unode> fair point
17:49 <xentec> the https meme is strong nowadays..
17:50 <kaniini_> yes
17:50 <kaniini_> TLS certificates are free
17:50 <kaniini_> because of lets encrypt
17:50 <kaniini_> but if you consider how busy an alpine mirror is (especially dl-cdn), TLS is insane :P
17:51 <arch3y_> about how much traffic is done monthly
17:51 <arch3y_> just curious
17:51 <kaniini_> i have no idea honestly, but literally whenever fastly screws up, people show up literally in seconds
17:51 <kaniini_> soooo
17:51 <kaniini_> i am assuming it is pretty busy ;P
17:51 <arch3y_> yeah thats good
17:51 aw1 joined
17:52 <arch3y_> I used to run a mirror netowrk and we did around 2T a month which wasnt bad
17:52 <IcePic> the load on decent cpus isnt that bad anymore.
17:52 <arch3y_> but we didnt have the community that you guys
17:52 <xentec> but it's still load, IcePic
17:52 <arch3y_> most of the time the boxes were doing close to 50-100Mpbs at times but it wasnt doing too much
17:52 <arch3y_> but thats probably small numbers compared to you guys
17:53 pwright joined
17:53 cyteen joined
17:53 <kaniini_> IcePic: it's unnecessary load. TLS does not protect you any more than the signatures already
17:53 <vifino> Many people seem to want https on sites which don't need it. Why would anyone need encryption on a public site with no login possibility?
17:53 <IcePic> I'm not trying to argue that TLS will give you much, just saying that modern CPUs handle it rather well
17:55 <ncopa> dl-cdn should be back now
17:55 <IcePic> our backupserver at work only accept TLS'ed connections and it does around 100MB/s per core (ie, per stream sent from clients)
17:55 <ryonaloli> vifino: to prevent people from tampering with the contents of the site
17:55 <ryonaloli> i've fucked with people's unencrypted sites and given them quite the scare, along with more malicious things.
17:56 <IcePic> so as long as noone wants single streams faster than normal gig link, you're fine. =)
17:56 <ryonaloli> including sites which were completely public
17:56 <ryonaloli> static webpages
17:56 <kaniini_> sure
17:56 <kaniini_> however
17:56 <IcePic> BUT, as long as the stuff you get is checksummed and validated otherwise, the transport doesnt matter
17:56 <kaniini_> that isn't relevant here as the packages and indices are *signed*
17:56 <ryonaloli> never been able to do so on pages which used tls (excepting badly broken tls, i imagine it'd be easy to do that)
17:57 <ryonaloli> kaniini_: oh is this about downloading packages over tls?
17:57 <kaniini_> yes
17:57 <ncopa> yes
17:57 <xentec> yes
17:57 <Xe> yes
17:57 <ryonaloli> does the package manager do anything before verification?
17:57 <kaniini_> they can MITM a backdoor into a package all they want, but it won't do any good because the signature check will fail
17:57 <ryonaloli> e.g. decompressing
17:57 <kaniini_> no
17:58 <ncopa> i think signature is compressed, so yes we decompress before verifying
17:58 <ryonaloli> ncopa: compressed like, gzip compressed? or internal signature compression like ed25519 being "compressed"?
17:58 <kaniini_> ncopa: checksum is checked against the index before decompression though
17:58 <ncopa> its checked while decompressing
17:59 <ncopa> but yes, checksum in index
17:59 <ryonaloli> then it has a greater attack surface area than with tls
17:59 <ryonaloli> potentialy
17:59 <ryonaloli> *potentially
17:59 <ncopa> yes
17:59 <kaniini_> not worth the expense on the mirrors to have TLS though
17:59 <ryonaloli> since you could exploit the decompressor as well as the signature verification tool
17:59 <ncopa> yes
17:59 <xentec> but you need to compromise the system first
18:00 <ncopa> his point is that its easier with http
18:00 <ryonaloli> plus tls would be useful for paranoid people who do not want the specific things they are downloading to be known.
18:00 <kaniini_> ok
18:00 <kaniini_> well
18:00 <ryonaloli> for example, you download a known vulnerable network facing daemon.
18:00 <kaniini_> whoever wants to front the money for that
18:00 <ncopa> i still dont know if https for apk mirrors is worth it
18:00 <ryonaloli> ncopa: use a light tls suite then
18:00 <kaniini_> to pay for TLS-enabled mirrors and the hardware upgrades the mirror operators would need to make TLS inexpensive
18:01 <kaniini_> anyway, i'm out of this conversation
18:01 <Bun> well, TLS doesn't hide size, and I bet the plaintext is fairly predictable, so you could guess what someone is downloading even with TLS ;p
18:01 <ryonaloli> chacha20-poly1305 or aes128-gcm and ecdhe with curve25519 or secp251
18:01 <kaniini_> blah blah blah grsec blah blah blah lolicon blah blah blah security
18:01 <ryonaloli> Bun: indeed, and that's a big issue with tls
18:01 <Bun> so clearly, alpine needs to start padding packages!
18:01 <ryonaloli> but it requires having a database of the file sizes and keeping such a database up to date
18:02 <kaniini_> Bun: yes i propose a 16GB pad for each package
18:02 <ryonaloli> pad all packages to the size of the largest package!
18:02 <ryonaloli> but then that leaks when you are updating
18:02 <xentec> kaniini_: how often does the tls discussion happen here? :D
18:02 <kaniini_> each package will now be 16GB
18:02 <ryonaloli> so let's transfer dummy updates every 5 minutes
18:02 <feuerteufel> Hi @ all
18:02 <kaniini_> xentec: "discussion"
18:02 <TBB> often
18:02 <ncopa> ryonaloli thanks for your feedback
18:02 <ryonaloli> lol
18:02 <ncopa> we will consider enabling tls
18:03 sebumd joined
18:03 <TBB> funnily enough I'm just working on running our internal repositories on https
18:03 <ryonaloli> ncopa: i assume the servers have aesni?
18:03 <ryonaloli> and pclmulqdq?
18:03 <ncopa> i dont have controll over all mirrors
18:03 <ryonaloli> (in cpuinfo0
18:03 <ryonaloli> *)
18:03 <kaniini_> our servers are hosted by NSA as directed by Trump himself
18:03 <kaniini_> i am being sarcastic :)
18:04 <IcePic> nah, then you would be using russian GOST crypto on them
18:04 <IcePic> =)
18:04 <sebumd> Is there a workaround for the CDN issue? Lol this is my first time using the alpine docker images and it's not a good look for the rest of my team :)
18:04 <ncopa> ryonaloli: how is tampering with static generated pages easier with http over https?
18:04 <ncopa> sebumd it should be back now
18:04 <xentec> sebumd: bad luck, but should be working
18:04 <ryonaloli> ncopa: because https provides integrity
18:04 <ncopa> sebumd sorry about that :-(
18:04 <kaniini> hm
18:05 <ryonaloli> i mean if it's http, then you can just mitm it and inject whatever you want
18:05 <ryonaloli> otherwise it's opaque
18:05 <kaniini_> you can do that with TLS too
18:05 <kaniini_> for only $99.95 comodo will happily sign whatever you want
18:05 <ryonaloli> heh
18:05 <ryonaloli> well there's always hpkp :P
18:05 <ryonaloli> and for something like alpine, you can just pin the keys
18:06 <ryonaloli> *pin the fingerprint
18:06 <kaniini_> is this the part where you propose using DANE and then secure DANE using DNSSEC too?
18:06 <kaniini_> ;)
18:06 <IcePic> ryonaloli: I think you mean well, but I don't believe they need to get more of "you can just do this, you can do that.."
18:06 <sebumd> Hmm ncopa: Trying to apy add mongodb, am I doing something wrong?
18:06 <ncopa> sebumd what error do you get?
18:07 <IcePic> by all means, set up an https alpine and see how it fares. but asking $someone else to do all the work isnt really nice.
18:07 <kaniini_> IcePic: yes, we can 'just' fork grsec and have it be 'instantly' as good as the original
18:07 <kaniini_> IcePic: so we should 'just do it'
18:07 <sebumd> ncopa, Error: unsatisfiable constraints: mongodb (missing) required by world[mongodb]
18:07 <TBB> if I can ever get any performance stats on hosting repos on https I'll be glad to share them
18:07 <ncopa> would be interesting to know the exact cost for https
18:07 <ryonaloli> IcePic: it's not like it's difficult to do
18:08 <feuerteufel> does anyone Know if the Alpine-Kernel supports frequency scaling and am I able to use that also on a XEN (dom0) installation?
18:08 <ryonaloli> i think the problem they're facing is the performance issue
18:08 <kaniini_> TBB: i dont think it is that bad, and if mirror operators wish to support TLS, i think we should record it
18:08 <IcePic> ryonaloli: nothing that is set on someone else ever is.
18:08 <kaniini_> TBB: but i don't think we should also say "TLS is required for alpine mirrors"
18:08 fabled joined
18:08 <ncopa> but, even if we do https for all our mirrors
18:08 <ryonaloli> and that's something i don't know. it depends on if they have aesni and pclmulqdq.
18:08 <ncopa> what about rsync://
18:08 <kaniini_> rsync over ssh obviously
18:08 <TBB> yeh, I'm not too sceptical about the performance per se
18:09 <ncopa> pointless to enforce https unless we fix rsync first
18:09 <kaniini_> it's not about the performance, it's about getting the mirror operators to do it
18:09 <kaniini_> and, hahaha, you cant get me to fight that battle
18:10 <ncopa> also https and rsync+ssh does not solve the issue when a mailcius mirror admin injects things
18:10 <kaniini_> it's okay
18:10 <kaniini_> we just solve that by requiring the mirror admin submit their social insurance number when applying
18:10 <kaniini_> then if they inject malicious things
18:10 <ncopa> :)
18:11 <kaniini_> we just go open a $100,000 credit card in their name
18:11 <iadknet> The CDN issue helped me uncover an inefficient ordering of one of our docker images (we were reinstalling git on every build by having it too low in the dockerfile)... so, thanks! :D
18:11 <kaniini_> and use it to fund development
18:11 <Bun> will they be posted on the wiki? because how else do I know to trust them as an end user
18:11 <sebumd> Also ncopa: this is the alpine:latest docker image that I'm running this in
18:11 <ncopa> my point is, https alone does not not solve all worlds problems
18:11 grayhemp joined
18:11 <kaniini_> Bun: no, but the credit card will be.
18:11 <kaniini_> :D
18:12 <ncopa> sebumd: i will check
18:12 <Unode> kaniini_: go watch http://www.imdb.com/title/tt3173594 it matches.
18:12 <sebumd> ncopa, this link helped, but I'm not sure why I had to do it: https://forums.docker.com/t/docker-apk-package-for-alpine-linux-has-an-unresolved-dependency-to-libseccomp/9604/2 ("Or in one command..")
18:12 grayhemp joined
18:13 <kaniini_> Unode: that seems awful
18:13 <kaniini_> oh
18:13 <kaniini_> ncopa is also not thinking too widely
18:13 <Unode> it's a pretty shitty movie but the story line fits.
18:14 <kaniini_> what if some alpine developer goes rogue
18:14 <kaniini_> and pushes a package that has rm -rf /* in post-install
18:14 <kaniini_> my point is
18:14 <Bun> guess I'm gonna install my updates in a VM first..
18:14 <kaniini_> at some point, using binary packages
18:15 <kaniini_> incurs some sort of risk
18:15 <ncopa> +1
18:15 <ncopa> and you have to calculate the cost vs the benefit (or risk)
18:15 <Unode> Well... using any distro out there incurs in risk :)
18:16 <ncopa> exactly
18:16 <ncopa> but if you use a distro that uses https only, then you are perfectly safe!
18:16 <Xe> (i only really have https set up for my alpine packages because my setup makes it harder to not setup https than it is to setup https)
18:16 <kaniini_> i think a malicious dev is more concerning than a malicious mirror admin
18:16 <ncopa> kaniini_ because they can do more damage
18:16 <kaniini_> now to be clear
18:16 <kaniini_> it is very hard to become an alpine dev
18:17 <kaniini_> it is a process that takes most people literally years
18:17 <kaniini_> so the odds of that happening are hopefully quite low
18:17 <kaniini_> but it's still more likely than a malicious mirror admin imo
18:17 <kaniini_> because it's easier to do
18:18 <kaniini_> a malicious package from a mirror admin has to have the right size and checksum in the APKINDEX, and the right signature itself
18:18 <xentec> kaniini_: how would malicious mirror admin even work? The packages are signed by buildservers, aren't they?
18:18 <kaniini_> or, alternatively, it has to have 0day exploit code that can break the decompressor (zlib)
18:19 Topic for
18:19 <kaniini_> xentec: in theory, if they could exploit zlib they could bypass the security in some theoretical case that seems not likely to be fixable
18:19 <TBB> so, what does attacking via a mirror require... re-signing all packages using self-generated keys placed in a specially crafted alpine-keys package and a self-signed index (since you pretty much have to start the install with --allow-untrusted)=
18:19 <TBB> ?
18:20 <kaniini_> you dont have to start the install iwht --allow-untrusted
18:20 <ncopa> re package sizes
18:20 <ncopa> the size is in index
18:20 <kaniini_> that's just what silly people do
18:20 <ncopa> and i think apk uses that
18:20 <kaniini_> it does
18:20 <ncopa> so we could have a max size for index
18:20 <TBB> silly people, or people unable for whatever reason to run the install on a platform other than Alpine
18:20 <Xe> TBB: set up something like https://github.com/Xe/aports/blob/master/core/xeserv-keys/APKBUILD
18:21 <kaniini_> TBB: they can download the keyring package itself
18:21 <xentec> TBB: https://git.alpinelinux.org/cgit/aports/tree/main/alpine-keys
18:21 <xentec> has even https in it :D
18:22 <TBB> (of course those concerned with security will pre-check the keys used in any case, and those who don't can blame themselves)
18:24 <TBB> I mean, you do check the signatures of the install images too, it's in no way different from installing from packages
18:26 <TBB> Xe: naturally I do that in our environment :)
18:29 grayhemp joined
18:29 <shodan45> how's everyone in alpine land?
18:29 <shodan45> wait for it.... "cold!"
18:29 <IcePic> tls-encrypted we're not.
18:29 <IcePic> ;)
18:29 <shodan45> get it? :P
18:30 <* kaniini> gets the hook
18:30 <* shodan45> bows
18:30 <* kaniini> removes shodan45 from the stage with said hook
18:35 <xentec> ncopa: on edge without cache: (1/1) [APK unavailable, skipped] Reinstalling libblkid (2.28.2-r1)
18:35 <xentec> I thought this was fixed?
18:35 jhyelton joined
18:38 cyborg-one joined
18:40 <ncopa> xentec got bigger issues. the backend for dl-cdn died
18:40 <ncopa> it crashed, rebooted then died again
18:40 <ncopa> we are working on it
18:41 <xentec> I tought both issues were connected but ok.
18:41 <xentec> hang in there!
18:59 ingo___ joined
19:13 cyteen joined
19:16 <Shiz> ncopa: can we at least put dl-cdn on another mirror in the meantime
19:16 <Shiz> or did we do that already
19:16 <Shiz> :p
19:37 blueness joined
19:41 <ncopa> we did already
19:41 <ncopa> should be working now
19:43 jhyelton joined
19:59 jhyelton joined
20:08 gopar joined
20:09 grayhemp joined
20:18 ppisati_ joined
20:19 jhyelton joined
20:20 k0nsl joined
20:20 k0nsl joined
20:23 ppisati joined
20:24 nurupo9 joined
20:25 nurupo9 left
20:31 jhyelton joined
20:34 jhyelton joined
20:44 grayhemp joined
20:49 blackwind_123 joined
21:01 jhyelton joined
21:07 jhyelton joined
21:12 jid joined
21:19 jhyelton joined
21:30 jhyelton joined
21:30 grayhemp_ joined
21:34 jhyelton joined
21:36 grayhemp joined
21:57 gopar joined
22:12 grayhemp joined
22:18 kunev joined
22:25 tmh1999 joined
22:37 dirac1 joined
22:41 tugrik joined
22:45 blueness joined
22:48 arenstar joined
22:54 lesion joined
22:54 boojinks joined
22:55 <boojinks> Hey guys. Has anyone got any ideas on how to view the contents of my efivars?
23:04 <xentec> boojinks: # mount -t efivarfs efivarfs <mountpoint>
23:06 <boojinks> xentec: they're mounted but binary so cat just corrupts the terminal - was wondering if there was any easy tool to read them/anyone knows the encoding?
23:06 <xentec> less?
23:12 emacsomancer joined
23:35 atlad003 left
23:44 grayhemp joined
23:58 iadknet_ joined