Missing expected images:
Cloud disk raw i386
Cloud disk raw x86_64
Cloud_atomic disk raw x86_64
Images in this compose but not Rawhide 20151201:
Cloud docker x86_64
No images in Rawhide 20151201 but not this.
--
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
Hello.
More than half year in the past freerdp was updated and then reverted
version to current present [1], mostly to allow built guacamole-server [2].
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 [3].
From freerdp depends:
$ dnf repoquery --source --alldeps --whatrequires freerdp-libs
...
freerdp-1.2.0-0.9.git.24a752a.fc23.src.rpm
guacamole-server-0.9.7-1.fc23.src.rpm
medusa-2.2-0.rc1.2.fc23.1.src.rpm
remmina-1.2.0-0.8.git.b3237e8.fc23.src.rpm
vinagre-3.18.1-1.fc23.src.rpm
vlc-2.2.2-0.1.fc23.src.rpm (rpmfusion.org)
weston-1.9.0-1.fc23.src.rpm
$ dnf repoquery --source --alldeps --whatrequires freerdp
...
krdc-15.04.2-2.fc23.src.rpm
Today I have try build freerdp [4] from master and all dependencies
against it.
And again, *only* guacamole-server fails to build with:
In file included from rdp_stream.h:29:0,
from rdp_fs.c:27:
rdp_svc.h:28:38: fatal error: freerdp/utils/svc_plugin.h: No such file
or directory
compilation terminated.
It relied on old svc_plugin which has been rid in 2013 year [5].
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.
[1] https://lists.fedoraproject.org/pipermail/devel/2015-March/209140.html
[2] https://lists.fedoraproject.org/pipermail/devel/2015-March/209181.html
[3] https://fedorahosted.org/fpc/ticket/575
[4] https://github.com/FreeRDP/FreeRDP
[5] https://github.com/FreeRDP/FreeRDP/pull/1574
--
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.
http://hubbitus.info
hi
I tried to log in to stop
http://koji.fedoraproject.org/koji/taskinfo?taskID=12024149 but it
failed with the following error using Firefox on Fedora 23
koji.fedoraproject.org. Il peer SSL ha rifiutato il certificato
considerandolo revocato. (Codice di errore: ssl_error_revoked_cert_alert)
any ideas?
Thanks in advance
Regards
- gil
I was flicking through package review requests to see if anything jumped
out as interesting when I saw this:
https://bugzilla.redhat.com/show_bug.cgi?id=1280422
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
issue ...
I was very surprised to see :
Package request has been approved:
https://admin.fedoraproject.org/pkgdb/package/rpg
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?
Hi,
I received mail that EPEL-7 branch was requested for PowerTOP in [1].
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
Jaroslav
[1] https://admin.fedoraproject.org/pkgdb/package/powertop/
Hello,
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:
https://lists.fedoraproject.org/archives/list/test%40lists.fedoraproject.or…
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).
Thanks,
Kamil
----- 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."
https://fedoraproject.org/wiki/Fedora_24_Beta_Release_Criteria#Upgrade_requ…
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:
https://fedoraproject.org/wiki/Template:Installation_test_matrix#Upgrade
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.
Thoughts?
Kamil