Re: Firefox 126.0 with DBus service

[Martin Stransky]

On 5/17/24 11:37, Michael J Gruber wrote:

Martin Stransky venit, vidit, dixit 2024-05-17 11:30:01:

On 5/17/24 11:14, Michael J Gruber wrote:

Martin Stransky venit, vidit, dixit 2024-05-17 11:04:47:

On 5/17/24 10:47, Vitaly Zaitsev via devel wrote:

On 17/05/2024 10:38, Martin Stransky wrote:

Hm, does really KDE Plasma access Firefox profile and searches it for
anything? That's interesting. Can you point me to any info about it?


It looks like it copies Firefox's *.sqlite databases to
~/.cache/bookmarksrunner on every user login and then uses them:

$ ls ~/.cache/bookmarksrunner/ | grep firefox
bookmarkrunnerfirefoxdbfile.sqlite
bookmarkrunnerfirefoxfavdbfile.sqlite
KRunner-Favicons-firefox-default


I see. I don't think it's useful for gnome search as it uses live data
(also from recently visited URL) and also sorts results for popularity.
It should give you the same results as writing directly to Firefox URL bar.



This feature looks more and more confusing.

How do the search providers (be it Gnome's or Plasma's variant) decide
which Firefox Profile to scrape?


The searches are received from the first launched Firefox instance and
its profile. Due to Firefox remote service usually all your FF windows
use the same profile and there's usually only one profile per user.

So usually you'll get search results from the recent Firefox you're running.


I guess I'm unusual then ...

If you do use "-no-remote -P $Profile" to have instances with separate
profiles, you have to start the "search provider profile" first. Or
maybe Gonome search starts the default profile first anyways. There is
no apparent way to control this.

I mean, I would understand if the search uses the default profile, but
just any running instance? Strong dislike over here.

In any case, I think we should *not* sneak this in unannouced, but with
a clear information about wht it does and how turn it off.


You can enable/disable gnome search by 
browser.gnome-search-provider.enabled at about:config for your profile.


There isn't any 'default' profile, Firefox usually use only one.

Also Firefox Gnome search provider has been here for long time, see
https://mastransky.wordpress.com/2020/09/25/firefox-gnome-shell-search-provider/

--
Martin Stransky
Software Engineer / Red Hat, Inc
--
___
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: Firefox 126.0 with DBus service

[Martin Stransky]

On 5/17/24 11:14, Michael J Gruber wrote:

Martin Stransky venit, vidit, dixit 2024-05-17 11:04:47:

On 5/17/24 10:47, Vitaly Zaitsev via devel wrote:

On 17/05/2024 10:38, Martin Stransky wrote:

Hm, does really KDE Plasma access Firefox profile and searches it for
anything? That's interesting. Can you point me to any info about it?


It looks like it copies Firefox's *.sqlite databases to
~/.cache/bookmarksrunner on every user login and then uses them:

$ ls ~/.cache/bookmarksrunner/ | grep firefox
bookmarkrunnerfirefoxdbfile.sqlite
bookmarkrunnerfirefoxfavdbfile.sqlite
KRunner-Favicons-firefox-default


I see. I don't think it's useful for gnome search as it uses live data
(also from recently visited URL) and also sorts results for popularity.
It should give you the same results as writing directly to Firefox URL bar.



This feature looks more and more confusing.

How do the search providers (be it Gnome's or Plasma's variant) decide
which Firefox Profile to scrape?


The searches are received from the first launched Firefox instance and 
its profile. Due to Firefox remote service usually all your FF windows 
use the same profile and there's usually only one profile per user.


So usually you'll get search results from the recent Firefox you're running.

--
Martin Stransky
Software Engineer / Red Hat, Inc
--
___
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: Firefox 126.0 with DBus service

[Martin Stransky]

On 5/17/24 10:47, Vitaly Zaitsev via devel wrote:

On 17/05/2024 10:38, Martin Stransky wrote:
Hm, does really KDE Plasma access Firefox profile and searches it for 
anything? That's interesting. Can you point me to any info about it?


It looks like it copies Firefox's *.sqlite databases to 
~/.cache/bookmarksrunner on every user login and then uses them:


$ ls ~/.cache/bookmarksrunner/ | grep firefox
bookmarkrunnerfirefoxdbfile.sqlite
bookmarkrunnerfirefoxfavdbfile.sqlite
KRunner-Favicons-firefox-default


I see. I don't think it's useful for gnome search as it uses live data 
(also from recently visited URL) and also sorts results for popularity. 
It should give you the same results as writing directly to Firefox URL bar.


I see it takes 24064 bytes only as it's just a simple and small DBus 
service. Does it really take 1GB on your box?


Other people in the Bodhi update ticket have the same problem. Firefox 
appears to be unable to shut down properly and continues to run in full 
mode.


I don't see such reports. If you can reproduce, can you file a bug at 
https://bugzilla.mozilla.org/ and cc me there?


I expect Firefox fails to quit for some reason but as it's connected to 
DBus service (as it's launched from it) so you see it as a part of it. 
But I bet you'll get the same results (ff hang) without the service.


--
Martin Stransky
Software Engineer / Red Hat, Inc
--
___
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: Firefox 126.0 with DBus service

[Martin Stransky]

On 5/17/24 10:28, Vitaly Zaitsev via devel wrote:

On 17/05/2024 08:05, Martin Stransky wrote:
Gnome search service is provided by running Firefox application 
itself. It's because it searches and publishes results from recent 
live user profile.


Why can't GNOME Search engine just parse Firefox's *.sqlite databases 
like everyone else does (like KDE Plasma)? It's more simple and easy.


Hm, does really KDE Plasma access Firefox profile and searches it for 
anything? That's interesting. Can you point me to any info about it?


So if we have Firefox without Gnome search service / DBus service we'd 
need different .desktop file with 'DBusActivatable=false' for it (as 
AFAIK rpm doesn't allow to overwrite file owned by different package). 


W should start providing it as a separate desktop file, since Firefox is 
now always running in the background and consuming more than 1GB of RAM. 
User can't even easily terminate this process without disabling the 
service. If you SIGKILL, systemd will spawn it again. And the service 
can't be disabled/masked too because Firefox doesn't start.


I see it takes 24064 bytes only as it's just a simple and small DBus 
service. Does it really take 1GB on your box?


So it's a bit complicated situation here. I think it's clumsy to have 
firefox-gnome and firefox-non-gnome rpm with different desktop files 
but I don't see any other option (beside to remove gnome search or 
implement it as different app and broker the search results).


1. Provide a standard shortcut without DBusActivatable and with 
NotShowIn=gnome for all other DEs in the firefox package.
2. Create a separate package with gnome-search related files (including 
a .service file and a special shortcut with OnlyShowIn=gnome).

3. Install this package only if the gnome-shell is installed.



Will look at the NotShowIn keyword, Thanks.

--
Martin Stransky
Software Engineer / Red Hat, Inc
--
___
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: Firefox 126.0 with DBus service

[Martin Stransky]

On 5/15/24 12:55, Vitaly Zaitsev via devel wrote:

On 15/05/2024 10:52, Ian McInerney via devel wrote:
What if I don't use GNOME search? I don't use the GNOME desktop, so I 
don't want to have a random Firefox process running on my machine that 
is doing absolutely nothing and just hogging resources. Is this 
process only created when something tries to talk to it on the DBus 
socket, or is it always there listening?


Yes, it should be moved to a separate package and installed only if the 
gnome-shell is installed.


Let's me explain it a bit:

Gnome search service is provided by running Firefox application itself. 
It's because it searches and publishes results from recent live user 
profile.


Gnome search provider needs to be 'activable' DBus service so you need 
to set DBusActivatable=true at .desktop file and the application needs 
to provide org.freedesktop.Application.


Activable service also means (from my testing) that the application 
itself it not run by 'Exec' specified at .desktop file but by DBus 
service. If DBus service is missing it's run first and then 
org.freedesktop.Application is queried.


So if we have Firefox without Gnome search service / DBus service we'd 
need different .desktop file with 'DBusActivatable=false' for it (as 
AFAIK rpm doesn't allow to overwrite file owned by different package).


If there's DBusActivatable=true at .desktop file but the DBus service is 
missing the applications fails to launch.


So it's a bit complicated situation here. I think it's clumsy to have 
firefox-gnome and firefox-non-gnome rpm with different desktop files but 
I don't see any other option (beside to remove gnome search or implement 
it as different app and broker the search results).


--
Martin Stransky
Software Engineer / Red Hat, Inc
--
___
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

Firefox 126.0 with DBus service

[Martin Stransky]

Hello folks,

Firefox 126.0 for Fedora 40 
(https://bodhi.fedoraproject.org/updates/FEDORA-2024-eabe68b149) comes 
with enabled DBus service.


It means there's a dedicated firefox process which may be run by DBus as 
service (/usr/share/dbus-1/services/org.mozilla.firefox.service) and 
provides org.freedesktop.Application interface.


It's needed for GNOME Search provider which is enabled and working again 
in Firefox 126.0.


Regards,
Martin

--
Martin Stransky
Software Engineer / Red Hat, Inc
--
___
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: Specify koji build machine mem req via. spec file

[Martin Stransky]

On 10/5/23 08:03, Adam Williamson wrote:

On Wed, 2023-10-04 at 12:19 +0200, Kalev Lember wrote:

On Wed, Oct 4, 2023 at 11:44 AM Martin Stransky  wrote:


Hello guys,

Is there's a way how to set requested amount of ram for koji builders?

I'd like to use it as Firefox builds fail recently due low memory, like
https://bugzilla.redhat.com/show_bug.cgi?id=2241690



I looked at the first linked build log in the ticket and it looks like the
build failed in the debuginfo extraction step. In that log, find-debuginfo
is called with -j3, and it could be that it ran out of memory because it
was trying to do 3 debuginfo extractions in parallel. You could try to
stick something like this in the spec file to tune it down:

# Require 32 GB of RAM per CPU core for debuginfo processing
%global _find_debuginfo_opts %limit_build -m 32768


Thanks for the idea, Kalev. I went ahead and applied this, and builds
for F38 and F39 succeeded. Let's hope it really helps and this wasn't
just luck!


Thanks Adam!

--
Martin Stransky
Software Engineer / Red Hat, Inc
___
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

Specify koji build machine mem req via. spec file

[Martin Stransky]

Hello guys,

Is there's a way how to set requested amount of ram for koji builders?

I'd like to use it as Firefox builds fail recently due low memory, like 
https://bugzilla.redhat.com/show_bug.cgi?id=2241690


Thanks,
Martin

--
Martin Stransky
Software Engineer / Red Hat, Inc
___
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: firefox builds seem stuck on the farm - pls check

[Martin Stransky]

On 8/30/23 10:51, Peter Robinson wrote:

On Wed, Aug 30, 2023 at 9:48 AM Martin Stransky  wrote:


On 8/30/23 10:43, Peter Robinson wrote:

On Wed, Aug 30, 2023 at 9:42 AM Marius Schwarz  wrote:


Hi,

as mozilla released the updates notes for ff 117, there are a lot of
high impact security fixes for ff 117.

unfortunatly, the ff 117 builds on the farm seem stuck for 40+h ,
according to koji.

I informed  Martin, but can someone else take a look too, in case hes
not available?


Which build in particular, can you provide a link to the root koji task?


The builds are here:

https://koji.fedoraproject.org/koji/packageinfo?packageID=37


So you mean all 3?


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

Re: firefox builds seem stuck on the farm - pls check

[Martin Stransky]

On 8/30/23 10:43, Peter Robinson wrote:

On Wed, Aug 30, 2023 at 9:42 AM Marius Schwarz  wrote:


Hi,

as mozilla released the updates notes for ff 117, there are a lot of
high impact security fixes for ff 117.

unfortunatly, the ff 117 builds on the farm seem stuck for 40+h ,
according to koji.

I informed  Martin, but can someone else take a look too, in case hes
not available?


Which build in particular, can you provide a link to the root koji task?


The builds are here:

https://koji.fedoraproject.org/koji/packageinfo?packageID=37

Thanks.


___
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


--
Martin Stransky
Software Engineer / Red Hat, Inc
___
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: Installing ffmeg-free degrades firefox video support

[Martin Stransky]

On 6/10/22 11:44, Vitaly Zaitsev via devel wrote:

On 10/06/2022 05:08, Gary Buhrmaster wrote:

I admit I have not checked, but does ffmpeg-free include
the hardware GPU support for the various patented
codecs (letting the GPU vendor pay the license costs
for the decoder) and if not, would RH legal consider
adding that hardware driver support acceptable to
ffmpeg-free?


Hardware decoding in ffmpeg is nonfunctional with stripped build-in 
codecs parts.


That's not exactly correct, for instance internal ffmpeg AV1 decoder is 
VA-API only, i.e. accelerated and ffmpeg does not ship internal SW decoder.


OTOH I don't believe it's possible to use H.264 HW decoding without 
patented parts as the decoding involves buffers ordering/stream 
extraction and so on.


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

Re: Installing ffmeg-free degrades firefox video support

[Martin Stransky]

On 6/5/22 15:08, Michael Catanzaro wrote:
On Sat, Jun 4 2022 at 01:05:58 AM +0300, Otto Urpelainen  
wrote:

It seems clear that there is a bug somewhere, but I cannot decide,
where, hence this post to devel. Should Fedora's Firefox actually have
media.ffmpeg.enabled set to false by default, because Fedora's variant
of ffmpeg has this problem? Should upstream Firefox be smarted about
which decoder library it attempts to use? Or should ffmpeg-free package
do something to avoid this from happening. Any opinions are welcome!


Only the developers will be able to tell you for sure, but I would start 
with a Firefox bug report. That's the place where code changes are most 
likely to be required, and the Firefox developers can always punt the 
bug to ffmpeg if they think it is doing something wrong.


Our ffmpeg-free is supposed to support H264 via OpenH264.


From my understanding ffmpeg-free should work with Firefox regardless 
of actual codec name.


Firefox uses avcodec_find_decoder() to query supported formats and it 
uses AVCodecID. So as far as openh264 ffmpeg module claims support of 
AV_CODEC_ID_H264 it's supported (unless the decoder crashes later and 
it's disabled or so).


You can get exact info by running Firefox with

MOZ_LOG="PlatformDecoderModule:5"

env variable.

Firefox without ffmpeg-free package uses GMP interface to use OpenH264 
and you can find its status at about:plugins page.


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

Re: PSA: openQA failures in tests using Firefox

[Martin Stransky]

On 5/25/22 08:58, Adam Williamson wrote:

and what I think is some kind of odd regression in Firefox 100 which
makes typing into some text entry boxes in the Cockpit and FreeIPA web
UIs not work reliably (this affects realmd_join_cockpit and
upgrade_realmd_client).


It's a good idea to file a bug at https://bugzilla.redhat.com

The typing problem may be 
https://bugzilla.mozilla.org/show_bug.cgi?id=1771104 and I'll backport 
that to Fedora.


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

Re: When is Firefox on Wayland Going to be the Default On KDE

[Martin Stransky]

On 12/16/21 14:02, Jaroslav Prokop wrote:

Hi,

On 12/16/21 09:56, Martin Stransky wrote:

On 12/16/21 06:44, Reon Beon via devel wrote:
I don't want to run MOZ_ENABLE_WAYLAND=1 firefox from the command 
line forever.
I just edit the file at `/usr/bin/firefox` on every update. Not the most 
comfortable but at least

I don't have to go to terminal for running firefox.


It's default on Fedora 35, isn't it? Please file a bug at 
https://bugzilla.redhat.com if it doesn't work for you.


I'll file a ticket (if someone was not faster).

I am afraid it is not default on neither F35 or F36.
The lines for this feature seem to be commented out [0].
I have submitted PR for this some time back [1].

JFTR is just a bugzilla ticket the preferred workflow for these changes?


Hello,

yes, bugzilla ticket is the preferred workflow for all FF changes (I'm 
not getting mail notify from src.fedoraproject.org/rpms/firefox).


Martin


Thanks,
Jarek

[0] https://src.fedoraproject.org/rpms/firefox/blob/f35/f/firefox.sh.in#_77
[1] https://src.fedoraproject.org/rpms/firefox/pull-request/36#
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure



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

Re: When is Firefox on Wayland Going to be the Default On KDE

[Martin Stransky]

On 12/16/21 06:44, Reon Beon via devel wrote:

I don't want to run MOZ_ENABLE_WAYLAND=1 firefox from the command line forever.


It's default on Fedora 35, isn't it? Please file a bug at 
https://bugzilla.redhat.com if it doesn't work for you.


Thanks.

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

Re: Firefox Hardware acceleration & VA-API how-to

[Martin Stransky]

Hello,

https://bugzilla.mozilla.org/show_bug.cgi?id=1742229 states that 
NVIDIA's NVDecod can be used with VA-API.


No idea what it actually means but I'll try to uplift that to Firefox 95.

Martin

On 11/15/21 13:34, Fabio Valentini wrote:

On Fri, Nov 12, 2021 at 9:37 AM Martin Stransky  wrote:


Hi folks,

I was told that people were having trouble with Firefox/HW
acceleration/VA-API setup on Fedora so I put some info at wiki at:

https://fedoraproject.org/wiki/Firefox_Hardware_acceleration

Hope it helps.
Martin


I appreciate the effort to document ways to improve things. However:


Video decoding on NVIDIA
Please buy some real Linux hardware.


This doesn't really help at all. Is it supposed to be funny, or is it
just cynical resignation?

I mean, even if I *could* throw a couple hundred bucks out the window
to replace a perfectly working NVidia hardware, most places don't even
seem to have AMD graphics cards in stock right now. Does that just
mean "tough luck" for users like me?

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




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

Re: Firefox Hardware acceleration & VA-API how-to

[Martin Stransky]

On 11/15/21 18:28, Aleksei Bavshin wrote:

On 11/15/21 08:45, Martin Stransky wrote:

On 11/15/21 17:38, Aleksei Bavshin wrote:

On 11/12/21 00:37, Martin Stransky wrote:

Hi folks,

I was told that people were having trouble with Firefox/HW 
acceleration/VA-API setup on Fedora so I put some info at wiki at:


https://fedoraproject.org/wiki/Firefox_Hardware_acceleration

Hope it helps.
Martin


Intel section fails to mention that accelerated video decoding on the 
Iris XE (Gen12) GPUs requires intel-media-driver and won't work with 
older libva-intel-driver. So we're out of luck until the sandboxing 
issue is resolved and the fix is backported to Fedora Firefox builds.


As usually, please update the page.
Thanks.


Hm. I just reread the whole section again.
Martin, did you mean to use intel-media-driver (iHD_drv_video.so) 
instead of the libva-intel-hybrid-driver (hybrid_drv_video.so)? Because 
everything makes sense with that substitution and the sandbox bug only 
mentions iHD_drv_video.so.


Frankly I use only libva-intel-driver (i965_drv_video.so) for Intel UHD 
620/630 which I have available and other info I have from upstream 
bugzilla (https://bugzilla.mozilla.org/show_bug.cgi?id=1619585).


Martin

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

Re: Firefox Hardware acceleration & VA-API how-to

[Martin Stransky]

On 11/15/21 17:38, Aleksei Bavshin wrote:

On 11/12/21 00:37, Martin Stransky wrote:

Hi folks,

I was told that people were having trouble with Firefox/HW 
acceleration/VA-API setup on Fedora so I put some info at wiki at:


https://fedoraproject.org/wiki/Firefox_Hardware_acceleration

Hope it helps.
Martin


Intel section fails to mention that accelerated video decoding on the 
Iris XE (Gen12) GPUs requires intel-media-driver and won't work with 
older libva-intel-driver. So we're out of luck until the sandboxing 
issue is resolved and the fix is backported to Fedora Firefox builds.


As usually, please update the page.
Thanks.

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

Re: Firefox Hardware acceleration & VA-API how-to

[Martin Stransky]

On 11/15/21 16:06, Steve Grubb wrote:

On Monday, November 15, 2021 8:23:59 AM EST Dominik 'Rathann' Mierzejewski
wrote:

Well, nVidia refuses to support VA-API like Intel and AMD do and the
VA-API-to-VDPAU won't help because dmabuf support is still required.
So... tough luck:


I can confirm that nvidia acceleration works fine on Fedora:

# vainfo
libva info: VA-API version 1.13.0
libva info: Trying to open /usr/lib64/dri/nvidia_drv_video.so
libva info: Found init function __vaDriverInit_1_12
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.13 (libva 2.13.0)
vainfo: Driver version: Splitted-Desktop Systems VDPAU backend for VA-API -
0.7.4



# vdpauinfo
display: :1   screen: 0
API version: 1
Information string: NVIDIA VDPAU Driver Shared Library  495.44  Fri Oct 22
06:03:50 UTC 2021



I use the negativio repository only because I need the whole cuda stack
including cudnn.


Please update the 
https://fedoraproject.org/wiki/Firefox_Hardware_acceleration#Video_decoding_on_NVIDIA 
page. I don't have supported NVIDIA hardware so I can't test that.


Thanks.

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

Re: Firefox Hardware acceleration & VA-API how-to

[Martin Stransky]

On 11/15/21 13:34, Fabio Valentini wrote:

On Fri, Nov 12, 2021 at 9:37 AM Martin Stransky  wrote:


Hi folks,

I was told that people were having trouble with Firefox/HW
acceleration/VA-API setup on Fedora so I put some info at wiki at:

https://fedoraproject.org/wiki/Firefox_Hardware_acceleration

Hope it helps.
Martin


I appreciate the effort to document ways to improve things. However:


Video decoding on NVIDIA
Please buy some real Linux hardware.


This doesn't really help at all. Is it supposed to be funny, or is it
just cynical resignation?

I mean, even if I *could* throw a couple hundred bucks out the window
to replace a perfectly working NVidia hardware, most places don't even
seem to have AMD graphics cards in stock right now. Does that just
mean "tough luck" for users like me?


Please read it as "I'm too stupid for such task". I don't know how to 
setup/run VA-API on NVIDIA.


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

Re: Firefox Hardware acceleration & VA-API how-to

[Martin Stransky]

On 11/15/21 15:25, Peter Robinson wrote:

On Mon, Nov 15, 2021 at 2:20 PM Martin Stransky  wrote:


On 11/12/21 17:07, Scott Talbert wrote:

On Fri, 12 Nov 2021, Martin Stransky wrote:


Hi folks,

I was told that people were having trouble with Firefox/HW
acceleration/VA-API setup on Fedora so I put some info at wiki at:

https://fedoraproject.org/wiki/Firefox_Hardware_acceleration


Along these lines, I am experiencing a pretty big regression in video
performance with recent Firefox versions on Fedora.  It probably started
with FF 93, but got a little better with FF 94.  It is really noticeable
when using Google Meet.  I'm using Wayland on AMD GPU hardware.  Is this
at all related to this HW acceleration stuff?


Please file a bug at https://bugzilla.redhat.com/ for further
investigation and cc me there. I can name ten reasons why you see it.


It sounds quite a lot like this bug filed by mattdm:
https://bugzilla.redhat.com/show_bug.cgi?id=2016162


Please file your own, I can dupe that later.
Thanks.

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

Re: Firefox Hardware acceleration & VA-API how-to

[Martin Stransky]

On 11/12/21 17:07, Scott Talbert wrote:

On Fri, 12 Nov 2021, Martin Stransky wrote:


Hi folks,

I was told that people were having trouble with Firefox/HW 
acceleration/VA-API setup on Fedora so I put some info at wiki at:


https://fedoraproject.org/wiki/Firefox_Hardware_acceleration


Along these lines, I am experiencing a pretty big regression in video 
performance with recent Firefox versions on Fedora.  It probably started 
with FF 93, but got a little better with FF 94.  It is really noticeable 
when using Google Meet.  I'm using Wayland on AMD GPU hardware.  Is this 
at all related to this HW acceleration stuff?


Please file a bug at https://bugzilla.redhat.com/ for further 
investigation and cc me there. I can name ten reasons why you see it.



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

Re: Firefox Hardware acceleration & VA-API how-to

[Martin Stransky]

On 11/12/21 11:04, Nicolas Chauvet wrote:

Le ven. 12 nov. 2021 à 09:37, Martin Stransky  a écrit :


Hi folks,

I was told that people were having trouble with Firefox/HW
acceleration/VA-API setup on Fedora so I put some info at wiki at:

https://fedoraproject.org/wiki/Firefox_Hardware_acceleration


Thanks for the documentation Martin.

Few notes:
- Only ffmpeg, libva-intel-driver (and intel-media-driver for newer
hw) are provided via rpmfusion (in nonfree section for the latter),
the other components are in fedora
- We might have a special issue for f35 as the introduction of crocus
DRI driver broke the X11 DRI/VAAPI mapping.
(Fix pending: https://bodhi.fedoraproject.org/updates/FEDORA-2021-83cbfc7e32
- rhbz#2017059)


Thanks, feel free to update the page.

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

Firefox Hardware acceleration & VA-API how-to

[Martin Stransky]

Hi folks,

I was told that people were having trouble with Firefox/HW 
acceleration/VA-API setup on Fedora so I put some info at wiki at:


https://fedoraproject.org/wiki/Firefox_Hardware_acceleration

Hope it helps.
Martin

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

Re: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG, OPUS, SPEEX, ...) for Fedora

[Martin Stransky]

On 11/8/21 13:37, Dominik 'Rathann' Mierzejewski wrote:

On Monday, 08 November 2021 at 11:51, Andreas Schneider wrote:

On Monday, November 8, 2021 10:55:32 AM CET Dominik 'Rathann' Mierzejewski
wrote:

On Monday, 08 November 2021 at 10:12, Andreas Schneider wrote:


Hi,

there are several packages in the distribution which require FFMPEG
(libavformat, libavcodec, etc.), one of them being chromium. The package
could

  be created in a way that you can easily replace it with a version

from rpmfusion to get to the full encoder/decoder set including H264 etc.

This is working fine with openSUSE and packages from Packman.

https://build.opensuse.org/package/show/multimedia:libs/ffmpeg-4
https://pmbs.links2linux.org/package/show/Essentials/A_tw-ffmpeg

The Packman version always has a higher release version than the one in
the

  distribution.


I'm interested in this, as I try to package electron for Fedora. The big
problem is the included ffmpeg. With openSUSE I can just use the system
ffmpeg, with Fedora I have to do some source code voodoo which I really
would

  like to avoid.



Maintaining such package would require keeping watch for any new files
you'd need to include and going through legal review each time you do.


Did you take a look how they solved it at SUSE?


Actually, yes. We cannot do the same as we cannot distribute the full
upstream source.


You have list for encoder and decoders which are allowed to be built. So if a
new encoder or decoder would be added, it would just not be built. You will
just always end up with the same set of encoders/decoders with every update.


Sometimes new dependencies get added to existing decoders/encoders which
would require legal review.


Packman uses the exact same package as openSUSE and all it does it to enable
all encoders and decoders.

All packages requiring ffmpeg can just always be built against the system
version.

It should be less legal work, as you have to check just one package and not
several which might include it as third_party source code.


Chromium was checked by legal. I'm not aware of any other Fedora
packages bundling a subset of FFmpeg.


Firefox ships bundled ffmpeg with VP8/9 and maybe some other codecs.

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

Re: glibc 2.34 vs firefox in rawhide vs mass build rebuild

[Martin Stransky]

Hi Florian,

I tried to install rawhide in VM to fix FF build but rawhide failed to 
boot (live iso and update by dnf from 34).


I'll look at it again.

Martin

On 7/20/21 12:17 PM, Florian Weimer wrote:

Firefox in rawhide hasn't been built successfully since
firefox-89.0-1.fc35 (built 2021-06-02).  Unfortunately that version does
not treat the clone3 system call correctly in its sandbox, so it won't
work with future glibc 2.34 snapshots.

I fixed the issues to get firefox building again and attached a patch to
this bug:

   firefox: FTBFS with Python 3.10 in rawhide due to collections.abc change
   <https://bugzilla.redhat.com/show_bug.cgi?id=1983645>

(The patch also includes a glibc 2.34 compatibility change, separately
tracked as #1983696 for downstream convenience.)

The sandbox works again because the rawhide sources already had the
required changes, they simply had not been built yet.

What's the Fedora etiquette for fixing such long-standing FTBFS bugs?

I seem to recall that firefox used to be a special package, not to be
touched even by provenpackagers.

On the other hand, I would like to upload another glibc 2.34 snapshot
whose ABI is closer to what upstream is going to release on August 2nd.
With that snapshot, glibc will start using clone3 internally, and that's
incompatible with older firefox builds.

It's not critical to do this glibc import before the mass rebuild
because we definitely expect that the glibc 2.34 release will be
backwards-compatible with what we have in Fedora today.  But we will
miss some non-critical changes related to libresolv integration, so I'd
like to proceed with the import.

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




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

Re: Proposal to deprecated `fedpkg local`

[Martin Stransky]

Please no, I use that regularly.
Martin

On 1/27/21 5:17 PM, Vít Ondruch wrote:

Hi,

I wonder, what would be the sentiment if I proposed to deprecated the 
`fedpkg local` command. I don't think it should be used. Mock should be 
the preferred way. Would there be anybody really missing this 
functionality?



Vít



___
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




--
Martin Stransky
Software Engineer / Red Hat, Inc
___
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: BZ + Firefox: browser freezes when choosing close reason?

[Martin Stransky]

Hi Till,

please install firefox-x11 package and use Firefox X11 to test if it's 
caused by Wayland backend.


Also please file a new bug at #BZ so it can be diagnosed  more, i.e. 
test Mozilla binaries, disable extensions etc..


Thanks,
Martin

On 9/5/20 2:50 PM, Till Hofmann wrote:

Hi all,

I'm having a weird problem with Bugzilla: Whenever I want to close an
issue and I click on the reason menu (the one that shows NOTABUG,
NEXTRELEASE etc.), my browser freezes. Is anyone else seeing this issue?

I've tried to search for similar bug reports, but searching for
"bugzilla firefox bug status" obviously doesn't result in anything useful.

I've seen this for a couple of weeks now. This is on Fedora 32 with
Firefox 80.0.1.

Kind regards,
Till
___
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




--
Martin Stransky
Software Engineer / Red Hat, Inc
___
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

Firefox crashes at Rawhide

[Martin Stransky]

Just FYI, Firefox is recently crashing on Rawhide due to two independent 
issues as rawhide gets all builds automatically:


1) PGO mis-compilation/Firefox bug 
(https://bugzilla.redhat.com/show_bug.cgi?id=1779082). Please use 'npgo' 
builds from koji.


2) glibc update (https://bugzilla.mozilla.org/show_bug.cgi?id=1600574#c8)
You can disable e10s as a workaround (set MOZ_FORCE_DISABLE_E10S=1 or 
browser.tabs.remote.autostart at about:config)


--
Martin Stransky
Software Engineer / Red Hat, Inc
___
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

Low Memory Detection on Linux

[Martin Stransky]

Folks,

do you know if there's any reliable and widely available way how to 
measure memory usage on Linux by user space application (Firefox in this 
case) and detect low-memory state?


Thanks,
ma.

---

 Hi Vicky, all,
our low-memory detection machinery is rather old and incomplete. The
only platform that has proper low-memory detection is Android and it
works well there. On 32-bit Windows we had code that hooked certain
allocation functions and used the hook to "sample" the current memory
status. When I ported this code to 64-bit Windows I improved it by
removing the hooks and using a relatively slow polling loop instead.
This was far less expensive CPU-wise but it wasn't optimal either. I'm
currently working on improving it. On macOS and Linux we simply never
implemented this mechanism.

 Gabriele

___
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: Could not execute import_srpm

[Martin Stransky]

I see that too, filed it as 
https://pagure.io/fedora-infrastructure/issue/7704

ma

On 4/8/19 12:08 PM, Antonio Trande wrote:

Hi all.

I can't upload source archive of new package 'smoldyn'

$ fedpkg import ../../smoldyn-2.58-1.fc29.src.rpm
Uploading: /home/sagitter/rpmbuild/SRPMS/fedora-scm/smoldyn/smoldyn-2.58.tgz

100.0%
Could not execute import_srpm: Fail to upload files. Server returns
status 408



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


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

Re: firefox-wayland and URLs in other programs

[Martin Stransky]

On 4/3/19 10:32 AM, Hans de Goede wrote:

Hi Martin,

On 02-04-19 17:24, Martin Stransky wrote:

Please file a #BZ and let's investigate it there.


As mentioned further down the thread, changing the
default web application in gnome settings from firefox
to firefox-wayland fixes this.

Let me know if you still want me to file a bug for this.


Ahh, it's fine then.

I suspected https://bugzilla.mozilla.org/show_bug.cgi?id=1526243 but 
it's not your case then.


Thanks,
mz.


Regards,

Hans




Thanks.

On 4/2/19 5:05 PM, Hans de Goede wrote:

Hi All,

To help testing firefox on wayland I'm running it as my day to day 
browser

now, but when I click links (specifically in thunderbird) I get a dialog
saying "firefox is running but not responding". I believe this is caused
by thunderbird spawning /usr/bin/firefox to open the link instead of
firefox-wayland.

Any ideas how to fix this? I guess I could try to set 
MOZ_ENABLE_WAYLAND=1

in my environment everywhere, but AFAIK a Wayland gnome-shell will not
parse /etc/profile or any of the other scripts, so setting an env 
variable

so that it works for apps launched from gnome-shell is tricky...

Regards,

Hans







___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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: firefox-wayland and URLs in other programs

[Martin Stransky]

Please file a #BZ and let's investigate it there.
Thanks.

On 4/2/19 5:05 PM, Hans de Goede wrote:

Hi All,

To help testing firefox on wayland I'm running it as my day to day browser
now, but when I click links (specifically in thunderbird) I get a dialog
saying "firefox is running but not responding". I believe this is caused
by thunderbird spawning /usr/bin/firefox to open the link instead of
firefox-wayland.

Any ideas how to fix this? I guess I could try to set MOZ_ENABLE_WAYLAND=1
in my environment everywhere, but AFAIK a Wayland gnome-shell will not
parse /etc/profile or any of the other scripts, so setting an env variable
so that it works for apps launched from gnome-shell is tricky...

Regards,

Hans



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

Re: F30: Self-Contained Change proposal: Firefox Wayland By Default On Gnome

[Martin Stransky]

On 1/28/19 9:21 AM, Tom Hughes wrote:

On 25/01/2019 21:55, Tom Hughes wrote:

On 25/01/2019 21:24, Richard W.M. Jones wrote:

On Fri, Jan 25, 2019 at 09:43:32AM -0500, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/Firefox_Wayland_By_Default_On_Gnome 



== Summary ==
Firefox is going to run natively on Gnome Wayland session and won't
use XWayland/X11 Gtk+ backend. This change affects Gnome only and
won't be enabled for other Wayland compositors (KDE Plasma, Sway).


Does this mean it won't work on Xorg?


I was just going to ask whether this means there will now be
one binary that supports both and, if not, what this means for
people still forced into X fallback.


I think I've answered this myself - the current firefox-wayland
in F29 is just a script that sets GDK_BACKEND so there is already
only a single binary that does both. The only change is presumably
that it will prefer the wayland backend.


Yes, that's correct. Also I'm going use a slightly different solution 
[1] in next versions as GDK_BACKEND breaks third party programs launched 
from FF.



That said my testing of the F29 build had strangely variable
results - on one machine it was largely fine and on another it
was completely non-functional for reasons I haven't quite
managed to figure out yet.


Firefox 64 used on Fedora right now has limited Wayland support and 
misses some upstream patches. Please try mozilla nightly [2] with 
GDK_BACKEND=wayland set.


Also the upcoming Firefox 65 carries some new Wayland fixes.

Thanks,
ma.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1522780
[2] https://www.mozilla.org/en-US/firefox/channel/desktop/
___
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

[Martin Stransky]

On 9/7/18 9:36 AM, Vít Ondruch wrote:



Dne 7.9.2018 v 03:45 Owen Taylor napsal(a):

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.

If you maintain a graphical application, please try creating a Flatpak
of it. Your experience will vary - some applications are quite easy,
but if your application, for example:

  * Uses qt5-qtwebengine
  * Uses many KDE libraries
  * Uses many Perl or Python packages
  * Uses texlive

etc, then you may want to wait - we will eventually be creating shared
builds to make bundling these easier.



Ah, make bundling easier, right. Finally we can bundle!


Honestly, I fail to see how this can be promoted as good for Fedora. It
might be good for upstream but not for Fedora.


As far as I remember we try to use upstream packages with minimal local 
changes,
put all our changes to upstream...so what's the problem? Don't you 
follow upstream with

your package(s)?

ma.


Vít



Also, if your application has a system service, installs a polkit
policy, or otherwise is not self-contained, then it's not a good
candidate for a Flatpak.

Or you can pick one of 280+ applications that have been identfied as
easy to Flatpak:
   
    https://fedoraproject.org/wiki/Flatpak:Easy


and assist out the application package maintainer by creating a
Flatpak of that.

An introduction, draft tutorial and other documentation can be found at:

   https://fishsoup.net/misc/fedora-docs-flatpak/flatpak/

(The plan is to integrate this into docs.fedoraproject.org
. For now, the documentation source
is at: https://github.com/owtaylor/fedora-docs-flatpak)

For help, please ask on #fedora-workstation on Freenode, or mail
desk...@lists.fedoraproject.org .

Owen



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




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


___
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: Firefox with native Wayland backend at updates

[Martin Stransky]

On 06/01/2018 02:26 AM, mcatanz...@gnome.org wrote:
On Thu, May 31, 2018 at 5:39 PM, Kevin Kofler  
wrote:

We try hard to avoid messy menus with duplicate entries, and you get away
with adding an extra desktop entry to an application installed by 
default on

almost all Spins, for an experimental option?


Ugh yes, thanks for pointing this out, Kevin. I just assumed it had been 
done as a new desktop action in the existing desktop file (fairly hidden 
and harmless), but it's actually a new desktop file.


Unfortunately that desktop file action can't be selected at "Default 
Applications" which makes it fairly unusable.


Please remember that, if your package is installed by default in 
Workstation, the working group should approve any new visible desktop 
files, as the default desktop launchers are carefully-curated.


Okay and can I apply somewhere for that?

Martin, can you please fix this? I suggest adding a new desktop action 
to the existing desktop file instead, or else split the new Wayland 
desktop file into a subpackage that would need to be installed manually 
for the launcher to appear.


The desktop action is sub optimal as it can't be registered as a default 
application. If I create a separate rpm package it will contain just the 
desktop file and firefox-wayland shell launcher at /usr/bin.


ma.


Thanks,

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


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

Re: Firefox with native Wayland backend at updates

[Martin Stransky]

On 06/01/2018 02:26 AM, mcatanz...@gnome.org wrote:
On Thu, May 31, 2018 at 5:39 PM, Kevin Kofler  
wrote:

We try hard to avoid messy menus with duplicate entries, and you get away
with adding an extra desktop entry to an application installed by 
default on

almost all Spins, for an experimental option?


Ugh yes, thanks for pointing this out, Kevin. I just assumed it had been 
done as a new desktop action in the existing desktop file (fairly hidden 
and harmless), but it's actually a new desktop file.


Please remember that, if your package is installed by default in 
Workstation, the working group should approve any new visible desktop 
files, as the default desktop launchers are carefully-curated.


Martin, can you please fix this? I suggest adding a new desktop action 
to the existing desktop file instead, or else split the new Wayland 
desktop file into a subpackage that would need to be installed manually 
for the launcher to appear.


Thanks,


Okay, Thanks, I didn't know that. Anyway #BZ works better here.
ma.


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


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

Re: Firefox with native Wayland backend at updates

[Martin Stransky]

On 05/29/2018 08:48 AM, Zbigniew Jędrzejewski-Szmek wrote:

On Mon, May 28, 2018 at 10:56:27AM +0200, Martin Stransky wrote:

We have Firefox 60.0.1 with native Wayland backend at Fedora updates now:

https://bodhi.fedoraproject.org/updates/FEDORA-2018-c0674d672f
https://bodhi.fedoraproject.org/updates/FEDORA-2018-1f788d5c09
https://bodhi.fedoraproject.org/updates/FEDORA-2018-a62434cca8

The Wayland backend is available as an extra desktop entry. Please
report all wayland related issues to #BZ as usually. You should not
notice any changes/regressions at default X11 backend.


Hi,

first of all, thanks for doing this. Finally having wayland-native ff
would be great.

I installed this update, and for me, this is the first version that is
usable through wayland, significantly improved over previous releases.
My gut feeling is that it's even snappier than the X version.


Thanks.


Nevertheless, there are still various glitches:
- reordering tabs using the mouse results in the tab being duplicated,
   not moved,
- trying to open links from other programs does not work. After a delay
   I see "Firefox is already running, but ...".
And there were some other buglets which I can't recall right now.

Should I file bugs for those in bugzilla?


Yes please and cc me there.
ma.


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


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

Firefox with native Wayland backend at updates

[Martin Stransky]

We have Firefox 60.0.1 with native Wayland backend at Fedora updates now:

https://bodhi.fedoraproject.org/updates/FEDORA-2018-c0674d672f
https://bodhi.fedoraproject.org/updates/FEDORA-2018-1f788d5c09
https://bodhi.fedoraproject.org/updates/FEDORA-2018-a62434cca8

The Wayland backend is available as an extra desktop entry. Please 
report all wayland related issues to #BZ as usually. You should not 
notice any changes/regressions at default X11 backend.


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

Re: Security updates and batched pushes

[Martin Stransky]

On 01/08/2018 01:36 AM, Kevin Fenzi wrote:

On 01/07/2018 01:38 PM, Christian Dersch wrote:

Hi all,

within the whole Meltdown and Spectre story I realized that Koji pushes
even security updates to batched only, not directly to stable. In


The critera for bypassing batched is if the update is marked "urgent".


concrete case we have the firefox update [1], which already received 10
positive karma and many users complaining that it takes so long to get
it out as a stable update. Shouldn't we change that behaviour to get
such security updates out fast when maintainer relies on autopush when
karma threshold is reached?


If they are urgent sure... perhaps this should have been so marked?
Or the maintainer/submittor can request stable anytime after it has
enough karma.

Anyhow, I have pushed it to request stable and will do another f27 push
after the current ones finish to get it out today.


Seems to be my fault then, didn't know that the urgent/high state has 
the meaning there.


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

Re: Call for testing - Firefox 57

[Martin Stransky]

On 11/06/2017 11:50 AM, Vít Ondruch wrote:



Dne 12.10.2017 v 10:58 Martin Stransky napsal(a):

On 10/12/2017 10:52 AM, Richard W.M. Jones wrote:

On Thu, Oct 12, 2017 at 09:57:20AM +0200, Martin Stransky wrote:

- and disabled XUL extensions


For people who don't follow the internals of how Firefox works,
this means all extensions you have installed will stop working.

Apparently there is preference "extensions.legacy.enabled" which
should enable them again, but this does not work in Firefox 57 in
Fedora.  Can we please enable that?


The pref itself does nothing, it has to be patched. I'll try to enable
that for our test package.

ma.



Hi Martin,

Is there any prospect to have this enabled? I know you said "no
promise", so I just wondering, because out of 12 extensions I am using,
the F57 is supported just by 3 of them. Actually I could live without
these 3, but hard to live without the remaining 9.


Unfortunately now, I have no idea how to enable it.
ma.



Vít
___
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: Updates for Firefox 57 beta

[Martin Stransky]

On 10/16/2017 11:10 AM, James Hogarth wrote:

On 16 October 2017 at 10:00, Martin Stransky  wrote:


On 10/15/2017 03:58 PM, Gerald B. Cox wrote:


On Sun, Oct 15, 2017 at 3:45 AM, Alexander Ploumistos <
alex.ploumis...@gmail.com> wrote:

Hello,


Now that FESCo has ruled that "firefox 57beta is removed from f25/f26
updates-testing but stays in f27/rawhide", could we at least keep
getting new builds in koji for f25/f26? Judging by the feedback in
bodhi, the various threads here, rhbz and FESCo tickets, there is a
number of users who don't mind sticking with Firefox 57. Going back to
v56 would entail undoing a number of changes and dealing with possible
breakages, only to repeat the whole process in about a month. By the
way, beta 8 was released on Friday.



I don't see why not, but that is up to the maintainer.  The issue wasn't
the testing.  It was the use
of the updates-testing process for something that wasn't intended to be
pushed to stable.



Sure, out of box thinking is not expected here and Vogons could take
lessons from our council members ;-)

ma.

p.s.: please no offense here.

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




Side note... saying something that "could be" offensive and relies on a
particular sense of humor and then adding a P.S. of "no offense" is not
generally well looked upon ...


Yeah, sorry for that but I could not resist :)


Have you built it in a COPR instead yet?


No I don't build copr builds as that means extra work here.


If need be I don't mind tracking your commits in F27/master and maintaining
a temporary COPR for F25/F26 users.


Sure go ahead if you wish. You may need to fiddle with system nss/nspr 
dependencies until nspr-4.17 and nss 3.33 hit stable. You can take the 
package at 
https://src.fedoraproject.org/rpms/firefox/tree/stransky-firefox-57



Of course we'll need to get the message out on compatibility stuff when it
does go to F26/F25 repos eventually ... I'd suggest a Fedora Magazine
article highlighting the situation? We could even do one early highlighting
the COPR if you'd like some early F26 FF57 testing results?

>

I'd be happy to propose the article to the Fedora Magazine editorial board
and write it up if that's helpful.


That would be great.

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

Re: Updates for Firefox 57 beta

[Martin Stransky]

On 10/15/2017 03:58 PM, Gerald B. Cox wrote:

On Sun, Oct 15, 2017 at 3:45 AM, Alexander Ploumistos <
alex.ploumis...@gmail.com> wrote:


Hello,

Now that FESCo has ruled that "firefox 57beta is removed from f25/f26
updates-testing but stays in f27/rawhide", could we at least keep
getting new builds in koji for f25/f26? Judging by the feedback in
bodhi, the various threads here, rhbz and FESCo tickets, there is a
number of users who don't mind sticking with Firefox 57. Going back to
v56 would entail undoing a number of changes and dealing with possible
breakages, only to repeat the whole process in about a month. By the
way, beta 8 was released on Friday.



I don't see why not, but that is up to the maintainer.  The issue wasn't
the testing.  It was the use
of the updates-testing process for something that wasn't intended to be
pushed to stable.


Sure, out of box thinking is not expected here and Vogons could take 
lessons from our council members ;-)


ma.

p.s.: please no offense here.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Updates for Firefox 57 beta

[Martin Stransky]

On 10/15/2017 11:04 PM, Greg Evenden wrote:

Hello,

Now that FESCo has ruled that "firefox 57beta is removed from f25/f26
updates-testing but stays in f27/rawhide", could we at least keep
getting new builds in koji for f25/f26? Judging by the feedback in
bodhi, the various threads here, rhbz and FESCo tickets, there is a
number of users who don't mind sticking with Firefox 57. Going back to
v56 would entail undoing a number of changes and dealing with possible
breakages, only to repeat the whole process in about a month. By the
way, beta 8 was released on Friday.

Best regards

as i have asked Martin himself via Email, he wont be compiling every BETA 
Release, more than likely he'll do Beta 9, Beta 11 an Beta 13, an then the 
Release Candidate.


I don't have any plan here it merely depends on my availability. I'll 
try to build every Beta but no promises here.


ma.

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

Re: Why is Fx 57 in Updates Testing?

[Martin Stransky]

On 10/13/2017 01:29 PM, Peter Oliver wrote:

On Thu, 12 Oct 2017, Adam Williamson wrote:


it sounds like downgrading from 56 to 52
(the most recent ESR), aside from the epoch bump it'd require on our
side, is not straightforward (it seems there were profile changes
between 56 and 52).


Ouch.

Is now a good time to think about how we could try to avoid getting into 
a similar situation again in the future?


I see that Firefox ESR releases are supported for one year plus twelve 
weeks (https://www.mozilla.org/en-US/firefox/organizations/faq/).  For 
Fedora 27, would it be safer to include Firefox 57 and 58, but then 
stick with Firefox 59 ESR from March onwards?




Fedora can certainly ship ESR line but nobody wants to package/maintain it.

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

Re: Call for testing - Firefox 57

[Martin Stransky]

On 10/12/2017 11:16 AM, Alexander Ploumistos wrote:

On Thu, Oct 12, 2017 at 10:57 AM, Martin Stransky  wrote:

and also expect new versions there. Please give it a shot and report any issue 
to our [1] or Mozilla bugzilla [2].


Hi Martin,

Do you want feedback in bodhi as well?


Please use Red Hat bugzilla for Fedora specific issues (not present at 
official Mozilla FF57 build). Feedback in bodhi may be user for short notes.



And do you want to be notified about bugs filed upstream?

I noticed a rendering bug in Stylo, which I filed upstream (#1407690),
but it turns out to be another case of #1391341, which won't be fixed
in Firefox 57 and it's been marked as "fix-optional" for Firefox 58.
However, until this is fixed, fedora wiki (among other websites) will
look a bit messy to anyone using Firefox.


Yes, please CC me there.

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

Re: Call for testing - Firefox 57

[Martin Stransky]

On 10/12/2017 10:52 AM, Richard W.M. Jones wrote:

On Thu, Oct 12, 2017 at 09:57:20AM +0200, Martin Stransky wrote:

- and disabled XUL extensions


For people who don't follow the internals of how Firefox works,
this means all extensions you have installed will stop working.

Apparently there is preference "extensions.legacy.enabled" which
should enable them again, but this does not work in Firefox 57 in
Fedora.  Can we please enable that?


The pref itself does nothing, it has to be patched. I'll try to enable 
that for our test package.


ma.


(See also the "IMPORTANT" box on this page:
https://noscript.net/getit#devel)

Rich.


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

Re: Call for testing - Firefox 57

[Martin Stransky]

On 10/12/2017 09:57 AM, Martin Stransky wrote:

Hi folks,

let's have some fun with upcoming Firefox 57 a.k.a Firefox Quantum. This 
is a major Firefox update with key - pleasant and unpleasant - changes:


- fastest than ever with Rust, CSS Stylo, Sandbox...
- new "Photon" look
- and disabled XUL extensions


Looks like the legacy addons still can be enabled by 
extensions.legacy.enabled pref at about:config [1].


Unfortunately that does not work for the Beta/Release we have at updates 
now. I'll try to enable it there but no promise.


ma.

[1] https://wiki.mozilla.org/Add-ons/Firefox57

according to the disruptive nature of the update which is planned to 
land in *all* Fedoras at Nov 14 I decided to put the update to the 
testing as soon as possible, which mean we have Firefox 57 Beta packages 
at update-testing right now.


If you don't consume update-testing regularly you can install Firefox 
only by:


# dnf update --enablerepo=updates-testing firefox

and also expect new versions there. Please give it a shot and report any 
issue to our [1] or Mozilla bugzilla [2].


Thanks!
ma.

[1] https://bugzilla.redhat.com/
[2] https://bugzilla.mozilla.org/
___
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: Why is Fx 57 in Updates Testing?

[Martin Stransky]

On 10/12/2017 10:48 AM, Dominik 'Rathann' Mierzejewski wrote:

On Thursday, 12 October 2017 at 10:08, Richard W.M. Jones wrote:

In practical terms, FF57 disables all extensions.

I had forgotten how unusable the web has become without NoScript ...


Have you tested with the latest noscript? 5.1.1 claims to support Fx57
and is in updates-testing, too.


There's also "extensions.legacy.enabled" pref at about:config which can 
be flipped:


https://wiki.mozilla.org/Add-ons/Firefox57

ma.


Regards,
Dominik


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

Call for testing - Firefox 57

[Martin Stransky]

Hi folks,

let's have some fun with upcoming Firefox 57 a.k.a Firefox Quantum. This 
is a major Firefox update with key - pleasant and unpleasant - changes:


- fastest than ever with Rust, CSS Stylo, Sandbox...
- new "Photon" look
- and disabled XUL extensions

according to the disruptive nature of the update which is planned to 
land in *all* Fedoras at Nov 14 I decided to put the update to the 
testing as soon as possible, which mean we have Firefox 57 Beta packages 
at update-testing right now.


If you don't consume update-testing regularly you can install Firefox 
only by:


# dnf update --enablerepo=updates-testing firefox

and also expect new versions there. Please give it a shot and report any 
issue to our [1] or Mozilla bugzilla [2].


Thanks!
ma.

[1] https://bugzilla.redhat.com/
[2] https://bugzilla.mozilla.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Why is Fx 57 in Updates Testing?

[Martin Stransky]

On 10/11/2017 09:42 PM, Stephen John Smoogen wrote:

[]


It is something we forget a lot.. but is a reason why older
maintainers of XYZ software (Mozilla, X11, gcc, kernel, etc) would
make sure that a heads up email about a major version change goes out.

If you put out a heads up that "tomorrow I will be pushing Firefox
57BETA into updates-testing" you could have given people heads up and
would have also learned from someone that updates-testing is on for
everyone in the post-branch world. While in this case it probably
would not have affected your decision, in other cases it might have
made it clearer that you needed to do so after a different time. It
would have also queued in people to either skip updates or know why
their workflow died.


I agree with you here, I should post the head up. I agree I 
underestimated that and I'm sorry for it.


ma.


In either case, people would be better informed.

[1] 
https://opensource.com/business/10/3/five-questions-about-building-community-chris-blizzard-mozilla



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

Re: Why is Fx 57 in Updates Testing?

[Martin Stransky]

On 10/11/2017 07:26 PM, Gerald B. Cox wrote:

On Wed, Oct 11, 2017 at 10:04 AM, Heiko Adams  wrote:


Am Mittwoch, den 11.10.2017, 07:53 -0700 schrieb Gerald B. Cox:

By definition BETA software is never intended to be pushed to stable.  Fx
57 is BETA.  When the STABLE version is released, then it can go into
updates-testing.  Not before.  Again, that is the purpose of RAWHIDE.

Does this mean it's also not allowed to push packaged git-snapshots of a
software to updates-testing because they are unreleased and potentially
unstable?



As Adam mentioned apparently this isn't the "Official Policy".

My opinion however is common sense dictates that you don't put anything in
updates-testing unless you intend to push that software to stable.  If you
want people to test out experimental software, put it in RAWHIDE.  If it's
a git-snapshot and your INTENT is to push it to stable (for example, you're
fixing a bug) then that is OK for updates-testing.

In this instance, there is no intent to push Fx 57 BETA to stable.  That's
why it does't belong in update-testing.


I think there's a bit misunderstanding here. Some parts of the FF57 
update are going to be in stable as is (if the testing goes well). That 
includes the CSD patch [1].


The package may not be finished yet but the FF57 is almost done
and 99% of the code is going to be shipped to stable. This is not a 
completely different version, it may got some bugfixes but what you see 
is what you will almost get as stable update at Nov 14.


I'm sure the package is almost done so I don't take your argument about 
"completely different" package.


Due to the radical change in extension handlings and also needs to test 
the CSD patch [1] which I'd like to include in stable package I decided 
to put the FF57 to testing as early as possible. This is really a 
special case.


I believed that the update-testing repository is intended for testing 
and it's used by power users who can handle that, exclude the package 
from testing if needed, downgrade broken package and so on.


I'm surprised that people use updates-testing for stable/production 
machines, have problem with handling the update and act like newbies. If 
you can't handle that, don't use that. Fedora is really a bleeding edge 
so don't complain you get new software with new features - even as 
testing only :)


Also, I think your expectation about dramatic change of new extension 
availability for FF57 last month before the final release is false.


ma.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1283299
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Why is Fx 57 in Updates Testing?

[Martin Stransky]

On 10/11/2017 03:17 PM, Gerald B. Cox wrote:

Was this on purpose?  Fx 57 is BETA, and  I was under the impression that
BETA software was for RAWHIDE.

Yes, I understand there is an annotation NOT to push Fx 57 to stable - but
I thought that was the purpose of updates testing... software there is
intended to be tested and pushed to stable.

There are many extensions which aren't yet available for Fx 57 - and we're
effectively moving up the timetable by putting it in updates testing.


To be clear here, my intention was to enable early testing of new 
Firefox 57 release which also includes the CSD patch [1].


If there's no interest for such package I'll pull that out and you can 
expect regular FF57 update when the time comes. Please speak out at #BZ [2].


And no, I'm not going to create COPR builds for that - it does not 
contain required NSS/NSPR packages and building from git is broken.


ma.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1399611
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1500806
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Why is Fx 57 in Updates Testing?

[Martin Stransky]

On 10/11/2017 03:52 PM, Tomasz Torcz wrote:

On Wed, Oct 11, 2017 at 03:32:07PM +0200, Martin Stransky wrote:

On 10/11/2017 03:17 PM, Gerald B. Cox wrote:

Was this on purpose?  Fx 57 is BETA, and  I was under the impression that
BETA software was for RAWHIDE.


It's going to be stable in one month. Fx 57 release date is 2017-11-14.


Yes, I understand there is an annotation NOT to push Fx 57 to stable - but
I thought that was the purpose of updates testing... software there is
intended to be tested and pushed to stable.


I expect the testing repo is used by experienced users who wish to test
software planned for Fedora thus I don't see any problem here.


   It's *updates*-testing repo and software in it should not be 'planned',
but basically 'ready' for Fedora.
   If you want testing repo for experienced users, use COPR.


I don't see it that way. Is that your personal statement or is that 
written in any Fedora rules? I don't see that at Fedora page [1].


Also, the COPR suffers from some drawbacks - can't easily build from 
Fedora or other git repo [2].


ma.

[1] https://fedoraproject.org/wiki/QA:Updates_Testing
[2] I know it's supposed to work but the work flow is somehow 
complicated and uneasy and it's broken from time to time (actually right 
now).

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

Re: Why is Fx 57 in Updates Testing?

[Martin Stransky]

On 10/11/2017 03:46 PM, Mátyás Selmeci wrote:

On 10/11/17 08:32, Martin Stransky wrote:

On 10/11/2017 03:17 PM, Gerald B. Cox wrote:

Was this on purpose?  Fx 57 is BETA, and I was under the impression that
BETA software was for RAWHIDE.


It's going to be stable in one month. Fx 57 release date is 2017-11-14.

Yes, I understand there is an annotation NOT to push Fx 57 to stable 
- but

I thought that was the purpose of updates testing... software there is
intended to be tested and pushed to stable.


I expect the testing repo is used by experienced users who wish to 
test software planned for Fedora thus I don't see any problem here.


There are many extensions which aren't yet available for Fx 57 - and 
we're

effectively moving up the timetable by putting it in updates testing.


Do you think it's better when it suddenly appears on stable at 
2017-11-14? I do not.


ma.


Will an older version (either 56 or the ESR version, 52) also be 
included in Fedora 27 as a separate package?


Note: There's also IceCat browser available at Fedora:

https://apps.fedoraproject.org/packages/icecat

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

Re: Why is Fx 57 in Updates Testing?

[Martin Stransky]

On 10/11/2017 03:46 PM, Mátyás Selmeci wrote:

On 10/11/17 08:32, Martin Stransky wrote:

On 10/11/2017 03:17 PM, Gerald B. Cox wrote:

Was this on purpose?  Fx 57 is BETA, and I was under the impression that
BETA software was for RAWHIDE.


It's going to be stable in one month. Fx 57 release date is 2017-11-14.

Yes, I understand there is an annotation NOT to push Fx 57 to stable 
- but

I thought that was the purpose of updates testing... software there is
intended to be tested and pushed to stable.


I expect the testing repo is used by experienced users who wish to 
test software planned for Fedora thus I don't see any problem here.


There are many extensions which aren't yet available for Fx 57 - and 
we're

effectively moving up the timetable by putting it in updates testing.


Do you think it's better when it suddenly appears on stable at 
2017-11-14? I do not.


ma.


Will an older version (either 56 or the ESR version, 52) also be 
included in Fedora 27 as a separate package?


No, we (Red Hat Desktop team) will ship Firefox 57 only as well as 
Mozilla does. Of course anyone can create/maintain additional Firefox 
packages (ESR, Developer edition...) for Fedora as I mentioned many 
times before.


This is also reason why I created this update for testing so early.

ma.


-Mat
___
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: Why is Fx 57 in Updates Testing?

[Martin Stransky]

On 10/11/2017 03:17 PM, Gerald B. Cox wrote:

Was this on purpose?  Fx 57 is BETA, and  I was under the impression that
BETA software was for RAWHIDE.


It's going to be stable in one month. Fx 57 release date is 2017-11-14.


Yes, I understand there is an annotation NOT to push Fx 57 to stable - but
I thought that was the purpose of updates testing... software there is
intended to be tested and pushed to stable.


I expect the testing repo is used by experienced users who wish to test 
software planned for Fedora thus I don't see any problem here.



There are many extensions which aren't yet available for Fx 57 - and we're
effectively moving up the timetable by putting it in updates testing.


Do you think it's better when it suddenly appears on stable at 
2017-11-14? I do not.


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

Re: Call for testing - Firefox CSD/titlebar

[Martin Stransky]

Do you mind to file at BZ please?
Thanks,
ma.

On 09/16/2017 06:15 PM, Christian Dersch wrote:

I can confirm this behaviour @KDE Plasma and also i3 window manager.


On 09/16/2017 06:03 PM, Mattia Verga wrote:

On KDE the result is terrible.

I get a window inside another window: http://tinyurl.com/yd6ppat3
___
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


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

Call for testing - Firefox CSD/titlebar

[Martin Stransky]

Guys,

there's available [1] new Firefox package with emulated CSD rendering [2].

What does it mean for you? Firefox renders CSD decorations on its own 
then and you don't see the default gnome titlebar on top of the main 
window and you get a "Chromish" look. That should also work with Firefox 
light themes.


But you need to enable it explicitly at about:config. Set 
"widget.allow-client-side-decoration" to true and restart the browser.


Please report any issues to bugzilla.redhat.com and mentions it's the 
CSD version. I'm also interested on testing when 
"widget.allow-client-side-decoration" is false - to make sure it does 
not break anything.


Thanks!
ma.

[1]
Fedora 25: https://koji.fedoraproject.org/koji/buildinfo?buildID=970606
Fedora 26: https://koji.fedoraproject.org/koji/buildinfo?buildID=970604
Fedora 27: https://koji.fedoraproject.org/koji/buildinfo?buildID=970605

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1399611
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: firefox-55.0.2-2.fc26.x86_64 conflicts with pkgconfig(nspr) >= 4.16

[Martin Stransky]

On 08/24/2017 04:46 PM, Dridi Boukelmoune wrote:

Hello,

For some reason I fail to understand, a non-devel package is
conflicting with a devel package :-/

According to dnf it's the only explicit conflict for the package:

 $ dnf repoquery --conflicts firefox-55.0.2-2.fc26.x86_64
 pkgconfig(nspr) >= 4.16

Maybe someone confused Conflicts with BuildConflicts in the spec?


You're right, I confused the Conflicts with BuildConflicts (didn't 
actually know that there's BuildConflicts). See 
https://bugzilla.redhat.com/show_bug.cgi?id=1484345#c11


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

Retired package - xulrunner

[Martin Stransky]

Hello,

Xulrunner is no longer supported by upstream and contains known security 
bugs so we decided to retire it from master (will be still available for 
Fedora 26).


If any project needs that package it has to bundle it.

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

Re: Firefox 52.0.1: CVE-2017-5428

[Martin Stransky]

On 03/22/2017 01:22 AM, Bojan Smojver wrote:

Does anyone know whether the fix for this problem is already in F25
builds of FF or should a new build be prepared and pushed to fix this?

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



Sorry I overlooked this one. Builds are in koji now, firefox-52.0-6.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Firefox 52 - ALSA backend disabled

[Martin Stransky]

Hi,

ALSA backend is no longer available in official Fedora Firefox builds 
[1] since it has been deprecated by Mozilla and no longer maintained [2].


If you still want to use ALSA on Fedora builds, you just need to rebuild 
Firefox with such option. Just set "alsa_backend" to 1 and run the build.


ma.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1431371
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1247056#c180
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

flatpak app launch script

[Martin Stransky]

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.


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

Re: Important: NSS + Firefox + Thunderbird + Seamonkey + Icecat + Xulrunner

[Martin Stransky]

On 01/21/2017 04:33 PM, Christian Dersch wrote:



On 01/21/2017 04:15 PM, Kai Engert wrote:

I've disabled autokarma.

Thanks :)


The current Firefox 50.x will go unsupported on Tuesday, replaced by
Firefox 51.
Usually new important security fixes are contained in the new Firefox
update.

Unless we want to delay Firefox 51, this update must go out earlier,
or at the
same as Firefox 51.

Well, security fixes are one important point, possibly breaking things
in a stable release another one (I tend to think everything is fixed
now). Don't get me wrong, I don't want to slow down things, but NSS is a
widely used library, even in essential system components. I don't like
the idea of pushing it to stable without enough testing for some days
(lets say 4-5 days at minimum), especially as there were other issues
like non-working FreeIPA (which is fixed I guess?). First, the update
has to be pushed to testing (not happened right now) and has to arrive
@users, then they also should have some time to test. Some users like me
also test ealier by downloading the stuff from Koji, but in general that
is what we have updates-testing for. I'm a bit upset because I don't
like the idea of forcing "that has to happen until Monday" when there
might be side-effects like the one with FreeIPA. Firefox is not the only
thing in the world. If Firefox update is extremely urgent it should get
a bundled copy of nss until we have the update.


We should not break FreeIPA critically with that update (crashes on 
start or so) for sure. But don't expect rock solid experience from 
Fedora - there are RHEL/CentOS or other enterprise distros for that.


Fedora is focused mainly on new features which is the nss 3.28.1 update 
and minor bugs should be addressed later.


ma.



I suggest that we make a broad call for getting this update tested
widely by
Monday.

Good idea! It should contain some hints what and how to test.

Greetings,
Christian
___
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: Important: NSS + Firefox + Thunderbird + Seamonkey + Icecat + Xulrunner

[Martin Stransky]

On 01/20/2017 04:13 PM, Josh Boyer wrote:

On Fri, Jan 20, 2017 at 9:52 AM, Kai Engert  wrote:

Hello,

we are currently dealing with a tricky situation, that the NSS and Mozilla
package maintainers have been discussing, and I'd like to publish our plan.

The most recent NSS update, version 3.28.1, is required to ship to the Firefox
51 update planned for January 24.

Unfortunately, NSS 3.28.1 is incompatible with Mozilla applications version 50
and older.

If Mozilla 50 or older is used together with NSS 3.28 or newer, and the
application attempts to use HTTP v2, the connections to some servers may fail
(including connections to Google servers).

The fix is simple, it's possible to apply a small patch to the older Mozilla
applications, to make it compatible with NSS 3.28.1

The difficulty here is the timing, and it's a conflict between "don't break
applications in Fedora" and "ship new Firefox security update as soon as
possible".

If we start by shipping NSS 3.28.1 first, without yet having fixed the Mozilla
applications, then we allow Firefox 51 to be shipped, but we risk that the other
 applications aren't fixed in time, and that users might see regressions, caused
by the upgrade to NSS 3.28.1

Alternatively, if we wait until all affected Mozilla packages have been updated
to fixed versions, it might delay the January 24 Firefox 51 update.

After discussing this, we have a preference to avoid the breakage in Fedora, and
try to ship all required updates as soon as possible.

In order to avoid the breakage, we want to add "Conflicts:" statements to the
NSS 3.28.1 package, that makes it conflict with all known Mozilla packages that
don't contain the required fix yet.

The packages we have identified are:
- firefox
- thunderbird
- seamonkey
- xulrunner
- icecat

I see that for all the above packages, build attempts that include the fix are
already ongoing in koji, so there's hope that we might be able to resolve the
situation in time.

However, if ANY of the above build cannot be completed soon, or, if ANY of the
updates cannot move to the stable Fedora updates, it can block users from
upgrading to the Firefox 51 update on Jan 24.

Is that acceptable?

Do you agree that we make NSS conflict with any known incompatible packages
mentioned above, and thereby may inhibit a subset of Fedora users from upgrading
to Firefox 51 immediately?

If we can get all the above builds done quickly, and all of them pushed to
Fedora stable updates quickly, we're good.


Note that we have the remaining risk that we haven't identified all Mozilla
packages that might be affected. The relevant code isn't in NSS, but in
Mozilla's network code. That means, if the above list of packages isn't the
complete set of affected Mozilla based applications, other packages might still
experience the connectivity regression. But as soon as another package is
identified, it can rebuild to pick up the mentioned fix.


Is bundling the newer NSS release inside of firefox itself an option?
While it may not be the best long-term solution and we all know the
downsides of bundling, it is at least pragmatic in the short-term.
That would allow firefox to ship and time for the remaining packages
to be updated.  Once they're ready, the bundling in firefox could be
dropped and an update with all the packages could be done.


All builds are ready except TB on arm. I'm sure we make that in time.

Martin


josh
___
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: Firefox 49.0.2

[Martin Stransky]

On 10/27/2016 11:11 AM, Michael J Gruber wrote:

Martin Stransky venit, vidit, dixit 26.10.2016 11:42:

Thanks for pointing it here, I miss that minor update. Btw. a new #BZ at
bugzilla.redhat.com would work even better.

There are two security bugs marked as "High" which means "Moderate" in
Fedora terms. The big ones has "Critical" rating and there's none fixed
in this release.

AFAIK the main reason for 49.0.(1|2) releases were:

- the async rendering (mozbz#1307108)
- the d3d9 fallback (mozbz#1309330)

which are not so important for Fedora so we're going to ship the 49.0.2
release and ship 50.0.


From the context, I guess that first "ship" is a a "skip", right?


Yes, sorry for the misleading typo here :)
ma.


ma.

On 10/25/2016 09:23 PM, Bojan Smojver wrote:

Could someone with access please build this version of FF. Apparently,
it's a security release.

Thanks,


___
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


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

Re: Firefox 49.0.2

[Martin Stransky]

Thanks for pointing it here, I miss that minor update. Btw. a new #BZ at 
bugzilla.redhat.com would work even better.


There are two security bugs marked as "High" which means "Moderate" in 
Fedora terms. The big ones has "Critical" rating and there's none fixed 
in this release.


AFAIK the main reason for 49.0.(1|2) releases were:

- the async rendering (mozbz#1307108)
- the d3d9 fallback (mozbz#1309330)

which are not so important for Fedora so we're going to ship the 49.0.2 
release and ship 50.0.


ma.

On 10/25/2016 09:23 PM, Bojan Smojver wrote:

Could someone with access please build this version of FF. Apparently,
it's a security release.

Thanks,


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

Re: Firefox 48 v Electrolysis

[Martin Stransky]

I believe it's disabled by default, because upstream enables it 
specifically for safe instances (no/safe extensions and so) by mozilla 
installer which is disabled in Fedora.


You can enable it by your own in about:config, set 
browser.tabs.remote.autostart value to true.


Note: some extensions are incompatible with e10s, see
https://www.arewee10syet.com/ for details.

ma.

On 07/27/2016 03:27 AM, Bojan Smojver wrote:

Will Fedora build of FF 48 have this enabled or disabled? Or is this
something every user will have to decide upon through options etc.?

Thanks,


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

Re: Firefox on Wayland

[Martin Stransky]

On 06/28/2016 12:13 PM, Martin Stransky wrote:

On 06/28/2016 08:41 AM, Samuel Rakitničan wrote:

I've failed to launch the application properly under X.org and
Wayland using the launcher icon in GNOME shell.

But when I switched to Wayland, I executed the `firefox` command
from "Terminix" and it worked under XWayland with no regressions so
far (I didn't notice any other than links from other apps can't be
opened as it tries to open new instance of Firefox).


Having this issue as well. It crashes under wayland  when launched
from .desktop file for some reason, but not if started directly with
"firefox" from gnome-terminal.


It's https://bugzilla.redhat.com/show_bug.cgi?id=1349736


New fixed package is available at Copr.
ma.


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

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

Re: Firefox on Wayland

[Martin Stransky]

On 06/28/2016 08:41 AM, Samuel Rakitničan wrote:

I've failed to launch the application properly under X.org and
Wayland using the launcher icon in GNOME shell.

But when I switched to Wayland, I executed the `firefox` command
from "Terminix" and it worked under XWayland with no regressions so
far (I didn't notice any other than links from other apps can't be
opened as it tries to open new instance of Firefox).


Having this issue as well. It crashes under wayland  when launched
from .desktop file for some reason, but not if started directly with
"firefox" from gnome-terminal.


It's https://bugzilla.redhat.com/show_bug.cgi?id=1349736


-- 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: Firefox on Wayland

[Martin Stransky]

On 06/22/2016 01:35 PM, Igor Gnatenko wrote:

Very cool! Is it possible to put it into rawhide instead of using
COPR? I think it's better.


No, it breaks some basic Firefox features (remote connection, OMTC, GL 
acceleration) when runs under X. We need to address those first.


ma.


On Wed, Jun 22, 2016 at 1:12 PM, Martin Stransky  wrote:

Hi Folks,

Firefox with native Wayland support is available here:

https://copr.fedorainfracloud.org/coprs/stransky/firefox-wayland/
https://stransky.fedorapeople.org/firefox-47.0-6.wayland.fc25.src.rpm

It's an official Fedora Firefox package (47.0) + Wayland patch and it
replaces your distro FF. Runs under X unless you specify Wayland display -
see "Installation Instructions".

Please report any crashes/issues at bugzilla or ABRT and note the Wayland
version.

Thanks,
ma.
--
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

Firefox on Wayland

[Martin Stransky]

Hi Folks,

Firefox with native Wayland support is available here:

https://copr.fedorainfracloud.org/coprs/stransky/firefox-wayland/
https://stransky.fedorapeople.org/firefox-47.0-6.wayland.fc25.src.rpm

It's an official Fedora Firefox package (47.0) + Wayland patch and it 
replaces your distro FF. Runs under X unless you specify Wayland display 
- see "Installation Instructions".


Please report any crashes/issues at bugzilla or ABRT and note the 
Wayland version.


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

Re: Firefox - call for testing (Gtk3 effort)

[Martin Stransky]

On 02/03/2016 05:08 PM, Jonathan Wakely wrote:

On 03/02/16 11:58 +0100, Jakub Jelen wrote:

Don't know it it will help, but I see Firefox almost always crash when
I open new window and try to close it on F23. Sometimes earlier after
opening the windows, sometimes later after closing.


I've been seeing this recently when I close a tab that was running a
plugin. I've submitted crash reports to mozilla every time.


Great. Unfortunately the Mozilla upstream crashes does not contain 
backtraces of system libraries. Could you please try to catch those 
crashes in gdb and submit a bug at bugzilla.redhat.com?


Instructions are here:
http://fedoraproject.org/wiki/Debugging_guidelines_for_Mozilla_products#Application_crash

Or you can try to catch the crash by ABRT tool.

Thanks!
ma.


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

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

Re: Firefox - call for testing (Gtk3 effort)

[Martin Stransky]

On 02/03/2016 02:45 PM, Jakub Jelen wrote:

On 02/03/2016 10:53 AM, Martin Stransky wrote:

Also please remove Firefox from ABRT blacklist at:

/etc/abrt/abrt-action-save-package-data.conf

ma.

On 02/03/2016 10:43 AM, Martin Stransky wrote:

Folks,

we see many Gtk3 crashes in Firefox recently
(https://bugzilla.mozilla.org/show_bug.cgi?id=1239962) which comes from
Gtk3 system library.

If you's like to help here, please install latest FF updates from koji:

F23: https://bodhi.fedoraproject.org/updates/FEDORA-2016-8344bd0b61
F22: https://bodhi.fedoraproject.org/updates/FEDORA-2016-d73684df54

and also enable the ABRT tool. If Firefox crashes please submit the
crash stat to ABRT retrace server.

That would help up greatly to investigate root of this problem.



Installed the package from koji, debuginfo, set up the ABRT to handle
the crashes (GPG,Unpackaged,Blacklist), restarted abrtd, crashed firefox
few times, but I still don't see the crashes in abrt-cli. Is there some
another config I am missing?


Hm, no idea. Maybe ABRT maintainer may help here? (cc mhabr...@redhat.com)

ma.


Anyway I found that the Firefox was crashed by DNSSEC/TLSA Validator
plugin:

https://addons.mozilla.org/en-US/firefox/addon/dnssec-validator/

Disabled and works fine for me so far.




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

Re: Firefox - call for testing (Gtk3 effort)

[Martin Stransky]

I'd need the ABRT backtrace for that - don't see it on my F23 box.

On 02/03/2016 11:58 AM, Jakub Jelen wrote:

Don't know it it will help, but I see Firefox almost always crash when I
open new window and try to close it on F23. Sometimes earlier after
opening the windows, sometimes later after closing.

Jakub

On 02/03/2016 10:43 AM, Martin Stransky wrote:

Folks,

we see many Gtk3 crashes in Firefox recently
(https://bugzilla.mozilla.org/show_bug.cgi?id=1239962) which comes
from Gtk3 system library.

If you's like to help here, please install latest FF updates from koji:

F23: https://bodhi.fedoraproject.org/updates/FEDORA-2016-8344bd0b61
F22: https://bodhi.fedoraproject.org/updates/FEDORA-2016-d73684df54

and also enable the ABRT tool. If Firefox crashes please submit the
crash stat to ABRT retrace server.

That would help up greatly to investigate root of this problem.



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

Re: Firefox - call for testing (Gtk3 effort)

[Martin Stransky]

Also please remove Firefox from ABRT blacklist at:

/etc/abrt/abrt-action-save-package-data.conf

ma.

On 02/03/2016 10:43 AM, Martin Stransky wrote:

Folks,

we see many Gtk3 crashes in Firefox recently
(https://bugzilla.mozilla.org/show_bug.cgi?id=1239962) which comes from
Gtk3 system library.

If you's like to help here, please install latest FF updates from koji:

F23: https://bodhi.fedoraproject.org/updates/FEDORA-2016-8344bd0b61
F22: https://bodhi.fedoraproject.org/updates/FEDORA-2016-d73684df54

and also enable the ABRT tool. If Firefox crashes please submit the
crash stat to ABRT retrace server.

That would help up greatly to investigate root of this problem.

Thanks!
ma.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

Firefox - call for testing (Gtk3 effort)

[Martin Stransky]

Folks,

we see many Gtk3 crashes in Firefox recently 
(https://bugzilla.mozilla.org/show_bug.cgi?id=1239962) which comes from 
Gtk3 system library.


If you's like to help here, please install latest FF updates from koji:

F23: https://bodhi.fedoraproject.org/updates/FEDORA-2016-8344bd0b61
F22: https://bodhi.fedoraproject.org/updates/FEDORA-2016-d73684df54

and also enable the ABRT tool. If Firefox crashes please submit the 
crash stat to ABRT retrace server.


That would help up greatly to investigate root of this problem.

Thanks!
ma.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Xulrunner - intent to remove from Fedora 24

[Martin Stransky]

On 01/28/2016 08:52 PM, Samuel Sieb wrote:

On 01/27/2016 10:17 PM, Ben Rosser wrote:

It's been a while since I've used it, but chatzilla appears to still
under active development here: https://hg.mozilla.org/chatzilla/shortlog.


Yes, it is still somewhat active.  I am one of the upstream developers.


However, the package appears to be five releases behind now (0.9.92 was
released last August according to Wikipedia), and I don't know what
chatzilla upstream is planning to do as a result of Firefox
deprecating XUL.


Unfortunately, the packager has abandoned it and was not able to sponsor
me as a co-maintainer.  I have been maintaining an updated package for
myself, it's a very easy package to maintain.


Hi,

If you'd like to maintain the package please start the "unresponsive 
maintainer" process as described here:


https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers

and may be transferred to you.

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

Re: Xulrunner - intent to remove from Fedora 24

[Martin Stransky]

On 01/26/2016 06:48 PM, Stephen John Smoogen wrote:

On 26 January 2016 at 10:18, Yaakov Selkowitz  wrote:

On 2016-01-26 08:55, Richard Hughes wrote:


On 26 January 2016 at 12:51, Martin Stransky  wrote:


does anyone use the xulrunner package? (and gecko-devel actually).
Mozilla
does not maintain it any more and the XUL as technology is going to be
removed/deprecated. I'd like to remove the package from Fedora 24.



PackageKit has a npapi plugin that I'm guessing is soon going to stop
working. When that happens I guess we can drop this dep.



If xulrunner is removed, then something else will need to provide npapi-sdk
in order to continue to build browser plugins.


Will browser plugins still exist when these changes go through?


Will exist a browser which can run this plugin? Firefox is going to 
remove NPAPI plugin support (it's disabled by default now), Chrome 
already did so. Does Web (Epiphany) run NPAPI?


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

Xulrunner - intent to remove from Fedora 24

[Martin Stransky]

Hi,

does anyone use the xulrunner package? (and gecko-devel actually). 
Mozilla does not maintain it any more and the XUL as technology is going 
to be removed/deprecated. I'd like to remove the package from Fedora 24.


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

Retired - nspluginwrapper

[Martin Stransky]

Hi Folks,

I'm going to retire and remove nspluginwrapper from Fedora 24 and newer 
[1]. Firefox and Chromium does not use that any more.


Please speak up if you need that.

ma.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1289053
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Firefox addon signing

[Martin Stransky]

On 08/28/2015 11:34 AM, Alexander Ploumistos wrote:

On Fri, Aug 28, 2015 at 12:24 PM, Martin Stransky  wrote:

Thanks for the info. Actually is there any reason why Fedora packager would
need to modify the original extension?



That depends on the extension and its particulars. For example,
adblock plus has an extortion-like scheme in place and it allows
certain ads from certain companies that have paid them good money for
their service. This patch blocks those ads as well:
http://pkgs.fedoraproject.org/cgit/mozilla-adblockplus.git/tree/disable-safeads.patch
I didn't care to check if such a modification is permitted by their TOS.



Hm, is such change actually allowed by AddBlock authors? It looks a bit 
controversial to me. The extension signing may also help users to make 
sure they have the original extensions from their authors.


ma.
--
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: Firefox addon signing

[Martin Stransky]

On 08/28/2015 11:40 AM, Emmanuel Seyman wrote:

* Martin Stransky [28/08/2015 11:24] :


Thanks for the info. Actually is there any reason why Fedora packager would
need to modify the original extension?


If there is a security issue with an extension, the packager might well
want to distribute a patched version while waiting for a new release.


That's possible but the update process in Fedora is recently too slow. 
Even Firefox security updates sits in testing for week. I bet that 
official update from AMO (mozilla extension site) will be way faster 
that Fedora update.


ma.
--
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: Firefox addon signing

[Martin Stransky]

On 08/28/2015 11:00 AM, Alexander Ploumistos wrote:

On Fri, Aug 28, 2015 at 10:18 AM, Martin Stransky  wrote:

Can we ship addons which are already signed by Mozilla? Or does Fedora
packager modify them somehow?


It seems that even when the source is an xpi file, rpm treats it like
any other source package and its contents can be patched. I don't know
how that works, because signed addons contain a manifest file with md5
and sha1 checksums for all included files and I would expect that
modifications to any of them would cause the addon to get disabled.
Obviously we need input from a packager involved with the process.
Asking legal couldn't hurt either.


Thanks for the info. Actually is there any reason why Fedora packager 
would need to modify the original extension?


ma.


I think that these are all the addons that we ship and must be signed
(dictionaries, themes and plugins are exempt from the signing
process):
http://pkgs.fedoraproject.org/cgit/firefox-esteidpkcs11loader.git/
http://pkgs.fedoraproject.org/cgit/mozilla-adblockplus.git/
http://pkgs.fedoraproject.org/cgit/mozilla-https-everywhere.git/
http://pkgs.fedoraproject.org/cgit/mozilla-noscript.git/
http://pkgs.fedoraproject.org/cgit/mozilla-requestpolicy.git/
http://pkgs.fedoraproject.org/cgit/spice-xpi.git/



--
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: Firefox addon signing

[Martin Stransky]

On 08/27/2015 04:40 PM, Alexander Ploumistos wrote:

Aren't the addons that we ship in fedora a bunch of text files zipped
in an xpi archive? It is kind of awkward to send them back and forth,
but if there are no other binaries, does it go against a particular
policy?

Or we could decide that we trust Mozilla's code review process and
drop packaging addons altogether, as was suggested. At least the users
will receive updates faster.


Can we ship addons which are already signed by Mozilla? Or does Fedora 
packager modify them somehow?


ma.
--
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: Firefox testing - offscreen surfaces and OMTC

[Martin Stransky]

On 08/25/2015 12:09 PM, Kamil Paral wrote:

I'm seeing flickering (e.g. with arstechnica) on

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] RV620/M82 [Mobility Radeon HD 3450/3470]

with native drivers (F22).



I have seen heavy flickering on mapy.cz (online maps) when zooming.
The longer I used the browser, the more it seemed to flicker. Radeon
R9 270, radeonsi driver, F22.



Thanks for testing! Can you please also test latest nightly build from
https://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-central/firefox-43.0a1.en-US.linux-x86_64.tar.bz2 
?


Can you also update https://bugzilla.redhat.com/show_bug.cgi?id=1255917
with your findings?

Thanks,
ma.
--
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: Firefox testing - offscreen surfaces and OMTC

[Martin Stransky]

On 08/24/2015 10:41 AM, drago01 wrote:

On Mon, Aug 24, 2015 at 10:18 AM, Martin Stransky  wrote:

On 08/24/2015 09:43 AM, drago01 wrote:


On Mon, Aug 24, 2015 at 8:54 AM, Martin Stransky 
wrote:


On 08/21/2015 08:28 PM, Thomas Daede wrote:



I've been running nightly with this enabled for quite a while on Intel
and it's been fine.

Note that OMTC is required for e10s.




If you mean OMTC by "this" then you're right - it works fine on nightly
because nightly is built with in-tree cairo. Fedora it built with system
cairo which causes crashes with OMTC enabled. First build which supports
in-tree cairo & Gtk3 is FF41.



Why? What's the difference between the in-tree and the system cairo?
Ist it newer? Older? Patched? Or just built with a different
configuration?



in-tree cairo is a cairo library intergated in firefox tree, patched for
mozilla needs and used for internal rendering. system cairo is a cairo
library shipped in Fedora and used by gtk3 to draw.


I know what system and in-tree means .. the question was whether
mozilla patched the in-tree version or if it is just a different
version than the system cairo.
Your comment implies the former.


AFAIK Mozilla cairo is a snapshot from 2010-01-21 + mozilla fixes.
ma.
--
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: Firefox testing - offscreen surfaces and OMTC

[Martin Stransky]

On 08/24/2015 09:43 AM, drago01 wrote:

On Mon, Aug 24, 2015 at 8:54 AM, Martin Stransky  wrote:

On 08/21/2015 08:28 PM, Thomas Daede wrote:


I've been running nightly with this enabled for quite a while on Intel
and it's been fine.

Note that OMTC is required for e10s.



If you mean OMTC by "this" then you're right - it works fine on nightly
because nightly is built with in-tree cairo. Fedora it built with system
cairo which causes crashes with OMTC enabled. First build which supports
in-tree cairo & Gtk3 is FF41.


Why? What's the difference between the in-tree and the system cairo?
Ist it newer? Older? Patched? Or just built with a different
configuration?


in-tree cairo is a cairo library intergated in firefox tree, patched for 
mozilla needs and used for internal rendering. system cairo is a cairo 
library shipped in Fedora and used by gtk3 to draw.


ma.


--
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: Firefox testing - offscreen surfaces and OMTC

[Martin Stransky]

On 08/21/2015 08:28 PM, Thomas Daede wrote:

I've been running nightly with this enabled for quite a while on Intel
and it's been fine.

Note that OMTC is required for e10s.


If you mean OMTC by "this" then you're right - it works fine on nightly 
because nightly is built with in-tree cairo. Fedora it built with system 
cairo which causes crashes with OMTC enabled. First build which supports 
in-tree cairo & Gtk3 is FF41.



The layer acceleration pref is a totally different thing and will stay
off for the near future. It's affected by a bug in libxcb which has been
patched but not made it to release yet:
https://bugs.freedesktop.org/show_bug.cgi?id=84252


What do you mean here by "acceleration"? The offscreen surfaces 
referenced in this post are CPU rendering.


ma.


On 08/21/2015 01:33 AM, Martin Stransky wrote:

Folks,

I'd use some testing for new Firefox feature - offscreen surfaces [1].
It may also fix crashes when OMTC is enabled [2]. Browser should be a
bit faster with those features on.

How to test?

- Install Firefox 40 on Fedora 22,23,Rawhide (you'd need Gtk3 build)
- go to about:config, click to any key and add a new one, boolean type.
The new key name is "layers.use-image-offscreen-surfaces" and set it to
true.
- enable "layers.offmainthreadcomposition.enabled" which may be disabled
now.
- restart your browser.

And you're set now. Please report any oddity (different than the usual
ones :)) at #BZ.

Thanks!
ma.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1015218
[2] Off Main Thread Composition - layout rendering in separate thread.
New feature in Firefox 40.


--
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: Firefox testing - offscreen surfaces and OMTC

[Martin Stransky]

On 08/21/2015 03:34 PM, Alexander Ploumistos wrote:

On Fri, Aug 21, 2015 at 4:24 PM, Martin Stransky  wrote:

I see the same flickering on NVIDIA hardware. Intel seems to be fine.


Which model? Is it using one of the older driver series?



It's GeForce GTX 750 with nvidia binary drivers.
ma.
--
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: Firefox testing - offscreen surfaces and OMTC

[Martin Stransky]

I see the same flickering on NVIDIA hardware. Intel seems to be fine.

On 08/21/2015 03:06 PM, Alexander Ploumistos wrote:

On Fri, Aug 21, 2015 at 11:33 AM, Martin Stransky  wrote:

- Install Firefox 40 on Fedora 22,23,Rawhide (you'd need Gtk3 build)
- go to about:config, click to any key and add a new one, boolean type. The
new key name is "layers.use-image-offscreen-surfaces" and set it to true.
- enable "layers.offmainthreadcomposition.enabled" which may be disabled
now.


What about "layers.acceleration.force-enabled"?


And you're set now. Please report any oddity (different than the usual ones
:)) at #BZ.


On my desktop (f22), with a GeForce 9800 GT and the 340.76 driver from
nVidia I am getting a lot of flickering when I scroll through some
pages (e.g. MDN, Ars Techinca, gmail) especially when they contain
fixed or sticky elements or elements whose background image is
repeated along the x and y axes. If you can get your hands on similar
hardware, scroll through this:
https://developer.mozilla.org/en-US/docs/Web/CSS/position

On a recent laptop (f22), with nVidia and Intel dual graphics, there
is no such problem on either adapter.

I have been unable to reproduce the crashes we were investigating so
far, so perhaps enabling "layers.use-image-offscreen-surfaces" could
be a solution (and I should get a newer graphics card - anyone cares
to get me a late birthday present?).


This is the graphics information provided by firefox for the desktop:

Adapter DescriptionNVIDIA Corporation -- GeForce 9800 GT/PCIe/SSE2
Asynchronous Pan/Zoomnone
Device IDGeForce 9800 GT/PCIe/SSE2
Driver Version3.3.0 NVIDIA 340.76
GPU Accelerated Windows0/1 Basic (OMTC)
Supports Hardware H264 Decodingfalse
Vendor IDNVIDIA Corporation
WebGL RendererNVIDIA Corporation -- GeForce 9800 GT/PCIe/SSE2
windowLayerManagerRemotetrue
AzureCanvasBackendcairo
AzureContentBackendcairo
AzureFallbackCanvasBackendnone
AzureSkiaAccelerated0


and for the laptop:

Adapter DescriptionNVIDIA Corporation -- GeForce GTX 860M/PCIe/SSE2
Asynchronous Pan/Zoomnone
Device IDGeForce GTX 860M/PCIe/SSE2
Driver Version4.5.0 NVIDIA 352.21
GPU Accelerated Windows0/1 Basic (OMTC)
Supports Hardware H264 Decodingfalse
Vendor IDNVIDIA Corporation
WebGL RendererNVIDIA Corporation -- GeForce GTX 860M/PCIe/SSE2
windowLayerManagerRemotetrue
AzureCanvasBackendcairo
AzureContentBackendcairo
AzureFallbackCanvasBackendnone
AzureSkiaAccelerated0


Adapter DescriptionIntel Open Source Technology Center -- Mesa DRI
Intel(R) Haswell Mobile
Asynchronous Pan/Zoomnone
Device IDMesa DRI Intel(R) Haswell Mobile
Driver Version3.0 Mesa 10.6.3 (git-ccef890)
GPU Accelerated Windows0/1 Basic (OMTC)
Supports Hardware H264 Decodingfalse
Vendor IDIntel Open Source Technology Center
WebGL RendererIntel Open Source Technology Center -- Mesa DRI
Intel(R) Haswell Mobile
windowLayerManagerRemotetrue
AzureCanvasBackendcairo
AzureContentBackendcairo
AzureFallbackCanvasBackendnone
AzureSkiaAccelerated0



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

Firefox testing - offscreen surfaces and OMTC

[Martin Stransky]

Folks,

I'd use some testing for new Firefox feature - offscreen surfaces [1]. 
It may also fix crashes when OMTC is enabled [2]. Browser should be a 
bit faster with those features on.


How to test?

- Install Firefox 40 on Fedora 22,23,Rawhide (you'd need Gtk3 build)
- go to about:config, click to any key and add a new one, boolean type. 
The new key name is "layers.use-image-offscreen-surfaces" and set it to 
true.
- enable "layers.offmainthreadcomposition.enabled" which may be disabled 
now.

- restart your browser.

And you're set now. Please report any oddity (different than the usual 
ones :)) at #BZ.


Thanks!
ma.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1015218
[2] Off Main Thread Composition - layout rendering in separate thread. 
New feature in Firefox 40.

--
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: Rapid release for security updates

[Martin Stransky]

On 05/19/2015 11:12 AM, drago01 wrote:

On Tue, May 19, 2015 at 10:38 AM, Martin Stransky  wrote:

Hi guys,

is there any mechanism how to speed up release of critical security fixes by
Fedora update system?

For instance Firefox packages are released *week* after official Mozilla
release which is really bad.

Any idea here?


Why does it take so long? Most firefox uipdates get enough karma
before they end up in testing.


I gess there's 2 day delay (one for testing push and one for stable 
push). It also take time to get karma for Fedora 20...



In that case they should be picked up by the next push (which is still
a manual process afaik; so no idea how often it happens).



--
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: Rapid release for security updates

[Martin Stransky]

On 05/19/2015 03:17 PM, Michael Cronenworth wrote:

On 05/19/2015 04:12 AM, drago01 wrote:

Why does it take so long? Most firefox uipdates get enough karma
before they end up in testing.
In that case they should be picked up by the next push (which is still
a manual process afaik; so no idea how often it happens).


Firefox 38.0 entered and exited bodhi in about 29 hours. That's pretty
good.


Firefox 38.0, Fedora 20, security update. Submitted 2015-05-13, not yet 
stable (only submitted for stable now, have not hit the repository).



Firefox 38.0.1, marked as "bugfix" and not "security", has only been in
bodhi for 24 hours.


That's F20/F21 case, not Fedora 20.


@OP, If you need more eyes on updates you're free to post to this list
or the test list.


Thanks, but is there anything better? The F20 updates are usually ignored...

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

Rapid release for security updates

[Martin Stransky]

Hi guys,

is there any mechanism how to speed up release of critical security 
fixes by Fedora update system?


For instance Firefox packages are released *week* after official Mozilla 
release which is really bad.


Any idea here?

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

FYI: Firefox - No more binary components in extensions

[Martin Stransky]

 Forwarded Message 
Subject: No more binary components in extensions
Date: Mon, 4 May 2015 11:03:12 -0400
From: Benjamin Smedberg 
Reply-To: dev-extensi...@lists.mozilla.org
To: dev-platform , Firefox Dev 
, dev-extensi...@lists.mozilla.org


(Followup questions or comments to mozilla.dev.extensions only, please.)

With the landing of bug 1159737, I have removed support for binary XPCOM
components in extensions. This is planned to ride the Firefox 40 train.

This change is necessary because we no longer expose or intend to expose
a binary-stable API to XPCOM. Most addons have already moved away from
binary XPCOM components, but those that haven't are a source of
instability around Firefox releases.

Extension authors that need to use native binaries are encouraged to do
so using the addon SDK "system/child_process" pipe mechanism:
https://developer.mozilla.org/en-US/Add-ons/SDK/Low-Level_APIs/system_child_process

If this is not sufficient, JS-ctypes may be an alternative mechanism to
use shared libraries, but this API is much more fragile and it's easy to
write unsafe code.

I will be updating MDN documentation and removing or archiving old
documentation about binary XPCOM components in the next few weeks.

--BDS

___
dev-platform mailing list
dev-platf...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform



--
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: Flash plugin 0-day vulnerability in the wild

[Martin Stransky]

On 01/26/2015 02:03 PM, drago01 wrote:

On Mon, Jan 26, 2015 at 2:01 PM, Ahmad Samir  wrote:

On 26 January 2015 at 14:55, Martin Stransky  wrote:



Where have you got that? Official Adobe site [1] says the latest is
11.2.202.438 and flash download page [2] gives me the same. I see the Ubuntu
update with .440 package but what's that?

ma.

[1] http://www.adobe.com/software/flash/about/
[2] https://get.adobe.com/flashplayer/


flash-plugin-11.2.202.440 is available in the yum repo hosted by
Adobe. But on[1] it doesn't say anything about the issue being fixed
for Linux.


Sure it does "Adobe Flash Player 11.2.202.438 and earlier versions for
Linux" ... 440 > 438 ...



There's no official confirmation of the fix of the CVE-2015-0311 in 440 
yet, you can only assume that.


ma.

--
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: Flash plugin 0-day vulnerability in the wild

[Martin Stransky]

On 01/26/2015 02:12 PM, Ahmad Samir wrote:

On 26 January 2015 at 15:03, drago01  wrote:

On Mon, Jan 26, 2015 at 2:01 PM, Ahmad Samir  wrote:

On 26 January 2015 at 14:55, Martin Stransky  wrote:



Where have you got that? Official Adobe site [1] says the latest is
11.2.202.438 and flash download page [2] gives me the same. I see the Ubuntu
update with .440 package but what's that?

ma.

[1] http://www.adobe.com/software/flash/about/
[2] https://get.adobe.com/flashplayer/


flash-plugin-11.2.202.440 is available in the yum repo hosted by
Adobe. But on[1] it doesn't say anything about the issue being fixed
for Linux.


Sure it does "Adobe Flash Player 11.2.202.438 and earlier versions for
Linux" ... 440 > 438 ...

 From https://helpx.adobe.com/security/products/flash-player/apsa15-01.html:

"UPDATE (January 24): Users who have enabled auto-update for the Flash
Player desktop runtime will be receiving version 16.0.0.296 beginning
on January 24. This version includes a fix for CVE-2015-0311"

I was thinking of something along those lines for the Linux version too.



Firefox does not use the 16.X line - that's the Pepper API plugin which 
runs with Chrome only.


ma.
--
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: Flash plugin 0-day vulnerability in the wild

[Martin Stransky]

On 01/26/2015 01:48 PM, drago01 wrote:

On Mon, Jan 26, 2015 at 1:40 PM, Martin Stransky  wrote:

On 01/23/2015 10:51 AM, Martin Stransky wrote:


Folk,

There's a live 0-day flash vulnerability which is not fixed yet [1][2].
If you use flash plugin I recommend you to enable the click-to-play mode
for it.

There's also a Fedora Firefox update with such change [3].

ma.

[1]

https://isc.sans.edu/diary/Flash+0-Day+Exploit+Used+by+Angler+Exploit+Kit/19213

[2]

http://malware.dontneedcoffee.com/2015/01/unpatched-vulnerability-0day-in-flash.html

[3] https://bugzilla.redhat.com/show_bug.cgi?id=1185241



This vulnerability has got CVE-2015-0311 name [1]. Thx to drago01 to point
that out. Unfortunately it's still unfixed by Adobe and latest flash for
Linux/Firefox (11.2.202.438) is still vulnerable.


The latest one is 11.2.202.440 ... which is supposed to have the fix.


Where have you got that? Official Adobe site [1] says the latest is 
11.2.202.438 and flash download page [2] gives me the same. I see the 
Ubuntu update with .440 package but what's that?


ma.

[1] http://www.adobe.com/software/flash/about/
[2] https://get.adobe.com/flashplayer/

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