[releng] Issue #7340: rebuild packages that require old boost
by Dusty Mabe
dustymabe reported a new issue against the project: `releng` that you are following:
``
There are quite a few packages in rawhide that require an old version of boost. They probably need to be rebuilt. I used this command to determine what needs to be built: `(dnf repoquery --queryformat '%{SOURCERPM}' --whatrequires 'libboost_system.so.1.64.0()(64bit)'; dnf repoquery --queryformat '%{SOURCERPM}' --whatrequires 'libboost_system.so.1.64.0') | sort | uniq`:
```
[root@f28vanilla ~]# (dnf repoquery --queryformat '%{SOURCERPM}' --whatrequires 'libboost_system.so.1.64.0()(64bit)'; dnf repoquery --queryformat '%{SOURCERPM}' --whatrequires 'libboost_system.so.1.64.0') | sort | uniq
Repository rawhide-debuginfo is listed more than once in the configuration
Repository rawhide-source is listed more than once in the configuration
Last metadata expiration check: 2:59:00 ago on Wed 21 Feb 2018 10:58:30 AM UTC.
Repository rawhide-debuginfo is listed more than once in the configuration
Repository rawhide-source is listed more than once in the configuration
Last metadata expiration check: 2:59:00 ago on Wed 21 Feb 2018 10:58:30 AM UTC.
blender-2.79-6.fc28.src.rpm
cpp-hocon-0.1.6-3.fc28.src.rpm
dmlite-0.8.8-6.fc28.src.rpm
dynafed-1.3.1-8.fc28.src.rpm
ember-0.7.2-22.fc27.src.rpm
facter-3.9.3-1.fc28.src.rpm
fawkes-1.0.1-13.fc28.src.rpm
gazebo-8.1.1-4.fc28.src.rpm
grass-7.2.1-2.fc27.src.rpm
libkolab-1.0.2-9.fc27.src.rpm
liblsl-1.12.0-1.fc28.src.rpm
libndn-cxx-0.4.1-8.fc27.src.rpm
LuxRender-1.6-26.fc28.src.rpm
mrpt-1.4.0-6.fc28.src.rpm
nodejs-mapnik-3.6.2-5.fc27.1.src.rpm
ompl-1.3.2-1.fc28.src.rpm
openvdb-4.0.2-1.fc28.src.rpm
openvibe-1.1.0-7.fc27.src.rpm
orthanc-1.3.0-4.fc28.src.rpm
player-3.1.0-4.fc27.src.rpm
pokerth-1.1.1-27.fc28.src.rpm
rospack-2.0.14-18.fc27.src.rpm
spring-100.0-13.fc28.src.rpm
swift-3.0-0.12.rc2.fc27.src.rpm
tomahawk-0.8.4-18.fc28.src.rpm
uwsgi-2.0.15-7.fc28.src.rpm
votca-xtp-1.4.1-1.fc28.src.rpm
wesnoth-1.13.10-1.fc28.src.rpm
wt-3.3.7-5.fc27.src.rpm
```
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7340
6 years
[releng] Issue #7398: Make Rawhide repository handling more suitable for
automated processing
by Kamil Páral
kparal reported a new issue against the project: `releng` that you are following:
``
**Background**
I've been working on Fedora QA automation for many years. All these years, I've had to fight with the way how Fedora structures its repositories especially regarding Rawhide. I can't even count in how many tools we needed to define the current Rawhide <-> `$releasever` mapping and maintain that mapping. That includes special paths for Rawhide (or Branched) in terms of repository location. Today I finally forced myself to file this ticket and ask Releng for improving this from their side (while maintaining full compatibility with existing approaches).
**Problem**
Currently, `$releasever` and repository handling uses a completely different approach for stable releases, Branched and Rawhide.
Stable releases use `$releasever` NN number when accessing repos, either over mirrormanager:
https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$...
or directly using a repo path:
http://dl.fedoraproject.org/pub/fedora/linux/releases/$releasever/
They have `fedora`, `updates` and `updates-testing` system repos defined.
Branched release uses `$releasever` for mirrormanager and for repo path, but it's placed in `development/` directory rather then `releases/`:
http://dl.fedoraproject.org/pub/fedora/linux/development/$releasever/
It has `fedora`, `updates` (empty) and `updates-testing` (empty or used, depending on release schedule) system repos defined.
Rawhide *doesn't* use `$releasever` neither for mirrormanager nor for repo path, and it's again placed in `development/`:
http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/
It has `rawhide` system repo defined (no `fedora`, `updates` or `updates-testing`).
Due to Rawhide not using `$releasever`, it needs to have its custom set of repository files (and a differently named base repo), which point to the "right" mirrormanager and baseurl URLs.
So in conclusion, this is the list of things that don't work:
* Accessing a particular release repo path without the knowledge of its current status (some are in `development/`, some are in `releases/`).
* Accessing Rawhide repo using `$releasever` (which **is** provided by the system, just doesn't work), in particular:
https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$...
http://dl.fedoraproject.org/pub/fedora/linux/development/$releasever/
All these are not accessible.
* Using the same repository config file in any Fedora release, making use of `$releasever` in URLs (breaks on Rawhide). This doesn't involve only Fedora repo files, but also any third-party repo files.
* Querying other releases' repodata from Rawhide, by using `dnf --releasever=` (because repo URLs are hardcoded to Rawhide).
* Using commands like `dnf --enablerepo=updates-testing` from Rawhide.
The consequence of all of this is that our tools are littered with if clauses, doing special things for Rawhide (and sometimes Branched). We need to have separate configs for different releases, often [quite complicated](https://pagure.io/taskotron/libtaskotron/blob/8a7f76c5a336d0b8e5ec99d7996b3baf39c4ddb0/f/conf/yumrepoinfo.conf.example). We can't use the same additional repositories in all releases. We need to do hacks to figure out if a provided disk image is Rawhide or not, or deciding if we're running on Rawhide release during runtime. And the worst of all, we need to maintain all of this and reconfigure it several times per year (branching, going stable). This is error-prone, tedious and causes a delay during which things crash or provide incorrect results (e.g. between the branching happens and the configs are updated and deployed).
I'd like all of these issue to go away, and be maintenance free.
**Proposed solution**
1) Teach mirrormanager to recognize both `rawhide` and its matching `$releasever` at the same time. When Rawhide is 29, these two URLs should return the same content:
https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-rawhide&arch=x86_64
https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-29&arch=x86_64
2) Create empty `updates` and `updates-testing` repositories for rawhide. These repos will be forever empty. Make them exposed in mirrormanager again under both names (29 and rawhide). This will allow to use the same DNF commands in stable releases and in Rawhide without side-effects.
3) Create a directory in repo layout that contains symlinks to all releases regardless of their release status. For example let's create
http://dl.fedoraproject.org/pub/fedora/linux/releases/all
showing this content:
```
linux/
├── development
│ ├── 28
│ ├── 29 -> rawhide
│ └── rawhide
└── releases
├── 26
├── 27
└── all
├── 26 -> ../26
├── 27 -> ../27
├── 28 -> ../../development/28
├── 29 -> rawhide
└── rawhide -> ../../development/rawhide
```
As you can see, all releases are addressable from there. Not only that, but when Rawhide is 29, both these names are included and translate to the same target. This is important, because it allows people to use `$releasever` everywhere.
4) Have a `$releasever` number symlink also for `updates` and `updates/testing` paths:
```
linux/
└── updates
├── 26
├── 27
├── 28
├── 29 -> rawhide
├── rawhide
└── testing
├── 26
├── 27
├── 28
├── 29 -> rawhide
└── rawhide
```
**Future improvements**
The changes proposed above would improve the situation immensely for me, and for other developers/tool authors interacting with releases in a similar fashion. But when this is in place, other, releng-related improvements could be achieved. For example, `fedora-repos-rawhide` could be got rid of. Currently you need to maintain two different set of repos, one for rawhide and one for others. With the above changes, you could use the same repos for all releases, i.e. `fedora`, `updates` and `updates-testing`. The last two would be empty for rawhide. The base repo would automatically work using `$releasever`. However, this way the release would follow the `$releasever` even after branching happens, so people running Rawhide would suddenly run Branched. That might not be desired, and could be solved by `fedora-repos-rawhide` containing just a single file - a config drop-in for DNF, that would override `$releasever` to `rawhide` (this part would need to be implemented, because it seems it's not possible today). With this approach, just by installing `fedora-repos-rawhide`, the users would make sure they always stay on Rawhide. The package contents would never need to be updated, same as `fedora-repos` wouldn't. Everything would work without regular maintenance.
CC @ausil @kevin @puiterwijk @dmach @jskladan @tflink @adamwill
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7398
6 years
Fedora Release Engineering Meeting Summary for 2018-04-05
by Mohan Boddu
======================================
#fedora-meeting-2: RELENG (2018-04-05)
======================================
Meeting started by mboddu at 17:00:00 UTC. The full logs are available
athttps://meetbot.fedoraproject.org/fedora-meeting-2/2018-04-05/releng.20...
.
Meeting summary
---------------
* init process (mboddu, 17:00:01)
* Roll Call (mboddu, 17:00:43)
* #7403 Consider no longer producing the Workstation repo tree in
composes (mboddu, 17:08:38)
* LINK: https://pagure.io/releng/issue/7403 (mboddu, 17:08:45)
* nirik will file a ticket against Workstation-WG and based on the
input we get from the WG we will make necessary decisions (mboddu,
17:19:48)
* #7398 Make Rawhide repository handling more suitable for automated
processing (mboddu, 17:22:40)
* LINK: https://pagure.io/releng/issue/7398 (mboddu, 17:22:46)
* mboddu will close the ticket for now and ask Kamil to reopen the
ticket if he needs anymore help (mboddu, 17:30:56)
* Alternate Architecture Updates (mboddu, 17:32:06)
* Open Floor (mboddu, 17:35:52)
Meeting ended at 17:39:08 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* mboddu (55)
* nirik (26)
* masta (14)
* Kellin (14)
* zodbot (5)
* tyll (0)
* puiterwijk (0)
* pbrobinson (0)
* pingou (0)
* dgilmore (0)
* maxamillion (0)
* sharkcz (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
6 years
[releng] Issue #7360: Bugzilla Assignee Overrides: text unclear
by Nikos Mavrogiannopoulos
nmav reported a new issue against the project: `releng` that you are following:
``
I'm reading the following text [from the fedora-scm-requests project](https://pagure.io/releng/fedora-scm-requests).
```
To override the default assignee in Bugzilla, find/or create the YAML file that configures the
repository you want to set (e.g. rpms/python-requests). The bugzilla_contact key in the YAML file is
used to override this with a dictionary, where each key represents a product (e.g. "Fedora EPEL" or
"Fedora"). Each value should specify the FAS username or FAS group (groups are signified by
starting with a "@") of the default Bugzilla ticket assignee for the component in that product.
```
It is unclear to me what to do to override the bugzilla assignee. Questions I have:
* How to find or create the yaml file?
* Where does it have to be (in the package repo), subdir?
* Does it have to have a specific name or any yaml file would do?
* Could you give an example of such a file?
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7360
6 years
[releng] Issue #7420: Block gnome-tweak-tool in F28
by Kalev Lember
kalev reported a new issue against the project: `releng` that you are following:
``
I did 'fedpkg retire' for gnome-tweak-tool f28 and master branches on 2018-03-20, but it only got blocked in f29 in koji, but not in f28.
Please ensure that it's also blocked in f28.
```
$ koji list-history --package gnome-tweak-tool
Wed Mar 21 06:17:48 2018 package list entry for gnome-tweak-tool in f29 updated by releng
blocked: False -> True
Thu Mar 29 21:33:37 2018 package list entry created: gnome-tweak-tool in f28-Beta by mohanboddu [still active]
Thu Mar 29 21:40:58 2018 gnome-tweak-tool-3.27.3-3.fc28 tagged into f28-Beta by mohanboddu [still active]
```
Thanks,
Kalev
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7420
6 years
[release] pungi 4.1.23
by Lubomír Sedlář
Hello everyone,
a new version of Pungi is available! The 4.1.23 build is ready to be
used. Updates are filed and waiting to get into updates-testing.
Many of the fixes in this release have already been backported into
Fedora package.
Most important changes in this release are:
* There is now a metadata file describing the modules that are
included in the compose.
* Multilib packages in modules should not be included correctly.
* Modules can be retrieved from a Koji tag and not just from PDC
* Instead of Python modulemd library Pungi now depends on libmodulemd.
* Ostree creation now consumes packages from the same repository that
buildinstall phase does. This means it can run earlier in the
process, in parallel to solving dependencies and creating
repositories for each variant.
* It is now possible to configure gathering separately for each
variant and include packages from multiple sources. Modular
and non-modular packages do not mix.
As always, there are other minor fixes.
Refer to the documentation [1] for details on what configuration
options are available.
[1] https://docs.pagure.org/pungi/index.html
If you encounter problems or need general help, stop by #fedora-releng
IRC channel or file issues in Pagure.
Happy composing!
Lubomír
6 years
