In the fedmsg world this was done by the modname passed to the
fedmsg.publish() function but in fedora-messaging there is no
such concept, so we need to pass the exact/correct topic.
This commit fixes that.
Signed-off-by: Pierre-Yves Chibon <pingou@pingoured.fr>
It doesn't make much sense to have a shebang in a script that is
not executable. Also, we set 775 permissions to it in a spec file
anyway.
I am adding it because the tests need to run the script.
Except for a simple refactoring that shortens our over-complicated
`main` function, this also have an added value. Not every distgit
instance is interested in sending `fedmsg` messages. In such cases,
we don't want to force them to install the `python-fedmsg` package.
* they were rendered incorrectly due to printing Content-type with
extra new line already in main body. That means error statuses were
not properly handed to httpd. Also fix related buggy test.
GSS_NAME is only set in a specific configuration (with GssapiLocalNames on).
Make the upload.cgi also work if that configuration is not set.
Signed-off-by: Patrick Uiterwijk <patrick@puiterwijk.org>
=============
distgit: Upload files to both the new and old path
Currently, the CGI script is set to upload files:
- to the old path if the upload uses md5
- to the new path if the upload uses sha512
The old path is as follows:
/%(srpmname)s/%(filename)s/%(hash)s/%(filename)s
The new path is:
/%(srpmname)s/%(filename)s/%(hashtype)s/%(hash)s/%(filename)s
This was meant to ensure compatibility with current fedpkg which
always downloads from the old path, but will eventually download from
the new path when we move to sha512.
However, working more on this, I now think it would make for a smoother
transition if we instead always stored the files at the new path, but
just hardlinked to the old path if the upload is using md5.
This is what this patch achieves.
With this deployed in production, fedpkg could be patched to try
downloading from the new path, and fallback to the old one if necessary,
which decouples the migration to the new path from the migration to the
new hash.
=============
distgit: Ensure the folder exists
We can't hard link the file if the folder containing the link
destination does not exist.
Hurray for testing in staging!
=============
distgit: os.link fails if the dest already exists
=============
distgit: And so does os.makedirs
=============
distgit: Actually hardlink over the existing source at the old path
Without this, the file could exist at both the old and new path, taking
the space on the disk twice.
This forces a hardlink if the file already existed at the old path.
=============
Remove the lookaside email hook (rely on fedmsg now).