The description of Kevin is very precise. I am additionally thinking about
implementing
user option to rebuild all project packages for a new target when added. So
when f27 is added, user could click one button to launch rebuild of all his
packages
for this target.
Basically, this allows us to be
Hi,
Matthew Miller writes:
> Someone on Reddit noted that there's a zero-length file named `1` in /
> on their F25 system. I just looked on mine, and I have one too. It's
> not owned by any RPM. And I checked on an F24 box, and it's got that
> too. Anyone know where this is coming from?
I see i
On Thu, Oct 13, 2016 at 3:11 AM, Michal Novotny wrote:
> The description of Kevin is very precise. I am additionally thinking about
> implementing
> user option to rebuild all project packages for a new target when added. So
> when f27 is added, user could click one button to launch rebuild of all
Dne 13.10.2016 v 09:37 Neal Gompa napsal(a):
> On Thu, Oct 13, 2016 at 3:11 AM, Michal Novotny wrote:
>> The description of Kevin is very precise. I am additionally thinking about
>> implementing
>> user option to rebuild all project packages for a new target when added. So
>> when f27 is added,
- Original Message -
| From: "Adam Williamson"
| To: "Development discussions related to Fedora"
| Sent: Thursday, October 13, 2016 12:26:10 PM
| Subject: Re: PROPOSAL: Blocking the release is our only "big hammer" — let's
add a softer one.
|
| On Thu, 2016-10-13 at 14:40 +1000, Jeff
On Tue, Oct 11, 2016 at 08:29:59AM +0100, Richard W.M. Jones wrote:
> > Furthermore, stage4-disk.img.xz is a strange beast; it contains a
> > compiler but no include files and no 'as' command.
>
> Our rather hacked-up GCC is missing dependencies on glibc-headers &
> binutils. We're going to fix t
On 13/10/2016 4:56 PM, Adam Williamson wrote:
> On Thu, 2016-10-13 at 14:40 +1000, Jeff Fearn wrote:
>> On 13/10/16 14:02, Adam Williamson wrote:
>>> On Wed, 2016-10-12 at 21:09 -0400, Josh Boyer wrote:
On Wed, Oct 12, 2016 at 8:33 PM, Adam Williamson
wrote:
> On Wed, 2016-10-12 at 0
On Thu, Oct 13, 2016 at 12:02 AM, Adam Williamson
wrote:
> On Wed, 2016-10-12 at 21:09 -0400, Josh Boyer wrote:
>> On Wed, Oct 12, 2016 at 8:33 PM, Adam Williamson
>> wrote:
>> > On Wed, 2016-10-12 at 09:55 -0400, Josh Boyer wrote:
>> > > All of the extra app stuff could be avoided if we disallow
On 2016-10-12, Kaleb S. KEITHLEY wrote:
>
> Sure, but I just installed a rawhide box from
> Fedora-Server-netinst-x86_64-Rawhide-20161010.n.0.iso and it still has
> openssl-1.0.2j-1.fc26.x86_64 and a `dnf update openssl` is not giving me
> anything newer.
>
Because rawhide repositories are subj
On Thu, 13 Oct 2016 11:26:55 + (UTC)
Petr Pisar wrote:
> On 2016-10-12, Kaleb S. KEITHLEY wrote:
> >
> > Sure, but I just installed a rawhide box from
> > Fedora-Server-netinst-x86_64-Rawhide-20161010.n.0.iso and it still
> > has openssl-1.0.2j-1.fc26.x86_64 and a `dnf update openssl` is no
On Thu, Oct 13, 2016 at 1:22 PM, Josh Boyer wrote:
> On Thu, Oct 13, 2016 at 12:02 AM, Adam Williamson
> wrote:
>> On Wed, 2016-10-12 at 21:09 -0400, Josh Boyer wrote:
>>> On Wed, Oct 12, 2016 at 8:33 PM, Adam Williamson
>>> wrote:
>>> > On Wed, 2016-10-12 at 09:55 -0400, Josh Boyer wrote:
>>> >
libbson-1.5.0-0.1.rc2.fc26 removes soname aliases visiable on RPM level
as "libbson-1.0.so.0(LIBBSON_*)(64bit)" provides and keeps
"libbson-1.0.so.0()(64bit)" only.
The 1.5.0-rc2 will be pushed into rawhide only and I will rebuild the
three affected packages there:
mongo-c-driver-1.3.5-6.fc26.src
On 13/10/16 13:50, Petr Pisar wrote:
libbson-1.5.0-0.1.rc2.fc26 removes soname aliases visiable on RPM level
as "libbson-1.0.so.0(LIBBSON_*)(64bit)" provides and keeps
"libbson-1.0.so.0()(64bit)" only.
That's not an "soname alias" it's a symbol versioning provide.
So are you saying that this
On 13/10/16 14:05, Tom Hughes wrote:
On 13/10/16 13:50, Petr Pisar wrote:
libbson-1.5.0-0.1.rc2.fc26 removes soname aliases visiable on RPM level
as "libbson-1.0.so.0(LIBBSON_*)(64bit)" provides and keeps
"libbson-1.0.so.0()(64bit)" only.
That's not an "soname alias" it's a symbol versioning
The versions of config.sub and config.guess in redhat-rpm-config are
3+ years old. I'd like to update these to the very latest versions,
primarily because the upstream versions support riscv64.
Is there a reason not to do that? I don't want to break something
unexpectedly.
Rich.
--
Richard J
On 2016-10-13, Tom Hughes wrote:
> On 13/10/16 14:05, Tom Hughes wrote:
>> On 13/10/16 13:50, Petr Pisar wrote:
>>
>>> libbson-1.5.0-0.1.rc2.fc26 removes soname aliases visiable on RPM level
>>> as "libbson-1.0.so.0(LIBBSON_*)(64bit)" provides and keeps
>>> "libbson-1.0.so.0()(64bit)" only.
>>
>>
On Čt, 2016-10-13 at 14:32 +, Petr Pisar wrote:
> On 2016-10-13, Tom Hughes wrote:
> >
> >
> > In other words, does the soname need to change?
> >
> The soname did not change. But packages built against older library
> linked to versioned symbols. Thus they had to be rebuild.
>
> I'm not v
On 10/13/2016 04:57 PM, Richard W.M. Jones wrote:
The versions of config.sub and config.guess in redhat-rpm-config are
3+ years old. I'd like to update these to the very latest versions,
primarily because the upstream versions support riscv64.
Is there a reason not to do that? I don't want to
On Thursday, October 13, 2016 6:23:24 PM CEST Panu Matilainen wrote:
> On 10/13/2016 04:57 PM, Richard W.M. Jones wrote:
> >
> > The versions of config.sub and config.guess in redhat-rpm-config are
> > 3+ years old. I'd like to update these to the very latest versions,
> > primarily because the up
On Thu, Oct 13, 2016 at 06:23:24PM +0300, Panu Matilainen wrote:
> On 10/13/2016 04:57 PM, Richard W.M. Jones wrote:
> >
> >The versions of config.sub and config.guess in redhat-rpm-config are
> >3+ years old. I'd like to update these to the very latest versions,
> >primarily because the upstream
No missing expected images.
Failed openQA tests: 6/102 (x86_64), 3/17 (i386), 1/2 (arm)
ID: 40820 Test: x86_64 Workstation-live-iso
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/40820
ID: 40827 Test: i386 Workstation-boot-iso install_default
URL: https
Announcing the creation of a new nightly release validation test event
for Fedora 25 Branched 20161013.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
I could use some help figuring out the best fix for the following problem
where only the i686 builds fail:
cd /builddir/build/BUILD/oiio-Release-1.7.7/build/linux/src/libutil &&
/usr/bin/cmake -E cmake_link_script CMakeFiles/fmath_test.dir/link.txt
--verbose=1
/usr/bin/c++ -O2 -g -pipe -Wall -We
Missing expected images:
Workstation live i386
Workstation live x86_64
Failed openQA tests: 2/91 (x86_64), 1/16 (i386), 1/2 (arm)
ID: 40971 Test: arm Minimal-raw_xz-raw.xz
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/40971
ID: 41034 Test: x86_64 un
On 10/13/2016 12:04 PM, Richard Shaw wrote:
The following workaround was suggested by upstream and seemed to do the
trick but upstream doesn't want to perform needless initialization on
platforms/arches that don't require it.
Why would it be arch-dependent whether or not a variable needs to be
On Thu, 2016-10-13 at 19:33 +1000, Jeff Fearn wrote:
>
> > That's not the intent of the fields as I understand them. 'severity' is
> > supposed to represent how bad the bug is, whereas 'priority' is
> > supposed to represent how important it is to get it fixed compared to
> > other bugs in the sam
On 14/10/2016 11:07 AM, Adam Williamson wrote:
> On Thu, 2016-10-13 at 19:33 +1000, Jeff Fearn wrote:
>>> That's not the intent of the fields as I understand them. 'severity' is
>>> supposed to represent how bad the bug is, whereas 'priority' is
>>> supposed to represent how important it is to get
On Fri, 2016-10-14 at 11:26 +1000, Jeff Fearn wrote:
>
> Not that I think either of those fields are good for marking something
> as a blocker for the distribution, a blocker flag would be more useful
> for that IMO.
None of this is about the blocker process, we already have one of those
and it w
On Thu, Oct 13, 2016 at 6:15 PM, Samuel Sieb wrote:
> On 10/13/2016 12:04 PM, Richard Shaw wrote:
>
>> The following workaround was suggested by upstream and seemed to do the
>> trick but upstream doesn't want to perform needless initialization on
>> platforms/arches that don't require it.
>>
>>
On 10/14/2016 01:15 AM, Samuel Sieb wrote:
On 10/13/2016 12:04 PM, Richard Shaw wrote:
The following workaround was suggested by upstream and seemed to do the
trick but upstream doesn't want to perform needless initialization on
platforms/arches that don't require it.
Why would it be arch-depe
30 matches
Mail list logo
