DevHeads.net

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

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

Do you want to make Fedora 31 better? Please spend 1 minute of your time and try to run [*]:

sudo dnf --releasever=31 --setopt=module_platform_id=platform:f31 --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 actual upgrade.

But very likely you get some dependency problem now. In that case, please report it against the appropriate package. Or
against fedora-obsolete-packages if that package should be removed in Fedora 31.

Copr retention policy has been changed

Hi.
Copr is running out of space. No need to panic.

New release of Mock (fixes and subscription-manager support)

Hi,
I released new version of Mock and mock-core-configs. For full release notes see:
<a href="https://github.com/rpm-software-management/mock/wiki/Release-Notes-1.4.18" title="https://github.com/rpm-software-management/mock/wiki/Release-Notes-1.4.18">https://github.com/rpm-software-management/mock/wiki/Release-Notes-1.4.18</a>
I just submitted packages to Bodhi.

I would like to point two things here:

1) It should fixes all those issues you reported in past days (selinux, rprivate, groupadd).
2) Mock now supports subscription-manager, which allows you to build packages for RHEL with cost-free developer license.
No need to wait for CentOS 8.

Big thanks to Pavel Raiskup who done those two things.

Projects in Copr @ discussion.f.o

Hi,
I want to soon enable embedded discussion on Copr projects pages.

ownership of /proc and /sys

Hi,
directories /proc/ and /sys/ are owned by filesystem package. This worked in past where we needed those directories to
exist so we can mount the procfs and sysfs.

However this cause issues in containers:
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1548403" title="https://bugzilla.redhat.com/show_bug.cgi?id=1548403">https://bugzilla.redhat.com/show_bug.cgi?id=1548403</a>
and during building where hacks are needed:
<a href="https://github.com/rpm-software-management/mock/pull/234/commits/d7e0b413c83bec00fd1ed75ee15122a9cc6db62e" title="https://github.com/rpm-software-management/mock/pull/234/commits/d7e0b413c83bec00fd1ed75ee15122a9cc6db62e">https://github.com/rpm-software-management/mock/pull/234/commits/d7e0b41...</a>

I have bunch of ideas, but all of them ugly (e.g., not own that file and create that directories in scriptlet). Do you
have any ideas about this situation?

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.