Fedora Rawhide-20170709.n.0 compose check report
Missing expected images: Atomic qcow2 x86_64 Workstation live i386 Server boot i386 Atomic raw-xz x86_64 Kde live i386 Failed openQA tests: 21/137 (x86_64), 1/18 (i386), 1/2 (arm) New failures (same test did not fail in Rawhide-20170708.n.0): ID: 119009 Test: x86_64 Workstation-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/119009 ID: 119041 Test: x86_64 Workstation-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/119041 ID: 119097 Test: x86_64 universal install_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/119097 Old failures (same test failed in Rawhide-20170708.n.0): ID: 118992 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/118992 ID: 118993 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/118993 ID: 118994 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller URL: https://openqa.fedoraproject.org/tests/118994 ID: 118997 Test: x86_64 Server-dvd-iso server_cockpit_basic URL: https://openqa.fedoraproject.org/tests/118997 ID: 119015 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/119015 ID: 119018 Test: x86_64 Workstation-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/119018 ID: 119019 Test: x86_64 Workstation-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/119019 ID: 119026 Test: x86_64 KDE-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/119026 ID: 119032 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/119032 ID: 119034 Test: x86_64 KDE-live-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/119034 ID: 119036 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/119036 ID: 119037 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/119037 ID: 119102 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/119102 ID: 119107 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/119107 ID: 119109 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/119109 ID: 119110 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/119110 ID: 119114 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/119114 ID: 119115 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/119115 ID: 119116 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/119116 ID: 119137 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/119137 Soft failed openQA tests: 62/137 (x86_64), 14/18 (i386) (Tests completed, but using a workaround for a known bug) New soft failures (same test did not soft fail in Rawhide-20170708.n.0): ID: 119005 Test: x86_64 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/119005 ID: 119061 Test: x86_64 universal install_scsi_updates_img URL: https://openqa.fedoraproject.org/tests/119061 ID: 119071 Test: x86_64 universal install_xfs URL: https://openqa.fedoraproject.org/tests/119071 ID: 119082 Test: x86_64 universal install_blivet_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/119082 ID: 119083 Test: x86_64 universal install_blivet_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/119083 ID: 119093 Test: x86_64 universal install_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/119093 ID: 119111 Test: x86_64 universal install_updates_img_local URL: https://openqa.fedoraproject.org/tests/119111 ID: 119124 Test: i386 universal install_scsi_updates_img URL: https://openqa.fedoraproject.org/tests/119124 ID: 119127 Test: i386 universal install_btrfs URL: https://openqa.fedoraproject.org/tests/119127 ID: 119131 Test: i386 universal install_blivet_btrfs URL: https://openqa.fedoraproject.org/tests/119131 Old soft failures (same test soft failed in Rawhide-20170708.n.0): ID: 118982 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/118982 ID: 118983 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/118983 ID: 118984 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/118984 ID: 118985 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/118985 ID: 119002 Test: x86_64 Server-dvd-iso install_updates_nfs URL: https:/
[Test-Announce] 2017-07-10 @ 15:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2017-07-10 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! Fedora 26 is signed off, so let's check in on its status and any remaining tasks, then take a first look at what's coming up in the Fedora 27 cycle. If anyone has any other items for the agenda, please reply to this email and suggest them! Thanks. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 26 status / retrospective 3. Fedora 27 planning 4. Test Day status 5. Open floor -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [Test-Announce] Fedora 26 Candidate RC-1.4 Available Now!
Adam Williamson wrote: > Note that for dumb reasons that I hate we actually strip the metadata > from the final compose when it's actually approved and shipped out to > mirrors, but when a compose completes, the metadata related to that > compose is uploaded to PDC: https://pdc.fedoraproject.org/ . Once > that's done it's not expected, and it may in fact be impossible, for > that metadata to be edited, and it's never removed. So even though the > metadata for Alpha, Beta and Final composes can't be found on the > mirrors with them, it *can* be seen in PDC. All this does not explain why you cannot just drop an ISO file into the directory to be sent to the mirroring. Just ignore all the compose tools and cp or scp or rsync the file in, how hard can that be? Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Unicode 10 support across releases
nicolas.mail...@laposte.net wrote: > I'm quite sure deploying a font that supports a newer unicode revision > than the base system is ok. The various font utilises won't know to look > for new glyphs and gucharmap won't show pretty name for those glyphs, > that's all. And not even necessarily all of them. KCharSelect is typically updated along with the other KDE applications. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Bundled Provides Libraries and Versioning
Adam Miller wrote: > In today's FESCo meeting we discussed the fact that there are many > RPMs currently in Fedora (a reported 244 in Rawhide currently) that > are defining a `Provides: bundled() = ` but excluding > the version completely[0][1]. This removes that ability to properly > perform source code auditing and security vulnerability tracking. > > My question to the Fedora Contributor Community is, how should we > handle this? Is this something that should just simply be fixed by the > packages currently violating the Guidelines, should the Guidelines be > altered in a way that makes this easier to deal with for Packagers but > also provides what is needed for auditing and vulnerability tracking, > or is there simply clarification needed by what is required in the > field? A version number may not even exist at all. Not all code that people copy is a library with a version number. Copylibs often don't bother doing releases because everyone just embeds it as a git submodule or checks out some random revision to copy into their own SCM. Hence, it is not realistic to require a version number. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: Graphical Applications as Flatpaks
Jaroslav Reznik wrote: > = System Wide Change: Graphical Applications as Flatpaks = > https://fedoraproject.org/wiki/Changes/Graphical_Applications_as_Flatpaks > > Change owner(s): > * Owen Taylor This change is leaving several questions unanswered: * As I understand it, those Flatpaks are going to be built from RPMs. Is the intent to ship both the original RPMs and the Flatpak or only the Flatpak (or is this going to depend on the individual package)? And if the former, are the shipped RPMs going to be the FHS-compliant version or the one relocated into Flatpak's proprietary prefix? * What is the advantage of shipping Fedora distribution packages to Fedora users as Flatpaks? I see only drawbacks compared to RPM, because everything not included in the base runtime must be bundled, so we have all the usual issues of bundled libraries: larger downloads, more disk consumption, more RAM consumption (shared system libraries are also shared in RAM), slower and less efficient delivery of security fixes, FHS noncompliance, etc. And the portability argument is moot when we are talking about delivering Fedora software to Fedora users. I strongly oppose this change. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: Graphical Applications as Flatpaks
On Sun, Jul 9, 2017 at 6:46 PM, Kevin Kofler wrote: > Jaroslav Reznik wrote: >> = System Wide Change: Graphical Applications as Flatpaks = >> https://fedoraproject.org/wiki/Changes/Graphical_Applications_as_Flatpaks >> >> Change owner(s): >> * Owen Taylor > > This change is leaving several questions unanswered: But... it's shiny! And new! And distinct from all other packaging systems, so it won't have *any* of the problems any or all of them have shown! And if there's a conflict, overwrite, or embedded incompatible library or conflicting dependency, it will be a Simple Matter Of Programming. And it could not possibly run into any of those more difficult already documented and partially addressed conflicts because, hey, it's *new* and people will stop using the other tools immediately due to its obvious superiority! Sorry, but I've been seeing these kinds of issues for a long time. pkg, apt, rpm, VM images, docker, chroot cages, encap, pyvenv, and associated build tools such as autoconf, CPAN, pip, ant, maven, and gradle. I still see a lot of inevitable and unavoidable conflicts between system libraries published with RPM and flatpack bundled graphical packages. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Unretiring python-greenlet in EPEL7 for python34 ?
On Sun, Jun 25, 2017 at 9:12 AM, Kevin Fenzi wrote: > On 06/24/2017 11:01 PM, Michel Alexandre Salim wrote: > > python-greenlet was marked as dead.package for the epel7 branch because > > it's in rhel-extras: > > > > however, it seems that it's only built for python 2. Is it fine if we > bring > > it back in EPEL but make it python3 only? > > As long as it's a new package called 'python3-greenlet' (or anything > except python-greenlet), sure. > > If it's called python-geenlet it will override the rhel extras one. > > So, a new package review for python3-greenlet should work fine. > > Ah, neat! python3-greenlet review request submitted: https://bugzilla.redhat.com/show_bug.cgi?id=1468949 If anyone would like to swap, let me know. Best regards -- Michel Alexandre Salim profile:https://keybase.io/michel_slm GPG key ID: 4AF554ABA36A937A > kevin > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Bundled Provides Libraries and Versioning
On 2017-07-07, Adam Miller wrote: > `Provides: bundled() = ` but excluding > the version completely[0][1]. This removes that ability to properly > perform source code auditing and security vulnerability tracking. > > My question to the Fedora Contributor Community is, how should we > handle this? It's wrong assumption that a version of the bundled code is known. Either the bundled upstream has no versions, or the bundled code is heavily modified (hence the reason for not unbundling and the need for Provides: bundled()), or there the bundled code has no upstream (anymore). I usually try to track the version when the code was bundled from, but sometimes it's impossible to figure out. Thus I recommend relaxing the guidelines. It's still better to have an unversioned bundled() RPM symbol than nothing. -- Petr ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
