On 01/05/2017 11:36 PM, Lukas Slebodnik wrote:
On 01/05/2017 08:19 PM, Lukas Slebodnik wrote:
Even if we had this capability, I'm not sure if we would use it in
rawhide. It could considerably increase the size of the dependency
information.
You would remove "temporary versions" with official
On Sun, Feb 5, 2017 at 11:28 PM, Kevin Kofler wrote:
> Tom Hughes wrote:
>> I believe it's referring to the use of /usr/bin/env as mentioned here:
>>
>> https://fedoraproject.org/wiki/Script_Interpreters_(draft)
>
> Note that this is a draft guideline that was voted down:
> https://meetbot.fedorap
Tom Hughes wrote:
> I believe it's referring to the use of /usr/bin/env as mentioned here:
>
> https://fedoraproject.org/wiki/Script_Interpreters_(draft)
Note that this is a draft guideline that was voted down:
https://meetbot.fedoraproject.org/fedora-meeting/2009-08-19/fedora-meeting.2009-08-19-
Hans de Goede wrote:
> First the what: ever since AMD and NVIDIA started shipping
> their own Linux drivers we have had multiple competing
> implementations of libGL.so.1 (and friends) where the way
> the linker works means that there can be only one.
> This has made installing AMD or NVIDIA's driv
Hi Michael,
On Mon, Feb 6, 2017 at 3:31 AM, Michael Catanzaro
wrote:
> Dude it looks like you have a tracking pixel in your mail:
>
> http://405n.mj.am/oo/AEUAHWjyTGwAAC8AAAMA
> AAQnNwBYl01S75wFdcYGRwyu2D_3puuyegAD-So/0b56895f/e.gif" height="1"
> width="1" alt="" border="0" s
On Sun, Feb 05, 2017 at 11:02:16PM +0100, Igor Gnatenko wrote:
> On Sun, 2017-02-05 at 18:29 +, Zbigniew Jędrzejewski-Szmek wrote:
> > systemd.spec file has
> > %ifarch %{ix86} x86_64 aarch64
> > BuildRequires: gnu-efi gnu-efi-devel
> > %endif
> >
> > ... and this seems to work fine in mock/k
On Sun, 2017-02-05 at 18:29 +, Zbigniew Jędrzejewski-Szmek wrote:
> systemd.spec file has
> %ifarch %{ix86} x86_64 aarch64
> BuildRequires: gnu-efi gnu-efi-devel
> %endif
>
> ... and this seems to work fine in mock/koji/etc.
>
> dnf builddep deals file with an srpm built on the architecture:
Dude it looks like you have a tracking pixel in your mail:
http://405n.mj.am/oo/AEUAHWjyTGwAAC8AAAMA
AAQnNwBYl01S75wFdcYGRwyu2D_3puuyegAD-So/0b56895f/e.gif" height="1"
width="1" alt="" border="0" style="height:1px;width:1px;border:0;"/>
Is that intentional? What's up with that
On Sun, 2017-02-05 at 09:10 +0100, Hans de Goede wrote:
> This also mostly explains the why of this change,
> except for why also bring it to Fedora 25 and not
> just to Fedora 26 and later?
>
> The main reason for this is a non-technical reason,
> we (as in the Fedora project) have quite vocally
Hi,
On 05-02-17 20:35, Christian Dersch wrote:
Hi all,
On 02/05/2017 09:10 AM, Hans de Goede wrote:
This also mostly explains the why of this change,
except for why also bring it to Fedora 25 and not
just to Fedora 26 and later?
The main reason for this is a non-technical reason,
we (as in t
Everybody has made some valid points, but as far as pushing to F25
stable goes, there may be an undetermined number of people who
-unaware of this discussion and for whatever reason- already have
libglvnd and relevant packages installed from testing. I'm not sure
that someone who was advised in a f
Hi all,
On 02/05/2017 09:10 AM, Hans de Goede wrote:
>
> This also mostly explains the why of this change,
> except for why also bring it to Fedora 25 and not
> just to Fedora 26 and later?
>
> The main reason for this is a non-technical reason,
> we (as in the Fedora project) have quite vocally
>
On Sun, 5 Feb 2017 11:02:40 -0700
Jerry James wrote:
> I've got 3 updates where something weird happened. Is this a known
> bodhi issue? First is this update:
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2017-b4d8e33d45
>
> I created it to contain updates for both F-24 and F-25 for
> py
On 02/05/2017 09:10 AM, Hans de Goede wrote:
Hi All,
So a lot has been said about $subject and FESco has asked me
to send a mail to the devel list describing the what and why
of this change.
My view: This change is way too radical to apply it to a distribution
midst lifetime of its release.
systemd.spec file has
%ifarch %{ix86} x86_64 aarch64
BuildRequires: gnu-efi gnu-efi-devel
%endif
... and this seems to work fine in mock/koji/etc.
dnf builddep deals file with an srpm built on the architecture:
$ fedpkg clone -a systemd && cd systemd && fedpkg srpm
$ sudo dnf builddep *.src.rpm
I've got 3 updates where something weird happened. Is this a known
bodhi issue? First is this update:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-b4d8e33d45
I created it to contain updates for both F-24 and F-25 for
python-BTrees. As you can see, it contains two instances of the
update
On Tue, 24 Jan, 2017 at 07:06:14 GMT, Mattia Verga wrote:
> In the latest version of RawTherapee, developers suggest the use of
> -DCMAKE_CXX_FLAGS="-std=c++11".
>
> I've tried to modify the .spec file with
> -DCMAKE_CXX_FLAGS="$RPM_OPT_FLAGS -std=c++11" [1], but koji still use
> "-std=c++11 -st
On 02/05/2017 03:10 AM, Hans de Goede wrote:
Hi All,
So a lot has been said about $subject and FESco has asked me
to send a mail to the devel list describing the what and why
of this change.
There's two issues here that are important not to conflate: whether the
glvnd update should go into f2
On 05/02/17 16:05, Pranav Kant wrote:
I have been trying to fix this rpmlint error in one of my package that I
maintain. I can't recall this rpmlint error popping up in previous
updates I pushed for this package, so this looks something new to me.
See the only failed automated test results here
Hi all,
I have been trying to fix this rpmlint error in one of my package that I
maintain. I can't recall this rpmlint error popping up in previous updates
I pushed for this package, so this looks something new to me.
See the only failed automated test results here[1].
1) How can I fix this erro
Missing expected images:
Cloud_base qcow2 x86_64
Kde live x86_64
Cloud_base raw-xz x86_64
Xfce raw-xz armhfp
Minimal raw-xz armhfp
Kde live i386
Failed openQA tests: 63/96 (x86_64), 13/17 (i386)
New failures (same test did not fail in Rawhide-20170204.n.0):
ID: 56362 Test: x86_64 Workstat
I believe there is something wrong in the recent (several months) nouveau
driver. So chances are high that your machine will default to Wayland as
soon as you switch off secondary videochip.
There are some rhbz tickets related though.
05 фев 2017 г. 11:52 пользователь "Timothy Ward"
написал:
>
Just wanted the links to more information on what will cause gdm and
session manager to default to X instead of wayland.
Have a laptop and desktop with fully updated system with debug package
repos active and both systems default to X and will not start on
wayland.
This was not he case with Fedo
Hi All,
So a lot has been said about $subject and FESco has asked me
to send a mail to the devel list describing the what and why
of this change.
First the what: ever since AMD and NVIDIA started shipping
their own Linux drivers we have had multiple competing
implementations of libGL.so.1 (and f
On 02/05/2017 01:32 AM, David Howells wrote:
Panu Matilainen wrote:
%if %{__isa_bits} == 64
Requires: libisl.so.15()(64bit)
%else
Requires: libisl.so.15()
%endif
That doesn't work. It complains about illegal characters.
Sure it works. It's copy-pasted from a spec I just built *just in cas
25 matches
Mail list logo
