Re: F37 Change: Legacy Xorg Driver Removal (System-Wide Change proposal)

On Thu, Apr 21, 2022 at 10:10 AM Adam Jackson wrote: > > On Wed, Apr 20, 2022 at 6:06 PM Kevin Kofler via devel > wrote: > > > > Adam Williamson wrote: > > > Right now it's not entirely clear whether this is considered part of > > > the Change scope o

Re: F37 Change: Legacy Xorg Driver Removal (System-Wide Change proposal)

On Wed, Apr 20, 2022 at 6:06 PM Kevin Kofler via devel wrote: > > Adam Williamson wrote: > > Right now it's not entirely clear whether this is considered part of > > the Change scope or not. The paragraph about the `uvesafb` driver seems > > kind of aspirational and doesn't seem to commit to

Re: F37 Change: Legacy Xorg Driver Removal (System-Wide Change proposal)

> == Summary == > > This change will remove the `xorg-x11-drv-vesa` and > `xorg-x11-drv-fbdev` driver packages, and associated support code from > the `xorg-x11-server-Xorg` package. > > == Owner == > * Name: [[User:ajax|Adam Jackson]] > * Email: a...@redhat.com > > >

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

On Tue, Apr 5, 2022 at 6:51 PM Demi Marie Obenour wrote: > > I'm flattered, but I intend to drop vesa in F37 regardless of the > > outcome of this particular change. The only supported way to get to > > graphics with vesa is to use Xorg, and we sincerely want to be out of > > the business of

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

On Tue, Apr 5, 2022 at 4:01 PM Sebastian Crane wrote: > If the installation media can not install onto BIOS-only machines yet > all the bootloader stages support BIOS, then there will be an awkward > stage where some existing Fedora installations can be upgraded, but if > anything goes wrong

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

On Tue, Apr 5, 2022 at 11:18 AM Ben Cotton wrote: > While this will eventually reduce workload for boot/installation > components (grub2 reduces surface area, syslinux goes away entirely, > anaconda reduces surface area), the reduction in support burden > extends much further into the stack -

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

On Tue, Apr 5, 2022 at 3:15 PM Neal Gompa wrote: > We also lack solutions for dealing with the NVIDIA driver in > UEFI+Secure Boot case. Are you planning to actually *fix* that now? > Because we still don't have a way to have kernel-only keyrings for > secure boot certificates to avoid importing

Re: FESCo wants to know what you use i686 packages for

On Thu, Mar 17, 2022 at 6:25 AM Richard W.M. Jones wrote: > > On Thu, Mar 17, 2022 at 11:10:12AM +0100, Florian Weimer wrote: > > * Richard W. M. Jones: > > > > > On Wed, Mar 16, 2022 at 07:27:05PM -0400, Demi Marie Obenour wrote: > > >> Native compilation on 32-bit is a dead end. > > > > > > And

Re: FESCo wants to know what you use i686 packages for

I have a bunch of old Loki game ports I'd prefer keep working. I also have some backburner projects that need enough 32-bit userspace to run old binary drivers, but tbh it's probably easier to just use like el7 for that at this point. To the extent we keep i686 builds [1] I really think they need

Re: Documentation for F15's "Remove SETUID" Change?

On Wed, Mar 2, 2022 at 7:15 PM Steve Grubb wrote: > As someone involved in that change, the situation was much worse back in > 2011. Almost everything was running as root. The inspection tools back then > were non-existent, which is what I wrote pscap and netcap. > > Now, a lot of things use

Orphaned X11 packages

The following packages, previously owned by xgl-maint, are now up for grabs: xorg-x11-xfs xorg-sgml-doctools xorg-x11-drv-v4l xorg-x11-xsm xorg-x11-twm xorg-x11-drv-sisusb xorg-x11-xdm xorg-x11-docs Upstream development on all of these is pretty much nil, so if you're serious about picking up

Orphaned package: imake

I ported X off of imake a bit over 16 years ago but apparently there's still 20-odd packages that use it. I don't have the bandwidth or interest to maintain it, so someone who does is welcome to pick it up. - ajax ___ devel mailing list --

Re: Xorg utility deaggregation changes and updates

Spoke too soon, some other build failures that don't look like my fault: ddd: https://koji.fedoraproject.org/koji/taskinfo?taskID=48032896 gdm: https://koji.fedoraproject.org/koji/taskinfo?taskID=48033123 - ajax ___ devel mailing list --

Xorg utility deaggregation changes and updates

I've gone through (almost) every package I could find that depended on one of the xorg-x11-* superpackages and fixed them up as best I could. Here's how that went. lxde-common has been switched to explicitly require xprop from xorg-x11-utils, but still explicitly requires xorg-x11-server-utils

Re: X.org Utility Deaggregation - Fedora 33 Self-Contained Change proposal

On Sat, Jul 11, 2020 at 6:22 AM Zbigniew Jędrzejewski-Szmek wrote: > Repoquery: > $ for i in xorg-x11-{apps,font-utils,server-utils,utils,xkb-utils}; do echo > == $i; dnf repoquery --whatrequires $i; echo; done This is a bit of an overcount since you're not using --exactdeps. datura:~% for i

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 16:28 -0400, Paul Dufresne via devel wrote: > Le 20-04-06 à 15 h 34, Adam Jackson a écrit : > > On Mon, 2020-04-06 at 13:46 -0400, Alexei Podtelezhnikov wrote: > > > Xorg does not start without xorg-x11-drv-intel on GMA 3150. OpenGL > >

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.

Re: @core install picking up desktop packages

On Thu, 2020-04-02 at 13:24 -0400, Steve Grubb wrote: > Hello, > > I've been doing some testing of F32 and was curious about something. I have a > kickstart file that just installs @core to be a minimal system. While looking > over the resulting system, there are fonts, wayland, gtk3 and

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

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

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: 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: 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 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: 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: "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: /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: 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: 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: 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: 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: 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: 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: 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: 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: [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: [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: 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: 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 =

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

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

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

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

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

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

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

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

  1   2   3   4   5   6   7   >