Re: LibreOffice packages

[Matthias Clasen]

Lets not make this a drama.

Package maintenance changes have never gone through change proposals.

> However, it surprises me that for a package, that is part of the 
deliverables of Fedora releases, no coordination effort was made to 
transition the package from Red Hat maintenance to Fedora maintenance.

My email is that effort.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

LibreOffice packages

[Matthias Clasen]

Hey, 

as you've probably seen, the LibreOffice RPMS have recently been orphaned, and 
I thought it would be good to explain the reasons
behind this.

The Red Hat Display Systems team (the team behind most of Red Hat’s desktop 
efforts) has maintained the LibreOffice packages in Fedora for years as part of 
our work to support LibreOffice for Red Hat Enterprise Linux. We are adjusting 
our engineering priorities for RHEL for Workstations and focusing on gaps in 
Wayland, building out HDR support, building out what’s needed for 
color-sensitive work, and a host of other refinements required by Workstation 
users. This is work that will improve the workstation experience for Fedora as 
well as RHEL users, and which, we hope, will be positively received by the 
entire Linux community. 

The tradeoff is that we are pivoting away from work we had been doing on 
desktop applications and will cease shipping LibreOffice as part of RHEL 
starting in a future RHEL version. This also limits our ability to maintain it 
in future versions of Fedora. 

We will continue to maintain LibreOffice in currently supported versions of 
RHEL (RHEL 7, 8 and 9) with needed CVEs and similar for the lifetime of those 
releases (as published on the Red Hat website). As part of that, the engineers 
doing that work will contribute some fixes upstream to ensure LibreOffice works 
better as a Flatpak, which we expect to be the way that most people consume 
LibreOffice in the long term. 

Any community member is of course free to take over maintenance, both for the 
RPMS in Fedora and the Fedora LibreOffice Flatpak, but be aware that this is a 
sizable block of packages and dependencies and a significant amount of work to 
keep up with.

Matthias
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

A late change proposal

[Matthias Clasen]

https://fedoraproject.org/wiki/Changes/UnfilteredFlathub

Before xmas, when the deadline for system-wide changes came near,
I flipped this change proposal to the ChangePageReadyForWrangler category,
and thereby send it to neverneverland, since the correct category is
ChangeReadyForWrangler :(

I've corrected that today, and I would like to ask that this feature could
maybe still be considered, even though it is late by now.

The reasons are:

- While this is flagged as a system-wide change, really the only
system-widge
   aspect here is policy (there are no releng or other coordination needs)

- This is not a new feature, it has been discussed before, so the discussion
  will hopefully be short and can focus on the changes we made to address
  the concerns from last time.

- It was submitted in time and only missed the deadline due to process
gotchas.

Matthias
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

[Matthias Clasen]

On Sat, Jan 7, 2023 at 9:31 AM Giuseppe Scrivano 
wrote:

>
> I've just opened a PR upstream for Podman to kill -9 all the remaining
> exec sessions when the container process terminates, so both --pid=host
> and --pid=private behaves in the same way.  It would solve the issue we
> are seeing.
>
>
That is fantastic. Thanks, Giuseppe!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

[Matthias Clasen]

On my Silverblue system, the main offender for this is podman.

As soon as I have a toolbox running, conmon holds up the reboot for a very
long time because it refuses to shutdown properly.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Matthias Clasen]

On Wed, Jul 6, 2022 at 3:06 PM Florian Weimer  wrote:


> If the GNOME's sysprof does not
> work with Fedora, fix it or use something else.  Do not change how
> Fedora is built.
>

The result of that attitude is that performance work in the desktop space
is happening
on GNOME OS images, or in Flatpak runtimes instead of on Fedora. Which is a
bit
sad for Fedora as a supposedly developer-friendly environment.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Matthias Clasen]

On Tue, Jul 5, 2022 at 3:40 PM Marek Polacek  wrote:

>
> Maybe not, but even ~1% is still an unacceptable slowdown.  It would take
> about a year for the compiler to catch up.
>
>
(Un)acceptable for whom?  And why would it be unacceptable?
You just said compilers will make up for it quickly, not to mention
hardware continuously getting faster too...

I haven't seen any convincing arguments as to why such a small
drop would be the end of the world.

And I don't think Fedora is or should be used in high-speed trading or
similar
environments where every microsecond matters.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Matthias Clasen]

On Thu, Jun 30, 2022 at 4:55 AM Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:

> Daan De Meyer via devel wrote:
> > Which shows a smaller than 1% slowdown between the binary built with
> frame
> > pointers and the binary built without frame pointers.
>
> I am still strongly opposed to degrading performance and size for all
> users
> just to help the handful users of poorly-designed profiling tools.
>
>
I am coming a bit late to this discussion, but I would like to inject the
viewpoint that 'performance' (however defined)
isn't the only criterion by which we should just judge what Fedora
produces. At least for Fedora Workstation, being
a useful system for developers with working debugging and profiling tools
should have some weight too.

And I doubt that you'd be able to notice a 'smaller than 1% slowdown' on
your system.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[Matthias Clasen]

On Mon, Jan 6, 2020 at 5:08 AM Lennart Poettering 
wrote:

>
> I mean, yes, the OOM killer might not be that great currently, but
> this sounds like something to fix in kernel land, and if that doesn't
> work out for some reason because kernel devs can't agree, then do it
> as fallback in userspace, but with sound input from the kernel folks,
> and the blessing of at least some of the kernel folks.
>
>
I agree that the implementation may need some work, but one thing should be
clear:
it is not a winning strategy to wait for the kernel folks to fix this. They
have for all practical
purposes given up on this problem, and are not going to solve the issue for
us.
___
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: Can we maybe reduce the set of packages we install by default a bit?

[Matthias Clasen]

On Tue, Apr 9, 2019 at 12:08 PM Lennart Poettering 
wrote:

> Heya,
>
> today I installed the current Fedora 30 Workstation beta on my new
> laptop. It was a bumpy ride, I must say (the partitioner (blivet?)
> crashed five times or so on me, always kicking me out of anaconda
> again, just because I wanted to undo something). But I don't really
> want to discuss that. What I do want to discuss is this:
>
>
>
> Ideally, the top 4 wouldn't be installed at all anymore (in case of
> the first two at least on the systems which do not need them). But if
> that's not in the cards, it would be great to at least not enable
> these services anymore in the default boot so that they are only a
> "systemctl enable" away for people who need them?
>
>
I think all of these are good ideas. "No udev-settle" seems like a nice
highlevel goal to shoot for.

Another one I might add: "No stuck stop jobs" - it annoys me every single
time when I reboot and something like rngd or conmon holds up my reboot
for several minutes for no reason 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: auto-starting libvirtd on Workstation

[Matthias Clasen]

I don't think we particularly need autostarting vms on the workstation. It 
would be very nice to get libvirtd activated. I know we've asked for this 
before...
___
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: CUPS will change license since 2.3 version - now incompatible with GPLv2

[Matthias Clasen]

On Wed, 2017-11-08 at 18:07 -0600, Michael Catanzaro wrote:
> On Wed, Nov 8, 2017 at 2:43 PM, Neal Gompa 
> wrote:
> > libkprint, kde-print-manager, etc. may have dependencies that make 
> > the mix impossible. I don't know for sure, though.
> 
> GTK+
> 

For GTK+, one possible answer is to rely on the flatpak print portal,
which moves the cups interaction out of process. It still requires to
figure out a way how to use a gtk with cups support in the portal
process.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: GNOME 3.25.92 megaupdate

[Matthias Clasen]

On Wed, 2017-09-06 at 14:02 +0200, Kalev Lember wrote:
> On 09/06/2017 01:22 PM, Tomasz Kłoczko wrote:
> > [tkloczko@domek SPECS.fedora]$ grep filetrigger * | grep icons
> > adwaita-icon-theme.spec:%transfiletriggerin --
> > %{_datadir}/icons/Adwaita
> > adwaita-icon-theme.spec:%transfiletriggerpostun --
> > %{_datadir}/icons/Adwaita
> > gnome-icon-theme.spec:%transfiletriggerin --
> > %{_datadir}/icons/gnome
> > gnome-icon-theme.spec:%transfiletriggerpostun --
> > %{_datadir}/icons/gnome
> > gnome-themes-standard.spec:%transfiletriggerin --
> > %{_datadir}/icons/HighContrast
> > gnome-themes-standard.spec:%transfiletriggerpostun --
> > %{_datadir}/icons/HighContrast
> > hicolor-icon-theme.spec:%transfiletriggerin --
> > %{_datadir}/icons/hicolor
> > hicolor-icon-theme.spec:%transfiletriggerpostun --
> > %{_datadir}/icons/hicolor
> >  
> > Seems like packages installing other themes *already* are doing
> > exactly
> > what I've been thinking that they should be doing so updating per
> > icon
> > theme strategy should be OK.
> 
> Right, I added file triggers to all gnome-related icon themes last
> cycle
> with the plan to delete the scriptlets from individual packages soon.
> I
> can add the triggers to KDE and other themes as well if their
> maintainers are fine with it. rdieter?

Lets try to bring some clarity into this. The only 'drop dir' icon
theme is hicolor - applications are expected to install their app icons
there, which is why we need a file trigger to update the icon cache for
this theme when an unrelated package places new content there.

Other themes should be entirely self-contained within their package.
Apps have no business dropping icons intio Adwaita or HighContrast, so
it really is not necessary to have file triggers for those themes,
afaics.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Nested rich-dependencies in rpm

[Matthias Clasen]

On Wed, 2017-04-12 at 18:20 +0200, Björn 'besser82' Esser wrote:
> 
> > 
> > @Björn: Do you know how libyui chooses the toolkit?
> 
> Yes.  Libyui performs a check on init of ui whether it's running on
> a 
> TTY or not:
> 
>  if TTY it instantly uses libyui-ncurses
>  else it *tries* to load - and uses the first available - 
> GUI-backend in the following order:
> 
>  libyui-qt
>  libyui-gtk
>  libyui-ncurses
> 
> If it cannot load any backend or cannot open a TTY in case of 
> libyui-ncurses, it throws an error and shuts down the ui.
> 

To throw in my 2c as gtk maintainer: I'd rather have a well-written qt
app on my desktop than something that relies on fragile toolkit
abstraction layers like this. Both gtk and qt are already abstractions.
Adding another one on top does not make things better, most of the
time...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: flatpak app launch script

[Matthias Clasen]

On Wed, 2017-02-01 at 14:26 +0100, Martin Kolman wrote:
> On Wed, 2017-02-01 at 07:16 -0600, Michael Catanzaro wrote:
> > On Wed, 2017-02-01 at 13:46 +0100, Martin Kolman wrote:
> > > Can you pass command line arguments like this ? For example
> > > inkscape
> > > can be used not only as a GUI app, but also from the command line
> > > to
> > > convert SVG files to PNG and other things. So it would be good if
> > > flatpack can also support that.
> > 
> > Yes. Arguments to flatpak go before the name of the app to launch,
> > arguments to the app go after.
> 
> Nice! It's good to know it already works. :)
> 
> BTW, what about sandboxing & file access ?
> 
> Let's say I try to run (a hypothetical) example:
> 
> flatpak run com.example.inkscape --svg-to-png /home/user/foo.svg
> 
> As the file is outside of the sandbox what will happen ? Will it fail
> to access the file or will the user be asked to confirm access to it
> ? 
> 
> I guess one could also just enable $HOME access for the app in a case
> like this, but still.

I've filed https://github.com/flatpak/flatpak/issues/543 for a related
issue in desktop file Exec lines.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Nautilus usability

[Matthias Clasen]

On Tue, 2016-11-29 at 14:40 +0100, Michael Schwendt wrote:
> On Mon, 28 Nov 2016 15:26:50 +0100, Jiri Eischmann wrote:
> 
> > I'm missing a link to a bug report here.
> 
> Blame the bad experience I've made with tickets at
> bugzilla.gnome.org.
> 
> There is no reason to believe that the Nautilus devs aren't happy
> with
> the feature set, or else I cannot explain why this progress window
> feature has been created exactly like this.

You are just making assumptions about the nautilus developers here.


> At most I could file an RFE. A waste of time without prior
> discussion,
> in my point of view.

Discussion with whom ? If you hope to achieve any change, involving the
people who wrote the code would be helpful, and this list is not the
place where you will achieve that...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: systemd 230 change - KillUserProcesses defaults to yes

[Matthias Clasen]

On Thu, 2016-06-02 at 14:19 -0400, Paul Wouters wrote:
> > 
> > On Jun 1, 2016, at 09:48, Lennart Poettering wrote:
> > 
> > Any scheme that relies on unprivileged programs "being nice"
> > doesn't
> > fix the inherent security problem: after logout a user should not
> > be
> > able consume further runtime resources on the system, regardless if
> > he
> > does that because of a bug or on purpose.
> 
> You are redefining the meaning of (a graphical) logout. It simply
> means another user can use the mouse,
> keyboard and screen of this device. It makes no statement on whether
> the machines resources are shared or not.   
> 
> It allows you to kill anything that has to do with the user
> controlling the screen, keyboard and mouse but the killing should be
> limited to those processes. And then we are back at "just fix those
> broken processes".

I think the discussion is starting to go in circles. It is pretty clear
that we have different opinions about the desired behavior of logout.

--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: systemd 230 change - KillUserProcesses defaults to yes

[Matthias Clasen]

On Thu, 2016-06-02 at 10:02 -0400, Paul Wouters wrote:
> 
> People aren't agreeing with you. So making it a default seems like a
> bad
> idea. People do seem to agree on "obviously broken windoing apps"
> that
> are left lingering. Why can't we just let those get killed?
> 

You are misinformed. This is not about 'obviously broken' windowing
apps. Applications that have X or wayland connections get killed
reliably when the session ends, because that connection is going away.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: gnome-software integration

[Matthias Clasen]

> xiphos-gtk2.rpm:
> /usr/bin/xiphos-gtk2
> /usr/share/appdata/xiphos-gtk2.appdata.xml
> /usr/share/applications/xiphos-gtk2.desktop
> 
> xiphos-gtk3.rpm:
> /usr/bin/xiphos-gtk3
> /usr/share/appdata/xiphos-gtk3.appdata.xml
> /usr/share/applications/xiphos-gtk3.desktop

I have to ask though: is it really worth shipping 2 copies of the
application ? I would suggest to just ship one of them.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: systemd 230 change - KillUserProcesses defaults to yes

[Matthias Clasen]

On Wed, 2016-06-01 at 09:59 -0400, Matthew Miller wrote:

> 
> This paints a very specific premise of what a "logout" is, and I'm
> not
> sure I agree with it. There are actually many cases where I want to
> use
> resources on systems I have accounts on without specifically being
> logged in — the login session is just a connection in to manage
> things.
> 
> Otherwise, we should remove user crontabs, at, and similar.  And
> there
> are definitely some systems where that policy has a place, but I
> don't
> see it making sense as Fedora default, either system wide or for any
> of
> the Editions.
> 

Explicitly marking things to escape the session (nohup, crontab,
starting system services, etc) is very different from just leaking any
and all non-terminating processes out of the session.

I am very much in favor of systemd enforcing that the session actually
ends when I log out, so that I don't accidentally leave processes
running. Leaking session processes have been a perennial problem that
we have been battling forever (gconf, ibus, pulseaudio, the list goes
on...). And they are causing actual problems, from preventing re-login
to subtly breaking the next session to slowing down shutdown.

That doesn't mean that you can't have user crontabs. As Lennart says,
using those mechanisms should ideally be a privileged operation (with a
lenient policy on single-user systems).


Matthias
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: What to do with application that only works in some desktops

[Matthias Clasen]

On Tue, 2016-05-31 at 18:54 +0200, Göran Uddeborg wrote:
> Hello!
> 
> I would like to ask for some help what to do with
> https://bugzilla.redhat.com/show_bug.cgi?id=1324881  I've been
> pondering it for some time, but I know too little to know what to do.
> 
> It's about the old amusement xpenguins.  (A program showing small
> penguins walking on the windows and jumping between them.)  As can be
> seen in the bug report, it doesn't show anything in e.g. Gnome.  From
> what I understand this is because Gnome doesn't show the actual X
> root
> window.  It has a second window covering the entire screen as
> background, and this window hides all the penguins.
> 
> A first question is if this is indeed correct?
> 
> If so, could anyone describe it in more technically correct terms.  I
> would like to write a warning about the issue in the description of
> the package.

I would suggest something like:

xpenguins works by drawing on the X root window. This is a cute hack
that might not have the desired effect in modern desktop environments
where the root window is not visible.

> 
> But a problem is that "NotShowIn=GNOME;" doesn't seem to have any
> effect in the current Gnome version.  There is no menu to exclude
> xpenguins from, and when I try it seems just as available regardless
> of that setting.  As you may have guessed I'm not a regular Gnome
> user, but that is what I see when I test it.
> 
> So a second question is if anyone has any advice on how to best
> handle
> this?  How to best make sure Gnome users don't get fooled to use a
> program that do not work in their environment.

How did you determine that NotShowIn=GNOME; doesn't have any effect?
It should work fine to hide xpenguins from the places where
applications are normally listed in GNOME (the shell overview and
search).
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: best approach for cleaning package metadata cache for old versions on upgrade?

[Matthias Clasen]

On Fri, 2016-04-15 at 09:08 -0400, Honza Šilhan wrote:

> Do you think you can remove cache of any package without the crash?
> I remember cleaning cache for docker (even after properly deleting
> the saved
> images) and I was not able to get it work again.

Thats part of the semantics of /var/cache/, isn't it ?

If you place something there, you are basically saying: Removing this
won't affect the functionality of this package. 
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: best approach for cleaning package metadata cache for old versions on upgrade?

[Matthias Clasen]

On Thu, 2016-04-14 at 12:51 -0400, Matthew Miller wrote:
> There is a thread on the users' list * dealing with the issue that
> after an upgrade, there's no non-obscure way to clean cached metadata
> (or packages, even) from previous releases. The thread discussses DNF
> and Yum, but it may apply to PackageKit/Software as well; I'm not
> sure
> offhand.
> 
> It seems like we should handle this in some way on upgrade. My first
> thought was to make it an RFE dnf-plugin-system-upgrade. But, is that
> the right place? Maybe some time-base system should prune metadata
> associated with repositories for any earlier $releasever? (Or,
> actually, maybe for any repository which does not match a current
> configuration?) Or maybe a "dumb" process to sweep the cache based on
> age alone would do?
> 

If you put it in the dnf plugin, you leave out the new graphical
upgrade that is coming in F24.

It is also not really dnf-specific at all. Other apps or services may
leave stuff behind in /var/cache too. One radical, but simple approach
would be to simply rm -rf /var/cache after the upgrade. That would give
you a system that is a bit closer to 'freshly installed' state.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Firefox not working anymore over ssh?

[Matthias Clasen]

On Mon, 2016-04-04 at 15:23 -0500, Michael Catanzaro wrote:
> On Mon, 2016-04-04 at 13:56 -0600, Kevin Fenzi wrote:
> > 
> > It does. 
> > 
> > Also, I haven't seen any of the breakage in webkit mentioned in
> > this
> > thread here with a skylake laptop. 
> The bug only occurs in accelerated compositing (OpenGL) mode, which
> is
> currently only used when necessary to support a particular web page
> (e.g. GitHub commit diffs, or search results on DuckDuckGo). Ongoing
> work is to make accelerated compositing mode mandatory and use it on
> all web pages. Once this work lands, modesetting driver users will
> need
> to disable DRI3 in order to practically use WebKit.

Once again goes to show how problematic it is to use web rendering
stacks from browsers in other places: Now we have an initial setup tool
that depends on GL+DRI3 working just because it needs to render two
entries in a webpage :-(
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Firefox not working anymore over ssh?

[Matthias Clasen]

On Sat, 2016-04-02 at 09:17 -0500, Michael Catanzaro wrote:

> > 
> > So if there are issues with WebKit they should be fixed. "It can't
> > work lets go back to DRI2" isn't really an option in the long run
> It would be great if somebody would fix this. I just want to give a
> heads-up that we are not going to delay architectural improvements in
> WebKit for just DRI3 plus modesetting driver, and that this is going
> to
> render lots of apps totally unusable (gnome-initial-setup, gnome-
> online-accounts, Evolution, etc.) possibly in the F25/F26 timeframe
> if
> this isn't resolved.
> 

That seems to be a bit over-dramatic. gnome-initial-setup works fine.
The online accounts step will be affected, but that's about it.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: GNOME 3.19.92 megaupdate

[Matthias Clasen]

On Tue, 2016-03-15 at 13:06 +0100, Vít Ondruch wrote:
> So do you see any solution/improvement for this issue? I repeatedly
> reported the breakages, I made some proposals (as simple as "send an
> email"), which IMO should improve the situation, but it seems that
> you
> prefer to keep status quo.

A solution would be to have rawhide gated by some form of minimal auto-
qa that keeps such breakage out of composes.

Asking the people who already do a _ton of work+ to get all these
builds done in multiple streams to do even more work, and asking in an
accusatory tone, is probably not going to lead to a solution.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Gnome always broken in Rawhide

[Matthias Clasen]

On Fri, 2016-01-22 at 12:37 +0100, Vít Ondruch wrote:
> Hi everybody,
> 
> I am wondering why the Gnome updates in Rawhide has to be always
> broken?
> Today I updated my computer just to find out that my gnome-shell is
> crashing instantly. As it turned out, majority of Gnome components
> were
> at 3.19.4 version but gnome-shell was at 3.19.3. Yes, there is
> already
> gnome-shell 3.19.4 in Koji, which fixes the crashes, but I really
> don't
> understand, why you don't build the Gnome in a side tag or why the
> dependencies are not more strict to prevent the broken update?

We typically do use a side tag after branching, when bodhi updates make
it much more practical to enforce batched updates.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Proposal to reduce anti-bundling requirements

[Matthias Clasen]

On Wed, 2015-09-30 at 08:13 -0600, Orion Poplawski wrote:

> 
> I'd just like to point out that we have always had the requirement
> for 
> package that bundled libraries to carry the "Provides:
> bundled(libname)" 
> metadata.  What's new here is not needing to go through the FPC to
> get 
> an exception.  Which perhaps leads to people not declaring their 
> packages bundled libraries.
> 

The only way to ever make declaration of bundling reliable is to
automate it somehow.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 cloud image (and, for that matter, minimal anything) bloat

[Matthias Clasen]

On Thu, 2015-09-24 at 11:00 -0400, Adam Jackson wrote:
> On Thu, 2015-09-24 at 00:59 +, Zbigniew Jędrzejewski-Szmek wrote:
> 
> > Bummer. The reason for libxkbcommon dependency is to be able to
> > make
> > sure that the new config is valid. Before that was added we had a
> > set
> > of rules and heuristics implemented in localed and regular bug
> > reports
> > when typos and other mistakes were not caught by localed but Xorg
> > would not accept the new config. This is more important than might
> > seem, 'cause people tend to get grumpy when a misconfigured
> > keyboard
> > mapping prevents them from typing in their password. So this
> > dependency
> > does bring useful functionality.
> 
> We can certainly make xkeyboard-config smaller. About half its on-
> disk
> footprint is localized strings, %langpack would help. The geometry
> subdir is completely useless, and I'm reasonably sure the xml it
> installs is really just source data and not anything apps or libs
> use.
> All told that'd get xkeyboard-config down to a hair over 2M on disk.
> 

Not saying that it is very useful, but I believe gkbd-keyboard-display
does use geometry information.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Disable PulseAudio flat volumes to prevent it from pushing volume level to max

[Matthias Clasen]

On Tue, 2015-09-22 at 05:31 -0500, kendell clark wrote:
> hi
> I'm ambivolent on the subject. If flat volumes become a problem, I
> know
> how to turn them off. However, I think because of all the complaints
> here by people who have a very good track record and don't complain
> often, this seems to bear out what I've been trying to say.

You can't really draw too many conclusions from the fact that people
complain on this list - its what you do on this list. Other people with
good track record who don't have a problem with volume handling (like
me) will not show up here to praise and defend PA.

Now, we should certainly look at ways to improve the situation, but
that that will require talking to PA developers...

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Disable PulseAudio flat volumes to prevent it from pushing volume level to max

[Matthias Clasen]

On Tue, 2015-09-22 at 15:51 +0200, Lennart Poettering wrote:
> On Thu, 17.09.15 20:59, Germano Massullo (germano.massu...@gmail.com)
> wrote:
> 
> > Today I had a scary experience with the audio of my computer.
> > I was listening to music with Amarok, using my headphones... The
> > KMix
> > volume level was ~ 35%. When I logged into a video conference
> > application, the volume suddenly reached the 100%. I was shocked,
> > having
> > the maximum audio level shooted in your ears is a painful
> > experience.
> > The conference application that triggered PulseAudio pushing volume
> > to
> > maximum level probably should have never asked the system for a
> > 100%
> > audio level, but on the other hand, PulseAudio should never allow
> > an
> > application to make such sudden changes.
> > To avoid that, you have to set
> > flat-volumes = no
> > in /etc/pulse/daemon.conf
> 
> This is a non-sensical request. If an app uses the mixer APIs to set
> the volume of something to very loud, that's what happens. Flat
> volumes have nothing to do with that.
> 
> I mean, the app you are using shouldn't set the volume like this, and
> that's the key here. If you turn off flat volumes you win about
> nothing, you just work around this specific app. Soon the next app
> will come along and play the same game with the actual device volume,
> and you won *zero*.
> 
> Don't mix flat volumes with misbheaving apps. Turning off flat
> volumes
> is a hack around the broken apps at best, and completely pointless..

For better or worse, misbehaving apps are a reality that is probably
not going to go away... I think we need to have a volume control
approach that is at least somewhat tolerant against such apps and has
some safeguards.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora Ring 0 definition

[Matthias Clasen]

On Wed, 2015-09-02 at 15:24 -0400, Josh Boyer wrote:

> (Also, the original definition included Anaconda because you need
> something to actually install Fedora Ring 0 with and that brought in
> GTK, etc).)

I think 'not self-hosting' should be understood to imply 'not self-
installing' - ie don't pull in anaconda.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [HEADS UP] rpm-4.12.90 in rawhide

[Matthias Clasen]

On Wed, 2015-07-29 at 09:49 +0200, Vít Ondruch wrote:
 Dne 28.7.2015 v 18:15 Matthias Clasen napsal(a):
  On Tue, 2015-07-28 at 14:49 +0200, Vít Ondruch wrote:
  
   Just out of curiosity, do you have already any candidates for 
   File 
   Triggers? I suppose /sbin/ldconfig is one of them. Do you plan 
   to 
   have some F24 feature to get rid of these?
  Here is a list of candidates:
  
  https://fedoraproject.org/wiki/Workstation/Tasklist#filetrigger
 
 Workstation WG is keeping an eye on this. Very nice. Thank you.

As a test balloon, I've now added file triggers to gdk-pixbuf2-2.31.5
-2.fc24, and librsvg2-2.40.9-3.fc24 now relies on them to get its
pixbuf loader registered. 

Let me know if you see any problems with those updates that might be
caused by the file triggers.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: and legacy software Re: pyorbit

[Matthias Clasen]

On Sat, 2015-08-01 at 03:24 +0200, Kevin Kofler wrote:
 Bastien Nocera wrote:
  You're just 8 years late for noticing that:
  https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/xse
  ttings/gsd-xsettings-manager.c#n79
  and the explanation has been here for 4 years.
 
 That is not the place I was talking about. That is the gnome-settings
 -daemon 
 default, it only applies when you're running gnome-settings-daemon as 
 your 
 XSettings manager (i.e., basically only under GNOME). I'm talking 
 about the 
 toolkit default inside GTK+ 3, which is used if the XSetting is NOT 
 set. 
 That is what recently changed. xsettings-kde, the XSettings manager 
 running 
 in KDE Plasma sessions, expects the toolkit to honor the hardware DPI 
 if the 
 relevant XSetting is not set, as Qt does. It only sets an explicit 
 DPI value 
 if the user set an explicit DPI value in KDE System Settings. So GTK+ 
 3 now 
 displays with the wrong font sizes in KDE Plasma sessions.

In other words, xsettings-kde makes unjustified assumptions, and you
blame gtk.

But before we drop this as leading nowhere: what is the hardware dpi
you're talking about ? Should I use the value that cairo tells me ? Or
fontconfig ? or x resources ? or the display size ? or parse the edid
data myself ?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: and legacy software Re: pyorbit

[Matthias Clasen]

On Wed, 2015-07-29 at 12:47 +0200, Michael Schwendt wrote:
 On Tue, 28 Jul 2015 21:27:45 +0100, Sérgio Basto wrote:
 
  As I have thought for some time,  I think we should have a team to 
  keep
  packages and make migrations like gtk2 to gkt3, libgnome2, pyorbit,
  gnome-python2, pyhton2 to python3 , qt3 etc etc
 
 Wishful thinking. Porting from gtk2 to gtk3 is non-trivial or not 
 even
 feasible in all cases (without dropping some 
 features/implementations).
 Some developers are unhappy with gtk3. Others switch to Qt.

There is little reason to switch from gtk2 to gtk3 if you are happy
with gtk2 and don't want any newfangled stuff. gtk2 will be maintained
for the forseeable future.

Its a different story for the other GNOME2 era libraries mentioned
here: libgnome, orbit, gnome-python2 - porting away from those is long
-overdue if you haven't yet.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [HEADS UP] rpm-4.12.90 in rawhide

[Matthias Clasen]

On Tue, 2015-07-28 at 14:49 +0200, Vít Ondruch wrote:

 Just out of curiosity, do you have already any candidates for File 
 Triggers? I suppose /sbin/ldconfig is one of them. Do you plan to 
 have some F24 feature to get rid of these?

Here is a list of candidates:

https://fedoraproject.org/wiki/Workstation/Tasklist#filetrigger
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal: Drop comps

[Matthias Clasen]

On Tue, 2015-07-14 at 10:13 +0200, Vít Ondruch wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 Can we just drop comps entirely (or at least trim them down 
 significantly)? I know that this will not happen from day to day, but 
 I see the comps just as an ugly workaround for missing weak 
 dependencies, which we have now.

I've always thought that comps is just an ugly extra layer that only
adds more work and indirection, and few if any benefits. So, I welcome
this suggestion. Of course, as with all extra layers, once it is there,
it tends to accrete random functionality. As others have pointed out in
this thread, comps has things such as the (still mysterious to me)
environment groups, and some translated strings. I don't think any of
the examples that were mentioned so far would make me go yes, we
should really have an xml file look-aside somewhere to hold this
functionality.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnssec-trigger + GNOME + NetworkManager integration

[Matthias Clasen]

On Tue, 2015-06-23 at 18:43 +0200, Tomas Hozza wrote:

Hey, I was out for a week, so this may be a bit of a late reply.

As Michael and Bastien already stated, all the GNOME networking UI
relies on information gotten from NetworkManager, and we'd like to keep
it that way. In particular, NetworkManager has an existing API to
inform us about captive portals - if at all possible, you should keep
that working.

[...]

 This boils down to what we need from some new version of the UI that 
 we
 need to be well integrated with GNOME:

 1. Be able to inform user about some situations (Captive portal
 detected, network blocks all DNS communication, ...) and enable the 
 user
 to take an action. (This could be possibly done by the notifications
 system in latest GNOME)

 - this may be solved also in GNOME already, and may be OK if done
 technically correctly. Please note my note earlier on NM notifying 
 other
 services when Captive Portal is detected

My perspective on this is that we already have a UI: GNOME shell
displays network status, including captive portal. If NetworkManager
needs to add a few more connection states related to DNSSEC, we can
adapt to that.

GNOME shell also launches a browser when needed for captive portal
login. If we need to tweak the way the browser is launched to make it
work on a dnssec-enabled system, that should be possible.

 2. Possibly have some indicator showing if the system is in Secure 
 or
 Insecure state.
 
 3. Enable the user to switch between those two states manually

This seems dubious, at best. What does it mean if my system is
'insecure' ? Will my credit card number be stolen ? Will my system be
taken over by intruders if I don't disconnect immediately ? Most users
will have no idea, and have to treat such a switch either as scary,
don't touch or as the fix the internet button.

I could see adding information regarding the dnssec status of
connections to the network panel. For that to happen, the information
needs to be represented in the nm connection configuration, e.g. in
NmSettingIP4Config, which already has settings like ignore-auto-dns.

 4. Additionally enable the user to trigger the reprobe of
 connection-provided DNS resolvers and display result of the probe 
 (last
 one).
 
 - this should not be needed for regular use. It is more of a 
 debugging tool

I would encourage you to ship it separately as such, then. I don't even
think it needs to be a graphical tool, a commandline utility would be
just fine for this purpose.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F23 Self Contained Change: Standardized Passphrase Policy

[Matthias Clasen]

On Tue, 2015-06-23 at 12:21 -0400, Jan Kurik wrote:
 = Proposed Self Contained Change: Standardized Passphrase Policy =
 https://fedoraproject.org/wiki/Changes/Standardized_passphrase_policy
 
 Change owner(s):
 * Kevin Fenzi kevin at scrye dot com
 * David Cantrell dcantrell at redhat dot com
 * Tomas Mraz tmraz at redhat dot com 
 
 Currently a number of places ask users to set passphrases/passwords. 
 Some of them enforce some kind of rules for passphrases/passwords, 
 others different rules. This change would create a common base policy 
 for as many of these applications as possible, allowing for local 
 users or products to override this base in cases they need to do so. 

But passwords and passphrases are not all the same shape or color - the
requirements for a password you want to use for ssh login over the
internet are quite different from ones for a shared account used by all
family members, or a passphrase that you use to protect your diary in
your home directory.

How does a single common policy make sense for such wildly different
use cases ?

Your list of applications looks like you are really only interested in
passwords for local user accounts, though. If that is the case, please
make that clear in the description.

[...]

 The applications involved in this change should be at least:
 * anaconda - sets initial root and user passphrases/passwords. 
 * passwd - command line utility that changes passphrases/passwords. 
 * initial-setup - sets up users if they were not setup in anaconda. 

You should add gnome-control-center to this list.

 * libpwquality - doesn't set passwords, but should be used in common 
 for quality checking in a consistent manner. 

All of the applications that you are listing are already using
libpwquality, which has not really helped to move us to a consistent
user experience in this area. We should evaluate if libpwquality is
really suitable for what we need here. 


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F23 System Wide Change: Default Local DNS Resolver

[Matthias Clasen]

On Fri, 2015-06-12 at 09:57 -0400, Paul Wouters wrote:
 On Fri, 12 Jun 2015, Matthias Clasen wrote:
 
  I've just installed dnssec-trigger on rawhide to try this out, and
  found that it breaks networking on my Workstation. I used to get a
  network connection on login, now I get a question mark in top bar, 
  and
  a status icon with obsure menu options appears.
 
 Did your networking actually break, or just the notification icon 
 status?
 Is the unbound service running?
 Is the dnssec-triggerd service running?
 
 I have noticed that the network status icon in the top right has 
 never
 worked for me in at least a year. It sometimes says ? when I have
 proper network connectivity and sometimes shows the wifi waves when
 I do not have network connectivity. I did not realise this might have
 been due to dnssec-triggerd/unbound.

Maybe that is because you play too much with DNSSEC ? :-) It works
pretty reliably for me and we don't have a huge influx of 'network
status is broken' bugs which we would have if it was as broken as you
say...
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F23 System Wide Change: Default Local DNS Resolver

[Matthias Clasen]

On Fri, 2015-06-12 at 10:58 +0200, Tomas Hozza wrote:
 
  3. NM waits for some signal from unbound/dnssec-trigger about the
  trustability of the DNS server
 
 If you think NM needs to do some action (as I don't), we don't have
 problem with notifying NM (if you provide some API).
 

This is your feature, so you are responsible for making sure that it
does not break the rest of the OS, not the other way around...

I've just installed dnssec-trigger on rawhide to try this out, and
found that it breaks networking on my Workstation. I used to get a
network connection on login, now I get a question mark in top bar, and
a status icon with obsure menu options appears. This is quite a
contrast from what the Change page says: Users shouldn't notice this
change at all.

The OS integration of this feature is clearly not done.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Changes in the f22 workstation

[Matthias Clasen]

On Mon, 2015-03-09 at 12:31 +0100, Vít Ondruch wrote:
 Dne 20.2.2015 v 22:09 Matthias Clasen napsal(a):
  I wanted to give a heads-up to the wider audience about a number 
  of  workstation changes that are landing in the f22 branch (and 
  rawhide)  this week, in time for the alpha freeze next week:
  
  - The message tray at the bottom is gone, notifications are now 
  shown 
  at the top, and can be reviewed in the calendar popup (
  https://fedoraproject.org/wiki/Changes/GnomeShell_NewNotifications)
  
 
 Unfortunately, this is rather half baked, especially the Empathy 
 integration. Why I can reply just to notifications which are just on 
 the screen? Why I can't reply to notifications, which are already 
 hidden in calendar popup? Moreover, once there is empathy 
 notification, it is not obvious if next message arrived or not. I 
 quite often miss new messages now :(

The notification rewrite was a major change, some fallout has to be 
expected... we're working through these items now. Revisiting chat 
notifications in on the todo list before 3.16. Thanks for your 
feedback!

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Changes in the f22 workstation

[Matthias Clasen]

I wanted to give a heads-up to the wider audience about a number of 
workstation changes that are landing in the f22 branch (and rawhide) 
this week, in time for the alpha freeze next week:

- The message tray at the bottom is gone, notifications are now shown 
at the top, and can be reviewed in the calendar popup (
https://fedoraproject.org/wiki/Changes/GnomeShell_NewNotifications)

- The gnome-shell theme has been refreshed

- The login screen is using Wayland (
https://fedoraproject.org/wiki/Changes/Login_Screen_Over_Wayland)

- Codec installation has been integrated in gnome-software (currently 
this is hooked up in totem)

- Nautilus has received a number of improvements (
https://fedoraproject.org/wiki/Changes/Nautilus_Improvements)

Please let us know if you see any fallout from these changes.


Thanks! Matthias

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: another input/output question (libinput / pulseaudio / ....)

[Matthias Clasen]

On Mon, 2015-02-09 at 08:44 +1000, Peter Hutterer wrote:

 However, especially for libinput, it gets hazy and also mostly pointless.
 aside from some special processing required for touchpads and tablets, we
 don't care much _what_ a device is, we just pass on the events.  If a device
 has keys, it'll be a keyboard. if it sents KEY_MUTE we pass that on, the
 compositor/X stack will then handle that however need be. There's no real
 benefit to us trying to figure out what is a headset and what isn't, we'd
 still just pass on the keys.

Fair enough. One thing that is important, though, is to preserve enough
information about the originating device (and the general device
topology) that higher levels have a chance to do the right thing (e.g.
mute the headset and not the speakers, if that is where the mute button
is).

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: FESCo Elections results

[Matthias Clasen]

On Thu, 2015-02-05 at 14:52 +0100, Kevin Kofler wrote:
 Jaroslav Reznik wrote:
# votes |  name
  - +--
  1427  | Kevin Fenzi
  1247  | Adam Jackson
   919  | Tomas Hozza
   818  | Parag Nemade
   617  | Debarshi Ray ← GNOME developer
  - +--
   540  | Alberto Ruiz ← GNOME developer
   441  | David King ← GNOME developer
 
 What does this tell you? :-)

It should tell you that we care enough about Fedora to put our names on
the ballot.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: DNF replacing yum: fedup?

[Matthias Clasen]

On Tue, 2015-01-27 at 01:26 +, Naheem Zaffar wrote:
 
 
 On 26 January 2015 at 22:52, Will Woods wwo...@redhat.com wrote:
 
 (As an aside, PackageKit should also support these operations,
 so we can
 use PackageKit to make a Upgrade GUI Thing.)
 
 
 Gnome Software has had some interesting work done in the 3.16 cycle to
 handle upgrades.

This sounds like a legend in the making.

We have looked at this, and we have initial designs for how this could
look, but no code has been written yet.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F22 Self Contained Change: Gnome Shell - New Notifications

[Matthias Clasen]

On Wed, 2015-01-14 at 13:24 +, Peter Robinson wrote:
 On Wed, Jan 14, 2015 at 1:17 PM, Pierre-Yves Chibon pin...@pingoured.fr 
 wrote:
  On Wed, Jan 14, 2015 at 01:00:27PM +0100, Jaroslav Reznik wrote:
  = Proposed Self Contained Change: Gnome Shell - New Notifications =
  https://fedoraproject.org/wiki/Changes/GnomeShell_NewNotifications
 
  Change owner(s): Florian Müllner fmuel...@redhat.com
 
  Redesign the way in which notifications are shown and kept available in 
  gnome-
  shell.
 
  == Detailed Description ==
  The message tray is one of the remaining weaker points of the original 
  gnome-
  shell design. This change will replace it with a new implementation of
  notifications that avoids the problems of the current implementation.
 
  Is there a place where the detailed description is more detailed?
  A wiki page on gnome.org maybe listing the current problems and the new 
  approach
  taken?
  I'm curious and would like to read more about this :)
 
 Allan Day, one of the gnome designers, did a pretty good overview in a
 couple of blog posts.
 
 http://blogs.gnome.org/aday/2014/06/18/a-notifications-update/

Good point - I've added that link to the page now.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Schedule for Wednesday's FESCo meeting (2014-12-17 at 18UTC)

[Matthias Clasen]

On Wed, 2014-12-17 at 04:33 -0500, Bastien Nocera wrote:
 Hey,
 
 - Original Message -
  
  Following is the list of topics that will be discussed in the FESCo
  meeting tomorrow at 18:00UTC in #fedora-meeting on
  irc.freenode.net.
  
 snip
  #topic ticket #1372 Workstation Product defaults to wide-open firewall
  .fesco 1372
 
 I'm not going to be around for this, as I'll be on a plane. Hopefully somebody
 from the Workstation WG can be there to answer questions, as well as provide
 information about the discussions between myself and the firewalld team.

I'll be there

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] Summary/Minutes from today's FPC Meeting (2014-12-11 17:00 - 18:25 UTC)

[Matthias Clasen]

On Mon, 2014-12-15 at 10:18 +0700, Michel Alexandre Salim wrote:
 
 On 12/13/2014 12:54 AM, Zbigniew Jędrzejewski-Szmek wrote:
  On Fri, Dec 12, 2014 at 09:38:52AM -0500, Bastien Nocera wrote:
 
 
  - Original Message -
  On 12/12/2014 03:18 PM, Bastien Nocera wrote:
 
 
  - Original Message -
  On Fri, Dec 12, 2014 at 09:04:19AM -0500, Bastien Nocera wrote:
 
  Agreed, a static library is a waste of time. What about a normal
  shared library? Do you think patches to do that would be accepted?
 
  How does a shared library solve any of those problems?
  I wonder why I have to explain this ;)
 
  It would concentrate/centralize a distributed, undetectable origin of
  bug into one point of maintenance and development.
 
  It wouldn't solve the problem of not wanting to offer an API to 
  third-parties...
  Hi,
  
  I understand why upstream did not want to do that, but current
  situation is not very attractive either. The same piece of library-like
  code is duplicated in two places in gnome, in cinnamon, and we are talking
  about duplicating in a fourth place.
  
  FPC wants to have it split out and shared. gvc has the last commmit in
  git 13 months ago. Shouldn't be that much of an issue to split it out.
  
 Having a static lib that goes against upstream's wishes, and that won't
 be used by the core GNOME applications anyway, seems rather anomalous as
 well.
 
 On the other hand, given that Cinnamon, Budgie, and other GNOME-related
 external projects are using this internal dependency anyway, I'd say the
 intent of not offering an API to third-parties has already failed... and
 not offering a *stable* API should be obvious enough by offering only a
 static lib. We could even add a README.Fedora file clearly stating that
 this library comes with no API stability guarantee.
 
 Seems that we should go back to the FPC, now that the objection from
 upstream (in some cases overlapping with Fedora package maintainers) is
 clear. At the very least, we need a decision on what to do with shared
 internal modules that are not intended to be used by external third
 parties - like libgd and libg-v-c, but I won't be surprised if there are
 others.


I don't think you can really force a package maintainer to provide a
static library for code the is very explicitly not meant to be shared.
Just because others decided to ignore that wish and copied it anyway.

The only outcomes I can see if this is being forced is a) us loosing
package maintainers who are fed up with this or b) upstream starting to
change internal apis every release, just to make copying this code so
difficult that it becomes impractical.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 downloads repository metadata in 3 places!

[Matthias Clasen]

On Mon, 2014-12-15 at 18:01 +0100, Kevin Kofler wrote:
 Robert Marcano wrote:
  I don't know why the time to rebuild rpms is important, updates are now
  applied at boot time, so rpms can be rebuilt with smaller nice/ionice
  before the user reboots (on Workstation product).
 
 Offline updates are only a (mis)feature of the GNOME Workstation product. 
 The tools shipped by all the other spins (Apper, Yumex) do immediate updates 
 as always.

...which brings this thread to the end of its useful life.

If you have constructive suggestions for how to improve detection of
'metered' connections, please direct them to the desktop list, or send
patches to the gnome-software component in bugzilla.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Workstation Product defaults to wide-open firewall

[Matthias Clasen]

On Mon, 2014-12-08 at 17:08 +0100, Reindl Harald wrote:
 Am 08.12.2014 um 16:55 schrieb Bastien Nocera:
  You're free to select another firewall zone.
 
  How, when you don't even install the firewall configuration tool by 
  default?
 
  Settings - Network, select your network - Identity - Firewall zone
 
 that's possible with one click?
 
 fine, then the only right decision would have been ship *that* as 
 default and say You're free to select another firewall zone exactly 
 that way BUT NOT ship danergous and unsecure defaults
 
 there is no but and if
 
 nobody of your user audience will lock down his machine manually when 
 all seems to work and a user which is not able to manually switch to a 
 more unsecure mode (by read 5 seconds docs or Google) better stays with 
 shields up - better be safe than sorry
 
 hopefully i die before the userbase growing up with that direction of 
 wrong defaults is in the position to make decisions and technical 
 implementations!

It is clear by now that you don't agree with the decision the
workstation WG has taken on this topic. I don't think rehashing the same
arguments over and over will lead to any new insights. In particular
with 'I hope I die' style rhetoric.





-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Workstation Product defaults to wide-open firewall

[Matthias Clasen]

On Tue, 2014-12-09 at 01:35 +0100, Kevin Kofler wrote:
 
 To me, it is obvious that the Workstation WG is in deliberate contempt of
 FESCo's decision. That alone ought to lead to sanctions from FESCo. In
 addition, FESCo's decision must be implemented properly by a security update
 ASAP. A wide-open firewall is a security issue. We CANNOT leave it unfixed.

Ah, the appeal to authority, lovely. 

I know it is hard, but maybe try to accept that there are different
views of the world, and not everybody shares black-and-white one. The
sky is not falling just because we are shipping a non-paranoid firewall
configuration.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Tick-tock release cadence?

[Matthias Clasen]

On Thu, 2014-12-04 at 09:39 -0500, Matthew Miller wrote:


 What do you think? Would this help towards the goals listed above?
 Would it help _other_ things? What downsides would it bring?

I think it is not useful to set up a general mechanism of alternating
releases and borrow a name for it before you've discussed what concrete
tasks in release engineering and qa there are that we just cannot get
done. You're essentially asking ask to buy the cat in the bag...

If we agree to this, will we get 

https://fedorahosted.org/rel-eng/ticket/5721

resolved for f22 ? What about

https://phab.qadevel.cloud.fedoraproject.org/T377

I think it is much better to talk about concrete goals and tasks in the
rel-eng and qa space than about 'tick-tock' schedules. We're building an
OS after all, not a cuckoo clock :-)



