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

[Adam Jackson]

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 or not. The paragraph about the `uvesafb` driver seems
> > > kind of aspirational and doesn't seem to commit to anything. The
> > > "Benefit to Fedora" section states "Verified modern supported paths for
> > > cases currently handled by vesa/fbdev", but I'm not 100% clear what is
> > > meant by that.
> >
> > IMHO, it is not acceptable to remove the vesa driver without having
> > something like uvesafb to replace it.
>
> I like how I'm being told _not_ to find out where the remaining bugs
> are in our native drivers, and instead preserve something awful for
> eternity.

Turns out the support story is less bad than I thought, the simpledrm
change was more powerful than I knew. I've updated the change again
but the short story is vga= on kcmdline will give you just as good of
support as UEFI framebuffer.

- ajax
___
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: F37 Change: Legacy Xorg Driver Removal (System-Wide Change proposal)

[Adam Jackson]

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 anything. The
> > "Benefit to Fedora" section states "Verified modern supported paths for
> > cases currently handled by vesa/fbdev", but I'm not 100% clear what is
> > meant by that.
>
> IMHO, it is not acceptable to remove the vesa driver without having
> something like uvesafb to replace it.

I like how I'm being told _not_ to find out where the remaining bugs
are in our native drivers, and instead preserve something awful for
eternity.

- ajax
___
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: F37 Change: Legacy Xorg Driver Removal (System-Wide Change proposal)

[Adam Jackson]

Apologies for the delay here, but I've updated the change proposal
page based on the feedback in this thread. Please let me know what you
think.

- ajax

On Thu, Apr 7, 2022 at 4:10 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/LegacyXorgDriverRemoval
>
>
> == 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
>
>
> == Detailed Description ==
>
> Fedora's primary desktop environments are moving away from being X11
> sessions, to being Wayland servers in their own right. This transition
> is incomplete, and the Xorg server is still potentially used in a
> variety of "fallback" situations. In particular the `vesa` and `fbdev`
> drivers can find themselves pressed into use when accelerated graphics
> is unavailable. Both of these drivers are somewhat deprecated
> upstream, and the code to reach them is increasingly fragile as it
> gets exercised less and less.
>
> This change will identify the remaining configurations that can reach
> these drivers, establish an alternative for display support for each
> configuration, and then remove the drivers and their support code in
> xserver.
>
> == Feedback ==
>
> None yet.
>
> == Benefit to Fedora ==
>
> * Verified modern supported paths for cases currently handled by vesa/fbdev
> * Simpler support/testing matrix for QE
> * One less reason to need Xorg installed at all
>
> == Scope ==
> * Proposal owners: ajax needs to audit hardware support matrix for
> cases that can hit these drivers, and the rest of the OS for places
> that can configure them.
>
> * Other developers: Maintainers of other affected components may need
> to incorporate some changes, and may wish to look for additional
> support code that can be dropped.
>
> * Release engineering: This is mostly ensuring that the two driver
> packages are indeed dropped from the compose, etc.
>
> * Policies and guidelines: N/A (not needed for this Change) Although
> this is a system-wide change I don't think there's any real policy
> impact.
>
> * Trademark approval: N/A (not needed for this Change)
>
> * Alignment with Objectives: Yes, we'd be arguably the First to try this.
>
> == Upgrade/compatibility impact ==
>
> For an upgraded system to notice this change, it would need to be
> already using one of these drivers. For cases we can identify where
> this would happen without explicit configuration, we will ensure the
> display is enabled by some other path or documented as no longer
> supported. However, for cases where the driver is set explicitly in
> `xorg.conf`, there is no obviously correct remedy that we could do
> automatically, and the user will need to fix their X configuration
> manually.
>
> == How To Test ==
>
> This should fall out naturally from the normal release testing
> process, but we'll expand the details here as the various
> configurations are tested and fixed.
>
> == User Experience ==
>
> This change should be largely invisible, but there will likely be
> observable changes (for instance, if you end up using a Wayland
> session, `$WAYLAND_DISPLAY` will likely no longer be empty). These
> will be documented here as we fix the individual cases.
>
> == Dependencies ==
>
> The kernel may need changes to add more drivers for more situations.
>
> The installer and other system-wide configuration tools should be
> audited to ensure they don't emit cases that can force vesa/fbdev.
>
> The major desktop environments may need to be fixed to handle more
> cases, and may wish to drop code to support the old cases.
>
> == Contingency Plan ==
>
> * Contingency mechanism: ajax reverts the changes.
> * Contingency deadline: Beta freeze seems fine.
> * Blocks release? No. Partial completion is possible.
>
> == Documentation ==
>
> Just this page so far.
>
> == Release Notes ==
>
> None yet.
>
>
> --
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> 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-i

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

[Adam Jackson]

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 maintaining Xorg the hardware server. (We'll need an X
> > server forever, Xwayland isn't going away, don't misread me here.)
>
> Does that mean that F37 will only have an Xwayland package, not an
> Xorg package?  And does it mean that XFCE support is being deprecated?
> Qubes OS relies on the latter.

I chose my words carefully, I said "drop vesa" not "drop Xorg". It
means F37 will not have a vesa driver for the Xorg server to use. Xorg
will still be there for at least another release, probably several.

It's likely that the long term plan for preserving X11-only desktop
environments would be to run (say) weston such that its only client is
a fullscreen Xwayland, rather than Xorg driving the hardware directly.

> > And frankly at this point if you seriously want to use vesa it's
> > because you're trying to like reverse engineer some obscure card's
> > VBIOS, and if you're doing that you're probably building your own X
> > server anyway, I know I would be. Its use as an emergency driver on
> > physical GPUs is negligible, we have native drivers for virtually
> > everything made in the last 20 years. Its use as an emergency driver
> > in virtual machines is more statistically significant, maybe, but even
> > there we usually have a drm driver these days, and where we don't we
> > can probably club it into bochs_drm since that's the only rom anyone
> > bothers to use for that.
>
> Do we have DRM drivers for the UEFI framebuffer and the standard
> QEMU-emulated graphics?

Yes.

- ajax
___
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: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Adam Jackson]

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 it'd be impossible to reinstall them! The lack of a
> BIOS installer as a fallback would make running Fedora on BIOS-only
> machines risky enough that it seems to me as no better than removing
> support entirely. Could I missing something here?

If I were interested in keeping BIOS machines installable, I'd
probably just rebuild the F36 installer every so often, pointing it at
newer repos by default each time. Long term that might be a little
weird - if the installed system stops knowing about BIOS partition
tables you might end up with a machine unable to inspect its own disk
layout from like gnome-disks - but...

- ajax
___
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: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Adam Jackson]

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 - for instance, VESA support can
> be removed from the distro.

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 maintaining Xorg the hardware server. (We'll need an X
server forever, Xwayland isn't going away, don't misread me here.)

And frankly at this point if you seriously want to use vesa it's
because you're trying to like reverse engineer some obscure card's
VBIOS, and if you're doing that you're probably building your own X
server anyway, I know I would be. Its use as an emergency driver on
physical GPUs is negligible, we have native drivers for virtually
everything made in the last 20 years. Its use as an emergency driver
in virtual machines is more statistically significant, maybe, but even
there we usually have a drm driver these days, and where we don't we
can probably club it into bochs_drm since that's the only rom anyone
bothers to use for that.

- ajax
___
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: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Adam Jackson]

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 them into the firmware.

Couple of thoughts, here:

1 - This is a non sequitur to the question of removing BIOS support,
because Secure Boot is not a BIOS feature, so nobody relying on Secure
Boot today would stand to lose anything.

2 - How is this our problem to solve? NVIDIA are the ones with the
private source code.

3 - Your complaint describes solution: import NVIDIA's signing key
into your firmware. If you want both Secure Boot and nvidia.ko so
badly, then you as the consumer need to tell your platform to trust
what NVIDIA signs. If that's a burden, again, see point 2 about who
exactly is making your life hard here. Remedies there might include
some UI streamlining around mokutil, or getting nvidia and nouveau to
use the same (open) kernel driver so the question just goes away.

- ajax
___
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: FESCo wants to know what you use i686 packages for

[Adam Jackson]

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 I was going to add that this is wrong - 32 bit chroots running on
> > > 64 bit hosts work fine and run at full speed.
> >
> > No, not for everyone, they don't.  Some Fedora packages need more than a
> > 32-bit address space to build, and that becomes more and more common.
>
> This is true, but what proportion of packages does this really affect?
> Also it's stuff like Firefox that we wouldn't want to compile for 32 bit
> anyway.

See my earlier comment about llvm and OpenGL.

- ajax
___
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: FESCo wants to know what you use i686 packages for

[Adam Jackson]

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 to be
emitted from a 64-bit toolchain. I'm sympathetic to the argument that
you shouldn't run a 32-bit web browser anyway, so I don't care _so_
much about linking like firefox or webkit. But something like llvm
finds its way into the runtime for a lot of things, like the GL
drivers that provide the compatibility with the game you're trying to
run, and it's goofy to need to work around 32-bit address space
limitations just to link a 32-bit libLLVM. Building with gcc.i686 is a
choice we don't need to make.

[1] - My personal opinion here is we should try a little harder than
necessary, because I think that kind of compatibility is a worthwhile
goal, but also the specific things you need the compatibility have
boundaries and 100% coverage for 32-bit builds is pointless.

- ajax

On Wed, Mar 16, 2022 at 9:54 AM David Cantrell  wrote:
>
> Hi,
>
> Our most recent FESCo meeting involved discussing the proposal to drop i686
> builds of jdk8,11,17 from Fedora 37 onward.  The topic quickly changed to the
> larger question of "what do people use i686 packages for?"
>
> Rather than guess, we wanted to ask the community what you use i686 packages
> for in Fedora.  There are no wrong answers here.  We are seeking information.
>
> Why?  Since the removal of the i686 kernel in Fedora, we want to reduce the
> number of i686 packages provided in the repo.  As time marches on, the ability
> to build a lot of things for i686 becomes unrealistic or even impossible.
> Remember it goes beyond providing builds...providing support, bug fixes, and
> security fixes for those packages too.  Maybe some things using i686 packages
> now can move to x86_64 packages.  We do not know yet, but a goal is to figure
> out what packages, if anything, can drop their i686 builds.
>
> NOTE: Nothing is changing now.  We are in an information gathering phase.
>   
>
> If you use i686 packages for something now, please respond to this thread.
>
> Thanks,
>
> --
> David Cantrell 
> Red Hat, Inc. | Boston, MA | EST5EDT
> ___
> 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
___
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: Documentation for F15's "Remove SETUID" Change?

[Adam Jackson]

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 capabilities with a few still running as root when
> they don't need to be. [...]

Not... really. grep is telling me there are 22 spec files that say
%cap and 63 that match /%attr.4/.

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

Orphaned X11 packages

[Adam Jackson]

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 any of these you may also wish to take on the
module upstream:

https://gitlab.freedesktop.org/xorg

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

Orphaned package: imake

[Adam Jackson]

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 -- 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: Xorg utility deaggregation changes and updates

[Adam Jackson]

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

Xorg utility deaggregation changes and updates

[Adam Jackson]

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
despite that AFAICT it never mentions any of the utilities therein. I
assume this is a packaging convenience, the package owner would need
to decide which pieces of -server-utils are really wanted.

i3 has a Recommends for xorg-x11-apps but the package itself does not
ever mention any of the apps contained therein. I'm leaving it alone,
the package owner can decide the intent there.

The following packages failed to rebuild, for what look to be unrelated reasons:

calamares: https://koji.fedoraproject.org/koji/buildinfo?buildID=1555141
fltk: https://koji.fedoraproject.org/koji/taskinfo?taskID=48031944
squeak-vm: https://koji.fedoraproject.org/koji/buildinfo?buildID=1555076
sugar-artwork: https://koji.fedoraproject.org/koji/buildinfo?buildID=1555075
xastir: https://koji.fedoraproject.org/koji/buildinfo?buildID=1555072

I have not yet started to detangle xorg-x11-font-utils, it has some
subtle interaction with the xserver build system that I think can be
simplified better.

- ajax
___
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: X.org Utility Deaggregation - Fedora 33 Self-Contained Change proposal

[Adam Jackson]

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 in
xorg-x11-{apps,font-utils,server-utils,utils,xkb-utils}; do echo ==
$i; dnf -q repoquery --exactdeps --whatrequires $i --qf %{sourcerpm} |
sort -u; echo; done
== xorg-x11-apps
arcem-1.50.2-6.fc31.src.rpm
ddd-3.3.12-33.fc31.src.rpm
freenx-server-0.7.3-47.fc31.src.rpm
squeak-vm-4.10.2.2614-22.fc31.src.rpm
xmonad-0.15-3.fc31.src.rpm

== xorg-x11-font-utils
nethack-3.6.6-1.fc31.src.rpm
nx-libs-3.5.99.24-1.fc31.src.rpm
urw-base35-fonts-20170801-13.fc31.src.rpm

== xorg-x11-server-utils
arandr-0.1.10-1.fc31.src.rpm
classification-banner-1.7.0-4.fc31.src.rpm
gdm-3.34.1-1.fc31.src.rpm
i-nex-7.6.1-1.fc31.src.rpm
lutris-0.5.7-1.fc31.src.rpm
lxde-common-0.99.2-8.fc31.src.rpm
lxrandr-0.3.2-2.fc31.src.rpm
ocaml-camlimages-4.2.5-11.fc31.src.rpm
plasma-workspace-5.18.5-2.fc31.src.rpm
urw-base35-fonts-20170801-13.fc31.src.rpm
xfce4-session-4.14.2-1.fc31.src.rpm
xkeycaps-2.46-26.fc31.src.rpm

== xorg-x11-utils
backintime-1.2.0-6.fc31.src.rpm
boswars-2.7-19.svn160110.fc31.src.rpm
compiz-manager-0.7.0-9.fc31.src.rpm
compton-0.1-0.5.beta3.fc31.src.rpm
cros-guest-tools-1.0-0.35.20200611git5ab8724.fc31.src.rpm
ddd-3.3.12-33.fc31.src.rpm
gnome-shell-extension-unite-8-5.fc31.src.rpm
gyazo-1.2-9.fc31.src.rpm
inxi-3.1.03-1.fc31.src.rpm
java-atk-wrapper-0.33.2.1-0.pre01.fc31.src.rpm
kodi-18.6-1.fc31.src.rpm
lxde-common-0.99.2-8.fc31.src.rpm
plasma-workspace-5.18.5-2.fc31.src.rpm
surf-2.0-8.fc31.src.rpm
wallpapoz-0.6.2-11.fc31.src.rpm

== xorg-x11-xkb-utils
bicon-0.5-9.fc31.src.rpm
calamares-3.2.11-7.fc31.src.rpm
ibus-1.5.21-9.fc31.src.rpm
tigervnc-1.10.1-5.fc31.src.rpm
x2goserver-4.1.0.3-5.fc31.src.rpm

36 packages is a little more than I was hoping for, but still not bad.
I'll start going through this list to figure out what needs to change.

- ajax
___
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: Urgently downgrade xorg-x11-drv-intel

[Adam Jackson]

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.
> > 
> > I am pondering a compiler bug. Your scratch builds are fine so it
> > seems. What if you rebuild without koji on your desktop using shiny
> > Fedora 32.
> 
> Yes, I also thought of that, looks like there've been a few gcc changes 
> between the current Fedora build of xorg-x11-drv-intel and now. 
> 
> The driver works equally well if I compile locally of course (which is how I 
> figured, trying to bisect), but koji uses mock which installs the same gcc 
> version to build of course, you can see that here:
> 
> https://kojipkgs.fedoraproject.org//work/tasks/1463/43191463/root.log
> 
> Either way, good to know the scratch build works for you.
> 
> Adam, want me to launch an official build, just to rebuild?

Yes, please!

- ajax
___
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: Urgently downgrade xorg-x11-drv-intel

[Adam Jackson]

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
> > > 2.1 used to be enabled on this hardware, but got dropped
> > I think we have a fix for that. Let me poke at things a bit.
> > 
> Euh... maybe that?
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1762151#c20

Yeah, applying that makes X start, but then the screen is all black
instead of showing me anything. That seems to be true of the GLES2
glamor backend even for Xephyr on Skylake, so hopefully it shouldn't
take too much longer to figure out, and in the worst case we can
disable the GLES2 backend.

- ajax
___
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: Urgently downgrade xorg-x11-drv-intel

[Adam Jackson]

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 up with
> > working 3D acceleration. And if you uninstall xorg-x11-drv-intel,
> > you'll fall back to the modesetting driver we use on the other Intel
> > chips, so, give it a shot?
> 
> Xorg does not start without xorg-x11-drv-intel on GMA 3150. OpenGL
> 2.1 used to be enabled on this hardware, but got dropped

I think we have a fix for that. Let me poke at things a bit.

- ajax
___
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: Urgently downgrade xorg-x11-drv-intel

[Adam Jackson]

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.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1820815
> https://bugzilla.redhat.com/show_bug.cgi?id=1818972

What happens if you uninstall xorg-x11-drv-intel?

The background here is that the intel driver hasn't had a release in
(checks) wow, over five years, which means its quality at any given
point is sort of unknown. You'd hope it would be converging on a good
state, and it does seem to have an ever-slowing change rate, but you
still end up with patches getting reverted after a month:

https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/-/commit/d90a2ff1a6f338fa70fc9a110d9f7b0e622c8a57

And this mostly doesn't matter because we default to a different driver
for most Intel hardware released since about 2006, with the notable
exception of your (Alexei's) machine which was new as of about 2010.

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 up with
working 3D acceleration. And if you uninstall xorg-x11-drv-intel,
you'll fall back to the modesetting driver we use on the other Intel
chips, so, give it a shot?

- ajax
___
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: @core install picking up desktop packages

[Adam Jackson]

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 others. Is this 
> intentional? The system probably doesn't have everything that's needs to 
> function as a desktop. Why are all these installed by @core?

Because you're installing with weak dependencies enabled, and one of
them is bringing in gtk3. I haven't tried to figure out which one, I
just know dnf install --setopt=install_weak_deps=false @core didn't try
to pull in libX11.

- ajax
___
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: deduplicating noarch subpackages

[Adam Jackson]

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] https://github.com/rust-lang/cargo/pull/7873
> 
> Worst case, I could just build them as arch'ed subpackages, specific to
> the host which compiled them.

I'd lean in favor of removing at least the architecture part of the
host triple from the hash. koji is still going to build those noarch
packages on every architecture and compare them, so if you do remove
the arch from the hash and they all compare equal, it can't have
mattered which arch you built it from.

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

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

[Adam Jackson]

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 s390x seems to be repeatable, unique to that
architecture, and frankly hilarious:

PassivGrab.c: In function '_XtCheckServerGrabsOnWidget':
PassivGrab.c:292:35: error: array subscript 0 is outside array bounds of 
'XtServerGrabRec[1]' {aka 'struct _XtServerGrabRec[1]'} [-Werror=array-bounds]
  292 |  first.pMask = GRABEXT(pFirstGrab)->pModifiersMask;
PassivGrab.c:556:22: note: while referencing 'tempGrab'
  556 | XtServerGrabRec  tempGrab;
  |  ^~~~

Where GRABEXT here is just doing the standard C trick for incrementing
past the current struct and returning a (differently typed) pointer to
the data beyond:

#define GRABEXT(p) ((XtServerGrabExtPtr)((p)+1))

A scratch build, including a dump of PassivGrab.i in the build.log, can
be found here:

https://koji.fedoraproject.org/koji/taskinfo?taskID=41355653

Any ideas?

- ajx
___
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: Fedora 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

[Adam Jackson]

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 calling conventions.  There could be a
> slowdown mixing package versions, though.
> 
> It's also conceivable t hat some packages change struct layout under
> #ifdef __AVX2__, and those changes could be externally visible.  I do
> not think this is likely, though, because these packages would fail to
> run with user-compiled -march=native code today.

You could detect this automatically by running abidiff against the two
arch variants for corresponding builds. Which would be nice.

> > Would there be some kind of initial 'mass build' to populate existing
> > packages / things that don't rebuild very often?
> 
> Yes, for the VZEROUPPER change, we would have to do an initial rebuild.

Can you expand on this change? What are the tradeoffs for disabling
vzeroupper? (At least, my gcc thinks it's enabled by default.)

- ajax
___
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: Fedora 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

[Adam Jackson]

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 tag to avoid confusion.
> > > 
> > 
> > Changing the RPM architecture does not necessarily mean that you
> > wouldn't remain compatible with baseline x86_64. For example,
> > OpenMandriva's build of the distribution optimized for first
> > generation AMD Ryzen systems uses the "znver1" RPM architecture, but
> > the "znver1" architecture is deliberately considered compatible with
> > x86_64, so packages that are "x86_64" are still installable. There are
> > numerous examples of this for 32-bit x86, and there's no reason we
> > couldn't do this for 64-bit x86.
> 
> But the value of %_arch still changes, right?

I don't think that needs to be true. If I'm reading the rpm source
right (always questionable) it looks like %_arch is set from $CANONARCH
in the installplatform script, which treats ia32e and amd64 such that
$CANONARCH is still x86_64.

Granted this does mean you'd need to patch the normal (not the one in
your buildroot) rpm package to know about this architecture too, which
is maybe not ideal, or else require that installing packages from this
buildroot requires using that buildroot's rpm.

- ajax
___
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: Minimization Objective report

[Adam Jackson]

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 like 30 minutes to look into this. If you're
> > not even willing to put in _that_ little effort, then forgive me for
> > not taking your assertion that "you simply cannot win" very seriously.
> 
> I am not the one who spent 2 months gaining 0.5%…

You're right, you spend two months achieving zero towards this goal,
and complaining about what progress they _have_ made. You have provided
zero constructive feedback, and your defeatist attitude helps nobody.

Consider the option of not being gratuitously unpleasant.

- ajax
___
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: Minimization Objective report

[Adam Jackson]

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 not look like a huge 
> success to me. You simply cannot win against the creeping bloat. :-(

Ahem.

In the spirit of positivity and collaboration, I spent a few minutes
looking at the results given to try to find some easy wins. Here's what
I found:

python3-libs ships multiple copies of its pyc files, corresponding to
different optimization levels. I don't know what a good packaging
solution to that would look like, but if we only shipped the -O2 kind
(which seems appropriate for minimization, as they're smallest) we
could drop about 13M out of 32M, which seems pretty great.

About 2/3 of glib2 is translations. If it was langpacked like glibc you
could drop another 8M. Likewise about 9M out of 10M for coreutils-
common, 4.5 out of 7.5 for bash, 4 out of 10 for gnupg2.

You're not using coreutils-single, which would save you another 6M or
so.

It's hard to understand why dejavu-sans-fonts is in there, since there
are zero font libraries installed in the container base. Probably
that's brought in by the langpacks somewhere along the line, but it
seems like fonts and translations should be logically separate here (no
point installing fonts if you're not going to be printing or making
images, right?). That's another 5.5M.

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 like 30 minutes to look into this. If you're
not even willing to put in _that_ little effort, then forgive me for
not taking your assertion that "you simply cannot win" very seriously.

- ajax
___
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: request: Please revive beignet!

[Adam Jackson]

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 glibc-2.29, llvm,clang 8 and it worked on Fedora
> > 30.   However now on Fedora 31, archlinux's patch any longer works, and
> > I am obliged to use binary packages of beignet borrowed from Fedora 29. 
> > But it's old and won't held in Fedora mirrors in the near future.

This is not strictly true. koji retains the builds for things that
shipped in "gold" releases forever, so this should stick around:

https://kojipkgs.fedoraproject.org/packages/beignet/1.3.2/5.fc29/

But I agree, that's not ideal.

> > I guess there are many users still using Ivybridge or Haswell and
> > needing beignet.  Will developers support beignet?
> 
> Commit [1] says "Starting in Q1’2018, Beignet has been deprecated in
> favor of NEO OpenCL driver" 
> 
> [1] 
> https://src.fedoraproject.org/rpms/beignet/c/74628d735c9a4e6c8ac5c888adbfca0f5db282b3?branch=master

Unfortunately NEO doesn't support Ivybridge or Haswell, so that's not
much help. Likewise there's a new "iris" gallium driver in Mesa that I
think in principle could be built/loaded as an OpenCL driver, but it
too only supports Broadwell and newer.

We don't have the resources to keep beignet building with newer and
newer llvm, let alone working. If the broader community wanted to pick
up that project and run with it, that'd be awesome, but it's not
something we're likely to maintain on our own. (My personal preference
for solving this problem would be another gallium driver for gen4
through gen7, but that is admittedly also a lot of work.)

- ajax
___
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: FreeGLUT update with soname bump

[Adam Jackson]

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
___
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: About to orphan FreeGLUT

[Adam Jackson]

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

- ajax
___
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: ownership of /proc and /sys

[Adam Jackson]

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:
> https://bugzilla.redhat.com/show_bug.cgi?id=1548403
> and during building where hacks are needed:
> https://github.com/rpm-software-management/mock/pull/234/commits/d7e0b413c83bec00fd1ed75ee15122a9cc6db62e
> 
> I have bunch of ideas, but all of them ugly (e.g., not own that file and 
> create that directories in scriptlet). Do you
> have any ideas about this situation?

Make systemd create them? It has to manage them anyway.

- ajax
___
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: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Adam Jackson]

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 AVX2].

This is not what I'd call a good idea. I've had to shoot it down
several times on internal mailing lists for RHEL, I think it's even
less a good idea for Fedora.

Skylake Pentium and Celeron models - dating from 2015 - don't have AVX
at all. Why do we want to break them? Has Intel promised they're not
going to pull a trick like that again?

If we really want to chase after Clear Linux benchmarks then fix ld.so
to know that avx2 is a capability (like we could for i686 + sse2).
Moving the baseline like this is far, far too aggressive.

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

Stale packages in Fedora 30

[Adam Jackson]

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 just to raise visibility.

Fedora 21
dia-gnomeDIAicons-0.1-5.fc21.src.rpm
jam-control-1.03-4.fc21.src.rpm
publican-fedora-4.0-2.fc21.src.rpm
rubygem-chunky_png-1.2.7-3.fc21.src.rpm
rubygem-dotenv-0.8.0-3.fc21.src.rpm
rubygem-gruff-0.3.6-8.fc21.src.rpm
rubygem-hydra-0.24.0-6.fc21.src.rpm
rubygem-kwalify-0.7.2-10.fc21.src.rpm
rubygem-rmail-1.0.0-11.fc21.src.rpm
rubygem-rspec-longrun-0.1.2-4.fc21.src.rpm
rubygem-rufus-scheduler-2.0.4-9.fc21.src.rpm
rubygem-xmpp4r-0.5-11.fc21.src.rpm
rubygem-xmpp4r-simple-0.8.8-11.fc21.src.rpm
R-xtable-1.7.1-4.fc21.src.rpm

Fedora 22
eurephia-1.1.0-9.fc22.src.rpm
hail-0.8-0.16.gf9c5b967.fc22.src.rpm
kde-plasma-activitymanager-0.5-8.fc22.src.rpm
kguitar-0.5.1-19.926svn.fc22.src.rpm
pam_radius-1.4.0-2.fc22.src.rpm
prozilla-2.0.4-18.fc22.src.rpm
rubygem-authlogic-3.4.2-1.fc22.src.rpm
rubygem-cookiejar-0.3.2-5.fc22.src.rpm
rubygem-text-format-1.0.0-13.fc22.src.rpm
sslogger-0.96-13.fc22.src.rpm
steadyflow-0.2.0-4.fc22.src.rpm
telepathy-haze-0.8.0-3.fc22.src.rpm
udev-browse-0.3-5.fc22.src.rpm

Fedora 23
brewtarget-2.1.0-3.fc23.src.rpm
centerim-4.22.10-19.fc23.src.rpm
escape-200912250-12.fc23.src.rpm
fbdesk-1.4.1-19.fc23.src.rpm
fedorainfinity-screensaver-theme-1.0.0-10.fc23.src.rpm
fedora-screensaver-theme-1.0.0-12.fc23.src.rpm
gnue-common-0.6.9-16.fc23.src.rpm
gtkmathview-0.8.0-19.fc23.src.rpm
horst-3.0-6.fc23.src.rpm
kawa-2.0-2.fc23.src.rpm
kmplayer-0.11.3c-10.fc23.src.rpm
libexplain-1.4-4.fc23.src.rpm
manaplus-1.3.10.27.2-8.fc23.src.rpm
python-jabberbot-0.15-4.fc23.src.rpm
qdevelop-0.29-5.fc23.src.rpm
qutim-0.3.2-5.git.6f3a98a.fc23.src.rpm
rubygem-openstack-quantum-client-0.1.5-9.fc23.src.rpm
rubygem-puppet-lint-1.1.0-2.fc23.src.rpm
rubygem-sanitize-2.1.0-5.fc23.src.rpm
taskjuggler-2.4.3-22.fc23.src.rpm
teal-1_40b-14.fc23.src.rpm

Fedora 24
ayttm-0.6.3-14.fc24.src.rpm
blobwars-1.19-13.fc24.src.rpm
clojure-1.7.0-1.fc24.src.rpm
dumbster-1.6-20.fc24.src.rpm
elasticsearch-1.7.1-3.fc24.src.rpm
font-manager-0.7.2-4.fc24.src.rpm
free42-1.4.77-1.fc24.src.rpm
gnomint-1.2.1-128.fc24.src.rpm
golang-github-skynetservices-skydns-2.5.3-0.1.a.git8688008.fc24.src.rpm
gyachi-1.2.11-14.fc24.src.rpm
hoard-3.8-12.fc24.src.rpm
homerun-1.2.5-5.fc24.src.rpm
ht-2.0.22-4.fc24.src.rpm
jboss-jaxb-intros-1.0.2-10.fc24.src.rpm
jboss-web-8.0.0-0.6.Alpha1.fc24.src.rpm
jboss-web-native-2.0.10-9.fc24.src.rpm
jenkins-antisamy-markup-formatter-plugin-1.3-2.fc24.src.rpm
jenkins-ant-plugin-1.2-6.fc24.src.rpm
jenkins-commons-jelly-1.1.20120928-10.fc24.src.rpm
jenkins-crypto-util-1.4-6.fc24.src.rpm
jenkins-external-monitor-job-plugin-1.4-4.fc24.src.rpm
jenkins-extras-memory-monitor-1.9-3.fc24.src.rpm
jenkins-icon-shim-1.0.4-4.fc24.src.rpm
jenkins-instance-identity-1.4-5.fc24.src.rpm
jenkins-javadoc-plugin-1.3-4.fc24.src.rpm
jenkins-jexl-1.1-5.20111212.fc24.src.rpm
jenkins-ldap-plugin-1.11-3.fc24.src.rpm
jenkins-matrix-auth-plugin-1.2-3.fc24.src.rpm
jenkins-matrix-project-plugin-1.6-2.fc24.src.rpm
jenkins-pam-auth-plugin-1.2-3.fc24.src.rpm
jenkins-ssh-cli-auth-1.2-8.fc24.src.rpm
jenkins-ssh-credentials-plugin-1.11-4.fc24.src.rpm
jenkins-sshd-1.6-7.fc24.src.rpm
jenkins-ssh-slaves-plugin-1.10-3.fc24.src.rpm
json4s-3.2.7-4.fc24.src.rpm
js-yui2-2.9.0-10.fc24.src.rpm
jutils-1.0.1-13.20110719svn.fc24.src.rpm
kcemirror-0.1.5-16.fc24.src.rpm
libhttpserver-0.9.0-3.fc24.src.rpm
libnasl-2.2.11-18.fc24.src.rpm
lostirc-0.4.6-22.fc24.src.rpm
mahout-collection-codegen-plugin-1.0-4.fc24.src.rpm
maven-changelog-plugin-2.3-2.fc24.src.rpm
maven-ejb-plugin-2.3-14.fc24.src.rpm
maven-help-plugin-2.2-8.fc24.src.rpm
maven-hpi-plugin-1.113-5.fc24.src.rpm
maven-rar-plugin-2.4-2.fc24.src.rpm
maven-repository-plugin-2.3.1-14.fc24.src.rpm
mcollective-2.8.4-2.fc24.src.rpm
mhwaveedit-1.4.22-9.fc24.src.rpm
mingw-llvm-3.0-11.fc24.src.rpm
mycila-licenses-1-4.fc24.src.rpm
ncbi-blast+-2.2.31-4.fc24.src.rpm
openpts-0.2.6-13.fc24.src.rpm
opensaml-java-xmltooling-1.3.4-12.fc24.src.rpm
Pound-2.7-3.fc24.src.rpm
primer3-2.3.6-6.fc24.src.rpm
quake3-1.36-26.svn2102.fc24.src.rpm
racoon2-20100526a-32.fc24.src.rpm
Ray-2.3.1-12.fc24.src.rpm
rescu-1.8.2-0.2.gitbeb9897.fc24.src.rpm
rubygem-compass-1.0.1-3.fc24.src.rpm
rubygem-connection_pool-2.2.0-2.fc24.src.rpm
rubygem-riot-0.12.7-3.fc24.src.rpm
scalaz-7.0.0-6.fc24.src.rpm
silvia-0.2.2-0.11.9324db2git.fc24.src.rpm
snoopy-2.2.6-3.fc24.src.rpm
snownews-1.5.12-14.fc24.src.rpm
SocketW-031026-9.fc24.src.rpm
sugar-colordeducto-7-7.fc24.src.rpm
sugar-xoeditor-13-4.fc24.src.rpm
sugar-yupana-17-3.fc24.src.rpm
termit-2.9.6-8.fc24.src.rpm
tunneler-1.1.1-17.fc24.src.rpm
w3c-libwww-5.4.1-0.27.20060206cvs.fc24.src.rpm
xar-1.5.2-15.fc24.src.rpm
zhu3d-4.2.6-7.fc24.src.rpm

Fedora 25
emacs-pymacs-0.25-8.fc25.src.rpm
gogoc-1.2-49.fc25.src.rpm

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

[Adam Jackson]

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 "averages" and some nearby binary rpms to
each:

Arithmetic mean: 1347495
-rw-r--r--. 1 ajax ajax   13532128 Feb  9 16:52 
texlive-pgfplots-doc-svn47373-25.fc30.noarch.rpm
-rw-r--r--. 1 ajax ajax   13522512 Feb 17 19:28 
Singular-doc-4.1.1p3-4.fc30.x86_64.rpm
-rw-r--r--. 1 ajax ajax   13452180 Feb  7 11:45 
asterisk-sounds-core-es-g722-1.6.1-5.fc30.noarch.rpm
-rw-r--r--. 1 ajax ajax   13411540 Mar 14 10:27 
eclipse-dtp-1.14.102-4.fc30.noarch.rpm
-rw-r--r--. 1 ajax ajax   13358352 Mar 13 05:50 
gcc-go-9.0.1-0.10.fc30.x86_64.rpm

Geometric mean: 104613
-rw-r--r--. 1 ajax ajax 104624 Feb  9 16:55 
texlive-datetime2-polish-doc-svn36692.1.0-25.fc30.noarch.rpm
-rw-r--r--. 1 ajax ajax 104624 Feb  3 21:55 usbutils-010-3.fc30.x86_64.rpm
-rw-r--r--. 1 ajax ajax 104612 Aug 17  2018 
samtools-libs-0.1.19-16.fc29.x86_64.rpm
-rw-r--r--. 1 ajax ajax 104600 Feb  5 11:43 
kf5-khtml-devel-5.55.0-1.fc30.x86_64.rpm
-rw-r--r--. 1 ajax ajax 104588 Feb  2 00:49 objenesis-2.6-4.fc30.noarch.rpm

Median: 71064
-rw-r--r--. 1 ajax ajax  71068 Feb  7 01:26 dagger-1.2.2-10.fc30.noarch.rpm
-rw-r--r--. 1 ajax ajax  71068 Feb 24 17:02 
gnome-shell-extension-system-monitor-applet-36-4.20190224git2583911.fc30.noarch.rpm
-rw-r--r--. 1 ajax ajax  71064 Feb 15 10:55 
cbi-plugins-javadoc-1.1.5-5.fc30.noarch.rpm
-rw-r--r--. 1 ajax ajax  71064 Mar 11 08:03 
opensips-acc-2.4.5-1.fc30.x86_64.rpm
-rw-r--r--. 1 ajax ajax  71060 Feb  2 05:40 
libgrss-devel-0.7.0-8.fc30.x86_64.rpm
-rw-r--r--. 1 ajax ajax  71040 Feb  2 23:15 
mbuffer-20181119-2.fc30.x86_64.rpm

So I kind of take it back. Even single-threaded and at zstd level 19
you'll get about 1MB/s of output (according to your sample table in the
change proposal), and something like 90% of packages are below 1MB
compressed, so I'm hard pressed to care about <1s of difference in
compression time for the vast majority of packages.

Possibly more interesting are the 21 biggest packages (an almost
arbitrary number, the 22nd biggest is the first one that's not noarch):

-rw-r--r--. 1 ajax ajax 1690320420 Feb  1 08:13 
FlightGear-data-2018.3.2-1.fc30.noarch.rpm 
-rw-r--r--. 1 ajax ajax 1378818072 Feb 16 12:29 
speed-dreams-robots-base-2.2.2-2.fc30.noarch.rpm 
-rw-r--r--. 1 ajax ajax  918112496 Mar 20 11:06 
xonotic-data-0.8.2-6.fc30.noarch.rpm 
-rw-r--r--. 1 ajax ajax  913953504 Feb  7 11:46 
astrometry-data-4204-0.76-2.fc30.noarch.rpm 
-rw-r--r--. 1 ajax ajax  876513824 Feb 16 12:29 
redeclipse-data-1.5.6-9.fc30.noarch.rpm 
-rw-r--r--. 1 ajax ajax  795939928 Feb  6 15:24 
alienarena-data-7.71.0-2.fc30.noarch.rpm 
-rw-r--r--. 1 ajax ajax  763842068 Feb  4 15:33 
0ad-data-0.0.23b-2.fc30.noarch.rpm 
-rw-r--r--. 1 ajax ajax  520122860 Aug 23  2018 
supertuxkart-data-0.9.3-2.fc30.5.noarch.rpm 
-rw-r--r--. 1 ajax ajax  518557008 Mar 13 15:44 
kicad-packages3d-5.1.0-1.fc30.noarch.rpm 
-rw-r--r--. 1 ajax ajax  496263868 Feb  3 22:27 
vdrift-data-20141020-16.fc30.noarch.rpm 
-rw-r--r--. 1 ajax ajax  464651048 Feb  7 11:46 
astrometry-data-4205-0.76-2.fc30.noarch.rpm 
-rw-r--r--. 1 ajax ajax  447486852 Feb  3 17:35 
warsow-data-2.1.2-3.fc30.noarch.rpm 
-rw-r--r--. 1 ajax ajax  426017596 Feb 26 22:33 
wesnoth-data-1.14.6-1.fc30.noarch.rpm 
-rw-r--r--. 1 ajax ajax  413617108 Feb  3 17:15 
vegastrike-data-0.5.1-18.r1.fc30.noarch.rpm 
-rw-r--r--. 1 ajax ajax  400129316 Feb  2 01:53 
openarena-0.8.8-14.fc30.noarch.rpm 
-rw-r--r--. 1 ajax ajax  398661608 Feb  6 21:49 
berusky2-data-0.9-10.fc30.noarch.rpm 
-rw-r--r--. 1 ajax ajax  398113064 Jan 31 08:12 
btbuilder-data-0.5.16-4.fc30.noarch.rpm 
-rw-r--r--. 1 ajax ajax  382267140 Mar  9 14:26 
pioneer-data-20190203-2.fc30.noarch.rpm 
-rw-r--r--. 1 ajax ajax  367174128 Feb  1 21:20 
julius-japanese-models-4.4.2.1-5.fc30.noarch.rpm 
-rw-r--r--. 1 ajax ajax  357514216 Feb  9 16:48 
texlive-kerkis-svn15878.0-25.fc30.noarch.rpm 
-rw-r--r--. 1 ajax ajax  353033380 Aug 17  2018 
torcs-data-1.3.7-4.fc28.noarch.rpm 

Or, the biggest desktop apps, since they're likely to see frequent
rebuilds, which are basically: eclipse, libreoffice, and firefox.

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

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

[Adam Jackson]

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 successful build completion.
That's likely a win overall, especially when we consider the local mock
case of "why is this build failing", where you're likely to iterate
several times until you succeed. Still, it would be nice to see some
more detailed numbers to back that up. For example:

- For the minimal buildroot, what's the difference in download size and
decompression time?
- What's the mean and/or median size of an rpm in Fedora, and what
difference in {de,}compression time would that likely experience?
- Which package's mock buildroot has the largest size (compressed or
not, though it's probably the same either way), and what time
difference would that package experience with this change?

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

Re: Destop environment and gl performance...

[Adam Jackson]

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 generates has to also be presented to the
screen, which - for cinnamon, and gnome-shell, and kwin's gl mode -
means that display _also_ uses GL and so will be contending with glmark
for the GPU.

The offscreen glmark numbers ought to be nearly identical.

> Even better is there a way to investigate the GPU usage (a la ps or top)
> to understand such issues ?

GL profiling is something of a dark art with the open source tools. If
you have an intel gpu you could start with intel_gpu_top from the igt-
gpu-tools package.

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

Re: vsync in VM?

[Adam Jackson]

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, I'm seeing hundreds or thousands of FPS in glxgears,
> implying that vsync is not working.
> 
> Is that an expected state? Is there a simple way to force vsync on
> inside a VM? (using virt-manager + libvirt)

Short answer: yes it's expected, no there's no way to do that, probably
there should be.

Long answer:

The concept of "vsync" in a virtual machine is a bit fuzzy. What
monitor's timings do you think you're syncing to? What do you do when
there's more than one host process watching the framebuffer (think both
gtk and vnc views on the same device)? But, assuming you manage to
answer those questions...

At least in qemu's implementation neither qxl nor bochs has any
"hardware" concept of a vertical retrace interrupt. And for both of
those you'll end up with llvmpipe for the 3D driver, which doesn't have
any concept of vsync either. The latter we could maybe fix in a few
ways, but I wouldn't expect the former to ever change.

virtio looks like it has _some_ internal notion of interrupts, but if
that's supposed to be implementing vsync it's not obvious to me how
it's accomplishing that. vmwgfx I suspect does have synthetic vsync
events, but I think you'd need to be using an actual vmware vm to make
that happen and not qemu.

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

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

[Adam Jackson]

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 "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 thought process here, could you please elaborate on that?
> > 
> > mock defaults to setting up buildroots for older OSes with yum, from
> > the containing OS' side. yum is python2-only. So a py2-less host OS
> > can't build for older OSes, without some finagling. In fact currently
> > mock _defaults_ to yum, even for newer OSes, so removing python2 breaks
> > mock's default invocation.
> 
> yum was already removed from Fedora 31. So removal of python2 doesn't change 
> this, or does it?

I suppose removing python2 does not make it any _more_ broken, no.

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

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

[Adam Jackson]

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 thought process here, could you please elaborate on that?

mock defaults to setting up buildroots for older OSes with yum, from
the containing OS' side. yum is python2-only. So a py2-less host OS
can't build for older OSes, without some finagling. In fact currently
mock _defaults_ to yum, even for newer OSes, so removing python2 breaks
mock's default invocation.

Vaguely related, there's no way to pass --yum or --dnf to fedpkg
mockbuild. I've filed a bug about this, which has gotten no attention:

https://pagure.io/rpkg/issue/413

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

RFC: switch to uvesafb and drop openchrome in F31+

[Adam Jackson]

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 on x86 machines is either efifb if you're
living in the future, or X's vesa driver if you're living in the past.
At this point there are only two X drivers that require userspace setup
support, vesa and openchrome. (The latter I'm also considering nerfing,
because I sincerely doubt there are any Fedora users of it; if this is
you, speak up.) Removing this code would simplify some awkward device
enumeration cases in the X server - cases which have come up in the F30
blocker list, and I would like not to be on the critical path for that
kind of thing in the future.

This would also move an 8086 emulator out of the X server to a
dedicated usermode helper. Which is nice, since X still has to run with
elevated privileges in these cases, and X hasn't exactly lacked for
CVEs.

Having done this, we would also potentially _expand_ the number of
devices we support for graphics, because we would have a vesa-backed
fbdev driver. There exist wayland servers that can display to fbdev,
but I'm not aware of any that can display directly to vesa.

But there are risks. For one, we've never tried this. uvesafb itself is
not untested - I believe you can coax ubuntu and gentoo into using it -
but we've never built it in Fedora before, so the interactions with
with our initramfs, with plymouth, and so on are only "tested" to the
extent that they're the same thing everyone else is doing.

In particular, I'm not entirely sure how well the handoff from uvesafb
to drm works in practice. From efifb to drm is fairly well tested, and
also fairly likely to be safe, because efifb does not give you any
ability to _change_ video device state. uvesafb does, and we could end
up putting the GPU in a new funky state that the drm driver doesn't
know how to handle. I suspect this is unlikely, and possible to
mitigate (by blocking uvesafb from initializing in more cases, for
instance), but it's something to be aware of.

Finally, uvesafb only supports video devices that support VBE 2.0 or
higher. In principle, X's vesa driver supports any VBE implementation
at all. I'm not convinced this is a real issue for us though. VBE 2.0
dates to 1994, and I have maybe one pre-2.0 video card in my collection
of old weird junk.

So. Pros: remove some sketchy code from a setuid program everyone has
installed, potentially lower its privilege profile, potentially enable
wayland in more scenarios. Cons: maybe lose some device support, maybe
break gfx fallback on old-firmware systems.

What do we think?

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

Re: "Basic graphics mode" feature and criterion discussion

[Adam Jackson]

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, and general improvement in the reliability and
> coverage of the major drivers for the major graphics hardware
> manufacturers) and inherently less likely to work (due to the general
> trend of work on kernel modesetting and Wayland) than it used to be.

At least in a Gnome context, the issue is that 'nomodeset' will likely
leave you with efifb, and that mutter does not support (both being a
wayland server and) rendering to fbdev devices, only drm devices. (This
will probably soon be true for weston too; no idea what KDE does these
days.) So in that scenario gdm will instead launch Xorg.

Now, Xorg's not about to delete fbdev support, but this means you're
exercising quite a few different paths relative to the normal Wayland
session. Input devices are driven from Xorg so xinput(1) will show more
interesting results, xrandr(1) will behave differently, control-center
will be using a different backend, you probably won't get hidpi support
working the same way, you'd expect HDR not to work once that's a thing
we support at all, etc etc etc.

So with the above caveat understood that "work correctly" has a bunch
of asterisks next to it and you will probably be able to tell that
you're using a fallback path, I don't think it's intrinsically less
likely that graphics fallback would work. I might prefer that we call
it "desperation" or "emergency" graphics instead of "basic", I suppose.
But the support path itself is something we already want/need to keep
working for the case of hardware released after the OS. I might want to
see the code implementing that fallback path made cleaner, and I might
wish the path weren't necessary, but.

> 4) (This one mainly for ajax and airlied) to what extent does the
> concept of a 'fallback option' for our supported desktop environments
> and graphical servers still actually make sense? Could a different
> implementation of the same basic idea be envisaged, and would it be
> useful? If so, should we do that, and what would be the consequences
> for the criteria?

The components necessary to support fallback graphics are components we
already have to support graphics in a dumb vm. I don't see that
requirement going away, so I don't see much point in disabling that
support for physical machines.

From an implementation perspective I would certainly like to see the
fallback path look more like the supported path, in that I'd like drm
devices to be the only graphics abstraction, and eventually would like
to stop caring about Xorg - meaning, the X server also being the
display server and input server. But saying 'nomodeset' is a perfectly
unambiguous way of asking for the fallback path, I don't think there's
much point in requiring you to say something different on kcmdline.

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

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

[Adam Jackson]

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

C's "char" type is either signed or unsigned by default, it's a
function of the processor-specific ABI. It happens to be signed on i686
and x86_64, and unsigned on all the other arches Fedora supports. So:

> /builddir/build/BUILD/gdcm-2.8.8/Testing/Source/Common/Cxx/TestString2.cxx:29:24:
>  error: narrowing conversion of '-1' from 'int' to 'char'  [-Wnarrowing]

This would only trigger on unsigned-char arches, because you can't
represent -1 with an unsigned number.

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

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

[Adam Jackson]

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 software using
> them should be migrated to DNF.

I have a couple of older OSes I often need to do builds for in mock,
which OSes use yum natively. Unfortunately pyrpkg doesn't have any way
to invoke mock with --dnf, so when mock attempts to construct the
chroot it tries to use yum to do it. With this change (or indeed
already on my F29 machine without yum installed) I would no longer be
able to use fedpkg to build for those OSes.

Obviously I can work around this by invoking mock manually with an
appropriate config file, but it would be pleasant if pyrpkg was fixed
as well.

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

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

[Adam Jackson]

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.
> 
> /usr/include/GL/glext.h:467:10: fatal error: KHR/khrplatform.h: No such file 
> or directory
> 
> Since /usr/include/GL/glext.h belongs to mesa-libGL-devel and not
> camotics I think it would be more appropriate to put the dependency
> there. Thoughts?

Apologies, this was a change to how the GL headers were structured. I'd
noticed the issue already in 18.3.0, but apparently the change was
backported to the 18.2.x series (in F29) as well. I've backported the
fix to F29 and built an update:

https://bodhi.fedoraproject.org/updates/FEDORA-2018-002d43a640

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

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

[Adam Jackson]

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 Wayland, not X, right?

The thing driving the display [1] is a wayland server named gnome-
shell. Due to accident of implementation there is also an X server
named Xwayland running as well. This CVE affects the X server named
Xorg.

[1] - Assuming you select "GNOME" from the little gear menu in gdm, as
opposed to "GNOME on Xorg".

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

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

[Adam Jackson]

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
https://bodhi.fedoraproject.org/updates/FEDORA-2018-4ab08fedd6

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

Re: Intent to orphan coan

[Adam Jackson]

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 that
unifdef just chokes on. I'd be happy to take it.

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

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

[Adam Jackson]

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 email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: RFC: Alternative -devel packaging

[Adam Jackson]

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 itself. If the drivers themselves have non-trivial
> > dependencies, the buildroot is more likely to fail to compose.
> 
> That's a boostraping problem. The general solution is to make our build 
> tools bootstrap aware, so they activate bootstrap mode as needed 
> automatically, instead of forcing packagers to switch the conditional 
> manually in spec files each time a bootstraping situation arises.

If you consider buildroot size to be a metric to be reduced - and
clearly people do, see BuildRequires: gcc - then this is not just a
bootstrapping issue.

Is there a proposal anywhere for the kind of bootstrap awareness you
describe?

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

Re: RFC: Alternative -devel packaging

[Adam Jackson]

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 dependencies. I'm not sure I see an example of anything
like that in opencv or virtualbox-guest-additions, but I might be
misreading you.

- ajax
___
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/MEHQOUJCR6GZB3FBZGQERH6RLXAEB7TI/

RFC: Alternative -devel packaging

[Adam Jackson]

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 that the devel package requires the package
providing the API library, _and_ said required package requires the
drivers. What if instead you had (in pseudo-spec):

%package devel
Requires: %{name}-sdk

%package sdk

%package libs
Requires: foo-drivers

where -libs and -sdk have identical %files, but -sdk has automatic
provides for library sonames turned off (so it never satisfies a
runtime dependency). This would duplicate some content on the mirrors,
but not the installed system, and it would let you compose a buildroot
with only the API surface you link against.

---

Is this all dodging the issue that nothing agrees what Recommends:
means? And that nobody's compose tools or comps files really understand
what drivers they want, and that propagating that information is an
unbounded task? Well, yeah, a bit. I still think it'd solve a real
problem, I'm just wondering if the idea is too ugly to consider.

- ajax
___
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/CHZR6OMICCL3Y6V7OFPV7MR62CSQY77C/

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

[Adam Jackson]

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 include changing the kernel configuration for i686 to
a higher baseline, and if so, which?

- ajax
___
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/5RI7PCUNY4DP2S4YF434WL5CEOTDNTLC/

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

[Adam Jackson]

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 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/52TT3XLRTVUUHSGB7YPOM6RXXC2UTPNB/

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

[Adam Jackson]

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
> > > > > 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 this proposed change, you will need an x86-64-capable CPU.
> > 
> > That's not how I read the proposal. No reason a P4 shouldn't work if
> > all you're requiring is SSE2+FXSR, right?
> 
> It will probably work, but it's more of a happy accident than a 
> deliberate decision.  I would still suggest it if it were incompatible 
> with Pentium 4 CPUs without x86-64 support.  (The fewer of these 
> Netburst power guzzlers are running, the better, to be honest.)

Certainly, I'm no netburst fan either. But the last[*] 32-bit-only
Intel chip was Yonah (Core 1), which went out of production in 2008-
ish, so there's about seven years worth of CPUs between the
introductions of SSE2 and AMD64. So this isn't eliminating the
possibility of extant i686 kernels, which "will need an x86-64-capable
CPU" might otherwise imply.

[*] - Ignoring Quark, as the rest of the market did.

- ajax
___
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/TGAZS4TK3F5XW4PIRXCJCLMQYVC4HCZP/

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

[Adam Jackson]

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 this proposed change, you will need an x86-64-capable CPU.

That's not how I read the proposal. No reason a P4 shouldn't work if
all you're requiring is SSE2+FXSR, right?

- ajax
___
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/6OYP2FKS4ASPWQ4OAZFLPUXFDTNUUEGK/

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

[Adam Jackson]

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 x86-64 systems, and nothing more.
> 
> So the 32-bit x86 SIG would be required to rebuild all of the userspace
> packages to run on actual 32-bit hardware, right?  (What would those be
> called, since i686 is taken?)

No. The 32-bit ABI level being targeted here is basically the Pentium
4, which was a 32-bit part. On a P3 or older, yes, you'd need a
rebuild, but the P4 was 2001 so we're talking about hardware old enough
to vote here.

If we did want to allow for pre-P4 32-bit userspace, what I'd probably
do is (mostly) change %_libdir to /usr/lib/sse2 for i686, and leave it
as /usr/lib for a (reintroduced) i586 architecture.

- ajax
___
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/5ZTMW77HAWOFQN3QTA2BJB7IYQXWRUQW/

Re: Recommended way to pass CFLAGS/LDFLAGS through libtool

[Adam Jackson]

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 = -Wl,--as-needed,-lm,--no-as-needed -lvirt
> 
> Failure to do so would qualify as "a poorly written Makefile.am".

Nothing in the libtool documentation mentions reordering linker
arguments, or using -Wl to prevent that. Blaming the makefile for not
using undocumented libtool features to work around libtool's own
misdesign is perhaps unwarranted.

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

Re: Call for testing of xserver 1.20 release candidates

[Adam Jackson]

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 prone
> to breakage to be pushed after F28 release?

That I'm suggesting doing it is evidence that I think it should be safe
to do. We've rebased llvm in live releases and that's far more
disruptive.

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

Re: Call for testing of xserver 1.20 release candidates

[Adam Jackson]

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 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
> > going to try to land this for F28 GA. But I would _very_ much like to 
> > push this as an update, and would appreciate any and all testing and
> > feedback.
> 
> I would say the opposite: land this today so that it can get in F28 Beta
> (tomorrow starts package freeze for the beta release), and don't do a
> post release update that changes the drivers ABI.

Much as I would like to, the change process does exist, and says it's
far too late for that for F28 gold.

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

Call for testing of xserver 1.20 release candidates

[Adam Jackson]

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
going to try to land this for F28 GA. But I would _very_ much like to 
push this as an update, and would appreciate any and all testing and
feedback.

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

Re: Using LTO for Fedora package builds

[Adam Jackson]

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 finds actual bugs, since the
compiler now has the whole program to work with and can do better error
checking. For example:

https://cgit.freedesktop.org/xorg/xserver/commit/?id=c3147a20065b212fac78eb29c9bb9e150f9b22f5

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

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

[Adam Jackson]

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, /usr/include/rpc was 
> exclusively used by glibc.

tirpc could also do #pragma GCC system_header I bet.

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

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

[Adam Jackson]

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 do you something else which is unusual, such as
> > > running the preprocessor separately?
> > 
> > Not that I'm aware of. The generated cc line is:
> > 
> > ninja: Entering directory `build'
> > [1/17] ccache cc  -Ios/libxserver_os@sta -Ios -I../os -Ixfixes -I../xfixes
> 
> ccache runs the preprocessor separately. 8-)

Hah! Of course it would. Thanks for the explanation.

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

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

[Adam Jackson]

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/rpcauth.c:47:0:
> > /usr/include/tirpc/rpc/rpc.h:83:12: warning: redundant redeclaration of 
> > ‘bindresvport’ [-Wredundant-decls]
> >   extern int bindresvport(int, struct sockaddr_in *);
> >  ^~~~
> > In file included from /usr/include/tirpc/rpc/rpc.h:40:0,
> >   from ../os/rpcauth.c:47:
> > /usr/include/netinet/in.h:502:12: note: previous declaration of 
> > ‘bindresvport’ was here
> >   extern int bindresvport (int __sockfd, struct sockaddr_in *__sock_in) 
> > __THROW;
> >  ^~~~
> > 
> > Is there any reasonable fix for this?
> 
> Redeclarations in system headers are expected.  Do you compile with 
> -Wsystem-headers?  Or do you something else which is unusual, such as 
> running the preprocessor separately?

Not that I'm aware of. The generated cc line is:

ninja: Entering directory `build'
[1/17] ccache cc  -Ios/libxserver_os@sta -Ios -I../os -Ixfixes -I../xfixes
-Irender -I../render -Irandr -I../randr -Ipresent -I../present -Iinclude
-I../include -Idri3 -I../dri3 -Idbe -I../dbe -Imiext/sync -I../miext/sync
-Imiext/shadow -I../miext/shadow -Imiext/damage -I../miext/damage -Imi -I../mi
-Iglamor -I../glamor -Ifb -I../fb -Iexa -I../exa -Idamageext -I../damageext
-Icomposite -I../composite -IXi -I../Xi -IXext -I../Xext -I/usr/include/X11/dri
-I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16
-I/usr/include/tirpc -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64
-Wall -Winvalid-pch -std=gnu99 -O2 -g -DHAVE_DIX_CONFIG_H -fno-strict-aliasing
-fvisibility=hidden -Wall -Wpointer-arith -Wmissing-declarations -Wformat=2
-Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wbad-function-cast
-Wold-style-definition -Wunused -Wuninitialized -Wshadow -Wmissing-noreturn
-Wmissing-format-attribute -Wredundant-decls -Werror=implicit -Werror=nonnull
-Werror=init-self -Werror=main -Werror=missing-braces -Werror=sequence-point
-Werror=return-type -Werror=trigraphs -Werror=array-bounds
-Werror=write-strings -Werror=address -Werror=int-to-pointer-cast
-Werror=pointer-to-int-cast -fPIC -D_DEFAULT_SOURCE -D_BSD_SOURCE -DHAS_FCHOWN
-DHAS_STICKY_DIR_BIT -MMD -MQ 'os/libxserver_os@sta/rpcauth.c.o' -MF
'os/libxserver_os@sta/rpcauth.c.o.d' -o 'os/libxserver_os@sta/rpcauth.c.o' -c
../os/rpcauth.c
In file included from ../os/rpcauth.c:47:0:
/usr/include/tirpc/rpc/rpc.h:83:12: warning: redundant redeclaration of 
‘bindresvport’ [-Wredundant-decls]
# ...

Is -Wredundant-decls just not a thing one should try to use?

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

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

[Adam Jackson]

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 interfaces related to
> Sun RPC from glibc.

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/rpcauth.c:47:0:
/usr/include/tirpc/rpc/rpc.h:83:12: warning: redundant redeclaration of 
‘bindresvport’ [-Wredundant-decls]
 extern int bindresvport(int, struct sockaddr_in *);
^~~~
In file included from /usr/include/tirpc/rpc/rpc.h:40:0,
 from ../os/rpcauth.c:47:
/usr/include/netinet/in.h:502:12: note: previous declaration of ‘bindresvport’ 
was here
 extern int bindresvport (int __sockfd, struct sockaddr_in *__sock_in) __THROW;
^~~~

Is there any reasonable fix for this? I assume this wouldn't happen in
F28 because glibc (providing ) would not provide that
decl anymore, though I've not tried.

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

Re: Issues in F26 that bug me

[Adam Jackson]

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 as well as X with the nouveau driver, as far as I'm
aware. If you want to run the binary driver, X is still there, you can
still use it. There are (relatively easy) technical and (relatively
hard) political issues with running wayland on the binary driver, and
we're working both with upstreams and with NVIDIA to find solutions. In
order to know what those remaining issues are, we needed to change the
default away from X sometime, so we did.

> I know it is not your fault when manufacturers
> (those idiots) refuse to reveal their instruction set or communications
> architecture, but shouldn't some form of industry standards
> organization be created to set up some standards so new systems could
> be used across OS's and platforms?

To the extent such an organization already exists, it's called Khronos
(of which Red Hat is a member). But one does not just get to invent a
standard and expect people will adopt it, the standard must both solve
a problem they're having and save them money (or time or other
resource). Neither does defining a standard make its implementation
magically appear.

The kind of standard that would enable us to support any given GPU as
soon as it hits the market would look something like AHCI, essentially
a register file definition for every possible feature you might want to
drive. This would not solve a problem any GPU vendor is having, it
would create a new one, because their existing programming model is not
going to match that standard. Nor would it save them any time or money
or effort, it would cost them significant amounts of each.

API standards like OpenGL _do_ solve a problem those vendors have,
which is how to keep high-value applications running while retaining
the freedom to improve how the hardware works. Even a much lower-level
standard like Vulkan still abstracts the hardware away, though to a
different set of primitive operations. In order to keep pushing that
abstraction layer down towards the hardware, we also work on projects
like Mesa for the "save them money" part of the incentive structure.
And as a result we've seen vendors start to simply adopt Mesa rather
than support their own GL stack; at some point Mesa becomes cheaper.

So I wouldn't call those vendors "idiots", myself. They might be self-
centered, but they're not stupid. They're doing the best they can to
serve the markets they have and want. If we want to change their
behavior, it's incumbent on us to provide the incentive.

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

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

[Adam Jackson]

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
> > > which currently uses svc_/clnt_/xdr_ symbols from glibc.  It does not
> > > indicate whether these packages can use libtirpc or have bundled
> > > replacements.
> > How exactly these xdr_ symbols changed?
> 
> They are compat symbols, so existing binaries can still reference them.
> 
> The perl-PDL situation is yet a bit more complex.  Rebuilding it with 
> the new glibc succeeds because the xdr_ symbols actually come from HDF, 
> which only provides a static library.  Our ld does not default to “-z 
> defs”, so SD.so contains an undefined symbol references to xdr_enum and 
> similar symbols.  This reference is unversioned, so the glibc dynamic 
> linker will still bind it to the base symbol version in glibc (e.g., 
> xdr_enum@GLIBC_2.2.5).

Would it help if xdr_enum@GLIBC_2.2.5 etc. were made weak symbols? That
way an unversioned reference could resolve to the one in libtirpc if
that happens to be in memory. (I _think_ this is how do_lookup_x
already works, but it's hard to ever be sure I'm reading it right.)

Definitely mostly in favor of -z defs though. ld doesn't have a way to
invert that option atm, but once it does that'd nice to have in a mass
rebuild.

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

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

[Adam Jackson]

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

I'm mostly in favor of this, but as the perpetrator of the current
hardening flag hack in r-r-c, I really do wish there was a better way
to set these defaults than -specs=blah. The current implementation is
fragile and leaks out to the rest of the OS in weird ways.

I'm aware that fixing this "sanely" would probably require fixing the
toolchain to (allow us to) declare more intent about the destination of
an ET_REL object when it's being built; fine, let's do that.

Is anyone looking at this change from that perspective?

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

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

[Adam Jackson]

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

It'd be pleasant if ld could warn you about excess linkage.

> 2) until recently, there was no way to enable the option for just one
> library and restore it afterwards, so many spots, including, but not limited
> to, gcc driver itself, do --as-needed -lgcc_s --no-as-needed, which if
> somebody forces --as-needed at the start of the linker command line has the
> effect that everything up to the -lgcc_s on the command line behaves
> --as-needed, and everything after it doesn't.  Since 3 years ago ld
> offers the --push-state/--pop-state options, so one can use
> --push-state --as-needed -lgcc_s --pop-state instead and that at the end
> restores the previous --as-needed behavior.  So, before turning it by
> default, you'd need to check everywhere where --no-as-needed is used and
> see if it is something where --push-state/--pop-state should be used.

libtool will throw away your attempts to use --as-needed and --push-
state anyway, because libtool is trash.

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

Re: Fedora 27 ships with outdated intel driver from 20160929

[Adam Jackson]

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
> experience performance regressions for day-to-day work (eclipse,
> libreoffice, ...) on my gen5 laptop and I suspect gen4 (i965) is even
> worse.
> 
> Therefore, I continue using xorg-x11-drv-intel + SNA, however, the
> package shipped by Fedora is really outdated and now over a year old
> (20160929): https://bugzilla.redhat.com/show_bug.cgi?id=1496252
> 
> I don't expect active support for this settup, but please either ship
> a more recent version of this package or drop it altogethert.

Yeah, it's sort of hard to remember to update a driver that hasn't seen
a release in nearly three years. I've built a new snapshot for rawhide
and F27.

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

Re: Purpose of Makefile in package repository?

[Adam Jackson]

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 such a Makefile then be deleted or
> does it serve any other purpose?

That is correct. Most packages had a nearly identical copy of this
Makefile, but a few (most notably the kernel) had extended it with
other maintainer convenience commands. I suspect what happened here is
that when we moved to git we preserved any Makefile that didn't match
the standard one.

This particular one is certainly not doing anything useful anymore,
feel free to nuke it.

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

Re: Testing graphical applications inside mock fails

[Adam Jackson]

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
> >   Extension:130 (MIT-SHM)
> >   Minor opcode: 5 (X_ShmCreatePixmap)
> >   Resource id:  0x280005f
> > X Error: BadDrawable (invalid Pixmap or Window parameter) 9
> >   Major opcode: 62 (X_CopyArea)
> >   Resource id:  0x2800060
> > X Error: BadDrawable (invalid Pixmap or Window parameter) 9
> >   Major opcode: 62 (X_CopyArea)
> >   Resource id:  0x2800060
> > X Error: BadDrawable (invalid Pixmap or Window parameter) 9
> >   Major opcode: 62 (X_CopyArea)
> >   Resource id:  0x2800060
> > ...
> 
> QT_X11_NO_MITSHM=1 helps with these, though.

Qt should be better at this, I think. MIT-SHM can fail for any number
of reasons that are clearly perfectly easy to detect, it should
silently fall back to the non-MIT-SHM path.

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

Re: Testing graphical applications inside mock fails

[Adam Jackson]

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 mesa-libGL inside the chroot as there were
> messages about missing files. But still no luck, some applications
> appear with an incomplete window, other ones without any. All
> applications that i have tested have a common error messages:
> 
> libGL error: failed to open drm device: No such file or directory
> libGL error: failed to load driver: i965
> 
> Is it possible to do that?

Short answer:

# mknod /dev/dri/card0 c 226 0

Long answer:

You're apparently trying to test the app inside the mock chroot by
having it display on an X server outside that chroot. When GL tries to
initialize it will ask the X server for the /dev node for the GPU, but
nothing inside the chroot has created it.

If all you need to test the application is to run some non-interactive
test suite, you may find xvfb-run(1) in the xorg-x11-server-Xvfb
package to be a better fit. This will create a virtual X server running
inside the chroot, detached from any hardware, and will use a software
GL driver if necessary.

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

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

[Adam Jackson]

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 without libEGL.so.1,
> that's a client library.

glamor needs libEGL too. But it does so through libepoxy, which doesn't
have a DT_NEEDED for it (or libGL) because it's all dlopen magic
instead.

xorg-x11-server-{Xorg,Xwayland} should grow at least a Recommends for
libEGL and libGL.

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

Re: RFC: Disable cairo-gl backend in F27

[Adam Jackson]

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 does not care.

I've rebuilt cairo and rubygem-cairo with the gl backend disabled. If
there's any further fallout I'm sure the mass rebuild will let us know.

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

RFC: Disable cairo-gl backend in F27

[Adam Jackson]

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 into literally every gtk process on the
system, so it's a bit expensive to have libGL loaded 80 times and never
used. As far as I can work out we enabled the backend in 2012-ish
because some of the wayland demos wanted it, but they no longer do.

Indeed the API itself does not seem to have very many users in F26:

 U cairo_gl_device_set_thread_aware
 U cairo_gl_surface_create
 U cairo_gl_surface_create_for_window
 U cairo_gl_surface_swapbuffers
./cairo-1.14.10-1.fc26.x86_64/usr/bin/cairo-sphinx
 U cairo_gl_surface_create
 U cairo_gl_surface_create_for_texture
 U cairo_gl_surface_get_height
 U cairo_gl_surface_get_width
 U cairo_gl_surface_set_size
 U cairo_gl_surface_swapbuffers
./rubygem-cairo-1.15.9-1.fc26.x86_64/usr/lib64/gems/ruby/cairo-1.15.9/cairo.so
 U cairo_gl_device_set_thread_aware
 U cairo_gl_surface_create_for_texture
 U cairo_gl_surface_get_height
 U cairo_gl_surface_get_width
./webkitgtk-2.4.11-5.fc26.x86_64/usr/lib64/libwebkitgtk-1.0.so.0.22.17
 U cairo_gl_device_set_thread_aware
 U cairo_gl_surface_create_for_texture
 U cairo_gl_surface_get_height
 U cairo_gl_surface_get_width
./webkitgtk3-2.4.11-5.fc26.x86_64/usr/lib64/libwebkitgtk-3.0.so.0.22.17

cairo-sphinx is a cairo replay tool for regression testing, and can
just be rebuilt without GL support. The two webkitgtk packages are dead
in F27. That just leaves rubygem-cairo, whose cairo-gl support also
appears to be optional.

I'm not aware of any ruby gems that explicitly require cairo-gl to
work, but I also don't know how i'd even begin to search for that. I
also haven't checked this against any external repositories yet.

Does this sound like a reasonable plan? Does this sound like a "self-
contained" change?

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

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

[Adam Jackson]

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 -L/home/navid/development/Chpp/lib
> -Wl,-rpath,/home/navid/development/Chpp/lib:/usr/local/lib -lz -lglog
> -lcryptopp /usr/local/lib/libre2.so -lprotobuf -lpthread -lfontconfig
> -lfreetype -lpng -lz -ljpeg -lwebp -lwayland-client -lwayland-server
> -lwayland-egl -lwayland-cursor -lGLEW -lvulkan ../lib/libskia.a -ldl
> -lglog -lcryptopp /usr/local/lib/libre2.so -lprotobuf -lpthread
> -lfontconfig -lfreetype -lpng -ljpeg -lwebp -lwayland-client
> -lwayland-server -lwayland-egl -lwayland-cursor -lGLEW -lvulkan
> ../lib/libskia.a -ldl && :

-lGLEW here means skia is trying to get the GL symbols from the GLEW
wrapper library. But GLEW doesn't wrap all GLX symbols, so if the
application calls one of the ones it doesn't wrap, it needs to also
link with -lGL.

> /usr/bin/ld: ../lib/libskia.a(gpu.GrGLCreateNativeInterface_glx.o):
> undefined reference to symbol 'glXGetCurrentContext'
> 
> /usr/local/lib/libGL.so.1: error adding symbols: DSO missing from
> command line

This is the linker telling you that skia should also have said -lGL.

> Although I fixed my problem with compiling libglvnd from upstream and
> installing it myself.

I don't understand how this would have fixed anything. Can you
elaborate?

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

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

[Adam Jackson]

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 because there just isn't any graphics hardware for s390x?

Right. Not just -server-devel, -server-Xorg as well. I haven't actually
tried to build the Xorg server on s390 in ages, it might work but who
knows. We've always built Xvfb for all arches though, and the xvfb-run
script makes launching it pretty painless.

That said there are a few potentially visible differences between dummy
and Xvfb from the app perspective, so if you find something that
doesn't work with Xvfb please do let me know.

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

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

[Adam Jackson]

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 requires.
> 
> These GPUs will stop claiming fragment shaders support from Mesa 17.1.[0], 
> just FYI

Oh good! That's for the best, really.

glamor also has a gles2 path, but right now it's known to be broken.
We'd like to fix that in general since some arm chips are never going
to be able to do enough desktop GL to satisfy glamor. When/if that
happens we can revisit glamor on gen3.

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

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

[Adam Jackson]

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
the GPUs that happen to be commonly attached to 32-bit CPUs. Which is
what this:

> [42.108] (WW) glamor requires at least 128 instructions (64
> reported)

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

We knew this, though, which is why our (actually Debian's) patch to the
X server to default to modesetting on intel only does so for gen4 and
newer:

http://pkgs.fedoraproject.org/cgit/rpms/xorg-x11-server.git/tree/06_use-intel-only-on-pre-gen4.diff

This way gen2 and gen3 still get native 2D and 3D acceleration.

> I used modesetting on F25 with Option "AccelMethod" "none" and worked
> very well, Intel drive crash when using pipelight and with
> modesetting the crash don't happens, but I need to use a no-default
> option ... 

That's just a bug in the intel driver, then. Can you be more specific?

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

Re: amdgpu xorg driver not installed by default

[Adam Jackson]

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 modesetting driver works fine on these cards. As far as
I'm aware the only reason to want the amdgpu X driver is a) for older X
servers that don't have the modesetting driver, b) if you want to use
the closed-source 3D driver as well. Neither of those apply to Fedora,
so...

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

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

[Adam Jackson]

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Adam Jackson]

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 well, but sure. 
Can you drill down on this a bit? Which subtests get most worse?

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

Re: Should we stop stripping static libraries?

[Adam Jackson]

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 ask for it is counter-intuitive.

I think this speaks more to a misunderstanding of the tools than
unintuitive behaviour. -g is a compile phase option, and it asks for
debugging info to be emitted for the object being compiled. It has no
effect on the link phase. In your initial email you wrote:

> What happens if a program built without -g is linked to the libc.a
> with debug symbols?

One does not build _programs_ with/out -g. One builds objects, and
links objects into programs.

If your static binary is being built in an rpm then you will still end
up with a stripped binary and separate debuginfo; it's just that now it
will include debuginfo for the static library you linked against as
well.

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

Re: F25 Self Contained Change: Rust Compiler

[Adam Jackson]

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 that may affect rustc, which are
> > > certainly a possibility.
> > 
> > At the moment llvm has codegen support for every Fedora architecture,
> > primary and secondary. Of architectures we've formerly supported it's
> > missing s390 and ia64.
> 
> Perhaps I'm looking in the wrong place, but F24 "llc -version" does not
> show mips, which is in the list of secondary architectures here:
> 
>   https://fedoraproject.org/wiki/Architectures#Structure
> 
> Should "Mips" be added to LLVM_TARGETS_TO_BUILD?

Eep, you are correct. I have another llvm build I need to submit
shortly anyway, I'll add mips to the list. Thanks for the catch.

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

Re: F25 Self Contained Change: Rust Compiler

[Adam Jackson]

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 and secondary. Of architectures we've formerly supported it's
missing s390 and ia64.

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

Re: Why Wayland session runs on 2nd VT?

[Adam Jackson]

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 else) implements fast user
switching. Been true of the X session too for several releases now.

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

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

[Adam Jackson]

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 sort of the reason Go and Rust exist.

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

Re: Minimizing the fedora docker base image footprint

[Adam Jackson]

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, but I would like to hear your thoughts either way.

Removing tzdata seems like a bad idea. I think a small amount of code
change could make the cost of keeping tzdata much lower. Virtually all
of the tzdata files are less than 4 kilobytes, so most of the on-disk
storage cost is block size overhead:

dmt:~% du -s --apparent-size /usr/share/zoneinfo
1720/usr/share/zoneinfo
dmt:~% du -s /usr/share/zoneinfo
4780/usr/share/zoneinfo

Possible options include:

a) Glue all the compiled zone info together in a single file, teach
glibc and friends about it
b) Glue the zone info together in a romfs image, mount it from a
systemd unit
c) Both of the above: glue them all together in a romfs, add a
fuse/overlay fs to expose the individual files
d) Mount a zoneinfo fs exported from the host

A somewhat similar criticism applies to removing gconv. Pretending that
applications don't have to deal with multiple character encodings is
likely to be wrong, and we don't currently have any metadata to track
whether a binary calls iconv() so there's no way to express the need
for the gconv modules. Here again, most of these libraries are
relatively small, and gluing them all together would be a decent size
win:

dmt:/usr/lib64/gconv% du -c *.so | tail -1
7352total
dmt:/usr/lib64/gconv% du --apparent-size -c *.so | tail -1
6448total
dmt:/usr/lib64/gconv% size -t *.so | tail -1
4778516  161368    2016 4941900  4b684c 
(TOTALS)

Both things are possible here: we could teach rpm's find-requires to
know about iconv, _and_ link all the gconv modules together.

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

Re: [ANNOUNCE] Fedora support for Vulkan

[Adam Jackson]

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 not supported at all:

dmt:~/fedora/anvil/anvil% grep -A13 -- '->is_haswell' src/vulkan/anv_device.c
   if (device->info->is_haswell) {
  fprintf(stderr, "WARNING: Haswell Vulkan support is incomplete\n");
   } else if (device->info->gen == 7 && !device->info->is_baytrail) {
  fprintf(stderr, "WARNING: Ivy Bridge Vulkan support is incomplete\n");
   } else if (device->info->gen == 7 && device->info->is_baytrail) {
  fprintf(stderr, "WARNING: Bay Trail Vulkan support is incomplete\n");
   } else if (device->info->gen >= 8) {
  /* Broadwell, Cherryview, Skylake, Broxton, Kabylake is as fully
   * supported as anything */
   } else {
  result = vk_errorf(VK_ERROR_INCOMPATIBLE_DRIVER,
 "Vulkan not yet supported on %s", device->name);
  goto fail;
   }

As far as earlier chipsets are concerned, Ironlake and earlier are
almost certainly never going to be supported. I don't know about Sandy
Bridge, but I doubt it. If you're unsure which Intel GPU you have:

% lspci -n -s 0:2
00:02.0 0300: 8086:0166 (rev 09)

and then match the device ID (here 0166) to the architecture code name
here:

https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units

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

Re: [ANNOUNCE] Fedora support for Vulkan

[Adam Jackson]

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 windowAborted (core dumped)
> 
> Is there some prerequisite or configuration I'm missing?

DRI3 is a prerequisite, yes. The F23 builds of the intel driver had it
disabled until fairly recently, but this update should sort you out:

https://bodhi.fedoraproject.org/updates/FEDORA-2016-606ca05253

Alternatively you can enable it in xorg.conf:

Section "Device"
Identifier "intel"
Driver "intel"
Option "DRI" "3"
EndSection

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

[ANNOUNCE] Fedora support for Vulkan

[Adam Jackson]

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 benefit of a few decades of experience - it's a
much better match for both the hardware it targets, and the
applications trying to use the hardware.

== How do I get it? ==

$ sudo dnf copr enable ajax/vulkan
$ sudo dnf install vulkan anvil vkcube
$ vulkaninfo

Currently the repository includes the driver loader, as well as Intel's
open source drivers for gen8+ (Broadwell, Cherryview, Skylake, Broxton
and Kabylake) GPUs. The Intel drivers also have incomplete support for
Ivybridge, Haswell, and Baytrail devices; I can vouch that the
Ivybridge support is good enough to run the vkcube demo.

Package reviews have been created so this can all be integrated into
the OS directly:

https://bugzilla.redhat.com/show_bug.cgi?id=1308985
https://bugzilla.redhat.com/show_bug.cgi?id=1308986

== What else can I do with it? ==

The Khronos group hosts a number of open source repositories related to
the Vulkan standard, including the specification and conformance test
suite:

https://github.com/KhronosGroup?utf8=%E2%9C%93=vulkan

A number of sample applications are available:

https://github.com/SaschaWillems/Vulkan
https://github.com/McNopper/Vulkan

The API reference is available online:

https://www.khronos.org/registry/vulkan/specs/1.0/refguide/Vulkan-1.0-web.pdf
https://www.khronos.org/registry/vulkan/specs/1.0/apispec.html

Your favorite hardware driver or 3D game engine quite likely could use
help in enabling a Vulkan port, if you feel like getting your hands
dirty. The vulkan branch of Mesa would be a good place to start:

https://cgit.freedesktop.org/mesa/mesa/log/?h=vulkan

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

Re: Strange display bug

[Adam Jackson]

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 enabled to know what
> triggerer the bug
> 
> It is hard to write a bug report, so I made a 30 seconds video
> showing it.
> 
> https://www.youtube.com/watch?v=0kPOTBIGKLY
> 
> Sorry for this vague "report", but some bugs are just hard to
> describe.

Which GPU is this with? How big are the displays you're using?

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

Heads up: LLVM repackaging in F24

[Adam Jackson]

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.

This means the llvm consumers need to be relinked against the new set
of libs, and that's grinding its way through koji now. Hopefully those
will all complete before the next rawhide compose, but arm might hold
us back a bit.

On the plus side, this makes it possible to actually build lldb, clang,
and compiler-rt independently of the llvm core. This is a huge win from
my perspective because I absolutely do not care about clang and want
never again to get any bugs about it. If you're someone who does care
about one of those subprojects, they could use maintainers.

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

Re: Heads up: LLVM repackaging in F24

[Adam Jackson]

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 that's what you mean:

hyoscyamine:~/fedora% grep ^Source0 {compiler-rt,clang,lldb}/*.spec
compiler-rt/compiler-rt.spec:Source0:   
http://llvm.org/releases/%{version}/%{name}-%{version}.src.tar.xz
clang/clang.spec:Source0:   
http://llvm.org/releases/%{version}/cfe-%{version}.src.tar.xz
lldb/lldb.spec:Source0: 
http://llvm.org/releases/%{version}/%{name}-%{version}.src.tar.xz

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

Re: rawhide report: 20160115 changes

[Adam Jackson]

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 `main':
/builddir/build/BUILD/Atlas/src/Map.cxx:467: undefined reference to
`glewInit'

Which is due to missing -lGLEW on the link line, which is due to:

checking for glewInit in -lGLEW... no

Which is due to:

configure:7274: gcc -o conftest -O2 -g -pipe -Wall -Werror=format-
security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic
-I/usr/local//include -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-
hardened-ld -L/usr/local//lib conftest.c -lGLEW  -lplibul -lcurl
-lm  >&5
/usr/lib/gcc/x86_64-redhat-linux/5.3.1/../../../../lib64/libplibul.so:
undefined reference to `operator delete[](void*)'

Which appears to be because plib's shared libraries - which we just
conjure up out of thin air and aren't something upstream ships - are
linked with gcc not g++ so the C++ runtime never gets pulled in.  Fixed
in plib-1.8.5-14.fc24 and FlightGear-Atlas-0.5.0-0.16.cvs20141002.fc24.

> [avogadro]
>   avogadro-libs-1.1.1-15.fc24.i686 requires libGLEW.so.1.10

CMakeFiles/python-module.dir/swig.cpp.o: In function
`Molecule_OBMol(Avogadro::Molecule&)':
/builddir/build/BUILD/avogadro-
1.1.1/libavogadro/src/python/swig.cpp:554: undefined reference to
`OpenBabel::OBMol::OBMol(OpenBabel::OBMol const&)'
/builddir/build/BUILD/avogadro-
1.1.1/libavogadro/src/python/swig.cpp:554: undefined reference to
`OpenBabel::OBMol::~OBMol()'
/builddir/build/BUILD/avogadro-
1.1.1/libavogadro/src/python/swig.cpp:554: undefined reference to
`OpenBabel::OBMol::~OBMol()'
collect2: error: ld returned 1 exit status

No clue what's going on here, sorry.  The link line looks the same here
as in the previous successful f24 build, and it's the same version of
openbabel as then, so if I had to guess this is due to a behaviour
change between gcc 5.1.1 and 5.3.1.

> [gtatool]
>   gtatool-gui-2.1.0-9.fc24.i686 requires libGLEWmx.so.1.10

Missed this one because I forgot about libGLEWmx, which I'd honestly
like to retire, I don't think anything actually needs glewmx over glew.
Not that it builds in rawhide presently anyway:

Error: nothing provides libdap.so.17 needed by gdal-libs-2.0.1-3.fc24.i686

Fixed in gdal-2.0.1-4.fc24 and gtatool-2.1.0-10.fc24 (tentatively,
that's all rebuilt locally but building gdal is slow on arm).

> [k3d]
>   k3d-0.8.0.5-1.fc24.i686 requires libGLEWmx.so.1.10

Just missed because glewmx.  Fixed in k3d-0.8.0.5-2.fc24.

> [libreoffice]
>   1:libreoffice-core-5.1.0.1-2.fc24.i686 requires libGLEW.so.1.10
>   1:libreoffice-gtk3-5.1.0.1-2.fc24.i686 requires libGLEW.so.1.10
>   1:libreoffice-kde-5.1.0.1-2.fc24.i686 requires libGLEW.so.1.10
>   1:libreoffice-ogltrans-5.1.0.1-2.fc24.i686 requires libGLEW.so.1.10

Fixed in libreoffice-5.1.0.2-2.fc24, which built fine but wasn't
included in this compose because it took 15 hours to complete because
arm.

> [linphone]
>   linphone-3.6.1-11.fc24.i686 requires libGLEW.so.1.10
>   linphone-mediastreamer-3.6.1-11.fc24.i686 requires libGLEW.so.1.10

sipwizard.c:56:2: error: 'soup_xmlrpc_parse_method_response' is
deprecated: Use 'soup_xmlrpc_parse_response' instead
[-Werror=deprecated-declarations]

%configure --disable-strict, fixed in linphone-3.6.1-13.fc24.

> [mesa-demos]
>   mesa-demos-8.2.0-5.fc24.i686 requires libGLEW.so.1.10

A prior commit had accidentally clobbered the xdriinfo tarball line
from the sources file, so the srpm couldn't be assembled.  Fixed
in mesa-demos-8.3.0-2.fc24.

> [openmsx]
>   openmsx-0.11.0-4.fc23.i686 requires libGLEW.so.1.10

build/main.mk:26: *** No suitable Python interpreter found. Please
install Python version 2.x where x >= 5. If your Python interpreter is
installed in a non-standard location, please set the environment
variable PYTHON to the full path of the interpreter binary..  Stop.

Probably the build system could be ported to python3, but I am
certainly not the person who's going to do it. Fixed in openmsx-0.11.0-
6.fc24.

> [scorched3d]
>   scorched3d-44-5.fc23.i686 requires libGLEW.so.1.10

In file included from ../wxdialogs/MainDialog.cpp:35:0:
../../launcher/wxdialogs/TrueTypeFont.h:28:22: fatal error: freetype.h: No such 
file or directory
 #include 

This looks to be fallout from the freetype 2.6.1 upgrade, which means
scorched3d was never following freetype's include guidelines in the
first place:

https://lists.fedoraproject.org/pipermail/devel/2015-October/215402.html

Fixed in scorched3d-44-7.fc24.

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

Re: ELF arch question

[Adam Jackson]

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 going to have to read the elf class of the file to be sure?

If you consider ia64 to be a Fedora platform - and I would totally
forgive you if you didn't - then no, %{_libdir} is /usr/lib there. But
it's not clear to me from the question why you're trying to work this
out from the file type instead of just using %{_lib} or %_{libdir}.

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

Heads up: glew soname bump in F24

[Adam Jackson]

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 following source packages will be affected:

amanith
avogadro
blender
bzflag
calligra
cegui
cegui06
compat-SFML16
dreamchess
enblend
FlightGear-Atlas
gambas3
gimp-normalmap
glew
gource
hugin
kicad
libgltf
libprojectM
libreoffice
linphone
logstalgia
maniadrive
megaglest
mesa-demos
meshlab
OpenColorIO
opencsg
OpenImageIO
openmsx
openscad
pymol
root
rss-glx
scorched3d
sdljava
spring
supertux
toped
warzone2100
widelands
wt
wxmacmolplt

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

Re: On running gui applications as root

[Adam Jackson]

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 arbitrary
data to arbitrary files.  I can feed arbitrary input events to an emacs
window and have it modify any file the process could modify.  It's a
lot harder to get, say, virt-manager to write arbitrary data to
arbitrary places.

- ajax
-- 
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: On running gui applications as root

[Adam Jackson]

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 window, but I don't want to
> do that.

That's kind of a non sequitur. To a first order, there are zero root-
owned files you need to edit routinely. And I feel pretty comfortable
calling any counterexamples bugs that need fixing.

> And finally, it's *my computer*, dammit.

In the threat model being described, no, it is not, there's another
agent on the system subverting your use of it.

You are of course free to disregard that risk, or measure it in the
event and conclude it's safe enough, and in many cases it will in fact
be safe. Great, fine, that's a conclusion a consumer can come to. But
in the Fedora context we are the producer, not the consumer. Developing
an operating system means considering what is best in the general case,
and in the general case, if using the system requires a known-dangerous 
configuration, we've done our job poorly.

Phrased another way: no, it's not *your computer* we're talking about
here. The computer in question rightfully belongs to someone else; we
are here discussing how to be responsible for the code they allow us to
run on it.

- ajax
-- 
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: On running gui applications as root

[Adam Jackson]

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 you can run it, but no graphics for
> you!".

The point is, if things in Fedora require "run this bit of GUI as root"
in order to function, we've done a poor job. That people have bad
habits already is not sufficient justification to encourage them to
have more.

To the bug in question: probably we should make it so 'sudo gedit' does
work, but I'd still strongly discourage anyone from actually doing so.

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