On Thu, Feb 4, 2016 at 5:12 PM, Adam Williamson
wrote:
> Hi folks! As part of the efforts to integrate openQA testing for Fedora
> I've been working to get the packages in the official repositories (for
> now the Fedora deployments are pulling openqa itself from a COPR).
> We've now got all the de
kendell clark wrote:
> However, this is not always easy. The comments in this thread about
> packagers can also be applied, easily, to the upstream community. Some
> devs are friendly and helpful, while others are do it my way types of
> people. Chromium is a good example of the latter.
As the QtW
From 570b3341890b3490a7051a8e6523b0f1a3d5ddfa Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering
Date: Thu, 4 Feb 2016 13:06:50 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild
---
perl-Data-GUID.spec | 5 -
1 file changed, 4 insertions(+), 1 deletion
On Thu, Feb 04, 2016 at 01:11:48PM -0800, Andrew Lutomirski wrote:
> On Wed, Feb 3, 2016 at 8:44 AM, Zbigniew Jędrzejewski-Szmek
> wrote:
> > Sorry to reply with such a delay.
> >
> > On Mon, Jan 25, 2016 at 07:43:35PM -0800, Andrew Lutomirski wrote:
> >> I also think that the whole gethostname(2)
On Thu, Feb 04, 2016 at 03:38:36PM -0700, Stefan Nuxoll wrote:
> No, but it would be a good start. Maybe koji can automatically open a ticket
> on bugzilla for all packages that require a rebuild due to an soname bump (if
> the package Requires either the package or has a query-able reference to
No, but it would be a good start. Maybe koji can automatically open a ticket on
bugzilla for all packages that require a rebuild due to an soname bump (if the
package Requires either the package or has a query-able reference to that
library). Automatically attempting a scratch rebuild of the dep
Hi folks! As part of the efforts to integrate openQA testing for Fedora
I've been working to get the packages in the official repositories (for
now the Fedora deployments are pulling openqa itself from a COPR).
We've now got all the dependencies and os-autoinst (the test runner)
packaged, and I've
On Thu, Feb 04, 2016 at 01:34:28PM -0700, Kevin Fenzi wrote:
> Greetings, we've been told that the email addresses
> for these package maintainers are no longer valid. I'm starting the
> unresponsive maintainer policy to find out if they are still interested
> in maintaining their packages (and if
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Following is the list of topics that will be discussed in the FESCo
meeting Friday at 17:00UTC in #fedora-meeting on irc.freenode.net.
NOTE: due to DevConf.cz, we may not have quorum and these may be discussed
next week instead.
To convert UTC to yo
On 4 February 2016 at 17:22, Adam Jackson wrote:
> Which GPU is this with? How big are the displays you're using?
It is a Dell XPS 15 (2014 mod), with a single Intel display adapter.
The internal display is 15" and the external is 40+" something, both
full HD. The bug is always triggered on the in
On Wed, Feb 3, 2016 at 8:44 AM, Zbigniew Jędrzejewski-Szmek
wrote:
> Sorry to reply with such a delay.
>
> On Mon, Jan 25, 2016 at 07:43:35PM -0800, Andrew Lutomirski wrote:
>> I also think that the whole gethostname(2) mechanism is terminally
>> screwed up. We abuse the hostname for multiple pur
Greetings, we've been told that the email addresses
for these package maintainers are no longer valid. I'm starting the
unresponsive maintainer policy to find out if they are still interested
in maintaining their packages (and if so, have them update their email
addresses in FAS). If they're not
On 02/04/2016 08:48 PM, Richard Shaw wrote:
> On Thu, Feb 4, 2016 at 1:37 PM, Florian Weimer wrote:
>
>>> I haven't gone back and checked the full release but I would think that
>> the
>>> --scrub=all to mock would bring all packages up to the same level.
>>
>> Did you specify the mock config as
On Thu, Feb 4, 2016 at 1:52 PM, Florian Weimer wrote:
> On 02/04/2016 08:48 PM, Richard Shaw wrote:
> > On Thu, Feb 4, 2016 at 1:37 PM, Florian Weimer
> wrote:
> >
> >>> I haven't gone back and checked the full release but I would think that
> >> the
> >>> --scrub=all to mock would bring all pac
On Thu, Feb 4, 2016 at 1:37 PM, Florian Weimer wrote:
> > I haven't gone back and checked the full release but I would think that
> the
> > --scrub=all to mock would bring all packages up to the same level.
>
> Did you specify the mock config as well? I think it just scrubs a
> single chroot.
On 02/04/2016 08:36 PM, Richard Shaw wrote:
> On Thu, Feb 4, 2016 at 1:17 PM, Florian Weimer wrote:
>
>> On 02/04/2016 08:04 PM, Richard Shaw wrote:
>>> I'm getting the following error when I build on koji but all mock builds
>>> complete. I even did a --scrub=all just to see if the package set w
On Thu, Feb 4, 2016 at 1:17 PM, Florian Weimer wrote:
> On 02/04/2016 08:04 PM, Richard Shaw wrote:
> > I'm getting the following error when I build on koji but all mock builds
> > complete. I even did a --scrub=all just to see if the package set was
> > slightly different due to the root cache b
On 02/04/2016 08:04 PM, Richard Shaw wrote:
> I'm getting the following error when I build on koji but all mock builds
> complete. I even did a --scrub=all just to see if the package set was
> slightly different due to the root cache but it still completes in mock:
> /builddir/build/BUILD/oiio-Rel
On 02/04/2016 01:14 PM, Felix Miata wrote:
Przemek Klosowski composed on 2016-02-04 12:28 (UTC-0500):
for a in {a..z} {A..Z} ; do dnf update $a'*'; done
An alternative to what I've been doing. When I can remember, I first change
to an empty directory before typing dnf, so bash has nothing loca
I'm getting the following error when I build on koji but all mock builds
complete. I even did a --scrub=all just to see if the package set was
slightly different due to the root cache but it still completes in mock:
[ 47%] Building CXX object
src/libOpenImageIO/CMakeFiles/OpenImageIO.dir/__/dpx.im
Missing expected images:
Cloud disk raw i386
Cloud_atomic disk raw x86_64
Kde disk raw armhfp
Kde live i386
Cloud disk raw x86_64
Kde live x86_64
No images in this compose but not Rawhide 20160203
Images in Rawhide 20160203 but not this:
Design_suite live x86_64
Kde live i386
Scientific_kde liv
On 4 Feb 2016 7:06 pm, "Dave Johansen" wrote:
>
> On Wed, Feb 3, 2016 at 8:40 AM, Dennis Gilmore wrote:
>>
>> Hi all,
>>
>> Per the Fedora 24 schedule[1] we will be starting a mass rebuild for
Fedora 24
>> very shortly. We are doing a mass rebuild for Fedora 24 for
>> https://fedoraproject.org/w
Przemek Klosowski composed on 2016-02-04 12:28 (UTC-0500):
> Felix Miata wrote:
>> I have lots of test installations using identical partition sizes for EXT3 or
>> EXT4 / filesystems. the filesystem space these provided is adequate on all if
>> running Mageia or openSUSE, but quite often not for
On Wed, Feb 3, 2016 at 8:40 AM, Dennis Gilmore wrote:
> Hi all,
>
> Per the Fedora 24 schedule[1] we will be starting a mass rebuild for
> Fedora 24
> very shortly. We are doing a mass rebuild for Fedora 24 for
> https://fedoraproject.org/wiki/Changes/GCC6
>
> we will start the mass rebuild on 2
On 02/03/2016 05:28 PM, Felix Miata wrote:
I have lots of test installations using identical partition sizes for EXT3 or
EXT4 / filesystems. the filesystem space these provided is adequate on all if
running Mageia or openSUSE, but quite often not for Fedora. Working around
the inadequacy on Fedor
On Thu, 2016-02-04 at 12:47 +, Jonny Heggheim wrote:
> Hi, my internal laptop screen turns on and off.
>
> It happens both on Fedora 23 and Fedora rawhide. With Gnome 3 and
> xmonad. The bug is triggered by most of the webpages. It have also
> happend with other programs, but I have not been e
On 04/02/16 00:08 +0100, Kevin Kofler wrote:
Jonathan Wakely wrote:
A workaround would be to make it too hard for the compiler to see the
problem:
void* ptr = page->data;
_root = new (ptr) impl::xml_document_struct(page);
This way GCC doesn't see that the address refers to a 1-byte array.
I observer this issue like past 10 release of FF. Some versions it is
better, some worse.
Why is the ABRT handler disabled anyway? I have no idea where the data
from the default handler goes and I doubt anybody cares (but I hope I am
wrong ;))
Vít
Dne 3.2.2016 v 12:12 Martin Stransky napsal(a
On 03/02/16 15:10 -0800, Samuel Sieb wrote:
On 02/03/2016 02:28 PM, Felix Miata wrote:
Problem #3:
When running from say the /boot directory the same dnf command above:
# dnf update kd*, kf*, q*, per*, pyt*, u*, v*, x* y*, z*
dnf reports cannot install package inityada, cannot install
Hello everyone,
another version od DNF and DNF-PLUGINS-CORE has been released. Recently
released DNF adds socks5
proxy support and repoquery has new --unneeded and --recent switches available.
Additionally a lot
of bugs have been fixed. For more information see DNF [1] and plugins [2]
release n
I have comments at the top of the spec file that explain the reason for
the warning below. In addition, I have posted messages about this
warning on this list; see
project.org/thread/GI3L74J47OLRTYLQIMSEUA7SUZR5VLU7/#JUUSDFET2HBPUDIP3G7CPHB7Q7XCCLEG
Should I just ignore the message below ?
On
On 04/02/16 13:44 +0100, Sandro Mani wrote:
On 04.02.2016 13:40, Jakub Jelinek wrote:
On Thu, Feb 04, 2016 at 01:36:50PM +0100, Sandro Mani wrote:
Med builds are failing with
medfile_int_wrap.cc:11272:30: error: no matching function for call to 'std::vector >::erase(SwigValueWrapper<__gnu_cx
Hi, my internal laptop screen turns on and off.
It happens both on Fedora 23 and Fedora rawhide. With Gnome 3 and
xmonad. The bug is triggered by most of the webpages. It have also
happend with other programs, but I have not been enabled to know what
triggerer the bug
It is hard to write a bug re
On 04.02.2016 13:45, Jonathan Wakely wrote:
On 04/02/16 13:36 +0100, Sandro Mani wrote:
Hi
Med builds are failing with
medfile_int_wrap.cc:11272:30: error: no matching function for call to
'std::vector
>::erase(SwigValueWrapper<__gnu_cxx::__normal_iteratorstd::vector > > >&)'
result = (
On 04/02/16 13:36 +0100, Sandro Mani wrote:
Hi
Med builds are failing with
medfile_int_wrap.cc:11272:30: error: no matching function for call to 'std::vector >::erase(SwigValueWrapper<__gnu_cxx::__normal_iterator > > >&)'
result = (arg1)->erase(arg2);
A standalone version which fails to com
On 04.02.2016 13:40, Jakub Jelinek wrote:
On Thu, Feb 04, 2016 at 01:36:50PM +0100, Sandro Mani wrote:
Med builds are failing with
medfile_int_wrap.cc:11272:30: error: no matching function for call to 'std::vector >::erase(SwigValueWrapper<__gnu_cxx::__normal_iterator > > >&)'
result = (a
On Thu, Feb 04, 2016 at 01:36:50PM +0100, Sandro Mani wrote:
> Med builds are failing with
>
> medfile_int_wrap.cc:11272:30: error: no matching function for call to
> 'std::vector
> >::erase(SwigValueWrapper<__gnu_cxx::__normal_iterator std::vector > > >&)'
>result = (arg1)->erase(arg2);
>
Hi
Med builds are failing with
medfile_int_wrap.cc:11272:30: error: no matching function for call to 'std::vector >::erase(SwigValueWrapper<__gnu_cxx::__normal_iterator > > >&)'
result = (arg1)->erase(arg2);
A standalone version which fails to compile (ignoring the fact that arg2 is not
in
On Thu, 4 Feb 2016 10:53:11 +0100, David Tardon wrote:
> On Wed, Feb 03, 2016 at 11:27:30PM +0100, Kevin Kofler wrote:
> > Yaakov Selkowitz wrote:
> > > This is the hazard of using %{_libdir}/*.so.* in %files. Is there any
> > > reason why such a syntax should NOT be formally discouraged in the
On 2/4/2016 4:48 AM, Michael Schwendt wrote:
On Wed, 3 Feb 2016 19:35:41 -0700, Kevin Fenzi wrote:
But thats not how I look at it least. Instead of being one package who
says "My packages are great", you can say "My packages are great, and
other people help me when they can, and I help them o
On Thu, Feb 04, 2016 at 11:46:34AM +0100, Michael Schwendt wrote:
> > Rawhide is broken too often too easily, leading to too few
> > contributors/developers running it, leading to more problems.
> Is the Fedora Project still not doing anything to change that?
Well, see previous messages in this th
On Wed, 3 Feb 2016 19:35:41 -0700, Kevin Fenzi wrote:
> But thats not how I look at it least. Instead of being one package who
> says "My packages are great", you can say "My packages are great, and
> other people help me when they can, and I help them out and our
> community is great". It's not t
On Thu, 4 Feb 2016 04:21:59 -0500, Matthew Miller wrote:
> Rawhide is broken too often too easily, leading to too few
> contributors/developers running it, leading to more problems.
Is the Fedora Project still not doing anything to change that?
As long as some developers continue using Rawhide a
Hi,
On Tue, Feb 02, 2016 at 05:10:43AM -0500, Matthew Miller wrote:
> Ideally, every
> line in a package definition (specfile or what have you) is only there
> because of some exception from the typical case. For well-behaved
> upstreams, the perfect packaging description would be _empty_. With al
On 02/03/2016 11:28 PM, Felix Miata wrote:
Problem #2:
A way to work around problem #1 is with wildcards, e.g.
# dnf update g* i*, kd*, kf*, q*, per*, pyt*, u*, v*, x* y*, z*
When this example is used following observance of problem #1, DNF naturally
skips downloading packages already
2016-02-03 17:04 GMT+01:00 Jonathan Wakely :
> On 03/02/16 08:44 -0700, Jerry James wrote:
>
>> 1. Demotivating packagers
>>
>> I know a number of companies have experimented with "ownership-free"
>> models of code development, but they are able to offer incentives that
>> Fedora cannot offer, such
On Wed, Feb 03, 2016 at 11:27:30PM +0100, Kevin Kofler wrote:
> Yaakov Selkowitz wrote:
> > This is the hazard of using %{_libdir}/*.so.* in %files. Is there any
> > reason why such a syntax should NOT be formally discouraged in the
> > packaging guidelines?
>
> There is: I do not want to have to
On Thu, Feb 04, 2016 at 10:04:39AM +0100, Ralf Corsepius wrote:
> >Why bureaucracy?
>
> Because this cannot work without coordination in a multi-admin world
> => Fedora is not a Cathedral, so bureaucracy is inevitably required.
I don't think this follows. I mean, let's just look at the _metaphor_
On 02/04/2016 09:44 AM, Matthew Miller wrote:
On Wed, Feb 03, 2016 at 07:09:53PM +0100, Ralf Corsepius wrote:
Right. Tooling should stop that too. And I'm not just talking
_completely_ in hand-wavy theory. This is Dennis Gilmore's plan, where
any package build which breaks other packages (or pos
On 3.2.2016 16:34, Zbigniew Jędrzejewski-Szmek wrote:
> Hi,
>
> On Wed, Jan 27, 2016 at 11:57:37PM +0100, Jan Pokorný wrote:
>> attempt on settle this one down: http://tools.ietf.org/html/rfc6761
>
> rfc6761 is a useful reference, but it doesn't really solve this
> discussion one way or another.
On Wed, Feb 03, 2016 at 07:09:53PM +0100, Ralf Corsepius wrote:
> >>Right. Tooling should stop that too. And I'm not just talking
> >>_completely_ in hand-wavy theory. This is Dennis Gilmore's plan, where
> >>any package build which breaks other packages (or possibly other
> >>integration testing)
On Wed, Feb 03, 2016 at 09:08:04AM -0700, Jerry James wrote:
> > Right. Tooling should stop that too. And I'm not just talking
> > _completely_ in hand-wavy theory. This is Dennis Gilmore's plan, where
> > any package build which breaks other packages (or possibly other
> > integration testing) get
= Proposed Self Contained Change: Shenandoah 1.0 =
https://fedoraproject.org/wiki/Changes/Shenandoah
Change owner(s):
* Christine H. Flood
* Roman Kennke
This change aims at adding a very low pause time Garbage
Collection(GC) algorithm named Shenandoah to OpenJDK.
== Detailed Description ==
We
53 matches
Mail list logo
