#6261: Create secondary release staging SOP
-----------------------------+------------------------
Reporter: till | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 23 Final | Component: other
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
Should be similar to the one for primary I guess:
https://fedoraproject.org/wiki/Stage_final_release_for_mirrors
It came up when I noticed that the CHECKSUM files for secondary test
releases are not signed:
https://dl.fedoraproject.org/pub/fedora-
secondary/releases/test/23_Alpha/Server/ppc64le/iso/Fedora-Server-23
-ppc64le-CHECKSUM
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6261>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#6393: Bogus "broken dependencies in the rawhide tree" notifications
--------------------+------------------------
Reporter: ellert | Owner: rel-eng@…
Type: task | Status: new
Milestone: | Component: koji
Keywords: | Blocked By:
Blocking: |
--------------------+------------------------
Hi.
I keep getting copies of the following message.
```
root has broken dependencies in the rawhide tree:
On x86_64:
root-mathmore-5.34.32-8.fc24.x86_64 requires libgsl.so.0()(64bit)
On i386:
root-mathmore-5.34.32-8.fc24.i686 requires libgsl.so.0
Please resolve this as soon as possible.
```
This was fixed on 2016-04-11 with the successful build of
root-6.06.02-1.fc25
https://koji.fedoraproject.org/koji/buildinfo?buildID=753202
Since it was fixed I keep getting more copied of this message, so far 7 of
them. Why?
I first though that there was a "typo" in the message, and that it was
actually referring to Fedora 24, but this doesn't seem to be the case:
root-6.06.02-1.fc24 was pushed to stable yesterday, and I still got a new
copy of the message today.
Why do I get these messages still?
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6393>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#6372: secondary sync scripts have issues with src.rpm syncing
-----------------------------+------------------------
Reporter: kevin | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 24 Alpha | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
Mar 15 19:17:30 arm-hub01.qa.fedoraproject.org rsyncd[53390]: rsync:
change_dir "/development/rawhide/Everything/source/SRPMS/h" (in fedora-
arm) failed: No such file or directory (2)
arm appears to have a dir named 'tree' under source/ not SRPMS.
Mar 15 20:27:27 s390-koji01.qa.fedoraproject.org rsyncd[29705]: rsync:
link_stat "/updates/23/s390x/p/php-pecl-libsodium-1.0.2-1.fc23.src.rpm"
(in fedora-s390) failed: No such file or directory (2)
s390 src.rpms are in /updates/N/SRPMS/ not /updates/N/s390x/x/src.rpm
https://pagure.io/releng/blob/master/f/scripts/secondary-sync.py#_202 is
the script that does the syncing.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6372>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#6369: Please create a f24-gnome side tag
-----------------------------+------------------------
Reporter: kalev | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 24 Alpha | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
Hi,
Please create a new f24-gnome side tag and build target. We'll use it for
building GNOME megaupdates before submitting them to Bodhi, to help ensure
they don't cause issues in F24 proper while we're preparing the updates.
Thanks,
Kalev
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6369>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#6402: Bodhi is ignoring epoch
-----------------------------+------------------------
Reporter: jussilehtola | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 24 Final | Component: mash
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
Problem: bodhi seems to be ignoring epoch in the determination of obsolete
updates.
Full description:
There's an issue with segfaults in epson-inkjet-printer-escpr version
1.6.4. I updated the package to 1.6.5, and pushed out the update epson-
inkjet-printer-escpr-1.6.5-1.1lsb3.2.
However, I noticed that the file that was causing the crash had not been
changed from 1.6.4 to 1.6.5. So, I introduced Epoch 1, rolled back the
package to the 1.5.2 version, and pushed out the resulting epson-inkjet-
printer-escpr-1.5.2-3.1lsb3.2 as updates.
However, bodhi has marked the latter update, epson-inkjet-printer-
escpr-1.5.2-3.1lsb3.2 (epoch 1), as being obsoleted by epson-inkjet-
printer-escpr-1.6.5-1.1lsb3.2 (epoch 0). This should not happen, because
1:1.5.2-3.1lsb3.2 is newer than 0:1.6.5-1.1lsb3.2.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6402>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
Hello all,
I have been working on a proposal on how to handle Fedora's Docker
Registry requirements to deliver our future "docker-ized" content to users in
a way that won't leave us with a bottleneck to the user community hitting a
single download location. Below you will find that proposal and I would
greatly appreciate feedback. The good news is I did a small PoC of the plan
I would like to propose along with the workflow (simulating some steps in the
process for brevity), and it all worked! The potentially bad news is that
this introduces a reasonable amount of net-new services inside the Fedora
Infrastructure. I wanted to sanity-check this proposal with the Rel-Eng crew
and then send to the Infrastructure Team for feedback and advisement after
I'm sure this makes sense to everyone from a rel-eng perspective. Thank you
all in advance.
Quick vocab background for Docker stuff:
registry: a collection of docker image repositories
repository: named after an image and is a collection of multiple tags of
an that image
tag: an arbitrary string assigned to a specific docker image
(identified by the image's sha256 checksum)
NOTE: The "latest" tag is special and is assumed if no tag is
provided. This is true also for a 'docker pull' operation and
an image tagged "latest" will be the default image pulled by
users.
Proposal:
Pulp[0] + Crane[1] + MirrorManager[2] + Docker Distribution[3]
Pulp is a platform for managing repositories of content, such as software
packages, and making it available to a large numbers of consumers. It is also
capable of managing docker content.
Crane is a stand-alone python flask wsgi application written by the Pulp team
to serve as a API entry point for the docker client and will answer to an
user's 'docker pull'. It does not however create content manifests or provide
hosting for docker image content, instead it depends on someone creating the
manifest metadata themselves or having pulp publish it and serves 302
redirects to the docker client so they can find where the docker images
actually live.
I'll assume everyone here knows their way around MirrorManager.
Docker Distribution is the defacto standard open source implementation of the
Docker Registry V2 API spec[4]. It provides many features but the ability to
have it's back-end storage be provided by a "mirror network" much like the one
Fedora has at it's disposal is not one of them. The reason we need this in
place is because the mechanism by which you could push a docker image directly
to Pulp in Docker Registry v1 no longer exists in v2 so we must instead
perform a "sync" operation between the two. (This is a common problem for
all known "third party" v2 registry implementations).
Workflow:
OSBS will perform Builds, as these builds complete they will be pushed
to the docker-distribution (v2) registry, these will be considered
"candidate images". Pulp will sync and publish the candidate repository.
Testing will occur using the "candidate images" (details of how we want
to handle that are outside the scope of this proposal).
A "candidate image" will be marked stable once it's criteria have been
satisfied to do so. (This is vague because this is a topic of ongoing
discussion and work to decide what criteria an image will need to abide
by before being considered "stable" and promoted as such)
Once stable, pulp will publish that repository's content to a directory,
we will split that content and sync the image layers along with their
metadata to Mirror Manager master mirror. We will also sync the repo
metadata published by Pulp to somewhere Crane can pick it up. (This could
and will likely be something that Bodhi triggers via the Pulp REST API)
Mirror Manager will Pulp distribute to the mirrors the image layers and
their metadata.
Crane will get the new repository metadata and will serve redirects to
the new content relative to download.fedoraproject.org which will
perform another redirect (via MirrorManager) where the docker client
upon a "docker pull" will find it's content.
I have put together an ascii diagram in hopes that it will assist in seeing
the full picture.
https://maxamillion.fedorapeople.org/FedoraPulpDocker.txt
(I couldn't get it to paste cleanly into my email client)
If there are any questions, comments, or feedback please let me know.
Thank you,
-AdamM
[0] - http://www.pulpproject.org/
[1] - https://github.com/pulp/crane
[2] - https://github.com/fedora-infra/mirrormanager2/
[3] - https://github.com/docker/distribution/
[4] - https://docs.docker.com/registry/spec/api/
#6376: Missing administrators of several KDE packages
-----------------------------+------------------------
Reporter: dvratil | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 24 Alpha | Component: other
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
Hi,
shortly after group maintainership was introduced in pkgdb KDE SIG started
using it. At some point we submitted several new packages where we set
group::kde-sig as an owner. Back then pkgdb allowed that but the result is
that now we have a bunch of packages with only group::kde-sig having
approved ACLs and thus we are not able to add/approve new ACLs for them or
manage the packages.
Could you please add me (FAS dvratil) and Rex (FAS rdieter) as package
administrators to the packages below?
{{{
rpms/kaccounts-integration
rpms/kaccounts-providers
rpms/kde-cli-tools
rpms/kdecoration
rpms/kdeedu-data
rpms/kf5-kfilemetadata
rpms/kf5-kpackage
rpms/kf5-kpeople
rpms/kf5-kwayland
rpms/kf5-kxmlrpcclient
rpms/kf5-modemmanager-qt
rpms/kf5-networkmanager-qt
rpms/khelpcenter
rpms/khotkeys
rpms/kinfocenter
rpms/kio-extras
rpms/kmenuedit
rpms/ksysguard
rpms/kwrited
rpms/libkeduvocdocument
rpms/libkface
rpms/libkgeomap
rpms/libkscreen-qt5
rpms/libksysguard
rpms/plasma-nm
rpms/plasma-pk-updates
rpms/plasma-workspace-wallpapers
rpms/signon
rpms/signon-kwallet-extension
rpms/signon-plugin-oauth2
rpms/signon-ui
}}}
Thanks a lot.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6376>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project