Re: Orphaning packages (was LibreOffice packages)

[Bastien Nocera]

Do you want to pick up the rest of the libimobiledevice stack as well? That's 
ifuse, libplist, libusbmuxd and usbmuxd.
___
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

Orphaning packages (was LibreOffice packages)

[Bastien Nocera]

Hello,

As part of the same process outlined in Matthias Clasen's "LibreOffice 
packages" email, my upstream and downstream work on desktop Bluetooth, 
multimedia applications (namely totem, rhythmbox and sound-juicer) and 
libfprint/fprintd is being stopped, and all the rest of my upstream and 
downstream work will be reassigned depending on Red Hat's own priorities, as I 
am transferred to another team.

While it's possible that some of the maintenance will stay with me in the new 
team, I've not yet been told which team I would be joining.

Here is a list of Fedora packages which I maintained or co-maintained which I 
won't be able to contribute to anymore:
apfs-fuse
bluez
codespell
eosrei-emojione-fonts
geocode-glib
gnome-bluetooth
gnome-epub-thumbnailer
gnome-kra-ora-thumbnailer
gnome-user-share
gom
grilo
grilo-plugins
ifuse
iio-sensor-proxy
libfprint
libglib-testing
libimobiledevice
libpeas
libplist
libportal
libusbmuxd
low-memory-monitor
malcontent
power-profiles-daemon
sloccount
switcheroo-control
totem
totem-pl-parser
umockdev
usbmuxd

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

Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week

[Bastien Nocera]

On Fri, 16 Jun 2023 at 12:08, Miro Hrončok  wrote:

> On 16. 06. 23 9:57, Bastien Nocera wrote:
> >
> >
> > On Fri, 16 Jun 2023 at 09:48, Miro Hrončok  > <mailto:mhron...@redhat.com>> wrote:
> >
> > On 16. 06. 23 9:41, Bastien Nocera wrote:
> >  > Scolding people that haven't seen your original message for
> limitations
> > in the
> >  > build system isn't nice.
> >
> > Apologies for not being nice enough. However, we need to notify the
> folks who
> > do that and ask them to stop, because as you say, the system is not
> perfect.
> >
> > If you have specific suggestions, please speak up.
> >
> >
> > Yes, tell folks that they might have missed an email instead of sending
> a
> > scolding " Please, don't do that."
>
> Thanks for the suggestion. I honestly had no idea that "please, don't do
> that"
> could be considered unfriendly, but I hope that's language/cultural
> barrier
> (rather than me being a sociopath). I've adjusted my wording in the
> followup
> emails.
>

Thanks for heeding advice in good grace :)


> >  > I fixed my missing the devel-announce email by subscribing to the
> list
> > (though
> >  > this should probably be implemented somewhere in the accounts
> system)
> > but I'm
> >  > afraid I cannot do anything about the build system not allowing
> for
> > specific
> >  > blocking of builds in circumstances such as yours.
> >
> > I kindly ask you not to submit rawhide builds of packages that have
> been
> > already built in our side tag, until the side tag is merged. If you
> cannot do
> > that, I kindly ask you not to build any packages until the side tag
> is merged.
> > Unfortunately, asking people is the only thing I am able to do.
> >
> >
> > I'm talking about limitations in the build system that don't allow you
> to
> > automatically do what you're trying to get *people* to do instead.
> >
> > People are fallible, and filing an RFE for the build system would go
> some way
> > to shifting the burden to a computer.
>
> This has actually been discussed on this list several times already, but
> Fabio
> was kind enough to file that RFE today:
>
> https://pagure.io/koji/issue/3847
>
> That said, most of Fedora's RFEs to Koji that would make things easier for
> packagers seem to linger, presumably due to capacity reasons.
>

I think it's important, whether we can implement solutions now or not, to
track those problems. It will make it easier for others to find the ticket,
and comment on whether it would have been useful to them, and maybe figure
out just how much time they could have saved using those features.

Cheers

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

Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week

[Bastien Nocera]

On Fri, 16 Jun 2023 at 09:48, Miro Hrončok  wrote:

> On 16. 06. 23 9:41, Bastien Nocera wrote:
> > Scolding people that haven't seen your original message for limitations
> in the
> > build system isn't nice.
>
> Apologies for not being nice enough. However, we need to notify the folks
> who
> do that and ask them to stop, because as you say, the system is not
> perfect.
>
> If you have specific suggestions, please speak up.
>

Yes, tell folks that they might have missed an email instead of sending a
scolding " Please, don't do that."


> > I fixed my missing the devel-announce email by subscribing to the list
> (though
> > this should probably be implemented somewhere in the accounts system)
> but I'm
> > afraid I cannot do anything about the build system not allowing for
> specific
> > blocking of builds in circumstances such as yours.
>
> I kindly ask you not to submit rawhide builds of packages that have been
> already built in our side tag, until the side tag is merged. If you cannot
> do
> that, I kindly ask you not to build any packages until the side tag is
> merged.
> Unfortunately, asking people is the only thing I am able to do.
>

I'm talking about limitations in the build system that don't allow you to
automatically do what you're trying to get *people* to do instead.

People are fallible, and filing an RFE for the build system would go some
way to shifting the burden to a computer.

Cheers

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

Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week

[Bastien Nocera]

On Fri, 16 Jun 2023 at 08:50, Miro Hrončok  wrote:

> On 13. 06. 23 14:02, Tomas Hrnciar wrote:
> > Hello,
> >
> > in order to deliver Python 3.12, we are running a coordinated rebuild in
> a side
> > tag.
> >
> > https://fedoraproject.org/wiki/Changes/Python3.12
> > <https://fedoraproject.org/wiki/Changes/Python3.12>
> >
> > We anticipate starting this rebuildsometimethis week.
> >
> > If you see a "Rebuilt for Python 3.12" (or similar) commit in your
> package,
> > please don't rebuild it in regular rawhideor another rawhide side tag.
> If you
> > need to, please let us know, so we can coordinate.
> >
> > If you'd like to build apackageafter we already rebuilt it, you should
> be able
> > to build it in the side tag via:
> >
> > on branch rawhide:
> > $ fedpkg build --target=f39-python
> > $ koji wait-repo f39-python --build 
> >
> > Note that it will take a while before all the essential packages are
> rebuilt,
> > so don't expect all your dependencies to be available right away.
> Please, don't
> > attempt to build your package in the side tag before we do.
> > When in trouble, ask here or on IRC (#fedora-python on Libera.Chat).
> Ping me
> > (thrnciar) or Miro (mhroncok) if you need to talk to us.
> >
> > Builds:
> >
> https://koji.fedoraproject.org/koji/builds?latest=0=f39-python=-build_id=0
> <
> https://koji.fedoraproject.org/koji/builds?latest=0=f39-python=-build_id=0
> >
> >
> > Please avoid any potentially disturbing or major changes in Python
> packages
> > until the rebuild is over.
> >
> > Thanks. Let us know if you have any questions.
>
> The following packages were built in rawhide after they were built in out
> Python 3.12 side tag (f39-python):
>
> codespell
> devscripts
> iscsi-initiator-utils
> libxc
> miniupnpc
> petsc
> python-apypie
> python-bitarray
> python-boto3
> python-cerberus
> python-cloudflare
> python-hpack
> python-pyudev
>
> Please, don't do that.
>

Scolding people that haven't seen your original message for limitations in
the build system isn't nice.

I fixed my missing the devel-announce email by subscribing to the list
(though this should probably be implemented somewhere in the accounts
system) but I'm afraid I cannot do anything about the build system not
allowing for specific blocking of builds in circumstances such as yours.

Cheers


>
> I will now rebuild them in the side tag again.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
>
>

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

Re: Future of shared-mime-info in Fedora

[Bastien Nocera]

- Original Message -
> On 28. 08. 20 13:33, Bastien Nocera wrote:
> > I'm sorry, I read through the mail, but I don't understand what you'd want
> > me to say, or what questions you'd want me to answer.
> 
> You pretty much answered all the questions. Thanks.
> 
> > In short, I've maintained the upstream shared-mime-info for 16 years, and
> > now is the time to let others in the community maintain it, both upstream
> > and downstream. It is still absolutely required, but it's not important
> > enough to be able to set time aside for.
> 
> Understood.
> 
> > As for the mimeapps.list, you might need to peruse the shared-mime-info
> > specifications, which explain what the different files do:
> > https://specifications.freedesktop.org/
> 
> How is the list maintained in Fedora? Is there some working group (e.g.
> workstation) overseeing this or is it just the shared-mime-info package
> maintainer? Or is it Rex as indicated in
> https://lists.fedoraproject.org/pipermail/devel/2015-July/212403.html ?

It used to a direct copy of the Workstation (GNOME) defaults. Now it's a copy
of nothing, and folks that care about it can ask the new maintainer for
changes.

The GNOME/Workstation defaults now live in the gnome-desktop3 package. I'd
encourage other desktops to ship their own mimeapps.list files to set defaults,
and leave the mimeapps.list in shared-mime-info well alone (it shouldn't
be needed, but "it broke things" not to have, and I never actually knew what
it broke).
___
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: Future of shared-mime-info in Fedora

[Bastien Nocera]

- Original Message -
> Hello Fedorans, Bastien,
> 
> I have noticed that the shared-mime-info package was orphaned couple days
> ago.

I'm sorry, I read through the mail, but I don't understand what you'd want
me to say, or what questions you'd want me to answer.

In short, I've maintained the upstream shared-mime-info for 16 years, and
now is the time to let others in the community maintain it, both upstream
and downstream. It is still absolutely required, but it's not important
enough to be able to set time aside for.

As for the mimeapps.list, you might need to peruse the shared-mime-info
specifications, which explain what the different files do:
https://specifications.freedesktop.org/

Did I miss anything?

> Bastien, AFAIK you were the primary point of contact in Fedora and I also see
> you are the RHEL 8 default bugzilla assignee.
> 
> Considering the following commit:
> 
> https://gitlab.freedesktop.org/xdg/shared-mime-info/-/commit/6f4947b01
> 
> I've disregarded the idea the the package was orphaned by accident.
> 
> I also see that GNOME mime types have been moved away from the package (on
> rawhide only):
> 
> https://src.fedoraproject.org/rpms/shared-mime-info/c/da05922d10
> https://src.fedoraproject.org/rpms/gnome-desktop3/c/9909d22b
> 
> I always considered shared-mime-info an important package, however I don't
> see
> it in comps. Maybe it is no longer that important?
> 
> A repoquery reveals ~50 packages that require it including PackageKit, Thunar
> (Xfce), some NetworkManager packages, kdelibs (KDE)...
> 
> A recursive repoquery yields ~ 6650 packages.
> 
> I've taken the orphaned package for now to avoid any disruption (and a
> totally
> unreadable orphans report), but I don't really understand the Fedora package,
> it
> has a manually created source without any comment explaining where is this
> from:
> 
> https://src.fedoraproject.org/rpms/shared-mime-info/blob/master/f/mimeapps.list
> 
> Bastien, could you please give me a hint about this file? Thanks
> 
> -
> 
> The package technically has 8 co-maintainers and a sig, but I don't put much
> hopes into the crowd there considering they haven't touched the package in
> years.
> 
> Are there any interested Fedora packages that understand mime info better
> than I do
> 
> -
> 
> PS There is an interesting file-ownership problem reported in Bugzilla
> https://bugzilla.redhat.com/show_bug.cgi?id=1486468 - I plan to discuss this
> later on the packaging mailing list as well.
> 
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Many packages unnecessarily link to libpython

[Bastien Nocera]

- Original Message -
> Hello everyone,
> 
> As of Python 3.8, python C extensions modules should not link to libpython,
> unless they embed the interpreter in their code. Relevant upstream PR:
> https://github.com/python/cpython/pull/12946
> If your package links to libpython without requiring it, it won't be possible
> to use the python3-debug binary with your python C extension, unless you
> recompile the extension against it.
> 

> hadess libpeas libplist

libpeas embeds an interpreter, so that link is expected. libplist has been 
updated
in rawhide to fix the wrong linkage, but the library name has changed, so a 
couple
of modules might need to be fixed up and rebuilt. gvfs is one of them:
https://gitlab.gnome.org/GNOME/gvfs/-/merge_requests/88

Cheers
___
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: Call for participation: Fedora Flatpaks

[Bastien Nocera]

Urgh, unfinished trains of thought.

- Original Message -
> > * Benefit to Fedora contributors: they can make their packaging work
> > available across distributions and distribution versions.
> 
> Most likely duplicating upstream work on getting that same

...on getting that same application into end-users hands. What do you think 
would
happen to the opt-in creation of Fedora Flatpaks if you get none of the benefits
of being able to empower upstream with maintaining that package?

> > * Benefit to upstream: if they already have a good relationship with Fedora
> > and their application is well maintained there, they can point users on all
> > distributions to a Fedora Flatpak.
> > * Benefit to Red Hat: We build infrastructure technology and content that
> > we
> > can take into the RHEL context and make runtimes and Flatpaks available to
> > our customers with the type of guarantees that we are already providing for
> > RPM content.
> 
> That doesn't seem to require

That doesn't seem to require the Flatpaks to be build from binary RPMs, or RPMs
at all. The Fedora/RHEL runtime is part of the OS, so no duplication of work,
but packaging application-supporting libraries would be.
___
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: Call for participation: Fedora Flatpaks

[Bastien Nocera]

- Original Message -
> Hi Bastien,
> 
> Here are some of the benefits I see of this effort as compared to simply
> telling users to consume Flatpaks from Flathub or independent repositories:

Sorry it took a couple of days to get back to you.

If the end-goal is shipping Flatpaks, and that those Flatpaks need to be built
on Fedora infrastructure to be distributable, then we have some other options.

> * Benefit to Flaptak users on all distributions: more applications are
> available more quickly. Some applications will be much easier to create
> Flatpaks of this way because of their build dependencies. For lightly
> maintained, older applications, building a Flatpak of an RPM within Fedora
> is simple and avoids creating another independent place that someone has to
> keep an eye on.

For older, mature or not well-maintained, applications, I would think that
having them available through an upstream Flatpak would be more viable, sharing
maintenance with other distributions.

> * Benefit to Flatpak users on all distributions: this works towards having a
> runtime (whether Fedora or RHEL/CentOS based) that has a long lifetime and
> strong security update guarantees

Having a long lifetime and strong security update guarantees is also a goal
of the Flatpak Freedesktop SDK and runtime.

> * Benefit to Fedora users: they can get Flatpaks and runtimes from a source
> they already have trust in.

OK.

> * Benefit to Fedora users: this is a repository of Flaptaks we can enable by
> default (there are ongoing discussions of splitting up Flathub, but
> currently it combines both content that Fedora can point users to, and
> content that is problematical from a legal or Free Software point of view,
> all mixed together.)

Seems that this problem is being worked on then.

> * Benefit to Fedora contributors: they can work within the community and
> infrastructure they are already familiar with to fill gaps in the set of
> available Flatpaks.

Sure, it avoids creating more accounts, but the tooling is so different that
I don't think that it's going to help much.

> * Benefit to Fedora contributors: they can make their packaging work
> available across distributions and distribution versions.

Most likely duplicating upstream work on getting that same 

> * Benefit to upstream: if they already have a good relationship with Fedora
> and their application is well maintained there, they can point users on all
> distributions to a Fedora Flatpak.
> * Benefit to Red Hat: We build infrastructure technology and content that we
> can take into the RHEL context and make runtimes and Flatpaks available to
> our customers with the type of guarantees that we are already providing for
> RPM content.

That doesn't seem to require 

> LIke many things we do in Fedora, the benefit to RHEL is a big reason that
> we've been doing this work, and was an influence in some of decisions about
> how things were implemented, but I think the work does stand on its own as
> useful to the Fedora and Flatpak communities.

In summary, I think that building Flatpaks from Fedora binary RPMs in Fedora
infrastructure is not the right path forward:
- long-term supported runtime and SDK is a good thing, no questions, and that
  can probably be generated on Fedora infrastructure, as it shares so much
  with the Fedora OS itself
- Building Flatpak from binary RPMs is a bad idea. In Flatpak, you'd want the
  app dependencies (the ones that aren't part of the runeimt) to be as closely
  configured to what the application needs as necessary. That means that one
  applications might disable 99% of a library just to have the one plugin it
  needs to run, that wouldn't be possible when building from a binary RPM. That
  also means that the application is impacted by changes in those libraries, 
when
  the point of Flatpak is that the runtime is API and ABI stable, and all the
  rest is under the application's control. Think of every time you saw a mass
  change on the fedora-devel list, that's every time your application might 
break
  even though you didn't make a single change to it.

What I'd rather see would be:
- the tools working on source RPMs, rather than binary RPMs, and would generate
  flatpak-builder manifests. Those manifests can be then be used in Flathub,
  or by the upstream developers in their own repository, or used in the upstream
  project's CI to generate nightlies
- Because it has a global view of library usage, and compilation options, Fedora
  can make headway on de-duplicating those particular bits for inclusion in the
  runtime, or as shared build modules, similar to 
https://github.com/flathub/shared-modules
- the Fedora infrastructure can then use those upstream manifests, with little
  modification, to build against the Fedora SDK, on Fedora infrastructure, with
  Fedora signing keys, so that the chain of trust is not broken, whether with
  end-users or contributors
- those upstream maintained Flatpak manifests make it 

Re: Call for participation: Fedora Flatpaks

[Bastien Nocera]

Hey Owen,

- Original Message -
> I'd like to invite Fedora contributors to start creating Flatpaks of
> graphical applications in Fedora. We're still working on putting the final
> pieces into place to have a complete story from end to end, but it's
> definitely close enough to get started.

As discussed earlier in both mailing-lists and face-to-face, I'd like to know
why this is interesting for either upstream or downstream developers.

Who is the target for this feature, why does it make sense for packagers to
package within Fedora (or eventually CentOS, or RHEL), rather than upstream,
whether in Flathub or an independent repository?

I can expand on what I think are the benefits for Fedora, and its downstreams,
but that would require making guesses at roadmaps that I don't have a view
into.

Cheers
___
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: GNOME 3.30.0 megaupdate

[Bastien Nocera]

- Original Message -
> On Wed, Sep 5, 2018 at 9:04 AM, Kalev Lember  wrote:
> 
> 
> > Dunno what to do wrt the ongoing freeze and getting final 3.30 in F29
> > Beta, I guess it may be too late for that. Any opinions from QA here?
> 
> 
> If 3.29 is not what GNOME folks had ever wanted to ship in the Beta,
> why are we hearing about it one week before go/nogo? The schedule has
> been published for what, 9 months? *shrug*

GNOME has been releasing every 6 months on pretty much the same dates
for more than 10 years, and Fedora's schedule is modelled after GNOME's
for the purpose of getting things like GNOME, and other bi-yearly
time-based releases into Fedora. So Fedora knows well what schedule it
needs to adopt to get a .0 version of GNOME into the beta.

With GNOME 3.30 having been released yesterday, on schedule, I'm not sure
how either the Fedora packagers or the upstream could have done things
differently.

As a sidenote, this tone of discourse is frankly getting old. GNOME aren't
there to spite you.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned Packages in rawhide (2018-08-27)

[Bastien Nocera]

- Original Message -
> So audiofile has eight current maintainers (plus all of gnome-sig) but
> somehow none of those maintainers has admin privileges on the
> repository.  Would any of the maintainers like be made an admin so that
> SDL and everything that depends on it can drop out of this report?
> 
> Just let me know and I'll make the change for you.

Please consider it to be orphan, for all intents and purposes.

audiofile hasn't been a dependency of GNOME since the days of esound, so
somebody will need to pick it up and care for it.

Cheers
___
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: Testers for LCD Panel Self Refresh on laptops with Intel graphics wanted

[Bastien Nocera]

- Original Message -
> On Thu, Feb 01, 2018 at 12:34:50PM +0100, Hans de Goede wrote:
> > Hi All,
> > 
> > For the "Improved Laptop Battery Life" feature:
> > https://fedoraproject.org/wiki/Changes/ImprovedLaptopBatteryLife
> > 
> > I'm working on for Fedora 28 I would like to also try and enable
> > Panel Self Refresh on laptops with Intel graphics, some quick tests
> > have shown this to save another 0.5W (when idle / nothing on the
> > screen changes). This is currently off be default because it is
> > known to cause issues on some devices. So I think we will probably
> > need a white- or black-list. But first we need more data on this.
> > 
> > If you can spare 10 minutes, please see my blogpost for how to test
> > this and send me a mail with the info request in the blogpost:
> > https://hansdegoede.livejournal.com/18653.html
> 
> Hi Hans,
> 
> I didn't exactly play with the psr like you asked, but your blog intrigued
> me to play with powertop again.
> 
> On my Dell 5510 laptop, which has two graphics chips (intel for display,
> nvidia for external displays), setting the following to good:
> 
> Runtime PM for PCI Device NVIDIA Corporation GM107GLM [Quadro M1000M]
> 
> dropped me from 14W down to 6-7W.  And doubled my battery life.  Considering
> I normally don't connect up the external display, I find this a huge
> savings.
> 
> So indirectly I want to say thank you!

FWIW, switcheroo-control is supposed to turn off the discrete device on boot,
so you wouldn't need to do this. But it doesn't work with Secure Boot enabled
because of the location of the vga_switcheroo in /sys (under debug).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Bugzilla auto-CC

[Bastien Nocera]

Due to the sheer number of packages I have commit rights for (the whole 
inherited "gnome-sig" package list, https://src.fedoraproject.org/ shows 280 
packages), I'll be marking all mails from the Fedora section of the Bugzilla as 
read.

The infrastructure needs to be fixed instead of me doing busy work.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Bastien Nocera]

- Original Message -
> Bastien Nocera wrote:
> > However we end up doing it, I think it'd be better if we could do it
> > without you, whatever it is you do for Fedora. We, and certainly I, don't
> > want this level of toxicity and utter malfeasance on a mailing-list that
> > I'm supposed to be subscribed to.
> > 
> > Please, do leave, so you don't have to endure our apparent incompetence.
> 
> Nicolas Mailhot has done a lot of work on font packaging and organizing the
> Fonts SIG.

"What it is you do for Fedora" was meant as "even if you package half of the
distribution, it's irrelevant".

> Asking an experienced contributor like him to leave is extremely
> rude.

You probably skipped reading Nicolas' mail.

> All the more because you are just shooting the messenger. And you
> yourself admitted that you did not even bother looking him up before ruling
> him dispensable.

That's what you don't understand. I don't want to work with 10x brogrammers who
think they can get away with saying we are "forcing on everyone half-assed
software". I'll let you read the end of that sentence as well.

> This kind of toxic attitude is absolutely unacceptable. How about YOU leave
> instead?

That's funny that you'd use the same vocabulary I used to describe Nicolas' 
mail.
How is telling somebody who obviously thinks we're doing a bad job to leave 
"toxic"?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Bastien Nocera]

"We" in this case is me, my Red Hat colleagues working on GNOME, Fedora 
Workstation, upstream developers involved in Fedora Workstation and upstream 
developers who are not involved in Fedora, usually because of answers like this.

I'm also fine with you leaving. In fact, that's probably a request I made to a 
number of Fedora decision makers.

This has nothing to do with the apparent technical discussion and everything to 
do with the tone and vocabulary used. If you think we're that incompetent, or 
full of ourselves, then please, do leave, and show us how great you and your 
ideas are because I'm not, and we are not, going anywhere.

- Original Message -
> 
> 
> Am 17.07.2017 um 18:58 schrieb Bastien Nocera:
> >> 1. make flatpacked sofware behave like rpms in all the rpm-centric
> >> management
> >> tools, and remove the rpm layer only when everyone *in* *the* *Fedora*
> >> *universe* agrees it is not needed anymore and the replacements are
> >> better.
> >> 2. make a wayland, not a gnome 3.0
> > 
> > However we end up doing it, I think it'd be better if we could do it
> > without
> > you, whatever it is you do for Fedora. We, and certainly I, don't want this
> > level of toxicity and utter malfeasance on a mailing-list that I'm supposed
> > to be subscribed to.
> > 
> > Please, do leave, so you don't have to endure our apparent incompetence
> 
> who you you think you are?
> 
> that "we" includes the userbase GNOME centric people tend to forget and
> if you are not careful enough the "we" could remain some people making a
> distribution for their own usecase without a userbase
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Bastien Nocera]

- Original Message -
> On Sun, Jul 16, 2017 at 11:13:28PM +0200, Kevin Kofler wrote:
> > Matthew Miller wrote:
> > > I strongly dispute the idea that Fedora must be tied to a particular
> > > packaging technology.
> > 
> > The particular packaging technology is what ensures that we have a
> > coherent,
> > integrated system. Flatpaks by design cannot offer the kind of integration
> > that native packages can offer, neither in terms of using shared system
> > libraries (saving space), nor in terms of user experience (even with
> > "portals", there will always be kinds of interoperation that the sandbox
> > just cannot allow).
> > 
> > And if the users will get their packages in a generic format rather than a
> > native Fedora format, what advantage do they get from getting it from
> > Fedora
> > to begin with? The point of delivering Fedora packages is to integrate them
> > into the distribution. Only native packages can provide that.
> 
> Exactly, upstreams might as well just deliver .zip files which unpack
> into a single directory and provide a ./application.sh script to set
> up the LD_LIBRARY_PATH and cgroups right.  That's basically what we're
> talking about here when you strip it back to the essentials.

That's about as accurate as me saying that virtualisation is essentially
using the CPU's builtin virtualisation functionality when you strip it back
to the essentials.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Bastien Nocera]

- Original Message -
> >  There's a
> > burning the ships sort of appeal in that approach,
> 
> Actually, the correct analogy would be "burning platform" (and we all know
> how well that ended).
> 
> Flatpacks are an unproven tech that can still crash and burn in the market.
> 
> Even if it eventually succeeds crash-landing it in Fedora while half the
> security and management tools are lacking is a great way for the
> distribution to get an awful reputation, while others will rip the fruits of
> this work some years later.
> 
> It would be nice, for once, if the desktop team could integrate its latest
> idea in the distribution, and remove deprecated parts once the replacements
> are mature, instead of forcing on everyone half-assed software, with half
> the bits missing, no alternatives, and years of bad blood while they insist
> it is good enough and users are wrong to expect working workflows (yay for
> echo chamber effects and devs agreeing with themselves they are right but
> persecuted).
> 
> ie:
> 1. make flatpacked sofware behave like rpms in all the rpm-centric management
> tools, and remove the rpm layer only when everyone *in* *the* *Fedora*
> *universe* agrees it is not needed anymore and the replacements are better.
> 2. make a wayland, not a gnome 3.0

However we end up doing it, I think it'd be better if we could do it without
you, whatever it is you do for Fedora. We, and certainly I, don't want this
level of toxicity and utter malfeasance on a mailing-list that I'm supposed
to be subscribed to.

Please, do leave, so you don't have to endure our apparent incompetence.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Bastien Nocera]

- Original Message -
> 
> 
> Am 17.07.2017 um 12:16 schrieb Bastien Nocera:
> > It's like you didn't listen to the arguments when this feature was
> > implemented in Fedora years ago, and continue not to.
> > You're wrong, and the fact that you keep insisting you're not is frankly
> > intellectual dishonesty.
> > 
> > If you really believe you're correct, try to kill your X server in the
> > middle of an upgrade... Or simply re-read the tons of examples in the old
> > threads.
> 
> guess what happens when "dnf "i s running within a screen session and
> "KillUserProcesses=no" is set other then the silly default - the upgrade
> continues without any issue

Offline upgrades predate this systemd feature by a number of years. You also
completely dismiss the amount of work that might be needed to make it use
screen, whether screen can survive all the changes underneath it.

> so fix the update tools to work implicit that way instead burry the
> wrong handling with "oh we apply updates due reboot"

"Fixing the update tools" doesn't fix the breakage handled by applications
when you change files from underneath them. Again, read the original threads
to get a complete picture.

And when you take it all into account, the fix looks something like Flatpak,
with atomic upgrades, and parallel installation.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Bastien Nocera]

It's like you didn't listen to the arguments when this feature was implemented 
in Fedora years ago, and continue not to.
You're wrong, and the fact that you keep insisting you're not is frankly 
intellectual dishonesty.

If you really believe you're correct, try to kill your X server in the middle 
of an upgrade... Or simply re-read the tons of examples in the old threads.

- Original Message -
> Debarshi Ray wrote:
> > How about reliable online updates of running applications as a
> > benefit?
> 
> Upgrading RPM applications online just works. I do it all the time. The KDE
> tools do not even implement offline updates (and IMHO that's a good thing).
> The worst that can happen is that some recalcitrant applications (by far the
> minority) need to be restarted after updating (or if you upgraded the whole
> desktop, then your session may need to be restarted after updating). Until
> you do that, the current session may be "hosed" to some extent, but
> restarting will fix it. It is surely the lesser evil than forcing a complete
> system reboot before the update as GNOME does now. I never had a hosed
> system. In most cases, I just run the updates and continue working without
> even restarting anything, it just works.
> 
> This issue is being deeply blown out of proportion.
> 
> Kevin Kofler
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: No i686 kernel: Can we require SSE2 for i686?

[Bastien Nocera]

- Original Message -
> On Thu, Jul 13, 2017 at 07:47:58AM -0400, Bastien Nocera wrote:
> > > To give an example outside of the kernel, the installer 'Reclaim Space'
> > > function has been broken on i686 for about 10 months, and no-one seems
> > > to be lining up to fix that one either:
> > To be fair, no-one seems to be lining up to fix anaconda bugs in general...
> 
> I don't think that's fair at all. There is a whole anaconda team that

Case in point. The anaconda team fixes bugs in anaconda. There are few (no?)
outside contributors.

> very definitely works on bugs. If there's something in particular that
> needs priortization and you're having trouble getting attention on it,
> please raise it as a prioritized issue.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: No i686 kernel: Can we require SSE2 for i686?

[Bastien Nocera]

- Original Message -

> It's not a question of a single specific bug, though. It's a question
> of having someone or a group of someones interesting in the *ongoing
> requirement* for making sure i686 still works.
> 
> To give an example outside of the kernel, the installer 'Reclaim Space'
> function has been broken on i686 for about 10 months, and no-one seems
> to be lining up to fix that one either:

To be fair, no-one seems to be lining up to fix anaconda bugs in general...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Bastien Nocera]

- Original Message -

> > - make it possible to create Flatpaks quicker for some more complicated
> > apps
> 
> That just requires shipping the tools for third parties to use, not using
> them to deliver software packaged by Fedora.

The tooling is koji and bohdi. Shipping them isn't enough, hosting them is
necessary as well.

> > - developers not having to learn GPG to sign their releases
> 
> That is a very weak argument. It is very straightforward to set up an RPM
> signing key, not any harder than writing a specfile. And then you just run
> rpmsign --addsign to sign the RPMs.
> 
> And in the end, you are just saying that Flatpak does away with a critical
> security feature. Relying exclusively on the sandboxing for security is a
> very bad idea. Sandbox evasion exploits exist.

"developers not having to learn GPG to sign their *Flatpak* releases"

I really don't understand how you misinterpreted that sentence so badly,
individual Fedora developers never had to GPG sign their Fedora packages...

> > - more efficient update tracking than RPM (eg. no need to download 20 megs
> >   of metadata to know there's nothing to update)
> 
> But less efficient updating, because you will need to download much more
> than 20 megs of bundled libraries.

You download deltas, so the downloading is unlikely to be any worse than
downloading packaged updates. It also means I can update individual apps
without guesswork.

> The only reason the metadata is smaller
> is because there is almost no dependency information encoded (only a single
> dependency on a runtime). But those dependencies are what makes installing
> and updating packages so efficient! Flatpak throws away the main competitive
> advantage of GNU/Linux!

It's not efficient if I need to download 20 megs of data to see that I have
nothing to update. I really don't see why dependencies make installing and
updating packages "so efficient".

> And it is actually possible to solve the metadata size issue, see the work
> on metadata deltas. (There was at least one talk at DevConf on this.)

Right. It's just not done yet.

I started replying from the bottom of the mail, but I stopped midway. The
number of unsubstantiated claims got the better of me.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: No i686 kernel: Can we require SSE2 for i686?

[Bastien Nocera]

- Original Message -

> If you intend to kill Fedora, and furtherly emphasize the impression of
> Fedora not being community driven distro :(

For the distro to be community-driven, somebody needs to get behind the
wheel. Nobody's done that for i686 kernels.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: No i686 kernel: Can we require SSE2 for i686?

[Bastien Nocera]

- Original Message -
> On Tue, Jul 11, 2017 at 10:55:25PM +0200, Michal Schorm wrote:
> > He won't install it on his home desktop PC or work laptop. He rather find
> > an old dusty laptop from 2005 in his shed and starts to learn there.
> 
> If we're being honest, a typical 2005-era laptop is going to yield a
> rather lousy experience with any modern Linux Desktop.  (And an even
> lousier experience with modern Windows!)

This is my old go-to-blogpost for such comments:
http://www.hadess.net/2015/04/jdll-2015.html

For about 50 dollars/pounds/euros, you can transform a 10 year old machine
into something that'll be decently usable.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Fedora-packaging] Bundled Provides Libraries and Versioning

[Bastien Nocera]

- Original Message -
> On Saturday, 08 July 2017 at 17:24, Ville Skyttä wrote:
> [...]
> > If the bundled version corresponds to an upstream release to an extent that
> > it can be called that version, and checks like the discussed one could be
> > skipped just by looking at the version label, then it must be practically
> > the same. So why is it bundled in the first place?
> 
> There can be many reasons: copylibs, no upstream support for building as
> shared library, no stable API/ABI, etc. Many of them are listed on the
> wiki page: https://fedoraproject.org/wiki/Bundled_Libraries_Virtual_Provides

There's no mention of zlib or LZMA SDK libs in there. Should those be added?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Bastien Nocera]

- Original Message -
> Jaroslav Reznik wrote:
> > = System Wide Change: Graphical Applications as Flatpaks =
> > https://fedoraproject.org/wiki/Changes/Graphical_Applications_as_Flatpaks
> > 
> > Change owner(s):
> > * Owen Taylor 
> 
> This change is leaving several questions unanswered:
> 
> * As I understand it, those Flatpaks are going to be built from RPMs. Is the
> intent to ship both the original RPMs and the Flatpak or only the Flatpak
> (or is this going to depend on the individual package)? And if the former,
> are the shipped RPMs going to be the FHS-compliant version or the one
> relocated into Flatpak's proprietary prefix?
> 
> * What is the advantage of shipping Fedora distribution packages to Fedora
> users as Flatpaks? I see only drawbacks compared to RPM, because everything
> not included in the base runtime must be bundled, so we have all the usual
> issues of bundled libraries: larger downloads, more disk consumption, more
> RAM consumption (shared system libraries are also shared in RAM), slower and
> less efficient delivery of security fixes, FHS noncompliance, etc. And the
> portability argument is moot when we are talking about delivering Fedora
> software to Fedora users.

Why do we care about FHS compliance inside a Flatpak? And why would it be
slower to release security fixes?
 
> I strongly oppose this change.

You forgot the positive changes such as:
- sandboxing
- dogfooding and testing for the sandboxing technologies
- make it possible to create Flatpaks quicker for some more complicated apps
- developers not having to learn GPG to sign their releases
- more efficient update tracking than RPM (eg. no need to download 20 megs of
  metadata to know there's nothing to update)

There's plenty more depending on which part of the chain you'd be in.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intel i915 firmwares

[Bastien Nocera]

- Original Message -
> That might be the reason why I had to blacklist the snd-hdmi-lpe-audio module
> on my system. Pulseaudio crashed trying to access the HDMI audio device.

This wasn't related. Hans pointed me to a work-around for which I found the
upstream bug:
https://bugs.freedesktop.org/show_bug.cgi?id=100488

Cheers
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intel i915 firmwares

[Bastien Nocera]

- Original Message -
> On Wed, Jun 28, 2017 at 05:20:13AM -0400, David Airlie wrote:
> > 
> > > I ran into this today:
> > > https://gist.github.com/Brainiarc7/aa43570f512906e882ad6cdd835efe57
> > > 
> > > DRM firmware is loaded by default. HuC and GuC are not. Things work
> > > without them, and things work with them loaded. So what's the pro/con
> > > and if there's a pro, why isn't it the kernel default? Seems like if
> > > it should be default, either upstream should set them as the default,
> > > or the CPU/GPU should ask for it?
> > 
> > I expect when upstream decided they are stable and useful enough, upstream
> > will enable them. I'm not fully sure how useful they are, I think they
> > might possibly enable lower power states, but also nasty bugs.
> 
>   The same upstream which did not release stable version of Xorg Intel driver
> for past three years? ;-)
>   According to the link, the firmwares are needed for HDMI audio, which is
> quite critical functionality.  HDMI audio for older chipsets did not
> require binary blobs, so this is kind of regression.

That might be the reason why I had to blacklist the snd-hdmi-lpe-audio module
on my system. Pulseaudio crashed trying to access the HDMI audio device.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: mp3 encoding now ok

[Bastien Nocera]

- Original Message -
> Hi,
> So just wanted everyone to know that we now have the go ahead to ship mp3
> encoding in Fedora too. So anyone involved with packaging
> mp3 encoders can now start migrating them to the Fedora repositories. We are
> still in the process of evaluating other codecs.

I'll tell Thomas we can retire Codeina.

Thanks :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: systemd-coredump-python

[Bastien Nocera]

- Original Message -
> There's a new tiny package which provides a python traceback logging in
> the journal for python processes. It's very similar to the existing
> handler provided by abrt, it also installs itself as sys.excepthook
> using a .pth file, but instead of communicating with abrt, it talks to
> systemd-coredump directly.

If it's an upstream feature, could you please update:
https://bugs.freedesktop.org/show_bug.cgi?id=82507
?

Cheers
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS UP] fprintd-pam update vs "authconfig --update"

[Bastien Nocera]

- Original Message -
> Hi,
> 
> Please be careful with fprintd-pam update. It might happen that you
> might not be able to log in to your computer anymore as it happened to me.

Isn't that what https://bodhi.fedoraproject.org/updates/FEDORA-2017-4b67ae702a 
mentions?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: flatpak app launch script

[Bastien Nocera]

- Original Message -
> Hi,
> 
> I feel that launching a flatpak app from command line a bit regression
> from rpm packages. It's really different to type:
> 
> $firefox
> 
> or
> 
> $flatpak run org.mozilla.Firefox
> 
> Especially when "flatpak run org.mozilla" carries no information for
> user, they just want to launch the app and don't care if that's rpm,
> flatpak, snap or whatever. The ALT+F2 is affected too by this.
> 
> And why to care about about command line anyway? I think we should
> match it with existing rpm system as much as possible.
> 
> To match flatpak usability with rpm packages, can there be a launch
> script (say in /var/lib/flatpak/bin to keep it consistent) like we have
> in /usr/bin? I expect that launch script should be owned by flatpak app,
> optional.

"firefox" is not namespaced, Flatpak, for security reasons, only exports
namespaced data, so as to avoid clashes. This is one of the reasons why
you can easily install Nightly and stable versions of apps.

I think most of our users do not launch Firefox from the command-line,
and the few that do would likely know how to create a shell script.

The important thing is that clicking on links has the expected result,
launching the default browser. You can select it through "Settings ->
Details -> Default Applications".
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal: Rethink Fedora multilib support

[Bastien Nocera]

- Original Message -
> On 05/01/17 14:42 -0500, Randy Barlow wrote:
> >On Thu, 2017-01-05 at 17:02 +, Jonathan Wakely wrote:
> >> Which definitely changes how software is built.
> >
> >Containers also change the way software must be written in some cases,
> >since they expect there to be one main process and don't expect that
> >main process to interact with other "main" processes on the system.
> >There are some program architectures that aren't well suited to be run
> >in containers since containers expect programs to work in specific
> >ways. I don't think they are general enough to cover all use cases.
> >
> >I also expect that users will not appreciate being forced to use
> >containers if they want to keep being able to do things they can do
> >today. Offering it to them as an option rather than the only solution
> >is probably a friendlier approach.
> 
> 
> That would certainly be a problem if the proposal was to run each
> 32-bit application in its own container environment, but I think the
> suggestion is to have a single 32-bit container used by all 32-bit
> software. With that approach all the 32-bit software would be able to
> interact with the rest of the 32-bit system, there wouldn't be
> segregation between them.
> 
> But we would need to consider how a 32-bit application starts other
> programs via things like xdg-open. Would you have to have a 32-bit
> browser installed so that you could click on links in 32-bit
> applications? Would xdg-utils have to be installed on the system
> twice, once in the 64-bit host and once in the 32-bit container? And
> install things like Firefox and image viewers twice?

I wonder how that would work when 1) you need access outside the sandbox
(say to play audio through PulseAudio, which needs an ALSA 32-bit plugin),
or 2) the 32-bit binary is a plugin (remember 32-bit Flash inside Firefox
with the nppluginwrapper?).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: GSequencer upstream wants to package for fedora

[Bastien Nocera]

You're right, it's better :)

- Original Message -
> Bastien Nocera wrote:
> > I would advise you to look into packaging your application using Flatpak:
> > http://flatpak.org/
> > so that you can package your application for both Fedora, and every other
> > distribution out there that has Flatpak available to it.
> 
> That is no replacement for a native RPM package.
> 
> Kevin Kofler
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: GSequencer upstream wants to package for fedora

[Bastien Nocera]

Hey Joel,

- Original Message -
> Hi all
> 
> My name is Joël Krähemann. I maintain Advanced Gtk+ Sequencer and I'd
> like to provide it in fedora. Linux is my OS of choice since 2001.
> Along the time I have used many distributions like debian, linux from
> scratch, SUSE, fedora and a few others.
> 
> Prior I did an RPM spec provided on:
> 
> https://sourceforge.net/projects/ags/files/fedora/
> 
> Note the project is mainly hosted by GNU Savannah.
> 
> http://nongnu.org/gsequencer
> 
> The domain http://gsequencer.org is forwarded to it. Current stable
> version of GSequencer is 0.7.113 and I'm working on version 1.0. The
> branch 0.7.x only gets bug-fixes or features back-ported I'd really
> like to see there.
> 
> Next goals are doing remote bindings and lv2 UI support as well
> extending MIDI support. Further I'd like to accelerate loading Lv2
> plugins the current code doing XPath lookup with RDF turtle converted
> XML is slow for certain plugins. But you are able to blacklist if you
> wish.

I would advise you to look into packaging your application using Flatpak:
http://flatpak.org/
so that you can package your application for both Fedora, and every other
distribution out there that has Flatpak available to it.

Cheers
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Bastien Nocera]

- Original Message -

> For that sort of comparison then comparing Macs to any other consumer
> desktop is not possible and is its own category of hardware. I can buy
> 2-3 equivalent memory/cpu/video ASUS systems for a Macbook.

Coo, we might need new computers for the GNOME events box. Can you
point me to the 250$ equivalent for those:
http://www.apple.com/mac-mini/specs/
?

[1]

> They may
> not be as well engineered or as pretty but they are functional and do
> allow me to change out memory and disks much more easily than a Mac.
> Does that mean we shouldn't compare them for working? If we can't then
> we really need to make this a focus early on in a release with people
> wanting it helping out.. 

They work well enough. We have people doing work upstream and downstream
trying to make them work better. Except that we don't spend our time
continuous testing the installer on hardware that we might only have one
model of.

[1]: I hate those "the Macs are too expensive/proprietary/whatever" comments.
Cool, don't buy them, don't use them, but there are plenty of other crapola
hardware to go around in the non-Mac computers we support, and you just don't
see the amount of work done upstream for the undocumented ACPI devices
to make a single button work on your laptop.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Bastien Nocera]

- Original Message -

> The reality is that QA is thinly spread in general. Making this
> blocker "about Macs" is a misleading conclusion, there's a grain of
> truth in it, but it's mistaking the forest for the trees. Next time
> there's a release blocking bug, it'll just be something else.

It's not "about Macs", it's about the installer and its dependencies.
There are other release blocking bugs, and certainly Live images
that don't work are embarrassing, but not being able to install the
system is as bad as it gets.

FWIW, an application included in the Live image that crashes on startup
but has a 0-day update scheduled is a much smaller problem than not
being able to boot the installer, or the installer working as expected.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Bastien Nocera]

- Original Message -
> On 17 November 2016 at 10:22, Bastien Nocera <bnoc...@redhat.com> wrote:
> >
> >
> > - Original Message -
> > 
> >> No I am not asking for continuous testing. I am asking that if people
> >> really care about the hardware support they get in the muck and do
> >> just a little of the work in an organized fashion. Put together a Mac
> >> SIG that focuses on getting the best experience on the hardware. Send
> >> some QA people newer Macs. Otherwise how do people know that it is
> >> really important to you versus "I have 4 minutes on the internet so I
> >> can send a complaint email" important. Because at this point that is
> >> all this looks like.
> >
> > So, I can't say that the problem is more systemic than what you describe
> > without making it seem like I'm "sending a complaint email". Let me know
> > if you want a list of hardware enablement I've done on Macs over the years.
> >
> 
> That was rude of me and I apologize. Dialing back my melodramatics.. I
> will try to walk through my reasoning.
> 
> 1. There was no proposal to drop Macs. Josh wasn't at the meeting but
> said he would have argued for it at the meeting because he felt it was
> too little too late. The other FESCO members seem to have disagreed
> with him so it wouldn't have passed. If a proposal was made for it, it
> would happen for Fedora 26 and not Fedora 25.

But if the installer is (completely) broken, it might as well be dropped.
Alas, it's not completely broken.

> 2. The Fedora QA group has 1 mac mini which is very old and is only
> used for total install and not dual boot. It would not have found this
> issue.

The testing should be switched to be a dual-boot test, as it's what
Mac users are more likely to be using (and also a necessity for firmware
upgrades).

> The Fedora QA group also has no one using Mac hardware day to
> day.

This isn't a problem. There are people using Macs day-to-day, and they report
bugs. The problem here, and I can't emphasise this enough, this problem is
a systemic problem with the installer QA, specifically.

Once the machine is installed, it's usually fairly straight forward to
update packages, downgrade them, and fix hardware specific problems as long
as the device can be booted, and a sufficient amount of hardware is working.

The installer not working, especially when it's a last minute problem,
it becomes a blocker. Do we need a different schedule for installer
development?

> 3. Out of the people who on this thread said they have Apple hardware,
> at least 2 have tested Fedora 25 but they both did in a way that would
> not have hit the bug but could have been work arounds IF (and ONLY IF)
> it had gone out.

I'm pretty sure there's plenty more folks using Fedora on Macs and testing
it than just 2. Again, it shows that the problem is making sure the
installer works. Dogfooding for the rest of the system is done. There are
hardware-specific bug reports being done.

> 4. Of the people who did have Macs but didn't test, most of them
> seemed to have assumed that someone else was testing it for them OR
> they didn't know how to test OR they didn't use dual boot so would not
> have tested it.

Given that I use my hardware for development (in this case, hardware
enablement), I don't really have the time to constantly wipe and reinstall
the system to test rawhide installers. I guess that most folks that already
have Fedora installed on their machines will simply upgrade the system.

> 5. Various people think that users of Mac hardware is the group Fedora
> should focus on but they don't seem to be talking with each other
> enough to say how.

IMO, making sure the installer works and the bootloader is correctly installed
would be enough. After that, we can rely on testers from a number of
groups, whether Fedora Mac users, upstream users, etc.

> So to me this says that a Macintosh Special User Group would be a
> useful tool to answer 2 through 4. They could better find someone who
> can rotate through the Fedora QA group to answer 2. They can also work
> out what pathways may need to be tested. The people in 3 who are
> testing can help the people in 4 also spread out the work. They can
> also say which Mac hardware is a good fit for Fedora and which one
> isn't.  This can better aim people who are coming in but end up with
> say some particular hardware from going in and trashing their computer
> when it would not have worked without expert help.
> 
> Does that sound better than my over the top original rant?

It's better, but I don't think that the problem lies in the QA team,
although some things could be done better there.

The main problem to me seems to be that the installer sees too little
testin

Re: Fedora on Macs, removing the release criterion

[Bastien Nocera]

