Re: Small rant: installer environment size

[Ray Strode]

Hi,

On Thu, Dec 8, 2022 at 2:55 PM Adam Williamson
 wrote:
> This is the direction Daniel was thinking down. I'm waiting for someone
> with more expertise to reply, but I suspect the reply is going to be
> along the lines of "yes, we *can* do that, but it's somewhat tricky
> work that involves thinking about lots of paths that aren't obvious,
> and somebody would need to dedicate their time to working on that".
Presumably we could package the firmware separately and just unpack it
into place from a udev rule when the hardware is detected?

But first, do we actually know this is a problem?
I think you're saying squashfs loads the whole decompressed image into
memory, but my expectation prior to your mail was that it performs I/O
on the usb stick (with a cache in between).  If my intuition was right
and files only hit ram when accessed, then it seems like this is
pretty much not an issue, right?

Do you have stats on memory usage when running in a live 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: orphaning some packages

[Ray Strode]

Hi,

Over the years, I've acquired some packages that aren't really widely
used anymore. I'm orphaning them now as part of a clean up initiative
for the GNOME packages.

I don't think any of them will be of any interest to anyone, but just
in case someone does want one, I'm including the list here:

Ancient themes:

bluecurve-classic-metacity-the
me
bluecurve-gnome-theme
bluecurve-gtk-themes
bluecurve-icon-theme
bluecurve-kde-theme
bluecurve-metacity-theme
bluecurve-xmms-skin
fedora-screensaver-theme

Ancient settings editor:
gconf-editor

Ancient GNOME libraries
libbonobo
libbonoboui
libgnome
libgnomeui

gtk2 UI designer that uses above GNOME libraries
glade2

--Ray

On Tue, Nov 29, 2022 at 10:53 AM Ray Strode  wrote:
>
> Hi,
>
> Over the years, I've acquired some packages that aren't really widely
> used anymore. I'm orphaning them now as part of a clean up initiative
> for the GNOME packages.
>
> I don't think any of them will be of any interest to anyone, but just
> in case someone does want one, I'm including the list here:
>
> Ancient themes:
>
> bluecurve-classic-metacity-theme
> bluecurve-gnome-theme
> bluecurve-gtk-themes
> bluecurve-icon-theme
> bluecurve-kde-theme
> bluecurve-metacity-theme
> bluecurve-xmms-skin
> fedora-screensaver-theme
>
> Ancient settings editor:
> gconf-editor
>
> Ancient GNOME libraries
> libbonobo
> libbonoboui
> libgnome
> libgnomeui
>
> gtk2 UI designer that uses above GNOME libraries
> glade2
>
> --Ray
___
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: F34 gdm login prompt goes crazy when a fingerprint reader with no enrolled prints is present

[Ray Strode]

Hi,

On Tue, Mar 2, 2021, 11:20 AM Pavel Březina  wrote:
> Can you reiterate the problem? The snippet above don't tell me much.
Sorry, let me summarize (but also see Benjamin's email).

Right now, if fingerprint auth is disabled in authselect, it's not
disabling fingerprint auth at the graphical login screen.

To disable fingerprint auth at the login screen, it needs to write out
a dconf file to tweak the enabled authentication methods.
I'm pretty sure it used to do this, or at least authconfig did.

If it doesn't disable it in the dconf config, the login screen will
try to use it.  It will then fail, and the user will see an error
message
blink by 3 times as it keeps retrying.

Now, on to Benjamin's point, if the fingerprint-auth service returned
AUTHINFO_UNAVAIL, then the login screen would treat the
failure as a "service unavailable" failure, and know not to retry,
which would be better that status quo. It would fix the user
experience,
but it's still not as good as not trying in the first place.

Of course, it wouldn't have to be an either/or.  authselect could
write out the dconf config, and make sure the fingerprint-auth stub
service returns PAM_AUTHINFO_UNAVAIL instead of falling back to
PAM_AUTH_ERR from the pam_deny in /etc/pam.d/other

make sense?

--Ray
___
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: F34 gdm login prompt goes crazy when a fingerprint reader with no enrolled prints is present

[Ray Strode]

Hi,

Ahh, okay.

On Tue, Mar 2, 2021 at 9:31 AM Hans de Goede  wrote:
> sudo authselect select minimal
> sudo authselect apply-changes
>
> Which results in the following /etc/pam.d/fingerprint-auth file:
>
> [hans@x1 linux]$ sudo cat /etc/pam.d/fingerprint-auth
> # Generated by authselect on Tue Mar  2 15:24:53 2021
> # Do not modify this file manually.

Ahhh, okay. So authselect is supposed to be writing out dconf files to set

org.gnome.login-screen enable-password-authentication false

in /etc when it neuters the fingerprint-auth stack.  Can you file a bug?

There might also be some pam magic we could do to force it to return
AUTHINFO_UNAVAIL in that case and then
gnome-shell would DoTheRightThing(tm) even without the dconf change.

--Ray
___
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: F34 gdm login prompt goes crazy when a fingerprint reader with no enrolled prints is present

[Ray Strode]

Hi,

On Sun, Feb 28, 2021 at 9:46 AM Hans de Goede  wrote:
> > https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683 
> > 
> > seems like this is already in updates.  you definitely have the gnome-shell 
> > 40.beta installed?  could be a pam_fprintd is returning a different error 
> > code than expected for no enrolled fingerprint
So we've been investigating this in the above upstream link.

There is a case where pam_fprintd is returning a code we aren't
expecting, but, it shouldn't ever happen :-)

pam_fprintd checks up front if there are no enrolled fingerprints and
then returns the correct error code in that case.

You guys are apparently getting past that part and failing later.
Almost as if the prints were there and then a split second later
disappeared.

One theory is there are files present, but they're unreadable. Maybe
because of selinux?

Can you try in permissive mode, also output ls -lRZ /var/lib/fprint

> Any debugging options which I can enable somewhere to show the pam_fprintd 
> error ?
you can put "debug" on the ends of the lines that say pam_fprintd.so
in /etc/pam.d/fingerprint-auth
that should make the journal more chatty.

--Ray
___
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: F34 gdm login prompt goes crazy when a fingerprint reader with no enrolled prints is present

[Ray Strode]

Hi,

On Sat, Feb 27, 2021, 2:56 PM Ray Strode  wrote:

> ah i think we need to pull in
>
> https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683
>
seems like this is already in updates.  you definitely have the gnome-shell
40.beta installed?  could be a pam_fprintd is returning a different error
code than expected for no enrolled fingerprint
___
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: F34 gdm login prompt goes crazy when a fingerprint reader with no enrolled prints is present

[Ray Strode]

ah i think we need to pull in

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1683

Ray

On Sat, Feb 27, 2021, 2:31 PM Hans de Goede  wrote:

> Hi Benjamin, Ray,
>
> I noticed this problem while dogfooding F34, I'm fully up2date as of today.
>
> Today's gdm update did help in making the problem more clear.
>
> What happens is that as soon as I press enter / click my main user in gdm,
> the password entry box keeps getting updated (and clearing its content)
> every 1 - 2 seconds with a "failed to authenticate with fingerprint"
> (or something like that) briefly showing below the password entry box
> every time it gets cleared.
>
> After a non-fixed amount of tries it stops doing this and only then I
> can successfully login. The same happens on the lock screen of gnome-shell,
> except that there it never stops doing this.
>
> The "failed to authenticate with fingerprint" is new as of todays
> gdm update, before this it was just "failed to authenticate". Now that
> I know fprintd is involved I've masked fprintd and that works around this.
>
> As said I'm running a fully up2date F34 on a Thinkpad X1 carbon 8th gen,
> with the "Linux" fingerprint firmware installed by fwupd. I don't think
> I have ever enrolled a fingerprint, which might be part of the problem,
> but in that case it should really just act as if there is no fingerprint
> reader present.
>
> The login dialog / fprintd should certainly _not_ repeatedly show the
> error IMHO even showing it once would be wrong here, but it would be
> a big improvement.
>
> Let me know if you need any logs, want a bugzilla for this, or if there
> is anything else which I can do to help debug this.
>
> Regards,
>
> Hans
> ___
> 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
>
___
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: Seeking the maintainer of dbus-python

[Ray Strode]

hi,

On Wednesday, February 12, 2020, Miro Hrončok  wrote:
>> sure.  amigadave, do you want to be comaintainer too?
>
> You can only make one person a main admin. Any co-maintainers can be
handled later by them.

well i added neal and amigadave as admins, too, before giving the project
to vojtech.

Ray
___
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: Seeking the maintainer of dbus-python

[Ray Strode]

hi,

On Wednesday, February 12, 2020, Miro Hrončok  wrote:
> Ray, could you please give this package to to FAS user "vtrefny"?

sure.  amigadave, do you want to be comaintainer too?

Ray
___
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: RFC: switch to uvesafb and drop openchrome in F31+

[Ray Strode]

Hi,

You laid this out pretty nicely.  So a few questions:

1) uvesafb is only a /dev/fb driver right ? I guess it won't help with
gnome-shell,
but might help with weston?
2) I believe SimpleDRM is a drm version of uvesafb...have you considered it?
3) One thing i'm worried about is races with the real modesetting
drivers. can we avoid loading this if theres another driver that
advertises support for the pci device? does it already?
4) if you drop vesa and openchrome, maybe you could move fbdev in the
server tree like modesetting.  If you went with simpledrm instead,
maybe you could drop fbdev entirely too?

