Re: Orphaning the cura-lulzbot package set
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
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
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
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
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
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
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
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?
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?
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
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
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
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?)
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?
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
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
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
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
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
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
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
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
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
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?
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!
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
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
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
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
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
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
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?
>> *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
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
