15:00:04 #startmeeting rb-general 15:00:04 Meeting started Tue Jul 27 15:00:04 2021 UTC. The chair is h01ger. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:04 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:00:10 \o/ 15:00:26 welcome to this monthly meeting, please briefly introduce yourself or briefly update us on recent or planned projects 15:00:58 * h01ger = Holger Levsen, juggling jenkins/tests.r-b.o things as usual :) 15:01:19 o/ 15:01:20 Hi, I'm Roland Clobus, a Debian Contributor. I'm working on reproducible Debian live images 15:01:21 the full agenda for today is at https://pad.riseup.net/p/rb-irc-meetings-keep 15:01:25 * obfusk = Felix C. Stegerman | F-Droid core contributor | Debian & nixpkgs maintainer | Python/Haskell/web dev | they/them 15:01:56 the meetings are supposed to last between 1-2h, maybe rather an hour, but we have lots of time (just after 23-42m on one topic we move on anyway), though of course we aim to keep them short. the meetings are logged via https://meetbot.debian.net/reproducible-builds 15:02:14 #info anyone can leave information in the meetbot log like this 15:02:15 o/ Arnout Engelen, Scala/JVM, Nix, pretty busy so no 'current projects' tbqh ;) 15:02:17 * lamby Chris Lamb, playing around with quite a few things but often returning to diffoscope and patching various parts of Debian. 15:02:31 * kpcyrd = kpcyrd | rebuilderd developer/maintainer | Reproducible Arch Linux and Alpine 15:02:31 sangy = Santiago Torres-Arias | in-toto lead | Arch Security Person | Professor @ Purdue University | He/Him 15:03:48 Nice to see you all. 15:04:10 * fepitre , Frédéric Pierret, Qubes OS project 15:04:55 * marmarek = Marek Marczykowski-Górecki, Qubes OS too 15:05:00 hello everyone. i'll wait 2-3 more minutes for people to introduce themselves and then we'll move on 15:05:21 * tobiaswiese student, currently mainly occupied with my exams 15:06:00 * bmwiedemann Bernhard M. Wiedemann, doing r-b fixes for openSUSE / SUSE 15:07:45 wheeehooo - glad to see so many nice folks around! 15:07:57 * vagrantc waves 15:07:57 hi 15:08:04 hey Ariadne 15:08:44 o/ 15:08:48 let's go 15:08:50 #topic short time slot for checkins from various projects: Debian: snapshot.d.o mirror status update (fepitre) 15:09:26 ok so I've added to snapshot api service a better to localize where is a package 15:09:36 https://github.com/fepitre/debian-snapshot#api-examples 15:09:59 you can better obtain info of which archive, suite, timestamp, component a package is 15:10:22 nice 15:10:23 this is still not finished because I'm not totally happy of how data are presented right now but any collaboration on that is welcomed 15:10:51 fepitre: care to elaborate on what makes you unhappy about the data presented? 15:11:07 I would certainly try to simply json output 15:11:18 fepitre: can one simply replace snapshot.d.o URLs with your service? 15:11:19 on the same way I'm storing data in DB 15:11:36 archive-suite-component (list of range of timestamps) 15:12:06 the goal is to be able to implement metasnap feature of common timestamp for a buildinfo 15:12:14 ah 15:12:29 also to replace metasnap? 15:12:31 yes 15:12:40 (metasnap.debian.net) 15:12:41 cool 15:12:57 so right now it took weeks to provision a new DB to register every location that a package has seen 15:13:06 fepitre: to make sure I understand. It seems there's a lot of duplication within the fileinfo object (i.e., there's a bunch of date ranges and a bunch of repeated data) is that right? 15:13:14 fepitre: do you store a full copy of everything on your snapshot service or just an index? :) 15:13:17 sangy, yes 15:13:19 e.g. feed it a .buildinfo and it gives you the timestamp for the repository to use? 15:13:22 next topic? (aiming for short slots like 5min or so - we can always make this a bigger topic if needed though) 15:13:39 (happy to last this some more minutes though) 15:13:44 because a package for a given archive has "hole" in its history on snapshot, this is what josch highlighted 15:13:57 fepitre: Got it. Just wanted to make sure I followed 15:14:14 I can definitely take a look at this async. Happy to move on :) 15:14:19 (asking to get an idea on disk requirements) :) 15:14:24 kpcyrd, I store everything yes 15:14:38 another topic: ismypackagereproducibleyet.org still looking for more data sources next to Debian, Arch, openSUSE 15:14:42 data + a DB with enough info to provide an usuable API 15:14:59 bmwiedemann: please add it to the pad 15:15:41 vagrantc, yes 15:15:56 kpcyrd: disk requirements were explained in the last meeting, you could check the log. something like 4tb atm.. 15:16:05 ok, thanks 15:16:09 shall we move on? 15:16:14 yep, another arches are coming. Done :) 15:16:20 fepitre: are you ok with people using your service? :) 15:16:23 like, public use 15:16:33 kpcyrd: yes 15:16:42 ok cool 15:16:43 there will be a better connected mirror, but yes 15:17:04 #topic short time slot for checkins from various projects: Debian: rebuilder status update (h01ger) 15:17:32 not too much has happened, https://pad.riseup.net/p/rebuilders%2Borchestration-tools got some updates after our last meetings 15:17:51 but hasnt been put on the website yet (to be discussed later) 15:18:26 one thing has happened though: i concluded to setup *both* rebuilderd implementations, the one from fepitre and the one from kpcyrd 15:18:41 and then we can see which we like better and if they produce the same results :) 15:19:06 h01ger, yes also I would love to have python-debian 1.40 in bullseye 15:19:06 note that rebuilderd is just a scheduler :) 15:19:23 I've actually been meaning to bring up that there's a possibility to loop in the folks from tekton to have another scheduler 15:19:24 i'll certainly ask for help / document what i'm doing on #debian-reproducible... 15:19:43 sangy: yes likely 15:19:56 fepitre: i think that ship has sailed. in bullseye-backports hopefully possible though 15:20:03 as package-rebuilder uses debrebuild, I would love to have some debrebuild release compatible with bullseye 15:20:11 I can't believe how cheap a 4TB HDD is these days... :o 15:20:12 * h01ger done with updates on this topic.. 15:20:39 sangy: whats tekton? 15:20:49 h01ger: tekton is a pipeline manager that works on top of kubernetes 15:21:12 * h01ger just ordered a external 4tb usb disc for 90€ (for a friends backup purposes, rb unrelated) 15:21:15 it's v. extensible, so you can basically arrange it to build a rebuilder scheduler (that also manages the workloads) 15:21:18 lamby: 12TB HDD for 280 EUR 15:21:51 I'm wondering if it'd make sense to rename one of the debrebuild's, we've had multiple srebuild in the past and that was confusing as well :) 15:21:53 h01ger: not trying to go against any of the things that exist though. I love fepitre's and kpcyrd's work 15:22:03 kpcyrd: +1 15:22:36 sangy, yes in fact I've used a very common orchestrator framework in python (celery) to have a standalone software doing all at once 15:22:36 kpcyrd: YES (renaming) 15:22:43 i was originally planning to use tekton for alpine reproducibility testing, but … actually i’ll elaborate later :) 15:22:53 any other suggestion or workflow can be done 15:22:54 bmwiedemann: madness! 15:22:57 shall we move on? 15:23:10 please :) 15:23:32 (this is not the right topic to discuss various rebuilder implementations :) 15:23:43 #topic short time slot for checkins from various projects: Arch Linux: rebuilder status update (kpcyrd) 15:23:46 :) 15:24:28 kpcyrd: so how will you rename yours ;) 15:24:33 i mean, the stage is yours :) 15:24:36 not sure if this is the place to talk about it, but one hesitation I've been having (from deploying rebuilders on NYU infra) is that there's no easy way to communicate workload information (e.g., expected memory, build time, cores) 15:24:37 This is not directly related to the results on https://tests.reproducible-builds.org/archlinux/archlinux.html, right? 15:25:08 * h01ger thinks its more about https://reproducible.archlinux.org/ 15:25:10 https://reproducible.archlinux.org/ is still working fine, we've started classifying remaining un-reproducible packages and currently got 896 (54.37%) 15:25:29 kpcyrd: can you explain more about automatically classifying things? 15:25:29 sangy: something fedora is considering is putting that information in the spec file 15:25:47 sangy: for openSUSE packages, we have a _constraints file to describe required Disk, RAM, CPU, arch 15:26:03 most of it is due to haskell and because we currently don't set PYTHONHASHSEED=0 in our devtools 15:26:16 Ariadne: that sounds like a good idea 15:26:27 case in point, there's rebuilding going on here, but our poor cores.... http://reproducible-builds.engineering.nyu.edu/ 15:26:46 I also would like to be able to limit worker resources in some sort of "native" way 15:26:56 Would 'export PYTHONHASHSEED=${SOURCE_DATE_EPOCH}' also make sense? 15:27:18 rclobus: I had =42 and it caused some testsuites to fail 15:27:19 bmwiedemann: do you have any info on this? 15:27:23 sangy: Those are NYU-hosted semi-cloud nodes? 15:27:23 sangy: please stop the side discussion... (and add it to topic if there's more to discuss on the topic) 15:27:36 h01ger: it's not automated (except the ^haskell- packages), it's a script that takes a random unclassified package, opens a diffoscope in your browser and generates note until you enter an empty line, then opens the next diffoscope 15:27:37 lamby: yeah, these are on the internal NYU servers 15:27:47 rclobus: I've used that for python-for-android 15:27:49 h01ger: oh, I thought it was part of the rebuilderd discussion? 15:27:51 kpcyrd: ah 15:28:27 can we please stay on topic. following three discussions at once on three topics is a bit hard on the brain :) 15:28:43 sangy: I have an example: https://build.opensuse.org/package/view_file/openSUSE:Factory/chromium/_constraints 15:28:48 kpcyrd: are you done with updates on the arch rebuilder? 15:28:50 my bad, I thought i was being on topic 15:28:52 rclobus: yes, but 0 works too, this currently has to be set in every package until there's a decision by the devtools devs 15:29:26 the NYU ones are Arch Linux rebuilders too :) 15:29:29 kpcyrd: next topic? 15:29:48 in case I didn't miss anything in the backlog - yes 15:29:53 #topic short time slot for checkins from various projects: rebuilderd: status update (kpcyrd) 15:30:15 there's quite a bit of overlap between the topics 15:30:19 * h01ger nods 15:30:26 ah, now I see 15:30:28 happy to move on if everything has been said already 15:30:38 we're currently desperatly looking for more _independent_ people running rebuilders :) 15:30:50 so I'll add that we should be expecting one from Purdue university by end of August 15:30:55 I want to host kpcyrd, and fepitre's 15:31:00 sangy: nice! 15:31:09 & same here :) (tests.r-b.o) 15:31:09 also, I don't have access to NYU's anymore, so we're independent now :D 15:31:10 I think jelle (currently on vacation) currently knows best what kind of resources people would need 15:31:24 sangy: yey! 15:31:44 #info https://github.com/kpcyrd/rebuilderd 15:32:03 next topic then? 15:32:25 something I strongly suggest when running rebuilderd is using two instances, one for results, one for builds 15:32:42 the api on the NYU one is very slow sometimes for example 15:32:45 * h01ger hopes this is documented in the README :) 15:33:18 kpcyrd: yeah, I think that's where the issue lies. I want to figure out a way to use all 96 cores for builds though. That's why I'd like to have the scheduler be able to control workload limits 15:33:54 kpcyrd: what do you mean by "results" and "builds" ? 15:35:11 vagrantc: so rebuilderd has a web view to report resuilts, and then a backend that schedules builds. So schedule the builds somewhere else, and host the web-view in something that doesn't get hit by workers clogging the CPU 15:35:16 vagrantc: reproducible.archlinux.org runs on a 3€/month VPS and is just keeping track of everything, the build servers should be external so they don't impact the api if they start swapping 15:36:00 got it, thanks for clarifying :) 15:36:06 you're welcome :) 15:36:44 then.. 15:36:47 #topic short time slot for checkins from various projects: Alpine Linux: status update (Ariadne) 15:37:30 alpine reproducibility effort is starting to ramp up… kpcyrd’s work on making the raspberry pi installation image reproducible is starting to land in upstream components (for example apk indices are now reproducible) 15:37:54 very nice! 15:38:02 there’s a couple of patches still pending on that but then all install media (except ISOs) should be reproducible 15:38:23 Ah, apk indices are included on install media? 15:38:39 .buildinfo support is headed for abuild as well 15:38:51 dang, nice job! 15:38:57 https://reproducible-builds.org/projects/who#Alpine currently links to https://tests.reproducible-builds.org/alpine/alpine.html but that page hasnt been really updated since april 2020... 15:39:20 is there a more current url of these effors? (either tests, or documentation or ...) 15:39:23 lamby: not the full index, but the packages that get baked into the install medium get tracked in an APKINDEX :) 15:39:23 lamby: yes, we create a minirepo on the install media, and then use that to install a live environment into tmpfs 15:39:37 Cool 15:39:52 i think debian media have similar indices to support cdebootstrap 15:40:49 h01ger: i’ve no idea who set up or runs that URL, but we are working issues in #alpine-reproducible on OFTC 15:41:24 kpcyrd and myself worked on that url a while ago 15:41:37 anyway once the buildinfo stuff is merged into abuild we will set up a rebuilder and all that :) 15:41:44 probably next month i would guess 15:41:59 :thumbsup: 15:42:06 and that’s about it 15:42:42 so you can next topic if you want :) 15:42:44 Ariadne: https://salsa.debian.org/reproducible-builds/reproducible-website/-/blob/master/_data/projects.yml#L1 is what you want to update one day 15:42:54 * h01ger nods, thank you! 15:43:09 * h01ger waits for 60secs for questsions 15:43:12 -s 15:43:35 #topic short time slot for checkins from various projects: Debian live-build (rclobus) 15:43:47 I've written a summary to the mailing list: https://lists.reproducible-builds.org/pipermail/rb-general/2021-July/002303.html 15:44:07 :thumbsup: :) 15:44:10 rclobus, are you already using my snapshot instance? 15:44:23 In short: all regular images (except for cinnamon) are reproducible, then though I only tested standard, GNOME and KDE. 15:44:30 fepitre: Not yet. 15:44:54 First I wanted to add artifacts, so the ISO files could be downloaded for later inspection. 15:44:59 that's a pretty comprehensive set to test 15:45:18 Due to some oversight, I managed to fill /tmp on the Jenkins master node... Oops! 15:45:26 does 'comprehensive' mean 'small' or 'inclusive' here? 15:45:50 rclobus, sure, don't hesitate to ping me, I look at any issue and help into solving them (if exists) 15:45:56 The set contains the configuration of all current Debian Live images 15:45:58 h01ger: complete ? 15:46:10 h01ger: or ... nearing complete 15:46:41 vagrantc: thanks :) 15:47:02 At this moment, I see a non-reproducibility that can be reproduced with PERL_HASH_SEED. 15:47:18 And for some reason diffoscope quit on Jenkins, but not on my computer 15:47:22 Anyway, 15:47:31 rclobus: really excited to see this work :) 15:47:58 +1 15:48:06 the artifacts are disabled for the moment, but I'm planning to reintroduce that feature. But this time without risk of filling all drives on the Jenkins nodes 15:48:10 * h01ger too - just unhappy about the debian live situation in general, but thats unrelated/offtopic here (though i'd be happy to explain in a unlogged situation...) 15:48:30 next topic? 15:48:33 Yes. 15:48:51 #topic short time slot for checkins from various projects: https://ismypackagereproducibleyet.org looking for more datasources ( bmwiedemann ) 15:49:56 bmwiedemann: the datasource you want to use for Arch Linux is probably https://reproducible.archlinux.org/api/v0/pkgs/list :) 15:50:25 kpcyrd: arch seems to be included already 15:50:38 bmwiedemann: what data sources do you have currently? 15:51:17 obfusk: it's using a different datasource though: https://ismypackagereproducibleyet.org/?pkg=rebuilderd&query=query 15:51:52 ah. 15:52:11 maybe cbaines knows something that could be used to query guix ? 15:52:33 and someone else nix? 15:52:53 I have no idea how the nix RB infrastructure works, but (as a nix package maintainer) I'd be happy to help :) 15:53:24 seems we lost bmwiedemann :/ 15:53:28 ah, back 15:53:29 I don't think there is any easy API for it? cc gchristensen 15:53:34 bmwiedemann: ah hi :) 15:53:41 we have Arch, openSUSE, Debian 15:54:16 we don't currently check reproducibility of the whole nixpkgs, so we'd either have to publish partial results from something like https://r13y.com/iso_gnome or make progress on https://github.com/tweag/trustix 15:54:31 1. our build infrastructure at hydra.nixos.org has rudimentary support for reproducibility checking, but it is mostly POC-grade. r13y.com is a smallish wrapper around Nix that substitutes the binaries, then does a check build locally of each one, and publishes the report. it does this via buildkite on a schedule 15:54:42 the arch data is a bit optimistic, as it reports packages as reproducible if there is one reproducible subpackage 15:54:43 not sure what the API would look like but happy to talk about one 15:55:25 raboof: partial results would be a good start. everyone has different packages anyway 15:55:29 * h01ger is reminded of https://m.xkcd.com/2494/ :) 15:55:32 oh, this isn't looking as good as it used to: https://data.guix-patches.cbaines.net/repository/2/branch/master/latest-processed-revision/package-reproducibility 15:55:36 (flawed data) 15:56:12 shall we move on and leave the details here for later? 15:56:36 (bmwiedemann) 15:57:07 gchristensen: I import json data about packages. You can check the sources for data from others. 15:57:11 OK to move on. 15:57:28 ok 15:57:33 #topic short time slot for checkins from various projects: F-Droid (obfusk) 15:58:46 we now have 1 more app that uses signatures embedded in the metadata: Bitcoin Wallet 15:59:12 this is a good or bad thing? :) 15:59:20 vagrantc: good. 15:59:24 nice. is there a list of those apps? a way to only show these in the fdroid ui? 15:59:41 obfusk: the signature is only in metadata, not in the artifact the end-user installs? 15:59:56 https://f-droid.org/docs/Reproducible_Builds/ 16:00:08 * sangy needs to step out now. Pleasure everyone 16:00:15 sangy: o/ 16:00:24 we support 1) link to a published official APK. if it's "equal" we only publish that 16:00:52 and 2) extract APK signatures and embed them in our metadata repository. 16:01:28 in that case we copy the sigs to the unsigned apk to generate the published official APK. 16:01:54 if that verifies it's reproducible and we publish both that and - as usual - an APK signed by f-droid itself. 16:02:32 so that combines both our normal built-and-signed-by-us and provided-by-developer-and-guaranteed-to-correspond-to-source 16:02:47 obfusk: i have "vlc" installed from fdroid. how can i see if thats reproducible? 16:03:10 h01ger: it's not :( 16:03:26 you can check the metadata for Binaries: or a signatures/ directory 16:03:32 you can also see it on the website. 16:03:40 e.g. https://f-droid.org/en/packages/de.schildbach.wallet/ 16:04:01 "It is built and signed by F-Droid, and guaranteed to correspond to this source tarball." + " It is built and signed by the original developer." 16:04:43 ok, so i need to search for a url somehow and then look for a string there ;) 16:04:45 ony of my own apps had some build issues which have been fixed now. it's not published yet, though so it *could* still fail :') 16:05:12 https://f-droid.org/packages/dev.obfusk.jiten will hopefully show v1.1.0 soon 16:05:23 (CI passed though) 16:05:29 allright, thanks for the updates! move on? 16:05:35 not yet :) 16:05:41 (I'll try to be brief) 16:05:44 ok! 16:06:32 I also decided today to look into supporting verifying signed git tags from upstream repos soon. 16:06:39 and finally: 16:06:56 (related to Android but not F-Droid directly) 16:07:30 starting next month google play will require developers to use "app bundles" instead of APKs (for now apps). which means they need to hand over their signing keys to google. 16:07:43 they do provide "code transparency" (https://developer.android.com/guide/app-bundle/code-transparency) 16:08:03 obfusk: Huh. What's the reason for that change? 16:08:31 which is a very weak form of RB that doesn't check anything but binary code and doesn't actually check anything by default on install time. can only be done manually. 16:08:50 egads! 16:09:10 lamby: I assume b/c it allows google to build multiple APKs specifically targeted to devices from the app bundle it saves them bandwith. 16:09:17 of course it also gives them a lot more control. 16:09:30 "hand over your signing keys" sounds like a huge you're doing it wrong 16:09:55 vagrantc: well... technically f-droid does that too. except there's no "hand over", just *signed by us* 16:10:15 the url given states "It uses a code transparency signing key, which is solely held by the app developer." 16:10:19 obfusk: that's fine and honest ... 16:10:42 h01ger: yes. but that's only for that *optional* and incomplete feature 16:10:51 ic 16:11:05 https://developer.android.com/guide/app-bundle/ 16:11:20 shall we move on? (discussing android/google politics is kinda offtopic here and now ;) 16:12:36 yes. 16:12:42 ok 16:12:52 thats for all the 'short' updates! :) 16:13:00 * h01ger learned a lot 16:13:04 #topic r-b ecosystem (lamby) 16:13:22 Thanks 16:13:48 This is mostly just a reminder and pointer to check out the "Help us map the reproducible builds ecosystem" thread on our mailing list 16:13:49 https://lists.reproducible-builds.org/pipermail/rb-general/2021-July/002302.html 16:14:13 The background is not too extensive, but probably doesn't make sense to simply repeat it here on IRC 16:14:55 #info https://pad.riseup.net/p/rbecosystemmapping-keep 16:15:10 lamby: I just added python-for-android 16:15:34 One thing folks here can easily do is see if their project, organisation, goal or initiative is covered there. 16:15:35 And if not, simply add it: no need to be "pretty", we can always go through and tidy it up later. 16:15:38 obfusk: perfect, thanks 16:16:29 lamby: should I add apksigcopier? 16:16:41 yes please :) 16:16:45 obfusk: Sure, yes. 16:16:51 * fepitre has to leave. thank you and see you soon 16:16:58 fepitre: o/ 16:16:58 Do err on the side of adding "too much", if anything 16:17:02 cheerio, fepitre 16:18:11 anything else on this topic? 16:18:29 Nothing more from me, at least 16:18:45 lamby: there's a bit of overlap between that pad and https://pad.riseup.net/p/rebuilders%2Borchestration-tools :) 16:19:02 Ah, that's a good spot. I'll add a link from one to the other. 16:19:46 i linked that pad to some folks who i know to be funding RB work, to see if they want to add themselves 16:20:28 Ariadne: 👍👍 16:21:02 ok, lets move on 16:21:06 # topic r-b.o/docs/verification.md or rebuilding.md (h01ger) 16:21:14 * raboof has to leave o/ 16:21:20 so i want to document https://pad.riseup.net/p/rebuilders%2Borchestration-tools properly, on our website 16:21:22 raboof: o/ 16:21:51 i'm just unsure whether to use r-b.o/docs/verification.md or rebuilding.md or something else. or both? 16:22:11 (and that page needs text too, not just links like the pad has right now) 16:23:07 what do you think? 16:23:29 h01ger: semi-related (and I forgot this earlier): https://verification.f-droid.org/ (https://f-droid.org/docs/Verification_Server/) 16:24:10 rebuilding.md would be "I want to run an independent build server" and verification.md would be "I'm a user, how do I ensure the package has been independently verified"? 16:24:23 *the package I'm about to install 16:24:46 thats a nice distinction 16:25:01 kpcyrd: that was my thought as well :) 16:26:20 ok, i can work with that. :) next topic then? 16:26:41 (i'll prepare those pages, half empty at first...) 16:27:58 #topic Any Other Business (AOB) 16:28:03 #topic Any Other Business (AOB) - Setting PYTHONHASSEED/PERL_HASH_SEED in reprotest (rclobus) 16:28:13 (we can have more AOB topics...) 16:28:33 I have a question about this: can we enforce e.g. the reverse ordering of hashes? 16:28:58 i.e. to guarantee a difference when the scripts runs for the second time? 16:29:29 Hm. So I did a patch for this years ago, but IIRC it was rejected by upstream... 16:29:56 For Python. 16:29:59 Because occasionally, the results are reproducible, when the second build is run. 16:30:00 I feel like I'm missing context :) 16:30:06 Context: 16:30:18 I'm running a Perl script, that contains a hash. 16:30:28 That uses a 'foreach' to list all elements 16:30:38 According to the docs, the hash order is undefined. 16:31:01 "hash" as in "set" instead of "cryptographic hash", right? :) 16:31:07 kpcyrd: yes 16:31:08 fwiw: python dicts (hashes) now preserve insertion order (sets don't) 16:31:20 I see, thanks 16:31:24 kpcyrd: key->value mapping 16:31:29 With PERL_HASH_SEED, we can enforce the order, but we cannot be certain that a different seed value will *certainly* result in a different order. 16:32:15 So, by accident, we might declare the script reproducible, even though it isn't. 16:33:17 rclobus: I would assume this only happens when the seed is not properly set though? 16:33:29 or am I missing a scenario? 16:33:51 rclobus: I wouldn't worry too much about this, if it's a problem it's going to show up in the wild given enough rebuilders :) 16:34:04 what kpcyrd says 16:34:16 also, if we can reproduce something, we can reproduce it :) 16:34:20 and the python situation is much improved now that dicts preserve insertion order. 16:34:22 kpyrd: Ok, I'll stop worrying :-) 16:34:38 you can prove something is unreproducible, you can't prove it is reproducible 16:34:41 a rebuilder confirms "I've built the binary artifact out of this source input", it doesn't matter if it needs multiple tries (first try is still nice though) 16:35:14 (i disagree with the last 'it doesnt matter' but i'm fine to disagree here and now :) 16:35:40 (basically: it matters but not much) 16:35:41 (it's ok if) 16:35:42 #topic Any Other Business (AOB) - Setting PYTHONHASSEED/PERL_HASH_SEED in reprotest (rclobus) 16:35:47 bah, sorry 16:35:53 any other topic? 16:36:01 last call 16:36:17 None here. :) 16:36:22 h01ger: did you see my links to the f-droid verification server? 16:36:39 obfusk: yes 16:36:46 (so e.g. vlc is indeed not reproducible, not just not officially) 16:37:03 ack 16:37:08 obfusk: i wasnt asking about vlc i was asking about a general way to find out whether an fdroid app is reproducible 16:37:14 vlc was just an example 16:37:18 ; leaves now. Thanks for the meeting. 16:37:20 h01ger: I know :) 16:37:25 o/ 16:37:25 rclobus: o/ 16:37:46 obfusk: i didnt receive an answer to that general question though :) 16:38:00 maybe s#receive#understand# ;) 16:38:04 i need to prod people giving talks related to reproducible-builds at the upcoming debconf to know what's up :) 16:38:09 meant to ask on the list 16:38:14 https://verification.f-droid.org/ -> "This is the Verification Server for https://f-droid.org. It rebuilds apps from source that were built by f-droid.org and checks that the results match. If they match, then there is a file named *.verified.txt added next to the APK that was verified. If not, then there is output from diffoscope in HTML and text." 16:38:30 and would also be curious if anyone is giving talks at any upcoming conferences related to reproducible builds 16:38:31 (the .txt seems to be missing, but there's a verified: in a .json) 16:38:48 vagrantc: maybe we should discuss merging out talks? 16:39:19 i got the impression there were maybe also other talks 16:39:36 h01ger: yeah, maybe we merge ... 16:39:48 h01ger: but maybe take it outside the "meeting" 16:40:07 h01ger: e.g. https://verification.f-droid.org/org.videolan.vlc_13030408.apk.json -> verified: false 16:40:42 obfusk: https://verification.f-droid.org/ indeed has the info, i'm just not impressed with the different names there "org.vi_server.red_screen_2" compared to how the app is called on the device user facing.. 16:40:47 vagrantc: yeah 16:41:08 obfusk: the app is called 'vlc' not 'org.videolan.vlc_13030408' ;p 16:41:27 anyhow, any other topic or should we finish this meeting for today? 16:41:34 h01ger: yes. 16:41:42 but https://f-droid.org/packages/org.videolan.vlc/ -> https://f-droid.org/repo/org.videolan.vlc_13030408.apk 16:41:56 org.videolan.vlc != vlc 16:42:01 but a nice api would be fine 16:42:07 but i'm repeating myself :) 16:42:22 s/fine/nice/ 16:42:28 :) 16:42:38 #topic closing time 16:42:44 thanks all! 16:42:50 thanks! 16:42:50 Thanks for arranging and running the meeting, h01ger. Looking forward to the next one... 16:42:52 unless someone has a very last topic... 16:43:10 #info next meeting will be Tuesday, 31st of August at 15 UTC, here 16:43:28 thank you all! it's been a pleasure and quite informative! 16:43:33 o/ 16:44:11 o/ 16:44:14 vagrantc: last meeting you suggested you could help me with my "how do I find debian packages I can help with problem"... 16:44:17 o/ 16:44:26 obfusk: oh, i did, didn't i :) 16:44:32 h01ger: should I add the android app bundle stuff to the report or is that OT? 16:44:53 obfusk: add anything to the report, lamby is a great editor :) 16:44:56 obfusk: now might not be a great time for me ... but maybe sometime thursday? 16:45:01 "anything" obviously :) 16:45:18 what? no fanfiction? 16:45:35 \o 16:45:38 #endmeeting