Re: Moving away from the term "karma" in Bodhi

[Lukas Ruzicka]

Agreed, Arnie.


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
-- 
___
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: Moving away from the term "karma" in Bodhi

[Lukas Ruzicka]

> I think this is _why_ we should change it. We don't mean _any_ of that.

@matthew,
I did not say that we mean something of that or that we should or should
not mean any of that. The truth is, words not only have a denotation, they
also have connotations. They might be positive or negative. For me, the
connotations of the word "karma" are positive and I cannot come up with a
negative one. Therefore, I am not convinced the word itself could be a
problem.

On the other hand, I agree that it might not be clear for newcomers, but as
it has been part of the Fedora system and "culture" for such a long time a
question arises: Should we throw our culture away to please anybody passing
by who just lurks in for a while?

@michael,
I consider myself a believer  (not a Buddhist however) so I cannot speak
for the word Karma, but I would not feel offended if we called something a
"shrine", or "redeemer" or whatever. Actually, if I were a Buddhist, I
would feel offended by us removing the word Karma.

By the way, the word "Bodhi" itself has a significant religious meaning and
we are not taking Bodhi away, however I somehow feel this is going to be
the next step.

@mattia,
The ticket you have posted for us to view has been merged which means that
the change has already been made. I do not think this is how we should be
doing things. The discussion here has been going on still. What is the
point to bring that information to a list, if you do not want to wait for
other people's opinions?
-- 
___
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: Moving away from the term "karma" in Bodhi

[Lukas Ruzicka]

Well, I am very sad about this step and I feel very sorry that you are
trying to remove the word karma from the process. I believe that Karma
denotes one of the most powerful, the most noble, and the most fair
principles of this world, because traditionally it is above this world.
Kudos, or anything you have suggested, is far less.

The Linux world has always had a kind of "lore" with interesting project
names, acronyms, which mostly were made up as "pun intended". I do not
understand why anybody has an urge to take this away.

Please, think twice about it, because the world will always get you people
that want to diminish the meaning of your contribution to the project by
claiming that your work is not noble/tolerant/clean/you-name-it enough.
Once you take a step back, they will take up new positions and they'll
start pushing again.

And you will hardly get back what you let go.

On Mon, Nov 11, 2024 at 9:16 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Mon, Nov 11, 2024 at 08:47:57AM +0100, Sandro wrote:
> > On 11-11-2024 08:27, Zbigniew Jędrzejewski-Szmek wrote:
> > > On Sun, Nov 10, 2024 at 03:18:49PM +, Mattia Verga via devel wrote:
> > > > I have started to move away Bodhi from using the term "karma" to rate
> > > > updates. I know this word has become familiar to all Fedora users,
> but
> > > > there were several requests in the past to stop the misuse. As I may
> not
> > > > be the most "politically correct" person you know, this task has been
> > > > low priority for me; nevertheless, I've now found some spare time to
> > > > start working on it.
> > > >
> > > > So, I plan to replace the term "karma" with "feedback" where users
> > > > submit their (+1|0|-1) vote: a Comment will no more have the "karma"
> > > > property, but it will be "feedback". At the same time, TestCaseKarma
> and
> > > > BugKarma will become TestCaseFeedback and BugFeedback.
> > > >
> > > > For updates, the term "karma" is used as the sum of all
> karma|feedback
> > > > submitted by users, so I plan to rename this to "rating". English is
> not
> > > > my native language, but I think it is correct to rate an update
> > > > positive|neutral|negative and rating should be quite understandable
> to
> > > > foreign speakers.
> > >
> > > Is this decision final? "karma" is a distinct term that is not easily
> > > confused. But if you tell me that an update had a negative "rating",
> > > people in Fedora will not know what you're talking about. The word
> > > is much more generic.
> >
> > How about replacing the term "karma" with "kudos"? It has a similar ring
> to
> > it and should be uncontroversial.
>
> That's a great idea. If we are to change, please do 'kudos' rather
> 'rating'/'feedback'/'evaluation'.
>
> Zbyszek
>
> > Could the icon above the colon voor neutral (neither positive nor
> negative)
> > be changed at the same time to make it more distinct? It now uses the
> same
> > thumbs up as the positive colon, wrongly suggesting the default selection
> > being positive karma|kudos|feedback when it actually doesn't add to the
> > count.
> >
> > -- Sandro
> >
> > --
> > ___
> > 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
> --
> ___
> 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
>


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
-- 
___
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: I need help with update.install_default_update_live _boot_to_anaconda module failed (Fedora 34 openssl update)

[Lukas Ruzicka]

This is not OpenSSL related, probably just a minor glitch.
I have restarted the test and it passed:

https://openqa.fedoraproject.org/tests/993723#



On Tue, Sep 21, 2021 at 11:57 AM Miro Hrončok  wrote:

> Hello,
>
> I've created this Fedora 34 openssl update:
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2021-0ba998eb43
>
> Repeatedly, the update.install_default_update_live test fails with:
>
>   _boot_to_anaconda module failed
>
> I have no idea how to diagnose the failure at
> https://openqa.fedoraproject.org/tests/992742 or if it is openssl related
> at all.
>
> Could somebody please help me?
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> 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
>


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
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: Fedora Jam switch to GNOME

[Lukas Ruzicka]

Hi Erich,

so today I spent some time in the recording session with the following
settings and configurations:

   - The machine is 2x 12core Intel Xeon with an SSD drive and 32GB RAM - I
   know that this is a recording overkill and I am not sure how much the
   machine itself can influence the recording process.
   - Soundcard is Focusrite Scarlett 2i4 over USB
   - My system is an updated Fedora Workstation 32 with stock kernel (I
   only lifted up the ulimits)
   - The recording session was set to 48KHz, 32bit float audio
   - The session had about 15 tracks, out of which there were 5 sound+midi
   tracks and the rest were sound tracks

and I have made the following observations:

   - the session could perform playback normally on 512 samples and 10ms
   latency
   - when I recorded on 512 samples and 10ms latency, I could work
   flawlessly for about 10 or 15 minutes and then, all of a sudden, Ardour
   spat a bunch of xruns. I started to delete the xrun markers one after
   another and Ardour crashed.
   - then I restarted it on 1024 samples and 21ms latency which was fine
   for the rest of the work -> did not have any more xruns.

So, I can confirm, that with the above settings I can use stock Fedora
Workstation with Gnome desktop for my recording at 1024 samples with 21ms
latency.
I could not test higher freqencies, because I do not have any such a
project ready, but when I experimented with 192KHz, I was fine with 2048
sampes and 42ms latency, which I remember very well (from that experience
my settings of 2048 samples do originate from).

I hope you can use this info, if you needed something else, please let me
know.


On Wed, Jun 10, 2020 at 8:13 PM Harsh Jain  wrote:

> Hi Erich ,
> Sorry , I thought the primary focus was to find a new de to shift to .
> Improving Gnome in terms of reducing resource usage (and in general )
> seems pretty nice . I'd be happy to have another de I can work smoothly
> with :)
> This might not be relevant but if you install pantheon de , you can switch
> to gnome on the logout screen (even if you didn't install it ) and it
> basically brings gnome shell with pantheon apps .
> I felt it was a bit smoother than normal gnome ( I didn't test this
> extensively but everything seemed to work fine ) .Maybe this can help in
> some way ?
> Thanks ,
> Harsh
>
> On Wed, 10 Jun, 2020, 22:10 ,  wrote:
>
>> On Wed, 2020-06-10 at 22:01 +0530, Harsh Jain wrote:
>> > Hi ,
>> > I'm not too familiar with Fedora Jam but if you want to minimize
>> > resource usage , shouldn't XFCE be a better choice since it's less
>> > intensive with resources . Although Gnome has also reduced resource
>> > usage since initial 3.x releases as well I think . It's just really
>> > hard to decide between evrything (l'm de hopping currently as well) .
>> > Again ,I'm sorry if none of this was useful .
>> > Thanks ,
>> > Harsh
>> >
>>
>> Hi Harsh,
>>
>> I also lead Ubuntu Studio and we just moved away from Xfce to KDE
>> Plasma because we wanted a more-functional desktop for creative
>> professionals. The resource usage between Xfce and Plasma is neglegable
>> (about 50MB difference) and KDE is a better choice for graphics artists
>> (which Ubuntu Studio also covers.
>>
>> I think you missed the point though: the goal is to help GNOME improve.
>> I've had conversations with people who want to see GNOME improve in
>> this regard and want to work with me in improving it. So, this isn't
>> about simply switching desktops, this is about helping another desktop
>> improve its situation. If Jam is to switch, it's going to GNOME, that
>> decision is already made. The "If" is what I'm working on, whether or
>> not to actually go through with it.  If it does happen, the goal is to
>> improve GNOME. One can always install whatever desktop they want and do
>> "dnf groupinstall 'Audio Production'".
>>
>> I hoep that clears things up, as I think you missed the point. :)
>>
>> Erich
>> ___
>> 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
>>
> ___
> 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
>


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

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

Re: Fedora Jam switch to GNOME

[Lukas Ruzicka]

>
> This is exactly the kind of feedback i'm looking for. Thanks! I do know
> that under Plasma and Xfce I've seen < 2ms latency with the right
> hardware (PCI cards, primarily). I've been able to push my Behringer
> UMC404HD (a USB interface) under 10 before. I have yet to do any formal
> testing on GNOME, but I'm glad to read what you wrote. Thanks!
>

Now, I am playing back a previously recorded project with 512 samples,
which gives the latency of 10ms and Ardour is performing fine
without any xruns. The project has 10 tracks and each track has about 3
plugins used. It is getting late here, but if you want, I can try to record
something tomorrow and see which latency I can go to before getting  xruns
and give the feedback here.

I agree that you do not want even one xrun in your session.

PS: I might find out that latency is no more an issue as it was before. I
guess I am using such benevolent settings just for sure.


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


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
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 Jam switch to GNOME

[Lukas Ruzicka]

offering. That's less about GNOME vs KDE and more about PipeWire still
> needing work to be broadly adopted.
>
>
Well, does it mean that PipeWire is going to replace Jack? Because if not,
then it is a non-issue for recording anyway.




>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> 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
>


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
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 Jam switch to GNOME

[Lukas Ruzicka]

Hello,

I am using Fedora Workstation with the stock kernel and Gnome Desktop for
my recording attempts with Ardour. I am using the Focusrite Scarlett USB
sound card and I can get down to 40ms latency without getting any xruns (a
couple of releases back, it was an xrun hell). I am aware that the 40ms are
nothing really good, but since I only do some folkie stuff (upto 15 tracks)
it is OK for me and I think that you can make music on Gnome Desktop.

However, I am totally aware that people like to use what they are used to.

Lukas

On Wed, Jun 10, 2020 at 7:21 PM Kalev Lember  wrote:

> Hi Erich,
>
> I think this is a great idea -- thanks for getting the discussion started!
>
> I've always found it weird that the Jam spin is based on another desktop,
> different from what Fedora Workstation uses. I think it makes a lot of
> sense to switch over and try to improve the audio issues in GNOME. We have
> a lot of Fedora developers who are also GNOME upstream developers and this
> should create nice synergies.
>
> As you may be aware, Wim Taymans has been working on pipewire that
> Workstation ships with, with the goal of improving the audio and video
> experience in Fedora Workstation and GNOME and Linux desktop in general.
> The Jam spin switching to GNOME makes a lot of sense in this context --
> that way the Jam users can quickly give feedback on any pipewire issues and
> feature requests, hopefully improving the overall situation quickly.
>
> Good idea and +1 from me.
>
> --
> Kalev
>
>
> On Wed, Jun 10, 2020 at 6:10 PM  wrote:
>
>> Hi all,
>>
>> I'm considering moving Fedora Jam from KDE Plasma to GNOME. There are
>> multiple reasons for this, and I think part of it would be beneficial
>> to the overall GNOME and Fedora communities as it would be a way to be
>> helping improve the situation in GNOME that exist as the biggest
>> objections from the community of musicians and Linux audio enthusiasts
>> in the overall community.
>>
>> The biggest objections are resource usage, since the more resources
>> that are in use, the more it tends to interfere with real-time audio
>> processes, causing buffer overruns and/or underruns. These overruns and
>> underruns are known as Xruns. The fewer Xruns, the better, as Xruns
>> cause pops during recording. When doing real-time audio work, you want
>> to have as low of latency as possible which requires as small of a
>> buffer as possible. The goal is to have a small buffer to get minimal
>> latency while avoiding Xruns.
>>
>> Unfortunately, GNOME has, since 3.0, traditionally interfered with
>> these processes and caused Xruns. My goal, by moving Fedora Jam from
>> Plasma to GNOME, is to help GNOME improve this situation.
>>
>> The other reason for switching away from Plasma is the overall negative
>> attitude I see from Fedora KDE users and former Fedora KDE
>> contributors. It seems to be an attitude against the progress of
>> improving the Linux desktop for the better, and simply complaining. I
>> know some of this attitude comes from Red Hat dropping KDE from being a
>> desktop in REHL, among other changes. That attitude is regressive, and
>> does nothing to help the community if all you do is complain. I could
>> name names, but for the sake of the "Friends" foundation, I will not.
>>
>> Anyhow, I'd love to see a discussion about this as well as any guidance
>> toward making this change. I know there would have to be a new
>> kickstart along with Koji pointing toward said kickstart. I could make
>> the kickstart, but I think I'd need Koji to look for it.
>>
>> Thanks and best regards,
>> Erich
>> 
>> Erich Eickmeyer
>> Fedora Jam
>> ___
>> 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
>>
> ___
> 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
>


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
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: Anaconda RFE: change in default behaviour when adding users.

[Lukas Ruzicka]

Hello again,

this was my mistake, I overlooked the fact, that I cannot start the
installation when either root or user admin are set up. This behaviour
seems pretty logical to me, so I am taking the previous message back.
Please ignore it and sorry for the inconvenience.

Lukas

On Tue, Mar 3, 2020 at 3:15 PM Lukas Ruzicka  wrote:

> Hello,
> today I have been doing some Anaconda testing and realized that there was
> a change in default
> behaviour of Anaconda when adding users to the system.
>
> Previously:
>
>1. The root account was not locked by default.
>2. The user account was not an admin account.
>
> Currently:
>
>1. The root account is locked by default.
>2. The user account is not an admin account.
>
> I think that this default setting could mean a risk of people forgetting
> to tick the "Make user admin" checkbox and end up with an unusable system.
>
> I would like to propose that by default:
>
>1. The root account is locked.
>2. The user account "Make user admin" is checked.
>
> Nice to have:
>
>1. The user account "Make user admin" could behave according to the
>setting of the root account.
>2. With root unlocked, the user should be NOT admin by default.
>3. With root locked, the user should be admin by default.
>
> What do you think?
>
> --
>
> Lukáš Růžička
>
> FEDORA QE, RHCE
>
> Red Hat
>
> <https://www.redhat.com>
>
> Purkyňova 115
>
> 612 45 Brno - Královo Pole
>
> lruzi...@redhat.com
> TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <https://redhat.com/trusted>
>


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat

<https://www.redhat.com>

Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <https://redhat.com/trusted>
___
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

Anaconda RFE: change in default behaviour when adding users.

[Lukas Ruzicka]

Hello,
today I have been doing some Anaconda testing and realized that there was a
change in default
behaviour of Anaconda when adding users to the system.

Previously:

   1. The root account was not locked by default.
   2. The user account was not an admin account.

Currently:

   1. The root account is locked by default.
   2. The user account is not an admin account.

I think that this default setting could mean a risk of people forgetting to
tick the "Make user admin" checkbox and end up with an unusable system.

I would like to propose that by default:

   1. The root account is locked.
   2. The user account "Make user admin" is checked.

Nice to have:

   1. The user account "Make user admin" could behave according to the
   setting of the root account.
   2. With root unlocked, the user should be NOT admin by default.
   3. With root locked, the user should be admin by default.

What do you think?

-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
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: Change proposal discussion - Optimize SquashFS Size

[Lukas Ruzicka]

Hello everybody,
as I see it, we all want the same, but the priorities differ. My several
cents (although I will repeat myself):

*Let us properly curate the composes in terms of shipped applications
(a.k.a essential applications)*
Explanation: Our composes ship too many applications. By making a clever
selection of applications shipped in the default installation,
we could fix many of our problems. I remember that Windows used to install
an empty unusable system without any useful application. Linux distros, on
the other hand have plenty of applications by default and newbies do not
know which one to use, power users perhaps use a different set of apps, so
they need to install extra anyway. What if we made sure that our composes
have (this is just an example list, this would need an extra discussion)
and nothing more:

   - one terminal emulator
   - standard set of console applications
   - one desktop environment
   - applications that are only based on graphic bindings for that
   environment -> do not mix GTK with QT apps, for example
   - one text editor
   - one web browser
   - one music and movie player
   - one graphical editor (vector, bitmap)
   - one office suite
   - etc ...

Curating the applications and keeping their count low would:

   - reduce the ISO size
   - reduce the download time
   - reduce the installation time
   - reduce the time needed for testing
   - enable test the small amount of applications far better and more
   thoroughly

This would help with basically everything.

PS: KDE, especially, is very generous about unnecessary applications. Why
do I need three web browsers installed? Why do I need two terminal
emulators?
Why do I need the three games and why do I need games at all?

-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
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 32 system-wide change proposal: reduce installation media size by improving the compression ratio of SquashFS filesystem

[Lukas Ruzicka]

>
> Why stacked images? Consider a single base.img that's maybe 1G, and
> now you don't have to do separate composes for server, cloud, GNOME,
> KDE, Cinnamon, LXQt, Astronomy that repeat a lot of the same steps,
> including expensive steps like compressing the same things over and
> over again. Just do a 'dnf group install' tacked onto that base.img,
> the work being done is custom for that output, rather than repetitive.
> Not complicated. It would be fast enough that the high level variants
> could be composed on demand. Seconds. It'd be fast enough to queue it
> for download within the hour.
>

Well, I would like that.
+1



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


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
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: Modularity and the system-upgrade path

[Lukas Ruzicka]

Either the strategy should be:
>
> "We offer alternate Perl versions for containers etc. they conflict with
> the
> default Perl version and with the non-modular apps. That is known and
> accepted."
>
> Or the strategy should be:
>
> "We build all our Perl applications for all our Perl versions, so users
> who
> choose their Perl stream can still keep their applications from the
> distribution."
>
>
Exactly. While I am thinking that the *first strategy is easily achievable*,
even with what we already have,
the *second strategy is very complicated* to achieve, because we cannot
predict what applications
users want to install and in which versions. They all would have to work in
Fedora, otherwise the distro
does not make sense any more. Let me explain.

If I know that installing an alternative version of Perl could break Perl
bindings to other applications, I can
create a container to use that alternative version of Perl and be happy,
having actually the standard Perl in the
system and another version in the container, or I just install a system
with that, because I only need
to have one purpose operating system, such as LAMP or other servers. That's
fine.

For desktop users, however, this is not good because you place limitations
on them. While I believe it is fairly ok
to build a server solution around containers (or even virtual machines),
this is overly complicated for Desktop.
I do not understand why we would like to make Desktop complicated, when the
majority of Red Hat use Fedora as
their desktop solution. Also, there are spins that basically are
Workstations (or other desktops) that have certain
packages pre-installed and we expect them to work flawlessly.

The questions is: *With modularity ... can we make sure that everything
works with everything as it does nowadays?*

I believe that having non-modular defaults will make sure the distro works
in its entirety, while having alternative versions
in modules will help developers and sysadmins to install what they want and
need, if it is not the default. For me, this is a win win situation.
I understand that it is more work for the packager, but it is more
convenient for the users and we should think about the users
in the first place.

I have been following this discussion since it started and all I am getting
is "We are having issues, but we are working on them.",
but nobody has ever explained why it is bad to use Miro's approach.



-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
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: Modularity: The Official Complaint Thread

[Lukas Ruzicka]

Again, no one forces you or any other packager to use modularity
> tooling right now.
>
> As Fedora developer you have a choice to join the effort, bring your
> input and use cases, try and test (and revert if it doesn't work) or
> you can stay away from it and keep using same tools as before.
>

Well, noone forces you *right now. *That is an important thing to notice.
Someone will force you to use it later.
And, by the way, some people were forced to use it, because they installed
an application whose dependencies were
modularized, so they were force onto modularity without wishing for it.

I, personally, do not have anything against modularity except that *it is
forced upon us. *
My preference is that anybody could choose whether they want to go modular
or stay ursine -
do I really want that much, when I want that Fedora is for everybody?


FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
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: Modularity and all the things

[Lukas Ruzicka]

*There's a very large difference between feedback like "I think the user
experience is suboptimal here, for this reason" and "I don't like the
entire design, you should scrap it and start over".*

Well, I can agree with that.


>
> In the first case, it's possible to incorporate that into an existing
> project if the benefits justify the investment. In the latter case, it
> requires a *substantial* reinvestment in work while simultaneously
> demoralizing and disrespecting the people who have been working on it. It's
> a fundamental difference between constructive and destructive criticism.
>
> By all means, if there are user experience problems, highlight those.
>

I was already trying to point things out from my perspective while testing
modularity in Fedora:

   1. You cannot choose if you want to be modular, you just become modular
   when installing applications that depend on modules. At this status quo,
   this behaviour is hard to accept.
   2. Broken upgrades for users with libgit2 - instead of a proper solution
   we have implemented a hack to reset the libgit2 module and thus enable to
   upgrade. If users knew about this (because they would have opted-in), they
   would be able to reset libgit2 for themselves and we would not need to hack
   it.
   3. I do not understand why we want to hide modularity from users by
   shipping default modules to make users not notice we are modular. What is
   wrong about non-modular defaults and modular streams for various use cases?
   Nobody has ever explained why having everything modular is so much better.
   4. Why absence of modular repos will break the system? Why cannot users
   choose what they need best?
   5. Some modules are not correctly formed according to criteria, we have
   agreed upon. Bugs were opened.
   6. Some streams are not correctly formed. Bugs were opened.
   7. Some modules still do not have a yaml file in the
   fedora-module-defaults, you especially told me they must have it.
   8. Naming conventions are not good, streams are named ad hoc.
   9. Some modules cannot be installed on Fedora 31 due broken
   dependencies. Bugs opened.
   10. Yet, many bugs I open against particular modules remain unresolved.
   11. Even the testmodule, which should be there for people to look at how
   to do it, is broken.

And this all will be shipped with Fedora 31, because we block on DNF
behaviour but not on modular sanity.


> Just don't draw the conclusion that the whole system is unsalvageable. Let
> the team that's working on it figure out if there's a way to fix the UX or
> if it truly does mean that a structural flaw exists in the design. The
> Modularity Team is reading these threads and is keeping notes on all of the
> legitimate issues raised. As of right now, we don't feel that the situation
> is unrecoverable.
>
>
I did not say anything like that.

Please keep your suggestions constructive. Tell us where we are falling
short. We are listening. We're just not ready to throw away years of work
because it isn't perfect yet. If we did that every time, we'd never get
anywhere. We wouldn't have taken projects like systemd, KDE 4,
NetworkManager, and GNOME 3 from their rocky starts to where they are now.
All of those examples were hard-fought changes that brought considerable
instability to Fedora when they initially landed and now are cornerstones
of the Fedora story.

Do you point this to me or is it a general statement? I will go with the
second here, because I have never said that anybody should throw their
entire work away. I have only been consistently suggesting to have
modularity opt-in *until the problems are fully solved*.

Right now, they are not fully solved and we still force modularity upon our
users. I do not think this is correct from the QE perspective.

I cannot help you to code, since I am not as good,  and I have never
commented on how you decide to make things work.
I am pointing to things that do not work, and I will be doing it again and
again, because I believe it is part of my job to make sure the users get
what they deserve.



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


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
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 Gu

Re: Modularity and all the things

[Lukas Ruzicka]

On Thu, Oct 24, 2019 at 10:40 AM Igor Gnatenko <
ignatenkobr...@fedoraproject.org> wrote:

>
> This basically makes modularity not useful for many things:
>
> 1. People will have to have different workflows between "default"
> version (standard workflow, as we have today) and "modular" version.
>

I do not think so. If modularity was an opt-in, then people could consume
the default non-modular
content and only switch to modules when they wanted to solve a specific
problem. Those specific
problems were in the beginning to be slower or be faster than the normal
Fedora would be.

 Also that means, on the distribution upgrade maintainers will have to

> do many things to remove modular stream, add old one and upgrade
> non-modular version.


The packagers would probably maintain one non-modular version for each
Fedora release
and other versions in modules, if they liked to.



> This is also not only about maintainers, but end
> users too:
>
> FXX: fish 3.x is non-modular, stream 4.x exists
> FXX+1: fish 4.x is non-modular, stream 3.x exists
>

This is not what I'd expect. I would rather like:

FXX: fish 3 is non-modular, streams 3, 4 exist as modules
FXX+1: fish 4 is non-modular, streams 3, 4 exist as modules.

>From the users' perspective, if I did not care about the fish version and I
only wanted fish, they would do *dnf install fish *which
will result in non-modular content. If someone wanted a specific version of
the fish, they might do
*dnf module install fish:3 *
which would result in a modular fish, of the same version, but this version
would stay on the system as long as the user would switch
manually.

If fish:3 became EOL, DNF would say something like: *The fish:3 stream does
not have a follower in the new Fedora release,*
*what to you want to do:*
*a) switch to a non-modular default (version 4)*
*b) switch to a different modular stream (fish:4)*
*c) switch to a different modular stream (fish:5)*