- Original Message -
> On 2016-11-17 07:43 AM, Stephen John Smoogen wrote:
> > 2. The Fedora QA group has 1 mac mini which is very old and is only
> > used for total install and not dual boot. It would not have found this
> > issue. The Fedora QA group also has no one using Mac hardware day to
> > day.
> 
> This bit isn't quite true. We found the bug *on* that Mac Mini. I'm
> worried it's not likely to find *other* bugs that people are likely to
> encounter on the systems they actually want to run Fedora on (newer
> laptops), but it did find this one.

Newer Mac laptops don't have working keyboards or touchpads as they're
not connected through USB internally. That's not Fedora's problem though.
The problem is if the installer doesn't work when the pre-requisite
hardware does.

> The problem is that we didn't get around to running the test until the
> day before the go/no-go. There's a lot of stuff to test, and anything
> which only one person is likely to test is a risk. Frankly speaking,
> given how humans work, things that involve digging some piece of
> hardware you never touch out of a pile and hooking it up to a keyboard
> and mouse and a monitor and power and network is quite likely to get
> passed over in favour of something you can run in a VM. Especially if
> it's 4:30. This is why I have an Unused Arm Devices Pile Of Shame on my
> desk...
> 
> So, partly this is our fault because we could've tested this earlier and
> didn't. But it's also the case that we really need more redundancy in as
> much of the required testing as possible.

Is there any continuous testing done on the images on the installer? Is it
on real hardware? Is it possible to mock hardware setups? Comparing
boot setups on working and non-working installations.

I think it would be possible to do testing that didn't rely quite as much
on manual testing, through regression testing on "mock" hardware (a hacked
up VM with a test disk image), comparing the partition types after installation
against a working setup, comparing the file lists in the boot partition,
etc.

I'm surprised that the Anaconda, and blivet developers aren't taking part
of this conversation. I'd certainly like them to point out all the ways in
which they're already doing what I mentioned, and showing how we could
add more test cases.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F24 GStreamer zero day

[Bastien Nocera]

- Original Message -
> On 23 November 2016 at 14:03, Chris Murphy  wrote:
> > On Wed, Nov 23, 2016 at 10:36 AM, Adam Williamson
> >  wrote:
> >> On Wed, 2016-11-23 at 10:33 -0800, Andrew Lutomirski wrote:
> >>> On Nov 23, 2016 10:12 AM, "Michael Catanzaro" 
> >>> wrote:
> >>> >
> >>> > On Wed, 2016-11-23 at 16:36 +0100, Hans de Goede wrote:
> >>> > > I don't think that is entirely true. I've recently been trying
> >>> > > to get gnome3 to run on under-powered machines like cheap ARM
> >>> > > tablets, and I can do "dnf remove tracker" more or less just
> >>> > > fine, I loose totem due to some weird dependency chain, and I
> >>> > > think also gnome-documents which I guess is an issue for some
> >>> > > use-cases, but most of gnome will stay and work just fine.
> >>> >
> >>> > Besides those, also gnome-photos and gnome-music (which aren't
> >>> > installed by default currently, but will eventually be). And indexed
> >>> > search is really very important for nautilus.
> >>>
> >>> That's indexed search by *name*, right?  I can't imagine *any* reason
> >>> that
> >>> running a codec in the indexer is needed for nautilus.
> >>
> >> "I want to find all the files I have that are songs by Justin Bieber,
> >> so I can shoot them into outer space".
> >
> > Pretty sure such metadata is a function of the container format, e.g.
> > mp4, m4a, rather than the codec used for encoding the music or video
> > itself.
> 
> It might be but because most people tie those two things together when
> they are writing code.. they get bundled together. This is why codecs
> have been such a rich target in Windows (and in some ways Mac) malware
> over the years. You get two channels to build an exploit for free :).

They're not bundled together. Especially seeing as the popular filetypes
have codecs depending on patents whereas the container formats don't.

We've been able to tell you how long your DivX or MPEG-4 files were,
out-of-the-box, on Fedora, for years. We just can't play them out-of-the-box.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Bastien Nocera]

- Original Message -

> No I am not asking for continuous testing. I am asking that if people
> really care about the hardware support they get in the muck and do
> just a little of the work in an organized fashion. Put together a Mac
> SIG that focuses on getting the best experience on the hardware. Send
> some QA people newer Macs. Otherwise how do people know that it is
> really important to you versus "I have 4 minutes on the internet so I
> can send a complaint email" important. Because at this point that is
> all this looks like.

So, I can't say that the problem is more systemic than what you describe
without making it seem like I'm "sending a complaint email". Let me know
if you want a list of hardware enablement I've done on Macs over the years.

> For example, in the past 4 years the ARM builders have been nothing
> but a pain in the ass, but they are kept going because there are
> people who banded together and do a lot of the work. Yes there are the
> various people who show up and expect XYZ board to be magically
> supported but there are still a lot of people who show up, test the
> bugs on what they find important to them and those boards get covered.
> If the Mac is important enough, pick a couple of models which are what
> you are going to focus on and season the pot.

Apples and oranges. There's no installer on ARM. There's no need to wipe
all your data on a desktop system that you have one unit of.

The *installer* breaking is a very different proposition to whatever piece
of software breaking. We don't release updated installers. Making it 
uninstallable
means people will just not use any of our software. And it's even worse
when 1) it was supported and working 2) it probably worked better than
most other distributions.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Bastien Nocera]

- Original Message -
> On 11 November 2016 at 03:20, Andreas Tunek  wrote:
> >
> >
> > As a mac owner (although one that is not very well supported by
> > Linux*) I really appreciate the fact that Fedora works. And saying you
> > do not want to support that hardware anymore just because you found a
> > regression/bug is kind of lame.
> 
> You are reading that wrong. The problem isn't that we don't want to
> support Mac hardware, we are finding we can't support Mac hardware to
> the level that it blocks a release because there are not enough people
> testing the hardware in a fashion that finds blocker level bugs.
> 
> This is where you and other Mac users can and MUST help out. Fedora is
> a stone soup. Unless people bring some amount of work to the pot, what
> they get out is water flavoured gravel.  You can bring the spice and
> aroma of a Mac hardware.. but if you don't then it doesn't mean that
> we can wait until someone else does.

That's an unfair characterisation of the problem. There are certainly plenty
of people testing out Fedora on Macs. I'm guessing most of those folks have
a single machine that they use Fedora on. You're asking them to do continuous
testing of the installer, which the installer team is much more likely to be
able to do.

There's regular hardware giveaways within Red Hat, when departments that do
use Macs give them away when they do their hardware refresh. So it would be
possible to test this out at the root.

I installed Fedora 25 on the MacBook Pro that was given to me, but I upgraded
it via gnome-software.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC (round 2): Change the default hostname for Fedora 26+

[Bastien Nocera]

- Original Message -

> Further, from a purely technical perspective, I think I've been swayed by
> arguments around the generation of the hostname:
> 
> * I'm fine with the lowercase "fedora-" prefix. It makes sense since
> hostnames
> are generally normalized to lower-case in common usage.
> 
> * I like Zbigniew and Lennart's thoughts on how to generate the "random"
> suffix.
> the implementation I'd likely use is to take the first eight characters of an
> md5 (or SHA) hash of /etc/machine-id and use those. That should make it both
> repeatable and unique.
> 
> 
> 
> For Anaconda folks: would it be possible to have the currently-selected
> hostname
> be visible next to the "Networking" spoke on the main hub page? You show the
> selected environment group beside the "Software Selection" spoke and the
> connected network device, so it might be useful to let people know what the
> hostname is as well. (This would also be handy if it turns out that DHCP is
> trying to assign a hostname; the user may not want or expect that)

As mentioned in the fedora-desktop thread about branding, I don't like seeing
this sort of randomly generated and nonsensical (and I mean that in that a 
string
of hex characters obviously don't *mean* something) shouldn't be user-visible.

Right now, you'd see the hostname on the machine itself in the Sharing and
Details panels in GNOME, in bash's prompt, and in quite a few remotely 
accessible
services (the Bluetooth name, shared media, ssh, etc.).

There's nothing stopping us from having a hidden/secondary hostname though,
and a randomly generated one would fit perfectly for this sort of use case.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: 2 packages seeking new point of contact

[Bastien Nocera]

- Original Message -
> Greetings.
> 
> Due to https://pagure.io/fesco/issue/1639 we have orphaned 2 packages
> that need a new point of contact:
> 
> rpms/authd -- A RFC 1413 ident protocol daemon ( master f25 f24 f23 )
> rpms/python-gudev -- Python (PyGObject) bindings to the GUDev library (
> master f25 f24 f23 )

Might be worth porting whatever uses python-gudev to using libgudev through
gobject-introspection.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: DNF and PackageKit background data usage

[Bastien Nocera]

No, there's no UI:
https://bugzilla.gnome.org/show_bug.cgi?id=745747

- Original Message -
> On Mon, 2016-10-31 at 15:09 +, Richard Hughes wrote:
> > 
> > I think this kind of issue is really fixed the hard way, i.e. fixing
> > bugs and adding unimplemented features rather than just adding complex
> > UI workarounds.
> 
> I think making it work as best as possible without interaction is
> great, but I'd argue that fundamentally this needs interaction. At a
> bare minimum the UI for users to mark connections as metered or
> unmetered needs to be there. Is there actually UI for this already? I
> could not find it.
> 
> The question of what the default state should be is an interesting one,
> and I bet your take on it differs substantially depending on your level
> of 'internet connection privilege'. ;)
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: DNF and PackageKit background data usage

[Bastien Nocera]

- Original Message -
> On Mon, 2016-10-31 at 08:18 -0400, Bastien Nocera wrote:
> 
> > > How does a connection become "unmetered"? It can't just be on interface
> > > type,
> > > as I have metered connections on all interface types, so presumably you
> > > use
> > > some form of web service to distinguish "metered" from "unmetered" based
> > > on
> > > a list of known IP blocks?
> > > 
> > > Or do you simply assume that all connections are metered until the user
> > > says
> > > otherwise?
> > 
> > They're metered unless you either tag them as unmetered, or hints are
> > provided
> > to NetworkManager by what you're connected to. For example, Android
> > tethering
> > is automatically tagged as metered as Android provides a hint in its DHCP
> > configuration.
> 
> Does NetworkManager 'hint' that wired connections are unmetered?

It doesn't say "definitely metered" or "definitely unmetered". We usually take
that to mean it's unmetered.

> Otherwise your description doesn't seem to square with the fact that
> most everyone sees background update downloads OOTB.
> 
> Even still, in fact, kparal mentioned them happening on hotel wifi, so
> why would that be the case if the default is 'metered'?

Looks like I switched metered and unmetered around in my description ;)

They're unmetered unless you either tag them as metered, or something
(like a DHCP server) tells NM they're metered.

Sorry about that.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: DNF and PackageKit background data usage

[Bastien Nocera]

- Original Message -
> > On 30 October 2016 at 01:26, Adam Williamson 
> > wrote:
> > > 1) Both dnf and GNOME Software / PackageKit default to performing
> > > fairly data-hungry transactions in the background, out of the box,
> > > without telling you about it. GNOME's is particularly bad, as it will
> > > happily download available updates in the background, which can be
> > > gigabytes worth of data.
> > 
> > If you're on an "unmetered" connection type...
> 
> This can be problematic even on an unmetered connection. An anecdotal
> experience: A few months back I was on a hotel wifi, I vitally needed some
> information quick, and the wifi simply didn't work - all web pages timed
> out. I was very disgruntled about a crappy hotel wifi (that used to work the
> day before), when in 5-10 minutes, I saw "Your updates were downloaded and
> are ready to install" popup. Then I realized... tried the web browser and
> web pages loaded normally. The wifi connection was so slow that while
> PackageKit was downloading updates in the background, I couldn't access the
> web at all.
> 
> My poor experience stemmed from:
> a) not being informed that updates were being downloaded in the background -
> so I assumed the problem was elsewhere
> b) not being able to pause/abort background downloads - even if I had
> realized/figured out PackageKit was hogging the network, there'd have been
> no way to stop the downloads (certainly no user accessible one, and even
> when I tried to kill the process some time in the past, it just kept
> respawning)
> 
> You can disregard this as a "slow hotel wifi problem only", but I live in a
> block of flats, the air is jammed with 20-30 wifi networks all around me,
> and I experience a similar situation (though not that severe) from time to
> time even at my home, a few meters from the AP - one full speed download can
> completely kill any other (my own) network traffic. Again, this would not be
> a problem if I a) knew about it b) could stop it.

I'd really like the kernel to do QoS on the user's own connections. We can know
whether downloads are interactive or not, so there is metadata available
to make this better, and not cripple interactive downloads while background
downloads are ongoing.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: DNF and PackageKit background data usage

[Bastien Nocera]

- Original Message -
> On 31/10/16 12:18, Bastien Nocera wrote:
> 
> > They're metered unless you either tag them as unmetered, or hints are
> > provided
> > to NetworkManager by what you're connected to. For example, Android
> > tethering
> > is automatically tagged as metered as Android provides a hint in its DHCP
> > configuration.
> 
> What if you're not even using NetworkManager?
> 
> Only my laptop, which needs the easy UI of Network Manager to connect to
> different networks, uses NM while all my non-mobile machines just use
> systemd-networkd to manage the network.
> 
> So how do I tag a connection as unmetered with systemd-networkd?

You can't. You get a box of bits if you start replacing parts of the
Workstation experience, eg. the network status icon also won't work
as expected. That's par for the course.

> More to the point how do I tag it as unmetered at certain times of day...

Right now, you'd script it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: DNF and PackageKit background data usage

[Bastien Nocera]

- Original Message -
> On 31 Oct 2016, at 11:41, Richard Hughes  wrote:
> > 
> > On 30 October 2016 at 01:26, Adam Williamson 
> > wrote:
> >> 1) Both dnf and GNOME Software / PackageKit default to performing
> >> fairly data-hungry transactions in the background, out of the box,
> >> without telling you about it. GNOME's is particularly bad, as it will
> >> happily download available updates in the background, which can be
> >> gigabytes worth of data.
> > 
> > If you're on an "unmetered" connection type...
> > 
> 
> How does a connection become "unmetered"? It can't just be on interface type,
> as I have metered connections on all interface types, so presumably you use
> some form of web service to distinguish "metered" from "unmetered" based on
> a list of known IP blocks?
> 
> Or do you simply assume that all connections are metered until the user says
> otherwise?

They're metered unless you either tag them as unmetered, or hints are provided
to NetworkManager by what you're connected to. For example, Android tethering
is automatically tagged as metered as Android provides a hint in its DHCP
configuration.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F25 workstation, and (almost) hidpi displays

[Bastien Nocera]

- Original Message -
> Adam Williamson wrote:
> > If you use Fedora (Workstation, at least, and I think maybe KDE too) on
> > a 3200x1800 13" screen then hidpi mode will kick in, and everything
> > will be sized as if you were using a 1600x900 13" screen, which is a
> > pretty common setup.
> 
> Yes, Plasma 5 definitely handles that as a hidpi display.
> 
> But KDE is actually much smarter and can handle any DPI, though you will
> likely have to configure it manually, because as you explained, the
> developers of the commonly used X drivers decided to be jerks and
> deliberately report a bogus geometry.

[Citation really needed]

