19:04:40 <jelle> #startmeeting
19:04:40 <el_phrik> Meeting started Wed Jan 10 19:04:40 2018 UTC.  The chair is jelle. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:04:40 <el_phrik> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:04:54 <jelle> #topic UTF-8 failures with Python.
19:05:06 * jelle suspects el_phrik can't edit the topic :p
19:05:20 <sangy> yeah, no op :L
19:05:31 <jelle> #topic UTF-8 failures with Python.
19:05:41 <jelle> I hope it sets it back, oh well.
19:05:48 <Foxboron> R.I.P
19:05:49 * sangy keeps a backup of the old topic anyway
19:06:15 <jelle> I guess, I've answered myself here in the topic, we should explicitly set the LANG or wait on glibc to support C.UTF-8
19:07:00 <sangy> should this be done by fixing pacman-reproducible or is this something simpler?
19:07:21 <sangy> also, do we know how long would waiting for glibc take?
19:07:23 <guys> LANG='en_US.UTF-8' python ...
19:07:31 <guys> sangy: we've been waiting years so far
19:07:35 <jelle> sangy: no idea how long that takes ;(
19:07:39 <sangy> oh, that's bad
19:07:52 <sangy> guys: that'd mean we need to change all the PKGBUILDS no?
19:07:52 <anthraxx> o/
19:07:58 * sangy waves at anthraxx
19:08:00 <jelle> and the build env explicitly doesn't set the LANG/LC_ALL
19:08:04 <jelle> sangy: yup
19:08:10 <sangy> oh that sounds painful
19:08:12 <guys> calibre does LANG= possibly because you can actually get weird issues with the locales if you try building without UTF-8 support
19:08:18 <Foxboron> guys will have that done by the end of the week :p
19:08:42 <jelle> sangy: it's not ideal, but it does seem like we have a workaround
19:08:47 <anthraxx> guys: well specifically for arch the devtools sets it anyway, we kind of onyly support that path so we should adopt the way we build?
19:09:00 <sangy> jelle: that's what I was going to say. It doesn't sound like the "clean" solution to me, but what works works
19:09:09 <guys> Yes, if you are building with a non-UTF-8 locale this seems sort of broken anyway.
19:09:39 <anthraxx> imo we should fix it in jenkins repo
19:09:55 <jelle> anthraxx: as in setting the LANG?
19:10:07 <guys> repro builds should require that the repro container, in addition to also setting S_D_E etc. should set the locale to something that is at least UTF-8
19:10:15 <anthraxx> jelle: and generate locale
19:10:20 <jelle> anthraxx: ok
19:10:27 <jelle> currently build two sets fr_CH.UTF-8
19:10:29 <sangy> that also sounds easier to do
19:10:30 <anthraxx> guys: ++
19:10:46 <guys> FWIW, I maintain the glibc-git package in AUR, which explicitly refuses to support non-UTF-8 locales
19:10:51 <anthraxx> it also matches what we expect to be set when using devtools
19:10:56 <sangy> so #action "update the archlinux-repro script to set the locale and LANG"?
19:11:02 <guys> You can get it in my custom repo on pkgbuild.com as well
19:11:24 <anthraxx> and another action to properly set stuff in jenkins repo
19:11:45 <jelle> #action set and generate UTF-8 locale and LANG for build 1 on Jenkins, not equal to the LANG set in build 2
19:11:46 <sangy> anthraxx: ++, although we may want to be more precise than "stuff" :P
19:13:14 <sangy> so, I think this settles the first topic?
19:13:15 <jelle> #agreed set and generate UTF-8 lang in build 1, different from build 2
19:13:24 <jelle> #topic Package disorderfs
19:13:29 <anthraxx> LANG and LC_ALL are not set on one node, but archlinux itself officially only supports devtools builds that set them
19:14:01 <jelle> I think this can be skipped, not important for now
19:14:04 <anthraxx> i see the point of having one unset, but thats just not what we currently support.
19:14:15 <sangy> jelle: i think it wouldn't hurt to have an #action for it too
19:14:23 <jelle> sangy: true!
19:14:31 <jelle> #action package disorderfs in the official repos
19:14:32 <sangy> I think this'll be helpful down the line for our last topic "re: create a public to-do list"
19:14:40 <jelle> yes :)
19:14:49 <jelle> #topic Pacman release
19:15:19 <sangy> here I have no idea what's the status really
19:15:21 <anthraxx> pacman release should come soon :D
19:15:30 <anthraxx> question is if we need something in BUILDINFO before the release
19:15:50 <jelle> Allan mailed about the road to 5.1, if we need to change something about the BUILDINFO file we should discuss it now.
19:15:55 <jelle> https://www.mail-archive.com/pacman-dev@archlinux.org/msg15970.html
19:15:56 <el_phrik> Title: [pacman-dev] Road to 5.1 (at www.mail-archive.com)
19:16:26 <sangy> we were talking yesterday about including CFLAGS and LDFLAGS
19:16:33 <jelle> just wanted to bring that up :-)
19:16:34 <sangy> I'm starting to think it's not such a good idea
19:16:58 <anthraxx> sangy: why not?
19:17:28 <sangy> anthraxx: well, from what was brought up yesterday, these flags should be in the makepkg.conf or probably set on the PKGBUILD if needed to be overridden no?
19:18:10 <anthraxx> sangy: the point is, if something is changed in makepkg.conf you will never ever know
19:18:39 <sangy> ah, I see what you mean. In case the canonical makepkg.conf is changed
19:18:42 <anthraxx> if one packages needs something, that should obviously be done in the PKGBUILD
19:18:54 <sangy> that should trigger a rebuild though? I'm not too familiar with that process, so I may be wrongf
19:19:39 <sangy> also, in that case, we may also want to dig into which other values are of interest to "preserve" from the makepkg.conf that build that package right?
19:19:45 <guys> if the package itself needs different flags, the PKGBUILD must override it explicitly and reubild the package with a new pkgrel
19:20:15 <guys> If we want to record the distro flags, the question is, is devtools itself enough for this?
19:20:59 <anthraxx> the adventage is we can easily observe what FLAGS were used to build a package and also detect if people have something lese
19:21:23 <anthraxx> there are maintainers not using devtools but own makechrootpkg stuff and who knows if they merke makepkg.conf correctly when changes happen
19:21:52 <sangy> I can see how it'd be helpful to have something akin to a namcap for BUILDINFO auditing
19:22:01 <sangy> with that info in there that is
19:22:24 <anthraxx> also, striltly speaking for pacman, it should be able to rerpoduce without arch linux specific makepkg.conf knowledge so having FLAGS you can set in makepkg.conf would be a good thing to put into that
19:22:37 <guys> Sure, makes sense.
19:22:57 <jelle> anthraxx: but if we record modified CFLAGS from a PKGBUILD, so we can't verify if the original makepkg.conf was correct
19:23:01 <guys> I just want to state for the record, putting `env` in .BUILDINFO is madness and I won't be having with it.
19:23:12 <anthraxx> jelle: we record makepkg.conf not PKGBUILD overrides in build()
19:23:21 <jelle> anthraxx: ok
19:23:26 <guys> specific flags environment variables I can hear recording.
19:23:35 <sangy> guys: you mean the whole env?
19:23:46 <sangy> yeah that's ridiculous and probably a privacy nightmare
19:23:56 <guys> sangy: precisely, the whole env is not makepkg's job
19:24:06 <anthraxx> guys: i think FLAGS are fine
19:24:09 <anthraxx> guys: ++
19:24:16 <guys> if a package scrapes weird variables from env, this is not our fault.
19:24:21 <jelle> I can't see anything useful in env
19:24:22 <guys> (and should be fixed)
19:24:23 <sangy> I'm looking at the makepkg.conf manpage though, I can see how other info can be taken in as well
19:24:40 <jelle> and the things I see in env, if they are set to different things... then that's a bug
19:24:49 <guys> jelle, anthraxx: someone definitely proposed recording all of `env`, so I wanted to state it for the record
19:24:49 <sangy> e.g., MAKEFLAGS, STRIP_*, etc.
19:24:55 <jelle> guys: np
19:25:27 <anthraxx> guys: i see. for me im just interested in MAKEFLAGS, C{PP}FLAGS LDFLAGS DEBUGFLAGS and stuff
19:25:29 <sangy> we should probably list/review them all
19:25:50 <sangy> I can probably make a listing of them on a hackmd and we vote them in-out. Would that make sense to all?
19:26:28 <jelle> #action review which MAKEFLAGS, C{PP}FLAGS LDFLAGS DEBUGFLAGS and stuff should be in the BUILDINFO file
19:27:36 <anthraxx> ^^ we should hurry before the release is done :D
19:27:43 <jelle> yup
19:28:01 <sangy> I'll get at this today, and ping everyone for voting/discussion asap
19:28:06 <jelle> awesome
19:28:46 <Foxboron> We could tell Allan to wait for this :p
19:28:58 <Foxboron> But i guess the release wont be made this week
19:29:00 <jelle> then he'll demand bourbon!
19:29:04 <anthraxx> yeah
19:29:06 <sangy> lol
19:29:13 <jelle> #topic Reproducible build script progress
19:29:31 <jelle> sooner would be better then later yeah
19:29:35 <anthraxx> ^ we should start the ALA implementation stuff
19:29:41 <sangy> ALA?
19:29:45 <Foxboron> Archive
19:29:45 <anthraxx> arch linux archive
19:29:48 <jelle> anthraxx: that's the next topic ;-)
19:29:49 <sangy> oh I see
19:29:59 <sangy> jelle helped me dig up what I had on my coreos machine
19:30:05 <anthraxx> jelle: but its "Reproducible build script progress" ;)
19:30:13 <sangy> oh right
19:30:15 <sangy> soz, I rushed
19:30:21 <jelle> anthraxx: yeah this is purely about what the script should be
19:30:31 <anthraxx> it should pull ALA :P
19:30:57 <Foxboron> Sure, but the outline for the scripts/feature ideas paves the way for what we need from the ALA
19:31:14 <anthraxx> what i find *expremely* important is that the stanard user faced reproducible script should be kept as simple as possible without overengineering it into a monster
19:31:36 <jelle> I've toyed around a bit at CCC and first pulled the repo from $builddate and created a chroot. But this might cause issues for mismatching package versions
19:31:38 <anthraxx> the background: it should be easily understandable and reviewable without needting to read weeks of source code
19:31:54 <jelle> anthraxx: I want to stub out a specification
19:32:15 <jelle> I mean, should it take a "packagename" or a .pkg.tar.xz?
19:32:40 <sangy> as a random thought to throw in there, I think we shouldn't have it depend on systemd like the current *-makepkg scripts
19:32:50 <Foxboron> What i have is something mirroring (read reimplements) devtools and tests packages. It currently works quite well except for misc config and packaging stuff
19:33:08 <jelle> Foxboron: hmm but your tool builds twice
19:33:16 <Foxboron> yeah i'm aware :D
19:33:18 <anthraxx> sangy: nspawn is neat why not?
19:33:32 <Foxboron> sangy: i don't see the harm is nspawn tbh. What would the other option be?
19:33:34 <jelle> I believe this script is Arch specific, so we can depend on any arch package we want
19:33:42 <anthraxx> jelle: good question, we need to define where and how PKGBUILD comes from (especially at correct version)
19:33:58 <anthraxx> and passing either a .tar.gz.xz or directly a plain .BUILDINFO should be an option
19:33:59 <jelle> anthraxx: I want to make a list of pitfalls yeah
19:34:10 <sangy> Foxboron, anthraxx: well, I don't know how friendly it is with other containerization solutions
19:34:13 <anthraxx> jelle: arch-chroot is arch specific wrapper, systemd-nspawn is not
19:34:19 <jelle> with a specification, we prboably make a better implementation :)
19:34:40 <jelle> anthraxx: I've used mkarchchroot
19:34:46 <Foxboron> I'd like a specification and work on whatever people agree on is a better solution tbh :D
19:35:01 <Foxboron> sangy: umm, im unsure? I don't see any problems to be honest
19:35:08 <jelle> It's a bit of a bummer that we don't install BUILDINFO files
19:35:16 <anthraxx> jelle: we need a custom thingie anyway for ALA setup
19:35:31 <jelle> anthraxx: yup, but this deals with installing a build user and such
19:35:34 <sangy> Foxboron: the reason I started work with reprotest was that using the x-buildpkg scripts wouldn't work on my coreos machine
19:35:56 <guys> I think it is reasonable to have people reproduce Arch packages on, say, a Debian machine running an Arch nspawn container...
19:35:59 <sangy> (or any other containerd provisioning)
19:36:19 <jelle> guys: but then you need pacman
19:36:22 <guys> If we want our reference implementation to be *systemd* specific, then okay
19:36:23 <anthraxx> jelle: why that? if you want to test a package you want to test it before installing.... if the reason to do so is to ensure its not backdoored :P
19:36:37 <jelle> anthraxx: ok, so we take an .pkg.tar.xz
19:36:46 <anthraxx> jelle: you need pacman anyway inside the container
19:36:50 <Foxboron> guys: yes, thats sorta why i started bootstrapping with the bootstrap image instead of using pacstrap
19:36:52 <guys> jelle: not really, you can nspawn and explicitly install a list of package files from within the container.
19:36:58 <anthraxx> jelle: or .BUILDINFO, both should work
19:37:07 <anthraxx> Foxboron: ++
19:37:09 <jelle> anthraxx: hmm I don't see the .BUILDINFO case
19:37:35 <sangy> jelle: it does make sense to me, the .BUILDINFO already contains packages and versions to install into the target
19:37:38 <jelle> guess it makes testing easier
19:37:42 <anthraxx> jelle: why should i need a whole tarball if i cann pass a .BUILDINFO? we extract that anyway from the tar.gz.xz why not have a way to pass it directly
19:37:50 <anthraxx> jelle: we may want to publish it somewhere to download
19:38:00 <jelle> anthraxx: oh archweb comes to mind
19:38:09 <jelle> ko
19:38:09 <anthraxx> jelle: the .tar.gz.xz is literally just to get the .BUILDINFO out of it
19:38:15 <jelle> anthraxx: true
19:38:24 <sangy> anthraxx: well, you also want to check that it matches :P
19:38:31 <jelle> we have to deal with two formats of the BUILDINFO btw
19:38:37 <anthraxx> sangy: true
19:38:46 <sangy> jelle: which are?
19:38:57 <anthraxx> jelle: we don't care for format zero :P
19:39:00 <jelle> sangy: the one we currently have and the one in pacman-git
19:39:11 <sangy> anthraxx: ++
19:39:17 <jelle> anthraxx: then we need a lot of rebuilding
19:39:31 <anthraxx> jelle: we need that anyway the old one lacks needed info
19:39:41 <jelle> anthraxx: hmm such as?
19:39:46 <guys> jelle: the one we currently have is unsustainable, as it is created by a nondeterministic packaging process altogether.
19:39:55 <sangy> jelle: e.g., the vars we discussed in topic--
19:40:12 <guys> we have *lots* of repro issues with packages that are built with the stable version
19:40:16 <anthraxx> jelle: everything, version, packager and such. you can support by also reading .PKGINFO however
19:40:31 <jelle> anthraxx: that's what I did indeed
19:40:51 <jelle> ok, let's develop on the format in pacman-git then
19:40:58 <anthraxx> not saying we must not, just saying lets focus on getting one format done :P
19:41:02 <jelle> yes
19:41:07 <jelle> well that is the one we should aim for
19:41:07 <sangy> that's also true, baby steps!
19:42:26 <sangy> hmm, so I guess #action -> work on a specification for the reproducible script for arch?
19:42:31 <jelle> step 2, extract pkgbuild_sha256sum and somehow find the correct PKGBUILD
19:42:50 <sangy> oh, or let's make it more granular :P
19:42:58 <jelle> this might be tricky, but asp can checkout the arch dir
19:43:08 <anthraxx> jelle: using /repo/ instead of /trunk makes it much easier
19:43:14 <jelle> anthraxx: yes
19:43:30 <jelle> anthraxx: but, does asp handle testing/extra packages
19:43:49 <anthraxx> no clue of it can pull testing
19:44:11 <guys> sure, asp export testing/pkgname
19:44:37 <jelle> guys: hmm but we don't know if a package is in testing from the BUILDINFO
19:45:01 <guys> That is true, but I only answered the question "does asp handle it"
19:45:07 <jelle> [jelle@lithium][/tmp/intel-ucode/repos]%ls
19:45:08 <jelle> extra-any/  testing-any/
19:45:17 <jelle> that's asp -a x86_64 checkout intel-ucode
19:45:20 <jelle> not sure if the -a matters
19:45:22 <guys> and asp checkout gets you the whole tree anywya
19:45:49 <jelle> zomg
19:45:51 <jelle> list-repos         NAME...     List repos for packages
19:46:05 <jelle> hmm then you still miss the version
19:46:13 <anthraxx> well not only we need to decide if testing/extra but we also want previous versions
19:46:18 <anthraxx> jelle: ++
19:46:35 <jelle> anthraxx: wonder if we need the arch in the BUILDINFO file
19:46:35 <sangy> I recall guys brought up a waay to get the version from the git log ors omething similar?
19:46:37 <jelle> as in any/x86_64
19:46:47 <guys> I don't know that that is solvable without getting git-based dbscripts
19:46:52 <guys> With git tags for versions.
19:47:10 <guys> You can always grep the difflog for pkgver=
19:47:10 <sangy> guys: it would make a lot of sense to have tags -> versions on the git side
19:47:37 <guys> sangy: currently we only have svntogit on auto-export mode.
19:47:47 <jelle> hmmm, asp knows the arch of a package
19:48:12 <anthraxx> jelle: hm not for now, but maybe future?
19:48:23 <jelle> anthraxx: I mean to determine if it's any/x86_64
19:48:28 <jelle> anthraxx: but we can also get that from asp
19:49:07 <jelle> anthraxx: I would want to reproduce only versions in our repository btw
19:49:08 <anthraxx> we should package in git -,-
19:49:13 <jelle> not older versions
19:49:20 <anthraxx> je must support older versions
19:49:34 <jelle> anthraxx: why?
19:50:10 <jelle> because people might have outdated machines?
19:50:19 <anthraxx> well at one point ALA will get cleaned anyway but we should try to do it
19:50:42 <anthraxx> jelle: you want to proof/disproof things, its mostly just about getting the PKGBUILD and call it a day
19:50:50 <sangy> anthraxx: we should package in git agreed, but oh well
19:50:53 <jelle> anthraxx: hmmm
19:51:10 <anthraxx> jelle: it may fail anyway if ALA gets cleaned at one point but i see no reason to explicitly deny trying to reproduce an older one
19:51:35 <anthraxx> jelle: ok %s/must/should/could/
19:51:57 <guys> Maybe repro builds should not hardcode the method of acquiring a PKGBUILD. :p
19:52:22 <guys> How can I reproduce my-terrible-package from the AUR if you hardcode that?
19:52:24 <anthraxx> yeah --pkgbuild= would be cool
19:53:01 <jelle> guys: ok, so overriding with --pkgbuild=?
19:53:17 <guys> It should take a PKGBUILD and a pkg.* and have a wrapper script for scraping PKGBUILD versions from asp
19:53:29 <anthraxx> jelle: f.e. you may want to check some thing. f.e. someone backdoors a package, rolls it out, let a victim upate it and the releases a non-backdoored version. nobody will noticed
19:53:32 <guys> Or --pkgbuild= I guess
19:53:37 <jelle> hmmm
19:53:38 <anthraxx> jelle: we may want to be able to prove that
19:54:18 <guys> But I feel the "convenience" aspect of grabbing the PKGBUILD should not be our primary concern...
19:54:28 <jelle> I d
19:54:30 <jelle> *I do
19:54:55 <guys> packages should be reproducible with two ingredients: 1) the build recipe, 2) the built package you are reproducing against.
19:54:56 <jelle> I should be able to arch-repro-test *.pkg.tar.xz => yes you are lucky || no you are screwed
19:55:28 <guys> extra-repro-test should be a wrapper around arch-repro-test and asp
19:55:36 <guys> :p
19:56:01 <jelle> maybe
19:56:02 <anthraxx> something like that
19:56:06 <Foxboron> more devtools reimplementation you say :D?
19:56:14 <jelle> ok, next hurdle
19:56:14 <anthraxx> sure :P
19:56:17 <sangy> that'd be nice. But we can probably put that into a spec to triage our goals?
19:56:31 <jelle> sangy: uhu
19:56:53 <Foxboron> jelle: will you make a document or somewhere to write the specc?
19:57:15 <jelle> Foxboron: uhh by all means make an RFC :)
19:58:17 <jelle> anyone wants to add something to this topic?
19:58:35 <sangy> I think that's it for me
19:58:38 <jelle> ok
19:58:44 <anthraxx> me2
19:58:49 <jelle> Foxboron: I have some notes about caveats, that can come later
19:59:02 <guys> seems reasonable
19:59:12 <jelle> #topic Arch Linux Archive: Don't remove packages mentioned in BUILDINFO file
19:59:24 <Foxboron> jelle: sure :)
19:59:33 <jelle> sangy has been awesome and wrote a small script, turns out we don't remove the archived packages yet!
19:59:43 <sangy> :D
19:59:51 <anthraxx> which is good :P
20:00:05 <anthraxx> but we should still bring such a script into existence
20:00:17 <anthraxx> i mean, finalize it and give devops a way to access it
20:00:21 <jelle> so it seems we can just start writing an archive removal script with BUILDINFO in mind and an $ARCHIVE_DATE
20:00:23 <jelle> anthraxx: yes
20:00:26 <dmc> yay I missed it
20:00:32 <jelle> dmc: still in progress :p
20:00:48 <dmc> seems about done
20:00:55 <dmc> am I wrong?
20:01:00 <jelle> anthraxx: I'm collecting information about how the current archive script works
20:01:01 <jelle> dmc: yes
20:01:02 <anthraxx> dmc: nearly
20:01:21 <dmc> !check if jelle just likes to say the opposite of whatever I do
20:01:22 <phrik> Testing if jelle just likes to say the opposite of whatever I do: [PANIC]
20:01:39 <dmc> should've tried el_phrik
20:01:45 <jelle> I guess sangy and I will pick this up, we need to discuss with devops/arch-dev how long we want to keep archive packages
20:01:56 <sangy> lol
20:02:02 <jelle> currently we are almost running out of disk space and a month seems to be something along 80-160 GB
20:02:03 <anthraxx> !check if we are awesome
20:02:04 <phrik> Testing if we are awesome: [PASS]
20:02:14 <sangy> jelle: yes, I think we need to merge this script with the current archive infrastructure, which I didn't know already existed
20:02:22 <jelle> :D
20:02:39 <anthraxx> jelle: i only care we never ever remove anything referenced by up-to-date BUILDINFO files :PO
20:02:42 <jelle> sangy: that's here https://git.archlinux.org/users/seblu/archivetools.git/
20:02:45 <el_phrik> Title: users/seblu/archivetools.git - Arch Linux Archive Tools (at git.archlinux.org)
20:02:45 <anthraxx> everything else is just a matter of space
20:02:49 <jelle> anthraxx: of course
20:03:26 <jelle> well that was short :)
20:03:52 <jelle> #topic Killed builds
20:04:05 <guys> Do we have to archive things referenced by old versions that we keep because *they* are referenced?
20:04:17 <jelle> guys: we never remove anything now
20:04:45 <guys> I mean, once we start deleting things. ;)
20:05:05 <jelle> guys: that's a concern for the repos I guess
20:05:24 <jelle> as in https://archive.archlinux.org/repos/2017/05/12/
20:05:26 <el_phrik> Title: Index of /repos/2017/05/12/ (at archive.archlinux.org)
20:05:30 <jelle> those shouldn't break yeah
20:05:55 <guys> From a reproducibility perspective, do we care about reproducing every package still available, recursively?
20:05:59 <guys> Or just the latest?
20:06:10 <sangy> that's a damn good question
20:06:21 <sangy> right now my script doesn't do it recursively
20:06:25 <guys> If we reproduce x version 1, using y version 2 (old), do we want to reproduce y version 2 as well?
20:06:25 <Foxboron> One step at a time?
20:06:49 * jelle imagines an exploding tree
20:06:53 <sangy> I think for now let's do just the first layer. Later down the line we can either skip that by having attestations of reproducibility
20:06:58 <sangy> hmm, for context
20:07:13 * guys attests sangy is reproducible
20:07:14 <sangy> this is a scan that I did a couple of weeks ag ohttps://ptpb.pw/vkCg
20:07:29 <jelle> ah
20:07:31 <sangy> just with the like 20 versions of the keyring I'm :S
20:07:41 <guys> heh
20:07:59 <jelle> you can't read this, but we have packages still build in 2013 in the repos
20:08:04 <jelle> s/read/view/
20:08:12 <jelle> https://www.archlinux.org/packages/community/x86_64/lockfile-progs/
20:08:14 <el_phrik> Title: Arch Linux - lockfile-progs 0.1.17-1 (x86_64) (at www.archlinux.org)
20:08:33 <guys> https://www.archlinux.org/packages/?sort=last_update
20:08:35 <el_phrik> Title: Arch Linux - Package Search (at www.archlinux.org)
20:08:36 * guys views it
20:08:54 <guys> liblqr 0.4.2-1 is slightly older
20:08:59 <anthraxx> guys: ++ that once day we reproduce recursively
20:09:03 <jelle> guys: I was looking at https://www.archlinux.org/devel/reports/old/
20:09:05 <el_phrik> Title: Arch Linux - Developer Login (at www.archlinux.org)
20:09:37 <jelle> all these packages have no pie no nada
20:09:44 <jelle> makes me sad
20:09:49 <anthraxx> we need a TODO list for those anyway
20:09:54 <anthraxx> PIE, RELRO
20:09:55 <sangy> anthraxx: although I agree. I think it's also a good idea to later down the line have something like distributed reproducers that we can trust. That's a topic for another meeting though
20:10:01 <guys> I thought we already went and rebuilt things for PIE
20:10:06 <jelle> guys: nope
20:10:09 <sangy> spring cleaning!
20:10:10 <jelle> lua51-expat
20:10:28 <guys> Well, we can wait to rebuild those, for pacman 5.1 and nail two birds with one stone.
20:10:39 * guys volunteers
20:10:54 * jelle orders guys tissues
20:11:14 <jelle> ok
20:11:19 <guys> Wait, we had a topic!
20:11:20 <anthraxx> and we need to bake brtln not implement https://bugs.archlinux.org/task/56856 otherwise the whole chain is borked if we loose the posibillity to reproduce gcc
20:11:23 <guys> killed builds
20:11:23 <el_phrik> Title: FS#56856 : [gcc] Bootstrap using profile-guided optimization (at bugs.archlinux.org)
20:11:38 <jelle> anyone has input killed builds?
20:11:48 <guys> I dunno, what is killing them?
20:11:48 <jelle> how can I repro that locally, stupid question :D
20:12:00 <brtln> don't bake me plz
20:12:03 <brtln> I'll do what you want
20:12:04 <jelle> as I am not sure how I can repro the jenkins env easily
20:12:07 <anthraxx> brtln: :D
20:12:10 <guys> brtln: :p
20:12:13 <jelle> anthraxx: just take his vodka
20:12:18 * Foxboron bakes brtln
20:12:29 <sangy> lol
20:12:37 <sangy> Foxboron: you had one job! now repro is dead!
20:12:45 <anthraxx> brtln: how can we pay you... bourbon too? :P
20:12:46 <jelle> ah PGO
20:13:02 * sangy has no idea abouut this topic
20:13:31 <jelle> sangy: for example syslinux/gnutls/ltrace where blacklisted
20:13:34 <anthraxx> bourbon, the universal currency for arch devs
20:13:52 <jelle> sangy: the jenkins job kills builds after $x hours
20:13:56 <anthraxx> jelle: they were hanging
20:14:18 <anthraxx> literally hanging without progress
20:14:20 <sangy> hmm... interesting
20:14:25 <anthraxx> we need to investigate the reason
20:14:27 <jelle> anthraxx: that's weird, gnutls build fine
20:14:35 <anthraxx> jelle: all of them buld fine locally
20:14:56 <sangy> I wonder if there's a way to ssh into the build machine while it's building. We should ask h01ger
20:14:58 <jelle> anthraxx: maybe the log isn't correct on https://tests.reproducible-builds.org/archlinux/archlinux.html
20:15:00 <el_phrik> Title: Reproducible Arch Linux ?! (at tests.reproducible-builds.org)
20:15:09 <jelle> sangy: I'd rather do that locally
20:15:20 <anthraxx> sangy: maybe if we send h01ger bourbon too :P
20:15:35 <jelle> lolwat
20:15:37 <jelle> muse-autoloads.el has changed since visited or saved.  Save anyway? (yes or no) E...lisp/muse-autoloads.el locked by jenkins@profi... (pid 50002): (s, q, p, ?)? rror reading from stdin
20:15:52 <anthraxx> hmmm
20:15:54 <sangy> ah, so it needs an interactive frontend
20:15:57 <jelle> anthraxx: ok I'll make a list of "easy-hacks" :P
20:16:17 <anthraxx> just redirect /dev/niull or yes to it :D
20:16:27 <jelle> #topic SSL verification issues
20:16:30 <sangy> does pacman have anything akin to DEBIAN_FRONTEND=noninteractive ?
20:16:46 <guys> sangy: no
20:16:52 <guys> We assume people aren't insane
20:16:53 <anthraxx> we need to reschedule everything dpownload failed before 03.01.
20:17:10 <anthraxx> hg svn and stuff is left
20:17:18 <jelle> anthraxx: yup I believe that's the case
20:17:23 <anthraxx> we have like 30 failed packages that should be fine now
20:17:38 <jelle> should that should just be a todo, disable SSL verification for SVN/HG in jenkins
20:17:50 <guys> operating a few weeks into the future should be more than enough IMO for reproducible smoketesting.
20:17:58 <guys> We don't need years.
20:18:16 <jelle> #action disable ssl verification for HG/SVN downloads in the jenkins script
20:18:28 <jelle> guys: well a cert can expire next week
20:18:35 <guys> Question is, how do we disable SSL verification in HG/SVN?
20:18:44 <jelle> that's an action point!
20:18:48 <guys> Do they have OS-global configurations?
20:19:11 <guys> We certainly don't implement VCS configurations in makepkg, despite IIRC requests
20:19:20 <jelle> ah
20:20:17 <jelle> guys: I'll just make this an action point, since timeboxing the meeting to an hour would be good
20:20:26 <jelle> #topic Create a public to-do list
20:20:54 <anthraxx> guys: no sometimes its years only that are in something
20:20:56 <sangy> well, that last one can be pre-populated with our #actions, and then there's that?
20:21:01 <anthraxx> guys: just properly disable SSL verification
20:21:04 <sangy> we should start a wiki page
20:21:05 <brtl_n> if we're talking about public todo lists, it would be nice to finally use our kanboard for things like this
20:21:11 <guys> https://bugs.archlinux.org/task/37743
20:21:13 <el_phrik> Title: FS#37743 : makepkg does not use SVN proxy configuration (at bugs.archlinux.org)
20:21:24 <anthraxx> brtln: how do we can access to it?
20:21:27 <jelle> I've had one user ask, how he could be of help, we should accept more help, how do we guide people :)
20:21:40 <brtl_n> most likely devops team need to create account for each of you
20:22:07 <anthraxx> brtln: awesome <3
20:22:11 <sangy> brtl_n: kanboard would be awesome
20:22:12 <Foxboron> Ah yeah, i was actually going to suggest using the kanban board :D
20:22:17 <guys> Hmm, this bug seems totally different in a way :p
20:22:39 <jelle> hmmm not sure yet about kanban
20:22:54 * Foxboron throws agile towards jelle
20:23:02 * jelle burns agile
20:23:08 <anthraxx> jelle: yes, but its hard.. we need a list of stuff that that people could possibly pick up
20:23:08 * guys agilely dodges
20:23:09 <brtl_n> well, kanban doesn't inply kanboard
20:23:17 <jelle> anthraxx: indeed
20:23:19 <brtl_n> it's just easier to grasp what's going on
20:23:39 <jelle> anthraxx: I think we need to have a page on our wiki about reprodicuble builds the concepts and how that ties into Arch
20:23:44 <jelle> *reproducible
20:23:48 <brtl_n> especially if someone like me don't want to get involved too much but also want to complain about irrelevant things
20:24:00 <jelle> hehe
20:24:38 <jelle> anthraxx: I mean we can point people to reproducible issues, but how do they reproduce them ;-)
20:24:44 <brtl_n> if all people who want to have account on our kanboard instance have their gpg keyids filled in archweb, I will just proceed tomorrow and make accounts for everyone
20:25:28 <brtl_n> if someone doesn't have archweb account, please send me on query your preferred login, email and keyid so I can send you encrypted initial password
20:26:03 <anthraxx> jelle: well they can help fixing the issues on the repro site :P
20:26:15 <jelle> anthraxx: hmm yeah
20:26:17 <anthraxx> jelle: simle 5-steps howto should be sufficient
20:26:47 <sangy> brtl_n: that's the fingerprint field on the /profile page right?
20:26:59 <jelle> we should be able to reference/retrieve a lot of information on reproduciblebuilds.org
20:27:24 <brtl_n> yes, fingerprint field is fine
20:28:40 <brtl_n> nothing more about public to-do, right?
20:28:58 <brtl_n> let's move on then, if there's anything left on the agenda…
20:29:05 <jelle> that was all
20:29:14 <jelle> well yeah someone has to write wiki pages
20:30:26 <jelle> #action add meetbot plugin to phrik
20:30:29 <jelle> #endmeeting