* Nobody can guarantee that those will be compatible
>

Very true. So we should probably be very much aware of this, because if we
cannot maintain compatibility between single
modular streams, how do we maintain compatibility across all the modules,
default or non-default, in a typical desktop
environment of Fedora?
Or wait, is modularity still the food for containers as advocated in the
beginning? Then we do not have to worry about compatibility
too much, because once you want to switch to a different stream, just
create a new container.


> 2. In Rust we use modularity to build bunch of packages, filter
> buildroot-only packages and ship only one user-facing RPM. If we
> remove default stream, people won't be ever able to do `dnf install
> ripgrep'. This is worst UX we can provide.
>

If DNF said, in this case, something like
*The package you are trying to install is only available as a module, *
*please use dnf module install ripgrep to install it. -> *I do not see that
as the worst UX at all. On the contrary, this
is a clear message to the user that he should either go modular (with
everything it brings) or forget about that package.
The choice remains in their hands.


The problem is that we don't have
> well-defined *user* experience.
>

Agreed 100%.



> After last few years with modularity, I don't think it is improving
> but it definitely causes some problems.
>

> P

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


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
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: Modularity and all the things

[Lukas Ruzicka]

Are you proposing to _do_ those things, or proposing that someone else
> oughta?
>

This is an unfair statement!

I thought Fedora is a community of people. In the community, we have
programmers, visionaries, idealists, testers, graphics ... and we also have
users, that only know
if they like or dislike something, if the want or don'ŧ want to use the
product somehow. Not everybody
is a good programmer or a software designer, so they cannot go and make it
betterby themselves,
but they can still give valid ideas. And it may be good to hear their
voice, because they may have
good ideas, too.

It is easy to fall in love with someone or something no matter what others
tell me, and
not see any problems and flaws because love can fool us quite well.

In the end . love hurts.



>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> 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
>


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
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: Modularity and the system-upgrade path

[Lukas Ruzicka]

This is a policy choice, not a technical matter. If modules became more
> popular, and the dependencies between modules grew, we'd need
> to settle on similar rules, where bigger changes are done with a certain
> cadence. This is why I think that the "independent lifecycles for modules"
> are illusory, made possible by current scarcity of modules.
>

Currently (F31), there are about 63 modules listed with *dnf module list*.
I have attempted to install all modules and all streams. Between single
installations
I always reverted the system to its default state, i.e. modular repos
enabled, but no
modules installed, enabled, disabled or anything.

>From those 63 modules,

   - about 18 are not correctly defined according to criteria that I had
   agreed on with Stephen, https://pagure.io/modularity/issue/149.
   - about 8 modules cannot be installed because of some dependency
   problems: #1764546, #1764616, #1764623, #1764624, #1764606, #1764606,
   #1764611, #1764604

In some of the cases, packagers themselves report that the particular
module should NOT be included
in that particular version of Fedora, currently 31, but they still ARE.

So, not just the tooling, the content is problematic as well, it is not
ready and nobody seems to care, as there
are bugs reported that have not been resolved for several weeks. And since
we do not currently block on modular sanity,
we cannot enforce anything.

As far as tooling is concerned, I have been seeing complaints about DNF
doing a bad job, but from the perspective of acceptance
testing, it's the DNF operations that usually work fine with installing,
enabling, disabling, removing, resetting and switching modules and streams.

I believe, that if modularity was opt-in, we would be able to use it just
fine, as it is designed now with some little tweakings, such as DNF
providing enough info on retired or discontinued streams, offering a
possibility to choose a different stream to switch to on upgrades. The
longing for default modular Fedora is what makes it more problematic,
because we need to hide everything from the users and make everything work
automatically. If modularity was a matter of personal choice we would not
have to hide anything from anybody, because those users would be able to
read the necessary documentation and tweak their systems just fine.

---

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
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: Modularity and the system-upgrade path

[Lukas Ruzicka]

>
>
>
> This has been working quite fine so far, so it would be bad to loose this
> capability, as the actual
> users in question are definitely not power users and will not be able to
> fix any of these issues
> by themselves.
>
>
+1, this was one of my points, too. I think that Fedora should be open for
users of all categories, not just
power users, but also newbies and similar species.



-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
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 32 System-Wide Change proposal: Modules in Non-Modular Buildroot

[Lukas Ruzicka]

3) We need to get the policy I described above written onto -stone
> tablets- the Packaging Guidelines and then we need to go and make any
> stream that isn't compliant with it a non-default stream.
>

Thank you. If we want to use default streams, then we indeed need a strict
policy on how they are formed and we need to make sure, the
requirements are met here. I dare to say, that we should block on every
default stream that would not meet the requirements.

-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
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: Modularity and the system-upgrade path

[Lukas Ruzicka]

This does not work for server components and is not generalizable. For
> example, you cannot have multiple versions of Samba running on the same
> system. You cannot have multiple versions of FreeIPA running on the same
> system either. These server components have requirements beyond package
> installability.
>
> We have an answer for those use cases with VMs and containers and they
> aren't requiring parallel installability.
>
>
I am glad that this works for you.


I have been using Linux for 17 years as my only operating system since I
deleted the windows partitions from my desktop in
2002. I started with Mandrake, moving over Gentoo, to Archlinux and now
Fedora. And I am really proud that I can serve the
Fedora community.

In return, I would love to use Fedora as my primary (and my only) operating
system, because you use what you love and
what you love you want to make better. But if I cannot use it to run my
graphical, musical, and typesetting software nicely from
one single machine, I will not be able to use it primarily. Does it mean,
that I will have to keep at least two PCs, one for testing Fedora,
and another one for having fun? Most bugs I have noticed where coming from
using Fedora daily, not from looking into test environments.

I understand, that server people need stuff, but we, the desktop people,
need stuff, too. Let's try to make everyone happy. I know, we
can do it, if we want to.
But yeah, I fear the day, when I will have to put several containers
together to stitch myself a modern solution that any Linux distro provided
20 years ago.

I hope those days won't come.








> --
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland
> ___
> 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
>


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
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: Modularity and the system-upgrade path

[Lukas Ruzicka]

Or, even better (or worse): Sombody installs GIMP via GNOME Software,
> and under the hood, dnf does its magic and installs gimp from the
> module, which might depend on another, even non-default module, etc.
> But then, what will happen when that module is EOL, and the user has
> never even interacted with dnf, or modules? Will system upgrades break
> and prompt the user to fix something they didn't even know existed,
> and have never interacted with?
>

This has already happened. We have had complaints from people who had never
installed any module, or used the "dnf module" command and they still ended
up with
modules installed with a problem to upgrade their computers to F31.




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


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
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: Modularity and the system-upgrade path

[Lukas Ruzicka]

>
>
> I'm comfortable saying that most Fedora users are not installing the
> distro
> just to support one specific application, as one might with RHEL or
> CentOS,
> but to benefit from the Four Foundations of Fedora, in this case the most
> important ones being Freedom, Features and First.
>

Exactly ... this is what I believe, too. I think that Fedora users put
Fedora on their
desktops and laptops to be creative in many ways of creativity. Some make
make music,
some enhance pictures, some model in Blender, cut videos, write documents.
The majority, I dare to say, is not interested in having several Inkscape
versions, they
want the newest yet stable enough and they are satisfied with that.


> It'd be great to have a working modular system, but since we don't seem to
> have that, it's not a good idea to force the broken implementation on
> users.
> We need to consider what is best for Fedora's users, not what is best for
> Red
> Hat, at least in my opinion.
>

Fedora modules must be ready to work in all possible combinations and
streams, if we really
mean it seriously. For example, I as a user, want to install the newest
version of Gimp, because I
need the newest features, but since the newest Scanner Application stopped
supporting my device,
I need the penultimate one. I also play windows games with wine and I set
the current version of
wine to suit my needs, so I want to stick with this version as long as
possible and maybe even beyond,
and I also want an NFS share for my TV to consume, but because I am
paranoid, I want to go 2 versions behind
the latest.

To make a long story short, I will need lots of different stream working in
harmony and I will want
to upgrade my PC without any problems.
Until we can provide this, we should keep modularity as opt-in technology
preview.



>
> I see no reason that dropping certain parts of Modularity from actual
> releases
> of Fedora will harm the relationship with Red Hat, as Stephen suggests.
> Such
> tests can, and probably should, be done in Rawhide, until they're actually
> ready for users.
>
> So far, the best approach seems to be to remove default modules, and
> require a
> non-modular version for fedora releases and branched. (In addition to
> whatever
> packagers would package as modules. To clarify, I am not attempting to
> suggest
> nothing should be done with Modularity except in Rawhide.)
>

This seems to me the easiest way to solve current problems.



>
> We're not saying this to discourage you, at least that is not my goal. My
> goal
> is to ensure the best result for the end user.
>
> --
> John M. Harris, Jr.
> Splentity
>
> ___
> 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
>


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
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: Modularity and the system-upgrade path

[Lukas Ruzicka]

Thank you for clarifications.

It's somewhat disheartening to hear responses that largely boil down to "If
> you can't get it perfectly right, stop trying!".
>

I am sorry if this is what you feel about my comments. I never wanted to
say that you should stop trying if you cannot get it perfectly right. I
agree that trying (and perhaps failing or winning) is the motor to
development and evolution. What I wanted to say was "Until we can't get it
perfectly right, let's not make it a default." Do you think this a stupid
approach from a QE's perspective?

You have said a couple of times, that users should not switch off modular
repos, because they could break their system. What if, until we know it's
perfectly safe, users would not break their system with modular repos off?
In that case, we could have a modularity opt-in for the time's being, and
we could buy us time to test default streams and whatever you need to test.




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


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
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: Modularity and the system-upgrade path

[Lukas Ruzicka]

I don't think containers can replace modularity. They need to coexist.
> If we want to create containers built on top of a distribution (no
> randomly picked bits from the internet, reproducible builds, security,
> ...), we need a way to distribute multiple versions of the software
> (module streams) and they frequently need to be built against each other
>   (module contexts).
>
>
Once I was told, that the purpose of modularity is to enable people to
create containers with
any software version they long for.

This totally has made sense to me, because containers usually only serve a
specific purpose, so
it is easier to pick up correct software versions and limit their
combinations, for example for a LAMP container
or something like that, and it is not so crucial that some other
application might not be fully compatible with that,
because I could create another container with the other application.

System-wide? That is another story, because here we need 100% compatibility
for everything, because we
never can think of combinations of applications and use cases, that
Workstation users long for.

With modularity, we could make Fedora a great distro for developers. But I
would like to see Fedora being the
distro for everyone, and not just developers. Therefore, we need to be as
versatile as possible.
I also have a slogan:

WHATEVER YOU HAVE EXPECTED FROM AN OS ... YOU FIND IT WITH FEDORA.

Let's do it perfect.




>
> >
> > Simo.
> >
> > On Fri, 2019-10-04 at 10:57 -0400, Stephen Gallagher wrote:
> >> Right now, there are two conflicting requirements in Fedora Modularity
> >> that we need to resolve.
> >>
> >> 1. Once a user has selected a stream, updates should follow that
> >> stream and not introduce incompatiblities. Selected streams should not
> >> be changed without direct action from the user.
> >> 2. So far as possible, Modularity should be invisible to those who
> >> don't specifically need it. This means being able to set default
> >> streams so that `yum install package` works for module-provided
> >> content.
> >>
> >> Where this becomes an issue is at system-upgrade time (moving from
> >> Fedora 30->31 or continuously tracking Rawhide). Because of
> >> requirement 1, we cannot automatically move users between streams, but
> >> in the case of release upgrades we often want to move to a new default
> >> for the distribution.
> >>
> >>
> >> The Modularity WG has generally agreed that we want and need to
> >> support behavior of the following use-cases:
> >>
> >>
> >> Use Case 1:
> >>
> >> On Fedora 30, user Alice runs
> >>
> >> yum install Foo
> >>
> >> The package "Foo" is provided by a module "foo" with a default stream
> >> "v1.0". Because it's available in a default stream, the package is
> >> installed and the module stream "foo:v1.0" is implicitly enabled for
> >> the system.
> >>
> >>
> >>
> >> Fedora 31 is released. On Fedora 31, the module "foo" has a new
> >> default stream "v1.1". When upgrading from Fedora 30 to Fedora 31,
> >> Alice expects the package Foo she installed to be upgraded to version
> >> 1.1, because that's what would have happened if it was provided as a
> >> package from the non-modular repositories.
> >>
> >>
> >>
> >> Use Case 2:
> >>
> >> On Fedora 30, user Bob runs
> >>
> >> yum enable foo:v1.0
> >>
> >> In this case, the "v1.0" stream of the "foo" module has a dependency
> >> on the "v2.4" stream of the "bar" module. So when enabling "foo:v1.0",
> >> the system also implicitly enables "bar:v2.4".
> >>
> >>
> >>
> >> Fedora 31 is released. On Fedora 31, the module stream "foo:v1.0" now
> >> depends on "bar:v2.5" instead of "bar:v2.4". The user, caring only
> >> about "foo:v1.0" would expect the upgrade to complete, adjusting the
> >> dependencies as needed.
> >>
> >>
> >> At Flock and other discussions, we've generally come up with a
> >> solution, but it's not yet recorded anywhere. I'm sending it out for
> >> wider input, but this is more or less the solution we intend to run
> >> with, barring someone finding a severe flaw.
> >>
> >> Proposed Solution:
> >>
> >> What happens today is that once the stream is set, it is fixed and
> >> unchangeable except by user decision. Through discussions with UX
> >> folks, we've more or less come to the decision that the correct
> >> behavior is as follows:
> >>
> >> * The user's "intention" should be recorded at the time of module
> >> enablement. Currently, module streams can exist in four states:
> >> "available, enabled, disabled, default". We propose that there should
> >> be two additional states (names TBD) representing implicit enablement.
> >> The state "enabled" would be reserved for any stream that at some
> >> point was enabled by name. For example, a user who runs `yum install
> >> freeipa:DL1` is making a conscious choice to install the DL1 stream of
> >> freeipa. A user who runs `yum install freeipa-client` is instead
> >> saying "give me whatever freeipa-client is the default".
> >>
> >> * The state `dep_enabled

Re: Modularity and the system-upgrade path

[Lukas Ruzicka]

> So despite providing zero feedback here, this was voted at the modularity
> meeting:
>
> * Tagging Module Defaults into non-modular repo  (sgallagh, 15:41:37)
>* AGREED: We disagree with merging default streams into the main repo
>  as non-modular packages. Our approach is to implement a mechanism of
>  following default streams to give people the experience they want.
>  (+4 0 -0)  (asamalik, 16:07:40)
>

Well,
based on this discussion, pushing content in modular defaults is not the
experience that people want. I have been a bit ill
for some time and before I could add my point to the discussion, everything
has been more or less said.
Just for illustration, this is what I wanted to say about it:

   1. Modularity should stay away from my system until I call for it -> now
   it is not the case, because modularity sneaks into users' computer through
   modular defaults that overcome the non-modular packages. Gimp is the first
   such "horse" that jumps into almost everybody's desktop and they are
   modular without even knowing it.
   2. Modularity should provide alternative content, if I need it and when
   I need it. Modules should be installable only through "dnf module" command
   and not through the regular dnf command, so that I explicitely need to
   allow modularity on my system.
   3. The naming conventions of the streams should be *obligatory* for
   every module packager. So, if we decide that we want a "latest" stream,
   then all modules should have a "latest" stream for rolling updates.
   Currently, they all have various names of streams, from which I cannot tell
   anything. If there should be a "slow" path, then again, all modules should
   have a "slow" path.
   4. Non-modular Fedora must be a valid use case and remain an option.
   5. If I decide to go modular, there must be a way to go non-modular
   again, without breaking the system. Or, if modular is the only option, so
   if I go into specific streams, there must be a way to go to defaults
   without breaking the system. With non-modular defaults, this seems easy.
   With modules? I am not sure.
   6. We need to expect that once there are hundreds of modules, people
   will install all possible combinations and they all will need to work. I am
   not sure, we will be able to test something like that.

Seeing the reaction of the Modularity WG ... I do not understand how it is
possible that such important decisions are taken by 4 people without any
Fedora wide discussions like this. And yet, it seems a little bit that even
opinions on this list will not fall on fertile grounds.

I wish the communication improved in the first place. Community means
togetherness.



> should aim for solution 1. if solution 2. is not negotiable by the
> modularity WG.
>

+1




-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
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: Getting .fc32 packages while trying to follow F31 branch ?

[Lukas Ruzicka]

I totally agree with you.

-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
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: [Test-Announce] 2019-05-13 @ 15:00 UTC - Fedora QA Meeting

[Lukas Ruzicka]

The meeting took place in #fedora-meeting as usual.

Lukas

On Mon, May 13, 2019 at 6:01 PM Silvia Sánchez  wrote:

>
> Hello,
>
> In which channel?  I couldn't find the meeting.
>
> Regards,
> Silvia
> FAS:  Lailah
>
>
>
>
> On Mon, 13 May 2019 at 12:26, Geoffrey Marr  wrote:
>
>> Hey all,
>>
>> We didn't meet last week, and there are a few action items from the last
>> week, so let's meet to go over those. I'll put the action items from the
>> previous meeting at the end of this email. adamw is on vacation so we can
>> really only go over one of them, but let's meet to do that. It will also be
>> good to get a reminder and rundown of the upcoming test days.
>>
>> If you feel something has been missed and should be added to the agenda,
>> please respond to this email! See you soon.
>>
>> == Previous Meeting Action Items ==
>>
>> 1. lruzicka to follow up on "Modularity UX Questions" thread again asking
>> for more concrete results
>> 2. adamw to revise F30 Common Bugs for Final
>> 3. adamw to resurrect the 'late blocker waiver' proposal with a third
>> draft or re-send of the second draft
>>
>> == Proposed Agenda Topics ==
>>
>> 1. Previous meeting follow-up
>> 2. Upcoming test days
>> 3. Open floor
>>
>> Geoff Marr
>> IRC: coremodule
>> ___
>> 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://getfedora.org/code-of-conduct.html
>> 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://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>
> ___
> test mailing list -- t...@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org
>


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Modularity UX Questions

[Lukas Ruzicka]

Hello,
please could you tell me if any decisions have been made on how this thread
is going to be handled? Is it defined somewhere, where I could read, what
the behaviour will be like?

Thanks.

On Tue, Apr 2, 2019 at 3:19 PM Adam Samalik  wrote:

>
>
> On Tue, Apr 2, 2019 at 2:50 PM Stephen Gallagher 
> wrote:
>
>> On Tue, Apr 2, 2019 at 3:36 AM Adam Samalik  wrote:
>>
>> > When a packager doesn't provide the YAML defaults file at all, I'd
>> assume it could have been unintentional and notified them about that fact.
>> However, I wouldn't prevent the module to get to the compose or anything —
>> just let them know so they can decide.
>> >
>> > How DNF should behave? Considering there is no default stream nor
>> default profile, I'd suggest the following command to fail with an
>> appropriate error message:
>> >
>> > $ dnf module install modulename:stream
>> >
>> > I'd strongly encourage DNF to suggest how to move forward, notifying
>> the user there is no default profile defined for this module and that they
>> either need to specify one in the install command:
>> >
>> > $ dnf module install modulename:stream/profile
>> >
>> > ... or to enable the module in order to consume the packages directly
>> by the following command:
>> >
>> > $ dnf module enable modulename:stream
>> > $ dnf install packagename
>> >
>> > As Modularity is a new technology, I personally wouldn't be afraid of
>> longer error messages — within reason of course — giving the user guidance.
>> >
>>
>> Yeah, I think if no default object exists in the metadata, `dnf module
>> install modulename:stream` should probably not install anything and
>> instead prompt them to select a profile explicitly (ideally listing
>> the available options or suggesting `dnf enable modulename:stream`).
>>
>> >>
>> >>
>> >>
>> >> === A module has explicitly set one or more of its streams to have no
>> >> default profiles ===
>> >>
>> >> This is a similar case to the above, except that a conscious choice
>> >> was made by the module maintainer to say that this module has no
>> >> reasonable default packages that could be selected. (For example, it
>> >> could be a collection of popular libraries that extend a particular
>> >> programming language, but there’s no obvious subset of them that makes
>> >> sense to install. It may exist and have streams solely because it
>> >> needs to be kept in sync with the interpreter version.)
>> >>
>> >> The open question is the same as the previous one: how should dnf
>> >> module install handle this case? In this particular example, it might
>> >> be more acceptable that it follows the enable fallback, since the
>> >> maintainer selected the lack of a profile explicitly. However, having
>> >> context-sensitive differences can be difficult for people to process.
>> >
>> >
>> > I assume the difference here is that the packager has provided the YAML
>> defaults file, but haven't specified a default profile as opposed to not
>> providing that file at all?
>> >
>>
>> No, this is "the packager has provided a YAML defaults file like:
>>
>> ```
>> document: modulemd-defaults
>> version: 1
>> data:
>> modified: 20190402
>> module: somemodule
>> stream: 1.0
>> profiles:
>> 1.0: [ ]
>> ```
>>
>> See that the '1.0' stream is listed as having an empty set of default
>> profiles. Thus, a conscious decision has been made that no default
>> makes sense for this stream. What do we do here?
>>
>> I'm leaning towards treating it like the above. DNF should provide a
>> helpful error suggesting available profiles or `dnf enable
>> module:stream`
>>
>
> Ah, got it!
>
> Still strongly prefer consistent behaviour of this and the above — failing
> and giving the user a guidance.
>
>
>>
>>
>> > If that's true, I would strongly prefer consistency and fail on an
>> install command without having a stream specified, and give the user
>> guidance in an error message as above.
>> >
>> >>
>> >>
>> >>
>> >> === A module has a profile that contains zero RPMs ===
>> >>
>> >> In this case, a profile definition has been made in the module
>> >> metadata and it explicitly contains zero RPMs within it. Such an
>> >> example might be for compatibility: the module previously provided a
>> >> profile with that name that contained content, but it is no longer
>> >> doing so. Retaining the name may have been done to allow existing
>> >> scripts to avoid breaking. If we have a profile that contains zero
>> >> packages, should it be an error if we attempt to install it? If not,
>> >> what should the UX look like?
>> >
>> >
>> > This seams as a strange, yet possible choice for the packager to make.
>> >
>> > I do not have a strong opinion on this one. I'd probably suggest to not
>> be too clever and let them have that choice, and make the install command
>> work without installing any RPMs, and possibly emit a warning to the user
>> about the fact.
>>
>> Yeah, I'm leaning towards making a zero-package profile be a
>> validation error in libmodu

Re: Basic graphics mode / 'nomodeset' testing request, round 2

[Lukas Ruzicka]

I have a no boot, too. Reported in the Bugzilla.
L.

On Wed, Apr 10, 2019 at 6:41 PM Geoffrey Marr  wrote:

> Have tried two machines so far, a MacBook
>
> 02:00.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960
> Integrated Graphics Controller (primary) (rev 03)
>
> and a Dell Precision M4600 with:
>
> 01:00.0 VGA compatible controller: NVIDIA Corporation GF106GLM [Quadro
> 2000M] (rev a1)
>
> The MacBook has strange keybindings between the Command/Ctrl/Alt/Function
> keys and I can't for the life of me figure out how to register a
> "Ctrl-Alt-F3", so I can't say for sure if the error is in the log, but it's
> definitely not booting. The Dell however is showing the same error, the
> "(EE) Cannot run in framebuffer mode. Please specify busIDs for all
> framebuffer devices" and likewise not booting any further. I did a search
> through the logs for what Kamil is seeing in the second message, but none
> of those lines were found, only the original error. If I can get this
> MacBook into a terminal, I'll post what it says too.
>
> Geoff Marr
> IRC: coremodule
>
>
> On Wed, Apr 10, 2019 at 9:28 AM Kamil Paral  wrote:
>
>> On Wed, Apr 10, 2019 at 3:21 PM Kamil Paral  wrote:
>>
>>> Then I tried with Thinkpad T450s. I had to boot in UEFI with CSM on,
>>> because CSM off or even SecureBoot on make the image unbootable (I'll
>>> report a separate bug about that).
>>>
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1698550
>>
>> ___
>> test mailing list -- t...@lists.fedoraproject.org
>> To unsubscribe send an email to test-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org
>>
> ___
> test mailing list -- t...@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org
>


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Modularity UX Questions

[Lukas Ruzicka]

=== A module does not have one or more of its profiles specified to be
> the default. ===
>
>
Here, I would expect that DNF will finish with error, advising the user to
select a profile specifically, such as using "dnf module install
:/".

 === A module has explicitly set one or more of its streams to have no

> default profiles ===
>
>  Here, I could imagine that such a module would be marked "special".
Marking a module "special" would clearly tell QA that special behaviour is
intented (empty profile or something similar). The DNF either should not
list them in "dnf module list" or if listed they should have a visible
distinction (such as "s") or something like that. We could utilize the
difference between "dnf module list" and "dnf module list --all", that
currently do the same job, so that "dnf module list" would only show
installable modules, while "dnf module list --all" would list all modules,
as the option suggests.
If someone attempted to install a special module, DNF should not proceed
anyhow and warn about that.


> === A module has a profile that contains zero RPMs ===
>
>
See above. This should be a typical example of a "special" module.




> In this case, a profile definition has been made in the module
> metadata and it explicitly contains zero RPMs within it. Such an
> example might be for compatibility: the module previously provided a
> profile with that name that contained content, but it is no longer
> doing so. Retaining the name may have been done to allow existing
> scripts to avoid breaking. If we have a profile that contains zero
> packages, should it be an error if we attempt to install it? If not,
> what should the UX look like?
>
>
> [1]
> https://communityblog.fedoraproject.org/modularity-hackfest-march-2019/
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Broken modules on rawhide

[Lukas Ruzicka]

Why people disable the repo, I do not know. I might have a slight notion.

However, you cannot upgrade from Fedora 29 to Fedora 30 with Modular
repositories allowed. It fails with an error similar to what Mirek has
reported. Disabling modular repositories fixed the problem and an upgrade
was possible, but I see this as quite a serious issue and if it is not
fixed, I will definitely report this as a blocker.

I do not know, where the problem lies, whether the modules have not been
built yet or something, but I would definitely expect that in time of
Branching, things like that would have been solved. Otherwise, people will
not want to get into problems like this and they might think twice about
modular content.



On Wed, Feb 27, 2019 at 11:37 AM Miro Hrončok  wrote:

> On 27. 02. 19 11:09, Igor Gnatenko wrote:
> > I think those messages are just informational, because nothing uses
> those
> > modules to build packages..  or am I wrong?
>
> It aborts the build.
>
> ---
>
> Modular dependency problems with Defaults:
>
>   Problem 1: conflicting requests
>- nothing provides module(platform:f30) needed by module
> avocado:stable:3020190213205848:a5b0195c-0.x86_64
>   Problem 2: conflicting requests
>- nothing provides module(platform:f30) needed by module
> bat:latest:3020190214090936:e50d0d19-0.x86_64
> ...
>   Problem 12: conflicting requests
>- nothing provides module(platform:f30) needed by module
> stratis:1:20181215204600:a5b0195c-0.x86_64
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>File "/usr/bin/dnf", line 58, in 
>  main.user_main(sys.argv[1:], exit_code=True)
>File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 193, in
> user_main
>  errcode = main(args)
>File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 64, in
> main
>  return _main(base, args, cli_class, option_parser_class)
>File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 99, in
> _main
>  return cli_run(cli, base)
>File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 115, in
> cli_run
>  cli.run()
>File "/usr/lib/python3.7/site-packages/dnf/cli/cli.py", line 1108, in
> run
>  return self.command.run()
>File "/usr/lib/python3.7/site-packages/dnf/cli/commands/install.py",
> line 97,
> in run
>  module_debsolv_errors))
>File "/usr/lib/python3.7/site-packages/dnf/module/module_base.py", line
> 604,
> in format_modular_solver_errors
>  msg = dnf.util._format_resolve_problems(errors)
>File "/usr/lib/python3.7/site-packages/dnf/util.py", line 384, in
> _format_resolve_problems
>  msg += "\n  - ".join(rs)
> TypeError: sequence item 0: expected str instance, list found
>
> Could not execute mockbuild: Failed to execute command.
>
> ---
>
> Is this a dnf bug?
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Disabled registration from a certain IP due to a limit.

[Lukas Ruzicka]

Sometimes, there does not have to be a reason. It is my beliefs. I rather
prefer a pure Fedora solution (be it a little bit tougher to use) then a
polished 3rd site solution.
I also have some of my projects on Github, but everything related to
Fedora, I host on Pagure. I feel honoured to be part of Fedora.
You do not have to explain to me why that is a good step. I do not see it
that way, I do not want to persuade anybody to stay at Pagure if they do
not feel it the way I do. What I want is to have my vote.

Lukas

Lukas

On Mon, Dec 17, 2018 at 3:25 PM Manas Mangaonkar 
wrote:

> GitHub operates independantly i don't see a reason for your worry.
>
> On Mon, Dec 17, 2018, 7:27 PM Lukas Ruzicka 
>> Hello,
>>
>> I would like to vote in this discussion, because I strongly disagree with
>> Fedora related stuff moving out from Pagure (that Fedora owns and controls)
>> to GitHub, which is proprietary (because controlled by Microsoft).
>>
>> The fact that I cannot log into the discussion nor create a new account
>> because the limit for my IP address has been reached. I want to say that I
>> do not have any account there and never created one, so I think this goes
>> to a Red Hat IP as a whole and not my personal address.
>>
>> Either way, this limits my right to vote in this matter. Please, could
>> someone responsible fix this problem?
>>
>> --
>>
>> Lukáš Růžička
>>
>> FEDORA QE, RHCE
>>
>> Red Hat
>>
>> <https://www.redhat.com>
>>
>> Purkyňova 115
>>
>> 612 45 Brno - Královo Pole
>>
>> lruzi...@redhat.com
>> TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <https://redhat.com/trusted>
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> 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: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat

<https://www.redhat.com>

Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <https://redhat.com/trusted>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Disabled registration from a certain IP due to a limit.

[Lukas Ruzicka]

Hello,

I would like to vote in this discussion, because I strongly disagree with
Fedora related stuff moving out from Pagure (that Fedora owns and controls)
to GitHub, which is proprietary (because controlled by Microsoft).

The fact that I cannot log into the discussion nor create a new account
because the limit for my IP address has been reached. I want to say that I
do not have any account there and never created one, so I think this goes
to a Red Hat IP as a whole and not my personal address.

Either way, this limits my right to vote in this matter. Please, could
someone responsible fix this problem?

-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: What does delaying F31 mean for packagers/users?

[Lukas Ruzicka]

Sorry about the two lines of the letter that do not fit much into the
concept:

So, I like the idea of one major and one minor release, if we want to stay
conservative and do not want to go the rolling updates way. And, in case we
want to stay super conservative and we do not want change anything, I think
Debarshi's approach would work just fine.

Thanks for understanding,
Lukas

On Wed, Nov 28, 2018 at 10:20 AM Lukas Ruzicka  wrote:

> Hello,
> I do not think that we should be taking the path towards Gnome being in
> one module. This is not, what "modular" means. In my understanding, modules
> should be smaller, rather independent units, that will help solve some user
> cases, but definitely not upgrading half of the system.
> Also, if we should provide updated ISOs, as one of the ideas was, why not
> do a normal release instead? It does not have to be packed with all new
> stuff, fixes and minor updates could be just fine ... and the new Gnome.
> I think there are several strategies, where we could go next, for example:
>
>
>- Release regularly to get the new Gnome, but do not push for so many
>new features in Fedora 31, if we need more time to fix things.
>- Adopt the Major / Minor approach and make the autumn release a minor
>one, so that Fedora 31 becomes a minor release.
>- Adopt the "rolling updates" strategy for Fedora and introduce a
>Fedora LTS that would be here for people who do not want rolling updates.
>- Just skip the release with all the consequences it will have ... no
>updates to new versions
>
> Let us not make Fedora messy by creating huge modules with dependencies in
> the whole system. It is too risky to go that way, because modularity is
> just at its beginning and has issues we must solve first. For example, what
> happens if you have a module stream installed and all the dependencies in a
> working system and you want to change from one stream to another? As far as
> I know, nobody guarantees at the moment, that the dependencies will not
> break. Can you image how putting Gnome into a module will affect the system
> when this is not solved?
>
> I'd rather see Fedora stay a bit older for a period of time than to see it
> breaking and leaving people angry.
>
> Take care,
> Lukas
>
>
>
>
> I quite like the idea of one major and one minor release in a year.
>
> I think that Debarshi's approach would work nicely
>
> On Wed, Nov 28, 2018 at 9:34 AM Debarshi Ray  wrote:
>
>> On Tue, Nov 27, 2018 at 10:38:52AM -0500, Owen Taylor wrote:
>> > One of the key parts of making a decision to delay/skip F31 is
>> > figuring out, ahead of the decision, what the expected experience is
>> > for users and packagers. Does F30 have normal stability, or do we try
>> > to keep users happy by moving things forward with ad-hoc updates and
>> > cross-our-fingers and hope nothing breaks?
>> >
>> > I tend to think about this in terms of GNOME - would we rebase to
>> > GNOME 3.34 in the middle of F30 or not? But there's a lot of other
>> > pieces of software where similar considerations apply: container
>> > tools, cockpit, NetworkManager, etc.
>> >
>> > And if we did do updates like that, would we consider respinning media
>> > and making a "F30.1"?
>>
>> Umm... can't we treat it the same as the Fedora 20/21 situation?
>> Skipping a GNOME release can be a bit painful for the upstream GNOME
>> community, which is overwhelmingly tilted towards Fedora, but it's not
>> the end of the world either. After all, I don't think the longer
>> Fedora 21 cycle had any negative long-term effect on that group at
>> all. :)
>>
>> The Desktop Team could more aggressively backport bug-fixes to GNOME
>> 3.34 upstream, and if needed backport selected features to Fedora 30
>> downstream. We have done this during the usual six month Fedora
>> releases (eg., Thunderbolt support, free RHEL in Boxes, etc.), and we
>> have done this for RHEL too, so there's some precedence in this area.
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>
>
>
> --
>
> Lukáš Růžička
>
> FEDORA QE, RHCE
>
> Red Hat
>
> <https://www.redhat.com>
>
> Purkyňova 115
>
> 6

Re: What does delaying F31 mean for packagers/users?

[Lukas Ruzicka]

Hello,
I do not think that we should be taking the path towards Gnome being in one
module. This is not, what "modular" means. In my understanding, modules
should be smaller, rather independent units, that will help solve some user
cases, but definitely not upgrading half of the system.
Also, if we should provide updated ISOs, as one of the ideas was, why not
do a normal release instead? It does not have to be packed with all new
stuff, fixes and minor updates could be just fine ... and the new Gnome.
I think there are several strategies, where we could go next, for example:


   - Release regularly to get the new Gnome, but do not push for so many
   new features in Fedora 31, if we need more time to fix things.
   - Adopt the Major / Minor approach and make the autumn release a minor
   one, so that Fedora 31 becomes a minor release.
   - Adopt the "rolling updates" strategy for Fedora and introduce a Fedora
   LTS that would be here for people who do not want rolling updates.
   - Just skip the release with all the consequences it will have ... no
   updates to new versions

Let us not make Fedora messy by creating huge modules with dependencies in
the whole system. It is too risky to go that way, because modularity is
just at its beginning and has issues we must solve first. For example, what
happens if you have a module stream installed and all the dependencies in a
working system and you want to change from one stream to another? As far as
I know, nobody guarantees at the moment, that the dependencies will not
break. Can you image how putting Gnome into a module will affect the system
when this is not solved?

I'd rather see Fedora stay a bit older for a period of time than to see it
breaking and leaving people angry.

Take care,
Lukas




I quite like the idea of one major and one minor release in a year.

I think that Debarshi's approach would work nicely

On Wed, Nov 28, 2018 at 9:34 AM Debarshi Ray  wrote:

> On Tue, Nov 27, 2018 at 10:38:52AM -0500, Owen Taylor wrote:
> > One of the key parts of making a decision to delay/skip F31 is
> > figuring out, ahead of the decision, what the expected experience is
> > for users and packagers. Does F30 have normal stability, or do we try
> > to keep users happy by moving things forward with ad-hoc updates and
> > cross-our-fingers and hope nothing breaks?
> >
> > I tend to think about this in terms of GNOME - would we rebase to
> > GNOME 3.34 in the middle of F30 or not? But there's a lot of other
> > pieces of software where similar considerations apply: container
> > tools, cockpit, NetworkManager, etc.
> >
> > And if we did do updates like that, would we consider respinning media
> > and making a "F30.1"?
>
> Umm... can't we treat it the same as the Fedora 20/21 situation?
> Skipping a GNOME release can be a bit painful for the upstream GNOME
> community, which is overwhelmingly tilted towards Fedora, but it's not
> the end of the world either. After all, I don't think the longer
> Fedora 21 cycle had any negative long-term effect on that group at
> all. :)
>
> The Desktop Team could more aggressively backport bug-fixes to GNOME
> 3.34 upstream, and if needed backport selected features to Fedora 30
> downstream. We have done this during the usual six month Fedora
> releases (eg., Thunderbolt support, free RHEL in Boxes, etc.), and we
> have done this for RHEL too, so there's some precedence in this area.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org