<     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:01 <rfs613> FAQ seems to be here: https://www.opensmtpd.org/faq/index.html ... and it says "is only intended to be used as a supplement to the man pages"... the man pages are eg http://man.openbsd.org/smtpd
00:02 poptart joined
00:02 poptart joined
00:02 <jirutka> hm, I haven’t read that :(
00:02 <jirutka> I’m too tired now
00:02 <rfs613> there isn't much in that man page unfortunately, but there are other man pages related, such as snmpctl
00:02 <rfs613> and perhaps this one: http://man.openbsd.org/smtpd.conf.5
00:02 <jirutka> but still this is NOT how FAQ should look like and it’s wrong that it contains *almost* complete list of keywords
00:03 <jirutka> this http://man.openbsd.org/smtpd.conf.5 contains that important rcpt-to option
00:03 <jirutka> afk
00:11 BitL0G1c joined
00:28 <Shiz> jirutka: i agree that it may be a bit confusing yes
00:29 <rfs613> perhaps they should remove every other keyword from the FAQ then ;-)
00:48 blueness joined
01:11 <Shiz> ncopa: kaniini: relevant changes to alpine-conf PR'd
01:11 <Shiz> :)
01:12 <kaniini> ok
01:12 <kaniini> i'll check in a bit
01:13 <Shiz> no rush
01:15 tmh1999 joined
01:17 <jirutka> and brief show-up how to install Mailman 3 Suite on Alpine :P https://gitlab.com/mailman/mailman-suite/issues/3
01:29 s33se joined
01:48 s33se_ joined
03:02 nmatt joined
03:16 <kaniini_> hi
03:36 blueness joined
03:38 tmh1999 joined
03:52 blueness joined
04:39 blueness joined
05:03 fabled joined
05:14 D630 joined
06:20 vakartel joined
06:32 fabled joined
07:09 <xentec> wireguard-tools requires bash dependency for wg-quick but it's missing
07:27 <clandmeter> is that script mandatory for normal operations?
07:34 t0mmy joined
07:42 tty` joined
07:58 royger joined
07:58 rnalrd joined
08:02 <xentec> clandmeter: strictly speaking no, but it's extremely helpful for setting up wg interfaces (especially at boot time)
08:04 <clandmeter> any chance you can replace bashism with posix?
08:06 <xentec> this gonna take a while https://git.zx2c4.com/WireGuard/tree/src/tools/wg-quick.bash#n26
08:07 <mosez> the texlive package is missing http://www.tug.org/texlive/Contents/live/texmf-dist/scripts/texlive/mktexlsr.pl :(
08:11 <mosez> nvm, now it's failing with something else... :(
08:27 <Shiz> xentec: oh brother
08:27 <Shiz> may be quicker to even rewrite it
08:27 <Shiz> this is full of bashisms
08:27 minimalism joined
08:56 <clandmeter> yes it is
08:57 <scadu> hi
08:57 <scadu> https://github.com/alpinelinux/aports/pull/1388 would it be possible to merge this one? OpenVPN bump to 2.4.2
08:58 <mosez> hum... texlive@testing sucks :(
08:59 <scadu> would be nice to see 2.4.2 in 3.6. hope it wasn't frozen yet
09:03 <Shiz> if it's a security update, it won't be a problem
09:04 <Shiz> but I don't handle main, so cc clandmeter ;p
09:09 <scadu> clandmeter: could you please take a look at pr #1388 linked above?
09:09 <algitbot> Bug #1388: [v2.2] Vulnerability in freeradius &lt; 2.2.0 allow remote code execution - Alpine Linux - Alpine Linux Development: http://bugs.alpinelinux.org/issues/1388
09:09 <scadu> algitbot: stupid you :P
09:14 <xentec> just noticed that linux-headers are still on 4.4: https://git.alpinelinux.org/cgit/aports/tree/main/linux-headers/APKBUILD
09:31 <Shiz> xentec: fwiw i'm rewriting it because i'm bored
09:31 <Shiz> :p
09:32 <xentec> nice
09:51 <Shiz> xentec: do you have wireguard installed?
09:51 <xentec> yes
09:51 <Shiz> could you check the output for a few commands for me?
09:52 <Shiz> i don't have wg
09:52 <xentec> sure
09:52 <Shiz> # wg show <interface> fwmark
09:52 <Shiz> # wg show <interface> allowed-ips
09:52 <Shiz> # wg show <interface> endpoints
09:52 <Shiz> (feel free to anonimyze and stuff, i just need the format)
09:59 <xentec> Shiz: https://dpaste.de/8kia
10:00 <xentec> also fyi wg always shows IPs but can read hostnames as well
10:08 blueness joined
10:09 <Shiz> xentec: could you check if this prints the ips:
10:10 <Shiz> wg show "$INTERFACE" allowed-ips | sed -e 's/.*([0-9a-f:./]+)/\1/g' | sort -nr -k 2 -t /
10:10 <Shiz> ?
10:14 <xentec> Shiz: it prints pubkeys and ips. the regex is too greedy
10:14 <Shiz> oh
10:14 <Shiz> i forgot the $
10:14 <Shiz> could you add that and try again
10:15 <xentec> nope. but wg emity a \t between keys and ips so you could use that as a delimiter
10:15 <xentec> *emits
10:20 <Shiz> found something that works
10:20 <Shiz> wg show "$INTERFACE" allowed-ips | cut -f2- | tr ' ' '\n' | sort -nr -k 2 -t /
10:21 gromero joined
10:22 <xentec> yep, 1 row/ip
10:29 <coredumb> was there really a need for an Alpine CoC ?
10:30 <coredumb> just asking, not trying to stir up too much debate ;)
10:31 <xentec> where?
10:33 <coredumb> xentec: devel mailing list
10:33 <clandmeter> http://lists.alpinelinux.org/alpine-devel/201705byindex.html
10:35 <xentec> imho Code of Conflict > CoC :D
10:39 <Shiz> coredumb: immediate need right now, no
10:39 <Shiz> but these things are more for 'when you need em you're glad you have em'
10:39 <Shiz> imo
10:39 <Shiz> and i expect the community to grow :)
10:40 <coredumb> Shiz: OK :)
10:49 <Shiz> jirutka: is it intentional that llvm4-dev doesn't depend on llvm4-static
11:03 <^7heo> coredumb: please don't mix tech stuff and social, politically-drifting stuff
11:07 <xentec> and yet a proposal to put social, politically-drifting stuff into a tech project is made ;)
11:12 czart_ joined
11:14 <martanne> Hi, what is the Alpine package policy with regard to static Lua modules? It would be nice, if there were a package shipping lpeg.a. Currently the lua-lpeg package only contains the shared library.
11:16 <^7heo> xentec: not by me it isn't
11:17 <coredumb> ^7heo: how am I mixing? -devel mailing list -devel IRC channel ...
11:17 <^7heo> xentec: what I proposed is apolitical
11:23 <Shiz> ladies, please
11:24 <Shiz> let's chill
11:24 <Shiz> martanne: i wouldn't be opposed to them, but what's the direct use case for them?
11:24 <Shiz> honestly asking since i'm not that familiar with lua
11:28 <martanne> Shiz: I want to build a self contained binary of a project of mine. I currently have ugly build scripts for musl+all dependencies, but would like to replace them with a Dockerfile based on an Alpine image.
11:29 <Shiz> right, but how do static lua modules integrate?
11:29 <Shiz> i presume they're loaded by the lua interpreter?
11:31 <martanne> yes, you link a luaopen_<lib-nam> function into the C binary and register it in the Lua package loader
11:32 <martanne> https://github.com/martanne/vis/blob/master/vis-lua.c#L2440-L2447
11:35 cyteen joined
11:45 <martanne> Shiz: so technically it is not loaded by the Lua interpreter it is only referenced.
11:45 <martanne> But I just realized that in general Alpine's -dev packages do not ship static versions of the libraries. So this won't work the way I naively assumed :/
11:45 <Shiz> in general they should
11:47 <rfs613> martanne: (offtopic) I use your editor (on Alpine), it's nice. I changed the colors and syntax highlighting to be more vim-like (personal pref, I find solarized is hard to read)
11:47 <^7heo> wow, I didn't know vis.
11:47 <^7heo> Nice!
11:48 <^7heo> martanne: nice work!
11:49 <xentec> Shiz: if you're still working on wg-quick, could you also fix this line? https://git.alpinelinux.org/cgit/aports/tree/testing/wireguard-hardened/APKBUILD#n35
11:49 <xentec> s/grsec-/${_flavor}=/
11:49 <Shiz> ah yes
11:53 <martanne> Shiz: well libtermkey for example does not seem to do so
11:53 <^7heo> Do we have vis in alpine?
11:54 <martanne> rfs613: thanks, we have a themes wiki page now, feel free to add a reference to it
11:54 <martanne> ^7heo: yes there is a package
11:54 <^7heo> yeah I just installed it
11:54 ppisati joined
11:54 <^7heo> I'm gonna try that asap.
11:54 <^7heo> at least I know how to quit it
11:54 <^7heo> starts well.
11:57 freedomrun joined
12:01 <Shiz> martanne: if the package offers static libraries we package them in -dev, but maybe it needs a special configure switch to enable that we didn't pass
12:14 farosas joined
12:18 leitao joined
12:22 gromero joined
12:38 minimalism joined
12:41 tmh1999 joined
13:10 blueness joined
13:29 <pickfire> ^7heo: vis is cool
13:29 <pickfire> But kinda weird.
13:29 <^7heo> how so?
13:29 <pickfire> Like cursor on the back.
13:29 <pickfire> And left/right can move across lines.
13:30 <pickfire> rfs613: I like papercolor but papercolor on vis is super hard to configure.
13:38 mihnea joined
13:38 mihnea_ joined
13:48 <^7heo> < pickfire> Like cursor on the back.
13:48 <^7heo> What do you mean?
13:49 <^7heo> Wow, when I press escape, the cursor doesn't go back by one character.
13:49 <^7heo> Is there a way to change that?
14:03 cyteen joined
14:14 <^7heo> but really, vis seems MUCH faster than vim here.
14:15 <scadu> ^7heo: this is not suprising. check also kakoune, if you have a while
14:17 <scadu> vim has a baggage of dead and/or deprecated code and neovim isn't any better since, well, it's based on vim
14:18 <^7heo> tbh, I do not think kakoune is better for me either.
14:24 <pickfire> ^7heo: Yeah.
14:24 <pickfire> Tried kakoune, looks nice like vis but has it downfalls.
14:25 <pickfire> ^7heo: Haha, I think vim move the cursor back by one character.
14:26 <pickfire> I find kakoune pretty messy with whitespaces and as well get annoyed by that paperclip.
14:26 <pickfire> neovim is still much better.
14:26 <hiro> ed is fast
14:26 <pickfire> Just without the features of multiple edit like in vis or kakoune.
14:26 <pickfire> hiro: Yes, ed is fast. But not useful for all types of stuff.
14:27 <^7heo> pickfire: yes vi does move the cursor back by one character.
14:27 <^7heo> hiro: ed lacks the features I'm using
14:27 <pickfire> I like ed but if you don't do line edit, no good at all.
14:27 <^7heo> hiro: such as vim plugins.
14:27 <hiro> i never tried such :)
14:28 <rfs613> pickfire: yeah the way vim moves cursor back when exiting insert mode, it's weird... but when you get used to it, and it doesn't happen, it seems strange.
14:28 <pickfire> hiro: Tried editing a long line of json that you get on web with ed.
14:28 <hiro> for a long time i didnt even use vim, just plain old vi
14:28 <pickfire> rfs613: Yeah.
14:28 <hiro> people were outraged i didnt know features like line selection and stuff like that
14:28 <hiro> v V
14:28 <pickfire> And I like neovim ^v
14:28 <hiro> ah visual
14:28 <pickfire> vim*
14:28 <rfs613> vi is something you learn over many years.
14:29 <pickfire> hiro: What is that?
14:29 <rfs613> you start with how-the-BLEEP-do-i-get-outta-here and then work you way up slowly ;-)
14:29 <pickfire> You mean you can do v in ed?
14:29 <hiro> i never edit long lines of json. if i had to i'd introduce strategic line breaks
14:29 <^7heo> nah but for example, with vim, I can see the errors in my code as I save it.
14:29 <hiro> rfs613: why, vi is dead simple
14:29 <^7heo> if I forget a ; at the end of a line
14:30 <pickfire> I just don't like the fact that neovim's gv does not work well with ^v
14:30 <^7heo> or something like this
14:30 <^7heo> my vim setup will tell me.
14:30 <hiro> no, pickfire, i can't do v in vi, only in vim :)
14:30 <pickfire> Oh
14:30 <pickfire> hiro: If you are talking about vim, v is no surprised for me. I surprised my dad with ^v.
14:31 <pickfire> He don't know what is } and ^v
14:31 <hiro> ^7heo: crazy shit
14:31 <^7heo> hiro: right?
14:31 <^7heo> hiro: vim uses gcc to compile the code and parses its output to indicate the line and error in the editor.
14:31 <^7heo> hiro: I actually like it.
14:31 <hiro> haha :)
14:32 <hiro> i dont know what ^v is :)
14:32 <^7heo> it's visual line.
14:32 <hiro> or do i? might be muscle memory
14:32 <^7heo> a selection mode to apply things on.
14:32 <pickfire> hiro, ^7heo: Try this in vim, iMon<Enter>Tue<Enter>Wed<Enter>^vggI<p>gv$A^@
14:33 <hiro> i'll try later when i have actual vim access :)
14:33 <pickfire> And try gv + ^v + A again, notice that the cursor block append after the cursor.
14:33 <pickfire> ^7heo: What? No.
14:33 <pickfire> 22:32 < ^7heo> it's visual line.
14:33 <pickfire> It's visual block mode. V is visual line mode.
14:34 <^7heo> < pickfire> hiro, ^7heo: Try this in vim, iMon<Enter>Tue<Enter>Wed<Enter>^vggI<p>gv$A^@
14:34 <^7heo> http://ix.io/tvv
14:34 <^7heo> not really cool.
14:34 <pickfire> Oh, I forgot he <Escape>
14:34 <^7heo> yeah.
14:34 <pickfire> T_T
14:34 <^7heo> You did.
14:34 <^7heo> ;)
14:34 <hiro> ah yeah, i use visual block mode, too
14:35 <^7heo> Yeah visual block is really cool
14:35 <^7heo> helps a lot.
14:35 <hiro> see, vim is hard, lol
14:35 <pickfire> hiro, ^7heo: Try this in vim, iMon<Enter>Tue<Enter>Wed<Escape>gg^vGI<p>gv$A^@
14:35 <pickfire> That should do it.
14:36 <^7heo> Again
14:36 <^7heo> you missed another escape...
14:36 <hiro> ahha
14:36 <pickfire> hiro, ^7heo: Try this in vim, iMon<Enter>Tue<Enter>Wed<Escape>gg^vGI<p><Escape>gv$A^@
14:36 <^7heo> Thanks.
14:36 <pickfire> ^7heo: Well, you can put the escapes yourself.
14:36 <pickfire> ^^
14:36 <^7heo> (I already did that but thanks for actually giving the right command)
14:36 <^7heo> yeah no.
14:36 <pickfire> No?
14:36 <^7heo> I'm stupid as fuck when it's about reading commands from others.
14:37 <^7heo> I blindly type sudo rm -rf /* in my shell at all times.
14:37 <^7heo> pickfire: also, you want: iMon
14:37 <pickfire> haha
14:37 <^7heo> oops
14:37 <pickfire> Yeah, iMon is correct.
14:37 <pickfire> To <insert>Mon
14:38 <hiro> but he wrote that...
14:39 <pickfire> Well, maybe there's a more efficient way to do it, I don't know about that, but I just know that after you typed that, do gvA and look how annoying it is, it does not append after the cursor.
14:40 <hiro> i don't get what it's supposed to achieve
14:40 <hiro> but i'll try
14:40 <^7heo> pickfire: also, you want: iMon^MTue^MWed^[gg^vGI<p>^[gv$A^@
14:41 <^7heo> hiro: it's supposed to achieve <p>$day</p>
14:41 <pickfire> hiro: http://ix.io/tvw
14:41 <pickfire> ^7heo: Ah, that's right.
14:42 <^7heo> pickfire: I mean that's the real input for it.
14:42 <pickfire> ^7heo: There's no input, just output.
14:42 <hiro> oh, i thought p was a key
14:42 <hiro> haha
14:43 <^7heo> yeah no, that's why it's important to use the real escape codes.
14:43 <^7heo> the only problem then is to represent the ^ character.
14:44 <^7heo> pickfire: yes there is an input, it's: iMon^MTue^MWed^[gg^vGI<p>^[gv$A^@
14:44 <pickfire> Yeah.
14:44 <* pickfire> need to sleep
14:45 <pickfire> Good night, sleep tight and don't let the bed bugs bite.
14:45 <pickfire> \o
14:45 <^7heo> also for some reason it's now doing <p><p> as opposed to <p></p>
14:45 <hiro> night. i hope you'll find the right key combo to wake up again even if you have some emacs nightmare oO
14:46 <pickfire> ^7heo: If you need </p>, you need to type the whole thing out.
14:47 <^7heo> hmm
14:49 <pickfire> ^7heo: Especially, </strong> but of course I know you can do i</^x^i^[
14:49 <pickfire> For the completion of the inserted xml block.
14:49 <pickfire> Or ^x^o, I forgot.
14:51 <^7heo> I now have a headache.
15:00 fabled joined
15:15 <hiro> same
16:06 <martanne> Yes, vis does not aim to be bug-for-bug compatible with vi(m), instead it tries to combine modal editing with structural regexp. Anyway this is probably off topic here, move editor flamewars to #vis-editor.
16:06 <martanne> For my usecase I would need Alpine packages for statically build versions of libtermkey-dev (and indirectly unibilium-dev, alternatively libtermkey could also be linked against libterminfo) and lua-lpeg.
16:06 <martanne> I'm willing to spend some time on it myself, but somebody who is already familiar with Alpine packaging would probably be faster ;)
16:25 <^7heo> hmm
16:25 <^7heo> fair point
16:26 <^7heo> I'll see if I find the time this w/e, unless someone is faster than I
16:27 <^7heo> martanne: did I get it wrong or is there no ~/.visrc?
16:31 <martanne> ^7heo: there is one in ~/.config/vis/visrc.lua, see the man page or ":help Lua" for details.
16:48 tty` joined
16:52 <^7heo> yeah that's what I did, that's why I ask
16:52 <Shiz> i'm having "fun" with llvm
16:52 <Shiz> fucking tsan
16:53 <^7heo> no idea what that is
16:53 <Shiz> threadsanitizer
16:54 <Shiz> also I've been trying to build libc++abi and libc++
16:54 <Shiz> with full test suite
16:54 <Shiz> Expected Passes : 5067
16:54 <Shiz> Expected Failures : 27
16:54 <Shiz> Unsupported Tests : 546
16:55 <Shiz> Unexpected Failures: 86
16:55 <Shiz> not bad...
16:55 <Shiz> only 86 failures out of 5067 tests
16:55 <Shiz> :P
17:01 <^7heo> what about unexpected passes?
17:52 leo-unglaub joined
18:00 t0mmy joined
18:03 __0xAX joined
18:08 <jirutka> mosez: yeah, it’s known that texlive pkg is bad, but texlive is very big messy beast, so it’d require a lot of effort to really fix it (rewrite from ground)… I’d like to do it someday…
18:08 <Shiz> sup jirutka :)
18:11 <jirutka> Shiz: yes, it’s intentional that llvm4-dev does not depend on llvm4-static, for two reasons: llvm4-static is actually not always needed, and some stupid autodetections makes decision about type of linking based on existence of llvm’s static archives… but I don’t remember with which software I had this problem
18:11 <Shiz> ah okay
18:11 <Shiz> gotcha
18:12 <jirutka> martanne: I totally agree with shipping Lua static modules (in -dev pkgs)! actually it’d be handy even for myself quite soon, I’m about to finish my tool for packaging Lua scripts like self-contained statically linked executable
18:14 <jirutka> martanne: "in general Alpine's -dev packages do not ship static versions of the libraries" … that’s not exactly true, it depends, some -dev pkgs contain static libs
18:17 ^ingo^^^ joined
18:17 <jirutka> hmm, we already have vis pkg in community, great, I’m gonna try it soon! :)
18:21 <jirutka> martanne: so you’d like to add lpeg.a, that should not be problem… anything else?
18:23 <martanne> jirutka: the other thing is not Lua related: libtermkey (and dependencies)
18:25 <martanne> it can either be linked against the ncurses terminfo library (or as done in the current Alpine package against unibilium)
18:25 czart joined
18:31 <jirutka> martanne: okay, I’ll look at these two now
18:31 <jirutka> lpeg should be easy, don’t know about libtermkey
18:35 <martanne> thanks, it shouldn't be difficult either the lib is made up of 3 C files, but the build system uses libtool :/
18:35 <martanne> also there have been new upstream releases (0.20 vs 0.18 currently packaged by Alpine)
18:54 <jirutka> hm, I found a bug in Lua on musl…
19:00 <martanne> what is the problem?
19:01 <jirutka> os.setlocale() returns "C;C;C;C;C;C" instead of "C"
19:04 <jirutka> hm, but it’s not bug in lua, it just calls musl’s setlocale…
19:06 <jirutka> hm, not sure… maybe Lua calls it with wrong arguments
19:07 <Shiz> lots of Cs
19:08 <jirutka> heh, yeah
19:08 <jirutka> I’m just playing with setlocale from locale.h, to see how it behaves
19:10 <martanne> os.setlocale() in Lua results in setlocale(LC_ALL, NULL)
19:12 <hiro> ^7heo: what is ^@?
19:13 <martanne> This matches the Lua 5.3 documentation: "When called with nil as the first argument, this function only returns the name of the current locale for the given category.
19:13 <hiro> i think it's not that great to try and force doing every single text-related processing in vim. i would just do
19:13 <hiro> for day in Mon Tue Wed; do echo "<p>$day</p>";done
19:14 <hiro> though tbh i'd just propose <pre>
19:14 <hiro> Mon
19:14 <hiro> Tue
19:14 <hiro> Wed
19:14 <hiro> </pre>
19:14 <hiro> html is totally unneeded when what you want is just linebreaks.
19:14 <hiro> problems that shouldn't exist but require complex features in vim and so on
19:15 <hiro> i grew up with
19:15 <hiro> 'v' is not implemented
19:15 <hiro> so, i know there is alternatives
19:16 <hiro> even if i now use visual sometimes, i would have my ways around it. and i might even suspect that it normally would save time.
19:17 <jirutka> martanne: I know that, but setlocale("C") returns just "C" both on macOS and Fedora
19:17 <martanne> jirutka: POSIX only says "The string returned by setlocale() is such that a subsequent call with that string and its associated category shall restore that part of the global locale."
19:17 <jirutka> martanne: but "C;C;C;C;C;C" on musl
19:18 <jirutka> martanne: and that’s what musl setlocale(LC_ALL, "C") returns
19:18 <jirutka> LC_ALL = 6
19:19 <martanne> yeah, but if I'm reading the spec right the musl behavior is fine (according to POSIX)
19:20 <jirutka> yes, that’s my perception too
19:20 <jirutka> I’m thinking how to modify it in lua to return the same value as on other platforms
19:21 <jirutka> actually when I read description of LC_ALL, the musl’s behaviour seems to be more correct
19:21 <jirutka> (that’s actually not surprising)
19:25 <jirutka> hm, glibc says: "When you read the current locale for category LC_ALL, the value encodes the entire combination of selected locales for all categories. If you specify the same “locale name” with LC_ALL in a subsequent call to setlocale, it restores the same combination of locale selections."
19:26 <martanne> maybe it folds "C;C;C;C;C;C" into "C" (as long as all values are the same)
19:26 <jirutka> yes
19:27 <jirutka> when I change just ctype for example, then on Fedora os.setlocale() returns LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;…
19:29 <jirutka> lol
19:29 <^7heo> hiro: 0x1e
19:29 <jirutka> when I do the same on macOS: C/en_US.UTF-8/C/C/C/C
19:30 <jirutka> on Alpine: en_US.UTF-8;C;C;C;C;C
19:30 <martanne> yeah, I guess these locale representations are implementation defined. You shouldn't care about the exact values.
19:30 <jirutka> yeah
19:31 <jirutka> but one lpeg test asserts the exact value, that’s how i found that there’s something wrong/different
19:31 <martanne> then fix the test :)
19:31 <hiro> ^7heo: how do i type it?
19:32 <^7heo> ctrl and @
19:33 <^7heo> on a us kb, ctrl shift 2
19:33 <jirutka> I think that it’d be reasonable to modify loslib.c in lua to fold it into single value when all special locales are the same, ’cause that’s what both macOS/FreeBSD and glibc do
19:33 <hiro> ^7heo: ah, i can't type that
19:33 <hiro> ^7heo: on urxvt
19:33 <jirutka> can someone try this on OpenBSD? #include locale.h; setlocale(LC_ALL, "C"); printf(setlocale(LC_ALL, ""));
19:34 <martanne> jirutka: patching Lua seems wrong, if anything you should probably modify musl
19:34 <hiro> iso 14755 mode is triggered by ctrl-shift
19:34 <hiro> i always thought ^@ is \0
19:34 <hiro> but that made no sense
19:34 <hiro> what effect does it have here anyway?
19:38 <jirutka> martanne: I doubt that musl would accept such patch, their implementation is not wrong, just different
19:40 <martanne> yeah, but why "fix" it only in Lua vs everywhere? Lua doesn't guarantee a particular value either, so the current behavior seems fine.
19:41 <jirutka> hm, you’re right
19:41 <Shiz> should be fixed in lpeg
19:43 <jirutka> you mean in the test?
19:43 blueness joined
19:43 <Shiz> yeah
19:48 <martanne> jirutka: just change it to assert(os.setlocale("C"))
20:00 <jirutka> martanne: Shiz: does this makes sense? http://tpaste.us/Yner
20:01 <Shiz> i'd add a $(RANLIB) maybe
20:02 <jirutka> Shiz: RANLIB is not defined by default, so I’d need assign default value to it as well
20:02 <Shiz> yea
20:03 <jirutka> okay
20:03 <jirutka> aha, actually this makefiles defines even CC (actually hardcodes, env. provided is ignored)
20:03 <Shiz> does it?
20:03 <Shiz> e.g. CC = gcc is not a hardcode
20:03 blueness joined
20:04 <Shiz> :P
20:04 <jirutka> not? I thought that `CC ?= gcc` is needed to make it overridable
20:04 <Shiz> nope
20:04 <Shiz> :)
20:04 <Shiz> ?= takes it from the environment
20:04 <Shiz> but
20:04 <Shiz> e.g. make CC=gcc even overrides normal assignments
20:05 <Shiz> (as opposed to CC=gcc make, which puts it into the env)
20:06 <jirutka> aha
20:06 <jirutka> so basically you can override any variable defined in Makefile?
20:08 <skarnet> yes, if you declare them as make variables, not env variables
20:08 <skarnet> make CC=gcc -> CC is a make variable
20:08 <skarnet> CC=gcc make -> CC is an env variable which will be overridden by make variables
20:09 <skarnet> it's more complex than it needs to be, and it takes some getting used to, but it kinda makes sense and can be worked with.
20:09 <kaniini_> coredumb: the CoC proposal is largely to prevent some outsider from showing up and shoving some less desirable CoC on us
20:10 Emperor_Earth_ joined
20:11 <coredumb> kaniini_: just so that it's clear to me, what kind of outsiders are we talking about?
20:12 <jirutka> coredumb: do you need an example?
20:12 <jirutka> coredumb: https://bugs.ruby-lang.org/issues/12004
20:13 <coredumb> jirutka: ok
20:14 <kaniini_> that particular outsider seems unlikely to show up
20:14 <coredumb> indeed
20:14 <jirutka> for me this is the main reason why I’ve agreed with this CoC effort, to avoid similar situation as in Ruby and many other OSS projects where someone as Coraline came, started enormous shitstorm and basically *forced* her CoC to the community
20:15 <kaniini_> coredumb: essentially, we are just defining pre-existing policy as a formality, there's nothing to be concerned about
20:15 <coredumb> I'm sure you have someone in mind .... amm I wrong?
20:15 <kaniini_> no, it is just a precautionary measure for a few reasons
20:15 <coredumb> ok
20:16 <kaniini_> 1) to encourage trolls to go do their CoC troll somewhere else
20:16 <kaniini_> 2) to define specifically what is already disallowed in our communication fora
20:16 <kaniini_> 3) since it's in writing, anyone we delegate moderator privileges too will know as some kind of guideline what is acceptable or not
20:17 Emperor_Earth__ joined
20:19 <coredumb> ok makes sense
20:31 <Shiz> 1) still seems needlessly paranoid to me, but whatever
20:36 <TemptorSent> Hmm, do we have Ada packaged anywhere?
20:38 <jirutka> Ada? I’m not sure, maybe in Museum of programming languages? :)
20:39 <TemptorSent> Yeah, or anything that requires safety verification.
20:39 <jirutka> Ada programs are mathematically verificable for coretness?
20:40 <TemptorSent> Yup.
20:40 <jirutka> hmm, interesting
20:40 <jirutka> didn’t know that
20:40 <TemptorSent> Milspec/spacecraft computers use it.
20:41 <jirutka> isn’t there any newer lang that can be verificable and there’s tool for that?
20:42 <TemptorSent> Not that I'm aware off off hand with certified commercial compilers.
20:42 <kaniini_> yes, we do have Ada packaged.
20:43 <kaniini_> gcc-gnat will pull in all ada stuff
20:43 <TemptorSent> Thank you kaniini_!
20:43 <jirutka> Ada first appeared in 1980… I’ve confused it with some other lang, this is much younger than I expected
20:44 <jirutka> last stable release 2016
20:44 <jirutka> looks pretty alive
20:44 <TemptorSent> Yes, latest language rev 2012
20:44 <TemptorSent> jirutka are you thinking ALGOL?
20:45 <TemptorSent> Or PL/1?
20:45 <jirutka> yes, ALGOL
20:46 <TemptorSent> Ah, yeah - haven't seen ALGOL around much lately. PROLOG is still kicking though I think.
20:47 <jirutka> Ada is for embedded RT systems, hmm
20:48 <jirutka> Ada looks surprisingly innovative for its age
20:48 <jirutka> shame on me that I didn’t know about it
20:49 <TBB> also used in the defense industry if I'm not mistaken
20:54 <TemptorSent> Yes TBB - defense, aerospace, aviation, medical, nukes - anywhere you need real guarentees about behavior and failure modes.
20:56 <kaniini_> pls do not use alpine in a nuclear bomb ;/
20:56 <arch3y_> question does musl support libintl.h
20:56 <TemptorSent> kaniini_: I was referring to power plants, but the point stands -- Linux has no place in critical systems.
20:57 <Shiz> maybe we need to attach an itunes-like disclaimer to alpine
20:57 <Shiz> not to use it for nuclear weapons
20:57 <kaniini> something something imagine dragons - radioactive
20:57 <TBB> oh damn
20:57 <* TBB> cancels his project
20:58 <jirutka> arch3y_: it’s provided by gettext-dev…
20:58 <arch3y_> thanks
20:59 <TemptorSent> *lol* - But in all seriousness, any RT-Critical system should NOT be implemented on top of linux.
21:00 <kaniini> what about IoT dildos
21:00 <TemptorSent> Alpine is nice for servers or non-critical embedded use, but shouldn't even be considered for things such as driverless cars, human-interacting robotics, or anything that is inherently dangerous.
21:01 <TemptorSent> kaniini: Hmm, not sure on those ;)
21:02 <kaniini> it may alarm you to find out that the google self driving car runs on linux
21:02 <jirutka> TemptorSent: indeed, but there are still a lot of idiots who build something that really needs RT system on top of vanilla Linux :(
21:02 <TemptorSent> Yes, I do find all such systems distrubing since I know how they fail.
21:03 <kaniini> what about linux-rt
21:03 <TemptorSent> jirutka: Realistically, the RT components should be running on a dedicated RT kernel and hardware with proper watchdogs.
21:03 <jirutka> TemptorSent: and I wouldn’t be surprised at all if some cars have critical driving systems directly connected with entertainment system written in JavaScript… :(
21:04 <TemptorSent> linux-rt is not a true RT solution -- you can't control interrupts nearly fine-grained enough to make a safety-critical system.
21:04 <jirutka> kaniini: linux-rt is better than vanilla, but still quite bad for RT, at least based on what I heard from one engineer at CTU who teach RT systems
21:05 <TemptorSent> Yeah, the more I see of integrated automotive technology, the more I run screaming the other way.
21:05 <TemptorSent> linux-rt basically gives you the ability to set bounded latency -- but that's about all.
21:06 <TemptorSent> Nothing in the kernel is designed with RT operation in mind.
21:06 <jirutka> one company I’d rather not name really wanted to implement some part of entertaiment system to car in Dart!
21:06 <arch3y_> it seems that musl is helping ppl clean up their code and fix weird things
21:06 <TemptorSent> arch3y_: Making things actually portable tends to do that :)
21:06 <jirutka> arch3y_: yes, that was basically one of the main messages in ncopa’s talk on FOSDEM :)
21:06 <Shiz> car entertainment systems are not a problem lol
21:07 <Shiz> they have no hard-rt requirements
21:07 <Shiz> but yeah, linux for hard-rt is a no-no
21:07 <jirutka> Shiz: the problem is that these systems are often not properly isolated from critical systems!
21:07 <Shiz> jirutka: sure, but that's not what TemptorSent is talking about
21:07 <arch3y_> yeah its kind of nice I dont know much about C but it seems to be fixing alot of bad habits in code
21:07 <TemptorSent> Spamming a shared canbus is BAD.
21:07 <Shiz> hard-rt doesn't spread across communication buses :p
21:07 <Shiz> entertainment systems just need to be secure, not hard-rt
21:07 <Shiz> (and there alpine could help... if you wanted to go for linux)
21:08 <Shiz> (help, it is not a total solution of course)
21:08 <TemptorSent> Shiz: When the entertanment system is using the same canbus as the vehicle control system, bad RT behavior on the entertainment device CAN cause serious issues on the control side.
21:09 <kaniini_> Shiz: funny you should mention that, the radio in my car infact does seem to run both alpine *and* docker
21:09 <kaniini_> :|
21:09 <Shiz> hah
21:09 <TemptorSent> Nice kaniini_!
21:10 <kaniini_> it also boots off an SD card
21:10 <kaniini_> that is inside it
21:10 <kaniini_> instead of having proper flash
21:10 <kaniini_> good work General Motoros
21:10 <kaniini_> Motors*
21:10 <* kaniini_> thumbs up
21:10 <jirutka> kaniini_: Docker in car?! WHAT THE HELL?
21:11 <kaniini_> jirutka: indeed, it's in the legal notices
21:11 <jirutka> kaniini_: you must be kidding
21:11 <Shiz> soon: docker in your ship
21:11 <Shiz> ... wait
21:11 <kaniini_> jirutka: i guess each 'app' runs in its own docker container
21:11 <TemptorSent> Shiz: CAN-bus is explicitly designed to support hard RT usage, and often serves to replace RS-485 or SPI/I2C links.
21:11 <jirutka> kaniini_: OMFG, I don’t wanna live on this fucking insane planet anymore
21:11 <Shiz> TemptorSent: okay that's fair
21:11 <Shiz> jirutka: hey, at least it has isolation
21:11 <kaniini_> GM does not use CAN anymore
21:11 <kaniini_> it uses ethernet
21:11 <kaniini_> true story
21:11 <jirutka> Shiz: you mean “isolation”?
21:11 <Shiz> your entertainment system is 99% likely to use linux anyway
21:12 <Shiz> might as well put SOME effort into isolating stuff
21:12 <Shiz> jirutka: userns is better than nothing
21:12 <Shiz> ;p
21:12 <jirutka> this world is insane
21:13 <TemptorSent> kaniini_: Is it "ethernet" or "EtherNet" (two VERY different things)
21:14 <kaniini_> TemptorSent: ethernet
21:14 <TemptorSent> kaniini_: Any idea of what protocol stack?
21:14 <kaniini_> TemptorSent: IP
21:14 <TemptorSent> Hmm, that's odd.
21:15 <kaniini_> TemptorSent: yes, my GM death trap is running it's own IP network, and the OnStar (GM IoT platform) module serves as the router and switch
21:15 <TemptorSent> That doesn't qualify for hard-rt.
21:15 <kaniini_> TemptorSent: it is not twisted-pair cabling, just the ethernet signalling itself, to be clear
21:15 <kaniini_> TemptorSent: send all blame to broadcom
21:15 <TemptorSent> Ahh, that module must provide the interfacing to the vehicle control systems.
21:16 <TemptorSent> Yeah, ethernet with no PHY is common in such applicaitons.
21:17 <Shiz> entirely unrelatedly
21:18 <Shiz> thing i want to work on post-3.6: seeing how viable using clang as a system compiler is
21:18 <Shiz> including hardening
21:18 <kaniini_> yes, absolutely
21:18 <TemptorSent> That would be nice Shiz.
21:25 <TemptorSent> Holy crap - gnat is pulling in 62 new packages?!?
21:27 <kaniini_> ada is serious business
21:28 <TemptorSent> Hmm, broke on first try, then started with 'apk update --available', which seems to be pulling in a bunch of unrelated stuff.
21:28 <TemptorSent> tiff, freetype, etc.
21:32 <kaniini_> yes, --available means upgrade the distribution :P
21:41 <awilfox> isn't it basically the equivalent to dist-upgade?
21:42 <TemptorSent> Bloody hell, kernel is still eating itself on upgrade :/
21:42 <Shiz> awilfox: sorta
21:43 <kaniini_> what is in your /etc/apk/world
21:43 <TemptorSent> depmod is trying to run against `uname -r` rather than the newly installed kernel.
21:43 <kaniini_> oic
21:43 <Shiz> on a technical level, it changes apk behavior to prefer upgrading versioned dependencies rather than holding them at the same version
21:43 <Shiz> e.g. if clang depends on llvm=4.0.0, it would normally hold it
21:43 <Shiz> err
21:43 <Shiz> >=4.0.0
21:43 <Shiz> even if a newer verison is available
21:43 <Shiz> if i understand it correctly
21:43 <TemptorSent> That appears to be correct.
21:44 <awilfox> ah.
21:44 <TemptorSent> kaniini - see 'kmod-23-r1.trigger' for the fubared depmod it looks like.
21:45 <TemptorSent> I have modules now, but they're not being properly handled by the script.
21:46 <jirutka> omfg, in #opensmtpd are really idiots
21:46 <jirutka> I don’t have any patience for this
21:46 <jirutka> this level of arrogant stupidity
21:47 <kaniini_> you had higher expectations for the openbsd crowd ?
21:47 <TemptorSent> So, what calls kmod.trigger?
21:47 <jirutka> kaniini_: yes
21:47 <kaniini_> they are "we are always right" blowhards, any email thread involving them would tell you this ;)
21:47 <jirutka> kaniini_: aha :(
21:48 <jirutka> I should consider switching back to Postfix
21:48 <Shiz> i uhm
21:48 <Shiz> kind of am on their side on this one
21:48 <Shiz> no offense but you were kind of acting like a dick
21:48 <jirutka> Shiz: have you read the recent conversation? full of it?
21:48 <Shiz> i've read the entirety, yes
21:49 <jirutka> Shiz: sorry, but I’ve reported them problem in the documentation, explained million times why it’s a problem and posted patch that actually fixes the primary problem (duplicated information)
21:49 <jirutka> and they asked me to write a proper FAQ page for them… like it has anything in common
21:49 <jirutka> this is totally different issue
21:50 <jirutka> and then he asked to just updated the outdated info, so he apparently still don’t understand the problem of duplicated source of truth
21:50 <jirutka> sorry, but this is idiocy
21:50 <Shiz> or, from their side: you come in ranting angrily about a fault in a page and then submit a diff to remove all of it
21:50 <Shiz> i can understand why they'd be wary
21:50 <Shiz> you were kinda aggressive during your whole interaction
21:50 <jirutka> Shiz: yes, b/c removing this page is the only proper solution of this exact problem
21:50 <jirutka> Shiz: writing proper replacement is different issue
21:51 <Shiz> i guess they don't want to throw out the baby with the bathwater
21:51 <jirutka> Shiz: and yes, I agree that my introduction was bad, but I think that i’ve explained why I acted like that
21:51 <Shiz> jirutka: right, but there's the thing
21:51 <jirutka> anywyay, I’ve reported them problem, they don’t give a fuck
21:51 <Shiz> you explained but never apologized (that i saw of)
21:51 <Shiz> and you continued being pretty aggressive :p
21:51 <Shiz> i'm not saying you're not right on a technical level btw
21:51 <Shiz> i'm just saying i can see why they'd be kinda wary
21:52 <jirutka> does it even matter? it doesn’t look like he really understand what the fuck is the real problem here
21:52 <jirutka> and yes, his reactions made me very upset, so at the end I was very aggressive
21:52 <jirutka> b/c I can’t understand how can be anyone so stupid/arrogant/whatever
21:53 <jirutka> it’s so simple issue, not anything you need doctorate from users psychology etc.
21:54 <jirutka> but what the heck I’ve expected from people who has web like this https://opensmtpd.org/ and soure code in CVS…
21:56 <scadu> jirutka: https://www.youtube.com/watch?v=OdIJ2x3nxzQ :)
21:56 <jirutka> and I even wasted like a half hour trying to find the best approach how to semantically encode into HTML page that it’s replaced by some other page, without need to add HTTP 301 to web server; so I eventually just added meta for robots to not index that page
21:56 <scadu> jirutka: chill, there is no sense to get so angry
21:58 <jirutka> and now I’m trying to understand this stupidity of crappy libtool http://stackoverflow.com/a/16070483/2217862
21:59 <jirutka> "you MUST specify SOME sort of an argument (LINK-COMMAND) referring to a tool; BUT that LINK-COMMAND argument doesn't even need to exist as a real program"
21:59 <scadu> welp, I received a call 5 minutes before ending my shift that something does not work
21:59 <scadu> fun fun
21:59 <Shiz> :(
21:59 <scadu> jirutka: open the yt url linked :P
22:01 <TemptorSent> jirutka: Is it just using it as a placeholder name?
22:01 <jirutka> TemptorSent: probably
22:02 <awilfox> dunno the convo here but it sounds like you are being "we are always right" back at them :p
22:02 <TemptorSent> "build-my-whatever"
22:02 <awilfox> and when two conflicting opinions both come from "we are always right" people...
22:02 <awilfox> lol
22:02 <jirutka> ar: `u' modifier ignored since `D' is the default (see `U') o.O
22:02 <Shiz> jirutka: i've seen that one around
22:02 <Shiz> you can ignore it afaik
22:04 <TemptorSent> Hmm, yeah 'u' only works if timestamps are non-zero.
22:05 <jirutka> yeah, it looks that it produces the same result as when i run ar manually, so it should be hopefully okay
22:18 <jirutka> martanne: FYI, there’s now lua-lpeg-dev with lpeg.a for Lua 5.[123] and libtermkey-dev with added libtermkey.a in edge
22:20 <Shiz> hmm
22:20 <Shiz> looks like a grsecurity stting is blocking people from running glx-accelerated stuff as non-root
22:21 <TBB> what setting causes that?
22:21 <Shiz> libdrm can't read the relevant entries in /sys and thus fails to identify the card
22:22 <jirutka> Shiz: this is problem even for LXC when you want to use userns https://github.com/lxc/lxc/issues/296#issuecomment-234708658
22:23 <jirutka> Shiz: so I’d suggest to disable it in our grsec kernel
22:23 <Shiz> i wish it could be enabled with a sysfs toggle
22:23 <Shiz> :P
22:23 <TBB> that's what I've been seeing suggest as a solution: disable it and if you require restrictions then write a policy
22:23 <TBB> suggested*
22:27 <TBB> interestingly enough you just solved some of my scheduling problems for the weekend jirutka; I was supposed to try some of those namespace tools like firejail with a grsec enabled system; looks I won't have to if it's problematic :)
22:28 <jirutka> TBB: this should not discourage you, I run LXC on grsec kernel without any problem, just some grsec features must be disabled, like this one
22:29 <jirutka> TBB: my personal notes about grsec for installing LXC on Gentoo, few years old, so not sure if still relevant https://dpaste.de/iNk0
22:30 <arch3y_> is there a way with apk to tell which pkg provides a fil
22:30 <arch3y_> or is it best to just read the file listing on the pkgs sit
22:32 <jirutka> arch3y_: currently it’s not
22:32 <jirutka> arch3y_: it’s planned feature for next gen of apk
22:33 <arch3y_> jirutka: ok thanks for the info
22:36 <TemptorSent> Yeah, we need package manifests to support that ability easily.
22:36 <arch3y_> something like the files tarball in arch
22:36 <k63ZXXguczqE> TBB firejail + grsec + firefox works nicely here
22:37 <k63ZXXguczqE> even with a dedicated firefox user
22:37 <arch3y_> I know its a bad word but itd be nice to pull down those manifests and run a command to search
22:37 <TBB> oh cool!
22:37 <TemptorSent> arch3y_: Ideally, something more complete and useful.
22:37 <arch3y_> rightfully so
22:37 <arch3y_> you guys are the experts I just use the things
22:38 <TemptorSent> arch3y_: I'm working on a suite that handles manifests, indexes, and dep-chains.
22:38 <TBB> I find it a fascinating idea to do some ostree + firejail + appimage magic for fun
22:38 <k63ZXXguczqE> but i don't run any webgl stuff
22:38 <TBB> and this is encouraging :)
22:38 <arch3y_> nice I can see there are some interesting advantages built into abuild Im enjoying pkging software
22:38 <arch3y_> for apline
22:39 <TemptorSent> arch3y_: Combined, that allows determining the deps directly for any particular individual file, both by file and by package.
22:39 <martanne> jirutka: thanks, I will check it out later.
22:40 <TemptorSent> It could even allow us to do something like 'alien' packaging without a lot of work.
22:41 blueness joined
22:48 <TemptorSent> kaniini - When you have a moment, I'd like to discuss a couple of general purpose tools for alpine, namely a manifest/index tool, a dep-solver, and a pax archiver.
22:51 <TemptorSent> Those tools could be the guts of apk 3, as well as being useful independently. A minimal graph-structured database would round out the features.
22:55 <TemptorSent> I don't want to start hacking on any of that in C (or other language?) until some significant discussions have taken place, but I'd like to start working that direction.
22:58 <martanne> jirutka: could you also add a static version of unibilium? The termkey.pc file should probably reference it. Thanks again, I'm off to bed for now.
23:01 <TemptorSent> Has anyone figured out how to package cmucl?
23:05 <TemptorSent> Bloody bootstrap chicken and egg problem :/
23:08 <Shiz> kaniini: ncopa: https://github.com/Shizmob/grsecurity-research
23:08 <Shiz> publicized my repo about splitting up grsec in order to understand it more properly
23:08 <Shiz> might be relevant to our 3.6 maintenance plans
23:10 <TemptorSent> 7.13 MB in UNSPLIT? Ouch!
23:11 <Shiz> down from... more than that
23:11 <TemptorSent> Yeah, what a mess!
23:13 <TemptorSent> A lot of function prototype changes too, which means the propagate through the entire codebase.
23:14 <TemptorSent> UDREF isn't exactly small.
23:14 <Shiz> uderef also isn't nearly done being split up
23:15 <Shiz> i haven't split out the x86 code yet for instance
23:15 <Shiz> which is by far the biggest chunk
23:15 <Shiz> (and the most invasive)
23:16 <TemptorSent> Yeah, that looks like much of the changeset. A lot of auditing needed, some of the code looks potentially fragile and probably needs to ifdefed.
23:16 <TemptorSent> Oh, that asm trick is fugly tool
23:17 <Shiz> ?
23:18 <TemptorSent> It appears to be relying on the integer length (rather than the previous long or size_t) for partitioning the memory space.
23:18 <Shiz> where?
23:19 <jirutka> does anyone know how (and if) should be static library (.a) properly recoded in pkgconfig (.pc) file?
23:22 <TemptorSent> Shiz - trying to track down what's going on, it may be the semantics changed as well.
23:25 <TemptorSent> Ahh, okay - it looks like it's related to contstifying, and the pointer changed to a struct, so the index makes sense I guess.
23:26 <TemptorSent> explicit use of u64 in place of several of the size_t and ptr types as well.
23:28 <TemptorSent> But here's one I don't know if I trust: drivers/gpu/drm/radeon/mkregtable.c @@ -624,14, +624,14 @@
23:29 <TemptorSent> -size_t end; / +long end;
23:32 <TemptorSent> jirutka - kaniini would be the one to ask.
23:33 <kaniini> jirutka: direct path to the .a, and only put it in libs.private
23:33 <kaniini> ideally
23:33 <kaniini> in reality you probabyl dont want to do that
23:33 <jirutka> kaniini: relative path, e.g. libs.private: libfoo.a ?
23:33 <kaniini> no
23:33 <kaniini> you want
23:34 <kaniini> Libs.private: -L/path/to/libfoo -lfoo
23:34 <kaniini> well
23:34 <kaniini> it depends
23:34 <kaniini> what exactly is the .a
23:34 farosas joined
23:34 <kaniini> can it be used with .so files?
23:34 <kaniini> etc
23:34 <jirutka> okay, I’ll wait for martanne if he actually really need it
23:39 blueness joined
23:40 <kaniini> i've spent the past 2 hours trying to make virt-install work
23:40 <kaniini> then i remembered, red hat makes systemd
23:40 <kaniini> and i realized quickly that this was a fool's errand
23:40 <TemptorSent> *lol*
23:42 <jirutka> heh "The intention is not to be bug for bug compatible with vi(m)" :)
23:42 <jirutka> but-to-bug compatibility, I must remember this :)
23:43 <kaniini> it does weird shit with lvm
23:43 <awilfox> virt-install works fine on not-systemd
23:43 <awilfox> I don't use it any more though, because I switched from xm to xl
23:43 <awilfox> and virt-install does some weird stuff with xl
23:43 <kaniini> awilfox: it's because of lvm
23:44 <awilfox> oh.
23:44 <kaniini> it is trying to do things with lvm that i do not want it to do
23:44 <kaniini> and then failing
23:44 <kaniini> some weird bullshit involving snapshots
23:44 <kaniini> and then it tries to swap out for a snapshot
23:44 <kaniini> or something
23:45 <kaniini> i don't think virt-install actually works with libvirt-managed LVM pools
23:45 <kaniini> all i know is.
23:45 <kaniini> when i did it by hand, it works fine
23:45 <kaniini> :D
23:46 <jirutka> do you really need virt-install or libvirt? isn’t https://github.com/jirutka/qemu-openrc sufficient? ;)
23:46 <kaniini> and libvirt is kind of a piece of junk anyway
23:46 <kaniini> jirutka: actually i do need some sort of management layer because we have literally 1000s of VMs
23:46 <jirutka> kaniini: aha, understand
23:46 <kaniini> i will just make something myself
23:46 <kaniini> this libvirt is too bullshit
23:46 <jirutka> agree
23:47 <jirutka> libvirtd is horrible piece of shit
23:47 <kaniini> some sort of MQTT thing i guess i will make
23:47 <kaniini> and then an agent that subscribes to MQTT topics
23:47 <kaniini> and acts on them
23:48 <awilfox> making a better libvirt+friends was on my todo list but then everyone started dissing xen (this was around 4.0 - 4.1 era) and when I would look up stuff it would all say "no, use kvm instead" so I gave up \o/
23:48 <algitbot> \o/
23:48 <jirutka> kaniini: please get me informed about progress, I’d like to try that tool! :)
23:49 <skarnet> I've had a distant eye on those things too, and never did anything for the same reason as awilfox
23:49 <awilfox> yeah, something nicer than `xl ...` would be fantastic
23:49 <awilfox> I could likely source a c2q or such for testing it
23:51 <jirutka> vis looks really interesting, I’ll try to use it for some time
23:51 <awilfox> also, fwiw, I have not even touched qemu in some years, except for some limited FreeBSD testing; I use xen pv for everything
23:52 <awilfox> much faster and lighter :)
23:53 <Shiz> @kaniini │ i've spent the past 2 hours trying to make virt-install work
23:53 <Shiz> this is why i use a custom qemu wrapper thing
23:53 <Shiz> :P
23:53 <Shiz> awilfox: skarnet: libvirt doesn't have to use xen
23:53 <kaniini> awilfox: kvm is necessary in this setup because it is for the windows farm
23:54 <Shiz> it can use qemu-kvm just fine
23:54 <kaniini> awilfox: but hey, at least we wont have to keep disinfecting our vmware machines
23:54 <jirutka> yeah, I used to use libvirtd with QEMU/KVM… actually I even didn’t know that it works with Xen too… but as I said, I really can’t recommend libvirtd