Re: Discussion: what would not blocking on btrfs look like?
On Mon, Aug 26, 2019 at 5:16 AM wrote: > I understand them. The point is, for them and even us (the installer) > is work on BTRFS not a priority. It's something we can't benefit on > RHEL and it could be almost completely replaced by LVM + xfs solution. > However, it still giving us bugs and making our test surface bigger. > > >From the Anaconda team PoV it would make our lives easier to not > support BTRFS at all. I'm not saying that we should drop BTRFS in > Fedora, only that it would be easier for Anaconda team to be without > that on Fedora. It would also be easier if Custom and Advanced partitioning UIs were dropped entirely. Most Linux distros now support Btrfs. All the top 10 do. One, currently ranked #7 Solus, supports it via a point and shoot installer, deferring to Gparted to actually set it up. All the others have a custom interface that supports Btrfs directly. Meanwhile, #23 Parrot uses Btrfs by default for home and root. And so does openSUSE for a while now. And the idea being floated, is that Fedora shouldn't have a sense of adventure, but to maybe drop Btrfs from the installer. Fedora would be the first, if it did. It is completely reasonable for Red Hat to have maintainability concerns about Btrfs for RHEL, and it's entirely fair for Red Hat to have a bias against it. If it were true that Red Hat is, however unintentionally, injecting its Btrfs bias into Fedora, that would be troubling. -- Chris Murphy ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Discussion: what would not blocking on btrfs look like?
On Fri, Aug 23, 2019 at 2:26 PM Laura Abbott wrote: > > I don't think we need someone to join the team per se. All we need is > someone who we can assign bugs to and have them work through the issues, > whether that's development or working with upstream to test. We have > a fedora-btrfs bug alias and we can add whoever we want on here. > > I'm okay with keeping btrfs alive if there's enough of a community who > is willing to actually fix bugs and work through the issues. We > do this with other parts of the kernel too. Past Fedora kernel team statements officially recommended against Btrfs. I think it would be weird to make Btrfs the default file system, were that still the case. And one way to alleviate that, it sounds like, is if there were a Btrfs developer on the Fedora kernel team in some capacity, even if it is strictly Btrfs bugs. But I'm open to other ideas. And if it's just a case of release criteria violating Btrfs bugs remaining blocker worthy, then I think it can go either way. > I think 3-5 are the best options right now with a focus on having btrfs > be available but not "supported". If we had a group of people who were > willing to actively debug issues like the one Adam reported, I'd be okay > with #1. I'm on the fedora-kernel-btrfs@ since February, and also supposedly get btrfs-progs bug notifications. And I've been on linux-btrfs@ since early days, they know who I am, even though I can't code my way out of a hat. They've always been responsive when I show them bugs I can reproduce. -- Chris Murphy ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Discussion: what would not blocking on btrfs look like?
On Mon, Aug 26, 2019 at 7:16 AM wrote: > > On Sat, 2019-08-24 at 07:31 -0700, Adam Williamson wrote: > > On Fri, 2019-08-23 at 19:00 -0600, Chris Murphy wrote: > > > On Fri, Aug 23, 2019 at 1:17 PM Adam Williamson > > > wrote: > > > > > > > So, there was recently a Thing where btrfs installs were broken, > > > > and > > > > this got accepted as a release blocker: > > > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1733388 > > > > > > Summary: This bug was introduced and discovered in linux-next, it > > > started to affect Fedora 5.3.0-rc0 kernels in openqa tests, patch > > > appeared during rc1, and the patch was merged into 5.3.0-rc2. The > > > bug > > > resulted in a somewhat transient deadlock which caused installs to > > > hang, but no corruption. The fix, 2 files changed, 12 insertions, 8 > > > deletions (1/2 the insertions are comments). > > > > > > How remarkable or interesting is this bug? And in particular, > > > exactly > > > how much faster should it have been fixed in order to avoid > > > worrying > > > about it being a blocker bug? > > > > > > 7/25 14:27 utc bug patch was submitted to linux-btrfs@ > > > 7/25 22:33 utc bug was first reported in Fedora bugzilla > > > 7/26 19:20 utc I confirmed upstream's patch related to this bug > > > with > > > upstream and updated the Fedora bug > > > 7/26 22:50 utc I confirmed it was merged into rc2, and updated the > > > Fedora bug > > > > > > So in the context of status quo, where Btrfs is presented as an > > > option > > > in the installer and if there are bugs they Beta blocking, how > > > could > > > or should this have been fixed sooner? What about the handling > > > should > > > have been different? > > > > Nothing. The kernel team's concern is not related to this bug or the > > handling of this bug in any way. The only relevance of the bug is > > that > > it alerted the kernel team to the fact that we currently block on > > btrfs, which they think we should not. > > I understand them. The point is, for them and even us (the installer) > is work on BTRFS not a priority. It's something we can't benefit on > RHEL and it could be almost completely replaced by LVM + xfs solution. > However, it still giving us bugs and making our test surface bigger. > > >From the Anaconda team PoV it would make our lives easier to not > support BTRFS at all. I'm not saying that we should drop BTRFS in > Fedora, only that it would be easier for Anaconda team to be without > that on Fedora. This is flat-out a trap. This is what makes Anaconda such a failure as a community project. Why does the past (RHEL) affect the present and future (Fedora)? There's basically no way whatsoever to make anything better with this logic. The Anaconda releases that any improvements would be going into aren't even landing into the RHEL 8 branch that governs the latest iteration of Fedora's past. From any reasonable person's perspective, this answer makes no sense unless you're using RHEL as an excuse to not support Fedora. -- 真実はいつも一つ！/ Always, there's only one truth! ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Discussion: what would not blocking on btrfs look like?
On Mon, Aug 26, 2019 at 11:16 AM Laura Abbott wrote: > > On 8/23/19 9:00 PM, Chris Murphy wrote: > > On Fri, Aug 23, 2019 at 1:17 PM Adam Williamson > > wrote: > > > >> So, there was recently a Thing where btrfs installs were broken, and > >> this got accepted as a release blocker: > >> > >> https://bugzilla.redhat.com/show_bug.cgi?id=1733388 > > > > Summary: This bug was introduced and discovered in linux-next, it > > started to affect Fedora 5.3.0-rc0 kernels in openqa tests, patch > > appeared during rc1, and the patch was merged into 5.3.0-rc2. The bug > > resulted in a somewhat transient deadlock which caused installs to > > hang, but no corruption. The fix, 2 files changed, 12 insertions, 8 > > deletions (1/2 the insertions are comments). > > > > How remarkable or interesting is this bug? And in particular, exactly > > how much faster should it have been fixed in order to avoid worrying > > about it being a blocker bug? > > > > 7/25 14:27 utc bug patch was submitted to linux-btrfs@ > > 7/25 22:33 utc bug was first reported in Fedora bugzilla > > 7/26 19:20 utc I confirmed upstream's patch related to this bug with > > upstream and updated the Fedora bug > > 7/26 22:50 utc I confirmed it was merged into rc2, and updated the Fedora > > bug > > > > So in the context of status quo, where Btrfs is presented as an option > > in the installer and if there are bugs they Beta blocking, how could > > or should this have been fixed sooner? What about the handling should > > have been different? > > > > That's a fair question. This bug actually represents how this _should_ > work. The concern is that in the past we haven't seen a lot engagement > in the past. Maybe today that has changed as demonstrated by this thread. > I'm still concerned about having this be a blocker vs. just keeping it > as an option, simply because a blocker stops the entire release and it > can be a last minute scramble to get things fixed. This was the ideal > case for a blocker bugs and I'm skeptical about all bugs going this well. > If we had a few more people who were willing to be on the btrfs alias and > do the work for blocker bugs it would be a much stronger case. > Out of curiosity, how many such issues have we had in the past 2 years? I personally can't recall any monumental occasions where people were scrambling over *Btrfs* in Fedora. If anything, we continue to inherit the work that SUSE and Facebook are doing upstream as part of us continually updating our kernels, which I'm grateful for. And in the instances where we've had such issues, has anyone reached out to btrfs folks in Fedora? Chris and myself are the current ones, but there have been others in the past. Both of us are subscribed to the linux-btrfs mailing list, and Chris has a decent rapport with most of the btrfs developers. What more do you want? Actual btrfs developers in Fedora? We don't have any for the majority of filesystems Fedora supports, only XFS. Is there some kind of problem with communicating with the upstream kernel developers about Fedora bugs that I'm not aware of? > > I note here that ext2 and ext3 are offered as file systems in > > Custom/Advanced partitioning and in this sense have parity with Btrfs. > > If this same bug occurred in ext2 or ext3 would or should that cause > > discussion to drop them from the installer, even if the bug were fixed > > within 24 hours of discovery and patch? What about vfat? That's > > literally the only truly required filesystem that must work, for the > > most commonly supported hardware so it can't be dropped, we'd just be > > stuck until it got fixed. That work would have to be done upstream, > > yes? > > > > I don't think that's really a fair comparison. Just because options > are presented doesn't mean all of them are equal. ext2/ext3 and vfat > have been in development for much longer than btrfs and length of development > is something that's particularly important for file system stability > from talking with file system developers. It's not impossible for there > to be bugs in ext4 for example (we've certainly seen them before) but > btrfs is only now gaining overall stability and we're still more likely to see > bugs, especially with custom setups where people are likely to find > edge cases. > Nope. We can totally use this because LVM has not existed as long (we use LVM + filesystem by default, not plain partitions), and we still encounter quirks with things like thinp LVM combined with these filesystems. OverlayFS is mostly hot garbage (kernel people know it, container people know it, filesystem people know it, etc.), and yet we continue to try to use it in more places. Stratis is in an odd state of limbo now, since its main developer and advocate left Red Hat. There are plenty of examples of Red Hat doing crazy/experimental things... I'd like to think Red Hat isn't supposed to be special here, but in this realm, it seems like it is... -- 真実はいつも一つ！/ Always, there's only one truth!
Re: Discussion: what would not blocking on btrfs look like?
On Mon, Aug 26, 2019 at 10:48 PM Chris Murphy wrote: > > On Fri, Aug 23, 2019 at 1:44 PM Justin Forbes wrote: > > > > All of this, the criteria, and the UI support for btrfs are from the > > many years old proposal to make btrfs the default filesystem. In the > > beginning, it was not ready, but did show promise. This proposal came > > up for several releases in a row, and at the end of it, even the > > upstream developers recommended against it. > > Josef Bacik alone pushed for it. And it was Fedora that wasn't ready > for Btrfs, not the other way around. In Josef's last couple emails to > devel@ he stated the decision would need to be made by others, not > him. He pretty much gave up once SUSE got there first. > Indeed. In fact, I more or less took over the reigns of trying to improve Fedora's Btrfs support after Josef gave up. > I'm not aware of any upstream developers recommending Fedora not use > it. A significant chunk of upstream are at SUSE and by this time had > moved to Btrfs by default, so it'd be a little weird if they're > recommending against the thing. > If anything, the Btrfs stack developers at SUSE have been nothing but helpful whenever I've talked to them about working on bringing this to Fedora. I've literally *never* heard them say that Btrfs isn't ready. However, they have told me in the past to be cautious with some features for "enterprise supportability". But they've never said anything about Btrfs not being ready as a whole. > > > At this point, it is safe > > to say that btrfs will not be the default. Since that time, things > > have not gotten better. > > This is ambiguous. One possible way to read this is: no matter what > resources are put into supporting it in Fedora, it's safe to say it > won't be the default. Another possibility: the support resources > necessary haven't materialized, therefore it won't be the default. > > I would like to better understand why it is "safe to say" it won't be > the default. > I really didn't want this to come up, and I ignored this the first time, but I can't anymore... I'm pretty sure this is another variation of the "shutdowns" I keep getting when trying to work on Btrfs support in Fedora. It's surprisingly annoying that Fedora as a community distribution has touch points where community members have basically zero chance at being successful at anything. Honestly, I'm surprised we've kept Anaconda as the installer for Fedora, given the attitude I and other community members get from the Anaconda developers and sheer amount of pain and agony we have to deal with to even attempt simple contributions, much less complex ones. Amazingly, I do have a single commit in Anaconda[0], but the amount of effort and time it took to get it in was ridiculous. And while I like the Anaconda installer, I don't like that there can never be a community around it. It's one of those projects that has a stranglehold around it that is designed to discourage you. And that's not even with things like Btrfs. There's been a request (with code even!) from the Qubes OS folks to add GPG key support to kickstart[1] and Anaconda[2] for literally years. I've wanted to accept the changes for livecd-tools[3] for years, but I can't until pykickstart and anaconda support it. I'm not even going to get into the repo --priority option from the FedBerry guys. By any meaningful measure, Anaconda has less community than Btrfs, and it remains the "blessed" installer. Moreover, it gets to singlehandedly dictate what the distribution supports. And its developers basically get to shut down any discussion of anything related to Btrfs, in any form or fashion[4]. And you wonder why Btrfs support is so weak in Fedora? Because of all this, I was discouraged from finishing and submitting my change proposal to fully enable Btrfs with full system snapshots[5]. I'm honestly not surprised that Josef gave up. I'm surprised that I'm still stubborn enough to try to make it happen, but perhaps there's a part of me that hates giving up... [0]: https://github.com/rhinstaller/anaconda/commit/c8c5589e4a4c5451d91ae8c47bf2fe0270d2af5f [1]: https://github.com/bcl/pykickstart/pull/32 [2]: https://github.com/rhinstaller/anaconda/pull/375 [3]: https://github.com/livecd-tools/livecd-tools/pull/14 [4]: https://bugzilla.redhat.com/show_bug.cgi?id=1717728#c9 [5]: https://fedoraproject.org/wiki/Changes/BtrfsWithFullSystemSnapshots > > > > > Yes, there is active btrfs development > > upstream. It is fairly narrowly focused, and not something we can > > rely upon for a supported default among the Fedora use cases. > > The thread is ostensibly about whether it's appropriate to block > release on Btrfs related bugs, not whether it should be the default > file system. But as it's been brought up, I'd like to know if there's > any difference in the expected support resources between it remaining > "blocker worthy" versus becoming "a default file system" somewhere in > the Fedora ecosystem in a release
Re: Discussion: what would not blocking on btrfs look like?
On Fri, Aug 23, 2019 at 1:44 PM Justin Forbes wrote: > > All of this, the criteria, and the UI support for btrfs are from the > many years old proposal to make btrfs the default filesystem. In the > beginning, it was not ready, but did show promise. This proposal came > up for several releases in a row, and at the end of it, even the > upstream developers recommended against it. Josef Bacik alone pushed for it. And it was Fedora that wasn't ready for Btrfs, not the other way around. In Josef's last couple emails to devel@ he stated the decision would need to be made by others, not him. He pretty much gave up once SUSE got there first. I'm not aware of any upstream developers recommending Fedora not use it. A significant chunk of upstream are at SUSE and by this time had moved to Btrfs by default, so it'd be a little weird if they're recommending against the thing. > At this point, it is safe > to say that btrfs will not be the default. Since that time, things > have not gotten better. This is ambiguous. One possible way to read this is: no matter what resources are put into supporting it in Fedora, it's safe to say it won't be the default. Another possibility: the support resources necessary haven't materialized, therefore it won't be the default. I would like to better understand why it is "safe to say" it won't be the default. > > Yes, there is active btrfs development > upstream. It is fairly narrowly focused, and not something we can > rely upon for a supported default among the Fedora use cases. The thread is ostensibly about whether it's appropriate to block release on Btrfs related bugs, not whether it should be the default file system. But as it's been brought up, I'd like to know if there's any difference in the expected support resources between it remaining "blocker worthy" versus becoming "a default file system" somewhere in the Fedora ecosystem in a release blocking capacity (i.e. presumably a Fedora Spin could choose to make Btrfs its default file system, but that wouldn't be release blocking). > While > Fedora does enable it in the kernel, and plans to continue doing so, > it is enabled in the "if you break it, you get to keep the pieces" > method of many other options. Sure, we will be happy to bring in a > patch that is headed upstream if it fixes a bug, and someone points us > to it. No, we aren't going to spend time debugging issues with it > ourselves. There is no shortage of issues in more "core" kernel > pieces that require attention. That's understandable and reasonable. I don't think anyone uninterested in supporting Btrfs should be made to feel like they ought to. Life is short, do what you're interested in doing, no more. -- Chris Murphy ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
[Test-Announce] Fedora 31 Beta Freeze
Hi all, Today's an important day on the Fedora 31 schedule[1], with several significant cut-offs. First of all today is the Bodhi activation point [2]. That means that from now all Fedora 31 packages must be submitted to updates-testing and pass the relevant requirements[3] before they will be marked as 'stable' and moved to the fedora repository. Today is also the Beta freeze[4]. This means that only packages which fix accepted blocker or freeze exception bugs[5][6] will be marked as 'stable' and included in the Beta composes. Other builds will remain in updates- testing until the Beta release is approved, at which point the Beta freeze is lifted and packages can move to 'stable' as usual until the Final freeze. Finally, Today is the '100% code complete deadline' Change Checkpoint[5], meaning that Fedora 31 Changes must now be code complete, meaning all the code required to enable to the new change is finished. The level of code completeness is reflected as tracker bug state ON_QA. The change does not have to be fully tested by this deadline'. Finally, today is also the Software String freeze[7], which means that strings marked for translation in Fedora- translated projects should not now be changed for Fedora 31. Mohan Boddu [1] https://fedoraproject.org/wiki/Releases/31/Schedule [2] https://fedoraproject.org/wiki/Updates_Policy#Bodhi_enabling [3] https://fedoraproject.org/wiki/Updates_Policy#Branched_release [4] https://fedoraproject.org/wiki/Milestone_freezes [5] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process [6] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process [7] https://fedoraproject.org/wiki/ReleaseEngineering/StringFreezePolicy ___ test-announce mailing list -- test-announce@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-announce@lists.fedoraproject.org
Re: Discussion: what would not blocking on btrfs look like?
On Mon, 2019-08-26 at 19:33 +0200, Frantisek Zatloukal wrote: > On Mon, Aug 26, 2019 at 4:53 PM Kamil Paral wrote: > > > On Mon, Aug 26, 2019 at 2:42 PM Justin Forbes > > wrote: > > > > > From my standpoint, ext4 and xfs are the primary supported root > > > filesystems. I don't think that anything else should be release > > > blocking. > > > > If this is the case, we can explicitly list the supported file systems in > > criteria. The list would need to be extended with at least vfat, which is > > used for ESP, though. > > > > If we go this route, it would be nice to communicate this somehow to the > > end user, directly in anaconda interface. Either by showing a warning when > > a "not officially supported" filesystem is selected, or by hiding those > > filesystems in dialogs when creating a new partition (with a documented > > override). > > > > Hmm, I don't see this as necessary. I think changing criterions on what > file systems are blocking doesn't mean we need to hide things or add some > ugly warnings. Anybody who uses advanced partitioning should know what is > doing, we can just update criterions so not everything visible in advanced > partitioning must work and is supported. I mean, I don't see that there's necessarily an equivalence between "knowing what you're doing" and "expecting it to be broken". That's the reason I quite like the current criterion: it commits us to not just throwing a bunch of hand grenades at the user in the installer. If we're going to do that it should at least be communicated *somehow* outside of just being in the release criteria. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Discussion: what would not blocking on btrfs look like?
On Mon, Aug 26, 2019 at 4:53 PM Kamil Paral wrote: > On Mon, Aug 26, 2019 at 2:42 PM Justin Forbes > wrote: > >> From my standpoint, ext4 and xfs are the primary supported root >> filesystems. I don't think that anything else should be release >> blocking. > > > If this is the case, we can explicitly list the supported file systems in > criteria. The list would need to be extended with at least vfat, which is > used for ESP, though. > > If we go this route, it would be nice to communicate this somehow to the > end user, directly in anaconda interface. Either by showing a warning when > a "not officially supported" filesystem is selected, or by hiding those > filesystems in dialogs when creating a new partition (with a documented > override). > Hmm, I don't see this as necessary. I think changing criterions on what file systems are blocking doesn't mean we need to hide things or add some ugly warnings. Anybody who uses advanced partitioning should know what is doing, we can just update criterions so not everything visible in advanced partitioning must work and is supported. > Existing partitions still need to be handled somehow, so the warning bar > might need to be implemented in any case (warn that the existing partition > is unsupported by allow to use it, or warn that the existing partition > can't be used unless the override is activated). > I am -1 on this. I just somehow hate the idea of showing warnings and/or adding some blocks and overrides. We weren't testing on unsupported/other file systems anyway (correct me if I am mistaken), so what's the difference now? ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Discussion: what would not blocking on btrfs look like?
On Mon, Aug 26, 2019 at 2:42 PM Justin Forbes wrote: > From my standpoint, ext4 and xfs are the primary supported root > filesystems. I don't think that anything else should be release > blocking. If this is the case, we can explicitly list the supported file systems in criteria. The list would need to be extended with at least vfat, which is used for ESP, though. If we go this route, it would be nice to communicate this somehow to the end user, directly in anaconda interface. Either by showing a warning when a "not officially supported" filesystem is selected, or by hiding those filesystems in dialogs when creating a new partition (with a documented override). Existing partitions still need to be handled somehow, so the warning bar might need to be implemented in any case (warn that the existing partition is unsupported by allow to use it, or warn that the existing partition can't be used unless the override is activated). ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Fedora 31 compose report: 20190826.n.0 changes
OLD: Fedora-31-20190825.n.0 NEW: Fedora-31-20190826.n.0 = SUMMARY = Added images:1 Dropped images: 0 Added packages: 1 Dropped packages:0 Upgraded packages: 38 Downgraded packages: 0 Size of added packages: 78.57 KiB Size of dropped packages:0 B Size of upgraded packages: 2.10 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 3.77 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Workstation raw-xz aarch64 Path: Workstation/aarch64/images/Fedora-Workstation-31-20190826.n.0.aarch64.raw.xz = DROPPED IMAGES = = ADDED PACKAGES = Package: clojure-maven-plugin-1.8.1-3.fc31 Summary: Clojure plugin for Maven RPMs:clojure-maven-plugin Size:78.57 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: R-dbplyr-1.4.2-1.fc31 Old package: R-dbplyr-1.4.0-3.fc31 Summary: A 'dplyr' Back End for Databases RPMs: R-dbplyr Size: 579.49 KiB Size change: 7.53 KiB Changelog: * Sun Aug 25 2019 Elliott Sales de Andrade - 1.4.2-1 - Update to latest version Package: R-dplyr-0.8.3-1.fc31 Old package: R-dplyr-0.8.0.1-3.fc31 Summary: A Grammar of Data Manipulation RPMs: R-dplyr R-dplyr-devel Size: 11.16 MiB Size change: 29.84 KiB Changelog: * Sun Aug 25 2019 Elliott Sales de Andrade - 0.8.3-1 - Update to latest version Package: R-ggplot2-3.2.1-1.fc31 Old package: R-ggplot2-3.1.1-2.fc31 Summary: Create Elegant Data Visualisations Using the Grammar of Graphics RPMs: R-ggplot2 Size: 3.74 MiB Size change: 310.63 KiB Changelog: * Sun Aug 11 2019 Elliott Sales de Andrade - 3.1.1-3 - Remove explicit dependencies provided by automatic dependency generator * Mon Aug 26 2019 Elliott Sales de Andrade - 3.2.1-1 - Update to latest version Package: R-hms-0.5.1-1.fc31 Old package: R-hms-0.5.0-3.fc31 Summary: Pretty Time of Day RPMs: R-hms Size: 116.35 KiB Size change: 415 B Changelog: * Sun Aug 25 2019 Elliott Sales de Andrade - 0.5.1-1 - Update to latest version Package: R-rematch2-2.1.0-1.fc31 Old package: R-rematch2-2.0.1-3.fc31 Summary: Tidy Output from Regular Expression Matching RPMs: R-rematch2 Size: 57.26 KiB Size change: 5.53 KiB Changelog: * Sun Aug 25 2019 Elliott Sales de Andrade - 2.1.0-1 - Update to latest version Package: R-rmarkdown-1.15-1.fc31 Old package: R-rmarkdown-1.14-1.fc31 Summary: Dynamic Documents for R RPMs: R-rmarkdown Size: 2.14 MiB Size change: 62 B Changelog: * Sun Aug 25 2019 Elliott Sales de Andrade - 1.15-1 - Update to latest version Package: R-rsconnect-0.8.15-1.fc31 Old package: R-rsconnect-0.8.13-3.fc31 Summary: Deployment Interface for R Markdown Documents and Shiny Applications RPMs: R-rsconnect Size: 406.81 KiB Size change: 9.37 KiB Changelog: * Sun Aug 25 2019 Elliott Sales de Andrade - 0.8.15-1 - Update to latest version Package: R-webutils-1.0-1.fc31 Old package: R-webutils-0.6-6.fc31 Summary: Utility Functions for Developing Web Applications RPMs: R-webutils Size: 281.46 KiB Size change: 2.63 KiB Changelog: * Sun Aug 25 2019 Elliott Sales de Andrade - 1.0-1 - Update to latest version Package: R-xfun-0.9-1.fc31 Old package: R-xfun-0.7-3.fc31 Summary: Miscellaneous Functions by 'Yihui Xie' RPMs: R-xfun Size: 192.56 KiB Size change: 9.36 KiB Changelog: * Sun Aug 25 2019 Elliott Sales de Andrade - 0.9-1 - Update to latest version Package: anki-2.1.15-1.fc31 Old package: anki-2.1.14-2.fc31 Summary: Flashcard program for using space repetition learning RPMs: anki Size: 2.41 MiB Size change: -806 B Changelog: * Fri Aug 23 2019 Christian Krause - 2.1.15-1 - Update to new upstream version 2.1.15 (BZ 1744359) - Remove obsolete requirement python3-qt5-webkit Package: buildbot-2.4.0-1.fc31 Old package: buildbot-2.3.1-2.fc31 Summary: Build/test automation system RPMs: buildbot buildbot-master buildbot-worker buildbot-www Size: 4.56 MiB Size change: -442.31 KiB Changelog: * Wed Jul 24 2019 Fedora Release Engineering - 2.3.1-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild * Mon Aug 19 2019 Miro Hron??ok - 2.3.1-4 - Rebuilt for Python 3.8 * Sun Aug 25 2019 Neal Gompa - 2.4.0-1 - Update to 2.4.0 (#1743002) Package: cc1541-3.0-1.fc31 Old package: cc1541-2.0-3.fc31 Summary: Tool for creating Commodore 1541 Floppy disk images in D64, G64, D71 or D81 format RPMs: cc1541 Size: 203.58 KiB Size change: 55.95 KiB Changelog: * Sun Aug 25 2019 Bj??rn Esser - 3.0-1 - New upstream release Package: copyq-3.9.2-1.fc31 Old package: copyq-3.9.1-1.fc31 Summary: Advanced clipboard manager RPMs: copyq Size
Re: Testing Workstation
Yes, F31. I just found out there are similar problems in F30 Workstation too. I'll try to gather more information. Regards, Lailah. On Mon, 26 Aug 2019 at 15:32, wrote: > On Mon, 2019-08-26 at 15:21 +0200, Silvia Sánchez wrote: > > The problem is that it wasn't my computer and I'm still searching who > > had this problem to ask for more details. > > Just for confirmation: such user was using Rawhide (or now F31), yes? > > Thanks, > Alessio > > ___ > test mailing list -- test@lists.fedoraproject.org > To unsubscribe send an email to test-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org > ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Testing Workstation
On Mon, 2019-08-26 at 15:21 +0200, Silvia Sánchez wrote: > The problem is that it wasn't my computer and I'm still searching who > had this problem to ask for more details. Just for confirmation: such user was using Rawhide (or now F31), yes? Thanks, Alessio ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Testing Workstation
Hello all, Alessio, the user I mentioned didn't touch SELinux to fix this issue. That's why I said I don't think it's related. I'm not saying they are the same bug, only saying there was a similar issue and it didn't seem to be related to SELinux. And in that issues, the options were greyed out. So yes, *I am *talking about another issues. About the automatic time zone, disabling that didn't make the list available for change. The problem is that it wasn't my computer and I'm still searching who had this problem to ask for more details. All for now, Lailah On Sat, 24 Aug 2019 at 18:16, Alessio wrote: > On Sat, Aug 24, 2019, 5:58 PM Silvia Sánchez wrote: > >> >> I'm not sure is that about SELinux. They didn't see any SELinux alert, >> but the option, tab or whatever it is called in Gnome for changing >> timezones was greyed out. Even after unlocking it, it was impossible to >> choose because it remained greyed/disabled. >> > > Silvia, Adam is right. I didn't test newest F31 composes since the report. > But by disabling selinux, these issues had gone. > > What I saw related to timezone is in this screenshot: > https://alciregi.fedorapeople.org/screenshot/timezone.png > So the option to select the time zone was not grayed out, but the > subsequent list was empty. (This was with selinux enabled). > > I think you are talking about another issue. > BTW timezone option is correctly grayed out if you turn automatic timezone > on. > > Ciao, > A. > >> ___ > test mailing list -- test@lists.fedoraproject.org > To unsubscribe send an email to test-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org > ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Fedora-31-20190826.n.0 compose check report
No missing expected images. Failed openQA tests: 13/152 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-31-20190825.n.0): ID: 436097 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/436097 Old failures (same test failed in Fedora-31-20190825.n.0): ID: 436063 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/436063 ID: 436075 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/436075 ID: 436078 Test: x86_64 Workstation-live-iso desktop_background URL: https://openqa.fedoraproject.org/tests/436078 ID: 436080 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/436080 ID: 436094 Test: x86_64 KDE-live-iso desktop_background URL: https://openqa.fedoraproject.org/tests/436094 ID: 436098 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/436098 ID: 436101 Test: x86_64 Silverblue-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/436101 ID: 436109 Test: x86_64 Silverblue-dvd_ostree-iso desktop_background URL: https://openqa.fedoraproject.org/tests/436109 ID: 436127 Test: x86_64 universal install_software_raid URL: https://openqa.fedoraproject.org/tests/436127 ID: 436133 Test: x86_64 universal install_no_swap URL: https://openqa.fedoraproject.org/tests/436133 ID: 436152 Test: x86_64 universal install_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/436152 ID: 436157 Test: x86_64 universal install_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/436157 ID: 436176 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/436176 Soft failed openQA tests: 3/152 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-31-20190825.n.0): ID: 436164 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/436164 ID: 436165 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/436165 ID: 436181 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/436181 Passed openQA tests: 136/152 (x86_64) New passes (same test not passed in Fedora-31-20190825.n.0): ID: 436077 Test: x86_64 Workstation-live-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/436077 ID: 436096 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/436096 ID: 436135 Test: x86_64 universal install_blivet_ext3 URL: https://openqa.fedoraproject.org/tests/436135 Skipped non-gating openQA tests: 1 of 154 Installed system changes in test x86_64 Everything-boot-iso install_default: System load changed from 0.02 to 0.14 Previous test data: https://openqa.fedoraproject.org/tests/435654#downloads Current test data: https://openqa.fedoraproject.org/tests/436065#downloads Installed system changes in test x86_64 Workstation-live-iso install_default_upload: 3 packages(s) added since previous compose: firebird, firebird-utils, libib-util 1 services(s) added since previous compose: dbus-:1.7-org.freedesktop.problems@0.service loaded active running dbus-:1.7-org.freedesktop.problems@0.service 1 services(s) removed since previous compose: dbus-:1.6-org.freedesktop.problems@0.service loaded active running dbus-:1.6-org.freedesktop.problems@0.service Previous test data: https://openqa.fedoraproject.org/tests/435656#downloads Current test data: https://openqa.fedoraproject.org/tests/436067#downloads Installed system changes in test x86_64 Workstation-live-iso install_default@uefi: 3 packages(s) added since previous compose: firebird, firebird-utils, libib-util 1 services(s) added since previous compose: dbus-:1.7-org.freedesktop.problems@0.service loaded active running dbus-:1.7-org.freedesktop.problems@0.service 1 services(s) removed since previous compose: dbus-:1.6-org.freedesktop.problems@0.service loaded active running dbus-:1.6-org.freedesktop.problems@0.service System load changed from 0.24 to 0.61 Previous test data: https://openqa.fedoraproject.org/tests/435658#downloads Current test data: https://openqa.fedoraproject.org/tests/436069#downloads Installed system changes in test x86_64 KDE-live-iso install_default_upload: 1 services(s) removed since previous compose: pcscd.service System load changed from 0.64 to 2.30 Previous test data: https://openqa.fedoraproject.org/tests/435671#downloads Current test data: https://openqa.fedoraproject.org/tests/436082#downloads Installed system
Re: Discussion: what would not blocking on btrfs look like?
On Fri, Aug 23, 2019 at 8:00 PM Chris Murphy wrote: > > On Fri, Aug 23, 2019 at 1:17 PM Adam Williamson > wrote: > > > So, there was recently a Thing where btrfs installs were broken, and > > this got accepted as a release blocker: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1733388 > > Summary: This bug was introduced and discovered in linux-next, it > started to affect Fedora 5.3.0-rc0 kernels in openqa tests, patch > appeared during rc1, and the patch was merged into 5.3.0-rc2. The bug > resulted in a somewhat transient deadlock which caused installs to > hang, but no corruption. The fix, 2 files changed, 12 insertions, 8 > deletions (1/2 the insertions are comments). > > How remarkable or interesting is this bug? And in particular, exactly > how much faster should it have been fixed in order to avoid worrying > about it being a blocker bug? > > 7/25 14:27 utc bug patch was submitted to linux-btrfs@ > 7/25 22:33 utc bug was first reported in Fedora bugzilla > 7/26 19:20 utc I confirmed upstream's patch related to this bug with > upstream and updated the Fedora bug > 7/26 22:50 utc I confirmed it was merged into rc2, and updated the Fedora bug > > So in the context of status quo, where Btrfs is presented as an option > in the installer and if there are bugs they Beta blocking, how could > or should this have been fixed sooner? What about the handling should > have been different? > > I note here that ext2 and ext3 are offered as file systems in > Custom/Advanced partitioning and in this sense have parity with Btrfs. > If this same bug occurred in ext2 or ext3 would or should that cause > discussion to drop them from the installer, even if the bug were fixed > within 24 hours of discovery and patch? What about vfat? That's > literally the only truly required filesystem that must work, for the > most commonly supported hardware so it can't be dropped, we'd just be > stuck until it got fixed. That work would have to be done upstream, > yes? From my standpoint, ext4 and xfs are the primary supported root filesystems. I don't think that anything else should be release blocking. As for whether the installer exposes other options, it is really more of an installer and QA question. We are certainly not even discussing turning them off in the kernel at this point, and I don't think that we should. > -- > Chris Murphy > ___ > kernel mailing list -- ker...@lists.fedoraproject.org > To unsubscribe send an email to kernel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/ker...@lists.fedoraproject.org ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: [Test-Announce] Proposal to CANCEL: 2019-08-26 Fedora QA Meeting
Sure, sorry, I forgot. Cheers, Lailah On Mon, 26 Aug 2019 at 14:23, wrote: > On Mon, 2019-08-26 at 14:18 +0200, Silvia Sánchez wrote: > > > > Hello, > > > > I had a bug report I thought it could be important but now it's too > > late, so let's leave it for the next week. > > > In the meanwhile you can share it in the mailing list, isn't it? > > Ciao, > A. > > ___ > test mailing list -- test@lists.fedoraproject.org > To unsubscribe send an email to test-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org > ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: [Test-Announce] Proposal to CANCEL: 2019-08-26 Fedora QA Meeting
On Mon, 2019-08-26 at 14:18 +0200, Silvia Sánchez wrote: > > Hello, > > I had a bug report I thought it could be important but now it's too > late, so let's leave it for the next week. In the meanwhile you can share it in the mailing list, isn't it? Ciao, A. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Fedora rawhide compose report: 20190826.n.0 changes
OLD: Fedora-Rawhide-20190825.n.0 NEW: Fedora-Rawhide-20190826.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 6 Dropped packages:0 Upgraded packages: 78 Downgraded packages: 0 Size of added packages: 13.67 MiB Size of dropped packages:0 B Size of upgraded packages: 423.25 MiB Size of downgraded packages: 0 B Size change of upgraded packages: 29.23 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: clojure-maven-plugin-1.8.1-3.fc32 Summary: Clojure plugin for Maven RPMs:clojure-maven-plugin Size:78.56 KiB Package: rust-idna0.1-0.1.5-1.fc32 Summary: IDNA (Internationalizing Domain Names in Applications) and Punycode RPMs:rust-idna0.1+default-devel rust-idna0.1-devel Size:219.94 KiB Package: rust-percent-encoding1-1.0.1-1.fc32 Summary: Percent encoding and decoding RPMs:rust-percent-encoding1+default-devel rust-percent-encoding1-devel Size:24.47 KiB Package: rust-serde_urlencoded0.5-0.5.5-1.fc32 Summary: `x-www-form-urlencoded` meets Serde RPMs:rust-serde_urlencoded0.5+default-devel rust-serde_urlencoded0.5-devel Size:28.85 KiB Package: rust-url1-1.7.2-1.fc32 Summary: URL library for Rust, based on the WHATWG URL Standard RPMs:rust-url1+default-devel rust-url1+encoding-devel rust-url1+heap_size-devel rust-url1+heapsize-devel rust-url1+query_encoding-devel rust-url1+rustc-serialize-devel rust-url1+serde-devel rust-url1-devel Size:116.46 KiB Package: thrift-0.10.0-19.fc32 Summary: Software framework for cross-language services development RPMs:fb303 fb303-devel perl-thrift python3-fb303 python3-thrift thrift thrift-devel thrift-glib thrift-qt Size:13.21 MiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: Mayavi-4.6.2-5.fc32 Old package: Mayavi-4.6.2-4.fc31 Summary: Scientific data 3-dimensional visualizer RPMs: Mayavi Mayavi-doc python3-mayavi Size: 105.18 MiB Size change: 556.69 KiB Changelog: * Mon Aug 19 2019 Miro Hron??ok - 4.6.2-5 - Rebuilt for Python 3.8 Package: R-dbplyr-1.4.2-1.fc32 Old package: R-dbplyr-1.4.0-3.fc31 Summary: A 'dplyr' Back End for Databases RPMs: R-dbplyr Size: 579.51 KiB Size change: 7.56 KiB Changelog: * Sun Aug 25 2019 Elliott Sales de Andrade - 1.4.2-1 - Update to latest version Package: R-dplyr-0.8.3-1.fc32 Old package: R-dplyr-0.8.0.1-3.fc31 Summary: A Grammar of Data Manipulation RPMs: R-dplyr R-dplyr-devel Size: 11.16 MiB Size change: 29.82 KiB Changelog: * Sun Aug 25 2019 Elliott Sales de Andrade - 0.8.3-1 - Update to latest version Package: R-hms-0.5.1-1.fc32 Old package: R-hms-0.5.0-3.fc31 Summary: Pretty Time of Day RPMs: R-hms Size: 116.35 KiB Size change: 415 B Changelog: * Sun Aug 25 2019 Elliott Sales de Andrade - 0.5.1-1 - Update to latest version Package: R-rematch2-2.1.0-1.fc32 Old package: R-rematch2-2.0.1-3.fc31 Summary: Tidy Output from Regular Expression Matching RPMs: R-rematch2 Size: 57.39 KiB Size change: 5.66 KiB Changelog: * Sun Aug 25 2019 Elliott Sales de Andrade - 2.1.0-1 - Update to latest version Package: R-rmarkdown-1.15-1.fc32 Old package: R-rmarkdown-1.14-1.fc32 Summary: Dynamic Documents for R RPMs: R-rmarkdown Size: 2.14 MiB Size change: 40 B Changelog: * Sun Aug 25 2019 Elliott Sales de Andrade - 1.15-1 - Update to latest version Package: R-webutils-1.0-1.fc32 Old package: R-webutils-0.6-6.fc31 Summary: Utility Functions for Developing Web Applications RPMs: R-webutils Size: 281.45 KiB Size change: 2.62 KiB Changelog: * Sun Aug 25 2019 Elliott Sales de Andrade - 1.0-1 - Update to latest version Package: R-xfun-0.9-1.fc32 Old package: R-xfun-0.7-3.fc31 Summary: Miscellaneous Functions by 'Yihui Xie' RPMs: R-xfun Size: 192.56 KiB Size change: 9.36 KiB Changelog: * Sun Aug 25 2019 Elliott Sales de Andrade - 0.9-1 - Update to latest version Package: anki-2.1.15-1.fc32 Old package: anki-2.1.14-2.fc31 Summary: Flashcard program for using space repetition learning RPMs: anki Size: 2.41 MiB Size change: -688 B Changelog: * Fri Aug 23 2019 Christian Krause - 2.1.15-1 - Update to new upstream version 2.1.15 (BZ 1744359) - Remove obsolete requirement python3-qt5-webkit Package: buildbot-2.4.0-1.fc32 Old package: buildbot-2.3.1-4.fc32 Summary: Build/test automation system RPMs: buildbot buildbot-master buildbot-worker buildbot-www Size: 4.59 MiB Size change: 1018.06 KiB Changelog: * Sun Aug 25 2019 Neal Gompa - 2.4.0-1 - Update to 2.4.0 (#1743002) Package: cc1541-3.0-1.fc32 Old package: cc1541-2.0-3.fc31 Summary: Tool for creating Commodore 1541 Floppy disk images in D64
Re: [Test-Announce] Proposal to CANCEL: 2019-08-26 Fedora QA Meeting
Hello, I had a bug report I thought it could be important but now it's too late, so let's leave it for the next week. Regards, Lailah On Mon, 26 Aug 2019 at 04:06, Adam Williamson wrote: > Hi folks! I'm proposing we cancel the QA meeting tomorrow, as there > isn't a lot for the agenda. We will be doing a blocker review meeting, > though - I'll send out the announcement for that in a minute. > > If you're aware of anything important we have to discuss this week, > please do reply to this mail and we can go ahead and run the meeting. > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora > 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 > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org > ___ > devel mailing list -- de...@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org > ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Fedora-Rawhide-20190826.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 22 of 45 required tests failed, 15 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Unsatisfied gating requirements that could not be mapped to openQA tests: FAILED: compose.cloud.all MISSING: fedora.Workstation-boot-iso.x86_64.64bit - compose.install_default MISSING: fedora.Workstation-boot-iso.x86_64.uefi - compose.install_default Failed openQA tests: 67/152 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-Rawhide-20190825.n.0): ID: 435913 Test: x86_64 Workstation-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/435913 ID: 435937 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/435937 Old failures (same test failed in Fedora-Rawhide-20190825.n.0): ID: 435877 Test: x86_64 Server-boot-iso install_default **GATING** URL: https://openqa.fedoraproject.org/tests/435877 ID: 435878 Test: x86_64 Server-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/435878 ID: 435879 Test: x86_64 Server-dvd-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/435879 ID: 435881 Test: x86_64 Server-dvd-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/435881 ID: 435887 Test: x86_64 Server-dvd-iso support_server URL: https://openqa.fedoraproject.org/tests/435887 ID: 435890 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/435890 ID: 435891 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/435891 ID: 435892 Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation URL: https://openqa.fedoraproject.org/tests/435892 ID: 435893 Test: x86_64 Server-dvd-iso install_repository_hd_variation URL: https://openqa.fedoraproject.org/tests/435893 ID: 435907 Test: x86_64 Server-dvd-iso install_updates_nfs URL: https://openqa.fedoraproject.org/tests/435907 ID: 435911 Test: x86_64 Everything-boot-iso install_default **GATING** URL: https://openqa.fedoraproject.org/tests/435911 ID: 435912 Test: x86_64 Everything-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/435912 ID: 435944 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/435944 ID: 435946 Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/435946 ID: 435948 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/435948 ID: 435956 Test: x86_64 universal install_package_set_minimal URL: https://openqa.fedoraproject.org/tests/435956 ID: 435957 Test: x86_64 universal install_anaconda_text **GATING** URL: https://openqa.fedoraproject.org/tests/435957 ID: 435958 Test: x86_64 universal support_server URL: https://openqa.fedoraproject.org/tests/435958 ID: 435959 Test: x86_64 universal install_repository_http_variation **GATING** URL: https://openqa.fedoraproject.org/tests/435959 ID: 435960 Test: x86_64 universal install_repository_http_graphical **GATING** URL: https://openqa.fedoraproject.org/tests/435960 ID: 435961 Test: x86_64 universal install_mirrorlist_graphical **GATING** URL: https://openqa.fedoraproject.org/tests/435961 ID: 435962 Test: x86_64 universal install_delete_pata **GATING** URL: https://openqa.fedoraproject.org/tests/435962 ID: 435963 Test: x86_64 universal install_delete_pata@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/435963 ID: 435964 Test: x86_64 universal install_sata **GATING** URL: https://openqa.fedoraproject.org/tests/435964 ID: 435965 Test: x86_64 universal install_sata@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/435965 ID: 435966 Test: x86_64 universal install_kickstart_user_creation **GATING** URL: https://openqa.fedoraproject.org/tests/435966 ID: 435967 Test: x86_64 universal install_scsi_updates_img **GATING** URL: https://openqa.fedoraproject.org/tests/435967 ID: 435968 Test: x86_64 universal install_multi **GATING** URL: https://openqa.fedoraproject.org/tests/435968 ID: 435969 Test: x86_64 universal install_multi@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/435969 ID: 435970 Test: x86_64 universal install_simple_encrypted URL: https://openqa.fedoraproject.org/tests/435970 ID: 435971 Test: x86_64 universal install_simple_free_space URL: https://openqa.fedoraproject.org/tests/435971 ID: 435972 Test: x86_64 universal install_multi_empty URL: https://openqa.fedoraproject.org/tests/435972 ID: 435973 Test: x86_64 universal install_software_raid URL: https://openqa.fedoraproject.org/tests/435973 ID: 435974 Test:
