[LLVM] CommandLine Error: Option 'track-memory' registered more than once!

Hi guys, I see this error when building POCL or Beignet which looks like a bug in clang or llvm, can you please investigate? : CommandLine Error: Option ': CommandLine Error: Option 'track-memory' registered more than once! track-memory' registered more than once! LLVM ERROR: inconsistency in regi

Re: GPG2 as default /usr/bin/gpg

On St, 2016-02-17 at 05:52 +, Christopher wrote: > I just ran into this: https://bugzilla.redhat.com/show_bug.cgi?id=130 > 9175 > It's not a huge deal (and there are several workarounds, for git and > for > other tools which default ot using 'gpg'), but it highlights the > mismatch > between th

rawhide report: 20160217 changes

Compose started at Wed Feb 17 05:15:04 UTC 2016 Broken deps for i386 -- [3Depict] 3Depict-0.0.18-3.fc24.i686 requires libmgl.so.7.4.0 [IQmol] IQmol-2.3.0-9.fc24.i686 requires libboost_serialization.so.1.58.0 IQmol-2.3.0

Re: [ANNOUNCE] Fedora support for Vulkan

> On Tue, 2016-02-16 at 11:34 -0800, Andrew Lutomirski wrote: > > > DRI3 is a prerequisite, yes. The F23 builds of the intel driver had it > disabled until fairly recently, but this update should sort you out: > > https://bodhi.fedoraproject.org/updates/FEDORA-2016-606ca05253 This is great, not

Re: [ANNOUNCE] Fedora support for Vulkan

Anyone know if/when nvidia drivers will be included? On Wed, Feb 17, 2016 at 7:24 AM Peter T. wrote: > > On Tue, 2016-02-16 at 11:34 -0800, Andrew Lutomirski wrote: > > > > > > DRI3 is a prerequisite, yes. The F23 builds of the intel driver had it > > disabled until fairly recently, but this upda

Re: [ANNOUNCE] Fedora support for Vulkan

Peter T. wrote: >> On Tue, 2016-02-16 at 11:34 -0800, Andrew Lutomirski wrote: >> >> >> DRI3 is a prerequisite, yes. The F23 builds of the intel driver had it >> disabled until fairly recently, but this update should sort you out: >> >> https://bodhi.fedoraproject.org/updates/FEDORA-2016-606ca0

ship Fedora with /etc/{subuid|subgid}

Hello everyone, TL;DR; a fresh Fedora installation won't have /etc/subuid and /etc/subgid Docker user namespace implementation require those files to be present - otherwise it fails Docker user ns relies on two files /etc/{subuid,subgid} to be on the rootfs in order to gather information about

orphaning dx (OpenDX)

Hello, I'm orphaning the dx and dx-samples in rawhide. It is FTBFS in rawhide due to stricter checks in gcc-6, the upstream is dead (or actually it was never there, ever since IBM released the code), and the code itself is ancient (1999). I don't use it and I don't know anyone who does, so it's no

Re: orphaning dx (OpenDX)

On Wed, Feb 17, 2016 at 7:54 AM, Dominik 'Rathann' Mierzejewski < domi...@greysector.net> wrote: > Hello, > I'm orphaning the dx and dx-samples in rawhide. > > It is FTBFS in rawhide due to stricter checks in gcc-6, the upstream > is dead (or actually it was never there, ever since IBM released th

Re: orphaning dx (OpenDX)

On Wednesday, 17 February 2016 at 15:00, Richard Shaw wrote: > On Wed, Feb 17, 2016 at 7:54 AM, Dominik 'Rathann' Mierzejewski < > domi...@greysector.net> wrote: > > > Hello, > > I'm orphaning the dx and dx-samples in rawhide. > > > > It is FTBFS in rawhide due to stricter checks in gcc-6, the ups

Intent to retire cvc3

The cvc3 package was superceded by cvc4 quite awhile ago, but I have kept it around because the why package was using it. Now the why package has other alternatives, such as z3, so I intend to finally retire cvc3, in F-24+ only. I will do so in about a week unless someone has a reason to keep it

pghmcfc pushed to perl-Path-Class (master). "Update to 0.36 (..more)"

From ac883dd8ae5a1ce5e1bf4c09e732e1b916681993 Mon Sep 17 00:00:00 2001 From: Paul Howarth Date: Wed, 17 Feb 2016 15:16:22 + Subject: Update to 0.36 - New upstream release 0.36: - Use croak instead of die; use eval syntax instead of universal::isa (as perlcritic wishes) - Load File::Co

Re: [ANNOUNCE] Fedora support for Vulkan

On Wed, Feb 17, 2016 at 08:43:09AM -0500, Neal Becker wrote: > Peter T. wrote: > > >> On Tue, 2016-02-16 at 11:34 -0800, Andrew Lutomirski wrote: > >> > >> > >> DRI3 is a prerequisite, yes. The F23 builds of the intel driver had it > >> disabled until fairly recently, but this update should sort

Re: orphaning dx (OpenDX)

On 02/17/2016 03:09 PM, Dominik 'Rathann' Mierzejewski wrote: On Wednesday, 17 February 2016 at 15:00, Richard Shaw wrote: On Wed, Feb 17, 2016 at 7:54 AM, Dominik 'Rathann' Mierzejewski < domi...@greysector.net> wrote: Hello, I'm orphaning the dx and dx-samples in rawhide. It is FTBFS in raw

Re: GPG2 as default /usr/bin/gpg

On Wed, 17 Feb 2016 10:29:29 +0100 Tomas Mraz wrote: > On St, 2016-02-17 at 05:52 +, Christopher wrote: > > I just ran into this: > > https://bugzilla.redhat.com/show_bug.cgi?id=130 9175 > > It's not a huge deal (and there are several workarounds, for git and > > for > > other tools which def

Re: GPG2 as default /usr/bin/gpg

On Wed, Feb 17, 2016 at 05:52:45AM +, Christopher wrote: > I just ran into this: https://bugzilla.redhat.com/show_bug.cgi?id=1309175 > It's not a huge deal (and there are several workarounds, for git and for > other tools which default ot using 'gpg'), but it highlights the mismatch > between t

[Bug 1308365] slic3r crashes when loading known good stl files

https://bugzilla.redhat.com/show_bug.cgi?id=1308365 --- Comment #3 from Miro Hrončok --- For the reference: https://github.com/alexrj/Slic3r/issues/3238 -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extr

Re: GPG2 as default /usr/bin/gpg

Unless there are any issues with gpg, and to my knowledge there aren't, I can't see any important reason to default 'gpg' to 'gpg2', at least not for f24. I will say that if this is done, we need to be able to use the normal alternatives system (update-alternatives) to change what's used, withou

Re: GPG2 as default /usr/bin/gpg

On St, 2016-02-17 at 07:29 -0800, Brian C. Lane wrote: > On Wed, Feb 17, 2016 at 05:52:45AM +, Christopher wrote: > > I just ran into this: https://bugzilla.redhat.com/show_bug.cgi?id=1 > > 309175 > > It's not a huge deal (and there are several workarounds, for git > > and for > > other tools w

Re: GPG2 as default /usr/bin/gpg

On Wed, Feb 17, 2016 at 04:51:48PM +0100, Tomas Mraz wrote: > On St, 2016-02-17 at 07:29 -0800, Brian C. Lane wrote: > > On Wed, Feb 17, 2016 at 05:52:45AM +, Christopher wrote: > > > I just ran into this: https://bugzilla.redhat.com/show_bug.cgi?id=1 > > > 309175 > > > It's not a huge deal (an

Re: GPG2 as default /usr/bin/gpg

On 17 February 2016 at 15:51, Tomas Mraz wrote: > The problem is that now the keystores are incompatible and it creates > big confusion to the users when they see some key in gnupg-1 and do not > see it in gnupg-2 and the other way around. If it helps, I lost about 2 hours the other day trying to

Re: GPG2 as default /usr/bin/gpg

On February 17, 2016 6:04:04 PM GMT+02:00, Richard Hughes wrote: >On 17 February 2016 at 15:51, Tomas Mraz wrote: >> The problem is that now the keystores are incompatible and it creates >> big confusion to the users when they see some key in gnupg-1 and do >not >> see it in gnupg-2 and the ot

Re: GPG2 as default /usr/bin/gpg

On Wed, 17 Feb 2016 07:29:26 -0800 "Brian C. Lane" wrote: > I am opposed to this. If a tool wants/needs to > use v2 it should be using gpg2 not gpg. gpg v1.4.x is still active > upstream and is shipped as gpg so we shouldn't be renaming it. Is there any sense upstream how much longer 1.x will be

Re: GPG2 as default /usr/bin/gpg

El mié, 17-02-2016 a las 16:04 +, Richard Hughes escribió: > If it helps, I lost about 2 hours the other day trying to work out > why > my keys were not visible when imported using gpgme. I'd be 100% > behind > the change to switch to gpg2 if it saves just one other person 2 > hours > of confus

Re: orphaning dx (OpenDX)

On 02/17/2016 02:54 PM, Dominik 'Rathann' Mierzejewski wrote: Hello, I'm orphaning the dx and dx-samples in rawhide. It is FTBFS in rawhide due to stricter checks in gcc-6, the upstream is dead (or actually it was never there, ever since IBM released the code), and the code itself is ancient (19

[Bug 1305212] perl-OpenOffice-UNO: FTBFS in rawhide

https://bugzilla.redhat.com/show_bug.cgi?id=1305212 --- Comment #4 from Upstream Release Monitoring --- ppisar's perl-OpenOffice-UNO-0.07-19.fc24 completed http://koji.fedoraproject.org/koji/buildinfo?buildID=715412 -- You are receiving this mail because: You are on the CC list for the bug.

[Bug 1106166] perl-OpenOffice-UNO: FTBFS in rawhide: tests fail randomly

https://bugzilla.redhat.com/show_bug.cgi?id=1106166 --- Comment #5 from Upstream Release Monitoring --- ppisar's perl-OpenOffice-UNO-0.07-19.fc24 completed http://koji.fedoraproject.org/koji/buildinfo?buildID=715412 -- You are receiving this mail because: You are on the CC list for the bug.

GCC 6 -Wnonnull is too aggressive

Hello, I'm facing problems with new behavior in GCC 6. Let's assume we have trivial program like this: $ cat assert.c #include #include __attribute__((nonnull)) int f(char *txt) { assert(txt != NULL); return 0; } int main(int argc, char **argv) { return 0; } And

Re: GCC 6 -Wnonnull is too aggressive

On 17 February 2016 at 16:43, Petr Spacek wrote: > I'm all ears to hear what is the best solution/workaround for this. Tell upstream that -Werror is an antisocial thing to do. Richard -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedor

Re: ship Fedora with /etc/{subuid|subgid}

- Messaggio originale - | Da: "Antonio Murdaca" | A: devel@lists.fedoraproject.org | Cc: "Daniel J Walsh" , "Nalin Dahyabhai" | Inviato: Mercoledì, 17 febbraio 2016 14:44:34 | Oggetto: ship Fedora with /etc/{subuid|subgid} | | Hello everyone, | | TL;DR; | a fresh Fedora installation w

Re: GCC 6 -Wnonnull is too aggressive

On Wed, Feb 17, 2016 at 05:43:51PM +0100, Petr Spacek wrote: > __attribute__((nonnull)) is tremendously useful for static code analysis and > helped to uncover a lot of (not-yet triggered) issues in the code, so just > removing the attribute would not make me happy. Sure. > On the other hand, ass

eseyman pushed to perl-MooseX-Types-VariantTable (master). "Modernize spec file"

From 3f7245d9ecb9c720f2232dd815bb6437ebe88d53 Mon Sep 17 00:00:00 2001 From: Emmanuel Seyman Date: Wed, 17 Feb 2016 17:52:56 +0100 Subject: Modernize spec file --- perl-MooseX-Types-VariantTable.spec | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/perl-

Re: GPG2 as default /usr/bin/gpg

On Wed, Feb 17, 2016 at 09:29:10AM -0700, Kevin Fenzi wrote: > On Wed, 17 Feb 2016 07:29:26 -0800 > "Brian C. Lane" wrote: > > > I am opposed to this. If a tool wants/needs to > > use v2 it should be using gpg2 not gpg. gpg v1.4.x is still active > > upstream and is shipped as gpg so we shouldn't

Re: GCC 6 -Wnonnull is too aggressive

El mié, 17-02-2016 a las 17:53 +0100, Jakub Jelinek escribió: > That is wrong.  Even older gcc versions would just optimize away the > assertion. Even in -O0 builds? We've been hesitantly removing ASSERT(this) statements from WebKit to avoid compiler warnings from clang. Our asserts are enabled o

Re: GCC 6 -Wnonnull is too aggressive

On Wed, Feb 17, 2016 at 11:14:29AM -0600, Michael Catanzaro wrote: > El mié, 17-02-2016 a las 17:53 +0100, Jakub Jelinek escribió: > > That is wrong.  Even older gcc versions would just optimize away the > > assertion. > > Even in -O0 builds? Probably not, though the warning will be at -O0 too.

Re: GCC 6 -Wnonnull is too aggressive

On 02/17/2016 05:43 PM, Petr Spacek wrote: Hello, And because upstream is paranoid, it is being compiled with: $ gcc -Werror -Wall Did anyone met similar problem? What did you do with it? Remove -Werror. __attribute__((nonnull)) is tremendously useful for static code analysis and helped

Re: GCC 6 -Wnonnull is too aggressive

On Wed, Feb 17, 2016 at 05:43:51PM +0100, Petr Spacek wrote: > Hello, > > I'm facing problems with new behavior in GCC 6. > > Let's assume we have trivial program like this: > > $ cat assert.c > #include > #include > > __attribute__((nonnull)) > int f(char *txt) { > assert(txt != NUL

deprecating nepomuk in f24+

kde-sig has tentative plans to remove support for kde4 nepomuk (starting with f24). What that means is soon kdelibs will be built without libnepomuk (and friends), and packages: nepomuk-core nepomuk-widgets will be eol'd. Packages affected by this include: nepomuk(kdelibs) bangarang c

Re: GPG2 as default /usr/bin/gpg

On St, 2016-02-17 at 08:10 -0800, Brian C. Lane wrote: > On Wed, Feb 17, 2016 at 04:51:48PM +0100, Tomas Mraz wrote: > > On St, 2016-02-17 at 07:29 -0800, Brian C. Lane wrote: > > > On Wed, Feb 17, 2016 at 05:52:45AM +, Christopher wrote: > > > > I just ran into this: https://bugzilla.redhat.co

Re: GCC 6 -Wnonnull is too aggressive

On Wed, Feb 17, 2016 at 05:30:27PM +, Daniel P. Berrange wrote: > Instead of using __attribute__((nonnull)) directly in the code, define a > macro for it. When compiling normal builds with gcc, make the macro > expand to nothing, but when compiling with coverity or other static analysis > tools

Re: GCC 6 -Wnonnull is too aggressive

On Wed, 17 Feb 2016 18:25:29 +0100, Ralf Corsepius wrote: > Remove -Werror. [...] > -Werror is useful to devs when actively working on code, but using it in > released production code to be used in packages is plain st***. -Werror has found me many times bugs in Fedora add-on patches not being up

Re: GCC6: failure with -isystem /usr/include

Orcan Ogetbil wrote: > On 16 February 2016 at 13:08, Rex Dieter wrote: >> So, 2 options (not mutually exclusive): >> >> * fix configure to not add /usr/include to ac_incpath >> * fix src/src.pri.in to comment-out (or remove) the line starting with >> INCLUDEPATH += (I don't think it's needed) >> >

Re: libguestfs's builds started to fail in f24

On Wed, Feb 17, 2016 at 05:53:51PM +, notificati...@fedoraproject.org wrote: > libguestfs's builds started to fail in f24 > https://apps.fedoraproject.org/koschei/package/libguestfs The failed task is apparently: http://koji.fedoraproject.org/koji/taskinfo?taskID=13024768 The build.log

Re: GCC 6 -Wnonnull is too aggressive

On 02/17/2016 06:51 PM, Jan Kratochvil wrote: On Wed, 17 Feb 2016 18:25:29 +0100, Ralf Corsepius wrote: Remove -Werror. [...] -Werror is useful to devs when actively working on code, but using it in released production code to be used in packages is plain st***. -Werror has found me many tim

Re: GPG2 as default /usr/bin/gpg

On Wed, Feb 17, 2016 at 1:18 PM Brian C. Lane wrote: > On Wed, Feb 17, 2016 at 09:29:10AM -0700, Kevin Fenzi wrote: > > On Wed, 17 Feb 2016 07:29:26 -0800 > > "Brian C. Lane" wrote: > > > > > I am opposed to this. If a tool wants/needs to > > > use v2 it should be using gpg2 not gpg. gpg v1.4.x

Fedora Rawhide 20160217 compose check report

Missing expected images: Kde disk raw armhfp Kde live i386 Kde live x86_64 Images in this compose but not Rawhide 20160216: Design_suite live x86_64 Robotics live i386 Workstation live x86_64 Robotics live x86_64 Workstation live i386 Minimal disk raw armhfp Cinnamon live i386 Mate live i386 Wor

Re: GPG2 as default /usr/bin/gpg

On Wed, Feb 17, 2016 at 1:09 PM John M. Harris, Jr. wrote: > Unless there are any issues with gpg, and to my knowledge there aren't, I > can't see any important reason to default 'gpg' to 'gpg2', at least not for > f24. > > The biggest reason I can think is to make things consistent with the out-

Re: ship Fedora with /etc/{subuid|subgid}

Strange package to include those. This also looks like an interesting package. http://manpages.ubuntu.com/manpages/vivid/man1/newuidmap.1.html On 02/17/2016 11:45 AM, Antonio Murdaca wrote: > > - Messaggio originale - > | Da: "Antonio Murdaca" > | A: devel@lists.fedoraproject.org > | Cc

Re: GPG2 as default /usr/bin/gpg

On Wed, Feb 17, 2016 at 06:41:51PM +0100, Tomas Mraz wrote: > On St, 2016-02-17 at 08:10 -0800, Brian C. Lane wrote: > > > > I'm not sure what you're asking here. We have 2 different binaries > > already. I don't see any reason to add more or rename the existing > > ones. > > I meant renaming the

Re: ship Fedora with /etc/{subuid|subgid}

On Wed, Feb 17, 2016 at 01:31:41PM -0500, Daniel J Walsh wrote: > Strange package to include those. > > This also looks like an interesting package. > > http://manpages.ubuntu.com/manpages/vivid/man1/newuidmap.1.html Fedora packages the same source package and calls the result shadow-utils. Che

Re: ship Fedora with /etc/{subuid|subgid}

- Messaggio originale - | Da: "Nalin Dahyabhai" | A: devel@lists.fedoraproject.org | Inviato: Mercoledì, 17 febbraio 2016 19:52:55 | Oggetto: Re: ship Fedora with /etc/{subuid|subgid} | | On Wed, Feb 17, 2016 at 01:31:41PM -0500, Daniel J Walsh wrote: | > Strange package to include thos

Re: ship Fedora with /etc/{subuid|subgid}

- Messaggio originale - | Da: "Antonio Murdaca" | A: "Development discussions related to Fedora" | Inviato: Mercoledì, 17 febbraio 2016 19:56:04 | Oggetto: Re: ship Fedora with /etc/{subuid|subgid} | | | | - Messaggio originale - | | Da: "Nalin Dahyabhai" | | A: devel@lists.

Re: GPG2 as default /usr/bin/gpg

On Wed, Feb 17, 2016 at 4:51 PM, Tomas Mraz wrote: > On St, 2016-02-17 at 07:29 -0800, Brian C. Lane wrote: >> On Wed, Feb 17, 2016 at 05:52:45AM +, Christopher wrote: >> > I just ran into this: https://bugzilla.redhat.com/show_bug.cgi?id=1 >> > 309175 >> > It's not a huge deal (and there are

Re: [ANNOUNCE] Fedora support for Vulkan

On Wed, Feb 17, 2016 at 1:24 PM, Peter T. wrote: >> On Tue, 2016-02-16 at 11:34 -0800, Andrew Lutomirski wrote: >> >> >> DRI3 is a prerequisite, yes. The F23 builds of the intel driver had it >> disabled until fairly recently, but this update should sort you out: >> >> https://bodhi.fedoraproject.

Schedule for Thursday's FPC Meeting (2016-02-18 17:00 UTC)

Following is the list of topics that will be discussed in the FPC meeting Thursday at 2016-02-18 17:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. rktime): 2016-02-18 09:00 Thu US/Pacific PST 2016-02-18 12:00 Thu US/Eastern EST 2016-02-18 1

Re: [ANNOUNCE] Fedora support for Vulkan

drago01 wrote: > On Wed, Feb 17, 2016 at 1:24 PM, Peter T. wrote: >>> On Tue, 2016-02-16 at 11:34 -0800, Andrew Lutomirski wrote: >>> >>> >>> DRI3 is a prerequisite, yes. The F23 builds of the intel driver had it >>> disabled until fairly recently, but this update should sort you out: >>> >>> htt

Re: [ANNOUNCE] Fedora support for Vulkan

I read the readme in the Vulkan branch on the mesa git but how do you tell if your chipset is specifically supported? Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: [ANNOUNCE] Fedora support for Vulkan

- Original Message - > From: "Zach Villers" > To: "Development discussions related to Fedora" > > Sent: Wednesday, 17 February, 2016 11:34:47 PM > Subject: Re: [ANNOUNCE] Fedora support for Vulkan > > Anyone know if/when nvidia drivers will be included? There are no open source vulka

Self Introduction: Hannes Frederic Sowa

Hello all, I am already a long time user of Fedora and enjoy every new release. For quite some time I pondered on finally contributing some bits and pieces back to the community. After last weeks meet-up with my team and especially Lubomir during devconf.cz, I finally decided to start this.

Saxon-HE: new package or update?

Background information: Upstream of package saxon (http://saxon.sourceforge.net/) has changed the Open source branch to Saxon-HE, as well as the maven artifact since version 9.4. I would like to update the Saxon version, that will also change the maven artifactId from saxon to Saxon-HE. As far a

Re: Saxon-HE: new package or update?

Il 18/02/2016 02:36, Ding Yi Chen ha scritto: Background information: Upstream of package saxon (http://saxon.sourceforge.net/) has changed the Open source branch to Saxon-HE, as well as the maven artifact since version 9.4. I would like to update the Saxon version, that will also change the m

Re: Self Introduction: Hannes Frederic Sowa

On Wed, Feb 17, 2016 at 10:40:38PM +0100, Hannes Frederic Sowa wrote: > submit a package for iovisor-bcc - > - which provides tooling around the new eBPF infrastructure in the > kernel. This might eventually need some fixes upstream first so the > build process is s

Re: Saxon-HE: new package or update?

- Original Message - > > > Il 18/02/2016 02:36, Ding Yi Chen ha scritto: > > Background information: > > Upstream of package saxon (http://saxon.sourceforge.net/) has changed the > > Open source branch to Saxon-HE, as well as the maven artifact since version > > 9.4. > > > > I would lik

Re: Self Introduction: Hannes Frederic Sowa

Hello Hannes, > On Thursday, 18 February 2016 3:11 AM, Hannes Frederic Sowa wrote: > back to the community. After last weeks meet-up with my team and > especially Lubomir during devconf.cz, I finally decided to start this. ... > At first, I will try my luck with a probably more simple package, GNU

Re: [LLVM] CommandLine Error: Option 'track-memory' registered more than once!

On 02/17/2016 03:24 AM, Igor Gnatenko wrote: > Hi guys, I see this error when building POCL or Beignet which looks > like a bug in clang or llvm, can you please investigate? > > : CommandLine Error: Option ': CommandLine Error: Option > 'track-memory' registered more than once! > track-memory' reg

dnf --refresh upgrade vs. CVE-2015-7547 updates.

On 2016-02-16 16:41:27 the glibc rawhide build to fix CVE-2015-7547[1] completed: https://koji.fedoraproject.org/koji/buildinfo?buildID=736361 On 2016-02-17 the rawhide repodiff email showed the build: ~~~ glibc-2.22.90-36.fc24 - * Tue Feb 16 2016 CArlos O'Donell https://www

Re: dnf --refresh upgrade vs. CVE-2015-7547 updates.

On Thu, 2016-02-18 at 01:06 -0500, Carlos O'Donell wrote: > On 2016-02-16 16:41:27 the glibc rawhide build to fix CVE-2015-7547[1] > completed: > https://koji.fedoraproject.org/koji/buildinfo?buildID=736361 > > On 2016-02-17 the rawhide repodiff email showed the build: > ~~~ > glibc-2.22.90-36.fc

Re: Saxon-HE: new package or update?

On 02/18/2016 02:36 AM, Ding Yi Chen wrote: > Background information: > Upstream of package saxon (http://saxon.sourceforge.net/) has changed the > Open source branch to Saxon-HE, as well as the maven artifact since version > 9.4. > > I would like to update the Saxon version, that will also chang