[releng] Issue #7344: Please generate static deltas for FAW27
by Colin Walters
walters reported a new issue against the project: `releng` that you are following:
``
ostree has had static deltas for years now; it makes us look less than stellar if people aren't getting them. We do this as part of the FAH release process, but at the moment there is no such thing for FAW which just drops out of pungi. Simplest thing is probably to add it to Ansible for now, literally just `ostree --repo=/path/to/repo static-delta generate --if-not-exists fedora/27/x86_64/workstation`. (However, the benefits of deltas will be greatly maximized if we batch updates)
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7344
5 years, 1 month
[releng] Issue #7455: Missing f28 dist-git branches
by Petr Pisar
ppisar reported a new issue against the project: `releng` that you are following:
``
Till now I found 4 packages that were missing f28 dist-git branches that should have been created at f28 branching time:
rpms/perl-Alien-Base-ModuleBuild
rpms/perl-Exporter-Easy
rpms/perl-Math-Utils
rpms/perl-Test-Exit
I worry there is some bug in the mass branching script and more packages are missing the f28 branch. Please recheck the repositories and create the branches where missing. (These four have already been fixed.)
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7455
5 years, 1 month
[releng] Issue #7439: Bodhi can now manage containers
by Randy Barlow
bowlofeggs reported a new issue against the project: `releng` that you are following:
``
Greetings!
Today I deployed Bodhi 3.6.0 to production, which adds support for containers (except for buildroot overrides). To make use of it, we just need to add container releases to Bodhi with all the appropriate Koji tags and we're off to the races. Doing so may or may not require Freeze Break Requests, not sure, but wanted to let you know that the feature is ready for your use as you see fit.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7439
5 years, 1 month
[releng] Issue #7405: [s390x] Latest cloud-base and (or) container images
are failing for F28 and rawhide composes
by Sinny Kumari
sinnykumari reported a new issue against the project: `releng` that you are following:
``
By looking into last few nightly composes for container and cloud on s390x, I observed that we never had all of the artifacts built successfully in a single compose.
For example:
* From Fedora-28-20180317.n.0 - cloud-base and container-minimal-base image built successfully. container-base image failed
* From Fedora-28-20180317.n.0 - cloud-base and container-base image built successfully. conatiner-minimal-base image failed.
Similar results from rest of the latest compose.
I did some local run of these images using imagefactory and each time following behavior has been seen:
* kernel.img and initrd files get downloaded, vm gets launched to start install process.
* vm boots and it reaches at
[ OK ] Reached target System Initialization.
[ OK ] Reached target Basic System.
[ 35.891858] dracut-initqueue[817]: RTNETLINK answers: File exists
[ 76.688981] random: crng init done
[ 427.634076] dracut-initqueue[817]: Warning: dracut-initqueue timeout - starting timeout scripts
---
[ 625.922797] dracut-initqueue[817]: Warning: dracut-initqueue timeout - starting timeout scripts
[ 625.923855] dracut-initqueue[817]: Warning: Could not boot.
Starting Dracut Emergency Shell...
Warning: /dev/root does not exist
dracut:/#
and vm install stops here.
Not sure what is the reason of this behavior. Can it be something related to network between s390x machine and koji ?
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7405
5 years, 1 month
[releng] Issue #7388: predicting dependency failures in image builds
by Dusty Mabe
dustymabe reported a new issue against the project: `releng` that you are following:
``
It would be nice if we could predict when dependency failures in image builds will happen. I have been using a rough set of commands to do this in the past few weeks but this could be polished up and put in place to forecast failures.
What I;ve been doing is:
`
dnf --releasever 29 --installroot /srv/installroot/ --disablerepo=* --enablerepo=today --enablerepo=koji install $(cat packages.txt | sed 's/^-/--exclude /' | tr '\n' ' ')
`
- where repo `today` is today's rawhide run
- where repo `koji` is the f29-build repo
- where packages.txt is the %packages list from a kickstart file
This is a pretty good indicator of failures.
This could be refined and put into a testing framework to run often. Steps: For each kickstart do:
- `ksflatten` kickstart file and get `%packages` list
- For groups use libcomps and fedora-comps repo to determine packages
- use koji `f29-build` repo and list of packages to determine if there are missing dependencies
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7388
5 years, 1 month
[releng] Issue #7379: Cannot install the python2-markdown RPM on Rawhide
because the module gets pulled in for some reason
by Randy Barlow
bowlofeggs reported a new issue against the project: `releng` that you are following:
``
Bodhi CI is failing to run on Rawhide because it cannot install python2-markdown. Instead of the RPM being present in the repository, the module for it is present instead and is signed with the wrong key:
```
$ sudo docker run --rm -it registry.fedoraproject.org/fedora:rawhide dnf install -y python2-markdown
Fedora - Rawhide - Developmental packages for the next Fedora release 3.0 MB/s | 60 MB 00:19
Last metadata expiration check: 0:00:21 ago on Wed Mar 7 17:12:37 2018.
Dependencies resolved.
===================================================================================================================================================================================================================
Package Arch Version Repository Size
===================================================================================================================================================================================================================
Installing:
python2-markdown noarch 2.4.1-11.module_0b083f9b rawhide 189 k
Installing dependencies:
python2 x86_64 2.7.14-13.fc29 rawhide 101 k
python2-libs x86_64 2.7.14-13.fc29 rawhide 6.3 M
python2-pip noarch 9.0.1-16.fc29 rawhide 1.8 M
python2-setuptools noarch 38.4.0-3.fc28 rawhide 622 k
Transaction Summary
===================================================================================================================================================================================================================
Install 5 Packages
Total download size: 9.0 M
Installed size: 36 M
Downloading Packages:
(1/5): python2-markdown-2.4.1-11.module_0b083f9b.noarch.rpm 513 kB/s | 189 kB 00:00
(2/5): python2-2.7.14-13.fc29.x86_64.rpm 274 kB/s | 101 kB 00:00
(3/5): python2-setuptools-38.4.0-3.fc28.noarch.rpm 743 kB/s | 622 kB 00:00
(4/5): python2-pip-9.0.1-16.fc29.noarch.rpm 942 kB/s | 1.8 MB 00:01
(5/5): python2-libs-2.7.14-13.fc29.x86_64.rpm 1.1 MB/s | 6.3 MB 00:05
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total 1.4 MB/s | 9.0 MB 00:06
warning: /var/cache/dnf/rawhide-2d95c80a1fa0a67d/packages/python2-markdown-2.4.1-11.module_0b083f9b.noarch.rpm: Header V3 RSA/SHA256 Signature, key ID a3cc4e62: NOKEY
Importing GPG key 0x429476B4:
Userid : "Fedora 29 (29) <fedora-29(a)fedoraproject.org>"
Fingerprint: 5A03 B4DD 8254 ECA0 2FDA 1637 A20A A56B 4294 76B4
From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-29-x86_64
Key imported successfully
Import of key(s) didn't help, wrong key(s)?
Public key for python2-markdown-2.4.1-11.module_0b083f9b.noarch.rpm is not installed. Failing package is: python2-markdown-2.4.1-11.module_0b083f9b.noarch
GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-29-x86_64
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: GPG check FAILED
```
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7379
5 years, 1 month
[releng] Issue #7354: apitrace-libs.i686 version mismatches
apitrace-libs.x86_64 on F27
by Sandro Mani
smani reported a new issue against the project: `releng` that you are following:
``
On F27 the current version of apitrace is apitrace-7.1-7.fc27.
On F27 x86_64 however,
# dnf install --refresh apitrace-libs.i686
currently gives you apitrace-libs-7.1-7.fc27.i686 (note: -7 instead of -9). On the other hand,
# dnf install --refresh apitrace-libs
gives you apitrace-libs-7.1-9.fc27.x86_64 as expected.
apitrace-libs is multilib whitelisted, but appears to be out of sync.
See also #1541099.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7354
5 years, 1 month