f39 local kernel builds don't install

[David Airlie]

Just had upstream dev move to f39 and I tried it myself.

Building an installing a kernel from Linus now fails

make  -C /home/airlied/devel/kernel/build \
-f /home/airlied/devel/kernel/linux/Makefile install
make[1]: Entering directory '/home/airlied/devel/kernel/build'
make --no-print-directory -C /home/airlied/devel/kernel/build \
-f /home/airlied/devel/kernel/linux/Makefile install
# INSTALL /boot
  unset sub_make_done; /home/airlied/devel/kernel/linux/scripts/install.sh
grub2-mkrelpath: error: failed to get canonical path of `/boot/vmlinuz-6.6.0+'.
dirname: missing operand
Try 'dirname --help' for more information.

this appears to be because I now have /boot/bzImage-6.6.0+ instead of
/boot/vmlinuz-6.6.0+, but I don't see anything upstream that changed,
so I assume it's systemd kernel-install that broke?

Dave.
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: List of long term FTBFS packages to be retired next week

[David Airlie]

> waffle  ajax

rescued this,

Dave.
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Small rant: installer environment size

[David Airlie]

On Thu, Dec 8, 2022 at 10:46 PM Kevin Kofler via devel
 wrote:
>
> Adam Williamson wrote:
> > On Thu, 2022-12-08 at 07:57 +0100, Florian Weimer wrote:
> >> It has all the targets in it.  As it's for JIT, we'd only need one
> >> target.
> >
> > That sounds interesting, though of course the details of how to
> > implement it could be a bit tricky, I guess...
>
> Build /usr/lib64/libLLVM-15.so with only the host as the target, and a
> renamed /usr/lib64/libLLVM-cross-15.so with all the targets. Link the
> compilers against the latter.

We'd have to build host + amdgpu backends into it.

Dave.
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Testing of software that utilizes GPUs

[David Airlie]

On Thu, Oct 20, 2022 at 8:20 PM Benson Muite  wrote:
>
> Is there any way to test software that uses GPUs on COPR or Koji?  The
> number of such packages will likely increase in future.  In particular
> for software that uses ROCM, SYCL, Vulkan and OpenCL?

There is no way to test them with an actual GPU.

We have Vulkan and CL CPU emulation, Mesa will likely provide a CL CPU
side for testing soon alongside pocl,
and for Vulkan we have lavapipe.

Dave.
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[David Airlie]

Nope the _video.so files are the vaapi ones.

Replacing that package with rpmfusion built should work fine.

On Thu, Sep 29, 2022 at 10:26 AM Neal Gompa  wrote:
>
> On Thu, Sep 29, 2022 at 1:46 AM David Airlie  wrote:
> >
> > On Wed, Sep 28, 2022 at 4:30 PM Nicolas Chauvet  wrote:
> > >
> > > Le mar. 27 sept. 2022 à 20:57, David Airlie  a écrit :
> > > >
> > > > On Wed, Sep 28, 2022 at 4:02 AM Frantisek Zatloukal 
> > > >  wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > since this mesa change ( 
> > > > > https://src.fedoraproject.org/rpms/mesa/c/94ef544b3f2125912dfbff4c6ef373fe49806b52?branch=rawhide
> > > > >  ) in F37 and rawhide, the mesa package lost support for vaapi 
> > > > > accelerated encoding and decoding of h264, h265 and decoding of vc1 ( 
> > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2123998 ).
> > > > >
> > > > > It seems like a big regression from F36 for users with GPUs with open 
> > > > > source drivers (mainly AMD, maybe nVidia/other non x86...), that 
> > > > > affects common use-cases of Fedora Workstation, like watching videos, 
> > > > > in-house game streaming, attending online meetings and many more.
> > > >
> > > > This was an oversight being enabled prior to this, and I think we have
> > > > to remove it from older Fedora as well. Fedora cannot ship anything
> > > > that causes the OS to provide an API which exposes patent algorithms.
> > > >
> > > > The patent licensing around H264/H265 is such that providing this
> > > > could leave Red Hat and other Fedora distributors exposed to legal
> > > > problems.
> > > > Dave.
> > > >
> > > > > I'd like to ask:
> > > > > - Can somebody elaborate on reasons to change something that was 
> > > > > working in Fedora for some time already?
> > > > > - Is there any short/mid/long term plan to improve the situation?
> > > > > - Would it be possible to provide vaapi support at least as an 
> > > > > rpmfusion addon to alleviate the fallout in the short term?
> > > >
> > > > The last might be possible, but I'm not sure how to go about it.
> > > At least I've asked in 
> > > https://bugzilla.redhat.com/show_bug.cgi?id=2123998#c8
> > >
> > > That the fedora mesa package completely drops the vaapi backend, so a
> > > complementary package can just drop the missing files instead of
> > > rebuilding a whole mesa package.
> > > It would assume the fedora mesa package to have everything needed in
> > > order to cope with vaapi backend enabled in the core libraries and
> > > that the vaapi backend only provide the implementation.
> >
> > Please take a look at the rawhide changes I just pushed. This should
> > split things out sufficiently.
> >
>
> But wait, aren't these the DRI drivers[1]?
>
> [1]: 
> https://src.fedoraproject.org/rpms/mesa/c/07e1e0b1628d9c55d3858c4655409768c5c0b5de?branch=rawhide
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
>
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[David Airlie]

On Wed, Sep 28, 2022 at 4:30 PM Nicolas Chauvet  wrote:
>
> Le mar. 27 sept. 2022 à 20:57, David Airlie  a écrit :
> >
> > On Wed, Sep 28, 2022 at 4:02 AM Frantisek Zatloukal  
> > wrote:
> > >
> > > Hi,
> > >
> > > since this mesa change ( 
> > > https://src.fedoraproject.org/rpms/mesa/c/94ef544b3f2125912dfbff4c6ef373fe49806b52?branch=rawhide
> > >  ) in F37 and rawhide, the mesa package lost support for vaapi 
> > > accelerated encoding and decoding of h264, h265 and decoding of vc1 ( 
> > > https://bugzilla.redhat.com/show_bug.cgi?id=2123998 ).
> > >
> > > It seems like a big regression from F36 for users with GPUs with open 
> > > source drivers (mainly AMD, maybe nVidia/other non x86...), that affects 
> > > common use-cases of Fedora Workstation, like watching videos, in-house 
> > > game streaming, attending online meetings and many more.
> >
> > This was an oversight being enabled prior to this, and I think we have
> > to remove it from older Fedora as well. Fedora cannot ship anything
> > that causes the OS to provide an API which exposes patent algorithms.
> >
> > The patent licensing around H264/H265 is such that providing this
> > could leave Red Hat and other Fedora distributors exposed to legal
> > problems.
> > Dave.
> >
> > > I'd like to ask:
> > > - Can somebody elaborate on reasons to change something that was working 
> > > in Fedora for some time already?
> > > - Is there any short/mid/long term plan to improve the situation?
> > > - Would it be possible to provide vaapi support at least as an rpmfusion 
> > > addon to alleviate the fallout in the short term?
> >
> > The last might be possible, but I'm not sure how to go about it.
> At least I've asked in https://bugzilla.redhat.com/show_bug.cgi?id=2123998#c8
>
> That the fedora mesa package completely drops the vaapi backend, so a
> complementary package can just drop the missing files instead of
> rebuilding a whole mesa package.
> It would assume the fedora mesa package to have everything needed in
> order to cope with vaapi backend enabled in the core libraries and
> that the vaapi backend only provide the implementation.

Please take a look at the rawhide changes I just pushed. This should
split things out sufficiently.

Dave.
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[David Airlie]

On Wed, Sep 28, 2022 at 5:53 AM Michael Cronenworth  wrote:
>
> On 9/27/22 2:36 PM, David Airlie wrote:
> > The implicit IANAL is very clear here.
>
> I wish you had started the discussion the legal list yourself prior to the 
> git commit.
>
> A certain website that monitors this mailing list is probably already 
> preparing to
> post how Fedora 37 is no longer going to work with popular video codecs. Once 
> that
> post is made the Internet will take that story and bend it a few ways to make 
> us
> look bad.

The thing is we've had this ruling in place forever, a lot of people
misunderstood it, I only recently educated myself on the topic.

HW vendors do not pay for patents. The legal list posting above is a
perfect example of why technical people should not play at being
lawyers.

Think of it like a jigsaw puzzle, where the person who places the last
piece in the puzzle pays the license. But then stop thinking of it
like that and just assume it's a lot vaguer and way more legally
involved than that.

Dave.
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[David Airlie]

On Wed, Sep 28, 2022 at 5:34 AM Michael Cronenworth  wrote:
>
> On 9/27/22 1:56 PM, David Airlie wrote:
> > The patent licensing around H264/H265 is such that providing this
> > could leave Red Hat and other Fedora distributors exposed to legal
> > problems.
>
> How is Mesa violating H264/H265 patents? Mesa wasn't performing any patented
> functionality.
>
> If simply handling the bitstream is a violation like you say then 
> glibc/kernel could
> be patent infringing with an open() call. Let's not get that silly.

The implicit IANAL is very clear here.

Dave.
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[David Airlie]

On Wed, Sep 28, 2022 at 5:11 AM Chris Adams  wrote:
>
> Once upon a time, David Airlie  said:
> > On Wed, Sep 28, 2022 at 4:02 AM Frantisek Zatloukal  
> > wrote:
> > > since this mesa change ( 
> > > https://src.fedoraproject.org/rpms/mesa/c/94ef544b3f2125912dfbff4c6ef373fe49806b52?branch=rawhide
> > >  ) in F37 and rawhide, the mesa package lost support for vaapi 
> > > accelerated encoding and decoding of h264, h265 and decoding of vc1 ( 
> > > https://bugzilla.redhat.com/show_bug.cgi?id=2123998 ).
> > >
> > > It seems like a big regression from F36 for users with GPUs with open 
> > > source drivers (mainly AMD, maybe nVidia/other non x86...), that affects 
> > > common use-cases of Fedora Workstation, like watching videos, in-house 
> > > game streaming, attending online meetings and many more.
> >
> > This was an oversight being enabled prior to this, and I think we have
> > to remove it from older Fedora as well. Fedora cannot ship anything
> > that causes the OS to provide an API which exposes patent algorithms.
> >
> > The patent licensing around H264/H265 is such that providing this
> > could leave Red Hat and other Fedora distributors exposed to legal
> > problems.
>
> But isn't this just providing for hardware decoding, where (presumably)
> the hardware vendor arranged for whatever needed licenses?

The presumably is wrong. hw vendors do not cover the license costs for
the patents.

Dave.
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[David Airlie]

On Wed, Sep 28, 2022 at 4:02 AM Frantisek Zatloukal  wrote:
>
> Hi,
>
> since this mesa change ( 
> https://src.fedoraproject.org/rpms/mesa/c/94ef544b3f2125912dfbff4c6ef373fe49806b52?branch=rawhide
>  ) in F37 and rawhide, the mesa package lost support for vaapi accelerated 
> encoding and decoding of h264, h265 and decoding of vc1 ( 
> https://bugzilla.redhat.com/show_bug.cgi?id=2123998 ).
>
> It seems like a big regression from F36 for users with GPUs with open source 
> drivers (mainly AMD, maybe nVidia/other non x86...), that affects common 
> use-cases of Fedora Workstation, like watching videos, in-house game 
> streaming, attending online meetings and many more.

This was an oversight being enabled prior to this, and I think we have
to remove it from older Fedora as well. Fedora cannot ship anything
that causes the OS to provide an API which exposes patent algorithms.

The patent licensing around H264/H265 is such that providing this
could leave Red Hat and other Fedora distributors exposed to legal
problems.
Dave.

> I'd like to ask:
> - Can somebody elaborate on reasons to change something that was working in 
> Fedora for some time already?
> - Is there any short/mid/long term plan to improve the situation?
> - Would it be possible to provide vaapi support at least as an rpmfusion 
> addon to alleviate the fallout in the short term?

The last might be possible, but I'm not sure how to go about it.

Another consideration would be to somehow gate at least the h264 bits
on having openh264 installed, since then in theory a system consuming
h264 formats would be covered.

Dave.
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Suggestion: Use a unified kernel image by default in the future.

[David Airlie]

On Mon, Jun 27, 2022 at 6:33 PM Gerd Hoffmann  wrote:
>
> On Sun, Jun 19, 2022 at 08:54:51PM -, Sharpened Blade via devel wrote:
> > Use unified kernel images by default for new releases. This can allow
> > for the local installation to sign the kernel and the initrd, so the
> > boot chain can be verified until after the uefi. Currently, the initrd
> > can be modified by attackers, so even if the / partition is encrypted,
> > the systems data can be read on the next boot. If the kernel image,
> > which includes the command line, and the initrd, is signed  then it is
> > harder to comprimise the system. The system can still be comprimised
> > if the uefi is modified.
> >
> > If this was used, then the kernel could no longer be signed in the
> > package by the fedora infrastructure.
>
> I'd rather have fedora ship a unified + signed kernel image with a
> generic (aka 'dracut --no-hostonly') initrd instead of generating one
> on the local system.

I think the issue with this is the initrd side blows out a lot, you
include all the firmware for all the modules in the system and then
you have 3 of them in /boot.

I do wonder if it's possible to use multiple initrds, and maybe have
the firmware in a separate initrd shared between all installed kernels
if we go down this route.

Dave.
___
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)

[David Airlie]

On Thu, Apr 7, 2022 at 12:33 PM Luya Tshimbalanga
 wrote:
>
> Reading the comments, it seems the overlooked word is “depreciated” meaning 
> users will have time to properly transition their hardware.

Transition to what though, another distro?

moving to new hw won't help maintain things for older stuff.

I want to maintain one distro on the hw I maintain upstream drivers
for, this will stop me doing that with Fedora. I work for Red Hat, I
don't really want to move off Fedora, but having to keep Ubuntu and
Fedora mixtures would be a pita, and CentOS can't even build the newer
driver stacks without serious intervention.

Dave.
___
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)

[David Airlie]

On Wed, Apr 6, 2022 at 1:18 AM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
>
> == Summary ==
> Make UEFI a hardware requirement for new Fedora installations on
> platforms that support it (x86_64).  Legacy BIOS support is not
> removed, but new non-UEFI installation is not supported on those
> platforms.  This is a first step toward eventually removing legacy
> BIOS support entirely.
>
> == Owner ==
> * Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří
> Konečný]], [[User:bcl| Brian C. Lane]]
> * Email: rharw...@redhat.com
>
>
> == Detailed Description ==
> UEFI is defined by a versioned standard that can be tested and
> certified against.  By contrast, every legacy BIOS is unique. Legacy
> BIOS is widely considered deprecated (Intel, AMD, Microsoft, Apple)
> and on its way out.  As it ages, maintainability has decreased, and
> the status quo of maintaining both stacks in perpetuity is not viable
> for those currently doing that work.
>
> It is inevitable that legacy BIOS will be removed in a future release.
> To ease this transition as best we can, there will be a period (of at
> least one Fedora release) where it will be possible to boot using the
> legacy BIOS codepaths, but new installations will not be possible.
> While it would be easier for us to cut support off today, our hope is
> that this compromise position will make for a smoother transition.
> Additional support with issues during the transition would be
> appreciated.
>


Just a personal frustration here, I recently worked on a project to
rewrite the mesa driver for a range of intel GPUs from gen4->gen7, we
ship it in Fedora 35 as the default driver on those GPUs.

It was of great benefit to me and the community that I could use
Fedora for developing this sort of feature, and have a place to roll
it out for validation. This change would invalidate a wide range of
the machines I wrote this on from being used.

I have a fully operational 965G desktop machine that runs f35, a
mostly operational 965GM HP laptop with busted fan, and a GM45 in a
Thinkpad W500 machine that are all pre-UEFI but still can run fedora.
I've got one Ironlake HP laptop that has UEFI but only if I hand pick
the boot file since its UEFI implementation has a bunch of BIOS
warnings around it saying not to enable it for normal use. The T440s I
have doesn't seem to be installed in UEFI mode and that likely means I
need to nuke it and start again.

This would mean for future projects I'd probably have to consider
moving off Fedora would definitely count as a major pita for me, I
also cleanly installed all these machines with F35 as I didn't want
the behaviour of updating from f31 to f33 to f35 etc.

Dave.
___
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: spirv-tools ftbfs no idea what the compiler is telling me.

[David Airlie]

just adding Jakub.

On Sun, Jan 30, 2022 at 7:50 AM Artur Frenszek-Iwicki
 wrote:
>
> Bumping this since I have an identical issue with colobot - the compilation 
> errors out when a C-like string literal is assigned to an std::string, with 
> the compiler providing the same "memcpy accessing... overlaps lots-of-bytes 
> at offset -3" error message.
>
> A.FI.
> ___
> 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

spirv-tools ftbfs no idea what the compiler is telling me.

[David Airlie]

This seems serious, but I've no idea what it means.

The line of code appears to be 398 marked below.

std::string spvTargetEnvList(const int pad, const int wrap) {
  std::string ret;
  size_t max_line_len = wrap - pad;  // The first line isn't padded
  std::string line;
  std::string sep = "";

  for (auto& name_env : spvTargetEnvNameMap) {
std::string word = sep + name_env.first;
if (line.length() + word.length() > max_line_len) {
  // Adding one word wouldn't fit, commit the line in progress and
  // start a new one.
  ret += line + "\n";
  line.assign(pad, ' ');
  // The first line is done. The max length now comprises the
  // padding.
  max_line_len = wrap;
}
line += word;
398 >>sep = "|";
  }

  ret += line;

  return ret;
}

In file included from /usr/include/c++/12/string:40,
 from
/builddir/build/BUILD/SPIRV-Tools-21e3f681e2004590c7865bc8c0195a4ab8e66c88/source/spirv_target_env.h:18,
 from
/builddir/build/BUILD/SPIRV-Tools-21e3f681e2004590c7865bc8c0195a4ab8e66c88/source/spirv_target_env.cpp:15:
In function 'std::char_traits::copy(char*, char const*, unsigned int)',
inlined from 'std::__cxx11::basic_string, std::allocator >::_S_copy(char*, char
const*, unsigned int)' at
/usr/include/c++/12/bits/basic_string.h:423:21,
inlined from 'std::__cxx11::basic_string, std::allocator >::_S_copy(char*, char
const*, unsigned int)' at
/usr/include/c++/12/bits/basic_string.h:418:7,
inlined from 'std::__cxx11::basic_string, std::allocator >::_M_replace(unsigned
int, unsigned int, char const*, unsigned int)' at
/usr/include/c++/12/bits/basic_string.tcc:532:22,
inlined from 'std::__cxx11::basic_string, std::allocator >::assign(char const*)'
at /usr/include/c++/12/bits/basic_string.h:1647:19,
inlined from 'std::__cxx11::basic_string, std::allocator >::operator=(char
const*)' at /usr/include/c++/12/bits/basic_string.h:815:28,
inlined from 'spvTargetEnvList[abi:cxx11](int, int)' at
/builddir/build/BUILD/SPIRV-Tools-21e3f681e2004590c7865bc8c0195a4ab8e66c88/source/spirv_target_env.cpp:398:11:
/usr/include/c++/12/bits/char_traits.h:431:56: error: 'memcpy'
accessing 2147483650 or more bytes at offsets [-1073741822,
3221225470] and [-1073741823, 1073741824] overlaps 2147483653 bytes at
offset -3 [-Werror=restrict]
  431 | return static_cast(__builtin_memcpy(__s1,
__s2, __n));
  |^
cc1plus: all warnings being treated as errors
___
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: How to handle ABI breakage in Rawhide

[David Airlie]

On Mon, Dec 6, 2021 at 12:49 PM Bernie Innocenti  wrote:
>
> Hello David,
>
> This spirv-tools-libs build changed the ABI of libSPIRV-Tools.so in
> Rawhide on Nov 23:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1858749
>
> The shared lib has no soversion, and other libs in Fedora depend on it:
>
>   mpv: symbol lookup error: /lib64/libshaderc_shared.so.1: undefined
> symbol: _ZN8spvtools23CreateAggressiveDCEPassEv
>
> On Dec 2nd, libshaderc was also rebuilt, and now it agrees with the new
> ABI of spirv-tools-libs:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1862359
>
> However, libplacebo would also need rebuilding:
>
>undefined symbol: _ZN8spvtools23CreateAggressiveDCEPassEv
> (/lib64/libplacebo.so.157)
>
> I rebuilt it locally, but there are more packages using the old ABI:
>
>% mpv
>mpv: symbol lookup error: /lib64/libavfilter.so.7: undefined symbol:
> _ZN8spvtools23CreateAggressiveDCEPassEv
>
> I would like to request that we revert the ABI of libSPIRV-Tools.so or,
> at least bump the soversion to avoid silently breaking all dependencies.
>
> What are the current Fedora packaging guideline regarding ABI stability
> of shared libraries?

This library has no ABI guarantees upstream, which is painful to deal
with. I've figured out what they messed up and hopefully put things
back like they should be with the correct ABI.

Thanks for the headsup, sorry it took a bit longer to get to it,

I've filed an upstream MR to restore the ABI there, to avoid it in future.

Dave.

>
> Are there no automated checks to prevent this common accident? This
> happens frequently, and discourages Rawhide testing.
>
> Thanks,
>
> --
> _ // Bernie Innocenti
> \X/  https://codewiz.org/
>
___
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: systemd-oomd blows away the gnome-shell desktop session

[David Airlie]

On Wed, Jul 28, 2021 at 12:14 PM Aleksei Bavshin
 wrote:
>
> On 7/27/21 6:23 PM, David Airlie wrote:
> > Hi,
> >
> > I've been using f34 with gnome/wayland session on a 16MB machine which
> > has 8GB zram swap configured.
> >
> > If I build anything large inside my desktop environment (llvm/clang)
> > from a gnome-terminal, systemd-oomd blows away my whole desktop slice.
> > This seems overly hostile.
> >
> > Now in theory I can use systemd-run to run a shell but my
> > understanding is the DE is meant to be smarter here.
> >
> > Is it at least launching firefox etc in new cgroups or are all
> > processes on my desktop in one big cgroup?
>
> IIRC, gnome-terminal supposed to put each tab into a new cgroup. And
> Gnome would create cgroup for each desktop application started via Gnome
> shell or glib functions.
> While it's still a bit fragile and there's a lot of ways to escape (i.e.
> xdg-open, third-party application launchers, starting apps from the
> terminal, etc.), normal use in Gnome should work just fine.
>
> ---
>  From your description, something obviously went wrong: either
> assignment of cgroups has failed and everything is in the same big
> group, or sd-oomd made a bad shot. systemd-cgls should show which it is.

Thanks for the hint, systemd-cgls at least makes it appear as if everything
is in different slice

─user.slice
│ └─user-1000.slice
│   ├─user@1000.service
│   │ ├─session.slice

│   │ ├─app.slice

│   │ │ ├─app-org.gnome.Terminal.slice
│   │ │ │ ├─vte-spawn-f4a41678-fa09-4ab7-b6d4-d89e18bdb5f4.scope

I do find it strange it picks
Killed 
/user.slice/user-1000.slice/user@1000.service/session.slice/org.gnome.Shell@wayland.service

I might have to dig into systemd-oomd to see why it picks totally the
wrong option here.

Is there a command to list the current memory usage for each cgroup?

Dave.
___
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

systemd-oomd blows away the gnome-shell desktop session

[David Airlie]

Hi,

I've been using f34 with gnome/wayland session on a 16MB machine which
has 8GB zram swap configured.

If I build anything large inside my desktop environment (llvm/clang)
from a gnome-terminal, systemd-oomd blows away my whole desktop slice.
This seems overly hostile.

Now in theory I can use systemd-run to run a shell but my
understanding is the DE is meant to be smarter here.

Is it at least launching firefox etc in new cgroups or are all
processes on my desktop in one big cgroup?

Even if it launched gnome-terminal in another group I assume this
would result in it blowing away all my open terminals just to kill the
compiler/linker that is consuming all the RAM/swap. Again this seems
overly hostile.

Any ideas other than campaigning for systemd-oomd to be turned off again?

Dave.
___
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: i686 build OOMing

[David Airlie]

On Thu, May 20, 2021 at 6:45 PM Leigh Scott  wrote:
>
> Is disabling debug on i686 an option?
>
> --- a/vulkan-validation-layers.spec
> +++ b/vulkan-validation-layers.spec
> @@ -43,7 +43,12 @@ developing applications that use %{name}.
>
>  %build
>  # Decrease debuginfo verbosity to reduce memory consumption even more
> +%ifarch %{ix86}
> +%global debug_package %{nil}
> +%global optflags %(echo %{optflags} | sed 's/-g /-g0 /')
> +%else
>  %global optflags %(echo %{optflags} | sed 's/-g /-g1 /')
> +%endif
>  %global optflags %(echo %{optflags} | sed 's/-O2 /-O1 /')
>

I ended up dropping to O1 as sufficient, I don't think it'll really
matter for this package to not be optimised.

But I could consider dropping to g0 on ix86 I suppose.

But it's mostly a debugging package so I think it might not be optimal
to have no symbols for it at all.

Dave.
___
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: i686 build OOMing

[David Airlie]

On Thu, May 20, 2021 at 4:51 AM Kevin Fenzi  wrote:
>
> On Tue, May 18, 2021 at 04:59:50PM -0600, Jeff Law wrote:
> >
> > On 5/18/2021 4:44 PM, David Airlie wrote:
> > > https://kojipkgs.fedoraproject.org//work/tasks/3814/68223814/build.log
> > >
> > > cd 
> > > /builddir/build/BUILD/Vulkan-ValidationLayers-sdk-1.2.176.1/i686-redhat-linux-gnu/layers
> > > && /usr/bin/g++ -DAPI_NAME=\"Vulkan\" -DVK_ENABLE_BETA_EXTENSIONS
> > > -DVK_USE_PLATFORM_WAYLAND_KHR -DVK_USE_PLATFORM_WAYLAND_KHX
> > > -DVK_USE_PLATFORM_XCB_KHR -DVK_USE_PLATFORM_XCB_KHX
> > > -DVK_USE_PLATFORM_XLIB_KHR -DVK_USE_PLATFORM_XLIB_KHX
> > > -DVK_USE_PLATFORM_XLIB_XRANDR_EXT -DVkLayer_khronos_validation_EXPORTS
> > > -I/builddir/build/BUILD/Vulkan-ValidationLayers-sdk-1.2.176.1/layers
> > > -I/builddir/build/BUILD/Vulkan-ValidationLayers-sdk-1.2.176.1/layers/generated
> > > -I/usr/include/glslang -I/usr/include/spirv/include
> > > -I/builddir/build/BUILD/Vulkan-ValidationLayers-sdk-1.2.176.1/i686-redhat-linux-gnu
> > > -I/builddir/build/BUILD/Vulkan-ValidationLayers-sdk-1.2.176.1/i686-redhat-linux-gnu/layers
> > > -O2 -flto=auto -ffat-lto-objects -fexceptions -g1
> > > -grecord-gcc-switches -pipe -Wall -Werror=format-security
> > > -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
> > > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> > > -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
> > > -m32 -march=i686 -mtune=generic -msse2 -mfpmath=sse -mstackrealign
> > > -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
> > > -Wpointer-arith -Wno-unused-function -Wno-sign-compare -DNDEBUG -fPIC
> > > -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers
> > > -fno-strict-aliasing -fno-builtin-memcmp -fvisibility=hidden
> > > -Wimplicit-fallthrough=0 -std=gnu++11 -MD -MT
> > > layers/CMakeFiles/VkLayer_khronos_validation.dir/generated/chassis.cpp.o
> > > -MF CMakeFiles/VkLayer_khronos_validation.dir/generated/chassis.cpp.o.d
> > > -o CMakeFiles/VkLayer_khronos_validation.dir/generated/chassis.cpp.o
> > > -c 
> > > /builddir/build/BUILD/Vulkan-ValidationLayers-sdk-1.2.176.1/layers/generated/chassis.cpp
> > > cc1plus: out of memory allocating 65536 bytes after a total of 3310292992 
> > > bytes
> > >
> > > We already use -g1 to try and reduce memory usage, and I tried not
> > > doing parallel jobs in case it was too much? any suggestions, is this
> > > LTO?
> >
> > Not likely LTO since this isn't a link phase AFAICT.
>
> And parallel jobs reduction isn't likely to help out, it looks like the
> single cc1plus process is hitting the 3GB/1GB split anyhow. ;(

Oh wow I forgot that existed, so it's not even a VM configuration issue.

I'll go reproduce somewhere locally and experiment in more detail by
removing my hair.

Dave.
___
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

i686 build OOMing

[David Airlie]

https://kojipkgs.fedoraproject.org//work/tasks/3814/68223814/build.log

cd 
/builddir/build/BUILD/Vulkan-ValidationLayers-sdk-1.2.176.1/i686-redhat-linux-gnu/layers
&& /usr/bin/g++ -DAPI_NAME=\"Vulkan\" -DVK_ENABLE_BETA_EXTENSIONS
-DVK_USE_PLATFORM_WAYLAND_KHR -DVK_USE_PLATFORM_WAYLAND_KHX
-DVK_USE_PLATFORM_XCB_KHR -DVK_USE_PLATFORM_XCB_KHX
-DVK_USE_PLATFORM_XLIB_KHR -DVK_USE_PLATFORM_XLIB_KHX
-DVK_USE_PLATFORM_XLIB_XRANDR_EXT -DVkLayer_khronos_validation_EXPORTS
-I/builddir/build/BUILD/Vulkan-ValidationLayers-sdk-1.2.176.1/layers
-I/builddir/build/BUILD/Vulkan-ValidationLayers-sdk-1.2.176.1/layers/generated
-I/usr/include/glslang -I/usr/include/spirv/include
-I/builddir/build/BUILD/Vulkan-ValidationLayers-sdk-1.2.176.1/i686-redhat-linux-gnu
-I/builddir/build/BUILD/Vulkan-ValidationLayers-sdk-1.2.176.1/i686-redhat-linux-gnu/layers
-O2 -flto=auto -ffat-lto-objects -fexceptions -g1
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
-m32 -march=i686 -mtune=generic -msse2 -mfpmath=sse -mstackrealign
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-Wpointer-arith -Wno-unused-function -Wno-sign-compare -DNDEBUG -fPIC
-Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers
-fno-strict-aliasing -fno-builtin-memcmp -fvisibility=hidden
-Wimplicit-fallthrough=0 -std=gnu++11 -MD -MT
layers/CMakeFiles/VkLayer_khronos_validation.dir/generated/chassis.cpp.o
-MF CMakeFiles/VkLayer_khronos_validation.dir/generated/chassis.cpp.o.d
-o CMakeFiles/VkLayer_khronos_validation.dir/generated/chassis.cpp.o
-c 
/builddir/build/BUILD/Vulkan-ValidationLayers-sdk-1.2.176.1/layers/generated/chassis.cpp
cc1plus: out of memory allocating 65536 bytes after a total of 3310292992 bytes

We already use -g1 to try and reduce memory usage, and I tried not
doing parallel jobs in case it was too much? any suggestions, is this
LTO?

Dave.
___
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: mesa 21.0.0-rc3 making rawhide really unstable?

[David Airlie]

On Thu, Feb 4, 2021 at 12:02 AM Fabio Valentini  wrote:
>
> On Wed, Feb 3, 2021 at 12:42 PM Milan Crha  wrote:
> >
> > On Wed, 2021-02-03 at 15:26 +1000, David Airlie wrote:
> > > Please test:
> > >
> > > mesa-21.0.0~rc3-2.fc34
> > >
> > > which I just built for rawhide.
> >
> > Hi,
> > for what it's worth, it helped me with gdm, it opens now, but I cannot
> > log in to "GNOME on Xorg", I'm immediately returned back to the gdm.
> > Logging to "GNOME" (aka Wayland) works.
>
> Can confirm, gdm and gnome/wayland works again, but all Xorg based
> sessions are now even more broken, e.g. you're returned to gdm a
> second after you enter your password.

Has anyone got a backtrace they could put in a bug? I'm not seeing a
crash with X.org here in my test VMs.

Dave.
___
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: mesa 21.0.0-rc3 making rawhide really unstable?

[David Airlie]

On Wed, Feb 3, 2021 at 1:17 AM Fabio Valentini  wrote:
>
> Hi everybody,
>
> After updating my rawhide VMs today, it looks like
> mesa-21.0.0~rc3-1.fc34 is making all sessions really unstable.
> gnome-shell (wayland) repeatedly crashes after opening any windows,
> and Xorg based LightDM or Pantheon session crashes at launch with
> compositor segfaults. One system was fine until I updated mesa, so
> this issue should really be caused by the mesa 20 → 21 update ...
>
> Can somebody shine light on whether this is limited to my systems or
> if this is a general problem with mesa 21?
>
Please test:

mesa-21.0.0~rc3-2.fc34

which I just built for rawhide.

Dave.
___
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

f33/f34 amdgpu firmware for 6800/6900

[David Airlie]

I've packaged up the firmware for the new AMD GPUs in linux-firmware
in updates-testing. I doubt anyone will have access to one of these
cards for a few weeks anyways, but if somene does end up with one,
please see how it fairs.

https://bodhi.fedoraproject.org/updates/FEDORA-2020-ff2b09cd0a

Dave.
___
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: Help needed to fix a FTBFS (shaderc)

[David Airlie]

On Mon, Aug 10, 2020 at 6:55 PM Leigh Scott  wrote:
>
> > On Mon, Aug 10, 2020 at 2:57 AM Leigh Scott  > wrote:
> >
> > Yeah glslang sucks in terms of providing a stable API, I think
> > upstream would need to address these things,
> >
> > Though I hadn't realised it would FTBFS things that badly.
> >
> > Dave.
>
> Can we revert back to the old version please?, it builds fine.
> Here's a working spec file  
> https://leigh123linux.fedorapeople.org/pub/SPECS/glslang.spec
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=49015264
>
> TBH it looks like you were having a bad cmake day :-)

Initially that was the bad thing, but the upstream project appears to
have split those two libraries out, I'd prefer to keep tracking
upstream in rawhide, maybe we can get upstream to address the lack of
ABI in the disaster that is glslang.

Dave.
___
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: Help needed to fix a FTBFS (shaderc)

[David Airlie]

On Mon, Aug 10, 2020 at 2:57 AM Leigh Scott  wrote:
>
> I found this
>
> https://github.com/KhronosGroup/glslang/commit/b8c3386ec00b9de2925732c0a29c588d60f8c8fd
>
> and added the new libs ( -lMachineIndependent -lGenericCodeGen ) to the link 
> flags

Yeah glslang sucks in terms of providing a stable API, I think
upstream would need to address these things,

Though I hadn't realised it would FTBFS things that badly.

Dave.
___
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: Better interactivity in low-memory situations

[David Airlie]

On Fri, Aug 16, 2019 at 7:48 AM Chris Murphy  wrote:
>
> On Thu, Aug 15, 2019 at 2:19 PM Chris Murphy  wrote:
> >
> > [  718.068633] fmac.local kernel: SLUB: Unable to allocate memory on
> > node -1, gfp=0x900(GFP_NOWAIT|__GFP_ZERO)
> > [  718.068636] fmac.local kernel:   cache: page->ptl, object size: 72,
> > buffer size: 72, default order: 0, min order: 0
> > [  718.068639] fmac.local kernel:   node 0: slabs: 296, objs: 16576, free: 0
> > [  718.068704] fmac.local kernel: chronyd: page allocation failure:
> > order:0, mode:0x800(GFP_NOWAIT),
> > nodemask=(null),cpuset=/,mems_allowed=0
> >
> > Not sure what to make of that.
>
> Asked on #fedora-kernel, it's a known issue with 5.3.0-rc4 and drm.
>

Nope it's not that.

Something has leaked all your memory (not drm).

Dave.
___
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: Better interactivity in low-memory situations

[David Airlie]

On Sun, Aug 11, 2019 at 2:57 AM Georg Sauthoff  wrote:
>
> On Fri, Aug 09, 2019 at 03:50:43PM -0600, Chris Murphy wrote:
> [..]
> > Problem and thesis statement:
> > Certain workloads, such as building webkitGTK from source, results in
> > heavy swap usage eventually leading to the system becoming totally
> > unresponsive. Look into switching from disk based swap, to swap on a
> > ZRAM device.
> >
> > Summary of findings (restated, but basically the same as found at [2]):
> > Test system, Macbook Pro, Intel Core i7-2820QM (4/8 cores), 8GiB RAM,
> > Samsung SSD 840 EVO, Fedora Rawhide Workstation.
> > Test case, build WebKitGTK from source.
> [..]
>
> To avoid such issues I disable swap on my machines. I really don't see
> the point of having a swap partition if you have 16 or 32 GiB RAM. Even
> with 8 GiB I disable swap.

Disabling swap doesn't avoid the issues, it can in fact make them worse.

If you have apps allocate memory they don't always OOM before the
kernel tries to evict text pages, but since SSDs are fast it then
tries to pull back in those text pages before realising (that is what
most of the latest rounds of articles has been about). Something like
firefox runs with no swap, starts to need more memory than the system
has, parts of firefox executable get paged out, but then are needed
for firefox to use the RAM, and round in circles it goes.

Having swap is still in this day and age better for your system that
not having it.

Dave.
___
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

[David Airlie]

On Tue, Jul 23, 2019 at 6:03 AM Josh Boyer  wrote:
>
> On Mon, Jul 22, 2019 at 3:27 PM Ben Cotton  wrote:
> >
> > https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
> >
> > == Summary ==
> > Fedora currently uses the original K8 micro-architecture (without
> > 3DNow! and other AMD-specific parts) as the baseline for its
> > x86_64 architecture.  This baseline dates back to 2003
> > and has not been updated since.  As a result, performance of Fedora is
> > not as good as it could be on current CPUs.
> >
> > This change to update the micro-architecture level for the
> > architecture to something more recent.
> >
> > == Owner ==
> > * Name: [[User:fweimer| Florian Weimer]]
> > * Email: [mailto:fwei...@redhat.com fwei...@redhat.com]
> >
> > == Detailed Description ==
> >
> > 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].
>
> Would it be possible to include some basic instructions or a script
> for people to run on their systems to see if they are AVX2 compliant?
> That would help them assess the impact.

They did below, grep avx2 /proc/cpuinfo.

But don't bother, this will just get embarrassing and turn into a pile
on. I think this should be retracted before it ends up being a
phoronix article making the project look bad.

Dave.
___
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

[David Airlie]

On Tue, Jul 23, 2019 at 5:58 AM Ben Cotton  wrote:
>
> On Mon, Jul 22, 2019 at 3:45 PM Solomon Peachy  wrote:
> >
> > But since anectdote != data, are there any sort of deployment numbers
> > out there that show how many Fedora deployments are on AVX[2]-capable
> > hardware?
> >
> There are no stats available that could be considered defensible. At
> best, we could come up with some estimates based on the stats from
> other sources that we might assume have a similar profile as Fedora.
> I'm not sure if that data exists anywhere, though.
>
> My main personal machine also lacks AVX2-capable hardware, so from a
> personal perspective, I'm not super keen on this change. I'm
> privileged enough to be able to upgrade my hardware if required, but I
> recognize that it's not a reasonable request for others.
>
> > > Fedora will use current CPUs more efficiently, increasing performance
> > > and reducing power consumption.
> >
> > I think we need to see some actual benchmarks demonstrating this.  For
> > the core kernel and system libraries rather than microbenchmarks or
> > specific applications that already sport AVX[2] codepaths.
> >
> I agree. It would be good to see some more specifics about what the
> benefit will be. That's the only way we can decide if it's worth the
> cost.

I think we don't need to bother, there is way too much hardware still
being sold by CPU vendors that don't meet this baseline.

We aren't Apple. If you want to add avx2 optimised binaries to the
system work out how to do that, create fat binary support for Linux,
add a second set of packages for cases that it might matter etc.

Just unilaterally removing a whole chunk of the x86 architecture
support isn't a plan, benchmarks or stats won't help.

Dave.
___
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

[David Airlie]

On Tue, Jul 23, 2019 at 5:46 AM Solomon Peachy  wrote:
>
> On Mon, Jul 22, 2019 at 02:51:27PM -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].
>

Can we just kill this and pretend it was never suggested.

From a desktop point of view this would be a really bad idea, I think
you should expand your preliminary discussions to CPU vendors who
aren't Intel server chips.

Dave.
___
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: glibc-headers troubles with rawhide on ARM

[David Airlie]

On Tue, Jul 2, 2019 at 10:57 PM Olivier Fourdan  wrote:
>
> Hi,
>
> On Tue, Jul 2, 2019 at 2:22 PM Peter Robinson  wrote:
> > On Mon, Jul 1, 2019 at 12:02 PM Florian Weimer  wrote:
> > > [...]
> > >
> > >  on Arm hasn't worked for a long, long time, so we've removed
> > > it from glibc.  Sorry it broke the build.
> >
> > It seems xorg-x11-server was also using this in it's builds:
> >
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=35892190
>
> Precisely, that's why I raised the issue here :)
>
> FWIW, I managed to get the Xserver to build by removing the `#include
> ` and references to outb/outw/outl :
>
> http://koji.fedoraproject.org/koji/taskinfo?taskID=35981723
>
> But I don;t think it'll fly with the Xorg drivers, as those are most
> likely the consumers of outb/outw/outl.
>
> So I filed https://gitlab.freedesktop.org/xorg/xserver/issues/840
> upstream to gauge the water and see what we can do.

Any driver that does port io. should probably not be built on ARM,
unless the port io can be disabled anyways.

Dave.
___
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: Orphaning: llvm5.0, clang5.0, llvm6.0, clang6.0

[David Airlie]

On Sat, Feb 9, 2019 at 5:50 PM Igor Gnatenko
 wrote:
>
> https://cgit.freedesktop.org/beignet/
>
> Last commits are from 2018/08 which is half year ago.
>
> I'd like to keep it, but try using master branch.

Beignet is dead upstream, Intel are no longer supporting it.

Dave.
___
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

packaged jenkins is broken

[David Airlie]

So we ship a jenkins in F29 at least that is broken on install due to
what looks like an incompatability with dom4j.

Upstream it looks like jenkins via stapler-jelly uses a fork of dom4j,
and the standard dom4j shipped in Fedora doesn't work the same.

There have been bugs filed, but nobody seems to have cared enough to
fix it, it looks to have been broken for at least 2 release cycles,
should we be looking at dropping jenkins as nobody could be using the
web frontend at least in the current state.

Dave.
___
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: Intention to orphan vulkan stack

[David Airlie]

> Hi Leigh,
>
> Please give them all to me.
>
> Thanks,

Oh and thanks for all the work you've done on packaging them up until now!

Dave.

> Dave.
> >
> > glslang
> > spirv-headers
> > spirv-tools
> > vulkan-headers
> > vulkan-loader
> > vulkan-tools
> > vulkan-validation-layers
> > ___
> > 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
___
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: Intention to orphan vulkan stack

[David Airlie]

On Wed, Nov 7, 2018 at 9:13 AM Leigh Scott  wrote:
>
> I haven't got the time or energy to maintain these packages any more, any 
> takers?

Hi Leigh,

Please give them all to me.

Thanks,
Dave.
>
> glslang
> spirv-headers
> spirv-tools
> vulkan-headers
> vulkan-loader
> vulkan-tools
> vulkan-validation-layers
> ___
> 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
___
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: Wyland is a disaster

[David Airlie]

On Thu, Feb 1, 2018 at 12:13 PM, Tomasz Kłoczko 
wrote:

>
> On 1 February 2018 at 01:42, Peter Hutterer 
> wrote:
> [..]
>
>> > So event4 it is in my case touch pad and event5  it is Logitech M185
>> mouse.
>> > In other words: those "libinput bug" log entries looks like are not
>> related
>> > to emitting those short bursts of repeating keystrokes.
>>
>> not directly, but they indicate where the issue is: key repeat is handled
>> in
>> the clients, not in libinput. With delays like this it's easy to see why
>> you
>> would get key repeat - if your key release event is delayed by 300ms or
>> more
>> the client will handle repeats before it gets the events.
>>
>> But the real cause of the issue is that you're getting crazy delays
>> because
>> gnome-shell is too busy with something else. The rest is fallout from
>> that.
>>
>
> So that is quite possible explanation and cause of those delays probably
> is in what I've already described.
> Every few second in kernel messages I have sequence:
>
> [74330.405990] [drm] PCIE gen 2 link speeds already enabled
> [74330.417096] [drm] PCIE GART of 1024M enabled (table at
> 0x00162000).
> [74330.417206] radeon :01:00.0: WB enabled
> [74330.417212] radeon :01:00.0: fence driver on ring 0 use gpu addr
> 0x2c00 and cpu addr 0xd8c75981
> [74330.417216] radeon :01:00.0: fence driver on ring 3 use gpu addr
> 0x2c0c and cpu addr 0x1142ed24
> [74330.417965] radeon :01:00.0: fence driver on ring 5 use gpu addr
> 0x00072118 and cpu addr 0x095357f2
> [74330.434413] [drm] ring test on 0 succeeded in 2 usecs
> [74330.434428] [drm] ring test on 3 succeeded in 7 usecs
> [74330.611793] [drm] ring test on 5 succeeded in 2 usecs
> [74330.611809] [drm] UVD initialized successfully.
> [74330.611949] [drm] ib test on ring 0 succeeded in 0 usecs
> [74330.612118] [drm] ib test on ring 3 succeeded in 0 usecs
> [74331.267267] [drm] ib test on ring 5 succeeded
> [74340.515810] radeon :01:00.0: swiotlb buffer is full (sz: 2097152
> bytes)
> [74340.515819] swiotlb: coherent allocation failed for device :01:00.0
> size=2097152
> [74340.515827] CPU: 0 PID: 27342 Comm: kworker/0:1 Tainted: GW
> 4.15.0-0.rc9.git4.1.fc28.x86_64 #1
> [74340.515832] Hardware name: Sony Corporation VPCSB2M9E/VAIO, BIOS
> R2087H4 06/15/2012
> [74340.515841] Workqueue: pm pm_runtime_work
> [74340.515849] Call Trace:
> [74340.515862]  dump_stack+0x85/0xbf
> [74340.515871]  swiotlb_alloc_coherent+0xe0/0x150
> [74340.515889]  ttm_dma_pool_get_pages+0x21b/0x620 [ttm]
> [74340.515908]  ttm_dma_populate+0x24d/0x340 [ttm]
> [74340.515923]  ttm_bo_move_memcpy+0x185/0x610 [ttm]
> [74340.515933]  ? lock_acquire+0x9f/0x200
> [74340.515940]  ? reservation_object_wait_timeout_rcu+0xb3/0x500
> [74340.515987]  radeon_bo_move+0x1a7/0x220 [radeon]
> [74340.516003]  ttm_bo_handle_move_mem+0x2a4/0x5d0 [ttm]
> [74340.516021]  ttm_bo_evict+0x186/0x370 [ttm]
> [74340.516046]  ttm_mem_evict_first+0x174/0x1d0 [ttm]
> [74340.516060]  ttm_bo_force_list_clean+0x6d/0x130 [ttm]
> [74340.516089]  radeon_suspend_kms+0x11e/0x3e0 [radeon]
> [74340.516103]  ? vga_switcheroo_runtime_resume+0x60/0x60
> [74340.516126]  radeon_pmops_runtime_suspend+0x54/0xc0 [radeon]
> [74340.516135]  pci_pm_runtime_suspend+0x61/0x170
> [74340.516144]  vga_switcheroo_runtime_suspend+0x24/0xa0
> [74340.516151]  __rpm_callback+0xbc/0x1f0
> [74340.516160]  ? vga_switcheroo_runtime_resume+0x60/0x60
> [74340.516168]  rpm_callback+0x1f/0x70
> [74340.516175]  ? vga_switcheroo_runtime_resume+0x60/0x60
> [74340.516181]  rpm_suspend+0x12d/0x6e0
> [74340.516195]  pm_runtime_work+0x73/0xb0
> [74340.516204]  process_one_work+0x249/0x6b0
> [74340.516219]  worker_thread+0x3a/0x390
> [74340.516229]  ? process_one_work+0x6b0/0x6b0
> [74340.516236]  kthread+0x121/0x140
> [74340.516243]  ? kthread_create_worker_on_cpu+0x70/0x70
> [74340.516253]  ret_from_fork+0x3a/0x50
>
> during which whole desktop is frozen for fraction of the second. During
> those freezes it is not possible even to move mouse cursor.
> Do you have idea what it may be?
>

Try booting with radeon.runpm=0

Dave.
___
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?

[David Airlie]

> 
> Hi folks! Wanted to run this up the flagpole somewhere before I just
> went and did it...
> 
> We have a couple of openQA tests which just run Firefox on top of a
> bare X server to do some browser tests. Up to now just 'dnf
> groupinstall base-x' then 'dnf groupinstall firefox', then 'startx
> /usr/bin/firefox', was enough; but now in Rawhide it seems like X fails
> to start if only the 'base-x' package group is installed, it fails
> looking for libEGL.so.1:
> 
> https://openqa.stg.fedoraproject.org/tests/137965#step/server_cockpit_default/19
> 
> This file seems to be in the libglvnd-egl package, which it seems
> doesn't get installed along with base-x.
> 
> 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.

Whatever used to make mesa-libEGL get installed should make this get installed.

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

Re: Intel i915 firmwares

[David Airlie]

No not the same upstream.

I'll look into the hdmi audio situation when I get back from holidays.


- Original Message -
> From: "Tomasz Torcz" <to...@pipebreaker.pl>
> To: devel@lists.fedoraproject.org
> Sent: Wednesday, 28 June, 2017 8:52:03 PM
> Subject: Re: Intel i915 firmwares
> 
> On Wed, Jun 28, 2017 at 05:20:13AM -0400, David Airlie wrote:
> > 
> > > I ran into this today:
> > > https://gist.github.com/Brainiarc7/aa43570f512906e882ad6cdd835efe57
> > > 
> > > DRM firmware is loaded by default. HuC and GuC are not. Things work
> > > without them, and things work with them loaded. So what's the pro/con
> > > and if there's a pro, why isn't it the kernel default? Seems like if
> > > it should be default, either upstream should set them as the default,
> > > or the CPU/GPU should ask for it?
> > 
> > I expect when upstream decided they are stable and useful enough, upstream
> > will enable them. I'm not fully sure how useful they are, I think they
> > might possibly enable lower power states, but also nasty bugs.
> 
>   The same upstream which did not release stable version of Xorg Intel driver
> for past three years? ;-)
>   According to the link, the firmwares are needed for HDMI audio, which is
> quite critical functionality.  HDMI audio for older chipsets did not
> require binary blobs, so this is kind of regression.
> 
> --
> Tomasz Torcz   "Never underestimate the bandwidth of a station
> xmpp: zdzich...@chrome.plwagon filled with backup tapes." -- Jim Gray
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intel i915 firmwares

[David Airlie]

> I ran into this today:
> https://gist.github.com/Brainiarc7/aa43570f512906e882ad6cdd835efe57
> 
> DRM firmware is loaded by default. HuC and GuC are not. Things work
> without them, and things work with them loaded. So what's the pro/con
> and if there's a pro, why isn't it the kernel default? Seems like if
> it should be default, either upstream should set them as the default,
> or the CPU/GPU should ask for it?

I expect when upstream decided they are stable and useful enough, upstream
will enable them. I'm not fully sure how useful they are, I think they
might possibly enable lower power states, but also nasty bugs.


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

Re: LLVM compatibility hazard on F24/F25

[David Airlie]

- Original Message -
> From: "Josh Stone" 
> To: devel@lists.fedoraproject.org
> Sent: Friday, 17 February, 2017 4:50:47 AM
> Subject: LLVM compatibility hazard on F24/F25
> 
> re https://bugzilla.redhat.com/show_bug.cgi?id=1422930
> 
> This is an indirect consequence of the LLVM update for bug 1376213.  In
> the initial llvm-3.8.1-1 update, ajax enabled the Mips target, but this
> was never pushed out due to unrelated build issues.  Then later I found
> I needed an LLVM update for s390x, so I fixed those issues too and
> pushed out llvm-3.8.1-2.
> 
> Rust detects the available targets when rustc is built, and this is its
> first update using llvm-3.8.1-2, so now it has picked up the Mips target
> and uses Mips-related symbols.  But this is a compatibility hazard, and
> there's no sort of symbol versioning on these per-target symbols.
> 
> I think I can fix the rust dependency with a manual entry:
> 
> Requires: llvm-libs%{?_isa} >= 3.8.1-2
> 
> But is that the best we can do at this point?  Any other options?

That seems like the best option.

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

Re: F25 workstation, and (almost) hidpi displays

[David Airlie]

> > 
> > DP-3-1 connected primary 1920x1200+0+0 (normal left inverted right x axis y
> > axis) 518mm x 324mm
> > 
> > Not sure what you think is hiding it, sounds like KDE is just broken.
> 
> Well, no, that's not fair - X allows you to query the display size, and
> it used to return whatever the display claimed was its physical size,
> then it changed to returning a lie explicitly intended to cause things
> that do a DPI calculation to calculate 96pdi. KDE uses that X
> interface, and so when X changed its behaviour, it resulted in KDE
> almost always rendering at 96dpi (which is basically the result the X
> change wanted, but wasn't necessarily what the KDE developers wanted).
> 
> It's true that they *can* still query the actual EDID-reported display
> size somehow, but it's not really fair to say that KDE is 'broken' when
> X explicitly went and changed the interface KDE was using with the
> intent of making KDE do something different to what it thought it was
> doing.

They can use xrandr to get the screen size connected to the output, I'm
not sure what else they want.

The old DPI reporting was always broken for multimonitor, so was deprecated
in favour of reporting the sizes and letting the DE do whatever it wants,
the old API was also fixed in time as 96, you can override it on the X.org
command line if you want, but really to support multi-head properly, use
the new API.

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

Re: F25 workstation, and (almost) hidpi displays

[David Airlie]

- Original Message -
> From: "Kevin Kofler" 
> To: devel@lists.fedoraproject.org
> Sent: Friday, 28 October, 2016 7:50:48 AM
> Subject: Re: F25 workstation, and (almost) hidpi displays
> 
> nicolas.mail...@laposte.net wrote:
> > But, GTK core maintainers have always insisted those didn't exist (just
> > like they insisted on hardcoding 96 dpi, on the eve of Apple showing the
> > world it was arbitrary and obsolete).
> 
> The worst is that this mentality has infected the core X11 as well, also
> breaking KDE's code that would carefully compute the correct DPI, if only
> X11 would not go out of its way to lie to it about the physical screen size!

You could use the randr protocol to read the physical screen size,

DP-3-1 connected primary 1920x1200+0+0 (normal left inverted right x axis y 
axis) 518mm x 324mm

Not sure what you think is hiding it, sounds like KDE is just broken.

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

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

[David Airlie]

I've rebuilt all the jasper packages with the offending patch removed because 
it breaks a lot
of stuff.

I'll see if the owner shows up, and files the errata, otherwise I'll get to it 
in next couple of days,
unless someone wants it done more urgently.

Dave.

- Original Message -
> From: "Matthew Miller" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Thursday, 15 September, 2016 8:46:27 AM
> Subject: Re: Please unpush FEDORA-2016-7776983633 on all releases or drop 
> support for libjasper
> 
> On Wed, Sep 14, 2016 at 03:11:35PM -0700, Adam Williamson wrote:
> > > If I recall correctly, we need libjasper for opencv for openqa, so I'm
> > > not sure we can drop this?
> > yeah, please don't just drop it. if anyone wants to work with me/openQA
> > upstream/both to port it to something else, great, but we do need to
> > cover that usage.
> 
> OpenCV can definitely be built _without_ JPEG 2000 support. I'm not
> sure how much of a loss that would be. I see that Debian is dropping
> JasPer — and looks like that's what they decided to do. (See
> https://release.debian.org/transitions/html/jasper-rm.html and
> https://anonscm.debian.org/git/debian-science/packages/opencv.git/tree/debian/changelog)
> 
> 
> > note, we do have this update installed on all the openQA boxes, and
> > they're all working perfectly fine.
> 
> Probably because openQA is unlikely to use JPEG 2000.
> 
> 
> --
> Matthew Miller
> 
> Fedora Project Leader
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
> 
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: [ANNOUNCE] Fedora support for Vulkan

[David Airlie]

- Original Message -
> From: "Kevin Kofler" <kevin.kof...@chello.at>
> To: devel@lists.fedoraproject.org
> Sent: Saturday, 20 February, 2016 12:14:00 PM
> Subject: Re: [ANNOUNCE] Fedora support for Vulkan
> 
> David Airlie wrote:
> > No, nothing concrete has been mentioned in this area at all.
> > 
> > sw rendering won't benefit from vulkan very much, in fact it would be
> > worse than GL in some cases, as Vulkan really works on the building up
> > long command buffers and executing them, rather than direct execution in a
> > context that GL does.
> 
> But eventually there will be Vulkan-only software and some fallback is
> needed for the hardware not supported by any hardware driver.
> 

Not necessarily. Until someone writes one, there are no plans to have one.

We have GL, I doubt we'll be writing compositors in Vulkan anytime soon,

fallbacks would probably be to use GL.

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

Re: [ANNOUNCE] Fedora support for Vulkan

[David Airlie]

> 
> Adam Jackson wrote:
> > 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.
> 
> What about software rendering? Is something like llvmpipe, or a port of the
> existing llvmpipe, in the works for Vulkan?

No, nothing concrete has been mentioned in this area at all.

sw rendering won't benefit from vulkan very much, in fact it would be worse
than GL in some cases, as Vulkan really works on the building up long 
command buffers and executing them, rather than direct execution in a context
that GL does.

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

Re: [ANNOUNCE] Fedora support for Vulkan

[David Airlie]

- Original Message -
> From: "Zach Villers" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Wednesday, 17 February, 2016 11:34:47 PM
> Subject: Re: [ANNOUNCE] Fedora support for Vulkan
> 
> Anyone know if/when nvidia drivers will be included?

There are no open source vulkan drivers for nvidia.

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

Re: [ANNOUNCE] Fedora support for Vulkan

[David Airlie]

- Original Message -
> From: "Marcin Juszkiewicz" 
> To: devel@lists.fedoraproject.org
> Sent: Wednesday, 17 February, 2016 8:59:51 AM
> Subject: Re: [ANNOUNCE] Fedora support for Vulkan
> 
> W dniu 16.02.2016 o 19:48, Adam Jackson pisze:
> 
> > 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.
> 
> > Your favorite hardware driver or 3D game engine quite likely could use
> > help in enabling a Vulkan port
> 
> Any info about Radeon support?

No, AMD haven't shared any firm plans on Linux Vulkan support, I think the 
latest
is,

a binary stack will be released at some point supporting amdgpu using GPUs,
this binary stack at some undisclosed point after that will be open sourced.

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

Re: Rawhide 2016-02-13 status report: utterly broken (mesa vs. llvm)

[David Airlie]

Thanks Adam,

in theory the mesa that is building now is the all good, definitely this
time. I'll see how it goes in practice.

Lessons learned, don't be the part of the poor suckers maintaining llvm.

Dave.

- Original Message -
> From: "Adam Williamson" 
> To: devel@lists.fedoraproject.org, t...@lists.fedoraproject.org
> Sent: Sunday, 14 February, 2016 1:58:59 AM
> Subject: Rawhide 2016-02-13 status report: utterly broken (mesa vs. llvm)
> 
> In case anyone's wondering why there are no openQA tests today: today's
> Rawhide is entirely broken by some change in llvm. mesa dependencies
> are broken, which breaks the compose of just about every single image,
> certainly all the images openQA tests (all lives and the boot.iso's
> failed).
> 
> There was an attempt to build mesa today which failed, so I'm figuring
> airlied is working on this, but obviously it would be good if this
> could be fixed ASAP.
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
> http://www.happyassassin.net
> 
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
> 
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Advertised OpenGL version clarification

[David Airlie]

- Original Message -
> From: "Sérgio Basto" 
> To: "Fedora devel" 
> Cc: "Adam Jackson" 
> Sent: Saturday, 30 January, 2016 9:48:55 AM
> Subject: Advertised OpenGL version clarification
> 
> Hi,
> Some people have been asking for opengl 3 +
> 
> https://ask.fedoraproject.org/en/question/8311/why-fedora-do-not-ship-o
> pengl-30-even-disable-it-for-intel-hw/
> 
> https://ask.fedoraproject.org/en/question/80679/supertuxkart-not-workin
> g-after-fedora-23/?answer=80681#post-id-80681
> 
> 
> Red Hat response (March 2013) : http://lists.fedoraproject.org/pipermai
> l/test/2013-March/114161.html
> 
> > What's the status of enabling the floating-point features in Mesa? It
> > prevents OpenGL 3+ from being advertised.
> 
> 
> We've asked our lawyers.  If and when they give the go-ahead, we'll
> enable it.  If they don't, we won't.
> 
> Ajax , this is already enabled or not ? do see anything that disable it, in
> Mesa package source:
> https://pkgs.fedoraproject.org/cgit/rpms/mesa.git
> 
> My Intel Ironlake , just advertise OpenGL version string: 2.1 ? can't
> advertise 3 + ?

we enable gl3/4 on all hw that can do it. swrast is still up in the air legally.

ironlake isn't gl3 capable hw.

Dave.
\> Thanks,
> --
> Sérgio M. B.
> 
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Dealing with the "my packages" problem

[David Airlie]

- Original Message -
> From: "Brian C. Lane" 
> To: devel@lists.fedoraproject.org
> Sent: Thursday, 19 November, 2015 7:05:57 AM
> Subject: Re: Dealing with the "my packages" problem
> 
> On Wed, Nov 18, 2015 at 02:24:37PM -0500, Rob Crittenden wrote:
> > Matthew Miller wrote:
> > > On Tue, Nov 17, 2015 at 06:08:24PM -0600, Jason L Tibbitts III wrote:
> > >> After some IRC discussion I've come to the following proposal: that
> > >> maintainers have some way to easily indicate how open they are to
> > >> external contributions.  Basically this would take the form of a few
> > >> options in pkgdb where maintainers can indicate their willingness to
> > >> have provenpackagers carry out a few actions.  Please read the github
> > >> ticket for details:
> > >>   https://github.com/fedora-infra/pkgdb2/issues/274
> > > 
> > > What if we made the options be about _the package_ rather than about
> > > the maintainer's prickliness? Rather than "Please don't touch my
> > > package" (I know that's not your wording; added for emphasis) make it
> > > "This package has unusual complications; please coordinate any changes
> > > with the package maintainers."
> > > 
> > > Well, except, less wordy. :)
> > > 
> > > And, in thinking about it, I don't think we should encourage the
> > > option of "Don't even ask". If there really _is_ something that's a big
> > > deal, the package maintainer can always say no when asked.
> > > 
> > 
> > As one of the complainers about current policy, here are my thoughts.
> > 
> > I appreciate tibbs bringing up the discussion. I'd vote for a default
> > stance of "Ask first."
> 
> I don't think we need a technical solution, we just need the people who
> feel the need to modify packages they aren't normally involved with to
> ask first. It doesn't matter how simple or complicated the change is,
> just be polite.

But that doesn't scale.

And scaling is important. We aren't developing a set of 4000s silos here,
we are meant to be developing a coherent operating system.

You don't stuff, get over it, maintain it as best you can, if someone else
screws it up, git revert and move on. If someone persistently screws things
up then we should deal with *that* problem. I don't think we have anyone
actively trying to screw up Fedora, so in theory we are all on the same team
and pulling in the same direction. So maybe if we started with an attitude
that they are have a good reason for touching the package, and worked with
that instead of defaulting to silos it would help a lot more.

Dave.
-- 
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: Dealing with the "my packages" problem

[David Airlie]

> 
> tl; dr: I have submitted the following RFE for pkgdb:
>   https://github.com/fedora-infra/pkgdb2/issues/274
> Please add comments there if you have any.
> 
> I know I'm not the only provenpackager to have applied a bugfix to
> someone's package only to be yelled at it for it.  Some maintainers are
> more prickly about having others touch the packages they maintain for
> the community than others, and unfortunately there's currently just no
> way to know whether you'll be thanked or flamed for helping out with a
> package.
> 
> After some IRC discussion I've come to the following proposal: that
> maintainers have some way to easily indicate how open they are to
> external contributions.  Basically this would take the form of a few
> options in pkgdb where maintainers can indicate their willingness to
> have provenpackagers carry out a few actions.  Please read the github
> ticket for details:
>   https://github.com/fedora-infra/pkgdb2/issues/274
> 
> This would be purely advisory, with hopefully reasonable defaults.  I
> believe it has the potential to eliminate quite a bit of friction that
> provenpackagers must handle, as well as eliminate the hesitation some of
> us feel for fear of being flamed.
> 

This seems like a crappy technical solution to a social problem.

Maybe by renaming package maintainers to something like caretakers we could
start changing the way people who maintain packages view their positions.

You don't own a package in Fedora. You are taking care of it on behalf
of the Fedora community, other people in the community can touch your package.

The other option is to just open all packages to everyone, I've no idea
why we still have ACLs in the land of git.

Dave.
-- 
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: wayland in rawhide

[David Airlie]

> hi,
> 
> > Here's one on Ironlake, with two monitors plugged in.
> >
> > https://bugzilla.gnome.org/show_bug.cgi?id=750610
> >
> > still not fixed, doesn't fall back.
> Well, black screens obviously aren't good, and we should clearly fix this.
> 
> If we don't get it fixed by closer to release, than maybe it's a good
> data point for switching
> back to Xorg for fedora 24.  But note:
> 
> 1) 3 monitor setups are somewhat more rare than one and two monitor
> setups, so it's important to fix, but the impact is more limited so
> the problem didn't get as much exposure as it would have otherwise.

This is a laptop with two monitors plugged in, this isn't rare. nearly
every desk in my office is this use case. Some of them are even crazy
enough to want to rotate one of the monitors. For this case I also
think they have the laptop lid closed, so the 3rd monitor isn't even
on, or at least with X we'd always drop back to two monitors working
and the third off.

> 2) the bug was reported by a developer who has reproducing hardware
> and intimate domain knowledge around the functions related to the
> failure (you).

This bug was just an example I knew about, I'm sure we've many others that just
get a bit ignored, due to not being something trivially reproducible on
an a single user laptop.

I started debugging this, and realised after spending time in mutter,
that it clearly wasn't something I was going to be able to fix without
expending a lot more time, and clearly the people who wrote the code were
in a better position to debug.

Dave.
-- 
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: wayland in rawhide

[David Airlie]

- Original Message -
> From: "Ray Strode" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Friday, 13 November, 2015 12:56:48 AM
> Subject: Re: wayland in rawhide
> 
> Hi,
> 
> > This seems still still be confusing a lot of people, I see quite
> > regularly queries on some forums like G+ that when they upgrade to
> > anything post F-21 all they get is a black screen on boot. Is there
> > any way that if way for that to happen automatically where they don't
> > get to a gdm login prompt?
> 
> Well it's supposed to automatically happen if users don't get a GDM
> prompt, but there was a case with hybrid hardware where we sending the
> prompt to the wrong card.
> 
> That was fixed in this bug I think:
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=753434

Here's one on Ironlake, with two monitors plugged in.

https://bugzilla.gnome.org/show_bug.cgi?id=750610

still not fixed, doesn't fall back.

Like filing bugs is all well and good, but going default while nobody is fixing 
the blackscreens isn't good.

Dave
-- 
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: wayland in rawhide

[David Airlie]

> That's fine.  I don't have a problem adding "GNOME on Xorg" option to
> the session
> menu in the interim. I'll do it tomorrow.

This is what the feature page said would happen in the first place. So
I'm also confused why you didn't just do that.

> 
> I will say you're coming off (to me anyway) as somewhat combative.  We're on
> the same team here.  Let's keep it constructive and friendly?

Okay, I'll try and be a little less pissed off at disabling features users
use, that we've spent years implementing in X/GNOME.

The fact you are requesting wayland by default while we still have the 
following list:

Close all remaining feature parity gaps between the Wayland and the X11 session:

input methods
on-screen keyboard
hi-dpi support
clipboard proxy for xwayland
attached modal dialogs
tablet support
startup notification
touch proxy for xwayland
accessibility features
output rotation 

These are just the missing features (never mind dialog boxes in wierd places 
bugs)
and it doesn't even contain the USB output hotplugging, or secondary GPU output 
use cases.

So maybe I'm getting old, but I thought we were over shoving half-baked onto 
users now,
Maybe implement all those features, get them into the non-default wayland 
session,
then go lobby for enabling the wayland session by default, otherwise I feel you 
are
putting the cart before the horse.

Dave.
-- 
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: wayland in rawhide

[David Airlie]

> Hi,
> 
> On Tue, Nov 10, 2015 at 4:32 PM, David Airlie <airl...@redhat.com> wrote:
> > I'd rather we waited until wayland sessions are feature equivalent with X.
> Note this is in rawhide, early in the Fedora 24 devel cycle.  If things don't
> work out, going back isn't hard.
> 
> > Sweeping this under the carpet and then not providing users any way to get
> > to something that
> > works on their hardware.
> We fall back to X in cases when we notice things aren't working, just
> as we do for the login screen.
> Remember we've been shipping the login screen on wayland for 2 releases now.
> And we provide a config option to turn wayland off explicitly for
> cases where users just want or need
> to use X.

The login screen is fine, if it just comes up on your laptop display you can
still login, however the active desktop session is a different story.

You are enabling something that is known broken and removes features from users.

Desktop rotation doesn't work for starters. This is a pretty basic feature that
I know lots of people use. You've just enabled a regression by default for all 
of
these people. This isn't what rawhide is for. If someone reports the regression
in a bug will you revert this feature.

Maybe trialing GNOME on wayland as the default is premature but removing the 
option
on login to use GNOME on X is definitely. As such I respectfully ask you put 
that
option back in rawhide.

If you still disagree, I'll probably have to spend time I could spend working on
stuff, taking this through some Fedora process I haven't had to deal with.

Dave.
-- 
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: wayland in rawhide

[David Airlie]

> Today I built snapshots of gnome-session gdm gnome-shell and mutter
> that change how we do sessions at the login screen. We'll no longer
> have separate items for GNOME and GNOME on Wayland.  Instead they're
> now both consolidated under the GNOME item.  That item will use
> wayland if it can, but if it falls back (because of a failure or
> nvidia proprietary drivers, or the user explicitly disables wayland in
> /etc/gdm/custom.conf) then that GNOME item will use Xorg instead.
> 
> I'm doing this for now in rawhide as preparation for this system-wide
> f24 change:
> 
> https://fedoraproject.org/wiki/Changes/WaylandByDefault
> 
> If things don't pan out for whatever reason, or the change gets
> otherwise rejected for f24, we'll split the items back out into two
> items.
> 
> But it's good to get this in rawhide now, so we can get as much
> exposure as possible to potential wayland problems and get them fixed
> up before release.
> 
> Just a heads up ! If you're a rawhide user please test!

I'd rather we waited until wayland sessions are feature equivalent with X.
Sweeping this under the carpet and then not providing users any way to get to 
something that
works on their hardware. The Fedora world isn't just an Intel laptop.
We know off enough bugs in mutter/wayland and feature differences without
forcing it on the world. Maybe we should spend more time fixing the deficiencies
we know about before going out and finding new ones.

For examples this change deliberately breaks optimus machines in
rawhide and stops USB monitor hotplugging from working, these are features
I spent a lot of time making sure they worked in Fedora and you have just
removed them without consulting me. As such I request you revert this.

Also I'd wait until mutter stops requiring Xwayland running for native apps.

Dave.
-- 
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: llvm 3.7 for rawhide and then f23

[David Airlie]

- Original Message -
> From: "Stephen Gallagher" <sgall...@redhat.com>
> To: devel@lists.fedoraproject.org
> Sent: Saturday, 19 September, 2015 1:17:45 AM
> Subject: Re: llvm 3.7 for rawhide and then f23
> 
> On Thu, 2015-09-17 at 00:16 -0400, David Airlie wrote:
> > Hi,
> > 
> > So I've been updating rawhide to llvm 3.7 upstream, so we can get
> > OpenGL 4.1 support on the radeonsi GPUs.
> > 
> > The two depends on llvm I don't control/know about were julia and
> > pocl, I've done my best to make them work,
> > pocl I've rebased to git, which seems to be upstream advice
> > julia I've updated to the latest in the 0.4 branch and had to move
> > some tests to the not working on i686 list.
> > 
> > Once the builds complete, I'll get rel-eng to tag the whole lot over
> > into rawhide. Then I'll repeat for Fedora 23 some time next week and
> > file an update.
> > 
> 
> 
> Given that we are now post-Beta for F23, it seems a little late in the
> cycle to be introducing a new llvm runtime. Is it guaranteed to be
> backwards-compatible?

It's llvm, there is never a good time to upgrade it and no llvm release is 
backwards compatible.

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

llvm 3.7 for rawhide and then f23

[David Airlie]

Hi,

So I've been updating rawhide to llvm 3.7 upstream, so we can get OpenGL 4.1 
support on the radeonsi GPUs.

The two depends on llvm I don't control/know about were julia and pocl, I've 
done my best to make them work,
pocl I've rebased to git, which seems to be upstream advice
julia I've updated to the latest in the 0.4 branch and had to move some tests 
to the not working on i686 list.

Once the builds complete, I'll get rel-eng to tag the whole lot over into 
rawhide. Then I'll repeat for Fedora 23 some time next week and file an update.

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

captive portal implementation found lacking

[David Airlie]

Hey devs,

So Simo wanted to explode so I've tried to distill down the issues we saw:

a: you can't uninstalled the config connectivity package from workstation 
without losing gnome-shell and gdm.
https://bugzilla.redhat.com/show_bug.cgi?id=1205963

this seems sub optimal.

b: the feature is over zealous in its letting you know it can't find fp.org

you are sitting there typing, you get a full screen window with some GNOME 
stuff on it, with no warning
whatsoever. Has your local network crashed? no, fedoraproject.org webserver got 
outaged or the route
failed over, but you don't get that info, you get a full screen GNOME page.

maybe just indicate in the top corner or pop up a status bar for someone to 
click on to get the 
full screen page, my desktop is not a tablet

maybe we should be trying to connect to more than one site, and maybe some 
sites on different networks.

Otherwise I think this feature is a bit half baked as is.

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

hardening breaks X.org

[David Airlie]

So the rebuild to use hardened builds by default in rawhide, broke X.org.

Thanks guys, my system is more secure, but I can't run any apps.

Anyways enough snark from me, the problem seems to be that hardening
makes bind now override RTLD_LAZY options, and the X server relies
on the RTLD_LAZY on its drivers being lazy.

So should I

a) turn off hardened builds for all Xorg server/driver packages?

b) or is there a way to get partial relro back?

Dave.
-- 
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: hardening breaks X.org

[David Airlie]

- Original Message -
 From: Moez Roy moez@gmail.com
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
 Cc: David Airlie airl...@redhat.com, Adam Jackson a...@redhat.com, 
 Till Maas opensou...@till.name
 Sent: Monday, 2 March, 2015 1:15:19 PM
 Subject: Re: hardening breaks X.org
 
 On Sun, Mar 1, 2015 at 5:16 PM, David Airlie airl...@redhat.com wrote:
  So the rebuild to use hardened builds by default in rawhide, broke X.org.
 
  Thanks guys, my system is more secure, but I can't run any apps.
 
  Anyways enough snark from me, the problem seems to be that hardening
  makes bind now override RTLD_LAZY options, and the X server relies
  on the RTLD_LAZY on its drivers being lazy.
 
  So should I
 
  a) turn off hardened builds for all Xorg server/driver packages?
 
  b) or is there a way to get partial relro back?
 
  Dave.
  --
  devel mailing list
  devel@lists.fedoraproject.org
  https://admin.fedoraproject.org/mailman/listinfo/devel
  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
 
 In RHEL 7.1 beta I see in the changelog:
 
 2014-09-17 Adam Jackson a...@redhat.com 1.15.0-27
 - Link Xorg as a PIE
 
 and
 
 2014-02-25 Adam Jackson a...@redhat.com 1.15.0-6
 - Fix dist tag
 - Link Xorg with -z now
 
 

This works fine for the X server itself, since its not a shared library.

However the drivers can't use -z now, that new flags forced this on everywhere.

Dave.
-- 
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: gcc5 ICE xserver build on ARM

[David Airlie]

- Original Message -
 From: Marek Polacek pola...@redhat.com
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
 Sent: Tuesday, 17 February, 2015 4:31:36 PM
 Subject: Re: gcc5 ICE xserver build on ARM
 
 On Tue, Feb 17, 2015 at 07:14:43AM +0100, Marek Polacek wrote:
  On Tue, Feb 17, 2015 at 12:26:57AM -0500, David Airlie wrote:
   Just kicked off an Xserver build in rawhide,
   
   and it appears gcc ICE.
   http://koji.fedoraproject.org/koji/getfile?taskID=8960146name=build.log
   
   libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../include
   -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wmissing-declarations
   -Wformat=2 -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs
   -Wbad-function-cast -Wold-style-definition -Wdeclaration-after-statement
   -Wunused -Wuninitialized -Wshadow -Wmissing-noreturn
   -Wmissing-format-attribute -Wredundant-decls -Wlogical-op
   -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
   -fno-strict-aliasing -fno-strict-aliasing -D_DEFAULT_SOURCE
   -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/include/libdrm
   -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16
   -I/usr/include/X11/dri -I../include -I../include -I../Xext
   -I../composite -I../damageext -I../xfixes -I../Xi -I../mi
   -I../miext/sync -I../miext/shadow -I../miext/damage -I../render
   -I../randr -I../fb -I../dbe -I../present -fvisibility=hidden -O2 -g
   -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
   -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
   -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard -c xdmcp.c  -fPIC -DPIC
   -o .libs/xdmcp.o
   xdmcp.c: In function 'XdmcpFatal':
   xdmcp.c:1413:16: internal compiler error: Segmentation fault
   status-length, status-length, status-data);
   ^
   Please submit a full bug report,
   with preprocessed source if appropriate.
   See http://bugzilla.redhat.com/bugzilla for instructions.
   
   Not sure how best to proceed.
  
  Please submit a full bug report,
  with preprocessed source if appropriate.
  See http://bugzilla.redhat.com/bugzilla for instructions.
 
 Thought, we have 3 bug reports about internal compiler error:
 Segmentation fault on ARM (#1193212, #1193244, #1193142), so
 perhaps opening another bug is not necessary.

Well I can't provide any info, I don't have an ARM box here,
and it happens in the buildroot which I don't think I can access
to get the files out from.

Which is why I hope gcc devs have such things once I point out
the failure case!

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

gcc5 ICE xserver build on ARM

[David Airlie]

Just kicked off an Xserver build in rawhide,

and it appears gcc ICE.
http://koji.fedoraproject.org/koji/getfile?taskID=8960146name=build.log

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../include -DHAVE_DIX_CONFIG_H 
-Wall -Wpointer-arith -Wmissing-declarations -Wformat=2 -Wstrict-prototypes 
-Wmissing-prototypes -Wnested-externs -Wbad-function-cast 
-Wold-style-definition -Wdeclaration-after-statement -Wunused -Wuninitialized 
-Wshadow -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls 
-Wlogical-op -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 -fno-strict-aliasing 
-fno-strict-aliasing -D_DEFAULT_SOURCE -D_BSD_SOURCE -DHAS_FCHOWN 
-DHAS_STICKY_DIR_BIT -I/usr/include/libdrm -I/usr/include/pixman-1 
-I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/X11/dri 
-I../include -I../include -I../Xext -I../composite -I../damageext -I../xfixes 
-I../Xi -I../mi -I../miext/sync -I../miext/shadow -I../miext/damage -I../render 
-I../randr -I../fb -I../dbe -I../present -fvisibility=hidden -O2 -g -pipe -Wall 
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches 
-march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard -c xdmcp.c  -fPIC -DPIC -o 
.libs/xdmcp.o
xdmcp.c: In function 'XdmcpFatal':
xdmcp.c:1413:16: internal compiler error: Segmentation fault
status-length, status-length, status-data);
^
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugzilla.redhat.com/bugzilla for instructions.

Not sure how best to proceed.

Dave.
-- 
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: Workstation Product defaults to wide-open firewall

[David Airlie]

 
 
  sudo firewall-cmd --set-default-zone=FedoraServer
  That will limit it to SSH, DHCPv6 and cockpit
 
  Or use default zone Public, which swaps cockpit out and adds mDNS
 
  Or if you're Reindl Harald-level paranoid (no offense intended, Harald
  but you're the most paranoid sysadmin I know, even more than me):
 
  sudo firewall-cmd --set-default-zone=block
 
 It always amaze me why people that says it is easy to change de default,
 were not happy with:
 
 sudo firewall-cmd --set-default-zone=OpenZone
 
 instead of forcing the less secure one to eveyone.

I also thought that the whole points of having Zones etc, was so that
we could pick a different zone per network connection,

so if I'm in the office or at home I can say use this zone, if I'm
at a coffee shop I can pick a different one etc.

Or was this consider too much UI for the normal user? Surely
OSX has something to copy from, since they seem to define what
a normal user expects.

Dave.
-- 
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: LLVM 3.5 rebase

[David Airlie]

 
 i can take a look at llvmpy this week, but i'd recommend just retiring
 it otherwise. it can come back if it has to.

I was going to retire it before, but upstream had a patch,

Its jsut a wrapper aruond the API, it probably needs to be developed
in sync with llvm, and so far I haven't seen any upstream dedication to
doing so.

The thing is then llvmpy will hve an unstable API, which means the llvmpy
users will need changing for every llvm release.

Dave.
-- 
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: Multiple problems with multiple monitors

[David Airlie]

 
 
 I've searched for bugs related to the specific problems I've been having, and
 I've not been able to find anything that describes what I'm seeing.
 
 I have an HP EliteBook 840 that also comes with an UltraDock, to which I've
 plugged-in two external monitors and I use in conjunction with the built-in
 laptop display.

What Fedora distro are you using?

Does this laptop have multiple GPUs? what GPU is it etc.

You probably should file a bug against the primary GPU with the dmesg.

 Issue #2: When I undock my laptop while logged-in, Gnome Shell just crashes.
 When I redock after the laptop has been started when unconnected, one of the
 two external monitors start-up (the one connected by VGA), but not the one
 connected by a DisplayPort connection. And, recently (but not when I first
 started using this laptop with the dock, which was about a month ago), now
 when I start-up with the laptop docked and both external monitors connected,
 both external monitors will be active, but the built-in display will show
 nothing. Gnome Shell reports the built-in display is active, but will not
 display anything unless I deactivate it and reactivate it via the settings
 Displays utility.

This sounds like MST releated but I can't say without more info.

Dave.
-- 
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: F21/F22: xorg-x11-drv: which for SiS?

[David Airlie]

- Original Message -
 From: Felix Miata mrma...@earthlink.net
 To: devel@lists.fedoraproject.org
 Sent: Tuesday, 23 September, 2014 4:50:46 PM
 Subject: F21/F22: xorg-x11-drv: which for SiS?
 
 xorg-x11-drv-sis seems to have disappeared. Did that happen on purpose? It
 still exists as a selelection in Bugzilla. Xorg is looking for sis module but
 cannot find it. Gfxchip here is Z7/Z9 (XG20 core). Is it now supposed to be
 using some other (not installed) driver? Before today's upgrade, X still
 worked.

https://lists.fedoraproject.org/pipermail/devel/2013-October/190696.html

That?

Dave.
-- 
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: rfc: xserver rebase in F20 (was Re: Slipping F21)

[David Airlie]

 To add some context the feature that I am asking for is working DRI3 +
 present ... with mesa 10.2
 it gives us GLX_EXT_buffer_age which finally fixes tearing issues in
 mutter that some user are experiencing
 without using workarounds like forcing the compositor to always redraw
 the whole screen (which costs performance
 and battery life).

There is no working DRI3 + present anywhere at all yet, or if there is
it involves SNA which has its own set of not working.

Dave.
-- 
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: rfc: xserver rebase in F20 (was Re: Slipping F21)

[David Airlie]

 
  To add some context the feature that I am asking for is working DRI3 +
  present ... with mesa 10.2
  it gives us GLX_EXT_buffer_age which finally fixes tearing issues in
  mutter that some user are experiencing
  without using workarounds like forcing the compositor to always redraw
  the whole screen (which costs performance
  and battery life).
 
 There is no working DRI3 + present anywhere at all yet, or if there is
 it involves SNA which has its own set of not working.

And also DRI3 breaks a bunch of working features like gpu offload, again
DRI3 + present is a keithp feature, it works on his laptop so he shipped it.

It needs someone who cares to take over and finish development.

Dave.
-- 
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: llvm 3.4 in rawhide time

[David Airlie]

 
 
 On 14 Jan 2014 06:04, David Airlie  airl...@redhat.com  wrote:
  
  Hi all,
  
  I've gotten a build tag f21-llvm for attempting to rebase rawhide to llvm
  3.4
 
 Assuming there aren't any major stumbling blocks, are there any plans to back
 port llvm 3.4 to f20 (like was done for llvm 3.3 in f19)?
 
 I need clang 3.4 for my day job but have been holding off on a parallel
 installable version until I know what's happening in Fedora proper.

Maybe, we might like it for GPU drivers, but I want to see how hairy it is,
so far it looks rather hairy, most of the projects failed on my simple just 
rebuild it.

Dave.
-- 
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: llvm 3.4 in rawhide time

[David Airlie]

  
  On 14 Jan 2014 06:04, David Airlie  airl...@redhat.com  wrote:
   
   Hi all,
   
   I've gotten a build tag f21-llvm for attempting to rebase rawhide to llvm
   3.4
  
  Assuming there aren't any major stumbling blocks, are there any plans to
  back
  port llvm 3.4 to f20 (like was done for llvm 3.3 in f19)?
  
  I need clang 3.4 for my day job but have been holding off on a parallel
  installable version until I know what's happening in Fedora proper.
 
 Maybe, we might like it for GPU drivers, but I want to see how hairy it is,
 so far it looks rather hairy, most of the projects failed on my simple just
 rebuild it.
 
 iirc last time the rebase was required in order to get a later Mesa into the
 distro. I will hold off for a few days to see just how hairy things are. If
 you decide not to rebase f20 i will build something privately, or even a
 copr build if anybody else is interested in it.
 
 If you need any help with testing, patches, etc i would be happy to help
 where i can.

It looks like OpenGTL is going to be the sticking point,

upstream appears dead, and llvm removed its old school llvm::sys::Path interface
that OpenGTL appears to use in a few places. My C++ is fairly fail, and I 
managed
to at least fix two files, but then realised how big a hole I was digging.

If anyone has some C++ expertise (package maintainer cc'ed), and some time it 
might not
be too bad too work out,

Dave.



diff -up OpenGTL-0.9.18/OpenGTL/GTLCore/Debug.cpp.myfix OpenGTL-0.9.18/OpenGTL/GTLCore/Debug.cpp
--- OpenGTL-0.9.18/OpenGTL/GTLCore/Debug.cpp.myfix	2014-01-15 11:45:27.0 +1000
+++ OpenGTL-0.9.18/OpenGTL/GTLCore/Debug.cpp	2014-01-15 11:45:27.0 +1000
@@ -111,14 +111,18 @@ Debug::Private::~Private()
   delete m_voidStream;
 }
 
+static llvm::StringRef getUserHomeDirectory() {
+  const char* home = getenv(HOME);
+  return home ? llvm::StringRef(home) : llvm::StringRef(/);
+}
 void Debug::Private::readConfigFile( const String _fileName, std::map GTLCore::String, LibraryDebugInfo  _destination)
 {
-  llvm::sys::Path path = llvm::sys::Path::GetUserHomeDirectory();
-  path.appendComponent( (const std::string)_fileName);
-  if( path.exists() )
+  llvm::SmallString128 mypath(getUserHomeDirectory());
+  llvm::sys::path::append(mypath, llvm::StringRef(_fileName));
+  if( llvm::sys::fs::exists(llvm::Twine(mypath)) )
   {
 std::ifstream in;
-in.open(path.c_str() );
+in.open(mypath.c_str() );
 if(in)
 {
   std::string cstr;
@@ -195,7 +199,7 @@ String Debug::Private::extractFunctionNa
 
 std::ostream Debug::Private::report( std::ostream _stream, const std::map GTLCore::String, LibraryDebugInfo  _informationRecords, const String _streamName, const String _libraryName, const String _fileName, int _line, const String _functionName )
 {
-  GTLCore::String fileName = llvm::sys::Path((const std::string)_fileName).getLast().str();
+  GTLCore::String fileName = llvm::sys::path::filename(llvm::StringRef(_fileName)).str();
   GTLCore::String functionName = Private::extractFunctionName( _functionName );
   if( isEnabled( _informationRecords, _libraryName, fileName, functionName ) )
   {
diff -up OpenGTL-0.9.18/OpenGTL/GTLImageIO/ImageDC.cpp.myfix OpenGTL-0.9.18/OpenGTL/GTLImageIO/ImageDC.cpp
--- OpenGTL-0.9.18/OpenGTL/GTLImageIO/ImageDC.cpp.myfix	2012-12-29 21:27:12.0 +1000
+++ OpenGTL-0.9.18/OpenGTL/GTLImageIO/ImageDC.cpp	2014-01-15 11:48:35.0 +1000
@@ -65,7 +65,7 @@ bool ImageDC::canEncodeImage( const GTLC
 
 GTLCore::String ImageDC::extension( const GTLCore::String _fileName ) const
 {
-  GTLCore::String ext = llvm::sys::Path( (const std::string)_fileName ).getSuffix().str();
+  GTLCore::String ext = llvm::sys::path::extension( llvm::StringRef((std::string)_fileName) ).str();
   return ext.toLower();
 }
 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

llvm 3.4 in rawhide time

[David Airlie]

Hi all,

I've gotten a build tag f21-llvm for attempting to rebase rawhide to llvm 3.4, 
so far I've started just getting llvm built into the buildroot,
and once it gets past arm it seems like it should succeed.

That leaves the fun of rebasing and fixing all the llvm dependant packages:

mesa
OpenGTL
dragonegg
gambas3-gb
lightspark
pocl
pure
python-llvmpy

I'll take care of mesa, but once the arm builds and buildroot are dong I'd 
appreciate any help with the other packages,

I'll probably try and rebuild them all locally first, so far at least OpenGTL 
and python-llvmpy have failed miserably!

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

glew 1.10 in rawhide

[David Airlie]

Hi,

I bumped glew in 1.10 in rawhide, I haven't rebuilt all the dependencies but I 
can if anyone wants, but I thought I'd give
 a headsup to the maintainers so they can rebuild their packages.

Dave.
-- 
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: glew 1.10 in rawhide

[David Airlie]

Actually I feel guilty now, I'll do a mass rebuild in rawhide.

amanith-0.3-26.fc20.src.rpm
avogadro-1.0.3-20.fc21.src.rpm
blender-2.69-1.fc21.src.rpm
bzflag-2.4.2-7.fc20.src.rpm
calligra-2.7.4-2.fc21.src.rpm
cegui06-0.6.2-15.fc20.src.rpm
cegui-0.7.9-5.fc20.src.rpm
compat-SFML16-1.6-3.fc21.src.rpm
enblend-4.1.2-1.fc21.src.rpm
FlightGear-Atlas-0.4.9-0.14.cvs20130922.fc21.src.rpm
freewrl-1.22.13.1-9.fc20.src.rpm
gambas3-3.5.1-1.fc21.src.rpm
gimp-normalmap-1.2.3-6.fc21.src.rpm
glew-1.9.0-4.fc20.src.rpm
gource-0.40-1.fc21.src.rpm
hugin-2013.0.0-1.fc21.src.rpm
kalzium-4.11.90-1.fc21.src.rpm
libprojectM-2.0.1-20.fc20.src.rpm
linphone-3.6.1-2.fc20.src.rpm
maniadrive-1.2-55.fc20.src.rpm
megaglest-3.7.1-9.fc20.src.rpm
mesa-demos-8.1.0-4.fc20.src.rpm
meshlab-1.3.2-2.fc20.src.rpm
opencsg-1.3.2-9.fc20.src.rpm
OpenImageIO-1.2.3-1.fc21.src.rpm
openmsx-0.9.1-1.fc20.src.rpm
openscad-2013.06-5.fc21.src.rpm
pymol-1.6.0-2.20130620svn4032.fc20.src.rpm
quesoglc-0.7.2-8.fc20.src.rpm
root-5.34.10-1.fc21.src.rpm
rss-glx-0.9.1.p-17.fc20.src.rpm
scorched3d-43.3d-9.fc21.src.rpm
sdljava-0.9.1-23.fc20.src.rpm
SFML-2.0-3.fc20.src.rpm
spring-94.1-6.fc20.src.rpm
supertux-0.3.3-13.fc20.src.rpm
toped-0.9.81-5.svn2211.fc20.src.rpm
vdrift-20120722-6.fc20.src.rpm
warzone2100-3.1.0-3.fc20.src.rpm
widelands-0-0.38.build17.fc20.src.rpm
wxmacmolplt-7.4.4-2.fc20.src.rpm

Dave.


- Original Message -
 From: Miro Hrončok mhron...@redhat.com
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
 Sent: Monday, 18 November, 2013 7:54:03 AM
 Subject: Re: glew 1.10 in rawhide
 
 If you don't want to do mass rebuild, maybe you should send this email
 directly to the owners of glew dependent packages, so they don't miss
 it. Especially when the traffic on devel is so high.
 
 Ne 17. listopad 2013, 21:48:31 CET, David Airlie napsal:
  Hi,
 
  I bumped glew in 1.10 in rawhide, I haven't rebuilt all the dependencies
  but I can if anyone wants, but I thought I'd give
a headsup to the maintainers so they can rebuild their packages.
 
  Dave.
 
 --
 Miro Hrončok
 --
 Phone: +420777974800
 IRC: mhroncok
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
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: glew 1.10 in rawhide

[David Airlie]

- Original Message -
 From: Miro Hrončok mhron...@redhat.com
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
 Sent: Monday, 18 November, 2013 10:54:38 AM
 Subject: Re: glew 1.10 in rawhide
 
 If you haven't done it yet, skip openscad and opencsg, I've rebuilt
 those once I read your email.
 

Oops, I just pushed the changes to master, I'll skip rebuilding them though,

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

root rebuild failed after glew update

[David Airlie]

Hi owners,

I tried to rebuild root after glew update, but it failed due to hadoop changes,

Not sure if hadoop needs a build in rawhide for the current f20 build or 
something else.

Dave.
-- 
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: root rebuild failed after glew update

[David Airlie]

- Original Message -
 From: punto...@libero.it
 To: devel@lists.fedoraproject.org
 Sent: Monday, 18 November, 2013 1:54:06 PM
 Subject: Re: root rebuild failed after glew update
 
 Il 18/11/2013 04:40, Christopher Meng ha scritto:
  On Mon, Nov 18, 2013 at 11:26 AM, punto...@libero.it punto...@libero.it
  wrote:
  hi
  Hadoop has nothing to do with glew ...
  can you please add the part, of the build.log, where fails to compile?
  regards
  gil
  http://koji.fedoraproject.org/koji/buildinfo?buildID=479029:
 
  Checking for libhdfs ... no
  Checking for libjvm ... /usr/lib/jvm/java/jre/lib/amd64/server
  Explicitly required HDFS dependencies not fulfilled
 
  And libhdfs is from hadoop.
 seem, you missing a buildrequires hdf5 or hdf (devel)
 http://pkgs.fedoraproject.org/cgit/hdf
 http://pkgs.fedoraproject.org/cgit/hdf5
 

Did something get subpackaged, or requires rewritten since root built the last 
time it was tried.

Though not my package, I'll let the package owner fix the depends if things 
have changed.

Dave.
-- 
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: Target Display Mode in Fedora

[David Airlie]

 The iMac and HP Z1 have a bi-directional DisplayPort/Thunderbolt port, which
 lets them be used as a Display for another computer. Apple calls it Target
 Display Mode, though HP doesn't seem to have a special name for it. This is
 really quite useful, I've used an iMac hooked up to a Linux machine at a
 previous job, and it's awesome to switch between the two machines when
 you've only got space for one display on the desk. The feature is invoked by
 a fairly non-standard keyboard combination. Here is a video illustrating
 what I mean (
 http://www.youtube.com/watch?feature=player_detailpagev=Y7_OZgBX8kQ#t=60 ),
 note how he switches the iMac from being the display for the MacBook to
 being an iMac again via keyboard shortcut (sort of off-screen).
 
 However, this feature is only implemented in OS X and Windows (via HP's My
 Display application) on the iMac and Z1 respectively. Which means that if,
 for example, a Z1 has Linux as the primary OS, the Z1 cannot currently be
 used as a monitor for a laptop or another computer (via Target Display
 Mode). As far as I've been able to discover, Target Display Mode does not
 exist under any flavor of Linux.
 
 What would it take to support this in Fedora? Is this a Desktop-centric
 feature for Gnome/KDE/Cinnamon, or is this something that would/should be
 part of the Linux kernel itself? I don't think it's directly part of a
 graphics driver (at least on Windows, since HP released My Display as a
 separate program), but again I'm not sure.

You'd have to reverse engineer or ask HP/Apple what they actually do for this
to work.

then implement that.

Dave.
-- 
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: Mesa needs an update?

[David Airlie]

- Original Message -
 From: Jef Spaleta jspal...@gmail.com
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
 Sent: Friday, 2 August, 2013 10:14:31 AM
 Subject: Re: Mesa needs an update?
 
 On Thu, Aug 1, 2013 at 3:50 PM, Morgan Howe mth...@gmail.com wrote:
  I didn't say you need to bump it to bleeding edge git. I'm just letting you
  know that there's a pretty serious bug in the current version of mesa that
  is affecting at least a few people - probably even more who just rolled
  back
  to F18 and didn't bother filing a bug report. I'm well aware that a version
  bump might introduce new bugs, but just thought someone might want to
  consider at least looking into it since a completely broken X is a fairly
  major issue.
 
 okay im a little confused. You filed it and then closed it as upstream.
 
 How does that help the package maintainer in Fedora keep track of this
 as an outstanding issue to possibly address as an update?
 
 You've short circuited the bug workflow a bit by jumping the gun and
 marking your own issue as resolved.  I believe the intent with regard
 to the UPSTREAM resolution in our bugzilla workflow is for
 maintainers to use to mark as resolved with the intention of pulling
 new upstream release and pushing it as an update some time soonish.
 If as the reporter you mark it as resolved, you've greatly reduced the
 chance that a maintainer is going to notice the bug as still
 outstanding. So you might want to rethink how you handled this report.

Also unless he rebuild the upstream mesa in rpm with the same flags, I'm not 
sure
this is guaranteed fixed upstream.

Dave.
-- 
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: system freezes after loading gdm/gnome

[David Airlie]

 As usual, I have completely forgotten any relevant system/software
 info, so:
 
 This is a Thinkpad T420 with:
 
   00:02.0 VGA compatible controller: Intel Corporation 2nd Generation
   Core
  Processor Family Integrated Graphics Controller (rev 09)

I've just sent a mesa-9.1-2 build for koji for F19 that should workaround this,
we don't have a proper fix yet, but the chromeos developers had a hack in their
tree they pointed me at, and it does appear to let me boot again with RC6 
enabled.

Dave.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Seeking primary maintainer for LLVM

[David Airlie]

- Original Message -
 From: Michel Alexandre Salim sali...@fedoraproject.org
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
 Sent: Monday, 25 February, 2013 7:30:56 PM
 Subject: Re: Seeking primary maintainer for LLVM
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 25/02/13 13:06, Siddhesh Poyarekar wrote:
  On Mon, Feb 25, 2013 at 11:49:49AM +0700, Michel Alexandre Salim
  wrote:
  - - Refactorig LLVM's build system to properly use versioned
  shared objects. I note that other distributions, and BSD, are
  still using static linking, so we appear to be the only ones
  attempting to package LLVM properly. - - Dealing with Clang
  breaking when GCC is updated, and compatibility issues with
  secondary architectures
  
  Thanks to Jens for doing the 3.2 update -- and others who've
  been contributing packaging patches.
  
  Let me know if you're interested, and I'll release the package
  then.
  
  I've never looked at llvm internals before, but it would be a fun
  challenge for me.  I can take it up if you're OK with things being
  broken occasionally while I figure things out.  Of course, if
  someone else who has a clue wants to take it up, I'd like it if I
  could co-maintain.
  
 Given that Mesa depends on LLVM, I suppose brokenness in anything but
 Rawhide is not really advisable.
 
 I'd be happy to give you and Jens co-maintainership though, until a
 more permanent maintainer steps forward (ideally one of those who
 have
 committed semi-regularly before).

I expect myself, ajax or glisse need to step up to this, I'm probably
worst choice at the moment, but I can at least find the time with juhp
to the llvm/mesa lockstep updates.

Dave.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[David Airlie]

- Original Message -
 From: Richard Hughes hughsi...@gmail.com
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
 Sent: Wednesday, 31 October, 2012 6:35:14 AM
 Subject: Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how  
 to install into a LVM partitions (or
 RAID))
 
 On 30 October 2012 18:45, Adam Williamson awill...@redhat.com
 wrote:
  so if were to try and switch back to oldui at
  this point, we'd have to go through the whole process of adjusting
  the
  code for the changes to dracut again, quite apart from any other
  issues.
 
 I don't understand how fixing up the old anaconda with the dracut
 changes would be so difficult. More than 140 man-hours? It's surely
 going to be a lot less work than getting anaconda to a point where it
 actually works with a consistent UI. Anaconda isn't the kind of thing
 we can fix with a zero day update, and surely it should have been
 developed in parallel with a release and then switched on just
 after
 branching rather than the situation we have now where there is major
 design and development work being done *so close* to where we should
 have everything locked down tight.
 
 I really don't see why the Anaconda team should be treated so
 differently from every other team. If we ship anything close to the
 Anaconda we've got now then F18 is going to get ripped apart by the
 reviewers.

Should we just skip F18? (like seriously).

Dave.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why is not enabled TapButton of touchpad on Fedora by default?

[David Airlie]

 Ok, but I do not understand why a simple thing is not set by default?
 bit empathic? a lot users want is enabled by default, others doesn't
 like it, ok, but a who doesn't like it, not affect on your
 navigation, can ignore this.

There is no good default, you set it one way, you get a crapton of hate mail, 
you set it the other you get a crapton of hate mail.

Therefore you provide a discoverable settings box, if your desktop is too crap 
to do that then complain to them.

Dave.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Any ETA for OpenCL support in Mesa?

[David Airlie]

 
 Hello All!
 Since March 2012 can be built with --enable-opencl (see this -
 http://www.phoronix.com/scan.php?page=news_itempx=MTEwMTE ) so maybe
 it's time to enable it in Fedora? Actually I really don't know what's
 the status of OpenCL support in Nouveay/Radeon drivers - according to
 various Phoronix articles some work was already done and some patches
 still have to be merged. Could someone summarize the current status
 of
 OpenCL support in the drivers as well as in the high-level libraries?

I made a first pass at packaging it and starting feeling ill at the pain,

the big problem was pacakging libclc, its horribly developed, got what I think
is a handwritten build system in python (or a port of one), requires a fair
few patches to even get close to being useful.

I'm sort of waiting for AMD to say when they think things are more ready,
from a radeon pov, and from what I know nouveau support still isn't merged
into mesa.

So at the moment I get the feeling that you could probably run clinfo and not
much more.

Dave.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers

[David Airlie]

- Original Message -
 From: Jon Masters j...@redhat.com
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
 Cc: Michel Alexandre Salim sali...@fedoraproject.org
 Sent: Wednesday, 9 May, 2012 10:57:30 PM
 Subject: Re: Like C++? Not afraid of quirky build systems? Seeking LLVM   
 co-maintainers
 
 On 05/06/2012 02:29 AM, Michel Alexandre Salim wrote:
 
  LLVM is becoming an increasingly integral part of our distribution
  (with mesa now using it to build the LLVMpipe renderer, for
  example)
  that I don't really feel comfortable maintaining it mostly by
  myself.
 
 Thanks for the private email about ARM stuff. I've just kicked off
 another scratch build for ARM LLVM that might fix our outstanding
 problems. I'm ok - vaguely - in being a co-maintainer on ARM if there
 is
 nobody else on our end who can represent ARM (as it seems). I started
 going through some of its design over the weekend, in my copious
 non-existent spare time to try to understand the ARM bits.
 
 More broadly though, I feel that GCC is well represented in terms of
 engineering knowledge but I'm *concerned* that we run the risk of
 growing a dependence on LLVM that is more critical than the LLVMpipe
 stuff. Before we can blink, we might need LLVM for building lots of
 other fundamental stuff. I am wondering if as a distribution we ought
 to
 have an official FESCo-debated position on LLVM use? I do not think
 Fedora has the resources to maintain two critical toolchain pieces. I
 do
 think LLVM is useful, etc. BUT its growing use is concerning.

Don't confuse llvm and clang, llvm has no equivalent in gcc world,
clang is a C compiler like gcc that uses llvm tech.

Apart from llvmpipe, we use llvm to execute vertex shaders on earlier AMD 
chipsets,
newer AMD GPUs are also going to use llvm as the shader compiler backend for
GLSL shaders.

AMD also have open source OpenCL work in progress, that uses the GPU driver
and LLVM.

It probably makes sense that one of myself, ajax or glisse help out packaging
llvm, but we aren't the most reliable people in terms of spare time to commit.

Dave.

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

Re: RFC: Primary architecture promotion requirements

[David Airlie]

- Original Message -
 From: Josh Boyer jwbo...@gmail.com
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
 Cc: Jakub Jelinek ja...@redhat.com, second...@lists.fedoraproject.org
 Sent: Tuesday, 20 March, 2012 4:08:16 PM
 Subject: Re: RFC: Primary architecture promotion requirements
 
 On Tue, Mar 20, 2012 at 11:58 AM, Brendan Conoboy b...@redhat.com
 wrote:
  On 03/20/2012 08:24 AM, Jakub Jelinek wrote:
 
  I think the speed of the build hardware should be also part of the
  criteria,
  as all primary architectures are built synchronously.  GCC on
  x86_64/i686
  currently builds often in 2 hours, sometimes in 4 hours if a
  slower or
  more
  busy box is chosen, but on ARM it regularly builds 2 days.  That
  is a slow
  down factor of 12x-24x, guess for other larger packages it is
  similar.
 
 
  Our current build systems can turn GCC 4.7 around in about 24
  hours. The
  enterprise hardware we anticipate using will take that down to
  about 12
  hours.  If speed of build hardware is a consideration, where do you
  draw the
  line?  No secondary arch is going to get to the speed of x86_64 in
  the
  foreseeable future, so it's effectively a way to keep PA an
  exclusive x86
  club.
 
  I think the real question is, for the developers of on devel-list,
  how will
  longer builds for one arch than another affect your workflow?  If
  builds on
  two architectures start at the same time, but one takes longer to
  finish
  than the other, how will that impact you?  Right now you'll still
  be able to
  see and use the results of the faster build before the slower build
  completes, so are you materially impacted?
 
 I thought about this a bit yesterday.  My conclusions are that it
 will
 impact people in 2 cases.
 
 1) The build works fine on i686 and x86_64 and completes in the
 current
 normal time, but then the ARM build fails some number of
 minutes/hours
 later.  For most packages, that likely isn't a big deal but for large
 packages like gcc and the kernel, I could have done exactly what you
 propose and downloaded the x86 results while waiting hours for ARM to
 complete and tested.  If the ARM build fails while I'm doing that, I
 need
 to go and redo that testing after ARM is fixed because it failing
 will fail
 the entire koji build.
 
 2) Updates.  Submitting updates requires the entire build to be
 complete
 which means you have to wait for the slowest thing to finish.  Having
 to
 wait for 12 hours effectively means you can't even test your update
 until
 the next day, and then after you test it you can submit it.  Again,
 this
 is mostly compounded for large packages, but it does impact workflow.
 

3) chain builds in rawhide become slower.

For X we do a lot of chain + dependency building, and I think the gnome guys do 
as well

So now I have 12 packages to update, I need the first two to complete before I 
can get the next 10 etc,

Dave.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Heads up: F17 Alpha RC1 arriving ahead of schedule

[David Airlie]

  TC3:
  
  https://fedorahosted.org/rel-eng/ticket/5083
  
  this is two days ahead of schedule, but it's good to get going
  early!
  The compose should arrive some time today, Andre will no doubt
  announce
  it as usual. Thanks all.
 
 Ugh, we really want this one:
 https://admin.fedoraproject.org/updates/beefy-miracle-kde-theme-16.91.0.1-1.fc17,kde-settings-4.8-5.fc17
 in! :-(
 
 Without it, Plasma has a blank (all black) background.

What KDE isn't perfect in the distro at Alpha, we should revert it to the one 
from F16?

sorry I can't resist joining in the fedora-devel meme of the week.

Dave.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

rawhide java versioning issue?

[David Airlie]

so I was trying to fix xorg-x11-docs, which uses fop which uses java, which 
means I've no idea.

http://koji.fedoraproject.org/koji/taskinfo?taskID=3549524

The main error is below so I suspect the problem is that some apache/avalon 
framework jar file is build with the 1.7 jdk but the buildroot installed the 
1.6 jdk. Should something have its dependency bumped?

Dave.

usr/bin/xmlto: line 316: local: can only be used in a function
  GENfonts.ps
/usr/bin/xmlto: line 316: local: can only be used in a function
Making portrait pages on A4 paper (210mmx297mm)
java virtual machine used: /usr/lib/jvm/jre/bin/java
classpath used: 
/usr/share/java/commons-io.jar:/usr/share/java/batik-all.jar:/usr/share/java/avalon-framework-api.jar:/usr/share/java/avalon-framework-impl.jar:/usr/share/java/xmlgraphics-commons.jar:/usr/share/java/commons-logging.jar:/usr/share/java/fop.jar:
main class used: org.apache.fop.cli.Main
flags used: 
options used: 
arguments used: -fo /tmp/xmlto.1D9adG/fonts.proc -ps 
/builddir/build/BUILD/xorg-docs-1.6/general/fonts/fonts.ps
Exception in thread main java.lang.UnsupportedClassVersionError: 
org/apache/avalon/framework/configuration/ConfigurationException : Unsupported 
major.minor version 51.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:634)
at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)
at java.net.URLClassLoader.access$000(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:212)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
at org.apache.fop.apps.FopFactory.init(FopFactory.java:153)
at org.apache.fop.apps.FopFactory.newInstance(FopFactory.java:177)
at 
org.apache.fop.cli.CommandLineOptions.init(CommandLineOptions.java:121)
at org.apache.fop.cli.Main.startFOP(Main.java:157)
at org.apache.fop.cli.Main.main(Main.java:204)
make[2]: *** [fonts.ps] Error 1
make[2]: Leaving directory `/builddir/build/BUILD/xorg-docs-1.6/general/fonts'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/builddir/build/BUILD/xorg-docs-1.6/general'
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: BEWARE: a problematic glibc made it to stable (F16)

[David Airlie]

 
  The Glibc package maintainer.  I'm pretty sure he understands
  upstream, and FESCo should probably start the discussion with him
  first anyway.
 
 I'm not exactly sure what glibc upstream (defined as people without
 commit rights to Fedora git) have to do with this at all.  The issue
 AIUI is that unproven glibc changes are getting committed to stable
 Fedora branches rather than rawhide where they belong.  Surely, this
 is a matter to discuss with the Fedora maintainer(s) of glibc and
 nobody
 else.

They are mostly the same people.

Its not like glibc is that inviting for a development community to gather 
around.

Dave.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: grub / grub2 conflicts

[David Airlie]

 On Thu, Sep 22, 2011 at 05:18:09PM +0100, Mark McLoughlin wrote:
  On Thu, 2011-09-22 at 17:00 +0100, Matthew Garrett wrote:
   grub provides no mechanism for you to know that, which means you
   can't
   reliably know that. Which means relying on them being compatible
   is
   incorrect.
  
  You described yourself how libguestfs could check it. And failing
  libguestfs doing it, the user could be warned to check it.
 
 I described something that is, practically speaking, impossible.

you run rpm -q grub in the guest and on the host, if they are the same nvr,
then they are the same package, where's the rocket science here.

 There is no rational reason to have grub and grub2 installed on the
 same
 system at once, and having them both there increases the complexity
 of
 the system.

you can install KDE and GNOME and you are worrying about grub and grub2?

surely grubby could detect which one is actually in use and pick it without the 
world ending.

but I agree with Mark, you guys are completely conflating two very different 
things and using
one to justify the other.

the is no technical reason why grub and grub2 should conflict, if there is 
syslinux should also conflict.

Maybe I have a grub USB key I want to update with a new grub while my main MBR 
is grub2.

Dave.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: grub / grub2 conflicts

[David Airlie]

 On Thu, Sep 22, 2011 at 02:02:15PM -0400, David Airlie wrote:
 
  you run rpm -q grub in the guest and on the host, if they are the
  same nvr,
  then they are the same package, where's the rocket science here.
 
 No, that's not good enough. You need to know the version installed on
 the system, not the packaged version. Upgrading the package doesn't
 cause grub-install to be rerun.
 
   There is no rational reason to have grub and grub2 installed on
   the
   same
   system at once, and having them both there increases the
   complexity
   of
   the system.
  
  you can install KDE and GNOME and you are worrying about grub and
  grub2?
 
 They don't both attempt to sit in the same few bytes.

Nicely editing out of the other use-case I supplied. grub and grub2 *packages* 
don't install into the same few bytes.

I thought you were good at backing up arguments with technical reasons, not 
strawmen.

The argument is should it be possible to install grub1 and grub2 *packages* on 
the same system?

The strawman is if you install grub1 and grub2 bootloaders into the MBR on the 
same system they will conflict. I totally agree with your strawman, but you 
still haven't provided any technical reasons why the argument is wrong. Above 
all people Matthew I thought you were aware of how strawmen work and would be 
against their use.

Dave.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: noexec on /dev/shm

[David Airlie]

- John Reiser jrei...@bitwagon.com wrote:

 On 12/14/2010 07:28 PM, Lennart Poettering wrote:
 
  In order to make things secure we minimize what is allowd on the
 various
  API file systems we mount. That includes that we set noexec and
 similar
  options for the file systems involved. The interface how to access
  /dev/shm is called shm_open(), and given that this is how it is
 there is
  very little reason to allow people to execute binaries from them.
 Of
  course, this is a very recent change, and at this point while we
 assume
  that this will not break any valid use of this directory, we cannot
 be
  sure about this, so we'd be very interested to learn why exactly
 you
  want the noexec to be dropped. What is your application that needs
 that?
  If there is a point in dropping the noexec, we'll definitely be
 willing
  to do so, but if the only reason would be I always misused /dev/shm
 as
  a scratch space, then we won't be very convinced. The API fom
 /dev/shm
  is shm_open(), and if you place other stuff in there, then you are
  misusing it and actually creating all kinds of namespacing problems
  (since /dev/shm is actually an all-user shared namespace), and we
 aren't
  particularly keen to support such misuses by default.
 
 The claim The API for /dev/shm is shm_open() is incorrect.
 Very early in the history of shm [late 1970's at the Columbus, Ohio,
 USA
 branch of Bell Telephone Laboratories], then shm_open, shmget, etc.,
 were
 the only means of access; the objects had names that were 32-bit
 binary
 integers.  In fact, when shm became more widely used then there were
 denial-of-service attacks based on the premise that enumerating
 objects
 in shm required 2**32 exhaustive search via shmget.  As soon as
 /dev/shm
 was integrated into the filesystem, then creat, open, read, write,
 close,
 lseek, execve, etc. (any filesystem API) became additional access
 paths.
 This integration began appearing by about the mid 1980's, around 25
 years
 ago, and since then applications have been using /dev/shm via
 ordinary
 files system APIs in addition to shmget etc.
 
 Why?  Because *fast* operations on small numbers of
 small-to-medium-sized
 files can be a big advantage for performance.  /tmp often is much
 slower
 because /tmp often is a harddrive: the need for space in /tmp often
 exceeds
 the size of physical RAM.  Also, mounting /tmp as tmpfs can meet
 resistance
 because tmpfs does not support all features that applications expect.
 A ramdisk might be used, except that early ramdisks allowed at most a
 few megabytes (comparable to the capacity of a floppy disk), which is not
 large enough to support typical simultaneous usage.  Applications
 also cannot rely on ramdisks because superuser privileges usually are
 required to access a ramdisk.  In many cases ramdisks have been
 replaced
 by:  /dev/shm !!
 


You are conflating shm_open and shmget which are two completely separate things,

I'm not sure you actually know what you are talking about, AFAIK /dev/shm is a 
Linux only thing,
that provides an interface for Posix SHM to glibc from the kernel, nothing 
more. Its even mentioned in the man page for shm_open.

It sounds like what you really want is to configure your systems with a RAM 
disk somewhere that you can exec from.

Dave.

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