DevHeads.net

Postings by =?ISO-8859-2?Q?Miroslav_Such=FD?=

requesting feedback on Mock default

Hi,
you - fedora developers - are most significant users of Mock. Therefore I would like to ask you about feedback on:

<a href="https://github.com/rpm-software-management/mock/issues/266" title="https://github.com/rpm-software-management/mock/issues/266">https://github.com/rpm-software-management/mock/issues/266</a>

The summary is:
Previously all output - both stdout and stderr - were mixed together. Like you will get on normal console.
Nowadays, if there is output to stderr, mock will prefix it with BUILDSTDER to indicate that it is coming from stdout.

I can definitely make this configurable. That is easy. The question is, what should be the default?

Fedora GPG keys

Can someone enlighten me what happened to:
<a href="https://getfedora.org/keys/" title="https://getfedora.org/keys/">https://getfedora.org/keys/</a>
? There used to be GPG keys of Fedora, but now it just return 404.

dist-git

I would like to ask what is status of dist-git in CentOS? Do you use it is as bunch of packages or as package?

Originally dist-git was just bunch of packages copied to propper places. But since we started using dist-git in Copr we
packaged it:
<a href="https://koji.fedoraproject.org/koji/packageinfo?packageID=20308" title="https://koji.fedoraproject.org/koji/packageinfo?packageID=20308">https://koji.fedoraproject.org/koji/packageinfo?packageID=20308</a>
and gave it propper upstream:
<a href="https://github.com/release-engineering/dist-git" title="https://github.com/release-engineering/dist-git">https://github.com/release-engineering/dist-git</a>

Copr and Fedora now use this package.

/etc/yum.repos.d -> /etc/distro.repos.d

Hi,
I am curious whether we can move our repo files from
/etc/yum.repos.d
to
/etc/distro.repos.d

In Fedora 31 we are going to wipe away last left overs of YUM, so it really does not have sense to keep `yum.repos.d`.

DNF for ages parse config files from:
{"/etc/yum.repos.d", "/etc/yum/repos.d", "/etc/distro.repos.d"}
Therefore the move of repo files does not require any change in DNF. It should be just change in fedora-repos.
If anyone put his private repos to /etc/yum.repos.d then DNF will parse it too.

RHEL8 and Mageia7 available in Copr

Hi,
I just added those chroots to Copr:
rhelbeta-8-x86_64
mageia-7-i586
mageia-7-x86_64

Please be aware that there is no available EPEL for rhelbeta-8-x86_64 yet.

Fedora 30 added to FAF

Hi,
I added Fedora 30 to
<a href="https://retrace.fedoraproject.org/faf/summary/" title="https://retrace.fedoraproject.org/faf/summary/">https://retrace.fedoraproject.org/faf/summary/</a>

Reporting from Fedora 30 works now and you should start to issues from Fedora 30 there.

Miroslav

Donate 1 minute of your time to test upgrades from F29 to F30

Do you want to make Fedora 30 better? Please spend 1 minute of your time and try to run:

sudo dnf --releasever=30 --setopt=module_platform_id=platform:f30 --enablerepo=updates-testing distro-sync

If you get this prompt:

...
Total download size: XXX M
Is this ok [y/N]:

you can answer N and nothing happens, no need to test the real upgrade. Upgrades will be fine for you.

But very likely you get some dependency problem now.

Broken modules on rawhide

<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1680320#c2" title="https://bugzilla.redhat.com/show_bug.cgi?id=1680320#c2">https://bugzilla.redhat.com/show_bug.cgi?id=1680320#c2</a>

When you try to run:
mock -r fedora-rawhide-x86_64 shell

You will get:
Problem 1: conflicting requests
- nothing provides module(platform:f30) needed by module stratis:1:20181215204600:a5b0195c-0.x86_64
Problem 2: conflicting requests
- nothing provides module(platform:f30) needed by module standard-test-roles:3.0:3020190214144451:a5b0195c-0.x86_64
....

rawhide has module_id=platform:f31.

When will be all rawhide modules rebuild? Or what is the solution for this? Because right now all rawhide modules are
basically broken.

Orphaning glacier-cli

Hi,
I just orphaned `glacier-cli` package.

It is command line utility for AWS Glacier service.

rhel 8 beta mock configs and EOLed mock configs

Hi,
I just released [1] new mock-core-config package which include new
rhelbeta-8-* configs.
This will allows you to build packages on top of RHEL 8 Beta. This is
temporary config.

how to detect Atomic Rawhide?

Hi,
in DNF's Copr plugin we are detecting whether you are running in Rawhide or not, so we can enable you rawhide chroot (or
numbered).

We use this code:

import distro
distro.linux_distribution(full_distribution_name=False)

which returns triplet:
('Fedora', '30', 'Rawhide')
('Fedora', '29', 'Workstation Edition')

where the third string is taken from /etc/os-release
VERSION="30 (Rawhide)"
VERSION="29 (Workstation Edition)"

it is the string in parentheses. If there is a rawhide, we think that the system is rawhide.

DNF and Modularity

Hi,
I have to admit that I am a bit puzzled about DNF behavior with modularity.

I have installed repo files with modularity repos, but all of them are disabled. I have no module enabled on my system
(F29 BTW).

Retiring pgtune

I want to retire pgtune
<a href="https://src.fedoraproject.org/rpms/pgtune" title="https://src.fedoraproject.org/rpms/pgtune">https://src.fedoraproject.org/rpms/pgtune</a>

The original upstream is dead and python2 only:
<a href="https://github.com/gregs1104/pgtune" title="https://github.com/gregs1104/pgtune">https://github.com/gregs1104/pgtune</a>

There is a new upstream based on the original version:
<a href="https://github.com/le0pard/pgtune" title="https://github.com/le0pard/pgtune">https://github.com/le0pard/pgtune</a>

But it is far of being simple. It is made in ruby and node.js. And I do not want to maintain it.
Additionally is is no more command line tool, but web service, which is available online as well:
<a href="https://pgtune.leopard.in.ua/#/" title="https://pgtune.leopard.in.ua/#/">https://pgtune.leopard.in.ua/#/</a>

If you want to take over take this package - not sure why - then please contact me.

fedora-messaging for Copr - what do you need?

As part of migration of fedmsg from ZMQ to AMQP, I would like to revisit what is Copr sending to fedmsg.

Right now we are sending:

'build.start': {
'what': "build start: user:{user} copr:{copr}" \
" pkg:{pkg} build:{build} ip:{ip} pid:{pid}",
},
'chroot.start': {
'what': "chroot start: chroot:{chroot} user:{user}" \
" copr:{copr} pkg:{pkg} build:{build} ip:{ip} pid:{pid}",
},
'build.end': {
'what': "build end: user:{user} copr:{copr} build:{build}" \
" pkg:{

Multi-arch support in Mock

Hi,
I just pushed into updates-testing new release of Mock (1.4.11). It has nice new feature:

$ sudo dnf install qemu-user-static # weak dependency
$ mock -r fedora-28-ppc64le --forcearch ppc64le shell

This will give you Fedora shell on different architecture. Emulated by QEMU. And of course you can build packages for
the different architectures this way.
You can do this for any architecture: aarch64, armhfp, ppc64, ppc64le, s390x.

People are asking me how much slower it is.

Change in Copr retention policy?

Hi,
I would like to open discussion about Copr retention policy change.

Right now we have:

This means that we still have repos for fedora-18-* and epel-5-*.

Is this reasonable? Or are we just wasting storage?

heads up: mock's fedora-29-x configs

I just released new `mock-core-configs` and there is a new feature.

It contains:

$ ls -l /etc/mock
...
lrwxrwxrwx. 1 root mock 26 May 2 09:13 fedora-29-aarch64.cfg -> fedora-rawhide-aarch64.cfg
lrwxrwxrwx. 1 root mock 25 May 2 09:13 fedora-29-armhfp.cfg -> fedora-rawhide-armhfp.cfg
lrwxrwxrwx. 1 root mock 23 May 2 09:13 fedora-29-i386.cfg -> fedora-rawhide-i386.cfg
lrwxrwxrwx. 1 root mock 24 May 2 09:13 fedora-29-ppc64.cfg -> fedora-rawhide-ppc64.cfg
lrwxrwxrwx. 1 root mock 26 May 2 09:13 fedora-29-ppc64le.cfg -> fedora-rawhide-ppc64le.cfg
lrwxrwxrwx.

Orphaning some Spacewalk packages

I am going to orphan some Spacewalk packages:
perl-Satcon
spacewalk-proxy-html
spacewalk-proxy-docs
spacewalk-config

They does not have sense to be in Fedora without additional Spacewalk packages. They live in Copr repos. But if anyone
want it, feel free to grab it.

Miroslav

Clean up your spec files

Hi,
I am sometimes reviewing spec files and I very often see common mistakes. I mean in packages which are already in
Fedora. For a long time and they have some dust from past times.

I am not going to file bug reports as those are not bugs. I will just point it here and leave it up to you to check your
spec files:

* Group: System Environment/Base

Please remove it. Group was intended for something (sort apps in menus), but it never actually worked. It was required
for EL5 packages. Since EL6 it can be omitted.

Orphaning some Spacewalk packages

I orphaned
rhnmd
This is Spacewalk package which is not developed any more.

And I orphaned
perl-Socket-MsgHdr
perl-Crypt-GeneratePassword
as I these are not used in Spacewalk as well.

Miroslav

Remove old GPG keys?

I just stumbled upon
<a href="https://unix.stackexchange.com/questions/400634/does-anyone-bother-to-remove-rpmkeys" title="https://unix.stackexchange.com/questions/400634/does-anyone-bother-to-remove-rpmkeys">https://unix.stackexchange.com/questions/400634/does-anyone-bother-to-re...</a>
with the nice link to:
<a href="https://blog.laimbock.com/2014/05/02/how-to-remove-an-imported-gpg-key-from-rpm/" title="https://blog.laimbock.com/2014/05/02/how-to-remove-an-imported-gpg-key-from-rpm/">https://blog.laimbock.com/2014/05/02/how-to-remove-an-imported-gpg-key-f...</a>
And I wonder: is it a good idea to keep old gpg keys in RPM db? Or should we automate the removal of old keys?

Mirek

Pagure token only 2 months?!

Hi,
I recently added new package to Fedora and went through the new process which uses:
fedrepo-req-branch
See
<a href="https://pagure.io/fedrepo_req/blob/master/f/README.md" title="https://pagure.io/fedrepo_req/blob/master/f/README.md">https://pagure.io/fedrepo_req/blob/master/f/README.md</a>
I have been surprised that you first need to configure this tool.

CI projects in Copr

Hi,
I am gathering informations about various use of CI with Copr. Do you use Copr for building packages for nightlies? For
building packages before pull request is merged? Do you have your set up described somewhere? What is the name of your
project?

Please let me know. Either here or via private reply.
It will help me to understand your use of Copr and to make Copr better.

Thanks in advance.

Miroslav Suchy

Orphaning several rubygem-* packages

Hi,
I just orphaned several packages:
rubygem-ttfunk
rubygem-xmlhash
rubygem-wirb
rubygem-unicode-display_width
rubygem-single_test
rubygem-ruby-rc4
rubygem-robotex
rubygem-rkerberos
rubygem-paint
rubygem-mobileesp_converted
rubygem-hoptoad_notifier
rubygem-foreman_api
rubygem-fast_xs
rubygem-Ascii85

I do not use them and I want to focus more on my other packages.
Feel free to grab them.

`best=1` in new Mock

Hi,
I just released new version of Mock. And I want to quote one important
change from the release notes so everyone is aware of it:

<a href="https://github.com/rpm-software-management/mock/wiki/Release-Notes-1.3.3" title="https://github.com/rpm-software-management/mock/wiki/Release-Notes-1.3.3">https://github.com/rpm-software-management/mock/wiki/Release-Notes-1.3.3</a>

All chroot (but rawhide) configs now contains best=1.
This way DNF will always try to install latest package. If its
dependence cannot be satisfied DNF will report an error.

F25 Server cloud image

I just wanted to download F25 Cloud image for OpenStack and was surprised that there is none. There is just Atomic image.
But Atomic use rpm-ostree for installing packages. There is no DNF. However I cannot find any module for rpm-ostree for
Ansible.

Am I missing something? What should I install nowdays when I am using Ansible for managing configuration?

Mock and Copr are failing for epel-*

Hi everybody.
Some of you noticed that Copr (and mock-1.2.19) is failing to initialize epel-* buildroots. It errors with incorrect gpg
signature for some package.
It is my fault.
Epel configs use Centos and Epel gpg keys. In the 1.2.19 release I used just Centos keys - even for the Epel repository.
Which results in the error.

I am preparing new release (1.2.20), which should land in bodhi in few minutes.

I am sorry for this error I made.

Improvements of Fedora Sponsorship process

I had the talk [1] about Fedora Sponsorship process at Flock. And we had
very interesting follow-up discussion.

We come up with several improvements, which should be easy to implement
and may improve the process a lot. I am posting it here so more people
can see that and join the discussion.

a) Sponsoree (who apply for package maintainer status) is required to
create Copr project and maintain the package there until he get the
package into Fedora. This should show his endurance to sponsors.

Unable to package lots of rubygems in Copr due missing license

Hi,
I started rebuilds of whole rubygems.org as RPM packages in Copr.
See:
<a href="https://copr.fedorainfracloud.org/coprs/g/rubygems/rubygems/" title="https://copr.fedorainfracloud.org/coprs/g/rubygems/rubygems/">https://copr.fedorainfracloud.org/coprs/g/rubygems/rubygems/</a>

However lots of gems cannot be imported due licensing problems.
Such gems fail with this dist-git log:
<a href="http://copr-dist-git.fedorainfracloud.org/per-task-logs/320374-f24.log" title="http://copr-dist-git.fedorainfracloud.org/per-task-logs/320374-f24.log">http://copr-dist-git.fedorainfracloud.org/per-task-logs/320374-f24.log</a>

And quoting from this link:

15 thousands python3-* packages for Fedora

Hi,
I just finished packaging of 15 634 python3-* packages for Fedora.
<a href="https://copr.fedorainfracloud.org/coprs/g/copr/PyPI3/" title="https://copr.fedorainfracloud.org/coprs/g/copr/PyPI3/">https://copr.fedorainfracloud.org/coprs/g/copr/PyPI3/</a>
You can click on Builds and Monitoring tab. But be aware that those
pages are HUGE (40MB) and they are loading and rendering several
minutes. Tab "Packages" is timeouting and this will be fixed in next
release.

I am now building python2-* packages too:
<a href="https://copr.fedorainfracloud.org/coprs/g/copr/PyPI2/" title="https://copr.fedorainfracloud.org/coprs/g/copr/PyPI2/">https://copr.fedorainfracloud.org/coprs/g/copr/PyPI2/</a>

This is only for rawhide and for statistic purposes, but there will be
more.