Fedora-Cloud-30-20191129.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 1/1 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
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: Screencaster issue

[Samuel Sieb]

On 11/28/19 12:27 PM, pmkel...@frontier.com wrote:

https://ask.fedoraproject.org/t/need-help-with-screencaster/4308

I'm still left with questions I need some help with. Apparently the main 
issue with the failed attempts is things not working with Wayland. The 
explanation seemed to support this. Is this really a Gnome / Mutter 
issue? I suppose it might be that the authors of the screen casters need 
to rewrite their screen interfaces because the gstreamer or ffmpeg are 
no longer allowed as an application interface under Wayland.


According to the forum, it sounds like you have it solved now.  The 
issue is that if you're using Wayland, X applications can't read the 
screen.  Actually, Wayland apps can't do that directly either.  There's 
a new system called pipewire that provides that support now and will 
eventually take over from pulseaudio and jack as well.  You need an 
application that has support for pipewire, which I assume the latest OBS 
does 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: Proposal: Asynchronous blocker review process (using Pagure)

[Frantisek Zatloukal]

On Thu, Nov 28, 2019 at 1:31 PM Kamil Paral  wrote:

>
> 5. Once some kind of understanding of the issue is formed, a privileged
> member (e.g. a member of @fedora-qa FAS group) can start the vote by
> including a command in his comment, e.g. "START VOTE" on a separate line.
> (Note that this is just a proposal. We can easily let anyone start the
> vote, or we can allow voting right from the
> 9. If new important information appear or the vote needs to be repeated
> for any other reason, a privileged member can restart the vote e.g. by
> issuing RESTART VOTE command. (We can have more such administrative
> commands for any purpose we need, same as we have them with IRC bots).
>

It's probably just a small detail, why would we need (RE)START VOTE
commands? It seems we can vote whatever/whenever we want, bot would just
count the last VOTE +/- 1, 0 comment (or rather command) from each
participant.
___
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: 20191128.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20191127.n.0
NEW: Fedora-Rawhide-20191128.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  3
Dropped packages:2
Upgraded packages:   92
Downgraded packages: 0

Size of added packages:  616.33 KiB
Size of dropped packages:11.04 MiB
Size of upgraded packages:   5.39 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   14.52 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: perl-Test2-Tools-Explain-0.02-2.fc32
Summary: Explain tools for the Perl Test2 framework
RPMs:perl-Test2-Tools-Explain
Size:13.69 KiB

Package: php-psr-http-client-1.0.0-1.fc32
Summary: Common interface for HTTP clients
RPMs:php-psr-http-client
Size:10.78 KiB

Package: python-pycdio-2.0.0-7.fc32
Summary: A Python interface to the CD Input and Control library
RPMs:python3-pycdio
Size:591.87 KiB


= DROPPED PACKAGES =
Package: eclipse-usage-4.11.0-1.fc31
Summary: Usage reporting plug-ins for Eclipse
RPMs:eclipse-usage
Size:125.20 KiB

Package: embree2-2.17.7-3.fc32
Summary: Collection of high-performance ray tracing kernels developed at Intel
RPMs:embree2 embree2-devel embree2-examples
Size:10.91 MiB


= UPGRADED PACKAGES =
Package:  HdrHistogram-2.1.11-1.fc32
Old package:  HdrHistogram-2.1.9-8.fc31
Summary:  A High Dynamic Range (HDR) Histogram
RPMs: HdrHistogram HdrHistogram-javadoc
Size: 224.08 KiB
Size change:  14.52 KiB
Changelog:
  * Thu Oct 10 2019 Jie Kang  - 2.1.11-1
  - Update to 2.1.11


Package:  QuantLib-1.16-1.fc32
Old package:  QuantLib-1.13-4.fc31
Summary:  A software framework for quantitative finance
RPMs: QuantLib QuantLib-devel QuantLib-doc QuantLib-test
Size: 79.41 MiB
Size change:  319.50 KiB
Changelog:
  * Mon Nov 25 2019 Tom Callaway  - 1.16-1
  - update to 1.16


Package:  R-igraph-1.2.4.2-1.fc32
Old package:  R-igraph-1.2.4.1-3.fc31
Summary:  Network Analysis and Visualization
RPMs: R-igraph
Size: 17.68 MiB
Size change:  -23.92 KiB
Changelog:
  * Wed Nov 27 2019 Elliott Sales de Andrade  - 
1.2.4.2-1
  - Update to latest version


Package:  R-rgdal-1.4.8-1.fc32
Old package:  R-rgdal-1.4.7-1.fc32
Summary:  Bindings for the 'Geospatial' Data Abstraction Library
RPMs: R-rgdal
Size: 9.81 MiB
Size change:  -739 B
Changelog:
  * Wed Nov 27 2019 Elliott Sales de Andrade  - 
1.4.8-1
  - Update to latest version


Package:  accerciser-3.34.2-1.fc32
Old package:  accerciser-3.34.1-1.fc32
Summary:  Interactive Python accessibility explorer for the GNOME desktop
RPMs: accerciser
Size: 2.52 MiB
Size change:  262 B
Changelog:
  * Wed Nov 27 2019 Kalev Lember  - 3.34.2-1
  - Update to 3.34.2


Package:  bubblewrap-0.4.0-1.fc32
Old package:  bubblewrap-0.3.3-3.fc31
Summary:  Core execution tool for unprivileged containers
RPMs: bubblewrap
Size: 246.86 KiB
Size change:  10.22 KiB
Changelog:
  * Wed Nov 27 2019 Kalev Lember  - 0.4.0-1
  - Update to 0.4.0


Package:  cmake-3.16.0-1.fc32
Old package:  cmake-3.16.0-0.1.rc4.fc32
Summary:  Cross-platform make system
RPMs: cmake cmake-data cmake-doc cmake-filesystem cmake-gui 
cmake-rpm-macros
Size: 45.69 MiB
Size change:  3.34 KiB
Changelog:
  * Tue Nov 26 2019 Bj??rn Esser  - 3.16.0-1
  - Update to 3.16.0
  - Exclude test "kwsys.testProcess-5" on S390X


Package:  cockpit-208-1.fc32
Old package:  cockpit-207-1.fc32
Summary:  Web Console for Linux servers
RPMs: cockpit cockpit-bridge cockpit-dashboard cockpit-doc 
cockpit-docker cockpit-kdump cockpit-machines cockpit-networkmanager 
cockpit-packagekit cockpit-pcp cockpit-selinux cockpit-sosreport 
cockpit-storaged cockpit-system cockpit-tests cockpit-ws
Size: 17.64 MiB
Size change:  -27.35 KiB
Changelog:
  * Wed Nov 27 2019 Martin Pitt  - 208-1
  - Storage: Drop ???default mount point??? concept
  - Machines: Support transient virtual networks and storage pools
  - Machines: Sliders for disk size and memory in VM creation
  - Logs: Improve crash reporting


Package:  cockpit-ostree-180-1.fc32
Old package:  cockpit-ostree-179-2.fc31
Summary:  Cockpit user interface for rpm-ostree
RPMs: cockpit-ostree
Size: 189.97 KiB
Size change:  14.78 KiB
Changelog:
  * Wed Nov 27 2019 Martin Pitt  - 180-1
  - timeline: Use PF4 inspired background color
  - NPM dependency updates


Package:  cockpit-podman-11-1.fc32
Old package:  cockpit-podman-10-1.fc32
Summary:  Cockpit component for Podman containers
RPMs: cockpit-podman
Size: 979.67 KiB
Size change:  53.22 KiB
Changelog:
  * Wed Nov 27 2019 Martin Pitt  - 11-1
  - Fix Alert notification in Image Search Modal
  - Allow more than a single Error Notification for Container action errors
  - Various Alert cleanups
  - T

Fedora-Rawhide-20191128.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Compose FAILS proposed Rawhide gating check!
26 of 43 required tests failed, 17 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 99/161 (x86_64), 1/2 (arm)

Old failures (same test failed in Fedora-Rawhide-20191127.n.0):

ID: 490469  Test: x86_64 Server-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/490469
ID: 490470  Test: x86_64 Server-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/490470
ID: 490473  Test: x86_64 Server-dvd-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/490473
ID: 490478  Test: x86_64 Server-dvd-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/490478
ID: 490493  Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/490493
ID: 490494  Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation
URL: https://openqa.fedoraproject.org/tests/490494
ID: 490495  Test: x86_64 Server-dvd-iso install_repository_hd_variation
URL: https://openqa.fedoraproject.org/tests/490495
ID: 490496  Test: x86_64 Server-dvd-iso install_vnc_server
URL: https://openqa.fedoraproject.org/tests/490496
ID: 490498  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/490498
ID: 490499  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/490499
ID: 490502  Test: x86_64 Server-dvd-iso install_vncconnect_server
URL: https://openqa.fedoraproject.org/tests/490502
ID: 490506  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/490506
ID: 490508  Test: x86_64 Everything-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/490508
ID: 490509  Test: x86_64 Everything-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/490509
ID: 490510  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/490510
ID: 490511  Test: x86_64 Workstation-live-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/490511
ID: 490512  Test: x86_64 Workstation-live-iso install_default_upload 
**GATING**
URL: https://openqa.fedoraproject.org/tests/490512
ID: 490525  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/490525
ID: 490526  Test: x86_64 KDE-live-iso install_no_user **GATING**
URL: https://openqa.fedoraproject.org/tests/490526
ID: 490527  Test: x86_64 KDE-live-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/490527
ID: 490528  Test: x86_64 KDE-live-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/490528
ID: 490541  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/490541
ID: 490543  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/490543
ID: 490544  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/490544
ID: 490553  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud **GATING**
URL: https://openqa.fedoraproject.org/tests/490553
ID: 490554  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/490554
ID: 490555  Test: x86_64 universal install_kickstart_user_creation 
**GATING**
URL: https://openqa.fedoraproject.org/tests/490555
ID: 490556  Test: x86_64 universal install_scsi_updates_img **GATING**
URL: https://openqa.fedoraproject.org/tests/490556
ID: 490557  Test: x86_64 universal install_multi **GATING**
URL: https://openqa.fedoraproject.org/tests/490557
ID: 490558  Test: x86_64 universal install_multi@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/490558
ID: 490559  Test: x86_64 universal install_no_swap
URL: https://openqa.fedoraproject.org/tests/490559
ID: 490560  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/490560
ID: 490561  Test: x86_64 universal install_blivet_ext3
URL: https://openqa.fedoraproject.org/tests/490561
ID: 490562  Test: x86_64 universal install_blivet_xfs
URL: https://openqa.fedoraproject.org/tests/490562
ID: 490563  Test: x86_64 universal install_blivet_software_raid
URL: https://openqa.fedoraproject.org/tests/490563
ID: 490564  Test: x86_64 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/490564
ID: 490565  Test: x86_64 universal install_kickstart_firewall_disabled 
**GATING**
URL: https://openqa.fedoraproject.org/tests/490565
ID: 490566  Test: x86_64 universal install_pxeboot
URL: https://openqa.fedoraproject.org/tests/490566
ID: 490567  

Re: Proposal: Asynchronous blocker review process (using Pagure)

[Kamil Paral]

On Thu, Nov 28, 2019 at 5:59 PM Lukas Ruzicka  wrote:

>
> 7. People vote by submitting comments containing VOTE +1/0/-1 on a
>> separate line (and including any justification or feedback they wish in the
>> comment as well; the command has to simply be on its own line so that we
>> can detect it well).
>>
>
> The VOTE must be only +1 or -1. Indecisive people do not need to put that
> down, they just can do nothing.
>

The idea behind voting is that we can distinguish people who abstain from
the vote from people who haven't voted yet. The summary at the top of the
issue (populated by the bot) could look like this:

Voting summary:  *+2,1,-1*
+1:
  kparal (hyperlink to comment)
  jskladan (hyperlink to comment)
0:
  lruzicka (hyperlink to comment)
-1:
  lbrabec (hyperlink to comment)

Commented but haven't voted yet:
  adamwill
  fzatlouk

Because Pagure supports Markdown, we can create pretty summaries that
actually contain links to where each individual provided their comment,
without overloading the content with hyperlinks. We can also easily see
who's missing from the vote, or perhaps mistyped their vote and hasn't been
counted. The overall vote summary is displayed in the same format FESCo
uses for voting "(plus votes, ambivalent votes, minus votes)".
___
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

Screencaster issue

[pmkel...@frontier.com]

I've been needing a screen caster for a while. I starting "auditioning" 
them and ran into a consistent problem. The folks at Ask Fedora got me 
to a good place and provided an explanation as to why the video wasn't 
working (link next).


https://ask.fedoraproject.org/t/need-help-with-screencaster/4308


I'm still left with questions I need some help with. Apparently the main 
issue with the failed attempts is things not working with Wayland. The 
explanation seemed to support this. Is this really a Gnome / Mutter 
issue? I suppose it might be that the authors of the screen casters need 
to rewrite their screen interfaces because the gstreamer or ffmpeg are 
no longer allowed as an application interface under Wayland.



Thanks and Have a Great Day!

Pat (tablepc)
___
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: Proposal: Asynchronous blocker review process (using Pagure)

[Kamil Paral]

On Thu, Nov 28, 2019 at 5:14 PM Adam Williamson 
wrote:

> So overall I agree with a lot of what you wrote. It does cause me to
> wonder if writing some kind of plugin/extension for Pagure, or just
> writing the functionality into the blockerbugs app, might possibly be
> *less* work than writing and maintaining the 'blocker bot', however.


You mean patching Pagure to allow for voting? It's pretty specific to our
use case, I'm not sure if Pagure would be interested in having that. There
is something similar on Github/Gitlab by acking/nacking a pull request, but
that is for PRs where it makes sense. We would need to use it on tickets,
where it generally doesn't make much sense. I also considered voting by
adding thumbs-up/thumbs-down reactions (already supported by Pagure), but
that is a process that doesn't create any activity log and the result can
be arbitrarily changed at any time, even after voting has ended.

The process of VOTE +1/0/-1 and updating the summary is very lightweight on
the blocker bot functionality (it should be really trivial to implement)
and it doesn't hurt us much if the bot goes unresponsive - counting
manually is not that much work. I see voting in BBA as a much more daunting
task, because of authentication, notifications, long term logging, making
sure the service is up at all times, etc. Also it wouldn't make much sense
to have discussion and voting at two separate places, which means having
the discussions in BBA as well, which brings yet more requirements.

The other part of the bot, mainly updating blocker bugs in Bugzilla
automatically, was something we've talked about a long time and that can't
be done with any Pagure extensions etc.


> My
> other concern would be that if we use something other than the
> blockerbugs app or Bugzilla, we now have *three* different systems
> involved in the blocker review process - Bugzilla, the blockerbugs app,
> and the discussion system. That seems like a lot of moving parts to
> keep synchronized.
>

That is a valid concern. But, we already have three systems, the third
being IRC :-) And that would get replaced by Pagure. If IRC is down, our
processes are negatively affected (the same would happen if Pagure was
down). My main goal is to avoid being overly reliant on BBA. If Bugzilla or
Pagure are down, it's a Fedora-wide crisis and it will get resolved
promptly. If BBA is down, just a few people from our team can do something
about it, and if that is a complex issue, the priority to getting external
help is much lower than with Bugzilla or Pagure. I also want us to stay
away from the sysadmin roles as much as we can. So BBA (including the
blocker bot, if we want to distinguish that) plays, in my ideal world, just
a support role, but we don't depend on it. If things break, we can always
do the same thing manually (list proposed blockers in bugzilla, have the
discussion there or elsewhere, then set the right fields, etc). And that
principle is valid even in the proposed scenario.