> (KDE would just work if the drivers
> wouldn't go out of their way to break it.)
> 
> Since Qt 5.6, non-integer scale factors are also supported in principle:
> http://blog.qt.io/blog/2016/01/26/high-dpi-support-in-qt-5-6/
> though there may be rendering glitches and other issues with them.

So Qt 5.6 supports non-integer scale factors with the exact same problems
that made GTK+ developers not support it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: iphone mount in nautilus on Fedora 24

[Bastien Nocera]

- Original Message -
> On Tue, 2016-10-11 at 09:52 -0400, Bastien Nocera wrote:
> > 
> > 
> > - Original Message -
> > > 
> > > 
> > > > 
> > > > 
> > > > - Original Message -
> > > > 
> > > > Yup. The "normal" mount contains nothing that normal users
> > > > should access.
> > > > Accessing the photos will leave ghosts on the device, and there
> > > > have been
> > > > no
> > > > ways to update the music database in Linux for a few iOS
> > > > releases.
> > > 
> > > I very much doubt that anyone would release any code to touch an
> > > idevice
> > > music database due to fear of
> > > legal action from the manufacturer. It may exist already.
> > > 
> > > The ability to sync contacts, calendars and events, meeting info,
> > > notes,
> > > pictures etc ( anything that would be considered the personal data
> > > entered
> > > by the idevice owner is another matter entirely. Anything that the
> > > law
> > > provides in most countries such as the IP to that person or the
> > > copyright of
> > > documents or photos etc, and yes it can be a very grey area
> > > between the laws
> > > in different countries. This is just the other side of the coin
> > > but this
> > > time from the owners perspective and legal rights.
> > 
> > What Linux applications support syncing those contacts? Are you sure
> > they actually
> > require the mounted filesystem?
> 
> These do not need the exposure of the mounted filesystem in nautilus.

Not sure that's worth mentioning in this thread then.

> 
> This is more to do about developing applications for linux
> to access the idevice that about iOS development on Fedora
> Workstation but it may just help this also.

Again, you don't need access to that particular filesystem to use sbmanager,
or sync contacts. Maybe we'll get to that use case at some point.

> > 
> > 
> > > 
> > > 
> > > While nautilus still exposes the pictures on an idevice
> > > through  gphoto2
> > > system does not seem to have changed.
> > 
> > I can't parse that.
> > 
> > > 
> > > 
> > > As far as I am aware it is possible to copy pictures from the
> > > idevice but
> > > transfers of pictures to the idevice will succeed, but will not be
> > > shown on
> > > the idevice by native apps without further hacking.
> 
> This is only because a camera roll management needs implementation to
> parse the file format.
> > 
> > 
> > So it doesn't work. Sure you could use, and you can still use, the
> > partition
> > as storage. But I don't see the point in doing that.
> 
> And it will stay that way if we do not allow developers easy access to
> these area on the idevice. So everyone looses.

It's still there, it's just not mounted by default.


> Actually it is not unrelated at all as supports the subject of the
> email.
> 
> 
> The fact that a properties dialogue is not available in nautilus
> in the side bar is a problem as it stops any user from displaying the
> extra properties of a idevice using the mentioned extension.

But that's not related to the disabling of the "main" partition mount.

> > > https://bugzilla.gnome.org/show_bug.cgi?id=741302
> > > 
> > > https://git.gnome.org/browse/nautilus-ideviceinfo/log/?ofs=100
> > > 
> > > http://blog.sukimashita.com/2015/01/09/gtk-3-support-for-nautilus-
> > > ideviceinfo/
> > > 
> > > I hope this can  be resolved in the short term as it provides all
> > > users of
> > > idevices with info that is expected today and further benefits
> > > the foss community and the goals of Fedora, Gnome and downstream
> > > distributions etc.
> > 
> > Showing all the possible partitions doesn't help anyone, that I can
> > see. Explain
> > how the data on that partition is useful to the large majority of
> > iOS/Linux users,
> > and we can investigate.
> The data from the idevice partition is useful for a developer not for
> a regular user.
> 
> 
> As I have explained above about the properties dialogue is not
> available for a mounted idevice means that all user cannot
> get this info easily without writing an application to get
> it.
> This info is convenient to know for all users.
> 
> It is available for other usb connected devices why not an idevice.

That's a different bug.

We're pretty much in agreement that the main partition we used to show for iOS
devices doesn't have any uses beyond fiddling with the internals of the device,
and that it would be nice if the nautilus properties tab could be made to work
again.

Let's continue the discussion about that last one in the bug.

Cheers
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F25 Self Contained Change: IBus Emoji Typing

[Bastien Nocera]

- Original Message -
> On 07/11/16 20:25, Bastien Nocera-san wrote:
> >
> >
> > - Original Message -
> >> On 07/08/16 20:41, Bastien Nocera-san wrote:
> >>> I think that the emoji input method should be a separate input method, so
> >>> that most users would have the choice between inputting using the
> >>> keyboard
> >>> layout that matches their keyboard, and a separate input method for
> >>> emojis.
> >>
> >> I think the emoji typing does not depend on XKB but is used frequently and
> >> I
> >> don't think it should be separated.
> >
> > It is on every other platform I can think of.
> 
> I don't think so.
> I can see Emoji input on MS-IME in MS-Windows without switching engines in
> Japanese.
> I can see Emoji input on Mac without switching engines with
> Command-Control-Space key.
> I can see Emoji input on Xperia keyboard in Android without switching
> engines.

Fair enough. Where's the design work for this functionality?

> >>> The IBus XKB engine is not discoverable (it's not listed in GNOME's
> >>> Region
> >>> & Language settings) and the keyboard shortcut to input emojis is also
> >>> not
> >>> discoverable. Having a separate input method is likely the better way to
> >>> implement this.
> >>
> >> I replied this.
> >
> > You haven't. You're implementing this without any regards for prior art and
> > design work that's been done. You certainly can implement this internally
> > however you want, but the end result has to match certain expectations, and
> > designs. Your implementation won't, and as a result won't be discoverable.
> >
> 
> What do you mean in the certain expectations and designs.
> As I explained, a radio button would be a idea to resolve your disacoverable
> way because I think you mean the GUI access.

A radio button somewhere in ibus doesn't make it discoverable.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: iphone mount in nautilus on Fedora 24

[Bastien Nocera]

- Original Message -
> > - Original Message -
> > 
> > Yup. The "normal" mount contains nothing that normal users should access.
> > Accessing the photos will leave ghosts on the device, and there have been
> > no
> > ways to update the music database in Linux for a few iOS releases.
> 
> I very much doubt that anyone would release any code to touch an idevice
> music database due to fear of
> legal action from the manufacturer. It may exist already.
> 
> The ability to sync contacts, calendars and events, meeting info, notes,
> pictures etc ( anything that would be considered the personal data entered
> by the idevice owner is another matter entirely. Anything that the law
> provides in most countries such as the IP to that person or the copyright of
> documents or photos etc, and yes it can be a very grey area between the laws
> in different countries. This is just the other side of the coin but this
> time from the owners perspective and legal rights.

What Linux applications support syncing those contacts? Are you sure they 
actually
require the mounted filesystem?

> is
> > 
> > You can still access the device by editing the URL in the "Documents on..."
> > location. Just remove the ":3" at the end.
> 
> Thanks for this info,
> > 
> > If you have use cases that aren't the 2 mentioned above, or using your
> > iDevice
> > as a thumb drive, please file bugs against gvfs in the upstream GNOME
> > Bugzilla.
> > 
> > Cheers
> 
> 
> While I agree for the normal non developer user, the removal, to be able to
> access what you could originally access, on the idevice before the code
> change, may be of little value.
> 
> It is frustrating if you are developing applications and need access to these
> areas for debugging, checking directory, files and structure etc of the
> idevice.
> 
> It is even more frustrating when the Fedora workstation is being targetted as
> a developer's platform, and it also affects any downstream distribution
> developers in the same way.

How do you develop iOS applications on Linux? In any case, it's not a target
of Fedora Workstation. It could be, but it's not.

> While nautilus still exposes the pictures on an idevice through  gphoto2
> system does not seem to have changed.

I can't parse that.

> As far as I am aware it is possible to copy pictures from the idevice but
> transfers of pictures to the idevice will succeed, but will not be shown on
> the idevice by native apps without further hacking.

So it doesn't work. Sure you could use, and you can still use, the partition
as storage. But I don't see the point in doing that.

> The other mount exposes the so called document folder of some user installed
> apps on the idevice and may be useful for someone developing

It's useful for adding files to applications, for example, music, photos, or
documents in most 3rd-party applications.

> but is off
> limited use to a normal non developer user, unless the normal non developer
> wants to use the phone as a usb drive to transport files without carrying an
> extra usb drive.
> 
> The removal of the nautilus properties page on an connected idevice does have
> an effect that a nautilus-ideviceinfo extension that has been in gnome git
> for many years cannot be easily exposed and used and a gnome bugzilla entry
> has been active from last year without even a comment to date.

That's unrelated.

> https://bugzilla.gnome.org/show_bug.cgi?id=741302
> 
> https://git.gnome.org/browse/nautilus-ideviceinfo/log/?ofs=100
> 
> http://blog.sukimashita.com/2015/01/09/gtk-3-support-for-nautilus-ideviceinfo/
> 
> I hope this can  be resolved in the short term as it provides all users of
> idevices with info that is expected today and further benefits
> the foss community and the goals of Fedora, Gnome and downstream
> distributions etc.

Showing all the possible partitions doesn't help anyone, that I can see. Explain
how the data on that partition is useful to the large majority of iOS/Linux 
users,
and we can investigate.

Cheers
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: "Could not retire package"

[Bastien Nocera]

- Original Message -
> On Thursday, September 15, 2016 12:20:57 PM CDT Bastien Nocera wrote:
> > - Original Message -
> > 
> > > On Thursday, September 15, 2016 11:51:47 AM CDT Bastien Nocera wrote:
> > > > Could not retire package: You are not allowed to retire the package:
> > > > rpms/obexd on branch f24.
> > > > 
> > > > obexd has been integrated in bluez since version 5.something, which
> > > > happened at least 5 Fedora releases ago.
> > > > 
> > > > My guess is that the "critpath" status of the package is stopping that.
> > > > 
> > > > Cheers
> > > 
> > > you can not retire packages from stable Fedora releases,  because we have
> > > no way to remove it from already shipped pieces
> > 
> > Do you know where does the message come from, so that I can file a bug for
> > the message to actually say that?
> 
> I belive it is pkgdb that returns the message. however fedpkg may need some
> loginc to interprit the message

Filed as https://github.com/fedora-infra/pkgdb2/issues/400
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Tracking num-lock state on wayland

[Bastien Nocera]

- Original Message -
> Hi,
> 
> I maintain lockkeys extension for gnome shell. It displays num-lock and
> caps-lock states in the panel. It also shows notification if either of
> these states change.
> 
> I use Keymap's "state-changed" signal:
> Gdk.Keymap.get_default().connect('state-changed', ...);
> to receive numlock and capslock changes.
> 
> It works well in X11. In Wayland however, it works only partially. I
> receive state change signals only when XWayland application is focused.
> When native wayland application is focused - I get no state change
> signals.
> It can be reproduced on Fedora 24. I didn't test on Fedora 25.
> 
> Is there other similar api that would work on wayland ?
> Is there a way to change state "from code" ? I want change f.e. num-
> lock state when user clicks with a mouse on a button.

You can't do that in Wayland, that should only be accessible to the compositor.
See:
https://bugzilla.gnome.org/show_bug.cgi?id=771873
https://bugzilla.gnome.org/show_bug.cgi?id=771874
https://bugzilla.gnome.org/show_bug.cgi?id=659243

Cheers
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Orphaning packages

[Bastien Nocera]

- Original Message -
> On Thu, Sep 15, 2016 at 11:39:20AM -0400, Bastien Nocera wrote:
> > - gnome-web-photo
> >   Requires porting to a newer version of WebKit:
> >   https://bugzilla.redhat.com/show_bug.cgi?id=1375837
> >   I don't think the maintainer (chpe) is still maintaining it upstream
> 
> It is just Vincent now because chpe removed himself in commit
> d738f13028a3512f6f7650dbc91c524b23dc25c8. :) Since Vincent
> moved on to other projects in 2012, and the last real code commit
> was in early 2011, I think it is safe to call it dead.
> 
> > - xchat-gnome
> >   I started using Polari for IRC
> 
> I think we should drop xchat-gnome since hexchat is a worthy
> replacement.

UI-wise, hexchat is horrible. But as I said, I've moved to Polari so
I know the UI to be reasonable :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: "Could not retire package"

[Bastien Nocera]

- Original Message -
> On Thursday, September 15, 2016 11:51:47 AM CDT Bastien Nocera wrote:
> > Could not retire package: You are not allowed to retire the package:
> > rpms/obexd on branch f24.
> > 
> > obexd has been integrated in bluez since version 5.something, which
> > happened at least 5 Fedora releases ago.
> > 
> > My guess is that the "critpath" status of the package is stopping that.
> > 
> > Cheers
> 
> you can not retire packages from stable Fedora releases,  because we have no
> way to remove it from already shipped pieces

Do you know where does the message come from, so that I can file a bug for
the message to actually say that?
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

"Could not retire package"

[Bastien Nocera]

Could not retire package: You are not allowed to retire the package: rpms/obexd 
on branch f24.

obexd has been integrated in bluez since version 5.something, which
happened at least 5 Fedora releases ago.

My guess is that the "critpath" status of the package is stopping that.

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

Orphaning packages

[Bastien Nocera]

Hey,

I've orphaned a number of packages in Fedora:
- vinagre
  Taken over by Felipe Borges, as he's working on migrating
  the remote connection functionality to Boxes

- gnome-web-photo
  Requires porting to a newer version of WebKit:
  https://bugzilla.redhat.com/show_bug.cgi?id=1375837
  I don't think the maintainer (chpe) is still maintaining it upstream

- rhythmbox and libgpod
  It's still maintained upstream, and the maintainer
  is responsive. The iPod/Music syncing functionality doesn't work with
  newer/supported versions of iOS. I'll carry on maintaining those packages
  in RHEL for the foreseeable future. Hopefully soon replaced by GNOME Music
  in the default Workstation installation.
  There's also stable and nightly Flatpaks from GNOME

- xcf-pixbuf-loader
  The upstream is gone (was on gitorious), though there is a mirror at:
  
http://www.geeqie.org/cgi-bin/gitweb.cgi?p=geeqie/xcf-pixbuf-loader.git;a=summary
  There's a few small crasher bugs. I do not know whether it still supports 
latest
  versions of the XCF format, as it's a format internal to the GIMP.

- gnome-dvb-daemon
  Is maintained, upstream. Unfortunately, I don't use DVB-T at all anymore, but 
the
  latest versions should nicely integrate with GNOME Videos, by providing a 
channels list
  through grilo.

- xchat-gnome
  I started using Polari for IRC

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

Re: F24, small backward steps

[Bastien Nocera]

- Original Message -

> Could you elaborate a little on your reasoning/thoughts please?
> 
> I am quite interesting to understand your point of view.
> From where I stand, we are offering a way for someone to unlock someone's
> else
> computer without a password.
> I understand the procedure isn't straight forward:
> - Find unattended and unlocked laptop
> - Enroll your fingerprint
> - Gain access to the computer whenever you want
> 
> I do realise that to do the second step you need access to the machine, which
> is
> pretty much the third step.
> But enrolling your fingerprint is likely less noticeable by the owner of the
> machine then, say, changing their password (which actually asks for the
> current
> password first), but will give you want you ask: permanent access to the
> machine
> (physically).

Password prompts in GNOME do mention that the fingerprint reader is activated, 
so
it's not so much opening a backdoor as opening the bay window next to the front
door.

> This is all nicely theoretical but it still seems like something that should
> be
> fixed, no?

It keeps slipping by, and it's not super important, which is the reason why it
keeps getting forgotten.

I'll get to it next time I do maintenance on fprintd.

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

Re: F24, small backward steps

[Bastien Nocera]

- Original Message -
> 
> 
> - Original Message -
> > I'm seeing 24 bugs at:
> > https://apps.fedoraproject.org/packages/fprintd/bugs/all
> > including a potential security one: https://bugzilla.redhat.com/1333882
> 
> Fedora's bugzilla is a garbage fire as far as I'm concerned. I already made
> that abundantly clear I think.

I said "garbage fire" when I meant "tire fire". It keeps on burning and I'm
too lazy/busy to handle those bugs downstream when the majority of the work,
triaging and discussions happen upstream.

I should also note that the Red Hat bugzilla is far too coarse for handling
split-up projects like gnome-control-center and gnome-settings-daemon, both of
which are connected to multiple system layers (the kernel, systemd, a lot
of specialised daemons, windowing systems, and their dependencies) and which
have separate maintainers upstream.

Apologies again for the vocabulary used.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Bastien Nocera]

For which one of the problems you listed? It would certainly have been 
interesting to list those in your original mail.

- Original Message -
> On 09/13/2016 11:09 AM, Daniel P. Berrange wrote:
> > On Tue, Sep 13, 2016 at 10:00:32AM -0500, Michael Catanzaro wrote:
> >> Hi,
> >>
> >> To be clear, the problem is that a small handful of package maintainers
> >> (including Bastien) are collectively "responsible" for all of the GNOME
> >> and freedesktop components in Fedora (including fprintd), and it's
> >> simply not reasonable to expect them to read all the bugs that are
> >> assigned to them, let alone take the time to forward them upstream. If
> >> you use Red Hat Bugzilla, the right developers may never notice your
> >> bug report at all.
> >>
> >> You have a much better chance filing bugs upstream. You should only use
> >> Red Hat Bugzilla for these components if you happen to know there is a
> >> specific maintainer who actually looks at the Red Hat bugs for that
> >> specific component, or if you're planning to propose it as a release
> >> blocker, or if you just don't care whether anybody sees your bug. If
> >> you have a packaging bug then it's the right place, but please ping
> >> someone to be sure it gets noticed.
> >>
> >> Of course this is not how Bugzilla is intended to work, but it is how
> >> it actually works for GNOME stuff. It's unfortunate, but without some
> >> Launchpad-style automatic bug forwarding, this is going to remain the
> >> case indefinitely.
> > 
> > This is a truly awful experiance from POV of a Fedora user filing bugs :-(
> > We've set a silent trap for them with no warning of the fact that their
> > bug reports are going to be ignored until Fedora EOL procedure closes
> > them :-(
> > 
> > Even if we can't enhance Red hat Bugzilla, we can at least do more to
> > alert users to this so they stand a chance of doing the right thing.
> > 
> > eg, update the component description to tell user to file in GNOME
> > bugzilla instead, and have a bot that adds a comment to any new bugs
> > that are still filed, closing them WONTFIX and asking the user to
> > re-open against upstream GNOME bugzilla, instead of leaving the bug
> > open and ignored until Fedora EOL.
> > 
> > Regards,
> > Daniel
> > 
> Thanks for recognizing this.  I am the OP.  I pretty quickly got a
> response suggesting that I file a bug report "upstream".  I did that, or
> so I thought, and immediately got a response from someone that it was
> the wrong place or list followed by another declaring the matter closed.
> I went back to my day job.
> 
> 
> --
> Roger Wells, P.E.
> leidos
> 221 Third St
> Newport, RI 02840
> 401-847-4210 (voice)
> 401-849-1585 (fax)
> roger.k.we...@leidos.com
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
> 
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Bastien Nocera]

- Original Message -
> Hi,
> 
> To be clear, the problem is that a small handful of package maintainers
> (including Bastien) are collectively "responsible" for all of the GNOME
> and freedesktop components in Fedora (including fprintd), and it's
> simply not reasonable to expect them to read all the bugs that are
> assigned to them, let alone take the time to forward them upstream. If
> you use Red Hat Bugzilla, the right developers may never notice your
> bug report at all.
> 
> You have a much better chance filing bugs upstream. You should only use
> Red Hat Bugzilla for these components if you happen to know there is a
> specific maintainer who actually looks at the Red Hat bugs for that
> specific component, or if you're planning to propose it as a release
> blocker, or if you just don't care whether anybody sees your bug. If
> you have a packaging bug then it's the right place, but please ping
> someone to be sure it gets noticed.
> 
> Of course this is not how Bugzilla is intended to work, but it is how
> it actually works for GNOME stuff. It's unfortunate, but without some
> Launchpad-style automatic bug forwarding, this is going to remain the
> case indefinitely.

Couldn't have put it better, thanks.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Bastien Nocera]

- Original Message -

> This is a truly awful experiance from POV of a Fedora user filing bugs :-(
> We've set a silent trap for them with no warning of the fact that their
> bug reports are going to be ignored until Fedora EOL procedure closes
> them :-(
> 
> Even if we can't enhance Red hat Bugzilla, we can at least do more to
> alert users to this so they stand a chance of doing the right thing.
> 
> eg, update the component description to tell user to file in GNOME
> bugzilla instead, and have a bot that adds a comment to any new bugs
> that are still filed, closing them WONTFIX and asking the user to
> re-open against upstream GNOME bugzilla, instead of leaving the bug
> open and ignored until Fedora EOL.

A couple of things could be done to help with that:
- Bring back the x-bugzilla .desktop metadata, and have ABRT file upstream bugs
- Make ABRT reports more useful (right now it's attaches a *lot* of extra
  information, basically everything it can, as files). It's not possible
  to search for parts of backtraces in the query tool.
- More useful templates when filing bugs, explaining where to file RFEs and
  non-packaging bugs. As (for GNOME and a lot of other tools) we simply
  package upstream, it would be most better to point directly to the
  right place to file bugs.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Bastien Nocera]

- Original Message -
> On Tue, Sep 13, 2016 at 07:30:07AM -0400, Bastien Nocera wrote:
> > 
> > 
> > - Original Message -
> > > I'm seeing 24 bugs at:
> > > https://apps.fedoraproject.org/packages/fprintd/bugs/all
> > > including a potential security one: https://bugzilla.redhat.com/1333882
> > 
> > Fedora's bugzilla is a garbage fire as far as I'm concerned. I already made
> > that abundantly clear I think.
> 
> Well, https://bugzilla.redhat.com/1333882 is a security bug, blocking:
> https://bugzilla.redhat.com/1305770 which mentions:
> ``
> Upstream bug:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=89407
> ``
> 
> and:
> ``
> This issue has been reported as far back as 2011:
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=651196
> ``
> 
> So, you may not care about Red Hat bugzilla, but there is a security bug
> issued
> in there for more than 6 months and which is referencing a bug "upstreamed"
> for
> 5 years.

Which I don't consider to be a security bug, hence the reason why I didn't 
touch it.

> To me it looks like there is something in your "garbage" that needs a little
> attention.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Bastien Nocera]

- Original Message -
> I'm seeing 24 bugs at:
> https://apps.fedoraproject.org/packages/fprintd/bugs/all
> including a potential security one: https://bugzilla.redhat.com/1333882

Fedora's bugzilla is a garbage fire as far as I'm concerned. I already made
that abundantly clear I think.

> so I'm not sure what you call 'upstream bugs' but there are bugs reported
> against fprintd.

By upstream, I mean upstream. That's https://bugs.freedesktop.org for fprintd.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Bastien Nocera]

- Original Message -
> 
> 
> Dne 9.9.2016 v 21:53 Roger Wells napsal(a):
> > Just a couple of smallish things after upgrading (via dnf) from F23 to
> > F24 a couple of months ago:
> >
> >
> > 2. fingerprint identification:
> >
> > The laptop has a fingerprint reader and it works fine.  However
> > I prefer not to use it. The user set up specifies that fingerprint login
> > is disabled.
> >
> > However whenever I am asked for a password the fingerprint
> > reader blinks until I swipe a finger over it (even after using a
> > password).
> >
> > No fingerprint is registered.
> >
> > This is different than F23 where it never blinked.
> >
> >
> 
> 
> If I am not mistaken "dnf remove fprintd-pam" should completely disable
> the fingerprint reader, although you might observe some error messages
> in your journal later.
> 
> But don't worry, the fprind daemon is broken for ages and nobody cares,
> so it might work once, but then it crashes ...

There's no upstream bugs against fprintd specifically, so, like, you're wrong?
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Installing alsa-ucm by default in F25?

[Bastien Nocera]

FWIW, this was done in:
commit 07106ddaa4f45aa188019d497a6a042bd7b58750
Author: Peter Robinson 
Date:   Sat Apr 2 10:24:17 2016 +0100

add alsa-ucm

For F24 and F25.

Thanks!

- Original Message -
> > alsa-ucm contains routing information to setup sound codecs
> > on some machines, usually SoC-based. It contains configuration
> > that's mostly relevant to ARM devices, but also a few Atom (CherryTrail and
> > Broadwell) related SoCs on Intel.
> >
> > Could we install alsa-ucm by default? As it is necessary for PulseAudio to
> > be able to use those devices, should we get it dragged in as a PA
> > dependency?
> 
> I think pulling it in by default is fine, it's tiny in size and has no
> extra deps, I'd add it to comps as opposed to a hard dep on pulseaudio
> though.
> 
> Peter
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
> 
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Retiring media-explorer

[Bastien Nocera]

Hey,

media-explorer has been broken for a while, and didn't see any
upstream development since 2013 as can be seen here:
https://github.com/media-explorer/media-explorer/commits/master

The versions of clutter, clutter-gst and GStreamer used are positively
ancient, and the grilo version is the old API (0.2).

Shame it's going away, it was a nice and simple "set top box" type UI,
which could have found more use.

If anyone wants to work on this upstream and downstream, drop me a private
message, and I'll do my best to help revive it.

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

Installing alsa-ucm by default in F25?

[Bastien Nocera]

Hey,

alsa-ucm contains routing information to setup sound codecs
on some machines, usually SoC-based. It contains configuration
that's mostly relevant to ARM devices, but also a few Atom (CherryTrail and
Broadwell) related SoCs on Intel.

