[releng] Issue #7424: Fix F28 tagging where bodhi tagged older build over new
by Kalev Lember
kalev reported a new issue against the project: `releng` that you are following:
``
I noticed these 4 packages where Bodhi has tagged older builds over newer, making the _old_ build appear in the repositories. There's likely more, these are just the ones I accidentally noticed.
Please fix by retagging the newer build.
```
$ koji list-history --tag f28 --package gstreamer1-plugins-base
Fri Mar 30 14:33:16 2018 gstreamer1-plugins-base-1.14.0-1.fc28 tagged into f28 by bodhi [still active]
Fri Mar 30 14:33:17 2018 gstreamer1-plugins-base-1.13.91-1.fc28 tagged into f28 by bodhi [still active]
$ koji list-history --tag f28 --package gstreamer1-plugins-good
Fri Mar 30 14:33:17 2018 gstreamer1-plugins-good-1.14.0-1.fc28 tagged into f28 by bodhi [still active]
Fri Mar 30 14:33:17 2018 gstreamer1-plugins-good-1.13.91-1.fc28 tagged into f28 by bodhi [still active]
$ koji list-history --tag f28 --package gstreamer1-plugins-bad-free
Fri Mar 30 14:33:16 2018 gstreamer1-plugins-bad-free-1.14.0-1.fc28 tagged into f28 by bodhi [still active]
Fri Mar 30 14:33:17 2018 gstreamer1-plugins-bad-free-1.13.91-1.fc28 tagged into f28 by bodhi [still active]
$ koji list-history --tag f28 --package gstreamer1-plugins-ugly-free
Fri Mar 30 14:33:17 2018 gstreamer1-plugins-ugly-free-1.14.0-1.fc28 tagged into f28 by bodhi [still active]
Fri Mar 30 14:33:17 2018 gstreamer1-plugins-ugly-free-1.13.91-1.fc28 tagged into f28 by bodhi [still active]
```
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7424
6 years
[releng] Issue #7441: Fix F28 tagging where bodhi tagged older xed build
over new
by Leigh Scott
leigh123linux reported a new issue against the project: `releng` that you are following:
``
Bodhi has tagged older xed build over newer, making the old build appear in the repositories. There's likely more, these are just the ones I accidentally noticed.
https://bugzilla.redhat.com/show_bug.cgi?id=1569251
xed is also absent on the f28 cinnamon spin
Please fix by retagging the newer build.
```
koji list-history --tag f28 --package xed |grep 1.6.4
Tue Mar 20 04:40:55 2018 xed-1.6.4-0.2.20180309git3733860.fc28 tagged into f28 by bodhi [still active]
Fri Mar 30 13:34:30 2018 xed-1.6.4-0.1.20180309git3733860.fc28 tagged into f28 by bodhi [still active]
```
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7441
6 years
[releng] Issue #7505: Stray NFS silly-rename file in
fedora/linux/updates/28/Everything/x86_64/repodata
by Jason ティビツ
tibbs reported a new issue against the project: `releng` that you are following:
``
On batcave, I see this:
```
rw-r--r--. 1 263 263 10909600 May 17 12:43 /srv/web/pub/fedora/linux/updates/28/Everything/x86_64/repodata/.nfs0000000001ca7d1e00009327
```
It also shows up in the generated file list, but I can't transfer it over rsync as the server configuration has exclude = **/.nfs*.
```
rsync: link_stat "/linux/updates/28/Everything/x86_64/repodata/.nfs0000000001ca7d1e00009327" (in fedora-enchilada) failed: No such file or directory (2)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1659) [Receiver=3.1.3]
```
This unfortunately causes my mirror process to fail.
Short term, could someone see what's up with that file? Maybe delete it and regenerate the file list?
Longer term, I will modify the file list generator upstream to allow files to be skipped by pattern. Depending on how I do that, it may be necessary to update the places where create-filelist is called to pass some additional options.
I also note that rsyncd.conf.download.j2 contains:
```
exclude = .snapshot/ .~tmp~/ /.private/ /.private/** **/.nfs*
```
so it would probably be smart to just match that behavior in the file list generator to avoid problems like this.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7505
6 years
Proposed to delete /mnt/koji/mash/
by Kevin Fenzi
Greetings.
/mnt/koji is getting low on space, and one thing I noticed is that we
still have:
/mnt/koji/mash/
This is the directory we used to use back when we used mash to push
updates. It has in it:
221G atomic
59M atomic-updates
160M atomic-updates-logs
1.3T updates
So, nuking this should save us hopefully about 1.5TB.
Additionally, in /mnt/koji/compose/ we have at least 108 each of:
Fedora-Cloud-26-*
Fedora-Docker-26*
Fedora-Cloud-27-*
Fedora-Docker-27*
How many of those should we keep around?
Also, we have compose dirs for 26, 27, 28 with all the composes we had
for each cycle. Do we want to/need to keep those around any?
Should we delete them when a release goes EOL?
If anyone sees anything else we are no longer using, please let me know.
Does anyone need/want/see a need for any of the above?
kevin
6 years
[releng] Issue #7521: KOJI Rawhide buildroot broken by dnf
by Michal Schorm
mschorm reported a new issue against the project: `releng` that you are following:
``
Error: (Fedora rawhide KOJI )
Problem: package policycoreutils-devel-2.8-1.fc29.x86_64 requires dnf, but none of the providers can be installed
- package selinux-policy-devel-3.14.2-20.fc29.noarch requires policycoreutils-devel >= 2.8, but none of the providers can be installed
- package dnf-2.7.5-14.fc29.noarch requires python3-dnf = 2.7.5-14.fc29, but none of the providers can be installed
- conflicting requests: nothing provides python3-libdnf >= 0.11.1 needed by python3-dnf-2.7.5-14.fc29.noarch
--
Solution suggestion:
Untag the broken dnf version?
--
Aditional info:
Issue hit by building mariadb package for rawhide.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7521
6 years
