from:"mcatanzaro"

Good job finding old links. Archeology is useful for discussions like 
this.


On Tue, Aug 27, 2019 at 5:59 AM, Christopher 
 wrote:

The current status is that the Workstation WG never came up with a
solution in 5 years


To be clear, the status quo is our solution. This blog post describes 
the rationale:




___
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 Workstation and disabled by default firewall

On Tue, Aug 27, 2019 at 2:37 PM, Iñaki Ucar  
wrote:

There's no need to write "a new style of firewall". It would be as
easy as asking the user once whether a new connection is trusted or
not. That's it.


But, well, how do you do that? What do you show to the user?

___
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 Workstation and disabled by default firewall


Thanks for the input, David.

On Tue, Aug 27, 2019 at 2:37 PM, David Kaufmann  wrote:
If there is a switch to "default reject" it is also very important 
that

the process to open up a port is easier than to disable the firewall
completely or injecting an "accept anything" rule. (e.g. by 
documenting

how to open ports in the installation instructions)


This seems like a particularly important point. We used to have users 
disabling the firewall since it's a lot easier to do that than to 
figure out what port needs to be opened to make an app work (assuming 
the user even knows what a port is).


___
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 Workstation and disabled by default firewall

On Tue, Aug 27, 2019 at 11:14 AM, John Harris  
wrote:
Please consider the security aspect of this. This is a critical 
vulnerability.
Please, don't make us look like the Linux Mint folks. If Workstation 
is to be
a viable product, especially if it's going to be advertised 
prominently, as

the primary download for Fedora, this needs to be fixed.


Can you point to any other major (serious) desktop Linux distro that 
ships with a restrictive firewall configuration?


The main competitor of Fedora Workstation is Ubuntu. Ubuntu ships 
without a firewall enabled and nobody considers this a critical 
vulnerability. Now: why is that...?


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Workstation and disabled by default firewall

On Tue, Aug 27, 2019 at 4:22 AM, John Harris  
wrote:
No, that is not how this works, at all. First, let's go ahead and 
address the
idea that "if the firewall blocks it, the app breaks, so it's the 
firewall's
fault": It's not. If the firewall has not been opened, that just 
means it
can't be accessed by remote systems until you EXPLICITLY open that 
port, with
the correct protocol, on your firewall. That's FINE. That's how it's 
designed

to work. There's nothing wrong with that.

This means that the system administrator (or owner, if this is some
individual's personal system) must allow the port to be accessed 
remotely,
before the app can be reached remotely, increasing the security of 
the system.


You've already lost me here. Sorry, but we do not and will not install 
a firewall GUI that exposes complex technical details like port 
numbers. Expecting users to edit firewall rules to use their apps is 
ridiculous and I'm not really interested in debating it.


If the user is capable of editing firewall rules and wants to do so, 
that user can surely also change the policy to not open all these 
ports. Yes?


___
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 Workstation and disabled by default firewall

On Tue, Aug 27, 2019 at 4:23 AM, John Harris  
wrote:
At least in KDE, possibly not in GNOME as it lacks many of the 
features

available in KDE, you can specify the zone of the connection in your
NetworkManager configuration GUI.


We used to have this for a long time, but removed it recently because 
the firewall zones were never really used for anything. We just have a 
Workstation zone that we expect users to not change. (But of course, if 
you want to change your firewall settings, you can change it if you 
want to.)


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Workstation and disabled by default firewall

On Tue, Aug 27, 2019 at 5:59 AM, Christopher 
 wrote:

The current status is that the Workstation WG never came up with a
solution in 5 years, and new people are finding this default
configuration and getting upset about the failure of Fedora
Workstation to meet basic security expectations.

Since Workstation WG has not come up with any better solution over the
course of 10 Fedora releases / 5 years, and the default insecure
status persists, I think it's reasonable to conclude that FESCo's
trust in the Workstation WG's ability to come up with a satisfactory
solution was misplaced. I would strongly urge the current FESCo
require Worksation to adopt the same secure default configuration as
Server, until such a time as Workstation WG comes up with a solution
for Workstation that can *honestly* clear the change proposal process.


To be clear, we have never had any plans to work on this.

If there is a separate team of firewall developers that would be 
interested in writing a new style of firewall, then I'm sure the WG 
would be happy to reopen discussion of the issue, including a 
discussion of requirements, etc. But I highly doubt anybody will be 
interested in this effort to reenable a stricter firewalld 
configuration. This doesn't seem like a serious effort to think about 
how a firewall could be useful, it just seems like an effort to break 
software.


___
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 Workstation and disabled by default firewall

2019-08-26 Thread mcatanzaro

On Mon, Aug 26, 2019 at 4:15 PM, Robert Marcano 
 wrote:
This is a reasonable point of view, until you notice Linux desktops 
evironments don't provide applications with a method to detect if 
they are running on a private network or not (See Windows Home, 
Office, Internet network settings).


Then a non technical user start Rythmbox, enable music sharing, and 
it works perfectly on their home network but then decides to buy a 
WAN card/USB stick and suddenly all the music is being shared to the 
world.


I wish NetworkManager could do something about these situations, 
maybe the default should be the public zone for interfaces that 
receive public IP addresses.


I don't have a good answer to this, other than to complain to the 
Rhythmbox developers. That's extremely bad if it's possible to 
accidentally share your music to the world.


Michael

___
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 Workstation and disabled by default firewall

2019-08-26 Thread mcatanzaro



Well the thing is, blocknig ports tends to break applications that want 
to use those ports. We're not going to do that, period. It also doesn't 
really accomplish anything: either your app or service needs network 
access and you have whitelisted it (in which case the firewall provides 
no security), or it needs network access and you have not whitelisted 
it (in which case your firewall breaks your app/service). In no case 
does it increase your security without breaking your app, right? Unless 
you have malware installed (in which case, you have bigger problems 
than the firewall). Or unless you have a vulnerable network service 
installed that you don't want (in which case, uninstall it).


So if you want to change the firewall settings, you'd need to 
completely rethink how the firewall works. And nobody seems interested 
in doing that. We could e.g. have a list of apps that are allowed 
network access, but then we'd need some form of attestation so apps 
can't impersonate each other. So only sandboxed (flatpaked) apps could 
use this hypothetical new firewall. And we surely don't want to have 
yes/no permission prompts, so we can't really ask the user "do you want 
your app to access the network?" (the user will almost always say yes). 
I'm not really sure what design would even work.


Avoiding unnecessary network services makes more sense.

On Mon, Aug 26, 2019 at 3:45 PM, Alexander Ploumistos 
 wrote:


As a matter of fact, you did:




Thanks for dredging up these links!

Michael

___
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: Better interactivity in low-memory situations

2019-08-11 Thread mcatanzaro

On Sun, Aug 11, 2019 at 10:50 AM, Chris Murphy 
 wrote:

Let's take another argument. If the user manually specifies 'ninja -j
64' on this same system, is that sabotage? I'd say it is. And
therefore why isn't it sabotage that the ninja default computes N jobs
as nrcpus + 2?  And also doesn't take available memory into account
when deciding what resources to demand? I can build linux all day long
on this system with its defaults and never run into a concurrent
usability problem.

There does seem to be a dual responsibility, somehow, between the
operating system and the application, to make sure sane requests are
made and honored.


This seems like a distraction from the real goal here, which is to 
ensure Fedora remains responsive under heavy memory pressure, and to 
ensure unprivileged processes cannot take down the system by allocating 
large amounts of memory. Fixing ninja and make to dynamically scale the 
number of parallel build processes based on memory pressure would be 
wonderful, but it's not going to solve the underlying issue here, which 
is that random user processes should never be able to hang the system.


Michael

___
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

Could not execute clone: [Errno 2] No such file or directory: '/home/mcatanzaro/Projects/fedora-scm/eog/.git/info/exclude'

2019-08-06 Thread mcatanzaro


$ fedpkg clone eog
Cloning into 'eog'...
remote: Counting objects: 2048, done.
remote: Compressing objects: 100% (1594/1594), done.
remote: Total 2048 (delta 787), reused 1036 (delta 349)
Receiving objects: 100% (2048/2048), 253.53 KiB | 2.33 MiB/s, done.
Resolving deltas: 100% (787/787), done.
Could not execute clone: [Errno 2] No such file or directory: 
'/home/mcatanzaro/Projects/fedora-scm/eog/.git/info/exclude'


The clone actually succeeds. I've been seeing this error for weeks now. 
What's going on?


___
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: How do I remove GLIBCXX_ASSERTIONS?

2019-08-03 Thread mcatanzaro

On Thu, Aug 1, 2019 at 1:28 PM, Steven A. Falco  
wrote:

What is the best way to do that?


Don't. As Florian has pointed out in Launchpad, this would convert the 
nice crash into a security vulnerability. The assertions have a 
negligible impact on performance, so better leave them enabled and 
focus on fixing your software bug instead.


Michael

___
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: Intent to orphan "tracker"

2019-07-29 Thread mcatanzaro

On Mon, Jul 29, 2019 at 6:46 AM, Carlos Garnacho  
wrote:
Sure, can try to make it part of the release routine. My ID is 
'garnacho'.


I don't think any work is required when releasing, since it should be 
automatically updated by Kalev's scripts. The work will just be keeping 
an eye on the bug reports, especially ABRT reports which look to have 
gotten out of hand. Getting these under control should really improve 
quality!


Michael

___
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: Intent to orphan "tracker"

2019-07-28 Thread mcatanzaro


On Sun, Jul 28, 2019 at 1:12 PM, mcatanz...@gnome.org wrote:

Odd, I only see eight bugs with changes since May:


OK sorry, I wasn't logged in so wasn't seeing all the private bug 
reports. I really wish ABRT didn't mark bug reports private by default 
for every backtrace containing a hash table "key"


Anyway, thanks for orphaning rather than just letting the crash reports 
go unaddressed.


Michael

___
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: Intent to orphan "tracker"

2019-07-28 Thread mcatanzaro

On Sun, Jul 28, 2019 at 9:35 AM, Igor Gnatenko 
 wrote:

I'm getting hundreds of ABRT bugs from tracker which I simply have no
time to go through. Would anybody like to take over that package from
me?


Odd, I only see eight bugs with changes since May:

https://bugzilla.redhat.com/buglist.cgi?component=tracker_id=10365965=Fedora

I do see a huge amount of crashes from the tracker-miners package:

https://bugzilla.redhat.com/buglist.cgi?component=tracker-miners_id=10365966=Fedora

Looks like tracker-miners has a serious problem with crashes. But you 
don't own tracker-miners.


Michael

___
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 31 System-Wide Change proposal: Python means Python3

2019-07-10 Thread mcatanzaro



Surprise, apparently python3 is coming to macOS in some form (maybe 
only for developers? not sure?) so WebKit should be fine with switching 
to pytohn3 regardless.


I don't think it's important to this discussion, just wanted to send a 
correction. I wasn't expecting this


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: adding speech installation to fedora network installation image

On Fri, Jun 28, 2019 at 11:13 AM, Martin Kolman  
wrote:
Certainly - but I'm afraid we in the Anaconda team don't have any 
experience
what all needs to be available (what packages should be included & 
what services started)
to make text-to-speech work on the image. We would definitely welcome 
some feedback

from a domain expert on this.


I've been advised that the domain experts are available at 
orca-l...@gnome.org:


https://mail.gnome.org/mailman/listinfo/orca-list

which seems to be pretty active. Good place for questions for both 
developers and users.


I'm also told that standard advice is currently to only use live 
installers if accessibility features are required. Shame.


Michael

___
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: adding speech installation to fedora network installation image

On Fri, Jun 28, 2019 at 10:44 AM, stan via devel 
 wrote:

it doesn't make sense to open a bug.  There is no gnome, and because
adding gnome would make the image too large, it will not be added.
Netinstall is a minimal image meant to be used from virtual consoles
with no graphical support.


But remember this isn't exclusive to netinstall. Only the live image 
runs a GNOME session: that's the only scenario when anaconda is running 
inside GNOME.


I think it makes sense to open a bug against anaconda to ask the 
anaconda developers whether text-to-speech is intended to work outside 
of live images. It seems odd to require that blind users exclusively 
use live images to install Fedora. E.g. that's not how RHEL is expected 
to be installed. And non-Workstation Fedora products do not have live 
installers.


Michael

___
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 31 System-Wide Change proposal: Python means Python3



On Fri, Jun 28, 2019 at 10:42 AM, mcatanz...@gnome.org wrote:
If Fedora has /usr/bin/python, then at least we have a *chance* to 
make the scripts we care about work in both python2 and python3 (our 
current plan). Whereas without /usr/bin/python, we're really out of 
options. So I very much support /usr/bin/python -> /usr/bin/python3. 
It will cause some problems for us and we'll have a difficult 
transition period, but at least there will exist the possibility of 
transitioning.


Accidentally hit send too soon. I meant to add: /usr/bin/python -> 
/usr/bin/python3 is better than all available alternatives. It's the 
only way that /usr/bin/python remains in Fedora pointing to a supported 
python interpreter. And that is the only chance that cross-platform 
python scripts have to work without pain and suffering (beyond that of 
making the script work with both python2 and python3). We're not python 
developers and just want to run some python scripts; wrapping up all 
our python inside e.g. bash scripts that start a virtualenv would be a 
sad end to this tale.


___
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 31 System-Wide Change proposal: Python means Python3

On Thu, Jun 27, 2019 at 5:51 PM, Stephen John Smoogen 
 wrote:
Actually I think it makes more sense that F31 provides no 
/usr/bin/python. Then a lot of things which depend on it can be found 
and fixed since they have not adapted to the Future any other way.


It would mean we have no chance of maintaining python scripts that work 
for both macOS and Fedora. Fedora's preference doesn't win here: on 
macOS /usr/bin/python is python2, and there is no /usr/bin/python2 so 
we can't use that in shebangs, and none of that is going to change. So 
e.g. WebKit's scripts have to use #!/usr/bin/python or #!/usr/bin/env 
python no matter what Fedora wants. Trying to convince Apple to use a 
virtualenv for building WebKit isn't going to happen.


(Actually #!/usr/bin/python cannot be used ever, because that doesn't 
work on FreeBSD, so we use #!/usr/bin/env python and rely on 
downstreams to rewrite it to the #!/usr/bin/python version if required 
for packaging. Messy enough yet?)


Anyway, we were able to make WebKit build in Fedora without using 
/usr/bin/python by using a combination of (a) changing shebangs for 
Linux-specific scripts, and (b) executing the scripts through CMake 
otherwise, so the shebang doesn't matter. So it's not an issue that 
/usr/bin/python is unavailable during package builds. It's an issue for 
developers using Fedora who need to use unpackaged scripts that are 
required to work on macOS.


If Fedora has /usr/bin/python, then at least we have a *chance* to make 
the scripts we care about work in both python2 and python3 (our current 
plan). Whereas without /usr/bin/python, we're really out of options. So 
I very much support /usr/bin/python -> /usr/bin/python3. It will cause 
some problems for us and we'll have a difficult transition period, but 
at least there will exist the possibility of transitioning.


Without /usr/bin/python we'd probably have to tell developers to 
manually install as python2 in /usr/local so that scripts using 
/usr/bin/env python get python2... way worse.


Michael

___
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 31 System-Wide Change proposal: Python means Python3

2019-06-27 Thread mcatanzaro


On Thu, Jun 27, 2019 at 4:34 PM, Neal Gompa  wrote:

This is because
in everything *except* Linux distributions, the unversioned name has
already switched over.


Not in macOS.

___
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: adding speech installation to fedora network installation image

2019-06-27 Thread mcatanzaro

On Thu, Jun 27, 2019 at 8:31 AM, stan via devel 
 wrote:

I'm not familiar enough with orca and gnome to say if this is a bug or
not.  When I looked for bugs, I found a bug from February that stated


Only the live image runs in a GNOME session where GNOME session 
services like orca are expected to be working. The netinstall image 
only runs anaconda, it doesn't run GNOME at all. I don't know whether 
the anaconda developers except orca to be supported in netinstall mode.


Michael

___
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: [HEADS UP] Unannounced soname bump of qrencode

2019-06-25 Thread mcatanzaro



Let's ensure this at least doesn't happen for the same library again 
and again.


In [1], change SHOULD NOT -> MUST NOT.

Require maintainers (or provenpackagers) to fix violations like [2] 
when unannounced soname bumps occur.


(If anyone wants to write a script to detect such problems proactively, 
even better.)


If we don't fix [2] the problem will just occur again.

[1] 
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_listing_shared_library_files
[2] 
https://src.fedoraproject.org/rpms/qrencode/blob/f48205000af5397008dbd645abb941e0dbb49636/f/qrencode.spec#_63


___
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: Reporting is disabled because the generated backtrace has low informational value

2019-06-24 Thread mcatanzaro


On Mon, Jun 24, 2019 at 6:50 AM, mcatanz...@gnome.org wrote:
That's not right. The backtrace was processed on the retrace server, 
so installing debuginfo locally should not be required.


I think it's a longstanding ABRT bug.

Michael


Oh, I forgot what I was actually planning to write about when I decided 
to send a mail. ABRT doesn't support reporting crashes from flatpak 
apps. It's a feature we requested a while ago [1]. In the meantime, if 
a flatpak app crashes, you'll have to generate a backtrace manually 
using the flatpak-coredumpctl command:


$ flatpak-coredumpctl org.gnome.Epiphany.Devel//master

So that's easy, but the backtrace will be useless unless you have debug 
symbols installed for both the runtime and the application. I can never 
remember how to do that and there doesn't exist documentation anywhere 
that I can see. ABRT will need to learn how to do all of this.


None of this is relevant to Chris's crash, because he's not reporting 
that a flatpak application is crashing. He's reporting that flatpak 
itself is crashing. ABRT should already be able to handle this like it 
does any other bug, and it's surely an ABRT bug for it to have failed 
here.


[1] https://github.com/abrt/abrt/issues/1196

___
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: Reporting is disabled because the generated backtrace has low informational value

2019-06-24 Thread mcatanzaro

On Sun, Jun 23, 2019 at 9:34 PM, Sam Varshavchik 
 wrote:
That's your key piece of info. You're missing the debuginfo package, 
without it the backtrace has no info.


With a native, directly-installed RPM, the debug repo gets 
automatically enabled, and the debuginfo packages gets automatically 
fetched and installed. I guess with flatpacks, this is not automatic. 
Don't know much about flatpaks, but this is what you need to figure 
out how to make it happen.


That's not right. The backtrace was processed on the retrace server, so 
installing debuginfo locally should not be required.


I think it's a longstanding ABRT bug.

Michael

___
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: Docker and user namespaces on F30

2019-05-10 Thread mcatanzaro

On Fri, May 10, 2019 at 12:10 PM, Tomasz Torcz  
wrote:

  This is not what Fedora ships. We have (in F30)
  docker-1.13.1-67.git1185cfd or moby-engine-18.06.3-2.ce.gitd7080c1.


What is going on with this very weird, very confusing versioning? The 
Fedora version doesn't even look like the upstream date-based version 
numbers? Is the Fedora release really just that old?


___
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: environment variables LANGUAGE

2019-04-16 Thread mcatanzaro



My first thought is accountsservice, check that first.

___
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: F30 live images still contain dbus-daemon package, anaconda-core requires it ?

2019-04-11 Thread mcatanzaro


On Thu, Apr 11, 2019 at 2:39 AM, jkone...@redhat.com wrote:
The problem is that Anaconda have to start it's own session of dbus 
but

dbus-broker, by design, don't have easy way how to do this without
systemd running.


TBH we should probably keep dbus-daemon around until we have a 
replacement for dbus-run-session anyway; it's too useful when working 
with headless environments like continuous integration, containers, 
etc. There is already an issue for this at 
https://github.com/bus1/dbus-broker/issues/145, so Anaconda is far from 
the only one having this problem.


Michael

___
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: Can we maybe reduce the set of packages we install by default a bit?

2019-04-09 Thread mcatanzaro

On Tue, Apr 9, 2019 at 12:11 PM, Adam Williamson 
 wrote:

To be specific here, 'at' is part of the @standard group. 'chrony' is
pulled in several ways. It's part of @standard *if 
gnome-control-center
is being installed*, so effectively it'll be installed with 
Workstation

but not other editions/spins.


Note that Workstation doesn't include @standard at all.

___
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: [PSA] %meson contains -Db_ndebug=true

2019-04-09 Thread mcatanzaro

On Tue, Apr 9, 2019 at 7:54 AM, Kalev Lember  
wrote:

Awesome, thanks Igor! All of this sounds good to me.


Yeah, sounds like everything is fine now after the if-release fix. 
Thanks!


___
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: [PSA] %meson contains -Db_ndebug=true

2019-04-08 Thread mcatanzaro



On Mon, Apr 8, 2019 at 1:39 PM, Benjamin Tissoires 
 wrote:

That's not how I read it:
https://github.com/mesonbuild/meson/blob/master/docs/markdown/Builtin-options.md#base-options
-DB-ndebug defaults to false.


OK, then I was totally wrong, thanks.

Shame the docs are so hard to search through. :(


Again, this setting should be set per project, so reverting the change
was the right call IMO.


OK, I agree now. Since it's off by default in meson upstream, we 
shouldn't be turning it on in Fedora. Sounds like reverting is the 
right move.


With the above in mind, I consider mesa's meson build system to be 
broken for incorrectly assuming distros will use -Db_ndebug=if-release 
or -Db_ndebug=true, since we will not be doing that. So mesa should 
find another way to ensure its performance-sensitive asserts are not 
enabled in plain builds (or release builds). Right? We can of course 
work around the issue in the Fedora spec by using -Db_ndebug=true just 
for mesa.


Michael

___
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: [PSA] %meson contains -Db_ndebug=true

2019-04-08 Thread mcatanzaro

On Mon, Apr 8, 2019 at 5:50 AM, Kalev Lember  
wrote:
I agree as well. Please don't override -Db_ndebug in distro-wide 
%meson
macro and instead move the override to mesa packaging if it's needed 
there.


Well hold up. -Db_ndebug defaults to if-release... right? We have only 
changed the behavior for plain builds (distro builds) to match release 
builds? So any package that has ever tested a release build would 
already know to expect assertions to be disabled, and the only broken 
packages are those that have never tested a release build?


I see three options:

- Plain builds should match the behavior of release builds, and Fedora 
plain builds should match the behavior of upstream plain builds. This 
is what we briefly had but just reverted. (Option one)


- Upstream plain builds should be really completely plain. Fedora can 
either add on -Db_ndebug=true or not (options two and three). This 
makes less sense to me because -Db_ndebug is really special, not like 
other compiler flags.


I don't think it's right to say "NDEBUG should be off by default 
because that's how it is with Autotools" since we're not Autotools 
anymore, we should decide something that makes sense for meson, based 
on meson semantics and meson expectations and in coordination with 
meson upstream. E.g. I see you (Igor) reverted the RPM macro change, 
but that was just the bandaid over the default behavior of if-release, 
which is actually still changed, right? It's unclear to me what the 
default value of -Db_ndebug is due to underdocumentation, but if it's 
if-release then this change is just going to reappear again in the next 
version of meson, right?


Michael

___
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: More than 10% of all Fedora spec files are not POSIX sh compliant

2019-03-26 Thread mcatanzaro

On Thu, Mar 21, 2019 at 5:05 PM, Tomasz =?UTF-8?b?S8WCb2N6a28=?= 
 wrote:

[tkloczko@domek SPECS.fedora]$ rpm -E %_buildshell
/bin/sh


How can this discussion still be ongoing? Why not just change it to 
/bin/bash and move on?


___
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: Chromium C++ help needed

2019-03-13 Thread mcatanzaro

On Wed, Mar 13, 2019 at 11:53 AM, Jakub Jelinek  
wrote:

calling methods on NULL pointers to objects etc.


Chromium probably does this (or, at least, did in the past). Removing 
-fno-delete-null-pointer-checks could introduce Fedora-specific crashes.


Michael
___
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: /etc/yum.repos.d -> /etc/distro.repos.d

2019-03-13 Thread mcatanzaro

On Wed, Mar 13, 2019 at 7:50 AM, Kalev Lember  
wrote:
Please don't, it's just pointless renaming that invalidates all end 
user
documentation and makes it harder for other programs such as 
packagekit

and gnome-software that all need to adopt for the new paths.


Handling a rename is not exactly rocket science. Why would this be at 
all problematic? The change is proposed for F31, not F30. That's plenty 
of time. If this is the last remaining usage of "yum" in the distro 
then let's get rid of it and move on. Since both locations should be 
read, it should be fully backwards-compatible anyway.



Also, I've heard rumours that dnf might get renamed back to yum in the
future.


Do the dnf developers know about this rumor...?

Michael
___
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: Fedora 30 Beta blocker status mail #3

2019-03-08 Thread mcatanzaro

On Fri, Mar 8, 2019 at 1:18 PM, Adam Williamson 
 wrote:

I requested testing on desktop@ and test@ lists earlier this week; so
far that seems to suggest that this is failing for a lot of people on 
a

lot of hardware...but it also fails the same way on F29 in most cases,
suggesting we shipped F29 broken as well. I don't think we've yet had
feedback from a system where nomodeset is actually *needed*, which
would be interesting.


Please also consider that the target audience for Fedora Workstation is 
not going to know about nomodeset or how to modify the kernel command 
line. So unless we have some specific release criterion referencing 
nomodeset, I'm not sure why it would be a blocker.

___
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: Editions vs. Spins (was: Re: F30: System-Wide Change proposal: DNF UUID)

2019-01-14 Thread mcatanzaro

On Mon, Jan 14, 2019 at 12:05 PM, John Harris  
wrote:
The easiest way to make any of the Spins more accessible, for them to 
have any
chance comparable to the prominent advertising of Workstation and 
similar
options, would be to make them more prominent on the "getfedora" 
index. This

also have a huge effect on SEO.


So the reason spins are not very visible -- and ought to stay not very 
visible -- is that they don't get the same level of attention as the 
main products, and we don't really want anybody to download those 
unless they know in advance what they are doing. In particular, we 
really don't want Fedora to be judged by the quality of its spins and 
labs. There are a lot of them, and it's just not plausible to keep up 
with quality control for every one.


The Plasma spin is perhaps an exception here. I could totally see that 
one being elevated to the level of Fedora product: "Fedora Plasma" or 
something like that. I wouldn't really mind having two desktop 
products, myself. We just can't create Fedora products for every single 
desktop out there, or the download page is going to become way too hard 
to navigate, and users will become less-likely to wind up with the 
versions of Fedora that we want to promote. So if we promote KDE to a 
product, I'd say we'd have to draw the line there, and I'd argue that 
would make sense due to KDE's outsized importance to the Fedora 
community relative to other spins, and the QA it already receives 
(especially its blocker bug eligibility). I assume we fear branding 
difficulties if we have multiple UIs for Fedora? Perhaps it'd be a huge 
mistake. But the potential benefits of attracting more KDE users and 
developers to Fedora might well outweigh the cost! It's at least worth 
seriously considering.


Michael
___
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: responding to CVEs

2019-01-14 Thread mcatanzaro

On Mon, Jan 14, 2019 at 7:35 AM, Dave Love 
 wrote:

I ask because three CVEs have triggered automated bug reports against
libxsmm .  I 
don't

understand why the CVEs were issued, since a problem with unrealistic
input to a (rather rarely used) development tool doesn't strike me as 
a

security problem.


Wow, of course "heap-based buffer overflow" and "resource exhaustion" 
are worth CVEs. If the developers don't intend to fix these issues, you 
should retire the package.


Michael
___
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: F30 System-Wide Change proposal: Replace Comps Language Group With Langpacks

2019-01-10 Thread mcatanzaro


On Thu, Jan 10, 2019 at 11:36 AM, mcatanz...@gnome.org wrote:
In the future, we'd like to switch to running gnome-initial-setup 
prior to anaconda for language and keyboard layout selection, then 
anaconda, then gnome-initial-setup again on firstboot. Anaconda would 
therefore not be used for language selection at all. What would 
happen if language was selected only in gnome-initial-setup. Would 
the right language packs be installed? Would the languages even 
appear in the list to allow selection?


BTW, the rationale for this is that anaconda is too late to do language 
selection. It's basically impossible to select your language or input 
method on the live system unless you know English. Ditto for keyboard 
layout and input sources. And if you don't know English, you might not 
be able to read the "Try Fedora / Install Fedora" screen.

___
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: F30 System-Wide Change proposal: Replace Comps Language Group With Langpacks

2019-01-10 Thread mcatanzaro



Will gnome-control-center be able to install missing language packs and 
input sources?


What about gnome-initial-setup?

In the future, we'd like to switch to running gnome-initial-setup prior 
to anaconda for language and keyboard layout selection, then anaconda, 
then gnome-initial-setup again on firstboot. Anaconda would therefore 
not be used for language selection at all. What would happen if 
language was selected only in gnome-initial-setup. Would the right 
language packs be installed? Would the languages even appear in the 
list to allow selection?


Michael
___
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: Orphaned packages to be retired

2019-01-07 Thread mcatanzaro

On Mon, Jan 7, 2019 at 4:57 PM, Stuart D. Gathman  
wrote:

retiring pygtk2 retires most of Fedora desktops and gui apps, from
Gnome-shell to cinnamon to openbox. ;-)


Hm, sounds like there is a bad dependency in the chain somewhere. 
pygtk2 is very much obsolete and should be allowed to disappear. 
Nothing in GNOME should be using it anymore. Curious what the 
problematic dep is here.

___
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: desktop-file-validate fails with error: file contains group "Catia Shortcut Group", but groups extending the format should start with "X-"

2018-12-14 Thread mcatanzaro

On Fri, Dec 14, 2018 at 7:14 AM, Martin Gansser 
 wrote:

how can i solve this ?
Thanks Martin


All the custom groups need to start with "X-" (for "extension"). E.g.:

[Catia Shortcut Group]

Replace it with:

[X-Catia Shortcut Group]

Michael
___
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: Which I/O scheduler is Fedora switching to in 4.21? mq-deadline or BFQ?

2018-12-13 Thread mcatanzaro

On Thu, Dec 13, 2018 at 2:30 PM, stan  
wrote:

Latency statistics:
 min max avg std_dev conf99%
1.51   2.583 1.925330.576087 11.5249


Looks like this is what we want for Workstation, where latency is more 
important than throughput?

___
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: New ZoneMinder packages - except el7

2018-12-08 Thread mcatanzaro

On Sat, Dec 8, 2018 at 10:26 AM, Andrew Bauer 
 wrote:

Sorry for the noise. This was meant for the rpmfusion devel list.


Why is Zoneminder in RPMFusion? I'm curious why is it ineligible for 
Fedora?


Michael
___
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: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

2018-11-26 Thread mcatanzaro

On Mon, Nov 26, 2018 at 10:03 AM, Matthew Miller 
 wrote:
I know it was a big time-off holiday week in the US, but I expected a 
little
more interest in this post. Perhaps it seemed like too much text to 
digest

along with turkey and stuffing. :) I'm highlighting it with a subject
reflecting the big, direct impact, and here's some other top-level
proposals:


Can we use this as an opportunity to work out how to use the blocker 
bugs process for a megaupdate? Our reputation for providing an 
up-to-date desktop took a hit last time we did this, so we'll want to 
provide a GNOME 3.34 megaupdate in October 2019 to compensate for the 
missing Fedora release there. We'll need a monthslong testing process 
for this to go smoothly mid-release.


Michael
___
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: Fedora Lifecycles: imagine longer-term possibilities

2018-11-15 Thread mcatanzaro

On Tue, Nov 13, 2018 at 5:36 PM, Matthew Miller 
 wrote:

But there are some good cases for a longer lifecycle. For one thing,
this has been a really big blocker for getting Fedora shipped on
hardware. Second, there are people who really could be happily running
Fedora but since we don't check the tickbox, they don't even look at 
us

seriously. I'd love to change these things. To do that, we need
something that lasts for 36-48 months.


"Canonical Extends Ubuntu 18.04 LTS Linux Support to 10 Years"

https://www.serverwatch.com/server-news/canonical-extends-ubuntu-18.04-lts-linux-support-to-10-years.html

I just don't see how we're going to be able to compete with that, not 
unless our Fedora LTS is just CentOS with different branding.


Michael
___
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: Fedora Lifecycles: imagine longer-term possibilities

On Wed, Nov 14, 2018 at 4:42 PM, John Florian  
wrote:
I still don't understand what makes updating these for a *new* 
release significantly easier than an *existing* one. So let's 
just say GNOME (or whatever) comes out next month with a new major 
release we want to showcase. Why is it necessary to have a 
Fedora 30 to be able to realize this update. What is so 
difficult about providing this for Fedora 29. I'm trying to 
understand why these upstream updates can't be decoupled from the 
Fedora release schedule.


It's all a matter of QA. The freeze, the blocker bug process, and the 
quantity of users who test the stuff for us. We'd need major changes to 
our updates process to account for this in a mid-release update. The 
blocker bugs process would be needed, for a single bodhi update. At 
least a month or two of testing (during which new versions of the 
update will be released, so the update will have to go through some 
iterations). And lots and lots of testers: currently we get those for 
free because tons of people help us test beta releases of Fedora, I 
think far more than run updates-testing.


This is all doable and solvable. Not a blocker. But if we don't take it 
seriously and make some big changes in how we release updates, it won't 
go well. Not well at all. So I'd recommend against it, unless there is 
some major benefit available from doing so.


Michael
___
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: Fedora Lifecycles: imagine longer-term possibilities

On Wed, Nov 14, 2018 at 10:31 AM, Matthew Miller 
 wrote:
Is there a way we could do these as ".1" releases, with orchestrated 
QA for

the big update rather than a whole release?


It's a possibility... I'd rather call it .5 for halfway, though.

F30, F30.5, F31... ehh, it would be OK, but there should be real 
concrete gain if we do this. It gets us no closer to a 36 month 
lifetime.


Or, if we can combine this with having a gated Rawhide meant for 
day-to-day
use (and using ostree for rollbacks), would that be adequate for the 
"on the

edge" GNOME community?


No, even I wouldn't use it. I like having a stable desktop.

Michael
___
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: Fedora Lifecycles: imagine longer-term possibilities

On Tue, Nov 13, 2018 at 5:36 PM, Matthew Miller 
 wrote:

But there are some good cases for a longer lifecycle. For one thing,
this has been a really big blocker for getting Fedora shipped on
hardware. Second, there are people who really could be happily running
Fedora but since we don't check the tickbox, they don't even look at 
us

seriously. I'd love to change these things. To do that, we need
something that lasts for 36-48 months.


Is 36 months an absolute minimum for getting onto consumer laptops?

Don't underestimate the difficulty of adding an extra year. 48 months 
is a *lot* harder than 36.  36 is a lot harder than 24 or 27 (2 years 
plus 3 month upgrade window).


Michael
___
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: Fedora Lifecycles: imagine longer-term possibilities

On Wed, Nov 14, 2018 at 9:29 AM, Ralf Corsepius  
wrote:
Absolutely. Fedora once was a pretty solid end-user distro and 
fun-project for devs. Now it has become an unstable, experimental 
"bleeding edge" distro with a more and more balloning overhead.


I don't agree at all. Fedora is great. We have tons of compliments from 
users in places like /r/Fedora and /r/GNOME praising how stable Fedora 
is. We have by far the most developers working on the distro, thanks to 
Red Hat. And our QA process -- blocker bugs and freeze exceptions -- is 
second to none, and ensures we have the highest-quality product of any 
comparable distro on release day.


What we have is a reputation management issue. This reputation that 
Fedora is bleeding edge or a testbed for RHEL is pervasive, and we need 
to find some way to kill it.


Another issue is that our updates QA remains insufficient: broken 
updates are able to reach users before they can be detected and pulled, 
defeating the benefit of all that release day QA. Subjectively, this 
situation feels better nowadays than it used to be. But we still had a 
big problem with the recent broken mesa and GCC updates, for example.


Michael
___
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: Fedora Lifecycles: imagine longer-term possibilities

On Wed, Nov 14, 2018 at 9:08 AM, Gerald Henriksen  
wrote:

My feeling is part of the solution is to move to a yearly release
cycle.  Unlike the early days of Fedora things just aren't changing as
quick in terms of the base of the OS - hardware support in the kernel
is generally excellent, and both Gnome and KDE (and likely the others)
are mature environments that while they improve with each release
there isn't generally anything that says a 6 month wait would be
unbearable - and consideration should also be done to the track record
that given the overall stability of those desktops that upgrades can
likely be done safely mid-Fedora-release.


We need to rebase GNOME within about two months of the new upstream 
releases, or we'll lose our edge with the GNOME community. We'd be 
ceding our position as best GNOME distro to Ubuntu and Arch. So a 
one-year cycle means a major GNOME version update will need to land in 
the middle of a release to avoid that. And these do not have a good 
reputation for stability. Basically we'll wind up with a bunch of bugs 
landing halfway through the release, and without the usual Fedora QA 
process to ensure the most important of them get fixed before they 
reach users. So I can't support this plan


Michael
___
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: Better fonts by default?

2018-11-10 Thread mcatanzaro


On Sat, Nov 10, 2018 at 4:03 PM, Neal Gompa  wrote:

Most of the defaults upstream are largely due to legal issues that are
no longer applicable.


As of very recently, Marik did make one change: subpixel rendering is 
now enabled by default in Fedora's freetype package (if you have the 
latest F29 updates) at build time, whereas it's still disabled by 
default upstream. But it remains disabled at runtime. But I don't think 
that's due to legal reasons. I think it's just because that's what 
Nikolaus prefers. He's an expert on font rendering, and I'm not, so 
you'd have to ask him.


Another difference is that we disable bitmap fonts at the fontconfig 
level, because it's insane not to. That really ought to be changed 
upstream.



And Fedora is the only distribution I know of
that actually actively maintains a very large fontconfig configuration
for every single font.


I wasn't aware of this?

Michael
___
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: Better fonts by default?

2018-11-10 Thread mcatanzaro


On Sat, Nov 10, 2018 at 8:57 AM, Neal Gompa  wrote:

Does anyone actually take care of our fonts stuff anymore?


Off the top of my head, there's Akira Tagoh covering fontconfig both 
upstream and downstream, Marek Kasik covering freetype downstream, and 
Nikolaus Waxweiler handling freetype upstream, Cantarell upstream, and 
the GNOME settings.


It seems unlikely to me that any downstream customizations would be 
accepted directly into Fedora, since we try to stick very close to 
upstream defaults. So please, send any desired improvements upstream.


For example, the gschema changes should go to the gnome-settings-daemon 
project, where it is probably going to run up against the fact that (I 
believe) Nikolaus prefers grayscale hinting. I'm sure he'd be happy to 
provide a rationale for why rgba is not default. Then the fontconfig 
changes should be submitted to the fontconfig project. The author of 
the changes should again be prepared to argue why the changes should 
become defaults. I don't see why upstream would reject the changes if 
they are good.


At the end of the day, font settings are highly subjective, so I'm 
pretty skeptical of anything called "fedora-enhanced-defaults" or 
"fedora-better-fonts". They don't look any better or worse to me. They 
just look different. So I'm inclined to trust the expertise of the 
people maintaining the font packages, who've probably not set the 
defaults as they are arbitrarily


Michael
___
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: IBM buying RedHat

2018-11-01 Thread mcatanzaro


On Thu, Nov 1, 2018 at 8:32 AM, Neal Gompa  wrote:

These are questions I'm interested in answers on. However, I'm also
worried about how much the "cloud" was mentioned in the presser. It
makes me nervous about Red Hat's investment into other areas, which a
lot of the Linux ecosystem relies on, even outside of the Fedora
community. Desktop Linux, traditional server platforms, IoT, etc. look
like areas that might be disinvested in. :(


The press release's focus on cloud cloud cloud sure makes it sound like 
desktop team will be first in line for cuts. I think it's quite natural 
for Fedora Workstation users to be worried right now, given the lack of 
public statement regarding the future of Red Hat's desktop work. It 
goes without saying that Fedora will not have a very bright future if 
Red Hat's investment in desktop and Workstation were to cease or be 
significantly reduced.


Plus a lot of my friends work on desktop and they will be :( :( :( if 
their jobs go away.


Michael
___
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: Translating the banner text

2018-10-31 Thread mcatanzaro

On Wed, Oct 31, 2018 at 10:18 AM, scootergrisen 
 wrote:
During Fedora Workstation 29 installation there are some banners 
being shown like the ones on 
https://fedoraproject.org/wiki/How_to_Create_an_Anaconda_Banner


In the svg code i see some of the banners are translate into multiple 
language.
I would like to translate the banners for a more complete translation 
of the installer but where are the instructions/translations?


Just want to add: the banners don't really look great, and it'd be nice 
to see them removed from the installer (or replaced). First there's the 
hot dog, which is fun but not very professional. Then the Rhythmbox one 
where "Music" gets cut off after "Mus" because the full width of the 
banner is not displayed


Michael
___
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: bottlenecks that case my machine to freeze

2018-10-25 Thread mcatanzaro

On Thu, Oct 25, 2018 at 6:50 AM, Nicolas Mailhot 
 wrote:
I get the same thing without any special load. System would work fine 
for hours and then input would start bugging.


It translates into floods of keystrokes, or eaten keystrokes, or 
keystrokes being fed to apps out of order. Requires a system reboot 
to fix.


There is a serious bug somewhere in libinput WRT input queue 
management (priorization, ordering, and press/release detection).


I use Logitech wireless keyboards and mice with the bluetooth usb 
dongle. Don't know if that's your case too.


Regards,


I don't think it's a libinput problem. I was talking with Alex about 
this a while back, and if I remember correctly, he thinks it's a 
Wayland protocol flaw: basically there's no way for the compositor to 
tell the difference between "the key is being pressed for a long time" 
and "the computer is under such heavy load that the keypress end event 
hasn't arrived from the client yet". Of course it's a bit more 
complicated than that, but the end result is too many keystrokes, or 
eaten keystrokes. Something changed in F28 (or was it F27? recently at 
any rate) to make this bug occur way more often than it used to, and 
we're not quite sure what, but anyway, the problem is known to the 
relevant developers so hopefully might get fixed soonish.


Hardware details aren't needed because it occurs for many developers on 
diverse hardware.


Michael
___
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: F29 Self-Contained Change: GnuTLS enables TLS 1.3 by default

2018-10-05 Thread mcatanzaro

On Fri, Oct 5, 2018 at 5:21 PM, Nathanael D. Noblet  
wrote:

Ok, I can help with the debugging if needed. I just didn't know what
stack this was built on. Let me know if/what you'd like me to do.


Honestly I have no clue since the code seems foolproof. A bug report at 
https://gitlab.gnome.org/GNOME/glib-networking/issues would be a good 
place to start so we can get it onto some bugtracker, at least.
___
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: F29 Self-Contained Change: GnuTLS enables TLS 1.3 by default

2018-10-05 Thread mcatanzaro

On Fri, Oct 5, 2018 at 4:54 PM, Nathanael D. Noblet  
wrote:

Ok, so should I be filing a bug and if so against which component? I
wasn't sure if the google online accounts part of GNOME used GnuTLS or
not.


It uses glib-networking, which does use GnuTLS. glib-networking already 
enables SNI (off the top of my head, in GTlsClientConnectionGnutls.c), 
so some further debugging is going to be required here to see if indeed 
it's true that the SNI extension is not being sent for some reason.
___
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: hibernation — does it work for you?

2018-10-04 Thread mcatanzaro

On Wed, Oct 3, 2018 at 5:38 PM, Zbigniew Jędrzejewski-Szmek 
 wrote:

Note: I'm not talking about the user-space configuration issues
(resume= not set on the kernel command line, no swap, swap encrypted
with temporary keys, whatever), but only about any potential kernel
driver issues.


Well "whatever" is a big deal here, we need to know exactly what is 
expected to work and what not before we can test this, or we'll provide 
you with false reports that it's broken.


A default install of Fedora with encryption enabled creates swap on 
encrypted LVM. Is that expected to work? I'm not planning to 
repartition my computer to test this and it's maybe not worth arguing 
about if that's not expected to work.


Also, don't forget secure boot, kinda a big deal
___
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: Attention Gmail users, please turn off HTML mail

2018-10-02 Thread mcatanzaro

On Tue, Oct 2, 2018 at 3:40 PM, Dominik 'Rathann' Mierzejewski 
 wrote:

Stop sending e-mail to public mailing lists using Gmail, then?


Perhaps we've reached the end of meaningful conversation in this 
thread
___
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: Non-responsive package maintainer - Ray Strode (halfline), Plymouth package

2018-10-02 Thread mcatanzaro



On Tue, Oct 2, 2018 at 1:17 AM, fedora201...@nuclearsunshine.com wrote:

Hi Ray, unfortunately in some cases it doesn't though. It's currently
completely breaking boot with amdgpu+LUKS, and before that for several
months under amdgpu it was not echoing LUKS characters to screen or
otherwise updating at all after showing the LUKS prompt, making it 
seem

that password entry was not working and the boot process had frozen.


Since this is a very common setup, surely it should be a release 
blocker bug. I would propose it using the usual blocker review process.


In fact, since this bug looks like a disaster, I'm going to do that now.


I'm not jumping up and down demanding "devote all your time to fix my
Plymouth bug(s)!" ;) (I've disabled RHGB for now on my system in any
case); rather saying that if there aren't enough resources to make 
this
level of maintenance realistic at the moment, it might be worth 
looking

at whether it's still a good idea for Plymouth to continue to be
enabled by default?


If a bug prevents booting, please propose it using the blocker review 
process. Unless it requires a really esoteric hardware setup, it's 
probably a blocker.


Michael
___
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: F29 Self-Contained Change: GnuTLS enables TLS 1.3 by default

2018-09-23 Thread mcatanzaro

On Sun, Sep 23, 2018 at 10:14 AM, Nicolas Mailhot 
 wrote:
??? That's not a Google choice, SNI is one of the 
Mandatory-to-Implement
Extensions in TLS 1.3. You'll need it to connect to anything that 
claims

TLS 1.3 (which will be everyone as soon as someone publishes a hole in
TLS 1.2)

Of course Google *was* heavily involved in the TLS 1.3 draft, and *is*
working on obsoleting SNI as it exists today in favour of an encrypted
variant.


I didn't know that!

In that case... well, that requires changes in all applications using 
GnuTLS that don't already use gnutls_server_name_set(). They will 
either need to call gnutls_server_name_set(), or else disable TLS 1.3. 
Correct?


Michael
___
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: F29 Self-Contained Change: GnuTLS enables TLS 1.3 by default

2018-09-23 Thread mcatanzaro

On Sun, Sep 23, 2018 at 7:57 AM, Michael Schwendt  
wrote:

That an update for SNI may be required is clear, but it doesn't answer
the question where a change will be needed.


The Claws Mail developers will have to investigate. The right place 
will be close to all the other uses of GnuTLS, though, after creating 
the gnutls_session_t, before connecting to the server.


On Sun, Sep 23, 2018 at 7:57 AM, Michael Schwendt  
wrote:

No, it isn't, because fetchmail doesn't use gnutls. Claws Mail does,
and additionally it is based on libetpan, which uses gnutls
internally, too.


There's really nothing more to say about the problem than what's 
explained there. If you want to connect to Google with TLS 1.3 you're 
going to have to use SNI, because Google has decided to require it. 
It's unfortunate that this artificially introduces an incompatibility 
for applications that are turning on TLS 1.3 when so much effort has 
gone into ensuring the protocol is backwards-compatible and resistant 
to so many ways of breaking that.


You could also just turn off TLS 1.3 with 
gnutls_set_default_priority_append(). Of course, that will break in a 
few years when Google starts refusing TLS 1.2 connections. Better to 
use SNI.


Michael
___
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: F29 Self-Contained Change: GnuTLS enables TLS 1.3 by default

2018-09-22 Thread mcatanzaro

On Sat, Sep 22, 2018 at 3:32 PM, Michael Schwendt  
wrote:

Apparently, this change breaks Google Mail IMAP for Claws Mail.
https://bugzilla.redhat.com/1629151


You'll need to add a call to gnutls_server_name_set(), see:

https://www.gnutls.org/manual/gnutls.html#Server-name-indication

The problem is explained quite well in the other linked bug:

https://bugzilla.redhat.com/show_bug.cgi?id=1611815

Hope that helps,

Michael
___
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: Fedora 29 Beta Bug

2018-09-21 Thread mcatanzaro

On Thu, Sep 20, 2018 at 9:29 AM, Chris Murphy  
wrote:
Add systemd.debug-shell=1 boot parameter at the grub menu, then 
switch to tty9 once startup has failed.


We only have tty1 through tty6?

Michael
___
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: Orphaning qt5-qtwebengine

2018-09-11 Thread mcatanzaro



Kevin,

Thanks for taking care of this package for so long. It's an 
exceptionally-challenging package that most maintainers would not be 
willing to touch, and your work was very much appreciated.


Michael
___
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: F29 System Wide Change: Remove Excessive Linking

2018-08-04 Thread mcatanzaro


On Thu, Aug 2, 2018 at 4:57 AM, Jakub Jelinek  wrote:
Changing the behavior of say -lpthread on the command line is a bad 
idea,
many projects really expect it to mean that the mentioned library is 
linked
in and if it no longer does, it causes silent breakage.  Forcing 
users to do

-Wl,--push-state,--no-as-needed ... -Wl,--pop-state
whenever they really mean to link some library is too hostile.


My understanding is that at least Debian and SUSE have defaulted to 
--as-needed for years, and probably more distros do as well... so 
presumably most problems should have been shaken out already. Is anyone 
familiar with the status of --as-needed in other distributions?


If Fedora and RHEL are the only major distros that are different, then 
that argues in favor of adopting this change, so that developers using 
Fedora don't accidentally write programs that are broken on other 
distributions. I know I've been stung by this in the past, when an 
application I developed on Fedora failed to link on Debian


Michael
___
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/message/3AONF4EJ27EDPWJOK6U6KKAMYOHP3SY5/

Re: RFC: Pass --auto-features=enabled in meson

2018-07-23 Thread mcatanzaro

On Mon, Jul 23, 2018 at 8:27 PM, Josh Boyer
wrote:

My biggest objection here is that it blindly enables things, which
continues to make our package set a web of inter-dependencies and
makes any attempts at minimization harder. I don't think we should
default to building everything in here. I understand autotools might
do that, but I wouldn't necessarily call autotools a best practice to
begin with...

It's a bit confusing, but Igor is proposing that we *disable* auto
feature detection by passing -Dauto_features=enabled. Um, what? Yes,
the options are enabled, auto (default), and disabled, where both
enabled and disabled turn off auto feature detection. enabled is used
to fail the build whenever an auto dependency is missing, and disabled
is used to allow the build to proceed without that feature.

-Dauto_features=auto is the meson default, and it's what we currently
suffer with autotools: features get silently enabled or disabled
depending on which BuildRequires are present in the spec file. This is
the status quo, and it's a disaster. Auto dependencies are good if
you're building packages locally and don't want to install unnecessary
dependencies (hence a good default behavior), but very bad if you're a
Linux distribution building packages for other people to use and now
have a broken or inferior package due to a desireable dependency being
disabled by mistake. I'm pretty sure there's no argument for keeping
this behavior when building Fedora packages.

We had originally forbidden the use of meson's auto features in GNOME
due to this problem (the automagic dependencies problem [1]), which
annoyed the Meson developers and led to the creation of this
-Dauto_features option. Now it's safe to recommend using auto features,
because we assume distros will build with -Dauto_features=enabled. With
this setting, if you want to disable a feature that's recommended by
upstream, you'll now have to explicitly disable it, which is surely
what we want to avoid features disappearing by mistake.

Then on the other end of the spectrum, -Dauto_features=disabled would
disable all auto features... that would make packagers responsible for
constantly monitoring the upstream feature set with every release and
making choices about what to enable or disable. It sounds like you
might be advocating this option, but that does not seem at all
practical to me. Packagers sometimes know better than upstream which
features should be enabled in Fedora, but not usually. And packagers
might sometimes audit the upstream feature list after new releases to
see if new features should be enabled... but that seems like a rarity
to me. If we use -Dauto_features=disabled, a bunch of important
features will go missing, and Fedora will suffer from that. So let's
trust upstream by default, and override where it makes sense.

Michael

[1]
https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Automagic_dependencies

___
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/message/QIRIH5QL6EP7YR4BW3N7CLH2C2MQO7HL/

Re: RFC: Pass --auto-features=enabled in meson

2018-07-23 Thread mcatanzaro

On Mon, Jul 23, 2018 at 4:44 PM, Igor Gnatenko 
 wrote:
I believe that for distribution we should make sure that all default 
features are enabled and if not, packager should explicitly disable 
feature. For instance when I was testing some RPM patches for new 
compression types, it was disabling some default feature because the 
configure script was written in a wrong way.


Yes, it's intended that distributions like Fedora build with 
-Dauto_features=enabled. We should definitely do so. Otherwise, 
desireable features will inevitably be disabled by mistake.


Michael

___
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/message/NYQUFTBOZLUU2WHZTQ2RDNYQIRCD4FBV/

Re: [HEADS UP] Removal of GCC from the buildroot

2018-07-23 Thread mcatanzaro


Another one, this time without any Vala:

https://bugzilla.redhat.com/show_bug.cgi?id=1606043
___
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/message/SRWNOFJVCW2RYWFEINSEZFYXF2TTUIFT/

Re: [HEADS UP] Removal of GCC from the buildroot

2018-07-20 Thread mcatanzaro

On Sun, Jul 8, 2018 at 1:46 PM, Igor Gnatenko 
 wrote:
As per Changes/Remove GCC from BuildRoot, I'm going to automatically 
add BuildRequires: gcc and/or BuildRequires: gcc-c++ to packages 
which fail to build with common messages (like gcc: command not 
found, also autotools/cmake/meson are supported).


I just got four bug reports for Vala projects that are failing due to 
missing GCC:


https://bugzilla.redhat.com/show_bug.cgi?id=1603972
https://bugzilla.redhat.com/show_bug.cgi?id=1604143
https://bugzilla.redhat.com/show_bug.cgi?id=1604150
https://bugzilla.redhat.com/show_bug.cgi?id=1604352

The error message is:

configure: error: in `/builddir/build/BUILD/five-or-more-3.28.0':
configure: error: no acceptable C compiler found in $PATH

Michael
___
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/message/JXSGEMOEQNBOC6XJSU4A2E5YUEK5OLE5/

Re: FESCo Elections - May 2018 : Results announcement

2018-06-20 Thread mcatanzaro

On Thu, Jun 14, 2018 at 11:13 AM, Matthew Miller
wrote:

There's another aspect of burnout: two years is a big commitment. In
the past, we've bad people who really were getting burned out or busy
with other commitments but who felt they couldn't really step down
without abandoning their responsibilities. If we did go to two year
terms, I'd rather see one year + automatic re-up if you want.

Semi-concrete-ish proposal: let's either do that, or do something
really similar.

Premise: we currently have too many open positions in too many
elections.

Under your proposal, we'll have one FESCo election per year, electing 4
or 5 seats at minimum, plus extra seats for any members who have
decided not to re-up. So there would be between four and nine seats
open in each yearly election, but generally I'd guess it would probably
be between five and seven. On the whole, I think this would be a
positive change, because decreasing election frequency will increase
the importance of the elections. There is a sweet spot between too
frequent and too rare, and my intuition says we are too frequent right
now. But there will probably be more open positions per election than
we have now, and that seems negative to me.

5-7 spots (up from 4-5 currently) is kind of a lot. We'll have reduced
the frequency of elections (good), but the elections we do have will be
busier and more complicated and harder to vote for (bad). I think it
would still be a net win, but I'll propose one more change to reduce
open spots: FESCo members get *two* automatic re-ups. This way, a FESCo
member could serve up to three years between elections if desired, but
there are still annual elections, and there is never any expectation of
serving more than one year: that's just something each member would
decide at the end of the year when it's time for new elections. Instead
of 5-7 open seats, my guess is we'd probably have more like 3-5,
depending on how many candidates decide to re-up, which is more in line
with today's elections. This should make the elections more
significant, and hopefully also easier for voters.

I could even support more re-ups than that, but I'll only propose two.
It seems like the sweet spot to me. We don't want to overcorrect and
wind up with too few open positions and too few elections. And we don't
want terms to be *too* long, because FESCo members should still be
responsive to the Fedora developer community.

Aside: we might also want to align elections to calendar years instead
of Fedora releases, since otherwise the schedule could get screwy if we
ever wind up getting too far off of the target May/October cycle.

Michael
___
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/message/VOFMJ5XQ6CTYR3QH3SLD3GUFGQJQELVG/

Re: FESCo Elections - May 2018 : Results announcement

2018-06-14 Thread mcatanzaro

On Thu, Jun 14, 2018 at 2:52 PM, Randy Barlow 
 wrote:

Another way to achieve a similar goal (fewer elections) is to have all
of FESCo swap in/out together, rather than tick-tocking 4 and 5 seats.
This way we keep a year long term, but also only one election per 
year.


I recommended against this, because:

we'd wind up with twice as many candidates on the ballot at each 
election, which would make the elections more confusing (more names 
to recognize, more candidate interviews to read) and could backfire 
on us (as I'd expect voters are more likely to vote in simpler 
elections).


I would guess that the more names there are on the ballot, the less 
likely voters will be inclined to vote. Choice paralysis!


Michael
___
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/message/356XLKO4PSKC4GIE7AN35SQJYEWMBQV2/

Re: FESCo Elections - May 2018 : Results announcement

2018-06-14 Thread mcatanzaro

On Thu, Jun 14, 2018 at 8:27 AM, Brian (bex) Exelbierd
wrote:
I've heard from several people (warning anecdata!) that they often
don't vote when they are happy with the way things are. One
person specifically said they didn't vote because they liked the
whole slate of candidates and were ok with whomever won.

I think that might have a lot to do with the turnout, indeed. I believe
there's a general perception in the community that FESCo has been doing
a good job, and there's not really any significant issues involved in
the election.

But also, consider election burnout. FESCo, Mindshare, and Council
elections, every six months or thereabouts... it turns out to be a lot,
right? We've had nine completed elections in the past year, or fourteen
if you count the five cancelled elections. [1] That's a quirk of our
releases not being exactly six months apart, but it's also kind of a
lot, right? Reading the interviews for the same candidates again and
again each year gets old pretty fast. So if we want to increase turnout
and improve our elections, the first thing I would do is make the
elections less frequent, to reduce voter burnout, e.g. once hold them
all once per year (for three elections per year) instead of twice per
year.

I would also double the terms served by the candidates (at least for
FESCo), since otherwise we'd wind up with twice as many candidates on
the ballot at each election, which would make the elections more
confusing (more names to recognize, more candidate interviews to read)
and could backfire on us (as I'd expect voters are more likely to vote
in simpler elections). Longer terms would also make the results of the
elections more consequential, i.e. it becomes more important to vote if
you care about FESCo because the people elected are going to be there
for two years instead of one.

Michael

[1] https://admin.fedoraproject.org/voting/archives
___
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/message/KSQHMOXFY5J2SZZWW6UYWQRGJK6NPCOD/

Re: F29 Self Contained Change: User PATH Prioritization

2018-06-07 Thread mcatanzaro

On Thu, Jun 7, 2018 at 4:59 AM, Zbigniew Jędrzejewski-Szmek 
 wrote:

I'm pretty sure ~/bin should be moved too. All the same considerations
apply to ~/bin as to ~/.local/bin, and having one at the beginning and
one at the end would be rather strange.


Yes, surely it makes no sense to change one but not the other. Thanks 
for pointing this out, Zbigniew.


Michael
___
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/message/PUXMP6ZPEKACSCQ7AXECPE4SJOR3VY2K/

Re: F29 System Wide Change: Strong crypto settings: phase 2

2018-06-06 Thread mcatanzaro

On Wed, Jun 6, 2018 at 4:39 AM, Nikos Mavrogiannopoulos 
 wrote:

I am actually very curious about the results of such a move, and know
whether it is going to have a significant impact today. Debian has
already tried experimenting with it:

https://lists.debian.org/debian-devel/2017/08/msg00166.html


But OpenSSL is not used by browsers.


I think the debate here is whether fedora (and in general operating
systems) can afford to be stricter than the browsers. As an OS our
attack surface is much larger than the browser setup, and thus it 
makes

sense (to me), to be more careful.


You previously said in this thread that the system policy *will* be 
used by browsers.


I would not be concerned if we had a separate policy that was suitable 
for use by browsers, which could be used by Firefox, glib-networking, 
etc. But we don't, and it's not proposed here.


Michael
___
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/message/QWP2MRLDBDGS4IS5C6NJHXCQDJSM4BQL/

Re: F29 System Wide Change: Strong crypto settings: phase 2

2018-06-05 Thread mcatanzaro


On Fri, Jun 1, 2018 at 6:40 AM, Jan Kurik  wrote:

and weak
Diffie-Hellman key exchange sizes (1024 bit)


What size is currently required by upstream Firefox and Chrome?

The most recent reference I could find is 
https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/WyGIpevBV1s 
which suggests they are still using 1024.


Michael
___
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/message/UGWSYDWBCTALCQ5B2MKYXFLKE47S7BCM/

Re: F29 System Wide Change: Strong crypto settings: phase 2

2018-06-05 Thread mcatanzaro

On Tue, Jun 5, 2018 at 4:14 AM, Nikos Mavrogiannopoulos 
 wrote:

Note that this change, if applied, includes browsers shipped by fedora
(i.e., firefox). That is pretty much all or nothing plan, either we
bump the defaults for all software, or for none.


Nikos, I'm really surprised to see you commenting here without saying 
anything for or against the change.


Surely this will break a large number of websites?

And, if not, then surely we should be able to first convince upstream 
Firefox and Chrome to drop support for TLS 1.0 and 1.1? I would not 
have any objections if these upstreams were to take the step first. Yet 
that seems extremely unlikely.


Michael
___
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/message/AQ5G7JYTQQHCXV6OEWUZ26YT35NCAX7M/

Re: F29 System Wide Change: Strong crypto settings: phase 2

On Fri, Jun 1, 2018 at 11:55 AM, Daniel P. Berrangé 
 wrote:
Yeah if you add the gnutls-glib-networking.config file in the RPM, 
that

defeats the point IMHO, as it'll never fallback to use @SYSTEM if this
file always exists with @GLIBNETWORKING defined in it.

The idea of the mechanism was that apps/libs build with @MYNAME,SYSTEM
priority but never define @MYNAME themselves, so it gives the local
sysadmin to customize the app/lib in isolation if they so wish, but
out of the box still respects @SYSTEM.


If @SYSTEM is changed as proposed, then glib-networking must not 
out-of-the-box respect @SYSTEM, because it needs to out-of-the-box 
work. :) So I guess we should just not use @SYSTEM then, yes?


I wonder what Tomas intends here.

Michael
___
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/message/UXJ6VAWQPN35HUHUCES4DKOQL32LWI5Y/

Re: F29 System Wide Change: Strong crypto settings: phase 2

On Fri, Jun 1, 2018 at 10:34 AM, Daniel P. Berrangé
wrote:
IIUC, glib-networking uses GNUTLS. If so, a while ago I added
ability to
specify an ordered list of named priority aliases to GNUTLS that
might handle

the kind of scenario you describe.

https://www.berrange.com/posts/2016/11/15/new-tls-algorithm-priority-config-for-libvirt-with-gnutls-on-fedora-25/

eg in libvirt we now use the string "@LIBVIRT,SYSTEM" in Fedora
builds which
tells GNUTLS to find the policy "LIBVIRT" and if that is not present,
fall

back to the "SYSTEM" policy.

We do this so libvirt respects system policy by default, but admins
can
then set an alternative system wide policy for libvirt connections
that

uses something stricter (or weaker), without affecting TLS usage for
non-libvirt connections. We've done the same for QEMU which
"@QEMU,SYSTEM"

as its default policy now, for VNC and its other TLS services.

OK... so we could add a @GLIBNETWORKING,SYSTEM policy, I suppose, and
install a file
/etc/crypto-policies/local.d/gnutls-glib-networking.config. The
difference is that file would need to be packaged, not controlled by
the system administrator. Seems almost like an abuse of a local.d?

Re: F29 System Wide Change: Strong crypto settings: phase 2

On Fri, Jun 1, 2018 at 8:06 AM, Daniel P. Berrangé 
 wrote:

What is the availibility of TLS 1.2 vs 1.1/1.0 on the internet ?
ie how likely is this to break the ability of users to access websites
they care about ?


Yeah... this has been discussed on this list before. If this change is 
made, then we will need to drop our glib-networking patch that causes 
glib-networking to respect Fedora's system crypto policy, since we 
simply cannot afford to be more restrictive than major browsers. I 
believe the system crypto policy developers should consider how this is 
really intended to work, because there's no point in having a system 
policy if software stops using it.


It could be doable if glib-networking was able to specify a priority 
string like @SYSTEMLEGACY insetad of just @SYSTEM, but the current 
design of the system crypto  policy prevents applications from choosing 
between the three policies.


Michael
___
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/message/A64V3LCMZALUDK4BFBKIXTEG2QC3EZVM/

Re: Firefox with native Wayland backend at updates