Re: Orphaning the cura-lulzbot package set

[Thomas Daede]

On 4/12/21 09:29, Miro Hrončok wrote:
P.S. I opened an upstream pull request to add support for the Lulzbot 
TAZ Pro and the Mini 2 in the main Cura codebase (still actively 
maintained). I would highly recommend that anyone considering reviving 
these packages devote their efforts in that direction instead.


Hey spot,
The packages are retired on rawhide now.

Should cura obsolete cura-lulzbot?



Upstream cura has its own config directory and is much newer, so I don't 
think that helps - it's essentially a different program.


I configured cura to work with my printer by setting up my printer as 
custom and copying the start/end gcode. As a bonus, the slicer is much 
newer and improved, so I don't think I'll miss cura-lulzbot. FAME 3D has 
actually opened a PR to cura now as well: 
https://github.com/Ultimaker/Cura/pull/10232


I did try to update lulzbot-marlin-firmware, but a) Lulzbot's forks are 
a disaster to unravel and b) the arduino package is retired in F35+. 
Instead, I used this firmware: 
https://github.com/drunken-octopus/drunken-octopus-marlin


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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Thomas Daede]

On 7/23/19 7:52 AM, Andrew Lutomirski wrote:
> 
> In the interest of a productive discussion, could we maybe focus on what
> the benefits are, both of changing the baseline in general and of
> enabling any particular features?

As someone whose software heavily depends on SSE and AVX2 assembly code,
we always do runtime detection. The SSE2 baseline of x86_64 is handy as
there are a few things I can inline as a result, but there is no
performance benefit to an AVX2 baseline, other than possibly the binary
size dropping a bit as it no longer has to include the SSE2 versions of
the functions.
___
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: F29 Self-Contained Change: Basic FPGA Support

[Thomas Daede]

On 07/18/2018 02:26 PM, Ben Cotton wrote:
> == User Experience ==
> Currently the Fedora support for FPGAs is basically non existent.
> There's currently a few open tools for specific FPGAs. This is the
> beginning of improving this with the intention of having a uniform as
> possible  user experience across FPGAs as is currently possible.

There is zero overlap between the open tools for FPGAs and the FPGAs
supported by the kernel FPGA manager right now. You should limit the
scope of this change to the FPGAs you actually want to support.

I wouldn't actually mind the open tools getting packaged (icestrom,
yosys, arachne-pnr, abc, tinyprog) but you should be clear if you're
doing that or not.
___
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/CTKWEQ6EK45RXK6UBA734H2Z6V2YBOD3/

Re: Lots a permission denied activity

[Thomas Daede]

On 07/16/2018 11:27 AM, Steve Grubb wrote:
> There is a /usr/libexec/tracker-extract process that searches my directories 
> about every 11 seconds. I can imagine on a laptop that would be a lot of disk 
> activity. Sometimes I use root in my home directory and accidentally create 
> files owned by root. This leads to a lots of events on my system. Does it 
> really need to run with this frequency?

I think this is a regression in tracker or one of its dependencies I
started noticing this happening last week. I haven't yet rolled it back
to figure out what version is at fault, though.
___
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/B2IMAX5VMFOZYYP7LGIARY7N5ER3KTNX/

Re: F29 System Wide Change: uEFI for ARMv7

[Thomas Daede]

On 07/03/2018 05:15 AM, Jan Kurik wrote:
> Move to uEFI as the default boot mechanism for ARMv7 devices.

Will this work with virt-manager too? Currently, while aarch64 boots via
uEFI there, it seems that armv7 is only supported by manually specifying
a kernel and initrd.
___
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: ${hyperkitty_url}

Re: Firefox "Looking Glass" fiasco

[Thomas Daede]

On 12/18/2017 03:00 PM, Sam Varshavchik wrote:
> Does anyone read this as Mozilla admitting that they messed up?

This was published today:
https://blog.mozilla.org/firefox/update-looking-glass-add/



signature.asc
Description: OpenPGP digital signature
___
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

[Thomas Daede]

This now landed in Firefox Nightly, and it's working great! The only bug
I hit was with the dark theme:
https://bugzilla.mozilla.org/show_bug.cgi?id=1416673

On 09/15/2017 12:26 AM, Martin Stransky wrote:
> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Updates for Firefox 57 beta

[Thomas Daede]

On 10/16/2017 01:56 PM, Richard W.M. Jones wrote:
> Can you enable "extensions.legacy.enabled"?  That would solve the main
> problem.
> 
> I had a look at the RPM and grepped the FF sources but I couldn't work
> out how you are supposed to enable that setting, but I guess FF
> maintainers may have a better idea.

Some internal XPCOM interfaces have changed or disappeared, so there is
no guarantee this will work with all extensions.
___
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?

[Thomas Daede]

On 10/12/2017 10:52 AM, Adam Williamson wrote:
> I think that may not realistically be possible, though, as 56 is not
> being made an ESR, AFAICT, and 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).

I should note that there are also backwards incompatible profile changes
from 57 to 56.

Backporting security fixes is definitely an option. I don't know of any
current security fixes that need to be backported (and because 57 isn't
released yet, severe ones will be backported to 56 point releases by
upstream), but if you lock F26 or F27 to 56, you'll have to be
backporting for 6 months or a year, respectively.
___
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?

[Thomas Daede]

On 10/12/2017 02:54 AM, Till Hofmann wrote:
> Yes, but that wasn't branded as all-new, better-than-ever Firefox (which
> it is), that intentionally breaks stuff which is directly visible by the
> end-user. An update that breaks the majority of extensions is very hard
> to sell for a stable release, as much as I love the new Firefox.

Special-casing a normal Firefox release would be a bad idea as they
don't receive security backports. Switching Fedora to ESR-only would be
the only safe way to accomplish this.

(this is unrelated to whether it should have been pushed as Beta)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: power management

[Thomas Daede]

On 04/09/2017 02:39 AM, František Zatloukal wrote:
> I had bad experience with enabling powertop' service - USB mice and 
> headphones don't work very well with that. But I am using tuned (tuned-gtk) 
> for few years and I didn't notice any issues (top-battery) profile. I see 
> that my Haswell laptop is using both C2 and C3 power-saving states.

Do you know which powertop tunable was the one to cause issues? We
should make a note to avoid it (or the tuned or tlp equivalent)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: power management

[Thomas Daede]

On 04/07/2017 05:04 PM, Chris Murphy wrote:
> Powertop, maybe it ought to be a feature request for F27, and see if a
> bunch of bug reports happen during the beta *shrug*. I've used it on
> an ancient and new laptop, of different manufacture, and haven't had a
> problem. But of course if it puts e.g. USB bus to sleep and there's a
> bug preventing it from waking up when someone plugs a flash drive in,
> that'd be pretty annoying as default behavior if this is a
> possibility.

Powertop by itself doesn't set any tunables on boot - it's more of a
debugging tool. While that means it won't break anything, it also will
have no effect for most users, making it mostly uninteresting as a
feature request.

For stuff like framebuffer compression, the Intel driver only enables it
on sufficiently new hardware where it's expected bugs are less likely.
Maybe some similar heuristic could be used for setting default tunables,
but I'm not sure what it would be without specific examples.

thermald seems to be something else entirely - it's for thermal
throttling. This might prevent the thermal MCE's that pop up when my
machine overheats, but as far as I can tell is an independent issue.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: power management

[Thomas Daede]

There's also tuned, another way to set lots of kernel bits. I think it
was an accepted feature for a previous Fedora release, but it's off by
default, and it is only mentioned in the Fedora 20 power saving guide,
which seems to have disappeared entirely for Fedora 21+:

https://docs.fedoraproject.org/en-US/Fedora/20/html/Power_Management_Guide/tuned.html

It would be really nice to have something on by default. I certainly
don't want to go through the laundry list of tunables and profiles every
time I install a Fedora system. The big thing that has prevented this
previously, as I understand, is the possibility to expose power
management bugs, breaking things for some users.

In my experience some of the powertop settings make quite a big
difference. Out of the box on my haswell laptop, Fedora never enters any
package state lower than C2. Just turning on SATA link power management,
for example, allows it to enter C3 and saves a few watts.

On 04/07/2017 03:47 PM, Chris Murphy wrote:
> 01.org has several projects related to power management, but most
> aren't in Fedora repositories. Are any of these useful for the recent
> effort to make power management better on Fedora?
> 
> I've been compiling thermald from source for a while, and it does make
> a difference to battery life and heat generation on laptops. It's only
> in copr and that version is old.
> 
> The description of thermal daemon:
> "This is an active open source project distributed under the LGPL open
> source license. With a mature and established codebase containing
> about 12,000 lines of code.
> 
> Linux Therman Daemon is currently used in distributions such as Ubuntu
> and Fedora and can be used any Linux-based system, including Chromium,
> Chrome OS or Android."
> 
> Except it's not used in Fedora. Intel is the maintainer upstream.
> Seems like a strong candidate for default installation and activation
> on Fedora Workstation.
> 
> Next up is Powertop, which I've used off and on mostly for diagnostic.
> But it also has some startup time optimizations applied with a systemd
> unit. *shrug* I can't quantify how useful those optimizations are. The
> one in Fedora right now is the previous version which doesn't work on
> Skylake or Kabylake CPUs.
> 
> RAPL Power Meter I've never used.
> 
> suspendresume I hadn't even heard of until looking at this page just
> now, but the description sounds like it'd useful for both workstation
> and server products.
> 
> "The use of Suspend/Resume is an excellent way to save power in Linux
> platforms, whether in Intel® based mobile devices or large-scale
> server farms. Optimizing the performance of suspend/resume has become
> extremely important because the more time spent entering and exiting
> low power modes, the less the system can be in use."
> 
> 
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F24 → F25 upgrade made my system sluggish (input lag?)

[Thomas Daede]

On 12/14/2016 03:29 AM, Martin Ueding wrote:
> How could I diagnose this regressions? There are no issues in
> `journalctl -f` whenever there is a short lag. Any log that might help?

Could it be something to do with dbus? Do all of these actions make
messages appear in dbus-monitor? I've noticed a similar lag, but only
when opening links in a Firefox window.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Are MP3 files now permitted in Fedora packages?

[Thomas Daede]

On 12/11/2016 07:33 AM, Chris Adams wrote:
> I would expect if they are provided by upstream, they should be fine.
> However, if they are generated during build from some other source, that
> won't be acceptable, as MP3 encoding is still not allowed in Fedora.

Note also that if you are generating the MP3 files, you should really be
generating Ogg Opus or Vorbis files instead, to save install space (plus
they have decoders already shipped with gstreamer-plugins-base). Unless
your package totally lacks playback for anything besides MP3, of course,
but the only current providers of MP3 decode in Fedora are gstreamer and
libmpg123, and it's unlikely software uses the latter directly.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Fedora 26 C/C++ Compilation Flags Updates

[Thomas Daede]

I have such a piece of hardware and could run a benchmark in ~1 week, if
you're curious. That said, Fedora Workstation is borderline unusable on
that hardware anyway - due to the integrated graphics, not the CPU. I
doubt most users would notice a slowdown from different CFLAGS when
gnome-shell can't repaint the screen faster than 15fps.

On 11/10/2016 04:22 AM, Florian Weimer wrote:
> On 11/10/2016 12:42 PM, Alexander Ploumistos wrote:
>> On Thu, Nov 10, 2016 at 12:30 PM, Jan Kurik  wrote:
>>> * Drop -mtune=atom on i686: This flag was added to improve performance
>>> on the Intel Bonnell microarchitecture.
>>
>> Would you happen to have a ballpark estimate of the performance cost
>> that would incur on actual Bonnel CPUs?
> 
> Unfortunately not.  I'm not sure which architecture revision could
> provide a reference CPU, and then there is the matter of obtaining
> access to that piece of hardware.
> 
> Florian
> ___
> 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: Touchpad data needed - 5 min of effort

[Thomas Daede]

Thinkpad W540, with two finger right click on (which I think is off by
default):

https://people.xiph.org/~tdaede/w540.evemu.xz

On 11/13/2016 07:20 PM, Peter Hutterer wrote:
> [Disclaimer: sorry if you've seen this one before, I posted it to desktop@
> but I only got one recording. That's not quite enough to call it a dataset,
> let alone do any analysis on it. Please do consider the minimal effort
> required on your behalf.]
> 
> Are you using a touchpad frequently during the day? Then please read on, I 
> need
> some touchpad usage data and it'll only take you 5 minutes to run the commands
> below to gather the data.
> 
> If you're technical enough, here's the TLDR:
> in screen, run sudo evemu-record > touchpad-recording.evemu, select your
> touchpad device and at the end of the day upload a compressed tarball 
> somewhere
> and send me the link off-list. thanks.
> 
> Otherwise, the steps one-by-one:
> 
> Open a a terminal now, then install evemu:
>$> sudo dnf install -y evemu screen
> 
> Then start screen:
>$> screen -S evemu
> 
> Now you're inside screen and you can start the recording
>$> sudo evemu-record > $HOME/touchpad-recording.evemu
> 
> One device will be a touchpad, named "SynPS/2 Synaptics Touchpad" or some 
> other
> name that should be identifiable. If you're on a late model Dell, it may be
> named DLL0234 or something. Once you selected the device, evemu will start
> recording.
> 
> Then hit Ctrl+a, then d to detach screen and return to the terminal.
> 
> Check that the recording works:
>$> tail -f $HOME/touchpad-recording.evemu
> 
> Whenever you touch the touchpad, you should see events filling up the screen
> now. If so, everything is working. Hit Ctrl+C to quit the 'tail' command. You
> can close the terminal now.
> 
> The screen session will now sit in the background, recording all your touchpad
> events into that file. At the end of the day:
> 
> First, open a terminal and restore the screen session:
>$> screen -r evemu
> 
> Hit Ctrl+C to interrupt the evemu-record process, then type exit to quit
> screen. Compress it first so it reduces in size a bit:
> 
>$> gzip $HOME/touchpad-recording.evemu
> 
> Now upload the newly created $HOME/touchpad-recording.evemu.gz file somewhere
> and send me a off-list email with the link so I can grab it.
> 
> Thanks heaps.
> 
> As for "why" do I need this? I need it to analyse touchpad motion data to get
> an idea of what range of finger motion speed is common and expected during
> normal usage.
> 
> Cheers,
>   Peter 
> ___
> 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: F25 workstation, and (almost) hidpi displays

[Thomas Daede]

On 10/21/2016 03:31 PM, Adam Williamson wrote:
>> There was a lot of kerfuffle around the GTK (and Wayland) decision to
>> only support integer scales, searching for it will give you some background.
> 
> I don't recall that...do you have any specific references? At the time
> hidpi was first added to GNOME, IIRC, only OS X was really doing it,
> and it only did it in integers (because, as you say, they just make
> sure that's all the hardware they ship needs).

I think this thread was the start of the discussion:
https://lists.freedesktop.org/archives/wayland-devel/2013-May/009073.html

There were several after that. Sometimes they are quite difficult to
follow, as the concepts of fractional scaling, and scaling based on EDID
DPI are often mixed up, although they are orthogonal. Even more so
because until recently, Qt still used EDID DPI scaling (as of 5.6, it
supports a mode like Windows where it assumes 96dpi and supports
fractional scale factors)

There are technical issues with drawing natively at fractional scales,
such as choosing sizes of Xembeds or Wayland subsurfaces, which are
always snapped to the nearest pixel. Qt and Firefox manage, but probably
because neither really uses Xembeds, and both have to work on Windows.
There are also personal preferences, as integer scales with legacy
applications can use nearest neighbor resampling leading to sharp but
pixelated images, and fractional scaling usually uses bicubic or lanczos
which leads to soft images.

I think it would be great to improve the out of box experience for these
displays that sit at awkward scaling steps, with the tools that we
currently have. I'm not exactly sure of the best approach, though. For
example, Firefox could be changed to pick up a fractional scaling from
the gnome-tweak-tool's font scaling, but that means its widget sizes
don't quite line up with other GTK3 apps. You can also achieve Mac-style
2x->1.5x or 3x->2x scaling via xrandr plane scaling - maybe a UI could
be created for that (but with the performance caveats).

> Still, now I got curious and looked it up, it's a bit difficult to
> interpret Windows' history here. I can at least tell that Windows 7 and
> 8 had 100%, 125% and 150% scaling settings, and 8.1 and 10 have up to
> 200% and per-display scaling, but I haven't found any references as to
> exactly how this is implemented for each release - whether it's really
> interface scaling, complete with high-resolution interface assets in
> the OS so the scaled display actually looks sharp, or if it's just text
> scaling like GNOME's 'text scaling factor'...

I have a Windows 10 machine right next to me (being used by a coworker).
It appears to have full interface scaling, with high resolution assets,
for apps that indicate support. It's currently set to 1.5x scaling with
a 4k monitor.

For multiple displays, the app can only have one scaling at a time, but
it does change per monitor. Moving an app across screens causes a sudden
"snap" in its scale factor once it's over halfway to the other screen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F25 workstation, and (almost) hidpi displays

[Thomas Daede]

On 10/21/2016 03:20 PM, Adam Williamson wrote:
> Out of curiosity, do you know if that's hidpi-style 'scale everything'
> scaling, or is it just font size scaling?

It's hidpi-style 'scale everything'. Apps can either natively draw at
1.5x or 1.25x, or be scaled by the compositor (with what looks like a
bicubic approximation).

> I read somewhere that Apple came up with a trick for doing 1.5x hidpi
> scaling - they just scale everything 3x in software then tell the GPU
> to scale it back down by 2x on output. Which is a neat wheeze. Be
> trickier to do 1.25x that way, though.

Yup, in theory this should be implementable by a Wayland compositor,
too. The downside is that this approach is disastrous to memory
bandwidth - you're rendering over double the number of pixels that you
need to, and then you have to sample from all of those pixels in the
compositor, too. It's also not compatible with hinting (which Apple
doesn't do anyway).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F25 workstation, and (almost) hidpi displays

[Thomas Daede]

On 10/21/2016 03:08 PM, Adam Williamson wrote:
> 13" 1080p laptops are the biggest exception to this that I can think
> of. I dunno what you do with them on Windows; I think Windows has a
> slider somewhere which more or less works like the 'scaling factor'
> setting.

Yes, Windows also has a scaling factor, but it behaves more like the
Firefox one - it supports non-integer scales. Applications that don't
signal support for it are scaled by the compositor.

Mac hardware seems to have settled into choosing display densities where
integer scaling makes sense, though on PC there is more variety,
probably due to Windows supporting it.

There was a lot of kerfuffle around the GTK (and Wayland) decision to
only support integer scales, searching for it will give you some background.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F25 workstation, and (almost) hidpi displays

[Thomas Daede]

In Firefox, the about:config setting:

layout.css.devPixelsPerPx

can be set to an arbitrary non-integer scalefactor, such as 1.25 or 1.5.

Unfortunately, GTK applications are limited to scalefactors of 1 or 2 so
you're stuck with Large Text, gnome-tweak-tool's font scaling factor, or
setting font sizes directly in gnome-tweak-tool.

On 10/21/2016 11:44 AM, Chris Murphy wrote:
> HP Spectre 13" 1920x1080 and all text everywhere by default is just on
> the cusp of too small. I don't think this is really a hidpi display,
> so I'd expect this problem to be much worse if it were 3200x1800.
> 
> To compensate, I'm using Large Text in Universal Access. But
> applications don't use that, such as Firefox.  Further,
> Preferences>Content >Fonts & Colors> Size is not used on many sites,
> so that produces mixed results. Yes I can control-+ to get bigger
> text, but that's a per page setting apparently - so I get even more
> mixed results.
> 
> So... what am I missing that'd make this a better out of the box experience?
> 
> This is gnome 3.22.1 on wayland. Thanks.
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Locked memory limits are too low

[Thomas Daede]

For Fedora Workstation, the current limit on mlock()ed memory per user
is 64kiB, which less than what some applications need.

In particular, Bitcoin Core uses mlock() to prevent private keys from
being swapped to disk. The total size of the wallet keys can exceed 300kB.

Audio is another use case that uses mlock() to prevent skips. Fedora
already has special cases for some apps such as jack, which it gives 4GB.

It looks like another custom rule was given to qemu recently:
https://bugzilla.redhat.com/show_bug.cgi?id=1293024

The reason for the restriction is presumably an anti-DoS measure for
multi-user systems. It's not really clear where the 64kiB value came
from though - it seems like it could be much, much higher.

Thoughts on raising the value?

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

Re: Please unpush FEDORA-2016-7776983633 on all releases or drop support for libjasper

[Thomas Daede]

On 09/14/2016 12:50 PM, Richard Hughes wrote:
> Although, perhaps given upstream has not had a release since 2006 and
> we've acquired 14 out-of-tree security patches (and countless others
> for various fixes) perhaps we should drop dep this from applications
> completely?

OpenJPEG has long replaced Jasper as the implementation of choice for
JPEG2000. I think it would be reasonable to drop Jasper and ask
upstreams to port to a different implementation if they still want
JPEG2000 support.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: ARM help needed

[Thomas Daede]

That's all x86 assembly, not ARM.

It looks like all that program is doing is trying to select a bundled
software mesa implementation. None of those are probably included in the
Fedora build anyway, I'd suggest patching to not build that executable
at all.

On 01/05/2016 06:12 PM, Orion Poplawski wrote:
> paraview is failing to build on arm:
> 
> /builddir/build/BUILD/ParaView-v5.0.0-RC3-source/fedora/CommandLineExecutables/paraview-config-forward.c:
> 
> In function '__cpuid':
> /builddir/build/BUILD/ParaView-v5.0.0-RC3-source/fedora/CommandLineExecutables/paraview-config-forward.c:95:3:
> 
> error: impossible constraint in 'asm'
>asm volatile("cpuid" : "=a"(out[0]), "=b"(out[1]), "=c"(out[2]),
> "=d"(out[3])
>^
> /builddir/build/BUILD/ParaView-v5.0.0-RC3-source/fedora/CommandLineExecutables/paraview-config-forward.c:
> 
> In function 'check_xcr0_ymm':
> /builddir/build/BUILD/ParaView-v5.0.0-RC3-source/fedora/CommandLineExecutables/paraview-config-forward.c:124:3:
> 
> error: unknown register name '%edx' in 'asm'
>__asm__("xgetbv" : "=a" (xcr0) : "c" (0) : "%edx");
>^
> /builddir/build/BUILD/ParaView-v5.0.0-RC3-source/fedora/CommandLineExecutables/paraview-config-forward.c:
> 
> In function 'get_cpu_features':
> /builddir/build/BUILD/ParaView-v5.0.0-RC3-source/fedora/CommandLineExecutables/paraview-config-forward.c:124:3:
> 
> error: unknown register name '%edx' in 'asm'
>__asm__("xgetbv" : "=a" (xcr0) : "c" (0) : "%edx");
>^
> 
> Would someone familiar with arm assembly be willing to take a look?
> Unfortunately this is a generated file, but I've attached at copy.
> 
> Does arm even implement cpuid?
> 
> Thanks.
> 
> 
> 
> --
> 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: What's the current status of mp3-licensing issues?

[Thomas Daede]

On 11/15/2015 10:34 AM, Gerald B. Cox wrote:
> My understand is that Opus excels at lower bitrates; above 100 Vorbis is
> better.

Opus is always better - but at high bitrates, artifacts become so
imperceptible that it doesn't matter too much which codec you pick, so
you might still pick Vorbis for greater compatibility.

> In any event, are the same FUD tactics that were used against
> Vorbis applying to Opus - and with the expiration of the MP3 patents I
> would think those arguments would now be moot... but I'm sure there will
> always be some excuse.

As has been seen, the threats against Vorbis were all hollow. If your
claims are baseless, it doesn't matter if the unspecified patents are
expired or not :)

In general, Opus adoption has been very fast compared to Vorbis because
it is vastly better than other options in the low-delay niche, and is
mandatory for WebRTC.
-- 
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: Announcing the release of Fedora 23 Beta!

[Thomas Daede]

On 09/25/2015 02:18 PM, Andreas Tunek wrote:

> Removed librtmp (what could go wrong?), now I get the following error:
> 
> Sep 25 23:14:39 iMacLinux dnf[621]: Error: package
> kernel-core-4.1.7-200.fc22.x86_64 requires systemd >= 200, but none of
> the providers can be installed
> Sep 25 23:14:39 iMacLinux dnf[621]: (try to add '--allowerasing' to
> command line to replace conflicting packages)
> Sep 25 23:14:39 iMacLinux systemd[1]: dnf-system-upgrade.service: main
> process exited, code=exited, status=1/FAILURE
> Sep 25 23:14:39 iMacLinux systemd[1]: Unit dnf-system-upgrade.service
> entered failed state.
> Sep 25 23:14:39 iMacLinux systemd[1]: dnf-system-upgrade.service failed.
> Sep 25 23:14:39 iMacLinux systemd[1]: Rebooting as result of failure.
> 

This looks like it might be related to
https://bugzilla.redhat.com/show_bug.cgi?id=1244175

I had a similar problem. --allowerasing will try to erase the currently
running kernel, which will fail.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Thomas Daede]

Um, that bug looks totally unrelated to the problems reported here.

On 09/21/2015 06:51 PM, Rex Dieter wrote:
> Rex Dieter wrote:
> 
>> Germano Massullo wrote:
>>
>>> Il 21/09/2015 21:45, Thomas Daede ha scritto:
>>>> Is there currently a bug open for this? I'd rather it not get lost.
>>> I think that a FESCo ticket would be more appropriate.
>>
>> I think it would be premature to appeal to FESCo without giving pulseaudio
>> maintainers a chance to respond to your proposal first.
>>
>> Mind filing a bug with your proposal ?
> 
> We could recycle the bug you filed for that purpose,
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1264177
> 
> -- Rex
> 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Thomas Daede]

In the case of Youtube, you shouldn't be having any issues because
Mozilla switched to using a soft mixer internal to Firefox:

https://bugzilla.mozilla.org/show_bug.cgi?id=1046814

If you still have issues, you should report them upstream.

(note that this means all website volume sliders are designed to behave
as a mixer, not as flat volumes)

On 09/21/2015 04:59 PM, Michael Catanzaro wrote:
> That's definitely not correct. With flat volumes, applications can and
> do set the system volume to 100%. I've received numerous complaints
> about this. It's particularly frustrating when watching YouTube videos,
> since YouTube sets the system volume to 1 when starting a video. We are
> still waiting for some promised "browsers API" in PulseAudio to fix
> this easily.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Thomas Daede]

OK, here's a couple of counterexamples, still using default apps:

- I start chatting on Firefox with WebRTC and I can't hear the person
talking over my music. So I open the GNOME control center and make
Firefox louder. Pulseaudio is awesome. But now, the volume of all of my
other applications is permanently lowered, and can no longer reach max
volume. When I unplug my headphones and want to crank up my laptop
speakers, I discover my music plays back too quietly. In fact, it turns
out that now I have to open the settings and adjust every application
back up to 100%, whenever I open a new application.

- Rhythmbox's volume slider goes from 0-100%, and this changes system
master volume. I don't know of any other OS that does this - it's
certainly not the skeumorphic thing to do.

- Many web pages include a volume control, e.g. Youtube. This is always
expected to behave in the traditional (multiplicative) way, so Firefox
had to implement a soft volume control before hitting pulseaudio:
https://bugzilla.mozilla.org/show_bug.cgi?id=1046814

With flat volumes, applications initially start at 100%, and you can
change the volume up or down. Without, you can only adjust them down.
While being able to adjust both ways might be nice at first, it quickly
becomes a mess when your application's volumes end up all over the place
with some use of this feature.

To me, flat volumes seems to be a result of discovering that HD Audio's
spec provides well defined amplitude levels for the master mixer
control, and then trying to find a problem to solve with that new
ability. I don't think this one worked out.

On 09/21/2015 03:00 PM, Owen Taylor wrote:
> On Thu, 2015-09-17 at 23:26 +0200, Germano Massullo wrote:
>> Il 17/09/2015 21:13, Andrew Lutomirski ha scritto:
>>>
>>> To clarify: did you get blasted by music or by video conference
>>> sounds?  If the music volume got louder, then it sounds like either
>>> a
>>> straight-up bug in PulseAudio (and a severe and dangerous one at
>>> that)
>>> or a serious bug in your video conference volume in which it
>>> adjusts
>>> the volume of streams other than its own.
>>>
>>> If you got blasted by video conference sounds, then I'd say it's a
>>> serious design flaw in PulseAudio.  PulseAudio should offer an
>>> easy-to-configure maximum volume (probably A-weighted power, but
>>> peak
>>> level works, too, if considerably less well) on a per-output basis
>>> with which to protect your ears.
>>>
>>> --Andy
>> I got blasted from the music because I was not making a conference, I
>> only logged into the software, so the music was the only sound I was
>> listening to. PulseAudio pushed the master audio level to 100%
>> (therefore all applications audio level changed to 100%, due flat-
>> volume setting).
> 
> I'm not an expert in the subject, but I'm pretty sure this is not how
> flat volumes are supposed to work - it doesn't sound like useful
> behavior at all!
> 
> Experimenting with GNOME, the model presented to the user seems to be:
> 
>  - Each application's volume control separate goes from 0-100% of the
>maximum system volume. 
>  - Adjusting each application is independent
>  - Modifying the system global volume slider proportionally adjusts the
>volume of each application
>  - The system global volume slider is always maintained to be at least
>as much as the maximum of any application
> 
>  NOTE: The system global volume slider is *not the same as the hardware
>volume and does not represent a multiplication factor for
>application volumes. It's just something that the user can
>drag to change the volume of all applications.
> 
> There is danger to the ears if an application assumes that 100% volume
> is a safe volume and blindly sets its volume to 100% without user
> input. But that only affects that application - one application's
> misbehavior never affects another application.
> 
> It sounds like KDE ends up implementing a different model, either
> intentionally or because of bugs. It's also possible that lower level
> bugs (sound card driver, for example) might be making things misbehave.
> 
> In general, the fact that pulseaudio is configurable in this area is
> going to be the source of almost infinite bug chasing, as applications
> and desktop environments are "fixed" for one setting or another. It's
> also very easy for people to stop investigating problems and say that
> "changing the setting fixed it for me." :-(
> 
> - Owen
> 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Thomas Daede]

Is there currently a bug open for this? I'd rather it not get lost.

On 09/17/2015 11:59 AM, Germano Massullo wrote:
> ===
> Definition of flat-volumes from [1] : it scales the device-volume with
> the volume of the "loudest" application. For example, raising the VoIP
> call volume will raise the hardware volume and adjust the music-player
> volume so it stays where it was, without having to lower the volume of
> the music-player manually.
> ===
> 
> Today I had a scary experience with the audio of my computer.
> I was listening to music with Amarok, using my headphones... The KMix
> volume level was ~ 35%. When I logged into a video conference
> application, the volume suddenly reached the 100%. I was shocked, having
> the maximum audio level shooted in your ears is a painful experience.
> The conference application that triggered PulseAudio pushing volume to
> maximum level probably should have never asked the system for a 100%
> audio level, but on the other hand, PulseAudio should never allow an
> application to make such sudden changes.
> To avoid that, you have to set
> flat-volumes = no
> in /etc/pulse/daemon.conf
> 
> I found many users stories complaining about this default setting [2]
> [3] [4] and you can easily find other by searching "pulseaudio flat
> volumes".
> I completely agree with user gaggra comment at [3]
> 
> < misbehaving software can /physically hurt you/. You would think that
> once that was understood, the design of this sort of behaviour would be
> treated in a very conservative, careful manner.>>
> 
> Moreover this default setting can cause sound crackling [5].
> 
> So I would like to start a discussion about disabling this default
> behaviour for the mentioned reasons.
> 
> 
> [1] https://wiki.archlinux.org/index.php/PulseAudio
> [2]
> https://major.io/2015/06/08/pulseaudio-popping-with-multiple-sounds-in-fedora-22/
> [3]
> https://www.reddit.com/r/linux/comments/2rjiaa/horrible_decisions_flat_volumes_in_pulseaudio_a/
> [4]
> http://awesomelinux.blogspot.it/2013/06/pulseaudios-dynamic-volume-levels-are.html
> [5] https://bugzilla.redhat.com/show_bug.cgi?id=1264177
> 
> 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Thomas Daede]

I also absolutely hate flat-volumes. Often I have trouble getting an
application loud enough, and discover that it's too low in the mixer.
The idea of flat volumes is to avoid a global volume, but the way it
interacts is super confusing and unlike any other system people use
(except maybe Android, but all of its "content" apps are still coalesced
under one mixer).

That said, apps shouldn't be setting their own Pulseaudio volume in
general. Firefox did that for a while and ran into a similar bug as you
got with Amarok, so they implemented their own internal soft volume
rather than adjusting their Pulseaudio volume.

That said, flat-volume is the upstream default so we might want their
input, as well as looking at what other distros do.

On 09/17/2015 11:59 AM, Germano Massullo wrote:
> ===
> Definition of flat-volumes from [1] : it scales the device-volume with
> the volume of the "loudest" application. For example, raising the VoIP
> call volume will raise the hardware volume and adjust the music-player
> volume so it stays where it was, without having to lower the volume of
> the music-player manually.
> ===
> 
> Today I had a scary experience with the audio of my computer.
> I was listening to music with Amarok, using my headphones... The KMix
> volume level was ~ 35%. When I logged into a video conference
> application, the volume suddenly reached the 100%. I was shocked, having
> the maximum audio level shooted in your ears is a painful experience.
> The conference application that triggered PulseAudio pushing volume to
> maximum level probably should have never asked the system for a 100%
> audio level, but on the other hand, PulseAudio should never allow an
> application to make such sudden changes.
> To avoid that, you have to set
> flat-volumes = no
> in /etc/pulse/daemon.conf
> 
> I found many users stories complaining about this default setting [2]
> [3] [4] and you can easily find other by searching "pulseaudio flat
> volumes".
> I completely agree with user gaggra comment at [3]
> 
> < misbehaving software can /physically hurt you/. You would think that
> once that was understood, the design of this sort of behaviour would be
> treated in a very conservative, careful manner.>>
> 
> Moreover this default setting can cause sound crackling [5].
> 
> So I would like to start a discussion about disabling this default
> behaviour for the mentioned reasons.
> 
> 
> [1] https://wiki.archlinux.org/index.php/PulseAudio
> [2]
> https://major.io/2015/06/08/pulseaudio-popping-with-multiple-sounds-in-fedora-22/
> [3]
> https://www.reddit.com/r/linux/comments/2rjiaa/horrible_decisions_flat_volumes_in_pulseaudio_a/
> [4]
> http://awesomelinux.blogspot.it/2013/06/pulseaudios-dynamic-volume-levels-are.html
> [5] https://bugzilla.redhat.com/show_bug.cgi?id=1264177
> 
> 
-- 
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

[Thomas Daede]

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.

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

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: Is it time to allow Chromium in Fedora?

[Thomas Daede]

 *if* you use binary tarballs they *should not* be extracted in a user
 writeable location as *no binary* whenever possible should have
 permissions allowing a ordinary user to change them
 
 This is simply not the way how end users install original Mozilla
 Firefox binaries.
 

In addition, if you have write access to ~/, you can also change .bashrc
to add paths to executable files and do all sorts of other nasty things.

FWIW I run Mozilla's Firefox nightly builds and they work perfectly fine
on Fedora. I've also found the lag behind the official releases
annoying, also for some other large end-user packages (blender), for no
perceived benefit. But it's not especially painful.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Unretiring the mumble package

[Thomas Daede]

I currently use Mumble quite a bit, but it has been orphaned in F22+. I
have emailed the previous maintainer but didn't get a response.

I would be interested in maintaining the package, but this would be the
first that I have done for Fedora.

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