<    April 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 _2_9  
30
00:33 skarnet joined
01:00 blueness joined
01:11 <Shiz> https://pastebin.com/raw/TbZdhVwq
01:11 <Shiz> hmm...
01:32 s33se joined
02:03 tmh1999 joined
02:12 Emperor_Earth joined
02:14 blueness joined
02:55 <pickfire> https://github.com/SirCmpwn/sway/issues/1139#issuecomment-291476127
02:55 <pickfire> Is there an alternative to paxctl for alpine?
02:56 <Shiz> http://pkgs.alpinelinux.org/packages?name=paxctl&branch=&repo=&arch=&maintainer=
02:56 <Shiz> ?
03:00 <pickfire> Shiz: No, I mean is there other programs that is installed by default that is similar to paxctl?
03:01 <Shiz> why can't you use paxctl?
03:01 <Shiz> not that i know of
03:02 <Shiz> you may be able to use the attr package to set the xattr variant
03:02 <Shiz> setfattr -n user.pax.flags -v m /bin/myfile
03:02 <Shiz> like such
03:03 <Shiz> where what comes after -v is what you'd normally pass to paxctl, minus -
03:04 <Shiz> kaniini: why did paxctl get plonked in edge?
03:05 <kaniini> we only use xattr
03:05 <kaniini> paxmark is the replacement it pretty much works the same as paxctl
03:05 <kaniini> beyond that paxctl is not cross-endian safe
03:07 <Shiz> ah, didn't know of paxmark
03:07 <kaniini> paxmark sets xattrs
03:07 <kaniini> so basically
03:08 <kaniini> got dropped cuz it was outdated and broken for crosscompiling
03:23 <tmh1999> kaniini : so I enabled CONFIG_DEVTMPFS_MOUNT, rc-update add services you mentioned. and I have to # rc-update del networking boot because I don't have network config for kvm for now. and I am stuck at this : http://tpaste.us/Vbqz. I guess there is no tty available.
03:24 <Shiz> check your inittab file
03:24 <tmh1999> kvm option -append "console=tty0" doesn't help
03:24 <kaniini> try using /dev/console for the getty
03:25 <tmh1999> Shiz : I had to disable all tty[1-6] in inittab because it thrown not found error before
03:25 <kaniini> which might be the way to go by default
03:26 <tmh1999> kaniini : set it in inittab or kvm option ?
03:26 <kaniini> inittab
03:28 <Shiz> >[ 3.194544] console [ttyS1] enabled
03:28 <Shiz> seems like this is the on you want
03:28 <Shiz> not tty0
03:30 <pickfire> Shiz: How do I get the attr?
03:30 <Shiz> pickfire: apk add attr
03:30 <pickfire> Huh?
03:31 <pickfire> setfattr -n user.pax.flags -v m /bin/myfile
03:31 blueness joined
03:31 <Shiz> oh
03:31 <Shiz> getfattr -n user.pax.flags /bin/myfile
03:32 <pickfire> Shiz: Is there any man pages where I can know more about attr and stuff.
03:32 <pickfire> I don't know which to set for /usr/bin/sway
03:33 <Shiz> https://wiki.gentoo.org/wiki/Hardened/PaX_Quickstart#paxctl
03:33 <Shiz> flag overview is here
03:34 <tmh1999> Shiz : I tried ttyS1 and did't work
03:34 <tmh1999> kaniini Shi : /dev/console defintely work !
03:34 <tmh1999> kaniini : thank you :)
03:34 <pickfire> Looks like getcap /usr/bin/sway works as well
03:37 <Shiz> those are entirely different things
03:37 <pickfire> PaX looks complicated.
03:38 <Shiz> not particularly
03:38 <pickfire> Shiz: They called me to do sudo setcap cap_sys_ptrace,cap_sys_tty_config=eip /usr/bin/sway
03:38 <pickfire> And it works
03:38 <Shiz> that has nothing to do with pax
03:38 <pickfire> But still mouse and keyboard doesn't move.
03:38 <pickfire> Shiz: What does that relates to?
03:39 <pickfire> They said it is related to grsec
03:39 <Shiz> http://man7.org/linux/man-pages/man7/capabilities.7.html
03:39 <pickfire> sudo setcap cap_sys_ptrace,cap_sys_tty_config=eip /usr/bin/sway
03:39 <Shiz> it has nothing to do with grsec either
03:39 <pickfire> https://github.com/SirCmpwn/sway/issues/1139#issuecomment-291441398
03:40 <Shiz> the only one mentioning setcap in that thread is you...
03:40 <pickfire> I heard setting capabilities is nice but need a lot of effort compared to setuid bit.
03:40 <pickfire> Shiz: Yeah, they told me to do so.
03:40 <pickfire> https://github.com/SirCmpwn/sway/issues/1139#issuecomment-289421389
03:41 <Shiz> anyway, it has nothing to do with grsec or pax
03:41 <Shiz> that's just linux capabilities
03:41 <pickfire> Shiz: What does it have to do with?
03:41 <Shiz> 05:39:12 Shiz │ http://man7.org/linux/man-pages/man7/capabilities.7.html
03:42 <pickfire> Ah
03:42 <pickfire> Shiz: capabilities relates to setcap right?
03:42 <Shiz> yes
03:42 <pickfire> And grsec relates to setfattr
03:42 <pickfire> Oh, I think I get it now.
03:43 <pickfire> Before that, I assume setcap == setfattr
03:43 <Shiz> no, pax relates to the user.pax.flags xattr, which you can manipulate through setfattr
03:43 <Shiz> but yes, they are different things
03:45 <kaniini> tmh1999: so that means we have boot on s390x?? :D
03:45 <tmh1999> kaniini : technically I don't call it a boot process ?!
03:46 <tmh1999> kaniini : or I don't know
03:46 <kaniini> tmh1999: well i mean you booted to something inside qemu :)
03:46 <tmh1999> kaniini : yes :)
03:46 <tmh1999> kaniini : it's strange that I did nothing :|
03:47 <tmh1999> build the linux-vanilla thing, install it in a rootfs
03:47 <tmh1999> then copy /boot/* stuff
03:47 <tmh1999> then "boot"
03:52 <tmh1999> kaniini : oh man such a feeling
04:05 ppisati_ joined
04:12 MH0815 joined
04:13 tty` joined
04:13 dfs joined
04:17 xsteadfastx joined
04:54 <scadu> jirutka: xsteadfastx oh, I missed this one. btw, gst would require update. I will try to take a look this weekend, but I don't promise anything.
05:12 fabled joined
05:47 <xsteadfastx> scadu: if you find something out, tell me please :)
05:54 Madchen joined
06:38 <scadu> xsteadfastx: sure thing
07:27 stwa joined
07:49 t0mmy joined
07:58 fekepp joined
08:02 fekepp1 joined
08:03 royger joined
08:18 fekepp joined
08:36 atmoz joined
08:41 stwa_ joined
08:41 stwa_ joined
08:42 vakartel joined
09:03 alacerda_ joined
09:05 <xsteadfastx> clandmeter: im trying to split snapcast into a snapcast-client and snapcast-server subpackage. https://gist.github.com/xsteadfastx/b42ff77704227b40c0c8d1aae424506a is it right that package() is almost empty? or how should i handle that?
09:09 <clandmeter> xsteadfastx, yes thats right
09:09 <clandmeter> it will be a a meta pkg
09:09 <clandmeter> so what you can do is, make it depend on both server and client
09:10 <clandmeter> then when you add the meta, it will pull in both.
09:10 <xsteadfastx> ah thats cool
09:11 <clandmeter> you could also patch the makefile and remove bash from makedepends
09:11 <clandmeter> not sure why he wants bash in makefile
09:11 <xsteadfastx> thats what i though too
09:12 <xsteadfastx> now one question: what about the docs subpackage?
09:12 <xsteadfastx> this fails now
09:12 <clandmeter> ah right
09:12 <clandmeter> make install... has been removed.
09:13 <clandmeter> i would bring back make install... and then move the bins from pkgdir to subpkgdir
09:13 <xsteadfastx> i thought this wasnt needed if i use this as meta package
09:13 <clandmeter> and doc would have both server and client man pages.
09:13 <clandmeter> it isnt
09:14 <clandmeter> but then you need to manually copy the man files
09:14 <xsteadfastx> but... wouldnt apk add snapserver now install just the stuff from make install and not just the subpackages?
09:14 faffolter joined
09:15 <clandmeter> make install.. will install in pkgdir
09:15 <clandmeter> it installs the bins and man files (if im correct)
09:15 <clandmeter> if you move the bins to subpkgs, then the default_doc function will move the man files to -doc
09:16 <clandmeter> so main pkg (pkgdir) will be empty and a meta pkg
09:16 <xsteadfastx> aahhh ok now i understand
09:16 <xsteadfastx> because im moving them out... there are not in there anymore
09:16 <clandmeter> so you can do it whatever way you want to do it.
09:16 <xsteadfastx> in the final package
09:16 <clandmeter> they way i tell you will save you one line :)
09:17 <xsteadfastx> hehehe... and it makes more sense... and docs are working... i will try it now
09:17 <clandmeter> some projects dont have a proper makefile (missing make install) so you will have to copy the bins/files yourself.
09:19 <clandmeter> i just hope this guy's code is better then his packaging :)
09:21 <xsteadfastx> i dont know about the code... but the software works pretty neat
09:47 blueness joined
10:05 <clandmeter> fabled, do we already support LAZY in edge?
10:15 faffolter joined
10:22 <fcolista> uh? We have two perl-list-moreutils pacakges
10:22 <fcolista> one in main, one in community
10:23 <fcolista> I would remove the one one in community
10:24 stwa joined
10:35 blueness joined
10:39 <clandmeter> xsteadfastx, scadu, jirutka: we fixed mopidy (py-gst1).
10:39 <jirutka> clandmeter: \o/
10:39 <algitbot> \o/
10:40 <clandmeter> http://tpaste.us/nZkv
10:40 <xsteadfastx> wwuuaaattt??? :)
10:40 <xsteadfastx> unbelievabl
10:40 <xsteadfastx> e
10:41 <xsteadfastx> that makes me really happy
10:52 <clandmeter> xsteadfastx: https://git.alpinelinux.org/cgit/aports/commit/?id=7e0a0e26
10:52 <scadu> clandmeter: wololo, really?
10:52 <clandmeter> scadu, yes :)
10:52 <scadu> clandmeter: I suspected some missing switch, but...
10:53 <scadu> glad it's fixed. now, the only thing to do is moving mopidy from unmaintained to testing :P
10:53 <clandmeter> yeah we could
10:53 <clandmeter> do you prefer that over pip?
10:54 <scadu> clandmeter: not sure, I don't use mopidy on Alpine nowadays. xsteadfastx?
10:54 <scadu> clandmeter: maybe we could stick with pip for now.
10:54 <clandmeter> i will commit py-gst1 to aporst soonish
10:55 <scadu> \o/
10:55 <algitbot> \o/
10:55 <clandmeter> i think it needs to have support for both pythons
10:55 <scadu> I think so
10:55 <clandmeter> similar like gobject py
10:56 <clandmeter> and ill check if we can upgrade gst to latest stable
11:01 <jirutka> grrrr, error: An unknown error occurred To learn more, run the command again with --verbose. make: *** [Makefile:65: dist] Error 101
11:01 <jirutka> trying to build latest rustc…
11:02 <clandmeter> xsteadfastx, i added py-gst1 also to testing (just py2 support for now)
11:02 <jirutka> and I’m already running it with --verbose
11:03 <clandmeter> you should be able to add mopidy from pip and make sure you have all gst plugins
11:04 <jirutka> screw it, should go to work instead
11:05 <^7heo> yeah same here
11:05 <^7heo> I just arrived @work
11:17 <jirutka> ^7heo: deref @work
11:20 <^7heo> no please :D
11:20 <^7heo> I need it.
11:21 <jirutka> ok, other way: locate @work
11:21 <^7heo> ah you meant to GET the reference
11:21 <^7heo> not destruct it.
11:21 <^7heo> I see.
11:21 <^7heo> :D
11:21 <jirutka> yeah
11:24 stwa joined
11:26 vakartel joined
11:43 <fabled> clandmeter, yes, i cherry-picked LAZY stuff to edge
11:51 <jirutka> fabled: what’s LAZY stuff? o.O
11:52 <jirutka> wow, build of the latest rustc did NOT failed! \o/
11:52 <algitbot> \o/
12:10 fab joined
12:14 leitao joined
12:15 farosas joined
12:15 stwa joined
12:53 terra joined
13:06 <terra> guys, can we add minor release numbers like r7.2 for packages for testing purposes? It does seem that apk discards x.2 or so.
13:06 <^7heo> terra: what software are you referring to?
13:07 <^7heo> also, gpg2 is "broken"
13:07 <^7heo> at least according to its -doc package.
13:07 <terra> packages in general
13:07 <^7heo> terra: packages in general don't have a version number starting with r.
13:08 <terra> ^7heo: I'm talking about "release" numbers
13:08 <^7heo> terra: you mean patch numbers?
13:13 <terra> ^7heo: pkgrel="" in APKBUILD
13:15 <^7heo> yeah that.
13:16 <^7heo> our internal revision numbering.
13:16 <terra> for example, musl is r7 now but I'm doing some tests but I don't want to increase package release number during upgrades so I think increasing minor number would be good idea.
13:16 <^7heo> "I don't want to increase package release number" How is that our problem?
13:16 <terra> r7.1 detected by apk upgrade but 7.2 doesn't
13:17 <^7heo> look, just increase the $pkgrel
13:17 <^7heo> everyone does that, and unless you have a technical, not religious problem with it, it won't change.
13:17 <terra> ^7heo: in that case official release will be discarded..
13:18 <terra> I also want to in track with official releases
13:18 <^7heo> well, not if you send your patch for it.
13:18 <^7heo> and it gets in.
13:19 <^7heo> I don't see anything that cannot be solved by tagging anyway.
13:19 <terra> we are talking about different purposes.
13:19 <^7heo> if you install your package with apk add $file.apk it won't get upgraded automatically on apk upgrade AFAIK
13:19 <^7heo> if you install your package via your own repository, just tag it like @personal
13:20 <^7heo> and install musl@personal
13:21 <terra> my idea is better because it deviates minimum from official
13:22 <^7heo> whatever, this is a waste of time.
13:23 <terra> contrary, I find it very useful if apk supports minor package release number for testing puposes
13:24 <^7heo> the world doesn't orbit around you; submit patch you wrote on your own time, get it rejected, or not, not my problem.
13:24 <^7heo> until then, feel free to use the solution I wrote above.
13:29 <terra> ^7heo: neither around you..
13:30 stwa joined
13:36 tmh1999 joined
13:37 <nmeum> ^7heo: why is gpg2 broken?
13:38 <^7heo> nmeum: because the documentation documents options that aren't there.
13:38 <^7heo> nmeum: the documentation documents --receive-keys / --recv-keys but only the latter is implemented.
13:38 <nmeum> which ones?
13:38 <^7heo> that ^ at least; I have not found more yet.
13:39 <nmeum> well…send upstream a bug report? :p
13:39 <^7heo> no time for that.
13:40 <nmeum> I know that feel
13:40 <^7heo> The funny thing is that I wasted so much time trying to explain terra how to use apk
13:40 <^7heo> and then I lack time for relevant things.
13:40 <^7heo> well, I'm not good at time management, that is sure.
13:40 <nmeum> :)
13:40 <^7heo> Anyway, laters.
13:41 <nmeum> cu
13:47 <Shiz> i'll jump in and say gpg1 > gpg2
13:47 <Shiz> :p
13:47 <^7heo> Shiz: do we have gpg1 in the repos?
13:47 <Shiz> yes
13:47 <Shiz> it's just called gpg1
13:47 <^7heo> thanks a lot.
13:47 <Shiz> and replaces= gpg2
13:47 <Shiz> afaik
13:47 <^7heo> are both intercompatible?
13:48 <^7heo> ok they must be since they replace each other.
13:48 <Shiz> for most purposes, yes
13:48 <^7heo> ok
13:48 <Shiz> jirutka │ wow, build of the latest rustc did NOT failed! \o/
13:48 <algitbot> \o/
13:48 <Shiz> nice, making progress?
13:49 <^7heo> Shiz: I don't find it.
13:49 <Shiz> huuh what the hell
13:49 <^7heo> Shiz: do you mind running `apk info --who-owns $(which gpg1)`?
13:49 <Shiz> oh
13:49 <Shiz> gnupg1
13:49 <Shiz> sorry my bad
13:49 <^7heo> thanks ;)
13:49 <^7heo> better ;)
13:50 <Shiz> and the binary is just called gpg, not gpg1
13:50 <Shiz> :p
13:50 <^7heo> yeah, that's what I was using anyway, and I guess it was a symlink to gpg2
13:50 <^7heo> lemme try that now.
13:51 <^7heo> well, doesn't change anything, tbh
13:51 <^7heo> ah it does.
13:52 <^7heo> The doc is right.
13:52 <^7heo> :D
13:52 <Shiz> :)
13:52 <^7heo> thanks Shiz ;)
13:58 tmh1999 joined
14:08 <clandmeter> jirutka: https://linux.die.net/man/3/dlopen RTLD_LAZY
14:13 ovf joined
14:21 LouisA joined
14:26 <leitao> ncopa, we built go 1.8 on alpine/ppc64le from upstream.
14:26 <leitao> current go version on alpine is 1.7.4
14:26 <leitao> I think that 1.7.4 has issues with ppc64le.
14:27 <leitao> Is it possible to bump go to 1.8?
14:27 <leitao> or maybe disable go on ppc64le for 3.6
14:29 <ncopa> hum
14:29 <ncopa> thtas a good question
14:29 <ncopa> i think we want go 1.8
14:30 <ncopa> there was a pull request for go 1.8
14:31 <Shiz> nice
14:31 <Shiz> it seems like a good thing to include before 3.6
14:31 <Shiz> with the docker community and all
14:31 <Shiz> (same for rust, tbh)
14:32 NightKhaos joined
14:46 <mosez> has anybody planned to build galera packages for alpine? :D
14:47 <mosez> ah... it's included within the mariadb package
14:47 <Shiz> mosez: "There are no longer separate MariaDB Galera Cluster releases for MariaDB 10.1 and above. Simply download MariaDB (10.1 or above) and configure your cluster as normal."
14:47 <Shiz> yes
14:47 <Shiz> :p
14:48 <jirutka> Shiz: yeah, I’d like to move rust into community before v3.6, but there are some issues not yet solved
14:48 <Shiz> what are we looking at?
14:48 <jirutka> Shiz: currently we use hack to link it dynamically with musl that has some negative consequences
14:48 <Shiz> hmm
14:48 <jirutka> Shiz: but hopefully this can be avoided now
14:48 <Shiz> didn't the latest rust have an option for static/dynamic?
14:48 <jirutka> Shiz: upstream merged support for static/dynamic switching
14:49 <Shiz> :)
14:49 <jirutka> Shiz: next issue is that currently it downloads some crates from internet during build
14:49 <Shiz> and the builder is separate
14:49 <Shiz> yeah
14:50 <jirutka> I hope that I will manage to somehow solve it before v3.6
14:50 <Shiz> do you have a current apkbuild somewhere?
14:51 <jirutka> I’ll push updated apkbuild today at evening
14:52 <Shiz> :)
14:52 <mitchty> would be cool too to get idris/ghc into community for 3.6 too
14:53 <mitchty> agda is... a bit more involved but next on my list
14:56 <jirutka> mitchty: yeah, definitely!
15:03 <mosez> shiz: are you sure that it's enabled on alpine? i'm not sure which .so should be added as wsrep_provider
15:05 <mosez> https://forum.alpinelinux.org/forum/installation/installing-mariadb-where-wsrep-provider -.-
15:06 <mosez> the only wsrep file within the plugins dir is wsrep_info.so.so
15:07 <mosez> wsrep_info.so of course
15:33 NightKhaos joined
16:00 vakartel joined
16:32 <pickfire> I tried building tup for alpine but it shows tup warning: unshare(CLONE_NEWUSER) failed, and tup is not privileged. Subprocesses will have '.tup/mnt' paths for the current working directory and some dependencies may be
16:32 <pickfire> missed.
16:32 <pickfire> During bootstrap
16:33 <pickfire> What permission do I need to add?
16:34 fabled joined
16:35 BitL0G1c joined
17:33 minimalism joined
18:03 <duncaen> ncopa: does chromium work for you without the stack size patch for the shutdown detector?
18:14 Shiz joined
18:20 <jirutka> I don’t know if Rust devs just don’t give a fuck about musl-based systems or their build system is so complex and messed that even they are not able to change wrong assumptions they implemented into it…
18:21 <Shiz> what's up
18:21 <jirutka> just reading some issues about building Rust on musl-based systems…
18:21 <jirutka> like this one https://github.com/rust-lang/rust/pull/40113
18:22 terra joined
18:22 <skarnet> jirutka: #whynotboth
18:25 <terra> should I work in community or testing for new packages before commit ?
18:26 <jirutka> terra: new packages → testing
18:27 <terra> jirutka: thanks
18:28 leo-unglaub joined
18:38 <nmeum> jirutka: I believe it's the latter
18:39 <jirutka> it seems that the main problem is that they fucked it up before and now insists on preserving wrong behaviour for backward compatibility…
18:40 Shiz joined
18:41 czart__ joined
18:42 <nmeum> I've been briefly using rust this year for embedded development and I believe they fucked up the entire language
18:43 <jirutka> why do you think?
18:43 <jirutka> so
18:43 <TemptorSent> Conceptually, I like it -- but the details are a mess.
18:44 <TemptorSent> The language is a work-in-progress, and feels like it.
18:44 <jirutka> well, it’s still young; but they strongly preserve backward compatibility since 1.0
18:45 <TemptorSent> jirutka: Yeah, that's the problem I think... the language isn't mature enough to have that backwards compatability be a good thing :)
18:46 <TemptorSent> jirutka: It prevents them from overhauling major design decisions.
18:46 <jirutka> TemptorSent: yeah, I think that I can agree with that
18:48 <nmeum> I tend to agree with TemptorSent. Besides if you are using it without libstd you need nightly features for basically everything
18:48 <jirutka> not for everything, basically just for compiler plugins…
18:50 <terra> should we avoid release candidate versions of packages? abuild doesn't accept -rc3 version for instance.
18:51 <jirutka> terra: the correct format is _rc3
18:51 <terra> pff
18:51 <jirutka> terra: what?
18:51 <jirutka> terra: and yes, if you don’t have a special reason, then it’s better to stick to stable releases
18:51 <terra> jirutka: nothings. thanks btw.
18:52 <TemptorSent> Query: Preferred default location for staging directory for kernel/mkinitfs? /var/tmp/staging? /var/cache/staging? Something else?
18:53 <jirutka> TemptorSent: what exactly is the staging directory?
18:54 <TemptorSent> jirutka: The directory to unpack the kernel, modules (including externally packaged), firmware, dtbs, headers, etc. before installation/creating modloop/building initramfs.
18:55 <TemptorSent> jirutka: As well as staging userspace needed in initfs.
18:56 <jirutka> TemptorSent: /var/tmp
18:56 <jirutka> but not /var/tmp/staging, too general name
18:56 <TemptorSent> jirutka: Thanks. We don't clear automatically, correct?
18:56 <jirutka> maybe use mktemp?
18:57 <TemptorSent> jirutka: That doesn't work out well as the name changes each time.
18:57 <jirutka> TemptorSent: I think that /var/tmp is not cleared automatically, but not 100% sure
18:57 <Shiz> mktemp seems fine for this
18:58 <Shiz> not sure why you'd want a certain fixed directory
18:58 <TemptorSent> jirutka: We want the staging directories to persist, especially for building images or cross/platform
18:58 <TemptorSent> Shiz: Because it caches the downloaded/extracted files per arch (and per krel for kernel artifacts)
18:59 <TemptorSent> Shiz: So multiple invocations shouldn't be starting from scratch.
18:59 <Shiz> it should use /var/cache/distfiles for that
18:59 <TemptorSent> Shiz: That doesn't work for multiple arch apk roots.
19:00 <jirutka> TemptorSent: aha, then /var/cache/<something> for caching files used for multiple invocations (just these)
19:00 <Shiz> i mean, it should cache the downloads there
19:00 <Shiz> as they are ostensibly agnostic
19:00 <Shiz> and for the building work, just use a mktemp
19:00 <jirutka> . /var/cache/<???>/<arch>
19:00 <TemptorSent> Shiz: For each arch, you need to have an apkroot initilized with 'apk --arch $arch -p $root add --initdb'
19:02 <TemptorSent> jirutka: That's what I was leaning towards, the structure below the root is <arch>/<krel>/<pkg(-subset)>/
19:02 <TemptorSent> /var/cache/mkalpine/staging perhaps?
19:03 <jirutka> so you already have a name for your baby, mkalpine? :)
19:03 <TemptorSent> Since it will be used by update-kernel, mkinitfs, mkimage, for the modloop
19:04 <TemptorSent> jirutka: Well, mkimage certainly isn't in scope any more :)
19:04 <jirutka> that’s what terrifies me…
19:05 <TemptorSent> jirutka: Why? Becasue I seperated functionality into a distinct tool?
19:05 <TemptorSent> jirutka: That's the unix way :)
19:05 <jirutka> aha, so this is a name for a set of tools/scripts?
19:06 <TemptorSent> Right now, each tool is handling (or NOT handling in many cases!) staging it's own files.
19:06 <jirutka> aha, okay
19:06 <TemptorSent> jirutka: Yes, it's a suite of related tools.
19:06 <TemptorSent> jirutka: With common infrastruture to avoid duplicating things needlessly.
19:07 <jirutka> that sounds good
19:07 <TemptorSent> jirutka: That way we only have to define arch-specific stuff in one place, rather than having it scattered through scripts with special cases.
19:09 <TemptorSent> jirutka: And handling custom kernels reduces to a set of definitions for the targets we need (and one custom install step, since the kernel 'make install' target does NOT do what we want)
19:11 <TemptorSent> jirutka: so it will look something like 'kerneltool --arch s390x --stage all:/usr/src/linux --stage modules:zfs --stage firmware:linux-firmware'
19:11 <TemptorSent> With zfs and linux firmware using packaged versions.
19:12 <TemptorSent> It will check the flavor and version match for modules :)
19:13 <TemptorSent> Syntax not at all set in stone, suggestions welcome.
19:13 <TemptorSent> It detects the configured arch and kernel release from the build directory or an explicit apk automatically.
19:17 <TemptorSent> I haven't yet setup anything for downloading/extracting kernel sources, but I've considered how to make it so abuild can use it to build modules for multiple flavors of a kernel at one go.
19:17 fekepp joined
19:22 <TemptorSent> Ideally, mkinitfs wouldn't have to deal with modules at all, we can just have it give a list of module sets it wants and let kernel tool figure out the deps and cpio them up for mkinitfs to include.
19:24 <TemptorSent> That should eliminate most of the initfs breakage since we will know which packages we need installed and check that we've actually included the requested modules AND all deps (depmod -e)
19:25 <TemptorSent> 'mkmodloop' can use the exact same mechanism to allow us to specify modules for inclusion to trim the size depending on the needs of the system.
19:34 <Shiz> jirutka: if you have the apkbuild somewhere, i'd like to take a look ;)
19:35 <* Shiz> feeling up for some apkbuild hacking
19:35 <^7heo> APKBUILDs shouldn't need hacking
19:37 <Shiz> for the best definition of the word hacking
19:37 <Shiz> ;p
19:37 <^7heo> Installing NetBSD on a toaster?
19:43 <ncopa> duncaen: i dont know, i think i just copied the patch from void. (thanks!)
19:44 <duncaen> afaik no, the last commit just changed the version thats why i ask
19:44 <^7heo> ncopa: any chance to release mkinitfs?
19:44 <ncopa> ^7heo: not tonight
19:45 <ncopa> ^7heo: ping me tm and i'll try get it done
19:46 <^7heo> ncopa: awesome thanks
19:47 fabled joined
19:47 <TemptorSent> ncopa, ^7heo: Other than the mkinitfs script itself, initramfs-init, and the /usr/share files, is anything but nlplug-findfs in use?
19:48 <TemptorSent> (basically, bootchart :)
19:48 <ncopa> not really
19:48 <ncopa> i dont think we have used it for years
19:48 <ncopa> fabled: do we still use bootchart?
19:48 <fabled> not for a while
19:48 <fabled> i was hoping to use the new thing
19:49 <fabled> but it's still work-in-progress
19:49 <ncopa> but we can rip out the old bootchart?
19:49 <TemptorSent> In other words, could nlplug-findfs become its own package, since it require compilation, and make mkinitfs arch independent?
19:49 <ncopa> TemptorSent: it could
19:50 <ncopa> i just dont think i makes much sense to run initramfs without initramfs-init
19:50 <TemptorSent> It seems like that might clean up the tree a bit.
19:50 <ncopa> we should probably move all your work out to a separate git tree
19:50 <TemptorSent> ncopa: Right, but initramfs is a script as opposed to a compiled artifact.
19:51 <ncopa> i can move nlplug-findfs out to separate git repo if you feel strong for it
19:51 <TemptorSent> ncopa: Agreed. If you approve, perhaps a top-level mkalpine for all of the various mk-tools?
19:51 <ncopa> or we could create a subpakcage of it
19:52 <TemptorSent> ncopa: I don't feel terribly strongly about it, but I figure it would make tracking it in git much clearer.
19:52 <ncopa> ok
19:53 <TemptorSent> ncopa: That way changes to scripts don't change the repo for nlplug-findfs and make merges more complex.
19:54 <ncopa> initramfs-init is kind of tied to nlplug-findfs though
19:54 <TemptorSent> We have the existing tools of mkinitfs, mkimage, and update-kernel, to which I would like to add mkmodloop and kerneltool.
19:55 <ncopa> sounds good to me
19:55 <ncopa> so we keep nlplug-findfs in separate repo
19:55 tsuraan joined
19:55 <ncopa> and the others in your new repo?
19:56 <ncopa> and make mkinitfs a subpackage of alpine-mktools?
19:56 <TemptorSent> ncopa: Not necessarily, as nlplug-findfs could be used by someone rolling their own without the tools, and we could use mkinitfs to make inits that use very simple shims without nlplug-findfs
19:57 minimalism joined
19:57 <ncopa> ok
19:57 <tsuraan> do subpackage dependencies implicitly inherit the dependencies of the main package?
19:57 <tsuraan> I'm trying to install librbd, and it brings in all of ceph, but from https://git.alpinelinux.org/cgit/aports/plain/testing/ceph/APKBUILD, it doesn't look like it should need to
19:57 <Shiz> tsuraan: no
19:57 <Shiz> or well
19:57 <ncopa> tsuraan: i think it does
19:58 <Shiz> if the subpackage didn't override depends=, then yes
19:58 <Shiz> if it does, only if the override includes $depends
19:58 <Shiz> :P
19:58 <TemptorSent> ncopa: That would work, I'd have to make a couple changes to the layout of the dirs, but that's no problem.
19:58 <Shiz> so if the subpackage doesn't specify any deps, yes it wil
19:58 <tsuraan> in this case, the override for librbd() does replace depends with "librados"
19:58 <tsuraan> and then, librados doesn't replace depends. so it's inheriting everything. makes sense
19:58 <ncopa> TemptorSent: how the git repo dirs are organized and how we make subpackages is not really related
19:59 <Shiz> mama mia what a package
19:59 <tsuraan> the ceph one? yeah, it's pretty good :)
19:59 <TemptorSent> ncopa: Right, but it would make more logical sense than pulling files from three different directories.
20:00 <ncopa> nah
20:00 <ncopa> when we build a package
20:00 <ncopa> and "make install"
20:00 t0mmy joined
20:00 <TemptorSent> ncopa: There is a subset of files used by all tools.
20:01 <ncopa> the source file organization becomes completely irellevant
20:01 <ncopa> oh
20:01 <ncopa> so you have some shared files
20:01 <ncopa> thats no problem
20:01 <TemptorSent> ncopa: So if we want to have just what we need for mkinitfs, and not necessarily everything for mkimage, it would make sense to change a few things.
20:01 <ncopa> sure
20:01 <tsuraan> does alpine have a good way to provide different versions of a package? My ceph cluster is currently at 10.2, while 11.2 is probably recommended, and 12.x is coming out.
20:02 <ncopa> mkinitfs needs to run alone
20:02 <Shiz> tsuraan: not particularly right now
20:02 <Shiz> we typically solve it with different packages
20:02 <Shiz> (and replaces= if they conflict with eachother)
20:02 <TemptorSent> ncopa: Basically, the mkimage branch I have includes mkimage, mkinitfs, and update-kernel as modular components.
20:02 <Shiz> or conflicts=
20:03 <ncopa> good
20:03 <ncopa> but some shared shell functions?
20:03 <ncopa> i think we can sort that out
20:03 <TemptorSent> ncopa: so mkinitfs needs to know about it's feature and load those.
20:03 <tsuraan> okay, that'll work for me
20:04 <ncopa> need to go
20:04 <TemptorSent> ncopa: the plugin loader can already handle it, and the mkinitfs wrapper script is only loading a subset already.
20:04 <TemptorSent> ncopa: Okay, take care, and thanks for the input!
20:04 <ncopa> TemptorSent: thanks for working on this
20:05 <TemptorSent> ncopa: No problem, it will help save a few shreds of my sanity in the long run :)
20:06 <TemptorSent> ncopa: It also will stage everything, create manifests, and cache the stage dir per arch/krel, so we don't have to keep doing the same thing over and over again :)
20:07 <TemptorSent> ncopa: mkmodloop will be able to use the same feature sets as mkinitfs with very little additional work, for instance.
20:09 <ncopa> perfect
20:09 <ncopa> thats what i wanted for some time
20:09 <ncopa> im super happy that you help us clean up the mess :)
20:11 leo-unglaub joined
20:14 <Shiz> :)
20:20 LouisA joined
20:21 <TemptorSent> ncopa: I still have a bit more rolling-refactoring to do before it's all cleaned up, but it's moving that way while still keeping compatability with the old system as close as possible.
20:22 tsuraan left
20:24 <TemptorSent> ncopa: One BIG request for apk -- can we have 'apk search -x' allow searching with the full atom, for instance 'apk search -x linux-grsec-4.9.20-r0'?
20:25 <TemptorSent> ncopa: That's one of the big problems I'm having to work around currently.
20:28 <TemptorSent> ncopa: The other is extracting a manifest with signatures from the .apk, although I have an awk script that appears to work reading the tar file directly :)
20:35 alacerda joined
20:44 <TemptorSent> Question, how do we specify an arch and kernel release combination? is $arch/$krel appropriate?
20:45 <TemptorSent> (i.e. 'x86_64/4.9.20-0-grsec')
20:46 <TemptorSent> Or is ${arch}_${krel} better? (i.e. x86_64_4.9.20-0-grsec)
20:48 <terra> should I subscribe alpine-aports mailing list before sending patches via git?
20:49 <TemptorSent> The former is convenient for dir structure, and my preference if not objectionable for some unforseen reason.
20:50 <TemptorSent> And is there an existing notation for packages including arch?
20:54 <terra> oh, I just saw my post on aports mailing list :)
20:56 <Shiz> TemptorSent: the existing convention is ::, afaik
20:56 <Shiz> e.g. mypkg::noarch
20:56 <Shiz> but that my just be an artifact of some implementation thing in abuild
21:00 Emperor_Earth joined
21:29 <mitchty> well found a bug in the ghc testsuite for 8.2 :)
21:30 <mitchty> also learnt of a new "feature" of python 3.6 argv handling
21:38 <Shiz> oh?
21:39 <mitchty> yeah if you pass a tuple in, don't do this ("", ...) or if you have to, do (" ", ...)
21:39 <mitchty> the first is invalid in 3.6
21:44 blueness joined
21:51 <TemptorSent> Shiz: Thanks. I'm afraid the colon may break things in odd ways, but I suppose that could be mitigated with some escaping...
21:52 <TemptorSent> Shiz: For instance, what would you get if you used that format in a url?
21:52 <Shiz> why would you use it in a url
21:53 <TemptorSent> Shiz: Because you may want to use it in a script that pulls configs from a remote site.
21:54 <Shiz> seems like overengineering
21:54 <TemptorSent> Shiz: Not that it's currently implemented, but I can see the feature being useful to many.
21:54 <Shiz> colons work fine in urls, so?
21:55 <TemptorSent> Shiz: They sometimes need to be escaped.
21:56 <Shiz> then curl or wget can handle that
21:56 <TemptorSent> Shiz: But the point is that the colon is treated as a special char by the fs and such.
21:56 <Shiz> no?
21:56 <Shiz> : is not a special char in any *nix file system that i know of
21:56 <TemptorSent> Shiz: Many tools treat it as the host:file.
21:56 <Shiz> please don't highlight me every line
21:57 <TemptorSent> tar for instance.
21:57 <Shiz> that has nothing to do with the file system, and that's the problem of those tools
21:58 <TemptorSent> Okay, I can't use it transparently as a file name, how about that?
21:58 <Shiz> but you can
21:58 <TemptorSent> Just like I can't name files with a leading '-' and expect them to be handled correctly.
21:59 <Shiz> but you also can
21:59 <Shiz> that's what -- was invented for
21:59 <TemptorSent> 'touch a::b ; tar -cvf blah::blah.tar a::b'
22:00 <TemptorSent> Try it.
22:00 <TemptorSent> Having to use -- every invocation isn't reasonable, and not all tools even support it!
22:01 <Shiz> it worked
22:01 <Shiz> do i win now?
22:01 <Shiz> even if it didn't, you can't reasonably expect to workaround every shitty piece of software that thinks it needs to be clever
22:01 <TemptorSent> Okay, let me clarify my criteria: I need a fs-transparent means of indicating arch/pkgname-pkgver.
22:02 <Shiz> if some tar implementation doesn't accept filenames with colons, it's that tar implementation's fault
22:02 <Shiz> : is fs-transparent
22:02 <TemptorSent> Then why does the shell want to quote it in completion?
22:02 <Shiz> i don't know, posix doesn't say it should
22:02 <Shiz> http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html
22:03 <Shiz> The application shall quote the following characters if they are to represent themselves:
22:03 <Shiz> | & ; < > ( ) $ ` \ " ' <space> <tab> <newline>
22:04 <TemptorSent> type 'echo "$PATH"'
22:04 <Shiz> what about it
22:09 BitL0G1c joined
22:20 <TemptorSent> I'm trying to break LESS things unintentionally.
22:24 <TemptorSent> So if ::$arch is used safely and universally already, that's fine, but if it's an artifact from on particular use that never was considered in terms of using it elsewhere, I'd prefer not to perpetuate that.
22:25 <TemptorSent> But the inability for the tar built into busybox to handle it in an output filename is enough to cause problems without having to look very hard.
22:29 <TemptorSent> Whereas the '/' does the right thing automatically and creates the tar file under the arch dir, with the requirement the directory exist, and '_' allows for flattening the filesystem, if that is desirable.
22:30 <Shiz> busybox tar can handle it just fine though?
22:30 <Shiz> you're thinking of gnu tar, probably :p
22:31 <Shiz> but yeah im not sure on arch conventions, i think fabled would know best
22:32 <TemptorSent> Thank you. And I get an io error when I try on my system.
22:32 <TemptorSent> It looks like I did end up with gnu tar on here somehow :/
22:35 <TemptorSent> And the sad thing is that NONE of the tar programs available in packages that I've found can acutally read the PAX headers and spit them out properly!
22:36 <Shiz> ;p
22:36 <Shiz> i think gnu tar may be part of build-base or alpine-sdk
22:37 <TemptorSent> Yeah, I didn't notice that it had overwritten the bb link.
22:37 <Shiz> $ apk info -r tar
22:37 <Shiz> tar-1.29-r1 is required by:
22:37 <Shiz> abuild-2.29.0-r2
22:38 <TemptorSent> Yeah, I'll have to make sure and test against bb tar explicitly and make sure no gnuisms get in there.
22:41 <TemptorSent> Anyway, I'm working on unmangling the kernel/module installation handling, hence the interest.
22:42 <Shiz> hey, as long as you retain the option to build an initramfs without any kernel stuff in it
22:42 <Shiz> :p
22:43 <TemptorSent> Actually, that's largely what I'm working on improving.
22:44 <TemptorSent> And fixing it so it actually makes sure you have the required packages you need to install the files in the initfs features.
22:45 <TemptorSent> The entire kernel staging mess for modloop,update-kernel, and mkinitfs is getting extracted to its own tool.
22:46 <TemptorSent> Currently, it will silently fail in an unbootable manner if something didn't update right during an upgrade.
22:47 <TemptorSent> This way, the upgrade is essentially atomic.
23:01 blueness joined
23:27 <kaniini> jirutka: you around?
23:27 <jirutka> kaniini: sort of…
23:27 <kaniini> jirutka: i think i have a solution to this php5/php7 php-config conflict
23:27 <jirutka> kaniini: continue…
23:28 <kaniini> jirutka: we just use .post-install script to set up the symlink to the right php-config binary (ghetto alternatives)
23:28 <jirutka> kaniini: no
23:28 <kaniini> jirutka: that is all we can do
23:28 <jirutka> kaniini: how you can specify what should be the default?
23:29 <kaniini> jirutka: the idea is that php-config by default points to php-config7, but if it does not already exist, then php-config5 could claim it. but php7-dev will always set it to php-config7.
23:31 <jirutka> kaniini: I really don’t like idea of introducing semi-working hackish update-alternatives in this way; since we agreed to keep only php5 pkg and use it as dependency only in app pkgs that require php5, it’s imo better to just add version suffix to all php5 binaries (without any symlinks
23:31 <jirutka> or to let them in conflict
23:31 <kaniini> jirutka: i can go that way too. but i intend to solve this now, as in right now. so i will go that way
23:32 <kaniini> it is blocking my rebuild
23:32 <jirutka> I’m afraid that once we do this, other will start using it too and there will not be motivation to create a real solution instead of this hack
23:32 <kaniini> i agree
23:32 <kaniini> lets just fix php5 by removing the php-config symlink (and make it php-config5 instead)
23:33 <jirutka> I’d prefer to start with removing php5-* pkgs
23:33 <jirutka> then add version suffix to php5
23:33 <jirutka> this should solve issue with building
23:33 <kaniini> do you know which php5-* packages can be nuked?
23:34 <jirutka> there are also two PRs from Vakartel about refactoring php5/php7 pkg, but it’s really huge and still didn’t have time and mood to review it
23:34 <jirutka> IIRC Valery said that basically all of them
23:34 <jirutka> b/c existing pkgs that require php5, like phpldapsomething, don’t need any php5-* extensions
23:35 <Shiz> remove everything and see what builds
23:35 <Shiz> :p
23:39 <jirutka> omg, rustc doesn’t work, b/c it somehow hard-coded wrong absolute paths into rlibs >_<
23:39 <Shiz> oh! i think i had that one too
23:39 <Shiz> fun innit
23:40 <jirutka> or at least it looks like this…
23:40 <jirutka> not entirely sure when reading stack trace again
23:41 <jirutka> hm, looks more like two unrelated issues
23:41 <jirutka> crt1.c:(.text+0x0): multiple definition of `_start'
23:41 <jirutka> what does this really mean?
23:42 <Shiz> jirutka: it means crt1.o got linked in twice
23:42 <Shiz> i think
23:42 <jirutka> huh
23:43 <Shiz> maybe it's also foolishly linking in crt1.o into libraries?
23:43 <jirutka> okay, gonna write bug report
23:43 <jirutka> i don’t know; I’ve used this patch https://github.com/rust-lang/rust/pull/40113
23:43 <Shiz> or maybe it supplies its own start()
23:43 <jirutka> probably not complete yet?
23:43 <Shiz> but that sems VERY unlikely
23:43 <Shiz> jirutka: have you looked at void's patch for the same?
23:44 <jirutka> Shiz: yes, they use my old method
23:44 <Shiz> ah
23:44 <jirutka> Shiz: that has some negative consequences, so not really suitable for anything but testing
23:44 <Shiz> gotcha
23:44 <jirutka> Shiz: this patch should be more clean, but something is still fucked
23:45 <Shiz> the latest comment in that link:
23:45 <Shiz> "About figuring out when to pass -nostdlib and crt*, I found the easiest way to get things working both shared and static was to remove them entirely. In other words, if we just let the linker find libc and the startup files, we don't need any overriding at all (no linker flags, no musl root), as long as the linker knows where to find the files. And if the compiler is native, an appropriate cross linker
23:45 <Shiz> exists, or musl-gcc exists, that is a valid assumption. "
23:45 <Shiz> this seems like the ideal approach
23:45 <Shiz> but not what the PR does right now
23:45 <jirutka> I heard that Julia is quite fucked… and still it was so less pain to build it on musl, just a matter of days
23:45 <Shiz> so the appropriate change seems to be to remove it passing -nostdlib and the crt files
23:46 <jirutka> it’s almost a year since I started dealing with this
23:46 <Shiz> i think rust's main issue is simply treating musl as a non-native target
23:46 <jirutka> I’ve already removed -nostdlib
23:46 <Shiz> jirutka: then don't pass crt*.o either
23:46 <Shiz> that is your issue
23:46 <Shiz> :p
23:46 <jirutka> hmm, but how?
23:46 <Shiz> https://github.com/rust-lang/rust/pull/40113/files#diff-76b86accb738e520d5b72633f76a77f5L59
23:46 <Shiz> remove this
23:47 <jirutka> haa
23:47 <Shiz> and the stuff around it
23:47 <Shiz> the crt*.o stuff is implied if you don't pass -nostdlib
23:47 <Shiz> no wonder you get a dupe start definition if you als pass it explicitly
23:47 <Shiz> they get linked in twice :D
23:47 <jirutka> btw every bigger software team, especially when developing new lang, should have at least one person with experience from packaging for some linux distro
23:48 <jirutka> these all issues would not happen then
23:48 <Shiz> well, the issue here is, this all works for glibc
23:48 <Shiz> their problem is treating musl like primarily an xcompile/non-native target
23:48 <Shiz> which leads to huge issues for us
23:48 <kaniini> grrrr
23:48 <jirutka> no, the issue is that they made some very stupid assumptions and they are rooted to bones of their build system
23:48 <kaniini> we need to solve this php5 thing
23:48 <jirutka> kaniini: yes
23:48 <Shiz> kaniini: like i said :P
23:48 <jirutka> kaniini: it’s broken as hell, I know
23:48 <Shiz> remove all php5- packages
23:48 <Shiz> see which builds break
23:48 <Shiz> re-add the ones that are needed
23:49 <jirutka> kaniini: but why it bothers you now? already branching v3.6?
23:49 <jirutka> Shiz: no, this is not a good approach… we already seen this and it created a lot of mess
23:49 <Shiz> okay
23:49 <kaniini> jirutka: i am doing a rebuild on my own machines to determine where we are at
23:49 <jirutka> kaniini: aha
23:50 <jirutka> so just remove all php5 craps locally?
23:50 <Shiz> jirutka: fwiw i was never claiming to do it in the main git
23:50 <Shiz> just locally
23:50 <kaniini> do you know what mailing list or github or whatever
23:50 <Shiz> for testing
23:50 <kaniini> vakartel said this plan on
23:50 <kaniini> because i can test it, but i need to know what he actually proposed
23:50 <jirutka> kaniini: https://github.com/alpinelinux/aports/pull/1061 (bottom of page)
23:51 <kaniini> ok
23:51 <kaniini> i was looking in patchwork and aports list
23:51 <jirutka> kaniini: he hasn’t, I’ve proposed solution after discussion with few core devs (including you actually :P)
23:51 <jirutka> kaniini: the last patch for php I’ve seen in Patchwork from Vakartel was just trying to broke it even more
23:52 <kaniini> okay
23:52 <kaniini> i see what to do on 1061
23:52 <jirutka> kaniini: he added replaces= to php5/php7… imo he doesn’t have a clue what it really means, because it would totally broke it
23:52 <kaniini> i will test it and if it is good, i will push
23:52 <kaniini> it is nice having an e5-2690v2 sitting in my closet
23:53 <kaniini> i can sit here and do test runs all day
23:53 <Shiz> only v2?
23:53 <Shiz> pleb
23:53 <Shiz> :p
23:53 <kaniini> i will start a go fund me
23:53 <kaniini> to get a new one
23:53 <kaniini> if u want to donate
23:53 <kaniini> :)))))
23:54 <jirutka> kaniini: 1061 looks okay, but I read it only in hurry
23:54 <* Shiz> has a E5-2679 v4 lying around
23:55 <jirutka> kaniini: only single CPU board?
23:55 <kaniini> dual cpu
23:55 <jirutka> kaniini: I use 2 * 12 cores / 64 GiB RAM / 2x VelociRaptor for testing :P
23:55 <kaniini> 40 threads total
23:55 <kaniini> 256gb ram
23:55 <jirutka> uh… ookay…
23:56 <jirutka> I’m ashamed now XD
23:56 <Shiz> hehehe
23:56 <kaniini> i have 3 of them
23:56 <jirutka> wut?!
23:56 <kaniini> i am going to make a rebuild server someday
23:56 <kaniini> that lets me build in parallel across all 3
23:56 <jirutka> I should say my boss that I need new servers…
23:57 <kaniini> something like debian's rebuildd
23:57 <kaniini> except obviously working with aports trees
23:57 <kaniini> instead
23:57 <Shiz> jirutka: you can get cheap v2s on ebay these days too
23:58 <kaniini> yes, these 3 came from eBay
23:58 <kaniini> probably
23:58 <kaniini> some vps company
23:58 <kaniini> or some such
23:58 <jirutka> Shiz: I don’t wanna pay for them, I have already many servers around, just no one so powerful :/
23:58 <Shiz> heh
23:58 <kaniini> i had to replace the HDDs though
23:58 <Shiz> my only server is an E3-1231 v3
23:58 <kaniini> they all basically failed
23:59 <kaniini> cuz they were seagate junk
23:59 <kaniini> replaced them with HGST
23:59 <Shiz> i was considering making my next workstation from second hand xeons
23:59 <kaniini> seems OK so far
23:59 <Shiz> you can get 40 cores + mobo + 64gb ram for... #350
23:59 <algitbot> Feature #350: Please update Nagios and Nagios-web to latest version - Alpine Linux - Alpine Linux Development: http://bugs.alpinelinux.org/issues/350
23:59 <Shiz> $350
23:59 <Shiz> roughly
23:59 <Shiz> 40 threads*
23:59 <kaniini> anyway