Commit 24a68c34 authored by Holger Levsen's avatar Holger Levsen

berlin2016: cross-distro formatting

Signed-off-by: Holger Levsen's avatarHolger Levsen <holger@layer-acht.org>
parent af4e20f8
......@@ -108,8 +108,8 @@ Day 2
- **Documentation**
- **Funding and CII**
- **RPM and hacking**
- **Nix build stuff to be incorporated with test at https://tests.reproducible-builds.org**
- **Boostrap test jenkins to replicate https://tests.reproducible-builds.org**
- **Nix build stuff to be incorporated with tests at [https://tests.reproducible-builds.org](https://tests.reproducible-builds.org)**
- **Boostrap test jenkins to replicate [https://tests.reproducible-builds.org](https://tests.reproducible-builds.org)**
- **Embedded images cross-distro**
* 16:30 Adjourn
......@@ -125,7 +125,7 @@ Day 3
* 10.00 Opening Session
* 10:20 Working Sessions VI
- **Cross-distro collaboration on reproducible builds https://pad.riseup.net/p/reproduciblebuildsII-crossdistro**
- **[Cross-distro collaboration]({{ "/events/berlin2016/crossdistro/" | prepend: site.baseurl }})**
- **Boostrapping II https://pad.riseup.net/p/reproduciblebuildsII-bootstrappingII**
- **Documentation III https://pad.riseup.net/p/reproduciblebuildsII-documentationIII**
- **Binary transparency II https://pad.riseup.net/p/reproduciblebuildsII-binarytransparencyII**
......
---
layout: event_detail
title: crossdistro
title: Cross-distro collaboration
event: berlin2016
order: 250
permalink: /events/berlin2016/crossdistro/
---
see https://pad.riseup.net/p/rb-thu-cross-distro
# Cross-distro
* web infrastructure for searching, sorting
* don't necessarily need a single database, but maybe the distros share code to run their respective databases
* what's in the buildinfo files
## What's Debian-specific about buildinfo files?
The dependencies are written as NVR - name, version, release - single string
Doc team working on getting buildinfo specification up to the doc page
Debian wiki says half the fields are the output of a deb-* tool
* The dependencies are written as NVR - name, version, release - single string
* Doc team working on getting buildinfo specification up to the doc page
* Debian wiki says half the fields are the output of a deb-* tool
* But that page is outdated
Architecture names are different, and have slightly different semantics
* Architecture names are different, and have slightly different semantics
* e.g., Fedora has subarchitectures of armhbf - You could build RPMs for just that family, not optimized for any subarchitecture
Considering adding a Known-Signature field to the buildinfo file - You're expected to copy it when you rebuild the RPM, since you don't have the private key to re-sign it
* Considering adding a Known-Signature field to the buildinfo file - You're expected to copy it when you rebuild the RPM, since you don't have the private key to re-sign it
Which fields are necessarily distro-specific? Which can we ask the distros to conform to a spec?
Arch buildinfo files are included in the package, so they only include things that don't change. They're not even using RFC822 format.
......@@ -31,13 +27,15 @@ Signatures: buildinfo files are made at build time, but the RPM is signed later.
Could include two checksums - One signed, one unsigned.
Let's publish a buildinfo spec 1.0, and have people simply try to work to fit into it. Then come back in a year and revise for 1.1 for whatever couldn't be handled with 1.0.
* Or is it too early for that? Some preference to update on a rolling basis to try to get problems addressed sooner.
* Document what fields are expected to vary across distributions - based on the content of a Distribution field.
* Or is it too early for that? Some preference to update on a rolling basis to try to get problems addressed sooner.
* Document what fields are expected to vary across distributions - based on the content of a Distribution field.
## How can cross-distro communication happen?
r-b-general seems to be OK - but needs to be more widely advertised.
* Docs are going to include a "Get Involved" page aimed at distro folks. This needs to be part of that.
* Docs are going to include a "Get Involved" page aimed at distro folks. This needs to be part of that.
Problem that all the current r-b infrastructure is hosted on Debian. In order to get involved, you need to know Debian process: what channels to use, how to file bugs. It's a barrier to entry. Documentation could also help with this - although that still leaves a perceptual barrier to entry. Something Forge-like would be more friendly - Something that consolidates all the work in a single place. Fedora used to have FedoraHosted; now it has https://pagure.io/.
......@@ -65,7 +63,7 @@ issues-and-notes.yaml - Stored in a Git repository that lists distro-specific is
https://maintainer.zq1.de - Bernhard's site that shows the version of a package in each distro, with links to source repos and patch trackers (todo: bug-trackers?)
Unrelated cross-distro MLs
https://lists.linaro.org/mailman/listinfo/cross-distro ARM-specific?
[https://lists.linaro.org/mailman/listinfo/cross-distro](https://lists.linaro.org/mailman/listinfo/cross-distro) ARM-specific?
## Gentoo
......@@ -77,4 +75,4 @@ As a matter of policy, Gentoo packages can change without changing the package v
Does it make sense for buildinfo files to refer to each other? e.g., this package was built with this version of GCC, here's the buildinfo file for that...
CFLAGS need to be sorted. Probably best to do that when the buildinfo file is written. Just pick an order and use that.
-
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment