Re: On running gui applications as root

On Fri, 2015-10-30 at 14:58 -0700, Andrew Lutomirski wrote: > On Fri, Oct 30, 2015 at 2:48 PM, Adam Jackson <a...@redhat.com> wrote: > > > > Anyone running any X (or wayland) application as root in their desktop > > session is completely bonkers and deserves every co

Re: On running gui applications as root

On Fri, 2015-10-30 at 11:41 -0400, John Dulaney wrote: > As Halfline points out, the decision needs to be made whether to allow > gui applications to be run as root.  I figured I'd bring this up for > discussion in the hopes that a decision may be made whether or not to > allow this. Anyone

Schedule for Wednesday's FESCo Meeting (2015-11-04)

Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at   http://fedoraproject.org/wiki/UTCHowto or run:   date -d '2015-11-04 18:00 UTC' Links to all tickets

Summary/Minutes from today's FESCo Meeting (2015-11-04)

=== #fedora-meeting: FESCO (2015-11-04) === Meeting started by ajax at 18:01:11 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2015-11-04/fesco.2015-11-04-18.01.log.html . Meeting summary

Re: Summary/Minutes from today's FESCo Meeting (2015-10-07)

On Thu, 2015-10-08 at 10:55 +0200, Tomas Mraz wrote: > Yes, it seems the quantity over quality view won. :( This is a false dichotomy. The ultimate metric of quality is whether the distribution contains a working copy of the software you want to run. Bundling is a maintenance concern for

Re: Summary/Minutes from today's FESCo Meeting (2015-10-07)

On Sat, 2015-10-10 at 01:51 +0200, Kevin Kofler wrote: > * Scanning binary packages for conflicting symbols does not work either > because they are only a problem if the conflicting libraries get dragged > into the same executable at runtime. You can compute this statically. You know the

Re: Summary/Minutes from today's FESCo Meeting (2015-10-07)

On Fri, 2015-10-09 at 14:55 +, Jóhann B. Guðmundsson wrote: > Interesting taking the consumer perspective. > > So where does FESCo intend to draw the line now that it has chosen to > head down this path. I mean, I can't speak for fesco as a whole, but speaking for myself: I reject the

Re: Summary/Minutes from today's FESCo Meeting (2015-10-07)

On Fri, 2015-10-09 at 13:50 +0100, Richard W.M. Jones wrote: > I agree - the new wording does appear to give in to poor programming > practices. Bundling is _not_ intrinsically poor practice. Firefox is a good example of this, there have been several cases where using the system instance of

Re: Summary/Minutes from today's FESCo Meeting (2015-10-07)

On Fri, 2015-10-09 at 01:22 +0200, Kevin Kofler wrote: > Adam Jackson wrote: > > From the consumer's perspective it makes zero difference whether a > > particular library is bundled or not, as long as the app works. > > Only until they run into their first symbol confli

Re: Removing vm86 support?

On Tue, 2015-07-07 at 16:20 -0700, Andrew Lutomirski wrote: I'm asking here because Fedora seems to one of few distros that enables CONFIG_VM86 on 32-bit kernels. Would anyone object if the upstream kernel (and hence Fedora) removed vm86 support? This would break 16-bit real mode programs

Re: [Fedora-legal-list] [RFC] Switching to SPDX in license tags

On Thu, 2015-07-09 at 10:05 -0400, Richard Fontana wrote: On Thu, Jul 09, 2015 at 03:53:51PM +0200, Stanislav Ochotnicky wrote: Without looking too much into SPDX license list - would some of the licenses we currently consider MIT fall under different license name under SPDX? No, because

Re: Removing vm86 support?

On Wed, 2015-07-08 at 11:29 -0700, Andrew Lutomirski wrote: It may not end up going away. I want to mark it BROKEN, which means that basically everyone's config will disable it. The problem is that it's buggy and probably full of security holes. Certainly using it the way xserver needs to

Re: [ACTION REQUIRED] FTBFS Packages in rawhide (2015-07-08)

On Wed, 2015-07-08 at 21:55 +, opensou...@till.name wrote: The following packages did not build for two releases and should be retired when Fedora (F23) is branched, unless someone takes care of them. If you know for sure that the package should be retired, please do so now with a proper

Re: On running gui applications as root

On Tue, 2015-11-17 at 17:30 +, Andrew Haley wrote: > On 11/02/2015 03:05 PM, Adam Jackson wrote: > > But, why take the risk exposure, when you could simply not? > > How else would I edit root-owned files?  I don't get it.  I mean, > I guess I could run an editor in a text w

Re: On running gui applications as root

On Wed, 2015-11-18 at 11:53 -0800, Andrew Lutomirski wrote: > I don't understand.  If a user who has the right to act as root asks > to authorize a program to run as root on their behalf, we should grant > that request.  And, once we grant it, we shouldn't be > passive-aggressive and say "sure

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

On Wed, 2015-09-16 at 18:26 +0100, Peter Robinson wrote: > What is the proper fix to these issues? Having fixed some myself and > ajax having looked at a bunch of them I don't think it's as simple as > just mass rebuilding the packages. A lot of it is libtool being shit, which is nothing new I

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

On Thu, 2015-09-17 at 12:00 +0100, Steve Grubb wrote: > Also, the full RELRO thing is a bit oversold. You need it if the > executable is PIE, and that's not needed in the general case. There are > far worse problems that are easy to fix that are not getting attention. > With the RELRO thing, you

Re: Fedora 23 cloud image (and, for that matter, minimal anything) bloat

On Thu, 2015-09-24 at 00:59 +, Zbigniew Jędrzejewski-Szmek wrote: > Bummer. The reason for libxkbcommon dependency is to be able to make > sure that the new config is valid. Before that was added we had a set > of rules and heuristics implemented in localed and regular bug reports > when

Re: llvm 3.7 for rawhide and then f23

On Sun, 2015-09-20 at 21:00 +0800, Christopher Meng wrote: > On 9/20/15, David Airlie wrote: > > It's llvm, there is never a good time to upgrade it and no llvm release is > > backwards compatible. > > Yes, so unless someone is pretty familiar with LLVM upstream, keep >

Re: On running gui applications as root

On Wed, 2015-11-18 at 21:45 +, Ian Malone wrote: > Not really getting this. For any configuration task where you replace > editing a root owned text file with access through some authorised > gui, that gui is still vulnerable. That gui's code, unlike emacs, doesn't allow you to write

Heads up: glew soname bump in F24

I'm planning to bump glew to 1.13.0 in the next day or so. This will require rebuilding roughly 43 dependent packages (see list below). I'm running through a mass mockchain of that locally, I'll kick off rebuilds in koji once that's complete and assuming things mostly rebuild successfully. The

Re: rawhide report: 20160115 changes

On Fri, 2016-01-15 at 10:51 +, Fedora Rawhide Report wrote: Some fallout from the glew rebase in here, none of which is strictly glew's fault as far as I can tell. > [FlightGear-Atlas] > FlightGear-Atlas-0.5.0-0.15.cvs20141002.fc24.i686 requires > libGLEW.so.1.10 Map.o: In function

Re: ELF arch question

On Wed, 2016-01-13 at 16:03 -0700, Orion Poplawski wrote: > rpm flags shared libraries of ELFCLASS64 with '(64bit)' on all architectures > except Alpha (which thankfully we don't support).  My question is, are > ELFCLASS64 libraries always installed in /usr/lib64 on all Fedora platforms, > or am I

Re: Strange display bug

On Thu, 2016-02-04 at 12:47 +, Jonny Heggheim wrote: > Hi, my internal laptop screen turns on and off. > > It happens both on Fedora 23 and Fedora rawhide. With Gnome 3 and > xmonad. The bug is triggered by most of the webpages. It have also > happend with other programs, but I have not been

Heads up: LLVM repackaging in F24

LLVM upstream is (eventually) dropping their autotools build system in favor of their cmake buildsystem. This wouldn't normally be something you'd notice, but the two produce different sets of shared libraries, autotools gave you one big libLLVM and cmake gives you lots of individual libraries.

Re: Heads up: LLVM repackaging in F24

On Wed, 2016-01-27 at 11:25 -0500, Neal Gompa wrote: > Aren't clang, lldb, and compiler-rt still part of the main LLVM > package sources, though? It would make sense to continue building them > as part of the LLVM package since they ship together. They're distributed as separate tarballs, if

Re: [ANNOUNCE] Fedora support for Vulkan

On Wed, 2016-02-17 at 14:30 -0600, Richard Shaw wrote: > I read the readme in the Vulkan branch on the mesa git but how do you > tell if your chipset is specifically supported? The driver emits a warning chirp if the chipset isn't fully supported, and will refuse to initialize on devices that are

Re: hawkey replaced by libhif, DNF into C initiative started

On Thu, 2016-02-25 at 18:58 +0100, Jan Kratochvil wrote: > On Thu, 25 Feb 2016 18:03:52 +0100, David Malcolm wrote: > > I think I'm only semi-serious here [1], but have you considered > > Rust? > > [1] e.g. it's not yet in Fedora. > > or proven C++11(/14/17)? > (it is already in Fedora) C++ is

Re: Minimizing the fedora docker base image footprint

On Mon, 2016-02-22 at 09:54 -0500, Courtney Pacheco wrote: > If possible, I'd like some feedback on the work I did. Comments and  > criticism are more than welcomed! I realize there may be some  > controversy in terms of what I chose to remove and what I chose to turn  > into weak dependencies,

[ANNOUNCE] Fedora support for Vulkan

I'm pleased to announce support for Vulkan for Fedora! == What is Vulkan? == Vulkan is a new generation graphics and compute API that provides high- efficiency, cross-platform access to modern GPUs. Or: Vulkan is to OpenGL as Wayland is to X11. It does many of the same things, but - with the

Re: [ANNOUNCE] Fedora support for Vulkan

On Tue, 2016-02-16 at 11:34 -0800, Andrew Lutomirski wrote: > $ vkcube > 1 physical devices > anv_device.c:405: FINISHME: Get correct values for VkPhysicalDeviceLimits > vendor id 8086, device name Intel(R) HD Graphics 520 (Skylake GT2) > vulkan: No DRI3 support > Vulkan not supported on given X

Re: Why Wayland session runs on 2nd VT?

On Thu, 2016-03-03 at 15:47 +0100, Vít Ondruch wrote: > Why Wayland session runs on 2nd VT? > > I.e. my 1st VT always contains the GDM and 2nd VT actually displays the > Wayland user session. That is confusing, looking like that nobody is > logged in ... That's how GDM (and pretty much everyone

Re: F25 Self Contained Change: Rust Compiler

On Wed, 2016-07-13 at 12:42 -0700, Josh Stone wrote: > On 07/13/2016 07:50 AM, Adam Jackson wrote: > > On Wed, 2016-07-13 at 07:26 +, Stefan Nuxoll wrote: > > > Rust uses LLVM for codegen, so in theory, yes. This excludes any > > > potential platform-specific bugs t

Re: F25 Self Contained Change: Rust Compiler

On Wed, 2016-07-13 at 07:26 +, Stefan Nuxoll wrote: > Rust uses LLVM for codegen, so in theory, yes. This excludes any > potential platform-specific bugs that may affect rustc, which are > certainly a possibility. At the moment llvm has codegen support for every Fedora architecture, primary

Re: amdgpu xorg driver not installed by default

On Wed, 2017-02-08 at 13:24 +, christiankl...@gmail.com wrote: > Amdgpu has been available since Fedora 24 but the Xorg driver is > (still) not installed by default on Fedora 25 nor on Rawhide, yet > AFAIK it is required to do anything meaningful with the newer AMD > cards. Incorrect. The

Re: Headsup: Xserver update switching Intel GPUs from xorg-x11-drv-intel to -modesetting by default coming to rawhide

On Wed, 2017-02-22 at 02:42 +, Sérgio Basto wrote: > The default of modesetting is enable glamor Correct. > and glamor doesn't run on 32-bit archs Incorrect. Glamor works fine on 32-bit CPUs, and on 64-bit CPUs if you force them to run 32-bit binaries. What it doesn't work on is some of

Re: Headsup: Xserver update switching Intel GPUs from xorg-x11-drv-intel to -modesetting by default coming to rawhide

On Wed, 2017-02-22 at 22:51 +, František Zatloukal wrote: > > ... is trying to say. The "gen3" family of Intel GPUs (i915, i945, G33) > > are (to put it politely) garbage. Though they claim to support fragment > > shaders, the instruction limit of those shaders is far less than what > > glamor

Re: Headsup: Xserver update switching Intel GPUs from xorg-x11-drv-intel to -modesetting by default coming to rawhide

On Sat, 2017-01-14 at 08:20 +0100, Branko Grubic wrote: > I just want to mention that this change has been pushed (merged) to f25 > branch as well (which is not planed I guess), I filled bug #1413251 [1] D'oh, my bad. New update in testing shortly. - ajax

Re: Should we stop stripping static libraries?

On Tue, 2016-11-15 at 10:57 +0530, Siddhesh Poyarekar wrote: > On Monday 14 November 2016 02:18 PM, Florian Weimer wrote: > > Is this really necessary?  It's not the way ld currently works. > > It is necessary because the idea of unexpectedly finding debuginfo in > their binaries when one did not

Re: Headsup: Xserver update switching Intel GPUs from xorg-x11-drv-intel to -modesetting by default coming to rawhide

On Tue, 2017-01-10 at 11:59 -0600, Michael Cronenworth wrote: > Are performance regressions covered under this clause? > > Iris 5100 (Haswell) > gtkperf - Intel = ~29 seconds > gtkperf - Modeset = ~35 seconds > > Fairly significant change. On a benchmark that doesn't reflect real usage very

Re: RFC: Disable cairo-gl backend in F27

On Mon, 2017-07-10 at 23:43 +0900, Mamoru TASAKA wrote: > While I may be missing something, I don't think current Fedora package > needs ruby cairo-gl bindings. > Also, ruby-cairo gem does not have examples for cairo-gl surface nor have > test suite for that, so I guess the ruby-cairo upstream

Re: libglvnd-egl needed for X: should it be in base-x comps group? Or should something require it?

On Tue, 2017-07-25 at 01:49 -0400, David Airlie wrote: > > So, should this package be added to base-x ? Should something depend on > > it? Should X actually start up without libEGL.so.1, and I should file > > *that* as a bug? Thanks! > > Hans might answer this better, but X should start fine

RFC: Disable cairo-gl backend in F27

Apologies that this is just after the system-wide change deadline (thanks for putting that on a holiday btw), but I hadn't had a chance to dig into this before now and I think it's fairly low impact. Cairo's OpenGL backend is not especially well maintained or widely used, and cairo gets linked

Re: xorg-x11-drv-dummy for s390x?

On Tue, 2017-05-02 at 21:47 -0600, Orion Poplawski wrote: > I make fairly extensive use or xorg-x11-drv-dummy for running graphical  > tests in koji builds.  I see that xorg-x11-drv-dummy is not built for  > s390x, probably due to xorg-x11-server-devel not being available on  > s390x - apparently

Re: Can anybody check to see if libglvnd does get build correctly

On Sat, 2017-05-20 at 14:09 +0430, navid Rahimi wrote: > Hi, > > I am trying to use Skia static library in my system. The problem is > it depends on libglvnd. That's not the problem, I don't think. > : && /usr/bin/clang++ -rdynamic CMakeFiles/Chpp.dir/src/main.cpp.o -o > Chpp

Re: Testing graphical applications inside mock fails

On Tue, 2017-09-12 at 16:34 +, Samuel Rakitničan wrote: > > X Error: BadAccess (attempt to access private resource denied) 10 > > Extension:130 (MIT-SHM) > > Minor opcode: 1 (X_ShmAttach) > > Resource id: 0x131 > > X Error: BadShmSeg (invalid shared segment parameter) 128 > >

Re: Testing graphical applications inside mock fails

On Tue, 2017-09-12 at 12:35 +, Samuel Rakitničan wrote: > Hi, > > I am trying to test graphical application inside mock chroot > environment as documented on Fedora wiki [1], but I am unable to do > that successfully. In addition to that instructions I've installed > mesa-dri-drivers and

Re: Purpose of Makefile in package repository?

On Tue, 2017-10-03 at 14:48 +, Tim Landscheidt wrote: > I searched a bit in the wiki, and my sense is that at some > point in the past packages were maintained in a CVS reposi- > tory with Makefiles and that those have been replaced by Git > repositories and fedpkg. > > Is that correct? Can

Re: RFC: -Wl,--as-needed by default

On Mon, 2017-11-27 at 09:46 +0100, Jakub Jelinek wrote: > There are several problems with forceful --as-needed: > 1) forcing it everywhere is a workaround to broken tools that add -l* > options just in case (like auto*, libtool, pkg-config) pkg-config isn't broken here. Individual pc files might

Re: Fedora 27 ships with outdated intel driver from 20160929

On Wed, 2017-10-25 at 09:04 +0200, Clemens Eisserer wrote: > Hi there, > > For Fedora 26 (or was it 25) it was decided to replace the > intel-optimized xorg-x11-drv-intel with the generic > modesetting+glamor > approach. > While this works well for >= Sandy-Bridge (gen6) based chips, I >

Re: F29 System Wide Change: i686 Is For x86-64

On Mon, 2018-06-04 at 08:59 -0500, Ian Pilcher wrote: > On 06/04/2018 04:28 AM, Florian Weimer wrote: > > It should, because -march=x86-64 implies just SSE2 and FXSR, and Xeon MP > > supports both. But the intent is what the subject says: i686 binaries > > are for running legacy software on

Re: F29 System Wide Change: i686 Is For x86-64

On Tue, 2018-06-05 at 13:20 -0500, Dennis Gilmore wrote: > as part of this change I suspect we would need to make kernel changes > to stop building a i686 kernel, and all i686 deliverables would stop > being made. We would? - ajax ___ devel mailing

Re: F29 System Wide Change: i686 Is For x86-64

On Mon, 2018-06-04 at 10:35 +0200, Jan Kurik wrote: > == Scope == > * Proposal owners: > Adjust the redhat-rpm-config, gcc, and glibc packages to switch to the > new compiler flags. Except for mstackrealign, there is substantial > experience with this configuration downstream. Does this change

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

On Mon, 2018-06-04 at 16:04 +0200, Florian Weimer wrote: > > > This proposal suggests to accept this reality and build the i686 > > > packages in such a way that they require the ISA level of (early) > > > x86-64 CPUs. > > > > On which x86 CPU families will Fedora continue to work? > > Based on

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

On Mon, 2018-06-04 at 17:21 +0200, Florian Weimer wrote: > On 06/04/2018 05:07 PM, Adam Jackson wrote: > > On Mon, 2018-06-04 at 16:04 +0200, Florian Weimer wrote: > > > > > > > This proposal suggests to accept this reality and build the i686 > > > >

Re: F28 System Wide Change: Hardening Flags Updates for Fedora 28

On Thu, 2018-01-04 at 14:28 +0100, Jan Kurik wrote: > = System Wide Change: Hardening Flags Updates for Fedora 28 = > https://fedoraproject.org/wiki/Changes/HardeningFlags28 > > Change owner(s): > * Florian Weimer > > > This system-wide change covers changes to the hardening flags in > Fedora

Re: F28 System Wide Change: Removal of Sun RPC Interfaces From glibc

On Tue, 2018-01-09 at 12:25 +0100, Florian Weimer wrote: > On 01/09/2018 11:00 AM, Petr Pisar wrote: > > On 2018-01-05, Florian Weimer wrote: > > >perl-PDL-2.18.0-4.fc27.src.rpm > > > > [...] > > > This is based on relatively current Fedora rawhide/x86_64 and reflects > >

Re: Issues in F26 that bug me

On Sun, 2018-01-14 at 11:02 -0800, Howard Howell wrote: > 3. Wyland!!??!!! I liked X. It worked! Wyland has some > quirks, including the inability to run some kinds of video cards, like > Nvidia, and while it was brutal before, at least you could get it > working. Now Wayland works about

Re: RFC: Alternative -devel packaging

On Tue, 2018-08-07 at 18:25 +0100, Sérgio Basto wrote: > In my point of view, in opencv package , sdk should require -devel not > the inverse I'm not so much concerned with the _names_ of the subpackages, as with the idea of packaging the same files in multiple packages and being careful with

RFC: Alternative -devel packaging

Consider a library like libGL. At runtime, you want the drivers it might load to be installed. But when building an application, you just need the library itself. If the drivers themselves have non-trivial dependencies, the buildroot is more likely to fail to compose. The problem, in a sense, is

Re: RFC: Alternative -devel packaging

On Tue, 2018-08-28 at 13:47 +0200, Nicolas Mailhot wrote: > Le 2018-08-07 17:33, Adam Jackson a écrit : > > Consider a library like libGL. At runtime, you want the drivers it > > might load to be installed. But when building an application, you just > > need the library i

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

On Tue, 2018-08-28 at 00:03 +0200, Till Maas wrote: > waffle orphan 24 weeks ago Dependency for piglit, taken. - ajax ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an

Re: F28 System Wide Change: Removal of Sun RPC Interfaces From glibc

On Mon, 2018-01-22 at 19:19 +0100, Florian Weimer wrote: > On 01/22/2018 06:26 PM, Adam Jackson wrote: > > > > I'm trying to prepare xserver for this change, and it seems to provoke > > an awkward warning when building on F27: > > > > In file included from ../os

Re: F28 System Wide Change: Removal of Sun RPC Interfaces From glibc

On Fri, 2018-01-05 at 12:19 +0100, Jan Kurik wrote: > = System Wide Change:Removal of Sun RPC Interfaces From glibc = > https://fedoraproject.org/wiki/Changes/SunRPCRemoval > > Change owner(s): > * Florian Weimer fweimer AT redhat DOT com> > > > This system-wide change covers the removal of

Re: F28 System Wide Change: Removal of Sun RPC Interfaces From glibc

On Tue, 2018-01-23 at 08:00 +0100, Florian Weimer wrote: > On 01/22/2018 10:15 PM, Adam Jackson wrote: > > On Mon, 2018-01-22 at 19:19 +0100, Florian Weimer wrote: > > > Redeclarations in system headers are expected. Do you compile with > > > -Wsystem-headers? Or

Re: F28 System Wide Change: Removal of Sun RPC Interfaces From glibc

On Tue, 2018-01-23 at 09:17 +0100, Florian Weimer wrote: > On 01/23/2018 08:59 AM, Yaakov Selkowitz wrote: > > Is this another reason to move the headers out of > > /usr/include/tirpc, > > once glibc no longer provides conflicting headers? > > Seems worth a try. Unlike /usr/include/rpcsvc,

Re: Call for testing of xserver 1.20 release candidates

On Tue, 2018-03-06 at 12:57 +, Leigh Scott wrote: > > On Mon, 2018-03-05 at 18:03 +0100, Kalev Lember wrote: > > > > Much as I would like to, the change process does exist, and says it's > > far too late for that for F28 gold. > > Can't new Xorg wait till F29?, isn't this change to big and

Re: Recommended way to pass CFLAGS/LDFLAGS through libtool

On Mon, 2018-04-09 at 11:15 -0500, Yaakov Selkowitz wrote: > True, if you need to preserve order you need to use -Wl, for each such > argument, e.g.: > > libdemo_la_LDFLAGS = -Xlinker --as-needed -Xlinker -lm -Xlinker > --no-as-needed -lvirt > > or: > > libdemo_la_LDFLAGS =

Call for testing of xserver 1.20 release candidates

Short version: $ sudo dnf copr enable ajax/upstream $ sudo dnf upgrade Long version: I've set up a copr containing a rebuild of the X server and drivers for the upstream 1.20 release candidates. Unfortunately the upstream and Fedora schedules didn't line up as well as I'd have liked, so I'm not

Re: Call for testing of xserver 1.20 release candidates

On Mon, 2018-03-05 at 18:03 +0100, Kalev Lember wrote: > On 03/05/2018 05:48 PM, Adam Jackson wrote: > > Short version: > > > > $ sudo dnf copr enable ajax/upstream > > $ sudo dnf upgrade > > > > Long version: > > > > I've set up a co

Re: Using LTO for Fedora package builds

On Sun, 2018-02-25 at 13:19 +0100, Florian Weimer wrote: > On 02/25/2018 12:45 PM, Zbigniew Jędrzejewski-Szmek wrote: > > > What's our current take on using LTO for Fedora package builds? > > systemd would like to use it. > > Why? What are the benefits? I've seen a couple of cases where LTO

Re: CVE-2018-14665 : Xorg X Server Vulnerabilities

On Thu, 2018-11-01 at 16:33 +0200, Cătălin George Feștilă wrote: > https://www.securepatterns.com/2018/10/cve-2018-14665-xorg-x-server.html Forgive me, it's been a stressful week. https://bodhi.fedoraproject.org/updates/FEDORA-2018-839720583a

Re: CVE-2018-14665 : Xorg X Server Vulnerabilities

On Thu, 2018-11-01 at 13:08 -0500, Chris Adams wrote: > Once upon a time, Jiri Eischmann said: > > I wonder if Fedora has even been affected. I was not able to reproduce > > the exploit on Fedora 29 Workstation (with Xorg older than the one > > fixing the issue). > > IIRC F29 Workstation uses

Re: Intent to orphan coan

On Wed, 2018-09-19 at 00:02 +0100, Jonathan Underwood wrote: > I don't have the time to continue maintaining this package, > unfortunately. Please get in touch if you want to maintain the > package and I'll hand it over to you. I use coan fairly regularly, it seems to get a lot of things right

Re: /usr/include/GL/glext.h:467:10: fatal error: KHR/khrplatform.h: No such file or directory

On Mon, 2018-12-10 at 09:23 +, Samuel Rakitničan wrote: > Hi, > > Got an e-mail from Koschei [1] with a notice that camotics package is > starting to fail to build. The reason for this seems to be that > something that used to pull mesa-libEGL-devel doesn't do so anymore. > >

Re: "Basic graphics mode" feature and criterion discussion

On Tue, 2019-03-26 at 11:14 -0700, Adam Williamson wrote: > The justification for this is, I hope I am correctly representing all > views here (please say so if not), that this mechanism is both less > necessary (due to a general reduction in the amount of 'weird' graphics > hardware out there,

Re: GCC9 bug on ppc64le ? or why just fail in ppc64le rawhide?

On Fri, 2019-02-22 at 19:59 +, Sérgio wrote: > Add -fsigned-char fix the build thanks, I still not understood, why > only ppc64le and GCC 9 I can't speak to the gcc9 part, but this would probably have failed on aarch64 and s390x as well, you just didn't notice because those aren't arches in

Re: F30 Self-Contained Change proposal: Retire YUM 3

On Mon, 2019-01-28 at 12:27 -0500, Ben Cotton wrote: > == Detailed Description == > Remove packages from the distribution: > * createrepo > * yum > * yum-langpacks > * yum-utils > * yum-metadata-parser > * yum-updatesd > * python-urlgrabber > > All these packages should no longer be used and all

Re: Destop environment and gl performance...

On Wed, 2019-05-29 at 19:45 +0200, Theodore Papadopoulo wrote: > Can someone explain why the destop environment (here Cinnamon) can have > such an impact on the graphic card performance ? Because (I suspect) you're not measuring glmark2 --off-screen, which means the output that glmark

Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression

On Wed, 2019-05-29 at 16:19 -0400, Ben Cotton wrote: > * Faster koji builds (installations in build roots) The numbers here seem to indicate that you'll have faster koji build _setup_. But getting comparable compression rates as xz means spending (apparently) significantly more time at

Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression

On Thu, 2019-05-30 at 12:20 -0400, Adam Jackson wrote: > - What's the mean and/or median size of an rpm in Fedora, and what > difference in {de,}compression time would that likely experience? Just to follow up on this since it was quick to math out. For Fedora 30's x86_64 repo, various &qu

Stale packages in Fedora 30

Since I was looking at a copy of the F30 repo for amd64, here's a list of a bunch of packages whose dist tag suggests they haven't rebuilt successfully in any currently-supported Fedora release. I'm sure some of these are incompletely retired or there's otherwise some good reason for it, this is

Re: Fedora 32 System-Wide Change proposal: Retire Python 2

On Thu, 2019-04-25 at 21:13 +0200, Miro Hrončok wrote: > On 25. 04. 19 20:33, Adam Jackson wrote: > > On Thu, 2019-04-25 at 19:33 +0200, Miro Hrončok wrote: > > > On 25. 04. 19 18:38, Nico Kadel-Garcia wrote: > > > > How much is going to be needed for

Re: vsync in VM?

On Thu, 2019-05-02 at 17:05 +0200, Kamil Paral wrote: > Hello, > > I wonder whether it's expected that vsync doesn't work in VMs. I've > tested Fedora 28/29/30 Workstation and Fedora 30 KDE guests on Fedora > 30 host, with virtio GPU (3D acceleration on and off) or QXL GPU, and > in all cases,

Re: Fedora 32 System-Wide Change proposal: Retire Python 2

On Thu, 2019-04-25 at 19:33 +0200, Miro Hrončok wrote: > On 25. 04. 19 18:38, Nico Kadel-Garcia wrote: > > > > How much is going to be needed for "mock" to still work for older > > operating systems? > > I'm confused. How is the change relevant for mock? I think I'm missing some > pieces of the

RFC: switch to uvesafb and drop openchrome in F31+

I'm considering changing the vesa support code in future Fedora releases, for a few reasons. I think this will both simplify the support burden for developers, and increase the number of supported video configurations in practice. But it's not clear-cut, hence this email. The fallback video path

Re: About to orphan FreeGLUT

On Tue, 2019-09-17 at 15:12 +, Gwyn Ciesla via devel wrote: > I'd love to see this not go away. If you can't find another volunteer > before you orphan, I'll take it, FAS: limb. If someone with more > experience with it steps up, give it to them. I can't have mesa-demos break so I'm happy to

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

On Mon, 2019-07-22 at 14:51 -0400, Ben Cotton wrote: > After preliminary discussions with CPU vendors, we propose AVX2 as the > new baseline. AVX2 support was introduced into CPUs from 2013 to > 2015. See > [https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2 > CPUs with

Re: ownership of /proc and /sys

On Tue, 2019-07-23 at 11:01 +0200, Miroslav Suchý wrote: > Hi, > directories /proc/ and /sys/ are owned by filesystem package. This worked in > past where we needed those directories to > exist so we can mount the procfs and sysfs. > > However this cause issues in containers: >

Re: Minimization Objective report

On Wed, 2019-11-20 at 02:53 +0100, Kevin Kofler wrote: > Adam Jackson wrote: > > That's about 44M worth of potential savings out of a 204M base image, a > > bit over 20%. I'll happily file proper bug reports for these somewhere > > if we want, but it took me li

Re: request: Please revive beignet!

On Fri, 2019-11-01 at 00:18 +, Sérgio Basto wrote: > On Fri, 2019-11-01 at 08:06 +0900, Tetsuji Rai wrote: > > Hi all, > > > > I've been using Fedora for a long time, but I was at lost to see there's > > no beignet supported in Fedora 30. But fortunately, archlinux had > > source patches for

Re: Minimization Objective report

On Fri, 2019-11-15 at 23:38 +0100, Kevin Kofler wrote: > Adam Samalik wrote: > > 1/ A history chart for base images [2] is now being generated — includes > > data since 25 September. It's a bit rough initial implementation, but it's > > there! > > Almost 2 months of work to save… 0.5%! That does

Re: FreeGLUT update with soname bump

On Fri, 2019-10-04 at 13:23 +, Gwyn Ciesla via devel wrote: > Hi! I'll be updating FreeGLUT to 3.2.1 today. Since this includes a > soname bump, I'll do so with a chained rebuild for: > > mesa I think you mean mesa-demos for the source package here. mesa proper doesn't link to glut. - ajax

Re: deduplicating noarch subpackages

On Tue, 2020-02-11 at 16:21 -0800, Josh Stone wrote: > Another alternative is to try to remove the host information from the > metadata hash, which I've already started upstream[3], but I'm not sure > alleviate their concerns about caching and such. > > [3]

Possible gcc/s390x bug (was Re: Mass rebuild status)

On Sat, 2020-02-01 at 16:59 -0800, Kevin Fenzi wrote: > See > https://kojipkgs.fedoraproject.org/mass-rebuild/f32-failures.html > and > https://kojipkgs.fedoraproject.org/mass-rebuild/f32-need-rebuild.html > > for detailed lists of what needs rebuilding and what failed. libXt's failure on

Re: Fedora 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

On Mon, 2020-01-13 at 10:52 +0100, Florian Weimer wrote: > * Kevin Fenzi: > > > Can packages built in this buildroot be used on the same system with > > packages from the normal buildroot? > > Yes, I expect them to be compatible at the interface level because the > flags do not directly alter

Re: Fedora 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

On Fri, 2020-01-10 at 11:05 +0100, Florian Weimer wrote: > * Neal Gompa: > > > On Fri, Jan 10, 2020 at 4:28 AM Florian Weimer wrote: > > > We do not want to change the RPM architecture, so that users still can > > > install third-party software. This means that we need to change the > > > dist

Re: Urgently downgrade xorg-x11-drv-intel

On Fri, 2020-04-10 at 15:35 +0200, Olivier Fourdan wrote: > On Fri, Apr 10, 2020 at 3:24 PM Alexei Podtelezhnikov > wrote: > > >> > > >> Is koji still fc31? My problematic rebuilds are obviously fc32. > > > > > > > > > All the scratch builds I spawned for this issue are for F32 of course. > > >

Re: Urgently downgrade xorg-x11-drv-intel

On Mon, 2020-04-06 at 13:46 -0400, Alexei Podtelezhnikov wrote: > > > On Mon, Apr 6, 2020 at 12:57 PM Adam Jackson wrote: > > But the driver we default to on all the newer Intel chips should work > > on yours too, though I'm not entirely sure whether you'll end u

Re: Urgently downgrade xorg-x11-drv-intel

On Mon, 2020-04-06 at 09:27 -0400, Alexei Podtelezhnikov wrote: > Hi All, > > Please urgently downgrade xorg-x11-drv-intel before shipping Fedora 32 and > spare users some pain. At least two very recent crash/segfault reports are > fixed by downgrading to the fc31 version of xorg-x11-drv-intel.

<    1   2   3   4   5   6   7   >