Dear All,
I haven't used winswitch for a few years now, and haven't really got
the bandwidth to maintain the package, and so I plan to orphan it in
the coming week. Winswitch is developed by the same person as Xpra and
provides a front end to Xpra as well as other remote desktop
applications. I've cc'd the Xpra package owner in case he wants to
pick it up.
Cheers,
Jonathan

I updated the version of nodejs-qunitjs in Rawhide today, and it's license
has changed from "MIT and ASL 2.0" to "MIT". Previously, the entire
package was under the MIT license, with the exception of the src/diff.js
file, which was under the ASL 2.0 license. That file has since been
removed, and the entire package is now under the MIT license.
--
Jared Smith

Hello,
I'm intending to either orphan or better retire the following
packages.
python-wordpress-xmlrpc
python-mozbase
pymunin
feedstail
All of them can be considered dead upstream, and haven't seen
a release for loong time.
Takers? Otherwise I'll retire them in a week.
Matthias
--
Matthias Runge <mrunge(a)matthias-runge.de>

Hi everyone,
The DNF team is currently reviewing DNF compatibility with YUM 3 and we'd
like to get feedback on this one:
https://bugzilla.redhat.com/show_bug.cgi?id=1120253
rpmdb checksum is a checksum of all installed RPMs
It has no cryptographical value, it's just an unique ID of RPMs on a system
before and after each transaction and it's used in dnf history info and dnf
history list.
If checksums of 2 following transactions do not match, DNF indicates that.
This happens if a user installs an RPM by hand via rpm command.
Then `dnf history list` looks like:
2 | install bar | 2018-01-01 02:00 | Install | 2 <
1 | install foo | 2018-01-01 01:00 | Install | 7 >
the "<" and ">" characters indicate discontinuity in rpmdb hashes
Here's the question:
DNF computes the checksum from RPM N-E:V-R.A
while YUM computed it from E:N-V-R.A
We'd like to change the behavior to be compatible with YUM again.
This would create 1 discontinuity in rpmdb checksums in the history,
because from that point a new algorithm will be used.
Are there any concerns about such change?
I believe that >90% users wouldn't notice anything as it's related to the
history database only.
thanks,
Daniel