00:05:32 <selsta> .merges
00:05:32 <xmr-pr> Merge queue empty
00:08:41 <selsta> .merge+ 6833 6828 6808
00:08:41 <xmr-pr> Added
00:22:31 <selsta> .merge+ 6822
00:22:31 <xmr-pr> Added
00:50:02 <charuto> what is the proper procedure to add public txos to the blackball set (example in the case of public donations)?
00:50:57 <charuto> also, is there a way to verify that a key image is valid and not falsified?
00:51:59 <needmoney90> ^ valid as in, the key image can be validated as belonging to a particular txo/private viewkey, given only that viewkey and txo/key image
00:53:55 <charuto> yeah thats what i meant
05:11:32 <luigi1111w> selsta done
08:28:51 <hyc> why don't we roll back the gitian builds' OS to an earlier ubuntu release, instead of always updating ubuntu 16?
08:29:33 <hyc> none of the platform libraries are statically linked into our builds anyway, so why do we update them before building?
08:29:48 <hyc> TheCharlatan: ^^
09:19:49 <TheCharlatan> what's the goal of doing that hyc? I don't quite follow what you mean with updating platform libraries before building. AFAICT only gitian-builder does updates, so it's not something we have configured on our end.
11:19:52 <hyc> the goal is avoiding new glibc dependencies
11:22:22 <Guest_80> Has any ETA been announced for triptych/
11:22:27 <Guest_80> ?*
11:31:41 <moneromooo> No.
11:32:01 <Guest_80> Cool thanks
11:34:13 <hyc> has it even been agreed that it's going in?
11:35:01 <moneromooo> No.
11:36:46 <Guest_80> So what's on the schedule after the fork next week?
11:37:48 <moneromooo> None.
11:39:00 <moneromooo> Or, rather, whatever people want to work on.
11:39:13 <moneromooo> Which is not a schedule.
11:40:09 <Guest_80> No kanban board or anything?
11:43:02 <dsc_> Upper management has previously attempted various adaptive, simultaneous workflows, primarily for process improvements, however, these pesky programms have a life of their own.
11:43:17 <dsc_> programmers*
12:30:51 <TheCharlatan> hyc we could go back to an older OS, but then we also have an older toolchain. Either way, requirement changes to libc are usually introduced with new code, not updates in the OS.
12:31:50 <hyc> but if we stick to an old glibc, requirements can't change
12:32:27 <moneromooo> I guess we also get security fixes in any dep we'd link statically.
12:32:34 <hyc> meanwhile, there's no reason we can't self-compile the desired toolchain and just stow them in the repo
12:33:05 <hyc> people need to get out of the mindset that you can only use the version of executables that some distro maker bundled with some package.
12:33:23 <moneromooo> Push a whole OS userland in a repo ?
12:33:31 <hyc> all of our static dependencies are already things that we build ourselves
12:33:37 <hyc> no
12:33:47 <hyc> only push the compiler+linker
12:33:58 <hyc> and only if we actually need a specific newer version
12:36:22 <hyc> as it is we already download an entire Android SDK, entire MacoSX SDK, entire FreeBSD SDK
12:36:49 <hyc> might as well build an entire Linux SDK once and never need to change it again
12:37:27 <hyc> right now our builds are only reproducible if you perform at around th same time as the release was made
12:38:11 <hyc> if enough time has passed, underlying OS updates get pulled in, so what you get later won't necessarily be byte-for-byte identical to when the build was first done
12:38:41 <hyc> we should not be pulling in those OS updats.
12:43:10 <hyc> funny thing is every platform except Linux builds with a frozen SDK
13:32:09 <hyc> so, a slightly simpler approach - download an older glibc, extract to a separate directory tree
13:32:25 <hyc> edit gcc specs file to point to that instead of the default locations
13:32:34 <hyc> no problemo
13:58:46 <hyc> heh. ubuntu 16 used glibc-2.23 so it would still be too new
14:50:17 <hyc> so how far back do we want to support? 2.19? 2.17?
14:58:29 <TheCharlatan> I think before the change that led to the introduction of __signgam, we were down to 2.17
15:00:02 <TheCharlatan> or at least that is what objdump on 0.15 reveals.
15:08:43 <hyc> hm, I can find 2.19 but not 2.17 here http://old-releases.ubuntu.com/ubuntu/pool/main/g/glibc/
15:23:41 <TheCharlatan> doesn't matter. If you select anything below 2.23 we'll use the symbols from <=2.17 again.
15:26:27 <TheCharlatan> The __signgam change was only introduced in 2.23: https://sourceware.org/bugzilla/show_bug.cgi?id=15421
15:27:51 <hyc> I'll try a build with 2.19 then
18:17:04 <hyc> meh. turning 8 debs into a single depends pkg is not straightforward
18:19:21 <hyc> mebbe I should just extract al the debs and then tar the result
18:40:24 <binaryFate> GUI 0.17.0.1 binaries are out on getmonero.org
20:16:08 -xmr-pr- mountassir opened issue #6861: Ledger Nano X wrong device status after upgrading to 0.17.0.1
20:16:09 -xmr-pr- > https://github.com/monero-project/monero/issues/6861
20:39:07 <thomasb06> Hello. Not being a student in computer science, would you have a bit of room for contributing? Maybe with setting the documentation up to date or something simple?
20:44:17 <moneromooo> Sure, there are a number of non coding things one can do.
20:44:34 <moneromooo> Documentation is often a moving target though.
20:45:20 <moneromooo> Maybe you could start by documenting what you had to find out by yourself and wish were docuemnted in the first place.
20:45:22 <thomasb06> moneromooo: hey... well, coding is going to tough for me: I only do fortran on a daily basis
20:45:29 <moneromooo> There are a few guides on getmonero.org already.
20:46:25 <thomasb06> ah, I have an idea then: I had to find by myself that to start mining I had to start monerod first. Maybe I can add this
20:48:32 <thomasb06> first I'll "peel" getmonero.org and if I see a possible improvement I'll submit it
20:49:33 <thomasb06> (peel -> go through)
21:47:26 <TheCharlatan> thomasb06 maybe try following the different compilation and testing tutorials. There always seems to be something to fix in them.