-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Power consumption with Fedora

[Matthias Clasen]

On Tue, 2014-12-02 at 11:33 -0500, Owen Taylor wrote:

 
  * The backlight eats a ton of battery - 4W for the display backlight
 and 1W for the keyboard backlight. If you are getting poor battery life,
 turn off the keyboard backlight and turn the screen down. But how do we
 fix this for all users? We used to be much more aggressive about screen
 dimming in GNOME, and it was really annoying. Can we find some happy
 medium?

Did we ever do a close comparison to OS X' backlight handling ?


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Join to Mozilla Location Service in Fedora

[Matthias Clasen]

On Thu, 2014-11-06 at 09:43 -0500, Paul Wouters wrote:
 On Thu, 6 Nov 2014, Martin Stransky wrote:
 
  as you may know [0] Firefox in Fedora [1] is using Mozilla Location service 
  [2] as a location provider instead of the Google one.
 
  I'd like to ask you to join the project, install the Mozilla Stumbler 
  application [3] and help to improve the location accuracy.
 
 Are third party (non-browsers, free opensource software) allowed to use the 
 service?
 
 The licensing I see mostly talks about the gathering the data, but not
 about consuming the data.

We are actually using the mozilla location service for the desktop
location consumers nowadays, via geoclue. So adding to the mozilla
database will also help the desktop apps.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal for integration tests infrastructure

[Matthias Clasen]

On Tue, 2014-11-04 at 04:56 -0500, Colin Walters wrote:
 This looks related to: https://wiki.gnome.org/GnomeGoals/InstalledTests
 
 (Note that the Issues with make check is equivalent to issues with rpm 
 %check)
 
 It's implemented by gnome-continuous, and there's been a bit of effort to 
 make -tests subpackages for some pieces in Fedora, but AFAIK no runner yet.

The upstream continuous test runner is in the gnome-desktop-testing
package. And the following tests packages are available to make use of
it:

gjs-tests
gtk3-tests
glib2-tests
pango-tests
clutter-tests
gdk-pixbuf2-tests
gnome-weather-tests
gtksourceview3-tests
glib-networking-tests

I would love to bring the other upstream tests to Fedora as well -
altogether, we have 500 tests running continuously in gnome-continuous.



-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: btrfs as default filesystem for F22?

[Matthias Clasen]

On Tue, 2014-10-07 at 13:24 -0400, Josh Boyer wrote:
 On Tue, Oct 7, 2014 at 1:19 PM, Gerald B. Cox gb...@bzb.us wrote:
  Thanks James... I am aware of all the warnings.  They might as well put up a
  skull  crossbones.  I have all my data backed up twice.  But this is my
  point... you don't say toxic and then simultaneously talk about proposing it
  as the default file system on Fedora.
 
 Right... no single person is saying both things.  We don't have
 split-personality disorder here.  Someone started discussing it as
 default, and a bunch of other people chimed in that it wasn't ready.
 Until those concerns are dealt with, it's not really even a candidate
 for default consideration.

I think the point is somewhat valid though. To just keep repeating the
mantra 'its not ready' is not going to make it any more ready. If suse
can identify a stable subset of btrfs features and use it as their
default file system with those restrictions, why can't we do the same ?
The approach makes sense to me, at least...

Are the suse and fedora kernels that different that there is no synergy
to be had here ?

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: How to include fonts in Gnome Software?

[Matthias Clasen]

On Mon, 2014-10-06 at 10:49 -0700, Luya Tshimbalanga wrote:
 Hello,
 
 I noticed Titillium typeface is unlisted in Gnome Software. How to 
 include it? I tried to look at the documentation about the process but 
 not available.

Hey Luya, I see these fonts here:

https://github.com/hughsie/fedora-appstream/tree/master/appdata-extra/font

and there is appdata for them in /usr/share/app-info/xml/ on my system,
but for some reason they still don't show up in gnome-software. Kalev
and I briefly looked into it, but couldn't quite figure it out. I'll ask
Richard to take a look tomorrow (he's off today).

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: The Shimmer Project - Desktop Suites GTK+ 3

[Matthias Clasen]

On Fri, 2014-10-03 at 22:20 +0530, Satyajit Sahoo wrote:
 They have completey rewritten Adwaita and integrated it into GTK. If
 they change it again, it'll be hard for them too. But let's hope for
 the best :D

Even better to just talk to 'them' - we are right here, and happy to
answer questions. It is hard to give your issues equal weight unless we
hear about them. 

In terms of 'breaking it again', you should be aware of this change: 

https://git.gnome.org/browse/gtk
+/commit/?id=4d9d655b4efe9fd23ad18449d3e45fb8cd4d9cf0

Themes will be css-only in 3.16.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Improving the offline updates user experience

[Matthias Clasen]

On Tue, 2014-09-16 at 16:21 +0200, Zdenek Kabelac wrote:

 
 Has Fedora given up Unix ??

This thread has gone quite far out into the weeds. It started with a
fairly concrete question: can we improve the offline update experience
by requiring only a single reboot, instead of two ?

I'd still be interested in hearing Lennarts opinion on this.


Matthias

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On-demand launching via socket activation

[Matthias Clasen]

On Wed, 2014-09-10 at 09:31 -0400, Stephen Gallagher wrote:

  Should I apply for an exception of some sort, or does the socket 
  activation policy need revisiting?
  
 
 It's also worth noting that FESCo granted the WGs the rights to make
 decisions like this, so I'd recommend asking the Workstation WG for
 permission to add this to their systemd preset file. I suspect it will
 be granted.

I think its a great idea. If you want to propose it, we can discuss it
in the next WG meeting (I sadly saw this too late for the one that just
ended...).

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: blivet-gui announcement

[Matthias Clasen]

On Fri, 2014-09-05 at 15:55 +0200, Vratislav Podzimek wrote:
 On Fri, 2014-09-05 at 09:04 -0400, Bastien Nocera wrote:
  
  - Original Message -
   Good news, everyone! We (me and CC'd Vojtech Trefny) would like to
   introduce you the next generation tool for storage management -- the
   **blivet-gui** tool [1]_. It is a GUI tool based on the blivet python
   library (originally Anaconda's storage management and configuration
   tool) inspired by GParted and other storage management tools. Why not
   use GParted you ask?
  
  Actually my question is why not gnome-disk-utility? :)
 Because it doesn't work well with LVM, RAID, BTRFS and a combination of
 them.

Leaving LVM out was an explicit decision, because of all the system
integration problems with LVM. It works fine with RAID and btrfs as far
as I know. Do you have any concrete complaints about the RAID or btrfs
support in gnome-disk-utility ?

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: blivet-gui announcement

[Matthias Clasen]

On Fri, 2014-09-05 at 20:53 +0200, Farkas Levente wrote:

 
 system-config-lvm was removed from rhel7 while g-d-u is not able to
 configure lvm. so it _definitely_ a step forward. and really not agree
 with you about the root user usage. you imho those who would like to
 configure disk and lvm should have to be root privileges and should have
 to know what he does. it's again so lennartish when you belive a buggy
 pulse is better then a working alsa if the concept is better. NO simple
 it's not true. a usable working program always better the a perfectly
 design idealism which never really works.

I don' think this is a productive direction to take this discussion in.
This has nothing to do with Lennart, alsa or idealism. Separating the
privileged mechanism from the UI is really not 'design idealism', but
simply with good engineering practice. Pointing this out is not being a
'negative nelly' either, but providing constructive feedback.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Orphaning some packages

[Matthias Clasen]

I've decided to orphan some packages:

ORBit2
at-spi
eog-plugins
gamin
gnome-themes
icon-naming-tools
libIDL
libglade2
libgnomecanvas

Please pick them up if you are interested in them.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Orphaning some packages

[Matthias Clasen]

On Thu, 2014-09-04 at 13:27 +0200, Hans de Goede wrote:
 Hi,
 
 As I was curious of any of my packages depends on
 any of these I've run some repoqueries to see what
 depends on these, and we still have a ton of
 dependencies on these.
 
 So unless we want to drop a ton of packages, we really
 need someone to pick these up:

[...useful data cut...]

Oh, it didn't occur to me to check for deps. Anyway, most of the
packages on the list are gnome2-era things that are no longer used in
GNOME today. Maybe cinnamon or mate people have an interest in them ?

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: How to restart dbus service?

[Matthias Clasen]

On Thu, 2014-07-17 at 16:21 +0200, Mathieu Bridon wrote:
 On Thu, 2014-07-17 at 16:11 +0200, Miroslav Suchý wrote:
  Hi,
  how can I restart dbus service, registered via systemd unit?
  
  To be specific, I have in system:
  /usr/share/dbus-1/services/org.a11y.atspi.Registry.service
  with:
  [D-BUS Service]
  Name=org.a11y.atspi.Registry
  Exec=/usr/libexec/at-spi2-registryd --use-gnome-session
 
 That service should instead have a SystemdService= key, with the name of
 the systemd unit as its value. (then Exec= becomes completely unused)
 
 Without this (and the actual systemd unit), the service is completely
 unknown by systemd, so it can't restart it.
 

This is a session service, so systemd is not in the picture (yet).

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf even allows to uninstall RPM and systemd without warnings

[Matthias Clasen]

On Mon, 2014-06-23 at 11:14 -0500, Bruno Wolff III wrote:


 Try yum update when the oldest installed kernel (and the running 
 kernel) is the only one that works and there is a new (still broken for 
 your system) kernel update available. In that case one really wouldn't 
 expect the running kernel be removed. Having to remove a specific kernel 
 before 
 doing an update (to make sure the wrong one wasn't removed) would be 
 a pain.

I would suggest that the fix for this is to not push broken kernels so
frequently that 'the oldest one is the only that works' becomes an
issue, and to introduce automatic testing that ensures you can at least
boot rawhide to the login screen, _before_ a build gets pushed out to
the masses.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Wayland

[Matthias Clasen]

On Mon, 2014-05-05 at 03:59 -0400, Jaroslav Reznik wrote:

  The whole confusion is because the feature was initially written for
  3.12 but then the whole .next thing happened.
  In short the text needs to be updated.
 
 Matthias updated it, I asked him but probably it needs more updates.

Sorry, I didn't pay much attention to Fedora last week. I'll do better
this week.

Indeed, the feature page made much more sense when it was originally
written, before 3.10. As has been pointed out, we've made considerable
progress in porting to Wayland already. But, the port is not 100%
complete yet. I'll try to reword the feature page to emphasize the
completion aspect. 

What we are aiming for in F21 is to have the Wayland session ready for
day-to-day use without major regressions.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Wayland

[Matthias Clasen]

On Wed, 2014-04-30 at 16:05 +0200, Thorsten Leemhuis wrote:

 Is this about integrating this work in Fedora? Or more porting work? Or
 even make Wayland the default in F21? The section How To Test sounds
 as if the later is the case, but it's not entirely clear to me.

I've tried to clarify the detailed description a bit, but I'm afraid it
is still not great. It might be better to just strip all mention of F20
from the feature.

Whether to switch the default or not depends on whether we manage to
complete the port without user-visible regressions in time for F21. That
is the goal, we'll see if we get there this time. 

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Incorrect order of /usr/bin and /usr/sbin in path

[Matthias Clasen]

On Mon, 2014-05-05 at 16:19 -0400, Simo Sorce wrote:

 
 It's a practical way to keep helpers out of path and autocomplete
 without polluting /usr/lib[64] and having to deal with multilib issues,
 what's pointless about it ?
 

It causes pointless configure and Makefile complications in every single
upstream project that wants to install something into that location and
has to differentiate between Fedora (/usr/libexec) and the rest of the
world (/usr/lib/$pkg). It has ripple-on effects throughout the project -
e.g. having to patch the right prefix into desktop files, into service
files, etc etc.

The fact that multilib gets in the way is an argument against the way we
do multilib, not against /usr/lib/$pkg, from my pov.


Matthias

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Workstation: Disable firewall

[Matthias Clasen]

On Tue, 2014-04-15 at 20:41 +0200, Thomas Woerner wrote:

 
  What you need is clearly different zones that the user can configure
  and associate to networks, with the default being that you trust nothing
  and everything is firewalled when you roam a new network.
 
 We have that already with zones in firewalld.

Kindof. If I open the network panel and find the 'Firewall zone' combo,
I am presented with a choice of:
Default
block
dmz
drop
external
home
internal
public
trusted
work

This list is far too long, and none of it is translated or even properly
capitalized. And there is no indication at all why one would choose any
zone over any other, and what consequences it has.

So, what you have currently is a raw bit of infrastructure that is
directly exposed to the end user, without any design or integration.

 
 The limitations in gnome 3 are:
 - Applets are not easily visible in the desktop.
 - An applet is not always visible, even if the state in the applet is to 
 be visible.
 - Sending out notifications is prohibiting the use of left and right 
 mouse button menus: While the notification is visible, a left and right 
 mouse button click on the applet only shows the notification.
 - After closing an notification sent out by the applet, the applet is 
 made invisible in the tray with a still visible state in the applet. Not 
 even a hide and show will make it visible anymore.
 - Left and right mouse button menus are loose in the desktop and are not 
 visibly connected to the applet, it is not visible any more after 
 clicking on it.

GNOME doesn't have applets anymore, so complaining that your applet
doesn't work great in GNOME is missing the point. 

I don't think we want a 'firewall' UI anyway; the firewall is not
something most users can or should understand and make decisions of. 

What I envision is that we will notify the user when we connect to a new
network, with a message along the lines of:

You have connected to an new network. If this is a public network, you
may want to stop sharing your Music and disable Remote Logins.
[Turn off sharing] [Continue sharing] [Sharing Preferences...]

And we will remember this for when you later reconnect to the same
network.

When we have this infrastructure, we can use this information to also
set the network zone to Home/Public - I don't think the long list of
zones I showed above makes any sense. Either you are at home and
comfortable sharing the network, or not.

I've filed a bug for this:
https://bugzilla.gnome.org/show_bug.cgi?id=727580


Matthias

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: trimming down Fedora installed size

[Matthias Clasen]

On Wed, 2014-04-09 at 08:39 -0400, Matthew Miller wrote:
 On Wed, Apr 09, 2014 at 07:50:37AM -0400, Stephen Gallagher wrote:
   I would say in the long run we should be working towards creating 
   separated locale,doc,man packages
  Hmm, I wonder if RPM 4.12 would allow us to do this with weak
  dependencies?
  Perhaps something like having a metapackage on the system for docs and
  one for each language. Then we could break up the doc and language
  packages into sub-packages that are installed conditionally on the
  presence of that metapackage on the system.
  Of course, I think there would still be work needed in RPM to support
  adding a language later, but maybe we could solve that with special
  tooling or a yum plugin.
 
 +1 to all of this. Needs:
 
   * rpm macros, possibly other RPM work
   * packaging guidelines
   * yum/dnf tooling
   * a plan for realistically getting from where we are now to where we
 want to be
   * executing on that plan

From the desktop/workstation perspective, here are a few things I would
like to see if we decide to work on this:

Support for a new locale is more or less like a 'system extension' for
the OS. It would be good to define clear rules for what it means to
provide a subpackage that becomes part of this system extension.

In an ideal world, this could even be automatic and pattern-based (e.g.
if you install anything into /usr/lib64/gstreamer-1.0, you are providing
a 'codec' extension, and all the files below that directory belong to
it).

To present this in the UI, we need to know the available 'extension
points' (either a fixed list, or a way to enumerate them), as well as
the installed and available extensions for each, including suitable
metadata (name+short description at least).

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Considering GNOME 3.12 as an F20 update

[Matthias Clasen]

Hey,

so the time has come to consider this - thanks to the great work of
Richard and Kalev on the copr, we have a set of 3.12 packages that have
already received fairly wide testing.

But we should be careful, so I want to ask for concrete problem reports
with the copr packages, besides dependency problems caused by the
parallel nature of the copr itself.

Did any of your gnome-shell extensions break ?

Did you experience crashes or other serious problems with applications ?

If so, please let us know on the desktop list. If I don't hear of major
problems by next week, I'll file a Fesco ticket to ask for an exception.


Matthias

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Considering GNOME 3.12 as an F20 update

[Matthias Clasen]

On Thu, 2014-04-03 at 16:32 +, Jóhann B. Guðmundsson wrote:
 
 On 04/03/2014 04:22 PM, Matthew Miller wrote:
 
  Now, in reading that policy, there are quite a few things that match the
  Things that would make it less likely to grant a request list. But, on the
  other hand, by having a longer-than-typical Fedora release cycle this time
  around, we are already in special circumstances territory.
  
 
 Gnome community is not know for their stability in their UI so we are
 talking about user visible changes.
 
 Sysadmins on these parts brought out their voodoo dolls and started
 stabbing them while cursing the new and improved network settings
 that came with F20 and Gnome 3.10 and other docket breakage that
 followed in other words Gnome community is not know for their
 stability in their UI so we are talking about user visible changes
 being introduced into GA release.
 
 And I have yet to see any request have been made to the test list to
 at least do the same validation on Gnome as is done before we release
 an new GA release.

Note that I am not asking about armchair opinions about whether this
idea would theoretically fit the guidelines.

Neither am I asking for war stories of sysadmins whose life was ruined
by f20.

I am interested in concrete problems that have been experienced by the
people who have tried out Richards copr. If you are not in that group of
people, maybe you should actually try the copr before participating in
this discussion.

Thanks,

Matthias

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Per-Product Config file divergence

[Matthias Clasen]

On Mon, 2014-03-10 at 15:46 -0700, Adam Williamson wrote:

 Just for the more-public-record, I remain pretty sure this is a bad idea
 and don't think we should allow it. You should always be considered to
 be running exactly 0 or 1 Products. I think we should consider how to
 allow things like 'run a desktop on the Server product', but that
 shouldn't be conceived as 'run Workstation on Server'.

I agree. We shouldn't get into the muddy areas of mixing, extending and
customizing and stacking one on top of the other, before we even have a
clear picture of what the different products will look like. 

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Read this if your package includes a status notifier / system tray icon

[Matthias Clasen]

On Thu, 2014-03-06 at 00:07 +0100, Kevin Kofler wrote:

 That was the excuse for not supporting the spec in GNOME Shell:
 http://lists.freedesktop.org/archives/xdg/2010-January/011228.html
 A very bad excuse, considering that, as I pointed out, the spec GNOME 
 proposes using instead (the Galago spec) is worse when it comes to that!

Please stop rewriting history. The spec was proposed, flaws were pointed
out in the review, and there was no willingness to address those flaws
in any meaningful way.

You can consider it an 'excuse' all you want, but from my perspective,
it was the right decision.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Read this if your package includes a status notifier / system tray icon

[Matthias Clasen]

On Wed, 2014-03-05 at 20:04 +0100, Kevin Kofler wrote:

 --+-
 GTK+ (2 or 3) | You must use Canonical's libappindicator, which is
   | interoperable with the KDE implementation. It is
   | already packaged in Fedora. Several GTK+ packages
   | already support it, for those, it is only a matter
   | of adding the BuildRequires (libappindicator-devel
   | for GTK+ 2, libappindicator-gtk3-devel for GTK+ 3).
   | For some others, patches to add libappindicator
   | support are available from Ubuntu.
 --+-

Of course, you can also just stop using status icons and instead inform
the user with notifications when something requires his immediate
attention. That will work under any desktop.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: default file system, was: Comparison to Workstation Technical Specification

[Matthias Clasen]

On Mon, 2014-03-03 at 16:16 +0200, Ric Wheeler wrote:


 I am fine with something like what is proposed by Steve above - let users 
 have 
 the GUI present an option that gives preference to the default without 
 totally 
 hiding other options.

You and Josef are sending mixed messages here: btrfs is fine, but just
not ready to be the default and don't make it the default, but we
still need users to install it so it can get better, so don't take away
the option. I don't think that is reasonable - either it is ready to be
widely used, ie the default, or it isn't in which case it shouldn't
appear in the UI.

I'm pretty firmly against filesystem choice in the workstation
installer.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Packages with missing %check

[Matthias Clasen]

On Wed, 2014-02-26 at 16:58 +0100, Miloslav Trmač wrote:
 2014-02-26 14:11 GMT+01:00 Colin Walters walt...@verbum.org:

 The *very first* test I run is does the OS still boot?
 That's called smoketest for me, and it only takes a few
 minutes.
 
 
 That seems to be optimizing for bugs that break the boot, when bugs
 that occur in less-frequently used parts of the system are far more
 common; a lot of software is not used, or not critical, in the boot
 path.

It is optimizing for answering the most important question first, which
is: Can I tag this build / push this to the thousands of developers and
testers which be blocked from testing the less-frequently used parts of
the system if their system doesn't boot anymore after the upgrade.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] May I file 1000 bugs aka upstream test suite tracking

[Matthias Clasen]

On Fri, 2014-02-21 at 16:51 +0200, Alexander Todorov wrote:

 I want to track which packages *DO NOT* have any tests and later be able to 
 focus on creating them (be it working with volunteers, GSoC participants or 
 whoever is willing to step up to this task).

In that case, I suggest simply keeping a list of good candidate packages
for adding testsuites on the wiki somewhere. That is much less of a
hassle than hundreds of bugs.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to WGs and rel-eng: Move 90-default.preset from systemd to fedora-release

[Matthias Clasen]

On Tue, 2014-02-18 at 07:43 -0800, Adam Williamson wrote:
 
 
 Very much +1. Putting it in kickstarts is a worse tying problem than 
 putting it in a package: it ties this configuration mechanism to a 
 system for creating deliverables, which is what kickstart is. We need to 
 be moving away from having configuration in kickstarts, not adding more.

Hear, hear. Reminds me of this comment in fedora-live-base.ks:

%post
# FIXME: it'd be better to get this installed from a package
cat  /etc/rc.d/init.d/livesys  EOF
[...]

Has been there from day 1 :-) Its hard to change your ways when it is so
easy to just continue the existing hack...

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: advertisement in packaged software (e.g. Firefox)

[Matthias Clasen]

  
  Are we allowed to ship software in Fedora that dynamically loads
  advertisements from the web and shows them to users?
 
 I think allowed is probably the wrong term to use here. Fedora
 packaging rules on what is allowed to be included have pretty much
 focused on legality of packages. ie licensing, trademarks, patents,
 etc. The question of whether advertisements are allowed is starting
 to venture into the grounds of philosophy. There's probably also a
 privacy question to answer here too. To me though, those aren't
 criteria for forbidding software from Fedora entirely, but are
 relevant when choosing whether a piece of software is set as the
 default option installed for users.

Yeah, I agree. This is not about being allowed to, but the question is
whether we want to. And for that, the question probably is: it depends.

I can't imagine having very obnoxious and prominents advertisements in
the flagship applications that we install by default. But an application
that is otherwise useful to our users should probably not be banned from
the package universe just because it downloads an ad.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.NEXT Products and the fate of Spins

[Matthias Clasen]

On Fri, 2014-01-31 at 06:03 -0500, Stephen Gallagher wrote:
 
 What this does reveal is a bigger problem: that the audiences of at least 
 some of the spins are not aware of this relationship to the larger Fedora 
 ecosystem. This would indicate that the dropping or de-promoting the spins 
 might lead the users of them to believe that the functionality they provided 
 was removed from Fedora. While it is not a correct perception, it is 
 nonetheless one that will occur (to some degree no matter how we advertise 
 things) if some or all spins go away. It's a point that clearly merits 
 consideration.

The spins concept splits the community into small fiefdoms and creates
unnecessary divisions.

I've seen mails on this list recently where people proudly stated that
they would continue to advertise one particular spin at conferences etc,
regardless what the official Fedora products are. If that is how we
advertise 'Fedora', it is not really a surprise that our users are
unclear about what it really is...

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora.NEXT Products and the fate of Spins

[Matthias Clasen]

On Fri, 2014-01-31 at 14:34 +0100, Lukáš Tinkl wrote:

 Fedora isn't a Gnome OS, perhaps that's what they're trying to convey; 
 making it one will most probably create less confusion but I'm sure it 
 will also make us less relevant (my personal opinion).

Not sure why that was necessary, but I'll answer anyway:

I would be happy if Fedora moves towards being an OS, with a clear
separation between system and applications, and a clear definition of
what is part of the core system and what isn't. I don't think it makes
sense to discuss products if we don't agree on that as a necessity. 

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

a questionable dependency chain

[Matthias Clasen]

I've switched to rawhide yesterday, and discovered that vinagre now
forces rsyslog onto my system. That's not great.

The dependency chain goes something like this:

vinagre - spice - libcacard - ... glusterfs ... -
rsyslog-mmjsonparse - rsyslog

I think there's at least two questionable links in this chain:

- why does libcacard need glusterfs ?

- why does glusterfs need rsyslog ?

Can we get one or both of these cut, maybe ?

Matthias

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: SELinux RPM scriplet issue annoucement

[Matthias Clasen]

On Mon, 2014-01-20 at 23:18 -0800, Adam Williamson wrote:
 On Tue, 2014-01-21 at 01:01 -0600, Ian Pilcher wrote:
  On 01/20/2014 11:48 AM, Adam Williamson wrote:
   The bug currently under discussion was caused by a change that came in
   inadvertently, not intentionally, and was actually intended for Rawhide.
  
  I can't help wondering if there's an opportunity for process/workflow
  improvement right there.
 
 Well, I'd have to leave that to the SELinux folks to comment, but I
 would say it's only happened once since I came to Fedora that I
 remember, and everyone makes mistakes sometimes :/

Exactly. And because everybody makes mistakes, we have processes to
catch and prevent those inevitable mistakes from going out. I think it
would be great to make adjustments to the process / policy so that we
get better at preventing this...

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: adam's grump of the day: icons in fonts (was Re: web-assets-httpd stuck in limbo?)

[Matthias Clasen]

On Wed, 2014-01-15 at 22:31 -0800, Adam Williamson wrote:
 On Wed, 2014-01-15 at 22:59 -0700, T.C. Hollingsworth wrote:
 
  * Another individual thought that all web authors are stupid for
  wanting to use fancy fonts and that I am wasting my time.  (He might
  be right about that last bit... :-P)
 
 While we're doing asides, that one *does* get right on my nerves.
 
 If anyone overrides font choices in their browser config and wonders why
 an increasing number of sites - inc. github, and the wordpress admin
 interface - seem to display weird hieroglyphs all over the place, it's
 because of this clever trick: web designers have decided that it's a
 really good idea to abuse font rendering engines as a way to render
 icons, and starting shipping icons as made-up Unicode codepoints in
 their sites' custom fonts. If you override their font choice, then of
 course these icons wind up as garbage, because your font does not have
 them, because ICONS AREN'T FUCKING TEXT CHARACTERS, web designers.

It makes a lot of sense, actually. At least the symbolic icons that have
become prevalent in our uis share a lot of characteristics with text,
and can benefit from getting the same treatment as glyphs.

We've been discussing this as an option for rendering symbolic icons in
GTK+ too.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Taskotron

[Matthias Clasen]

On Mon, 2014-01-06 at 18:06 +0100, Vít Ondruch wrote:
 Dne 6.1.2014 17:53, Matthew Miller napsal(a):
  On Mon, Jan 06, 2014 at 09:36:09AM -0700, Tim Flink wrote:
  One of the primary reasons for replacing AutoQA with taskotron is to
  make it easier for folks to contribute checks. AutoQA's implementation
  just isn't capable of doing that in a reasonable fashion. We haven't
  gotten into the specifics of how package-specific checks would work
  yet, but one idea was to keep them in the package's git repo.
  What about including them in the RPMs themselves, in a new section similar
  to the existing %check -- or just in a standard file location (so no changes
  to RPM itself are needed immediately)?
 
 
 Not sure how RPM fits here. For example, Ruby on Rails framework consist 
 of 8 basic packages and I'd like to be able to do some basic integration 
 test if any of this packages is rebuilt. This is totally independent of 
 RPM IMO.

We are still very interested in having installed tests for the GNOME
stack run in the Fedora context. See here:
https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests
These tests also assume that they are running in a session on an
installed system, not at build time in a build system.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: /usr/share/xsessions and window manager

[Matthias Clasen]

On Mon, 2013-11-18 at 11:23 +0800, Christopher Meng wrote:
 Hi,
 
 Yesterday I reviewed a package notion, which is a new window
 manager(new to fedorian), it installs desktop file to
 /usr/share/xsession.
 
 Interesting, when I looking into more window manager in Fedora, I found 
 that:
 
 openbox installs desktop file to /usr/share/xsessions
 pekwm installs desktop file to /usr/share/xsessions
 dwm installs desktop file to /usr/share/xsessions
 ratpoison installs desktop file to /usr/share/xsessions
 fvwm installs desktop file to /usr/share/xsessions
 sawfish installs desktop file to /usr/share/xsessions
 icwm installs desktop file to /usr/share/xsessions
 enlightenment installs desktop file to /usr/share/xsessions
 awesome installs desktop file to /usr/share/xsessions
 
 -
 fluxbox installs desktop file to /usr/share/applications
 xmonad installs desktop file to /usr/share/applications
 i3 installs desktop file to /usr/share/applications
 mutter installs desktop file to /usr/share/applications
 byobu installs desktop file to /usr/share/applications
 
 
 So I think that maybe  these have been doing wrong for years? Should I
 file RFE for these?

No. These files serve different purposes.

Files in /usr/share/applications are to make applications known to the
desktop shell (the fact that mutter installs a desktop file there is
more or less a historic remnant - we could probably remove it without
harm).

Files in /usr/share/xsessions tell the display manager which sessions to
offer to the user on the login screen.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F20 Beta upgrade issues - network status gone

[Matthias Clasen]

On Wed, 2013-11-13 at 17:58 -0800, Adam Williamson wrote:

  - I don't have any Bluetooth status or display in gnome-shell now.  I
did previously.  I do not know what I need to install or tweak to get
it back, or where to report it.
 
 I'm not as sure about this one, but it's probably the same thing: no
 'status' will be displayed unless there's something useful to display
 (like a paired device).

Yes, the bluetooth icon shows up on the top bar when you've paired a
device. In that case you also get a bluetooth submenu in the system
status. I just tried with my phone.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: unaccessability

[Matthias Clasen]

On Fri, 2013-11-08 at 14:06 +0200, Joonas Sarajärvi wrote:
 2013/11/7 Christian Schaller cscha...@redhat.com:
  Ok, so I guess the solution would be for the launcher to do something like 
  this:
 
  gnome-terminal --geometry 80x37 --disable-factory --role=bitchx 
  --class=bitchx --name bitchX IRC --title BitchX IRC
 
 
 Isn't the Terminal attribute of desktop files[1] supposed to tell the
 launcher program that it should start the application inside a
 terminal? My impression is that Gnome at least used to support it, and
 I know that KDE does support it. It should quite easily allow
 specifying launchers for terminal-based programs that do not usually
 need command line arguments.
 
 [1] http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html

GNOME supports the Terminal key just fine. But just having your commandd
run in a terminal is not quite enough to give it an identity as a
separate application - to the rest of the system it will appear just as
a terminal. The extra arguments that Christian shows there help to
overcome this problem.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Base] Summary/Minutes from today's Base WG meeting (2013-11-08)

[Matthias Clasen]

On Fri, 2013-11-08 at 10:51 -0600, Dennis Gilmore wrote:

   * LINK: http://fpaste.org/52688/38392758/   (pknirsch, 16:19:54)
   * Base definition: installer, compose tools, minimal install (for some
 definition there), and functionality the majority products want to
 use  (pknirsch, 16:21:30)
 

Hey, I read your minutes, and discussed some of my thoughts on this with
my workstation wg peers. Basically, I think that defining a 'base' as a
particular set of packages (minimal install, or some variant thereof)
does not really provide us what we need to build one or more products.'

What we really need as a base is a definition of the apis that are
guaranteed to be stable and that the products and applications can rely
on. Packages can to some extent serve as a proxy for that, but they are
really just an implementation detail of how the product is put
together. 

For example, when you talk about an OS being systemd-based, the
important part is not that systemd is part of the minimal install, but
the fact that applications can rely on org.freedesktop.login1 and so on
being available on the session bus, and that installing a unit file
in /usr/lib/systemd/system is the proper way to make a service known to
the system, etc.

There will of course be APIs that are product-specific. Eg, the server
product might define a remote management api that is not relevant for a
workstation. And desktop applications running on the workstation need to
know which session services they can rely on.


Just my 2 cents, Matthias

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Base] Summary/Minutes from today's Base WG meeting (2013-11-08)

[Matthias Clasen]

Forgot one thing - the installer question.

I think it already came up tangentially in some of the workstation prd
discussions, but I think we should at least be open to the idea that the
different products need to be able to define their own install
experience.

That would imply that the 'installer' you mention as part of base should
perhaps be just a shared installer backend which can support different
frontends. I know the anaconda team has been working towards
establishing such a separation, with kickstart being the interface
between frontend and backend. I don't know how far that got though, so
maybe this is more of a long-term goal.

Just wanted to mention it.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Workstation PRD summary and next steps

[Matthias Clasen]

On Sat, 2013-11-09 at 01:03 +0100, Kevin Kofler wrote:
 Christian Schaller wrote:
  The next update of the PRD will be posted to the fedora-desktop list as
  that is the designated 'home' of the working group and product and we want
  to avoid cluttering up the general Fedora-devel list with product specific
  further discussion.
 
 In other words, you want to move all discussion to a list that's mostly only 
 followed by GNOME people where you can expect all changes to be swept 
 through without any criticism…

No, we want to move to a forum where the working group members have a
chance to discuss things without being drowned out by 100+ mails/day
from you. The other working groups are doing the same on their
respective mailing lists.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: gtk3 broken/missing icons on kde

[Matthias Clasen]

On Tue, 2013-11-05 at 08:23 +0100, drago01 wrote:
 On Tue, Nov 5, 2013 at 3:03 AM, Adam Williamson awill...@redhat.com wrote:
  On Sun, 2013-10-27 at 01:46 +0200, Kevin Kofler wrote:
  Adam Williamson wrote:
   I don't think we'd really be correct in blocking the release for such
   issues - especially not Beta. We used to have 'polish' criteria for
   Final which at least required the icons used in the system menus - i.e.
   what's specified in the app's .desktop file - to be sane for all
   installed applications, but we dropped that (and other polish criteria)
   with the F19/F20 criteria re-write on the basis that they were really
   stretching a bit too far and would be unlikely to hold up to a 'last
   blocker before release' acid test. Stuff like this doesn't break
   anyone's use of the system catastrophically and can reasonably be fixed
   with updates.
 
  But it also affects the live images (making them look very unpolished) and
  we don't respin those.
 
  That's why I said 'reasonably' not 'perfectly' :) I can see an argument
  for blocking Final, though in practice, I don't think our current
  standards are such that it really makes sense to claim our final
  releases are so smooth as to be worth enforcing a high standard of
  polish via the blocker mechanisms
 
 Then we should that. There is a difference between perfect and something 
 that
 looks obviously broken.

Are we really fighting about the classification of fixed bugs here, or
is there a new issue that I am not aware of ?

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

[Matthias Clasen]

On Tue, 2013-11-05 at 12:35 +0100, Nicolas Mailhot wrote:
 Le Lun 4 novembre 2013 23:02, Nicolas Mailhot a écrit :
 
  The problem is not to get code in the hands of developers. You don't need
  distros for that. The problem is to get the code to end-users and
  developers spend more time fighting the constrains it involves than trying
  to understand this problem-space.
 
  Of course the aim might not be to reach end users but to push code from
  developpers to other developers.
 
 And if that is the case, there is a huge disconnect between GNOME goals
 and Fedora Workstation goals. GNOME speakers repeat all year round their
 software is not aimed at power users, but developers are the über power
 user.

Why do you think the two sets of goals have to be one and the same ?

The Fedora Workstation effort (not a great name, by the way), is brand
new, and its goals have only just been drafted. How could the goals that
GNOME has followed in the past 3 years be perfectly align with it ? And
why should they, for that matter ? This is not a GNOME project, it is
about saving Fedora.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

[Matthias Clasen]

On Tue, 2013-11-05 at 16:32 -0500, Josh Boyer wrote:

  Right, that's exactly what I was saying. I just think this is all the
  _original poster_ was talking about, not any kind of automatic
  configuration of such repositories. (Or at least, you can read it that
  way).
 
 OK.  I guess that's fine, but it seems like a non-goal to me.  I mean,
 it already works that way.  All adding it to the PRD would do would
 make an easy thing to check off the list as met.

I would actually like to go a little further, and make it easy to enable
'clean' third-party repositories. If we imagine a future where e.g.
valve is hosting a repository with their steam client, or say, the
chromium web browser is available from the a fedora people page, I would
really like it if searching for 'steam' or 'chromium' in gnome-software
would bring up a text that said something like: The software you are
looking for is available from a third-party repository. Do you want to
enable it ?

Matthias

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

[Matthias Clasen]

On Mon, 2013-11-04 at 11:37 +0100, Nicolas Mailhot wrote:

 GNOME decided to break it all the time (can't even get extensions work
 from one gnome-shell version to the next one and no gracefully disabling
 is still functional breakage).

So, you take the one API that is explicitly declared non-stable to judge
GNOME wrt to API stability ? Not a very strong case, I'm afraid.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: gnome software shell search provider? [Re: Is Gnome Software ready for primetime?]

[Matthias Clasen]

On Sat, 2013-11-02 at 18:22 +0100, Reindl Harald wrote:
 Am 02.11.2013 18:16, schrieb Michael Catanzaro:
  The other change I want is for PackageKit to download updates weekly by
  default. Currently updates come daily, but daily offline updates would
  be completely absurd. All we have to do to support this is to change the
  default value of one gsettings key.
  
  [1] http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates/
 
 in case of security updates with zero-deay exploits everywhere in
 the news weekly updates are more absurd for a bleeding-edge
 distribution - at this point the whole idea with offline-updates
 should be recosindered (saying as KDE user which is running
 yum daily per hand and updates-testing enabled, so not affected
 from all this changes)

Whether the updates are done 'offline' or not has only little relation
to how often we check for available updates and notify the user.

The logic I recently implemented for gnome-software 3.12 in F21 is to
check for new updates once per day, and download updates when they are
important (e.g. security updates), or when it has been a week since the
last time we installed updates. When a consistent set of updates has
been downloaded, we notify the user about available updates.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Is Gnome Software ready for primetime ?

[Matthias Clasen]

On Fri, 2013-11-01 at 18:33 -0500, Michael Catanzaro wrote:
 On Fri, 2013-11-01 at 11:01 +, Richard Hughes wrote:
  Sure. GNOME is a complete desktop, not a collection of packages
  designed to be replaced.
 Personally, I see little benefit in prohibiting users from removing core
 apps.  If they don't like a particular program, why force it on them?
 Many people like to have exactly one application for each task - for me
 that's the GNOME application, but it's not hard to understand why people
 replace Epiphany with Firefox, Totem with VLC, etc.
 
 Having a few uninstallable apps isn't a huge deal, but will be annoying
 for many and will justifiably draw user criticism.
 
 Anyway I'm curious exactly which apps will be uninstallable: are they
 handpicked or is there some criterion (e.g. everything in the core
 moduleset? but then would you be stuck with Epiphany if you install it,
 even though it's not installed by default?)
 
 On Fri, 2013-11-01 at 11:01 +, Richard Hughes wrote:
  We wanted to write an application that rocked for a certain set of
  users, rather than write a generic UI that wasn't really usable by
  anyone. Also, given that you can easily install the old packagekit
  package tools using the application installer, there's really no
  reason to get upset at all.
 When they're installed at the same time, is there appropriate magic to
 ensure that gnome-software handles system updates, or would there be
 some sort of horrible competition between the two?  (Maybe
 gpk-update-viewer should be retired entirely?) 

There's no competition.

If you run gpk-update-viewer it will let you install updates (individual
updates, 'online'), but it has no active role in monitoring system
updates.

In F20, the monitoring is done by the updates plugin in
gnome-settings-daemon (and it will use gnome-software when asked to
bring up a UI).

For F21, this is being moved to gnome-software itself - it fits better
there, and we get rid of the PackageKit dependency in
gnome-settings-daemon, which people have complained about before
(#699348).

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct