<    June 2018     >
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 _2_0 21 22 23  
24 25 26 27 28 29 30
00:16 tuxether[m] joined
00:16 bernhardgruen[m] joined
00:16 Aerdan[m] joined
00:16 ata2001[m] joined
00:16 runelabs[m] joined
00:16 andypost[m] joined
00:16 MartijnBraam[m] joined
00:16 ncopa[m] joined
00:16 PureTryOut[m] joined
00:16 wictory[m] joined
00:16 ollieparanoid[m] joined
00:16 hl joined
00:16 clandmeter1 joined
00:16 drebrez[m] joined
00:16 Michitux joined
00:16 fcolista[m] joined
00:16 Ceruleis[m] joined
00:16 carlosdavidepto[ joined
00:16 RyabyyDenis[m] joined
01:51 wener joined
02:03 wener joined
02:39 mickibm joined
04:02 mepholic joined
05:57 <ncopa> mksully221: its #8966
05:57 <algitbot> Bug #8966: User Generated Kernel apk Will Not Boot - Alpine Linux - Alpine Linux Development: https://bugs.alpinelinux.org/issues/8966
05:58 <mps> algitbot started to work again, nice
06:01 <mps> I cannot upgrade exiv2 package in edge. 'apk add -u exiv2' shows just '1 error; 1738 MiB in 614 packages'
06:03 <mps> and 'apk version | grep exiv2' shows 'exiv2-0.25-r0 < 0.26-r0'
06:21 rdutra joined
06:34 NIN101 joined
06:40 <ncopa> mps: try: apk fix
06:49 clemens31 joined
06:56 <mps> ncopa: tried but didn't help
06:59 <clandmeter> ncopa, moring.
06:59 <clandmeter> did you see my question?
07:11 <ncopa> how to select latest netboot
07:11 <ncopa> i saw it
07:11 <ncopa> and i am thinking of it
07:11 <ncopa> short answer: parse latest-release.yaml
07:12 <ncopa> I am thinking that we could also create a symlink named 'netboot-latest' or simply 'netboot' which points to latest
07:13 <ncopa> for all other images we dont create such symlink, but you can parse the yaml
07:14 clemens31 joined
07:14 <clandmeter> ncopa, parsing seems strange
07:14 <clandmeter> can we not have a single netboot folder with latest release?
07:15 <ncopa> everything is possible
07:15 <clandmeter> :)
07:15 <ncopa> can we have a single url with the latest iso?
07:15 <ncopa> yes
07:15 <ncopa> but i see the point
07:16 <clandmeter> maybe we can have a metadata file in the folder saying which release it is?
07:16 <clandmeter> or a symlink
07:16 <ncopa> i am slightly hesitant though because i dont want to recommend use of the netboot-3.8.0_rc2/ files
07:17 <ncopa> we don't sign those files
07:20 <clandmeter> well i can sign them via netboot.a.o just not the modloop.
07:22 <ncopa> if you need to (re)sign them via netboot, then i assume that you need to download them to netboot.a.o
07:22 <clandmeter> yes i would
07:23 <ncopa> then you can download the signed tarball, (and verify gpg signature) and put them in your own netboot/ directory
07:23 <clandmeter> but it would be nice if we could split bootscript/signatures and images.
07:23 <ncopa> i guess we could sign the files using apk key
07:25 <clandmeter> why dont we sign the netboot images?
07:25 <ncopa> we will sign the tarballs
07:25 <clandmeter> i know
07:25 <clandmeter> but you cant boot from it.
07:26 <ncopa> the problem is how the mkimage script is designed
07:26 <ncopa> it is designed to produce a single outfile
07:26 <ncopa> not 3
07:26 <ncopa> so it does not create checksums
07:26 <ncopa> etc
07:26 <ncopa> does not put the url in the yaml
07:26 <clandmeter> we cannot fix that?
07:26 <ncopa> it requires a relatively big refactoring
07:27 <ncopa> outfile needs to be an array
07:27 <ncopa> there are many weird questions
07:27 <ncopa> what if you have 3 different file extensions?
07:27 <ncopa> it is a can of worms
07:28 <ncopa> then if we put the raw vmlinuz and initramfs on all mirrors
07:29 <ncopa> we make it very easy and convenient for people to do stupid stuff like fetch kernel with http and just boot it
07:29 <clandmeter> all major distros supply netboot images.
07:29 <clandmeter> if we do it this way i suggest remove it completely
07:29 <ncopa> i dont oppose images
07:30 <clandmeter> you can ship a netboot.tar.gz but i would suggest to rename it.
07:30 <clandmeter> it has nothing to do with netboot.
07:30 <ncopa> it has a kernel and modloop and initramfs with ehternet dirvers
07:31 <ncopa> all you need to set up your own tftp
07:31 <clandmeter> ok lets tell that our users.
07:31 <ncopa> im just expressing my thoughts
07:31 <clandmeter> you want to netboot like other distros?
07:31 <ncopa> im not saying i am right :)
07:32 <clandmeter> im sorry, but you will have to setup it up yourself.
07:32 <clandmeter> :)
07:32 <ncopa> how do you do netboot on otherdistros?
07:32 <clandmeter> http://ftp.nl.debian.org/debian/dists/stretch/main/installer-amd64/current/images/netboot/debian-installer/amd64/
07:33 <ncopa> so you just download the files from http and thats it?
07:33 <ncopa> no checksum verification? no signature check? not even https?
07:34 <ncopa> what is this netboot.tar.gz? http://ftp.nl.debian.org/debian/dists/stretch/main/installer-amd64/current/images/netboot/
07:34 <ncopa> there is an iso
07:35 <ncopa> https://www.debian.org/distrib/netinst there is a "network boot" paragraph to the right
07:36 <ncopa> https://www.debian.org/releases/stable/amd64/ch04s05.html.en
07:40 <clandmeter> if we use our own ipxe bootloader we can verify the images except the modloop.
07:46 <ncopa> and we can sign the modloop similar to what we do with apk.static
07:46 <ncopa> so we can verify it with the apk keys
07:48 <clandmeter> yes that would be neat
07:51 <ncopa> lets say we create a netboot-latest symlink to the netboot directory
07:51 <ncopa> how are this supposed to be used?
07:51 <ncopa> i dont have much experience with netboot, that is why i am asking
07:57 <clandmeter> ncopa, this is the main ipxe boot script https://github.com/alpinelinux/alpine-netboot/blob/master/boot.ipxe
07:57 <clandmeter> it loads the kernel and initramfs
07:57 <clandmeter> and will verify with the supplied signatures
08:16 <Tecuane> @ncopa: fast-tracking here
08:16 <Tecuane> if you want that case statement structured multi-line, i can do it
08:16 <Tecuane> i don't mind either way, it was mostly to avoid a bashism and to discourage 'extension'
08:23 fekepp joined
09:23 <ncopa> Tecuane: i think i can fix it. I am testing it here now
09:29 [[sroracle]] joined
09:38 terra joined
09:40 <terra> Anyone noticed that firefox-esr decorations problematic on x86 ?
09:40 <ncopa> terra: yes
09:40 <ncopa> its an old issue
09:40 <ncopa> and nontrivial to ix
09:40 <ncopa> fix*
09:40 <terra> is there a workaraound?
09:41 <terra> Same issue with Pale Moon
09:42 <ncopa> #4248
09:42 <algitbot> Bug #4248: Firefox menus and dialogs missing text - Alpine Linux - Alpine Linux Development: https://bugs.alpinelinux.org/issues/4248
09:43 <ncopa> oh i never posted the upstream bug report
09:43 <ncopa> https://bugzilla.mozilla.org/show_bug.cgi?format=default&id=1284293
09:46 <terra> ncopa: thanks. I'm reading.
09:50 <ncopa> I re-read it myself
09:51 <ncopa> and i think I may have a suggestion to ao workaround
09:51 <ncopa> i mean
09:51 <ncopa> i may have something that makes it better
09:51 <terra> It seems related with degraded floating point precision on 32bit mode
09:51 <ncopa> yes
09:51 <ncopa> i think we should just drop that
09:51 <terra> Can it be fixed with some extra gcc optimizations?
09:52 JayBau joined
09:52 <ncopa> i think it can be fixed to not modify floating point precision
09:53 <ncopa> some JS calculations may not be as expected, but at least i should show the widgets properly
09:53 <ncopa> iirc there was some testcases for what this is supposed to solve
09:53 <terra> The bad thing is even web content text can't be rendered on Pale Moon. But this is out od scope of Alpine.
09:53 <terra> *of
09:54 <ncopa> yes
09:59 <ncopa> Tecuane: your patch breaks script when there are 2 disks in raid1
10:24 <ncopa> terra: unfortunately i dont have time to work on it now
10:24 <ncopa> i also need work on chromium
10:24 <ncopa> but first prio is the v3.8 release
10:24 <terra> ncopa: You already have been helpful
10:25 <terra> thank you
10:26 <terra> Some Gentoo guys who trying to port PaleMoon to musl noticed this this issue and seek help from me.
10:26 <ncopa> aha
10:26 <terra> At least I learned what is all about
10:26 <ncopa> i think just removing that code that change the precision may help
10:26 fekepp1 joined
10:27 <ncopa> but i havent investigated what other ocnsequences it leads to
10:27 <terra> on musl or firefox ?
10:28 <ncopa> firefox
10:28 <ncopa> prevent firefox to mess with the fpu precision
10:29 <terra> https://github.com/mozilla/gecko-dev/blob/esr45/js/src/jsnum.cpp#L1045
10:29 <terra> ?
10:29 <ncopa> yes
10:29 <ncopa> https://github.com/mozilla/gecko-dev/blob/esr45/js/src/jsnum.cpp#L1047
10:29 <terra> ok thanks.
10:29 <ncopa> change __GNUC__ to __GLIBC__
10:30 <ncopa> but the code looks different in recent firefox
10:30 <ncopa> i think the function moved or got renamed
10:30 <terra> ok
10:30 <ncopa> so you may need to grep for "fstcw"
10:30 <terra> I got it
10:34 <ncopa> i think we should drop support for "data" mode disk install
10:36 <_ikke_> Not that I'm using it, but why?
10:36 <ncopa> setup-disk script is messy
10:36 <ncopa> to simplify
10:37 <ncopa> and the data mode setup is tricky to get right wrt upgrades
10:37 <ncopa> we use data mode on our bld1/bld2
10:37 <ncopa> and it is seldom that an upgrade "just works"
10:39 <_ikke_> right ;-)
10:42 fekepp joined
10:49 Fusl joined
11:04 wener_ joined
11:50 <terra> ncopa: it seems just discarding that part in jsnum.cpp on musl fixed the problem. At least on Pale Moon.
11:51 <terra> Thank you
11:51 <terra> I will test it on firefox too.
12:15 wener joined
12:31 fabled joined
12:42 <nmeum> https://git.alpinelinux.org/cgit/aports/commit/?id=7a7493c33286ca7e43c8171cd6fad02bd13574c8 didn't we decide that we wanted to upgrade to 2.9.1 instead of simply including the patch for the CVE yesterday?
12:43 rajivr joined
12:43 faffolter joined
12:43 <ncopa> terra: would be great if you could send a patch for alpine
12:44 <ncopa> nmeum: that was what I wanted
12:44 <ncopa> its not too late to upgrade freetype
12:47 <nmeum> sure, I just dislike the fact that we discuss something on irc and that the opposite is actually implemented
12:48 <nmeum> but well…I don't really expect everyone to read the entire irc backlog…
12:49 <nmeum> anyway, I am working on an upgrade
12:56 <nmeum> ncopa: turns out: there is a configure option to enable freetype-config again: http://tpaste.us/X6ee ok?
12:56 <ncopa> ah great!
12:56 <ncopa> lets enable it
12:57 <nmeum> ok, I will just push the patch I linked above then
13:00 <nmeum> pushed
13:13 wener joined
13:13 <JayBau> _ikke_ https://pastebin.com/dZYedLZs not really sure how to check /var/logs after mounting the disk, this is what I see after mounting the disk
13:31 wener joined
13:33 wener_ joined
13:37 JayBau joined
13:52 mmlb joined
14:26 fekepp joined
14:30 <ncopa> heh
14:30 <ncopa> ipxe is pretty cool
14:31 <ncopa> qemu-system-x86_64 --enable-kvm -m 1024 -cdrom http://boot.alpinelinux.org/alpine-ipxe/x86_64/ipxe.iso
14:32 <tmh1999> :D
14:32 <tmh1999> what :O qemu supports downloading iso from remote :O
14:33 <ncopa> yeah, if its built with curl support
14:33 <tmh1999> I've lived my whole life wrong ...
14:33 <ncopa> this is first time i am actually testing it
14:33 <tmh1999> +1
14:34 <ncopa> but really
14:34 <ncopa> this is awesome
14:34 <tmh1999> clandmeter: ^ that's for you
14:34 <ncopa> clandmeter: you have don great job with this!
14:34 <_ikke_> \o/
14:34 <algitbot> \o/
14:35 <clandmeter> ncopa, you can also boot ipxe kernel directly
14:37 <terra> ncopa: https://github.com/alpinelinux/aports/pull/4495
14:37 <ncopa> qemu: could not load kernel 'http://boot.alpinelinux.org/alpine-ipxe/x86_64/ipxe.lkrn': No such file or directory
14:38 <ncopa> what is awesome with the iso is that you only need qemu and an url to run alpine
14:39 <tmh1999> I'm trying to make the iso for s390x too. it looks like kvm can use iso.
14:39 wener joined
14:49 <ncopa> clandmeter: re netboot
14:50 <ncopa> i think i will create a symlink to latest
14:50 <clandmeter> ok
14:51 <ncopa> i think the fastly cache is available via https too
14:51 <ncopa> just with other name
14:53 <clandmeter> yes it is
14:54 <clandmeter> we use it for cname
15:09 mksully22 joined
15:21 <clandmeter> ncopa, are you planning to setup periodical edge releases?
15:22 <clandmeter> would be nice to have it for netboot
15:26 <duncan^> Will there be more regular releases of 3.8? Especially kernel releases, for those of us using diskless boot, where it's nontrivial to create a new image with updated kernel
15:31 <ncopa> duncan^: yes. we should make releases more often after 3.8..0
15:32 <ncopa> clandmeter: yes, I was thinking that we should do monthly edge releases or similar
15:32 <ncopa> duncan^: there is a tool also: update-kernel
15:33 <ncopa> ok i think its time for rc3
15:33 <ncopa> oh
15:33 <ncopa> clandmeter: what is the status of rpi kernel?
15:34 <omniuwo> it's like an rc a day
15:39 wener_ joined
15:48 mickibm joined
15:58 _JayBau_ joined
15:59 <clandmeter> ncopa, i didn't have time to check boot properly
16:00 <ncopa> i think i just grab what you had, upgrade it to 4.14.49 and push it
16:00 <ncopa> then ask community to test
16:00 clemens31 joined
16:00 <clandmeter> We could try to update
16:00 <clandmeter> Ask ppl to test rc
16:01 <clandmeter> Need also new fw
16:01 <ncopa> how do i update the firmware?
16:03 <clandmeter> There is a commit is
16:03 <clandmeter> Id
16:03 <clandmeter> In release scripts
16:04 <ncopa> rpi release scripts or alpine release scripts?
16:04 <clandmeter> Alpine
16:04 <ncopa> aports-build script?
16:04 <ncopa> on
16:04 <ncopa> oh
16:05 <ncopa> how do i find the correct commit hash?
16:06 <ncopa> i just grab the latest in master branch?
16:07 mickibm joined
16:10 <clandmeter> They don't mention tags in commits?
16:31 <clandmeter> They do
16:35 <ncopa> jirutka: looks like perl-test-warn is regularily added to testing :D
16:48 wener joined
16:49 tmh1999 joined
17:29 wener joined
17:31 rdutra joined
17:32 <mickibm> @ncopa: there should be an updated comment with the mkinitfs patch to use first network interface that is up. Want me to submit another PR to change the comment or could someone with master access just add it?
17:32 <mickibm> https://github.com/alpinelinux/mkinitfs/blob/master/initramfs-init.in#L145
17:32 <mickibm> sorry about that
17:39 <mickibm> as far as ppc64le PXE testing is going - we used: http://dl-cdn.alpinelinux.org/alpine/v3.8/releases/ppc64le/netboot-3.8.0_rc2/ and it tried booting with eth3 interface using my patch however eth2 interface is the one we want to use and according to sysfs it is not up <sigh>. I think it would be beneficial to specify the interface we want when dhcp
17:39 <mickibm> is enabled, such as ip=dhcp:ethX in kernel cmdline. any thoughts? I can submit a PR
17:43 czart joined
17:45 <mickibm> ...trying to get exact operstate right now
17:46 wener joined
17:50 <ncopa> mickibm: i updated the comment. thanks
17:50 <ncopa> i pushed rc3
17:50 <mickibm> thank you. cannot get operstate - stuck in dhcp loop. must be a weird race condition?
17:51 <ncopa> hum
17:52 <ncopa> can you add boot option debug_init
17:52 <mickibm> sure
17:52 <ncopa> should show the execution of the init script
17:52 <ncopa> maybe alos try use the rc3
17:52 <ncopa> which is out now
17:53 <mickibm> ok thanks
17:53 Topic for
17:53 <_ikke_> What did you change?
17:53 <_ikke_> it's still RC2
17:53 <_ikke_> (the topic)
17:54 Topic for
17:54 <ncopa> sorry
17:54 <_ikke_> np
17:54 <ncopa> thanks
17:54 <mickibm> no modloop for rc3 in ppc64le?
17:56 <ncopa> http://dl-master.alpinelinux.org/alpine/v3.8/releases/ppc64le/netboot-3.8.0_rc3/modloop-vanilla
17:57 <mickibm> oh thanks, i was looking at dl-cdn
17:58 <_ikke_> probably still needs to sync
18:00 <mickibm> thanks guys. will update shortly
18:01 wener joined
18:42 wener joined
18:45 wener joined
19:02 <mickibm> @ncopa im using a newer Power machine, but just want to confirm, part of the kernel boot parameters I add: debug_init after my ip=dhcp, modloops, etc...
19:03 <mickibm> because im getting some CPU lockups
19:07 <mickibm> gotta go, be online soon
19:22 tmh1999 joined
19:36 qwertty joined
19:37 JayBau joined
19:46 wener joined
19:50 Fusl joined
19:54 <mksully22> on a power8 machine installing rc3 as a qemu guest the install intermittantly fails with the messages:
19:54 <mksully22> Mounting boot media failed.
19:54 <mksully22> initramfs emergency recovery shell launched. Type 'exit' to continue boot
19:54 <mksully22> On successful attempts booting with the debug_init parameter set the "nlplug-findfs -p /sbin/mdev -d -b /tmp/repositories -a /tmp/apkovls" the output includes the scsi devices:
19:54 <mksully22> nlplug-findfs: uevent: action='add' subsystem='scsi_disk' devname='(null)' devpath='/devices/vio/71000002/host0/target0:0:0/0:0:0:0/scsi_disk/0:0:0:0'
19:54 <mksully22> nlplug-findfs: uevent: action='add' subsystem='srp_host' devname='(null)' devpath='/devices/vio/71000002/host0/srp_host/host0'
19:54 <mksully22> nlplug-findfs: uevent: action='add' subsystem='scsi_generic' devname='sg0' devpath='/devices/vio/71000002/host0/target0:0:0/0:0:0:0/scsi_generic/sg0'
19:54 <mksully22> On a failed boot this output isn't present...maybe a race condition in the device discovery?
19:59 terra joined
20:06 mickibm joined
20:16 fekepp joined
20:23 <terra> ncopa: I submitted the patch that fixing window decoration issue on x86 for firefox-esr.
20:23 <terra> https://github.com/alpinelinux/aports/pull/4495
20:39 JayBau joined
20:42 wener joined
20:52 wener joined
21:20 mickibm joined
21:23 wener joined
21:43 mksully22 joined
21:43 wener joined
21:47 mickibm joined
21:57 mps joined
21:59 <Xe> _ikke_: do you by chance know why the tcl packages for alpine ship the dynamically linked .so library for tcl but not the statically linked .a library for it?
22:00 <_ikke_> Xe: not sure why it's done, but I recall that they are removed by default
22:00 <zNVxxliww5gP> have you looked in the -dev pkg for the .a file?
22:00 <Xe> zNVxxliww5gP: yes
22:00 <zNVxxliww5gP> ok. just asking
22:00 <_ikke_> there are a lot of .a files in packages though
22:01 <Xe> _ikke_: i'd be curious to find out. it's worth noting that the alpine packages ship the tcl stubs .a file
22:02 <_ikke_> You'd have to ask one of the core developers probably
22:02 <Xe> alternatively some subpackage to install the static library would be nice
22:02 <Xe> kaniini: how come the libtcl8.6.a file isn't shipped in Alpine but its correlating .so file is?
22:03 <kaniini> why not ask whoever maintains it
22:03 <_ikke_> It's not that they are explicitly removed in the package
22:06 <Xe> clandmeter: how come the libtcl8.6.a file isn't shopped in the tcl-dev package, but the tcl stub library .a file is?
22:06 <Xe> shipped*
22:07 Bureaucat joined
22:07 <_ikke_> sorry for my ignorance, but what's a stub .a file?
22:07 <Xe> my usecase is to statically link a tool that depends on the system tcl
22:07 nots joined
22:08 <_ikke_> 5unix/libtclstub8.6.a
22:08 <_ikke_> that u mean?
22:08 <Xe> _ikke_: it's something special to tcl apparently, i only found out about it by digging through /usr/lib while looking for libtcl8.6.a, https://wiki.tcl.tk/285
22:08 <Xe> the stub library is not the entire tcl library, which is what i'd need
22:08 <_ikke_> Ok, so the compilation apparently only produces that file
22:09 <Xe> huh
22:09 <Xe> that's odd
22:10 Fusl joined
22:10 <Xe> ah well then
22:14 <_ikke_> http://tpaste.us/xew7
22:22 craftyguy joined
22:24 wener joined
22:45 wener joined
23:03 <hanez> hi, i took over maintainership for daemontools and ucspi-tcp about two years ago. these packages are in testing since then. is it possible to get them in community in some way?
23:04 <Shiz> sure, submit a PR :)
23:04 <Shiz> that moves it
23:05 <hanez> okay... but what's the normal process... just adding it too testing pulling it directly over to community would make no sense... so some time they should stay in testing or not?
23:07 <hanez> with djb software there is another problem. i believe these packages have been in community already but were "downgraded" to unmaintained some day because there where no updates. i belive these packages will not getting updates in the future thoug. so how to prevent them for being moved "down" again?
23:08 <skarnet> I don't have an answer for you but will use that opportunity for a plug
23:08 <skarnet> s6 and s6-networking, which do the same thing as daemontools and ucspi-tcp (basically, same commands, just prefix them with s6-), are in main/
23:09 <hanez> is there some discussion somewhere before moving packages to "unmaintained"?
23:09 <hanez> you mean i should prefix daemontools with s6-daemontools?
23:10 <skarnet> no, but s6-svscan, s6-supervise, s6-svc, etc.
23:10 <skarnet> and s6-tcpserver
23:10 <hanez> ah, yes... they do the same but a complete rewwrites as i know
23:10 <skarnet> yes, and for a reason
23:11 <hanez> so, you think there is no space for djb stuff?
23:11 <skarnet> oh, there certainly is space
23:11 <hanez> ok
23:11 <skarnet> but you can get the same functionality with a more recent and actually maintained code base :P
23:12 <hanez> i will maybe take a look at s6 in the future and maybe move over... but for now i will make a pull request to community
23:12 <skarnet> https://skarnet.org/software/s6/
23:12 <hanez> maybe that is the right choice in the future... ;)
23:12 <skarnet> you really will be in familiar territory if you know daemontools
23:13 <hanez> yes, i know these tools but was too lazy because djb stuff always worked for me... :P
23:13 <skarnet> of course they work, but they're unmaintained
23:14 <skarnet> it's like runit tbh
23:15 <hanez> yeah
23:15 <hanez> but, a s6-tcpserver package is not available btw.
23:16 <skarnet> s6-networking
23:16 <hanez> ah, yes i see
23:16 <hanez> thanks
23:16 <hanez> then it may it's useless to maintain djb stuff and could go ver to other stuff... ;)
23:17 <hanez> i would like to have netqmail in alpine.
23:17 <skarnet> it isn't there? hm.
23:17 <skarnet> (and no, there's no way I'm rewriting that one)
23:17 <skarnet> (not in the next decade anyway)
23:18 <hanez> there were licensing issues in the past because djb didn't allowed to package it but i think nowadays it's okay
23:18 <hanez> :D
23:18 <skarnet> it's been okay for more than 10 years now :P
23:18 <hanez> i want to migrate all my servers over to alpine this year and i really need qmail
23:19 <skarnet> tbh netqmail can easily be installed from the tarball
23:19 <hanez> does your tcpserver support ssl?
23:19 <hanez> skarnet: yeah, but a package would be nice
23:19 <skarnet> try s6-tlsserver
23:19 <hanez> wow, cool
23:20 <skarnet> and it should link against bearssl nowadays
23:21 <skarnet> try it, if it's linked against libressl then you have an old version
23:21 <skarnet> the new version takes 10% as much RAM :P
23:22 <hanez> great... i know your s6 stuff for some time but never took a deeper look inside but it looks nice. even your code is very nice and clean. easy readable...
23:22 _ikke_ joined
23:23 <skarnet> I learned from djb, and then I kept coding and improved :P
23:23 <hanez> looks very impressive to me and i believe it does al i want
23:25 <skarnet> cool then :)
23:25 <skarnet> if you have questions we have a #s6 channel
23:25 <hanez> okay... that's definitely much more djb ever had... :P
23:26 <skarnet> djb didn't have readiness notifications either ;)
23:26 <_ikke_> hanez: afaik, packages are only moved to unmaintained when there are issues building it / running it
23:26 <hanez> yep
23:26 <hanez> _ikke_: okay.
23:26 <hanez> i will make a pull request then.
23:27 <skarnet> and his supervise isn't a finite state machine, there are cases where svc is unresponsive :P
23:27 <hanez> but it looks like skarnet's stuff looks good for me too
23:27 <hanez> skarnet: yes, i had often these situations
23:28 <skarnet> did you? I'm impressed - those are corner cases and I only hit them when looking for them :D
23:28 <hanez> i had that in a very high volume/traffic qmail environmentt at a german tv-channel many years ago
23:29 <hanez> there were situations were we needed to kill processes the hard way
23:29 <skarnet> chances are that wasn't a "supervise doesn't respond to svc" case, but a lengthy lameduck problem
23:30 <skarnet> i.e. qmail needed time between the SIGTERM and the exit
23:30 <hanez> maybe... we couldn't really debug because it was a very productive system and in test environments it never happened
23:30 <skarnet> (s6 allows you to define a timeout, if the process hasn't exited after N milliseconds then it gets SIGKILLed)
23:31 <skarnet> (but you don't want to do that with qmail if you value your mail queue)
23:32 <hanez> yes, that's problem. destroying the queue as evil as hell... /o\
23:34 <skarnet> what could help you though is receiving a notification when the process has actually died
23:34 <skarnet> send the sigterm, wait for the notification, then proceed
23:34 <skarnet> s6 can do that
23:35 <hanez> it's nice to see all your stuff in arch's AUR repo so i could start testing you software soon
23:35 <hanez> cool
23:35 <skarnet> it's in AUR? heh. I have no idea who packages it for arch tho ^^"
23:35 <hanez> AUR are no packages just build instructions
23:35 wener joined
23:36 <hanez> if your stuff does a great job this stuff may should go into "community" in arch... ;)
23:37 <skarnet> tbh I've stopped being interested in arch (as well as Debian etc.) when they switched to systemd
23:37 <skarnet> so I don't know how arch works and I don't really want to know :P
23:37 <skarnet> musl distros are way above the others anyway :P
23:37 <hanez> yep, that is my problem too. on my desktop i do not care so much. my server farm runs gentoo on every mashine but that ofeten is a pain
23:38 <hanez> yes, ii will swwitch on my desktop away from arch too. but i have no time for that actually. i am planning to buy a new notebook soon and this device will never get in tocuh with systemd. ;)
23:40 <hanez> i run alpine and void in some virtual machines since some years and maintaining them is no work at all
23:40 <hanez> i prefer aalpine
23:40 <skarnet> for your next desktop, try Adélie. Also a musl distro. :)
23:41 <hanez> you do not use alpine on a desktop?
23:42 <skarnet> lots of people do. I don't, for the simple reason I basically don't use a desktop ;)
23:42 <skarnet> <- server man
23:43 <hanez> yeah, am server man too but i need a device to access them and i am writing a lot of software for fun and my work
23:45 <skarnet> same, but I made the decision long ago not to touch desktop software, because if I look under the hood I'll have an urge to rewrite everything
23:45 <skarnet> and I can't afford that.
23:46 wener joined
23:47 <hanez> yes, i don't do too. i use awesome wm and mostly minimal tools. i do not need much. in most cases vim is enough.
23:49 _ikke_ joined
23:49 <hanez> many years i spent often a lot more time maintaining my desktop then hacking on cool stuff. nowadays my desktop just works... no features but it works and i am extremely productive since minimalizing my workspace
23:50 <skarnet> ^
23:51 <skarnet> exact same reason why I don't want a fancy desktop