I've made a new test tarball today, and put it on my own web server since I didn't want to repeat the problems with the one I put on downloads.kde.org:
http://www.valdyas.org/~boud/calligra-3.0.0.1.tar.xz Extra weirdness: last week, during the krita release, I could use gpg to sign, this week, with no updates or whatever, and the same plasma 5 environment, signing fails again: boud@thinkstation:~/kde/src/createtarball> gpg2 --output calligra-3.0.0.1.tar.xz.sig --detach-sig calligra-3.0.0.1.tar.xz You need a passphrase to unlock the secret key for user: "Boudewijn Rempt <foundat...@krita.org>" 4096-bit RSA key, ID 722EA3BD, created 2016-09-06 gpg: problem with the agent: No pinentry gpg: no default secret key: Operation cancelled gpg: signing failed: Operation cancelled And gpg-agent is running: boud@thinkstation:~/kde/src/createtarball> ps ax | grep gpg-agent 1806 ? S 0:00 /usr/bin/dbus-launch --sh-syntax --exit-with-session /usr/bin/ssh-agent /usr/bin/gpg-agent --sh --daemon --keep-display --write-env-file /home/boud/.gnupg/agent.info-thinkstation:0 /etc/X11/xinit/xinitrc 1808 ? Ss 0:00 /usr/bin/ssh-agent /usr/bin/gpg-agent --sh --daemon --keep-display --write-env-file /home/boud/.gnupg/agent.info-thinkstation:0 /etc/X11/xinit/xinitrc 1809 ? Ss 0:00 /usr/bin/gpg-agent --sh --daemon --keep-display --write-env-file /home/boud/.gnupg/agent.info-thinkstation:0 /etc/X11/xinit/xinitrc On Tue, 20 Dec 2016, Dag wrote: > I'd like to discuss how to handle future releases, we don't want to continue > to burden Boudewijn with it. > > To summarize, I see two problem areas: > - Who can generate the final release tarball. (pnt 4 below) > It must be someone with a trusted pgp key (I'm not trusted, so can't do it). > It should take <30 minutes, so is there somebody out there who could help? > > - Somewhere to upload tarball for testing/checking before released to > download.kde.org. > I thought about ftp://upload.kde.org/incoming but I don't think that is > possible? > > To ensure (as much as possible) that things will go smoothly I'm working on a > release script > and also plan to add more autotesting of the messages generation framework. > We can't have another mess like this time. > > So I propose a release cycle like this: > > 1. ~2 weeks before release; string freeze and feature freeze > 2. Closer to release some of us (I) create tarball, test and check if ok. > 3. When ok, tag git > 4. Create release tarball, upload for testing > 5. Somebody (I) download tarball, build and test to verify it is ok > 6. Publish tarball on download.kde.org (or possibly upload.kde.org) > 7. Notify packagers and wait some time (a week?) for feedback > 8. Announce to the world > > What have I missed? > Solutions (and comments) are welcome > > Cheers, > Dag > -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org