More than half year in the past freerdp was updated and then reverted
version to current present , mostly to allow built guacamole-server .
As I see it still stick with that version.
Meantime freerdp move forward. Remmina, which require fresh versions of
freerdp also can't be updated.
Recently our bundling policy changed .
From freerdp depends:
$ dnf repoquery --source --alldeps --whatrequires freerdp-libs
$ dnf repoquery --source --alldeps --whatrequires freerdp
Today I have try build freerdp  from master and all dependencies
And again, *only* guacamole-server fails to build with:
In file included from rdp_stream.h:29:0,
rdp_svc.h:28:38: fatal error: freerdp/utils/svc_plugin.h: No such file
It relied on old svc_plugin which has been rid in 2013 year .
Main question. Is it a good reason to bundle copy of current version
freerdp into guacamole-server (at least until someone do not willing
port it) and update it for rest of Fedora?
I have not tried to do such bundle yet, but if no one argue I could try
do that with update freerdp and rebuild all other deps too.
With best wishes, Pavel Alexeev.
Yes, I'm a fool - I believe in people, honesty, goodness and justice.
And also in the fact that I can make this world just a little better
unless stop fighting.
I was flicking through package review requests to see if anything jumped
out as interesting when I saw this:
Thought I'd take a look as I hadn't had time to review it when it first
appeared and the requester had fixed the github breaking fedora-review
I was very surprised to see :
Package request has been approved:
Given that there is no assignee, no review and no flags on the bug was
there just a mistake in an automated process or has policy changed on
actually needing a review?
I received mail that EPEL-7 branch was requested for PowerTOP in .
Is there any way how to cancel (or at least comment) such requests?
Because this request is apparently invalid, PowerTOP is already
included in RHEL-7
thanks & regards
a week ago I proposed a new release criterion for upgrading across two releases (e.g. from F21 to F23 directly, skipping F22). As this was never officially supported (even though users were probably unaware of this fact, because we haven't discouraged it either), I'm gathering feedback from multiple parties. You can read my original proposal below, and you can see the existing discussion on test list here:
In a nutshell, QA team is OK with supporting this, and Will Woods as dnf-plugin-system-upgrade maintainer as well. What I would like to see is some general feedback from package maintainers, because this will require all packages to be able to upgrade while skipping a release. As I said, many users already assume this works and according to our history it does in the majority of cases, but now it would become even more important.
Also, as one person mentioned, Richard Hughes might be implementing graphical support for system upgrade in Fedora 24. Richard, if you can add your opinion, that would be very welcome as well. If you're going to just call dnf-plugin-system-upgrade in the background, hopefully there should be no complications, since it's going to support it (and it already does).
----- Forwarded Message -----
From: "Kamil Paral" <kparal(a)redhat.com>
To: "For testing and quality assurance of Fedora releases" <test(a)lists.fedoraproject.org>
Sent: Monday, November 23, 2015 4:52:54 PM
Subject: criterion proposal: upgrading across 2 releases
Our current upgrade criterion says:
"For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed."
Currently we have no criterion that would cover upgrading across 2 releases, e.g. from F21 to F23 (directly, not one by one). But in the real world this very often happens. It's even one of the reasons we support our releases until N+2 release is available + 1 month (i.e. F21 is supported until F23 is out + 1 month). The often cited reason is for people to be upgrading just once per year (and have one month to do that). And of course many (probably most) of them don't upgrade one by one, but skip a release.
I feel that for something as important as system upgrade, we should provide a better level of quality and assurance for upgrading across 2 releases. Currently we have no criterion and testing it is just an afterthought, not even tracked anywhere. I'd like to amend the existing criterion to include N-2 release as well, i.e.:
"For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of any of the two previous stable Fedora releases with that package set installed."
(language corrections very welcome)
We can discuss whether N+2 upgrading should be a separate Final criterion, not joined with the Beta one. I don't feel strongly either way.
I'd also set up a new test case in our installation matrix in the upgrade section:
Something like QA:Testcase_upgrade_dnf_skip_release. The question is whether to have just a single test case and let people choose which package set they test, or whether to pick some particular package set. We probably don't want to test all combinations, at least not manually. Just a single "please test something" test case would be satisfactory here, I think. Something will get tested, and we will block on important bugs we discover, that's the important change.
If we decide to not go this route for some reason, I think we should adjust our tools (system-upgrade) and documentation (wiki, fedora docs) and provide very clear and visible warning that the only officially supported means of upgrading is to go up releases one by one. And that skipping releases might be dangerous (considerably more than doing it the recommended way). Because I feel we would be doing our users a disservice if we neither tested skipping releases nor warned them against doing that.