BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//pretalx//pretalx.devconf.info//devconf-cz-2026//speaker//XTVUNQ
BEGIN:VTIMEZONE
TZID:CET
BEGIN:STANDARD
DTSTART:20001029T040000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20000326T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:pretalx-devconf-cz-2026-MVEWZ8@pretalx.devconf.info
DTSTART;TZID=CET:20260618T140000
DTEND;TZID=CET:20260618T143500
DESCRIPTION:Update one package in your container image and watch your users
  re-download 500MB of unchanged content. Traditional Dockerfile layers are
  instruction-based—a single package update invalidates an entire layer.\
 n\nThis talk introduces **chunkah**\, a tool that post-processes container
  images into content-based layers. Files are grouped by package\, not Dock
 erfile structure. Update one package\, users download only that layer.\n\n
 We'll cover:\n\n- Why instruction-based layers hurt pull performance (with
  numbers)\n- How content-based splitting works under the hood\n- Live demo
 : chunkah in action\, before/after comparison\n- How `podman history` reve
 als package-to-layer mapping\n\nFrom Project Hummingbird\, where we run 70
 + production container images with chunkah\, we'll show real metrics on ba
 ndwidth savings and how to adopt this in your own builds.\n\n**Audience**:
  Container image builders\, CI/CD engineers\, registry operators\, anyone 
 who's wondered why their image pulls are so slow.
DTSTAMP:20260430T115404Z
LOCATION:D0206 (capacity 154)
SUMMARY:Stop Re-Downloading Your Container Images: Content-Based Layers wit
 h Chunkah - Michael Krausch-Hofmann
URL:https://pretalx.devconf.info/devconf-cz-2026/talk/MVEWZ8/
END:VEVENT
BEGIN:VEVENT
UID:pretalx-devconf-cz-2026-JM8CZM@pretalx.devconf.info
DTSTART;TZID=CET:20260618T161500
DTEND;TZID=CET:20260618T165000
DESCRIPTION:Rebuild the same Containerfile with the same packages and you'l
 l get a different image hash. This isn't a bug—it's the default behavior
  of container builds\, and it breaks verification\, caching\, and supply c
 hain security.\n\nThis talk explores the surprisingly hard problem of repr
 oducible container builds. We'll dissect exactly what breaks reproducibili
 ty—timestamps\, SQLite journal modes\, machine-id files\, transaction lo
 gs—and show practical techniques to fix each one.\n\nWe'll cover:\n\n- L
 ive demo: same Containerfile\, different hash—why?\n- SOURCE_DATE_EPOCH 
 and timestamp normalization\n- The SQLite WAL surprise—and the one-line 
 fix\n- A checklist of artifacts to remove for reproducibility\n- Verificat
 ion: rebuilding from SLSA provenance attestations\n\nFrom Project Hummingb
 ird (70+ container images\, SLSA Level 3)\, we'll show how to achieve bit-
 for-bit identical rebuilds in your CI/CD pipelines.\n\n**Audience**: CI/CD
  engineers\, security teams\, anyone wondering why their image rebuilds do
 n't match.
DTSTAMP:20260430T115404Z
LOCATION:E112 (capacity 156)
SUMMARY:Why Your Container Builds Aren't Reproducible (And How to Fix It) -
  Michael Krausch-Hofmann
URL:https://pretalx.devconf.info/devconf-cz-2026/talk/JM8CZM/
END:VEVENT
END:VCALENDAR