On 01/12/2018 06:08 AM, Luya Tshimbalanga wrote:
On 2018-01-11 01:02 PM, Troy Dawson wrote:
Hello,
Python3 will be in the next major RHEL release. I don't mean RHEL
7.6, but with numbers higher than 7.
There are many, many packages with something like the following
if 0%{?fedora}
%defin
Missing expected images:
Atomic qcow2 x86_64
Atomic raw-xz x86_64
Failed openQA tests: 11/129 (x86_64), 5/24 (i386), 1/2 (arm)
New failures (same test did not fail in Rawhide-20180110.n.0):
ID: 185438 Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tes
On 2018-01-11 01:02 PM, Troy Dawson wrote:
> Hello,
> Python3 will be in the next major RHEL release. I don't mean RHEL
> 7.6, but with numbers higher than 7.
> There are many, many packages with something like the following
>
> if 0%{?fedora}
>%define with_python3 1
> %endif
>
> If you ha
On 01/11/18 09:47, Christopher-san wrote:
On Tue, Jan 9, 2018 at 9:08 AM Jan Kurik mailto:jku...@redhat.com>> wrote:
= System Wide Change: IBus Unicode Typing =
https://fedoraproject.org/wiki/Changes/IBus_Unicode_Typing
Change owner(s):
* Takao Fujiwara
IBus core provides
On 01/11/18 09:47, Christopher-san wrote:
On Tue, Jan 9, 2018 at 9:08 AM Jan Kurik mailto:jku...@redhat.com>> wrote:
= System Wide Change: IBus Unicode Typing =
https://fedoraproject.org/wiki/Changes/IBus_Unicode_Typing
Change owner(s):
* Takao Fujiwara
IBus core provides
> I just noticed, there is a difference in the default value of
> `/proc/sys/net/core/optmem_max` on armv7l:
>
> On all arches it is 20480, but on armv7l it is 10240.
>
> Is there any specific reason for limiting the maximum ancillary buffer
> size allowed per socket on this arch?
No specific reas
On Thu, 2018-01-11 at 20:53 -0500, Josh Boyer wrote:
> Small caveat, nobody said RHEL 8. Troy said the next major version of
> RHEL will have python3, that's all. This is where the awkwardness
> comes in. I think people can appreciate not being able to talk
> publicly about any current or future
On Thu, Jan 11, 2018 at 8:32 PM, Jason L Tibbitts III wrote:
>> "JB" == Josh Boyer writes:
>
> JB> Hm. On the one hand, that's a fair assumption to make. On the
> JB> other hand, it seems unnecessarily adversarial.
>
> I certainly didn't intend it that way; hell, none of that even entered
>
> "JB" == Josh Boyer writes:
JB> Hm. On the one hand, that's a fair assumption to make. On the
JB> other hand, it seems unnecessarily adversarial.
I certainly didn't intend it that way; hell, none of that even entered
my mind. To flip it around, to be completely honest your response comes
On Thu, Jan 11, 2018 at 4:34 PM, Jason L Tibbitts III wrote:
>> "FW" == Florian Weimer writes:
>
> FW> It could also be branched into Red Hat Enterprise Linux proper, and
> FW> in that case, it would be nice to minimize the differences.
>
> That would be kind of outside the scope of Fedora, t
On Thu, Jan 11, 2018 at 11:24:56PM +0100, Lennart Poettering wrote:
> I hope you are aware that user id 65534 is used by user namespacing
> (i.e. CLONE_NEWUSER) too, and in that context is probably much more
> prominently visible to users than in the NFS context. The fact that
> the user/group is c
On Thu, 11 Jan 2018, Lennart Poettering wrote:
> We are not taking the concept of this user/group away. We are also not
> taking the UID/GID assignment 65534 away, either. All we are doing is
> assigning it a better name and do so unconditionally, independently of
> whether nfsutils is installed o
On Do, 11.01.18 16:13, Steve Dickson (ste...@redhat.com) wrote:
> > This is problematic in a few different ways:
> > * 65534:65534 is used by the kernel as the overflow identifier, when
> > some UID cannot be represented in the current namespace. This applies
> > to both NFS, but probably more com
On Thu, 2018-01-11 at 13:55 -0800, Adam Williamson wrote:
> Hi folks!
>
> Kernel updates for Fedora 26 and Fedora 27 are now available with
> initial mitigations for both Spectre variants. As the update
> description states:
>
> "This is also the first update to contain some spectre mitigations.
Hi folks!
Kernel updates for Fedora 26 and Fedora 27 are now available with
initial mitigations for both Spectre variants. As the update
description states:
"This is also the first update to contain some spectre mitigations.
Some patches for variant 1 as well as the initial retpoline build for
va
Planned Outage: apps.fedoraproject.org/nuancier 2018-01-12 10:00 UTC
There will be an outage starting at 2018-01-12 10:00 UTC, which will last
approximately 30 minutes,
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run:
date -d '2018-0
> "FW" == Florian Weimer writes:
FW> It could also be branched into Red Hat Enterprise Linux proper, and
FW> in that case, it would be nice to minimize the differences.
That would be kind of outside the scope of Fedora, though. Many of us
watching from outside would assume that instructions
On 01/11/2018 10:09 PM, Jason L Tibbitts III wrote:
TD> If you have something like that, please change it to something like
TD> this.
TD> if 0%{?fedora} || 0%{?rhel} > 7
TD>%define with_python3 1
TD> %endif
If things work as they have in the past, packages will need to
explicitly be bra
On Thu, Jan 11, 2018 at 01:57:55PM -0600, Justin Forbes wrote:
> Following is the list of topics that will be discussed in the
> FESCo meeting Friday at 16:00UTC in #fedora-meeting on
> irc.freenode.net.
>
> To convert UTC to your local time, take a look at
> http://fedoraproject.org/wiki/UTCHow
On 01/10/2018 11:14 AM, Stephen John Smoogen wrote:
> On 10 January 2018 at 08:50, Neal Gompa wrote:
>> On Wed, Jan 10, 2018 at 5:46 AM, Jan Kurik wrote:
>
>>> The new mapping for nobody:nobody would be implemented in two redundant
>>> ways:
>>> * as a static allocation in /etc/passwd and
WOW... Why do you guys keep picking on NFS?? :-)
On 01/10/2018 05:46 AM, Jan Kurik wrote:
> = System Wide Change: Rename "nobody" user =
> https://fedoraproject.org/wiki/Changes/RenameNobodyUser
>
> Change owner(s):
> *Zbigniew Jędrzejewski-Szmek
> * Lennart Poettering
>
> Use "nobody:nobody"
> "TD" == Troy Dawson writes:
TD> If you have something like that, please change it to something like
TD> this.
TD> if 0%{?fedora} || 0%{?rhel} > 7
TD>%define with_python3 1
TD> %endif
If things work as they have in the past, packages will need to
explicitly be branched for EPEL8 an
Hello,
Python3 will be in the next major RHEL release. I don't mean RHEL
7.6, but with numbers higher than 7.
There are many, many packages with something like the following
if 0%{?fedora}
%define with_python3 1
%endif
If you have something like that, please change it to something like th
Announcing the creation of a new nightly release validation test event
for Fedora 28 Rawhide 20180111.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki
Following is the list of topics that will be discussed in the
FESCo meeting Friday at 16:00UTC in #fedora-meeting on
irc.freenode.net.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/UTCHowto
or run:
date -d '2018-01-12 16:00 UTC'
Links to all issues below ca
Hello together,
I just noticed, there is a difference in the default value of
`/proc/sys/net/core/optmem_max` on armv7l:
On all arches it is 20480, but on armv7l it is 10240.
Is there any specific reason for limiting the maximum ancillary buffer
size allowed per socket on this arch?
Cheers,
B
On Thu, Jan 11, 2018 at 1:08 PM, Adam Williamson wrote:
> On Thu, 2018-01-11 at 10:19 -0700, Chris Murphy wrote:
> > On Thu, Jan 11, 2018 at 3:26 AM, James Hogarth
> wrote:
> >
> > > Having upgraded and freshly installed systems so different is going to
> > > be messy with supporting users and i
On Thu, 2018-01-11 at 10:19 -0700, Chris Murphy wrote:
> On Thu, Jan 11, 2018 at 3:26 AM, James Hogarth
> wrote:
>
> > Having upgraded and freshly installed systems so different is going to
> > be messy with supporting users and in many deployed environments...
> > and it's not even about F26 an
On Thu, Jan 11, 2018 at 3:26 AM, James Hogarth wrote:
> Having upgraded and freshly installed systems so different is going to
> be messy with supporting users and in many deployed environments...
> and it's not even about F26 and F27 -> F28 but what happens on an F29+
> system?
>
> Is this worka
On Thu, Jan 11, 2018 at 6:57 AM, Zbigniew Jędrzejewski-Szmek
wrote:
> And also, at some point in the future once this is implemented and the
> new setup has been around for a while, systemd should start emitting a
> warning during boot, to notify people that such setups will stop being
> supporte
On Thu, Jan 11, 2018 at 5:53 AM, Zbigniew Jędrzejewski-Szmek
wrote:
> On Thu, Jan 11, 2018 at 10:26:19AM +, James Hogarth wrote:
>> I know this may sound fairly nasty in terms of work required to agree
>> a solution but I honestly have a strong dislike to taking this
>> approach.
>>
>> Having
On Thu, Jan 11, 2018 at 5:39 AM, David Demelier wrote:
> On Thu, Jan 11, 2018 at 05:22:05AM -0500, Nico Kadel-Garcia wrote:
>> What RPM are you building from?
>
> I do rpmbuild -ba OpenRCT2.spec
I should have said "SRPM". What you have mentioned there is a .spec
file, and I've no idea where you g
Hello,
I have orphaned:
- perl-Net-Ping-External (no in-Fedora users it seems)
- perl-Net-RawIP (used by sqlninja)
- python-4Suite-XML (used by python-amara and testoob)
Feel free to take them over.
Mirek
___
devel mailing list -- devel@list
On Wed, 2018-01-10 at 08:06 -0800, Kevin Fenzi wrote:
> On 01/09/2018 02:09 PM, Tim Landscheidt wrote:
> > BTW, are there technical reasons why the metadata is updated
> > en bloc and not incrementally like for example delta RPMs,
> > or is it just that nobody bothered to implement something
> > li
> And also, at some point in the future once this is implemented and the
> new setup has been around for a while, systemd should start emitting a
> warning during boot, to notify people that such setups will stop being
> supported at some future point.
But your average user won't see that. For sta
> If anyone notices Ruby programs which suddenly start to throw stack
overflow errors (SystemStackError or the error message
"stack level too deep") but *only* in the latest Rawhide (glibc >=
2.26-9000, ruby >= 2.5.0), then I'm interested to hear from you.
I faced "stack level too deep" when runni
On Wed, Nov 1, 2017 at 7:48 PM, Kevin Fenzi wrote:
> On 10/24/2017 03:36 AM, Kamil Paral wrote:
> > On Sun, Oct 8, 2017 at 12:14 AM, Kevin Fenzi wrote:
> >
> >> They should be there starting tomorrow.
> >>
> >
> >
> > I still don't see any dumps in there. Is it still being worked on?
>
> I seem
Hello Dominik,
On Thu, Jan 11, 2018 at 2:52 PM, Dominik 'Rathann' Mierzejewski
wrote:
> On Saturday, 26 August 2017 at 22:50, Alexander Ploumistos wrote:
> [...]
>> I have checked if there are any packages at the moment that require
>> liborigin* or liborigin*-devel and I have found none (though
OK I believe this is actually a bug in the nbdkit plugin rather than
glibc / Ruby. Apparently you need to call some functions to tell Ruby
about the thread stacks. Totally undocumented ...
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programmi
On Wed, Jan 10, 2018 at 2:23 PM, Andrew Lutomirski wrote:
>> On Jan 9, 2018, at 9:59 AM, Kevin Fenzi wrote:
>>
>>> On 01/08/2018 10:53 AM, Kevin Kofler wrote:
>>> Kevin Fenzi wrote:
Well, if this firefox update was urgent, shouldn't it have been marked
urgent?
>>>
>>> Urgency is always
One followup that should help people understand things:
When someone pushes an update to a package that isn't
in Atomic Host (or Workstation), *and* one is using rpm-ostree
in "pure ostree" mode (i.e. you never ran `rpm-ostree install`),
then checking for updates just uses libostree, which like an
Hello, Alexander.
Sorry to bring back an old e-mail, but it seems there were no replies.
On Saturday, 26 August 2017 at 22:50, Alexander Ploumistos wrote:
[...]
> I have checked if there are any packages at the moment that require
> liborigin* or liborigin*-devel and I have found none (though I'd
On Wed, Jan 10, 2018, at 2:38 PM, Stephen John Smoogen wrote:
>
> This sounds a lot like the Atomic project and how it does things...
Atomic could mean either (rpm)-ostree or Docker/OCI. In the
Docker/OCI world search isn't standardized yet AIUI but there's
progress on that upstream. I am not
On Thu, Jan 11, 2018 at 01:19:41PM +0100, Florian Weimer wrote:
> On 01/11/2018 12:42 PM, Richard W.M. Jones wrote:
> >If anyone notices Ruby programs which suddenly start to throw stack
> >overflow errors (SystemStackError or the error message
> >"stack level too deep") but*only* in the latest Ra
Hi everyone,
just a heads-up that we are going to rename the webkitgtk4 package to
webkit2gtk3 in the rawhide - please see [0]. I will take care of updating
the BR for the packages under gnome-sig myself and for others I will create
a PR.
$ dnf repoquery --whatrequires webkitgtk4 --arch x86_64
--
Dne 10.1.2018 v 21:47 Kevin Howell napsal(a):
> Right now, I'm thinking what must be done is: rename
> subscription-manager-rhsm to python-rhsm or python2-rhsm or
> python3-rhsm per the python naming guidelines.
Rename the package to python-rhsm which does not have main package and only two
subp
On 11.01.2018 09:25, Dominik 'Rathann' Mierzejewski wrote:
Hi, Sandro.
On Wednesday, 10 January 2018 at 14:58, Sandro Mani wrote:
I've received a request to package a version of scotch with 64bit integers
(as opposed to 32bit). I suppose the details are less important, the bottom
line is
sco
On 01/11/2018 12:42 PM, Richard W.M. Jones wrote:
If anyone notices Ruby programs which suddenly start to throw stack
overflow errors (SystemStackError or the error message
"stack level too deep") but*only* in the latest Rawhide (glibc >=
2.26-9000, ruby >= 2.5.0), then I'm interested to hear fr
On Wed, Jan 10, 2018 at 7:50 PM, Adam Williamson wrote:
> On Wed, 2018-01-10 at 10:45 +0100, Kamil Dudka wrote:
> > On Tuesday, January 9, 2018 11:51:03 PM CET David Kaspar [Dee'Kej] wrote:
> > > The new Ghostscript should be available for trying/testing in Rawhide
> in a
> > > few hours. I will
On Thu, Jan 11, 2018 at 12:34:54PM +0100, Lennart Poettering wrote:
> On Do, 11.01.18 10:53, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
>
> > > As a very simple example take a docker host that has been upgraded
> > > with a fresh container on it. The nobody user is going to differ
> >
If anyone notices Ruby programs which suddenly start to throw stack
overflow errors (SystemStackError or the error message
"stack level too deep") but *only* in the latest Rawhide (glibc >=
2.26-9000, ruby >= 2.5.0), then I'm interested to hear from you.
Rich.
--
Richard Jones, Virtualization Gr
On Do, 11.01.18 10:53, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> > As a very simple example take a docker host that has been upgraded
> > with a fresh container on it. The nobody user is going to differ
> > between the two which will at a minimum cause confusion, if not actual
> > i
On Thu, Jan 11, 2018 at 11:50:50AM +0100, Andrea Musuruane wrote:
> Actually you should use the %cmake macro:
> https://fedoraproject.org/wiki/Packaging:Cmake
Thanks, this is indeed the correct solution.
--
David Demelier
___
devel mailing list -- deve
On 01/11/2018 11:45 AM, David Demelier wrote:
On Thu, Jan 11, 2018 at 11:21:56AM +0100, Patrick Monnerat wrote:
I also encountered this problem before and I fixed it by respecting the
RPM_OPT_FLAGS. Before cmake, use:
export CFLAGS="${RPM_OPT_FLAGS}"
export CXXFLAGS="${RPM_OPT_FLAGS}"
Is ther
On Thu, Jan 11, 2018 at 10:26:19AM +, James Hogarth wrote:
> On 11 January 2018 at 01:41, Zbigniew Jędrzejewski-Szmek
> wrote:
> > On Wed, Jan 10, 2018 at 10:26:24AM -0500, Nico Kadel-Garcia wrote:
> >> On Wed, Jan 10, 2018 at 6:18 AM, Zbigniew Jędrzejewski-Szmek
> >> wrote:
> >> > On Wed, Ja
On Thu, Jan 11, 2018 at 11:45 AM, David Demelier
wrote:
> Is there a place where you see that we must use this variable?
>
> Anyway, it worked, I changed the CMake invocation to:
>
> cmake ... \
> -DCMAKE_C_FLAGS="${RPM_OPT_FLAGS}" \
> -DCMAKE_CXX_FLAGS="${RPM_OPT_FLAGS}" \
>
On Thu, 2018-01-11 at 11:21 +0100, Patrick Monnerat wrote:
> I also encountered this problem before and I fixed it by respecting
> the
> RPM_OPT_FLAGS. Before cmake, use:
>
> export CFLAGS="${RPM_OPT_FLAGS}"
> export CXXFLAGS="${RPM_OPT_FLAGS}"
>
> This did the trick.
>
> Obviously the problem
On Thu, Jan 11, 2018 at 11:21:56AM +0100, Patrick Monnerat wrote:
> I also encountered this problem before and I fixed it by respecting the
> RPM_OPT_FLAGS. Before cmake, use:
>
> export CFLAGS="${RPM_OPT_FLAGS}"
> export CXXFLAGS="${RPM_OPT_FLAGS}"
Is there a place where you see that we must us
On Thu, Jan 11, 2018 at 05:22:05AM -0500, Nico Kadel-Garcia wrote:
> What RPM are you building from?
I do rpmbuild -ba OpenRCT2.spec
--
David Demelier
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@l
On 11 January 2018 at 01:41, Zbigniew Jędrzejewski-Szmek
wrote:
> On Wed, Jan 10, 2018 at 10:26:24AM -0500, Nico Kadel-Garcia wrote:
>> On Wed, Jan 10, 2018 at 6:18 AM, Zbigniew Jędrzejewski-Szmek
>> wrote:
>> > On Wed, Jan 10, 2018 at 11:56:46AM +0100, Reindl Harald wrote:
>> >>
>> >> Am 10.01.2
On Thu, Jan 11, 2018 at 5:13 AM, David Demelier wrote:
> Hello,
>
> I'm trying to upgrade my OpenRCT 2 package [0] to fedora 27.
>
> It looks like something changed regarding the generation of debug files
> because
> I can't get it to build a .rpm anymore.
>
> I get:
>
> Processing files: Ope
On 01/11/2018 11:13 AM, David Demelier wrote:
Hello,
I'm trying to upgrade my OpenRCT 2 package [0] to fedora 27.
It looks like something changed regarding the generation of debug files because
I can't get it to build a .rpm anymore.
I get:
Processing files: OpenRCT2-debugsource-0.1.1-
Hello,
I'm trying to upgrade my OpenRCT 2 package [0] to fedora 27.
It looks like something changed regarding the generation of debug files because
I can't get it to build a .rpm anymore.
I get:
Processing files: OpenRCT2-debugsource-0.1.1-1.fc27.x86_64
error: Empty %files file
/home/m
Hi, Sandro.
On Wednesday, 10 January 2018 at 14:58, Sandro Mani wrote:
> I've received a request to package a version of scotch with 64bit integers
> (as opposed to 32bit). I suppose the details are less important, the bottom
> line is
>
> scotch 32bit: typedef int32_t SCOTCH_Num;
>
> scotch 64b
On Wednesday, 10 January 2018 at 23:27, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Jan 09, 2018 at 08:27:51PM +, Sérgio Basto wrote:
[...]
> > I need more one help from provenpackager merge and build player [1]
> > from what I see to build fawkes, you just need rebuild player. I had
> > confu
65 matches
Mail list logo
