<    March 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:54 mikeee_ joined
02:13 gromero joined
02:28 s33se joined
02:52 royger joined
03:56 Emperor_Earth joined
05:25 royger joined
05:34 blueness joined
05:37 royger_ joined
05:54 mattjbarlow joined
06:24 fabled joined
06:29 slukin joined
06:34 systmkor joined
06:50 stwa joined
06:52 <TemptorSent> Hello fabled, how are you?
06:52 <fabled> TemptorSent, hey, back online. catch backlog.
06:53 <fabled> catching up on backlog*
07:08 <TemptorSent> fabled: Oh.. see you in couple days then I guess ;)
07:08 vakartel joined
07:23 t0mmy joined
07:36 <fcolista> fabled, i know this is up on my head, but any hint from you can be enlightening: https://dpaste.de/UgF3#L8
07:37 <fcolista> i've greenbone-security-assitant crash when I login
07:37 <fcolista> this collected the core dump and run gdb to get the backtrace
07:37 <fcolista> *I collected
07:38 <fcolista> i've sent those info to openvas devel since one year, never got a reply. So I contacted them over irc
07:38 <fcolista> still waiting for reply
07:38 <fcolista> I wondering what else i should send to help them in troubleshooting
07:39 <fcolista> Seems that nobody uses greenbone security assistant on musl..
08:26 mackson joined
08:28 <fabled> fcolista, do we have alpine or upstream bug report on it?
08:29 <fcolista> fabled, yes.
08:29 <fcolista> http://lists.wald.intevation.org/pipermail/openvas-devel/2016-November/003769.html
08:29 <fcolista> I've rebuilt greenbone with symbols
08:30 <fcolista> and this is the backtrace i got: https://dpaste.de/7qb3
08:38 <fcolista> thsi is with full symbols (from oepnvas-libraries too): https://dpaste.de/VzR8
08:46 <TemptorSent> Hey fabled, can you take a look at the behavior of --cache-dir when --root is also passed and let me know if that is what you intended?
08:47 <TemptorSent> It's forced to a relative (to --root) root even when it was passed an absolute
08:49 <fabled> TemptorSent, hum, i did not test that. it should probably be absolute.
08:50 <TemptorSent> Okay, that's what I thought -- it's being set based on root_fd,db->cache_dir IIRC.
08:50 <TemptorSent> Does the same apply to host keys?
08:50 <TemptorSent> If so, the easy thing would be to check the leading / and force absolute if present.
08:51 <fabled> hum
08:51 <fabled> i thought leading / makes it absolute
08:51 <fabled> that's how openat() should work
08:52 <fabled> man page says:
08:52 <fabled> If pathname is absolute, then dirfd is ignored.
08:52 <TemptorSent> Hmm, not acting right for me at least then.. I get a rather empty cache dir.
08:52 <TemptorSent> I'm wondering if it may be actually overwritten by --root processign then.
08:53 <fabled> should not be
08:53 <TemptorSent> What I'm trying to do is replace all apk calls with $APK calls, which I have set as APK="abuild-apk --cache-dir=$cachedir"
08:53 <TemptorSent> ...thus the root command and --root follow the --cache-dir spec.
08:53 <fabled> yeah, that makes sense and was on my planned changes. but even better if you get it done :)
08:54 <TemptorSent> You might want to take a look at the PR ;)
08:56 <TemptorSent> Also, I have a question, would it be absolutely horrific to get rid of the separate _flavored lists and append an artifical "flavor" of "FLAVOR" to the packages that need the special help instead?
08:57 <TemptorSent> ...and let a quick run through sed | xargs take care of the damage :)
08:59 tmh1999 joined
08:59 <TemptorSent> In fact, take a look at the most recent push just a few seconds ago and you can see where mkinitfs can now be dovetailed in with almost no effort beyond a call.
09:00 <TemptorSent> At this point, I could use some input regarding the rest of the boot architecture and where you want to go with things.
09:01 <TemptorSent> It's almost to the point I can use it for my real-world needs, but I won't pretend to have all the use-cases covered.
09:04 <TemptorSent> Oh, and a bunch of people have been on asking about how to do zfs-root, so it might be good to document what's actually supported, as I think people expect it to work out of the box and setup with setup-alpine.
09:12 <TemptorSent> Basically what's left is a couple calls to the plugins loader, a bit of startup code and argument passing, an iterator or two, and really not much more that's not implemented as a plugin.
09:13 <TemptorSent> I have a few more things that bug me that are on the TODO list, but I hit many of the major ones already, and hopefully it's fairly readable.
09:22 jlyo joined
09:23 fekepp joined
10:36 vakartel joined
10:56 blueness joined
11:15 <fabled> fcolista, yes, looks out-of-stack
11:18 <fcolista> fabled, how do we workaround this issue with musl?
11:21 <fabled> i suspect it's libmicrohttpd creating threads, and gsad not requesting large enough stack size
11:26 <fabled> fcolista, try something like http://sprunge.us/jdKS
11:27 <fcolista> great
11:27 <fcolista> let me patch
11:32 <fcolista> ok, i've applied the patch.
11:32 <fcolista> https://dpaste.de/N2a8
11:32 <fcolista> it still segfaults
11:32 <fcolista> guys from openvas says that it's related to a malloc() which fails (maybe due to too much local variables declared)
11:32 <fcolista> *might be related, actally
11:51 <fabled> fcolista, try 4MB ?
11:52 <fcolista> fabled, i tested a HUGE amount
11:52 <fabled> oh
11:52 <fcolista> 512*1024*1024
11:52 <fabled> that's not good
11:52 <fabled> but the crash location is different now too
11:53 <fcolista> https://dpaste.de/makz
11:53 <fcolista> this is the new crash
11:54 <fcolista> this is the crash with stack 512*1024*1024
11:55 <fabled> strace?
11:55 <fcolista> doing right now
11:55 blueness joined
11:56 <fcolista> https://dpaste.de/2g8D
11:56 <fcolista> here we go
11:57 <fabled> fcolista, thread size did not change, i think your value was too large or something
11:58 <skarnet> you need to strace -f to show what created threads are doing, those are the ones that are segfaulting
11:58 <skarnet> the main thread is just blocking in pselect()
12:00 <fabled> yeah, that too. but mmap() before clone() says it's allocating only ~80k stack
12:01 <skarnet> yeah
12:01 <fabled> so either the patch is not working, or something else is wrong
12:01 <skarnet> does the thing actually call pthread_attr_setstacksize() with the value it's given in your patch?
12:02 <fabled> it should
12:03 <skarnet> I can't help but read "gsad" as "gee... sad."
12:17 gromero joined
12:19 leitao joined
12:21 ferseiti joined
12:26 blueness joined
12:28 blueness joined
12:42 farosas_ joined
12:53 vakartel joined
12:57 blueness joined
13:03 <fcolista> fabled, how did you see the 80k stack?
13:07 Ganwell joined
13:10 Ganwell joined
13:14 <fabled> fcolista, in the end of the strace:
13:14 <fabled> mmap(NULL, 90112, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x3353d255d000
13:14 <fabled> mprotect(0x3353d255e000, 86016, PROT_READ|PROT_WRITE) = 0
13:14 <fabled> clone(child_stack=0x3353d2572a98, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID|0x400000, parent_tidptr=0x3353d2572b20, tls=0x3353d2572ae8, child_tidptr=0x3353d2572b20) = 3989
13:14 <fabled> the second argument (first non-null) to mmap()
13:15 <fcolista> ah
13:15 <fcolista> 90112
13:15 <fcolista> so the patch actually didn't change the stack size
13:16 <fcolista> anwyay, the segfault happens in openvas-libraries
13:19 <fabled> yes, but in a thread created from libmicrohttpd
13:19 <fcolista> ok
13:20 <fcolista> I've tested libmicrohttpd
13:20 <fcolista> with doc/examples it is shipped
13:20 <fcolista> (wondering if it's libmicrohttpd having issue)
13:20 <fcolista> it works
13:20 <fcolista> with all examples
13:20 <fabled> oh, there's a bug in my patch
13:20 <fcolista> so this is defenetly a openvas bug
13:20 <fcolista> really?
13:20 <fabled> it's https?
13:21 <fabled> affects https only
13:21 <fcolista> i tried both
13:21 <fcolista> http and https
13:21 <fabled> hmm, should've worked for http
13:21 <fabled> http://sprunge.us/ASMi
13:21 <fabled> the https side needs the parameter before dh_params due to it being conditional
13:22 <fcolista> applied
13:22 <fcolista> testing now
13:22 leitao joined
13:25 <fcolista> http://sprunge.us/MNLB strace output
13:26 <fcolista> still 90112
13:44 <fabled> strange
13:44 <fabled> sounds like the patch is not working then
13:45 <fcolista> interestingly. fabled
13:45 <fcolista> http://sprunge.us/GZAj
13:46 <fcolista> https shows that stack is augmented
13:46 <fcolista> 532480
13:46 <fcolista> this is when i run gsad via https
13:56 <fabled> well, it seems to crash regardless
13:56 czart_ joined
13:57 <fcolista> right
13:57 <fcolista> so it's not due (only) to the stack size
13:58 <fabled> oh
13:58 <fabled> you have newer gsad than me
13:59 <fcolista> yes. Is the one in edge
14:02 <fabled> fcolista, seems there's unix listener now, so http://sprunge.us/gQOX
14:02 <fabled> not sure if that is it or not
14:03 <fcolista> building with this patch
14:03 <fabled> but i suspect it might be something different, since it crashed with https too
14:04 <fcolista> oh
14:04 <fcolista> gsad does not build with this patch
14:04 <fcolista> /home/fcolista/aports/community/greenbone-security-assistant/src/greenbone-security-assistant-7.0.2/src/gsad.c: In function 'start_unix_http_daemon':
14:04 <fcolista> error: 'MHD_OPTION_STACK_SIZE' undeclared (first use in this function)
14:04 <fcolista> should be declared
14:05 <fabled> typo, they should be MHD_OPTION_THREAD_STACK_SIZE
14:06 <fcolista> ah ok
14:06 <fabled> as in http://sprunge.us/gFJE
14:06 <fcolista> http://sprunge.us/JYOI
14:06 <fabled> but i think there's something more going on
14:06 <fabled> any simple way to reproduce?
14:07 <fcolista> apk add openvas-manager
14:07 <fcolista> apk add openvas-cli openvas-scanner
14:07 <fcolista> apk add greenbone-security-assistant python
14:07 <fcolista> apk add redis
14:07 <fcolista> sed -i -e "s/# \(unix.*\)/\1/" /etc/redis.conf
14:07 <fcolista> rc-service redis start
14:07 <fcolista> rc-update add redis
14:07 <fcolista> greenbone-nvt-sync
14:07 <fcolista> greenbone-scapdata-sync
14:07 <fcolista> greenbone-certdata-sync
14:08 <fcolista> openvas-manage-certs -a
14:08 <fcolista> rc-service openvassd create_cache
14:08 <fcolista> rc-service openvassd start
14:08 <fabled> urgh :)
14:08 <fcolista> openvasmd --create-user=admin --role=Admin
14:08 <fcolista> openvasmd --rebuild
14:08 <fcolista> rc-service openvasmd restart
14:08 <fcolista> then, as last:
14:08 <fcolista> /usr/sbin/gsad --listen= --port=80 --mlisten= --mport=9390 --http-only -f
14:08 <fcolista> :D
14:09 <skarnet> I like your simple ways to reproduce
14:09 <fcolista> jsut forgot the "simple" part
14:10 <fcolista> :)
14:18 <fabled> fcolista, urgh, the openvas-libraries seem to allocate 1MB on stack
14:18 <fabled> try: http://sprunge.us/Vigd
14:20 <fabled> it affects directly scalability and memory usage in high-traffic situations
14:20 <fabled> it allocates thread per connection
14:20 <fabled> i think it would be appropriate to file a bug against openvas-libraries on the huge stack variable
14:20 <fabled> it's not good in embedded platforms
14:21 <fcolista> fabled, tried this patch : http://sprunge.us/Vigd
14:21 <fcolista> stil lsegfault
14:30 <fabled> fcolista, try http://sprunge.us/EBJK
14:30 <fabled> it seems to need 2 1MB buffers
14:31 <fabled> so 2mb stack is not enough
14:31 <fabled> that's kinda lame code
14:31 fekepp joined
14:31 ferseiti joined
14:39 <ncopa> fcolista: i think it should be reported upstream
14:39 <fcolista> ncopa, with 4*1024*1024 patch gsad works
14:40 <ncopa> i think you should report it upstream
14:40 <fcolista> ncopa, yes of course
14:40 <fcolista> i was on openvas channel
14:40 <fcolista> irc channel
14:40 <fcolista> since this bug is there since 1yr
14:40 <ncopa> its not good to expect 4MB stack
14:40 <fcolista> and nobody cared
14:40 <ncopa> code is gnu style
14:41 <ncopa> ...
14:41 <fabled> yeah, it's crappy xml parser requiring two 1MB buffers on stack
14:41 <ncopa> its an xml parser?
14:41 <ncopa> ugh
14:41 <ncopa> thats security issue then
14:42 <fabled> it's thread per-connection, with 4MB stack; not great for scalability...
14:42 <ncopa> urgh
14:42 <ncopa> well
14:43 <ncopa> on gnu libc its 8MB per connection then :)
14:43 <fabled> oh, i thought glibc has 4mb stack
14:43 <ncopa> glibc has 8 by default
14:43 <ncopa> or whatever you set with ulimit
14:43 <fabled> ok
15:00 trn joined
15:13 vakartel joined
15:15 dsabogal joined
15:15 mikeee_ joined
15:29 fabled joined
15:30 fekepp joined
15:35 <ncopa> fcolista: did you have a backtrace of the openvas-library problem?
15:37 <ncopa> hum
15:37 <ncopa> i think i found it
15:38 <ncopa> well its multiple places
15:38 <ncopa> i wonder if they have some recursive thing
15:39 <fcolista> ncopa, they fixed the issue in their svn repo
15:41 <fcolista> "<bricks> svn
15:41 <fcolista> <bricks> we did allocate several mb for the xml parser on the stack instead of using the heap"
15:43 <ncopa> so they did that on purpose?
15:44 <fcolista> apparently yes
15:46 <* skarnet> slow claps.
15:48 <ncopa> skarnet: do you have any url or reference i can use that explains why it is a bad idea
15:48 <ncopa> its a thing that pops up once in a while
15:48 <fcolista> using the stack rather than the heap?
15:49 <ncopa> yes
15:49 <skarnet> using the *thread* stack
15:49 <ncopa> allocating bigger buffers on the stack instead of on heap
15:49 <skarnet> it's a bad idea precisely because of that very use case
15:49 <ncopa> why that is a generally bad idea
15:49 <skarnet> systems generally have limited stack space
15:49 <ncopa> the "fix" i guess is to allocate bigger stack space
15:50 <ncopa> *thread* stack space
15:50 <skarnet> it doesn't matter in a single-threaded program
15:50 <skarnet> but in a multi-threaded program, you have one address space for N threads
15:50 <skarnet> so N stacks have to share the address space
15:51 <skarnet> so you need to decide in advance how much vsz you'll give each stack
15:51 <ncopa> doesnt it also have a perfomance impavt?
15:51 <ncopa> impact*
15:51 <skarnet> it does unless you overcommit
15:51 <ncopa> i mean, if you have your big data on large stack
15:52 <skarnet> the thing is, stack overflow can't be caught like heap overflow
15:52 <ncopa> *nod*
15:52 <ncopa> im thinking cache misses
15:52 <skarnet> so in order to avoid crashes, if you don't overcommit, then you gotta commit all your stack when you create a thread
15:52 <ncopa> if you have large buffer on stack
15:52 <skarnet> (maybe not, but in theory you should)
15:52 <ncopa> data is populated over various functions
15:53 <skarnet> again, I don't think it matters for single-threaded programs with only 1 stack
15:53 <ncopa> then you'd get cpu cache misses on every call?
15:53 <skarnet> that I don't know
15:53 <skarnet> but the problem I'm aware of is definitely virtual space explosion
15:54 <skarnet> and I don't have a good reference about that, but maybe #musl does
15:55 <skarnet> for the record, I do allocate buffers and large structures on the stack
15:55 <skarnet> but 1. my programs are single-threaded and 2. "large", to me, means 1-2 MB at most
15:55 <skarnet> I think the biggest amount of stack I've ever used was around 800 kB
15:56 <skarnet> big applications with megabytes of data should definitely use the heap
15:58 <fcolista> svn log https://svn.wald.intevation.org/svn/openvas/branches/openvas-libraries-9.0/ -l 1 --diff
16:02 BitL0G1c joined
16:03 <fcolista> i think i need to backport this to 3.5
16:08 <ncopa> fcolista: that was the solution i was hoping for
16:08 <fcolista> good
16:09 <ncopa> good job
16:09 <fcolista> I'm building gsad without the previous patch
16:09 <fcolista> and with the upstream patch applied to openvas-libraries
16:09 <fcolista> let me check if it works
16:10 <ncopa> they should probably check if the malloc succeeded to handle low memory situations
16:11 <ncopa> ah glib handles that
16:13 <fcolista> yup. It worked!
16:13 <fcolista> ah
16:13 <fcolista> no
16:13 <fcolista> it crashes after a while
16:13 <fcolista> :/
16:13 <fcolista> /0\
16:14 <ncopa> they probably allocate more big buffers
16:14 <ncopa> fcolista: can you build with debugging symbols enabled
16:15 <ncopa> and generate a backtrace?
16:15 <fcolista> sure
16:15 <fcolista> but now the issue is different
16:15 <fcolista> [107821.227773] MHD-connection[24436]: segfault at 73bce643aef0 ip 000073bce405dd94 sp 000073bce643aee0 error 6 in libpcre.so.1.2.8[73bce404d000+25a000]
16:15 <fcolista> it crashes on libpcre
16:15 <ncopa> would be nice with a backtrace
16:16 <fcolista> sure
16:16 <fcolista> i need to run now, i'll prepare a clean env tomorrow
16:16 <fcolista> thx!
16:16 <ncopa> ok
16:16 <ncopa> have a ncie evening
16:43 <mitchty> question on test suites, if there are multiple levels of tests, aka a short, medium, and silly long running version, what should go into check()?
16:44 <mitchty> reason I ask is i was adding the ghc testsuite stuff and there is a short test suite good for a run on say travis to stay within its hour timeout, a normal run, which takes about 45 minutes on my skylake box, and a long run, which is still going
16:44 <ncopa> i'd go for shorter test
16:45 <ncopa> if we do sillly long then people will just disable all the testing
16:52 <ncopa> Annapurna Labs Alpine platform (ARCH_ALPINE) [N/y/?] (NEW)
16:52 <ncopa> new kernel config option
16:52 <ncopa> i checked up what it was
16:52 <ncopa> http://www.annapurnalabs.com/
16:52 <ncopa> the logo looks somewhat familiar
16:52 <ncopa> and they apparently have a product line called "alpine"
16:56 <kaniini> humm
16:56 <kaniini> not sure what we should do about that
16:59 <ncopa> i suppose we simply dont support their hardware :)
17:00 <ncopa> seriously, i dont think we care too much
17:10 mikeee_ joined
17:24 <^7heo> I can't believe it...
17:25 <^7heo> it's not possible to use WinSCP to connect to sshd...
17:25 <^7heo> (with sshd from alpine)
17:25 <^7heo> I believe it's a mismatch of security protocols.
17:26 <kaniini> yes, not the same as when some company tried to release "GNOME OS"
17:26 <kaniini> :p
17:29 <^7heo> ?
17:30 <skarnet> ^7heo: I connect WinSCP to dropbear on a regular basis.
17:30 <kaniini> ^7heo: https://arstechnica.com/tech-policy/2014/11/gnome-open-source-project-fights-groupon-over-gnome-trademark/
17:32 <^7heo> skarnet: using openssh here.
17:32 <^7heo> skarnet: it's default in alpine.
17:32 <^7heo> skarnet: can't change it no.
17:32 <^7heo> now*
17:32 <skarnet> I also use WinSCP to connect to openssh's sshd on a regular basis.
17:32 <^7heo> dude, I dunno what's happening.
17:32 <^7heo> I have negative time before deadlines
17:33 <^7heo> I have 100938410985yu105 things on my plate left until tomorrow
17:33 <^7heo> I have NO fucking time to debug any of this.
17:33 <skarnet> yu105 yourself
17:33 <^7heo> yeah I know.
17:33 <^7heo> I don't care actually, sorry.
17:33 <^7heo> I just want this to WORK.
17:33 <^7heo> I didn't expect *ssh* to fuck up.
17:33 <^7heo> first time I have problems ith it.
17:33 <^7heo> with it.
17:33 <^7heo> (unlike my keyboard)
17:34 <^7heo> the real issue is that I don't have any log.
17:34 <^7heo> it just fails.
17:34 <^7heo> and ofc no change in the sshd_config increases the log amount.
17:34 <^7heo> v_v
17:36 <^7heo> ok debug worked.
17:36 <^7heo> skarnet: just one question, are you using windows 10?
17:36 <^7heo> skarnet: or windows 7?
17:38 <^7heo> ok
17:38 <^7heo> auhorized_keys isn't the right name.
17:39 <^7heo> I wasted 1h on a typo.
17:39 <^7heo> as usual.
17:40 <^7heo> Sorry for the noise.
17:46 <^7heo> also, wtfismyip.com \o/
17:46 <algitbot> \o/
17:55 trn joined
18:06 NIN101 joined
18:22 tmh1999 joined
19:19 <scadu> have -devel swapped name with -offtopic last time?
19:19 <TemptorSent> scadu: Quite possible :)
19:22 <TemptorSent> mmlb: Okay fixed the root cause of xtables-addons even getting considered by making the base profile only set the kernel if it's not already set. Now if kernel_flavors isn't empty, it won't overwrite it.
20:04 skarnet joined
20:10 fabled_ joined
20:38 hairyhenderson joined
21:34 m4 joined
21:34 <mosez> clandmeter: new version of gitea released... 1.1.0 8)
21:34 <mosez> https://github.com/go-gitea/gitea/releases/tag/v1.1.0
21:35 <mosez> the pr for the blog post have to be merged, but we got 348 merged pull requests :D
21:38 vakartel joined
21:58 <laskin> Hi. There is a problem with Alpine Wiki: on page https://wiki.alpinelinux.org/wiki/Upgrading_Alpine#Upgrading_Alpine_Linux_on_CD there are code examples that look like 'setup-bootable -u ERROR in latestalp.php: failed to read /var/www/dl-3.alpinelinux.org/htdocs/alpine/.latest.x86_64.txt /media/$LBU_MEDIA'
21:59 <laskin> Does anybody know how to fix it?
22:10 <ashb> laskin: I'm guessing but I think "ERROR in latestalp.php: failed to read /var/www/dl-3.alpinelinux.org/htdocs/alpine/.latest.x86_64.txt" is meant to be a version
22:10 <ashb> so `setup-bootable -u 3.5 /media/$LBU_MEDIA` maybe?
22:13 <ashb> (Or maybe v3.5)
22:19 <mitchty> is there a switch with abuild to make sure it calls the check() function in the apkbuild? i'm currently using abuild -r but don't see a switch that screams i'll run checks as well
22:30 czart joined
22:35 <TemptorSent> Trying to debug cross-arch build of images, but mmlb is reporting a failure by mkinitfs, mostly likely originating from lddtree doing the wrong thing.
22:36 <TemptorSent> Has anyone else run into issues with lddtree resolving libraries when in a foreign arch root?
22:40 <clandmeter> mosez, nice
22:40 <clandmeter> i had the minor update still in by git stashed
22:47 <clandmeter> mosez, looks like govendor is not happy
23:25 <mosez> clandmeter: why govendor? you don't need to execute it. the deps are already bundled.
23:26 <clandmeter> then why provide the vendor file?
23:26 <mosez> https://github.com/go-gitea/gitea/tree/master/vendor everything should be there
23:26 <mosez> because we need to update the deps somehow :)
23:26 <clandmeter> sure, so its broken now
23:27 <clandmeter> i mean even if i dont need it it should work right?
23:29 <clandmeter> would be nice if somebody could fix the makefile to allow setting a version number if building from tarball
23:31 <clandmeter> mosez, I moved it to community now.
23:31 <TemptorSent> Well this is an entertaing rabbit hole -- any sage advice on getting apk to do the right thing when cross-building?
23:32 <mosez> clandmeter: https://cl.ly/3M0F0T1G2U2M builds fine for me on alpine
23:32 <mosez> clandmeter: damn... i forgot the version thing :(
23:33 <clandmeter> mosez, yes it builds fine.
23:34 <clandmeter> its on the repo now
23:34 <mosez> awesome
23:34 <clandmeter> but i had to remove govendor
23:34 <clandmeter> and fix the version patch
23:34 <mosez> you mean the vendor.json file?
23:34 <clandmeter> yes
23:34 <mosez> ok
23:35 <clandmeter> on 1.0.x i could use govendor just fine
23:35 <clandmeter> not sure how you guy's pull in vendor files
23:35 <mosez> but we just updated deps, otherwise there had been no changes to the vendor.json
23:36 <clandmeter> when i find one i usually use it to make sure the deps are uptodate
23:37 <clandmeter> ^7heo, you are now the official maintainer of gitea :p
23:38 <clandmeter> I was too lazy to remove it
23:38 <mosez> i will create an issue for the version
23:38 <clandmeter> mosez, did any of the performance fixes get in?
23:38 <clandmeter> regarind flat repo's in particular
23:39 <clandmeter> regarding...
23:39 <clandmeter> like aports...
23:44 <clandmeter> bedtime, gnite ppl
23:45 <mosez> clandmeter: https://github.com/go-gitea/gitea/issues/1173
23:45 <mosez> clandmeter: i have not checked latest results
23:50 <mosez> migrating linux and aports to try.gitea.io now :)
23:53 <TemptorSent> g'night clandmeter
23:53 minimalism joined