Could we install alsa-ucm by default? As it is necessary for PulseAudio to
be able to use those devices, should we get it dragged in as a PA
dependency?

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

Re: iphone mount in nautilus on Fedora 24

[Bastien Nocera]

- Original Message -

> I did not have gvfs-gphoto2 installed. After installing it I now see
> the separate mount. Thanks for your help!
> 
> Let me try to summarize. Can you please correct me if I'm wrong:
> 
> - Before (Fedora 22) I didn't need this because a "generic mount" of the
>   phone was supported.
> - Now (Fedora 24) I need gvfs-gphoto2 installed to access pictures on
>   the iphone.
> 
> I have a custom install so I don't know the answer to this question:
>   - Is gvfs-gphoto2 get installed by default?

It's in the "gnome-desktop" group, which is in the kickstart file for
Fedora Workstation.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: iphone mount in nautilus on Fedora 24

[Bastien Nocera]

- Original Message -
> 
> 
> On 07/12/2016 05:01 AM, Bastien Nocera wrote:
> > 
> > 
> > Huh, the phone should still be getting mounted, but as a camera, and just
> > as
> > a camera, and you can remove photos there without botching the phone's
> > internal
> > photo database.
> > 
> > That definitely works here.
> > --
> 
> Yeah All I see are "documents on dusty's iphone" and it shows 4 apps
> that I have installed on my phone. The apps are random and have
> nothing to do with my pictures.
> 
> Maybe I have a bad setup.

It should be a separate mount. Make sure you have gvfs-gphoto2 installed as 
well.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: iphone mount in nautilus on Fedora 24

[Bastien Nocera]

- Original Message -
> 
> 
> On 07/11/2016 07:33 AM, Bastien Nocera wrote:
> > 
> > 
> > - Original Message -
> >>> On 07/09/2016 12:04 AM, Peter Robinson wrote:
> >>>>> In older Fedora (at least Fedora 22) I could easily mount my ihphone
> >>>>> in Nautilus. I could click on it in the left hand side of the File
> >>>>> Manager and it would mount.
> >>>>>
> >>>>> I am having trouble getting this same behavior in Fedora 24. Can
> >>>>> someone verify this works or does not work for them? You should be
> >>>>> able to verify this with Fedora 24 + Gnome + iphone + iphone cable.
> >>>>
> >>>> Support is provided by gvfs-afc through the libimobiledevice stack,
> >>>> the later hasn't really changed since F-22 when the 1.2.0 version
> >>>> fixed up support for the new iOS devices, upstream have confirmed that
> >>>> iOS 10 works with that version too [1], so not sure what might have
> >>>> broken.
> >>>
> >>> Hey Peter, thanks for responding.
> >>>
> >>> So things "work" just not as they used to. I can still mount the
> >>> files from the iphone if I use idevicepair and ifuse as described
> >>> at http://www.dedoimedo.com/computers/fedora-22-iphone.html
> >>>
> >>> The problem is when I'm using nautilus I used to just be able to click
> >>> on the iphone in the left hand side menu and it would mount the files
> >>> and I could browse around. Now I see a similar item in the menu but
> >>> all I see are "Documents on Dusty's iPhone" and it lists out a few apps
> >>> that are installed on my phone, but it doesn't give me any option to
> >>> mount and browse files.
> >>>
> >>
> >> Well there's been no change lower down the stack since F-22 and the
> >> core functionality seems to be working. That indicates it's either 1)
> >> a change in iOS version that has impacted this (I've no idea about
> >> this) or a change in the way gvfs deals with iOS/afc which looking at
> >> changelogs for 1.28 could be  the case [1]. The one of interest seems
> >> to be commit 0b68656
> >>
> >> [1] https://download.gnome.org/sources/gvfs/1.28/gvfs-1.28.0.changes
> 
> Thanks Peter
> 
> > 
> > Yup. The "normal" mount contains nothing that normal users should access.
> > Accessing the photos will leave ghosts on the device, and there have been
> > no
> > ways to update the music database in Linux for a few iOS releases.
> > 
> > You can still access the device by editing the URL in the "Documents on..."
> > location. Just remove the ":3" at the end.
> > 
> > If you have use cases that aren't the 2 mentioned above, or using your
> > iDevice
> > as a thumb drive, please file bugs against gvfs in the upstream GNOME
> > Bugzilla.
> > 
> 
> Thanks Bastien. My use case is that I want to be able to copy pictures
> off of my phone and onto the computer. I simply copy them off of the
> phone, then eject phone from computer and then I delete them on the
> phone using the phones interface.. This is my method of recovering
> space on the phone.
> 
> I used to be able to just double click the icon in Nautilus and
> drag/drop the pictures where I wanted them to go. Now I have to use
> the CLI to get the same functionality.

Huh, the phone should still be getting mounted, but as a camera, and just as
a camera, and you can remove photos there without botching the phone's internal
photo database.

That definitely works here.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: iphone mount in nautilus on Fedora 24

[Bastien Nocera]

- Original Message -
> > On 07/09/2016 12:04 AM, Peter Robinson wrote:
> >>> In older Fedora (at least Fedora 22) I could easily mount my ihphone
> >>> in Nautilus. I could click on it in the left hand side of the File
> >>> Manager and it would mount.
> >>>
> >>> I am having trouble getting this same behavior in Fedora 24. Can
> >>> someone verify this works or does not work for them? You should be
> >>> able to verify this with Fedora 24 + Gnome + iphone + iphone cable.
> >>
> >> Support is provided by gvfs-afc through the libimobiledevice stack,
> >> the later hasn't really changed since F-22 when the 1.2.0 version
> >> fixed up support for the new iOS devices, upstream have confirmed that
> >> iOS 10 works with that version too [1], so not sure what might have
> >> broken.
> >
> > Hey Peter, thanks for responding.
> >
> > So things "work" just not as they used to. I can still mount the
> > files from the iphone if I use idevicepair and ifuse as described
> > at http://www.dedoimedo.com/computers/fedora-22-iphone.html
> >
> > The problem is when I'm using nautilus I used to just be able to click
> > on the iphone in the left hand side menu and it would mount the files
> > and I could browse around. Now I see a similar item in the menu but
> > all I see are "Documents on Dusty's iPhone" and it lists out a few apps
> > that are installed on my phone, but it doesn't give me any option to
> > mount and browse files.
> >
> 
> Well there's been no change lower down the stack since F-22 and the
> core functionality seems to be working. That indicates it's either 1)
> a change in iOS version that has impacted this (I've no idea about
> this) or a change in the way gvfs deals with iOS/afc which looking at
> changelogs for 1.28 could be  the case [1]. The one of interest seems
> to be commit 0b68656
> 
> [1] https://download.gnome.org/sources/gvfs/1.28/gvfs-1.28.0.changes

Yup. The "normal" mount contains nothing that normal users should access.
Accessing the photos will leave ghosts on the device, and there have been no
ways to update the music database in Linux for a few iOS releases.

You can still access the device by editing the URL in the "Documents on..."
location. Just remove the ":3" at the end.

If you have use cases that aren't the 2 mentioned above, or using your iDevice
as a thumb drive, please file bugs against gvfs in the upstream GNOME Bugzilla.

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

Re: F25 Self Contained Change: IBus Emoji Typing

[Bastien Nocera]

- Original Message -
> On 07/08/16 20:41, Bastien Nocera-san wrote:
> > I think that the emoji input method should be a separate input method, so
> > that most users would have the choice between inputting using the keyboard
> > layout that matches their keyboard, and a separate input method for
> > emojis.
> 
> I think the emoji typing does not depend on XKB but is used frequently and I
> don't think it should be separated.

