sayanchowdhury opened a new pull-request against the project: `releng` that you are following:
``
Script to delete the nightly AMIs periodically
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/pull-request/6613
pingou reported a new issue against the project: `releng` that you are following:
``
As far as I understood from Patrick the current mechanism for koji to allow/deny building from a source is fairly simple.
With pagure on the top of dist-git, we may need something a little more flexible as we would like to support the following use-cases:
* Builds from main repo proceed as now
* Builds from forks can only be either (or both) of:
* scratch-build
* in a certain tag used for the CI integration (redefining the dist tag to allow building the same package, once for testing and once for real)
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6671
dustymabe reported a new issue against the project: `releng` that you are following:
``
We'd like to put out "pre-release" images for Fedora 26 atomic host. I was told by dennis that we should not use the images that are created by the nightly f26 branched "gloabal" compose because those get cleaned up quickly. Thus, we'd like to run a daily run of fedora 26 atomic host, just like we do for f25 (where we are using `fedora-atomic.conf` from the pungi-fedora repo and the results stored at https://kojipkgs.fedoraproject.org/compose/twoweek/ like the 25 results are so that we can allow people to test using them.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6713
rdieter reported a new issue against the project: `releng` that you are following:
``
To ease the building of batch updates of kde-related packages (of up to 70 packages at a time), please create a f26-kde koji build target (similar to how f25-kde works). Thanks.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6689
asamalik reported a new issue against the project: `releng` that you are following:
``
The modularity team needs to be able to build modules using local module-build-service (MBS). After some discussion on #fedora-modularity with @jkaluza and @psabata it appears I need `f26-modularity` to appear at [kojipkgs.fedoraproject.org/repos](https://kojipkgs.fedoraproject.org/repos/) so MBS can use it as a buildroot for modules.
I probably want you to run `koji add-target f26-modularity-repo f26-modularity f26-modularity`. (@jkaluza promised it's the right command)
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6696
kalev reported a new issue against the project: `releng` that you are following:
``
Hi,
Please create a new f26-gnome side tag and build target. We'll use it for building GNOME megaupdates before submitting them to Bodhi.
Thanks,
Kalev
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6700
mbriza reported a new issue against the project: `releng` that you are following:
``
Hello,
for testing, I have released FMW 4.0.95. To accommodate the changes I'll list below you can use that, however I'd like to ship 4.1.0 (when it's done) as the release for F26.
Mac builds:
======
Homebrew ( https://brew.sh/ ) or an other package manager is required. Use it to install xz (to provide /usr/lib/liblzma.dylib and the required headers).
It's then necessary to include the liblzma.dylib file inside the package (in Contents/Frameworks) and change the rpath pointing at it with install_name_tool. See https://github.com/MartinBriza/MediaWriter/blob/master/dist/mac/build.sh#L38 to see how it's done. No special signing is required for this file.
If you're using macdeployqt with the --always-overwrite argument, you need to stop using it or the compose will fail.
Windows builds:
======
It's necessary to build using F26 or Rawhide. There is a multitude of bugs solved by updating to Qt 5.7.1 which is now included only in F26 and above.
No extra build steps are required, however there's more dynamic libraries to include in the package. See https://github.com/MartinBriza/MediaWriter/blob/master/dist/win/build.sh#L34 .
Also please note that when your code signing certificate for Windows expires, it's now necessary to get a "secure flash drive" from Unizeto with a new one, making it now more than €100 instead of €14 - we should probably change the certificate provider.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6721
kevin reported a new issue against the project: `releng` that you are following:
``
Right now we have a list of releng folks that trade off weekly handling bodhi updates pushes. Because all these folks are in different locations and have different workdays and business, updates pushes happen as they are able throughout the day. Additionally some folks are able to push on weekends and holidays and others are not.
Since we no longer need a human release engineer to sign packages before pushing updates, we should consider moving this to just a cron script that runs at the same time every day. This would have the advantage of making the pushes much more predictable and would also save time of busy release engineers.
The script would need to have a bit of error handling and check for existing lock files and error out if any exist. It would also need to be adjustable during freezes to not push the stable updates for the frozen release. Any issues or problems would need to follow a process of filing a ticket on the issue and all release engineers communicating on that ticket so no one is duplicating efforts.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6617
jlebon reported a new issue against the project: `releng` that you are following:
``
We have internal testers which essentially check for new commits by polling the `fedora-atomic/25/x86_64/updates/docker-host` ref on https://kojipkgs.fedoraproject.org/atomic/25. When the ref changes, a new test is triggered. We've been seeing failures in which the ref gets updated, but the commit object to which the ref points to is not yet in the repo.
We need to make sure that all the refs are being updated safely: first objects, then refs. There is a more complete [rsync-repos](https://github.com/ostreedev/ostree-releng-scripts/blob/master… script that knows how to safely do this.
For the updates ref in specific, judging from the masher code, it seems like we're operating on the live repo and then "waiting" for it sync out?
https://github.com/fedora-infra/bodhi/blob/1a2871520d719c44f5cab37b2a555474…https://github.com/fedora-infra/bodhi/blob/1a2871520d719c44f5cab37b2a555474…
What kind of lag are we talking about? 10m? 30m? Is there any way to know when *all* the files have been synced out?
We might need to change this so that we compose on a *copy* of the repo, and then e.g. use the rsync script above to update the real repo. But this presumes that the order in which we rsync to the mount reflects the order in which it hits the public, which may not be true it seems?
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6645