Anyway, your email makes it sound like there are more pluses than
cons, so i'm on board.

--Ray

On Tue, Apr 23, 2019 at 8:47 PM Adam Jackson  wrote:
>
> I'm considering changing the vesa support code in future Fedora
> releases, for a few reasons. I think this will both simplify the
> support burden for developers, and increase the number of supported
> video configurations in practice. But it's not clear-cut, hence this
> email.
>
> The fallback video path on x86 machines is either efifb if you're
> living in the future, or X's vesa driver if you're living in the past.
> At this point there are only two X drivers that require userspace setup
> support, vesa and openchrome. (The latter I'm also considering nerfing,
> because I sincerely doubt there are any Fedora users of it; if this is
> you, speak up.) Removing this code would simplify some awkward device
> enumeration cases in the X server - cases which have come up in the F30
> blocker list, and I would like not to be on the critical path for that
> kind of thing in the future.
>
> This would also move an 8086 emulator out of the X server to a
> dedicated usermode helper. Which is nice, since X still has to run with
> elevated privileges in these cases, and X hasn't exactly lacked for
> CVEs.
>
> Having done this, we would also potentially _expand_ the number of
> devices we support for graphics, because we would have a vesa-backed
> fbdev driver. There exist wayland servers that can display to fbdev,
> but I'm not aware of any that can display directly to vesa.
>
> But there are risks. For one, we've never tried this. uvesafb itself is
> not untested - I believe you can coax ubuntu and gentoo into using it -
> but we've never built it in Fedora before, so the interactions with
> with our initramfs, with plymouth, and so on are only "tested" to the
> extent that they're the same thing everyone else is doing.
>
> In particular, I'm not entirely sure how well the handoff from uvesafb
> to drm works in practice. From efifb to drm is fairly well tested, and
> also fairly likely to be safe, because efifb does not give you any
> ability to _change_ video device state. uvesafb does, and we could end
> up putting the GPU in a new funky state that the drm driver doesn't
> know how to handle. I suspect this is unlikely, and possible to
> mitigate (by blocking uvesafb from initializing in more cases, for
> instance), but it's something to be aware of.
>
> Finally, uvesafb only supports video devices that support VBE 2.0 or
> higher. In principle, X's vesa driver supports any VBE implementation
> at all. I'm not convinced this is a real issue for us though. VBE 2.0
> dates to 1994, and I have maybe one pre-2.0 video card in my collection
> of old weird junk.
>
> So. Pros: remove some sketchy code from a setuid program everyone has
> installed, potentially lower its privilege profile, potentially enable
> wayland in more scenarios. Cons: maybe lose some device support, maybe
> break gfx fallback on old-firmware systems.
>
> What do we think?
>
> - ajax
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Changing nsswitch.conf on a running system (was Re: /etc/nssswitch.conf is supposed to be a symlink now?)

[Ray Strode]

Hi,

On Wed, Nov 28, 2018, 9:45 AM Florian Weimer  /etc/nsswitch.conf is owned by glibc.  It is not a symbolic link as we
> ship it.
>
> If find out which packages replaces our configuration with a symbolic
> link, please file a bug against that package.  If they want to take over
> /etc/nsswitch.conf, this is negotiable, but it needs coordination with
> the glibc package.
>

This is a bit of a tangent, but we probably avoid changing
/etc/nsswitch.conf on a running system at all (defer until next offline
update?) until

https://sourceware.org/bugzilla/show_bug.cgi?id=12459

gets fixed.  as it stands, no long running daemon will see changes to the
file, I think, leading to potentially weird bugs sometime after authselect
is run right? (and maybe not in an obviously connected way)

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

Re: Attention Gmail users, please turn off HTML mail

[Ray Strode]

> I suggest that if we think this is a serious issue and that we want to
> get the maximum possible help to those who are forced to pay by the
> bit that we stop sending them mail they don't need all together.  Lets
> move this mailing list (and others) to discussion.fedoraproject.org.
Why switch, when we already have 

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

?  it does good quoting already, you get to click what you want, and i'm 
guessing this reply i'm sending will show up plaintext.

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

Re: Non-responsive package maintainer - Ray Strode (halfline), Plymouth package

[Ray Strode]

Hi,
On Mon, Oct 1, 2018 at 4:29 PM Stephen  wrote:
> The maintainer for Plymouth, Ray Strode (halfline), is not addressing
> its bugs on RHBZ (one response all year on a single bug, accepting a
> patch), including showstopper bugs that are preventing boot entirely in
> some instances.
I'm around, but I work on a lot of stuff. plymouth doesn't get a lot
of attention,
since it basically works. It doesn't see as much development as some
components because other parts of the stack have been prioritized.

Having said that, Hans de Goede has taken up the mantle of improving the
boot experience recently, including some changes to plymouth. So you should
see some changes soon.

plymouth does get fixes for blocker issues when necessary, and i still give it
some attention upstream.

It is receiving the amount resources we considered appropriate at the moment.

--Ray
___
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: Flatpaks in src.fedproject.org - a namespace conumdrum

[Ray Strode]

Hi,

On Tue, Sep 4, 2018 at 4:00 PM Owen Taylor  wrote:
> Each flatpak needs to be tagged into two koji tags:
>
>   f29-modular-updates (this is the destination for the module build)
>   f29-flatpak (this is the destination for the Flatpak container build)
>
> The package list for each koji tag is populated from pagure by the
> owner-sync-pagure script (*). But that script has no way of knowing
> what repositories under modules/ in src.fedoraproject.org are just
> modules and what modules are also Flatpaks, so it has no way to
> populate the f29-flatpak tag package list correctly.
I haven't dealt with modularity yet, really, so tell me if i wrong (i'm
kind of guessing a little bit from briefly snooping around). module
building is like so, right?

1) user runs `fedpkg module-build` in a the module git repo
2) this gets submitted to a service to build the module
3) the service reads a metadata file with a list of rpms to build
4) the service submits those builds to koji
5) sometime later owner-sync-koji runs and does a massive
loop over all modules and finds all packages associated
with each module and tags them all with f29-modular-updates

so assuming i have the gist of things captured above, my question
is…why doesn't the service that submits the builds, also do the
tagging ?  it just seems strange to have the huge loop doing extra
work.  if the service did the tagging, then it could also do the flatpak
detecting, and do the additional tagging.  judging from the koji
command line, it seems koji even allows tagging multiple builds at
the same time, so i guess the build service could do them all in
one swoop.

Anyway, take my suggestions with a grain of salt because i have
an incomplete understanding of the architecture, MBS, koji, etc.

--Ray
___
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: remote X connections

[Ray Strode]

 gdm-3.26.2.1-3.fc27

   Update ID: FEDORA-2017-e8628817ff
Content Type: rpm
 Release: Fedora 27
  Status: pending
Type: bugfix
   Karma: 0
   Autokarma: True  [-3, 3]
 Request: testing
   Notes: Add buildrequires for X server so DisableTcp config option works
: properly.
   Submitter: rstrode
   Submitted: 2017-11-30 14:31:29
Comments: bodhi - 2017-11-30 14:31:29 (karma 0)
  This update has been submitted for testing by
  rstrode.

  https://bodhi.fedoraproject.org/updates/FEDORA-2017-e8628817ff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Multiseat seems broken in Fedora 24

[Ray Strode]

Hi,

> Is this use case still supported by Fedora?
It's definitely not a tested use case.  Definitely worth filing a bug
in upstream (gnome) bugzilla.  I wouldn't be surprised if there's more
than one bug that needs to get fixed before it will work again,
though.
It's going to get worse after
https://bugzilla.gnome.org/show_bug.cgi?id=741688 lands since
gnome-shell will only handle one seat, but it will get started
per-user.

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

[Ray Strode]

Hi,

> I don't think we need to change Fedora 24 for this. Unless I misunderstood, 
> this
> systemd change has not been pushed to Fedora 24 (nor proposed for it). We're
> prepping for how to deal with things in Fedora 25.

No, I was the one misunderstanding things.  I thought the systemd
change got pushed into F24 in early May, but reading through my IRC
logs, that was just miscommunication.

Of course the systemd change was going to address a bug we have with
lingering processes at log out, so we'll probably have to come up with
some other fix for f24 at some point, but we can do it as a
post-release update.

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

[Ray Strode]

Hi,

On Wed, Jun 1, 2016 at 10:58 AM, Matthias Clasen  wrote:
> 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.

This is definitely true. It's a class of bug that's hit us over and
over again. (in addition to gconf, ibus, and pulseaudio above, you
could add bonobo-activation-server, evolution-data-server, gam_server
off the top of my head).  The problem is that background services
don't generally take display connections, since they don't need to
display anything.  So they don't die when the display goes away.

We tried to fix this a long time ago with the introduction of dbus
into the desktop.  The idea was the session dbus-daemon daemon would
define the scope of the session, and services would grab a bus
connection if they wanted to be scoped to the session.

Of course, starting in Fedora 24, we no longer have a session bus.
It's a user bus now.  So the bus won't go away until the last user
session (for a user) ends, and those background services won't go away
until they lose their bus connections, since they still rely on
dbus-daemon to cut the cord when the session ends.  While those
background services are waiting for their bus connection to disappear,
they're keeping the session alive (but in a "closing" state).

To me, KillUserProcesses=yes is better from a theoretical
it-should-have-always-done-this-if-it-could-have standpoint, and it's
better from real world
it-eliminates-a-class-of-bugs-that-has-plagued-us standpoint.

I don't like that it requires users to have to change workflows, so
that's a negative and I understand why the change is controversial.

We may want to consider reverting the user bus change for F24 and
revisit in F25, not sure.

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

Re: wayland in rawhide

[Ray Strode]

Hi,

On Mon, Nov 16, 2015 at 3:35 PM, Jared K. Smith
 wrote:
> Can you please tell me where to find this config option, as I can't seem to
> find it -- and I'm getting annoyed with Wayland enough to go back to X for a
> week or two until things improve.
WaylandEnable=false in /etc/gdm/custom.conf is what I was talking about, but
one of the things I added as a result of this thread is a

GNOME on Xorg

option in the session list in gdm.


 > The latest issue I'm seeing (and the one
> that bugs me enough to go back) is a set of weird cursor artifacts, as shown
> in this screencast:
That's tracked here:

https://bugzilla.gnome.org/show_bug.cgi?id=758025

--Ray
-- 
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: wayland in rawhide

[Ray Strode]

hi,

> Here's one on Ironlake, with two monitors plugged in.
>
> https://bugzilla.gnome.org/show_bug.cgi?id=750610
>
> still not fixed, doesn't fall back.
Well, black screens obviously aren't good, and we should clearly fix this.

If we don't get it fixed by closer to release, than maybe it's a good
data point for switching
back to Xorg for fedora 24.  But note:

1) 3 monitor setups are somewhat more rare than one and two monitor
setups, so it's important to fix, but the impact is more limited so
the problem didn't get as much exposure as it would have otherwise.
2) the bug was reported by a developer who has reproducing hardware
and intimate domain knowledge around the functions related to the
failure (you).

I'm sure we can figure this one out after a few minutes poking at it
with the hardware.  If not you, then me, or Rui, or a hand full of
other people.

Regardless of what this bug means for Fedora 24, I don't think it
should affect what we're doing for rawhide.

--Ray
-- 
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: [RFC] DistGit Container Image namespacing for Layered Image Build Service

[Ray Strode]

Hi,

On Tue, Nov 10, 2015 at 1:08 PM, Adam Miller
 wrote:
> If we were to go with the former rather than the latter, we would need
> to find a way to "namespace" container images so they can be
> determined as different. I've thought about this a lot and I worry
> about defining a namespace by some alphanumberic sequence because I
> just know that at some point there will end up being a piece of
> software in the ecosystem that we want to package as a rpm that will
> share this pattern and result in problematic filtering. We could
> accept that risk and simply say "this sequence is a reserved word" or
> use a special character as the leading character in a DistGit
> repository name to signify that it is a container.

git repositories normally use '/' to separate namespaces, so i'd propose

$ fedpkg clone containers/cockpit

and maybe add support for

$ fedpkg clone srpms/cockpit

at the same time.

This has the added benefit that cgit will automatically filter docker
reposistories when you visit, e.g,

http://pkgs.fedoraproject.org/cgit/containers/


--Ray
-- 
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: wayland in rawhide

[Ray Strode]

Hi,

> This seems still still be confusing a lot of people, I see quite
> regularly queries on some forums like G+ that when they upgrade to
> anything post F-21 all they get is a black screen on boot. Is there
> any way that if way for that to happen automatically where they don't
> get to a gdm login prompt?

Well it's supposed to automatically happen if users don't get a GDM
prompt, but there was a case with hybrid hardware where we sending the
prompt to the wrong card.

That was fixed in this bug I think:

https://bugzilla.gnome.org/show_bug.cgi?id=753434

--Ray
-- 
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: wayland in rawhide

[Ray Strode]

Hi,

> So I upgraded to F23 just around Alpha or Beta can’t remember and I’ve 
> experienced some odd mouse / copy paste behaviour. I haven’t yet filed a bug 
> but now I’m wondering… How do I know if I’m using Wayland? I’ve never 
> specifically configured it so anything I’m experiencing in a normal GNOME 3 
> session is either ‘normal’ but I don’t like it, configurable change that has 
> a different default or some weird bug… I’d like to know if I’m somehow not 
> using X anymore, and that’s the problem.

It's unlikely that you're using wayland in Fedora 23 since it's not
the default.  You can check if you're on wayland by running

$ ls -l $XDG_RUNTIME_DIR/wayland-0

if it returns a socket you're probably using wayland.
-- 
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: wayland in rawhide

[Ray Strode]

Hi,

On Thu, Nov 12, 2015 at 5:51 AM, Jared K. Smith
 wrote:
> I've been testing Wayland myself since around the F22 time period, but
> "middle click paste" and the occasional odd bug keep annoying me enough to
> go back to X.  Can you elaborate on the plans for supporting middle click to
> paste, or is it considered a relic of a bygone era and I should try to
> unlearn?

Plans for middle-click paste are tracked here:

https://wiki.gnome.org/Initiatives/Wayland/PrimarySelection

--Ray
-- 
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: wayland in rawhide

[Ray Strode]

Hi,

On Tue, Nov 10, 2015 at 4:32 PM, David Airlie  wrote:
> I'd rather we waited until wayland sessions are feature equivalent with X.
Note this is in rawhide, early in the Fedora 24 devel cycle.  If things don't
work out, going back isn't hard.

> Sweeping this under the carpet and then not providing users any way to get to 
> something that
> works on their hardware.
We fall back to X in cases when we notice things aren't working, just
as we do for the login screen.
Remember we've been shipping the login screen on wayland for 2 releases now.
And we provide a config option to turn wayland off explicitly for
cases where users just want or need
to use X.

--Ray
-- 
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: wayland in rawhide

[Ray Strode]

Hi,

On Wed, Nov 11, 2015 at 7:58 PM, David Airlie  wrote:
>
>> That's fine.  I don't have a problem adding "GNOME on Xorg" option to
>> the session
>> menu in the interim. I'll do it tomorrow.
>
> This is what the feature page said would happen in the first place. So
> I'm also confused why you didn't just do that.
Initially the feature page was written before Fedora 23.  I was involved in
a more recent discussion about the implementation details of
pushing the big red switch, and having one item that did fallback was the
conclusion of the discussion.  I did edit the wiki to say this:

Users will be able to disable wayland by setting WaylandEnable=false
 in /etc/gdm/custom.conf but there will no longer be two separate menu
items for GNOME on Wayland and GNOME on X11.

before I posted the announcement.  Did I miss somewhere else on the
page that contradicts that? or are you alluding to back when the page
was first written?

> These are just the missing features (never mind dialog boxes in wierd places 
> bugs)
> and it doesn't even contain the USB output hotplugging, or secondary GPU 
> output use cases.
That list isn't exactly accurate. Some of the items on their have been
fixed since they were
added pre-f23.  I did peck at the list a little, but  I'll do a more
exhaustive update tomorrow.

--Ray
-- 
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: wayland in rawhide

[Ray Strode]

Hi,

On Wed, Nov 11, 2015 at 3:35 PM, David Airlie  wrote:
> Maybe trialing GNOME on wayland as the default is premature but removing the 
> option
> on login to use GNOME on X is definitely. As such I respectfully ask you put 
> that
> option back in rawhide.
So just to be clear, there is an option to use X.  It's the same
option people have used
to force the login screen to X the past two releases.  It's just been
extended to apply
to user sessions as well.  You're objection isn't that there is no
option, it's that it's not
as prominently placed as you'd like it to be.

That's fine.  I don't have a problem adding "GNOME on Xorg" option to
the session
menu in the interim. I'll do it tomorrow.

I will say you're coming off (to me anyway) as somewhat combative.  We're on
the same team here.  Let's keep it constructive and friendly?

> If you still disagree, I'll probably have to spend time I could spend working 
> on
> stuff, taking this through some Fedora process I haven't had to deal with.
I think your input when the system-wide change is discussed would be valued.
Clearly, any help you provide with wayland is valued as well.

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

wayland in rawhide

[Ray Strode]

Hey guys,

Today I built snapshots of gnome-session gdm gnome-shell and mutter
that change how we do sessions at the login screen. We'll no longer
have separate items for GNOME and GNOME on Wayland.  Instead they're
now both consolidated under the GNOME item.  That item will use
wayland if it can, but if it falls back (because of a failure or
nvidia proprietary drivers, or the user explicitly disables wayland in
/etc/gdm/custom.conf) then that GNOME item will use Xorg instead.

I'm doing this for now in rawhide as preparation for this system-wide
f24 change:

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

If things don't pan out for whatever reason, or the change gets
otherwise rejected for f24, we'll split the items back out into two
items.

But it's good to get this in rawhide now, so we can get as much
exposure as possible to potential wayland problems and get them fixed
up before release.

Just a heads up ! If you're a rawhide user please test!

--Ray
-- 
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 running gui applications as root

[Ray Strode]

Hi,

> It's certainly the case that *gnome* might do something ridiculous if
> you 'sudo gedit' something, but 'sudo emacs' really ought to be
> equally acceptable regardless of whether you're using the terminal or
> X frontend.
emacs is probably okay, just by virtue of the fact that if the admin gives
the user the right to run emacs as root, they almost definitely trust the
user with general root access.

In that same light, it's probably fine if the user running sudo has full
access to sudo anyway, but it's considerable riskier if it's a restricted
sudo configuration or say consolehelper (or worse a setuid application!).
The problem is that X is a big api and it's designed with the notion that
everyone who has access to the display is pretty much at the same
trust level. It's possible to prod and poke at one client from other clients
 in pretty arbitrary ways.

As I know you know, it's generally a good idea to have code running
with elevated privileges as self contained as possible and accessible
with as narrow an interface as possible.

the wayland protocol is a little better than X, it doesn't let clients see
much past themselves, or let them influence other clients in as ad hoc
of ways.  Still, code running with elevated privileges should be *small*,
doing whatever job it's supposed to do.  And that job shouldn't be
interacting with the user. you don't need elevated privileges to interact
with the user, so why would put the code to interact with a user in a
process running with elevated privileges ?

polkit solves the problem nicely because it encourage separating
mechanism from interface, and gives fine grained control via named
actions, not programs.

Anyway, that's the argument, as I understand it, in broad strokes.

--Ray
-- 
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: Do you know how many 64-bit architectures Fedora has?

[Ray Strode]

Hi,

 If someone can
 suggest a better way than how I'm doing it now, I'm all ears, because I hate
 this patch[0].
I think the solution you came up with from this thread is okay as a
downstream hack, but I think a better solution would be to get
upstream to ask apt at built time where to put methods.  It seems apt
has an apt-config binary for this:

$ apt-config dump |grep Dir::Bin::methods
Dir::Bin::methods /usr/lib64/apt/methods;

So there's no reason this needs to be hardcoded at all.

Even better would be if apt would ship this information in it's
pkgconfig file, then it could be queried using pkg-config.

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

[Ray Strode]

On Sat, Feb 21, 2015 at 7:20 AM, Vit Ondruch vondr...@redhat.com wrote:
 Same experience with gdm-3.15.90.1-1.fc23 here. I had to downgrade to 
 gdm-3.15.3.1-4.fc22.x86_64 to be able to log in again. Nevertheless, this 
 seems to be know issue, since there is already this [1] commit in dist-git, 
 unfortunately the associated sources are missing so far :/


odd i thought i built that yesterday. something must have went wrong,
will built it today




 [1] 
 http://pkgs.fedoraproject.org/cgit/gdm.git/commit/?id=5c5ff1efb9b5901b5448358304091c0f9b768cad

 - Original Message -
 From: Alexander Ploumistos alex.ploumis...@gmail.com
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
 Sent: Saturday, February 21, 2015 10:55:01 AM
 Subject: Re: Changes in the f22 workstation

 On Sat, Feb 21, 2015 at 10:11 AM, drago01 drag...@gmail.com wrote:
 Can you be more specific? What kind of systems? What didn't work?

 I tested the 20150218 image in a vm and when it booted, gdm did not
 display the user list and there was no way to lift the screen lock.
 Also, I was unable to switch to another vt. I know it's not a real
 machine, but with the test image from a little less than a month ago,
 I had no such issues.

 When F21 came out, I had tried the wayland gnome session on an old
 i686 system (dual Athlon MP, GeForce 6800) with both nouvau and with
 the proprietary driver and the session just crashed every 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
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
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

[Ray Strode]

Hi,

On Sat, Feb 21, 2015 at 8:07 AM, Ray Strode halfl...@gmail.com wrote:
 odd i thought i built that yesterday. something must have went wrong,
 will built it today
I guess I got distracted and didn't upload the source tarball.  building now.
In the meantime, you can workaround the bug by setting
InitialSetupEnable=false in /etc/gdm/custom.conf

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

[Ray Strode]

Hi,

On Fri, Feb 20, 2015 at 7:00 PM, Pete Travis li...@petetravis.com wrote:
 I'm nervous about GDM on Wayland; Wayland has never worked well on my
 systems.  Can you talk about fallback strategies a bit?  Can GDM detect when
 Wayland isn't working well enough to be usable, and cleanly fall back?
It tries to.  We do start X in a different way now when falling back
(as part of the user session, instead of as root outside of the user
session), so there may be bugs that need to get ironed out.  It worked
okay in my limited testing though (putting nomodeset on the kernel
commandline on my intel based laptop)

 That's probably a big ask, though; presumably this can be set one way or
 another by the user?
Right you can put WaylandEnable=false in the [daemon] section of
/etc/gdm/custom.conf to skip wayland altogether.

--Ray
-- 
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!

[Ray Strode]

Hi,

On Wed, Dec 17, 2014 at 4:14 AM, Richard Hughes hughsi...@gmail.com wrote:
 I'm erring on the network panel in gnome-control-center; but I agree
 there's no really good place for this kind of thing.
maybe key whether or not to download updates based on the zone (which
is used strictly for firewall atm, but could potentially be
generalized)...
-- 
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 handle upgrades to Fedora 21

[Ray Strode]

Hi,
 I agree with Rahul that standard is not a great name for the
 nonstandard, non-productized upgrade, though. Generic is more
 descriptive anyway.

I'm not sure it's worth repainting the bikeshed at this point, but
during the alluded-to discussion a few alternative names came up that
would have been better than fedora-release-standard:

1) fedora-release-nonstandard
2) fedora-release-custom
3) fedora-release-diy
4) fedora-release-noncompliant

and i'll just throw another out there now

5) fedora-release-respin

If we do want to change it, it should happen soon

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

[Ray Strode]

Hi,

- Original Message -
  We should be enabling the user to get the things
  done he/she cares about, not forcing them to learn the things we care
  about.
  
  There should be no You must be this tall to ride Fedora Workstation
  signs.
 [...snip...]
 
 Is it the intent that the developer cases here completely subsume the
 case of a developer who is working primarily on Fedora itself
 (including the Worsktation)?  Perhaps we should call that out to
 correctly prioritize integration of the various developer tools
 currently available or planned for the Workstation.

That's a good point, too. My mail is trying to make sure we consider 
developers who don't work on Fedora, but just use Fedora for development.
Paul makes a very reasonable point that we should be clear to accomodate 
(and not alienate) ourselves (Fedora contributors) as well.

So, as a throw-away example..., It might not make sense to have fedpkg in
the default install, but having an easily obtainable Fedora SDK of sorts
that includes all the bits needed to get up and going might be a good idea.

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

[Ray Strode]

Hi,

I think this is a pretty good starting point for our development direction, and
sets the stage for us making positive progress in the new working group model.

I do think we should keep it open to tweaks in the future as things
play out, (at
the discretion of the 9 members on the working group).  In other words, I think
it lays a solid outline for enabling us all to know which direction to go, but
i want to make sure if it doesn't ever get in the way. The working
group should
treat it as a living document that gets updated as necessary to
reflect changes in
the landscape.

Some comments inline below (mostly nits):

 Fedora Workstation PRD

 Mission statement
 The Fedora Workstation working group aims to create  a reliable,
 user-friendly and powerful operating system for laptops and PC hardware.
 The system will primary be aimed at providing a platform for development
Extra space between create and a reliable
s/primary/primarily/

 Target audience
 General:
 Programming Environment: web languages and tools, open source databases, IDE,
 Compilers, debug tools, performance monitoring
 Desktop apps should be sufficient to make this system the users's only 
 computer.
s/users's/user's/

While I'd certainly like us to aim more generally, I understand we have to have
some focus, and given the technical pre-existing userbase this is a pretty good
one.

I think if we do a good job, we'll be able to attract all sorts of users
outside of our prescribed target audience, though.

 Case 1: Student
 Engineering/CS student who needs a personal system for software class wor and
 personal projects. Software class work may require particular tool chain
 versions. Tries out new versions of open source applications when released.
 Uses computer to play games.
s/class wor/classwork/

I think this is a good one to target, because the student pool is a good place
to recruit new contributors, and they're more likely to show up if we're making
something they want to use.

 Ability to play 3D games from commercial publishers distributing games for
 Linux.
makes sense.

 Multiple developer environments i.e. school standard for class work,
 latest tools for personal use.
s/i.e./, e.g.,/

I guess this may also involve a virtual machine, if the class is standardizing
on some windows tools.

 Case 2: Independent Developer
 Personal development system for an independent software developer doing
 contract work or developing apps for a new opportunity.

 Desktop Apps: Up to date desktop with email client, browser, productivity
 suite, messaging, and  complete set of desktop apps and utilities.  Desktop
 apps should be sufficient to make  this system the developer's only computer.
s/and  complete/and a complete/
s/make  this/make this/

[... snip other use cases that sound good ...]

 Other users
 While the developer workstation is the main target of this system and what we
 try to design this for, we do of course also welcome other users to the
 Fedora Workstation. In fact many of the changes and improvements we expect to
 implement for developers will be equally beneficial to other user segments,
I think this is a really important point.  Developers are users, too,
just trying
to get their work done.  We should make sure the OS doesn't get in the way, and
that it doesn't enforce artificial barriers to entry.  Just because a user may
know how the sausage is made, doesn't mean we should make them stuff their own
(so to speak).  And if a user/developer doesn't know the inner workings of
Fedora, that's okay, too.  We should be enabling the user to get the things
done he/she cares about, not forcing them to learn the things we care about.

There should be no You must be this tall to ride Fedora Workstation signs.


 Overall plans and policies for the product
 Bullet list numerating the technical goals and design principles of the 
 product

s/numerating/enumerating/. Though, maybe the fact that it's a bullet list is
self-evident.  How about just, Technical goals and design principles:

 Robust Upgrades
 Upgrading the system multiple times through the upgrade process should give a
 result that is the same as an original install of Fedora Workstation. Upgrade
 should be a safe and process that never leaves the system needing manual
 intervention.

safe and what? safe and pleasant? safe and reliable?  It might be good to have
some notion of frequency of updates.  Do we keep them asynchronous?  Do we ask
rel-eng to queue them up into batches?  I've seen some people complain about
the fedora firehose.  Maybe that's a discussion for a different time, and not
this document.  I don't know.

 Encapsulation of development environments
[...]
 Quality releases
[...]
 Container based application install
[...]

I'd reorder these so they are grouped better.  Put Encapsulation and Containers
next to each other, and put Quality Releases and Robust Upgrades next to each
other, too.

 3rd party software Fedora Workstation will work with partners and ISVs 

Re: Is Gnome Software ready for primetime ?

[Ray Strode]

Hi,

On Fri, Nov 1, 2013 at 3:27 PM, Tim Lauridsen tim.laurid...@gmail.com wrote:
 Cleaned up the appdata xml

 https://github.com/timlau/yumex/blob/master/misc/yumex.appdata.xml

Small errors here:

   liControl want package repositories there is enabled for current
session/li

maybe should be:

   liControl what package repositories are enabled for the current
session/li

--Ray
-- 
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 Workstation WG Governance Charter

[Ray Strode]

Hi,

On Wed, Oct 30, 2013 at 9:01 AM, Josh Boyer jwbo...@fedoraproject.org wrote:
 The other positions will be filled by general election
 every two years. As a special exception, four seats will be filled in
 one year, with those positions chosen at random (unless some number of
 members decide to step down). Voting will follow the standard Fedora
 election process and be open to all contributors in the CLA+1 group.

 In the event that a current member relinquishes their seat, that seat
 will be filled by the first runner up in the previous election.  If
 that person is not able or willing to fill the seat, it will go to
 each successive runner up until the seat is filled.

I think, I personally, would rather see the previous working group
decide new members of the working group.  They're the ones doing the
work, so they should get the most say in the direction the work goes.
(the whole fedora is a meritocracy not a democracy thing).

Put another way: I don't think someone who works on desktop related
software should have much say in who gets to be put in the cloud
working group, or vice-versa.

Let the people already doing the work decide the continuing direction
of the work.
If things really get off course, fesco can intervene, but I don't
think that will happen.

--Ray
-- 
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 Workstation WG Governance Charter

[Ray Strode]

Hi,

On Wed, Oct 30, 2013 at 3:22 PM, Josh Boyer jwbo...@fedoraproject.org wrote:
 In your opinion, should we have term limits imposed to ensure we have
 fresh members coming into the WG?  As I said in another email, I think
 we should shoot for some continuity while also encouraging new members
 to step up.

Not sure.  I mean, as the saying goes if it ain't broke, don't fix
it.  Making membership autorotate kind of contradicts that little bit
of wisdom. I think when people get tired or ineffectual, they'll say
so, and relinquish their seats. People know when they're burned out,
or when they're not helping for the most part.  And I think the people
on current working group have good intentions, and are willing to
objectively put the project first.

--Ray
-- 
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 Fedora boot experience

[Ray Strode]

Hi,

On Thu, Mar 14, 2013 at 6:30 AM, Björn Persson
bj...@xn--rombobjrn-67a.se wrote:
 How about turning the messages that Plymouth needs to display into
 pictures? There would be a set of pre-rendered image files with
 translations of the phrase Press Esc if you want to see what's going
 on. for all the different locales, and the correct image for the
 configured locale would be included when the initrd was generated.
 Plymouth would then just put that picture up on the screen, not caring
 about what language it's written in or with which font.
Yea, we've talked about doing that before.  We've also talked about
querying the console font.  So definitely possibilities to address the
limitation.

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

Re: Improving the Fedora boot experience

[Ray Strode]

Hi,

 This is an interesting idea, but I don't think plymouth makes it any
 easier to display CJK  Indic glyphs. (Please someone more technical
 tell me if I'm wrong here, I vaguely remember this being an issue when
 we wanted to add a messagse to fedup)

 I hoped that it would be easier to localize plymouth compared to grub2. In
 addition to that we'd also get rid of problems resulting of the
 interaction between grub2 s gfx stack and the kernel/plymouth, and last but
 not least we wouldn't need to maintain a theme for grub.
Yea it's not really easier.  We start plymouth in the initrd, and we
don't have fonts, translations, font rendering libraries or anything
in the initrd.  we could ship those things in the initrd but it would
make the initrd substantially larger.

Of course we can do localized text fine on systems that don't have
initrds, or at later points in the boot process after we've switched
out of the initrd.

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

Re: Improving the Fedora boot experience

[Ray Strode]

Hi,

On Tue, Mar 12, 2013 at 6:15 PM, Matej Cepl mc...@redhat.com wrote:
 And which doesn’t nonsensically short timeout, so that I manage to get
 booted sometimes only on third or fourth attempt (yes, I am easily
 distracted to do something else while the system boots up; you have
 a problem with that?) I have never understood the sense of this timetout
 anyway ... if I want to let stay half-booted system (before the hard
 drives are unencrypted) while I go for weekend trip, why should systemd
 have to have problems with that?
That's just a bug:

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

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

Re: Fedora Members Absent or present?

[Ray Strode]

Hi,

 Interesting script. Is it planned bring it into Fedora rpm? Say in
 fedora-packager or standalone package?
It does seem interesting, though, when I run it on me it doesn't give
dates for recent mailing list posts, and isn't able to show bugzilla
activity.

Still, very cool hack, overall!

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

Re: Install from ISO file supported

[Ray Strode]

Hi,

 1. Download a LiveCD Fedora.iso (it takes less time than download the DVD
 iso file)
 2. Launch  fedup --iso Fedora-LiveCD.iso, that make the job of adjusting
 GRUB2 i.a.
 3. Reboot the system
 3. Choose LiveCD entry from GRUB2) Perform the installation as you wish
Unfortunately, the way the livecd's currently work, they can't be used
to do upgrades. They merely copy the live installation byte for byte
to the selected hardisk volumes, blowing away anything that's already
there.

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

Re: Install from ISO file supported

[Ray Strode]

Hi,

 I find it easier (and smaller) to download the netinst.iso (like
 Fedora-18-x86_64-netinst.iso)
 Loop-back mount and pull the vmlinuz and initrd.img into /boot
The vmlinuz and initrd are made available separately here:

http://mirrors.kernel.org/fedora//releases/18/Fedora/x86_64/os/images/pxeboot/

So you can avoid the loop-back mount.  It's a good tip, though.
Sometimes creating a grub entry is the most straightforward way to get
things rolling.

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

Re: prefered way of configuring X11 keyboard layouts in F18

[Ray Strode]

On Thu, Dec 20, 2012 at 3:49 PM, Sérgio Basto ser...@serjux.com wrote:
 On Qui, 2012-12-20 at 20:16 +0100, Nicolas Mailhot wrote:
 IIRC, an anaconda bug already exists (don't remember the number, I do
 remember answering some questions Mismo asked about the Debian system
 there)

 I need the number

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

and

https://bugzilla.redhat.com/show_bug.cgi?id=837292
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd requires HTTP server and serves QR codes

[Ray Strode]

Hi,

On Mon, Oct 8, 2012 at 1:07 PM, Lennart Poettering mzerq...@0pointer.de wrote:

 Correct. Note that this is not accessible at all, by default, and mostly
 a preview for now. Later on we will add http digest auth and proper TLS
 support (including client certs) if people want to control
 access. (thankfully, libmicrohttpd already implements auth+tls, so this
 is easy for us to provide).
I think negotiate-auth would be a really good feature here, since many
enterprise deployments use kerberos based SSO in their intranets.

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

Re: Install Fedora Button for LiveCD

[Ray Strode]

Hey again,

On Fri, May 4, 2012 at 9:19 AM, Cosimo Cecchi cosi...@gnome.org wrote:
 // provided by the 'anaconda' package
 anacondaApp = Gio.DesktopAppInfo.new('anaconda.desktop');
 if (!anacondaApp)
     anacondaApp = Gio.DesktopAppInfo.new('liveinst.desktop');

 I think you only want liveinst.desktop and not anaconda.desktop.
 Minimally, you need to swap them so liveinst.desktop gets run by
 default.

 Yeah good point - I copied that code from Kalev's notification, but it
 seems /usr/share/applications/anaconda.desktop is not provided by any
 package in my F17, so I now just removed it.
Sorry to give you bad advice, I was totally wrong.

We do this in the kickstart file:

mv /usr/share/applications/liveinst.desktop
/usr/share/applications/anaconda.desktop

I believe we do that so the WM_CLASS matches.

My misguided messages was because I was worried anaconda was getting
run instead of /usr/sbin/liveinst

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

Re: Install Fedora Button for LiveCD

[Ray Strode]

Hi,

On Thu, May 3, 2012 at 4:22 PM, Cosimo Cecchi cosi...@gnome.org wrote:
 What do you think?

 [1] https://github.com/cosimoc/fedora-welcome

Looking I see this:

// provided by the 'anaconda' package
anacondaApp = Gio.DesktopAppInfo.new('anaconda.desktop');
if (!anacondaApp)
anacondaApp = Gio.DesktopAppInfo.new('liveinst.desktop');

I think you only want liveinst.desktop and not anaconda.desktop.
Minimally, you need to swap them so liveinst.desktop gets run by
default.

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

Re: disruptive libffi upgrade