You are right that synchronization issues might occur, especially when we
start displaying the same data in several places. The canonical source is
and will be Bugzilla, but we display blocker/FE status in BBA and now the
same info would be visible through Pagure ticket tags. That... might not be
a good idea. I was thrilled by the idea of having an easy-to-look-at and
easy-to-use list of current and past blockers/FEs (because often I need to
find a past accepted/rejected blocker and that is a painful experience
using Bugzilla), but it's not necessary. All the tags are just sugar on
top. Perhaps we should start without it, and add it later, if we feel it
would be useful and we have no synchronization issues.
___
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: For today's agenda item - Proposed disk unmount test case

[Chris Murphy]

On Thu, Nov 28, 2019 at 12:28 PM Chris Murphy  wrote:
>
> XFS kernel (since /etc/fstab sets / fs_passno to 0, we should only see
> this message with default installations)
> [  372.027026] XFS (vdb3): Starting recovery (logdev: internal)

Rats, the part in parenthesis is confusing. Rewrite: (we should only
see this message)

This message is what we'd see pretty much no matter what, including
the Fedora Server case which defaults to XFS. Even if fs_passno were 1
or 2 for some reason, fsck.xfs is a no op,therefore we'd still see the
above message when mount is attempted.

-- 
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: For today's agenda item - Proposed disk unmount test case

[Chris Murphy]

On Thu, Nov 28, 2019 at 2:30 AM Kamil Paral  wrote:
>
> On Wed, Nov 27, 2019 at 9:17 PM Chris Murphy  wrote:
>>
>> A fair point about VM testing is whether the disk cache mode affects
>> the outcome. I use unsafe because it's faster and I embrace misery. I
>> think QA bots are now mostly using unsafe because it's faster too. So
>> depending on the situation it may be true that certain corruptions are
>> expected if unsafe is used, but I *think* unsafe is only unsafe in the
>> event the host crashes or experiences a power failure. I do forced
>> power offs of VMs all the time and never lose anything, in the case of
>> ext4 and XFS, journal replay always makes the file system consistent
>> again. And journal replay in that example is expected, not a bug.
>
>
> By "that example", do you mean the story you just described, or the "bad 
> result example" from the test case?

The story, which is too verbose and also confusing, so just ignore it. :-D

> Because in that test case example, if the machine was correctly powered 
> off/rebooted, there should be no reason to reply journal or see dirty bits.

That should be true, yes.


>
>>
>>
>> How to test, step 2 and 3:
>> This only applies to FAT and ext4. XFS and Btrfs have no fsck, both
>> depend on log replay if there was an unclean shutdown. Also, there are
>> error messages for common unclean shutdowns, and error messages for
>> uncommon problems. I think we only care about the former, correct?
>
>
> I believe so. Is there a tool that could tell us whether the currently 
> mounted drives were mounted cleanly, or some error correction had to be 
> performed? Because this is quickly getting into territory where we will need 
> to provide a large amount of examples and rely on people parsing the output, 
> comparing and (mis-)judging. The wording in journal output can change any 
> time as well. And I don't really like that.

FAT, ext4, and XFS all have a kind of "dirty bit" set upon mount. It's
removed when cleanly unmounted. Therefore if the file system isn't
mounted, but the "dirty bit" is set, it can be assumed it was not
cleanly unmounted. Both kernel code and each file system's fsck can
detect this, and the message you see depends on which discovers the
problem first. The subsequent messages about how this problem is
handled, I think we can ignore. As you say, it will be variable. All
we care about is the indicator that it was not properly unmounted.
Here are those indicators for each file system:

FAT fsck (since /etc/fstab sets EFI system partition fs_passno to 2,
this is what's displayed for default installations)
Nov 28 12:04:21 localhost.localdomain systemd-fsck[681]: 0x41: Dirty
bit is set. Fs was not properly unmounted and some data may be
corrupt.

FAT kernel
[  205.317346] FAT-fs (vdb1): Volume was not properly unmounted. Some
data may be corrupt. Please run fsck.

ext4 fsck (since /etc/fstab sets /, /boot, /home fs_passno to 1 or 2,
this is what's displayed for default installations)
Nov 28 12:07:21 localhost.localdomain systemd-fsck[681]: /dev/vdb2:
recovering journal

ext4 kernel
[  316.756778] EXT4-fs (vdb2): recovery complete

XFS kernel (since /etc/fstab sets / fs_passno to 0, we should only see
this message with default installations)
[  372.027026] XFS (vdb3): Starting recovery (logdev: internal)


If the test case is constrained only to default installations, the
messages to test for:
"0x41: Dirty bit is set"
"recovering journal"
"XFS" and "Starting recovery"

If the test case is more broad, to account for non-default additional
volumes that may not be set in fstab or may not have fs_passno set,
also include:
"EXT4-fs" and "recovery complete"
"FAT-fs" and "Volume was not properly unmounted"

In each case I'm choosing the first message that indicates previously
unclean shutdown happened. Whether fsck or kernel message, they should
be fairly consistent in that I'm not expecting them to change multiple
times per year. The gotcha is, how would we know? Failure to
automatically parse for these messages, should they change, will
indicate a clean shutdown. *shrug*

>> Steps 4-7: I'm not following the purpose of these steps. What I'd like
>> to see for step 4, is, if we get a bad result (any result 2 messages),
>> we need to collect the journal for the prior boot: `sudo journalctl
>> -b-1 > journal.log` and attach to a bug report; or we could maybe
>> parse for systemd messages suggesting it didn't get everything
>> unmounted. But offhand I don't know what those messages would be, I'd
>> have to go dig into systemd code to find them.
>
>
> I think the purpose is to verify that both reboot and poweroff shut down the 
> system correctly without any filesystem issues (which means fully committed 
> journals and no dirty bits set).

Gotcha. Yeah, I think it's reasonable to test the LiveOS reboot as
well as the installed system's reboot, to make sure they are both
properly unmounting file systems.


-- 
Chris Murphy

Fwd: Proposal: Asynchronous blocker review process (using Pagure)

[Lukas Ruzicka]

I support the idea of an asynchronous blocker bug process.


> Blocker Bugs App (DIY solution)
> **
>
>
I am not sure how complicated that would be, but the blockerbug application
could do the stuff and in the background it could have Bugzilla as a
backed, so the Bugzilla process described later, could be controlled from
the Blocker Bugs application. This would have a strong stable backend with
all pluses and the rather Spartan looks could be replaced by more modern UI
of the Fedora Bootstrap.


>
> [1] https://qa.fedoraproject.org/blockerbugs/
>
> Mailing lists
> 
>
>
I would rather avoid this, as this needs a lot of attention, otherwise you
might overlook some important part of the communication.



>
> Bugzilla
> 
>

> Pagure
> ***
>
>
That seems the same to me. Only the medium differs. Maybe, the tagging is a
plus for Pagure.



> 7. People vote by submitting comments containing VOTE +1/0/-1 on a
> separate line (and including any justification or feedback they wish in the
> comment as well; the command has to simply be on its own line so that we
> can detect it well).
>

The VOTE must be only +1 or -1. Indecisive people do not need to put that
down, they just can do nothing.

Otherwise, I think it is ok.

>
>
> ___
> 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
>


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
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: Proposal: Asynchronous blocker review process (using Pagure)

[Adam Williamson]

On Thu, 2019-11-28 at 13:29 +0100, Kamil Paral wrote:
> What are your thoughts? Does the proposal sound reasonable? Would you
> change something? Would you use a different backend system? Have I
> forgotten something important? Feedback welcome.

So overall I agree with a lot of what you wrote. It does cause me to
wonder if writing some kind of plugin/extension for Pagure, or just
writing the functionality into the blockerbugs app, might possibly be
*less* work than writing and maintaining the 'blocker bot', however. My
other concern would be that if we use something other than the
blockerbugs app or Bugzilla, we now have *three* different systems
involved in the blocker review process - Bugzilla, the blockerbugs app,
and the discussion system. That seems like a lot of moving parts to
keep synchronized.

Thanks for working on this!
-- 
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

Proposal: Asynchronous blocker review process (using Pagure)

[Kamil Paral]

We've talked about replacing blocker bug review meetings with something
else for a long time. The meeting has an upside of a higher communication
bandwidth, but also a downside of requiring participants to be available at
the same time (throughout the world), often being extremely long, and being
scheduled just once per week (because of mentioned downsides). I've put
some thoughts into making the process asynchronous, and you can see all the
options I considered described below. I close up with a proposal for the
best choice I found.

Asynchronous blocker review process will:
- allow more people to participate (they are not restricted to a particular
time, which is inconvenient for some people)
- allow us to better gather feedback from maintainers/developers by CCing
them
- possibly allow a faster turn-around for voting (if you propose a blocker
on Tuesday, it doesn't have to wait for the next Monday's meeting)
- reduce frustration from long meetings (but perhaps add different ones)
- restrict our communication bandwidth somewhat (real-time chat makes it
easier to debug issues than e.g. email)

I think we'll need to try it first to decide if we like it or not. Here are
my thoughts for different systems we could use:

Blocker Bugs App (DIY solution)
**

We can implement all the necessary features to our Blocker Bugs App [1]. We
even talked about it in the past. There would be a Voting page where
discussions could be held for each proposed blocker, and a voting system.
We could tailor everything exactly to our needs. But it also implies a lot
of time spent in development, writing from scratch features that already
exist elsewhere (discussions, notifications, etc) and a long-term
maintenance of it (we want out blocker decisions to be available basically
indefinitely, ideally with a URL that doesn't change). I'm skeptical that
we want to devote a lot of our time to implement such a system, and I don't
even think it's a smart thing to do, if there are existing solutions
(implemented and maintained by other people) which could work "well
enough". That's why I'm mentioning this solution, but try to avoid it as
much as possible, and explore other systems below.

[1] https://qa.fedoraproject.org/blockerbugs/

Mailing lists


This is trivial to use. For every proposed blocker, we simply start a
thread on test list (with a predefined subject format), discuss & decide.
It's simple, but also quite bare-bones. We can CC people easily, but that
tends to be complicated with people not subscribed to the list. It's very
easy to see just a partial conversation, due to the usual reply headers
madness. We can link this conversation into the bug report using a
hyperkitty view (as long as we have hyperkitty), but it suffers from the
same issues, possibly showing just a partial conversation. It's very hard
to count the votes across all the replies. It's also hard to track the
status of the conversation (initial discussion, voting in progress,
resolved, etc). Overall, mailing lists are workable, but far from a good
solution, and that's why I'm looking into other solutions below.

Bugzilla


For each proposed blocker, we can create (ideally auto-create) a parallel
bug report in Bugzilla (against "distribution" or a special component that
we create). We will link those two bugs together, using Blocks or External
Trackers. Then we simply have the conversation there. We can teach Blocker
Bugs App to link to the "discussion bug" from its UI. We can easily CC and
"needinfo" other people. Bugzilla automatically sends notifications for new
comments, and anyone can subscribe to all blocker bug discussions (either
by using Bugzilla's own component watcher, or by watching the appropriate
distgit component in Pagure, if available). You can rely on having
long-term stable URLs. You can list all open and closed blocker discussions
tickets. We can use some additional status for marking "voting in progress"
(though that won't be fully obvious). This all sounds pretty good. A slight
drawback is that it's not easy to count votes - you have to go through all
the comments, find the votes and manually count them. We could create a
script that would parse all comments and update the vote summary in the
Whiteboard (or perhaps Environment or Doc Text, which is multiline) after
each discussion update. I believe Bugzilla is a decent solution for async
blocker bug meetings. Its UI is not very pretty, but it has most of the
necessary functions.

Pagure
***

This is very similar to the Bugzilla description. For each proposed
blocker, we (auto-)create a ticket in a "fedora-blockers" project, for the
purpose of a blocker discussion. We interlink the bug and the ticket. We
teach Blocker Bugs App to link to the discussion ticket from its UI. We can
easily ping other people using @name tagging. Pagure automatically sends
notifications for new comments, and anyone can subscribe to all blocker bug
discussions using Pagure UI 

Fedora-Cloud-31-20191128.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 1/1 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
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: For today's agenda item - Proposed disk unmount test case

[Kamil Paral]

On Wed, Nov 27, 2019 at 9:17 PM Chris Murphy 
wrote:

> On Wed, Nov 27, 2019 at 10:35 AM pmkel...@frontier.com
>  wrote:
>
> > https://fedoraproject.org/wiki/User:Tablepc/Draft_testcase_reboot
>
> Why does it need to happen on baremetal only? Any problem discovered
> by this test case is sure to need a deep dive no matter baremetal or
> VM.


I also tend to think that this test case doesn't need to be bare metal
exclusive.


> One thing all my Btrfs effort has taught me is how underestimated
> hardware and firmware bugs are in the storage stack (and even before
> Btrfs, the ZFS folks knew about this which is why it was invented).
>
> A fair point about VM testing is whether the disk cache mode affects
> the outcome. I use unsafe because it's faster and I embrace misery. I
> think QA bots are now mostly using unsafe because it's faster too. So
> depending on the situation it may be true that certain corruptions are
> expected if unsafe is used, but I *think* unsafe is only unsafe in the
> event the host crashes or experiences a power failure. I do forced
> power offs of VMs all the time and never lose anything, in the case of
> ext4 and XFS, journal replay always makes the file system consistent
> again. And journal replay in that example is expected, not a bug.
>

By "that example", do you mean the story you just described, or the "bad
result example" from the test case? Because in that test case example, if
the machine was correctly powered off/rebooted, there should be no reason
to reply journal or see dirty bits.


>
> How to test, step 2 and 3:
> This only applies to FAT and ext4. XFS and Btrfs have no fsck, both
> depend on log replay if there was an unclean shutdown. Also, there are
> error messages for common unclean shutdowns, and error messages for
> uncommon problems. I think we only care about the former, correct?
>

I believe so. Is there a tool that could tell us whether the currently
mounted drives were mounted cleanly, or some error correction had to be
performed? Because this is quickly getting into territory where we will
need to provide a large amount of examples and rely on people parsing the
output, comparing and (mis-)judging. The wording in journal output can
change any time as well. And I don't really like that.


>
> Steps 4-7: I'm not following the purpose of these steps. What I'd like
> to see for step 4, is, if we get a bad result (any result 2 messages),
> we need to collect the journal for the prior boot: `sudo journalctl
> -b-1 > journal.log` and attach to a bug report; or we could maybe
> parse for systemd messages suggesting it didn't get everything
> unmounted. But offhand I don't know what those messages would be, I'd
> have to go dig into systemd code to find them.
>

I think the purpose is to verify that both reboot and poweroff shut down
the system correctly without any filesystem issues (which means fully
committed journals and no dirty bits set).

If we can make all of this easy to test, then we can automate it, and it's
a worthwhile effort. If this is mostly guesswork, I wonder whether we
really need such a test case. Because yes, it is something that can go
wrong (as everything can), but it's not very likely (and if it does,
affected people will probably notice soon and file bugs). And we need to be
picky when adding test cases, because we can't test anything and
everything, we need to focus on those most important or problematic bits.
___
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