I want to sum up what happened in Copr during 2019. At the end of this email, you can see our TODO list and cast your
vote on what we should focus on.
During the year 2019:
* we added native AARCH64 builders
* we added emulated ARMhfp builders
* released eight new versions of Mock including features as Jinja templates in configs, Dynamic BuildRequires,
subscription-manager support, which enables us to build on top of RHEL, Fedora Toolbox support, and container image
support which allows building using incompatible RPM.
To give credit - some of these Mock's features were contributed by community members.
* We removed outdated chroots, which allowed us to reclaim terabytes of disk space. At the same time, we give you the
option to keep those old repos if you want them.
* we provided RSS feed
* we added project discussions by integration with https://discussion.fedoraproject.org
* your project can be marked as temporary, and we delete it automatically after a specified amount of days. This is
great for CI projects.
* we migrated from fedmsg to fedora-messaging
* we provide anonymized DB dump so that you can play with our data
* you can pin your favorite projects now
* thanks to Amazon, we can use AWS for builders for free, which allowed us to use more builders.
* user Iucan rebuilds all R packages from CRAN for Fedora
* we are contributing to speed up createrepo_c, because that one is our biggest bottleneck. For projects like Cran or
python rebuilds, the createrepo task runs longer than the build of package and cannot be parallelized.
* Many interesting projects appeared in Copr and we wrote about them
* Added per-package config option to blacklist the package from building against particular chroots
* Added support for multilib projects https://pagure.io/copr/copr/issue/1181
* Refined modularity support, module dependency, module_hotfixes flags, ...
* Copr permissions can now be set via API and CLI.
* Removing old builds automatically, per option that only keeps a maximum number of builds per given package.
What are our plans for 2020? We have some mandatory tasks:
* migrate to new datacenter together with the whole fedora-infrastructure
* install and use new and bigger storage
Yet we have quite a long list of RFEs and tasks to do. As **you** are our customers, I would like to hear your opinion
on what is crucial for you.
Please cast your vote here:
* allow more parallel builds - everyone wants faster builds. I am afraid we cannot speed up the build itself, but we
can focus on allowing us to run more builds in parallel to handle peaks.
* Mock development - we spend a lot of time on Mock development. We utilize those new features in Copr, but they are
useful even for your local workflow with Mock. Should we spend more time on longstanding RFEs?
* build Flatpak application from your project - we have a viable idea how to build Flatpak app from your project with
just a few clicks, and we can upload the result to some registry. E.g., to https://quay.io/
* new commands for our API and copr-cli
* run lints like rpmlint or rpm-inspect after each build and give you hints on how to improve your spec files
* automatically rebuild PyPI and Rubygems - we already did this in the past, but we did not rebuild it for new Fedoras
* allow you to vote for quality of the project with thumbs up/down and high quality repos automatically promote and
will enable them as one big repo of "editors pick".
* focus on rpm spec generators - See https://docs.pagure.org/copr.copr/user_documentation.html#scm what we support
* add emulated architecture s390x - while we would like to add native architecture, it will likely not happen next
year, but we can do builds using QEMU.
* add RHEL as a target - right now you can build on top of CentOS, but we can allow you to build on top of RHEL
* better automatic builds triggered by GitHub, Gitlab, aka mimic the Copr CI we have for Pagure - git server sends
request - copr replies back with build status
* runtime dependency config between copr projects, so `dnf copr enable <user/foo>` enables other projects transitively
* something else - is something blocking you from using Copr? Please share it with us.
Please cast your vote here:
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
I'm Erich, the current project leader of Ubuntu Studio, the creativity-oriented flavor of Ubuntu. I've been leading that project for the past two years.
In that time, my team and I have taken Ubuntu Studio strides from where it was. However, due to some circumstances I will not mention here, we are looking for an alternative, and Fedora, with the Fedora Jam lab and with CCRMA's attention, seemed to be the perfect place to land. That said, it seems as though the Jam lab is dead, so I am here to revive it with mattdm's blessing.
We revamped a tool called Ubuntu Studio Controls (https://help.ubuntu.com/community/UbuntuStudio/UbuntuStudioControls), which makes audio configuration for Jack super simple. We wish to port that tool to Fedora, so I, with the help of another, will be working on packaging that, possibly naming it Studio Controls or Jam Controls.
I bring with me a team of people, including the primary developer of Ubuntu Studio Controls. We intend to make Jam a great project for musicians and audio engineers alike. I've been doing audio engineering for nearly 26 years, so this is an area that's completely within my wheelhouse.
In order to do the Self-Contained Change Request required, I need to be CLA+1, so that's the motivation behind joining the packaging group or whatever other group anyone feels is relevant to this project.
Thanks for reading!
Il giorno gio 24 ott 2019 alle ore 19:28 Strahil <hunter86_bg(a)yahoo.com> ha
> Hi Sandro,All,
> Can I upgrade the tools on existing VM , or it requires a fresh one? Best
If you have oVirt windows guest tools already installed suggestion is to
uninstall it before installing this new installer.
> Best Regards,
> Strahil Nikolov
> On Oct 24, 2019 14:35, Sandro Bonazzola <sbonazzo(a)redhat.com> wrote:
> as part of the work on oVirt 4.4, the team rewrote the VirtiIO Windows
> Drivers installer using the open source framework WiX.
> Thanks to the virtio-win maintainer, the new installer is not shipped
> anymore within oVirt Guest Tools ISO: it's shipped now directly into VirtIO
> Windows ISO
> Please give it a run on your testing environment / testing VMs and let us
> know about your experience at devel(a)ovirt.org.
> Sandro Bonazzola
> MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
> Red Hat EMEA <https://www.redhat.com/>
> <https://www.redhat.com/>*Red Hat respects your work life balance.
> Therefore there is no need to answer this email out of your office hours.*
MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
Red Hat EMEA <https://www.redhat.com/>
<https://www.redhat.com/>*Red Hat respects your work life balance.
Therefore there is no need to answer this email out of your office hours.
No idea where to report these:
| Notification time stamped 2020-01-30 09:55:53 UTC
| mschwendt pushed 1 commit to rpms/claws-mail (el6)
The requested URL was not found on the server. If you entered the URL manually please check your spelling and try again.
| Notification time stamped 2020-01-30 09:57:08 UTC
| mschwendt pushed 1 commit to rpms/claws-mail (epel7)
The requested URL was not found on the server. If you entered the URL
manually please check your spelling and try again.
Based on the latest fail to build from source policy, the following packages
will be retired from Fedora 32 approximately one week before branching (2020-02-03).
The packages in rawhide were not successfully built at least since Fedora 30.
This report is based on dist tags.
Packages collected via:
If you see a package that was built, please let me know.
If you see a package that should be exempted from the process, please let me
know and we can work together to get a FESCo approval for that.
There is an open exception request for shim-unsigned-aarch64 and
shim-unsigned-x64, but it has not yet been approved -- if it gains no negative
votes within 1 day, it will be:
If you see a package that can be rebuilt, please do so.
Package (co)maintainers Latest build
elasticsearch hubbitus, jvanek, lbazan, Fedora 24
expresso jamielinux, nodejs-sig, Fedora 28
libocrdma ocrdma Fedora 27
nuvola-app-google-calendar martinkg Fedora 29
nuvola-app-groove martinkg Fedora 28
nuvola-app-logitech-media- martinkg Fedora 29
nuvola-app-plex martinkg Fedora 29
nuvola-app-soundcloud martinkg Fedora 29
nuvola-app-yandex-music martinkg Fedora 29
shim-unsigned-aarch64 pjones (exception request) Fedora 28
shim-unsigned-x64 pjones (exception request) Fedora 28
The following packages require above mentioned packages:
Depending on: expresso (1)
nodejs-chrono (maintained by: jamielinux, nodejs-sig, tomh)
nodejs-chrono-1.0.5-10.fc31.src requires npm(expresso) = 0.9.2
martinkg: nuvola-app-soundcloud, nuvola-app-logitech-media-server,
nuvola-app-yandex-music, nuvola-app-groove, nuvola-app-google-calendar,
pjones: shim-unsigned-aarch64, shim-unsigned-x64
I've noticed these a few times now, and I have *no idea* where this is
coming from, for example:
dnf --releasever=rawhide --repo rawhide --repo rawhide-source
repoquery --source --requires python-pytest-harvest
python3dist(makefun) >= 1.5
Aaaaaand the "directory" and "removed" entries are obviously bogus.
Does anybody have an idea what's going on? Maybe a dependency
generator is still running while RPM is already cleaning up the build
Unison is a file synchronization tool written in OCaml. The binary
protocol isn't compatible from one major release to the next, so to
provide compatibility with the broader ecosystem of Unison on other
Linux distros we have 3 branches of it in Fedora:
unison213 (upstream release 2.13)
unison227 (upstream release 2.27)
unison240 (upstream release 2.40)
We don't package upstream releases 2.48 or 2.5x in Fedora at all.
Anyway the news is that none of these branches can be compiled with
our OCaml 4.10.0-beta-1 compiler. For the past 5 years OCaml has been
introducing safe, immutable strings. This has required code changes
so was introduced gradually, but the last step happens next month when
OCaml 4.10.0 final is released. In OCaml 4.10 the -unsafe-string
option is disabled, so code must be updated to use immutable strings.
Even the upstream version of Unison has not been ported to use safe
strings (ie requiring the -unsafe-string option), never mind the older
branches that we're packaging.
I did attempt a safe string port and ... it's complicated. The code
does a lot of byte string manipulation all over the place using its
own custom functions with four letter function names, single letter
variable names, and no comments.
(Don't believe me? Here's the first function that would need to be
If we were to package Unison properly in Fedora (apart from fixing
the big mess above), I would prefer that we had a single unison
package which built multiple versioned unison subpackages. I had
a proof of concept of this a few years ago.
It looks as if Unison will be orphaned and retired unless someone who
cares persuades upstream to move to immutable strings and backport the
same work to the older branches.
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
I've recently updated my laptop to F31. Then I was no longer
able to ssh into it. After a little debugging... it turns
out my laptop was not getting the expected ip address
from DHCP. The reason for that was the MAC address it was
sending to dhcpd had change!!! Looking at the interfaces
bridge0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.31.1.175 netmask 255.255.0.0 broadcast 172.31.255.255
inet6 fe80::98f9:f0d0:4b79:cdaa prefixlen 64 scopeid 0x20<link>
ether 3a:00:66:8a:dd:b9 txqueuelen 1000 (Ethernet)
RX packets 259601 bytes 112149182 (106.9 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 256704 bytes 39319273 (37.4 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
enp0s31f6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether 8c:16:45:fe:c1:f1 txqueuelen 1000 (Ethernet)
RX packets 355186 bytes 134328851 (128.1 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 256743 bytes 40395059 (38.5 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 16 memory 0xec200000-ec220000
The bridge0 interface has as different MAC that the enp0s31f6 interface.
How can that be?? Esp when the hardware address (HWADDR=8C:16:45:FE:C1:F1)
is set in the ifcfg-bridge0_slave_1.
What has changed and where is the bridge MAC address coming from???
Just a few reminders for folks:
* If your package failed to build in the mass rebuild
( https://kojipkgs.fedoraproject.org/mass-rebuild/f32-failures.html )
and you want to fix it, please do so. Just do a normal commit/build
cycle for rawhide as you normally would. It should disappear from the
above list and no FTBFS bug will be filed.
* If you want to fix something else or update a package or whatever,
just do it as normal. The script that tags the mass rebuild back in will
see a newer build and not tag in the one from the mass rebuild.
* There were some failures on s390x at the beginning of the mass
rebuild. We will try and resubmit these after the mass rebuild is
done. You're welcome to resubmit them (make sure you resubmit or do a
new build in the f32-rebuild tag, not the normal tag) also anytime. The
above link should update and they will have no FTBFS filed for them.