It is on every other platform I can think of.

> If the engine should be enabled by default for any languages, I think it
> would make sense that the XKB engines also enable emoji and switching
> engines
> would be more cost than switching input modes.
> Once this feature is implemented, the translatable annotations also can be
> implementable for input method engines.
> I think other platforms does not separate engines for emoji typing.

They do.

> > The IBus XKB engine is not discoverable (it's not listed in GNOME's Region
> > & Language settings) and the keyboard shortcut to input emojis is also not
> > discoverable. Having a separate input method is likely the better way to
> > implement this.
> 
> I replied this.

You haven't. You're implementing this without any regards for prior art and
design work that's been done. You certainly can implement this internally
however you want, but the end result has to match certain expectations, and
designs. Your implementation won't, and as a result won't be discoverable.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 Self Contained Change: IBus Emoji Typing

[Bastien Nocera]

- Original Message -
> Bastien Nocera <bnoc...@redhat.com> さんはかきました:
> 
> > I think that the emoji input method should be a separate input method,
> > so that most users would have the choice between inputting using the
> > keyboard layout that matches their keyboard, and a separate input
> > method for emojis.
> 
> Are you talking about something like ibus-gucharmap?

Something similar to:
https://github.com/lalomartins/ibus-uniemoji

ibus-gucharmap is far too wide a use-case.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 Self Contained Change: IBus Emoji Typing

[Bastien Nocera]

I think that the emoji input method should be a separate input method, so that 
most users would have the choice between inputting using the keyboard layout 
that matches their keyboard, and a separate input method for emojis.

The IBus XKB engine is not discoverable (it's not listed in GNOME's Region & 
Language settings) and the keyboard shortcut to input emojis is also not 
discoverable. Having a separate input method is likely the better way to 
implement this.

- Original Message -
> On 07/08/16 19:54, Bastien Nocera-san wrote:
> >
> >
> > - Original Message -
> >> Bastien Nocera <bnoc...@redhat.com> さんはかきました:
> > 
> >>> Except that the way that you'll be implementing this means it's
> >>> completely
> >>> undiscoverable. I know no one other than those that already use an IBus
> >>> method to input a non-latin language that use things like typing booster.
> >>
> >> Oh, sorry, I wrote mistakenly "typing booster" above, that was just
> >> a typo. What Fujiwara San is implementing has nothing to do with typing
> >> booster, it is for the IBus XKB engine.
> >
> > Same applies to the IBus XKB engine. This engine doesn't seem to be listed
> > in GNOME's Region and Language panel, the shortcut isn't discoverable, and
> > the
> > UI for it doesn't match what users expect from their use of emoji on mobile
> > platforms.
> >
> 
> If the implementaion will satisfy users, I also wish to implement to
> GtkIMContextSimple.
> I agree the undiscoverable point should be considered later.
> Maybe a switching radio menu item is an idea?
> I don't wish the lookup table by default against the mobile.
> I'm not clarified that you pointed the UI which does not match mobile users.
> 
> 
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 Self Contained Change: IBus Emoji Typing

[Bastien Nocera]

- Original Message -
> Bastien Nocera <bnoc...@redhat.com> さんはかきました:

> > Except that the way that you'll be implementing this means it's completely
> > undiscoverable. I know no one other than those that already use an IBus
> > method to input a non-latin language that use things like typing booster.
> 
> Oh, sorry, I wrote mistakenly "typing booster" above, that was just
> a typo. What Fujiwara San is implementing has nothing to do with typing
> booster, it is for the IBus XKB engine.

Same applies to the IBus XKB engine. This engine doesn't seem to be listed
in GNOME's Region and Language panel, the shortcut isn't discoverable, and the
UI for it doesn't match what users expect from their use of emoji on mobile
platforms.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 Self Contained Change: IBus Emoji Typing

[Bastien Nocera]

- Original Message -
> On 07/08/16 00:25, Mike FABIAN-san wrote:
> > Bastien Nocera <bnoc...@redhat.com> さんはかきました:
> >
> >> Re-send to the change owner
> >>
> >> - Original Message -
> >>> = Proposed Self Contained Change: IBus Emoji Typing  =
> >>> https://fedoraproject.org/wiki/Changes/IBus_Emoji_Typing
> >>>
> >>> Change owner(s):
> >>> * Takao Fujiwara 
> >>>
> >>> The IBus core will provide the Emoji Unicode typing with the IBus XKB
> >>> engines.
> >>>
> >>> == Detailed Description ==
> >>> IBus has already provided Unicode hex codes tying with Ctrl-Shift-u and
> >>> now
> >>> we
> >>> think the similar implementation for the Emoji typging. With IBus XKB
> >>> engines,
> >>> Emoji typing will be provided with the Emoji annotations [1] following
> >>> Ctrl-
> >>> Shift-e.
> >>>
> >>> == Scope ==
> >>> * Proposal owners:
> >>>  - IBus core provide the dictionary of the Emoji typing.
> >>>  - IBus XKB engines load the Emoji dictionary.
> >>>
> >>> * Other developers: N/A
> >>>
> >>> * Release engineering: N/A
> >>>  - List of deliverables: N/A
> >>>
> >>> * Policies and guidelines: N/A
> >>>
> >>> * Trademark approval: N/A
> >>>
> >>> [1] http://unicode.org/emoji/charts/index.html#col-annotations
> >>
> >> Will this use:
> >> https://github.com/lalomartins/ibus-uniemoji/
> >> ?
> >
> > I don’t think so, it is supposed to work in all xkb engines of
> > ibus-typing booster, this is not a seperate engine like ibus-uniemoji.
> 
> Sorry, I missed the email.
> I expect to use emoji not to switch the IBus engines.
> Actually ibus-anthy already implements emoji typing in Japanese.
> 
> This implementation enables emoji typing in English with any IBus XKB
> engines.
> I also evaluated ibus-uniemoji:
> http://unicode.org/pipermail/unicode/2016-June/003781.html
> http://unicode.org/pipermail/unicode/2016-July/003786.html
> 
> Now IBus XKB engine uses both en.xml for annotations and emoji.json for
> categories and ascii aliases.

Except that the way that you'll be implementing this means it's completely
undiscoverable. I know no one other than those that already use an IBus
method to input a non-latin language that use things like typing booster.

A separate input method that's automatically added to the default list of
"keyboard layouts" would be much better suited to our use case, and matches
the way people are used to enter emojis on Android and iOS, with a separate
keyboard layout.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 Self Contained Change: IBus Emoji Typing

[Bastien Nocera]

Re-send to the change owner

- Original Message -
> = Proposed Self Contained Change: IBus Emoji Typing  =
> https://fedoraproject.org/wiki/Changes/IBus_Emoji_Typing
> 
> Change owner(s):
> * Takao Fujiwara 
> 
> The IBus core will provide the Emoji Unicode typing with the IBus XKB
> engines.
> 
> == Detailed Description ==
> IBus has already provided Unicode hex codes tying with Ctrl-Shift-u and now
> we
> think the similar implementation for the Emoji typging. With IBus XKB
> engines,
> Emoji typing will be provided with the Emoji annotations [1] following Ctrl-
> Shift-e.
> 
> == Scope ==
> * Proposal owners:
>  - IBus core provide the dictionary of the Emoji typing.
>  - IBus XKB engines load the Emoji dictionary.
> 
> * Other developers: N/A
> 
> * Release engineering: N/A
>  - List of deliverables: N/A
> 
> * Policies and guidelines: N/A
> 
> * Trademark approval: N/A
> 
> [1] http://unicode.org/emoji/charts/index.html#col-annotations

Will this use:
https://github.com/lalomartins/ibus-uniemoji/
?

It would be great if this feature used the emoji fonts directly, so we
can use colour icons:
http://www.hadess.net/2016/05/blog-backlog-post-1-emoji.html

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

Re: F25 Self Contained Change: Better Switchable Graphics Support

[Bastien Nocera]

- Original Message -
> = Proposed Self Contained Change: Better Switchable Graphics Support =
> https://fedoraproject.org/wiki/Changes/BetterSwitchableGraphicsSupport
> 
> Change owner(s):
> * Hans de Goede 
> 
> All modern laptops have a gpu integrated into their processor (the
> igpu), some models also have a more powerful dedicated gpu (dgpu),
> this is called switchable graphics. The goal of this feature is to
> improve Fedora's support for such laptops.
> 
> 
> == Detailed Description ==
> By default all apps will run on the more energy efficient igpu and the
> OS can choose to switch to the dgpu when more gpu-power is necessary,
> trading battery time for graphics performance. On most laptops the
> default gpu can be changed to the dgpu so that everything will always
> run on the dgpu.
> 
> Linux support for switchable graphics currently is not very good. E.g.
> on many laptops some of the external connectors are only connected to
> the dgpu and to be able to use those external connectors without
> issues users need to change the default gpu to the dgpu, resulting in
> a hot running laptop and the battery draining much faster.
> 
> The goal of this feature is to improve switchable graphics support
> under Linux, allowing the igpu to be used as default, allowing maximum
> batter life, while keeping everthing working normally. Specifically
> the following should all work: external outputs, suspend / resume
> (including suspend/resume with external monitors connected / while
> docked) and suspending the dgpu when not used.

Yep, all this should be automatic.

> A secondary goal is to allow people to run graphically demanding
> programs on the dgpu by starting them with "DRI_PRIME=1 program", note
> that since we do not support dynamic reclocking of nvidia GPUs this
> will not always result in a performance improvement.

I have some WIP code for gnome-shell to allow that, and it would detect
whether prime is available through a D-Bus service (which also runs a
few hacks for some devices):
https://github.com/hadess/switcheroo-control

> == Scope ==
> * Proposal owners: Fix switchable-graphics related kernel and xorg
> bugs, ensure gnome-control-panel "Displays" setting works properly on
> switchable-graphics setups
> 
> * Other developers: GNOME control-panel developers (if changes are
> necessary there)

Shouldn't be necessary, though it would be nice if the display adapters
available trickled down from the switcheroo D-Bus service all the way
to gnome-session and then the Details panel in GNOME.

See also:
https://wiki.gnome.org/Design/OS/DualGPU

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

Re: F25 Self Contained Change: IBus Emoji Typing

[Bastien Nocera]

- Original Message -
> = Proposed Self Contained Change: IBus Emoji Typing  =
> https://fedoraproject.org/wiki/Changes/IBus_Emoji_Typing
> 
> Change owner(s):
> * Takao Fujiwara 
> 
> The IBus core will provide the Emoji Unicode typing with the IBus XKB
> engines.
> 
> == Detailed Description ==
> IBus has already provided Unicode hex codes tying with Ctrl-Shift-u and now
> we
> think the similar implementation for the Emoji typging. With IBus XKB
> engines,
> Emoji typing will be provided with the Emoji annotations [1] following Ctrl-
> Shift-e.
> 
> == Scope ==
> * Proposal owners:
>  - IBus core provide the dictionary of the Emoji typing.
>  - IBus XKB engines load the Emoji dictionary.
> 
> * Other developers: N/A
> 
> * Release engineering: N/A
>  - List of deliverables: N/A
> 
> * Policies and guidelines: N/A
> 
> * Trademark approval: N/A
> 
> [1] http://unicode.org/emoji/charts/index.html#col-annotations

Will this use:
https://github.com/lalomartins/ibus-uniemoji/
?

It would be great if this feature used the emoji fonts directly, so we
can use colour icons:
http://www.hadess.net/2016/05/blog-backlog-post-1-emoji.html

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

[Bastien Nocera]

- Original Message -
> On 01/06/16 10:20, Bastien Nocera wrote:
> 
> >> On Sun, May 29, 2016 at 06:51:20PM -0600, Chris Murphy wrote:
> >>> So there's tmux, screen, curl, wget, and probably quite a few others
> >>> that don't necessarily get daemonized that are probably affected.
> >>
> >> I would really like to see a solution whereby tmux and screen _just
> >> work_ without any required changes to user behavior. They're basically
> >> commands which _indicate_ "I want a new session that persists".
> >
> > Really? The only times I ever used it was to access serial consoles with
> > a better emulation than separate apps.
> 
> You've obviously never had to run something that's going to take hours
> or days to complete on a remote server and not wanted it to abort half
> way through because of a network glitch then.

Yeah, I never used nohup. *roll eyes*

> That's when I use screen, either just setting running something in the
> background, or leaving it connected but knowing it will continue if
> anything goes wrong and I can just reattach from a new login.

The screen manual says "Screen  is  a  full-screen  window manager that
multiplexes a physical terminal between several processes (typically
interactive shells).".

It doesn't say "it persists in the session by default, always, that's
always how you're going to use it".
--
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

[Bastien Nocera]

- Original Message -
> On Sun, May 29, 2016 at 06:51:20PM -0600, Chris Murphy wrote:
> > So there's tmux, screen, curl, wget, and probably quite a few others
> > that don't necessarily get daemonized that are probably affected.
> 
> I would really like to see a solution whereby tmux and screen _just
> work_ without any required changes to user behavior. They're basically
> commands which _indicate_ "I want a new session that persists".

Really? The only times I ever used it was to access serial consoles with
a better emulation than separate apps.

> It seems fine to have some administrative option which prevents that,
> but I think allowing that behavior should be the default. That way,
> accidental lingering processes will be cleaned up, but people's
> expectations around tmux/screen will still be met.
> 
> I liked the suggestion of having those programs become "scope" aware
> (https://github.com/tmux/tmux/issues/428) but it looks like upstream
> tmux at least is not keen on it. What can we do instead?

Patch the applications downstream, or document things with enough details
and mention it in the release notes.

Both the writing of the documentation and the patching would show whether
implementing lingering is well documented enough, and viable enough.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 Self Contained Change: Replace UDisks2 by Storaged

[Bastien Nocera]

- Original Message -
> On Fri, 15 Apr 2016 05:09:00 -0400 (EDT)
> Bastien Nocera <bnoc...@redhat.com> wrote:
> 
> > Hey,
> ...
> > What are the additional dependencies compared to Udisks2?
> 
> None AFAIK: storaged itself should not pull anything else than udisks2 in
> the current Rawhide.
> 
> > Would gnome-disk-utility, gvfs, etc. work as well as they used to without
> > regressions when dropping in storaged, either on a running system, or when
> > compiling against it?
> 
> Yes, such is the plan.
> 
> > Will bug fixes and enhancements to the common part between storaged and
> > udisks2 be backported to udisks2?
> 
> I assume this is a question for the udisks2 developers.

It's not. I don't think that Workstation wants to stray from upstream GNOME,
which uses udisks2, so providing maintenance would be useful.

> > I'm fairly certain we don't want iSCSI binaries in the Workstation
> > installation (we've been trying to get rid of the ones that Anaconda brings
> > in already).
> > 
> > I also don't see why ZRam is something 1) you'd want to have to configure,
> > 2) that has its place in a storage API.
> 
> It's been put to the API because Blivet would like to use it from storaged
> eventually.

Still, I don't understand the use-case for such an interface.

> However you're right: this is something that the user may not
> want
> to install and therefore the storaged-zram is a separate package. Same as
> LSM, LVM2, iSCSI, bcache and BTRFS plugins. Of course the plugins have their
> own additional dependencies.

Would that mean that we don't need to ship with the iscsi initiator in
Workstation because there would be no direct or indirect dependencies in 
Anaconda,
for example?
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 Self Contained Change: Replace UDisks2 by Storaged

[Bastien Nocera]

- Original Message -

> > 2) that has its place in a storage API.
> Why is an API providing some additional functionality you are not going
> to use in your specific usecase a problem ?
> 
> I'm sure glibc and kernel provide many API calls not directly used by
> the default apps on the workstation and we are still using them...

If I ever saw an example of logical fallacy, that is one.

Why do I care? Because if I didn't whine on this very list some time ago,
storaged wouldn't be API-compatible with udisks2, and I have to wonder about
the architecture of something we would have to support when it makes
decisions like supporting features for which you don't have a clear use-case.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 Self Contained Change: Replace UDisks2 by Storaged

[Bastien Nocera]

Hey,