[Ray Strode]

Hi,

On Fri, Apr 13, 2012 at 10:06 AM, Colin Walters walt...@verbum.org wrote:

 You have to temper guidelines with some thought.  How recently
 have these symbols been introduced?  Are you aware of anything that
 actually calls them?  If nothing does, have you considered simply
 removing them?   Or, have you considered just keeping the symbols
 but making them do nothing?

Put another way, so name bumps are for when incompatibly changing the
API, but these functions were never officially part of the API.  Any
program that used them, was using the library in an off-label way, and
they can expect undefined behavior from doing so (including undefined
symbols errors at startup).

Likely, there are no such programs anyway, so it's moot, I guess.  I
guess there's a slight risk a program isn't using lazy binding, but
not sure it's a big enough risk to bother caring.

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

gnome 3.2

[Ray Strode]

Hey everyone,

I'm going to be doing a big gnome 3.2 update for f16 soon and as such
I've been running a script to automate package bumps/rebuilds.

The script[1] is pretty hacked together so it may not always do the
right thing.  It's chugging through the output of jhbuild list for
the gnome-apps-3.2 moduleset[2] cross referenced with releases sent to
gnome's ftp-release-list[3]

If you've seen a build go by from me, that's probably why.

Because the script is so adhoc it may make a mistake or two or three
or four.  If that happens just let me know in private email or on irc
(i'm halfline) and i'll try to correct it.

--Ray

[1] http://rstrode.fedorapeople.org/build.sh.txt
[2] http://rstrode.fedorapeople.org/3.2-packages.txt
[3] http://mail.gnome.org/archives/ftp-release-list/2011-September/thread.html
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

tomboy orphaned

[Ray Strode]

Hey guys,

A long, long time ago (before the extras/core merge in fact i think) i
was given tomboy to help spread the influx of mono packages across
desktop team.

IIt's a neat program, but I don't really use it. I'm more of a
send-myself-email/scribble-on-whiteboard kind of guy.  I'm also not
very good about maintaining it.

I've orphaned it now.  If anyone is interested in it, feel free to take it.

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

Re: SSD support in Anaconda/F14

[Ray Strode]

Hi,

On Sun, Dec 26, 2010 at 10:32 AM, drago01 drag...@gmail.com wrote:
 You don't want to use LVM (and you should mount the fs with the
 discard option for trim to work).
At plumbers it came out during the filesystem talk that the discard
option is a really bad idea.  It apparently has performance and
reliabilty problems.  Apparently, you're just supposed to run a
command manually (that I don't remember of hand) when your disk starts
to fill up.

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

Re: pulseaudio crashes: non-responsive maintainer Lennart Poettering

[Ray Strode]

Hi,

On Sat, Nov 20, 2010 at 4:52 PM, Kevin Fenzi ke...@scrye.com wrote:
 filed month+ ago:
       https://bugzilla.redhat.com/show_bug.cgi?id=643296

 Simple fix of memory corruption affecting various applications incl.
 Firefox.

 Completed Policy for nonresponsive package maintainers there, got an
 off-list reply but still no fix commit or commit rights approval.

 Lennart is surely around...
I wonder if the nonresponsive package maintainers policy should have a
provision for ping maintainer on irc

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

Re: updates-testing trainwreck.

[Ray Strode]

Hi,

On Fri, Nov 19, 2010 at 12:15 PM, Dave Jones da...@redhat.com wrote:
 Wtf happened in updates-testing ?

 gdm and a bunch of other stuff crashes on startup..

  gdm[1622]: #9  0x0032031195aa in gtk_icon_theme_lookup_icon () from 
 /usr/lib64/libgtk-x11-2.0.so.0
  gdm[1622]: #10 0x00320311a08c in gtk_icon_theme_load_icon () from 
 /usr/lib64/libgtk-x11-2.0.so.0

Maybe your icon cache got corrupt somehow?

does

touch /usr/share/icons/*

fix things?

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

Re: ConsoleKit documentation needed

[Ray Strode]

Hi,

On Fri, Aug 13, 2010 at 4:17 PM, Christoph Wickert
christoph.wick...@googlemail.com wrote:
 What are they doing and how is ck-launch-session different from 
 ck-xinit-session?
The differences are extremely minor.  The latter was written first to
fill a specific need for fedora and was stuffed in the xorg-x11-xinit
package, while the former is what ended up making its way upstream.
They do the same thing.

 The background of this question is that there are problems accessing
 removable media in LXDE and Xfce when logging in in runlevel 3 and then
 using startx. I know I can fix these problems by executing startlxde or
 startxfce4 through ck-launch-session, but honestly I have no idea what
 I'm doing.
I don't think you should need to do that.  ck-xinit-session is run
automatically by /etc/X11/xinit/xinitrc

 What is the recommended way to open and close a ConsoleKit session when
 logging in in runlevel 3?
pam_ck_connector does it at login time (for the terminal session) and
then xinitrc does it at startx time.

 Should this be done in the scripts that strart the desktop environment?
No.  The only time it should be run manually is if the user is
explicitly trying to bypass the custom distro machinery with a
~/.xsession file or similar.  In that case, they need to do it
themselves (or not, depending on why they're choosing to use
~/.xsession instead of ~/.Xclients in the first place)

For most cases you shouldn't need to do anything.  I wonder if
something is clearing your environment? That program sets an
environment variable called XDG_SESSION_COOKIE that needs to make its
way into the session.

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

Re: [HEADS-UP] systemd is now the default init system in rawhide

[Ray Strode]

Hi

On Wed, Jul 28, 2010 at 6:26 AM, Lennart Poettering
mzerq...@0pointer.de wrote:
 On Sat, 24.07.10 00:14, Casey Dahlin (cdah...@redhat.com) wrote:


 On Fri, Jul 23, 2010 at 10:54:50PM -0500, Garrett Holmstrom wrote:
  On 7/23/2010 20:26, Lennart Poettering wrote:
   - You can boot into either of them by setting the init= kernel cmdline
      option according to your wishes. If you pass init=/bin/systemd you
      will boot into systemd, if you pass init=/sbin/upstart you will boot
      into upstart (note the /sbin vs. /bin!)
 
  Why is the systemd executable in /bin instead of /sbin?

 Without looking too closely I believe systemd eventually seeks to replace
 things like gnome-session daemon. It has session management in mind as well 
 as
 system.

 Yes, this is the case. Normal users can and should start it and it might
 even be invoked by scripts such as gnomerc or suchlike. On most
 distributions (with the exception of Fedora) /sbin/ is not in $PATH and
 hence the right place for the systemd binary is /bin/ and nothing else.

Could put systemd in /sbin and have a symlink to it called

 /bin/sessiond

That would also allow the daemon to know which mode it's running in.
 Still, probably not worth it.

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