unretire request - coot

[Tim Fenn]

I recently requested and had received approval of a re-review of a package
I'm unretiring:

https://bugzilla.redhat.com/show_bug.cgi?id=1359402

However, I don't have TICKET_CREATE privileges on rel-eng trac to make the
unretire request. How should I proceed?

Regards,
Tim
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 Self Contained Change: Replace Coolkey with OpenSC

[David Woodhouse]

On Thu, 2017-02-02 at 15:49 +0100, Jan Kurik wrote:
> = Proposed Self Contained Change: Replace Coolkey with OpenSC =
> https://fedoraproject.org/wiki/Changes/Replace_Coolkey_with_OpenSC
> 
> Change owner(s):
> * Jakub Jelen 
> 
> There are more PKCS#11 libraries supporting the same smart cards in
> the system. For the next releases, we would like to promote OpenSC as
> a default PKCS#11 provided in place where Coolkey driver is used these
> days, which will extend a list of supported smart cards and make use
> of the most of the OpenSC.
> 
> 
> == Detailed Description ==
> 
> Currently, there are several PKCS#11 modules available in Fedora. Some
> of them provide the same functionality as the others. Currently, the
> majority of the work around smart cards is done in the OpenSC project
> supporting all the major cards we are interested to have in Fedora. On
> the other side, there is no significant development efforts in Coolkey
> project, which is currently used by default in some applications
> (NSS).
> 
> The provided libraries are dynamically loaded PKCS#11 libraries, so
> existing applications should not depend directly on either package.
> The transition should be smooth as the change of the path in the
> configurations, if any. The only exceptions are NSS (Coolkey installs
> its module to the NSS database), ESC and pesign (explicit requires
> should be removed).
> 
> $ dnf repoquery --whatrequires coolkey
> esc-0:1.1.0-30.fc25.x86_64
> pesign-0:0.112-4.fc25.x86_64
> 
> We would like to:
> * Get rid of explicit requires (pesign, esc)
> * Switch the default PKCS#11 module in applications from Coolkey to
> OpenSC (NSS, ESC, pesign, ...?)
> * Retire the Coolkey package from Fedora (estimated in Fedora 27+)
> 
> During last months we worked with NSS to implement and test missing
> features in OpenSC to follow CoolKey driver and specification
> behavior.

Can we please *finally* get NSS fixed to use the p11-kit-configured
modules by default?

smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: HEADS UP: libwebp-0.6.0 soname bumps

[Kalev Lember]

On 02/02/2017 10:04 AM, Sandro Mani wrote:
> On 02.02.2017 08:49, Kalev Lember wrote:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1418572 is the review for
>> compat-libwebp05 package I put together just now.
>>
> I see the review is already taken care of. Happy to help maintaining if
> required.

Great, thanks. Added you as a co-maintainer.

It's now reviewed and built for rawhide, compat-libwebp05-0.5.2-1.fc26

-- 
Kalev
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F26 Self Contained Change: Replace Coolkey with OpenSC

[Jan Kurik]

= Proposed Self Contained Change: Replace Coolkey with OpenSC =
https://fedoraproject.org/wiki/Changes/Replace_Coolkey_with_OpenSC

Change owner(s):
* Jakub Jelen 

There are more PKCS#11 libraries supporting the same smart cards in
the system. For the next releases, we would like to promote OpenSC as
a default PKCS#11 provided in place where Coolkey driver is used these
days, which will extend a list of supported smart cards and make use
of the most of the OpenSC.


== Detailed Description ==

Currently, there are several PKCS#11 modules available in Fedora. Some
of them provide the same functionality as the others. Currently, the
majority of the work around smart cards is done in the OpenSC project
supporting all the major cards we are interested to have in Fedora. On
the other side, there is no significant development efforts in Coolkey
project, which is currently used by default in some applications
(NSS).

The provided libraries are dynamically loaded PKCS#11 libraries, so
existing applications should not depend directly on either package.
The transition should be smooth as the change of the path in the
configurations, if any. The only exceptions are NSS (Coolkey installs
its module to the NSS database), ESC and pesign (explicit requires
should be removed).

$ dnf repoquery --whatrequires coolkey
esc-0:1.1.0-30.fc25.x86_64
pesign-0:0.112-4.fc25.x86_64

We would like to:
* Get rid of explicit requires (pesign, esc)
* Switch the default PKCS#11 module in applications from Coolkey to
OpenSC (NSS, ESC, pesign, ...?)
* Retire the Coolkey package from Fedora (estimated in Fedora 27+)

During last months we worked with NSS to implement and test missing
features in OpenSC to follow CoolKey driver and specification
behavior.

== Scope ==
* Proposal owners:
-- For Fedora 26, we want to switch all applications to OpenSC and
leave Coolkey as a backup. We will unregister coolkey from NSS
database and register OpenSC instead.
-- For Fedora 27, we would like to retire coolkey package, if there
will not show up any problem with the transition in previous phase.

* Other developers:
The other packages using PKCS#11 should make sure they work with
OpenSC, if they were depending on coolkey directly for future releases
(will be communicated with affected package owners).

* Release engineering:
N/A
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

When PHP QA meets Fedora QA (Koschei)

[Remi Collet]

Hi,

I'm used to build PHP Release Candidate or stable version in rawhide, as
part of the PHP Project QA, usually shortly before their announcement.

So, as 7.1.2RC1 was tagged on Tuesday, I built it in Rawhide.

Koschei does its work, and allow us to discover some breakages (FTBFS
for Zend Framework, Atoum, Nette, Horde...)

So, we discover 2 regressions:

- in dom extension (also in upcoming 7.0.16)

- in the engine, in method prototype check

Thanks to Fedora QA, we were able to quickly fix these regressions
upstream (RM have reverted the bad change).

New version 7.1.2RC1 have been rebuild today in rawhide and everything
seems ok again.

This version will be officially announced as available soon today.


Just to enlight the great and useful collaboration between the 2 projects.

(this is not the 1st time this happen, but I'd like, for once, to give
it a bit more visibility)


Remi.


P.S. sorry to all php package maintainers in fedora for the Koschei
noise / spam.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F26 Self Contained Change: Replace Coolkey with OpenSC

[Jan Kurik]

= Proposed Self Contained Change: Replace Coolkey with OpenSC =
https://fedoraproject.org/wiki/Changes/Replace_Coolkey_with_OpenSC

Change owner(s):
* Jakub Jelen 

There are more PKCS#11 libraries supporting the same smart cards in
the system. For the next releases, we would like to promote OpenSC as
a default PKCS#11 provided in place where Coolkey driver is used these
days, which will extend a list of supported smart cards and make use
of the most of the OpenSC.


== Detailed Description ==

Currently, there are several PKCS#11 modules available in Fedora. Some
of them provide the same functionality as the others. Currently, the
majority of the work around smart cards is done in the OpenSC project
supporting all the major cards we are interested to have in Fedora. On
the other side, there is no significant development efforts in Coolkey
project, which is currently used by default in some applications
(NSS).

The provided libraries are dynamically loaded PKCS#11 libraries, so
existing applications should not depend directly on either package.
The transition should be smooth as the change of the path in the
configurations, if any. The only exceptions are NSS (Coolkey installs
its module to the NSS database), ESC and pesign (explicit requires
should be removed).

$ dnf repoquery --whatrequires coolkey
esc-0:1.1.0-30.fc25.x86_64
pesign-0:0.112-4.fc25.x86_64

We would like to:
* Get rid of explicit requires (pesign, esc)
* Switch the default PKCS#11 module in applications from Coolkey to
OpenSC (NSS, ESC, pesign, ...?)
* Retire the Coolkey package from Fedora (estimated in Fedora 27+)

During last months we worked with NSS to implement and test missing
features in OpenSC to follow CoolKey driver and specification
behavior.

== Scope ==
* Proposal owners:
-- For Fedora 26, we want to switch all applications to OpenSC and
leave Coolkey as a backup. We will unregister coolkey from NSS
database and register OpenSC instead.
-- For Fedora 27, we would like to retire coolkey package, if there
will not show up any problem with the transition in previous phase.

* Other developers:
The other packages using PKCS#11 should make sure they work with
OpenSC, if they were depending on coolkey directly for future releases
(will be communicated with affected package owners).

* Release engineering:
N/A
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: HEADS UP: libwebp-0.6.0 soname bumps

[Sandro Mani]

On 01.02.2017 23:58, Björn 'besser82' Esser wrote:


Hi Sandro,

could you please tell me, when gnuplot has been rebuilt successfully?


Gnuplot is now built.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Python Classroom Lab

[Stephen Gallagher]

On 02/02/2017 07:13 AM, Josh Boyer wrote:
> On Wed, Feb 1, 2017 at 10:40 AM, Stephen Gallagher  
> wrote:
>> On 02/01/2017 10:34 AM, Neal Gompa wrote:
>>> On Wed, Feb 1, 2017 at 10:31 AM, Stephen Gallagher  
>>> wrote:

 What's the advantage here vs. providing a "Python Classroom Lab" install 
 target
 in GNOME Software that allows you to turn any Fedora Workstation 
 installation
 into a Classroom Lab?

>>>
>>> GNOME Software can't do that. As far as I know, there's no
>>> way to expose installable groups in GNOME Software. Apper (in KDE) has
>>> some capability for it, but the PackageKit backend (dnf backend) has
>>> no support for it because it was not implemented because GNOME
>>> Software has no support for groups.
>>>
>>
>> Sure it can; you just create a metapackage that Requires/Recommends: all of 
>> the
>> members of the comps group and add AppData XML and a logo to that 
>> metapackage.
> 
> Um... that sounds like a hack to work around the fact that GNOME
> Software doesn't have support for groups.  I'm not sure that
> suggestion is fixing the right problem.
> 

Well, I'm not sure it *can* be solved without a master package, because
something needs to provide AppData and logos.




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Python Classroom Lab

[Josh Boyer]

On Wed, Feb 1, 2017 at 10:40 AM, Stephen Gallagher  wrote:
> On 02/01/2017 10:34 AM, Neal Gompa wrote:
>> On Wed, Feb 1, 2017 at 10:31 AM, Stephen Gallagher  
>> wrote:
>>>
>>> What's the advantage here vs. providing a "Python Classroom Lab" install 
>>> target
>>> in GNOME Software that allows you to turn any Fedora Workstation 
>>> installation
>>> into a Classroom Lab?
>>>
>>
>> GNOME Software can't do that. As far as I know, there's no
>> way to expose installable groups in GNOME Software. Apper (in KDE) has
>> some capability for it, but the PackageKit backend (dnf backend) has
>> no support for it because it was not implemented because GNOME
>> Software has no support for groups.
>>
>
> Sure it can; you just create a metapackage that Requires/Recommends: all of 
> the
> members of the comps group and add AppData XML and a logo to that metapackage.

Um... that sounds like a hack to work around the fact that GNOME
Software doesn't have support for groups.  I'm not sure that
suggestion is fixing the right problem.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Why does BuildRequires: kernel in Koji pull in kernel-debug-*?

[Neal Gompa]

On Thu, Feb 2, 2017 at 6:26 AM, Richard W.M. Jones  wrote:
>
> libguestfs BuildRequires: kernel, but gets kernel-debug-core:
>
> https://kojipkgs.fedoraproject.org//packages/libguestfs/1.34.4/1.fc25/data/logs/x86_64/root.log
> (from https://koji.fedoraproject.org/koji/buildinfo?buildID=837312)
>
> Why?
>

It's because of this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1228897

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Why does BuildRequires: kernel in Koji pull in kernel-debug-*?

[Richard W.M. Jones]

libguestfs BuildRequires: kernel, but gets kernel-debug-core:

https://kojipkgs.fedoraproject.org//packages/libguestfs/1.34.4/1.fc25/data/logs/x86_64/root.log
(from https://koji.fedoraproject.org/koji/buildinfo?buildID=837312)

Why?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 Self Contained Change: Anaconda LVM RAID

[David Woodhouse]

Please don't drop me from Cc when replying. I know the list has a
misguided setup, but mailers can be configured to ignore that. Thanks.

http://david.woodhou.se/reply-to-list.html

On Wed, 2017-02-01 at 12:13 -0700, Chris Murphy wrote:
> On Wed, Feb 1, 2017 at 4:55 AM, David Woodhouse  wrote:
> > My server at home broke on upgrading to Fedora 22 (#1201962), and also
> > on upgrading to Fedora 20 before that (IIRC).
>
> That's a while ago, the system upgrade method is different now. At
> least on workstation it's using systemd offline update to do the major
> version upgrade, same as minor updates. So if it's able to do minor
> updates without breaking, it should be able to do the major one
> successfully. Whether there may be a bug that prevents a successfully
> upgraded system from booting - well that's what testing is for.

I'm not sure the upgrade method matters, does it? In both cases I think
it was changes to dracut and the way raid was assembled (perhaps moving
from automatically in the kernel to doing it in userspace, or vice
versa).

> > So let's please ensure that we have proper
> > test coverage for existing systems.
>
> Please describe your proposal for ensuring proper test coverage, in
> particular if you personally aren't able to test what is by definition
> a custom layout?

Nono, this *isn't* a custom layout. It's a fairly standard RAID setup.
But if we change the defaults, then I suppose that retrospectively
*makes* it a "custom layout"... at least in the sense that we can
reasonably expect it to keep breaking every release or two :(


smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Dependency rebuild order

[Richard W.M. Jones]

On Wed, Feb 01, 2017 at 08:02:19PM +0100, Sandro Mani wrote:
> Hi
> 
> Wondering if someone has some neat script which outputs the rebuild
> order of a set of packages, say after a library these depend on
> bumped its soname.

This isn't generally solvable because installing a package can add RPM
macros which adjust the spec file in arbitrary ways.

Anyway, I've got a script I use to rebuild all the OCaml packages.
However it requires a bit of expertise to run:

http://git.annexia.org/?p=goaljobs.git;a=tree
http://git.annexia.org/?p=goals.git;a=blob;f=fedora_ocaml_rebuild.ml

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Dependency rebuild order

[Sandro Mani]

On 02.02.2017 10:40, Honza Silhan wrote:

Hi,

my former colleague was investigating how to do it. This task had been
already solved by the mach project available at
http://thomas.apestaart.org/projects/mach/ and packaged in Fedora
under the same name. Interesting bits are inside ./scirpts/mach.in
(more specifically in Root.rebuild() and Srpm.results()).


Cool, I'll have a look, thanks!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Kerberos KCM credential cache by default

[Alexander Bokovoy]

On ti, 31 tammi 2017, Florian Weimer wrote:

On 01/31/2017 02:38 PM, Jakub Hrozek wrote:

On Tue, Jan 31, 2017 at 02:36:12PM +0100, Florian Weimer wrote:

On 01/31/2017 10:36 AM, David Woodhouse wrote:

Please ensure this works with winbind. The switch to KEYRING: by
default didn't — pam_winbind was putting creds in /tmp/krb5cc_$UID
still, and then they weren't consistently being found there.


OpenJDK could be affected by this as well.


Does OpenJDK work with KERING now or only handles FILE?


Hmm.  I assumed it handled KEYRING:, but both jdk8 and jdk9 only seem 
to implement FILE:.  So this change shouldn't result in a regression.

Unfortunately, JDKs are tending not to value integration with
system-wide Kerberos libraries. We had this issue with S4U2Proxy support
(it took three or more years to get S4U2Proxy support in Java's native
Kerberos provider) and we'll continue having it with other features. KCM
protocol in libkrb5 is the same one libkrb5 is already using on Mac OS
X, with a small change of doing Unix domain socket on the Linux and
doing a special kernel interface on Mac OS X.

--
/ Alexander Bokovoy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Dependency rebuild order

[Honza Silhan]

Hi,

my former colleague was investigating how to do it. This task had been
already solved by the mach project available at
http://thomas.apestaart.org/projects/mach/ and packaged in Fedora
under the same name. Interesting bits are inside ./scirpts/mach.in
(more specifically in Root.rebuild() and Srpm.results()).

Honza

On Wed, Feb 1, 2017 at 8:02 PM, Sandro Mani  wrote:
> Hi
>
> Wondering if someone has some neat script which outputs the rebuild order of
> a set of packages, say after a library these depend on bumped its soname.
>
> Thanks
> Sandro
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Kerberos KCM credential cache by default

[Alexander Bokovoy]

On ti, 31 tammi 2017, David Woodhouse wrote:

On Tue, 2017-01-31 at 10:24 +0100, Jan Kurik wrote:

= System Wide Change: Kerberos KCM credential cache by default =
https://fedoraproject.org/wiki/Changes/KerberosKCMCache

Change owner(s):
* Jakub Hrozek


Default to a new Kerberos credential cache type called KCM which is
better suited for containerized environments and provides a better
user experience in the general case as well.


== Detailed Description ==
Over time, Fedora used different credential cache types to store
Kerberos credentials - going from a simple file-based storage (FILE:)
to a directory (DIR:) and most recently a kernel-keyring based cache
(KEYRING:).

Each of these caches has its own set of advantages and disadvantages.
The FILE ccache is very widely supported, but does not allow multiple
primary caches in a collection. The DIR cache does, but creating and
managing the directories including proper access control can be
tricky. The KEYRING cache is not well suited for cases where multiple
semi-isolated environments might share the same kernel. Managing
credential caches' life cycle is not well solved in neither of these
cache types automatically, only with the help of a daemon like SSSD.

The scope of this change is to introduce a new Kerberos credential
cache type called KCM and switch to using it by default.

With KCM, the Kerberos caches are not stored in a "passive" store, but
managed by a daemon. In this setup, the Kerberos library (typically
used through an application, like for example, kinit) is a "KCM
client" and the daemon is being referred to as a "KCM server". The KCM
server will be provided as a socket-activated service of the SSSD
deamon.


Please ensure this works with winbind. The switch to KEYRING: by
default didn't — pam_winbind was putting creds in /tmp/krb5cc_$UID
still, and then they weren't consistently being found there.

It is a bug in winbindd. There is a patch on samba-technical@ which
attempts to fix this but I haven't yet looked into reviewing it, sorry.

--
/ Alexander Bokovoy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1418484] perl-Code-TidyAll-0.56 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1418484

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Code-TidyAll-0.56-1.fc
   ||26
 Resolution|--- |RAWHIDE
Last Closed||2017-02-02 04:32:18



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Kerberos KCM credential cache by default

[Alexander Bokovoy]

On ti, 31 tammi 2017, Rex Dieter wrote:

Jan Kurik wrote:


F26 System Wide Change: Kerberos KCM credential cache by default


Hi, can you please consider changing the name of this change/feature to not
use "KCM".  That's an acronym commonly used in kde/plasma for KDE Config
Module, e.g.
https://techbase.kde.org/Development/Tutorials/KCM_HowTo
to avoid any possible confusion, thanks.

Sorry, KCM is the name of the feature in Kerberos, namely Kerberos Cache
Manager. The very same KCM protocol is used on Mac OS X.


That said, googling seems to imply that kcm has a history of being commonly
used in kerberos contexts too for awhile, so there may be no avoiding it. :(

Yep.

--
/ Alexander Bokovoy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Kerberos KCM credential cache by default

[Alexander Bokovoy]

On ti, 31 tammi 2017, Jakub Hrozek wrote:

On Tue, Jan 31, 2017 at 09:47:05AM -0600, Rex Dieter wrote:

Jakub Hrozek wrote:

> On Tue, Jan 31, 2017 at 07:04:33AM -0600, Rex Dieter wrote:
>> Jan Kurik wrote:
>>
>> > F26 System Wide Change: Kerberos KCM credential cache by default
>>
>> Hi, can you please consider changing the name of this change/feature to
>> not
>> use "KCM".  That's an acronym commonly used in kde/plasma for KDE Config
>> Module, e.g.
>> https://techbase.kde.org/Development/Tutorials/KCM_HowTo
>> to avoid any possible confusion, thanks.
>
> I'm fine with renaming the change but I'm not sure what name would be
> better, do you have some suggestion?

just take KCM out?  "Kerberos credential cache by default" should still be
fairly clear.  If not (clear), then don't worry about it.


Kerberos credential cache is a fairly generic term. KCM is one type of a
Kerberos credential cache, FILE: is another, KEYRING is another..

It is Kerberos Cache Manager, as opposed to credentials cache or
credentials cache collections.

--
/ Alexander Bokovoy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: HEADS UP: libwebp-0.6.0 soname bumps

[Sandro Mani]

On 02.02.2017 08:49, Kalev Lember wrote:

On 02/02/2017 08:12 AM, Kalev Lember wrote:

Hi Sandro,

Thanks for working on this! The number of packages affected by the
soname bump is quite big though and I think it needs a compat package.
We probably wouldn't have to keep it around for a long time, but maybe
it should be there during the F26 lifetime and get retired in F27.

This is a bit pressing right now because webkitgtk4 is currently failing
to rebuild and that is causing broken deps for Workstation and leading
to the QA nightly tests not working and so on.

I also imagine there are a bunch of third party packages that are still
linking with old libwebp soname and would benefit if we kept the ABI
compatibility as well.

Would you have time to review a compat package and help maintain it if I
put one together?

https://bugzilla.redhat.com/show_bug.cgi?id=1418572 is the review for
compat-libwebp05 package I put together just now.

I see the review is already taken care of. Happy to help maintaining if 
required.


Thanks
Sandor
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: HEADS UP: libwebp-0.6.0 soname bumps

[Sandro Mani]

On 01.02.2017 18:59, Sandro Mani wrote:

Hi

I'm about to fire off the libwebp and mingw-libwebp 0.6.0 updates, 
which include soname bumps.


I'm rebuilding all of the dependent packages:

A quick status update here on the packages not yet rebuilt:

- Packages which are stuck due to depending directly or indirectly on 
numpy whose GCC7 rebuild failed due to a test failure in ppc64le:

gdal
python-pillow
opencv
python-webm
mapnik
OpenImageIO
python-mapnik

- Packages still building/pending:
webkitgtk3
gnuplot

- Other failures unrelated to libwebp:

guacamole-server-0.9.10-2.fc26
typescript.c:133:46: error: '%s' directive writing 6 bytes into a region 
of size between 0 and 2047 [-Werror=format-overflow=]


weston-1.12.0-2.fc26
libweston/compositor-rdp.c:621:53: error: 'RDP_PIXEL_FORMAT_B8G8R8A8' 
undeclared (first use in this function); did you mean 'PIXEL_FORMAT_BGRA32'?


mingw-qt5-qtwebkit-5.5.1-4.fc26
/builddir/build/BUILD/qtwebkit-opensource-src-5.5.1/Source/WTF/wtf/Atomics.h:259:19: 
error: '_mm_mfence' was not declared in this scope

 MemoryBarrier();

qt5-qtwebengine-5.7.1-7.fc26
/builddir/build/BUILD/qtwebengine-opensource-src-5.7.1/src/3rdparty/chromium/v8/src/objects.h:3170:55: 
error: invalid use of incomplete type 'class v8::internal::Heap'


efl-1.18.4-3.fc26
ELUA_EOLIAN_LIBRARY_PATH=../src/lib/eolian/.libs ../src/bin/elua/elua 
-I/builddir/build/BUILD/efl-1.18.4/src/bindings/luajit 
-C/builddir/build/BUILD/efl-1.18.4/src/scripts/elua/core 
-M/builddir/build/BUILD/efl-1.18.4/src/scripts/elua/modules 
-A/builddir/build/BUILD/efl-1.18.4/src/scripts/elua/apps lualian -I. -o 
lib/ecore_audio/ecore_audio.eo.lua lib/ecore_audio/ecore_audio.eo
make[4]: *** [Makefile:52023: lib/ecore_audio/ecore_audio.eo.lua] 
Segmentation fault (core dumped)


purple-telegram-1.3.0-2.fc26
tl-parser/tl-parser.c:1907:21: error: '__builtin___sprintf_chk' may 
write a terminating nul past the end of the destination 
[-Werror=format-overflow=]

 sprintf (s, "%lld", lrand48 () * (1ll << 32) + lrand48 ());

webkitgtk4-2.15.4-2.fc26
/builddir/build/BUILD/webkitgtk-2.15.4/Source/JavaScriptCore/b3/air/AirLiveness.h:110:54: 
internal compiler error: in tsubst_copy, at cp/pt.c:14398


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1418132] perl-Net-STOMP-Client-2.3 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1418132



--- Comment #1 from Fedora Update System  ---
perl-Net-STOMP-Client-2.3-1.el7 has been submitted as an update to Fedora EPEL
7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4822324076

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1418132] perl-Net-STOMP-Client-2.3 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1418132



--- Comment #4 from Fedora Update System  ---
perl-Net-STOMP-Client-2.3-1.el5 has been submitted as an update to Fedora EPEL
5. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-9883adf65e

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1418132] perl-Net-STOMP-Client-2.3 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1418132



--- Comment #2 from Fedora Update System  ---
perl-Net-STOMP-Client-2.3-1.el6 has been submitted as an update to Fedora EPEL
6. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-102609ab15

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1418132] perl-Net-STOMP-Client-2.3 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1418132



--- Comment #3 from Fedora Update System  ---
perl-Net-STOMP-Client-2.3-1.fc25 has been submitted as an update to Fedora 25.
https://bodhi.fedoraproject.org/updates/FEDORA-2017-7dde4ae472

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: HEADS UP: libwebp-0.6.0 soname bumps

[Kalev Lember]

On 02/02/2017 08:12 AM, Kalev Lember wrote:
> Hi Sandro,
> 
> Thanks for working on this! The number of packages affected by the
> soname bump is quite big though and I think it needs a compat package.
> We probably wouldn't have to keep it around for a long time, but maybe
> it should be there during the F26 lifetime and get retired in F27.
> 
> This is a bit pressing right now because webkitgtk4 is currently failing
> to rebuild and that is causing broken deps for Workstation and leading
> to the QA nightly tests not working and so on.
> 
> I also imagine there are a bunch of third party packages that are still
> linking with old libwebp soname and would benefit if we kept the ABI
> compatibility as well.
> 
> Would you have time to review a compat package and help maintain it if I
> put one together?

https://bugzilla.redhat.com/show_bug.cgi?id=1418572 is the review for
compat-libwebp05 package I put together just now.

-- 
Kalev
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org