- Original Message -
> = Proposed Self Contained Change: Replace UDisks2 by Storaged =
> https://fedoraproject.org/wiki/Changes/Replace_UDisks2_by_Storaged
> 
> Change owner(s):
> * Peter Hatina 
> * Tomáš Smetana 
> 
> Storaged extends UDisks2 API by exporting several enterprise features
> (in form of plugins), such as LVM2 and iSCSI. This project is a
> drop-in replacement for UDisks2, either from D-Bus or binary point of
> view. The main motivation of this change is to provide the unified
> D-Bus API for all the clients who are willing to manage LVM2, iSCSI,
> Btrfs, BCache, LSM and ZRam.
> 
> == Detailed Description ==
> Aim of Storaged is to provide unified higher level management
> interface for various clients who are willing to query and manage
> storage bits of the system. We plan to replace UDisks2 by Storaged,
> since the Storaged itself is the fork of UDisks2 and these 2 projects
> in its core haven't diverged so much (Storaged got some improvements
> which popped up while using it).

What are the additional dependencies compared to Udisks2?

Would gnome-disk-utility, gvfs, etc. work as well as they used to without 
regressions when
dropping in storaged, either on a running system, or when compiling against it?

Will bug fixes and enhancements to the common part between storaged and
udisks2 be backported to udisks2?

I'm fairly certain we don't want iSCSI binaries in the Workstation installation
(we've been trying to get rid of the ones that Anaconda brings in already).

I also don't see why ZRam is something 1) you'd want to have to configure,
2) that has its place in a storage API.

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

Re: Orphaning: xchat-gnome

[Bastien Nocera]

- Original Message -
> Reasons:
> - it's effectively dead upstream (and has been for about 5 years...)
> - it has a variety of crashers I haven't gotten around to finding time to fix
> - I don't really use it any more anyways
> 
> Suggestions: use hexchat, or polari, or irccloud, or really anything
> else.
> Or take it if you want.

Taken until https://bugzilla.gnome.org/show_bug.cgi?id=709189 makes the 
migration
a non-problem.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: kmods and Fedora

[Bastien Nocera]

- Original Message -
> Josh Boyer wrote:
> > If you are creating a cert to sign the out-of-tree modules and expect
> > it to be accepted by the kernel, it cannot be ephemeral.  A user would
> > need someway to import it into their kernel or have it passed from
> > grub.  The only way to do so is to have it embedded in shim or the
> > kernel during the build of those binaries.  I do not foresee Fedora
> > creating yet another persistent key to sign things with, which means
> > you would need another tool that can use the existing key in the
> > kernel builders.
> 
> That just proves that Restricted Boot and especially our implementation of
> it (requiring kernel modules to be signed) is a very bad thing.

How do you expect to be able to ensure that the kernel only loads "known good"
modules if you can insert random modules that might subvert SecureBoot and
all that it allows to secure?
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Browser choice in live images

[Bastien Nocera]

- Original Message -
> On Thu, 2015-11-05 at 09:53 -0600, Michael Catanzaro wrote:
> > On Thu, 2015-11-05 at 16:21 +0100, Jos Vos wrote:
> > > I see that the F23 Xfce live image still includes only Midori as the
> > > internet browser, similar to the F22 image.
> > 
> > Midori still depends on an old version of WebKitGTK+, so it has not had
> > any security updates in a long time. It's irresponsible to ship it
> > until this is fixed.
> 
> WebKitGTK+ 2.4.9 was shipped in May, and 2.4.8 before that in January
> with a bunch of security fixes, all despite the fact that they had since
> released 2.6.x and 2.8.x.  This tells me that the 2.4 branch, while
> deprecated, continues to be maintained.

Michael is an upstream WebKitGTK+ developer, he'd know.
-- 
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

[Bastien Nocera]

- Original Message -
> Recently, I filed a bug (1274451) about running virt-manager on Wayland.
> As it turns out that this is applicable to running gui applications as
> root on Wayland in general, the scope was changed (see Cole's comments).
> 
> As Halfline points out, the decision needs to be made whether to allow
> gui applications to be run as root.  I figured I'd bring this up for
> discussion in the hopes that a decision may be made whether or not to
> allow this.
> 
> In the instance that the decision is made to not allow gui applications
> root access, then we will also need to figure out a sane way to have
> applications that require more than the usual set of user priviledges to
> continue to work across multiple compositors and window managers that
> may or may not have the necessary authentication agents built-in.

We already have those mechanisms: polkit (né PolicyKit) and D-Bus.

This is how we control backlights, LEDs, network connections, Bluetooth,
geolocalisation, etc. in a standard Linux desktop.

Cheers
-- 
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: [EPEL-devel] Orphaned Packages in epel7 (2015-10-26)

[Bastien Nocera]

- Original Message -
> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for sure
> that the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Can you please just retire libgnomecups and be done with it? You've been 
emailing
us about this package since the end of June, the 6 weeks have been and gone many
times over.

Cheers

> Note: If you received this mail directly you (co)maintain one of the affected
> packages or a package that depends on one. Please adopt the affected package
> or
> retire your depending package to avoid broken dependencies, otherwise your
> package will be retired when the affected package gets retired.
> 
> Package(co)maintainersStatus Change
> ===
> bouncycastle-pkix orphan, java-sig, msrb  1 weeks ago
> create-tx-configuration   orphan, immanetize, sparks  8 weeks ago
> electronics-menu  orphan, chitlesh2 weeks ago
> erlang-basho_metrics  orphan, erlang-sig, skottler7 weeks ago
> erlang-getopt orphan, erlang-sig, skottler7 weeks ago
> erlang-mochiweb   orphan, erlang-sig, skottler7 weeks ago
> libgnomecups  orphan, ajax, alexl, caillon,   18 weeks ago
>   caolanm, group::gnome-sig,
>   hadess, johnp, mbarnes, rhughes,
>   rstrode, ssp, vicodan, xiphmont
> mockito   orphan  19 weeks ago
> prototype orphan  5 weeks ago
> reflections   orphan, gil 0 weeks ago
> scriptaculous orphan  5 weeks ago
> shutter   orphan  1 weeks ago
> syntaxhighlighter orphan  5 weeks ago
> 
> The following packages require above mentioned packages:
> Depending on: bouncycastle-pkix (4), status change: 2015-10-16 (1 weeks ago)
>   bouncycastle-mail (maintained by: s4504kr)
>   bouncycastle-mail-1.50-3.el7.noarch requires bouncycastle-pkix 
> = 1.50-1.el7
>   bouncycastle-mail-1.50-3.el7.src requires bouncycastle-pkix = 
> 1.50-1.el7
> 
>   canl-java (maintained by: ellert)
>   canl-java-2.1.1-4.el7.noarch requires 
> mvn(org.bouncycastle:bcpkix-jdk15on)
>   = 1.50
>   canl-java-2.1.1-4.el7.src requires 
> mvn(org.bouncycastle:bcpkix-jdk15on) =
>   1.50
> 
>   voms-api-java (maintained by: ellert)
>   voms-api-java-3.0.5-3.el7.noarch requires
>   mvn(org.bouncycastle:bcpkix-jdk15on) = 1.50
>   voms-api-java-3.0.5-3.el7.src requires 
> mvn(org.bouncycastle:bcpkix-jdk15on)
>   = 1.50
> 
>   voms-clients-java (maintained by: ellert)
>   voms-clients-java-3.0.6-3.el7.noarch requires
>   mvn(org.italiangrid:voms-api-java) = 3.0.5
>   voms-clients-java-3.0.6-3.el7.src requires
>   mvn(org.italiangrid:voms-api-java) = 3.0.5
> 
> 
> Depending on: electronics-menu (2), status change: 2015-10-07 (2 weeks ago)
>   kicad (maintained by: jcapik)
>   kicad-2015.03.21-2.rev5528.el7.1.x86_64 requires 
> electronics-menu =
>   1.0-12.el7
> 
>   qelectrotech (maintained by: remi)
>   qelectrotech-0.40-1.el7.x86_64 requires electronics-menu = 
> 1.0-12.el7
> 
> 
> Depending on: erlang-mochiweb (1), status change: 2015-08-31 (7 weeks ago)
>   couchdb (maintained by: wtogami)
>   couchdb-1.6.1-1.el7.src requires erlang-mochiweb = 2.4.2-2.el7
>   couchdb-1.6.1-1.el7.x86_64 requires erlang-mochiweb(x86-64) = 
> 2.4.2-2.el7
> 
> 
> Depending on: libgnomecups (2), status change: 2015-06-17 (18 weeks ago)
>   libgnomeprint22 (maintained by: mkasik, alexl, caillon, caolanm,
>   group::gnome-sig, johnp, mbarnes, rhughes, rnorwood, rstrode, ssp,
>   xiphmont)
>   libgnomeprint22-2.18.8-8.el7.src requires libgnomecups-devel = 
> 0.2.3-15.el7
>   libgnomeprint22-2.18.8-8.el7.x86_64 requires 
> libgnomecups-1.0.so.1()(64bit)
> 
>   libgnomeprintui22 (maintained by: mkasik, alexl, caillon, caolanm,
>   group::gnome-sig, johnp, mbarnes, rhughes, rnorwood, rstrode, ssp,
>   xiphmont)
>   libgnomeprintui22-2.18.6-8.el7.1.x86_64 requires
>   libgnomeprint-2-2.so.0()(64bit)
> 
> 
> Depending on: mockito (1), status change: 2015-06-12 (19 weeks ago)
>   assertj-core (maintained by: rfenkhuber)
>   assertj-core-2.2.0-1.el7.noarch requires 
> mvn(org.mockito:mockito-core) =
>   

Re: Packaging of PlayOnLinux

[Bastien Nocera]

- Original Message -
> On 2015-10-14, Alexandre Moine  wrote:
> > But, we have to be very careful with this software since it downloads
> > scripts and icons from the web (in the automated installer part)...
> > And it can install for example IE or steam by simply clicking a
> > button, without any mentions of the proprietary part of these
> > software. I don't know if this is legal from the point of vue of our
> > lawyers :)
> >
> Yet web browsers download and execute proprietary software every minute
> and nobody is for removing the browsers from Fedora because of that.

That would be because that's not the sole purpose of a web browser, as
is explained the guidelines. We'd remove any browser that *only* did that.
-- 
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: Announce: Group projects in Copr

[Bastien Nocera]

- Original Message -
> It is my pleasure to announce new version of Copr.
>   https://copr.fedoraproject.org/

Seems that the new version broke sorting by date in the Builds listing.

For example, I don't really understand how this is sorted:
http://i.imgur.com/l1pUiMJ.png
-- 
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: Packaging of PlayOnLinux

[Bastien Nocera]

- Original Message -
> Hello,
> 
> I want to ask if PlayOnLinux could be packaged to Fedora. This program
> has list of proprietary programs which are not downloaded but could be
> installed if you give it setup.exe file.
> 
> Also it downloads Windows redistributable when user explicitly wants to
> install program (which using this redist) or given redistributable.
> 
> If this is not "legal" in terms of Fedora how it's differ from
> OpenSource software which are using not-OpenSource addons? Example of
> this could be https://marketplace.firefox.com .
> 
> I think it's sad that this good LGPL wine prefix manager software is
> not part of the Fedora and I like to change this.

If the application cannot work without downloading anything, or being supplied
third-party (sometimes proprietary) applications, then it's closer to an
emulator than a front-end that's generally useful.

And emulators aren't allowed in 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: Packaging of PlayOnLinux

[Bastien Nocera]

- Original Message -
> Dne 14.10.2015 v 16:50 Bastien Nocera napsal(a):
> > If the application cannot work without downloading anything, or being
> > supplied
> > third-party (sometimes proprietary) applications, then it's closer to an
> > emulator than a front-end that's generally useful.
> 
> The guidelines speaks about *dependencies*.
> https://fedoraproject.org/wiki/Packaging:Guidelines#Packages_which_are_not_useful_without_external_bits
> 
> I think that the idea behind this wording was "runtime dependencies". To deny
> application which can not even run without
> those proprietary deps.
> PlayOnLinux is mainly for games, but you can run any Windows program using
> that. Even Gimp or Firefox (I could not
> remember program which does not have native linux version and is free).
> So it may not be useful for you, but it can be useful for somebody else.
> 
> For me PlayOnLinux is much closer to virt-manager.
> 
> > And emulators aren't allowed in Fedora.
> 
> What?
> You mean like Wine, all those terminal emulators, QEMU, atari++, hercules,
> fuse-emulator and lots of others?

The ones listed here:
https://fedoraproject.org/wiki/Licensing:SoftwareTypes?rd=Licensing/SoftwareTypes
-- 
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: Summary/Minutes from today's FESCo Meeting (2015-10-07)

[Bastien Nocera]

- Original Message -
> Bastien Nocera wrote:
> > 2 distributions add slightly different versions of the same functionality
> > -> incompatible
> 
> I said that carrying more feature patches makes it "more likely" that
> packages from other distros will work, not "100% certain" (which is
> obviously not possible when there are incompatible versions of the same
> patchset floating around).
> 
> > Application compiled on Fedora using the new features -> doesn't work on
> > other distribution
> 
> And that's not a problem for OUR users, only for those of the other
> distribution. So why would that be ours to worry about?

That's a problem for OUR users because when they use Fedora, they want to be
able to make a tarball of their software for their friend on Ubuntu to test.
Here, you're making Fedora a bad choice for developers that want to target
more than just Fedora.

> > Your advice would be making Fedora a _worse_ distribution for third-party
> > developers, and you equate those third-party developers to developers of
> > proprietary applications.
> 
> GCC supports __attribute__((deprecated("message"))) these days. So we can
> tag the added functions with something like:
> __attribute__((deprecated("nonstandard function added by a non-upstream
> patch to make FooApp work, use in other applications strongly
> discouraged")))
> 
> If the developers opt to use those functions anyway, then that's not our
> problem.

This isn't made to tag symbols that aren't upstream, and the end-user 
application
will just barf out with unresolved symbols when you try to run it, which is
far from useful.

> > Not all Free Software is easy to compile from source, not all Free
> > Software is packaged in Fedora. Forcing users to become packagers before
> > they can use a third-party software is detrimental to Fedora's success.
> 
> I don't really agree, at least not fully. I think packaging software
> properly is a much more effective way to spend our time than making third-
> party blobs work as is, especially WHEN those binaries are actually Free
> Software and can thus be packaged properly from source.

Should I send you emails every time a software I want to use isn't packaged?
Because that's what it sounds like you want me to do :)

> Sure, the USERS
> should not have to become packagers, but the existing packagers should not
> waste their time on compatibility with binary blobs, but spend it usefully
> on packaging Free Software from source.

I'll ask something, in earnest: have you ever written and shipped non-trivial 
software on Linux?

Because I don't think you would give those advices if you had.
-- 
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: Summary/Minutes from today's FESCo Meeting (2015-10-07)

[Bastien Nocera]

- Original Message -
> On 2015-10-13, Bastien Nocera <bnoc...@redhat.com> wrote:
> >> Bastien Nocera wrote:
> >> > 2 distributions add slightly different versions of the same
> >> > functionality
> >> > -> incompatible
> >> 
> >> I said that carrying more feature patches makes it "more likely" that
> >> packages from other distros will work, not "100% certain" (which is
> >> obviously not possible when there are incompatible versions of the same
> >> patchset floating around).
> >> 
> >> > Application compiled on Fedora using the new features -> doesn't work on
> >> > other distribution
> >> 
> >> And that's not a problem for OUR users, only for those of the other
> >> distribution. So why would that be ours to worry about?
> >
> > That's a problem for OUR users because when they use Fedora, they want to
> > be
> > able to make a tarball of their software for their friend on Ubuntu to
> > test.
> > Here, you're making Fedora a bad choice for developers that want to target
> > more than just Fedora.
> >
> If you exchange Fedora and Ubuntu, you will get the same valid
> statement. This is not about Fedora or Ubuntu. It's about you don't like
> diverse world where distributions differ.

I enjoy it when people tell me what I don't like.

> I have a good news for you:
> There are different operating sytems where executing foreign blobs is
> standard practice because there is exactly one distribution of the
> operating system.

We already did the "distributions aren't compatible" thing in the 90's.

If Ubuntu and Fedora binaries aren't compatible, which one do you think
is going to get used by developers that need to generate programs running
on Ubuntu?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct