Re: Closing most games (chroimumBSU etc) causes a reset of gnome in Tue Mar 5 on Fedora 41 (rawhide)

[Kamil Paral]

> Latest update seems to have fixed it.

That's interesting. It shouldn't be in Fedora yet. I have a Fedora bug
filed here:
https://bugzilla.redhat.com/show_bug.cgi?id=2268998

and the upstream issue is here:
https://gitlab.gnome.org/GNOME/mutter/-/issues/3332

The fix was only merged yesterday upstream.
--
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Rawhide Beta Everything.iso and other ISOs -- btrfs -- serious issue

[Kamil Paral]

That sounds like this Common Issue:
https://discussion.fedoraproject.org/t/its-difficult-to-reformat-a-btrfs-partition-subvolume-in-the-installer/89052
--
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [status] Fedora CI / 2023-11-03

[Kamil Paral]

On Mon, Nov 6, 2023 at 10:32 AM Miroslav Vadkerti 
wrote:

> On Fri, Nov 3, 2023 at 4:16 PM Miroslav Vadkerti 
> wrote:
>
>> Hi all,
>>
>> Fedora CI is very well alive! We will be sending out bi-weekly updates
>> like this one about some of our plans, interesting information and status
>> updates.
>>
>> Find us on the Fedora CI matrix chat 
>> in case you would like to discuss something.
>>
>>
>> ⏱️ Plans
>>
>>-
>>
>>Close the mailing list and replace it with the Discourse tag
>>-
>>
>>Move Fedora CI Jenkins under Testing Farm infrastructure |
>>fedora-ci/general#440 
>>-
>>
>>Deprecate STI tests via Fedora 40 Change Proposal | general/issue#443
>>
>>
>>
>>  Info
>>
>>-
>>
>>It is now easy to do integration testing of Fedora packages hosted on
>>GitHub, see this blog post for details:
>>https://cockpit-project.org/blog/tmt-cross-project-testing.html
>>-
>>
>>Support for testing on AWS instances with dedicated AMD GPUs was
>>deferred to November | fedora-ci/general#422
>>
>>-
>>
>>A prototype for running tmt tests against aarch64 on a pagure.io
>>project was implemented for pagure.io/fedora-asahi/kiwi-descriptions
>>project
>>https://pagure.io/fedora-ci/general/issue/441
>>https://pagure.io/fedora-asahi/kiwi-descriptions/pull-request/48
>>
>>
>>

Thanks, it's nice to see a status report like this from time to time.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [Test-Announce] Fedora Linux 39 Final is NO-GO

[Kamil Paral]

On Wed, Oct 11, 2023 at 11:06 AM Michael J Gruber 
wrote:

> I noticed that we switched off updates-testing by default for F39
> installs very recently. Is that something that is tied to the release
> date or the final freeze date?
>

There's no exact time defined, but usually this happens shortly before we
start producing Final RC images. Pre-release testers are expected to be
able to configure it. But it's true that giving it more visibility
(announce when we disable updates-testing) would be beneficial for testing
purposes (interested people could toggle it back to enabled right away).
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Intention to tighten RPM crypto-policy back

[Kamil Paral]

On Tue, Sep 26, 2023 at 7:23 PM Alexander Sosedkin 
wrote:

> On Tue, Sep 19, 2023 at 7:47 PM Kevin Fenzi  wrote:
> > It might be good to go through all the ones that were hit by this (it
> > wasn't just chrome) and indicate if they are now fixed.
> > You can see a partial list in the common bug:
> >
> >
> https://discussion.fedoraproject.org/t/popular-third-party-rpms-fail-to-install-update-remove-due-to-security-policies-verification/70498
> >
> > and in the discussion off it.
>
> Whoa, that's too many, I suspect misreporting.
>

It was definitely accurate at the time when I wrote it :)
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Test-Announce] Re: Join now GNOME 45 Test Week

[Kamil Paral]

On Mon, Aug 14, 2023 at 5:39 AM Sumantro Mukherjee 
wrote:

> Hello,
>
> As most of you might know, with each new release of Fedora, we get a
> new GNOME and that means this is the time to test GNOME 45's new
> features. GNOME 45 test week begins today. During the course of next
> week, we will have 14-17 reserved for testing the Desktop and the Core
> Apps [0] and the rest for testing GNOME Apps that need extensive
> testing[1]
>
> As always, you can submit results for respective test days in [2] and
> [3]. The development folks and QE folks come from different time zones
> and will be available on Martix/element chatrooms as much as possible.
>
> [0]
> http://fedoraproject.org/wiki/Test_Day:2023-08-14_Fedora_39_GNOME_45_Desktop_and_Core_Apps
> [1]
> http://fedoraproject.org/wiki/Test_Day:2023-08-18_Fedora_39_GNOME_45_Apps
> [2]https://testdays.fedoraproject.org/events/1642


This is supposed to be: https://testdays.fedoraproject.org/events/162


>
> [3]https://testdays.fedoraproject.org/events/164
> --
> //sumantro
> Fedora QE
> TRIED AND PERSONALLY TESTED, ERGO TRUSTED
> ___
> desktop mailing list -- desk...@lists.fedoraproject.org
> To unsubscribe send an email to desktop-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/desk...@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Kamil Paral]

On Sat, Jun 3, 2023 at 2:43 PM Michael Catanzaro 
wrote:

> We cannot ship anything from Flathub because
> FESCo will not allow it. I don't *like* this FESCo requirement, but I
> also don't expect that to change.


I haven't studied that ruling, but perhaps the assumption was that said
software is available both on Flathub and in Fedora? If LO disappears from
Fedora, I'd consider it a good argument for re-evaluating that decision.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: It’s time to transform the Fedora devel list into something new

[Kamil Paral]

On Tue, Apr 25, 2023 at 4:21 AM Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:

> * An absurd assumption that everyone is new to the Internet, leading to
> lots
> of ridiculous gamified spam "achievements" for basic things such as
> replying
> to a thread, with which you get bothered on every single Discourse forum
> you
> (have to) sign up to.
>

This is a part I agree with. I've been very annoyed by the gamified
achievements, and I haven't found a way to completely shut them off.
Fortunately they stopped appearing after some time, perhaps I earned all of
them already. Or perhaps they were enabled on Ask, but they're not enabled
on Discussions?

Matt, is this something configurable?
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: It’s time to transform the Fedora devel list into something new

[Kamil Paral]

On Thu, Apr 20, 2023 at 11:21 PM Matthew Miller 
wrote:

> I propose that we transition devel list, and eventually most of our
> mailing lists, to Fedora Discussion (our Discourse-powered forum).
>

I've spent more than a decade perfecting my email filters and I have a
setup that works for me very well. I dislike certain aspects of mailing
lists (cross-posting, top-posting, reply-to, etc, which just can't work
well when everyone has to be vigilant all the time to do things right), but
I *like* my existing setup and processes. But that's me, us, the old timers.

Having said that, my impression is that mailing lists are an already lost
battle. If you don't have an influx of new contributors, your project is
going to die eventually. Mailing lists are a big hurdle for newcomers.
Young people are not used to it (who still uses mailing lists, in
read-write mode, except for OSS communities?), the lists are difficult to
set up, the user interfaces are bad, there are many peculiarities to be
aware of (top-posting, etc). I don't know if moving away from mailing lists
will make our contributor base grow, but I'm quite certain that staying
with mailing lists will make our contributor base **not** grow. And our
project will slowly decline over time.

Imagine that you want to contribute to a project and you discover they're
still using svn, or cvs. There are still some. I personally wouldn't be
bothered, I'd just invest time elsewhere. I value my time. I imagine this
feeling might be similar to what younger people feel when they're asked to
use a mailing list. It would require too much investment from them, and so
they'll go somewhere else with a more comfortable barrier to entry.

With some things, there's a simple transition path, because new things are
both technically superior and more comfortable at the same time, and still
extremely similar. Svn -> git. Plain git -> git with pull requests. Irc ->
Matrix. But we don't really have the same equivalent with mailing lists. I
guess mailman3+hyperkitty was supposed to be that replacement, but as we
can see, it didn't work out. A discussion forum is very different, but it's
a workflow that people are familiar with and has much easier onboarding.
Mailing lists are a lost cause. They are being abandoned, nobody migrates
*to* mailing lists. If we want to keep new blood flowing in, we can't be
afraid to change stuff. We have to adapt, instead of requiring everyone
else to adapt to us.

I already have some experience with Discourse and so far it seemed OK to
me. But I haven't used it as frequently and in such a volume as mailing
lists. I also still haven't built my workflow alternative to my email
workflow in there. But I'd be happy to experiment with it. But in order to
get real-world experience, it would be great if this was a shared
experience, where a mass of users really moves and starts using it as a
primary discussion platform. Then we can collectively figure out the
benefits and drawbacks and any workarounds for those drawbacks.

Cheers,
Kamil
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora 38 Workstation boot time and memory improvements

[Kamil Paral]

On Fri, Apr 14, 2023 at 10:28 AM Michael J Gruber 
wrote:

> > I didn't mention this in time to even discuss whether it'd make a good
> > addition to the release notes, but I think users will be happy to see
> > that Fedora 38 Workstation boots faster and uses less baseline memory
> > (measured from a session logged in to GNOME with only a terminal
> > application running to get the output of the "free" command).
>
> Interesting. Can you pin down from you analysis where the difference comes
> from, especially in user-space? I'm asking for a friend :-)
>

Just a note: GDM gets shut down after a timeout. So the stats might differ
whether you collect them directly after login or a short while afterwards.
Something to be aware of.


> ... the point being: Do upgrades profit as well, or should we review
> systemd services at boot which might remain from F37 after upgrade for new
> defaults?
>

If there are really some memory improvements in GNOME 44, it will affect
upgrades as well, of course. At this moment I'm a bit skeptical about the
presented numbers, though.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaned: hstr

[Kamil Paral]

On Thu, Mar 30, 2023 at 5:12 PM Jonathan Wright via devel <
devel@lists.fedoraproject.org> wrote:

> I've grabbed this package.  I'll keep an eye on the GH issue and get an
> update released once upstream releases patches/updates for the kernel
> issues.
>

Thanks, Jonathan. I was a happy hstr user until recently. It's hard to go
back to the regular Ctrl+r bash history.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: crypto-policies

[Kamil Paral]

On Sat, Mar 25, 2023 at 8:20 AM Neal H. Walfield  wrote:

> Panu wrote https://bugzilla.redhat.com/show_bug.cgi?id=2170878#c126 :
>
> > To me the key points here are
> > 1) there's a lot of obsolete/broken crypto out there
> > 2) we need better error messages
> >
> > Properly dealing with 2) needs an API redesign, but we'll try to work
> out some sort of bandaid solution.
>
> Are better diagnostics sufficient from your point of view, or are you
> looking for a different solution?
>

I think my question in
https://bugzilla.redhat.com/show_bug.cgi?id=2170878#c125 wasn't really
answered, or at least I don't understand the implications.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Unable to install locally built rpms

[Kamil Paral]

On Tue, Feb 28, 2023 at 11:56 AM Sérgio Basto  wrote:

> this issue definitely should go to the common bugs , IMO.
>

See the link that I posted ;)
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Unable to install locally built rpms

[Kamil Paral]

On Tue, Feb 28, 2023 at 9:39 AM Ralf Corsépius  wrote:

> Hi,
>
> [Resending here, because the test list doesn't allow me to post, there]
>
> on f38, I am unable to install any locally built package (signed with a
> local key, I have been using for many years):
>
> # rpm -U xpetri-0.4.8-0.fc38.x86_64.rpm
> error: xpetri-0.4.8-0.fc38.x86_64.rpm: Header V4 RSA/SHA256 Signature,
> key ID a6b9312e: BAD
> error: xpetri-0.4.8-0.fc38.x86_64.rpm cannot be installed
>
> # rpm -qip xpetri-0.4.8-0.fc38.x86_64.rpm
> error: xpetri-0.4.8-0.fc38.x86_64.rpm: Header V4 RSA/SHA256 Signature,
> key ID a6b9312e: BAD
> error: xpetri-0.4.8-0.fc38.x86_64.rpm: not an rpm package (or package
> manifest)
>
>
> # dnf install xpetri-0.4.8-0.fc38.x86_64.rpm
> Last metadata expiration check: 1:30:47 ago on Tue 28 Feb 2023 06:25:45
> AM CET.
> Dependencies resolved.
> ...
>  0.4.8-0.fc38  @commandline
> ...
> Installing dependencies:
> ...
> Downloading Packages:
> (1/6): XXX.rpm ...
> Total   1.2 MB/s
> | 130 kB 00:00
> ...
> Problem opening package XXX.rpm
> ...
> The downloaded packages were saved in cache until the next successful
> transaction.
> You can remove cached packages by executing 'dnf clean packages'.
> Error: GPG check FAILED
>
>
>
> Worse, after trying forcefully to install packages using rpm -U --nogpg
> this happens:
>
> # rpm -qa
> gpg-pubkey-d651ff2e-5dadbbc1
> gpg-pubkey-8ff214b4-3afa5d46
> gpg-pubkey-a6b9312e-5227e975
> gpg-pubkey-94843c65-5dadbc64
> error: rpmdbNextIterator: skipping h#   5
> Header V4 DSA/SHA1 Signature, key ID 8ff214b4: BAD
> Header SHA256 digest: OK
> Header SHA1 digest: OK
> error: rpmdbNextIterator: skipping h#   6
> Header V3 RSA/SHA1 Signature, key ID d651ff2e: BAD
> Header SHA256 digest: OK
> Header SHA1 digest: OK
> gpg-pubkey-5323552a-6112bcdc
> ...
> => nogpg is not ignored, as it is supposed to be.
>
>
> What are people supposed to do?
>

That's most certainly this problem:
https://ask.fedoraproject.org/t/popular-third-party-rpms-fail-to-install-update-remove-due-to-security-policies-verification/31594

I don't understand these security measures much, but creating a new key
using modern tools should be sufficient to resolve this. See the article to
learn how to detect and uninstall already affected packages present on your
system first.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Proposal: drop delta rpms (for real this time)

[Kamil Paral]

On Tue, Feb 21, 2023 at 9:48 PM Matthew Miller 
wrote:

> But, I think it's time to move on. We have ostree and various
> container-delta approaches. We should focus on those — and give DeltaRPMs a
> sad, fond farewell.
>

+1 from me. It will speed up the compose, and I haven't seen a positive
impact from deltarpms in a long time. They are rarely available and the
saved bandwidth is usually negligible (and reassembling of the rpm is
usually quite slow).
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unfiltered Flathub (System-Wide Change proposal)

[Kamil Paral]

On Wed, Jan 11, 2023 at 5:26 PM Ben Cotton  wrote:

> One thing I don't see addressed here is how this would impact the release
> criteria. Would it? If so, now's the time to start coordinating with the QA
> team to make those changes.
>

I think we're mostly concerned with the default experience, i.e. without
third-party repos enabled. But the toggle should definitely work, since
it's offered by gnome-initial-setup. So from the QA perspective I think
we'll be mostly focusing on whether the repos are enabled correctly if the
toggle is used, and whether the gnome-software prioritization approach
(Fedora before Flathub) works properly. At this moment, I don't see any
effect on our existing release criteria, but if anyone sees something,
please speak up.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unfiltered Flathub (System-Wide Change proposal)

[Kamil Paral]

On Wed, Jan 11, 2023 at 2:37 PM DJ Chase  wrote:

> Providing nonfree packages out of the box ultimately promotes the use of
> that nonfree software, which violates this foundation.
>

It's not out of the box. You have to *opt-in* to third-party repos (which
already contain Steam, Nvidia binary driver, etc).
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unfiltered Flathub (System-Wide Change proposal)

[Kamil Paral]

On Wed, Jan 11, 2023 at 1:22 PM Neal Becker  wrote:

> The one concern I have with this proposal is it says that flatpak version
> would only be offered if it didn't duplicate a package in fedora.
>

Citation needed. Do you mean this sentence?
> Where there are overlaps, Fedora content will be preferred over Flathub
content.

That has a completely different meaning than what you wrote. It says Fedora
content will be offered by default, but it doesn't mean the Flathub content
won't be available. In gnome-software, you'll still be able to select and
install the Flathub package, if you so desire.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unfiltered Flathub (System-Wide Change proposal)

[Kamil Paral]

On Tue, Jan 10, 2023 at 7:50 PM Ben Cotton  wrote:

> # Adjust GNOME Software so that it uses the following priority order
> when deciding which package to offer by default:
> ## Fedora Flatpaks
> ## RPMs
> ## Flathub Flatpaks
>

Thanks for this. That was my concern last time. With my QA hat on, I think
this is good to go now.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Unfiltered Flathub (System-Wide Change proposal)

[Kamil Paral]

On Wed, Jan 11, 2023 at 2:44 AM Alexander Ploumistos <
alex.ploumis...@gmail.com> wrote:

> Flathub carries programs like VLC, mpv, yt-dlp, bundled versions of
> ffmpeg and so on. Why is it ok now to get these from flathub, but not
> from RPM Fusion?
>

I guess the difference could be between a general-purpose app store, and a
collection of apps "not allowed in Fedora". IOW there is a different
purpose of existence. I'm not a lawyer, though. It's definitely a good
question to raise.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Future of BIOS RAID support in the installer

[Kamil Paral]

On Wed, Nov 23, 2022 at 6:46 PM Vojtech Trefny  wrote:

> Hi, I am planning to change how we support BIOS RAID (sometimes also
> called Firmware or Fake RAID) in the installer in the future. I plan
> to go through the official Fedora change process for Fedora 38, but
> I'd like to get some feedback first.
>
> We are currently using dmraid to support these types of RAIDs in
> blivet[1] (storage library the Anaconda installer uses) and we would
> like to replace it with mdadm. The main reason is that dmraid is no
> longer actively maintained, but it will also mean one less dependency
> for the installer (we use mdadm for the software RAID support) and one
> less service running during boot (dmraid-activation.service).
>
> The potential issue here is that mdadm doesn't support all BIOS RAID
> types. mdadm supports only Common RAID Disk Data Format standard[2]
> (DDF) and Intel Matrix Storage Technology (IMSM) so by switching to
> mdadm we would remove support for some of the older formats that
> existed before DDF was standardized. I am not sure how many people are
> still using these older RAIDs and the main reason for sending this
> email is to find out. So if you are using a BIOS RAID on your system,
> can you check what kind? You can find out simply by checking the
> filesystem type on the underlying disk(s) reported by for example
> `lsblk -f`. Types supported by mdadm are "ddf_raid_member" and
> "isw_raid_member".


Hi Vojtech. I just confirmed that our Fedora QA test machine in Brno has
isw_raid_member-type RAID, so I'm happy to report that we can continue
testing Firmware RAID even after this change ;-)

Kamil
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Remove initial-setup from KDE Spin & Kinoite (Self-Contained Change proposal)

[Kamil Paral]

On Mon, Nov 14, 2022 at 10:34 PM Ben Cotton  wrote:

> We currently don't use the initial-setup application in the main KDE
> Spin and Kinoite installation ISOs as everything gets configured at
> installation time via Anaconda.


While that's true, wouldn't it make sense to adjust Anaconda to require a
regular admin user created during installation? Because currently you
either need to set root password or create a regular admin user in
Anaconda, and if you only set up root, you're offered to create the regular
user in the initial-setup. If you drop initial-setup, that workflow is not
possible anymore. According to our recent conversation in the kde list, it
seems you'd like to make sure a regular admin user gets created every time.
I think it would make sense to configure Anaconda this way at the same time
as initial-setup is dropped.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Test-Announce] Help test backlight control changes on old laptops in the upcoming kernel

[Kamil Paral]

Hello,

kernel 6.1 or 6.2 will change how laptop backlight is handled and it might
negatively affect some laptops, especially older ones. Hans De Goede, the
developer of that change, asks for wider community testing. Here are his
blog posts containing all necessary instructions:

* Part 1: https://hansdegoede.livejournal.com/26427.html
* Part 2: https://hansdegoede.livejournal.com/27130.html

If you can, please help him identify affected laptops, so that this change
can be prepared with a minimum negative impact. All results are to be
submitted directly to Hans (not to this list), as described in the blog
posts.

Thank you!
Kamil Páral
Fedora QA
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Modernize Live Media (System-Wide Change proposal)

[Kamil Paral]

On Tue, Oct 18, 2022 at 10:43 PM Ben Cotton  wrote:

> There should be new options for resetting the persistent overlay and
> booting with no persistence. The default options should boot with
> persistence and setup of persistence should work.
>

Neal, Matt, what is the rationale for enabling persistence for the default
boot option? I have mixed opinions about this. One of the benefits of a
Live image, as we use it today, is that it's always the same/fresh. If I
use it and then hand it over to a friend/colleague, I don't need to worry
that some personal files (like a browser history) were left behind. I also
don't need to worry that I (or the previous user) made some changes which
would negatively impact the installation process or my user environment
(like configuring a different keymap, or installing some updates). It's
always as the creators intended. With the proposed Change, suddenly I need
to care and need to worry.

My impression is that currently persistence use is basically non-existent.
Our well-advertised tools like Fedora Media Writer don't support it. Even
if we flip this to make it easily available (which is probably a good
thing), how many users do you estimate would actually want to make use of
it? Who would want to work from a Live image regularly? I'm sure there are
some use cases, but they seem so niche to me, that making it a non-default
boot option wouldn't be a problem at all.

I wonder if you've thought about this and why you decided to propose making
it enabled by default. Thanks.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Test-Announce] Fwd: Fedora IoT Test Week Occurring Now!

[Kamil Paral]

Forwarding a test day announcement from Geoff:

Hello testers!

Just a heads up: the IoT Test Week is occurring now! [0]

Please add your results to the test week page [1] and feel free to chat in
#fedora-test-day on libera.chat.

Note, in case you tried to test earlier in the week and were faced with bad
linked test images, the links have been fixed and you should be able to
download and install now!

Geoff Marr
IRC: coremodule

[0] https://fedoraproject.org/wiki/Test_Day:2022-09-19_Fedora_37_IoT_Edition
[1] https://testdays.fedoraproject.org/events/142
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Heads up: GNOME 43.0 megaupdate is in testing

[Kamil Paral]

On Wed, Sep 21, 2022 at 6:02 PM Kamil Paral  wrote:

> On Wed, Sep 21, 2022 at 10:30 AM Kalev Lember 
> wrote:
>
>> This is the GNOME version that's we'll be shipping F37 Final with, so
>> please make sure to test it and file issues for things that would need
>> fixing before F37 GA. I'd suggest starting upstream at gitlab.gnome.org
>> for most issues, and then letting me (and other people) know in
>> #fedora-workstation if anything needs backporting to Fedora (since there
>> won't be any more upstream releases before F37 Final).
>
>
> Hi Kalev,
> while it's not essential, I find it unfortunate that Night Light controls
> are now broken, I think many people use it:
> https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2056
> It should be fixed by this commit (I haven't tested it), but it seems it's
> not present in mutter-43.0-1:
> https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2623
>
>
And another important mutter fix seems to be this one:
https://bugzilla.redhat.com/show_bug.cgi?id=2128660
https://gitlab.gnome.org/GNOME/mutter/-/issues/2387
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2624
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Heads up: GNOME 43.0 megaupdate is in testing

[Kamil Paral]

On Wed, Sep 21, 2022 at 10:30 AM Kalev Lember  wrote:

> This is the GNOME version that's we'll be shipping F37 Final with, so
> please make sure to test it and file issues for things that would need
> fixing before F37 GA. I'd suggest starting upstream at gitlab.gnome.org
> for most issues, and then letting me (and other people) know in
> #fedora-workstation if anything needs backporting to Fedora (since there
> won't be any more upstream releases before F37 Final).


Hi Kalev,
while it's not essential, I find it unfortunate that Night Light controls
are now broken, I think many people use it:
https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2056
It should be fixed by this commit (I haven't tested it), but it seems it's
not present in mutter-43.0-1:
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2623
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Release criteria proposal: except BitLocker-enabled installs from Windows dual-boot criterion bootloader requirement

[Kamil Paral]

On Mon, Sep 19, 2022 at 9:17 PM Adam Williamson 
wrote:

> "The installer must be able to install into free space alongside an
> existing clean Windows installation. As long as the Windows
> installation does not have BitLocker enabled, the installer must also
> install a bootloader which can boot into both Windows and Fedora."
>

The updated criterion sounds OK to me.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: FYI: livesys and livesys-late init.d files left over after Fedora installation

[Kamil Paral]

On Mon, Sep 19, 2022 at 10:46 AM Marius Schwarz 
wrote:

>
> Hi,
>
> if Fedora 35 Liveimage is used to install Fedora, livesys and
> livesys-late initscripts are incorrectly copied onto the system
> or not deleted after they lost their functionality.
>

That's not a bug, that's expected. They should be no-op on the installed
system. Nobody cared enough to come up with a better system yet. But now
that fedora-autofirstboot exists, I filed a ticket about it here:
https://pagure.io/fedora-autofirstboot/issue/3
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Check out the Fedora Packager Dashboard!

[Kamil Paral]

On Thu, Aug 25, 2022 at 11:43 AM Artur Frenszek-Iwicki <
s...@fedoraproject.org> wrote:

> For example, at the top of the page, there's a bunch of numbers. I have no
> idea what they mean.
> Hovering over each of these displays a tooltip - which is nice - but five
> seconds after that tooltip disappears,
> I'll forget the meaning and the numbers will go back to being visual
> clutter. It would be immensely helpful
> to have some symbolic icons next to the numbers, which would allow to
> easily guess what each of them means.
>

According to your description, your browser might be broken, perhaps due to
some content blocking?
See this screenshot, there are symbolic icons everywhere, there's a
Settings cog in upper right, etc:
https://i.imgur.com/gFKDUT2.png

File a bug, if the missing icons are not caused by your customized browser
configuration.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: future of dual booting Windows and Fedora, redux

[Kamil Paral]

On Fri, Jul 29, 2022 at 2:32 PM Chris Murphy 
wrote:

> On Fri, Jul 29, 2022, at 4:38 AM, Kamil Paral wrote:
>
> Currently there is this (insufficient, of course):
>
> https://ask.fedoraproject.org/t/windows-with-encrypted-disks-bitlocker-cant-be-booted-from-the-grub-boot-menu/20612
>
>
> Looks pretty good actually. What's missing or unclear?
>

The workarounds section is bare bones. It needs to be made into a full
proper guide, so that less experienced users can also follow it.


> I think we should consider swapping the built-in bootmanager and
> efibootmgr sections. The efibootmgr section needs enhancement first: how to
> find the Windows boot entry number; use case 1: do a one time boot of
> windows with --bootnext; use case 2: persistently make Windows or Fedora
> the default boot OS with --bootorder; use case 3: boot Fedora from Windows
> when Windows is the default boot OS. Each with examples and screenshots.
>
> The efibootmgr CLI is a consistent interface for everyone. It's much
> easier to document concisely. The firmware method defies screenshots or
> examples. I'd either make it a secondary section or remove it, but have no
> strong feeling about it.
>

I believe both approaches should be present, but I don't feel strongly
about ordering. When you want to boot a secondary OS (let's say Windows),
the firmware option (when it works and you know how to trigger it) feels
more natural to me, and is definitely more friendly than asking general
users to run a cryptic command in a terminal as root. Also, booting Fedora,
logging in and running a command just to be able to get into Windows is not
the definition of a smooth experience for me. It would be a bit better with
a GUI tool and even better if it could be done from GDM, but still an
annoyance in all cases. Pressing e.g. F12 after starting the PC is the
fastest way. It all depends how often you need to get to the secondary OS,
or whether there are e.g. multiple users, some of them using Fedora and
some of them Windows, on the same PC. The preferences can then differ a lot.


> I'd like to see some proper guide available in Fedora Docs/Quick Docs/wiki
> that I could reference from that Common Issue entry.
>
>
> I'd like Ask and Quickdoc to be essentially identical. This no conflicting
> info between them. Each is a single authoritative source. And each should
> be updated in parity.
>

The Common Issues section on Ask isn't supposed to contain full-length
articles, howto's, guides. At least how I imagine it. I'd prefer having a
good guide written somewhere (Docs), and just link to it from Common
Issues. The purpose of Common Issues is to highlight important and highly
visible problems affecting lots of users, provide some links and context
and a workaround if available, or a link to a system update when the fix is
ready.

If the current situation (can't boot Windows from GRUB on UEFI under
certain conditions) becomes a feature instead of a bug, e.g. because we are
unable to solve it and we remove the GRUB boot menu on all UEFI machines
altogether as proposed, I'd even want it removed from Common Issues. It's
really only supposed to document release bugs. General troubleshooting,
howto's and guides should be elsewhere. We already somewhat discussed that
with Mattdm when people wanted to add e.g. instructions on how to configure
the proprietary nvidia driver, etc. It's not a bug -> we should have a
separate section for these guides (on Ask/Docs/elsewhere), be it
proprietary driver common steps, dual-boot configuration common steps, or
anything similar.


> One pretty big weakness I missed in the summary: the non-functional
> Windows menu item in GRUB. That's quite a trap. I'm not sure any
> documentation adequately addresses this. But I also don't know an easy way
> to detect this situation and either inhibit creation of or remove this item.
>

I suppose Anaconda would have to be involved, detect encrypted partitions
and provide a hint when the bootloader is created. It would be a static
solution, far from ideal, but arguably better than the current state.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: future of dual booting Windows and Fedora, redux

[Kamil Paral]

On Thu, Jul 28, 2022 at 6:52 PM Chris Murphy 
wrote:

> Short term approaches:
>
> - Documentation: GRUB's Windows boot option may not work, how to use
> efibootmgr --bootnext and --bootorder
>

Currently there is this (insufficient, of course):
https://ask.fedoraproject.org/t/windows-with-encrypted-disks-bitlocker-cant-be-booted-from-the-grub-boot-menu/20612

I'd like to see some proper guide available in Fedora Docs/Quick Docs/wiki
that I could reference from that Common Issue entry.


> In the near term, we're looking at an awareness and documentation effort,
> while seeing how the other options shake out. And it probably doesn't
> significantly matter whether we change the release criterion now or also
> wait a bit longer.
>

We can change the criterion shortly before Final, if needed. Since we
expect the situation to improve in the future, we could just add a
(temporary) footnote to the existing criterion saying that the special case
of Windows partitions encrypted by Bitlocker are exempt from the
requirement (of booting Windows from GRUB).
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: future of dual booting Windows and Fedora, redux

[Kamil Paral]

On Tue, Jul 26, 2022 at 8:06 PM Chris Murphy 
wrote:

> a. Fix GRUB by giving it the ability to modify UEFI NRAM "bootnext" value,
> so that instead of chainloading the Windows bootloader from GRUB, GRUB will
> modify the system NVRAM such that the next boot (only) will directly boot
> the Windows bootloader. Thus far there's no interest by GRUB upstream.
> Whereas systemd-boot has implemented it.
>
> b. Add a user space utility modifies system NVRAM such that the next boot
> (only) will directly boot the Windows bootloader. And also remove the
> Windows boot entry in GRUB, on UEFI systems. (It would be retained on BIOS
> systems.)
>
> c. Change the release criterion.
>
> https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Windows_dual_boot
>
> Current: The installer must be able to install into free space alongside
> an existing clean Windows installation and install a bootloader which can
> boot into both Windows and Fedora.
>
> Replacement: The installer must be able to install into free space
> alongside an existing clean Windows installation, install and configure a
> bootloader that will boot Fedora.
>
> d. Consider the problem sufficiently difficult to fix that we need an
> extension to the exceptional case allowance, and wave the bug for another
> release.
>

I've been to numerous events where we helped students install Fedora into
dual boot. One of the top 5 questions afterwards (maybe even #1) is "how do
I make it boot Windows by default?". In the old days, that consisted of
editing the grub config file and changing the default selected value to
match the Windows boot item, or when "GRUB_DEFAULT=saved" actually worked,
I just told them "It will remember the last selected option". That was easy
enough and user friendly.

>From the proposed options, only a) satisfies that. It is a bit inconvenient
that it adds a few more seconds to the boot process (one more reboot), but
it can boot Windows by default. If I told them that they must boot Fedora
and select something in some menu every time they want to boot Windows
(option b)), that would be a gameover. Many of them wouldn't have wanted to
install Fedora in such a case. Especially for newcomers, Fedora is just an
experiment, a **secondary** option. If we can't deliver that, if we
"hijack" their computer and make Fedora the primary system, and make it
hard to get into Windows (which they intend to continue using 90% of their
time), they'll not want it.

I know that there are other approaches available, like the firmware-based
one-time boot menu invoked directly during system startup. But again, for
newcomers, if I tell them "the PC will boot Fedora by default, and if you
want Windows, you have to press F12 during startup and choose Windows",
many of them will not want it. The other way round (boot Windows by
default, press F12 to boot Fedora) might be acceptable for them -- this is
easy to achieve for power users using efibootmgr after installation, but if
Anaconda included such a configuration option, it would be accessible even
for less experienced users. There are still issues with this approach,
though:
1. I'm not sure if all systems actually support a one-time boot menu.
2. The one-time boot menu key is different on different systems, and it's
mostly not advertised during startup, and so you have to figure it out by
trial and error (or from a system manual) and remember it.
3. And some systems are configured for a "quick boot" where they actually
ignore keyboard input during startup and you can only enter it by using a
tool from a booted OS (efibootmgr or a Windows alternative, some Rescue
dialog hidden deep in system settings).

While all of us here are happy to run Fedora by default, let's not forget
about newcomers and their needs, because our user base will die out
otherwise.

So, in the ideal world, a combination of approaches would be accessible.
Option a) to support booting Windows by default (or Fedora, or whatever you
picked last), and also a userspace graphical utility which would allow
users to set the Windows bootloader as default, therefore saving some
seconds on each boot. Of course it would include a guide on how to figure
out and test the one-time boot menu first, and allow them to change the
default bootloader back to Fedora if they wish.

If there's not enough will to implement option a) (or some workaround with
the same effect), we'll have to change our release criterion (option c) -
I'd probably propose some changes to the wording). I don't see any benefit
in delaying the status quo (option d)). But we should also clarify the
situation to our users. On the Fedora download page, we should make it
clear that users with an encrypted drive will not be able to boot Windows
out of the box anymore, and they'll need to take additional steps to get
into Windows. That might include a tool in Fedora (option b)), or figuring
out how to get to a one-time boot menu. It should also contain instructions
on how to switch back to 

Automated reports redirected into a new mailing list: test-reports

[Kamil Paral]

Hello testers and developers,

please note that we've set up a new mailing list called test-reports [1]
and we've redirected all automated compose/updates/test/etc reports into
it. These reports were previously sent to the test list and devel list and
created a lot of visual noise among regular conversations (especially in
the test list). You can see test-reports archives [1] to see which emails
I'm talking about. The only exception is the main rawhide compose report,
which still goes to the devel list (as well as test-reports), because it
was deemed useful enough to be kept there.

If you're interested in receiving these reports, please subscribe to the
new list. The default reply is set to go to the test list, where we can
have conversations about any suspicious changes/outcomes, but you can of
course start your discussion in the devel list, if you prefer.

Cheers,
Kamil
Fedora QA

[1]
https://lists.fedoraproject.org/archives/list/test-repo...@lists.fedoraproject.org/
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-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/devel-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Test-Announce] Automated reports redirected into a new mailing list: test-reports

[Kamil Paral]

Hello testers and developers,

please note that we've set up a new mailing list called test-reports [1]
and we've redirected all automated compose/updates/test/etc reports into
it. These reports were previously sent to the test list and devel list and
created a lot of visual noise among regular conversations (especially in
the test list). You can see test-reports archives [1] to see which emails
I'm talking about. The only exception is the main rawhide compose report,
which still goes to the devel list (as well as test-reports), because it
was deemed useful enough to be kept there.

If you're interested in receiving these reports, please subscribe to the
new list. The default reply is set to go to the test list, where we can
have conversations about any suspicious changes/outcomes, but you can of
course start your discussion in the devel list, if you prefer.

Cheers,
Kamil
Fedora QA

[1]
https://lists.fedoraproject.org/archives/list/test-repo...@lists.fedoraproject.org/
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Kamil Paral]

On Wed, Jun 29, 2022 at 8:42 PM Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:

> > Flathub should only be preferred when there is no Fedora Flatpak
> available.
>
> I don't see it in the proposal.
>

I see:
"GNOME Software will prefer Fedora flatpaks over Flathub flatpaks"

What is *not* in the proposal and should be added is a clarification
whether Fedora RPMs or Flathub flatpaks take precedence, when both exist
(and a Fedora flatpak doesn't). My preference would be:
Fedora flatpak > Fedora RPM > Flathub
or
Fedora RPM > Fedora flatpak > Flathub

If this is the case, I believe this Change is a great benefit to Fedora.
I'd be worried if we prioritized third-party software over our own builds.
Yes, the security is better with flatpak over rpm, but there are also other
aspects. Like having things under our own control, or having a pretty good
pre-release testing processes (updates-testing, bodhi, karma) compared to
flathub.

On Thu, Jun 30, 2022 at 4:50 PM Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:

> I would prefer a non-sandboxed app instead of a third-party DEB repack.


And nobody is taking that option away from you ;-)
You've made your preference known. Repeating it numerous times doesn't
contribute to a pleasant discussion.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Fallback Hostname (System-Wide Change proposal)

[Kamil Paral]

On Tue, Jun 14, 2022 at 4:50 PM Michael Catanzaro 
wrote:

> I think we should add this.
>
> However, gnome-initial-setup is a bit late because currently anaconda
> uses hostname to name your btrfs subvolumes. :(
>
> anaconda would perhaps be a better place, but only if it uses hostnamed
> so as to allow spaces, Unicode, etc. We don't want anaconda to use
> stricter rules for hostnames than the installed system does.
>

I think we currently hardcode all live images to have "localhost-live"
hostname in the kickstart, because of some x11 bug a long time ago which
failed with a plain "localhost":
https://pagure.io/fedora-kickstarts/blob/main/f/fedora-live-base.ks#_207

Changing it to "fedora-" would be great.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: remove-retired-packages feedback

[Kamil Paral]

On Thu, May 26, 2022 at 3:52 PM Miroslav Suchý  wrote:

> If you already upgraded to Fedora 36 - what is your feedback about
>
>
> https://docs.fedoraproject.org/en-US/fedora/latest/release-notes/sysadmin/System_Utilities/#remove-retired-packages
>
> Did you run the command `remove-retired-packages`? Do you find it useful?
> Comments and ideas are welcome either here or at:
>

I found it very useful, thank you. I'd like to see support for --help and
also an execution mode that only prints the retired packages and doesn't
ask for a sudo password.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Updated criteria proposal: networking requirements

[Kamil Paral]

On Sat, Jun 4, 2022 at 1:36 AM Adam Williamson 
wrote:

> Any more thoughts, comments, adjustments etc? Thanks!
>

Which milestone is this supposed to block? It sounds fine (to my networking
layman ears).
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: The future of FMN (Fedora Messaging Notifications)

[Kamil Paral]

On Sat, May 14, 2022 at 11:40 AM Aurelien Bompard <
abomp...@fedoraproject.org> wrote:

> Hey folks!
>
> After spending some time evaluating our options, CPE's Advance
> Reconnaissance Team came up with this proposal for the next version of FMN:
>
> https://fedora-arc.readthedocs.io/en/latest/fmn/april2022/index.html
>
> Please check it out if you're interested, it has an analysis of the
> existing system and requirements for the next.
> And the best time for feedback is now, before the work actually starts :-)
>

One of the current issues that I don't see listed is that people receive
notifications with empty or incomplete descriptions, and often it's not
even possible why (which filter caused it and how to prevent it). For
example:


from: notificati...@fedoraproject.org
to: kpa...@redhat.com
subject: fedmsg notification  # see that even the subject is generic
content:
Notification time stamped 2022-05-14 01:48:35 UTC
https://bodhi.fedoraproject.org/updates/FEDORA-2022-af58cd6f88

It doesn't say why I received the notification, what happened to that bodhi
update, nothing. Of course in FMN settings I enabled:
"We can annotate your messages with a "triggered by" link that will let you
know which filter was responsible for triggering each message."
but it doesn't work.

Here's another example:

from: notificati...@fedoraproject.org
to: kpa...@redhat.com
subject: Fedora Notifications Digest (3 updates)
content:
Digest Summary:
1.
2.
3.  Fedora EPEL 9 Update: testcloud-0.7.1-1.el9

Very useful.

This one is my favorite:

from: notificati...@fedoraproject.org
to: kpa...@redhat.com
subject: fedmsg notification
content:
Notification time stamped 2021-12-14 08:34:53 UTC

{
"certificate":
"LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUUyakNDQkVPZ0F3SUJBZ0lDQXBzd0RRWUpL\nb1pJaHZjTkFRRUxCUUF3Z2FBeEN6QUpCZ05WQkFZVEFsVlQKTVFzd0NRWURWUVFJRXdKT1F6RVFN\nQTRHQTFVRUJ4TUhVbUZzWldsbmFERVhNQlVHQTFVRUNoTU9SbVZrYjNKaApJRkJ5YjJwbFkzUXhE\nekFOQmdOVkJBc1RCbVpsWkcxelp6RVBNQTBHQTFVRUF4TUdabVZrYlhObk1ROHdEUVlEClZRUXBF\nd1ptWldSdGMyY3hKakFrQmdrcWhraUc5dzBCQ1FFV0YyRmtiV2x1UUdabFpHOXlZWEJ5YjJwbFkz\nUXUKYjNKbk1CNFhEVEU0TURreU5qSXpNalV3T0ZvWERUSTRNRGt5TXpJek1qVXdPRm93Z2VReEN6\nQUpCZ05WQkFZVApBbFZUTVFzd0NRWURWUVFJRXdKT1F6RVFNQTRHQTFVRUJ4TUhVbUZzWldsbmFE\nRVhNQlVHQTFVRUNoTU9SbVZrCmIzSmhJRkJ5YjJwbFkzUXhEekFOQmdOVkJBc1RCbVpsWkcxelp6\nRXhNQzhHQTFVRUF4TW9abVZrYlhObkxXMXAKWjNKaGRHbHZiaTEwYjI5c2N5NW1aV1J2Y21Gd2Nt\nOXFaV04wTG05eVp6RXhNQzhHQTFVRUtSTW9abVZrYlhObgpMVzFwWjNKaGRHbHZiaTEwYjI5c2N5\nNW1aV1J2Y21Gd2NtOXFaV04wTG05eVp6RW1NQ1FHQ1NxR1NJYjNEUUVKCkFSWVhZV1J0YVc1QVpt\nVmtiM0poY0hKdmFtVmpkQzV2Y21jd2dnRWlNQTBHQ1NxR1NJYjNEUUVCQVFVQUE0SUIKRHdBd2dn\nRUtBb0lCQVFEUm4xd1E1UVZwN2JCdUpFUjlNOUkwZ2o0WHB0NTlFZDdnU1p2RVQvcSsrUVNFb0x2\nWApkb0tnOTdkWXhZK2FPdll1TDAzc1lOdjZEcmJLZVM2blk5V1dwKytoZ1hUMXBEaFY3QmRxeitt\nNFoxbDhsYjFHCi9mZHAwd1FON0RMVndDclYyTmNSajZ6b2J0NHV2Z0JYaWtVUWhRNjl5V2E2VE9D\nTis5OWEwUUtjTUJzNENuNTAKc2pmUTNGQUNsV1B3NUhkNkNPMHJWenhPODRROGc0bEpCcTRubHY0\nc0xRVmZoZTNoZWMzTEFObUt2RGNSc3JpbgpDUXFGdFF5MVNmR0pHWnE4RkEyUDhkckVCd1BqdnZx\nMTJ4MHJucEJjdVM5bXlLQmhOYVE3eSs5bE9GTXJSZFBrCmRaUXY0eGdSU0FzZGJQRDlyeXYrTE1n\nS1YvVnVTdm11RzF0eEFnTUJBQUdqZ2dGWE1JSUJVekFKQmdOVkhSTUUKQWpBQU1DMEdDV0NHU0FH\nRytFSUJEUVFnRmg1RllYTjVMVkpUUVNCSFpXNWxjbUYwWldRZ1EyVnlkR2xtYVdOaApkR1V3SFFZ\nRFZSME9CQllFRkM0anZCbmhFSnRDTkxHaTg5UHgreU41K1VNa01JSFZCZ05WSFNNRWdjMHdnY3FB\nCkZHdEFXdmtTQ0lsWjUxbmxCZlVDSFFwT2Z4UUFvWUdtcElHak1JR2dNUXN3Q1FZRFZRUUdFd0pW\nVXpFTE1Ba0cKQTFVRUNCTUNUa014RURBT0JnTlZCQWNUQjFKaGJHVnBaMmd4RnpBVkJnTlZCQW9U\nRGtabFpHOXlZU0JRY205cQpaV04wTVE4d0RRWURWUVFMRXdabVpXUnRjMmN4RHpBTkJnTlZCQU1U\nQm1abFpHMXpaekVQTUEwR0ExVUVLUk1HClptVmtiWE5uTVNZd0pBWUpLb1pJaHZjTkFRa0JGaGRo\nWkcxcGJrQm1aV1J2Y21Gd2NtOXFaV04wTG05eVo0SUoKQU9OUUhrZFBGeDVGTUJNR0ExVWRKUVFN\nTUFvR0NDc0dBUVVGQndNQ01Bc0dBMVVkRHdRRUF3SUhnREFOQmdrcQpoa2lHOXcwQkFRc0ZBQU9C\nZ1FBQnFBcDQzd3lUbk5XUUJYODUzSEVEUEpDTTM4aVJTdlV3dzFCejd4MmFpSWpuCkVPTWZ1djhB\nTEV2Z2JXeDhSc0RBNTluRkNXS1FJRWdGeEFBcUFMUFJwYWF3dFRUcnN1VlQ3bFhlSEhrU21VblEK\ncEdKSFd1elU2OUZibFdaWkpDTVQzUTRVYWNUa0VHNE1XMFFqOWp1aFNpM2lHOHZXVXZlMTEzUTNL\nMDhmVHc9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==\n",
"crypto": "x509",
"i": 2390172,
"msg": {
"bug": {
"alias": [],
"assigned_to": "kpa...@redhat.com",
"cc": [],
"cf_atomic": "",
"cf_category": "",


I love receiving json dumps.

Of course these are just examples I could quickly find. I don't need to
debug them. I roughly know why I received them. But in the past, I
sometimes received a notification that I really had zero idea why I got it.
Also, I sometimes received a completely empty email, IIRC. The problem is,
I believe, that FMN doesn't require the "event->human description"
formatter to exist. If it does, it uses it, but if it doesn't, it sends you
a blank email, a json dump, a bare link, whatever it finds in the raw
event. That really shouldn't happen. I only kept FMN enabled because those
emails are 

Re: F37 Change: Legacy Xorg Driver Removal (System-Wide Change proposal)

[Kamil Paral]

On Thu, Apr 7, 2022 at 10:06 PM Ben Cotton  wrote:

> https://fedoraproject.org/wiki/Changes/LegacyXorgDriverRemoval
>
> == Summary ==
>
> This change will remove the `xorg-x11-drv-vesa` and
> `xorg-x11-drv-fbdev` driver packages, and associated support code from
> the `xorg-x11-server-Xorg` package.
>

Adam, I'm sure this proposal is related to your comment here:
https://bugzilla.redhat.com/show_bug.cgi?id=2067151#c42

Thanks for creating it as a Change.

Can you please clarify what happens to the "basic graphics mode" boot
options on our install media? As I understand it, it's required to let
Fedora boot on systems with unsupported/broken driver graphics. So I assume
this basically means a) old hardware which doesn't get much testing and
drivers bitrot, b) completely new hardware for which the drivers are not
yet ready, and c) nvidia (nouveau has a high failure rate, afaik)? Is this
summary correct? How many nvidia users will get affected? What happens in
any of those cases, will those users not be able to run a Fedora installer
at all? Will they need to run netinst in text mode, or will even text mode
be unsupported? What will they do instead?

In my personal experience, I had to use basic graphics mode on one laptop
which had an extremely old Radeon driver, and Fedora installer simply
didn't boot on it. So the basic graphics mode was a way to at least install
the system, and then I could start experimenting with different kernels or
trying some advice from the net. But the installation must be done first,
in some way.

In a similar fashion, there is sometimes a new GPU launch which is not
supported on our latest stable installer (because it has an old
kernel/mesa), and installing Rawhide is... hard to recommend, not to
mention it's often very broken. So enthusiasts with the latest GPU can
install Fedora using basic graphics mode, and then fully update their
system and switch to a regular driver. What will they do after this Change?

Thanks.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Possible regression in GNOME in Fedora 36 Branched 20220401.n.0

[Kamil Paral]

On Tue, Apr 5, 2022 at 6:14 AM Ian Laurie  wrote:

> I've done some playing and it looks like it is the first resize after
> the first login after a boot causes it.  After that it doesn't seem to
> happen (or it is very infrequent if it does).
>

I'm quite certain it's this:
https://ask.fedoraproject.org/t/connecting-disconnecting-an-external-monitor-switches-gnome-to-the-login-screen/21076
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [IPP-over-USB printers/scanners] Expected breakage when ipp-usb+a driver are installed

[Kamil Paral]

Hi Zdenek,
a QA person here. This sounds like it's going to be a major headache for us
(and our users), I hope I'm wrong. I initially skipped your message,
because it was too technical (seemed targeted at system admins, not regular
users) and I don't know half of the printer-related abbreviations and
terms. I guess my blissful ignorance ends :-)

I very much like how Chris summarized the problem in a more user-friendly
language in test list [1]:

> The very rudimentary summary is:
> 1. When upgrading (does not apply to clean installs);
> 2. with a printer that supports ipp-usb (a.k.a. driverless printing);
> 3. using the native driver (which can be a cups filter, free or nonfree)
> Printing breaks.
>

I believe this is something that was missing from your announcement.

I tried to create a Common Issues entry for our users here:
https://ask.fedoraproject.org/t/common-issues/20975

Please help me finish it by directly editing or suggesting additions and
fixes in comments. That text should be readable and actionable by an
average Joe, deep technical details can be linked. This is all just
printer-related, scanners didn't fit into my brain for the moment, they'll
get a separate treatment.

This looks like a major change, I wonder why it wasn't included in F36
ChangeSet [2]. I think we should consider adding it there, even though it's
way past the deadline. It would make the change more visible/searchable and
also make the description and workarounds more accessible.

Now, I have a load of questions:
1. Is Chris' summary above correct?
2. Does this affect only USB printers, and no network printers?
3. Can you estimate what portion of our user base (who own printers) is
going to be affected by this? How common are printers supporting IPP over
USB?
4. If the printer doesn't support IPP over USB, what will happen? Will the
printer continue to work as usual, and the ipp-usb package will not
interfere?
5. How can an average Joe tell whether he's using a classic driver (which
is incompatible with ipp-usb)?
6. When you talk about 'removing the old print queue', is it the same as
removing the printer from system settings (e.g. gnome-control-center)?
7. If Joe removes the printer from system settings, what will happen then?
Is a reboot necessary? Will the printer magically appear there by some
autodiscovery? Or is it necessary to manually add the printer, but no
driver selection is needed? Alternatively, is it possible that the printer
will only appear in print dialogs (from different apps), but it will not be
listed in system settings?
8. Is it necessary that Joe also removes the real driver from the system
(like hplip), or will the action described above be sufficient?
9. I read that Firefox might not work with the new setup [3][4]. I'm *very*
concerned about that. Can you elaborate? When exactly will printing from
Firefox not work? For all IPP over USB printers handled through ipp-usb?
10. Can it happen that the IPP-over-USB approach offers less printing
options than its real driver counterpart? E.g. paper types, color
adjustments, etc. What if the user wants to use the real driver instead,
for these reasons, what is the recommended approach? (Ideally for an
average Joe, if possible, i.e. no lpadmin commands).
11. What can we do better during the upgrade? I read we can't fix this
perfectly. But even if the package removed all "print queues" during
installation, it would go from "My printer doesn't print and I have idea
why, I'm so angry" situation into "My printer disappeared, I had to add it
again, I'm so angry" situation (in case it wasn't IPP over USB, in which
case it would be autodetected and immediately re-appear). That seems like
an obvious lesser evil. In the first case, you have no idea what to do,
except for magically stumbling on our documentation. In the second case,
it's obvious that you need to add the printer again, if it is not there,
and so it allows users to fix the situation themselves pretty naturally. I
understand this won't work on rpm-ostree based systems, but it's still a
huge leap forward. Am I misunderstanding something?
12. This can still be reverted, right? It's enough to stop recommending
ipp-usb in F36, correct? Or is there a technical reason why that mustn't be
changed? I simply wonder whether we still have a way out if this is deemed
too catastrophic without some automatic workarounds like the one proposed
above.

Thanks!
Kamil

[1]
https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/thread/YL3XCMM7O27MEG6B2K54L2YSP2OJ7ZJ4/
[2] https://fedoraproject.org/wiki/Releases/36/ChangeSet
[3] https://bugzilla.redhat.com/show_bug.cgi?id=2066528#c4
[4] https://bugzilla.redhat.com/show_bug.cgi?id=1983403
___
devel mailing list -- devel@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: 

Re: FESCo wants to know what you use i686 packages for

[Kamil Paral]

On Wed, Mar 16, 2022 at 2:56 PM David Cantrell  wrote:

> If you use i686 packages for something now, please respond to this thread.
>

There are some game-related packages (not dependencies) which need to be
installed as i686 so that they can apply to 32bit games. I know of the
following:
* mangohud  (performance overlay)
* gamemode  (performance and desktop UX tuning)

Perhaps there are more.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [Bugzilla-announce-list] Action Required: Bugzilla - API Authentication changes

[Kamil Paral]

Jeff Fearn replied to my email, but he only copied the internal
bugzilla-list, because he wanted to include security details and didn't
feel comfortable doing that on a public list. I've selected the most
important parts of his replies and deleted the rest. Please see his
responses below:

On Wed, Feb 9, 2022 at 1:37 PM Jeff Fearn  wrote:

> On 9/2/2022 20:33, Kamil Paral wrote:
> > initially I (and not just me) read the email as "update to the latest
> > python-bugzilla and you'll be fine". But after I played with
> > bugzilla.stage, and read the announcement more carefully, it seems that
> the
> > only possible authentication method is now using the bugzilla api key,
> i.e.
> > using the username + password login is no longer possible (for API
> access).
> > Is that correct?
>
> Yes this is correct.
>
> > I do have several concerns regarding that. The change seems too sudden
> and
> > a lot of Fedora tooling interacts with bugzilla.
>
> This has been discussed for some time on the internal bugzilla-list.
>
> [snip]
>
> > So, basically two questions:
> > 1. Why are we given so little time to react? Can this change wait at
> least
> > until F36 is released (around the end of April), so that the Anaconda and
> > ABRT teams (as well as others) can incorporate the changes
>
> The time line was based on the feedback we got on bugzilla-list.
> Technically it's a pretty easy change and no one raised these kinds of
> issues.
>
> People with blockers should send a mail to bugzilla-list, or open a
> ticket, with all the gory details, and we can mash it out.
>
> The list is better IMO because there are people from other teams who can
> contribute to the discussion.
>
> > 2. Is there a good enough justification for completely banning
> > username+password authentication? Because this will have a strong impact
> on
> > Fedora quality by reducing the amount of crash reports which we receive,
> I
> > can't imagine it any other way.
>
> This change is driven by security of credentials
> [snip]
>

Based on Jeff's responses, I'd encourage teams, which own a high-impact
application/tooling affected by this change and can't react quickly enough,
to post into the internal bugzilla-list and discuss this issue. The
deadline could be possibly extended if there are good reasons for it, it
seems. Teams without access to the internal bugzilla-list can open a
bugzilla ticket (against the Bugzilla product) or contact Jeff directly, I
assume.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [Bugzilla-announce-list] Action Required: Bugzilla - API Authentication changes

[Kamil Paral]

On Tue, Feb 1, 2022 at 3:30 AM Jeff Fearn  wrote:

> Tl;dr From Monday 28th February, applications making API calls to
> Bugzilla may no longer authenticate using passwords or supplying API
> keys in call parameters. Instead, API keys must be supplied in the
> Authorization header.
>
> Support for using the Authorization header has been deployed to all Red
> Hat Bugzilla instances. You can change your code at any time and not
> have to wait for the old methods to be disabled.
>
> We will require all authenticated API usage to use this new method; this
> will break API access to Red Hat Bugzilla for any tools that don't use
> the Authorization header [1].
>
> If you are not certain your tooling authenticates using this header then
> you need to take action to confirm it does and to modify your tooling to
> use it if it doesn't.
>
> This new method does away with logging in and out of the API and uses
> API_KEYs in a standard Authorization header. This header needs to be
> sent with every call to the API.
>
> The old methods will be disabled on a rolling basis across the RHBZ
> servers.
>
> Target Dates:
>
> https://bugzilla.stage.redhat.com - Mon 07th Feb 00:00 UTC
> https://bugzilla.redhat.com - Mon 28th Feb 00:00 UTC
>

Hello Jeff,

initially I (and not just me) read the email as "update to the latest
python-bugzilla and you'll be fine". But after I played with
bugzilla.stage, and read the announcement more carefully, it seems that the
only possible authentication method is now using the bugzilla api key, i.e.
using the username + password login is no longer possible (for API access).
Is that correct?

I do have several concerns regarding that. The change seems too sudden and
a lot of Fedora tooling interacts with bugzilla. Even worse, there are some
tools which will get downright broken or massively impacted with no option
to fix that. The first one that comes to mind is the Anaconda installer. If
there's a crash during installation, it asks the user for username+password
bugzilla credentials to report a bug. This can't get fixed for F35, because
the installer images are already created, there is no update mechanism. So
we'll lose all installer bug reports (unless reported manually) starting
Feb 28th. This could be improved in F36, which is currently scheduled for a
release on April 19th.

However, even if Anaconda changes the bug reporting mechanism and asks the
user to create an API key first, and then provide it to Anaconda, I fear
that this will have a devastating impact on the number of bug reports that
we receive. It is quite different to fill out a username and a password
(which you already remember or have it stored, but is of a reasonable
length), from going to bugzilla (on a different computer, because your
current one is crashed during installation), creating a new api key (you
can't even display your existing ones, so you must have them stored
separately or always create a new one), and then retyping a 40-character
random string from one computer to another. Who will have the dedication to
do this "stuff"? And possibly repeatedly, in case of more crashes? (Even
we, the QA team, will hate this. You can't always easily share your
clipboard into a VM with the installation environment, or when using bare
metal, and if we have to retype a 40-character random string several times
per day, because we made the installer crash, that's going to severely
impact us on multiple levels).

This same issue is shared with Fedora's crash reporting tool, ABRT. Any
time something crashes on the desktop, the user is suggested to submit a
bug report. Instead of providing the username+password, the user will have
to go through the api key creation motions. But at least this time the api
key can be remembered by ABRT. But again I fear we'll lose a considerable
amount of bug reports. Instead of removing obstacles, we're adding them.
And as before, the change is too sudden, the ABRT team might not be able to
react in time and we'll lose all bug reports starting Feb 28th.

So, basically two questions:
1. Why are we given so little time to react? Can this change wait at least
until F36 is released (around the end of April), so that the Anaconda and
ABRT teams (as well as others) can incorporate the changes?
2. Is there a good enough justification for completely banning
username+password authentication? Because this will have a strong impact on
Fedora quality by reducing the amount of crash reports which we receive, I
can't imagine it any other way.

PS: This is also sent to the Fedora devel list, I hope you can reply there
as well. It can be done from the web interface, if you prefer [1].

Thanks,
Kamil Páral
Fedora QE

[1]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 

Re: F36 Change: Enable exclude_from_weak_autodetect by default in LIBDNF (System-Wide Change proposal)

[Kamil Paral]

On Fri, Nov 12, 2021 at 10:50 PM Maxwell G via devel <
devel@lists.fedoraproject.org> wrote:

> Hi everyone,
>
> On Thu, 2021-09-16 at 15:17 -0400, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/ExcludeFromWeakAutodetect
> >
> >
> > == Summary ==
> > exclude_from_weak_autodetect enables autodetection of unmet weak
> > dependencies (Recommends or Supplements) of installed packages and
> > blocks installation of packages satisfying already unmet dependencies.
> > In other words: When you don't have the recommended package installed,
> > it won't be automatically installed with future upgrades of the
> > recommending package.
>
> I am not sure if this was intended, but this change has broken rich
> weak dependencies when both packages are not installed as part of the
> same transaction.
>
> In my yt-dlp package's specfile[1], I have three subpackages for shell
> completions: `yt-dlp-bash-completion`, `yt-dlp-zsh-completion`, and
> `yt-dlp-fish-completion. Here is the `bash-completion` block:
>
> ``` spec
> %package bash-completion
> Summary:Bash completion for %{name}
> Requires:   %{name} = %{version}
> Requires:   bash-completion
> Supplements:(%{name} and bash-completion)
> BuildArch:  noarch
> ```
>
> The intended effect is for the shell completions to be installed at the
> time `yt-dlp` itself is installed if the respective shell package
> (`bash-completion`, `zsh` or `fish`) is already present while still
> allowing users to opt out. However, now this does not work; dnf will
> only install the completions if both `yt-dlp` and the shell package are
> installed as part of the same transaction. I can confirm that this is
> caused by this change, because adding `--
> setopt=exclude_from_weak_autodetect=false` fixes the problem. Replacing
> `Supplements` with forward facing boolean `Requires` did not work
> either.
>
> ``` spec
> Recommends: (%{name}-bash-completion if bash-completion)
> Recommends: (%{name}-zsh-completion if zsh)
> Recommends: (%{name}-fish-completion if fish)
> ```
>
> While I agree that {rich,} weak dependencies should not be reinstalled
> as part of updates, I do believe that they should be installed if one
> of the packages is being installed for the first time.
>
> I also think we should consider implementing better guidelines for
> shell completions in Fedora. I believe that shell completions should be
> split into subpackages and that these subpackages should depend on the
> shells themselves or a `-filesystem` package that actually own the
> directories. Right now, directory ownership is kind of a mess. At least
> on my system, there are several packages that own /usr/share/bash-
> completion, /usr/share/zsh/vendor-completions, /usr/share/zsh/site-
> functions, and /usr/share/fish/vendor_completions.d/. We can also use
> this oppurtunity to create macros for each of these directories.
>
> Management of shell completion packages was discussed further in my
> package review ticket [2].
>
> I am relatively new to Fedora, so please correct me if I got anything
> wrong.
>
> Thanks,
> Maxwell
>
> [1]: https://src.fedoraproject.org/rpms/yt-dlp/blob/rawhide/f/yt-dlp.spec
> [2]: https://bugzilla.redhat.com/show_bug.cgi?id=2012522
>
>
Hey Maxwell,
can you please file a new bug in bugzilla against dnf and copy the problem
description into it? Then make your new bug block bug 2013327 [1], which is
the tracker for this Change. This way you'll make sure that this problem
doesn't get lost and the maintainer has to deal with it before the
appropriate Change deadline. Thanks!

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2013327
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Action required: Account system IRC pointer reset

[Kamil Paral]

On Tue, Nov 9, 2021 at 11:35 PM Kevin Fenzi  wrote:

> The old Fedora account system had a ‘irc nick’ field. The new Fedora
> account system has
> a ‘Chat nicknames’ section. In that section you can put IRC nick(s) or
> Matrix Ids.
> If you do not qualify them, they are assumed to be for the libera.chat
> (IRC) and fedora.im (matrix) networks.
>

Hi Kevin. I heard about Fedora getting its own Matrix server in the future,
but never saw any announcement that it is here already. Is fedora.im
production-ready? I'm happy to replace my old Matrix account with a Fedora
one, if everything is ready.

Thanks for info,
Kamil
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Enable exclude_from_weak_autodetect by default in LIBDNF (System-Wide Change proposal)

[Kamil Paral]

On Mon, Sep 27, 2021 at 3:03 PM Miro Hrončok  wrote:

> I've checked the status quo.
>
> Package "reproducer_reversed" starts supplementing package "rpm". "rpm" is
> installed, but "reproducer_reversed" is not.
>
> 1. dnf upgarde, no rpm update available: reproducer_reversed is not pulled
> in
> 2. dnf reinstall rpm: reproducer_reversed is pulled in
> 3. dnf downgrade rpm: reproducer_reversed is pulled in
> 4. dnf upgrade rpm: reproducer_reversed is pulled in
> 5. dnf upgrade, rpm update avilable: reproducer_reversed is pulled in
>
> Would this change proposal actually change the observed behavior? In what
> way?
>

Based on Jaroslav's response, I'm afraid the new behavior will be that
"reproducer_reversed" doesn't get pulled in in any of those cases (or
perhaps just in case #2). But let's wait for Jaroslav to provide a
definitive answer.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Enable exclude_from_weak_autodetect by default in LIBDNF (System-Wide Change proposal)

[Kamil Paral]

On Mon, Sep 27, 2021 at 8:30 AM Jaroslav Mracek  wrote:

> > 2. What happens if package P (already installed on the user's system)
> > starts recommending package Q (not installed on the user's system)? Will
> Q
> > get auto-installed together with P's update, or not? I believe it's
> > important to keep auto-installation enabled for *new* weak relationships.
>
> New weak dependencies of package P are installed.
> Installed P-1-1.noarch (no recommends)
> Available P-1-2.noarch (recommends ddd) will install ddd on upgrade if
> possible.
>
> > 3. Similarly to above (perhaps exactly the same case), what happens when
> > package Q (not installed) starts supplementing package P (installed),
> will
> > it get auto-installed or not?
>
> No, Q will be not installed. With supplements it is difficult to known
> when it appears, because that information is not on RPMDB.
>

While it makes sense technically, this might be quite confusing for
packagers. Up until now I think there were no real-world differences
between forward (recommends) and backward (supplements) dependencies. This
(and also the first answer) should get documented in the Change proposal
and in the packaging guidelines [1]. Can you please add an action item to
the proposal to adjust relevant Fedora docs?

[1]
https://docs.fedoraproject.org/en-US/packaging-guidelines/WeakDependencies/
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Changes to Bugzilla query limits

[Kamil Paral]

On Fri, Sep 17, 2021 at 2:09 PM Ben Cotton  wrote:

> I'm passing along a lightly-edited announcement from the Red Hat
> Bugzilla admins. You may have noticed this change already. The short
> version is that the search API now defaults to returning 20 bugs, but
> authenticated calls can request up to 1000.
>
> More details are on the Community Blog:
> https://communityblog.fedoraproject.org/changes-to-bugzilla-queries/


I wonder if the RH Bugzilla team could synchronize with Fedora schedule
next time, and avoid making potentially disruptive changes during an infra
freeze...
(Yes, I'm still somewhat salty that BlockerBugs App broke during a blocker
review meeting because of this).
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Enable exclude_from_weak_autodetect by default in LIBDNF (System-Wide Change proposal)

[Kamil Paral]

On Thu, Sep 16, 2021 at 9:18 PM Ben Cotton  wrote:

> https://fedoraproject.org/wiki/Changes/ExcludeFromWeakAutodetect
>
>
> == Summary ==
> exclude_from_weak_autodetect enables autodetection of unmet weak
> dependencies (Recommends or Supplements) of installed packages and
> blocks installation of packages satisfying already unmet dependencies.
> In other words: When you don't have the recommended package installed,
> it won't be automatically installed with future upgrades of the
> recommending package.
>

Exciting. I have the following questions:
1. Do I understand correctly that this will be enabled by default in F36
and later and disabled by default in F35 and older? The proposal text is
*very* convoluted and doesn't explain this clearly (I think it should be
edited to be clearer).
2. What happens if package P (already installed on the user's system)
starts recommending package Q (not installed on the user's system)? Will Q
get auto-installed together with P's update, or not? I believe it's
important to keep auto-installation enabled for *new* weak relationships.
3. Similarly to above (perhaps exactly the same case), what happens when
package Q (not installed) starts supplementing package P (installed), will
it get auto-installed or not?
4. If there's a scenario where we want some packages pulled automatically
on the first update after installation, but we don't want to include them
on the media (possibly because of size constraints or something else), how
can that be achieved? Has somebody reviewed the kickstarts for cases like
these? I think at least some localization-related files are automatically
installed post-installation.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Test-Announce] BlockerBugs webapp upgraded to 1.4.0

[Kamil Paral]

Hello,

for those of you who use our BlockerBugs app to track release blockers
(e.g. tracked bugs for F35 Beta [1]), there's a new version 1.4.0 deployed
to production.

The most user-visible change in this release is a new purple anchor icon,
which is displayed next to blocker bugs which depend on some other bugs.
This way, you can easily see what other issues need to be resolved before
the bug in question can be closed. These bugs are also highlighted in text
form on the "IRC Format" and "Requests" tabs (which are mostly useful for
the core QA team during blocker meetings and when requesting update pushes
and new composes).

An example of the anchor icon:
https://i.imgur.com/KGMjh34.png

If you encounter any issues, please let us know:
https://pagure.io/fedora-qa/blockerbugs

Cheers,
Kamil

[1] https://qa.fedoraproject.org/blockerbugs/milestone/35/beta/buglist
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: PSA: partner-bugzilla to be replaced with bugzilla.stage on July 31st

[Kamil Paral]

On Tue, Jul 27, 2021 at 10:39 AM Miro Hrončok  wrote:

> On 27. 07. 21 10:34, Kamil Paral wrote:
> > If any of you uses https://partner-bugzilla.redhat.com
> > <https://partner-bugzilla.redhat.com> (e.g. for integration testing,
> etc,
> > basically as a staging Bugzilla instance), please note that it says:
> >
> > "This instance of Bugzilla will be shut down permanently on July 31st at
> 12:30
> > AM UTC. You should use bugzilla.stage.redhat.com
> > <https://bugzilla.stage.redhat.com> instead"
> >
> > I noticed very recently as well, and I figured there might be more
> people
> > interested in it in this list.
>
> At least in https://pagure.io/fedora-infra/ansible, there are quite a few
> occurrences.
>

I created https://pagure.io/fedora-infrastructure/issue/10131 to notify the
infra team.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

PSA: partner-bugzilla to be replaced with bugzilla.stage on July 31st

[Kamil Paral]

If any of you uses https://partner-bugzilla.redhat.com (e.g. for
integration testing, etc, basically as a staging Bugzilla instance), please
note that it says:

"This instance of Bugzilla will be shut down permanently on July 31st at
12:30 AM UTC. You should use bugzilla.stage.redhat.com instead"

I noticed very recently as well, and I figured there might be more people
interested in it in this list.

Cheers,
Kamil
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Attempt to contact "Standard Test Interface" project collaborators

[Kamil Paral]

On Wed, Jun 30, 2021 at 3:13 AM Michal Schorm  wrote:

> Hello,
> I tried to contact the people behind "Standard Test interface" CI.
> I sent the e-mail about 3 weeks ago.
> Then after about 2 weeks (= ~1 week ago) I reacted to the same email
> so it would appear in their inboxes again.
>
> Yet no response came, so i'm trying here.
>

Hi Michal,
the best route might be to ask in the "ci" mailing list or their IRC
channel (perhaps no longer on Freenode, though):
https://docs.fedoraproject.org/en-US/ci/#_contact
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: IRC Announcement

[Kamil Paral]

On Mon, May 31, 2021 at 6:55 PM Fabio Valentini 
wrote:

> > If I intend to use Matrix exclusively, do I still need to register on
> libera.chat, in order to participate in Fedora rooms?
>
> I think if you want to show up on the IRC side with your expected IRC
> nick (for example, for IRC meetings, for zodbot to recognise you, and
> for IRC rooms that are set up to only allow registered users), then
> you will need to register on libera.chat and then set up that account
> with "@appservice:libera.chat" ("!username foo", "!storepass bar",
> "!nick baz" should do the trick, and allow you to authenticate over
> SASL - at least that worked for me).
>

This helped a lot, thanks.

I'd still prefer if I didn't have to register an IRC nick and didn't need
to communicate with Appservice and NickServ (I just wish to forget about
IRC completely), hopefully that will be possible in the future.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: IRC Announcement

[Kamil Paral]

On Mon, May 31, 2021 at 10:44 PM Fabio Valentini 
wrote:

> > Maybe it helps in Element Web, Settings, Preferences, to deactivate
> > "Show join/leave messages (invites/kicks/bans unaffected)"
>
> Thanks for the suggestion, but I already had that setting turned off for
> months.
>
> Weirdly enough, turning it *back on* seems to make performance of the
> #fedora-devel room more bearable. It's still very very bad -
> considering this is running on a recent top-of-the-line 8-core CPU
> from 2021 ... the join/leave messages add a lot of noise, but at least
> opening #fedora-devel doesn't make Firefox freeze for half a minute 
>

Thanks! It adds a lot of visual noise, but the rooms can finally be used
now.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: IRC Announcement

[Kamil Paral]

On Thu, May 27, 2021 at 8:11 PM Nick Bebout  wrote:

> If you are a Matrix user, we ask for your patience as we get bridges setup
> on the new network. If you were joined to rooms via the generic freenode
> bridge, you will need to leave them and rejoin the fedora rooms in matrix
> (which will be plumbed with the Libera channels)
>

Is there some official list of invite-style links to Fedora channels for
Matrix users? Can be work-in-progress, but at least something. As a
relatively new Matrix user, I have to say I'm utterly confused at the
moment. I don't know how to distinguish a native Matrix room from a "portal
room". I don't know how to distinguish whether a room is bridged or not,
and where to. So basically I don't know whether to stay in the current
rooms or leave, and how to find the "right rooms" which I should join.

If I intend to use Matrix exclusively, do I still need to register on
libera.chat, in order to participate in Fedora rooms?

Has someone also encountered severe performance issues in certain rooms in
Element (a room taking minutes of full CPU usage to load)? I saw it in the
past rarely as well, but in the last few days I encountered it in at least
half the rooms I was connected to.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Disappearing and re-appearing i686 packages in the x86_64 compose

[Kamil Paral]

On Fri, May 7, 2021 at 7:59 PM Kevin Fenzi  wrote:

> No, I don't think it will ever be "fixed".
> ...
> We have in update pungi config a (IMHO poorly named)
> "multilib_whitelist" variable. We can add packages to this and pungi
> will pull them in, no matter if something depends on them or not.
>

Anyone willing to work on a Change which would allow packagers to achieve
the same behavior by adding a custom Provides to RPM packages (e.g.
"x-fedora-multilib=x86_64+i686")? It would be easier to adjust your own
package rather than wait on a PR approval for the pungi config.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Unretiring and maintaining the Fish Fillets NG game

[Kamil Paral]

On Thu, Apr 29, 2021 at 3:59 AM Nikolay Nikolov  wrote:

> What are the next steps for unretiring these two packages and
> maintaining them?
>

Hey Nikolay,
thanks for taking care of Fish Fillets, it's a great game (and also from my
country). Here I found the instructions for unretiring a package:
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [Test-Announce] 2021-02-22 @ 17:00 UTC - Fedora 34 Blocker Review Meeting

[Kamil Paral]

On Sun, Feb 21, 2021 at 10:18 PM Chris Murphy 
wrote:

> On Sun, Feb 21, 2021 at 12:24 PM Tom Seewald  wrote:
> >
> > If Gnome is still hanging for 2 minutes on reboot [1] then I think we
> may want to consider that a blocking bug for F34. I can at least confirm
> that this bug is still affecting Rawhide.
> >
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1909556
>
> Under what criterion would it be a blocker?
>

https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/thread/QAKYTKLYBQS5OMBSATXHTYJA3RWS2U5P/

Never got approved :-/ Perhaps it's time to re-ignite the discussion?
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: PackageKit-gtk3-module i686 (x86_32) is missing in Fedora 33 repositories

[Kamil Paral]

On Tue, Jan 26, 2021 at 7:06 PM Kevin Fenzi  wrote:

> > Adding normal packages are requirements for a devel package just to make
> it
> > multilib feels... unclean? Perhaps I'm misunderstanding something. In
> order
> > to have the logic self-contained, why don't we add something like
> > "Provides: multilib(x86_64, i686)" into affected packages and make pungi
> > process that?
>
> Feel free to suggest it to rpm. ;)
>

Why rpm? Isn't that entirely in our hands, what Provides we assign to
Fedora packages and what meaning we give it?


>
> I'd personally just like to drop i686 entirely, but I don't think
> everyone else is ready for that.
>

No no no, I'm not willing to give up my games collection! :-)
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: i686 packages for x86_64 platform

[Kamil Paral]

On Tue, Jan 26, 2021 at 1:49 PM Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:

> On 26.01.2021 13:24, Honggang LI wrote:
> > What is the rule to concurrently select both x86_64 and i686 build
> > for Fedora X86_64 platform?
>
> Fedora ships only i686 packages for multilib support (e.g. Wine and Steam).
>

For a bit of context, Honggang is asking because of:
https://bugzilla.redhat.com/show_bug.cgi?id=1919864

rdma-core suddenly stopped being multilib in F33, which of course caused
issues for existing users. I believe it was a consequence of this packaging
change:
https://src.fedoraproject.org/rpms/rdma-core/c/ef8db100db16dfbfec42ed58eb0d2e57ca81bc0a?branch=f33
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: PackageKit-gtk3-module i686 (x86_32) is missing in Fedora 33 repositories

[Kamil Paral]

On Mon, Jan 25, 2021 at 11:10 PM Kevin Fenzi  wrote:

> For rawhide, and branched (prerelease) yes, changes likely would need to
> be there.
> For updates its the infrastructure ansible repo.
>

Sigh.

So, IMHO, tickets for this should be filed as releng tickets
> and folks should note which they are talking about above.
>

Thanks, I'll try to remember that.

> > However, as you can see, the maintainers don't respond much to such
> requests :-(
> > > Perhaps Mohan, Kevin or others could shed a light here how to best
> make sure those requests are noticed? Thanks.
>
> releng ticket I would think, but can you expand on which requests aren't
> noticed ?
>

Here's one:
https://pagure.io/pungi-fedora/issue/849

Here's a second one, but yesterday I found out that there was a related PR
merged, so I updated it:
https://pagure.io/pungi-fedora/issue/811

A third one:
https://pagure.io/pungi-fedora/issue/501

> I expect it's valuable to have the logic for multilibs, "self
> > contained" in the package instead of to rely on any infra tweaks.
> >
> > (1) https://src.fedoraproject.org/rpms/PackageKit/pull-request/7
>
> Yeah, I would definitely prefer that.
>

Adding normal packages are requirements for a devel package just to make it
multilib feels... unclean? Perhaps I'm misunderstanding something. In order
to have the logic self-contained, why don't we add something like
"Provides: multilib(x86_64, i686)" into affected packages and make pungi
process that?
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: PackageKit-gtk3-module i686 (x86_32) is missing in Fedora 33 repositories

[Kamil Paral]

On Mon, Jan 25, 2021 at 11:17 AM Graham White 
wrote:

> Hi,
>
> I'm trying to get to the bottom of bug #1901065 -
> https://bugzilla.redhat.com/show_bug.cgi?id=1901065
>
> Anyone know why PackageKit-gtk3-module.i686 has been removed from the
> Fedora 33 repositories?  This package was there for Fedora 32 and checking
> Koji it looks like the 32-bit version is still being built.  However, for
> some reason it's not appearing in the F33 repositories for the x86_64
> architecture.  We have some packages that rely on the 32-bit version so it
> would be good to have it re-included in the repo.
>

Multilib detection (which i686 packages should end up in x86_64 repos) is
done in Pungi. There is some heuristics which I haven't found documented
anywhere (one would think it should be in the packaging docs). A
whitelisting of some package can be requested here:
https://pagure.io/pungi-fedora/issues

However, as you can see, the maintainers don't respond much to such
requests :-( Perhaps Mohan, Kevin or others could shed a light here how to
best make sure those requests are noticed? Thanks.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Software Management (RPM, DNF) 2020 retrospective

[Kamil Paral]

On Mon, Jan 18, 2021 at 2:08 PM Marius Schwarz 
wrote:

> Am 18.01.21 um 09:35 schrieb Daniel Mach:
> > DNF 5
> > -
> >   * The goal is to remove redundant code and make sure all tools built
> > on top libdnf work the same (DNF currently uses a different code path
> > than microdnf and PackageKit)
>
> Can you add a new goal:
>
> Don't use Python for it, as it it's slow on mobile devices like
> Pinephone a.s.o.
>

Have you tried microdnf?
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Software Management (RPM, DNF) 2020 retrospective

[Kamil Paral]

On Mon, Jan 18, 2021 at 11:33 AM Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:

> On 18.01.2021 11:29, Kamil Paral wrote:
> > Sounds great. But I don't see those commands neither in F33 nor in
> > Rawhide. Am I looking wrong? Thanks.
>
> You need to install dnf-plugin-system-upgrade package first.
>

Thanks, Vitaly! This was mighty confusing. First, the recommended approach
by DNF itself doesn't work:

$ sudo dnf offline-distrosync
No such command: offline-distrosync. Please use /usr/bin/dnf --help
It could be a DNF plugin command, try: "dnf install
'dnf-command(offline-distrosync)'"

$ sudo dnf install 'dnf-command(offline-distrosync)'
Last metadata expiration check: 3:48:58 ago on Mon 18 Jan 2021 08:39:43 AM
CET.
No match for argument: dnf-command(offline-distrosync)
Error: Unable to find a match: dnf-command(offline-distrosync)

Second, a man page for dnf-offline-* is missing even if you install the
right plugin, so it's not clear that you have it at all.

And third, why on earth is this bundled with system-upgrade, what is their
relationship? I want to perform "dnf upgrade" (or distrosync) in a safe
manner, and so doing it offline with "dnf offline-upgrade" seems natural.
So it's an offline version of upgrade/distrosync, and it's closer to those
commands than to a system-upgrade command, in my eyes.

Daniel, see above for some tips on improvements, thanks :-)
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Software Management (RPM, DNF) 2020 retrospective

[Kamil Paral]

On Mon, Jan 18, 2021 at 9:36 AM Daniel Mach  wrote:

> $ dnf offline-upgrade
> $ dnf offline-distrosync
>* New commands to upgrade your system on reboot
>

Sounds great. But I don't see those commands neither in F33 nor in Rawhide.
Am I looking wrong? Thanks.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: proposal: move Data Corruption criterion from Final to Beta

[Kamil Paral]

On Mon, Jan 11, 2021 at 1:04 PM Kamil Paral  wrote:

> Hello, I already sent this proposal (quoted below) to the test list last
> week. Please read the existing discussion at:
>
> https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/thread/BFN427ECEZTGYCDKHJYH6VWWTGDA2BSG/
>
> So far, I collected a thumbs up from Chris Murphy and Ben Cotton. I'm
> forwarding it also here to the devel list, to collect more feedback, if
> there is any.
>

Because there have been no concerns, I implemented the change today:
https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/message/V3XH3DIRZA4TUMTUL5RNKZSXUNPJUCLV/

Cheers,
Kamil
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

proposal: move Data Corruption criterion from Final to Beta

[Kamil Paral]

Hello, I already sent this proposal (quoted below) to the test list last
week. Please read the existing discussion at:
https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/thread/BFN427ECEZTGYCDKHJYH6VWWTGDA2BSG/

So far, I collected a thumbs up from Chris Murphy and Ben Cotton. I'm
forwarding it also here to the devel list, to collect more feedback, if
there is any.

Thanks,
Kamil

-- Forwarded message -
From: Kamil Paral 
Date: Thu, Jan 7, 2021 at 1:44 PM
Subject: proposal: move Data Corruption criterion from Final to Beta
To: test 

I propose we move the existing Data Corruption criterion from Final to
Beta. The criterion sounds like this:
"All known bugs that can cause corruption of user data must be fixed or
documented at Common F34 bugs."
https://fedoraproject.org/wiki/Fedora_34_Final_Release_Criteria#Data_corruption
(see footnotes for some additional details)

The reason for this proposal is this bugzilla [1] and this blocker ticket
[2] where we discussed whether we should ship an older Firefox on F33 Beta
media, which was known to completely wipe the whole user profile on
upgraded systems. We didn't (and still don't) have any release criterion
which says that this situation should not occur. Fortunately, in the F33
Beta case, we managed to ship a fixed version of Firefox in time, and so we
didn't really need to make a decision back then.

I talked about this problem in general in [2], and I said:
"I support moving the Data Corruption criterion to Beta, with the rationale
that we also require system upgrades to be fully working at Beta, and that
puts testers into a tough place where they are recommended to upgrade but
might lose personal data. It seems to me that those two things should be
coupled together, for important cases (like this one, IMO). The corruption
criterion allows us to decide when we want to demand the fix and when it's
enough to have it documented. If e.g. all my history+bookmarks+passwords
get purged from Firefox or if e.g. my ~/Documents folder gets removed on
Beta upgrade, I believe we should have an option to block the Beta release.
At the same time, we don't need to apply it if you only lose e.g. your
color profiles in gnome-terminal. Currently your whole home can get purged
and we don't have a way to stop it in Beta, I find that a problem."

The criterion as currently written is flexible enough that it doesn't force
us to fix the issue, if we consider it low-risk or low-impact, but it
*enables us* to have that conversation and accept the high-risk or
high-impact issues as blockers. That's why I believe moving it to Beta
doesn't bring any downsides, just advantages.

Please comment, thank you.
Kamil

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1881495
[2] https://pagure.io/fedora-qa/blocker-review/issue/118
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Proposal: gate stable release critical path updates on openQA test results

[Kamil Paral]

On Thu, Jan 7, 2021 at 6:26 PM Adam Williamson 
wrote:

> Hey folks!
>
> So here's an idea I was thinking about over the RH shutdown: I propose
> we gate stable release critical path updates on the openQA tests.
>

+1, awesome

I'm glad I'm not going to be that person that everybody pokes when
something breaks or an unexpected result arrives :-)
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)

[Kamil Paral]

On Thu, Dec 3, 2020 at 3:27 AM Dusty Mabe  wrote:

> There are three update streams for Fedora CoreOS. The "stable" stream is
> still
> on Fedora 32 but has been receiving bi-weekly updates and should be
> switched over
> to Fedora 33 soon (probably this week). The `next` and `testing` streams
> have been
> updated to Fedora 33 and the `next` stream has been on F33 since early
> october. My
> point here is that if you want Fedora 33 and you are a Fedora CoreOS user
> you can
> easily adopt a stream that has it.
>

Since FCOS has automatic updates, perhaps the messaging could be something
along the lines "Selected users will begin their automatic upgrade process
to F34 in the next few days, and the full rollout to all users is expected
to be finished in a couple of weeks. If you want to upgrade early, you can
manually switch to the 'testing' branch immediately.". I think it's pretty
much expected these days that major large-scale upgrades first hit 1% of
the user base, then 10%, then 100% (or similar). Think Android/iOS
upgrades, etc. So if the same approach is taken with FCOS, shortly after
F34 is GA, I believe this process can be pretty clear to the users, if
explained well. And integrate well with their and our expectations at the
same time.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: video meeting to discuss Matrix/Element and IRC

[Kamil Paral]

As someone who hates IRC with passion (including the necessity of
maintaining a znc instance and dealing with IRC authentication and network
issues from time to time) and would love to jump to a more modern solution
ASAP, what is the best course of action for me now?

- Create an account with some Matrix server, and join my favorite Fedora
channels from there?
- Or wait until some formal decision is reached and possibly the Fedora
Matrix server is available?
- Will there be any advantage in using the Fedora server over others?
- If not, do you have any recommendation which server to register at - are
there any differences between them, e.g. in stability or resposivity or
features?
- Can I already join all Fedora-related channels hosted on freenode, or
just some select ones?
- Are there any difficulties with the Matrix-to-IRC bridge to be aware of?
For example do I still need to forward my IRC authentication somehow
through Matrix? Or are modern chat features (like image editing or
reactions) also supported on those bridged channels? Or anything else?

Thanks for replies.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

orphaned python-mongoquery

[Kamil Paral]

Hello, the python-mongoquery package is now orphaned, our group doesn't
need it anymore. It doesn't seem to be required by any other package. If
python-mongoquery is useful to you, feel free to take it:
https://src.fedoraproject.org/rpms/python-mongoquery

Cheers,
Kamil
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: orphaning Taskotron-related packages

[Kamil Paral]

On Wed, Nov 25, 2020 at 2:29 PM Josef Skladanka  wrote:

> > Orphaning python-mongoquery and retiring everything else makes sense to
> > me.
> >
> > Tim
>
> +1
>

OK, I'll make it happen.
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-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/qa-devel@lists.fedoraproject.org

Re: orphaning Taskotron-related packages

[Kamil Paral]

On Mon, Nov 16, 2020 at 8:27 AM František Zatloukal 
wrote:

> The "correct" way to do this is to use orphaning procedure. This way,
> anybody interested will have enough time to take over the to-be removed
> packages.
>

"When Fedora maintainers do not want or are not able to maintain a package
any longer, they can orphan or retire
 the
package. When they think that the package is still useful for Fedora, they
should orphan it. Then other maintainers that are interested in maintaining
it, can take ownership of this package. In case the package is no longer
useful for Fedora, e.g. because it was renamed, upstream does not exist
anymore, then it should be retired."
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers

As I said, I think it makes sense to go for orphaning in case of
mongoquery, and retiring for taskotron packages. But as you note:


>
> Also, all packages that are orphaned for 6+ weeks get retired. This will
> happen before F34, so there is no harm in doing this through orphans.
>

Yes, it should be the same anyway, if we do it right now. I just know that
sometimes the retirement process does not happen automatically and the
packages linger, and that's why I suggested retiring the upstream-dead
packages right away. I see no benefit in a two-step process, only potential
issues. But I don't care, really.

Anyway, what do you think about the actual proposal, and not the
technicalities?
Tim, Josef, do you have anything to say here?
Thanks.
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-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/qa-devel@lists.fedoraproject.org

Re: orphaning Taskotron-related packages

[Kamil Paral]

Note: The email subject should have said "retiring" instead of "orphaning".
There is little reason to orphan them, retiring is the right approach here.
Perhaps except for mongoquery, somebody else could be interested in
maintaining that, so that one should be orphaned instead.
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-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/qa-devel@lists.fedoraproject.org

orphaning Taskotron-related packages

[Kamil Paral]

Hello,
our Taskotron-related repositories (with exceptions like resultsdb) have
been marked as EOL and archived more than half a year ago. I believe it's
time to also tidy up our rpm packages in Fedora.

Looking at our group ownership [1] I have identified the following rpms
which could be retired:
* libtaskotron - nothing depends on it
* taskotron-trigger - nothing depends on it
* python-mongoquery - only taskotron-trigger depends on it
* execdb - nothing depends on it

I think we could have a light discussion regarding libtaskotron. The git
repo is marked as EOL and therefore the package should go away. However,
it's easy to flip the git repo back to a live state and it's not that
trivial to bring back an rpm package. So we should at least briefly
consider whether there is anything in that repo that could be useful in
some of our other current efforts. When looking at the code [2], I think
there are a few modules that could be potentially useful elsewhere, like
koji_utils/bodhi_utils/rpm_utils, perhaps a method or two from
os_utils/file_utils, and a perhaps a few directives. The problem is that
the code is not currently designed to work as a standalone library, but as
a runner - it expects a config file present, it expects certain directories
present, etc. The directives are exceptionally horrible if you want to use
them just by importing and not through the runner. It would require a
fairly big rewrite. Also we could drop ca. 70%-80% of the current codebase
(the runner stuff and unuseful modules).

If Tim said he would like to use some of that code in his CI efforts, or
Josef et al. said they would use some of that for oraculum or packager
dashboard etc, we might not retire libtaskotron, but restructure it into
something more useful. I'd be fine helping with that. But, even if we
wanted to do that, I'd honestly consider leaving libtaskotron as it is, and
rather creating a new package instead, something like 'libfedoraqa' or
similar. And only the few useful modules would be transferred there. It
feels to me much cleaner than reusing the libtaskotron name but gutting it
heavily.

What are your thoughts? Do you see any near-term use of some of the
existing code in libtaskotron? Or any other mentioned packages? Or can we
just drop them and bring them back if we ever need them? (If we don't have
an immediate use, there is a high probability we won't ever need them
again).

Thanks,
Kamil

[1] https://src.fedoraproject.org/group/qa-tools-sig
[2] https://pagure.io/taskotron/libtaskotron/blob/develop/f/libtaskotron
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-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/qa-devel@lists.fedoraproject.org

Re: current maintainer of lmbench3

[Kamil Paral]

On Sun, Nov 1, 2020 at 9:53 PM Ryan Kosta  wrote:

> Dear QA tool development,
>
> During this week's kernel testday, I encountered a few interesting
> compilation errors with lmbench. Nothing to warrent major concern but
> their was a variable or two that had the wrong types, enough to offer a
> patch or two.
>
> When looking for lmbench I found the official intel github repository
> for it online. The readme was consistent with the readme in the source
> from the testcase stating the version as 2alpha8. yet the directory was
> named lmbench3.
>
> For this testcase did you clone lmbench directly from the intel github
> repository or is their an internal Fedora repository in which it came
> from?
>

Hey Ryan,
for reference, this is the test day and the test case we're talking about,
correct?
https://fedoraproject.org/wiki/Test_Day:2020-10-26_Kernel_5.9_Test_Week
https://fedoraproject.org/wiki/QA:Testcase_kernel_regression

We don't own the kernel-tests test suite, that's owned by the kernel team.
You can file issues or ask questions in the project repository:
https://pagure.io/kernel-tests
or using Kernel team's communication channels, i.e. their IRC or a mailing
list:
https://fedoraproject.org/wiki/Kernel

Hope that helps :)
Kamil
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-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/qa-devel@lists.fedoraproject.org

Re: Proposal: drop extras-qa from all fedora bugs

[Kamil Paral]

On Tue, Sep 29, 2020 at 6:31 PM Kevin Fenzi  wrote:

> Since time began (Fedora 7), all fedora bugs in bugzilla have had their
> "QA Contact" field set to: extras...@fedoraproject.org.
>
> Bugzilla describes "QA Contact" as:
>
> "The person responsible for confirming this bug if it is unconfirmed,
> and for verifying the fix once the bug has been resolved."
>
> However, also since at least 2007-04-20 emails to that address go to
> /dev/null. (Before that they went to a linux.duke.edu address, so I am
> not sure where they went).
>
> I'd like to propose dropping this from all Fedora bugs.
>
> It's a useless extra email that bugzilla has to generate, network has to
> send and deliver and we have to drop in the bitbucket.
>

+1
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Release criteria proposal: first boot experience

[Kamil Paral]

On Tue, Sep 1, 2020 at 10:24 PM Michael Catanzaro 
wrote:

> Hi,
>
> We currently have a bug where the Online Accounts page in initial setup
> is nonfunctional. [1] This doesn't violate any current release
> criterion, but surely we don't want to release with a broken initial
> setup experience. So let's add a new requirement for that. How about
> something like:
>
> "If an initial setup utility is run or intended to be run after the
> first boot of the installed system, then it must start successfully and
> each page or panel of the initial setup utility should withstand a
> basic functionality test."
>
> OK that's pretty basic, but it gets the point across. I think this can
> be a final requirement, not necessarily important enough to be a beta
> requirement. Bikeshed away!
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1870476


This criterion is now live:
https://fedoraproject.org/wiki/Fedora_33_Final_Release_Criteria#First_boot_experience
https://fedoraproject.org/w/index.php?title=QA%3ATestcase_base_initial_setup=revision=588239=491757
https://fedoraproject.org/w/index.php?title=Template%3ABase_test_matrix=revision=588240=581773

Thanks everyone involved.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Manual intervention required: broken /etc/nsswitch.conf and /etc/resolv.conf for F33 early adopters

[Kamil Paral]

On Mon, Sep 14, 2020 at 12:37 PM Pavel Březina  wrote:

> apply-changes only works if you have valid authselect configuration (no
> manual changes) and you edit /etc/authselect/user-nsswitch.conf or one
> of the selected profile template.
>
> If you need to restore previous configuration you can either use
> backup-restore (if there is any backup, see backup-list) or you can use
> 'authselect current --raw' which will print you what authselect command
> line was used.
>
> authselect select `authselect current --raw` --force
>

Thanks, that seems to have worked.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Manual intervention required: broken /etc/nsswitch.conf and /etc/resolv.conf for F33 early adopters

[Kamil Paral]

On Fri, Sep 11, 2020 at 7:03 PM Michael Catanzaro 
wrote:

>
> > If it is, what is the proper way to revert back to upstream defaults
> > in this case? Should I append "--force" to the command? (I don't want
> > to destroy my system, that's why I'm not simply trying it. All of
> > this seems awfully complex and fragile).
>
> Yes, use --force. That tells authselect that it is OK to overwrite your
> manual configuration. Otherwise, authselect is careful to not overwrite
> files that have been edited manually.
>

Sigh, authselect is even more complicated than I thought. I can't simply do
"sudo authselect apply-changes --force". I need to do "sudo authselect
select $something --force" first, according to the man page. And I have no
idea what $something is. Can you please provide an exact set of commands to
run? Thanks.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Manual intervention required: broken /etc/nsswitch.conf and /etc/resolv.conf for F33 early adopters

[Kamil Paral]

On Thu, Sep 10, 2020 at 5:54 PM Michael Catanzaro 
wrote:

> On Thu, Sep 10, 2020 at 9:36 am, Kamil Paral  wrote:
> > On Thu, Sep 10, 2020 at 8:54 AM Mikhail Gavrilov
> >  wrote:
> >> # authselect apply-changes
> >>  [error] [/etc/authselect/nsswitch.conf] has unexpected content!
> >>  [error] Unexpected changes to the configuration were detected.
> >>  [error] Refusing to activate profile unless those changes are
> >> removed or overwrite is requested.
> >>  Some unexpected changes to the configuration were detected. Use
> >> 'select' command instead.
> >
> > I see the same error.
>
> I'm a bit concerned that two different people are seeing this. I don't
> think we have any scriptlets tha writes to /etc/nsswitch.conf or
> /etc/authselect/nsswitch.conf on its own. But maybe, for non-live
> installs, that could happen if the systemd RPM gets installed before
> the authselect RPM? Then systemd would think /etc/nsswitch.conf is not
> managed by authselect. Hm
>
> Anyway, if you can find a way to get to this state from a clean
> install, without touching those files manually, then please do report a
> bug. That shouldn't be happening.
>

I did edit /etc/nsswitch.conf manually, because obviously I needed a
working system :) The confusing part here is that the error message claims
that **/etc/authselect/nsswitch.conf** has unexpected content. So this
doesn't seem to be related to /etc/nsswitch.conf having been edited by
hand. Is it? If it is, what is the proper way to revert back to upstream
defaults in this case? Should I append "--force" to the command? (I don't
want to destroy my system, that's why I'm not simply trying it. All of this
seems awfully complex and fragile).
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Manual intervention required: broken /etc/nsswitch.conf and /etc/resolv.conf for F33 early adopters

[Kamil Paral]

On Thu, Sep 10, 2020 at 8:54 AM Mikhail Gavrilov <
mikhail.v.gavri...@gmail.com> wrote:

> # authselect apply-changes
> [error] [/etc/authselect/nsswitch.conf] has unexpected content!
> [error] Unexpected changes to the configuration were detected.
> [error] Refusing to activate profile unless those changes are removed or
> overwrite is requested.
> Some unexpected changes to the configuration were detected. Use 'select'
> command instead.
>

I see the same error.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Blocker Review discussion tickets -- now available

[Kamil Paral]

Hello everyone,

I'd like to announce a new project of the QA team and an extension of the
BlockerBugs App [1]. The blocker and freeze exception proposals can now not
only be discussed during regular blocker review meetings [2], but also at
any time through discussion tickets hosted on Pagure [3]. So even if you
don't have time to participate in the meeting, you can still participate
and vote in those discussion tickets.

This will be mostly interesting to people who participated in blocker
review meetings in the past, but we hope we can attract new participants
this way. It is also very useful for package maintainers and developers,
because they can now easily provide feedback regarding a proposed blocker
or a freeze exception without attending a meeting at a particular time or
diluting a technical discussion in Bugzilla.

To participate, open the BlockerBugs App for a particular milestone (e.g.
F33 Beta [4]) and you'll see "Vote!" and "Discuss" links for
proposed/accepted blockers and freeze exceptions. Follow the links to see
tickets where you can express your opinion (which should ideally reflect
our release criteria [5]). You can vote according to the guide present at
[3], please read it carefully. A bot is following each ticket, updating the
voting summary, and accepting certain commands. Watching the Pagure repo
[3] also gives you the option to get notified about every new proposed
blocker/freeze exception.

We've been using these discussions for a week or two now (I apologize for a
late announcement) and so far our existing practice seems to be to vote for
proposals throughout the week using these discussion tickets, close those
which we can easily get enough votes and agree on, and discuss the
remainder during the next blocker review meeting. So the regular blocker
review meeting hasn't been replaced, but we use the discussion tickets to
cut down on the meeting length. We're still trying to figure out the best
approach to take here, so nothing is set in stone. The voting functionality
itself is also still in development, we'll try to provide new features and
improve the experience based on your feedback.

I'll be happy to answer questions, if there are any.
Thanks,
Kamil
Fedora QA

PS: Development credits go to Lukas Brabec, Frantisek Zatloukal, Tim Flink,
Josef Skladanka and Adam Williamson.

[1] https://qa.fedoraproject.org/blockerbugs/
[2] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
[3] https://pagure.io/fedora-qa/blocker-review
[4] https://qa.fedoraproject.org/blockerbugs/milestone/33/beta/buglist
[5] https://fedoraproject.org/wiki/Fedora_Release_Criteria
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-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/devel-announce@lists.fedoraproject.org

[Test-Announce] Blocker Review discussion tickets -- now available

[Kamil Paral]

Hello everyone,

I'd like to announce a new project of the QA team and an extension of the
BlockerBugs App [1]. The blocker and freeze exception proposals can now not
only be discussed during regular blocker review meetings [2], but also at
any time through discussion tickets hosted on Pagure [3]. So even if you
don't have time to participate in the meeting, you can still participate
and vote in those discussion tickets.

This will be mostly interesting to people who participated in blocker
review meetings in the past, but we hope we can attract new participants
this way. It is also very useful for package maintainers and developers,
because they can now easily provide feedback regarding a proposed blocker
or a freeze exception without attending a meeting at a particular time or
diluting a technical discussion in Bugzilla.

To participate, open the BlockerBugs App for a particular milestone (e.g.
F33 Beta [4]) and you'll see "Vote!" and "Discuss" links for
proposed/accepted blockers and freeze exceptions. Follow the links to see
tickets where you can express your opinion (which should ideally reflect
our release criteria [5]). You can vote according to the guide present at
[3], please read it carefully. A bot is following each ticket, updating the
voting summary, and accepting certain commands. Watching the Pagure repo
[3] also gives you the option to get notified about every new proposed
blocker/freeze exception.

We've been using these discussions for a week or two now (I apologize for a
late announcement) and so far our existing practice seems to be to vote for
proposals throughout the week using these discussion tickets, close those
which we can easily get enough votes and agree on, and discuss the
remainder during the next blocker review meeting. So the regular blocker
review meeting hasn't been replaced, but we use the discussion tickets to
cut down on the meeting length. We're still trying to figure out the best
approach to take here, so nothing is set in stone. The voting functionality
itself is also still in development, we'll try to provide new features and
improve the experience based on your feedback.

I'll be happy to answer questions, if there are any.
Thanks,
Kamil
Fedora QA

PS: Development credits go to Lukas Brabec, Frantisek Zatloukal, Tim Flink,
Josef Skladanka and Adam Williamson.

[1] https://qa.fedoraproject.org/blockerbugs/
[2] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
[3] https://pagure.io/fedora-qa/blocker-review
[4] https://qa.fedoraproject.org/blockerbugs/milestone/33/beta/buglist
[5] https://fedoraproject.org/wiki/Fedora_Release_Criteria
___
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 -- devel@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/devel@lists.fedoraproject.org

Re: BTRFS, relatime vs. noatime

[Kamil Paral]

On Sun, Sep 6, 2020 at 1:37 AM Chris Murphy  wrote:

> But if you've got a snapshot once per day, times ten days, and this kind
> of aggressive search function touching every file? Maybe an extra 1-2G of
> metadata being pinned
>

I don't follow. If you have one master copy and 10 snapshots, and you
change the metadata on the master copy, why would it generate more metadata
(than when having a single snapshot)? All those snapshots can share the
same metadata block (provided the file wasn't changed in the meantime) and
just the master copy would get a new metadata block. So it should be the
same amount of newly written blocks, regardless of how many snapshots you
have. What am I missing?
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Release criteria proposal: first boot experience

[Kamil Paral]

On Fri, Sep 4, 2020 at 8:17 PM Adam Williamson 
wrote:

> On Fri, 2020-09-04 at 12:12 -0500, Michael Catanzaro wrote:
> > On Wed, Sep 2, 2020 at 12:57 pm, Kamil Paral  wrote:
> > > Overall I find the criterion reasonable and useful and I'm +1 to
> > > incorporating it. Its current phrasing seems fine to me.
> >
> > So how does the process of adding the new criterion work? I guess we
> > should leave the weekend for additional comment, in case anybody wants
> > to suggest improvements, but it'd be nice to get this incorporated into
> > the release criteria and repropose the gnome-initial-setup bug.
>
> To be honest it's something we've never had the roundtuits to write up
> in a nice clean policy. The convention is basically: once a draft has
> been up for a while (say, a week or two, depending on urgency) without
> significant objections, you just go ahead and add it to the wiki. i.e.
> it's a fuzzy consensus system. :)
>

Yes, but I find it concerning that I was the only one who provided feedback
to this proposal. It might have been partially caused by the fact that it
wasn't sent to the test list. I urge everyone who has some opinion on this
to provide it, at least in the form of a thumbs up. Thanks.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: F34 Change: Reduce installation media size by improving the compression ratio of SquashFS filesystem (Self-Contained Change)

[Kamil Paral]

On Fri, Sep 4, 2020 at 6:17 AM John Reiser  wrote:

> On 2020-09-01 at 12:13 UTC, Kamil Paral wrote:
> [[snip]]
> >  I'd like to ... hugely speed up the installation instead
> [[snip]]
>
> Zstd is faster than xz at de-compression, but a much larger speed
> improvement
> would be to parallelize and pipeline "rpm --install".  This would benefit
> both install and the creation of 'mock' build environments.
>

Yes, but that's not what this enhancement is about. Also it would have no
effect on Live image installation. Let's not distract this discussion with
independent topics, rather let's discuss this particular proposal.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: F34 Change: Reduce installation media size by improving the compression ratio of SquashFS filesystem (Self-Contained Change)

[Kamil Paral]

On Wed, Sep 2, 2020 at 8:28 PM Matthew Miller 
wrote:

> On Tue, Sep 01, 2020 at 02:13:21PM +0200, Kamil Paral wrote:
> > Bohdan, could you build the same image in several configurations (the
> most
> > likely candidates) and share them with us? (We can host them in our QA
> > fedorapeople space, if needed). That would allow interested parties to
> test
> > and benchmark the experience themselves.
>
> Would it be crazy for us to produce some of the artifacts in _both_
> varieties?
>

That's a question for Releng. However, QA would have to validate both...
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Release criteria proposal: first boot experience

[Kamil Paral]

On Tue, Sep 1, 2020 at 10:24 PM Michael Catanzaro 
wrote:

> Hi,
>
> We currently have a bug where the Online Accounts page in initial setup
> is nonfunctional. [1] This doesn't violate any current release
> criterion, but surely we don't want to release with a broken initial
> setup experience. So let's add a new requirement for that. How about
> something like:
>
> "If an initial setup utility is run or intended to be run after the
> first boot of the installed system, then it must start successfully and
> each page or panel of the initial setup utility should withstand a
> basic functionality test."
>
> OK that's pretty basic, but it gets the point across. I think this can
> be a final requirement, not necessarily important enough to be a beta
> requirement. Bikeshed away!
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1870476


Hey Michael,
all criteria proposals should definitely (also) go to the test list, adding
into CC.

Just to put everyone on the same page, we already have this Basic criterion:
"A system installed with a release-blocking desktop must boot to a log in
screen where it is possible to log in to a working desktop using a user
account created during installation or a 'first boot' utility."
https://fedoraproject.org/wiki/Basic_Release_Criteria#Expected_installed_system_boot_behavior

That means that user creation is already guaranteed to be functional (but
might be rough around the edges). Of course that doesn't cover any other
actions available in the initial setup. Therefore your proposal (targeting
the Final milestone, which seems sensible) makes sense in this regard.

There are the screens in the initial setup:
1. Welcome
2. Privacy (Location Services, Automatic Problem Reporting)
3. Online Accounts (Google, Nextcloud, Microsoft, Facebook)
4. About You (Name, Username, Enterprise Login)
5. Password
6. Done

Since every screen contains just a couple of things, the "basic
functionality test" as you phrased it seems to cover essentially everything
that is present in there, with one arguable exception of the Enterprise
Login functionality. Do you have the same impression?

This will also cover the other initial setup screen that is visible for KDE
and other desktops (does it run also for ARM text installs? I'm not sure).
That one contains:
1. User Creation (Name, Username, Password, Make admin, Advanced)
And that was all (at least for my KDE install during which I didn't create
a regular user).

Overall I find the criterion reasonable and useful and I'm +1 to
incorporating it. Its current phrasing seems fine to me.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: F34 Change: Reduce installation media size by improving the compression ratio of SquashFS filesystem (Self-Contained Change)

[Kamil Paral]

On Fri, Aug 28, 2020 at 12:55 AM Michel Alexandre Salim <
mic...@michel-slm.name> wrote:

> On Thu, 2020-08-27 at 11:13 -0400, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/OptimizeSquashFS
> >
> > == Summary ==
> > Improve compression ratio of SquashFS filesystem on the installation
> > media.
> >
> ...
> >
> > Based on the results above, I'd suggest selecting the following
> > ''optimal configuration'': XZ algorithm, with block size of 1MiB and
> > without BCJ filter (plain xz -b 1M, without -Xbcj x86).
> > On the right, you can see the impact of the compression algorithms on
> > installation time.
> >
> Why XZ as opposed to, say, ZSTD?
>

Bohdan's preference seems to be to make the images smaller. I'm in the
opposite camp. I'd like to keep the images roughly the same size (or
smaller, but just a bit smaller, not as small as possible) and hugely speed
up the installation instead. Which means zstd in one of the configurations.
Each image is downloaded just once, but installed 1+ times. And with
automation and all the CI work which Fedora and Red Hat invests a lot of
effort into, it can be a hundred installations from a single image (without
being bound to slow USB stick transfer speeds, as in the proposal). Of
course, I'm biased.

Bohdan, could you build the same image in several configurations (the most
likely candidates) and share them with us? (We can host them in our QA
fedorapeople space, if needed). That would allow interested parties to test
and benchmark the experience themselves.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Release criteria proposal: networking requirements

[Kamil Paral]

On Sat, Aug 29, 2020 at 1:59 AM Adam Williamson 
wrote:

> On Fri, 2020-08-21 at 17:11 -0700, Adam Williamson wrote:
> > Hi folks!
> >
> > So at this week's blocker review meeting, the fact that we don't have
> > explicit networking requirements in the release criteria really started
> > to bite us. In the past we have squeezed networking-related issues in
> > under other criteria, but for some issues that's really difficult,
> > notably VPN issues. So, we agreed we should draft some explicit
> > networking criteria.
>
> Update: here's a second draft with feedback so far incorporated, thanks
> to everyone. Still mulling over whether/how to split it more across
> milestones.
>
> === Network requirements ===
>
> Each of these requirements apply to both installer and installed system
> environments. For any given installer environment, the 'default network
> configuration tools' are considered to be those the installer documents
> as supported ways to configure networking (e.g. for anaconda-based
> environments, configuration via kernel command line options, a
> kickstart, or interactively in anaconda itself are included).
>
>  Basic networking 
>
> It must be possible to establish both IPv4 and IPv6 network connections
> using both typical router-provided addressing systems (e.g. DHCP on
> IPv4 or SLAAC or IPv6) and static addressing. The default network
> configuration tools for the console, for release-blocking desktops and
> for installer environments must work well enough to allow typical
> network connection configuration operations without major workarounds.
> Standard network functions such as address resolution and connections
> with common protocols such as ping, HTTP and ssh must work as expected.
>
> Footnote titled "Supported hardware": Supported network hardware is
> hardware for which the Fedora kernel includes drivers and, where
> necessary, for which a firmware package is available. If support for a
> commonly-used piece or type of network hardware that would usually be
> present is omitted, that may constitute a violation of this criterion,
> after consideration of the [[Blocker_Bug_FAQ|hardware-dependent-
> issues|normal factors for hardware-dependent issues]]. Similarly,
> violations of this criteria that are hardware or configuration
> dependent are, as usual, subject to consideration of those factors when
> determining whether they are release-blocking
>
>  VPN connections 
>
> Using the default network configuration tools for the console and for
> release-blocking desktops, it must be possible to establish a working
> connection to common OpenVPN, openconnect-supported and vpnc-supported
> VPN servers with typical configurations.
>
> Footnote titled "Supported servers and configurations": As there are
> many different VPN server applications and configurations, blocker
> reviewers must use their best judgment in determining whether
> violations of this criterion are likely to be encountered commonly
> enough to block a release, and if so, at which milestone. As a general
> principle, the more people are likely to use affected servers and the
> less complicated the configuration required to hit the bug, the more
> likely it is to be a blocker.
>

Sounds good to me.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Release criteria proposal: networking requirements

[Kamil Paral]

On Sat, Aug 29, 2020 at 1:57 AM Adam Williamson 
wrote:

> On Thu, 2020-08-27 at 10:06 -0600, Chris Murphy wrote:
> > On Fri, Aug 21, 2020 at 6:11 PM Adam Williamson
> >  wrote:
> > >
> > >  Basic networking 
> > >
> > > It must be possible to establish both IPv4 and IPv6 network connections
> > > using DHCP and static addressing. The default network configuration
> > > tools for the console and for release-blocking desktops must work well
> > > enough to allow typical network connection configuration operations
> > > without major workarounds. Standard network functions such as address
> > > resolution and connections with common protocols such as ping, HTTP and
> > > ssh must work as expected.
> >
> > What about mDNS?
>
> ehhh
>
> I am probably a bit biased on this front because I always found mDNS to
> be a pile of garbage and gave up trying to use it a while back. :P But
> if a significant amount of people are actually using it and relying on
> it, adding it might make sense. Anyone else have input on this? Who out
> there does use mDNS?
>

I contact my machines (even VMs) through .local every day, I'd be
very angry if it didn't work, and I consider myself a significant amount of
people ;o)
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Proposal to Add: Log In/Out Blocker Criteria

[Kamil Paral]

On Wed, Aug 12, 2020 at 4:25 PM Kamil Paral  wrote:

> I'd accept the criterion as proposed (because we need it now), and do the
> reorganization later (possibly when this cycle is over and we have more
> time to bikeshed about best criterion layout). I'm fine with either adding
> to the existing criterion (mine version) or creating a standalone criterion
> (Geoff's version), just note that the standalone version would still need
> to get tweaked (remove "multiple user accounts", etc).
>

In accordance with the discussion during the last QA meeting, I've put my
proposed changes live:
https://fedoraproject.org/w/index.php?title=Fedora_33_Beta_Release_Criteria=revision=586432=576081
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Making `ls` colours follow terminal configuration

[Kamil Paral]

On Thu, Aug 6, 2020 at 3:25 PM Allan Day  wrote:

> Hi all,
>
> coreutils currently configures `ls` to use 256 colours rather than 16.
> This is a downstream Fedora change which means that `ls` doesn't
> follow the colour palette that's configured in the terminal.
>

It makes sense to synchronize with upstream again. And the fact that ls
didn't follow my configured colors in gnome-terminal was somewhat annoying.
Thumbs up from me.
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Proposal to Add: Log In/Out Blocker Criteria

[Kamil Paral]

On Thu, Aug 6, 2020 at 5:47 AM Stephen J. Turnbull 
wrote:

> I'm really uncomfortable about the amount of crossp-posting, so I'm
> limiting this to devel@ (I receive it) and test@ (obvious to me why
> relevant).
>
> Kamil Paral writes:
>  > Adam writes:
>
>  > > Arguably the environment from which they logged in is not
>  > > "working as expected" if you can't then log in as someone else.
>  >
>  > However, the existing basic criterion [1] only requires the *initially*
>  > created user to be able to log in. So if you create a second user, and
>  > can't log in with it after a system boot,
>
> Adam's argument is that this is covered by "working as expected".
>

It's not covered in the situation I described. Adam's quoted criterion only
applies after log out, and so it doesn't apply to secondary users (created
after system installation) which try to log in immediately after system
boot (so there is no previous log out) and it fails.


>
> FWIW, I think that the criterion should be something like
>
> users created by *scripts* as part of a *supported* installation
> or upgrade process and which are documented as able to log in,
> must be able to log in from any condition where login is
> documented to be possible.  Logging out must return the login
> facilities to the state in which log in occurred unless some
> *condition* (such as shutdown in progress) *explicitly* changes
> it.
>

I don't think we should only guarantee login for users created during
installation. That seems very poor QA and I wouldn't want to use a system
in which I can create a user but it can't log in and "it's OK". We should
guarantee login for all users which pass some sanity check (i.e. you create
them using standard tools and approaches and don't do anything horrible to
them). Unlike your proposed criterion (which is very convoluted to cover
those corner cases), I don't think we need to specify them. That's the
point of the blocker meeting, to discuss that particular situation. If
somebody removed their login shell, well, that's clearly not our problem
and not a criterion violation - it doesn't need to be codified. On the
other hand, if a regular system update removed that login shell, that's a
big bummer on our side. I prefer easy-to-understand criteria which might
not cover all corner cases (they'll never will, even if you try), but
convey the intended goal well, and people can then use them as a basis for
decision making (while considering all the circumstances).

I'm not sure what you mean by "documented". I wouldn't rely on Fedora
documentation too much in these cases. So that would mean we'd also need to
create and maintain some lists of "which users are supposed to be able to
log in" and "in which conditions the logins are possible".
___
devel mailing list -- devel@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/devel@lists.fedoraproject.org

Re: Poor first time experience for potential contributors interested in release validation

[Kamil Paral]

On Thu, Aug 6, 2020 at 5:16 AM Jonathan Watt  wrote:

> I originally reported this issue at
> https://bugzilla.redhat.com/show_bug.cgi?id=1862703 but was asked to
> re-report it here:
>
> I was using whatcanidoforfedora.org to see what areas I could contribute
> to. I selected "Validate Releases" and it took me to the QA wiki:
>
>   https://fedoraproject.org/wiki/QA/Join#release-validation
>
> That section says:
>
>   For information on getting and installing pre-releases, see .
>

Actually, it's in this section:
https://fedoraproject.org/wiki/QA/Join#Testing_Fedora_pre-releases
where it talks about Alpha and Beta releases. And since we have none for
F33 yet, the get-prerelease page is empty. At least I hope it will come
alive again once we have a Beta compose (Alphas are no longer produced).
The wording could be improved regarding this, yes.

What is applicable right now is Rawhide testing, release validation testing
(on Rawhide) and test days. We'll be branching F33 from Rawhide during the
next week or so, I believe, so then it will become F33 testing instead of
Rawhide testing.

As Ben said in Bugzilla, the best place to talk about this is the test list
[1] (this is not the test list), or you can create tickets for us in our
tracker [2].

Thanks for your interest in helping us!

[1]
https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/
[2] https://pagure.io/fedora-qa
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-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/qa-devel@lists.fedoraproject.org