Hi,
It seems some recent changes (rawhide) result in tons of files in
/usr/lib/.build-id which are obviously not needed, and as non-unique
create conflicts
ex: https://kojipkgs.fedoraproject.org/work/tasks/1239/18391239/root.log
Remi
___
devel mailing
On Tue, Mar 14, 2017 at 11:38:51PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Mar 14, 2017 at 08:29:00PM +, Daniel P. Berrange wrote:
> > On Tue, Mar 14, 2017 at 08:09:00PM +, Richard W.M. Jones wrote:
> > > Re: https://bugzilla.redhat.com/show_bug.cgi?id=1431876
> > >
> > > Curre
=> https://bugzilla.redhat.com/1432372
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
f17c61052975ecc188c285ee93dbb07926c880a28e49afdd5af0c7c997e8b12be72412d0964391f1232f853935ee0ff2838cd5d62f8f3b4f52c341904069ccea
XML-LibXML-2.0129.tar.gz
https://src.fedoraproject.org/lookaside/pkgs/perl-XML-LibXML/XML-LibXML-2.0129.tar.gz/sha512/f17c61052975ecc188c285ee93dbb07926c880a28
On Tue, Mar 14, 2017 at 05:35:54PM -0400, Daniel J Walsh wrote:
>
>
> On 03/14/2017 05:18 PM, Dusty Mabe wrote:
> >
> > On 03/14/2017 05:15 PM, Daniel J Walsh wrote:
> >>
> >> On 03/14/2017 05:02 PM, Dusty Mabe wrote:
> >>> On 03/14/2017 04:56 PM, Daniel J Walsh wrote:
> On 03/14/2017 04:29
On Tue, 14 Mar 2017 19:04:22 -0400, Randy Barlow wrote:
> What do you find misleading about the review?
It has discussed headers that are not installed anywhere. I expected
to find a spec file that either deletes headers from the buildroot or
includes them in a non-devel package to begin with. In
On Wed, 2017-03-15 at 10:12 +0100, Remi Collet wrote:
> Hi,
>
> It seems some recent changes (rawhide) result in tons of files in
> /usr/lib/.build-id which are obviously not needed, and as non-unique
> create conflicts
>
> ex: https://kojipkgs.fedoraproject.org/work/tasks/1239/18391239/root.log
https://bugzilla.redhat.com/show_bug.cgi?id=1432280
Jitka Plesnikova changed:
What|Removed |Added
Status|ASSIGNED|MODIFIED
Fixed In Version|
On Wed, Mar 15, 2017 at 4:59 AM, Jerry James wrote:
> On Tue, Mar 14, 2017 at 5:27 AM, Peter Robinson wrote:
>> You can assign pocketsphinx and it's dep sphinxbase to me as I need
>> them for a project I'm investigating ATM.
>
> Packagedb is claiming that you are not in the packager group, from
On 03/15/2017 05:27 AM, Daniel P. Berrange wrote:
> On Tue, Mar 14, 2017 at 05:35:54PM -0400, Daniel J Walsh wrote:
>>
>> On 03/14/2017 05:18 PM, Dusty Mabe wrote:
>>> On 03/14/2017 05:15 PM, Daniel J Walsh wrote:
On 03/14/2017 05:02 PM, Dusty Mabe wrote:
> On 03/14/2017 04:56 PM, Daniel
Hi,
I'm upgrading some LV2 audio plugin system related packages in rawhide.
The packages are:
lv2
serd
sord
sratom
lilv
suil
I'm not using a build tag, so the entire work will last some days.
Any packages that depend on these should rebuild after this update
ends.
There are no soname bumps, so o
Dne 15.3.2017 v 04:14 Zbigniew Jędrzejewski-Szmek napsal(a):
> This conflict should be temporary, the patch to make the abrt
> handler non-exclusive should be trivial.)
Patches are welcome.
> 4. run a python script that throws an exception
>e.g. python3
> /usr/lib/python3.5/site-pack
Igor Gnatenko wrote:
> Why it got pushed to stable?
Because the maintainer enabled autokarma, which is always a mistake.
Updates should only ever be pushed after carefully considering the feedback
inside and outside Bodhi, including the actual text of the comments, which
the Bodhi software cann
- Original Message -
> There's a new tiny package which provides a python traceback logging in
> the journal for python processes. It's very similar to the existing
> handler provided by abrt, it also installs itself as sys.excepthook
> using a .pth file, but instead of communicating with
On 15 March 2017 at 00:05, Jonathan Wakely
wrote:
> If glibc-static was removed from Fedora and that change propagated to
> RHEL I know of companies that might stop being customers of Red Hat.
>
> Being unable to statically link their applications would be a
> showstopper for some, and would caus
On Wed, Mar 15, 2017 at 01:47:18PM +0100, Kevin Kofler wrote:
> Igor Gnatenko wrote:
> > Why it got pushed to stable?
>
> Because the maintainer enabled autokarma, which is always a mistake.
>
> Updates should only ever be pushed after carefully considering the feedback
> inside and outside Bodh
On Wed, Mar 15, 2017 at 01:39:48PM +0100, Miroslav Suchý wrote:
> Dne 15.3.2017 v 04:14 Zbigniew Jędrzejewski-Szmek napsal(a):
> > This conflict should be temporary, the patch to make the abrt
> > handler non-exclusive should be trivial.)
>
> Patches are welcome.
It's on my todo list ;)
On 03/15/2017 02:51 PM, Tomasz Kłoczko wrote:
So you want to say that RH already guarantees Linux ABI compatibility below
glibc? I would be really surprised if it would be truth .. and I'm 100%
sure that exactly this part is not in RH support small prints. In other
words you may have only impress
On 14 March 2017 at 20:15, Richard W.M. Jones wrote:
> These are very useful for building embedded systems, initramfses,
> static linked binaries of large proprietary programs, and any case
> where you don't want to depend on the system libraries.
>
There are still none of the real embedded syst
On 03/15/2017 05:17 AM, Daniel P. Berrange wrote:
>
> Sure, if udev maintainers are willing to ship the kvm rule by default,
> that's fine with me for reason you suggest. I simply don't think it'll
> have any effect on usage of /dev/kvm inside containers
>
Does that mean you assume my scenario
On Wed, Mar 15, 2017 at 11:32:35AM -0400, Dusty Mabe wrote:
>
>
> On 03/15/2017 05:17 AM, Daniel P. Berrange wrote:
> >
> > Sure, if udev maintainers are willing to ship the kvm rule by default,
> > that's fine with me for reason you suggest. I simply don't think it'll
> > have any effect on usa
On 03/15/2017 11:49 AM, Daniel P. Berrange wrote:
> On Wed, Mar 15, 2017 at 11:32:35AM -0400, Dusty Mabe wrote:
>>
>> On 03/15/2017 05:17 AM, Daniel P. Berrange wrote:
>>> Sure, if udev maintainers are willing to ship the kvm rule by default,
>>> that's fine with me for reason you suggest. I simp
On 15 March 2017 at 14:16, Florian Weimer wrote:
[..]
> The main problem with static linking in Fedora is that we do not rebuild
> all static libraries once we update glibc-static. glibc only provides ABI
> compatibility for dynamic linking. The only saving grace is that we
> gradually cut back
On 03/14/2017 05:05 PM, Jonathan Wakely wrote:
> If glibc-static was removed from Fedora and that change propagated to
> RHEL I know of companies that might stop being customers of Red Hat.
Even if Fedora removed it, we could still make the business decision to
add it back to RHEL.
> Being unable
> Wiadomość napisana przez Josh Stone w dniu 15.03.2017, o
> godz. 17:56:
>
> This may still be a useful consideration for Fedora itself. Would we
> alienate anyone if Fedora removed glibc-static?
I think that this particular case should not be removed. Some tools do need
static linking (e.g
On Wed, Mar 15, 2017 at 09:56:50AM -0700, Josh Stone wrote:
> On 03/14/2017 05:05 PM, Jonathan Wakely wrote:
> > If glibc-static was removed from Fedora and that change propagated to
> > RHEL I know of companies that might stop being customers of Red Hat.
>
> Even if Fedora removed it, we could st
On 03/15/2017 05:45 PM, Tomasz Kłoczko wrote:
You are not even trying to answer on above question .. a bit sad because
you are simple ignoring some very good technical arguments.
Please read again what I wrote.
In a container (and multi-toolchain) world, static linking of glibc does
not add a
On 03/15/2017 01:05 AM, Jonathan Wakely wrote:
If glibc-static was removed from Fedora and that change propagated to
RHEL I know of companies that might stop being customers of Red Hat.
This is not the right list for discussing Red Hat Enterprise Linux
matters, but please be advised that the a
On 03/15/2017 10:08 AM, Daniel P. Berrange wrote:
> On Wed, Mar 15, 2017 at 09:56:50AM -0700, Josh Stone wrote:
>> On 03/14/2017 05:05 PM, Jonathan Wakely wrote:
>>> If glibc-static was removed from Fedora and that change propagated to
>>> RHEL I know of companies that might stop being customers of
Does anybody know why I'd have got this today?
The only recent change to Boost is to enabled the MPI packages on
ppc64le, but that shouldn't have affected all arches:
--- a/boost.spec
+++ b/boost.spec
@@ -7,11 +7,8 @@
%global boost_docdir __tmp_docdir
%global boost_examplesdir __tmp_examplesdir
On 15 March 2017 at 17:22, Florian Weimer wrote:
> Please read again what I wrote.
>
> In a container (and multi-toolchain) world, static linking of glibc does
> not add a significant support burden because we cannot use glibc as an
> abstraction layer for the kernel, unlike what other operating
On 15/03/17 13:51 +, Tomasz Kłoczko wrote:
On 15 March 2017 at 00:05, Jonathan Wakely
wrote:
If glibc-static was removed from Fedora and that change propagated to
RHEL I know of companies that might stop being customers of Red Hat.
Being unable to statically link their applications would
On 15/03/17 18:24 +0100, Florian Weimer wrote:
On 03/15/2017 01:05 AM, Jonathan Wakely wrote:
If glibc-static was removed from Fedora and that change propagated to
RHEL I know of companies that might stop being customers of Red Hat.
This is not the right list for discussing Red Hat Enterprise
On 15 March 2017 at 18:53, Jonathan Wakely
wrote:
> There are people who use the static libraries, for their own reasons,
> and don't expect support when they do so.
>
I can only repeat that such people should consider linking own binaries
against uClibc as this implementation is not affected by
On 03/14/2017 03:46 PM, Tomasz Kłoczko wrote:
This problem is wy bigger than you may be thinking. Above it is
only tip of the iceberg ..
# dnf list | grep -- -static | grep -c x86_64
196
This includes all available packages, but if you look at the actual
usage on an average system, i.e. o
Please turn off HTML in GMail.
On 03/15/2017 02:26 PM, Tomasz Kłoczko wrote:
I can only repeat that such people should consider linking own binaries against
uClibc as this implementation is not affected by issue with hidden loading NSS
DSOs which probably make such binaries useless on moving ar
Missing expected images:
Server dvd i386
Xfce raw-xz armhfp
Server boot i386
Failed openQA tests: 14/107 (x86_64), 1/2 (i386), 1/2 (arm)
New failures (same test did not fail in Rawhide-20170314.n.0):
ID: 65287 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fe
OK here is full list of spec files which have glibc-static in BuildRequires:
./g/gcc.git/gcc.spec:BuildRequires: glibc-static
./g/gdb.git/gdb.spec:BuildRequires: glibc-static%{bits_local}
./g/gdb.git/gdb.spec:# multilib glibc-static is open Bug 488472:
./g/gdb.git/gdb.spec:#BuildRequires: glibc-st
Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2017-03-16 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.
Local time information (via. rktime):
2017-03-16 09:00 Thu US/Pacific PDT
2017-03-16 12:00 Thu US/Eastern EDT
2017-03-16 1
On Wed, Mar 15, 2017 at 9:51 AM, Tomasz Kłoczko
wrote:
>
> On 15 March 2017 at 00:05, Jonathan Wakely
> wrote:
>>
>> If glibc-static was removed from Fedora and that change propagated to
>> RHEL I know of companies that might stop being customers of Red Hat.
>>
>> Being unable to statically link
Dear all,
You are kindly invited to the meeting:
Fedora 26 Alpha Go/No-Go Meeting on 2017-03-16 from 17:00:00 to 19:00:00 UTC
At fedora-meetin...@irc.freenode.net
The meeting will be about:
Before each public release Development, QA and Release Engineering meet to
determine if the release
Le 15/03/2017 à 10:24, Remi Collet a écrit :
> => https://bugzilla.redhat.com/1432372
It seems this report is only raised during PHP build (but other package
can be affected).
The issue is now fixed
- in php (dropping some old unneeded %attr)
- in rpm
Everything works now as expected (Koschei ha
42 matches
Mail list logo
